Key Escrow for Encrypted Backups

Encryption turns a backup into a liability with a condition attached. The ciphertext is worthless without a key, which is the point, and it stays worthless forever if the key is lost, which is usually not. Backup retention is measured in years; key management is measured in months. The two clocks run at different rates, and the failure mode appears at the intersection: a backup that is intact, verifiable, and undecryptable.

The design that makes this manageable is a hierarchy in which the key that protects the data is itself protected by a key with a longer life and a different custodian. Whether that hierarchy survives an incident depends on decisions made long before the incident, mostly about where copies of the top key live.

Two keys with different lifetimes

A data encryption key is generated per backup, or per object within a backup, and used to encrypt the payload with an authenticated mode such as AES-256-GCM. The mode’s parameters are fixed and small: a 256-bit key, a 96-bit nonce, and a 128-bit authentication tag. The nonce must never repeat under the same key. Reusing a nonce in GCM does not merely weaken the ciphertext; it leaks the exclusive-or of the two plaintexts and allows forgery of messages under that key. Generating a fresh key per object removes the problem at the cost of one key per object, which is why keys are cheap and nonces are not.

The data key is then wrapped, meaning encrypted, by a key encryption key that lives in a key management service or an HSM. The wrapped key is stored next to the ciphertext. Decryption is a two-step operation: unwrap the data key with the service, then decrypt the payload locally. The service never sees the data, and the data never leaves the client unencrypted.

The hierarchy exists so that the long-lived secret is small, rarely used, and kept in a place with an audit trail, while the short-lived secrets are numerous and disposable. A data key that leaks compromises one object. The key encryption key that leaks compromises everything it ever wrapped, which is why it is generated inside the HSM and never exported in the normal course of operation.

Rotation that does not rewrite the data

Rotating the key encryption key does not require re-encrypting the backups. The wrapped data keys can be unwrapped with the old key version and rewrapped with the new one, an operation that touches a few hundred bytes per object rather than the object itself. This is the property that makes rotation practical at all: re-encrypting a multi-terabyte repository every quarter is not a schedule anyone keeps.

The rewrapping pass is still a full traversal of the repository’s metadata, and it has to complete before the old key version is disabled. That requirement is where rotation fails in practice. A rotation job that covers recent backups and times out on the archive tier leaves a tail of objects wrapped under the old version; the old version is then disabled on schedule, and the tail becomes undecryptable. The failure is silent because it affects data nobody reads until a restore.

Two rules prevent it. The old key version stays enabled until every wrapped key in the repository has been confirmed rewrapped, and that confirmation comes from reading each object’s key header rather than from the rotation job’s exit status. Destruction of the old version is a separate, deliberate, audited step, delayed by a period longer than the longest plausible discovery of a missed object.

Retention plays into the same arithmetic. If the key rotation interval is ninety days and the backup retention is seven years, then a backup taken today will outlive roughly twenty-eight key versions. Every one of those versions must remain usable, or the backups wrapped under it must have been rewrapped and the version retired. A key management policy that destroys versions after a fixed count, independent of what is still wrapped under them, is a policy for deleting backups on a schedule nobody wrote down.

What escrow protects and what it endangers

Escrow is a copy of the key material held somewhere other than the system that uses it, so that the loss of that system does not make the data unrecoverable. The obvious case is a key management service in the same account, region, or cluster as the data: a compromise or a destructive accident that removes the data also removes the keys, and the encryption has simply made the deletion faster and more complete.

The less obvious case is the ordinary one. The service is available, the account is intact, and the person who knew which key alias was used has left. Key material that exists in exactly one place has an availability equal to that place’s availability, and a key whose identifier is unknown is functionally destroyed.

Escrow widens the attack surface, and that is not a side effect; it is the mechanism. A second copy of the root key is a second thing to steal. The controls that make it acceptable are procedural rather than cryptographic: split knowledge so that no single person holds the whole key, dual control so that two people must act together, an offline medium stored in a physically controlled location, and an audit record of every use. The escrow copy is used rarely, which is both its protection and its weakness, because a procedure exercised once a year is a procedure that does not work.

There is a legitimate opposite use of the same lever. Destroying the key destroys the data, quickly and completely, without needing to find every copy of the ciphertext. That makes key destruction an erasure mechanism, and it also makes an accidental key destruction indistinguishable from an accidental data destruction. The two uses need different authorization paths, or the erasure capability becomes the incident.

Splitting a key among people

The standard way to hold an escrow copy without trusting one holder is threshold secret sharing. A secret is split into n shares such that any k of them reconstruct it and any k-1 reveal nothing. Shamir’s construction, published in 1979, uses a random polynomial of degree k-1 whose constant term is the secret; each share is a point on the polynomial, and interpolation recovers the constant from any k points.

The parameters are the policy. A 3-of-5 split tolerates the loss of two holders and requires three to act. A 2-of-3 split is easier to assemble and weaker against collusion. The shares must be stored separately, because shares stored together are a single copy of the secret with extra steps, and the reconstruction must happen on a machine that is not the one being recovered from.

Threshold sharing protects against the loss of holders and against any single holder acting alone. It does not protect against a compromised reconstruction environment: once the shares are combined, the secret exists in memory on whatever machine performed the combination, and that machine becomes the weakest point. The same concern applies to the key management service’s own root of trust, which is why hardware security modules exist.

Key derivation is the other half of the design. A single high-entropy secret is expanded into per-purpose keys with a derivation function, so that the key used to wrap backups is not the key used to authenticate the configuration that describes them. HKDF is the standard construction for this: extract a pseudorandom key from the input material, then expand it with a context string that binds each derived key to its purpose. Without the binding, two subsystems given the same input derive the same key, and a compromise of one is a compromise of both.

Drills that include the key

A restore drill that uses the same key service, the same credentials, and the same network path as production tests the data path and skips the key path. The key path is the one that fails in a disaster, because it depends on components that the disaster may have removed: the key service’s availability, the identity provider that authorizes access to it, the network route to it, and the humans who hold the shares.

The drill that covers it restores the oldest retained backup, using only material that is held outside the failed environment. That means the escrow shares, the offline copy of the repository credentials, and a documented procedure for combining them. The oldest backup is the right target because it is the one wrapped under the oldest key version, which is the version most likely to have been retired, and because its retention is the one the policy has had the most opportunities to break.

The output is a duration and a yes or no, recorded. A key ceremony that takes four hours is a fact that belongs in the recovery time objective, and it is not visible from any backup report. A share that no longer reconstructs is a fact that should be discovered in a drill rather than during an incident.

The dependency between the restore procedure and the key material is one instance of the circular dependency described in recovery ordering for multi-service estates, and the verification that the decrypted result is the data that was intended is the subject of checksum verification and restore drills.