Orin NX: Is It Bricked After Fusing an ECDSA P-256 Key Hash with a BootSecurityInfo Value of 0x20b?

[pinyu.wang]

As mentioned in the title, on Orin NX, I fused an ECDSA P-256 Key with a BootSecurityInfo value of 0x20b, which is intended for an ECDSA P-521 Key. After that, I was not able to perform ./odmfuseread.sh.

I know there are still two public key hash fuses that can be burned, but I’m not sure if I can burn them again because the wrong key has already been burned.

Here is the configuration that I used to burn the wrong keys:

wrong_fuse.conf

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="PublicKeyHash" size="64" value="a ECSDA P-256 Key Hash"/>
    <fuse name="SecureBootKey" size="32" value="sbk generated from openssl rand -hex (32bytes)"/>
    <fuse name="OemK1" size="32" value="OemK1 generated from openssl rand -hex (32bytes)"/>
    <fuse name="BootSecurityInfo" size="4" value="0x20b"/>
</genericfuse>

This is the command I used to burn:

sudo ./odmfuse.sh -X wrong_fuse.conf -i 0x23 jetson-orin-nano-devkit

This is the command I used to read the fuse:

sudo ./odmfuseread.sh -i 0x23 -k ecdsa_256.pem -S xxx.sbk jetson-orin-nano-devkit

Here is the partial odmfuseread.sh log

