Skip to main content

​
What the attestation report proves

The attestation report is the gateway’s proof of identity. It proves the API is served by a specific workload running inside a genuine TEE and publishes the public keys used to sign receipts and support end-to-end encryption. Fetch it before trusting receipts: 
export API_KEY="<API_KEY>"
export BASE="https://inference.phala.com"
export NONCE="$(openssl rand -hex 16)"

curl -s "$BASE/v1/aci/attestation?nonce=$NONCE" \
  -H "Authorization: Bearer $API_KEY" \
  -o report.json

​
What to inspect first

jq '{api_version, workload_id, workload_keyset_digest,
     report_data: .attestation.report_data,
     stale_after: .attestation.freshness.stale_after,
     provenance: .attestation.source_provenance}' report.json
Check that:
  • api_version is aci/1.
  • attestation.freshness.stale_after is in the future.
  • workload_id and workload_keyset_digest are present; receipts must cite the same values.
  • attestation.source_provenance matches the gateway release you trust.
  • attestation.report_data is bound to your nonce and the published keyset.

​
What the report contains

FieldWhat it proves
workload_idStable identity of the gateway workload.
workload_keyset_digestDigest over the published keyset. Receipts cite this value.
attestation.tee_typeTEE technology, for example tdx.
attestation.evidence.quoteHardware-signed TDX quote. This is the root of trust.
attestation.report_dataValue bound into the quote, committing to the nonce and keyset.
attestation.workload_keysetWorkload identity, receipt signing keys, E2EE (end-to-end encryption) public keys, TLS keys, and keyset epoch.
attestation.keyset_endorsementSignature over the keyset under the workload identity key.
attestation.source_provenanceSource repo, commit, image digest, and image provenance when available.
attestation.freshnessFetch and expiry timestamps.
service_capabilitiesRuntime capabilities such as supported E2EE versions.

​
Verification steps

​
1. Verify the TEE quote

Verify attestation.evidence.quote against Intel DCAP collateral and confirm the quote’s report data matches attestation.report_data. You can use Phala’s public verification service for TDX quote decoding: 
jq -r '.attestation.evidence.quote' report.json > quote.txt

curl -s https://cloud-api.phala.com/api/v1/attestations/verify \
  -H "Content-Type: application/json" \
  -d "{\"hex\":\"$(cat quote.txt)\"}"
For local verification, use an Intel DCAP verifier such as dcap-qvl. For manual inspection, paste the quote into the TEE Attestation Explorer.

​
2. Verify nonce and keyset binding

The quote’s report data must commit to the nonce you generated and to the gateway keyset. This prevents replay and proves the receipt-signing keys belong to the attested workload. At a high level, your verifier should:
  1. Canonicalize the workload_keyset.
  2. Recompute the expected keyset digest.
  3. Confirm the quote report data binds that digest and your NONCE.
  4. Confirm workload_keyset_digest matches the recomputed digest.

​
3. Verify the keyset endorsement

Verify attestation.keyset_endorsement under attestation.workload_keyset.workload_identity. This ties the receipt signing keys and E2EE keys to the attested workload identity. Receipts are only valid when their signatures verify under a key from attestation.workload_keyset.receipt_signing_keys.

​
4. Check freshness and provenance

attestation.freshness.stale_after must be in the future when you verify. In production, compare attestation.source_provenance.repo_url, repo_commit, and image provenance against the release or source code you are willing to trust.

​
5. Handle multi-instance deployments

The top-level attestation is the instance that answered your request. all_attestations lists other instances behind the same service. When verifying a receipt, match the receipt’s workload_id and workload_keyset_digest against the attestation for the instance that signed it.

​
Legacy compatibility

GET /v1/attestation/report remains available for older clients. It returns the gateway attestation in a compatibility response shape and may include top-level signer fields such as signing_address. New integrations should use GET /v1/aci/attestation.

​
Next step

After you verify the gateway report, verify a response by checking a signed receipt.