Remote Attestation

The remote trust problem

A cloud provider claims that an approved application is running inside a genuine TEE.

Before sending private data, a user or organization may need to know: Is the hardware genuine? Which code is running? Which configuration is active? Is debug mode enabled? Is the firmware acceptable? Is the evidence fresh? Has the report been modified? Does the communication key belong to the TEE?

Remote attestation helps answer these questions.

What is remote attestation?

Remote attestation is a process in which one system produces cryptographic evidence about its state and another system evaluates that evidence.

The IETF Remote ATtestation procedureS (RATS) architecture provides a vendor-neutral model for generating, conveying, and evaluating attestation claims.

The three main roles

Attester

The Attester produces evidence. It may be an enclave, a confidential VM, a mobile device, a secure subsystem, a confidential GPU, or a network device.

Verifier

The Verifier evaluates evidence. It may check digital signatures, certificate chains, platform identity, firmware version, application measurement, debug state, security version, revocation status, freshness, reference values, and appraisal policy.

Relying Party

The Relying Party uses the result to make a decision. It may decide to release a key, send private data, accept a connection, authorize a transaction, accept a computation result, or permit access to a service.

The Verifier and Relying Party can be separate services or part of the same application.

Important terms

Claim — A statement about the Attester. Examples: application measurement, product identity, firmware version, debug mode, security version, device identity.

Evidence — Contains claims produced by the Attester for appraisal.

Endorsement — Supporting information from a manufacturer, owner, or another authority. Examples: platform certificate, vendor verification key, hardware certificate chain, security statement about a firmware version.

Reference value — Describes an expected or accepted state. Examples: approved application measurement, minimum firmware version, allowed signer, required configuration, accepted model hash.

Attestation result — The Verifier's conclusion after evaluating the evidence against policy.

A complete attestation flow

1. Create a challenge — The Verifier or Relying Party creates a fresh random nonce. 2. Collect claims — The TEE collects hardware, firmware, software, and configuration information. 3. Include freshness data — The nonce is included in, or cryptographically connected to, the evidence. 4. Sign the evidence — A hardware-backed attestation mechanism signs the evidence. 5. Send the evidence — The Attester sends the evidence to the Verifier. 6. Validate authenticity — The Verifier checks signatures, certificates, and endorsement information. 7. Validate freshness — The Verifier confirms that the nonce matches the current challenge. 8. Apply appraisal policy — The Verifier compares claims against accepted reference values. 9. Produce the result — The Verifier produces an attestation result. 10. Make a decision — The Relying Party releases a secret, sends data, accepts the connection, or rejects the TEE.

Why freshness matters

Without a nonce or another freshness mechanism, an attacker may record an old valid report and replay it later.

A nonce connects the evidence to the current interaction. The verifier should check that the nonce matches the challenge, the nonce was not previously accepted, the signed evidence covers the nonce, and the challenge was generated securely.

Binding a communication key

A common secure pattern is:

1. Generate a new key pair inside the TEE. 2. Hash the public key. 3. Include the hash in the attestation evidence. 4. Verify the evidence. 5. Confirm that the presented public key matches the hash. 6. Create an encrypted session using that key. 7. Release the secret through the encrypted session.

This connects TEE identity, loaded software, attestation evidence, communication key, and the secure network channel.

Evidence verification and policy appraisal

These are different operations.

Evidence verification asks: Is the evidence authentic and cryptographically valid?

Policy appraisal asks: Is the reported state acceptable?

A report may be correctly signed but still show debug mode enabled, outdated firmware, wrong application measurement, revoked platform, or a security version below the minimum. Correctly signed evidence can still be rejected.

Entity Attestation Tokens

The Entity Attestation Token specification defines a format for conveying attested claims about an entity.

RFC 9711 was published in April 2025 and provides a flexible model for carrying attestation claims in token form.

An EAT is a format for claims. It does not create trustworthy evidence by itself. Trust still depends on the Attester, signing keys, verification, endorsements, reference values, and policy.

What attestation may prove

Depending on the system, attestation may support a claim that:

• Evidence came from a recognized platform.
• A particular software image was loaded.
• A specific configuration was active.
• Debug mode was disabled.
• A minimum security version was present.
• A public key was generated inside the environment.
• The evidence was fresh.

What attestation does not prove

Attestation does not automatically prove that:

• The application is free of bugs.
• The source code matches the binary.
• The application has been audited.
• The application will not leak data.
• The result is mathematically correct.
• The operator will keep the system available.
• The platform has no side-channel risk.
• The user's device is secure.

Platform example: AWS Nitro Enclaves

Nitro Enclaves can produce signed attestation documents containing platform measurements, a nonce, and optional application-provided data.

AWS KMS can evaluate these documents before allowing selected cryptographic operations.

Key takeaways

• Remote attestation provides evidence about platform and software state.
• The main roles are Attester, Verifier, and Relying Party.
• Evidence must be checked for authenticity and freshness.
• Reference values describe accepted states.
• Policy appraisal is different from signature verification.
• A secure communication key should be bound to the evidence.
• Attestation does not prove application correctness.