Secure Boot / Image Validation – AHAB API Usage on i.MX93

[csenatore]

Hello NXP team,

I am encountering an issue on the i.MX93 in the context of Secure Boot and image validation.

My goal is to validate the flash.bin before storing it to the eMMC. Specifically, only trusted images should be saved to ensure a successful boot after the next reset.

Relevant keywords in this context:

• PDoS (Permanent Denial-of-Service)

• Secure Boot Bricking Attack

• Time-of-check to time-of-use (TOCTOU)

For my test environment, I plan to implement the validation and storage of the boot firmware in U-Boot, and later move this into the Linux system.

In U-Boot, we are using the following interface:

cntr_length = cntr_hdr->length_lsb + (cntr_hdr->length_msb << 8);
auth_hdr = ahab_auth_cntr_hdr(cntr_hdr, cntr_length);
if (!auth_hdr)
    goto ahab_release;

We use the ELE firmware only to verify the CNTR_HDR with its signature.
Checksum verification is done in software, as the ELE firmware requires the images to be in their load address in order to verify them.

if (!cntr_hdr->num_images)
    goto ahab_release;

img_idx = (struct boot_img_t *)((u8 *)cntr_hdr + sizeof(struct container_hdr));

for (i = 0; i < cntr_hdr->num_images; i++) {
    void *img_ptr;
    img_ptr = (void *)cntr_hdr + img_idx[i].offset;

    ret = cntr_image_check_sha(&img_idx[i], img_ptr);
    if (!ret)
        goto ahab_release;
}

ahab_release:
ahab_auth_release();

This method works for all containers, including 2nd boot containers (e.g., U-Boot SPL, Cortex-M firmware) and all application containers. The signatures and SHA checksums can be successfully validated.

However, this method does not work for the 1st boot container (ELE firmware).
When calling ahab_auth_cntr_hdr(cntr_hdr, cntr_length);, I get the following error:

Error: ele_auth_oem_ctnr: ret -5, cntr_addr 0x80000000, response 0x551ff29

As a result, the ELE firmware triggers a reset.

Booting the flash.bin via Serial Download or from eMMC works fine on a closed board.

The only difference between the ELE-FW container and the BOOT/APP containers is that the NXP-SRK flag is set instead of the OEM-SRK flag.

My questions are as follows:

• Can the ELE-AHAB API be used to verify NXP-signed containers at runtime from user space?

• Is it generally possible to use the ELE-AHAB API for signature verification, or would it be better to implement a custom software-based method to verify the HDR signature?

If the latter is the case, where can I find more detailed information about the SRKH (Super Root Key Hash) values used for NXP-signed containers?
If I need to implement the ahab_auth_cntr_hdr method manually, I would need to know the exact fuse locations of the SRKH on all processors that support AHAB.

Thank you very much for your support.

[Harvey021]

Hello @csenatore 

"This method does not work for the 1st boot container" - this is expected because this API doesn't work for ELE container.

Per the questions:

(1) No, the API can only used to authenticate OEM containers. Why do you want to authenticate ELE container? The ELE container is signed by NXP and directly downloaded as binary. When the device boots up, the ELE ROM will authenticate the FW, after it pass, then the OEM containers will be loaded and authenticated.

(2) The BSP use the ELE-AHAB API for signature verification if secure boot is enabled, but yes, you can implement a custom software-based method to verify.

The NXP SRKH fuses are not visible by user. User can only read the OEM SRKH fuses.

Regards

Harvey

[csenatore]

Hello @Harvey021 ,

Thank you very much for your quick response.
First, here are the answers to your questions:

"Why do you want to authenticate the ELE container?":
My goal is to verify all images or container elements for validity before storing them.
The reason for this is to ensure a secure and guaranteed boot process after an update.

In the field, the firmware is always received from an untrusted source within a security context, regardless of whether it's delivered over the internet or via an external interface such as USB devices.

Whoever controls the external source also controls what is stored.
Therefore, I want to implement an end-to-end validation of the images.
The i.MX93 is capable of verifying the container to be stored based on the signature and the SRKH values.

If the images are not verified before being written to storage, there is no way to ensure that they haven’t been tampered with.

Here is a simple example:

An attacker gains access to an external update source and replaces flash.bin with a malicious flash-evil.bin.
This flash-evil.bin contains a tampered 1st boot container (ELE firmware).

Scenario 1:

The ELE image is filled with NULL data, but the container header remains unchanged.
In this case, the SHA hash in the container header will not match the image content.
A hash check will detect this mismatch, and the image will not be stored.

Scenario 2:

The ELE image is filled with NULL data, and the SHA hash in the container header is adapted to match the tampered image.
Now, the hash check of the image content matches the header, and the image is seen as valid.
If this is an OEM container, the signature of the container header can be verified, and the mismatch will be detected.
However, for NXP containers, I don’t have a way to verify the header signature.
I must assume the signature is valid.

This forces me to store a faulty container.

If the board is closed (i.e., secure boot is enabled), the attacker has successfully executed a Denial-of-Service (DoS) attack, because during AHAB secure boot, a container with an invalid signature cannot be loaded.
The system will not boot, resulting in a critical failure.
If the malicious flash-evil.bin is distributed through an online update infrastructure accessed by multiple boards simultaneously, the damage multiplies.

So my key question is:

What options do I have to verify the ELE firmware, which is obtained from untrusted sources, before storing it as the next boot image on the eMMC?

The only approach I can currently think of is to parse the signature block, extract the certificate and SRKs, recalculate the SRKHs, and verify them within my own application logic.

How do you assess the risk of DoS attacks in a secure boot context?
In your opinion, what is the best way to protect against this?
Has NXP perhaps already provided a solution or at least a recommendation to address this issue?

Thank you very much for your support.

[Harvey021]

Hello @csenatore 

The design target is to prevent the malicious FW from booting up on device, so if the ELE FW container failed to be authenticated or verified, the device cannot boot up. We have no way to know whether the boot images in external storage was replaced/corrupted.

"The only approach I can currently think of is to parse the signature block, extract the certificate and SRKs, recalculate the SRKHs, and verify them within my own application logic."

- Yes, I think this method should be feasible.

In addition, the chip support Primary Boot Container Set and Secondary Boot Container Set. The Secondary Boot Container Set is a copy of the Primary Container Set. ROM will always try to load the Primary Container Set first and if the Primary Container Set fails, ROM will then attempt to load the Secondary Container Set. So one method may can help here is to use Secondary Container Set as backup boot image in case of Primary Boot failure. More details can be found in i.MX93 Reference Manual.

Regards

Harvey