hej
I have buried the fuses on an Orion nano, but the OEMK1 key seems to not be used for anything
This is my fuse config xml with a 0 or 1 ones replacing the keys(length is matching)
<genericfuse MagicId="0x45535546" version="1.0.0">
<fuse name="PublicKeyHash" size="64" value="0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"/>
<fuse name="SecureBootKey" size="32" value="0x0000000000000000000000000000000000000000000000000000000000000000"/>
<fuse name="OemK1" size="32" value="0x1111111111111111111111111111111111111111111111111111111111111111"/>
<fuse name="BootSecurityInfo" size="4" value="0x209"/>
</genericfuse>
i do need the PKC and SBK to flash the device, but then I regenerate the EKS blob with a random value for OEMK1. It is still booting without problem, I would expect it to complain that it is not the current oemk1 key
This is how I generate the EKS blob
echo "0000000000000000000000000000000000000000000000000000000000000085" > oem_k1.key
# openssl rand -rand /dev/urandom -hex 16 > fv_hex_file.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 "94524f4f8d53c431f2e5ff546f0060637c3297130fafebdd69b696b74c78f9aa" > sym_t234.key
#openssl rand -rand /dev/urandom -hex 16 > sym2_t234.key # disk encryption key
echo "97fb25a006c5520185cf892165e41285" > sym2_t234.key
#openssl rand -rand /dev/urandom -hex 16 > auth_t234.key # uefi variables authentication key
echo "089b8259e2b1c6dee77584d4efdb9e45" > auth_t234.key
python3 gen_ekb.py -chip t234 -oem_k1_key oem_k1.key \
-in_sym_key2 sym2_t234.key \
-in_sym_key sym_t234.key \
-in_auth_key auth_t234.key \
-out eks_t234.img
And I flash the orin using
sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 \
-c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml \
-p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
--external-only \
--append \
-i sym2_t234.key \
--uefi-enc sym_t234.key \
--uefi-keys uefi_keys/uefi_keys.conf \
-u pkc.pem \
-v sbk.key\
--showlogs --network usb0 jetson-orin-qs-motherboard internal
hello lucasjeppesen,
actually not, you’ll see assert at UEFI due to mismatch OEM_K1 key.
the error log looks like below..
E/TC:?? 00 jetson_user_key_pta_uefi_vars_auth:920 UEFI variable auth key not set !
E/TC:?? 00 stmm_handle_variable_authentication:910 Failed to get signed CMAC ffff0008
ASSERT [FvbNorFlashStandaloneMm] /dvs/git/dirty/git-master_linux/out/nvidia/optee.t234-uefi/StandaloneMmOptee_RELEASE/edk2-nvidia/Silicon/NVIDIA/Drivers/FvbNorFlashDxe/VarIntCheck.c(922): ((BOOLEAN)(0==1))
BTW,
we’ve check disk encryption with a custom key worked normally.
please see-also Topic 270934 for the steps.
where would this error apear, is it on the debug uart then boot or flashing or is it from the command ?
hello lucasjeppesen,
it’s the error logs of UEFI, you’ll need to setup serial console to obtain the UART logs.
uart-data.txt (79.7 KB)
i read the serial from the orin while it was booting but i dont seam to find the error msg you mention, i have attatched the serial output from picocom
hello lucasjeppesen,
did you fuse the target correctly? let’s check $ sudo nv_fuse_read.sh to read the fuse variable on your target.
you may also check $ df -h, it should looks like below if you’ve disk encryption enabled
/dev/mapper/crypt_root 54G 5.6G 46G 12% /
/dev/mapper/crypt_UDA 374M 14K 350M 1% /mnt/crypt_UDA
/dev/nvme0n1p1 371M 97M 247M 29% /boot
i checked the public_key_hash and it is matching the i set in the fuse_config
and i can see the enctyped partions both with df -h and lsblk
output:
q@nxquadsat40:~$ sudo nv_fuse_read.sh
[sudo] password for q:
Sorry, try again.
[sudo] password for q:
odm_lock: 0x00000000
revoke_pk_h0: 0x00000000
revoke_pk_h1: 0x00000000
optin_enable: 0x00000000
public_key_hash: 0xa3d82ff7a526379977a71654dd1d905b45112f3f4610117585affb4429c13c4ff3e7116962d04f17af0abc425ec47d6e83e2824c8f23ebc0b101833a31e8e280
boot_security_info: 0x00000209
odmid: 0x0000000000000000
pk_h1: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
pk_h2: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
security_mode: 0x00000000
reserved_odm2: 0x00000000
reserved_odm3: 0x00000000
reserved_odm0: 0x00000000
reserved_odm1: 0x00000000
reserved_odm6: 0x00000000
reserved_odm7: 0x00000000
reserved_odm4: 0x00000000
reserved_odm5: 0x00000000
odminfo: 0x00000000
system_fw_field_ratchet1: 0x00000000
system_fw_field_ratchet0: 0x00000000
system_fw_field_ratchet3: 0x00000000
system_fw_field_ratchet2: 0x00000000
ecid: 0x847263ac4b53f406
q@nxquadsat40:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/crypt_root 16G 7.8G 6.8G 54% /
/dev/mapper/crypt_UDA 356M 24K 329M 1% /mnt/crypt_UDA
tmpfs 3.8G 84K 3.8G 1% /dev/shm
tmpfs 1.5G 27M 1.5G 2% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
/dev/nvme0n1p1 359M 62M 269M 19% /boot
/dev/nvme0n1p11 63M 112K 63M 1% /boot/efi
tmpfs 763M 92K 762M 1% /run/user/128
tmpfs 763M 80K 762M 1% /run/user/1000
q@nxquadsat40:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 16M 1 loop
zram0 252:0 0 635M 0 disk [SWAP]
zram1 252:1 0 635M 0 disk [SWAP]
zram2 252:2 0 635M 0 disk [SWAP]
zram3 252:3 0 635M 0 disk [SWAP]
zram4 252:4 0 635M 0 disk [SWAP]
zram5 252:5 0 635M 0 disk [SWAP]
nvme0n1 259:0 0 119.2G 0 disk
├─nvme0n1p1 259:1 0 400M 0 part /boot
├─nvme0n1p2 259:2 0 15.6G 0 part
│ └─crypt_root 253:0 0 15.6G 0 crypt /
├─nvme0n1p3 259:3 0 128M 0 part
├─nvme0n1p4 259:4 0 768K 0 part
├─nvme0n1p5 259:5 0 31.6M 0 part
├─nvme0n1p6 259:6 0 128M 0 part
├─nvme0n1p7 259:7 0 768K 0 part
├─nvme0n1p8 259:8 0 31.6M 0 part
├─nvme0n1p9 259:9 0 80M 0 part
├─nvme0n1p10 259:10 0 512K 0 part
├─nvme0n1p11 259:11 0 64M 0 part /boot/efi
├─nvme0n1p12 259:12 0 80M 0 part
├─nvme0n1p13 259:13 0 512K 0 part
├─nvme0n1p14 259:14 0 64M 0 part
├─nvme0n1p15 259:15 0 400M 0 part
│ └─crypt_UDA 253:1 0 384M 0 crypt /mnt/crypt_UDA
└─nvme0n1p16 259:16 0 479.5M 0 part
q@nxquadsat40:~$
hello lucasjeppesen,
could you please try updating EKS image (with the incorrect OEM_K1 key), then using below flash commands to update QSPI.
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 --showlogs -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" jetson-orin-nano-devkit internal
i run
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 --showlogs -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” -u pkc.pem -v sbk.key jetson-orin-nano-devkit internal | tee l4t_initrd_output
I added -v -u else it would not do anything
it do throw an error on boot now
E/TC:?? 00 jetson_user_key_pta_uefi_vars_auth:984 UEFI variable auth key not set !
E/TC:?? 00 stmm_handle_variable_authentication:894 Failed to get signed CMAC ffff0008
ASSERT [FvbNorFlashStandaloneMm] /out/nvidia/optee_ftpm.t234-uefi/StandaloneMmOptee_RELEASE/edk2-nvidia/Silicon/NVIDIA/Drivers/FvbNorFlashDxe/VarIntCheck.c(932): ((BOOLEAN)(0==1))
Did the command I ran for flashing before not update the EKS?
uart-data-eks-update.txt (114.7 KB)
l4t_initrd_output.txt (469.6 KB)
hello lucasjeppesen,
yes, it looks you did not update EKS partition correctly.
as mentioned, please refer to Topic 270934 for the steps to full flash your target to enable disk encryption with custom key.
i found running the 3 commands listen in the ducmentation Disk Encryption — NVIDIA Jetson Linux Developer Guide
with the adding the uefi and pkc and sbk works and is writing the eks blob aswell
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 \
--showlogs \
--no-flash \
--uefi-enc sym_t234.key \
--uefi-keys uefi_keys/uefi_keys.conf \
-p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
-u pkc.pem -v sbk.key\
jetson-orin-qs-motherboard internal
sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 \
--showlogs \
--no-flash \
--external-device nvme0n1p1 \
-S 16GiB \
-c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml \
--external-only \
--append \
-i sym2_t234.key \
--uefi-enc sym_t234.key \
--uefi-keys uefi_keys/uefi_keys.conf \
-u pkc.pem -v sbk.key\
jetson-orin-qs-motherboard external
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 \
--showlogs \
--flash-only \
--uefi-enc sym_t234.key \
--uefi-keys uefi_keys/uefi_keys.conf \
-u pkc.pem -v sbk.key\
jetson-orin-qs-motherboard internal
but i tried using all 0’s as oemk1 key in the eks and it worked aswell, is this becouse the oemk2 key and PscOdmStatic is not fused?
hello lucasjeppesen,
did you meant you’re using all 0s to create EKS image?
how you replace that binary file on your target? did you repeat those 3 commands again?
BTW,
it’s MB2 for verifying the boot images it loads, such as ATF, OP-TEE, UEFI… and etc. So only when OemKeyValid and SecurityMode are burned, the signature of these components will be checked. you may see-also Topic 337248 as see-also.
yes, then i use all 0’s for the oemk1 key to create a an eks blob it will boot without proble, if i use a random value for the oemk1 key in the eks it will not boot, and it works witout problem if i use the oemk1 key i fused
| oemk1 key |
boots |
| all 0 |
yes |
| the fused oemk1 key |
yes |
| random value |
no |
I re-ran all three commands between testing each key, and the only diffrent on the eks generation is the Oemk1 key.
i dont seam to see OemKeyValid as a fuse anywhere in the documention
hello lucasjeppesen,
please refer to Jetson Orin Fuse Specification, it’s bit-9 of FUSE_BOOT_SECURITY_INFO_0.
i think i found it. i do have odm key vaild fused if i understand it correnctly( bit 9 in boot_security_info) do not not have security mode burned as i understand it will lock up most of the fuses and remove my ability to burn the non burned fuses.
is it expected behavior that an all 0 oem k1 key works as well as the burned into the oemk1 fuse, but a random key do not work?
hello lucasjeppesen,
that’s unexpected, it should assert at UEFI due to mismatch OEM_K1 key.
I doubt you’re not replace EKS image correctly for testing.
did the exact same as I did for the random OEM K1 key. I first did the random key, and it did not boot, and then I did the all 0s key, and then it booted, which I would think indicates the all 0’s is a valid OEM k1 key,
I tried to read about it in the fuse documentation, and it mentioned FUSE_KEYS_PSC_STATIC_OEM_0_0_0 and FUSE_KEYS_PSC_STATIC_OEM_0_1_0(I would think it is PscOdmStatic in the fuse config), which contains oem_k1_purpose and oem_k2_purpose, and the defualt purpose seams to be ENC could it be the oem k2 is used as it would be all 0’s as i did not burn an value where?
hello lucasjeppesen,
just for confirmation, you’re not yet burn SecurityMode fuse variable, right?
SecurityMode is not burned
hello lucasjeppesen,
to be honest, we’ve tested with SecurityMode enabled.
here’re more details regrading to OEM_K1/K2.
OEM_K1/K2 to derive a root key which is itself used to sign and encrypt the EKB.
– OEM_K1 is the root of trust of EKB, and it is used to derive the RPMB key too.
– OEM_K2 is to derive the PV encryption key. If you don’t need to encrypt CPUBL with a PV key, you don’t need to care about OEM_K2.
in JP-6.0/r36.3.0 release version, it was using OEM_K2,
in JP-6.1/r36.4.0 (the latest release version) they are both used to open EKB.
furthermore,
PscOdmStatic, we recommend burning it to 0x60, which sets the purpose of:
– OEM_K1 to encryption
– OEM_K2 to KDK(key derive key)