La semaine dernière, les mauvaises nouvelles se sont accumulées autour de PGP. Plusieurs développeurs du noyau Linux ont constaté que de fausses clés PGP ont été mises en ligne, mimant les identifiants des leurs. De son côté, GnuPG a corrigé un bug de son générateur de nombres aléatoires, vieux de 18 ans.
Alors que le chiffrement semble souvent se résumer à un concours de force, certaines vulnérabilités peuvent facilement permettre de mettre à mal le système. C'est ce qu'a prouvé la semaine dernière une révélation autour des développeurs du noyau Linux et la correction d'une vieille faille dans GnuPG.
Des clés PGP publiques « mimées »
Ainsi, depuis juin, il a été découvert que les clés PGP publiques de plusieurs développeurs du noyau Linux, dont celles de Linus Torvalds et de Greg Kroah-Hartman, ont été mimées. De fausses signatures, créées au plus près des vraies, ont ainsi été forgées. Certaines de ces clés servaient habituellement à signer les mises à jour du noyau Linux, un élément des plus sensibles. Elles ont depuis été révoquées et remplacées par d'autres, plus sûres. Cela même si aucune conséquence concrète n'a été signalée.
Pour mémoire, PGP permet de signer et de chiffrer nombre d'éléments, dont les emails. Avec une clé privée (que seul le propriétaire possède) et une clé publique, chaque message peut être certifié facilement. Mais le système n'est pas parfait.
Par exemple, la clé PGP publique de votre serviteur est listée en ligne avec l'identifiant « 0x205354a9a507b285 ». Une référence rapide pour une clé de plus de 2 000 caractères. C'est cet identifiant que le rédacteur de ces lignes communiquera pour pointer vers la clé complète, qui servira au correspondant pour signer ou chiffrer un message à son intention.
Un identifiant court... trop court
Le problème est qu'il est possible d'utiliser des identifiants très courts, de 32 bits ou moins (soit environ 8 caractères). Avec une combinaison si courte, il est possible de créer une « collision » entre deux clés. En clair, deux clés publiques peuvent avoir exactement le même identifiant, et ce, assez simplement.
Après avoir créé une clé avec le même identifiant qu'une clé légitime, et en l'utilisant avec des contacts habituels de la victime, il est possible (dans une certaine mesure) de se faire passer pour elle. Aussi, dans le cas où les clés sont mises en ligne sur un registre public, un logiciel qui voudra y récupérer les clés de chiffrement (à partir de l'identifiant court) pourra prendre la mauvaise clé.
De plus, leurs signatures par d'autres clés peuvent elles aussi être mimées. Avec PGP, il est possible de signer la clé de quelqu'un d'autre, pour certifier sa légitimité. Une « toile de confiance » qui fait la force du système. Or, comme le montre ce graphique conçu par Aeris, de nombreuses signatures ont été scrupuleusement reproduites (en haut à droite), créant une confusion d'autant plus forte pour certaines de ces clés.
Le problème de la faiblesse des identifiants de 32 bits ou moins est largement connu. Dès 2011, la communauté Debian alertait à son propos, quand un site Evil32 a récemment été monté pour illustrer le problème. Une « collision » pourrait ainsi être provoquée en quelques secondes, un problème grave pour un tel outil. Selon Greg Kroah-Hartman, les développeurs du noyau Linux n'ont pas été les seuls visés. L'opération aurait concerné 24 000 clés considérées de confiance.
Un autre exemple. Jusqu'en 2014, GnuPG, l'outil de référence pour générer et gérer les clés, ne vérifiait généralement pas celles reçues. Une attaque type homme du milieu ou un DNS menteur, pour mener vers un faux serveur avec une clé disposant du même identifiant, pouvait ainsi conduire à télécharger une clé malicieuse en toute discrétion.
GnuPG règle un problème vieux de 18 ans
Sur un sujet proche, GnuPG voit sa sécurité renforcée. Dans un message publié le 17 août, Werner Koch, l'auteur de GnuPG et Libgcrypt, propose des mises à jour de ses logiciels pour corriger un bug dans le générateur de nombres aléatoires (RNG) de Libgcrypt. Le problème est simple : « un attaquant qui obtient 4 640 bits du générateur peut facilement prédire les 160 bits suivants ».
Ainsi, GnuPG 1.4.21 et Libgcrypt 1.7.3, 1.6.6 et 1.5.6 pour GnuPG-2 corrigent cette vulnérabilité, présente depuis les débuts de l'outil il y a de cela 18 ans. Pour le moment, les clés générées avec le logiciel ne semblent pas être à risque. « Une première analyse sur l'impact de ce bug dans GnuPG montre que les clés RSA existantes ne sont pas affaiblies » estime Werner Koch. Un impact semble aussi peu probable sur les clés DSA et Elgamal, estime-t-il. Il invite donc à ne pas révoquer ses clés trop hâtivement.
Pour mémoire, GnuPG est l'un de ces projets open source largement utilisés, mais peu soutenus financièrement. Il a fallu largement médiatiser les difficultés financières de Werner Koch. Les dons avaient afflué, de la part de particuliers et d'entreprises, dont Facebook qui a implémenté GnuPG par la suite dans sa messagerie.
