RT1020 HAB Boot Issue , with MCUXpresso Security Provisioning Tool

[Seongyon_Jeong]

Hello, I'm an embedded developer working with the RT1020 EVK platform.

I have studied and followed the first two tutorial videos on the following site:
https://www.nxp.com/design/design-center/training/TIP-MCUXPRESSO-SECURE-PROVISIONING-TOOL

The project I’m testing is based on the shell demo app from the SDK examples.
I’m conducting tests with the boot mode always set to Authenticated (HAB) to support secure boot functionality.

However, I've encountered some confusing results that I cannot fully explain.
Here is a detailed summary of the test steps and observations:

---

Key Generation and Image Creation

After generating keys and applying them, I set XIP_BOOT_HEADER_ENABLE=0 in the shell demo project, then built the project in MCUXpresso IDE, which produced evkmimxrt1020_shell.axf. Using the MCUXpresso Secure Provisioning Tool (SPT), I created the following three binaries via the Build Image tab:

• evkmimxrt1020_shell.bin

• signed_MIMXRT1020_flashloader.bin

• unsigned_MIMXRT1020_flashloader.bin

---

1. Board A (Fuses Burned, HAB Enabled)

This board has gone through the full process in the tutorial videos, and the fuses have already been programmed.

(1-a) Flash evkmimxrt1020_shell.bin

• Mode: Serial Downloader

• Image: evkmimxrt1020_shell.bin

• No fuse warning popup (as expected, fuses already burned)

• Result: Successful write, board boots normally

(1-b) Flash signed_MIMXRT1020_flashloader.bin

• Result: Successful write, but board does not boot Why?

(1-c) Flash unsigned_MIMXRT1020_flashloader.bin

• Result: Successful write, but board does not boot (expected)

---

2. Board B (HAB Not Yet Enabled)

This board has not been fused yet.

(2-a) Flash evkmimxrt1020_shell.bin

• Fuse warning popup appears → Chose "NO (write image only)"

• Expectation: Board should not boot

• Result: Board boots successfully Why??

(2-b) Flash signed_MIMXRT1020_flashloader.bin

• Result: As expected, board does not boot

(2-c) Flash unsigned_MIMXRT1020_flashloader.bin

• Expectation: Board should boot normally

• Result: Does not boot Why?

---

3. Flashing via MCUXpresso IDE GUI Flash Tool (Board A, internal boot mode)

(3-a) Flash .axf (XIP_BOOT_HEADER_ENABLE=0)

• Result: Does not boot

(3-b) Flash .bin

• Result: Does not boot

(3-c) Flash signed_MIMXRT1020_flashloader.bin

• Result: Does not boot

(3-d) Flash unsigned_MIMXRT1020_flashloader.bin

• Result: Does not boot (expected)

(3-e) Flash .axf (XIP_BOOT_HEADER_ENABLE=1)

• Result: Does not boot

---

4. Flashing via MCUXpresso IDE (Board B, internal boot mode)

(4-a) Flash .axf (XIP_BOOT_HEADER_ENABLE=0)

• Result: Boots successfully

(4-b) Flash .bin

• Result: Does not boot

(4-c) Flash signed_MIMXRT1020_flashloader.bin

• Result: Does not boot (expected)

(4-d) Flash unsigned_MIMXRT1020_flashloader.bin

• Expectation: Should boot

• Result: Does not boot Why?

(4-e) Flash .axf (XIP_BOOT_HEADER_ENABLE=1)

• Result: Boots successfully

---

My Main Questions

1. Why do cases 1-b and 1-c fail to boot on Board A, even though the fuses are already burned and the board is HAB-enabled?

2. From the results of 1-a and 2-a, it seems that flashing evkmimxrt1020_shell.bin may implicitly select the proper signed/unsigned flashloader image based on the HAB status.
   Is this correct?
   If not, does the evkmimxrt1020_shell.bin file internally include both the signed and unsigned versions of the flashloader?
   (This seems unlikely based on file sizes.)

