Evervault Encryption

Evervault Encryption is the encryption scheme used across all of Evervault's Primitives. All key management and cryptographic operations take place within the Evervault Encryption Engine (E3) which runs exclusively in an AWS Nitro Enclave.

By default, any data that you encrypt using Relay, UI Components or our SDKs can all be decrypted and used by all of our other Primitives. For example, you could collect credit card data from your customers using Evervault's Inputs UI Component and then perform credit card verification using Functions — without any additional configuration.

Evervault takes on the responsibility for managing your encryption keys so you don't need to worry about storing them safely. We also manage key rotation and provisioning on your behalf with no additional configuration.

If your infrastructure is compromised, simply rotate your API token in the Evervault Dashboard and we'll take care of the rest. Your API token doesn't contain any sensitive key material and is only used to authenticate with the Evervault Encryption Engine.

Evervault Encryption Engine (E3)

At the core of Evervault is the Evervault Encryption Engine (E3). All cryptographic operations for our hosted Primitives (Functions, Enclaves, Relay and UI Components) take place in E3.

E3 is built on AWS Nitro Enclaves. Nitro Enclaves are Secure Enclaves backed by isolated, hardened, and highly constrained virtual machines.

Using enclaves means that Evervault cannot access your data. Enclaves have no persistent storage, no interactive access, and no external networking. Root users and admin users on the parent EC2 instance cannot access or SSH into the enclave. The only way to communicate with the enclave is through the secure local channel from the parent EC2 instance attached to the enclave.

Enclaves have attestation for verifying that only authorized code is running in the enclave, and to verify the enclave’s identity. Key material is only passed to E3 if it passes all attestation checks. Similarly, all other Primitives will only interact with a fully-attested deployment of E3.

Evervault Encryption Scheme

Encryption Keys

The current Evervault Encryption Scheme (EES) comprises two sets of keys: the App Master Key, and a public/private asymmetric key pair.

App Master Key (AMK)

When an Evervault App is created, an App Master Key (AMK) is provisioned for that App.

Each AMK is generated for use with AES-256 symmetric encryption (with a 256-bit key length).

We use Shamir's Secret Sharing to split the AMK into three shares with a quorum of three. Of these three shares, two are stored in separate databases on Evervault's infrastructure — encrypted using a key that is only accessible by E3’s AWS Nitro Enclave. Once these shares have been generated, the original AMK is discarded.

Your API token is generated by taking the third share and offsetting it by XORing each byte of the share with randomly generated “offset bytes”, which are stored by Evervault.

Evervault stores the API token encrypted in its database using AWS KMS to allow you to retrieve it using the Dashboard. Each access request is tracked and there is a full audit log of each API token decrypt operation.

App Asymmetric Keypair

Two Elliptic Curve Diffie-Hellman keypairs are generated for each App: one on the secp256r1 curve (NIST P-256) and one on the secp256k1 curve (Koblitz). Two keys are used in order to allow for complete interopability with different encryption libraries, many of which will only support a subset of all standardized elliptic curves.

The private key is encrypted with the App's AMK (using AES-256), and the plaintext private key is discarded.

The AMK-encrypted private key is stored in the Evervault database. Evervault never sees the private key in plaintext. The only point where the private key is accessible is within the E3 AWS Nitro Enclave.

The public asymmetric key is stored in the Evervault database and is publicly available for any clients who wish to encrypt data to be processed by your App.

Encryption

Your App's ECDH public key is loaded by the Evervault SDK or by E3, which generates a new, ephemeral ECDH keypair per encryption. The SDK or E3 then derives a 32-byte (256 bit) shared secret using the App ECDH public key and the ephemeral ECDH private key.

The data is then encrypted using AES-256-GCM with a 12-byte initialization vector (IV) and 16-byte auth tag. A string is generated containing the ephemeral ECDH public key, AES-encrypted data and the key IV.

The plaintext AES key and the ephemeral ECDH private key are discarded.

The encrypted data returned by the Evervault SDK or E3 can then stored anywhere on your infrastructure. Evervault does not store the data in any form—neither in plaintext, nor encrypted.

Evervault-encrypted data is encoded using the following structure:

Our data structure is designed so that you don’t need to change your database configuration or models. You can store Evervault-encrypted data in your database as you would the plaintext data.