Xavier nx buring fuses with JP-5.1.5/r35.6.2

Hi, I have burnt fuses on my xavier nx following the instructions on Secureboot page.
After flashing with command : sudo ./odmfuse.sh -X <fuse_config> -i <chip_id> <target_config>

My config file looked something like this :

After fusing the device, I try to flash with the command :
sudo ./flash.sh -u <pkc_keyfile> -v <sbk_keyfile> jetson-xavier-nx-devkit mmcblk0p1

Command fails with the error :

Name: jetson-xavier-nx-devkit-emmc, Board Family: t186ref, SoC: Tegra 194,

OpMode: production, Boot Authentication: NS,Disk encryption: enabled ,###############################################################################
Error: either RSA key file and/or SBK key file are provided for none SBK and PKC protected target board.

The device is in Non secure mode and I cannot flash. If I flash without the keys, the image will not boot.
I have another device on which I’ve ran ./odmfuse.sh with –test and –noburn without using fuse config xml file and a generated config file seems to be similar. (sudo ./odmfuse.sh --test --noburn -p -k “pkc.pem” -S “sbk.key” --KEK2 “kek2.key” -i 0x19 jetson-xavier-nx-devkit-emmc)

Generated odfuse_pkc.xml :

What is the correct way to run odmfuse.sh to fuse xavier nx device to enable Secureboot and PKCSBK mode?

Hello,

Thanks for visiting the NVIDIA Developer Forums.
To ensure better visibility and support, I’ve moved your post to the Jetson category where it’s more appropriate

Cheers,
Tom

Missing xml config files :

initial_fuse_config.txt (2.1 KB)

generated_fuse_config_from_test.txt (390 Bytes)

hello mwesigwa.guma,

just for confirmation, which is the fuse_config you’re used to run odmfuse script?

used for burning :

initial_fuse_config.txt (2.1 KB)

Generated from test run :

generated_fuse_config_from_test.txt (440 Bytes)

hello mwesigwa.guma,

let’s give it another try by running flash script for check fuse variables.
$ sudo ./flash.sh --read-info -u <pkc> -v <sbk> <target_conf> <rootdev>

I’m afraid you’ve brick this device..
according to fuse xml file, it looks you did not burn BootSecurityInfo. please refer to Jetson Xavier NX Fuse Specification Application Note for the details of FUSE_BOOT_SECURITY_INFO.
besides.. after the SecurityMode fuse is burned with a value of 0x1, all additional fuse write requests will be blocked.

BTW,
JetPack-6 public release support Orin series only.
please works with Jetpack-5 (i.e. JetPack 5.1.5) if you’re using Xavier NX.

running sudo ./flash.sh --read-info -u <pkc> -v <sbk> <target_conf> <rootdev> results in the same error :
Error: either RSA key file and/or SBK key file are provided for none SBK and PKC protected target board.

After fusing with the command sudo ./odmfuse.sh -p -k <rsa.pem> -S <sbk.key> --KEK2 <kek2.key> -i 0x19 jetson-xavier-nx-devkit-emmcon a different device, I was able to flash the device successfully and boot with SecureBoot enabled.

However, when I enable payload signing at flashing time it does not work. Initrd authentication fails :

/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007 ��OpenAndReadFileToBuffer: \boot\initrd failed signature verification: Security Vi olation ExtLinuxBoot:sds Failed to Authenticate \boot\initrd (Security Violation) L4TLauncher: Unable to boot via extlinux: Security Violation L4TLauncher: Attempting Kernel Boot

after generating uefi keys and conf file, I run the following commands :

python3 sources/tegra/optee-src/nv-optee/optee/samples/hwkey-agent/host/tool/gen_ekb/gen_ekb.py
-chip t194 -kek2_key keys_v2/kek2.key
-fv keys_v2/fv_for_ekb_ek.key
-in_sym_key keys_v2/user_encryption.key
-in_sym_key2 keys_v2/disk_encrption.key
-in_auth_key keys_v2/user_authentication.key
-out eks_t194.img

