JP4836493B2

JP4836493B2 - リアルタイム転送プロトコル（ｒｔｐ）パケット認証のための方法

Info

Publication number: JP4836493B2
Application number: JP2005155748A
Authority: JP
Inventors: ガーグサチン; サインネヴジョット; コーチトサイティモシー
Original assignee: アバイアインコーポレーテッド
Priority date: 2004-05-27
Filing date: 2005-05-27
Publication date: 2011-12-14
Anticipated expiration: 2025-05-27
Also published as: EP1601156A2; US20050265349A1; US7372856B2; JP2005341593A; CA2506967A1; EP1601156A3

Description

本発明は、パケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法に関する。詳細には、本発明は、ＩＰネットワーク上での音声通信において、料金詐欺、プライバシー侵害、音声品質の劣化、またはサービス妨害（ＤｏＳ）を防止するための方法に関する。

ＩＰ上での音声通信（ＶｏＩＰ）による電話は、豊富な機能およびコスト節約の面ですばらしく大きな可能性を提供する。しかし、データ・ネットワークとそれに対応する通信プロトコルの利用は、それらに付随するセキュリティ上の脆弱性も持ち込む。さらに、信号伝達およびメディア転送用のＶｏＩＰプロトコル自体が、料金詐欺、プライバシー侵害、音声品質の劣化、またはサービス妨害（ＤｏＳ）を可能にする、さらなる脆弱性を生じさせる。

特に、メディア転送のための基礎として使用されるリアルタイム転送プロトコル（ＲＴＰ）は、第三者による私的会話の盗聴、偽造された内容の挿入、および音声品質を劣化させるパケットの挿入や変更を始めとする、様々な攻撃を受けやすい。
ＲＴＰについての説明は、以下の文献中に見つけることができる。
・H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-time Applications," IETF RFC 3550, July 2003, <http://www.ietf.org/rtf/rtf3550.tet?number=3550>

これらのＲＴＰの脆弱性に対する懸念を受けて、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）のオーディオ／ビジュアル転送作業部会が、ＲＴＰトラフィックに、機密性、メッセージ認証、および再生保護を提供する、セキュアなリアルタイム転送プロトコル（ＳＲＴＰ）を提案した。ＳＲＴＰと同様に、ＳＲＴＣＰは、ＲＴＰ制御プロトコル（ＲＴＣＰ）に、類似のセキュリティを提供する。

ＳＲＴＰは、セキュリティの強化を実現するため、ＲＴＰペイロードの高度暗号化標準（ＡＥＳ）による暗号化、およびメッセージ認証のための鍵付きハッシング（ＨＭＡＣ−ＳＨＡ１）を使用する、ヘッダーおよび暗号化ペイロードのメッセージ認証ハッシュについて詳細に定める。アバイヤ（Ａｖａｙａ）社の製品は、これまで実施されてきたアバイヤ暗号化アルゴリズム（ＡＥＡ）による暗号化ばかりでなく、このより新しいＡＥＳによる暗号化によってもサポートされる。ＭＡＣ−ＳＨＡ１は、デフォルトのメッセージ認証符号であり、必ず実装しなければならない。しかし、オプションのメッセージ認証符号も許可される。ＨＭＡＣ−ＳＨＡ１は、１６０ビットのダイジェストを生成し、最下位の方から高々８０ビットを切り捨てることを推奨する。しかし、帯域幅を効率的に利用するため、（１）ＲＴＰペイロードがステートレスである、（２）攻撃者がＳＲＴＰ暗号文に意味をなす変更を施せる可能性が小さい、（３）データ転送またはアクセス制御上の決定がＲＴＰデータに基づいて行われない、という条件が満たされる場合は、１２８ビットを切り捨てることもできる（その結果、３２ビットの認証タグが得られる）。

ＳＲＴＰ、ＡＥＳ、ＨＭＡＣ−ＳＨＡ１、およびＡＥＡについてのさらなる説明は、それぞれ以下の文献中に見つけることができる。
・M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman, "The Secure Real-time Transport Protocol," IETF RFC 3711, March 2004, http://www.ietf.org/rtf/rtf3711.tet?number=3711
・National Institute for Standards and Technology (NIST), "Advanced Encryption Standard (AES)," FIPS pub 197, http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
・H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," IETF RFC 2104, February 1997, http://www.ietf.org/rtf/rtf2104.tet?number=2104
・R. Gilman, "An Efficient Encryption Algorithm for Audio Version 1.2," Avaya COMPAS document93923, July 3, 2002

ＳＲＴＰの潜在的な懸念の１つは、認証ハッシュによって課されるオーバーヘッドである。図１に見られるように、ヘッダーと暗号化ペイロードの全体を、ＨＭＡＣ−ＳＨＡ１アルゴリズムによってハッシュして、８０ビットまたは３２ビットのメッセージ認証タグを生成する。タグは、各パケットを認証できるように計算しなければならない。

