Vulnérabilité dans la génération de signatures de clés privées ECDSA sur la courbe NIST P521 dans l’outil PuTTY
- Toutes les versions de PuTTY de 0.68 à 0.80 présentent une vulnérabilité critique dans le code qui génère des signatures à partir de clés privées ECDSA utilisant la courbe NIST P521
- Le problème survient lorsque PuTTY ou Pageant génère une signature à partir de la clé lors de l’authentification auprès d’un serveur SSH
- Cette vulnérabilité a reçu l’identifiant CVE-2024-31497
- Elle a été découverte par Fabian Bäumer et Marcus Brinkmann de la Ruhr University Bochum
Impact de la vulnérabilité
- L’impact de cette vulnérabilité est l’exposition de la clé privée
- Si un attaquant dispose de quelques dizaines de messages signés et de la clé publique, il possède suffisamment d’informations pour reconstruire la clé privée
- Il peut alors forger des signatures comme s’il était l’utilisateur et se connecter à tous les serveurs utilisant cette clé
- Pour obtenir ces signatures, il suffit à un attaquant de compromettre brièvement un serveur auprès duquel la clé sert à s’authentifier, ou d’avoir un accès temporaire à une copie de Pageant contenant la clé
- En revanche, ces signatures ne sont pas exposées à un espion passif écoutant simplement la connexion SSH
- Si vous possédez ce type de clé, il est recommandé de la révoquer immédiatement
- Il faut supprimer l’ancienne clé publique de tous les fichiers
authorized_keys d’OpenSSH ainsi que des fichiers équivalents sur les autres serveurs SSH, afin que les signatures issues de la clé compromise n’aient plus de valeur
- Il faut ensuite générer une nouvelle paire de clés pour la remplacer
Types de clés affectés
- Le seul type de clé affecté est l’ECDSA 521 bits
- Dans PuTTYgen sous Windows,
ecdsa-sha2-nistp521 apparaît au début du champ Key fingerprint; dans Pageant sous Windows, elle est décrite comme NIST p521; dans le protocole SSH ou dans les fichiers de clé, son identifiant commence par ecdsa-sha2-nistp521
- Les autres tailles d’ECDSA et les autres algorithmes de clé ne sont pas affectés
- En particulier, Ed25519 n’est pas affecté
Détails de l’erreur
- Tous les schémas de signature DSA doivent générer une valeur aléatoire pendant la signature
- On l’appelle
nonce (terme cryptographique désignant une valeur à usage unique), ou la lettre k
- Il est bien connu que si un attaquant peut deviner la valeur de k utilisée, ou trouver deux signatures générées avec la même valeur de k, il peut immédiatement reconstruire la clé privée
- C’est pourquoi générer des signatures DSA sur un système dépourvu d’une source d’aléa de haute qualité est risqué
- Comme PuTTY a été développé sur Windows, il ne disposait à l’origine d’aucun générateur cryptographique de nombres aléatoires
- PuTTY a donc généré k de manière déterministe, sans utiliser de nombres aléatoires
- La technique centrale consiste à calculer un hachage sécurisé incluant à la fois le message à signer et la clé privée dans l’entrée du hachage
- Cette technique est aujourd’hui largement adoptée, et la RFC 6979 documente une méthode concrète et bien connue pour la mettre en œuvre
- Cependant, PuTTY utilisait déjà depuis 2001 sa propre méthode pour faire la même chose, et la RFC n’a été publiée qu’en 2013, de sorte qu’elle ne suivait pas cette spécification
Cause de la vulnérabilité
- La technique de PuTTY consiste à produire un hachage SHA-512 puis à le réduire modulo q, l’ordre du groupe utilisé dans les systèmes DSA
- Dans tous les cas sauf P521, le biais introduit par la réduction d’un nombre sur 512 bits modulo q est négligeable
- Mais dans le cas de P521, q fait 521 bits (c’est-à-dire plus de 512 bits), donc réduire un nombre de 512 bits modulo q n’a aucun effet
- On obtient alors une valeur de k dont les 9 bits de poids fort sont toujours à 0
- Ce biais rend possible une attaque de reconstruction de clé
Correctif de la vulnérabilité
- Pour corriger cette vulnérabilité, PuTTY abandonne entièrement son ancien système de génération de k et passe à la technique de la RFC 6979 pour tous les types de clés DSA et ECDSA
- Les clés EdDSA comme Ed25519 utilisaient déjà un autre mécanisme et ne changent pas
- En revanche, cela ne change rien au fait que des informations sur les anciennes clés privées P521 ont déjà fuité chaque fois qu’une signature a été générée avec l’ancien générateur de k
L’avis de GN⁺
- Il s’agit d’une vulnérabilité découverte relativement récemment, mais qui semble provenir d’un problème dans une méthode utilisée depuis 2001. C’est un bon exemple des risques liés à une implémentation maison qui ne suit pas les standards dès le départ.
- Cette vulnérabilité ne touche qu’un type précis de clé, mais si cette clé a été utilisée, les conséquences peuvent être graves. Il est donc essentiel de révoquer immédiatement les clés affectées.
- Dans les projets open source, les parties liées à la cryptographie devraient suivre les standards et faire l’objet de vérifications externes. En particulier, la génération d’aléa est cruciale, et il est plus sûr de s’appuyer sur le système d’exploitation ou sur des bibliothèques éprouvées.
- PuTTY est un émulateur de terminal open source très utilisé, prenant en charge les protocoles SSH, Telnet et Rlogin, et apprécié pour sa capacité à enregistrer les informations de connexion. Il semble important de réagir activement aux futurs correctifs de sécurité.
- Sur macOS ou Linux, on peut utiliser à la place de PuTTY le terminal intégré ou iTerm2. Sous Windows, on peut envisager Windows Terminal, PowerShell ou Cmder comme alternatives.
4 commentaires
Ah..
Je ne pense pas avoir déjà utilisé ce type de clé, mais j’ai quand même fait la mise à jour.
En voyant ça, j’ai tout de suite mis à jour vers la version 0.81 haha
Avis Hacker News
Voici un résumé des commentaires de Hacker News :
kdevrait elle aussi être aléatoire sur 521 bits, mais PuTTY n’utilisait qu’un aléa sur 512 bits, ce qui remplissait les 9 bits de poids fort avec des zéros. Cela peut conduire à la divulgation de la clé privée via l’algèbre linéaire.putty) utilisé pour fixer les vitres des fenêtres.q. Il semblerait plus judicieux de ne garder que le nombre de bits nécessaire, ou de hacher séparément le message et la clé privée avant de les combiner.