Crypto-agilité : concevoir des systèmes de défense capables de changer d'algorithme

La plupart des systèmes de défense ne tombent pas en panne parce que leur cryptographie était faible lors de leur déploiement. Ils tombent en panne parce que la cryptographie n'a pas évolué alors que le monde avançait. Un algorithme qui était solide au moment du déploiement devient obsolète, puis déconseillé, puis interdit — et le système qui l'a codé en dur nécessite désormais un programme d'ingénierie pluriannuel impliquant plusieurs fournisseurs pour changer une seule primitive. La crypto-agilité est la discipline qui consiste à concevoir des systèmes de façon à ce que le remplacement d'un algorithme soit une tâche de configuration et de déploiement, non une refonte. Avec la migration vers la cryptographie post-quantique désormais obligatoire pour les données de défense à longue durée de vie, l'agilité n'est plus un raffinement — c'est la condition préalable pour survivre à la prochaine transition sans redéployer le système.

Ce que signifie réellement la crypto-agilité

La crypto-agilité est la propriété d'un système lui permettant de modifier ses algorithmes, ses tailles de clés et ses protocoles sans rearchitecturer l'application qui en dépend. Le test est simple : combien de temps, et combien de lignes de code, faut-il pour remplacer un algorithme par un autre ? Dans un système non agile, la réponse est « nous rouvrons la conception », car le nom de l'algorithme, la longueur de clé et l'ensemble de paramètres sont dispersés à travers la logique applicative, les formats de sérialisation, les modèles de certificats et les gestionnaires de protocoles. Dans un système agile, la réponse est « nous modifions une politique », car chacune de ces décisions a été externalisée vers une configuration dès la construction du système.

L'agilité n'est pas la même chose que disposer d'une bonne bibliothèque cryptographique. Un programme peut utiliser la bibliothèque la mieux auditée disponible et rester totalement rigide, parce que l'application appelle une fonction spécifique — RSA_sign, une courbe nommée, un condensé fixe — directement depuis le code métier. La substituabilité de la bibliothèque n'aide pas si les sites d'appel ne le sont pas. L'agilité est une propriété architecturale de l'ensemble du système, non une fonctionnalité d'une seule dépendance.

Pourquoi les systèmes de défense en ont besoin maintenant

Deux calendriers entrent en collision dans l'acquisition de défense. Le premier est la durée de vie opérationnelle de la plateforme. Un véhicule de combat, une famille de radios ou une suite de commandement et contrôle est censée fonctionner pendant vingt à quarante ans. Sur cette période, les normes cryptographiques seront renouvelées plusieurs fois — la transition depuis SHA-1, la dépréciation de RSA 1024 bits et le passage au chiffrement authentifié se sont tous produits au cours d'une seule génération de plateformes. Tout algorithme intégré dans un système aujourd'hui sera obsolète bien avant que le matériel soit retiré du service.

Le second calendrier est la menace quantique. Un ordinateur quantique cryptographiquement pertinent briserait RSA et la cryptographie à courbes elliptiques, et la stratégie « collecter maintenant, déchiffrer plus tard » signifie que des adversaires peuvent capturer le trafic chiffré d'aujourd'hui et le stocker jusqu'à ce que cette machine existe. Les données de défense soumises à des exigences de confidentialité de plusieurs décennies sont donc déjà à risque, même si l'ordinateur quantique n'existe pas encore. La réponse des normes — CNSA 2.0 et la suite post-quantique NIST — fixe des délais de migration fermes. Un système sans agilité ne peut pas respecter ces délais sans un effort de réingénierie que le calendrier ne permet pas. Pour le modèle de menace et le calendrier qui sous-tendent cela, voir notre analyse de la menace de l'informatique quantique pour les communications de défense.

Commencer par un inventaire cryptographique

On ne peut pas migrer ce que l'on ne voit pas, et on ne peut pas rendre agile ce que l'on n'a pas localisé. Le premier livrable de tout programme de crypto-agilité est un inventaire cryptographique — de plus en plus formalisé sous le nom de nomenclature cryptographique, ou CBOM. Il s'agit d'un catalogue complet de chaque endroit où le système utilise la cryptographie : chaque algorithme et mode, chaque longueur de clé, chaque certificat et son émetteur, les versions de protocoles négociées sur chaque interface, les bibliothèques qui implémentent les primitives, et — élément crucial — les données que chaque instance protège et la durée pendant laquelle elles doivent rester confidentielles.

