Skip to main content

Encryption

An important part of data control is knowing that your policies are not being circumvented. Often this is seen as an "operations problem" — that one needs to have the right network architecture and infrastructure IAM settings to prevent direct access to sensitive data. We think such an approach is slow, hard to get right, and nearly impossible to validate, as evidenced by the myriad of data breaches that occur every month. One of Antimatter's core philosophies is that encryption, if done correctly, is a much simpler and more complete solution to this problem.

Encryption allows you to take a complex and sometimes intractable data access problem, and turn it into a key management problem: if someone gains access to ciphertext but does not have the key, then they have still not gained access to the data.

Historically, key management has itself been a complex problem. That is why Antimatter has focused a lot of our efforts on providing a simple, yet effective architecture for both encryption and key management.

Data in Antimatter capsules is encrypted with a three-tier key scheme: Root Encryption Keys, Key Encryption Keys and Data Encryption Keys. A capsule is encrypted with a Data Encryption key. This data encryption key (dek) is in turn encrypted with the domains active key encryption key (kek), yielding enc_dek. This encrypted data encryption key is stored with the capsule (no data encryption keys are ever stored in any form in Antimatter).

The key encryption key is in turn encrypted with the domain's root encryption key before being stored. A key encryption key is only ever kept decrypted in memory for a bounded amount of time (usually 5 minutes, but it's configurable) before it is flushed, and the encrypted form must be re-loaded and re-decrypted with the root encryption key.

The root encryption key (REK) is usually held externally. It can be held by the data processor (e.g. a SaaS vendor who is using Antimatter to manage customer data) or it can be held by the data owner (e.g. the end customer, in a Hold Your Own Key setup). Antimatter makes it very easy to configure where the REK is held, and to change it (see the Root Encryption Key section).

The advantages of this architecture are that:

  1. Capsules are encrypted with their own Data Encryption Keys (unless key reuse is enabled). This ensures that the audit trail of which keys were accessed corresponds 1:1 with which data in the capsules was accessed.
  2. There is an efficient dependency between the Data Encryption Keys and the Root Encryption Keys, via a small number of Key Encryption Keys. If a Root Encryption Key were to be revoked, the Key Encryption Keys would become unavailable after a small period of time.
  3. Key operations remain high performance, even though we are tying into an external key management service.

Three trust domains​

The above architecture also reduces the attack surface of encrypted data by increasing the number of things that need to be breached for an attack to succeed:

  • If the ciphertext were to be stolen from the data processor's storage, an attacker would still need to either obtain valid Antimatter credentials for that domain, or to breach Antimatter's key vault and separately obtain the Root Encryption Key before to be able to decrypt that data.
  • If all the key material held by Antimatter were to be stolen, they'd still need to steal the ciphertext and gain access to the Root Encryption Key in order to be able to decrypt the data.
  • Similarly, if the Root Encryption Key and the Ciphertext were both stolen, they'd still need to get the encrypted Key Encryption Keys from Antimatter in order to be able to decrypt the data.

So in order for a data breach to occur, one would need to compromise at least two, and sometimes three different parties.

Root Encryption Keys​

The goal of the DEKs and KEKs are to effectively tie the decryptability of a capsule to the availability of the Root Encryption Key. Thus, how the Root Encryption Key is held determines the availability and security of the data in a domain.

For a newly created domain, the Root Encryption Key will be set to one held by Antimatter using a cloud KMS (which KMS will depend on which cell the domain is assigned to). You can change the active root encryption key to a key that you hold in your own infrastructure. We support Azure, AWS and GCP's key management products, and intend to support various commercial on-premise key management solutions as well.