Signal, le service de messagerie chiffrée.
En quelques mots
Signal désigne à la fois un protocole de chiffrement bout-en-bout et un service de messagerie basé sur ce protocole. Développé par la fondation du même nom et introduit en 2014, il est multi-plateforme, et disponible pour Android, iOS, Windows, Apple et les distributions Linux Debian.
Open-source et gratuit, Signal vous permet d’échanger des messages, des contenus média, des fichiers, ainsi que de passer des appels audio et vidéo avec un ou plusieurs destinataires. Son code source, accessible à tous (https://github.com/signalapp/), est régulièrement audité par des professionnels. De nombreux autres services de messagerie (open source ou propriétaire) affirment se reposer intégralement ou partiellement sur le protocole de Signal : WhatsApp et Messenger dans leur fonctionnalité « conversation secrète », ou encore Skype.
Considéré comme le protocole le plus sûr, Signal est notamment plébiscité par Edward Snowden, le PDG de Twitter Jack Dorsey ou le cryptologue renommé Bruce Schneier.
Pourquoi utiliser Signal ?
Pour protéger vos communications et accéder à un service de messagerie sûr, Signal est une excellente option. Son protocole de chiffrement de bout en bout garantit la confidentialité de vos échanges, et votre adresse IP est masquée pour une navigation anonyme. De plus, il vous propose des appels audio et vidéo de haute qualité, ainsi que le partage de fichiers de toutes tailles.
En suivant ce guide (non exhaustif) qui vous aide à prendre en main l’application, vous pourrez utiliser Signal en toute sécurité et profiter de toutes les fonctions de l’application, en toute tranquillité. Signal vous propose une aide complète pour une prise en main facile et une utilisation optimale.
Signal : une référence en matière de sécurité
Signal s’est imposé comme une référence en matière de messagerie sécurisée dans le monde entier, et continue d’intégrer de nouvelles fonctionnalités pour améliorer l’expérience utilisateur tout en renforçant la sécurité.
Rappel sur le chiffrement de bout-en-bout
Le chiffrement de bout en bout (end-to-end encryption, ou E2EE) consiste à chiffrer un échange entre 2 interlocuteurs de sorte qu’aucun intermédiaire (fournisseur d’accès internet, serveur de messagerie, routeurs, …) ne dispose de moyen de déchiffrer cet échange. C’est comme si l’on faisait transiter l’information dans un coffre-fort que seul le destinataire et l’expéditeur peuvent ouvrir avec un mot de passe. De plus, de nombreux outils de chiffrement sont disponibles gratuitement sur internet, ce qui aide à protéger vos communications.
Comprendre l’importance du chiffrement de bout en bout est assez simple. Imaginez que vous devez envoyer une information confidentielle à un ami. Sans chiffrement, n’importe qui pourrait intercepter et lire votre message. Avec le chiffrement de bout en bout, vous créez un canal sécurisé que seuls vous et votre ami pouvez déchiffrer.
Il est intéressant de noter que les 2 méthodes ne sont pas incompatibles et peuvent être utilisées conjointement : on peut très bien chiffrer via un protocole comme Signal (couche 7 du modèle OSI), et imposer que les échanges soient chiffrés entre les différents intermédiaires via TLS (couche 3). Choisir de combiner ces méthodes permet de créer un système de sécurité à plusieurs niveaux, rendant encore plus difficile l’accès à vos données par des personnes non autorisées.
Les différents problèmes à résoudre
Il est intéressant de noter que les 2 méthodes ne sont pas incompatibles et peuvent être utilisées conjointement : on peut très bien chiffrer via un protocole comme Signal (couche 7 du modèle OSI), et imposer que les échanges soient chiffrés entre les différents intermédiaires via TLS (couche 3). Choisir de combiner ces méthodes permet de créer un système de sécurité à plusieurs niveaux, rendant encore plus difficile l’accès à vos données par des personnes non autorisées.
Les différents problèmes à résoudre
Nous allons maintenant nous pencher sur ce qui fait la force du protocole Signal. Admettons que nous souhaitions créer notre propre protocole de chiffrement pour des communications de type chat, commençons par lister les problèmes que nous aurions à résoudre.
Confidentialité
Comme souvent en cryptographie, la difficulté de mise en place d’un protocole « parfait » réside dans l’échange initial des clés entre les 2 parties.
Le premier problème qui se pose est celui de la confidentialité de l’échange. En effet, dans la mesure où on ne contrôle pas tous les nœuds du réseau, on doit se méfier des intermédiaires et d’éventuelles écoutes/interceptions (NEVER TRUST THE NETWORK !). Le cryptage de bout en bout est donc essentiel pour garantir la confidentialité des échanges, notamment lorsque vous partagez des pièces jointes avec vos contacts.
Pour renforcer la sécurité de vos communications, il est crucial de vérifier que la plateforme que vous utilisez pour échanger des informations est bien sécurisée. Assurez-vous que l’URL commence par “https://” et qu’un cadenas vert s’affiche dans la barre d’adresse. Cela indique que le site utilise un protocole de sécurité pour protéger vos données. De plus, il est important de protéger vos fichiers et vos documents en utilisant un mot de passe complexe et en évitant de les partager avec des personnes non autorisées. N’oubliez pas que la sécurité en ligne est un travail de tous les jours.
Historiquement, ce problème très commun a d’abord été résolu par la création en 1976 du protocole Diffie-Hellmann, permettant l’échange de clé sur un canal non sécurisé. Ce protocole, robuste dans le concept, présente en revanche le défaut de ne pas fournir d’authentification entre les 2 parties.
Un attaquant souhaitant se positionner au milieu de la communication de façon passive peut ainsi très facilement se faire passer pour l’autre partie auprès de chacun des 2 correspondants (on parle d’attaque man-in-the-middle) et relayer les communications sans que personne ne puisse s’en rendre compte. Imaginez les dégâts potentiels pour une entreprise !
Asynchronisme et sécurité : un défi de taille
Outre l’absence de confiance en le réseau, un autre problème à résoudre réside dans l’aspect asynchrone des échanges. En effet, dans un certain nombre de cas, comme celui du très répandu protocole TLS (utilisé pour HTTPS notamment), on se trouve dans une situation dite « synchrone », c’est-à-dire que la communication n’a lieu que lorsque le client et le serveur sont en ligne, si le serveur est injoignable, il n’y a simplement pas d’échange. De cela résulte que les clés de chiffrement utilisées pour la session sont générées instantanément dès la communication engagée, ce qui laisse une fenêtre de temps extrêmement courte à un attaquant pour tenter une cryptanalyse.
Or, pour un protocole de discussion textuelle, il faut envisager que le téléphone de l’un des protagonistes ne soit pas connecté. Cela implique que les clés utilisées lors de l’échange initial soient stockées sur le serveur central jusqu’à ce que la communication puisse être établie. Cela laisse donc à un attaquant potentiel davantage de temps pour tenter de casser les clés utilisées, et pose un problème : il faut stocker les clés et s’assurer que celui qui vient les chercher est légitime. Des solutions payantes peuvent offrir des options de sécurité renforcées pour la protection de donnée.
La persistance des messages ou le perfect forward secrecy
Le dernier problème à résoudre est un autre classique de la cryptographie. Encore une fois, on suppose qu’avec les ressources nécessaires, un attaquant peut finir par casser un secret. Admettons qu’un adversaire coriace et obstiné a enregistré tous les échanges effectués sur un canal chiffré depuis 6 mois entre vous et votre interlocuteur. Avec du temps et des ressources en calcul, il a finalement réussi après quelques mois à « casser » le chiffrement d’un des messages, peut-il de fait lire tous les autres messages ?
Ce problème, qui se pose pour tous les échanges « longue durée », s’appelle le perfect forward secrecy (PFS pour les intimes). Expliqué autrement, cela consiste à s’assurer que si un secret est révélé, les secrets ultérieurs et antérieurs ne sont pas mis en danger, ce qui nécessite la création de nouvelles clés indépendantes des clés précédentes, et une mise à jour des clés à chaque échange. C’est une option essentielle pour se prémunir contre le spam et les attaques ciblées.
La réponse apportée par Signal
Pour résoudre tous ces problèmes, le protocole Signal se repose sur un ensemble de protocoles sous-jacents astucieusement imbriqués. Nous allons tenter ici de résumer ce qui fait l’intérêt de ce protocole.
Pour les plus avides de détails techniques, vous trouverez en bibliographie le lien vers davantage d’explications.
Pour résoudre le premier problème, celui de l’échange de clé, Signal se repose sur une encapsulation du fameux Diffie Hellmann (« DH »), appelée Extended Triple Diffie-Hellman (X3DH). Toujours afin d’améliorer la sécurité, cette version de DH n’est ici plus basée sur des problèmes d’arithmétique modulaire comme dans sa version initiale, mais sur des courbes elliptiques, un joli objet mathématique aux propriétés fort intéressantes en cryptographie (clés relativement courtes, ce qui permet des gains en temps de calcul, mais pour lesquelles les attaques sont extrêmement fastidieuses). C’est un élément essentiel à intégrer dans votre stratégie de sécurité.
Pour résoudre le deuxième problème, celui de l’asynchronisme, les clés du X3DH, servant à l’établissement du secret, sont stockées sur le serveur central, attendant d’être récupérées par l’interlocuteur. Un mécanisme appelé SESAME (Secure European System for Applications in a Multi-vendor Environment), permet de gérer l’authentification des appareils lorsqu’ils viennent interroger le serveur, évitant ainsi qu’un imposteur ne puisse entamer la conversation à la place de votre interlocuteur légitime. Ce guide vous aidera à mieux comprendre son fonctionnement.
Double Ratchet : le garant de la confidentialité à long terme
Enfin, pour régler la question du perfect forward secrecy, un mécanisme avancé de dérivation de clé (génération d’une clé en se basant sur une clé pré-existante) permet de gérer le renouvellement des clés pour chaque message : le protocole Double Ratchet (« double roue crantée » en français). Créé en 2013, il a été annoncé et détaillé avec la sortie du protocole Signal et constitue donc son atout majeur. Pour l’anecdote, ce nom fait référence au fait que sur une roue crantée, on peut procéder à des itérations dans un sens mais pas dans l’autre. Il est crucial de l’intégrer pour se protéger du spam.
Signal offre une grande limite de sécurité et de confidentialité pour tous vos échanges. Sa conception ingénieuse lui permet de résoudre les problèmes clés de la communication chiffrée, en faisant un outil de choix pour les utilisateurs soucieux de la protection de leurs données.
Double Ratchet, en s’appuyant sur les échanges de clés DH, permet aux interlocuteurs de calculer indépendamment la même clé de session renouvelée pour chaque message, sans qu’un attaquant ne puisse obtenir d’information sur la clé à venir. Admettons qu’une clé de session soit révélée, les interlocuteurs peuvent dormir sur leurs 2 oreilles : il n’est pas possible d’extrapoler ni les clés précédentes, ni les clés suivantes.
Toute l’astuce du Double Ratchet réside donc dans le couplage du mécanisme de dérivation avec celui du DH, permettant ainsi de s’assurer que les clés soient renouvelées à chaque message, sans qu’aucune clé ne soit envoyée jamais sur le réseau, même chiffrée.
Figure 5 :
« Signal ? Ouais ça fonctionne avec du X3DH sur des courbes elliptiques X525519 et X448, la signature c’est ECDSA, et après il y a un Double Ratchet pour gérer le PFS, et SESAME pour l’asynchro, je t’explique tout ça autour d’un verre ? »
« Mmmmh non merci, je suis #TeamTelegram »
Pour les plus observateurs d’entre vous, un problème reste à résoudre. C’est celui du man-in-the-middle, car comme on l’a dit, le protocole DH ne traite pas de l’authentification.
Une vérification par SMS est faite par Signal, afin d’associer un numéro de téléphone avec un jeu de clés publiques. Néanmoins le SMS reste une donnée relativement peu fiable pour associer un appareil à un individu. Un mécanisme de vérification dit out-of-band (hors-bande) permet ainsi de s’assurer de façon définitive que l’échange n’a pas été intercepté. De façon générale, il s’agit en effet du seul moyen d’écarter le doute concernant le système d’annuaire (qui lie une identité et une clé).
Pour valider que l’échange était bien confidentiel et l’a toujours été, il faut donc s’assurer avec son/ses interlocuteurs (par un biais autre que Signal, il va sans dire) que l’on retrouve bien sur notre application le même code propre à la communication en question.
Ce code, résultant du protocole « Double Ratchet », s’appuie en effet sur l’idée que les interlocuteurs peuvent arriver à un même résultat de calcul qui est impossible à résoudre pour un acteur externe, même s’il a écouté tous les échanges.
Pour chaque conversation, un code est ainsi consultable par chacune des 2 parties (ou plus), si ce code n’est pas le même, c’est qu’il y a nécessairement eu interception, et qu’il y avait un man in the middle.
Comparaison avec d’autres systèmes de messagerie
Si Signal est considérée comme l’une des messageries les plus sûres au monde, c’est donc grâce à la robustesse du protocole sur laquelle elle se repose, ainsi que de sa démarche open-source, qui favorise l’auditabilité. Parmi les nombreuses applications de messagerie sécurisées (Telegram, Whatsapp, Mattermost, Viber, Mumble, …) beaucoup se reposent sur d’autres protocoles, dont le détail du fonctionnement nécessiterait d’autres articles.
Le protocole Signal n’a cependant à ce jour, jamais été hacké et reste considéré comme ce qu’il y a de plus sûr. Par souci évident d’indépendance, je vous recommande cependant de rester sur la version « officielle » de Signal, et d’éviter les applications propriétaires qui « enrobent » ce protocole open-source sans expliquer les contours de leur travail.
Quelle que soit la messagerie que vous utiliserez, renseignez-vous un minimum sur son fonctionnement et ses réglages par défaut. Au-dessus de 2 utilisateurs, Telegram désactive par exemple le end-to-end, de même que le chiffrement n’est pas activé sur Messenger par défaut.
De même, Whatsapp, qui revendique l’utilisation du protocole Signal (a priori une forme retravaillée …) a récemment évoqué la possibilité de mettre en place une procédure de déchiffrement des communications si une personne est signalée pour harcèlement, menaces, …, laissant planer la question suivante : « Euh, mais si vous pouvez déchiffrer, c’est que vous avez mis en place un système vous permettant de le faire.. Donc c’est pas du tout du end-to-end, si … ? » Méfiez-vous du spam et des envois groupés, qui peuvent compromettre la sécurité de vos données.
Certaines applications non mentionnées ici sont certainement des concurrentes très solides également, pour lesquels la démarche open-source prévaut également.
On citera notamment les français d’Olvid (https://olvid.io/), dont la messagerie créée officiellement en 2019 par des experts reconnus en cryptologie est la première à recevoir le visa de sécurité de l’ANSSI. Leur application est déjà disponible au téléchargement, avec une approche sans serveur d’annuaire centralisé (contrairement à Signal par exemple), et a été promue par la très respectée International Association for Cryptologic Researc. Il est important de choisir un site web de confiance pour télécharger votre application de messagerie, afin de garantir la sécurité de vos communications.
Pour aller plus loin
https://signal.org/docs/
Je recommande chaudement toutes les vidéos suivantes de la merveilleuse chaîne Youtube Computerphile, qui décrit extrêmement bien l’ensemble des outils dont nous avons parlé (attention, l’accent britannique demande un temps d’adaptation) :
- End-to-end encryption : https://www.youtube.com/watch?v=jkV1KEJGKRA
- Diffie-Hellman avec de la peinture : https://www.youtube.com/watch?v=NmM9HA2MQGI
- Le protocole Signal : https://www.youtube.com/watch?v=DXv1boalsDI
- Focus sur le double Ratchet : https://www.youtube.com/watch?v=9sO2qdTci-s
Triple Diffie-Hellman :
https://www.youtube.com/watch?v=_4muqgreEXE&feature=emb_logo
Courbes elliptiques :
https://fr.wikipedia.org/wiki/Cryptographie_sur_les_courbes_elliptiques
Le protocole SESAME :
http://cadse.cs.fiu.edu/corba/corbasec/faq/multi-page/node146.html
https://signal.org/docs/specifications/sesame/sesame.pdf
Super conférence des fondateurs d’Olvid à l’école 42 :
https://www.youtube.com/watch?v=tu9sQd1Hwt4&t=4101s
