Remote attestation: evidence, verification, and policy-gated trust
Attestation does not pronounce a system “secure.” It supplies authenticated claims that a verifier appraises so a relying party can make a scoped decision.
Direct answer
Remote attestation is a procedure in which an Attester produces signed Evidence about itself, a Verifier appraises that evidence against endorsements, reference values, freshness, and policy, and a Relying Party decides whether to grant access or release a secret.The IETF RATS roles
| Role or input | Responsibility |
|---|---|
| Attester | Produces claims about identity and state as Evidence |
| Evidence | Claims intended for appraisal, normally protected by a hardware-rooted signing chain |
| Endorsements | Manufacturer or supply-chain statements used to evaluate authenticity and security state |
| Reference values | Known-good or approved measurements and versions |
| Verifier | Checks authenticity, freshness, collateral, reference values, and appraisal policy |
| Attestation Result | The Verifier’s output for a Relying Party; not the raw evidence itself |
| Relying Party | Applies its own policy and decides whether to authorize the requested action |
Keeping these roles separate prevents a common design error: treating a vendor-signed report as an authorization decision. A signature can establish provenance while the reported measurement, debug state, security version, freshness, or device membership remains unacceptable.RATS
A defensible key-release flow
- The relying system supplies a nonce or other accepted freshness challenge.
- The workload binds an ephemeral session public key or equivalent endpoint identity into report data.
- The TEE produces evidence covering platform identity, measurements, security version, policy-relevant attributes, and the bound data.
- The verifier validates certificate chains, revocation and TCB collateral, freshness, expected measurements, versions, debug state, and binding.
- The verifier returns a scoped result; the relying party checks its own authorization policy.
- The key broker encrypts a short-lived secret to the bound workload key and records the policy/result identifiers without logging the secret.
What a verifier must actually check
- Cryptographic signature and the manufacturer or platform certificate chain.
- Certificate, endorsement, and platform security collateral validity and revocation state.
- Freshness through a nonce, timestamped trusted protocol, or another explicitly accepted mechanism.
- Launch and runtime measurements against versioned reference values.
- Security version numbers, mitigation or advisory status, and downgrade policy.
- Debug, development, migration, and other policy-sensitive attributes.
- Binding between evidence, the intended workload/session endpoint, and any attached device set.
EAT is a format, not the procedure
RFC 9711 defines the Entity Attestation Token, a standards-track claims format that can be represented with CBOR Web Token or JSON Web Token encoding. EAT can carry attestation claims, but adopting the token format does not supply a trustworthy Attester, reference values, verification policy, or authorization decision.EAT
Common failure modes
- Accepting any correctly signed evidence from a device family without checking measurements or policy attributes.
- Using stale evidence or omitting a verifier-controlled freshness mechanism.
- Verifying on the same untrusted host without a separate trust argument.
- Releasing a reusable secret that is not cryptographically bound to the attested endpoint.
- Allowing automatic fallback to an unverified or development-mode workload.
- Never expiring reference-value exceptions or never testing revocation and collateral outages.
Frequently asked questions
Is an attestation report a security certificate?
No. It is evidence containing claims. A verifier must authenticate and appraise those claims, and a relying party must make a scoped authorization decision.
Why bind a public key into attestation evidence?
It connects the approved measured environment to the endpoint receiving the secret. Without binding, a valid report can potentially be relayed while a different endpoint receives the released material.
Is EAT the same as remote attestation?
No. EAT is a standardized token format for claims. Remote attestation also needs evidence generation, endorsement and reference data, verification, policy, freshness, and relying-party authorization.
Sources
- RATS
- EAT
- CCCWhy is attestation required for confidential computing?Confidential Computing Consortium
Relevant GPU availability
Verified specifications, confidential-mode support, and public listings for the accelerators this post covers.
Ready to reserve capacity?
Confidential Nodes matches bare-metal confidential GPU nodes to workloads, with verified provider data behind every listing.