SECURING IMX RT 1020 WITH HAB — NXP High Assurance Boot

In embedded and IoT systems, ensuring the authenticity of firmware before execution is not optional — it is a fundamental security requirement. The iMX RT1020, a popular NXP Cortex-M7 crossover MCU, addresses this through the HAB (High Assurance Boot) mechanism. HAB provides a hardware-enforced path to external secure boot, preventing unauthorized or tampered firmware from ever executing on the device. For engineers working on connected products via our edge computing services, understanding HAB is essential to building tamper-resistant IoT nodes.

This blog explains the secure boot concepts behind NXP's HAB, the hardware root of trust it establishes, and the practical steps for enabling both Dev Boot and Secure Boot modes on the iMX RT1020.

Secure Boot Concepts: HAB, External Secure Boot, and Hardware Root of Trust

NXP's HAB mechanism uses asymmetric encryption to protect firmware integrity. Asymmetric encryption works by creating a mathematically linked key pair: one key encrypts (or signs) a message and the other decrypts (or verifies) it. It is computationally infeasible to use the encryption key to decrypt the same message. With sufficiently large key sizes, brute-force decryption without the complementary key is practically impossible.

In the context of HAB and external secure boot:

• The private key is used to sign the firmware image. It is kept securely in the provisioning environment and never stored on the device.
• The public key (or its hash) is stored in One Time Programmable (OTP) fuses on the device, establishing a permanent hardware root of trust that cannot be altered after provisioning.
• At boot time, the HAB logic validates the firmware signature using the on-device public key, completing the external secure boot verification chain.

Because the public key hash is burned into OTP fuses, no external party can override or substitute the public key. Any attempt to present a different public key will fail the hash comparison against the OTP values. This is the core of the hardware root of trust established by HAB.

During the device provisioning sequence:

1. A public/private key pair is generated. The private key is secured in the provisioning system.
2. A hash of the public key is computed and burned into the device's OTP fuse area, establishing the hardware root of trust. This prevents any further modification.
3. The firmware image is hashed and signed using the private key. The signed image comprises the firmware, its encrypted hash, and the public key — this bundle is programmed into boot memory.

During the boot validation sequence:

1. The HAB logic extracts the individual components of the signed image.
2. It validates the public key by comparing the computed hash against the value stored in the OTP fuses — a direct check against the hardware root of trust.
3. It calculates the hash of the firmware and compares it with the hash recovered by decrypting the signed hash using the public key.
4. If both checks pass, boot proceeds. If either check fails, HAB aborts the boot, preventing execution of unauthorized firmware.

This complete validation flow is the foundation of external secure boot on NXP iMX RT devices.

Code Signing for iMX RT1020 Using HAB Tools

Code Signing Tools and Workflow

NXP provides all the tools necessary for code signing, key pair generation, and boot flash programming. The key tools are:

• MfgTool — Programs firmware images to the target device over USB in serial downloader mode.
• elftosb — Converts application images (in SREC/ELF format) into boot image (.sb) format that the bootloader can consume.
• CST (Code Signing Tool) — Generates the private/public RSA key pairs and signs firmware images, producing the encrypted hash and certificate structures required by the HAB mechanism.

The device can be programmed using two methods: Dev Boot Mode (for development) and Secure Boot Mode (for production). Once the device is programmed in Secure Boot Mode — with the OTP fuses burned — it is not possible to revert to Dev Boot Mode. All subsequent firmware must be properly signed to pass HAB validation. This one-way transition is an inherent property of any hardware root of trust implementation.

Our Secure Boot for Embedded Systems expertise guides product teams through secure boot enablement processes, ensuring trusted execution on NXP i.MX RT platforms.

Dev Boot Mode

Dev Boot Mode is used during the development and debug phase before the hardware root of trust fuses are burned. To program the device in Dev Boot Mode using MfgTool:

• Create an unsigned boot_image.sb using the elftosb tool from the SREC format application image (app.s19 file).
• Ensure the MfgTool configuration file cfg.ini is present with the following content: chip → MXRT102X, name → MXRT102X-DevBoot.
• Import the boot_image.sb file to …/Tools/mfgtools-rel/Profiles/MXRT102X/OS Firmware from …/Tools/elftosb/linux/amd64/.
• Place the device in serial downloader mode and connect it to the host PC.
• Launch MfgTool and press Start to program the target.
• Click Stop and then Exit to close MfgTool.

In Dev Boot Mode, the HAB mechanism is present in the ROM but is not enforced — the firmware is executed without signature validation, allowing rapid iteration during development.

Secure Boot Mode — Activating HAB with External Secure Boot

Chain of Trust: Burning OTP Fuses

Establishing the chain of trust begins with programming the OTP fuse once with the hash of the public key. This step is irreversible — it permanently configures the hardware root of trust on the device. Use MfgTool as follows:

• Confirm the device is in serial downloader mode.
• Generate private/public key pairs using the CST tool; this produces fuse.bin and fuse.table files containing the public key hash for OTP programming.
• Set cfg.ini to: chip → MXRT102X, name → MXRT102X-Burnfuse.
• Create and import the enable_hab.sb file to …/Tools/mfgtools-rel/Profiles/MXRT102X/OS Firmware from …/Flashloader_RT1020_1.0_GA/Tools/elftosb/linux/amd64/.
• After successfully programming enable_hab.sb, the device OTP fuses are burned and the HAB mechanism is permanently enabled. The device is now ready for external secure boot.

The OTP fuse burn must be executed only once. After this point, the chain of trust is anchored in hardware and cannot be modified.

Code Signing and Flashing the Signed Image

To program the device with a signed image after the OTP fuses are burned, the code signing step must be completed first using the CST tool. Then use MfgTool as follows:

• Create a signed boot_image.sb using elftosb from the SREC format application image (app.s19). The signing process uses the private key to create the HAB-compatible signed image bundle.
• Set cfg.ini to: chip → MXRT102X, name → MXRT102X-SecureBoot.
• Import the signed boot_image.sb file to …/Tools/mfgtools-rel/Profiles/MXRT102X/OS Firmware from …/Flashloader_RT1020_1.0_GA/Tools/elftosb/linux/amd64/.
• Run MfgTool to program the signed image. On next boot, HAB will validate the signature against the hardware root of trust stored in OTP, and boot will proceed only if the chain of trust is intact.

Full process details can be found in the NXP iMX RT1020 product documentation. Once secured, it is impossible to execute unauthorized software. The same HAB-based code signing concepts extend naturally to OTA firmware updates — new firmware images can be authenticated by the HAB mechanism before they are programmed, ensuring the external secure boot guarantee holds across the device lifetime.

About Embien

Embien has been actively developing IoT devices that form critical parts of larger connected networks, where security breaches carry significant consequences. We have extensive experience applying advanced tools and techniques — including NXP HAB, external secure boot, and hardware root of trust provisioning — to prevent unauthorized access and firmware tampering. Get in touch with us to give your design the security it deserves.