Gouverner la cryptographie: inventaire, agilité et conformité

Gouverner la cryptographie: inventaire, agilité et conformité

Un algorithme choisi en 2010 par une équipe qui a quitté l’entreprise depuis, codé en dur dans une bibliothèque que personne ne met à jour, protégeant des données qui doivent rester secrètes jusqu’en 2045 : voilà le portrait ordinaire d’un parc informatique. La cryptographie n’y est pas un choix ponctuel mais un patrimoine, avec ses inventaires, ses dettes et ses successions. Ce chapitre explique comment recenser ce patrimoine, comment écrire des systèmes capables de changer d’algorithme sans tout casser, et comment composer avec des contraintes qui ne relèvent pas des mathématiques : normes, droit de l’exportation, brevets et débats politiques sur l’accès des États aux données chiffrées.

Explication de la marmotte

Une grande maison compte des dizaines de serrures, posées à des époques différentes par des serruriers différents. Le jour où un modèle se révèle fragile, il faut savoir où il est installé et pouvoir le remplacer sans murer les portes. Ce chapitre parle de cet inventaire et de cette capacité à changer, appliqués aux protections informatiques.

→ Lire l’explication complète de la marmotte

Pourquoi inventorier avant de migrer ?

Toute migration cryptographique commence par une question d’apparence triviale : où l’algorithme visé est-il utilisé ? La réponse est presque toujours « plus d’endroits que prévu ». Un inventaire utile ne se contente pas de lister des noms d’algorithmes ; il relie sept informations pour chaque point d’usage.

Élément	Exemple	Pourquoi il compte
Algorithme et taille	RSA 2048, ECDSA P-256, AES-128-GCM	Détermine la marge de sécurité et la date de dépréciation
Protocole	TLS 1.2, SSH, S/MIME, format de jeton	Le même algorithme peut être négocié ou figé selon le protocole
Bibliothèque	OpenSSL, BoringSSL, Bouncy Castle, module natif de l’OS	C’est elle qu’il faudra mettre à jour ou reconfigurer
Version et dépendance	OpenSSL 1.1.1 via une image de conteneur	Une dépendance transitive peut figer une version obsolète
Clé	Emplacement, propriétaire, date de création, rotation	Changer d’algorithme impose souvent de régénérer les clés
Donnée protégée	Sauvegardes clients, jetons de session, archives signées	Fixe l’enjeu réel d’une faiblesse
Durée utile	15 minutes pour une session, 30 ans pour un acte notarié	Indique si la protection doit survivre à l’algorithme

La dernière colonne est la plus négligée et la plus décisive. Une donnée interceptée aujourd’hui et chiffrée avec un échange de clés classique peut être stockée puis déchiffrée le jour où un calculateur quantique suffisamment grand existera : c’est le scénario dit « récolter maintenant, déchiffrer plus tard ». Si la durée de sensibilité d’une donnée dépasse la durée de vie probable de l’algorithme qui la protège, la migration est déjà en retard. La page Préparer la migration post-quantique détaille ce calcul.

L’inventaire se formalise de plus en plus sous la forme d’un CBOM (Cryptography Bill of Materials), déclinaison cryptographique du SBOM (Software Bill of Materials), la nomenclature des composants logiciels. Le format CycloneDX a introduit dans sa version 1.6, publiée en 2024, un type de composant dédié aux actifs cryptographiques : algorithmes, certificats, clés, protocoles, avec leurs propriétés et leurs dépendances. Son intérêt est de pouvoir être interrogé : « quels services utilisent encore RSA sous 3072 bits pour des données à durée longue ? » devient une requête, plus une enquête.

Les sources de l’inventaire sont multiples et aucune n’est complète seule : analyse statique du code (appels aux bibliothèques), analyse des dépendances, scan réseau des suites TLS (Transport Layer Security) réellement négociées, extraction des certificats des magasins et des équipements, journaux des modules matériels de sécurité. L’écart entre le code et le réseau est en soi un résultat : il révèle les équipements oubliés et les exceptions « temporaires » installées il y a six ans.

Comment rendre le changement possible ?

La crypto-agilité désigne la capacité d’un système à remplacer un algorithme, une taille de clé ou un paramètre sans réécriture majeure ni interruption de service. Elle ne s’improvise pas le jour de la crise : elle se construit dans les formats et le code.

Le premier outil est le versionnement. Chaque donnée protégée porte l’identifiant de la méthode qui l’a protégée. Les empreintes de mots de passe au format dit PHC (Password Hashing Competition) en donnent un exemple quotidien :

