I’m trying to get disk encryption to work on the Orin AGX developer kit. I’ve gathered that I need to create an ekb.key and a corresponding eks_t234.img based on the same key to get this to work. In the source for the gen_ekb.py script I saw that for t234 usage of the script there seems to be some different keys that are used, compared to the t194 usage of it.
I don’t think I want to commit to fusing any keys on the board as I’m only interested in encryption at this point. In the t194 usage of the script it uses all zeroes for for example the KEK2 key, but in the t234 usage it says to fill the “OEM_K2” fuse key value. I’m therefore wondering if I can just put all zeroes in my case, since I don’t want to fuse the board at this time?
There’s also a lot of other values that I’m wondering if I need to change in my case. For reference, I’ve provided the example usage below:
# [T234 example]
# Fill your OEM_K2 fuse key value
echo "432646294a404e635266556a586e3272357538782f413f442a472d4b61506453" > oem_k2.key
# This is the fixed vector for deriving EKB root key from fuse.
# It is expected user to replace the FV below with a user specific
# FV, and code the exact same user specific FV into OP-TEE.
echo "bad66eb4484983684b992fe54a648bb8" > fv_ekb_t234
# Generate user-defined symmetric key files
# openssl rand -rand /dev/urandom -hex 16 > sym_t234.key
# openssl rand -rand /dev/urandom -hex 16 > sym2_t234.key
echo "010203040506070809a0b0c0d0e0f001" > sym_t234.key
echo "f0e0d0c0b0a001020304050607080900" > sym2_t234.key
echo "5a5a5a5a5a5a5a5aa5a5a5a5a5a5a5a55a5a5a5a5a5a5a5aa5a5a5a5a5a5a5a55a5a5a5a5a5a5a5aa5a5a5a5a5a5a5a55a5a5a5a5a5a5a5aa5a5a5a5a5a5a5a5" > uefi_pub.key
echo "00112233445566778899aabbccddeeff" > uefi_enc.key
echo "ffeeddccbbaa99887766554433221100ffeeddccbbaa99887766554433221100ffeeddccbbaa99887766554433221100ffeeddccbbaa99887766554433221100" > device_id.cert
python3 gen_ekb.py -chip t234 -oem_k2_key oem_k2.key \
-fv fv_ekb_t234 \
-in_sym_key sym_t234.key \
-in_sym_key2 sym2_t234.key \
-in_uefi_pubkey uefi_pub.key \
-in_uefi_enckey uefi_enc.key \
-in_device_id device_id.cert \
-out eks_t234.img
fv_ekb_t234: I’ve seen this as the fixed vector used in most instances. However, since I’m not fusing the board, is there any point to change this? If I should change it, could it be a random vector with the same length?
sym_t234.key and sym2_t234.key: In the t194 case these are all zeroes, I’m guessing they should be for my case too?
uefi_pub.key: Should this be changed, or is this the public key from some sort of signing of the uefi image? If I build a new image of GitHub - NVIDIA/edk2-nvidia: NVIDIA EDK2 platform support, should I sign it somehow and provide the public key from that signing process? Could you point me to some resources where I can find out more about this?
uefi_enc.key: I’m not sure what this is for or if it should just be what the example says.
since you’re not fusing the target, please leave the board unfused, OP-TEE will inject a test key when booting.
in this case, you need to use the EKS image which generated by the example.sh (in OP-TEE source tarball). sym2_t234.key is the key for disk encryption, please only update this in the script file to create EKS image.
after that, you should update the binary file, and assign the key for flashing the target. $ cp eks_t234.img bootloader/eks_t234.img $ sudo ROOTFS_ENC=1 ./flash.sh -i sym2_t234.key jetson-agx-orin-devkit mmcblk0p1
BTW, you may see-also below for the sample command-line to run disk encryption for external device.
for instance, $OUT/Linux_for_Tegra/tools/kernel_flash/README_initrd_flash.txt, Workflow 10: Disk encryption support on external device
Thank you very much for the fast reply! I had some success following Workflow 11, example 4. However, that attempt encrypted only the eMMC drive, and not the external nvme drive. Below are the steps I took for that attempt:
### Workflow 11, Example 4
sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash jetson-agx-orin-devkit internal
## Edited `flash_l4t_nvme_rootfs_enc.xml` to have 471859200 sectors, as the nvme drive is 250GB
sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_nvme_rootfs_enc.xml -p "-i sym2_t234.key" --external-only -S 200GiB --append --showlogs jetson-agx-orin-devkit external
sudo systemctl stop udisks2.service
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only
In this case I also wondered where I could find more information about how to supply the encryption passphrase? My understanding from the documentation is that the passphrase will be the disk UUID if it is not provided. Is that correct?
I also tried Workflow 10 in the hopes that it would encrypt the nvme drive, however I’m encountering kernel panic when booting after this attempt: bootlog_capture.txt (55.3 KB)
The commands I ran and the resulting logs are below:
# I also edited the sector size in the flash_l4t_nvme_rootfs_enc.xml file in this case
sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_nvme_rootfs_enc.xml -p "-i sym2_t234.key" --external-only -S 200GiB jetson-agx-orin-devkit external
after reading the documentation a bit closer and upgrading to 35.4.1 I was able to get the disk encrypted using a modified version of this answer. However, I’m still a bit unclear about how the encryption works. From what I gather, the flash.sh script generates a luks-passphrase that OP-TEE uses to unlock the disk at boot time?
I’m interested in configuring the system to not automatically unlock the disk. I want to run my own program that injects the luks passphrase, or waits for it to be input through I/O like what I’m used to on vanilla ubuntu machines. Is that possible?
It looks like it should be however I can’t find the option to provide the “User input string or passphrase (optional)” illustrated in the linked figure.
the linked figure. i.e. Creating an Encrypted Rootfs on the Host you point-out is the steps for flashing process.
may I know what’s the real use-case, are you going to check whether ROOTFS_ENC is enabled correctly?
actually, it’s valid during the flash process.
for instance. $ sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 -i ./ekb.key --no-flash --showlogs --external-device nvme0n1p1 -c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml -S 100GiB --append --external-only jetson-orin-nano-devkit external
[INFO] : 7. Now verify on device if the corectly flashed with disk encryption
....
[INFO] : /dev/nvme0n1p1: UUID="937d30caxxxx" TYPE="ext4" PARTLABEL="APP" PARTUUID="7293e259xxx"
[INFO] : blkid output with APP : /dev/nvme0n1p1: UUID="937d30caxxxx" TYPE="ext4" PARTLABEL="APP" PARTUUID="7293e259xxxx"
[INFO] : blkid output with APP_ENC : /dev/nvme0n1p3: UUID="e9657238xxxxx" TYPE="crypto_LUKS" PARTLABEL="APP_ENC" PARTUUID="e9657238xxxxx"
...
[INFO] : APP_ENC partition encryption UUID matches
furthermore, it’s OPTEE LUKS CA for verification during system boot-up.
it’s the cryptsetup utility that can use the passphrase to unlock the encrypted disks during the boot process.
please dig into public release sources, you may see-also below for more details.
for example, $public_sources/atf_and_optee/optee/samples/luks-srv/README
The end goal of this is setting up yubikey-luks so I can either type in the passphrase, or use the yubikey to unlock the system. However, now it seems like the system is automatically unlocked by the luks-srv automatically?
Thinking it over, I believe the automatic login fits my usecase just as well, so I don’t think I’ll pursue setting up the yubikey decryption.