Introduction à GnuPG
Beaucoup de personnes ont récemment entendu parler de problèmes de confidentialité liés à Internet. Les échanges d'information ne sont pas sûrs. En particulier, le courrier électronique (email) peut être lu par des tierces personnes, et on n'est jamais sûr de la provenance réelle d'un email.
Afin d'améliorer ces conditions, il est possible d'utiliser des procédés cryptographiques. En particulier, il existe des méthodes à clés asymétriques, permettant soit de signer (authentifier) un texte, soit de le chiffrer (le rendre illisible au monde entier).
GnuPG est une des implémentations utilisant un tel système à clés asymétriques, et c'est le logiciel que nous utiliserons dans cette introduction. Il a l'énorme avantage, en comparaison avec son équivalent propriétaire PGP, d'être un logiciel libre et de reposer sur la norme OpenPGP. De plus, le créateur de PGP, Philip Zimmermann, a rejoint récemment le groupe OpenPGP et incite à utiliser des outils libres.
Cette documentation va présenter l'utilisation de GnuPG, ainsi que toute la philosophie qui tourne autour du système de chiffrement à clé publique.
Installation et manipulations initiales
1 Au commencement...
Avant tout, il est indispensable de récupérer, si cela n'est pas déjà fait, une version de GnuPG compatible avec votre système (compilation des sources, paquetages RPM, DEB, etc.) et de l'installer en suivant le processus habituel. Pour ce faire, lisez la documentation fournie sur le site de GnuPG (http://www.gnupg.org/).
Pour les utilisateurs de Debian, il suffit de taper apt-get install gnupg en tant que root.
Une fois cette installation faite, il faut créer une clé qui va nous suivre tout au long de ce processus. Cette clé doit être pérenne si vous voulez l'utiliser à long terme, donc il faut la créer avec soin.
La commande magique pour ce faire est :
gpg --gen-key
Le cas échéant, il va afficher la ligne :
gpg: you have to start GnuPG again, so it can read the new options file
Dans ce cas, il suffit de taper une nouvelle fois :
gpg --gen-key
Plusieurs questions sont posées. Il est recommandé de prendre les valeurs par défaut, à moins de savoir exactement ce que vous faites.
- Le real name et l'email address sont le nom et l'adresse email qui seront associés à la clé, et qui apparaîtront dans les annuaires et lorsque les autres personnes récupéreront notre clé : il est donc recommandé d'y mettre des informations valides, qui pourront servir à nous différencier.
- L'adresse email sera utilisée dans les logiciels de messagerie ; elle doit donc être celle avec laquelle on veut signer, chiffrer et déchiffrer des messages.
- Enfin, la passphrase est une sorte de mot de passe. Elle doit être complexe, pas trop courte, et difficilement trouvable. Elle sera demandée à chaque processus de signature ou de chiffrement. Un bon mot de passe mélangera des lettres, des chiffres et des symboles non alpha-numériques, des majuscules et des minuscules, et ne devra pas être trop court. Un bon mot passe serait par exemple Epg(3£9mVfAjpD !
Le programme va peut-être afficher un message disant qu'il n'a pas assez de nombres aléatoires en réserve. Afin de générer de l'entropie dans le système, il suffit d'ouvrir un autre terminal sur la machine et de lancer une commande gourmande en CPU (par exemple, find / -name toto).
À la fin, un message doit nous indiquer que les clés publique et secrète ont été créées.
2 OK, j'ai tapé ces commandes. Mais qu'est-ce qui s'est passé réellement ?
Nous avons généré deux clés. L'une d'elle est la clé publique, que l'on va pouvoir donner à tout le monde. L'autre est la clé secrète, qu'on doit absolument être le seul à conserver. Ces clés sont enregistrées dans le répertoire par défaut, qui est le répertoire .gnupg dans le répertoire par défaut de l'utilisateur (cd ~/.gnupg/). Lorsqu'on regarde à l'intérieur de ce répertoire, on remarque en effet qu'il y a en particulier deux fichiers, pubring et secring.
Les clés publique et secrète sont étroitement liées. L'une sert à défaire ce que l'autre a fait :
- Lorsqu'on signe un message, on chiffre un résumé (hash) avec la clé secrète, et n'importe qui avec la clé publique peut déchiffrer ce résumé pour vérifier s'il correspond bien au message. Vu que personne ne doit connaître la clé secrète, si le message est valide à la fin, c'est qu'il a été signé par la bonne personne.
- Lorsqu'on chiffre un message, on utilise la clé publique, et seul le propriétaire de la clé secrète pourra appliquer la formule pour déchiffrer le message.
Pour de plus amples informations concernant les algorithmes de chiffrement, visitez le lien http://laurent.flaum.free.fr/pgpintrofr.htm.
On se rend compte que la clé secrète est une des clés de voûte du système. Si quelqu'un d'autre a accès à notre clé secrète, il pourra envoyer des messages en se faisant passer pour nous, ou bien il pourra lire des messages chiffrés à notre intention. C'est à ce moment qu'intervient le concept de passphrase : pour améliorer encore plus la sécurité, les programmes demanderont la passphrase pour pouvoir utiliser la clé secrète (techniquement, la clé secrète est chiffrée avec la passphrase). Ainsi, en plus de la clé secrète, il faut connaître la passphrase pour pouvoir utiliser les fonctionnalités de GnuPG. Mais cela n'empêche pas de faire extrêmement attention à sa clé secrète, en particulier si on est sur un ordinateur partagé par de nombreux utilisateurs.
3 Certificats de révocation
Avant d'aller plus loin, il est préférable de créer des certificats de révocation. En effet, il se peut, pour x raisons, que notre clé ne soit plus sûre, perdue, ou tout simplement périmée. Afin de pouvoir dire au reste du monde que cette clé est périmée, on peut utiliser un certificat qu'on aura créé auparavant (quand on n'avait pas encore perdu la clé par exemple) et que l'on publiera, afin que les personnes soient au courant.
Pour ce faire, la commande suivante suffit :
gpg --gen-revoke mon_id
mon_id, comme on le retrouvera par la suite, est une chaîne de caractères propre à une clé du trousseau. Typiquement, cela peut être le nom, ou l'ID de la clé (voir plus loin), ou encore l'adresse email.
Il est conseillé de générer un certificat pour les trois types de révocation, afin d'être prêt dans tous les cas de figure. Une fois ces certificats générés, il faut les garder dans plusieurs endroits sûrs où on est certain que personne n'y aura accès (il ne faut pas que n'importe qui puisse révoquer notre clé...).
Une fois les clés et les certificats créés, l'initialisation du processus est faite. On peut se mettre à l'utiliser dans la vie de tous les jours...
Utilisation
Dans un premier temps, nous allons voir ensemble une série de commandes utiles à taper dans un terminal, puis nous verrons qu'il est possible de coupler les commandes de GnuPG avec des logiciels indépendants.
Dans tous les cas, en guise d'aide-mémoire, un recours à gpg --help ou à man gpg ne pourra qu'être conseillé...
1 Bien gérer son trousseau
Tout d'abord, nous venons de créer notre clé, mais nous allons voir qu'il est possible d'importer les clés publiques d'autres personnes dans notre trousseau de clés publiques (pubring). Afin de lister les clés qui sont dans notre keyring (porte-clés), il suffit de taper la simple commande :
$ gpg --list-keys
/home/leto/.gnupg/pubring.gpg
-----------------------------
pub 1024D/A0BBED3B 2001-07-12 Loïc Bernable <leto@vilya.org>
sub 1024g/52AF5615 2001-07-12
On remarque que notre propre clé publique est déjà dans le trousseau, et qu'elle est elle-même séparée en deux parties : la première pour valider les signatures que l'on émet, et la deuxième pour que d'autres personnes puissent nous chiffrer des messages (que l'on déchiffrera donc avec notre clé secrète). On peut aussi noter l'ID de notre clé, qui référence cette clé de manière unique : il est situé sur la première ligne, après le premier '/'. Ici, l'ID de notre clé est 0xA0BBED3B.
Si on le désire, il est possible d'ajouter une adresse email à notre clé. On va éditer notre clé et ajouter un uid :
$ gpg --edit-key leto
[...]
pub 1024D/B844D5E8 created: 2001-07-12 expires: never trust: -/u
sub 1024g/63CB897E created: 2001-07-12 expires: never
(1). Loïc Bernable <leto@vilya.org>
Command>
À ce stade, il est possible de taper la commande help pour avoir la liste des sous-commandes disponibles.
Command> adduid
Grâce à cette commande, on peut ajouter un uid de la même façon qu'on avait créé l'utilisateur initial. On remarque dès maintenant l'appel à la passphrase pour autoriser la modification.
Command> save
Command> quit
Après les changements sauvés, on remarque qu'une nouvelle entrée est apparue dans notre trousseau (l'ordre des adresses email importe peu) :
$ gpg --list-keys
/home/leto/.gnupg/pubring.gpg
-----------------------------
pub 1024D/A0BBED3B 2001-07-12 Loïc Bernable <leto@parinux.org>
uid Loïc Bernable <leto@vilya.org>
sub 1024g/52AF5615 2001-07-12
On pourra maintenant signer et se faire envoyer des mails chiffrés en utilisant indifféremment l'une ou l'autre de ces adresses email.
Maintenant que notre clé publique est complète, on peut la diffuser. L'usage veut que les clés publiques soient envoyées sur des serveurs de clés qui, eux-mêmes, communiquent entre eux. Ainsi, lorsqu'on reçoit un message signé d'une personne dont on n'a pas la clé dans notre trousseau, il est possible d'aller chercher la clé publique sur un serveur de clés afin de vérifier l'authenticité du message. De la même façon, si on veut envoyer un message chiffré à une personne, on peut récupérer sa clé publique afin de l'utiliser pour chiffrer le message.
ATTENTION ! Cette méthode n'est pas sûre. Avant de faire confiance à une clé récupérée de cette manière, bien lire la partie 4 sur les réseaux de confiance.
Il existe plusieurs serveurs de clés usuels. Citons par exemple les serveurs pgp.mit.edu, www.keyserver.net, wwwkeys.pgp.net, wwwkeys.us.pgp.net, wwwkeys.uk.pgp.net, etc. (La commande host -l pgp.net | grep wwwkeys donne une liste non exhaustive de serveurs de clés.)
Envoyons notre clé sur le serveur pgp.mit.edu par exemple :
$ gpg --keyserver pgp.mit.edu --send-key 0xA0BBED3B
gpg: success sending to `pgp.mit.edu' (status=200)
Notre clé est donc maintenant disponible sur ce serveur, et par la suite, elle sera normalement répliquée sur les autres serveurs de clés.
Maintenant, nous souhaitons ajouter un ami à notre trousseau. Une recherche rapide sur le site Web de pgp.mit.edu (par exemple) nous donne :
pub 1024/CE63A2E7 2000/02/23 Benoit <benoit@parinux.org>
Il suffit donc de taper la commande suivante afin d'importer la clé publique du serveur de clés vers notre trousseau :
$ gpg --keyserver pgp.mit.edu --recv-key 0xCE63A2E7
gpg: requesting key CE63A2E7 from pgp.mit.edu ...
gpg: key CE63A2E7: public key imported
gpg: Total number processed: 1
gpg: imported: 1
Maintenant, lorsqu'on listera les clés de notre trousseau, on aura une clé supplémentaire :
$ gpg --list-keys
/home/leto/.gnupg/pubring.gpg
-----------------------------
pub 1024D/A0BBED3B 2001-07-12 Loïc Bernable <leto@parinux.org>
uid Loïc Bernable <leto@vilya.org>
sub 1024g/52AF5615 2001-07-12
pub 1024D/CE63A2E7 2000-02-23 Benoit <benoit@parinux.org>
sub 2048g/B5A97C83 2000-02-23
4.2 Bon, c'est bien joli d'avoir des clés, mais quand et comment puis-je les utiliser ?
On peut séparer leur utilisation en deux cas distincts : l'utilisation de manière brute ou l'utilisation automatisée au sein d'un programme.
Commençons par cette dernière. Certains logiciels de messagerie comme mutt, pine, ou encore elm disposent de fonctionnalités pour utiliser GnuPG pour toutes les fonctions de cryptographie.
Prenons l'exemple de mutt. En règle générale, mutt est livré avec un ficher d'exemples appelé gpg.rc, et qu'il suffit de sourcer dans le .muttrc (ajouter la ligne source ~/.mutt/gpg.rc dans le .muttrc en adaptant le chemin où trouver le fichier gpg.rc).
Désormais, lorsqu'un mail est écrit, et prêt à envoyer (menu d'envoi), une simple pression de la touche p affiche un menu de cryptographie, permettant de signer et/ou chiffrer un message. De la même manière, lorsqu'un mail signé arrive, il est automatiquement vérifié en fonction des clés présentes dans le trousseau.
Si la clé correspondante n'existe pas dans le trousseau, un message l'indique au début du corps du message. On peut alors forcer le rapatriement automatique de la clé publique correspondant à un mail signé en modifiant les commandes dans le fichier gpg.rc (il suffit d'ajouter l'option --keyserver pgp.mit.edu ou --keyserver wwwkeys.pgp.net par exemple après les commandes commençant par gpg). On peut aussi lui spécifier d'aller vérifier les signatures mais sans garder les clés publiques dans le trousseau si elles n'étaient pas présentes (option --no-auto-key-retrieve).
Pour plus de détails concernant l'utilisation de GnuPG dans mutt, voir la page GnuPG sur le site Muttfr.org (http://www.muttfr.org/mutt/mutt.php3?inc=mutt-7.html).
Ceci dit, il est possible d'utiliser GnuPG directement en ligne de commande. Pour signer un fichier :
$ gpg --clearsign --armor mon_fichier
un fichier mon_fichier.asc est créé, qui commence par les lignes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
et qui finit par la signature du fichier :
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD4DBQE7W46rX1807qC7PesRAk7RAJi4QF2t7nlvJkeoZKLcD9BcANhHAKCIz/gp
kNFatbp77Si64SvtfzCfvQ==
=aPzJ
-----END PGP SIGNATURE-----
Pour chiffrer un fichier, en le signant :
$ gpg --sign --armor --encrypt mon_fichier
Ici, en plus de la passphrase, il est demandé l'ID pour lequel le message sera chiffré.
Pour voir les différentes possibilités, se référer à la page de manuel de GnuPG (man gpg).
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.
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, il 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 ).
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 UID, il est possible de les signer tous ou de choisir ceux qu'on veut 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éel 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 effectue 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 connaît 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 ? correspondent à 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); par
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 connaît 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 ?
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 débuter 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'agrandit...
La place de GnuPG dans la cryptographie
Ce système, même s'il semble plus contraignant qu'un système à base d'autorités de certifications, n'en est pas moins puissant. Au contraire, même, dans une architecture basée sur les PKI, on n'est jamais sûr qu'une autorité de certification n'ait jamais été compromise, alors que dans ce système, la sécurité repose sur des échanges mutuels entre personnes.
Et encore. Comment être sûr qu'on parle à la bonne personne ? Qui me prouve que les papiers d'identité ne sont pas des faux ? Pourquoi ne pourrait-on pas avoir en face de nous un déguisement ? Et comment être sûr que ce que je lis sur la carte de visite est bien ce qui y est inscrit ?
- Oh, je vous en prie, Mulder, ne soyez pas aussi paranoïaque !
- Qui ça, moi ? Paranoïaque ?
Diffusion de cette documentation
Cette documentation est la propriété de son auteur. Elle est librement diffusable sous les termes de la Licence de Documentation Libre GNU (GNU Free Documentation License) dans sa version 1.1.
La Licence de Documentation Libre GNU peut être consultée à l'adresse http://www.gnu.org/copyleft/fdl.html ou à l'adresse http://www.IDEALX.org/fr/licences/gfdl.html pour une traduction en français.
Une version SGML de ce document est disponible à l'adresse http://www.vilya.org/gpg/gpg-intro.sgml.
Note à propos de cet article :
Cet article est une honteuse récupération du superbe document écrit par Loïc Bernable <leto@vilya.org> disponible sur http://www.vilya.org/gpg/. Suite à l'annonce de sa disponibilité sur Da Linux French Page, il nous a semblé important d'en accroître un peu plus la diffusion en le publiant dans le magazine.