Secure Boot
 | RidgeRun Platform Security Manual RidgeRun documentation is currently under development. |
Secure Boot
Secure Boot is a critical security feature in embedded systems, ensuring that all software originates from a trusted source and remains untampered. Also known as:
- NXP: High Assurance Boot (HAB) or Advanced High Assurance Boot (AHAB)
- NVIDIA: Secure Boot
It ensures that all software in the system comes from a trusted source and hasn't been tampered with (or unaltered). This process protects systems from malicious modifications by verifying the authenticity and integrity of key components like the boot loader, drivers, and other modules. It checks for:
- Digital Signatures: To confirm software origin.
- Integrity Verification: To ensure software hasn't been altered.
The system’s Root of Trust is essential, using cryptographic keys (private for the hardware, public for the bootloader) to validate these components. The Chain of Trust begins with verifying the bootloader and extends through the kernel, drivers, and typically up to user-space applications. If any component fails verification, the boot process halts.
For Secure Boot to function correctly, it’s vital that the system is configured with the proper keys, securely stored. If misconfigured or exposed to malicious parties, attackers could create and sign harmful software, bypassing Secure Boot without triggering failures.
Example: NVIDIA Jetson
Secure Boot
On NVIDIA Jetson Systems, Secure Boot is activated to block the execution of unauthorized boot codes. Secure Boot process in NVIDIA SoCs, is implemented with Public Key Cryptography (PKC wikipedia page) where a pair of keys is used, a private and a public one, and the main principle of Public Key Cryptography is that you can generate the public key from the private key pair but not the other way around. This is important to know because the way NVIDIA SoCs implement a secure boot is by storing a public key hash on a device called fuse and signing the boot codes with the private key. The fuse is a device that can only be written once, and cannot be modified after that. The name comes from the analogy of a real electrical fuse that, once burned, cannot be burned a second time. The Root of Trust (https://developer.ridgerun.com/wiki/index.php/RidgeRun_Platform_Security_Manual/Platform_Security/Root_of_Trust) authenticates each boot code by generating a public key hash from the private key that the boot codes were signed with, and comparing it to the key hash on the respective fuse.
 | lleon: ok, we jumped from fuses to Root of Trust. Please, connect the ideas (please remove this box when addressed) |
| lleon: use bold letters to emphasise the warnings (please remove this box when addressed) |
As a precautionary note, remember the nature of the fuse devices. You have only one chance of writing to these devices, so be careful with the process. A mistake in the fuse burning process could lead to an inoperative, unreversible state on the SoC. Also, be careful with the key storage. This method relies on how securely the keys are stored. If the private keys are lost, signing the boot codes to be authenticated will be almost impossible.
It is important to know that the root-of-trust that uses the NVIDIA SoCs fuses to authenticate boot codes ends at the Bootloader. After this, the current Bootloader (UEFI) will use UEFI’s Security Keys scheme to authenticate its payloads. UEFI Secure Boot process is explained below, but as a point of comparison, it does not use fuse devices. UEFI Secure Boot can be disabled by just having physical access to the board and reflashing it. That is a security flaw it has against Secure Boot itself. So they can be viewed as a compliment rather than two different ways of protecting the SoC.
| lleon: a diagram of how to connect Secure Boot and UEFI is compulsory at this point. (please remove this box when addressed) |
UEFI Secure Boot
UEFI Secure Boot shares the goal with the general Secure Boot process previously explained, to avoid the execution of untrusted codes. It uses digital signatures to verify that each code it loads is trusted. Specifically it uses two keys and a database to achieve it. A main key that is used on a platform level and in this case, is used to sign an specific key that is going to be used to sign the database. This database holds the keys to sign the codes to be authenticated. These codes are better known as UEFI payloads. In simpler terms:
- Platform Key (PK) : Top-level key, is used to sign KEK.
- Key Exchange Key (KEK) : Key used to sign Signatures Database.
- Signature Database (db) : Contains keys to sign UEFI payloads.
These three elements are stored in the form of a UEFI authenticated variable. The equivalent of a fuse device for UEFI secure boot with the difference that is a software based component. When the UEFI firmware attempts to load a payload, it checks its signature against the keys stored in the database (db) to verify it. Below, on figure 1, is a summary of the process.
The UEFI payloads for NVIDIA Jetson SoC's are:
- extlinux.conf: tells the extlinux bootloader how to load the operating system kernel and related files.
- initrd: initial RAM disk is a temporary root file system that's loaded into RAM by the bootloader
- kernel images: kernel is the fundamental software component that manages the computer's hardware and provides essential services to user-level applications.
- kernel-dtb images: A kernel DTB image is a binary representation of the Device Tree, which is a data structure that describes the hardware configuration of a system.
- BOOTAA64.efi: Typically used as part of the boot process when the device is trying to boot from removable media like a USB drive or an SD Card
These are the codes that are authenticated after they are loaded and before their execution. They have to be correctly signed to be executed. Like the general Secure Boot process, the keys must be stored securely. Unlike the general Secure Boot process, the UEFI secure boot authentication is effective unless there is physical access to the SoC to reflash it, with the UEFI secure boot process disabled. As mentioned before, the two boot code authentication methods could be a good combination, rather than two independent ways to secure the SoC. <be>
| lleon: there is no clarity if we can use both together or if they are mutually exclusive (please remove this box when addressed) |
Example: NXP
As an example of a Secure Boot implementation, we can look at NXP's High Assurance Boot or HAB. As a first step of the implementation, a utility is used to generate private and public keys. The private key is used to encrypt the image being built. As a result of this encryption, a unique identifier certificate is obtained and attached to the image along with the public key. The hash of the obtained public key is also burned to chip. This process is illustrated in Figure 1 and the process of obtaining the private key certificate is illustrated in Figure 2.
When an image is loaded into the board, the public key decrypts the certificate. After this, the obtained certificate is compared with the image to ensure they match. If the match is successful, the image can be trusted, and the system will boot as normal. However, the image is deemed unsafe if a match is not obtained, and the system won't boot. A correct certificate can only be obtained if a user can access the private key. This process is illustrated in Figure 3.
