Résumé

  • Dans MLS, les membres du groupe peuvent calculer les clés AEAD des chaînes d’envoi. Un déchiffrement réussi atteste donc une capacité détenue dans le groupe, pas l’origine auprès d’un client unique.
  • La signature propre au client fournit une preuve d’origine plus forte. La validation d’identité, le droit d’agir, la livraison et le résultat humain exigent encore leurs propres reçus.
  • Une nouvelle époque cryptographique ne clôt pas, à elle seule, un incident : il faut identifier le secret compromis et vérifier retrait, révocation, convergence et reprise applicative.

La scène se joue avant même la signature du contrat. Dans une grille d’audit, le fournisseur coche « chiffrement authentifié », « identité vérifiée » et « livraison sécurisée ». Les trois formulations semblent raconter la même continuité. Or chacune peut relever d’un système différent, observer un état différent et échouer sans entraîner les deux autres. Acheter la continuité verbale revient à acheter une ambiguïté opérationnelle.

La RFC 9750, publiée comme document d’architecture informatif, fournit un antidote précis. Dans Messaging Layer Security, le cadrage commun protège les messages par chiffrement authentifié. Mais tous les membres disposent des secrets du groupe et peuvent calculer les clés AEAD des chaînes d’envoi de l’époque. L’ouverture valide d’un message signifie qu’un membre — ou un attaquant ayant compromis les clés correspondantes — a pu le produire. Elle ne choisit pas un client parmi tous les détenteurs possibles.

Ce résultat n’est ni faible au sens courant, ni défectueux. Il est simplement borné par la distribution de la clé. Une capacité partagée produit une preuve collective. Lui faire dire « ce client précis a envoyé » ajouterait une conclusion que le mécanisme n’a pas observée.

La signature constitue un deuxième reçu

La RFC 9420, spécification MLS sur la voie de normalisation, apporte le niveau suivant. Chaque message porte une signature numérique. Pour un membre, la clé de vérification se trouve dans le LeafNode indiqué par l’index de feuille. La signature couvre le contenu, sa représentation sur le réseau et le GroupContext de l’époque. Elle lie donc l’acte à une capacité de signature particulière dans un état de groupe déterminé.

La différence devient essentielle en cas de compromission. Avec les seuls secrets AEAD, un adversaire peut parfois produire du chiffré acceptable sans pouvoir imiter la signature d’un client valide. À l’inverse, le vol de la clé de signature — ou l’accès à un oracle capable de signer à la demande — atteint directement la preuve d’origine. Un module matériel peut empêcher l’extraction de la clé sans empêcher nécessairement tous les abus de l’opération de signature.

Les journaux devraient conserver séparément l’ouverture AEAD, l’époque et la génération acceptées, l’index de feuille, le résultat de la signature et la décision d’identité. Réduire ces événements à un booléen « authentique » détruit la distinction même dont l’enquête aura besoin pour circonscrire l’incident.

Cette séparation justifie aussi des protections asymétriques. La RFC 9750 recommande d’accorder une priorité particulière aux clés privées de signature et évoque les modules matériels ou enclaves sécurisées. Les secrets de groupe changent souvent et ne se prêtent pas toujours au même traitement. Une politique uniforme des secrets peut sembler simple dans un questionnaire ; elle masque en réalité des durées de vie, des usages et des conséquences différentes.

L’identité et le mandat restent hors de la signature

L’unité MLS est un client, pas une personne. Un même utilisateur peut avoir plusieurs appareils, donc plusieurs clients et plusieurs clés. Le service d’authentification délivre les justificatifs, contrôle la liaison entre identité de référence et clé, puis décide si deux justificatifs désignent le même client. Ces décisions encadrent la cryptographie sans être produites par elle.

Une signature valide assortie d’un justificatif valide peut identifier un client selon les règles de ce service. Elle ne prouve pas qu’une personne donnée était devant l’écran, qu’elle détenait encore une fonction organisationnelle ni qu’elle avait le droit métier d’effectuer l’opération. Une session automatisée, une délégation, un appareil partagé ou un rôle révoqué ailleurs peuvent tous laisser une signature techniquement correcte.

