I think that Torizon OS, by integrating the Yocto project tools and secure boot management, can use a TPM such as the SLB9673 to :
Store the private keys used to sign Secure Boot components.
Attest boot integrity by measuring each component.
Is this implemented? Could the TPM replace Efuse?
At the end of the documentation about the secure boot, you have this sentence :
The workflows for secure boot, encryption and TPM integration work only using Yocto Project as of today. We are working on integrating these workflows into TorizonCore Builder.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
Thank you for reaching out with your question about using a TPM for secure boot on your iMX8M Mini with Torizon OS. Currently, the secure boot implementation on Torizon OS primarily relies on Efuses to store the public keys necessary for validating the boot process. This is crucial for establishing a Chain of Trust, where each component in the boot sequence verifies the integrity and authenticity of the next.
While you have a TPM on your setup, the integration of TPM for secure boot purposes is not yet fully supported in TorizonCore Builder. As of now, the workflows for secure boot, encryption, and TPM integration are available through the Yocto Project. This means that while you can use a TPM for certain security functions, such as storing private keys or attesting boot integrity, it cannot directly replace Efuses for storing the public keys used in the secure boot process.
Efuses are used to store these keys in a manner that is immutable and tightly coupled with the hardware, which is essential for the initial stages of secure boot. The TPM, on the other hand, can enhance security by storing private keys and providing additional integrity checks, but it does not replace the need for Efuses in the current secure boot implementation.
In summary, while TPMs can complement the secure boot process by providing additional security features, they do not currently replace the role of Efuses in storing the public keys necessary for secure boot on Torizon OS. Future updates may expand the integration of TPMs, but for now, Efuses remain a necessary component for secure boot on Toradex hardware.
I hope this clarifies your query. 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:
Just to clarify, what parts of the secure boot process do you want to use to store the keys in your TPM?
Our secure boot process is composed of multiple different checks that create a complete chain of trust. From your description it sounds like you’re mostly interested in the initial part of the process where the bootloader is checked. This is also known as “high assurance boot” (HAB), by NXP who created the mechanism on their SoCs.
If that is the case, then there does seem to be some documentation from NXP about using hardware security modules with HAB: NXP Documentation Portal
That said, this isn’t something we have personally tried or are experienced in. That said, from what I can understand this just uses the secure hardware as a backend for the key creation rather than typical openssl. I believe the public keys themselves would still need to be set in the efuses on the device.
Thanks for your reply. I appreciate the information and your reference to the NXP documentation.
To clarify my goals:
I aim to store the private keys used for signing secure boot components (bootloader, kernel, root filesystem, and potentially Docker containers) directly in the TPM (SLB9673 in my case) instead of generating and storing them in software.
I also thinking about leveraging the TPM for boot integrity attestation using PCR measurements, which would extend the chain of trust to every key system component beyond eFuses, ideally covering up to Docker containers.
I see, thank you for clarifying your use-case for us. As of now I can say this is something we don’t have implemented. It is of interest to us to be clear. I can bring this up to our security team. Though of course these things would still take time to investigate and then implement.
One question though, with regards to your 1st point “store the private keys”. Did you mean something else or did you really mean private keys? For our chain of trust, the private keys are not anywhere on the system to begin with. The private keys get used to sign the binaries during the build process, but then they’re not anywhere in the deployed system, just the public keys used for verification. Or am I misunderstanding you on this point?
