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.