WireTap demonstrates a critical vulnerability specifically in Intel SGX's memory encryption implementation, but does not identify Intel TDX as vulnerable to this attack.
An attacker who gains physical access to a server (guy-with-a-glock argument) can use inexpensive hardware (a DRAM interposer and logic analyzer) to monitor the memory bus. By analyzing the patterns in SGX's encrypted memory traffic, they can extract the Quoting Enclave's private signing key.
Once this key is obtained, the attacker can forge legitimate-looking attestation quotes, effectively impersonating trusted enclaves. This compromises both the confidentiality and integrity of any SGX-protected workload.
Is Intel TDX vulnerable?
Intel TDX (Trust Domain Extensions) is not vulnerable to the WireTap attack for several key reasons and implements significant architectural improvement over SGX:
Hardware requirements: TDX requires 4th or 5th Generation Intel Xeon Scalable Processors (Sapphire Rapids and Emerald Rapids), which mandate DDR5 memory. WireTap specifically targets DDR4 memory systems, making the current attack technically incompatible.
Memory integrity: TDX implements memory integrity verification across the entire physical address space, not just isolated memory regions like SGX's Enclave Page Cache. This includes the Alias Checking Trusted Module (ACTM) which prevents the memory aliasing attacks that similar vulnerabilities like BatteringRAM exploit.
Security maturity
The WireTap attack is serious and deserves attention, but it's important to maintain perspective. Every security technology has vulnerabilities—hardware, software, and cryptographic libraries alike.
TEEs have existed in various forms far longer than zero-knowledge systems: TrustZone in mobile devices since 2004, DRM and payment chips for decades, and SGX since 2015. This maturity means researchers and adversaries understand where to attack, resulting in a steady stream of disclosed vulnerabilities. This isn't a weakness—it's the natural evolution of battle-tested technology.
By comparison, ZK proof systems are complex, evolving rapidly, and their unknown vulnerabilities remain undiscovered. This doesn't make them inferior—it makes them younger. Vulnerabilities will emerge in ZK systems too, and when they do, the response should be the same: responsible disclosure, rapid patching, and collaborative improvement.
Protecting Data in Use
We know how to protect static data with cryptography and data in transit with protocols like TLS Notary, but protecting data in use remains the biggest challenge. TEEs offer a pragmatic middle ground; while they require trusting hardware manufacturers and have known limitations, they enable complex computations at near-native performance using familiar languages and frameworks.
Alternative approaches like FHE provide stronger cryptographic guarantees but currently impose 100-1000x performance overhead and require specialized knowledge, making them impractical for most real-world applications today.
Our Approach
At Livy, we're aware of the security challenges facing TEE implementations. That's why we've made deliberate architectural choices:
We build on Intel TDX, not SGX, specifically because of its improved security architecture against attacks like WireTap. But we don't stop there—we're actively monitoring the security landscape, evaluating emerging vulnerabilities, and preparing migration paths if needed.
We provide hybrid verifiability by combining TDX execution with cryptographic proofs. When additional verification is needed, we leverage zkDCAP (zero-knowledge Data Center Attestation Primitives) to cryptographically verify TDX attestations, adding another layer of trustless verification to the attestation chain itself.
We maintain developer familiarity because security shouldn't require abandoning your tools and expertise. Developers can run existing code without modification, getting both Web2-level performance and Web3-level verifiability.
Our commitment is to deliver the strongest security posture available today while maintaining practical usability, and remain vigilant as the threat landscape evolves.
Conclusion
Until fully hardware-verifiable systems exist, we need practical solutions that deliver trust today. TEEs enable verifiable execution of AI models, DeFi vaults, and other critical systems while maintaining compliance and transparency. By combining them with cryptographic verification and building open, developer-driven systems, we create robust platforms that bring Web2 capabilities together with Web3-level security and verifiability.
References
[1] P.-C. Cheng, W. Ozga, E. Valdez, S. Ahmed, Z. Gu, H. Jamjoom, H. Franke, and J. Bottomley, "Intel TDX Demystified: A Top-Down Approach," ACM Comput. Surv., vol. 56, no. 3, pp. 65:1–65:30, Mar. 2024, doi: 10.1145/3652597.
[2] A. Muñoz, R. Ríos, R. Román, and J. López, "A survey on the (in)security of trusted execution environments," Computers & Security, vol. 129, p. 103180, 2023, doi:10.1016/j.cose.2023.103180
[3] J. Van Bulck, D. Oswald, E. Marin, et al., "WireTap: Breaking Server SGX via DRAM Bus Interposition," 2025. [Online]. Available: https://wiretap.fail/
[4] F. De Ridder, J. Van Bulck, et al., "Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via," 2025. [Online]. Available: https://batteringram.eu/
[5] Intel, "Data Center Attestation Primitives (DCAP)," Intel Developer Zone. [Online]. Available: https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/attestation-services.html