したがって、可能なサービス妨害攻撃の１つは、各パケットが不正な認証タグを含む一連の偽パケットを目標に大量に送り付けることである。

図２に、ＨＭＡＣ−ＳＨＡ１を使用して認証タグを計算するためのステップを示す。主たる計算には、５１２ビットのＮ＝Ｌ＋３個のブロックをハッシュするステップが含まれるが、ただし、Ｌ＝ｃｅｉｌ（Ｍ／６４）であり、Ｍは認証タグが対象とするＲＴＰヘッダーとペイロードのバイト数である。計算全体には、ＸＯＲ演算、パディング操作、およびコピー操作がいくつか含まれるが、全体の実行時間は、ほぼハッシュ操作によって左右される。１つのＳＨＡ１ハッシュを求めるためのメイン処理は、２０のステップからなるラウンドを４回繰り返すことから成り立っている。これら４回のラウンドには、全部で７４０回の３２ビット論理および算術演算（ＡＮＤ、ＯＲ、ＮＯＴ、ＸＯＲ、モジュロ加算）が含まれる。ハッシュ操作に加えて、２回の５１２ビットＸＯＲ演算は、３２回の３２ビット論理ＸＯＲ演算を必要とする。

しかし、これら２回のＸＯＲ演算は、最適化を行うことで分離することができる。最適化は、値が小さなＭに対して可能である。図２の各ＸＯＲ演算に続いて、ハッシュ操作が行われる。ＸＯＲ演算値に対するハッシュ操作の結果は、事前に計算しておき、そのハッシュ操作に対応する元の初期化ベクトル（ＩＶ）を置き換えるために使用することができる。これら２つの値は、１回だけ計算すればよいが、それは、最初に鍵のＳＲＴＰ交換を行った後は、鍵およびｉｐａｄ／ｏｐａｄの値は変化しないからである。したがって、安定状態では、ハッシュを２回減らすことができ、計算のオーバーヘッドは、Ｌ＋１個のブロックをハッシュするのに要するオーバーヘッドに減少する。８０００ＭＨｚのＧ．７１１音声符号化の場合、各ＲＴＰパケットのペイロードには、１６０個の８ビット・サンプル、すなわち１６０バイトが含まれる。ＲＴＰヘッダーは１２バイト長であり、ＣＳＲＣフィールドは存在しないと仮定する。そうすると、各ＲＴＰパケットには、１７２バイトが含まれるので、Ｌ＝ｃｅｉｌ（１７２／６４）＝３、Ｎ＝Ｌ＋３＝６となる。上で説明した最適化を行えば、Ｎ＝Ｌ＋１＝４となる。

各ＳＲＴＰパケットの認証では、６回のＳＨＡ１ハッシュ操作が必要とされ、これは、制御フロー命令を数に入れなくても、約７４０×６＝４５６０回の論理演算に等しく、６０ＭＨｚのプロセッサで７６ｍｓかかる。攻撃者は、この計算のオーバーヘッドを利用して、プロセッサ・サイクルを消費させることだけを目的として、認証プロセスを起動する偽パケットを犠牲者に大量に送り付けることができる。
H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-time Applications," IETF RFC 3550, July 2003, <http://www.ietf.org/rtf/rtf3550.tet?number=3550> M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman, "The Secure Real-time Transport Protocol," IETF RFC 3711, March 2004, http://www.ietf.org/rtf/rtf3711.tet?number=3711 National Institute for Standards and Technology (NIST), "Advanced Encryption Standard (AES)," FIPS pub 197, http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," IETF RFC 2104, February 1997, http://www.ietf.org/rtf/rtf2104.tet?number=2104 R. Gilman, "An Efficient Encryption Algorithm for Audio Version 1.2," Avaya COMPAS document93923, July 3, 2002 National Institute for Standards and Technology (NIST), "Security Requirements for Cryptographic Modules," FIPS pub 140-2, http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf National Institute for Standards and Technology (NIST), "Annex C: Approved Random Number Generators," FIPS pub 140-2 Annex C, http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf National Institute for Standards and Technology (NIST), "Digital Signature Standard (DSS)," FIPS pub 186-2, <http://csrc.nist.gov/publications/fips/fips186-2/fips-186-2-channel1.pdf>

本発明は、従来のＳＲＴＰの方法が抱える問題点に対処するために行われた。以下で、総称的にＳＲＴＰ＋と呼ばれる本発明の３つの実施形態について説明するが、これらの実施形態は、偽パケットによって消費されるプロセッサ・サイクルの最大量を著しく低下させる。各実施形態は、ヘッダーとペイロードの全体を認証する必要がないメッセージ認証の実施形態を利用する。この点が、メッセージ認証と、単一のメッセージ認証タグを用いた保全性チェックとを共に実行する、ＳＲＴＰとは異なる。対照的に、ＳＲＴＰ＋は、偽パケットを速やかに識別する目的で、認証だけに焦点をしぼる。したがって、数多くの偽パケットが存在する状況で、ＳＲＴＰ＋は優れた働きをする。しかし、パケットがすべて本物である場合は、最小量ながらも一定のオーバーヘッドが課される。また、本発明のＳＲＴＰ＋の予想性能についても説明する。