sudo cp eks_t194.img bootloader/eks_t194.img

sudo ADDITIONAL_DTB_OVERLAY=“BootOrderEmmc.dtbo” ./flash.sh -u keys_v2/rsa_priv.pem -v keys_v2/sbk.key
–uefi-keys uefi_keys_v2/uefi_keys.conf
–uefi-enc keys_v2/user_encryption.key
jetson-xavier-nx-devkit-emmc mmcblk0p1

What could I be doing wrong here ?

Also jetpack I am using is JetPack 5.1.5 SDK

hello mwesigwa.guma,

please help me to understand the status..
you’re now able to fuse/flash Xavier NX to enable bootloader secureboot on the other device.
it’s the follow-up issue regrading to UEFI secureboot, please narrow down to check it’s due to signed UEFI payloads (--uefi-keys) or, UEFI payload encryption (--uefi-enc).

The problem is the UEFI payload encryption (-- uefi-enc), when I flash with this option, I see the error above (\boot\initrd failed signature verification: Security Violation…)

Actually both –uefi-keys and –uefi-enc are failing with the same error. The only command that flashes and boots an image is : sudo ADDITIONAL_DTB_OVERLAY=“BootOrderEmmc.dtbo” ./flash.sh
-u keys_v2/rsa_priv.pem -v keys_v2/sbk.key
jetson-xavier-nx-devkit-emmc mmcblk0p1

Not working : –uefi-keys and –uefi-enc
Working : regular flash with only -u and -v options

these are the steps I took

sudo ./odmfuse.sh -p -k “$DIR/$RSA_PRIV_KEY” -S “$DIR/$SBK_KEY” --KEK2 “$DIR/$KEK2_KEY” -i 0x19 jetson-xavier-nx-devkit-emmc

