Skip to content

Requirements

Etminan is four binaries, with deliberately different needs. A monitored host runs etminan-agent and needs a TPM 2.0 and an IMA-capable Linux kernel. A verifier device needs neither — it only needs to reach the hosts it polls — and runs two: etminan-verifierd, the trust daemon that holds the only signing key and authorizes every operator action, and etminan-verifier, the command-line tool operators and the timer actually invoke.

The fourth, etminan-witness, belongs to neither and that is its purpose: it checks the evidence the verifier produces, on some third machine where the evidence arrives — a mail host, a log collector, an auditor's laptop. It needs nothing at all: no TPM, no database, no key, no daemon to talk to. See Knowing the verifier is alive.

This chapter is the pre-flight checklist for the two machines that have requirements worth checking.

The two roles never share a machine

Physical or virtual — what the quote proves

Etminan treats a vTPM as a first-class TPM. What changes between deployment classes is not whether attestation works, but how far down the stack the proof reaches. State this deliberately, because it is the first thing an assessor asks — under ISO 27001, NIS2, DORA, SOC 2 or PCI-DSS alike:

Deployment class Enrollment What a quote proves What it does not prove
VM with a vTPM, hypervisor you own Default (no --ek-roots) The guest OS was not tampered with from the inside — including by guest root. Your trust perimeter is unchanged, because the hypervisor is already yours to administer. That the TPM is silicon. A compromised hypervisor could emulate one.
Discrete or firmware TPM Default (no --ek-roots) The AK is resident in the same TPM that holds the endorsement key (credential activation). That the TPM is a genuine, manufacturer-issued part.
Discrete or firmware TPM --ek-roots <dir> All of the above, plus hardware provenance: the EK certificate chains to a manufacturer root you trust. Physical attacks (cold-boot, desoldering, evil maid) and below-TPM firmware implants.

--ek-roots is a deliberate hardening step, not a default. It refuses any host that presents no EK certificate — which is the normal state for a vTPM/swtpm — so apply it to a bare-metal group, never fleet-wide across virtualized hosts. See Enrolling a host.

Public cloud is a separate decision

Azure Trusted Launch, GCP Shielded VM and AWS NitroTPM use the same technical path, but the hypervisor is the cloud provider's, not yours — so the trust perimeter genuinely moves. That is a different trust statement from the one above and needs its own sign-off; it is not covered by "customer-owned hypervisor".

The verifier's entire trust value comes from being administratively separate from the hosts it checks. Never run etminan-agent and etminan-verifier on the same box — a host compromise would then reach the judge as well as the judged.

flowchart TB
    subgraph mon["Monitored hosts — need a TPM + IMA"]
        a1["web-01<br/>etminan-agent"]
        a2["db-02<br/>etminan-agent"]
        a3["app-03<br/>etminan-agent"]
    end
    subgraph ver["Separate device — no TPM"]
        v["etminan-verifier<br/>polls hourly over mTLS"]
    end
    v -->|"quote request → quote + log delta"| a1
    v --> a2
    v --> a3
    style mon fill:#0f1c18,stroke:#1e332b,color:#e9efec
    style ver fill:#0f1c18,stroke:#7fd99a,color:#e9efec

Monitored host (etminan-agent)

Hardware and kernel

Requirement Detail
TPM 2.0 A TPM 2.0 device — discrete chip, firmware TPM, or a vTPM/swtpm on a VM. The agent uses the resource-managed device node /dev/tpmrm0, not the raw /dev/tpm0.
SHA-256 PCR bank Etminan uses the SHA-256 bank of PCR 10, exclusively and by design. A TPM that exposes only a non-SHA-256 bank is out of scope and cannot be enrolled.
IMA-capable kernel The kernel's Integrity Measurement Architecture must be built in, with securityfs mounted at /sys/kernel/security. The agent reads the per-bank log ascii_runtime_measurements_sha256.
CPU architecture x86_64 — the only supported architecture. The agent links tpm2-tss (via tss-esapi) and is built natively per architecture; it does not cross-compile to musl. arm64 packages exist as an experimental build — see the note below before considering them.