本発明の第１の実施形態は、パケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法を提供し、この方法は、擬似乱数を生成するための擬似乱数生成器（ＰＲＮＧ）を提供するステップと、ネットワークのエンドポイント１とエンドポイント２の間で、セキュリティ保護された方式によって、ＰＲＮＧ乱数種を交換するステップと、エンドポイント１において、擬似乱数の１つを認証タグとして、ＲＴＰシーケンス番号に基づいて各ＲＴＰパケットに割り当てるステップと、エンドポイント１において、割り当てられた擬似乱数をパケットにそれぞれ添付するステップと、パケットをエンドポイント２に送信するステップと、エンドポイント２において、受信パケットのシーケンス番号に対応する擬似乱数を生成するステップと、エンドポイント２において、生成された擬似乱数を着信ＲＴＰパケットに含まれる認証タグと比較するステップと、生成された擬似乱数と一致する認証タグを有するＲＴＰパケットだけを認証するステップとを含み、さらに、１つまたは複数の先行ＲＴＰパケットが消滅または遅延したために、着信ＲＴＰパケットのシーケンス番号に順序の乱れが生じた場合には、生成される擬似乱数が着信ＲＴＰパケットのシーケンス番号に対応するように、ＰＲＮＧを複数回反復するステップであって、最後に正常に受信されたＲＴＰパケットのシーケンス番号から開始されるステップを含む。

本発明の第２の態様は、パケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法を提供し、この方法は、ネットワークのエンドポイント１において、鍵を選択するステップと、鍵をネットワークのエンドポイント２にセキュリティ保護を施して送信するステップと、パケット中のシーケンス番号とタイムスタンプのハッシュを生成し、ハッシュをパケットと共にエンドポイント２に送信するステップと、エンドポイント２において、前もって受信しておいた鍵を使用して、受信パケットのシーケンス番号とタイムスタンプのハッシュを計算するステップと、受信したハッシュと計算したハッシュとを比較するステップと、受信したハッシュと計算したハッシュとが等しい場合、パケットを承認するステップとを含む。

本発明の第３の実施形態は、パケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法を提供し、この方法は、エンドポイント１において、Ｎ個の順序づけられた乱数を生成するステップと、Ｎ個の乱数を、ＳＲＴＰパケットの暗号化ペイロードの一部として、エンドポイント２に送信するステップと、エンドポイント２において、Ｎ個の乱数を復号し、保存するステップと、エンドポイント１において、Ｎ個の乱数からなる現在の系列に付加される追加の乱数を１個生成して、乱数をＮ＋１個にするステップと、Ｎ＋１個の順序づけられた乱数の最初の１つを平文形式で、残りのＮ個の順序づけられた乱数を暗号形式で、共に現在のパケットに収めて、エンドポイント１からエンドポイント２に送信するステップと、エンドポイント２において、平文形式で受信した乱数を、エンドポイント２に保存されているＮ個の乱数と比較するステップと、平文形式で受信した乱数が、前もって保存されているＮ個の乱数の１つと一致する場合、パケットを承認し、それに伴い、パケット中のＮ個の乱数を復号し、前もって保存されている乱数を、Ｎ個の乱数の現在の組として保存するステップとを含む。

本発明を適用できるさらなる範囲は、以下本明細書で行う詳細な説明から明らかになるであろう。しかし、詳細な説明および具体例は、本発明の好ましい実施形態についてのものであっても、説明のために提示されたに過ぎず、本発明の主旨および範囲内で行える様々な変更および修正が、詳細な説明から当業者には明らかとなるであろうことを理解されたい。

本発明は、以下本明細書で行う詳細な説明および添付の図面からより完全に理解することができよう。添付の図面は、説明のために提示されたに過ぎず、したがって、本発明を限定するものではない。

このセクションでは、ＳＲＴＰ＋の実施形態を３つ提案して説明する。これらの実施形態は、各ＲＴＰパケットの認証タグの生成および検査の方式に関して異なっている。しかし、３つの実施形態はすべて、各パケットにタグを付加する。図３に、ＲＴＰヘッダーのフィールドを示す。ＲＴＰの仕様では、（「Ｘ」と表記された）拡張フィールドが１に設定されていれば、ヘッダー拡張部をもつことが許される。実際のヘッダー拡張部は、元のヘッダーに付加され、拡張部長データと拡張部データ自体から構成される。この第２のロケーションの使用は便利であり、既存のＲＴＰ仕様を簡単に利用できる。しかし、転送メカニズムの中には、帯域利用を最低限に抑えるために、ヘッダーを圧縮するものがあり、そのような場合は、ヘッダー拡張部をもつことは許されない。そのような状況では、図１に示すように、タグをＲＴＰペイロードに、ＳＲＴＰＨＭＡＣタグの直後の位置に添付することができる。

