Key Destruction, Retired Keys, and Cryptographic Erasure

A key has a lifecycle that ends, and the end is the part most systems implement worst. Retiring a key means removing it from service for new operations. Destroying it means making it unrecoverable by any party, including the operator. Deleting the file that held it accomplishes neither reliably, and on modern storage it frequently accomplishes nothing at all.

What deletion removes

A file deletion removes a directory entry and, in most filesystems, nothing else. The blocks remain allocated in the free list with their contents intact until reused, and until then any process with direct access to the device can read them. A copy-on-write filesystem keeps the old blocks reachable through existing snapshots, so deleting a file in the live tree can leave every version of it accessible. A log-structured filesystem may retain the old data until the segment is garbage-collected.

Backups multiply this. A key file that was deleted a year ago may exist in monthly archives, in an object store with versioning enabled, in a replica in another region, and in the snapshot a database restore will eventually use. Destruction has to reach all of them, and the set of copies is usually larger than the system’s inventory suggests.

Solid-state storage adds a layer that overwriting does not reach. A write to a logical block address goes to a fresh physical page, and the old page remains until the device’s own garbage collection erases the block. The mapping table decides which physical page a read returns, and that table is not under the operating system’s control. Overwriting a file at the filesystem level may therefore leave the previous contents in physical pages for an unbounded time. NIST SP 800-88 treats overwrite as adequate for magnetic media under stated conditions and generally recommends cryptographic erase or physical destruction for flash, precisely because the controller’s internal behaviour is not observable.

The same argument applies to the host. A key that was in memory may be in a swap file, a hibernation image, a crash dump, or a page that was copied on write and never cleared. The memory protections reduce those copies but cannot enumerate them.

Two kinds of end-of-life

The distinction between retirement and destruction structures the whole process, because the requirements differ.

A retired key is no longer used for new operations but may still be needed to verify old signatures, decrypt archived data, or validate a MAC recorded in a log. It must remain available for those specific operations and must not be available for anything else. The enforcement is a policy on the key’s permitted uses, held by whatever enforces the key boundary — a usage attribute in a hardware module, a role restriction in a key service, or an authorization check in the only code path that can reach the key. Marking a key retired in a database while leaving it callable by the same API is a bookkeeping change, not a retirement.

A destroyed key is gone. No operation can use it, no backup contains it, and no party can reconstruct it. Between retirement and destruction sits the interval during which archived data still needs the key, and that interval is determined by the retention policy for the data, not by the calendar interval chosen for rotation.

The trap is a retention policy that keeps data forever and therefore keeps every key forever. Data that is never deleted requires keys that are never destroyed, which means the population of live keys grows without bound and a compromise of the key store exposes the entire history. Retention limits on data are, indirectly, the precondition for key destruction.

Cryptographic erasure

When data is encrypted under a data key, and that data key is wrapped under a master key, destroying the wrapped data key makes the payload permanently unreadable. The ciphertext can remain in place, on immutable media, in snapshots, in backups; without the data key it is a random-looking byte string. This is cryptographic erasure: the deletion is applied to the key rather than to the ciphertext.

The construction is the same hierarchy described in envelope encryption, used for a different purpose. Its value is highest where the alternative is unavailable: write-once media, replicated object stores with versioning, off-site backups that cannot be recalled, and any medium whose controller hides its physical state. In those settings, the ciphertext can be left where it is, and the destruction is one operation on a small piece of metadata.

The property must be designed in from the start. If one data key covers many objects, destroying it erases all of them — fine for a tenant, wrong for a single record. If the data key is cached in memory outside the key store, destroying the stored copy does not revoke the cached one; the rotation machinery’s version signalling is what tells a process to drop its cache, and the same signal must be used for destruction. If backups of the key store exist, they must be destroyed too, which reintroduces the original problem one level up: the master key’s backups are now the thing that must be enumerated.

The chain has to terminate somewhere. A root key in a hardware module can be destroyed by zeroizing the module’s storage, which is an operation the module performs and can attest to. A root key derived from a passphrase cannot be destroyed while the passphrase is known to anyone, and the passphrase’s own lifetime is the limit. A root key held in a file is only as destroyed as the file’s storage.

There is a second, subtler limit. Cryptographic erasure assumes the ciphertext is not decryptable by other means: that the algorithm is strong, that the key was not escrowed elsewhere, that no plaintext copy exists, and that no attacker recorded the key when it was live. It erases the data as it exists in the encrypted store, not data that was decrypted and copied. Erasure and access control are complementary, not substitutes.

Proving that a key is gone

The auditable part of destruction is the record: which key, which version, what operation was performed, by whom, at what time, and what evidence exists that the copies are gone. In a hardware module, the evidence is the module’s own response to a destroy command, and the module’s audit log is the trail. In a software store, the evidence is weaker: a record that the key material was overwritten, with no proof that every replica was.

Replicas are the central difficulty. A key store with three replicas has three copies, plus backups, plus any export taken for migration. Destruction must be a distributed operation with a result per replica, and the operation cannot be reported complete until every replica has confirmed. A policy that marks the key destroyed after the first success produces a system that believes a key is gone while two copies remain, which is worse than knowing it is still present.

Forward secrecy affects the claim as well. Data encrypted under a session key that was derived and discarded cannot be recovered later by any party, including the one that recorded the ciphertext. That is a form of erasure that happens automatically at the end of the session, and it is why protocols that discard ephemeral secrets provide a stronger destruction guarantee for their traffic than protocols that keep a long-term key that can decrypt it.

Key destruction and media sanitization meet at the physical layer. NIST SP 800-88 defines categories of sanitization — clear, purge, destroy — with the last requiring physical destruction or a verified cryptographic erase, and it maps them to media types. The mapping is not uniform: what counts as purge for a magnetic disk (overwrite or a secure erase command) differs from what counts for flash, and for some devices only physical destruction qualifies. A data disposal policy that applies one method across all media will be wrong for some of them.

Sequencing a disposal

A workable sequence has four steps, and each has a failure mode.

First, determine what the key protects and whether that data is still needed. This requires a registry that maps keys to the data they encrypt, which most systems lack; without it, the only safe assumption is that a key protects something retained, and nothing is ever destroyed. Recovering from the absence of the registry means rebuilding it, which is cheaper done at write time.

Second, retire the key: remove it from the set usable for new encryption, mark it as decrypt-only, and reject any attempt to use it for signing or wrapping. Verify the restriction by attempting the forbidden operation and observing a failure, rather than by reading the attribute.

Third, destroy every live copy. Overwrite the material where the storage permits it, using a write the compiler and the runtime cannot elide; delete the wrapped form; invalidate every cache that held it, via the same mechanism that propagates rotation signalling; and destroy the replicas with a per-replica confirmation.

Fourth, destroy the backups that contain it, or verify that the backup retention period has elapsed and that the backups are scheduled for expiry. This is the step that stretches from hours to years, and the key’s status during it should be “retired, pending destruction” rather than “destroyed”, so that any use of the key during the interval is treated as anomalous rather than impossible.

The record from those four steps is what an auditor can check. It should state which keys were destroyed, what operations were performed on which media, which replicas confirmed, and which backups were expired. The key service API is where these operations are exposed, and the reason to give them their own call rather than folding them into a generic delete is that destruction has a different authorization requirement, a different audit trail, and a different failure mode from removing a reference.