Envelope encryption and KMS, explained

Envelope encryption means encrypting data with a data key, then encrypting, or wrapping, that data key with a master key that never leaves a key management service (KMS). The wrapped data key is stored right next to the data, and the KMS is asked to unwrap it only when the data has to be read. Every major cloud KMS works this way, because it keeps master keys in hardware, keeps bulk encryption fast and local, and makes rotating the master key cheap.

The problem with one big key

Suppose a platform wants to encrypt millions of student records, exported reports and backups. There are two obvious approaches, and both break down:

• One key, held by the application. Every server needs a copy, so the key spreads across machines, config files and backups. If it leaks once, everything encrypted with it is exposed, and replacing it means re-encrypting all the data.
  
  
• Send all the data to the key service. Master keys in a KMS never leave it, so the service would have to do the encrypting. But key services are built for small payloads: AWS KMS's Encrypt operation accepts at most 4,096 bytes, and Google Cloud KMS caps its encrypt and decrypt input at 64 KiB. Every call would also add network latency and cost.
  
  

Envelope encryption combines the strengths of both: bulk encryption happens locally and quickly, while the key that ultimately protects everything stays in hardware. It is the machinery behind most encryption at rest in the cloud.

Data keys and key-encryption keys

Google's envelope encryption documentation uses two terms that make the idea clear:

• A data encryption key (DEK) encrypts the data itself. There are many of them, and each protects a limited amount of data.
  
  
• A key encryption key (KEK) encrypts the DEKs. There are few of them, they are stored centrally in the KMS, and they are used rarely.
  
  

Think of sealed exam papers. Each bundle is locked in its own box, and the box's key travels with it inside a sealed pouch that only the exam controller's office can open. A thief who steals a box, pouch and all, still can't read the papers. And when the controller's office changes its seal, it only has to reseal the small pouches, never reopen the boxes.

Google's recommendations for DEKs follow from this: generate them locally, never store them unencrypted, keep each one near the data it protects, create a new one each time data is written, don't share one DEK between different users, and use a strong algorithm such as AES-256 in GCM mode (see AES-GCM vs AES-CBC). KEKs belong in a central key service and should be rotated regularly, and after any suspected incident.

How cloud KMS does it

AWS Key Management Service (AWS KMS) follows the same pattern with its own names. Its top-level keys are called KMS keys, and according to AWS's cryptography documentation they never leave its FIPS 140-3 Security Level 3 validated hardware security modules unencrypted. The flow is:

1. Ask for a data key. The service returns two copies of a fresh data key: one in plaintext and one encrypted under your KMS key.
   
   
2. Encrypt locally. The application encrypts the data with the plaintext data key, then removes that key from memory.
   
   
3. Store the encrypted data key with the data. It is safe to store, because only the KMS can unwrap it.
   
   
4. To read the data, send the encrypted data key to the KMS, which checks your permissions, logs the request and returns the plaintext data key for the application to use and discard.
   
   

AWS stresses that KMS generates and unwraps data keys but doesn't store, track or use them; managing them is the application's job. You can also attach an encryption context, non-secret labels such as which institute a record belongs to, which must match exactly at decryption time and appear in the audit logs, binding each data key to its purpose.

AWS also distinguishes customer managed keys, which you create and control and which carry a monthly fee plus usage charges, from keys that AWS services create and manage for you. Other clouds and HSM vendors offer the same wrapping pattern under different names.

A worked example

Imagine, as an illustration, an online coaching platform that stores records for 300 institutes. It gives each institute its own data key, wrapped by one master key in its KMS.

• Smaller blast radius. A bug that exposes one institute's data key exposes that institute's records, not everyone's.
  
  
• Cleaner exits. When an institute leaves and asks for its data to be deleted, old backups still hold copies. Destroying the key makes those copies unreadable, but only if no usable copy of the key survives; a wrapped data key sitting in a backup can still be unwrapped while its master key exists. That is why some platforms give each customer a separate master key in the KMS and delete that key when the customer leaves.
  
  
• Visible access. Every unwrap passes through the KMS and lands in its logs, so an unusual burst of decryption for one institute stands out.
  
  
• Cheap master-key rotation. Rotating the master key doesn't touch the institutes' data at all, as the next section explains.
  
  

