Remote Attestation

What remote attestation is

Remote attestation is the mechanism by which a device tells a server "here is signed, tamper-evident proof of what I am and what I am running — you decide whether to trust me." Rather than granting access based purely on possession of a credential, the server evaluates the evidence against a policy and only then issues a token, a certificate, or a session.

The IETF Remote ATtestation procedureS (RATS) working group has formalised the actors and vocabulary in RFC 9334. Three roles matter:

In TigerTrust's architecture, the on-device agent is the attester, PKI Core hosts the verifier, and the issuing CA inside PKI Core is the relying party. Backend policy resolution sits between the two, choosing which policy applies to which device type.

How it works

A typical attestation exchange follows five steps:

1. Challenge. The verifier issues a fresh, single-use nonce. This defeats replay: a captured evidence bundle from yesterday cannot be reused today.
2. Evidence generation. The attester asks its root of trust — a TPM, a Confidential Computing platform like SEV-SNP or TDX, or an isolated enclave — to produce signed evidence including the nonce.
3. Transport. The attester bundles the evidence with any supporting material (the endorsement certificate, event log, quoted PCR values) and sends it to the verifier over a normal HTTPS channel.
4. Appraisal. The verifier validates every signature, checks the nonce, chain-verifies endorsement certificates, and compares reported state against a policy (golden PCR values, allowed measurement digests, permitted signers, etc.).
5. Attestation result. The verifier returns a structured verdict — often a signed Attestation Result document — that the relying party consumes.

The critical property is unforgeability: the evidence must be produced by hardware or firmware the attacker cannot subvert, and it must include a fresh nonce so old evidence cannot be replayed.

What problem it solves

Certificate issuance, secrets access, and workload admission all traditionally trust "the caller presented the right credential." That model breaks the moment credentials leak, are stolen, or are cloned into an attacker-controlled environment. Remote attestation replaces "who has the key" with "prove you are the hardware and software configuration we expect."

Concretely, attestation lets you enforce:

• Firmware and software integrity — the device booted the code you approved, not tampered firmware or a rootkit.
• Key non-exfiltration — the private key going into a certificate is provably resident in a TPM or enclave, not a copy on someone's laptop.
• Environment authenticity — this is running on your real hardware, not a VM impersonating a factory sensor.
• Freshness — the evidence was produced in response to this request, not captured months ago and replayed.

Without attestation, the strongest thing you can say is "someone with the right credentials made this request." With attestation, you can say "this specific hardware, in a specific software state, made this request." That is a categorically stronger guarantee.

The three-question framework

TigerTrust's design doc frames every attestation as answering three questions, each with a specific proof:

Skip any one and the attack surface returns. Skip the quote — stolen credentials work again. Skip credential activation — attackers submit a self-generated AK. Skip Certify — attackers get a real attestation from a real TPM and then substitute their own key into the CSR.

When to use it

Remote attestation is the right tool when:

• Devices operate outside your physical control (IoT, edge, field deployments).
• Certificate misuse would be expensive or catastrophic (industrial control, medical devices, code signing, high-value TLS).
• Regulations reference hardware-rooted identity — CNSA 2.0, IEC 62443, PCI-DSS 4.0, HIPAA hardware controls.
• You are running workloads on untrusted infrastructure and need to prove the workload is what you deployed (confidential computing).

It is overkill for short-lived cloud workloads that can rely on SPIFFE/SPIRE identity, or for internal services already inside a well-controlled trust boundary.

Common misconceptions

"Attestation prevents malware from running." It does not. Attestation is a detection mechanism, not a prevention mechanism. The TPM will happily measure malware into a PCR and sign a quote saying "I am running malware." The verifier's job is to refuse trust when the reported state does not match a golden reference. Enforcement happens off-device.

"A signed quote is proof of trustworthy state." Only if the verifier actually knows what "good" looks like. A quote you cannot compare against a golden reference is just a signed record of arbitrary bytes. Golden values, event log replay, and per-device-type policies do the actual work.

"Attestation and authentication are the same thing." They overlap but differ. Authentication answers "who are you?"; attestation answers "what state are you in?" Modern architectures combine them — authenticate with a certificate whose issuance was gated on a passing attestation.

"Once a device is attested, you are done." Attestation is only fresh at the moment the evidence was produced. Runtime state can drift — kernel updates, config changes, IMA violations. Serious deployments run periodic re-attestation and quarantine devices whose evidence goes stale.

How TigerTrust implements it

TigerTrust's verifier lives in services/pki-core/internal/attestation and runs every attestation check as pure Go code with no I/O, which makes it unit-testable against the github.com/google/go-tpm-tools/simulator. Every failure carries a machine-readable reason code — quote_verify, pcr_mismatch:<n>, certify_verify, ek_chain — so operators can build alerts and dashboards without parsing free-form logs. A background worker also runs periodic re-attestation and quarantines devices whose latest passing attestation is older than twice the policy's freshness ceiling. See the TPM_ATTESTATION design doc for the full flow.

Related reading

• IETF RFC 9334 — RATS architecture, actor definitions, and evidence lifecycle.
• Keylime — a well-known open-source runtime attestation reference project.