Security
Part 2 of 6 · Secrets & KMSEnvelope Encryption — DEK, KEK & CMK Hierarchy
Envelope encryption separates bulk data crypto (fast local AES with a DEK) from key protection (a KMS-held CMK or KEK wraps the DEK). This lesson is the DEK, KEK, and CMK hierarchy, the encrypt and decrypt paths, AAD, key policies, and rotation by re-wrap versus re-encrypt.
- 1Gist
- 2Maps
- 3Q&A
- 4Sandbox
Voice readout needs Web Speech Synthesis in this browser.
Why the hierarchy beats one big key
Prefer
Local AES with a wrapped DEK
The app encrypts bytes with a data key. KMS only wraps and unwraps that key. A stolen object store holds ciphertext and a wrapped DEK.
- Bulk AES stays off the KMS request quota.
- Per-object or per-tenant DEKs limit blast radius.
- CMK material stays in the HSM.
- Re-wrap can rotate CMK material without rewriting every payload.
Alternative
Every encrypt call hits the CMK
Simple to draw. Latency, quotas, and a single decrypt grant cover the whole dataset.
- Network RTT on every object.
- KMS throttling becomes a data-plane outage.
- Compromise of the decrypt grant is the whole corpus.
- Rotation means rereading plaintext or stopping the world.
Overview
Envelope encryption separates bulk data crypto from key protection. Fast local AES uses a data-encryption key. The KMS-held customer master key, or an intermediate key-encryption key, wraps that DEK. Interviews want the hierarchy, the round trip, and what an attacker has after they copy the bucket.
Interview punchline: compromise of storage shows ciphertext plus wrapped DEKs. Those bytes are useless without KMS decrypt permission on the CMK.
You should be able to:
- Draw plaintext DEK lifetime: born in KMS, used in memory, discarded, never logged.
- Say what KMS does not see on a client-side envelope.
- Pick re-wrap or re-encrypt from the incident, not from the calendar.
Why hierarchy beats one big key
| Model | How it works | Pros | Cons |
|---|---|---|---|
| Single CMK encrypts all data | Every encrypt calls KMS | Simple mental model | Latency, quotas, huge blast radius if the decrypt grant leaks |
| Envelope (DEK plus wrap) | Local AES; KMS only wraps the DEK | Fast; scoped DEKs; CMK stays in the HSM | DEK lifecycle and AAD have to be careful |
| Client-side plus CMEK | App owns DEKs; cloud uses the customer CMK | Strong tenancy isolation | App complexity; you must back up wrapped DEKs |
Key hierarchy flow
Sequence
- 1
App → KMS CMK
GenerateDataKey
- 2
KMS CMK → App
plaintext DEK and wrapped DEK
- 3
App → Local AES
Encrypt payload with DEK
- 4
App → App
Zero plaintext DEK in memory
- 5
App → Object Store
Save ciphertext, wrapped DEK, and AAD
- 6
App
Decrypt path
- 7
App → Object Store
Load envelope
- 8
App → KMS CMK
Decrypt wrapped DEK with CMK
- 9
KMS CMK → App
plaintext DEK
- 10
App → Local AES
Decrypt ciphertext with DEK
Lesson map
Envelope Encryption — DEK, KEK & CMK Hierarchy
Envelope encryption separates bulk data crypto (fast local AES with a DEK) from key protection (a KMS-held CMK or KEK wraps the DEK). This lesson is the DEK, KEK, and CMK hierarchy, the encrypt and decrypt paths, AAD, key policies, and rotation by re-wrap versus re-encrypt.
Architecture. Architecture
Select a node to see why it exists, or an edge to see the protocol, direction, effect, and consequence.
Mermaid export
flowchart TB app["App"] local["Local AES"] kms["KMS CMK"] store["Object Store"] app -->|GenerateDataKey| kms kms -->|plaintext DEK| app app -->|Encrypt payload| local app -->|Save ciphertext,| store app -->|Load envelope| store app -->|Decrypt wrapped| kms
CMK, KEK, and DEK
- CMK (customer master key). Root symmetric or asymmetric key in the KMS or HSM. Key policy plus IAM gate every use. Who may call Decrypt is an authorization decision; the model lives on the Authorization hub. How the caller authenticated lives on the OAuth hub.
- KEK (key-encryption key). Often the CMK itself. In multi-tenant hierarchies it is an intermediate key that wraps DEKs.
- DEK (data-encryption key). Ephemeral, per-object, or per-tenant key that actually encrypts bytes.
AAD and context binding
Pass additional authenticated data into AES-GCM: tenant id, object id, purpose. A ciphertext swapped onto another tenant fails authentication. KMS encryption context does the same job for wrap and unwrap. Context is not a secret. It is a binding. Log it. Do not log the DEK or the plaintext.
Rotation strategies
| Strategy | What rotates | Cost | When |
|---|---|---|---|
| CMK version rotation | New CMK material; re-wrap DEKs | Medium (metadata) | Annual or compliance |
| DEK re-encrypt | New DEK; rewrite ciphertext | High (data rewrite) | After suspected DEK exposure |
| Per-tenant CMK | Isolate tenants | Ops plus cost | Regulated multi-tenant SaaS |
Enable the new CMK version, re-wrap DEKs, and keep the old version for decrypt until the backlog is done. Then disable the old version. Credential overlap for passwords is the rotation lesson. The idea is the same: two versions are valid until the lag is gone. The bytes you rewrite are wrapped keys, not necessarily every row.
Runnable envelope
The sandbox uses AES-GCM when the cryptography package is present. Otherwise it uses a labeled toy wrap with the same fields: nonce, ciphertext, wrapped DEK, and tenant AAD. Either way the plaintext DEK is not stored, and a swapped tenant does not return the original plaintext. Production wrap happens inside the HSM, and zeroing a Python bytes object is best-effort.
Press Run. Snippets must be self-contained — no network, files, or native modules.
Decrypt path as a checklist
No crypto library required. The interview answer is the order of operations.
Press Run. Snippets must be self-contained — no network, files, or native modules.
Interview Q&A
Walk through encrypt with envelope encryption.
Answer
Call GenerateDataKey. Encrypt the data with the plaintext DEK. Discard that plaintext DEK. Persist ciphertext, the wrapped DEK, and the encryption context. The object store never holds the DEK in the clear.
What does KMS never see?
Answer
On a client-side envelope, KMS does not see the bulk plaintext. It sees wrap and unwrap of DEKs, and it authenticates callers with IAM and key policy. If you send the payload to KMS, you have left the envelope pattern.
What are encryption context and AAD for?
Answer
They cryptographically bind ciphertext to metadata. A cross-tenant or cross-purpose swap fails authentication. Context is public binding data, not a second password.
How do you rotate a CMK?
Answer
Enable a new CMK version, re-wrap DEKs with the new material, and keep the old version for decrypt until the backlog finishes. Then disable the old version. That is metadata work, not a full data rewrite.
CMEK versus service-managed encryption such as SSE-S3?
Answer
CMEK means the customer controls CMK policy and can revoke the cloud's ability to decrypt. Service-managed keys are simpler and give the customer less control. Pick CMEK when a tenant or a regulator must be able to cut decrypt off.
Why per-object DEKs?
Answer
They limit blast radius, allow selective re-encrypt, and avoid pushing terabytes through KMS APIs. One DEK for an entire bucket turns every object into the same incident.
What if the wrapped DEK is deleted?
Answer
The data is cryptographically shredded when no backup of that wrapped DEK exists. Teams use this on purpose for tenant offboarding. Backups of wrapped keys are backups of the data.
Where does the plaintext DEK live after encrypt?
Answer
Only in memory for the duration of the local AES call. The stored record has the wrapped DEK. Decrypt asks KMS to unwrap again. Logging the GenerateDataKey response defeats the hierarchy.
Pitfalls
An attacker copies the object store, not the KMS account. List the bytes they have, the API they still need, and the binding that stops them from moving tenant A's ciphertext onto tenant B's key.