Secure Boot and How It Works

Hi,

I have successfully managed to get Secure Boot working, and while I haven’t burned any fuses yet, I plan to test it tomorrow. However, I have a few questions regarding how Secure Boot operates.

I’m building the image using tdx-signed, and based on the boot log, everything appears to be set up correctly. My main concerns are:

  • Key rotation: Is it possible to rotate the SRK (Super Root Key) to a different one if our CA key is accidentally leaked online? If yes, how can this be done?

  • Docker container signing: How does Docker container signing work currently? I noticed it is marked as “coming soon”—do you have an estimated timeline for when this will be available?

  • Best practices: What are the best practices for using Secure Boot?

For example, if we generate a unique CA key for each device, it would result in different SRK keys being hashed into eFuses on each device. In this scenario, if one key is leaked, we would only need to update the compromised device rather than all devices in production.

Thank you in advance for your help and guidance!

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

Thank you for reaching out with your questions about Secure Boot on Toradex hardware. I’m glad to hear you’ve successfully set it up! Let’s address your concerns:

  1. Key Rotation: Yes, you can rotate the Super Root Key (SRK) if your Certificate Authority (CA) key is compromised. Toradex’s implementation allows for up to four SRK hashes to be burned into the eFuses of NXP i.MX System on Modules (SoMs). This means you can revoke a compromised key and still have other valid keys available for booting. It’s important to securely store these keys separately to ensure you can switch to a backup key if needed.

  2. Docker Container Signing: Currently, Docker container signing is marked as “coming soon” in the Torizon ecosystem. While there isn’t a specific timeline available, Toradex is actively working on integrating this feature to enhance the security of container deployments. Keep an eye on updates from Toradex for more information on when this feature will be available.

  3. Best Practices for Secure Boot:

    • Unique CA Keys: Using a unique CA key for each device can enhance security by limiting the impact of a key compromise to a single device. This approach means that if a key is leaked, only the affected device needs to be updated, not the entire fleet.
    • Key Management: Securely manage and store your signing keys. Consider using hardware security modules for added protection.
    • Testing Before Fusing: Thoroughly test your Secure Boot setup before burning fuses to ensure everything is configured correctly.
    • Regular Security Audits: Regularly audit your security setup and update your keys and configurations as needed to address new vulnerabilities.

By following these practices, you can maintain a robust Secure Boot implementation that protects your devices from unauthorized access and tampering.

I hope this helps! If you have any more questions, feel free to ask.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Downloading updated container images not working.

Greetings @Srimoki,

Let me try to address your questions as best as I can. By the way I’m assuming you’re using the Verdin i.MX8M Plus as you were in your other question. Let me know if this isn’t the case here since “secure boot” implementations can differ depending on the module.

Key rotation: Is it possible to rotate the SRK (Super Root Key) to a different one if our CA key is accidentally leaked online? If yes, how can this be done?

This is not possible as far as I know. The high-assurance-boot (HAB) architecture from NXP allows up to 4 SRKs per signed image. When you set the fuses on a device it programs the public component of the SRK to the device. Since these fuses are one time programmable and can’t be modified once set, it’s not really possible to rotate these on the device after the initial programming.

For further context, the boot image is then signed via a SRK table which contains information from all the generated SRKs. One of these SRKs will be used by the image during boot to validate itself. The SRK that is used is controlled by the “Source Index” field in the CSF file that is used to create the signed image.

While you can’t really rotate the keys, you can revoke one of the SRKs on the device, if they are compromised. That way if an image is trying to use a revoked SRK to validate it will fail. That said, since the fuses are permanent you can only revoke up to 3 of the 4 SRKs, since revoking all 4 would just mean the device can’t boot anything anymore.

For more information on this mechanism and other information about HAB I would recommend you refer to NXPs AN4581 document. This document can be downloaded from the NXP website though you will need an NXP account.

Docker container signing: How does Docker container signing work currently? I noticed it is marked as “coming soon”—do you have an estimated timeline for when this will be available?

At the moment we don’t have much to share on this upcoming feature. It’s still quite early in planning for this. The best timeline I can provide is that we hope to conclude work on it later this year maybe around Q3/Q4. Though I wouldn’t say this is a hard timeline as things can easily change between now and then.

Best practices: What are the best practices for using Secure Boot?

This is a bit of a broad question, do you have any specifics? For general overall usage NXP has many documents and articles covering HAB.

For example, if we generate a unique CA key for each device, it would result in different SRK keys being hashed into eFuses on each device. In this scenario, if one key is leaked, we would only need to update the compromised device rather than all devices in production.

Just to clarify this comment of yours. Are you saying you want to generate a completely unique set of keys and certs for each device of yours?

Best Regards,
Jeremias

Yeah, the idea is to generate a completely unique key for each device. That way, if one key gets leaked, we only need to replace that specific key. It also makes the risk of a key leak affecting all devices much smaller, right?

Well in theory, but in practice I don’t think that’s as secure or practical as one would think.

From a practicality/logistics point of view having completely unique keys per device would be a nightmare. Even just 100 devices would be 100 keys to track and manage. Also if one key got leaked then it’s likely multiple/all would been leaked as well. Unless you’re storing all 100 keys in 100 unique places/locations then, if an attacker got access to where you store your keys then they just have access to all the keys anyways.

If you notice how we designed our chain of trust, we do use unique keys/certs per chain of the boot process. The keys used for the secure boot of the bootloader are not the same keys used to verify the kernel and so on. So there is still some protection there and having 1 key leaked won’t break the entire chain of trust immediately.

Best Regards,
Jeremias