Secure Boot is often introduced as a simple concept:

Only authenticated software is allowed to run on the device.

While technically correct, this definition hides the real complexity.

Secure Boot is not a single feature, tool, or configuration flag. It is a system-wide trust architecture that starts at silicon power-on and extends through firmware, bootloader, kernel, and eventually user space. Before touching Yocto, signing tools, or vendor workflows, it is essential to understand:

• what problem Secure Boot actually solves
• what it explicitly does not solve
• how trust is established in an embedded system
• where responsibility shifts between hardware and software

This article focuses on those fundamentals.

The Threat Model

Every security mechanism exists to mitigate specific threats. Secure Boot primarily protects against:

• Unauthorized firmware replacement
• Persistent malware in flash storage
• Supply-chain tampering
• Physical access attacks involving storage modification

Typical attack scenarios include:

• Removing eMMC/NAND and flashing modified images
• Replacing bootloader or kernel binaries
• Downgrading firmware to vulnerable versions
• Injecting backdoors into update packages

Secure Boot does not protect against:

• Runtime exploits
• Kernel vulnerabilities
• Logic flaws in applications
• Side-channel attacks

It answers exactly one question:

Can this binary be trusted to execute?

Not:

Is this binary safe?

That distinction matters.

Root of Trust

Every Secure Boot system starts with a Root of Trust (RoT). The Root of Trust is not a single component, but a combination of immutable boot code and hardware-protected key material. In modern SoCs, this typically consists of:

• an immutable Boot ROM inside the processor
• hardware-backed key storage (eFuses / OTP memory / secure elements)

The Boot ROM contains minimal code whose only purpose is:

1. Load the first external boot image
2. Validate its cryptographic signature against a root key hash stored in hardware
3. Transfer execution if verification succeeds

The ROM does not trust keys embedded in software images. Instead, it relies on a public root key (or its hash) permanently programmed into the device.

Because this ROM is manufactured into silicon, it cannot be updated or patched in the field. For this reason, its functionality is intentionally minimal. This immutability makes it the foundation of the entire security model.

If the Root of Trust is compromised, Secure Boot collapses.

Chain of Trust

Once the Root of Trust verifies the first image, a Chain of Trust begins. Each stage becomes responsible for authenticating one or more subsequent components:

• Boot ROM verifies first-stage firmware
• First-stage verifies second-stage
• Bootloader verifies kernel, device tree, and related payloads
• Kernel may verify root filesystem

Every link depends on the integrity of the previous one. This model ensures that:

No unsigned or modified code can execute anywhere in the boot path unless explicitly permitted by the platform’s security policy.

If any verification fails, the system halts or enters recovery. Conceptually, the chain looks like:

Boot ROM → Firmware → Bootloader → Kernel → RootFS

On ARM platforms this often maps to:

• ROM
• Trusted Firmware
• U-Boot
• Linux kernel

This architecture is broadly standardized across vendors and aligns with guidance from organizations such as the Trusted Computing Group and processor vendors like ARM.

Verified Boot vs Measured Boot

Secure boot mechanisms are usually grouped into two related but fundamentally different models: Verified Boot and Measured Boot. While they are often mentioned together, they solve different problems.

Verified Boot

In a Verified Boot model, each boot stage cryptographically authenticates the next one before execution. If verification fails, execution is blocked.

This creates an enforcement-based security model:

• images must be signed by an authorized key
• verification happens synchronously during boot
• failures typically result in halt or recovery mode

In other words, Verified Boot answers the question:

Should this component be allowed to execute?

This is the dominant approach in embedded systems, where preventing unauthorized code execution is the primary goal.

Measured Boot

Measured Boot takes a different approach.

Instead of enforcing policy at boot time, each stage computes cryptographic measurements (hashes) of loaded components and records them in protected registers, often backed by a hardware security module or TPM.

Execution is not blocked.

Instead, measurements are accumulated and made available to later software layers or remote verifiers.

Measured Boot answers a different question:

What actually booted?

This enables:

• remote attestation
• post-boot integrity evaluation
• policy decisions based on system state

Rather than preventing execution, Measured Boot provides visibility.

Complementary Models

Verified Boot and Measured Boot are not mutually exclusive.

High-assurance platforms often combine both:

• Verified Boot enforces authenticity
• Measured Boot provides auditability and attestation

Embedded Linux platforms typically start with Verified Boot and optionally add Measured Boot when higher assurance or remote validation is required.

