Messageries, courrier sécurisé et groupes chiffrés

Le chiffrement de bout en bout, ou E2EE (End-to-End Encryption), promet que seuls les appareils de l’expéditeur et des destinataires peuvent lire un message, et non le serveur qui le transporte. Cette promesse est réelle, mais elle est plus étroite que ce que suggère l’icône du cadenas : elle porte sur le contenu, pas sur les métadonnées ; sur le trajet, pas sur les appareils ; et elle dépend entièrement de la façon dont les clés sont distribuées et vérifiées. Ce chapitre traite la messagerie sécurisée comme un problème de protocole : du courrier historique (PEM, PGP, S/MIME) aux groupes modernes avec MLS, jusqu’aux questions d’anonymat, d’horodatage et de preuve de réception.

→ Lire l’explication complète de la marmotte

Que promet réellement le bout en bout ?

La différence entre un canal TLS (Transport Layer Security) et l’E2EE tient à l’adversaire considéré. TLS protège chaque tronçon : de l’appareil au serveur, puis du serveur à l’appareil du destinataire. Le serveur, lui, déchiffre et voit tout. L’E2EE ajoute un adversaire au modèle : le serveur lui-même, qu’il soit curieux, contraint par une autorité ou piraté.

Question	TLS seul	E2EE
Un observateur du réseau lit-il le contenu ?	Non	Non
L’opérateur du serveur lit-il le contenu ?	Oui	Non
Un attaquant qui pirate le serveur lit-il l’historique ?	Oui	Non, sauf sauvegardes en clair
Le serveur voit-il qui écrit à qui, et quand ?	Oui	Oui, en général
Un appareil compromis lit-il les messages ?	Oui	Oui

Six objets délimitent la promesse. Le message est protégé en contenu. L’appareil reste le point faible : il déchiffre pour afficher, et un logiciel espion lit l’écran. Le serveur ne lit plus, mais il distribue les clés publiques, et c’est là que se loge le risque principal : un serveur malveillant qui substitue sa propre clé à celle du destinataire mène une attaque de l’homme du milieu parfaitement invisible si personne ne vérifie les clés. D’où les « numéros de sécurité » ou codes QR à comparer en personne, que l’immense majorité des utilisateurs n’a jamais ouverts. Le groupe multiplie les destinataires et pose la question des arrivées et des départs. La sauvegarde dans un nuage, si elle n’est pas elle-même chiffrée avec une clé que le fournisseur ne détient pas, annule la protection : l’historique se retrouve lisible chez un tiers. Les métadonnées enfin restent largement visibles.

Le courrier sécurisé et son héritage

Le courrier électronique a été conçu sans chiffrement, et toutes les solutions s’y sont greffées après coup. PEM (Privacy-Enhanced Mail), normalisé par les RFC 1421 à 1424 en 1993, reposait sur une hiérarchie de certificats ; il n’a jamais été largement adopté, mais son encodage en base64 encadré de lignes -----BEGIN ...----- survit dans tous les fichiers de certificats. MSP (Message Security Protocol), son équivalent militaire américain, a servi au système de messagerie de la défense. PGP (Pretty Good Privacy), publié par Phil Zimmermann en 1991 et normalisé sous le nom OpenPGP (RFC 4880, révisée par la RFC 9580 en 2024), a fait un autre choix : chaque utilisateur gère ses clés et les certifie mutuellement dans une toile de confiance (web of trust), sans autorité centrale.

S/MIME (Secure/Multipurpose Internet Mail Extensions) reprend au contraire le modèle des certificats X.509 délivrés par des autorités de certification, comme pour le web. C’est l’option des messageries d’entreprise intégrées, où l’annuaire distribue les certificats. PGP et la WebPKI ne relèvent donc pas du même modèle de confiance : dans le premier, chacun décide à qui il fait confiance ; dans la seconde, le navigateur ou le système d’exploitation décide pour lui, à travers une liste d’autorités. La page Relier une clé à une identité compare ces modèles.

La gestion des clés reste le talon d’Achille du courrier chiffré. Il faut découvrir la clé du destinataire, la vérifier, la renouveler, la révoquer, et retrouver les anciennes pour relire les anciens messages. Aucun de ces protocoles n’offre de confidentialité persistante : la compromission de la clé privée d’un destinataire expose tout son historique chiffré. L’attaque EFAIL, publiée en 2018, a en outre montré que des clients de messagerie pouvaient être amenés à exfiltrer le texte déchiffré de messages PGP ou S/MIME en manipulant le contenu HTML (HyperText Markup Language) d’un courrier : le chiffrement tenait, l’intégration dans le client cédait.

Les messageries instantanées : clés éphémères et cliquets

