メインコンテンツまでスキップ

11.3. Re-keying and access control (鍵の再生成とアクセス制御)

11.3. Re-keying and access control (鍵の再生成とアクセス制御)

鍵の再生成は, アクセス制御 (例えば, マルチキャスト RTP セッション中にメンバーが削除された場合) により発生する場合もあれば, 純粋に暗号学的な理由 (例えば, 鍵がそのライフタイムの終わりにある場合) により発生する場合もあります。SRTP デフォルトトランスフォームを使用する場合, 同じマスター鍵によって保護されるストリームのいずれかのインデックス空間が使い果たされる前に, マスター鍵を置き換えなければなりません。

鍵管理が SRTP 実装の鍵を再生成する方法は範囲外ですが, マルチキャストグループの鍵を管理する簡単な方法があることは明らかです。例えば, 単一送信者のマルチキャストでは, 通常, 新しい鍵がいつ必要かを決定するのは送信者の責任です。送信者は, 最大パケット数がいつ送信されたかを追跡できる唯一のエンティティです。受信者はいつでもセッションに参加および離脱する可能性があり, パケット損失や遅延などが発生する可能性があるためです。単一送信者のマルチキャスト以外のシナリオでは, 他の方法を使用できます。ここでは, 鍵交換が高コストな操作であり, 1 回の交換に数秒かかる可能性があることを考慮する必要があります。したがって, マスター鍵が使い果たされる/期限切れになる前に, 帯域外鍵管理が開始され, 受信者と共有される新しいマスター鍵が生成されます。いずれにせよ, 新しい鍵に切り替えるときに同期を維持するために, グループポリシーは, セクション 8.1 で説明されているように, MKI と <From, To> のどちらを使用するかを選択する可能性があります。

アクセス制御の目的で, <From, To> 期間は, パケットレートに応じて, 望ましい粒度で設定されます。一部の大規模グループシナリオでは, 高レートの鍵再生成が SRTCP にとって問題になる可能性があります。前述のように, マスター鍵を決定するために SRTCP インデックスではなく SRTP インデックスを使用することには潜在的な問題があります。特に, マスター鍵の切り替え中の短期間, SRTCP パケットが対応する SRTP の現在のマスター鍵の下にない場合があります。したがって, このようなシナリオで鍵の再生成に MKI を使用すると, より良い結果が得られます。