Measured Boot concepts are commonly associated with standards promoted by the Trusted Computing Group and TPM-based systems, while Verified Boot remains the baseline for most SoC-level secure boot implementations.

In short:

• Verified Boot enforces trust
• Measured Boot reports trust

They address different layers of the same security problem.

Keys, Signatures, and Trust Anchors

Secure Boot relies on asymmetric cryptography:

• private keys are used to sign software components
• public keys are used by the device to verify those signatures

However, not all keys play the same role.

A typical Secure Boot architecture distinguishes between:

• a root key (or root key hash) stored in hardware
• one or more signing keys used during development and production

The root key represents the trust anchor of the system.

Its public portion (or a hash of it) is permanently programmed into the SoC using mechanisms such as eFuses or OTP memory. From that moment forward, the device will only trust images that can be cryptographically traced back to this root key.

This establishes a simple but powerful rule:

The device does not trust software.
The device trusts keys.

Root Keys vs Signing Keys

In practice, the root key is rarely used directly to sign firmware images.

Instead, it is used to authenticate one or more intermediate signing keys, which are then used to sign actual boot components.

This creates a key hierarchy:

• Root key (hardware trust anchor)
• Intermediate or image signing keys
• Firmware, bootloader, and kernel images

This separation serves several purposes:

• limits exposure of the root private key
• allows signing keys to be rotated without reprogramming hardware
• enables different keys for development and production
• supports multiple authorized signers

Without this hierarchy, losing a single private key would permanently compromise every shipped device.

Trust Anchors and Device Lifecycle

Once the root key hash is fused into hardware, it becomes immutable.

From that point on:

• the device’s trust anchor cannot be changed
• all future software must be derived from that key
• recovery options become limited

This is why Secure Boot provisioning is usually treated as a one-way operation.

During early development, devices typically operate in an open or permissive mode. Once products enter manufacturing, the root key is programmed and the device is “closed”.

At that moment, Secure Boot stops being a configuration choice and becomes a permanent property of the hardware.

Why Key Management Matters

Cryptography is rarely the weak point.

Operational practices are.

Compromised signing keys, insecure build systems, or poorly controlled access to private material routinely defeat otherwise well-designed Secure Boot architectures.

For this reason, key management must be considered part of the Secure Boot design itself, not an implementation detail.

We will dedicate a full article later in this series to:

• development vs production keys
• CI integration
• offline signing
• key rotation strategies
• minimizing blast radius when compromises occur

Because in real systems, protecting keys is often harder than protecting code.

What Secure Boot Guarantees

When properly implemented, Secure Boot provides strong guarantees about software authenticity.

Specifically, it ensures that:

• only authorized firmware can execute
• persistent malware cannot survive reboots
• modified boot images are rejected
• supply-chain tampering becomes significantly harder

In other words, Secure Boot establishes cryptographic control over the boot path.

However, these guarantees are intentionally narrow.

Secure Boot does not protect against:

• runtime exploits
• kernel vulnerabilities
• logic flaws in applications
• privilege escalation inside a trusted image

It answers exactly one question:

Is this software authorized to run?

It does not answer:

Is this software correct, secure, or vulnerability-free?

Understanding this boundary is essential when designing real systems.

Secure Boot is a foundation, not a complete security solution.

Where Linux Fits In

Linux is simply another payload in the Secure Boot chain.

From the perspective of the boot process, it is treated no differently than any other firmware component: it is loaded, authenticated, and executed.

Once the kernel starts, Secure Boot has largely completed its job.

Any additional integrity guarantees — such as protecting the root filesystem, enforcing runtime measurements, or validating application code — belong to higher layers of the security architecture.

These mechanisms complement Secure Boot, but they are conceptually separate and will be addressed later in the series.

Summary

Secure Boot is fundamentally about establishing trust from power-on.

It relies on:

• an immutable hardware Root of Trust
• cryptographic verification at every boot stage
• carefully managed signing keys

Everything else — vendor tooling, Yocto integration, provisioning workflows — builds on top of these principles.

Without a clear understanding of this foundation, Secure Boot quickly becomes a collection of opaque commands and scripts.

With it, the entire boot process becomes a structured trust pipeline.

Next: From ROM to Linux — Understanding the ARM Boot Chain

In the next article, we will walk through a real ARM boot sequence step by step:

• Boot ROM
• trusted firmware stages
• bootloader
• Linux handoff

to see exactly where Secure Boot logic lives in practice, and how responsibility for verification moves from hardware to software as the system starts.

This will provide the concrete execution model needed before diving into vendor-specific implementations and Yocto-based workflows.