i.MX8MP (Verdin) Secure Boot: FIT verification in Open mode, update validation without fusing, fuse reversibility, and CST key “duration years” doubts

Technical Support
,
1

Hi Toradex Team,
I’m working on Verdin iMX8MP on Mallow carrier, building Yocto secure boot images using meta-toradex-security. I have a few quick questions:
1) FIT verification in Open mode vs full chain verification
In Open mode, I can verify FIT signature in U-Boot, but can I verify the ROM → SPL/U-Boot authentication stage (HAB/SRK)? If yes, what is the best way/log to confirm ROM auth happened?
2) Development-stage validation for updates (without fusing)
Before fusing/closing any board, is there a recommended way to pre-validate that a newly built or upadated signed bootloader/FIT (signed with the intended key) will boot on a closed device? Any offline/pre-flight verification checklist/tool?
3) “Soft fusing” vs “hard fusing” terminology
Toradex docs talk more about open state vs closed state, and “closing the device”.
3.1 Is there an official Toradex interpretation of “soft fusing” vs “hard fusing”?
Example: is “fusing the SRK/public key but keeping device not closed” considered a “soft stage”?3.2 What exactly changes when we close the device?
4) Can fused keys be reversed?
Can SRK/key fuses ever be reversed/cleared? If not, what’s the recommended safe approach for development/testing?
5) NXP CST PKI “duration years” — what happens after expiry?
While generating keys in NXP CST: Enter PKI tree duration (years)
If I enter 10 years, and that key (or its hash) is fused into hardware:
5.1 After 10 years, will the device stop booting images signed with that key?
5.2 Do we need to scrap hardware after certificate expiry?
5.3 Or is the “duration years” only for certificate metadata and not enforced by HAB/ROM?
6) Recommended key fusing steps (Toradex best practice)
Given my setup (Verdin iMX8MP, Yocto, meta-toradex-security):
What is the recommended step-by-step approach Toradex suggests for:
6.1 development verification (no fuses)
6.2 staging (if applicable)
6.3 production fusing and closing,
6.4 and safe update procedure afterwards?

Any guidance, official references, or a recommended checklist would be really helpful.

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I’d be glad to help with your Secure Boot questions for Verdin iMX8MP! To provide you with the most accurate guidance, could you let me know which OS and version you are using? For example, are you working with Torizon OS, BSP 7.x.y, or another specific version?

You can use the tdx-info command to get detailed information about your setup. More details are available at: tdx-info documentation

General Secure Boot Overview

Based on the available documentation, Toradex implements Secure Boot as a process of booting an image from a valid trusted source with authenticity and integrity checks(1). The implementation uses a Chain of Trust (CoT) where each bootable artifact validates the next one in sequence(1).

Toradex defines different coverage levels(1):

  • Minimal Chain of Trust (MCoT): Only the signed bootloader is validated by ROM code
  • Basic Chain of Trust (BCoT): Chain extends to kernel artifacts with U-Boot hardening
  • Extended Chain of Trust (ECoT): Encompasses most of the root filesystem
  • Full Chain of Trust (FCoT): Includes container image validation

Key Points About Device Closing

The process of burning the Efuse that enables Secure Boot is referred to as “closing the device”(1). The documentation indicates that to ensure the first stage of installable software is signed, the corresponding public key must be stored on the device in a way that cannot be changed, typically through one-time Efuse operations(1).

Development Considerations

From the community discussions, there are known issues with fuse comparison failures during development that can be addressed through proper U-Boot hardening and boot script adjustments(2). The hardening modifications are designed to prevent tampering, prevent execution of unsigned software, and prevent injection of kernel arguments(1).

Once you provide your specific OS version and setup details, I can offer more targeted guidance for your development workflow, validation procedures, and production deployment strategy.

Best regards, Toradex AI Assistant.

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

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Greetings @nidhishende,

FIT verification in Open mode vs full chain verification

Not sure if I fully understood your question. You’re basically asking how to verify if HAB worked?

Well on a closed device, it would be pretty obvious since a closed device will only boot appropriately signed bootloaders.

Development-stage validation for updates (without fusing)

The only real way to check as provided by NXP is to run hab_status in U-Boot. This will check if the currently running U-Boot would pass the usual HAB checks. If not various events would be printed.

“Soft fusing” vs “hard fusing” terminology

I don’t believe we use the soft/hard fusing terminology anywhere in our own documentation. What do you define these terms as?

When a device is closed that means the HAB check is enforced without question. Any bootloader must be appropriately signed, or the system will not boot at all in any operable way. An open device can still boot any bootloader signed, not-signed, or incorrectly signed with no issue. As said previously you can use hab_status in this stage to check if a bootloader would have passed or failed if the device was closed.

Can fused keys be reversed?

Not really. Fuses are one time programmable permanently.

You can “revoke” one of the SRKs (only on some NXP SoCs) so that it can’t be used anymore to validate a bootloader. But the fuse itself is still written. You can reference NXP application note 4581 for more info on this revoking process.

NXP CST PKI “duration years” — what happens after expiry?

This is answered by NXP on their forum here: https://community.nxp.com/t5/i-MX-Processors/HABv4-and-certificate-expiring-date/m-p/1058869

Recommended key fusing steps (Toradex best practice)

For development I would recommend to keep the device open, as closed devices are very inflexible to work with. As said before you can use hab_status to verify whether your system is setup correctly or not.

For production and update procedures I would recommend reading the following article: Secure Boot Fuse Programming at Scale | Toradex Developer Center

Best Regards,
Jeremias

4

Thank you for the information.

5

Glad I was able to help clarify. Do you have any further questions on this topic?

Best Regards,
Jeremias

6

You may validate your image without burning SRK fuses. hab_status will report no warnings if image is properly signed, though SRK fuses are unprogrammed. Before closing device, you need to burn SRK fuses, because HAB check won’t succeed any more after device is closed. You may recheck hab_status again after fusing SRK, but not yet closing device. This time hab_status will as well validate your boot image including SRK table check.

You should keep in mind that you should never regenerate certificates and SRK table if you plan to update existing signed and closed device with newly signed bootloader. SRK key revocation only band one of the existing keys, which was used to generate SRK table. Anyway you won’t be able to change SRK fuses without bricking your device.

In addition to what @jeremias.tx wrote, not only flashed U-Boot needs to be properly signed, bus as well device recovery needs properly signed U-Boot image. For recovery you will need to sign U-Boot, which comes with Tezi. Recovery just won’t work until you sign U-Boot image used for recovery over USB.