I am using a 64GB AGX Orin with a Connecttech Carrier board, Jetpack 5.1.3, and Jetson Linux 35.5. I have been following the encryption documentation at Disk Encryption — NVIDIA Jetson Linux Developer Guide 1 documentation. I am able to flash eMMC, flash eMMC encrypted with LUKS, and flash an NVMe drive to boot from, but I haven’t been able to flash a bootable NVMe encrypted with LUKS.
My application requires that the boot drive with the root file system be encrypted with LUKS, and only unencrypted on boot when a password is entered to meet Data at Rest requirements. The current status of the eMMC with LUKS is that it’s encrypted, but automatically unlocks on boot which has no value to me. I would also like to use a USB drive to act as a key to unencrypt on boot and allow headless operation.
For a LUKS NVMe boot configuration, I’ve gone through the initrd encrypted rootfs encryption process several times tweaking options based on the Disk Encryption documentation and the readme files associated with all the scripts ran. I was hoping that since a passphrase is specified it would meet my needs. So far I can get to the point where initrd runs, claims everything was flashed successfully, etc, but only get a blank screen upon booting from the NVMe.
Is there a path to meet my needs of a LUKS encrypted rootfs that requires a password to unlock? Other encryption methods like Sedutils/PBA might be acceptable, but there is little information aside from what’s provided by NVIDIA.
If there is a combination of what’s in the documentation that would give me the results I want, could you specify the key steps and flags in the flash commands to make it happen?
It’s hard to say if flashing was really successful if it didn’t boot, but I did get the message on the host PC that flashing was complete/successful/etc and to reboot the system to boot from the NVMe. Which then yielded a black screen, which doesn’t happen if I do things without encryption.
Can you confirm that it’s possible to LUKS encrypt and boot from the NVMe with a user-set password? If so I’ll run through things again and get the log, otherwise there’s no point.
There was a flash successful message, sorry if my wording was confusing. It just didn’t boot when I power cycled the board. I’ll run through things Monday and get back to you with the logs - you want the output from the UART, right? And to be clearer with the password thing, I’m looking for a password to decrypt the drive before getting into the OS., I know I can set a password for Ubuntu. So you enter one password to decrypt, then another to sign in.
On other non-ARM based systems, Ubuntu has an option to encrypt the boot drive with LUKS. So in that case upon boot you enter a password to unlock the drive, followed by a password to log-in as a user to the OS.
If the implementation for the LUKS NVMe boot drive is only like LUKS on the eMMC (ie ‘encrypted’ from an anti-tamper perspective, but boots right up without a decryption password) it has no use to me. I am trying to meet Data at Rest requirements.
My question about how the decryption interface was handled wasn’t answered, so I didn’t follow through with further troubleshooting in the interest of time. Given NVIDIA’s useless implementation of LUKS for the eMMC, I wasn’t assured that anything of value would come out of this and wasn’t going to waste my time without confirmation.
I’ve read the documentation, I know it uses Cryptsetup. I don’t know how many ways I can phrase this question: Upon powering the device, does a screen appear for the user to enter a password to decrypt the drive, followed by the usual Ubuntu login screen ? If on standard Ubuntu you select “encrypt with LUKS” during setup, this is what happens. This is what I want.
It is not what happens when following the Nvidia procedure for LUKS setup on the eMMC. To meet security requirements, I need the LUKS decryption to require a password, and not just unlock upon boot. The current anti-tamper flavor of the Nvidia luks implementation is useless for me - does the NVMe LUKS work the same way? Or is it what I’m looking for as described above? I literally just need to know if I should waste more time on this.
I need to encrypt the boot drive, otherwise I could just use an Opal drive and sedutils. A quick look at dislocker seems to be for encrypting a secondary drive. Your final suggestion on that thread was to look at the flashing to NVMe documentation, which is what brought me here in the first place. LUKS works for my current Data at Rest requirements, but not in the NVIDIA implementation I’ve seen for the eMMC. Can you answer my question about how the LUKS encryption on the NVMe behaves? Its a yes or no question.
would you like to understand how disk encryption works?
in general,
it’s gen_luks_passphrase.py, which is a tool at host side to generate passphrase for disk encryption when you create encrypted images.
upon system boot-up, nvluks-srv-app is a tool to run at device side to get passphrase generated from TEE at initrd stage for disk decryption.
these two are different tools running for different purposes, but the output should be aligned, or disk decryption will fail.
It’s fine to just say you don’t know or care what I’m talking about, instead of regurgitating the simplest summary of the documentation we’ve already discussed. The documented implementation of LUKS seems to be useless for Data at Rest requirements, but I’ll try one last time.
In standard desktop x86-64 Ubuntu, following the LUKS procedure results in an additional stage where the user has to enter a different passphrase to unlock the drive, followed by the usual user login for the OS. This works for Data at Rest requirements.
Following the LUKS encryption procedure in the NVIDIA Orin documentation, upon boot only the OS user login password is required. You can see the partitions are encrypted as LUKS, but automatically unlocking on boot doesn’t meet Data at Rest requirements and is frankly a useless implementation. If someone with physical access can take it somewhere, plug it in, and only need the OS password, that doesn’t meet the encryption requirements.
To reiterate some other points that have been missed: I’ve gotten LUKS set up on the Orin per the documentation when booting from the eMMC. This is a simple change when flashing. The result does not meet my needs. I haven’t gotten it to work with the NVMe flashing, but that’s separate and not significant at this stage. I have flashed to and booted from the NVMe normally, so I know that works. I stopped troubleshooting that combination to ask if there is any way to produce the passphrase input screen to unlock the drive before the OS login to save some time. It’s a simple question, where if its a no there is no path forward here, but for some reason we keep going in circles. At this point I just want closure that the procedures in the documentation do NOT provide the type of encryption interface I’m looking for.
please refer to The Threat Model, the data cannot be exposed even unmounted the disk to attack physically.
the security requirements of disk encryption is that if you lost the storage to someone, that person should not be able to access the data of the storage. the assumption is that because the person does not have access to the device, they can’t possibly know the ecid.
however, it cannot protect if you leak login ID and password.