Résumé

  • Le projet d’architecture Key Transparency décrit un cas où toutes les requêtes d’un utilisateur aboutissent et où toutes ses preuves sont valides, alors que le journal présente ailleurs une autre histoire. La cohérence locale conserve la bifurcation ; elle ne la signale pas à elle seule.
  • Pour découvrir cette séparation, il faut une voie de comparaison distincte : auditeur ou gestionnaire qui ne collabore pas avec le journal, requête anonyme, ou échange entre pairs. Chaque choix redistribue confiance, confidentialité et charge d’exploitation.

Deux histoires impeccables ne font pas une histoire commune

La scène d’ouverture est un scénario de travail, pas le récit d’une attaque observée. Elle met en évidence une limite de vocabulaire. Dire qu’une preuve est valide signifie que le calcul et l’état antérieur du client sont compatibles avec la réponse. Cela ne signifie pas encore que tous les clients ont reçu le même état.

Cette distinction occupe une place explicite dans draft-ietf-keytrans-architecture-09. Le Datatracker de l’IETF classe le texte comme Internet-Draft actif. La révision 09 date du 29 juin 2026 et la dernière mise à jour du dossier du 9 juillet. Le groupe de travail l’a transmis pour publication ; l’état IESG est Publication Requested, sans date de téléconférence. Le statut visé est Informational. Il ne s’agit donc ni d’un RFC approuvé ni d’un texte définitif.

Le problème traité précède le journal lui-même. Dans une messagerie chiffrée de bout en bout, le contenu peut être protégé alors que l’opérateur maîtrise encore l’annuaire qui associe un nom à une clé publique. Une substitution de clé par cet opérateur peut détourner l’identité du correspondant sans casser le chiffrement du transport.

Key Transparency inscrit ces associations dans un journal append-only protégé cryptographiquement. Search renvoie une valeur accompagnée d’une preuve. Update ajoute une nouvelle version. Monitor vérifie que les observations anciennes n’ont pas disparu et qu’une valeur détenue par l’utilisateur n’a pas changé à son insu. Le mécanisme commun porte donc sur un enchaînement vérifiable, non sur la vertu supposée de l’opérateur.

La difficulté apparaît lorsque le journal pratique l’équivoque. Il fournit à un groupe une branche et à un autre groupe une branche incompatible. Chaque client exige que la réponse suivante prolonge ce qu’il a déjà vu. Il reste ainsi sur une vue linéarisable et rejettera plus tard une réponse qui contredit cette mémoire. La bifurcation devient durable et prouvable. Mais, tant que les deux groupes ne se rencontrent pas, chacun peut continuer à valider.

La comparaison n’est pas incluse dans le verdict local

Le projet énumère trois familles de comparaison : un tiers de confiance, une communication anonyme avec le journal et une communication pair à pair. Ce sont des fonctions différentes du calcul de preuve. Elles apportent un point de vue que le client isolé ne peut fabriquer depuis sa seule branche.

Dans le mode d’audit tiers, un organisme extérieur suit la croissance du journal et signe une tête récente. La signature accompagne les réponses adressées aux utilisateurs. Cette garantie suppose toutefois que l’auditeur et l’opérateur du journal ne s’entendent pas pour signer la même branche trompeuse. Elle possède aussi une horloge : l’audit est généralement asynchrone et peut donc être en retard. Le retard maximal acceptable appartient à la configuration et à la politique d’exploitation.

La gestion par un tiers déplace davantage de fonctions. Le gestionnaire conserve et exploite l’essentiel du journal ; l’opérateur de messagerie continue d’appliquer les contrôles d’accès et d’authentifier les nouvelles versions. La sécurité dépend de la séparation entre eux, et l’opérateur doit disposer de son propre moyen de repérer les bifurcations du gestionnaire. Plusieurs témoins avec signature à seuil limitent le pouvoir d’un seul, mais il faut encore décider qui les nomme, comment leurs clés changent et qui remplace un membre défaillant.

Le mode Contact Monitoring refuse ce tiers permanent. Le propriétaire d’une étiquette vérifie régulièrement sa dernière valeur ; un contact qui vient d’observer une valeur récente revient ensuite vérifier qu’elle n’a pas été retirée avant que son propriétaire puisse la voir. Pour les bifurcations, il reste nécessaire d’utiliser une requête anonyme ou un échange entre pairs. La confiance n’a pas disparu : elle s’est déplacée vers la disponibilité des clients et la réalité de leurs rencontres.

Une requête anonyme compare la tête obtenue sans identité avec celle obtenue sur le canal authentifié. Le journal ne sachant pas quel utilisateur l’interroge, il risque de présenter la mauvaise branche. Les contrôles répétés augmentent la probabilité de découverte, à condition que l’anonymat soit réel et que le canal soit accessible.

L’échange entre pairs peut tenir dans très peu de données et passer par un canal hors bande, y compris un code QR. Sa faiblesse se trouve dans le graphe humain. Si deux communautés ne comparent jamais leurs vues, le journal peut maintenir une frontière entre elles. Un format de message ne crée pas, à lui seul, un graphe connecté.

La mémoire du client fait partie de la sécurité

Un client sait qu’une réponse ultérieure est cohérente parce qu’il conserve un point de contrôle. Perdre ce point au mauvais moment réduit sa capacité à démontrer qu’un nouvel historique contredit l’ancien. Le projet consacre donc une section entière à la perte d’état.

