HABv4 Secure Boot on i.MX RT: A Production Checklist (Fuses, Keys, Encrypted XIP)

Secure boot means the chip only runs firmware you signed. On the NXP i.MX RT10xx this is HAB (High Assurance Boot, version 4): the boot ROM checks a signature on your image against a hash of your public keys that is burned into the chip’s fuses.

The concept is simple. Production is not, because almost every step is one-way. A fuse bit can go from 0 to 1, never back. Burn the wrong value, or burn the right values in the wrong order, and a board on the line becomes scrap. For a product team, the order of the steps matters more than any single step.

In this article I give the checklist I use, in the order that keeps every step recoverable for as long as possible, with the reason behind each one.

The checklist at a glance

The first four steps can be repeated as often as you like. That is where all the testing belongs.

0. Draw the trust boundary first

Decide who is allowed to hold secrets before you generate a single key. My split: the contract manufacturer (EMS) assembles and tests boards with an unsigned test image and no keys. Boards leave the EMS open, with no secrets on them. Signing, fusing and device identity happen in-house.

That one decision keeps the private keys inside one building and makes every later step auditable.

1. Keys: only a hash goes into the chip

HAB uses a small tree of keys. The SRK (Super Root Key) sits at the top. It certifies a CSF key, which signs the command sequence, and an IMG key, which signs the image. The chip stores only a hash of the SRK public keys, in the SRK_HASH fuses.

With NXP’s SPSDK the key tree is one command. Without -ca you only get SRKs, which is not enough to sign:

nxpcrypto pki-tree hab -k rsa2048 -o keys -ca

Two rules matter more than the tool:

1. The private keys never live on a laptop that leaves the building. An HSM is the right home.
2. Choose the key size for the product’s lifetime, not the tutorial. HABv4 supports RSA from 1024 to 4096 bits. Most examples, including mine above, use RSA-2048. NXP’s AN13023 notes that BSI guidance does not accept RSA-2048 for new designs, while RSA-3072 is fine. If your product goes through that kind of review, decide before you fuse anything.

2. Sign the image

In SPSDK 2.0 (October 2023) the old tool names changed: elftosb became nxpimage, and nxpkeygen/nxpcertgen became nxpcrypto. Old tutorials fail quietly because of it.

nxpimage hab get-template -f mimxrt1060 -o hab_template.yaml
nxpimage hab export -c hab_template.yaml -o signed_image.bin

HAB signs a digest of the image. It does not encrypt it. Encryption is a separate step (step 5).

3. Boot the signed image on an open part

This is the step that prevents the most common production brick. Before any fuse is burned, erase the flash, program the final signed image, and boot it on a part that is still open.

In the open configuration HAB checks the signature but only logs a failure and boots anyway. That makes it the perfect test bench: you see every problem in the HAB event log, and the board still works. Do not move on until the log is clean.

4. Burn the SRK hash and check again

Now burn SRK_HASH, reboot, and check the HAB log a second time, this time against the fused hash. The part is still open, so a mistake here still boots. It just means this chip can never be closed with your keys.

5. Encrypted XIP: decide early

Signing proves who wrote the firmware. Anyone with a flash programmer can still read it. If the code itself is worth protecting, the i.MX RT106x can run encrypted code straight from flash with its BEE (Bus Encryption Engine): AES-128, two regions, decrypted on the fly while executing. Other RT10xx parts use OTFAD instead, and the RT1010 has neither.

The fuses involved are BOOT_CFG1[1], which enables encrypted XIP, and the key-select fuses BEE_KEY0_SEL / BEE_KEY1_SEL. These pick either a key derived from the chip-unique OTPMK or a key you burn yourself into SW_GP2.

One more trade-off: encrypted XIP does not work together with flash remapping. If you use MCUboot, that rules out its swap-by-remap mode and leaves overwrite-only updates, without a rollback slot.

6. Close the part

Burning SEC_CONFIG[1] closes the part. From then on, an image that fails authentication does not run: the boot ROM drops into the serial downloader instead.

My policy: the first batch stays open with the SRK fused, so it can still be recovered. Volume units are closed only after the full end-of-line test has passed on them.

Two details are easy to miss:

• Closing does not disable the USB serial downloader (SDP). A separate fuse, SDP_DISABLE, does that. I leave SDP enabled on purpose, as a recovery path.
• On a closed part the boot ROM enables the MPU. A debug or flash tool that worked before may need to disable it first.

7. Lock the debug port and the fuses, last

An open JTAG port bypasses everything above. The i.MX RT1060 Security Reference Manual describes three modes in the JTAG_SMODE fuses: enabled, Secure JTAG (challenge-response), or no debug. SJC_DISABLE gives the strongest protection. The manual also requires the KTE fuse to be burned, or the JTAG mode does not take effect.

The very last step is the lock fuses (BOOT_CFG_LOCK, SJC_RESP_LOCK, the GP locks and others), which stop anyone from burning more bits later. And never burn a reserved fuse.

Who checks what at runtime

A common question once MCUboot is in the picture: does HAB verify every application update? No. HAB verifies the bootloader at every reset. The bootloader then verifies the application with its own signature (ECDSA P-256 in my setup). That means two sets of signing keys, and both belong behind the same trust boundary from step 0.

Summary

1. The order is the safety net. Everything reversible (keys, signing, testing on an open part) happens before anything one-way.
2. Signing is not encryption. HAB proves origin. BEE hides the code, and on the RT106x it comes with a decrypt-only catch for updates.
3. Close late and in stages. First batch open with the SRK fused, volume units closed after their full test, debug and fuse locks last.

💬 Questions, corrections, or your own war story? Leave a comment below.