i.MX8MP + HAB + encrypted storage using CAAM

[JiriCh]

Hello,

I am using i.MX8MP processor with eMMC for persistent storage. I want to use secure boot (HAB) and create encrypted storage on eMMC using CAAM secure keys. eMMC is partitioned. I use one partition to store keys generated by caam-keygen and other partition (/dev/mmcblk2p7) is for the encrypted storage. I first created the encrypted storage on partition /dev/mmcblk2p7 using the steps descripted in AN12714. It works fine. I created a script that is called by Linux on my behalf at boot. The script imports key from blob, add it to the key retention service and mount the file system at /fsencrypted.

However, when I enabled HAB,  I got the following errors at Linux boot. 

<13>Jan  1 00:00:00 rc: Mounting enrypted storage on /dev/mmcblk2p7
[    7.771096] caam_jr 30903000.jr: Failed to execute blob decap descriptor
[    7.779322] caam_jr 30903000.jr: Blob decapsulation failed: -74
<13>Jan  1 00:00:00 rc:
<13>Jan  1 00:00:00 rc: CAAM keygen usage: caam-keygen [options]
<13>Jan  1 00:00:00 rc: Options:
<13>Jan  1 00:00:00 rc: create <key_name> <key_enc> <key_mode> <key_val> <text_type>
<13>Jan  1 00:00:00 rc: <key_name> the name of the file that will contain the black key.
<13>Jan  1 00:00:00 rc: A file with the same name, but with .bb extension, will contain the black blob.
<13>Jan  1 00:00:00 rc: <key_enc> can be ecb or ccm
<13>Jan  1 00:00:00 rc: <key_mode> can be -s or -t.
<13>Jan  1 00:00:00 rc: -s generate a black key from random with the size given in the next argument
<13>Jan  1 00:00:00 rc: -t generate a black key from a plaintext given in the next argument
<13>Jan  1 00:00:00 rc: <key_val> the size or the plaintext based on the previous argument (<key_mode>)
<13>Jan  1 00:00:00 rc: <text_type> can be -h or -p (default argument is -p)
<13>Jan  1 00:00:00 rc: -h generate a black key from the hex text that is provided in previous argument
<13>Jan  1 00:00:00 rc: -p generate a black key from the plain text that is provided in previous argument
<13>Jan  1 00:00:00 rc: import <blob_name> <key_name>
<13>Jan  1 00:00:00 rc: <blob_name> the absolute path of the file that contains the blob
<13>Jan  1 00:00:00 rc: <key_name> the name of the file that will contain the black key.
[    7.915905] trusted_key: device-mapper: crypt: dm-0: INTEGRITY AEAD ERROR, sector 204672
[    7.924042] trusted_key: device-mapper: crypt: dm-0: INTEGRITY AEAD ERROR, sector 204673
[    7.932172] trusted_key: device-mapper: crypt: dm-0: INTEGRITY AEAD ERROR, sector 204674
[    7.940292] trusted_key: device-mapper: crypt: dm-0: INTEGRITY AEAD ERROR, sector 204675
[    7.948466] trusted_key: device-mapper: crypt: dm-0: INTEGRITY AEAD ERROR, sector 204676
[    7.956639] trusted_key: device-mapper: crypt: dm-0: INTEGRITY AEAD ERROR, sector 204677
[    7.964793] trusted_key: device-mapper: crypt: dm-0: INTEGRITY AEAD ERROR, sector 204678
[    7.972971] trusted_key: device-mapper: crypt: dm-0: INTEGRITY AEAD ERROR, sector 204679
[    7.982432] trusted_key: device-mapper: crypt: dm-0: INTEGRITY AEAD ERROR, sector 204672
[    7.990562] trusted_key: device-mapper: crypt: dm-0: INTEGRITY AEAD ERROR, sector 204673
[    7.998853] Buffer I/O error on dev dm-0, logical block 25584, async page read
[    8.026440] EXT4-fs (dm-0): unable to read superblock
<13>Jan  1 00:00:00 rc: mount: /fsencrypted: can't read superblock on /dev/mapper/encrypted.
<13>Jan  1 00:00:00 rc: error: exit code 32

I figured out that I have to re-create the encrypted storage again (steps from AN12714) to get it working. However that removes my data stored on the partition. 

To avoid these issues, seems I first have to enable HAB and then create encrypted storage. 

My question is WHY? What happens with encrypted storage when I enable HAB? Do I do something wrong?

Thank you,

Jiri

[jrantanen · Accepted solution]

It's quite likely due to the fact that CAAM uses a "test key" while in open configuration (ie. before you close the device for fully enabling High Assurance Boot).

Once you close the device CAAM starts using the "real key" (ie. the OTPMK, a one time programmable master key, which is unique to each chip) and thus: anything encrypted with the test key becomes inaccessible.

See: https://community.nxp.com/t5/i-MX-Processors/i-MX-device-specific-black-key-blob/m-p/1380868/highlig...

[JiriCh]

Thank you for explanation.