Pas de substitution d'identité

Dans une messagerie sécurisée de bout en bout, l’identité d’un contact est portée par sa clé : substituer sa clé, c’est se substituer à lui. La paire de clés cryptographiques long terme d’un utilisateur sert de base à la construction du canal de communication sécurisé avec lui. Ces clés sont nécessaires pour le chiffrement de bout en bout, et ce sont elles que l’on cherche à authentifier dans une authentification de bout en bout.

Si cette paire de clés long terme change, toute la sécurité des échanges à venir avec cet utilisateur repose désormais sur la nouvelle paire. Une vérification manuelle effectuée sur l’ancienne clé ne vaut alors plus rien. Un changement de clé constitue donc une remise à zéro complète de la sécurité de vos échanges avec un utilisateur : une communication qui était sûre à un moment donné peut ne plus l’être après un changement de clé. Il ne s’agit pas d’une opération anodine.

Précisons que nous parlons ici du changement vers une clé totalement indépendante. Un changement de clé est en revanche acceptable si la nouvelle clé est signée par l’ancienne, ce qui pourrait être justifié lors d’un changement de primitive cryptographique (d’algorithme de chiffrement ou de signature) dans l’application, par exemple pour passer à un cryptosystème post-quantique. Dans ce cas, si la première clé a été authentifiée correctement, on peut considérer que la nouvelle l’est également.

Signal et WhatsApp permettent à un utilisateur de changer de clé, typiquement à l’occasion d’un changement de téléphone. Cette nouvelle clé est aléatoire et totalement indépendante de celle qui existait sur l’appareil précédent. Les correspondants de l’utilisateur en sont informés par une alerte indiquant que la clé a changé, mais cette alerte est purement informative : la nouvelle clé est acceptée par défaut, sans nouvelle vérification, alors que la sécurité du canal est complètement remise en cause.

Le problème de l’identification par numéro de téléphone

Plus préoccupant encore, pour changer la clé d’un utilisateur sur ces messageries, il suffit de prouver à l’annuaire du service que l’on est propriétaire du numéro de téléphone associé. Cette preuve s’appuie sur un code à six chiffres envoyé par SMS : intercepter ce SMS suffit donc à changer la clé d’un utilisateur et, de fait, à prendre le contrôle de son compte.

Qui peut intercepter ce SMS ? N’importe quel acteur situé sur sa chaîne d’acheminement. Dans le cas de Signal, on compte :

• Signal lui-même ;
• l’opérateur d’envoi de SMS pour le compte de Signal ;
• l’opérateur téléphonique du propriétaire du numéro ;
• à l’étranger, l’opérateur téléphonique local auquel le téléphone est connecté (ce que l’on appelle « roaming ») ;
• tout acteur capable d’installer une antenne-relais pirate à proximité du téléphone de l’utilisateur.

L’opérateur légitime de chacun de ces maillons, comme tout adversaire qui arriverait à les compromettre, est en mesure de prendre le contrôle d’un compte Signal ou WhatsApp. Concrètement, l’adversaire peut alors recevoir les messages adressés à la victime et en envoyer en son nom, se substituant à elle auprès de tous ses contacts.

Deux événements illustrent que le risque de reposer sur une telle chaîne d’acheminement est bien réel :

• À l’été 2022, une attaque par hameçonnage contre Twilio^archivé, alors chargé d’acheminer les SMS de vérification de Signal, a exposé le numéro ou le code de vérification d’environ 1900 comptes Signal, et un compte au moins a effectivement été réenregistré sur un appareil contrôlé par l’attaquant.
• Fin 2024, la CISA et le FBI^archivé ont révélé^archivé que le groupe Salt Typhoon, attribué à un acteur étatique chinois, avait compromis plusieurs grands opérateurs américains, avec un accès au contenu des SMS circulant en clair sur leurs réseaux ; les responsables du FBI ont eux-mêmes recommandé^archivé de délaisser le SMS au profit de messageries chiffrées. En réaction, de nombreuses voix ont recommandé l’usage de Signal. Ce conseil peut être contesté puisque, comme nous venons de le voir, la sécurité d’un compte repose sur la confidentialité d’un code reçu par SMS… donc sur ce que Salt Typhoon vient de compromettre.

Une détection trop tardive pour être protectrice