[   0.0091 ] Reading fuses
[   0.0096 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[   0.0101 ] File rcm_state open failed
[   0.0101 ] ERROR: failed to read rcm_state
...
[   0.3335 ] tegrasign_v3.py --key /home/intsa/keys/AC0231.pem0 --list mb1_bct_MB1_aligned_sigheader_encrypt.bct_list.xml --pubkeyhash pub_key.key --sha sha512
[   0.3355 ] Valid ECC key
[   0.3413 ] Saving public key in pub_key.key for ECC
[   0.3413 ] tegrahost_v2 --chip 0x23 0 --pubkeyhash pub_key.key --updatesigheader mb1_bct_MB1_aligned_sigheader_encrypt.bct.signed mb1_bct_MB1_aligned_sigheader_encrypt.bct.sig oem-ecc
[   0.3420 ] Info: Skip generating mem_bct because sdram_config is not defined
[   0.3420 ] Info: Skip generating mem_bct because sdram_config is not defined
[   0.3420 ] Copying signatures
[   0.3424 ] tegrahost_v2 --chip 0x23 0 --partitionlayout readinfo_t234_min_prod.xml.bin --updatesig images_list_signed.xml --pubkeyhash pub_key.key
[   0.3447 ] mb1_t234_prod_aligned_sigheader_encrypt.bin.signed filename is from images_list
[   0.3448 ] psc_bl1_t234_prod_aligned_sigheader_encrypt.bin.signed filename is from images_list
[   0.3448 ] Boot Rom communication
[   0.3452 ] 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.signed
[   0.3456 ] BR_CID: 0xAB012344705DE3C94000000010028280
[   0.3764 ] Sending bct_br
[   0.4196 ] 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.signed
[  10.5865 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[  10.5920 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[  10.5973 ] Retrieving board information
[  10.6000 ] tegrarcm_v2 --chip 0x23 0 --oem platformdetails chip chip_info.bin
[  10.6029 ] Retrieving EEPROM data
[  10.6030 ] tegrarcm_v2 --oem platformdetails eeprom cvm /home/intsa/JP60_PROD/Linux_for_Tegra/bootloader/cvm.bin --chip 0x23 0
[  10.6076 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[  10.6111 ] tegrarcm_v2 --chip 0x23 0 --ismb2applet
[  10.6126 ] Dumping customer Info
[  10.6143 ] tegrarcm_v2 --chip 0x23 0 --oem dump bct tmp.bct
[  10.6192 ] tegrabct_v2 --brbct tmp.bct --chip 0x23 0 --custinfo /home/intsa/JP60_PROD/Linux_for_Tegra/bootloader/custinfo_out.bin
[  10.6216 ] File tmp.bct open failed
Error: Return value 19
Command tegrabct_v2 --brbct tmp.bct --chip 0x23 0 --custinfo /home/intsa/JP60_PROD/Linux_for_Tegra/bootloader/custinfo_out.bin
Reading board information failed.

[JerryChang]

hello pinyu.wang,

@pinyu.wang

because the wrong key has already been burned.

what did you meant a wrong key has already been burned?
please aware that fuse burning operations cannot be reversed.

[pinyu.wang]

Sorry for the misleading language.

What I meant is that I mistakenly burned the first publicKeyHash fuse with the wrong key (ECDSA P-256). It is the wrong key because BootSecurityInfo was set to 0x20b, which is intended for ECDSA P-521.

I would like to know if I can

1. read the burned fuse keys
2. burn the second publicKeyHash fuse with a ECDSA P-521 key hash

after having fused the first one incorrectly.

[JerryChang]

hello pinyu.wang,

I see, you’ve given P256 keys but setting authentication scheme as P521.
for instance,

Bits [2:0] mapped to Secure Boot Authentication Scheme,
where:
...
010b: ECDSA P-256 Curve
011b: ECDSA P-521-Curve

do you know the detail SKUs of your target?
let’s try fuse read by adding SKIP_EEPROM_CHECK to skip eeprom check,
for instance,
$ sudo SKIP_EEPROM_CHECK=1 BOARDID=3767 FAB=300 BOARDSKU=0001 BOARDREV=N.2 CHIP_SKU=00:00:00:D4 ./odmfuseread.sh -i 0x23 -k PKC.key -S SBK.key jetson-orin-nano-devkit

[pinyu.wang]

Hi JerryChang,

I have two identical devices, and I found these lines in the log when I flashed the brand new (non-burnt) devices:

Board ID(3767) version(300) sku(0000) revision(P.1)
Chip SKU(00:00:00:D3) ramcode(00:00:00:00) fuselevel(fuselevel_production) board_FAB(300)

Both commands were executed on the burnt device and yielded the same results (failed to read rcm_state, timeout in USB write, File tmp.bct open failed):

sudo SKIP_EEPROM_CHECK=1 BOARDID=3767 FAB=300 BOARDSKU=0001 BOARDREV=N.2 CHIP_SKU=00:00:00:D4 ./odmfuseread.sh -i 0x23 -k PKC.key -S SBK.key jetson-orin-nano-devkit

sudo SKIP_EEPROM_CHECK=1 BOARDID=3767 FAB=300 BOARDSKU=0000 BOARDREV=P.1 CHIP_SKU=00:00:00:D3 ./odmfuseread.sh -i 0x23 -k PKC.key -S SBK.key jetson-orin-nano-devkit

[JerryChang]

hello pinyu.wang,

I’m afraid it may not recover since you’ve given P256 keys but setting authentication scheme as P521.
anyways, let me check this internally for confirmation.

[pinyu.wang]

Hi Jerry,

I appreciate you checking this internally for confirmation. Please let me know if there is any possible solution or further steps I can take.

Thank you again for your assistance.

[JerryChang]

hello pinyu.wang,

please give it a try to burn the other 2 PKCs.
you may see-also Revocation of the PKC Keys for verification.

[pinyu.wang]

Hi Jerry,

I’m afraid to inform you that these methods aren’t working. Here are the reasons:

1. Burning the other two PKCs requires specifying the incorrect burnt key. I burned and got ERROR: might be timeout in USB write again.
   

   

2. For the revocation process, we need to use the second or third PKCs to flash the revocation DTS. However, my board doesn’t have either the second or the third PKC.
   

   

If it is bricked, I’ll take responsibility for it.
Thank you.

[JerryChang]

hello pinyu.wang,

just for confirmation,
you should use fuse_config for adding PKC-1 and PKC-2 keys, and the odmfuse command-line to use -k options to load your P256 key.

[pinyu.wang]

Hello Jerry,

I did execute the command as you mentioned -k p256.key, but I am still getting the error: “ERROR: might be timeout in USB write.”

I’m not sure if the wrong key is causing the “ERROR: might be timeout in USB write,” but I think it might be the reason.

[JerryChang]

hello pinyu.wang,

it should due to you’ve setting authentication scheme as P521.
there’s no way back as fuse burning operations cannot be reversed.