RidgeRun Platform Security Manual/Platform Security/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

‎

‎

‎

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.

Fig 1. UEFI Secure Boot in Nvidia Jetson platforms. Extracted from link

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.

Fig 2. HAB key generation. Extracted from link

Fig 3. HAB certificate generation. Extracted from link

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.

Fig 4. HAB authentication process. Extracted from link

⟵ ⟶