A restarted secret store is running but refuses every read until the key protecting its contents is supplied — where can that key come from?
answer
- the lock's key is not inside the box
- start-up needs one input from outside
- running and reachable, still answering nothing
- shares recombined, unwrap delegated, or provider-held
- unattended restart is the dividing line
basics
~20 sThe protecting key must arrive from outside the store's own records: recombined from a threshold of shares held separately, unwrapped by a device or a separate key service the store authenticates to, or held by a managed provider that applies it for you.
solid answer
~50 sA store's records sit on disk as ciphertext, and the key that opens them cannot be one of those records — an attacker with the disk would take both. So every start-up has a moment where the process is up and answering nothing until that key is supplied from elsewhere. There are three broad shapes. The key can be split into parts at initialisation, with a threshold presented and recombined before the store serves. It can be kept on disk in wrapped form, with the unwrap delegated to a device that will not export keys, or to a separate key service the store proves its identity to first. Or a managed provider can hold it and apply it on the store's behalf, so the store never shows a locked state at all. Stores differ in which shapes they offer.
go deeper
Recall that a store's own files are encrypted and the key for them is not among those files, so something outside has to supply it when the store starts.
Explain the three supply shapes — a threshold of shares recombined, an unwrap delegated to a device or a key service, a provider that holds the key — and what each one needs available at start-up.
Show you have operated it: which shape your store used, whether a replaced node could come back with nobody woken, and what the first minute after a host failure actually looked like.
Treat it as a decision about who must be present before the estate can start, and price each shape against the recovery time the business has agreed to rather than against a security preference.
## The moment this question is about A secret store keeps its records on disk as **ciphertext**. Something has to turn that ciphertext back into values, and that something is a key — call it the **protecting key**, to hold it apart from the credentials the store keeps *for* other systems. The two are constantly confused, and they are not the same object: the protecting key opens the store, and a credential the store holds opens somebody else's database. The protecting key cannot be one of the store's own records, and it cannot sit in a plain file beside them. If it did, whoever took the disk would take both and the encryption would have bought nothing. That constraint creates a specific moment on every start-up: the process is running, the port is open, the storage is attached, and not a single read can be answered, because the one input the store needs has not arrived yet. ## Where the key can come from Every design answers the same question — *what, outside the store's own storage, supplies this key?* — and there are three broad answers. - **Recombined from shares.** The key is split at initialisation into parts, and a threshold of them must be presented and recombined before the store will serve. No single part reveals anything about the key, and nothing present on the host alone can open the store. - **Unwrap delegated.** The store keeps its protecting key on disk in **wrapped** form and asks something else to unwrap it — a device that will not export keys, or a separate key service. The store must first prove who it is to that thing, so the unwrap path becomes part of the start-up sequence. - **Held by the provider.** In a managed offering, the operator of the service holds the protecting key and applies it on the store's behalf. There is still a protecting key; you are simply not the one who supplies it, and the store never presents a locked state. Designs genuinely differ here, and several stores offer more than one shape as a configuration choice. Assuming that *every* store waits for a human after a restart is a common and expensive mistake, and so is assuming that none of them do. ## What each shape needs present | supply design | what must be available at start-up | unattended restart | what a stolen disk alone yields | |---|---|---|---| | threshold of shares | enough holders, reachable and willing | no | ciphertext only | | unwrap delegated | the device or key service, plus whatever proves the node's identity to it | yes | ciphertext only | | provider-held | the provider's service | yes — no locked state appears | ciphertext only | The last column is the same for all three, and that is the point worth saying out loud: the shapes differ in *who or what must be present to open the store*, not in how good the encryption is. ## What "supplied" does not mean - **It is not access control.** Once the store is open it answers every caller its rules allow. The protecting key defends against an offline read of the files, never against an authorised read. - **It is not a per-request step.** Once supplied, the key is held in the running process's memory and the store serves from there. That is why a memory capture on the host is a different threat from a stolen disk, and why re-locking usually means restarting or a deliberate operator action. - **It is not solved by a passphrase in the start-up configuration.** Putting the input in the file the service launches from is the same failure as putting it beside the data, moved one file over: anything that can read the host can start the store. - **It is not the credential a workload uses to read a value.** Those are issued to callers and have their own lifetimes; the protecting key exists only so the store can read itself. ## What an interviewer is listening for 1. **Name the moment.** The store can be healthy, reachable and completely useless, and the diagnosis is "it has not been given the key to its own contents" rather than "it is down". 2. **Name at least two shapes**, and say what each one requires to be present. A candidate who knows only the one their employer runs will describe it as how stores work. 3. **Say what stops being true.** A threshold of shares means no unattended restart. A delegated unwrap means the store cannot come back without the thing it delegates to. A provider-held key means there is no moment where you can withhold consent. 4. **Connect it to restart behaviour.** The whole reason this is asked is the unattended restart: node replacement, scaling and host failure all end at this step, and the design decides whether a machine finishes the job or a person has to.
- Once the store is serving, where does the key protecting its contents live?In the running process's memory, supplied or unwrapped once at start-up and held from then on. The store does not repeat the step per read, which is why re-locking generally means a restart or a deliberate operator action, and why reading process memory on the host is a different and far harder threat than taking the disk.
- How is this key different from a credential the store hands out to a caller?The protecting key exists only so the store can read its own ciphertext; nobody outside the store ever receives it. A credential the store holds or mints is meant to leave — it goes to a consumer and opens some downstream system. They have different lifetimes, different holders, and rotating one has nothing to do with rotating the other.
- Does encrypting the store's files mean an operator on the host cannot read values?No. Encryption at rest defends against an offline read — a stolen disk, a copied volume, a lifted backup. An operator on a running host can reach the serving process, and any caller the store's rules allow gets plaintext by simply asking. The protecting key is not an access-control mechanism.
saying these in an interview costs you the question
- Says the store keeps its protecting key in its own configuration file.
- Assumes every store starts locked and waits for a human to appear.
- Thinks encrypting the data files removes the need for a protecting key.
- Confuses the key protecting the store with a credential the store holds.
- Believes a managed provider means there is no protecting key at all.
- Claims supplying the key also decides which callers may read values.