A propos des messageries instantanées (Partie 2) : Quelques alternatives

Ecrit en janvier 2021, le texte qui suit n'a pas fait l'objet d'une publication à ce moment-là, par manque de temps pour lui donner une forme aboutie, et n'a fait que circuler en privé. Bien que certaines choses ne soient peut-être plus tout à fait actuelles (notamment dans la deuxième partie), j'ai décidé de le publier ici car le propos général reste actuel, et souvent méconnu des personnes avec lesquelles je m'entretiens sur ces sujets, qui ne comprennent pas toujours pourquoi je déserte ou rechigne à utiliser certains moyens de communication.

Cet post est une suite de celui-là.

Différentes alternatives 

 

L'icône de WhatsApp

WhatsApp

Développée initialement par Jan Koum et Brian Acton, deux anciens collaborateurs de Yahoo!, WhatsApp est une application très populaire, acquise par Facebook en 2014. Il s'agit d'un service de messagerie propriétaire et centralisé. L'identification des utilisateurs·trices se fait sur la base de leurs numéros de téléphone et les messages transitent par les serveurs et n'y sont stockés que pendant une durée de 30 jours.

Depuis 2016, la plateforme active un chiffrement de bout en bout par défaut des conversations et des appels en implémentant le protocole de l'application concurrente Signal, présenté plus haut, et assurant une confidentialité persistante aux interlocuteurs·trices. Ce faisant, quoique appartenant à Facebook, WhatsApp a paradoxalement démocratisé ce type de chiffrement et la confidentialité qui l'accompagne auprès du grand public.

Si WhatsApp implémente des protocoles de chiffrement dont la qualité est reconnue et ne stocke pas les messages, l'emploi des numéros de téléphone comme identifiants de connexion, son appartenance à Facebook et son caractère propriétaire et centralisé posent problèmes :

  • Rien ne permet de vérifier la bonne implémentation des procédés utilisés : par exemple, rien ne permet de vérifier que le protocole de Signal est bien implémenté et que les clés de chiffrement délivrées aux interlocuteurs·trices par le serveur ne sont pas truquées ou ne contiennent pas de portes dérobées.
  • Les numéros de téléphones constituent des métadonnées particulièrement sensibles dans le mesure où la plateforme appartient à Facebook et qu'ils constituent des informations qui peuvent être recoupées avec celles issues d'autres applications appartenant à l'entreprise. Certains de ces recoupements sont effectifs depuis 2017 à des fins de sécurité et de lutte contre le spam, ou dans le but d'une monétisation de ces données lorsque que cela est accepté par l'utilisateur·trice.
  • WhatsApp peut prendre des décisions à tout moment et les imposer à ces utilisateurs·trices sans possibilité de recours (changement dans les fonctionnalités proposées, modifications des conditions d'utilisation du service...). En cas d'arrêt ou de dysfonctionnement du service, ce sont aussi tous·tes les utilisateurs·trices qui sont impacté·e·s.

A l'heure où j'écris ces lignes, ces deux derniers points sont particulièrement d'actualité, WhatsApp ayant pris la décision de rendre obligatoires des recoupements supplémentaires de données à des fins publicitaires et pour améliorer l'expérience de l'utilisateur·trice sur les différents "Produits Facebook". Si ces nouvelles conditions d'utilisation ne seront pas appliquées aux utilisateurs·trices européen·e·s, pour le moment du moins, ce changement brutal dans les conditions d'utilisation du service pour de nombreux utilisateurs·trices illustre le bien le pouvoir d'une plateforme centralisée détenue par une unique entité.

D'autres critiques peuvent aussi être formulées à l'égard de WhatsApp. Par exemple, l'obligation d'utiliser un smartphone pour utiliser la plateforme, ou certaines fonctionnalités problématiques comme la possibilité d'effectuer des backups de ses conversations et de ses médias dans des clouds non-chiffrés (Google Drive ou iCoud d'Apple), ou encore la future fonctionnalité permettant à WhatsApp d'accéder à une partie de la conversation en cas de signalement.

 

Icône de Signal

Signal