En Contact Monitoring, le risque est particulièrement sensible pour une valeur encore dans la fenêtre de surveillance ou dans une zone qui n’a pas suffisamment circulé entre pairs. Avec un auditeur, l’intervalle fragile correspond notamment au retard autorisé de celui-ci. Une page web éphémère, le remplacement d’un appareil, une sauvegarde incomplète ou une réinitialisation provoquée par un adversaire modifient alors la propriété de sécurité, sans modifier l’algorithme cryptographique.

L’exploitation doit préciser ce qui survit à une récupération de compte : dernière tête acceptée, obligations Monitor en attente, signatures de témoins, date de la dernière comparaison et configuration du journal. Un client restauré ne devrait pas être traité silencieusement comme un client neuf. Lorsque la continuité ne peut être établie, cette incertitude doit être enregistrée avant toute décision locale.

Le délai de détection dépend lui aussi de paramètres concrets : ancienneté maximale d’une réponse, fenêtre raisonnable de surveillance, fréquence réelle des tâches de fond, cadence des requêtes anonymes ou du bavardage entre pairs, retard de l’auditeur et efficacité du contrôle appliqué au gestionnaire. L’utilisateur peut devoir rester connecté assez longtemps pour que ces opérations se terminent. Le mot « détectable » n’a de portée opérationnelle que si ces délais ont des propriétaires et des alarmes.

Les indicateurs utiles séparent donc validation et rencontre. Il faut conserver l’âge du dernier point de contrôle, le retard du témoin, les comparaisons réussies ou impossibles, les obligations de surveillance, les récupérations d’état, les réponses rejetées pour ancienneté et le temps entre conflit et traitement. Un tableau entièrement vert sur les seules preuves peut accompagner une bifurcation durable.

Les règles d’accès ne sont pas abolies

L’architecture laisse à l’application son transport et l’essentiel de ses contrôles : authentification, droit de rechercher une identité, limitation de débit, droit de modifier une étiquette. Key Transparency permet de vérifier une opération autorisée ; il ne décide pas qui doit être autorisé.

Contact Monitoring produit un cas révélateur. Une personne pouvait consulter une étiquette hier et n’en a plus le droit aujourd’hui. Elle peut pourtant devoir lancer plus tard Monitor pour achever l’obligation créée par sa consultation initiale. Le projet exige que ce contrôle reste possible. Une révocation qui ferme uniformément tous les chemins peut supprimer la preuve nécessaire pour découvrir un retrait malveillant.

Les coûts de confidentialité diffèrent aussi. Un auditeur voit le nombre, l’ordre et le moment approximatif des changements, mais pas le texte clair des étiquettes et valeurs. Un gestionnaire voit généralement ce que voit l’opérateur : étiquettes, valeurs, historique et trafic de requêtes. Le canal anonyme doit protéger ses métadonnées. Le pair à pair réduit l’observateur institutionnel mais peut révéler des relations ou des rencontres. Il n’existe pas de témoin sans empreinte informationnelle.

Choisir un tiers exige donc plus qu’un nom dans un contrat. Il faut décrire les données observées, la durée de conservation, les possibilités de corrélation, la preuve signée, la distribution de sa clé et le comportement attendu lorsque les signatures prennent du retard ou cessent.

Changer de journal sans effacer l’histoire

Le projet recommande que les clients puissent utiliser plusieurs journaux, notamment parce qu’une migration rapide est un moyen de rétablissement après une défaillance. Mais une migration mal conduite peut détruire précisément la possibilité de vérifier l’ancien système.

Dans une transition progressive, l’ancien journal doit rester disponible assez longtemps pour que les utilisateurs souvent hors ligne terminent leur surveillance. Le fermer trop tôt rend certaines conduites anciennes indétectables pour eux. Dans une transition immédiate, la taille finale et la racine de l’ancien journal doivent être distribuées par un canal digne de confiance afin que tous terminent sur le même point de contrôle.

La fédération ajoute une question d’autorité : quelle entité contrôle le journal correspondant à une identité donnée ? Tous les participants doivent appliquer une politique cohérente d’aiguillage. Sinon, la divergence peut être créée par la résolution de l’autorité avant même que les preuves soient comparées.

L’élagage sépare enfin les données utilisateur des données cryptographiques. Une valeur peut être supprimée parce qu’elle a expiré ou n’est plus accessible, alors que certains nœuds restent nécessaires à la production de preuves pour l’état conservé. La politique de suppression et la continuité de la preuve doivent être reliées sans être confondues.

Une bifurcation détectée ne dicte pas la sanction

Lorsque deux vues vérifiables sont incompatibles, le protocole peut fournir une preuve non répudiable du mauvais comportement du journal. L’application doit encore choisir la suite : avertir, bloquer un changement de clé, suspendre un envoi, demander une vérification hors bande, isoler un appareil ou maintenir un service limité pendant l’enquête.

Cette décision ne doit pas être dissimulée dans le verdict cryptographique. Les conséquences d’une fausse alerte, d’une usurpation manquée ou d’une interruption ne sont pas identiques pour chaque service. Le mécanisme commun doit rendre le conflit observable et transportable ; l’acteur qui supporte le risque doit conserver le choix local, documenté et réversible.

La bonne question n’est donc pas seulement « les preuves passent-elles ? ». Il faut demander si les voies indépendantes comparent réellement les vues, si la mémoire survit aux parcours de récupération, si l’ancien journal reste consultable durant une migration et si l’organisation sait qui peut interrompre une communication. Un journal ne devient transparent que lorsque ses témoins peuvent se rencontrer.

Sources