UEFI Secureboot with disk encryption

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
, ,
45

hello JulienMoinard,

it’s failure when EKB extraction, the error is due to mismatch content header.

E/TC:0 0 ekb_extraction_process:227 Bad parameter: eks image not correct
E/TC:0 0 jetson_user_key_pta_init:801 jetson_user_key_pta_init: Failed (ffff0006).
E/TC:0 0 call_initcalls:43 Initcall __text_start + 0x000c3120 failed`

there’re several test approaches you may give them a try…
(1) could you please double check eks_t194.img has updated correctly.
(2) please try not using user_key.
(3) is it possible to validate with r35.3.1 release version?

46

Hi,

Like you can see in my previous post I have the same issue on r35.3.1. I not recompile UEFI I use your last release (r35.3.1) instead.

When you tell me not using user_key I already done that on my previous post but I need user_key to generate EKS ? So user_key is in eks but not provided in flash command ?

I update eks_t194.img like I update eks.img for Jetpack 4.6.3 I don’t understand.

Best regards,

47

Hello,

This doesn’t work for me on l4t-r35.3.1.

Could you share with us all information with example keys to use with gen_ekb.py please ?

Best regards,
Julien.

48

hello JulienMoinard,

it turns out there’s an issue with --user_key.
FYI,
the option --user_key is only supported with JP-4.x to encrypt/decrypt user images, such as kernel/kernel-dtb.
however, this options is no longer supported with JP-5.x, it’s replaced by --uefi-enc options, and it’ll be available by the next JP-5 release, i.e. Jetpack-5.1.2 release version.

back to your original question…
the root cause might be the EKS image is not correctly decrypted.
you’ll need to check kek2.key which is used to encrypt EKS image.
hence,
please check… whether the KEK2 key is burned into the target.
a) If yes…, could you please check whether the burned KEK2 key is the same as the key2.key used in generating eks image?
b) If no…, could you please check whether the key2.key includes zeros key.

49

Hello JerryChang,

Thank you so much for your answer about --user_key I need to wait for your next release , do you have any lead time ?

Your right, I will double check by kek2 key.

Do you think I need to use last odmfuse from jetpack 5 to fuse a new board to ensure that the format / bit order of the key is ok ? Or you don’t change anything with odmfuse in the last 2 years ?

In another word can I use an old already fused board with old odmfuse script to flash with new jetpack 5 ?

I have so many already fused board so I your change something probably I can’t use anymore my old SOM already fused ?

Best regards,

50

hello JulienMoinard,

I don’t have solid schedule for next JP-5 release, sorry for that.
please expect it may not be available soon since JP-5.1.1 has just public in late March.

>> In another word can I use an old already fused board with old odmfuse script to flash with new jetpack 5 ?
>>I have so many already fused board so I your change something probably I can’t use anymore my old SOM already fused

as mentioned above, you should avoid using --user_key for JP-5.
as long as all fused/flashing keys are match, image flashing should also works.
furthermore, we had also confirm with the device that fused before (in JP-4). and we verify with flashing JP-5 image to it.

51

Hi Julien,

I’ve successfully enabled diskencryption with uefi secureboot on this release, however Im using a Xavier AGX…
As JerryChang already mentioned, --user-key is not support on this release. See my post: UEFI Secureboot JP 5.1.1 L4T 35.3.1 - #19 by riboyama

I took a quick look at the Jetpack 4.5 docs, it seems that your board is fused correctly and that your fuses are compatible with this release. However, I’m no expert so take this with a grain of salt.

Generating eks_t194.img:

python3 gen_ekb.py -chip t194 -kek2_key kek2.key \
        -fv fv_ekb_t194.key \
        -in_sym_key sym_t194.key \
        -in_sym_key2 sym2_t194.key \
        -out eks_t194.img
  • The fv_ekb_194.key should be bad66eb4484983684b992fe54a648bb8, unless you have recompiled the optee sources with another key.
  • ---user-key is unsupported. sym_t194.key is the user_key. So sym_t194.key must be all zero’s: 00000000000000000000000000000000
  • sym2_t194.key is your rootfs encryption key. It will also be used for flash.sh -i sym2_t194.key
  • Copy eks_t194.img to Linux_for_Tegra/bootloader/eks_t194.img

Flashing:

The flash.sh script is broken in this release if you enable Secureboot and Diskencryption together when using flash.sh See my post for the fix.

After you’ve edited disk_encryption_helper.func you can now flash:

The correct flash command for PKC + SBK + DiskEncryption + UEFI Secureboot (AGX devkit) is sudo ROOTFS_ENC=1 ./flash.sh --uefi-keys uefi_keys/uefi_keys.conf -i $sym2file -u $keyfile -v $sbkfile jetson-agx-xavier-devkit mmcblk0p1

On first boot you will see that dbx and dbt cannot be enrolled, this is OK.
On reboot you should see Skipped - USER_MODE, this means that the uefi secureboot is enabled.

52

Hi Riboyama,

Thank you so much for your help for UEFI it is works well except some warning message that I can remove by myself if I recompile uefi binary. So thank again.

For my issue with EKS you answer some question I have, user key need to be 0 to be used with gen_ekb. But I have always an issue.

b) If no…, could you please check whether the key2.key includes zeros key.

I try without SBK and PKC by using KEK2 to 0 and user_key to 0 on unfused board :

lootus@ubuntu:/local/dev/photon-5.1/nvidia_sdk/JetPack_5.1.1/Linux_for_Tegra/keys$ sudo python3 gen_ekb.py -kek2_key key2.key -fv fv_ekb -in_sym_key user.key -in_sym_key2 disk.key -out ../bootloader/eks_t194.img
lootus@ubuntu:/local/dev/photon-5.1/nvidia_sdk/JetPack_5.1.1/Linux_for_Tegra/keys$ cat key2.key 
00000000000000000000000000000000
lootus@ubuntu:/local/dev/photon-5.1/nvidia_sdk/JetPack_5.1.1/Linux_for_Tegra/keys$ cat user.key 
00000000000000000000000000000000
lootus@ubuntu:/local/dev/photon-5.1/nvidia_sdk/JetPack_5.1.1/Linux_for_Tegra/keys$ cat disk.key 
7B233A2F57E7EFA655A6F7B963E8EBCC
lootus@ubuntu:/local/dev/photon-5.1/nvidia_sdk/JetPack_5.1.1/Linux_for_Tegra/keys$ cat fv_ekb
bad66eb4484983684b992fe54a648bb8

sudo python3 gen_ekb.py -kek2_key key2.key -fv fv_ekb -in_sym_key user.key -in_sym_key2 disk.key -out ../bootloader/eks_t194.img

lootus@ubuntu:/local/dev/photon-5.1/nvidia_sdk/JetPack_5.1.1/Linux_for_Tegra$ sudo ROOTFS_ENC=1 ./flash.sh -i keys/disk.key jetson-xavier-nx-devkit-emmc mmcblk0p1
[sudo] Mot de passe de lootus : 
###############################################################################
# L4T BSP Information:
# R35 , REVISION: 3.1
# User release: 0.0
###############################################################################
Change device boot from mmcblk0p1 to internal
# Target Board Information:
# Name: jetson-xavier-nx-devkit-emmc, Board Family: t186ref, SoC: Tegra 194, 
# OpMode: production, Boot Authentication: NS, 
# Disk encryption: enabled ,
###############################################################################
copying soft_fuses(/local/dev/photon-5.1/nvidia_sdk/JetPack_5.1.1/Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-soft-fuses-l4t.cfg)... done.
./tegraflash.py --chip 0x19 --applet "/local/dev/photon-5.1/nvidia_sdk/JetPack_5.1.1/Linux_for_Tegra/bootloader/mb1_t194_prod.bin" --skipuid --soft_fuses tegra194-mb1-soft-fuses-l4t.cfg --bins "mb2_applet nvtboot_applet_t194.bin" --cmd "dump eeprom boardinfo cvm.bin;reboot recovery" 
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands

] ▒▒: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
E/TC:0 0 ekb_extraction_process:227 Bad parameter: eks image not correct
E/TC:0 0 jetson_user_key_pta_init:801 jetson_user_key_pta_init: Failed (ffff0006).
E/TC:0 0 call_initcalls:43 Initcall __text_start + 0x000c3240 failed

I don’t understand this kek2.key work on jetpack 4 , I try to change kek2.key on jetpack 4 by changing a byte and of course It doesn’t work with a similar issue so my kek2 key on jetpack 4 is right but the same for jetpack 5 . I am so confused

So you seems right my kek2 key is not the right one . Are your really sure that an old board fused witht odmfuse from jetpack 4 is not an issue to use this board fused to be usable with jetpack 5 ?
Any change on hardware SOM that explain that ?

I am crazy !

Best julien.

53

I guess you could check the odmfuse config on your Jetpack 4.x to see if the key matches with your fuses.
Can you try copying the eks_t194.img with cp, instead of using --out ../bootloader/eks_t194.img maybe the tool doesn’t overwrite the image correctly?

python3 gen_ekb.py -kek2_key key2.key -fv fv_ekb -in_sym_key user.key -in_sym_key2 disk.key -out eks_t194.img
cp eks_t194.img Linux_for_Tegra/bootloader/eks_t194.img
54

Hi,

Do you have an idea how to check that keys match with fuse ?

Because in Jetpack 4 gen_ekb work well and linux boot properly with disk encryption.
But not in Jetpack 5 but if it is works well at your side , I make a mistake probably ?

sudo python3 gen_ekb.py -kek2_key key2.key -fv fv_ekb -in_sym_key user.key -in_sym_key2 disk.key -out eks_t194.img

lootus@ubuntu:/local/dev/photon-5.1/nvidia_sdk/JetPack_5.1.1/Linux_for_Tegra/bootloader$ cp keys/eks_t194.img bootloader/eks_t194.img

As you can see, file has been updated before upgrade

vmware_hyd5E9BBhs
vmware_hyd5E9BBhs910×55 15.1 KB

But after flash , my eks_t194.img file was updated and do you know why ? for signing probably but sign is in another file ?

vmware_qwPPX2khEo
vmware_qwPPX2khEo913×73 19.5 KB

Do you have an example to use ODM fuse compare with mine ?

Best regards,
Julien.

55

Hi,

I just try with a new board and fuse with known keys but I have the same issue.


[0002.760] I> EKB detected (length: 0x410) @ VA:0x52709400
[0002.761] I> Setting EKB blob info to OPTEE dtb finished.
▒▒NOTICE:  BL31: v2.6(release):07eea4970
NOTICE:  BL31: Built : 07:55:15, Mar 19 2023
I/TC:
I/TC: Non-secure external DT found
I/TC: OP-TEE version: 3.19 (gcc version 9.3.0 (Buildroot 2020.08)) #2 Sun Mar 19 15:02:42 UTC 2023 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
E/TC:0 0 ekb_extraction_process:227 Bad parameter: eks image not correct
E/TC:0 0 jetson_user_key_pta_init:801 jetson_user_key_pta_init: Failed (ffff0006).
E/TC:0 0 call_initcalls:43 Initcall __text_start + 0x000c3240 failed
I/TC: Primary CPU switching to normal world boot
▒▒

Sombody can confirm me that encryption disk work on JetPack 5.1.1 with a Jetson Nx ?

It is very important for me to be able to load this eks img

Best regards,
Julien.

56

please refer to previous comment, post #29. disk encryption works normally with l4t-r35.3.1 on Xavier NX eMMC.

what’s the keys you’re used for a new board?

to clarity,
if you’re used an unfused board, that’s zero key (i.e. all zero kek2.key) to encrypt EKS image.
the key for decrypting kernel/kernel-dtb, and the key for disk encryption that are all stored in the EKS.

57

and… where this script file gen_ekb.py came from? are you using the one from JP-5.1.1 public release package?
i.e. r35.3.1/Linux_for_Tegra/source/public/atf_and_optee/optee/samples/hwkey-agent/host/tool/gen_ekb/gen_ekb.py

58

Hi Julien,

You’re missing the -chip t194 parameter when using gen_ekb.py.
So in your case it should be sudo python3 gen_ekb.py -chip t194 -kek2_key key2.key -fv fv_ekb -in_sym_key user.key -in_sym_key2 disk.key -out eks_t194.img

59

Hi,
I missing this time the -chip t194 but by default it already t194 so It change nothing.

I retry all and post all step to be sure.

Best regards,

60

Hello,

It is works fine now.
My gen_ekb was not the last one.

Thank you for your support.

61

thanks for confirmation, glad to know it works.
BTW, please see-also comment #48, please avoid using --user_key for JP-5.x release version.

1 Like
63

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