Need help for flashing Secure boot and Disk Encryption for Jetson Orin NX 16GB

Greetings all, I have been facing an issue which I can’t seem to overcome:

Brief description of issue: Tried to enable secure boot and disk encryption of Jetson Orin NX 16GB. Managed to perform the flash using l4t_initrd_flash.sh but ended up getting the error “No key available with this passphrase” and “Kernel panic - not syncing” (see attached image at the bottom).

Configuration:

JETPACK_VERSION=“36.4.0”
BOARD_CONFIG=“jetson-orin-nano-devkit”
STORAGE_DEVICE=“nvme0n1p1”
DISK_SIZE_GIB=400
NUM_SECTORS=$(( DISK_SIZE_GIB * 1024 * 1024 * 1024 / 512 ))
DISK_SIZE=“${DISK_SIZE_GIB}GiB”
L4T_DIR=“Linux_for_Tegra”

Host version: Ubuntu 22.04 (and Ubuntu 20.04 Docker)
Carrier board: Default Jetson Orin Nano Developer Kit
Module: Jetson Orin NX 16GB-DRAM (Production)

Steps followed:
Extract files and setup

tar xvf Jetson_Linux_R36.4.0_aarch64.tbz2
sudo tar xvf Tegra_Linux_Sample-Root-Filesystem_R36.4.0_aarch64.tbz2 -C Linux_for_Tegra/rootfs/
tar xvf public_sources.tbz2
cd Linux_for_Tegra/source
tar xvf nvidia-jetson-optee-source.tbz2
cd ../
sudo ./tools/l4t_flash_prerequisites.sh
sudo ./apply_binaries.sh

Generate Keys

# RSA    
openssl genrsa -out rsa.pem 3072
    PKCS_KEY_XML_HASH=$(./bootloader/tegrasign_v3.py --pubkeyhash rsa.pubkey rsa.hash --key rsa.pem | grep "tegra-fuse format" | awk '{print $NF}')
    
# SBK
    SBK_0=$(openssl rand -hex 4)
    SBK_1=$(openssl rand -hex 4)
    SBK_2=$(openssl rand -hex 4)
    SBK_3=$(openssl rand -hex 4)
    SBK_4=$(openssl rand -hex 4)
    SBK_5=$(openssl rand -hex 4)
    SBK_6=$(openssl rand -hex 4)
    SBK_7=$(openssl rand -hex 4)
    SBK_KEY=$(echo "0x${SBK_0} 0x${SBK_1} 0x${SBK_2} 0x${SBK_3} 0x${SBK_4} 0x${SBK_5} 0x${SBK_6} 0x${SBK_7}")
    echo "${SBK_KEY}" > sbk.key
    SBK_KEY_XML="0x${SBK_0}${SBK_1}${SBK_2}${SBK_3}${SBK_4}${SBK_5}${SBK_6}${SBK_7}"
    echo "${SBK_KEY_XML}" > sbk_xml.key

# KEK    
    KEK_2_0=$(openssl rand -hex 4)
    KEK_2_1=$(openssl rand -hex 4)
    KEK_2_2=$(openssl rand -hex 4)
    KEK_2_3=$(openssl rand -hex 4)
    KEK_2_4=$(openssl rand -hex 4)
    KEK_2_5=$(openssl rand -hex 4)
    KEK_2_6=$(openssl rand -hex 4)
    KEK_2_7=$(openssl rand -hex 4)
    KEK_2_KEY=$(echo "0x${KEK_2_0} 0x${KEK_2_1} 0x${KEK_2_2} 0x${KEK_2_3} 0x${KEK_2_4} 0x${KEK_2_5} 0x${KEK_2_6} 0x${KEK_2_7}")
    echo "${KEK_2_KEY}" > kek.key
    KEK_2_KEY_XML="0x${KEK_2_0}${KEK_2_1}${KEK_2_2}${KEK_2_3}${KEK_2_4}${KEK_2_5}${KEK_2_6}${KEK_2_7}"
    echo "${KEK_2_KEY_XML}" > kek_xml.key
    KEK_2_KEY_OPTEE="${KEK_2_0}${KEK_2_1}${KEK_2_2}${KEK_2_3}${KEK_2_4}${KEK_2_5}${KEK_2_6}${KEK_2_7}"
    echo "${KEK_2_KEY_OPTEE}" > kek_optee.key
    
