Key Management

Key management is the set of policies and mechanisms governing a cryptographic key from creation to destruction. A key is not a static object; it is a resource with a state (active, suspended, expired, revoked, destroyed) and a lifetime over which its security guarantees hold. Three properties define whether key management is done well: confidentiality of storage (the key never leaks to an unauthorized party), bounded exposure (compromising the key exposes only a limited amount of past or future data), and timely revocation (when compromise is detected, dependent parties learn quickly enough to stop trusting the key). Two derived concepts do most of the heavy lifting in modern systems. Forward secrecy (sometimes called perfect forward secrecy, PFS) is the property that session keys derived during a protocol run cannot be recovered even if the long-term private key is later compromised. It is achieved by using ephemeral key-exchange values — generated fresh per session and destroyed immediately after use — so that no persistent secret ties past sessions to a future compromise. Key rotation is the practice of periodically replacing a key with a new one, even absent any known compromise, so that the "blast radius" of an eventual leak is capped to the traffic protected since the last rotation. A third concept, key derivation, lets a single high-entropy master secret generate many independent-looking subkeys for different purposes (encryption, authentication, different sessions) using a Key Derivation Function (KDF) such as HKDF. This avoids key reuse across contexts, a classic source of cross-protocol attacks, and underlies ratcheting schemes (as in the Signal protocol) where each message derives a fresh key from the previous one and then erases the old key, giving both forward secrecy and post-compromise security (recovery after a transient compromise).

The key lifecycle as a state machine

Every key, symmetric or asymmetric, moves through a small number of states. Modeling this explicitly is what turns "key management" from a vague buzzword into an engineerable system. ``` STATE MACHINE: Key Lifecycle States: PRE_ACTIVE -> ACTIVE -> SUSPENDED -> ACTIVE (resume) ACTIVE -> DEACTIVATED -> COMPROMISED (if detected) DEACTIVATED/COMPROMISED -> DESTROYED Transitions: generate() : NONE -> PRE_ACTIVE // key material created, not yet used activate() : PRE_ACTIVE -> ACTIVE // distributed, usable for new operations suspend() : ACTIVE -> SUSPENDED // temporarily disallowed (e.g. audit) resume() : SUSPENDED -> ACTIVE deactivate() : ACTIVE -> DEACTIVATED // planned end of life (rotation) compromise() : ACTIVE -> COMPROMISED // detected/suspected leak: emergency revoke() : DEACTIVATED|COMPROMISED -> REVOKED // publish to relying parties destroy() : REVOKED -> DESTROYED // zeroize all copies of key material ``` The critical invariant this machine enforces: a key may only be used for new cryptographic operations while in the ACTIVE state. Decryption of old ciphertext may still be permitted after deactivation (to read historical data), but encryption, signing, and key agreement using that key must stop the moment it leaves ACTIVE. Violating this — continuing to encrypt with a "deactivated" key because rotation tooling is incomplete — is one of the most common real-world key-management bugs.

Generation

Key generation quality is foundational: every downstream guarantee assumes the key was drawn uniformly (or near-uniformly, for structured keys like RSA primes) from its keyspace using a cryptographically secure random number generator (CSPRNG). The 2012 "factorable.net" incident, where embedded devices generated RSA keys with insufficient entropy at boot time, is the canonical failure: many devices produced the same prime factor, allowing trivial GCD-based factorization across the public key corpus. ``` FUNCTION generate_rsa_keypair(bit_length): // must use a CSPRNG seeded with sufficient entropy repeat: p <- random_prime(bit_length / 2) q <- random_prime(bit_length / 2) until p != q and gcd(p - 1, q - 1) is small and (pq) has bit_length bits n <- p q phi <- (p - 1) * (q - 1) e <- 65537 // common fixed public exponent d <- modular_inverse(e, phi) return (public_key = (n, e), private_key = (n, d)) ``` The correctness of RSA generation depends entirely on `random_prime` drawing from a source with enough entropy that no two independent runs, anywhere in the world, are likely to produce a shared prime. If the entropy pool has only, say, 32 bits of real randomness at generation time (common on headless embedded devices immediately after boot), the effective keyspace collapses far below 2^(bit_length), and collisions become plausible across a large fleet of devices — exactly what happened in practice.

Distribution and storage

