skip to content

A device attests that your settlement signing key was generated inside it — what does that statement actually prove?

level: seniorimportance: nice to knowfreq 26%

answer

  1. a signed statement about birth
  2. provenance, not behaviour
  3. binds one public half only
  4. verify with an independently obtained key
  5. silent on who may invoke

basics

~20 s

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.

solid answer

~50 s

It is a statement about the key's birth, signed by an identity the device holds and which chains to something the manufacturer vouches for. It binds a public half to the assertions that its private counterpart was generated inside the device, was marked non-exportable, carries a stated usage constraint, and was created at a given moment on a device of a given model and firmware state. What it does not assert: that the caller invoking the key is legitimate, that the device's access rule is sensible, that any particular signature was authorised, or — strictly — what the attributes are *now*. And it only means anything if you verify it with the issuer's key obtained independently. An attestation you fetch from a device and verify with a key that same device handed you proves nothing.

code

json · 12 lines
json
{
  "attestedPublicKey": "b3f1a9...",
  "generatedInside": true,
  "exportable": false,
  "usagePolicy": ["sign"],
  "deviceSerial": "D-4471",
  "deviceModel": "signing-appliance-2",
  "firmwareState": "measured-ok",
  "generatedAt": "2026-04-02T09:14:00Z",
  "signedBy": "device-identity-key",
  "signature": "9ac2d0..."
}

go deeper

for a junior

Recall that an attestation is a signed claim about where a key was created and what it was allowed to do — not a claim about how it has been used since.

for a middle

List what the statement binds: one public half, in-device generation, the attributes set at generation, the device and firmware state, and a time. Then say what it is silent about.

for a senior

Show that you know the verification step is the load-bearing one, and that an attestation captured but never stored outside the device answers nothing when an incident asks about provenance.

for a principal

Decide which key classes must carry evidence of provenance at all, who holds the independent verification keys, and what your answer is when a supplier will not attest.

## What an attestation is An attestation is evidence for a claim you would otherwise have to take on trust. The claim is *"the private half of this public key was generated inside this device and given these attributes."* The evidence is a signed statement produced by an identity key that lives in the device and was placed there by its manufacturer, so that verifying the statement chains back to someone who is prepared to vouch for the device being genuine and behaving as specified. It matters because "the key is in hardware" is otherwise an unverifiable assertion by whoever configured the thing. A key generated on a laptop and imported ten minutes later looks identical from the outside. ## What the statement binds - The **public half** it is about, so the statement cannot be transplanted onto a different key. - **Where the private half was generated** — inside this device, rather than imported. - **The attributes set at generation**: non-exportable, and the operations the key may be used for. - **Which device**: a model, a serial, and often a measurement of the firmware state at the time. - **When**, so the claim can be placed against the device's own history. - A **signature** from the device's identity key, which is the part that makes it evidence rather than a label. ## What it does not say - **Nothing about invocation.** It says the key cannot be copied out. It does not say who may ask for a signature, and the access rule that decides that is configuration the attestation never touches. - **Nothing about any particular operation.** An instruction signed with an attested key is signed with an attested key; whether it should have been signed is a property of your submission path. - **Nothing about the present, strictly.** It is a statement about the moment of generation. Designs differ in whether attributes can be changed afterwards — in some, the non-export flag is fixed for the life of the key; in others, attributes are mutable by an administrator. Which one you have is a property of the device, and the attestation is not where you learn it. - **Nothing your own trust does not supply.** It is worth exactly what the vouching chain is worth. A compromised device, or a manufacturer identity you have no independent reason to trust, produces attestations that verify perfectly. ## Verifying it is the part teams get wrong The common failure is circular: fetch the attestation from the device, fetch the verification key from the same device, verify, declare success. That checks only that the device is self-consistent — which an attacker who controls it can arrange. The verification key has to arrive through a channel independent of the device: obtained from the manufacturer directly, pinned at procurement, or held in a trust store you maintain. Everything the attestation is worth rests on that one step. The second failure is verifying it once at provisioning and then never recording it. Six months later, nobody can say whether the settlement key was generated in the device or imported, which is precisely the question an incident asks. ## Where it is worth asking for one For a settlement signing key, the attestation is what supports every downstream claim you would like to make: that there is no copy to find, that the scope of an incident is bounded by invocations rather than unbounded, that an auditor asking "can this key leave the device" gets an answer with evidence behind it rather than a screenshot of a setting. That is a narrow but genuinely load-bearing role, and it is why the sequence matters: **generate inside, attest at generation, store the attestation outside the device, verify it against an independently obtained key.** Do those in a different order and you have a document rather than evidence.

  • Why is verifying an attestation with a key the device supplied worthless?
    Because it only shows the device agrees with itself, which anyone who controls the device can arrange. The verification key must come from the manufacturer or a trust store you maintain, independently of the device being assessed. That independent channel is where the attestation's whole value lives.
  • An auditor asks whether the settlement key can leave the device. What do you show?
    The attestation captured at generation, verified against an independently held key, plus where it is stored and when it was last verified. A configuration screen showing a non-export setting is an assertion by whoever configured it; the attestation is evidence that chains to the manufacturer.

saying these in an interview costs you the question

  • An attestation proves the signatures made with that key were authorised
  • Verifying it with a key the same device handed you is enough
  • It guarantees the device's access rules are correctly scoped
  • It is a live statement about the device's state right now
  • Any device can emit one, so it adds nothing over a configuration screenshot