Le piratage d’un serveur de messagerie ne signifie pas nécessairement que tous les messages ont été lus. Le résultat dépend des données stockées, de l’emplacement des clés et du niveau d’accès de l’attaquant. Même lorsque le texte des conversations est correctement chiffré de bout en bout, les informations de compte, les horaires, l’appartenance aux groupes et les chemins d’acheminement peuvent être sensibles.
Pour évaluer un incident, demandez d’abord ce que l’attaquant a obtenu : une copie de la base de données, des clés d’infrastructure, un serveur actif ou le système de distribution du logiciel ? Ces scénarios n’ont pas les mêmes conséquences.
Une base volée diffère d’un serveur sous contrôle
Un attaquant disposant seulement d’une ancienne copie de la base de données est limité aux données qui y figurent. Le contrôle du service actif peut permettre de collecter de nouvelles données, de voler des sessions, de modifier les réponses ou de tenter de remplacer la clé d’un contact. L’accès à la chaîne de distribution du logiciel présente un autre risque : du code malveillant sur un terminal peut voir le texte avant le chiffrement ou après le déchiffrement.
L’affirmation « la base de données ne contient pas de clé permettant de lire les messages » est donc importante, mais ne répond pas entièrement à tous les types d’intrusion.
Comparaison de cinq modèles d’architecture
Ce sont des modèles pédagogiques, pas un classement de cinq produits. Un service peut employer plusieurs modèles pour des fonctionnalités différentes.
| Modèle | Données accessibles depuis la base | Limite importante |
|---|---|---|
| Messages et mots de passe en clair | Contenu et identifiants directement lisibles | Absence de protection adaptée pour les deux types de données |
| Mots de passe hachés, messages en clair | Contenu lisible ; des hypothèses de mots de passe peuvent être testables | La qualité du stockage des mots de passe ne protège pas les conversations |
| Contenu chiffré avec une clé du serveur | Texte chiffré ; la lecture dépend de l’accès à la clé | Une véritable séparation entre clés et données est importante |
| Conversation E2EE avec sauvegarde accessible au fournisseur | La conversation en direct peut être protégée, mais la copie de l’historique crée une voie d’exposition distincte | La politique et les clés de sauvegarde doivent être examinées |
| Conversation E2EE avec récupération chiffrée et clé indépendante | Texte chiffré et données opérationnelles ; la protection du contenu dépend de la conception et de la protection des clés | L’appareil, la phrase de récupération et l’authentification du contact restent importants |
Le chiffrement des disques du serveur est utile contre le vol d’un disque brut. Lorsque l’attaquant dispose aussi du service actif ou de la clé de déchiffrement, il ne faut pas présumer la même protection. L’E2EE vise à empêcher le service intermédiaire de détenir la clé nécessaire pour lire le contenu protégé.
Que révèlent les métadonnées ?
Les métadonnées peuvent indiquer quels comptes ont communiqué, quand ils étaient actifs, à quels groupes ils appartiennent et quelle quantité de données a été transférée. Ce n’est pas le texte des messages, mais ces informations permettent de comprendre les réseaux de relations ou les habitudes d’activité.
La page de sécurité de Livara décrit explicitement le stockage et le traitement de données opérationnelles, notamment le routage, les appartenances, les horaires, la taille du texte chiffré et l’état de livraison. La confidentialité du contenu privé ne doit pas être interprétée comme un anonymat complet ou une absence totale de données sur le serveur.
SRP ne met pas les données de compte à l’abri des tentatives de devinette
SRP permet de prouver la connaissance d’un mot de passe sans transmettre directement ce dernier. Le serveur conserve néanmoins des données de vérification, appelées verifier. La section sécurité de la RFC 5054 explique que leur vol peut permettre une attaque par dictionnaire pour deviner le mot de passe.
Ainsi, « le mot de passe n’est pas envoyé sur le réseau » diffère de « aucune donnée liée au mot de passe ne peut être volée ». Un mot de passe fort et unique, la protection de l’appareil et une réponse adaptée à l’incident restent nécessaires. SRP ne remplace pas non plus le chiffrement du contenu ni la protection des sessions de connexion.
Quelles limites Livara annonce-t-il ?
Le document de sécurité de Livara décrit LVR1 pour les messages directs et LGS1 pour les groupes protégés. La protection d’un groupe dépend de son état réel ; un ancien groupe incompatible ne doit pas porter l’étiquette E2EE. Les canaux publics se trouvent en dehors de cette frontière de confidentialité.
Ce même document présente la récupération v7 comme un paquet d’identité chiffré et protégé avant son téléversement. Ce processus restaure l’identité cryptographique, pas l’historique des conversations. La divulgation de la phrase de récupération ou d’un appareil contenant les clés constitue un scénario différent du simple vol de la base de données.
Il s’agit de descriptions publiées du produit, et non des conclusions d’un audit indépendant réalisé dans cet article. Citer AES ou ML-KEM ne prouve pas non plus, à lui seul, la bonne gestion des clés ou la bonne implémentation de l’application.
Quelles questions poser lors de l’annonce d’un incident ?
- Quelle période et quels systèmes ont été touchés ? L’expression vague « informations des utilisateurs » ne suffit pas.
- Du texte en clair, des fichiers, des clés, des verifiers, des sessions de connexion ou seulement du texte chiffré étaient-ils accessibles ?
- L’attaquant pouvait-il modifier le service ou le logiciel distribué aux utilisateurs ?
- Quelles actions faut-il effectuer par les voies officielles : déconnecter les sessions, changer le mot de passe, mettre à jour ou vérifier l’identité des contacts ?
- La récupération recommandée risque-t-elle d’effacer l’historique local ? Lisez les limites avant de désinstaller l’application.
N’utilisez pas le lien d’un message anonyme pour une « vérification urgente du compte ». Ouvrez vous-même l’annonce à l’adresse officielle. Le modèle de menace de Livara aide à comprendre les limites générales ; l’étendue d’un incident réel doit être établie à partir de ses propres éléments de preuve.