１．秘密擬似乱数系列（実施形態１）
この実施形態では、認証タグは、暗号によってセキュリティ保護された擬似乱数系列中の数である。表１に示すように、各ＲＴＰパケットには、そのシーケンス番号に基づいて、擬似乱数が割り当てられる。各ＲＴＰパケットは、パケットの３２ビット・フィールドに収められたシーケンス番号を有する。アバイヤ社の製品で使用される場合、擬似乱数生成器（ＰＲＮＧ）は、ＦＩＰＳ−１４０を満たしていなければならない。（非常に簡潔であるために）非常に効率の良いＰＲＮＧを始めとして、利用可能なＰＲＮＧが数多く存在する。ＰＲＮＧはセキュリティのために使用されるので、それ自体も「暗号によってセキュリティ保護されて」いる必要がある。連邦情報処理規格は、いくつかのＰＲＮＧを、「暗号によってセキュリティ保護されて」いると認定した。そのような認定されたＰＲＮＧの１つは、図４に示すような、ＳＨＡ１などの暗号ハッシュに基づいている。

擬似乱数生成器（ＰＲＮＧ）に関するさらなる説明は、以下に示す米国標準規格技術研究所（ＮＩＳＴ）の文献中に見つけることができる。
・National Institute for Standards and Technology (NIST), "Security Requirements for Cryptographic Modules," FIPS pub 140-2, http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
・National Institute for Standards and Technology (NIST), "Annex C: Approved Random Number Generators," FIPS pub 140-2 Annex C, http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf
・National Institute for Standards and Technology (NIST), "Digital Signature Standard (DSS)," FIPS pub 186-2, <http://csrc.nist.gov/publications/fips/fips186-2/fips-186-2-channel1.pdf>

ＲＴＰ通信の双方のエンドポイントは、発信パケットの認証タグを生成し、着信パケットのタグを検査するために、各シーケンス番号に対応する擬似乱数を知らなければならない。図５（Ａ）に、２つのエンドポイント間の通信を示す。図５（Ｂ）には、この実施形態のフローチャートを示す。

図５（Ｂ）に示すように、ＲＴＰパケットを送信する前に、ＰＲＮＧ用の乱数種を選択し（ステップＳ１）、セキュリティ保護された方式で交換する（ステップＳ２）。

ＳＲＴＰを使用する場合、ＳＲＴＰ＋ＰＲＮＧ鍵の交換は、ＳＲＴＰ用の鍵のセキュリティ保護を施した交換に便乗して行うことができる。鍵が交換された後、３２ビットのＳＲＴＰ＋認証タグが生成され、各ＲＴＰパケットに添付される（ステップＳ３）。１つのパケットの認証タグが分かっても、後続パケットのタグを生成することはできないので、この認証タグは、平文で送信することができる。

ＳＲＴＰの場合、３２ビットのロールオーバー・カウンタが、シーケンス番号の幅を４８ビットに効果的に拡張する。したがって、表１のシーケンス番号は、丸々４８ビットのシーケンス番号に基づくことができる。しかし、シーケンス番号が実際には１６ビットであると考えても、実用上で混乱が生じることはない。例えば、２０ｍｓに１つの割合でパケットを送信するとしても、シーケンス番号がロールオーバーして、最初から繰り返すようになるまでには、１３１０秒が経過している。

パケットが順序を乱して到着したり、消滅したりした場合、パケットのシーケンス番号は、予想した番号とは異なっている。その場合、正しいシーケンス番号の擬似乱数が計算されるまで、ＰＲＮＧが数回繰り返される。例えば、最後に受信したシーケンス番号が１０００であり、新たに受信したシーケンス番号が１００４である場合、シーケンス番号１００４に対応する擬似乱数を計算するために、ＰＲＮＧを４回繰り返さなければならない。ＰＲＮＧは現在の番号より後の番号しか計算できないので、パケットが実際は順序を乱して到着した場合、シーケンス番号１００１、１００２、１００３の擬似乱数を記憶しておかなければならない（ステップＳ４）。したがって、計算された擬似乱数のスライディング・ウィンドウを維持していなければならない。ステップＳ５で、エンドポイント２において、着信パケットの認証タグが、計算されたタグと比較される。タグが等しい場合（ステップＳ６）、着信パケットは承認される。着信パケットの認証タグが、スライディング・ウィンドウ内の最小シーケンス番号の擬似乱数と一致する場合、スライディング・ウィンドウを前方にシフトさせて、承認パケットをウィンドウから廃棄することができる。

スライディング・ウィンドウのサイズは、使用するメディア符復号器が許容できるシーケンス番号の最大前方スキップに基づくべきである。スライディング・ウィンドウを使用する利点の１つは、受信予定のパケットの擬似乱数をあらかじめ計算しておけるので、認証プロセス中の計算量の多い部分を、パケット受信時点から時間的にずらすことが可能になる点にある。

