How it works

Attest, re-attest, keep attesting

Attestation is when a machine proves what hardware and software it runs. The proof comes from a chip the machine cannot fake. This page explains the idea in five steps.

1. A machine can prove what it runs

A security chip records what the machine starts and signs a report. A verifier compares the report with the values it expects. If they match, the verifier releases a key, a credential or data. This is Remote attestation.

2. The proof goes stale

The report describes one moment. An update, a repair, a new AI model or a published flaw changes the machine, or changes what the report is worth. The old proof now describes something that no longer exists.

3. So the machine proves itself again

4. It has to hold through the whole life of a product

• Design. Decide what will be measured, who verifies it and what happens when a check fails.
• Build. Every build produces its expected measurements and a record of how it was made.
• Make or deploy. Each unit gets an identity rooted in hardware and proves itself for the first time.
• Operate. Units prove their state on a schedule and before sensitive actions.
• Update. After every change, the unit proves the new state and the old one is refused.
• Retire. Identities are revoked and keys destroyed, so a retired unit cannot come back.

More in Attestation in the product life cycle.

5. It depends on what your product trusts

Everything your security rests on is your trusted computing base. Attestation can make parts of it provable, and some technologies remove parts of it. See it part by part in the TCB definition tool, or run the TCB check for your own product.

The working parts

Between a measurement and a decision there are seven parts: evidence, endorsements, reference values, an appraisal policy and more. Each is explained in evidence, reference values and appraisal, with what is compared and what it means.

How each platform does it

• Processors and TEEs: Intel TDX and SGX, AMD SEV-SNP, Arm CCA, Arm TrustZone and PSA, TPM, DICE
• GPUs: NVIDIA GPUs
• Phones and personal devices: Android, Apple devices
• OT, industrial and small devices: Controllers and industrial devices
• Clouds: Amazon Web Services, Microsoft Azure, Google Cloud, Oracle Cloud Infrastructure
• Verifiers and transparency: Independent verifiers, Transparency services

Each one is explained in the platform guide: what it proves, the evidence, who verifies, and when to prove it again.

The terms

• Reattestable
• Remote attestation
• Re-attestation
• Continuous attestation
• Re-attestation vs continuous attestation
• Trust on first use (TOFU)
• Attestation freshness
• IETF RATS architecture
• EAT and CoRIM
• Trusted execution environment (TEE)
• Confidential AI
• GPU attestation
• Attested TLS
• Workload identity (SPIFFE/SPIRE)
• Measured boot
• TPM
• DICE
• Runtime integrity
• Software supply chain attestation
• Continuous compliance
• Wallet Unit Attestation (WUA)
• Two meanings of attestation in eIDAS 2.0
• IEC 62443
• TCB recovery
• AI passport
• Attestable computing
• Agent sandbox
• RXSWIN
• Quote, report, token: names for evidence
• Local attestation
• Binary and property-based attestation
• Attestation across vendors
• Enclave, trust domain, realm: one idea, many names
• Library operating systems for enclaves
• Provisioning and onboarding
• Self-sovereign identity (SSI)
• Why small devices struggle to be trusted
• Attestation in the product life cycle
• Non-repudiation
• Anonymous attestation: DAA, EPID and group signatures
• Attested authorship

Background

• A short history of attestation, from 1972 to today
• Attestable computing: integrity first, confidentiality optional
• The reading list: foundations, standards, attacks, and who runs it in production