Connexion
XChat : la sécurité du chiffrement de bout-en-bout questionne, Proton en profite
Oui, non, peut-être
Sur X, un échange entre un ingénieur et Proton a remis la sécurité des messages chiffrés du réseau social sur le devant de la scène. Même si la solution adoptée n’est pas aussi simple que l’ingénieur le pensait, elle reste très critiquée.
Au cours des derniers mois, X a diffusé auprès d’un nombre croissant d’utilisateurs sa fonction de messagerie sécurisée Xchat, présentée comme ayant un chiffrement de bout en bout (E2EE).
« Toutes les affirmations sur le chiffrement de bout en bout ne se valent pas »
Ce 1ᵉʳ décembre, Ansgar, chercheur à la fondation Ethereum, a publié un message sur X pour s’en prendre à cette sécurité, qu’il a qualifiée de « ridicule ». Il pointait deux défauts majeurs dans l’implémentation faite par X : la clé privée de chiffrement est stockée sur les serveurs de l’entreprise et les conversations ne sont protégées que par un code PIN à quatre chiffres.
Cette communication a rapidement été reprise par le compte officiel de Proton, avec un message simple : « Malheureusement, toutes les affirmations sur le chiffrement de bout en bout ne se valent pas ». Il enchainait sur la propension des « géants de la tech » à « vendre du vent en matière de confidentialité en prétendant offrir chiffrement et protection de la vie privée, alors qu’en réalité, ils détiennent la clé principale et peuvent accéder à vos contenus ».
Rappelons que l’objectif du chiffrement de bout en bout est de transmettre une information que seul le destinataire pourra lire. Dans une solution E2EE solide, aucun des intermédiaires impliqués dans la transmission de ces données ne peut lire l’information, car seul le destinataire possède la clé privée pour déchiffrer le message. Quand l’un des acteurs dispose de la clé, il a la capacité d’accéder aux informations, brisant la promesse initiale.
Sécurité matérielle, mais code à quatre chiffres
En pratique, c’est un peu plus complexe. Au lancement, X reconnaissait déjà que son implémentation ne disposait pas d’une sécurité persistante, ce qui la rendait plus sensible aux attaques par l’homme du milieu (MITM). Cependant, en réponse à un tweet du chercheur en sécurité Matthew Green, un ingénieur de chez X avait confirmé l’utilisation de serveurs HSM (Hardware Security Modules) pour stocker les clés privées. X se sert de Juicebox (pdf) pour la sécurité des clés, un projet open source divisant les secrets en plusieurs morceaux, stockés par les HSM. Ils ne peuvent être reconstruits qu’avec le code PIN.
Si Ansgar a reconnu dans un premier temps que l’implémentation n’était pas aussi simple qu’il le pensait, elle augmentait la pression sur le code PIN, limité à quatre chiffres et donc sujet aux attaques par force brute. Quatre chiffres, cela ne laisse que 10 000 possibilités, ce qui se passe quasi instantanément s’il n’y a pas de protections supplémentaires.
Dans un autre message avertissant Proton de son changement d’avis, il signalait également que les HSM, qui permettent de faciliter l’utilisation, sont de moins bonnes protections que des clés privées stockées directement chez les utilisateurs. Proton a remercié le chercheur mais assume son message initial, puisque des géants « comme Google, Microsoft, etc » peuvent accéder aux e-mails, fichiers sur le cloud et autres.
Les éléments mis en avant ne sont cependant pas nouveaux. Matthew Garrett, un autre chercheur en sécurité, les avait déjà mentionnés dans un billet de blog daté du 5 juin. D’autres étaient revenus sur la question, par exemple le compte Mysk le 4 septembre pour affirmer que X n’implémentait pas correctement Juicebox.
