Fail flashing Orin AGX with UEFI payload encryption enabled (--uefi-enc) enabled with JP36.3

Autonomous Machines Jetson & Embedded Systems Jetson AGX Orin
,
1

I am attempting to flash the JP36.3 to my Orin AGX with UEFI payload signing and encrypting enabled.

I use the following command line:

sudo ./flash.sh --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc /home/default_keys/nvidia-jetson-optee-source/optee/samples/hwkey-agent/host/tool/gen_ekb/sym_t234.key jetson-agx-orin-devkit internal

But I get the following error.

###############################################################################
# L4T BSP Information:
# R36 , REVISION: 3.0
# User release: 0.0
###############################################################################
uefi_enc_content= 010203040506070809a0b0c0d0e0f001
Error: key size has to be 64

/home/default_keys/nvidia-jetson-optee-source/optee/samples/hwkey-agent/host/tool/gen_ekb/sym_t234.key is the file generated by /home/default_keys/nvidia-jetson-optee-source/optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh and just contains “010203040506070809a0b0c0d0e0f001”.

The doc states the key should be 256 bits, so I modified the example.sh in nvidia-jetson-optee-source/optee/samples/hwkey-agent/host/tool/gen_ekb to use a 256 bit long key. I tried “010203040506070809a0b0c0d0e0f001010203040506070809a0b0c0d0e0f001” and “0000000000000000000000000000000000000000000000000000000000000000”. The flashing succeeds, but UEFI boot fails.

Every time I run example.sh I copy the eks_t234.img generated to the bootloader folder prior to flashing.

What am I doing wrong?

I have not flashed OEM_K2 and am hoping to be able to just use the default fuse key. This is what is in the stock example.sh: “432646294a404e635266556a586e3272357538782f413f442a472d4b61506453” for the default OEM_K2. Is this the correct value to use?

I have verified that if I only use --uefi-keys and not --uefi-enc, the OS boots OK. So I think the issues is purely with the UEFI encryption.

EDIT
Here is the error when I boot after flashing with --uefi-enc. It then drops to the UEFI shell.

I> Current Boot-Chain Slot: 0
I> BR-BCT Boot-Chain is 0, and status is 1. Set UPDATE_BRBCT bit to 0
I> Task: Burn RESERVED_ODM0 fuse
I> Task: Lock fusing
I> Task: Clear dec source key
I> MB2 finished

��NOTICE: BL31: v2.8(release):e12e3fa93
NOTICE: BL31: Built : 09:56:21, May 6 2024
I/TC:
I/TC: Non-secure external DT found
I/TC: OP-TEE version: 3.22 (gcc version 11.3.0 (Buildroot 2022.08)) #2 Mon May 6 17:07:49 UTC 2024 4
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.hl
I/TC: Primary CPU initializing
I/TC: Test OEM keys are being used. This is insecure for shipping products!
E/TC:00 00 ekb_extraction_process:216 Bad parameter: eks image not correct
E/TC:00 00 jetson_user_key_pta_init:1049 jetson_user_key_pta_init: Failed (ffff0006).
E/TC:00 00 call_initcalls:43 Initcall __text_start + 0x0016f250 failed
I/TC: Primary CPU switching to normal world boot
��
Jetson UEFI firmware (version 36.3.0-gcid-36191598 built on 2024-05-06T16:58:59+00:00)

��I/TC: Reserved shared memory is disabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
I/TC: WARNING: Test UEFI variable auth key is being used !
I/TC: WARNING: UEFI variable protection is not fully enabled !
��
Jetson System firmware version 36.3.0-gcid-36191598 date 2024-05-06T16:58:59+00:
00
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
…
��I/TC: Reserved shared memory is disabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
E/TA: is_user_key_exists:65 TEE_InvokeTACommand failed with res = 0xffff0001
��L4TLauncher: Attempting Recovery Boot
Android image header not seen
Failed to boot recovery:0 partition

2

FYI I edited my original post to add the error I get when booting after flashing with --uefi-enc

4

hello jeanphilippe.arnaud,

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.

may I double confirm your environment setup.
for instance, here’re bootloader SecureBoot and UEFI SecureBoot. did you have only UEFI secureboot enabled?

besides,
what’s your steps to update EKS image? could you please share your command-line for reference?

5

Hello Jerry,

I have only enabled UEFI Secureboot. Secureboot at the bootloader level is currently disabled (no fuse burnt).

I downloaded the source code package nvidia-jetson-optee-source and am using optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh from within.

Here is the script I run. I modified the value for sym_t234.key and sym2_t234.key as the original example used 128 bit keys which are too short for the AGX. Aside from this the script is the same.

# [T234 JPA]
echo "432646294a404e635266556a586e3272357538782f413f442a472d4b61506453" > oem_k2.key

# This is the default initial vector for EKB.
echo "bad66eb4484983684b992fe54a648bb8" > fv_ekb_t234

# Generate user-defined symmetric key files
# openssl rand -rand /dev/urandom -hex 16 > sym_t234.key
# openssl rand -rand /dev/urandom -hex 16 > sym2_t234.key
echo "010203040506070809a0b0c0d0e0f001010203040506070809a0b0c0d0e0f001" > sym_t234.key
echo "010203040506070809a0b0c0d0e0010203040506070809a0b0c0d0e0f001f001" > sym2_t234.key

python3 gen_ekb.py -chip t234 -oem_k2_key oem_k2.key \
        -fv fv_ekb_t234 \
        -in_sym_key sym_t234.key \
        -in_sym_key2 sym2_t234.key \
        -out eks_t234.img
6

BTW, could you please check below documentation for UEFI Secureboot overall flow.
for instance, $OUT/Linux_for_Tegra/tools/README_uefi_secureboot.txt

7

Hi Jerry,
My apologies for wasting your time, I made a mistake and used the OEM_K2 from a previous Jetpack release. Jetpack 36.3 uses all 0s for the test value.

So, correcting the script to the following, creates an EKS that is loaded by the optee_os.

# [T234 JPA]
# Fill your OEM_K1 fuse key value
echo "0000000000000000000000000000000000000000000000000000000000000000" > oem_k1.key

# Generate user-defined symmetric key files
# A random generate key is recommended for production, and a specified key is recommended for testing
# For each key, there are reference examples for generating random key and specifying keys.
# openssl rand -rand /dev/urandom -hex 32 > sym_t234.key    # kernel/kernel-dtb encryption key
echo "0000000000000000000000000000000000000000000000000000000000000000" > sym_t234.key
# openssl rand -rand /dev/urandom -hex 16 > sym2_t234.key   # disk encryption key
echo "00000000000000000000000000000000" > sym2_t234.key
# openssl rand -rand /dev/urandom -hex 16 > auth_t234.key   # uefi variables authentication key
echo "00000000000000000000000000000000" > auth_t234.key

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 \
        -out eks_t234.img
8

hello jeanphilippe.arnaud,

thanks for status update,
just double confirm, you’re able to run with UEFI secureboot enabled after EKS image update, right?

are we able to close this discussion thread?

9

Hello Jerry,
Yes, the ticket can be closed. I am able to use UEFI payloads signing and encryption.

11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.