In the previous article, we examined how trust transitions across a generic embedded boot chain:

Boot ROM → Early Firmware → Bootloader → Linux

We are now almost ready to move from architecture to implementation.

This article serves as a transitional step in the series.

Before diving into the practical aspects of image signing and Yocto integration, it is important to clarify how Secure Boot is actually implemented across different NXP i.MX generations.

Although the underlying principles remain the same — a hardware Root of Trust extending through a verified boot chain — the authentication mechanisms differ significantly between legacy and modern platforms.

In this chapter, we focus on understanding those differences:

• HAB (High Assurance Boot), used on legacy platforms such as i.MX6 and i.MX7
• AHAB (Advanced High Assurance Boot), introduced with i.MX8 and continued in i.MX9

This clarification is essential before moving toward the practical implementation steps in the next article.

Generation 1 — HAB (High Assurance Boot)

HAB is the Secure Boot implementation used in platforms such as:

• i.MX6
• i.MX7

In HAB-based systems:

• Verification logic is embedded directly inside the Boot ROM
• The ROM authenticates the first executable image (typically U-Boot SPL or U-Boot)
• Authentication uses a public key infrastructure anchored in eFuses

HAB Trust Model

HAB relies on:

• Super Root Keys (SRK)
• SRK hash programmed into eFuses
• Signed boot images containing a Command Sequence File (CSF)

The flow looks like:

Boot ROM → Authenticate Image via HAB → Execute

If verification fails:

• the device halts or records a failure event
• depending on configuration, boot may stop entirely

The Boot ROM remains the sole hardware-enforced authority.

There is no separate secure co-processor enforcing policy.

Generation 2 — AHAB (Advanced High Assurance Boot)

With the i.MX8 and i.MX9 families, NXP introduced AHAB.

AHAB represents a significant architectural evolution.

Instead of relying solely on Boot ROM logic, AHAB introduces:

• a dedicated security subsystem (e.g., SECO on i.MX8)
• containerized signed images
• a more structured authentication flow

AHAB Architectural Changes

In AHAB systems:

• The Boot ROM loads a signed container
• Authentication is delegated to a secure execution environment
• Multiple firmware components may be authenticated within a single container

The flow becomes:

Boot ROM → Load Container → Secure Subsystem Verifies → Release Execution

This design:

• decouples verification from minimal ROM code
• allows more complex policies
• supports authentication of multiple firmware components

---

HAB vs AHAB — Structural Comparison

Feature	HAB (i.MX6/7)	AHAB (i.MX8/9)
Root key storage	eFuses (SRK hash)	eFuses (root hash)
Verification engine	Boot ROM	Secure subsystem (e.g., SECO)
Image format	Raw image + CSF	Signed container
Multi-image support	Limited	Native
Architectural complexity	Lower	Higher

The transition from HAB to AHAB mirrors the broader industry shift toward:

• modular firmware stacks
• hardware-assisted security subsystems
• stronger isolation between verification logic and application firmware

---

Super Root Keys (SRK) and Provisioning

The Super Root Key (SRK) is the cryptographic anchor of trust in NXP i.MX Secure Boot implementations.
It is not a single key, but a set of public keys that collectively define which firmware is authorized to execute on a device.

1️⃣ What SRK Really Is

On legacy platforms such as i.MX6, a typical configuration uses:

• 4 RSA key pairs generated offline
• The public keys form the SRK table
• A cryptographic hash of the SRK table is permanently programmed into the device eFuses

The SoC stores only the hash in hardware. At boot, this hash is used to verify that any firmware attempting to run is signed by a key included in the SRK table.

Conceptually, the SRK functions like a Certificate Authority embedded in silicon.

---

2️⃣ Why a Table of Keys?

There are two main reasons for multiple keys:

✔ Key Rotation

If a signing key is compromised, it can be revoked using dedicated SRK revoke bits in the eFuses, without invalidating the entire device.

✔ Separation of Environments

Different keys can be assigned for:

• Development/lab images
• Production firmware
• Recovery
• Reserve/backup

This provides flexibility while maintaining a strong root of trust.

---

3️⃣ Provisioning Flow (HAB on i.MX6)

Step 1 — Generate Keys

Using NXP’s Code Signing Tool (CST):

• Generate RSA key pairs
• Assemble the SRK table
• Compute the hash of the SRK table

Step 2 — Sign Firmware Images

Firmware such as U-Boot SPL, U-Boot proper, or kernel images is signed using the private key corresponding to one of the public keys in the SRK table.
The signature and key metadata are embedded in a Command Sequence File (CSF), which the ROM/HAB library can parse.

Step 3 — Test in Open Mode

Devices initially start in Open Mode:

• HAB verifies signatures but does not enforce fatal halts
• Enables testing and validation of the signing process
• Provides debug output via HAB events

Step 4 — Fuse Programming

Once validation is complete:

• Program the SRK hash into the eFuses
• Optionally, set SEC_CONFIG bits to transition the device into Closed Mode

After this step:

Only firmware signed with a key in the SRK table will boot.
This operation is irreversible.

---

4️⃣ Runtime Authentication

During boot:

1. The ROM reads the SRK hash from eFuses
2. The signed image presents its SRK table
3. The hash of the image’s SRK table is calculated
4. The hash is compared against the hardware-stored value
5. If matched:
   • Verify certificate chain
   • Verify the firmware signature
6. On success → execution transfers to the authenticated image

Any mismatch in the hash or signature causes the image to be rejected before execution.

---

5️⃣ Security Implications

• Lost private keys: Cannot sign future firmware; devices relying on that key become un-updatable.
• Incorrect eFuse programming: Can permanently lock out the device.
• Fuse Programming Ceremony: Industrial deployments enforce multi-step procedures, offline signing, and HSM use to minimize human and operational risk.

---

6️⃣ Preparing for Modern Platforms (AHAB)

In modern platforms (i.MX8/9):

• The principle is the same: a root hash in eFuses defines trust
• Images are containerized, supporting multiple components
• Key management and hierarchy are more flexible
• Provisioning flows still involve careful programming of hardware-rooted trust anchors

The concept remains: the SoC trusts keys, not software, and any bootable firmware must be cryptographically traceable to the SRK.

Device Lifecycle States

Both generations support lifecycle states such as:

• Open (development mode)
• Closed (Secure Boot enforced)

In Open state:

• signatures may be validated but not enforced
• debug access may be available

In Closed state:

• signature verification becomes mandatory
• unauthorized images cannot execute

Understanding lifecycle management is as important as understanding image signing.

Mismanaging device state can permanently lock development hardware.

---

Why This Matters for Yocto

From a build system perspective, HAB and AHAB differ in:

• image structure
• signing tools
• metadata generation
• integration points in the boot chain

Before implementing signing in Yocto, it is essential to know:

• whether your platform uses HAB or AHAB
• which components must be signed
• how containers or CSF files are generated
• when provisioning must occur

The implementation steps differ significantly.

---

Summary

NXP’s Secure Boot architecture evolved from:

• HAB — ROM-centric authentication
  to
• AHAB — subsystem-assisted, container-based authentication

Both enforce a Root of Trust anchored in hardware.

However, their internal trust delegation and image structures differ.

In the next article, we will move from architecture to practice and examine how Secure Boot signing is integrated into a Yocto workflow on a modern i.MX platform.