Retirer une personne d’un groupe chiffré devrait l’empêcher de recevoir les secrets nécessaires aux futurs messages protégés. Modifier uniquement la liste des membres ne suffit pas si les expéditeurs restants continuent d’utiliser du matériel de clé que l’ancien membre connaît déjà.
La transition n’est pas non plus instantanée sur l’ensemble d’un réseau peu fiable. Une architecture de groupe sûre doit définir à quel état d’appartenance correspond un message et ce que fait un expéditeur avant d’avoir traité un retrait.
Les messages passés et futurs sont des problèmes distincts
Un ancien membre peut conserver les messages, fichiers et clés reçus lorsqu’il était autorisé. Son retrait ne peut ni lui faire oublier l’historique ni effacer ses captures d’écran.
L’objectif réalisable consiste à l’exclure du nouvel état cryptographique après la prise d’effet du retrait. De même, ajouter une personne soulève une question distincte : obtient-elle l’accès à l’ancien historique ? Les produits et protocoles emploient des termes comme la confidentialité persistante dans différents contextes ; décrire simplement la règle d’accès souhaitée est donc souvent plus clair qu’une étiquette ambiguë.
Pourquoi les groupes à clés d’expéditeur ont besoin d’un nouvel état
Dans une architecture à clés d’expéditeur, chaque participant peut chiffrer les messages ordinaires du groupe avec une chaîne partagée avec les destinataires autorisés. Cela peut éviter de chiffrer séparément l’intégralité du contenu pour chaque destinataire à chaque envoi.
Après un retrait, l’ancien membre peut encore posséder l’ancienne chaîne. Les expéditeurs restants ont donc besoin d’un état de remplacement non distribué au membre exclu, et les clients d’un contexte d’appartenance convenu pour l’utiliser. La rotation doit couvrir les expéditeurs et appareils concernés ; modifier un seul indicateur côté serveur ne suffit pas.
Le protocole exact compte. MLS, spécifié dans la RFC 9420, gère le retrait par un changement d’époque validé qui fournit une nouvelle entropie aux membres restants. C’est un exemple de transition d’état définie, et non l’affirmation que Livara implémente MLS.
Ce que Livara documente pour LGS1
La page de sécurité de Livara décrit une chaîne d’expéditeur signée par expéditeur, les clés étant distribuées via des sessions LVR1 par paires. Elle indique que de nouvelles clés d’expéditeur sont créées et distribuées lors des changements d’appartenance.
Cela étaye une affirmation sur l’architecture publiée de renouvellement des clés. Cela n’établit pas un délai mesuré de « révocation instantanée » et ne prouve pas que chaque condition de concurrence, scénario d’appareil hors ligne et nouvelle tentative est correctement géré. Ces points nécessitent une analyse de l’implémentation et des tests.
Les contrôles d’appartenance côté serveur et l’exclusion cryptographique ont également des rôles différents. Le service peut refuser la livraison ou l’accès, tandis que le chiffrement devrait empêcher une partie exclue disposant d’une copie d’un texte chiffré ultérieur de l’ouvrir sans les nouveaux secrets.
Un plan de test utile pour le retrait
Dans un groupe de test autorisé, vérifiez les scénarios suivants avec des messages non sensibles :
| Scénario | Question à résoudre |
|---|---|
| Retrait d’un membre alors que tous sont en ligne | Quel message est le premier sous le nouvel état d’appartenance ? |
| Un expéditeur restant est hors ligne | Doit-il actualiser l’appartenance et les clés avant de renvoyer des messages ? |
| Le membre retiré se reconnecte plus tard | Peut-il obtenir de nouvelles distributions de clés d’expéditeur ou seulement les anciens contenus auxquels il était autorisé ? |
| Plusieurs changements de membres surviennent simultanément | Tous les appareils restants convergent-ils vers le même état ? |
| Un ancien message fait l’objet d’une nouvelle tentative | Son époque d’origine est-elle conservée plutôt que le message soit étiqueté à tort comme nouveau contenu ? |
Un test limité à l’interface peut confirmer le comportement visible, mais ne peut pas prouver à lui seul l’exclusion cryptographique. Une évaluation rigoureuse doit examiner les clés et textes chiffrés qu’un appareil de test exclu peut obtenir.
Ce que les administrateurs doivent retenir
Retirez les participants inutiles, examinez les membres restants et évitez d’envoyer de nouveaux contenus sensibles tant que l’application n’a pas traité le changement. Si un participant actuel transfère délibérément du contenu, le renouvellement des clés du groupe ne peut empêcher cette divulgation.
Pour un usage hautement sensible, demandez au fournisseur les règles précises de retrait, le comportement de révocation des appareils et les preuves issues des tests. La promesse importante est une frontière bien définie pour les futurs messages, pas une affirmation non étayée selon laquelle un bouton de retrait détruit toutes les copies passées.
