Dans un article, le chercheur Nadim Kobeissi pointe des faiblesses du modèle de sécurité de ProtonMail, qui propose du chiffrement de bout en bout d'emails. Contactée, la société balaie la critique, revendique des choix de conception communs avec d'autres services sécurisés et interroge les intentions derrière cette étude.

Hier, Nadim Kobeissi a publié une analyse formelle de l'architecture de sécurité de ProtonMail (PDF). Professeur à la branche parisienne de la New York University, il est connu pour plusieurs projets, dont Cryptocat et Peerio et pionnier de la cryptographie web (voir notre portrait début 2015). Dans son document, écrit « en quelques jours », il attaque frontalement le service, estimant que son webmail ne fournit pas réellement de chiffrement de bout en bout, pour plusieurs raisons.

« ProtonMail n'a, depuis sa genèse, jamais fourni de garantie de sécurité pour le chiffrement de bout en bout à la majorité de ses utilisateurs », écrit Kobeissi, pensant que la plupart des membres passent par cette version web.

La promesse du chiffrement de bout en bout

L'intérêt de ProtonMail, par rapport aux applications PGP classiques, est que le service gère lui-même le chiffrement et les clés (privée et publique) qui le permettent. ProtonMail conserve la clé privée de l'utilisateur sur ses serveurs, pour la lui fournir sur n'importe quel appareil. Cette clé est chiffrée avec un dérivé du mot de passe de l'utilisateur, inconnu de ProtonMail.

En principe, la clé privée est déchiffrée localement (par exemple dans le navigateur), le serveur n'en ayant que sa copie chiffrée. Toutes les opérations de chiffrement sont effectuées localement, ProtonMail ne voyant que le contenu chiffré des messages ; les métadonnées, dont l'objet, sont tout de même hébergées en clair.

La société a construit une solide réputation sur ce modèle, en devenant par ailleurs la principale responsable d'OpenPGPjs, la bibliothèque qui gère le (dé)chiffrement des données dans le navigateur web. Elle a depuis lancé son propre réseau privé virtuel (VPN), ProtonVPN, promu par Mozilla.

Passons en revue les critiques de Kobeissi, avec les réponses de l'entreprise.

Un outil de chiffrement fourni par le webmail

La principale concerne le webmail, qui permet de consulter les messages en les déchiffrant localement. Problème : OpenPGPjs, la bibliothèque servant à chiffrer et déchiffrer les emails, est fournie par le serveur sans contrôle d'intégrité. En théorie, le serveur pourrait livrer une version compromise d'OpenPGPjs à un utilisateur particulier sans qu'il ne le sache, donc obtenir une copie du mot de passe utilisateur, voire interférer avec les messages.

Pour Kobeissi, le webmail de ProtonMail ne peut pas prétendre fournir du chiffrement de bout en bout, parce que le serveur fournit le code à chaque connexion. Selon lui, l'entreprise doit soit fournir son « webmail » sous forme d'application de bureau (à la distribution certifiée) et retirer la version web, soit arrêter de clamer fournir du chiffrement local.

La société suisse estime que la version web n'invalide pas cette promesse de sécurité. « Le modèle de menace pour la cryptographie web diffère légèrement de celui des applications natives, et nous en convenons. Ce que dit l'article [de Nadim Kobeissi], c'est que la ligne pour le chiffrement de bout en bout devrait être tracée à un autre endroit de celui où nous l'avons tracée. Notre approche [de cryptographie web] était plus controversée en 2014 qu'aujourd'hui, quand les applications en une page sont devenues la norme », nous répond Bart Butler, le directeur technique de ProtonMail.

ProtonMail défend donc son choix, rappelant que les messageries instantanées chiffrées WhatsApp et Wire ont le même modèle sur le web, tout en prétendant fournir un chiffrement local. Interrogé, Nadim Kobeissi refuse d'étendre le débat aux autres services. Il avait pourtant lui-même subi des critiques similaires avec la première mouture de Cryptocat, dont il avait basculé la distribution vers une extension pour navigateur, certifiée par les boutiques officielles d'extensions.

« La vraie solution tient en deux parties. D'une part, il faut un standard dans les navigateurs pour signer des paquets web. Des travaux sont en cours et nous les suivons de près. D'autre part, nous devons stocker des empreintes (checksums ou hashs) de ces paquets web dans un endroit que nous ne contrôlons pas, avec un historique permanent des versions que le navigateur peut vérifier. La blockchain est une option parmi d'autres », ajoute le directeur technique. Il faudrait donc attendre.

Quid des applications mobiles ? Kobeissi rappelle que le code est téléchargé une seule fois à l'installation ou la mise à jour, par le biais d'une boutique d'applications (App Store ou Google Play Store), qui garantit l'intégrité du code. Pas de problème de ce côté, donc. Il groupe avec eux le Bridge, l'application de bureau permettant d'utiliser un client mail local, distribuée directement par ProtonMail.

L'envoi d'emails chiffrés vers des tiers critiqué

En plus du chiffrement d'emails par PGP, entre utilisateurs de ProtonMail ou avec des gens disposant de leurs propres clés PGP, le service permet d'envoyer des emails chiffrés à des tiers sans moyens de chiffrement. À l'écriture du mail, il est possible de le protéger via un mot de passe (« clé prépartagée »), à communiquer au contact par un autre biais. Le destinataire reçoit un message en clair avec un lien vers ProtonMail, qui réclame alors le mot de passe et déchiffre localement le contenu dans une page web.

Selon l'analyse de Kobeissi, le mot de passe peut être récupéré par ProtonMail, une nouvelle fois en envoyant une version compromise d'OpenPGPjs. Il pourrait aussi remplacer la clé publique envoyée au destinataire avec l'email en clair, par une clé publique correspondant à sa propre clé privée, permettant de déchiffrer lui-même le message en toute discrétion.

