Cloud Envelope Encryption & Key Rotation

Cloud KMS Setup

Data objects 10

Key State

KEK v1 · 10 unique DEKs · 0 objects exposed

KEK version

Unique DEKs

Blast radius

0 / 10

Rotations

How it works

Cloud KMS services (AWS KMS, GCP Cloud KMS, Azure Key Vault) never encrypt bulk data with the master key directly. Instead they use envelope encryption:

DEK_i        = random 256-bit key, one per object
Ciphertext_i = Encrypt(DEK_i, plaintext_i)
WrappedDEK_i = Encrypt(KEK_v, DEK_i)   ← stored alongside the object

Decrypt: DEK_i = Decrypt(KEK_v, WrappedDEK_i)
         plaintext_i = Decrypt(DEK_i, Ciphertext_i)

Rotate master key — the KMS mints a new KEK version. Every WrappedDEK is simply re-wrapped under the new version; the bulk ciphertext is never touched, so rotation is cheap even for petabytes of data.
Envelope encryption ON — every object gets its own DEK. If one DEK leaks (a compromised process, a debug log, a misconfigured cache), only the single object it protects is exposed — the graph shows one red node.
Envelope encryption OFF — every object is "encrypted" with the same shared key. The same single leak now exposes every object at once: this is the blast-radius argument for per-object DEKs, and why "one key encrypts everything" is a real anti-pattern.
Simulate DEK leak — picks one random DEK and marks it exposed, then traces every object wrapped under it. Blast radius = exposed objects ÷ total objects.

The KEK itself is never exported from the KMS's hardware boundary — only Encrypt and Decrypt calls cross it, which is why compromising an application's memory can leak a DEK but essentially never the KEK.

Master key (KEK) Data-encryption key (DEK) Protected data object Exposed data object

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.