Generate same black key(on different boot) from blob using caam-keygen

[belpai]

Feels that I'm missing some steps on how to generate black keys from blobs every boot and use it to decrypt my partitions.

I was expecting that from a blob, I'd be able to, every boot, generate a black key from the blob using `caam-keygen import <path-to-blob> importKey` and use this black key to decrypt my devices, however I can see that every boot this key changes.
So what we're missing here?

To create the blob, I'm using `caam-keygen create devicekey ecb -s 64` and then using the black key `devicekey` to encrypt my partition. However, only persisting the `.bb` file to use it on the next boot.

I'm using kirskstone branch and haven't enabled HAB yet.
Thanks,

[rudi_cyber]

It is basic security design. Every power cycle CAAM will generate a different black key from black key blob. 

It is similar to the dynamic password when you access your bank account. 

[belpai]

Thank you for the answer @rudi_cyber, I get your point, but still something is not right...

Now, let's go for the next step on how we encrypt the partitions... We were previously using the blob to encrypt/decrypt, but we know this is not quite safe as the blob is just available.

We're using `cryptsetup` for this, so for encrypting we're:

`cryptsetup -q luksFormat /dev/mmcblk1 --key-file /tmp/devicekey`

and to decrypt (after reboot) we're:

`cryptsetup open /dev/mmcblk1 rootA --key-file /tmp/deviceKey`

We're checking the an12714 (attached), they're using dmsetup instead, however still having a reboot in the middle and using the same black key generated from the blob in different boots to decrypt the partition. What am I missing here?

[Harvey021]

Hi @belpai 

CAAM's built-in blob protocol provides a method for protecting user-defined data across
system power cycles. The data to be protected is encrypted so that it can be safely placed
into non-volatile storage before the chip is powered down. Each time that the blob protocol is used to protect data, a different randomly generated key is used to encrypt the data. This random key is itself encrypted using a key encryption key and the resulting encrypted key is then stored along with the encrypted data. The key-encryption key is derived from the chip's master secret key so the key-encryption key can be recreated when the chip powers up again. 

Best regards

Harvey

[belpai]

@Harvey021I'm starting to understand it a bit better. Thanks for the patience

However, how can I have access to the key-encryption key? As IMHO, this is a good one to be used to encrypt our rootfs, as it's related to the CAAM module only and can't be read from a NV partition.

After this is done, at some point we'll fuse (enable HAB), so then the partition can only be decrypt by the same hw (same CAAM).

More specifically: how (based on what I showed on my previous replies) I should approach this issue? You agree with me that encrypting using the blob as key isn't a very good idea, right?

[Harvey021]

"encrypting using the blob as key isn't a very good idea, right?"

Would you be willing to share your thoughts through mail?

harvey.yu_1@nxp.com

Best regards

Harvey

[rudi_cyber]

It is very clear description in 2.3 DM-Crypt using CAAM's Secure Key of AN12714.

The black key is session key. 

The DM-Crypt  is using red key to do encryption not the black key. 

The black key changing every power cycle. But CAAM will get the same red key. 

If you read i.MX Linux User's Guide(bsp release document) 10.6 crypto_af_alg application support or crypto af_alg blackkey demo - NXP Community.  , you can see  it doesn't matter the black key is changing. CAAM knows the openssl key to decrypt the encrypted data.

black key is used to protect red/plaint text key.  black key is not directly used for encryption.

suggest you can read  i.MX Linux User's Guide(bsp release document) the  10.5 Disk encryption acceleration. 

[belpai]

I have read the documentation a few times by now, however it only covers black keys and dmsetup... and I need cryptsetup(luks2) and red keys...

On the same documentation is mentioned that:

"The red key can still be encapsulated to blobs and decapsulated to red key only by CAAM. The encapsulation and decapsulation is performed through the Linux Key Retention service."

I understand from this that having a redkey blob, I can (by adding to the keyring) make it a plain red key.
How can I have a red key blob?

My goal is to use cryptsetup with Luks2, and not do this manually every boot on the initramfs, however it seems that caam-keygen only generates black key blobs and black keys from it, so this is not what I need.
Feel free to help here as well @Harvey021 
I also read this: https://fossies.org/linux/cryptsetup/docs/Keyring.txt that works just fine IF I have a non-changing key on the keyring...

Thank you both,