L'Internet Engineering Council (
IETF) a publié un
projet de nouveau protocole - Message Layer Security (MLS). Sa mission est de fournir une messagerie sécurisée entre deux appareils. Il décrit des structures de données abstraites qui peuvent être utilisées non seulement dans les applications de chat, mais aussi pour travailler avec
TLS 1.3 et JSON. Parlons des principes du MLS.
/ photo Rama CCLes ingénieurs de l'IETF ont publié deux documents. Le premier
décrit les exigences du système de messagerie pour implémenter le protocole MLS, et le second
décrit le protocole MLS lui-même .
À propos de l'architecture de messagerie
Le service de messagerie (Messaging Service) comprend deux services qui surveillent la sécurité de la réception / transmission des messages.
Le premier est le service d'authentification. Il est responsable de la sécurité des données personnelles - identifiant, numéro de téléphone, ainsi qu'une paire de clés unique pour identifier les clients.
Le second - Delivery Service - stocke et distribue les clés entre les clients pour échanger des messages cryptés. Le service de livraison fonctionne uniquement avec les données nécessaires à la messagerie et ne touche pas aux informations personnelles des expéditeurs. Cela limite «l'empreinte» des métadonnées côté serveur.
Dans de nombreux systèmes, les services de livraison et d'identification sont représentés par une seule entité logique ou serveur. Cependant, dans MLS, ce sont deux composants distincts. Les auteurs ont décidé de séparer ces processus afin que MLS puisse être utilisé avec des protocoles d'autorisation ouverts, tels que
OAuth .
Cela fournit un autre avantage. Même si le fournisseur de services de messagerie contrôle les processus d'authentification et de remise, les métadonnées seront protégées de manière fiable. Le fournisseur ne pourra pas associer de messages chiffrés à des clés publiques.
Comment fonctionne MLS
Les utilisateurs de messagerie sont regroupés. Pour créer un groupe, les participants «ajoutent» leurs clés UserInitKey et forment un
secret . UserInitKey est une paire clé
Diffie-Hellman et sert à initialiser des utilisateurs individuels.
Le protocole utilise deux types d'
arbres binaires . Le premier - l'
arbre Merkle (c'est un arbre de hachage) - sert à confirmer l'authenticité des opérations menées par les membres du groupe. Le deuxième type - Ratchet-tree - est utilisé pour extraire leurs secrets.
Le groupe peut effectuer les opérations de base suivantes:
- Ajoutez un nouveau membre du groupe (créez un dialogue).
- Mettre à jour les informations secrètes des membres du groupe.
- Supprimez un membre du groupe.
Si un membre du groupe A souhaite créer un dialogue avec B et C, il télécharge d'abord ses clés d'initialisation (InitKeys). Ensuite, ces clés sont utilisées pour former des messages GroupAdd, qui doivent ajouter les membres B et C.
Les messages GroupAdd sont envoyés à l'ensemble du groupe et traités dans l'ordre B et C. Lorsque leurs réponses reviennent à A, l'état du groupe est mis à jour et il affiche «nouveaux arrivants». Tous les autres messages envoyés par les membres du système avant d'être acceptés dans le groupe sont ignorés.
Contrairement à TLS et DTLS, le nouveau protocole ne contient pas la phase de «prise de contact» en tant que telle. MLS utilise les soi-disant messages de prise de contact. Les participants à la correspondance les échangent à chaque fois, vous devez ajouter ou supprimer un nouveau membre du groupe.
Le message de prise de contact encapsule un message spécial sur le changement de statut du groupe, et inclut également GroupInitKey, afin qu'un nouveau membre puisse être initialisé, et les signatures de l'un des membres actuels du groupe, ainsi que la preuve de Merkl (pour vérifier l '«authenticité» de la personne qui a signé).
Ce qui attend MLS
Des représentants de Google, Mozilla, Twitter, du MIT, de l'institut de recherche français
INRIA et de la plateforme de communication Wire
ont participé au développement de l'architecture et des exigences du MLS. Le protocole lui-même a été créé par des personnes de Cisco, Facebook, Google et Oxford University.
/ Catalogue de livres photo CCLe sort du protocole sera décidé le mois prochain, lorsque le Conseil de l'IETF se réunira pour discuter à nouveau du projet d'options. Si tout se passe bien, alors dans un an, le MLS sera approuvé par l' IESG (Internet Engineering Steering Group), et il deviendra une norme.
Ce que nous faisons dans IT-GRAD: • IaaS • Hébergement PCI DSS • Cloud -152
Contenu de notre blog d'entreprise IaaS: