L4T 35.5.0 EKB CMAC Failure on fused device

After fusing a Orin Nano on 5.1.3/35.5.0, I get the following EKB CMAC error on boot. I have added some additional debug/print statements to OPTEE to narrow down the issue (some addresses and values are redacted). Prior to fusing (and using the default EKB image in the BSP source) the CMAC check completes OK and the device boots normally.

ÿäNOTICE:  BL31: v2.6(release):
NOTICE:  BL31: Built : 00:00:00, Jan  1 1980
I/TC: Physical secure memory base 0x27c040000 size 0x3fc0000
I/TC:
I/TC: Non-secure external DT found
I/TC: OP-TEE version: 3.22 (gcc version 9.5.0 (GCC)) #1 Tue Jan  1 00:00:00 UTC 1980 aarch64
I/TC: Primary CPU initializing
E/TC:00 00 hwkey_derivation_process:359 Derived EKB_RK from #0 fuse key succeeded
E/TC:00 00 hwkey_derivation_process:359 Derived EKB_RK from #1 fuse key succeeded
E/TC:00 00 jetson_user_key_pta_init:967 EKB Base Addr = XX773319YY
E/TC:00 00 ekb_extraction_process:217 EXTRA_LOG: ekb_rks_num = 2
E/TC:00 00 ekb_extraction_process:259 EKB CMAC check of #0 EKB_RK = 99.
E/TC:00 00 ekb_extraction_process:261 EKB signature mismatch when using #0 EKB_RK.
E/TC:00 00 ekb_extraction_process:264 ekb->ekb_cmac as string: XX YY
E/TC:00 00 ekb_extraction_process:265 ekb_cmac_verify as string: XX YY
E/TC:00 00 ekb_extraction_process:259 EKB CMAC check of #1 EKB_RK = 99.
E/TC:00 00 ekb_extraction_process:261 EKB signature mismatch when using #1 EKB_RK.
E/TC:00 00 ekb_extraction_process:264 ekb->ekb_cmac as string: XX YY
E/TC:00 00 ekb_extraction_process:265 ekb_cmac_verify as string: XX YY
E/TC:00 00 ekb_extraction_process:328 Tried all EKB_RKs but still can't extract the EKB image.
E/TC:00 00 jetson_user_key_pta_init:982 jetson_user_key_pta_init: Failed (ffff00XX).
E/TC:00 00 call_initcalls:43 Initcall __text_start + 0x0011d7XX failed
I/TC: Primary CPU switching to normal world boot

I have the following setup:
Orin Nano, Fused with RSA-3k PublicKeyHash, OemK1, and OemK2 i.e (BootSecurityInfo = 0x201)

I have regenerated the ekb.img following the instructions in the nv-optee README.

  • I used the same FV (-fv) as used in our nv-optee.
  • I provided an auth_key (-in-auth-key).

The docs [1] are a bit ambiguous so I’ve tested multiple other flags when generating the EKB:

<sym_key_file> is the user encryption key. This is the user encryption key provided by the --uefi-enc option in the flash command <…>

We do not set --uefi-enc or --uefi-conf when flashing so I’ve tested both omitting the sym_key_file and providing an all zero key (like the example script does).

Burn the EKB fuse key into the device’s fuse. <…> For the Jetson AGX Orin series, Jetson Orin NX series, and Jetson Orin Nano series, the fuse is OEM_K1 or OEM_K2.

Will both OemK1 and OemK2 be automatically attempted as the EKB fuse key? Or is it required to fuse OEM_K1_PURPOSE or OEM_K2_PURPOSE to indicate which OEM key should be the EKB fuse key?

I have not fused either OEM_K1_PURPOSE or OEM_K2_PURPOSE. I have generating the EKB image using both -oem_k1_key and -oem_k2_key but still get the CMAC failure in both cases.

hello anon1,

it sounds like known issue, please try re-generate EKS image for verificaiton.

