How Oasis Protects Privacy Despite TEE Vulnerabilities
Trusted Execution Environments (TEEs) enable efficient confidential smart contract execution on the Oasis Network. By leveraging TEEs, confidential ParaTimes — like Sapphire and Cipher — provide enormous flexibility to developers. Developers can build smart contracts that are fully confidential, fully public, or anywhere in between on that spectrum.
TEEs reduce developer and user friction; a crucial motivating factor for Oasis. The EVM-compatible confidential Sapphire ParaTime functions similar to any other EVM, providing a familiar runtime environment with built-in confidentiality through TEEs.
Questions around TEEs and their security have been raised in light of the recently documented Æpic exploit and disclosure about how it could be used to attack other blockchain networks. This article will explain the vulnerability, how we mitigate the risks that it poses, and why we believe TEEs still offer the best tradeoff in terms of flexibility, usability, and confidentiality. TLDR: 1) There is no risk of loss of funds on the Oasis Network due to TEE vulnerabilities; 2) the Oasis Network is secure against the aforementioned Æpic vulnerability and attacks; 3) Oasis has a unique, state-of-the-art defense-in-depth design that minimizes privacy risks from TEE vulnerabilities; and 4) we continue to develop our cutting-edge security and privacy technologies to push the industry forward.
The Oasis Network minimizes risks from TEE vulnerabilities
Security researchers have identified numerous vulnerabilities in TEE platforms in the past, and TEE vendors have developed solutions to patch these vulnerabilities, released as CPU microcode updates. A recent exploit affecting Intel SGX, known as the Æpic attack, exposed a data leak vulnerability in the CPU microcode, which could exfiltrate enclave application data due to unsanitized cache lines. Vulnerabilities like this one could potentially lead to private data protected by confidential smart contracts being exposed.
So how does this vulnerability affect the Oasis Network? First, it is important to note that the Oasis Network does not rely on TEEs for ensuring data integrity, including token balances–so TEE vulnerabilities will never threaten data integrity or cause loss of funds on the Oasis Network. Intel has implemented a solution for the Æpic attack, with microcode updates released a few months ago, and Oasis is working with our node operators to help them update their systems. Most importantly, Oasis’ unique defense-in-depth approach to protecting confidentiality ensures that there was never a significant risk of data exposure due to Æpic.
Because issues like Æpic can occur, it is important that systems relying on TEEs to protect data confidentiality be designed to be resilient to TEE vulnerabilities. The Oasis Network employs a number of mitigations to prevent data leaks in the event of such vulnerabilities. First, only SGX-enabled nodes that are elected to the committees responsible for executing Oasis confidential ParaTimes (i.e., Sapphire and Cipher) are allowed to access encryption keys. Furthermore, we restrict the membership of these committees to trusted operator partners as an additional measure to prevent unknown bad actors from trying to exploit vulnerabilities like Æpic. Finally, nodes on the network are also required to refresh their attestations regularly, so any node that does not apply required security updates will become ineligible for registration and/or election to confidential ParaTime committees and thus will no longer be able to access encryption keys. As a result, when a new vulnerability arises, the risk of data exposure in Oasis ParaTimes is minimized, even before all vulnerable systems can be fixed via microcode patches.
Now that we have discussed how Oasis mitigates the risk of data leaks due to TEE vulnerabilities let’s dive into how usability compares to other privacy-preserving techniques.
Why TEEs still offer the best tradeoff
From the architecture of the network to the choice of which privacy-preserving computation techniques to use, ease of development and low user friction are paramount. Other privacy-preserving computation techniques, such as fully homomorphic encryption (FHE), secure multi-party computation (MPC), and zero-knowledge proofs (ZKP), have disadvantages in cost, flexibility, and usability.
The main limitation of homomorphic encryption is high computational overhead and cost of the processing.
MPC is a potent privacy-preserving computation technique. However, it can be computationally expensive and requires much communication between the parties, adding significant latencies during computation. These drawbacks limit the ability of MPC to be used for blockchain networks.
Zero-knowledge protocols are not well suited to protect privacy for general smart contract execution, especially when aggregating multiple data sources. It should also be noted that ZKPs only work for privacy where the prover knows the state that is required to generate the proof, but which the verifier does not need to know. This does not work for cases where some state must also be kept confidential from the prover.
By comparison, Oasis’ TEE-based approach in the Sapphire ParaTime has extremely low computation costs. The network is much more flexible, allowing developers to customize smart contracts and add privacy in the ways that best suit developers’ and users’ needs. It can match the performance of any other EVM network for generalized smart contract execution, even when applications need to aggregate data from many parties.
Crucially, it is very easy to start building on Sapphire. Developers can port over their applications in minutes, in a language they know, while only having to modify a few lines of code to get started. Users can interact with confidential dApps seamlessly and see that the Sapphire approach is cheaper, more flexible, and adds far less friction.
When considering these factors and how Oasis minimizes the risk of data exposure due to TEE vulnerabilities, it is clear that TEEs are currently the most practical approach for bringing wide-scale privacy to the Web3 space.
The success of the recent Sapphire “Keep it Confidential” Hackathon shows that this approach is resonating with developers. Participants attested to how easy it is to build on Sapphire. We saw an impressive set of applications built during the short one-month period that are novel to Web3. Without TEEs and Sapphire’s EVM compatibility, dApps of this nature could not be built.
We are looking for more projects to build dApps on Sapphire or use Sapphire as the privacy layer. We would also like to offer grants to qualified teams. If interested, please apply here.