Signal est à la fois le nom d'une application de messagerie et du protocole de chiffrement de bout en bout qu'elle utilise. Lancée en 2014, l'application met en commun les fonctionnalités de deux applications existant depuis 2010, TextSecure (permettant le chiffrement des échanges SMS) et Redphone (permettant de passer des appels chiffrés). Elle est désormais maintenue par la Signal Fondation, une organisation sans but lucratif américaine co-crée par Moxie Marlinspike et Brian Acton (après que ce dernier ait quitté WhatsApp suite à la décision de Facebook d'opérer des recoupements de données des utilisateurs·trices avec celles issues des autres produits de Facebook).

Contrairement à WhatsApp, Signal est open source et affirme ne pas utiliser les données des utilisateurs·trices à d'autres fins que celles strictement nécessaires au fonctionnement du service. Signal implémente le chiffrement de bout en bout apportant une confidentialité persistante sur la base des protocoles développés par son créateur et chiffre par défaut l'ensemble des conversations. En cas de non-reconnexion de la ou du destinataire, les messages ne sont stockés que temporairement sur les serveurs.

La plateforme est recommandée par la Commission Européenne et mise en avant par l'Electronic Frontier Foundation, un organisme chargé de défendre les libertés individuelles des internautes. Pour ne rien gâcher, elle fait même l'objet d'une recommandation par Edward Snowden.

Malgré ces très bons points, Signal partage certaines critiques qui peuvent être adresses à WhatsApp : 

  • Bien qu'open source, l'architecture de l'application reste centralisée. Les utilisateur·trices sont donc dans l'obligation de faire confiance au serveur et à celles et ceux qui l'opèrent, tant pour l'acheminement de leurs messages que pour assurer la gestion de leurs clés de chiffrement.
  • Il est obligatoire de s'identifier avec son numéro de téléphone et de posséder un smartphone pour utiliser le service. Même si la plateforme n'appartient pas à une entreprise comme Facebook, de telles données restent peu anonymisantes et constituent des métadonnées sensibles accessibles à Signal.
  • En cas de modifications du service ou de ses conditions d'utilisation, les utilisateurs·trices n'ont pas d'autre alternative que d'accepter les changements ou de quitter la plateforme. En situation de dysfonctionnements ou d'arrêt du service, aucune alternative n'est possible non plus.

