Tamper-evident audit log

Note the word: tamper-evident, not tamper-proof.

Anyone with sufficient privilege on a machine can modify a file on that machine. A local log cannot prevent that and should not claim to. What it can do is make the modification impossible to hide — and that is a genuinely achievable property, which is why it is the one worth claiming.

How chaining works

Each record includes a hash of the record before it. Records therefore form a chain, and each hash depends on the entire history preceding it.

Alter one record and its hash no longer matches what the next record expects. That mismatch cascades: every record after the altered one fails verification. To hide the edit you would need to recompute the whole chain from that point forward — and if the chain’s head is anchored somewhere you do not control (in BitShout’s case, the macOS Keychain), recomputing it locally does not help.

The result is not “you cannot change the log”. It is “you cannot change the log and have it still verify”, which for forensic purposes is the property that matters.

Append-only, and what “clearing history” must mean

A tamper-evident log that supports deletion has a contradiction in it. If retention or a “clear history” action can remove records, then removing records is a supported operation and the guarantee is gone.

The resolution is generations. Clearing history does not delete the past; it closes the current generation, opens a new one, and writes an explicit marker record saying what happened. The record of the deletion is itself part of the record.

Vocabulary is an integrity property too

An audit log’s usefulness depends on its words meaning one thing each. The distinctions that matter most for a containment system:

Observed fact            ≠ policy decision
Policy denied            ≠ operating-system denied
Authorization approved   ≠ action executed
Brokered success         ≠ credential released
Evidence present         ≠ authority granted
Missing evidence         ≠ permission granted

A log that records “blocked” for something its policy engine merely decided should be blocked has perfect cryptographic integrity over a claim that is not true. Integrity of the container does not confer accuracy on the contents.

Why it should not become a second problem

An audit trail full of file contents, command lines and network payloads is a privacy liability that did not exist before you started logging. Redaction has to run before records are written rather than before they are displayed, storage should be local by default, and export should be an explicit action rather than a background upload.

See audit and security evidence for the full model.