3. In case 2-c, the board does not boot even though it’s unfused and the unsigned image was used.
   Why does this happen?
   The same issue is observed in 4-d as well.
   Since the MCUXpresso IDE can flash .bin files directly, I expected it to boot in this case.

4. In 3-b and 3-c, Board A does not boot even when using the correct .bin or signed flashloader image.
   Could this be a limitation of flashing via IDE rather than via SPT?
   And, what exactly is the signed_MIMXRT1020_flashloader.bin image?
   Is it not the signed application image?

5. For all 1, 2, 3, 4 test cases, I’ve listed the expected result and the actual result.
   Please let me know if any of my expectations were incorrect, or if any of my test methods were flawed.

6. Based on my experiments, I am questioning my understanding of Authentication (HAB) secure boot.

I originally understood HAB secure boot to serve the purpose of ensuring image integrity and preventing tampering.
However, based on my test results, this no longer seems to be the full picture.

Now I wonder:

Is the actual purpose of the signed image in HAB not just integrity checking,
but also to bind the image to a specific board (or manufacturer),
such that the image only works on a device with matching keys/fuses?

For example, in my tests, the signed image only boots on Board A when written via the Secure Provisioning Tool’s Write Image function, using the original .bin (not directly flashing the signed image separately).

This behavior makes me question my earlier belief that:

"A signed image embedded in the production board should not boot on a 3rd-party board (even if copied),
regardless of whether the image has been modified or not."

Isn't this the core security goal of HAB —
to prevent unauthorized devices from executing even legitimate (but cloned) firmware?

Therefore, in my experiment with Board B (HAB not enabled),
when I write only the signed image (without burning any fuses), and it fails to boot —
isn't that the expected result which proves this security model?

I’d appreciate confirmation or correction if my interpretation is off.

[marek-trmac · Accepted solution]

Hi,

(A) about "flash flashloader": the flashloader delivered in SEC tool was built to RAM. Probably it could be possible to run is as "load-to-ram" image. On the build page, if you signed your application, the flashloader is signed too, but it is expected to run in the RAM. Can you clarify how your flashloader was built? What is the start address and entry point? What flashloader application is it? Did you run flashloader in the debugger and it worked? 

(B) about signature verification: HAB always verifies the image signature, if the HAB is disabled, the image boots also if the signature is not valid; if HAB is enabled, the image boot only with valid signature

(C) about XIP_BOOT_HEADER_ENABLE: this option creates the image with the header, that contains FCB (flash config block) and some other stuff needed for bootable image. In SEC tool the header is created by nxpimage tool, so it is not needed in the source image. Latest version of the SEC tool automatically removes the header from the source image. So basically with XIP_BOOT_HEADER_ENABLE=0 and XIP_BOOT_HEADER_ENABLE=1, the SEC tool should work. The only difference is, with XIP_BOOT_HEADER_ENABLE=1 it is possible to "reuse" FCB configuration from the source image header. 

1. Why do cases 1-b and 1-c fail to boot on Board A, even though the fuses are already burned and the board is HAB-enabled?
   See (A)

2. From the results of 1-a and 2-a, it seems that flashing evkmimxrt1020_shell.bin may implicitly select the proper signed/unsigned flashloader image based on the HAB status.
   Is this correct?
   If not, does the evkmimxrt1020_shell.bin file internally include both the signed and unsigned versions of the flashloader?
   (This seems unlikely based on file sizes.)
   Yes, SEC tool automatically uses signed flashloader if HAB is enabled.

3. In case 2-c, the board does not boot even though it’s unfused and the unsigned image was used.
   Why does this happen? 
   The same issue is observed in 4-d as well.
   Since the MCUXpresso IDE can flash .bin files directly, I expected it to boot in this case. 
   See (A)

4. In 3-b and 3-c, Board A does not boot even when using the correct .bin or signed flashloader image.
   Could this be a limitation of flashing via IDE rather than via SPT?
   And, what exactly is the signed_MIMXRT1020_flashloader.bin image?
   Is it not the signed application image?
   See (A)

