etminanNearly every file-integrity monitoring (FIM) tool describes itself as “tamper-proof.” It's on the box for AIDE-style checkers, for commercial FIM modules bolted onto endpoint suites, for compliance dashboards. The word is doing an enormous amount of marketing work — and for the threat most people actually worry about, a root-level compromise, it is usually not true. Worse, the gap is not a bug in any one product. It's structural, and once you see the shape of it you can't unsee it.
This post is about the difference between what “tamper-proof” sounds like and what it takes to earn it. Short version: you cannot make a compromised machine unable to change its own files. What you can do is make those changes impossible to hide from something the machine can't reach. That requires a root of trust in hardware and a verdict rendered off the box — not a cleverer program running on the same host.
The claim, and what root actually does to it
Classic FIM — AIDE, Tripwire, Samhain — works one way: a program on the host hashes the files you care about, compares them against a local database of known-good hashes, and raises an alarm if something changed. That reliably catches the honest failure: a botched deploy, a hand-edited config, a package that drifted. It's genuinely useful for that. The trouble starts the moment the adversary is not an accident but an attacker with root.
What the tool reports
“All monitored files match the baseline. No unauthorized changes detected.” The scheduled scan ran, the hashes matched, the dashboard is green.
What actually happened
The attacker replaced /usr/sbin/sshd, ran aide --update to
bless the new hash into the local database, and edited the cron job so the next compare
never fires. The green dashboard is telling the truth — from its own corrupted point of view.
The database and the code that raises the alarm both live on the machine being watched. A root compromise sits above both. It can recompute the baseline, silence the check, or make sure the alarm never leaves the host. The tool did exactly what it was designed to do; the design just assumed the host would tell the truth about itself. Once root is gone, that assumption is gone with it.
Tamper-evident is the honest word
Here's the distinction the marketing tends to collapse, kept apart:
- tamper-proof
- Changes cannot be made. For software on a general-purpose host under a root adversary, this is not achievable — root can change anything, including the watcher. Treat the word, applied to on-host software, as a red flag.
- tamper-evident
- Changes cannot be hidden. You don't stop the tampering; you guarantee that any tampering is detectable by something outside the attacker's reach. This is the honest, achievable target — and it is genuinely strong when the “something outside” is real.
Every credible integrity system is aiming at the second one, whether or not its brochure says so. The only question worth asking a vendor is: evident to whom, and can the compromised host interfere with that party? If the answer is “a log file on the same host” or “the same agent that took the measurement,” the tamper-evidence is theatre.
Three things genuine tamper-resistance requires
To make a change impossible to hide, three properties all have to hold at once. Miss any one and root slips back above the watcher.
A measurement the host can't rewrite
The record of what ran must be append-only in hardware, not a file root can edit. A TPM Platform Configuration Register is extend-only: new value = hash(old ‖ new). You can't walk it backwards to erase an entry.
Evidence signed by a key the host can't extract
The measurement must be signed by a key that never exists in software. A TPM attestation key's private half never leaves the chip, so a compromised OS can't forge a clean, freshly-signed statement — it can only relay the real one.
The verdict rendered off the box
The decision “is this host trustworthy?” must be made somewhere the host can't touch. If the alarm can fire only on a separate machine, root on the monitored host has nothing local to silence.
Notice that all three are about moving trust off the thing being trusted. That's the whole game. A better hashing algorithm, a stealthier agent, a tamper-resistant local database — none of it changes the fact that root is above local software. Only hardware the OS can't rewrite, plus a decision made elsewhere, does.
Where the root of trust actually lives
In Etminan those three properties map onto concrete machinery. Linux's IMA (Integrity Measurement Architecture) hashes executables and files as they're opened and extends each hash into TPM PCR 10 — that's requirement 01. Each cycle a separate verifier sends a fresh random nonce and asks the host's agent for a quote: a TPM-signed statement of the current PCR values with that nonce folded in, signed by an attestation key whose private half never leaves the TPM — requirement 02. The agent hands back the quote plus the human-readable IMA measurement log, and the verifier — a separate, independently administered device — does the deciding: requirement 03.
The load-bearing step is that the verifier replays the IMA log and recomputes PCR 10, then checks the result against the value the TPM just signed. That binds the readable list of “exactly which files were measured, and their hashes” to the cryptographic quote. The host can't hand over a tidy log that disagrees with the signed PCR, and it can't forge a clean freshly-nonced quote, because the signing key is sealed in hardware. The nonce means the answer can't be a replay of a clean quote captured before the compromise. The host is reduced to a relay: it can refuse to answer, but a host that goes silent is a host raising its own alarm.
A pleasant consequence: verifying a quote is pure signature math over data the agent already sent — a public-key check, a nonce comparison, a hash replay. So the verifier needs no TPM of its own. The machine that makes every trust decision is a plain, self-contained binary, deliberately a different kind of machine from the ones it watches. There's a whole separate post on why that's true.
A checklist to hold any “tamper-proof” FIM to
You don't need to trust anyone's brochure, including ours. Five yes/no questions separate real tamper-evidence from a green dashboard that a root compromise can paint any colour it likes:
| Ask your integrity tool… | Classic on-host FIM | Hardware-rooted, off-box |
|---|---|---|
| If root re-blesses the baseline, can a change be hidden? | Yes — hidden | No |
| Is the measurement record append-only in hardware? | No | Yes (PCR) |
| Is the evidence signed by a key the host can't extract? | No | Yes (TPM AK) |
| Is the alarm decision made off the monitored host? | No | Yes |
| Is drift operator-approved, never auto-accepted? | Usually auto | Yes, signed & logged |
The last row matters more than it looks: an integrity tool that quietly auto-accepts “routine” drift trains itself to normalise the one change that matters.
Etminan proposes drift and never auto-accepts it — a new or changed measurement lands in a pending queue and joins the trusted baseline only when an operator approves it, signed with an Ed25519 operator key and appended to a hash-chained audit log. There is no auto-approve path to disable, because there was never one to begin with.
The honest boundary
A hardware root of trust is strong, not magic. Stating where it stops is the part that makes the rest believable:
- It defends against remote and software-level root compromise — an attacker who gains privileged code execution over the network. That is the common case, and it is exactly the case classic on-host FIM fails.
- It does not defend against physical attacks — cold-boot, evil-maid, desoldering or interposing the TPM. If the adversary is at the machine with tools, this is not your control.
- It does not cover below-TPM firmware implants or a compromised hypervisor presenting a virtual TPM — if the layer beneath the TPM is lying, the TPM signs a truthful signature over a lie.
- Denial of service is detectable, not preventable — a host can refuse to answer, but silence is itself the alarm.
So the honest claim isn't “tamper-proof.” It's tamper-evident against the threat that actually keeps people up at night, with the evidence anchored in hardware the host can't rewrite and rendered somewhere the host can't reach. That's a claim you can hold a vendor to — and the comparison page lays out where this is concretely ahead of the classic tools, and where it's honestly behind.
See it decide against a host you control
The free, open Standard edition is a package install and a few-minute quickstart — verifier identity, operator key, agent enrollment, first baseline approval. Change a watched file and watch the alarm fire on the verifier, not the host.