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'algorithme 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 algorithme 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'algorithme 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

Ici je vais parler un peu des client que je recommande et comment utiliser OMEMO avec. Mais avant tout regardons ensemble les bonnes pratiques à appliquer.

Voici quelques bonnes pratiques que vous devriez idéalement toujours appliquer sur XMPP avec vos correspondant·es, en discussion à 2 ou en groupe :

• Activer OMEMO par défaut : Tous les bons clients XMPP vous permettent d'activer/désactiver OMEMO globalement mais aussi par conversation. Vous devriez toujours l'activer par défaut.
• Vraiment vérifier les empreintes : Quand vous ajoutez un nouveau contact, vous devriez systèmatiquement vérifier mutuellement vos empreintes de clés OMEMO. Vous pouvez éventuellement publier vos empreintes si vous avez un site web (les miennes sont ici). Vérifiez ensemble vos empreintes via un canal de confiance (qui vous permet de prouver vos identités).
• Être vigilant·e si de nouvelles clés se présentent : Il arrivera qu'un de vos contact ai soudain une nouvelle clé OMEMO, la plupart du temps sans qu'il vous en ai averti avant. Cela devrait déclencher une petite alerte dans votre tête : demandez-lui immédiatement de vérifier cette nouvelle clé via son empreinte ! Soit en vous la confirmant via un autre appareil dont vous avez déjà vérifié la clé, soit via un autre canal de confiance si c'était son seul appareil. Évitez de discuter de quoi que ce soit d'autre tant que cette nouvelle clé n'est pas vérifiée, sauf preuve du contraire une nouvelle clé non-vérifiée doit être considéré comme celle d'un attaquant.
• Ne pas faire vos tests de clients avec votre compte principal : Il arrive que des personnes test plein de clients XMPP, ce qui génére donc sur leur compte plein de clés OMEMO qu'ils ne vont pas utiliser ensuite. Cela confuse énormément leurs correspondant·es qui vont alors arrêter de faire confiance à ces personnes et croire aveuglément toute nouvelle clé qui apparait. C'est le meilleur moyen pour détruire tout le principe de confiance des clés OMEMO. Si vous voulez tester plein de clients, faites un compte de test pour ne pas embêter les personnes qui discutent avec vous.

Sur Gajim vous pouvez :

• Activer OMEMO par défaut : Via les Préférences (l'icône d'engrenage en bas à gauche), sélectionnez votre compte, puis dans l'onglet Confidentialité règlez la Méthode de chiffrement par défaut sur OMEMO.
• Activer OMEMO par conversation : Via Choisir un chiffrement (l'icône de cadena en bas à droite d'une conversation) et en sélectionnant OMEMO.
• Voir vos propres empreintes de clés d'identité : Via les Préférences (l'icône d'engrenage en bas à gauche), sélectionnez votre compte, puis dans l'onglet Chiffrement (OMEMO) vous pouvez voir l'Empreinte pour cet appareil ainsi que les Autres appareils connectés à votre compte.
• Activer/désactiver la confiance aveugle dans les clés d'identité : Via les Préférences (l'icône d'engrenage en bas à gauche), sélectionnez votre compte, puis dans l'onglet Chiffrement (OMEMO) vous pouvez activer ou non la Confiance aveugle.
• Vérifier les empreintes des personnes dans une conversation : En faisant un clic-droit sur l'avatar d'une personne, puis détails et en allant dans l'onglet Chiffrement (OMEMO).

Sur Conversations vous pouvez :

• Activer OMEMO par défault : Menu (les trois points en haut à droite), puis Paramètres, section Sécurité, dans Chiffrement OMEMO sélectionnez Activé par défaut ou Toujours.
• Activer OMEMO par conversation : Dans une conversation, sélectionnez la cadena en haut, puis OMEMO.
• Voir vos propres empreintes de clés d'identité : Menu (les trois points en haut à droite), puis Gérer les comptes, sélectionner votre compte, en bas vous pouvez voir l'empreinte de cet appareil sous Votre nom et plus bas les empreintes des Autres appareils.
• Activer/désactiver la confiance aveugle dans les clés d'identité : Menu (les trois points en haut à droite), puis Paramètres, section Sécurité, cochez ou non Faire aveuglément confiance avant vérification.
• Vérifier les empreintes des personnes dans une conversation : Dans une conversation, appuyez longtemps sur l'image d'une personne, puis Détails du contact, en bas vous pouvez voir les clés OMEMO et activer/désactiver la confiance.

