docs(protocol): add Chain of Trust page (TEE foundation & boot-time attestation)

[raorla]

Summary

Adds a new Chain of Trust page to the Protocol section, documenting how Nox
establishes a verifiable chain of trust from Intel TDX hardware up to the running
off-chain workloads, through boot-time attestation.

This is Part 1 — the foundation: the TEE layer (Intel TDX), the dstack
orchestration layer, the deployment architecture, and the boot-time gating
mechanism (no known measurement → no keys → no service). It also covers sealed
environment variables and Proof-of-Cloud hardware provenance.

Changes

• src/protocol/chain-of-trust.md: new page (/protocol/chain-of-trust).
• src/assets/images/chain-of-trust.png: deployment architecture diagram.
• .vitepress/sidebar.ts: added a "Chain of Trust" entry to the Protocol section
  (after "Protocol Vision").

Notes

• Verified locally: prettier --check passes and vitepress build completes
  successfully (image bundled and referenced correctly).
• Content sourced from the internal Confluence page "Chain of Trust for Nox –
  Part 1: TEE foundation and boot-time attestation".

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
nox-documentation	Ready	Preview, Comment	Jul 16, 2026 10:27am

[Copilot]

Pull request overview

Adds a new Protocol documentation page describing Nox’s boot-time attestation “chain of trust” (Intel TDX → dstack orchestration/gating → workload start), and exposes it in the Protocol sidebar navigation.

Changes:

• Added a new /protocol/chain-of-trust page covering TDX roots of trust, dstack gating, sealed env vars, and Proof-of-Cloud provenance.
• Added the new page to the Protocol section of the VitePress sidebar.
• Added a deployment architecture diagram image referenced by the page.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/protocol/chain-of-trust.md	New “Chain of Trust” documentation page (Part 1: TEE foundation & boot-time attestation) with architecture and boot-gating explanation.
src/assets/images/chain-of-trust.png	Diagram asset referenced by the new documentation page.
.vitepress/sidebar.ts	Adds “Chain of Trust” entry to the Protocol sidebar for navigation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[64ix]

Code Review — Chain of Trust page

Review assistée (Claude Code) : ~30 affirmations techniques vérifiées contre le code source (iExec-Nox/dstack@1c2c1ac, dstack-setup, dstack-deployment), 13 liens externes testés, build VitePress + prettier exécutés sur la branche.

Résumé

Page de très bonne qualité : sur l'ensemble des affirmations techniques vérifiées contre le code, une seule est factuellement inexacte. Les 13 liens externes sont valides (tous les repos GitHub cités sont bien publics, portail d'attestation live, post X et article Phala vérifiés), le build VitePress passe, prettier passe, le sidebar est correct.

🔴 À corriger avant merge

1. « Gramine Sealing Key Provider … during its first boot » est inexact — src/protocol/chain-of-trust.md l.135 (tableau) et l.183–187.

Dans le code (dstack-util/src/system_setup.rs, setup_fs → get_keys_from_local_key_provider), la sealing key est récupérée à chaque boot du dstack-KMS — c'est ainsi qu'il re-dérive sa disk_crypt_key pour monter son disque chiffré à chaque redémarrage. Seule la génération des root keys (ca_key/k256_root/rpc_key) est first-boot-only (cf. docs/kms-boot-sequence.md, phase Bootstrap vs Onboarding). Le paragraphe l.183–187 conflate les deux.

Correction suggérée : préciser que la sealing key est obtenue du SGX key provider à chaque boot (après preuve d'identité mesurée), et que ce sont les root keys du protocole qui ne sont générées qu'au premier boot.

🟡 Suggestions

#	Localisation	Suggestion	Catégorie
2	l.165–170	Le « all five checks pass » incluant le device id est exact dans le code (kms/auth-simple/index.ts:89-196), mais les templates de déploiement (dstack-setup/.../auth-config.json.template) mettent allowAnyDevice: true, ce qui rend le check device-id vacant en pratique. Soit le déploiement réel l'active, soit nuancer (« when device pinning is enabled »).	Exactitude
3	chain-of-trust.png	4096×4078 px, 1,3 Mo — plus du double de la plus grosse image existante du site (516 Ko). À redimensionner (~1600 px de large) et compresser.	Performance
4	l.59, 137	L'Ingestor est nommé deux fois mais jamais lié vers /protocol/ingestor, alors que Runner/Handle Gateway/KMS sont systématiquement liés.	Cohérence
5	l.267	## Further Reading — toutes les autres pages Protocol terminent par ## Learn More.	Convention
6	l.100–120	Collision de nommage « KMS » : le dstack-KMS (provisioning des clés de boot) et le Nox KMS (/protocol/kms, clé privée du protocole) sont deux composants distincts très proches dans le texte. Une phrase de désambiguïsation à la première mention de dstack-KMS éviterait la confusion.	Clarté
7	l.134	La ligne auth-config.json du tableau omet les champs devices/allowAnyDevice que le schéma porte aussi (lié au point 2).	Complétude

Nits

• l.21–22 : « convinced of a non-trivial property » (singulier) suivi de trois puces — « properties » ou reformuler.
• l.243–245 : l'état ponctuel de la flotte (node1 OVH avec seal, node2 phoenixNAP sans) vieillira vite ; envisager un renvoi vers le portail d'attestation comme source de vérité plutôt qu'un inventaire figé.
• « Nox CVMs exporter » et « dstack-agent » sont des noms informels (composants réels : dstack-consul-cvms-agent, dstack-guest-agent) — acceptable pour de la doc.

Incohérences avec les pages existantes (hors scope de cette PR)

La nouvelle page est plus juste que l'existant sur trois points, à corriger dans une PR séparée :

• protocol-vision.md (Code Integrity) affirme au présent que les hashes autorisés sont « recorded in the on-chain Registry » — la whitelist est off-chain aujourd'hui, comme cette page le dit correctement.
• protocol-vision.md (Proof of Cloud) décrit un mécanisme à base de TPM, différent du mécanisme réel décrit ici (PPID Intel DCAP + registre de la Proof of Cloud Alliance).
• runner.md l.19 : « the only component that manipulates plaintext values » — faux, la Handle Gateway manipule aussi du plaintext.

✅ Ce qui est solide

• Les 5 checks de Boot Authorization, l'extension dans RTMR[3] (compose_hash/app_id/instance_id), le flux sealed env vars (X25519 éphémère + AES-256-GCM, filtrage allowed_envs), la disk_crypt_key/LUKS, le contrat DstackKms gardé off-chain, et le comportement du dstack-gateway (ACME, WireGuard, load-balancing par app_id) : tous vérifiés exactement contre le code.
• Les 4 documents de séquence référencés existent bien sur iExec-Nox/dstack@master.
• Frontmatter, containers ::: info/::: tip, casse des titres : conformes aux conventions du site.

Verdict

Request Changes (léger) — corriger le point 1 (seule vraie erreur factuelle), idéalement traiter les points 2–5, et c'est mergeable. Le fond technique est remarquablement fidèle au code pour une page de cette densité.