New physical attacks are quickly diluting secure enclave defenses from Nvidia, AMD, and Intel

Trusted execution environments, or TEEs, are everywhere—in blockchain architectures, virtually every cloud service, and computing involving AI, finance, and defense contractors. It’s hard to overstate the reliance that entire industries have on three TEEs in particular: Confidential Compute from Nvidia, SEV-SNP from AMD, and SGX and TDX from Intel. All three come with assurances that confidential data and sensitive computing can’t be viewed or altered, even if a server has suffered a complete compromise of the operating kernel.

A trio of novel physical attacks raises new questions about the true security offered by these TEES and the exaggerated promises and misconceptions coming from the big and small players using them.

The most recent attack, released Tuesday, is known as TEE.fail. It defeats the latest TEE protections from all three chipmakers. The low-cost, low-complexity attack works by placing a small piece of hardware between a single physical memory chip and the motherboard slot it plugs into. It also requires the attacker to compromise the operating system kernel. Once this three-minute attack is completed, Confidential Compute, SEV-SNP, and TDX/SDX can no longer be trusted. Unlike the Battering RAM and Wiretap attacks from last month—which worked only against CPUs using DDR4 memory—TEE.fail works against DDR5, allowing them to work against the latest TEEs.

Some terms apply

All three chipmakers exclude physical attacks from threat models for their TEEs, also known as secure enclaves. Instead, assurances are limited to protecting data and execution from viewing or tampering, even when the kernel OS running the processor has been compromised. None of the chipmakers make these carveouts prominent, and they sometimes provide confusing statements about the TEE protections offered.

Many users of these TEEs make public assertions about the protections that are flat-out wrong, misleading, or unclear. All three chipmakers and many TEE users focus on the suitability of the enclaves for protecting servers on a network edge, which are often located in remote locations, where physical access is a top threat.

“These features keep getting broken, but that doesn’t stop vendors from selling them for these use cases—and people keep believing them and spending time using them,” said HD Moore, a security researcher and the founder and CEO of runZero.

He continued:

Overall, it’s hard for a customer to know what they are getting when they buy confidential computing in the cloud. For on-premise deployments, it may not be obvious that physical attacks (including side channels) are specifically out of scope. This research shows that server-side TEEs are not effective against physical attacks, and even more surprising, Intel and AMD consider these out of scope. If you were expecting TEEs to provide private computing in untrusted data centers, these attacks should change your mind.

Those making these statements run the gamut from cloud providers to AI engines, blockchain platforms, and even the chipmakers themselves. Here are some examples:

• Cloudflare says it’s using Secure Memory Encryption—the encryption engine driving SEV—to safeguard confidential data from being extracted from a server if it’s stolen.
• In a post outlining the possibility of using the TEEs to secure confidential information discussed in chat sessions, Anthropic says the enclave “includes protections against physical attacks.”
• Microsoft marketing (here and here) devotes plenty of ink to discussing TEE protections without ever noting the exclusion.
• Meta, paraphrasing the Confidential Computing Consortium, says TEE security provides protections against malicious “system administrators, the infrastructure owner, or anyone else with physical access to the hardware.” SEV-SNP is a key defense securing the integration of AI features into Meta’s WhatsApp Messenger.
• Even Nvidia claims that its TEE security protects against “infrastructure owners such as cloud providers, or anyone with physical access to the servers.”
• The maker of the Signal private messenger assures users that its use of SGX means that “keys associated with this encryption never leave the underlying CPU, so they’re not accessible to the server owners or anyone else with access to server infrastructure.” Signal has long relied on SGX to protect contact-discovery data.

I counted more than a dozen other organizations providing assurances that were similarly confusing, misleading, or false. Even Moore—a security veteran with more than three decades of experience—told me: “The surprising part to me is that Intel/AMD would blanket-state that physical access is somehow out of scope when it’s the entire point.”

In fairness, some TEE users build additional protections on top of the TEEs provided out of the box. Meta, for example, said in an email that the WhatsApp implementation of SEV-SNP uses protections that would block TEE.fail attackers from impersonating its servers. The company didn’t dispute that TEE.fail could nonetheless pull secrets from the AMD TEE.

The Cloudflare theft protection, meanwhile, relies on SME—the engine driving SEV-SNP encryption. The researchers didn’t directly test SME against TEE.fail. They did note that SME uses deterministic encryption, the cryptographic property that causes all three TEEs to fail. (More about the role of deterministic encryption later.)

