How to achieve dual HAB authentication for two images (bootloader + app) on i.MX RT1050

[BiHDeveloper]

Hi,

I’m working on a secure boot implementation for the i.MX RT1050 MCU and I’d like to achieve dual image authentication — one for the second-stage bootloader and another for the application image, both located in external flash.

My current setup idea is as follows:

• I plan to use the MCU Secure Provisioning Tool to generate the SRK, IMG, and CSF keys/certificates.

• These keys will be used to sign and authenticate the second-stage bootloader through HAB.

• The application image is stored in flash after the bootloader, and I’d like to be able to update it independently (e.g., via USB or OTA).

At the moment, my idea is to implement a custom authentication mechanism in the second-stage bootloader. The bootloader would:

1. Read the application image footer (containing a public key, SHA-256 hash, and signature) - manually implemented/added on image.

2. Verify the app image authenticity before jumping to it.

However, I’d like to know:

• Is it possible to use NXP-generated certificates (from the Secure Provisioning Tool) or the HAB mechanism itself to authenticate both the bootloader and the application image?

• If so, what is the recommended approach to securely implement HAB authentication for two images (bootloader + app) on i.MX RT1050?

• Should both images be signed using the same SRK/CSF keys, or does NXP provide a supported method for multi-image verification?

Any official guidance, examples, or references to documentation for this type of dual secure boot chain would be greatly appreciated.
At the moment, I only have AN12681.pdf, so I would appreciate advice on how to properly implement this setup using NXP’s recommended method.

Thank you!

[diego_charles]

Hi @BiHDeveloper 

Your custom bootloader can use the  HAB APIs integrated into the bootROM to authenticate the application image, the image could be signed with the same keys and certs than the bootloader. 

I would like to also  recommend you the CST Version 4.0.1, that you can get  from nxp.com. this is the latest version. From the CST you can check the  RM00298
High Assurance Boot Version 4 API Reference Manual.

At this moment I do not have released and simple demo to point you to. But you can take a look at our SBL. More precisely to the api implementation https://github.com/nxp-mcuxpresso/sbl/blob/master/component/secure/semifunc/hab_rvt.c

I hope this helps!

Diego

[BiHDeveloper]

Hi Diego,

Thank you for your reply and the useful references.

I have used the same key set to sign both the bootloader and the application image, and I am invoking the ROM HAB API from within my Second Stage Bootloader to authenticate the application image.
The authentication process works — the function returns a valid reset handler address, meaning the image is successfully verified.

Here’s the relevant call I am using:
load_addr = (uint32_t)hab_authenticate_image_no_dcd(1, ivt_offset, image_start, bytes);

and the implementation of that wrapper:
hab_image_entry_f hab_authenticate_image_no_dcd(uint8_t cid, uint32_t ivt_offset, uint32_t start, size_t bytes)
{
return g_habrvtTree->authenticate_image_no_dcd(cid, ivt_offset, (void **)&start, (size_t *)&bytes, NULL);
}

However, after the authentication succeeds, I call the ROM functions to report the HAB status and events, and I consistently get a WARNING status, even though the image is validated correctly.

Example output:

Hab rvt report status = 0x69, config = 0xcc, status = 0x99
Report event #0 -> 0xf0
[HAB EVENT #0] (44 bytes):
DB 00 2C 43 69 0A C0 00 CA 00 24 00 02 C5 1B 00 00 00 0A 28 20 00 10 ...
...
No more HAB events (status=0x33)

When parsing the first HAB event according to the HAB4 documentation, it indicates:

• 0x69 – Warning

• 0x0A – Unsupported engine

• 0xC0 – Event logged in hab_rvt.run_csf()

• The following sequence 0C C5 1B 00 corresponds to the verification index of image key, HAB_PCL_CMS protocol, DCP engine, and default configuration.

So, from what I understand, the ROM reports a warning because it tries to use the DCP engine during CSF execution, but it is not properly available or initialized in this context.
I have attempted to manually enable and initialize the DCP in my bootloader using the SDK API (DCP_Init() with default config and enabling the DCP clock), but the warning still persists.

The image is verified successfully and executes correctly, but I would like to understand how to avoid or suppress this Unsupported Engine (DCP) warning when authenticating an image from the custom bootloader using HAB ROM APIs.

Any insights into how the ROM initializes the DCP during the primary boot process (or how to replicate that behavior from the second stage bootloader) would be very helpful.

Thanks again

[diego_charles]

Hi @BiHDeveloper 

You are welcome! 

I am very sorry for my delayed response! 

I already replied to you with a test in this thread : https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/HAB-authentication-succeeds-with-WARNING-Unsuppo... 

please help me to check it, and let me know if you have any questions to do so, or any comments, I will wait for your reply. 

Best regards, 

Diego