# symmetric encryption keys
    openssl rand -rand /dev/urandom -hex 32 > sym_t234.key
    openssl rand -rand /dev/urandom -hex 16 > sym2_t234.key
    openssl rand -rand /dev/urandom -hex 16 > auth_t234.key

# UEFI, 
    mkdir -p uefi_keys
    cd uefi_keys
    
    GUID=$(uuidgen)
    
# PK
    openssl req -newkey rsa:2048 -nodes -keyout PK.key -new -x509 -sha256 -days 3650 \
        -subj "/CN=my Platform Key/" -out PK.crt
    cert-to-efi-sig-list -g "${GUID}" PK.crt PK.esl
    
# KEK
    openssl req -newkey rsa:2048 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 \
        -subj "/CN=my Key Exchange Key/" -out KEK.crt
    cert-to-efi-sig-list -g "${GUID}" KEK.crt KEK.esl
    
# db_1
    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
    cert-to-efi-sig-list -g "${GUID}" db_1.crt db_1.esl
    
# db_2
    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
    cert-to-efi-sig-list -g "${GUID}" db_2.crt db_2.esl
    
# UEFI keys config
    cat > uefi_keys.conf <<EOF
UEFI_DB_1_KEY_FILE="db_1.key";
UEFI_DB_1_CERT_FILE="db_1.crt";
UEFI_DEFAULT_PK_ESL="PK.esl"
UEFI_DEFAULT_KEK_ESL_0="KEK.esl"
UEFI_DEFAULT_DB_ESL_0="db_1.esl"
UEFI_DEFAULT_DB_ESL_1="db_2.esl"
EOF
    
    cd ..
    
    sudo tools/gen_uefi_keys_dts.sh uefi_keys/uefi_keys.conf

Generate OP-TEE image

    python3 ./source/optee/samples/hwkey-agent/host/tool/gen_ekb/gen_ekb.py \
        -chip t234 \
        -oem_k1_key kek_optee.key \
        -in_sym_key sym_t234.key \
        -in_sym_key2 sym2_t234.key \
        -in_auth_key auth_t234.key \
        -out bootloader/eks_t234.img

Create fuse config

# read SBK and KEK if not in memory
    if [ -z "$PKCS_KEY_XML_HASH" ]; then
        PKCS_KEY_XML_HASH=$(./bootloader/tegrasign_v3.py --pubkeyhash rsa.pubkey rsa.hash --key rsa.pem | grep "tegra-fuse format" | awk '{print $NF}')
    fi
    
    # read SBK and KEK if not in memory
    if [ -z "$SBK_KEY_XML" ]; then
        SBK_KEY_XML=$(cat sbk_xml.key)
    fi
    if [ -z "$KEK_2_KEY_XML" ]; then
        KEK_2_KEY_XML=$(cat kek_xml.key)
    fi
    
    cat > fuse.xml <<EOF
<genericfuse MagicId="0x45535546" version="1.0.0">
  <fuse name="PublicKeyHash" size="64" value="${PKCS_KEY_XML_HASH}"/>
  <fuse name="SecureBootKey" size="32" value="${SBK_KEY_XML}"/>
  <fuse name="OemK1" size="32" value="${KEK_2_KEY_XML}"/>
  <fuse name="BootSecurityInfo" size="4" value="0x209"/>
  <fuse name="SecurityMode" size="4" value="0x1"/>
</genericfuse>
EOF

Burn fuse

    sudo ./odmfuse.sh -i 0x23 -k rsa.pem -S sbk.key -X fuse.xml "$BOARD_CONFIG"

Setup qspi

    sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
         --uefi-keys uefi_keys/uefi_keys.conf \
         --network usb0 \
         --no-flash \
         --showlogs \
         -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
         "$BOARD_CONFIG" internal > qspi_flash.log 2>&1

Setup rootfs

# update NUM_SECTORS in flash config
    FLASH_CONFIG="./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml"
    sed -i "s/EXT_NUM_SECTORS/${NUM_SECTORS}/g" "$FLASH_CONFIG"

# setup encrypted rootfs
    sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh \
        --uefi-keys uefi_keys/uefi_keys.conf \
        -i ./sym2_t234.key \
        --external-device nvme0n1p1 \
        -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml \
        --showlogs \
        --no-flash \
        --external-only \
        --append \
        --network usb0 \
        "$BOARD_CONFIG" \
        external > rootfs_flash.log 2>&1