Les messageries modernes ont tiré la leçon. Le protocole Signal combine un échange de clés initial asynchrone, possible même si le destinataire est hors ligne grâce à des clés préalablement déposées sur le serveur, et un double cliquet (Double Ratchet) qui renouvelle les clés à chaque message. Deux propriétés en découlent.

La forward secrecy (confidentialité persistante, FS) : la compromission des clés actuelles ne permet pas de déchiffrer les messages passés, parce que les clés qui les protégeaient ont été effacées. La post-compromise security (sécurité après compromission, PCS) : après une compromission ponctuelle, les échanges suivants redeviennent sûrs dès que de nouvelles contributions aléatoires non observées par l’attaquant entrent dans le calcul des clés. La première protège le passé, la seconde guérit l’avenir ; les confondre conduit à croire qu’un téléphone volé puis récupéré redevient sûr instantanément, ce qui n’est vrai qu’après quelques échanges, et seulement si l’attaquant n’a pas gardé un accès permanent à l’appareil.

Le multi-appareil complique le modèle : chaque appareil d’un utilisateur possède ses propres clés, et l’envoi d’un message revient à le chiffrer pour chaque appareil de chaque destinataire. L’ajout d’un appareil doit être signalé aux contacts, faute de quoi le serveur pourrait en ajouter un discrètement. Une politique raisonnable de rotation multi-appareils prévoit : une clé distincte par appareil, jamais copiée d’un appareil à l’autre ; une notification visible à chaque ajout ; la révocation immédiate d’un appareil perdu ; et le renouvellement des clés de session de tous les groupes auxquels cet appareil participait.

Les groupes modernes avec MLS

Dans un groupe de n membres, l’approche naïve consiste à chiffrer chaque message n fois, ou à renouveler la clé de groupe en l’envoyant à chacun : un coût proportionnel à n à chaque changement, prohibitif pour des milliers de participants. MLS (Messaging Layer Security), publié par l’IETF (Internet Engineering Task Force) sous la forme de la RFC 9420 en juillet 2023, organise les clés du groupe en arbre. Son mécanisme, dit TreeKEM, place les membres aux feuilles d’un arbre binaire ; chaque nœud interne porte une paire de clés connue des seuls membres de son sous-arbre. Pour renouveler sa contribution, un membre ne chiffre de nouveaux secrets que vers les nœuds frères de son chemin jusqu’à la racine, soit un nombre de chiffrements de l’ordre de log₂(n) : une dizaine pour mille membres, au lieu de mille.

Le groupe évolue par époques. Un membre propose des changements (ajout, retrait, mise à jour de sa clé), puis un commit les applique et fait passer le groupe à l’époque suivante, avec un nouveau secret. L’ajout d’un membre se déroule ainsi, et il vaut la peine de le dessiner :

Le retrait est symétrique : le commit qui retire un membre renouvelle les secrets de façon qu’il ne puisse pas calculer ceux de l’époque suivante. Ne pas gérer le retrait d’un membre est une erreur classique des systèmes de groupe artisanaux, qui continuent de chiffrer pour un participant parti.

Les KeyPackages sont en principe à usage unique, pour qu’un même matériel de clé ne serve pas à plusieurs ajouts ; un client doit donc en publier régulièrement de nouveaux et retirer ceux qui ont été consommés, les déploiements prévoyant en général un KeyPackage dit de dernier recours, réutilisable, pour le cas où la réserve serait épuisée. La rotation des key packages fait partie de l’hygiène opérationnelle, au même titre que la mise à jour régulière de sa feuille, qui procure la sécurité après compromission.

L’architecture d’un service MLS

MLS décrit le protocole entre clients, pas le service qui les relie. L’IETF a publié séparément un document d’architecture qui distingue deux rôles. Le service d’authentification (Authentication Service) lie les identités aux clés, par exemple au moyen de certificats ; c’est le point de confiance, l’équivalent de la vérification des numéros de sécurité. Le service de distribution (Delivery Service) stocke les KeyPackages, achemine les messages et ordonne les commits, car deux commits concurrents pour la même époque doivent être départagés. Le service de distribution ne lit pas le contenu, mais il voit la composition des groupes et le trafic, et il peut refuser de transmettre.

Cartographier une architecture MLS consiste donc à placer ces composants : clients (avec leur état de groupe local), service d’authentification, service de distribution, stockage des KeyPackages, et à indiquer pour chacun ce qu’il voit et ce qu’il peut empêcher. Les compromis opérationnels apparaissent alors : un état de groupe à synchroniser entre appareils, des commits à ordonner, des clients qui restent hors ligne longtemps et ralentissent la guérison du groupe.

L’interopérabilité est l’une des ambitions de MLS : permettre à des messageries différentes de partager des groupes. Elle suppose toutefois des accords qui dépassent le protocole, sur le format des identités, le service d’authentification et la distribution. Plusieurs messageries professionnelles ont adopté MLS, et les obligations d’interopérabilité imposées aux grandes messageries par le règlement européen sur les marchés numériques en font un candidat naturel ; l’ampleur réelle du déploiement grand public reste à observer service par service.