$argon2id$v=19$m=65536,t=3,p=4$c2VsdW5pcXVl$k2N0Zm9ybWF0ZGVzb3J0aWU

Le préfixe annonce l’algorithme et ses paramètres. Un système qui lit ce préfixe peut vérifier une ancienne empreinte bcrypt ($2b$...) et, au passage, la recalculer en Argon2id lors de la connexion réussie suivante. Sans préfixe, le système ne sait même pas quel algorithme appliquer, et la seule migration possible est une réinitialisation générale des mots de passe, très appréciée des équipes d’assistance. La page Transformer mots de passe et secrets applicatifs en clés développe ce cas.

Le deuxième outil est la négociation contrôlée. Dans un protocole, les deux parties s’accordent sur un algorithme ; la politique locale doit fixer la liste autorisée et l’ordre de préférence, et le protocole doit protéger cette négociation contre la falsification. La crypto-agilité n’est pas la négociation libre : accepter « tout ce que l’autre propose » ouvre la porte aux attaques par downgrade (repli forcé vers une version plus faible). Les attaques FREAK et Logjam, publiées en 2015, ont exploité des serveurs qui acceptaient encore des suites « export » à 512 bits, héritage des restrictions américaines des années 1990 : un intermédiaire actif forçait ce choix, cassait la petite clé et lisait la session. TLS 1.3 authentifie l’ensemble de la négociation.

Le troisième outil est la dépréciation organisée : un algorithme passe par des états explicites (recommandé, toléré, interdit en création, interdit en lecture), chacun daté. Le NIST (National Institute of Standards and Technology) procède ainsi dans sa publication SP 800-131A, et son projet de rapport IR 8547, publié en novembre 2024, propose de déprécier RSA et les courbes elliptiques offrant 112 bits de sécurité après 2030 puis de les interdire après 2035. Les dates peuvent évoluer ; la méthode est à copier.

Viennent ensuite les outils d’ingénierie classiques. Un feature flag (interrupteur de fonctionnalité) active le nouvel algorithme pour une fraction du trafic et permet de revenir en arrière en minutes. La double lecture accepte l’ancien et le nouveau format en lecture pendant la transition, tout en n’écrivant que le nouveau ; elle doit avoir une date de fin, faute de quoi elle devient un repli permanent. L’observabilité enfin mesure ce qui est réellement utilisé : un compteur par algorithme et par version, exporté vers la supervision, dit quand l’ancien format a disparu du trafic et quand la double lecture peut être retirée.

Atelier : préparer une migration de hash ou de courbe

Soit une application qui signe ses jetons d’accès en ECDSA (Elliptic Curve Digital Signature Algorithm) sur P-256 et veut passer à Ed25519. Le plan raisonnable se déroule en cinq temps.

1. Publier la nouvelle clé avant de s’en servir : les vérificateurs (services consommateurs, partenaires) chargent les deux clés publiques, identifiées par un champ kid (key identifier) et un champ d’algorithme explicite.
2. Vérifier les deux : les consommateurs acceptent les jetons des deux algorithmes, mais l’algorithme est déduit de la clé désignée par kid, jamais du champ annoncé par le jeton lui-même, faute de quoi un attaquant choisit l’algorithme à la place du vérificateur. La page JWS détaille ce piège.
3. Basculer l’émission progressivement par interrupteur, en surveillant le taux d’échec de vérification.
4. Attendre l’expiration de tous les jetons de l’ancien type : si leur durée de vie maximale est d’une heure, une heure suffit ; si elle est d’un an, la transition dure un an.
5. Retirer l’ancienne clé et l’ancien code de vérification, puis le vérifier dans l’inventaire.

Tant que l’étape 5 n’est pas franchie, revenir en arrière consiste à réinverser l’interrupteur. Une migration sans plan de repli transforme un correctif de sécurité en panne de production, et la panne est généralement résolue en réactivant l’ancien algorithme partout, ce qui n’était pas l’objectif.

Atelier : un mini-CBOM pour une application web

Pour une application web ordinaire, un premier inventaire tient en quelques lignes, ici dans un format simplifié inspiré de CycloneDX :

