Chapter 44 — Key management lifecycle

How it works

The lifecycle:

   GENERATION
     always a CSPRNG (G1 Ch 12), ideally inside an HSM/KMS that never
     exports the raw key material for root/master keys. For BYOK
     (bring-your-own-key), generate offline with a real entropy source
     and import via the provider's secure import ceremony (wrapped with
     the provider's public wrapping key -- never transmitted in the
     clear).

   THE HIERARCHY (recap and extend Part 2 Ch 9):
     ROOT / MASTER KEY (HSM-backed, rarely touched, the ultimate trust
       anchor -- e.g. your KMS's root of trust, or an offline root CA key
       for signing, G1 Ch 29)
       -> INTERMEDIATE / CUSTOMER MASTER KEYS (per environment, per
          tenant -- these are what you actually reference in policy)
          -> DATA ENCRYPTION KEYS (ephemeral, per-object/per-field,
             wrapped by the CMK, never stored unwrapped)
     Splitting the hierarchy this way means ROTATING the top of the tree
     is cheap (re-wrap the layer below; you don't have to touch the
     bulk data) while the ROOT changes rarely and under heavy control.

   DISTRIBUTION
     never transmit a raw key over an unauthenticated or unencrypted
     channel. Envelope encryption (Part 2 Ch 9) is itself a distribution
     mechanism -- the DEK travels ONLY in its wrapped form; only the KMS
     call unwraps it, in memory, for the instant it's needed.

   ROTATION -- two different things people conflate:
     BACKING-KEY ROTATION ("rotate the CMK"): the KMS creates a NEW key
       VERSION under the same key ID; NEW encrypt/wrap operations use the
       new version; OLD ciphertext remains decryptable because the KMS
       keeps old versions available. Cheap, usually automatable
       (annual auto-rotation is a checkbox in most cloud KMS), and does
       NOT require touching your bulk data.
     DATA RE-ENCRYPTION ("actually re-encrypt everything under a new
       key"): required when you suspect the OLD key material itself is
       compromised (not just "it's been a year"), or a compliance
       standard mandates a hard cryptoperiod. Expensive -- you must
       decrypt-then-re-encrypt every object/record. Plan for it (batch
       jobs, versioned ciphertext format with a key-id prefix so you can
       migrate incrementally) rather than discovering you can't do it
       during an incident.
     Because DEKs are generated per-object/per-field and wrapped by the
     CMK, "rotating the CMK" (cheap) already limits the blast radius of a
     CMK compromise going forward -- new data uses the new version
     immediately. It's the OLD data, still wrapped by the old version,
     that needs the expensive path if that old version is the one that
     leaked.

   ESCROW AND BACKUP -- deliberately, not accidentally:
     Disaster recovery needs SOME way to recover keys if a region/HSM is
     lost -- multi-region KMS replication, or an offline backup of a root
     key under strict M-of-N control (below). This is legitimate and
     necessary.
     The RISK version of the same idea is a backdoor: a key escrowed
     "for support purposes", a master key one person can export, a
     vendor with unilateral key access. Every escrow path must be
     justified, access-controlled as tightly as the key itself, and
     logged -- treat "can this key be recovered by someone other than an
     authorized custodian following a documented procedure" as a
     standing audit question.

   DESTRUCTION / CRYPTO-SHREDDING
     see Part 2 Ch 9 and Ch 46 -- destroying the key that wraps a dataset
     makes that dataset permanently unrecoverable, which is how you
     satisfy erasure requests and tenant offboarding across every copy
     (including backups) simultaneously, PROVIDED no plaintext copy or
     unwrapped-key copy exists elsewhere (verify this, don't assume it).

   ALGORITHM AGILITY
     key metadata should record the ALGORITHM and PARAMETERS it was
     created under (G1 Ch 25's crypto-agility principle, applied to keys
     specifically) so a future migration (e.g. a post-quantum signing key
     rotation) is a planned rollover, not an archaeology project.

HSM operations and key ceremonies (for root/master keys):

   FIPS 140-2/3 Level 2 or 3 hardware for root keys -- tamper-evidence
   (L2) or tamper-response (L3), so key extraction requires defeating
   physical protections, not just software access.

   SPLIT KNOWLEDGE / DUAL CONTROL / M-of-N: no single person can
   reconstruct a root key alone. A KEY CEREMONY generates the key inside
   the HSM (it never exists outside it) and splits any BACKUP/recovery
   material into N shares held by different custodians, requiring M of
   them (e.g. 3 of 5) to reconstruct -- and reconstruction itself happens
   inside a controlled ceremony, logged, witnessed, rare.
   (This is exactly how DNSSEC root-zone key ceremonies and most
   certificate authority root-key generations work -- publicly documented
   processes worth reading once for the model.)

   SEPARATION OF DUTIES: whoever administers KEYS (creates, rotates,
   sets policy) should not be the same role that administers the DATA
   those keys protect, and vice versa. A single compromised admin account
   then can't both access the data AND grant itself the key to decrypt
   it.

   MONITORING: every key USE (encrypt/decrypt/sign) and every key ADMIN
   action (create, rotate, policy change, delete) is logged (Part 2 Ch 9's
   CloudTrail example) and reviewed; a spike in decrypt calls for one key,
   or a policy change outside a change window, is a detection rule
   (Ch 54), not just an audit artefact.

   BYOK vs HYOK vs cloud-managed:
     cloud-managed key       simplest; provider generates and holds it.
     BYOK (bring your own)   you generate the root key material (often in
                              your own HSM) and import it into the
                              provider's KMS -- you control generation,
                              the provider operates the service.
     HYOK (hold your own /
       external key manager)  the key material NEVER enters the
                              provider's environment; an EXTERNAL KEY
                              STORE (AWS XKS, GCP External Key Manager)
                              on YOUR infrastructure services
                              encrypt/decrypt calls -- maximum control,
                              maximum operational burden, and a hard
                              dependency: if your external KMS is down,
                              the cloud provider cannot decrypt ANYTHING
                              that depends on it, including their own
                              support access.