Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

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
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) :

-----BEGIN PGP MESSAGE-----

owGFkms00wsAwPffZpvNsrXMKwylu7qJpZB5TolCu+il0VozUx6rcXVKIWFWDYkk
kUu3Jg1hGxVDRF6X1DzypqjreWQobvee07l9uvfj78Pvy+/8EtEQEAKgCnAvbvmw
9IFHmicQXGY415gbzvUJf2NMCQ5lBIcS9AloJA8GhYIABHQSrw8NVNVK35n8eM2T
qUbYd1cJ/LdQq2oESgfQUJ/wDj8AAaqc0UWrkDAul7EeRN3erAvp3Q3eKyPLBN3U
zMsfLd2UGhItSQPkbYw8HjrmM0cLOFXHJ92KU2zBlUWjeuqZN4MQ4vpFljUlwuvk
6pcij/4UmeLotqD9W9EG7AOSOUKsQY5JhSnWfMjQaGggs6pgirGlV3HderGVUzeC
fHtFR0diJjJf0jAT2uZvJ95brEtst2YfDL2548YxGrHPdWUmXojmRYg1x3s9lhbB
t+Mh5+Q2BlfrY107+ntgk1m5Is4SIKesXjWwF7+hCYv4GZOYhZlee4O9GHq9ljfh
Kyqh3Xq5yBnudyJsuWnd263DxbJyH6sQBG+TCTXJaWN+mCYIC4CAEm0XJj2I4Mik
h/oTyIFMu4BvePIbGPudseEBnlDct1I2/5G1ww+sDVFShlSzQEooZQQcDFNDKiNQ
YCgeDAHAugBYPRKEVMZ8V5QZ8C9o6pKY1DKb42jNoyzYe/3hZ5Xahg75vbXq/QT8
wzqkl6+3m/ZD30FUp1oTJRETObQQ5GZU+hBoKZS9eLZYeCB6aHS0+IqO5uZ9geJJ
gmES87ITZy7jTMT8agLbufNPzhiWMlyHlj5Zq+II3nTM4n1hy2AGlrF7QEs+YWsr
jCoWmC4NUfhEHrDQH3wgQzGft7Gmpvi9xaJgR4WV6WQI6izkgZOD4SbTbH1ql776
xsIEG+Rb9kWV+P2SJfvWqof1qpkDX19lexDcWWtQ56prgqwTe93ybKi5YXIdzLsY
UlIzzNwOuV9esEclI0a6K9yT6ZZ0aujXbrbXy/A3s60Bj05L/31Q8mQGgrvUees+
aJuJ+JNKQZtjSzcrvevlsI4UNx57YUwgD4gH3tGu0TvsA7o1mss4m+gH9JRe2yyk
JviOJZff5dJGZgY+KzdsHNfjm6f2iidJd+D2r8JBp1fOwU5URx0rqX2QovroeqPd
pf7khUMyJ18caVpGzZMdhZ94uqvE7vrhpHLF0bDZRjeXrbq0jFcl7+5VcGcKYnbN
9d9Angl4VhritX1icO55hdrZqNxy9XjNj9T19PyieuH0rBKVZWv59DYqOJp67Cod
jMs/iasBREa8Q7hnhyBpgxM9dxNvxUEx3bAlgefjMUpIpXdZd05oS2kcqq35tpjb
tnu2GWUi+udBHrATqvEtBuF/NlP5cSRaPgJUUnxtvpntbHmZJCDI1/CaKyOzZ3/Z
8LVpvf906yC/dtL2jMUYKHq1X3uE33dF2K7hz92ni/f1dhSpPwhdH224a49Ws63o
pas/jR7c/gbrmUbGkdNEK4nE5Y47r8sg8M0CYZpOzJMk7BHP41jrD2TVu/HEIIY2
aZqiGb/PlmgW5q7XsLZ2tV2SwyGBWEXR0V3GeyPnAGJb0TkHN+UKGeGL3CcLkpSe
o6LfGmb8GpVox7YSNknWMex6+Aw8+aJefSWlptaz1IdmOfFVg70lK/ZQteN5wbVG
zh3X3aPglGcNtQ0uXryG0P4bUemS7TZk8vCGqsC+7cFfAkyTiPNDnT/2GDeBr7LU
+ubBR5kKJZFz43Ff+silzp+g8squKeu08IzzGiDGdI/xwcy4dBt8ZgRsbe7wuNXc
7QhC/tRhk5cepeUys7L5sP75PJHfYWMN0JGWp+u5qS+ULrYP4PFtXNnZuFGpqcOe
re+q1jpGl9O6ugtKKuC7EYEWSJawtFzks5ie+2Gvv245zOk+Fh6gtW7KFiLFq6m2
gJ3cFb9lX5KOjPZqcTfvx4O94Aqe5IX0eZfQ/jFE6sI57M6vUP90vwcrdvUe+XlY
3V2SzdS4sAeDqc/yrjZY5a9xKMhOmetkbqhbJtFZbK1ThitmlgqBRYQReXPIjGpU
snNnYUxTam4+Xeb+Fw==
=AIgB
-----END PGP MESSAGE-----

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

