Skip to content

CONCEPT Cited by 1 source

Envelope Encryption

Envelope encryption is a multi-level key-hierarchy scheme for encrypting data at rest. Data is encrypted with unique per-segment Data Encryption Keys (DEKs), which are themselves encrypted ("wrapped") by higher-level keys, with the root-of-trust key held outside the system doing the encrypting — typically in a hardware- backed Key Management Service (KMS).

The hierarchy

The canonical shape is three levels:

  1. Root key — lives in the KMS (AWS KMS, Azure Key Vault, Google Cloud KMS, HSM-backed). Never leaves the KMS in plaintext. In the concepts/cmk-customer-managed-keys case this is the customer's CMK in their own cloud tenancy.
  2. Key Encryption Key (KEK) — a transient middle layer owned by the data service's key-manager component; used to wrap DEKs. KEKs are themselves wrapped by the root key.
  3. Data Encryption Key (DEK) — unique per data segment (per file, per row group, per block, per WAL segment, …); encrypts the actual data bytes; stored in wrapped form next to the data.

Databricks' Lakebase launch articulates this hierarchy explicitly: CMK (in customer KMS) wraps KEK (in Databricks Key Manager Service), which wraps DEKs (stored alongside every data segment). (Source: sources/2026-04-20-databricks-take-control-customer-managed-keys-for-lakebase-postgres)

Why the levels exist

  • Performance. The KMS is an expensive, rate-limited, externally- owned dependency. Without the DEK layer, every block-level read or write would hit the KMS. With the hierarchy, the KMS is only called to unwrap DEKs, and the unwrapped DEK can then encrypt/decrypt many bytes locally. High-throughput encryption at storage-system scale becomes feasible.
  • Rotation without re-encryption. Rotating the root key only requires re-wrapping the (small) KEK/DEK set against the new root — the (potentially petabytes of) data underneath the DEKs is untouched. Databricks' launch post calls this "seamless key rotation"; it's a structural property of the envelope model.
  • concepts/cryptographic-shredding. Destroying the root key (or revoking access to it) makes every wrapped DEK useless and every downstream byte inaccessible, without physically deleting the data. This is the revocation primitive that gives CMK its teeth.
  • Trust-boundary separation. The data-service operator can encrypt / decrypt data without ever holding the root key. The customer (or HSM, or audit system) holds the root and observes every unwrap.

Why the DEK is stored next to the data

DEKs are wrapped (i.e. themselves encrypted by the KEK, which is wrapped by the root). A wrapped DEK is useless to anyone who cannot contact the KEK+root path. So co-locating the wrapped DEK with its ciphertext is safe, and has huge operational benefits: a reader pulls "ciphertext + wrapped DEK" in one fetch, then only needs one KMS round-trip per segment (per DEK lifetime, really, since the unwrapped DEK can be cached for a bounded window).

Common variants

  • Two-level. Some designs collapse KEK and DEK, or the root and KEK: S3 SSE-KMS, for example, uses bucket-level KEKs derived from a KMS key and per-object DEKs. The "two/three levels" count is less important than the invariant that the root key gates an exponentially larger amount of data than it directly encrypts.
  • Per-segment DEK vs. per-object DEK. Coarser DEKs (per-bucket, per-table) save metadata at the cost of blast-radius on a key compromise; finer DEKs (per row group, per WAL segment, per page) cost more metadata but reduce compromise scope. Lakebase goes fine-grained ("unique keys generated for every data segment").
  • Per-boot compute keys. Compute VMs in a concepts/stateless-compute tier add a short-lived per-boot key under the envelope to protect VM-local scratch state — see patterns/per-boot-ephemeral-key.

Seen in

Last updated · 200 distilled / 1,178 read