TresorTresor API Docs
Workspace Docs

Attestation

Hardware-rooted proof that the API endpoint is the audited Tresor router running inside an AMD SEV-SNP Confidential VM.

When you call https://api.tresor.co, the certificate-authority chain proves only that you reached a server controlled by Tresor — it does not prove that the binary serving your request is the audited router running inside a Confidential VM. An attacker (or an insider) with TLS-termination access could intercept traffic without breaking any conventional check.

Tresor publishes a hardware attestation envelope on every router pod. Combined with a trust bundle signed by an offline release-root key, this lets your client refuse to send traffic to anything that isn't a release you've explicitly trusted.

This page explains the trust model and verifier algorithm. To put it into practice, see Verify the attestation.

Trust model

   Release ceremony (offline)
       │
       ▼
   Release Root Key (Ed25519)  ←── pinned by your client
       │ signs
       ▼
   Trust bundle JWS (https://trust.tresor.co/api/router.json)
       │ lists
       ▼
   { allowed_hw_measurements, allowed_workload_identity_tags, min_tcb }
       │ matches
       ▼
   GET https://api.tresor.co/attestation
       │ contains
       ▼
   AMD SEV-SNP report → MEASUREMENT, REPORTED_TCB, REPORT_DATA
       │ binds
       ▼
   tls_spki_sha256  ⇄  live TLS handshake SPKI

Three things have to line up: the SNP MEASUREMENT must be in the allowlist, the workload identity tag must be in the allowlist, and the live TLS public key must match the one bound inside the SNP report.

Verifier algorithm

For each new connection (or once per max_age_seconds):

  1. Fetch GET /attestation from the API endpoint.
  2. Fetch the trust bundle from trust_bundle_url and verify its EdDSA JWS signature with your pinned release root public key. Reject if valid_until is in the past.
  3. Decode snp_report_b64 and extract MEASUREMENT, REPORTED_TCB, and REPORT_DATA. Verify the VCEK chain against the AMD root CA in the bundle.
  4. Reject unless MEASUREMENT ∈ allowed_hw_measurements and workload_identity_tag ∈ allowed_workload_identity_tags.
  5. Reject unless REPORTED_TCB ≥ min_tcb.
  6. Reject unless REPORT_DATA[0:32] == SHA-256( hex_decode(tls_spki_sha256) || hex_decode(workload_identity_tag) ).
  7. Open a fresh TLS connection to the API endpoint, capture the leaf certificate's SPKI, hash it with SHA-256, and reject unless it matches tls_spki_sha256.

If all checks pass, cache the verified (tls_spki_sha256, MEASUREMENT, workload_identity_tag) tuple and use it as a TLS pin until the cache expires.

Why each check matters

  • MEASUREMENT allowlist — proves the running binary's launch digest is one Tresor has audited and signed off on.
  • Workload identity tag allowlist — adds a coarse-grained release-channel constraint independent of the per-build hash.
  • TCB floor — refuses to talk to a CPU/firmware combination known to be vulnerable.
  • REPORT_DATA binding — splices the TLS cert and the binary identity into the SNP report so the attestation cannot be replayed against a different cert or a different binary.
  • SPKI match — closes the loop with the live connection, defeating any TLS-terminating intermediary.

Operational notes

  • Bundle freshness. The trust bundle has a valid_until (typically 90 days). Tresor re-signs it whenever a new measurement, identity tag, or TCB floor enters the allowlist.
  • Caching. The attestation envelope itself is small (≈ 2 KB). Honour max_age_seconds.
  • Failure mode. A failed pin must abort the request. There is no useful "soft fail" mode for an attestation check.
  • Release-root rotation. Rotation requires re-pinning by every client. Tresor announces rotations at least 30 days in advance.

See also

Zero-Access Architecture

Receipts