A propos des messageries instantanées (Partie 1) - Une exploration de leurs architectures et de leur fonctionnement
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.
« Parlons-nous via XMPP ou Matrix .»
Depuis plusieurs mois, telle est la petite phrase que j'associe à mon compte Whatsapp. En temps normal, il est assez rare qu'elle soit relevée et qu'on m'interpelle à son sujet. Pourquoi utiliser autre chose, alors que Whatsapp « fonctionne si bien » ? Pourquoi utiliser autre chose, alors que « tout le monde est dessus » ? Pourquoi vouloir trouver plus de sécurité ailleurs, alors que Whatsapp affirme « chiffrer les messages de bout-en-bout », d'une façon que « même Whatsapp ne parvient pas à les déchiffrer » ?
Pourtant, à l'heure où WhatsApp a pris la décision de recouper les données de ses utilisateurs·trices non-européen·e·s, un nombre croissant de personnes s'intéressent peu à peu aux alternatives. Signal, Telegram, ou encore la récente application Olvid, ont le vent en poupe.
L'objectif de cet article est d'aborder le fonctionnement de ces messageries instantanées et de donner des clefs pour comprendre ma préférence pour certains outils. Pour discuter les différentes alternatives, j'envisagerai d'une part la qualité du chiffrement qu'elles proposent et d'autre part les enjeux liés à l'architecture et au design de ces plateformes.
Qu'est-ce que le chiffrement et comment fonctionne-t-il ?
Chiffrements symétriques et asymétriques
D'après la définition du dictionnaire Larousse, le chiffrement est défini comme « une opération qui consiste à transformer un message, dit « message clair », en un autre message, inintelligible pour un tiers, dit « message chiffré », en vue d'assurer le secret de sa transmission. » L'idée de base est simple : l'interlocuteur·trice chiffre le message avec une clé de chiffrement (un décalage de lettres dans l'alphabet, un nombre, une phrase de passe, etc...), qui est connue du ou de la destinataire·trice, et qui est utilisée pour déchiffrer le message. On appelle cela le chiffrement symétrique.
Dans le contexte de la sécurité des réseaux, où des interocuteurs·trices et des machines communiquent à distance, l'utilisation d'un chiffrement symétrique nécessitant le partage d'une même clé de chiffrement est risqué : celle-ci pourrait en effet être interceptée par une tierce personne qui aurait alors accès aux messages.
Pour les échanges en-ligne, on a donc recours à un autre type de chiffrement, dit chiffrement asymétrique : un système où les interlocuteurs·trices produisent deux de clés de chiffrement distinctes, l'une étant envoyée au destinataire (dite clé « publique ») tandis que l'autre est tenue secrète (dite clé « privée »). Lorsque ce type de chiffrement est utilisé, le message envoyé est chiffré avec la clé publique du ou de la destinataire qui est ensuite le ou la seul·e à pouvoir déchiffrer l'information à l'aide de sa clé privée.
La vidéo « Les codes secrets » de Science Étonnante offre une bonne explication pédagogique sur le chiffrement, allant du chiffrement symétrique au chiffrement asymétrique : https://invidious.fdn.fr/watch?v=8BM9LPDjOw0
Pour des raisons de performances, le chiffrement asymétrique peut aussi jouer le rôle d'un cocon dans lequel se négocie une clé de chiffrement cette fois-ci symétrique, sur laquelle s'appuieront par la suite les échanges entre les utilisateurs·trices. Dans ce cas, le chiffrement asymétrique ne sert qu'à initier une session de chiffrement symétrique, en rendant impossible l’obtention de la clé de chiffrement par une personne se trouvant sur le chemin. C'est ainsi que fonctionne l'HTTPS (voir ci-dessous) ainsi que certains protocoles utilisés dans le contexte des messageries instantanées.
Le chiffrement dit « de bout en bout »
Lorsqu'il est question de chiffrer les communications en-ligne, deux stratégies (pour simplifier) existent :
La première consiste à sécuriser la connexion entre deux machines. On connaît tous·tes le petit cadenas qui s'affiche en haut du navigateur tandis que nous surfons sur internet. La plupart des sites internet d'aujourd'hui utilisent en effet une connexion chiffrée grâce au protocole HTTPS. Ce dernier garantit d'une part que les données que nous échangeons avec le site (un numéro de carte bancaire, un mot de passe,... ) ne circulent pas « en clair » (c'est à dire « lisiblement ») sur le réseau, et d'autre part, il atteste que le site avec lequel nous communiquons est bien celui que nous pensons visiter, et que son contenu n'a pas été modifié en cours de route (par exemple, qu'il s'agit bien du site de notre banque et non d'un site frauduleux).
Pour en savoir plus sur l'HTTPS, vous pouvez visionner la vidéo de Monsieur Bidouille à ce sujet : https://video.monsieurbidouille.fr/videos/watch/9f4ae31b-efaa-4fb6-a8ef-50e2baf35e85
Dans ce cas de figure, la sécurisation des données intervient durant leur transport vers le serveur et depuis celui-ci. Le contenu de la communication lui-même n'est pas chiffré, en revanche, lorsqu'il se trouve sur le serveur. Ainsi, les photos que j'envoie à mes ami·e·s par l'intermédiaire de plateformes comme Facebook ou Instagram ne pourront être interceptées par un pirate qui se situerait entre mon ordinateur et les serveurs de Facebook. Cependant, même lorsqu'elles ne sont partagées qu'avec certaines personnes précises, elles sont lisibles pour Facebook. Elles pourraient donc être accessibles à un employé de l'entreprise qui dispose légitimement des accès - ou à un attaquant il y accéderait illégitimement.
Lorsqu'un chiffrement de bout en bout est utilisé, en revanche, les données sont chiffrées tant durant leur transport qu'au niveau du serveur qui les fait transiter. Ainsi, lorsque j'envoie un message ou une image sur une plateforme comme Whatsapp qui affirme « chiffrer les conversations de bout en bout », ceux-ci sont chiffrés de façon à ce que seuls moi et mes destinataires puissions en lire le contenu.
Le protocole de Signal, une référence en la matière
Pour assurer le chiffrement de bout en bout, WhatsApp et d'autres applications partagent un fonctionnement similaire qui se distingue par la manipulation de différents types de clés de chiffrement (symétriques et asymétriques, à long terme ou éphémères) et l'implémentation de deux mécanismes, développés par Trevor Perrin and Moxie Marlinspike pour leur messagerie TextSecure (devenue par la suite Signal), et spécifiés publiquement en 2016. Le premier consiste en un échange étendu de clés éphémères Diffie-Hellman (X3DH) et le second dans un algorithme dit, de « double rochet » (Double Ratchet).
En premier lieu, l'échange étendu de clés éphémères Diffie-Hellman a pour but d'assurer la confidentialité initiale des échanges. Avant d'envoyer leur premier message chiffré, les interlocuteurs·trices échangeant des clés éphémères signées par leur clé privée pour définir une valeur commune - le secret racine de session - qui servira à établir une première clé de chiffrement symétrique avec laquelle chiffrer le premier message, sans que celle-ci ne puisse être interceptée par une tierce personne. Afin d'assurer une « confidentialité persistente » (voir ci-dessous) dès le premier message, et ce y compris si l'interlocuteur·trice est hors ligne et ne peut participer à l'échange de clé, Signal prévoit dans cette étape l'utilisation possible de clés à usage unique générées lors de la première connexion de l'utilisateur·trice et pouvant être envoyée par le serveur à la personne souhaitant initier un échange.
En second lieu, après l'établissement initial de la session, l'algorithme de Double Ratchet a pour rôle de faire évoluer les chiffrements symétriques et asymétriques au fil de la conversation, d'une part par une dérivation du chiffrement symétrique, à chaque message envoyé (en cas de monologue par la même personne), et d'autre part, par l'exécution d'un nouvel échange Diffie-Hellman, permettant d'actualiser le secret racine de la session, dès la réception d'un message.
Déjà présent dans le protocole OTR lancé en 2004, le concept de « ratchet », ou « rochet », en français, peut être directement rapproché du fonctionnement de la roue mécanique du même nom : une roue à cliquet dont la forme ne permet pas d'inverser le sens de rotation :
La référence à la roue à rochet met en évidence une propriété fondamentale de ce type d'algorithmes, celle de garantir une « confidentialité persistente ». Cette propriété signifie qu'en cas de compromission d'une clé privée d'un·e des participant·e·s, les messages échangés précédemment ne peuvent pas être déchiffrés. L'imbrication des deux mécanismes de rafraîchissement des secrets symétriques et asymétriques garantissent également que la compromission d'une clé symétrique ne peut conduire qu'au déchiffrement d'un unique message.
Considérés comme très fiable, et sécurisant jusqu'à chaque message individuellement, les mécanismes qui précèdent sont implémentés par Signal et WhatsApp mais également, à quelques différences près, par des systèmes comme XMPP (OMEMO) et Matrix (Olm).
Pour plus d'informations sur les protocoles de chiffrement utilisés par Signal et OMEMO, vous pouvez vous référer à l'article de Florian Maury « Chiffrement de messagerie quasi instantanée : à quel protocole se vouer ? » publié sur le blog du magazine MISC en 2017.
Infrastructure et design
En s'intéressant au fonctionnement des messageries instantanées, le chiffrement n'est pas le seul enjeu technique. Même lorsque nos messages font l'objet d'un chiffrement « de bout en bout », certaines informations restent accessibles et peuvent être collectées par les fournisseurs des services que nous utilisons. Il s'agit de « métadonnées ». Celles-ci sont par exemple, notre adresse IP, un identifiant unique lié à notre compte (un numéro de téléphone, un e-mail, un pseudonyme), les horaires, la fréquences et les destinataires de nos communications.
D'autres questions se posent donc en termes de sécurité et de confidentialité : Où se trouvent les serveurs qui relaient les messages ? A qui appartiennent-ils ? Comment opèrent-ils la gestion de nos contacts ? Que font-ils des données ou des métadonnées qu'ils détiennent ? Stockent-ils les messages qu'ils font transiter ? Et si oui, combien de temps les données stockées restent-elles dans ces serveurs ?
Centralisation versus décentralisation ou fédération
La plupart des services de messageries instantanées s'appuient sur une architecture centralisée. Ceci signifie que les données de tous·tes les utilisateurs·trices transitent ou sont stockées sur des machines appartenant à la même entité (personne, entreprise, organisation...). Pour communiquer avec les autres personnes inscrites, l'utilisateur·ŧrice est obligé·e de s'inscrire également sur la même plateforme.
D'un point de vue technique, les avantages d'une telle architecture sont la « simplicité » d'administration et de développement du service. De celui de l'utilisateur·trice, la simplicité se manifeste dans le cadre de la procédure d'inscription et lors de l'utilisation du service qui se fait au travers d'une unique et même application, implémentant toutes les fonctionnalités offertes par le service, et partagée par tous·tes les utilisateurs·trices.
Mais si cette architecture a ses avantages, elle a aussi ses inconvénients. En premier lieu, dans le cas d'un dysfonctionnement, ce sont tous·tes les utilisateurs·ŧrices du service qui sont impacté·e·s. En cas d'attaque, ce sont aussi les données de l'ensemble des utilisateurs·trices qui peuvent être compromises. Enfin, le traitement et la concentration des données entre les mêmes mains conduit à une situation où les utilisateurs·ŧrices sont en quelque sorte à la merci du fournisseur de service. En effet, en cas de changement (modification d'une fonctionnalité ou changement dans les conditions d'utilisation du service) ou d'une interruption de celui-ci, aucun recours ou alternative n'est possible. La centralisation d'un service facilite également sa censure administrative par certains gouvernements qui ne souhaitent pas que leurs citoyens y accèdent.
Une architecture décentralisée, ou fédérée, au contraire, implique la répartition des données des utilisateurs·trices en plusieurs points du réseau. Dans cette situation, la communication entre les utilisateurs·trices est régie par un protocole commun mais les données sont stockées et traitées par des gestionnaires et des ressources différents. La situation est similaire à l'email : une personne disposant d'un compte chez YahooMail! pourra communiquer avec une personne ayant créé un compte chez Google (Gmail) et vice versa. Si la décentralisation se conjugue avec une ouverture du code et des protocoles, chaque personne qui le souhaite et dispose des ressources financières et des compétences techniques pour le faire peut aussi mettre en place son propre serveur - appelé parfois « instance » -, et ainsi stocker ses propres données.
Par rapport à une infrastructure centralisée, une telle structure rend le système plus résiliant. En cas de dysfonctionnement, ou en cas d'attaque, tous les utilisateurs·trices du réseau ne sont pas impacté·e·s. L'existence de différents serveurs laisse également plus de liberté et d'agentivité aux utilisateurs·trices puisqu'en cas de modifications du service ou de fermeture d'un nœud du réseau, elle leur offre la possibilité de s'inscrire ailleurs sans perdre la possibilité de communiquer avec leurs contacts.
En revanche, une infrastructure décentralisée est plus difficile à développer et à faire évoluer. Toute mise à jour de fonctionnalité ou de sécurité doit en effet assurer une rétro-compatibilité avec les versions précédentes du logiciel puisque les différents nœuds du réseau ne seront pas mis à jour en même temps.
Elle doit également faire consensus parmi tous·tes les contributeurs·trices au projet.
Du côté de l'utilisateur·trice, elle implique aussi des incertitudes : où s'inscrire ? comment choisir le serveur auquel confier ses données ? comment être certain·e de la sécurité d'un nœud du réseau ?
Code propriétaire versus code ouvert ou libre
Un second critère relevant concerne le code de l'application utilisé. Un code propriétaire est un code fermé qui n'est pas accessible pour les utilisateurs·ŧrices. Celles-ci et ceux-ci sont alors contraint·e·s de croire sur parole le prestataire de service sur la façon dont ce dernier fonctionne.
Un code ouvert ou libre, au contraire, permet à celles et ceux qui le souhaitent, et qui en ont les capacités, de lire le code de l'application pour vérifier qu'il effectue bien ce qu'il prétend effectuer. Même si tout le monde n'est pas en mesure de comprendre un code informatique, une telle approche renforce la sécurité d'une application et garantit à l'utilisateur·trice que la manipulation qui est faite de ses données correspond bien à ses attentes. Une faille ou une mauvaise implémentation peuvent en effet être rapidement identifiées.
Comme écrit ci-dessus, il permet aussi à toute personne d'installer son propre serveur, possibilité à laquelle s'ajoute également celle de proposer un fork du logiciel, c'est à dire de créer un nouveau logiciel à partir de code source d'un logiciel existant, dans le cas où la direction prise par le développement de ce dernier est déplaisante pour certain·e·s utilisateurs·ŧrices.
Transit versus stockage des messages
Un troisième critère concerne la durée pendant laquelle les messages sont stockés sur les serveurs du prestataire de service. Dans le cas d'une application comme WhatsApp, les messages ne font que transiter par les serveurs et n'y sont stockés que dans le cas où le ou la destinataire est hors ligne, et cela durant une durée limitée de temps, dans le cas où celui ou celle-ci ne se reconnecte pas.
D'autres services stockent au contraire les messages. Ceci permet à l'utilisateur·trice de retrouver le contenu de ses conversations en cas de réinstallation de l'application ou de connexion avec un nouvel appareil. Cependant, le stockage en ligne des communications assure une confidentialité moindre que lorsque les messages et les médias envoyés sont récupérés et stockés sur les appareils des interlocuteurs·trices, pouvant ainsi être effacés à tout moment s'ils ou elles le désirent.
S'identifier avec un numéro de téléphone et un smartphone
Un dernier paramètre qu'il est utile de prendre en considération concerne la manière d'identifier l'utilisateur·trice. Une application telle que WhatsApp - mais c'est également le choix de Signal et de Telegram - utilise le numéro de téléphone des utilisateurs·trices comme identifiant pour se connecter au service.
S'agissant d'une messagerie instantanée qui fait transiter les messages par internet, aucune nécessité technique n'impose d'identifier les utilisateur·ŧrices par ce moyen-là. Si celui-ci apporte des facilités (il est alors aisé de découvrir qui, dans ses contacts, utilise ou non l'application) et découle probablement d'une continuité avec les échanges SMS/MMS, il pose différents problèmes :
- Le numéro de téléphone est loin d'être une donnée anonymisante et constitue une métadonnée sensible qui est connue par le prestataire de service, même lorsque le contenu des messages est chiffré. Dans le cas d'une infrastructure centralisée, le prestataire de service est en outre à même de géolocaliser et de tracer le graph social de l'ensemble des utilisateurs·trices, dont il connaît aussi la fréquence des échanges.
- Une utilisation confortable du service suppose que l'utilisateur·trice partage sa liste de contacts avec le serveur afin d'identifier lesquels de ses contacts utilisent l'application. Même lorsque les numéros sont partagés sous une forme altérée (par exemple, par une fonction mathématique de hashage), il n'est pas forcément impossible de retrouver les numéros de téléphone à partir de cette forme détournée. L'usage de ceux-ci peut aussi donner lieu à des failles côté client. C'est ainsi que Tristan Granier, en détournant une fonctionnalité permettant d'effectuer une recherche par contact téléphonique, est parvenu à extraire de WhatsApp des numéros de personnalités publiques françaises.
- Du point de vue de l'utilisateur·trice, l'obligation de partager son numéro de téléphone peut apparaître problématique dans le cas de la participation à un groupe constitué de personnes qui ne sont pas préalablement dans ses contacts (groupe constitué autour d'un intérêt commun, par exemple).
Dans certains cas (WhatsApp, Signal), l'utilisation du service requiert également la possession d'un smartphone, même lorsqu'une application pour ordinateur indépendante existe (Signal). S'agissant de messageries se voulant sécurisées, ce choix est discutable lorsqu'on sait à quel point les smartphone sont des appareils généralement peu respectueux de la vie privée des utilisateurs·ŧrices.
Suite avec le passage en revue de différentes alternatives : ici.