P8 : pourquoi un nœud tactique doit démarrer même quand la sécurité n'est pas parfaite

Un équipement tactique qui refuse de démarrer est un équipement perdu pour la mission en cours. Le principe P8 d’OC2-Edge tire la conséquence de ce constat : au démarrage, la disponibilité prime sur l’enforcement. Cet article expose le vécu terrain qui fonde ce principe, sa formulation exacte, le test qui le prouve dans le dépôt, et le contrepoint qui l’empêche de devenir du laxisme.

Le vécu terrain

Les systèmes sécurisés modernes accumulent des conditions préalables au démarrage : signature de l’image à vérifier, certificat en cours de validité, serveur de licence joignable, mise à jour appliquée jusqu’au bout. Chacune de ces conditions est légitime prise isolément. Leur conjonction produit des équipements qui s’arrêtent pour des causes sans rapport avec une attaque.

Le cas d’école est documenté : en décembre 2018, un certificat logiciel expiré dans des nœuds de cœur de réseau Ericsson a mis hors service les données mobiles de dizaines de millions d’abonnés, chez O2 au Royaume-Uni et SoftBank au Japon, pendant une journée [1]. Aucun attaquant, aucune compromission : un mécanisme de sécurité a appliqué sa règle, et la règle a produit un déni de service auto-infligé. Le même schéma se rejoue à plus petite échelle chaque fois qu’un équipement embarqué exige un serveur d’activation injoignable depuis le terrain, ou qu’une mise à jour interrompue par une coupure d’alimentation laisse le système dans un état qu’il refuse lui-même.

Sur un nœud tactique, ces causes ne sont pas des cas limites. L’horloge dérive quand le GPS est brouillé, donc les vérifications de validité temporelle échouent. Le réseau est intermittent par doctrine, donc les serveurs distants sont injoignables par défaut. Les coupures d’alimentation en cours de mise à jour sont un événement normal. Un socle qui traite ces situations comme des anomalies bloquantes n’est pas conçu pour son environnement.

OC2-Edge traite d’abord ces causes par construction, avant toute posture. Les images système A/B signées absorbent la mise à jour interrompue : si la nouvelle image ne démarre pas ou n’est pas complète, le nœud retombe sur l’image précédente, intacte. L’absence de serveur distant est le cas nominal : aucune fonction du socle n’exige de joindre une infrastructure pour démarrer. P8 couvre ce qui reste : les cas où une vérification de sécurité échoue réellement au démarrage.

Le principe P8

P8 se formule ainsi : le nœud démarre toujours, et l’état de sécurité constaté au démarrage détermine une posture, jamais un refus de service.

Trois postures sont définies.

1. NOMINAL : toutes les vérifications passent. Le nœud offre l’intégralité de ses fonctions.
2. DÉGRADÉ : une ou plusieurs vérifications échouent pour une cause compatible avec une panne ou une indisponibilité (composant matériel absent, chaîne de certificats non vérifiable, horloge non fiable). Le nœud démarre, restreint les fonctions qui dépendaient de la garantie perdue, affiche sa posture à l’opérateur et la propage aux pairs du maillage.
3. CONFINÉ : les constats indiquent une compromission probable et non une panne. Le nœud démarre en isolation, conserve ses journaux, et n’offre que les fonctions d’investigation et de restauration.

Deux propriétés accompagnent ces postures. La posture est explicite : elle est affichée, interrogeable et propagée, jamais implicite. La transition est journalisée : chaque changement de posture produit un événement horodaté, signé et conservé, qui documente la cause du changement. La dégradation silencieuse est exclue au même titre que le refus de service.

La propagation aux pairs est la partie la moins visible et la plus structurante. Un nœud en posture DÉGRADÉ l’annonce au maillage, et chaque pair ajuste ce qu’il accepte de lui : les fonctions qui exigent la garantie perdue ne lui sont plus déléguées, les autres continuent. La décision de confiance se prend ainsi côté consommateur, sur une information honnête, plutôt que côté nœud défaillant par un arrêt unilatéral qui déciderait pour tout le monde.

Cette approche s’aligne sur les référentiels de résilience existants. Le NIST SP 800-193 structure la résilience des plateformes autour de trois fonctions, protection, détection, récupération, et non autour du seul blocage [2]. La sûreté de fonctionnement industrielle, formalisée par la série IEC 61508, raisonne de même en états dégradés définis et maîtrisés plutôt qu’en tout ou rien [3][4].

Le test qui le prouve

Le blog est l’organe de preuve du projet, et P8 a son test dans la suite publique du dépôt, parmi les ~930 tests automatisés au vert.

Le scénario est le suivant. Le nœud de test est configuré avec un TPM (Trusted Platform Module), le composant matériel qui scelle les mesures d’intégrité du démarrage, conformément à la spécification TPM 2.0 du Trusted Computing Group [5]. Le test retire le TPM de la machine émulée, puis redémarre le nœud. Le comportement vérifié est triple :

1. le nœud termine son démarrage, sans blocage ni boucle de reboot ;
2. la posture exposée est DÉGRADÉ, avec la cause « TPM absent » interrogeable par l’opérateur et par les pairs ;
3. un événement de transition est présent dans le journal, horodaté et signé, avant toute autre activité du nœud.

Le test échoue si le nœud refuse de démarrer, et il échoue tout autant si le nœud démarre en prétendant être NOMINAL. Les deux erreurs sont symétriques : la première sacrifie la disponibilité, la seconde sacrifie l’honnêteté de l’état. Ce scénario se rejoue sur l’environnement d’émulation x86-64 et ARM64 du dépôt, sans matériel spécifique, et s’exécute à chaque version dans les 9 chaînes d’intégration continue : une régression sur P8 bloque la publication de la version au même titre qu’une régression fonctionnelle.

Le contrepoint : refus par défaut partout ailleurs

P8 ne fait pas d’OC2-Edge un système permissif. Le principe s’applique au démarrage et à lui seul, parce que le démarrage est le moment où le refus coûte la mission. Partout ailleurs, la règle inverse s’applique : refus par défaut.

1. Installation de modules : un module non signé, ou signé par une clé révoquée, est rejeté sans posture intermédiaire. Le nœud fonctionne sans ce module.
2. Connexions au maillage : un pair qui ne prouve pas son identité n’obtient pas de session. Une posture DÉGRADÉ annoncée par un pair restreint ce que les autres nœuds acceptent de lui.
3. Mises à jour : une image dont la signature ou la chaîne TUF ne se vérifie pas n’est pas appliquée. Le nœud reste sur l’image précédente.

La différence de traitement est cohérente : refuser un module ou une mise à jour laisse le nœud opérationnel, refuser de démarrer le supprime. P8 arbitre uniquement le cas où la sanction de sécurité et la perte totale de service sont la même chose.

Le principe se résume d’une formule : muter n’est pas guérir. Un nœud qui refuse de démarrer n’a pas traité son problème de sécurité, il l’a rendu invisible et y a ajouté une perte de capacité. Un nœud qui démarre en posture DÉGRADÉ expose son problème, le journalise, le propage, et laisse l’opérateur décider en connaissance de cause. De ces deux comportements, un seul produit de l’information exploitable pour la défense du système.

La spécification complète du principe P8, les définitions formelles des trois postures et le code du test sont publiés dans le dépôt.

Sources

1. The Register, « Why millions of Brits’ mobile phones were knackered on Thursday: An expired Ericsson software certificate », 2018, https://www.theregister.com/2018/12/06/ericsson_o2_telefonica_uk_outage/
2. NIST, « SP 800-193, Platform Firmware Resiliency Guidelines », 2018, https://csrc.nist.gov/pubs/sp/800/193/final
3. IEC, « Safety and functional safety (IEC 61508) », https://www.iec.ch/functional-safety
4. IEC, « IEC 61508-1:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems », 2010, https://webstore.iec.ch/en/publication/5515
5. Trusted Computing Group, « TPM 2.0 Library Specification », https://trustedcomputinggroup.org/resource/tpm-library-specification/