Agilité cryptographique et gouvernance

Dernier chapitre, et le seul qui ne contienne pas de mathématiques. C'est aussi celui dont vos étudiants auront le plus besoin, parce que la migration post-quantique échouera rarement sur un problème cryptographique et souvent sur un problème d'inventaire.

On ne migre pas ce qu'on ne connaît pas

Toutes les organisations qui ont commencé une migration rapportent la même surprise : elles ne savaient pas où était leur cryptographie.

Elle est dans le code applicatif, mais aussi dans des bibliothèques transitives dont personne ne connaît la liste, dans des configurations de serveurs web, dans des certificats émis il y a huit ans par une équipe dissoute, dans des équipements réseau dont le fournisseur a disparu, dans des protocoles industriels non documentés, dans des cartes à puce, dans des sauvegardes chiffrées avec une clé conservée ailleurs.

Le préalable est donc un inventaire cryptographique, et il doit répondre à quatre questions pour chaque usage : quel algorithme et quelle taille de clé ; quelle donnée est protégée et pendant combien de temps ; qui est responsable du composant ; et peut-on en changer sans remplacer le matériel.

La quatrième question est celle qu'on oublie, et c'est la plus discriminante. Un système « agile » se migre par une mise à jour logicielle. Un système non agile — une clé publique gravée dans un composant, un protocole propriétaire à algorithme figé — a un temps de migration qu'aucun budget ne réduira. Il faut alors agir sur le prochain cycle d'achat, c'est-à-dire aujourd'hui pour un problème qui se manifestera dans dix ans.

Le CBOM

L'inventaire ne vaut que s'il est automatisable et versionné. Un tableur mis à jour une fois par an décrit surtout l'organisation d'il y a un an.

Le format qui s'impose est le CBOM — Cryptography Bill of Materials — une extension du format de nomenclature logicielle CycloneDX. Il décrit les actifs cryptographiques comme un SBOM décrit les dépendances : algorithmes, tailles de clés, protocoles, certificats, points d'usage, et les relations entre eux.

Trois bénéfices, dans l'ordre de leur importance pratique.

Il est produit par outillage — analyse statique, inspection des binaires, sondes réseau — donc il ne dépend pas de la mémoire des équipes.

Il est différentiel : on compare deux versions et l'on voit ce qui a bougé, ce qui permet de suivre la migration au lieu de la constater.

Il est interrogeable : le jour où un algorithme est cassé, la question « où l'utilisons-nous ? » reçoit une réponse en minutes plutôt qu'en trimestres. C'est cette propriété, et non la conformité, qui justifie l'effort.

Prioriser

Le chapitre 1 a donné la règle : $X + Y > Z$. Le chapitre 13 a ajouté la dissociation entre échange de clés et signatures. Ensemble, ils donnent un ordre de traitement défendable.

D'abord, l'échange de clés protégeant des données à longue durée de vie. C'est la seule catégorie où la récolte anticipée mord, et l'hybridation y est peu coûteuse.

Ensuite, les signatures à longue durée de vérification — firmwares, racines de confiance, horodatage légal. Non pas parce que la récolte les menace, mais parce que leur $Y$ est long et souvent irréductible.

Ensuite seulement, le reste des signatures, en attendant que la compression des chaînes de certificats mûrisse.

Et hors périmètre, le symétrique : vérifier qu'AES est en 256 bits et passer à autre chose. Un plan qui consacre un chapitre à « migrer AES » gaspille du budget et, plus grave, de la crédibilité auprès des équipes techniques.

L'exercice de ce chapitre montre que ce classement ne ressemble pas à celui de l'intuition : le portail client, actif le plus visible, arrive en bas ; les archives, que personne ne réclame, arrivent en haut.

L'agilité cryptographique

Le vrai objectif de la migration n'est pas d'arriver à ML-KEM. C'est d'arriver à un état où le prochain changement d'algorithme ne sera plus un projet.

Quatre propriétés caractérisent un système agile.

L'algorithme est une donnée, pas du code. Il se lit dans une configuration ou une politique, et le changer ne demande pas de recompiler.

Les identifiants d'algorithme circulent dans les formats. Les messages, certificats et fichiers chiffrés indiquent explicitement l'algorithme employé, ce qui rend possible la coexistence de deux générations pendant la transition.

Les tailles ne sont pas figées. C'est le piège le plus fréquent : un champ de base de données dimensionné pour une signature ECDSA de 64 octets, un tampon de 256 octets pour une clé publique, un format binaire à longueur fixe. Ces hypothèses se découvrent au pire moment.

La transition est prévue dans le protocole. Négociation, repli, hybridation : la possibilité de faire coexister deux algorithmes doit exister avant d'en avoir besoin.

Cette dernière propriété est ce qui a permis à TLS 1.3 d'absorber l'hybridation sans modification, comme le chapitre 13 l'a montré. TLS était agile ; la plupart des systèmes ne le sont pas.

Qui publie quoi

