GnuPG 2.2.20 simplifie la gestion des clés publiques dès le premier contact : comment ça marche ?

Si une personne vous envoie un message signé via GPG mais que vous n'avez pas sa clé publique pour en vérifier la validité, comment faire ? Vous pouvez la récupérer en ligne ou elle peut être présente en pièce jointe. Mais dans ce dernier cas, l'import n'est pas toujours très simple. Un problème qui fait désormais partie du passé.

Les développeurs de GnuPG viennent de publier la version 2.2.20 de l'outil de chiffrement. Comme nous l'évoquions dans #LeBrief, elle apporte quelques correctifs et améliorations, mais surtout deux paramètres basés sur les règles Autocrypt, devant guider les développeurs dans la conception de solutions de chiffrement plus simples.

C'est l'un des sujets sur lequel l'équipe de GPG travaille le plus ces dernières années. La version 2.2 mise en ligne en 2017 intégrait ainsi les mécaniques TOFU (Trust On First Use) et Web Key Service/Directory pour simplifier la découverte des clés publiques de manière décentralisée. Aujourd'hui, l'idée est de proposer une solution similaire, mais plus directe.

En effet, l'idée est de permettre à chacun de signer un message tout en intégrant sa clé publique à la signature, plutôt que de fournir ces deux éléments de manière séparée. Ainsi, le destinataire peut vérifier la validité du message même en cas de premier contact, puis répondre de manière chiffrée, l'import de la clé publique étant automatisé.

Un dispositif qui doit encore être intégré à des plugins tels que GpgOL pour Outlook, mais qui est prometteur. Voici un petit guide d'utilisation, en ligne de commandes pour le moment.

Générer une signature en intégrant sa clé publique

Nous partirons ici du principe que vous savez ce qu'est le chiffrement asymétrique, GnuPG et que vous disposez de votre propre paire de clés. Si ce n'est pas le cas, nous avons de nombreux guides pour vous permettre d'y voir plus clair :

Imaginons maintenant que Jean Deauh (me@jeandeauh.fr) veuille communiquer avec une personne dont on vient de lui donner l'adresse email : Alice Wonderland (alice@wonderland.de). Il veut lui permettre de vérifier qu'il est bien l'expéditeur et que son message n'a pas été modifié. Pour cela, il doit signer cryptographiquement son message.

Dans la façon actuelle dont fonctionne GnuPG, Jean doit signer le message grâce à sa clé privée, faire parvenir le message signé à Alice. Celle-ci pourra en vérifier la validité grâce à la clé publique de Jean. Mais comment se la procurer ? Alice peut passer par un serveur de clé ou une mécanique d'import simplifié et automatisé via une Web Key Directory. Mais pour cela, Jean doit avoir au préalable avoir mis en ligne sa clé publique et Alice doit être sûr de récupérer la bonne.

Une autre solution consiste à envoyer la clé publique avec le message, ce qui a désormais un nouvel avantage.

Signer un message avec intégration de la clé publique

Car avec GnuPG 2.2.20 Jean peut signer son message en indiquant qu'il veut intégrer sa clé publique à la signature, sous la forme d'un sous-paquet. Une méthode « 2-en-1 » qui s'inspire du CertificateSet de la Cryptographic Message Syntax (CMS, RFC 5652). Comment faire ? En une ligne de commande :

echo Coucou ! > text.txt
gpg -s -a --include-key-block text.txt

Ici, Jean crée un message dans un fichier texte et le signe (signature au format « lisible » ASCII via le paramètre -a). Le résultat obtenu est différent de s'il l'avait fait sans y intégrer sa clé publique (via --include-key-block) :

La taille du fichier est de 2 199 octets, contre 557 sans la clé, avec le contenu suivant :

On le voit, la seconde est plus courte, puisqu'elle ne contient que la signature. Les deux messages n'ont par contre rien à voir, ne permettant pas de distinguer la signature de la clé publique de l'utilisateur, qui est la suivante :

Vérifier un message avec la clé publique intégrée à la signature

Le fichier généré par la nouvelle méthode est la seule à permettre une vérification avec extraction et import de la clé publique en une seule étape. Ainsi, recevant le message et la signature, Alice n'a qu'une commande à effectuer :

gpg --verify --auto-key-import text.txt.asc
gpg: Signature faite le 03/23/20 16:35:48 Paris, Madrid
gpg: avec la clef RSA 6D0F1A993692AE0EB3EFCA06518F13C5985E6721
gpg: clef 518F13C5985E6721 : clef publique « Jean Deauh  » importée
gpg: Bonne signature de « Jean Deauh  » [inconnu]
gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance.
gpg: Rien n'indique que la signature appartient à son propriétaire.
Empreinte de clef principale : 6D0F 1A99 3692 AE0E B3EF CA06 518F 13C5 985E 6721
gpg: WARNING: not a detached signature; file 'text.txt' was NOT verified!

La clé publique est identifiée, détectée puis importée. GnuPG précise qu'elle n'a pour le moment pas été vérifiée par l'utilisateur et n'est donc pas considérée comme une clé de confiance dans le cadre du Web of Trust (WOT). La validité est confirmée : le fichier n'a pas été modifié, il a été envoyé par la personne ayant généré cette signature.

Si Alice avait utilisé la méthode classique, elle aurait rencontré une erreur :

gpg --verify text.txt.asc
gpg: Signature faite le 03/23/20 16:35:48 Paris, Madrid
gpg: avec la clef RSA 6D0F1A993692AE0EB3EFCA06518F13C5985E6721
gpg: Impossible de vérifier la signature : Pas de clef publique

L'import automatisé de la clé publique du destinataire paraît anodin, mais il est d'importance : grâce à lui, Alice pourra ensuite directement répondre à Jean en protégeant son message de sorte qu'il soit le seul à pouvoir le lire. Pour cela, il sera chiffré avec la clé publique de Jean, et ne sera lisible que par un utilisateur disposant de sa clé privée.

Une nouvelle procédure intéressante

Cette nouvelle méthode est donc parfaite pour favoriser un premier contact. Vous voulez initier un échange sécurisé avec un tiers qui ne vous connaît pas, et ne dispose donc pas de votre clé publique. Dès la réception de votre message, celle-ci lui est transmise et peut être intégrée à son trousseau, lui permettant de vous répondre dans la foulée.

On imagine que les clients avec interface graphique pourront rendre cet import automatisé optionnel, ou tout du moins demander à l'utilisateur son accord avant de procéder. Mais une telle simplification est la bienvenue. On se demande d'ailleurs pourquoi personne n'y a pensé plus tôt.

Signaler une erreur