JetPack 6.2.1 Disk Encryption
I’m trying to setup a system where, if someone gets hold of the system cannot read the content of the hard drive without extraordinary means. I don’t mind if someone can flash the system with new software. I’m using a guide from forecr.io to get started: JetPack-6.x Installation for DSBOARD-ORNXS which contains the first steps:
sudo ./tools/l4t_flash_prerequisites.sh
sudo ./apply_binaries.sh
cd ..
sudo ./replace_bsp_files.sh
cd Linux_for_Tegra/
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” --showlogs --network usb0 jetson-orin-nano-devkit internal
This works fine and I have an unecrypted system running.
I have tried following this guide:
docs_nvidia_com /jetson/archives/r38.2.1/DeveloperGuide/SD/Security/DiskEncryption.html
here is my interpretation of it: (I’ll write it as a guide as it seems likely someone like me will try to search for these steps in a near future and hopefully find this and then the answer to how to actually do it.)
Redo the partition table tools/kernel_flash/flash_l4t_external.xml:
(This is straight from the DiskEncryption.html-guide)
<partition name="APP" id="1" type="data">
<allocation_policy> sequential </allocation_policy>
<filesystem_type> basic </filesystem_type>
<size> 419430400 </size>
<file_system_attribute> 0 </file_system_attribute>
<allocation_attribute> 0x8 </allocation_attribute>
<percent_reserved> 0 </percent_reserved>
<align_boundary> 16384 </align_boundary>
<unique_guid> APPUUID </unique_guid>
<filename> system_boot.img </filename>
<description> **Required.** Contains the boot partition. This partition must be defined
after `primary_GPT` so that it can be accessed as the fixed known special device
`/dev/mmcblk0p1`. </description>
</partition>
<partition name="APP_ENC" id="2" type="data" encrypted="true" reencrypt="false">
<allocation_policy> sequential </allocation_policy>
<filesystem_type> basic </filesystem_type>
<size> APP_ENC_SIZE </size>
<file_system_attribute> 0 </file_system_attribute>
<allocation_attribute> 0x8 </allocation_attribute>
<percent_reserved> 0 </percent_reserved>
<align_boundary> 16384 </align_boundary>
<unique_guid> APP_ENC_UUID </unique_guid>
<filename> system_root_encrypted.img </filename>
<description> **Required.** Contains the encrypted root partition("/"). </description>
</partition>
I had to change a different partition to id=”3” as it previously already had one with id=”2”.
Then download “Driver Package (BSP) Sources” from a version here: [u]https://developer.nvidia.com/embedded/jetson-linux-archive[/u]
In that archive there is a “nvidia-jetson-optee-source” folder. Extract it somewhere and go to the folder optee/samples/hwkey-agent/host/tool/gen_ekb/
In that folder there is an example.sh file. Uncomment all key “generations” which just set them to zeroes. (I’m guessing this is what is being referred to as “Generic Keys” in the DiskEncryption.html-guide, but I’m not sure)
Try to run the example.sh to generate the zero-keys-eks-img
sh example.sh
It will fail and you have to create a python venv and activate it and pip install a bunch of packages. Then run it again.
Copy eks_t234.img to Linux_for_Tegra/bootloader/
Copy sym2_t234.key to Linux_for_Tegra/disc_enc.key
Then run:
sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh -i disc_enc.key -p "--generic-passphrase" --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --showlogs --network usb0 jetson-orin-nano-devkit internal
Which is the same as the Forecr guide with added ROOTFS_ENC=1 and -i disc_enc.key -p “–generic-passphrase” from the DiskEncryption.html-guide
That works. The system starts and seems to be encrypted (with keys being all zeroes, but still).
The next step fails, so stop following this guide if you are reading this here.
Now I tried changing the example.sh to do openssl key generation instead and then flashing that. This resulted in a system with these in the boot log:
No key available with this passphrase.
/bin/bash: line1: crypt_UDA: command not found
ERROR: fail to unlock the encrypted dev /dev/nvme….
I’m guessing that just changing the keys from zeroes to random numbers was not the right approach but I can’t understand this part of the guide, which I think I should follow: DiskEcryption.html.guide→ Replacing the Generic Key with the Per-device Unique Key at First Boot
But the first step of that is “To replace generic key with a per-device unique key, run the init script in the initrd:”. Then no clue to what that means. I have found that there is an init script in the bootloader/l4t_initrd.img. Does that mean that I should encrypt the device with the zeroes-key and then run “init” on target? If that is the case, why the hassle of generating the eks_t234.img with just zeros if everyone needs that anyway. So that can’t be the way.
My questions are:
Is generic keys the zero keys?
Have I managed to get to “**Replacing the Generic Key with the Per-device Unique Key at First Boot”?
**
if yes,
Does anyone have more clues on how to do the rest of the steps?
Related question:
Why is the DiskEncryption.html-guide is so vague on what to do? Why doesn’t it say what to do with an example instead of giving a clue on what should happen next. Following that guide for the first time is very hard.
And so sorry for obfuscating all links. I’m not allowed to put more than 4 links in the post and the system automatically finds links and makes them links so I had to obfuscate them… and there is no way to find what is made into links and unlink them.