GnuPG 2.2 est disponible : des changements majeurs, notamment pour la distribution des clés
\o/
Le 29 août 2017 à 06h00
10 min
Logiciel
Logiciel
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-grab
est activé par défaut pour éviter les attaques de type X-Sniffing--disable-dirmngr
permet de désactiver complètement les accès réseau de GnuPGshow-only
peut ê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é :
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 [email protected]
, 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.
Le 29 août 2017 à 06h00
GnuPG 2.2 est disponible : des changements majeurs, notamment pour la distribution des clés
-
gpg2, c'est fini
-
La révolution est dans la distribution
-
TOFU et Web Key Service, c'est le turfu !
-
La récupération automatique pour vérifier une signature
-
La récupération automatique pour chiffrer un message
-
La simplicité n'est pas la sécurité
-
L'objectif final : motiver les hébergeurs et les services de messagerie
Commentaires (40)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 17/08/2017 à 08h06
#1
Bref, ils ont automatisé ce qu’on fait tous quand on veux chercher une clé (ou un md5, ou une adresse email…): on va chercher l’information sur le web à un endroit qu’on considère arbitrairement “de confiance”.
Bref, c’est la mort du “Web Of Trust” et le retour du “I Know What I’m Doing”.
Le 17/08/2017 à 08h15
#2
Bravo, tu viens de découvrir la différence entre un standard et la bidouille " /> Pour le reste, tu as du mal lire, puisque ce n’est en rien la mort du WOT, mais plutôt un complément pour la phase de découverte qui reste un des points de friction essentiel (sans pouvoir remplacer le modèle de confiance sur le fond)
Le 17/08/2017 à 08h45
#3
Hmm…. Pas d’accord.
“WoT = establish the authenticity of the binding between a public key and its owner.”
Laisser le logiciel télécharger une clé depuis une URL quelconque (qui n’est même pas une Autorité de Certification ou un site ayant pignon sur rue) n’apporte aucun niveau de confiance
https://davlgd.fr/.well-known/openpgpkey/hu/s8y7oh5xrdpu9psba3i5ntk64ohouhga
WHOIS davlgd.fr
nic-hdl: ANO00-FRNIC
type: PERSON
contact: Ano Nymous
remarks: ————– WARNING ————–
remarks: While the registrar knows him/her, this person chose to restrict access to his/her personal data.
remarks: So PLEASE, don’t send emails to Ano Nymous.
remarks: This address is bogus and there is no hope of a reply.
remarks: ————– WARNING ————–
registrar: OVH
changed: 04/01/2011 anonymous@anonymous
anonymous: YES
La seule chose qui me donne confiance dans le lien que tu as donné, c’est qu’il est posté dans une news rédigée par ton compte sur le site nextinpact.com. " />
Le 17/08/2017 à 09h20
#4
Le pire c’est qu’on est d’accord. Je reprend tes terme entre guillemets:
Moralité, tu as confiance dans l’adresse email et tu peux techniquement utiliser GPG pour écrire a cette adresse email => pourquoi se faire chier avec le WoT dans ce cas ?
Le 17/08/2017 à 09h27
#5
Moi je balance ma clé GnuPG dans l’enregistrement TXT de mon DNS. " />
Le 17/08/2017 à 09h30
#6
WKD n’est pas une question de confiance, mais de distribution. Cela permet d’automatiser le processus de premier contact à travers un canal sécurisé et simple à mettre en place.
Le WOT permet de vérifier qu’une clé (et non un email) et certifiée par d’autres ou non, et éventuellement de la certifier soi-même si on a pu la vérifier d’une manière ou d’une autre avec la personne concernée. Tu peux récupérer une fausse clé via WKD si le serveur est compromis.
Le WOT est là pour te permettre de t’en apercevoir simplement ou au moins de douter de la véracité de la clé si aucune certification tierce ne vient la confirmer, et donc de procéder à des vérifications complémentaires.
Pour rappel, l’email est une partie d’une identité d’une clé, pas son élément principal. Tu peux avoir 50 clés avec différentes identités et parfois une même adresse email.
Le 17/08/2017 à 09h31
#7
Et personne n’a de moyen simple de la récupérer (de mémoire GPG proposait une méthode de récupération du genre via PKA mais elle a été dépréciée il y a un moment)
Le 17/08/2017 à 09h37
#8
Le 17/08/2017 à 09h43
#9
Tu peux diffuser déjà ta clef via un enregistrement DNS / DANE (avec les paramètres cert, pka ou dane de l’argument –auto-key-locate). Après il faut juste disposer d’un serveur DNS qui le propose (pas franchement pratique à gérer soi-même) ou d’un hébergeur qui le permet (rarement le cas). C’est notamment pour ça que d’autres pistes ont été creusées comme je l’explique dans le papier, même si DANE reste un élément qui est dans le scope de ce que prévoit l’équipe de GPG via le protocole WKS (voir les slides)
Le 17/08/2017 à 09h49
#10
Le 17/08/2017 à 09h57
#11
Pour ma part, je trouve que tout ca reste de la bidouille avec des idées/technos faites maison et les incohérences qui vont avec.
Du genre la clé doit être vérifiée par un moyen externe, mais WKD requiert une connexion https pour empêcher toute altération de la clé au moment de sa récupération. Pourquoi s’assurer que la clé est inaltérée si on doit de toute façon la vérifier ?
Du genre fabriquer la well-know URI avec Z-BASE-32(SHA1(LowerCase(LocalPart($email)))).
Y avait pas plus simple/standard en 2017 pour construire une URL ?
Même si c’est louable de travailler sur le sujet épineux du combo identité+confidentialité des internautes, la complexité du truc m’incite à croire que tout cela sera balayé par une solution clé-en-main fournie par un GAFA. Dommage…
Le 17/08/2017 à 10h26
#12
Tu vois de la bidouille là où il est simplement question de couvrir les différents angles. Si tu mets un gilet pare-balle pour te protéger et qu’on te coupe la tête à la machette, cela ne veut pas dire que le gilet était inefficace hein ;)
Le lien chiffré permet de s’assurer d’une protection pendant le transport de la clef, pour éviter certains types d’attaques, tout en permettant ce qui est le but de WKD : une récupération rapide de la clef pour une adresse email donnée. Tu peux trouver cette solution suffisante, et t’arrêter là, c’est une possibilité. Personne ne t’oblige à faire plus.
Mais si tu veux t’assurer de la fiabilité de la clé via des tiers et sur le long terme, le WOT est une source d’info fiable et distribuée. C’est complémentaire, ça vise d’autres besoin. Penser que WKD est là pour assurer la confiance, c’est un peu comme ceux qui pensent que les préservatifs sont un moyen de contraception, alors qu’il s’agit d’un outil de lutte contre les MST, qui peut en partie faire office de moyen contraceptif (sans être totalement fiable, voir le cas de Ross Geller).
Pour le reste, tu oublies une dernière chose : le protocole WKS est pensé pour une intégration complète à un service de messagerie. Si ce dernier fait le taffe, l’utilisateur ne voit presque rien. Là on propose seulement un moyen de publier simplement une clef (mon Dieu il y a un ID à copier/coller) pour ceux qui veulent exploiter WKD en attendant que des services de messageries (et pourquoi pas un des GAFAM ?) commencent à l’intégrer de leur côté :)
PS : Même Signal propose un contact rapide, à compléter par une vérification visuelle des empreintes via un QR Code. On peut ne pas le faire, mais on s’expose. Comme toujours, c’est une question de choix personnels et de modèle de menace. Chacun voit midi à sa porte, l’important étant que les outils permettent de se protéger complètement lorsque c’est nécessaire.
Le 17/08/2017 à 10h42
#13
Le 17/08/2017 à 10h45
#14
Le 17/08/2017 à 11h02
#15
Raté :
3 000 ans av. J.-C. les soldats égyptiens souhaitant se protéger des maladies vénériennes utilisaient des boyaux de mouton ou des vessies de porc.
Extrait de l’article wikipedia.
Ce même article présente le préservatif à la fois comme un moyen de contraception et de protection contre les MST.
Si David a des informations sourcées (ailleurs que dans une fiction) qu’il corrige cet article. En fait, c’est logique, il n’y a pas de raison que la protection soit meilleure dans un cas que dans l’autre puisqu’elle est sensée arrêter les même fluides .
J’arrête la digression, mais, on voit que les analogies, c’est toujours casse gueule.
Le 17/08/2017 à 11h21
#16
Le 17/08/2017 à 11h25
#17
Le 17/08/2017 à 12h04
#18
Le 17/08/2017 à 12h08
#19
“Promis ! on l’implémente après la sortie d’Half-Life 3” " />
Le 17/08/2017 à 12h10
#20
Tu sembles quand même oublier que GPG est largement utilisé dans plein de domaines. Après, dans le cas de l’email (surtout pour le grand public) ce n’est pas courant, mais c’est un cas d’usage parmi d’autres :)
Mais c’est justement l’objectif que de partir sur un protocole simple à implémenter et simple d’usage pour l’utilisateur final. Après c’est comme tout, chacun en fera ce qu’il en voudra :)
Le 17/08/2017 à 12h19
#21
Le préservatif n’a qu’une action physique alors que la pilule ou le sterilet agissent sur 2 à 3 points (ovulation, glaire cervicale, endomètre) qui conduiront à empêcher la nidation et donc la grossese. C’est pour cela que l’indice de Pearl du préservatif et plus élevé que celui du sterilet ou de la pilule.
https://fr.wikipedia.org/wiki/Efficacit%C3%A9_des_m%C3%A9thodes_contraceptives
https://en.wikipedia.org/wiki/Comparison_of_birth_control_methods
On peut dire que le préservatif est efficace en contraception ponctuel et quand on une recherche une efficacité sur les MST grâce son effet barrière sur les “fluides”. Mais quand tu n’as pas besoin d’une protection contre les MST (partenaire unique monogame de plus 3 mois), il existe des moyens contraceptifs bien plus efficace (malheureusement la contrainte repose sur la dame).
Le 17/08/2017 à 12h23
#22
Vous utilisez GPG dans le cadre de INpact Mediagroup ou de la Presse Libre ?
Perso, le seul endroit où j’ai remarqué une adoption de GPG c’est GitHub. Et encore, ca reste limité pour un site qui regroupe des profils techniques en matière de logiciel. Par exemple Linus Torvalds ne signe pas ses commits.
Le jour ou github (ou fb, ou google) imposera GPG a tous les comptes utilisateurs, alors là je reprendrais espoir dans l’adoption de ce standard.
Le 17/08/2017 à 12h57
#23
Le 17/08/2017 à 13h05
#24
Les “initiatives” sont surtout des services spécialisés… il ne s’agit pas d’adoption du standard par des services mainstream.
Comme dit juste avant, si demain Gmail et Outlook imposent GPG a tous les comptes utilisateurs et que FB/Twitter/G+ deviennent des Web Key Directory alors on aura fait un grand pas dans l’adoption du standard. Sinon, j’ai bien peur que ca reste un truc de nerd sécuromaniac.
Le 17/08/2017 à 13h14
#25
Note que Facebook propose déjà un support de GPG avec chiffrement des notifications envoyées par le service et publication de la clé publique :)
Le 17/08/2017 à 13h30
#26
Le 17/08/2017 à 13h35
#27
Oui, Facebook gère également l’Esperanto. Mais je n’ai pas vu une adoption massive de cette langue depuis ce support… " />
Le 17/08/2017 à 15h01
#28
Je me rappelle plus bien de la gestion des versions : GuPG 2.1.23, c’est celle avec ou sans porte dérobée ?
Le 17/08/2017 à 15h27
#29
Pour le modèle de confiance, c’est TOFU
Bravo, maintenant j’ai faim…
Le 17/08/2017 à 15h31
#30
Avec ce nom, ça doit être avec porte dérobée. Un logiciel Gnu, au contraire, tu as les sources, la porte dérobée est plus difficile à cacher.
Le 17/08/2017 à 15h39
#31
Rappelons la campagne de financement pour GnuPG " />
Le 17/08/2017 à 16h32
#32
Le 17/08/2017 à 20h55
#33
Ont-il ajouté une fonction pour chiffrer un fichier directement avec une clé publique sans l’ajouter dans un trousseau ? Un peu à la manière du chiffrement symétrique proposé avec cette commande :
gpg2 –output CHEMIN_DESTINATION/NOM_FICHIER.gpg –symmetric NOM_FICHIER_SOURCE
Ce serai super utile pour un usage avec des livecd ou simplement pour ne pas laisser de trace sur la machine que l’on utilise (clé privé sur une clé USB chiffré).
Le 17/08/2017 à 21h22
#34
Le principe du symétrique, c’est qu’il n’y a pas de clé, du coup c’est un peu logique qu’elle ne soit pas ajoutée à un trousseau. Après rien ne t’empêche de supprimer la clef publique ensuite ou d’utiliser un trousseau temporaire avec –primary-keyring, mais j’ai du mal à comprendre quel est le souci dans le fait de stocker une clef publique pour assurer le chiffrement d’un fichier.
Le 17/08/2017 à 22h09
#35
Non, je ne pense pas qu’il y ait (enfin) un mode d’utilisation sans fichier keyring.
Par contre, on peut facilement créer/travailler avec un keyring temporaire (option –primary-keyring, ou meme –homedir).
Il faudra juste penser à supprimer le fichier keyring à la fin.
Edit: grillé par le chef. Ca m’apprendra a pas rafraichir mes onglets. " />
Le 18/08/2017 à 10h25
#36
Le 18/08/2017 à 15h01
#37
Du coup je comprends pas, tu veux faire de l’asymétrique mais sans clé à importer ? (Je ne vois pas le rapport avec la doc au passage).
Le 19/08/2017 à 09h18
#38
Le 19/08/2017 à 09h23
#39
Mais en fait ce que tu veux faire est déjà possible, sauf que tu n’indiques pas l’emplacement d’une clef publique mais d’un trousseau (ce qui revient fondamentalement au même puisque c’est juste un emplacement de fichier)