２．シーケンス番号／タイムスタンプ・ハッシュ（実施形態２）
実施形態１の一代替形態では、先に計算した擬似乱数を記憶しておくためにスライディング・ウィンドウを維持する必要がなくなる。ＰＲＮＧを使用する代わりに、ＲＴＰヘッダー内のシーケンス番号とタイムスタンプを、ＨＭＡＣ−ＳＨＡ１など、暗号によってセキュリティ保護されたハッシュを使用してハッシュして、認証タグを取得する。したがって、各パケットを独立に検査することができる。順序違いのパケットや消滅パケットが、認証プロセスに影響を与えることはない。

図６（Ａ）に、２つのエンドポイント間の通信を示す。図６（Ｂ）から分かるように、この実施形態は、メッセージ認証符号が、ヘッダーとペイロードの全体の代わりに、ヘッダーだけを認証する点を除いて、ＳＲＴＰと同じである。したがって、そのような実行上の節約が、セキュリティ保護された同じハッシュをより短いビット列に適用することによって実現されても、驚くにはあたらない。

特に、図６（Ｂ）には、この実施形態のステップのポイントが示されている。
エンドポイント１において、鍵を選択する（ステップＳ１）。
鍵をセキュリティ保護を施してエンドポイント２に送信する（ステップＳ２）。
パケット内のシーケンス番号とタイムスタンプのハッシュを生成し、パケットと共にエンドポイント２に送信する（ステップＳ３）。
エンドポイント２において、先に受信した鍵を使用して、受信パケットのシーケンス番号とタイムスタンプのハッシュを計算する（ステップＳ４）。
受信したハッシュと計算したハッシュを比較する（ステップＳ５）。
受信したハッシュと計算したハッシュが等しければ、パケットを承認する（ステップＳ６）。

実施形態１と同様に、ＳＲＴＰ＋鍵は、ＳＲＴＰ鍵と一緒に交換することができる。実際、ＳＲＴＰ鍵をそのまま、ＳＲＴＰ＋鍵として使用することさえできる。ＳＲＴＰ＋認証タグは、平文で送信することができる。

３．秘密乱数連鎖（実施形態３）
実施形態１および２はどちらも、擬似乱数の生成またはメッセージ・ダイジェストの計算の際に、ＳＨＡ１に依存している。したがって、これら２つの実施形態で実現される実行上の節約は、少なくとも１つのブロックに関してＳＨＡ１ハッシュ操作を実行する必要性によって制限される。第３の実施形態は、ＳＨＡ１はまったく必要としないが、ＳＲＴＰ暗号化と併せて使用しなければならない。この実施形態では、送信側が、事前に一連の乱数を計算し、１つの数を各パケットの認証タグとして使用する。認証タグは、平文で送信されるが、次のＮ個のパケットのための乱数は、暗号化される（例えば、ＳＲＴＰ暗号化ペイロードに含まれる）。受信側は、ペイロードを復号した後、Ｎ個の乱数を保存する。これらの乱数は、次のＮ個の予想パケットのシーケンス番号に対応しており、認証のために、後続パケットの認証タグと比較される。最初のパケットの認証が可能になる前に、おそらくはＳＲＴＰ鍵交換の間に、最初のＮ個の乱数を受信側に送信しなければならない。図７（Ａ）に、２つのエンドポイント間の通信を示す。
図７（Ｂ）には、以下に示すこの実施形態のステップのポイントが示されている。

エンドポイント１において、Ｎ個の順序づけられた乱数を生成する（ステップＳ１）。
Ｎ個の乱数を、ＳＲＴＰパケットの暗号化ペイロードの一部として、エンドポイント２に送信する（ステップＳ２）。
エンドポイント２において、Ｎ個の乱数を復号し、保存する（ステップＳ３）。
エンドポイント１において、Ｎ個の乱数からなる現在の系列に付加される追加の乱数を１個生成して、乱数をＮ＋１個にする（ステップＳ４）。
Ｎ＋１個の順序づけられた乱数の最初の１つを平文形式で、残りのＮ個の乱数を暗号形式で、共に現在のパケットに収めて、エンドポイント１からエンドポイント２に送信する（ステップＳ５）。
エンドポイント２において、受信した平文の乱数を、エンドポイント２に保存されているＮ個の乱数と比較する（ステップＳ６）。

受信した平文の乱数が、前もって保存されているＮ個の乱数の１つと一致する場合、現在のパケットを承認し、それに伴い、現在のパケット中のＮ個の乱数を復号し、前もって保存されている乱数を、Ｎ個の乱数の現在の組として保存する（ステップＳ７）。

上記のステップ１、ステップ２、およびステップ３は、セッション生成中に１つのセッションにつき１回実行される初期動作に相当し、ステップ４〜ステップ７は、パケットごとに実行されるパケット単位の動作に相当する。

この実施形態の主たる利点は、認証検査で簡単な算術比較しか必要としないため、認証検査のオーバーヘッドが非常に低いことである。しかし、追加のバイトを送信側で暗号化し、受信側で復号する必要がある。ブロック暗号で暗号化する際、最後のブロックに、ブロック・サイズより小さい平文の数ビットが含まれる場合、Ｎ個の乱数を潜ませるために、その未使用ビットを使用することができる。残念ながら、１２８ビットのＡＥＳブロックと共に使用した場合、Ｇ．７１１符号化用のデフォルトの１６０バイトのペイロードに、未使用ビットは残らない。

さらに、これらの暗号化バイトは、ＲＴＰペイロードのサイズを増加させる。さらなる不都合は、各パケットと共にＮ個の乱数の組の全体を送信する必要があることであり、これは非常に冗長性が大きい。１つの可能な緩和策は、乱数の桁数を最小にすることである。真の乱数は、擬似乱数とは違って本当にランダムなので、前の乱数が分かっても予測することができず、そのため、乱数の桁数を非常に小さくすることができる。おそらく、各乱数の桁数を、４ビットほどの小ささにすることができる。また、Ｎの値も、メディア符復号器が許容できるシーケンス番号の最大前方スキップによって制限され得る。

４．本発明の実施形態の性能分析
ＳＲＴＰ＋の３つの実施形態のそれぞれから期待される性能改善について理解するため、図８に示すような複数のシステムにおいて各実施形態を実施した。
図８から分かるように、複数のシステムとは、
（１）Ｌｉｎｕｘ２．４．７−１０を実行する、２５６ＭＢのＲＡＭを備えた１．５ＧＨｚのＰｅｎｔｉｕｍ（登録商標）ＩＶシステム、
（２）Ｌｉｎｕｘ２．４．２０−２０．９を実行する、５１２ＭＢのＲＡＭを備えた８６６ＭＨｚの２−ＣＰＵＰｅｎｔｉｕｍ（登録商標）ＩＩＩシステム、および
（３）４ＧＢのＲＡＭを備えた４５０ＭＨｚの４−ＣＰＵＳｐａｒｃシステムである。

すべてのテスト・プログラムは、単一のＣＰＵで実行し、メモリ・コンテンションは問題としなかった。ＳＨＡ１およびＨＭＡＣ−ＳＨＡ１を実施するため、オープン・ソースのｂｅｅｃｒｙｐｔ−３．１．０パッケージを使用した。

表２に、ＳＲＴＰ＋の３つの実施形態でそれぞれ測定した性能、およびＳＲＴＰの性能を示す。これらの数値は、実施形態１における乱数生成、実施形態２におけるＨＭＡＣ−ＳＨＡ１符号生成、実施形態３における１２８ビット・ブロックのＡＥＳ暗号化、およびＶｏＩＰアプリケーションで一般的な１７２バイトのＲＴＰパケットを用いるＳＲＴＰにおけるＨＭＡＣ−ＳＨＡ１符号生成によって課される、実行時オーバーヘッドの部分に関する性能だけを示している。実際のＶｏＩＰシステムが配備される実際のプラットフォームは、上記のテスト・システムとは異なり得るが、ＳＲＴＰ＋の相対的な性能は、大部分のシステムにおいて、表２に提示する結果に類似している。

表２に示すように、参照番号５、６、７、８は、実施形態（方式）３に関して以下のことを示している。

参照番号５：１２８ビットのＡＥＳブロックの数は、実施形態３で必要な乱数のサイズおよび数に依存する。これらの実験では、４ビットの乱数が３２個あれば十分であると仮定している。

参照番号６：０．４７ｍｓは、鍵が１２８ビットである場合の時間である。鍵が１９２ビットおよび２５６ビットの場合、１．５ＧＨｚのＰｅｎｔｉｕｍ（登録商標）ＩＶで、時間はそれぞれ、０．５６ｍｓおよび０．６６ｍｓになる。

参照番号７：０．８０ｍｓは、鍵が１２８ビットである場合の時間である。鍵が１９２ビットおよび２５６ビットの場合、８６６ＭＨｚのＰｅｎｔｉｕｍ（登録商標）ＩＩＩで、時間はそれぞれ、０．９６ｍｓおよび１．１０ｍｓになる。

参照番号８：２．８３ｍｓは、鍵が１２８ビットである場合の時間である。鍵が１９２ビットおよび２５６ビットの場合、４５０ＭＨｚのＳｐａｒｃで、時間はそれぞれ、３．２３ｍｓおよび３．６２ｍｓになる。

表２からは、様々なことが読み取れる。最も顕著に読み取れることは、３つの実施形態のすべてで、ＳＲＴＰに比べて性能の改善が見られることである。しかし、実際のスピードアップは、実施形態３を除けば、１桁のオーダーより小さい。相対的な数値は、直観的なものである。表３に、各テスト・システムにおいて、５１２ビットのメッセージ・ブロックのＳＨＡ１ダイジェストを計算するのに要した時間を示す。再び表２の数値を見ると、実施形態１は、１つのＳＨＡ１ハッシュを計算するのに時間の大部分を費やしていることが分かる。実施形態２の場合、Ｌ＝ｃｅｉｌ（４／６４）＝１、Ｎ＝Ｌ＋１＝２であり、これは、実施形態２が、２個の５１２ビット・ブロックのＳＨＡ１ダイジェストを計算しなければならず、そのため、実施形態１よりもほぼ２倍の実行時間が必要であることを意味している。１７２バイトＲＴＰパケットのＳＲＴＰの場合、Ｌ＝ｃｅｉｌ（１７２／６４）＝３、Ｎ＝Ｌ＋１＝４である。

