Confidential Computing's Whole Pitch Is 'Trust the Proof, Not the Cloud.' Two Years of Formal Verification Just Found the Proof Doesn't Prove What You Think.
- Patrick Duggan
- 2 hours ago
- 5 min read
The entire sales pitch of confidential computing is one sentence: you can run your most sensitive workload on hardware you do not own, in a cloud you do not control, and cryptographically prove to yourself that nobody — not the cloud provider, not a rogue admin, not a co-tenant — can see inside. The mechanism that delivers that proof is called remote attestation, and this week a researcher who spent two years formally verifying it published the finding that the proof does not prove what the industry says it proves. This is not a patch-Tuesday bug. It is a design-level break in the trust primitive that Intel SGX and TDX, AMD SEV, and every confidential-VM offering on Azure, Google Cloud, and beyond are built on top of. And before we go further, the honest caveat we lead every one of these with: there is no evidence of this being exploited in the wild, and this is formal-verification research rather than an active campaign. That is true. It is also, for a foundational trust flaw, cold comfort — because you cannot patch your way out of a protocol that structurally cannot do the thing it promised.
The researcher is Muhammad Usama Sardar at TU Dresden, working with co-authors Mariam Moustafa and Tuomas Aura, and separately with Viacheslav Dubeyko and Jean-Marie Jacquet. The work landed in two peer-reviewed papers — Identity Crisis in Confidential Computing at AsiaCCS 2026, and Intra-handshake.fail at ESORICS 2026 — and it carries CVE-2026-33697, scored 7.5. For context, that beats BadRAM's 5.3 and now ranks as the highest-severity confidential-computing vulnerability on the board. But the CVSS number undersells it, the same way it always does when the flaw is in the foundation rather than the walls.
Here is the mechanism, in plain terms, because it is genuinely elegant and genuinely bad. Confidential computing uses a protocol called attested TLS: on top of a normal encrypted TLS connection, the server presents cryptographic evidence that it is running genuine, unmodified code inside a real Trusted Execution Environment. Your client checks that evidence, sees "yes, this is the real workload in a real enclave," and starts sending secrets. Sardar's finding is that the evidence proves the software is genuine — and proves nothing about where that software actually is. So two attacks fall straight out. In a diversion attack, a connection you intended for one server gets silently redirected to a different compromised machine that happens to be running identical software; the attestation passes, because the code really is genuine — it is just genuine code on the attacker's box. In a relay attack, your client cryptographically verifies a legitimate server, and then encrypts its data to an entirely different malicious machine anyway. The proof checks the code. It never binds to the connection actually carrying your data.
The depth of it is in what Sardar calls the three binding levels. Level 1 ties the attestation evidence only to the initial key exchange. Level 2 covers the client's handshake traffic. Level 3 — the one that matters — binds the evidence to the application traffic keys, the keys that actually protect the sensitive data you are trying to keep secret. Level 3 is the whole point; it is the only level that means "this proof covers the channel your secrets ride on." And the finding is that the best current mitigations reach only Level 2, while Level 3 "may not be possible" within the intra-handshake architecture at all without breaking the security properties of TLS 1.3 itself. The evidence has to be generated before the application keys exist. You cannot bind a proof to something that has not been created yet. That is not a bug someone forgot to fix. That is a timing contradiction baked into how the handshake is shaped. Sardar's recommendation to the IETF TLS working group was blunt: developers should abandon intra-handshake attestation altogether.
This is not theoretical hand-waving against a whiteboard protocol. The team analyzed four real, in-production implementations and the attacks applied to every version they tested: Meta's Private Processing, the confidential-computing layer behind WhatsApp; Edgeless Systems' Contrast; Cocos AI, versions 0.4.0 through 0.8.2; and the Confidential Computing Consortium's own Attestation SIG proof-of-concept. Read that list again — the reference implementation from the industry body whose entire job is to get confidential computing right is on it. And the Meta detail is the one that should stop every security leader who outsources assurance to an audit: Meta commissioned an extensive security review from Trail of Bits in 2025, a genuinely top-tier shop, and that review did not catch the relay attacks — because it did not use formal verification. Two smart teams looked at the same protocol. The one that modeled it mathematically found the hole the one that read the code did not. That gap is the actual lesson, and it is bigger than confidential computing.
The vendor responses tell you where this goes next. Intel, through Mikael Moreau, said the company does not consider its attestation infrastructure a sovereignty limitation — Intel has no access to plaintext workload data, and customers can delegate their verification decisions. That is a real point and also a careful sidestep of the binding question. Google did not respond to requests for comment. And layered underneath all of it is the March 2026 extraction of the SGX Global Wrapping Key from Intel's Gemini Lake platform, which reached root keys burned into hardware fuses — and when the root keys are out, attestation can simply be forged, no protocol subtlety required. So the trust anchor is being pressured from two directions at once: the protocol on top cannot bind to your data, and the hardware root underneath has already leaked on at least one platform.
We opened this thread back in April, in An Early Investigation Into Platform Verification Security, because the fragility of "the machine proves it can be trusted" was visible before this week's formal results made it undeniable. This is the shoe dropping. And it fits the pattern we keep writing about from every other angle: the trust lifecycle is universal, and the softest surface in any system is the one everybody assumes is hard. Attestation is treated as bedrock — the thing you build on and stop questioning. The confidential-computing pitch works precisely because customers are told they no longer have to trust the cloud, only the math. When the math turns out to check the wrong thing, everything stacked on top of it inherits the flaw silently, and the people relying on it have the least reason to look, because they were sold certainty.
So here is the honest read for anyone actually running confidential workloads, capped where we cap everything. Do not rip out your TEEs tomorrow; there is no exploit campaign, and confidential computing still raises the cost of a whole class of attacks meaningfully. But stop treating attestation as a finished, trustworthy checkmark, and specifically stop assuming that "attestation passed" means "my data went to the enclave I verified." If your architecture depends on Level 3 binding — if your threat model includes a cloud provider or a co-tenant who could stand up identical software on a machine they control — then the guarantee you think you have does not currently exist, and the researchers who proved it think it may not be buildable in the current design. Ask your confidential-computing vendor exactly which binding level they achieve, in writing. If the answer is Level 2, or if they cannot answer, you have learned something the CVSS score will never tell you. The proof was the product. The proof has a hole. That is the whole story, and it is worth more to know it than to keep trusting the seal on the vault door.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments