Génération de clés cryptographiques : 256 bits critiques d’aléatoire

Les deux piliers de la sécurité cryptographique

La cryptographie repose sur deux fondements. Le premier est la complexité mathématique : les algorithmes s’appuient sur des problèmes faciles à mettre en place mais extraordinairement difficiles à inverser. Le second est l’aléatoire. Les protocoles cryptographiques utilisent des nombres aléatoires pour générer des clés secrètes, des vecteurs d’initialisation et des nonces. Ces valeurs doivent être imprévisibles. Si un attaquant peut les deviner ou les reproduire, la complexité mathématique devient sans importance^[s].

Imaginez la chose ainsi : vous pouvez installer la serrure la plus solide au monde, mais si quelqu’un peut prédire la clé, la serrure ne sert à rien. Les mathématiques du chiffrement qui protègent vos communications peuvent être compromises non pas par une faiblesse mathématique, mais par un aléatoire prévisible.

Comment les ordinateurs créent de l’aléatoire

Les ordinateurs sont des machines déterministes. Avec les mêmes entrées, ils produisent les mêmes sorties. C’est l’inverse de l’aléatoire. Pour générer des nombres imprévisibles, les systèmes d’exploitation collectent de l’entropie à partir de sources physiques : variations de timing dans les frappes au clavier, opérations sur le disque, arrivée des paquets réseau et bruit électronique dans les composants matériels.

Les systèmes Linux modernes maintiennent un seul pool d’entropie alimenté par un générateur de nombres pseudo-aléatoires cryptographiquement sûr (CSPRNG) basé sur ChaCha20. Les interruptions d’événements matériels contribuent à des variations de timing qui alimentent l’entrée du pool^[s]. Une fois que ce pool a accumulé au moins 256 bits d’entropie estimée, le système peut produire indéfiniment des sorties cryptographiquement robustes.

Un CSPRNG doit satisfaire deux propriétés critiques. Premièrement, le test du bit suivant : étant donné une séquence quelconque de bits de sortie, aucun algorithme efficace ne peut prédire le bit suivant avec une probabilité significativement supérieure à 50 %^[s]. Deuxièmement, le secret rétroactif : même si un attaquant compromet l’état actuel du générateur, il ne peut pas déterminer quels nombres ont été générés précédemment^[s].

Quand l’aléatoire fait défaut : des catastrophes bien réelles

L’histoire offre des exemples édifiants de ce qui se passe lorsque la génération de clés cryptographiques repose sur un aléatoire faible.

Révélée en 2008, la vulnérabilité Debian OpenSSL provenait d’une modification spécifique à Debian, téléchargée pour la première fois en septembre 2006. Cette faille ne laissait que l’identifiant de processus (PID) comme source effective d’aléatoire pour OpenSSL sur les systèmes Debian affectés^[s][s]. Au lieu de l’espace de recherche prévu de 340 282 366 920 938 463 463 374 607 431 768 211 456 valeurs, les attaquants pouvaient énumérer 32 767 possibilités dérivées du PID pour de nombreuses clés affectées.

Fin 2010, fail0verflow a révélé une faille de signature dans la PlayStation 3 : le logiciel de signature de Sony utilisait un nombre constant là où le calcul de signature nécessitait une valeur véritablement aléatoire et imprévisible. Cette erreur a permis aux pirates de calculer la clé privée de signature de Sony^[s].

En 2012, des chercheurs ont appliqué une opération mathématique simple (calcul du plus grand commun diviseur) à 11 millions de modules publics RSA distincts et ont obtenu des clés privées pour 0,50 % des hôtes TLS et 0,03 % des hôtes SSH dans leur analyse. Ils ont reproduit un trou d’entropie au démarrage dans le générateur de nombres aléatoires de Linux dans des conditions susceptibles de se produire dans les appareils sans écran et embarqués^[s].

Il ne s’agit pas d’incidents isolés. Un aléatoire faible a provoqué des vulnérabilités de sécurité récurrentes sur des décennies d’informatique. En 2024, un bug subtil dans PuTTY (versions 0.68 à 0.80) a introduit un biais statistique dans la génération de nonces ECDSA, permettant aux attaquants de récupérer des clés privées de signature à partir d’environ 60 signatures^[s].

Le seuil des 256 bits

Pourquoi 256 bits ? Ce n’est pas une exigence universelle pour chaque clé cryptographique, mais c’est une cible courante de haut niveau de sécurité et le seuil de semis utilisé par le générateur de nombres aléatoires de Linux. Une clé de 256 bits offre environ 1,16 × 10⁷⁷ valeurs possibles—un espace de clés astronomiquement grand. Même si un attaquant pouvait vérifier un billion de clés par seconde, épuiser cet espace prendrait plus de temps que l’âge de l’univers.

