Attestation Flow
KMS self-attestation and public verification via Intel Trust Authority
Two Attestation Paths
The system supports two attestation paths: (1) KMS self-attestation via POST /attest, used by nodes during Plane 1 verification and by the public verifier; and (2) public verification via the Attestation Verifier web app, which chains the KMS attestation through Intel Trust Authority for independent validation.
KMS Self-Attestation
The POST /attest endpoint lets any caller obtain a fresh TDX quote from the KMS. This is the foundational building block for both node verification (Plane 1) and the public attestation verifier.
Request
Content-Type: application/json
{
"nonce": "hex-encoded-bytes" // caller-provided freshness nonce
}
Response
Content-Type: application/json
{
"quote": "base64-encoded-tdx-quote" // raw TDX quote from dstack
}
Internal Flow
Report Data Construction
The KMS constructs report_data = SHA256(nonce || binding_data) before requesting the quote from dstack. The binding_data may include additional context (e.g., KMS version). The caller can verify the nonce is included in the quote’s report_data to confirm freshness.
Public Attestation Verifier
The attestation verifier is a public web application that allows anyone to verify a KMS instance is running inside a genuine TDX enclave. It chains the KMS’s self-attestation through Intel Trust Authority for independent verification.
Full Verification Flow
Verification Details
What the Verifier Checks
Quote Authenticity
Intel Trust Authority cryptographically verifies the TDX quote was produced by genuine Intel TDX hardware. The ITA signature on the returned JWT is the trust anchor.
Freshness
The verifier generates a fresh nonce for each request. The nonce appears in the quote’s report_data, proving the attestation was produced for this specific verification session.
Measurements
The JWT contains MRTD, RTMR0–3 values. The verifier displays these for manual comparison against known-good values published in release notes.
TCB Status
The JWT includes the TCB (Trusted Computing Base) status: UpToDate, SWHardeningNeeded, OutOfDate, etc. This indicates the platform’s security patch level.
JWT Claims Displayed
"attester_tcb_status": "UpToDate",
"attester_type": "TDX",
"tdx_mrtd": "a1b2c3...",
"tdx_rtmr0": "d4e5f6...",
"tdx_rtmr1": "...",
"tdx_rtmr2": "...",
"tdx_rtmr3": "...",
"tdx_report_data": "...",
"advisory_ids": ["INTEL-SA-..."],
"iat": 1700000000,
"exp": 1700003600
}
Architecture
Frontend
React single-page application. User inputs a KMS URL and optional binding data. Results are displayed in a structured, readable format with color-coded status indicators.
React TypeScript
Backend
Serverless API function (/api/verify). Handles nonce generation, KMS communication, ITA integration, and JWT validation. Stateless — no database required.
serverless TypeScript
Node Usage (Plane 1)
When a merod node boots, it uses the same POST /attest endpoint to verify the KMS before requesting its storage key. The flow is simpler than the public verifier — the node performs its own quote verification without going through ITA.
Generate Nonce
The node generates a random nonce locally.
Call POST /attest
Send the nonce to the KMS. Receive the raw TDX quote.
Verify Quote Locally
The node verifies the TDX quote signature, checks report_data contains the nonce, and compares MRTD against known-good KMS measurements embedded in its configuration.