Etminan vs. AIDE, Tripwire, Samhain & Keylime

01 — Core architectural difference

Where does the check actually run?

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.

Local only

AIDE

Purely local, cron-triggered batch comparison against a local (optionally signed) database. No network component at all.

Local, signed

Tripwire

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.

Centralized logging

Samhain

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.

Off-host, hardware-rooted

Etminan

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.

02 — Where Etminan is ahead

Not just differently designed — concretely ahead.

Full-root-compromise model

An attacker with full root cannot suppress alerting — at most they can silence the agent, but unreachability is itself an alarm trigger. On AIDE/Tripwire/ Samhain, root compromise can rewrite the local database or tamper with the check process before anything is ever reported.

Hardware-verifiable chain

Signed TPM quotes plus IMA-log PCR replay prove byte-for-byte that the reported log matches the signed PCR — not just "some process computed a hash and claims it matches."

Enforced operator workflow

Drift is never auto-accepted. Every new baseline requires an explicit, reasoned, signed human approval, recorded in a self-contained, hash-chained audit trail — no external tool or service required. AIDE/Tripwire's "update database" is typically a single unprotected admin command.

Boot integrity as a signal

Boot-chain attestation (PCR0–7 quoted alongside PCR10) is on the roadmap (Planned) — a signal AIDE/Tripwire/Samhain have no equivalent mechanism for.

Silence is a finding

Host unreachability is a finding, not a silent soft-skip — closes the classic "just kill the agent" evasion.

Near-immediate write detection, no privileged daemon

An in-process, unprivileged fanotify watcher triggers a targeted sweep the instant a watched file's write completes, rather than waiting for the next polling cycle — shrinking the write-without-read gap to near-zero latency. Tripwire/AIDE can reach comparable granularity only by layering on auditd with perm=wa rules, which needs its own privileged daemon (CAP_AUDIT_CONTROL/CAP_AUDIT_WRITE). Etminan gets equal-or-better latency with no new daemon and no new broad capability beyond what IMA log access already requires.

Richer finding context

Package-manager correlation (does the changed file belong to an installed package, was it a real authenticated transaction) plus a plain-language verdict — instead of a bare hash diff.

Ticket-system correlation — shipped

The Etminan Plugin API's change-source category automatically correlates a pending baseline change against external change-management/ ticket systems (Request Tracker ships today) and surfaces every match — "was this actually planned," not just "does a package own this file." None of the three established tools attempt this at all: AIDE is diff-and-report with no approval workflow to correlate anything against; Tripwire's re-init step has no ticket-system awareness; Samhain is file-integrity plus centralized logging only.

Native alert channels — shipped

PagerDuty, Slack, and a generic webhook, alongside email — the same external, allowlisted Plugin API model as change-source correlation, no in-process HTTP client anywhere in the verifier. AIDE has no built-in alerting beyond cron + mail at all; open-source Tripwire is the same; Samhain's central 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.

Extensible by design, not by age

