Burn ODM Key Valid fuse bit on PKCSBK fused Jetson orin nano

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
,
1

Hi everyone,

Platform: jetson-orin-nano-devkit
BSP: 36.4.0

I’m working on enabling secure boot on Jetson Orin Nano.

I have burn fuses in several steps:

  1. First PKC hash and Boot Security Info fuse bits [2:0] burned ECDSA P-521 is used
  2. Second PKC hash burned
  3. Secure boot key and Boot Security Info fuse bit [3] burned

Security mode is not burned

After that I have observed that device can start with signed but not encrypted boot images.
Flashing with signed and encrypted boot images fails.

Based on topic:

I have assumed that I need too burn Boot Security Info fuse bit [9].

But I have problem with burning this bit.

Commands that I use to burn that fuse:
sudo ./odmfuse.sh --test -X fuse_t234_jetson_oem_key_valid.xml -i 0x23 -k priv.pem -S sbk.key jetson-orin-nano-devkit
Security Boot Info value is OR-ed with 0x1e0 original value and I’m trying to burn 0x3eb value

Also I’m not able to read fuses in recovery mode with command:
sudo ./odmfuseread.sh -i 0x23 -k priv.pem -S sbk.key jetson-orin-nano-devkit
I’m able to read fuses from system using nv_fuse_read.sh and read values match already burn. Unfortunately Secure Boot Key is not read by nv_fuse_read.sh

What I have already tried without any success:

  • different host system Ubuntu 20.04, 22.04, 24.04
  • different sbk.key format
  • disabling USB autosuspend
  • compared readed eeprom and it matched
  • use BSP 36.4.4 version

I found topic with similar situation:

and Boot Security Info fuse bit [9] was burned successfully, but without explanation how it was done?

How I can fuse that extra bit?

2

*** Please note that this reply is generated by LLM automatically ***

To address your issue with burning the Boot Security Info fuse bit 9 on the Jetson Orin Nano, I’ll provide a comprehensive explanation of the process and compare the different approaches you’ve tried.

Understanding the Fuse Configuration

The Boot Security Info fuse bits are used to configure the secure boot settings on the Jetson device. The bits are defined as follows:

  • Bit 20: PKC hash and Boot Security Info fuse bits
  • Bit 3: Secure boot key and Boot Security Info fuse bit
  • Bit 9: Boot Security Info fuse bit (required for encrypted boot images)

Burning Fuses with the Fuse Configuration File

To burn fuses, you need to use the odmfuse.sh script with the -X option and provide the fuse configuration XML file. The command syntax is:

sudo ./odmfuse.sh -X <fuse_config> -i <chip_id> <target_config>

In your case, you need to burn the Boot Security Info fuse bit 9, which requires the fuse_config file to have the correct value.

Issue with Burning Boot Security Info Fuse Bit 9

You’ve tried burning the fuse bit 9 using the odmfuse.sh command, but it fails. You’ve also tried different host systems, sbkkey formats, and BSP versions without success.

Comparison with the Working Solution

The solution that worked for you was using the l4t_initrd_flash.sh script with the default EKB image. This script is used to flash the device with a signed and encrypted boot image. The command syntax is:

sudo ./l4t_initrd_flash.sh -u <pkc_key_file> -v <sbk_key_file> <device> mmcblk0p1

In this case, the script burns the Boot Security Info fuse bit 9 successfully without any additional explanation.

Key Differences

The key differences between the two approaches are:

  • The odmfuse.sh script is used to burn fuses directly, while the l4t_initrd_flash.sh script is used to flash the device with a signed and encrypted boot image.
  • The l4t_initrd_flash.sh script uses the default EKB image, which may contain the necessary configuration for burning the Boot Security Info fuse bit 9.

Recommendation

To burn the Boot Security Info fuse bit 9, you can try using the l4t_initrd_flash.sh script with the default EKB image. This approach has worked for you in the past, and it may be the simplest way to burn the fuse bit.

If you still want to use the odmfuse.sh script, you can try modifying the fuse configuration XML file to include the correct value for the Boot Security Info fuse bit 9. You can also try using a different BSP version or host system to see if it makes a difference.

Additional Tips

  • Make sure to use the correct fuse_config file and target_config for your device and carrier board.
  • Verify that the pkc_key_file and sbk_key_file are in the correct format and location.
  • Use the --showlogs option with the l4t_initrd_flash.sh script to see the detailed logs and identify any issues.

