Le protocole Web Key Service, qui doit permettre une meilleure distribution des clés pour un premier contact, est désormais actif par défaut dans GnuPG. Si des services comme Posteo commencent à l'implémenter, vous pouvez l'exploiter pour diffuser vous-même votre clé publique. 

Comme nous avons pu le voir, l'équipe de GnuPG vient de publier une mise à jour importante estampillée 2.1.23. Préparant l'arrivée de la nouvelle branche stable 2.2.x, elle active par défaut le support d'un nouveau protocole de distribution : Web Key Service (WKS) et ses Web Key Directory (WKD). 

WKS/WKD : la diffusion simplifiée de votre clé GPG publique

Pour faire simple, il s'agit de lier une adresse email à une clé publique GnuPG sans avoir à passer par le système des serveurs de clés. Ces derniers permettent en effet à n'importe qui de publier une clé pour n'importe quelle adresse, sans aucune vérification. Ils ne peuvent donc pas être considéré comme un moyen de trouver une clé de confiance du premier coup, sans vérification complémentaire.

L'idée derrière WKS/WKD est de stocker un fichier dans un dossier prédéfini du serveur hébergé par un domaine, afin d'y exposer les clés de ceux qui y disposent d'une adresse email. Si un utilisateur veut chiffrer un document pour cette adresse, et qu'il ne dispose pas déjà d'une clé associée dans son trousseau local, GPG ira la chercher sur le serveur.

Si un fichier contenant la clé publique est trouvé, il est importé et le message est chiffré automatiquement, une fois que l'utilisateur aura donné son accord. Ainsi, plus aucune étape n'est nécessaire entre la demande de chiffrement et son exécution en l'absence d'une clé publique associée. De quoi largement simplifier un premier contact.

L'objectif final est d'inciter les services de messagerie et autres hébergeurs à proposer une intégration native du protocole, tout comme les clients tels que Thunderbird/Enigmail. Ainsi, diffuser une nouvelle clé sera relativement simple tant pour l'expéditeur que pour le destinataire.

Posteo : un service d'email avec chiffrement plutôt intéressant

Mais voilà, pour le moment, seul Posteo propose un début d'intégration de WKS/WKD. Ce service de messagerie allemand est plutôt engagé dans le domaine du chiffrement et de la protection des données. Il permet notamment de chiffrer via un mot de passe votre carnet d'adresses, votre calendrier et le stockage de l'ensemble de vos données.

Vous pouvez aussi y refuser l'envoi d'un email si le chiffrement SSL/TLS de la connexion n'est pas assuré sur l'ensemble du parcours. Vous recevrez alors un message qui vous demandera si vous voulez tout de même envoyer le message ou non.

Vous pouvez simplement transmettre votre clé publique (GPG ou S/MIME) à travers un email, afin d'intégrer l'annuaire DNS du service. Mais pour le moment, WKD ne semble pas pleinement fonctionnel. La fourniture de cette clé vous permettra d'activer un chiffrement à l'entrée dont le principe est de l'utiliser pour chiffrer l'ensemble des messages reçus afin qu'ils ne soient pas accessibles en clair. Ainsi, seule une personne détenant votre clé privée pourra les lire.

Le service met aussi en avant son utilisation exclusive d'énergie « verte » (fournie par Greenpeace Energy) entre autres engagements sociaux et écologiques, l'absence de publicité et l'absence de divulgation de données à caractère personnel. Le tarif de base est de 1 euro par mois pour 2 Go de stockage, deux alias, la gestion du carnet d'adresse et du calendrier.

Si vous le souhaitez, vous pouvez payer plus, le service proposant un prix libre. Vous pouvez aussi ajouter du stockage (0,25 euro par Go), des alias (0,10 euro pour deux) ou des calendriers (0,10 euro pour trois). La note peut donc vite grimper, surtout si vous êtes gourmand du côté des pièces jointes.

Diffuser votre propre clé publique : les prérequis

En attendant que les hébergeurs et les fournisseurs d'email se bougent, vous avez néanmoins une possibilité qui s'offre à vous si vous voulez profiter de la généralisation de WKS/WKD : diffuser vous-même votre clé publique. Pour cela, il vous faudra disposer de quatre choses :

• Un serveur d'hébergement lié à un domaine
• Un certificat SSL/TLS lié à ce domaine
• Une adresse email liée à ce domaine
• Une paire de clés GPG liée à cette adresse

Dans notre cas nous avons opté pour une solution simple : un hébergement mutualisé OVH. Comme d'autres (Gandi ou Infomaniak par exemple), la société propose la mise en place automatisée et gratuite d'un certificat Let's Encrypt à activer dans son Manager, et des emails sur l'ensemble de son offre.

Notez d'ailleurs que même l'offre Start10M accessible gratuitement sur chaque domaine, permet d'obtenir un certificat Let's Encrypt. Pour rappel, elle se compose de 10 Mo de stockage web, 5 Go pour une adresse accessible via les protocoles POP/IMAP, une interface Roundcube (1.2.4), dix redirections et un répondeur.

Générer votre clé avec GPG

Une fois que vous avez tout ce qu'il vous faut, la première étape à suivre est de générer le fichier qui contiendra votre clé publique. Ici, une procédure d'export classique ne suffit pas.

Les équipes de GnuPG mettent à votre disposition une solution à base de script Python, plutôt pensée pour ceux qui disposent d'un serveur dédié. Mais il y a franchement plus simple. Tout commence par une simple ligne de commande :

C:\>gpg --with-wkd-hash -k me@jeandauh.fr