AIDE/Tripwire/Samhain's integration breadth comes from decades of incremental, mostly-external point integrations. Etminan's comes from a small number of reusable shapes (package-manager checkers, the Plugin API's two categories) designed in early, so each new integration is a bounded, reviewable addition — closing the integration gap through design, not just accumulated age.

Signed extension trust, not just a signed database

AIDE's local database is only optionally signed, and Tripwire's asymmetric-key signing (both above) covers the local file-integrity database only — neither has an equivalent for trusting a new detection rule or external add-on itself. Etminan's plugins install/update path (verifier/src/plugin_catalog.rs) closes that in the other direction: a plugin's trust chain runs through an Ed25519 signature over a catalog manifest, verified against a key compiled into the binary, before any SHA-256 it lists is trusted at all — not yet publicly live (see the Plugin API for status), but a real design win once it is, not just a longer feature list.

03 — Where Etminan is honestly behind

The trade side of the trade.

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.

Hardware dependency

Requires a TPM 2.0, physical or virtual. AIDE/Tripwire/Samhain run on any machine, no special hardware at all.

Maturity

AIDE, Tripwire, and Samhain have 15–25+ years of production hardening between them. Etminan is new, without a full real-world pilot through an entire patch cycle yet.

Platform breadth

Linux only today (IMA-dependent). AIDE/Tripwire/Samhain also run on *BSD, Solaris, and partly macOS/Windows.

Unprivileged write-triggering needs a modern kernel

IMA itself still only measures on read-open, not on write — the in-process fanotify watcher that triggers a near-immediate targeted sweep the instant a write completes (see "ahead" above) needs unprivileged FAN_REPORT_FID support, which requires Linux ≥5.13. On an older kernel, or if fanotify is unavailable for any reason, this degrades gracefully to the per-cycle sweep alone — bounding detection to polling granularity in that fallback case, same as the baseline behavior every host already has.

Enrollment is the weakest link

Enroll proves the AK resides in the same TPM as the EK via credential activation, so a detached software key can't enroll — but without a manufacturer EK-certificate chain (true for many vTPMs) it can't prove that TPM is genuine hardware rather than software-emulated, nor that it's this specific host's TPM, so a human witness confirms identity on first use. AIDE/Tripwire don't have this problem, since they need no hardware trust chain at all.

A new high-value target

The verifier itself becomes a critical single point of trust — if it's compromised, it can suppress alarms just as effectively as the classic self-checking model this design replaces.

Nothing below the TPM boundary

Firmware/UEFI implants and SPI-bus attacks are explicitly out of scope — unlike deeper Secure-Boot-attestation stacks. A guest's vTPM quote can't vouch for the hypervisor either; that layer is covered by attesting the hypervisor host in its own right, not by the guest.

Coarser policy filtering

IMA has no path filter at the kernel level, so Etminan measures broadly and filters on the verifier side after the fact. AIDE/Tripwire allow fine-grained rules directly in the policy config.

Scale: measured in its parts, not yet field-proven end-to-end

The cryptographic core is not the bottleneck: verifying one host's signed quote and replaying its usual incremental IMA delta measures at roughly a millisecond of CPU (release build, commodity hardware). What we don't yet publish is a full-scale end-to-end benchmark or the established tools' decades of production data: treat this as engineered and measured in its parts, not yet field-proven at thousands of hosts.

Physical attacks out of scope

Cold-boot, TPM desoldering, evil-maid — software/remote threat protection only, same limit any of these tools would have against a physically present attacker.

04 — Closing the gap

What's actually planned, not just aspirational.

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.

FreeBSD support

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.

Windows support

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.

OpenBSD / NetBSD

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.

A real production pilot

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)	Planned	No	No	No
Host silence treated as a finding	Yes	No	No	Partial
Near-immediate write detection, no privileged daemon	Yes (unprivileged fanotify)	No	Only via external auditd	Only via external auditd
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 (Ed25519-signed catalog)	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+

06 — Adjacent attestation approaches

And next to the actual attestation players?

AIDE, Tripwire, and Samhain are the file-integrity tools Etminan replaces. The fairer question for a security team already sold on TPM attestation is how Etminan sits next to Keylime — the established open-source platform — and cloud attestation (AWS Nitro, Azure Attestation, GCP Confidential Computing). Both are legitimate; here's the honest split.

Keylime — the established platform

Keylime and Etminan share the same foundation: a TPM 2.0-anchored quote, verified off-host in software — both verifiers are pure signature math, so neither needs a TPM of its own. Keylime is the mature, CNCF-hosted option: a full platform — registrar, verifier, tenant, its own policy/allowlist model, and a revocation framework — built for continuous, largely automated attestation at scale. Etminan is deliberately the opposite shape: two small Rust binaries and a SQLite baseline, with an operator-approved-only philosophy where drift is proposed and never auto-accepted. It is leaner to run and to audit by hand; Keylime is richer and more battle-tested. If you want a full attestation platform with a policy engine, Keylime is the right call — not a weakness we gloss over.

