When a settlement signing key is generated inside a device that will not export it, what crosses the boundary on each signature?
answer
- the key stays put
- computation goes where the key is
- a handle, not key material
- digest in, signature out
- copying stopped, invocation not
basics
~20 sOnly 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.
solid answer
~40 sThe device generates the key pair internally and marks the private half non-exportable at generation, so there is no interface that hands it back. Signing therefore happens where the key is. On each signature the service authenticates to the device with a credential of its own, passes a `handle` that names which key to use, and passes the input — usually the digest of the settlement instruction, though some interfaces take the payload and digest it inside. Back come a signature and a status. What the service holds in memory is a credential and a reference, not key material: useful only while the device answers and the credential is valid. That is the whole reduction — copying is stopped, and invocation by an authorised caller is not.
code
pseudocode · 10 lines// the service never receives key material
session = device.authenticate(serviceCredential)
handle = session.open(keyLabel = "settlement-signing")
digest = hash(instruction) // computed in the service
signature = session.sign(handle, digest) // computed inside the device
send(instruction, signature)
// the branch that does not exist for this key:
session.export(handle) // refused - key was generated non-exportablego deeper
Remember the shape: the key is made inside a device that will not hand it out, so the service sends what needs signing and gets a signature back. Nothing secret is copied into the service.
Be able to list what crosses the boundary in each direction — a credential, a handle, a digest going in; a signature and a status coming back — and say what the service is left holding if someone reads its memory.
Show that you plan for the consequences: a synchronous dependency in the settlement path, a finite operation rate at peak, and the fact that the device's guarantee covers copying and not invocation.
Frame it as buying one specific property at a known cost, and be able to say where that trade stops paying — high-rate keys, keys you can re-key in an afternoon, and estates where the device becomes a single failure domain.
## The inversion that defines hardware-backed custody The ordinary way a service signs something is to obtain key material and compute with it: read the private key from a file or a store, load it into process memory, call a signing routine, and keep the bytes until the process exits. **Hardware-backed custody inverts that.** The key pair is generated *by* the device, inside it, and carries an attribute set at generation saying the private half may never leave. There is no interface that returns it — not in the clear, not under a passphrase, not to an administrator of the device. Because the material cannot come to the computation, the computation goes to the material. ## What actually crosses on each signature 1. **Authentication.** The payments service proves which identity it is, using a credential of its own that the device recognises. 2. **A reference to the key.** A `handle` or label naming *which* key inside the device to use. It is not the key and it is meaningless against any other device. 3. **The input.** Usually the digest of the settlement instruction; some interfaces accept the whole payload and digest it inside. Either way the input travels *in*. 4. **The result.** A signature and a status travel back out. What never crosses is the private key or any encoding of it. ## What the service is left holding - A **credential** that authenticates it to the device. - A **handle**, valid only against that device, for that key. - The **public verification half**, which is not a secret. So an attacker who reads the service's process memory, its disk or its configuration gets a credential and a reference. Those are worth having — they buy signatures — but they expire, they can be revoked at the device, and every use of them is an operation the device counts. That is a precise and real change in blast radius: *"the attacker has the key, forever, anywhere"* becomes *"the attacker can obtain signatures while they keep access to a box that records every one."* ## Where the guarantee stops | Concern | In-device generation with no export | |---|---| | A copy of the key taken off the host, or found in a backup, image or log | Stopped — there is no copy to take | | An administrator walking away with the material | Stopped for material; not for access | | A caller with a valid credential asking for a signature | **Not stopped** — that is the device working as designed | | A bug in the service that submits an instruction nobody authorised | **Not stopped** — the device signs a digest, it has no view of authorisation | | Everything already signed becoming suspect after an intrusion | **Not stopped**, though the scope is bounded by the invocation record | The candidate failure here is to credit the device with stopping misuse. It stops *copying*. Misuse is bounded by the credential, the device's own access rule, and the code path that decides what gets submitted. ## The costs the inversion buys - **Latency per operation.** Signing is no longer an in-process call; it is a round trip to a box, with session setup on the first call. - **A finite operation rate.** The device sustains some number of operations per second and no more, and that ceiling has to be planned against peak settlement volume rather than average. - **A synchronous dependency.** If the device is unreachable, settlement instructions cannot be signed. The signing path inherits the device's availability, so redundancy is part of the design, not an afterthought. - **Backup becomes a design problem**, because the property that makes the key safe is exactly the property that prevents you copying it somewhere safe. ## Provenance is a separate claim "Generated inside the device" and "held inside the device" are different statements. A key generated on an ordinary machine and then imported carries the no-export attribute from the moment of import onward, but anything the generating machine left behind — swap, a temporary file, a backup, an operator's terminal — is untouched by it. When the distinction matters, what closes it is an attestation: a signed statement from the device about where the key was born and which attributes it was given. Without that, "it is in hardware" is a claim about the present, not about the key's history.
- The device returns a signature in a few milliseconds — why does that still change capacity planning?Because it is a synchronous round trip to a shared box with a finite operation rate, not an in-process call. Peak settlement volume, not average, sets the requirement, and the signing path now inherits the device's availability. Plan spare capacity and a second device, and measure queueing at the device rather than assuming signing is free.
- If the key was generated elsewhere and imported into the device, what changes?The no-export attribute only bounds copies made from the device onward. Whatever the generating machine left behind — a file, swap, a backup, an operator's screen — is outside that guarantee, so you cannot claim the material exists in exactly one place. Only in-device generation, ideally evidenced by an attestation, supports that claim.
- Why does the service still need a credential of its own if it holds a handle?The handle is a reference, not authority. The device decides whether to act on it by authenticating the caller and checking its own rule about which identities may invoke which key for which operation. A handle taken from the service's memory is useless without a credential the device will still accept.
A notary will stamp your document but will not lend you the stamp: you bring the page to the counter. Nobody can walk off with the stamp, and whatever the counter will stamp for you, it stamps.
saying these in an interview costs you the question
- The service downloads the key from the device into memory for the signing run
- Generating the key inside the device also guarantees nobody misuses it
- A handle is as good as the key, so protecting the service's credential adds nothing
- Signing inside the device is free, so there is no operation rate to plan for
- Importing a key into the device makes the copies on the generating machine irrelevant