AI
SGX.fail and TEE.fail: What the Recent Physical Attacks Actually Did
SGX.fail and TEE.fail are physical memory-bus attacks published the month before this talk. In the SGX.fail physical memory-bus attack walkthrough (02:33), an attacker places a hardware device on the memory bus, sniffs encrypted traffic, and replays it. Root privilege is also required. The attack hits newer Intel SGX, Intel TDX, and AMD SEV, all of which switched to deterministic encryption for performance. Early SGX used nondeterministic ciphertext and is not affected.
Some in the Web3 community responded:
“TEE has been fully compromised.” — Kang Li (quoting a Web3 community claim)
Li’s counter: a highly privileged physical attack exploiting one performance tradeoff, not proof the security model is broken.
TEE Fundamentals and Why High Attack Volume Does Not Mean Total Compromise
TEE is not new. ARM introduced TrustZone close to 20 years ago. Intel SGX followed a decade later, then AMD SEV and Intel TDX. Each creates an isolated memory region that runs code even when the host OS or system administrator is compromised. Azure, Google Cloud, and Amazon all ship this as confidential computing.
TEE draws more scrutiny than ZKP, MPC, or FHE because it defends against a stronger adversary. Those alternatives assume attackers follow the protocol. TEE assumes your attacker already has root. A higher bar produces more published attacks, not a weaker technology.
“so far TE is still the best defense for privilege attack” — Kang Li
Where TEE Lives in Web3: Wallets, Layer-2 Rollups, and Privacy Chains
TEE appears in three places across Web3. Wallets and enterprise custodians use it to store and process private keys. Layer-2 rollups and off-chain compute networks, including Phala and Automata, run AI or batch computation outside the chain and post an attestation report on-chain as proof. On-chain AI inference is too expensive because every validator must participate; TEE shifts that work off-chain without abandoning verifiability. The third group covers privacy chains such as Secret Network, where all account balances and transaction history are public by default, and TEE shields state from that exposure.
Secret Network: How Blind Attestation Trust Opened a Consensus Key Theft Path
Secret Network runs every validator node inside an Intel SGX enclave and encrypts all blockchain state under a shared consensus seed. New nodes get that seed only after presenting a valid SGX attestation report. The network checked the report and nothing else.
“the early version of secret network blindly trust this without you know looking at any other factor” — Kang Li
TEE.fail showed the gap: steal an attestation key from real hardware, generate a convincing report on a normal machine, and Secret Network hands over the consensus seed. One key decrypts the entire chain state. The fix added proof-of-cloud checks verifying the node runs on a real cloud instance, not attestation alone.
Samsung Blockchain Wallet and SafeHeron: Software Bugs Inside the Enclave
Hardware isolation does not fix software bugs. Samsung’s TrustZone wallet accepted a size field from the normal world without bounds-checking it. Sending an oversized value triggered a failed malloc that exposed the wallet PIN through a leftover debug logging path (30:42). The PIN sat adjacent to the IO buffer, and a debug print statement left in shipped code sent it out in plaintext. SafeHeron’s open-source SGX enterprise custody module had the same class of flaw: an unvalidated pointer passed from normal world allowed arbitrary writes inside the enclave, enabling key extraction (32:15).
Takeaways and the Tclave Rust SDK
TEE is designed against a severe privilege-attacker threat model. Every published exploit tightens the system rather than killing it. Applications that rely on attestation reports alone, with no additional layer such as proof-of-cloud validation, are the ones that broke.
“so far TE is still the best defense for privilege attack” — Kang Li
To cut the memory-safety bugs that hardware isolation cannot fix, Li’s team built Tclave: a Rust SDK that replaces the C-based TEE libraries where most of those bugs live. Sample applications and SDK code are at tclave.apache.org.
Q&A
Are there any bottlenecks for TEE adoption in Web3 applications? No performance bottleneck — TEE is faster than ZKP and HSM — but adoption is blocked by perception, because critics compare TEE against alternatives under different threat models. ▶ 35:18
Have you found Web3 vendors more or less responsive to vulnerability disclosure compared to traditional enterprise vendors? Large enterprise vendors (Azure, Google Cloud, Intel) have mature disclosure processes, but some crypto projects still respond like vendors 20 years ago — one threatened legal action when shown a vulnerability. ▶ 37:36
Notable Quotes
TEE has been fully compromised. Kang Li (quoting a Web3 community claim) · ▶ 5:55
so far TE is still the best defense for privilege attack Kang Li · ▶ 8:34
in the crypto field I start to feel like I’m experiencing something like I experienced like 20 years ago Kang Li · ▶ 38:26
Key Takeaways
- Treat SGX.fail as a sophisticated physical attack with strong prerequisites, not proof that TEE is dead.
- Layer physical access controls and proof-of-cloud validation on top of attestation reports—never rely on attestation alone.
- Rewrite TEE application code in Rust to eliminate the memory safety bugs that hardware isolation cannot protect against.
About the Speaker
Kang Li
Dr. Kang Li is a member of the Teaclave, an open source project under Apache Foundation. He was the founder and mentor of multiple CTF teams, including Blue-lotus and Disekt. He has received multiple CVEs related to Azure Confidential Computing, AMD SEV-SNP, and Samsung TEE trusted applications. He currently works at a security auditing firm specializing in confidential computing implementations.