Protocoles et infrastructure

Les douze chapitres précédents ont forgé des primitives : chiffrements, MAC, signatures, échanges de clés. Un protocole réel les assemble — et c'est un art distinct, car un montage de briques parfaites peut fuir par ses jointures. Ce chapitre montre comment on établit une communication sûre entre deux inconnus, prend TLS 1.3 comme cas d'étude, et finit sur le maillon qu'aucune preuve ne protège : l'aléa.

Échange de clés authentifié

Le chapitre 10 l'a établi sans détour : Diffie-Hellman brut tombe devant l'homme du milieu. Mallory établit un secret avec chacun et relaie en clair. Le problème n'est pas le secret — il est bien calculé — mais l'identité : rien ne dit à Alice que $g^b$ vient de Bob.

La réponse est l'échange de clés authentifié. On lie l'échange à une identité vérifiable en signant les messages du protocole avec une clé de long terme, elle-même attestée par un certificat. Alice ne se contente plus de recevoir $g^b$ : elle reçoit $g^b$ signé par une clé dont un certificat garantit qu'elle est celle de Bob. Mallory, incapable de produire cette signature, ne peut plus s'intercaler.

Une propriété qu'on exige en plus, et qui a un nom : la confidentialité persistante (forward secrecy). Les clés de session sont dérivées d'un Diffie-Hellman éphémère — un $g^a, g^b$ neuf à chaque session, jeté ensuite. Conséquence : si la clé privée de long terme de Bob est compromise demain, les sessions d'hier restent illisibles, car leur secret éphémère n'existe plus nulle part. C'est le « récolter maintenant, déchiffrer plus tard » du chapitre 1 rendu inopérant — du moins tant que Diffie-Hellman tient, ce que le chapitre 14 viendra nuancer.

TLS 1.3, l'assemblage de tout le cours

TLS protège l'essentiel du trafic web, et sa version 1.3 (2018) est une refonte disciplinée par vingt ans d'attaques. Elle est le point de convergence du cours entier.

Sa poignée de main (handshake) établit une session en un seul aller-retour : ECDH éphémère (chapitre 11) pour le secret, signature (chapitre 9 ou 11) attestée par certificat pour l'authentification, HKDF (chapitre 8) pour dériver les clés de session, et AEAD (chapitre 8) pour chiffrer et authentifier les données. Chaque brique de ce cours y a sa place exacte.

Ce que TLS 1.3 a retiré est aussi instructif que ce qu'il garde, car chaque suppression est une attaque refermée. Exit RSA pour le transport de clé — il n'offrait pas la forward secrecy et traînait l'attaque de Bleichenbacher (chapitre 1) depuis 1998. Exit CBC et ses oracles de padding (chapitre 4). Exit les suites cryptographiques négociables à l'ancienne, dont la négociation elle-même se faisait attaquer (dégradation forcée vers un chiffre faible). TLS 1.3 impose forward secrecy et AEAD, sans option de s'en passer. La leçon de conception : réduire la surface, ne laisser aucun choix dangereux ouvert. C'est l'exact pendant de Curve25519 (chapitre 11), sûre par défaut.

PKI et certificats X.509

Reste la question qui fonde tout : comment Alice sait-elle que telle clé publique est vraiment celle de Bob ? Par un certificat — la clé publique de Bob, son identité, et une signature d'une autorité de certification (AC) qui atteste le lien. Alice fait confiance à l'AC (sa clé est préinstallée dans le navigateur), donc à ce qu'elle signe. C'est l'infrastructure à clé publique (PKI), et le format des certificats est X.509.

La confiance se délègue en chaîne : une AC racine signe des AC intermédiaires, qui signent les certificats des sites. Le navigateur remonte la chaîne jusqu'à une racine qu'il connaît. Ce système marche à l'échelle du web — mais sa sécurité est celle de son maillon le plus faible, et le maillon est humain autant que mathématique. Une AC compromise signe de faux certificats pour n'importe qui : c'est arrivé avec DigiNotar en 2011, dont les faux certificats Google ont servi à espionner des dizaines de milliers d'Iraniens. La réponse a été la transparence des certificats (Certificate Transparency) — des journaux publics et inaltérables où tout certificat émis est inscrit, rendant une émission frauduleuse détectable.

Le maillon qu'aucune preuve ne couvre : l'aléa

Toute la cryptographie de ce cours suppose de l'aléa de qualité : les nonces, les clés éphémères, les premiers de RSA, le $k$ de DSA. Un générateur défaillant anéantit des schémas parfaitement prouvés — c'est le rappel brutal du chapitre 12 sur ce que les preuves ne couvrent pas.