application: portail-clients
composants:
  - usage: TLS frontal
    protocole: TLS 1.2 et 1.3
    bibliotheque: OpenSSL 3.0 (image nginx)
    certificat: ECDSA P-256, expire 2027-03-01, émis par une AC publique
  - usage: mots de passe
    algorithme: Argon2id (m=64 Mio, t=3), anciennes empreintes bcrypt coût 10
    bibliotheque: argon2-cffi
    duree_utile: tant que le compte existe
  - usage: jetons de session
    algorithme: HMAC-SHA-256
    cle: secret dans le KMS, rotation trimestrielle
    duree_utile: 8 heures
  - usage: sauvegardes
    algorithme: AES-256-GCM, clé enveloppée par le KMS
    duree_utile: 10 ans (obligation de conservation)

L’exercice révèle en général une ligne que personne ne sait remplir, une durée utile plus longue qu’imaginé et une bibliothèque embarquée que nul ne maintient : trois bonnes raisons de le faire.

Quelles contraintes externes pèsent sur les choix ?

Les normes fixent ce qui est reconnu : publications FIPS (Federal Information Processing Standards) et SP du NIST, normes ISO (International Organization for Standardization) et CEI (Commission électrotechnique internationale), RFC (Request for Comments) de l’IETF (Internet Engineering Task Force), référentiels nationaux comme ceux de l’ANSSI (Agence nationale de la sécurité des systèmes d’information). La conformité en découle : un marché public, un secteur régulé ou un client peut exiger un module validé FIPS 140-3, une qualification nationale ou une évaluation selon les Critères communs. Ces exigences contraignent la liste des algorithmes et parfois celle des bibliothèques utilisables, ce qui doit figurer dans l’inventaire avant tout choix technique. Les pages NIST, ISO, ANSSI et Common Criteria présentent ces acteurs.

L’exportation et l’importation sont encadrées. L’arrangement de Wassenaar, conclu en 1996, coordonne entre une quarantaine d’États les contrôles sur les biens à double usage, dont certains produits de chiffrement. L’Union européenne l’applique par le règlement (UE) 2021/821 ; les États-Unis par leurs règles d’exportation EAR (Export Administration Regulations), où la cryptographie relève de la catégorie 5, partie 2. En France, la loi pour la confiance dans l’économie numérique de 2004 rend l’utilisation des moyens de cryptologie libre, mais soumet leur fourniture, leur importation et leur exportation, selon les cas, à déclaration ou à autorisation auprès de l’ANSSI. Le cadre applicable dépend du pays, du secteur et de la nature du produit : il se détermine avec un juriste pour une juridiction donnée, pas dans un tableau générique.

Les brevets ont longtemps pesé sur l’adoption. Le brevet américain de RSA a expiré en septembre 2000, ce qui a libéré son usage aux États-Unis ; les incertitudes sur les brevets entourant certaines techniques de courbes elliptiques ont freiné leur déploiement pendant des années. Un brevet n’est pas un standard : un algorithme peut être normalisé et breveté, ou libre et non normalisé, et ces deux propriétés se vérifient séparément.

Politique et confiance : un débat qui ne s’éteint pas

Le key escrow (séquestre de clés) consiste à déposer une copie des clés, ou de quoi les reconstruire, auprès d’un tiers, souvent pour permettre un accès légal. La puce Clipper, proposée par le gouvernement américain en 1993, en est l’exemple fondateur : elle chiffrait les communications vocales avec l’algorithme Skipjack et transmettait un champ permettant aux autorités, munies des clés séquestrées, de déchiffrer. En 1994, Matt Blaze a montré qu’on pouvait contourner ce champ, et le projet n’a jamais trouvé son marché. Les propositions d’accès exceptionnel reviennent régulièrement sous d’autres formes ; la critique technique constante est qu’un accès réservé aux « bons » est un accès, et qu’un mécanisme ajouté pour un tiers élargit la surface d’attaque pour tous.

Ces débats ont façonné des communautés : le mouvement cypherpunk, né d’une liste de diffusion en 1992, et l’affaire PGP (Pretty Good Privacy), dont l’auteur Phil Zimmermann a fait l’objet d’une enquête américaine pour exportation entre 1993 et 1996. L’IACR (International Association for Cryptologic Research) structure la recherche académique, des organisations de défense des libertés comme l’EFF (Electronic Frontier Foundation) portent les contentieux, et la transparence des processus de normalisation est devenue une exigence après l’affaire du générateur Dual_EC_DRBG, normalisé par le NIST en 2006 puis retiré en 2014 sur fond de soupçons de porte dérobée.

Une politique de clés, qui dit comment les clés sont générées, stockées, renouvelées et détruites, n’est pas une politique d’accès, qui dit qui peut utiliser quoi. Le séquestre se situe exactement à leur croisement, ce qui explique qu’il cristallise autant de désaccords.