Deux remarques pour orienter la lecture. Le NIST normalise des algorithmes ; l'IETF normalise leur usage dans les protocoles, et c'est ce second travail qui conditionne les déploiements. Et les agences nationales ne s'alignent pas exactement : l'exigence d'hybridation de l'ANSSI est plus stricte que la position du NIST, et le BSI recommande des schémas que le NIST n'a pas retenus. Une organisation multinationale doit satisfaire la plus contraignante.

Rejouer le scénario

Terminons par l'exercice que ce cours prépare depuis le chapitre 10.

Supposons qu'une attaque efficace contre Module-LWE soit publiée demain matin. ML-KEM et ML-DSA tombent. Que se passe-t-il dans votre organisation ?

Les questions à poser, dans l'ordre :

• Combien de temps pour savoir où vous utilisez ML-KEM ? Si la réponse dépasse la semaine, votre inventaire est le problème.
• Vos déploiements sont-ils hybrides ? Si oui, vous conservez la sécurité classique et vous avez le temps de réagir. Si non, vous êtes nu — c'est le 30 juillet 2022 de SIKE.
• Pouvez-vous basculer vers une autre famille — HQC pour l'encapsulation, SLH-DSA pour la signature — sans réécrire vos applications ? C'est le test d'agilité, et c'est la raison pour laquelle le NIST a normalisé des schémas reposant sur des hypothèses différentes.
• Vos données déjà chiffrées sont-elles rechiffrables, ou faut-il les considérer comme compromises ?

Ce scénario n'est pas une hypothèse d'école. Il s'est produit pour SIKE, et pour Rainbow, à quelques mois d'intervalle, sur des candidats arrivés en finale d'un processus de normalisation international. La question n'est pas de savoir s'il se reproduira mais de savoir si vous serez en mesure d'y répondre.

À vous

// Un inventaire cryptographique réduit à l'essentiel, et le tri qui en fait
// un plan de migration. C'est l'exercice le plus proche de ce que vous ferez
// réellement en entreprise.

const ANNEE = 2026;
const Z = 15;   // horizon CRQC retenu, en années — hypothèse à assumer

// X = durée de vie de la donnée ou de la vérification, Y = temps de migration
const INVENTAIRE = [
  { actif: "Terminaison TLS du portail client", algo: "ECDHE P-256", role: "confidentialite", X: 2,  Y: 1, agile: true },
  { actif: "Archives de santé chiffrées",        algo: "RSA-2048",    role: "confidentialite", X: 50, Y: 3, agile: true },
  { actif: "VPN site à site (siège ↔ usine)",    algo: "IKEv2 ECDH",  role: "confidentialite", X: 10, Y: 2, agile: true },
  { actif: "Racine de confiance en silicium",    algo: "ECDSA P-256", role: "signature",       X: 25, Y: 8, agile: false },
  { actif: "Signature des mises à jour",         algo: "RSA-4096",    role: "signature",       X: 12, Y: 4, agile: true },
  { actif: "Sauvegardes hors ligne",             algo: "AES-256",     role: "symetrique",      X: 30, Y: 1, agile: true },
  { actif: "Jetons de session (24 h)",           algo: "HMAC-SHA256", role: "symetrique",      X: 1,  Y: 1, agile: true },
  { actif: "Horodatage légal",                   algo: "ECDSA P-256", role: "signature",       X: 30, Y: 5, agile: true },
];

// Le symétrique n'est pas menacé : il suffit de vérifier la taille de clé.
const MENACE = { confidentialite: true, signature: true, symetrique: false };

function evaluer(e) {
  // À COMPLÉTER — renvoyer { urgence, marge, note } où :
  //   marge   = Z - (X + Y)
  //   urgence = "hors périmètre" si l'algorithme n'est pas menacé,
  //             "CRITIQUE" si marge < 0, "à planifier" si marge < 5,
  //             "surveillance" sinon
  //   note    = un commentaire libre, notamment si l'actif n'est pas agile
  return { urgence: "?", marge: 0, note: "" };
}

const RANG = { "CRITIQUE": 0, "à planifier": 1, "surveillance": 2, "hors périmètre": 3 };

const evalues = INVENTAIRE.map((e) => ({ ...e, ...evaluer(e) }))
  .sort((a, b) => RANG[a.urgence] - RANG[b.urgence] || a.marge - b.marge);

console.log("urgence        | marge | actif                              | note");
for (const e of evalues) {
  console.log(
    `${e.urgence.padEnd(14)} | ${String(e.marge).padStart(5)} | ${e.actif.padEnd(34)} | ${e.note}`
  );
}

const ANNEE = 2026;
const Z = 15;

