Page suivante
Page précédente
Table des matières
5. Les réseaux de confiance (« web of trust »)
Maintenant que l’on a parlé de la partie technique concernant l’utilisation au
jour le jour de GnuPG, il reste un problème majeur : l’authenticité des clés.
5.1 Donnez-moi vos empreintes !
Imaginons qu’une clé que l’on vient de télécharger à partir d’un serveur de
clés ne soit pas réellement la clé de la personne à laquelle on pense. Si on
envoie un message chiffré en utilisant cette clé, une tierce personne aura
accès à ce message, et pourra réémettre le message avec la clé réelle du
destinataire, ce qui fait qu’une personne aura lu le message sans qu’aucune
des deux extrémités ne soit au courant. De même, si un message vient d’une
personne dont on ne possède pas la clé avec certitude, le fait de la
télécharger à partir d’un serveur ne garantit pas son authenticité
(souvenez-vous comme il a été simple de crééer une clé et de la déposer sur le
serveur de clés, un peu plus haut dans ce document …). Par exemple, de
nombreux plaisantins se sont amusés à créer et enregistrer de fausses clés sur
des serveurs, et notamment on peut trouver plusieurs clés appartenant
soit-disant à Philip Zimmermann, créateur de PGP, mais qui sont en fait autant
de contrefaçons.
Il va falloir authentifier toutes ces clés. Pour l’instant, les différentes
clés qu’on a pu récupérer par l’intermédiaire des serveurs de clés sont
inutilisables car non sûres (un message dans mutt par exemple nous le
rappelle).
Nous allons donc utiliser des mécanismes de signature des clés et de
contre-signature.
Dans un premier temps, il est possible de générer une empreinte
(fingerprint) des différentes clés de son trousseau, et en particulier la
sienne :
$ gpg --fingerprint /home/leto/.gnupg/pubring.gpg ----------------------------- pub 1024D/A0BBED3B 2001-07-12 Loïc Bernable <[email protected]> Key fingerprint = 5BF7 988C 9367 2E86 DE52 F141 5F5F 34EE A0BB ED3B uid Loïc Bernable <[email protected]> sub 1024g/52AF5615 2001-07-12 pub 1024D/CE63A2E7 2000-02-23 Benoit <[email protected]> Key fingerprint = A6CC 7BC2 6DBC 9B34 AA10 07E5 E0D1 AB7E CE63 A2E7 sub 2048g/B5A97C83 2000-02-23
On peut alors noter sur un support facilement transportable (typiquement, une
carte de visite) le fingerprint correspondant à sa propre clé publique.
Lorsqu’on va rencontrer une personne avec qui on sera susceptible d’avoir des
échanges utilisant GnuPG ou PGP, on s’échange ses fingerprint mutuels, dans
notre cas en s’échangeant les cartes de visite. Pour que l’échange se fasse
dans les règles de l’art, l’échange doit comporter une vérification de
l’identité réelle de la personne grâce aux papiers d’identité.
Une fois qu’on a récupéré le fingerprint de la personne, on peut télécharger
la clé publique à partir d’un serveur (petite astuce : les 8 derniers
caractères du fingerprint correspondent à l’ID de la clé), et relancer la
commande gpg –fingerprint pour afficher le fingerprint correspondant à
la clé que l’on vient de télécharger. Il ne reste plus qu’à comparer le
fingerprint obtenu et celui marqué sur la carte de visite, et si les deux
concordent, alors on est sûr à 100% que la clé publique qu’on a maintenant
dans notre trousseau correspond à la personne avec qui on a fait
physiquement l’échange des cartes et la vérification des papiers
d’identité. En bref, on a la bonne clé publique.
Notons qu’à l’occasion de rencontres (expositions, meetings, conférences) il
est possible de rencontrer un grand nombre de personnes, et ainsi d’échanger
un grand nombre de fingerprints. Il existe aussi des Keysigning parties
où le but des participants est de tisser une toile de signatures afin
d’augmenter la taille de leur trousseau de clés (voir le GnuPG Keysigning
Party HOWTO,
http://www.cryptnet.net/fdp/crypto/gpg-party.html ).
5.2 Je te signe, tu me signes …
On pourrait s’arrêter là, mais cela limiterait fortement les possibilités
d’action (on ne pourrait utiliser GnuPG qu’avec des personnes qu’on aurait
rencontré physiquement). C’est là qu’entrent en jeu deux mécanismes : les
contre-signatures et les réseaux de confiance.
On va donc contre-signer la clé publique que l’on vient de télécharger. La clé
publique de notre trousseau va donc être légèrement modifiée car on va y
ajouter un petit morceau de signature propre à nous, généré par notre clé
secrète, attestant qu’on est d’accord sur le fait que cette clé publique
appartient bien à son propriétaire.
Il suffit d’utiliser la commande
$ gpg --sign-key id_de_la_personne
Si la personne possède plusieurs UIDs, il est possible de les signer tous ou
de choisir ceux qu’on veux signer.
ATTENTION ! Afin de savoir à quoi s’en tenir, il ne faut *jamais*
signer une clé sur la bonne foi d’une tierce personne ou si une personne a
envoyé son fingerprint par mail, etc. La signature d’une clé doit se faire
*uniquement* après vérification en réél de la personne, avec transfert
physique du fingerprint.
On vient donc de signer (contre-signer en fait) la clé publique de notre
interlocuteur. On va maintenant dire au reste du monde qu’on a signé la clé de
l’autre personne. On peut soit envoyer à son propriétaire la clé signée : on
exporte la clé et on l’envoie :
gpg --export --armor id_de_la_personne
ou on l’envoie directement sur un serveur de clés :
gpg --keyserver pgp.mit.edu --send-key id_de_la_personne
L’usage fait que généralement, on fait les deux : on envoie la clé à un
serveur de clés et on prévient l’autre qu’on a signé la clé. Lorsqu’on envoie
la clé au serveur de clés, ou lorsqu’on réimporte une clé qui a été signée
depuis, cette dernière n’est pas écrasée, mais les signatures sont extraites
et ajoutées le cas échéant. Les clés qu’on a récupérées ont donc peut-être
été signées par d’autres personnes. Pour le voir, il suffit de taper la
commande :
$ gpg --list-sigs /home/leto/.gnupg/pubring.gpg ----------------------------- pub 1024D/A0BBED3B 2001-07-12 Loïc Bernable <[email protected]> sig A0BBED3B 2001-07-18 Loïc Bernable <[email protected]> uid Loïc Bernable <[email protected]> sig A0BBED3B 2001-07-18 Loïc Bernable <[email protected]> sub 1024g/52AF5615 2001-07-12 sig A0BBED3B 2001-07-12 Loïc Bernable <[email protected]> pub 1024D/CE63A2E7 2000-02-23 Benoit <[email protected]> sig 5ED61FDA 2000-06-06 [User id not found] sig CE63A2E7 2000-02-23 Benoit <[email protected]> sig B4C5FE7F 2001-07-18 [User id not found] sub 2048g/B5A97C83 2000-02-23 sig CE63A2E7 2000-02-23 Benoit <[email protected]>
On remarque qu’on a sa propre clé auto-signée, et que la clé qu’on a récupérée
a été signée par plusieurs personnes qu’on ne connait pas (on n’a pas leur clé
publique dans notre trousseau). Si on importe par exemple la clé d’UID
0xB4C5FE7F, on aurait la réponse suivante :
$ gpg --list-sigs benoit pub 1024D/CE63A2E7 2000-02-23 Benoit <[email protected]> sig 5ED61FDA 2000-06-06 [User id not found] sig CE63A2E7 2000-02-23 Benoit <[email protected]> sig B4C5FE7F 2001-07-18 Olivier Berger <[email protected]> sub 2048g/B5A97C83 2000-02-23 sig CE63A2E7 2000-02-23 Benoit <[email protected]>
On peut donc savoir qui sont les personnes qui ont signé les clés de notre
trousseau. Mais avec l’option –list-sigs, on sait juste que la clé a été
signée par un certain nombre de personnes, sans le vérifier. On peut demander
à GnuPG de vérifier les différentes signatures qu’il possède de chaque clé
avec les clés qu’il a dans son trousseau :
$ gpg --check-sigs benoit pub 1024D/CE63A2E7 2000-02-23 Benoit <[email protected]> sig? 5ED61FDA 2000-06-06 sig! CE63A2E7 2000-02-23 Benoit <[email protected]> sig! B4C5FE7F 2001-07-18 Olivier Berger <[email protected]> sub 2048g/B5A97C83 2000-02-23 sig! CE63A2E7 2000-02-23 Benoit <[email protected]>
Les ? correspondant à des signatures qui n’ont pas été vérifiées (on ne
possède pas la clé publique pour vérifier) , alors que les ! indiquent
que la signature correspond à la clé publique que l’on a sur notre trousseau.
Il peut donc être intéressant de récupérer fréquemment les nouvelles
signatures des clés qui font partie de notre trousseau. Une manière simple est
de passer par un script à glisser dans son crontab, une fois par jour. Voici
un exemple de tel script (merci à O. Berger) :
#!/bin/sh echo "" echo "Mise à jour des clés GnuPG :" echo "" for i in $(/usr/bin/gpg --list-keys | grep '^pub' | cut -c 12-19); do /usr/bin/gpg --keyserver pgp.mit.edu --recv-key $i; done
Bon, on peut se dire, c’est bien joli tout ça, mais à quoi ça sert ? Dans un
premier temps, ce processus tisse un réseau de confiance autour de soi, avec
les personnes avec qui on se fait des échanges de clés.
Puis, on est amené à récupérer un jour la clé d’une personne, appelons-la
Charlie. On ne connait pas personnellement Charlie, on ne l’a jamais vu, mais
Charlie connaît Bernard. Or, nous (Alphonse), on connaît bien Bernard, c’est
un bon ami, et on a confiance en lui. On a échangé nos clés tous les deux, et
B et C en ont fait de même.
Vu qu’on a confiance en B, on peut se dire qu’il a bien fait les choses et
qu’il a signé la clé de C en suivant le protocole requis (échange physique des
fingerprint, contrôle de l’identité). On peut alors se dire qu’il y a 99% de
chances pour que la clé de C soit la bonne (mais on n’est jamais sûr, c’est
pourquoi, dans un cas pareil, il ne faut *jamais* signer une clé qu’on a
contrôlée par ce moyen).
Maintenant, imaginons que B ne soit pas quelqu’un que l’on connaît bien, cela
peut être une personne avec qui on a fait un échange de fingerprints la seule
fois où on l’a rencontré, mais qu’on ne connaît pas pour autant : on ne peut
pas être sûr que la vérification de la clé de C s’est faite dans de bonnes
conditions, donc on ne va pas faire autant confiance à la clé publique de C
(on va dire, 40% par exemple).
Afin de mettre cette confiance en forme, il est possible d’attribuer plusieurs
niveaux de confiance à un utilisateur. Pour se faire il faut éditer la clé et
utiliser la commande trust :
$ gpg --edit-key benoit [...] Command> trust pub 1024D/CE63A2E7 created: 2000-02-23 expires: never trust: -/q sub 2048g/B5A97C83 created: 2000-02-23 expires: never (1). Benoit <[email protected]> Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources...)? 1 = Don't know 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully s = please show me more information m = back to the main menu Your decision?
Tout ce qu’il reste à faire, c’est indiquer le niveau de confiance pour cet
utilisateur. Facile, non ?
5.3 Et ils sont où mes copains dans tout ça ?
Une possibilité, si on est curieux, est de mettre sous la forme d’un graphique
l’ensemble des relations existantes entre les différentes clés du trousseau.
Une très bonne page pour partir sur ce sujet est le site des clés des
développeurs Debian (
http://www.chaosreigns.com/code/sig2dot/ ).
Parmi les meilleurs rendus, on note ceux qui utilisent le script
sig2dot.pl, qu’on utilise par la suite dot ou neato. Notons que
dans sa version 0.12, sig2dot.pl génère une erreur fatale lorsqu’on a une
clé du keyring qui n’est signée par aucune de celles présentes. Il suffit de
modifier quelques lignes, pour en fait enlever les couleurs :
# $red = $sigcount{$id} / $maxsigcount; # $green = .25; # $green = $signedbycount{$id} / $sigcount{$id} / $maxratio * .75; # $blue = $signedbycount{$id} / $maxsignedbycount; ### no color ### $red = .75; $green = .75; $blue = .75; ### end ###
Il ne reste plus qu’à suivre l’évolution des interconnexions au fur et à
mesure que le trousseau s’aggrandit …