TEE backend verification (Phase 2)

​

Where this fits in the trust chain

C-Node (v6.0.0+) ──── Phase 1 ────▶ P-Node -tee image (v7.0.0+) ──── Phase 2 ────▶ Backend LLM (SecretVM)
                      (consumer                                      (this document)
                       verifies                                       P-Node verifies
                       P-Node)                                        its own backend

​

Overview

• Full attestation (AttestBackend) runs at startup and whenever the fast verify detects a backend change. It performs end-to-end cryptographic verification of the backend’s CPU TEE quote, GPU attestation evidence, workload integrity, and TLS binding.
• Fast verification (FastVerifyBackend) runs on every inference prompt. It always re-fetches the CPU quote and compares its hash and TLS binding against the cached attestation snapshot. If the quote changes, it triggers full re-attestation. There is no TTL — the fast check runs on every request unconditionally.

​

Security guarantees

• Hardware authenticity — The backend runs inside a genuine Intel TDX confidential VM with a hardware-signed attestation quote that chains back to Intel’s root of trust.
• Firmware and OS integrity — The measured boot chain (MRTD, RTMR0-2) matches entries in the SecretVM artifact registry, confirming the VM runs an authentic, unmodified SecretVM image.
• Workload integrity — RTMR3 is recalculated from the backend’s docker-compose.yaml and root filesystem data, proving the exact workload configuration running inside the TEE has not been altered.
• Model identity — The docker-compose.yaml declares which AI models are loaded. Because RTMR3 covers this file byte-for-byte, swapping, adding, or removing any model changes the hash and fails verification.
• TLS channel binding — A digest of the TLS certificate is embedded in the CPU quote’s reportData, binding the attested environment to a specific TLS identity. Current SecretVMs bind SHA-256 of the certificate’s SPKI (public key); legacy VMs bind SHA-256 of the full certificate. Either is accepted so a mixed fleet keeps verifying. This prevents man-in-the-middle attacks: inference data can only reach the attested endpoint.
• CPU-GPU binding — The GPU attestation nonce is embedded in the second half of the CPU reportData, cryptographically linking the GPU evidence to the same CPU TEE quote and preventing GPU attestation replay.
• GPU hardware authenticity — GPU attestation evidence is independently verified by NVIDIA’s Remote Attestation Service (NRAS), confirming the GPU hardware is genuine and uncompromised.
• Continuous verification — Every inference prompt triggers a fast re-check of the backend’s identity. TLS binding or quote changes between attestations are detected immediately.

​

Verification checks

​

Full attestation flow

​

Step by step

1. Fetch CPU quote — The proxy-router requests the raw TDX attestation quote from the backend’s attestation port (:21434/cpu).
2. Verify CPU quote — The quote is sent to the SecretAI Portal’s quote-parse API, which performs cryptographic verification against Intel’s root of trust.
3. TLS binding — The proxy-router computes both the SHA-256 of the connection certificate’s SPKI (current binding) and of the full certificate DER (legacy binding) and compares the first 32 bytes of the quote’s reportData against either. A match proves the TLS endpoint is inside the attested TEE.
4. Workload verification (if artifact registry is loaded):
   • Fetch docker-compose.yaml from the backend. Old attest-rest serves it wrapped in an HTML <pre> block, newer attest-rest serves the raw bytes; both the raw response and the HTML-extracted content are tried against the measurement.
   • Parse the TDX quote to extract measurement registers (MRTD, RTMR0-3).
   • Look up MRTD + RTMR0-2 in the artifact registry to confirm this is a recognized SecretVM build.
   • Recalculate the expected RTMR3 from SHA-256(docker-compose.yaml) combined with rootfs_data using a SHA-384 extend chain.
   • Compare the calculated RTMR3 against the quote’s RTMR3 to prove workload integrity.
5. Fetch GPU attestation — Retrieve GPU attestation data (JSON containing nonce, architecture, and evidence list) from :21434/gpu.
6. CPU-GPU binding — Verify that the second 32 bytes of the CPU reportData match the GPU nonce, proving both attestations originate from the same machine and session.
7. NRAS verification — Submit GPU evidence to NVIDIA’s Remote Attestation Service (/v4/attest/gpu) for independent hardware validation. NRAS returns a signed JWT (Entity Attestation Token); the proxy-router requires the request to succeed, the x-nvidia-overall-att-result claim to be true, and the attested eat_nonce to equal the CPU-bound nonce. NRAS failure is fatal by design: attestation fails and the model’s snapshot is stored as failed. The attesting node therefore needs network access to nras.attestation.nvidia.com (NVIDIA’s edge blocks some IPs/regions with a 403).
8. Cache snapshot — Store the attestation result (quote hash, TLS binding, workload status) for use by the fast verification path. The cache has no TTL — it remains valid as long as the backend’s CPU quote and TLS certificate haven’t changed.

