Confidential computing’s promise of hardware-level isolation for sensitive data in the cloud is facing a critical security challenge. Researchers have identified fundamental flaws in the remote attestation protocols used to prove server integrity, enabling relay attacks that bypass cryptographic trust mechanisms and leave production AI and data workloads exposed to interception.
The Architecture of an Identity Crisis
Confidential computing relies on the concept of a Trusted Execution Environment (TEE)—an isolated enclave within a processor designed to protect code and data from the host operating system or hypervisor. To verify that an enclave is genuine, the system uses remote attestation. Before any data is processed, the server must cryptographically prove to the client that it is running authorized, unmodified code. This process is the bedrock of “sovereign cloud” initiatives.
However, new research presented at the AsiaCCS 2026 conference by Muhammad Usama Sardar and his colleagues at TU Dresden reveals that this trust mechanism is fundamentally misaligned with its intended function. The study, titled Identity Crisis in Confidential Computing, exposes that current attested TLS protocols verify the integrity of the software, but fail to tie that verification to the physical location or the specific instance of the server.
Consequently, an attacker can perform a diversion attack. They can intercept a connection meant for a legitimate server and redirect it to a malicious machine running identical code. Because the protocol validates the what (the software) rather than the where (the specific physical host), the client remains unaware that its sensitive data is being decrypted by an unauthorized party.
Beyond the Handshake: The Intra-Handshake Failure
The security risks extend into the TLS handshake process itself. In a forthcoming paper accepted for ESORICS 2026, Intra-handshake.fail, researchers analyzed seven methods of “intra-handshake attestation”—a technique where cryptographic evidence is generated during the initial connection phase. None of these seven methods successfully prevent relay attacks.
Sardar’s team categorized the failure into three levels of cryptographic binding:
- Level 1 (Weakest): Ties evidence to the initial Diffie-Hellman key exchange. Three of the seven mechanisms achieve this, but it provides no protection against subsequent redirection.
- Level 2: Ties evidence to the client’s handshake traffic key. The researchers developed a proposed mitigation using a cryptographic binder that achieves this, but it remains insufficient for long-lived, high-security connections.
- Level 3 (Strongest): Ties evidence to the application traffic key—the actual key used to encrypt the payload. The paper concludes this level “may not be possible” within the current architecture of intra-handshake attestation without breaking the fundamental properties of TLS 1.3.
Production Impact and the CVE-2026-33697 Reality
This is not a laboratory curiosity. The vulnerability, designated CVE-2026-33697, carries a high-severity score of 7.5 on the Common Vulnerability Scoring System (CVSS). It directly affects production systems including Meta’s Private Processing for WhatsApp, Edgeless Systems’ Contrast, and the open-source Cocos AI platform (versions 0.4.0 through 0.8.2).
The gap between theory and practice was highlighted by Meta’s previous security audit. While the company commissioned a review from Trail of Bits, the firm did not detect the relay attack. According to the ESORICS paper, this is because manual audits rely on sampling, whereas formal verification tools like ProVerif perform an exhaustive check of all possible scenarios within a threat model. The reliance on non-formal methods in industry-standard audits has left a blind spot that attackers can exploit.
Institutional Inertia and the Sovereignty Gap
The response from the Confidential Computing Consortium (CCC) has drawn scrutiny. After researchers requested a dedicated repository to publish their findings and formal analysis artifacts, they faced a ten-day delay from the CCC’s Attestation Special Interest Group, which includes representatives from the hardware and cloud vendors whose products are directly implicated by the vulnerability.
This organizational friction underscores the broader skepticism expressed by Germany’s Federal Office for Information Security (BSI). A BSI spokesperson noted that while confidential computing provides “defense-in-depth,” it does not address dependencies on identity and key management services. As the BSI stated, vendor marketing often gives “too much weight to its technical capabilities,” suggesting that current confidential computing implementations cannot satisfy the requirements for digital sovereignty on their own.
For Intel, the challenge is managing the reliance on its silicon-based root of trust. Mikael Moreau, Intel’s France Communication Manager, maintains that their attestation infrastructure is not a sovereignty limitation, noting that Intel does not sit in the customer’s plaintext data path. However, this does not address the legal risks posed by frameworks like the 2024 US RISAA law, which could potentially compel hardware manufacturers to cooperate with intelligence orders.
The 30-Second Verdict for Enterprise IT
- The Vulnerability: Attested TLS protocols currently verify that the code is correct, but not that it is running on the intended, secure hardware.
- The Risk: Relay attacks allow attackers to transparently redirect encrypted traffic to malicious hardware, even if the software is legitimate.
- The Fix: Current “intra-handshake” attestation methods cannot achieve the necessary level of security. Researchers recommend shifting to “post-handshake attestation” to bind identity to the final application traffic keys.
- The Outlook: The IETF’s Secure Evidence and Attestation Transport (SEAT) working group is now incorporating these findings into their standards, but production systems remain vulnerable until these architectural changes are implemented.
As the industry moves toward formalizing these standards—such as through the work being documented at the IETF SEAT working group—the consensus among researchers is clear: the current generation of attested TLS is not yet mature. Until post-handshake attestation becomes the standard, organizations relying on confidential computing for absolute data sovereignty are operating under a false sense of cryptographic security.
