Club LinuX Nord-Pas de Calais

10- Un bug de GnuPG compromet les clés ElGamal

Fabien ILLIDE, Gaétan RYCKEBOER — 2003-12-05T11:05:33Z

Werner Koch a annoncé le 27 novembre 2003 la découverte par Phong Nguyen (un étudiant de l'ENS) d'un bug critique dans GnuPG. Ce bug permet d'obtenir en quelques secondes la clé secrÚte de certaines personnes. Une fois cette clé en sa possession, un utilisateur malveillant peut ainsi usurper leur identité ou déchiffrer leurs couriers électroniques. Et moi, comment vérifier si je suis concerné ?

Effectivement, la découverte de ce problème a suscité de nombreuses interrogations de la part des utilisateurs de GnuPG. Heureusement, seules les doubles clés utilisant l'algorithme ElGamal pour la signature et le chiffrement sont affectées, et leur nombre total est estimé à environ un millier.

La liste de toutes les clés de votre trousseau affectées peut être obtenue avec la commande suivante :
gpg --list-keys --with-colon | awk -F: '{if($4 == 20) print "gpg --list-keys 0x"$5}'

Ou grâce à cette autre commande, plus simple mais moins complète :

gpg --list-keys | grep 1024G gpg --list-keys | grep 2048G

Voici un exemple de clé affectée :
pub 1024D/xxxxxxxx 1998-10-12 Foo bar
sub 1024G/xxxxxxxx 1998-10-12 [expire : 2012-10-25]

(sous Windows, il faut utiliser la commande gpg --list-keys --with-colon | FIND ":20:")

Notez le G majuscule qui indique les doubles clés ElGamal pour le chiffrement ou la signature. Les clés marquées d'un D (DSA), d'un R (RSA) ou d'un g (ElGamal simple) ne sont pas compromises. Dans le cas présent, c'est une sous clé qui est compromise ; il ne faut pas révoquer la clé primaire, mais simplement la sous clé (via la commande gpg --edit-key).

Si votre clé publique est compromise, vous devez immédiatement créer un certificat de révocation et le transmettre aux serveurs de clés, puis en informer toutes les personnes ayant signé votre clé, afin qu'elles révoquent leur signature. Il faut absolument sortir du réseau de confiance et éviter ainsi qu'un tiers usurpe votre identité et compromette la totalité de votre réseau de confiance.

Reportez vous au paragraphe 3 de notre FAQ GPG pour savoir comment révoquer votre clé.

Un patch (correctif de sécurité) servant à désactiver cette fonction est disponible. Il sera intégré aux prochaines versions de GnuPG.

Pourquoi révoquer sa signature ? Elle est indépendante de la clé, non ?

Signer une clé consiste à dire : « cette clé a été vérifiée. Elle appartient bien à la personne qui prétend la détenir. Si vous me faites confiance, vous pouvez lui faire confiance ». C'est vrai, au moment de la signature, puisque gpg est réputé sûr, et que vous avez vérifié un papier d'identité attestant de l'identité de la personne vous présentant la clé à signer.

Mais la signature dit aussi que l'utilisateur peut faire confiance à cette clé. Moi, qui l'ai signée, je lui accorde la mienne. Or, j'ai connaissance d'une faille qui permet à un tiers de s'approprier cette clé, et de se faire passer pour la personne qui a émise la clé gpg et me l'a présentée.

Autrement dit, j'ai connaissance d'un moyen qui permet à quelqu'un d'autre de l'utiliser à mon insu. La clé n'est donc plus sûre, et je le sais. Je ne peux me permettre de dire que j'accorde ma confiance à cette clé. Je révoque donc ma signature, qui représente la relation de confiance.

En générant le certificat de révocation, je dit ouvertement que j'ai signé la clé, mais que maintenant je ne lui fais plus confiance :
« cette clé a été vérifiée. Elle appartenait, au moment de la vérification, à une personne qui a attesté de son identité. Maintenant, cette clé est potentielement (ou complètement) compromise. Si vous me faites confiance, ne faites plus confiance à cette clé ».

Maintenant, pour votre utilisation personelle, n'oubliez pas d'ajuster la valeur de confiance que vous accordez à la clé, en jouant sur le paramètre "trust" (voir le chapitre 4 de la FAQ, relatif aux réseaux de confiance).

D'accord. C'est donc important, ça fait partie de mon rôle de suivre les clés que j'ai signé, et leur validité. Mais maintenant, comment je la révoque, cette signature ? Comment j'annonce que cette clé n'est plus fiable ?

Prenons un cas pratique. Tout d'abord, je cherche les clés compromises que j'ai signé. Il n'y en a pas beaucoup, ça va aller vite.

gaetan@nutella:~$ gpg --list-keys | grep 1024G sub 1024G/A20XXXXX 1998-07-02 gaetan@nutella:~$ gpg --list-key A20832C0 pub 1024D/3DCXXXXX 1998-07-02 Xxxx XXXX <Xxx@foo.org> uid Xxxx XXXX <Xxx@debian.org> sub 1024G/A20XXXXX 1998-07-02 gaetan@nutella:~$ gpg --list-sig A20832C0 pub 1024D/3DCXXXXX 1998-07-02 Xxxx Xxxxxx <xxxx@foo.org> sig 52732D43 2003-07-29 Gaetan RYCKEBOER <gryckeboer@virtual-net.fr> sig 3674000A 2003-07-29 Gaetan RYCKEBOER <gaetan@ryckeboer.org> sig 3DCXXXXX 2001-05-05 Xxxx Xxxxxx <xxxx@foo.org> uid Xxxx Xxxxxx <xxxx@debian.org> .../... sig 442XXXXX 2000-07-20 [Nom utilisateur introuvable] sig 52732D43 2003-07-29 Gaetan RYCKEBOER <gryckeboer@virtual-net.fr> sig 3674000A 2003-07-29 Gaetan RYCKEBOER <gaetan@ryckeboer.org> sig 3DCXXXXX 1998-07-02 Xxxx Xxxxxx <xxxx@foo.org> sub 1024G/A20832C0 1998-07-02 sig 3DCXXXXX 1998-07-02 Xxxx Xxxxxx <xxxx@foo.org>

On voit que la clé ElGamal qui pourrait être compromise, est une sous clé de la clé DSA 1024D/3DCXXXXX. Personnellement, je n'accord pas ma confiance aux sous clés. Je choisis de révoquer mes signatures pour la totalité de la clé [1].

Ensuite, j'édite la clé [2], avec mon gpg mi-français mi-anglais, et j'utilise la commande revsig :

gaetan@nutella:~$ gpg --edit-key A20832C0 pub 1024D/3DCXXXXX créée: 1998-07-02 expire: never confiance: -/f sub 1024G/A20832C0 créée: 1998-07-02 expire: never (1) Xxxx Xxxxxx <xxxx@debian.org> (2). Xxxx Xxxxxx <xxxx@foo.org> Commande> revsig .../... Générer un certificat de révocation pour cette signature ? (o/N)y

Notez bien le "y", les questions sont en français, les réponses en anglais ;-)

