Skip to main content

Envelope Encryption

Encrypt data with a data-encryption key and protect that key under a separately stored key-encryption key or key service.

Two key layers

Envelope encryption uses a data-encryption key to protect application data and a key-encryption key or key-management service to wrap that data key. The wrapped data key can be stored next to the ciphertext. The unwrapped data key exists only where and when an authorized process needs it.

This design separates high-volume data encryption from high-authority root-key custody and supports per-object, tenant, dataset, or time-bounded data keys.

Record and context

Generate a fresh data key through an approved cryptographic mechanism. Use authenticated encryption for the data. Bind tenant, object identifier, format version, purpose, and relevant metadata as associated data. Wrap the data key under the selected key-encryption key with its own version and policy.

Store the format version, key-encryption key identifier, wrapped data key, data nonce, associated-data definition, ciphertext, and tag. Never rely on storage location alone to bind a ciphertext to its tenant or object.

Rotation and access

Rotating a key-encryption key can rewrap data keys without decrypting and re-encrypting all application data, when the construction and service support it. Rotating a data key requires new data encryption and a plan for existing records. Record progress and retain old keys only while old records need them.

Authorize unwrap by workload, tenant, data class, purpose, and environment. Limit plaintext data-key caching and erase it from memory when practical. Log key identifiers and operations, not plaintext keys or sensitive data.

Failure and residual risk

Storing wrapped and unwrapped keys together removes the separation. A compromised application with broad unwrap permission can decrypt every record even if the root key is non-exportable. Associated-data mismatch can make records unavailable. Lost root keys can make all dependent data unrecoverable. Backups must preserve both ciphertext and the right wrapped-key and metadata versions.

Pomerium boundary

Pomerium can control human access to administrative services and can protect an application route. The application and key service own data-key generation, wrap and unwrap policy, record format, associated data, caching, rotation, backup, and recovery. Pomerium does not provide application envelope encryption by protecting the route.

Evaluation checklist

  • What data-key scope limits compromise without creating unmanageable key volume?
  • Is the key-encryption key stored and authorized separately from ciphertext storage?
  • Are tenant, object, purpose, and version bound through associated data?
  • Can key-encryption key rotation rewrap data keys without exposing plaintext data?
  • Can a compromised workload invoke unwrap for unrelated tenants or records?
  • Do backup, restore, migration, and disaster recovery preserve every required key and format version?

Sources and further reading

Keep learning

Get a Personalized Demo

Schedule a Call with a Pomerium Engineer

Get a Demo