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
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.
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?
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.
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?
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.
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.
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.