Il va falloir donner une raison à la révocation. Seul le changement de nom d'utilisateur est possible, je vais mettre en commentaire la raison réelle de la révocation :

Vous êtes sur le point de révoquer ces signatures: Xxxx Xxxxxx <xxxx@debian.org> signé par 52732D43 à 2003-07-29 Xxxx Xxxxxx <xxxx@foo.org> signé par 52732D43 à 2003-07-29 Faut-il vraiment générer les certificats de révocation ? (o/N)y Please select the reason for the revocation: 4 = Le nom d'utilisateur n'est plus valide 0 = Cancel Votre décision ? 4 Enter an optional description; end it with an empty line: > ElGamal keys are now seriously compromised > .../... Is this okay? y

Maintenant, il suffit de taper son mot de passe, et de vérifier que tout s'est bien déroulé.

Commande> quit Enregistrer les changements? y gaetan@nutella:~$ gpg --list-sig A20832C0 pub 1024D/3DCXXXXX 1998-07-02 Xxxx Xxxxxx <xxxx@foo.org> rev 52732D43 2003-12-01 Gaetan RYCKEBOER <gryckeboer@virtual-net.fr> sig 52732D43 2003-07-29 Gaetan RYCKEBOER <gryckeboer@virtual-net.fr> sig 3674000A 2003-07-29 Gaetan RYCKEBOER <gaetan@ryckeboer.org> sig 3DCXXXXX 2001-05-05 Xxxx Xxxxxx <xxxx@foo.org> sig 3DCXXXXX 2001-05-05 Xxxx Xxxxxx <xxxx@foo.org> uid Xxxx Xxxxxx <xxxx@debian.org> rev 52732D43 2003-12-01 Gaetan RYCKEBOER <gryckeboer@virtual-net.fr> .../... sig 442XXXXX 2000-07-20 [Nom utilisateur introuvable] sig 52732D43 2003-07-29 Gaetan RYCKEBOER <gryckeboer@virtual-net.fr> sig 3674000A 2003-07-29 Gaetan RYCKEBOER <gaetan@ryckeboer.org> sig 3DCXXXXX 1998-07-02 Xxxx Xxxxxx <xxxx@foo.org> sub 1024G/A20832C0 1998-07-02 sig 3DCXXXXX 1998-07-02 Xxxx Xxxxxx <xxxx@foo.org>

On voit qu'une ligne nouvelle est apparue. Il y a un certificat de révocation sur les deux UID (xxxx@foo.org et xxxx@debian.org) que j'avais signés.

Tout en bas, on voit la sous clé ElGamal incriminée.

gaetan@nutella : /signatures$

[1] C'est mon avis, vous n'êtes pas obligés de faire comme moi, mais je n'aime pas jouer avec la sécurité, et les sous clés GPG sont très mal comprises voir mal gérées par les logiciels. Pour ne pas introduire de confusion dans la tête des utilisateurs, je décourage l'utilisation des sous clés, et ici, je révoque complètement ma confiance.

[2] gpg --edit-key #KID

11- Sous clefs et auto-signature

Gaétan RYCKEBOER — 2003-12-03T23:00:00Z

En pratique, de quelle façon les adresses e-mail contenues dans les UID sont-elles utilisées par mon client mail ?
Comment ça marche, les clés secondaires ?

Une clef contient effectivement plusieurs User ID ; c'est à dire que pour un même numéro de clef, il y a plusieurs adresses de courriel, associées chacune à un nom d'utilisateur.
Lorsque tu lis un courriel, le client de messagerie va demander à gpg de regarder dans ton trousseau de clefs publiques, s'il n'y en a pas une avec un UID qui correspond à l'adresse électronique d'où semble provenir le courriel.
S'il trouve une telle clef, gpg va regarder si elle a été signée par qauelqu'un à qui tu fais confiance, et calcule la valeur de confiance que l'on peut accorder à cette clef.

En fonction de ce "score", gpg va répondre au client de messagerie. Il va lui préciser si oui ou non le message est signé par une clef à laquelle tu peux faire confiance, et à quel niveau de confiance.

Pour cela, il est important d'estimer la confiance (en fait, lui affecter une valeur = valeur de confiance) que tu accordes aux clefs que tu signes, et éventuellement aux gens que tu n'a pas signé, mais avec lesquels tu dialogues régulièrement Et dont les clefs sont signées par un biais ou un autre par ta propre clef. Cela évite à gpg de recalculer à chaque fois une valeur qui exprime ta confiance. Il prend les valeurs que tu as attribuée aux clefs.

Attention, il faut apporter un soin particulier à la définition d'une valeur de confiance pour une clef donnée. Il faut encore une fois que tu te poses la question : « Cette personne, est-ce que je la connais ? Comment puis-je vérifier que ce n'est pas un imposteur ? Des personnes que je connais ont-elles signé la clef de cette personne ? »

Au final, tu ne signeras pas cette clef, puisque tu n'as pas vu son passeport, mais les autres questions, il faut que tu te les poses.
Tu dois également te demander si cette personne a bien compris le fonctionnement de gpg et de ses réseaux de confiance, et si elle ne signe pas n'importe comment. Eh oui, la confiance que tu lui accorderas influencera aussi indirectement la confiance apportée aux personnes et leurs clés (puiqu'elles ont été signées par la clé de cette personnes, avec une valeur de confiance calculée par gpg... On l'a vu au début du paragraphe).

Et les clefs secondaires ?

C'est une sorte de serpent de mer... Le besoin initial était de pouvoir révoquer sa clef, sans perdre le réseau de confiance. Tu as une clé primaire, qui est signée, que tu utilises pour signer. A cette clef, tu ajoutes des UID, ils ne sont pas signés, c'est normal.

Quelqu'un a dit un jour, que ce serait bien d'y ajouter des clefs secondaires, pour les différentes adresses email, ta vie personelle et professionelle, tes différents travaux... Ainsi, tu révoques la clef secondaire quand tu le souhaîtes, tu ne perds pas ton réseau de confiance.

Ce raisonnement a deux failles.

Que se passe-t-il si quelqu'un finit par s'introduire dans le réseau de confiance ? Il ne sera jamais "sorti", puisque tu gardes ta clef ad vitam eternam. Un "espion dormant" le restera le temps qu'il le souhaîtera. Et un jour, il pourra mettre à mal la confiance de l'ensemble des personnes de ton réseau de confiance. Ce n'est donc pas sûr, et va à l'encontre des buts sous-jacents de gpg.
Comment être sûr de la validité de la clef secondaire ? On vient tout juste de parler des clef ElGamal doubles, et de la possibilité de corruption de la fiabilité de ces dispositifs. Certains ont une clef ElGamal secondaire de leur clef primaire... comment faire dans ce cas ? La clef est-elle sûre ? Quand vous recevez un mail, vous vérifiez toujours avec quelle clef il l'a signée ? La secondaire, voire quelle clef secondaire ? La clef primaire ?

Non, décidément. Tout est mélangé, compliqué, complexifié par l'utilisation de ces clefs ; gpg est déjà suffisamment compliqué comme cela. Personnellement, je décourage fortement l'utilisation de clefs secondaires ; c'est jouer avec le feu. Un bonne clef, c'est une clef primaire DSA, pour chiffrer, et la clé secondaire ElGamal, pour signer. Point.

Dans la mesure ou mes UID sont auto-signés par ma clé privée (afin d'en attester de leur propriété), le fait de révoquer cette
auto-signature n'invaliderait-il pas indirectement l'UID entier (je n'ai dès lors plus de problème si je décide par exemple de changer d'email) ?
C'est une bonne idée, je n'y vois pas de contre indication ;-)
Voir à ce propose le chapitre 10 de la FAQ, relatif à la révocation des signatures.

Le fait de révoquer ma clé publique n'a des conséquences que sur ma
propre sécurité, n'est-ce pas ?

Révoquer une clef publique veut dire que tu vas dire au monde entier que tu avais une clef, mais que pour une raison X ou Y, il ne faut plus l'utiliser. Si quelqu'un reçoit un jour un message signé par cette clef, il ne devra pas lui faire confiance.

D'autre part, lorsque tu te recréeras une nouvelle clef publique, l'ancienne et sa révocation resteront sur le serveur. Tu apparaîtras donc plusieurs fois sur le serveur de clefs. Cela n'a pas d'autres implications que le regard de la personne qui s'en rendra compte et se demandera pourquoi.

9- Les UID associés aux clés

Gaétan RYCKEBOER — 2003-05-20T15:16:17Z

Ces histoires d'UID, c'est étrange. Ce qui m'intéresse, c'est pas de lier une clé et une adresse mail,
c'est de lier une clé et une personne physique, non ? C'est bien pour ça que je
demande la carte d'identité du possesseur de la clé avant de avant signer cette derniÚre.

Parce que globalement, qu'il m'écrive avec une adresse mail ou avec une autre,
tant que je suis sûr que c'est lui je suis content non ?

Pourquoi signe-t-on les UID distinctement des clé de ses interlocuteurs ?

Oui, mais comment identifier quelqu'un ? Dans la vraie vie, ce n'est pas
trop dur. Tu disposes de quelques critères rapides qui font appel à ta mémoire et
ton sens de l'observation et de de l'ouie ;-)

– son visage ;
– sa taille ;
– sa couleur de cheveux ;
– sa coupe de cheveux ;
– sa tenue vestimentaire ;
– son port (démarche/façon de se tenir) ;
– sa langue ;
– son langage ;
– sa voix ;
– ses intonations ;
– etc.

Ainsi, si l'un de ses aspects change entre le moment où tu auras mémorisé
l'individu et le moment où tu le rencontres à nouveau, tu éprouveras des difficultés à
l'identifier, mais si les autres caractères changent, tu parviendras tout de même à reconnaître la personne.
Un seul critère est généralement suffisant : voix, visage, empreintes
digitales permettent d'identifier l'individu dans 80% des cas. Mais une
voix, ça s'imite. Un visage, ça se maquille. Des empreintes... ça se
falsifie.
Seule la concordance de l'ensemble des critères augmente
la probabilité de reconnaissance au dessus d'un certain seuil,
que tu pourras considérer comme sûr (ou réputé sûr ?). Tu diras alors "Je
suis sûr à 95% que c'est bien le même individu", ce qui est
généralement abrégé en "c'est bien la même personne".

Bien. Maintenant, voyons l'identification électronique.
Tu disposes de plusieurs critères :
– adresse courriel ;
– façon de rédiger ;
– adresse IP ;
– serveurs de messagerie ;
– taille du message ;
– pays d'envoi ;
– heure d'envoi ;
– logiciel de messagerie utilisé ;
– nom ;
– prénom ;
– clé GPG.

Un des problèmes du numérique, c'est la facilité avec laquelle on peut imiter/falsifier l'un, voire l'ensemble des critères de reconnaissance.

