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

RFC 3550 - 9. セキュリティ

9. セキュリティ (Security)​

下位層プロトコルは最終的に、認証、完全性、および機密性を含め、RTP アプリケーションに求められ得るすべてのセキュリティサービスを提供し得る。[27] には IP 向けにこれらのサービスが規定されている。RTP を用いる初期の音声および映像アプリケーションは、IP 層でそのようなサービスが利用可能になる前に機密性サービスを必要としたため、次節で記述される機密性サービスが RTP および RTCP とともに用いるよう定義された。その記述は既存の慣行を成文化するためここに含まれる。RTP の新たなアプリケーションは、後方互換性のためこの RTP 固有の機密性サービスを実装してよく (MAY)、かつ／または別のセキュリティサービスを実装してよい (MAY)。この機密性サービスによる RTP プロトコルへのオーバヘッドは低いため、将来このサービスが他のサービスに取って代わられたとしてもその代償は最小である。

あるいは、他のサービス、サービスの他の実装、および他のアルゴリズムが将来 RTP 向けに定義されてよい (MAY)。とくに、Secure Real-time Transport Protocol (SRTP) [28] と呼ばれる RTP プロファイルが、RTP ヘッダを平文のままにしてリンクレベルのヘッダ圧縮アルゴリズムが引き続き動作できるよう、RTP ペイロードの機密性を提供するために開発されている。多くのアプリケーションにとって SRTP が正しい選択となることが期待される。SRTP は Advanced Encryption Standard (AES) に基づき、ここで記述するサービスより強力なセキュリティを提供する。ここで提示する手法が特定のセキュリティ要求に適切であるとは主張しない。プロファイルはアプリケーションが提供すべきサービスおよびアルゴリズムを規定してよく、その適切な利用についての助言を提供してよい (MAY)。

鍵配布および証明書は本書の範囲外である。

9.1 機密性 (Confidentiality)​

機密性とは、意図した受信者のみが受信パケットを復号できること、すなわち他者にとってパケットは有用な情報を含まないことを意味する。内容の機密性は暗号化により達成される。

本節で規定された方法に従い RTP または RTCP を暗号化したい場合、単一の下位層パケットで送信のためカプセル化されるすべてのオクテットは 1 つの単位として暗号化される。RTCP については、各単位ごとに引き直される 32 ビットのランダム数を、暗号化前に単位の先頭に付加しなければならない (MUST)。RTP については何もプレフィックスを付加しない。代わりに、シーケンス番号およびタイムスタンプフィールドがランダムオフセットで初期化される。これはランダム性が不十分であるため弱い初期化ベクトル (IV) とみなされる。さらに、後続フィールドである SSRC が攻撃者により操作可能な場合、暗号化方式にはさらなる弱点がある。

RTCP について、実装は複合 RTCP パケット内の個別 RTCP パケットを 2 つの別個の複合 RTCP パケットに分離してよく (MAY)、1 つは暗号化し、もう 1 つは平文で送信する。たとえば、暗号鍵を知らないサードパーティモニタに配慮して、SDES 情報は暗号化し受信報告は平文で送信してよい。図 4 に描かれるこの例では、すべての複合 RTCP パケットが SR または RR パケットで始まるという要件を満たすため、SDES 情報は報告なしの RR パケット（およびランダム数）に付加されなければならない (MUST)。SDES CNAME 項は暗号化されたパケットまたは平文パケットのいずれか一方に必要であり、両方には不要である。暗号化を損ない得るため、同じ SDES 情報を両方のパケットで運ぶべきではない (SHOULD NOT)。

         UDP packet                     UDP packet

[random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2]

         encrypted                     not encrypted

#: SSRC identifier

   図 4: 暗号化および非暗号化の RTCP パケット

暗号化の存在および正しい鍵の使用は、受信側によりヘッダまたはペイロードの妥当性検査を通じて確認される。そのような妥当性検査の例は付録 A.1 および A.2 にある。

RFC 1889 の RTP 初期仕様の既存実装と整合させるため、デフォルトの暗号化アルゴリズムは、セクション 5.1 の P ビットで記述されるように 8 オクテットの倍数へのパディングが示される点を除き、RFC 1423 [29] セクション 1.1 で記述される暗号ブロック連鎖 (CBC) モードの Data Encryption Standard (DES) アルゴリズムである。初期化ベクトルはゼロである。なぜならランダム値が RTP ヘッダで、あるいは複合 RTCP パケットのランダムプレフィックスによって与えられるからである。CBC 初期化ベクトルの使用の詳細は [30] を参照。

ここで規定された暗号化方式をサポートする実装は、相互運用性を最大化するため、この方式のデフォルト暗号として常に CBC モードの DES アルゴリズムをサポートすべきである (SHOULD)。この方式が選ばれたのは、インターネット上で運用される実験的音声および映像ツールにおいて使用が容易かつ実用的であることが実証されているためである。しかし DES はその後、容易に破られることが判明した。

デフォルトアルゴリズムの代わりに、Triple-DES のようなより強力な暗号化アルゴリズムを用いることが推奨される (RECOMMENDED)。さらに、安全な CBC モードでは各パケットの最初のブロックを、暗号のブロックサイズと同じサイズのランダムで独立な IV と XOR することが必要である。RTCP については、各パケットごとに独立に選ばれた 32 ビットのランダム数を各パケットの先頭に付加することで（部分的に）達成される。RTP については、タイムスタンプおよびシーケンス番号はランダム値から始まるが、連続するパケットは独立にランダム化されない。両方の場合（RTP および RTCP）でランダム性は限られていることに注意。高セキュリティアプリケーションは、より一般的な他の保護手段を考慮すべきである (SHOULD)。他の暗号化アルゴリズムは、非 RTP 手段によりセッションごとに動的に規定されてよい (MAY)。とくに、AES に基づく SRTP プロファイル [28] は、既知平文および CBC 平文操作の懸念を考慮して開発されており、将来の正しい選択となる。

IP レベルまたは上述の RTP レベルにおける暗号化の代替として、プロファイルは暗号化された符号化向けの追加ペイロード種別を定義してよい (MAY)。それらの符号化はパディングおよび暗号化の他の側面をどう扱うかを規定しなければならない (MUST)。この方法は、望まれるアプリケーションに対しヘッダを平文のままにしてデータのみを暗号化できる。これは復号と復号化の両方を扱うハードウェアデバイスにとりわけ有用であり得る。また、RTP および下位層ヘッダのリンクレベル圧縮が望まれ、ペイロードの機密性（アドレスではなく）が十分であるアプリケーションにとり価値がある。なぜならヘッダの暗号化は圧縮を妨げるからである。

9.2 認証およびメッセージ完全性 (Authentication and Message Integrity)​

認証およびメッセージ完全性サービスは、これらのサービスは鍵管理基盤なしでは直接的に実現可能でないため、RTP レベルでは定義されない。認証および完全性サービスは下位層プロトコルにより提供されることが期待される。