Un journal public pour démasquer les clés fantômes des messageries

Chaque fois qu’un message part sur WhatsApp ou iMessage, le téléphone de l’expéditeur le chiffre avec la clé publique du destinataire, une sorte de cadenas ouvert que n’importe qui peut fermer, mais que seul le téléphone de ce destinataire sait rouvrir. Ce cadenas, l’application ne l’invente pas : elle le demande au serveur de la messagerie. Et c’est là que se loge le point faible que décrit le groupe de travail de l’IETF, l’organisme qui rédige les normes techniques d’internet : l’opérateur du service « peut générer une clé publique pirate dont il détient la clé privée correspondante, et l’associer au compte d’un utilisateur à son insu », ce qui lui permet d’usurper son identité ou d’écouter ses conversations (architecture Key Transparency, version 10).

Le chiffrement de bout en bout, qui empêche le serveur de lire les messages qu’il transporte, ne dit rien de l’honnêteté de cet annuaire de clés. La transparence des clés (Key Transparency) s’attaque à ce point précis, et l’IETF soumet son document d’architecture à un dernier appel à commentaires qui se termine le 23 octobre.

Une substitution invisible pour l’utilisateur

Avec une clé ajoutée en douce, rien ne change à l’écran : la conversation reste marquée comme chiffrée, et elle l’est bien, mais avec une clé dont l’opérateur détient la contrepartie privée, de sorte qu’il peut lire les messages. Qu’il agisse de lui-même, sous la contrainte d’une autorité ou parce que ses serveurs ont été piratés, le résultat est le même. Apple le formule ainsi dans le billet qui présentait sa parade en 2023 : si « un adversaire puissant » compromettait un service d’annuaire de clés, celui-ci « pourrait commencer à renvoyer des clés compromises » (Apple Security Research, 27 octobre 2023).

Le scénario n’a rien de théorique dans le débat public. En novembre 2018, deux responsables techniques britanniques, Ian Levy (NCSC, l’agence de cybersécurité) et Crispin Robinson (GCHQ, le service de renseignement électronique), ont proposé une voie d’accès pour la police qui ne casse pas le chiffrement : selon eux, « il est relativement facile pour un fournisseur de service d’ajouter silencieusement un participant des forces de l’ordre à une discussion de groupe ou à un appel », en supprimant la notification sur le seul appareil de la cible (Lawfare, 29 novembre 2018). En mai 2019, 47 organisations, entreprises et experts ont répondu par une lettre ouverte contre ce qu’ils appellent la « proposition fantôme » (ghost proposal) : selon eux, elle saperait « le processus d’authentification qui permet aux utilisateurs de vérifier qu’ils communiquent avec les bonnes personnes » (Lawfare, 30 mai 2019). C’est précisément ce processus que la clé fantôme contourne.

La parade existe depuis longtemps sur le papier : comparer à la main, en face à face, le « code de sécurité » (WhatsApp) ou le code de validation (iMessage) affiché sur les deux téléphones. Elle suppose que les deux interlocuteurs se voient ou disposent d’un autre canal sûr, et qu’ils pensent à le faire. La charte du groupe de travail de l’IETF fixe l’objectif inverse : vérifier les clés doit demander à l’utilisateur « peu d’action (idéalement aucune) », et même pas qu’il sache que le système existe (charte du groupe keytrans).

Un registre où rien ne s’efface

L’idée est d’obliger l’opérateur à inscrire chaque clé publique de chaque compte dans un journal « en ajout seul » : on peut y ajouter des entrées, jamais en retirer ni en modifier sans que cela se voie. Le journal est organisé en arbre, de sorte qu’une seule empreinte numérique (une courte suite de caractères calculée à partir de tout le contenu) en résume l’état à un instant donné ; changer une seule entrée change l’empreinte.

Le document de l’IETF décrit trois opérations. Quand Alice écrit à Bob, son application cherche la clé de Bob et reçoit, avec elle, une preuve mathématique qu’elle figure bien dans le journal. Quand Bob change de téléphone, sa nouvelle clé est ajoutée. Et, en arrière-plan, chaque application surveille régulièrement le journal : elle vérifie que ce qui lui a été montré n’a pas disparu et, pour son propre compte, qu’aucune clé n’y a été ajoutée sans elle. C’est ce dernier point qui piège la clé fantôme : pour qu’Alice l’utilise, elle doit figurer au journal, où le téléphone de Bob la verra. Selon le document, les entrées malveillantes y sont « en général également visibles pour l’utilisateur concerné et pour ses contacts ».

