要約

  • SFrame は中継が内容を読まずに映像を選択転送できるようにする。機密性の確保は、転送判断そのものをなくすことではない。
  • 映像の暗号化単位によって、中継が選べる範囲と受信端末が待つ場所が変わる。認証に通ることと表示に使えることは異なる。
  • 鍵と参照フレームの到着順がずれると、参加者は後続フレームを復号できても映像を再構成できない。接続単位ではなく受信者単位の確認が必要になる。

映像を一つのフレームとして暗号化するか、より小さなパケットを単位にするか。この選択は、通常は実装上の細部に見える。だが、受信者が画面を表示するまでのどこで待つのかという、会議の体験に直接関わる境界でもある。

フレーム全体を SFrame で保護する構成では、受信側は保護されたフレームをすべて受け取り、復号してからデコードする必要がある。途中まで届いたフレームを先に部分デコードすることはできない。RFC 9605 の第 6.3 節が示すこの制約は、暗号が遅いという測定結果ではない。処理を始められる条件についての記述である。

パケット単位の保護には、別の付加的なデータ量や実装上の負担が伴う。どちらがあらゆる端末とネットワークで速いかを、この仕様だけから決めることはできない。ただし、「暗号化されている」という一つの説明の内側にも、受信結果を左右する複数の選択があることは分かる。

何を一つに包むかが、何を選べるかを決める

SFrame は、選択転送を担う SFU がメディアの平文を読むことなく動作できるようにする仕組みだ。必要な鍵を SFU に渡さず、送信端と受信端の間で内容を保護する。RFC 9605 は 2024 年 8 月に Proposed Standard として公表された。ここで論じるのはその設計であり、現在の製品普及率ではない。

複数の画質を扱う場面では、保護と選択の関係が見えやすい。サイマルキャストでは、別々に符号化した映像の各版を独立した暗号文とし、各暗号化処理で異なるカウンター値を使う。中継は中身を開かず、用意された版の中から選べる。

スケーラブル映像符号化で中継に特定の層を取り除かせたい場合は、その層を別の SFrame 暗号文にする必要がある。中継が一つの認証済みデータを好きな位置で切り、そのまま検証を通せるわけではない。

つまり、送信側とアプリケーションが選択可能な保護単位を作り、中継がその範囲で判断する。内容の不正な改変を検出する仕組みは、すべての正しい単位をすべての受信者に届ける義務までは作らない。保護された内容が変えられていないことと、必要な内容が選ばれたことを混同してはならない。

違う画面を配ることには合理性がある

RFC 7667 第 3.7 節の選択転送構成では、中継は受信者ごとに異なる送信元の集合を届けられる。帯域や表示レイアウトに応じて、映像の版や層を選ぶこともできる。

小さな一覧表示と大きな共有画面では必要条件が違う。帯域の限られた端末に、受信できない量の映像を送ることが公平とは限らない。適切な間引きが会議を継続させる場合もある。差のある配信を直ちに妨害と呼ぶのは、技術的にも運用上も飛躍だ。

一方で、その合理性は選択の説明責任を消さない。同じ会議に接続しているという情報だけでは、同じ場面を十分に見られているか分からない。送信元を選んだ理由と、受信者に必要な表示を満たしたかは、別途確かめる対象になる。

制御情報の流れにも判断点がある。RFC 7667 によれば、中継は RTCP の要求を自身で処理することも、送信元側へ渡すこともできる。受信者が新しい参照画像を必要としても、その要求が単一の責任者に直結するとは限らない。

鍵が届けば、欠けた映像も戻るのか

参加者の追加時には、鍵の配布と映像の配送が異なる経路を通り得る。RFC 9605 第 6.2 節は、受信者がまだ持っていない鍵で暗号化されたキーフレームが先に届く場合を扱う。

そのフレームが破棄されると、後から鍵を受け取っても参照画像は戻らない。続いて届く依存フレームは復号に成功しながら、参照不足のためデコードできない可能性がある。暗号処理の成功と表示の失敗は同時に成立する。

仕様は、この特定の行き違いを避けるため、新しい鍵が使われ始めてからキーフレームを生成する方法を論じている。全サービス共通の入室時間を保証しているのではない。未知の鍵に対応する暗号文を一時保存して再試行することも許容されるが、すべての実装に求められる機能ではない。

この区別を怠ると、復旧作業が的外れになり得る。鍵がない端末に依存フレームを追加送信しても、鍵の配布にはならない。参照を失った端末で復号処理だけを速くしても、参照は生まれない。実際に起きた障害を報告しているのではなく、標準が記述する依存関係から導ける診断上の注意である。

見える情報と信頼できる情報も違う

SFrame の鍵識別子とカウンターは完全性が保護されるが、該当する中間ノードに対して秘密ではない。アプリケーションは、中継が読める一方、改変すれば認証で分かる追加メタデータを設けることもできる。ただし、周辺の情報すべてが自動的に認証範囲に入るわけではない。

受信側は、復号の準備に必要な処理を除き、認証が終わる前にそのメタデータを意味に基づいて利用してはならない。読めることは信頼してよいことと同じではない。また、見える鍵識別子に不要な業務上の意味を持たせれば、その意味は映像の暗号化では隠れない。

SSRC や MID といった転送上の識別子も、恒久的な人物名ではない。ストリームの再利用で、同じ識別子が別の参加者のメディアを運ぶことがある。SFrame の認証済みの関連付けは SFU による帰属の操作への対処に役立つが、鍵を持つ悪意ある参加者に対する個別送信者認証までは提供しない。

端末の信頼も残る。RFC 8827は WebRTC のブラウザーを信頼の基盤に含め、メディアの暗号化転送を基本要件とする。追加の SFrame 保護は、侵害されたブラウザーが安全である証拠にはならない。

本稿では公式の RFC 9605 正誤情報も確認した。検証済みの三件は、nonce を作る擬似コードの変数、AES-CTR が認証を含まないモードであるという説明、認証用副鍵の記述を修正するものだった。本稿の選択転送と参照フレームの論点をなくす修正ではない。これらの資料から、製品の適合性、実測性能、意図的な遮断が証明されるわけでもない。

中継が読める範囲を狭めることには明確な価値がある。その価値を正確に評価するには、中継がなお選べる範囲と、端末が表示に必要とする条件も正確に分ける必要がある。