Instancier sa chaîne OC2 souveraine : le guide BITD

OC2-Edge est publié sous licence Apache-2.0. Le dépôt public contient le socle : OS immuable à démarrage vérifié, modules signés et révocables, cryptographie post-quantique, maillage multi-porteuses, image tactique dans un navigateur. Ce socle ne devient un système opérationnel qu’au moment où un acteur l’instancie : il génère ses propres clés, reconstruit ses propres images, opère son propre dépôt de mise à jour et constitue son propre dossier de preuves.

Cet article décrit ce que contient une instance, dans quel ordre la monter, comment plusieurs instances se fédèrent, et ce que le mot « souverain » recouvre précisément dans ce contexte. Il condense le guide d’instance du dépôt, qui reste la référence en cas d’écart.

À qui s’adresse ce guide

Quatre profils de la base industrielle et technologique de défense (BITD) instancient OC2-Edge pour des raisons différentes.

Le maître d’œuvre intègre OC2-Edge comme couche C2 (commandement et contrôle) d’un système de systèmes. Son besoin : auditer le socle ligne à ligne, maîtriser la chaîne de signature de ses livrables, et prouver à son client étatique que la chaîne de mise à jour de la flotte ne dépend d’aucun tiers. Une instance complète, avec autorité de certification et dépôt de mise à jour, répond à ce besoin.

L’équipementier de taille intermédiaire (ETI) livre un sous-système : senseur, effecteur, radio, calculateur. Son besoin : qualifier ses modules et ses Provider Packs dans un environnement représentatif avant livraison au maître d’œuvre. Une instance légère sur émulateur suffit ; elle partage les mêmes outils que l’instance de production du maître d’œuvre.

La startup édite un module spécialisé : fusion de pistes, analyse de spectre, logistique de l’avant. Son besoin : développer et signer sans matériel dédié. Le socle s’émule en x86-64 et en ARM64 ; une instance minimale tient sur un poste de développement.

Le service étatique (centre d’essais, direction technique, unité) monte une instance d’évaluation pour instruire une homologation, rejouer les preuves publiées ou comparer des offres industrielles sur une base commune.

Dans les quatre cas, la mécanique est identique. Aucun compte à créer chez Cercle Digital, aucune licence à activer, aucun serveur tiers à contacter.

Ce qui est commun, ce qui est à vous

Instancier ne veut pas dire refaire. Le partage des rôles entre le socle et l’instance est le suivant.

Reste commun, maintenu dans le dépôt public : le code du socle, les ~930 tests automatisés, les 9 chaînes CI, les schémas de manifeste, la documentation et les gabarits. Une instance rejoue ces éléments ; elle n’a pas à les réécrire, et les correctifs du socle lui parviennent par le canal open source ordinaire.

Devient propre à l’instance : les clés, les images construites, le dépôt de mise à jour, le catalogue de modules approuvés et le dossier de preuves. Ces cinq objets ne transitent jamais par Cercle Digital ; ils naissent chez l’opérateur et y restent.

La frontière est nette : tout ce qui engage la confiance de la flotte est à l’instance, tout ce qui relève de l’ingénierie du socle est mutualisé. Une instance minimale (startup, évaluation) peut différer les briques 4 et 5 ; une instance de production les monte toutes les cinq.

Les cinq briques d’une instance

Une instance complète comporte cinq briques. Chacune correspond à un chapitre du guide d’instance du dépôt.

Brique 1 : l’usine à images

L’usine à images produit les images d’OS de la flotte : images A/B signées, UKI (Unified Kernel Image), démarrage vérifié. La propriété structurante est la reproductibilité bit à bit : deux compilations indépendantes des mêmes sources, avec la même chaîne d’outils, produisent des artefacts identiques à l’octet près [5].

La conséquence pratique : l’opérateur d’instance ne fait pas confiance aux binaires publiés par Cercle Digital. Il rejoue le build sur sa propre infrastructure et compare les empreintes avec celles publiées par les 9 chaînes CI du dépôt. Une divergence d’un seul octet est détectable et bloquante. Les ~930 tests automatisés du dépôt public se rejouent de la même manière, sur l’infrastructure de l’opérateur.

La reproductibilité impose une discipline que le dépôt outille : chaîne d’outils épinglée par version et par empreinte, dépendances vendorées dans le dépôt, horodatages et chemins de build normalisés [5]. L’usine à images d’une instance est donc un environnement décrit, pas une machine artisanale : la description d’environnement fait partie du dépôt, et deux instances distinctes qui l’appliquent produisent les mêmes octets.

Brique 2 : l’autorité de certification de flotte

L’instance opère sa propre infrastructure de gestion de clés (PKI). L’architecture suit les recommandations classiques de gestion de clés : séparation des rôles, protection de la racine, durées de vie bornées [6][7].

La racine est générée hors ligne, lors d’une cérémonie de clés documentée, sur une machine qui ne se connecte jamais à un réseau. Elle est conservée sous clé, sur support déconnecté. Trois autorités intermédiaires en dérivent : signature d’images, signature de modules, identité des nœuds. Les signatures utilisent ML-DSA-65 (FIPS 204) ; les échanges de clés utilisent le KEM hybride X25519MLKEM768.

Le point non négociable : la clé racine de l’instance n’existe que chez l’opérateur. Cercle Digital ne la voit jamais, ne la contresigne pas, et ne peut ni la révoquer ni la remplacer.

La PKI de flotte se dimensionne dès la cérémonie : durées de vie des intermédiaires bornées, procédure de rotation écrite avant la première signature, procédure de révocation testée sur l’émulateur avant d’être nécessaire en opération. Le guide d’instance fournit les gabarits de ces procédures. La règle d’usage est celle des référentiels de gestion de clés : une clé dont le plan de retrait n’existe pas ne doit pas entrer en service [6].

Brique 3 : le dépôt TUF

Les mises à jour de la flotte transitent par un dépôt conforme à TUF (The Update Framework) [1]. TUF répartit la confiance sur quatre rôles signataires :

1. root : la racine de confiance, signée hors ligne, qui désigne les clés des trois autres rôles ;
2. targets : les artefacts livrables (images, modules) et leurs empreintes ;
3. snapshot : l’état cohérent de l’ensemble du dépôt à un instant donné ;
4. timestamp : la preuve de fraîcheur, signée fréquemment, qui empêche de servir un état ancien.

Cette répartition apporte la résistance à la compromission du dépôt : un attaquant qui prend le contrôle du serveur de dépôt ne peut ni forger une mise à jour valide, ni faire accepter une version obsolète, tant que les clés hors ligne (root, targets) restent saines [1]. La spécification prévoit aussi les seuils de signatures : un rôle peut exiger plusieurs clés distinctes pour valider une publication, ce qui permet à un opérateur d’imposer une règle des deux personnes sur les images de flotte [1]. La rotation des clés d’un rôle est une opération normale du cycle de vie, décrite par la spécification, et non un incident.

Le projet Uptane applique le même cadre aux flottes de véhicules, avec des contraintes d’embarqué proches des nôtres : liens intermittents, nœuds à faibles ressources, mises à jour partielles. Sa spécification a guidé la déclinaison flotte d’OC2-Edge [2].

Brique 4 : le magasin de modules

Le magasin de modules est le catalogue des modules approuvés pour la flotte de l’instance. Chaque entrée contient le manifeste du module, sa signature, son niveau d’isolation (natif, microVM ou WASI) et son état (actif, suspendu, révoqué). Le magasin est propre à chaque instance : l’opérateur décide seul de ce qui y entre et de ce qui en sort.

L’entrée au magasin suit une procédure définie par l’opérateur, que le guide d’instance structure en trois contrôles : validation du manifeste contre le schéma du socle, vérification de la signature de l’éditeur, décision d’approbation tracée avec le niveau d’isolation imposé. Un module tiers non audité entre en isolation WASI ou microVM ; le niveau natif reste réservé aux modules revus. La révocation d’un module se propage à la flotte par le dépôt TUF, comme une mise à jour ordinaire, et prend effet sans attendre le prochain cycle d’images. Le parcours de création d’un module est décrit dans un article dédié.

