Blog

Nouvelles de Mars et Avril

Nous sommes ravis de vous retrouver pour ce billet avec quelques nouvelles de l’avancée du projet, et, pour la première fois, un billet un peu plus technique et qui aborde un point précis de ce que sera Caliopen.

Des brèves

  • Les principaux développeurs ont eu beaucoup de travail en dehors de Caliopen durant le mois de mars, donc les avancées sur ce plan sont limitées : il faut une réorganisation complète du code pour permettre à de nouveaux participants d’intégrer plus facilement le projet avant la mise à disposition d’une version alpha publique prévue pour la fin mai. C’est en cours, ce sera très bientôt le cas.
  • Nous ne restons pas inactifs pour autant: nous avons par exemple rencontré les gens de Manzalab pour évaluer avec eux nos pistes concernant la ludification du progrès des utilisateurs dans leur indice de confidentialité. Un pad (où chacun peut déposer ses idées) est ouvert à ce sujet.
  • Une autre rencontre utile a été celle avec les gens du projet PEPS, pour essayer de trouver des synergies entre deux projets par ailleurs assez différents. L’occasion pour tous de s’interroger sur l’intégration de l’indice de confidentialité de Caliopen dans d’autres services de messagerie.
  • Une conférence sur Caliopen a été donnée por la première fois en dehors de France, en Italie grâce au BGLUG et à Daniele Pitrolo. Une autre conférence est d’ores et déjà prévue le 24 avril à Brest, mais si vous souhaitez que nous venions présenter Caliopen chez vous, n’hésitez pas à nous contacter.

Le cas des clés

Depuis le premier jour de Caliopen, la même question revient, régulièrement, sur la méthode de chiffrement que nous utiliserons pour garantir la confidentialité des échanges.

S’il nous est si difficile d’y répondre, c’est que cette question méconnait largement notre projet:

  • il n’y a pas « la » méthode de chiffrement de Caliopen, parce que – par principe – l’utilisateur aura le choix entre ne rien chiffrer, chiffrer ses envois, chiffrer ses messages stockés… Des choix plus ou moins contraignants pour son usage quotidien, et qui joueront dans le calcul de son indice général de confidentialité, mais qui ne seront en rien imposés. Caliopen proposera des solutions intégrées de chiffrement, c’est dans son ADN, mais n’obligera à rien.
  • et nous ne considérons pas, non plus, que quiconque puisse « garantir » une confidentialité des échanges. Même dans l’environnement le mieux protégé, nul n’est à l’abri d’un micro, d’une clé USB utilisée en son absence, d’une attaque ciblée, ou d’une simple erreur.

L’ambition de Caliopen, c’est de compliquer la surveillance de masse au point de la rendre trop chère pour être envisagée. l’objectif n’est pas de protéger tel ou tel individu (même si – à l’évidence – tout passera par là) mais de mieux protéger l’ensemble des utilisateurs.

Si on ne comprend pas ces préalables, il est difficile de comprendre Caliopen. Nous sommes tous habitués à raisonner en termes binaires (mes communications sont chiffrées, je suis protégé / je ne chiffre pas mes communications la NSA sait tout de moi) alors que, dans notre projet, tout est question de niveau (moi et mes contacts sommes mieux protégés et je peux encore améliorer ça).

Pour autant, on ne peut pas se contenter de cette explication sans indiquer, malgré tout, les choix techniques que nous avons faits en matière de chiffrement. Et notamment sur la question des clés.

Dès l’origine, nous avons décidé que Caliopen n’enfermerait pas ses utilisateurs dans son écosystème: nos choix sont conservateurs et compatibles avec l’ensemble des systèmes de messagerie existants, selon le bon vieux principe de Postel (« soyez tolérant dans ce que vous acceptez, et pointilleux dans ce que vous envoyez »). Il en va de même en ce qui concerne le chiffrement: pour rester ouverts au reste du monde, les utilisateurs qui le souhaiteront utiliseront PGP pour signer, ou chiffrer leurs messages.

PGP présente un avantage énorme: il est totalement décentralisé. À l’inverse de S/MIME, il ne repose sur aucune autorité centrale chargée de la diffusion des clés publiques.

Mais PGP a un énorme inconvénient: parce qu’il est totalement décentralisé, il est difficile de connaître la clé publique qui vous permettra de chiffrer le message destiné à un nouveau contact, et il est tout aussi difficile de mettre à disposition de ses contacts la clé qui leur permettra de chiffrer les messages à vous destinés. Un serveur de clé ? Même si le protocole SKS a été une belle avancée, il reste très instable au quotidien. Et, parce qu’il centralise la gestion des clés, il représente une vulnérabilité qui fragilise un système tel que PGP. Pour les utilisateurs de Caliopen qui décideront de créer leur propre clé de chiffrement, nous devions proposer une autre solution.

