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.
Commentaires (70)
#1
un attaquant qui obtient 4 640 bits du générateur peut facilement prédire les 160 bits suivants On est quand meme loin d’une faille catastrophique…
#2
#3
C’est le problème du libre ça. Comme le source est disponible les failles sont visibles facilement.
En gros c’est comme si une banque installait un super système de sécurité mais laissait les plans sur internet.
N’importe qui qui travaille dans la sécurité sait que le secret est primordial.
Donc il ne faut jamais utiliser du libre quand on veut faire de la sécurité à cause du manque de secret, ce qui s’applique à la vie réelle s’applique aussi à l’informatique.
#4
On est pas vendredi !
" />
#5
#6
Troll du jour, bonjour !
#7
Bravo pour la comparaison complètement foireuse. Un must je dois dire!
#8
C’est pour cela que tu utilises ce pseudo ! Bien vu !
Comme ça, on ne peut pas dire qui tu es.
#9
#10
“pgp un truc de terroristes” @ casevieille
#11
#12
#13
#14
Oh boy. Ça a mordu.
#15
#16
sérieux? t’as répondu à ça?
" />
" />
#17
réflexe conditionné, je pense
" />
#18
eh ben ça mord aujourd’hui.
" />
#19
Don’t feed the troll. ;)
" />
Edit :
#20
post édité à moitié pardonné.
" />
#21
#22
#23
#24
#25
Désolé, je ne peux résister à répondre à quelqu’un qui est aussi intelligent qu’Ulysse qui disait au Cyclope qu’il s’appelait Nemo.
À propos, ce soir, est diffusé “Mon nom est Personne” sur France 3.
#26
Mimées ?
" />
" />
J’aurais préféré “contre-façonnées”
#27
#28
#29
#30
#31
PGP permet de faire les deux (peut être pas avec les même clef cela dit)
edit: grillé
#32
#33
PGP peut forger un certificat qui sert a signer ou a chiffrer.
Edit : double BBqed.
#34
J’ai pas voulut faire du troll … désolé !
Au pire un peu de feed, mais simplement pour démontrer sa bêtise… et je ne pense pas être le seul…
Bref, j’ai l’impression que le courant passe mal en ce moment avec le communauté de NextImpact … pas grave … j’ai pourtant l’impression de partager pas mal les idées générales de celle-ci…
#35
Les hippies sont pas acceptés ici
" />
" />
#36
#37
Ah merci ! Ceci explique donc cela !
C’est donc un pur délit de faciès … j’accepte !
#38
J’ai mis à jour l’article avec une mention des signatures de clés mimées/contrefaites. En plus d’avoir “reproduit” un bon nombre de clés, les gens derrière cette petite opération ont soigné les détails en refaisant certaines signatures entre elles. Merci à Aeris pour le signalement.
" />
#39
Il faut donc relire l’article ?
#40
Oui, sinon tu passes à côté du vrai problème :P Le short-id tout seul est connu depuis des lustres.
#41
Juste le troisième paragraphe de la troisième partie, le reste ne bouge pas. C’est un simple ajout.
#42
#43
Oui, merc, j’ai vu l’ajout. Par contre, mon écran n’est pas assez grand pour visualiser le graphique. Je dois zoomer et me déplacer.
" />
#44
La même ici, du coup je joue au Christophe Colomb des signatures PGP. 
" />
#45
Merci de me rassurer 
" /> !
" />)
On est pas dredi n’ont plus … mais vu comment commence la semaine je suis iNpatient (promis, plus de feed de ma part
#46
Au vu du pseudo c’était facile
" />
#47
Au vu du pseudo c’était facile pour un hippi 
" />
" />
Parce que bon c’est pas non plus l’évidence pour non averti
#48
C’était pour vous démasquer :)
#49
Il a tout autant de mérite à être connu que certaines personnes actuellement (voir même plus que certaines)
" />
#50
J’ai ajouté des couleurs histoire de pouvoir distinguer les clefs collisionnées (même short-ID = même couleur (mais la réciproque est fausse :P))
#51
Elle est sensée, cette réflexion, et plein de bon sens. Mais de l’autre côté, on peut passer à côté d’un trou béant sans le voir. Pas assez de yeux pour le voir ou ceux-ci rivés ailleurs.
#52
Je comprend pas trop la première faille. C’est davantage une faille d’un site qui collecte les clés publiques plutôt que de PGP lui-même, non ?
#53
Merci à ceux qui ont travaillé, ceux qui y travaille encore, ceux qui viendront s’ajouter dans le futur et aux donateurs qui sans eux le produit risque d’avancer lentement. Unissons nos forces pour avancer plus vite et plus surement.
Vive le libre!
#54
et windows est reconnu pour être une passoire de sécurité
" />
#55
Au moins tu nous as fait rigoler !
" />
#56
#57
Rajoute aussi qu’il y a une volonté de recréer l’emprunte par captation de messages “legit” envoyés aux serveurs : le cassage du certif ne se fait pas par brute force mais par compilation de réponses.
La volonté n’étant pas plus de casser que d’avoir une emprunte valide durable dans le système.
Pour la puissance de calcul, elle est toute relative, ça fait un certain temps que les puces AMD sont devenues très bonnes pour faire ce genre d’opérations sha/ash + guess, restait qu’a monter un POC pour montrer que PGP était faillible de la sorte sur certaines configs.
Se qui m’étonne, c’est le nombre de bits nécessaires relativement faible pour reforger une clé valide, ça veux dire que derrière reforger une empreinte complète devient possible en relativement peu de temps. :/
#58
Ça pêche a la dynamite par ici.
#59
#60
Question: À qui profite le crime la faille ?
" />
Vu la débauche de moyens mis en œuvre c’est pas Jean-Paul dans sa cave de geek qui fait ça…
#61
#62
Haaaa, une niouze qui a une semaine. Je l’attendais.
" />
#63
#64
Merci du compliment, parce que c’en est un pour moi.
" />
#65
“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.“Tu récupère bien des clés legit dans ce cas. Il suffit d’une clé forgée par collision “faible” dans la chaîne de confiance et toutes les autres tombent en cascade. Il n’y a pas bruteforce => tu reforge le certificat racine a la suite. Tu collisione pas toutes les clés, juste une suffit : comme dit au dessus tu reproduis ensuite le certificat racine.
#66
#67
Je suis loin d’être expert, mais le problème c’est pas tout simplement les short-ID ?
Je vois ça comme si je choisissais un mot de passe long et compliqué pour une bonne sécurité, mais vu que c’est pas pratique à utiliser j’utilise un gestionnaire de mot de passe avec un mot de passe global qui ne casse pas trois pattes à un canard…
C’est assez stupide, non ?
#68
Merci pour ces détails et les suivants.
#69
#70
Moralité, plus c’est long, plus c’est bon…
" />