Is it possible to decrypt a rootfs disk in another system, knowing the ECID and the keys used to generate it

[louis46]

Hello,

I’m using a Jetson Orin NX and my goal is to have an encrypted rootfs NVMe drive to block disk access as described in the documentation.

But I would like to be able to decrypt the disk with another host to access the stored data in the case there would be a hardware failure.

For the encryption part, I got everything to work, my board is unfused and I flashed it with some customs keys and the board successfully booted on the encrypted partition.
But it is for the decryption part that I have some problems.
As I have the keys that got used to generate the encrypted rootfs, I thought it should be possible but I couldn’t get it to work.

Here is what I did:

# Use custom sym2_t234.key to generate a bootloader image and copy it to the correct folder
python3 gen_ekb.py -chip t234 -oem_k1_key oem_k1.key \
-in_sym_key2 sym2_t234.key -out eks_t234.img

cp ./source/tegra/optee-src/nv-optee/optee/samples/hwkey-agent/host/tool/gen_ekb/eks_t234.img ./bootloader/eks_t234.img


# With the board in recovery mode
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 --showlogs \
-p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --no-flash \
PE1100N-orin internal | tee internal_flashing_logs.txt

sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 \
-c tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml --showlogs --network usb0 --no-flash \
--external-only --append -i ./sym2_t234.key PE1100N-orin external | tee external_flashing_logs.txt


# Finally flash both images on the device
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 --showlogs --flash-only

As said previously, this part is working and the board is booting correctly after that.

But when using an external USB enclosure to connect the NVMe drive to a Ubuntu host, I can NOT get the partition to decrypt:

# Here is how I generated the passphrase based on the key and the board ID
python3 gen_luks_passphrase.py -k sym2_t234.key \
-c "luks-srv-ecid" -u -e "0x80012344705DE3C08C00000009FD8140"

# Trying to decrypt the drive gives this error
sudo cryptsetup open /dev/sda2 test_decrypt --key-file ./sym2_t234.key
No key available with this passphrase.

Am I doing something wrong or is it not possible ?

The log files are attached for more information if needed.
external_flashing_logs.txt (158.3 KB)
internal_flashing_logs.txt (210.6 KB)
serial_logs_boot.txt (104.7 KB)

Thanks for your help

[linuxdev]

I’ve never done it, but if you have a bit-for-bit exact image of the partition, then you can cover it with loopback and treat the loopback device as a partition. Should your other system have keys and everything to mount the encrypted device via command line, then you can do this with the loop device itself as if it is the partition. dd is one way of making a bit-for-bit exact clone. Cloning the rootfs does the same thing, but in recovery mode (you’d only want the raw clone though, the sparse clone is useless for this purpose). Keep in mind clones are huge and take a long time to create since it is an entire partition turned into a file (your host would need a partition far larger than the partition being cloned).

[louis46]

Thanks for your answer!
For the tests and to avoid copying large amounts of data with the clones, I’m currently using an external enclosure to connect the NVMe drive to the host (which is not the Jetson and on which I try to decrypt and mount the disk).
I’ve never used loopbacks, do they provide more functionality than directly mounting the drive?

[linuxdev]

The entire purpose of loopback is to take a file and make it appear to be a partition to tools working with it. Keep in mind that disks have partitions and other metadata when you clone an entire disk. However, by itself, a file covered by loopback becomes a partition. This partition has no type or anything else.

While speaking of this, consider that there are a limited number of loopback devices, and they are numbered starting from “/dev/loop0”, and count up, e.g., there might be a “/dev/loop3”. Your system might have other loopback devices running at the time, so start by examining which loopback devices already exist:
losetup --list

An alternate view:
losetup -a

Before I begin, realize that there are many different ways to create an empty file. If you do this, then it should always be a multiple of 512 bytes. If the block size of a given device is 512 bytes (or a multiple like 4096), then this is due either the formatting or the hardware of the disk. When you use a clone you don’t care because it will already be a valid multiple of 512 bytes or some larger size. Listing the exact byte size of a clone after you create it and verifying a multiple of 512 bytes is a good sanity check. Raw clones do this (such as dd), sparse clones do not.

This command “covers” a file with loopback (and it could be a partition clone), and echos the name of the loop file (I am arbitrarily calling the file “filename.bin”; the name of the file does absolutely nothing other than help you remember what it is; a partition is binary data, and has no other kind of data until it is formatted and files created within the format; a clone is already formatted):
sudo losetup --find --show ./filename.bin

I’m going to pretend this showed it is “/dev/loop0”, although it is unlikely that’s the exact name. You could then use commands which examine a partition by naming it:
lsblk -f /dev/loop0
(this is a block device)

You could find out about the partition (which won’t have info because it is not a cloned disk; it is a subset, a cloned partition, and partitions don’t have the same metadata that a whole disk does):
sudo gdisk -l /dev/loop0

Don’t do this, but if you wanted to format a file (destroying its current content), then you could format it as ext4:
sudo mkfs.ext4 /dev/loop0

If this is in fact an ext4 partition, then you could mount it. Example:
sudo mount /dev/loop0 /mnt

Any encryption software needed to mount the original partition is still required. Any prompting you get for passwords or keys will still occur even though it is a loopback device (the mount command does not think of this as a “fake” partition; it is now a block device). If you are missing some user space software or kernel driver, then you will have to figure that out as you go.

Note that you could release this loopback device (you “detach” the loop device; it still exists, but is not associated and won’t show up in commands to list it):
sudo losetup -d /dev/loop0

See “man losetup”.

[JerryChang]

hello louis46,

FYI,
gen_luks_passphrase.py 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 should be aligned or disk decryption will fail.

here’s another approach instead of using an unique ECID to enable disk encryption.
please see-also Topic 291335 to create encrypted images with a generic key, (--generic-passphrase)

[louis46]

Hello JerryChang,

Thanks to your answer, I checked how is the nvluks-srv-app launched and found my mistake.
The context string used is the partition UUID:

python3 gen_luks_passphrase.py -k sym2_t234.key -c "<UUID>" -u -e "<ECID"

And with that passphrase it is now possible to decrypt the partition in another system, like I wanted.

I also tested the massflash with the --generic-passphrase parameter and it worked perfectly!

I have a last question: when using a generic passphrase, the key is replaced with a unique one on first boot. But if instead the generic was not replaced on first boot, are there any security risks other than the passphrase being the same for multiple devices?

[JerryChang]

hello louis46,

please refer to The Threat Model.
the data cannot be exposed even unmounted the disk to attack physically.
re-cap as below.

The purpose of disk encryption is to prevent an attack from stealing or tampering with data on the disk. Even if the disk is physically unmounted (or, in the case of an internal device such as an eMMC, is removed from the device), the data cannot be exposed.

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 threaten assumption is that because the person does not have access to the device, they can’t possibly know the ECID.

anyways,
the security of your device depends on how securely you keep the key files.