Table of Contents
1. Background
2. What is Evervault
2.1. Encryption service
2.2. Runtime provisioning
a. Evervault Functions
b. Evervault Cages
3. Deep dive
3.3. Less infrastructure overhead
3.4. TLS Attestation
3.5. Unknown sidecar
3.6. Insufficient access control
4. My thought
5. Final thought
Background
If you haven't read my previous post, please read AWS Nitro Enclaves Ecosystem (1) - Chain of trust on how I see services built on top of AWS Nitro Enclaves and the importance of Attestation Document.
This time, I'm going to talk about my thought on Evervault.
What is Evervault
Evervault provides transparent encryption using relay webhooks.
Encryption service
The idea is that before sensitive data goes into the system, you can route the traffic through Evervault Inbound Relay to encrypt it so that the system can only get the encrypted data.
To use the encrypted data, Evervault provides Outbound Relay to decrypt the data before sending it to the external components.
Using it, developers can build applications that handle sensitive data without worrying about encryption or changing the code to protect it.
Evervault states that the encryption is performed by Evervault Encryption Engine (E3), which is running on Nitro Enclaves. However, there is no way for us to tell whether it's true. There is no independent audit available as well.
Runtime provisioning
Evervault Functions
Besides simply encrypting data, Evervault also provides the environment for developers to run simple functions on sensitive data.
The current offering is Evervault Functions, in which you can invoke your custom Python or Node.js application with the encrypted data. Your application will be given decrypted data as parameters so you can perform your business logic on it.
The example Evervault provides is to validate encrypted phone number
Evervault Cages
Evervault Functions is not running on Nitro Enclaves, so I will not discuss it in this blog post. But Evervault has a beta offering called Evervault Cages which provides a similar feature on Nitro Enclaves. In this blog post, I will focus on it.
Deep dive
I tried Evervault Cages by following their documentation, as well as the help from the Evervault team to understand how it works.
This session is about the key points which are worth considering.
Less infrastructure overhead
Using Cages CLI, you can quickly build your docker application and deploy it into Nitro Enclave. You don't need to provision EC2 instances or configure Nitro Enclaves. Evervault provides the infrastructure in their AWS account for you during deployment.
You also don't need to handle external traffic, as Evervault will handle it for you. The Cage application endpoint will be forwarded to the exposed port of your enclave application. Evervault can also forward egress traffic from the enclave to the Internet.
TLS Attestation
Another feature Evervault Cages provides is TLS Attestation.
When TLS termination is enabled in your Cage application, the attestation document of the Nitro Enclave will be embedded inside the Cage endpoint TLS certificate.
According to the documentation, you can only use Evervault SDK or CLI to validate the embedded Attestation document. The tools use an undocumented API to retrieve the attestation. We can use the same API to validate the attestation document ourselves.
When connecting to the Cage application endpoint <cage_name>.<cage_id>.cages.evervault.com (or <nonce>.attest.<cage_name>.<cage_id>.cages.evervault.com if you want to use nonce on the attestation), the Evervault-signed TLS cert will contain a Nitro Enclave attestation document in the Subject Alternative Name (SAN) section, in hex code format.
Besides using TLS Attestation, Cage environment also provides an internal API http://127.0.0.1:9999/attestation-doc for developers to retrieve attestation document within the enclave.
These two features help application developers use attestation documents to validate enclave identity without writing their code to retrieve attestation documents.
Unknown sidecar
To achieve features like egress proxy, TLS Attestation, etc. Evervault Cages installs a proxy sidecar, which they call it Data Plane.
When we run the following command
ev-cage build --write --output .
ev-cage will modify our original Dockerfile, adding two files (One is the runtime dependency, the other one is the sidecar) into it.
As of the time of writing, there is still no source code of the Data Plane sidecar publicly available. So when using Evervault Cages, we need to keep in mind that an unknown binary is running along with your application in the enclave.
There is a risk of Evervault doing bad things on the sidecar, or there are vulnerabilities on it.
Insufficient access control
API key is the only authentication method Evervault provides for programmatic access.
In a simple platform, this is not an issue. But if I use Nitro Enclaves (or Evervault Cages in this case), I would expect additional data protection.
The issues I can see are:
-
Lack of permission separation
Each Evervault app only has one API key, which can be used across different services (i.e. Relay, Functions, Cages).
An API key used by Cages can also be used by Functions, so we cannot guarantee an encrypted data can only be decrypted by Cage.
-
Lack of attestation document support
The decryption API only takes the API key as the sole authentication method. There is no control similar to AWS KMS key policy, where we can specify "only this enclave image can decrypt my secret"
Image if I have a system which handles both phone no. and credit card no. I want to validate phone no. on Evervault Functions because it's not very sensitive.
But I want to validate the credit card no. on Cages because it's more sensitive than phone no.
In this case, I have no way to protect credit card no. because the phone no. validation developers can decrypt the credit card no. using their API key (because they are the same).
Even though API keys are separated, the credit card no. validation developers can also decrypt the credit card no. because they can write a rogue app (e.g. reverse shell) and deploy it to Cages, then use the decrypt API. Since there is no attestation authentication on the API, we cannot specify which enclave image can decrypt the secret.
My thought
The idea of Evervault is good, making data protection as easy as possible. Abstracting protecting data-in-use away from developers using Functions and Cages is a boost on adoption.
However, the current state of Evervault Cages is still a long way to go. I would say Cages is as good as the current Functions offering in terms of security and privacy, but there is no significant extra benefit on top of it.
I would suggest the following if Evervault is targeting first-time users who are not familiar with confidential computing and want a quick start:
-
Provides permission control for the API key so users can have more control of data on different privacy levels.
Evervault response: Evervault is now working on refining the scopes for API Keys, specifically for decoupling Cages from the surrounding products
If Evervault is to target more advanced users who treat sensitive data seriously, they can:
-
Open source the Data Plane sidecar so users can review its security.
Alternatively, if Evervault wants to avoid publishing the source code, they can find a reputable 3rd-party audit. Or open source a lightweight version of the sidecar with fewer functions, so users can choose to minimise their risk by using it.
Evervault response: Evervault is now undergoing a 3rd Party audit for Cages. Open sourcing is also in their roadmap.
-
Provides attestation document authentication so users can specify which enclave image can decrypt specific data.
Evervault response: Evervault is now working on the Cages auth for encryption/decryption to include an attestation step
Final thought
To be fair, Evervault Cages is a new release, and it's not expected to be perfect now. Evervault team has done a great job of democratising Nitro Enclaves’ use. They are open to feedback as well.
I suggest you try it out and have a taste of how confidential computing works.
Top comments (0)