Summary

  • Publiée le 1er novembre, la révision 11 du projet d’architecture KEYTRANS ajoute une section sur l’intégrité du client, absente de la révision 10 du 7 octobre.
  • Le service qui distribue une application modifiée ou une fausse configuration du registre peut priver un utilisateur de vérification, même si le registre reste cohérent pour les autres.

Un registre peut être parfaitement tenu et son contrôleur parfaitement aveugle. C’est le problème que la nouvelle section 7.3 du projet KEYTRANS place devant les services de communication chiffrée. La preuve cryptographique ne sert que si l’application la demande, vérifie la bonne clé et conserve une mémoire fiable de ce qu’elle a vu.

La transparence des clés cherche à empêcher l’exploitant d’attribuer discrètement une autre clé publique à un compte. Les clients interrogent un journal et confrontent la réponse à des preuves ; la surveillance ou un tiers peuvent révéler des vues divergentes. Mais l’exploitant distribue souvent aussi le logiciel client et les paramètres du journal. Le contrôlé peut donc fournir l’instrument de contrôle.

La révision 11 décrit le geste concret : une version ciblée de l’application peut supprimer la vérification des preuves ou la surveillance. Une configuration altérée peut substituer à la clé publique du journal, ou d’un tiers, une clé détenue par l’exploitant. Aucun arbre cryptographique n’a besoin d’être cassé pour cet utilisateur. Le texte précédent ne comportait pas cette section consacrée à l’intégrité du client.

Le nouveau passage énumère quatre conditions : exécution sûre sur l’appareil, implémentation correcte, configuration authentique et horloge locale juste. Il distingue le terminal compromis, qui peut révéler directement clés privées et messages, de l’état local modifié ou ramené en arrière. Une horloge fausse peut faire accepter une ancienne vue du journal.

Le projet propose des pistes plutôt qu’un déploiement constaté. Un journal public des versions logicielles rendrait visible une mise à jour envoyée seulement à quelques personnes ; code ouvert et constructions reproductibles permettraient d’en examiner le contenu. D’autres protections concernent l’appareil, l’état conservé et l’heure authentifiée. La question décisive pour un service précis reste simple : peut-il changer le vérificateur d’un seul client sans trace publique ? La fiche IETF classe toujours ce document parmi les travaux du groupe soumis à l’IESG.