L'inventaire est presque toujours plus surprenant que ce que le programme attendait. La cryptographie se cache dans des micrologiciels dont personne ne détient le code source, dans des binaires tiers dont les choix algorithmiques ne sont pas documentés, dans des modules matériels de sécurité aux capacités fixes et dans des valeurs par défaut de protocoles négociées au moment de l'exécution plutôt que choisies à la conception. Un inventaire utile enregistre la confiance dans la découverte et la propriété pour chaque entrée, distinguant « nous l'avons lu dans le code source » de « nous l'avons observé sur le réseau » de « le fournisseur nous l'a dit ». Il doit être un artefact vivant régénéré par le pipeline de construction, non un audit ponctuel qui est obsolète le lendemain de sa publication.

De l'inventaire à la priorisation des risques

L'inventaire n'est pas seulement une carte — c'est l'entrée de la priorisation. Deux attributs déterminent l'ordre de migration : la durée de confidentialité des données protégées, et l'exposition du canal. Les données qui doivent rester secrètes pendant trente ans et qui transitent par un lien externe sont les premières à migrer, car c'est exactement ce que cible la stratégie « collecter maintenant, déchiffrer plus tard ». Les données éphémères sur un segment interne physiquement protégé peuvent attendre. Sans l'inventaire, ce triage est impossible et le programme migre soit tout en même temps (ce qui est inabordable), soit les éléments faciles en premier (ce qui laisse les données les plus risquées exposées le plus longtemps).

La couche d'abstraction algorithmique

Le cœur structurel d'un système agile est une couche d'abstraction algorithmique — un fournisseur cryptographique ou une interface de service qui s'intercale entre le code applicatif et les implémentations concrètes. Le code applicatif ne nomme jamais un algorithme. À la place, il exprime une intention : « signer ce message », « établir une clé de session avec ce pair », « chiffrer cet enregistrement au repos ». En complément de l'intention, il référence une politique nommée — par exemple signing.c2-link.v3 — et la couche d'abstraction résout cette politique vers un algorithme concret, une longueur de clé et un ensemble de paramètres au moment de l'exécution.

L'avantage est qu'un remplacement d'algorithme devient une modification de politique. Faire passer signing.c2-link.v3 d'une signature à courbe elliptique à une signature post-quantique est un changement de configuration déployé par environnement, sans modification du code appelant ni recompilation de l'application qui émet la demande de signature. La même indirection permet à un programme d'exécuter différents algorithmes dans différents théâtres ou pour différents niveaux de classification à partir d'un seul binaire, et lui permet d'échelonner une migration — ancienne politique en production, nouvelle politique en test — sans bifurquer la base de code.

La conception correcte de l'interface est importante. Elle doit être suffisamment grossière pour que les développeurs d'applications ne puissent pas accidentellement la contourner (pas de porte de secours « donnez-moi une clé AES brute » qui recodifie le choix en dur), et elle doit exposer les métadonnées d'algorithme afin que les appelants puissent enregistrer quelle politique a été appliquée. Le HSM, le coffre-fort de clés et les mécanismes de rotation vivent également derrière cette couche ; pour le côté opérationnel, voir notre guide sur la gestion des secrets dans les pipelines CI/CD de défense.

Versionner les protocoles, les certificats et les données stockées

L'agilité au niveau du site d'appel est nécessaire mais non suffisante. Les artefacts cryptographiques survivent au moment de leur création — un enregistrement chiffré aujourd'hui peut être déchiffré dans quinze ans, un certificat émis maintenant est vérifié par des pairs pendant toute sa période de validité, et une session de protocole est négociée entre deux systèmes suivant des calendriers de mise à jour différents. Chacun de ces éléments doit contenir suffisamment de métadonnées pour survivre à un changement d'algorithme.

Protocoles. Les formats sur le réseau doivent inclure des identifiants d'algorithme explicites et des champs de version afin que deux pairs puissent négocier un algorithme commun plutôt que d'en supposer un. Un protocole qui code en dur « la signature est ECDSA-P384 » ne peut pas être mis à niveau sans rompre simultanément tous les pairs déployés — un jour J opérationnellement impossible à travers une force déployée. Un protocole qui négocie « je prends en charge ces suites algorithmiques, vous prenez en charge celles-là, nous nous accordons sur la plus forte commune » se met à niveau de manière fluide à mesure que les points terminaux migrent à leur propre rythme.

Certificats. Les profils de certificats doivent prendre en charge de nouveaux identifiants d'algorithme de signature et d'encapsulation de clé, et le chemin de validation ne doit pas rejeter un algorithme inconnu mais approuvé par politique. L'infrastructure à clé publique elle-même a besoin d'une racine agile : si l'autorité de certification ne peut émettre qu'un seul algorithme, l'infrastructure devient le goulot d'étranglement quelle que soit l'agilité des points terminaux.

