Chiffrement de bout en bout : comment fonctionne MLS (RFC 9420)

« Chiffré de bout en bout » est devenu un argument commercial courant. Derrière la formule, il y a des protocoles précis, et tous ne se valent pas, surtout pour les groupes. MLS, pour Messaging Layer Security, est le standard publié par l'IETF en juillet 2023 sous le numéro RFC 9420. Voici ce qu'il fait, simplement.

Le principe du bout en bout

Dans une messagerie classique, votre message est chiffré pendant le trajet vers le serveur, puis lisible par le serveur, qui le rechiffre vers le destinataire. Avec le chiffrement de bout en bout, le message est chiffré sur votre appareil avec des clés que seuls les appareils des participants possèdent. Le serveur ne fait que relayer des données qu'il ne peut pas lire.

La difficulté n'est pas de chiffrer un message, mais de gérer les clés : qui les possède, comment elles sont partagées, ce qui se passe quand quelqu'un rejoint ou quitte une conversation, ou quand un appareil est compromis.

Le problème des groupes

Les premiers protocoles de bout en bout ont été conçus pour des conversations à deux. Pour un groupe, beaucoup d'implémentations chiffrent en réalité le message séparément pour chaque appareil, ou partagent une clé de groupe renouvelée de façon coûteuse. Plus le groupe grandit, plus cela devient lourd, et plus il est tentant de renouveler rarement les clés.

Ce qu'apporte MLS

MLS organise les membres d'un groupe dans un arbre de clés (un « ratchet tree »). Chaque membre connaît les clés de son propre chemin dans l'arbre. Quand la composition change ou qu'un membre renouvelle ses clés, seule une partie de l'arbre est mise à jour : le coût croît avec le logarithme de la taille du groupe, et non avec sa taille. Les changements sont regroupés dans des commits qui font passer tout le groupe à une nouvelle époque, avec de nouvelles clés.

Deux garanties essentielles

• La confidentialité persistante (forward secrecy) : les clés évoluent sans cesse et les anciennes sont effacées. Une clé dérobée aujourd'hui ne permet pas de lire les messages d'hier.
• La sécurité après compromission (post-compromise security) : un membre dont l'appareil a été compromis renouvelle ses clés ; après ce renouvellement, l'attaquant ne peut plus lire la suite.

Des membres authentifiés

Chaque membre est identifié par un certificat lié à ses clés. Les clients vérifient que chaque appareil du groupe correspond bien à un membre légitime : un serveur malveillant ne peut pas glisser discrètement un appareil supplémentaire sans que cela se voie.

Ce que MLS ne règle pas seul

Aucun protocole ne fait tout. Il reste à :

• vérifier les identités : comparer un numéro de sécurité ou un QR code avec son interlocuteur reste la meilleure protection contre une substitution de clés ;
• protéger les appareils : si le téléphone est déverrouillé entre de mauvaises mains, les messages déchiffrés sont lisibles ;
• limiter les métadonnées : le serveur doit savoir à qui livrer un message ; un bon service conserve le moins possible et le moins longtemps possible.

Et dans Discus ?

Discus utilise MLS (suite de chiffrement standard du RFC 9420) au moyen d'une implémentation libre existante, OpenMLS. Les clés sont générées et conservées sur les appareils, protégées par la passkey ; les appels audio et vidéo sont chiffrés avec des clés dérivées du groupe MLS et renouvelées à chaque changement d'époque. Pour aller plus loin : notre page sécurité, limites comprises.