À l’instar de Werner Koch (dont nous avons traduit la réponse récente à une critique de PGP – voir encadré), nous avons choisi d’utiliser le DNS.

  • Parce que tout utilisateur de Caliopen a un identifiant unique (identifiant@domaine) pouvant faire office d’adresse email s’il le désire, le DNS permet de trouver aisément sa clé publique: il suffit pour cela d’interroger le serveur de nom du domaine (par exemple ‘dig @ns.brainstorm.fr -t cert laurent.brainstorm.fr’ renverra la clé PGP de « laurent@brainstorm.fr »). Inutile de chercher un serveur SKS fonctionnel, inutile de passer par un intermédiaire.
  • Parce que, de ce point de vue, le DNS est un système décentralisé: en dehors des administrateurs de la zone, et encore plus si celle-ci est gérée via DNS, il est extrêmement difficile pour un tiers de la modifier pour y insérer de fausses clés.
  • Parce que des clés ainsi stockées sont plus facilement révocables (ce qui est sinon un des principaux défauts de PGP).

Il existe d’autres raisons, mais à l’occasion de la traduction du billet cité en encadré, nous avons découvert que le projet STEED, du même Werner Koch, les résumait admirablement dans ce document.

Encore une fois, il n’est pas question de contraindre l’utilisateur de Caliopen: si celui-ci préfère d’autres méthodes pour diffuser sa clé publique, libre à lui. L’algorithme de Caliopen attribuera plus ou moins de points dans le calcul de l’indice de confidentialité selon qu’il aura eu connaissance d’une clé selon une technique plus ou moins sûre, mais toutes seront gérées, évidemment.

D’autres aspects des techniques de chiffrement choisies pour Caliopen (génération des clés, stockage de la clé privée et utilisation sur des terminaux multiples) seront traités dans de futurs billets.

Contact

C’est la fin de ces nouvelles, mais, comme vous le savez bien, il y a plusieurs moyens de rester en contact avec nous:

Ce billet est également disponible en anglais et italien.

« Le cas des clefs »
Article de Werner Koch traduit de l’allemand.

Dans le magazine C’T 6/2015 du 21 Février, Jürgen Schmidt signe un éditorial souhaitant qu’on « Laisse mourir PGP ».Il considère PGP (et le standard OpenPGP) comme un « un dinosaure boîteux » et dépassé. Pour le démontrer, il compare PGP aux services en ligne d’Apple, et à l’outil de messagerie instantanée Textsecure.

Sans parler du fait que, comme toute entreprise américaine, ces deux exemples peuvent être contraints d’intégrer des portes dérobées dans leurs logiciels, c’est comme comparer des trains à des sous-marins. Ils sont en métal et font du transport, mais c’est leur seul point commun.

Pourtant, dans son article « Le cas des clefs », page 160, c’est sous cet angle qu’il décrit ses problèmes.

Comparer des protocoles en ligne (comme TextSecure) avec des protocoles hors-ligne (OpenPGP ou S/MIME) n’est pourtant pas une approche très honnête. Une réunion, qu’elle ait lieu dans un bureau ou par visio-conférence, n’entrainera pas les mêmes contraintes qu’un échange de courrier. De nombreux problèmes son plus faciles à résoudre lors d’un échange en simultané que lors d’une discussion asynchrone.

Pour autant, les courriers, e-mails et comptes rendus sont encore loin d’être inutiles; ce n’est que par ces outils de correspondance hors-ligne que les informations peuvent être conservées de manière confidentielle et rester à disposition pour être utilisées plus tard.

Et nous avons besoin de protocoles hors-ligne, qui fonctionnent même même quand il n’y a plus de réseau. D’ailleurs, le réseau « Sneakernet » est souvent moins cher (plus de bande passance, cf. Backups) et plus sûr qu’une connexion en ligne. Ceux qui ont vu Citizenfour se souviendront de la différence que fait Snowden entre son ordinateur portable en ligne et celui son ordinateur hors-ligne (« air-gapped »). Or l’e-mail est par nature un outil hors-ligne.

