Evidence, explained mechanically
The hash-chained audit trail: how tamper-evidence actually works
A signing ceremony produces a story — who was asked, how they proved identity, what they signed. The audit trail keeps that story, and the hash chain is what stops anyone from rewriting it afterwards.
What the trail records
Every meaningful event of an envelope's life: creation, document upload, recipient additions, identity codes issued and confirmed, the ceremony opening, fields placed, the signature drawn, completion, delivery. Each row carries its own timestamp and is bound to the envelope it belongs to.
The chain, mechanically
Each row carries the SHA-256 hash of the row before it, computed together with the row's own canonical bytes — so row N's fingerprint commits to everything from the beginning of the log through row N-1 plus row N itself (SHA-256 is specified in NIST FIPS 180-4). The first row's chain starts from a seed derived from the envelope's own identifier, so the chain is anchored to that envelope and nothing else.
The consequence is one-directional: change any row — even one character of a timestamp — and that row's recomputed hash no longer matches what the later rows committed to. The tampering is detectable without trusting anyone's word that the log is intact.
How it is verified
Verification is recomputation, not inspection: take the rows, recompute each hash, compare with the chain as stored. A mismatch anywhere means an edit somewhere. In Signattio the chain travels inside the sealed evidence certificate in the PDF, so the recomputation is available to anyone holding the document — no account, no trust in the vendor required.
Chain versus ledger
A linear hash chain is not a blockchain: there is no distributed consensus and no token, because there is a single authoritative service producing the rows. What the chain buys is exactly the property a dispute needs — unilateral edits to the record are detectable — while the PDF's own PAdES signature and trusted timestamp anchor the whole package to a time that does not depend on the service's say-so.
The honest limit: a hash chain proves the record has not been altered since sealing; it does not prove the events happened as written. That proof comes from the design around it — identity checks, ceremony records, and the fact that the seal itself is verifiable independently.
Sources
- NIST FIPS 180-4 — Secure Hash Standard (SHA-256).
- RFC 3161 — TSP Time-Stamp Protocol (Adams, Cain, Pinkas, Zuccherato, 2001).
- Regulation (EU) No 910/2014, articles 41 and 42 — CELEX 32014R0910.
- The Signattio product documentation (the /docs section of this site).
This is an explanation of the technical record, not legal advice.
Read next
The evidence layer inside the PDF: the PAdES levels.
Inside the timestamp token that anchors the chain in time.
Where the trail's rows come from, stage by stage.