Secure Boot and Chain of Trust Explained

1. The Goal of Secure Boot

The primary goal of a secure boot process is straightforward: to prevent the execution of unauthorized or malicious software. In an automotive ECU, this is paramount. An attacker who could replace the standard firmware with their own could compromise vehicle safety, steal data, or alter the vehicle's function.

The fundamental principle is to measure and verify each piece of software before it is executed. A trusted component checks the next component in the boot sequence against an expected value. If the check passes, that component is executed and becomes the new trusted component, responsible for verifying the next stage.

This sequential verification process creates what is known as a Chain of Trust.

2. The Chain of Trust: How it Works

The chain of trust is the core concept of secure boot. Imagine a chain where each link is a piece of software (e.g., a bootloader, an OS kernel). For the chain to be strong, each link must be verified by the previous one before it's added. If any link is found to be fraudulent, the chain is broken, and the boot process is halted.

As the video highlighted, secure boot relies on asymmetric cryptography and digital signatures, not encryption. The software itself is typically readable, but any modification to it will invalidate its signature.

The process is as follows:

1. A developer generates a cryptographic hash (e.g., SHA-256) of the final software binary.
2. This hash is then "signed" using a private key. This signature is a small block of data.
3. The signature is appended to the binary image.
4. On the device, the corresponding public key is stored in a secure, immutable location.
5. During boot, the preceding software stage (the verifier) does two things:
   • It calculates a fresh hash of the binary image it just loaded.
   • It uses the stored public key to decrypt the signature, revealing the original hash calculated by the developer.
6. If the freshly calculated hash matches the developer's original hash, the binary is authentic and untampered. The verifier can then transfer execution to it.

3. The Anchor: The Root of Trust

A chain is only as strong as its anchor. The chain of trust must start from a component that is inherently trusted and cannot be modified. This is known as the Hardware Root of Trust (RoT).

In most SoCs, the RoT is a small piece of code permanently etched into the chip's Boot ROM during manufacturing. This code is immutable. Its job is to verify the very first stage of mutable software loaded from flash or other non-volatile memory.

To perform its verification, the Boot ROM needs access to the public key. Storing the entire key in the limited ROM space can be inefficient. A common practice, which your experience with microcontrollers will make intuitive, is to store a hash of the public key in one-time programmable (OTP) fuses on the SoC. The full public key can be stored with the bootloader image in flash. The Boot ROM then reads the public key from flash, hashes it, and compares it to the trusted hash stored in the OTP fuses before using it.

4. The Boot Sequence: A Practical Example

Let's walk through a typical boot sequence in a system using ARM TrustZone, building on what we learned in the last lesson about Trusted Firmware-A (TF-A).

The process, tying into the TF-A terminology, often looks like this:

1. Power On -> Boot ROM (BL1): The processor begins executing from the immutable Boot ROM (this is BL1 in the TF-A context). It contains the Root of Trust Public Key (ROTPK) or its hash. It loads the next stage bootloader (BL2) from flash into RAM.
2. Verification of BL2: The Boot ROM calculates the hash of BL2 and verifies its signature using the ROTPK. If it matches, it jumps to BL2. The chain is now one link long.
3. BL2 Execution: BL2 is now the trusted verifier. Its job is to load the subsequent images for both the Secure and Normal worlds:
   • BL31: The EL3 Secure Monitor runtime (the core of TF-A).
   • BL32: The Trusted Execution Environment (TEE) or Secure OS.
   • BL33: The Normal World bootloader (e.g., U-Boot).
4. Verification of BL3x: BL2 contains the public keys needed to verify BL31, BL32, and BL33. It authenticates each of them before proceeding.
5. Execution Handoff: Once verified, BL2 jumps to BL31 (the Secure Monitor), passing information about the entry points for the other images. BL31 then completes the setup of the Secure World and finally launches the Normal World bootloader (BL33/U-Boot) to boot the main OS like Linux.

