AWS KMS Encryption Explained: Master Keys, Data Keys, and How the Flow Works

The AWS KMS System Has Three Pieces of Hardware

To protect your terabytes of data quickly and securely, AWS uses a key hierarchy with three components, each serving a distinct, crucial role:

The Encryption Flow: Locking the Data

Imagine you have a huge, sensitive document (your data) that needs to be sealed and stored.

Step 1: Request the Key Material

Your application sends a request to AWS KMS: "Hey Vault, please give me a new key to encrypt this document using Master Key X."

• The Vault (KMS) uses its Vault Key (KMS_K) to perform two functions:
• It generates a unique, fast, temporary Plaintext Data Key (DK_P).
• It encrypts that temporary key, creating the Encrypted Data Key (DK_E).

Step 2: Local Encryption and Immediate Cleanup

The Vault returns both the plaintext key and the encrypted key to your application over a secure TLS channel.

• Your application uses the Plaintext Data Key (DK_P) to encrypt the entire document locally. This is fast and efficient.
• Immediately after use, DK_P is wiped from memory. It is a disposable, one-time-use key.

Step 3: Storing the Secure Blob

You now have the encrypted document, but you still need a way to decrypt it later.

• You store the Encrypted Data Key (DK_E) right next to the encrypted data (for example, in S3 object metadata or a database column).

Together, the encrypted data and DK_E form a self-contained encrypted blob.

The Decryption Flow: Unlocking the Data

A week later, you need to read the document.

1. Retrieve the blob: Your application fetches both the encrypted document and DK_E.
2. Request to unlock: Your application sends only DK_E to AWS KMS in a Decrypt request.
3. The Vault unlocks: AWS KMS checks IAM permissions. If you are authorized, KMS uses the Master Key (KMS_K) to decrypt DK_E, recovering the original DK_P.
4. Local decryption: Your application uses DK_P to decrypt the document, then immediately destroys DK_P.

The Ultimate KMS Question: Why Two Keys?

This architecture exists to solve two critical requirements at the same time:

1. The Need for Speed (Why DK_P Exists)

• Problem: The KMS Master Key lives inside slow, heavily audited hardware (an HSM). Encrypting a 10 GB file directly with it would be slow, expensive, and rate-limited.
• Solution: DK_P is a fast, lightweight AES-256 key that can encrypt gigabytes of data locally without additional KMS calls.

2. The Need for Persistence and Security (Why DK_E Exists)

• Problem: DK_P must be destroyed after use for security. But you still need a way to recover it later.
• Solution: DK_E is the encrypted, persistent version of the fast key. Even if an attacker steals both the encrypted data and DK_E, they cannot decrypt anything without access to the Master Key in KMS.

The KMS Master Key is the security policy; the Data Key (DK_P) is the fast, disposable tool that enforces it.