Proof you can't fake: shipping dual-vendor Intel TDX + NVIDIA CC attestation for AI training claims

The last two posts in this series were about the theory of confidential computing — attesting a CPU TEE, attesting a GPU, binding a session key to the quote. This post is the theory turning into a shipped system. Over one stretch of work I took a proof-of-training pipeline from “trust the miner’s attestation JSON” to “every claim is cryptographically bound and independently verifiable” — closing three trust gaps back to back, each one found by actually trying to break the previous fix.

Table of contents

The system: proofs instead of checkpoints

The project is SparkDistill, a trustless AI-distillation economy running on SN74/Gittensor. I develop this under my GitHub handle, ai-hpc. The design goal is one I like a lot: no trained weights are ever the merged artifact. A miner submits a recipe, a dataset, and a claim — eval scores, training metadata, a per-file sha256 manifest of the checkpoint — and the validator either retrains from source to check it, or, for the fast path, verifies the claim’s proof bundle without ever downloading multi-gigabyte weights.

That fast path only works if the claim can’t be forged. The mechanism is a hash:

claim_sha256 = sha256(scores ‖ training_metadata ‖ checkpoint_manifest)

and the question the whole attestation stack answers is: can I prove this exact hash was produced by a real training run, on real hardware, inside a real confidential environment — without trusting the miner’s word for any of it?

Where it started: GPU-only binding

The baseline (v0.1.0) bound claim_sha256 into the NRAS eat_nonce — the nonce field of an NVIDIA Confidential Computing attestation, the same GPU CC mechanism from the first post. That’s a real binding: the GPU’s signed report vouches for the exact claim digest, not just “some training happened on some GPU.” But it left a gap I’d flag in any review of my own code: the GPU attests itself, not the software stack around it. Nothing measured what ran — the training harness, the recipe, the OS — only that a genuine CC-mode GPU processed a nonce equal to the claim hash. A tampered host driving a genuine GPU would still pass.

Gap 1 — the software stack was declared, not measured (#45–#47)

The fix is the CPU-side half of the story from the confidential-inference post: an Intel TDX measured VM. PR #45 adds a TDX quote captured via configfs-tsm, with the same claim_sha256 zero-padded into the quote’s 64-byte REPORTDATA field:

claim_sha256 (32 bytes) ── zero-padded ──► REPORTDATA (64 bytes) ──► TDX quote
                                                                        │
                                                             signed by CPU-fused key

The quote also carries MRTD — the measurement of the guest image itself, hashed at boot the same way the first post described for any TDX CVM. eval.verify gained a tdx_bound check: recompute the claim digest, confirm it equals the quote’s REPORTDATA. Now a claim is bound to two independent hardware roots instead of one — GPU and CPU TEE, checked separately.

I kept the scope honest in the PR: this only proves the quote commits to the claim. It says nothing yet about whether the quote itself is genuine. PR #46 re-attested the project’s baseline run live on a provisioned TDX guest to prove the mechanism actually works outside a test suite — tdx_bound: true against a real 5,247-byte quote, not a mock. PR #47 updated the public-facing docs to match: the proof-of-training claim was now GPU and TDX bound.

Gap 2 — a fabricated quote would still pass (#48)

Binding isn’t authenticity. tdx_bound: true only checks that some blob with the right REPORTDATA was recorded — a hand-crafted JSON with a fake tdx field and the correct 64 bytes would sail through the check added in #45. PR #48 closes that: verify_tdx_quote (via dcap-qvl) validates the quote’s ECDSA signature, chains the PCK certificate up to Intel’s root CA, checks QE identity, and pulls platform TCB status from live Intel PCS collateral:

TDX quote ──► ECDSA sig ✓ ──► PCK cert chain → Intel root CA ✓ ──► QE identity ✓ ──► TCB status

Reported as tdx_signature alongside tdx_bound. A clean pass looks like {"verified": true, "status": "UpToDate", "advisory_ids": []} — and stale-TCB or advisory-flagged statuses are surfaced, not silently waved through, so a validator can make its own policy call instead of the harness deciding for them.

Gap 3 — the GPU side had the exact same hole (#49)

Once I’d closed the Intel side, the NVIDIA side had the identical weakness: eval.verify took the GPU attestation JSON’s passed flag on faith, the same trust-me problem #48 had just fixed for TDX. PR #49 adds verify_gpu_token: every NRAS-signed JWT in the GPU’s Entity Attestation Token — platform and per-device — gets its ES384 signature checked against a key resolved from NVIDIA’s published JWKS by kid, with issuer (https://nras.attestation.nvidia.com) and expiry enforced. One deliberate exclusion: the SDK-local overall JWT is HS256-signed with a key the SDK itself holds, so it’s not counted as evidence — only NVIDIA’s own signature counts.

The complete chain

Three PRs later, a claim carries an authenticated, dual-vendor, triple binding instead of a single self-reported nonce:

                          claim_sha256
                         (scores + training + checkpoint manifest)
                                │
                 ┌──────────────┴──────────────┐
                 ▼                              ▼
        NRAS eat_nonce (GPU)            REPORTDATA (TDX, zero-padded)
                 │                              │
        gpu_signature: NVIDIA JWKS      tdx_signature: Intel DCAP / PCS
        (ES384, kid-resolved,           (ECDSA sig, PCK chain → Intel
         issuer + expiry checked)        root CA, QE identity, TCB status)
                 │                              │
                 └──────────────┬───────────────┘
                                 ▼
                    claim is bound to a genuine GPU
                    AND a genuine, measured TDX VM

Verified live on the project’s baseline run:

claim_bound:           true              (claim digest in the GPU attestation nonce)
gpu_signature:         true, 2 tokens    (NVIDIA JWKS, ES384)
tdx_bound:             true              (claim digest in TDX REPORTDATA)
tdx_signature:         true, UpToDate    (Intel DCAP / PCS)
checkpoint_hash_match: true

A hand-crafted attestation JSON now fails signature verification on both sides — the exact attack #45’s binding alone couldn’t stop. It shipped as v0.1.1 — “dual-vendor authenticated, measured-VM attestation.”

The honest lesson: verification found a real bug, not just a missing check

Tightening the harness surfaced something attestation alone can’t catch. The full live function test rejected honest claims on 2.1 percentage points of cross-server generation drift on a tiny three-problem Triton quick-check set — the eval server wasn’t deterministic enough for a benchmark that small to be exact. The fix wasn’t more cryptography: per-benchmark claim_tolerance_pct (5pp for the tiny Triton set) and pinning the eval server (--seed 0 --no-enable-prefix-caching). Worth saying plainly: attestation proves who ran what, not that your eval is reproducible. You still need both.

Why this is the post the last two were building toward

The TEE/GPU-CC post and the confidential-API post laid out the mechanisms in the abstract: measured boot, a signed quote, a nonce binding a key or a claim to an attested environment. Shipping #45 through #49 is what it costs to actually use those mechanisms end to end in a system with real adversarial incentive — miners who want a merged PR without doing the training. Every gap I closed was the same shape: a binding existed, but authenticity of the thing being bound to didn’t. That’s the pattern worth remembering past this one project: binding without authenticity is not attestation — it’s just a hash check with extra steps. Do both, on both vendors, or the weaker one is the one that gets exploited.