La coalition dans le code : labels, releasability et le partenaire sous-habilité

Une coalition n’échange pas ses informations en bloc. Chaque nation, chaque industriel, chaque échelon reçoit ce que sa politique de partage autorise, et rien de plus. Les systèmes qui ne savent pas exprimer cette granularité finissent dans l’un de deux excès : tout partager par un canal unique, ou ne rien fédérer du tout. OC2-Edge inscrit la décision de partage dans le socle, au niveau du message. Cet article décrit le mécanisme, les standards sur lesquels il repose, et les preuves associées dans le dépôt.

Diffuser, expurger, bloquer

Pour chaque message sortant et pour chaque partenaire destinataire, le nœud prend une décision parmi trois.

1. Diffuser : le partenaire est habilité pour l’intégralité du message. Il le reçoit tel quel.
2. Expurger : le partenaire est habilité pour une partie du message. Il reçoit une version réduite, dont les fragments non partageables sont retirés.
3. Bloquer : le partenaire n’est habilité pour aucune partie du message. Il ne reçoit rien, et ne voit pas qu’un message a existé.

La décision est prise message par message et partenaire par partenaire. Il n’existe pas de commutateur global « mode coalition » : deux partenaires du même maillage peuvent recevoir deux vues différentes du même flux, chacune conforme à la politique qui les concerne.

Un exemple fixe les idées. Une position amie est produite avec un commentaire de renseignement sur la source de la détection. La nation partenaire pleinement habilitée reçoit la position et le commentaire. Le partenaire industriel qui opère un lot logistique reçoit la position seule : le commentaire, marqué d’un caveat qui ne le concerne pas, est retiré. L’observateur d’une organisation tierce, absent de toute liste de releasability du message, ne reçoit rien. Les trois décisions sont prises par le socle, sur les marquages du message et le profil de chaque destinataire, sans intervention manuelle au fil de l’eau.

Le deuxième cas est celui qui manque le plus souvent aux systèmes existants. Le partenaire sous-habilité y est traité comme un partenaire bloqué : faute de pouvoir retirer le fragment sensible, le système retient le message entier. OC2-Edge structure ses messages en fragments expurgeables : chaque fragment porte son propre marquage, et la version transmise à un partenaire est la composition des fragments qu’il est en droit de recevoir. Une position amie dont le commentaire de renseignement est retiré reste une position amie exploitable. Recevoir une version réduite vaut mieux que ne rien recevoir, et le socle rend ce compromis systématique plutôt qu’artisanal.

Les standards : STANAG 4774 et STANAG 4778

La décision de partage n’a de valeur que si les partenaires interprètent les marquages de la même façon. OC2-Edge n’invente pas de format : le socle implémente les deux standards OTAN prévus pour cela.

Le STANAG 4774, publié comme ADatP-4774, définit la syntaxe des labels de confidentialité : une structure XML qui porte la politique de sécurité de référence, la classification, et des catégories extensibles [1][2]. C’est dans ces catégories que s’expriment les caveats (mentions restrictives complémentaires de la classification) et la releasability, c’est-à-dire la liste des nations ou des communautés autorisées à recevoir l’information. Un label « releasable » à une nation donnée se lit de façon identique par toutes les implémentations conformes.

Le STANAG 4778, publié comme ADatP-4778, définit la liaison entre le label et la donnée : le mécanisme cryptographique qui attache le label au contenu qu’il qualifie, de sorte qu’un label ne puisse être ni détaché, ni réattaché à un autre contenu sans que la vérification échoue [3]. Sans cette liaison, un label n’est qu’un commentaire. Avec elle, le label suit la donnée dans les stockages, les files store-and-forward et les retransmissions, et chaque nœud du chemin peut rejouer la décision de partage sur pièces.

L’expurgation décrite plus haut s’appuie directement sur ce couple : chaque fragment porte son label lié, et la version réduite d’un message reste un objet vérifiable, avec des liaisons valides sur les fragments conservés.

Le choix de standards existants plutôt que d’un format propre est un choix de doctrine autant que de technique. Un format de label propriétaire, même supérieur sur le papier, recréerait le problème qu’il prétend résoudre : chaque interconnexion exigerait une passerelle de traduction, c’est-à-dire un composant de confiance supplémentaire, coûteux à homologuer et propice aux pertes d’information de marquage. Un label ADatP-4774 se lit tel quel par les systèmes des nations qui implémentent le standard, et la conformité du socle se vérifie contre un document public plutôt que contre une spécification maison.

La décision de partage se rejoue par ailleurs à chaque saut. Dans un maillage store-and-forward, un message peut transiter par des nœuds intermédiaires avant d’atteindre son destinataire, y compris pendant des fenêtres d’émission contraintes par la discipline décrite dans l’article EMCON. Le label lié voyage avec la donnée : chaque nœud du chemin applique la politique sur pièces, et un fragment non transmissible à un intermédiaire n’emprunte pas ce chemin.

Un roster convergent, prouvé par propriétés

