Suite à l’annonce de notre 4e OpenPGP Email Summit, cet article fournira un bref aperçu de cet événement. Nous avons collaboré avec un certain nombre de personnes impliquées dans différents projets OpenPGP, des universitaires et d’autres personnes soucieuses de la sécurité de la messagerie/de la vie privée. L’ordre du jour de ce 4e OpenPGP Email Summit incluait des discussions en séance plénière, des séances publiques (c’est à dire, des groupes de travail), une soirée signature de clés, de la nourriture et des boissons et bien sûr, beaucoup de fun.
Ce qui suit est un résumé des différents points qui ont été discutés lors des discussions en séance plénière et des séances publiques. La plupart du contenu est très technique et n’intéresse que les développeurs de logiciels liés au courrier électronique OpenPGP.
Séances plénières et séances publiques du 4e OpenPGP Email Summit ( 20/10/2018) – Jour 1
OpenPGP : conférence en séance plénière
de Phil Zimmermann
– OpenPGP nécessite beaucoup d’améliorations. Travaillons à ces améliorations.
– Débarrassez-vous des versions primitives cryptographiques vieilles et obsolètes du protocole, et utilisez les algorithmes et les designs cryptographiques modernes, bien étudiés et ne faisant l’objet d’aucun brevet, lorsque vous avez recours au protocole (TLS 1.3 peut en être un bon exemple).
– Chacha20, Poly1305 et AES ne sont que quelques-uns des bons algorithmes (ils n’apprécient pas le mode Galois/Counter, cependant).
– Vérification de la clé : le modèle de confiance OpenPGP est difficile à expliquer aux utilisateurs non techniques. Nous vérifions les empreintes digitales des clés publiques à l’aide de différents canaux latéraux, ce qui n’est généralement pas pratique. Les empreintes digitales des clés publiques peuvent être transférées via d’autres supports sécurisés (par exemple, WhatsApp / Signal /…) ou le protocole ZRTP & Signal (par exemple, Silent phone). L’idée est d’utiliser d’autres supports/systèmes en plus d’OpenPGP pour exploiter (renforcer) la confiance, au lieu du modèle de confiance actuel de PGP.
– Manque d’effet réseau dans OpenPGP : en grande partie en raison de la complexité opérationnelle, nous n’avons pas réussi à atteindre davantage d’utilisateurs. Dépassons cela en prenant des exemples de systèmes qui ont déjà exploité avec succès l’effet de réseau.
– Nous attendons avec impatience les personnes qui auront l’ambition d’améliorer / de moderniser la norme OpenPGP.
Réflexions sur l’intégration de la cryptographie post-quantique
– Nous devrions également commencer à utiliser la cryptographie post-quantique dans OpenPGP. Le temps est venu.
– Les clés post-quantiques peuvent être énormes. Ne transportons pas les clés, mais plutôt les empreintes digitales, et téléchargeons les clés à partir de serveurs de clés de nouvelle génération.
Aller de l’avant
– Norme actuelle RFC4880; Nouveau projet de norme RFC4880bis; Groupe de travail: https://tools.ietf.org/wg/openpgp/
– Supprimer les primitives cryptographiques vieilles/obsolètes : chiffrements, algorithmes de compression,…, et autres choix de conception (par exemple, remplacer MDC par AEAD).
– Éliminer les éléments obsolètes, réduire autant que possible tout en intégrant les points d’amélioration dans le cadre syntaxique existant.
– Utiliser des primitives cryptographiques modernes (par exemple, seules les paires de clés basées sur ECC-curve25519 pour les nouveaux utilisateurs,…). Supprimer la prise en charge de l’ancien (par exemple, supprimer l’option pour générer d’anciennes clés basées sur un chiffrement,…) et avancer dans la bonne direction.
– Demander aux fournisseurs de logiciels OpenPGP de maintenir leur implémentation à jour dans les appareils des utilisateurs (par exemple, utiliser une sorte de mise à jour automatique) et inciter les utilisateurs à mettre à jour leur paire de clés en supprimant l’ancienne clé (si nécessaire).
– L’univers OpenPGP n’a pas été bien géré, nous devons le moderniser. Cela demandera beaucoup de volonté politique.
D’autres exposés informatifs ont également été présentés sur les projets AutoCrypt, DeltaChat et NextLeap (pour empêcher les attaques de type MITM) par leurs propriétaires/membres respectifs.
Session OpenPGP : serveurs de clés SKS
Discussion animée par : Kristian Fiskerstrand
– Pools de serveurs de clés: https://sks-keyservers.net/overview-of-pools.php
– Sujets traités : Nouvelles exigences en matière de pool, Suppression des ID utilisateur pour des raisons de confidentialité, Amélioration des performances du serveur de clés.
– Le pool de serveurs de clés contient actuellement 5 serveurs gérés par 2 opérateurs.
– Quelles données le serveur de clé doit-il contenir ? Faut-il stocker les ID des utilisateurs ? Ne devons-nous pas autoriser les signatures de confiance externes sur les serveurs de clés et utiliser un service différent pour cela? SKS doit-il uniquement répondre aux empreintes digitales ?
OU nous devrions rendre tout cela facultatif?
– D’autres problèmes d’équilibrage de charge existent également.
– Pour que l’on ne rende pas les serveurs de clés délibérément ignorants pour fournir la bonne clé, devons-nous effectuer les opérations cryptographiques (par exemple, vérifier les signatures de confiance et prendre une décision raisonnable) ou renoncer à ce que le serveur de clés gère cette fonction pour la confier à un service externe ?
– Les implémentations alternatives (non-OCaml) sont également les bienvenues (de préférence avec des exigences minimales).
– Autres mécanismes de découverte de clé : WKD (https://wiki.gnupg.org/WKD), serveur de clés Mailvelope, etc.
– Vous souhaitez connaître les réactions de la communauté à ce sujet.
Pour connaître le suivi: Mailing list openpgp@ietf.org (https://www.ietf.org/mailman/listinfo/openpgp)
Session OpenPGP : Autocrypt level 2
Discussion animée par : Patrick Brunschwig
– Discussion sur les éléments à synchroniser (clé privée: message de configuration de cryptage automatique, état de cryptage automatique, carnet d’adresses, routage alternatif, préférences générales de client de messagerie : signature / HTML /…, politique de définition de règles, jeu de clés publiques, règles de filtrage, balises, etc.).
– Propriétés: Facile à utiliser, authentifié & confidentiel, en cours, automatiquement, plus de deux appareils,…
– Options pour réaliser la synchronisation: protocole Kolab, mécanisme d’appariement, services interagences : protocole de messages de groupe, perte de message de couverture.
– Risque / effets secondaires: aboutir à la synchronisation vers un périphérique avec lequel on souhaite se synchroniser (éviter les accès filaires), suppression / duplication, échec de la synchronisation (suppression de clés,….), Mouvement latéral après compromission.
– Séparer en plusieurs couches: définir le mécanisme d’appariement et de synchronisation (comment établir une authentification, ne pas canaliser la syntaxe à synchroniser,…), le stockage (IMAP, NextClout, Gdrive,…), Que faut-il synchroniser ?
– Compteur MITM: vérification de clé en personne basée sur le code QR de la clé publique (automatisé avec des jetons d’authentification), temps d’arrêt dans le flux de vérification (non encore planifié, à discuter), clés séparées stockées pour différents contextes (groupes ou . 1:1), toute la clé doit changer si un élément de la clé est modifié.
– Cryptage automatique et Webmail : intégrez Autocrypt (par exemple, Mailfence, Mailvelope). Autocrypt ne définit pas les techniques de mise en œuvre et laisse généralement ce choix à l’exécutant afin qu’il effectue les meilleurs choix dans son architecture d’application.
– Bien qu’Autocrypt ne le nécessite pas, les fournisseurs de messagerie Web signent les en-têtes Autocrypt à l’aide de la technologie d’authentification DKIM pour assurer leur intégrité.
Session OpenPGP : Méthodes de découverte des clés multiples
Discussion animée par : Daniel Kahn Gillmor
– Les méthodes de découverte de la prise en charge de clés multiples du MUA (Mail User Agent, ou client de messagerie) : comment les gérer et comment utiliser différentes réponses de découverte de clés à partir de différents emplacements pour prendre une décision logique/raisonnable quant à l’utilisation de la bonne clé?
– Méthodes de découverte de clé existantes: Autocrypt (par courrier électronique), WKD (par courrier électronique), SKS pool (par courrier électronique/keyid/fpr), le serveur de clés Mailvelope (par courrier électronique /keyid/fpr), LDAP (par courrier électronique/keyid/fpr), DNS (par email), Garbage pile par Kai & PEP (par email/keyid/fpr), keybase.io (par le nom d’utilisateur/ou au moyen des médias sociaux/fpr), remplacement local (par exemple, par des signatures locales sur des clés importées manuellement ou dans le carnet d’adresses).
– La confiance dans les méthodes de découverte de clé (via les adresses électroniques) : WKD est utilisé par GpgOL, Enigmail,… et crypte automatiquement les messages entre deux utilisateurs dont la clé publique est connue de WKD.
– Ranking/classement et gestion des conflits : lorsque les services utilisent plusieurs méthodes de découverte de clé et obtiennent plusieurs réponses avec différentes clés publiques ? Enigmail et GnuPG ont une liste avec un ordre dans lequel il est possible de rechercher les clés, ce qui permet de prendre une décision raisonnable quant à la clé à utiliser. Le serveur de clés Mailvelope et garbage pile ne renvoient tous deux qu’un résultat unique.
– Lorsque plusieurs clés sont trouvées : quelles sont les actions possibles ?
> Le ranking – sur la base de la validité ou d’autres critères comme la dernière sous-clé créée.
> Le Cryptage en utilisant chacune d’elles – présente l’avantage que les risques que le destinataire ne parvienne pas à décrypter le message sont minimisés.
> Transmettre le problème à l’utilisateur.
…
– Problèmes de fuite de métadonnées, chaque source de découverte de clé ayant des fuites de métadonnées différentes, par exemple, le DNS est particulièrement problématique, le WKD ne révèle que le domaine,… Pour la recherche, commencez sans fuites de métadonnées et avec une faible latence.
Session OpenPGP : Représentation du message de validation de la signature numérique dans le temps
Animateur de la discussion: Daniel Kahn Gillmor
– La signification d’une signature au fil du temps n’est pas claire, avec un protocole de stockage et de transfert tel que le courrier électronique. Questions posées : de quelle manière une signature valide / invalide affecte-t-elle mon MUA ? En examinant les anciens messages, sachant que le statut est maintenant différent, cela affecte-t-il ce que mon MUA va faire ?
– Nous ne semblons pas avoir une représentation unifiée du message de validation de la signature dans le temps, dans les cas où la clé du signataire a expiré ou été révoquée après la signature.
– OpenPGP.js : l’expiration et la révocation sont traitées différemment. Lorsqu’une signature est vérifiée, la validité de la clé est déduite de l’heure de la signature.
– GnuPG : utilise l’horodatage sur la signature elle-même. Si la clé n’a pas expiré, elle est considérée comme valide. Sinon elle est considérée comme invalide.
– Les différents MUA affichent le message de validation de la signature différemment : exigez davantage de tests d’utilisabilité et les commentaires généraux.
– Utiliser différents points de données liés au temps, qui pourraient être pris en compte lors de l’évaluation de la validité de la signature (résultats de validation de la mise en cache ?), et afficher ainsi le bon message de validation de la signature à l’utilisateur.
– Les signatures et les dates sont utilisées de manière très différente dans différentes applications de messagerie électronique et laissent la place à davantage de conversations et d’apprentissage mutuels.
Session OpenPGP : En-têtes protégés / Trou de mémoire
Discussion animée par : Dr.-Ing. Dominik Schürmann
– Les spécifications ont été déterminées en 2016, mais n’ont pas évolué. Le projet de norme Internet IETF devrait arriver dans les mois à venir. Une nouvelle source d’informations centralisées serait un avantage (par exemple, un site Web).
– Certains clients l’implémentent, mais il reste des problèmes d’implémentation (par exemple, des problèmes de threading avec le sujet,…) et de compatibilité (par exemple, le mode de repli conduisant à un message tronqué, les MUA ne décryptant pas de tels messages,…).
– Étant donné que les spécifications évoluent encore, une coordination visant à réduire au minimum les spécifications est nécessaire (par exemple, en commençant par chiffrer le sujet et en évitant les références, etc., ce qui constituerait également une bonne base pour procéder à des itérations).
– Réduire la capacité de recherche : la recherche dans l’objet réel du message n’est pas possible.
– Il est également nécessaire de conseiller les MUA pour différents aspects, par exemple, le fait de n’utiliser que la première partie MIME du message crypté, « Sujet crypté » en tant que nom de sujet sert également d’indicateur de sécurité : Utiliser « No Subject » ou « Subject unavailable » ou Embedded Subject» ou Hidden Subject» – “No Subject” serait rejeté par les mesures de détection de spam.
– Considération de confidentialité : ne pas localiser la chaîne de sujet remplacée choisie qui pourrait révéler le langage du message réel.
La journée s’est terminée par une fête de signature de clés !
4e OpenPGP Email Summit sessions publiques (21-10-2018) – Jour 2
Session OpenPGP : Serveurs de clé publique et préoccupations basées sur le
GDPR
Discussion animée par : Patrick Brunschwig & Vincent Breitmoser
– La clé OpenPGP est PII. Le téléchargement automatique de clés sans consentement préalable de l’utilisateur dans un langage clair et facile à comprendre (la case à cocher ne fonctionne pas car elle n’est pas très indicative) rend les applications critiques pour le GDPR.
– Pour l’instant, les serveurs de clés publiques n’ont reçu aucune plainte d’une autorité de Protection des Données (APD). Mais nous devons aller dans la bonne direction.
– Les gens utilisent réellement des adresses électroniques pour trouver des clés publiques, et cela fonctionne dans la plupart des cas, par exemple, le serveur de clés Mailvelope (mais cela supprime la fédération et d’autres exigences que nous avons dans le pool).
– Idée : la marque neutre d’un serveur de clés est nécessaire. N’utilisez pas le serveur de clés Mailvelope dans OpenKeychain. Keys.openpgp.org peut servir d’accueil pour ce nouveau serveur. Il sera géré par un groupe petit mais stable. Les clés doivent être vérifiables et supprimables.
– Points de discussion : adresse e-mail, signature tierce, quelle solution de remplacement voulons-nous ? Rechercher uniquement au moyen d’ID complets (+ empreintes digitales) et non au moyen de sous-chaînes pour des raisons de performances?
– Interface : HKP ? Laisser le choix à l’implémentation du serveur de clés (ou à un remplacement instantané), sur quelles données renvoyer (par exemple, tous les ID de clés ?). Gouvernance : demander à n’importe quelle organisation à but non lucratif de l’exécuter ? (par exemple, EFF) ?
– Gmail et certains autres fournisseurs utilisent certains algorithmes pour nettoyer (supprimer les points,…) la partie locale d’une adresse e-mail – ce qui interrompra la stratégie de correspondance exacte. Cela pourrait-il être implémenté dans des tables de recherche, ou la représentation de l’email pourrait-elle être normalisée au moyen d’un intermédiaire ?
– La recherche avec des identifiants de clé longs (64 bits) peut-elle entraîner des conflits ? Plus tard, supprimez les identifiants de clé longs, lorsque les empreintes digitales sont dans les signatures.
Session OpenPGP: Indicateurs de sécurité (usurpation de code HTML)
Discussion animée par : Daniel Kahn Gillmor
– L’affichage HTML entraîne plusieurs risques : canaux d’ex-filtration ? Les désactiver complètement ? Ou autoriser la visualisation limitée de contenu externe ?
– Indicateurs dans la liste de messages ? Remplir la ligne émettrice ou d’autres éléments qui ne peuvent pas être manipulés par le corps de texte ? Restituer les emails sous forme de texte uniquement, avec un bouton pour permettre l’affichage HTML ?
– Plusieurs clients ont des problèmes avec un seul état de signature, PGP inline est problématique, en particulier pour les signatures à la pièce. Peut-être n’avoir qu’un seul état de signature par message (mais cela aura un impact immédiat sur les signatures des listes de diffusion).
– Limiter le statut cryptographique à «enveloppe cryptographique» contre «charge utile cryptographique» – n’utiliser que l’ensemble de couches de la crypto MIME à la périphérie même du message. https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html
– S’il y a un blob chiffré en ligne dans un message en texte clair, laisser l’utilisateur le déchiffrer manuellement »?
– L’Université de Bochum a envoyé un courrier à de nombreux MUA à propos d’indicateurs d’interface utilisateur pouvant être usurpés. Nous devrions nous préparer à faire le lien avec ses travaux lorsque surviennent des plaintes portant sur un affichage simplifié : https://www.golem.de/news/openpgp-gnupg-signaturen-faelschen-mit-html-und-bildern-1809-136738.html
– L’espace pour les en-têtes de sécurité au niveau de l’interface est géré différemment par les implémentations. De nombreuses améliorations peuvent être apportées, en veillant à informer l’utilisateur de la manière la plus simple à comprendre (par exemple, en affichant un indicateur détaillé par défaut, mais en le laissant réduire l’indicateur tout en profitant de l’occasion pour l’informer sur les plus petits indicateurs,…)
Session OpenPGP: Horodatage pour la validation de la signature
Discussion animée par : Danny De Cock
– Déclaration de problème : la validation de signature numérique OpenPGP (dans la plupart des implémentations) prend en compte le statut actuel (révoqué/expiré) de la clé du signataire et affiche un message de validation de signature imprécis/source de confusion si la clé du signataire est révoquée/expirée.
– Compte tenu du statut de la paire de clés du signataire (valide/invalide) au moment de la signature (horodatage), si elle est valide – la signature numérique reste valide à jamais et inversement dans l’autre cas.
– Conservez les états: utilisez un tiers de confiance pour gérer les horodatages et fournir des informations de validation de signature en cas de conflit.
– OU Bien utilisez les arbres de Merkle pour combiner différentes valeurs de hachage (en utilisant l’ordre des nœuds) à vérifier. Par exemple, le destinataire du message peut hacher chaque signature obtenue et en conserver un enregistrement (dans une base de données basée sur une arborescence Merkle par exemple), qui peut être utilisé comme support vérifiable pouvant être transmis au tribunal.
– En cas de révocation de la clé du signataire, il y a toujours un délai entre le moment où la clé a été compromise (ce qui peut être inconnu de l’utilisateur) et le moment où elle a été révoquée par l’utilisateur. Toute signature faite pendant ce temps serait considérée comme malveillante. En cas de présence d’une autorité de confiance, la dernière signature vérifiée (effectuée par l’utilisateur lorsque la clé n’a pas été compromise) peut être utilisée.
– En plus du point ci-dessus, au lieu d’avoir une autorité de confiance, nous pouvons demander au signataire du message de publier le dernier état vérifié de la clé sur un canal public (par exemple, serveurs de clés publiques, autres canaux,…), qui servira de point de données pour le dernier état vérifié (qui peut être utilisé pour prendre une décision raisonnable, par exemple, l’heure de signature par rapport au dernier état vérifié ?).
Slides de la session : https://homes.esat.kuleuven.be/~decockd/slides/20181021.signature.validation.pdf
OpenPGP : Affichage de validation de la signature
Discussion animée par : Andre Heinecke
– Le message d’affichage de validation de signature est différent selon les implémentations.
– Le message de validation de signature doit également informer l’utilisateur qu’une signature valide ne signifie pas que la clé du signataire utilisée pour signer le message appartient au propriétaire légitime. Il pourrait y avoir un deuxième paramètre donnant une indication sur la confiance dans la clé du signataire.
– Certaines implémentations fournissent également des informations pour la vérification de l’adresse de l’expéditeur en plus de la signature numérique elle-même.
– Les signatures sont faites sans contexte, les implémentations peuvent fournir des choix, par exemple, toujours signer pour ce destinataire avec cette empreinte digitale, etc.
– Une présentation générale du message de validation de signature numérique pourrait être un état binaire, si un message est valide ou non.
Session OpenPGP : Courrier électronique supprimable
Discussion animée par : Daniel Kahn Gillmor
– Définition du courrier électronique supprimable : contrôle la période de temps pendant laquelle un courrier électronique peut être lu.
– Une tentative de recadrer le «secret de transmission» et de l’adopter pour un format de message archivable tel que le courrier électronique.
– OpenPGP peut utiliser une rotation fréquente des sous-clés pour obtenir le même résultat (avec une fenêtre temporelle plus longue). Mais il est difficile de faire changer les clés à plusieurs reprises, en particulier dans les cas où l’on ne peut pas lire les anciens emails, ce qui n’est généralement pas souhaitable.
– Les emails doivent-ils être archivés? C’est une contradiction avec le « secret de transmission ». Cependant, nombreux sont ceux qui pensent que l’archivage des e-mails est une fonctionnalité dans les cas d’utilisation en entreprise (par exemple, pour des raisons de respect de la législation) et dans les cas d’utilisation personnelle (par exemple, les utilisateurs peuvent conserver leurs e-mails par choix).
– Certaines implémentations (par exemple, NotMuch) stockent la clé de session (chiffrée symétriquement), tout en permettant aux utilisateurs de supprimer/faire pivoter des clés (asymétriques) et en leur permettant de lire l’ancien message chiffré. Une autre approche consisterait à rechiffrer tous les messages sur une clé locale.
– Il n’y a pas de règle d’auto-suppression dans les clients de messagerie. Alors que certains messagers (instantanés) le permettent. À cet égard, d’autres options peuvent également être explorées pour définir une politique de suppression personnelle, par exemple dans les en-têtes de courrier électronique, les annotations de sous-clés, etc. Toutefois, l’application d’une telle politique pour les courriers électroniques peut nécessiter des accords de rapprochement bilatéraux / mutuels.
– Supprimer un e-mail localement ne suffit pas, car il y a toujours d’autres personnes qui pourraient avoir une copie de celle du message qui peut être récupérée. Les utilisateurs peuvent simplement prendre une capture d’écran ou utiliser un autre canal latéral pour conserver une copie de cet email.
– Certaines recherches dans ce domaine ont proposé d’utiliser une sous-clé différente pour chaque message. Toutefois, cela conduit à des problèmes communs (par exemple, environnements multi-périphériques,…).
– Supprimer les courriels après une courte durée (par exemple, une semaine) ou tous les six mois constituerait-il une amélioration par rapport à leur conservation pour une durée indéterminée?
– Idée: pré-générer et publier des clés pour une « rotation intensive » permettant aux parties en communication d’utiliser une clé particulière pendant une courte période, puis d’utiliser une clé différente. Cependant, une rotation fréquente peut pousser les utilisateurs à consulter fréquemment des serveurs de clés, ce qui peut conduire à des métadonnées (IP, quel destinataire,…). Exiger un canal hors bande pour accéder aux touches pivotées nécessite un support en ligne bien connecté.
– Concernant les fenêtres d’intervention, les courriels peuvent prendre une journée pour leur réception. Nous devons déterminer quel délai d’intervention serait approprié, et pour qui.
Justus évoque deux approches concernant la manière d’adapter Forward Secrecy à OpenPGP : https://sequoia-pgp.org/talks/2018-08-moving-forward/moving-forward.pdf https://www.youtube.com/watch?v = an6oYjikAPY
Les groupes de travail ont été suivis d’une séance de synthèse et la journée s’est terminée par une séance collaborative/ de piratage entre différents projets OpenPGP avec de nombreuses discussions parallèles judicieuses. Vous trouverez ici (lien en anglais) une version encore plus détaillée de ces sessions avec un FAQ.
Nous sommes heureux d’avoir eu l’occasion d’accueillir le 4e OpenPGP Email Summit et d’acquérir, de partager et d’échanger des compétences sur des sujets importants qui contribueront à façonner l’avenir d’OpenPGP. Cela nous a également permis de collaborer avec d’autres projets OpenPGP qui partagent avec nous la vision commune du renforcement de la sécurité et de la confidentialité des données dans ce monde de plus en plus connecté. Nous attendons avec impatience les développements ultérieurs sur tous les sujets discutés lors de diverses conférences plénières/sessions ouvertes/discussions parallèles et continuerons à soutenir toute autre initiative contribuant à faire d’Internet un lieu plus sûr et plus ouvert.
Nous remercions chaleureusement plus particulièrement :
- Patrick Brunschwig d’Enigmail pour avoir impliqué toutes ces personnes formidables à l’occasion de ce sommet
- La Renewable Freedom Foundation pour le financement des dîners
- Tous les participants exceptionnels du 4ème OpenPGP Email Summit
Mailfence est une suite de messagerie sécurisée et privée offrant aux utilisateurs un contrôle total sur leurs données. Pour en savoir plus sur nous, consultez notre page de presse.
[maxbutton id= »14″ ]
