TEE in Web3: Myths, Risks, and Real-World Pitfalls

TEE in Web3: Myths, Risks, and Real-World Pitfalls

Speakers: Kang Li, CTO, CertiK

Conference: DefCamp

YouTube: https://www.youtube.com/watch?v=caFS1dhULa0

Overview

In this insightful DefCamp talk, Kang Li, CTO of CertiK, delves into the complex interplay of Trusted Execution Environments (TEEs) and Web3 applications, aiming to demystify common misconceptions and highlight critical security pitfalls. The presentation addresses the recent waves of physical attacks against TEEs, such as SDX.fail and T.fail, which have fueled exaggerated claims that TEE technology is "fully compromised." Li robustly debunks this notion, arguing that while these attacks are severe and expose specific vulnerabilities in certain TEE implementations, they do not invalidate the fundamental security model of TEEs, especially when defending against highly privileged software attacks.

The talk provides essential context on what TEEs are, how they function across various hardware platforms (Intel SGX/TDX, AMD SEV, Arm TrustZone), and their diverse applications within the evolving Web3 landscape, from secure wallets to privacy-preserving blockchains. Li underscores the importance of understanding the specific threat models TEEs are designed to counter, contrasting them with other privacy-enhancing technologies. Through real-world examples, including vulnerabilities discovered in the Secret Network and Samsung Blockchain Wallet, he illustrates how sophisticated physical attacks and seemingly innocuous software bugs can undermine the security assurances provided by TEEs if not properly integrated and managed.

Ultimately, Li's presentation serves as a critical call to action for Web3 developers and security professionals. It emphasizes that while TEEs offer unparalleled protection against insider threats and privileged software access, their effective deployment requires a comprehensive understanding of their limitations, a multi-layered security approach that extends beyond mere attestation, and rigorous software development practices. The talk provides a balanced, analytical perspective, reaffirming TEEs as a vital component of robust security architectures, particularly in the challenging and high-stakes environment of Web3.

Background

▶ Watch: Introduction and recent TEE physical attacks (0:00)

The concept of a Trusted Execution Environment (TEE), while gaining renewed attention with confidential computing, is far from new. Kang Li traces its origins back to Arm's TrustZone, introduced nearly two decades ago for mobile devices. On a typical smartphone, the operating system (Android/iOS) runs in a "normal world," while sensitive operations like fingerprint verification, biometric identification, and payment processing occur within an isolated "trust zone" – the TEE. This isolation ensures that even a compromised operating system cannot access or tamper with critical data or code executing within the TEE.

More recently, hardware vendors like Intel and AMD have extended this concept to general-purpose computing with solutions like Intel SGX (Software Guard Extensions), Intel TDX (Trust Domain Extensions), and AMD SEV (Secure Encrypted Virtualization). These technologies allow developers to create enclaves – protected memory regions where code and data are isolated and encrypted, even from the host operating system, hypervisor, or other privileged software. Early SGX required applications to be specifically modified to run within enclaves, while newer generations like TDX and SEV allow entire virtual machines to operate as large enclaves, simplifying adoption.

These hardware-backed TEEs are the foundation of Confidential Computing, a paradigm where cloud providers (Azure, Google Cloud, Amazon) offer environments where data remains encrypted in memory and is only decrypted within the TEE. This model protects against insider threats, including malicious cloud administrators, and even a compromised administrator account, by ensuring that sensitive data is never exposed outside the secure enclave.

Li, having led teams working on TEEs and confidential computing for years, brings extensive prior experience to the discussion. His team was notably the first to publicly break the AMD SEV Secure Nested Paging (SMP) version, demonstrating a side-channel vulnerability that allowed data leakage with root access (which AMD subsequently fixed). They also developed SGX-Ray, a software tool released at Black Hat USA, designed to identify software implementation vulnerabilities within SGX enclaves, uncovering numerous bugs.

A crucial point Li emphasizes is the difference in security models when comparing TEEs to other privacy-enhancing technologies like Fully Homomorphic Encryption (FHE), Zero-Knowledge Proofs (ZKPs), or Multi-Party Computation (MPC). TEEs are designed to protect against privileged attackers, assuming the adversary might even have root access to the system. In contrast, many other technologies operate under a semi-honest security model, meaning participants or adversaries are assumed to follow the protocol, even if they try to infer information. This fundamental difference explains why TEEs are subjected to intense scrutiny and frequent public vulnerability reports – they aim to protect against a much stronger adversary, and any crack is significant. Despite this, cloud vendors continue to rely on TEEs for the strongest available protection against insider threats.