On objecte parfois que la victime finira par s’apercevoir de la compromission, par exemple lorsqu’elle constatera qu’elle est déconnectée de Signal ou WhatsApp. Dans certains cas, cette prise de conscience a posteriori n’est pas acceptable. Considérons un exemple concret : une journaliste se rend dans un pays hostile. Sur place, en roaming, son téléphone passe par un opérateur local, qui se trouve être l’adversaire. Celui-ci peut effectuer les étapes que l’on effectue généralement lorsque l’on change de téléphone et que l’on réinstalle Signal ou WhatsApp : il saisit le numéro de la victime, intercepte le SMS de vérification et prend la main sur son compte. Il reçoit désormais les messages destinés à la victime et peut écrire en son nom. La victime ne peut même pas reprendre le contrôle, car récupérer le compte exige un nouveau SMS, que ce même opérateur ne lui fera pas parvenir.

Une messagerie sécurisée doit protéger ses utilisateurs d’un réseau hostile. Celles qui utilisent le numéro de téléphone comme identifiant, et qui ne peuvent donc « authentifier » leurs utilisateurs que par SMS, sont vulnérables face à un réseau téléphonique malveillant.

Des protections additionnelles, mais un problème structurel

Signal propose un mécanisme de code PIN, dont le rôle mérite d’être précisé. Par défaut, ce PIN n’est requis que pour restaurer les paramètres et les contacts de l’utilisateur : il n’est pas nécessaire pour recouvrer le compte lui-même. Un attaquant ayant intercepté le SMS de vérification peut donc tout simplement ignorer cette étape et reprendre la main sur le compte.

Signal propose en complément une option appelée Registration Lock, qui rend la saisie du PIN obligatoire lors d’un ré-enregistrement. Cette option, lorsqu’elle est activée par l’utilisateur, limite la portée de l’attaque par interception de SMS. Sa protection est toutefois bornée dans le temps : passé un délai de sept jours, le Registration Lock est désactivé et le compte redevient récupérable sur seule présentation du SMS de vérification.

Cette limitation découle d’une contrainte de conception : Signal doit pouvoir laisser un nouvel utilisateur reprendre un numéro de téléphone qui a été réassigné par son opérateur après une période d’inactivité. Un Registration Lock permanent rendrait cette récupération impossible.

WhatsApp propose des protections comparables, avec les mêmes limites. Sa vérification en deux étapes ajoute un code PIN à six chiffres, exigé en plus du code SMS lors de l’enregistrement sur un nouvel appareil. Comme le PIN de Signal, elle est optionnelle et désactivée par défaut. Par ailleurs, elle ne verrouille pas le compte : celui-ci reste récupérable sur la seule base du code SMS. Si l’utilisateur a associé une adresse email, celle-ci n’offre qu’un raccourci de réinitialisation du PIN, et l’autorité se déplace alors vers un autre identifiant externe, l’email, également susceptible d’être intercepté ou compromis. À défaut d’email accessible, un délai de sept jours à compter de la dernière connexion rouvre la récupération par SMS seul. Cette échappatoire n’est pas un oubli, elle découle de la même contrainte de conception que celle décrite ci-dessus : il faut toujours pouvoir laisser un nouveau titulaire utiliser un numéro réattribué.

Ces mécanismes compliquent la tâche d’un adversaire opportuniste, mais ne suppriment pas le problème de fond : l’autorité sur le compte reste in fine liée à la possession du numéro de téléphone et à la coopération des acteurs acheminant des SMS.

Une limite intrinsèque au choix de l’identifiant

Cette dépendance n’est pas propre à Signal ou WhatsApp : elle découle directement du choix d’identifier les utilisateurs par leur numéro de téléphone. Dès lors qu’un compte est attaché à un numéro de téléphone, l’opérateur de la messagerie n’a aucun moyen propre de distinguer le propriétaire légitime du compte d’un nouvel utilisateur ayant légitimement récupéré ce numéro après réattribution par l’opérateur téléphonique. La seule preuve d’identité qu’il peut exiger est la possession du numéro, et la seule façon de la vérifier à distance reste l’envoi d’un code par SMS, ce qui implique la chaîne d’acteurs décrite plus haut. Aucun mécanisme additionnel ne peut échapper à cette dépendance : tant que l’identité repose sur un numéro de téléphone, l’autorité sur le compte reste suspendue à la coopération de ce qui contrôle ce numéro. Aucune messagerie reposant sur ce modèle ne peut donc faire structurellement mieux, sauf en abandonnant l’identifiant par numéro de téléphone.

Les évolutions récentes : Key Transparency

Le problème du changement de clé silencieux orchestré par un opérateur compromis a fait l’objet de développements importants ces dernières années. WhatsApp a été l’un des premiers acteurs grand public à déployer un mécanisme dit de Key Transparency, baptisé Auditable Key Directory (AKD)^archivé, reposant sur des structures de données cryptographiquement auditables. Apple a ensuite déployé un système comparable pour iMessage sous le nom de iMessage Contact Key Verification^archivé, avec des améliorations notables, notamment la vérification des preuves de cohérence directement sur l’appareil de l’utilisateur, et un mécanisme de « gossip » permettant à des clients différents de comparer, entre eux, les clés qu’ils voient pour un même utilisateur. Signal s’est engagé dans la même voie : un journal de transparence des clés^archivé tenu par Signal consigne les associations entre identifiants (numéro de téléphone, identifiant de compte, pseudonyme) et clés publiques, accompagné d’une implémentation de référence d’auditeur tiers^archivé ; une vérification automatique des clés^archivé s’appuyant sur ce journal est en place depuis août 2026 dans ses applications.

Ces systèmes permettent de détecter qu’un annuaire centralisé présente des clés différentes selon les destinataires (attaque dite de « split view ») ou qu’une clé aurait été ajoutée à l’insu de l’utilisateur. Ils permettent de mitiger le risque de faire confiance à un annuaire centralisé, en rendant ses opérations vérifiables et auditables.

Attention cependant : la sécurité repose conceptuellement toujours sur un tiers, le service d’annuaire et le service de transparence associé. Elle suppose aussi un écosystème d’auditeurs, un mécanisme de gossip qui fonctionne, et un utilisateur qui prête attention aux alertes d’incohérence lorsqu’elles surviennent.

Concernant l’écosystème d’auditeurs, il n’existe pas, à la date où nous écrivons (septembre 2026), de registre public d’auditeurs comparable aux listes de journaux reconnus que maintiennent les navigateurs pour la Certificate Transparency. Le journal de WhatsApp est vérifié par un auditeur tiers unique, Cloudflare^archivé, qui en contresigne la cohérence depuis 2024 et en publie l’état^archivé. Celui de Signal est audité par Cloudflare^archivé et par Trail of Bits^archivé. La portée de cette vérification mérite en outre d’être précisée : l’auditeur atteste que le journal est cohérent et que son passé n’est jamais réécrit, pas qu’une clé appartient à son propriétaire légitime ; et un auditeur unique déplace la confiance plus qu’il ne la supprime, puisqu’un opérateur et son auditeur pourraient, ensemble, présenter des vues divergentes sans détection. C’est probablement pour cette raison qu’Apple propose en parallèle un mécanisme de vérification manuelle par codes courts (protocole de SAS de Serge Vaudenay, professeur de cryptographie à l’EPFL), destiné aux utilisateurs qui souhaitent de l’authentification de bout en bout. Ce protocole est le même que celui utilisé par Olvid pour permettre à ses utilisateurs d’entrer en contact à distance.

Notons surtout que la Key Transparency ne répond pas au problème central de ce critère. Un ré-enregistrement obtenu en interceptant un SMS produit un changement de clé parfaitement « légitime » aux yeux du journal, qui le consignera comme il consignerait un changement de téléphone ordinaire. La Key Transparency vise l’annuaire qui ment sélectivement, pas la prise de contrôle de l’identifiant : tant que l’identité reste un numéro de téléphone, elle rend la substitution visible, elle ne la rend pas impossible.

Une solution structurelle : supprimer l’association clé-identifiant

Un aspect de l’implémentation d’Apple mérite d’être souligné : la vérification manuelle porte non pas sur la clé d’un appareil spécifique, mais sur une clé de compte (account key) signant l’ensemble des appareils actuels et futurs de l’utilisateur. La clé de compte est elle-même générée sur l’appareil et synchronisée via le trousseau iCloud chiffré de bout en bout. Cette approche évite l’un des problèmes principaux de la vérification manuelle, à savoir qu’elle doit être refaite à chaque changement d’appareil.

Cette amélioration ne traite cependant pas la question de fond. Tant que l’identité d’un utilisateur est portée par un identifiant non cryptographique (numéro de téléphone, adresse email, identifiant de compte) qu’il faut ensuite associer à une clé cryptographique publique, cette association demeure le talon d’Achille du système. Si la Key Transparency rend l’association vérifiable et auditable, elle ne supprime pas l’association elle-même. La clé de compte d’Apple est rattachée à un Apple ID, lui-même associé à une adresse email et, dans la plupart des configurations, à un numéro de téléphone : autant de points par lesquels un adversaire suffisamment déterminé peut tenter de détourner l’autorité sur le compte, indépendamment de la robustesse cryptographique de l’édifice qui se trouve par-dessus.

La seule façon de supprimer ce point d’attaque est de cesser de faire reposer l’identité de l’utilisateur sur un identifiant externe à la cryptographie. Plusieurs voies sont possibles pour y parvenir, et deux solutions illustrent cette philosophie par des moyens différents.

