Utilisation de GNU Privacy Guard (version 2)

Ce logiciel est installé par défaut sous Linux – au moins sur Debian et Ubuntu – est désormais disponible qu’en version 2 sur les distributions les plus récentes. Mon utilisation de la version précédente n’est plus pertinente, mais elle sera la base de cet article.

Les principales évolutions sont décrites ici.

Avant de générer des clefs, il est nécessaire de créer de l'entropie sur le système. La solution est d'installer le paquet rng-tools (sous Debian).

sudo apt update && sudo apt install rng-tools

Pour configuer rng-tools il faut éditer le fichier /etc/default/rng-tools pour ajouter cette ligne :

rng-tools

HRNGDEVICE=/dev/urandom

Et ensuite il faudra relancer ce service avec la commande :

sudo service rng-tools restart

Nous utiliserons le groupe de serveur de clés sks. Le bon fonctionnement des machines de ce groupe est vérifié par des contrôles de routine réguliers. Si un serveur ne fonctionne pas bien, il sera automatiquement retiré du groupe. Nous devrons aussi nous assurer que nous communiquerons avec le groupe de serveurs de clés au travers d’un canal chiffré, en utilisant un protocole qui s’appelle hkps. Pour utiliser le groupe de serveurs de clés, il faudra télécharger l’autorité de certification de sks-keyservers.net

cd; curl -O https://sks-keyservers.net/sks-keyservers.netCA.pem
sudo cp sks-keyservers.netCA.pem /usr/share/ca-certificates/
echo sks-keyservers.netCA.pem | sudo tee -a /etc/ca-certificates.conf
sudo update-ca-certificates

Il faudra ensuite utiliser les paramètres suivants dans ~/.gnupg/gpg.conf :

gpg.conf

keyserver hkps://hkps.pool.sks-keyservers.net

Et spécifier le chemin d’accès complet où vous avez sauvegardé le fichier de l’autorité de certification en bas du fichier dirmngr.conf :

dirmngr.conf

hkp-cacert /etc/ssl/certs/sks-keyservers.netCA.pem.pem

Avec cette configuration les interactions avec le serveur de clés seront chiffrées avec hkps, qui masquera notre réseau de relations sociales pour éviter qu’il soit divulgué à quiconque intercepterait le trafic réseau. Par exemple, si vous faites gpg –refresh-keys sur un serveur de clés qui ne supporte que hkp, quelqu’un surveillant le trafic pourrait voir toutes les clés que nous possédons dans notre trousseau en observant les demandes de mises à jour envoyées pour chacune d’entre elles. C’est là une information plutôt intéressante ! Note : hkps://keys.indymedia.org, hkps://keys.mayfirst.org et hkps://keys.riseup.net sont d’autres serveurs qui proposent ce service, mais il est préférable de leur préférer un groupe de serveurs.

Un utilisateur qui crée sa clé peut indiquer un serveur de clés spécifique auquel s’adresser pour récupérer les nouvelles versions de sa clé. Il est recommandé d’utiliser l’option suivante dans ~/.gnupg/gpg.conf, qui ignorera de telles instructions :

gpg.conf

keyserver-options no-honor-keyserver-url

C’est une bonne chose à faire, car

1. cela évite que les gens indiquent des méthodes non-sécurisées pour télécharger des mises à jour de leurs clés,
2. et même si le serveur choisi utilise hkps le rafraîchissement échouera parce que le ca-cert ne correspondra pas, ne correspondra pas, et donc la clé ne sera jamais mise à jour ;
3. notez aussi qu’un attaquant pourrait désigner un serveur de clés sous son contrôle afin de surveiller à quel moment et depuis quel endroit nous rafraîchissons les clés.