La publication spéciale 800-133 Rev. 2 du NIST est la recommandation finale actuelle du NIST pour la génération de clés cryptographiques, tandis que la Rev. 3 a été publiée en tant que projet public initial en avril 2026. Le NIST décrit la cryptographie comme reposant sur un algorithme et une clé cryptographique, et la recommandation couvre la génération de clés gérées et utilisées par des algorithmes cryptographiques approuvés^[s][s]. L’exigence pratique est une force de sécurité adéquate pour l’algorithme, et non que chaque clé cryptographique contienne exactement 256 bits d’entropie.

Au-delà de l’informatique classique : les préoccupations post-quantiques

Les ordinateurs quantiques menacent les fondements mathématiques de la cryptographie actuelle. L’algorithme de Shor peut factoriser de grands nombres de manière exponentiellement plus rapide que les méthodes classiques, compromettant potentiellement RSA. Il résout également le problème du logarithme discret qui sous-tend la cryptographie sur les courbes elliptiques^[s].

La génération de clés cryptographiques post-quantiques utilise des problèmes mathématiques différents. Le problème Module Learning With Errors (MLWE) sous-tend l’algorithme ML-KEM standardisé par le NIST en 2024^[s]. En termes simplifiés, les problèmes de la famille LWE consistent à trouver un vecteur secret s étant donné (A, b) où b = A·s + e mod q, avec A une matrice aléatoire et e un petit vecteur d’erreur^[s]. L’ajout de bruit rend ce problème difficile, même pour les ordinateurs quantiques, car il se ramène au problème du vecteur le plus proche sur les réseaux.

Mais même les algorithmes post-quantiques ne sont pas à l’abri d’un aléatoire faible. La norme FIPS 203 indique que les garanties de sécurité de ML-KEM dépendent de la confidentialité de plusieurs valeurs, y compris l’aléatoire utilisé par les deux parties^[s]. La robustesse mathématique de l’algorithme devient sans importance lorsque l’aléatoire qui l’alimente peut être deviné.

Architecture du pool d’entropie

La génération de clés cryptographiques modernes commence par la collecte d’entropie. Le noyau Linux maintient un seul pool d’entropie alimenté par un CSPRNG basé sur ChaCha20. Les interruptions d’événements matériels, y compris les frappes au clavier, les achèvements de disque, le timing d’arrivée des paquets réseau et les événements USB, contribuent à des variations de timing qui alimentent l’entrée du pool^[s]. Le pool utilise BLAKE2s (depuis le noyau 5.17) pour le hachage des entrées, intégrant la nouvelle entropie dans l’état existant.

La distinction critique : l’estimation de l’entropie (bits d’entrée imprévisible mélangés) est séparée de la génération de sortie (octets pseudo-aléatoires produits). Une fois que le pool atteint le seuil de semis de 256 bits, le CSPRNG ChaCha20 produit indéfiniment des sorties avec des garanties de sécurité cryptographique.

Avant le noyau 5.6, /dev/random bloquait lorsque les estimations d’entropie tombaient en dessous du seuil, tandis que /dev/urandom retournait des sorties sans la même sémantique de blocage. Depuis le noyau 5.6, /dev/random ne bloque plus après le démarrage initial, mais les pages de manuel Linux actuelles mettent toujours en garde contre le fait que /dev/urandom peut retourner des données avant l’initialisation lors du démarrage précoce. L’appel système getrandom(2), introduit dans le noyau 3.17, est l’interface préférée pour les applications sensibles au démarrage précoce, car il bloque jusqu’à ce que le pool d’entropie soit initialisé, sauf si GRND_NONBLOCK est défini^[s][s].

Propriétés de sécurité des CSPRNG

Un générateur de nombres pseudo-aléatoires cryptographiquement sûr doit satisfaire des exigences de sécurité formelles. Le test du bit suivant exige que, étant donné une séquence quelconque de bits de sortie, aucun algorithme en temps polynomial ne puisse prédire le bit suivant avec une probabilité significativement supérieure à 50 %^[s]. La résistance à l’extension de la compromission de l’état garantit que, si un attaquant compromet l’état interne, il ne peut pas déterminer les nombres générés avant la compromission^[s].

Le CSPRNG utilise une fonction cryptographique unidirectionnelle sécurisée (une fonction de hachage comme SHA-256 ou un chiffrement par bloc comme AES) pour mélanger l’état interne et produire la sortie. La sortie est ensuite réinjectée dans l’état interne^[s]. La publication spéciale 800-90A Rev. 1 du NIST spécifie les mécanismes DRBG (Deterministic Random Bit Generator) approuvés, basés sur des fonctions de hachage et des chiffrements par bloc^[s].

