Chiffrer le contenu une seule fois ne supprime pas le coût de la distribution des clés et de la livraison du message à tous les membres.
Dans l’architecture « clé d’expéditeur », ou Sender Key, l’expéditeur n’a pas besoin de chiffrer séparément le même contenu pour chaque membre du groupe. Chaque expéditeur possède sa propre chaîne de clés et transmet aux membres autorisés, par un chemin sécurisé, les éléments de clé nécessaires pour lire ses messages. Cette méthode réduit le coût du chiffrement du contenu ; les coûts de distribution des clés, de livraison des messages et de gestion des membres subsistent.
Comment LGS1 est-il décrit chez Livara ?
Selon la documentation de sécurité de Livara, LGS1 utilise une chaîne et une clé de signature distinctes pour chaque expéditeur, pour les messages de groupes privés compatibles en mode E2EE. Les clés d’expéditeur sont distribuées dans des sessions LVR1 entre deux participants ; une clé de message est ensuite dérivée pour chaque position de la chaîne. La documentation décrit également une rotation des clés après l’arrivée ou le départ de membres. Il s’agit d’une description de l’architecture du produit, et non du résultat d’un test de performance ou d’un audit indépendant réalisé par cet article.
Le parcours d’un message de groupe, étape par étape
- Préparation des membres : L’appareil doit vérifier l’identité cryptographique des destinataires et leur appartenance autorisée au groupe.
- Distribution de la clé d’expéditeur : Les informations nécessaires parviennent aux membres par des sessions privées. Pour un grand groupe, cette étape n’est ni gratuite ni indépendante du nombre de membres.
- Dérivation de la clé de message : La chaîne avance afin que des contenus différents ne soient pas chiffrés avec la même clé de message.
- Chiffrement et authentification : Le contenu est chiffré et le destinataire doit vérifier l’intégrité du message et l’identité de l’expéditeur.
- Changement de membres : Les clés de l’époque suivante ne doivent être accessibles qu’aux membres autorisés restants.
La « clé d’expéditeur » ne doit pas être assimilée à l’utilisation permanente d’une même clé AES pour tous les messages. L’état de la chaîne, le numéro de message et l’époque de clé font partie d’une conception sûre.
Quels coûts diminuent et lesquels subsistent ?
| Partie du travail | Effet de l’architecture à clé d’expéditeur |
|---|---|
| Chiffrement du contenu d’un message ordinaire | Peut être effectué une fois, au lieu de produire une copie chiffrée séparément pour chaque destinataire |
| Distribution des clés initiales ou nouvelles | Doit couvrir les membres autorisés ; le nombre de membres et d’appareils compte |
| Transmission réseau à tous les membres | Nécessite toujours de livrer les données aux destinataires |
| Départ d’un membre et appareil hors ligne | Nécessitent une gestion des époques, une coordination et un comportement clairement défini en cas d’échec |
L’affirmation « le coût total du groupe passe de O(N) à O(1) » est donc inexacte. On peut parler d’une opération précise, pas de l’ensemble du réseau. La vitesse et la consommation de batterie et de données doivent aussi être mesurées pour une version de l’application, un nombre de membres et des appareils précis.
Où intervient la protection post-quantique ?
Livara relie la distribution des clés de groupe aux sessions hybrides LVR1. La présence d’un composant post-quantique ne démontre pas à elle seule toutes les propriétés du groupe : la combinaison des clés, les signatures, la gestion de l’état et la validation des membres comptent également. La normalisation d’un algorithme ne vaut pas approbation de la sécurité d’une messagerie complète.
Pour comparer les architectures, le RFC 9420 sur MLS constitue un exemple de spécification formelle de gestion des clés de groupe. LGS1 ne doit pas être présenté comme MLS lui-même ou comme son implémentation ; les garanties de chaque protocole doivent être lues dans ses propres spécifications et éléments de preuve.
Que vérifier avant de faire confiance à un groupe privé ?
- Le groupe lui-même utilise-t-il réellement le chiffrement de bout en bout ? La documentation de Livara indique qu’un ancien groupe incompatible ne doit pas être étiqueté comme chiffré sans justification.
- Qui peut ajouter des membres, et comment les membres sont-ils informés d’un changement ?
- Un nouveau membre peut-il accéder à l’historique passé ou seulement aux messages futurs ? Vérifiez la réponse pour cette même version de l’application.
- L’époque de clé change-t-elle après le retrait d’un membre ? Le retrait de la liste ne prouve pas, à lui seul, le changement de clé.
- Les membres actuels peuvent-ils copier un message ? Oui ; le chiffrement ne supprime pas la nécessité de faire confiance au destinataire.
Questions fréquentes
Retirer un membre efface-t-il ses anciens messages ?
Non. La rotation des clés vise à limiter l’accès futur ; une copie déjà reçue ou enregistrée n’est pas nécessairement effacée de l’appareil du membre retiré.
LGS1 livre-t-il les messages lors d’une coupure totale du réseau ?
Le chiffrement ne crée pas de chemin de communication. La livraison exige que les appareils aient accès au service et à un chemin réseau ; distinguez la sécurité du contenu de la disponibilité.
Le serveur ne possède-t-il aucune information sur le groupe ?
Selon les limites déclarées par Livara, la confidentialité du contenu ne signifie pas que toutes les informations opérationnelles sont cachées. Lors du choix d’un groupe, lisez aussi les politiques relatives aux membres et aux métadonnées.
