Une copie du disque, le contrôle actif du serveur et l’accès à un téléphone sont trois scénarios différents ; une garantie générale ne suffit pas pour les trois.
Si un serveur de messagerie est pris sous contrôle, la réponse précise à « Qu’est-ce qui est révélé ? » dépend des données stockées, de l’emplacement des clés et du type d’accès de l’attaquant. Obtenir une copie du disque n’est pas la même chose que contrôler le service en fonctionnement et le circuit de distribution de l’application.
Cet article examine un scénario hypothétique à partir de la documentation publique de Livara. Il n’affirme ni l’emplacement des datacenters de Livara, ni la survenue d’une saisie, ni un fonctionnement garanti du service lors d’une coupure d’Internet. Chiffrement du contenu, disponibilité du réseau et sécurité de l’infrastructure sont des sujets distincts.
Déterminer d’abord le type d’accès
Une copie stockée du serveur : L’attaquant accède aux fichiers, bases de données ou sauvegardes présents dans cette copie. Si le contenu privé a été correctement chiffré sur l’appareil et si le serveur ne possède pas sa clé de déchiffrement, cette copie seule ne révèle pas le texte de la conversation.
Le contrôle actif du service : Outre la lecture des données existantes, l’attaquant peut bloquer certaines requêtes, renvoyer d’anciennes données ou modifier le comportement des composants qu’il contrôle. La vérification de l’identité du contact, le contrôle des versions et l’intégrité du client deviennent plus importants dans ce scénario.
L’accès simultané à l’appareil : Un téléphone déverrouillé, un logiciel malveillant ou une copie lisible détenue par un membre de la conversation peuvent révéler le contenu par une voie totalement différente. Le modèle de menace de Livara ne garantit pas non plus la protection d’un appareil déverrouillé ou infecté.
Quelles données sont visibles sur le serveur selon la documentation de Livara ?
La page de sécurité de Livara, portant la version 0.1.68, distingue le contenu des conversations directes sous LVR1 et des groupes privés compatibles sous LGS1 des informations opérationnelles. Cette même page indique qu’un ancien groupe incompatible reste explicitement hors E2EE ; il faut donc vérifier l’état de la conversation concernée.
| Catégorie de données | Limite documentée et conséquence possible |
|---|---|
| Texte et pièces jointes d’une conversation protégée | Le serveur conserve une copie chiffrée ; sa lecture exige la clé appropriée |
| Métadonnées de communication | Le service dispose d’informations telles que les participants, l’heure, la taille et l’état de livraison |
| Appartenance à un groupe | Relève des informations et des pouvoirs opérationnels du serveur |
| Canal public | Le contenu est public et lisible par le serveur |
| Paquet de récupération d’identité v7 | Chiffré avant l’envoi et nécessite un secret de récupération distinct |
| Mode facultatif d’enregistrement côté serveur | Distingué du mode E2EE par l’indicateur REC ; il ne faut pas lui supposer une confidentialité de bout en bout |
Du code LSS1 de protection des métadonnées est mentionné dans la documentation, mais il n’est pas raccordé à l’envoi ordinaire des messages. La présence du nom d’un protocole dans un projet ne prouve pas qu’il soit actif dans toutes les communications.
Ce tableau décrit les affirmations du produit, non les résultats d’un véritable test de saisie ou d’un audit indépendant de toutes les versions de la base de données.
Quelle importance les métadonnées peuvent-elles avoir ?
Les informations sur les communications entre personnes, les horaires et les appartenances aux groupes peuvent être sensibles même sans le texte des messages. Toutefois, dire « l’intégralité du graphe de communication est révélée pour toujours » manque de précision sans connaître la durée de conservation, la couverture des journaux et la version des données obtenues.
Une évaluation réelle doit demander quels champs ont été collectés, combien de temps ils ont été conservés et quelles sauvegardes sont accessibles. Le chiffrement du contenu ne détermine pas à lui seul la politique de conservation. On ne peut pas non plus déduire de l’architecture d’une messagerie que toutes conservent nécessairement les mêmes métadonnées.
Quels risques le contrôle du serveur présente-t-il pour les futurs messages ?
Une évaluation de sécurité doit tester séparément la manipulation de la liste des membres, la fourniture d’une clé d’identité différente, le blocage des mises à jour et la distribution d’un client malveillant. Les effets de chaque cas dépendent de la validation côté client, de l’affichage des changements et de la vérification de l’identité.
Sans tester l’implémentation, on ne peut affirmer que tout serveur compromis peut nécessairement ajouter un membre caché ; on ne peut pas davantage affirmer que le contrôle actif du serveur n’a aucun effet. Pour une conversation sensible, les changements inattendus d’identité ou de membres doivent être examinés. Comparer les empreintes des clés avec le contact par une voie indépendante et fiable apporte davantage d’informations que la seule confiance dans un nom affiché.
Si l’attaquant modifie le code exécuté sur l’appareil, il peut éventuellement voir le texte avant son chiffrement. C’est pourquoi la sécurité de la distribution et des mises à jour de l’application fait partie de ce scénario, et n’est pas un sujet extérieur au chiffrement.
Qu’apporte le caractère post-quantique ?
La norme NIST FIPS 203 relative à ML-KEM aide à établir un secret partagé. Son utilisation correcte dans une construction hybride peut réduire le risque de certaines attaques futures contre l’échange de clés. Cela ne remplace ni la sécurité de l’appareil, ni une conservation limitée des métadonnées, ni les contrôles d’accès au serveur.
Le Proof Lab ne démontre lui aussi que certaines opérations locales P-256, HKDF et AES-GCM, et exclut de ce test la composition complète LVR1/LGS1. Un résultat positif ne garantit pas la résistance du produit entier à une prise de contrôle de l’infrastructure.
Que faire lors d’une évaluation ou d’un incident réels ?
- Consigner le type d’accès et les informations confirmées ; ne pas confondre une rumeur de perturbation avec un incident de sécurité avéré.
- Vérifier la version de l’application et l’état du chiffrement de la conversation concernée.
- Examiner les changements d’identité, les membres du groupe et les sessions inconnues par les voies officielles.
- Ne pas confier de secret de récupération, de mot de passe ni de contenu privé à des inconnus pour un « contrôle de sécurité ».
- En cas de risque grave ou de question juridique, consulter un spécialiste approprié et ne pas prendre de mesures irréversibles sur la base d’un article.
Une conclusion fiable doit préciser quelles données sont protégées, dans quelle version et contre quel type d’accès. « Même si le serveur est saisi, il ne se passe rien » ne remplace pas cette réponse.