Anonymat et livraison

Le chiffrement cache le contenu, pas le fait de communiquer. Les métadonnées restantes d’une messagerie chiffrée typique forment une liste instructive : identifiants de l’expéditeur et du destinataire, horodatage, taille des messages, adresse IP (Internet Protocol) de connexion, liste des contacts, composition et nom des groupes, fréquence des échanges, et souvent le numéro de téléphone servant d’identifiant. Promettre l’anonymat avec seulement du chiffrement relève donc de l’abus de langage.

Les mixnets, proposés par David Chaum en 1981, répondent à ce problème : des relais reçoivent des messages chiffrés en couches, les retiennent, les mélangent et les réémettent dans un ordre différent, ce qui casse la corrélation entre entrées et sorties. Le prix est la latence et la bande passante, d’où un usage resté marginal. Le routage en oignon de Tor, plus rapide, chiffre en couches sans mélanger ni retarder, et protège donc moins bien contre un observateur qui voit à la fois l’entrée et la sortie du réseau. Certaines messageries réduisent aussi ce que le serveur apprend, par exemple en masquant l’identité de l’expéditeur dans l’enveloppe ; c’est une minimisation, pas un anonymat.

La livraison pose une autre question : prouver qu’un message a été envoyé, à quelle date, et qu’il a été reçu. L’horodatage par une autorité dédiée, normalisé par la RFC 3161, fait signer par un tiers l’empreinte d’un document et une date. La preuve de réception suppose que le destinataire ou son fournisseur signe un accusé. Le courrier certifié, sous la forme de la lettre recommandée électronique dans le cadre européen eIDAS (electronic IDentification, Authentication and trust Services), combine ces éléments chez un prestataire de confiance. La non-répudiation qui en résulte est pratique et juridique, pas mathématique : elle repose sur des journaux, des procédures et un prestataire audité. Elle est même contraire à certaines messageries chiffrées, conçues pour que les messages ne constituent pas une preuve signée, afin qu’un participant ne puisse pas démontrer à un tiers ce qu’un autre a écrit.

🐝 Ce qui arrive si on s’en passe

Sans chiffrement de bout en bout, l’opérateur du serveur lit chaque conversation, et quiconque obtient un accès à ce serveur hérite de l’historique complet sans jamais toucher un seul appareil. Sans vérification des clés de contact, le chiffrement devient même trompeur : un serveur qui substitue sa propre clé à celle du destinataire lit tout en affichant le cadenas. Sans renouvellement des clés au départ d’un membre, le groupe continue d’écrire à un ancien participant qui n’a jamais cessé de recevoir. Et sans aucun effort sur les métadonnées, la liste de qui écrit à qui, et à quelle heure, suffit souvent à reconstituer ce que le chiffrement prétendait cacher.

🦫 Explication de la marmotte 🍫

Dans une messagerie ordinaire, le serveur qui transporte les messages peut les lire. Le chiffrement de bout en bout change cela : le message est chiffré sur l’appareil de l’expéditeur et ne peut être déchiffré que sur les appareils des destinataires. Le serveur transporte alors des données qu’il ne sait pas lire. Pour que cela fonctionne, chaque appareil possède ses propres clés, et chaque utilisateur doit pouvoir vérifier que la clé affichée pour un contact appartient bien à ce contact. Les anciens systèmes de courrier sécurisé reposent sur des clés gérées à la main ou sur des certificats. Dans un groupe, la difficulté augmente : à chaque ajout ou retrait d’un membre, il faut changer les clés, pour qu’un nouveau venu ne lise pas les anciens messages et qu’un membre parti ne lise pas les suivants. Des protocoles récents organisent ces clés en arbre pour que ce changement reste rapide, même dans un grand groupe, et pour qu’un appareil piraté puis réparé retrouve sa protection. Plusieurs limites demeurent : un appareil compromis lit tout ce qu’il affiche, une sauvegarde non chiffrée annule la protection, et les informations autour des messages (qui parle à qui, quand, combien) restent visibles pour le serveur. Les cacher demande d’autres outils, qui mélangent et retardent les messages.

Pages voisines

La citent

Messageries, courrier sécurisé et groupes chiffrés

Elle cite

: les deux pages se citent l’une l’autre.

Messageries, courrier sécurisé et groupes chiffrés

Messageries, courrier sécurisé et groupes chiffrés

Que promet réellement le bout en bout ?

Le courrier sécurisé et son héritage

Les messageries instantanées : clés éphémères et cliquets

Les groupes modernes avec MLS

L’architecture d’un service MLS

Anonymat et livraison

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines