Кратко

  • Первичный core запускал GKDC, создавал групповой ключ и KEK, а прошедшие проверку узлы дерева могли сохранить эти материалы и передавать их новым участникам.
  • Снижение центральной нагрузки расширяло привилегированный контур. Сам RFC предлагал оставить раздачу только core-маршрутизаторам, если доверять всему дереву слишком рискованно.
  • Общий ключ доказывал доступ к групповому секрету, но не называл отправителя; удаление из ACL также не отнимало уже известный ключ, поэтому требовалось новое криптографическое состояние.

Масштабирование, увиденное со стороны скомпрометированного узла

Пока все маршрутизаторы исправны, делегирование выглядит как экономия. Теперь представим один взломанный промежуточный узел. Он не только меняет путь пакета. Если у него есть ACL, групповой ключ и право подготовить пакет доступа, он способен затронуть состав группы и конфиденциальность. Сэкономленная операция в центре оборачивается новой точкой власти на ветви.

Именно такой обмен предложил RFC 1949. Центральный Key Distribution Centre должен был отдельно аутентифицировать каждого получателя и зашифровать для него копию ключа. Отправка всех копий одним multicast не отменяла индивидуальной работы. Для большой группы узкое место сохранялось.

Карточка RFC Editor датирует документ A. Ballardie маем 1996 года и относит его к Experimental. Это граница фактов: можно анализировать проект, но нельзя выдавать номер RFC за свидетельство внедрения или популярности.

CBT давал проекту явный путь. JOIN_REQUEST шёл к core, JOIN_ACK возвращался назад и закреплял ветвь. Архитектура CBT описывала родительские и дочерние интерфейсы. Протокол CBTv2 считал маршрутизатор находящимся on-tree только после получения подтверждения.

Инициатор группы передавал первичному core подписанный список доступа. Core становился первым GKDC, создавал групповой ключ и KEK. Хост присылал подписанный token, управляющие сообщения проверялись по пути, а пакет доступа возвращал ACL, ключи и параметры Security Association, защищённые для конкретных получателей.

Делегировалась не только доставка

После успешного вступления узел мог хранить ACL и ключевой материал, проверить следующий запрос и передать секрет дальше. Первичный core больше не обслуживал каждый лист. Но новый узел получал практическое право расширять множество тех, кто знает ключ.

Для сравнения, GKMP назначал group controller, который создавал и обновлял ключи, собирал подтверждения, проверял сертификаты разрешений и распространял сведения о компрометации. Формы различались, функция контроля оставалась. Отказ от выделенного центрального KDC не превращал систему в бесхозную.

Один и тот же рисунок дерева скрывал два состояния. Маршрутное состояние показывало, куда пойдёт пакет. Состояние доверия показывало, кто может выдать доступ. JOIN_ACK подтверждал ветвь в определённый момент, но не актуальность всех копий ACL. Подпись подтверждала сообщение, но не стирание старого ключа и не будущую добросовестность узла.

RFC сам сузил привилегированный контур

Документ прямо спросил, разумно ли считать все маршрутизаторы дерева надёжными и защищёнными. В наиболее распределённой версии обычный узел мог расшифровывать, проверять, заново шифровать и передавать ключи. Тогда его компрометация переставала быть только сетевым событием.

Более строгий вариант направлял безопасные вступления к core и сохранял способность раздачи у core-маршрутизаторов. Централизация частично возвращалась, зато число привилегированных узлов уменьшалось. Выбор состоял не между хорошей «децентрализацией» и плохим «центром», а между объёмом снятой нагрузки и размером доверенной поверхности.

Общая тайна не указывала на конкретный голос

Если все участники знают один ключ, корректное сообщение может исходить от любого из них. RFC 1949 поэтому отделял ключи отправителей. Участник-отправитель мог распространить подписанные параметры под защитой группового ключа. Внешний отправитель сначала договаривался с первичным core, после чего core передавал его материал группе.

Право читать, право посылать и происхождение конкретного пакета — разные утверждения. Общая тайна не доказывает личность человека, мандат организации или разрешение выполнить последующую команду.

Исключённый участник уже знает прошлое

В схеме были срок ключа и KEK для обновления, но выборочного исключения в существующей группе она не решала. Требовались новые ключи, доставленные через заново сформированную группу/дерево CBT. Изменённый ACL не заставлял бывшего участника забыть текущий секрет.

Позднее RFC 2627 показал принцип исключения на логическом дереве ключей: все ключи, известные удаляемому листу на пути к корню, заменяются и передаются только оставшимся. Это не дерево маршрутизации CBT и не доказательство причинного продолжения. Это иной способ выразить разницу между записью о членстве и фактической способностью расшифровать.

Архитектура MSEC в RFC 4046 позже разделила регистрацию, удаление, авторизованный источник, масштабируемый rekey, устойчивость к сговору исключённых и восстановление после компрометации. Управление группой оказалось историей поколений, а не одноразовой выдачей секрета.

Что должен подтвердить работающий код

Принцип Heng Lu о первичности работающего кода не позволяет принять Experimental RFC за отчёт о реальности. Нужны наблюдения: сходятся ли версии ACL, кто хранит ключ, удаляется ли старое состояние, достигает ли rekey каждой ветви и теряет ли исключённый узел доступ к будущим данным.

Идея минимальной исходной спецификации и добровольного принятия объясняет привлекательность малого дополнения к существующим JOIN и ACK. Но компактный механизм должен явно назвать передачу полномочия. Право раздавать ключ не может быть незаметным побочным эффектом маршрутного вступления.

Разделение слоёв реальности не даёт слову «распределённый» завершить спор. Под ним остаются первичный core, подписанный ACL, доверенные маршрутизаторы, групповой ключ, KEK, удостоверения отправителей и поколения обновления. Центр исчез как единственная машина, но его власть стала копируемым состоянием.

Исторический вывод RFC 1949 — двойная цена масштаба. Можно уменьшить число операций центрального сервера. Но следует отдельно посчитать привилегированные узлы, устаревшие копии, пути компрометации и работу, после которой вчерашний участник действительно не читает завтрашние сообщения.

Источники

  1. RFC Editor — текущая карточка 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