メッセージデータの非順次着信に対する許容度を有するメッセージ完全性のための処理方法
本発明の１つの例示的な実施形態が、送信のためのアプリケーションパケットを処理するための方法を開示し、このアプリケーションパケットを複数のセグメントに分割し、第１の擬似ランダムビットを作成し、および、この複数のセグメントのそれぞれと、この複数のセグメントのそれぞれに関連する第１の擬似ランダムビットの諸部分とに基づいて、部分的タグを生成することを含む。この方法は、アプリケーションパケットの最後のセグメントに関連する最後の部分的タグを含め、部分的タグを組み合わせて、蓄積されたタグを作成し、この蓄積されたタグと、第２の擬似ランダムビットとに基づいて、認証タグを生成し、この認証タグを格納し、およびこの認証タグを含む複数のセグメントを送信することをさらに含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、米国法典第３５編１１９条（ｅ）（２）の下で、全体が組み込まれている開示である、２００６年１０月２３日に出願した仮出願第６０／８５３，６４６号の優先権を主張するものである。
【０００２】
本発明は、送信のためにアプリケーションパケットを処理するための方法に関する。
【背景技術】
【０００３】
暗号化とメッセージ認証／完全性の両方が、ワイヤレス無線インタフェースを介してセキュリティをもたらすのに必要とされる。メッセージ暗号化が、メッセージのプライバシーを保護するのに対して、メッセージ認証は、このメッセージを不正操作から保護する。
【０００４】
メッセージ認証プロセスにおいて、秘密鍵およびメッセージ認証アルゴリズムを使用する送信側が、メッセージに付加される短いタグを計算する。また、受信側も、その秘密鍵の知識に基づいて、受信されたメッセージに関するタグを計算し、この計算されたタグを、受信されたタグと比較する。これらのタグが同一である場合、受信側は、そのメッセージを受け入れ、同一でない場合、そのメッセージは、破棄される。
【０００５】
既存のメッセージ認証アルゴリズム、例えば、鍵付きＨＭＡＣ−ＳＨＡ（Ｈａｓｈ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ−Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ）およびＡＥＳ−ＣＢＣ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ−Ｃｉｐｈｅｒ Ａｌｇｏｒｉｔｈｍ ｉｎ Ｃｉｐｈｅｒ Ｂｌｏｃｋ Ｃｈａｉｎｉｎｇ）は、逐次演算であり、ビットが、送信された順序で処理されることを要求するため、アウトオブオーダーパケット処理を許さない。このため、メッセージ認証の従来のアプローチは、データをＲＡＭに送り、ＣＰ（中央プロセッサ）にデータパケットを並べ替えさせて、アプリケーションパケット（メッセージ）を再組み立てさせ、このアプリケーションパケットを、メッセージ認証を行うべきハードウェアに送らなければならない。このことにより、バス上のトラフィックが相当に増大し、パケット処理の際の待ち時間が相当に増す可能性がある。
【０００６】
さらに、既存のメッセージ認証アルゴリズムは、一度にブロック単位に対して作用する。その結果、ブロックレベルアルゴリズムは、非ブロック境界で終わるメッセージセグメントに対して作用することが不可能である。メッセージ認証タグ検証を実行することを始める前に、すべてのメッセージセグメントからアプリケーションパケット全体を再組み立てすることが必要である。
【発明の概要】
【課題を解決するための手段】
【０００７】
本発明の例示的な実施形態においては、送信のためにアプリケーションパケットを処理するための方法が、このアプリケーションパケットを複数のセグメントに分割し、第１の擬似ランダムビットを作成し、および、この複数のセグメントのそれぞれと、この複数のセグメントのそれぞれに関連する第１の擬似ランダムビットの諸部分とに基づいて、部分的タグを生成することを含む。この方法は、アプリケーションパケットの最後のセグメントに関連する最後の部分的タグを含め、部分的タグを組み合わせて、蓄積されたタグを作成し、この蓄積されたタグと、第２の擬似ランダムビットとに基づいて、認証タグを生成し、この認証タグを格納し、およびこの認証タグを含む複数のセグメントを送信することをさらに含む。
【０００８】
別の例示的な実施形態においては、受信されたアプリケーションパケットセグメントを処理する方法が、認証タグを含むアプリケーションパケットの複数のセグメントを受信し、第１の擬似ランダムビットを作成し、および、この受信された複数のセグメントのそれぞれと、この受信された複数のセグメントのそれぞれに関連する第１の擬似ランダムビットの諸部分とに基づいて、部分的タグを生成することを含む。この方法は、これらの部分的タグ、この受信された複数のセグメント、および、この受信された認証タグをメモリの中に格納し、この受信された複数のセグメントを組み合わせて、アプリケーションパケットを作成し、これらの部分的タグを組み合わせて、計算されたタグを作成し、および、この計算されたタグと、この受信された認証タグとに基づいて、アプリケーションパケットの真正性を検証することをさらに含む。
【０００９】
本発明の例示的な実施形態は、本明細書の後段で与えられる詳細な説明、ならびに、単に例示として与えられ、したがって、本発明の例示的な実施形態を限定するものではない、添付の図面から、より完全に理解されよう。
【図面の簡単な説明】
【００１０】
【図１】本発明の例示的な実施形態による論理暗号化方法を示す流れ図である。
【図２】図１における実施形態の例を表す図である。
【図３】本発明の例示的な実施形態による完全性タグを作成することの流れ図である。
【図４Ａ】図３に示される完全性タグ作成方法の例を表す図である。
【図４Ｂ】図３の方法による蓄積操作を示す図である。
【図５】本発明の例示的な実施形態によるＲＬＰセグメントの再送に関する流れ図である。
【図６】本発明の例示的な実施形態による解読およびインライン完全性検査を示す流れ図である。
【図７】本発明の例示的な実施形態によるブロックサイズセグメントの非倍数に関する部分的タグ計算を示す図である。
【図８】本発明の例示的な実施形態による可変長アプリケーションパケットに関する部分的タグ計算を示す図である。
【発明を実施するための形態】
【００１１】
「第１の」、「第２の」、「第３の」などの用語が、様々な要素、構成要素、領域、および／またはセクションを説明するのに本明細書で使用されるものの、これらの要素、構成要素、領域、および／またはセクションは、これらの用語によって限定されるべきではないことが理解されよう。これらの用語は、１つの要素、構成要素、領域、またはセクションを、別の領域またはセクションと区別するためにだけ使用される可能性がある。このため、後段で説明される第１の要素、第１の構成要素、第１の領域、または第１のセクションは、本発明の教示を逸脱することなく、第２の要素、第２の構成要素、第２の領域、または第２のセクションと呼ばれることも可能である。
【００１２】
本明細書で使用される用語法は、特定の例示的な実施形態を説明することだけを目的とし、限定することは意図していない。本明細書で使用される「ある」および「その」という単数形は、文脈によって、そうでないことが明らかに示されない限り、複数形も含むことが意図される可能性がある。「含む（ｃｏｍｐｒｉｓｅｓ）」および／または「含む（ｃｏｍｐｒｉｓｉｎｇ）」という用語は、本明細書で使用される場合、言明される特徴、完全体、ステップ、操作、要素、および／または構成要素の存在を明示するが、他の１つまたは複数の特徴、完全体、ステップ、操作、要素、構成要素、および／または以上のグループの存在または追加を排除しないことがさらに理解されよう。
【００１３】
例示的な実施形態は、理想化された実施形態（および中間構造）の概略図であることが可能な断面図を参照して、本明細書で説明される可能性がある。このため、例示的な実施形態は、本明細書で示される特定の配置および構成に限定されると解釈されるべきではなく、そのような配置および構成からの逸脱を含むべきである。
【００１４】
特に定義されない限り、本明細書で説明されるすべての用語（技術用語および科学用語を含む）は、当業者によって一般に理解されるのと同一の意味を有する。一般に使用される辞書において定義される用語などの用語は、当技術分野の文脈における、それらの用語の意味と合致する意味を有すると解釈されるべきであり、理想化された意味、または過度に形式的な意味で解釈されることは、本明細書でそのように明確に定義されない限り、ないことがさらに理解されよう。
【００１５】
本発明は、送信側と受信側の間のメッセージ認証に関する。送信側は、パケット通信を送信することができる任意のよく知られている無線通信システムにおける任意の通信デバイスであることが可能である。例えば、送信側は、移動局、基地局などであることが可能である。理解されるとおり、移動局は、移動電話機、ＰＤＡ、ポータブルコンピュータなどであることが可能である。受信側は、移動局、基地局などの、送信側の任意の受信する相手であることが可能である。さらに、本発明は、無線通信および／またはネットワーク通信に適用されることが可能であることが理解されよう。
【００１６】
メッセージ認証を最もよく理解するのに、本発明の実施形態に従って、メッセージ暗号化が、最初に説明される。さらに、暗号化を理解するために、無線リンクプロトコルが、最初に説明される。
【００１７】
（無線リンクプロトコル）
ＲＬＰ（無線リンクプロトコル）は、ＡＴ（アクセス端末装置）（移動局としても知られる）と、ＡＮ（アクセスノード）（基地局としても知られる）との間のワイヤレス無線インタフェースを介して機能するセグメント化−再組み立てプロトコルである。ＲＬＰは、アプリケーションパケットをＲＬＰセグメントまたはＲＬＰパケットに細分化（セグメント化）して、これらのセグメントまたはパケットが、ＲＦリンクを介して効率的に送信されることが可能であるようにすることを担う。さらに、ＲＬＰは、受信機におけるＲＬＰセグメントの再組み立て、順序の乱れたパケットの並べ替え、および伝送中にセグメントが失われた場合の再送も担う。
【００１８】
（メッセージ暗号化）
暗号化および／または認証／完全性は、ＲＬＰセグメントに対して実行されることが可能である。例えば、よく知られたＣＴＲ（カウンタモード）暗号化を使用して、ＲＬＰセグメントが暗号化されることが可能である。
【００１９】
暗号化されるべきＲＬＰセグメント、例えば、メッセージ、データ、音声などは、通常、平文と呼ばれ、暗号化プロセスの結果は、暗号文と呼ばれる。しばしば、この暗号化プロセスには、平文に対して暗号化アルゴリズムを実行して、暗号文を得ることがかかわる。ＤＥＳ（データ暗号化表示）、ＡＥＳ（高度暗号化表示）などの多くの暗号化アルゴリズムには、暗号化プロセスにおける鍵の使用がかかわる。暗号化鍵は、暗号化アルゴリズムにおいて暗号文を生成するのに使用されるビットシーケンスである。この暗号化鍵は、通信の送信側と受信側の両方で知られており、さらに、受信側において、この暗号化鍵を使用して、暗号文が平文に解読される。
【００２０】
ＡＮとＡＴの間で送信される情報のフレームの暗号化がかかわる無線通信環境における暗号化の場合、同一の情報（すなわち、同一の平文）が、異なる２つのフレームの中で送信される場合、問題が生じる。その状況では、同一の暗号文が、その２つのフレームのそれぞれに関して生成される。このため、この暗号文に関する情報が漏れたという言い方がされる。そのような漏れた暗号文に伴って行われる可能性がある反射攻撃を防止するのに、暗号同期を使用する暗号化技術が、開発された。暗号同期は、例えば、暗号化のための暗号同期の各回の使用後にインクリメントされるカウント値を含む。このようにして、暗号同期は、時とともに変化する。暗号同期の通常の使用において、暗号化アルゴリズムは、あたかも暗号同期が平文であるかのように、暗号同期に適用される。もたらされる出力は、マスクと呼ばれる。次に、このマスクが、暗号化のために情報（例えば、ＲＬＰセグメント）と排他論理和演算されて、暗号文が生成される。暗号化鍵の場合と同様に、暗号同期は、送信側と受信側の両方で知られており、さらに、受信側において、暗号同期を使用して、暗号文が平文に解読される。
【００２１】
（アプリケーションパケット暗号化）
本発明の実施形態によるメッセージ完全性をよりよく理解するのに、メッセージ完全性に適用される場合の、アプリケーションパケットを暗号化する方法の簡単方法の説明が、与えられる。
【００２２】
図１は、本発明の例示的な実施形態による論理暗号化方法の流れ図であり、さらに、図２は、このプロセスの図表による例を示す。
【００２３】
例示的な実施形態において、アプリケーションパケットのＲＬＰ（無線リンクプロトコル）セグメントが、別のアプリケーションパケットのＲＬＰセグメントとインタリーブされることなしに、暗号化のために送られるという想定が、存在する。また、単に例示の目的で、７６８バイトのアプリケーションパケットが、ＲＬＰストリームの第８０００番のバイト上で送信されており、ＲＬＰセグメント数は、４バイトの倍数であることも想定される。つまり、ＲＬＰセグメントは、ブロックサイズの倍数である。当業者には理解されるとおり、アプリケーションパケットサイズ、ＲＬＰバイトストリーム、およびＲＬＰセグメントのサイズはすべて、変えられることが可能である。
【００２４】
図１および図２を参照すると、送信側が、アプリケーションパケット、つまり、７６８バイトの長さを有するデータパケットを、ブロックサイズ例えば、３２ビット（４バイト）の倍数の平文ブロックＭ１−Ｍ１９２に論理的に分割する（ステップＳ１００で）。図２は、ブロックＭ１からＭＳを示す。
【００２５】
２つの引数（入力）、例えば、鍵ｋと、バイト番号に基づく暗号同期値とを用いるＡＥＳ（高度暗号化標準）を使用して、第１の擬似ランダムブロック（ビット）ＡＥＳｋ（０，８０００）−ＡＥＳｋ（０，８０１６）が、ステップＳ１１０で作成されることが可能である。図２において、表示、すなわち、ＴＹＰＥ、「０」を使用して、第１の擬似ランダムビットが、他の擬似ランダムビットと区別される。後段を参照されたい。
【００２６】
さらに詳細には、第１の擬似ランダムビットＡＥＳｋ（０，８０００）−ＡＥＳｋ（０，８０１６）は、以下のとおり書かれることが可能である。すなわち、
第１の擬似ランダムビット（ＯＵＴＰＵＴ）＝ＡＥＳ（ｋ，ＩＮＰＵＴ）
である。
【００２７】
ＡＥＳに対する暗号同期値（ＩＮＰＵＴ）は、２つの部分、ＴＹＰＥ（例えば、８ビット）と、ＣＯＵＮＴＥＲ（例えば、６４ビット）とに分割されることが可能であり、ＩＮＰＵＴビットの残りの部分は、０に設定されることが可能である。一般に知られているとおり、ＣＯＵＴＥＲ値は、ＩＮＰＵＴ値全体が、ＡＥＳに対して決して繰り返されることがないことを保証するために、ある特定のＴＹＰＥ値に関して、決して繰り返されてはならない。この場合も、「ＴＹＰＥ」を使用して、ＡＥＳの使用を区別して、様々な擬似ランダムビットが作成される。第１の擬似ランダムビットを作成するのに、ある特定のストリームに関して、ＢＹＴＥ＿ＮＵＭＢＥＲは、決して繰り返されないため、ＲＬＰストリームにおけるバイト番号が、ＣＯＵＮＴＥＲ値として使用されることが可能である。したがって、鍵ｋおよび暗号同期値を使用して、１２８ビットの出力が作成されることが可能である。暗号同期値のサイズは、変えられることが可能であり、さらに、暗号同期値は、他の入力、例えば、ｆｌｏｗＩＤ、リセットカウンタなどを含んでもよい。さらなる詳細は、後段で与えられる。
【００２８】
次に、ステップＳ１２０で、送信側が、平文ブロックＭ１からＭ８に対して、第１の擬似ランダムビットＡＥＳｋ（０，８０００）−ＡＥＳｋ（０，８０１６）とのＸＯＲ演算（排他論理和演算）を実行して、図２に示されるとおり、暗号化された（暗号文）ブロックＣ１からＣ８を作成する。
【００２９】
前段でＲＬＰセグメントを暗号化するのにＣＴＲ（カウンタモード）暗号化が説明されたものの、他のよく知られた暗号化方法、例えば、ＯＦＢ（出力フィードバック）モード、ＣＦＢ（暗号フィードバック）モードなどが使用されてもよい。
【００３０】
（メッセージ完全性）
アプリケーションパケット、より具体的には、ＲＬＰセグメントが暗号化されると、本発明の実施形態による完全性プロセスが、ＲＬＰセグメントに対して実行されて、アプリケーションパケットのための認証タグが生成されることが可能である。
【００３１】
図３は、本発明の例示的な実施形態による完全性（認証）タグを作成することの流れ図を示す。図４Ａは、このプロセスの図表による例を示す。簡明のため、暗号文ブロックという用語と、ＲＬＰセグメントという用語は、本開示全体にわたって互換的に使用される。
【００３２】
図３を参照すると、ステップＳ２００で、送信側が、第２の擬似ランダムビットＡｉを作成する。詳細には、この場合も、２つの引数（入力）、例えば、鍵ｋと、バイト番号に基づく暗号同期値とを用いるＡＥＳ（高度暗号化標準）を使用して、第２の擬似ランダムビットＡＥＳｋ（０，８０００）−ＡＥＳｋ（０，８０１６）が、作成されることが可能である。図４Ａにおいて、表示、すなわち、ＴＹＰＥ、「１」を使用して、第２の擬似ランダムビットが、他の擬似ランダムビット、例えば、第１の擬似ランダムビットと区別される。
【００３３】
さらに詳細には、第２の擬似ランダムビットＡＥＳｋ（０，８０００）−ＡＥＳｋ（０，８０１６）は、以下のとおり書かれることが可能である。すなわち、
第２の擬似ランダムビット（ＯＵＴＰＵＴ）＝ＡＥＳ（ｋ，ＩＮＰＵＴ）
である。
【００３４】
ＡＥＳに対する暗号同期（ｃｒｙｐｔｏｓｙｎｃ）値（ＩＮＰＵＴ）は、２つの部分、ＴＹＰＥ（例えば、８ビット）と、ＣＯＵＮＴＥＲ（例えば、６４ビット）とに分割されることが可能であり、ＩＮＰＵＴビットの残りの部分は、０に設定されることが可能である。一般に知られているとおり、ＣＯＵＴＥＲ値は、ＩＮＰＵＴ値全体が、ＡＥＳに対して決して繰り返されることがないことを保証するために、ある特定のＴＹＰＥ値に関して、決して繰り返されてはならない。この場合も、「ＴＹＰＥ」を使用して、ＡＥＳの使用を区別して、様々な擬似ランダムビットが作成される。第２の擬似ランダムビットを作成するのに、ある特定のストリームに関して、ＢＹＴＥ＿ＮＵＭＢＥＲは、決して繰り返されないため、ＲＬＰストリームにおけるバイト番号が、ＣＯＵＮＴＥＲ値として使用されることが可能である。
例えば、
ＯＵＴＰＵＴ［０］＝ＡＥＳ（ｋ，ＴＹＰＥ，０）は、１２８ビット長、つまり、１６バイト長である。次に、ＯＵＴＰＵＴ［１６］＝ＡＥＳ（ｋ，ＴＹＰＥ，１６）もやはり、１２８ビット長であり、ＯＵＴＰＵＴ［３２］＝ＡＥＳ（ｋ，ＴＹＰＥ，３２）もやはり、１２８ビット長であるといった具合である。
【００３５】
ＯＵＴＰＵＴは、一度に３２ビット長でラベルが付けられる。したがって、
Ａ０＝ＯＵＴＰＵＴ［０］の最初の４バイト
Ａ１＝ＯＵＴＰＵＴ［０］の第２番目の４バイト
Ａ２＝ＯＵＴＰＵＴ［０］の第３番目の４バイト
Ａ３＝ＯＵＴＰＵＴ［０］の最後の４バイト
Ａ４＝ＯＵＴＰＵＴ［１６］の最初の４バイト
Ａ５＝ＯＵＴＰＵＴ［１６］の第２番目の４バイト
Ａ６＝ＯＵＴＰＵＴ［１６］の第３番目の４バイト
Ａ７＝ＯＵＴＰＵＴ［１６］の最後の４バイト
Ａ８＝ＯＵＴＰＵＴ［３２］の最初の４バイト
Ａ９＝ＯＵＴＰＵＴ［３２］の第２番目４バイト
Ａ１０＝ＯＵＴＰＵＴ［３２］の第３番目４バイト
Ａ１１＝ＯＵＴＰＵＴ［３２］の最後の４バイト
である。
一般化すると、
【数１】
【００３６】
したがって、鍵ｋおよび暗号同期値を使用して、１２８ビットの出力が作成されることが可能である。暗号同期値のサイズは、変えられることが可能であり、さらに、暗号同期値は、他の入力、例えば、ｆｌｏｗＩＤ、リセットカウンタなどを含んでもよい。
【００３７】
次に図３を参照すると、ステップＳ２１０で、図１のステップＳ１２０で作成された各暗号文ブロック（ＲＬＰセグメント）に、第２の擬似ランダムビットＡｉのそれぞれのビットが掛けられて、部分的タグが作成される。
【００３８】
次にステップＳ２２０で、送信側は、ＲＬＰセグメントが最後のＲＬＰセグメントであるかどうかを判定する。ＲＬＰセグメントのヘッダの中のフラグが、先頭のセグメント、中央のセグメント、または最後のセグメントを示すように設定されることが可能である。ＲＬＰセグメントが、最後のＲＬＰセグメントではない場合、部分的タグ、例えば、３２ビットの部分的タグは、ステップＳ２３０で、送信側におけるアキュムレータ（図示せず）に送られる。送信側は、ステップＳ２４０で、ＲＬＰセグメントを受信機に送信する。
【００３９】
ＲＬＰセグメントが、最後のＲＬＰセグメントである場合、ステップＳ２３５で、最後の部分的タグは、アキュムレータに送られる。最後の部分的タグをアキュムレータに送るプロセスは、最後でない部分的タグをアキュムレータに送るプロセスと同一である。図４Ｂに示されるとおり、最後の部分的タグが、アキュムレータに送られた後、ステップＳ２４５で、それらの部分的タグを足して、３２ビットの蓄積されたタグを作成することによって、蓄積されたタグが形成される。理解されるとおり、部分的タグは、代わりに、各部分的タグが生成された後、部分的に蓄積されたタグに足されてもよい。次に、ステップＳ２５０で、送信側は、蓄積されたタグを、第３の擬似ランダムビットＡＥＳｋ（２，ＬａｓｔＢｙｔｅＮｕｍｂｅｒ）のｌｓｂ（最下位ビット）とＸＯＲ演算することによって、蓄積されたタグを暗号化して、認証タグを作成する。第３の擬似ランダムビットの形成は、以上の説明から直ちに明らかであるため、簡明のために、第３の擬似ランダムビットを作成することの説明は、省略する。
【００４０】
ステップＳ２６０で、ＲＬＰセグメント再送の場合、認証タグは、やはりメモリに送られる。ステップＳ２７０で、認証タグは、最後のＲＬＰセグメントに付加されて、復号のために受信機に送信される。メモリは、ＲＡＭ、あるいはＣＰ（中央プロセッサ）によって制御される他の任意の記憶デバイスであることが可能であり、あるいはメモリデバイスは、ＡＳＩＣ（特定用途向け集積回路）の一部である、またはＡＳＩＣによって制御されることが可能である。アプリケーションパケットの最後のＲＬＰパケットに関してだけ、認証タグは、格納される。
【００４１】
図４の実施形態に対する多数の変形が、この実施形態によって与えられる全体的な教示を逸脱することなく、可能であることが認識されよう。例えば、ステップＳ２１０およびＳ２２０は、逆の順序で実行されてもよく、あるいは並行に実行されてもよい。別の例として、ステップＳ２６０およびＳ２７０は、並行に、かつ／または順次に実行されてもよい。
【００４２】
（再送）
一般に知られているとおり、受信機は、送信側または送信機からの送信されたすべてのＲＬＰセグメントを受信するわけではない可能性がある。受信機が、送信されたすべてのＲＬＰセグメントを受信するわけではない可能性がある、多くの理由が存在する。簡明のため、ＲＬＰセグメントが失われる理由の詳細は、省略する。受信機が、すべてのＲＬＰセグメントを受信するわけではない場合、受信されなかったＲＬＰセグメントは、送信側によって再送される可能性がある。
【００４３】
送信側における中央プロセッサが、送信および再送のためのハードウェアにＲＬＰセグメントを送る際、中央プロセッサは、このＲＬＰセグメントが再送であるかどうかを示すビットも送る。再送を要求するプロセスは、当技術分野でよく知られており、したがって、このプロセスの説明もやはり、簡明のために省略する。
【００４４】
図５を参照すると、ステップＳ３００で、送信側または送信機が、ＲＬＰセグメントの再送を求める要求を受信する。ステップＳ３１０で、送信側は、この再送要求が、アプリケーションパケットの最後のＲＬＰセグメントに関するか、または最後ではないＲＬＰセグメントに関するかを判定する。要求が、最後ではないＲＬＰセグメントに関する場合、ステップＳ３２０で、そのＲＬＰセグメントが暗号化されて、再送される。
【００４５】
ステップＳ３１０で、要求が、アプリケーションパケットの最後のＲＬＰセグメントを求めるものである場合、ステップＳ３３０で、ＣＰ／ＲＡＭの中に格納されていた、蓄積された認証タグが、暗号化され、最後のＲＬＰセグメントに付加される。ステップＳ３４０で、この暗号化された最後のＲＬＰセグメントが、暗号化された認証タグと一緒に、受信機に再送される。
【００４６】
任意選択で、ステップＳ３１０とステップＳ３３０の間で、最後のＲＬＰセグメントは、さらに再細分化されてもよい。例えば、送信機が、送信条件に基づいて、最後のＲＬＰセグメント全体が、負荷を低減するように、より小さい断片にさらに分割されるべきであると決定することが可能である。これらの、より小さいセグメントのそれぞれは、異なるタイムスロット上で送信される。この場合、これらの、より小さい断片の最後の断片だけに、再送に先立って、暗号化された認証タグが付加される。
【００４７】
（解読およびインライン完全性検査）
受信機が、認証タグを含め、すべてのＲＬＰセグメントを適切に受信した場合、受信機は、これらのＲＬＰセグメントを、これらのセグメントが暗号化されていた場合、解読し、さらに、完全性検査を実行しなければならない。
【００４８】
図６は、本発明の例示的な実施形態による解読およびインライン完全性検査の方法を例示する流れ図を示す。この場合、「インライン」とは、完全性計算が、ＲＬＰセグメント全体を受信するのを待ってではなく、受信機によってＲＬＰセグメントが受信されるにつれて、行われることを意味する。
【００４９】
受信機においてすべてのＲＬＰセグメントが受信された後、ステップＳ４００で、第４の擬似ランダムビットが、作成される。図４のステップＳ２００の場合と同様に、ＡＥＳが、第４の擬似ランダムビットを作成するのに使用されることが可能である。第４の擬似ランダムビットの形成は、以上の説明から直ちに明らかであるため、簡明のために、第４の擬似ランダムビットを作成することの説明は、省略する。
【００５０】
ステップＳ４１０で、受信されたＲＬＰセグメントに関して部分的タグが作成される。これらの部分的タグは、３２ビットの部分的タグであることが可能である。次にステップＳ４２０で、受信機が、ＲＬＰセグメントが最後のＲＬＰセグメントであるかどうかを判定する。ＲＬＰセグメントが、最後のＲＬＰセグメントではない場合、ステップＳ４３０で、このＲＬＰセグメントが、解読され、さらに、部分的タグと一緒に、受信機のメモリに送られる。送信機と同様に、受信機のメモリは、ＲＡＭ、あるいはＣＰ（中央プロセッサ）によって制御される他の任意の記憶デバイスであることが可能であり、あるいはメモリデバイスは、ＡＳＩＣ（特定用途向け集積回路）の一部である、またはＡＳＩＣによって制御されることが可能である。図３および図４に関連して前述したステップとやはり同様に、この部分的タグ作成ステップと、ＲＬＰセグメントが最後のＲＬＰセグメントであるかどうか判定するステップは、逆転されてもよい。解読方法は、当技術分野においてよく知られており、したがって、解読方法の説明は、簡明のため、省略する。
【００５１】
ステップＳ４２０で、受信機が、ＲＬＰセグメントが最後のＲＬＰセグメントであると判定した場合、ステップＳ４４０で、最後のＲＬＰパケットが、解読される。やはりステップＳ４４０で、最後のＲＬＰセグメントの部分的タグが、第５の擬似ランダムビットＡＥＳｋ（２，ＬａｓｔＢｙｔｅＮｕｍｂｅｒ）のｌｓｂとＸＯＲ演算され、ステップＳ２７０からの認証タグと一緒に、メモリに送られる。第５の擬似ランダムビットの作成の説明は、簡明のため、省略される。さらに、第４の擬似ランダムビット、および第５の擬似ランダムビットを作成する方法は、それぞれ、前述した第２の擬似ランダムビット、および第３の擬似ランダムビットを作成する方法と同一であることが、当業者には明白となろう。
【００５２】
ＣＰ（中央プロセッサ）が、アプリケーションパケットを形成するように、すべてのＲＬＰセグメントを組み立てる。また、ＣＰは、ステップＳ４３０およびＳ４４０において受信されたすべての部分的タグを足す。ステップＳ４５０で、計算された部分的タグの合計が、受信された認証タグと等しい場合、そのアプリケーションパケットは、検証される。
【００５３】
（ブロックサイズの非倍数）
前述した例示的な実施形態において、完全性方法、暗号化方法、および解読方法は、ブロックサイズ、例えば、３２ビット（４バイト）の倍数であるＲＬＰセグメントに関して説明された。つまり、ＲＬＰセグメントは、３２ビットという標準のブロックサイズであった。以下の例示的な実施形態において、標準のブロックサイズではない、例えば、３２ビットの倍数ではないＲＬＰパケットが、説明される。簡明のため、標準のＲＬＰセグメントブロックサイズと非標準のＲＬＰセグメントブロックサイズの間で相違する態様（ステップ）だけが、説明される。
【００５４】
アプリケーションパケットのＲＬＰセグメントが、ブロックサイズの倍数でない、例えば、３２ビットの倍数でないものと想定し、さらに、あるビットシーケンス番号を所与として、３２ビットの倍数である先頭バイトを識別することが可能である。３２ビットの倍数である先頭バイトが識別されると、汎用ハッシュが、この３２ビット値に対して実行されることが可能である。
【００５５】
理解されるとおり、この「３２ビットの倍数」に先行するビット、および終端ビットが、適切に扱われなければならない。３２ビットの倍数ではないＲＬＰセグメントには、ＲＬＰセグメントの先頭に０が付加されることが可能であり、かつ／またはＲＬＰセグメントの終端に０が付加されて、３２ビットの暗号文ブロックＣｉを完成させることも可能である。例えば、３２ビットの暗号文は、多項式ｔとして書かれることが可能である。すなわち、
Ｃｉ，ａ×ｔ２４＋Ｃｉ，ｂ×ｔ１６＋Ｃｉ，ｃ×ｔ８＋Ｃｉ，ｄ×ｔ０
したがって、Ａｉ×Ｃｉは、以下のとおり書き換えられることが可能である。すなわち、
Ａｉ×Ｃｉ，ａ×ｔ２４＋Ａｉ×Ｃｉ，ｂ×ｔ１６＋Ａｉ×Ｃｉ，ｃ×ｔ８＋Ａｉ×Ｃｉ，ｄ×ｔ０
加算および乗算は、ガロア体（２３２）に基づいて計算されることが可能であり、あるいは、例えば、３２ビットより大きいモジュレータプライムに対して作用する他の体が、変更のために使用されることが可能である。完全な３２ビットＡｉが、そのブロックＣｉに関連付けられることが可能である。
【００５６】
詳細には、図７を参照して、第１のＲＬＰセグメント（ＲＬＰ１）が、ＲＬＰセグメント１が３つの追加のバイトで終わることを意味する、７バイト長であるものと想定されたい。次のセグメント、ＲＬＰセグメント２は、４バイトの倍数が始まる前に、残りのバイト（３バイト）を有する。３２ビットＣｉは、３２ビット、Ｃｉ，ａ、Ｃｉ，ｂ、Ｃｉ，ｃ、およびＣｉ，ｄから成る。したがって、Ｃ２の３バイトは、ＲＬＰセグメント１の一部であり、最後のバイトは、ＲＬＰセグメント２の一部である。さらに、３２ビットのＡ２が、作成され、ＲＬＰセグメント１とＲＬＰセグメント２の両方によって使用されて、部分的３２ビットタグが作成される。このため、ＲＬＰセグメント１に関する３２ビット部分的タグは、以下のとおり足され、
Ａｉ×Ｃｉ，ａ×ｔ２４＋Ａｉ×Ｃｉ，ｂ×ｔ１６＋Ａｉ×Ｃｉ，ｃ×ｔ８
さらに、ＲＬＰセグメント２に関する３２ビット部分的タグは、以下のとおり足される、
Ａｉ×Ｃｉ，ｄ×ｔ０
暗号化プロセスおよび部分的タグ作成プロセスの残りの部分は、前出の図１〜図４に関連して説明されるプロセスと同様である。さらに、前段で開示される認証タグ作成、ＲＬＰパケットの解読、ＲＬＰパケットの再送、および検証の方法は、同一である。図５〜図６、およびこれらの図の説明を参照されたい。
【００５７】
（可変長アプリケーションパケット）
アプリケーションパケットは、様々なバイト長を有することも可能である。したがって、本発明の例示的な実施形態が、これらのアプリケーションパケットにどのように適用されることが可能であるかの説明が、次に与えられる。簡明のため、前述した例示的な実施形態と異なる態様だけが、説明される。
【００５８】
アプリケーションパケットは、可変バイト長を有することが可能である。従来技術において、可変バイト長を有するアプリケーションパケットは、長さ（ブロック数）パラメータを、汎用ハッシュ計算の一部として、またはタグ暗号化への入力として含めることによって、扱われる可能性がある。例えば、パディングを使用して、最後の部分的に埋められたブロックが埋められることが可能である。しかし、この方法は、ＲＬＰセグメントが、乱れた順序で受信される場合、長さが分からないため、例示的な実施形態において使用され得ない。
【００５９】
先頭バイトおよび最後のバイトのバイト番号が、バイト長値に取って代わるように使用されることが可能である。Ｃ０値が、先頭バイトの番号に設定されることが可能であり、このことは、以下のとおり、項に寄与することが可能である。すなわち、Ｃ０×Ａ０。例えば、Ａ０は、擬似ランダムの、事前計算された、固定の値であることが可能であり、あるいはＡ０は、例えば、擬似ランダムストリームＡｉにおいてＡ１に先行する３２ビットの値であることが可能であり、Ｃ０は、アプリケーションパケットに先行する先頭ビットである。
【００６０】
Ａ０が、３２ビット境界の倍数にはない、任意のＣ０（先頭バイト番号）に関する擬似ランダムストリームＡｉにおいてＡ１に先行する３２ビットの値であるものと想定して、Ａ０が、先頭バイト番号を含むブロックに先行する３２ビット擬似ランダムブロックに設定される。また、ＲＬＰフローの最先頭、例えば、バイト０、１、２、および３に関して、先行するブロックが全く存在しないため、さらなるステップも要求される。例示として、Ａ０が、第６の擬似ランダムビットＡＥＳｋ（３，０）の最後のバイトであるように設定されることが可能であり、つまり、Ａ０＝ＡＥＳｋ（１，２６４−１）として設定されることが可能であり、ＡＥＳｋ（１，２６４−１）は、０ ｍｏｄ ２６４に先行する値である。ＲＬＰストリームが、２６４の３２ビットブロックに達することは、事実上、不可能であることに留意されたい。したがって、ＡＥＳに入力されるバイト番号全体は、６４ビットであるものと想定される。したがって、部分的３２ビットタグを作成するのに、Ｃ０が、先頭バイト番号（３２ビット）であり、さらに、Ａ０が、擬似ランダムストリームＡｉにおいてＡ１に先行する３２ビットマスク、例えば、Ａ０＝先行するＡＥＳｋ（１，．．．）出力ビットの最後の３２ビットである。ＲＬＰフローの最先頭の４バイトに関するＣ０に関するＡ０は、特に、前述したとおり作成される。
【００６１】
第７の擬似ランダムビットＡＥＳｋ（２，ＬａｓｔＢｙｔｅＮｕｍｂｅｒ）を使用して、暗号化されたタグ（認証タグ）を作成する際、異なるバイト番号で終わるアプリケーションパケットは、異なる暗号化タグを有する。やはり、第７の擬似ランダムビットを作成する方法は、前述した、第３の擬似ランダムビット、および第５の擬似ランダムビットを作成する方法と同一であることが可能である。タグを暗号化するのに、１２８ビットのブロック番号は、使用されず、ＡＥＳ入力として正確な最後のバイト番号が、使用されることが可能である。異なる２つのメッセージ、例えば、３２ビット長のメッセージＭの倍数、およびメッセージＭと、その後に続く０のバイトが、同一のタグを作成する可能性がある。しかし、各メッセージは、ランダムなストリングが、各メッセージに関して追加されるため、異なる仕方で暗号化される。
【００６２】
３２ビットの非倍数で始まり、３２ビットの非倍数で終わるが、同一のアプリケーションパケットに属するＲＬＰセグメントに関して、Ａｉは、ＲＬＰセグメントの先頭バイトにおいて、さらに、次のＲＬＰセグメントの先頭バイトにおいても、再使用されることが可能である。図８を参照して、３２ビットの非倍数で終わるアプリケーションパケットと、３２ビットの非倍数で始まる次のアプリケーションパケットとが、説明される。
【００６３】
ＲＬＰパケットは、４バイトＣｉを完成させるように０で満たされることが可能である。この場合、Ａｉは、両方のアプリケーションパケットに関して再使用されることが可能である。つまり、Ａｉは、第１のアプリケーションパケットの終端で使用され、第２のアプリケーションパケットの先頭で再び使用される。
【００６４】
第２のアプリケーションパケットの先頭バイトは、現在のｉに基づいて、４バイトＡｉを使用しつづけ、ただし、ｉは、（ＬａｓｔＢｙｔｅＮｕｍｂｅｒ／４）に等しい。第１のアプリケーションパケットの終端バイト、例えば、４Ｘ＋１バイト、４Ｘ＋２バイト、または４Ｘ＋３バイトに関して、最後のバイトに関連する３２ビットＡｉ、すなわち、（ＬａｓｔＢｙｔｅＮｕｍｂｅｒ／４）に等しいｉが、使用される。
【００６５】
本発明の例示的な実施形態は、アプリケーションパケット全体を再組み立てするのを待つ必要なしに、データが受信されるにつれて、メッセージ認証タグ検証を「オンザフライ」で可能にする。これらの例示的な実施形態は、バイトレベルの暗号化処理および認証処理、ならびにアウトオブオーダー処理を可能にする。
【００６６】
本発明の例示的な実施形態が、このように説明されたので、これらの実施形態が、多くの仕方で変更されることが可能であることが明白となろう。そのような変形形態は、本発明からの逸脱と見なされるべきではなく、そのようなすべての修正形態は、本発明の範囲に含められるべきものとする。
【技術分野】
【０００１】
本出願は、米国法典第３５編１１９条（ｅ）（２）の下で、全体が組み込まれている開示である、２００６年１０月２３日に出願した仮出願第６０／８５３，６４６号の優先権を主張するものである。
【０００２】
本発明は、送信のためにアプリケーションパケットを処理するための方法に関する。
【背景技術】
【０００３】
暗号化とメッセージ認証／完全性の両方が、ワイヤレス無線インタフェースを介してセキュリティをもたらすのに必要とされる。メッセージ暗号化が、メッセージのプライバシーを保護するのに対して、メッセージ認証は、このメッセージを不正操作から保護する。
【０００４】
メッセージ認証プロセスにおいて、秘密鍵およびメッセージ認証アルゴリズムを使用する送信側が、メッセージに付加される短いタグを計算する。また、受信側も、その秘密鍵の知識に基づいて、受信されたメッセージに関するタグを計算し、この計算されたタグを、受信されたタグと比較する。これらのタグが同一である場合、受信側は、そのメッセージを受け入れ、同一でない場合、そのメッセージは、破棄される。
【０００５】
既存のメッセージ認証アルゴリズム、例えば、鍵付きＨＭＡＣ−ＳＨＡ（Ｈａｓｈ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ−Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ）およびＡＥＳ−ＣＢＣ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ−Ｃｉｐｈｅｒ Ａｌｇｏｒｉｔｈｍ ｉｎ Ｃｉｐｈｅｒ Ｂｌｏｃｋ Ｃｈａｉｎｉｎｇ）は、逐次演算であり、ビットが、送信された順序で処理されることを要求するため、アウトオブオーダーパケット処理を許さない。このため、メッセージ認証の従来のアプローチは、データをＲＡＭに送り、ＣＰ（中央プロセッサ）にデータパケットを並べ替えさせて、アプリケーションパケット（メッセージ）を再組み立てさせ、このアプリケーションパケットを、メッセージ認証を行うべきハードウェアに送らなければならない。このことにより、バス上のトラフィックが相当に増大し、パケット処理の際の待ち時間が相当に増す可能性がある。
【０００６】
さらに、既存のメッセージ認証アルゴリズムは、一度にブロック単位に対して作用する。その結果、ブロックレベルアルゴリズムは、非ブロック境界で終わるメッセージセグメントに対して作用することが不可能である。メッセージ認証タグ検証を実行することを始める前に、すべてのメッセージセグメントからアプリケーションパケット全体を再組み立てすることが必要である。
【発明の概要】
【課題を解決するための手段】
【０００７】
本発明の例示的な実施形態においては、送信のためにアプリケーションパケットを処理するための方法が、このアプリケーションパケットを複数のセグメントに分割し、第１の擬似ランダムビットを作成し、および、この複数のセグメントのそれぞれと、この複数のセグメントのそれぞれに関連する第１の擬似ランダムビットの諸部分とに基づいて、部分的タグを生成することを含む。この方法は、アプリケーションパケットの最後のセグメントに関連する最後の部分的タグを含め、部分的タグを組み合わせて、蓄積されたタグを作成し、この蓄積されたタグと、第２の擬似ランダムビットとに基づいて、認証タグを生成し、この認証タグを格納し、およびこの認証タグを含む複数のセグメントを送信することをさらに含む。
【０００８】
別の例示的な実施形態においては、受信されたアプリケーションパケットセグメントを処理する方法が、認証タグを含むアプリケーションパケットの複数のセグメントを受信し、第１の擬似ランダムビットを作成し、および、この受信された複数のセグメントのそれぞれと、この受信された複数のセグメントのそれぞれに関連する第１の擬似ランダムビットの諸部分とに基づいて、部分的タグを生成することを含む。この方法は、これらの部分的タグ、この受信された複数のセグメント、および、この受信された認証タグをメモリの中に格納し、この受信された複数のセグメントを組み合わせて、アプリケーションパケットを作成し、これらの部分的タグを組み合わせて、計算されたタグを作成し、および、この計算されたタグと、この受信された認証タグとに基づいて、アプリケーションパケットの真正性を検証することをさらに含む。
【０００９】
本発明の例示的な実施形態は、本明細書の後段で与えられる詳細な説明、ならびに、単に例示として与えられ、したがって、本発明の例示的な実施形態を限定するものではない、添付の図面から、より完全に理解されよう。
【図面の簡単な説明】
【００１０】
【図１】本発明の例示的な実施形態による論理暗号化方法を示す流れ図である。
【図２】図１における実施形態の例を表す図である。
【図３】本発明の例示的な実施形態による完全性タグを作成することの流れ図である。
【図４Ａ】図３に示される完全性タグ作成方法の例を表す図である。
【図４Ｂ】図３の方法による蓄積操作を示す図である。
【図５】本発明の例示的な実施形態によるＲＬＰセグメントの再送に関する流れ図である。
【図６】本発明の例示的な実施形態による解読およびインライン完全性検査を示す流れ図である。
【図７】本発明の例示的な実施形態によるブロックサイズセグメントの非倍数に関する部分的タグ計算を示す図である。
【図８】本発明の例示的な実施形態による可変長アプリケーションパケットに関する部分的タグ計算を示す図である。
【発明を実施するための形態】
【００１１】
「第１の」、「第２の」、「第３の」などの用語が、様々な要素、構成要素、領域、および／またはセクションを説明するのに本明細書で使用されるものの、これらの要素、構成要素、領域、および／またはセクションは、これらの用語によって限定されるべきではないことが理解されよう。これらの用語は、１つの要素、構成要素、領域、またはセクションを、別の領域またはセクションと区別するためにだけ使用される可能性がある。このため、後段で説明される第１の要素、第１の構成要素、第１の領域、または第１のセクションは、本発明の教示を逸脱することなく、第２の要素、第２の構成要素、第２の領域、または第２のセクションと呼ばれることも可能である。
【００１２】
本明細書で使用される用語法は、特定の例示的な実施形態を説明することだけを目的とし、限定することは意図していない。本明細書で使用される「ある」および「その」という単数形は、文脈によって、そうでないことが明らかに示されない限り、複数形も含むことが意図される可能性がある。「含む（ｃｏｍｐｒｉｓｅｓ）」および／または「含む（ｃｏｍｐｒｉｓｉｎｇ）」という用語は、本明細書で使用される場合、言明される特徴、完全体、ステップ、操作、要素、および／または構成要素の存在を明示するが、他の１つまたは複数の特徴、完全体、ステップ、操作、要素、構成要素、および／または以上のグループの存在または追加を排除しないことがさらに理解されよう。
【００１３】
例示的な実施形態は、理想化された実施形態（および中間構造）の概略図であることが可能な断面図を参照して、本明細書で説明される可能性がある。このため、例示的な実施形態は、本明細書で示される特定の配置および構成に限定されると解釈されるべきではなく、そのような配置および構成からの逸脱を含むべきである。
【００１４】
特に定義されない限り、本明細書で説明されるすべての用語（技術用語および科学用語を含む）は、当業者によって一般に理解されるのと同一の意味を有する。一般に使用される辞書において定義される用語などの用語は、当技術分野の文脈における、それらの用語の意味と合致する意味を有すると解釈されるべきであり、理想化された意味、または過度に形式的な意味で解釈されることは、本明細書でそのように明確に定義されない限り、ないことがさらに理解されよう。
【００１５】
本発明は、送信側と受信側の間のメッセージ認証に関する。送信側は、パケット通信を送信することができる任意のよく知られている無線通信システムにおける任意の通信デバイスであることが可能である。例えば、送信側は、移動局、基地局などであることが可能である。理解されるとおり、移動局は、移動電話機、ＰＤＡ、ポータブルコンピュータなどであることが可能である。受信側は、移動局、基地局などの、送信側の任意の受信する相手であることが可能である。さらに、本発明は、無線通信および／またはネットワーク通信に適用されることが可能であることが理解されよう。
【００１６】
メッセージ認証を最もよく理解するのに、本発明の実施形態に従って、メッセージ暗号化が、最初に説明される。さらに、暗号化を理解するために、無線リンクプロトコルが、最初に説明される。
【００１７】
（無線リンクプロトコル）
ＲＬＰ（無線リンクプロトコル）は、ＡＴ（アクセス端末装置）（移動局としても知られる）と、ＡＮ（アクセスノード）（基地局としても知られる）との間のワイヤレス無線インタフェースを介して機能するセグメント化−再組み立てプロトコルである。ＲＬＰは、アプリケーションパケットをＲＬＰセグメントまたはＲＬＰパケットに細分化（セグメント化）して、これらのセグメントまたはパケットが、ＲＦリンクを介して効率的に送信されることが可能であるようにすることを担う。さらに、ＲＬＰは、受信機におけるＲＬＰセグメントの再組み立て、順序の乱れたパケットの並べ替え、および伝送中にセグメントが失われた場合の再送も担う。
【００１８】
（メッセージ暗号化）
暗号化および／または認証／完全性は、ＲＬＰセグメントに対して実行されることが可能である。例えば、よく知られたＣＴＲ（カウンタモード）暗号化を使用して、ＲＬＰセグメントが暗号化されることが可能である。
【００１９】
暗号化されるべきＲＬＰセグメント、例えば、メッセージ、データ、音声などは、通常、平文と呼ばれ、暗号化プロセスの結果は、暗号文と呼ばれる。しばしば、この暗号化プロセスには、平文に対して暗号化アルゴリズムを実行して、暗号文を得ることがかかわる。ＤＥＳ（データ暗号化表示）、ＡＥＳ（高度暗号化表示）などの多くの暗号化アルゴリズムには、暗号化プロセスにおける鍵の使用がかかわる。暗号化鍵は、暗号化アルゴリズムにおいて暗号文を生成するのに使用されるビットシーケンスである。この暗号化鍵は、通信の送信側と受信側の両方で知られており、さらに、受信側において、この暗号化鍵を使用して、暗号文が平文に解読される。
【００２０】
ＡＮとＡＴの間で送信される情報のフレームの暗号化がかかわる無線通信環境における暗号化の場合、同一の情報（すなわち、同一の平文）が、異なる２つのフレームの中で送信される場合、問題が生じる。その状況では、同一の暗号文が、その２つのフレームのそれぞれに関して生成される。このため、この暗号文に関する情報が漏れたという言い方がされる。そのような漏れた暗号文に伴って行われる可能性がある反射攻撃を防止するのに、暗号同期を使用する暗号化技術が、開発された。暗号同期は、例えば、暗号化のための暗号同期の各回の使用後にインクリメントされるカウント値を含む。このようにして、暗号同期は、時とともに変化する。暗号同期の通常の使用において、暗号化アルゴリズムは、あたかも暗号同期が平文であるかのように、暗号同期に適用される。もたらされる出力は、マスクと呼ばれる。次に、このマスクが、暗号化のために情報（例えば、ＲＬＰセグメント）と排他論理和演算されて、暗号文が生成される。暗号化鍵の場合と同様に、暗号同期は、送信側と受信側の両方で知られており、さらに、受信側において、暗号同期を使用して、暗号文が平文に解読される。
【００２１】
（アプリケーションパケット暗号化）
本発明の実施形態によるメッセージ完全性をよりよく理解するのに、メッセージ完全性に適用される場合の、アプリケーションパケットを暗号化する方法の簡単方法の説明が、与えられる。
【００２２】
図１は、本発明の例示的な実施形態による論理暗号化方法の流れ図であり、さらに、図２は、このプロセスの図表による例を示す。
【００２３】
例示的な実施形態において、アプリケーションパケットのＲＬＰ（無線リンクプロトコル）セグメントが、別のアプリケーションパケットのＲＬＰセグメントとインタリーブされることなしに、暗号化のために送られるという想定が、存在する。また、単に例示の目的で、７６８バイトのアプリケーションパケットが、ＲＬＰストリームの第８０００番のバイト上で送信されており、ＲＬＰセグメント数は、４バイトの倍数であることも想定される。つまり、ＲＬＰセグメントは、ブロックサイズの倍数である。当業者には理解されるとおり、アプリケーションパケットサイズ、ＲＬＰバイトストリーム、およびＲＬＰセグメントのサイズはすべて、変えられることが可能である。
【００２４】
図１および図２を参照すると、送信側が、アプリケーションパケット、つまり、７６８バイトの長さを有するデータパケットを、ブロックサイズ例えば、３２ビット（４バイト）の倍数の平文ブロックＭ１−Ｍ１９２に論理的に分割する（ステップＳ１００で）。図２は、ブロックＭ１からＭＳを示す。
【００２５】
２つの引数（入力）、例えば、鍵ｋと、バイト番号に基づく暗号同期値とを用いるＡＥＳ（高度暗号化標準）を使用して、第１の擬似ランダムブロック（ビット）ＡＥＳｋ（０，８０００）−ＡＥＳｋ（０，８０１６）が、ステップＳ１１０で作成されることが可能である。図２において、表示、すなわち、ＴＹＰＥ、「０」を使用して、第１の擬似ランダムビットが、他の擬似ランダムビットと区別される。後段を参照されたい。
【００２６】
さらに詳細には、第１の擬似ランダムビットＡＥＳｋ（０，８０００）−ＡＥＳｋ（０，８０１６）は、以下のとおり書かれることが可能である。すなわち、
第１の擬似ランダムビット（ＯＵＴＰＵＴ）＝ＡＥＳ（ｋ，ＩＮＰＵＴ）
である。
【００２７】
ＡＥＳに対する暗号同期値（ＩＮＰＵＴ）は、２つの部分、ＴＹＰＥ（例えば、８ビット）と、ＣＯＵＮＴＥＲ（例えば、６４ビット）とに分割されることが可能であり、ＩＮＰＵＴビットの残りの部分は、０に設定されることが可能である。一般に知られているとおり、ＣＯＵＴＥＲ値は、ＩＮＰＵＴ値全体が、ＡＥＳに対して決して繰り返されることがないことを保証するために、ある特定のＴＹＰＥ値に関して、決して繰り返されてはならない。この場合も、「ＴＹＰＥ」を使用して、ＡＥＳの使用を区別して、様々な擬似ランダムビットが作成される。第１の擬似ランダムビットを作成するのに、ある特定のストリームに関して、ＢＹＴＥ＿ＮＵＭＢＥＲは、決して繰り返されないため、ＲＬＰストリームにおけるバイト番号が、ＣＯＵＮＴＥＲ値として使用されることが可能である。したがって、鍵ｋおよび暗号同期値を使用して、１２８ビットの出力が作成されることが可能である。暗号同期値のサイズは、変えられることが可能であり、さらに、暗号同期値は、他の入力、例えば、ｆｌｏｗＩＤ、リセットカウンタなどを含んでもよい。さらなる詳細は、後段で与えられる。
【００２８】
次に、ステップＳ１２０で、送信側が、平文ブロックＭ１からＭ８に対して、第１の擬似ランダムビットＡＥＳｋ（０，８０００）−ＡＥＳｋ（０，８０１６）とのＸＯＲ演算（排他論理和演算）を実行して、図２に示されるとおり、暗号化された（暗号文）ブロックＣ１からＣ８を作成する。
【００２９】
前段でＲＬＰセグメントを暗号化するのにＣＴＲ（カウンタモード）暗号化が説明されたものの、他のよく知られた暗号化方法、例えば、ＯＦＢ（出力フィードバック）モード、ＣＦＢ（暗号フィードバック）モードなどが使用されてもよい。
【００３０】
（メッセージ完全性）
アプリケーションパケット、より具体的には、ＲＬＰセグメントが暗号化されると、本発明の実施形態による完全性プロセスが、ＲＬＰセグメントに対して実行されて、アプリケーションパケットのための認証タグが生成されることが可能である。
【００３１】
図３は、本発明の例示的な実施形態による完全性（認証）タグを作成することの流れ図を示す。図４Ａは、このプロセスの図表による例を示す。簡明のため、暗号文ブロックという用語と、ＲＬＰセグメントという用語は、本開示全体にわたって互換的に使用される。
【００３２】
図３を参照すると、ステップＳ２００で、送信側が、第２の擬似ランダムビットＡｉを作成する。詳細には、この場合も、２つの引数（入力）、例えば、鍵ｋと、バイト番号に基づく暗号同期値とを用いるＡＥＳ（高度暗号化標準）を使用して、第２の擬似ランダムビットＡＥＳｋ（０，８０００）−ＡＥＳｋ（０，８０１６）が、作成されることが可能である。図４Ａにおいて、表示、すなわち、ＴＹＰＥ、「１」を使用して、第２の擬似ランダムビットが、他の擬似ランダムビット、例えば、第１の擬似ランダムビットと区別される。
【００３３】
さらに詳細には、第２の擬似ランダムビットＡＥＳｋ（０，８０００）−ＡＥＳｋ（０，８０１６）は、以下のとおり書かれることが可能である。すなわち、
第２の擬似ランダムビット（ＯＵＴＰＵＴ）＝ＡＥＳ（ｋ，ＩＮＰＵＴ）
である。
【００３４】
ＡＥＳに対する暗号同期（ｃｒｙｐｔｏｓｙｎｃ）値（ＩＮＰＵＴ）は、２つの部分、ＴＹＰＥ（例えば、８ビット）と、ＣＯＵＮＴＥＲ（例えば、６４ビット）とに分割されることが可能であり、ＩＮＰＵＴビットの残りの部分は、０に設定されることが可能である。一般に知られているとおり、ＣＯＵＴＥＲ値は、ＩＮＰＵＴ値全体が、ＡＥＳに対して決して繰り返されることがないことを保証するために、ある特定のＴＹＰＥ値に関して、決して繰り返されてはならない。この場合も、「ＴＹＰＥ」を使用して、ＡＥＳの使用を区別して、様々な擬似ランダムビットが作成される。第２の擬似ランダムビットを作成するのに、ある特定のストリームに関して、ＢＹＴＥ＿ＮＵＭＢＥＲは、決して繰り返されないため、ＲＬＰストリームにおけるバイト番号が、ＣＯＵＮＴＥＲ値として使用されることが可能である。
例えば、
ＯＵＴＰＵＴ［０］＝ＡＥＳ（ｋ，ＴＹＰＥ，０）は、１２８ビット長、つまり、１６バイト長である。次に、ＯＵＴＰＵＴ［１６］＝ＡＥＳ（ｋ，ＴＹＰＥ，１６）もやはり、１２８ビット長であり、ＯＵＴＰＵＴ［３２］＝ＡＥＳ（ｋ，ＴＹＰＥ，３２）もやはり、１２８ビット長であるといった具合である。
【００３５】
ＯＵＴＰＵＴは、一度に３２ビット長でラベルが付けられる。したがって、
Ａ０＝ＯＵＴＰＵＴ［０］の最初の４バイト
Ａ１＝ＯＵＴＰＵＴ［０］の第２番目の４バイト
Ａ２＝ＯＵＴＰＵＴ［０］の第３番目の４バイト
Ａ３＝ＯＵＴＰＵＴ［０］の最後の４バイト
Ａ４＝ＯＵＴＰＵＴ［１６］の最初の４バイト
Ａ５＝ＯＵＴＰＵＴ［１６］の第２番目の４バイト
Ａ６＝ＯＵＴＰＵＴ［１６］の第３番目の４バイト
Ａ７＝ＯＵＴＰＵＴ［１６］の最後の４バイト
Ａ８＝ＯＵＴＰＵＴ［３２］の最初の４バイト
Ａ９＝ＯＵＴＰＵＴ［３２］の第２番目４バイト
Ａ１０＝ＯＵＴＰＵＴ［３２］の第３番目４バイト
Ａ１１＝ＯＵＴＰＵＴ［３２］の最後の４バイト
である。
一般化すると、
【数１】
【００３６】
したがって、鍵ｋおよび暗号同期値を使用して、１２８ビットの出力が作成されることが可能である。暗号同期値のサイズは、変えられることが可能であり、さらに、暗号同期値は、他の入力、例えば、ｆｌｏｗＩＤ、リセットカウンタなどを含んでもよい。
【００３７】
次に図３を参照すると、ステップＳ２１０で、図１のステップＳ１２０で作成された各暗号文ブロック（ＲＬＰセグメント）に、第２の擬似ランダムビットＡｉのそれぞれのビットが掛けられて、部分的タグが作成される。
【００３８】
次にステップＳ２２０で、送信側は、ＲＬＰセグメントが最後のＲＬＰセグメントであるかどうかを判定する。ＲＬＰセグメントのヘッダの中のフラグが、先頭のセグメント、中央のセグメント、または最後のセグメントを示すように設定されることが可能である。ＲＬＰセグメントが、最後のＲＬＰセグメントではない場合、部分的タグ、例えば、３２ビットの部分的タグは、ステップＳ２３０で、送信側におけるアキュムレータ（図示せず）に送られる。送信側は、ステップＳ２４０で、ＲＬＰセグメントを受信機に送信する。
【００３９】
ＲＬＰセグメントが、最後のＲＬＰセグメントである場合、ステップＳ２３５で、最後の部分的タグは、アキュムレータに送られる。最後の部分的タグをアキュムレータに送るプロセスは、最後でない部分的タグをアキュムレータに送るプロセスと同一である。図４Ｂに示されるとおり、最後の部分的タグが、アキュムレータに送られた後、ステップＳ２４５で、それらの部分的タグを足して、３２ビットの蓄積されたタグを作成することによって、蓄積されたタグが形成される。理解されるとおり、部分的タグは、代わりに、各部分的タグが生成された後、部分的に蓄積されたタグに足されてもよい。次に、ステップＳ２５０で、送信側は、蓄積されたタグを、第３の擬似ランダムビットＡＥＳｋ（２，ＬａｓｔＢｙｔｅＮｕｍｂｅｒ）のｌｓｂ（最下位ビット）とＸＯＲ演算することによって、蓄積されたタグを暗号化して、認証タグを作成する。第３の擬似ランダムビットの形成は、以上の説明から直ちに明らかであるため、簡明のために、第３の擬似ランダムビットを作成することの説明は、省略する。
【００４０】
ステップＳ２６０で、ＲＬＰセグメント再送の場合、認証タグは、やはりメモリに送られる。ステップＳ２７０で、認証タグは、最後のＲＬＰセグメントに付加されて、復号のために受信機に送信される。メモリは、ＲＡＭ、あるいはＣＰ（中央プロセッサ）によって制御される他の任意の記憶デバイスであることが可能であり、あるいはメモリデバイスは、ＡＳＩＣ（特定用途向け集積回路）の一部である、またはＡＳＩＣによって制御されることが可能である。アプリケーションパケットの最後のＲＬＰパケットに関してだけ、認証タグは、格納される。
【００４１】
図４の実施形態に対する多数の変形が、この実施形態によって与えられる全体的な教示を逸脱することなく、可能であることが認識されよう。例えば、ステップＳ２１０およびＳ２２０は、逆の順序で実行されてもよく、あるいは並行に実行されてもよい。別の例として、ステップＳ２６０およびＳ２７０は、並行に、かつ／または順次に実行されてもよい。
【００４２】
（再送）
一般に知られているとおり、受信機は、送信側または送信機からの送信されたすべてのＲＬＰセグメントを受信するわけではない可能性がある。受信機が、送信されたすべてのＲＬＰセグメントを受信するわけではない可能性がある、多くの理由が存在する。簡明のため、ＲＬＰセグメントが失われる理由の詳細は、省略する。受信機が、すべてのＲＬＰセグメントを受信するわけではない場合、受信されなかったＲＬＰセグメントは、送信側によって再送される可能性がある。
【００４３】
送信側における中央プロセッサが、送信および再送のためのハードウェアにＲＬＰセグメントを送る際、中央プロセッサは、このＲＬＰセグメントが再送であるかどうかを示すビットも送る。再送を要求するプロセスは、当技術分野でよく知られており、したがって、このプロセスの説明もやはり、簡明のために省略する。
【００４４】
図５を参照すると、ステップＳ３００で、送信側または送信機が、ＲＬＰセグメントの再送を求める要求を受信する。ステップＳ３１０で、送信側は、この再送要求が、アプリケーションパケットの最後のＲＬＰセグメントに関するか、または最後ではないＲＬＰセグメントに関するかを判定する。要求が、最後ではないＲＬＰセグメントに関する場合、ステップＳ３２０で、そのＲＬＰセグメントが暗号化されて、再送される。
【００４５】
ステップＳ３１０で、要求が、アプリケーションパケットの最後のＲＬＰセグメントを求めるものである場合、ステップＳ３３０で、ＣＰ／ＲＡＭの中に格納されていた、蓄積された認証タグが、暗号化され、最後のＲＬＰセグメントに付加される。ステップＳ３４０で、この暗号化された最後のＲＬＰセグメントが、暗号化された認証タグと一緒に、受信機に再送される。
【００４６】
任意選択で、ステップＳ３１０とステップＳ３３０の間で、最後のＲＬＰセグメントは、さらに再細分化されてもよい。例えば、送信機が、送信条件に基づいて、最後のＲＬＰセグメント全体が、負荷を低減するように、より小さい断片にさらに分割されるべきであると決定することが可能である。これらの、より小さいセグメントのそれぞれは、異なるタイムスロット上で送信される。この場合、これらの、より小さい断片の最後の断片だけに、再送に先立って、暗号化された認証タグが付加される。
【００４７】
（解読およびインライン完全性検査）
受信機が、認証タグを含め、すべてのＲＬＰセグメントを適切に受信した場合、受信機は、これらのＲＬＰセグメントを、これらのセグメントが暗号化されていた場合、解読し、さらに、完全性検査を実行しなければならない。
【００４８】
図６は、本発明の例示的な実施形態による解読およびインライン完全性検査の方法を例示する流れ図を示す。この場合、「インライン」とは、完全性計算が、ＲＬＰセグメント全体を受信するのを待ってではなく、受信機によってＲＬＰセグメントが受信されるにつれて、行われることを意味する。
【００４９】
受信機においてすべてのＲＬＰセグメントが受信された後、ステップＳ４００で、第４の擬似ランダムビットが、作成される。図４のステップＳ２００の場合と同様に、ＡＥＳが、第４の擬似ランダムビットを作成するのに使用されることが可能である。第４の擬似ランダムビットの形成は、以上の説明から直ちに明らかであるため、簡明のために、第４の擬似ランダムビットを作成することの説明は、省略する。
【００５０】
ステップＳ４１０で、受信されたＲＬＰセグメントに関して部分的タグが作成される。これらの部分的タグは、３２ビットの部分的タグであることが可能である。次にステップＳ４２０で、受信機が、ＲＬＰセグメントが最後のＲＬＰセグメントであるかどうかを判定する。ＲＬＰセグメントが、最後のＲＬＰセグメントではない場合、ステップＳ４３０で、このＲＬＰセグメントが、解読され、さらに、部分的タグと一緒に、受信機のメモリに送られる。送信機と同様に、受信機のメモリは、ＲＡＭ、あるいはＣＰ（中央プロセッサ）によって制御される他の任意の記憶デバイスであることが可能であり、あるいはメモリデバイスは、ＡＳＩＣ（特定用途向け集積回路）の一部である、またはＡＳＩＣによって制御されることが可能である。図３および図４に関連して前述したステップとやはり同様に、この部分的タグ作成ステップと、ＲＬＰセグメントが最後のＲＬＰセグメントであるかどうか判定するステップは、逆転されてもよい。解読方法は、当技術分野においてよく知られており、したがって、解読方法の説明は、簡明のため、省略する。
【００５１】
ステップＳ４２０で、受信機が、ＲＬＰセグメントが最後のＲＬＰセグメントであると判定した場合、ステップＳ４４０で、最後のＲＬＰパケットが、解読される。やはりステップＳ４４０で、最後のＲＬＰセグメントの部分的タグが、第５の擬似ランダムビットＡＥＳｋ（２，ＬａｓｔＢｙｔｅＮｕｍｂｅｒ）のｌｓｂとＸＯＲ演算され、ステップＳ２７０からの認証タグと一緒に、メモリに送られる。第５の擬似ランダムビットの作成の説明は、簡明のため、省略される。さらに、第４の擬似ランダムビット、および第５の擬似ランダムビットを作成する方法は、それぞれ、前述した第２の擬似ランダムビット、および第３の擬似ランダムビットを作成する方法と同一であることが、当業者には明白となろう。
【００５２】
ＣＰ（中央プロセッサ）が、アプリケーションパケットを形成するように、すべてのＲＬＰセグメントを組み立てる。また、ＣＰは、ステップＳ４３０およびＳ４４０において受信されたすべての部分的タグを足す。ステップＳ４５０で、計算された部分的タグの合計が、受信された認証タグと等しい場合、そのアプリケーションパケットは、検証される。
【００５３】
（ブロックサイズの非倍数）
前述した例示的な実施形態において、完全性方法、暗号化方法、および解読方法は、ブロックサイズ、例えば、３２ビット（４バイト）の倍数であるＲＬＰセグメントに関して説明された。つまり、ＲＬＰセグメントは、３２ビットという標準のブロックサイズであった。以下の例示的な実施形態において、標準のブロックサイズではない、例えば、３２ビットの倍数ではないＲＬＰパケットが、説明される。簡明のため、標準のＲＬＰセグメントブロックサイズと非標準のＲＬＰセグメントブロックサイズの間で相違する態様（ステップ）だけが、説明される。
【００５４】
アプリケーションパケットのＲＬＰセグメントが、ブロックサイズの倍数でない、例えば、３２ビットの倍数でないものと想定し、さらに、あるビットシーケンス番号を所与として、３２ビットの倍数である先頭バイトを識別することが可能である。３２ビットの倍数である先頭バイトが識別されると、汎用ハッシュが、この３２ビット値に対して実行されることが可能である。
【００５５】
理解されるとおり、この「３２ビットの倍数」に先行するビット、および終端ビットが、適切に扱われなければならない。３２ビットの倍数ではないＲＬＰセグメントには、ＲＬＰセグメントの先頭に０が付加されることが可能であり、かつ／またはＲＬＰセグメントの終端に０が付加されて、３２ビットの暗号文ブロックＣｉを完成させることも可能である。例えば、３２ビットの暗号文は、多項式ｔとして書かれることが可能である。すなわち、
Ｃｉ，ａ×ｔ２４＋Ｃｉ，ｂ×ｔ１６＋Ｃｉ，ｃ×ｔ８＋Ｃｉ，ｄ×ｔ０
したがって、Ａｉ×Ｃｉは、以下のとおり書き換えられることが可能である。すなわち、
Ａｉ×Ｃｉ，ａ×ｔ２４＋Ａｉ×Ｃｉ，ｂ×ｔ１６＋Ａｉ×Ｃｉ，ｃ×ｔ８＋Ａｉ×Ｃｉ，ｄ×ｔ０
加算および乗算は、ガロア体（２３２）に基づいて計算されることが可能であり、あるいは、例えば、３２ビットより大きいモジュレータプライムに対して作用する他の体が、変更のために使用されることが可能である。完全な３２ビットＡｉが、そのブロックＣｉに関連付けられることが可能である。
【００５６】
詳細には、図７を参照して、第１のＲＬＰセグメント（ＲＬＰ１）が、ＲＬＰセグメント１が３つの追加のバイトで終わることを意味する、７バイト長であるものと想定されたい。次のセグメント、ＲＬＰセグメント２は、４バイトの倍数が始まる前に、残りのバイト（３バイト）を有する。３２ビットＣｉは、３２ビット、Ｃｉ，ａ、Ｃｉ，ｂ、Ｃｉ，ｃ、およびＣｉ，ｄから成る。したがって、Ｃ２の３バイトは、ＲＬＰセグメント１の一部であり、最後のバイトは、ＲＬＰセグメント２の一部である。さらに、３２ビットのＡ２が、作成され、ＲＬＰセグメント１とＲＬＰセグメント２の両方によって使用されて、部分的３２ビットタグが作成される。このため、ＲＬＰセグメント１に関する３２ビット部分的タグは、以下のとおり足され、
Ａｉ×Ｃｉ，ａ×ｔ２４＋Ａｉ×Ｃｉ，ｂ×ｔ１６＋Ａｉ×Ｃｉ，ｃ×ｔ８
さらに、ＲＬＰセグメント２に関する３２ビット部分的タグは、以下のとおり足される、
Ａｉ×Ｃｉ，ｄ×ｔ０
暗号化プロセスおよび部分的タグ作成プロセスの残りの部分は、前出の図１〜図４に関連して説明されるプロセスと同様である。さらに、前段で開示される認証タグ作成、ＲＬＰパケットの解読、ＲＬＰパケットの再送、および検証の方法は、同一である。図５〜図６、およびこれらの図の説明を参照されたい。
【００５７】
（可変長アプリケーションパケット）
アプリケーションパケットは、様々なバイト長を有することも可能である。したがって、本発明の例示的な実施形態が、これらのアプリケーションパケットにどのように適用されることが可能であるかの説明が、次に与えられる。簡明のため、前述した例示的な実施形態と異なる態様だけが、説明される。
【００５８】
アプリケーションパケットは、可変バイト長を有することが可能である。従来技術において、可変バイト長を有するアプリケーションパケットは、長さ（ブロック数）パラメータを、汎用ハッシュ計算の一部として、またはタグ暗号化への入力として含めることによって、扱われる可能性がある。例えば、パディングを使用して、最後の部分的に埋められたブロックが埋められることが可能である。しかし、この方法は、ＲＬＰセグメントが、乱れた順序で受信される場合、長さが分からないため、例示的な実施形態において使用され得ない。
【００５９】
先頭バイトおよび最後のバイトのバイト番号が、バイト長値に取って代わるように使用されることが可能である。Ｃ０値が、先頭バイトの番号に設定されることが可能であり、このことは、以下のとおり、項に寄与することが可能である。すなわち、Ｃ０×Ａ０。例えば、Ａ０は、擬似ランダムの、事前計算された、固定の値であることが可能であり、あるいはＡ０は、例えば、擬似ランダムストリームＡｉにおいてＡ１に先行する３２ビットの値であることが可能であり、Ｃ０は、アプリケーションパケットに先行する先頭ビットである。
【００６０】
Ａ０が、３２ビット境界の倍数にはない、任意のＣ０（先頭バイト番号）に関する擬似ランダムストリームＡｉにおいてＡ１に先行する３２ビットの値であるものと想定して、Ａ０が、先頭バイト番号を含むブロックに先行する３２ビット擬似ランダムブロックに設定される。また、ＲＬＰフローの最先頭、例えば、バイト０、１、２、および３に関して、先行するブロックが全く存在しないため、さらなるステップも要求される。例示として、Ａ０が、第６の擬似ランダムビットＡＥＳｋ（３，０）の最後のバイトであるように設定されることが可能であり、つまり、Ａ０＝ＡＥＳｋ（１，２６４−１）として設定されることが可能であり、ＡＥＳｋ（１，２６４−１）は、０ ｍｏｄ ２６４に先行する値である。ＲＬＰストリームが、２６４の３２ビットブロックに達することは、事実上、不可能であることに留意されたい。したがって、ＡＥＳに入力されるバイト番号全体は、６４ビットであるものと想定される。したがって、部分的３２ビットタグを作成するのに、Ｃ０が、先頭バイト番号（３２ビット）であり、さらに、Ａ０が、擬似ランダムストリームＡｉにおいてＡ１に先行する３２ビットマスク、例えば、Ａ０＝先行するＡＥＳｋ（１，．．．）出力ビットの最後の３２ビットである。ＲＬＰフローの最先頭の４バイトに関するＣ０に関するＡ０は、特に、前述したとおり作成される。
【００６１】
第７の擬似ランダムビットＡＥＳｋ（２，ＬａｓｔＢｙｔｅＮｕｍｂｅｒ）を使用して、暗号化されたタグ（認証タグ）を作成する際、異なるバイト番号で終わるアプリケーションパケットは、異なる暗号化タグを有する。やはり、第７の擬似ランダムビットを作成する方法は、前述した、第３の擬似ランダムビット、および第５の擬似ランダムビットを作成する方法と同一であることが可能である。タグを暗号化するのに、１２８ビットのブロック番号は、使用されず、ＡＥＳ入力として正確な最後のバイト番号が、使用されることが可能である。異なる２つのメッセージ、例えば、３２ビット長のメッセージＭの倍数、およびメッセージＭと、その後に続く０のバイトが、同一のタグを作成する可能性がある。しかし、各メッセージは、ランダムなストリングが、各メッセージに関して追加されるため、異なる仕方で暗号化される。
【００６２】
３２ビットの非倍数で始まり、３２ビットの非倍数で終わるが、同一のアプリケーションパケットに属するＲＬＰセグメントに関して、Ａｉは、ＲＬＰセグメントの先頭バイトにおいて、さらに、次のＲＬＰセグメントの先頭バイトにおいても、再使用されることが可能である。図８を参照して、３２ビットの非倍数で終わるアプリケーションパケットと、３２ビットの非倍数で始まる次のアプリケーションパケットとが、説明される。
【００６３】
ＲＬＰパケットは、４バイトＣｉを完成させるように０で満たされることが可能である。この場合、Ａｉは、両方のアプリケーションパケットに関して再使用されることが可能である。つまり、Ａｉは、第１のアプリケーションパケットの終端で使用され、第２のアプリケーションパケットの先頭で再び使用される。
【００６４】
第２のアプリケーションパケットの先頭バイトは、現在のｉに基づいて、４バイトＡｉを使用しつづけ、ただし、ｉは、（ＬａｓｔＢｙｔｅＮｕｍｂｅｒ／４）に等しい。第１のアプリケーションパケットの終端バイト、例えば、４Ｘ＋１バイト、４Ｘ＋２バイト、または４Ｘ＋３バイトに関して、最後のバイトに関連する３２ビットＡｉ、すなわち、（ＬａｓｔＢｙｔｅＮｕｍｂｅｒ／４）に等しいｉが、使用される。
【００６５】
本発明の例示的な実施形態は、アプリケーションパケット全体を再組み立てするのを待つ必要なしに、データが受信されるにつれて、メッセージ認証タグ検証を「オンザフライ」で可能にする。これらの例示的な実施形態は、バイトレベルの暗号化処理および認証処理、ならびにアウトオブオーダー処理を可能にする。
【００６６】
本発明の例示的な実施形態が、このように説明されたので、これらの実施形態が、多くの仕方で変更されることが可能であることが明白となろう。そのような変形形態は、本発明からの逸脱と見なされるべきではなく、そのようなすべての修正形態は、本発明の範囲に含められるべきものとする。
【特許請求の範囲】
【請求項１】
送信のためのアプリケーションパケットを処理するための方法であって、
アプリケーションパケットを複数のセグメントに分割し、
第１の擬似ランダムビットを作成し、
複数のセグメントのそれぞれと、複数のセグメントのそれぞれに関連する第１の擬似ランダムビットの諸部分とに基づいて、部分的タグを生成し、
アプリケーションパケットの最後のセグメントに関連する最後の部分的タグを含め、部分的タグを組み合わせて、蓄積されたタグを作成し、
蓄積されたタグと、第２の擬似ランダムビットとに基づいて、認証タグを生成し、
認証タグを格納し、および
認証タグを含む複数のセグメントを送信することを含む、方法。
【請求項２】
認証タグを生成することが、蓄積されたタグと、第２の擬似ランダムビットに対して排他論理和演算を実行することを含む、請求項１に記載の方法。
【請求項３】
第２の擬似ランダムビットが、第２の擬似ランダムビットのｌｓｂ（最下位ビット）である、請求項２に記載の方法。
【請求項４】
複数のセグメントに対して、第３の擬似ランダムビットのそれぞれの部分との排他論理和演算を実行することによって、複数のセグメントを暗号化して、暗号文ブロックを作成することをさらに含む、請求項１に記載の方法。
【請求項５】
第１の擬似ランダムビット、第２の擬似ランダムビット、および第３の擬似ランダムビットが、鍵ｋと、暗号同期値とを用いるＡＥＳ（高度暗号化標準）を使用して作成される、請求項４に記載の方法。
【請求項６】
部分的タグの生成が、アプリケーションパケットの先頭バイト番号に、鍵ｋと、そのアプリケーションパケットに先行するバイト番号である暗号同期値とを用いるＡＥＳを使用して作成された第４の擬似ランダムビットを掛けることを含む、請求項５に記載の方法。
【請求項７】
複数のセグメントの最後のセグメントの再送を求める要求を受信し、
複数のセグメントの最後のセグメントに、格納された認証タグを付加し、および
最後のセグメントと、認証タグとを再送することをさらに含む、請求項１に記載の方法。
【請求項８】
最後のセグメントを複数の断片に再細分化することをさらに含み、再送することが、複数の断片と、認証タグとを送信する、請求項７に記載の方法。
【請求項９】
複数のセグメントのそれぞれが、ブロックサイズの倍数である、請求項１に記載の方法。
【請求項１０】
複数のセグメントが、ブロックサイズの倍数ではない場合、
ブロックサイズの倍数であるセグメントを識別し、および
ブロックサイズセグメントの倍数の先頭に０を予め付加することと、ブロックサイズセグメントの倍数の終端に０を付加することの少なくとも１つを実行することをさらに含む、請求項１に記載の方法。
【請求項１１】
受信されたアプリケーションパケットセグメントを処理する方法であって、
認証タグを含むアプリケーションパケットの複数のセグメントを受信し、
第１の擬似ランダムビットを作成し、
受信された複数のセグメントのそれぞれと、受信された複数のセグメントのそれぞれに関連する第１の擬似ランダムビットの諸部分とに基づいて、部分的タグを生成し、
部分的タグ、受信された複数のセグメント、および受信された認証タグをメモリの中に格納し、
受信された複数のセグメントを組み合わせて、アプリケーションパケットを作成し、
部分的タグを組み合わせて、計算されたタグを作成し、および
計算されたタグと、受信された認証タグとに基づいて、アプリケーションパケットの真正性を検証することを含む、方法。
【請求項１２】
第１の擬似ランダムビットが、鍵ｋと、暗号同期値とを用いるＡＥＳ（高度暗号化標準）を使用して作成される、請求項１１に記載の方法。
【請求項１３】
複数のセグメントの受信された最後のセグメントに関する最後の部分的タグを作成し、および
最後の部分的タグに対して、第２の擬似ランダムビットのｌｓｂ（最下位ビット）との排他論理和演算を実行することをさらに含む、請求項１１に記載の方法。
【請求項１４】
第２の擬似ランダムビットが、鍵ｋと、暗号同期値とを用いるＡＥＳ（高度暗号化標準）を使用して作成される、請求項１３に記載の方法。
【請求項１５】
複数のセグメントの最後のセグメントの再送を受信し、
複数のセグメントの受信された最後のセグメントに関する最後の部分的タグを作成し、および
最後の部分的タグに対して、第２の擬似ランダムビットのｌｓｂ（最下位ビット）との排他論理和演算を実行することをさらに含む、請求項１１に記載の方法。
【請求項１】
送信のためのアプリケーションパケットを処理するための方法であって、
アプリケーションパケットを複数のセグメントに分割し、
第１の擬似ランダムビットを作成し、
複数のセグメントのそれぞれと、複数のセグメントのそれぞれに関連する第１の擬似ランダムビットの諸部分とに基づいて、部分的タグを生成し、
アプリケーションパケットの最後のセグメントに関連する最後の部分的タグを含め、部分的タグを組み合わせて、蓄積されたタグを作成し、
蓄積されたタグと、第２の擬似ランダムビットとに基づいて、認証タグを生成し、
認証タグを格納し、および
認証タグを含む複数のセグメントを送信することを含む、方法。
【請求項２】
認証タグを生成することが、蓄積されたタグと、第２の擬似ランダムビットに対して排他論理和演算を実行することを含む、請求項１に記載の方法。
【請求項３】
第２の擬似ランダムビットが、第２の擬似ランダムビットのｌｓｂ（最下位ビット）である、請求項２に記載の方法。
【請求項４】
複数のセグメントに対して、第３の擬似ランダムビットのそれぞれの部分との排他論理和演算を実行することによって、複数のセグメントを暗号化して、暗号文ブロックを作成することをさらに含む、請求項１に記載の方法。
【請求項５】
第１の擬似ランダムビット、第２の擬似ランダムビット、および第３の擬似ランダムビットが、鍵ｋと、暗号同期値とを用いるＡＥＳ（高度暗号化標準）を使用して作成される、請求項４に記載の方法。
【請求項６】
部分的タグの生成が、アプリケーションパケットの先頭バイト番号に、鍵ｋと、そのアプリケーションパケットに先行するバイト番号である暗号同期値とを用いるＡＥＳを使用して作成された第４の擬似ランダムビットを掛けることを含む、請求項５に記載の方法。
【請求項７】
複数のセグメントの最後のセグメントの再送を求める要求を受信し、
複数のセグメントの最後のセグメントに、格納された認証タグを付加し、および
最後のセグメントと、認証タグとを再送することをさらに含む、請求項１に記載の方法。
【請求項８】
最後のセグメントを複数の断片に再細分化することをさらに含み、再送することが、複数の断片と、認証タグとを送信する、請求項７に記載の方法。
【請求項９】
複数のセグメントのそれぞれが、ブロックサイズの倍数である、請求項１に記載の方法。
【請求項１０】
複数のセグメントが、ブロックサイズの倍数ではない場合、
ブロックサイズの倍数であるセグメントを識別し、および
ブロックサイズセグメントの倍数の先頭に０を予め付加することと、ブロックサイズセグメントの倍数の終端に０を付加することの少なくとも１つを実行することをさらに含む、請求項１に記載の方法。
【請求項１１】
受信されたアプリケーションパケットセグメントを処理する方法であって、
認証タグを含むアプリケーションパケットの複数のセグメントを受信し、
第１の擬似ランダムビットを作成し、
受信された複数のセグメントのそれぞれと、受信された複数のセグメントのそれぞれに関連する第１の擬似ランダムビットの諸部分とに基づいて、部分的タグを生成し、
部分的タグ、受信された複数のセグメント、および受信された認証タグをメモリの中に格納し、
受信された複数のセグメントを組み合わせて、アプリケーションパケットを作成し、
部分的タグを組み合わせて、計算されたタグを作成し、および
計算されたタグと、受信された認証タグとに基づいて、アプリケーションパケットの真正性を検証することを含む、方法。
【請求項１２】
第１の擬似ランダムビットが、鍵ｋと、暗号同期値とを用いるＡＥＳ（高度暗号化標準）を使用して作成される、請求項１１に記載の方法。
【請求項１３】
複数のセグメントの受信された最後のセグメントに関する最後の部分的タグを作成し、および
最後の部分的タグに対して、第２の擬似ランダムビットのｌｓｂ（最下位ビット）との排他論理和演算を実行することをさらに含む、請求項１１に記載の方法。
【請求項１４】
第２の擬似ランダムビットが、鍵ｋと、暗号同期値とを用いるＡＥＳ（高度暗号化標準）を使用して作成される、請求項１３に記載の方法。
【請求項１５】
複数のセグメントの最後のセグメントの再送を受信し、
複数のセグメントの受信された最後のセグメントに関する最後の部分的タグを作成し、および
最後の部分的タグに対して、第２の擬似ランダムビットのｌｓｂ（最下位ビット）との排他論理和演算を実行することをさらに含む、請求項１１に記載の方法。
【図１】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５】
【図６】
【図７】
【図８】
【公表番号】特表２０１０−５０７９８２（Ｐ２０１０−５０７９８２Ａ）
【公表日】平成２２年３月１１日（２０１０．３．１１）
【国際特許分類】
【出願番号】特願２００９−５３４６１０（Ｐ２００９−５３４６１０）
【出願日】平成１９年１０月２２日（２００７．１０．２２）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０２２４０９
【国際公開番号】ＷＯ２００８／１０８８２８
【国際公開日】平成２０年９月１２日（２００８．９．１２）
【出願人】（５９６０９２６９８）アルカテル−ルーセント ユーエスエー インコーポレーテッド (965)
【Ｆターム（参考）】
【公表日】平成２２年３月１１日（２０１０．３．１１）
【国際特許分類】
【出願日】平成１９年１０月２２日（２００７．１０．２２）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０２２４０９
【国際公開番号】ＷＯ２００８／１０８８２８
【国際公開日】平成２０年９月１２日（２００８．９．１２）
【出願人】（５９６０９２６９８）アルカテル−ルーセント ユーエスエー インコーポレーテッド (965)
【Ｆターム（参考）】
[ Back to top ]