pub rsa4096 2015-04-12 [SC] [expire : 2017-12-31]
C508D8474655467F2E58D86A34354A80ABE928E6
uid [ inconnue] Jean Dauh <me@jeandauh.fr>
s8y7oh5xrdpu9psba3i5ntk64ohouhga@jeandauh.fr
sub rsa4096 2015-04-12 [E] [expire : 2017-12-31]
sub rsa4096 2015-04-12 [S] [expire : 2017-12-31]

Ici, le but est de récupérer un ID qui sera nécessaire dans la composition de l'URL où GPG ira chercher la clé. Celui-ci est constitué de 32 caractères issus d'une empreinte SHA-1 de la partie locale de l'email (ici, me) encodée via Z-Base32, qui est une version spécifique de Base32 se voulant plus simple à appréhender et à gérer pour un utilisateur, notamment en évitant les confusions possibles entre certains caractères. 

Il se situe sous la ligne commençant par uid, dans notre cas il s'agit de s8y7oh5xrdpu9psba3i5ntk64ohouhga. Le fichier contenant la clé publique sera composé uniquement de cet ID. Ainsi la commande d'export devra être la suivante :

gpg --export me@jeandauh.fr > s8y7oh5xrdpu9psba3i5ntk64ohouhga

Mettre votre clé publique en ligne

Une fois ce fichier créé il faut le placer sur votre serveur. Dans notre cas nous utilisons le client FTP open source Filezilla. Il faudra commencer par créer une série de répertoires afin d'arriver à l'URL finale telle qu'elle doit être composée :

https://jeandauh.fr/.well-known/openpgpkey/hu/s8y7oh5xrdpu9psba3i5ntk64ohouhga

Une fois le dernier répertoire créé (hu, pour hashed user-id), il suffit d'y placer le fichier qui contient votre clé. Dans notre cas, nous avons rencontré deux problèmes à cette étape. La première concerne le mode de transfert opéré par défaut par Filezilla. En effet, le fichier était modifié et ne faisait plus la même taille à l'arrivée du fait de sa composition. Nous avons donc du opter pour un transfert binaire plutôt qu'ASCII ou le mode automatique (Transfert > Type de Transfert).

Ensuite, il faut savoir qu'OVH active par défaut un firewall sur ses offres mutualisées (mod_security). Celui-ci bloque certains types de requêtes, notamment celles opérées par GnuPG pour récupérer la clé lorsque celle-ci est détectée.

À défaut d'une solution plus fine permettant de faire passer ces requêtes, la seule chose à faire est de désactiver ce firewall. Pour cela vous pouvez passer par le Manager comme décrit ici, mais dans notre cas cela ne fonctionnait pas. Vous pourrez alors éditer le fichier .ovhconfig à la racine de votre serveur, et remplacer la ligne du firewall ainsi :

http.firewall=none

Espérons tout de même qu'une meilleure solution pourra être trouvée. Chez d'autres hébergeurs, des procédures similaires seront parfois nécessaires, tout dépendra de la composition et de la configuration de votre serveur. N'hésitez pas à vous rapprocher du service client en cas de problème ou à partager vos expériences dans les commentaires.

Enfin, n'hésitez pas à placer un fichier .htaccess à la racine du répertoire .well-known afin d'éviter qu'un tiers puisse lister les fichiers présents dans ses différents sous-répertoires, si une telle interdiction n'est pas déjà mise en place. Pour cela, il suffit de placer le contenu suivant dans le fichier :

Options -Indexes

Il n'y a plus qu'à tester

Une fois le fichier en ligne, vous n'avez plus qu'à vérifier que tout fonctionne. Pour cela, une simple ligne de commande de chiffrement d'un fichier suffit : 

echo Coucou > test.txt
gpg -e -r me@jeandauh.fr test.txt

La clef devrait être récupérée automatiquement si elle n'est pas déjà présente dans votre trousseau local. L'avertissement classique pour une clé non certifiée vous sera ensuite affiché afin de vous demander de confirmer qu'il faut bien l'utiliser malgré tout. Cette demande peut être retirée avec l'utilisation de l'argument --always-trust.

gpg: clef 34354A80ABE928E6 : clef publique « Jean Dauh <me@jeandauh.fr> » importée
gpg: Quantité totale traitée : 1
gpg: importées : 1
gpg: aucune clef de confiance ultime n'a été trouvée
gpg: « me@jeandauh.fr » automatiquement récupéré par WKD

gpg: 49F683FB653B891F : aucune assurance que la clef appartienne vraiment à l'utilisateur.
sub rsa4096/49F683FB653B891F 2015-04-12 Jean Dauh <me@jeandauh.fr>
Empreinte clef princip. : C508 D847 4655 467F 2E58 D86A 3435 4A80 ABE9 28E6
Empreinte de sous-clef : 3416 D6D3 F710 A81D D899 E069 49F6 83FB 653B 891F

La clef n'appartient PAS forcément à la personne nommée
dans l'identité. Si vous savez *vraiment* ce que vous
faites, vous pouvez répondre oui à la prochaine question.

Faut-il quand même utiliser cette clef ? (o/N)

Si vous confirmez, le fichier sera chiffré. Dans tous les cas, la clé sera ajoutée à votre trousseau local. Et désormais, n'importe qui avec la dernière version de GnuPG pourra faire de même, et chiffrer un fichier vous étant destiné de manière automatique.

Un dispositif que l'on a hâte de voir intégré à des outils tels que GPA et Kleopatra ainsi que les différents clients mail qui gèrent GPG nativement ou via des extensions. L'arrivée de la version stable de GPG4Win 3.0 sous Windows, attendue normalement pour la fin du mois, devrait permettre d'en avoir un premier aperçu.

Notez enfin que cette URL peut aussi être utilisée dans les données d'une OpenPGP Card afin de permettre de récupérer votre clé publique au sein d'une nouvelle machine (voir notre analyse).