Là, au moment où je te parle (où tu me lis plutôt), comment peux-tu être sûr que c'est
bien moi que tu entends^Wlis ? Mon courriel ? Rien de plus facile à
falsifier. Ma parlure ? Mouais, c'est plus un critère secondaire. Mon IP
? Le serveur d'envoi ? Je connais d'autres abonnés à la liste qui ont le mot de passe root sur ce serveur. Le logiciel d'envoi ? Mutt, c'est facile à trouver. Beaucoup de monde l'utilise. L'heure d'envoi ? C'est vrai qu'en général les gens travaillent à 15h30... ou sont au café. Taille du message ? Bof... Clé GPG ? Si elle n'est pas compromise, c'est un bon moyen, en
effet.
Reprenons donc. Rien n'est sûr sur le Net, pas même l'adresse courriel. Néanmoins, on peut supposer que si un utilisateur qui vous présente sa clé est soigneux et que même si sa clé publique a été barbotée, il aura pris la peine de vérifier que ses adresses déclarées (vraisembablement sur plusieurs serveurs - genre laposte.net, free.fr,
boulot.com) ne sont pas tous compromises simultanément. C'est à dire que le voleur ne pourra pas relever toutes les boîtes électroniques à la fois.
En revanche, rien n'empêche le voleur de clé de se fabriquer une boîte aux lettres chez Hotmail.com par exemple, en utilisant l'identifiant (et d'autres informations comme le nom ou le prénom) de la personne à qui appartenait la clé initialement.

Comme le voleur sait utiliser la clef privée parce qu'il connaît la passphrase (phrase d'authentification), ou qu'il n'y en a pas, il ajoute son adresse de courriel à la clef GPG. Ainsi, il gagne une chance de plus de ne pas être
démasqué par toutes les personnes qui prennent pour habitude de faire confiance aux clef GPG et aux informations qu'elles contiennent.
Tu reçois un mail de toto@hotmail.com signé par la clé n°1234 qui est celle qu'utilise habituellement toto@linux.net. D'ailleurs, tu as signé cette clé, et l'adresse toto@hotmail.com y figure - du moins sur les
serveurs de clé -. Tu te dis "ah, toto s'est fait un nouvel e-mail". Et tu mets à jour ton trousseau.

L'intérêt pour le voleur, c'est qu'il t'écrit depuis un e-mail que tu
penses appartenir à toto, mais qui lui est complètement étranger. Toto
ne sais pas que tu crois lui parler. C'est tout bénef pour le voleur.

Si les signatures GPG étaient associées au numéro de clé, et non au
courriel, tu n'aurais - à la limite - aucun moyen de savoir que toto a
un nouvel e-mail. Pire, comme TU as signé la clé, et que le voleur a
ajouté son e-mail qu'il utilise pour se faire passer pour toto, les gens
à qui il va écrire auront confiance. Ils n'imagineront même pas que toto
a un nouvel e-mail en hotmail.com depuis le moment où tu as signé sa
clé.

La clé est compromise, c'est sûr, mais ni toi ni le vrai toto, ne le sauront peut-être pas avant que le voleur ait accompli son forfait.

GPG ne servirait alors à rien.

Pour éviter cela, il FAUT signer chaque UID lors des "soirées GPG échange de
clé", et se méfier lorsque des UID sont ajoutés.

Ne pas oublier les questions rituelles : "toto@hotmail.com, c'est bien à
toi ?"

Là, j'ai quand même la vague impression que c'est, comme on dit,
"overkill". J'ai peur que ce genre de subtilité freine l'adoption de
GPG, mais je reconnais qu'il peut y avoir une utilité.

Overkill = tuer les mouches au bazooka, c'est ça ? Désolé, je ne cause pas bien le nerd.

Bon. Il faut bien comprendre que les réseaux de confiance GPG (PGP) ne tiennent qu'à un fil. Si l'un des membre (maillon) du réseau est défaillant, prend la sécurité par dessus la jambe, signe un peu n'importe qui, il met en péril l'ensemble des membres du réseau. Lorsque vous signez des clef, il faut bien être sûr que la personne à qui vous accordez votre confiance ait bien compris cet aspect. Personnellement, le nombre de clé que j'ai signées se compte sur les doigts d'une seule main. Par exemple, je ne signerais pas la clé GPG de quelqu'un qui signe trop de clés, même si par ailleurs je lui fais confiance. Je ne lui accorderais pas la délégation de la mienne

Tout cela pour dire, que la signature des UID est une sécurité supplémentaire, et que GPG ne PEUT PAS être utilisé avec tous ses mécanismes, de façon simple et sécurisée à la fois.

Cela dit, si on ne signe pas n'importe quoi, si on n'a pas de besoins de sécurité extraordinaires, nul besoin de se péoccuper des détails : On protège bien sa clé. On crée un certificat de révocation au cas où. On ne diffuse pas sa passphrase. On restera dans des conditions d'utilisations moyennes, et il ne devrait pas y avoir de problème.

D'autre part, J'en ai fait la douloureuse expérience, moins il y a d'UIDs associés à une clef donnée, mieux c'est. L'idéal étant d'avoir UNE clef par adresse de courriel. Personnellement, j'ai une clef professionnelle, et
une clef personnelle. Si ma clef perso, j'ai 3 UID, en laposte.net, free.fr, et ryckeboer.org. Si un beau jour je ne loue plus ryckeboer.org, je n'ai plus qu'à révoquer ma clef. Pareil si je change de fournisseur d'accès Internet et quitte Free.fr.

Mettre plus de 3 UID sur une clef me paraît plus que déraisonnable.

6- Fingerprint (empreinte digitale) d'une clé

Gaétan RYCKEBOER — 2002-05-15T22:00:00Z

Comment créer le fingerprint ?
(avec de l'encre et du papier ou c'est autre chose ?)

Le fingerprint est créé en même temps que la clé.

