Optee pre-provisioned RPMB key

Technical Support
, , , ,
21

A suggestion that would be the direct way to automate the update, as optee is the whole reason for this additional step. I dont know if you have ever managed a production line, counting minutes each with a cost price.

But as we already have to run and handle 2 YOCTO builds with one line of configuration being different, affecting 10 lines of code - we’ll just put the value of TDX_OPTEE_FS_RPMB_MODE into a file and install it in the image.

Best Regards - Paul

22

Just some quick things to note here. Apologies if these points were already obvious, but I figured I’d write it down just in case:

  • The device must be booted HAB-closed for RPMB fusing to occur. This is because the HUK is only available after the device is closed, and the HUK is used in key derivation.
  • Simply testing whether the image on the device is the factory image or the production image won’t tell you if the device is closed or not.
  • OP-TEE implements a function called plat_rpmb_key_is_ready() to determine whether the device’s HUK is available or not, and will not program the RPMB key if there’s no HUK. This is a safety measure; if you were to write the RPMB key before the device is closed, it would be derived based on the development HUK, which is a fake HUK that is not actually unique to the device.
  • You will need to reboot after programming the HAB keys and setting the HAB mode to closed. After the reboot the RPMB key will be automatically fused into the eMMC.
  • It is only after the reboot in HAB-closed mode that you can safely update to the production image. So rather than testing for the TDX_OPTEE_FS_RPMB_MODE, it would be safer to check if the device is HAB-closed, or that the RPMB key has been programmed. You can check HAB status with the hab_status u-boot command, or with linux userspace utilities to read the appropriate fuse, if they are included in your factory image. To test for whether the RPMB key is programed properly from linux space, meta-toradex-security recommends reading the mmc’s RPMB counter, performing a write, and then verifying that the counter has incremented. Note that if this test passes, it also necessarily implies that the device is HAB-closed.
  • # mmc rpmb read-counter /dev/mmcblk*rpmb
# optee_example_secure_storage
# mmc rpmb read-counter /dev/mmcblk*rpmb
23

After closing device and rebooting “factory” mode mmc command fails

RPMB operation failed, retcode 0x0007

indicating “No RPMB key is enrolled” so something is not working.

Only information from dmesg:

[ 0.000000] OF: reserved mem: 0x9e000000..0x9effffff (16384 KiB) nomap non-reusable optee
[ 1.180953] optee: probing for conduit method.
[ 1.185473] optee: revision 4.4 (ecea75b7)
[ 1.185930] optee: dynamic shared memory is enabled
[ 1.195664] optee: initialized driver

ADDED - this looks bad

[    0.115836] Initialise system trusted keyrings
[    4.977348] Key type trusted registered
[    5.554788] trusted_key: key_unseal failed (-74)
[   10.565026] trusted_key: key_unseal failed (-74)

but entries in optee survive powercycle

Any suggestions to check ?

I will try a clean build from clean repo sync - next year .. maybe something does not clean correctly.

Best Regards - Paul

24

We’ll see if our team can take a look at the errors you shared and come up with some possible ideas that could lead to what you observed.

Best Regards,
Jeremias

25

Are you 100% sure the device is actually closed, and not just fused with HAB/AHAB keys? That is, has the final fusing command generated in the fuse-cmds.txt file actually been run, and then the device powercycled? I’m referring to the one at the end of this block:

# After the device successfully boots a signed image without generating
# any HAB events, it is safe to secure, or 'close', the device. This is
# the last step in the process. Once the fuse is blown, the chip does
# not load an image that has not been signed using the correct PKI tree.
# Be careful! This is again a One-Time Programmable e-fuse. Once you
# write it you can't go back, so get it right the first time. If
# anything in the previous steps wasn't done correctly, after writing
# this bit, the SOM will not boot anymore!
fuse prog <ACTUAL FUSE CMD INTENTIONALLY OMITTED>
26

Hi Jon,

device is locked and which skipping over the u-boot CLI also indicates.

UPDATE:

After starting from clean directory and syncing repo (BSP 7.5.0 kernel 6.6.117) :

Unfortunately result in dmesg is

[   10.926844] trusted_key: key_unseal failed (-74)

And

mmc rpmb read-counter /dev/mmcblk0rpmb
RPMB operation failed, retcode 0x0007

Best Regards - Paul

27

Hi, getting off the original topic.

So i opened a new topic:

Possible OPTEE and CAAM conflict on JR0 (jobring) - Technical Support - Toradex Community

28

Hi @pfarre,

Just to clarify. The new topic is following off the trusted_key: key_unseal failed (-74) issue that you are running into, correct?

Best Regards,
Jeremias

29

Hi Jeremias,

yes primarily the ‘key_unseal’ part and that the encrypted partition seems to fail after going into factory’ mode on OPTEE.

BR - Paul