Skip to main content
The attestation report is the gateway’s proof of identity. It shows that the gateway is a specific piece of software running inside a genuine Intel TDX TEE, and it publishes the public keys the gateway uses to sign receipts and to run end-to-end encryption. Every other guarantee depends on this report, so verify it first. Fetch it with a fresh nonce:
See GET /v1/aci/attestation for the full field reference. This page explains what each part proves.

​
What the report contains

The receipt-signing keys live in attestation.workload_keyset.receipt_signing_keys, and the E2EE keys in attestation.workload_keyset.e2ee_public_keys. (The legacy /v1/attestation/report alias also adds top-level signing_address / signing_algo / signing_public_key for older clients.)

​
Why the nonce matters

You pass ?nonce=<random>. The gateway mixes your nonce into report_data inside the hardware-signed quote. Because the quote is signed by the TEE, a report that commits to a nonce you just generated cannot be a replay of an old capture. Generate a new nonce every time you verify, and confirm the report’s report_data is derived from that nonce and the published keyset.

​
How verification uses the report

A verifier checks, in order:
  1. attestation.evidence.quote verifies against Intel’s DCAP collateral, and the quote’s report data binds your nonce and the workload_keyset.
  2. keyset_endorsement verifies under workload_keyset.workload_identity, so the receipt-signing and E2EE keys genuinely belong to this workload.
  3. workload_id and workload_keyset_digest match what later receipts cite.
  4. The report is fresh (freshness.stale_after is in the future).
  5. In production, source_provenance matches the reviewed release.
Steps 1 through 4 are mechanical and run offline once you hold the report. Step 5 is a policy decision: it compares the attested source against the release you are willing to trust.
The gateway loads its identity and signing keys from dstack KMS inside the TEE. There is no ephemeral-key or stub-quote mode: a report always carries a real hardware quote.

​
Multi-server deployments

An endpoint can be served by more than one TEE instance behind the same hostname. The top-level attestation is the instance that answered your request; all_attestations lists every instance’s report. When you verify, check the instance that signed your receipt by matching workload_id and workload_keyset_digest.

​
Next

Receipts

How a single response is bound to this attested identity.

Verify a response

Run the full check end to end.