Flash board

    sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
        --showlogs \
        -u rsa.pem \
        -v sbk.key \
        -i sym2_t234.key \
        --uefi-keys uefi_keys/uefi_keys.conf \
        --network usb0 \
        --flash-only > flash_device.log 2>&1

The flash was successful.

Logs and errors:

qspi_flash.log (206.8 KB)

rootfs_flash.log (175.8 KB)

flash_device.log (75.8 KB)

I’ve been stuck at these setup steps for a long time. Would appreciate the help!

hello ntyy,

there’s logs about fail to unlock the encrypted partition. it usually caused by incorrect EKS image.
let’s check it’s related to disk encryption, could you please re-flash a board without ROOTFS_ENC=1 for confirmation.

hey JerryChang,

thanks a lot for the response. do you mean that the oem_k1_key used to create the eks image using gen_ekb.py does not match the OemK1 config used to burn the fuse in fuse.xml?

alright, I removed the ROOTFS_ENC=1 flag in the step of setting up the encrypted rootfs, and then ran the following commands

# setup rootfs
    sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
        --uefi-keys uefi_keys/uefi_keys.conf \
        -i ./sym2_t234.key \
        --external-device nvme0n1p1 \
        -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml \
        --showlogs \
        --no-flash \
        --external-only \
        --append \
        --network usb0 \
        "$BOARD_CONFIG" \
        external > rootfs_flash_no_rootfsEncFlag.log 2>&1

# flash
    sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
        --showlogs \
        -u rsa.pem \
        -v sbk.key \
        -i sym2_t234.key \
        --uefi-keys uefi_keys/uefi_keys.conf \
        --network usb0 \
        --flash-only > flash_device_without_rootfsEncFlag.log 2>&1

The flashing step failed. Here are the new logs:

rootfs_flash_no_rootfsEncFlag.log (174.6 KB)

flash_device_without_rootfsEncFlag.log (9.1 KB)

hello ntyy,

ahh.. you should use the flash configuration file without rootfs_enc, also, please remove -i sym2_t234.key for using default key.
here’s sample flash commands,
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --showlogs --network usb0 jetson-orin-nano-devkit internal

hey JerryChang,

Noted! okay I used the following commands to setup secureboot. This is using the original approach of setting up the qspi and rootfs before flashing:

# setup qspi 
    sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
         --uefi-keys uefi_keys/uefi_keys.conf \
         --network usb0 \
         --no-flash \
         --showlogs \
         -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
         "$BOARD_CONFIG" internal > qspi_flash.log 2>&1

# setup rootfs (no ROOTFS_ENC=1, no -i flag, changed flash config file)
    sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
        --uefi-keys uefi_keys/uefi_keys.conf \
        --external-device nvme0n1p1 \
        -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml \
        --showlogs \
        --no-flash \
        --external-only \
        --append \
        --network usb0 \
        "$BOARD_CONFIG" \
        external > rootfs_setup_no_rootfsEncFlag.log 2>&1

# flash (no -i flag)
    sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
        --showlogs \
        -u rsa.pem \
        -v sbk.key \
        --uefi-keys uefi_keys/uefi_keys.conf \
        --network usb0 \
        --flash-only > flash_device_without_rootfsEncFlag.log 2>&1

All the steps here were successful! Managed to boot up the device and the command mokutil –sb-state returned SecureBoot enabled.

may I know how to proceed with the disk encryption?

Would it be that the arguments for generating the eks_t234.img in this command is wrong?

hello ntyy,

thanks for confirmation, so that’s an issue with incorrect EKS image.

please see-also Topic 256705 for reference.

Hi JerryChang,

Thank you for the response. I am still facing the same error after doing the steps shown below. I checked the eks image using hexdump -C Linux_for_Tegra/bootloader/eks_t234.img and got the following:

