Envelope Encryption: KEK vs. DEK and Key Wrapping

Envelope encryption is a key management pattern that protects data using two separate key layers: a Data Encryption Key (DEK) that encrypts data directly, and a Key Encryption Key (KEK) that encrypts the DEK. This matters because storing a single encryption key alongside the data it protects provides no additional security over unencrypted storage. Separating the key that protects data from the key that protects that key enables independent security controls at each layer. The recommended action: use AES-256-GCM for DEKs, AES Key Wrap (RFC 3394) with a 256-bit KEK for wrapping, store the KEK inside a FIPS-validated HSM or managed KMS, and generate unique DEKs per resource rather than sharing one DEK across all data.

Quick Answer: What Is Envelope Encryption?

Envelope encryption uses two separate encryption keys: a DEK to encrypt data and a KEK to encrypt the DEK. The encrypted DEK (called a wrapped DEK) is stored alongside the encrypted data. When data access is needed, the wrapped DEK is unwrapped by the KEK (inside the KMS or HSM), the plaintext DEK is used briefly to decrypt the data, and then discarded from memory. The KEK never leaves the key management system. This pattern limits blast radius: compromising the application or data storage layer yields wrapped DEKs, which are useless without the KEK. For the full context of how this fits into a broader key management program, see the related blog on Key Management in Cryptography.

Introduction to Envelope Encryption

If you work in security or cloud infrastructure, you have likely encountered envelope encryption in compliance reviews, architecture discussions, and cloud migration planning. It is the standard key management pattern in cloud-native key management services and enterprise Hardware Security Module (HSM) deployments, and it appears in NIST SP 800-57’s key hierarchy guidance.

The core insight behind envelope encryption is that the problem of protecting data at scale is different from the problem of protecting keys. Data changes constantly and can be enormous in volume; encrypting it requires a fast symmetric algorithm. Keys change rarely and are small; protecting them is a key management problem. Separating these two concerns into two key layers, each with appropriate algorithms and storage, is what envelope encryption does.

Understanding Data Encryption Keys (DEKs)

The Data Encryption Key (DEK) is the key that directly encrypts data. It can protect a database record, file, storage object, or message. DEKs use symmetric encryption algorithms because symmetric encryption is orders of magnitude faster than asymmetric encryption for bulk data. AES-256-GCM is the current standard: AES-256 provides 256-bit key strength; GCM (Galois/Counter Mode) provides authenticated encryption, meaning any tampering with the ciphertext is detectable at decryption time.

DEKs should be unique and short-lived. Generating a new DEK for each resource (file, record, or session) rather than sharing one DEK across all data limits blast radius: if one DEK is compromised, only the data tied to that specific DEK is exposed. DEKs are generated in application memory, used to encrypt data, and then discarded from memory. They are stored in wrapped form, never in plaintext alongside the data they protect. A plaintext DEK next to the data it encrypts provides no meaningful security over unencrypted storage.

Understanding Key Encryption Keys (KEKs)

The Key Encryption Key (KEK) does not encrypt data. Its sole function is to encrypt and protect DEKs. This separation is deliberate: it means that even if someone gains access to the application layer where data is processed, they still cannot read data without separately accessing the KEK, which lives in a completely different system with different access controls.

KEKs are managed by dedicated systems: in cloud environments, a managed service (AWS KMS Customer Master Key, Azure Key Vault key, or Google Cloud KMS key); in on-premises deployments, an HSM. An HSM is a physical device designed specifically to store and operate on cryptographic keys without ever exposing them in plaintext. The KEK never leaves the HSM or KMS in plaintext form, which is the property that makes the two-layer architecture effective.

Access to the KEK must be tightly controlled through identity-based access policies, and every access must be logged. These audit logs satisfy compliance requirements under PCI DSS Requirement 3.6, HIPAA, and FIPS 140-2, and provide the forensic trail needed to investigate potential key misuse. In advanced deployments, the KEK itself is protected by a master key in the hierarchy: a master key that never leaves the HSM hardware boundary wraps the KEK, which in turn wraps DEKs. This aligns with the three-tier key hierarchy described in NIST SP 800-57 and FIPS 140-2.

Key Wrapping: How KEKs Protect DEKs

