Cryptographic Key Management

Encryption is only as strong as the protection of its keys. AES-256 does not help if the key sits in a configuration file next to the ciphertext, if every engineer can call decrypt, if nobody can say which data a key protects, or if a lost key makes backups unreadable. Most real-world cryptographic failures are key management failures, not broken algorithms.

Key management covers the full lifecycle of keys — creation, storage, use, rotation, backup, revocation, and destruction — together with the access control and audit around every operation. Cloud key management services (KMS) and hardware security modules (HSMs) handle the hardest parts, but the architecture around them — key hierarchies, policies, rotation plans, and recovery — remains the application team's job.

TL;DR

Quick Example

Envelope encryption with AWS KMS and AES-GCM, binding each data key to its tenant through encryption context:

Turning on automatic rotation for the KMS key:

A decrypt call with the wrong tenant's context fails, and every call — successful or not — is recorded in the audit log.

Core Concepts

The Key Lifecycle

NIST SP 800-57 describes these stages and recommends crypto-periods — how long a key may be used — based on its type, volume of use, and risk.

Key Hierarchies and Envelope Encryption

Encrypting large amounts of data directly with a KMS key is slow and limited in size, so systems use a hierarchy:

To decrypt, the application asks KMS to unwrap the DEK. This keeps master keys inside the service, limits how much data any one DEK protects, and makes rotation of the KEK cheap: DEKs can be re-wrapped without re-encrypting the data. Google Cloud KMS, Azure Key Vault, HashiCorp Vault's transit engine, and AWS KMS all support this pattern. See Encryption and HashiCorp Vault.

Access Control and Separation of Duties

Encryption context (or associated data) binds ciphertext to its purpose — tenant, table, environment — so a DEK unwrapped for one context cannot be misused for another, and logs show what was decrypted. Grant decrypt permission narrowly, per service and key.

Auditing

KMS operations are logged (for example in AWS CloudTrail, Google Cloud Audit Logs, or Azure Monitor). Alert on unusual decrypt volume, decrypts from unexpected identities or networks, policy changes, disabled keys, and scheduled deletions.

Rotation

Rotation of a KEK alone does not change data already encrypted with old DEKs; when policy requires new key material for existing data, plan a re-encryption job. See JWT.

Destruction, Crypto-Shredding, and Customer-Managed Keys

Crypto-shredding makes data unrecoverable by destroying the keys that encrypt it — practical for deleting a tenant's data from backups and replicas where deleting every copy is hard. It only works if keys are scoped (per tenant or per dataset) and no other copies of the key exist.

Destruction is irreversible, which is why KMS services enforce waiting periods before deleting keys and why keys should be disabled first to see what breaks.

Customer-managed keys (CMK, BYOK, HYOK) let SaaS customers control the keys protecting their data — revoking access cuts off the provider. They require per-tenant key hierarchies, clear behavior when a key is unavailable, and support processes for key loss.

Responding to Key Compromise

  1. Contain: disable the key or revoke the identities that misused it.
  2. Assess: use audit logs to determine what was decrypted or signed, when, and by whom.
  3. Rotate: create new keys, re-encrypt affected data, and reissue signed artifacts or tokens.
  4. Revoke trust: remove compromised public keys from JWKS and trust stores; revoke certificates.
  5. Review: fix the root cause — over-broad permissions, leaked credentials, missing alerts.

See Cryptographic Failures and Secrets Management.

Best Practices

Never Handle Master Keys in Application Code

Use KMS or HSM operations and envelope encryption; application memory should only ever hold short-lived data keys.

Scope Keys Narrowly

Separate keys by purpose, environment, and — where useful — tenant, so access and deletion can be targeted.

Plan for Algorithm Change

Record which algorithms and key sizes protect which data, so migrations such as post-quantum cryptography are tractable. See Post-Quantum Migration.

Test Recovery and Deletion

Rehearse restoring from backups with key access, and confirm that disabling a key affects only what you expect.

Common Mistakes

Keys Stored Next to the Data

One Key for Everything

Deleting a Key Without Knowing Its Data

FAQ

What is envelope encryption?

A pattern in which data is encrypted with a data key, and the data key is itself encrypted with a key-encryption key held in a KMS or HSM. Only the encrypted data key is stored alongside the data.

What is the difference between a KMS and an HSM?

An HSM is tamper-resistant hardware that generates and protects keys and performs cryptographic operations. A KMS is a managed service — often backed by HSMs — that adds APIs, access policies, auditing, and rotation.

How often should encryption keys be rotated?

According to defined crypto-periods based on risk and usage — commonly yearly for KMS master keys, with immediate rotation after suspected exposure. Data keys are often generated per object.

What is crypto-shredding?

Deleting data by destroying the keys that encrypt it, which makes every copy of the ciphertext — including backups — unreadable.

Does rotating a KMS key re-encrypt my data?

Not automatically. Automatic rotation creates new key material for future encryptions and keeps old material for decryption. Re-encrypting existing data requires a separate process.

Related Topics

References