TextSecure

Auteurs : Fanny RIBARD et Abdou ABDELMOUMNI

TextSecure est une application mobile open source de messagerie pour Android développée par Open Whisper Systems. TextSecure permet d'envoyer des messages chiffrés à d'autres utilisateurs de l'application. TextSecure est, en novembre 2014, un des deux seuls logiciels de messagerie instantanée avec Cryptocat. En mars 2015, Open Whisper Systems sort la version 2.0 de son application Signal pour iOS, qui permet désormais de communiquer de façon chiffrée avec TextSecure3.

Buts

L’objectif de TextSecure est d’offrir deux éléments importants : - Sécurité de bout en bout. - Confidentialité et secret futur. Dans la pratique, Textsecure construit un flux de message entre deux utilisateurs, qui conservera une confidentialité pendant une certaine durée. Ce flux permet une connexion sécurisée, ne pouvant être décrypté.

Terminologie

TextSecure a été renommé récemment Signal, mais le code de base et sa documentation conservent le nom TextSecure.

Cette application fait appel à plusieurs composants :
- Le serveur TextSecure est le serveur centralisé qui coordonne l’état du reste du système.
- Le Signal Protocol fait référence au protocole utilisé par les applications de messagerie comme Facebook Messenger ou Google Allo. Il implémente les différentes fonctionnalités décrites ci-dessous, mais il est libre de router ces messages et le suivi des métadonnées comme il le souhaite.
- L'application Signal est une application mobile qui implémente le protocole Signal en utilisant les politiques TextSecure Server décrites ci-dessous. Il s'agit de la mise en œuvre initiale du protocole.

Architecture

TextSecure est une modification du protocole de discussion Off-The-Record avec un accent sur la coordination asynchrone. Alors que OTR nécessite une poignée de main interactive, TextSecure considère la latence indéterminée inacceptable.

Au lieu de cela, des copies du rôle du serveur sont stockées dans la clé de négociation par un serveur centralisé pour que les clients potentiels puissent les récupérer et les utiliser. Ce serveur agit comme un canal qui ne fait pas confiance aux informations clés capables de décrypter des données. Tout le cryptage est un chiffrement de bout en bout.

Cryptographie

TextSecure utilise un petit ensemble de primitives cryptographiques. La cryptographie à clé publique est effectuée par courbe elliptique Diffie-Hellman en utilisant Curve25519. AES est utilisé pour le cryptage symétrique, le mode compteur sans remplissage et le mode de chaînage de blocs de chiffrement. HMAC-SHA256 est utilisé pour l'authentification des messages.

« Double Ratchet Algorithm » :

Le cœur du moteur de cryptage est l’algorithme « Axolotl double ratchet ».

Illustration pour comprendre le système de cliquet

Le ratchet, cliquet en francais, est un mécanisme qui maintient un système en l'état ou, plus généralement, l'empêche de revenir en arrière et le force à aller de l'avant.

Le mécanisme utilise deux cliquets :

- Le cliquet de réception
- Le cliquet d’émission

La structure permet que la première moitié de la clé de négociation soit sauvegardée et rejouée de façon asynchrone pour effectuer une poignée de main complète. Le cliquet de réception est utilisé lorsqu'un message est reçu, qui contiendra des informations permettant la prochaine négociation de clé. De nouvelles clés symétriques seront ensuite générées permettant le cryptage et l'authentification des message.

Le cliquet d’émission génère un nouvel ensemble de clés à l'aide du flux de clés généré à partir de l'ensemble précédent de données secrètes partagées. Le cliquet d’émission est réinitialisé quand le cliquet de réception est activé et que les données secrètes partagées ont été modifiées. Un des éléments importants du processus est que les expéditeurs n’ont jamais à attendre pour envoyer un message. Ils peuvent toujours l’envoyer, ce message sera reçu en un laps de temps limité. Ces messages seront tous cryptés avec différentes clés symétriques. Cela implique que les clés courantes des appareils des utilisateurs ne peuvent pas être utilisées pour décrypter un message envoyé dans le passé.

Protocole

Phase 1 : Inscription

L’inscription commence lorsque le client émet une demande au serveur, en indiquant sur quel numéro de téléphone il doit être contacté. Le client envoie un message d’authentification contenant les clés de cryptage symétrique (clé de signalement) et la clé public long terme. Une collection de clé prédéfinie sera aussi copiées par l’utilisateur quand il est receveur d’un message, ces clés seront utilisées pendant la première moitié de la négociation de clés. Ces clés stockées permettent à un expéditeur d'effectuer une négociation de clés sans exiger que le client soit en mesure de répondre, réduisant significativement le temps de réponse de l’application. Le client télécharge également une « clé de secours » qui est utilisée en dernier et est partagée entre toutes les sessions jusqu'à ce que le destinataire partage de nouvelles clés.

