Private key stored in FUSEs

We are looking for solution to store other private key not limited to secureboot key. we noticed that there are ODM reserved bit in fuse.
(FUSE_RESERVED_ODM0 [31:0])

Repost per request
old post in RSA or ECC private key stored in FUSEs

/…/
(FUSE_RESERVED_ODM7 [31:0])

Is it NVIDIA’s recommendation to store a private key in these fuses for the Jetson Nano or is there another recommended way to store a private key?

Thanks

hello terry8uwg2,

may I know what’s your actual use-case?

we have per device mqtt key and model encryption key for example we want to put into the fuse .

hello terry8uwg2,

it may not works for Jetson Nano.

the concept of Secureboot is to prevent execution of unauthorized code during boot process through chain-of-trust;
those authenticates boot components (such as, Boot Configuration Table, bootloader binaries, and warmboot vector) were signed using private key.
once the ODM production mode bit is burned, fused keys can no longer be read.

you may enable TA/CA services to perform a secure operation,
however, it’s secureOS feature and it only applies to: Jetson Xavier NX, Jetson AGX Xavier series, and Jetson TX2 series devices.
please also check developer guide, Trusty, a Trusted Execution Environment for reference,
thanks

hi Jerry, I understood the secureboot is different thing . what i am asking is if i can leverage fuse to store other key if fuse is large enough . i think fuse and secureboot are different topic.

hello terry8uwg2,

it’s ODM field fuses, for example, it’s 256-bits of field programmable ODM_Reserved fuses.
you may check those fuse via sysnode, for example, /sys/devices/7000f800.efuse/7000f800.efuse:efuse-burn/reserved_odm*
note,
once the ODM production mode bit is burned, fused keys can no longer be read.
thanks

Hi Jerry
“once the ODM production mode bit is burned, fused keys can no longer be read” can you explain how to read the ODM field then ? if we put key in the ODM field and how the application read these key ?

hello terry8uwg2,

to clarify,
fused keys can no longer be read once the ODM production mode bit is burned; the only exception is the Reserved_ODM fuses; Reserved_ODM will be disabled after you’d program the ODM_lock fuse bit.

it’s Secureboot is to prevent execution of unauthorized code during boot process through chain-of-trust.
so,
you may have your use-case to store keys in fuse for using before program the ODM_lock.

Hi Jerry,

what’s purpose of ODM_LOCK if we can not read them afterwards. in our case do you suggest we can use these 256-bits field but never lock the fuse bit ?

hello terry8uwg2,

these keys were actually used for Jetson security, ODM_lock being the final step for make the device for production.

Hi Jerry

so i am sorry i sitll dont know how should i use these field . ? Should i store our priviate key but not lock the fuse bit ? otherwise you said i can not read them . we are looking for a place we can save priviate key and read it out after system boot up

hello terry8uwg2,

please avoid to burn ODM production and also ODM lock to program the fuse,
after system boot-up, you’re able to read the fuse (via, efuse) for your use-case.
thanks

should i use sudo ./odmfuse.sh -i <chip_id> -c PKC -p -k <key.pem> [-D <DK_file>] in the factory to burn it first then after booting up the program can read via /sys/devices/7000f800.efuse/7000f800.efuse:efuse-burn/reserved_odm* ?

hello terry8uwg2,

please refer to developer guide, Secureboot.
you may exclude -p options, since it’ll sets production mode.