How attestation works
Five steps between a challenge and a verdict, and the component that performs each.
backend rh.issueChallenge({ ask }) → { nonce, challenge: "rhc1.<nonce>.<ask>" } (single-use, 5 min)
device Respond(challenge) → evidence (quote over nonce, + what the ask names)
backend rh.verify(evidence, { nonce }) → verdict (chain, replay, policy, on this call)The chip signs the nonce
TPM2_Quote under the enrolled attestation key over the nonce inside the challenge: PCR 7 for an identity ask, PCRs 0–7 with the event log for posture. A key ask adds TPM2_Create of a P-256 key under the storage parent and TPM2_Certify of it by the attestation key over the same nonce. A quote captured yesterday or on another machine carries the wrong nonce and is discarded.
The verifier proves the key is in a real chip
At enrollment, EkCertificateValidator walks the endorsement-key certificate chain; AiaChaser fetches missing intermediates (up to 16 levels, cached) and the chain must end at a pinned manufacturer root. TPM2_MakeCredential / ActivateCredential then proves the attestation key lives in the same chip as that EK. Every later quote names its signing key inside the signed structure; the verifier resolves the device from that name and checks the signature against the key it recorded. Nothing in the evidence identifies the device by any other means.
EkChainFetchFailed is operational and retried. EkNotTrusted and EkKeyMismatch are cryptographic and rejected outright.
The event log must reproduce the signed PCRs
For a posture ask the verifier replays the measured-boot log and requires it to reproduce the quoted PCR values; only then are the Secure Boot variables, the platform key issuer and the boot chain read from it. secureBootVerified, eventLogVerified and the oem-keyed claim come from that replay, never from anything the client asserts.
The policy judges the answer
PolicyResolver takes the policy the challenge pinned at mint: the calling key's identity policy for an identity ask, its posture policy for a posture ask. The class from the EK chain, the EAR status, the required PCRs and the rotation facts are evaluated here. A call that names a policy is 400 policy_bound_to_key; the enroll relay admits a device under the key's identity policy or returns 422 admission_refused.
The verdict comes back on the same call
A pass / warn / fail, an EAR status, the boot booleans, the assurance claims, a stable per-tenant device id, and for a passing key ask the certified public key. Nothing is stored on the client and no token is issued.