要約
- RFC 5159 は 2008 年 3 月の Informational RFC で、OMA BCAST 用の四つの SDP 属性を登録した。
SRTPROCTxRateは rollover counter の送信頻度を 1 から 65535 で宣言した。- 属性がない場合の既定値は一であり、送信予定を揃えるための規則だった。
- 頻度の宣言だけでは、受信側が正しい ROC を認証済みで受け取ったことも、同期したことも分からない。
SRTPAuthenticationは RCCm1、RCCm2、RCCm3 を選ぶが、個別パケットの認証結果ではない。stkmstreamは保護メディアを短期鍵メッセージのストリームへ結び付けた。- 正しいストリーム名は、鍵の到着、権利確認、状態の導入、復号、再生を保証しなかった。
- メディアレベルの
stkmstreamはセッションレベルの一覧を上書きした。 - ストリーム番号は一つの SDP セッション内でのみ一意で、永続的な識別子ではなかった。
- 保護されていない
bcastversionはダウングレードに、改変されたストリーム地図はサービス妨害に使われ得た。 - 属性名は IETF/IANA に登録された一方、意味の変更管理は OMA に残った。
- 監査では宣言、実パケット、受理済み状態、認証、復号、再生を別々の証跡として扱う必要がある。
周期は計画であり、受領記録ではない
SRTP は短いシーケンス番号だけで長時間のパケット列を扱うため、rollover counter を使って上位の状態を補う。送信側と受信側が同じ値を持っていなければ、同じ鍵と同じアルゴリズムを設定していても、パケットの解釈や認証に失敗し得る。
SRTPROCTxRate は、そのカウンターをどの頻度で送るかを SDP に記す。範囲は 1 から 65535 で、省略時は一である。相手はこの値を読んで、どの程度の間隔で更新情報が現れるかを予測できる。
だが、予測と観測は違う。ネットワークでパケットが落ちることも、完全性検査で拒否されることも、受信処理が遅れて必要な時点に間に合わないこともある。再起動や状態復元の後に、片側だけが古い値を保持する場合もある。送信ログの「送出済み」は、受信側の「受理し適用した」を代行できない。
したがって同期の証明には、宣言された頻度、実際に送られた制御パケット、その受信と認証、導入されたカウンター、そしてその状態で処理したメディアの結果が必要になる。一枚の設定画面が証明するのは最初の項目だけである。
アルゴリズム名は判定結果ではない
もう一つの属性 SRTPAuthentication は、数値によって RCCm1、RCCm2、RCCm3 を選択した。送受信側が同じ処理を選ぶためには重要だが、「RCCm2」と書かれていること自体が一つのパケットを認証するわけではない。
実際の判定には、対象パケット、鍵、ROC を含む状態、リプレイ関連の状態、選択された方式が必要である。いずれかが違えば、構成が文法上正しくても結果は失敗する。逆に、監視が設定だけを見ていると、パケットを一つも正常処理していない端末を「準拠」と数えてしまう。
暗号システムの監査では、方針と判定を分けなければならない。方針は何を行う予定だったかを示す。判定は特定の入力に対して何が起きたかを示す。RFC 5159 の属性は主に前者を運ぶ。
鍵ストリームへの道標は鍵を運ばない
放送の多重化された環境で、端末がすべての制御ストリームを受け続けるのは無駄が多い。stkmstream は、選んだメディアに必要な Short Term Key Message のストリームを示し、処理対象を絞るための属性だった。
同じ属性を複数置き、代替候補や複数の必要ストリームを表すこともできた。セッション全体の値に対して、個別メディアの値は上書きとして働いた。端末は番号を見るだけでなく、どの階層の宣言が有効かを解決しなければならない。
道標が正しくても、鍵は届かないかもしれない。メッセージが届いても、端末に利用権がないかもしれない。鍵を取り出しても別のコンテキストに入るかもしれない。導入に成功しても、認証、復号、再生のどこかで止まる可能性がある。
そのため、stkmstream を見つけた時点を「鍵配布完了」とする指標は誤っている。少なくとも購読、パケット受信、メッセージ処理、権利判定、鍵の展開、コンテキスト導入、メディア処理を別のイベントとして持つべきである。
ローカル番号はセッションを失うと別物になる
ストリーム識別子はゼロではない整数で、一つの SDP セッションの中で一意であればよかった。別のセッションが同じ番号を再利用することは正当である。番号だけをログ基盤へ送ると、この命名空間が消える。
たとえば障害記録に「stream 4」とだけ残っていても、どの記述のどのメディアに対する 4 かは分からない。メディアレベルの上書きがあれば、セッションレベルの 4 は実際には使われていなかった可能性もある。後日の記述更新で意味が変わっていても、平坦化された表には差が現れない。
証拠として保存すべき単位は、記述のハッシュまたは版、origin、時刻、メディア節、作用域、番号、端末が解決した値である。局所的な識別子を永続的な主キーに昇格させてはならない。
バージョン文字列にも実行権限があった
bcastversion は BCAST の版を表す文字列だった。秘密情報ではないが、端末がどの能力を使うかに影響する。RFC 5159 は、完全性保護がない場合に値を古い版へ改変し、ダウングレードを起こせると警告した。
stkmstream の改変は別の形で効く。必要な鍵メッセージから端末を遠ざけたり、無関係なストリームを処理させたりして、サービス妨害や資源浪費を引き起こせる。保護すべきなのは鍵そのものだけではなく、鍵を探す場所と処理法を決める制御情報でもある。
サーバー側の原文が正しいことと、端末が正しい原文を受け取ったことは異なる。受信した記述の完全性と、その記述から選ばれた動作を結び付ける必要がある。
登録機関と意味の管理者は同一ではなかった
この RFC は Standards Track ではなく Informational である。技術的な仕様は OMA BCAST に由来し、IETF と IANA は SDP 名前空間で属性名を登録した。名称の衝突を防ぐ役割と、意味を変更する権限は別々の組織にあった。
後の多重化分類では bcastversion と stkmstream が NORMAL とされ、二つの SRTP 属性は分類未決定のままとされた。これは bundled media の間で属性をどう扱うかという分類であって、安全評価でも実装証明でもない。
RFC は 3GPP MBMS、3GPP2 BCMCS、DVB-H での利用を想定していた。想定は 2008 年の設計文脈を示すが、特定事業者による導入や端末での再生を証明しない。実運用の主張には実運用の証拠が必要である。
出典
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加