Verification

Getting a quote back is not the same as trusting it. Verification is the set of checks that turn a raw TDX quote into a verdict: that it was produced by genuine Intel TDX hardware, that it is fresh (not replayed), that its measurements are the ones you expect, and that they match a known release. Mero TEE ships a public attestation verifier — a web app plus a stateless /api/verify serverless function — that performs these checks on a KMS attestation or against a live node.

The quote-production step this consumes is described in Attestation Flow; the register model is shared with Calimero Core’s TEE Attestation page.

What the verifier checks

The verifier establishes four independent properties. A quote is only trustworthy when all four hold.

1. Freshness (nonce binding). When the verifier fetches a node’s attestation itself, it generates a fresh 32-byte nonce, sends it, and then confirms the first 32 bytes of the quote’s own report_data equal that nonce. For a pasted KMS attestation it does the same with the nonce the operator sent to /attest, when given (nonce_b64). A mismatch means the attestation was not produced for this request — a possible replay — and is rejected. report_data, MRTD and RTMR0–3 are always read from the quote bytes Intel Trust Authority appraises, never from fields returned beside them (a node’s quote.body, a pasted reportDataHex).

   Freshness does not say the URL is the attested TD: a server there can forward the attest call to a genuine node. So a node is also asked to bind its transport key (bindTransportKey), the quote must commit to it, and the verifier opens a sealed session to that key over the same URL (/sealed/v2, one request to /admin-api/health). Only the holder of the key completes it, so transport_verified: true means the server at the URL is the attested TD, and false that it is not. A node that serves no sealed transport (only relay nodes do) reports null: the page then says the verifier cannot tell.

2. Quote authenticity (signature chain). The verifier submits the quote to Intel Trust Authority (ITA) (https://api.trustauthority.intel.com/appraisal/v2/attest by default, keyed by ITA_API_KEY). ITA cryptographically appraises that the quote came from genuine Intel TDX hardware and returns a signed JWT. The verifier then verifies that JWT’s signature against Intel’s published JWKS (https://portal.trustauthority.intel.com/certs, issuer https://portal.trustauthority.intel.com). Intel’s signature on the JWT is the trust anchor — if it does not verify, the result is reported as unverified.

3. Measurements. The ITA claims carry the quote’s measurement registers — MRTD, RTMR0–3 — and the TCB status (attester_tcb_status, e.g. UpToDate, SWHardeningNeeded, OutOfDate). The verifier surfaces these, parsed from the quote itself and cross-checked against the claims.

4. Release policy match. The verifier compares MRTD and RTMR0–3 against a signed release: for a KMS, the kms_allowed_* lists of the release’s kms-attestation-policy.<profile>.json; for a node, the profile’s entry in published-mrtds.json. All five registers pin the image — firmware, kernel, the dm-verity root hash on the command line, and the role/profile/root-hash event in RTMR3 — so a match identifies the release and profile the instance runs; no match means it is not a released image.

verifier ── nonce (32 random bytes) ──▶ node /admin-api/tee/attest
          (or: operator ── nonce ──▶ KMS /attest inside the VPC, pastes the response)
verifier ◀── { quoteB64 } ──

1. quote report_data[0..32] == nonce ?            -> freshness / anti-replay
2. quote ──▶ Intel Trust Authority ──▶ signed JWT
   verify JWT signature vs Intel JWKS              -> quote authenticity
3. read MRTD / RTMR0-3 / tcb_status                -> measurements
4. MRTD / RTMR0-3 vs signed release policy         -> known-release match

▶ Replay

Inputs the verifier accepts

/api/verify works from any one of:

• node_url — the verifier fetches /admin-api/tee/attest from a merod node (nonce generated server-side, freshness checked). Hosts are constrained by an allow-list (NODE_ALLOWED_HOSTS) and must be public addresses, redirects are not followed, and a failing node’s response body is not echoed (SSRF protection).
• attestation (+ optional nonce_b64) — a pre-fetched attestation JSON, pasted. This is the only way to verify a KMS: replicas listen only inside their VPC, so the verifier never fetches from one. Call /attest from inside the VPC with a nonce you chose and paste the response together with that nonce.

Note

Freshness is checked when the verifier chose the nonce (node_url) or was told it (nonce_b64). Without either, the verifier can still check the ITA signature and the measurements against the release, but it cannot vouch that the quote was minted for this session.

Two internal trust planes

The public verifier is the operator-facing tool. Inside the system, two automated verification relationships run continuously (see the trust model):

• A node verifies the KMS before requesting a key: it pulls a quote via /attest with a fresh nonce, refuses a debug TD, and compares the KMS’s TCB status and MRTD / RTMR0–3 against the kms_allowed_* lists of the signed release policy — the same check as step 4 above, enforced on every key fetch.
• The KMS verifies a node on every key request: the quote signature, the nonce binding, and the full measurement policy are checked in Key Release.

The public verifier reproduces the node-verifies-KMS check in an independent, third-party way by chaining through Intel Trust Authority rather than trusting any Calimero-operated component.

Release verification is separate

Runtime attestation proves what a live instance is running. It says nothing about whether a release artifact is authentic — that is established separately by the release pipeline’s Sigstore signatures and SHA-256 checksums, which prove provenance and integrity but not runtime state. Full operator trust needs both: verify the release artifacts, then attest the running instance against them. The measurement reference values and version pairings used for that comparison are managed in Policy Management.

Caution

Measurements are authoritative only when read from a verified quote. The same values taken from provisioning metadata, an image label or operator-supplied config prove nothing — only the TDX-attested values can be trusted.