Secure Boot
🚧 Documentation is under development
The RidgeRun Platform Security Manual guide is currently under active development. Some sections may be incomplete or change without notice.
Questions? Contact RidgeRun or email to support@ridgerun.com.
- Introduction
- General Security Concepts
- Getting Started
- Contact Us
- Sponsor your Favorite Feature
Secure Boot
Secure Boot is a critical security feature in embedded systems that ensures only authorized software is executed during the boot process. Depending on the platform, this mechanism may have different names:
- NXP: High Assurance Boot (HAB) or Advanced High Assurance Boot (AHAB)
- NVIDIA: Secure Boot
Secure Boot ensures that software loaded during the boot process comes from a trusted source and has not been tampered with. This mechanism protects the system from unauthorized modifications by verifying the authenticity and integrity of critical components such as the bootloader, kernel, firmware, and other boot components.
Secure Boot typically verifies:
- Digital Signatures: To confirm software origin.
- Integrity Verification: To ensure the software hasn't been altered.
The system's Root of Trust is essential to this process. Software components are signed using a protected private key, while the device uses trusted public-key information, or a cryptographic hash derived from it, to verify their signatures.
This establishes a Chain of Trust, in which an initially trusted component verifies the next component before allowing it to execute. The exact chain depends on the platform and its boot architecture, but it commonly extends from immutable boot code to boot firmware, the bootloader, and the operating system. If a required component fails verification, the secure boot process prevents that component from being executed.
For Secure Boot to function correctly, the system must be provisioned with the correct trust information, and the corresponding private signing keys must be securely protected. If signing keys are compromised, an attacker may be able to sign malicious software that the device recognizes as authorized, undermining the protection provided by Secure Boot.
NVIDIA Jetson Implementation
On NVIDIA Jetson platforms, Secure Boot is divided into two complementary mechanisms: SoC-level Secure Boot and UEFI Secure Boot. SoC-level Secure Boot establishes the hardware-backed Chain of Trust and authenticates the early boot components up to UEFI, while UEFI Secure Boot extends this protection by authenticating the components loaded after UEFI starts.
Secure Boot
On NVIDIA Jetson systems, Secure Boot is used to prevent the execution of unauthorized boot code. The Secure Boot process on NVIDIA SoCs uses Public Key Cryptography (PKC) which relies on a pair of keys: a private key and a public key.
A fundamental principle of Public Key Cryptography is that the public key can be derived from the private key, while the private key cannot feasibly be derived from the public key. This is important because NVIDIA SoCs implement Secure Boot by storing trusted key information in one-time programmable fuses and using the corresponding private key to sign boot components.
These fuses are one-time programmable (OTP), meaning that once specific fuse values have been programmed, they cannot be restored to their previous state. As explained in this section, the Root of Trust must provide an immutable and tamper-resistant foundation from which the secure boot process can begin.
In this case, the hardware Root of Trust begins with immutable code stored in the on-chip BootROM and trust information provisioned into the SoC's fuses. During the boot process, the BootROM uses this trusted information to authenticate the required boot components before allowing them to execute. The public-key information associated with the signed boot components is validated against the trusted key information provisioned into the device.
As a precautionary note, keep in mind the one-time programmable nature of security fuses. Fuse programming is an irreversible operation and should be performed carefully. Incorrectly programming security-related fuses can leave the SoC in a state in which the expected boot software can no longer be authenticated.
Private-key storage is equally important. The security of this mechanism depends on keeping the private signing keys protected. If a private key is compromised, an unauthorized party may be able to sign malicious boot components that the device recognizes as trusted. If the private key is lost, it may no longer be possible to sign new boot components that the device will accept.
It is also important to distinguish the SoC-level Secure Boot chain from UEFI Secure Boot. NVIDIA's hardware-based boot authentication establishes trust from the BootROM and authenticates the required boot components leading to the UEFI bootloader. UEFI can then use its own Secure Boot key infrastructure to authenticate subsequent payloads.
These mechanisms therefore protect different stages of the boot process and can be used together to extend the Chain of Trust. The diagram below illustrates the boot components and their loading and authentication process.:
First, the BootROM code is executed, establishing the Root of Trust for NVIDIA Jetson Orin and Xavier systems. The BootROM loads and starts the PSCROM (Platform Security Controller Read-Only Memory), which authenticates subsequent boot components before they are allowed to execute.
The components authenticated at this stage include MB1 (Microboot 1) and its MB1 BCT (Microboot 1 Boot Configuration Table), as well as PSCBL1 (Platform Security Controller Bootloader 1).
MB1 initializes several parts of the SoC, including the CPU, and performs security-related configuration. PSCBL1 then starts MB2 (Microbootloader 2), which performs additional firmware initialization and eventually loads the UEFI bootloader.
At this point, the boot process transitions to UEFI, which can use UEFI Secure Boot to authenticate subsequent boot payloads and continue the Chain of Trust.
UEFI Secure Boot
UEFI Secure Boot shares the same goal as the initial Secure Boot process described above: preventing the execution of unauthorized code. It uses digital signatures to verify that the UEFI payloads loaded during the boot process are trusted.
UEFI Secure Boot relies on a hierarchy of keys and signature databases to establish and manage this trust. The main elements are:
- Platform Key (PK) : The top-level key used to establish control over the Secure Boot configuration and authorize changes to the KEK database.
- Key Exchange Key (KEK) : A set of trusted keys used to authorize updates to the signature databases.
- Signature Database (db) : Contains trusted certificates, public keys, or hashes used to determine which UEFI payloads are authorized to execute.
These elements are stored as UEFI authenticated variables. Unlike the hardware fuses used to establish trust at the SoC level, these variables are managed by the UEFI firmware and provide the trust information required for UEFI Secure Boot.
When the UEFI firmware attempts to load a payload, it verifies the payload against the trusted entries stored in the signature database (db). If the payload satisfies the Secure Boot verification policy, it is allowed to execute.
Figure 1 below summarizes this process.
The UEFI payloads for NVIDIA Jetson SoCs are:
- extlinux.conf: A configuration file that specifies how the operating system kernel and related boot files should be loaded.
- initrd: The initial RAM disk, which provides a temporary root file system loaded into memory during the boot process.
- kernel images: The operating system kernel, which manages the system's hardware resources and provides essential services to user-space applications.
- kernel-dtb images: A binary representation of the Device Tree that describes the system's hardware configuration.
- BOOTAA64.efi: An AArch64 UEFI executable commonly used as a default bootloader path, particularly when booting from removable media such as a USB drive or SD card.
These boot components can be authenticated as part of the UEFI boot process before they are used or executed. The components that require cryptographic authentication must be correctly signed or otherwise trusted according to the configured UEFI Secure Boot policy.
As with the SoC-level Secure Boot process, the corresponding private signing keys must be stored securely. However, UEFI Secure Boot and SoC-level Secure Boot protect different stages of the boot process and rely on different trust mechanisms.
Rather than viewing them as independent ways to secure the SoC, they can be used together to extend the Chain of Trust. The SoC-level Secure Boot mechanism authenticates the boot components required to reach the UEFI bootloader. From there, UEFI Secure Boot can authenticate subsequent boot payloads according to its configured security policy.
NXP Implementation
As an example of a Secure Boot implementation, we can look at NXP's High Assurance Boot (HAB). As a first step in the implementation, a utility is used to generate the required private and public keys. The private key is used to sign the software image, while the corresponding public key is used to verify its authenticity.
The required certificates and signature information are generated as part of the signing process and included with the image so that the device can authenticate it during boot. Trust is established on the device by programming the corresponding public-key hash into the SoC's security fuses.
This process is illustrated in Figure 2, while Figure 3 shows the process of generating the keys and certificates used for signing.
When an image is loaded onto the board, the system first validates the public-key information against the trusted information stored in the eFuses. The validated public key is then used to verify the digital signature associated with the image. As part of this process, the system calculates a hash of the image and compares it with the value obtained through signature verification. If the verification is successful, the image is considered authentic and is allowed to continue through the boot process. If the verification fails, the image is considered unauthorized and is prevented from executing. A valid signature can only be generated using the corresponding private signing key. Therefore, protecting the private key is essential to maintaining the security of the Secure Boot process. This process is illustrated in Figure 4.
