要約

  • MBONED の第 01 版草案は Informational を意図した現行 Internet-Draft であり、RFC、実装、相互接続実績ではない。
  • TESLA は対称鍵の開示を遅らせて送信者と受信者の権限を分けるが、時刻同期とアプリケーションへの解放遅延を必要とする。
  • 共有鍵で復号できることは送信元証明ではなく、各コンテンツ単位は利用前に非対称な認証性を得なければならない。
  • 認証、再送・欠落、要求との結合、オリジン許可、プライベートモード同意、表示結果は別々の受領証である。

時間が認証境界になる

TESLA は公開鍵署名とは異なる方法で非対称性を作る。送信者はまだ公開されていない対称鍵でデータにタグを付け、受信者がそのデータを受け取ったと想定できる時点の後に鍵を明かす。開示予定時刻を過ぎて届いたデータは捨てる。

この構造では、鍵を知る普通の受信者が過去にさかのぼって正規の送信者を装うことを難しくできる。一方で、認証済みデータをアプリケーションへ渡せる時刻は一方向遅延より後になる。時計の誤差、ネットワーク遅延、開示スケジュールは単なる運用値ではなく、判定の入力である。

低遅延サービスが待ち時間を短縮するために検証前のフレームをデコーダーへ渡せば、TESLA は文書上存在していても保護境界として機能しない。必要なのは「最終的に検証できた」ではなく、「利用前に検証できた」という受領証である。

復号鍵は発言権ではない

効率的なグループ配信では、複数の受信者が同じ復号材料を持つことが多い。素朴な対称認証で同じ鍵を送信者タグにも使うと、正規の受信者も他の受信者が受理するタグを生成できる可能性がある。

これはすべてのグループ暗号を否定する話ではない。草案が要求しているのは、コンテンツ単位ごとに送信元の非対称性を保つことだ。署名なら秘密署名鍵、TESLA なら時間差、AMBI なら認証済みマニフェストが、その役割を担う。

運用台帳には「鍵を受け取った主体」と「コンテンツを発行できる主体」を別の列で記録すべきである。メンバーという一語で両者をまとめると、事故時に誰が復号でき、誰がタグを作れたかを説明できない。

署名とマニフェストも前提を持つ

パケットごとの非対称署名は、送信者だけが署名鍵を持ち、受信者には検証鍵だけを配る。だが検証鍵が正しいソース、対象コンテンツ、期間に結び付く理由は別に確立する必要がある。

AMBI は順序付きパケットダイジェストのマニフェストを認証済み帯域外チャネルで配る。親ページのオリジンと密接に関係する HTTPS からマニフェストを得る構成は一例になる。しかし、その URL が存在すること、TLS が成功したこと、マニフェストが全パケットを覆うことはそれぞれ別の事実である。

方式の名前だけで安全を判定してはいけない。署名方式では鍵の来歴、TESLA では時刻と解放、マニフェスト方式では帯域外チャネルと欠落処理を監査する。方式を選んだ記録は、方式が正しく実行された結果ではない。

ブラウザーは未認証データを解析しない

ブラウザー内のパーサー、コーデック、レンダラーは大きな攻撃面である。オブジェクト全体が完成してからだけ認証する設計では、注入パケットがメモリー確保、並べ替え、復元、部分デコードを先に引き起こし得る。

パケット単位の認証なら、改変や偽造をアプリケーション配送前に拒否できる。しかし UDP は順序、信頼配送、重複排除、リプレイ防御を提供しない。パケット番号、TESLA の時間区間、または順序付きマニフェストが重複、並べ替え、削除を別途示す必要がある。

最小のブラウザー境界は、送信元認証、必要な順序状態、要求との結合を通過したデータだけを信頼計算基盤へ入れることだ。復号成功や正しい送信元アドレスは、その代わりにならない。

一つの偽造が修復を増幅する

オブジェクト認証だけに頼ると、一つの注入パケットで大きなオブジェクト全体が失敗する。多数の受信者がユニキャスト修復を要求すれば、攻撃入力より大きな計算と帯域の支出が発生する。

