Act now: Recent security changes to Intel Remote Attestation

Verifying that the right code is running in the right environment with the latest security patches, a process known as remote attestation, is a crucial piece in Confidential Computing.

This ensures that the infrastructure provider, whether a cloud hyperscaler or another internal team, isn't getting surreptitious access to your workload.

Recent changes to Intel remote attestation greatly impacted the security of the Intel® Software Guard Extensions (SGX) / Trust Domain Extensions (TDX) ecosystem.

Understanding the Intel®SGX Root CA and TCB Info

The root of trust in the Intel remote attestation ecosystem is called the Intel®SGX Root CA. Despite the name, this is also used for Intel TDX. Any party that wishes to verify remote attestation involving Intel platforms ultimately relies on this root of trust.

One piece of data that is ultimately signed by this root of trust is the Trusted Computing Base (TCB) info, which is basically a summary of which security updates exist, and which versions are considered insecure. Every time Intel issues a security update, a new version of the TCB info is signed and published.

This is part of the TCB recovery process. This updated TCB info then allows verifiers to use this new data to ensure their infrastructure providers have installed these important security updates.

The Problem: Inability to Distinguish Between TCB Info Versions

However, Intel issues multiple different versions of these TCB info that are all considered valid at the same time. Before the recent changes by Intel, there was no way for a verifier solely relying on the Intel®SGX Root CA to tell these different versions apart. As such, a verifier might be presented with an older version of the TCB info.

This didn't use to be a big deal, because the different valid versions were at most 6 weeks apart. However, for March 12, 2024, TCB recovery, Intel maintained validity of an outdated TCB info up to 6 months after public disclosure of the applicable security vulnerability.

And for the Nov 12, 2024, TCB recovery, Intel is maintaining a 12-month timeline [source]. So, an infrastructure provider could delay installing security updates for 12 months after public disclosure without the workload owner being able to tell this. This is obviously much longer than industry-standard patching timelines!

Intel’s Solution: Introduction of TCB Evaluation Data Numbers

Fortanix highlighted this security problem with Intel back in September 2024. As of last month, Intel is now publishing TCB Evaluation Data Numbers [source], which is also ultimately signed by the Intel root of trust. This solves issues by allowing verifiers to tell different TCB info versions apart.

What Should You Do Now?

This is a crucial change in the security of the Intel®SGX/TDX ecosystem, and everyone who relies on this needs to act now to ensure their workloads are properly protected.

• If you implement an Intel remote attestation verifier, you need to ensure that you check the TCB evaluation data number in the TCB info is “new enough” according to the most recently published TCB Evaluation Data Numbers and your security patching policy.
• If you obtain a remote attestation verification service from a third party, you need to contact your service provider to ensure they've implemented the above change.
• If you obtain confidential computing infrastructure from a service provider, you need to contact your service provider to ensure they've implemented a security patching program that meets your patching policy.

Fortanix Is Ahead of the Curve

Fortanix has already implemented all necessary changes to ensure that verifiers detect outdated TCB info and enforce secure patching standards. As this is a critical shift in Intel®SGX/TDX security, we urge every Confidential Computing stakeholder to act now.