Attestation

Learn how to verify the ACI gateway attestation report for Confidential AI.

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

Field	What it proves
workload_id	Stable identity of the gateway workload.
workload_keyset_digest	Digest over the published keyset. Receipts cite this value.
attestation.tee_type	TEE technology, for example tdx.
attestation.evidence.quote	Hardware-signed TDX quote. This is the root of trust.
attestation.report_data	Value bound into the quote, committing to the nonce and keyset.
attestation.workload_keyset	Workload identity, receipt signing keys, E2EE (end-to-end encryption) public keys, TLS keys, and keyset epoch.
attestation.keyset_endorsement	Signature over the keyset under the workload identity key.
attestation.source_provenance	Source repo, commit, image digest, and image provenance when available.
attestation.freshness	Fetch and expiry timestamps.
service_capabilities	Runtime 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.