Le client s'inscrit ensuite auprès de Google Cloud Messaging pour obtenir un ID d'enregistrement qu’il partage à l’application TextSecure. Cet enregistrement indique si le client souhaite recevoir des SMS ou seulement des données.

Phase 2 : Comparaison de clés

Textsecure permet à deux clients voulant avoir une communication cryptée d’échanger l’empreinte de leur clé long terme respective afin de vérifier leurs identités.

Phase 3.1 : Envoi d'un message initial

L’utilisateur voulant émettre un message commence par demander une clé prédéfinie au receveur. Il reçoit en plus de cette clé prédéfinie, l’index de la clé envoyée, la clé publique long terme du receveur et son identifiant d’inscription. Ces informations seront utiles à la génération d’une clé secrète à partir de l’algorithme KDF (Key Derivation Algorithm), qu’on appellera la clé racine. Une paire de clé éphémère sera générée pour ce message. La clé racine est utilisée avec l’algorithme KDF pour obtenir une nouvelle clé racine et une clé chainée. Cette clé chainée est celle utilisée pour générer le chiffrement et les clés MAC.

Enfin, les compteurs AES sont initialisés. Il y a deux compteurs : « ctr » et « pctr ». Le compteur ctr est incrémenté à chaque message envoyé tandis que le compteur pctr contient l’index du dernier message lu.

Ceux-ci sont utilisés pour chiffrer le message pour le destinataire, qui est envoyé au serveur de l’application. Ce message contient les informations nécessaires pour que le destinataire effectue la négociation de clés.

Le serveur de l’application vérifiera que l'ID d'enregistrement Google Cloud Messenger est adapté au numéro de téléphone associé. Ensuite, il chiffrera le message avec les clés de signalement obtenues à l’inscription avant d'envoyer le message au cloud. Cette étape garantit que Google Cloud Messenger n’aura pas d’information sur l’émetteur du message.

Phase 3.2 : Réception d'un message

A la réception du message, le destinataire reçoit l'index de pré-clé et l'utilise pour trouver le préfixe utilisé par l'expéditeur. Il utilise ensuite les informations envoyées pour terminer la négociation de clés et pour trouver les mêmes clés racines que l'expéditeur. Ces clés générées permettent de déchiffrer le message envoyé.

Phase 4 : Envoi d'un message de suivi

Si l'expéditeur d'origine souhaite envoyer un deuxième message avant que le destinataire ne réponde, il génère une nouvelle clé chainée et l'utilise pour trouver de nouvelles clés d'authentification et de chiffrement.

Phase 5 : Envoi d'une réponse

Lorsque le destinataire souhaite répondre, il choisit d'abord une nouvelle paire de clés éphémère. En utilisant la clé publique éphémère de l'expéditeur, et leur clé privée éphémère, ils génèrent une nouvelle clé commune. Ceci est utilisé pour trouver une nouvelle clé chainée afin de trouver de nouvelles clés de chiffrement. Ceci permet de chiffrer le message, qui est envoyé avec la nouvelle clé publique éphémère.

TextSecure aujourd’hui

Les développeurs annoncent qu'ils arrêtent le support de la partie SMS/MMS chiffrés à partir de la version 2.7.

Pourquoi ?

Les raisons évoquées sont les suivantes :

- L'envoi des SMS/MMS chiffrés ne peut se faire de façon transparente : les utilisateurs doivent manuellement créer un premier échange de clés. Le problème est que les gens ne savent pas tous ce que représente réellement "une clé", ce qui rend moins efficace ce genre de solution.

- L'arrivée de la compatibilité iOS : avec Signal, iOS se voit disposer d'une solution compatible avec TextSecure. Cependant, iOS ne possède pas d'API qui permet à Signal d'envoyer/recevoir des SMS programmés rendant impossible la lecture des SMS chiffrés. Cela peut donc perturber les utilisateurs.

- SMS et MMS sont un désastre concernant la sécurité : aucune métadonnée ne peut passer autrement qu'en clair sur le réseau mobile. Ainsi, tous les réseaux télécoms sont capables d'intercepter les SMS et d'en examiner les métadonnées, révélant beaucoup trop d'informations même si le contenu est indéchiffrable. Les développeurs ne veulent pas avoir mauvaise conscience en sachant que des gouvernements peuvent oppresser des dissidents qui utilisent ce genre de solution.

- Paranoïa sécuritaire : en voulant se focaliser sur la sécurité des SMS et MMS, les développeurs n'ont plus de temps à accorder au développement de TextSecure afin de la rendre meilleure.