Secure Boot
 | RidgeRun Platform Security Manual RidgeRun documentation is currently under development. |
Secure Boot
 | lleon: complete with UEFI and specify the advantages, disadvantages, vulnerabilities of each one if not done correctly and what's the most recommended procedure (please remove this box when addressed) |
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
NVIDIA supports UEFI Secure Boot on its Jetson Platforms, which uses RSA to validate the authenticity and integrity of the code. The developer must generate private and public keys and then attach them to the system as a UEFI authenticated variable.
After keys have been enrolled in the target system, they must be used to sign the UEFI payloads generated when the image is created. These payloads include the L4tLauncher, kernel, kernel-dtb with private key and flash-signed images. After this, when an image is loaded into the system, the UEFI will verify the image signature using the associated certificate/public key at boot time. If there is a match, the system will boot normally. This process is illustrated in Figure 1.
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.
