Researchers from the Georgia Institute of Technology and Purdue University have disclosed TEE.Fail, a practical attack on trusted execution environments (TEEs) that targets servers using DDR5 memory. The team demonstrates cryptographic key extraction and attestation forgery against Intel SGX/TDX and AMD SEV‑SNP, raising concerns about isolation guarantees in modern data centers and cloud platforms.
What happened: a DDR5 memory-bus attack against TEEs
TEEs are designed to protect code and secrets from a potentially compromised operating system or hypervisor. However, in many DDR5 server deployments, memory encryption relies primarily on AES‑XTS without complementary integrity or anti‑replay protections at the memory-controller level. TEE.Fail shows that this performance-oriented trade-off can permit leakage of sensitive information through passive observation of the memory bus, even when memory is encrypted.
How TEE.Fail works: bus interception and AES‑XTS determinism
Low-cost DDR5 interposer and encrypted traffic capture
The researchers inserted a custom DDR5 interposer—built for under USD $1,000—between DIMMs and the motherboard to eavesdrop on memory traffic. By downclocking memory to 3200 MT/s and using a logic analyzer, they reliably captured encrypted blocks used by SGX/TDX enclaves and SEV‑SNP guests. This is a passive memory-bus interception technique requiring physical access but no chip decapsulation.
Kernel orchestration and a ciphertext dictionary
With root privileges, the team modified the Linux SGX driver to map virtual-to-physical addresses and to coerce repeated accesses to the same memory locations. Because AES‑XTS is deterministic per address (the same physical block produces the same ciphertext), they built a ciphertext dictionary that correlates observed patterns with sensitive data. This approach enabled partial plaintext recovery and reconstruction of high-value secrets.
Security impact: key extraction and forged attestation
Using recovered parameters (including nonces) alongside public signatures, the attack facilitated reconstruction of private signing keys, allowing researchers to forge SGX and TDX attestations—effectively impersonating a trusted environment. They report analogous extraction of OpenSSL signing keys inside AMD SEV‑SNP virtual machines, including scenarios with Ciphertext Hiding enabled. In tests on Intel Xeon platforms, the team also obtained a Provisioning Certificate Key (PCK), a device-identity credential used in attestation workflows.
Relation to prior DDR4 attacks: WireTap and Battering RAM
TEE.Fail builds on the methodology of earlier academic work—WireTap and Battering RAM—that used memory interposers against DDR4. The new contribution is the targeted exploitation of DDR5, where prevalent reliance on AES‑XTS without memory integrity or replay protection makes it easier to construct ciphertext dictionaries and harvest secrets from modern server platforms.
Threat model, limitations, and real-world risk
The attack requires a combination of conditions: physical access to the server, ability to insert an interposer, and elevated privileges to adjust kernel drivers. While this raises the bar for exploitation, the risk remains material in colocation facilities, supply-chain handling, insider scenarios, and “evil maid” threats. For organizations depending on SGX/TDX or SEV‑SNP to protect keys and ensure trustworthy attestation, compromise of signing material is a critical failure.
Vendor responses and immediate mitigations
The researchers notified Intel (April), Nvidia (June), and AMD (August). Vendors acknowledged the findings and indicated ongoing work on mitigations. In a bulletin, AMD stated that attacks requiring physical access fall outside its standard threat model and does not plan firmware updates. Regardless, organizations should strengthen operational controls to reduce exposure.
Recommended defensive measures
Practical steps include: minimizing physical access to servers; deploying tamper-evident seals and chassis intrusion sensors; enforcing Secure/Measured Boot and kernel-driver integrity controls (e.g., HVCI); restricting debugging and DMA; reviewing remote attestation pipelines and key rotation policies; and evaluating platforms that provide memory integrity and replay protection where performance budgets allow.
TEE.Fail underscores a long-standing lesson in secure systems design: encryption alone is insufficient without integrity and anti-replay. Organizations should reassess trust assumptions for TEEs deployed on DDR5-era platforms, engage vendors on roadmaps for integrity protection, and test critical workloads under realistic threat models. Continuous monitoring of vendor advisories and independent research will be essential to maintaining resilient confidential computing deployments.
