La version 2.1.23-1 de GnuPG vient de devenir la version 2.2.0, considérée comme la nouvelle branche « stable », en remplacement de la 2.0.x. Elle est disponible par ici. La sortie de GPG4Win 3.0 est donc imminente. L'équipe de GPGTools, qui produit un pack destiné aux utilisateurs de macOS, n'a pas encore donné de détails sur l'arrivée de sa prochaine version.
Pendant l'été, GnuPG a subi plusieurs mises à jour. La dernière en date ne paie pas de mine, mais elle augure de la prochaine branche stable 2.2.0 de l'outil de chiffrement. Elle active ainsi par défaut des fonctionnalités simplifiant l'échange de clés lors d'un premier contact.
Dans la série « on vous annonce des trucs énormes, mais on le fait l'air de rien », notre gagnant du moment est l'équipe de GnuPG. Il faut dire qu'elle est une habituée du genre.
Après une version 2.1.21 qui corrigeait principalement des bugs et autres failles de sécurité, nous avons a eu droit fin juillet à la 2.1.22 qui apportait quelques nouveautés, surtout une reconnaissance automatique de la présence de Tor sur le système. S'il est détecté, il est désormais automatiquement utilisé, excepté si l'utilisateur utilise l'argument --no-use-tor.
Début août, c'est la version 2.1.23 qui a été mise en ligne, une mouture qui va changer la donne. Et pour cause, il s'agit en réalité d'une release candidate pour la version 2.2.0 qui doit devenir à terme la nouvelle branche stable.
gpg2, c'est fini
Pour rappel, trois branches de GnuPG coexistent. Chacune propose un niveau de fonctionnalités différent et permet d'assurer un support à plus ou moins long terme selon les besoins : Classique (1.4.x), Stable (2.0.x) et Moderne (2.1.x).
La branche stable actuelle sera considérée comme en fin de vie le 31 décembre 2017. D'ici là, elle devra donc être remplacée par la 2.2.x qui commence à se dévoiler. Et le premier changement majeur qu'elle apporte est la fin de gpg2.
En effet, selon les cas, il existait jusqu'à maintenant deux exécutables installables sur le système. Le second était gpg qui sera désormais utilisé par défaut. Les adeptes de l'ancienne méthode ou ceux disposant d'applications qui nécessitent une continuité peuvent utiliser le paramètre --enable-gpg-is-gpg2 s'ils le souhaitent.
On compte aussi d'autres petites nouveautés :
--no-grabest activé par défaut pour éviter les attaques de type X-Sniffing--disable-dirmngrpermet de désactiver complètement les accès réseau de GnuPGshow-onlypeut être utilisé lors d'un import pour montrer le résultat, sans action
Dans ce dernier cas, la commande exacte à utiliser est la suivante :
gpg --import --import-options "show-only" clef.gpg
La révolution est dans la distribution
Mais le plus grand changement vient de la méthode de distribution des clés, qui se prépare à évoluer de manière importante. En effet, GnuPG est critiqué de longue date pour sa complexité, notamment dans la gestion et le partage des clés publiques avec des tiers (voir notre analyse).
Le système actuel repose sur deux grands principes : les serveurs de clés publiques et la toile de confiance (Web Of Trust, ou WOT) qui permet à chacun d'indiquer le niveau de confiance qu'il accorde à telle ou telle clé. Mais il permet à n'importe qui de publier une clé pour n'importe quelle identité/adresse email. De plus, il rencontre de nombreuses limites pratiques, notamment lors d'un premier contact. De quoi réduire sa capacité à être utilisé par le plus grand nombre.
Au fil du temps, différentes méthodes ont été tentées. Une clé publique étant un simple fichier texte, il peut être transmis de bien des manières. Récemment, ce sont les enregistrements DNS qui ont été exploités, notamment via DANE (DNS - based Authentication of Named Entities). Mais la faible évolution des pratiques en la matière, notamment chez les hébergeurs, a presque tué dans l'œuf une telle solution.
Il a donc été mis de côté pour le moment, même si l'utilisation de DANE reste une solution évoquée par l'équipe sur le long terme, notamment dans le cadre de la mise en place de son nouveau protocole de distribution.
TOFU et Web Key Service, c'est le turfu !
Car lorsqu'elle a reçu de nouveaux financements, l'équipe de GnuPG a décidé de travailler sur la refonte de ces deux grands principes en priorité. Ainsi, plusieurs éléments sont mis en place progressivement.
Pour le modèle de confiance, c'est TOFU (Trust On First Use) qui devra prendre place dans les mois à venir. Il est possible de le tester depuis la version 2.1.10. Pour la distribution des clés, c'est le protocole Web Key Service (WKS) et ses Web Key Directory (WKD) dont il est question.
Dans les deux cas, le but recherché est le même : faciliter l'échange de clés entre deux personnes qui se contactent pour la première fois, et qui n'ont donc pas à disposition dans leur trousseau local leurs clés publiques respectives. C'est cet ensemble qui se met en place petit à petit auquel nous commençons à avoir droit à travers cette version 2.1.23, qui active par défaut deux arguments qui étaient jusqu'à maintenant optionnels.
La récupération automatique pour vérifier une signature
Le premier est --auto-key-retrieve. Comme son nom l'indique, il permet de récupérer automatiquement la clé d'un tiers à travers les serveurs de clés publics, afin de permettre de vérifier simplement une signature.
Imaginons que vous téléchargiez la dernière version de votre distribution Linux préférée ou une application. Avec le fichier principal, les développeurs publient en général une signature permettant à un tiers de s'assurer qu'ils sont bien à l'origine du fichier téléchargé et que celui-ci n'a pas été altéré (voir notre analyse).
Ainsi, vous pouvez vérifier simplement la validité de l'ISO d'Ubuntu 17.04 via la commande suivante :
gpg --verify SHA256SUMS.gpg ubuntu-17.04-desktop-amd64.iso
Problème : vous ne disposez pas de la clé publique des développeurs d'Ubuntu. Jusqu'à maintenant, la procédure à suivre était de la télécharger pour l'importer dans votre trousseau local (via la commande gpg --fetch). Désormais, tout est automatique, tant que cette clé est présente au sein d'un serveur public.
GnuPG va automatiquement récupérer l'ID de celle qui a servi à générer la signature, et la télécharger. Le résultat vous sera alors affiché et la clé sera importée dans votre trousseau. Vous aurez alors la possibilité de la supprimer, ou de modifier votre niveau de confiance si vous avez pu vérifier sa véracité :
Avant / Après GnuPG 2.1.23
L'équipe a néamoins décidé de revenir en arrière pour éviter certains problèmes évoqués dans cet email, et de désactiver ce paramètre par défaut dans la prochaine version de GnuPG. Une version 2.1.23-1 a aussi été poussé dans la branche Unstable de Debian. Il restera tout de même possible de l'activer à la demande.
La récupération automatique pour chiffrer un message
L'autre argument mis en place par défaut est --auto-key-locate "local,wkd". Celui-ci implique que lorsque vous chiffrerez un message pour une adresse email précise, la clé publique sera cherchée dans votre trousseau local, et à défaut dans une Web Key Directory définie dans le protocole Web Key Service.
Derrière ce nom se cache un nouveau concept proposé comme standard à l'IETF par le développeur principal de GnuPG, Werner Koch. L'idée est de proposer de retrouver les clés liées à un domaine directement via des fichiers présents dans un répertoire à l'emplacement prédéfini (well-know URI).
Ainsi, lorsque vous décidez de chiffrer un message pour me@jeandauh.fr, sans disposer de la clé publique associée, GnuPG va aller interroger le fichier suivant afin d'y trouver la clé publique, et l'importer si elle correspond :
https://jeandauh.fr/.well-known/openpgpkey/hu/s8y7oh5xrdpu9psba3i5ntk64ohouhga
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 guide).
L'ID de fin est constituée 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.
Notez qu'un enregistrement DNS SRV peut être utilisé afin d'indiquer un domaine ou un port différent. On regrettera par contre qu'une telle fonctionnalité ne soit pas proposée de manière plus générale, notamment à travers la commande --fetch qui pourrait aller chercher la clé liée à un email précis dans la Web Key Directory afin de simplement l'ajouter au trousseau local sans autre action complémentaire.
La simplicité n'est pas la sécurité
Le chiffrement de la connexion via HTTPS doit être supporté par le serveur. À l'heure de Let's Encrypt, il est souvent proposé par défaut par les hébergeurs qui permettent de le mettre en place assez simplement.
Ainsi, on est assuré que le fichier transmis est bien celui présent sur le serveur, et qu'il n'a pas pu être altéré par un tiers pendant son téléchargement. Attention néanmoins, si une personne mal intentionnée venait à avoir accès à votre serveur, elle pourrait aisément modifier ce fichier, et donc se faire passer pour vous.
C'est notamment pour cela que WKS/WKD est présenté comme une manière de simplifier la distribution lors d'un premier échange, mais pas de revoir le modèle de confiance sur le fond. Ainsi, la toile de confiance permet toujours de s'assurer de la véracité d'une clef sur le long terme, avec le témoignage d'une multitude de tiers.
Il est donc toujours important de certifier des clés dont vous avez pu assurer la validité, afin de faire vivre ce modèle de confiance décentralisée. Bien entendu, vous pouvez aussi vous baser sur différentes déclarations effectuées par un utilisateur à travers des services comme Keybase.io (voir notre analyse).
L'objectif final : motiver les hébergeurs et les services de messagerie
La méthode des Well-kown URI n'a rien de bien nouveau. Elle est notamment utilisée par Keybase pour valider la propriété d'un domaine ou encore par Do Not Track. Chacun peut bien entendu publier sa clé sur son propre serveur (voir notre guide ci-dessous), mais le but de l'équipe de GnuPG est d'inciter les hébergeurs et autres fournisseurs de services d'email à proposer directement ce service.
Le protocole WKS intègre ainsi tout un dispositif permettant à un utilisateur de transmettre sa clé publique à son gestionnaire d'email pour que celui-ci la publie directement via WKD ou DANE. Là aussi, cela passe par une adresse prédéfinie, qui peut être reconnue et utilisée par des outils tiers. Un début d'intégration, détaillé par l'équipe de GnuPG, est d'ailleurs présent dans les nightly builds d'Enigmail.
Malheureusement, pour le moment seul le service Posteo propose l'embryon d'une telle fonctionnalité. Espérons qu'avec l'arrivée de cette version 2.1.23, puis de la future branche 2.20, les différents services commenceront enfin à jouer le jeu comme ils ont pu le faire avec la mise en place progressive de Let's Encrypt.
Ces derniers cherchant à inciter leurs utilisateurs à moins dépendre des GAFAM et à reprendre en main leurs données, nul doute que cela ne saurait tarder. Surtout que l'implémentation du protocole WKS proposé par GnuPG est relativement triviale pour leurs équipes. C'est en tous cas un point que nous suivrons avec attention dans les mois à venir.