for instance,
please visit NVIDIA Jetson Linux 35.5.0 to download [Driver Package (BSP) Sources].
please extract atf_src.tbz2 and nvidia-jetson-optee-source.tbz2 packages.
you may follow ./optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh to re-generate EKS image.

BTW,
you may see-also similar discussion thread, Topic 284400 for reference.

Thanks Jerry,

I did see Topic 284400 and I already regenerated the EKS image/partition. I have verified that the new EKS image is present after flashing because I have patched OPTEE (nv-optee) to print the FV and EKB CMAC values and they match what I expect; I can see the CMAC in the EKB image via hexdump -C and it matches the CMAC OPTEE prints as ekb->ekb_cmac.

hello anon1,

please note that, there’re pre-generated EKB keys were used to create EKS image.
may I double confirm what’s customize keys you’re using.

I’m providing my own keys. I’m using gen_ekb.py from the l4t/l4t-35.5.0 branch (rev ed23dddd3) of the nv-optee Git repo.
This is the command I’m using to generate the EKB partition.

python ./gen_ekb.py   \
         -chip t234            \
         -oem_k1_key ./oem_k1.key \
         -fv ./fv_ekb_t234    \
         -in_sym_key ./sym_t234.key     \
         -in_sym_key2 ./sym2_t234.key \
         -in_auth_key ./auth_t234.key     \
         -out ./eks_t234.img
  • oem_k1.key is 64 chars/bytes + LF.
  • fv_ekb_t234, auth_t234.key, sym_t234.key, and sym2_t234.key are all 32 chars/bytes + LF.

I’ve tried omitting the sym_key and/or sym_key2 keys since we don’t use them for kernel or disk encryption. Also the EKB CMAC failure occurs early enough that the exact contents and key types stored in the EKB partition shouldn’t matter.

hello anon1,

did you meant you’ve changed FV (fixed vector) key with yours?
there’s default vector of FV keys, had you also revised fv_for_ekb as mentioned below?
for instance,
$public_sources/atf_and_optee/optee/optee_os/core/pta/tegra/jetson_user_key_pta.c

// Random fixed vector for EKB
static uint8_t fv_for_ekb[] = {
        0xba, 0xd6, 0x6e, 0xb4, 0x48, 0x49, 0x83, 0x68,
        0x4b, 0x99, 0x2f, 0xe5, 0x4a, 0x64, 0x8b, 0xb8,

@JerryChang Yes, the fv_ekb_t234 file passed to gen_ekb matches the fv_for_ekb[] we set in OPTEE via a patch to the jetson_user_key_pta.c file.

here’s another way for testing…
could you please give it a try with the atf_src.tbz2 and nvidia-jetson-optee-source.tbz2 packages from NVIDIA Jetson Linux 35.5.0?

I did check and the two gen_ekb.py files are identical and the entire source/public/optee/optee_os source after extracting atf_src.tbz2 and nvidia-jetson-optee-source.tbz2 are identical to the nv-optee repo src I am using.

Also, I have the same issue on another fused Orin Nano except with a P-521 EC PublicKeyHash, most of my testing is on the P-521 fused board.

hello anon1,

this error log: Tried all EKB_RKs but still can't extract the EKB image.
it means OP-TEE cannot extract the EKS image.
generally, it’s due to the EKS image is not encrypted and signed by a correct key.

it looks you’ve also provided oem_k1_key to python script.
but… did you also have target fused OEM_K1 variable with the same key?

if the target is un-fused,
please try following in the script to set oem_k1.key to all zeros:
echo "0000000000000000000000000000000000000000000000000000000000000000" > oem_k1.key

Yes, the oem_k1_key or oem_k2_key key provided to gen_ekb matches the fused values provided in odmfuse.xml.

hello anon1,

could you please helps to understand…

  1. what fuse variables you’re enabled. (you may omit the values)
  2. please examine all those fuse has program to the target correctly.
  3. please share the complete steps for reference.

Thank you, it appears the OemK1 and OemK2 on one of the devices were just incorrect or missing. On the device I just fused with known OemK1 and OemK2 values, the EKS partition is working now.