I hope this explanation helps you understand the issue and find a solution to burn the Boot Security Info fuse bit 9 on your Jetson Orin Nano.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

4

hello dominik.b.td,

let me have confirmation, you’re going to have partial fuse burning onto your target?
Orin series it support 3 PKC keys, it’s a must for fusing 3 PKC keys at the same type and strength.

it leaves the secure boot check disable if you did not burn security_mode fuse.

that’s expected, SBK key is omitted by fuse reading.
FYI, you’ll see board communication failure if you’re using mismatch key for fuse read.

5

hello JerryChange,

Yes, and some of fuses are already burn as desribed here:

Now I want to burn bit[9] in Boot Security Info fuse

PKC hash 1 is burn and is the same type and strength as first

I plan to burn security_mode fuse at the end as device that I use will be use only for development.

I double check used key hash and SBK key and it seems to be valid
FYI, I’m using first PKC hash during fuse burning tries

As I have burn PKC hash 0 and 1, can not burned PKC hash 2 be the reason why I can’t burn extra fuses now?

6

hello dominik.b.td,

firstly, let’s try adding 3rd PKC key.
please refer to developer guide, Burn Fuses with the Fuse Configuration file.
since your target was previously burned with a PKC keys, (i.e. pkc0.pem, pkc1.pem),
please give it a try to specify fuse_config.xml file which contain hash value of your 3rd PKC key, and running with odmfuse.sh command with -k option for burning additional fuse variable.
for instance, $ sudo ./odmfuse.sh -X <fuse_config.xml> -i 0x23 -k <pkc0.pem> <target_config>

it’s Bit [9] ODM Key Valid of FUSE_BOOT_SECURITY_INFO_0.
this need to enable when you’ve OEM_K1 burned into the target.

7

hello JerryChange,

I have tried with only public key hash 2 fuse
For this command:

I get Error: Either PKC or SBK key is not provided for SBK+PKC protected target board. what is expected as SBK fuse in already burn

When specifying sbk.key with -S sbk.key I have the same result as for trying to burn bit[9] in Boot Security Info fuse, communication error:

[   1.9903 ] Sending bct_br
[   1.9917 ] ERROR: might be timeout in USB write.
Error: Return value 3

and there is no output on serial console on device

8

hello dominik.b.td,

could you please share your fuse command-line and also fuse_config.xml for reference.

9

hello JerryChang,

Command use for fuse:

sudo ./odmfuse.sh --test -X fuse_t234_jetson_oem_key_valid.xml -i 0x23 -k priv.pem -S sbk.key jetson-orin-nano-devkit

I have tried without --test with the same result communication error

fuse_config.xml for burn bit[9] in Boot Security Info:

<genericfuse MagicId="0x45535546" version="2.0.0">
    <fuse name="BootSecurityInfo" size="4" value="0x3eb" />
</genericfuse>

fuse_config.xml for burn public key hash 2:

<genericfuse MagicId="0x45535546" version="2.0.0">
    <fuse name="PkcPubkeyHash2" size="64" value="0x<redacted>" />
</genericfuse>
10

hello dominik.b.td,

are you able to read the fuse info?
please try with flash script to execute the commands as below..
$ sudo ./flash.sh --read-info -u <pkc> -v <sbk> <target_conf> <rootdev>

11

hello JerryChange?

I’m not able to read fuse info using.
I have tried with sudo ./odmfuseread.sh -i 0x23 -k priv.pem -S sbk.key jetson-orin-nano-devkit
and

sudo ./flash.sh --read-info -u priv.pem -v sbk.key jetson-orin-nano-devkit internal in my case.

And for both commands I got below error:

[   1.0598 ] Sending bct_br
[   1.2641 ] Sending mb1
[   1.2647 ] ERROR: might be timeout in USB write.
Error: Return value 3
Command tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader_encrypt.bin.signed --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader_encrypt.bin.signed --download bct_mb1 mb1_bct_MB1_sigheader_encrypt.bct
Reading board information failed.
12

hello dominik.b.td,

that’s due to incorrect keys has used, please double check you’ve assign the same PKC/SBK keys.

13

hello JerryChang,

