Trust Model
Ratatouille’s trust model is built from two independent chains that converge at the verifier. Neither chain alone is sufficient — a valid hardware quote proves the machine is the right machine, but says nothing about what’s running on it. A valid signed policy proves someone authorized approved a baseline, but says nothing about whether the machine matches it. The verifier combines both.
The two chains
Section titled “The two chains”Hardware chain
Section titled “Hardware chain”The hardware chain establishes that the machine presenting evidence is the specific hardware that enrolled.
The TPM Manufacturer burns an Endorsement Key (EK) into the silicon at manufacture time and signs an EK certificate with their CA. This certificate is the anchor — it cannot be faked without breaking RSA. During enrollment, Keylime’s registrar verifies this certificate against the manufacturer’s public CA, then establishes an Attestation Key (AK) — a separate key the TPM uses to sign quotes, so the EK is never directly exposed.
On every push cycle (~10 seconds), the agent requests a fresh TPM Quote from its local TPM — a hardware-signed snapshot of the PCR values at that moment, bound to a nonce supplied by the verifier when the agent’s session was opened. The agent then pushes the quote and the new IMA log entries to the verifier over an outbound TLS connection. A quote without a matching nonce is a replay; a quote with the wrong PCRs is a tampered machine. PCR[7] captures the Secure Boot state at boot; PCR[10] is extended by IMA on every binary load since boot.
The IMA log is the detailed record: every ELF binary, kernel module, and shared library that executed, with its SHA-256 hash. The log hash-extends into PCR[10], so any tampering with the log breaks the PCR.
Policy chain
Section titled “Policy chain”The policy chain establishes that someone with authority approved the expected state of the machine.
A policy author generates a runtime policy from an enrolled baseline machine’s IMA log — the set of hashes that are allowed to appear. They sign it with Cosign using keyless signing: no long-lived private key, just a short-lived certificate tied to their authenticated identity (GitHub Actions OIDC, email, etc.). The signature, certificate, and artifact hash are recorded in the Rekor transparency log — public, append-only, independently auditable.
On a git push, Ratatouille’s webhook handler fetches the bundle, re-verifies the signature and Rekor inclusion, and distributes the verified policy to the Keylime verifier for each enrolled device.
Convergence
Section titled “Convergence”The verifier holds both chains simultaneously. On each pushed attestation it checks:
- The TPM quote is signed by the registered Attestation Key (AK) for this device
- The nonce in the quote matches the one issued for this session (freshness)
- PCR[10] in the quote matches what the IMA log hash-extends to (log integrity)
- Every IMA log entry’s hash appears in the active signed policy (no unauthorized binaries)
- PCR[7] matches the expected Secure Boot state (boot integrity)
All five must pass. If any fails, the device is immediately marked FAILED.
What you have to trust
Section titled “What you have to trust”| Trust assumption | Why |
|---|---|
| TPM manufacturer | EK certificate is the hardware root — there is no layer below it |
| Keylime (open source) | The verifier and agent implementation — auditable on GitHub |
| Sigstore / Rekor | The transparency log is honest — publicly verifiable by anyone |
| Linux kernel IMA | The measurement subsystem itself — part of the mainline kernel |
What you do not have to trust: Ratatouille’s servers, the cloud provider, the network path, or the operator of the machine after enrollment. The evidence is cryptographically bound to the hardware and independently verifiable at every step.