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

La bonne solution est souvent low tech

Le 23 mars 2020 à 16h21

10 min

Logiciel

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 ([email protected]) veuille communiquer avec une personne dont on vient de lui donner l'adresse email : Alice Wonderland ([email protected]). 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.

Commentaires (19)

Shamaan Abonné

Le 24/03/2020 à 15h29

J’aurai une petite question(en fait plusieurs…) sur les usage de GPG et le chiffrement des correspondances de façon générale car à chaque news sur le sujet, je me demande toujours qui cela concerne en réalité.

Qui utilise vraiment ces systèmes de chiffrement ? et parmi votre entourage ?

A défaut, qui utilise des fournisseurs type Protonmail/Tutanota/posteo… mais en ayant compris le principe réel (avec le réel objectif d’essayer de chiffrer au maximum les correspondances) ?

Parmi vous(et votre entourage), avez-vous pris en compte le fait que ces services sont bien souvent incompatibles entre eux pour le moment (et donc cela réduit forcément la portée) ?

Je vous pose ces questions car, honnêtement, j’ai l’impression qu’en dehors d’une très faible minorité d’utilisateurs avancés, personne n’utilise ces solutions au quotidien.

J’ai bien des comptes Tutanota et Protonmail mais une seule personne de mon entourage à adopter l’un deux.

Actuellement, à défaut de chiffrement, j’ai lâché gmail pour un domaine perso chez un registre français.

Bref, même si je comprends l’intérêt et à peu près le fonctionnement, j’ai l’impression qu’en l’état, les protocoles existants pour la gestion des emails ne permettront pas l’arrivée du chiffrement “par défaut”.

Et tant que cela ne sera pas par défaut, je ne vois pas comment cela peut se répandre.

David_L Abonné

Le 24/03/2020 à 17h03

Trop peu de monde, mais ce n’est pas une raison pour ne pas s’y mettre. Ne serait-ce que la signature des email (via GPG ou autre d’ailleurs) serait une bonne chose si elle était généralisée. Mais on peut dire pareil des sauvegardes, de la saine gestion des mots de passe, etc. Le rapport bénéfice/risque est en général assez mal évalué jusqu’au premier gros problème. 

Pour GnuPG, ne pas oublier que ce n’est pas qu’une question de message, de nombreux systèmes se reposent dessus pour sécuriser des échanges sans que ce soit toujours visible des utilisateurs, que ce soit pour la signature de fichiers à récupérer en ligne, les mises à jour via APT ou autre sous Linux, etc. 

Shamaan Abonné

Le 24/03/2020 à 18h34

J’ai du mal à voir le rapport avec le bénéfice/risque. Quand une personne perd ses documents ou l’accès à un compte par mauvais mot de passe, le problème est très concret pour elle.

Ici, j’ai du mal à voir le problème concret qui pourrait la convaincre.

D’ailleurs, je le mesure un peu à mon niveau : j’ai réussi à convaincre quelques proches à l’usage de mots de passe via un gestionnaire et faire attention à leur sauvegarde. Si je leur parle de signature d’email et de chiffrement, je les perds directement car ils ne voient pas d’application concrète.

Si vous avez des arguments, je suis preneur, ça me permettra d’en parler plus facilement autour de moi" />

Ju_ Abonné

Le 24/03/2020 à 19h28

David_L a écrit :

(…)
Si MITM il y a il peut tout changer : la clé, la signature, le message. Par contre il ne peut pas récupérer le contenu du message d'origine. (...)
 

Bonjour,

Très intéressant article, cette nouvelle approche devrait permettre d’augmenter le nombre d’utilisateurs de chiffrement asymétrique pour les échanges de messages.

Dans la citation ci-dessus, je ne comprends pas la différence que vous faites entre le message et le message d’origine.

On est bien dans le cas ou Jean envoie un premier message chiffré à Alice ? Où dans le cas de la réponse d’Alice ? (réponse qui elle même contient son certificat publique avec la clé de chiffrement)

David_L Abonné

Le 25/03/2020 à 05h54