修復は受信者、オブジェクト、鍵エポック、時間窓ごとに上限を持つべきである。さらに、パケットタグ、順序、マニフェスト、オブジェクトダイジェスト、要求結合のどこが失敗したかを残す必要がある。

認証失敗率と修復コストは別の指標である。失敗パケットが少なくても、人気オブジェクト一つが多数の端末で再取得されれば影響は大きい。可用性チームが修復容量だけを増やすと、次の注入の増幅率を上げかねない。

正しいパケットが別の要求に属することもある

HTTPS のユニキャストでは、保護された一つの交換が要求と応答の対応を支える。マルチキャストデータは一方向で、クライアントの要求を運ばない。二つのチャネルが同じ正規ソースによって署名されていても、異なる要求に対応し得る。

追加の暗号学的結合がなければ、経路上の攻撃者が二つの信頼済みチャネルのパケットを交換しても、送信元署名は有効なままになり得る。欠けているのは「このデータはこの要求への応答である」という主張だ。

送信元、コンテンツ単位、要求、アプリケーション権限、表示結果を別に検証する必要がある。チャネル認証済みという一つの状態へ畳み込むと、真正だが誤った応答を追跡できない。

加入許可と回線保護は別である

悪意あるオリジンはブラウザーに多数のチャネル加入を試みさせ得る。ブラウザーはホスティングサイトに関連しないチャネルを制限し、必要なら CORS に似た明示的なクロスオリジン許可を求める。

上流ルーターは過負荷や異常加入を監視し、人気の低いコンテンツを対象にサーキットブレーカーを動かせる。ブラウザーはユーザーをオリジンから守り、ルーターは共有容量を守る。どちらも送信元署名やアプリケーション結果を決めない。

プライベートモードの加入は、IGMP や MLD のメタデータをネットワーク要素へ見せるため、明示的同意が必要になる。同意は観測可能な加入行為への許可であり、コンテンツの真実性や完全な匿名性への保証ではない。

暗号化後も共同配送は見える

暗号化は鍵を持たない観測者から本文を隠す。しかしサイズ、時刻、アドレス、プロトコル形状は残り得る。マルチキャストでは、暗号文の意味が分からなくても同一内容が複数方向へ配送されたと経路上で判断できる。

一台の受信端末が侵害されれば、そのエポックのグループ鍵と平文が露出し得る。個別認証した受信者へ TLS 1.3 などの前方秘匿なチャネルで短期鍵を配り、周期的に廃棄すれば過去範囲を制限できる。

ただしローテーション設定は削除証明ではない。送信者の切替、受信者の旧鍵拒否、端末上の消去を別々に確認する。加入リストから消えたことだけでは暗号学的排除は成立しない。

証拠を時系列で保持する

記録すべきなのは、受信者認証、鍵配布許可、鍵エポック、インストール、検証鍵またはマニフェスト、パケット到着、開示予定、認証判定、リプレイ・並べ替え・欠落、要求結合、オリジン許可、パーサー解放、アプリケーション結果である。

グループ秘密や個人データは記録しない。端末、要求、オブジェクトはハッシュ化できる。重要なのは、認証前に利用されたか、どの権限がどの時点で判定したかを復元できることだ。

受信者侵害、メンバー変更、時刻劣化、鍵配布経路変更、ソースまたはグループ移行、マニフェスト元変更、ブラウザー権限変更、修復増幅、ルーティング変更、新しい草案版は再評価の契機となる。

出典と限界

凍結資料は第 01 版と Datatracker の状態・履歴・参照、MBONED、Internet と UDP の脅威モデル、SSM と interdomain ASM 廃止、TLS 1.3、TESLA、NORM、ALC、マルチキャスト認証、WebRTC セキュリティ、Client Hints、QUIC、WebTransport、AMBI を含む。

これらは仕様文と公式記録を示す。実装適合、採用、性能、実際の偽造、端末侵害、プライバシー事故、表示結果は示さない。冒頭は証拠の順序を検討するための構成例である。

出典