Attested TLS flaw undermines confidential computing's core promise

Key Takeaways

• Formal verification shows attested TLS protocols cannot prevent relay attacks where data goes to a malicious server
• Seven binding mechanisms tested; none achieve the strongest security level needed for production use
• The flaw affects Intel TDX, AMD SEV, and all TEE-based systems positioned for sovereign cloud deployments

The protocol meant to prove your data reaches a trusted server cannot actually do that. Muhammad Usama Sardar, a researcher at TU Dresden, has spent two years formally verifying attested TLS, the security handshake underpinning confidential computing. His findings, published across two peer-reviewed papers, show the protocol checks software integrity but fails to prove location. A connection to one server can be silently redirected to a compromised machine anywhere in the world.

This matters because vendors are positioning confidential computing as the technical backbone of Europe's sovereign cloud ambitions. Intel's TDX promises "safeguards to data sovereignty." Google Cloud describes its confidential infrastructure as offering "full, auditable control" over customer data access. If the trust mechanism underlying these claims is architecturally broken, those promises ring hollow.

What does remote attestation actually prove?

Confidential computing relies on Trusted Execution Environments, hardware enclaves where code runs in isolation from everything else on the machine, including the operating system and hypervisor. Before sending sensitive data, a client requests cryptographic proof that the server runs inside a genuine, unmodified TEE. This process is remote attestation.

The problem: attestation proves a genuine TEE exists somewhere. It does not bind that proof to the specific endpoint in your TLS session. Sardar's team used ProVerif, a formal verification tool, to test whether attested TLS protocols deliver what they claim. The answer: they largely do not.

Their first paper, "Identity Crisis in Confidential Computing," presented at AsiaCCS 2026, demonstrated diversion attacks against two state-of-the-art attested TLS protocols. An attacker can redirect a connection to a different machine running identical software. The intended server has done nothing wrong. The client has no way to detect the switch.

Seven binding methods tested, none pass

The second paper, "Intra-handshake.fail," accepted for ESORICS 2026, goes deeper. It examines intra-handshake attestation, where evidence is generated during the TLS handshake itself. Sardar's team tested seven different ways of cryptographically binding attestation evidence to the underlying connection.

None of them prevent relay attacks. A client can verify evidence from a genuine, trustworthy server but end up encrypting traffic to an entirely different, malicious one.

The researchers formalize the problem as three levels of cryptographic binding. Level one ties evidence to the initial Diffie-Hellman key exchange. Level two covers everything through the server's identity confirmation. Level three, the only one that matters for production use, ties evidence to the application traffic key, the key encrypting the actual sensitive data.

Three of the seven mechanisms achieve level one. The rest fail even that baseline. The team's proposed fix, a binder built from the TLS handshake secret combined with the server's public key, formally achieves level two. Level three, the paper concludes, "may not be possible" within intra-handshake attestation without breaking properties of TLS 1.3.

Why the hardware trust assumption is inescapable

"In confidential computing, you have to trust the hardware manufacturer anyway," Sardar told The Register. "There is absolutely no way around this."

This is the foundational bargain. Intel, AMD, and ARM supply the TEE implementations. You trust their silicon or you don't use the technology. The protocol layer was supposed to handle everything above that root of trust: proving the right software runs in the right place, talking to the right client. Sardar's work shows it falls short on the "right place" requirement.

The Register reported in May that management engines running below the operating system on Intel and AMD chips fall outside what European sovereignty frameworks like SecNumCloud actually assess. This new research closes the loop on the layer above: the attestation protocol itself has fundamental gaps.

What this means for sovereign cloud and confidential AI

The confidential computing market is projected to reach $54.4 billion by 2030. The EU has invested over €1.2 billion in Gaia-X and sovereign cloud initiatives, many of which assume confidential computing provides cryptographic assurance of data residency and access control.

If attested TLS cannot prove which physical server processes your data, those assumptions need revisiting. A relay attack could route traffic through a compliant-looking endpoint to a non-compliant one. The client's attestation check would pass. The data would still land in the wrong jurisdiction.

Confidential AI workloads face similar exposure. Models trained or run inside TEEs are supposed to be protected from the cloud operator. But if the attestation handshake can be relayed, the operator, or anyone who compromises them, could substitute a different endpoint without detection.

Can vendors fix this?

Sardar's team proposes a mitigation that achieves level-two binding. That proves a client is talking to the right machine at the start of the handshake. It cannot prove that data sent minutes later still goes to that machine. For long-lived connections or streaming workloads, this gap matters.

Reaching level three may require changes to TLS 1.3 itself, properties the protocol was never designed to provide. That's a multi-year standardization effort with no guarantee of success.

In the meantime, vendors face a choice: acknowledge the limitation or continue marketing around it. Given the commercial stakes, expect creative interpretations of what "full control" and "data sovereignty" actually mean.

Frequently Asked Questions

What is attested TLS in confidential computing?

Attested TLS combines standard TLS encryption with TEE attestation in a single handshake. It's meant to prove your data reaches a genuine, unmodified trusted execution environment before you send sensitive information.

What is the attested TLS vulnerability researchers found?

The protocol checks software integrity but cannot cryptographically prove which specific server receives your data. Attackers can redirect connections to malicious endpoints without clients detecting the switch.

Which chip vendors are affected by this flaw?

All major TEE implementations, including Intel TDX, AMD SEV, and ARM CCA, use attested TLS protocols vulnerable to these relay and diversion attacks.

Does this mean confidential computing is useless?

No. TEEs still protect data from the operating system and hypervisor. But the attestation protocol provides weaker guarantees than marketed, especially for proving server identity and location.

Is there a fix for attested TLS vulnerabilities?

Researchers propose a mitigation achieving partial protection, but full protection may require changes to TLS 1.3 itself, a multi-year standardization effort.

Source: www.theregister.com