Le phishing existe principalement du fait de l’absence de signature numérique des emails, et donc de possibilité d’avoir une vérification forte des échanges.

Tous les emails (et à fortiori de nombreux messages échangés au quotidien sur les réseaux) transitent de manière chiffrée (via TLS) mais leur contenu est en clair à de nombreuses étapes. Le risque est là : que tous les échanges soient un jour récupérés et publiés. S’ils étaient chiffrés, ce ne serait pas (ou moins facilement possible).

Sans parler du fait que certains services ne chiffrent pas forcément en base. Essaie un jour de monter une instance Mastodon, de faire des messages privés et de regarder la base. Tu verras le “pouvoir” des administrateurs en absence d’un chiffrement. 

Tout ce qui est chiffré par l’utilisateur est de fait protégé. Quand on se repose sur des tiers, on dépend de leur bonne volonté. Et ce n’est pas toujours la bonne approche.

 

Ju_ a écrit :

 Dans la citation ci-dessus, je ne comprends pas la différence que vous faites entre le message et le message d’origine.

On est bien dans le cas ou Jean envoie un premier message chiffré à Alice ? Où dans le cas de la réponse d’Alice ? (réponse qui elle même contient son certificat publique avec la clé de chiffrement)

Je parlais d’un cas général. En cas de MITM, l’attaquant peut récupérer le message qui transite. S’il est en clair, il le récupère directement. S’il est chiffré, il ne peut pas avoir accès au message d’origine (non chiffré donc) à moins d’avoir la clé privée du destinataire.

Shamaan Abonné

Le 25/03/2020 à 11h58

David_L a écrit :

Le phishing existe principalement du fait de l’absence de signature numérique des emails, et donc de possibilité d’avoir une vérification forte des échanges.

Tous les emails (et à fortiori de nombreux messages échangés au quotidien sur les réseaux) transitent de manière chiffrée (via TLS) mais leur contenu est en clair à de nombreuses étapes. Le risque est là : que tous les échanges soient un jour récupérés et publiés. S’ils étaient chiffrés, ce ne serait pas (ou moins facilement possible).

Sans parler du fait que certains services ne chiffrent pas forcément en base. Essaie un jour de monter une instance Mastodon, de faire des messages privés et de regarder la base. Tu verras le “pouvoir” des administrateurs en absence d’un chiffrement. 

Tout ce qui est chiffré par l’utilisateur est de fait protégé. Quand on se repose sur des tiers, on dépend de leur bonne volonté. Et ce n’est pas toujours la bonne approche.

je rejoins les arguments techniques mais plaçons nous dans la peau d’une personne qui n’y connaît pas grand chose.

Dans les commentaires plus haut, Mihashi a indiqué: “Lors du premier contact (non chiffré, forcément), il faut vérifier l’identité de la personne que l’on croit contacter en utilisant un autre moyen.”

Cela rejoint également, pour ce que j’en comprends, ton exemple avec Bill Gates.

 

Si quelqu’un reçoit un email provenant de [email protected] signé correctement alors que le compte devrait être [email protected], comment l’utilisateur lambda peut s’y retrouver ?

il faudra qu’il passe par une étape supplémentaire de vérifier de la signature vis-à-vis de celle attendue. Qui le fera vraiment ?

D’où mon idée qu’il faudrait imaginer une évolution de protocole pour faciliter tout cela, si cela est seulement faisable…

Pour les messages échangés de façon générale, je rejoins une nouvelle fois les enjeux (13 ans de Nextinpact, ça aide!) mais le fameux “je n’ai rien à cacher” à la vie très dure.

Malgré les articles et vidéos dédiés à ce sujet, personne ne voit l’inpact sur son quotidien.

Presque tout le monde est ravi que Gmail ajoute tout seul les réservations (hotel/vol/…) dans les calendriers, que l’appli message d’Android fasse des propositions de réponse automatiques “éclairées par l’IA” selon l’analyse des anciens messages,…