Key wrapping is the process of using the KEK to encrypt a DEK, producing a wrapped key that can be stored safely. The wrapped DEK is cryptographically opaque: without the KEK, it cannot be used. The standard algorithm for key wrapping is AES Key Wrap, defined in RFC 3394 and governed by NIST SP 800-38F. AES Key Wrap is designed specifically for cryptographic key material, with built-in integrity verification: any tampering with a wrapped key is detectable before the key is used. AES Key Wrap with Padding (RFC 5649) is the recommended variant when the DEK length is not a multiple of 64 bits.

The full envelope encryption process for data encryption:

1. The application generates a unique AES-256 DEK in memory.
2. The DEK is used to encrypt the data using AES-256-GCM, producing ciphertext.
3. The plaintext DEK is sent to the KMS or HSM, which wraps it using the KEK via AES Key Wrap (RFC 3394).
4. The KMS returns the wrapped DEK. The plaintext DEK is immediately discarded from memory.
5. The wrapped DEK is stored alongside the ciphertext (in a database column, object metadata, or a separate key store reference).

For data decryption:

1. The application retrieves the ciphertext and the wrapped DEK.
2. The wrapped DEK is sent to the KMS or HSM, which unwraps it using the KEK and returns the plaintext DEK.
3. The plaintext DEK decrypts the ciphertext.
4. The plaintext DEK is immediately discarded from memory.

The KEK never leaves the KMS or HSM at any point. The plaintext DEK exists only in application memory for the duration of the encryption or decryption operation.

Algorithm and Protocol Selection

Component	Recommended	Minimum acceptable	Avoid	Reference
DEK algorithm	AES-256-GCM	AES-128-GCM	AES-ECB, DES, 3DES, RC4	NIST SP 800-57; PCI DSS Req. 3.5
KEK key wrapping algorithm	AES Key Wrap (RFC 3394) with 256-bit KEK	AES Key Wrap with 128-bit KEK	RSA PKCS#1 v1.5 key transport; manual key copying	NIST SP 800-38F; RFC 3394
KEK storage	FIPS 140-2 Level 2 or higher HSM or managed cloud KMS	FIPS 140-2 Level 2 HSM	KEK stored in application config files or environment variables	FIPS 140-2; NIST SP 800-57
DEK granularity	Per resource (per table, per S3 bucket, per file)	Per application with short cryptoperiod	One DEK for all data (single point of failure)	NIST SP 800-57 (limit data protected per key)
DEK in-memory caching TTL	Short TTL (minutes to hours) with cache invalidation on rotation	Session-scoped caching	Unlimited in-memory caching of plaintext DEKs	Operational best practice
Post-quantum (planning horizon)	ML-KEM (FIPS 203) for KEK protection in new infrastructure	Current AES/RSA pending PQC transition	RSA/ECC KEK protection alone for long-lived key hierarchies	NIST IR 8547; FIPS 203

KEK vs. DEK: Roles, Differences, and Defence in Depth

Both KEKs and DEKs are symmetric keys using the AES algorithm. What distinguishes them is purpose, lifecycle, and management:

Attribute	DEK (Data Encryption Key)	KEK (Key Encryption Key)
What it encrypts	Business data (files, records, objects)	Other keys (DEKs only)
Generation frequency	Frequently: per object, per session, or per resource	Rarely: once per application or per rotation cycle
Where it lives	Application memory during use; wrapped form in storage	Inside KMS or HSM; never exposed in plaintext outside
Who accesses it	Application processes with authorization to encrypt/decrypt	Only the KMS or HSM; no application ever holds the KEK
Rotation frequency	Frequent: per policy (often annually or per session)	Less frequent: policy-driven (often annually), major event
Compromise impact	Only the data encrypted by that specific DEK	All wrapped DEKs protected by that KEK (catastrophic; rotate immediately)
Audit requirement	Log DEK generation and wrap/unwrap events	Log all KEK access with full identity and operation detail

The security value of the two-layer separation is defence in depth. Compromising the application gives access to wrapped DEKs: useless without the KEK. Compromising the data store gives access to ciphertext and wrapped DEKs: useless without the KEK. Compromising the KEK gives access to unwrapped DEKs and ultimately to data, but the KEK lives inside a dedicated, audited, hardware-protected system with independent access controls. Both layers must be compromised simultaneously for an attacker to access plaintext data, which is a significantly harder problem than compromising either layer alone.

Performance and Interoperability Trade-offs

