Hi,
Is it possible to use secure boot with an encrypted hard-drive where the hard-drive decryption key is contained in the bootloader (or somewhere secure). After reading the docs it seems possible but I am not familiar with kernel/bootloader code. How would I go about doing this?
I am currently using an external MCU with encrypted flash to store keys but it would be ideal to use the built-in key storage on the Jetson Nano.
Thanks.
hello simoncharvey,
please refer to developer guide for the Disk Encryption session, this only applies to: Jetson Xavier NX, Jetson AGX Xavier series, and Jetson TX2 series. thanks
Thanks for the link - so the Jetson Nano has no place for storing the encryption keys?
So I’ve seen secure boot does work on the Jetson Nano - Would it be possible for the bootloader to decrypt the harddrive on boot? Would this make the keys readable after boot?
hello simoncharvey,
this disk encryption support is based-on Trusty; but it does not support on Jetson Nano.
please refer to developer guide, Trusty, a Trusted Execution Environment;
you should also check similar discussion thread, Topic 175826 for reference.
thanks
Yes, there is no trusted execution environment (TEE) on the Nano, so solutions that require that won’t work. But Simon would like to know what can be done on a Nano.
First, because there is no TEE, the disk encryption/decryption key would likely have to be stored in RAM at some point. A sophisticated attacker with physcal access to the machine might be able to extract the key by probing the memory bus. But if this risk is acceptable, then would the following work?
(1) embed the disk encryption/decryption key in the bootloader
(2) encrypt the bootloader with the secureboot key (SBK) using the standard Nano secureboot approach
(3) sign the bootloader using the standard Nano secureboot approach
(4) the bootloader should only load a signed OS, which uses the key to decrypt the disk
Alternatively, in another post it has been suggested that a disk encryption/decryption key could be stored in the odm_reserved fuses, but I have had trouble finding documentation that explains how, when, and whether these fuses can be read by OS during or after boot.
Jerry, can you point us to more specific documentation about odm_reserved?
Bruce
hello bmm,
please refer to below for more details about ODM_Reserved,
thanks
Hi Bruce,
Have you tested those steps? If you can tell me how I should approach step 4 I’ll give it a shot. Will this be a driver/module or what?
Can the signed os signature be faked? Since that signature should be readable won’t a modified OS be capable of spoofing the signature or does the bootloader actually generate it on boot?
Hi Simon,
I haven’t tested these steps, but I am working on them.
It should not be possible to fake the OS signature. There is a bootstrapping process here. First, the bootloader itself is authenticated during the Nano’s secureboot process which checks the signature of the bootloader (a hash of the public key used to sign the bootloader is stored in the “RSA Public Key Hash” fuse register). The bootloader can then contain a public key that is used to authenticate the signature of the OS. This is the normal process by which an OS is securely loaded.
The wrinkle we are trying to add in order to also encrypt the disk is to include an encryption key in the encrypted bootloader, and to have this key passed to the OS during the boot process. Modifying the bootloader without screwing up the secureboot process is likely to be a bit challenging.
Jerry, thanks for the response, but I am wondering if you can provide any pointers to documention on how and when the odm_reserved fuses can be READ (not written), and in particular whether they can be read by the bootloader or the OS. Is this possible? The standard document (Tegra Linux Driver) is very light on details. It describes these fuses as “Programmable fuses at the users direction. However, 32 MSB are reserved for NVIDIA use.” but doesn’t explain when the user can read them.
Bruce
Excellent, it sounds like you’re on the right track. I don’t understand how so few people require/ask about this. Surely the jetson nano is intended as an edge computing device and would then require some form of encryption.
Perhaps @mdegans has some knowledge on reading the fuses.
Simon
I think the issue is that since the Nano doesn’t have the Trusted Execution Environment like the Xavier and TX2, any solution for the Nano would have to be different and wouldn’t be as secure. So, even though the need for full-disk encryption is there, the effort to create a solution hasn’t materialized.