Disk encryption key in EKS partition

Hello,
I’m investigating disk encryption for Orin NX custom board using Jetpack 6.0.

Question: Is a custom key for disk encryption in EKS partition stored securely without burning any fuse?

The reason behind the question is that we have a requirement to protect current content with disk encryption while maintaining the ability to flash other images to the device in the future.

PS: Please assume we use ‘generic key’ for mass flashing and the key is replaced to a device unique key in the first boot as explained here

1 Like

hello akudo,

according to developer guide, Secure Boot — NVIDIA Jetson Linux Developer Guide 1 documentation
the root-of-trust that uses the NVIDIA SoCs fuses to authenticate boot codes ends at the Bootloader. After this, the current Bootloader (UEFI) will use UEFI’s Security Keys scheme to authenticate its payloads.
we strongly recommend that users enable fuse-based bootloader secure boot so that the root-of-trust can start from the BootROM.


besides, please see-also The Threat Model section.
re-cap as below.

Disk encryption cannot protect against the following types of threat:

  • A background process or daemon that has a security hole. An attacker may be able to use the hole to gain control of the process and access the disk.
  • Theft or leakage of the login ID and password. An attacker can use these credentials to log in to the device and access the disk.

BTW, you may see-also Topic 270934 for demonstration steps we’ve test disk encryption with a custom key on Orin Nano DevKit.

Hello JerryChang,
Thank you for your answer.

Understood the two types of threats you mentioned.
But I still don’t understand how the secure boot protects encrypted disk contents.
Can unauthorized boot code possibly read out the LUKS passphrase in Trusted Application and thus read out the encrypted disk contents? Is that the case even without knowing root password of the device?

Beside, can some tool read out EKS partition and thus extract LUKS passphrase in the TA from it? Here I assume tools like flashing tool with initrd, debug tool with serial port, or backup & restore tool. And please assume the generic passphrase at mass-flash time is replaced with per-device unique passphrase in the first boot as I mentioned earlier. Please also assume the device root password is not broken.

And if such a thing is possible, will the secure boot make a difference in dealing with it?

hello akudo,

please dig into Secure Boot section, which prevents execution of unauthorized boot codes through the chain of trust.
there’re several keys.
for instance,
PKC for sign: if PKC is burned, then the KEYFILE users provide is for signing the images.
SBK for encryption: if SBK is burned, then the SBKFILE users provide is for encrypting the images.
KEKs for encryption keys: they are keys to encrypt your keys. KEK0, KEK1, KEK2 are 128-bit key files; KEK256 is 256-bit key file.

once you’ve enable Jetson security (i.e. programming fuse configuration), you’ll need to using the same keys to flash the target, besides, partition update is disabled after secureboot.

ultimately,
the security of your device depends on how securely you keep the key file.

Hi JerryChang

Thank you for the secure boot reference.
Can I flash an image of different Jetpack version in future as long as the same key is used for the secure boot?

hello akudo,

yes, you must use the same keys to re-flash a fused target.

It is before applying the fuse burning for secure boot though, I flashed a root FS encrypted image to the Orin NX device, and then backed up the device as follows.

Linux_for_Tegra$ sudo ./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -b jetson-orin-nano-devkit

After this command, I can see following files under tools/backup_restore/images folder.

Linux_for_Tegra$ ll tools/backup_restore/images/
total 50652064
drwxr-xr-x 2 root root        4096 12月 12 14:59 ./
drwxr-xr-x 3 root root        4096 12月 12 14:02 ../
-rw-r--r-- 1 root root       16896 12月 12 14:09 gptbackup.img
-rw-r--r-- 1 root root       20480 12月 12 14:09 gptmbr.img
-rw-r--r-- 1 root root       55266 12月 12 14:55 nvme0n1p10_bak.img
-rw-r--r-- 1 root root      352912 12月 12 14:55 nvme0n1p11_bak.img
-rw-r--r-- 1 root root      365939 12月 12 14:55 nvme0n1p12_bak.img
-rw-r--r-- 1 root root        4608 12月 12 14:55 nvme0n1p13_bak.img
-rw-r--r-- 1 root root      292755 12月 12 14:55 nvme0n1p14_bak.img
-rw-r--r-- 1 root root    60588135 12月 12 14:55 nvme0n1p15_bak.img
-rw-r--r-- 1 root root     2195526 12月 12 14:55 nvme0n1p16_bak.img
-rw-r--r-- 1 root root    61698925 12月 12 14:09 nvme0n1p1_bak.img
-rw-r--r-- 1 root root 51576790344 12月 12 14:44 nvme0n1p2_bak.img
-rw-r--r-- 1 root root    31142877 12月 12 14:55 nvme0n1p3_bak.img
-rw-r--r-- 1 root root       55266 12月 12 14:55 nvme0n1p4_bak.img
-rw-r--r-- 1 root root      146388 12月 12 14:55 nvme0n1p5_bak.img
-rw-r--r-- 1 root root    31142877 12月 12 14:55 nvme0n1p6_bak.img
-rw-r--r-- 1 root root       55266 12月 12 14:55 nvme0n1p7_bak.img
-rw-r--r-- 1 root root      146388 12月 12 14:55 nvme0n1p8_bak.img
-rw-r--r-- 1 root root    35464392 12月 12 14:55 nvme0n1p9_bak.img
-rw-r--r-- 1 root root        2036 12月 12 14:55 nvpartitionmap.txt
-rw-r--r-- 1 root root    67108864 12月 12 14:09 QSPI0.img

If I enable the secure boot with fuse, will it still be possible to extract partitions like this?

And even if so, can I tell it is not possible to use this QSPIO.img as a clue to somehow find the LUKS passphrase?

hello akudo,

you’ve to assign PKC/SBK keys to backup/restore once you’ve enable SecureBoot,
for instance,
$ sudo ./tools/backup_restore/l4t_backup_restore.sh -u PKC.key -v SBK.key -b jetson-orin-nano-devkit-nvme

BTW,
you may also running with l4t_initrd_flash.sh to generate a massflash package.
it’ll create mfi_* package, for instance, mfi_jetson-orin-nano-devkit-nvme/, which contain all necessary binary files to deploy.
you may see-also README_initrd_flash.txt, [Workflow 8: Secure initrd Massflash] for reference.

you’ve to assign PKC/SBK keys to backup/restore once you’ve enable SecureBoot,

OK. This is good to hear.
Thank you.

Hello JerryChang,

Is “UEFI Secureboot” an essential feature to protect boot code and prevent reverse engineering? Or is it more of an optional feature?

hello akudo,

it depends-on your use-case.

L4TLauncher cannot detect whether UEFI payload encryption is enabled.
UEFI Secure Boot uses digital signatures (RSA) to validate the authenticity and integrity of the codes that it loads.
so, if the EKS contains the UEFI payload encryption key and UEFI secure boot is enabled,
L4TLauncher will assume that UEFI payload encryption is enabled and will attempt to decrypt the UEFI payloads.

please file another new discussion thread if you’ve follow-up questions.

Thank you for your answer, JerryChang
OK. I will create a new thread for a different topic in future.

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