mkdir -p uefi_keys
sudo rm -rf uefi_keys/*
cd uefi_keys

Generate PK RSA keypair and certificate

openssl req -newkey rsa:2048 -nodes -keyout PK.key -new -x509 -sha256 -days 3650 -subj “/CN=my Platform Key/” -out PK.crt

Generate KEK RSA keypair and certificate

openssl req -newkey rsa:2048 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj “/CN=my Key Exchange Key/” -out KEK.crt

Generate db_1 RSA keypair and certificate

openssl req -newkey rsa:2048 -nodes -keyout db_1.key -new -x509 -sha256 -days 3650 -subj “/CN=my Signature Database key/” -out db_1.crt

Generate db_2 RSA keypair and certificate (Optional)

openssl req -newkey rsa:2048 -nodes -keyout db_2.key -new -x509 -sha256 -days 3650 -subj “/CN=my another Signature Database key/” -out db_2.crt

create a UEFI keys config File

create_uefi_keys_conf → functio in my script that creates uefi_keys.conf file and fills it with configs for the above generated files

cd ..

generate uefi_default_security_keys.dtbo

sudo ./tools/gen_uefi_default_keys_dts.sh uefi_keys/uefi_keys.conf
sudo chmod 644 uefi_keys/_out/
sudo chmod 644 uefi_keys/_out/*.auth
sudo cp uefi_keys/UefiDefaultSecurityKeys.dtbo bootloader/

python3 sources/tegra/optee-src/nv-optee/optee/samples/hwkey-agent/host/tool/gen_ekb/gen_ekb.py
-chip t194 -kek2_key keys_v2/kek2.key
-fv keys_v2/fv_for_ekb_ek.key
-in_sym_key keys_v2/user_encryption.key
-in_sym_key2 keys_v2/disk_encrption.key
-in_auth_key keys_v2/user_authentication.key
-out eks_t194.img

sudo cp eks_t194.img bootloader/eks_t194.img

simple flash works successfully

sudo ADDITIONAL_DTB_OVERLAY=“BootOrderEmmc.dtbo” ./flash.sh
-u keys_v2/rsa_priv.pem -v keys_v2/sbk.key
jetson-xavier-nx-devkit-emmc mmcblk0p1

not working yet

sudo ADDITIONAL_DTB_OVERLAY=“BootOrderEmmc.dtbo” ./flash.sh
-u keys_v2/rsa_priv.pem -v keys_v2/sbk.key
–uefi-keys uefi_keys/uefi_keys.conf
jetson-xavier-nx-devkit-emmc mmcblk0p1

sudo ADDITIONAL_DTB_OVERLAY=“BootOrderEmmc.dtbo” ./flash.sh
-u keys_v2/rsa_priv.pem -v keys_v2/sbk.key
–uefi-keys uefi_keys/uefi_keys.conf
–uefi-enc keys_v2/user_encryption.key
jetson-xavier-nx-devkit-emmc mmcblk0p1

hello mwesigwa.guma,

we’ve confirmed UEFI secureboot + UEFI payload encryption on r35.6.2 + fused Xavier-NX is working.

BTW, since you’re based JP-5.1.5/r35.6.2/Xavier NX.
did you also generate the eks_t194.img and sym_t194.key from the same r35.6.2 source release, and then copy it to the BSP folder?

After switching to r35.6.2, UEFI secureboot + UEFI payload encryption on fused Xavier-NX worked and I was able to fully boot and run OS.
However, I am facing the same issue after updating fv_for_ekb and building the TOS.
Here are the steps I followed from ../atf_and_optee_README.txt:

export CROSS_COMPILE_AARCH64_PATH=$DIR/Linux_for_Tegra/l4t-gcc
export CROSS_COMPILE_AARCH64=$DIR/Linux_for_Tegra/l4t-gcc/bin/aarch64-buildroot-linux-gnu-
export UEFI_STMM_PATH=$DIR/Linux_for_Tegra/bootloader/standalonemm_optee_t194.bin

./sources/tegra/optee-src/nv-optee/optee_src_build.sh -p t194

sudo dtc -I dts -O dtb -o sources/tegra/optee-src/nv-optee/optee/tegra194-optee.dtb sources/tegra/optee-src/nv-optee/optee/tegra194-optee.dts

cd “$SCRIPT_DIR/../src/Linux_for_Tegra/sources/tegra/optee-src/atf/arm-trusted-firmware”

sudo make BUILD_BASE=./build
CROSS_COMPILE=“${CROSS_COMPILE_AARCH64}”
DEBUG=0 LOG_LEVEL=20 PLAT=tegra SPD=opteed TARGET_SOC=t194 V=0

cd “$SCRIPT_DIR/../src/Linux_for_Tegra”

sudo ./nv_tegra/tos-scripts/gen_tos_part_img.py
–monitor sources/tegra/optee-src/atf/arm-trusted-firmware/build/tegra/t194/release/bl31.bin
–os sources/tegra/optee-src/nv-optee/optee/build/t194/core/tee-raw.bin
–dtb sources/tegra/optee-src/nv-optee/optee/tegra194-optee.dtb
–tostype optee tos-optee_t194.img

sudo cp tos-optee_t194.img bootloader/tos-optee_t194.img

generate uefi_default_security_keys.dtbo

sudo ./tools/gen_uefi_default_keys_dts.sh “$SCRIPT_DIR/$UEFI_KEYS_DIR/uefi_keys.conf”
sudo cp “$SCRIPT_DIR/$UEFI_KEYS_DIR/UefiDefaultSecurityKeys.dtbo” bootloader/

generate eks_t194.img

python3 sources/tegra/optee-src/nv-optee/optee/samples/hwkey-agent/host/tool/gen_ekb/gen_ekb.py
-chip t194 -kek2_key “$SCRIPT_DIR/$KEYS_DIR/kek2.key”
-fv “$SCRIPT_DIR/$KEYS_DIR/fv_for_ekb_ek.key”
-in_sym_key “$SCRIPT_DIR/$KEYS_DIR/user_encryption.key”
-in_sym_key2 “$SCRIPT_DIR/$KEYS_DIR/disk_encryption.key”
-in_auth_key “$SCRIPT_DIR/$KEYS_DIR/user_authentication.key”
-out eks_t194.img

sudo cp eks_t194.img bootloader/eks_t194.img

sudo ADDITIONAL_DTB_OVERLAY=“BootOrderEmmc.dtbo” ./flash.sh
-u “$SCRIPT_DIR/$KEYS_DIR/rsa_priv.pem” -v “$SCRIPT_DIR/$KEYS_DIR/sbk.key”
–uefi-keys “$SCRIPT_DIR/$UEFI_KEYS_DIR/uefi_keys.conf”
–uefi-enc “$SCRIPT_DIR/$KEYS_DIR/user_encryption.key”
jetson-xavier-nx-devkit-emmc mmcblk0p1

Signed payloads authentication is failing again just like before with the same errors. Please point me in the right direction

hello mwesigwa.guma,

got it, thanks for confirmation.

as you can see..
here’s Random fixed vector, which MUST match the ‘fv’ vector used for EKB binary.
$public_sources/r35.6.x/Linux_for_Tegra/source/public/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,

besides update op-tee binaries, you should also update tos.img for using customize FVs.
you may see-also Topic 263994 for reference.

I don’t believe the problem is the fv_for_ekb as I have double checked this several times. I am also updating tos.img and replacing the one in bootloader/tos_t194.imgpath after going through the shared thread above. The boot process fails during an attempt to decrypt payload images. If the fv_for_ekb is incorrect it will usually fail before that. I assume there’s something i’m missing with the way I am generating the tos.img. Here are part of the logs:

etson UEFI firmware (version 6.2-40633251 built on 2025-05-16T01:35:20+00:00)
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
** WARNING: Test Key is used. **

��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
��L4TLauncher: Attempting Direct Boot
��E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0006
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
��OpenAndReadFileToBuffer: \boot\initrd failed signature verification: Security Vi
olation
ExtLinuxBoot:sds Failed to Authenticate \boot\initrd (Security Violation)
L4TLauncher: Unable to boot via extlinux: Security Violation
L4TLauncher: Attempting Kernel Boot
��E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0006
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
E/TA: decrypt_image:99 TEE_InvokeTACommand failed with res = 0xffff0007
��ReadEncryptedImage: Failed to read data from partition
OpteeDecryptImage: Failed to read data
ReadAndroidStyleKernelPartition: OpteeDecryptImage failed
Failed to boot kernel:0 p���

Are you able to update the tos.img and get the OS to successfully boot with the same jetpack? If so please share your steps as I can’t figure out what the problem is

hello mwesigwa.guma,

FYI, there’re secure-os, (tos-optee_t194_sigheader.img.encrypt) and eks (eks_t194_sigheader.img.encrypt) partitions they’re related to OP-TEE. did you update these two?

No I did not, where can I find instructions to update those files/partitions ?

hello mwesigwa.guma,

please refer to atf_and_optee_README.txt from public release sources.
you may check [Verifying the Image] for the steps.

Found the following error in the flashing logs :

[ 0.0246 ] WARNING: Can’t create EVPKey object from ECKey object
[ 0.0258 ] ERROR: Can’t create EVPKey object from EDKey object [ 0.0266 ] ERROR: ../security_tools/dev_keys/user_encryption.key is not valid ed25519 key in Open SSL format
[ 0.0266 ] ERROR: Can not extract key from ../security_tools/dev_keys/user_encryption.key
[ 0.0266 ] Invalid key format [ 0.0266 ] ********* Error. Quitting. *********

It turns out using oppenssl rand -rand /dev/urandom -hex 16 > user_encyption.key which is what is recommended in example.sh causes the error above. I switched to using oppenssl rand -hex 16 > user_encyption.key and the payloads are signed correctly. I am able to boot the OS now on both r35.6.1 and r35.6.2.

Thank you for your help @JerryChang