JP2009508390A - セキュアで帯域効率の良い暗号化同期方法 - Google Patents

Abstract

データパケットの暗号化同期のための方法。
パケットシーケンス番号の関数が予め定めた値と等しくなった際に、データパケットにロールオーバカウンタ（ＲＯＣ）値が周期的に付加され、送信される。
ＲＯＣはデータパケットの暗号化変換を効率的に同期させる。
開示される方法は様々な伝送プロトコルに対して広く適用可能であるが、インターネット技術標準化委員会(IETF)標準技術案(RFC)3711に規定されるセキュアリアルタイム伝送プロトコル(SRTP)を用いてデータパケットが受信機へ送信されるシステムに対して特に順応性がある。

Description

関連出願への相互参照
本出願は2005年9月9日出願の米国仮出願第60/715,873号の利益を享受するものであり、当該仮出願の開示内容は本明細書中に含まれているものとする。

本発明は全体として通信分野に関し、特にはセキュア通信の分野に関する。

セキュリティプロトコル又は暗号化プロトコルは、セキュリティ関連機能を実行するとともに、暗号化方法を適用する抽象的又は具体的なプロトコルである。暗号化プロトコルはセキュアなアプリケーションレベルデータ伝送に広く用いられている。暗号化プロトコルには通常、以下の見地のうち、少なくともいくつかが組み込まれている。鍵の合意(agreement)又は確立、エンティテイ認証、対称暗号化及びメッセージ認証マテリアルの構築、セキュアなアプリケーションレベルデータ伝送、及び否認防止(non-repudiation)方法。

信頼できない伝送機構上で稼働する暗号化プロトコルは、例えばパケット損失やパケットの順番違い(reordering)などに起因して、送信機及び受信機を同期化するための手段を必要とする。最低レベルにおいて、受信機はデータパケットを””理解可能(intelligible)な”データに正しく組み立てることが可能でなくてはならない。例えば、受信機が再送要求できるためには、データパケットが欠落しているかどうかを受信機が分からなくてはならない。同期は一般に、シーケンス番号を各パケットに付加するか、既存のシーケンス番号を用いることで実現される。そのようなシーケンス番号は、正当な鍵とともに暗号化アルゴリズムに入力され、パケット単位での同期が得られる。しかしながら、データ量、つまり必要な帯域を増加させないので、後者の手法の方が好ましい。

暗号化変換の特性により、ある１つの鍵に対して同じシーケンス番号が２度使用されることはない。しかしながら、従前の内蔵カウンタは通常１６ビットに過ぎない。そのため、高速な通信においては、１６ビットのシーケンス番号はほんの数秒で一巡(wrap)してしまうであろう。これは、結果として頻繁なリキー(re-keying)を必要とするので、非効率である。例えば、１６ビットのシーケンス番号を用いると、２¹⁶パケットごとに同じシーケンス番号が含まれることになり、受信機はこのような同じシーケンス番号を含んだパケットを区別することができない。

この問題を回避するため、ロールオーバカウンタ(ROC)を用いて「拡張」シーケンス番号を規定することができる。１６ビットのシーケンス番号(sequence_number)に対し、拡張シーケンス番号(EXTENDED_SEQ)はseqence_number+ROC*2¹⁶に等しくすることができる。このようなシステムにおいては、sequence_numberがモジュロ２¹⁶に達して「一巡」するごとに、送信機側及び受信機側でＲＯＣを更新しなくてはならない。しかし、ＲＯＣの値は通常パケットで搬送されず、送信機及び受信機によって暗黙的に維持されている。しかしながら、パケットの順序違い／損失が２¹⁵を超えない限り、試行錯誤的な方法に基づいてＲＯＣの値を推定して同期を維持可能であることを示すことができる。例えば、インターネット技術標準化委員会(IETF)標準仕様案(RFC)3711、「セキュアなリアルタイム伝送プロトコル」（「ＳＲＴＰ」）を参照されたい。