The talk then transitions to Web3, which Li describes as primarily a marketing term encompassing a range of blockchain and crypto applications. At its core, a Web3 application involves users submitting transactions to a distributed network of validator nodes. These nodes achieve consensus, agree on the transaction's validity, and record it on a public ledger (blockchain), making it immutable and transparent.

TEEs find diverse applications within the Web3 ecosystem, broadly categorized into three groups:

1. Wallets and Enterprise Custodians: Many crypto assets are stored or processed using TEEs to secure private keys and signing operations.
2. Layer 2 Rollups and Off-chain Computation: For computationally intensive tasks like AI processing or to scale blockchain transactions, operations are moved off-chain. TEEs can provide verifiable computation for these tasks, with attestation reports posted on-chain. Examples include Phala Network and Automata.
3. Private Chains and Privacy-Preserving Public Chains: To address the inherent transparency of public blockchains, some projects use TEEs to encrypt transaction data and blockchain state, ensuring that only code running within authenticated TEEs can access or decrypt this information. The Secret Network and Builder.net are prominent examples.

These foundational concepts set the stage for understanding the specific vulnerabilities and risks that emerge when TEEs are deployed in real-world Web3 scenarios.

Key Findings

▶ Watch: TEE's strong threat model vs. other privacy tech (13:50)

The central and most critical finding of Kang Li's talk is a strong refutation of the recent media narrative claiming TEEs have been "fully compromised." While acknowledging the severity of recent physical attacks like SDX.fail and T.fail, Li firmly asserts that TEEs remain the best defense against privileged attacks, such as those launched by cloud administrators or compromised root accounts. The perception of TEEs being fundamentally broken stems from a misunderstanding of their threat model and the specific nature of these advanced attacks.

Key findings from the talk include:

1. TEEs are not fully compromised; their security model remains valid for privileged attacks. The recent physical attacks, while impactful, exploit specific implementation details and require significant prerequisites (physical access, root privileges), not a complete breakdown of the TEE security architecture. Many common threats that TEEs protect against (e.g., cloud admin snooping) are still effectively mitigated.
2. Recent physical attacks (SDX.fail, T.fail) target specific TEE implementations due to performance optimizations. These attacks exploit the shift from non-deterministic to deterministic AES encryption in newer generations of Intel TDX, later versions of SGX, and AMD SEV. This optimization, while improving performance, introduced a vulnerability where identical plaintext in the same physical memory location yields identical ciphertext, creating a detectable pattern for sophisticated physical attackers. Older SGX designs, with their non-deterministic encryption, are not susceptible to these particular attacks.
3. Web3 applications that blindly trust TEE attestation reports are vulnerable. The talk highlights how the Secret Network, by solely relying on attestation reports to onboard validator nodes, became susceptible to the SDX.fail/T.fail attacks. If an attacker can fake an attestation report (by stealing attestation keys and running on a non-TEE machine), the network unknowingly sends sensitive consensus keys to a compromised "enclave," undermining its privacy guarantees.
4. Software vulnerabilities within the TEE application code itself pose significant risks. Beyond hardware-level exploits, Li demonstrates that even with a robust TEE, flaws in the software running inside the enclave can lead to critical compromises. Examples include insufficient input validation, memory boundary errors (buffer overflows), and unintended data leaks, as shown in the Samsung Blockchain Wallet and Safeheron SGX wallet examples. These are common software engineering challenges, but their impact within a TEE can be catastrophic.
5. A multi-layered security approach is essential for TEE deployments in Web3. The failures discussed underscore that TEEs are a powerful component, but not a standalone panacea. Effective security requires combining TEE attestation with additional layers of validation, physical security measures, and rigorous software development practices. Relying solely on the hardware attestation, without considering the broader operational security (OpSec) context, is a critical mistake.

In essence, while TEEs offer a robust foundation for confidential computing, their successful implementation in the complex and adversarial Web3 environment demands a holistic security strategy that accounts for both sophisticated hardware exploits and common software vulnerabilities.

Technical Deep Dive

▶ Watch: Secret Network's attestation vulnerability and lesson learned (22:50)

The technical core of the talk revolves around two primary categories of vulnerabilities: advanced physical attacks on TEE hardware and software implementation flaws within TEE-enabled applications.

