Chiffrement de messagerie quasi instantanée : à quel protocole se vouer ? – Partie 1/2

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 d’OMEMO.

Chiffrement des messages de bout en bout ou chiffrement du canal, qualité des algorithmes cryptographiques et de l’authentification des pairs, confidentialité persistante (Perfect Forward Secrecy ou PFS) ou non, fiabilité de l’équipement faisant tourner la solution, limitation de l’exposition des métadonnées, fuite du carnet d’adresses, localisation des serveurs, capacité à dénier l’envoi d’un 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é d’utilisation, l’accessibilité de la solution sur l’équipement de l’utilisateur 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 d’une myriade d’options, dont Telegram, WhatsApp, Signal, ou Apple iMessage. Ils peuvent aussi se tourner vers des solutions de messagerie instantanées traditionnelles augmentées du protocole Off-the-Record (OTR) [OTR] ou encore des e-mails augmentés grâce à OpenPGP [OPGP].

Se pose alors la question de séparer le bon grain de l’ivraie ; 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 d’OpenPGP et OTR.

La combinaison X3DH+Double Ratchet n’est cependant qu’une 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. L’utilisation de ces clés, afin de créer des sessions cryptographiques entre les utilisateurs, est dévolue à d’autres 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 l’objet de discussions [TELG1] et d’études [TELG2] et l’université de Johns Hopkins a étudié celle d’Apple iMessage [IMSG]. WeChat ou encore Slack sont hors sujet, puisqu’ils 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 d’assurer 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 d’utiliser OpenPGP pour envoyer des messages à un groupe d’utilisateurs. 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 d’associer 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 n’offre 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 l’utilisateur. En outre, pour la protection en intégrité des messages, l’utilisateur n’a le choix qu’entre des solutions imparfaites. L’une est sujette à des attaques par dégradation du niveau de sécurité (downgrade attack) [FORA] et l’autre use de signatures cryptographiques non répudiables, ce qui n’est 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 d’un groupe d’utilisateurs.

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 qu’une conversation a eu lieu entre deux parties, même si le contenu de la conversation reste inconnu d’un 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 d’apporter la confidentialité persistante. En effet, la compromission d’une clé privée DH n’affecte la confidentialité que d’un unique message ; de même, la compromission de la clé à long terme n’affecte 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 d’un message, tout en garantissant au destinataire la légitimité et l’intégrité du message reçu. Pour ce faire, les clés utilisées pour calculer des motifs d’inté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 l’authenticité d’un message qu’il détient. L’efficacité de ce mécanisme fait néanmoins débat parmi les experts, car il n’a jamais été éprouvé dans le cadre d’un 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 d’un problème d’obsolescence cryptographique. En effet, l’absence d’un 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 l’algorithme 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. L’usage 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 s’agissait, en fait, d’un seul et même protocole connu sous le nom d’Axolotl. Ce n’est qu’en 2016 qu’Axolotl 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 d’une variante d’Axolotl, n’a, à 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 qu’ils utilisaient réellement Double Ratchet [Lega].

X3DH est responsable de la négociation de clés cryptographiques. Celle-ci prend place lors d’une phase initiale. Les clés évoluent ensuite par dérivations, selon le protocole Double Ratchet. Ce dernier rafraîchit les clés à l’aide de cryptographie symétrique, ainsi que par l’apport 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 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.

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 n’a 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 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 » 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, 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.

Fig. 2 : Illustration de l’algorithme 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.

 

Fig. 3 : Illustration d’un 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 l’envoi d’un message faisant suite à une réponse. Cette clé asymétrique est répétée dans tous les messages suivants.

 

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 d’un équipement.

Florian MAURY
Spécialiste en sécurité des réseaux et des protocoles

La seconde partie de cet article sera publiée prochainement sur le blog, restez connectés 😉

Retrouvez cet article (et bien d’autres) dans MISC n°90, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !

Laisser un commentaire