Encrypted Boot: Field Updates

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Encrypted Boot: Field Updates

803 Views
floriandoerfler
Contributor III

Hi All

I would like to decrypt one partition of a linux system to memory using the encrypted boot feature in HAB. He have to be able to make updates to this partition in the field. So the procedure described in the CST documentation is not feasible for us: It suggests to load the unencrypted key onto the target hardware, encrypt it with the device-unique key using the CAAM, store the encrypted key blob and throw away the unencrypted key. It does not make sense to publish an encrypted partition together with the key to decrypt it.

So I thought of two ways to go:

Idea 1: Use a constant partition encryption key

Use the key that was used to create the initial data partition to also encrypt updated versions of the partition (using a generic AES encryption tool). As the encryption key for the partition does not change with an update, we don't have to update the encryption key blob. I would also have to update the bootloader, because the attached CSF contains a MAC of the data partition, which would have to change with an updated partition. The process of creating an updated bootloader creates a new secret key and encrypted partition, but I would throw that away.
The question here is: Is the MAC in the binary CSF connected with the new (unused) encryption key? This would invalidate this procedure. This possibility is described in the attached image.

Idea 2: Use a constant KEK

Build the updated system as the original one, using a self-chosen KEK stored in the SNVS. This way we can compute the encryption key blob (using a generic AES software) and attach it to the updated data partition BEFORE WE PUBLISH IT.

Does anyone understand what I'm trying to do? Any thoughts on either of the two solutions?

Regards

Florian

Tags (2)
0 Kudos
1 Reply

474 Views
Yuri
NXP Employee
NXP Employee

Hello,

Please look at my comments below.

1.

  The MAC is appended in the blob , and is intended to check the integrity of the encrypted DEK.

The CSF in section [Decrypt Data] only specifies the data range being decrypted by CAAM. The
command defines the index of the key, which is the one specified in the [Install Secret Key] command.

2.
Basically the U-Boot provides the tools to generate a DEK blob using a DEK in plaintext.

If needed, customers, can try using KEK, stored in the SNVS, instead of the DEK.  


Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos