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 d’autres 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 qu’un grand
nombre de sessions puissent être établies avec la confidentialité persistante
dès le premier message, et ce alors que le destinataire n’est 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 d’accéder à ses messages. L’utilisateur disposant
d’un PC, d’une tablette et d’un 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
d’authenticité par les autres utilisateurs.
Ces biclés sont utilisées afin d’établir des sessions entre un expéditeur et
l’ensemble 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
d’une discussion de groupe. La liste des périphériques destinataires peut même
contenir les équipements de l’expéditeur, afin de permettre la synchronisation
des messages émis entre équipements.
Autant de sessions sont créées qu’il y a d’équipements destinataires. Cette
étape n’a cependant besoin de se produire qu’une 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 d’une
implémentation à l’autre, comme le détaillera la section 3 de cet article.
Une fois les clés publiques des destinataires en possession de l’expé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. L’appariement des clés publiques DH est détaillé dans la figure 1.
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 d’assurer qu’une clé à usage unique
n’est bien distribuée qu’une seule fois. Si toutes les clés ont été distribuées,
aucune n’est fournie à l’expé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 d’un message de la part de l’équipement
destinataire.
L’ensemble 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 l’hypothè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é puisqu’elle est
totalement décorrélée de l’échange de clés et n’intervient que pour « certifier
Double Ratchet repose sur deux mécanismes de rafraîchissement des clés. Ces deux
mécanismes confèrent son nom à cet algorithme, puisqu’ils utilisent tous deux, à
l’instar d’une 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 d’une clé secrète à usage
unique. Cette clé de protection d’un message est obtenue par dérivation d’une
clé, tirée d’un 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 d’actualité 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 qu’un périphérique s’apprête à
envoyer un message consécutif à la réception d’un message par un autre
périphérique. La clé publique de cette nouvelle biclé DH est jointe à l’ensemble
des messages envoyés par ce périphérique jusqu’à la réception d’un message de la
part d’un 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 à l’aide de la fonction HKDF. Le résultat
de cette opération devient le nouveau secret racine actuel.
L’utilisation 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
lorsqu’un des participants se lance dans un monologue de plusieurs messages. La
compromission d’une clé symétrique ne mène alors qu’à la compromission d’un seul
message. La réception d’un message de la part de l’autre participant permet
ensuite de rafraîchir le secret racine. Ceci permet ainsi de prévenir la
compromission de plus d’un monologue en cas de compromission d’une 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
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.
Les utilisateurs souhaitant protéger leur messagerie quasi instantanée de bout
en bout disposent d’options 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 qu’ils
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é, à l’instar d’une 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 d’observer le graphe social de ses utilisateurs et la fréquence de
leurs échanges, quand bien même leurs concepteurs s’en défendent [^PAct]. Par
ailleurs, comme cet article l’a présenté, les serveurs de Signal et WhatsApp
sont en charge de la délivrance des clés publiques des contacts d’un
utilisateur. Pour cela, un dérivé cryptographique des numéros de tous les
contacts d’un 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 d’un
utilisateur de ces applications. En outre, il est à la charge des utilisateurs
de vérifier l’authenticité 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é à l’origine d’un
tumulte, en janvier 2017, lorsque le journal Guardian a rapporté qu’une
vulnérabilité publique depuis huit mois et non corrigée permet l’interception 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 l’identité propre de
l’utilisateur. Chaque utilisateur de XMPP est libre d’employer le serveur de son
choix, dont la sécurité peut être catastrophique ou excellente. Une sécurité
serveur excellente n’exempte 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 d’infrastructures plus respectueux de la vie privée
que ne le sont Signal ou WhatsApp.
Les arguments de l’éditeur de Signal concernant l’agilité d’un écosystème fermé,
soumis aux décisions unilatérales des développeurs, sont certainement fondés. À
l’instar 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 l’art 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é, l’application 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 l’acquisition de l’application au travers du Google Play Store. Les utilisateurs d’iOS peuvent utiliser ChatSecure [^ChSc]. Les utilisateurs PC peuvent, quant à eux, se tourner vers Gajim et son implémentation expérimentale d’OMEMO. 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].
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).