La différence avec la transparence des certificats, qui joue ce rôle depuis des années pour les certificats des sites web (c’est elle qui a révélé d’autres victimes après les faux certificats émis pour des domaines de Google, dévoilés le 6 octobre), tient à la discrétion : personne n’a à télécharger tout le journal. Chacun ne consulte que les entrées qui le concernent, et les identifiants y sont masqués.

Le piège des journaux à deux visages

Reste une ruse : un opérateur malhonnête pourrait tenir deux versions du journal, l’une montrée à Alice avec la clé fantôme, l’autre à Bob sans. Le document appelle cela une « bifurcation » (fork) et prévoit trois moyens de la détecter : un tiers de confiance qui surveille le journal et signe son empreinte ; une consultation anonyme du journal, pour vérifier que l’opérateur montre la même chose à un inconnu qu’à un utilisateur identifié ; ou un échange direct entre utilisateurs, qui comparent ce qu’ils ont vu (gossip, le « bouche-à-oreille » en jargon de cryptographe).

Le texte en tire trois façons de déployer le système. Dans la plus simple, sans tiers, les utilisateurs surveillent eux-mêmes leurs entrées et celles de leurs contacts. Dans la deuxième, un auditeur extérieur atteste, avec un peu de retard, que le journal est construit correctement. Dans la troisième, un tiers gère l’essentiel du journal et l’opérateur se contente d’autoriser les modifications. Dans ces deux derniers cas, la sécurité repose sur l’hypothèse que l’opérateur et le tiers, auditeur ou gestionnaire, ne s’entendent pas pour tricher.

De WhatsApp à Signal, des journaux déjà en service

Le document de l’IETF ne cite aucun service, mais quatre déploiements sont décrits par leurs concepteurs eux-mêmes.

• WhatsApp a annoncé le 13 avril 2023 une vérification automatique fondée sur la transparence des clés, déployée d’abord sur Android et désormais « entièrement disponible » sur Android et iOS, selon une mise à jour du billet (Engineering at Meta). Elle repose sur un annuaire de clés vérifiable (Auditable Key Directory, AKD), une bibliothèque publiée en code source ouvert ; les ingénieurs y évoquent « des dizaines de milliers de changements de clés » par minute (inscriptions, réinscriptions). Jusque-là, vérifier un contact demandait de scanner un code QR en sa présence ou de comparer un code de 60 chiffres ; la vérification devient automatique pour qui ouvre l’écran du code de sécurité d’une conversation. Depuis le 24 septembre 2024, Cloudflare vérifie de façon indépendante les preuves publiées par WhatsApp : l’entreprise contrôle que chaque version du journal découle correctement de la précédente et n’existe qu’en un exemplaire, et affirme n’avoir accès ni aux clés ni aux métadonnées des messages (blog de Cloudflare).
• iMessage propose depuis iOS 17.2 la « validation des clés de contact ». Les appareils vérifient automatiquement les clés reçues et alertent l’utilisateur en cas d’anomalie, mais seulement dans les conversations avec des personnes qui ont, elles aussi, activé la fonction ; Apple ajoute un code de validation à comparer en personne ou à partager publiquement (Assistance Apple). La fonction s’active dans les Réglages, sous son nom, et exige iOS ou iPadOS 17.2, macOS 14.2, watchOS 10.2 ou visionOS 1.1 au moins, le trousseau iCloud, l’identification à deux facteurs et un code sur chaque appareil ; elle n’est pas compatible avec les comptes Apple gérés. Pour la détection des journaux à deux visages, Apple indique que Messages glisse des empreintes du journal dans la partie chiffrée « d’un petit pourcentage de messages », la méthode du bouche-à-oreille.
• Proton Mail applique le principe au courrier électronique chiffré, mais en version bêta, sur l’application web seulement, et à activer soi-même dans les réglages (option « Verify keys with Key Transparency ») ; le journal y est stocké sur une chaîne de blocs privée, sans jeton ni cryptomonnaie (aide de Proton, consultée le 17 octobre 2026).
• Signal propose depuis le 11 août 2026 une « vérification automatique des clés », qui complète ses numéros de sécurité, jusque-là à comparer en personne ou par un autre canal de confiance (blog de Signal). L’application contrôle d’elle-même, régulièrement, les identifiants de son propre utilisateur ; pour un contact, la vérification se lance depuis l’écran de son numéro de sécurité et affiche, quand elle réussit, une coche verte et la mention « Encryption verified ». Elle exige de connaître le numéro de téléphone du contact : une personne connue par son seul nom d’utilisateur ne peut pas être vérifiée ainsi. Cloudflare et Trail of Bits servent d’auditeurs tiers : ils contrôlent que chaque nouvelle version du registre reprend la précédente, à une entrée près, sans page retirée ni modifiée en secret, puis la signent. Qui préfère ne dépendre d’aucun tiers, ni de Signal ni des auditeurs, peut désactiver la fonction dans les réglages de confidentialité et s’en tenir à la comparaison manuelle. Le code du serveur est publié en source ouverte.

