Le chiffrement de bout en bout protège les contenus pris en charge entre les appareils ; il ne rend ni ces appareils ni leurs utilisateurs infaillibles.
Le chiffrement de bout en bout (E2EE) protège le contenu des messages pris en charge : ce sont les appareils participants, et non le service qui les achemine, qui détiennent les moyens de le lire. Il ne masque pas automatiquement l’identité des personnes qui communiquent, ne sécurise pas un téléphone infecté et n’empêche pas le destinataire de copier un message.
Ce guide suit le parcours d’un message de son expéditeur à son destinataire, compare l’E2EE à HTTPS et présente les vérifications pratiques qui permettent d’évaluer les affirmations d’une messagerie sur son chiffrement.
Qu’est-ce que le chiffrement de bout en bout ?
Le chiffrement de bout en bout protège les informations en les chiffrant sur l’appareil de l’expéditeur et en ne les déchiffrant que sur un appareil participant du destinataire.
Dans une conversation E2EE correctement conçue, le message ne quitte pas l’appareil de départ sous forme de texte en clair. Il en sort sous forme chiffrée : des données qui devraient être inutilisables sans la bonne clé cryptographique.
Le service de messagerie peut contribuer à acheminer et à synchroniser ces données chiffrées sans avoir besoin de lire le contenu protégé. Selon le protocole, le même principe peut s’appliquer aux échanges individuels ou aux groupes.
Les « bouts » sont les appareils participants, pas nécessairement deux téléphones seulement. Un groupe ou l’ordinateur portable associé au compte d’une personne peut ajouter d’autres appareils autorisés.
C’est la différence essentielle entre le chiffrement de bout en bout et le simple chiffrement du transport.
Comment fonctionne l’E2EE ?
Les mathématiques peuvent être complexes, mais le parcours général d’un message reste compréhensible.
1. Chaque participant possède des clés cryptographiques
Une application de messagerie sécurisée crée ou conserve les éléments cryptographiques nécessaires sur l’appareil de l’utilisateur.
Certaines clés peuvent être diffusées publiquement. Les clés privées doivent rester protégées, car elles aident l’appareil à établir ou à retrouver les informations secrètes nécessaires au déchiffrement des messages.
2. Les appareils établissent des secrets partagés
Les participants échangent les informations publiques nécessaires pour dériver des secrets correspondants.
Le secret lui-même ne devrait pas avoir besoin d’être transmis sous une forme lisible. Chaque appareil effectue indépendamment les opérations cryptographiques nécessaires.
3. Le message est chiffré localement
Lorsque l’expéditeur appuie sur Envoyer, l’application chiffre le message sur son appareil.
La phrase lisible devient un contenu chiffré avant d’être envoyée vers le serveur ou relayée.
4. Le serveur achemine le contenu chiffré
L’infrastructure de messagerie dirige le message chiffré vers son destinataire. Elle peut conserver des données chiffrées pour assurer la synchronisation, la livraison et l’utilisation de plusieurs appareils autorisés.
Le serveur continue d’accomplir des tâches importantes pour le fonctionnement du service. L’E2EE change la forme du contenu des messages qu’il traite.
5. Le destinataire le déchiffre
Un appareil autorisé du destinataire utilise ses éléments cryptographiques pour authentifier et déchiffrer le contenu chiffré.
Le message lisible apparaît sur les appareils autorisés. L’historique local, les notifications, les sauvegardes et les exports ont alors besoin de leurs propres protections.
Que protège le chiffrement de bout en bout ?
L’E2EE vise avant tout à protéger le contenu d’une conversation.
Selon l’application et sa mise en œuvre, ce contenu peut comprendre :
- Les messages texte directs
- Les photos et les vidéos
- Les messages vocaux
- Les documents et les pièces jointes
- Les appels audio ou vidéo
- Les modifications de messages et les réponses
Lorsque ce contenu est correctement chiffré par l’application cliente, un attaquant qui intercepte le trafic réseau devrait voir des données chiffrées plutôt que le message d’origine.
Cela réduit aussi la quantité de contenu lisible des conversations accessible à l’infrastructure du service.
Le mot « chiffré » ne suffit toutefois pas à tout expliquer. Les utilisateurs doivent pouvoir savoir précisément quels types de conversations et quels circuits de traitement du contenu sont couverts.
Ce que l’E2EE ne protège pas automatiquement
Le chiffrement de bout en bout est une protection importante, mais ses limites sont souvent mal comprises.
Les métadonnées des messages
Un système peut avoir besoin d’informations de fonctionnement pour acheminer et synchroniser les messages.
Selon le service, il peut s’agir notamment :
- Du compte qui a envoyé le message
- De la conversation qui l’a reçu
- De l’heure d’envoi
- De l’état de livraison et de lecture
- Des membres de la conversation
- De la taille du message chiffré
- D’informations sur l’appareil ou la session
Le corps du message peut être illisible alors que certaines informations qui l’entourent restent accessibles au système.
C’est pourquoi « le contenu des messages est chiffré » et « le service ne collecte aucune métadonnée » sont deux affirmations distinctes.
Un appareil compromis
Le chiffrement de bout en bout ne protège pas le texte en clair contre un logiciel malveillant ou un autre attaquant disposant d’un accès suffisant à l’appareil. Cet accès n’exige pas nécessairement que l’écran soit déverrouillé : un écran verrouillé ne prouve pas, à lui seul, qu’un système d’exploitation compromis ne peut pas accéder aux données des messages.
Le message doit finir par devenir lisible sur un appareil autorisé. Un attaquant ayant accès aux données déchiffrées de l’application, à sa mémoire ou à l’affichage peut être en mesure de récupérer ce contenu. L’exposition exacte dépend de l’appareil, des logiciels et de la nature de la compromission.
La sécurité des appareils reste essentielle :
- Installez les mises à jour du système d’exploitation
- Utilisez un code de verrouillage robuste
- Examinez les extensions du navigateur
- Protégez les informations de récupération du compte
- Évitez les applications et les téléchargements d’origine inconnue
Les actions du destinataire
L’E2EE ne peut pas empêcher un participant de copier, de transférer ou de photographier un message, ni d’en faire une capture d’écran après son déchiffrement.
Le chiffrement protège l’acheminement entre les appareils. Il ne contrôle pas la personne qui se trouve à l’autre bout.
Les erreurs de récupération de compte
Les mécanismes de récupération doivent concilier sécurité et facilité d’utilisation.
Une procédure de récupération fragile peut compromettre un chiffrement robuste. À l’inverse, un système qui ne permet jamais de récupération peut rendre l’historique chiffré définitivement inaccessible en cas de perte d’une clé.
Une application digne de confiance devrait expliquer le fonctionnement de la récupération, les informations sauvegardées et les conséquences de la perte des éléments nécessaires à la récupération.
L’E2EE et TLS ne sont pas équivalents
La plupart des sites modernes utilisent HTTPS et TLS pour protéger le trafic entre un navigateur et un serveur.
Cette protection est importante. Elle contribue à empêcher des personnes présentes sur le même réseau, ou ailleurs sur le trajet, de lire ou de modifier facilement la connexion.
TLS protège la connexion entre ses propres extrémités. Pour une messagerie web classique, l’une de ces extrémités est le service. Celui-ci peut lire les données de l’application, sauf si une couche distincte de chiffrement du contenu les protège. La spécification TLS décrit la protection de cette connexion contre l’écoute, l’altération et la falsification.
Dans une messagerie classique dont le serveur peut lire les messages :
- Votre appareil chiffre la connexion réseau.
- Le serveur reçoit et traite le contenu lisible des messages.
- Le serveur établit une autre connexion protégée avec le destinataire.
Avec le chiffrement de bout en bout, le message lui-même est chiffré à l’intention des participants avant d’être placé dans la connexion réseau protégée.
Voici une comparaison simple :
| Protection | Messagerie protégée uniquement par TLS | Chiffrement de bout en bout |
|---|---|---|
| Protège les données pendant leur transport sur le réseau | Oui | Oui |
| Protection avant la traversée du réseau | Oui, pour cette connexion TLS | Oui, pour les appareils destinataires de la messagerie |
| Le service d’acheminement peut lire le contenu protégé des messages | Généralement, en l’absence de chiffrement supplémentaire du contenu | Pas à partir des seules données chiffrées, selon le fonctionnement prévu des clés |
| La sécurité des appareils reste nécessaire | Oui | Oui |
| Les métadonnées sont automatiquement masquées | Non | Non |
TLS et l’E2EE ne sont pas concurrents. Une messagerie privée a généralement besoin d’un transport sécurisé et d’un chiffrement du contenu correctement mis en œuvre.
Comment cette définition s’applique à Livara
Selon sa documentation de sécurité, Livara utilise l’accord de clés hybride LVR1, qui associe P-256 et ML-KEM-768, pour les communications directes. Les groupes privés compatibles utilisent des clés d’expéditeur LGS1, distribuées au moyen de sessions entre paires de participants. Les canaux publics sont lisibles par le serveur et ne doivent pas être présentés comme chiffrés de bout en bout.
Cette distinction concerne le mode de communication effectivement utilisé, pas le nom de la marque. La documentation décrit séparément le chiffrement des appels, y compris un mode d’enregistrement visible dont le périmètre de confiance est différent. Vérifiez l’état actuel de la conversation et de l’appel, au lieu de supposer que toutes les fonctions bénéficient de la même protection.
Il s’agit d’affirmations documentées par le produit, pas d’un audit indépendant réalisé pour cet article. Les métadonnées de fonctionnement et les appareils compromis restent des limites importantes. L’accord de clés post-quantique répond à une catégorie de risques cryptographiques ; il ne rend pas inoffensifs l’hameçonnage, les sauvegardes non sécurisées ou un écran déverrouillé.
Pourquoi les empreintes des clés publiques comptent
Une conversation chiffrée doit utiliser la clé de la personne attendue, et pas simplement n’importe quelle clé présentée par le système.
L’empreinte d’une clé publique est une représentation compacte de cette clé. Deux personnes peuvent comparer leurs empreintes par un autre canal de confiance, par exemple en personne ou lors d’un appel dont elles ont vérifié l’interlocuteur.
Des empreintes identiques renforcent la confiance dans l’utilisation des clés attendues.
Un changement d’empreinte ne prouve pas automatiquement une attaque. Il peut survenir après une réinitialisation légitime des clés ou une récupération sur un appareil. Ce changement devrait toutefois être visible et explicable, et non ignoré silencieusement.
Les sauvegardes et la récupération sont distinctes du chiffrement des échanges
Une application peut chiffrer les messages de bout en bout pendant les échanges, tandis qu’une sauvegarde séparée utilise d’autres clés et d’autres règles d’accès. Un export en clair peut également faire sortir du contenu lisible de la conversation chiffrée. Demandez ce qui est sauvegardé, qui peut le déchiffrer et ce qui se passe en cas de perte des éléments de récupération.
La sauvegarde de récupération décrite par Livara est chiffrée avant son envoi et restaure des éléments d’identité, pas l’historique des discussions. Ne supposez pas que la récupération d’un compte ou d’une identité rétablit toutes les anciennes conversations. Pour évaluer une sauvegarde de conversations chiffrées, examinez donc séparément ses clés, ses règles d’accès et sa procédure de restauration.
Comment évaluer une application de messagerie privée
Ne jugez pas un service de messagerie sur les seuls mots « chiffré » ou « sécurisé ».
Posez des questions précises.
Quelles conversations sont chiffrées de bout en bout ?
Vérifiez si la protection couvre les discussions individuelles, les groupes, les canaux, les appels et les pièces jointes.
Où les clés sont-elles créées et stockées ?
Cherchez une explication claire de la création des clés sur l’appareil et de la protection des sauvegardes.
Que conserve le serveur ?
Un service responsable devrait distinguer le contenu des messages des informations d’acheminement, des horodatages, des membres, des données de livraison et des autres données de fonctionnement.
Que se passe-t-il lorsque les clés changent ?
Un remplacement inattendu de clé devrait être visible. Des changements silencieux réduisent la capacité de l’utilisateur à vérifier ses contacts.
Comment fonctionne la récupération ?
Déterminez si le fournisseur peut restaurer les clés, si un secret de récupération est nécessaire et ce qui arrive lorsque ce secret est perdu.
Les affirmations sont-elles vérifiées indépendamment ?
La documentation de sécurité, les protocoles ouverts, les analyses professionnelles et les audits indépendants offrent des niveaux d’assurance différents.
Un discours commercial n’est pas un audit.
La confidentialité repose sur des limites clairement définies
L’affirmation la plus solide en matière de confidentialité ne se résume pas à « faites-nous confiance ».
Elle explique de manière précise et vérifiable :
- Ce qui est chiffré
- Où le chiffrement a lieu
- Quelles clés sont utilisées
- Ce que le serveur reçoit
- Quelles métadonnées subsistent
- Quels types de conversations sont exclus
- Comment la récupération modifie le modèle de menace
Le chiffrement de bout en bout ne couvre pas tous les aspects de la confidentialité. Mais, lorsqu’il est mis en œuvre avec soin et décrit honnêtement, il constitue une base essentielle pour les communications privées.
Pour passer à la pratique, appliquez les questions ci-dessus aux fonctions que vous utilisez réellement : discussions privées, groupes, pièces jointes, appels et sauvegardes.
Questions fréquentes
Que signifie E2EE ?
E2EE est l’abréviation anglaise de « end-to-end encryption », soit le chiffrement de bout en bout. Le contenu protégé est chiffré sur un appareil participant et déchiffré sur un autre appareil autorisé.
Un fournisseur d’accès à Internet peut-il lire les messages E2EE ?
Un fournisseur d’accès peut parfois constater l’existence d’une connexion et observer certaines informations réseau. Le contenu des messages correctement chiffrés ne devrait toutefois pas apparaître sous forme de texte en clair pendant le transport.
Le chiffrement de bout en bout masque-t-il les métadonnées ?
Pas automatiquement. Une messagerie peut encore traiter des informations d’acheminement, de membres, d’horodatage, de livraison, de taille des données chiffrées ou d’autres informations nécessaires au fonctionnement du service.
L’E2EE protège-t-il un téléphone volé dont l’écran est déverrouillé ?
Aucun protocole de chiffrement ne peut protéger entièrement un message lorsqu’un attaquant contrôle un appareil déjà autorisé et déverrouillé. Une sécurité robuste des appareils reste nécessaire.
Toutes les conversations Livara sont-elles chiffrées de bout en bout ?
Livara décrit actuellement l’E2EE pour le corps des messages et les médias des échanges directs individuels, ainsi que pour les groupes privés compatibles. Ces groupes utilisent le chiffrement de bout en bout LGS1, avec rotation automatique des clés d’expéditeur lors des changements de membres. Les canaux utilisent TLS et des autorisations authentifiées côté serveur ; ils ne sont pas présentés comme chiffrés de bout en bout.
Peut-on récupérer une clé de chiffrement Livara perdue ?
La documentation publique décrit la restauration d’éléments d’identité sauvegardés à l’aide du secret de récupération requis. Cela ne restaure pas l’historique des discussions. Consultez la procédure de récupération actuelle avant de supprimer ou de remplacer l’appareil d’origine.
L’E2EE est-il équivalent à la confidentialité persistante ?
Non. L’E2EE définit qui devrait pouvoir lire le contenu protégé. La confidentialité persistante concerne les effets d’une compromission ultérieure des clés sur les messages antérieurs. La sécurité après compromission concerne le rétablissement de la protection après une compromission, sous certaines conditions. Ces propriétés dépendent du protocole et de sa mise en œuvre. La spécification MLS, par exemple, définit explicitement les deux pour son mécanisme de clés de groupe. Cela ne signifie pas que toute messagerie chiffrée les possède automatiquement ou utilise MLS.
