The origin of the Merkle (hash) tree, the structure that makes inclusion and consistency proofs compact. The foundational primitive the whole field builds on.
link.springer.com/chapter/10.1007/3-540-48184-2_32
Audit logging and tamper-evident trails
Almost every serious system keeps a record of who did what, and when. The harder question is whether you can prove that record was not quietly edited later. This is the part of the field that answers it.
The goal is not to make a record unchangeable. It is to make a change impossible to hide.
A plain log file cannot tell you whether it was edited. Anyone with enough access can rewrite a past line, delete one, or insert one, and the file gives no sign. Audit logging and tamper-evident trails are the part of the field that fixes that, not by forbidding changes, but by making any change detectable.
Two ideas carry most of the weight, and both are simple to say. Append-only means you only ever add to the end, you never reach back and rewrite. Hash chaining means each new entry carries a short cryptographic fingerprint of the one before it, so the entries are linked like a chain. Change one old link and every fingerprint after it stops matching, and the tampering shows. Picture a guest book where each page is numbered and copies a short code from the page above. Tear out a page and the codes no longer line up. Make that code a cryptographic hash rather than a human scribble, and you have the core of the field. The rest of this page walks it: what it is, why it is hard, how it works, what it makes possible, and where it is going.
Two different jobs that often get the same name.
One is the operational practice of keeping logs. The other is a cryptographic property layered on top of them.
Audit logging is the practice: generate, transmit, store, and retain security-relevant records of system activity. The canonical statement of that management discipline is the NIST guide to log management NIST SP 800-92. Tamper-evidence is the property added on top: the log can prove it has not been altered.
Say the honest part plainly and early. The achievable goal is tamper-evident, not tamper-proof. You cannot stop a sufficiently privileged party from trying to alter a record. What you can do is make any modification, deletion, or reordering of past entries provable after the fact. The seminal secure-logging work frames the threat as an attacker who fully compromises the machine, and the realistic win is that entries written before that moment cannot be undetectably changed Schneier, Kelsey 1998.
A useful mental model from the literature names three actors: a logger that holds the records, clients that add entries, and auditors who challenge the logger to prove it behaved honestly. The design question that shapes everything else is how an auditor verifies the log without simply trusting the logger.
An edit breaks the link to trusted history
- 12Quote createdEntry and previous fingerprint are hashed
- 13Price revisedIncludes the fingerprint of entry 12
- 14Quote sentIncludes the fingerprint of entry 13
Separately held checkpointTrusted fingerprint after entry 14
Rewrite an earlier entry → recomputed chain no longer matches the trusted checkpoint.
The machine holding the log is part of the threat.
Access control alone is not enough, because the hard case is the administrator, the attacker with root, or the faulty service that already holds the access.
The classic hard case is an untrusted host: the very machine storing the log can reach the bytes on disk. Once a machine is fully compromised, you cannot protect entries written after the break-in, because the attacker controls the keys from that moment on. The achievable property is forward security: entries written before the compromise stay verifiable and cannot be silently rewritten. The original work does this with a one-way key that is advanced and never wound back Schneier, Kelsey 1998.
Then there is proving a negative, efficiently. An auditor wants to confirm that nothing in the past was removed or reordered, ideally without re-reading the entire log every time. A naive chain makes some checks grow with the size of the log, which does not scale to billions of entries. Closing that gap is what the tree-based work is for Crosby, Wallach 2009.
A subtler attack is a lying logger that shows one version of history to one observer and a different version to another, a split view, or fork. Catching it needs consistency proofs between versions and, often, gossip between observers. And tamper-evidence needs a trustworthy notion of order and time, so no single party can quietly back-date or forward-date an entry. The timestamping work that began with linked hashes is where that line starts Haber, Stornetta 1991.
What a compromised logger could change
- Delete
- Remove an event from the stored history.
- Rewrite
- Replace a previous event with a different value.
- Equivocate
- Present conflicting histories to different readers.
Keep a trusted checkpoint
A separately retained commitment provides something to verify against.
A stream of raw events becomes an ordered, verifiable structure.
A handful of primitives do the work: cryptographic hashes as fingerprints, a chain or a tree to link them, signatures and a one-way key for origin and forward security, and a published root that many independent observers can compare.
It starts with a cryptographic hash: a short, fixed-size value derived from data such that any change to the data changes the value, and you cannot feasibly find two inputs that share one. That is the primitive everything else is built on. In the linear case, each entry stores a hash of the previous entry's hash together with its own content, so the entries form a chain. Alter any past entry and every hash downstream of it stops matching, which localizes the break and makes it obvious. This is the linking idea behind digital timestamping, and the structural ancestor of later ledgers Haber, Stornetta 1991.
A flat chain does not scale to cheap proofs, so the field reaches for the Merkle tree: hash the entries pairwise up a binary tree until you reach a single value, the root, which is a compact commitment to the whole set Merkle 1987. Two proofs fall out. An inclusion proof shows a specific entry is in the log using only the few hashes along its path, on the order of the logarithm of the log's size. A consistency proof shows that a newer root still contains everything an older one did, so nothing earlier was changed or dropped. Extending this to an append-only log so both proofs stay logarithmic is the history tree Crosby, Wallach 2009.
Two more layers finish the picture. Entries or periodic checkpoints can be signed so their origin is provable, and an evolving, one-way key gives forward security: the key is used, then irreversibly advanced, so a later compromise cannot forge or rewrite earlier entries. And the current root, or signed tree head, can be published to many independent observers, so a logger trying to hide a split view would have to lie consistently to everyone at once. The standard that operationalizes this for the web's TLS certificates is Certificate Transparency RFC 9162, which obsoletes the original RFC 6962. Operationally, append-only is reinforced by write-once-read-many storage and by anchoring roots to an independent system, so the trail does not rest on the honesty of one machine.
Verify the chain against a checkpoint
h1 = H(seed, event1)
h2 = H(h1, event2)
h3 = H(h2, event3)- Edit event 2
Recomputing the chain changes h2 and h3.
- Compare the final commitment
The recomputed h3 differs from the retained checkpoint.
Merkle alternative
An inclusion proof checks one entry against a published tree root; a consistency proof checks append-only growth.
From "we keep logs" to "we can prove the logs are intact."
The payoff is the difference between asserting a record is accurate and being able to show it.
The first win is verifiable accountability. You can answer who accessed a particular customer record, and when, with a record that can be shown to be intact rather than merely asserted to be. The second is forensics: if a host is compromised, the pre-compromise trail stays trustworthy, which is exactly what an investigation needs, and the original motivation for the work Schneier, Kelsey 1998.
The third is compliance evidence. Audit trails are a named control in widely used frameworks. The NIST guide covers the management practice NIST SP 800-92, and the AICPA Trust Services Criteria used for SOC 2 reporting expect logging and monitoring of system activity AICPA TSC 2017. Tamper-evidence raises that bar from keeping logs to being able to prove they are intact. Named here neutrally, as part of the field's standards landscape, not as a claim about any one product's certifications.
Underneath all three is a single shift: inclusion and consistency proofs let an outside auditor verify behavior cryptographically rather than on the operator's word. That is the same move toward verify, do not just trust, seen across modern security.
An audit trail answers a concrete question
Audit question
Who exported the account record?
| Event field | Recorded evidence |
|---|---|
| Actor | user:184 |
| Action | account.export |
| Resource | account:482 |
| Time | 10:24:08 UTC |
| Integrity | Entry verified against retained checkpoint |
Transparency logs are becoming general infrastructure.
The pattern of a public, append-only, Merkle-backed, gossiped log is spreading from web certificates to software supply chains and beyond.
Compare signed checkpoints
Observer A
tree size: 128
root: 8ac1…Observer B
tree size: 128
root: f299…Conflicting history
Same log, same tree size, different signed roots.
The Certificate Transparency pattern is being generalized to software supply-chain artifacts, binary releases, and other domains where what was published, and when, has to be auditable. Append-only logs and verifiable maps are increasingly offered as reusable components rather than bespoke code, which lowers the cost of adding tamper-evidence to a system. Wider use of write-once storage and cross-system anchoring of roots means the integrity guarantee depends less on any single administrator.
Standards keep maturing: the Certificate Transparency lineage moved from RFC 6962 to RFC 9162, and the NIST log-management guide is in revision. The honest note to close on is the one the field itself states: none of this prevents a determined insider from corrupting a live system. It makes the corruption detectable and bounds what can be hidden. Saying that plainly reads as credibility, not weakness, and it is why the accurate word is tamper-evident, never tamper-proof.
The security review has a sharper question now.
Enterprise buyers and their auditors increasingly ask not only whether data is secure, but whether you can show, with evidence, who accessed a customer record and that the access history itself was not edited.
We wrote this page so a technical evaluator can understand that frontier on its own terms. As an example of where the idea naturally lands, a sales co-pilot that keeps one client's data isolated from another, adapts to one company's way of selling, or answers only from data a given person is allowed to see, becomes far easier to trust when the trail of those actions is itself verifiable. That is the outcome this page is about, described at the level of the field, not as a claim about any specific logging design. For our actual posture on logging, access controls, and data handling, the specifics live one click away: see Security. For the model itself, our own model, built for sales conversations, see Prism.
The six sources behind this page.
Introduces linking document hashes into a chain so nothing can be inserted, removed, or back-dated undetectably. The conceptual root of hash chaining.
link.springer.com/article/10.1007/BF00196791
The seminal secure-logging paper: defines the threat model of a fully compromised host and forward security, so pre-compromise entries cannot be undetectably altered. The honest "why it is hard."
usenix.org/conference/7th-usenix-security-symposium
The history tree: Merkle-based append-only logging with logarithmic inclusion and consistency proofs. The canonical scalable construction and the clearest "how it works at scale."
usenix.org/conference/usenixsecurity09
The standard for a large, widely deployed tamper-evident system: a public, append-only Merkle log with signed tree heads, inclusion and consistency proofs, and gossip to catch split views.
rfc-editor.org/rfc/rfc9162.html
The canonical operational standard for generating, protecting, retaining, and reviewing security logs. The "what is X" and compliance anchor that grounds the practice, not just the cryptography.
csrc.nist.gov/pubs/sp/800/92/final
More of the field, explained plainly.
Three more explainers from the same series, each a plain-language tour with links to the source papers.
Back to the research index.
Talk. Done.
You handle the conversation. Prism handles the note, the CRM, and the admin you dread. The easiest way to see it is to hear it.
No app required, just your phone number.