Signal, le service de messagerie chiffrée.

logo signal

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.

Photo de Bruce Schneier
Figure 1 : Le cryptologue renommé Bruce Schneier déclare « Signal, c’est chouette »

Open-source et gratuit, il 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. Le code des logiciels clients et serveurs étant accessible par tous (https://github.com/signalapp/), il est régulièrement audité et de nombreux autres services de messagerie (opensource ou propriétaire) affirment se reposer intégralement ou partiellement sur ce protocole : Whatsapp et Messenger dans leur accédant à la « conversation secrète », ou encore Skype.

Considéré comme le protocole le plus sûr à l’heure actuelle, il est notamment plébiscité par Edward Snowden, le PDG de Twitter Jack Dorsey ou le cryptologue renommé Bruce Schneier.

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.

comparatif types de chiffrement
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).

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 !).

schema-man-in-the-middle
Figure 3 : Attention Bob, un man in the middle !

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.

Asynchronisme
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 !

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. A force de temps et de ressources en calcul, il a finalement réussi au bout de 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.

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).

Pour résoudre le deuxième problème, celui de l’asynchronisme, les clés du X3DH, servant à la 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 (« Eh il y a un message pour moi ? »), évitant ainsi qu’un imposteur ne puisse entamer la conversation à la place de votre interlocuteur légitime.

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ée 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.

schéma double ratchet
Figure 4 : Le Double Ratchet dans les grandes lignes

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 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. 

écran de confirmation
Figure 6 : Me voilà rassuré

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, 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 la pléthore d’autres 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é cassé 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 … ? »

Certaines applications non mentionnées ici sont certainement des concurrentes très solides également, pour lesquels la démarche open-source prévaut également.

Logo Olvid
Figure 7 : Logo de la prometteuse start-up française

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 Research… A suivre donc !

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) :

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 

  • Post published:2 décembre 2020
  • Post author:

Arnaud B

Security Consultant