L’application détient la règle d’autorisation. La RFC 9750 précise que MLS n’impose pas lui-même le contrôle d’accès aux opérations de groupe. L’application décide qui peut ajouter ou retirer des membres, approuver une publication ou engager une modification sensible. Une Proposal décrit un changement envisagé ; un Commit modifie l’état. Aucun des deux ne devient, par sa seule validité cryptographique, le procès-verbal d’une approbation humaine légitime.

La présentation publique doit respecter cette frontière. « Signature du client vérifiée » est une observation. « Identité attendue confirmée » dépend du service d’authentification. « Action autorisée » dépend de la politique. Fusionner les trois sous un badge rassurant donne à la première couche une autorité institutionnelle qu’elle ne possède pas.

Une enveloppe valide ne prouve pas la livraison

Le service de livraison achemine les messages MLS et distribue les matériaux initiaux. Il peut assurer un ordre fort ou une cohérence éventuelle. Il peut aussi retarder, supprimer ou désordonner des éléments, voire conduire des clients vers des histoires divergentes. La sécurité vise à l’empêcher de lire le contenu ou de forger des messages clients acceptables ; elle ne transforme pas disponibilité et convergence en propriétés automatiques.

L’acceptation du chiffré par un appareil ne prouve donc pas que tous les destinataires l’ont récupéré, qu’ils ont accepté la même époque, qu’ils l’ont affiché ou qu’un lecteur a agi. Pour affirmer la livraison, il faut des reçus distincts : admission par le service, diffusion, récupération par client, traitement cryptographique, convergence d’état, présentation, puis observation du résultat lorsque celui-ci importe.

Le cas d’un nouveau client l’illustre bien. L’émission d’un message Welcome ne suffit pas à établir que le client l’a reçu et déchiffré. Tant qu’il n’a pas rejoint le groupe et contribué à l’état secret d’une manière vérifiable par les autres, son appartenance opérationnelle reste incertaine. L’envoi n’est pas la réception ; la réception n’est pas la convergence.

Dire quel secret a été compromis

La formule « les clés ont été changées » est insuffisante. Une compromission du ratchet peut exposer les clés AEAD actuelles et futures d’une chaîne pendant une époque, tout en préservant des clés passées correctement effacées. Une compromission plus large des secrets du groupe peut affecter chiffrement et déchiffrement pendant plusieurs époques. Une capacité de signature compromise porte sur l’attribution et peut demander une révocation propre.

Après une compromission passive, un Commit honnête peut installer des secrets neufs selon les conditions de sécurité post-compromission décrites par l’architecture. Face à un acteur toujours actif dans le protocole, la situation est plus exigeante : le retrait de la partie compromise est l’opération qui rétablit le secret pour les époques ultérieures lorsque les autres membres restent honnêtes.

Même alors, l’époque nouvelle n’est qu’un reçu cryptographique. La clôture exige la preuve du retrait ou de la mise à jour du client, de la révocation appropriée des justificatifs, de l’admission correcte des appareils de remplacement, du rétablissement de la politique et de la convergence des destinataires. « Époque avancée après retrait du client concerné » est une conclusion plus petite, mais beaucoup plus vérifiable, que « sécurité rétablie ».

Une échelle de preuve exploitable

Un cahier des charges sérieux devrait exiger huit réponses indépendantes : le chiffré a-t-il été analysé et ouvert ; l’époque, la génération et l’anti-rejeu ont-ils été acceptés ; la signature correspond-elle au LeafNode attendu ; le justificatif correspond-il à l’identité de référence ; le client était-il membre de l’état courant ; la politique autorisait-elle l’opération ; la livraison et le traitement ont-ils produit leurs reçus ; enfin, le résultat humain ou métier a-t-il été observé séparément ?

Sauter un barreau ne constitue pas un raccourci cryptographique. C’est une affirmation analytique supplémentaire. La discipline consiste à dire qui a observé quoi, à quel moment et sous quelle autorité.

Ni la RFC 9750 ni la RFC 9420 ne prouve qu’un produit nommé applique cette architecture. Les textes ne décrivent pas davantage un incident mesuré. Leur portée est plus utile : ils rendent visible une carte de responsabilités. Grâce à elle, les achats peuvent exiger les bons reçus, les opérations peuvent conserver les bons états et la direction peut refuser qu’un voyant vert se transforme en certitude universelle.

Sources