The Honest Way to Prove an Audit Log Was Not Altered, Offline

• A bare hash chain is corruption-evident, not authentic: anyone who can write the file can rewrite history and recompute it clean.
• Authenticity comes from an Ed25519 signature over a checkpoint held off-box, plus a monotonic watermark that rejects rollback.
• SHA-256 is self-contained and proven against the FIPS 180-4 known-answer vectors; a four-lens review produced five findings, all fixed.

I asked for unbreakable. The honest answer made it stronger.

I asked the team to make our audit ledger unbreakable. They came back and told me no, and they were right to. There is no such thing, and any vendor who sells you the word is selling you a feeling, not a mechanism. What they offered instead was better: a ledger where silent, undetectable alteration is not possible, and where every honest limit is stated out loud.

That distinction became a design principle. We stopped chasing a word we could not defend and started building a property we could prove. The property is tamper-evidence: alterations are detectable, verification runs with no network, and the boundary is written on the tin. Honesty is not a caveat we bolt on at the end. It is the security model.

The Open Audit Record is the append-only ledger inside SIOS, and it draws a hard line between what a hash chain gives you and what it does not. If you run regulated, offline, sovereign systems, the difference between corruption-evident and authentic is the difference between a log you hope is intact and one you can stand behind.

What a hash chain gives you, and what it does not

The Open Audit Record is an append-only, hash-chained ledger. Each record commits to the hash of the record before it, all the way back to a fixed genesis value. We write before we act: the rule is seal, persist (write and fsync to append-only storage), then act. If the machine dies mid-action, the intent is already on disk.

A chain like this catches accidental corruption and casual tampering. Flip a byte in an old record and every hash downstream stops matching. That is real and useful. It is also not enough, and pretending otherwise would be the exact dishonesty we are trying to avoid.

Here is the limit we designed around. There is no secret in the chain. A person who can write to the ledger file can edit, reorder, insert, or truncate history and then recompute the chain forward from the point they touched. The result is fully self-consistent, and a naive verify() that only checks internal links would accept it. A hash chain proves the file has not been corrupted. It does not prove the file is the real one.

Authenticity lives outside the ledger

Authenticity has to come from something an attacker cannot forge and cannot reach. So we anchor it outside the ledger entirely. The operation is sign_head(). It first verifies the chain, then signs a checkpoint with an Ed25519 key. The checkpoint commits to four things: the genesis value, the chain length, the head hash, and a Merkle root recomputed from the record contents.

That checkpoint is then stored off-box and append-only. A write-once medium, a separate tier the running system cannot rewrite, or even a printed receipt. The point is that the attacker who owns the ledger file does not own the checkpoint, and cannot produce a new one, because they do not hold the signing key.

This is where the one strong claim we are willing to make earns its keep. The record is tamper-evident and cryptographically verifiable relative to a signed checkpoint held where an attacker cannot rewrite it. Every word in that sentence is doing work, and none of it overreaches.

How verification actually runs, with no network

A verifier does two things, both offline. First, verify_signed_head checks the checkpoint's signature against a trusted public key. A checkpoint that was not signed by the real key is rejected before anything else happens. Second, verify_against confirms the live chain is exactly the one the checkpoint attests: same genesis, same length, same head hash, same Merkle root.

Then the anti-rollback watermark does its work. verify_against also requires the chain to be no older than the highest checkpoint the verifier has already accepted. This is a monotonic watermark, so replaying an old but genuinely signed checkpoint to roll the ledger back in time is rejected.

Trace the attacks through. Forgery fails, because the attacker cannot sign a checkpoint. Reordering and truncation fail, because the head hash, length, and Merkle root no longer match. Rollback fails, because the watermark has already moved past it. The tests prove it rather than assert it: a fully self-consistent forged chain passes bare verify() and then fails verify_against a genuine checkpoint, a truncated chain fails on length, and an older genuine checkpoint is rejected by the watermark.

The cryptographic core, kept small on purpose

The core that does all of this is dependency-free, forbids unsafe code, and does no I/O. That is deliberate. A verifier you can read in an afternoon and run on an air-gapped machine is worth more than one that pulls in a supply chain you cannot audit. Fewer moving parts, fewer places for something to hide.

The SHA-256 is self-contained and proven against the FIPS 180-4 known-answer vectors: the empty input, the string abc, the two-block case, and the one-million-a case. We use it as a plain hash, not as a secret-prefix MAC, so the length-extension weakness of that construction simply does not apply. The Merkle tree domain-separates leaves from internal nodes, a deliberate construction choice.