Pièges et confusions

L’absence d’inventaire est le piège fondateur : toutes les autres erreurs s’en nourrissent. L’algorithme codé en dur vient ensuite, avec son cousin le repli silencieux : un code qui essaie le nouvel algorithme puis, en cas d’échec, l’ancien, offre à l’attaquant le choix de provoquer l’échec. Traiter la conformité comme une preuve de sécurité est plus subtil : un module validé FIPS peut être mal configuré, une norme peut tolérer un algorithme que la recherche juge déjà fragile, et un audit de conformité vérifie la présence de contrôles, pas leur efficacité. Enfin, ignorer les contraintes juridiques locales expose à découvrir après la signature du contrat qu’une exportation demandait une autorisation.

🐝 Ce qui arrive si on s’en passe

Sans inventaire ni agilité, la découverte d’une faiblesse dans un algorithme tourne à l’enquête archéologique : il faut d’abord retrouver, bibliothèque par bibliothèque, où il est employé, pendant que la fenêtre d’exposition court. Les données dont la durée de sensibilité dépasse la durée de vie de l’algorithme restent protégées par une garantie périmée, sans que quiconque puisse dire lesquelles. Une migration lancée sans retour arrière possible transforme le correctif en panne, et la tentation devient alors de réactiver l’ancien algorithme en repli, ce qui offre à l’attaquant le choix du plus faible. L’attestation de conformité, elle, continue d’afficher un vert rassurant sur un parc que personne n’a recensé.

🦫 Explication de la marmotte 🍫

Une organisation utilise la cryptographie à de nombreux endroits : connexions sécurisées, stockage chiffré, signatures, certificats, programmes achetés ou développés. Chaque usage repose sur un algorithme, une taille de clé, une bibliothèque de programmation dans une version donnée, et protège des données qui doivent rester secrètes pendant une certaine durée. La gouvernance commence par un inventaire de tous ces éléments, parfois rédigé sous forme de nomenclature cryptographique, c’est-à-dire une liste structurée des composants et de leurs dépendances. Sans inventaire, on ne peut ni savoir ce qu’une faiblesse découverte touche, ni préparer un changement. La deuxième étape est l’agilité : écrire les programmes pour que l’algorithme puisse être remplacé. Cela suppose d’enregistrer une version avec chaque donnée protégée, de savoir lire l’ancien et le nouveau format pendant la transition, de pouvoir revenir en arrière et d’observer ce qui est réellement utilisé. Un algorithme inscrit en dur dans le code empêche tout cela. La négociation entre deux systèmes doit rester contrôlée : si elle accepte librement un algorithme ancien, un attaquant peut forcer ce choix. Viennent ensuite les contraintes externes : normes, règles d’exportation, brevets, lois différentes selon les pays, exigences des marchés publics. Enfin, respecter une norme ne prouve pas que le système soit sûr : conformité et sécurité se vérifient séparément.

À lire aussi

• Héritage, politique et limites de la cryptographieConclure le site en plaçant la cryptographie dans son histoire technique, ses contraintes juridiques, ses usages hérités et ses limites face à la gouvernance.
• Évaluer la force d’une protectionExpliquer comment raisonner en bits de sécurité, en durée de confidentialité et en coût réel d’attaque, sans réduire la décision à la longueur d’une clé.
• Choisir ECDSA, EdDSA ou RSA pour un certificat TLSComparer les signatures à courbe elliptique ECDSA et EdDSA au RSA historique pour les certificats TLS, selon la taille de clé, la performance, la sécurité et la compatibilité.
• RSA : trappe, padding et usages restreintsTraiter RSA comme une primitive encore rencontrée mais exigeante, où la sécurité dépend autant du padding, de la génération et de l’implémentation que du module.

Pages voisines

La citent

• Exploiter les clés : rotation, KMS et secrets
• Chiffrement par flot : état, compteurs et réutilisation interdite
• Chiffrer par blocs : de l’héritage DES à AES
• Signer numériquement : preuve publique, politiques de vérification
• Tester, auditer, répondre et migrer
• Certificats de courte durée

Gouverner la cryptographie: inventaire, agilité et conformité

Elle cite

• ⇄Lien dans les deux sens :Préparer la migration post-quantique
• ⇄Lien dans les deux sens :Récolter maintenant, déchiffrer plus tard
• Équité, vote, contrats et divulgation contrôlée
• Transformer mots de passe et secrets applicatifs en clés
• ANSSI
• Common Criteria

⇄ : les deux pages se citent l’une l’autre.