The agent writes its own IMA policy

You do not hand-craft an IMA policy. The packaged etminan-agent-ima-policy.service runs etminan-agent write-ima-policy once, early at boot, before the daemon starts — no reboot, no manual securityfs editing. It writes exactly two rules:

measure func=BPRM_CHECK mask=MAY_EXEC
measure func=FILE_CHECK mask=MAY_READ fsuuid=<root-fs-uuid>

IMA has no path filter, so measurement is deliberately broad and paths are filtered on the verifier side. See Agent configuration.

Privileges and users

The agent runs as a narrowly-privileged, non-root user. The package sets this up for you:

  • A system user etminan-agent in the tss group — group membership is what grants access to /dev/tpmrm0.
  • AmbientCapabilities=CAP_DAC_READ_SEARCH on the systemd unit — the IMA measurement log is root:root 0440 by kernel design, and this is the narrowest capability that lets the non-root agent read it (also what event-triggered write detection runs under). No CAP_SYS_ADMIN, no root.

Network

Requirement Detail
Inbound The agent listens on 0.0.0.0:7620 by default (ETMINAN_AGENT_LISTEN) for quote requests from the verifier. Allow the verifier to reach that port.
Transport Every connection is mutual TLS, pinned by certificate fingerprint — there is no plaintext path. See Mutual TLS.
Outbound None required. The agent never phones home; it only answers the verifier.

Verifier device (etminan-verifier)

The verifier makes every trust decision, yet has the lighter list of requirements — quote verification is pure offline signature math.

Requirement Detail
No TPM The shipped verifier binary carries zero TPM-library dependency. It verifies quotes using only the enrolled host's exported AK public key.
A separate machine Independently administered from every monitored host. This separation is the security property; treat the verifier as your trust root.
Portable binary The verifier builds natively on Linux and macOS and cross-compiles cleanly to static musl. Packages are provided for the supported Linux distributions below; other platforms build from source.
Outbound network Reachability to each enrolled agent's host:port. No inbound service is required.
Local storage Room for its trust store: the SQLite baseline.db (approved/pending/rejected measurements + the hash-chained audit log), state.json (per-host enrollment), and its own TLS identity under /var/lib/etminan-verifier.

The verifier is the one catastrophic-loss host

The AK fingerprints, the whole approved baseline, and the entire audit history live only on the verifier. Plan its backup from day one — see Backup & restore.

Supported distributions

Packages are built per distribution for the agent (which must link the distro's tpm2-tss); the verifier is portable and rides the same packages.

Family Versions Package
Debian 12 (bookworm), 13 (trixie) .deb
Ubuntu LTS 22.04, 24.04 .deb
Enterprise Linux (Alma / Rocky / RHEL) 9, 10 .rpm

EL 8 is not supported

Enterprise Linux 8 is dropped: its tpm2-tss is too old for the agent to build against. Use EL 9 or 10.

arm64 is EXPERIMENTAL — do not deploy it

Debian 13 arm64 packages are published, and the agent compiles and links correctly there. That is the whole of what is proven. No arm64 host has ever completed an attestation, and one failure mode is already known and measured:

On a virtualized arm64 guest, attestation cannot work at all — and it fails silently. IMA initialises before the TPM driver is available and logs No TPM chip found, activating TPM-bypass, so PCR 10 is never extended while the measurement log keeps filling up and looks healthy. The cause is structural rather than a misconfiguration: QEMU on aarch64 offers only a TIS TPM, and Debian's arm64 kernels build in only the CRB driver.

Physical arm64 servers are expected to be fine — they expose the TPM over CRB via ACPI, which is built in — but that has not been verified on hardware, so it remains an expectation, not a claim.

Use x86_64 for anything you rely on. Treat the arm64 packages as build artefacts for people validating the port, not as a deployment target.

Every release is GPG-signed with the Etminan Team key (7387 4214 090F 9137 862D 0AF1 E1E5 41B7 B424 36DF); always verify signatures before installing (the install chapters show how).

Next steps