Voici les questions qu'on voient souvent posés sur OMEMO mais aussi les problèmes les plus fréquents et comment les résoudre.

Oui, de manière générale si on a le choix entre chiffrer et ne pas chiffrer je considère qu'il vaut mieux chiffrer. Typiquement « est-ce que c'est utile de chiffrer ? » est une question que beaucoup de personnes se posent mais la question est dans le mauvais sens, il faut plutôt ce demander « Est-ce qu'il y a vraiment une bonne raison de ne pas chiffrer ? »

Tout dépend bien sur du modèle de menace qui s'applique à nous, nos interlocuteurs ou nos groupes, mais de manière générale et sans plus d'infos sur les modèles de menace je considère qu'il vaut mieux chiffrer par défaut.

La sécurité nécessite toujours des connaissances, des apprentissages et des compromis. Ces méthodes sont nécessaires pour bien vérifier avec qui on parle et que personne ne lis nos conversations privées.

Les personnes qui concoivent les protocoles et logiciels tentent régulièrement de faciliter l'usage du chiffrement, mais il faudra toujours apprendre à s'en servir correctement. Croyez-moi ça en vaut la peine.

La confiance aveugle avant vérification (nommé BTBV en anglais pour « Blind Trust Before Verification »), est une méthode popularisée par le client Conversations.

Le principe est simple : Permettre de faire fonctionner OMEMO sans valider les clés la première fois qu'on les vois pour faciliter l'accès au chiffrement. C'est censé être temporaire, le temps de valider la nouvelle clé. Hélas beaucoup de personnes ne font que de la confiance aveugle et ne valident jamais sérieusement les clés OMEMO.

Pensez toujours à valider les clés OMEMO que vous recevez rapidement et encouragez vos correspondant·es à faire de même.

En fait il existe actuellement 2 grandes versions d'OMEMO :

• OMEMO 0.3 (dit « OMEMO 1 ») : Version la plus implémentée. Le contenu des message est chiffré mais pas les metadonnées qui l'entoure (dans le XML).
• OMEMO 0.8+ (dit « OMEMO 2 ») : Version peu implémentée. Le contenu des messages et leurs metadonnées sont chiffrés.

OMEMO 2 est incompatible avec OMEMO 1, ce qui fait que n'importe quel client qui l'implémenterai ne pourrait plus communiquer avec les autres qui ne l'auraient pas encore fait (ou qui ne gérerait pas les 2 versions “à la fois”) : c'est d'ailleur déjà le cas de clients qui implémentent OMEMO 2 comme Kaidan.

En soit on serait ravis d'avoir enfin OMEMO 2 partout mais ça demande beaucoup de trvail de la part des développeur·euses et de test que très peu de gens font (la cryptographie c'est complexe), on a pas encore les outils logiciels pour faire ça dans tous les langages de programmation. Mais si des personnes veulent s'y attaquer ça serait super !

Concernant la sécurité : parler en absolu ne fonctionne pas (autant de la part des personnes qui disent que “c'est parfait” que de la part des personnes qui disent “c'est nul”). Il y a les mathématiques d'un côté avec les meilleures formules du monde qu'on puisse avoir et la réalité du monde véritable de l'autre : Il faut toujours concevoir ses mesures de sécurité en fonction de son modèle de menace, et un algorithme de sécurité qui n'est pas adapté pour quelqu'un peut l'être pour quelqu'un d'autre avec un autre modèle. Ce n'est pas “tout bien” ou “tout naze”, il y a des situations, des cas d'usages, des compromis, etc.