OpenPGP, contrairement à S/MIME (l’autre protocole de chiffrement hors-ligne), est décentralisé, ce qui présente d’énormes avantages: on peut l’utiliser partout, et il ne nécessite pas d’avoir une autorité de certification, tout comme une réunion n’a pas besoin d’être confirmée au préalable par un bureau d’enregistrement (le pendant IRL d’une autorité de certification). Souhaiter que les serveurs de clefs exigent un e-mail de confirmation avant de pouvoir envoyer sa clé passerait donc complètement à côté de la réalité de l’architecture décentralisée d’OpenPGP, puisque ça recréerait un système centralisé.

Bien sûr, dans un système centralisé, on peut controler l’identité de l’émetteur. Mais c’est impossible dans le cadre de services répliqués et décentralisés, qui sont intentionnellement sans contrôle central.

Quant aux problèmes que Jürgen Schmidt semble avoir rencontrés avec certains e-mails, indéchiffrables, ils pourraient très facilement être limités par une publication de ses coordonnées dans les mentions légales sur le site du journal C’T. En plus de son adresse email, il lui suffirait d’ajouter au moins l’identifiant de sa clé, son empreinte, ou même un lien direct.

Il n’aborde pas non plus les problèmes équivalents avec S/MIME bien que ce soit (parait-il) l’autre protocole le plus répandu de chiffrement de l’e-mail. C’est d’autant plus surprenant que C’T fait, depuis plusieurs années et de façon récurrente, la promotion de S/MIME en tant que solution de chiffrement facile d’utilisation.

Mais comment trouver une clef quand elle n’a pas été envoyée dans un premier e-mail ? Les supposées garanties de fiabilité des autorités de certification sont ridicules. Avec leur aide, n’importe quelle organisation d’espionnage – étatique ou privée – peut se faire délivrer n’importe quel certificat pour n’importe quelle adresse. Ce ne sont pas des clefs aussi clairement falsifiées que celles que l’on voit sur les serveurs de clefs, mais elles facilitent bien la vie de la NSA, du GCHQ et du BND.

Utiliser l’interface web d’un serveur de clefs pour démontrer qu’on peut fournir des « fausses » clefs est une méthode dénuée de sens, puisque le serveur de clefs ne peut (ou ne veut) pas utiliser de contrôles cryptographiques. Ceci devrait être parfaitement su de l’auteur de l’article, d’autant plus qu’il m’avait posé la question quelques jours auparavant. L’utilisation du logiciel OpenPGP aurait rapidement souligné qu’il s’agit bien de « fausses » clefs, puisqu’aucune d’elles n’aurait été importée, ni listée dans le trousseau.

C’est vrai: on peut soumettre n’importe quelle clé. L’exemple le plus courant est celui de « president@whitehouse.gov« , avec environ 27 clefs. Ça n’a évidemment rien de nouveau, et c’est quelque chose que l’on apprend dans toutes les Cryptoparties. C’est d’ailleurs la raison pour laquelle, dans certains journaux, ou sur des cartes de visites, on indique également une empreinte. Les utilisateurs les plus experts font même contresigner leurs clefs lors de « Keysigning Parties » (bien qu’il s’agisse plus d’un jeu de société que d’une solution utile pour le grand public).

Plutôt que de démolir tout à la fois les serveurs de clefs et OpenPGP, il serait bien plus efficace de demander aux fournisseurs d’e-mail d’agir : les adresses e-mail sont gérées via le DNS de manière unique, donc on pourrait – et devrait – se servir aussi du DNS pour obtenir une clé.

Certes, on peut toujours falsifier le DNS, puisqu’il n’est pas vraiment sûr, mais il y aurait au moins une clé pour chaque adresse mél. Il existe des RFC sur ce sujet depuis des années, et GnuPG a implémenté ce système depuis 2006 (voir http://www.guug.de/veranstaltungen/ffg2006/abstracts.html#4_2_2 ). À ce propos, en 2012, avec mon collègue Marcus Brinkmann, j’ai lancé un projet sous le nom de STEED (voir http://g10code.com/steed.html ), au sujet duquel C’T a publié un article « Confiance au 1er abord » à peu près exact (voir http://www.heise.de/artikel-archiv/ct/2012/20/190_Vertrauen-auf-den-ersten-Blick ).

Malheureusement les FAI ne veulent pas y participer et préfèrent nous endormir en prêchant la sécurité par le biais d’idioties comme le e-mail « made in Germany » ou en proposant la référence du service avec porte dérobée qu’est De-Mail.
(voir http://www.ccc.de/en/updates/2013/stellungnahmedemail)
[/expand]

Laisser une réponse