Others who misstate the TEEs’ protections provide more accurate descriptions elsewhere. Given all the conflicting information, it’s no wonder there’s confusion.

How do you know where the server is? You don’t.

Many TEE users run their infrastructure inside cloud providers such as AWS, Azure, or Google, where protections against supply-chain and physical attacks are extremely robust. That raises the bar for a TEE.fail-style attack significantly. (Whether the services could be compelled by governments with valid subpoenas to attack their own TEE is not clear.)

All these caveats notwithstanding, there’s often (1) little discussion of the growing viability of cheap, physical attacks, (2) no evidence (yet) that implementations not vulnerable to the three attacks won’t fall to follow-on research, or (3) no way for parties relying on TEEs to know where the servers are running and whether they’re free from physical compromise.

“We don’t know where the hardware is,” Daniel Genkin, one of the researchers behind both TEE.fail and Wiretap, said in an interview. “From a user perspective, I don’t even have a way to verify where the server is. Therefore, I have no way to verify if it’s in a reputable facility or an attacker’s basement.”

In other words, parties relying on attestations from servers in the cloud are once again reduced to simply trusting other people’s computers. As Moore observed, solving that problem is precisely the reason TEEs exist.

In at least two cases, involving the blockchain services Secret Network and Crust, the loss of TEE protections made it possible for any untrusted user to present cryptographic attestations. Both platforms used the attestations to verify that a blockchain node operated by one user couldn’t tamper with the execution or data passing to another user’s nodes. The Wiretap hack on SGX made it possible for users to run the sensitive data and executions outside of the TEE altogether while still providing attestations to the contrary. In the AMD attack, the attacker could decrypt the traffic passing through the TEE.

Both Secret Network and Crust added mitigations after learning of the possible physical attacks with Wiretap and Battering RAM. Given the lack of clear messaging, other TEE users are likely making similar mistakes.

A predetermined weakness

The root cause of all three physical attacks is the choice of deterministic encryption. This form of encryption produces the same ciphertext each time the same plaintext is encrypted with the same key. A TEE.fail attacker can copy ciphertext strings and use them in replay attacks. (Probabilistic encryption, by contrast, resists such attacks because the same plaintext can encrypt to a wide range of ciphertexts that are randomly chosen during the encryption process.)

TEE.fail works not only against SGX but also a more advanced Intel TEE known as TDX. The attack also defeats the protections provided by the latest Nvidia Confidential Compute and AMD SEV-SNP TEEs. Attacks against TDX and SGX can extract the Attestation Key, an ECDSA secret that certifies to a remote party that it’s running up-to-date software and can’t expose data or execution running inside the enclave. This Attestation Key is in turn signed by an Intel X.509 digital certificate providing cryptographic assurances that the ECDSA key can be trusted. TEE.fail works against all Intel CPUs currently supporting TDX and SDX.

With possession of the key, the attacker can use the compromised server to peer into data or tamper with the code flowing through the enclave and send the relying party an assurance that the device is secure. With this key, even CPUs built by other chipmakers can send an attestation that the hardware is protected by the Intel TEEs.

GPUs equipped with Nvidia Confidential Compute don’t bind attestation reports to the specific virtual machine protected by a specific GPU. TEE.fail exploits this weakness by “borrowing” a valid attestation report from a GPU run by the attacker and using it to impersonate the GPU running Confidential Compute. The protection is available on Nvidia’s H100/200 and B100/200 server GPUs.

“This means that we can convince users that their applications (think private chats with LLMs or Large Language Models) are being protected inside the GPU’s TEE while in fact it is running in the clear,” the researchers wrote on a website detailing the attack. “As the attestation report is ‘borrowed,’ we don’t even own a GPU to begin with.”

SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) uses ciphertext hiding in AMD’s EPYC CPUs based on the Zen 5 architecture. AMD added it to prevent a previous attack known as Cipherleaks, which allowed malicious hypervisors to extract cryptographic keys stored in the enclaves of a virtual machine. Ciphertext, however, doesn’t stop physical attacks. With the ability to reopen the side channel that Cipherleaks relies on, TEE.fail can steal OpenSSL credentials and other key material based on constant-time encryption.

Cheap, quick, and the size of a briefcase

“Now that we have interpositioned DDR5 traffic, our work shows that even the most modern of TEEs across all vendors with available hardware is vulnerable to cheap physical attacks,” Genkin said.

