Invalidate certificates used by secure boot

Technical Support
, ,
1

Hello,

I’m currently introducing secure boot on our Verdin imx8mp module with the help of meta-toradex-security and the guideline (UG10106) Code Signing Tool User Guide from NXP.
I created a pki tree with the script hab4_pki_tree.sh and generated one CA, 4 SRKs, 4 IMG and 4 CSF key pairs. So far so good - everything is up and running.
I understand the principal of revoking a SRK key in case it is compromised by fusing this information on the SOC and moving on with the next SRK key. With this approach you have 4 shots in case something happens to your key.

Beyond this mechanism of invalidating a SRK key, I would like to be able to also invalidate IMG and CSF keys and replace them by new ones. The code signing tool is providing a script for adding additional CSF/IMG keys derived from an SRK. The invalidation of a key could be done by installing an image with newer CSF and IMG certificate.
I think of scenarios where sever vulnerabilities can occur in an officially shipped image in the future. In this case I would like to prevent devices from booting images with older signatures created by outdated CSF or IMG keys. The device needs to store the information of the current valid certificate version somehow.
I heared about the possibility of using a persistent counter that increments when a new CSF/IMG certificate is used. This counter is not able to count down and therefore does not allow older certificat versions this way.
Is there something like that provided in the IMX8MP or do you have any recommendations on how to achive this?

Thanks in advance!
Best regards, Ralph

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 understand you’re looking to implement certificate invalidation beyond the standard SRK revocation mechanism for your Verdin iMX8MP secure boot implementation. This is an advanced security scenario that goes beyond the basic HABv4 capabilities.

Current HABv4 Capabilities

The Verdin iMX8MP uses HABv4 for secure boot implementation (1). The standard revocation mechanism you mentioned is correct - you can revoke compromised SRK keys using the revocation bitmask in the SRK table, giving you up to 4 backup keys (1).

For HABv4-based SoMs like the Verdin iMX8MP, the configuration allows setting revocations through the TDX_IMX_HAB_CST_SRK_INDEX variable to specify which SRK to use for signing within the SRK table (1).

Certificate Version Control Limitations

Based on the available documentation, HABv4 on iMX8MP does not provide a built-in persistent counter mechanism for IMG and CSF certificate version control. The HABv4 architecture primarily focuses on:

  • SRK revocation through eFuse programming
  • Certificate chain validation
  • Image authentication

Potential Approaches

While the standard HABv4 implementation doesn’t include the persistent counter feature you described, here are some approaches to consider:

1. Application-Level Version Control

Implement version checking at the application level where your software validates certificate versions against a stored value in secure storage (like encrypted EEPROM or secure elements).

2. Custom Boot Flow Integration

Modify your boot process to include version checks before proceeding with the main application, though this would require careful implementation to maintain the security chain.

3. Hybrid Approach with SRK Rotation

Use a combination of SRK rotation and controlled certificate deployment to limit the exposure window of potentially compromised subordinate keys.

Recommendations

For your specific use case on the Verdin iMX8MP:

  1. Leverage the existing SRK revocation mechanism as your primary defense against key compromise
  2. Implement application-level certificate validation for additional security layers
  3. Consider using HSM-backed signing (2) for better key management and control
  4. Review the meta-toradex-security layer documentation for additional security features that might complement your requirements

The persistent counter mechanism you mentioned might be available on newer NXP processors or through additional security co-processors, but it’s not a standard HABv4 feature on the iMX8MP.

I’d recommend consulting the NXP HABv4 documentation directly for any processor-specific extensions or contacting NXP support for advanced security requirements beyond the standard HABv4 implementation.

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 @Ralph,

This is the first I’ve heard of the idea of invalidating the CSF/IMG keys used in HAB.

I heared about the possibility of using a persistent counter that increments when a new CSF/IMG certificate is used. This counter is not able to count down and therefore does not allow older certificat versions this way.

Where did you hear of this? Was it from NXP themselves, or their documentation?

Best Regards,
Jeremias

4

Hello @jeremias.tx,

the information regarding the invalidation of CSF/IMG certificates is not from any official sources. I was pointed to this approach by someone and I was wondering if something like that is possible on the imx8mp? Maybe you can recommend any other approach to achieve the same result?

The CST tool supports adding additional IMG or CSF keys, so I thought there is also a way of invalidating older ones. What else could be the benefit of creating additional keys?

BR Ralgh

5

Well as I said prior we’re not aware of the ability to invalidate CSF/IMG certs in the HAB architecture. The secure boot/HAB technology is designed and managed by NXP, so we follow their lead on what features work or not.

Otherwise we run the risk of doing something that may not be be supported by NXP. Which then has an impact on maintenance, and support from NXP themselves if we have issues with HAB.

It would probably be more fruitful to direct this question to NXP first, and see if the invalidation of the certs is even a supported feature. They might even have documentation if it is supported.

Best Regards,
Jeremias