D'autres critiques peuvent être adressées à Signal comme la localisation de ses serveurs aux USA, sous loi américaine, l'usage d'un hébergement chez Google, l'utilisation longtemps obligatoire des services Google pour le fonctionnement des notifications, ou encore la procédure de vérification de clés de chiffrement simplifiée sous la forme de "nombre de sûreté", plus aisée pour les utilisateurs·trces, mais moins sécurisée en termes de sécurité cryptographique (critique qui pourrait d'ailleurs être faite à WhastApp aussi).

S'agissant d'une organisation sans but lucratif, soutenue seulement par les financements et par les dons, la structure centralisée de l'application pose enfin question pour son développement futur. Dans la mesure où toute personne souhaitant utiliser le service est tenue de s'inscrire auprès du même opérateur, ce dernier est nécessairement amené à voir son service prendre de l'ampleur et nécessiter un nombre croissant de ressources. A la mi-janvier 2021, alors que de nombreux·se utilisateur·trices se décident à adopter l'application suite à la décision de WhatsApp de modifier ses conditions d'utilisations, Signal voit ses serveurs surchargés et le service est inutilisable pendant plus de 24h. Si Signal devait accueillir autant d'utilisateurs·trices que WhatsApp, la Signal Fondation disposerait-elle des ressources nécessaires pour administrer le service et assurer sa maintenance à long terme, sans recourir à d'autres stratégies de monétisation ?

Telegram

Telegram a été créé en 2013 par les frères Nikolaï et Pavel Dourov, opposants à Poutine et connus en Russie pour être à l'origine de l'application VKontakte, pour assurer la sécurité de leurs communications face aux services secrets russes. La plateforme est en partie open source (coté client) et propriétaire (côté serveur). Un numéro de téléphone est requis pour s'inscrire mais il est possible de spécifier un nom d'utilisateur·trice pour entrer en contact avec d'autres personnes inscrites sur l'application. Un smartphone n'est en outre pas obligatoire et Telegram peut être installé sur ordinateur.

Pour sécuriser les échanges, Telegram propose ses propres algorithmes de chiffrement. Deux méthodes sont utilisées, engageant deux niveaux de confidentialités distincts : un chiffrement client-serveur, dans le cas des "Cloud Chat", sécurisant les communications durant leur trajet vers et depuis le serveur, et un chiffrement de bout en bout, dans le cas des "Secret Chat", sécurisant les communications entre deux interlocuteurs·trices.

Dans le premier cas, les échanges ne sont protégés que durant leur transport et apparaissent en clair sur le serveur où ils restent stockés (au Pays-Bas pour les utilisateurs européens). Le chiffrement des messages se fait avec une clé commune au serveur et à l'utilisateur·trice, déterminée à l'aide d'un échange de clés Diffie-Hellman. Les messages sont chiffrés avec cette clé et envoyés à Telegram, qui les déchiffre et les re-chiffre avec la clé utilisée par le ou la destinataire.

Cette manière de faire implique de faire confiance au serveur pour ne pas faire un mauvais usage des données qui lui sont lisibles et ne pas les modifier. Elle ne permet pas d'avoir une confidentialité persistante, et en cas de compromission de la clé d'un des interlocuteurs, tous les échanges stockés peuvent être déchiffrés.

Dans le second cas, des échanges de clés Diffie-Hellman sont effectués entre les deux appareils des interlocuteurs·trices. Le serveur ne sert alors que de transmetteur et les messages n'y font que transiter de manière chiffrées, ne pouvant être déchiffrés que par l'expéditeur et le destinataire. De nouveaux échanges de clés sont effectués à intervalles réguliers pour assurer une confidentialité persistante. Cependant, contrairement à l'algorithme de Double Ratchet de Signal, les clés symétriques utilisées ne font pas l'objet de dérivation à chaque message envoyé, et ces nouveaux échanges asymétriques n'interviennent que tous les 100 messages ou toutes les semaines. En cas de compromission d'une clé, c'est donc autant de messages qui pourraient être déchiffrés par un attaquant.

Relativement populaire, Telegram peut faire l'objet de plusieurs critiques :

  • Pour certains experts, la mise en place d'un chiffrement "maison"', par des non-experts en cryptographie, plutôt que de s'appuyer sur des mécanismes ayant déjà fait leurs preuves, est une démarche risquée en terme de sécurité.
  • Pour beaucoup d'utilisateurs·trices, la distinction entre les deux niveaux de confidentialité implémentés dans les Cloud Chat et dans les Secret Chat est peu connue : beaucoup des personnes qui utilisent l'application pensent ainsi - à tord - que leurs conversations sont chiffrées de bout en bout alors que ce n'est pas le cas. 
  • Le chiffrement de bout en bout n'est pas le mode par défaut appliqué aux conversations et il ne peut pas être utilisé pour les discussions de groupe.
  • L'infrastructure centralisée de l'application suppose de faire confiance aux serveurs et à ceux qui l'administrent, en particulier dans la situation où les conversations par défaut des utilisateurs·trices y sont stockées. Comme pour les solutions précédentes, la gestion centralisée de l'application place également les utilisateurs·trices dans une situation où il n'ont pas d'autre recours que de supprimer leur compte en cas de modification déplaisante du service ou de ses conditions.

Plus encore que pour Signal, dont l'infrastructure ne sert qu'à faire transiter les données et dont le développement est délégué à un organisme à but non lucratif, on peut s'interroger sur le futur d'une architecture centralisée appelée à grandir pour supporter la charge croissante des utilisateurs·trices et du stockage nécessaire aux "Cloud Chat". Une plateforme qui opère la gestion des communication de manière centralisée et propriétaire peut-elle rester durablement respectueuse des utilisateurs·trices tout en suppléant à ses coûts de fonctionnement ?

Icône d'Olvid
Logo de l'App Olvid, marque déposée —
https://www.olvid.io/fr/, marque déposée, https://fr.wikipedia.org/w/index.php?curid=13666553

Olvid

Lancée en 2019, Olvid se présente en toute modestie comme la messagerie « la plus sécurisée du monde ». En janvier 2021, alors que WhatsApp force de nombreux·se utilisateurs·trices à accepter de nouveaux recoupements de données avec la maison mère Facebook, Olvid s'affiche face à WhatsApp, Signal ou Telegram comme une alternative française, ne nécessitant pas d'identification par un numéro de téléphone, ne supposant pas de faire confiance à un serveur central et chiffrant ses métadonnées de manière à ce que le serveur ni aucun tiers n'ait pas la capacité « de savoir qui communique avec qui ».

A la différence des plateformes précédentes, Olvid conçoit ses serveurs comme des boîtes dans lesquelles les utilisateurs·trices glissent anonymement des contenus. Plutôt que de laisser au serveur le soin d'aiguiller les messages, ceux-ci y sont téléversés à la manière d'un document placé dans une Dropbox. Lorsqu'un message est reçu, le serveur notifie le client de l'utilisateur·trice, qui se connecte pour récupérer le contenu déposé et l'efface du serveur. Olvid envisage en outre un fonctionnement décentralisé où plusieurs serveurs Olvid pourraient co-exister. Ce n'est alors qu'au serveur de la ou du destinataire que sont adressés directement les contenus, sans transiter par d'autres serveurs.

Du point de vue du chiffrement, Olvid renforce la sécurité en imposant aux interlocuteurs·trices de vérifier leurs clés de chiffrement suite à leur premier échange de clé servant à établir un premier canal sécurisé. Cette vérification s'effectue au travers de la reconstitution d'un code de 8 chiffres qui doit être complété à moitié par l'un et par l'autre des participant·e·s. Un canal sécurisé est ensuite mis en place pour permettre l'échange d'une clé de chiffrement symétrique à partir de laquelle sont dérivées deux autres clés, l'une pour l'envoi et l'autre pour la réception des messages. Comme ses concurrents, Olvid prévoit un algorithme de rochet qui actualise régulièrement le chiffrement dans un sens comme dans l'autre afin d'assurer aux interlocuteurs·trices une confidentialité permanente. Cependant, comme pour Telegram, le cliquet n'opère que tous les 100 messages où toutes les semaines, risquant donc la compromission d'autant de messages en cas d'interception d'une clé symétrique.

Olvid, enfin, ne requiert pas de numéro de téléphone ou d'autre information personnelle. Seul, un lien vers le serveur de l'utiliateur·trice l'identifie auprès du système pour permettre l'acheminement des messages. Olvid affirme également ne pas conserver les adresses IP des connexions à son service.

Malgré les bons points cumulés par l'application, celle-ci n'est toutefois pas exempte de critiques : 

  • Pour stocker les données des utilisateurs·trices, Olvid utilise du stockage S3 hébergé par Amazon AWS. A peine mentionné dans ses conditions d'utilisation, ce détail n'en est pourtant pas un puisque les adresses IP peuvent ainsi être visible par ce prestataire, rendant caduque l'affirmation d'Olvid selon laquelle ni l'opérateur ni aucun tiers n'est en mesure d'identifier les utilisateurs·trices. Amazon est de surcroît un prestataire américain.
  • Bien qu'Olvid envisage la possibilité d'un fonctionnement décentralisé et affirme vouloir rendre son code open source, l'application n'est pour le moment ni open source ni décentralisée.
  • Pour le moment, Olvid n'existe que sur Android ou iOS et nécessite donc un téléphone ou une tablette.
  • L'interface d'Olvid n'est pas forcément aisée à appréhender et semble s'adresser avant tout aux entreprises. Certaines fonctionnalités, comme les appels audio ou vidéo, sont payantes. 
Logo d'XMPP
Raja SANDHU for XMPP Standards Foundation.Edited by Ludovic BOCQUET: A first time in September 2017 and a second time in September 2019. — https://xmpp.org/, MIT, https://commons.wikimedia.org/w/index.php?curid=20775269

OMEMO / XMPP

Anciennement Jabber, XMPP est un protocole ouvert permettant l'échange de messages instantanés et la gestion d'une liste et de données de contact. Il se présente en deux volets, l'un met en place les composants de base permettant au système de fonctionner, l'autre permet l'ajout de fonctionnalités au travers d'extensions, les "XEP" (XMPP Extension Protocols). OMEMO est l'une de ses extensions, permettant le chiffrement de bout en bout des conversations par l'implémentation de mécanismes similaires à ceux implémentés par Signal.

XMPP est un système de messagerie décentralisé. Les utilisateurs·trices inscrit·e·s sur un serveur peuvent communiquer avec d'autres inscrit·e·s sur un autre serveur, choisir quel prestataire leur convient le mieux et, s'ils le désirent, installer leur propre serveur. Lorsque le chiffrement est utilisé, les clés de chiffrement des utilisateurs·trices ne sont pas gérée par un serveur unique, empêchant de ce fait le risque de se voir attribuer des clés compromises.

Du côté de l'acheminement des messages, ces derniers ne font que transiter par les serveurs et n'y sont pas stockés sauf si le ou la destinataire est hors ligne (à l'exception des conversations de groupes, mais ce paramètre est réglable). L'identification des interlocuteurs·trices se fait au moyen d'un identifiant spécifique choisi par l'utilisateur·trice et non par un numéro de téléphone (sauf en cas d'usage de Quiksy, qui utilise alors les numéros de téléphone comme identifiants afin de présenter une ergonomie similaire à WhatsApp ou Signal). Les clients de messagerie laissent en outre le choix d'utiliser simultanément plusieurs comptes, et ainsi plusieurs identités, pour des contextes différents  (professionnel, familial,... ).

Du fait des caractéristiques relevées ci-dessus, l'écosystème d'XMPP offre plus de liberté et une meilleure confidentialité aux utilisateur·trices. Mais il a aussi ses inconvénients :

  • Il n'est pas évident de choisir à quel serveur confier ses données. Les serveurs n'implémentent en outre pas tous les mêmes XEP et n'implémentent donc pas nécessairement le chiffrement de bout en bout d'OMEMO. Ou n'implémentent pas les appels vocaux ou vidéo. 
  • Il n'est pas évident de choisir son client de messagerie. Tout comme les serveurs, tous les logiciels clients n'implémentent pas les mêmes XEP. Tous les clients n'activent pas non plus le chiffrement par défaut des communications. Enfin, tous les clients ne sont pas présents sur toutes les plateformes (Android, iOS, Windows, Mac ou Linux).
  • Du point de vue de l'expérience utilisateur·trice, beaucoup de logiciels clients ont une interface qui manque de lisibilité et d'esthétique.

Icône d'Element

Matrix - Matrix /Element

Créé en 2014, Matrix est d'abord un protocole développé au sein de l'entreprise américaine Amdocs, puis par la société "New Vector" basée au Royaume Uni. En 2018, une société à responsabilité limitée, la fondation Matrix.org, est créé. Plusieurs gouvernements et universités implémentent le protocole, dont l'Etat français pour sa messagerie sécurisée Tchap.

Comme XMPP, Matrix se veut un protocole de communication ouvert, prévu pour fonctionner dans une infrastructure décentralisée. L'identification ne passe pas par un numéro de téléphone et les utilisateurs·trices d'un serveur matrix peuvent communiquer avec d'autres, inscrit·e·s sur d'autres serveurs. En terme de facilité pour l'utilisateur·trice, la société qui développe Matrix développe également son client Element qui peut être utilisé sur toutes les plateformes et même au travers d'une interface web. Côté serveur, Matrix.org accueille aussi par défaut les nouveaux utilisateurs·trices sur son propre serveur.

A la différence des solutions de messageries précédentes, Matrix innove par une approche différente de la communication sécurisée. Plutôt que de rechercher à transporter des messages entre des serveurs ou des appareils, Matrix envisage la communication entre les interlocuteurs·ŧrices comme un "état partagé" entre les différents serveurs. Ainsi, même lorsqu'ils sont créés sur un serveur en particulier, les salons de discussions sont répliqués entre les différents serveurs des utilisateurs·trices. Cette manière de faire confère une grande résilience au système mais implique un stockage des messages, même sous forme chiffrée, sur les serveurs.

S'agissant du chiffrement de bout en bout, Matrix implémente deux protocoles distincts. Le premier, Olm, est utilisé dans le cas des conversations individuelles et consiste en une implémentation légèrement modifiée des échanges de clés Diffie-Hellman et de l'algorithme Double Ratchet de Signal. Le second, MegaOlm, est utilisé pour les conversations de groupe et simplifie la gestion des clés de chiffrement dans la situation où de nombreux·se utilisateur·ŧrices font partie d'un même groupe.

Dans ce cas, plutôt que de gérer une clé par appareil, une unique clé de session est générée pour l'utilisateur·trice à l'entrée de celui ou celle-ci dans la discussion et est utilisée par tous ses appareils. Ensuite, les clés chiffrant les nouveaux messages sont dérivés sur une base de chiffrement symétrique, sans nouvel échange asymétrique, sauf lorsqu'un membre rejoint ou quitte la conversation de groupe. Pour certains les experts, ce mode de fonctionnement est discutable. En effet, si un pirate accède à un statut du rochet, tous les messages qui suivent lui deviennent accessibles et de larges part de la conversation peuvent se retrouver compromises.

Matrix rend enfin possible les appels audio et vidéo grâce à une implémentation de jitsi, un logiciel de visoconférence basé sur XMPP.

Si Matrix cumule de bons points pour encourager l'adoption d'une plateforme décentralisée, certains points restent problématiques au-delà du chiffrement des conversations de groupe et du stockage des messages :

  • Par rapport à une solution comme XMPP, Matrix est particulièrement gourmand en ressources. Installer un serveur pour un cercle plus large que ses proches peut donc être onéreux. Au-delà du coût des installations, le problème est également écologique.
  • Le client officiel Element s'apparente plus à une forme de Discord et peut paraître déroutant par rapport à une application de messagerie instantanée classique. Un client comme FluffyChat propose une expérience différente s'approchant plus d'une interface de messagerie classique, mais les appels ne sont pas encore implémentés et doivent passer par l'application jitsi sur appareil mobile.
Icône de Delta Chat

Delta Chat

Peu connu, Delta Chat tient une place à l'écart dans le contexte des messageries instantanées. Plutôt que nécessiter l'intermédiaire d'un serveur dédié à l'usage de la messagerie instantanée, Delta Chat se présente comme un client mail qui se sert du compte mail de l'utilisateur·trice mais met en forme les messages de manière à produire une expérience propre à la messagerie instantanée. L'application n'intègre pas, en revanche, d'appels audio ou vidéo.

Disponible sur toutes les plateformes, Delta Chat est facilement installable sur son smartphone ou son ordinateur et une synchronisation est possible entre plusieurs plateformes. Si l'hébergeur mail est compatible (ça n'est pas le cas d'Hotmail, Protonmail ou Tuanota), l'inscription est aisée et se fait à l'aide des identifiants mail de l'utilisateur·trice, même si elle peut nécessiter quelques manipulations supplémentaires lorsque l'adresse mail est hébergée chez un prestataire comme Gmail ou YahooMail!.

Décentralisé de fait, et employant l'email, Delta Chat permet à ses utilisateurs·trices de communiquer de manière non-chiffrée avec des personnes n'ayant pas installé l'application. Avec les personnes qui disposent de celle-ci (ou d'un autre client supportant la norme "Autocrypt Level 1"), Delta Chat chiffre en revanche les messages de bout en bout. Ce chiffrement est basé sur openPGP et n'offre pas de confidentialité  persistante comme les solutions présentées précédemment, ceci en raison du caractère asynchrone de l'email, qui  rend impossible un mécanisme de rochet comme celui du protocole de Signal. Ainsi en cas de compromission de la clé privée d'un participant·e, l'attaquant peut avoir accès aux nouveaux messages mais aussi à l'historique de l'utilisateur·ŧrice.

Mais d'autres problèmes de confidentialité peuvent aussi être évoqués :

  • Dans le cas des conversations ou des groupes où les clés de chiffrement des participant·e·s n'ont pas été vérifiées, les messages peuvent cesser d'être chiffrés à tout moment si un·e utilisateur·trice désactive le chiffrement de bout en bout ou cesse d'utiliser Delta Chat.
  • Même si le contenu des messages est chiffré, certaines métadonnées restent en clair dans l'en-tête des messages et ceux-ci restent par défaut stockés dans le serveur de messagerie (d'abord dans la boite de réception puis dans un dossier dédié). La question de la confiance octroyée à un fournisseur de messagerie instantanée dans les cas précédents est donc en partie reportée sur le fournisseur email, qui n'a pas accès aux échanges mais est en mesure d'identifier qui fait partie d'une discussion ou d'un groupe.