Colibri iMX7D secure-boot: HAB errors after fusing SRK (U-Boot appears unsigned)

Technical Support
, ,
1

Subject: Colibri iMX7D secure-boot: HAB errors after fusing SRK (U-Boot appears unsigned)

Hardware / SW

  • Module: Colibri iMX7D SoM
  • Goal: Enable NXP HABv4 secure boot
  • Yocto: 7.3.3
  • Layers: meta-toradex-security (downloaded from Toradex)
  • CST: NXP CST 4.1 (keys generated with this version)

Configuration (local.conf)
INHERIT += “tdx-signed”
INHERIT += “imx-hab”
DISTRO_FEATURES:append = " security"
SECURE_BOOT = “1”
U_BOOT_SIGNED = “1”

TDX_IMX_HAB_ENABLE = “1”
TDX_IMX_HAB_CST_DIR = “${TOPDIR}/keys/cst”
TDX_IMX_HAB_CST_CERTS_DIR = “${TDX_IMX_HAB_CST_DIR}/crts”
TDX_IMX_HAB_CST_CRYPTO = “rsa”
TDX_IMX_HAB_CST_KEY_SIZE = “2048”
TDX_IMX_HAB_CST_KEY_EXP = “65537”
TDX_IMX_HAB_CST_DIG_ALGO = “sha256”
TDX_IMX_HAB_CST_SRK_CA = “1”
TDX_IMX_HAB_CST_SRK_INDEX = “1”

TDX_IMX_HAB_CST_SRK = “${TOPDIR}/keys/cst/crts/SRK_1_2_3_4_table.bin”
TDX_IMX_HAB_CST_SRK_FUSE = “${TOPDIR}/keys/cst/crts/SRK_1_2_3_4_fuse.bin”

TDX_UBOOT_HARDENING_ENABLE = “1”
TDX_UBOOT_HARDENING_ENABLE_DBG = “0”
TDX_CHECK_UNSUPP_BOOTMETH = “1”
TDX_DISABLE_UNSUPP_BOOTMETH = “1”

FIT signing (kernel/DTB authenticity)

UBOOT_SIGN_ENABLE = “1”
FIT_GENERATE_KEYS = “1”
UBOOT_SIGN_KEYDIR = “${TOPDIR}/keys/cst”
UBOOT_SIGN_KEYNAME = “CSF1_1_sha256_2048_65537_v3_usr”
UBOOT_SIGN_IMG_KEYNAME = “IMG1_1_sha256_2048_65537_v3_usr”

What we did

  1. Generated SRK/CSF/IMG keys with CST 4.1.
  2. Built the image. The build produced fuse-cmds.txt under the image deploy path.
  3. Flashed the image and booted before fusing → hab_status shows no HAB errors.
  4. Programmed fuses exactly as listed in fuse-cmds.txt (SRK hash and related words).
  5. Rebooted → now hab_status reports HAB events/errors. From the errors we inferred U-Boot is not being accepted as signed.

Problem

  • After fusing the SRK hash, HAB rejects the boot image. It looks like U-Boot is not signed (or the CSF doesn’t match the fused SRK) even though:
    • Signing is enabled in the build (see config above), and
    • We used the fuse commands generated by the build.
  1. For Colibri iMX7D with meta-toradex-security, are the variables above sufficient to ensure the U-Boot container (u-boot.imx) is signed with a valid CSF**?
  • Do we also need any board/machine-specific settings (e.g., additional TDX_* or UBOOT_* variables) to embed the CSF into u-boot.imx?
  1. Is U_BOOT_SIGNED = "1" redundant or required when INHERIT += "tdx-signed" and INHERIT += "imx-hab" are set?
  2. Does UBOOT_SIGN_ENABLE = "1" (FIT signing for kernel/DTB) interact with or gate the HAB CSF signing of U-Boot on i.MX7D, or are these independent knobs?
  3. The build generated fuse-cmds.txt. Can you confirm this file contains the correct SRK hash endianness/words for i.MX7D on Toradex BSP 7.3.3?
  4. Are there known issues with CST 4.1 and BSP 7.3.3 for i.MX7D (e.g., SRK CA vs. user certs, SRK index mismatch, or CSF version fields) that could cause HAB rejection after fusing?
  5. On i.MX7D specifically, should we expect the signed artifact to be u-boot.imx (U-Boot + IVT + DCD + CSF), and if so, which target(s) in your layer produce that file with an attached CSF?

Thanks in advance—any guidance or known-good config snippet for iMX7D + BSP 7.3.3 would be very helpful.

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Colibri iMX7D Secure Boot Configuration and HAB Issues

Your configuration looks mostly correct, but there are several important considerations for Colibri iMX7D secure boot implementation.

Known Secure Boot Vulnerabilities on Colibri iMX7D

First, be aware that there are known secure boot vulnerabilities affecting Colibri iMX7D modules (1). According to the errata documentation, Errata #2: HAR-11298 - Secure Boot Vulnerabilities (NXP ERR010872 and ERR010873) affects:

  • Colibri iMX7D 512MB V1.1D WinEC and earlier
  • Colibri iMX7D 512MB V1.1A
  • Colibri iMX7D 1GB V1.1A

These errata affect all i.MX and Vybrid processors when using security enabled configuration (SEC_CONFIG[1] eFUSE is programmed) (1). The fix is listed as “not scheduled” (1).

Configuration Analysis

Your configuration appears comprehensive, but here are key points to verify:

