RFC-0009 §1, verbatim : « Un artefact signé par un hôte est aussi une preuve que l'état de boot mesuré de cet hôte correspond aux attentes déclarées au moment de la signature. »
01La thèse
La chaîne d'artefacts signés donne aujourd'hui à chaque membre de la flotte une identité cryptographique en logiciel. L'ancrage matériel scelle cette identité dans le silicium, gating chaque secret sur l'attestation d'état de boot, et fait du mensonge sur l'identité un chemin vers l'expulsion automatique de la flotte. Un disque volé ne donne aucun système de fichiers lisible, un hôte altéré ne peut pas parler dans la chaîne de preuves, et un hôte qui ment de manière persistante cesse d'appartenir à la flotte.
02Cinq propriétés du citoyen cryptographique
| Propriété | Mécanisme |
|---|---|
| Identifié par une clé qui ne quitte jamais le silicium | Clé de signature générée dans le TPM2, scellée contre le set PCR déclaré de l'hôte. Exportable uniquement en moitié publique. |
| Autorisé par un enrôlement bind matériel | Le bootstrap token inclut le fingerprint de la clé Endorsement Key (EK) du TPM. Le CP refuse l'enrôlement si le quote EK ne correspond pas. |
| Autorisé à parler uniquement si l'état de boot correspond à la déclaration | Chaque signature de sonde atteste simultanément "kernel + initrd + cmdline au moment de la signature correspondent à l'attendu dérivé de la closure". |
| Autorisé à déchiffrer uniquement si l'état de boot correspond à la déclaration | Secrets agenix ET clés de volume LUKS scellés contre la même politique PCR. Kernel altéré = échec d'autorisation TPM avant que le plaintext ne soit accessible. |
| Auto-expulsé s'il ment de manière persistante | Machine d'état host-attestation quarantine. Le CP cesse d'émettre des certs mTLS frais après N AttestationDrift/Invalid consécutifs. L'hôte sort de la flotte active en un cycle de renouvellement (~30 jours), observable et réversible. |
03Quatre RFCs - design-stage, critères falsifiables
Clé de signature hôte bind TPM, secrets bind PCR (agenix + LUKS scellés contre la politique de boot-state), additions au protocole boot-evidence, flux de récupération avec escrow.
Bootstrap tokens bind EK, trois rôles opérateur documentés (release / org-root / infrastructure), canaux signés à seuil (signataires à jeton matériel N-of-M), host-attestation quarantine, runbooks de rotation testés.
Staleness bornée pour les artefacts de canal (particulièrement pertinent pour l'air-gap).
Transport de bundles signés, cache binaire souverain transport-only, flux de vérification sur hôte intermédiaire.
Chaque RFC est livrée avec une section de critères falsifiables. Total ~1000 lignes réparties sur RFC-0009, RFC-0010, RFC-0011, RFC-0012. Ce ne sont pas du langage aspirationnel - ce sont des spécifications qui attendent l'effort d'implémentation.
04Ce qui est déjà livré dans cette direction
La trajectoire n'est pas greenfield. La fondation est livrée :
- Abstraction TPM keyslot (
impls/keyslots/tpm/) : génération de clé primaire, éviction de handle persistant, wrapperstpm-sign-<nom>, support de politique PCR, idempotent à travers les wipes d'impermanence. RFC-0009 ne réimplemente pas ceci - elle l'étend avec un binding à l'identité hôte. - Machinerie de vérification d'artefacts signés : la même bibliothèque
verify-artifactqui vérifie aujourd'hui les signatures release CI vérifiera demain les preuves de boot quoted-TPM sur la même chaîne. - Slots de rotation trust-root (
current/previous/successor/retireAt) sur chaque racine de confiance déclarée. - Allowlist bootstrap-token : application single-use, scoping hostname + pubkey. Le binding fingerprint EK est un champ additif.
05Pourquoi cela compte pour la régulation
NIS2 Article 21(d) - sécurité de la chaîne d'approvisionnement. Demande comment vous savez que le logiciel exécuté sur votre hôte est celui que vous aviez l'intention de livrer. La chaîne d'artefacts signés répond aujourd'hui avec closure-hash + signature cryptographique. L'ancrage matériel étend : la chaîne de boot qui a chargé la closure est aussi mesurée dans chaque signature que l'hôte produit.
NIS2 Article 21(i) - contrôle d'accès + preuves d'accès privilégié. Demande comment vous savez qui est dans votre flotte et que ces hôtes n'ont pas été remplacés. Les certs mTLS signés par votre CA de flotte répondent aujourd'hui. L'ancrage matériel étend : la clé de signature de l'hôte ne peut pas quitter le TPM, l'enrôlement est lié à l'EK matériel enregistré au déballage, et un hôte qui ment sur son état de boot est automatiquement retiré.
ANSSI BP-028 v2.0 (R7-R14, R33). Hardening kernel + boot + audit. La chaîne actuelle livre les portes statiques. La trajectoire les attache à une chaîne de mesure attestée matériellement.
DORA Articles 9 + 17. Accès + authentification, ainsi que gestion d'incident. Tous deux bénéficient du modèle échec-visible / quarantaine-réversible : un hôte défaillant n'est pas silencieusement maintenu dans la flotte, et son expulsion est auditable de bout en bout.
Trajectoires SecNumCloud / qualification ANSSI exigent le type de chaîne de confiance ancrée matériellement que les RFCs spécifient. C'est le travail qui fait passer NixFleet de « outillage NIS2-aligned crédible » à « qualifiable pour des déploiements souverains ».
06Ce que ce n'est PAS - cadrage honnête
- Pas d'engagement calendaire. Ce travail est design-stage. Les pilotes sont entrée directe pour les priorités. Nous livrons quand la spec est bonne, pas quand un deck l'a promis.
- Pas de confidential computing. La trajectoire ne défend pas contre les altérations à l'exécution après un boot unsealed réussi. Cela exige AMD SEV / Intel TDX - RFC séparée future.
- Pas d'attaques niveau bus. L'accès physique soutenu avec interception du bus TPM est hors-scope (même RFC future).
- Pas auto-magique. La dérive PCR sur une mise à jour firmware légitime exige que l'opérateur teste sur staging, bumpe
firmwareGenerationdansfleet.nix, et laisse la CI re-signer. Le framework refuse l'acceptation silencieuse des changements de chaîne de boot - le coût est aussi la valeur. - Opt-in par hôte. Pas de bascule globale. Un hôte migre vers l'identité bind TPM en le déclarant dans
fleet.nix.
07Pour un opérateur pilote
Un pilote signé en 2026 informe directement la trajectoire de confiance. Le pilote valide le modèle de chaîne d'artefacts signés sur votre matériel et face aux exigences de preuves de votre auditeur. Les travaux futurs priorisent les intégrations dont vos opérateurs ont besoin - défauts du set PCR, outillage de capture d'EK, ergonomie du flux de récupération, UX de signature à seuil - les bons défauts émergent des déploiements réels, pas du design greenfield.
C'est le compromis que les pilotes acceptent : un framework qui livre aujourd'hui et itère avec leurs retours, en échange d'influence directe sur le design qui déterminera à quoi ressemblera la confiance ancrée matériellement dans l'infrastructure régulée européenne pour la prochaine décennie.
Si votre trajectoire en a besoin sous 18–36 mois, parlons-en maintenant →