しかし、（例えば、ＳＲＴＰが用いられる、３ＧＰＰマルチキャスト及び同報サービス（ＭＢＭＳ）のように）、複数のユーザが継続中のセッションに参加したり離脱したりするかもしれない一部のアプリケーションにおいては、各ユーザに現在のＲＯＣ値を与える必要があること、その情報を複数のユーザにどのようにして正確に転送するかが容易でないことから、この「拡張」手法は不十分である。ＳＲＴＰは現時点では帯域内信号方式(inband signaling)を用いてＲＯＣ値を提供するための機構を提供していない。しかしながら、鍵管理プロトコル（例えば、IETF RFC 3830に規定されるマルチメディアインターネットキーイング（「ＭＩＫＥＹ」））を用いて、帯域外(out-of-band)で値を通知することは可能である。この手法を用いることの問題は、鍵管理が通常は独立したプロセスによって実行されること、通常はユーザがセッションに参加することを決定する遙か前に鍵管理を実行されることである。この場合、鍵管理が実行された時点で用いられていたＲＯＣの値は、ユーザがセッションに参加する際には失効しているであろう。

鍵管理が事実上ＳＲＴＰストリーム処理と同期して実行されるとしても、ＳＲＴＰが拡張シーケンス番号を推定する方法によって、ＲＯＣ値が不正確となる可能性がある。例えば、メディア（ＳＲＴＰ）シーケンス番号がちょうど一巡した（例えば、0x0000に等しい）ところであり、その時点で鍵管理がＲＯＣ値を読んだと仮定する。
次に、ＲＯＣ値がユーザ（受信機）に伝送され、ユーザがＲＯＣ値を読んで参照用に保存する。パケットはメディアサーバとユーザの間の経路上で順序が入れ替わりうるので、ユーザが受信する最初のメディア（ＳＲＴＰ）パケットは、例えばシーケンス番号0xFFFFを有する、遅延したパケットであるかもしれない。この状況において、ＳＲＴＰはこの（遅延した）パケットを、１つ大きいＲＯＣ値を用いて処理するであろう。さらに、次に受信するＳＲＴＰパケットは、シーケンス番号0x0000を有する可能性が高い。この状況において、ＳＲＴＰはシーケンス番号が一巡したと推測又は予測し、自身のＲＯＣ値を１増加させるであろう。これは同期外れの原因となりうる。多数のパケット損失がある状況下や、あるいはユーザがセッションを離れ、ＲＯＣが少なくとも１巡するような長期間経過後に再度参加する場合、問題が再び生じる。

従って、セキュアで帯域効率の良い暗号化同期のための方法が必要とされている。
好ましくは、そのような方法は、帯域の効率よい使用と、不当な操作からの保護を実現するであろう。

従来技術の問題点を解決するため、本発明はセキュアで帯域効率の良い暗号化同期方法を開示する。概要を述べれば、パケットシーケンス番号の関数が予め定めた値と等しくなると、データパケットにロールオーバカウンタ（ＲＯＣ）値が周期的に付加され、送信される。ＲＯＣはデータパケットの暗号化変換を効率的に同期させる。

以下、より詳細に説明する例示的な実施形態によれば、受信機へ送信するためのデータパケットが送信機で受信され、方法は特に、データパケットがインターネット技術標準化委員会(IETF)標準仕様案(RFC)3711に規定されるセキュアリアルタイム伝送プロトコル（ＳＲＴＰ）を用いて受信機へ送信されるシステムにおいて用いるために順応性がある。上述のRFC3711の内容は、本明細書に含まれるものとする。送信機はまず、データパケットに対するパケットシーケンス番号がＲによって均等に割り切れるかどうかを判別する（ここで、Ｒは事前に送信機及び受信機によって合意されている整数である）。送信機及び受信機は、Ｒの値を選択するため、例えば、帯域外で通信することが可能である。このような目的のための好適なプロトコルには、セッション開始プロトコル（ＳＩＰ）、セキュアリアルタイム伝送プロトコル（ＳＲＴＰ）及びマルチメディアインターネットキーイング（ＭＩＫＥＹ）が含まれる。

パケットシーケンス番号がＲで均等に割り切れるならば、送信機は符号を算出すると共にデータパケットに付加する。ここで、符号はデータパケットに関連付けされた認証キーと送信機ロールオーバカウンタ（ＲＯＣ）値の関数である。送信機ＲＯＣ値は、送信機内のシーケンス番号カウンタが一巡する度に増加される送信機内のカウンタに対応する。送信機はまた、送信機ＲＯＣ値をデータパケットに付加し、そのデータパケットを受信機へ送信する。しかしながら、パケットシーケンス番号がＲで均等に割り切れない場合、送信機は送信機ＲＯＣ値を付加することなく、データパケットを単に送信する。

受信時、受信機はデータパケットに送信機ＲＯＣ値が付加されているかどうかを判別する。送信機ＲＯＣ値の存在は、そのパケットシーケンス番号がＲで均等に割り切れる場合に示される。データパケットが送信機ＲＯＣ値を含んでいない場合、受信機は、受信機が局所的に維持しているＲＯＣ値に基づいて推定されたＲＯＣ値を用い、パケットセキュリティ処理を実行する。データパケットが送信機ＲＯＣ値を含んでいる場合、送信機は受信機ＲＯＣ値（又はＲＯＣ値の推定値）ではなく、送信機ＲＯＣ値を用いてパケットセキュリティ処理を実行する。このセキュリティ処理の一部として、データパケットの完全性(integrity)が判別される。データパケットの完全性が確認されない場合、そのデータパケットは廃棄され、それ以上処理されない。一方、データパケットの完全性が確認されれば、受信機ＲＯＣ値へ送信機ＲＯＣ値を設定する。

以下に続く例示的な実施形態の詳細な説明を本技術分野に属する当業者がより良く理解できるように、本発明の原理について幾分大まかに要点を述べてきた。本技術分野に属する当業者は、開示される概念及び例示的な実施形態を、本発明と同じ目的を実現するための他の構成及び方法を設計又は変更するための基礎として容易に利用可能であることを理解するであろう。本技術分野に属する当業者はまたそのような等価構成が、特許請求の範囲によって規定される本発明の最も広い形態の精神及び範囲から逸脱しないことも理解すべきである。

本発明の特徴及び機能を説明するため、以下、添付図面とともに詳細な説明を行う。
図１は、本発明の原理に従ったセキュアで帯域効率の良い暗号化同期のためのシステム及びシステムにおける方法を説明する図である。システムは送信機１０１及び受信機１０２を備え、これらはいずれも以下に記載される原理に従った所定の動作を実行するように機能する。ここでは、インターネット技術標準化委員会(IETF)標準仕様案(RFC)3711に規定されるセキュアリアルタイム伝送プロトコル（ＳＲＴＰ）を用いてデータパケットが受信機へ送信される例示的なシステムに関して暗号化同期方法を説明する。しかし、本技術分野に属する当業者は、本発明による方法が他の伝送プロトコルに基づくシステムに対して広く適用可能であること、（もし必要ならば）そのような他のプロトコルについて必要となる適応について理解するであろう。

本発明の原理をＳＲＴＰベースのシステムにおいて実施するため、メッセージ認証アルゴリズム（本明細書では拡張メッセージ認証符号(XMAC)と呼ぶ）をＳＲＴＰフレームワークに追加することができる。ＸＭＡＣは例えば、インターネット技術標準化委員会(IETF)ハッシュベースメッセージ認証符号(HMAC)又は他の任意のセキュアＭＡＣに基づくことができる。以下の説明から本技術分野に属する当業者が理解するであろうように、ＳＲＴＰフレームワークの観点からすると、ＸＭＡＣは他の任意のＭＡＣアルゴリズムと本質的に同様に機能する。しかし、ＸＭＡＣは、認証鍵に加えてパラメータＲ（０〜２¹⁶の範囲の整数）を含む。送信機１０１及び受信機１０２は、ＭＡＣ及びＲの値について、例えば、本技術分野で既知であるような帯域外信号方式(out-of-band signalling)を用いて合意することが可能である。このような目的のための好適なプロトコルには、セッション開始プロトコル（ＳＩＰ）、セキュアリアルタイム伝送プロトコル（ＳＲＴＰ）及びマルチメディアインターネットキーイング（ＭＩＫＥＹ）が含まれる。

本方法によれば、受信機１０２に送信するため、データパケットが送信機１０１で受信される（ステップ１０３）。次に（ステップ１０４）、完全性変換(integrity transform)を除くＳＲＴＰ処理がデータパケットに行われる。このステップはデータ保護（すなわち、暗号化及び完全性保護）に用いる鍵を取得するステップ及び、完全性保護を適用すべき点までデータパケットを処理するステップ（例えば、何らかのＳＲＴＰ暗号化が、このステップの間に実行されるべきであろう）とを含む。

