A device verifies a firmware update's vendor signature but never compares the signed subject digest to the bytes it flashes. What has it verified?

## Indirection is the whole problem Modern artifact signing is rarely a signature laid directly across a file. It is a signature over a small **statement** that *names* the artifact by digest. An in-toto statement is the common shape: - `_type` — the statement schema; - `subject` — a list of entries, each with a name and a `digest` map such as `{"sha256": "..."}`; - `predicateType` and `predicate` — what is being claimed about that subject. The signature is applied to the envelope carrying this payload, separately from the payload itself. So a successful verification proves one thing: *the signing identity produced this statement*. Which real bytes the statement is about is a question the verifier has to answer for itself, by hashing the artifact in its hands and looking for that digest in `subject`. Miss that step and you have built a control that checks a document and installs a file, with nothing connecting them. ## What the gap buys an attacker A warehouse robot fleet takes firmware over the air. The controller downloads an update bundle, checks that the signature is valid and made by the fleet vendor's identity, and flashes the payload. It never hashes the payload. Now anyone who can substitute the payload between the check and the flash — an operator on the maintenance network, a contractor with physical access to a robot, a compromised staging cache — supplies their own firmware and reuses the vendor's genuine signature file unchanged. Verification is green, the vendor's key is untouched, and a fleet of machines that move at speed around people is running code nobody vouched for. The asset at risk here is not data; it is the safety of a physical process. Detached signatures make this failure natural. Signature and artifact are separate files, so the verifier must be *told* which artifact the check applies to, and it is easy to tell it one thing while the installer uses another. Formats where the signature lives inside the artifact container are less prone to it, because there is only one object to point at — though even then the installer must use the object it verified rather than fetching a fresh copy. ## Time of check, time of use Even a verifier that does the digest comparison correctly can undo it. Hash the file, match the subject, then re-download it, re-read it from a path another process can write, or unpack it and install from a directory that was rewritten in between, and the guarantee is gone: you verified one set of bytes and used another. The rule is that the bytes you hashed are the bytes you use — verify from a buffer or an immutable copy, and do not resolve the artifact a second time. ## Transport is not artifact integrity A frequent wrong answer is that fetching over TLS closes the gap. It does not. Transport security authenticates the server and protects the channel from outsiders; it says nothing about whether the object the server chose to send is the one the signature covers. If the mirror is compromised or misconfigured, the attacker is *inside* the channel and TLS carries their payload faithfully. Artifact integrity has to be established on the artifact, end to end from signer to consumer. ## The same failure as an audit problem The subject question also decides whether a signature can serve as evidence. Suppose a bank's release ledger records "signed by release-engineering" as proof that a specific build of an internal risk library shipped. If the signature covers a release manifest rather than the package bytes, the ledger proves that a manifest was approved — not what ran in production. An auditor asking "what code executed on this date?" can only be answered when there is an unbroken digest chain: the signed subject digest equals the artifact digest recorded at deploy time equals the digest of what the runtime loaded. Wherever that chain has a name in it instead of a digest, the evidence stops. ## The checklist a verifier owes you 1. The envelope's signature verifies against a key or identity you decided to trust. 2. The payload is a statement of the type you expected. 3. **The digest of the exact bytes you are about to use appears in that statement's `subject`.** 4. You then use *those* bytes, with no re-fetch, re-read or re-resolution between check and use. Step three is the one that gets skipped, and skipping it makes the other three decorative.