Broken-by-Design/posts/proto-msg-instant/index.md

689 lines
42 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
title: "Chiffrement de messagerie quasi instantanée : à quel protocole se vouer ?"
author: "Florian Maury"
date: "2017-03-01"
slug: "instant-msg"
tags:
- security
- messaging
- misc
- cryptography
---
Telegram, WhatsApp, Signal, OTR... et autant de protocoles de messagerie quasi
instantanée, de modèles de sécurité et de protocoles cryptographiques : lesquels
choisir ? Et si la solution idéale nétait pas dans la liste précédente ? Cet
article évoque les limites de plusieurs de ces solutions, et présente le cœur
cryptographique de Signal, WhatsApp et du protocole OMEMO. Il met finalement en
exergue, par une analyse comparative, certaines limites de Signal et des
qualités dOMEMO.
<!--more-->
Chiffrement des messages de bout en bout ou chiffrement du canal, qualité des
algorithmes cryptographiques et de lauthentification des pairs, confidentialité
persistante ({{< abbr PFS "Perfect Forward Secrecy" >}}) ou non, fiabilité de léquipement faisant tourner la solution, limitation de
lexposition des métadonnées, fuite du carnet dadresses, localisation des
serveurs, capacité à dénier lenvoi dun message : des critères rarement
considérés par les utilisateurs de messagerie. Leurs véritables critères de
sélection sont souvent la taille du réseau social joignable, la facilité
dutilisation, laccessibilité de la solution sur léquipement de lutilisateur
ou encore la liste des services annexes. Un constat compréhensible, puisque la
première liste est formée de critères abscons et rarement absolus, tandis que la
seconde liste affecte l'usage quotidien.
Certains utilisateurs restent néanmoins soucieux de leur vie privée ou sont
contraints par la nature de leurs activités en ligne à un niveau de sécurité
plus élevé. Ils disposent alors dune myriade doptions, dont Telegram,
WhatsApp, Signal, ou Apple iMessage. Ils peuvent aussi se tourner vers des
solutions de messagerie instantanées traditionnelles augmentées du protocole
<abbr title="Off-the-Record">OTR</abbr> [^OTR] ou encore des e-mails augmentés
grâce à OpenPGP [^OPGP].
Se pose alors la question de séparer le bon grain de livraie ; une tâche qui
est simplifiée par la forte concentration des applications autour des protocoles
X3DH [^X3DH] et Double Ratchet [^DR]. Ces deux protocoles, spécifiés récemment
dans le domaine public par les auteurs de Signal, sont employés par plusieurs
vendeurs, dont Signal et WhatsApp. En outre, la communauté de XMPP, un protocole
de messagerie quasi instantanée, a également choisi X3DH+Double Ratchet, afin de
remplacer leur usage dOpenPGP et OTR.
La combinaison X3DH+Double Ratchet nest cependant quune partie de la solution
pour sécuriser les communications. Plus spécifiquement, ces protocoles
permettent, respectivement, la négociation des clés et leur rafraîchissement.
Lutilisation de ces clés, afin de créer des sessions cryptographiques entre les
utilisateurs, est dévolue à dautres composants : le protocole Signal, dans le
cas de Signal et de WhatsApp, et le protocole OMEMO [^OMEM], dans le cas de
XMPP.
X3DH+Double Ratchet, OMEMO et Signal sont étudiés dans la suite de cet article.
Pour le lecteur intéressé, la sécurité de Telegram a fait lobjet de discussions
[^TELG1] et détudes [^TELG2] et luniversité de Johns Hopkins a étudié celle
dApple iMessage [^IMSG]. WeChat ou encore Slack sont hors sujet, puisquils ne
proposent pas de chiffrement de bout en bout.
# 1. Les protocoles inadéquats pour la messagerie quasi instantanée
## 1.1. OpenPGP
OpenPGP est un format de stockage de messages et de clés cryptographiques,
spécifié dans sa version la plus récente en 2007 [^OPGP]. Il est notamment
employé pour sécuriser des messages électroniques. Ce format étant agnostique
vis-à-vis de la nature des messages, il convient pour des réseaux de messagerie
décentralisés ou lorsque le destinataire est hors-ligne (protocole non
interactif). Il permet également dassurer de la protection de bout en bout,
puisque ce sont les messages qui sont chiffrés et non le canal de transport de
ces derniers.
En outre, il est possible dutiliser OpenPGP pour envoyer des messages à un
groupe dutilisateurs. Pour ce faire, la clé de chiffrement du message est
chiffrée avec les clés publiques de chacun des destinataires. Les clés publiques
ainsi utilisées doivent être préalablement créées, et stockées dans des
certificats OpenPGP. Ces certificats permettent dassocier des identités —
éventuellement des pseudonymes — à ces clés publiques. Ces certificats sont
transmis ponctuellement aux autres utilisateurs grâce à des annuaires ou par une
remise en main propre.
OpenPGP présente cependant des limites, en regard de solutions alternatives
spécialisées pour le chiffrement de messagerie quasi instantanée. Ainsi, il
noffre pas, de manière inhérente, de confidentialité persistante du fait de la
transmission ponctuelle des certificats : le rafraîchissement des clés est du
ressort de lutilisateur. En outre, pour la protection en intégrité des
messages, lutilisateur na le choix quentre des solutions imparfaites. Lune
est sujette à des attaques par dégradation du niveau de sécurité (*downgrade
attack*) [^FORA] et lautre use de signatures cryptographiques non répudiables,
ce qui nest pas toujours souhaitable.
## 1.2. Off-the-Record
Le protocole *Off-the-Record* a été spécifié, pour la première fois, en 2004 ;
sa version la plus récente date de 2012. Ce mécanisme permet léchange de clés
et de messages sécurisés de bout en bout. Létablissement de la session protégée
est effectué entre deux parties de manière interactive. Autrement dit, il est
nécessaire que les participants soient en ligne simultanément pour
létablissement de cette session. Cette propriété exclut un usage asynchrone, et
restreint donc ce protocole à la messagerie instantanée. Une variante, appelée
mpOTR [^MPO], permet déchanger des messages au sein dun groupe dutilisateurs.
Avec OTR, les utilisateurs sont identifiés par des clés publiques à long terme.
Les clés à long terme servent à signer/authentifier des échanges de clés
Diffie-Hellman (DH) éphémères. Ces clés éphémères servent, à leur tour, à
générer les clés protégeant les messages. Il convient de noter que les
signatures émises par les clés à long terme affectent la vie privée ; elles
constituent, en effet, une preuve non répudiable quune conversation a eu lieu
entre deux parties, même si le contenu de la conversation reste inconnu dun
observateur.
Une fois la négociation de clés initiale accomplie, de nouvelles biclés DH sont
introduites à chaque nouveau message. Cela permet ainsi de rafraîchir les
secrets et dapporter la confidentialité persistante. En effet, la compromission
dune clé privée DH naffecte la confidentialité que dun unique message ; de
même, la compromission de la clé à long terme naffecte que les futurs messages.
Le protocole *Off-the-Record* présente également une propriété de sécurité qui
serait favorable à la vie privée. Ainsi, *Off-the-Record* permettrait à un
expéditeur de dénier le contenu dun message, tout en garantissant au
destinataire la légitimité et lintégrité du message reçu. Pour ce faire, les
clés utilisées pour calculer des motifs dintégrité de messages sont divulguées
en clair après réception et vérification de ces messages. Conjuguée à un mode de
chiffrement malléable et à un clair connu, cette méthode peut permettre à un
observateur de forger un message chiffré et intègre arbitraire. Cet observateur
serait cependant incapable de prouver à un tiers lauthenticité dun message
quil détient. Lefficacité de ce mécanisme fait néanmoins débat parmi les
experts, car il na jamais été éprouvé dans le cadre dun procès, afin de
décrédibiliser une conversation enregistrée et utilisée comme preuve
incriminante.
Malgré ses nombreux avantages, le protocole *Off-the-Record*, tel que spécifié
dans sa version la plus récente (3.4), souffre dun problème dobsolescence
cryptographique. En effet, labsence dun mécanisme de négociation des
algorithmes fait d*Off-the-Record* un musée des algorithmes cryptographiques
des années 2000. Sont notamment employés lalgorithme de signature DSA, des
empreintes cryptographiques avec SHA-1, ou encore des échanges DH sur corps
entiers de 1536 bits avec un groupe fixé par la spécification. Lusage de cette
cryptographie datée est contraire aux bonnes pratiques actuellement reconnues.
# 2. X3DH+Double Ratchet
Les protocoles X3DH et Double Ratchet ont été inventés par Trevor Perrin et
Moxie Marlinspike. En 2013, il sagissait, en fait, dun seul et même protocole
connu sous le nom dAxolotl. Ce nest quen 2016 quAxolotl fut divisé et que
ses parties furent renommées afin de mettre fin à des confusions fréquentes
entre Axolotl et le protocole Signal. Il faut dire que le protocole Signal, qui
fait usage dune variante dAxolotl, na, à ce jour, jamais été spécifié ou
documenté et que la frontière entre les deux protocoles était donc pour le moins
floue. Les spécifications complètes de X3DH et Double Ratchet ont finalement été
publiées en novembre 2016. Cette publication a également permis de mettre fin à
de récurrentes menaces judiciaires que les auteurs de Signal ont pu proférer
contre des vendeurs prétendant implémenter le protocole Signal, alors quils
utilisaient réellement Double Ratchet [^Lega].
X3DH est responsable de la négociation de clés cryptographiques. Celle-ci prend
place lors dune phase initiale. Les clés évoluent ensuite par dérivations,
selon le protocole Double Ratchet. Ce dernier rafraîchit les clés à laide de
cryptographie symétrique, ainsi que par lapport régulier de nouveaux éléments
secrets asymétriques.
Pour effectuer ces opérations sur les clés, les deux protocoles emploient de la
cryptographie moderne : XEdDSA, une extension à EdDSA, sur les courbes
elliptiques curve25519 ou curve448 [^XDSA], SHA2 et HKDF [^HKDF].
## 2.1. X3DH
Chaque utilisateur du protocole X3DH doit générer et publier un ensemble de
biclés cryptographiques. Ces clés doivent être compatibles avec les fonctions
X25519 ou X448 de XEdDSA.
La première biclé est appelée clé à long terme. Elle sert dans le cadre
déchanges DH, mais elle est également employée pour signer dautres biclés,
appelées clés à moyen terme. Des biclés à usage supposément unique sont
également générées en grande quantité ; Signal et Conversations en génèrent
ainsi une centaine. Générer autant de clés à usage unique permet quun grand
nombre de sessions puissent être établies avec la confidentialité persistante
dès le premier message, et ce alors que le destinataire nest pas en ligne.
La génération de ces trois types de biclés (à long et moyen termes et à usage
unique) doit être répétée pour chacun des périphériques avec lesquels un
utilisateur est susceptible daccéder à ses messages. Lutilisateur disposant
dun PC, dune tablette et dun téléphone portable se retrouve ainsi rapidement
avec plusieurs centaines de biclés associées à son identifiant. Seule la clé à
long terme de chaque équipement nécessite cependant une vérification
dauthenticité par les autres utilisateurs.
Ces biclés sont utilisées afin détablir des sessions entre un expéditeur et
lensemble des périphériques des destinataires. Ces périphériques peuvent être
possédés par un même destinataire ou par plusieurs destinataires, dans le cadre
dune discussion de groupe. La liste des périphériques destinataires peut même
contenir les équipements de lexpéditeur, afin de permettre la synchronisation
des messages émis entre équipements.
Autant de sessions sont créées quil y a déquipements destinataires. Cette
étape na cependant besoin de se produire quune seule fois, lors de la première
conversation entre deux périphériques. Ces sessions ont, en effet, une durée de
vie illimitée.
Pour établir une session, la première étape consiste à récupérer les clés
publiques des périphériques destinataires. La manière dont elles sont publiées
et récupérées est laissée ici volontairement abstraite ; elle varie dune
implémentation à lautre, comme le détaillera la section 3 de cet article.
Une fois les clés publiques des destinataires en possession de lexpéditeur, ce
dernier effectue les mêmes étapes avec les clés de chaque périphérique pour
lequel une session doit être établie. La première étape consiste à générer une
nouvelle biclé DH éphémère. Trois à quatre échanges DH sont ensuite effectués,
entre les clés de léquipement expéditeur et celles de léquipement
destinataire. Lappariement des clés publiques DH est détaillé dans la figure 1.
![Illustration d'un échange de clé avec X3DH](./X3DH.jpg "Fig. 1 : Illustration des échanges de clés DH effectués dans le cadre de X3DH. Le trait en pointillé représente un échange optionnel, qui na lieu que si une clé à usage unique est disponible pour léquipement destinataire.")
La variabilité du nombre déchanges DH résulte de la capacité à récupérer une
des clés à usage unique pour léquipement destinataire. Certains dépôts de clés
tiennent, en effet, une comptabilité afin dassurer quune clé à usage unique
nest bien distribuée quune seule fois. Si toutes les clés ont été distribuées,
aucune nest fournie à lexpéditeur et seuls trois échanges DH sont opérés. Ceci
peut affecter la confidentialité persistante, car le destinataire ne fournit
alors que des clés qui sont partagées entre plusieurs sessions. Dans la section
2.2 traitant de Double Ratchet, il sera détaillé comment cette faiblesse est
cicatrisée dès la réception dun message de la part de léquipement
destinataire.
Lensemble des secrets résultant des échanges DH est ensuite concaténé et passé
à travers la fonction HKDF pour former une valeur secrète, appelée secret racine
de la session.
Cet échange de clés a la particularité de négocier un secret tout en préservant
la capacité des deux parties de nier avoir tenu une conversation ensemble. Cette
propriété est dérivée de lhypothèse de difficulté calculatoire de DH
(Computational DH Assumption). La signature XEdDSA des clés à moyen terme, qui
elle est non répudiable, ne prévient pas cette propriété puisquelle est
totalement décorrélée de léchange de clés et nintervient que pour « certifier
» la clé à moyen terme.
## 2.2. Double Ratchet
Double Ratchet repose sur deux mécanismes de rafraîchissement des clés. Ces deux
mécanismes confèrent son nom à cet algorithme, puisquils utilisent tous deux, à
linstar dune roue à rochet, des fonctions cryptographiques à sens unique pour
faire « évoluer » des secrets.
Le premier, représenté sur fond jaune dans la figure 2, utilise exclusivement la
cryptographie symétrique. Il permet de générer les clés secrètes protégeant les
messages. Avec ce mécanisme, chaque message bénéficie dune clé secrète à usage
unique. Cette clé de protection dun message est obtenue par dérivation dune
clé, tirée dun ensemble appelé chaîne de clés. Cette chaîne est formée par des
dérivations successives de secrets. Le secret initial de cette chaîne est le
secret racine actuel. La notion dactualité du secret racine provient du second
mécanisme de rafraîchissement des clés.
Ce second mécanisme, représenté sur fond vert dans la figure 2, utilise de la
cryptographie asymétrique. Il vise à faire évoluer la clé racine qui a été
négociée initialement, par exemple avec X3DH. Avec ce mécanisme, une nouvelle
biclé DH est tirée aléatoirement chaque fois quun périphérique sapprête à
envoyer un message consécutif à la réception dun message par un autre
périphérique. La clé publique de cette nouvelle biclé DH est jointe à lensemble
des messages envoyés par ce périphérique jusquà la réception dun message de la
part dun autre périphérique. Cette gymnastique est représentée dans la figure
3.
La nouvelle clé DH fraîchement tirée est utilisée dans un échange DH en
conjonction avec les clés publiques les plus récentes reçues dans des messages
émis par les autres périphériques. Le résultat de cet échange est ensuite «
mélangé » avec le secret racine actuel à laide de la fonction HKDF. Le résultat
de cette opération devient le nouveau secret racine actuel.
![Illustration de lalgorithme Double Ratchet](./DR.jpg "Fig. 2 : Illustration de lalgorithme Double Ratchet. Les clés composant la chaîne de clés sont représentées dans des diamants. Les clés de messages sont représentées dans des ellipses. Les algorithmes sont dessinés dans des boîtes roses aux bords arrondis. Les composants sur fond vert représentent la roue à rochet asymétrique. Les composants sur fond jaune représentent la roue à rochet symétrique.")
![Illustration dun enchaînement de messages avec un protocole de messagerie employant Double Ratchet](./msgflow.jpg "Fig. 3 : Illustration dun enchaînement de messages avec un protocole de messagerie employant Double Ratchet. De nouvelles clés asymétriques sont générées juste avant lenvoi dun message faisant suite à une réponse. Cette clé asymétrique est répétée dans tous les messages suivants.")
Lutilisation de ces deux mécanismes de rafraîchissement de clés permet de
bénéficier de clés secrètes uniques pour chaque message envoyé, y compris
lorsquun des participants se lance dans un monologue de plusieurs messages. La
compromission dune clé symétrique ne mène alors quà la compromission dun seul
message. La réception dun message de la part de lautre participant permet
ensuite de rafraîchir le secret racine. Ceci permet ainsi de prévenir la
compromission de plus dun monologue en cas de compromission dune clé
asymétrique.
Outre ces propriétés, les protocoles de messageries sécurisées reposant sur
Double Ratchet peuvent également se montrer tolérants vis-à-vis de la perte de
messages ou de la livraison de messages dans le désordre. Il suffit à ces
applications de conserver les différentes chaînes de clés, et de « sauter » les
messages encore non reçus, en appliquant plusieurs fois de suite la fonction
HMAC-SHA256 avec la « constante 2 » de la figure 2. Il convient néanmoins de
noter que conserver ainsi les clés, au lieu de les supprimer dès que possible,
peut mettre en péril la confidentialité persistante, en cas de compromission
dun équipement.
## 2.3. Intégration de X3DH+Double Ratchet dans OMEMO
La première version dOMEMO a été spécifiée par Andreas Straub en 2015, avec
laide de Daniel Gultsch, développeur principal du client XMPP Conversations. En
décembre 2016, OMEMO a été officiellement acceptée comme extension expérimentale
du protocole XMPP (XEP-0384).
Avec XMPP, chaque utilisateur est identifié par un <abbr title="Jabber
ID">JID</abbr>. Il sagit dun identifiant qui ressemble fort à une adresse
e-mail, mais il est suivi dune barre oblique (*slash*) et du nom dun
équipement ou dun logiciel. `florian@im.x-cli.eu/phone` est, par exemple, le
JID de lauteur de cet article lorsquil est connecté avec son téléphone. À
linstar des adresses e-mail, la partie précédant larobase désigne un
utilisateur local, tandis que la partie suivant larobase et jusquà la barre
oblique désigne le serveur sur lequel est hébergé cet utilisateur. XMPP est donc
un système fédéré, où chaque utilisateur choisit son fournisseur de service.
Les messages à destination dun utilisateur, désigné par son bare JID (c.-à-d.
son JID sans le nom de léquipement), sont délivrés au dernier périphérique
actif de cet utilisateur. Ce fonctionnement peut être altéré grâce aux
extensions *Carbon Messages* (XEP-0280) et *Message Archive Management*
(XEP-0313) afin que tous les équipements dun utilisateur aient accès à tous les
messages reçus. En outre, si un utilisateur est hors-ligne, ses messages peuvent
être stockés sur le serveur responsable du compte de lutilisateur. Ces messages
lui seront alors délivrés lors de sa prochaine connexion. Par ailleurs, des
informations relatives à un utilisateur peuvent être stockées, en clair, sur le
serveur responsable de son compte, grâce à lextension XMPP XEP-0163, appelée
*Personal Eventing Protocol* (PEP). Ce mécanisme, lui-même extensible, permet
ainsi à un utilisateur connecté ou hors-ligne de mettre à la disposition
dautres utilisateurs diverses informations comme son avatar, son dernier
message de statut, ou encore sa « carte de visite ».
OMEMO utilise ces différentes extensions XMPP pour offrir une méthode de
chiffrement de bout en bout à lergonomie moderne. Chaque équipement, lorsquil
active OMEMO, génère sa clé à long terme, sa clé à moyen terme et dune
vingtaine à une centaine de clés à usage « unique ». Les jeux de clés de chaque
équipement sont stockés dans le profil PEP utilisateur. Lorsquun expéditeur
souhaite établir une nouvelle session, il récupère toutes les clés auprès du
serveur responsable du compte du destinataire. Ensuite, il effectue un échange
de clés en suivant le protocole X3DH. Par équipement avec lequel une session
doit être établie, il sélectionne aléatoirement une clé à « usage unique ».
Cette sélection aléatoire permet de saffranchir du risque quun serveur
malveillant dégrade la confidentialité persistante en diffusant sciemment une
clé à usage unique déjà employée par ailleurs. Le risque de dégradation de la
confidentialité persistante nest cependant pas totalement évité. Il est, en
effet, possible que plusieurs sessions soient établies pendant quun
périphérique est hors-ligne, et que la sélection aléatoire provoque une
collision. Plus un périphérique tarde à remplacer les clés utilisées, et plus le
risque de collision grandit. Cette collision a une portée limitée puisquelle
na un impact que sur tout ou partie du premier monologue dun utilisateur. Si
léquipement, dont lune des clés à usage unique a été réutilisée, se connecte
et détecte cette situation, il est alors en mesure de rétablir la
confidentialité persistante. Il lui suffit denvoyer un message « de service »
dont le seul objet est de rafraîchir le secret racine. Cette situation semble,
dans tous les cas, préférable à labsence totale du quatrième échange DH.
# 3. Des divergences entre Signal et le protocole OMEMO
Signal et le protocole OMEMO sont par certains aspects très similaires.
Certaines implémentations dOMEMO utilisent, en effet, la bibliothèque
cryptographique libsignal [^libS] dOpen Whisper Systems, la société éditrice de
Signal. Ses usages sont cependant cantonnés aux échanges de clés X3DH et à la
maintenance des secrets avec Double Ratchet. Les points de divergences entre
Signal et les implémentations dOMEMO se situent donc sur les points suivants :
les identifiants et larchitecture réseau, linfrastructure de gestions de clés,
lusage qui est fait de ces clés, lexistence de documentation de qualité et la
capacité à auditer le protocole.
## 3.1. Les identifiants et linfrastructure réseau
Alors qu'OMEMO utilise une infrastructure répartie, où chaque utilisateur
choisit son fournisseur de services, grâce au réseau fédéré XMPP, Signal préfère
une infrastructure centralisée. Les auteurs de Signal ont, en effet, exprimé une
opinion très négative sur les notions de fédération et dinteropérabilité, les
qualifiant de causes génératrices de lossification des protocoles [^NoFd]. Au
diable donc lInternet ouvert, le succès de HTTP ou encore celui des courriers
électroniques. Moxie Marlinspike a même demandé à des clones (fork) de Signal de
ne pas employer les serveurs opérés par Open Whisper Systems, quand bien même le
protocole employé était le même [^GTFO]. Signal est donc un système clos ; la
porte de la fédération a été fermée à clé, clé qui est maintenant au fond dun
lac.
Signal utilise les numéros de téléphone des utilisateurs comme identifiants.
Cette pratique a certainement pour origine lusage des SMS/MMS comme première
méthode de transport des messages de Signal. En 2015, les développeurs ont
cependant décidé arbitrairement darrêter de prendre en charge le transport par
SMS/MMS, et dutiliser, à la place, exclusivement les serveurs dOpen Whisper
Systems, situés aux États-Unis. Cette décision a fait réagir une fraction de la
communauté qui a créé un clone de lapplication, désormais appelé Silence
[^Slnc].
Le choix dOpen Whisper Systems darrêter la prise en charge des SMS/MMS na
cependant pas causé larrêt de lusage des numéros de téléphone comme
identifiants. Il en résulte un problème de vie privée, dû au fait que les
métadonnées relatives aux expéditeurs et destinataires ne sont pas chiffrées par
le protocole Signal. En effet, ces identifiants pourraient permettre aux
opérateurs dOpen Whisper Systems de tracer le graphe social des utilisateurs,
ou encore de les géolocaliser, grâce au réseau SS7 [^SS7].
Le choix des numéros de téléphone comme identifiant est également fortement
discutable depuis la publication de Signal Desktop. Ce logiciel permet aux
utilisateurs de converser depuis des PC avec les utilisateurs Signal ; il nest
cependant pas possible demployer ce logiciel sans sêtre enrôlé préalablement
sur téléphone portable !
Pour finir, cette centralisation du service présente également des risques
topologiques. En effet, la géolocalisation aux États-Unis de la société Open
Whisper Systems et de ses serveurs signifie quelle est soumise à larsenal
légal américain. Celui-ci a dailleurs déjà été mis en œuvre à lencontre de
Signal [^PAct]. En outre, la centralisation facilite la censure administrative
du service, comme cela sest déjà produit plusieurs fois au Brésil pour WhatsApp
[^Braz], et en Égypte pour Signal [^Egyp]. Une technique expérimentale [^DomF],
inspirée du module *meek* pour Tor et appelée *Domain Fronting*, a été déployée en
réponse à ce dernier blocage. Son déploiement hâtif laisse cependant en suspens
des questions de vie privée, de confidentialité et dintégrité, eu égard à
labsence de protection de bout en bout de certaines (méta-)données transitant
par Google AppEngine lors du *Domain Fronting*.
En comparaison, les JID de XMPP/OMEMO peuvent être des pseudonymes noffrant
aucune corrélation avec un utilisateur particulier. Les utilisateurs les plus
prudents peuvent même se connecter à XMPP au travers de Tor, ou utiliser des
hidden services XMPP sur Tor. En outre, les identifiants ne sont pas liés à un
type déquipements. Ils peuvent ainsi être utilisés sur PC ou téléphone
exclusivement ou sur un mélange des deux. Finalement, pour la géolocalisation
des serveurs, linfrastructure répartie de XMPP permet de jongler à volonté avec
la localisation administrative et juridique des serveurs.
## 3.2. Linfrastructure de gestion de clés
Les serveurs gérés par Open Whisper Systems sont responsables du stockage des
clés publiques de tous les utilisateurs, et de distribuer ces clés aux nouveaux
utilisateurs. Ainsi, lorsquun nouvel utilisateur installe Signal, le logiciel
prélève les numéros de téléphone de lintégralité du carnet dadresses de
lutilisateur, et les envoie aux serveurs de Signal, qui retournent en échange
les clés des utilisateurs connus [^Leak]. Les utilisateurs figurant dans le
carnet de contacts sont également notifiés quun de leurs contacts vient
dinstaller Signal.
En vue de protéger la vie privée des utilisateurs, les numéros de téléphone des
contacts sont hachés avec une fonction cryptographique et le résultat est
tronqué ; cette technique savère cependant insuffisante et une recherche
exhaustive permet de recouvrer ces numéros de téléphone.
Pour chaque utilisateur du carnet dadresses ayant Signal, les serveurs dOpen
Whisper Systems retournent donc une clé à long terme, une clé à moyen terme et
optionnellement une clé à usage unique. Cette méthode de distribution
centralisée des clés exige de faire confiance aux serveurs. Ces derniers
peuvent, en effet, dégrader sciemment la confidentialité persistante en ne
retournant pas de clé à usage unique. Ils peuvent, en outre, tout simplement
fournir de fausses clés, en vue deffectuer une interception de messages. Cette
éventualité peut être contrée si les utilisateurs effectuent une vérification
des clés retournées et les valident. Lusage des clés préalable à cette
vérification nest cependant pas empêché, et nombre dutilisateurs font donc
probablement une confiance aveugle aux serveurs de Signal.
Les utilisateurs méfiants qui voudraient effectuer cette vérification ne sont
malheureusement pas dotés doutils adaptés. Ainsi, sil était auparavant
possible de vérifier la clé du destinataire dun message, les développeurs de
Signal ont dégradé cette possibilité en novembre 2016. Au nom détudes sur
lexpérience utilisateur, ils ont ainsi remplacé la vérification dempreintes
cryptographiques des clés par la comparaison de « nombres de sûretés » (*safety
number*) [^Saft], supposément plus faciles à comparer. Cette opération a ainsi
réduit la sécurité de lempreinte de 256 bits à 100 bits. Plus incompréhensible
encore, lempreinte a également été réduite dans le QRCode utilisé pour la
comparaison des clés, alors quil ne peut y avoir dimpact sur lexpérience
utilisateur, que lon photographie un QRCode de 100 ou 256 bits de sécurité !
Pour finir, la vérification des empreintes est impossible lors dune
conversation de groupe [^NoSN].
Pour enfoncer le dernier clou, Signal envisage de réviser à la baisse son
mécanisme de sécurité concernant le signalement dun changement de clés dun
pair [^Saft]. Auparavant, lorsquun utilisateur changeait de clé à long terme
(une opération rarissime), une notification était affichée et une confirmation
manuelle était exigée. Avec la nouvelle option, dont il est envisagé qu'elle
soit activée par défaut, seule une petite ligne sera affichée au milieu de la
conversation.
En comparaison, les clés OMEMO sont récupérées auprès dun serveur au choix du
destinataire. Avec le logiciel Conversations, par défaut depuis la version 1.15
de novembre 2016, les clés peuvent être employées sans avoir été vérifiées ; un
indicateur visuel différencie cependant les échanges avec les clés vérifiées et
les échanges sans vérification [^Ctru]. De plus, dès quune première clé dun
utilisateur est vérifiée, seules ses clés vérifiées sont utilisables. Dans le
cas où plusieurs périphériques seraient destinataires, chaque clé doit être
individuellement validée au premier usage, à laide dune empreinte
cryptographique de 256 bits. Il existe un risque dutiliser plusieurs fois une
clé à usage unique, mais le protocole prévoit une contre-mesure pour raccourcir
la durée de lincident.
## 3.3. Usage des clés symétriques
Signal chiffre les messages à laide dAES256 en mode CBC et ses motifs
dintégrité sont calculés avec HMAC-SHA256 dont le résultat est tronqué à 64
bits.
Ces choix peuvent faire débat. Ainsi, bien que Signal use dune composition
chiffrement/intégrité satisfaisante (*Encrypt-then-Mac*), limplémentation
incorrecte du mode CBC sest révélée à lorigine de nombreuses vulnérabilités au
fil des années. Cela a été notamment le cas dans TLS. En conséquence,
lexistence de meilleures alternatives, tant en performances quen sécurité, a
valu à ce mode dêtre déconseillé par les auteurs du RFC de HTTP/2 [^H2]. La
prochaine version de TLS ne la prend même tout simplement pas en charge [^TL13].
En outre, si lalgorithme HMAC-SHA256 est, à ce jour, irréprochable, la
troncature du motif dintégrité à 64 bits affaiblit son efficacité de manière
significative. Ce choix tient peut-être sa justification dans lusage des SMS
comme méthode originelle de transport des messages. À lheure actuelle, tous les
messages de Signal sont notifiés à laide de Firebase Cloud Messaging
(anciennement Google Cloud Messaging), et transportés sur le canal de données
des téléphones portables. Les problèmes de bande passante utile ne peuvent donc
plus constituer une justification. En fait, la grande bande passante désormais
disponible joue même à lencontre de cette troncature, rendant plus facile le
bombardement de messages frauduleux jusquà réussir à forger un motif correct.
En comparaison, OMEMO emploie AES256 avec le mode de chiffrement authentifié
GCM, considéré à létat de lart.
## 3.4. Documentation et audits
Signal est une cible mouvante. Jusqualors dénué de documentation, par une
volonté affichée de ses développeurs, ce nest que sur la pression croissante de
la communauté que les algorithmes XEdDSA, X3DH et Double Ratchet ont été
finalement spécifiés et publiés dans le domaine public. Si des études formelles
vont désormais pouvoir être menées sur ces trois protocoles, effectuer ce même
type détudes sur le protocole Signal reste encore un défi. Quelques-uns sy
sont néanmoins essayés, documentant leurs découvertes du protocole par «
ingénierie inverse du code source », afin de dégager des propriétés de sécurité
[^Etu1] [^Etu2]. Aucune attaque réellement significative na été découverte, à
ce jour.
En comparaison, le protocole OMEMO est documenté et standardisé dans une
extension expérimentale du protocole XMPP. Il a récemment subi un audit, ayant
révélé divers points dattention [^Audi], qui ont été rapidement pris en compte
par le protocole et au moins certaines implémentations.
# 4. Conclusion
Cet article a détaillé les atouts et inconvénients de plusieurs protocoles
permettant la sécurisation de messageries quasi instantanées. La figure 4
reprend les observations de manière synthétique.
![Synthèse des points forts et faibles de plusieurs protocoles dans le cadre de la messagerie (quasi) instantanée.](./table.jpg "Fig. 4 : Synthèse des points forts et faibles de plusieurs protocoles dans le cadre de la messagerie (quasi) instantanée. Les justifications ou références ont été apportées dans larticle.")
Les utilisateurs souhaitant protéger leur messagerie quasi instantanée de bout
en bout disposent doptions valables, comme Signal, WhatsApp, ou encore OMEMO.
Ces outils ont en commun un cœur cryptographique formé des protocoles X3DH et
Double Ratchet, dont il ressort de plusieurs études indépendantes quils
seraient fiables.
Malgré cela, ces différentes solutions offrent un niveau de protection de la vie
privée et de la confidentialité des messages qui varie de manière significative.
Ainsi, cet article a rappelé, à linstar dune conférence lors de la conférence
33c3 [^CCC], que les numéros de téléphone sont à la fois des identifiants de
compte pratiques, puisque déjà enregistrés dans le téléphone, mais aussi une
donnée personnelle sensible. Outre leur usage éventuel pour géolocaliser des
utilisateurs, ils sont nécessairement transmis en clair, en tant que métadonnées
de tout message : une situation préoccupante lorsque les messages du réseau
doivent passer par une infrastructure centralisée. Cette dernière est, en effet,
en mesure dobserver le graphe social de ses utilisateurs et la fréquence de
leurs échanges, quand bien même leurs concepteurs sen défendent [^PAct]. Par
ailleurs, comme cet article la présenté, les serveurs de Signal et WhatsApp
sont en charge de la délivrance des clés publiques des contacts dun
utilisateur. Pour cela, un dérivé cryptographique des numéros de tous les
contacts dun utilisateur est envoyé aux serveurs, qui répondent avec des clés
publiques associées. Cette dérivation cryptographique est hélas aisément
réversible [^Leak], et il est possible de retrouver la liste des contacts dun
utilisateur de ces applications. En outre, il est à la charge des utilisateurs
de vérifier lauthenticité des clés remises par les serveurs, une étape
probablement rarement effectuée et dont les mécanismes de vérification ont été
récemment dégradés dans Signal, parfois de façon inexplicable [^Saft]. Pour
WhatsApp, ce mécanisme de distribution de clés a même été à lorigine dun
tumulte, en janvier 2017, lorsque le journal Guardian a rapporté quune
vulnérabilité publique depuis huit mois et non corrigée permet linterception de
messages en clair [^Guar].
Finalement, cet article a détaillé le protocole OMEMO, qui utilise le réseau
XMPP pour la distribution des clés et des messages. Le réseau XMPP utilise des
serveurs répartis et des identifiants indépendants de lidentité propre de
lutilisateur. Chaque utilisateur de XMPP est libre demployer le serveur de son
choix, dont la sécurité peut être catastrophique ou excellente. Une sécurité
serveur excellente nexempte cependant pas les utilisateurs de la nécessité de
vérifier les clés cryptographiques.
Heureusement, grâce à la publication récente dans le domaine public des
spécifications de X3DH et de Double Ratchet par les auteurs de Signal, de
nombreuses applications peuvent séquiper de ce cœur cryptographique robuste
tout en faisant des choix dinfrastructures plus respectueux de la vie privée
que ne le sont Signal ou WhatsApp.
Les arguments de léditeur de Signal concernant lagilité dun écosystème fermé,
soumis aux décisions unilatérales des développeurs, sont certainement fondés. À
linstar du régime politique démocratique, les réseaux fédérés, comme XMPP,
nécessitent des négociations, des ententes et des compromis. Le résultat peut
cependant, au long cours, se montrer supérieur à la somme des idées exprimées
par les différents intervenants de lécosystème.
Ainsi, grâce la stabilité de sa spécification, sa licence ouverte, ses
primitives cryptographiques à létat de lart et son architecture répartie,
OMEMO offre aux utilisateurs de XMPP une méthode de communication protégée de
bout en bout efficace, auditable, et potentiellement durable.
---
Pour le lecteur intéressé, lapplication libre Conversations implémente OMEMO et des extensions permettant léconomie de la batterie du périphérique le faisant tourner [^Conv]. Un compte est optionnellement fourni à tout utilisateur faisant lacquisition de lapplication au travers du Google Play Store. Les utilisateurs diOS peuvent utiliser ChatSecure [^ChSc]. Les utilisateurs PC peuvent, quant à eux, se tourner vers Gajim et son implémentation expérimentale dOMEMO. Pour les utilisateurs souhaitant effectuer un auto-hébergement de leur serveur XMPP, Prosody [^Pros] implémente la partie serveur des optimisations permettant des économies de batterie. Enfin, la Quadrature du Net fournit un service XMPP ouvert à tous [^LQDN].
---
# 5. Remerciements
Je tiens à remercier mes relecteurs : Piotr Chmielnicki, François Contat, Arnaud
Ebalard, Sarah De Haro, Olivier Levillain, Mickaël Salaün, et Guillaume Valadon.
Les idées exprimées dans cet article ne sauraient les engager.
# 6. Réferences
[^OTR]: https://otr.cypherpunks.ca/
[^MPO]: https://www.cypherpunks.ca/~iang/pubs/mpotr.pdf
[^OPGP]: https://www.rfc-editor.org/rfc/rfc4880.txt
[^FORA]: https://www.ssi.gouv.fr/uploads/2015/05/format-Oracles-on-OpenPGP.pdf
[^XDSA]: https://whispersystems.org/docs/specifications/xeddsa/
[^DR]: https://whispersystems.org/docs/specifications/doubleratchet/
[^X3DH]: https://whispersystems.org/docs/specifications/x3dh/
[^HKDF]: https://www.rfc-editor.org/rfc/rfc5869.txt
[^OMEM]: https://xmpp.org/extensions/xep-0384.html
[^libS]: https://github.com/WhisperSystems/libsignal-protocol-java
[^Slnc]: https://silence.im/
[^TELG1]: https://news.ycombinator.com/item?id=6913456
[^TELG2]: https://cs.au.dk/~jakjak/master-thesis.pdf
[^IMSG]: https://isi.jhu.edu/~mgreen/imessage.pdf
[^Lega]: https://moderncrypto.org/mail-archive/messaging/2016/002275.html
[^PAct]: https://whispersystems.org/bigbrother/eastern-virginia-grand-jury/
[^Braz]: https://techcrunch.com/2016/07/19/whatsapp-blocked-in-brazil-again/
[^Egyp]: https://whispersystems.org/blog/doodles-stickers-censorship/
[^DomF]: https://www.bamsoftware.com/papers/fronting/
[^SS7]: https://www.youtube.com/watch?v=lQ0I5tl0YLY
[^GTFO]: https://github.com/LibreSignal/LibreSignal/issues/37
[^NoFd]: https://whispersystems.org/blog/goodbye-encrypted-sms/
[^Leak]: https://whispersystems.org/blog/contact-discovery/
[^Saft]: https://whispersystems.org/blog/safety-number-updates/
[^NoSN]: https://support.whispersystems.org/hc/en-us/articles/213134107-How-do-I-verify-the-person-I-m-sending-messages-to-is-who-they-say-they-are-
[^Ctru]: https://gultsch.de/trust.html
[^Etu1]: https://eprint.iacr.org/2014/904.pdf
[^Etu2]: https://eprint.iacr.org/2016/1013.pdf
[^Audi]: https://conversations.im/omemo/audit.pdf
[^H2]: https://www.rfc-editor.org/rfc/rfc7540.txt
[^CCC]: https://media.ccc.de/v/33c3-8062-a_look_into_the_mobile_messaging_black_box
[^Guar]: https://www.theguardian.com/technology/2017/jan/13/whatsapp-backdoor-allows-snooping-on-encrypted-messages
[^TL13]: https://tools.ietf.org/html/draft-ietf-tls-tls13-18
[^Conv]: https://conversations.im
[^Pros]: https://prosody.im
[^LQDN]: https://jabber.lqdn.fr
[^ChSc]: https://chatsecure.org/blog/chatsecure-v4-released/
Publié par les [Editions Diamond](https://connect.ed-diamond.com/MISC/misc-090/chiffrement-de-messagerie-quasi-instantanee-a-quel-protocole-se-vouer) sous licence [CC-BY-NC-ND](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.fr).