$ gpg --help | grep finger --fingerprint lister les clés et les empreintes --fingerprint [utilisateur] montrer les empreintes $ gpg --finger gaetan pub 1024D/52732D43 2001-10-31 Gaetan RYCKEBOER  Key fingerprint = F5F4 835B E444 38F5 64C5 DE4C 887D 512E 5273 2D43 uid Gaetan RYCKEBOER  sub 1024g/E8617172 2001-10-31 pub 1024D/3674000A 2001-10-31 Gaetan RYCKEBOER  Key fingerprint = 2657 ECE1 14D7 BB7B 3D36 9ED2 9FCB B804 3674 000A uid Gaetan RYCKEBOER  sub 1024g/5E416A3E 2001-10-31

On y retrouve :
– Le champ "sub" correspond à chaque fois à la partie privée de la clé ;
– le champ "pub" à la partie publique ;
– le champ "uid" à une adresse email et un nom.

Ce fingerprint, tu devra le présenter à toutes les personnes à qui tu demanderas de signer ta clé, pour qu'elles puisse s'assurer de sa validité.

Ouais... et tu disais qu'il fallait vérifier les fingerprint avant de signer une clé... Tu fais comment ?

Lorsque tu reçois un message signé, il est signé par une clé.
La mienne, c'est - comme gpg te l'indique - la clé n° 52732D43

Pour afficher les FINGERPRINTS, tu fais :

$ gpg --finger gaetan pub 1024D/52732D43 2001-10-31 Gaetan RYCKEBOER  Key fingerprint = F5F4 835B E444 38F5 64C5 DE4C 887D 512E 5273 2D43 uid Gaetan RYCKEBOER  sub 1024g/E8617172 2001-10-31 pub 1024D/3674000A 2001-10-31 Gaetan RYCKEBOER  Key fingerprint = 2657 ECE1 14D7 BB7B 3D36 9ED2 9FCB B804 3674 000A uid Gaetan RYCKEBOER  sub 1024g/5E416A3E 2001-10-31

Là, tu vois 2 clés, dont la n° 5273D43, qui a un de ses UID positionné à gaetan@virtual-net.fr, c'est la clé que j'utilise au boulot.

Tu veux signer une clé, donc tu possèdes une empreinte [1] pour la clé que tu t'apprètes à signer. Je rappelle que tu as idéalement reçu l'empreinte de visu, ou par FAX, courrier, ou un quelconque moyen qui te permette d'identifier l'expéditeur A COUP SÛR.

L'empreinte [2] est censée correspondre à la clé que tu as en ta possession. Si tel
est le cas, tu peux signer la clé.
Si ce n'est pas le cas, ou si l'ID de la clé est différent, TU NE LA SIGNE PAS, ce n'est pas celle que j'utilise, tu ne dois donc pas la certifier avec la tienne.

[1] fingerprint

[2] fingerprint. Tu suis ou quoi ?

8-Mise en conformité des mails GnuPG

Gaétan RYCKEBOER — 2002-05-14T13:00:27Z

Bon. Ca y est. Je cause par courriel à la moitié du monde, je signe tout avec gpg, mais je reçois des emails bizarres... Il paraît qu'ils sont signés, mais mutt ne sait pas le lire...

Il existe deux techniques pour écrire des mails signés ou cryptés par GnuPG. La première, officielle, consiste à rédiger un courrier en plusieurs parties et de type différent pour chaque partie. C'est du PGP-Mime.
La seconde, utilisée entre autres, par eudora, mozilla, pine... n'est plus aux normes, et consiste à ajouter la signature directement dans le corps du message, avec des balises texte.

Si tu utilises mutt (comme tu l'as dit), voici quelques filtres à rajouter dans le fichier .procmailrc de ton répertoire utilisateur et qui servent à te faciliter la vie lorsque tu reçois un courrier chiffré ou signé.

Messages encryptés et signatures :

:0 * !^Content-Type: message/ * !^Content-Type: multipart/ * !^Content-Type: application/pgp { :0 fBw * ^-----BEGIN PGP MESSAGE----- * ^-----END PGP MESSAGE----- | formail \ -i "Content-Type: application/pgp; format=text; x-action=encrypt" :0 fBw * ^-----BEGIN PGP SIGNED MESSAGE----- * ^-----BEGIN PGP SIGNATURE----- * ^-----END PGP SIGNATURE----- | formail \ -i "Content-Type: application/pgp; format=text; x-action=sign" }

Pour les clés :

:0 fBw * ^-----BEGIN PGP PUBLIC KEY BLOCK----- * ^-----END PGP PUBLIC KEY BLOCK----- | formail -i "Content-Type: application/pgp-keys; format=text;"

Ainsi, procmail récupère les clés ou les données cryptées et/ou signées que le client mail de ton interlocuteur a eu le mauvais goût d'intégrer au corps du message. Il les transmet ensuite à formail qui se charge d'ajouter le type MIME [1] correspondant. Mutt identifie alors correctement ce dernier, et le traite donc comme à l'accoutumée (déchiffrement à la volée, vérification des signatures, intégration de la clé au trousseau via Esc-k, etc.). Magique :)

Par contre, évidemment, ça ne permettra toujours pas à un utilisateur de gnus ou mozilla de lire directement les mails signés comme il faut avec mutt. Mais là... C'est au logiciel de s'adapter à la norme, pas l'inverse... Et puis l'effort est faible ;-)

[1] Multi Purpose (internet) Mail Encoding

VOIR EN LIGNE : Mutt France (article original)

7-Logiciels de mail supportant GnuPG

Gaétan RYCKEBOER — 2002-04-23T11:19:36Z

OK. Mais ton GnuPG, il marche partout ? Les gens avec qui je communique sauront-ils lire les mails que je signe, ou que je crypte ?

A priori, non... Enfin, les mails signés, a priori, devraient être lus sur tous les logiciels de messagerie. Pas forcément décodés, mais au moins lus. Le contenu est récupérable.

Enfin... partout où les logiciels de messagerie implémentent correctement la RFC 822, la référence.
S'ils n'y arrivent pas, c'est sans doute que leur logiciel n'implémente pas complètement la norme, et dans ce cas... "mauvais logiciel, changer de logiciel" ;-)