Brique 5 : le kit d’homologation d’instance

Le kit d’homologation structure les preuves que l’instance produit. Le dossier type comporte cinq volets :

1. les empreintes de build reproductible et le journal de leur comparaison avec les empreintes publiées ;
2. les résultats des tests rejoués sur l’infrastructure de l’instance ;
3. le procès-verbal de cérémonie de clés et les politiques de rotation et de révocation ;
4. l’inventaire des composants du socle et des modules approuvés ;
5. le journal des décisions d’approbation du magasin de modules.

Le kit fournit la structure du dossier et les gabarits ; la décision d’homologation reste celle de l’autorité compétente de l’opérateur. Le kit évite un écueil précis : dépendre des preuves d’un éditeur que l’autorité ne peut pas rejouer. Une autorité qui doute d’un volet le rejoue elle-même, avec les mêmes outils.

Le pas à pas condensé

L’environnement type comporte trois machines : une machine de build connectée au réseau interne, une machine de cérémonie qui ne se connecte jamais à aucun réseau, et un serveur qui héberge le dépôt de mise à jour de l’instance. L’ensemble se rejoue aussi sur un poste unique avec l’émulateur, pour une instance d’évaluation.

Les commandes ci-dessous illustrent l’enchaînement. Elles sont génériques ; la documentation du dépôt donne les options exactes et prime en cas d’écart. <URL_DU_DEPOT> désigne le dépôt public d’OC2-Edge.

1. Cloner et vérifier le dépôt.

git clone <URL_DU_DEPOT> oc2-edge
cd oc2-edge
git verify-commit HEAD

Sortie attendue : signature de commit valide, chaînée à la clé de publication du projet.

2. Rejouer le build reproductible et comparer les empreintes.

./ci/build-image.sh --profile node-x86_64
./ci/compare-digests.sh --against release-manifests/

Sortie attendue : une image UKI signée et un verdict d’égalité stricte entre vos empreintes et celles publiées. Toute divergence arrête la procédure.

3. Générer la racine hors ligne. Sur une machine déconnectée, dédiée à la cérémonie :

oc2 ca init --root --algo ml-dsa-65
oc2 ca issue --intermediate images
oc2 ca issue --intermediate modules
oc2 ca issue --intermediate nodes

Sortie attendue : une racine et trois intermédiaires. La racine part sous clé sur support déconnecté ; seuls les intermédiaires rejoignent les machines de travail. La cérémonie fait l’objet d’un procès-verbal signé par les témoins.

4. Initialiser le dépôt TUF de l’instance.

oc2 tuf init --repo https://depot.exemple.mil/oc2
oc2 tuf delegate --role targets --key targets.pub
oc2 tuf snapshot
oc2 tuf timestamp

Sortie attendue : les métadonnées des quatre rôles, la racine TUF signée hors ligne.

5. Publier la première image.

oc2 tuf add --target out/oc2-node-x86_64.img
oc2 tuf sign --role targets
oc2 tuf publish

Sortie attendue : l’image et son empreinte inscrites dans targets, un nouvel état snapshot et un timestamp frais.

6. Enrôler le premier nœud.

oc2 node enroll --serial <NUMERO_DE_SERIE> --ca nodes
oc2 node update --from https://depot.exemple.mil/oc2

Sortie attendue : le nœud reçoit son identité, vérifie la chaîne TUF, installe l’image sur la partition passive, bascule A/B au redémarrage suivant.

7. Ouvrir le dossier d’homologation. Le kit de la brique 5 s’initialise avec les preuves produites aux étapes 2 à 6 et se complète au fil de la vie de l’instance.

À l’issue de ces sept étapes, l’instance est autonome : elle construit, signe, distribue et prouve sans intervention extérieure.

Fédérer des instances sans les fusionner

Une coalition n’est pas une flotte unique. Chaque nation, chaque industriel, conserve son instance, ses clés et sa politique. La fédération repose sur trois mécanismes.