En outre, le serveur email de réception (par exemple Outlook) pourrait remplacer le contenu de l'email en clair pour rediriger le destinataire vers un site qu'il contrôle, imitant ProtonMail pour obtenir la clé ouvrant le contenu chiffré. Selon Kobeissi, il pourrait même chiffrer et déchiffrer un échange sans être détecté (par une attaque de l'homme du milieu).

« Ce sont des choix de conception délibérés pour faciliter l'utilisation. Cela revient à l'argument plus général sur les applications web. La fonction de chiffrement vers l'extérieur n'est pas appropriée pour les modèles de menace qui incluent les serveurs email tiers comme attaquant actif », répond Bart Butler. Présenter ces choix comme des failles serait donc trompeur, juge-t-il.

Des questions sur la solidité du mot de passe

Kobeissi remarque que les clés des boites de réception, les clés secrètes PGP et les mots de passe des emails chiffrés vers des tiers peuvent être vulnérables à des attaques par dictionnaire. Il est ainsi possible de mettre « 1 », « iloveyou » ou encore « password », assure-t-il.

« Autoriser des mots de passe extrêmement faibles accroit le problème et pourrait permettre l'obtention aisée de la clé privée PGP d'un utilisateur » juge le chercheur. Si un pirate venait à obtenir les emails des clients, il estime qu'il serait possible d'obtenir une bonne part d'entre eux en testant les 100 000 mots de passe les plus communs.

ProtonMail devrait donc imposer une longueur minimale pour les mots de passe, voire utiliser une bibliothèque de contrôle comme zxcvbn. La société pourrait aussi recommander des phrases de passe, argue-t-il.

« La raison pour laquelle nous ne sommes pas plus contraignants sur les mots de passe est que contrairement à beaucoup d'autres services en ligne, les conséquences d'une perte de mot de passe pour ProtonMail sont lourdes. Vous perdez l'accès à tous vos emails, pour toujours. Donc nous voulons vraiment que les internautes utilisent un mot de passe qu'ils peuvent retenir », nous explique l'entreprise.

Concernant les emails chiffrés vers des tiers, le mot de passe peut être donné par de nombreux moyens (comme le téléphone), ce qui justifie cette flexibilité aux yeux du service.

Un mot de passe utilisateur devinable, avec des efforts

Dans sa documentation, ProtonMail détaille la méthode d'authentification sur le serveur, par preuve de mot de passe sans connaissance (Zero Knowledge Password Proof, ou « ZKPP »). Le serveur de ProtonMail n'a aucune connaissance du mot de passe, même pas une empreinte. Par contre, il héberge bien la clé privée PGP de la boite mail, au chiffrement dérivé du mot de passe utilisateur.

Selon l'article, le choix de chiffrer cette clé privée avec un dérivé du mot de passe utilisateur pose un problème de sécurité. « La clé privée chiffrée [avec ce dérivé] agit comme un oracle pour le mot de passe de l'utilisateur. Cet oracle peut être utilisé pour une attaque par force brute ou une attaque par dictionnaire « hors ligne », invalidant donc la promesse de preuve de mot de passe sans connaissance (ZKPP) » écrit Kobeissi.

Pour lui, ProtonMail ne doit plus héberger les clés privées PGP de ses utilisateurs, ce qui enlèverait une bonne part de son intérêt au service.

Réponse de ProtonMail : « Cette partie n'a aucun sens ». La ZKPP n'aurait pas de rapport direct avec la sécurité du serveur mail, qui serait un problème traité à part.

« La ZKPP fournit des garanties sur la poignée de main entre le client et le serveur. Cela ne veut pas dire, et n'a jamais voulu dire, que le serveur lui-même ne pourrait pas monter une attaque par force brute contre le mot de passe utilisateur. Ce serait possible avec n'importe quelle [méthode d'authentification de l'utilisateur], y compris SRP que nous utilisons. Chiffrer la clé privée avec un dérivé du mot de passe n'y change rien », élabore Bart Butler.

Pour protéger les utilisateurs, dans l'idée que le serveur peut être compromis, « nous rendons [cette attaque contre le mot de passe] très coûteuse pour le serveur, en utilisant des empreintes de mots de passe lentes ».

Des accusations croisées

En conclusion, l'article pointe « des défaillances sérieuses dans l'architecture de sécurité de ProtonMail », qui demanderaient une correction urgente. Même dans le cas où ProtonMail assumerait ces points.

La publication de l'analyse, hier, a déclenché une passe d'armes entre Nadim Kobeissi et ProtonMail sur Reddit. Pour la société, l'étude est motivée par un accrochage la semaine dernière sur Twitter, après que le chercheur a relayé une prétendue faille de ProtonMail, associée à une demande de rançon. « Cette tentative d'extorsion est une intox, et nous n'avons aucune preuve qui indique le contraire », nous avait répondu l'entreprise sur le coup.

Le PDG de ProtonMail, Andy Yen, nous décrit l'analyse de Kobeissi comme un article-choc (« hit piece »), déguisé en vérification formelle. Pour la société, l'article n'est pas assez sérieux pour en être véritablement une. Sur Reddit, Kobeissi s'est défendu de donner son avis, estimant que le format ne laissait pas de place à des appréciations personnelles.

Note : Nadim Kobeissi nous a transmis son analyse le 19 novembre au soir, la veille de la publication, répondant alors à de premières questions. Nous avons contacté Jean-Philippe Aumasson, cryptographe reconnu, cité dans les remerciements de l'analyse, sans réponse pour le moment. Lors de nos discussions, ProtonMail estimait que l'affaire ne méritait pas d'article.