続く複数のステップでは、ヘッダ及びペイロードを含むデータパケットについてのＸＭＡＣ完全性保護を構成する。最初に（ステップ１０５）、パケットヘッダ内に存在するデータパケットのシーケンス番号(sequence_number)が、Ｒで均等に割り切れるか（すなわち、０ mod Ｒか）が判別される。パケットシーケンス番号がＲで均等に割り切れなければ、そのデータパケットには一切のＭＡＣタグは付加されず、そのデータパケットの処理はステップ１０８へ移行し、データパケットのＳＲＴＰ処理が送信前に完了する（ステップ１０９）。パケットシーケンス番号がＲで均等に割り切れれば、そのデータパケットに対するＭＡＣタグが算出される。

ステップ１０６で、ＭＡＣタグが算出され、そのデータパケットに付加される。ＭＡＣは、そのデータパケットに関連付けられているＳＲＴＰ認証鍵と送信機ロールオーバカウンタ（ＲＯＣ）値の関数であり、定型的にはHMAC(key, RTP_packet || ROC)と表現される。送信機ＲＯＣ値は、送信機内のシーケンス番号カウンタが一巡する度に増加される送信機内のカウンタに対応する。次に（ステップ１０７）、送信機ＲＯＣ値がさらにデータパケットに付加される。すなわち、この時点でデータパケットには、HMAC(key, RTP_packet || ROC) || ROCが付加されている。ステップ１０６及び１０７は、ＭＡＣ値によって完全性が保護された送信機ＲＯＣ値を、Ｒ番目ごとのパケットに付加する効果を有する。MAC（すなわち、RTP_packet || ROC）への入力は、ＳＲＴＰフレームワークによってこのように自動的に（RFC3711に従って）フォーマットされ、入力として提供される。本技術分野に属する当業者は、送信機ＲＯＣ値がパケットペイロードの一部としては送信されず、ＭＡＣタグの一部として送信されることに気付くであろう。すなわち、HMAC(key, RTP_packet || ROC) || ROCは、ＸＭＡＣの出力認証タグと見なすことができる。

最後に、Ｒで均等に割り切れないシーケンス番号を有するデータパケットと同様に、データパケットの処理がステップ１０８において引き続いて行われ、データパケットのＳＲＴＰ処理が、受信機１０２への送信（ステップ１０９）前に完了する。本技術分野に属する当業者は、受信機１０２において実施される処理がステップ１１０から開始しても、送信機１０１と受信機１０２の動作が非同期であることを理解するべきである。

データパケットを受信すると（ステップ１１０）、ＳＲＴＰ処理が、ＳＲＴＰ鍵導出(key derivation)の前まで実行される。次に（ステップ１１２）、送信機ロールオーバカウンタ（ＲＯＣ）値がデータパケットに付加されているかどうかが判別される。データパケットに付加されているＸＭＡＣ並びに送信機ＲＯＣ値の存在は、パケットシーケンス番号がＲで均等に割り切れる（即ち、sequence_number=0 mod R）場合に示される。

データパケットに何らのＲＯＣ／ＸＭＡＣも付加されていなければ、処理はステップ１２１へ移り、従前のＲＯＣ推定を用いた標準的なＳＲＴＰ鍵導出が実行される。このような場合、受信機１０２は自身の局所的に保存したＲＯＣ値(ROC_L)、通常は直前のパケットに関連付けられたＲＯＣ値、を考慮する。そして受信機は、いま受信したデータパケットのシーケンス番号(SEQ)と、やはり受信機が追跡している以前受信したシーケンス番号の最大値（S_L)とを調べる。これら３つの値(ROC_L,SEQ及びS_L)を用い、受信機は、そのデータパケットが送信された時点で送信機が使用したＲＯＣ値を推定することができる。これは、IETF RFC3711のApendixにおいて「インデックス推定」として記載されているような、様々な方法で実現することが可能である。一例として、現在のROC_L値が”ｘ”、S_L値が３(0x0003)、受信したSEQが0xffffであるとすると、２つのパケットの受信の間にSEQが「一巡」しているため、受信機は現在のデータパケットがROC=ROC_L-1（即ち、x-1）に対応する、（４「単位」時間分）遅延したパケットと推定するだろう。（本技術分野に属する当業者は、SEQ=0xffffの後、次のSEQは一巡して次のパケットがSEQ=0x0000等を有するであろうことを理解するだろう。）もちろん、パケットが本当にそのROC_L値に対応し、（２¹⁶−３）の連続したパケットが損失しているということも実際にはありうるだろう。しかし、そのような状態は起こりにくいので、受信機は「最尤」推定法を用いると言うことができる。すなわち、受信機は、最小量の損失／順序違い／遅延が発生しているという仮定の下で、最も可能性の高いＲＯＣを選択する。