Physical Attacks: SDX.fail and T.fail

The SDX.fail and T.fail attacks represent a new frontier in TEE exploitation, moving beyond traditional software-based side channels to require physical access and root privileges. The attacker's methodology involves:

1. Physical Device Access: An attacker must insert a physical device to perform a man-in-the-middle attack or sniff the memory bus. This is akin to network sniffing but applied directly to the CPU's memory access pathways.
2. Root Privilege: The attacker needs root access to the host system to pin specific memory regions to physical memory locations. This control is crucial for the exploit.

The fundamental vulnerability these attacks exploit lies in a performance optimization introduced in newer TEE generations: deterministic AES encryption.

• Early Intel SGX Design: Memory encryption was non-deterministic. If the same plaintext was written to the same physical memory location multiple times, the resulting ciphertext would be different each time. This made pattern analysis extremely difficult.
• Newer TEEs (Intel TDX, newer SGX, AMD SEV): For performance reasons, Intel and AMD adopted deterministic AES encryption. This means that if the same plaintext is written to the same physical memory location, it will consistently produce the same ciphertext. This predictability is the crack that SDX.fail and T.fail exploit. By observing the memory bus, an attacker can detect patterns in encrypted data, inferring information about the plaintext content.

Intel and AMD's response to these disclosures has been that such attacks fall outside their initial design assumptions, as they require physical access to the device – a strong prerequisite. However, for sensitive applications, especially in Web3 where trust assumptions are paramount, this distinction is critical.

Web3 Application Exploitation: Secret Network Example

The Secret Network is a prominent example of a public blockchain that leverages Intel SGX to provide privacy-preserving features. Its architecture is designed such that:

• Validator Nodes: All validator nodes run inside Intel SGX enclaves.
• Encrypted State: The entire blockchain state is encrypted and only decrypted within the TEE.
• Consensus Seed: A common consensus seed, encrypted by the public key attested by the TEE, is used to decrypt the state inside the enclave, allowing validators to reach agreement.
• Node Joining: New nodes must stake crypto assets and provide a valid attestation report from their Intel SGX enclave. This report is generated by a quoting enclave using an Intel-provided provisioning key, making it difficult to fake.

The critical vulnerability in the Secret Network's early design was its blind trust in this attestation report. The network assumed that a valid attestation report unequivocally proved that a node was running on genuine SGX hardware and that the enclave was secure.

• Exploit with SDX.fail/T.fail: These physical attacks enable an adversary to steal an SGX attestation key. With this key, an attacker can run a normal (non-TEE) machine, pretend to be an SGX validator node, and generate a seemingly valid attestation report.
• Consequence: The Secret Network, upon receiving this fake report, would then send the highly sensitive consensus seed (encrypted for the "enclave") to the attacker's fake machine. Since the attacker controls this "enclave," they can decrypt the consensus seed, gain access to the network's private state, and potentially manipulate transactions, completely undermining the network's privacy guarantees.

Mitigation: Secret Network has since addressed this by adding additional validation methods, such as checking the identity of nodes in their network and implementing extra physical validation to ensure actual hardware is being used, demonstrating that attestation alone is insufficient.

Software Vulnerabilities: Samsung Blockchain Wallet Example

Beyond hardware exploits, Kang Li highlights prevalent software implementation vulnerabilities within the Trust Applications (TAs) running inside TEEs. He describes work his team did to compromise the Samsung Blockchain Wallet, which uses Arm TrustZone.

• Architecture: The wallet handles private key generation, storage, and transaction signing within the TrustZone. It also employs a trusted UI for PIN entry, ensuring the PIN is captured only by the TEE and not exposed to the normal (Android) operating system. The private key never leaves the TrustZone.
• Vulnerability Type: The team focused on the interaction between the normal world application and the TA in the TrustZone. Common issues identified include:
• Insufficient Input Validation: TAs often fail to adequately validate inputs received from the potentially malicious normal world.
• Memory Boundary Errors: Lack of checks for memory bounds can lead to buffer overflows or underflows.
• Unintended Data Leaks: Debugging features or improper handling of errors can inadvertently expose sensitive data.

Specific Pin Leak Bug: A critical bug was found where manipulating the input size could lead to a pin leak:

1. Attacker-Controlled Input: The normal world application sends data to the TA, including a size parameter. An attacker can control this size.
2. malloc Failure: By sending a size larger than the intended IO_BUFF memory unit, the TA's internal code would attempt multiple malloc calls. The first malloc might succeed, but the subsequent one would fail due to memory exhaustion within the enclave's limited resources.
3. Memory Layout and Debugging: Due to an accidental memory layout, the user's PIN number was located immediately adjacent to the buffer being allocated. Crucially, the TA had an unnecessary debugging message that would print out information upon certain internal failures.
4. Pin Leak: When the second malloc failed, the debugging message was triggered, inadvertently printing the adjacent PIN number through the debug channel. This allowed the attacker, controlling the normal world, to exfiltrate the user's PIN. Samsung has since fixed this vulnerability.

Another example cited was a Safeheron SGX Wallet, which had a similar memory boundary problem. It failed to validate pointers when moving data between the normal world and the enclave, allowing a privileged attacker to manipulate pointer values, causing memory overwrites and leaks within the enclave.

These examples underscore that even with robust hardware TEEs, the software running within them must adhere to stringent security engineering principles to avoid critical compromises. The speaker also mentioned the Tclave project, which aims to rewrite TEE SDKs in Rust, a memory-safe language, to inherently prevent many of these common memory corruption bugs found in C-based implementations.

Demo / Proof of Concept

▶ Watch: Samsung Blockchain Wallet PIN leakage software bug (30:10)

While the talk did not feature live, interactive demonstrations of exploits, the speaker provided detailed conceptual proofs of concept by meticulously outlining the attack methodologies and their impact on real-world Web3 applications. These descriptions served to illustrate how both sophisticated physical attacks and common software vulnerabilities could compromise the integrity and confidentiality offered by TEEs.

Specifically, the discussion around SDX.fail and T.fail attacking the Secret Network served as a compelling proof of concept for the dangers of blindly trusting TEE attestation. The step-by-step explanation of how an attacker could steal an attestation key, fake an SGX environment, and trick the network into sending sensitive consensus keys demonstrated the practical exploit chain. This wasn't a live demo, but a clear articulation of how the reported vulnerabilities could be leveraged.

Similarly, the in-depth breakdown of the software bug found in the Samsung Blockchain Wallet provided a concrete proof of concept for internal TEE application vulnerabilities. The speaker detailed the specific interaction between the normal world and the Trust Application (TA), explaining how a manipulated size parameter, combined with memory layout and a debug message, directly led to the leakage of a user's PIN. This technical explanation, derived from actual vulnerability research, functioned as a powerful demonstration of the exploit's feasibility and mechanism.

These detailed case studies, backed by the speaker's extensive experience and prior research (e.g., breaking AMD SEV, developing SGX-Ray), effectively conveyed the real-world implications of the discussed myths and risks, serving as robust conceptual demonstrations of the outlined pitfalls.

Defensive Implications

▶ Watch: Web3 vs. enterprise vulnerability disclosure maturity (37:40)

The insights from Kang Li's talk provide crucial guidance for developers, security architects, and organizations deploying TEEs, especially within the Web3 ecosystem. Effective defense requires a multi-faceted approach that addresses both hardware-level threats and software-specific vulnerabilities.

1. Never Blindly Trust Attestation Reports Alone: The Secret Network example is a stark reminder that TEE attestation, while powerful, is not a standalone security solution. While it verifies the authenticity of the enclave and its code, it doesn't necessarily guarantee the physical integrity of the underlying hardware or the broader operational security. Web3 applications must implement additional layers of validation, such as:

• Proof of Cloud/Physical Security: Integrate attestation with checks for the physical environment where the TEE is hosted. For instance, using trusted cloud providers with robust physical security measures (e.g., monitoring, access controls) can mitigate physical attacks like SDX.fail/T.fail.
• Multi-Factor Attestation: Incorporate other forms of verification beyond a single attestation report, such as network-level checks or reputation systems for validators.
• Regular Audits and Monitoring: Continuously monitor the operational environment for anomalies that might indicate a compromised TEE or host.

1. Prioritize Software Memory Safety within TEEs: The Samsung Blockchain Wallet and Safeheron SGX Wallet vulnerabilities highlight that software bugs within the enclave are a major attack vector. Even the most secure hardware cannot protect against flawed code running inside it. Developers must:

• Rigorous Input Validation: All data entering the TEE from the untrusted normal world must be meticulously validated for type, size, and content to prevent injection attacks, buffer overflows, and other memory corruption issues.
• Strict Memory Boundary Checks: Implement robust checks to ensure that memory accesses stay within allocated bounds, preventing overwrites and leaks.
• Avoid Unnecessary Debugging/Information Leakage: Remove or secure debugging features in production environments, as they can inadvertently expose sensitive internal state or data.
• Adopt Memory-Safe Languages: Actively explore and adopt languages like Rust (as exemplified by the Tclave project) for TEE application development. Rust's strong type system and borrow checker prevent many common memory safety bugs (e.g., null pointer dereferences, use-after-free, buffer overflows) at compile time, significantly reducing the attack surface.

1. Understand and Define Your Threat Model: TEEs are specifically designed to defend against privileged attackers (e.g., root users, cloud administrators). It's crucial not to misapply TEEs to problems better suited for other privacy-enhancing technologies (like ZKP or FHE) that operate under different, often weaker, threat models. Conversely, for scenarios involving high-privilege adversaries, TEEs remain the strongest available defense.

1. Stay Informed and Patch Regularly: The security landscape for TEEs is dynamic, with new research and exploits emerging periodically. Organizations must have processes in place to monitor vulnerability disclosures, apply patches promptly, and update their TEE firmware and software components.

1. Secure the Supply Chain and Physical Access: Given that attacks like SDX.fail and T.fail require physical access and potentially involve stealing attestation keys, securing the entire supply chain of TEE hardware and restricting physical access to sensitive servers are paramount. This involves standard data center security practices, but with an elevated focus on hardware tampering.

By integrating these defensive strategies, Web3 applications can leverage the powerful security features of TEEs while mitigating the risks exposed by recent research and real-world vulnerabilities.

Key Takeaways

• TEEs are not "fully compromised": Despite recent sophisticated physical attacks (SDX.fail, T.fail), TEEs remain the most robust defense against privileged software attackers, such as malicious cloud administrators or compromised root accounts. Their fundamental security model is still valid for a wide range of threats.
• Physical attacks exploit specific TEE versions and require strong prerequisites: The SDX.fail and T.fail attacks leverage deterministic AES encryption in newer TEEs (Intel TDX, later SGX, AMD SEV) and require physical access to the memory bus plus root privileges on the host system. Older SGX versions with non-deterministic encryption are not susceptible to these particular attacks.
• Blind trust in TEE attestation is a critical vulnerability: Web3 applications like the Secret Network, which solely relied on attestation reports for node validation, were vulnerable to these physical attacks. A multi-layered security approach, combining attestation with additional physical security and operational validation, is essential to prevent compromise.
• Software vulnerabilities within TEE applications are a significant risk: Even with secure TEE hardware, flaws in the code running inside the enclave (e.g., insufficient input validation, memory boundary errors, unintended data leaks) can lead to critical compromises, as demonstrated by the Samsung Blockchain Wallet pin leak and Safeheron SGX wallet vulnerabilities.
• Memory-safe languages can enhance TEE security: Projects like Tclave, which implement TEE SDKs in Rust, highlight a proactive approach to mitigate common memory corruption bugs (like buffer overflows) that plague C-based TEE development, offering a more secure foundation for Web3 applications.
• Understanding the threat model is paramount for TEE comparisons: TEEs are designed for a strong adversary (privileged access). When comparing TEEs to other privacy-enhancing technologies (FHE, ZKP, MPC), it's crucial to acknowledge their different security models, as TEEs often defend against a significantly more powerful attacker.

About the Speaker(s)

Kang Li is the Chief Technology Officer (CTO) at CertiK, a leading Web3 security firm. With a deep background in hardware security and confidential computing, Li brings extensive expertise to the intersection of TEEs and blockchain technology. He previously worked at Intel, as noted by his disclaimer at the beginning of the talk, indicating his familiarity with the development and security aspects of Intel's TEE offerings like SGX and TDX.

Prior to his role at CertiK and his foray into the Web3 space (which he joined approximately three years ago), Kang Li led teams focused on TEEs and confidential computing research. His notable achievements include being part of the first team to publicly break the AMD SEV Secure Nested Paging (SMP) version, identifying a side-channel vulnerability. His team also developed SGX-Ray, a software tool designed to uncover software implementation vulnerabilities in SGX enclaves, which was released at Black Hat USA. His experience spans both breaking and building secure systems, providing a comprehensive perspective on the challenges and solutions in TEE security.