00000000  00 04 00 00 4e 56 45 4b  42 50 00 00 02 00 00 00  |....NVEKBP......|
00000010  4a b8 f0 90 c4 88 a9 c1  47 2b 40 41 f0 ec d5 d6  |J.......G+@A....|
00000020  ef 58 72 35 99 20 be fe  9a 3d 29 a5 ba a8 9d 95  |.Xr5. ...=).....|
00000030  60 00 00 00 45 45 4b 42  00 00 00 00 00 00 00 00  |`...EEKB........|
00000040  b9 06 7d 4e 4a 51 8c eb  69 01 6d 2c 30 a3 52 a7  |..}NJQ..i.m,0.R.|
00000050  0d 3e 66 ef 66 2f 86 fd  7a 68 f9 d8 28 76 3c 03  |.>f.f/..zh..(v<.|
00000060  23 e9 09 36 1c 01 30 dc  a6 2a 71 e0 75 3b 00 12  |#..6..0..*q.u;..|
00000070  ff e1 6f 4a 67 88 1d 0c  23 9c ef 1f f4 e7 00 4c  |..oJg...#......L|
00000080  0f 9e c2 9b 28 0a 87 d0  05 4f d4 a8 16 c7 54 c9  |....(....O....T.|
00000090  94 b7 db 1d 72 ac 6d 59  5f 8d c6 00 cf 4c b9 45  |....r.mY_....L.E|
000000a0  8a 30 a2 c1 2b 48 7b 26  78 4c 0c 7d 03 5e ab 38  |.0..+H{&xL.}.^.8|
000000b0  54 54 54 54 54 54 54 54  54 54 54 54 54 54 54 54  |TTTTTTTTTTTTTTTT|
*
00000400  54 54 54 54                                       |TTTT|

Narrowing to offset 0x24, we have: hexdump -C -n 4 -s 0x24 Linux_for_Tegra/bootloader/eks_t234.img, which gives:

00000024  99 20 be fe                                       |. ..|
00000028

Other things I’ve tried

Here are the things that I have tried, but they resulted in the same fail to unlock the encrypted dev error:

  • Generated the eks image using gen_ekb.py as shown in the first post.
  • Tried ./example.sh for an example generation using my custom kek_optee.key and sym_t234.key and sym2_t234.key, then copied the output eks_t234.img to /Linux_for_Tegra/bootloader
  • Verified that the kek_optee.key I passed as an argument for -oem_k1_key in gen_ekb.py corresponds to the key I used for fusing the board.
  • Ensure that files were originally extracted from Jetson_Linux_R36.4.0_aarch64.tbz2 and Tegra_Linux_Sample-Root-Filesystem_R36.4.0_aarch64.tbz2
  • Ensure that public_sources.tbz was downloaded from the correct version (R36.4.0) and reran the following commands:
# start in parent dir of Linux_for_Tegra/
tar xvf public_sources.tbz2
cd Linux_for_Tegra/source
tar xvf nvidia-jetson-optee-source.tbz2
cd ../
sudo tools/l4t_flash_prerequisites.sh
sudo ./apply_binaries.sh
  • Ran the same 3 commands as shown in the first post for setting up the qspi, setting up the rootfs, and then flashing the board.

Would really appreciate the assistance in this!

hello ntyy,

the offset of 4 magic bytes at the beginning of the EKS image has moving to 0x34 since JP-6.
you may running with below for confirmation.
$ hexdump -C -n 4 -s 0x34 eks_t234.img
00000034 45 45 4b 42 |EEKB|

it’s apply_binary script to create binaries to the root file system, it should be an issue that your EKS has been overwritten by the default file.
please try again to copy the output EKS image, and then running l4t_initrd_flash script for image creation/flashing.

Hello JerryChang,

The command hexdump -C -n 4 -s 0x34 eks_t234.img did indeed give 00000034 45 45 4b 42 |EEKB|.

As for this, I already ran gen_ekb.py after doing ./apply_binaries but am still encountering the same issue. This was the command used:

# inside of Linux_for_Tegra/    
python3 ./source/optee/samples/hwkey-agent/host/tool/gen_ekb/gen_ekb.py \
        -chip t234 \
        -oem_k1_key kek_optee.key \
        -in_sym_key sym_t234.key \
        -in_sym_key2 sym2_t234.key \
        -in_auth_key auth_t234.key \
        -out bootloader/eks_t234.img

Here’s the logs from the 3 commands

flash_device.log (74.9 KB)

rootfs_setup.log (177.2 KB)

qspi_setup.log (206.9 KB)

hello ntyy,

you should do this.. $ cp new_r364_EKS.img ~/r36.4.0/Linux_for_Tegra/bootloader/eks_t234.img before running the l4t_initrd_flash script.

Hey JerryChang,

I have been using the latest version of the generated eks_t234.img by having the file placed into Linux_for_Tegra/bootloader/eks_t234.img. Running this command:

automatically did that for me. I have verified using ls -l Linux_for_Tegra/bootloader/eks_t234.img that I am using the latest version of the eks image. After running this command, I run the 3 commands to setup qspi, setup rootfs, and then flash the board.

hello ntyy,

may I know which Jetpack release version you’re working with.
for instance, if you’re using JP-6.1/r36.4.0, you should download the same version public source package for the gen_ekb.py script file.
besides.. did you fuse your target?

Hello JerryChang,

I am using the installation packages from this website. I re-downloaded and re-extracted the packages:

  • Jetson_Linux_R36.4.0_aarch64.tbz2
  • Tegra_Linux_Sample-Root-Filesystem_R36.4.0_aarch64.tbz2
  • public_sources.tbz2

using

cd ~/jetson_test
tar xvf Jetson_Linux_R36.4.0_aarch64.tbz2
sudo tar xvf Tegra_Linux_Sample-Root-Filesystem_R36.4.0_aarch64.tbz2 -C Linux_for_Tegra/rootfs/
tar xvf public_sources.tbz2
cd Linux_for_Tegra/source
tar xvf nvidia-jetson-optee-source.tbz2
cd ../

sudo ./tools/l4t_flash_prerequisites.sh
sudo ./apply_binaries.sh

and ran all the commands from the top, but still got the same error about failure to unlock the encrypted partition.

Yes I fused the target, using this

hello ntyy,

since you’ve fused a device with OEM_K1.
you’ll need to run the python script, for instance, please check
$public_sources/r36.4.0/Linux_for_Tegra/source/atf_and_optee/optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh to revise the sample key with yours to re-create EKS image.

please do update the binary file $OUT/Linux_for_Tegra/bootloader/eks_t234.img ,
and then, please running below to update EKS image.
$ sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml -k A_eks --no-systemimg jetson-orin-nano-devkit-nvme nvme0n1p1

Hello JerryChang,

I tried the steps you suggested. Then ran

$ sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml -k A_eks --no-systemimg jetson-orin-nano-devkit-nvme nvme0n1p1 > eks_update.log 2>&1

then these commands

    sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
        --uefi-keys uefi_keys/uefi_keys.conf \
        --network usb0 \
        --no-flash \
        --showlogs \
        -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
        "$BOARD_CONFIG" \
        internal > qspi_setup.log 2>&1

    sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh \
        --uefi-keys uefi_keys/uefi_keys.conf \
        -i ./sym2_t234.key \
        --external-device nvme0n1 \
        -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml \
        --showlogs \
        --no-flash \
        --external-only \
        --append \
        --network usb0 \
        "$BOARD_CONFIG" \
        external > rootfs_setup.log 2>&1

    sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
        --showlogs \
        -u rsa.pem \
        -v sbk.key \
        -i sym2_t234.key \
        --uefi-keys uefi_keys/uefi_keys.conf \
        --network usb0 \
        --flash-only > flash_device.log 2>&1

and then rebooted the target but still got the same ERROR: fail to unlock the encrypted dev /dev/nvme0n1p2

Here are the logs:

eks_update.log (78.1 KB)

qspi_setup.log (206.8 KB)

rootfs_setup.log (171.4 KB)

flash_device.log (80.9 KB)

hello ntyy,

it’s partition update to replace EKS image, why you need to flash a target again completely?

Hello JerryChang,

Perhaps I did not understand how that was supposed to work. Anyway, this time I used ~/jetson_test/Linux_for_Tegra/source/optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh to generate the new eks image using the custom sym2_t234.key, sym_t234.key, kek_optee.key and auth_t234.key. Then, only ran the command $ sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml -k A_eks --no-systemimg jetson-orin-nano-devkit-nvme nvme0n1p1 (target is already flashed). The target boots up and shows the same error message: ERROR: fail to unlock the encrypted dev /dev/nvme0n1p2

hello ntyy,

please also check the 4 magic bytes at the beginning of the EKS image, which should be "EEKB".
for instance, please check EKS image at 0x34 offset
hexdump -C -n 4 -s 0x34 eks_t234.img
00000034 45 45 4b 42 |EEKB|