9.1. SSRC collision and two-time pad (SSRC 衝突と two-time pad)

9.1. SSRC collision and two-time pad (SSRC 衝突と two-time pad)

同じ鍵とインデックスから生成された固定の鍵ストリーム出力は, 一度しか暗号化に使用してはなりません (MUST)。そのような鍵ストリームの再利用 (暗号学者によって冗談めかして "two-time pad" システムと呼ばれます) は, セキュリティを深刻に損なう可能性があります。NSA の VENONA プロジェクト [C99] は, そのような妥協の歴史的な例を提供しています。SRTP および SRTCP の鍵材料を確立および維持するために自動鍵管理を使用することが要求されます (REQUIRED); この要件は, 手動鍵管理でより発生しやすい鍵ストリーム再利用を回避するためです。さらに SRTP では, 鍵または暗号的に重要な他のパラメータが RTP/RTCP ストリームおよびパケットごとに一意であることを要求することによって "two-time pad" が回避されます。事前定義された SRTP 変換は, パケットインデックスを含めることによってパケットの一意性を達成し, SSRC を含めることによってストリームの一意性を達成します。

事前定義された変換 (AES-CM および AES-f8) は, IV に SSRC を含めることによって, 同じ RTP セッションに属するストリーム間でマスター鍵を共有することを許可します。マスター鍵は異なる RTP セッション間で共有してはなりません (MUST NOT)。

したがって, 同じマスター鍵を共有する同じ RTP セッション内のすべての RTP ストリーム間で, SSRC は一意でなければなりません (MUST)。RTP 自体は, 同じ RTP セッション内で SSRC 衝突を検出するアルゴリズムを提供します。したがって, ストリームが同一のシーケンス番号も持つ時点で SSRC が衝突するという不運な事態 (確率はおよそ 2^(-48) で発生) では, 一時的な衝突が一時的な two-time pad につながる可能性があります。したがって, 鍵管理は, セッションで使用される SSRC を交渉パラメータとして含めることによってそのような SSRC 衝突を回避し, その一意性を積極的に保証するべきです (SHOULD)。これは, 例えば RTP レベルで SSRC 衝突が検出される前に同時に送信を開始できる複数の送信者が存在するシナリオでは強い要件です。

また, 異なる SSRC であっても, 同じ鍵の広範な使用は確率的衝突および時間-メモリトレードオフ攻撃が成功する可能性を高めるかもしれないことに注意してください。

説明したように, マスター鍵は同じ RTP セッションに属するストリーム間で共有されてもよい (MAY) ですが, 各 SSRC が独自のマスター鍵を持つことが推奨されます (RECOMMENDED)。マスター鍵が SSRC 参加者間で共有され, SSRC が上記で推奨されるように鍵管理モジュールによって管理されている場合, SSRC 衝突エラーに対する推奨ポリシーは, 参加者が SRTP セッションを離れることです。これは機能不全の兆候だからです。