KMS Fundamentals: CMKs, Data Keys, and Envelope Encryption

Part 2 of the AWS Secrets and Key Management series.

Cloud security often conflates "key management" with "encryption." In AWS, these are distinct layers. AWS Key Management Service (KMS) manages the lifecycle of cryptographic keys, but it does not typically perform the heavy lifting of encrypting your actual data payloads. Instead, KMS provides a mechanism to generate short-lived symmetric keys that you use locally. This pattern, known as envelope encryption, solves the scalability and security problems inherent in storing large amounts of encrypted data alongside a single master key.

To understand this architecture, we must first dissect the Customer Master Key (CMK), the role of Data Keys, and the specific API interactions that bind them together.

The CMK Abstraction

A Customer Master Key (CMK) is the logical entity you interact with in the AWS Console or CLI. As defined in the AWS KMS Developer Guide, a CMK is an identifier pointing to a key material object stored within the secure boundary of AWS KMS, rather than a raw cryptographic key that you can export or view. It is critical to understand this distinction because a CMK is protected by key policies, which are attached to every CMK and can be modified only by principals granted permission to do so. These key policies work in conjunction with IAM policies to define who can use the key, ensuring a robust access control model from the ground up.

When you create a CMK, AWS generates a 256-bit symmetric key internally. This key is used for two primary operations: encrypting other keys (Data Keys) and encrypting small amounts of data directly. You never see the plaintext of the CMK. If you request the key material, you cannot retrieve it. This design ensures that even if an attacker compromises your application server, they cannot extract the root key material from KMS because it never leaves the service, maintaining the security of your cryptographic assets.

CMKs also support automatic key rotation. AWS KMS automatically rotates CMKs annually, as described in the Key Rotation documentation. When enabled, KMS generates a new underlying key version every year. The CMK identifier remains constant, but the internal key version ID increments. This allows applications to continue using the same CMK ARN while the actual cryptographic material changes, mitigating the risk of long-term key exposure. Crucially, older versions of the key remain available for decrypting data encrypted under previous rotations, ensuring data accessibility without manual intervention.

The Data Key Problem

Consider a scenario where you need to encrypt a 50 GB database dump. This is a common challenge in cloud storage architectures where data volume scales rapidly. If you attempted to use the CMK directly to encrypt this data, you would face two significant issues:

1. Performance: According to AWS documentation, KMS is a networked service. Sending 50 GB of data over the network to AWS for encryption introduces massive latency and bandwidth costs.
2. Security Scope: If the CMK is compromised, all data encrypted directly with it is exposed. Furthermore, managing key rotation for directly encrypted data is complex because you would need to re-encrypt the entire dataset to use a new key version.

The solution is to use a Data Key (DEK). A Data Key is a symmetric key generated specifically for encrypting a single dataset or file. It is typically 128 or 256 bits long, matching the strength of the CMK. Unlike the CMK, the Data Key is ephemeral. It is generated, used locally, and then discarded (or stored only in its encrypted form).

Envelope Encryption Mechanism

Envelope encryption decouples the key used to protect data (the Data Key) from the key used to protect the key (the CMK). The primary operation for this flow is generateDataKey, which returns both plaintext and ciphertext versions of the key. This is achieved through the GenerateDataKey API operation.

Let’s walk through the mechanism with named actors: Alice (an application server running in EC2) and KMS (the AWS Key Management Service).

1. Generation

Alice needs to encrypt a file named sensitive_report.json. Alice does not generate the encryption key itself. Instead, it calls the KMS API:

aws kms generate-data-key \
    --key-id alias/my-report-key \
    --key-spec AES_256 \
    --output json

The GenerateDataKey API, as detailed in the AWS API Reference, returns two pieces of information:

1. Plaintext Data Key: A symmetric key that Alice can use to encrypt sensitive_report.json locally using AES-GCM or AES-CBC.
2. Ciphertext Data Key: The same key, but encrypted under the specified CMK.

Alice stores the Ciphertext Data Key alongside the encrypted file (e.g., in an S3 bucket metadata field or embedded in the file header). The Plaintext Data Key is kept in memory for the duration of the encryption operation and then securely wiped from memory.

2. Storage

The file is now encrypted locally using the Plaintext Data Key. The resulting artifact is sensitive_report.json.enc. Alice uploads this to S3 along with the Ciphertext Data Key. At this point, the CMK has not been involved in the data transfer. The data is secure, and the key required to unlock it is also present, but it is itself encrypted.

3. Decryption

When Alice needs to read the file, she retrieves sensitive_report.json.enc and the Ciphertext Data Key. She cannot decrypt the file because she does not have the Plaintext Data Key. She must ask KMS to decrypt the Ciphertext Data Key.

Alice calls the Decrypt API:

aws kms decrypt \
    --key-id alias/my-report-key \
    --ciphertext-blob fileb://ciphertext_data_key.bin

KMS verifies that Alice’s IAM role has permission to call kms:Decrypt on the specified CMK. If authorized, KMS uses the underlying CMK to decrypt the Ciphertext Data Key and returns the Plaintext Data Key to Alice.

Alice then uses this Plaintext Data Key to decrypt sensitive_report.json.enc locally. The CMK never left AWS. The data was never sent to AWS. The network traffic between Alice and KMS consists only of small metadata packets, not the bulk data.

Security Context and Access Control

Envelope encryption introduces a dependency: the application must manage the Ciphertext Data Key correctly. If the Ciphertext Data Key is lost, the data is unrecoverable, even if the CMK is intact.

To prevent misuse, KMS supports EncryptionContext. AWS KMS documentation states that EncryptionContext acts as additional authenticated data. This is a set of key-value pairs that act as additional authenticated data. When generating a Data Key, you might specify:

--encryption-context "Bucket=my-bucket,File=sensitive_report.json"

When decrypting, you must provide the exact same context. If the context does not match, KMS returns an error. This prevents "confusion attacks" where an attacker might try to use a valid Ciphertext Data Key from one context to decrypt data in another. It ensures that the key is only usable for its intended purpose.

Conclusion

AWS KMS is not designed to encrypt your data directly. It is designed to manage the keys that encrypt your data. By using envelope encryption, you leverage the security and auditability of KMS for key management while retaining the performance and control of local encryption for data handling. The CMK remains secure within AWS, the Data Key is generated on-demand, and the Ciphertext Data Key travels with your data, creating a scalable and secure encryption model for cloud-native applications.