None of this leans on secrecy for its integrity guarantee. The security comes from the Ed25519 signature and where the checkpoint is held, not from hiding how the hashing works. You can read every line and the guarantee still holds.

Four lenses, five findings, all fixed

We validated the design with a four-lens adversarial review, each lens attacking a different surface: the chain structure, the hashing and canonicalisation, the Merkle tree, and the checkpoint and API. Splitting the review this way stops a single reviewer's blind spot from becoming the system's blind spot.

The review produced five findings. All five are fixed. It also cleared the SHA-256 implementation, confirmed the absence of length-extension exposure given how we use the hash, and confirmed the Merkle domain separation. We would rather tell you there were five findings than imply there were none. A design that never found a problem was never really examined.

This is what auditability looks like from the inside. Not a badge, but a trail of specific weaknesses, specifically closed, that someone else could re-run.

Why the verification mechanism sits in our filed estate

We patent the mechanism, not the models. Across SIOS that means how sovereignty, auditability, licensing, and orchestration are enforced, and the Open Audit Record's verification path is squarely in that category. The novelty is not a hash chain, which is old and public. It is the combination: seal-persist-act ordering, a signed off-box checkpoint that commits to genesis, length, head, and a Merkle root, and a monotonic watermark that turns rollback from a silent success into a rejected input.

That combination is part of our filed estate. MICKAI has 104 filed patent applications carrying 2,340 claims in total, all patent-pending, and the enforcement mechanisms behind auditable, offline, sovereign operation are represented among them. We protect how the guarantee is produced and checked, never any AI model, and we run our own sovereign in-house models under our own names.

For customers in regulated and air-gapped settings, that matters in a practical way. The thing you are relying on to prove your logs is a mechanism we have committed to in the open and filed on, not a black box we could quietly change and deny later.

Questions people ask

How do you prove an audit log has not been altered with no internet connection?

You verify a signature offline. The ledger is hash-chained for internal consistency, and a checkpoint (its genesis, length, head hash, and Merkle root) is signed with an Ed25519 key and held off-box. A local verifier checks that signature against a trusted public key, confirms the live chain matches the checkpoint exactly, and rejects anything older than the highest checkpoint it has already accepted. No network is involved at any step.

If it is just a hash chain, why can't someone rewrite it?

They can rewrite the chain, and that is the honest point. A hash chain has no secret, so anyone who can write the file can edit history and recompute forward into a self-consistent result that a naive check accepts. What they cannot do is produce a matching checkpoint signed by the Ed25519 key they do not hold. The signed, off-box checkpoint is what makes rewriting detectable rather than silent.

What exactly can an attacker still do?

They can delete the ledger file or refuse to run the verifier. We do not hide that. Tamper-evidence means alterations are detectable, not that the bytes are indestructible. The difference is that destruction and refusal are conspicuous and provoke questions, whereas silent alteration is not possible. Frequent checkpoints shrink the only window that exists, which is activity since the last checkpoint the verifier actually witnessed.

Why won't you call it tamper-proof or unbreakable?

Because it would not be true, and honesty is the product here. No ledger is unbreakable: files can be destroyed and verifiers can be refused. We make the claim we can defend, that the record is tamper-evident and cryptographically verifiable relative to a signed checkpoint held where an attacker cannot rewrite it. Naming a stronger word would mislead the exact people who most need to trust the mechanism.

Does the anti-rollback watermark stop replay of an old, genuine checkpoint?

Yes. The watermark is monotonic. verify_against requires the chain to be no older than the highest checkpoint already accepted, so replaying a real but stale checkpoint to roll the ledger back in time is rejected. Combined with the signature check, this closes forgery, truncation, and rollback. The tests bear that out: a forged self-consistent chain fails verify_against a genuine checkpoint, a truncated chain fails on length, and an older genuine checkpoint is rejected by the watermark.

Why does self-contained crypto matter for sovereign deployments?

Because you can audit and run it on an air-gapped machine with nothing to trust but the code in front of you. The core is dependency-free, forbids unsafe code, and does no I/O. Its SHA-256 is proven against the FIPS 180-4 known-answer vectors and used as a plain hash, so length-extension does not apply, and the Merkle tree domain-separates leaves from internal nodes. Fewer moving parts means fewer places for a weakness to hide.