Aucun de ces systèmes ne suit une norme, qui n’existe pas encore. WhatsApp, Apple et Proton ont conçu les leurs chacun de leur côté ; Signal, le dernier venu, dit avoir travaillé à partir d’« une version antérieure du brouillon de protocole de l’IETF », avec des retouches adaptées à son usage.

Où en est la normalisation

Le document soumis aux commentaires, Key Transparency Architecture, rédigé par Brendan McMillion, en est à sa version 10, datée du 7 octobre 2026 (Datatracker). Le groupe de travail l’a déjà transmis à l’IESG, la direction technique de l’IETF ; le dernier appel en cours, ouvert du 9 au 23 octobre, s’adresse à toute la communauté de l’IETF, et non plus au seul groupe de travail (annonce). Deux relectures par des équipes de l’IETF, l’une consacrée à la sécurité (SECDIR), l’autre générale (GENART), sont attendues pour la même date.

Ce texte ne deviendra pas à lui seul une norme. Il vise le statut de RFC (Request for Comments, nom des documents publiés par l’IETF) « informationnelle », une catégorie que les règles de l’IETF décrivent comme publiée « pour l’information générale de la communauté d’internet », sans valoir consensus ni recommandation (RFC 2026). Il fixe le vocabulaire et les garanties attendues. Le protocole lui-même, destiné à devenir une norme, fait l’objet d’un autre document, encore en discussion dans le groupe : sa dernière version, la cinquième, date du 6 juillet 2026 (draft-ietf-keytrans-protocol). Un troisième texte doit l’adapter à MLS, le protocole normalisé de chiffrement des discussions de groupe. Pour les utilisateurs, rien ne change dans l’immédiat. Signal a déjà puisé dans un brouillon, en l’adaptant ; l’enjeu de la normalisation est que d’autres services puissent s’appuyer sur un mécanisme commun, stable et relu publiquement, plutôt que sur des systèmes maison.

Les angles morts que le texte assume

La garantie centrale du document est formulée avec ses conditions : si les outils cryptographiques sont sûrs, si les hypothèses propres au déploiement tiennent (pas de collusion avec le tiers) et si les appareils ne restent pas définitivement hors ligne, alors une tricherie du journal est « toujours détectée dans un délai borné ». Détectée, donc, et non empêchée : pendant ce délai, qui dépend de la fréquence des vérifications et du retard de l’auditeur, une clé fantôme peut servir. En cas de détection, le document prévoit seulement que l’utilisateur obtient une preuve de la tricherie, impossible à contester et publiable.

Le système suppose aussi que le téléphone garde en mémoire ce qu’il a déjà vérifié. Un appareil perdu, remplacé, réinstallé ou migré sans transfert de données perd une partie de cette capacité de détection, et le texte envisage qu’un opérateur provoque lui-même cette perte, « en forçant un utilisateur à se déconnecter et à se réinscrire ». Il recommande dans ce cas la gestion par un tiers, qui a son propre prix : ce gestionnaire « apprend en général tout ce que l’opérateur du service saurait », y compris l’historique des clés et la fréquence à laquelle tel compte est consulté.

D’autres limites découlent du périmètre même du mécanisme, qui ne vérifie qu’une chose : que la clé distribuée par le serveur est bien celle que tout le monde voit. Il ne protège pas un téléphone infecté par un logiciel espion, qui lit les messages après leur déchiffrement, ni les métadonnées (qui écrit à qui, quand), que l’opérateur continue de voir. Il ne déjoue pas l’arnaque : Apple précise que sa fonction n’a « pas été conçue pour empêcher des types de fraude tels que l’hameçonnage ». Et la vérification est confiée à l’application, que distribue l’opérateur même dont on se méfie ; c’est pourquoi les audits extérieurs, comme ceux que mène Cloudflare pour WhatsApp et, avec Trail of Bits, pour Signal, et les codes publiés en dehors du service comptent autant que le journal.

La transparence des clés ne rend donc pas l’opérateur digne de confiance ; elle oblige l’opérateur qui voudrait substituer une clé à l’inscrire dans un registre que surveillent le téléphone de la victime, ses contacts et, selon le déploiement, un auditeur, et où la trace datée de sa tricherie ne s’efface plus.

Les citations de l’IETF, d’Apple (billet en anglais), de Meta, de Cloudflare, de Signal et de Lawfare sont traduites de l’anglais par la rédaction.