I think used keys are correct.
I have tried it multiple times, with different formats etc.
On one of the host system when I run sudo ./odmfuseread.sh -i 0x23 -k priv.pem -S sbk.key jetson-orin-nano-devkit command I can see last_boot_error 0x9bf5ee5b from MB1 is not zero, as when device is boot normally.
Where is log with error:

[0000.061] I> MB1 (version: 1.4.0.4-t234-54845784-e89ea9bc)
[0000.067] I> t234-A01-1-Silicon (0x12347) Prod
[0000.071] I> Boot-mode : Coldboot
[0000.074] I> Entry timestamp: 0x00000000
[0000.078] I> last_boot_error: 0x9bf5ee5b
[0000.082] I> BR-BCT: preprod_dev_sign: 0

Maybe that error code can be helpful

I wondering if it is not some corner case with these fuses burned:

<genericfuse MagicId="0x45535546" version="2.0.0">
    <fuse name="PublicKeyHash" size="64" value="<redacted>" />    # burn is step 1
    <fuse name="PublicKeyHash1" size="64" value="<redacted>" />   # burn is step 2 with use of private key PKC1
    <fuse name="SecureBootKey" size="32" value="<redacted>" />    # burn in step 3 with use of private key PKC1
    <fuse name="BootSecurityInfo" size="4" value="0x1eb" />       # burn in step 3 with use of private key PKC1
</genericfuse>

Maybe there is some corner case when PublicKeyHash2 is no burned and/or OptInEnable is not fused

14

hello dominik.b.td,

can this target boot into linux? please have an alternative way to execute nv_fuse_read.sh on the target for checking fuse variables.

15

hello JerryChange,

Yes. When reading fuses with nv_fuse_read.sh
public_key_hash, pk_h1 and boot security value(0x1eb) match burned values, but secure boot key is not returned by nv_fuse_read.sh

I have log from serial during secure boot key fuse burning and it’s value match key that I have used

16

hello dominik.b.td,

please double check your security_mode remain 0x0, right?

17

hello JerryChang,

Yes security_mode is 0x0.
Here is output from nv_fuse_read.sh

./nv_fuse_read.sh 
odm_lock: 0x00000000
revoke_pk_h0: 0x00000000
revoke_pk_h1: 0x00000000
optin_enable: 0x00000000
public_key_hash: 0x<redacted>>
boot_security_info: 0x000001eb
odmid: 0x0000000000000000
pk_h1: 0x<redacted>
pk_h2: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
security_mode: 0x00000000
reserved_odm2: 0x00000000
reserved_odm3: 0x00000000
reserved_odm0: 0x00000000
reserved_odm1: 0x00000000
reserved_odm6: 0x00000000
reserved_odm7: 0x00000000
reserved_odm4: 0x00000000
reserved_odm5: 0x00000000
odminfo: 0x00000000
system_fw_field_ratchet1: 0x00000000
system_fw_field_ratchet0: 0x00000000
system_fw_field_ratchet3: 0x00000000
system_fw_field_ratchet2: 0x00000000
ecid: 0x<redacted>
18

hello dominik.b.td,

thanks for sharing fuse info, I assume you’re able to re-flash this target, right?
if yes.. let’s try to burn bit-9 in boot security Info. you’ll also need to burn OEM keys (i.e. OEM_K1/K2, PscOdmStatic) since it’s the bit of ODM key valid.

FYI,
OEM_K1 is the root of trust of EKB, and it is used to derive the RPMB key too.
OEM_K2 is to derive the PV encryption key. If you don’t need to encrypt CPUBL with a PV key, you don’t need to care about OEM_K2.
For PscOdmStatic, we recommend burning it to 0x60, which sets the purpose of:
OEM_K1 to encryption. (see-also OEM_K1_PURPOSE=0x0)
OEM_K2 to KDK(key derive key) (see-also OEM_K2_PURPOSE=0x6)

19

hello JerryChang,

I cannot burn Bit 9 in Boot Security Info, which is why I raised this issue.
Do You have idea what can be the reason for this?

20

hello dominik.b.td,

those fuse variables within your previous post #9 looks incorrect.
you should at least add OEM_K1 to enable bit-9 of Boot Security Info.

21

hello JerryChange,

I have tried to burn only public key hash 2 with no success, so I think the problem is with burning extra fuses in general for my case not in lack of OEM_K1