Encrypted image per i.mx6 unit

[paul_holmquist]

I was reading directions on encrypting u-boot image per Encrypted boot loader on SabreSD i.MX6q board but then at the end had the following statement (after step 18):

As a result we have encrypted boot image which can be loaded and executed by only current board. Because dek_blob.bin is unique per i.MX6 CPU.

If dek_blob is unique per i.MX6 chip/board then how would this be useful when image is for entire fleet of boards in the field?  Having to create a dek_blob per unit would require a service return or worse generate dek_blob and encrypt in the field.  And since the master key is unique per unit that wraps the dek creating the blob, can't make each HAB decrypt the same blob (also bad idea).

Now I don't see much need for encrypting UBoot image since a) Off-the-shelf and b) doesn't change much.  However, I would like to create a single encrypted kernel uimage that "all" units can decrypt.  Is that possible or maybe I'm missing something here....?

[Yuri]

Hello,

  The unique dek_blob  protects against cloning.

The boot ROM supports only OTPMK or default key (in open state)

for encryption boot. 

Have a great day,

Yuri

------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer

button. Thank you!

[paul_holmquist]

I understand how it prevents cloning.  However the problem with the design of this feature is that a unique blob must be appended to the uimage that is intended for a fleet of devices in the field.  This is not a practical solution given that the only way to then use this feature would be to create a database of blobs per unit during manufacturing.  Then when a new SW release must be pushed to all the deployed devices in the field, the build tools would need to generate a unique encrypted uimage (raw_uimage+unique_blob) for each individual device in the field even though the SW in that uimage would be identical.

The only solution around this issue that I can see would be to somehow store the blob in device non-volatile memory.  Then when new SW gets pushed in the field its already encrypted uimage (same DEK) but without the appended blob.  The install SW on the running device would then need to perform the last step of appending the unique blob to the encrypted uimage before preeminently storing.  Is that the intended use of this feature?  NXP seems to be lacking documentation that explains practical use of this feature.

[Yuri · Accepted solution]

Hello,

  Your considerations are correct.  Note, we do not have additional documentation, since

 approach using, for example,  non-volatile memory, is application dependent and we do not 

such boards / designs.  

Regards,

Yuri.