Bricked a module burning OEM K1 fuse

[Shamino0]

I have been operating successfully using a module where the PKC Hash was fused. This was passed to odmfuse.sh, and worked fine:

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="PublicKeyHash" size="64" value="0x... redacted ..."/>
    <fuse name="BootSecurityInfo" size="4" value="0x1E1"/>
</genericfuse>

For the next step in getting secure boot working (OP-TEE and a custom EKB), I burned this via odmfuse.sh:

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="PublicKeyHash" size="64" value="0x... redacted ..."/>
    <fuse name="OemK1" size="32" value="0x... redacted ..."/>
    <fuse name="BootSecurityInfo" size="4" value="0x3E1"/>
</genericfuse>

The burning appears to have succeeded. The module's console output:

I> FSKP (version: 0.0.0.0-t234-54845784-0793996d)
I> t234-A01-1-Silicon (0x12347)
I> Emulation:
I> Entry timestamp: 0x014ee29c
I> Regular heap: [base:0x40040000, size:0x10000]
I> DMA heap: [base:0x173800000, size:0x800000]
I> Task: Crypto init
I> Task: Program CBB PCIE AMAP regions
I> Task: Burn fuses
I> Index : 1    PublicKeyHash    size: 64
I> Index : 2    OemK1    size: 32
I> Index : 3    BootSecurityInfo    size: 4
I> Fuse Blob found
I>
I> Burning fuses
I> 1. Start PublicKeyHash burn
I> Fuse is already burned with the same value
I> 1. PublicKeyHash burn skipped
I>
I> 2. Start OemK1 burn
I> 2. OemK1 burnt successfully
W> No handling of CRC-32 for OemK1
I>
I> 3. Start BootSecurityInfo burn
I> 3. BootSecurityInfo burnt successfully
W> No handling of CRC-32 for BootSecurityInfo
I>
I> Successfully burnt fuses as per fuse info
I> Index : 1    PublicKeyHash    size: 64
I> Index : 2    OemK1    size: 32
I> Index : 3    BootSecurityInfo    size: 4
I> Fuse Blob found
I> No RPMB provisioning details is found. Skip RPMB Provisioning.
I> FSKP finished

But the module no longer boots. It always powers-on to recovery mode. Any attempt to access it via USB (e.g., to flash an image, or read fuses or even re-run odmfuse.sh) always fails during BootROM communication trying to send the MB1 image:

Running doflash.sh:

$ sudo ./doflash.sh 

Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
 
[   0.0477 ] Parsing partition layout
[   0.0483 ] tegraparser_v2 --pt secureflash.xml.tmp
[   0.0520 ] Parsing partition layout
[   0.0524 ] tegraparser_v2 --pt secureflash.xml.tmp
[   0.0539 ] mb1_t234_prod_aligned_sigheader.bin.signed filename is from --mb1_bin
[   0.0539 ] psc_bl1_t234_prod_aligned_sigheader.bin.signed filename is from --psc_bl1_bin
[   0.0539 ] Boot Rom communication
[   0.0543 ] tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.signed --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.signed --download bct_mb1 mb1_bct_MB1_sigheader.bct.signed
[   0.0548 ] BR_CID: 0xA1012344705DF888180000000E008180
[   0.2937 ] Sending bct_br
[   0.4324 ] Sending mb1
[   0.4335 ] 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.bin.signed --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.signed --download bct_mb1 mb1_bct_MB1_sigheader.bct.signed

And from odmfuse.sh:

$ sudo ./odmfuse.sh -i 0x23 -k .../pkc_key_priv.pem -X .../fuse_config.xml --test jetson-orin-nano-devkit-nvme
...
[   0.8172 ] Boot Rom communication
[   0.8177 ] tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.signed --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.signed --download bct_mb1 mb1_bct_MB1_sigheader.bct.signed
[   0.8181 ] BR_CID: 0xA1012344705DF888180000000E008180
[   0.9570 ] Sending bct_br
[   1.0959 ] Sending mb1
[   1.0981 ] ERROR: might be timeout in USB write.
Error: Return value 3
...

Any ideas? I'm not expecting to be able to recover this module, but I would like to know what I did wrong so I don't brick another one.

[Shamino0]

NVIDIA's suggestion ( https://forums.developer.nvidia.com/t/bricked-my-module-setting-up-a-custom-ekb/372455 ) is that I am providing the wrong PKC key, but that is definitely not the case. I've been using this same key for quite some time without any problems.

And it also makes no sense why burning the OEM K1 key would prevent normal booting. Even if the EKB became invalid (as I expect it would), Linux should still boot, but without working OP-TEE storage. And I should be able to flash a new image with the correct EKB.

[Shamino0]

It turns out that they were right. Looking more closely at the PKC key, it was a 2048-bit RSA key instead of the 3072-bit key described by the BootSecurityInfo fuses. When I re-generated my keys and made sure I actually got a 3702-bit key, it all worked as expected.

I have no idea why this mismatched PKC hash worked (or at least allowed Linux to boot) without an SBK or OemK1 key, but that's definitely why it failed in the presence of the encryption keys.

I was also surprised to see that Op-Tee asserts, preventing Linux from loading, if the EKB isn't encrypted with the OemK1 key. It wasn't a big deal to include it in the installer image, but it is kind of annoying because it means I can't just take a generic (unsigned) tegraflash image and sign it at install time (with the -u and -v options). I also need to copy my custom eks.img to the directory.

But I'm no longer blocked, so I'm happy again.