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 <leto@parinux.org>
     Key fingerprint = 5BF7 988C 9367 2E86 DE52  F141 5F5F 34EE A0BB ED3B
uid                            Loïc Bernable <leto@vilya.org>
sub  1024g/52AF5615 2001-07-12

pub  1024D/CE63A2E7 2000-02-23 Benoit <benoit@parinux.org>
     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 <leto@parinux.org>
sig        A0BBED3B 2001-07-18  Loïc Bernable <leto@parinux.org>
uid                            Loïc Bernable <leto@vilya.org>
sig        A0BBED3B 2001-07-18  Loïc Bernable <leto@parinux.org>
sub  1024g/52AF5615 2001-07-12
sig        A0BBED3B 2001-07-12  Loïc Bernable <leto@parinux.org>

pub  1024D/CE63A2E7 2000-02-23 Benoit <benoit@parinux.org>
sig        5ED61FDA 2000-06-06  [User id not found]
sig        CE63A2E7 2000-02-23  Benoit <benoit@parinux.org>
sig        B4C5FE7F 2001-07-18  [User id not found]
sub  2048g/B5A97C83 2000-02-23
sig        CE63A2E7 2000-02-23  Benoit <benoit@parinux.org>

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 <benoit@parinux.org>
sig        5ED61FDA 2000-06-06  [User id not found]
sig        CE63A2E7 2000-02-23  Benoit <benoit@parinux.org>
sig        B4C5FE7F 2001-07-18  Olivier Berger <oberger@april.org>
sub  2048g/B5A97C83 2000-02-23
sig        CE63A2E7 2000-02-23  Benoit <benoit@parinux.org>

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 <benoit@parinux.org>
sig?       5ED61FDA 2000-06-06  
sig!       CE63A2E7 2000-02-23  Benoit <benoit@parinux.org>
sig!       B4C5FE7F 2001-07-18  Olivier Berger <oberger@april.org>
sub  2048g/B5A97C83 2000-02-23
sig!       CE63A2E7 2000-02-23  Benoit <benoit@parinux.org>

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 <benoit@parinux.org>

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 ...


Page suivante Page précédente Table des matières