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 :
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 :
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 :
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 :
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 :
Sur Gajim vous pouvez :
Sur Conversations vous pouvez :
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 :
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).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 travail 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.