Connexion
Abonnez-vous

Mails chiffrés : Google confie E2EMail à la communauté et se concentre sur Key Transparency

Un projet peut en cacher un autre

Mails chiffrés : Google confie E2EMail à la communauté et se concentre sur Key Transparency

Le 28 février 2017 à 14h00

Il y a quelques jours, Google a officiellement confié son extension Chrome de chiffrement d'emails à la communauté. Cela après trois ans de développement sans grandes vagues. L'entreprise semble désormais plutôt miser sur Key Transparency, qui doit fournir une solution au problème de la toile de confiance.

E2EMail n'est plus un projet de Google. Le groupe de Mountain View a annoncé que son extension Chrome de chiffrement d'emails, destinée à Gmail, est désormais entre les mains de la communauté open source. Si le code est disponible depuis plusieurs mois sur GitHub, l'enfant est désormais lâché par ses parents. Lancé en juin 2014, le projet ne semble avoir reçu que peu de soin de la part de Google, dont les commits ont été rares l'an passé.

Un système vieux de trois ans, encore très limité

Pour mémoire, Google End-to-End ambitionnait de démocratiser le chiffrement via OpenPGP pour Gmail, grâce au navigateur maison. « E2EMail propose son approche pour intégrer OpenPGP à Gmail via une extension Chrome, avec une utilisabilité améliorée, tout en maintenant le corps des messages en texte clair uniquement sur le client » résume Google.

L'outil est fondé sur une bibliothèque de chiffrement en Javascript conçue en interne, « Google End-to-End », aussi utilisée par Yahoo. Pour le moment, il propose uniquement le chiffrement entre internautes disposant de l'extension, pour les messages texte. La clé privée est divisée en deux, une moitié étant hébergée localement sous la forme d'un code de 128 bits. Il est renouvelable grâce à un code fourni à l'installation.

Key Transparency à la rescousse

« Pour le moment, nous ne la recommandons que pour des tests et des retours sur l'interface » rappelle l'entreprise, qui utilise un serveur de clés centralisé pour les essais. La fédération avec d'autres serveurs est envisagée.

Cette annonce, quelque peu opportuniste, arrive un mois après celle de l'initiative Key Transparency de Google. L'équipe d'E2EMail annonce d'ailleurs que ce dernier projet aura une grande importance dans l'avenir de l'extension. « Plus de 20 ans après son invention, la plupart des gens ne peuvent ou ne veulent toujours pas utiliser [PGP], même pas son propre créateur » tacle Google en présentant Key Transparency.

Concrètement, il propose de faciliter la recherche de clés PGP, à partir de serveurs publics fédérés, avec gestion des modifications. Le principe est de lier les clés à une identité numérique, hébergeable de manière décentralisée, avec la possibilité de vérifier la propriété de l'ensemble des comptes. Le développement est partagé entre Google, l'équipe CONIKS de Princeton, Open Whisper Systems (derrière Signal) et Yahoo. 

D'autres approches en cours d'élaboration

Rappelons en outre que les implémentations de PGP chiffrent bien le contenu de l'email, mais pas les métadonnées, que ce soit les correspondants ou l'objet du message. C'est aussi l'approche choisie par le service suisse ProtonMail pour le chiffrement des messages, via la bibliothèque OpenPGP.js, dont il est devenu le principal contributeur.

D'autres outils se préparent également, comme le Dark Internet Mail Environment (DIME), qui compte revoir les méthodes de chiffrement des messages (voir notre actualité). Ici, les métadonnées sont aussi censées être protégées, un changement important face à PGP. Il est proposé par le concepteur du service Lavabit, récemment revenu d'entre les morts après sa fermeture en 2013... Même s'il ne propose aujourd'hui qu'un site vitrine et ne semble pas encore avoir mis en place le service en lui-même. Un effet d'annonce qui reste regrettable.

Plus généralement, les outils de messagerie chiffrée sont confrontés à deux problèmes majeurs actuellement. Le premier est de proposer une toile de confiance à la fois fiable et simple à utiliser, qui permette de vérifier simplement l'identité de quelqu'un, en exploitant des validations de tiers. Le second est bien de lier un compte ou un client à une personne physique, pour s'assurer que c'est bien avec elle que l'on communique. Si aucune solution miracle ne semble encore exister, des services comme Keybase ambitionnent d'apporter leur pierre à l'édifice.

Commentaires (9)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Il faut au moins que l’adresse du destinataire soit en clair. Et si l’on veut prévenir de la non distribution l’émetteur, il faut aussi avoir son adresse.



Cela rend compliqué de cacher ces données importantes dans les méta-données.

votre avatar

C’est ce que j’avais compris. Une enveloppe bioen scotchée empêche le facteur de lire nos lettres d’amour, mais même sans connaître son contenu, il sait à qui il la délivre (*) <img data-src=" />



* sauf les facteurs français puisqu’ils auront paumé le courrier avant <img data-src=" />

votre avatar

ben ça dépend à qui tu veux cacher les metadata.

mais à un moment donné effectivement, faudra bien que la lettre arrive à destination, et que le destinataire sache qui l’a envoyée.

votre avatar

ProtonMail ne chiffre pas les métadonnées ?!?

votre avatar

Je pensais aussi mais vu la troisième requête en termes de votes (Encryption of all metadata,https://protonmail.uservoice.com/forums/284483-feedback/filters/top) et son état (UNDER REVIEW&nbsp;), je crois pas <img data-src=" />

votre avatar

Le lien entre clef publique et identité (réelle ou numérique) est effectivement critique.



Avec Key Transparency leur solution est un Merkle tree fédéré (les commit sont des modifications de clefs). Autant rendre le système vraiment distribué et en faire un contrat blockchain. Éventuellement les noeuds du réseau blockchain pourraient être maintenus par le réseau de partenaires.



Google préfère sans doute garder le contrôle total sur la liste de clefs :

“A Key Transparency server could update user keys in a transparent, user visible

fashion that is analogous to an account-reset. The server could then

subsequently then deny the user the ability to remove or update unwanted public

keys under their account. This is permitted under this threat model. The

presence of 3rd party account access is visible to the user and all public keys

are in the public record.”

github.com GitHub

votre avatar

Les emails chiffrés ne protègent pas les métadonnées à la base. Pas plus chez Protonmail qu’ailleurs (mais ça tient surtout au fonctionnement de l’email).

votre avatar

Quid de Mailvelope? E2EMail semble faire la même chose mais moins bien…

votre avatar







David_L a écrit :



Les emails chiffrés ne protègent pas les métadonnées à la base. Pas plus chez Protonmail qu’ailleurs (mais ça tient surtout au fonctionnement de l’email).





Tu veux dire que c’est techniquement impossible (ou très difficile) ? Pas possible de délivrer le message si les métas sont chiffrés, un truc du genre ?


Mails chiffrés : Google confie E2EMail à la communauté et se concentre sur Key Transparency

  • Un système vieux de trois ans, encore très limité

  • Key Transparency à la rescousse

  • D'autres approches en cours d'élaboration

Fermer