LPC43S50 AES issue

[lpcware]

Content originally posted in LPCWare by rmilne on Wed May 27 06:36:10 MST 2015
Hi,

I cannot get aes ROM encryption to work properly on my LPC43S50 part and hopefully someone can point out my problem by looking at my code sample.  I use the same key & data provided in section 8.5.5 of UM10503 and have verified the output on an offline tool.  My results are 0x82, 0xa2, ... instead of the expected 0xc5, 0xcc, ...

I've coded the following test according to my interpretation of the document and have run out of ideas for getting the proper output.  Built with IAR EWARM 7.2. 

Is there sample code available for reference?
  

static bool is_init = false;
static uint8_t out_buf[16];

bool aesTest(void) {
  uint32_t retval;
  uint8_t test_key[16] = { 0x0f, 0x0e, 0x0d, 0x0c, 0x0b, 0x0a, 0x09, 0x08,
                           0x07, 0x06, 0x05, 0x04, 0x03, 0x02, 0x01, 0x00 };
  uint8_t test_data[16] = { 0x0f, 0x0e, 0x0d, 0x0c, 0x0b, 0x0a, 0x09, 0x08,
                            0x07, 0x06, 0x05, 0x04, 0x03, 0x02, 0x01, 0x00 };

  if(!is_init) {
    retval = Chip_AES_Init();
    if(retval == 0)
      is_init = true;
    else
      return false;
  }

  Chip_AES_LoadKeySW(test_key);

  retval = Chip_AES_SetMode(CHIP_AES_API_CMD_ENCODE_ECB);
  if(retval != 0)
    return false;

  retval = Chip_AES_Operate(out_buf, test_data, 1);
  if(retval != 0)
    return false;

  return true;
}

[lpcware]

Content originally posted in LPCWare by rmilne on Thu May 28 06:35:32 MST 2015
You're welcome.  An open engineering community is a happier place to be than a closed one.

Another find while I'm at it...

The aes ROM will also work using an unencrypted binary as long as the header is present.  My original programs failed because I was using IAR to load the binary which of course has no in-built feature to prepend a header.  Using the generic LPCScrypt tool will do fine for development (-key attribute not available).  Also the system requires a power cycle before the aes ROM will function - issuing a reset via the debugger after loading is insufficient.

[lpcware]

Content originally posted in LPCWare by jsidebottom on Wed May 27 21:22:21 MST 2015
Thanks for sharing, even if you aren't getting any help.
I've got one of these ordered, and am grateful to you (in advance) for the avoided frustration.

[lpcware]

Content originally posted in LPCWare by rmilne on Wed May 27 12:13:43 MST 2015
Well i just keep answering my own questions here (feels like a blog).  Turns out that Chip_AES_LoadKeySW and Chip_AES_ProgramKey do work but only if the code is loaded by the secure boot feature.  My steps using IAR with JLink with code programmed to SPIFI:

1/ Build your project and link for a zero starting address (UM says 0x10000000 - I disagree)

2/ Sign the binary with image_manager.exe (AES capable one provided by NXP after signing export control agreement):

C:\NXP\LPCScrypt\bin>image_manager -key 00000000000000000000000000000000 -i C:\path\to\out.bin -o C:\path\to\out.bin.hdr --bin

3/ Delete the .hdr extension from the file written by step 2.  Start JLink.exe in the same directory as the encrypted binary and load it to the SPIFI:
NB: Use the latest beta release of the jlink drivers - lpc43xx spifi programming was fixed just a few days ago

J-Link>loadbin out.bin 0x14000000

4/ Run the debugger without loading the code.  Note also that SWO won't work in this mode.

5/ Inaudible sigh of relief from my cubicle

[lpcware]

Content originally posted in LPCWare by rmilne on Wed May 27 11:41:22 MST 2015
...update. I found aes example code inside lpcopen_2_16_keil_iar_nxp_lpcxpresso_4337.zip and the entire array of data, key and output is completely reversed (little endian in both byte and word order)! Weird (and inefficient for network ordered data) but I can work with it. Unfortunately my test still fails because the key seems to be stuck at all zeros - the Chip_AES_LoadKeySW call has no effect. It looks like the only key I'm permitted is zeros. Do I have to program key zero (and lose my jtag) to get this to work?

BTW - I tried to program key 1 to test a non-zero key and it returned OK but actually failed because it too is still just zeros. Programming a second time returned 0x30003 (already programmed) but it is incorrectly programmed. Encryption with this key is again giving me the results of a zero key. Arrrgh!