Correct dummy tag for CMAC hash in LPC43Sxx

[lpcware]

Content originally posted in LPCWare by IJeffray on Wed Jul 30 06:10:54 MST 2014
On Page 53 of UM10503.pdf, the dummy tag value for the CMAC hash calculation is given as 0x3456789A.

The problem is, that's a 32bit value and the HASH_VALUE field is 64 bits wide.   Should we repeat the value across the 64bits, or pad with something at top or bottom, or is the value just given incorrectly in the datasheet?

[lpcware]

Content originally posted in LPCWare by IJeffray on Wed Aug 05 07:12:42 MST 2015
Hi LPC folks,

The utility you provided us, in August 2014, was called "image_manager" and definitely had this fault as I described. I discussed the problem at length via telephone and email with NXP support folks at the time.  This is the first I'd heard of "LPCScrypt" -- glad you've resolved that issue.   It would be most agreeable if you'd just release the source code however, since the published documentation (and that available via privileged DocStore access) is still badly lacking.

Ian

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Aug 05 06:59:46 MST 2015

---

Quote: rmilne

IJeffray has also notified me that the NXP image_manager utility doesn't control the AES_CONTROL bits.  This means that there is a 1 in 64 chance that the generated image will brick the part!  A post image generation verification tool is required.

---

I can confirm that the Image_manager utility as supplied with the AES enabled LPCScrypt package specifically checks for the situation where the encrypted header (bits 5:0) takes a 0x1A value - if this occurs, the AES_CONTROL field is used and the encryption process repeated.

The utility will not generate a final encrypted image with a value of 0x1A in bits 5:0 of the header!

For information regarding LPCScrypt, please see:

https://www.lpcware.com/lpcscrypt

With respect to the comments about our documentations description of the encryption process - I accept that both detail and overview information is lacking. This issue will be raised with our documentation team.

Yours,

LPCXpresso-Support

[lpcware]

Content originally posted in LPCWare by rmilne on Thu Jul 30 11:03:18 MST 2015
There is no example code for image creation
The IV of step 1a of section 7.3.2 is wrong and the notation IV = AES-1(User Key,1) is inscrutable. 
Reverse endianness isn't described sufficiently so that a custom offline tool that uses 'normal' byte ordering can be designed to generate secure images
IJeffray has made it known to me that the calculated starting IV must be reused at the start of each 512 byte frame (undocumented and NOT standard CBC)
IJeffray has also notified me that the NXP image_manager utility doesn't control the AES_CONTROL bits.  This means that there is a 1 in 64 chance that the generated image will brick the part!  A post image generation verification tool is required.

My conclusion - section 7 of the UM is worthless as an engineering document but OK for general info for how secure boot functions

[lpcware]

Content originally posted in LPCWare by mc on Wed Jul 29 19:21:11 MST 2015
Hi rmilne,
Thanks for the feedback. Could you please let us know which step is not clear in UM? I can see that the dummy header value is not clearly documented. The header value is shown as below.  We will make it clear in the document.

Bits 63-32 are all 0 and bits 31-0 are already mentioned in the UM. So the dummy header value is 0x000000003456789A .

[lpcware]

Content originally posted in LPCWare by IJeffray on Wed Jul 29 07:45:57 MST 2015
We have successfully implemented code to build images both on the device itself and standalone, not using any LPC code.   The datasheet is garbage - sorely lacking important detail.   There are also bugs in the NXP application which are actually quite serious (it has a 1 in 64 chance of generating an invalid image).  Drop me a line at ijeffray @ a2etech.com and we may be able to help.

[lpcware]

Content originally posted in LPCWare by rmilne on Wed Jul 29 07:27:15 MST 2015
Nothing in that app note addresses my issue.  I'm not using DFU.  I simply want to create my own encrypted images without using the image_manger utility inside the AES version of the LPC Scrypt tool.  Section 7.3.2 seems to describe the process of doing so but I cannot make enough sense of it to replicate the actual output of the image_manger utility using the same key and input binary.  I suspect there is missing info wrt the 512 byte frame requirement.

[lpcware]

Content originally posted in LPCWare by mc on Wed Jul 29 07:08:45 MST 2015
Hi rmilne,
Did you check below application note?
https://www.lpcware.com/content/nxpfile/an11648-lpc18sxx43sxx-secure-boot-qspi-device

[lpcware]

Content originally posted in LPCWare by rmilne on Wed Jul 29 06:49:19 MST 2015
Were you able to manually construct an encrypted image for the LPC43Sxx?
 
I've used the LPC Scrypt tool to generate zero key images that work perfectly on the target but I have yet to be able to construct a custom tool that can generate the same image.  There seems to be missing/misleading/contradictory info in section 7.3.2 of UM10503.  Perhaps NXP doesn't intend on exposing the internal logic of the image_manager utility.