Jetpack 5.1.1 disk encryption with user-generated ekb.key

Hi!

I’m trying to use NVMe disk encryption without fusing my own KEK2 key on Jetson Xavier NX Devkit.

I’m using script from optee samples to generate bootloader/eks_t194.img and ekb.key:

#!/bin/bash

# [T194 example]
# This is default KEK2 root key for unfused board
echo "00000000000000000000000000000000" > kek2.key

# This is the fixed vector for deriving EKB root key from fuse.
# It is expected user to replace the FV below with a user specific
# FV, and code the exact same user specific FV into OP-TEE.
echo "bad66eb4484983684b992fe54a648bb8" > fv_ekb_t194

# Generate user-defined symmetric key files
# openssl rand -rand /dev/urandom -hex 16 > sym_t194.key
# openssl rand -rand /dev/urandom -hex 16 > sym2_t194.key
#echo "00000000000000000000000000000000" > sym_t194.key
#echo "00000000000000000000000000000000" > sym2_t194.key
echo "11111111111111111111111111111111" > sym_t194.key
echo "11111111111111111111111111111111" > sym2_t194.key

python3 gen_ekb.py -chip t194 -kek2_key kek2.key \
        -fv fv_ekb_t194 \
        -in_sym_key sym_t194.key \
        -in_sym_key2 sym2_t194.key \
        -out eks_t194.img

The following command is used to flash device:

ROOTFS_ENC=1 tools/kernel_flash/l4t_initrd_flash.sh -c tools/kernel_flash/flash_l4t_nvme_rootfs_enc.xml --external-device nvme0n1 --external-only -p "-i ekb.key" jetson-xavier-nx-devkit-emmc external

If I use all 0’s for user-defined symmetric keys, everything goes fine, device is flashed succesfully and boots with encrypted root unlocked and mounted.
But if I use anything else for user-defined keys (replacing bootloader/eks_t194.img and ekb.key with generated ones), device is flashed fine, but nvluks-srv-app fails to unlock the rootfs with error No key found for this passphrase

What I am dong wrong here? Is it possible to use random user-defined symmetric keys without fusing device?

please see-also Topic 238756.

Hi Jerry,

I’m also interested in this topic. If you don’t mind, could you answer “Is it possible to use user-defined symmetric keys (other than all zeros) without fusing (kek2) on the device?”

Thank you!

had you fuse the target?
by default it’s using all zero as KEK2 root key for unfused board.
i.e. # echo "00000000000000000000000000000000" > kek2.key

FYI,
KEK it’s the Key for Encryption Key.
they are keys to encrypt your keys. KEK0, KEK1, KEK2 are 128-bit key files; KEK256 is 256-bit key file.
please use the commands, --KEK* to determine which key encryption key you’re going to fused.

Hey @JerryChang,

Thanks for the response! We understand that by default it’s using all zeros as KEK2 root key for an unfused board. And yes KEK is used to encrypt keys.

But we would still like to get a clarification on whether we have to fuse the target first before we can use user-defined symmetric keys that are not all zeros.

And @evchupriyanov, sorry didn’t mean to steal your post.

Thanks

hello elton3,

the only way to put the keys into the target is fuse burning.
please note that, Burning a fuse (changing the value of a fuse from 0 to 1) is non-reversible.

Hi, @JerryChang

So what will be the correct procedure of flashing/fusing eks_t194.img generated by gen-ekb.py script, so we can have our own luks encryption keys?

hello evchupriyanov,

here’re roughly steps for your reference,

(1) you may put the device into recovery, execute below to create the base image.
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --network usb0 --no-flash jetson-xavier-nx-devkit-emmc internal.

(2) then, please replace the default eks imagem i.e. eks_t194.img with yours.
please using the same key with, -i ekb.key to generate an image blob.
$ sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh -i ./ekb.key --network usb0 --no-flash --external-device nvme0n1p1 -c ./tools/kernel_flash/flash_l4t_nvme_rootfs_enc.xml --external-only --append jetson-xavier-nx-devkit-emmc external

(3) finally, put the device into recovery and then run below.
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --network usb0

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.