Par contre, pour crypter des emails pour ton interlocuteur, il faut qu'il ait déjà une clé GnuPG, ce qui implique qu'il soit au faît des problèmes de sécurité des emails et qu'il ait sans doute un plugin [1] sur son logiciel de messagerie [2]. Cela ne lui posera donc probablement pas de problème d'en recevoir.

D'ailleurs, voici une liste (non exhaustive) de plugins, que je me suis amusé à chercher sur Internet. Une autre liste existe, directement sur le site GPG

UNIX
a) vous êtes en console
– mutt : voir le .muttrc attaché.
– pine : pgp4pine, MagicPGP, PinePGP.
– emacs : il le fait naturellement. De toutes façons, vous êtes déjà poulpiforme, donc... Google n'a pas de secret pour vous. Un poulpe ça a plus de pattes qu'une araignée [3], non mais...
– Encrypter ou signer les mails à la volée ? Oui, avec GNU Anubis. Ah mais !
b) sous X
– Xemacs (voir plus haut).
– xfmail : GnuPG géré nativement.
– evolution : géré nativement.
– KMail : pas de solution actuellement avec GnuPG, mais un article sur la combinaison PGP/KMail.
– Mozilla (ou Netscape 6.x) : Enigmail.
– Sylpheed : gpgmpe (nécéssite une compilation) et quelques patches intéressants pour Sylpheed (dont GPG ASCII armoured).

– Rien de tout ça GnomePGP et SeaHorse peuvent fonctionner avec GnuPG.

Windows
Il faut bien sûr avoir installé GnuPG sous Windows ou PGP.
– Eudora : Un plugin plus ou moins buggué. La solution PGP (Pretty Good Privacy)fonctionne mieux, mais attention, le plugin PGP brut de fonderie n'envoie pas des courriers signés comme il faut [4].
– Outlook :
GnuPG Plugin
– Outlook Express : GPG-OE.
– Mozilla (ou Netscape 6.x) : Enigmail.

– autres : GPGRelay ou PGPSendmail permettent de créer un tunnel PGP crypté, de façon transparente pour l'utilisateur [5].

Autres
– IMP : OpenPGPWebmail.
– Solaris, ou SunOS ? Essayez privtool.

Toutes sortes d'informations peuvent être trouvées sur la page GnuPG dédiée aux frontends.

Dernier point : c'est lorsque les gens voient des choses nouvelles qu'ils s'y intéressent. Si vous prenez la décision de signer TOUS vos mails, vous provoquerez inévitablement la question "mais... c'est quoi ce fichier bizarre que tu m'envoies à chaque fois ?"
Et là, vous pouvez endosser le plus grand rôle de votre vie, le prosélyte.

Avec un peu de chance et de talent, votre interlocuteur sera convaincu. Au pire, il saura que ça existe, et que "des gens" utilisent GnuPG.

[1] module additionnel

[2] Ou alors que son logiciel gère gpg nativement

[3] Un esprit chagrin me signale qu'un poulpe n'a pas de pattes. Et que de toutes les façons, il n'a que 8 tentacules. Bon. Ben... même si le poulpe en a autant, ça fait déjà beaucoup.

[4] En fait, plusieurs plugins existent. Frédéric a le bon, pour la version Eudora 4.02 sur PC. Par contre, le mail signé est enregistré à part dans un fichier portant l'extension .ems - comme c'est le cas lorsque les signatures ne sont pas tout à fait reconnues comme il faut.
En tout état de cause, il s'agit toujours de logiciel propriétaire, donc non libre, ce qui sort du cadre de CLX, et du présent article.

[5] PGPSendmail, par exemple, crypte les mails à la volée si, il trouve une clé publique pour le destinataire sur un serveur de clés

5- Principe de base des clés, signatures mutuelles

Gaétan RYCKEBOER — 2002-04-18T13:55:56Z

chuis foncierement débile ou c'est super compliqué vot' bazar ??? Clés publiques, privés, certificats de révocation, signatures...

Woâââa. Nan, c'est vrai que ce n'est pas simple.

En fait, une clé est identifiée par un numéro, son ID.

Pour faire une clé perso, il faut une clé privée, et une
clé publique.
C'est un peu compliqué... en fait, appeler clé publique/clé privée est
un abus de langage, ou une synecdoque [1].
On devrait plutot dire partie privée de la clé, partie publique de la clé ; la clé, c'est l'ensemble des deux.

Ou plutot : « partie privée de la clé dont l'ID de la partie publique
est 1234 » lorsque l'on parle de clé privée, et
« partie publique de la clé, dont le numéro (de la partie publique) est
1234 »

Mais c'est lourd.

De ces deux parties de ta clé, la partie privée est la plus important,
c'est celle qu'il faut à tout prix "cacher" aux yeux du monde. Tu es le seul
à pouvoir l'utiliser ; c'est là-dessus que repose la sécurité du système.

La partie publique, par contre, sera envoyée aux personnes avec qui tu veux dialoguer.
Attention, la partie publique et la partie privée ont chacun un ID différent.. c'est là
que c'est difficile à comprendre. Une seule clé, mais deux parties, avec chacune un ID distinct.

Sur le serveur de clés dont on a discuté tout à l'heure, tu ne trouveras donc que la
partie publique de la clé. Et un individu lambda qui veut chiffrer un mail, le fera
avec la partie publique de ta clé.

OK ? Je continue.

Dans ta clé (ensemble privé/publique), tu trouves :
– un fingerprint (empreintes digitales de certification)
– une liste d'identifiants (nom/prénom, email, commentaires)

Chaque identifiant peut être signé par une ou plusieurs clés.

Attends, attends... comment tu fais pour signer une clé ? Enfin... un identifiant, je veux dire ?

Tout d'abord, lorsque tu signes une clé, enfin sa partie publique... zut. Le truc que tu as
en ta possession et que tu as trouvé sur le serveur de clés, tu va signer tous les identifiants
(les ensembles nom/email/commentaires) qui sont dedans.
Ainsi, si le propriétaire ajoute un identifiant à sa clé, après que tu l'ais signée, ta
signature n'apparaîtra pas sur le nouvel identifiant. Et c'est normal.
C'est comme si tu avais signé un contrat dont une clause aurait été rajoutée après.