Les défaillances sont de deux ordres. Il y a les accidents : le bug OpenSSL de Debian (2006-2008) qui réduisait l'espace des clés à 32 768 valeurs, ou les objets connectés qui engendrent leurs clés à froid, sans entropie. Et il y a le sabotage : Dual_EC_DRBG, un générateur normalisé par le NIST dont les constantes, on l'a appris avec Snowden, portaient une porte dérobée permettant à qui connaissait le secret de prédire toute la sortie. C'est ce soupçon, bien réel cette fois, qui a nourri la défiance envers les courbes NIST du chapitre 11.

La conséquence la plus tangible tient en un pgcd. Quand un parc d'appareils produit des clés RSA à faible entropie, certaines partagent un facteur premier — et le pgcd de deux modules publics les factorise toutes les deux d'un coup, sans jamais résoudre la factorisation. Montez-le.

// On collecte des clés publiques RSA (juste les modules n). Sur un parc
// d'objets à faible entropie — routeurs, cartes à puce démarrant à froid — le
// générateur produit parfois le MÊME premier dans deux clés distinctes.

function pgcd(a, b) {
  while (b > 0n) { [a, b] = [b, a % b]; }
  return a;
}

// Six premiers. Volontairement, deux modules vont partager p3.
const p1 = 10007n, p2 = 10009n, p3 = 10037n, p4 = 10039n, p5 = 10061n;

// Trois modules publics, tels qu'un scanner d'Internet les récolterait.
const modules = [
  { nom: "clé A", n: p1 * p2 },
  { nom: "clé B", n: p3 * p4 },
  { nom: "clé C", n: p5 * p3 }, // partage p3 avec la clé B — la faille
];

// ── À COMPLÉTER ───────────────────────────────────────────────────────────
// Pour chaque PAIRE de modules, calculer pgcd(n_i, n_j). S'il vaut plus que 1,
// c'est un facteur premier COMMUN : les deux clés sont factorisées d'un coup,
// sans jamais résoudre le problème de la factorisation.

function casserLeParc(modules) {
  const casses = [];
  for (let i = 0; i < modules.length; i++) {
    for (let j = i + 1; j < modules.length; j++) {
      // à compléter : g = pgcd des deux modules ; si g > 1, on tient un facteur
    }
  }
  return casses;
}

const resultats = casserLeParc(modules);
console.log("clés factorisées :", resultats.length ? resultats : "aucune");

function casserLeParc(modules) {
  const casses = [];
  for (let i = 0; i < modules.length; i++) {
    for (let j = i + 1; j < modules.length; j++) {
      const g = pgcd(modules[i].n, modules[j].n);
      if (g > 1n) {
        // g est un facteur commun : chaque module se scinde en g et n/g.
        casses.push({
          paire: [modules[i].nom, modules[j].nom],
          facteurCommun: g.toString(),
          [modules[i].nom]: [g.toString(), (modules[i].n / g).toString()],
          [modules[j].nom]: [g.toString(), (modules[j].n / g).toString()],
        });
      }
    }
  }
  return casses;
}

// Les clés B et C tombent : leur pgcd révèle p3 = 10037, et chacun des deux
// modules se scinde aussitôt. On n'a JAMAIS factorisé un module isolé — la
// difficulté du chapitre 9 est intacte. On a exploité une CORRÉLATION entre
// clés, née d'un générateur d'aléa défaillant.
//
// Ce n'est pas un exercice d'école. En 2012, l'étude « Mining Your Ps and Qs »
// a passé au pgcd des millions de clés RSA récoltées sur Internet et en a
// factorisé des dizaines de milliers — des équipements générant leurs clés au
// tout premier démarrage, avant d'avoir accumulé la moindre entropie. Le pgcd
// de deux nombres de 2048 bits est instantané ; le coût total est celui du
// balayage des paires.
//
// La leçon rejoint le chapitre 12 : une clé RSA parfaitement conforme, avec
// OAEP et PSS impeccables, est anéantie par un générateur pseudo-aléatoire
// défaillant. Aucune preuve de sécurité ne couvre l'aléa d'où sort la clé —
// c'est le maillon du chapitre, et l'un des plus fragiles.

Ce que la suite en fait

Ce chapitre a montré que la sécurité d'un système réel dépasse la solidité de ses primitives : elle tient à leur assemblage, à la gestion des identités, et à la qualité de l'aléa. Le chapitre 14, dernier du cours, change d'horizon temporel. Toute la clé publique déployée ici — RSA, ECDH, ECDSA, la PKI qui les atteste — repose sur des problèmes que l'algorithme de Shor résout en temps polynomial sur un ordinateur quantique. La forward secrecy elle-même n'y résiste pas contre un adversaire qui a enregistré le trafic. Il faut donc migrer, et l'agilité cryptographique que TLS 1.3 a commencé à outiller devient la compétence centrale.

À retenir

QCM de synthèse — Bloc IV — Protocoles et pratique

Le QCM ci-dessous porte sur l'ensemble du bloc : plusieurs questions relient les leçons entre elles. En cas d'erreur, le bilan indique le chapitre à revoir.