Why We Built Cages: Our Take on Secure Enclaves

Update: As of January 2024, Evervault Cages has been renamed Enclaves. Learn more about Evervault Enclaves.

Last month we launched Cages, a service for easily deploying and scaling AWS Nitro Enclaves. Here's why.

*Note: in this post we'll use the terms Enclave and Trusted Execution Environment (TEE) interchangeably.

A brief history of secure enclaves

A Secure Enclave, also known as a Trusted Execution Environment (TEE), is a highly constrained compute environment that allows for cryptographic verification (attestation) of the code being executed.

The most widely known implementation of a secure enclave came from the 2013 release of the Apple iPhone 5. Featuring a dedicated chip for processing the fingerprints of a user with Touch ID, millions of people were exposed to a leap in application security. Since then, various applications now use enclaves to process biometric data, financial transactions, and provide trustless account recovery, and signature verification. Hamstrung by hardware limits and scarce availability in the cloud, TEEs have only been exposed to a small fraction of application features they should be used for. At Evervault, we understand the potential TEEs have to protect data – entire classes of threat vectors such as data exfiltration, malware, and internal bad actors become far harder to exploit.

Some important context on our development journey:

Since the inception of Evervault, the mission of the company necessitated the use of Enclaves. We encountered the constraints of Intel’s SGX platform early on with our node-secureworker project. Trying to cram runtimes into tiny isolated enclaves that degraded performance wasn’t very popular with developers. We needed a platform that would provide isolated hardware and remote attestation without impacting application performance. AWS Nitro Enclaves provided us with that platform.

Using Enclaves at Evervault

We first used Nitro Enclaves when we built the Evervault Encryption Engine (E3). We decided to deploy E3 in an Enclave so that we could have the extra security guarantees of TEEs, like:

1. Secure I/O: They have no network access by default, and typically only have a single I/O channel for communication with the host instance.
2. Secure Memory: Through hardware segregation or virtualization, Enclave memory must be isolated from the host system.
3. Attestation: The ability to prove exactly what container is running in the Enclave and that it hasn’t been tampered with.
4. Key access: Enclaves are provisioned with a private key that can be used for cryptographic operations.

Drawbacks of Enclaves

AWS Enclaves are great for all of the above reasons. However, they're a nascent technology with some important technical challenges that need to be navigated:

• Reliably getting a high volume of network requests into and out of the Enclave over its singular VSock channel.
• Obtaining observability on the performance and health of the application running in the Enclave.
• Creating a pipeline for deploying the application in an Enclave.

We estimate that these challenges added roughly 12 weeks of engineering work to our E3 build.

Evervault's mission is to encrypt the web. We deeply believe Enclaves are the safest place to process encrypted data, and this technology has the potential to foundationally improve the security of the internet. So why is it hidden behind all this unnecessary overhead?

Making the best security more accessible

We decided to build a product (now called Cages) to abstract away this pain and make it easy for developers to deploy any application they want into an Enclave. The developer experience should make Enclaves more accessible while maintaining the existing rigorous security standards.

To achieve this, our users would need the following features on top of Secure Enclaves.

• They should be able to easily deploy any application as an Enclave, and be able to make requests to it over the internet.

• Any time they make a request to their application, they should be able to attest that the Enclave they are connecting to is running the exact container they built on their machine. This attestation should happen before any sensitive data is sent.

• We should be able to prove that Evervault does not need to be a trusted party in this attestation flow and that Evervault is not able to view or tamper with the data that users are sending to the Enclave. Even if Evervault were malicious, it should be impossible for us to spoof the user.

With our newest product release, Cages, we aim to achieve this. Over the next couple of weeks, we will release a series of posts that details ‘How We Built Cages’ step-by-step, and we hope you’ll follow along.

If you’re interested in trying out Cages, sign up for our beta here.