# It's time to talk about TEEs - Alin Tomescu

Source: https://alinush.github.io/tee
Kiwi News: https://news.kiwistand.com/stories/Its-time-to-talk-about-TEEs-Alin-Tomescu?index=0x6ad4ae2d6ba3f7ff905788f5127f2c0871415b918caaac926ceb20c3fcb1ab0285eac699
Submitted by misha on 2026-10-18 UTC, 2 upvotes, 0 comments

## Summary

Alin Tomescu argues that developers should reconsider deploying TEE-based applications, and should not put valuable secrets in TEEs, because the hardware's security claims are shaky. He surveys attacks including Foreshadow (2018), which let a malicious OS steal an Intel SGX attestation key, and several 2025 physical interposition attacks on DDR4 and DDR5 systems. He also notes that Intel TDX attestation is only safe if a verifier is pinned to the verifier's own PCK certificates, and that a 2024 BadRAM attack let a tampered DIMM produce false attestations on AMD SEV-SNP systems.

## Article

This post surveys some concerning attacks on TEEs. The goal is to persuade you to re-consider how you deploy TEE-based applications, if you should deploy them at all.

Trusted hardware companies (Intel, AMD, etc.) mainly compete on performance, functionality and (one hopes) developer-friendliness. They may try to compete on security, but this is hard, in my opinion: there’s always someone else who can (mis)claim more security and such claims are hard to adjudicate by the market. Furthermore, the complexity of modern CPU architectures, the pervasiveness of side-channels and the centralization of attestation services all make TEE security claims tenuous.

In any case, (some of) the TEE attacks follow below.

Bugs in the enclave code

Enclaves are meant to protect secrets and integrity of computation from the environment (e.g., host OS, or even the physical environment). But even if the enclave platform is secure, bugs in the code running in the enclave can lead to disaster.

Signal’s contact discovery enclave had memory safety issues that allowed the host to confuse it and caused the enclave to leak its own memory contents1.

TEE remote attestation forgery bugs

Many of these attacks impacted not only Intel SGX but other TEE platforms as well, like AMD SEV.

2018, Foreshadow: malicious OS can steal Intel SGX attestation key (for the first time!)

2020, SGAxe: needs ring-0 access to steal SGX attestation key (this was the 2nd time!)

2022, ÆPIC Leak: microarchitectural bug allows host root admin to steal SGX attestation key

2024, BadRAM2, tampered DIMM SPD chip on AMD SEV-SNP systems

A host root admin with one-time physical access (~$10 to reprogram the DIMM) can run a backdoored VM while the genuine AMD chip signs a report attesting to the benign VM (no key is extracted, but the attestation is false).

2025, WireTap.fail3, interposition physical attack for DDR4 systems

“We have successfully extracted attestation keys, which are the primary mechanism used to determine whether code is running under SGX. This allows any hacker to masquerade as genuine SGX hardware, while in fact running code in an exposed manner and peeking into your data. We demonstrate concrete security breaks on real-world software utilizing SGX, such as Secret Network, Phala, Crust, and IntegriTEE.”

2025, TEE.fail4, interposition physical attack for DDR5 systems

2025, Battering RAM, interposition physical attack for DDR4 systems

2026, DDRrop5, interposition physical attack for DDR5 systems by dropping writes

Intel TDX remote attestation forgery

You may say: “I don’t care; my threat model precludes physical attacks.” No it doesn’t, silly: your remote attestation verifier accepts a quote from any Intel CPU in good standing. And the attacker’s CPU is one of them. A break of one is a break of all, unless…

Unless: you pin your verifier to only accept your own PCK certificates6, which implicitly excludes the attacker’s CPU. This works for so-called scalable SGX (the only flavor left) and requires you to carefully manage a PKI. So, effectively requires you to wield a footgun. Good luck!

TEE liveness bugs

DoS is explicitly outside the threat model of SGX, TDX, SEV-SNP and Nitro (b.c. the host can simply refuse to schedule the enclave). So, here, we focus on liveness issues due to issues with the TEE platform itself.

2018, Revocation of SGX credentials in light of Spectre/Meltdown left TEE enclaves paralyzed

2022, SGX.fail7 details how slowly TCB recoveries roll out and how platforms can be left “out of date” for long stretches

2022, TPM Attestation Failure on AMD Platforms with ASP fTPM

Example impact: Gamers may be unable to compete in online cash tournaments.

More academic paper attacks

So many7$^,$8$^,$9$^,$10.

In theory, there are ways to reduce the attack surface of trusted hardware. For example, see Sanctum11 from my group at MIT back in the day (shameless plug). Unfortunately, in practice, these more principled designs tend to come with lower performance and/or less functionality.

Conclusion

There is much to be said about the safe use of TEEs12. This blog only touches on the threat model of, and past attacks on, TEEs. It is not trying to argue there is no way to leverage TEEs for security.

tl;dr? don’t put valuable secrets in your TEEs, or they’re likely to become public, especially if physical attacks are in your threat model.

TEEs can be used for defense-in-depth: e.g., put your MPC nodes in TEEs, or build low-stakes confidential apps with shared state whose privacy is provided by TEEs but whose integrity is assured via ZKPs.

But, since you’re likely going to ignore all of this, at least use TEEs carefully?13$^,$14$^,$15

References

For cited works, see below 👇👇