Protecting Key Material

Key selection, key version, algorithm and rotation all move to the service. The worker still chooses which fields to protect and which logical key name they use, but it keeps ciphertext it cannot read on its own.

Nothing in the objects changed. Rotation rewrites each small wrapped data key under the new wrapping key and leaves every object's ciphertext and every data key exactly as they were, so any copy of a data key or of a ciphertext taken earlier still decrypts.

Only the request and its result cross. The service authenticates, sends a handle naming the key and the instruction's digest, and the device computes the signature internally and returns it. Key material never travels; the operation travels to the key.

A key register records, per key: one owning team, what the key is for, the systems and data it protects, when it entered service, its current state, and which identities may use it.

Rotating the key that wraps each object's data key is a rewrap: only the small wrapped keys change and the ciphertext is never read. Rotating the key the rows are encrypted under means decrypting and re-encrypting every row.

Rotation changes only which key version encrypts new writes. Each stored ciphertext records the version that produced it, and the manager still holds the earlier versions, so old rows decrypt under the key that actually made them.

Wrapped data keys decrypt nothing on their own. They are usable only by getting the key manager to unwrap them, so the leak turns into an access-control question: whoever the manager will still answer can read those objects, and every unwrap it performs is on the record.

Look at invocation, not custody. Start with the device's operation count against the instructions the business issued, then the credential that authenticates to the device, the device's rule about who may invoke that key, and the code path that decides what gets submitted.

Batching removes round trips, not work. A hundred fields in one call is still a hundred encryptions inside the service; what falls is the number of network waits, request authorisations and concurrent calls the worker must keep in flight.

Bound it from three sides: the period the key could encrypt, the datasets whose ciphertext names it, and what the manager's usage records show calling it. Where a side is missing, the honest scope is everything it could have covered.

An exposed encryption key costs past confidentiality: whatever it encrypted and someone copied is readable forever. An exposed signing key costs future trust: its holder can mint records that verify until every verifier stops accepting it, and recent signatures fall into doubt.

Volume, per caller. Because each decrypt must be asked for, ten thousand decrypts in an hour is a number that exists outside the application and can be capped. A key inside the worker decrypts silently and leaves nothing to count.

The cache removes a manager call per read, and with it the manager's chance to refuse that read and its record of it. While an entry lives, withdrawing the service's right to unwrap changes nothing for those objects, and the decryption never appears in the manager's trail.

You cannot back up material that cannot leave, so you choose between replicating the key into sibling devices at generation, exporting it wrapped under a key that itself never leaves a device, or holding a second accepted key. Each weakens or costs something specific.

Three events escape it: keys minted self-service in seconds, systems decommissioned without anyone retiring their keys, and owning teams dissolved in reorganisations. None of the three touches a document, so the register is stale without anybody being careless.

Silence is not evidence. Gather recorded use over a window longer than the slowest cycle that could call the key, then deny it reversibly and watch for failures through a full cycle before anyone destroys material.

The systems and stores recorded as calling that key, the date it entered service, and the class of data those systems hold. Without the caller list the honest answer is "we do not know", and it cannot be reconstructed reliably afterwards.

A floor turns retirement from an intention into something the manager enforces and you can demonstrate, and it is the only completion test a backfill has. First, every copy anyone may still read - live rows, backups, replicas, archives - must already name a version at or above it.

Mint and redirect new writes first, keep the old key able to decrypt while data migrates, order the queue by what disclosure costs most, confirm from both the data side and the usage side, and only then retire — destruction last, because it is the irreversible step.

Granularity trades blast radius against volume. A key per object confines a leaked data key to one file and makes discarding that key an erasure; a key per tenant cuts wrapped keys and unwrap calls by a factor of 4,000 and makes one leaked key expose that tenant's entire set.

Keys you cannot re-key quickly because outside parties verify them, with low operation rates and high per-misuse consequence. High-rate data-path keys and keys you can replace in an afternoon do not earn the cost, the latency or the extra failure domain.

Make an owner a precondition of creating a key, point that owner at a team identifier an independent list can prove still exists, expire unattested claims, and give orphaned keys a named custodian with a deadline rather than a permanent home.

Start from the arithmetic: with no backfill, live versions converge to retention divided by rotation period - about seven here. Decide what that number should be, then choose between letting retention age versions out, funding a rolling backfill, or making rotation a cheap rewrap.

Readers must resolve the algorithm from the version the ciphertext names, not from a global setting. A version binds material and algorithm together, so one corpus can legitimately hold rows produced several different ways at once.

An attestation proves provenance, not behaviour: a signed claim that this public half's private counterpart was generated inside a genuine device, with stated attributes, at a stated time. It says nothing about who may invoke it or what was signed.

Read shape and the value of custody, per data class. A field read once at case closure pays one call; one rendered on every page view pays a call every time. Weigh that against what custody buys here.