データパケットが送信機ＲＯＣ値を含んでいる場合（ステップ１１２）、受信機ＲＯＣ値ではなく送信機ＲＯＣ値を用いてＳＲＴＰ鍵導出が実行される（ステップ１１３）。次に（ステップ１１４）、データパケットの完全性が判別される。これは、導出された鍵を用い、パケットに付加されたＸＭＡＣを（特に送信機ＲＯＣ値が正しいことについて）チェックし、データが壊れたり改ざんされたりしていないかを確認することにより実施可能である。例えば、ＸＭＡＣ（即ち、RFC3711で規定されるようなＳＲＴＰパケットの認証された部分）へ入力されるデータとしてＳＲＴＰが供給するデータ値を「MAC_INPUT」とし、やはりＳＲＴＰにより入力として与えられる受信タグをｔ’とする。次に、t=HMAC(key, MAC_INPUT || t'{4})を算出し、それをパケットに含まれるものとしての値t'[4]と比較する。ここで、X[n]はＸの最も右からｎバイトを除くサブストリングを、X{n}はＸの最も右からｎバイトを表す。tとt'[4]の値が等しいときのみ、ＸＭＡＣが正当であると検証される。

データパケットの完全性が確認できない場合（ステップ１１５）、そのデータパケットは破棄される（ステップ１１６）。一方、データパケットの完全性が確認されたら（ステップ１１５）、そのデータパケットに含まれている送信機ＲＯＣ値を受信機ＲＯＣ値として設定する（ステップ１１７）。これにより、送信機１０１０と受信機１０２のＲＯＣ値の同期が取られる。次に、ステップ１１８で、送信機ＲＯＣ値及びＸＭＡＣがデータパケットから除去され、その後データパケットに対するＳＲＴＰ処理（例えば暗号復号化）が完了する（ステップ１１９）。最後に、データパケットはアプリケーションへ出力可能となる（ステップ１２０）。

上述したものの代替実施形態において、sequence_number=0 mod Rを有する全てのデータパケットがデータパケットについて算出されたＭＡＣとＲＯＣを搬送するが、Ｒ番目ごとのタグにのみＲＯＣ値が含まれるようにしてもよい。つまり、送信機ＲＯＣ値はＭＡＣタグ算出の入力において常時用いられるが、送信機ＲＯＣ値はＲ番目ごとのパケットについてのＭＡＣ出力の一部を構成するだけである。この実施形態はセッション内の全データパケットの完全性を常時保護しなくてはならない際に利用可能である。

ＳＲＴＰプロトコルに通じた本技術分野に属する当業者は、ここで開示したＲＯＣ同期を実装するために必要となるＳＲＴＰフレームワークへの変更が、鍵導出用に局所受信機ＲＯＣ値ではなく受信した送信機ＲＯＣ値を利用することだけであることを理解するだろう。他の全ての動作はＸＭＡＣ変換によって内部的に処理可能であるので、ＳＲＴＰプロトコルの観点からは「ブラックボックス」と見なすことが可能である。本技術分野に属する当業者はさらに、上述の説明が拡張sequence_numberをどのように伝送しうるかについてのみ示しているけれども、ここで開示される原理を他の形式の同期データを搬送するために適合可能であることに気付くであろう。同様に、同期データをＭＡＣタグの一部として変換せずに、データパケットの他の場所（例えば、キーインジケータ、ペイロード、パケットヘッダ等の一部）の内部で伝送しても良い。

他の代替実施形態において、データパケットにＲＯＣを含めるかどうかの決定を、Ｒで均等に割り切れるかどうか以外の方法を用いて行うこともできる。一般に、シーケンス番号を集合{0, 1}にマッピングする任意の関数をＦとする。関数(F)はまず送信側と受信側とで一致させられる。送信側（及び受信側）は、あるパケットのシーケンス番号(s)に関数Ｆを適用し、F(s)=1の時のみＲＯＣ情報を付加する。上述の例では、ｓがＲで割り切れる場合のみF(s)が１となる。

上述の説明から、本発明が従来技術に対して顕著な利点を提供することが理解されるであろう。１番目に、ＳＲＴＰのような既存のプロトコルに最小の変更を加えるだけで、ＲＯＣ値の再同期手段を提供する。２番目に、Ｒ番目ごとのデータパケットのみが追加のオーバヘッドを有することになるので、Ｒパラメータの値を適切に設定することによって帯域を節約することができる。さらに、送信機ＲＯＣ値はＭＡＣによって保護されるため、セキュアに伝送され、ＤｏＳ(Denial of Service)攻撃を回避することができる。また、どのデータパケットが再同期情報（即ち送信機ＲＯＣ値）を含んでいるかを、「フラグ」や他のオーバヘッドを用いずに、受信機が容易に知ることができる。

本発明の原理に従ったセキュアで帯域効率の良い暗号化同期のためのシステム及びシステムにおける方法を説明する図である。

Claims (16)

1. インターネット技術標準化委員会(IETF)勧告案(RFC)３７１１において規定されるセキュアリアルタイム伝送プロトコル(SRTP)を用いてデータパケットが受信機へ送信される際に、前記データパケットの暗号化同期を行うために送信機で実施される方法であって、
   送信用のデータパケットを受信するステップと、
   完全性変換以外のＳＲＴＰ処理を前記データパケットに実行するステップと、
   前記データパケットに対するパケットシーケンス番号が、事前に前記送信機及び前記受信機によって合意がとれている整数Ｒによって均等に割り切れるかどうかを判別するステップと、
   前記パケットシーケンス番号がＲで均等に割り切れない場合に、
   前記データパケットに対するＳＲＴＰ処理を完了させるステップと、
   前記データパケットを前記受信機へ送信するステップと、
   前記パケットシーケンス番号がＲで均等に割り切れる場合に、
   前記データパケットに関連付けられたＳＲＴＰ鍵と送信機ロールオーバカウンタ（ＲＯＣ）値の関数であるメッセージ認証符号（ＭＡＣ）を算出し、前記データパケットに付加するステップであり、前記送信機ＲＯＣ値は、前記送信機内のシーケンス番号カウンタが一巡するごとに増やされる前記送信機内のカウンタに対応し、
   前記送信機ＲＯＣ値を前記データパケットに付加するステップと、
   前記データパケットに対するＳＲＴＰ処理を完了させるステップと、
   前記データパケットを前記受信機へ送信するステップと、
   を有することを特徴とする方法。
2. 前記データパケットにＳＲＴＰ処理を実行するステップが、前記データパケットのデータ保護用の１つ又は複数の鍵を導出するステップを含むことを特徴とする請求項１記載の方法。
3. 前記送信機がＲの値を選択するため、前記受信機と帯域外通信するステップをさらに有することを特徴とする請求項１記載の方法。
4. 前記シーケンス番号カウンタが１６ビットからなることを特徴とする請求項１記載の方法。
5. 前記Ｒが１から２¹⁶の範囲であることを特徴とする請求項４記載の方法。
6. 前記送信機及び前記受信機が前記Ｒの値について、
   セッション開始プロトコル(SIP)、
   セキュアリアルタイム伝送プロトコル(SRTP)、及び
   マルチメディアインターネットキーイング(MIKEY)
   のグループから選択されたプロトコルを用いて合意することを特徴とする請求項３記載の方法。
7. インターネット技術標準化委員会(IETF)勧告案(RFC)３７１１において規定されるセキュアリアルタイム伝送プロトコル(SRTP)を用いてデータパケットが送信機から受信される際に、前記データパケットの暗号化同期を行うために受信機で実施される方法であって、
   前記送信機からデータパケットを受信するステップと、
   ＳＲＴＰ鍵導出以外のＳＲＴＰ処理を前記データパケットに実行するステップと、
   前記データパケットに送信機ロールオーバカウンタ（ＲＯＣ）値が付加されているか判別するステップであり、前記送信機ＲＯＣ値の存在は、パケットシーケンス番号が前記送信機と前記受信機とが事前に合意した整数Ｒで均等に割り切れる場合に示され、
   前記データパケットが送信機ＲＯＣ値を含んでいない場合、
   従前のＲＯＣ推定を用いた標準的なＳＲＴＰ鍵導出を実行するステップと、
   前記データパケットが送信機ＲＯＣ値を含んでいる場合、
   受信機ＲＯＣ値ではなく前記送信機ＲＯＣ値を用いてＳＲＴＰ鍵導出を実行するステップと、
   前記データパケットの完全性を判別するステップと、
   前記データパケットの完全性が確認できない場合、前記データパケットを破棄するステップと、
   前記データパケットの完全性が確認された場合、
   前記受信機ＲＯＣ値に、前記データパケットに含まれる前記送信機ＲＯＣ値を設定するステップと、
   前記送信機ＲＯＣ値及びメッセージ認証符号（ＭＡＣ）を前記データパケットから除去するステップと、
   前記データパケットに対するＳＲＴＰ処理を完了させるステップと、
   を有することを特徴とする方法。
8. 前記データパケットの完全性を判別するステップが、前記ＭＡＣが正当であることを前記送信機ＲＯＣ値を用いて導出されたＳＲＴＰ鍵を用いて判別するステップを含むことを特徴とする請求項７記載の方法。
9. 前記受信機がＲの値を選択するため、前記送信機と帯域外通信するステップをさらに有することを特徴とする請求項７記載の方法。
10. 前記Ｒが１から２¹⁶の範囲であることを特徴とする請求項７記載の方法。
11. 前記送信機及び前記受信機が前記Ｒの値について、
    セッション開始プロトコル(SIP)、
    セキュアリアルタイム伝送プロトコル(SRTP)、及び
    マルチメディアインターネットキーイング(MIKEY)、
    のグループから選択されたプロトコルを用いて合意することを特徴とする請求項９記載の方法。
12. データパケットの暗号化同期方法であって、
    送信機において、受信機へ送信するためのデータパケットであって、パケットシーケンス番号(s)を含んだデータパケットを受信するステップと、
    前記送信機及び前記受信機によって事前に合意した、前記パケットシーケンス番号の関数F(s)が、予め定められた値に等しいかどうかを判別するステップと、
    前記F(s)が前記予め定められた値に等しい場合、
    前記データパケットに関連付けられた認証鍵と送信機ロールオーバカウンタ（ＲＯＣ）値の関数である符号を算出及び前記データパケットに付加するステップであり、前記送信機ＲＯＣ値は、前記送信機内のシーケンス番号カウンタが一巡するごとに増やされる前記送信機内のカウンタに対応し、
    前記送信機ＲＯＣ値を前記データパケットに付加するステップと、
    前記データパケットを前記受信機へ送信するステップと、
    前記F(s)が前記予め定められた値に等しくない場合、
    前記送信機ＲＯＣ値を付加せずに前記データパケットを前記受信機に送信するステップと、
    前記受信機で前記データパケットを受信するステップと、
    前記送信機ＲＯＣ値が前記データパケットに付加されているかを判別するステップであり、F(s)が前記予め定められた値に等しい場合に前記送信機ＲＯＣ値の存在が示され、
    前記データパケットが送信機ＲＯＣ値を含んでいる場合、
    受信機ＲＯＣ値ではなく前記送信機ＲＯＣ値を用いてセキュリティ処理を実行するステップであって、
    前記データパケットの完全性を判別するステップと、
    前記データパケットの完全性が確認できない場合、前記データパケットを破棄するステップと、
    前記データパケットの完全性が確認された場合、前記受信機ＲＯＣ値に、前記送信機ＲＯＣ値を設定するステップと、
    前記データパケットが送信機ＲＯＣ値を含んでいない場合、
    前記受信機ＲＯＣ値又は前記ＲＯＣ値の推定値を用いてセキュリティ処理を実行するステップとを含む、セキュリティ処理を実行するステップ、
    とを有することを特徴とする方法。
13. 前記送信機が、F(s)を選択するため、前記受信機と帯域外通信するステップをさらに有することを特徴とする請求項１２記載の方法。
14. 前記シーケンス番号カウンタが１６ビットからなることを特徴とする請求項１２記載の方法。
15. F(s)=１であることを特徴とする請求項１２記載の方法。
16. 前記送信機及び前記受信機が前記F(s)について、以下のグループから選択されたプロトコルを用いて合意することを特徴とする請求項１２記載の方法。
    セッション開始プロトコル(SIP)、
    セキュアリアルタイム伝送プロトコル(SRTP)、及び
    マルチメディアインターネットキーイング(MIKEY)。

Images