This multi-stage process is powerful. As you've seen in automotive development with the V-model, separating concerns is crucial. The silicon vendor (who makes the SoC) provides the Boot ROM (BL1). As a Tier 1 developer, you might provide the next stage (BL2), which then loads a bootloader (BL33/U-Boot) and an OS (Linux) provided by other parties. The chain of trust ensures all these components from different suppliers can be integrated securely.

5. An Important Distinction: Secure Boot vs. Measured Boot

There is a related concept called Measured Boot. It's an important distinction to understand for interviews.

• Secure Boot is about enforcement. If a signature is invalid, the boot process stops. It prevents the system from booting into an untrusted state.
• Measured Boot is about recording and reporting (attestation). During a measured boot, each component's hash is recorded in a secure log (e.g., in a Trusted Platform Module or TPM). The system will still boot, but it creates a verifiable audit trail of the exact software that was loaded. This log can then be sent to a remote server to "attest" to the device's state, proving what software is currently running.

The two are often used together to provide both enforcement and attestation.

6. Interview Corner

Q1: Explain the concept of a chain of trust. Where does it start and how is it maintained?
A: The chain of trust is the foundation of secure boot. It's a process where each software component is cryptographically verified before it's allowed to run. It starts with a hardware Root of Trust, which is typically immutable code in the SoC's Boot ROM. This RoT verifies the first-stage bootloader using a public key stored securely in hardware (e.g., in OTP fuses). Once verified, that bootloader becomes the new trusted entity and is responsible for verifying the next stage (like the OS kernel). This continues sequentially, with each verified component extending the chain of trust to the next, until the entire system is booted.

Q2: What is the difference between secure boot and measured boot?
A: Secure boot is an enforcement mechanism; it prevents the system from booting if any component fails signature verification. Its goal is to ensure only trusted code ever runs. Measured boot is a recording mechanism; it calculates a hash of each component as it loads and stores these measurements in a secure log. The system may still boot with untrusted code, but this log can be sent to a remote server to attest to the device's software state, allowing the server to decide if it trusts the device.

Q3: You're designing a secure boot system for an automotive ECU. What is the role of the silicon vendor versus you (the Tier 1 developer) in this process?
A: The roles are distinct and form different parts of the chain. The silicon vendor provides the anchor of the chain: the Hardware Root of Trust. This includes the immutable Boot ROM and the mechanism for securely provisioning the initial public key (or its hash), often via OTP fuses. My role as a Tier 1 developer is to build the next link. I would use the private key corresponding to the public key provisioned by the silicon vendor to sign my bootloader. This bootloader, once verified by the Boot ROM, becomes the trusted entity responsible for loading and verifying the rest of the software stack, such as the AUTOSAR OS, middleware, and application layers, which might come from us or other suppliers.

Conclusion

Today, we've established the critical principles behind ensuring a device starts in a known, trusted state. You've seen that secure boot is not a single action but a sequential process that builds a cryptographic chain of trust from an immutable hardware anchor.

Key Takeaways:

• The goal of secure boot is to prevent unauthorized code execution by verifying each software stage before it runs.
• This is achieved by building a Chain of Trust, where each link verifies the next using digital signatures.
• The process is anchored by an immutable Hardware Root of Trust (RoT), typically in the SoC's Boot ROM.
• The RoT uses a Root of Trust Public Key (ROTPK), often protected by storing its hash in OTP fuses, to verify the first mutable software stage.
• Multi-stage bootloaders (e.g., BL1, BL2, BL33) allow for a flexible and secure way to manage software components from different vendors in the supply chain.

Next Lesson Preview:
The entire secure boot process hinges on fast, reliable cryptography and the absolute protection of keys. In our next lesson, we will explore the role of a Hardware Security Module (HSM) and how this dedicated coprocessor is used for high-performance cryptographic operations and secure key storage, making robust security features like secure boot practical in resource-constrained automotive environments.