Les labels de confidentialité. Chaque objet échangé (piste, message, fichier) porte un label conforme à ADatP-4774, la syntaxe OTAN des labels de confidentialité [3]. Le label est lié cryptographiquement à l’objet selon le mécanisme ADatP-4778 [4] : il ne peut être ni détaché ni substitué sans invalider la signature.

La releasability par nation. La diffusion se décide par politique, objet par objet, sur la base du label : un objet marqué diffusable vers une nation la traverse, un objet non marqué reste dans l’instance d’origine. La séparation n’est plus portée par des silos réseau, elle est portée par les données.

Le roster convergent. Les instances échangent un annuaire des participants (nœuds, unités, capacités) qui converge par échanges pair à pair, sans autorité centrale. Deux instances qui se resynchronisent après une coupure aboutissent au même état d’annuaire, quel que soit l’ordre des échanges. L’architecture de fédération est traitée en détail dans La coalition dans le code.

La fédération hérite des propriétés du socle : elle fonctionne en liens intermittents, se dégrade de manière contrôlée quand une instance devient injoignable, et reprend sans procédure exceptionnelle quand le lien revient. Une instance se fédère donc sans céder ses clés ni ouvrir son dépôt : elle expose des objets labellisés, pas son infrastructure.

Ce que « souverain » veut dire ici

Le mot est employé souvent et défini rarement. Pour une instance OC2-Edge, il se vérifie sur trois possessions et une absence de dépendance.

Vous possédez vos clés. La racine de l’instance est générée chez vous, hors ligne, et n’est transmise à personne. Aucune clé de Cercle Digital n’est en position de signer pour votre flotte.

Vous possédez vos builds. Les images que vos nœuds exécutent sortent de votre usine à images. La reproductibilité bit à bit vous permet de prouver qu’elles correspondent aux sources auditées [5], sans faire confiance à un binaire tiers.

Vous possédez vos preuves. Le dossier d’homologation est constitué de mesures que vous avez produites et que votre autorité peut rejouer.

Aucune dépendance à Cercle Digital pour opérer. Pas de serveur d’activation, pas de licence à renouveler, pas de télémétrie obligatoire, pas d’appel réseau vers l’éditeur. La licence Apache-2.0 garantit le droit de fork : si Cercle Digital disparaît ou change d’orientation, chaque instance continue d’opérer et l’écosystème peut reprendre le socle.

La souveraineté ainsi définie n’est pas une déclaration ; c’est une propriété testable. Le test tient en trois questions à poser à tout fournisseur, OC2-Edge compris. Qui peut signer une image que ma flotte acceptera : si la réponse inclut quelqu’un d’autre que vous, vos clés ne sont pas à vous. Qui peut reconstruire le binaire que ma flotte exécute : si la réponse est personne, vos builds ne sont pas à vous. Qui peut rejouer les preuves de mon dossier d’homologation : si la réponse est seulement l’éditeur, vos preuves ne sont pas à vous. Le guide d’instance du dépôt indique comment obtenir trois fois la bonne réponse.

Sources

1. The Update Framework, « The Update Framework Specification », 2024, https://theupdateframework.github.io/specification/latest/
2. Uptane Alliance, « Uptane Standard for Design and Implementation », 2024, https://uptane.org/
3. NATO Standardization Office, « ADatP-4774, Confidentiality Metadata Label Syntax, Edition A », 2017, https://nso.nato.int/nso/nsdd/main/standards/ap-details/1967/EN
4. NATO Standardization Office, « ADatP-4778, Metadata Binding Mechanism, Edition A », 2018, https://nisp.nw3.dk/standard/nato-adatp-4778-ed.a-v1.html
5. Reproducible Builds, « Definition of a reproducible build », 2024, https://reproducible-builds.org/docs/definition/
6. NIST, « SP 800-57 Part 1 Rev. 5, Recommendation for Key Management », 2020, https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
7. ANSSI, « Mécanismes cryptographiques : règles et recommandations », 2021, https://cyber.gouv.fr/publications/mecanismes-cryptographiques