Hey
I need to implement factory flashing method on AGX, i read carefully the FSKP section, but still have an unclear issue:
1)Is the “Encrypted and Signed Blob” which describes how to create, include also the whole l4t or just the fuses? I built l4t with PKC, EKB and UEFI enc flags, but didn’t see this mention there.
2)After SOM is fused, any RCM access (by usb) must be followed with the PKC keys. So in factory floor, where this key cann’t be found, how it can burn the image if it fuse it? or first i need to flash the whole image, and only after to fuse?
Thanks
hello Moti_Shani,
per your description, it looks you’re going to enable bootloader secureboot, UEFI secureboot, and disk encryption.
it’s burn fuse to program keys (i.e. PKC/SBK/OEM_K1..etc) onto this module to enable bootloader secureboot.
however, you may enable UEFI secureboot, and disk encryption without burning fuses.
>>Q1
you may refer to flashing logs.
it’s by default to flash signed/encrypted (keys with all 0s) binary files onto bootloader partition.
for instance,
[ 20.2495 ] Writing partition mb1 with mb1_t194_prod_aligned_sigheader.bin.encrypt [ 249008 bytes ]
[ 20.2497 ] [................................................] 100%
[ 20.2947 ] Writing partition spe-fw with spe_t194_sigheader.bin.encrypt [ 95232 bytes ]
[ 20.3200 ] [................................................] 100%
[ 20.3239 ] Writing partition mb2 with nvtboot_t194_sigheader.bin.encrypt [ 207584 bytes ]
[ 20.3318 ] [................................................] 100%
[ 20.3391 ] Writing partition mts-preboot with preboot_c10_prod_cr_sigheader.bin.encrypt [ 24016 bytes ]
[ 20.3629 ] [................................................] 100%
please see-also developer guide, Flashing Script Usage.
you’ll need to provide the same keys to the flash command-line (i.e. -u <PKC_key_file>, -v <SBK_key_file> ) if you fused a target.
otherwise, it’ll abort the flashing process.
there’s Boot Rom communication in the early stage. for instance, it’ll report the errors like below and abort the process if you did not given keys to the fused target.
Error: Either RSA key file is not provided or SBK key file is provided for PKC protected target board.
>>Q2
that’s correct. the security of your device depends on how securely you keep the key file.
here’s tool generates a tarball called mfi_<target-board>.tar.gz that contains all the minimal binaries needed to flash in an unsecure environment. you may creating massflash image blob, which contain the necessary keys.
please see-also readme file, $OUT/Linux_for_Tegra/tools/kernel_flash/README_initrd_flash.txt, you may check [Workflow 8: Secure initrd Massflash] for the steps.
Thanks,
So, in the PFSK, where i create out.tar by :
sudo ./fskp_fuseburn.py --board-spec orin-agx-board-spec.txt -f fuseblob.xml -i 62 --test --key-exp fskp_ak.bin fskp_ek.bin --fskpcfg fskp_conf.txt -g out/ -c 0x23 -B /jetson-agx-orin-devkit.conf
what the out.tar contain? only the fuse blob? or also the all L4T image (bq,b2,uefi…)?
and if i want to update secured-fused device with USB (recovery mode, no production fuse burned),
Is there a way to do it without the keys (e.g updtae in factory floor in case of recall) by this FSKP method?
Thanks agein
hello Moti_Shani,
please see-also developer guide, Preparing the Encrypted and Signed Blob, it’s fuse blob.
you may refer to An Example: Using the Encrypted and Signed Blob at the Factory for the steps to setup an environment, and running fuse blob on the factory to burn fuse.
Hi @Moti_Shani, I hope you are doing well!
About the “Encrypted and Signed Blob”
The encrypted and signed blob generated during the FSKP (Factory Secure Key and Expansion Key Provisioning) process is an encrypted binary file that holds the fuse data that will be written to the device.
This data includes the values for fuses such as the public key hash, the secure boot key, and the boot security information.
This blob is only used for the fuse-burning process; it does not contain or represent the full L4T image or filesystem.
About Flashing and Fusing
After the fuse-burning process completes, secure boot becomes active on the device.
From that point on, all bootloaders and system images that are loaded onto the board must be signed using the private keys that were generated during the secure boot setup.
The secure boot workflow supports different methods to sign and flash the system images. This can be done in a single step, where images are signed and flashed together, or in two separate steps, where the signing and flashing are performed independently.
If you need more information, you can read the following wiki, where you will find step-by-step instructions on how to generate keys, create and encrypt the fuse blob, burn the fuses, and flash signed images:
RidgeRun Platform Security Manual – Secure Boot on NVIDIA Jetson
If you have more questions, please let me know!
Best Regards,
Oscar Mendez
Embedded SW Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: www.ridgerun.com