RidgeRun Platform Security Manual/Getting Started/Secure Boot

RidgeRun Platform Security Manual

Table of Contents [Sticky]

• Introduction
  • General Overview
  • Basic Concepts
• Platform Security
  • Root of Trust
  • Secure Boot
  • Trusted Execution Environment(TEE)
  • Trusted Platform Module(TPM)
  • Key Management Systems (Keyring)
  • Measured Boot and Integrity Measurement Architecture (IMA)
  • Disk Encryption
  • Over-the-Air updates (OTA)
  • Kiosk Modes
• Getting Started
  • Platform Support
  • Secure Boot
  • Trusted Execution Environment(TEE)
    • NVIDIA Jetson
  • Disk Encryption
    • NVIDIA Jetson
  • Over-the-Air
    • Main providers
    • NVIDIA Jetson
  • Kiosk Modes
• Contact Us
• Sponsor your Favorite Feature

Secure Boot

• 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.

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

Create a working directory. For this example it is going 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

In order to activate UEFI Secure Boot, first, let's 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

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 used to sign UEFI payloads
• UEFI_DEFAULT_PK_ES is the Platform Key.
• UEFI_DEFAULT_KEK_ESL_0 is the Key encryption key.
• UEFI_DEFAULT_DB_ESL_0 is for the file with the list of digital signatures of trusted software.

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 is used during flashing time. 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.