Dans un maillage fédéré, chaque nœud maintient un roster : la liste des partenaires connus, leurs habilitations et les politiques applicables. Les nœuds échangent leurs mises à jour de roster de façon asynchrone, avec des liaisons intermittentes et des ordres d’arrivée arbitraires. L’exigence est la convergence : deux nœuds qui ont reçu le même ensemble de mises à jour, dans n’importe quel ordre, calculent le même roster.

Cette propriété ne se démontre pas par quelques cas de test choisis à la main : l’espace des entrelacements possibles est trop grand. Le dépôt utilise le test par propriétés (property-based testing), technique introduite par QuickCheck [4] et implémentée ici avec la bibliothèque proptest [5] : le générateur produit des milliers de séquences aléatoires de mises à jour, de partitions et de réordonnancements, et le test vérifie que la propriété de convergence tient sur chacune. Quand une séquence la viole, l’outil la réduit automatiquement au contre-exemple minimal, qui devient un cas de non-régression. Ces tests font partie de la suite publique de ~930 tests automatisés du dépôt.

La conséquence opérationnelle est directe : la décision diffuser, expurger ou bloquer prise pour un partenaire est la même quel que soit le nœud du maillage qui la prend, parce que tous raisonnent sur le même roster convergé.

L’étanchéité exercice/réel, dans les deux sens

Une fédération de coalition sert autant à l’entraînement qu’aux opérations. Le socle distingue les modes LIVE et MAQUETTE, et l’étanchéité entre les deux est testée dans les deux directions :

1. aucune donnée d’exercice ne peut être présentée comme réelle : un objet MAQUETTE qui atteint un consommateur LIVE est rejeté, et le rejet est journalisé ;
2. aucune donnée réelle ne peut fuir vers un environnement d’exercice : un objet LIVE qui atteint un consommateur MAQUETTE est rejeté de la même façon.

Le premier sens protège la décision opérationnelle d’une pollution par la simulation. Le second protège la confidentialité : un environnement d’exercice, souvent moins protégé et plus largement ouvert aux partenaires, ne doit jamais devenir un canal d’exfiltration de données réelles. L’enjeu est aigu en coalition, où les exercices sont précisément le cadre dans lequel des partenaires aux habilitations hétérogènes s’interconnectent le plus librement. Les deux directions font l’objet de tests dédiés dans la suite publique, au même titre que la convergence du roster.

Ce que cela permet

Ces mécanismes ont un objectif unique : fédérer des instances OC2 opérées par des acteurs différents, nations ou industriels, sans exiger d’eux qu’ils fusionnent leurs politiques de sécurité. C’est l’approche retenue par l’initiative Federated Mission Networking (FMN) de l’OTAN : chaque participant conserve la propriété et la gouvernance de son réseau, et la fédération repose sur des standards d’interface communs [6].

Concrètement, deux industriels de la BITD qui instancient chacun le socle, avec leurs clés, leurs modules métier et leurs politiques propres, peuvent interconnecter leurs instances : les labels se lisent des deux côtés parce qu’ils suivent l’ADatP-4774, les liaisons se vérifient parce qu’elles suivent l’ADatP-4778, et chaque instance applique sa propre politique de releasability sur le flux commun. La coalition cesse d’être un projet d’intégration ad hoc pour devenir une propriété du socle.

L’état des preuves suit la règle du projet. Sont couverts par la suite publique du dépôt : la lecture et la production de labels, la vérification des liaisons, l’expurgation par fragments, la convergence du roster et l’étanchéité exercice/réel. La fédération de bout en bout entre deux instances opérées par des organisations réellement distinctes, avec leurs politiques et leurs chaînes de clés propres, n’a pas encore été jouée hors des environnements du projet : c’est un point ouvert, et l’objet exact de l’atelier proposé ci-dessous.

L’atelier fédération, proposé aux organisations qui souhaitent évaluer ce scénario sur leurs propres cas, se demande via la page de contact.

Sources

1. NATO Standardization Office, « ADatP-4774, Confidentiality Metadata Label Syntax, Edition A », 2017, https://nso.nato.int/nso/nsdd/main/standards/ap-details/1967/EN
2. NATO Interoperability Standards and Profiles, « Confidentiality Metadata Label Syntax (ADatP-4774 Ed A Ver 1) », https://nisp.nw3.dk/standard/nato-adatp-4774-ed.a-v1.html
3. NATO Standardization Office, « ADatP-4778.2, Profiles for Binding Metadata, Edition A », https://storage.nisp.nw3.dk/ADatP-4778.2_EDA_V1_E.pdf
4. Koen Claessen, John Hughes, « QuickCheck: A Lightweight Tool for Random Testing of Haskell Programs », ICFP 2000, https://dl.acm.org/doi/10.1145/351240.351266
5. Projet proptest, « proptest: Hypothesis-like property testing for Rust », https://github.com/proptest-rs/proptest
6. NATO Allied Command Transformation, « Federated Mission Networking », https://www.act.nato.int/activities/federated-mission-networking/