const INVENTAIRE = [
  { actif: "Terminaison TLS du portail client", algo: "ECDHE P-256", role: "confidentialite", X: 2,  Y: 1, agile: true },
  { actif: "Archives de santé chiffrées",        algo: "RSA-2048",    role: "confidentialite", X: 50, Y: 3, agile: true },
  { actif: "VPN site à site (siège ↔ usine)",    algo: "IKEv2 ECDH",  role: "confidentialite", X: 10, Y: 2, agile: true },
  { actif: "Racine de confiance en silicium",    algo: "ECDSA P-256", role: "signature",       X: 25, Y: 8, agile: false },
  { actif: "Signature des mises à jour",         algo: "RSA-4096",    role: "signature",       X: 12, Y: 4, agile: true },
  { actif: "Sauvegardes hors ligne",             algo: "AES-256",     role: "symetrique",      X: 30, Y: 1, agile: true },
  { actif: "Jetons de session (24 h)",           algo: "HMAC-SHA256", role: "symetrique",      X: 1,  Y: 1, agile: true },
  { actif: "Horodatage légal",                   algo: "ECDSA P-256", role: "signature",       X: 30, Y: 5, agile: true },
];

const MENACE = { confidentialite: true, signature: true, symetrique: false };

function evaluer(e) {
  const marge = Z - (e.X + e.Y);

  if (!MENACE[e.role]) {
    return { urgence: "hors périmètre", marge, note: "symétrique : vérifier ≥ 256 bits, rien d'autre" };
  }

  const urgence = marge < 0 ? "CRITIQUE" : marge < 5 ? "à planifier" : "surveillance";

  // L'agilité n'entre pas dans l'inégalité de Mosca, mais elle gouverne Y —
  // et un actif non agile a un Y qu'on ne peut PAS réduire en y mettant des
  // moyens. C'est la seule ligne qui mérite un traitement à part.
  const note = e.agile
    ? (e.role === "signature" ? "signature : pas de récolte anticipée, mais durée de vérification" : "confidentialité : exposée à la récolte anticipée")
    : "NON AGILE — Y irréductible, à traiter au prochain cycle matériel";

  return { urgence, marge, note };
}

const RANG = { "CRITIQUE": 0, "à planifier": 1, "surveillance": 2, "hors périmètre": 3 };

const evalues = INVENTAIRE.map((e) => ({ ...e, ...evaluer(e) }))
  .sort((a, b) => RANG[a.urgence] - RANG[b.urgence] || a.marge - b.marge);

console.log("urgence        | marge | actif                              | note");
for (const e of evalues) {
  console.log(
    `${e.urgence.padEnd(14)} | ${String(e.marge).padStart(5)} | ${e.actif.padEnd(34)} | ${e.note}`
  );
}

// Quatre enseignements du classement obtenu.
//
// 1. LA TERMINAISON TLS DU PORTAIL, l'actif le plus visible et celui que
//    tout le monde migre en premier, arrive en bas du tableau. X = 2 ans :
//    la donnée n'a plus de valeur quand la machine arrivera. Ce n'est pas
//    une raison de ne pas la migrer — c'est facile et c'est déjà fait dans
//    les navigateurs — mais ce n'est pas là que se joue le risque.
//
// 2. LES ARCHIVES DE SANTÉ sont critiques avec une marge très négative, et
//    elles n'ont aucune visibilité. Personne ne réclame leur migration.
//
// 3. LA RACINE DE CONFIANCE EN SILICIUM est le cas désespérant : Y = 8 ans
//    et NON AGILE. On ne peut pas accélérer une migration qui suppose de
//    changer le matériel. La seule action possible est d'exiger l'agilité
//    dans les spécifications d'achat du prochain cycle — c'est-à-dire
//    d'agir aujourd'hui sur un problème qui se manifestera dans dix ans.
//
// 4. LES SAUVEGARDES EN AES-256 sortent du périmètre. Grover les ramène à
//    128 bits, ce qui reste hors d'atteinte. Un plan de migration qui les
//    inclut gaspille du budget et de la crédibilité.
//
// La leçon de gouvernance : le classement par urgence réelle ne ressemble
// PAS au classement par visibilité. Un plan crédible se défend sur X et Y,
// pas sur l'importance ressentie des systèmes.

Ce que vous emportez de cette unité

Quatorze chapitres, et trois idées qui les traversent.

La difficulté est dans la description, pas dans l'objet. Un réseau est public, une base courte est secrète. Un code est public, sa structure de Goppa est secrète. Un système quadratique est public, l'espace d'huile est secret. La cryptographie asymétrique post-quantique est, à chaque fois, l'écart entre deux descriptions du même objet.

Une preuve borne une classe d'attaques, jamais les attaques. Le modèle QROM ne connaît ni le chronomètre ni le laser, et c'est par là que passent la plupart des cassures réelles. La sécurité effective se joue dans l'implémentation.

L'humilité est une exigence technique, pas une posture. SIKE avait onze ans d'examen public et une preuve de sécurité. Il est tombé en une après-midi, sur un théorème de 1997 que personne n'avait rapproché du sujet. C'est ce qui justifie l'hybridation, la normalisation de familles concurrentes, et l'agilité — trois formes du même refus de tout parier sur une seule hypothèse.

À retenir

QCM du bloc IV — Migration

Huit questions de décision plutôt que de connaissance : à chaque fois, une situation et un arbitrage à défendre. C'est le format le plus proche de ce qu'on vous demandera en poste.