goodpoint-box: verify enclave quote chains for e2ee inference keys (drop TOFU)

[amiller]

Today both e2ee clients trust enclave pubkeys on first use:

• near_e2ee.ts getKey() fetches GET /attestation/report?model=…&signing_algo=ecdsa and takes model_attestations[].signing_public_key straight out of the response — the attestation evidence in that same report is never checked.
• chutes_e2ee.ts instance() takes e2e_pubkey (+ nonce) from instance discovery, unverified.

So a compromised/MITM'd provider control plane could hand us a key that lives outside any enclave, and we'd encrypt the room's words to it. Verification means:

• NEAR (TDX+H100): verify the DCAP/TDX quote chain in the attestation report, check report_data actually binds signing_public_key, check measurements against expected values, and verify GPU evidence (NRAS) for the H100 side.
• Chutes (NVIDIA CC): verify the instance attestation binding e2e_pubkey, with nonce freshness.

Where it goes. Two options:

1. Inline in the two client files, per app. Quick, but every sibling app on the pod duplicates it.
2. Normalize at the pod level: the webhost already normalizes inbound trust (dstack: domain bound to attested app identity, keys derived only in the enclave) — do the same for outbound provider enclaves. One verifier on the tee-daemon (or a bitrouter-attestation role) verifies quotes once, pins the keys, and exposes a verified-key registry to sibling apps (goodpoint-box, interleave, otterpilot). dstack's own attestation stack doesn't cover this direction, but the same DCAP verification dependency (e.g. dcap-qvl) can be reused.

Leaning (2) — it's the same move dstack webhost already made for inbound trust, and it makes "verify the quote chain" a property of the pod rather than a chore for each app.

Acceptance: a forged/unattested pubkey is rejected in a test; verified keys cached with expiry + re-attestation; both providers covered.

---

Split (operator, 2026-08-16): the NEAR half now lives in #146 with its own ## Acceptance (delivered by PR #106; the merge gate closes #146, not this issue). What remains HERE: the Chutes (NVIDIA CC) half — verify the instance attestation binding e2e_pubkey with nonce freshness, dropping TOFU in chutes_e2ee.ts — plus the pubkey-cache expiry + re-attestation follow-up (the NEAR cache added in #106 is process-lifetime). This issue stays open with needs-spec until the remaining half is written up.

[amiller]

Candidate implementation for option (2): the bitrouter-attestation crate (crates.io, v1.0.0-alpha.25 as of 7/12, dcap-qvl 0.5). Its design is exactly this shape: enforce-at-route gateway hook with a refuse-unpinned policy, report_data binding key‖nonce — i.e., the TOFU fix.

Current usage on the pod: none. The only bitrouter reference is router-dashboard's optional OpenAI-compatible LLM_BASE=https://api.bitrouter.ai/v1 — that's routing, not verification. goodpoint-box's e2ee clients talk to NEAR/Chutes directly.

Integration shape: the crate is Rust, pod apps are Deno — so it runs in (or beside) the tee-daemon as the outbound gateway, exposing the verified-key registry described above. Its enforce-at-route hook matches that locus.

To confirm before adopting:

• bitrouter#566 (DCAP TCB status discarded) and bitrouter#567 (legitimacy anchored only to RTMR3) were closed 6/16–6/18 but the closing fix was never verified — check that current alphas enforce a TCB status floor and pin MRTD/RTMR0–2.
• NVIDIA GPU evidence (NRAS) for the H100 / NVIDIA-CC side: dcap-qvl covers the TDX quote only; hermes-agent is the reference for the NRAS + live-TLS binding piece. May need to pair the crate with that.
• Prefer the dstack ACI policy (AciDcapVerifierPolicy, docs: add Attested Confidential Inference draft Dstack-TEE/dstack#694) so pins follow the shared convention.