{"article":{"slug":"its-time-to-talk-about-tees","title":"It's Time to Talk About TEEs","subtitle":null,"summary":"Alin Tomescu surveys concerning attacks on trusted execution environments such as Intel SGX and AMD SEV, and argues that teams should reconsider how, and whether, they deploy TEE-based applications given how hard hardware security claims are to verify.","content_type":"opinion","language":"en","canonical_url":"https://alinush.github.io/tee","author":{"name":"Alin Tomescu","url":"https://alinush.github.io/","person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"Alin Tomescu","url":"https://alinush.github.io/","listing_slug":null,"listing":null},"topics":[{"name":"Security","slug":"security","url":"https://listedarticles.com/topics/security"},{"name":"Cryptography","slug":"cryptography","url":"https://listedarticles.com/topics/cryptography"},{"name":"Trusted Execution Environments","slug":"trusted-execution-environments","url":"https://listedarticles.com/topics/trusted-execution-environments"}],"about_listings":[],"cover_image_url":null,"license":"CC-BY-NC-4.0","word_count":1057,"reading_minutes":5,"published_at":"2026-10-11T00:00:00.000Z","added_at":"2026-10-18T05:17:09.498Z","updated_at":"2026-10-18T05:17:09.498Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":true},"profile_url":"https://listedarticles.com/articles/its-time-to-talk-about-tees","markdown_url":"https://listedarticles.com/articles/its-time-to-talk-about-tees.md","example":false,"citation":"Alin Tomescu, Alin Tomescu. \"It's Time to Talk About TEEs.\" 11 Oct 2026. https://alinush.github.io/tee (CC-BY-NC-4.0)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://alinush.github.io/tee"},"body_markdown":"This post surveys some concerning attacks on TEEs.\nThe goal is to persuade you to re-consider how you deploy TEE-based applications, if you should deploy them at all.\n\nTrusted hardware companies (Intel, AMD, etc.) mainly compete on performance, functionality and (one hopes) developer-friendliness.\nThey 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.\nFurthermore, the complexity of modern CPU architectures and the pervasiveness of side-channels makes TEE security claims tenuous.\n\nIn any case, (some of) the TEE attacks follow below.\n\n## Bugs in the enclave code\n\nEnclaves are meant to protect secrets and integrity of computation from the environment (e.g., host OS, or even the physical environment).\nBut even if the enclave platform is secure, bugs in the code running in the enclave can lead to disaster.\n\n- 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 contents[1](#fn:signal-sgx).\n\n## TEE remote attestation forgery bugs\n\nMany of these attacks impacted not only Intel SGX but other TEE platforms as well, like AMD SEV.\n\n- 2018, [Foreshadow](https://foreshadowattack.eu/): malicious OS can steal Intel SGX attestation key (for the first time!)\n- 2020, [SGAxe](https://sgaxe.com/): needs ring-0 access to steal SGX attestation key (this was the 2nd time!)\n- 2022, [ÆPIC Leak](https://aepicleak.com/): microarchitectural bug allows host root admin to steal SGX attestation key\n- 2024, [BadRAM](https://badram.eu/)[2](#fn:DWOplus25), tampered DIMM SPD chip on AMD SEV-SNP systems\n - 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).\n- 2025, [WireTap.fail](https://wiretap.fail/)[3](#fn:SDAplus25), interposition physical attack for DDR4 systems\n - *“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.”*\n- 2025, [TEE.fail](https://tee.fail)[4](#fn:CSBplus26), interposition physical attack for DDR5 systems\n- 2025, [Battering RAM](https://batteringram.eu/), interposition physical attack for DDR4 systems\n- 2026, [DDRrop](https://ddropattack.eu/)[5](#fn:DGJplus26), interposition physical attack for DDR5 systems by dropping writes\n - Intel TDX remote attestation forgery\n\nYou may say: *“I don’t care; my threat model precludes physical attacks.”*\nNo it doesn’t, silly: your remote attestation verifier accepts a quote from *any* Intel CPU in good standing.\nAnd the attacker’s CPU is one of them.\nA break of one is a break of all, unless…\n\nUnless: you pin your verifier to only accept your own PCK certificates[6](#fn:epid), which implicitly excludes the attacker’s CPU.\nThis works for so-called [scalable SGX](https://www.intel.com/content/www/us/en/content-details/843058/supporting-intel-sgx-on-multisocket-platforms.html) (the only flavor left) and requires you to carefully manage a PKI.\nSo, effectively requires you to wield a footgun.\nGood luck!\n\n## TEE liveness bugs\n\nDoS is explicitly outside the threat model of SGX, TDX, SEV-SNP and Nitro (b.c. the host can simply refuse to schedule the enclave).\nSo, here, we focus on liveness issues due to issues with the TEE platform itself.\n\n- 2018, [Revocation of SGX credentials in light of Spectre/Meltdown left TEE enclaves paralyzed](https://community.intel.com/t5/Intel-Confidential-Computing/GROUP-OUT-OF-DATE-what-is-the-most-recent-microcode-version/m-p/1139549?countrylabel=Latin%25252520America&profile.language=en)\n- 2022, [SGX.fail](https://sgx.fail)[7](#fn:VSYplus22) details how slowly TCB recoveries roll out and how platforms can be left “out of date” for long stretches\n- 2022, [TPM Attestation Failure on AMD Platforms with ASP fTPM](https://www.amd.com/en/resources/support-articles/faqs/pa-420.html)\n - Example impact: Gamers may be unable to compete in online cash tournaments.\n\n## More academic paper attacks\n\nSo many[7](#fn:VSYplus22)$^,$[8](#fn:ZGWplus24)$^,$[9](#fn:MHHW18)$^,$[10](#fn:TSS17).\n\nIn theory, there are ways to reduce the attack surface of trusted hardware.\nFor example, see Sanctum[11](#fn:CLD15e) from my group at MIT back in the day (shameless plug).\nUnfortunately, in practice, these more principled designs tend to come with lower performance and/or less functionality.\n\n## Conclusion\n\nDon’t put valuable secrets in your TEEs, or they’re likely to become public, especially if physical attacks are in your threat model[12](#fn:nuance).\n\n## References\n\nFor cited works, see below 👇👇\n\n1. [Signal’s SGX-based contact discovery gets broken](https://x.com/v12sec/status/2092664320547254388) [↩](#fnref:signal-sgx)\n2. **BadRAM}: Practical Memory Aliasing Attacks on Trusted Execution Environments**, by De Meulemeester, Jesse and Wilke, Luca and Oswald, David and Eisenbarth, Thomas and Verbauwhede, Ingrid and Van Bulck, Jo, *in 46th {IEEE} Symposium on Security and Privacy ({S\\&P})*, 2025 [↩](#fnref:DWOplus25)\n3. **WireTap: Breaking Server SGX via DRAM Bus Interposition**, by Alex Seto and Oytun Kuday Duran and Samy Amer and Jalen Chuang and Stephan van Schaik and Daniel Genkin and Christina Garman, *in 2025 SIGSAC Conference on Computer and Communications Security (CCS ‘25)*, 2025, [[URL]](https://wiretap.fail) [↩](#fnref:SDAplus25)\n4. **TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition**, by Jalen Chuang and Alex Seto and Nicolas Berrios and Stephan van Schaik and Christina Garman and Daniel Genkin, *in 47th IEEE Symposium on Security and Privacy (IEEE S\\&P ‘26)*, 2026, [[URL]](https://tee.fail) [↩](#fnref:CSBplus26)\n5. **DDRop}: Active Memory Interposer Attacks on Confidential {VMs} by Dropping {DDR5} Writes**, by De Meulemeester, Jesse and Gloor, Stefan and Jattke, Patrick and Moghimi, Daniel and Oswald, David and Thompson, Martin and Razavi, Kaveh and Verbauwhede, Ingrid and Van Bulck, Jo, *in Proceedings of the 2026 {ACM} {SIGSAC} Conference on Computer and Communications Security ({CCS} ‘26)*, 2026 [↩](#fnref:DGJplus26)\n6. It is my understanding that the “old” 2015 SGX architecture based on EPID is now retired. [↩](#fnref:epid)\n7. **SoK}: {SGX.Fail}: How Stuff Get e{X}posed**, by van Schaik, Stephan and Seto, Alex and Yurek, Thomas and Batori, Adam and AlBassam, Bader and Garman, Christina and Genkin, Daniel and Miller, Andrew and Ronen, Eyal and Yarom, Yuval, 2022, [[URL]](https://sgx.fail) [↩](#fnref:VSYplus22) [↩2](#fnref:VSYplus22:1)\n8. **CacheWarp}: Software-based Fault Injection using Selective State Reset**, by Zhang, Ruiyi and Gerlach, Lukas and Weber, Daniel and Hetterich, Lorenz and Lü, Youheng and Kogler, Andreas and Schwarz, Michael, *in 33rd USENIX Security Symposium (USENIX Security 24)*, 2024 [↩](#fnref:ZGWplus24)\n9. **SEVered: Subverting AMD’s Virtual Machine Encryption**, by Mathias Morbitzer and Manuel Huber and Julian Horsch and Sascha Wessel, 2018, [[URL]](https://arxiv.org/abs/1805.09604) [↩](#fnref:MHHW18)\n10. **CLKSCREW}: Exposing the Perils of {Security-Oblivious} Energy Management**, by Adrian Tang and Simha Sethumadhavan and Salvatore Stolfo, *in 26th USENIX Security Symposium (USENIX Security 17)*, 2017, [[URL]](https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/tang) [↩](#fnref:TSS17)\n11. **Sanctum: Minimal Hardware Extensions for Strong Software Isolation**, by Victor Costan and Ilia Lebedev and Srinivas Devadas, *in Cryptology {ePrint} Archive, Paper 2015/564*, 2015, [[URL]](https://eprint.iacr.org/2015/564) [↩](#fnref:CLD15e)\n12. For a more nuanced take, see [Andrew Miller’s post](https://medium.com/initc3org/tee-based-smart-contracts-and-sealing-pitfalls-eccd5d751329). [↩](#fnref:nuance)\n\n\nThis work is licensed under a [Attribution-NonCommercial 4.0 International](https://creativecommons.org/licenses/by-nc/4.0/) license.\n","body_html":"

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

\n

Trusted hardware companies (Intel, AMD, etc.) mainly compete on performance, functionality and (one hopes) developer-friendliness.\nThey 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.\nFurthermore, the complexity of modern CPU architectures and the pervasiveness of side-channels makes TEE security claims tenuous.

\n

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

\n

Bugs in the enclave code

\n

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

\n\n

TEE remote attestation forgery bugs

\n

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

\n\n

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

\n

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

\n

TEE liveness bugs

\n

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).\nSo, here, we focus on liveness issues due to issues with the TEE platform itself.

\n\n

More academic paper attacks

\n

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

\n

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

\n

Conclusion

\n

Don’t put valuable secrets in your TEEs, or they’re likely to become public, especially if physical attacks are in your threat model12.

\n

References

\n

For cited works, see below 👇👇

\n
  1. Signal’s SGX-based contact discovery gets broken ↩
  2. BadRAM}: Practical Memory Aliasing Attacks on Trusted Execution Environments, by De Meulemeester, Jesse and Wilke, Luca and Oswald, David and Eisenbarth, Thomas and Verbauwhede, Ingrid and Van Bulck, Jo, in 46th {IEEE} Symposium on Security and Privacy ({S\\&P}), 2025 ↩
  3. WireTap: Breaking Server SGX via DRAM Bus Interposition, by Alex Seto and Oytun Kuday Duran and Samy Amer and Jalen Chuang and Stephan van Schaik and Daniel Genkin and Christina Garman, in 2025 SIGSAC Conference on Computer and Communications Security (CCS ‘25), 2025, [URL] ↩
  4. TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition, by Jalen Chuang and Alex Seto and Nicolas Berrios and Stephan van Schaik and Christina Garman and Daniel Genkin, in 47th IEEE Symposium on Security and Privacy (IEEE S\\&P ‘26), 2026, [URL] ↩
  5. DDRop}: Active Memory Interposer Attacks on Confidential {VMs} by Dropping {DDR5} Writes, by De Meulemeester, Jesse and Gloor, Stefan and Jattke, Patrick and Moghimi, Daniel and Oswald, David and Thompson, Martin and Razavi, Kaveh and Verbauwhede, Ingrid and Van Bulck, Jo, in Proceedings of the 2026 {ACM} {SIGSAC} Conference on Computer and Communications Security ({CCS} ‘26), 2026 ↩
  6. It is my understanding that the “old” 2015 SGX architecture based on EPID is now retired. ↩
  7. SoK}: {SGX.Fail}: How Stuff Get e{X}posed, by van Schaik, Stephan and Seto, Alex and Yurek, Thomas and Batori, Adam and AlBassam, Bader and Garman, Christina and Genkin, Daniel and Miller, Andrew and Ronen, Eyal and Yarom, Yuval, 2022, [URL] ↩ ↩2
  8. CacheWarp}: Software-based Fault Injection using Selective State Reset, by Zhang, Ruiyi and Gerlach, Lukas and Weber, Daniel and Hetterich, Lorenz and Lü, Youheng and Kogler, Andreas and Schwarz, Michael, in 33rd USENIX Security Symposium (USENIX Security 24), 2024 ↩
  9. SEVered: Subverting AMD’s Virtual Machine Encryption, by Mathias Morbitzer and Manuel Huber and Julian Horsch and Sascha Wessel, 2018, [URL] ↩
  10. CLKSCREW}: Exposing the Perils of {Security-Oblivious} Energy Management, by Adrian Tang and Simha Sethumadhavan and Salvatore Stolfo, in 26th USENIX Security Symposium (USENIX Security 17), 2017, [URL] ↩
  11. Sanctum: Minimal Hardware Extensions for Strong Software Isolation, by Victor Costan and Ilia Lebedev and Srinivas Devadas, in Cryptology {ePrint} Archive, Paper 2015/564, 2015, [URL] ↩
  12. For a more nuanced take, see Andrew Miller’s post. ↩
\n

This work is licensed under a Attribution-NonCommercial 4.0 International license.

","headings":[{"level":2,"text":"Bugs in the enclave code","id":"bugs-in-the-enclave-code"},{"level":2,"text":"TEE remote attestation forgery bugs","id":"tee-remote-attestation-forgery-bugs"},{"level":2,"text":"TEE liveness bugs","id":"tee-liveness-bugs"},{"level":2,"text":"More academic paper attacks","id":"more-academic-paper-attacks"},{"level":2,"text":"Conclusion","id":"conclusion"},{"level":2,"text":"References","id":"references"}]}}