Trusted Execution Environments (TEEs) like Intel SGX and AMD SEV‑SNP recently hit the news with two nasty physical attacks: Battering RAM & Wiretap. These attacks target memory encryption and can expose attestation keys.
But here’s the kicker: Oasis wasn’t affected. Let’s break it down:
What went down with TEEs
The attacks:
Extract keys directly from memory using physical access.
Break the confidentiality guarantees of SGX v2 / SEV‑SNP.
Affected projects had to patch immediately.
examples: Phala, Secret Network, Crust, IntegriTEE.
Why Oasis stayed safe
Oasis isn’t just “TEE inside blockchain”. it’s layered security:
Runs critical components (key manager, Sapphire/Cipher runtimes) on older SGX v1, not affected by these attacks.
Core system doesn’t rely on enclave secrecy for correctness or funds safety.
Even if a TEE key were compromised, ephemeral keys & rotation reduce risk drastically.
Defense‑in‑Depth
Oasis uses multiple layers to protect users:
- On‑chain governance & staked validators
- Ephemeral key rotation & policy blacklists
- Enclave isolation for sensitive components
Even if a hardware TEE is compromised, consensus, funds, and historical messages stay safe.
Dev Takeaways
- TEEs are powerful but not infallible.
- Layered security > single-point trust.
- Design protocols assuming hardware can fail.
Oasis shows a blueprint for confidential computing done right in Web3.
Top comments (0)