Evidence anchoring
also called audit anchoring · off-box anchoring · audit log anchoring · signed chain head
Anchoring exists because a symmetric key has a structural problem as evidence: where integrity rests on a message authentication code, the key that verifies the log is the key that can forge it. Hand it to an auditor and you have handed them the ability to fabricate the record they were given it to check — they cannot verify independently, and you cannot demonstrate that you did not. An asymmetric signature splits those powers: the installation signs with the private half, everybody else verifies with the public half, which turns an internal integrity check into something an outside party can act on.
The signed statement is short and every field is inside the signature, with no envelope the signer did not commit to: an installation identity, the anchor’s own sequence number, the digest of the previous anchor, the head being attested, the number of entries covered, the protection level the chain had at signing time, the creation time, the key identifier, the algorithm and the cadence. Anchors are chained and numbered contiguously, which turns a deleted anchor into a visible break rather than a re-numberable hole. Two validly signed anchors sharing a sequence with different heads are equivocation — a self-contradiction under the signer’s own key — and worth reporting under that name rather than as a broken link, which would send an auditor looking for a deletion that did not happen. Attested heads and entry counts may only move forward.
Publication is the property, not a delivery detail. An anchor that never leaves the database it attests is only as durable as that database, and a sink administered by the party who runs the database is not independent — deleting the anchors and the rows is then one action rather than two. Delivery should be at-least-once from a durable per-destination cursor that advances only after the sink acknowledges that exact anchor, so a crash replays an anchor rather than skipping one, and receivers must answer success to an anchor they already hold: a receiver that rejects a duplicate as a permanent error wedges the pipeline at that sequence, and every later anchor stops publishing while the local ledger keeps growing and looks healthy.
Two disciplines decide whether this is worth anything. The public key is an input to verification and must arrive out of band — a key ceremony, a published fingerprint, an earlier evidence export — never read from the file being verified, because a key defaulted from the artefact under examination lets an attacker ship their own key beside their own rewritten anchors and every check reports success. A file that does not begin at anchor 1 should be refused unless partial verification was requested explicitly: a ledger starting at anchor 4 is a deletion, not a shorter file. On the signing side the discipline is refusal: refuse to sign when the chain does not verify, when the head has moved backwards, or when an already-anchored entry no longer matches what was attested — signing over a forged head launders the rewrite under a key the auditor was told to trust, whereas refusing leaves the previous anchor standing, and that anchor still contradicts the rewrite. Token Observe implements this shape, and ships its verifier as a standalone script needing no database, network or installation, so an auditor can run it on a machine they may not install anything on.
Four things an anchor does not prove belong beside the claim. Key theft: anyone who can read the private key out of the process or the key store signs whatever history they like, so asymmetry moves the target rather than removing it. Pre-anchor history: the first anchor attests the head as it stood when it was made and says nothing about whether the entries beneath it were already honest, so anchoring, like keying, is strictly forward-looking — a month of delay is a month of history that will only ever carry a plain digest. Sink collusion: suppression is detectable only if a copy exists somewhere the installation cannot reach. And time: the creation time is inside the signature so it cannot be edited afterwards, but it is asserted by the signer at the moment of signing, and only a trusted timestamp authority or a public ledger establishes when.
Six months later, on a laptop with no access to the installation
An auditor holds two things: a file of monthly anchors they were sent as they were produced, and a public key they took down at the key ceremony. They run an offline verifier that loads no database, opens no socket and needs nothing installed. A pass tells them the holder of that key signed every anchor in the file, that the anchors are contiguous and correctly linked, that any key change was signed by both the retiring and the incoming key, and that attested heads only ever moved forward. If the installation now presents a chain whose entry 8,412 digests to something other than the value in the March anchor, the March copy is the one that was not in the hands of whoever made the change. What the pass does not tell them: that the history beneath the first anchor was honest, that the signer’s clock was truthful, or that nobody stole the key.
What evidence anchoring is routinely confused with
- Trusted timestamping (RFC 3161)
- A timestamp authority is a third party asserting that a given digest existed at a given moment. An anchor is the installation asserting what its own record contained, in a form you can keep. Anchoring answers what the log said as of the copy you hold; timestamping answers when a digest existed. Neither substitutes for the other, and an anchor’s own creation time is the signer’s assertion, not proof of time.
- Digest-sealed export
- A seal is an unkeyed digest over a bundle: it detects change and attributes nothing, because whoever can rewrite the bundle can recompute it. An anchor is signed, so verifying it does not confer the ability to produce one. The seal is about the file; the anchor is about the ledger.
- WORM or object-lock export
- Write-once storage prevents the copy being overwritten, which is a real control at the infrastructure layer. It proves nothing cryptographically, cannot be verified offline against a key, and depends on the retention policy being administered by somebody other than the party under audit. Anchoring and write-once storage are complementary: the signature makes the copy checkable, the storage makes it hard to remove.
Related terms
Tamper-evident
Tamper-evident describes a record whose alteration can be detected afterwards by whoever checks it. Tamper-proof would describe a record that cannot be altered at all — a property no scheme delivers over storage the alterer administers — so a claim of tamper-evidence means something only when it names the attacker it holds against and the check that would reveal the change.
Audit chain
An audit chain is a record of administrative actions in which every entry carries a cryptographic digest computed over its own content and over the digest of the entry before it, so the entries form one linked sequence rather than a set of independent rows. Editing, reordering or removing an entry breaks that sequence at an identifiable point, which is what lets the integrity of the record be demonstrated rather than asserted.
Hash chaining
Hash chaining is the technique of computing each record’s cryptographic digest over both its own content and the digest of the record before it, so that a change to any record changes its digest and invalidates every digest after it. It makes alteration detectable by anyone who recomputes the digests; it does not prevent alteration, and it constrains only an attacker who cannot recompute them.
Digest-sealed export
A digest-sealed export is an evidence bundle issued together with a cryptographic digest computed over the canonical serialisation of its contents, so that a recipient holding that digest from another source can recompute it and confirm the file has not changed since it was issued. The seal establishes integrity relative to a value the recipient already holds; it establishes nothing about origin, because anyone able to rewrite the bundle can recompute the digest.
Where Token Observe does this
The definition above is the field's, not the product's. This is the part of the product that implements it, for a reader who wants to see one.
The terms next to this one
What a record of an agent's actions proves, and the several places where a word in common use claims more than the mechanism delivers.
Definitions are the easy part.
The glossary is written to be useful whether or not you ever buy anything. If you have got to the point of deciding how to implement one of these in your own estate, say what your agents do and you will get a straight answer about what it would actually take.
no form · no qualification step · no sales desk · the other three ways in