RidgeRun Platform Security Manual - NXP i.MX95 Yocto Build Process: Security Flow
🚧 Documentation is under development
The RidgeRun Platform Security Manual guide is currently under active development. Some sections may be incomplete or change without notice.
Questions? Contact RidgeRun or email to support@ridgerun.com.
- Introduction
- General Security Concepts
- Getting Started
- Contact Us
- Sponsor your Favorite Feature
Security Flow
This page introduces the security flow that developers should understand before building and validating a Yocto image for the NXP i.MX95 platform. The examples that follow are intended for a Toradex Verdin i.MX95-based system, but the security concepts apply to the i.MX95 boot architecture more generally.
From Fresh to Secure
This roadmap summarizes how a developer can move from a new Yocto project to a platform with the main security protections planned, enabled, and validated. Each step is explained in more detail in the sections that follow.
- Prepare the development environment: obtain the supported BSP, configure the Yocto layers, and create a clean build directory.
- Build a baseline image: build and boot the standard image so the board, boot media, serial console, and basic Linux environment are known to work.
- Enable and validate Secure Boot: configure signing, build signed boot artifacts, verify them on an open development module, and collect boot evidence.
- Add disk encryption when required: select the data to protect, define the early-boot unlock method, and validate successful and failed unlock attempts.
- Define secure OTA updates: authenticate update packages, deliver them through a trusted process, and install them only when they satisfy the update policy.
- Enable and validate antirollback: define the image-version policy and verify that an older image is rejected after a newer version is committed.
- Prepare production evidence: preserve checksums, build configuration, key and fuse records, boot logs, test results, and recovery procedures.
Understanding the i.MX95 Security Flow
The i.MX95 security flow explains how the platform moves from reset to a running operating system while preserving the chain of trust. Several components participate in this process: the Boot ROM starts the device, the EdgeLock Secure Enclave (ELE) makes security decisions, and the boot components load only the software that satisfies the configured policy.
The following explorer presents the security flow through three guided views: the normal boot trace, an authentication validation trace, and the provisioning path used when preparing a device for enforcement. It is useful for following how the different boot and security components interact during each stage of the process.
i.MX95 Security Flow Explorer
Select a view to follow the boot chain, inspect an authentication decision, or review the provisioning path. The explorer illustrates the logic; it does not perform cryptographic operations.
- Reads / checks
- Produces
- Engineer note
Run a validation scenario
ELE authorization trace
The flow can be followed through these main stages:
- Reset and trust anchors: the Boot ROM and ELE start from immutable on-chip code. The device uses the applicable NXP and OEM trust anchors to establish which signing keys can be accepted.
- Boot-source selection: the Boot ROM reads the boot configuration and selects a source such as eMMC, SD, OSPI, or an authorized recovery path.
- Container discovery and loading: the boot flow locates the AHAB container, reads its metadata, and loads the described images into their target memory locations.
- Authentication and optional decryption: ELE validates the container structure, signing-key trust, signature, and image hashes. When encrypted boot is configured, ELE decrypts the image before releasing it for execution.
- Authorization or failure policy: valid images continue. Invalid images are blocked, logged, or redirected to a policy-authorized recovery path according to the device lifecycle state.
- Platform startup and chain of trust: authenticated platform firmware initializes the system and continues the chain through U-Boot, TF-A, optional OP-TEE, Linux, and the application.
The static diagram below provides a complementary overview of the same process. It should be read from left to right, following the numbered stages. The arrows show the order of operations, while the boundaries between the Boot ROM, boot software, and ELE show where authentication or authorization decisions take place.
At a high level, the diagram can be understood as follows:
- Start from an immutable trust point: the Boot ROM begins execution and reads the boot configuration. This first code is part of the device and is not replaced by the Yocto build.
- Load the boot containers: the selected boot source provides the AHAB containers and the images described by them, such as platform firmware, U-Boot, and optionally a trusted execution environment.
- Ask ELE to validate the software: ELE checks the container structure, image hashes, signatures, signing-key hierarchy, and the applicable device policy. If encrypted boot is enabled, the configured flow also decrypts the protected boot artifacts before execution.
- Continue only after authorization: valid software is released to the next boot stage. Modified or unauthorized software is rejected, or the device follows an explicitly supported recovery path.
- Hand off to the operating system: after the trusted boot stages complete, control is transferred to Linux and the application environment.
Together, the explorer and the static diagram explain the sequence but do not replace the detailed procedures. Developers should use the Secure Boot section for signing and validation commands, and the other security sections for disk encryption, OTA, and antirollback.
The i.MX95 secure boot process follows a simple rule: the platform must authenticate security-sensitive firmware before allowing it to execute. The boot device provides the data, but the i.MX95 security hardware decides whether that data is trusted.
The main security authority is the EdgeLock Secure Enclave (ELE). It is an isolated security domain inside the SoC and acts as the platform Root of Trust. ELE authenticates boot images through Advanced High Assurance Boot (AHAB), manages the device lifecycle and secure-debug policy, and protects cryptographic operations and keys.
How the i.MX95 Boots
After reset, the i.MX95 Boot ROM selects a boot source such as eMMC, SD, Octal SPI flash, or USB Serial Downloader mode. The following table shows what each part of the chain does and what the developer should check when validating it.
| Stage | Main component | Main responsibility | Developer checks |
|---|---|---|---|
| Boot ROM | Boot ROM | Selects the boot source and starts the trusted boot path | Boot source configuration and ROM messages |
| Initial firmware | SPL and platform firmware | Loads and initializes the next container | Container-loading messages |
| Security validation | ELE and AHAB | Checks signatures, hashes, and trust anchors | ELE authentication status |
| Bootloader | TF-A/BL31 and U-Boot | Prepares the handoff to the operating system | BL31 and U-Boot logs |
| Operating system | Linux | Starts the platform and application environment | Kernel and system logs |
Typical Yocto artifacts include U-Boot, TF-A/BL31, optional OP-TEE, the Linux kernel, device trees, initramfs, and the root filesystem. The exact list depends on the BSP, machine configuration, boot media, and enabled Yocto features.
Where Trust Is Established
Trust is established across three areas rather than in one file or one tool:
| Area | Role in the trust chain |
|---|---|
| Signing host | Creates the key hierarchy, builds the boot artifacts, and signs the AHAB container with an OEM private key. |
| Device security state | Stores or enforces the trusted SRK hash and lifecycle policy that determine which signing hierarchy can be accepted. |
| ELE during boot | Verifies the container signature, signing-key hierarchy, and image hashes before releasing software for execution. |
The boot media is not itself a trust anchor, and Yocto does not replace the hardware trust anchor. A public key in an image is trusted only when it matches the key hierarchy accepted by ELE and the device lifecycle policy. The detailed signing, provisioning, and validation procedure is available in Secure Boot.
Authentication Versus Confidentiality
Authentication and confidentiality solve different problems. The following comparison helps the developer select the appropriate security procedure.
| Protection | Protects against | Main mechanism | Detailed section |
|---|---|---|---|
| Authentication | Modified or unauthorized firmware | AHAB signatures and image hashes | Secure Boot |
| Confidentiality during boot | Reading protected boot artifacts | Encrypted boot | Secure Boot |
| Data-at-rest confidentiality | Reading stored system data | LUKS/dm-crypt | Disk Encryption |
| Update authenticity | Installing unauthorized updates | Signed update packages | Over-the-Air (OTA) |
| Version policy | Reinstalling older vulnerable software | Antirollback policy | Antirollback |
Development and Production States
The lifecycle state changes how the device responds to security decisions. The module should remain open while the team is proving the signing and recovery flow, and it should move to an enforced state only after the required evidence is complete.
| State | Purpose | Recommended activities |
|---|---|---|
| OEM Open | Development and testing | Sign images, test authentication failures, verify recovery, and inspect boot logs. |
| OEM Closed | Production enforcement | Reject invalid images and apply the approved lifecycle and recovery policy. |
The developer should not close the device until a known-good image boots, modified images fail, recovery works, the trusted SRK hash has been verified, and the complete validation evidence has been recorded. A signed image booting successfully proves that the image is usable, but it does not by itself prove fuse-backed Secure Boot enforcement.
Relationship to the Yocto Build
Yocto prepares the software inputs for the security flow, but it is only one part of the process. The relationship can be summarized as:
Yocto configuration → boot artifacts → signing/encryption → AHAB container → device validation
Yocto produces the boot artifacts and applies the platform configuration used to assemble the image. The signing host protects the private keys and creates the signed container. The device then uses ELE and its security state to decide whether the result can execute. SRK provisioning, lifecycle changes, key protection, negative testing, and production evidence remain controlled activities outside the normal Yocto build.
The practical sequence is to prepare the source tree, configure the security layers and signing variables, build a baseline, sign the AHAB and FIT artifacts, validate them on an open development module, and capture evidence before fuse programming or lifecycle closure.