Tamper-evident

The two words differ in who acts and when. Prevention stops the change; evidence catches it afterwards, and only if somebody looks, and only if they have something to look against. Almost nothing in software is tamper-proof, because the storage is administered by somebody, and that somebody can write to it. A vendor using the word about a database their own product also writes to has either not thought about it or is hoping you will not. The useful form of the claim is conditional and specific: this alteration, by this actor, would be detected by this check.

For a plain hash chain the conditional is exact. It detects every alteration that does not also recompute every downstream digest. That covers a great deal of what actually happens to a database — accidental corruption, a restore that lost its tail, a migration that rewrote a column, an injection that reaches one row, an operator who edits the row they care about and does not know the rows are linked. It does not cover the party who can write every row, and that party is in the threat model by definition whenever the reason for the log is to hold administrators to account. This is why a verification result that reports only valid is under-informative: on an unkeyed chain, valid means nothing was altered without recomputing, which is a materially weaker statement than nothing was altered, and the result should say which of the two it is entitled to.

Each further mechanism moves the target somewhere specific rather than removing it. Keying the digests, so that entries are authenticated under a key held outside the store, moves it from whoever can write the database to whoever holds the key — and holds only if the key comes from a secret manager the database administrator cannot read. Sealing the head with a keyed checkpoint extends that backwards over history written before the key existed, at the level of the head rather than the individual row. Signing a statement of the head and publishing it off the box moves it again, to whoever holds the signing key and can also reach every copy you took. Write-once storage or object lock is a genuine complementary control at the infrastructure layer, and it proves nothing cryptographically and cannot be checked offline. None of these steps reaches tamper-proof, and the honest way to present them is as a ladder with the residual named at each rung.

Three things stay invisible to any in-store scheme, and they are the ones to plan around. Truncation where nothing is written afterwards leaves every surviving link honest. An attacker willing to edit the sequence counter as well can hide a deletion that would otherwise leave a hole. And host compromise — reading the key out of the process environment or the key store — signs or authenticates anything the attacker likes. The first two are answered outside the store, by a head sequence and digest recorded elsewhere before the event, or by an off-box signed anchor. The third is not answered at all, and should be stated as out of scope rather than argued away.

The word also fails people through tooling, in a way worth designing against. A missing key and an altered entry produce the same bytes: the digests do not match. One of those is a configuration mistake an operator made five minutes ago; the other is an accusation of tampering. A verification result that reports the second when the first is the likelier explanation makes the product accuse its own operators of the exact act it exists to detect, over a dropped environment variable — so where a failure occurs at or after a sequence that a keyed checkpoint seals, and this process holds no key, the result should say the key is suspected missing and label that a diagnosis rather than proof.