Données stockées. Chaque enregistrement chiffré ou objet signé doit enregistrer quel algorithme et quelle clé l'ont protégé. Sans cette étiquette, un système futur ne peut pas déchiffrer ou vérifier les données héritées après que l'algorithme actif a changé — les données deviennent illisibles non pas parce que la clé a été perdue mais parce que le système a oublié quel schéma il avait utilisé. Ces métadonnées sont ce qui rend une migration réversible et ce qui permet la coexistence d'ancien et de nouveau texte chiffré pendant la transition.

Un plan de migration par phases

Avec l'inventaire, la couche d'abstraction et les artefacts versionnés en place, la migration elle-même devient une séquence contrôlée et réversible plutôt qu'un jour J. Un plan praticable s'articule en cinq phases.

Phase 1 — inventaire. Construire et automatiser le CBOM, et trier les entrées par durée de confidentialité et exposition. Cette phase produit le carnet de migration et expose les dépendances qui provoqueraient autrement des défaillances sur le terrain.

Phase 2 — abstraction. Introduire la couche d'abstraction algorithmique et router chaque appel cryptographique existant à travers elle. Aucune logique applicative ne doit invoquer un algorithme directement. À la fin de cette phase, le système n'est pas plus sécurisé qu'avant, mais il est désormais modifiable — la condition préalable à tout ce qui suit.

Phase 3 — modes hybrides. Configurer la couche pour exécuter un algorithme classique et un algorithme post-quantique ensemble — par exemple un établissement de clé hybride combinant un échange à courbe elliptique avec un mécanisme d'encapsulation de clé à base de réseaux. La construction combinée reste sécurisée si l'un des composants est ultérieurement compromis, ce qui couvre à la fois une rupture quantique de l'algorithme classique et une faiblesse imprévue dans le nouvel algorithme post-quantique. Déployer les modes hybrides par environnement via une politique, en validant l'interopérabilité avec les systèmes alliés et régis par STANAG avant de modifier toute valeur par défaut.

Phase 4 — migration priorisée. En utilisant l'ordre de risque de l'inventaire, migrer en premier les données à longue confidentialité et exposées à l'extérieur, puis descendre jusqu'aux données internes de courte durée. Mesurer la couverture par rapport au CBOM à chaque étape afin que le programme puisse indiquer exactement quelle fraction des données à haut risque est protégée par la cryptographie post-quantique. Le séquençage détaillé de la conformité pour cette phase est exposé dans la feuille de route de migration CNSA 2.0.

Phase 5 — retrait. Ne retirer un algorithme classique exclusif qu'une fois que chaque pair dépendant et chaque chemin de données stockées a été rechiffré ou re-clé sous la nouvelle politique — ce que l'inventaire et les étiquettes de données stockées permettent de vérifier plutôt que de supposer. Le retrait est la dernière étape précisément parce que c'est la seule irréversible ; tout ce qui précède peut être annulé si l'interopérabilité ou les performances régressent.

Modes d'échec courants

Trois erreurs se répètent d'un programme à l'autre. La première consiste à traiter l'agilité comme un remplacement de bibliothèque — lier une bibliothèque capable de post-quantique tout en laissant des appels d'algorithme directs dans le code applicatif, ce qui produit un système pas plus agile qu'avant. La seconde consiste à migrer avant d'inventorier, ce qui garantit des dépendances manquées qui se manifestent comme des défaillances sur le terrain lorsqu'un pair ou un composant de micrologiciel non catalogué ne peut pas négocier le nouvel algorithme. La troisième consiste à supprimer l'ancien algorithme trop tôt, avant que chaque enregistrement stocké et chaque pair aient migré, ce qui rend les données héritées invérifiables ou illisibles. Chacune de ces erreurs est évitée par la même discipline : inventorier d'abord, abstraire avant de migrer, et retirer en dernier.

Ce que cela signifie pour l'acquisition

La crypto-agilité est la moins coûteuse quand elle est une exigence lors de l'attribution du contrat et la plus coûteuse quand elle est intégrée rétroactivement à un système déployé. Les programmes spécifiant de nouveaux logiciels de défense devraient exiger une couche d'abstraction algorithmique, une nomenclature cryptographique maintenue et des artefacts cryptographiques versionnés comme critères de réception — non comme une amélioration future. Les systèmes conçus aujourd'hui vivront à travers la transition post-quantique et au moins une transition après elle. Les concevoir pour qu'ils puissent changer d'algorithme à moindre coût est la différence entre un changement de configuration et un programme de redéploiement.