Si qulqu'un te demande de signer sa clé, tu commences par lui demander son fingerprint [2] par un moyen réputé sûr, qui te permette de l'identifier à coup sûr.
Par exemple, en le voyant de visu, ou par le courrier (bien que l'on puisse falsifier aussi du courrier
envoyé par La Poste)

Une fois que tu l'as, tu vérifies que le fingerprint reçu est bien celui qui
correspond à la clé que tu t'apprêtes à signer.
J'insiste sur le fingerprint... il faut vraiment que tu sois SÛR à 100%
que celui que tu as reçu est bien le fingerprint correspondant à la personne
censée être propriétaire de la clé que tu vas signer.
Si quelqu'un réussit à se faire passer pour un autre à ce moment-là, ce n'est pas une seule clé
qui est "corrompue", c'est le réseau de confiance entier.
Un fingerprint lu sur une carte de visite, sur un disquette, ou dans un courrier
dont tu peux identifier précisément l'émetteur est fiable.
Un fingerprint reçu par email ne l'est pas, sauf s'il est signé par un moyen quelconque.

Vérification faite, tu signes la clé avec ta propre clé :

gpg --sign-key 1234

A partir de ce moment, tu as certifié que tu faisais confiance au type
qui t'a demandé de signer sa clé, en disait "j'ai vérifié, la clé
n°1234 est bien celle de M. Toto TRUC".

Si M. Toto TRUC signe une clé, et que tu vois des données certifiées avec cette troisième clé, tu imagines que M. Toto TRUC a fait pareil pour signer la clé.
Tu peux donc faire confiance aux donnés certifiées par cette troisème clé, à condition que tu sois sûr que M. Toto est aussi soigneux que toi dans la vérification du fingerprint.
– GnuPG fonctionne sur un réseau de confiance.
– Il NE FAUT PAS signer une clé comme ça, c'est très très important de s'assurer que tu signes la bonne clé.
– IL FAUT TOUJOURS vérifier le fingerprint de la clé avant de la signer.
– IL FAUT VRAIMENT ETRE SUR que c'est le bon fingerprint qui te sert à vérifier la clé.
– Si tu n'es pas sûr que ce n'est pas le fingerprint de la clé, tu ne la signes pas.
– Et enfin, le fingerprint doit toujours correspondre à la clé.

Compris ?

Imaginons que moi, Gaétan RYCKEBOER, je vous demande de signer ma clé.
Le feriez vous ?

NON !!!

Je n'ai jamais donné physiquement mon fingerprint à qui que ce soit, et
la réception d'un fingerprint par email est non sûre, sauf si les
données sont signées par une clé que vous avez vous-même signé.

C'est le bordel, hein ?

Et c'est pour éviter de faire "entrer" une personne qui falsifie sa
clé, en se faisant passer pour quelqu'un d'autre, lors des opérations de
signatures mutuelles qui se font de temps en temps, comme parfois
aux mardi-linux, pour faire grandir son réseau de confiance.

[1] mouarf..

[2] les "empreintes digitales" de la clé.
Un CRC, en quelque sorte.

4- Réseau de confiance

Gaétan RYCKEBOER — 2002-04-16T10:53:31Z

Que signifie le message Attention, cette clé n'est pas certifiée avec une signature de confiance ! ?

GnuPG repose sur le principe d'un réseau de confiance.

Lorsque tu es sûr qu'une clé donnée appartient bien à la personne qui prétend la détenir (c'est à dire si tu es sûr que c'est bien toto, dont l'email est
toto@chezmoi.net qui a généré la clé dont l'ID est 123FDC54), tu peux la signer avec ta propre clé.

Si quelqu'un - qui sait que ta clé est bien valide et que c'est bien la tienne - reçoit des données signées avec la clé de toto, il saura qu'il pourra faire confiance à l'émetteur des données. En effet, tu as signé la clé de toto avec ta clé. Tu as donc fait confiance à la clé de toto. Donc, les données de toto sont dignes de confiance. Or toto a signé la clé de l'émetteur avec une clé que tu as signée, donc l'émetteur et ses données sont dignes de confiance (compliqué, non ?).

Ainsi, par échange de signatures mutuelles, tu fais grossir ton réseau de confiance, et donc le nombre de clés en qui tu peux avoir toute confiance.

Le message que tu indiques dans ta question signifie que le mail que tu as reçu est signé, mais que la clé utilisée n'est pas signée. Tu
dois donc prendre l'information contenu dans l'email avec des pincettes. Ou changer manuellement la confiance que tu apportes à cette clé avec :

$ gpg --edit-key 123FDC54 pub 1024D/123FDC54 créée: 2002-04-05 expire: never confiance: -/q sub 1024g/DF6B8891 créée: 2002-04-05 expire: never (1). toto (toto, cle perso)  Commande> trust ... Commande> quit

C'est d'ailleurs avec cette même commande gpg --edit-key que tu peux signer une clé, après t'être assuré que c'est la bonne clé ; pour ensuite l'envoyer sur les serveurs de clés, ou la renvoyer à l'émetteur.

3- Révocation d'une clé

Gaétan RYCKEBOER — 2002-04-16T10:44:22Z

Une passphrase ? Une clé secrÚte ? Et si je les perds ?

Il faut TOUJOURS avoir à disposition un certificat de révocation, au cas où, ta clé étant diffusée, tu paumes le mot de passe, ou si la sécurité de la clé se trouve compromise.

En fait, la bonne méthode, consiste à créer le certificat en même temps que la clé.

Le bon process devient donc :

$ gpg --gen-key $ gpg --gen-revoke toto@chezmoi.com > ~/.gnupg/revoke.macle $ gpg --send-key 123FDC54

Lorsque tu crées ton certificat, GnuPG te demande si c'est :
– 1 clé compromise
– 2 clé remplacée
– 3 clé qui n'est plus utilisée

Que choisir ? Il faut bien comprendre que le certifcat de révocation reste un bout de papier tant qu'il n'est pas envoyé. Tu pourras donc en créer plusieurs sans que cela entraîne de difficultés pour tes correspondants. Ta clé sera toujours utilisable.

Le certificat que tu souhaites créer, d'après la question posée, c'est le certificat de secours. C'est à dire celui que tu vas utiliser si ta clé a été compromise, ou si tu as perdu ton mot de pase. Ce qui revient au même. Pour le certificat, s'entend.

Si tu décides de ne plus utiliser ta clé GnuPG, tu pourras toujours fabriquer un autre certificat "clé remplacée" ou "clé qui est plus utilisée".

Bien. Maintenant, nous sommes dans le cas où tu as ton certificat et que ta clé a été volée, exposée, ou que tu as oublié ton mot de passe. Il te faut envoyer le
certificat aux serveurs de clé, par exemple via l'url WEB de l'un des serveurs.

Dans un ou deux jours, tout un chacun pourra télécharger la clé, par la méthode habituelle, mais elle sera marquée "révoquée". Attention, elle restera néanmoins
toujours utilisable. En revanche, bien évidemment, GnuPG avertira les utilisateurs que la clé ne doit plus être utilisée.

Pour être sûr que la clé ne sera plus utilisée, il faut envoyer un mail à tous les correpondants qui utilisent cette clé pour déchiffrer tes emails. Ils doivent être informés que ta clé est révoquée, et qu'ils ne doivent plus lui faire confiance.

C'est pas dangereux de laisser trainer son certificat de révocation ?

Le seul risque que tu coures c'est que quelqu'un l'utilise. Et que ta clé soit marquée comme révoquée, donc qu'elle soit réputée non fiable. [1]

Mais c'est mieux de changer de clé, que de ne pas être en mesure de signaler que ta clé est corrompue, non ?

[1] par
opposition à réputé fiable. En crypto la fiabilité est relative. On dit donc d'une méthode de sécurisation qu'elle est "réputée fiable" dans la mesure où
les moyens à mettre en oeuvre pour "casser" l'algorithme, ou pour lire les informations cryptés demandent trop de temps ou de ressources informatiques pour un individu lambda. Ou un
organisme lambda.

2- Création d'une clé

Gaétan RYCKEBOER — 2002-04-16T10:44:06Z

OK, je sais lire vos mails. Je veux faire pareil. Comment créer sa clé ?

$ gpg --gen-key

gpg va poser 3 questions :
– le nom
– l'email
– les commentaires (optionnels).

Ces trois paramètres forment l'identifiant. Une même clé pourra avoir plusieurs identifiants, crées par la suite. Par exemple, si tu as de nombreux emails, tu pourras avoir l'identifiant 1 pour l'email n°1, l'identifiant 2 pour l'email n°2, et ainsi de suite. Et tous ces identifiants seront utilisé par la même clé.

Attention, dans le cas où tu utiliserais GnuPG à la fois au boulot et pour des affaires "privées", il vaut mieux avoir deux clés. C'est plus facile de
révoquer une clé pour un ou deux identifiants, que la clé qui contient TOUS tes identifiants, professionnels et personnels. Ensuite, c'est moins embêtant
pour les utilisateurs de tes clés, chaque identifiant correspond à une ligne de perdue sur l'affichage des données signées. Cela peut être vraiment
pénible, dans le cas d'échange d'emails, par exemple.

1- Serveurs de clés

Gaétan RYCKEBOER — 2002-04-16T10:43:32Z

C'est sympa de signer vos emails avec GnuPG, mais
pourriez-vous communiquer aussi vos clés publiques afin que cela serve à quelque chose ?

Pour cela, repérez l'option keyserver dans le fichier /.gnupg/options :

# GnuPG can import a key from a HKP keyerver if one is missing # for sercain operations. Is you set this option to a keyserver # you will be asked in such a case whether GnuPG should try to # import the key from that server (server do syncronize with each # others and DNS Round-Robin may give you a random server each time). # Use "host -l pgp.net | grep www" to figure out a keyserver. #keyserver wwwkeys.eu.pgp.net keyserver pgp.mit.edu #keyserver certserver.pgp.com

Une fois cette partie de GnuPG paramétrée, les logiciels de messagerie l'utilisant vont être capables d'aller chercher les clés directement sur le serveur de clés connecté à Internet (ici pgp.mit.edu).

Pour information, ces serveurs s'échangent leurs clés (ils synchronisent leur contenu régulièrement). Il n'est donc pas nécessaire de se connecter sur tous les serveurs. Un seul serveur suffit.

Par exemple, mutt le fait très bien tout seul, dès qu'un mail signé arrive, la clé associée est automatiquement importée dans ton trousseau.

Si tu as un mailer qui ne "communique" pas très bien avec GnuPG, voici la manipulation pour récupérer la clé :

$ gpg --recv-key IDKEY

L'ID de ma clé perso, par exemple, celle que j'utilise quand je ne suis pas au turbin, c'est 3674000A. La commande devient donc :

$ gpg --recv-key 3674000A

Pour envoyer ta clé :

$ gpg --send-key IDKEY

Là encore, grâce aux connections entre les serveurs de clés, les informations déposées chez l'un finissent par être connues de tous les serveurs.

Pour info, voici ce que donne un mail signé, décodé avec mutt :

Date: 13 Apr 2002 10:46:14 +0200 From: Toto  Subject: Clefs GPG To: asr à mail.dotcom.fr X-Mailer: Evolution/0.13 (Preview Release) [-- La sortie PGP suit (heure courante : Mon Apr 15 11:03:19 2002) --] gpg: Signature faite sam 13 avr 2002 10:46:13 CEST avec une clé DSA ID 123FDC54 gpg: Bonne signature de "Toto (toto, cle perso) " gpg: ATTENTION: Cette clé n'est pas certifiée avec une signature de confiance ! gpg: Rien ne dit que la signature appartient à son propriétaire. gpg: Empreinte: 913E 6ACE B558 0A1D 997F 76D3 4DD4 231F 4F36 0C0C [-- Fin de sortie PGP --] [-- Les données suivantes sont signées --]