Oasis Unaffected by TEE Vulnerabilities 

Security researchers disclosed two physical attacks this week – Battering RAM and Wiretap – that successfully compromised Intel SGX and AMD SEV-SNP protections. The vulnerability affected multiple blockchain networks, including Phala, Secret, Crust, and IntegriTEE, forcing emergency upgrades. Thanks to the foresight of our team, Oasis remains secure and operational with zero impact.

Technical Background

The attacks exploited deterministic encryption in Intel's Scalable SGX and AMD SEV-SNP to extract attestation keys and bypass security guarantees. With these keys, attackers gained full access to encrypted smart contract data and cluster keys across affected networks.

In this sense, Oasis wasn't vulnerable due to preemptive steps taken. Years ago, the architecture was built to anticipate precisely this threat model. Oasis was designed with a fundamental principle: to separate concerns, ensuring that not all nodes require constant access to all keys, even when running in TEEs. 

The most critical infrastructure, Oasis key manager and Sapphire runtime, operates on Intel SGX v1 technology, which utilizes a fundamentally different memory encryption design that is unaffected by these attacks.

Defense in Depth

Even more importantly, Oasis has multiple layers of protection that exist entirely outside the TEE:

Onchain governance: Joining the Oasis key manager committee requires governance approval. For Sapphire/Cipher, participants must be validators with at least 5m staked ROSE. These requirements are enforced onchain and cannot be bypassed, even with full TEE compromise and possession of attestation keys.

Ephemeral keys: Transaction encryption uses ephemeral keys that rotate each epoch. Even if an attacker compromised a TEE and extracted keys, past transactions remain protected because those keys are securely erased and no longer exist.

Adaptive security policy: The network maintains a dynamic CPU blacklist system, allowing rapid response to newly discovered vulnerabilities at the hardware level. Following the private disclosure of these attacks, Oasis also implemented additional governance requirements for committee membership.

Conclusion

The researchers couldn't compromise Oasis because TEE access alone isn't sufficient. The network requires additional onchain enforceable conditions, stake amounts, governance approvals, and validator status that must be satisfied regardless of what happens inside the enclave.

While other blockchain projects work to upgrade their networks and assess the damage, Oasis continues operating exactly as designed, with no disruption and no compromise of user privacy. This validates the meticulous, multi-layered approach that we’ve followed since day one. 

For Oasis users and developers, no action is required, and the network remains unaffected. Thank you to the team for their foresight and continued hard work. We are continuing to think ahead to keep our network secure now and into the future.

Learn more about Oasis security architecture here.