Chiffrement de bout en bout (E2EE) : fonctionnement, vérification et limites
Le chiffrement de bout en bout chiffre un message sur l’appareil de l’expéditeur et ne le déchiffre que sur celui du destinataire : le serveur qui le relaie, l’opérateur et tout intermédiaire n’en voient que des octets illisibles. Il se distingue du simple chiffrement en transit (HTTPS), où le serveur lit le contenu en clair, et il ne couvre ni les métadonnées, ni les sauvegardes non chiffrées, ni un téléphone compromis.
Ce que « de bout en bout » change par rapport au cadenas HTTPS
Un message chiffré de bout en bout est chiffré sur l’appareil de l’expéditeur et déchiffré uniquement sur celui du destinataire. Entre les deux, le serveur de la messagerie relaie des octets qu’il ne sait pas lire, faute d’en détenir la clé. C’est toute la différence avec HTTPS : avec TLS (RFC 8446 pour la version 1.3), le tunnel est chiffré entre votre navigateur et le serveur, puis le serveur déchiffre, stocke, indexe, et rechiffre vers le destinataire. Un webmail classique voit donc chaque message en clair, même si le cadenas est affiché.
Trois niveaux de chiffrement coexistent souvent dans un même service, et les confondre mène à de fausses garanties.
La conséquence pratique se voit dans les incidents. En août 2022, l’attaque contre Twilio, prestataire d’envoi de SMS de Signal, a exposé les numéros de téléphone d’environ 1 900 utilisateurs et permis de tenter des réenregistrements de comptes. Aucun message, aucun contact, aucun historique n’a fuité : le serveur ne les possédait pas.
| Niveau | Qui peut lire le contenu en clair | Exemple |
|---|---|---|
| En transit (TLS) | Le client et le serveur | HTTPS, un webmail, une API REST |
| Au repos | L’opérateur qui détient la clé du stockage | Disque ou base de données chiffrés côté serveur |
| De bout en bout | Uniquement les correspondants | Signal, WhatsApp, un e-mail OpenPGP |
Échanger des clés sans jamais faire confiance au serveur
Le problème à résoudre : deux personnes qui ne se sont jamais parlé doivent partager un secret, souvent alors que l’une des deux est hors ligne. Le protocole Signal, repris par WhatsApp depuis avril 2016, par Google Messages pour le RCS et par Matrix sous le nom d’Olm, le règle en deux étapes.
Première étape, X3DH (Extended Triple Diffie-Hellman). Chaque appareil publie sur le serveur une clé d’identité, une clé signée renouvelée périodiquement et un lot de clés à usage unique, toutes sur Curve25519. Pour écrire à quelqu’un d’absent, on télécharge ce paquet, on calcule plusieurs échanges Diffie-Hellman croisés et on en dérive un secret partagé. Le serveur distribue les clés publiques mais ne peut rien en déduire.
Deuxième étape, le Double Ratchet. Chaque message reçoit sa propre clé AES-256, dérivée par HMAC-SHA256 d’une chaîne qui avance à sens unique, et un nouvel échange Diffie-Hellman est glissé dans chaque aller-retour. Résultat : voler la clé d’un message ne permet pas de lire les précédents (confidentialité persistante), ni les suivants une fois l’échange relancé. Depuis septembre 2023, Signal ajoute un échange post-quantique ML-KEM à la poignée de main initiale (PQXDH) ; Apple a fait de même pour iMessage avec PQ3 dans iOS 17.4.
Pour un e-mail, le mécanisme est plus ancien et plus rustique : OpenPGP (RFC 4880, révisée par la RFC 9580 en 2024) ou S/MIME (RFC 8551). Une commande suffit à chiffrer un fichier pour un correspondant dont on possède la clé publique : gpg --encrypt --sign --recipient alice@example.org rapport.pdf. Le résultat, rapport.pdf.gpg, peut transiter par n’importe quel serveur.
Vérifier que l’on parle bien à la bonne personne
Le maillon faible n’est pas le chiffrement, c’est l’annuaire. Puisque le serveur distribue les clés publiques, un opérateur malveillant ou compromis peut remplacer la clé de votre correspondant par la sienne, déchiffrer, relire, rechiffrer : une attaque de l’homme du milieu classique, invisible côté utilisateur tant que personne ne compare les clés.
C’est le rôle des « numéros de sécurité » de Signal et du « code de sécurité » de WhatsApp : 60 chiffres, ou un QR code, calculés à partir des clés d’identité des deux appareils. Si le code affiché chez vous correspond à celui affiché chez l’autre, lu de vive voix ou scanné en face à face, aucune clé n’a été substituée. Un changement de code en cours de conversation signale un nouveau téléphone, une réinstallation, ou un problème. La question mérite d’être posée avant d’envoyer quoi que ce soit de sensible.
Côté e-mail, l’équivalent est l’empreinte de la clé, 40 caractères hexadécimaux pour une clé OpenPGP v4 (gpg --fingerprint), à comparer par un autre canal que celui qui a servi à transmettre la clé.
Ce que le chiffrement de bout en bout ne protège pas
La garantie porte sur le contenu, en transit et sur le serveur. Tout le reste est en dehors du périmètre, et c’est là que se produisent la plupart des compromissions réelles.
Cela n’enlève rien à l’intérêt de la mesure. En décembre 2024, après l’intrusion du groupe Salt Typhoon dans les réseaux de plusieurs opérateurs télécoms américains, la CISA et le FBI ont recommandé publiquement de passer par des messageries chiffrées de bout en bout plutôt que par les SMS et les appels classiques, que les attaquants pouvaient intercepter chez l’opérateur.
- Les métadonnées : qui écrit à qui, quand, depuis quelle adresse IP, à quelle fréquence. WhatsApp les conserve et les transmet sur réquisition ; Signal a conçu son service pour n’en garder presque aucune (date de création du compte et de dernière connexion).
- Les terminaux : un logiciel espion comme Pegasus lit les messages après déchiffrement, à l’écran ou en mémoire. Le chiffrement n’y peut rien.
- Les sauvegardes : une sauvegarde WhatsApp sur Google Drive ou iCloud n’est chiffrée de bout en bout que si l’option est activée (disponible depuis fin 2021). Sur iPhone, la sauvegarde iCloud des messages reste lisible par Apple sans la « protection avancée des données ».
- Le correspondant lui-même : capture d’écran, transfert, appareil partagé ou déverrouillé.
- Les fonctions serveur : recherche dans les messages, aperçus de liens, modération automatique du contenu. Si le service propose ces fonctions sur le texte des messages, c’est qu’il le lit quelque part.
Qui le fait vraiment, et qui le fait à moitié
L’expression est devenue un argument marketing, il faut lire les conditions. Le tableau ci-dessous résume l’état des services les plus utilisés ; en cas de doute, cherchez le livre blanc technique du protocole, ou constatez son absence.
Un piège fréquent avec Telegram : les discussions ordinaires, les groupes et les canaux sont chiffrés entre le client et les serveurs de Telegram, qui détiennent les clés. Seuls les « échanges secrets », à activer à la main, limités à deux personnes et liés à un seul appareil, sont chiffrés de bout en bout.
| Service | Bout en bout | Remarque |
|---|---|---|
| Signal | Oui, par défaut, pour tout | Protocole documenté, code source publié |
| Oui par défaut pour les messages et appels | Sauvegardes chiffrées uniquement si l’option est activée ; métadonnées conservées | |
| iMessage | Oui entre appareils Apple | Le repli SMS (bulle verte) circule en clair ; sauvegarde iCloud lisible par Apple sans la protection avancée |
| Telegram | Non par défaut | Seuls les échanges secrets à deux le sont ; ni les groupes ni les canaux |
| Zoom | Optionnel, depuis octobre 2020 | Désactive l’enregistrement dans le cloud et la transcription en direct |
| Gmail, Outlook web | Non | TLS jusqu’au serveur seulement ; OpenPGP ou S/MIME à ajouter côté client |
Testez vos connaissances
Dans un service chiffré de bout en bout, qui peut lire le contenu d’un message ?
Score : 0 sur 3
Questions fréquentes
Le cadenas dans le navigateur signifie-t-il que mes messages sont chiffrés de bout en bout ?
Non. Le cadenas atteste d’un tunnel TLS entre votre navigateur et le serveur du service. Le serveur déchiffre ensuite tout ce qu’il reçoit. Un webmail en HTTPS lit vos e-mails ; une messagerie de bout en bout ne le peut pas, cadenas ou non.
Peut-on chiffrer un e-mail de bout en bout ?
Oui, avec OpenPGP ou S/MIME, à condition que le destinataire ait une clé et un client compatible (Thunderbird intègre OpenPGP depuis la version 78). Seuls le corps et les pièces jointes sont chiffrés : l’objet, l’expéditeur et les destinataires restent lisibles dans les en-têtes.
Que se passe-t-il si je change de téléphone ?
Une nouvelle paire de clés d’identité est générée et vos correspondants voient le code de sécurité changer. L’historique ne suit que si le service propose un transfert chiffré d’appareil à appareil ou une sauvegarde chiffrée de bout en bout ; sinon il est perdu, ce qui est le comportement attendu, pas un bug.
Un service peut-il afficher « chiffré de bout en bout » et tout de même lire mes messages ?
Pas sans tricher. Deux scénarios existent : une clé supplémentaire ajoutée en douce à la conversation, ce que la comparaison des codes de sécurité permet de repérer, ou une analyse du contenu sur l’appareil avant chiffrement (« client-side scanning »), au cœur du débat européen sur le règlement dit Chat Control. Dans les deux cas, ce n’est plus du bout en bout au sens strict.
Le chiffrement de bout en bout ralentit-il les échanges ?
De façon imperceptible sur un téléphone récent : AES est accéléré matériellement et les opérations sur courbe elliptique se comptent en millisecondes. Le coût réel est fonctionnel, pas calculatoire : pas de recherche côté serveur, pas d’aperçu généré par le service, gestion des appareils multiples plus compliquée.
À lire aussi
chiffrement · chiffrement asymetrique · attaque man in the middle · chiffrement email