Jetson Orin AGX Disk Encryption


I’m currently reading the documentation and I have two questions regarding passphrase generation:

Q1: Does the Orin AGX alone generate the passphrase using luks-srv (with the jetson_user_key_pta) after each boot? If so, what is the purpose of using

Q2: Can we use disk encryption without employing secure boot?

Thank you in advance.

hello elhamriothman,

as you can see in the developer guide, Creating an Encrypted Rootfs on the Host. is used on the host side to derive the LUKS key, and uses the key to generate the passphrase.

yes. you may see-also Topic 284400 for the steps.

Hello Jerry,

Thank you for the prompt reply. Everything looks good for Q2, but regarding Q1, I have a question. When we are on the host side and derive the LUKS key that generates the passphrase, we then pass it to the Jetson module. However, I’m unclear on the purpose of this step. Don’t we generate the passphrase after each boot on the Jetson module side? Additionally, I’m still unsure about how the decryption of the disk occurs exactly. I only found a manual script that uses cryptsetup and nvluks-srv-app to unlock the encrypted disk.

Thank you for your assistance.

hello elhamriothman,

actually, is more like validation tool executed on the host side for checking passphrase.
you may running with… $ python3 -k ekb.key -c "luks-srv-ecid" -u -e "BR_CID" to obtain the passphrase.
note, it depends-on your device of BR_CID and also ekb.key.

if there’s no issues,
the passphrase should the same by running with below on the target side.
$ sudo /usr/sbin/nvluks-srv-app -c "luks-srv-ecid" -u

So the passphrase is only generated once on the host side?

hello elhamriothman,

I don’t really understand your question. what’s your real use-case?
ekb.key is your key for disk encryption, which store in the EKS image and flashing onto the target.

Hello Jerry,

I have just completed flashing the Jetson Orin AGX with the encrypted image. In the initial paragraph discussing disk encryption, it states that the passphrase in the Jetson OP-TEE TA supports disk encryption with one-time passphrase generation during boot time. Therefore, my question is: does the user need to input anything during boot, or does it decrypt the disk autonomously using the one-time passphrase, if not how does the decryption of the disk exactly happen?

hello elhamriothman,


please check The Threat Model section,
the purpose of disk encryption is to prevent an attack from stealing or tampering with data on the disk.

Oh ok I see, and how does the the decryption works exactly when it comes to the jetson orin agx during the boot phase?

When I try to use the cmd $ sudo /usr/sbin/nvluks-srv-app -c "luks-srv-ecid" -u

I get this message: TEEC_InvokeCommand failed 0xffff0001 origin 0x4

this diagram outlines the overall process.

Yeah I already got a clear idea now, but I still can’t find why the TEEC error message when trying the cmd you sent me.

hello elhamriothman,

did you using customize key for disk encryption?
it might be the EKB image didn’t be extracted correctly.

as mentioned,
you may see-also Topic 284400 for the steps to re-generate a new EKS image and update it accordingly.

No I used the exemple keys, I have two encrypted partition it just I can’t seem to extract the passphrase.

hello elhamriothman,

just double confirm the L4T release version you’re now using. i.e. $ cat /etc/nv_tegra_release
is that’s possible, please moving to the latest release version (jetson-linux-r3550) for confirmation.

Hello Jerry,

Im using the R36 version.

hello elhamriothman,

FYI, is a tool at host side to generate passphrase for disk encryption when you create encrypted images.
nvluks-srv-app is a tool to run at device side to get passphrase generated from TEE at initrd stage for disk decryption.
they are different tools running for different purposes, but the output passphrase should be aligned or disk decryption will fail.

regrading to this error… TEEC_InvokeCommand failed 0xffff0001 origin 0x4
this command, nvluks-srv-app -c "luks-srv-ecid" -u which can only run at initrd stage to get passphrase,
so, this failure is expected as it avoid to retrieve passphrase on the target, or it might open a door for attackers.

for checking disk encryption functionality, you should make sure…
(1) disk encryption key is passed from flash tool correctly.
(2) disk encryption key inside eks.img is aligned and it can be extracted correctly at TEE side.

Hello Jerry,

I see thanks! I did notice that when I use lsblk my mmcblk3p2 contains the crypt_root, and the partition type is crypt. Additionally, I found a partition named mmcblk3p15 which has crypt_UDA. I’m not entirely sure what “UDA” stands for, perhaps “user data” or something similar, but it’s also encrypted and mounted at /mnt/crypt_UDA. As for the eMMC, everything seems fine. I just wish there was a way to see exactly how the boot process unfolds because the boot messages on the AGX appear too quickly for me to follow. I’m going to attempt to encrypt the SSD now.