1. Redundant Variables

U_BOOT_SIGNED = "1" may be redundant when using INHERIT += "tdx-signed" and INHERIT += "imx-hab", as these classes should handle the signing configuration automatically.

2. FIT vs HAB Signing Independence

UBOOT_SIGN_ENABLE = "1" (FIT signing for kernel/DTB) is independent from HAB CSF signing of U-Boot. These are separate security mechanisms:

  • HAB signing protects the bootloader itself
  • FIT signing protects the kernel and device tree

3. CST Tool Compatibility

There are known compatibility issues with NXP CST tool version 4.0.0 and later on older Linux distributions. Since you’re using CST 4.1, ensure you’re running on a recent Linux distribution (Ubuntu 24.04 or similar) for proper compatibility.

Troubleshooting Steps

  1. Verify Build Artifacts: Confirm that your build produces a signed u-boot.imx file with embedded CSF. The signed artifact should be larger than the unsigned version.

  2. Check HAB Events: Use hab_status command to get detailed information about the specific HAB events occurring after fusing.

  3. Validate Fuse Commands: The fuse-cmds.txt file should contain the correct SRK hash for your generated keys. Double-check that the fuse programming completed without errors.

  4. CSF Configuration: Ensure your CSF configuration matches the SRK index you specified (TDX_IMX_HAB_CST_SRK_INDEX = "1").

Alternative Approach

Given the known secure boot vulnerabilities on Colibri iMX7D (1), you might want to consider migrating to a newer platform. As noted in the community discussion (2), for secure boot requirements, the recommendation is to consider using Verdin AM62 Solo as an alternative to older iMX modules.

Next Steps

  1. Check your specific Colibri iMX7D hardware revision against the errata list (1)
  2. Verify that your Linux distribution is compatible with CST 4.1
  3. Examine the detailed HAB events to understand the specific authentication failure
  4. Consider testing with a minimal configuration first, then gradually adding complexity

The secure boot implementation for iMX-based platforms uses NXP’s HAB (High Assurance Boot) feature, and the configuration you’ve provided should theoretically work, but the known errata may be impacting your implementation.

Best regards, Toradex AI Assistant.

3
  1. We are using Colibri iMX7D 1GB V1.1A
  2. u-buntu version is 24.04
  3. my u-boot size is not changing
  4. CSF Configuration: We are using SRK_INDEX 1 only
    Before Fuse programing
    hab_status

Secure boot disabled

HAB Configuration: 0xf0, HAB State: 0x66
No HAB Events Found!

After Fuse Programing
Secure boot disabled HAB Configuration: 0xf0, HAB State: 0x66 --------- HAB Event 1 ----------------- event data: 0xdb 0x00 0x14 0x42 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x87 0x7f 0xf4 0x00 0x00 0x00 0x00 0x20 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) --------- HAB Event 2 ----------------- event data: 0xdb 0x00 0x14 0x42 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x87 0x7f 0xf4 0x2c 0x00 0x00 0x01 0xb4 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) --------- HAB Event 3 ----------------- event data: 0xdb 0x00 0x14 0x42 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x87 0x7f 0xf4 0x20 0x00 0x00 0x00 0x01 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) --------- HAB Event 4 ----------------- event data: 0xdb 0x00 0x14 0x42 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x87 0x80 0x00 0x00 0x00 0x00 0x00 0x04 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) --------- HAB Event 5 ----------------- event data: 0xdb 0x00 0x14 0x42 0x33 0x21 0xc0 0x00 0xbe 0x00 0x0c 0x00 0x03 0x17 0x00 0x00 0x00 0x00 0x00 0x58 STS = HAB_FAILURE (0x33) RSN = HAB_INV_CERTIFICATE (0x21) CTX = HAB_CTX_COMMAND (0xC0) ENG = HAB_ENG_ANY (0x00)

Why my u-boot is not Signing? still any configuration is missing?

4

Greetings @ks501865,

Just to clarify before we investigate any further. You said you’re using the Colibri iMX7D SOM. Are you using the 512MB or 1GB variant of this module? The meta-toradex-security meta-layer only supports the 1GB variant. So if you’re using the 512MB variant, then features may not work correctly.

Best Regards,
Jeremias

5

I am using Colibri iMX7D 1GB variant

6

Well our team ran a quick test and was unable to reproduce what you reported here. A test build was performed on the latest Yocto Scarthgap versions for the required meta-layers. The following cases were tested:

  • Booted a signed image on a fused Colibri iMX7D, hab_status didn’t return any errors.
  • Booted a signed image with the wrong keys on the same fused Colibri iMX7D (not closed), and hab_status returned several errors.
  • Booted again a signed image (with the correct keys) on the fused Colibri iMX7D, hab_status didn’t return any errors.

So everything seems to give the expected results.

As for build setup the local.conf used just has the following addition:

INHERIT += "tdxref-signed"

The only difference between tdxref-signed and tdx-signed is that tdxref-signed also enables rootfs protection features. But this is a step above the HAB, so it shouldn’t have any effect on what you’re seeing here.

All the other variables were not explicitly set meaning they just use the default values as documented in meta-toradex-security.

Given that our team was unable to reproduce your observation, I can only assume something strange occurred in your setup. Though it’s hard to say what exactly went wrong. I can only suggest building everything from scratch again just to be sure.

Also, since you’ve already fused your module I would recommend using the fuse read command in U-Boot to confirm that the correct values were written to the correct fuses.

Best Regards,
Jeremias