The equipment required by TEE.fail runs off-the-shelf gear that costs less than $1,000. One of the devices the researchers built fits into a 17-inch briefcase, so it can be smuggled into a facility housing a TEE-protected server. Once the physical attack is performed, the device does not need to be connected again. Attackers breaking TEEs on servers they operate have no need for stealth, allowing them to use a larger device, which the researchers also built.

A logic analyzer attached to an interposer.

A logic analyzer attached to an interposer.

Gear that plugs into the DIMNM.

Gear that plugs into the DIMNM.

An overview of the equipment involved.

An overview of the equipment involved.

Gear that plugs into the DIMNM.

An overview of the equipment involved.

The researchers demonstrated attacks against an array of services that rely on the chipmakers’ TEE protections. (For ethical reasons, the attacks were carried out against infrastructure that was identical to but separate from the targets’ networks.) Some of the attacks included BuilderNet, dstack, and Secret Network.

BuilderNet is a network of Ethereum block builders that uses TDX to prevent parties from snooping on others’ data and to ensure fairness and that proof currency is redistributed honestly. The network builds blocks valued at millions of dollars each month.

“We demonstrated that a malicious operator with an attestation key could join BuilderNet and obtain configuration secrets, including the ability to decrypt confidential orderflow and access the Ethereum wallet for paying validators,” the TEE.fail website explained. “Additionally, a malicious operator could build arbitrary blocks or frontrun (i.e., construct a new transaction with higher fees to ensure theirs is executed first) the confidential transactions for profit while still providing deniability.”

To date, the researchers said, BuilderNet hasn’t provided mitigations. Attempts to reach BuilderNet officials were unsuccessful.

dstack is a tool for building confidential applications that run on top of virtual machines protected by Nvidia Confidential Compute. The researchers used TEE.fail to forge attestations certifying that a workload was performed by the TDX using the Nvidia protection. It also used the “borrowed” attestations to fake ownership of GPUs that a relying party trusts.

Secret Network is a platform billing itself as the “first mainnet blockchain with privacy-preserving smart contracts,” in part by encrypting on-chain data and execution with SGX. The researchers showed that TEE.fail could extract the “Concensus Seed,” the primary network-side private key encrypting confidential transactions on the Secret Network. As noted, after learning of Wiretap, the Secret Network eliminated this possibility by establishing a “curated” allowlist of known, trusted nodes allowed on the network and suspended the acceptance of new nodes. Academic or not, the ability to replicate the attack using TEE.fail shows that Wiretap wasn’t a one-off success.

A tough nut to crack

As explained earlier, the root cause of all the TEE.fail attacks is deterministic encryption, which forms the basis for protections in all three chipmakers’ TEEs. This weaker form of encryption wasn’t always used in TEEs. When Intel initially rolled out SGX, the feature was put in client CPUs, not server ones, to prevent users from building devices that could extract copyrighted content such as high-definition video.

Those early versions encrypted no more than 256MB of RAM, a small enough space to use the much stronger probabilistic form of encryption. The TEEs built into server chips, by contrast, must often encrypt terabytes of RAM. Probabilistic encryption doesn’t scale to that size without serious performance penalties. Finding a solution that accommodates this overhead won’t be easy.

One mitigation over the short term is to ensure that each 128-bit block of ciphertext has sufficient entropy. Adding random plaintext to the blocks prevents ciphertext repetition. The researchers say the entropy can be added by building a custom memory layout that inserts a 64-bit counter with a random initial value to each 64-bit block before encrypting it.

The last countermeasure the researchers proposed is adding location verification to the attestation mechanism. While insider and supply chain attacks remain a possibility inside even the most reputable cloud services, strict policies make them much less feasible. Even those mitigations, however, don’t foreclose the threat of a government agency with a valid subpoena ordering an organization to run such an attack inside their network.

In a statement, Nvidia said:

NVIDIA is aware of this research. Physical controls in addition to trust controls such as those provided by Intel TDX reduce the risk to GPUs for this style of attack, based on our discussions with the researchers. We will provide further details once the research is published.

Intel spokesman Jerry Bryant said:

Fully addressing physical attacks on memory by adding more comprehensive confidentiality, integrity and anti-replay protection results in significant trade-offs to Total Cost of Ownership. Intel continues to innovate in this area to find acceptable solutions that offer better balance between protections and TCO trade-offs.

The company has published responses here and here reiterating that physical attacks are out of scope for both TDX and SGX