Olvid dote l’utilisateur d’une identité cryptographique persistante : c’est sa paire de clés long terme qui constitue son identité, partagée avec ses contacts. L’utilisateur, en somme, est sa clé. Il n’existe pas d’annuaire centralisé qui associerait un identifiant à une clé, et donc pas d’association susceptible d’être détournée. La conséquence directe est qu’un changement de clé n’est pas une opération de maintenance transparente, mais constitue, par construction, un changement d’identité : l’utilisateur qui dispose de la nouvelle clé n’est tout simplement plus le même utilisateur que celui qui disposait de la précédente.

SimpleX Chat retient le même diagnostic et y répond par une approche encore plus radicale : ne pas attribuer d’identifiant global à l’utilisateur, pas même une clé publique persistante. Chaque conversation s’appuie sur des identifiants de file (per-queue identifiers) propres à la relation bilatérale, distincts d’une conversation à l’autre. Deux contacts d’un même utilisateur SimpleX ne peuvent ainsi pas, en analysant les métadonnées du réseau, déterminer qu’ils parlent à la même personne. Là où Olvid répond « l’utilisateur est sa clé », SimpleX répond « il n’y a pas d’utilisateur, seulement des relations ». Les deux approches échappent au problème de l’annuaire centralisé, par des moyens différents. Ceci dit, faute d’identité stable, un utilisateur de SimpleX ne peut pas s’appuyer sur ses contacts existants pour en authentifier de nouveaux : il n’existe rien dont un tiers puisse se porter garant. C’est pourtant ainsi que se tisse un « réseau de confiance » : sur PGP, en signant la clé publique d’un autre utilisateur ; sur Olvid, en présentant l’un à l’autre deux de ses contacts. SimpleX dispose aussi d’un mécanisme d’introduction, celui par lequel l’hôte d’un groupe met ses membres en relation les uns avec les autres. Mais il n’emporte aucune garantie : sans identité stable, il n’existe rien que l’introducteur ait pu authentifier au préalable, et dont il puisse se porter garant ; la mise en relation ne vaut que ce que valent les maillons qu’elle traverse, eux-mêmes jamais authentifiés par construction. Impossible donc de construire un réseau de confiance, car cela nécessite des identités stables.

Sur Threema, l’approche est encore différente : l’identifiant n’est pas le numéro de téléphone mais une suite de 8 caractères aléatoires (le « Threema ID »), auquel une clé publique est associée une fois pour toutes. Le numéro de téléphone est optionnel et ne sert qu’à se faire retrouver par ses contacts. Aucun mécanisme ne permet de changer la clé d’un ID existant. Si vous perdez votre clé privée (par exemple, en cas de perte de votre téléphone), vous devez créer un nouvel ID, autrement dit, une nouvelle identité. Là où Olvid et SimpleX suppriment l’association entre un identifiant et une clé, Threema se contente de la figer. Cela suffit à écarter le changement de clé silencieux, mais pas à résoudre l’authentification : le lien initial entre un Threema ID et sa clé reste distribué par l’annuaire central de Threema, que l’on croit sur parole au premier contact. C’est pourquoi Threema valide effectivement le critère « Pas de substitution d’identité » mais pas le critère Authentification de bout en bout.

En septembre 2026, Signal a également introduit une nouvelle fonctionnalité payante intitulée « Signal Login^archivé » qui permet de ne pas avoir à renseigner son numéro de téléphone au moment de la création de son compte. Un identifiant cryptographique vient alors remplacer le numéro. La substitution de clé reste possible, mais nécessite la connaissance de cet identifiant, ce qui rend beaucoup plus complexe la plupart des attaques expliquées ici.

Les choix de conception d’Olvid, SimpleX Chat, Threema et Signal Login entraînent néanmoins une contrainte : la responsabilité de préserver son identité, qu’il s’agisse d’une clé long terme ou de la base de données locale rassemblant l’ensemble des relations, incombe entièrement à l’utilisateur, et sa perte définitive entraîne celle du compte. Olvid répond à cette contrainte par un système de codes de récupération à conserver hors ligne, qui permet de restaurer son identité cryptographique sur un nouvel appareil ; SimpleX, par des mécanismes locaux d’exportation et d’importation de la base. Il s’agit là d’un compromis de conception assumé, en faveur d’une sécurité structurellement plus forte, au prix d’une exigence accrue vis-à-vis de l’utilisateur.

Application de ce critère

✅Bon si la clé long terme d’un utilisateur ne peut jamais être remplacée par une clé indépendante ; en particulier, aucun mécanisme externe (code SMS, email) ne permet de réassocier son identifiant à une nouvelle clé. Un changement signé par l’ancienne clé reste acceptable.