Du coup, même si j’adhère à 100% à ton commentaire dans les constats/enjeux et solutions qui devraient être mises en place, je reste malgré tout à court d’arguments concrets pour conseiller mon entourage.

Quoi qu’il en soit, continuez à informer comme vous le faites car il n’y a que comme ça que l’on pourra être au courant de ces avancées !

David_L Abonné

Le 26/03/2020 à 11h21

Le souci c’est de penser qu’on peut lutter contre l’utilisateur qui ne fait pas ce qu’il faut et que la solution est forcément technologique. Si un utilisateur ne vérifie pas qui lui fait parvenir un message, tu pourras mettre toute la crypto du monde, que ça ne retirera rien au problème.

On a le même souci avec le discours “cadenas vert = sécurité” que certains ont poussé parce que ça faisait un discours simple à digérer pour le grand public. Et donc quand ce dernier tombe sur un site de phising avec un cadenas vers sans vérifier le contenu du certificat, l’authenticité de l’URL, etc… il se fait avoir.

Il faut une culture numérique plus forte, il faut informer sur les solutions, les enjeux et les risques. Cela prendra du temps à rentrer dans les moeurs, c’est une solution de long terme, mais rien ne sera plus efficace que ça. Il faut juste, en //, gérer tout ce qui va se passer d’ici là (et donc les fuites, pertes de données et leurs impacts plus ou moins douloureux… mais inévitable en l’état actuel des choses). 

glacasa Abonné

Le 23/03/2020 à 17h12

Intéressant, mais en pratique je me demande à quel point ça simplifie vraiment l’échange.

La clé est bien reçue, et certifie que le message est signé correctement - mais il faut toujours trouver un moyen de vérifier que la clé appartient bien à la bonne personne.

 Il faudrait pas que la simplification de la première étape fasse oublier la seconde.

 

David_L Abonné

Le 23/03/2020 à 17h22

L’idée c’est de retirer de la friction au cas le plus courant qui pose souci : je reçois un message d’une personne que je ne connais pas : je dois aller chercher sa clé, l’importer, lancer la vérification. WKD permet l’import auto, là on a une procédure équivalente pour le partage manuel des clés en une seule étape (import, vérification) via un unique fichier (un peu plus gros qu’auparavant). Dans les deux cas on est moins dépendant des serveurs de clés classiques qui ont montré leurs limites. 

Après la vérification d’une clé publique nécessitera toujours de s’assurer de leur véracité selon le besoin et le niveau de confiance que l’on peut leur accorder. C’est le cas tant pour OpenPGP que d’autres solutions comme Signal & co par exemple. Et même si ce n’est pas toujours très visible dans les applications plus modernes, ça n’en reste pas point nécessaire et complémentaire.

La vérification d’une signature est une chose (numérique), s’assurer qu’une personne est bien qui elle dit être, une autre (qui se confirme en général en physique).

AstroB33 Abonné

Le 23/03/2020 à 17h26

Je ne comprend pas l’intérêt du cas où la signature est intégrée au message. Si un main in the middle intercepte le message, le change + met ça propre clé dedans, le récepteur ne peut jamais s’en rendre compte., si?

David_L Abonné

Le 23/03/2020 à 17h42

C’était déjà le cas avant, c’est pareil si la clé d’un WKD est modifié sur le serveur ou pendant un transport non sécurisé (mais de mémoire WKD nécessite HTTPS). Mais bon, la sécurité du canal de communication, c’est le job de TLS, pas de GPG. 

Une signature cryptographique n’assure que d’une chose : qu’un message correspond à une signature. Je peux très bien envoyer un message depuis [email protected] avec une fausse signature correspondant à cet email à n’importe qui. En vérifier la conformité ne veut pas dire que ça vient de Bill Gates.

johanns

Le 23/03/2020 à 19h41

c’est un truc que je trouve très cool chez protonmail, il y a l’option d’attacher automatiquement sa clé publique lorsqu’on envoi un mail à un utilisateur hors de la plateforme suisse.

le hollandais volant Abonné

Le 23/03/2020 à 20h10

AstroB33 a écrit :

