RidgeRun Platform Security Manual/Getting Started/Secure Boot
 | RidgeRun Platform Security Manual RidgeRun documentation is currently under development. |
Secure Boot
 | lleon: what's a PKC key? (please remove this box when addressed) |
Secure Boot on an NVIDIA Jetson system is activated to block the execution of untrusted sources code. To achieve it, NVIDIA Jetson SoCs use public key cryptography and the Root of Trust. The Root of Trust on the SoC executes an untampered code stored in a Read-Only Memory manufactured with the chip. This code generates a public key hash from the private key digital signature embedded in each code that is going to be executed, and compares to a public key hash stored in hardware devices called fuses. If they match, the code comes from a trusted source and can be executed, otherwise it is not and the booting process is halted. So then, to activate a secure boot on an NVIDIA Jetson SoC, is necessary to generate a PKC key pair, store the public key hash on the fuses and sign the boot codes with the corresponding private key. As a relevant note, a fuse device can only be written once to, so it is important to do it right. Check out the [boot] general page in this wiki for more information. In this guide we are going to take a look at how to activate this feature on a Jetson Orin Nano.
- This guide was tested using a Jetson Orin Nano Developer Kit, but with slight modifications, can be applied to Jetson Orin NX series, Jetson AGX Orin series, the Jetson Xavier NX series, and the Jetson AGX Xavier series.
- This guide was tested using an Ubuntu system.
| lleon: can you elaborate which those modifications are? (please remove this box when addressed) |
| lleon: Ubuntu host or the Ubuntu on Jetson? Be more specific (please remove this box when addressed) |
Factory Secure Key and Expansion Key Provisioning
Factory Secure Key and Expansion Key Provisioning (FSKP) is a technique to improve the security when burning fuses on an SoC. As a reminder, "burning" the fuses refers to storing a public key hash in them, which can only be done once. Before, a script named odmfuse was used to do this process, and it was purely managed by the OEM (Original Equipment Manufacturer), a.k.a. the person or team building the final product. The additional security measure that FSKP brings, is that it encrypts the data passed to the SoC for fuse burning. This adds a layer of protection to the process. The fuse data is encrypted and later decrypted inside the SoC. It will be encrypted with expansion keys provided by an NVIDIA representative, and decrypted with a key already on the IROM (internal Read Only Memory) on the SoC.
| lleon: a flow diagram of the process would be beneficial (please remove this box when addressed) |
To begin the process, first generate an RSA key pair and a certificate from it. This is done to send the certificate to the NVIDIA representative and get the expansion keys encrypted.
Generate 4096 bits RSA public and private keys:
* aes-256-cbc: 256 bit keys to encrypt RSA key with AES (Advanced Encryption Standard). * out oem_rsa_priv.pem 4096: Specifies the output file name and the size of the RSA key. This command is going to ask for a passphrase to encrypt. Keep it in mind for the next steps. The output looks like the following: <syntaxhighlight lang="bash"> Generating RSA private key, 4096 bit long modulus (2 primes) ....................++++ ........++++ e is 65537 (0x010001) Enter pass phrase for oem_rsa_priv.pem: Verifying - Enter pass phrase for oem_rsa_priv.pem:
| lleon: which considerations should we take into account for the passkey? (please remove this box when addressed) |
Generate RSA x509 based Certification:
openssl req -new -x509 –outform PEM -key oem_rsa_priv.pem -out oem_publickey.cer -days 365
- new: Indicates that a new certificate should be generated.
- x509: Specifies that a self-signed certificate should be generated, rather than a CSR (Certificate Sign Request). A self-signed certificate is one that is signed by its own private key.
- outform PEM: Specifies the output format of the certificate as PEM (Privacy Enhanced Mail), which is a common format for storing certificates.
- key oem_rsa_priv.pem: Specifies the private key file to use for signing the certificate.
- out oem_publickey.cer: Specifies the output file name for the generated certificate. The certificate will be saved to a file named oem_publickey.cer. Although the extension is ".cer" which is common, the -outform PEM option means the file will contain PEM encoded data.
- days 365: Specifies the validity period of the certificate in days.
| lleon: how many days are recommended? (please remove this box when addressed) |
| lleon: is it recommended to use other configurations or just this one? (please remove this box when addressed) |
The output is going to ask you for the passphrase to read the private key and generate the certificate. It is going to also ask for information about your organization to add on the certificate:
Enter pass phrase for oem_rsa_priv.pem: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:CR State or Province Name (full name) [Some-State]:San Jose Locality Name (eg, city) []:San Jose Organization Name (eg, company) [Internet Widgits Pty Ltd]:RidgeRun Organizational Unit Name (eg, section) []:RidgeRun Common Name (e.g. server FQDN or YOUR name) []:RidgeRun Email Address []:ridgerun_inquiries@ridgerun.com
RSA 4096 bits is used by NVIDIA Recommendation. Email this CER file to the NVIDIA key custodian to get the expansion keys back and some other files to complete the process. The files needed are going to come in a zip file called Results.zip. There are two expansion keys, the AK expansion key (FSKP_AK) and the EK expansion key (FSKP_EK). Below are the contents of the Results.zip file with a basic explanation for each.
- fskp_ak.bin.rsa_wrap: The FSKP_AK wrapped with the RSA public key (binary). This is the file to be decrypted to obtain the AK key as binary data.
- fskp_ak.bin.rsa_wrap.info: metadata, Label, and String/Context used in KDF (Key Derivation Function), and KCV (Key Check Value) of FSKP_AK.
- fskp_ek.bin.rsa_wrap: FSKP_EK wrapped with RSA public key (binary). This is the file to be decrypted to obtain the EK key as binary data.
- fskp_ek.bin.rsa_wrap.info: metadata, Label, and String/Context used in KDF (Key Derivation Function), and the KCV (Key Check Value) of FSKP_EK.
- fskp_conf.txt: includes the AK and EK strings to encrypt the fuse data.
As reference for some concepts previously mentioned:
- KDF or Key Derivation Function: A function to generate the expansion keys from a root key. In this case, the root key is the Expansion key. This is the key that the NVIDIA representative has access to and is reference in the SoC with key index 62, and is stored in the IROM.
- KCV or Key Check Value: A Key Check Value is a short cryptographic checksum of a cryptographic key. It's used to verify the integrity of a key, ensuring that it hasn't been altered or corrupted.
You should also receive an FSKP tool package containing the instruments needed for the fuse burning process.
Prepare the necessary directories
To begin the encryption of the fuse data, we need to set up the necessary directories. First install the NVIDIA's board support package by downloading the Driver Package (BSP) and Sample Root Filesystem from the drivers section on the following link. Extract the downloaded files with the following commands inside a work directory (nvidia jetson in our case):
mkdir nvidia-jetson tar xf Jetson_Linux_R36.4.0_aarch64.tbz2 -C nvidia-jetson/ sudo tar xpf Tegra_Linux_Sample-Root-Filesystem_R36.4.0_aarch64.tbz2 -C \ nvidia-jetson/Linux_for_Tegra/rootfs
Run the following scripts inside the Linux for tegra directory:
cd nvidia-jetson/Linux_for_Tegra sudo ./tools/l4t_flash_prerequisites.sh sudo ./apply_binaries.sh
Output should look like the following:
. . . L4T BSP package installation completed! Disabling NetworkManager-wait-online.service Disable the ondemand service by changing the runlevels to 'K' Success!
(Optional) Create a Default User
sudo ./tools/l4t_create_default_user.sh -u <user_name> -p <password>
With NVIDIA's board support package installed, untar the FSKP tool package inside the Linux for Tegra directory. Assuming the FSKP tool package tar file was downloaded to the nvidia-jetson directory, use the following command:
tar xvjf ../fskp_partner_t234_R3x.x.0_aarch64.tbz2
The resulting directory is named l4t. Unzip the Results.zip file inside l4t/tools/flashtools/fuseburn/Results directory. Assuming you downloaded the Results.zip file inside the nvidia-jetson directory:
cp ../Results.zip l4t/tools/flashtools/fuseburn/Results cd l4t/tools/flashtools/fuseburn/Results unzip Results.zip
Decrypt AK and EK expansion keys binary data:
openssl rsautl -decrypt -inkey oem_rsa_priv.pem -in fskp_ak.bin.rsa_wrap > fskp_ak.bin openssl rsautl -decrypt -inkey oem_rsa_priv.pem -in fskp_ek.bin.rsa_wrap > fskp_ek.bin
Move these files from the Results directory to the fuseburn directory (one level above):
mv fskp_ak.bin .. mv fskp_ek.bin .. mv fskp_conf.txt ..
Prepare and encrypt the fuse data
The encrypted fuse binary data is called a fuse blob. This file is going to be decrypted in the SoC with the IROM stored key. Before going over how to prepare it, make sure the board specifications and configuration files have the right information about the board. The main variables to take into account are:
| lleon: Can you create a table with the most common, such as Orin Nano, NX and Orin AGX? (please remove this box when addressed) |
- BOARDID
- CHIP_SKU
- BOARDSKU
- RAMCODE_ID
- FAB
- BOARDREV
You can get the information of these variables by running the following command. This is for an NVIDIA Jetson Orin Nano with an SD Card. Remember to keep the board connected in recovery mode and with a USB-C to USB cable:
sudo ./flash.sh --read-info jetson-orin-nano-devkit internal
Almost at the end of the output, there should be a similar text to the following with the values we are looking for.
Board ID(3767) version(300) sku(0005) revision(K.2) Preset RAMCODE is 2 Chip SKU(00:00:00:D5) ramcode(2) fuselevel(fuselevel_production) board_FAB(300) ECID is 0x80012344705DE5196C000000100102C0
There should be information about the current state of the fuses, similar to the following:
PublicKeyHash: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 PkcPubkeyHash1: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 PkcPubkeyHash2: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 BootSecurityInfo: 00000000 ArmJtagDisable: 00000000 SecurityMode: 00000000 SwReserved: 00000000 DebugAuthentication: 00000000 OdmInfo: 00000000 OdmId: 0000000000000000 OdmLock: 00000000 ReservedOdm0: 00000000 ReservedOdm1: 00000000 ReservedOdm2: 00000000 ReservedOdm3: 00000000 ReservedOdm4: 00000000 ReservedOdm5: 00000000 ReservedOdm6: 00000000 ReservedOdm7: 00000000 Sku: 000000d5 Uid: c00201100000006c19e55d7004000000 OptEmcDisable: 0000000c
sudo ./fskp_fuseburn.py -h
[sudo] password for chidalgo:
FSKP execution started 2025-03-13 11:53:29.595125
fskp_fuseburn.py script version 0.2
Parsing input arguments
usage: fskp_fuseburn.py [-h] [-b] [-B BOARDNAME] [--board-spec BOARD_SPEC] [-c {0,x,2,3}]
[--instance INSTANCE] [-C <fskpcfg.txt|random>] [-e]
[-f <fuse_data.xml>] [-g <directory path>]
[-i <fskp key slot number>] [-H [HSM [HSM ...]]]
[-k <fskp.key> | -K | --key-exp <authkey> <enckey>]
[-p <pkc.key>] [-r {emmc,ufs,spi}] [-s] [-S {TA977SA,TA983SA}]
[-t] [-u] [-v [VERBOSE]] [-V] [-P <directory path>]
[--fskp-blob-out FSKP_BLOB_OUT] [--multi-blob KDK_DATABASE]
Parse Aruguments
optional arguments:
-h, --help show this help message and exit
-b, --burnfuse Burn fuses on target
-B BOARDNAME, --board BOARDNAME
set target board name or board config file. eg. p3701
--board-spec BOARD_SPEC
set target board info file.
-c {0,x,2,3}, --chip {0,x,2,3}
set tegra chipid. eg. 0x23 for Orin
--instance INSTANCE set USB interface id.
-C <fskpcfg.txt|random>, --fskpcfg <fskpcfg.txt|random>
Provide fskp configuration text file or use 'random' for
generating random strings
-e, --ecid Print ECID of the target
-f <fuse_data.xml>, --fusefile <fuse_data.xml>
Provide fuse xml file
-g <directory path>, --outdir <directory path>
Generate blob at <directory path> only and do not burn
-i <fskp key slot number>, --keyindex <fskp key slot number>
Tegra FSKP Key index alloted to OEM
-H [HSM [HSM ...]], --hsm [HSM [HSM ...]]
perform signing encryption operation in HSM mode. [ | fskp]
-k <fskp.key>, --key <fskp.key>
FSKP key file provided to OEM as per keyindex
-K, --skipfskpkey Skip using FSKP keyslot and key
--key-exp <authkey> <enckey>
Specifying the expansion auth key file and expansion enc key file
<authkey> <enckey>
-p <pkc.key>, --pkckey <pkc.key>
Provide PKC Key file. Flash PKC secured image.
-r {emmc,ufs,spi}, --rpmb {emmc,ufs,spi}
do RPMB Key Provisioning on given storage
-s, --skipconfirmation
skip confirmation message while fuse burning
-S {TA977SA,TA983SA}, --sku {TA977SA,TA983SA}
set target sku. eg. TA970SA or TA977SA
-t, --test perform test operation, do not burn fuses (default option).
-u, --skipuid skip querying UID of the target
-v [VERBOSE], --verbose [VERBOSE]
Enable verbose prints
-V, --version Print FSKP script version
-P <directory path>, --prebuilt <directory path>
Pick prebuilt blob from <directory path> and do not generate
--fskp-blob-out FSKP_BLOB_OUT
Only generate fskp blob at specified output directory.
--multi-blob KDK_DATABASE
The kdk fuse database
| lleon: synthesise the info from the portal (please remove this box when addressed) |
- pongo lo de nvidia portal?
- here will be specified that these is for an ubuntu system
- here will be specified also that secure boot ends at the bootloader (UEFI) so after this comes UEFI secure Boot.
UEFI Secure Boot
UEFI secure boot is a process to prevent the execution of bootloader codes that are not from a trusted source, a more in depth explanation is found in the UEFI Secure Boot section in the NVIDIA Jetson example case from the general [Secure Boot] page on this wiki.
| lleon: Can the instructions go one after the another? (please remove this box when addressed) |
How does UEFI Secure Boot Work?
UEFI Secure Boot employs RSA digital signatures to authenticate and verify the integrity of the code it loads during startup. Below are the main components used:
- Platform Key (PK) : Top-level key, is used to sign KEK.
- Key Exchange Key (KEK) : Keys used to sign Signatures Database.
- Signature Database (db) : Contains keys to sign UEFI payloads.
These keys and the keys database are first saved as a UEFI authenticated variable. This is done so that when UEFI payloads are loaded, they are verified looking for the associated certificate/key and comparing it to the ones on db (key database). The boot process will not finish as expected if they do not have the right certificate/key. The UEFI payloads are:
- extlinux.conf
- initrd
- kernel images (in rootfs, and kernel and recovery partitions)
- kernel-dtb images (in rootfs, and kernel-dtb and recovery-dtb partitions)
- BOOTAA64.efi
Set up working directory
| lleon: do we need to download this again or we can use the one we presented in secure boot? (please remove this box when addressed) |
Create a working directory. For this example it is going to be nvidia-jetson:
mkdir nvidia-jetson
Download the Driver Package (BSP) and Sample Root Filesystem from the drivers section on the following link. Extract the downloaded files with the following commands:
tar xf Jetson_Linux_R36.4.0_aarch64.tbz2 -C nvidia-jetson/ sudo tar xpf Tegra_Linux_Sample-Root-Filesystem_R36.4.0_aarch64.tbz2 -C \ nvidia-jetson/Linux_for_Tegra/rootfs
Run the following scripts inside the Linux for tegra directory:
cd nvidia-jetson/Linux_for_Tegra sudo ./tools/l4t_flash_prerequisites.sh sudo ./apply_binaries.sh
Output should look like the following:
. . . L4T BSP package installation completed! Disabling NetworkManager-wait-online.service Disable the ondemand service by changing the runlevels to 'K' Success!
(Optional) Create a Default User
sudo ./tools/l4t_create_default_user.sh -u <user_name> -p <password>
And we are ready to start the process to enable UEFI Secure Boot.
To enable UEFI Secure Boot, first install the following dependencies:
- openssl: Needed to generate keys, digital signatures and certificates and use them to sign codes.
- device-tree-compiler: To compile device tree sources that are going to be used in the boot process to enroll keys for code authentication.
- efitools: It allows you to generate, sign, and manage cryptographic keys used for UEFI Secure Boot.
- uuid-runtime: Is a package that provides utilities for generating and managing Universally Unique Identifiers (UUIDs). UUIDs are 128-bit numbers used to uniquely identify information in computer systems.
To install these dependencies, run the following command:
sudo apt install openssl device-tree-compiler efitools uuid-runtime
Generate RSA key pairs, certificates and EFI signature list File
| lleon: do we need another certificate? Please, clarify (please remove this box when addressed) |
In order to activate UEFI Secure Boot, first, let's create a folder for the uefi keys inside the Linux for Tegra folder and generate the Platform Key(PK) and certificate:
mkdir uefi_keys cd uefi_keys openssl req -newkey rsa:2048 -nodes -keyout PK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Platform Key/" -out PK.crt
- -newkey rsa:2048: new RSA private key with a key length of 2048 bits.
- -nodes: Tells openssl not to encrypt the private key.
- -keyout PK.key: This specifies the output file for the private key, named PK.key.
- -new: Creates a new certificate signing request (in this case, used to create a self signed certificate).
- -x509: tells openssl to generate a self-signed X.509 certificate instead of a CSR (Certificate Signing Request).
- -sha256: This specifies the SHA-256 hash algorithm for the certificate's signature.
- -days 3650: Sets the validity period of the certificate to 3650 days (10 years).
- -subj "/CN=my Platform Key/": Sets the subject of the certificate, which contains information about the certificate's owner.
- -out PK.crt: This specifies the output file for the certificate, named PK.crt
Generate the PK EFI signature list from X.509 certificate. As reference, the EFI signature list contains the digital signatures in the UEFI bootloader.
cert-to-efi-sig-list -g "${GUID}" PK.crt PK.esl
- -g "${GUID}": Specifies the GUID (Globally Unique Identifier) that will be associated with the signature list. GUIDs are used to identify different types of signatures and policies in UEFI Secure Boot.
- PK.crt: This is the input file, which is the X.509 certificate that you want to convert.
- PK.esl: This is the output file, which will be the EFI signature list. The .esl extension is commonly used for EFI signature lists.
Generate the KEK RSA key and certificate:
openssl req -newkey rsa:2048 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Key Exchange Key/" -out KEK.crt
- -newkey rsa:2048: new RSA private key with a key length of 2048 bits.
- -nodes: Tells openssl not to encrypt the private key.
- -keyout KEK.key: This specifies the output file for the private key, named KEK.key.
- -new: Creates a new certificate signing request (in this case, used to create a self signed certificate).
- -x509: tells openssl to generate a self-signed X.509 certificate instead of a CSR (Certificate Signing Request).
- -sha256: This specifies the SHA-256 hash algorithm for the certificate's signature.
- -days 3650: Sets the validity period of the certificate to 3650 days (10 years).
- -subj "/CN= Key Exchange Key/": Sets the subject of the certificate, which contains information about the certificate's owner.
- -out KEK.crt: This specifies the output file for the certificate, named KEK.crt
Generate the KEK EFI signature list from X.509 certificate.
cert-to-efi-sig-list -g "${GUID}" KEK.crt KEK.esl
- -g "${GUID}": Specifies the GUID (Globally Unique Identifier) that will be associated with the signature list. GUIDs are used to identify different types of signatures and policies in UEFI Secure Boot.
- KEK.crt: This is the input file, which is the X.509 certificate that you want to convert.
- KEK.esl: This is the output file, which will be the EFI signature list. The .esl extension is commonly used for EFI signature lists.
Generate the db_1 RSA Key and certificate.
openssl req -newkey rsa:2048 -nodes -keyout db_1.key -new -x509 -sha256 -days 3650 -subj "/CN=my Signature Database key/" -out db_1.crt
- -newkey rsa:2048: new RSA private key with a key length of 2048 bits.
- -nodes: Tells openssl not to encrypt the private key.
- -keyout db_1.key: This specifies the output file for the private key, named db_1.key.
- -new: Creates a new certificate signing request (in this case, used to create a self signed certificate).
- -x509: tells openssl to generate a self-signed X.509 certificate instead of a CSR (Certificate Signing Request).
- -sha256: This specifies the SHA-256 hash algorithm for the certificate's signature.
- -days 3650: Sets the validity period of the certificate to 3650 days (10 years).
- -subj "/CN= my Signature Database key/": Sets the subject of the certificate, which contains information about the certificate's owner.
- -out db_1.crt: This specifies the output file for the certificate, named db_1.crt
Generate the db_1 EFI signature list from X.509 certificate.
cert-to-efi-sig-list -g "${GUID}" db_1.crt db_1.esl
- -g "${GUID}": Specifies the GUID (Globally Unique Identifier) that will be associated with the signature list. GUIDs are used to identify different types of signatures and policies in UEFI Secure Boot.
- db_1.crt: This is the input file, which is the X.509 certificate that you want to convert.
- db_1.esl: This is the output file, which will be the EFI signature list. The .esl extension is commonly used for EFI signature lists.
Generate the db_2 RSA Key and certificate.
openssl req -newkey rsa:2048 -nodes -keyout db_2.key -new -x509 -sha256 -days 3650 -subj "/CN=my another Signature Database key/" -out db_2.crt
- -newkey rsa:2048: new RSA private key with a key length of 2048 bits.
- -nodes: Tells openssl not to encrypt the private key.
- -keyout db_2.key: This specifies the output file for the private key, named db_2.key.
- -new: Creates a new certificate signing request (in this case, used to create a self signed certificate).
- -x509: tells openssl to generate a self-signed X.509 certificate instead of a CSR (Certificate Signing Request).
- -sha256: This specifies the SHA-256 hash algorithm for the certificate's signature.
- -days 3650: Sets the validity period of the certificate to 3650 days (10 years).
- -subj "/CN= My another Signature Database/": Sets the subject of the certificate, which contains information about the certificate's owner.
- -out db_2.crt: This specifies the output file for the certificate, named db_2.crt
Generate the db_2 EFI signature list from X.509 certificate.
cert-to-efi-sig-list -g "${GUID}" db_2.crt db_2.esl
- -g "${GUID}": Specifies the GUID (Globally Unique Identifier) that will be associated with the signature list. GUIDs are used to identify different types of signatures and policies in UEFI Secure Boot.
- db_2.crt: This is the input file, which is the X.509 certificate that you want to convert.
- db_2.esl: This is the output file, which will be the EFI signature list. The .esl extension is commonly used for EFI signature lists.
Output should look like the following:
Generating a RSA private key .............................+++++ .....+++++ writing new private key to 'PK.key' -----
Generating a RSA private key ......+++++ .+++++ writing new private key to 'db_2.key' -----
and you should get three files (.crt .esl .key) for each component:
uefi_keys$ ls db_1.crt db_1.key db_2.esl KEK.crt KEK.key PK.esl db_1.esl db_2.crt db_2.key KEK.esl PK.crt PK.key
| lleon: can you tell if these settings are safe to change? (please remove this box when addressed) |
Create the UEFI Keys Config File
Open a file named uefi_keys.conf with your preferred text editor and add these lines:
UEFI_DB_1_KEY_FILE="db_1.key"; # UEFI payload signing key UEFI_DB_1_CERT_FILE="db_1.crt"; # UEFI payload signing key certificate UEFI_DEFAULT_PK_ESL="PK.esl" UEFI_DEFAULT_KEK_ESL_0="KEK.esl" UEFI_DEFAULT_DB_ESL_0="db_1.esl" UEFI_DEFAULT_DB_ESL_1="db_2.esl"
where:
- UEFI_DB_1_KEY_FILE and UEFI_DB_1_CERT_FILE are the key and certificate used to sign UEFI payloads
- UEFI_DEFAULT_PK_ES is the Platform Key EFI Signature list.
- UEFI_DEFAULT_KEK_ESL_0 is the Key encryption key EFI Signature list.
- UEFI_DEFAULT_DB_ESL_0 is the EFI Signature List of the signature database (db).
- UEFI_DEFAULT_DB_ESL_1 is the EFI Signature List of the signature database for known untrusted code signatures (dbx).
Generate the UEFI Secure Boot DTBO
This device tree blob overlay is used to store the security keys in the form of UEFI authenticated variable. It works by adding a modification to the device tree image to generate the UEFI authenticated variable with the database. To generate it, first, move to the Linux for Tegra folder:
cd ..
Use the gen_uefi_keys_dts script to generate it:
sudo tools/gen_uefi_keys_dts.sh uefi_keys/uefi_keys.conf
You should get a similar output to the following:
Linux_for_Tegra$ sudo tools/gen_uefi_keys_dts.sh uefi_keys/uefi_keys.conf Info: generating default keys dtbo. Info: adding node PKDefault. Info: adding node KEKDefault. Info: adding node dbDefault. Info: dts file is generated to UefiDefaultSecurityKeys.dts Info: dtbo file is generated to UefiDefaultSecurityKeys.dtbo Info: UefiDefaultSecurityKeys.dts and corresponding dtbo are generated. Info: generating update keys dtbo. removed 'UefiUpdateSecurityKeys.dts' Info: no update key dtbo is generated due to no update keys are provided. Info: generating dtbo is done.
Flash the board with the --uefi_keys option
To activate UEFI Secure Boot, run the flash command with the uefi-keys option. Remember to put the board in recovery mode and connect it to the host. For an NVIDIA Jetson Orin Nano with an SD Card, the command is:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device mmcblk0p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --uefi-keys uefi_keys/uefi_keys.conf --showlogs --network usb0 jetson-orin-nano-devkit internal
Now the board has the UEFI Secure Boot activated.