Enabling disk encryption on Jetson Orin NX

I am trying to enable Disk Encryption for a Jetson Orin NX. I’m using the Hadron Carrier for NVIDIA® Jetson Orin™ NX, but I am not able to make it work.

I read the manual and followed all the instructions from this post

This is my series of commands that I use based on the above post, with the only difference being the target board is cti/orin-nx/hadron/base which is defined by the CTI BSP.

# Generate the keys
cd gen_ekb/
./example.sh

# Copy the keys into Linux_for_tegra
cd ../Linux_for_Tegra
cp ../gen_ekb/sym2_t234.key ./sym2_t234.key
rm ./bootloader/eks_t234.img
cp ../gen_ekb/eks_t234.img ./bootloader/eks_t234.img

# Generate a new sign/encrypt file (`eks_t234_sigheader.img.encrypt`)
sudo ./flash.sh --no-flash -k A_eks -i "sym2_t234.key" cti/orin-nx/hadron/base nvme0n1p1

# Generate images for QSPI
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --no-flash --network usb0 cti/orin-nx/hadron/base internal

# Generate images for external storage device
sudo cp ./bootloader/eks_t234_sigheader.img.encrypt ./tools/kernel_flash/images/internal/eks_t234_sigheader.img.encrypt
sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --no-flash --external-device nvme0n1p1 -i ./sym2_t234.key -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml --external-only --append --network usb0 cti/orin-nx/hadron/base external

# Flash the encrypted EKS
sudo ./tools/kernel_flash/l4t_initrd_flash.sh -k A_eks --flash-only --showlogs

# Flash all images into the both storage devices
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 --showlogs --flash-only

The error I’m getting is

[   11.788709] ERROR: fail to unlock the encrypted dev /dev/nvme0n1p2.
[   11.790912] Kernel panic - not syncing:
[   11.790916] Attempted to kill init! exitcode=0x00007f00
[   11.790920] CPU: 3 PID: 1 Comm: bash Not tainted 5.15.136-tegra #45
[   11.790924] Hardware name: NVIDIA CTI Hadron + Orin NX/Jetson, BIOS 36.3.0-gcid-36106755 04/25/2024
[   11.790926] Call trace:
[   11.790927]  dump_backtrace+0x0/0x1c0
[   11.790940]  show_stack+0x34/0x50
[   11.790943]  dump_stack_lvl+0x68/0x84
[   11.790950]  dump_stack+0x18/0x34
[   11.790953]  panic+0xc4/0x398
[   11.790955]  do_exit+0xa1c/0xa50
[   11.790960]  do_group_exit+0x44/0xb0
[   11.790962]  __arm64_sys_exit_group+0x2c/0x30
[   11.790964]  invoke_syscall+0x5c/0x130
[   11.790968]  el0_svc_common.constprop.0+0x64/0x110
[   11.790970]  do_el0_svc+0x74/0xa0
[   11.790973]  el0_svc+0x28/0x80
[   11.790975]  el0t_64_sync_handler+0xa4/0x130
[   11.790976]  el0t_64_sync+0x1a4/0x1a8

Also attached are the flash log and the serial log.

Any idea what I’m missing?

flash.log (435.2 KB)
serial.log (296.1 KB)

hello chinmaypen,

above failure usually caused by an incorrect EKS image had applied.

you may refer to jetson-linux-archive, please double check you’re using the same public release version.
please review the steps as mentioned by example.sh to re-generate EKS image,
for instance, $public_sources/r36.4.0/Linux_for_Tegra/source/atf_and_optee/optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh
please check you’ve update EKS image, eks_t234.img accordingly. you may see-also Topic 270934 for steps to update EKS image.

Thanks @JerryChang for your help.

I am definitely using the same public release version for all the 3.

BSP_URL=https://developer.nvidia.com/downloads/embedded/l4t/r36_release_v3.0/release/jetson_linux_r36.3.0_aarch64.tbz2
ROOT_FS_URL=https://developer.nvidia.com/downloads/embedded/l4t/r36_release_v3.0/release/tegra_linux_sample-root-filesystem_r36.3.0_aarch64.tbz2
SOURCES_URL=https://developer.nvidia.com/downloads/embedded/l4t/r36_release_v3.0/sources/public_sources.tbz2

I have gone through and updated my example.sh to use openssl to generate random keys. I only ran it once and am reusing the .key and .img files for all my attempts.

#!/bin/bash

# [T234 example]
# Fill your OEM_K1 fuse key value
openssl rand -rand /dev/urandom -hex 32 > oem_k1.key
# 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

Just to confirm that my EKS image is fine.

> hexdump -C -n 4 -s 0x24 eks_t234.img
00000024  45 45 4b 42                                       |EEKB|

hello chinmaypen,

did you fuse your target? please use the same key as you’ve burn OEM_K1.

Oh! I didn’t realize that it’s a separate operation. Thanks for pointing that out.

I am struggling to find documentation about how to fuse the Jeston Orin. This document refers to a Using the Fuse Burning Toolkit for T234. I can’t find the document.

Is odmfuse.sh still the tool to use? Is the only fuse needed for just Disk Encryption (no need secure boot) OEM_K1?

hello chinmaypen,

you may enable disk encryption without SecureBoot (i.e. fuse burning).
please aware that, fuse burning operations are high-risk because they cannot be reversed.

so,
please refer to example.sh and updating only the keys you’ve applied to re-generate EKS image.

OK. Thanks @JerryChang ! I think I understand now.

I can run a Jetson Orin with Disk Encryption enabled in two ways.

  1. Fuse the board (and enable secure boot), then use the oem_k1.key used for fusing in example.sh and a custom sym2_t234.key to create a eks_t234.img and flash it using the steps above.

OR

  1. Don’t fuse the board (no secure boot), and use the default oem_k1.key ( 000... ) and a custom sym2_t234.key to create a eks_t234.img and flash it using the steps above.

Am I right?

that’s correct, and it’s suggest to test with approach-2 (don’t fuse the board) first.

1 Like

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