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?