Intégrité des messages : le serveur peut-il modifier un chat chiffré ?

Une messagerie peut permettre de modifier ou de supprimer un message. Mais, dans un système à chiffrement authentifié, le serveur ne devrait pas pouvoir modifier silencieusement le texte chiffré tout en livrant un message valide. L’intégrité des messages dans une messagerie permet au destinataire de détecter une modification des données après leur chiffrement ; elle n’équivaut ni à conserver un historique complet ni à prouver juridiquement une conversation.

Points essentiels

• Le chiffrement authentifié détecte l’altération du texte chiffré, mais ne conserve pas nécessairement l’historique des modifications et suppressions.
• Selon la documentation technique de Livara, AES-256-GCM protège les messages privés avec une étiquette d’authentification ; un paquet altéré ne devrait pas être déchiffré comme valide.
• Une modification autorisée doit être un nouvel événement chiffré de bout en bout, pas une réécriture secrète du paquet précédent par le serveur.
• Les numéros de sécurité aident à vérifier la clé de l’interlocuteur, pas son honnêteté ni la valeur juridique d’une capture d’écran.
• En cas de litige sensible, conservez aussi hors du fil les fichiers originaux, les horaires, l’état des modifications et des preuves indépendantes.

Qu’est-ce exactement que l’intégrité des messages ?

L’intégrité permet au destinataire de détecter une modification non autorisée des données chiffrées. La confidentialité demande « Qui peut lire le texte ? » ; l’intégrité demande « Les données reçues sont-elles celles que l’expéditeur a chiffrées ? ». L’explication du chiffrement de bout en bout et de ses limites développe cette distinction.

Illustration conceptuelle avec des libellés d’exemple : ce n’est ni l’interface réelle de Livara ni le résultat d’un test de rejet d’un message altéré.

Selon les documents techniques de Livara, les messages directs utilisent LVR1 et les groupes privés compatibles LGS1 pour le chiffrement de bout en bout. La page de sécurité de Livara indique que les anciens groupes incompatibles restent explicitement hors E2EE et qu’un nouveau groupe n’est pas créé avec le libellé chiffré tant que tous les membres ne sont pas prêts. Vérifiez l’état de la conversation concernée. Ces documents indiquent que LVR1 emploie ECDH P-256 et ML-KEM-768 pour dériver les clés des messages. Un composant standardisé ne constitue pas une approbation indépendante de toute la combinaison ou du produit. Livara utilise ensuite AES-256-GCM pour protéger le contenu.

D’après la documentation du produit, cette protection couvre les textes, modifications et pièces jointes des conversations privées. En revanche, les canaux Livara ne sont pas chiffrés de bout en bout : le serveur peut délibérément lire leur contenu, notamment pour supprimer les contenus abusifs. L’appartenance aux groupes est également contrôlée par le serveur. La sécurité des appels et le mode d’enregistrement doivent être évalués séparément des messages texte.

Détection des altérations et chiffrement AES-256-GCM en messagerie

Outre le chiffrement du contenu, AES-GCM produit une étiquette d’authentification. Si le texte chiffré ou les données authentifiées changent, la vérification doit échouer. NIST SP 800-38D définit GCM et avertit que réutiliser un nonce avec la même clé peut gravement affaiblir la sécurité.

Les spécifications techniques de Livara indiquent que les messages privés utilisent AES-256-GCM. Si le serveur modifie une partie du paquet protégé, il ne peut pas créer une nouvelle étiquette sans la clé du message ; le destinataire ne devrait donc pas accepter ce paquet comme intact. La réponse courte à « Le serveur peut-il modifier un message ? » est : il peut supprimer, retenir, bloquer ou retarder des données, mais ne devrait pas pouvoir faire passer un contenu altéré pour valide.

Cette garantie n’est pas illimitée. La cryptographie ne neutralise ni un logiciel malveillant sur l’appareil, ni l’accès d’un attaquant à un écran déverrouillé, ni une modification autorisée de l’utilisateur. L’intégrité du contenu ne masque pas nécessairement les métadonnées. Le guide des métadonnées de messagerie et de ce qu’elles révèlent explique cette limite.

Le serveur peut-il modifier un message, ou l’édition est-elle différente ?

Le serveur ne devrait pas pouvoir réécrire secrètement le paquet chiffré précédent, mais il peut livrer un événement de modification créé par l’expéditeur. La sécurité des modifications de messages dépend de leur authentification et de leur chiffrement de bout en bout, comme le message initial, et non d’un changement direct du texte stocké par le serveur.

Selon Livara, les modifications sont protégées par LVR1 dans les chats directs et par LGS1 dans les groupes privés compatibles. Pour évaluer l’interface, vérifiez si l’application affiche « modifié » ; la cryptographie seule ne conserve toutefois pas éternellement la version précédente sur tous les appareils.

« Supprimer pour tout le monde » est également une demande d’abandonner le contenu, pas une preuve que toutes ses copies ont été détruites. Le destinataire peut avoir vu le message, lu la notification, enregistré le fichier ou fait une capture d’écran. Les messages éphémères réduisent la persistance, mais ne garantissent pas la suppression de toutes les copies.

