[L4T 35.4.1] How to verify is SecureBoot is running


I am trying to implement Secure Boot on my Jetson Orin Nano+NVME using L4T 35.4.1 and an Orin Nano Developer Kit. I can flash the unit successfully but I want to know how I can tell if SecureBoot is running.

Here are my steps:

wget https://developer.nvidia.com/downloads/embedded/l4t/r35_release_v4.1/release/jetson_linux_r35.4.1_aarch64.tbz2
wget https://developer.nvidia.com/downloads/embedded/l4t/r35_release_v4.1/release/tegra_linux_sample-root-filesystem_r35.4.1_aarch64.tbz2
wget https://developer.nvidia.com/downloads/embedded/l4t/r35_release_v4.1/sources/public_sources.tbz2
tar xvf jetson_linux_r35.4.1_aarch64.tbz2
sudo tar xvf tegra_linux_sample-root-filesystem_r35.4.1_aarch64.tbz2 -C Linux_for_Tegra/rootfs/
tar xvf public_sources.tbz2
cd Linux_for_Tegra/source/public/
tar xvf nvidia-jetson-optee-source.tbz2
cd ../..
sudo tools/l4t_flash_prerequisites.sh
sudo ./apply_binaries.sh

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_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
echo "${SBK_KEY_XML}" > sbk_xml.key
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
echo "${KEK_2_KEY_XML}" > kek_xml.key
echo "${KEK_2_KEY_OPTEE}" > kek_optee.key
echo $PLACEHOLDER_KEY_1 > fv_ekb_t234
echo $PLACEHOLDER_KEY_2 > sym_t234.key
echo $PLACEHOLDER_KEY_3 > sym2_t234.key

python3 ./source/public/optee/samples/hwkey-agent/host/tool/gen_ekb/gen_ekb.py -chip t234 -oem_k2_key kek_optee.key -fv fv_ekb_t234 -in_sym_key sym_t234.key -in_sym_key2 sym2_t234.key -out bootloader/eks_t234.img

echo "<genericfuse MagicId=\"0x45535546\" version=\"1.0.0\">" > fuse.xml
echo "  <fuse name=\"PublicKeyHash\" size=\"64\" value=\"${PKCS_KEY_XML_HASH}\"/>" >> fuse.xml
echo "  <fuse name=\"SecureBootKey\" size=\"32\" value=\"${SBK_KEY_XML}\"/>" >> fuse.xml
echo "  <fuse name=\"OemK2\" size=\"32\" value=\"${KEK_2_KEY_XML}\"/>" >> fuse.xml
echo "  <fuse name=\"BootSecurityInfo\" size=\"4\" value=\"0x209\"/>" >> fuse.xml
echo "  <fuse name=\"SecurityMode\" size=\"4\" value=\"0x1\"/>" >> fuse.xml
echo "</genericfuse>" >> fuse.xml

sudo ./odmfuse.sh -i 0x23 -k rsa.pem -S sbk.key -X fuse.xml jetson-orin-nano-devkit

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 -u ./rsa.pem -v ./sbk.key --no-flash --showlogs -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" jetson-orin-nano-devkit internal

sudo cp bootloader/eks_t234_sigheader_encrypt.img.signed ./tools/kernel_flash/images/internal/

sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs -u ./rsa.pem -v ./sbk.key --no-flash --external-device nvme0n1p1 -i ./sym2_t234.key -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml -S 400GiB --external-only --append --network usb0 jetson-orin-nano-devkit external

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs -u rsa.pem -v sbk.key --network usb0 --flash-only

After finishing all those procedures, I can see the Orin Nano boot up and it takes me through a first-time setup wizard. After the first-time setup, then I can SSH into the Orin Nano.

  1. I can see the public key when running cat /sys/platform/devices/tegra-fuse/public_key.
  2. I can also see RSA PSS signature check pop up in MB2 bootloader logs.
  3. I can also run nv_fuse_read.sh on the Orin Nano and get this output:

root@ubuntu:/home/l6a# nv_fuse_read.sh
revoke_pk_h0: 0x00000000
revoke_pk_h1: 0x00000000
pk_h1: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
odminfo: 0x00000000
pk_h2: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
odmid: 0x0000000000000000
system_fw_field_ratchet1: 0x00000000
system_fw_field_ratchet0: 0x00000000
system_fw_field_ratchet3: 0x00000000
system_fw_field_ratchet2: 0x00000000
optin_enable: 0x00000000
public_key_hash: 0xe2c1b695222fc8af8a974f57073f9af0c9967d91d87375bf0c445c777e0e74f32a8b63cf65aacd0f59d6d6b34c120f2dc81369b2ce310de731f6fafffc90a352
ecid: 0x847262A8D72C0000
reserved_odm2: 0x00000000
reserved_odm3: 0x00000000
reserved_odm0: 0x00000000
reserved_odm1: 0x00000000
reserved_odm6: 0x00000000
reserved_odm7: 0x00000000
reserved_odm4: 0x00000000
reserved_odm5: 0x00000000
boot_security_info: 0x00000209
security_mode: 0x00000001
odm_lock: 0x00000000

  1. HOWEVER, when I run mokutil --sb-state, it still says:
root@ubuntu:/home/l6a# mokutil --sb-state
SecureBoot disabled
Platform is in Setup Mode

Are there any other steps you know to verify if SecureBoot is active? It seems like I am getting conflicting information from the system.

hello kevin.choi,

it looks you’ve fuse the target, and those key (you read from the target) should be identical with fuse.xml, right?

Secure boot establishes a root-of-trust, it start from the BootROM.
Secure boot for UEFI is a method to ensure that no unauthenticated code will be loaded from UEFI.
mokutil is the utility for checking UEFI Secure Boot.
please refer to developer guide, UEFI Secureboot for more details.

Hi @JerryChang
Yes, I fused the target, and public_key_hash matches what is in fuse.xml.

But I have two questions:

  1. How can I check if the SBK (SecureBootKey) is on the module as well?
  2. Is there any other way to check if Secure Boot is successfully running on the module?

hello kevin.choi,

all those keys (such as SBK, KEK…etc) will shown as 0xff... in fuse_info once SecurityMode has burned.
that is expected due to security concern. for instance, if these fuses can be read out after burning, that will be a huge security vulnerability.

one quick way for testing is given an incorrect SBK key to flash the target again,
it should report an error in the very beginning image flash stage, (i.e. BootRom) if you given wrong SBK key.

Hi @JerryChang
Thank you for answering.

In my printout of nv_fuse_read.sh, there are a lot of zeroes. If what you are saying is true, I should see a few more 0xFF in the fuses, right?

as you can see, none of them were user provided encryption keys.

Ok, let me ask this way.

How do I read fuse_info and see these fields that should have 0xFF?

please check… /sys/devices/platform/tegra-fuse on your target.

Hi @JerryChang
So if I wanted to add UEFI SecureBoot into my system as well, what would I have to do?
I understand we add the --uefi-keys uefi_keys.conf argument. How do I make uefi_keys.conf point to the rsa.pem and sbk.key file I created earlier?

hello kevin.choi,

please refer to UEFI Secureboot section, UEFI Secureboot implementations use PK, KEK, and db keys.
anyways, it looks like another new topic you’re asking, let’s have a new discussion thread to follow-up.

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