Envelope Encryption

Envelope encryption protects data with a data encryption key (DEK), then encrypts that key with a key encryption key (KEK). Google Cloud describes this separation as a way to keep many wrapped DEKs near their payloads while managing fewer KEKs centrally. The application-layer example keeps the KEK in Cloud KMS and uses an unwrapped DEK locally.

The separation provides a place to control access to unwrapping and can reduce the amount of material migrated during a KEK change. Its protection depends on how keys are used, retained and authorized; adding a key layer does not itself guarantee tenant isolation or complete data-use auditing.

What it does to rotation

Distinguish creating a new KEK version from moving existing wrapped DEKs to it. Cloud KMS rotation changes the version used for new encryption but does not automatically re-encrypt old ciphertext or disable old key versions. An application can separately unwrap and rewrap existing DEKs, avoiding payload re-encryption when those DEKs remain suitable. Check every dependent copy before retiring an old KEK version.

Google recommends a new DEK for each write and avoiding reuse across users. That limits reuse but does not settle incident recovery. If a plaintext DEK, or an old KEK together with its wrapped DEKs, has escaped, rewrapping the same DEKs cannot remove the attacker’s capability. Data still under your control may need new DEKs and payload re-encryption. Neither rotation nor re-encryption recalls plaintext or decryptable copies already taken.

Unwrapping and data access

Unwrapping is an authorization boundary, alongside access to ciphertext and permissions in the application. In Cloud KMS, decrypt permissions can be granted at the CryptoKey level. If one KEK wraps several tenants’ DEKs, a caller allowed to use that KEK does not acquire separate per-tenant restrictions merely because the DEK values differ.

A KMS audit log records key-service operations such as Decrypt. After unwrapping, an application can reuse a DEK for local reads without another KMS call; AWS Encryption SDK documentation describes such data-key caching. The KMS caller may also be a service acting for many users. Correlate key-service events with application and data-engine records, and verify collection settings, identifiers and retention. A decrypt-permission list and a query-permission list describe different layers of access.

Separate DEKs are useful building blocks for tenant isolation, but independent revocation needs a corresponding enforcement boundary. Options include tenant-specific KEKs and permissions, or a mediator that verifies the tenant and its association with the protected object before allowing unwrap. Include wrapped DEKs in backups and older versions in the inventory. Deleting one current wrapper cannot make all retained copies unreadable.

What it protects against, and what it does not

Threat	Does this help?	Why
Someone obtains stored ciphertext	Yes, under key-separation assumptions	Protection depends on the attacker lacking usable DEKs, KEKs and authorized decryption paths
One tenant’s data must become unreadable	Conditional	Independent key authorization or complete removal of usable key material is required; retained wrappers, backups and plaintext keys can defeat the intended revocation
An authorized application is compromised	Limited	It can use its grants and retained keys. Scope limits and KMS logs constrain or observe calls, not every subsequent local read
A key administrator acts maliciously	Depends on effective authority	Separate administration from decryption, inspect self-grant paths, and protect audit records; logging alone does not prevent misuse
Data leaves through an authorized export	No	The copy is written in plaintext or under a different key, which is why export paths are counted separately

An authorized consumer can still expose plaintext, so review its permissions and export paths separately. The broader distinction between protecting stored ciphertext and controlling use after decryption is covered in encryption.

Implementation notes worth knowing

Cloud KMS documents a 64 KiB maximum input for its Encrypt and Decrypt operations in this envelope-encryption example. Wrapping a small DEK lets the application encrypt a larger payload locally. Use the limits of the selected service and operation rather than treating this product limit as part of the cryptographic definition.

Caching trades fewer key-service calls for retained plaintext key material. A cooperative consumer’s cache expiry can limit continued use after permission is revoked, provided it actually discards the key and cannot reacquire it. An attacker’s copied DEK does not inherit that TTL. Revoking unwrap access blocks future authorized calls, not offline use of an already obtained key. Secrets management covers the credentials and operating procedures needed around these paths.

How key custody sits alongside request verification, network controls, and administrative paths is worked through in The Network Is Not a Credential.

References

• Google Cloud KMS, Envelope encryption
• Google Cloud KMS, Key rotation
• Google Cloud KMS, Permissions and roles
• Google Cloud KMS, Audit logging
• AWS Encryption SDK, Data key caching