-----BEGIN PGP MESSAGE-----

owGbwMvMwMEY2C98dEZcuiLjGskkjpLUihK9koqSuIprMc75pcn5pQqKCrxcnYzG
LAyMHAyyYoosufxSM80mrePb/P4UG0wvKxNIAwMXpwBMZM5EDoZFSa3ORUuc7hnd
l5AKXGFx4aTizLUBoqqFe23KzixQWm8s9Xtik0oE58n+5wJMy5g7wz8+XrjW+vTP
qzqfH/JOSnnOdWvXqc+xP7Ykb7/ds6v8ud6klM/pm7rz49q265XJtQdVPnv/cn/L
nEs6a/a0X7WzP93m5qZ4gmX9DZ3fMy86qrC99+5eMPVDvs1rhQdlExf43FRUO5Z7
Yd3UcsEPaw1j4nmL2c1ZaoqbPhaaeFVoiXL56z7arFUw9fKEfYtudAQAtR7VKTte
+Hz3Kb+T50O+ztgoGsS5u2vWzzRWs4TPxv+CJ7hebnu0d+L5Nx+EnbfEPt5/5WWx
fdzb+K1BU5junS2beEJE9fjG5rUA
=UFLB
-----END PGP MESSAGE-----

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 :

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBF5402YBCAC/8R4NDDIQSoMRUyke3J98mdrJW/7k+yAelp2D6zlOBcmQOTLg
PC9jpYkNhPZxGgFrxosymIf4KxO2ggvbx2WVbgi3x/lnPUN9VWT//LFT35TB+Fov
bkwtDSJpULjzIIYiojC7MRE34iMm4uCdwK3vYyvc+I49+c9xxuQK14UdHbg0rzf6
GDSqP6szKaH5xpDSPWlWdZU1k1xdKd5N/vGIqg2JfbcZ6dxT+vkCmogDedg+IozH
hk3T39sG7p+kr3H6AdhD/4wiQbfWXaqxi5vuEPfx3EEiSBBhxxpbIP0LitI9+7FJ
B2ZidvvMFNct47LBul47cAiJJzBRkUclq3YZABEBAAG0G0plYW4gRGVhdWggPG1l
QGplYW5kYXVoLmZyPokBVAQTAQgAPhYhBG0PGpk2kq4Os+/KBlGPE8WYXmchBQJe
eNNmAhsDBQkDwmcABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEFGPE8WYXmch
CWMH/A1R+rcyzvKiRD2JQ/dBVdFmO5bQDXCnz8Dn6gfoFApVX1tOG6lf4QvVFcxD
kBCA4vduTia1qQHOsMHFvfmwUILi5eWyhR0ZKkttt+4gI5Flg0dx85tyffX/imlJ
1e1x5hFD48YNubMSDEQCJ1w457DO4ZsRY0XgGtjqPz+qgbKPMfriQ4spiQH3329Q
m/j1pSXDw7LnOPmPNbs7Me5wC3MDqEdCIycxoCFR2SEXJbCKPgrXaX4MiEy4+kHP
wKnHD53g/cugUyBPZw4LecLDbj2Q3E6lPlGkdtgdEN2EMpHNBjdACkzYrUYMm4S5
OnhUZU6Ra+J32mlVyHjW8s9qrGy5AQ0EXnjTZgEIALiz8QMTf9WYpgAvMLfsDK3Q
RM7aZ5nZyOMduRPphnzmj9hqiAHdXY1h00Fq2hjNtnEnYVAfBdQ+95aKX+aSup50
XeTx4PYJySXpH4s3lty37jKcB0HLeABs/nkGYsKBXLTEqJQPrI7KQH/fkvdXwUdf
EzLwwVGlwVoHYrw6tECOWJG6+Fp28spOSi0eXZvLtN2hu3TxrYQ689+TCnJqvbVw
VTPq4fO+uxVzgaS6F4gZ61EcYauxx6rw8gVRZz85vJoLb4JRXIxhAhOrZBPDAa8m
iVcTvVcDl+Hq256QmIcEENoG+o9UruZDcL9bttqidc61hwvQzZq3dNBF8s0LMK8A
EQEAAYkBNgQYAQgAIBYhBG0PGpk2kq4Os+/KBlGPE8WYXmchBQJeeNNmAhsMAAoJ
EFGPE8WYXmchXasIALSyjfXNaUk5gzKPINgOic2/gKDyUiT9zBxo8M/hi8TuP3I4
5gCC/98b5IveharSGGh0Sx4WX1tErxeodRyCIzpGGs0/r8hNaF1hb9LWEVSXPBM8
l6/+kCn705zUtgMHKo+qlx2Es5ERWVRgET3oPA+eiCluYxsy8EMZiEs/KTR2Tx/J
EsT/0riicTIAZ7GCgtkuSIDzASnQsXlCTgm7wSD82F6fA5GZogwhz3Yu1AuQQGk7
qsy4FGNA24tjFjx+H8e/Q8PEVLVeXTnq/RhpK5+GV8JEe4+NynGcTUXlApS9ycTJ
SlWJyXXfk4GZuDM+PDzjJMBt3jNv/GoxkSn14tU=
=HHMg
-----END PGP PUBLIC KEY BLOCK-----

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.

