Unlocking the encrypted disk with nvluks-srv-app

[elton3]

Hi,

I have been following these 2 guides OP-TEE: Open Portable Trusted Execution Environment — Jetson Linux Developer Guide documentation and Disk Encryption — Jetson Linux Developer Guide documentation and using optee/samples/hwkey-agent/host/tool/gen_ekb/example.sh to generate a new eks.img for t194 chip.

I’m using Jetson Linux r35.3.1 and a host with ubuntu 20.04.

Here is a screenshot of the t194 portion in example.sh

I ran the example.sh, and once eks_t194.img was generated, I coped it over to Linux_for_Tegra/bootloader/

I also copied over the sym2_t194.key to Linux_for_Tegra/ekb.key and proceeded to flash NVME on the xavier nx with the command below:

sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -p "-i ekb.key" -c ./tools/kernel_flash/flash_l4t_nvme_rootfs_enc.xml --external-only -S 25GiB --showlogs jetson-xavier-nx-devkit external

So far so good, once it was flashed and rebooted, I could see my partition in the below screenshot:

Then I follow this instruction below to see if I can decrypt the encrypted partition:

I used sudo blkid to get this DISK_UUID of the partition,

Then I typed in this command: nvluks-srv-app --context-string "87e1bb72-6261-4252-ba6e-e14e1a2bae54" --get-unique-pass | cryptsetup -c luksOpen /dev/nvme0n1p2 /dev/mapper/test

And I got the error below:

The command to get passphrase: nvluks-srv-app --context-string "87e1bb72-6261-4252-ba6e-e14e1a2bae54" --get-unique-pass gave me this error:

And if I added sudo in front of it, I got this error:

Please let me know if I missed any anything or did something entirely wrong. Any help is appreciated!

Thanks!

[JerryChang]

hello elton3,

please refer to developer guide, Disk Encryption.
re-cap as below.

To prevent any form of attack from extracting the passphrase at boot time (e.g. in the initrd), use the command type LUKS_SRV_TA_CMD_SRV_DOWN . This command instructs luks-srv not to respond to a LUKS_GET command (to get the passphrase) until reboot. This step is crucial to ensure the security of your design.

may I know what’s the actual use-case?
once system boots up, there is no way we can extract the passphrase again.

[elton3]

Hi Jerry,

I see. I think I misunderstood how it works.

So the disk has already been unlocked on boot and mapped to /dev/mapper/crypt_root and mounted at /
Is that correct?

I was trying to validate disk encryption before fusing anything. Do you have any suggestion on how to best validate this?

Thanks!

[JerryChang]

hello elton3,

you may seeing The Threat Model, check if you could stealing data without keys.

[elton3]

Hey Jerry,

Thanks for your response and patience!

Please correct me if I’m wrong here:
So to emulate “stealing data”, I think what I could do is taking out the NVME and plugging it in on another Jetson Xavier NX platform and then trying to boot it.

For this to fail on unlocking disk during boot though, don’t I need to first generate a new KEK2 (that’s not all zeros) and fuse it on the device, and generate and re-flash a new eks.img with this unique KEK2 key?

KEK2, to my knowledge, is the fuse key to derive EKB_EK that encrypts/decrypts the EKB binary (eks.img) that contains the disk encryption key (sym2_key aka ekb.key) that is used to derive the passphrase used by cryptsetup to unlock the disk.

Thanks

[JerryChang]

@elton3

So to emulate “stealing data”, I think what I could do is taking out the NVME and plugging it in on another Jetson Xavier NX platform and then trying to boot it.

that’s correct.
so, once when the key leakage, others could access to this encrypted disk.