Qu'est-ce que le Sealed Sender et pourquoi c'est important ?

Le chiffrement de bout en bout est devenu un standard. WhatsApp, Signal, Messenger, Google Messages : toutes ces applications protègent désormais le contenu de vos messages. Mais il y a un problème que le chiffrement seul ne résout pas. Un problème que les agences de renseignement connaissent très bien, et que la plupart des utilisateurs ignorent : les métadonnées.

Qui parle à qui ? À quelle heure ? Combien de fois par jour ? Depuis quelle adresse IP ? Ces informations, appelées métadonnées, sont souvent plus révélatrices que le contenu lui-même. Et dans la plupart des messageries, le serveur les voit en clair. Le Sealed Sender est la technologie conçue pour résoudre ce problème.

1. Le problème des métadonnées

Quand vous envoyez un message chiffré de bout en bout sur une messagerie classique, le contenu est effectivement protégé. Personne entre vous et votre destinataire ne peut lire ce que vous avez écrit. Mais pour acheminer ce message, le serveur a besoin de savoir qui l'envoie et à qui il est destiné. C'est comme une enveloppe postale : le contenu est scellé, mais l'adresse de l'expéditeur et du destinataire sont lisibles par tout le monde.

Ces métadonnées sont extrêmement précieuses. Elles révèlent vos relations sociales, vos habitudes de communication, votre rythme de vie. Elles permettent de construire un graphe social complet de vos contacts sans jamais lire un seul message.

Le général Michael Hayden, ancien directeur de la NSA et de la CIA, l'a exprimé sans détour :

"We kill people based on metadata." (Nous tuons des gens sur la base de métadonnées.)

Cette déclaration, faite lors d'une conférence à l'Université Johns Hopkins en 2014, illustre la valeur que les agences de renseignement accordent aux métadonnées. Elles n'ont pas toujours besoin de lire le contenu de vos conversations. Savoir que vous avez appelé un avocat pénaliste, puis un service d'oncologie, puis votre assureur en l'espace de deux heures raconte déjà une histoire très précise.

Le cas de WhatsApp est particulièrement révélateur. Des documents internes du FBI, rendus publics en 2021 par l'organisation Property of the People, montrent que le FBI peut obtenir les métadonnées WhatsApp en quasi temps réel, avec des mises à jour toutes les 15 minutes. Cela inclut l'identité de l'expéditeur, du destinataire, les horodatages, les adresses IP et les identifiants d'appareil. Le contenu des messages reste chiffré, mais le graphe social est entièrement transparent.

Même Signal, malgré sa réputation de protection de la vie privée, était confronté à ce problème avant 2018. Le serveur Signal devait savoir qui envoyait un message à qui pour pouvoir l'acheminer. C'est pour résoudre cette faiblesse structurelle que le Sealed Sender a été créé.

2. Qu'est-ce que le Sealed Sender ?

Le Sealed Sender est une technologie introduite par Signal en octobre 2018. Son objectif est simple mais ambitieux : permettre l'envoi de messages chiffrés sans que le serveur ne connaisse l'identité de l'expéditeur.

Dans un système de messagerie classique, chaque message envoyé au serveur contient trois informations : l'identité de l'expéditeur, l'identité du destinataire et le message chiffré. Le Sealed Sender supprime la première : l'identité de l'expéditeur est cachée au serveur. Le serveur ne connaît que le destinataire et le message chiffré, sans savoir d'où il vient.

L'identité de l'expéditeur n'est pas perdue pour autant. Elle est incluse dans l'enveloppe chiffrée que seul le destinataire peut ouvrir. Le destinataire sait donc qui lui a écrit, mais le serveur, lui, ne le sait pas.

C'est un changement fondamental dans l'architecture de la messagerie sécurisée. Traditionnellement, l'authentification de l'expéditeur était nécessaire pour que le serveur puisse appliquer des règles (limitation de débit, anti-spam, facturation). Le Sealed Sender démontre qu'il est possible de séparer l'authentification de l'acheminement.

3. Comment ça fonctionne techniquement

Le Sealed Sender repose sur un processus en cinq étapes. Chacune joue un rôle précis dans la protection de l'identité de l'expéditeur.

Étape 1 : Le sender certificate (certificat d'expéditeur)

Avant d'envoyer un message Sealed Sender, l'expéditeur obtient un certificat à durée de vie courte auprès du serveur. Ce certificat contient le numéro (ou identifiant) de l'expéditeur, sa clé publique d'identité et une date d'expiration. Le tout est signé par le serveur. La durée de validité est délibérément courte (24 heures) pour limiter la fenêtre d'utilisation en cas de compromission.

Étape 2 : Le chiffrement Signal Protocol

Le message est chiffré normalement avec le protocole Signal (Double Ratchet, clés éphémères, etc.). Cette étape est identique à un envoi classique. Le résultat est un message chiffré de bout en bout que seul le destinataire peut déchiffrer.

Étape 3 : La création de l'enveloppe scellée

Le certificat d'expéditeur et le message chiffré sont placés ensemble dans une enveloppe. Cette enveloppe est ensuite chiffrée une seconde fois en utilisant les clés d'identité de l'expéditeur et du destinataire. Concrètement, un échange Diffie-Hellman est réalisé entre la clé d'identité de l'expéditeur et la clé d'identité du destinataire pour générer une clé de chiffrement symétrique. L'enveloppe est chiffrée avec cette clé.

Étape 4 : L'envoi anonyme

L'enveloppe scellée est envoyée au serveur sans authentification de l'expéditeur. Le serveur ne reçoit que l'enveloppe chiffrée et un delivery token (jeton de livraison) qui identifie le destinataire. Le serveur ne sait pas qui a envoyé le message. Il connaît uniquement le destinataire via le delivery token.

Étape 5 : La réception et la vérification

Le destinataire reçoit l'enveloppe scellée. Il la déchiffre en utilisant sa propre clé d'identité privée. À l'intérieur, il trouve le certificat d'expéditeur et le message chiffré par le protocole Signal. Il vérifie la signature du certificat (pour s'assurer que le serveur l'a bien émis), vérifie la date d'expiration, puis déchiffre le message Signal normalement. Le destinataire sait qui lui a écrit, mais le serveur ne l'a jamais su.

Le Sealed Sender transforme le serveur en facteur aveugle. Il livre le courrier sans jamais lire le nom de l'expéditeur sur l'enveloppe, car ce nom est à l'intérieur, scellé.

4. Le système de delivery tokens

Le Sealed Sender pose un problème pratique : si le serveur ne connaît pas l'expéditeur, comment empêcher les abus ? N'importe qui pourrait envoyer des messages non sollicités (spam) de manière anonyme. C'est là qu'intervient le système de delivery tokens.

Chaque utilisateur génère un token de livraison de 96 bits, dérivé de sa profile key (clé de profil). Cette clé de profil n'est partagée qu'avec les contacts acceptés. Le token est enregistré sur le serveur et associé au compte du destinataire.

Pour envoyer un message Sealed Sender, l'expéditeur doit fournir le delivery token du destinataire. Puisque seuls les contacts connaissent la profile key (et donc peuvent dériver le token), seuls les contacts acceptés peuvent envoyer des messages Sealed Sender. Les inconnus ne connaissent pas le token et ne peuvent donc pas abuser du système.

Ce mécanisme crée une autorisation implicite sans révéler l'identité de l'expéditeur au serveur. Le serveur vérifie que le token est valide pour le destinataire donné, mais ne peut pas déterminer quel contact l'a fourni. C'est une forme élégante de contrôle d'accès anonyme.

Ce système présente toutefois une limitation : si un attaquant parvient à obtenir la profile key d'un utilisateur (par exemple en étant un contact accepté qui devient malveillant), il pourrait envoyer des messages Sealed Sender non désirés. C'est pourquoi les messageries implémentent des mécanismes complémentaires de blocage et de signalement côté client.

5. Améliorations académiques

Le Sealed Sender de Signal a fait l'objet d'analyses académiques approfondies. En 2021, des chercheurs de l'University of Maryland ont publié un article fondamental lors de la conférence NDSS (Network and Distributed System Security Symposium), intitulé "Improving Signal's Sealed Sender".

Les chercheurs ont identifié plusieurs vulnérabilités dans l'implémentation initiale du Sealed Sender :

• Attaque par analyse de trafic : En observant les patterns de connexion et de réception, un serveur malveillant pourrait corréler l'activité d'envoi et de réception pour déduire qui communique avec qui, même sans connaître l'expéditeur directement.
• Attaque par timing : Le délai entre l'envoi et la réception peut révéler des informations. Si Alice se connecte, qu'un message Sealed Sender arrive, et que Bob se connecte immédiatement après, le serveur peut déduire qu'Alice a envoyé le message.
• Compromission du delivery token : Si le serveur collabore avec un contact malveillant, le token peut être utilisé pour dé-anonymiser l'expéditeur.

L'article propose des améliorations concrètes, notamment l'utilisation de techniques de Private Information Retrieval (PIR) pour récupérer les messages sans révéler l'identité du destinataire au serveur, et des mécanismes de padding temporel pour contrer les attaques par timing. Ces travaux ont influencé les évolutions ultérieures du protocole et les implémentations dans d'autres messageries.

D'autres travaux académiques ont exploré l'utilisation de boîtes aux lettres anonymes (anonymous mailboxes) pour éliminer complètement la nécessité de révéler le destinataire au serveur. Dans ce modèle, chaque utilisateur possède une boîte aux lettres identifiée par un jeton opaque, et le serveur stocke les messages sans savoir à quel compte ils sont destinés.

6. Hashe va plus loin

Hashe intègre le Sealed Sender dans son architecture de base, mais ne s'arrête pas là. L'objectif est de minimiser les métadonnées à chaque niveau du système, en combinant plusieurs techniques complémentaires.

Sealed Sender natif : Comme Signal, Hashe utilise le Sealed Sender pour masquer l'identité de l'expéditeur au serveur. Chaque message est enveloppé dans une couche de chiffrement supplémentaire qui cache l'origine du message. Le serveur Hashe ne sait pas qui envoie un message à qui.

Mailbox tokens dérivés par HKDF : Plutôt que d'utiliser un simple delivery token statique, Hashe utilise des tokens de boîte aux lettres dérivés par HKDF (HMAC-based Key Derivation Function). Chaque contact dérive un token unique à partir du secret partagé de la session Signal. Ce token sert à adresser les messages vers la boîte aux lettres du destinataire. Le serveur ne fait que stocker les messages dans des boîtes aux lettres identifiées par des tokens opaques, sans pouvoir les relier à des comptes utilisateurs spécifiques.

Message padding en blocs de 160 octets : L'analyse de la taille des messages est une technique classique de renseignement. Un message de 12 octets est probablement un "OK", tandis qu'un message de 2000 octets contient une réponse détaillée. Hashe contrecarre cette analyse en ajoutant un padding (remplissage) à chaque message pour que sa taille soit toujours un multiple de 160 octets. Un message de 12 octets et un message de 150 octets auront la même taille après padding. L'observateur ne peut plus déduire la longueur réelle du contenu.

Aucun identifiant personnel : Contrairement à Signal qui nécessite un numéro de téléphone, Hashe ne requiert aucune donnée personnelle pour créer un compte. Pas de numéro, pas d'e-mail, pas de nom. L'identifiant est un UUID aléatoire généré localement. Cela signifie que même si le Sealed Sender était compromis, l'attaquant obtiendrait un identifiant qui ne peut être relié à aucune personne réelle.

Messages éphémères par design : Les messages sont supprimés du serveur dès confirmation de réception, avec un délai maximum de 24 heures. Cette suppression systématique élimine le risque de compromission rétroactive : même si un attaquant obtient l'accès au serveur, il ne trouvera pas d'historique de messages à analyser.

Le Sealed Sender protège l'expéditeur. Les mailbox tokens protègent le destinataire. Le message padding protège le contenu. L'anonymat total protège l'identité. Hashe combine ces quatre couches.

Cette approche multi-couches représente une différence fondamentale par rapport aux messageries qui se contentent du chiffrement de bout en bout. Le chiffrement E2E protège le contenu, mais sans Sealed Sender, sans padding, sans anonymat et sans éphémérité, les métadonnées restent exposées. Et comme le rappelait le général Hayden, les métadonnées suffisent.

La protection des métadonnées est le prochain grand défi de la messagerie sécurisée. Le chiffrement de bout en bout est désormais un acquis, mais il ne protège qu'une partie de vos communications. Savoir que vous communiquez avec un avocat, un médecin ou un journaliste est parfois plus révélateur que le contenu de vos échanges.

Le Sealed Sender, introduit par Signal en 2018, a posé les fondations d'une réponse à ce problème. Les travaux académiques ultérieurs ont identifié ses limites et proposé des améliorations. Des messageries comme Hashe intègrent ces avancées pour offrir une protection plus complète, combinant anonymat de l'expéditeur, mailbox tokens opaques, padding des messages et éphémérité systématique.

En 2026, choisir une messagerie ne se résume plus à vérifier si elle chiffre les messages. Il faut aussi se demander : le serveur sait-il qui m'écrit ? Sait-il à qui j'écris ? Peut-il déduire la taille de mes messages ? Conserve-t-il un historique ? Si la réponse à l'une de ces questions est oui, votre vie privée n'est pas pleinement protégée.