Our guide to encryption key management covers the wider lifecycle these keys sit in.

Rotation made cheap

With envelope encryption, rotating the master key is almost free. In AWS KMS, for example, automatic rotation of a customer managed key happens every year by default, or on a custom period between 90 and 2,560 days, and can also be triggered on demand. The key's ID stays the same, older key material is kept so existing data keys can still be unwrapped, and applications need no changes, as AWS's rotation documentation explains. No data is re-encrypted.

That same documentation carries an important caveat: rotating the master key doesn't rotate the data keys or re-encrypt anything, and it doesn't help if a data key itself has leaked.

Our guide to key rotation covers schedules and the other kinds of keys you'll need to rotate.

Costs, limits and caching data keys

Every unwrap is a network call to the KMS, which adds latency and usually a per-request charge, and key services limit request rates. AWS KMS's shared quota for symmetric cryptographic operations is 10,000 requests a second per account and region by default, higher in a few large regions, and requests beyond it are throttled.

A worked example with illustrative numbers shows why that matters on exam day, when traffic arrives in bursts; our guide to handling 100,000 concurrent users covers the wider picture. If 20,000 students open a mock test within two minutes, and each student's first 30 requests each needed a fresh unwrap, the platform would make 600,000 KMS calls in 120 seconds: 5,000 a second, half the default quota, with a network round trip added to every request. If instead each application server keeps unwrapped data keys in memory for a few minutes, the KMS sees a handful of calls per server per key per cache period, a tiny fraction of that load.

Caching is a trade-off, not a free win. The plaintext data key lives in memory longer and protects more data, so a compromised server exposes more. AWS's own encryption library generates a new data key for every encryption by default and describes its data key caching as an optional feature to use cautiously, with limits on how long and how much a cached key may be used. Keep cache lifetimes short, cache only what you need, and never write plaintext keys to disk or logs.

What to ask a vendor about envelope encryption and KMS

If a platform stores your institute's data, these questions reveal a lot without needing its internal design:

• Is our data encrypted under keys that are separate from other customers' keys?
  
  
• Where are the master keys held, and is that hardware independently validated?
  
  
• Who, and which systems, can ask for our data keys to be unwrapped, and is every request logged?
  
  
• How often are master keys rotated, and what happens if a data key is exposed?
  
  
• Can we hold or control our own master key, and what happens to our data if we revoke it?
  
  
• When we leave, will our keys be destroyed, and will you confirm it?
  
  

Key takeaways

• Envelope encryption encrypts data with data keys and wraps those keys with a master key held in a KMS.
  
  
• The wrapped data key is stored beside the data; only the KMS can unwrap it, and every unwrap is logged.
  
  
• It avoids KMS size limits and latency for bulk data while keeping master keys in hardware.
  
  
• Rotating the master key needs no data re-encryption, but it doesn't fix a leaked data key.
  
  
• Caching data keys cuts cost and latency at scale, at the price of keeping plaintext keys in memory longer.
  
  

Frequently asked questions

What is KMS encryption?

KMS encryption means data is encrypted with keys managed by a key management service rather than keys an application stores itself. Usually it works as envelope encryption: the application encrypts data with a data key, and the KMS wraps that data key with a master key that never leaves its hardware. The KMS controls who may unwrap keys, logs every request and handles rotation of the master keys.

What is KMS key in AWS?

A KMS key is AWS KMS's name for a top-level key. It is a logical key with an ID and policies, backed by key material that stays inside AWS's hardware security modules. You use it to encrypt small amounts of data directly, or more often to generate and wrap data keys. Customer managed KMS keys are ones you create and control, with optional automatic rotation and a monthly fee.

What is key management service in AWS?

AWS Key Management Service (AWS KMS) is Amazon's managed service for creating and controlling encryption keys. It keeps top-level keys in FIPS 140-3 Level 3 validated hardware, lets you control access through key policies, records the use of your keys in audit logs, and rotates keys automatically if you choose. Many AWS storage and database services use it to encrypt data at rest, and applications use it for envelope encryption.