Résumé

  • RFC 1949 associait l’adhésion sécurisée à un arbre CBT à la remise des clés : le cœur principal initialisait l’autorité, puis des nœuds authentifiés pouvaient la relayer.
  • Ce mécanisme répartissait la charge, mais multipliait les dépositaires privilégiés. Le texte prévoyait lui-même une variante limitant la distribution aux seuls routeurs cœurs.
  • Le secret commun ne distinguait pas les émetteurs et la suppression d’un membre de l’ACL ne lui faisait pas oublier une clé ; l’origine et l’exclusion réclamaient des états cryptographiques distincts.

La révocation commence après la liste

Un membre est rayé de la liste d’accès à midi. À midi une, il possède encore la clé reçue le matin. La politique a changé, sa capacité à lire les messages protégés n’a pas encore changé. Cette minute résume le problème que la rhétorique de l’« accès » masque souvent : une inscription peut être annulée, une connaissance déjà transmise ne peut pas être rappelée.

RFC 1949 reconnaît cette limite. Pour exclure certains membres de tout ou partie des communications, sa seule réponse consiste à distribuer de nouvelles clés dans un groupe, donc un arbre CBT, nouvellement formé. L’exclusion n’est effective que lorsque les membres conservés partagent un état que l’exclu n’a jamais reçu.

La fiche actuelle du RFC Editor classe le texte d’A. Ballardie, publié en mai 1996, comme Experimental. Il faut conserver cette frontière : le document expose une architecture et ses hypothèses ; il ne prouve ni déploiement, ni conformité, ni succès sur un réseau donné.

Le problème de départ était celui d’un centre de distribution de clés obligé d’authentifier chaque récepteur et de protéger séparément la clé de groupe pour chacun. Même si les enveloppes individuelles étaient ensuite multicastées ensemble, leur fabrication restait linéaire avec le nombre de membres. La distribution d’une clé propre à chaque émetteur alourdissait encore la tâche.

Une topologie pour les paquets, une autre pour la décision

CBT construisait un arbre partagé autour de cœurs. Une demande JOIN avançait vers un cœur ; son accusé de réception revenait par le chemin inverse et fixait la branche. L’architecture CBT décrit les relations parent-enfant qui entretiennent cet arbre. La spécification CBTv2 insiste sur le fait qu’un routeur ne devient réellement « on-tree » qu’après réception du JOIN_ACK.

RFC 1949 superposait un second sens à cette géométrie. L’initiateur du groupe envoyait une liste de contrôle d’accès signée au cœur principal. Celui-ci devenait d’abord GKDC, produisait la clé de groupe et une clé de chiffrement de clés, ou KEK. L’hôte candidat fournissait un jeton signé. Les routeurs vérifiaient les messages de contrôle et, si l’adhésion était acceptée, un paquet d’accès redescendait la branche avec l’ACL, les paramètres de l’association de sécurité et les secrets chiffrés pour chaque destinataire.

Le saut conceptuel venait ensuite : un nœud authentifié pouvait conserver ces éléments, examiner une future adhésion et remettre à son tour les clés. Le cœur principal n’avait plus à répondre à chaque feuille. Mais le droit de décider qui recevrait le secret avait lui aussi quitté le centre. L’arbre de livraison était devenu un arbre de délégation.

La spécification GKMP, contemporaine, nommait plus frontalement un contrôleur de groupe chargé de créer et redistribuer les clés, de collecter les accusés de réception, d’examiner les certificats de permission et de gérer les informations de compromission. Les deux modèles déplacent le travail différemment ; aucun ne supprime la fonction de contrôle. L’absence d’un KDC dédié ne constitue pas une absence d’autorité.

Le texte recule devant sa propre hypothèse

RFC 1949 pose une question rare et utile : peut-on raisonnablement faire confiance à tous les routeurs de l’arbre ? Dans la version la plus distribuée, un routeur ordinaire pouvait déchiffrer, vérifier, rechiffrer et transmettre des éléments de clé. Sa compromission touchait donc la confidentialité et l’admission au groupe, pas seulement le routage.

La variante renforcée faisait remonter toute adhésion sécurisée jusqu’à un cœur et réservait la distribution des clés aux routeurs cœurs. Elle sacrifiait une partie de la distribution pour réduire l’ensemble privilégié. Le choix véritable portait sur le nombre de nœuds autorisés à hériter du jugement du cœur, non sur une opposition abstraite entre centralisation et décentralisation.

Une même liaison physique pouvait transporter les paquets et la délégation, sans que les preuves se confondent. Un JOIN_ACK attestait une branche acceptée. Une signature authentifiait un message. Aucun de ces reçus ne garantissait que toutes les copies de l’ACL étaient à jour, que les anciennes clés avaient été effacées ou que chaque routeur resterait digne de confiance.

Le groupe n’était pas le locuteur

Avec une clé commune, un récepteur pouvait vérifier que l’auteur d’un message disposait du secret du groupe. Il ne pouvait pas déterminer lequel des membres avait parlé. RFC 1949 séparait donc les clés propres aux émetteurs de la clé de groupe. Un émetteur déjà membre publiait ses paramètres signés sous la protection du secret commun ; un émetteur extérieur devait d’abord négocier avec le cœur principal, qui distribuait ensuite ses paramètres.

Cette séparation empêche une inférence trop large. Être autorisé à recevoir, être autorisé à envoyer et être l’origine d’un paquet sont trois faits différents. Une vérification sous secret partagé ne démontre ni identité civile, ni mandat institutionnel, ni autorisation d’une action ultérieure.

Changer de génération pour rendre le départ réel

La hiérarchie logique de clés de RFC 2627 quantifia plus tard une autre manière d’exclure. Lorsqu’un utilisateur part, toutes les clés qu’il connaît entre sa feuille et la racine doivent être remplacées puis livrées aux seuls membres restants. Cette construction n’est pas l’arbre de routage de RFC 1949 et ne prouve aucune filiation. Elle rend simplement visible la même contrainte : retirer un nom ne retire pas un bit déjà appris.

L’architecture MSEC de RFC 4046 distingua ensuite l’enregistrement, le retrait, la source autorisée des clés, le renouvellement à grande échelle, la résistance à la collusion et la reprise après compromission. Ces catégories montrent que la gestion d’un groupe n’est pas la remise ponctuelle d’un secret ; c’est la maintenance de plusieurs générations d’autorité.

Le mot « distribué » face à l’exploitation

La primauté du code opérationnel défendue par Heng Lu impose de ne pas transformer le statut d’un RFC en preuve de réalité. Il faudrait observer la convergence des ACL, la conservation et l’effacement des clés, la réussite du rekey sur chaque branche, le comportement lors d’une réparation de l’arbre et l’accès effectif d’un membre exclu.

La logique d’une spécification initiale minimale et d’une adoption volontaire explique l’élégance du projet : utiliser les JOIN et ACK explicites de CBT comme support d’une fonction de clés optionnelle. Mais un mécanisme réduit n’est sain que si sa limite d’autorité reste explicite. Le privilège de distribution ne doit pas apparaître comme un simple effet collatéral de la présence sur l’arbre.

La distinction entre couches de réalité et pouvoir symbolique retire enfin au mot « distribué » son rôle de conclusion. Sous l’étiquette demeurent un cœur initial, une ACL signée, une liste de routeurs de confiance, un secret commun, un KEK, des identités d’émetteurs et une histoire de renouvellements. Le centre ne s’est pas volatilisé : ses décisions ont été reproduites dans davantage d’endroits.

L’héritage de RFC 1949 tient à cette mesure plus exigeante de l’échelle. On peut compter les messages évités et les chiffrements déplacés. Il faut aussi compter les nœuds privilégiés, les politiques périmées, les chemins de compromission et le coût nécessaire pour que celui qui est parti ne puisse plus lire demain.

Sources

  1. RFC Editor — fiche actuelle de RFC 1949
  2. RFC 1949 — Scalable Multicast Key Distribution
  3. RFC 2093 — Group Key Management Protocol Specification
  4. RFC 2189 — Core Based Trees version 2 Protocol Specification
  5. RFC 2201 — Core Based Trees Multicast Routing Architecture
  6. RFC 2627 — Key Management for Multicast
  7. RFC 4046 — MSEC Group Key Management Architecture
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile