A structural difference, not just a feature list. AIDE, Tripwire, and Samhain are mature, hardware-independent file-integrity checkers — all three share one weak point: the checksum database and the alarm both live on the box being watched. Etminan trades that for a hardware trust anchor (TPM 2.0 + Linux IMA) at a real cost in maturity and platform breadth. Below is where that trade genuinely wins, where it honestly doesn't yet, and a feature-by-feature table.
Every one of these tools answers "has this file changed" — the difference is where the comparison logic itself executes, and therefore what a full root compromise on the monitored host can do to it.
Purely local, cron-triggered batch comparison against a local (optionally signed) database. No network component at all.
Database signed locally with an asymmetric key (open-source version). The commercial Enterprise variant adds a central console, but the check itself still runs on the host.
Closest of the three to Etminan's model — a central log server (yule), read-only database/config, stealth mode. But the hash
comparison itself still runs in userspace on the monitored host; only logging is
centralized.
The kernel's IMA subsystem measures files into a TPM PCR via a one-way extend — a separate, independently administered verifier device requests a TPM-signed quote over that PCR. The host agent makes no pass/fail decision and writes no alarm; it's a relay.
In all three established tools, a root-level compromise can rewrite the local database or tamper with the check process before anything is ever reported — the checker and the thing it's checking share a trust boundary. Etminan's AK private key never leaves the TPM, so the host's own root cannot forge a quote, no matter how completely it's compromised.
yule
server and syslog output are a step ahead of both but still not a native PagerDuty/Slack
integration — that plumbing is external to Samhain too. A config line and an
allowlisted, hash-pinned script is materially less assembly than any of the three
require for the same result.Every one of these is a real, current gap relative to three tools with a combined half-century-plus of production hardening — named directly rather than glossed over.
perm=wa.The platform-breadth and maturity trade-offs above are real today — here's what's specifically scoped to narrow them, ranked honestly by how close each one actually is, not by how good it would sound.
The nearest-term platform expansion. FreeBSD has a real
tpm2-tss port and a native tpm(4) device, so the hardware side is solvable — but Linux's
IMA has no FreeBSD equivalent, so this needs a from-scratch kernel-side measurement
source. audit(4)/OpenBSM logs opens but never ties into a
TPM PCR, and mac_veriexec only covers exec-time hash
checks against a manifest, not arbitrary watched-path reads — both already evaluated
and ruled insufficient on their own. Scoped as its own Phase-0-style empirical
investigation before any code, same rigor this project applied to Linux/TPM
originally, not assumed to just work.
Boot-integrity attestation is the easy half — Windows' native Measured Boot already produces TPM PCR values with no new driver needed. Arbitrary watched-path file integrity is the hard half: there's no IMA equivalent, so this would need a custom, WHQL-signed minifilter driver — a materially bigger and riskier undertaking than FreeBSD, with its own signing/certification process before it can ship at all. Deliberately sequenced behind FreeBSD, not started.
Explicitly deferred, not just deprioritized. OpenBSD's own hardening restricts loadable kernel modules in exactly the way this approach would need to fight against; NetBSD's TPM 2.0 userspace tooling is currently less mature than FreeBSD's. Revisit only once FreeBSD is proven, rather than spreading effort across three BSDs at once.
The most direct answer to the maturity gap isn't a feature at all — it's elapsed time. Running in parallel with an existing integrity-monitoring setup through one full real patch cycle is what actually starts closing the 15–25-year production-data gap against AIDE/Tripwire/Samhain, not something a code change can shortcut.
| Capability | Etminan | AIDE | Tripwire (OSS) | Samhain |
|---|---|---|---|---|
| Check/database off the monitored host | Yes | No | No | Partial (logging only) |
| Hardware-rooted trust (TPM) | Yes | No | No | No |
| Boot/firmware integrity (PCR0–7) | Yes | No | No | No |
| Host silence treated as a finding | Yes | No | No | Partial |
| Signed, reasoned operator approval workflow | Yes | No | Re-init only | No |
| Self-contained, hash-chained audit trail | Yes | No | No | No |
| Package-manager ownership correlation | Yes | No | No | No |
| Ticket/change-management correlation | Yes | No | No | No |
| Native PagerDuty/Slack/webhook alerting | Yes | No | No | Syslog/SIEM only |
| Third-party plugin/extension model | Yes | No | No | No |
| No special hardware required | No (needs TPM 2.0) | Yes | Yes | Yes |
| Platform breadth beyond Linux | No (Linux only) | Yes | Yes | Yes |
| Years of production hardening | New | 15–25+ | 15–25+ | 15–25+ |
AIDE, Tripwire, and Samhain are mature, hardware-independent local integrity checkers that all share the same structural weakness: the host checks and alarms on itself. Etminan trades that weakness for a hard hardware trust anchor (TPM + IMA) with external, non-forgeable attestation — at the cost of maturity, platform breadth, and a new high-value attack target (the verifier itself). On the surrounding ecosystem, Etminan has already closed two integration gaps outright — change-management correlation and native alert channels — that none of the three established tools address at all. Closing the remaining hardware/maturity/platform trade-offs is what turns "differently designed" into "strictly better."