What’s Holding Your Back From Encrypting By Default? Meet Envolope Encryption and the Cloud

Increasingly we see an encryption tick-box for data storage in the Cloud. S3 buckets, RDS, DynamoDB and EBS are just four storage services…

What’s Holding You Back From Encrypting By Default? Meet Envelope Encryption and the Cloud

Why can’t data in the public cloud be even more secure than an on-premise solution? — Keeping Your Secrets To Yourself

Introduction

Increasingly we see an encryption tick-box for data storage in the Cloud. S3 buckets, RDS, DynamoDB and EBS are just four storage services that can be enabled for encryption. With this, we either use the AWS-generated key or the customer-generated in the KMS (Key Management Store). The KMS stores the keys securely in an HSM (Hardware Security Module). But, what it your regulator says that the keys must never leave your premise?

Well, the KMS provides the solution to this, and which uses envelope encryption. With this, the customer has a root key, and AWS generates a data key. The data then encrypts the data, and then the data key is encrypted by the root key. The encryption key can then only be revealed with the use of the root key. This root key can then only exist on the customer’s site, and protected within a Hardware Security Module (HSM) and which is tamper-proof and stops the key from being extracted (as certified in NIST FIPS 140–2):

Figure 1: Hold-you-own-keys

The root keys are then defined as “customer-managed keys”, and can be created within a customer key store.

Envelope encryption

With envelope encryption, we take our data and then encrypt it with a Data Encryption Key (DEK) — also known as the data key. We then take the DEK and encrypt it with a Customer Master Key (CMK) — also known as the root key. After this, we can store the encrypted DEK alongside the encrypted data. In Figure 2, we see that Alice has the CMK and Wendy has the DEK. Wendy takes Alice’s data, and then encrypts this with her DEK, and either she or Alice can take Alice’s CMK and encrypts the DEK. Both the encrypted data and the encrypted DEK can be stored together (as in an envelope). To decrypt the data, Alice uses her CMK to decrypt the Encrypted DEK to reveal the DEK, and which can then be used to decrypt the data.

Figure 2: Envelope encryption (Alice is the customer, and Wendy is the Cloud provider)

One area where envelope encryption is used is with the AWS Secrets Manager. In Figure 3, we see that Alice has updated the password on the database (1). She then stores the secret password in the AWS Secrets Manager (2). Next, when Bob’s application wants to use the database, it retrieves the password from the Secrets Manager (3), and then applies this to access the database (4).

Figure 3: Updating with AWS Secrets Manager

With AWS Secrets Manager, whenever a new secret is created, the KMS (Key Management Service) creates a new encryption for the CMK to encrypt the data key (DEK). The DEK is then used to encrypt the secret data — as envelope encryption. When the secret is accessed, the KMS key is used to decrypt the data key (DEK), and which then decrypts the secret data. The data key is never stored in an unencrypted form and is always disposed of after it has been used. Another layer of protection that is applied is the mandatory use of a TLS connection for the request for secrets.

XKS Proxy

Within the External Key Store (XKS), we generate and store the root keys. These are stored in an on-premise HSM. When the KMS requires the decryption of the data key. It calls up the XKS proxy, and which translates AWS requests into vendor-specific requests. The root key is then used to decrypt the encrypted data key and then passed back for encryption/decryption of the data. An example of a customer store is to use SoftHSM [here]:

This implements the PKCS#11 (a standard for API calls for access to cryptographic tokens) interface for the storage of and access to keys. AWS is also releasing a proxy for this in Rust. Authentication can be built into the proxy to include trusted calls from the KMS API and with KMS key ARN (Amazon Resource Number). In the end, the XKS proxy can also be a kill switch, and which will enable and disable keys to be used. AWS will only keep the unencrypted data key in use for just a few minutes, after which it is deleted from their systems.

Conclusions

Is this the 20th Century or the 21st Century? What’s stopping you from encrypting by default?