Security Issues using the KEK2 default key

[evilinux]

When you are generating the EKB file, as explained in the guide, for unfused board we are using the KEK2 default key.

This is default KEK2 root key for unfused board
echo “00000000000000000000000000000000” > kek2_key

What can be the security issues related to this approach? (I am currently working on the disk encryption)

Can I use a custom KEK2 root key without fuse? As I understood, probably the EKB ciphertext will be encrypted with the zero-key (i.e., the kek2_key) and this one can be a security problem, but correct me if I am wrong.

[JerryChang]

PKC for sign:
if PKC is burned, then the KEYFILE users provide is for signing the images.

SBK for encryption:
if SBK is burned, then the SBKFILE users provide is for encrypting the images.

KEKs for encryption keys:
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.

[evilinux]

Hi Jerry, thanks a lot for your answer and for the details. But what if, if I use the default key (i.e., I leave the kek2 0 key for the unfused board) as I mentioned in the first post?

[JerryChang]

hello evilinux,

that’s by default using zero keys.
may I know the details of use-case and what’s security problem you’re mentioned.

[evilinux]

Ok. I am adopting the disk encryption key. In order to do that I generated the ekb file that contains the luks key. After that as the diagram depicted on the nvidia support guide, the ekb is encrypted by a derived key generated from the root key, and the root key is derived from the kek2 key that for unfused board is 0x000000.

Now, if I know that the master key kek2 adopted is zero (for unfused boards), an attacker can easily decrypt the content of the ekb file and extract the luks key that the user put there.

[JerryChang]

hello evilinux,

here’s the sample command-line to enable disk encryption.
$ sudo ROOTFS_ENC=1 ./flash.sh -i "./ekb.key" jetson-xavier-nx-devkit mmcblk0p1

you may see-also developer guide, for example, Tool for EKB Generation.
you should burn the EKB key you would like to used for disk encryption,
please execute the script file, gen_ekb.py to generate an image. also, as mentioned in developer guide, that sym2.key is equivalent to ekb.key in above sample flash commands.

BTW,
may I also know which Jetpack release you’re working with.
please check… $ cat /etc/nv_tegra_release

[evilinux]

HI Jerry, thanks again for the answer, but what I’m trying to highlight is another problem.
Take this picture as reference:

The ekb is encrypted by a derived key generated from the root key, and the root key is derived from the kek2 key. For unfused board is 0x000000000000000 (as default).

Now, if I know that the master key kek2 adopted is zero (for unfused boards), an attacker can easily re-generate the KEK2_RK and and the EKB_EK in order to extract the LUKS key that the user put in the EKB plaintext.

The problem is not a “programming/configuration” problem, but it is related on the security architecture and the mechanism related to the key derivation. If I am deriving a key from a default key for unfused board that is 0x00000000000000000, having or not the disk encryption could be potentially useless.

[JerryChang]

hello evilinux,

why don’t you fuse the target to enable Jetson security

[evilinux]

Yes. That one is the only solution to achieve the goal.