Once generated, a private key must never leave secure custody in plaintext. Three standard architectures: 1. Hardware Security Module (HSM): private key material is generated inside tamper-resistant hardware and never leaves it; all signing/decryption operations are requests sent to the HSM, which returns only the result. 2. Envelope encryption: a data encryption key (DEK) encrypts the actual payload; the DEK itself is encrypted under a key encryption key (KEK) held in an HSM or KMS. Only the small, wrapped DEK needs to travel with the data. 3. Threshold secret sharing: the private key is split via Shamir's Secret Sharing into `n` shares such that any `t` of them reconstruct the key, but fewer than `t` reveal nothing. No single custodian ever holds the whole key. ``` FUNCTION envelope_encrypt(plaintext, KEK): DEK <- generate_random_key() // fresh per object ciphertext <- AEAD_encrypt(DEK, plaintext) wrapped_DEK <- AEAD_encrypt(KEK, DEK) // KEK never leaves KMS/HSM return (ciphertext, wrapped_DEK) FUNCTION envelope_decrypt(ciphertext, wrapped_DEK, KEK): DEK <- AEAD_decrypt(KEK, wrapped_DEK) // decrypt happens inside HSM boundary plaintext <- AEAD_decrypt(DEK, ciphertext) return plaintext ```

Rotation and forward secrecy

Rotation replaces a key on a schedule (or on-demand after suspected compromise) without discarding the ability to decrypt historical data encrypted under the old key. The essential technique is key versioning: every ciphertext is tagged with the identifier of the key that produced it, so decryption can look up the correct (possibly retired) key. Forward secrecy is stronger: it is achieved not by rotating a long-lived key, but by never persisting the session key material at all. In an ephemeral Diffie–Hellman exchange (DHE / ECDHE), fresh random exponents are chosen for each session, combined to produce a session key, and then the exponents are erased. Compromising the long-term signing key (used only to authenticate the exchange) does not help an attacker recover past session keys, because those depended on ephemeral values that no longer exist anywhere. ``` FUNCTION ephemeral_dh_handshake(long_term_signing_key): a <- random_scalar() // fresh, ephemeral, per-session A <- g^a mod p signature <- sign(long_term_signing_key, A) send(A, signature) receive(B, peer_signature) verify(peer_public_key, B, peer_signature) session_key <- KDF(B^a mod p) // = KDF(g^{ab}) erase(a) // critical: destroy ephemeral secret return session_key ``` The invariant that makes this work: the only persistent secret is `long_term_signing_key`, used solely for authentication, never for key agreement. An attacker who steals it in the future can impersonate the server going forward, but cannot recompute `g^{ab}` for a past session because `a` (and `b`) were random, session-specific, and destroyed.

Symmetric ratcheting (post-compromise security)

Forward secrecy answers "what if the key leaks later?" A ratchet additionally answers "what if the key leaks now, temporarily?" — by deriving each new key from the old one via a one-way function and discarding the old key, so a transient compromise does not expose all future traffic once fresh entropy is reintroduced (as in the Signal Double Ratchet, which also mixes in fresh DH values). ``` FUNCTION symmetric_ratchet_step(chain_key): message_key <- HMAC(chain_key, "msg") next_chain_key <- HMAC(chain_key, "chain") erase(chain_key) // one-way: cannot recover old key from new return (message_key, next_chain_key) ``` Because HMAC is a one-way function under standard assumptions, knowledge of `next_chain_key` gives no efficient way to recover `chain_key`, which delivers forward secrecy within a session at the message granularity — even without a fresh DH exchange each message.

Revocation

When a key is confirmed or suspected compromised, relying parties must be told to stop trusting it before they perform an operation with it. Two classic mechanisms exist, both built on Public-Key Infrastructure and Certificates:

• Certificate Revocation Lists (CRLs): the CA periodically publishes a signed list of revoked certificate serial numbers; clients must fetch and check it.
• Online Certificate Status Protocol (OCSP): a client queries a responder in real time for the status of one certificate.

Both have a shared operational weakness: checking revocation costs latency and can fail (network down, responder overloaded), and many clients implement soft-fail — proceeding as if the certificate were valid when the revocation check itself cannot be completed. This converts an availability attack (block the OCSP responder) into an authentication bypass.

Key generation. Generating an RSA modulus of bit-length `n` requires finding two random primes of length `n/2`. By the prime number theorem, the density of primes near a random `k`-bit integer is about `1 / ln(2^k) = 1/(k · ln 2)`, so a primality test succeeds after an expected `O(k)` trials. Each Miller–Rabin primality test on a `k`-bit number costs `O(k^2)` to `O(k^3)` time depending on multiplication algorithm, giving expected total generation time `O(k^3)` to `O(k^4)` for a `k`-bit RSA key — polynomial, but noticeably slower than symmetric key generation, which is `O(k)` (just reading `k` random bits). This asymmetry is precisely why systems use asymmetric keys sparingly (for authentication and key agreement) and symmetric keys for bulk encryption.

