CLOUD CONCEPT

Envelope Encryption

Envelope encryption protects data with a data encryption key and protects that key with a separate key-encryption key.

Cloud Concepts Hub →

What is Envelope Encryption

Envelope encryption separates bulk data encryption from the protection and management of encryption keys. It combines efficient local encryption with centralized key controls, allowing cloud systems to protect large datasets without sending every byte through a key management service.

Envelope encryption uses a hierarchy of keys rather than a single key for every operation. A data encryption key, or DEK, encrypts the actual data, typically using a symmetric authenticated-encryption algorithm such as AES-GCM. A separate key-encryption key, or KEK, encrypts or wraps the DEK. The encrypted data, wrapped DEK, and required cryptographic metadata form a package that can be stored together. The KEK is protected separately, usually by a key management system or hardware security module.

A typical encryption workflow starts by generating a cryptographically random DEK. The application or storage service uses its plaintext form to encrypt the data, obtains an encrypted copy of the DEK under the KEK, and removes the plaintext DEK from memory as soon as practical. To decrypt, an authorized component submits the wrapped DEK to the key management system, obtains the plaintext DEK, and decrypts the data locally. Storing the wrapped DEK beside the ciphertext is normal; storing the plaintext DEK there would defeat the separation.

In AWS, an application can call AWS KMS GenerateDataKey to receive both a plaintext data key and an encrypted copy. It encrypts its payload locally and retains only the encrypted key with the payload. Later, AWS KMS Decrypt can recover the data key for an authorized caller. This avoids the small payload limit of direct KMS encryption and avoids sending a large file through KMS. Production implementations should use established encryption libraries and authenticated formats rather than assembling cryptographic protocols themselves.

Envelope encryption does not determine whether encryption is client-side or server-side. With client-side encryption, the application encrypts data before uploading it, so the storage service receives ciphertext. With server-side encryption, a storage service performs the encryption after receiving the data. Amazon S3 with SSE-KMS is an example of server-side encryption using envelope encryption. Choose the encryption location according to the trust boundary: requirements to encrypt before upload call for client-side encryption, while requirements for managed at-rest protection may be satisfied by server-side encryption. Transport encryption remains necessary in either case.

The key service choice depends on operational and control requirements. AWS KMS provides managed key protection, authorization, auditing, and integrations with storage services. AWS CloudHSM provides customer-controlled HSM resources for applications requiring more direct control over keys and cryptographic operations, but brings additional responsibility for integration, availability, and administration. CloudHSM is not automatically interchangeable with a KMS key in every service integration. Envelope encryption itself does not require asymmetric cryptography; the KEK can also be symmetric.

Key rotation is frequently misunderstood. Rotating the backing key material for a logical KMS key does not automatically re-encrypt existing data or replace its wrapped DEKs. Where the encryption format and service support it, a DEK can be rewrapped under another KEK without decrypting and re-encrypting the bulk data. However, changing the encryption key for existing managed storage may require a service-specific copy or migration operation. If a plaintext DEK was compromised, merely rewrapping it does not restore confidentiality; the affected data needs a new DEK and re-encryption.

Operational controls remain essential. Restrict both data access and key-use permissions, separate key administration from decryption privileges, and audit key operations. Use authenticated metadata to bind ciphertext to its intended context; AWS KMS encryption context is nonsecret additional authenticated data and must match when decrypting. Data-key caching can reduce latency and request costs, but increases plaintext-key lifetime and can delay the effect of access revocation. Disabling a KEK blocks future unwrap operations, not use of keys already held in memory. Permanent loss of all usable KEK material can make the protected data unrecoverable, including backups.

Key aspects of Envelope Encryption

Envelope encryption combines efficient data encryption with separately governed key protection, while requiring careful handling of metadata, permissions, rotation, and plaintext-key lifetime.

Separate data keys and key-encryption keys

Use DEKs for bulk data encryption and a separately protected KEK to wrap those keys. This keeps the long-lived protection key out of ordinary storage and application data paths.

Efficient bulk encryption

Encrypt large payloads locally or within the storage service rather than sending them to a key management API. Key-service requests handle small key material, although request latency, quotas, and costs still affect system design.

Portable encrypted key metadata

Store the wrapped DEK with the ciphertext and the metadata needed to interpret it. Protect metadata integrity and never persist the plaintext DEK alongside the encrypted data.

Independent choice of encryption location

Apply the same key hierarchy in client-side or server-side encryption. Select the location based on which components may see plaintext, not on the assumption that envelope encryption implies client-side protection.

Distinct rotation and re-encryption operations

Distinguish KEK rotation, DEK rewrapping, and bulk data re-encryption. Rewrapping may simplify migration between KEKs, but it does not remediate exposure of the plaintext DEK.

Authorization and key-lifecycle dependencies

Control who can unwrap data keys and plan for key availability, recovery, and deletion. Cached plaintext keys and already decrypted data remain usable even after future key-service access is revoked.

Cloud services for Envelope Encryption

AWS KMS supplies centrally governed key protection, while Amazon S3 and Amazon EBS perform bulk encryption within their storage workflows. Applications needing encryption before upload can instead encrypt locally and store ciphertext plus wrapped data keys in S3. AWS CloudHSM supports designs requiring direct control over HSM-backed key operations, with greater integration and operational responsibility. Across these approaches, storage permissions and key-use permissions must be designed together, and recovery plans must preserve access to the keys needed for both current data and retained backups.

Amazon Simple Storage Service image Amazon S3

Amazon S3 applies envelope encryption for server-side encryption, including SSE-KMS, where AWS KMS protects the key hierarchy used for object encryption. S3 Bucket Keys can reduce KMS request traffic, so SSE-KMS does not necessarily imply a separate KMS request for every object operation.

Open Amazon S3 →
AWS CloudHSM image AWS CloudHSM

AWS CloudHSM supplies customer-controlled HSM resources that applications can use to protect KEKs and wrap or unwrap DEKs. Applications must implement a compatible workflow and manage HSM availability and administration; CloudHSM is not a drop-in replacement for every KMS integration.

Open AWS CloudHSM →