Per-object DEKs maximize blast radius containment but create operational costs. Each data access requires a DEK unwrap operation against the KMS or HSM, which adds network round-trip latency (typically 1 to 10 ms per call depending on deployment) and consumes KMS API quota. For systems with high read throughput, this can create latency bottlenecks and rate limit pressure.

The standard mitigation is short-term in-memory caching of plaintext DEKs. The application unwraps a DEK once from the KMS, caches it in memory for a defined TTL (minutes to a few hours depending on sensitivity), and reuses it for multiple decrypt operations within that window before discarding and re-fetching. This trades a small increase in exposure window (the plaintext DEK remains in memory for the TTL) against a significant reduction in KMS API calls. Cache invalidation must occur immediately on key rotation events.

For interoperability, the wrapped DEK format must be standardized if data or keys are shared between systems. AES Key Wrap (RFC 3394) with documented key identifiers provides the interoperable standard. Applications storing wrapped DEKs must record the KEK identifier used for wrapping, so that decryption can retrieve the correct KEK version after a rotation event. This is especially important in multi-region or multi-cloud deployments where KEK copies may be replicated.

Deployment Examples

AWS KMS GenerateDataKey pattern: the application calls the AWS KMS GenerateDataKey API with the ARN of the Customer Managed Key (CMK, which acts as the KEK). KMS returns a plaintext AES-256 DEK and a wrapped version of the same DEK encrypted under the CMK. The application uses the plaintext DEK to encrypt data with AES-256-GCM, stores the ciphertext and the wrapped DEK (as object metadata or in a key reference table), and immediately discards the plaintext DEK from memory. The CMK never leaves AWS KMS. On subsequent data access, the application calls the KMS Decrypt API with the wrapped DEK; KMS returns the plaintext DEK for the decryption operation, which is again discarded after use.

On-premises HSM key wrapping for database field encryption: an enterprise database encrypts sensitive columns (credit card numbers, PHI, PII) at the application layer using per-column DEKs. The KEK for each column’s DEK is stored in an on-premises HSM integrated with the application through a PKCS#11 interface. When the application initializes, it requests the HSM to unwrap each column’s DEK into application memory; the wrapped DEKs are stored in the database alongside the encrypted column data. Plaintext DEKs are cached in application memory for the session. On session teardown, plaintext DEKs are zeroed from memory. All HSM wrap and unwrap operations are logged to the HSM audit log, providing the tamper-evident record that PCI DSS Requirement 3.6 and FIPS 140-2 require. HSM as a Service provides this capability for organizations that do not operate their own HSM infrastructure.

Multi-cloud envelope encryption with Bring Your Own Key (BYOK): an organization operating across multiple cloud providers generates a master KEK on-premises in an HSM and uses it to wrap per-provider KEKs. Each cloud KMS holds one wrapped provider-KEK, imported from the on-premises HSM. The cloud KMS unwraps the provider-KEK using the master KEK (provided by the on-premises HSM during import), and then uses the provider-KEK to wrap DEKs for cloud workloads. The master KEK remains exclusively on-premises. This gives the organization the ability to revoke cloud KMS access to the provider-KEK by withdrawing the master KEK, which effectively blocks all data decryption in the cloud provider without requiring migration of the data itself.

How Encryption Consulting Can Help

Envelope encryption is only as strong as the system protecting your KEKs. KEKs stored in application config files, environment variables, or software-only key stores do not provide the hardware-boundary protection that makes the two-layer architecture meaningful. Encryption Consulting’s HSM as a Service and Encryption Advisory Services address this directly:

• KEK protection in FIPS 140-3 validated HSMs: we design and implement HSM environments where Key Encryption Keys are generated, stored, and used entirely within the hardware boundary. The plaintext KEK never leaves the HSM, which is the property that FIPS 140-3 Level 3 enforces.
• AES Key Wrap implementation: we implement RFC 3394 AES Key Wrap within your HSM or KMS environment, including integrity checking built into every key wrap operation.
• Cloud KMS and HSM integration: for organizations running workloads on AWS, Azure, or Google Cloud, we integrate HSM-backed KEK management with cloud KMS services, including BYOK and HYOK (Hold Your Own Key) architectures that maintain on-premises KEK control.
• Audit logging and compliance alignment: we configure comprehensive audit trails covering every KEK access and DEK wrap/unwrap event, supporting PCI DSS, HIPAA, and FIPS 140-3 compliance requirements.
• Key rotation and lifecycle management: we establish the DEK and KEK rotation processes including automated re-wrapping of DEKs on KEK rotation, so that rotation events do not require re-encryption of underlying data.

