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 », Giles Hogben, directeur de l’ingénierie de la confidentialité chez Google, a dit. « 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) libéré 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 un couche de sécurité pour un chiffrement 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é », IETF indiqué à l’époque. « Comme le très utilisé Protocole Double Ratchet, 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.3MLS fournit une authentification robuste. »
Au cœur du MLS se trouve une approche connue sous le nom de Accord de clé de groupe continu (CGKA) qui permet à plusieurs clients de messagerie de se mettre d’accord 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é de transmission, quelles que soient les personnes qui rejoignent et quittent la conversation de groupe.
« La fonctionnalité de base de MLS est l’échange de clés authentifié de groupe continu (AKE) », le document standard lit. « 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 obtenant sécurité post-compromis en empêchant les messages de groupe d’être interceptés 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 tirer parti du protocole directement via les navigateurs Web, a dit 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 ».