1.for some fuse items，exp: oemK1, oemK2, SBK, stored in plain text in the configuration file, How to prevent the leakage of these keys，do you have any recommended practices? It is not only on the production line that equipment needs to be fused; R&D personnel also need to fuse equipment separately during the research and development process.
2.refer to Jetson-Orin-Fuse-Specification_DA, FUSE_KEYS_OEM_K1_0_TAG_0、FUSE_KEYS_OEM_K2_0_TAG_0、FUSE_KEYS_PSC_STATIC_OEM_0_0_0、FUSE_KEYS_PSC_STATIC_OEM_0_1_0, What are the functions of these fuse items, where are they used, and is it mandatory to perform fusing?
3.On the same device, the HUK changes before and after blowing the oemK1 fuse. Consequently, services derived from the HUK, such as secure storage, cannot decrypt content encrypted before the fuse was blown. Are there any solutions for this, and is there any way for the HUK to not depend on the oemK1?
— 🤖 This is an automated AI response. I’m here to help, but please verify important details! —
Based on the provided context, I will answer your questions about fuses on the Jetson Orin NX.
To prevent the leakage of keys stored in plain text in the configuration file, the provided context does not offer specific recommendations. However, it is essential to handle these keys securely, especially during the production line and R&D process. It is recommended to follow best practices for secure key management, such as storing keys securely, limiting access to authorized personnel, and using secure protocols for key exchange.
The provided context does not explicitly explain the functions of the fuse items FUSE_KEYS_OEM_K1_0_TAG_0, FUSE_KEYS_OEM_K2_0_TAG_0, FUSE_KEYS_PSC_STATIC_OEM_0_0_0, and FUSE_KEYS_PSC_STATIC_OEM_0_1_0. However, it mentions that OEM_K1 and OEM_K2 are used for generating the EKB (Encrypted Key Blob) image. The context also mentions that burning the OEM_K1 fuse changes the HUK (Hardware Unique Key), which affects services derived from the HUK, such as secure storage.
According to the provided context, there is no clear solution to prevent the HUK from depending on the OEM_K1 fuse. The context states that burning the OEM_K1 fuse changes the HUK, which affects services derived from the HUK. However, it is recommended to follow the guidelines provided in the NVIDIA Jetson Linux Developer Guide for Secure Boot and fuse management to ensure secure key management and minimize potential issues.
In summary, while the provided context does not offer explicit answers to all your questions, it emphasizes the importance of secure key management and following best practices for handling sensitive information. It is essential to consult the NVIDIA Jetson Linux Developer Guide and other relevant documentation for more detailed information on fuse management and secure boot on the Jetson Orin NX.
— We support team will also look into your issue to have further suggestions soon. please stay tuned. —
>> Q1
you may refer to $OUT/Linux_for_Tegra/bootloader/README_Massfuse.txt.
here’s tool to create a massfuse blob, which able to fuse targets to enable secureboot without revealing any SBK or PKC key files.
>> Q3
we’ve address the similar issue that HUK will not depends-on EKB.
is it possible for moving forward to the latest JetPack 6.2.2/L4T 36.5.0 release version for verification?
my device is jetson orin NX, and set the command’s target to jetson-orin-nano-devkit,I don’t know if the error is caused by an incorrect target specification.
>>Q2
I have read the document, but I am not sure if it is necessary to blow those fuse items, and if so, what values they should be blown to.
>>Q3
No, we just use Jetpack6.0/L4T 36.3,has no upgrade plan, Could you provide a patch based on L4T 36.3?
may I know what board authorization type you’re going to enabled?
please double check Burn Fuses with the Fuse Configuration file.
you may also refer to some of fuse configuration file samples.
unfortunately, we usually don’t back port changes.
please moving forward, just an FYI, NVIDIA JetPack™ 6.2.2, which includes security-related fixes.
see-also Release_Notes_r36.5.
for instance,
PKC for sign. if PKC is burned, then the KEYFILE users provide is for signing the images.
SBK for encryption. if SBK is burned, then the SBKFILE users provide is for encrypting the images.
is SBK mandatory to be enabled? what special components will be encrypted by SKB, I see ‘UEFI payload encryption’ will encrypt the initrd/kernel image/kernel dtb.
Are there any fuse items that have already been blown when the chip leave nvida factory,for exp: ecid, and is the HUK derived based on such fuse items, so the HUK will never changed
>> Q1
the bootloader binaries has authentication by PKC and decryption by SBK.
see-also.. $OUT/Linux_for_Tegra/bootloader/generic/cfg/flash_t234_qspi.xml for details.
>> Q2
there’re OEM_K1/K2 to derive a root key which is itself used to sign and encrypt the EKB.
FUSE_KEYS_OEM_K1_0_TAG_0 is the first word of the 128-bit authentication tag for the wrapped OEM_K1 fuse key, and it must typically be provisioned explicitly.
For PscOdmStatic, we recommend burning it to 0x60, which sets the purpose of:
– OEM_K1 to encryption. (see-also OEM_K1_PURPOSE=0x0)
– OEM_K2 to KDK(key derive key) (see-also OEM_K2_PURPOSE=0x6)
FUSE_KEYS_OEM_K1_0_TAG_0 corresponds to OemK1Tag in the Jetson fuse XML.
please have the case-sensitive XML fuse name,
for instance, <fuse name="OemK1Tag" size="16" value="0x..."/>
What should the value of OemK1Tag be set to? Is it acceptable to set it to a 128-bit random value, or does it need to be calculated from OemK1 using an algorithm? I haven’t found any relevant information in any official NVIDIA documentation or forums.