Modes de défaillance dans la génération de clés cryptographiques

La vulnérabilité Debian OpenSSL, révélée en 2008 et introduite par une modification spécifique à Debian téléchargée pour la première fois le 17 septembre 2006, illustre une défaillance catastrophique d’entropie^[s]. Le bug ne laissait que l’identifiant de processus (PID) comme entrée effective d’aléatoire^[s]. Comme les PID Linux varient généralement de 0 à 32 767, de nombreuses clés affectées se réduisaient à un ensemble énumérable qui pouvait être précalculé.

La recherche « Mining Your Ps and Qs » de 2012 a exploité une défaillance plus subtile. La génération de clés RSA nécessite la sélection de deux grands nombres premiers aléatoires p et q ; le module public N = p × q. Lorsque deux clés partagent un facteur premier (c’est-à-dire N₁ = p × q₁ et N₂ = p × q₂), le calcul de gcd(N₁, N₂) révèle p, factorisant immédiatement les deux clés. Les chercheurs ont calculé des GCD sur 11 millions de modules RSA distincts et ont obtenu des clés privées pour 0,50 % des hôtes TLS et 0,03 % des hôtes SSH dans leur analyse, les clés faibles étant concentrées dans les appareils sans écran et embarqués qui généraient des clés avec une entropie insuffisante^[s].

La vulnérabilité de PuTTY en 2024 (CVE-2024-31497) concernait un biais dans les nonces ECDSA. ECDSA nécessite un nonce k unique et imprévisible pour chaque signature. Le générateur de signatures P-521 de PuTTY produisait des valeurs de nonce dont les neuf bits supérieurs étaient toujours à zéro, introduisant un biais statistique. À partir d’environ 60 signatures, un attaquant pouvait récupérer la clé privée de signature^[s].

Générateur de nombres aléatoires matériel et limites de confiance

L’instruction RDRAND d’Intel (Ivy Bridge, 2012) et son implémentation par AMD (Zen, 2017) fournissent une génération de nombres aléatoires matérielle. Cependant, une dépendance exclusive au générateur matériel soulève des questions de confiance. En 2019, les systèmes AMD Ryzen avec certaines versions de firmware renvoyaient des valeurs constantes depuis RDRAND, un bug confirmé qui aurait affaibli de manière catastrophique tout système lui faisant entièrement confiance^[s].

Le comportement actuel du noyau consiste à effectuer un OU exclusif (XOR) entre la sortie de RDRAND et le pool d’entropie, en tant qu’entrée parmi d’autres. Cette défense en profondeur garantit qu’un matériel compromis ne peut à lui seul compromettre le pool si d’autres entrées d’entropie restent indépendantes.

Génération de clés post-quantiques

L’algorithme de Shor réduit la factorisation des entiers et les problèmes de logarithme discret à la recherche de période, résoluble en temps polynomial sur un ordinateur quantique^[s]. Cela menace RSA, Diffie-Hellman et la cryptographie sur les courbes elliptiques.

La génération de clés cryptographiques post-quantiques repose sur des problèmes liés aux réseaux. Le problème Module Learning With Errors (MLWE) sous-jacent à l’algorithme ML-KEM implique de trouver un vecteur secret s étant donné (A, b) où b = A·s + e mod q, avec A une matrice aléatoire et e un petit vecteur d’erreur^[s]. L’ajout de bruit rend ce problème difficile, même pour les ordinateurs quantiques, car il se ramène au problème du vecteur le plus proche sur les réseaux.

Mais les exigences en matière d’entropie ne diminuent pas pour les systèmes post-quantiques. La norme FIPS 203 indique que les garanties de sécurité de ML-KEM dépendent de la confidentialité de plusieurs valeurs, y compris l’aléatoire utilisé par les deux parties^[s]. La robustesse mathématique ne peut compenser des entrées prévisibles.

Dérivation de clés et normes de portefeuilles

Les portefeuilles de cryptomonnaies implémentent une dérivation hiérarchique de clés suivant les normes BIP-32, BIP-39 et BIP-44. Ces protocoles transfèrent l’entropie en nombres aléatoires, puis en phrases mnémoniques, et enfin en clés hiérarchiques contrôlant les actifs^[s]. Certains portefeuilles matériels isolent la génération de clés dans du matériel dédié avec de véritables générateurs de nombres aléatoires, séparant la collecte d’entropie des systèmes d’exploitation à usage général potentiellement compromis.