NXP i.MX95 Yocto Security Build Guide: Secure Boot, OTA and Encryption
- Introduction
- General Security Concepts
- Getting Started
- Contact Us
- Sponsor your Favorite Feature
The NXP i.MX95 Yocto build process connects a working embedded Linux image to platform-security procedures for AHAB Secure Boot, disk encryption, authenticated over-the-air (OTA) updates, and anti-rollback. Using the Toradex Verdin i.MX95 as the documented reference platform, this guide explains where to begin, which security procedure to follow, and how to validate changes before considering production provisioning. Steps and results depend on the Yocto BSP release, board configuration, boot media, and security lifecycle state.
This section explains how the security features of the NXP i.MX95 platform fit into a Yocto-based development workflow. The developer should first prepare and build a working reference image, confirm that the board boots correctly, and then apply the security procedures in the order that matches the product requirements.
The security flow provides the overall sequence, while the following sections describe how to configure, build, install, and validate each protection. The procedures are based on a Toradex Verdin i.MX95 platform and should be adapted when a different BSP, machine configuration, or boot-media layout is used.
Before Enabling Security Features
Establish a reproducible baseline before changing signing, storage, or update configuration:
- Prepare the BSP, supported Yocto layers, host tools, and target machine configuration.
- Build and boot the reference image on the target board and record the build configuration.
- Verify the boot medium, serial console, bootloader and Linux logs, and available recovery method.
- Identify the device lifecycle state and protect any signing credentials used during development.
- Select the security procedures according to the product threat model and update strategy.
Validated Yocto Environment
The Yocto-based i.MX95 image used for the security workflow is as follows:
| Environment Component | Validated Configuration |
|---|---|
| Yocto BSP | Toradex BSP 7.6.1 |
| Reference distro | tdx-xwayland
|
| Yocto branch | scarthgap-7.x.y (Yocto 5.0 Scarthgap)
|
| Linux | 6.6.138-7.6.1-devel
|
| Kernel | linux-toradex
|
| Image | tdx-reference-minimal-image — Verdin-iMX95_Reference-Minimal-Image
|
Security Flow
The RidgeRun Security Flow page provides the platform overview and the “From Fresh to Secure” roadmap.
Security Procedures
The following security hardening procedures for i.MX 95 are covered by RidgeRun's guide:
| Security mechanism | What it protects | Implementation guide |
|---|---|---|
| AHAB Secure Boot | Authenticates supported boot components using the configured hardware-backed trust chain. | Secure Boot |
| Disk Encryption | Protects data stored on the device against unauthorized access. | Disk Encryption |
| Secure OTA Updates | Authenticates software updates and supports controlled update and recovery workflows. | Over-the-Air (OTA) |
| Anti-rollback | Prevents use of software versions prohibited by an enforced version policy. | Antirollback |
Each procedure identifies its required setup, tools, commands, validation steps, and limitations. The developer should complete the baseline build and installation before beginning the security-specific validation.
FAQ
- How do I secure a Yocto Linux image on NXP i.MX95?
- Start with a working Yocto build, then select the protections required by the product threat model. The RidgeRun guide covers AHAB Secure Boot, disk encryption, authenticated OTA updates, and anti-rollback procedures.
- How does AHAB Secure Boot fit into the NXP i.MX95 Yocto build?
- Yocto produces the relevant boot artifacts, while the signing workflow prepares authenticated AHAB boot containers using NXP's Code Signing Tool (CST) and the platform's key hierarchy. The i.MX95 hardware security architecture, including EdgeLock Secure Enclave (ELE), participates in boot authentication. See the i.MX95 Secure Boot procedure for supported signing and validation steps.
- Does a signed i.MX95 image booting on an OEM Open module prove production Secure Boot enforcement?
- No. A successful signed-image boot in an OEM Open development state demonstrates that the selected build and signing path can work; it does not by itself prove the enforced production lifecycle and fuse policy. Production closure and irreversible provisioning require separate validation and authorization.
- What is the difference between secure OTA rollback and anti-rollback?
- OTA recovery or rollback allows a device to recover safely from a failed update. Security anti-rollback prevents use of software versions that are no longer permitted by the version policy. Both require explicit design and validation; see the OTA guide and anti-rollback guide.
Related Documentation
- NXP i.MX95 platform security overview
- i.MX95 security architecture and flow
- NXP i.MX95 Yocto reference build
- RidgeRun Platform Security Manual
For assistance integrating security into an NXP i.MX95 Yocto product, contact RidgeRun.