Ephemeral Diffie–Hellman. Each handshake costs one modular exponentiation per party, `O(k^3)` bit operations for a `k`-bit modulus using schoolbook multiplication (faster with Karatsuba or elliptic-curve groups, where a scalar multiplication costs `O(k)` point additions each `O(k^2)`). The security-relevant cost is not raw runtime but key-per-session freshness: forward secrecy requires literally one new exponentiation per session, which is the price paid for the property. Static (non-ephemeral) DH avoids this cost but sacrifices forward secrecy entirely — a real, honestly-stated tradeoff, which is why TLS 1.3 mandates ephemeral exchange and removed static RSA key exchange.

Ratcheting. A symmetric ratchet step is a single HMAC evaluation, `O(k)` for a `k`-bit key — essentially free. Its correctness rests on the one-wayness of HMAC (modeled as a pseudorandom function): given `next_chain_key = HMAC(chain_key, "chain")`, recovering `chain_key` is as hard as inverting a PRF, believed to require `Ω(2^k)` work for a `k`-bit key under standard cryptographic assumptions. This is why erasing `chain_key` after deriving the next one is not merely good hygiene — it is the entire security argument. If the old key is not erased, an attacker who compromises the current state also recovers all historical message keys by re-deriving forward, defeating the point.

Threshold secret sharing. A `(t, n)` Shamir scheme encodes the secret as the constant term of a random degree-`(t-1)` polynomial over a finite field, distributing `n` evaluation points as shares. Reconstruction from any `t` shares uses Lagrange interpolation, `O(t^2)` field operations (or `O(t log^2 t)` with fast interpolation). Correctness follows directly from the fact that a degree-`(t-1)` polynomial is uniquely determined by `t` points (linear algebra over a field), while any `t-1` points leave the constant term information-theoretically undetermined — the scheme's security is unconditional (information-theoretic), not merely computational, which is a genuine advantage over encryption-based key splitting.

Revocation propagation. CRL-based revocation has a latency lower bound: a compromised key remains trusted for up to the CRL's refresh interval (historically 24 hours or more), because clients cache lists. OCSP reduces this to near real-time per-check latency but adds a round trip (`O(1)` network calls per verification) and a fresh availability dependency — the responder becomes a target, and its failure mode (soft-fail) directly determines whether the system degrades safely or insecurely. There is no free lunch: OCSP stapling (the server periodically fetches its own signed status and presents it to clients) removes the client's network dependency at the cost of the same caching latency CRLs have, trading real-time freshness for availability. This is a genuine, unavoidable engineering tradeoff between freshness and availability in any revocation design.

Consider a TLS 1.3 server using ECDHE (elliptic-curve ephemeral Diffie–Hellman) for key agreement, tracing what happens across three sessions and a later key compromise.

The key lesson embedded in row 7: because the design used ephemeral Diffie–Hellman rather than deriving session keys directly from `sk_LT`, a total compromise of the long-term key six months later recovers zero historical session keys. This is forward secrecy behaving exactly as engineered. Row 8–9 shows the residual risk that forward secrecy does not eliminate: future impersonation until revocation is both issued and actually checked by clients — which is why soft-fail clients in row 9 are the real danger, not the compromise itself.

Key management as a formal discipline grew directly out of the invention of public-key cryptography itself: once keys no longer had to be exchanged in person, the entire question of how to generate, certify, store, and revoke them at scale became a first-class engineering problem rather than a matter of physical custody.

Cloud providers run dedicated Key Management Services — AWS KMS, Google Cloud KMS, Azure Key Vault — precisely to centralize envelope encryption, automatic rotation, and audit logging so that individual application teams never handle raw key material directly. HashiCorp Vault and HSM appliances (Thales, AWS CloudHSM) serve the same role on-premises, often required by regulatory regimes (PCI-DSS, FIPS 140-2/3) that mandate hardware-backed key storage for payment and government systems. The Signal protocol, and by extension WhatsApp and other end-to-end encrypted messengers, rely on the Double Ratchet — combining symmetric-key ratcheting with periodic fresh Diffie–Hellman exchanges — to give both forward secrecy and post-compromise security at the level of individual messages, not just sessions. TLS 1.3 mandates ephemeral key exchange for exactly the reasons traced in the worked example above, directly responding to the Heartbleed-era realization that long-term key compromise was inevitable and had to be made non-catastrophic. Certificate Transparency logs, used by every major browser, are themselves a key-management control: they make silent, fraudulently issued certificates for a domain publicly auditable, closing a gap that CRLs and OCSP alone could not. Password managers and passkey (WebAuthn/FIDO2) systems apply the same lifecycle discipline to per-service key pairs generated inside secure enclaves on end-user devices, ensuring private keys for authentication never leave the hardware they were generated on — a direct architectural descendant of the HSM model, brought down to consumer scale.

Ask the tutor: How would you design a key-rotation schedule and storage architecture for a service handling both TLS termination and long-term data-at-rest encryption?