Chiffrement de bout en bout (E2EE)

Qu'est-ce que le chiffrement de bout en bout (E2EE) ?

Le chiffrement de bout en bout (E2EE) signifie que les données sont chiffrées sur l'appareil de l'expéditeur et déchiffrées uniquement sur celui du destinataire. Le service intermédiaire, par exemple un serveur de messagerie, ne manipule que du texte chiffré, car il ne détient jamais les clés. L'Electronic Frontier Foundation le décrit ainsi : un message est transformé en message secret par son expéditeur d'origine et n'est décodé que par son destinataire final.

Comment fonctionne l'E2EE

• L'appareil de chaque utilisateur génère une paire de clés. La clé publique est partagée via le service, la clé privée ne quitte jamais l'appareil.
• L'expéditeur chiffre avec des clés dérivées du matériel de clé publique du destinataire et envoie le texte chiffré par le serveur.
• Le serveur stocke et transmet le texte chiffré sans pouvoir le lire.
• L'appareil du destinataire le déchiffre avec sa clé privée.

Les messageries modernes ajoutent un mécanisme de renouvellement des clés. L'algorithme Double Ratchet de Signal donne à chaque message sa propre clé : une fuite ultérieure n'expose pas les messages passés (confidentialité persistante, ou forward secrecy), et de nouveaux échanges Diffie-Hellman permettent à la conversation de se rétablir après une compromission brève. Le Double Ratchet a besoin d'un protocole distinct, comme PQXDH, pour convenir du premier secret partagé. Pour les groupes, l'IETF a normalisé Messaging Layer Security dans la RFC 9420, qui prend en charge des groupes de deux à des milliers de membres et offre la forward secrecy et la sécurité après compromission.

E2EE face au chiffrement en transit et au repos

TLS, le protocole derrière HTTPS, protège les données entre un client et un serveur pour que seuls ces deux points d'extrémité puissent les lire (RFC 8446). C'est le chiffrement en transit, mais le serveur voit le texte en clair. Le chiffrement au repos protège les données stockées, mais le service détient généralement les clés. Avec l'E2EE, le service n'a jamais les clés : même son personnel, ou un attaquant qui pénètre ses serveurs, ne peut pas lire le contenu des messages. Si un serveur peut déchiffrer une grande partie des messages, le système n'est pas chiffré de bout en bout. La plupart des produits E2EE utilisent aussi TLS, car les deux répondent à des menaces différentes.

Exemple

Vous envoyez une photo dans une messagerie. Votre téléphone la chiffre, l'application envoie le fichier chiffré et le serveur le remet à votre ami. Son téléphone le déchiffre et l'affiche. Le serveur a vu un bloc d'octets, sa taille et l'heure d'arrivée.

Ce que l'E2EE ne protège pas

• Un appareil compromis. Un logiciel malveillant sur le téléphone de l'expéditeur ou du destinataire voit le message après déchiffrement.
• Les métadonnées. Qui parle à qui et quand reste souvent visible pour le service, comme une enveloppe montre expéditeur, destinataire et destination même quand la lettre est scellée (une analogie du guide de l'EFF sur les métadonnées).
• Les sauvegardes. Si une conversation est sauvegardée sans chiffrement ou avec une clé que détient le fournisseur, la protection s'arrête là.
• Les personnes. Un destinataire peut copier ou capturer ce que vous envoyez, et un utilisateur peut être amené à faire confiance à une mauvaise clé.

Il ne remplace pas non plus le reste du travail de sécurité. Les comptes, les sessions et la confiance dans les appareils demandent toujours une gestion des identités et des accès (IAM), les API qui transportent le texte chiffré demandent la sécurité des API et les métadonnées stockées demandent la sécurité des bases de données. Voyez aussi les menaces de cybersécurité courantes que l'E2EE n'arrête pas.

Erreurs courantes

• Appeler HTTPS du chiffrement de bout en bout. HTTPS s'arrête au serveur.
• Laisser le serveur voir les clés. Un séquestre de clés ou une copie de « récupération » côté serveur peut transformer l'E2EE en chiffrement ordinaire sans que cela se voie.
• Ignorer la vérification des clés. Sans moyen de comparer numéros de sécurité ou empreintes, un serveur pourrait substituer une clé et s'interposer.
• Écrire sa propre cryptographie. Utilisez un protocole et une bibliothèque éprouvés.

E2EE, tests de charge et surveillance

LoadFocus ne propose pas de produits de chiffrement, et un test de charge ne peut pas lire un contenu E2EE, c'est précisément le but. Il peut en revanche tester le backend qui le transporte. Le serveur doit toujours accepter l'envoi de texte chiffré, distribuer les clés publiques, stocker les messages et les remettre vite à de nombreux appareils à la fois. Utilisez les tests de charge avec des comptes de test synthétiques et des charges opaques de taille réaliste pour voir comment ces points d'accès se comportent quand les utilisateurs virtuels augmentent, et la surveillance d'API pour les contrôler selon un calendrier. N'utilisez jamais de vraies données d'utilisateurs. Pour aller plus loin, lisez l'article (en anglais) Cloud testing security best practices.

Questions fréquentes sur le chiffrement de bout en bout

Le chiffrement de bout en bout est-il la même chose que HTTPS ?

Non. HTTPS (TLS) protège la connexion entre votre appareil et un serveur, mais le serveur peut lire les données. Le chiffrement de bout en bout les rend illisibles aussi pour le serveur.

L'entreprise qui exploite le service peut-elle lire mes messages E2EE ?

Pas le contenu, si le système est réellement chiffré de bout en bout, car elle ne détient pas les clés de déchiffrement. Elle peut en revanche voir des métadonnées, comme qui a contacté qui et quand.

Qu'est-ce que la forward secrecy ?

Une clé divulguée plus tard ne peut pas déchiffrer les messages passés. Le Double Ratchet de Signal donne pour cela une clé propre à chaque message.

L'E2EE fonctionne-t-il pour les conversations de groupe ?

Oui. Messaging Layer Security (RFC 9420) est une norme de l'IETF pour l'accord de clés de groupe et prend en charge des groupes de deux à des milliers de membres.

Le chiffrement de bout en bout rend-il une application invulnérable ?

Non. Il protège le contenu des messages en transit et sur le serveur, mais pas contre un appareil compromis, des sauvegardes non chiffrées ou une sécurité de compte faible.