Un nom de protocole ne prouve pas la sécurité : l’architecture, l’implémentation et le comportement réel lors des changements de membres et de clés sont déterminants.
Messaging Layer Security (MLS) et LGS1 de Livara ne sont pas deux certificats interchangeables de sécurité des conversations de groupe. MLS est une norme de protocole de l’IETF ; LGS1 est la conception propre à son produit documentée par Livara. Une comparaison équitable doit distinguer architecture, preuves relatives à l’implémentation et comportement réellement vécu par les utilisateurs.
La distinction essentielle oppose un état de groupe partagé fondé sur un arbre à des clés d’expéditeur distribuées par des sessions entre paires. Aucune étiquette ne dit, à elle seule, si une application gère correctement un membre exclu, un appareil obsolète ou une clé compromise.
La différence d’architecture
La RFC 9420 spécifie MLS pour l’établissement asynchrone des clés de groupe. Elle utilise un arbre ratchet et des époques de groupe, avec confidentialité persistante et sécurité après compromission sous des conditions définies. Sa structure arborescente réduit certains coûts de mise à jour des clés lorsque le groupe s’agrandit.
La documentation de sécurité de Livara décrit LGS1 comme une chaîne d’expéditeur signée pour chaque membre, distribuée par des sessions LVR1 entre paires et renouvelée lors des changements de membres. Il s’agit d’une affirmation du produit, pas d’une preuve de conformité de LGS1 à MLS ni d’une analyse équivalente.
| Question | MLS | Documentation de Livara LGS1 |
|---|---|---|
| Structure partagée | Arbre ratchet et époques | Chaînes par expéditeur |
| Mises à jour des clés | Changements d’état du groupe intégrés dans une nouvelle époque | Nouvelles clés d’expéditeur distribuées aux membres |
| Statut de la spécification | Norme de l’IETF, RFC9420 | Description publiée propre au produit |
| Ce qui reste à évaluer | Intégration applicative et implémentation | Spécification complète, implémentation et preuves indépendantes |
Ce tableau décrit des catégories de conception. Ce n’est ni un benchmark ni un classement de sécurité.
Ce que « logarithmique » signifie — et ne signifie pas
Une mise à jour cryptographique peut utiliser un nombre logarithmique de composants chiffrés du chemin dans l’arbre sans rendre tout le travail du système logarithmique. Les messages doivent toujours être distribués, les clients conservent un état et le comportement dépend de la structure du groupe et des opérations. L’ancienne comparaison « MLS nécessite O(log N) messages alors que tout est plus rapide dans LGS1 » mélangeait différents coûts sans fournir de mesures.
L’architecture MLS, RFC 9750, traite le service de livraison séparément de l’établissement cryptographique des clés. Elle aborde la distribution des messages et l’ordonnancement des changements de groupe. Cette séparation compte : calcul côté client, octets d’un commit, distribution totale par le serveur et trafic de reconnexion sont des métriques différentes.
Un rapport de performances pertinent doit préciser :
- la taille du groupe et le nombre d’appareils par personne ;
- si l’opération est un message ordinaire, une exclusion de membre, une mise à jour des clés ou une reconnexion ;
- les octets envoyés par le client initiateur par rapport au trafic total de livraison ;
- le temps écoulé, le modèle d’appareil, la version de l’implémentation et les conditions réseau ;
- le coût des mises à jour manquées et des changements répétés de membres.
Sans ces détails, les affirmations de « millisecondes », de « faible coût d’état » ou de supériorité pour une certaine taille de groupe ne sont pas établies.
Exclure un membre est un test de cycle de vie
La suppression d’un compte par un administrateur n’est qu’une partie du sujet. Les clients doivent s’accorder sur le nouvel état des membres, utiliser de nouvelles clés appropriées et ne pas les fournir aux appareils exclus. Une personne possédant déjà du texte en clair ou d’anciennes clés peut garder accès aux anciens contenus ; son exclusion ne fait pas disparaître ses copies.
Pour les deux systèmes, un test utile pose ces questions : après la fin de l’exclusion, l’appareil retiré peut-il déchiffrer un nouveau message de test non sensible ? Un membre qui était hors ligne peut-il rattraper les changements sans danger ? Tous les appareils d’un compte sont-ils pris en charge ? L’interface rend-elle visibles les échecs et les changements de membres ?
Ce sont des questions d’évaluation proposées, pas les résultats de tests effectués ici. Une comparaison de produits doit publier les résultats observés et la version testée, plutôt qu’assimiler un clic administratif réussi à une exclusion cryptographique.
La confidentialité persistante et la récupération sont conditionnelles
Protéger les anciens messages après une compromission ultérieure dépend du retrait de l’ancien matériel secret. Rétablir la protection des futurs messages dépend de l’incorporation de nouveaux secrets après que l’attaquant a perdu l’accès concerné. Dans MLS, le traitement des mises à jour du groupe fait partie de cette récupération ; envoyer une mise à jour ne signifie pas que tous les membres l’ont appliquée. Consultez les considérations de sécurité de la RFC 9420.
Pour une conception à clés d’expéditeur, demandez comment l’état compromis de chaque expéditeur est remplacé et redistribué. Une chaîne à sens unique ne doit pas être décrite, à elle seule, comme se rétablissant automatiquement face à un attaquant qui connaît son état actuel. La protection entre paires utilisée lors de la redistribution est pertinente, mais ne remplace pas une analyse complète au niveau du groupe.
Les affirmations post-quantiques exigent une suite cryptographique et un périmètre précis
Les suites cryptographiques définies dans la RFC9420 de base utilisent des mécanismes classiques à clé publique. MLS est extensible : une affirmation sur une implémentation particulière doit donc identifier sa suite réelle et ses extensions, plutôt que déclarer que tous les déploiements MLS resteront définitivement classiques.
L’utilisation documentée de la distribution hybride LVR1 par LGS1 est une affirmation différente d’une garantie post-quantique analysée indépendamment pour chaque opération de groupe. FIPS 203 standardise ML-KEM ; elle ne certifie pas le protocole de groupe complet qui l’intègre. Évaluez ensemble authentification, changements de membres, compromission des clés et implémentation, pas seulement le nom du KEM.
Que demander avant de choisir un produit ?
Demandez la spécification actuelle du protocole, des vecteurs de test et une revue indépendante propre à la version, y compris les constats non résolus. Comparez ensuite les exigences ordinaires du produit : appareils pris en charge, comportement des mises à jour, récupération, rôles de modération et données conservées sur les serveurs.
L’architecture MLS considère explicitement les services applicatifs et leurs hypothèses de confiance. De même, le modèle de menace de Livara doit être lu avec ses affirmations produit. Le chiffrement ne rend pas les participants autorisés dignes de confiance, ne bloque pas les captures d’écran et n’élimine pas toutes les formes de métadonnées.
Si les preuves manquent, notez « non établi » au lieu de qualifier automatiquement une conception de dangereuse ou de supérieure. La décision doit refléter les risques de votre groupe et la qualité des preuves disponibles.
Questions fréquentes
LGS1 est-il une implémentation de MLS ?
Les descriptions publiées montrent des architectures différentes. Cet article ne présente pas LGS1 comme une implémentation de MLS et n’affirme pas leur interopérabilité.
MLS exige-t-il que tous les membres soient connectés en même temps ?
Non. L’usage asynchrone fait partie de sa conception. Les applications ont toujours besoin de politiques pour les mises à jour retardées, les états obsolètes et les membres longtemps hors ligne.
La distribution post-quantique des clés règle-t-elle la sécurité du groupe ?
Non. Elle traite une partie de l’établissement des clés. L’identité, la composition du groupe, le cycle de vie des clés, la sécurité des terminaux et l’implémentation nécessitent encore des preuves.
Quelle conception est la plus rapide ?
Aucun benchmark dans cet article ne désigne un vainqueur. Mesurez les opérations et le déploiement qui comptent pour votre groupe.
