Understanding Envelope Encryption with AWS KMS

AWS Key Management Service (KMS) is a managed service that makes it easy to create and control cryptographic keys used to secure your data. KMS integrates with many AWS services and provides a central point of control for your encryption keys. It allows you to create, rotate, disable, and delete cryptographic keys, as well as define usage policies and audit their use.

Symmetric vs Asymmetric encryption

KMS supports both symmetric and asymmetric encryption.

Symmetric encryption uses a single key for both encryption and decryption. It's faster and uses less computational resources, making it ideal for encrypting large amounts of data or for scenarios requiring frequent encryption/decryption operations.

Asymmetric encryption uses a pair of mathematically related keys: a public key for encryption and a private key for decryption. It's commonly used for secure key exchange, digital signatures, and scenarios where the party encrypting the data is different from the one decrypting it.

Generating a Data Key with AWS KMS

Building on our understanding of symmetric encryption, AWS KMS uses this approach to generate what we call data keys - temporary symmetric keys used for client-side encryption. These data keys are particularly useful because they combine the efficiency of symmetric encryption with the centralised security management of KMS.

Key characteristics of KMS data keys:

• Always symmetric (AES-256 in this implementation)
• Generated on-demand for individual encryption operations
• Exist in two states: plaintext and encrypted (ciphertext)
• Designed for single-use encryption workflows

To generate a data key using the AWS KMS API:

• Ensure you have the necessary permissions to call the KMS GenerateDataKey API.
• Identify (or create) the KMS Customer Managed Key (CMK) you want to use for generating the data key.
• Use the AWS CLI to call the GenerateDataKey API:

This command returns two versions of the data key:

• Plaintext: The unencrypted data key
• CiphertextBlob: The encrypted data key

Using the plain-text Data Key for encryption

Here's a simple example of using the plaintext data key to encrypt data using OpenSSL on the command line:

Replace "YOUR_PLAINTEXT_DATA_KEY" with the actual plaintext key you received from KMS when calling aws kms generate-data-key.

Now you just need to store encrypted_data.txt , iv.txt and CiphertextBlob alongside each other in storage such as S3, DynamoDB etc.

Make sure to discard the plain text key when finished. Never store the unencrypted data key!

Using the encrypted Data Key for decryption

To decrypt data, we use the encrypted data key to get the plain text key from KMS before using openssl to perform the decryption. This example assumes you have the CiphertextBlob value stored in a file named encrypted_key.bin:

By following these steps, you can securely generate, use, and manage data keys for envelope encryption using AWS KMS. Remember to always handle plaintext keys with care and discard them immediately after use.

A key benefit of this approach is that your unencrypted data never leaves your local environment. Only the data key, not your actual data, is sent to KMS for encryption. This significantly reduces the risk of data exposure during transmission and processing.

Benefits

Envelope encryption offers several advantages:

• Performance: It allows for efficient encryption of large datasets, as only the small data key needs to be encrypted by KMS, not the entire dataset.
• Security: It limits the exposure of the CMK, as it's only used to encrypt the data key, not the data itself.
• Key management: You can encrypt multiple datasets with different data keys, all protected by the same CMK, simplifying key management.
• Offline decryption: Once you have the decrypted data key, you can decrypt the data offline without further calls to KMS.

Envelope encryption ensures that your unencrypted data and the plaintext data key never leave your local environment. Only the encrypted data key is sent to KMS for decryption, enhancing security. The CMK, or "root" key, remains within KMS, protected by AWS's hardware security modules. It's used solely to encrypt and decrypt the data keys, never directly handling your data.

Envelope Encryption vs AWS Secrets Manager

While both AWS KMS with envelope encryption and AWS Secrets Manager provide secure ways to handle sensitive data, they serve different purposes and have distinct advantages:

Cost Considerations

Using envelope encryption with KMS and storing encrypted data in a service like DynamoDB can be more cost-effective for large amounts of data or frequently accessed secrets. Secrets Manager charges per secret stored and per 10,000 API calls, which can add up for high-volume applications. In contrast, KMS charges primarily for API calls, and storage costs in DynamoDB or similar services can be lower for larger datasets.

Use Case Differences

• Secrets Manager is designed specifically for storing and managing secrets like database credentials, API keys, and other configuration data. It provides a simple interface for storing, retrieving, and rotating secrets.
• Envelope encryption with KMS is more flexible and can be used for encrypting any type of data, from small secrets to large files or database fields.

Key Rotation

• Secrets Manager offers automatic key rotation for supported secret types (like RDS credentials) and can be configured to rotate secrets on a schedule.
• With KMS, you can rotate the Customer Managed Key (CMK) used in envelope encryption, but you're responsible for re-encrypting the data keys and potentially the data itself.

Integration

• Secrets Manager integrates easily with many AWS services and provides SDK support for secret retrieval in applications.
• KMS requires more hands-on implementation but offers greater flexibility in how and where you store your encrypted data.

Access Control

• Both services provide fine-grained access control through IAM policies.
• Secrets Manager adds an extra layer of abstraction, allowing you to control access to specific secrets.
• With KMS, you control access to the keys, and you implement any additional access control for the encrypted data.

Scalability

• Envelope encryption with KMS can be more scalable for large amounts of data or high-throughput scenarios, as you're only using KMS to encrypt the data key, not the entire data set.
• Secrets Manager is optimised for storing and retrieving smaller pieces of configuration data and secrets.

In summary, if you're dealing primarily with application secrets and configuration, and value features like automatic rotation, Secrets Manager is likely the better choice. However, for encrypting large amounts of arbitrary data, especially if you need fine-grained control over the encryption process or are concerned about per-secret costs, envelope encryption with KMS could be more suitable and cost-effective.