Precise Usage of OEM_K1 Fuse Key for TA Encryption on Jetson AGX Orin with OP-TEE

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
1

I am exploring the encryption of Trusted Applications (TAs) for the Jetson AGX Orin using OP-TEE, with a specific focus on understanding the role of the OEM_K1 fuse key in this process. After studying the OP-TEE source code, Nvidia’s documentation (on Optee, secure boot, disk encryption etc..), and relevant forum threads, I still need clarification on certain details to ensure a secure and correct implementation.

Setup and Use Case:
In my current theoretical scenario, Bob owns a Jetson AGX Orin DevKit, and Alice needs to send him an encrypted TA. Alice aims to protect the algorithms within the TA from being reverse-engineered by Bob. The key question is: with what key should Alice encrypt and sign the TA so that Bob can run it on his Jetson AGX Orin DevKit? Put another way, what key should Bob share with Alice for her to encrypt and sign the TA?
(For simplicity, let’s set aside the fact that since Bob fused the OEM_K1 key, he knows it and could theoretically decrypt the TA offline. The focus here is on the encryption process within OP-TEE. Assume both Bob and Alice are honest actors with zero malicious intent whatsoever)

So far, I’ve reviewed:

  1. Encryption of a TA using HUK
  2. Purpose of OEM_K2 for Orin AGX
  3. Secure Boot — NVIDIA Jetson Linux Developer Guide 1 documentation
  4. OP-TEE: Open Portable Trusted Execution Environment — NVIDIA Jetson Linux Developer Guide 1 documentation
  5. Disk Encryption — NVIDIA Jetson Linux Developer Guide 1 documentation
  6. Trusted Applications — OP-TEE documentation documentation and Trusted Applications — OP-TEE documentation documentation
  7. How to encrypt a .ta file? · Issue #7112 · OP-TEE/optee_os · GitHub

Current Understanding:

  • TAs are encrypted using a symmetric key (TA_ENC_KEY), which OP-TEE either uses directly or derives from the OEM_K1 fuse key at runtime.
  • The encryption process follows a “sign-then-encrypt-then-MAC” workflow, resulting in a .ta file stored in the REE filesystem.
  • The OEM_K1 is a 256-bit AES key burned into the Jetson AGX Orin’s fuses, specified in big-endian hexadecimal format, as outlined in the Secure Boot documentation.

However, I remain uncertain whether the OEM_K1 key is used directly as TA_ENC_KEY or if some derivation OEM_K1 needs to be done to use it as TA_ENC_KEY to encrypt the TA. This hinges on how OP-TEE on the Jetson AGX Orin handles the key—does it use OEM_K1 directly, or does it perform some derivation and use the derived key to decrypt the TA?

Specific Questions in the Alice and Bob Scenario:

  • Burning OEM_K1: Bob follows the Secure Boot documentation and burns a randomly generated 256-bit AES key into OEM_K1 using odmfuse.sh.
  • Key Sharing: What key should Bob share with Alice so she can encrypt the TA file? Is it the 256-bit AES key fused into OEM_K1, or a key derived from OEM_K1?
  • Derivation Process: If derivation is required, what is the derivation method? This is critical, as if OP-TEE is performing this derivation and using this to decrypt the TA, Bob also needs to do the same derivation on the OEM_K1 and send this derived key to Alice.

Clarity on this query would be highly appreciated! Thank you!

5

hello iamdkg123,

FYI,
there’re OEM_K1/K2 to derive a root key which is itself used to sign and encrypt the EKB.

  • OEM_K1 is the root of trust of EKB, and it is used to derive the RPMB key too.
  • OEM_K2 is to derive the PV encryption key. If you don’t need to encrypt CPUBL with a PV key, you don’t need to care about OEM_K2.

you may see-also OP-TEE samples,
TA: $public_sources/r36.4.3/Linux_for_Tegra/source/atf_and_optee/optee/samples/luks-srv/ta/luks_srv_ta.c
CA: $public_sources/r36.4.3/Linux_for_Tegra/source/atf_and_optee/optee/samples/luks-srv/host/luks_srv_ca.c

it’s the jetson user key PTA to derive keys from EKB. for instance, invoke_jetson_user_key_pta.
you may see-also EKB Key Management for reference.

6

Thank you for the response! Unfortunately this doesn’t address what I am looking for. What I am interested in is what fuse key is used for TA encryption. I understand that OEM_K1 is the root of trust of EKB, and is used to derive the RPMB key as well.

But what I want to know is how and what key is used to encrypt and decrypt the TA?

Some questions related to your answer:

  • “derive the RPMB key”: What exactly is the derivation here? What kind of derivation is done on OEM_K1 ?
  • “derive the PV encryption key. If you don’t need to encrypt CPUBL with a PV key”: What is PV here? what is CPUBL here?

Again, coming back to the topic of TA encryption, how and what fuse is used for encrypting and decrypting the TA?

7

hello iamdkg123,

it’s CA to encrypt and decrypt data using user-defined keys stored in the EKB, and then talked to TA.
you may refer to sample script for those keys to create EKS image.

python3 gen_ekb.py -chip t234 -oem_k1_key oem_k1.key \
        -in_sym_key sym_t234.key \
        -in_sym_key2 sym2_t234.key \
        -in_auth_key auth_t234.key \
        -in_ftpm_sn 00000000000000000000 \
        -in_ftpm_eps_seed ftpm_eps_seed_file \
        -in_ftpm_rsa_ek_cert ftpm_rsa_ek_cert.der \
        -in_ftpm_ec_ek_cert ftpm_ec_ek_cert.der \
        -in_sid_cert sid_cert.der \
        -in_ftpm_rsa_ek_csr ftpm_rsa_ek_csr.der \
        -in_ftpm_ec_ek_csr ftpm_ec_ek_csr.der \
        -out eks_t234.img

moreover, please refer to op-tee sample, cpubl-payload-dec,
for instance, CPUBL Payload Decryption CA and TA.