19 commentaires
Avatar de glacasa Abonné
Avatar de glacasaglacasa- 23/03/20 à 17:12:15

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.
 

Avatar de David_L Équipe
Avatar de David_LDavid_L- 23/03/20 à 17:22:46

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).

Édité par David_L le 23/03/2020 à 17:24
Avatar de AstroB33 Abonné
Avatar de AstroB33AstroB33- 23/03/20 à 17:26:57

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?

Avatar de David_L Équipe
Avatar de David_LDavid_L- 23/03/20 à 17:42:47

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 bill@gates.com 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.

Avatar de johanns INpactien
Avatar de johannsjohanns- 23/03/20 à 19:41:37

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.

Avatar de le hollandais volant Abonné
Avatar de le hollandais volantle hollandais volant- 23/03/20 à 20:10:34

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.

Avatar de Mihashi Abonné
Avatar de MihashiMihashi- 23/03/20 à 21:59:37

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

Avatar de David_L Équipe
Avatar de David_LDavid_L- 24/03/20 à 05:17:47

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.

Édité par David_L le 24/03/2020 à 05:18
Avatar de Mihashi Abonné
Avatar de MihashiMihashi- 24/03/20 à 10:48:01

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 ?).

Avatar de David_L Équipe
Avatar de David_LDavid_L- 24/03/20 à 12:18:05

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é.

Il n'est plus possible de commenter cette actualité.
Page 1 / 2
  • Introduction
  • Générer une signature en intégrant sa clé publique
  • Signer un message avec intégration de la clé publique
  • Vérifier un message avec la clé publique intégrée à la signature
  • Une nouvelle procédure intéressante
S'abonner à partir de 3,75 €