The simplest way to encrypt sensitive data in a database is to use a single key for everything. But if that key leaks, all data is exposed. Replacing the key means re-encrypting all data.

Envelope encryption solves this by separating the “key that encrypts keys” from the “key that encrypts data.”

Symmetric Encryption

For use cases like DB column encryption, where every write requires encryption and every read requires decryption, symmetric encryption is the right fit. A single key handles both operations, keeping computational cost low.

Asymmetric encryption uses a public/private key pair. It serves key exchange and digital signatures well, but carries higher computational cost and more complex key management than symmetric encryption. For frequent encrypt/decrypt cycles in DB columns, it adds unnecessary overhead.

AES-256-GCM

Among symmetric algorithms, AES-256-GCM is a common choice because it satisfies security, integrity, and performance together.

On key length, AES-256 uses a 256-bit key that provides strong resistance against brute-force attacks. It is also the most widely vetted symmetric algorithm available.

The mode of operation, GCM (Galois/Counter Mode), has two advantages compared to other modes like CBC.

First, integrity. GCM generates an authentication tag alongside the ciphertext. Tampering is detected at decryption time. CBC requires a separate HMAC step for this; GCM handles it in a single operation.

Second, it uses an IV (initialization vector) to produce different ciphertext even for identical plaintext. The IV is stored alongside the ciphertext and must be used during decryption to recover the original.

GCM has one important pitfall, though. Encrypting twice with the same key and same IV completely breaks the security. IVs must be unique for every encryption, typically generated by a secure random source or managed via a counter-based scheme.

CMK/DEK Two-Tier Structure

The core of envelope encryption is splitting keys into two layers.

flowchart LR
    CMK["CMK
(Master Key)"] -->|"Encrypts/Decrypts DEK"| DEK["DEK
(Data Encryption Key)"]
    DEK -->|"Encrypts/Decrypts data"| DATA["Plaintext Data"]

At the top, the CMK (Customer Master Key) is used solely to encrypt DEKs and never touches data directly. It typically resides inside an HSM (hardware security module) and cannot be extracted.

The actual data is handled by the DEK (Data Encryption Key), which sits one layer below. Data is encrypted with the plaintext DEK, and then the DEK itself is re-encrypted by the CMK and stored.

Encryption Flow

A DEK is issued once from the key management service. At issuance, both the plaintext DEK and the encrypted DEK are returned together. The plaintext DEK encrypts the data immediately, and the encrypted DEK is stored alongside the data in the DB.

sequenceDiagram
    participant App as Service
    participant KMS as Key Management Service
    participant DB as DB

    App->>KMS: Request new DEK (specify CMK)
    KMS-->>App: Return plaintext DEK + encrypted DEK
    App->>App: Encrypt data with plaintext DEK + IV
    App->>DB: Store ciphertext + IV + encrypted DEK
    Note over App: Discard plaintext DEK immediately

When reading, fetch the ciphertext, IV, and encrypted DEK from the DB, request decryption of the encrypted DEK from the key management service, and decrypt the ciphertext with the returned plaintext DEK and IV. The plaintext DEK is held briefly in memory and discarded immediately.

Comparison with Single-Key Approach

With a single key, a leak exposes all data. With envelope encryption, a leaked DEK only affects the data encrypted by that specific DEK. The CMK resides in an HSM, making its leak far less likely.

Key Rotation

The practical advantage of envelope encryption becomes clear during key rotation.

With a single key, replacing it means re-encrypting all data. For large datasets, this is expensive in both time and cost.

With envelope encryption, rotating the CMK only requires re-encrypting the DEKs. The data remains encrypted with the same DEKs and does not need re-encryption. Since DEKs are tiny compared to the data, rotation cost is minimal.

flowchart LR
    subgraph Before ["Before Rotation"]
        CMK1["CMK v1"] --> DEK_ENC1["Encrypted DEK"]
    end
    subgraph After ["After Rotation"]
        CMK2["CMK v2"] --> DEK_ENC2["Encrypted DEK
(re-encrypted)"]
    end
    DEK_ENC1 -.->|"Only DEK re-encrypted
Data unchanged"| DEK_ENC2

Regular key rotation is essential for defending against insider threats. Envelope encryption minimizes the cost of this practice.

Using Cloud Key Management Services

While envelope encryption can be implemented from scratch, leveraging cloud key management services is the common approach. Selection criteria include:

  • HSM-based key storage: Whether CMKs exist only inside hardware, not software. HSM-based storage makes key extraction impossible.
  • Automatic key rotation: Whether the service supports automatic CMK rotation. Manual rotation adds operational burden.
  • Container environment compatibility: Whether keys can be injected into K8S environments without API calls from service code. This affects service code complexity.

Separating the service that issues keys from the service that stores encrypted keys is another common configuration. It limits how a single service compromise can propagate to the entire key set, and aligns with the principle of least privilege.

When Envelope Encryption Fits

Envelope encryption is effective under these conditions:

  • Large volumes of encrypted data with regular key rotation requirements
  • Multiple services sharing the same encryption keys
  • Compliance requirements for key management audit trails

For small-scale, one-time encryption, a single-key approach may suffice. Envelope encryption adds key management complexity, so it should be chosen when the scale and requirements justify that complexity.

References