​

Trust chain

​

Measurement registers

​

reportData layout

​

Per-prompt fast verify

​

Fast verify logic

1. Cache check — If no cached attestation exists (model was never attested), reject the request.
2. Status check — If the cached status is failed, run a full re-attestation before proceeding.
3. Re-fetch CPU quote — Always request the current CPU quote from :21434/cpu (~50 ms TLS handshake).
4. Hash comparison — Compute SHA-256 of the fetched quote and compare against the cached hash. A mismatch indicates the backend has changed (restart, redeployment) and triggers full re-attestation.
5. TLS binding comparison — Verify the current connection’s certificate digest matches the cached value. If the full-certificate digest differs but the SPKI digest matches (certificate renewed with the same TEE-resident key), full re-attestation runs instead. If neither matches, it is treated as a critical error (possible MITM attack) and the request is rejected immediately.
6. Pass — If both checks succeed, the inference request proceeds to the backend.

​

Model identity guarantee

MODELS='deepseek-r1:70b gemma3:4b llama3.2-vision llama3.3:70b qwen3:8b'

• Changing any byte of docker-compose.yaml — swapping qwen3:8b for a different model, altering a port binding, modifying an environment variable — produces a different RTMR3 value.
• The TDX hardware enforces that measurement registers reflect the actual loaded software. Values cannot be faked or overridden from within the VM.
• The proxy-router independently recalculates the expected RTMR3 and compares it against the hardware-reported value. Any discrepancy fails verification.

​

Configuration reference

​

Model tagging (on-chain)

• On the provider side: performs full AttestBackend against that model’s apiUrl host at startup, and runs FastVerifyBackend on every inference prompt (see Per-prompt fast verify).
• On the consumer side: runs VerifyProviderQuick against the provider’s P-Node at session open and on every prompt, refusing to forward inference if attestation fails.

func IsTeeModel(tags []string) bool {
    for _, raw := range tags {
        if strings.ToLower(raw) == "tee" {
            return true
        }
    }
    return false
}

​

Backend attestation endpoint derivation

• https://backend.example.com:21434/cpu — TDX CPU quote
• https://backend.example.com:21434/gpu — GPU attestation evidence
• https://backend.example.com:21434/docker-compose — backend’s compose file for RTMR3 replay

​

Environment variables

​

Health endpoint

GET /v1/models/attestation

• Attestation state (verified, pending, failed)
• Timestamp of last successful attestation
• Workload verification result (authentic_match, authentic_mismatch, not_authentic)
• TLS binding kind that matched (spki or certificate)
• Error details if verification failed

​

Architecture

​

Integration points

• ProxyReceiver.SessionPrompt — Calls FastVerifyBackend before forwarding each inference request for TEE-marked models. This is the per-prompt hot path. The fast verify re-fetches the CPU quote from the resolved attestation port and compares its hash and TLS binding against the cached snapshot. If the backend has changed, full re-attestation runs before the request proceeds.

​

Security gaps

​

Gap 1: No binding between blockchain model name and models-config

​

Gap 2: No binding between models-config and docker-compose.yaml

​

Gap 3: Multi-model docker-compose ambiguity

​

What is actually proven today

​

Possible directions

• Docker-compose model registry (off-chain) — maintain a curated registry of (docker-compose hash → model list) mappings, similar to the existing TDX artifact registry. When workload verification succeeds, look up the verified compose hash to get the models it contains, then check the consumer’s requested model against that list. No compose parsing needed, but every compose change needs a registry update.
• Parse docker-compose content — after fetching and verifying the compose, extract the MODELS environment variable and compare against the modelName from models-config. No external registry, but fragile: different backends (Ollama, vLLM, TGI) declare models differently.
• Backend model enumeration endpoint — use the LLM server’s /models endpoint (served from within the TEE over the attested TLS channel) and compare the returned list against the consumer’s requested model. Simple and backend-agnostic, but the list is self-reported by the backend software rather than measured into attestation registers.