Hello,
I want to encrypt a trusted application (.ta file) for OP-TEE on my Jetson AGX Orin Dev Kit on L4T 36.4.
To do that, I need access to the Hardware Unique Key (HUK), which depends on the platform implementation. I made a github issue for the encryption of a trusted application on OP-TEE How to encrypt a .ta file? · Issue #7112 · OP-TEE/optee_os · GitHub. Here it was pointed out that in order to encrypt a TA, the function tee_otp_get_hw_unique_key() in core/kernel/otp_stubs.c needs to be adjusted to read the HUK. How can I access the HUK on a Jetson AGX Orin?
On the file core/kernel/otp_stubs.c pointed out in the issue, there is a comment:
/*
* Override these in your platform code to really fetch device-unique
* bits from e-fuses or whatever.
*
* The default implementation just sets it to a constant.
*/
Since I dont want to use a constant value, I need to be able to read the HUK.
In the Secure Storage chapter, I can read:
Jetson Linux provides a HUK implementation, and it is calculated by using the NIST-SP-800-108 algorithm:
HUK = NIST-SP-800-108(key, context, label)
Where:
key is the EKB_RK. The OP-TEE document has a detailed description about EKB_RK.
context is the ECID of the Jetson device.
label is “tee-hw-unique-key”.
In the OP-TEE chapter you write that EKB_RK key should be burned onto theOEM_K1 fuse as the EKB fuse key. Also, there you write that MB2 is the the Bootloader stage that passes the EKB to OP-TEE. Does that mean that I might not need to read it myself because OP-TEE already knows about it? How can I use it then?
If not, how can I read that fuse key in the OP-TEE function to use it properly in the NIST-SP-800-108 function to calculate the HUK to use it for the TA encryption?
Where can I get the values for ‘context’ and ‘label’?
Would my approach generally be correct to do that or do I need to make some adjustments?
I really appreciate your help in the forum, thank you.
thank you for your reply. From your reference to the other topic I understand that OEM_K1 is the root of trust for the EKB. In the modes of operations part I can understand that once the device boots up, the nvluks-srv-app CA queries the luks-srv TA to recieve the per-device unique passphrase. For that, the TA sends a request to jetson_user_key_pta to generate a per-device unique LUKS key. The jetson_user_key_pta uses the NIST-SP 800-108 KD to derive a new key from the EKB disk encryption key. Now, the TA generates a passphrase with that LUKS key. This passphrase is then returned to the CA.
Does that mean that in my case, I need to also call the jetson_user_key_pta and derive a key from that and encrypt the TA with that key? That means I have to call the jetson_user_key_pta function inside the tee_otp_get_hw_unique_key() in core/kernel/otp_stubs.c to read the key that I would use for the encryption of the TA?
Or is there maybe the other situation, that I don’t need to implement the key reading myself and just need to encrypt the TA using a key derived from the EKB?
A small add on: I think I might have had a misunderstanding. I read in the OP-TEE chapter the following note: "To test the EKS feature on a board, where OEM_K1 has not been burned, OP-TEE uses a pre-defined hard-coded key instead of OEM_K1. However, after the security mode fuse is burned (make sure OEM_K1 fuse is burned before the security mode fuse), the EKS image must be created with the OEM_K1 value as the signing and encryption key."
Does that mean that once the OEM_K1 key is burned on the fuse, OP-TEE automatically uses the OEM_K1 key as signing and encryption key for the trusted applications? So I just have to sign and encrypt the TA with the OEM_K1 key and then I can deploy the TA in encrypted form on the Jetson AGX Orin?
BTW,
according to developer guide, i.e. Secure Boot — NVIDIA Jetson Linux Developer Guide 1 documentation
the root-of-trust that uses the NVIDIA SoCs fuses to authenticate boot codes ends at the Bootloader. After this, the current Bootloader (UEFI) will use UEFI’s Security Keys scheme to authenticate its payloads.
we strongly recommend that users enable fuse-based bootloader secure boot so that the root-of-trust can start from the BootROM.