Épuisement de l’entropie et erreurs liées aux clés faibles

La pénurie d’entropie se produit lorsqu’un système ne dispose pas d’une quantité suffisante de données imprévisibles pour initialiser son CSPRNG. Cela arrive sur les appareils embarqués qui viennent de démarrer, les serveurs virtualisés ou les systèmes ne recevant aucune entrée utilisateur. La sortie du RNG devient alors prévisible.

En 2006, un développeur Debian a supprimé une ligne signalée par Valgrind : MD_Update(&m, buf, j). Cette ligne constituait la source d’entropie. Résultat : OpenSSL sous Debian ne s’initialisait qu’avec le PID (au maximum 32 768 valeurs). Toutes les clés générées entre 2006 et 2008 appartiennent à un ensemble de 32 768 possibilités.

Les clés RSA, DSA et ECDSA, les clés d’hôte SSH, les certificats TLS et les clés de VPN SSL générés sur les systèmes Debian et Ubuntu entre 2006 et 2008 ont été compromis. Systèmes concernés : Debian Etch, Debian Lenny et Ubuntu 7.04 à 8.04. Des listes noires ont été publiées et les certificats ont été révoqués.

Les machines virtuelles (VM) peuvent être clonées avec un état de disque identique. Si les deux VM génèrent des clés à partir du même état du CSPRNG, elles produisent les mêmes clés. Les hyperviseurs injectent désormais de l’entropie via VirtIO RNG ou des tables ACPI, mais les VM mal configurées restent exposées à ce risque au démarrage.

Les appareils IoT (routeurs, caméras) génèrent souvent leurs clés SSH et TLS lors du premier démarrage, avant d’avoir accumulé suffisamment d’entropie. Des études ont révélé que des millions d’appareils partageaient quelques milliers de paires de clés RSA, car ils étaient tous initialisés à partir du même état de démarrage à faible entropie.

Lenstra et ses collègues (2012) ont recueilli 11,7 millions de certificats TLS et calculé les GCD deux à deux. Ils ont trouvé 12 720 clés RSA partageant un facteur premier, ce qui signifiait que les deux clés pouvaient être entièrement factorisées. 0,2 % de l’ensemble des clés publiques étaient compromises. Cause : entropie insuffisante au démarrage.

ECDSA nécessite un nonce aléatoire k unique pour chaque signature. Si k est réutilisé (ou faible), la clé privée peut être récupérée immédiatement : d = (s1-s2)^{-1} * (z1-z2) * k / (r1-r2) mod n. La PS3 de Sony utilisait k=constant : tous les jeux pouvaient être signés avec la clé récupérée.

SecureRandom de Java sur Android 4.x était initialisé avec l’heure système dans certaines conditions. Plusieurs applications de portefeuille Bitcoin ont généré des signatures avec le même nonce k, révélant les clés privées. Des millions de dollars ont été volés. Google a corrigé l’implémentation de SecureRandom.

Outils : ssh-vulnkey (vérifie les clés par rapport à la liste noire des clés faibles de Debian), badkeys (vérifie les certificats TLS à la recherche de facteurs premiers connus comme faibles), algorithme de calcul groupé des GCD pour l’audit en masse des clés RSA. Les journaux de transparence des certificats permettent une analyse à l’échelle de toute une population.

Utilisez getrandom(GRND_RANDOM) lors de la toute première génération de clé. Lisez depuis /dev/urandom après avoir attendu l’initialisation initiale (vérifiez que /proc/sys/kernel/random/entropy_avail > 128). Utilisez un RNG matériel (RDRAND) comme source d’entropie supplémentaire. Ne générez jamais de clés au premier démarrage sans délai d’attente.

Conservez l’état du CSPRNG entre les redémarrages : enregistrez 32 octets de /dev/urandom dans un fichier de graine lors de l’arrêt ; lisez ce fichier et réinjectez son contenu au démarrage. Cela assure la continuité de l’entropie entre les démarrages à froid. Linux le fait automatiquement, contrairement à de nombreux systèmes embarqués.

Quelle était la cause fondamentale du bogue d’entropie d’OpenSSL dans Debian ?

La pénurie d’entropie entraîne la génération de clés prévisibles. Compromissions réelles : OpenSSL sous Debian (graine limitée au PID), attaques par GCD contre des appareils IoT, réutilisation du nonce ECDSA de la PS3 et portefeuille Bitcoin Android. Initialisez toujours le générateur à partir de l’entropie de l’OS ; vérifiez soigneusement la génération de clés sur les systèmes embarqués. Ensuite : générer des clés, des nonces et des IV en toute sécurité.