Hi Team,
I am working on the Security features for the jetson orin nano and i am using latest jetpack i.e 6.2(R36.4.3). So I wanted to understand the sequence of the features like on what feature should I start with and subsequently what should be next. I would be if you guide me in this.
I referring to Security from Developer guide.
Thanks in advance.
I can’t answer your question, but something to start with: Is this Orin Nano a developer’s kit? If so, then it uses an SD card; if not, then the Nano uses eMMC. The SD card models are not capable of using secure boot; only the eMMC models have that ability. Once this is complete, then none of the non-rootfs partitions can be flashed without the private key (and SD card models don’t have eMMC partitions, they use QSPI memory instead).
Also, some of the content which is in “/boot
” will no longer work for booting once security fuses are burned. I recommend you make sure your kernel and device tree are correct in partitions. If you add a duplicate entry in “/boot/extlinux/extlinux.conf
”, and in that duplicate you remove any Image
or FDT
line (basically whatever docs say must be in partitions after burning fuses), then you can boot to that entry and see if your kernel and device tree, etc., still boot. If they boot like that, then you can try fuse burning; if not, then you are not ready to burn fuses.
Note that all partitions are always signed (other than rootfs). Signing is always enforced in those partitions, but the key is basically NULL until you burn fuses.
hello SeetharamNS,
may I know the actual use-case?
for instance, there’re bootloader secureboot, UEFI secureboot, disk encryption..etc
Hi Jerry,
use-case Traffic Management. It will deployed in public places. So I need to enable all the security features. So please help me with flow to proceed and enable all the security features.
Looking forward for your valuable assistance.
hello SeetharamNS,
so you’ll need to enable below as mentioned.
Thanks for you sugeestions @JerryChang .
I am working on it. In the documention they have suggested to use HSM(Hardware Security Module) to generate hexadecimal keys. So is it mandatory to use HSM or it ok if I use openssl tool during production.
hello SeetharamNS,
it’s suggested to use the Hardware Security Module (HSM) to generate a truly random number key.
however, it’s okay to use openssl
to generate key pair. the security of your device depends on how securely you keep the key file.
Ok, Thanks for the clarification.
Currently I am working on UEFI Secure Boot. I have a confusion, there in the documentation I can see two methods to enable UEFI Secure boot. I want to understand the differences and which would be better for the Jetson orin nano.
hello SeetharamNS,
the difference is.. the method to enable UEFI secureboot before/after flashing a target.
Hi Jerrychang,
So can I parallely do Secure boot and UEFI Secure boot(Method one) in single go?
hello SeetharamNS,
Yes, let me taking below flash command-line as an example,
Use eMMC as rootfs storage:
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh -u <pkc_keyfile> [-v <sbk_keyfile>] --uefi-keys uefi_keys/uefi_keys.conf jetson-agx-orin-devkit internal
for instance,
there’s -u <pkc_keyfile> [-v <sbk_keyfile>]
to flash a PKC/SBK target, which means it’s already fused to enable secureboot.
besides, it’s --uefi-keys uefi_keys/uefi_keys.conf
to provide signing keys, which enable the UEFI secureboot.
Hi JerryChang,
Thanks for confirmation.
I hope there are no overlaps in key generation during these two processes. I mean to say that whatever the keys we are generating in Secure Boot and UEFI Secure Boot are completely different and independent.
Thanks for the confirmation.
And do we have to follow Update the db/dbx Keys with a Capsule Update after Method one or method 2? or it can be/should be used after using either of the methods?
Also as per your below suggestion, don’t we need fuse_config.file(and mentioned parameters/keys) to flash the kit for Secure Boot or it is ok if i just use PKC and SBK keys for the same.
Yes, let me taking below flash command-line as an example,
Use eMMC as rootfs storage:
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh -u <pkc_keyfile> [-v <sbk_keyfile>] --uefi-keys uefi_keys/uefi_keys.conf jetson-agx-orin-devkit internal
for instance,
there’s -u <pkc_keyfile> [-v <sbk_keyfile>] to flash a PKC/SBK target, which means it’s already fused to enable secureboot.
besides, it’s --uefi-keys uefi_keys/uefi_keys.conf to provide signing keys, which enable the UEFI secureboot.
hello SeetharamNS,
it’s capsule update to replace keys (i.e. KEK, db, dbx keys) as long as key update is necessary.
it’s okay to use flash command-line to assign keys for image flashing.
you may see-also readme file for reference.
i.e. $OUT/Linux_for_Tegra/tools/kernel_flash/README_initrd_flash.txt
Hello JerryChang,
Thanks for the information on capsule update.
I am searching documentation for Kernel Secure Boot in L4T R36.4 developer guide documentation but not able to find. can you please help me with the documentation or any reference for the same?
hello SeetharamNS,
there’re bootlaoder secureboot and UEFI secureboot.
what did you meant Kernel Secure Boot? may I have more details.
Incidentally, if you have the fuses burned with a key, then the kernel can only be loaded from a correctly signed kernel partition. Flash itself puts the kernel into the partition if you adjust the flash to use your key and if that key matches the burned fuses.
Hi linuxdev,
Thanks for the information. Let me work on them and update.