Google a annoncé son intention d’ajouter la prise en charge de Message Layer Security (MLS) à son service Messages pour Android et l’implémentation open source de la spécification.
« La plupart des plates-formes de messagerie grand public modernes (y compris Google Messages) prennent en charge le cryptage de bout en bout, mais les utilisateurs d’aujourd’hui sont limités à communiquer avec des contacts qui utilisent la même plate-forme », a déclaré Giles Hogben, directeur de l’ingénierie de la confidentialité chez Google. « C’est pourquoi Google soutient fortement les efforts réglementaires qui nécessitent l’interopérabilité des grandes plates-formes de messagerie de bout en bout. »
Le développement intervient alors que l’Internet Engineering Task Force (IETF) a publié la spécification de base du protocole Messaging Layer Security (MLS) en tant que demande de commentaires (RFC 9420).
Certaines des autres grandes entreprises qui ont soutenu le protocole sont Amazon Web Services (AWS) Wickr, Cisco, Cloudflare, The Matrix.org Foundation, Mozilla, Phoenix R&D et Wire. Il manque notamment à la liste Apple, qui propose iMessage.
MLS, comme son nom l’indique, est une couche de sécurité pour le cryptage de bout en bout qui facilite l’interopérabilité entre les services et plates-formes de messagerie. Il a été approuvé pour publication en tant que norme par l’IETF en mars 2023.
« MLS s’appuie sur les meilleures leçons de la génération actuelle de protocoles de sécurité », notait à l’époque l’IETF. « Comme le protocole Double Ratchet largement utilisé, MLS permet un fonctionnement asynchrone et fournit des fonctionnalités de sécurité avancées telles que la sécurité post-compromis. Et, comme TLS 1.3, MLS fournit une authentification robuste. »
Au cœur de MLS se trouve une approche connue sous le nom d’accord de clé de groupe continu (CGKA) qui permet à plusieurs clients de messagerie de s’entendre sur une clé partagée qui s’adresse à des groupes allant de deux à des milliers d’une manière qui offre des garanties de confidentialité transmises quelles que soient les personnes qui rejoignent et quittent la conversation de groupe.
« La fonctionnalité principale de MLS est l’échange de clés authentifié en groupe continu (AKE) », lit-on dans le document standard. « Comme avec d’autres protocoles d’échange de clés authentifiés (tels que TLS), les participants au protocole s’accordent sur une valeur secrète commune, et chaque participant peut vérifier l’identité des autres participants. »
« Ce secret peut ensuite être utilisé pour protéger les messages envoyés par un participant du groupe aux autres participants à l’aide de la couche de cadrage MLS ou peut être exporté pour être utilisé avec d’autres protocoles. MLS fournit un AKE de groupe dans le sens où il peut y avoir plus de deux participants dans le protocole, et un AKE de groupe continu dans le sens où l’ensemble des participants au protocole peut changer avec le temps. »
Cette adhésion évolutive est réalisée au moyen d’une structure de données appelée arbre à cliquet asynchrone, qui est utilisée pour dériver des secrets partagés parmi un groupe de clients. L’objectif est de pouvoir supprimer efficacement n’importe quel membre, en réalisant une sécurité post-compromis en empêchant l’interception des messages de groupe même si un membre a été violé à un moment donné dans le passé.
D’autre part, le secret de transmission, qui permet de sécuriser les messages envoyés à un certain moment face à la compromission ultérieure d’un membre du groupe, est fourni en supprimant les clés privées des versions antérieures de l’arbre à cliquet, évitant ainsi que les anciens secrets de groupe soient redérivés.
Mozilla, qui espère voir une normalisation d’une API Web pour exploiter le protocole directement via les navigateurs Web, a déclaré que MLS est conçu de telle sorte que « la légitimité des nouveaux membres entrant dans un groupe est vérifiée par tout le monde : il n’y a nulle part où se cacher ».