Limitations of Envelope Encryption

• KEK compromise is catastrophic: if the KEK is compromised, every wrapped DEK it protects can be unwrapped, giving an attacker access to all the data those DEKs protect. KEK protection is the weakest link in the architecture, which is why HSM storage and strict access controls are not optional. A KEK stored in a software key store or environment variable reduces the two-layer architecture to a single effective layer.
• Per-object DEKs create storage and management overhead: a large object store with millions of files, each with a unique wrapped DEK, requires a key reference system to associate each object with its wrapped DEK. This reference system itself must be protected and must survive independent of the data store. Loss of the key reference mapping makes data permanently inaccessible even with the KEK intact.
• In-memory DEK caching expands exposure window: caching plaintext DEKs in application memory reduces KMS API call frequency but keeps plaintext key material in memory where it could be extracted by a memory dump or process inspection. Cache TTLs should be as short as performance requirements allow, and DEKs should be zeroed from memory immediately when no longer needed.
• KEK rotation requires coordinated re-wrapping: rotating the KEK does not automatically re-protect all existing wrapped DEKs. Every stored wrapped DEK must be re-wrapped under the new KEK before the old KEK is retired. This is a coordinated operation that requires careful execution to avoid leaving some DEKs wrapped under an old KEK while others are wrapped under the new one.

Conclusion

Envelope encryption solves the practical problem of protecting data at scale: you cannot feasibly store and rotate a single encryption key used for all data, and you cannot keep key material in plaintext alongside the data it protects. The two-layer DEK and KEK architecture addresses both problems by generating unique DEKs per resource, protecting them with a KEK that lives in a dedicated, hardware-protected system, and storing only wrapped DEKs alongside the data.

The pattern is practical across cloud-native (AWS KMS GenerateDataKey), on-premises HSM, and hybrid BYOK deployments. The controls that make it effective are: per-resource DEK granularity, AES Key Wrap (RFC 3394) as the wrapping algorithm, KEK stored in FIPS-validated hardware that prevents plaintext export, complete audit logging of all key operations, and defined rotation policies that include automated DEK re-wrapping on KEK rotation. If you want to assess or design an envelope encryption architecture for your environment, contact Encryption Consulting.

Frequently Asked Questions

What is envelope encryption?

Envelope encryption uses two key layers: a DEK to encrypt data, and a KEK to encrypt the DEK. The wrapped DEK is stored alongside the ciphertext. Data access requires unwrapping the DEK using the KEK (inside the KMS or HSM), decrypting the data, and discarding the plaintext DEK. The KEK never leaves the key management system.

What is the difference between a DEK and a KEK?

A DEK directly encrypts data; it is generated frequently, short-lived, and stored wrapped alongside the data it protects. A KEK only encrypts DEKs; it lives inside a KMS or HSM, is never exposed in plaintext outside that system, is accessed by no application directly, and is rotated on a policy-driven schedule as a significant operational event.

What is key wrapping and which algorithm should be used?

Key wrapping encrypts a DEK using the KEK so the wrapped key can be stored safely. The standard algorithm is AES Key Wrap (RFC 3394), governed by NIST SP 800-38F, using a 256-bit KEK. It includes built-in integrity checking so any tampering with a wrapped key is detectable before use.

How does envelope encryption work in AWS KMS?

The application calls GenerateDataKey with the CMK ARN. KMS returns a plaintext DEK (used immediately) and a wrapped DEK (for storage). The plaintext DEK encrypts the data and is discarded. The wrapped DEK is stored with the ciphertext. On access, the Decrypt API unwraps the DEK; the CMK (KEK) never leaves AWS KMS.

What are the performance trade-offs of per-object DEKs vs. shared DEKs?

Per-object DEKs limit blast radius to one object per key but require one KMS API call per access. Shared DEKs reduce API call frequency but increase compromise impact. The recommended middle ground is per-resource DEKs (per table, per bucket) with short-TTL in-memory caching of plaintext DEKs to reduce KMS API call frequency.

When should a KEK be rotated and what happens to existing DEKs?

KEK rotation follows a policy-driven schedule (typically annual). It does not require re-encryption of data: existing wrapped DEKs are re-wrapped under the new KEK (unwrap with old KEK, re-wrap with new KEK), which is a key management operation not a data operation. All wrapped DEKs must be re-wrapped before the old KEK is retired.