I have been looking at the fuse keys an am not finding detailed information how I can protect a device specific secret to seed the boot process. DICE has a requirement that the seeding secret can only be generated once during a boot cycle, to avoid that later code can get access to that seeding secret again.
Are there any protections around the fuse keys to ensure that they are only usable during the boot process? For example are these registers readable/usable all the time?
Thank you
S.
hello LordOfDorks,
you may also access the developer guide, please check the Security chapter for the details of security features.
suggest you should also access Tutorials page, expand the [Developer Tools] session and check the training video, Jetson Security and Secure Boot.
thanks
Hello Jerry,
Thank you for your pointers and I had read and watched all that already. These features describe how authenticated boot is done, but that is not what we are after with the Trusted Computing Group DICE functionality. We are looking to do measured boot, to create an attestation record what booted. For that purpose we need a device secret that can only be read by the very first binary and is then made inaccessible to protect the root of trust for identity/measurement.
I am looking what kind of access protections exist around the fuse keys, if any. From the documentation I see that the first binary may be encrypted for example. That is great functionality because we can embed the device identity in that first binary and encrypt it against unauthorized access. But the question remains: Other than the boot ROM code who can get access to the decryption key for that first binary? If the answer is: Access is limited to the ROM code than that is perfect and will do for us.
However if for example Trust Zone code could also get access to that key and be able to decrypt the first mutable binary then that would potentially expose that high integrity boot secret to a lower integrity execution context. Do you have any documentation that describes in detail what happens in the boot ROM - for example how the fuse keys are used to decrypt the first mutable binary?
Thank you
S.
S,
Bootrom is Jetson’s root of trust and the fuses are designed to be inaccessible for production. Under Trust Zone environment, application will use crypto API to gain access to secret and the key is not readable by any software.
Hello Chijen,
thank you for your response. Could you please elaborate on your answer? I do not understand what you mean with “production”. Are you referring to “production code” that gets executed after the bootrom? Does that include the TZ code? Also when you say “Under Trust Zone” does that mean that TZ may not be able access the key but can use it? So, TZ actually CAN decrypt the encrypted boot code, even if it does not have direct access to the key?
Could you please point me to some detailed documentation where all these low level hardware security features are described?
Thank you
S.
Production means it’s ready to ship product after development. In general, user will disable fuses access once going to production. not sure if this answers your original question.
Secure boot is to ensure boot process is secure and follow the chain of trust. Trust Zone is secure OS afterwards and that’s the trusted executed environment (TEE) where trusted application is running at to gain access security assets securely. It won’t decrypt encrypted boot code as it already passes boot stage but it does allow your apps to access secure assets. For instance, secure storage is one example. Encrypted video content is another example. This is a run-time environment where your application is running at. The secure boot training video has one slide to cover hardware security features.
Hello Chijen,
What the Trusted Computing Group is doing with DICE is orthogonal to what you are calling ‘Secure Boot’ (aka. authenticated boot). DICE provides measured boot, that makes sure that a measurement of the code is turned into a strong cryptographic identity. Preferably the identity derivation is rooted in the earliest running code (ROM code). So if the Tegra ROM code decrypts the first mutable binary with a key that is absolutely unavailable after that code has started execution, then I we can embed the device secret in the encrypted first binary and have it written into RAM where we can wipe it when we are done with it and there is no way that the binary will be able to decrypt its own code in the storage part again.
When you say ‘It won’t decrypt encrypted boot code as it already passes boot stage’ I assume that this is enforced in silicon on the SoC, correct? Further I assume that if the encryption key for the first mutable binary is not kept after the first mutual binary is encrypted, no other binary will ever be able to be created for this particular SoC. This makes this first mutable binary un-serviceable, but that is intended by our solution.
Thank you
S.
hello LordOfDorks,
FYI,
we had recently release trusty samples, you might access the latest L4T Sources via download center.
you should also found the trusty_src.tbz2 package included, please refer to below for reference,
thanks
$l4t-r32.2.1_JAX_TX2/public_sources/trusty/app/sample/*
Hello JerryChang,
Thank you very much for your pointer.
I read the README_secureboot.txt from “Jetson Platform Fuse Burning and Secure Boot Documentation and Tools for TX1 and Jetson Nano” and this looks very promising. I would like to confirm that the fused SBK is only used by the ROM to decrypt the boot binary and can NEVER be read back on the device. So if the SBK file that is used to burn the fuses is lost or deleted, there will be NO WAY to ever encrypt a new or decrypt an old boot binary for the device.
Especially referring here to section ‘Accessing the Fuse from the Target Board’ that states “The L4T secureboot package provide a means to access fuses from the target board after it boots up.” Can you please confirm that this does in fact NOT include the SBK (aka. the 128 bit secure_boot_key).
Thank you
S.
hello LordOfDorks,
FYI,
when the ODM production mode bit is burned, SBK key fuses can no longer be read.
Perfect, thank you for this confirmation.