Je ne comprend pas l’intérêt du cas où la signature est intégrée au message. Si un main in the middle intercepte le message, le change + met ça propre clé dedans, le récepteur ne peut jamais s’en rendre compte., si?

Non, car le MITM ne peut pas déchiffrer le message lui-même pour le changer : pour ça il a besoin de TA clé privée, qu’il n’est pas censé avoir.

Il peut bien mettre sa clé à la place de celui de l’expéditeur, mais dans ce cas la signature ne marchera plus.

Mihashi Abonné

Le 23/03/2020 à 21h59

Bah si vu qu’il a la clé publique…

David_L Abonné

Le 24/03/2020 à 05h17

johanns a écrit :

c’est un truc que je trouve très cool chez protonmail, il y a l’option d’attacher automatiquement sa clé publique lorsqu’on envoi un mail à un utilisateur hors de la plateforme suisse.

Oui mais tu n’apporte pas de solution au problème de l’import. Même si ça peut se faire côté client, autant le gérer le plus nativement possible. Là l’idée est de permettre au client qui reçoit la signature d’y trouver la clé publique sans autre fichier nécessaire et de pouvoir tout valider directement selon une procédure standard.

 

le hollandais volant a écrit :

Non, car le MITM ne peut pas déchiffrer le message lui-même pour le changer : pour ça il a besoin de TA clé privée, qu’il n’est pas censé avoir.

Il peut bien mettre sa clé à la place de celui de l’expéditeur, mais dans ce cas la signature ne marchera plus.

Si MITM il y a il peut tout changer : la clé, la signature, le message. Par contre il ne peut pas récupérer le contenu du message d’origine. C’est pour cela qu’il ne faut jamais oublier pour quoi on utilise une couche de sécurité. C’est comme HTTPS et le phishing. Ce n’est pas parce qu’il y a un cadenas vert que le site n’est pas malfaisant. Ce n’est pas parce qu’un mail est signé de manière valide que l’expéditeur est qui il dit être.

Mihashi Abonné

Le 24/03/2020 à 10h48

Mihashi a écrit :

Bah si vu qu’il a la clé publique…

David_L a écrit :

Si MITM il y a il peut tout changer : la clé, la signature, le message. Par contre il ne peut pas récupérer le contenu du message d’origine.

Petite correction par rapport à mon message précédent, le MITM peut récupérer le contenu du message d’origine seulement s’il n’est pas chiffré avec la clé publique du destinataire (ce qui dans le cas d’un premier échange de clé arrive forcément, non ?).

David_L Abonné

Le 24/03/2020 à 12h18

Oui, mais ce que je veux dire, c’est qu’en cas de MITM dans un échange non chiffré avec un tiers inconnu, ce n’est pas le rôle de GPG que d’assurer la couche de sécurité.

Mihashi Abonné

Le 24/03/2020 à 12h31

Tout à fait. Lors du premier contact (non chiffré, forcément), il faut vérifier l’identité de la personne que l’on croit contacter en utilisant un autre moyen.

Ça serait d’ailleurs intéressant, je pense, de l’indiquer dans la dernière partie de l’article.

le hollandais volant Abonné

Le 24/03/2020 à 14h30

Mihashi a écrit :

Petite correction par rapport à mon message précédent, le MITM peut récupérer le contenu du message d’origine seulement s’il n’est pas chiffré avec la clé publique du destinataire (ce qui dans le cas d’un premier échange de clé arrive forcément, non ?).

Tout dépend de comment l’expéditeur récupère initialement la clé publique du destinataire, en effet.

Mais je rejoins David là dessus : ceci n’est pas le rôle de GPG. C’est à l’utilisateur de faire attention. C’est là qu’interviennent les niveaux de confiance des clés publiques qu’on reçoit.

Mais si on considère que l’expéditeur possède la bonne clé publique et que la privée est bien privée, le message chiffré est SÛR (tant que la crypto derrière GPG ne sera pas tombée, évidement).

Un MITM ne peut rien faire si ce n’est le rendre indéchiffrable.