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

3. Des divergences entre Signal et le protocole OMEMO

Signal et le protocole OMEMO sont par certains aspects très similaires. Certaines implémentations d’OMEMO utilisent, en effet, la bibliothèque cryptographique libsignal [libS] d’Open 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 d’OMEMO se situent donc sur les points suivants : les identifiants et l’architecture réseau, l’infrastructure de gestions de clés, l’usage qui est fait de ces clés, l’existence de documentation de qualité et la capacité à auditer le protocole.

3.1 Les identifiants et l’infrastructure 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 d’interopérabilité, les qualifiant de causes génératrices de l’ossification des protocoles [NoFd]. Au diable donc l’Internet 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 d’un lac.

Signal utilise les numéros de téléphone des utilisateurs comme identifiants. Cette pratique a certainement pour origine l’usage des SMS/MMS comme première méthode de transport des messages de Signal. En 2015, les développeurs ont cependant décidé arbitrairement d’arrêter de prendre en charge le transport par SMS/MMS, et d’utiliser, à la place, exclusivement les serveurs d’Open 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 l’application, désormais appelé Silence [Slnc].

Le choix d’Open Whisper Systems d’arrêter la prise en charge des SMS/MMS n’a cependant pas causé l’arrêt de l’usage 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 d’Open 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 n’est cependant pas possible d’employer 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 qu’elle est soumise à l’arsenal légal américain. Celui-ci a d’ailleurs déjà été mis en œuvre à l’encontre de Signal [PAct]. En outre, la centralisation facilite la censure administrative du service, comme cela s’est 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 d’intégrité, eu égard à l’absence 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 n’offrant 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, l’infrastructure répartie de XMPP permet de jongler à volonté avec la localisation administrative et juridique des serveurs.

3.2 L’infrastructure 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, lorsqu’un nouvel utilisateur installe Signal, le logiciel prélève les numéros de téléphone de l’intégralité du carnet d’adresses de l’utilisateur, 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 qu’un de leurs contacts vient d’installer 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 s’avère cependant insuffisante et une recherche exhaustive permet de recouvrer ces numéros de téléphone.

Pour chaque utilisateur du carnet d’adresses ayant Signal, les serveurs d’Open 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 d’effectuer 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. L’usage des clés préalable à cette vérification n’est cependant pas empêché, et nombre d’utilisateurs 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 d’outils adaptés. Ainsi, s’il était auparavant possible de vérifier la clé du destinataire d’un message, les développeurs de Signal ont dégradé cette possibilité en novembre 2016. Au nom d’études sur l’expérience utilisateur, ils ont ainsi remplacé la vérification d’empreintes 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 l’empreinte de 256 bits à 100 bits. Plus incompréhensible encore, l’empreinte a également été réduite dans le QRCode utilisé pour la comparaison des clés, alors qu’il ne peut y avoir d’impact sur l’expérience utilisateur, que l’on photographie un QRCode de 100 ou 256 bits de sécurité ! Pour finir, la vérification des empreintes est impossible lors d’une 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 d’un changement de clés d’un pair [Saft]. Auparavant, lorsqu’un 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 d’un 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 qu’une première clé d’un 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, à l’aide d’une empreinte cryptographique de 256 bits. Il existe un risque d’utiliser plusieurs fois une clé à usage unique, mais le protocole prévoit une contre-mesure pour raccourcir la durée de l’incident.

3.3 Usage des clés symétriques

Signal chiffre les messages à l’aide d’AES256 en mode CBC et ses motifs d’inté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 d’une composition chiffrement/intégrité satisfaisante (Encrypt-then-Mac), l’implémentation incorrecte du mode CBC s’est révélée à l’origine de nombreuses vulnérabilités au fil des années. Cela a été notamment le cas dans TLS. En conséquence, l’existence de meilleures alternatives, tant en performances qu’en 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 l’algorithme HMAC-SHA256 est, à ce jour, irréprochable, la troncature du motif d’intégrité à 64 bits affaiblit son efficacité de manière significative. Ce choix tient peut-être sa justification dans l’usage des SMS comme méthode originelle de transport des messages. À l’heure actuelle, tous les messages de Signal sont notifiés à l’aide 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 à l’encontre 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 l’art.

3.4 Documentation et audits

Signal est une cible mouvante. Jusqu’alors dénué de documentation, par une volonté affichée de ses développeurs, ce n’est 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 s’y 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 n’a é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 d’attention [Audi], qui ont été rapidement pris en compte par le protocole et au moins certaines implémentations.

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.

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 l’article.

 

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

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.

Références

[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/

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

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