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.

Nous devons nous assurer que les clés se rafraîchissent régulièrement. La meilleure façon de le faire avec Debian ou Ubuntu est d’utiliser parcimonie :

sudo apt-get install parcimonie

Parcimonie est un démon qui rafraîchit lentement votre trousseau de clés à partir d’un serveur de clés en passant par Tor. Il utilise un délai aléatoire et un nouveau circuit Tor pour chaque clé. Le but est de compliquer la vie d’un attaquant qui voudrait corréler les mises à jour de clés avec votre trousseau. Vous ne devriez pas utiliser gpg –refresh-keys ou la fonction équivalente de votre client de messagerie pour rafraîchir les clés, parce que vous dévoilerez ainsi à toute personne qui vous écoute, et à l’opérateur du serveur de clés, la totalité des clés que vous désirez rafraîchir.

N’importe qui peut envoyer des clés sur les serveurs et il n’y a pas de raison de croire que celles que vous téléchargez appartiennent vraiment à la personne dont elles indiquent le nom. Nous devons donc vérifier personnellement avec le propriétaire l’empreinte entière de sa clé. Nous devrons faire cette vérification face à face ou par téléphone. Une fois que nous aurons vérifié l’empreinte, nous pourrons télécharger la bonne clé depuis un serveur :

gpg --recv-key '<fingerprint>'

Attention aux apostrophes droites ci-dessus (‘) qu’il faut placer autour de l’empreinte complète et qui sont nécessaires pour que la commande fonctionne. Les guillemets droits (“) fonctionnent également. Ne vous fiez pas à l’identifiant de clef.

Les identifiants courts pour les clés OpenPGP, par exemple 0×2861A790, sont d’une longueur de 32 bits. Il fut démontré la possibilité de les usurper avec une autre clé qui a le même identifiant. Les identifiants longs pour les clés OpenPGP (par exemple 0xA1E6148633874A3D) sont d’une longueur de 64 bits. Il est trivial de générer des collisions dessus, ce qui est également un problème potentiellement sérieux. L’utilisation du fingerprint est préférable.

La configuration utilisateur se fait dans le fichier gpg.conf ainsi que dans dirmngr.conf du répertoire par défaut de l'application. Si ces fichiers n'existent pas il faudra les créer et leur attribuer des droits limités :

nano ~/.gnupg/gpg.conf
chmod 600 ~/.gnupg/gpg.conf
chmod 600 ~/.gnupg/dirmngr.conf

Par défaut, le répertoire ~/.gnupg a ses autorisations définies sur 700 et les fichiers contenus sur 600. Seul le propriétaire du répertoire est autorisé à lire, écrire et accéder aux fichiers. Ceci est à des fins de sécurité et ne doit pas être modifié. Dans le cas où ce répertoire ou n'importe quel fichier à l'intérieur de celui-ci ne respecte pas cette mesure de sécurité, vous obtiendrez des avertissements concernant les autorisations de fichiers et de répertoires personnels non sécurisés.

gpg.conf

#
# This is an implementation of the Riseup OpenPGP Best Practices
# https://help.riseup.net/en/security/message-security/openpgp/best-practices
# Adapted by d2air for GnuPG v2
 
#-----------------------------
# default key
#-----------------------------
 
# The default key to sign with. If this option is not used, the default key is
# the first key found in the secret keyring
 
#default-key 0xD8692123C4065DEA5E0F3AB5249B39D24F25E3B6
 
 
#-----------------------------
# behavior
#-----------------------------
 
# Disable inclusion of the version string in ASCII armored output
no-emit-version
 
# Disable comment string in clear text signatures and ASCII armored messages
no-comments
 
# Display long key IDs
keyid-format 0xlong
 
# List all keys (or the specified ones) along with their fingerprints
with-fingerprint
 
# Display the calculated validity of user IDs during key listings
list-options show-uid-validity
verify-options show-uid-validity
 
# Try to use the GnuPG-Agent. With this option, GnuPG first tries to connect to
# the agent before it asks for a passphrase.
use-agent
 
 
#-----------------------------
# keyserver
#-----------------------------
 
