要約

  • RFC 1949 は、CBT の安全な参加手順にグループ鍵配布を重ね、認証済みの木上ノードへ後続参加者の認証と鍵受け渡しを委ねた。
  • それは中央の暗号処理を分散したが、権限を消去しなかった。全ルーターを信頼できない場合に、配布権限をコアへ戻す案も本文自身が示した。
  • 共通鍵は個別送信者を特定せず、ACL から名前を消しても既知の鍵は回収できない。送信者証明と排除には、それぞれ別の暗号状態が必要だった。

「一人抜けた後」を先に考える

メンバーがグループから外された。しかし、その端末は昨日受け取った共通鍵を保持している。ACL は今日の資格を語るが、鍵は昨日の許可が残した能力である。残ったメンバーが同じ鍵を使い続ける限り、名簿上の退場は未来の通信からの退場にならない。

RFC 1949 は、この難所について選択的な解決策を持たないと記した。特定メンバーを以後の通信から外すには、新しい鍵を新しく形成した CBT グループ／木を通じて配る必要がある。失効とは記録の削除ではなく、退場者が導出できない新状態への切替だった。

RFC Editor の記録によれば、A. Ballardie によるこの文書は1996年5月の Experimental RFC である。ここから読めるのは提案の構造であって、稼働実績や普及率ではない。

中央 KDC の問題は明快だった。多数の受信者を一人ずつ認証し、それぞれの公開鍵または共有秘密に合わせてグループ鍵を包めば、作業量は人数とともに増える。包みを一度にマルチキャストしても、一人ずつ作る暗号処理は消えない。しかも共通鍵だけでは、受信者は「グループの誰か」が送ったことしか確かめられず、送信者ごとの起点認証ができない。

JOIN_ACK が枝を権限経路に変える

CBT はグループごとに共有配送木を作る。参加要求はコアへ向かい、確認は逆向きに戻って枝を確定する。CBT のアーキテクチャは親子関係を明示し、CBTv2 の仕様は JOIN_ACK を受け取るまでノードを on-tree と見なさない。データが偶然流れたのではなく、誰が誰の上流・下流かを状態として持つ。

RFC 1949 はその明示性を鍵配布に利用した。グループ発起者が署名済み ACL を主コアへ渡し、主コアは最初の GKDC としてグループ鍵と再鍵用 KEK を作る。参加ホストは署名トークンを送り、途中のルーターは隣接する制御メッセージを検証する。承認されると、鍵と Security Association パラメーターを含むアクセス包が逆経路を下り、次の受領者ごとに暗号化される。

ここまでは中央から枝への配送である。拡張性の核心は、その後にある。認証を終えた木上ノードが ACL、グループ鍵、KEK を保持し、次の参加者を認証して材料を渡せる。主コアの仕事は減る。代わりに「この参加者へ秘密を渡してよい」と判断する場所が増える。

GKMP の仕様では、グループコントローラーが鍵生成、配布、受領確認、権限証明書の検査、侵害情報の処理を担った。配置は異なるが、どちらも制御主体を必要とする。「専用の中央 KDC がない」は、「誰にも決定権がない」という意味ではない。

文書自身が信頼範囲を縮めた

興味深いのは、RFC 1949 が自分の最も強い前提を放置しなかったことだ。配送木上の全ルーターが悪意なく、攻撃から十分守られていると仮定してよいのか。通常ノードが鍵を復号・再暗号化し、配布者にもなれるなら、ルーター侵害は転送障害を超えて会員資格と秘密保持へ届く。

そこで厳格版は、安全な JOIN_REQUEST をコアまで送り、鍵配布能力をコアルーターだけに残す。分散度は下がるが、特権集合は小さくなる。これは設計の敗北ではない。拡張性を「何台が仕事をするか」だけでなく、「何台を鍵権限者として信頼するか」で測り直した結果である。

同じ物理線をデータと権限が通るからこそ、証拠を分けなければならない。JOIN_ACK は枝が成立したことを示せる。署名はある主体があるメッセージを作ったことを検証できる。どちらも、そのノードの ACL が最新版であること、古い鍵を消したこと、将来も侵害されないことまでは証明しない。

共通鍵が証明するのは「誰か」まで

グループ鍵を全員が知れば、受信者はメッセージがグループ秘密を知る主体から来たと判断できる。しかし一人を名指しできない。RFC 1949 は送信者固有鍵を別に配る。既存メンバーの送信者は署名済み材料を共通鍵の下で公開し、非メンバー送信者は主コアと先に協議し、コアがその材料をグループへ渡す。

読む資格、送る資格、特定パケットの起点は別の主張である。共通秘密を使うと、認証範囲はグループ境界に留まる。そこから個人、組織、命令権限まで推論すれば、プロトコルが評価していない現実を足してしまう。

鍵を知った事実は削除できない

後の RFC 2627 は論理鍵階層で排除費用を示した。ある利用者を外すなら、その利用者が知る葉から根までの鍵を置換し、残留メンバーだけに再配布する。CBT の配送木とは別の構造であり、因果的な後継を意味しない。ただし「既知の秘密を名簿操作では消せない」という境界を数量として見せる。

RFC 4046 はさらに、加入・離脱、認可された鍵源、スケーラブルな再鍵、排除者の結託、侵害回復を別々の要件にした。グループ鍵管理とは、一つの鍵を渡す機能ではなく、複数世代の権限を変化させる仕組みなのである。

動いたかどうかを仕様番号から推測しない

Heng Lu の稼働コード優位を当てはめると、Experimental という登録も、美しいメッセージ図も、運用結果の代わりにはならない。観測すべきは ACL の収束、鍵消去、再鍵到達、障害時の保管者変更、退場者の未来アクセスである。

最小の初期仕様と自発的採用という視点では、既存の明示的 JOIN／ACK に任意の鍵配布を重ねる簡潔さが見える。だが小ささは曖昧さではない。配布権限がいつ、誰へ、どの条件で継承されたかは最小核の内側に置く必要がある。

現実の層を分ければ、「分散」という名称に保証を代行させずに済む。現実には主コア、署名 ACL、信頼ルーター一覧、グループ鍵、KEK、送信者資格、再鍵世代がある。中心は消えたのではなく、それらの状態へ分解されて木に配置された。

RFC 1949 が残す問いは、木が安全だったかではない。仕事を分けるために、いくつのノードへ判断力まで渡したのか。その答えは帯域や暗号回数だけでなく、特権保管者の数、古い政策のコピー、侵害時の波及、そして去った者に明日の鍵を渡さない費用で測られる。

情報源

  1. RFC Editor — RFC 1949 現行記録
  2. RFC 1949 — Scalable Multicast Key Distribution
  3. RFC 2093 — GKMP Specification
  4. RFC 2189 — CBTv2 Protocol Specification
  5. RFC 2201 — CBT 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