Que prouve l’authentification d’un message de chat ?

L’authentification d’un message de chat indique qu’il a été créé avec les clés de session et n’a pas été altéré en transit. Elle ne prouve pas que le titulaire du compte tenait personnellement l’appareil, que le texte est vrai ou que le destinataire pourra ensuite le prouver de façon concluante à un tiers.

Livara présente les numéros de sécurité comme un moyen de détecter un changement de clé. Deux personnes peuvent comparer les empreintes des clés par un canal indépendant ; le guide de vérification des chats avec les numéros de sécurité décrit les étapes pratiques. Cette vérification réduit le risque de substitution de la clé du contact par celle d’un attaquant, mais ne sécurise pas un appareil infecté.

L’authentification du compte constitue aussi une question distincte. Aucun mécanisme de connexion, aussi robuste soit-il, ne remplace l’intégrité des messages, la vérification de la clé du contact ou la sécurité de l’appareil.

L’intégrité du contenu n’est ni l’ordre ni la fraîcheur des messages

Un ancien paquet peut porter une étiquette d’authentification valide. Empêcher sa nouvelle acceptation nécessite une conception de protocole, des compteurs, des identifiants de session et la conservation de l’état du destinataire ; AES-GCM seul n’est pas un registre de l’ordre de toute la conversation. Cette distinction importe pour évaluer le rejeu, les messages tardifs et la synchronisation multiappareil.

Il faut aussi préciser quelles données sont réellement couvertes par l’étiquette. Si l’identifiant de conversation ou le type d’événement se trouve hors du contexte authentifié, protéger uniquement le corps ne résout pas tout le problème. L’examen du code et les tests de cette version précise doivent clarifier cette liaison.

Si le texte ou l’état d’un message est inattendu

Notez la version de l’application, l’heure d’observation, les appareils concernés et la présence d’un libellé de modification. Vérifiez auprès du contact, par une voie indépendante, s’il a effectué une modification autorisée. N’attribuez pas sans preuves un écart de synchronisation à une altération par le serveur ; mais n’écartez pas non plus sans raison les erreurs d’authentification ou changements de clé.

Pour un rapport technique, utilisez un message de test non sensible et ne publiez pas les données privées du contact. Si la conversation doit servir dans une affaire juridique, la cryptographie ou une capture d’écran ne détermine pas à elle seule sa validité légale ; consultez un professionnel qualifié avant de modifier les preuves.

Comment évaluer les promesses d’intégrité d’une messagerie ?

Ne vous contentez pas de « chiffré ». Demandez :

• Quelles conversations et quels fichiers sont chiffrés de bout en bout ?
• Quel algorithme AEAD le service utilise-t-il ?
• Comment les modifications et suppressions sont-elles consignées et affichées ?
• Comment l’utilisateur détecte-t-il un changement de clé du contact ?
• Quelles métadonnées, quels contenus ou quelles appartenances le serveur contrôle-t-il ?
• Les appels bénéficient-ils des mêmes garanties que les messages ?
• Le protocole a-t-il fait l’objet d’un audit indépendant ?

Livara publie des spécifications et des outils permettant de vérifier certaines de ses affirmations. Les utilisateurs Android peuvent comparer la somme de contrôle du fichier APK avec SHA-256 dans le Proof Lab pour vérifier l’application hors ligne. Cet article ne fournit toutefois aucune preuve d’un audit indépendant de la version actuelle. Publier des spécifications et des vecteurs de test aide à l’examen, sans remplacer un audit indépendant.

Pour les conversations privées, l’affirmation principale de Livara est limitée et claire : AES-256-GCM doit détecter l’altération du paquet, et les modifications doivent aussi être chiffrées. Cela ne signifie ni registre immuable, ni suppression certaine de toutes les copies, ni preuve juridique automatique.

Questions fréquentes

Un administrateur serveur peut-il modifier le texte d’un message chiffré ?

Avec une conception AES-256-GCM correcte, l’administrateur sans la clé du message ne peut pas modifier le texte chiffré et produire une étiquette valide. Il peut toujours supprimer, bloquer ou retarder le paquet. Cette garantie ne couvre ni un appareil infecté ni une modification autorisée par l’expéditeur.

Le libellé « modifié » prouve-t-il ce que contenait la version précédente ?

Non. Il indique seulement que le contenu affiché a changé après l’envoi, sauf si l’application conserve aussi un historique des versions. Le chiffrement peut authentifier l’événement de modification, mais ne préserve pas automatiquement l’ancien texte.

Un numéro de sécurité garantit-il l’authenticité de tous les messages ?

Non. Il aide à vérifier que la clé de chiffrement appartient au contact et à détecter ses changements. Il n’indique ni qui tenait l’appareil lors de l’envoi, ni si le message est vrai, ni si l’appareil est exempt de logiciels malveillants.

Supprimer pour tout le monde efface-t-il le message partout ?

Non. La fonction peut abandonner la copie dans l’application, mais ne récupère pas les fichiers enregistrés, notifications, captures d’écran ou enregistrements antérieurs. Elle réduit la persistance ; elle ne garantit pas l’effacement de l’appareil du destinataire ou d’autres systèmes.