# This is the server that --recv-keys, --send-keys, and --search-keys will
# communicate with to receive keys from, send keys to, and search for keys on
keyserver hkps://hkps.pool.sks-keyservers.net
 
# When using --refresh-keys, if the key in question has a preferred keyserver
# URL, then disable use of that preferred keyserver to refresh the key from
keyserver-options no-honor-keyserver-url
 
# When searching for a key with --search-keys, include keys that are marked on
# the keyserver as revoked
keyserver-options include-revoked
 
 
#-----------------------------
# algorithm and ciphers
#-----------------------------
 
# list of personal digest preferences. When multiple digests are supported by
# all recipients, choose the strongest one
personal-cipher-preferences AES256 AES192 AES CAST5
 
# list of personal digest preferences. When multiple ciphers are supported by
# all recipients, choose the strongest one
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
 
# message digest algorithm used when signing a key
cert-digest-algo SHA512
 
# This preference list is used for new keys and becomes the default for
# "setpref" in the edit menu
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

Le détail des différentes options possibles de ce fichier se trouvent ici.

dirmngr.conf

# The option --use-tor Dirmngr and thus GnuPG into “Tor mode” to route all network access via Tor (an anonymity network).
use-tor
 
# Provide a certificate store to override the system default
# Get this from https://sks-keyservers.net/sks-keyservers.netCA.pem
hkp-cacert /etc/ssl/certs/sks-keyservers.netCA.pem.pem

Le détail des différentes options possibles de ce fichier se trouvent ici.

Il est recommandé de générer une clé RSA de 4096 bits avec l’algorithme de hachage SHA-512, mais les courbes elliptiques sont maintenant supportées via l’option expert.

En cas transition, une méthode est de rédiger un communiqué de transition signé par les deux clés, puis en informer les gens. Cette page détaille le processus à suivre pour générer une telle clé en s’assurant d’utiliser le bon algorithme de hachage (ça peut être compliqué avec des versions de GnuPG plus anciennes que la 1.4.10).

Mettre une date d’expiration sur sa clé est une bonne chose. Pourquoi ? Parce que vous pouvez toujours étendre votre date d’expiration, même une fois qu’elle est passée ! Cette expiration est plutôt une sorte de valve de sûreté ou un « dispositif de l’homme mort » qui se déclenchera automatiquement à un certain moment. Si vous avez accès à la clé privée, vous pouvez le désamorcer. L’idée est de configurer un mécanisme qui désactivera votre clé au cas où vous n’y accéderiez plus (et ne disposez pas d’un certificat de révocation). Paramétrer une date d’expiration vous obligera à repousser cette date quand elle approchera. C’est une petite chose que vous devrez vous souvenir de faire.

Vous pouvez penser que c’est pénible et que vous ne voulez pas vous en occuper, mais c’est en fait une bonne chose de faire cela de façon régulière pour maintenir à niveau vos compétences OpenPGP. Cela indique aux utilisateurs que la clé est toujours active, que le détenteur de la clé l’utilise toujours, et cela vous donne une occasion de vérifier l’état actuel de vos outils, et vos bonnes pratiques. Du reste, beaucoup de personnes refuseront de signer une clé qui n’a pas de date d’expiration !

Si vous avez déjà généré une clé sans date d’expiration, vous pouvez en spécifier une sur votre clé existante en utilisant la commande suivante :

gpg --edit-key '<fingerprint>'

À présent, sélectionnez la sous-clé pour laquelle vous voulez paramétrer une date d’expiration (par exemple la première), ou aucune pour paramétrer l’expiration de votre clé primaire, puis invoquez la commande expire :

gpg> key 1
gpg> expire

Ajustez ensuite la date à une valeur raisonnable (par exemple deux ans plus tard), puis sauvegardez la clé et quittez :

Key is valid for? (0) 2y 
gpg> save

Vous pouvez alors envoyer votre clé aux serveurs de clés pour publier ce changement :

gpg --send-key '<fingerprint>'

gpg --expert --full-gen-key