Just as telling is direction. Keylime's recent momentum is decidedly cloud-native: as a CNCF project its active work centres on Kubernetes/OpenShift (its attestation-operator), per-pod IMA measurement, and Confidential Containers. Etminan goes the other way on purpose — it targets the machines that stay off the cluster: bare-metal, VMs, OT/ICS, and air-gapped on-prem, where a continuous cloud-native attestation platform is more than the job needs and a cluster is not even present. So the two aren't really converging on the same buyer: Keylime is following the fleet into Kubernetes; Etminan is deliberately serving the hosts that trajectory leaves behind.

Cloud attestation — where sovereignty rules it out

AWS Nitro, Azure Attestation, and GCP Confidential Computing cover many hosts that already live in those clouds — but they put a third-party provider in the trust path, and they do not exist for on-premises, air-gapped, or OT/ICS environments at all. For an EU operator under NIS2/DORA who is not permitted to route attestation through a US cloud, that is disqualifying regardless of feature set. Etminan's core attestation loop is self-hosted and offline — no cloud provider in the trust path, and no telemetry or phone-home in the core loop or any background operation. (Air-gapped operation for a verifier with no outbound network is a Planned Enterprise capability.)

Capability	Etminan	Keylime	Cloud attestation
TPM-anchored, off-host verification	Yes	Yes	Provider-side
Self-hosted; no third-party provider in the trust path	Yes	Yes	No (provider is the verifier)
On-prem / air-gapped / OT deployable	Yes (air-gap mode Enterprise, planned)	Self-hostable, geared to continuous online use	No
Footprint	Three binaries + SQLite	Full platform (registrar/verifier/tenant/policy/revocation)	Managed service
Deployment focus	Single hosts / VMs / bare-metal, incl. non-cluster & air-gapped	Continuous attestation at scale; recent focus Kubernetes / cloud-native (operator, per-pod, CoCo)	Cloud instances only
Drift handling	Operator-approved only, never auto-accepted	Policy/allowlist-driven, automation-first	Provider-defined
EU data sovereignty	Yes	Yes	No (foreign provider in path)
Maturity / ecosystem	New	Established (CNCF)	Vendor-operated

The short version: against cloud attestation, Etminan wins outright for sovereign, on-prem, and air-gapped deployments where a cloud provider in the trust path is a non-starter. Against Keylime, it is a different point on the curve — leaner and operator-controlled versus fuller and more mature, and increasingly a different target too: Keylime is moving with the fleet into Kubernetes, while Etminan stays with the non-cluster, air-gapped, and OT hosts. Not a strict upgrade — a deliberately different lane.

07 — Compliance frameworks

Mapped to the controls your auditors name.

AIDE and Tripwire are named in the frameworks enterprises are audited against — PCI-DSS 11.5.2, CIS benchmarks. Etminan has a control-by-control mapping (Enterprise — shared under NDA on request) showing where it satisfies those controls, and, just as important, where it stops, for the frameworks large enterprises answer to:

ISO/IEC 27001:2022 NIS2 DORA SOC 2 PCI-DSS 11.5.2

For controls it addresses — file-integrity monitoring, change detection, tamper-evident logging, and separation of duties (role-separated authenticated operators today (RBAC by Unix UID); four-eyes dual-control in development) — Etminan typically supplies stronger evidence than a host-resident checker: a root-compromised host cannot forge a TPM quote or suppress the off-host comparison. The mapping is deliberately honest about scope — it is detective integrity evidence, not a certification, and not a substitute for the policy and process a framework also requires. The mapping and the per-framework reports are confidential and go to evaluating teams under NDA on request.

Etminan vs. AIDE, Tripwire, and Samhain.