toc

Encryption Scheme

An overview of the Evervault Encryption Scheme (EES).

Encryption Keys

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

Team Master Key (TMK)

When an Evervault Team is created, a Team Master Key (TMK) is provisioned for that team.

It is generated exclusively for AES-256 symmetric encryption, and is stored in hardware security modules. We cannot see the TMK, but:

  • We store a Key Resource Name (KRN) for the TMK in our database to identify the TMK; and
  • We can perform cryptographic operations with the TMK via API.

Asymmetric Key Pair

A 2048-bit RSA public/private asymmetric key pair is generated per team.

The private key is encrypted with the team's TMK. The plaintext private key is discarded. The encrypted private key is stored in the Evervault database. Evervault never sees the private key in plaintext.

The public asymmetric key is stored in the Evervault database with encryption at rest.

Encrypting data and Cages

Encrypting data as it enters your infrastructure

The public asymmetric key is loaded in the Evervault SDKs, which generate an ephemeral symmetric AES-256 key for each evervault.encrypt() call.

This ephemeral AES-256 key is used to encrypt the data.

The ephemeral AES-256 key is then encrypted using the public asymmetric key using 2048-bit RSA. The plaintext AES key is discarded.

The encrypted data returned by the Evervault SDK is then stored in your database. Evervault does not store the data in any form—neither in plaintext, nor encrypted.

Evervault-encrypted data is returned in a format similar to JWT structure.

Learn more about the format of Evervault-encrypted data →

Cages

Encrypted data is sent to a Cage by calling evervault.run(). It can also be sent directly over HTTPS by sending a request to https://cage.run/cage-name.

A Cage consists of two components: the Evervault Runtime, and the serverless function you deploy to it.

  1. The Evervault Runtime exposes an instance of the Evervault Node.js SDK globally, which means that you don't need to include the SDK in the serverless function.
  2. The Evervault Runtime decrypts the private asymmetric key with the TMK by making an API request to the hardware security modules.
  3. The decrypted private key is automatically cached in the Runtime.
  4. The public key is only cached (after the first evervault.encrypt() call in SDK) if the customer invokes the evervault.encrypt() function within the Cage. It’s cached within the SDK, not the Runtime. If your serverless function does not require it, the public key is not cached.
  5. The decrypted private asymmetric key decrypts the Evervault-encrypted data as the data is passed through the Runtime to your serverless function.
  6. The result of the serverless function is returned and, optionally, encrypted using the Node.js SDK and the public asymmetric key. The encrypted value can be stored in the your database.
  7. The Cage is ejected, and garbage collection (of keys, data and result) occurs, i.e. Cages are stateless.