予想されるように、ＳＲＴＰの実行時間は、実施形態１の約４倍になる。実施形態３は、他の実施形態よりもはるかに速いが、その大きな理由は、１２８ビットのＡＥＳブロック暗号による暗号化が、５１２ビットのＳＨＡ１ハッシュ操作に比べて、より小さな入力ブロックに対して行われるためである。

ほとんどの場合、ＳＲＴＰ＋の実施形態の１つが、ＳＲＴＰと共に使用される。したがって、表２から、２つのタイプのオーバーヘッドを理解することができる。

第１に、すべての着信パケットが正常に認証される場合には、安定状態のオーバーヘッドが生じる。この場合、全オーバーヘッドは、ＳＲＴＰ＋オーバーヘッドと、さらにＳＲＴＰオーバーヘッドとから成り立っている。例えば、第１の実験システムでは、実施形態１、２、３の安定状態のオーバーヘッドは、それぞれ２６％、６８％、６％である。

第２のタイプのオーバーヘッドは、偽パケットが検出された場合に生じる。サービス妨害攻撃は、連続的に送られる偽パケットを含むことがある。そのようなシナリオでは、ＳＲＴＰ＋が偽パケットを検出し、ＳＲＴＰオーバーヘッドを起こす必要がないようにするので、受信側での全オーバーヘッドは、ＳＲＴＰ＋オーバーヘッドだけになる。

第１の実験システムを再び例にとると、実施形態１、２、３の偽パケット検出のスピードアップは、それぞれ３．８、１．５、１６．５である。

表２において、実施形態１の実行時間は、１６０ビットの鍵に基づいて、乱数を生成したものであることに留意されたい。ＦＩＰＳ１８６−２［８］では、鍵のサイズは１６０から５１２ビットまでとしなければならないと定めている。図８には、１つの擬似乱数を生成するのに必要な時間が、様々な鍵のサイズに対して示されている。鍵のサイズは、４４８ビットになるまで時間に影響しないが、４４８ビットになった途端に２倍になる。このような増加が４４８ビットで生じるのは、ＳＨＡ１が、メッセージに付加される６４ビットのメッセージ長を必要とするためである。したがって、４４８ビットを境に、５１２ビットのブロックを１つ余計に処理する必要が生じる。

本発明の効果
ＳＲＴＰ＋の３つの実施形態は、連続的な偽ＲＴＰパケットに基づく、サービス妨害攻撃に耐えるための技法を提示する。そのような連続的なパケットは、大量のコンピューティング資源を要求して、システムに期待されたサービスを提供させないようにすることができる。ＳＲＴＰ＋の実施形態は、パケットの速やかな認証を可能にすることで、プロセッサの潜在的な負荷を低下させる。

安定状態の動作では、ＳＲＴＰ＋によって、追加のオーバーヘッドが課される。幸いなことに、そのようなオーバーヘッドは、安定状態、すなわち、サービス妨害攻撃に遭遇していない状態の動作において、あまり重荷にならない。一方、偽パケットを検出するためのプロセッサ負荷の低下は、サービスが妨害されている状況において、非常に重要である。

ここまで本発明について説明してきたが、多くの方法によって本発明に変更を施し得ることは明らかであろう。そのような変更は、本発明の主旨および範囲から逸脱しているとは見なされず、当業者にとって明らかなそのような変更はすべて、添付の特許請求の範囲の範囲内に含まれるものとする。

従来のＳＲＴＰパケットの図である。ＨＭＡＣ−ＳＨＡ１を使用したＳＲＴＰ認証タグ生成の図である。本発明のＳＲＴＰ＋認証タグ・ロケーションの図である。ＦＩＰＳ１４０を満たす暗号によってセキュリティ保護された擬似乱数の生成図である。本発明の実施形態１による擬似乱数系列を伝達するＳＲＴＰ＋通信の概略図である。本発明の実施形態１による方法のステップのフローチャートである。本発明の実施形態２によるシーケンス番号／タイムスタンプ・ハッシュを伝達するＳＲＴＰ＋通信の概略図である。本発明の実施形態２による方法のステップのフローチャートである。本発明の実施形態３による秘密乱数連鎖を伝達するＳＲＴＰ＋通信の概略図である。本発明の実施形態３による方法のステップのフローチャートである。実施形態１の方法を用いて擬似乱数を１つ生成する時間を鍵サイズの関数として示した図である。

Claims

パケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法であって、
擬似乱数を生成するための擬似乱数生成器（ＰＲＮＧ）を提供するステップと、
前記ネットワークのエンドポイント１とエンドポイント２の間で、セキュリティ保護された方式によって、ＰＲＮＧ乱数種を交換するステップと、
前記エンドポイント１において、前記擬似乱数の１つを認証タグとして、ＲＴＰシーケンス番号に基づいて各ＲＴＰパケットに割り当てるステップと、
前記エンドポイント１において、前記割り当てられた擬似乱数を前記パケットにそれぞれ添付し、前記パケットを前記エンドポイント２に送信するステップと、
前記エンドポイント２において、受信パケットの前記シーケンス番号に対応する擬似乱数を生成するステップと、
前記エンドポイント２において、前記生成された擬似乱数を前記着信ＲＴＰパケットに含まれる前記認証タグと比較するステップと、
前記生成された擬似乱数と一致する前記認証タグを有する前記ＲＴＰパケットだけを認証するステップと、
１つまたは複数の先行ＲＴＰパケットが消滅または遅延したために、着信ＲＴＰパケットのシーケンス番号に順序の乱れが生じた場合には、生成される擬似乱数が前記着信ＲＴＰパケットの前記シーケンス番号に対応するように、前記ＰＲＮＧを複数回反復するステップであって、最後に正常に受信されたＲＴＰパケットのシーケンス番号から開始されるステップとを含む方法。
正常に受信されたパケットの現在のシーケンス番号を保存するステップをさらに含む、請求項１に記載のパケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法。
前記反復ステップが、まだ受信していない前記ＲＴＰパケットのシーケンス番号に対応する擬似乱数を計算するステップをさらに含む、請求項１に記載のパケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法。
前記擬似乱数を、前記パケットにそれぞれ割り当てられた認証タグとする、請求項１に記載のパケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法。
前記擬似乱数が、暗号ハッシュに基づく、請求項１に記載のパケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法。
前記暗号ハッシュが、ＨＭＡＣ−ＳＨＡ１である、請求項５に記載のパケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法。
前記擬似乱数が、平文として送信され、暗号化を必要としない、請求項１に記載のパケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法。
前記シーケンス番号が、１６ビット長である、請求項１に記載のパケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法。
前記シーケンス番号が、４８ビット長である、請求項１に記載のパケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法。
パケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法であって、
前記ネットワークのエンドポイント１において、鍵を選択するステップと、
前記鍵を前記ネットワークのエンドポイント２にセキュリティ保護を施して送信するステップと、
パケット中のシーケンス番号とタイムスタンプのハッシュを生成し、認証タグになる前記ハッシュを、前記パケットと共に前記エンドポイント２に送信するステップと、
前記エンドポイント２において、前もって受信しておいた前記鍵を使用して、受信パケットのシーケンス番号とタイムスタンプのハッシュを計算するステップと、
前記受信したハッシュと前記計算したハッシュとを比較するステップと、
前記受信したハッシュと前記計算したハッシュとが等しい場合、前記受信パケットを承認するステップとを含む方法。
前記シーケンス番号と前記タイムスタンプが、暗号によってセキュリティ保護されたハッシュを使用してハッシュされる、請求項１０に記載のパケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法。
前記暗号によってセキュリティ保護されたハッシュが、ＨＭＡＣ−ＳＨＡ１である、請求項１１に記載のパケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法。
前記シーケンス番号が、１６ビット長である、請求項１０に記載のパケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法。
前記シーケンス番号が、４８ビット長である、請求項１０に記載のパケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法。
パケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法であって、
エンドポイント１において、Ｎ個の順序づけられた乱数を生成するステップと、
前記Ｎ個の乱数を、ＳＲＴＰパケットの暗号化ペイロードの一部として、エンドポイント２に送信するステップと、
前記エンドポイント２において、前記Ｎ個の乱数を復号し、保存するステップと、
前記エンドポイント１において、前記Ｎ個の乱数からなる現在の系列に付加される追加の乱数を１個生成して、乱数をＮ＋１個にするステップと、
前記Ｎ＋１個の順序づけられた乱数の最初の１つを平文形式で、残りのＮ個の順序づけられた乱数を暗号形式で、共に現在のパケットに収めて、前記エンドポイント１から前記エンドポイント２に送信するステップと、
前記エンドポイント２において、平文形式で受信した前記乱数を、前記エンドポイント２に保存されている前記Ｎ個の乱数と比較するステップと、
平文形式で受信した前記乱数が、前記前もって保存されているＮ個の乱数の１つと一致する場合、前記パケットを承認し、それに伴い、前記パケット中の前記Ｎ個の乱数を復号し、前記前もって保存されている乱数を、前記Ｎ個の乱数の現在の組として保存するステップとを含む方法。
前記パケットが、ＶｏＩＰパケットである、請求項１５に記載のパケット・データ・ネットワークにおけるリアルタイム転送プロトコル（ＲＴＰ）パケット認証のための方法。