Jetson Orin Nano SBKPKC Fused USB_TIMEOUT Cannot Flash/Read Etc

Hi forum,

I generated keys and fused my Jetson Orin Nano Devkit using r36.4.4 with PKC, SBK, OEMK1, BootSecurityInfo and SecurityMode using the documented process - xml and commands below. My aim is to have a SBK secured board with encrypted external fs.

My board fused successfully - I burned all fuses at once - I can see in log output it is fused as expected; however now it doesnt accept the same keys to let me conduct any other process - I get the timeout in USB write error associated with failed key-check:

[   1.1197 ] BR_CID: 0xEB01<REDACTED>
[   1.1459 ] Sending bct_br
[   1.1897 ] Sending mb1
[   1.1904 ] ERROR: might be timeout in USB write.
Error: Return value 3

I could use some help please:

  • I’m certain the keys are correct (pkc is rsa3072) - what could be causing the failed auth checks?
  • How I can recover/flash the board (I have all the keys I fused it with)?
  • How I can understand what I did wrong to brick it / what I missed in the docs?
  • I failed to include fuse PscOdmStatic: 0x60 on the first run - is this enough to brick the board?

Things I’ve tried (all give the same error as above):

  • flash.sh --readinfo -u rsa.pem -v sbk.words
  • flash.sh --readinfo -u rsa.pem -v sbk.words_spaced
  • flash.sh --readinfo -u rsa.pem -v sbk.key
  • flash.sh --readinfo -u rsa.pem -v sbk.fuse
  • l4t_initrd_flash.sh - with -u and -v as above
  • odmfuse.sh with -k rsa.pem and -S sbk.words, sbk.words_spaced, sbk.key, sbk.fuse
  • odmfuseread.sh - as above
  • Fresh Linux_For_tegra tree
  • Keys are outside tree
  • Device wont boot to linux - cant use nv_read_fuse.sh
  • Tried second fuse-burn to add PscOdmStatic - but same auth error denies it.

fuse_config.xml

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="PublicKeyHash" size="64" value="0x<REDACTED>"/>
    <fuse name="SecureBootKey" size="32" value="<OMITTED 0x in this value as per docs>"/>
    <fuse name="OemK1" size="32" value="<OMITTED 0x in this value as per docs>"/>
    <fuse name="BootSecurityInfo" size="4" value="0x3EB"/>
    <fuse name="PscOdmStatic" size="4" value="0x60"/>
    <fuse name="SecurityMode" size="4" value="0x1"/>
</genericfuse>

Fusing Log Snippet - showing zeroed / factory keys before fusing

Fuse reading is done. The fuse values have been saved in: <redacted>
PublicKeyHash: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
BootSecurityInfo: 00000000
ArmJtagDisable: 00000000
SecurityMode: 00000000
SwReserved: 00000000
DebugAuthentication: 00000000
OdmId: 0000000000000000
OdmLock: 00000000
ReservedOdm0: 00000000
ReservedOdm1: 00000000
ReservedOdm2: 00000000
ReservedOdm3: 00000000
ReservedOdm4: 00000000
ReservedOdm5: 00000000
ReservedOdm6: 00000000
ReservedOdm7: 00000000

...

MagicId=0x45535546 version=0x1
node: name=PublicKeyHash size=64
type 0x2a size 64 
value=0x<REDACTED>
node: name=SecureBootKey size=32
type 0x66 size 32 
  value=<REDACTED>
node: name=OemK1 size=32
type 0x6a size 32 
  value=<REDACTED>
node: name=BootSecurityInfo size=4
type 0x0 size 4 
  value=0x3EB
node: name=SecurityMode size=4
type 0x1d size 4 
  value=0x1
done.
size of FSKP binary 386320
size of Fuse Blob 216
File saved as fskp_t234_updated.bin
done.

Host Setup:

  • Native Ubuntu 20.04
  • USB Autosuspend -1 set
  • Many different cables tried - 3.0 and 2.0

Thanks for any help!

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

The issue you’re experiencing with your Jetson Orin NX Devkit is likely due to the fact that you’ve fused the board with PKC, SBK, OEMK1, BootSecurityInfo, and SecurityMode, but you’re still trying to use the same keys to conduct other processes.

When you fuse a board with these security features, it changes the way the board authenticates and verifies the keys. In your case, you’ve successfully fused the board, but now it’s not accepting the same keys.

Here are a few possible reasons why you’re experiencing this issue:

  1. Key format: Make sure that your PKC key is in the correct format. The documentation specifies that the PKC key should be an RSA3072 key, but it’s possible that the key is not in the correct format or is not being read correctly.

  2. Key location: Ensure that the PKC key file and SBK key file are not placed under the bootloader directory. The documentation specifically warns against this.

  3. Fuse process: You mentioned that you didn’t include the fuse on the first run. This could be the cause of the issue. When you fuse a board, it’s essential to include all the necessary fuse options from the start.

  4. USB connection: Try using a different USB cable or port to rule out any issues with the USB connection.

  5. Autosuspend: You mentioned that you’ve set USB Autosuspend to 1. Try setting it to 0 to see if that resolves the issue.

To recover or reflash the board, you can try the following:

  1. Reflash the board: Use the flash.sh command with the -u and -v options to reflash the board with the correct keys.

  2. Use the nvreadfuse.sh command: This command can be used to read the fuse values from the board. This can help you understand what fuse values are currently set on the board.

  3. Use the odmfuse.sh command: This command can be used to set or clear fuse values on the board. Be careful when using this command, as setting or clearing the wrong fuse values can brick the board.

To understand what you did wrong and how to avoid it in the future, I recommend carefully reviewing the documentation and the commands you used to fuse the board. Make sure you understand the implications of each fuse option and how they interact with each other.

In comparison to other Jetson boards, the Orin NX has similar security features, but the specific fuse options and commands may differ. It’s essential to consult the documentation specific to your board to ensure you’re using the correct commands and options.

In summary, the issue you’re experiencing is likely due to the fact that you’ve fused the board with PKC, SBK, OEMK1, BootSecurityInfo, and SecurityMode, but you’re still trying to use the same keys to conduct other processes. To resolve the issue, try reflash the board with the correct keys, use the nvreadfuse.sh command to read the fuse values, and use the odmfuse.sh command to set or clear fuse values. Carefully review the documentation and the commands you used to fuse the board to understand what you did wrong and how to avoid it in the future.

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

hello snugger.49.arsenic,

let me have confirmation, did you follow Burn Fuses with the Fuse Configuration file to burn fuse with odmfuse.sh script file?
for instance, $ sudo ./odmfuse.sh -X <fuse_config> -i <chip_id> <target_config>

here’s one thing wrong with your BootSecurityInfo,
it’s the fuse variable for board authorization status, please refer to Jetson Orin Fuse Specification.
let me re-cap as below..

Boot Security Info
Bits interpreted by boot software with following mapping:
Bits [2:0] mapped to Secure Boot Authentication Scheme,
where:
000b: SHA2-512 Hash (not recommended)
001b: 3072-bit RSA
010b: ECDSA P-256 Curve
011b: ECDSA P-521-Curve

according to your settings, it’s defined the PKC as ECDSA P-521-Curve, which mismatch your actual burned PKC key (i.e. pkc is rsa3072).

Hi JerryChang,

Yes I used sudo ./odmfuse.sh -X <fuse_config> -i <chip_id> <target_config> command to burn the fuses.

Seems this board had different factory setting to our others - as per HW FAQ_31: BOOT_SECURITY_INFO was burned (by manufacturing) to 0x1E0 as default value

So to clarify - could you confirm the following?

So for boards with 0x000 default value for BOOT_SECURITY_INFO the following is valid (RSA, SBK, oemk1 for disk-enc):

<genericfuse MagicId="0x45535546" version="1.0.0">
<fuse name="PublicKeyHash" size="64"
value="0x<>"/>
<fuse name="SecureBootKey" size="32"
value="0x<>"/>
<fuse name="OemK1" size="32"
value="0x<>"/>
<fuse name="BootSecurityInfo" size="4"
value="0x209"/>
<fuse name="PscOdmStatic" size="4"
value="0x60"/>
</genericfuse>

and for boards with 0x1E0 from factory (0x209 OR factory 0x1E = 0x3E9); the following is valid (RSA, SBK, oemk1 for disk-enc):

<genericfuse MagicId="0x45535546" version="1.0.0">
<fuse name="PublicKeyHash" size="64"
value="0x<>"/>
<fuse name="SecureBootKey" size="32"
value="0x<>"/>
<fuse name="OemK1" size="32"
value="0x<>"/>
<fuse name="BootSecurityInfo" size="4"
value="0x3E9"/>
<fuse name="PscOdmStatic" size="4"
value="0x60"/>
</genericfuse>

Then final lock would burn (noting the recommendation to burn all fuses at once):

<fuse name="SecurityMode" size="4" value="0x1"/>

hello snugger.49.arsenic,

according to above, you may burn BOOT_SECURITY_INFO to 0x3E9 for all your boards. since bit:[8:4] were reserved has it’s not used by L4T.