5. For all 1, 2, 3, 4 test cases, I’ve listed the expected result and the actual result.
   Please let me know if any of my expectations were incorrect, or if any of my test methods were flawed.
   See (A) and (B)

The main purpose of the image authentication is to avoid running untrusted FW in your product (HAB verifies authenticity of the FW).

You can consider to encrypt the FW to avoid run it on 3-rd party board.

[Seongyon_Jeong]

Because of  many Question..  I divided my reply with two part.

anyway,

1 & 3 & 4 question : See(A)
   => Ah, I see. So both signed_xxxx.bin and unsigned_xxxx.bin are actually RAM-executable images, not XIP images meant to boot directly from flash. Right?

2. thanks.


You mentioned that the SEC tool automatically uses a signed flashloader when HAB is enabled.
Now, I’d like to ask something based on that.

Before executing “Build Image” in the SEC tool, I uploaded the xxxx.axf image to Board B (HAB-disabled).
Separately, I also flashed the image to Board A (HAB-enabled) using the SEC tool’s “Write Image” function.

In both cases, I used a Shell project that includes a memory dump command I had implemented.
In the “Build Image” tab, the Start Address was set to 0x60002000, and since the flash base address is normally 0x60000000,
I dumped around 400 bytes starting from that base address and printed it on the console.

Interestingly, the dumped data was identical on both Board A and Board B.
I was expecting the hex image to differ, especially since you mentioned that the flashloader is a “load to RAM” image.
So I assumed the actual flashloader might exist somewhere else in memory.

Is it possible to know where exactly this image is stored?
If the location is confidential or considered an NXP internal detail, could you at least confirm whether my observation —
that the data at the beginning of flash is the same on both boards — is correct?

[marek-trmac]

Hi
> So both signed_xxxx.bin and unsigned_xxxx.bin are actually RAM-executable images, not XIP images meant to boot directly from flash. Right?

That's right.

For the second question:
The XIP application image should be built to address 0x60002000 and it is stored at that address.
The load-to-RAM application is also stored at 0x60002000. Region 0x60000000-0x60002000 contains flash configuration block and some other info for the bootable image.

[Seongyon_Jeong]

Based on the content of (B), I understand that on a board with HAB disabled (i.e., someone who purchased an RT1020EVK board from NXP), even if our company’s signed firmware (a fully copied or stolen image of the total hex data) is loaded, the board will boot regardless of whether the signature is valid or not.
That is why I assume you said, “You can consider to encrypt the FW.”

However, since I haven’t studied encryption yet, I would like to ask in advance.

I’ve seen a diagram showing that the BEE module, which supports encryption, is directly connected to the flash.
Is it possible to configure it so that only a specific region of the flash is decrypted through the BEE module when read?

The reason is because we divide the flash into areas for fixed code and for non-volatile data. Although there is concern about flash lifetime during runtime, our firmware performs a lot of flash writing actions.
If we need to encrypt the data each time during runtime via a software function to update the non-volatile data and upload it to flash, we expect it to place a heavy load on the system.

Also, our firmware is structured to copy the fixed code section into SDRAM during runtime and follows this boot sequence:
ROM Boot (on-chip code) → XIP Boot (our firmware) → SDRAM Jumping Boot (our firmware).

So, assuming encryption is used, when the fixed code (firmware) is copied into SDRAM, the memory is copied like this:

In this case, even when copying encrypted data from flash, will it be decrypted by the BEE and stored in SDRAM?
I am concerned because during the Jump Boot to SDRAM, the BEE will clearly not be involved, and I fear that the device may go down as a result.

Given this situation, we believe that implementing encryption may be difficult at this time.
Do you have any recommendations or alternative approaches we could consider?

[marek-trmac]

Hi,
yes, you can select BEE region which is encrypted.
Decryption is done during the flash read; you do not need to do anything else.

ROM is capable to use "load-to-RAM" image and copy it from NOR flash into SDRAM, you need to use DCD file to initialize SDRAM during boot time. If the image is encrypted, it will be decrypted during copying.