Data encryption using secure boot and odm_reserved fuse in Jetson Nano

Hi,

I’d like to encrypt my machine learning model in the Jetson Nano so that other people cannot steal the model. I’ve read this thread, which concludes that making secure file encryption is impossible on Jetson Nano. I understood that TrustedZone in Xavier and TX2 is a good solution.

I’ve read NVIDIA Jetson Linux Developer Guide. In this document, Jetson has a user-programmable fuse odm_reserved. If the secure boot feature prohibits booting from an unknown storage, the odm_reserved fuse is only visible to the trusted user (is this correct?). This means that odm_reserved can be used as a secure key storage, because it is only accessible to the trusted user who has booted from storage authenticated by the secure boot.

So I came up with a way to encrypt data in Jetson Nano using secure boot and odm_reserved:

  1. Generate a key and encrypt the machine learning model (using LUKS encrypted partition, zip encryption, etc…)
  2. Burn that key to odm_reserved
  3. Prepare some program that reads a key from odm_reserved and decrypt the model. Include it in the application to be executed on Jetson Nano
  4. Following the secure boot configuration steps, generate key pair, burn fuse, sign, and flash boot files.

I know that software isolation like TrustedZone, of course, can’t be achieved by this method, so a cracked application may have an access to the machine learning model. However, this method, based on secure boot and odm_reserved, prevents stealing the model from SD card or eMMC on Jetson Nano, simply removing them from the Jetson board and connecting them to other computers.

Is my understanding of secure boot and odm_reserved correct? Does this method work?
Thanks!

hello yoshitaka.taguchi,

you’re correct that Trusty supports only applies to… Jetson Xavier NX, Jetson AGX Xavier series, and Jetson TX2 series devices.

I don’t think odm_reserved could protect the content of your machine learning model.
Secureboot prevents the execution of unauthorized boot codes through chain of trust; that’s approach to encrypt bootloader images.
but, your code were actually locate at APP partition, (i.e. system.img).

Hi, JerryChang,

Thank you for the reply.

your code were actually locate at APP partition, (i.e. system.img).

Yes! this is correct, the code of my application does exist in the partition.
However, I suppose that not the application codes, but the machine learning model (thousands of parameters) is saved and encrypted in the partition, which is encrypted using the key in odm_reserved. The application decrypts the encrypted machine learning model and put it in the RAM. So the non-encrypted machine learning model does not exist in the partition, while the vanilla application code exists in the partition.

I don’t care if the code of the application is stolen. I want the machine learning model to be encrypted in the storage, that is SD or eMMC. It is true that if some software in the operating system has vulnerabilities, the cracker can exploit it and steal the decrypted model in the RAM. I will give up when someone does this.

However, by making the model encrypted in the storage, I thought I could prevent the model to be stolen very easily, like just using the cp command. A very skilled cracker can steal the model, but I thought I could protect the model from usual people with the method above.

hello yoshitaka.taguchi,

it may works by using fuse key to encrypt parameters.
you may checking them as below,
i.e. /sys/devices/7000f800.efuse/7000f800.efuse:efuse-burn/

FYI,
there’s ODM production fuse to enable a global lock of all the manufacturing fuses.
once ODM production mode bit is burned, fused keys can no longer be read.
thanks

1 Like

Hi, JerryChang,

Thank you for providing the path to check that fuse. I will continue with this method.

For the ODM production fuse, let me ask you one more question.

once ODM production mode bit is burned, fused keys can no longer be read.

Here, “can no longer be read.” means “can no longer be read from non-authorized boot (and it is of course readable from authorized boot)”. Is this right?

In the Overall Fusing and Signing Binaries document, it says “The odm_production mode fuse is burned to protect the SoC device from erroneous ODM production fuse burning.” So I thought that odm_production_mode protects the additional writing, not the reading.

Reading your comment, I understood that I also have to burn odm_production fuse to hide the content of odm_reserved from other person. To use the odm_reserved as a key storage like in the method I described above, I need to burn odm_production fuse as well. Is this right?

Thanks,

hello yoshitaka.taguchi,

fuses are designed to be inaccessible for production.

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.

to clarify,
when you begin production and burn the ODM production fuse, secure boot is enabled, JTAG debug is disabled, and all the fuses become inaccessible except Reserved_ODM.
however,
Reserved_ODM fuse are programmable until it disabled by the ODM_lock fuse.
thanks

hello yoshitaka.taguchi,

FYI,
you may also check discussion threads about the Jetson security.
such as Topic 80861, and Topic 107742 for reference,
thanks

1 Like

Hi JerryChang,

when you begin production and burn the ODM production fuse, secure boot is enabled, JTAG debug is disabled, and all the fuses become inaccessible except Reserved_ODM.

Thank you for describing in detail. This is what I wanted to know.
In addition, the topics you gave me for reference helped me a lot.

Thanks,