OMEMO

OMEMO (pour « OMEMO Multi-End Message and Object Encryption ») est l'extension XMPP qui permet le chiffrement de bout en bout des informations (messages, fichiers, etc) sur XMPP. Il utilise pour cela l'algorythme dit « Double Cliquet » (« Double Ratchet » en anglais).

C'est donc surtout une manière de chiffrer les communications sur XMPP. Mais comme toujours avec le chiffrement, c'est complexe et quand on ne le comprend pas ça peut mener à des soucis. C'est pourquoi je fais cette page : permettre au plus grand nombre de comprendre OMEMO afin de bien l'utiliser, bien diagnostiquer les problèmes et bien les résoudre.

On va donc dans l'ordre essayer de :

• Comprendre le fonctionnement théorique de OMEMO
• Voir son fonctionnement dans les clients XMPP les plus courants
• Répondre aux questions et soucis les plus fréquents

Cette partie est la plus technique mais elle est nécessaire. Je vous assure que comprendre le fonctionnement de OMEMO va vous permettre de beaucoup mieux diagnostiquer les soucis et les résoudre. Je tente dans cette partie d'éviter au maximum de parler de mathématiques (aussi car ce n'est pas mon fort) et d'être clair sur ce que j'explique. Le but n'est pas de faire de vous des génies d'OMEMO mais plutôt d'en avoir une bonne compréhension globale.

OMEMO est en réalité un protocole qui mélange (comme souvent de nos jours) 2 types de chiffrements : symétrique et asymétrique.

Pour simplifier, on va dire que le chiffrement symétrique c'est un chiffrement dit « du secret partagé » : c'est typiquement le principe, dans les films, du mot de passe (qui change tous les jours) que le héros donne au garde derrière la porte quand celui-ci ouvre la petite fenêtre dessus. Vous et le garde avez le même mot de passe en commun, ce qui vous prouve qu'à la base vous êtes tous les deux en contact avec la personne de confiance qui a créé le mot de passe du jour.

Et on va dire que le chiffrement asymétrique c'est un chiffrement dit « des cadenas et de la clé » : Il faut imaginer que vous vouliez transmettre des messages secrets à une amie mais sans jamais vous rencontrer physiquement, donc dans cette situation impossible de s'échanger un mot de passe. À la place, votre amie va laisser dans un endroit connu plein de cadenas (tous les mêmes avec la même serrure) déverrouillés, dont seule elle a la clé. Il vous suffit donc, pour lui envoyer un message privé, de mettre votre message dans une boite que vous fermez avec l'un de ses cadenas et de lui envoyer. Comme seule elle en a la clé, seule elle pourra ouvrir la boîte. Et si vous faites pareil avec vos propres cadenas déverrouillés dont seul vous avez la clé, vous pouvez tous les deux vous échanger des messages privés sans jamais vous être rencontrés physiquement. Dans cet exemple on dit que les cadenas déverrouillés sont les clés publiques et les clés pour ouvrir vos propres cadenas sont les clés privées. Il ne faut jamais donner sa clé privée à personne, sinon elle n'est plus… privée.

Ainsi avec OMEMO chacun de vos appareils possède sa propre clé asymétrique : ce sont souvent les seules clés que vous voyez dans vos clients XMPP, celles dont vous devez vérifier l'empreinte avec vos correspondant·es. Comme ce sont ces clés que vous vérifiez avec vos interlocuteurs, on va les nommer « Clés d'identité », car ce sont ces clés qui permettent de prouver que c'est bien avec vous qu'on communique. Comme vu au-dessus, une clé asymétrique est composé d'une clé publique et d'une clé privée : ici la partie clé publique est publiée sur votre serveur XMPP (dans ce que l'on nomme un nœud PEP sur XMPP) et la partie clé privée reste bien au chaud sur votre appareil.

Mais en réalité, quand on communique avec une autre personne sur XMPP avec OMEMO, il y a encore une autre paire de clés asymétrique qui est créé régulièrement : c'est la « Clé de session » (nommé aussi « pre-key »). Dont la clé publique est partagé avec le client de votre interlocuteur et la clé privée reste comme toujours au chaud sur votre appareil. Pourquoi avoir encore des clés asymétriques ici vous vous demandez ? Et bien ça permet que si jamais une de nos clés de sessions est volée/cassée, il sera impossible pour le voleur de déchiffrer de futurs échanges, car cette clé de session change régulièrement.

Puis, grâce à cette clé de session (qui change régulièrement), on crée une première clé symétrique pour chiffrer un message, et on dérive de cette clé de message la seconde clé pour le seconde message et ainsi de suite. On nomme ces clés « Clés de message ». Ainsi chacun de nos messages est chiffré avec une clé symétrique unique. Si la clé d'un des messages est volée/cassée, alors le voleur ne peut pas lire les messages précédents, mais il peut éventuellement lire les messages suivants jusqu'au changement de la clé de session qui avait permis de créer la première clé de message de notre chaîne.

Au final on a donc nos 3 types de clés :

• Clés d'identités : Une seule par appareil, leur partie publique est stocké publiquement sur notre serveur XMPP. Elles servent à prouver notre identité et à échanger les clés de sessions.
• Clés de sessions : Générées régulièrement, pour permettre la confidentialité persistante, elle permet d'en dériver les clés de messages.
• Clés de messages : unique pour chaque message.

Voici un exemple pour mieux comprendre tout ça.

Tom et Jerry on chacun un appareil avec un client XMPP dessus. Ils ont donc une clé d'identité chacun pour leur appareil, dont la partie clé publique est publié sur leur serveur XMPP respectif (dans un nœud PEP).

Tom et Jerry s'ajoutent mutuellement comme contacts sur XMPP :

• Le client XMPP sur l'appareil de Tom va aller demander au serveur XMPP de Jerry « C'est quoi la clé d'identité publique de l'appareil de Jerry ? »
  • Le serveur XMPP de Jerry va lui répondre « C'est la clé A »
• Idem, le client XMPP sur l'appareil de Jerry va aller demander au serveur XMPP de Tom « C'est quoi la clé d'identité publique de l'appareil de Tom ? »
  • Le serveur XMPP de Tom va lui répondre « C'est la clé B »
• Tom et Jerry vont alors vérifier les empreintes de leurs clés via un autre canal de confiance (en se rencontrant physiquement, etc)
  • Tom va dire à Jerry « Ma clé c'est bien A »
  • Jerry va dire à Tom « Ma clé c'est bien B »
• Tom va alors envoyer un premier message à Jerry
  • Immédiatement, leurs appareils vont “échanger” une première clé de session (à l'aide d'un algorythme Diffie-Hellman) qu'on va nommer S-1
    • À partir de cette clé de session S-1, Une clé de message est générée, qu'on va nommer M-1
• Le message de Tom est chiffré avec cette clé de message M-1 et envoyé à l'appareil de Jerry
• Puis Jerry envois aussi un message : son appareil refait alors un “échange” pour avoir une nouvelle clé de session avec l'appareil de Tom. Cette nouvelle clé de session S-2
  • À partir de cette clé de session S-2, Une clé de message est générée, qu'on va nommer M-2
• Le message de Jerry est chiffré avec cette clé de message M-2 et envoyé à l'appareil de Tom
• Jerry envois ensuite 2 autres messages, cette fois pas de nouvelle clé de session, la clé de message M-3 est dérivée de la clé de message M-2 et la clé M-4 est dérivée de M-3, etc

Voici deux vidéos que je recommande pour comprendre l'algorythme derrière OMEMO, elles sont en anglais mais des pistes audio en français sont disponibles :

• Double ratchet algorithm: The ping-pong game encrypting Signal and WhatsApp
• Double Ratchet Messaging Encryption - Computerphile