(57)【要約】  開示されるのは、送信用アプリケーションパケットを処理するための方法であって、バイトストリーム中のアプリケーションパケットの複数のセグメントを受信するステップと、いくつかの数の複数のブロックをバイトストリーム内でグループ化することにより複数のスーパーブロックをバイトストリーム内で生成するステップと、第１の疑似ランダムビットを複数のスーパーブロックについて生成するステップと、複数のセグメントのそれぞれの先頭および末尾についてのブロック番号およびスーパーブロック番号を決定するステップと、部分タグをセグメントのそれぞれについて、バイトストリーム中の複数のセグメントの決定された先頭と末尾の間のブロック番号およびスーパーブロック番号に関連付けられた第１の疑似ランダムビットに基づいて生成するステップと、部分タグを累積されたタグを生成するために組み合わせるステップと、認証タグを累積されたタグおよび第２の疑似ランダムビットに基づいて生成するステップと、認証タグを記憶するステップと、セグメントを認証タグを含めて送信するステップとを含む、方法である。
2010510756.tif 000002
【特許請求の範囲】
【請求項１】
送信用アプリケーションパケットを処理するための方法であって、
バイトストリーム中のアプリケーションパケットの複数のセグメントを受信するステップであって、バイトストリームが複数のブロックを含む、ステップと、
いくつかの数の複数のブロックをバイトストリーム内でグループ化することにより複数のスーパーブロックをバイトストリーム内で生成するステップと、
第１の疑似ランダムビットを複数のスーパーブロックについて生成するステップと、
ブロック番号およびスーパーブロック番号を複数のセグメントのそれぞれの先頭について決定するステップと、
ブロック番号およびスーパーブロック番号をバイトストリーム中の複数のセグメントのそれぞれの末尾について決定するステップと、
バイトストリーム中の複数のセグメントの決定された先頭と末尾の間のブロック番号およびスーパーブロック番号に関連付けられた第１の疑似ランダムビットに基づいて、バイトストリーム中の複数のセグメントのそれぞれについて部分タグを生成するステップと、
部分タグを、アプリケーションパケットの最終セグメントに関連付けられた最終部分タグを含めて、累積されたタグを生成するために組み合わせるステップと、
認証タグを累積されたタグおよび第２の疑似ランダムビットに基づいて生成するステップと、
認証タグを記憶するステップと、
複数のセグメントを認証タグを含めて送信するステップとを含む、方法。
【請求項２】
認証タグを生成するステップが、排他的論理和演算を累積されたタグおよび第２の疑似ランダムビットに対して実行するステップを含む、請求項１に記載の方法。
【請求項３】
複数のセグメントのそれぞれについて部分タグを生成するステップにおいて、部分タグが、
部分タグ＝Ｃ１（ＡＳ）＋Ｃ２（ＡＳ）ｂ＋１＋．．．＋Ｃｎ−ｂ＋１（ＡＳ）ｎ＋Ｃ（Ｓ２−Ｓ１）ｎ−ｂ＋２（ＡＳ２）＋．．．＋Ｃ（Ｓ２−Ｓ１）ｎ−ｂ＋１＋ｂ２（ＡＳ２）ｂ２
であり、ここでＳがスーパーブロック番号、ｂがスーパーブロック内のブロック番号、ｎがスーパーブロック内のブロックの数、Ｃがセグメント内のブロック番号、およびＡＳが第１の疑似ランダムビットである、請求項１に記載の方法。
【請求項４】
複数のセグメントに対して第３の疑似ランダムビットのそれぞれの部分について排他的論理和演算を行って暗号文ブロックを生成することによって、複数のセグメントを暗号化するステップをさらに含む、請求項１に記載の方法。
【請求項５】
部分タグの生成が、アプリケーションパケットの先頭バイト番号を第４の疑似ランダムビットで乗じ、第４の疑似ランダムビットが鍵ｋおよび暗号同期値を備えるＡＥＳを使用して生成され、暗号同期値がアプリケーションパケットに先行するバイト番号である、ステップを含む、請求項１に記載の方法。
【請求項６】
複数のセグメントの最終セグメントの再送信のリクエストを受信するステップと、
記憶された認証タグを複数のセグメントの最終セグメントに付加するステップと、
最終セグメントおよび認証タグを再送信するステップとをさらに含む、請求項１に記載の方法。
【請求項７】
最終セグメントを複数のフラグメントに再フラグメント化するステップであって、再送信するステップが複数のフラグメントおよび認証タグを送信する、ステップをさらに含む、請求項６に記載の方法。
【請求項８】
複数のセグメントがブロックサイズの倍数でない場合に、
ブロックサイズの倍数であるセグメントを識別するステップと、
ブロックサイズの倍数であるセグメントの先頭の前にゼロを付加するステップ、およびブロックサイズの倍数であるセグメントの末尾にゼロを付加するステップの少なくとも１つを実行するステップとをさらに含む、請求項１に記載の方法。
【請求項９】
受信されたアプリケーションパケットセグメントを処理する方法であって、
バイトストリーム中のアプリケーションパケットの複数のセグメントを受信するステップであって、バイトストリームが複数のブロックを含む、ステップと、
いくつかの数の複数のブロックをバイトストリーム内でグループ化することにより複数のスーパーブロックをバイトストリーム内で生成するステップと、
第１の疑似ランダムビットを複数のスーパーブロックについて生成するステップと、
ブロック番号およびスーパーブロック番号を複数のセグメントのそれぞれの先頭について決定するステップと、
ブロック番号およびスーパーブロック番号をバイトストリーム中の複数のセグメントのそれぞれの末尾について決定するステップと、
バイトストリーム中の複数のセグメントの決定された先頭と末尾の間のブロック番号およびスーパーブロック番号に関連付けられた第１の疑似ランダムビットに基づいて、バイトストリーム中の複数のセグメントのそれぞれについて部分タグを生成するステップと、
部分タグ、受信された複数のセグメント、および受信された認証タグをメモリ中に記憶するステップと、
受信された複数のセグメントをアプリケーションパケットを生成するために組み合わせるステップと、
部分タグを計算されたタグを生成するために組み合わせるステップと、
アプリケーションパケットの信頼性を計算されたタグと受信された認証タグとに基づいて検証するステップとを含む、方法。
【請求項１０】
複数のセグメントのそれぞれについて部分タグを生成するステップにおいて、部分タグが、
部分タグ＝Ｃ１（ＡＳ）＋Ｃ２（ＡＳ）ｂ＋１＋．．．＋Ｃｎ−ｂ＋１（ＡＳ）ｎ＋Ｃ（Ｓ２−Ｓ１）ｎ−ｂ＋２（ＡＳ２）＋．．．＋Ｃ（Ｓ２−Ｓ１）ｎ−ｂ＋１＋ｂ２（ＡＳ２）ｂ２
であり、ここでＳがスーパーブロック番号、ｂがスーパーブロック内のブロック番号、ｎがスーパーブロック内のブロックの数、Ｃがセグメント内のブロック番号、ＡＳが第１の疑似ランダムビットである、請求項９に記載の方法。
【請求項１１】
最終部分タグを複数のセグメントの受信された最終セグメントについて生成するステップと、
排他的論理和演算を最終部分タグに対して第２の疑似ランダムビットの最下位ビット（ｌｓｂ）について行うステップとをさらに含む、請求項９に記載の方法。
【請求項１２】
複数のセグメントの最終セグメントの再送信を受信するステップと、
最終部分タグを複数のセグメントの受信された最終セグメントについて生成するステップと、
排他的論理和演算を最終部分タグに対して第２の疑似ランダムビットの最下位ビット（ｌｓｂ）について行うステップとをさらに含む、請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本非仮特許出願は、米国特許法第１１９条（ｅ）（１）に基づき、２００６年１１月２１日に出願された仮特許出願第６０／８６０，３３０号に対する優先権を主張し、その開示のすべてが組み込まれる。本非仮特許出願はまた、米国特許法第１２０条に基づき、２００７年１０月２２日に出願された非仮特許出願第１１／９７６，１２６号に対する優先権を主張し、その開示のすべてが組み込まれる。
【背景技術】
【０００２】
暗号化とメッセージ認証／完全性は共に、無線エアインターフェース上でセキュリティを備えるために必要である。メッセージの暗号化がメッセージのプライバシーを保護するのに対して、メッセージ認証はメッセージを改ざんから保護する。
【０００３】
メッセージ認証プロセスにおいて、秘密鍵およびメッセージ認証アルゴリズムを使用する送信器は、短いタグを計算し、これがメッセージに添加される。受信器も、受信されたメッセージについてのタグを秘密鍵の知識に基づいて計算し、計算されたタグを受信されたタグと比較する。タグが同じであれば、受信器はメッセージを受け入れ、そうでなければメッセージは廃棄される。
【０００４】
既存のメッセージ認証アルゴリズム、たとえば鍵付ハッシュメッセージ認証コード−セキュアハッシュアルゴリズム（ＨＭＡＣ−ＳＨＡ）および高度暗号化標準−暗号ブロック連鎖（ＡＥＳ−ＣＢＣ）中の暗号アルゴリズムは、これらが一連の演算であり、送信された順にビットが処理される必要があるために異常なパケットの処理ができない。そのために、メッセージ認証の従来の手法では、データをＲＡＭに送信し、中央処理装置（ＣＰ）にデータパケットの順序を並べ替えさせてアプリケーションパケット（メッセージ）の再組み立てを行い、アプリケーションパケットをハードウェアに送ってメッセージ認証を行わなければならない。これによってバス上のトラフィックが大幅に増加し、パケット処理の待ち時間が著しく増える可能性がある。
【０００５】
さらに、既存のメッセージ認証アルゴリズムは、一時にブロックに対する演算を行う。その結果、ブロックレベルのアルゴリズムは、非ブロック境界中で終了するメッセージセグメントに対する演算ができない。メッセージ認証タグの検証を開始する前に、すべてのメッセージセグメントから全てのアプリケーションパケットを再組み立てする必要が出てくる。
【発明の概要】
【課題を解決するための手段】
【０００６】
本発明の例示の実施形態において、送信用アプリケーションパケットを処理するための方法は、バイトストリーム中のアプリケーションパケットの複数のセグメントを受信するステップであって、バイトストリームが複数のブロックを含む、ステップと、いくつかの数の複数のブロックをバイトストリーム内でグループ化することにより複数のスーパーブロックをバイトストリーム内で生成するステップと、第１の疑似ランダムビットを複数のスーパーブロックについて生成するステップと、ブロック番号およびスーパーブロック番号を複数のセグメントのそれぞれの先頭について決定するステップとを含む。本方法はまた、ブロック番号およびスーパーブロック番号をバイトストリーム中の複数のセグメントのそれぞれの末尾について決定するステップと、バイトストリーム中の複数のセグメントのそれぞれの決定された先頭と末尾の間のブロック番号およびスーパーブロック番号に関連付けられた第１の疑似ランダムビットに基づいて、バイトストリーム中の複数のセグメントのそれぞれについて部分タグを生成するステップとを含む。本方法は、部分タグを、アプリケーションパケットの最終セグメントに関連付けられた最終部分タグを含めて、累積されたタグを生成するために組み合わせるステップと、認証タグを累積されたタグおよび第２の疑似ランダムビットに基づいて生成するステップと、認証タグを記憶するステップと、複数のセグメントを認証タグを含めて送信するステップとをさらに含む。
【０００７】
他の例示の実施形態において、受信されたアプリケーションパケットセグメントを処理する方法は、バイトストリーム中のアプリケーションパケットの複数のセグメントを受信するステップであって、バイトストリームが複数のブロックを含む、ステップと、いくつかの数の複数のブロックをバイトストリーム内でグループ化することにより複数のスーパーブロックをバイトストリーム内で生成するステップと、第１の疑似ランダムビットを複数のスーパーブロックについて生成するステップと、ブロック番号およびスーパーブロック番号を複数のセグメントのそれぞれの先頭について決定するステップとを含む。本方法はまた、ブロック番号およびスーパーブロック番号をバイトストリーム中の複数のセグメントのそれぞれの末尾について決定するステップと、バイトストリーム中の複数のセグメントのそれぞれの決定された先頭と末尾の間のブロック番号およびスーパーブロック番号に関連付けられた第１の疑似ランダムビットに基づいて、バイトストリーム中の複数のセグメントのそれぞれについて部分タグを生成するステップとを含む。本方法は、部分タグ、受信された複数のセグメント、および受信された認証タグをメモリ中に記憶するステップと、受信された複数のセグメントをアプリケーションパケットを生成するために組み合わせるステップと、部分タグを計算されたタグを生成するために組み合わせるステップと、アプリケーションパケットの信頼性を計算されたタグおよび受信された認証タグに基づいて検証するステップとをさらに含む。
【０００８】
本発明の例示の実施形態は、本明細書の以下に与えられた詳細な説明、および付属の図面からさらに十分に理解され、付属の図面は、説明のみを目的として与えられており、そのために本発明の例示の実施形態を限定するものではない。
【図面の簡単な説明】
【０００９】
【図１】本発明の例示の実施形態による論理暗号化方式の流れ図である。
【図２】図１の実施形態を図表で示す例である。
【図３】本発明の例示の実施形態による完全性タグ生成の流れ図である。
【図４Ａ】図３の完全性タグ生成法を図表で示す例である。
【図４Ｂ】図３の方法による累積演算の図である。
【図５】本発明の例示の実施形態によるＲＬＰセグメントの再送信のための流れ図である。
【図６】本発明の例示の実施形態による復号化およびインライン完全性検査の流れ図である。
【図７】本発明の例示の実施形態による可変長アプリケーションパケットについての部分タグの計算法である。
【発明を実施するための形態】
【００１０】
本明細書において、第１、第２、第３などの用語が様々な要素、構成部品、領域および／またはセクションを説明するために使用されうるが、これらの要素、構成部品、領域および／またはセクションが、これらの用語に限定されるべきでないことが理解されよう。これらの用語は、１つの要素、構成部品、領域、またはセクションを他の領域またはセクションから区別するために使用されているにすぎない可能性がある。したがって、下に述べる第１の要素、構成部品、領域またはセクションは、本発明の教示から逸脱することなく、第２の要素、構成部品、領域またはセクションと表記しうる。
【００１１】
本明細書で使用される専門用語は、特定の例示の実施形態を説明する目的のみで使用されており、限定することは意図されていない。用語「含む（ｃｏｍｐｒｉｓｅｓ）」および／または「含んでいる（ｃｏｍｐｒｉｓｉｎｇ）」は、本明細書で使用されるときは、述べられた特性、整数、ステップ、動作、要素、および／または構成部品の存在を指定するが、１つまたは複数の他の特性、整数、ステップ、動作、要素、構成部品、および／またはそのグループの存在または追加を排除しないことはさらに理解されよう。
【００１２】
例示の実施形態は、本明細書において、理想化された実施形態（および中間的な構造）の模式図の可能性がある断面図を参照しつつ説明されていることがありうる。そのため、例示の実施形態は、本明細書で図示される特定の位置および構成に限定されると解釈されるべきではなく、それから逸脱するものも含まれる。
【００１３】
別段に定義されない限り、本明細書で使用されるすべての用語（技術用語および科学用語を含めて）は、当業者に通常理解されるのと同じ意味を有する。日常的に使用される辞書中で定義されるような用語は、関連する技術の文脈における意味と一致する意味を持つものとして解釈されるべきであり、本明細書で明示的にそのように定義されない限り理想化されないこと、または過度に形式的な意味で解釈されないことがさらに理解されよう。
【００１４】
本発明は、送信器と受信器の間のメッセージ認証に関する。送信器は、パケット通信を送ることが可能な任意のよく知られている無線通信システム中の任意の通信装置であってよい。たとえば、送信器は、移動局、基地局などでありうる。理解されるように、移動局は、携帯電話、ＰＤＡ、携帯型コンピュータなどでありうる。受信器は、移動局、基地局などの任意の送信器の受信側相対物でありうる。さらに本発明は、無線および／またはネットワーク通信に適用されうることが理解されよう。
【００１５】
本発明の実施形態によるメッセージ認証が最もよく理解されるように、メッセージ暗号化についてまず説明する。暗号化の理解のために、第１に無線リンクプロトコルを説明する。
【００１６】
無線リンクプロトコル
無線リンクプロトコル（ＲＬＰ）は、アクセスターミナル（ＡＴ）（移動局としても知られている）とアクセスノード（ＡＮ）（基地局としても知られている）の間の無線エアインターフェース上で動作するセグメント化用かつ再組み立て用のプロトコルである。ＲＬＰは、アプリケーションパケットが効率的にＲＦリンク上で送信されることができるように、アプリケーションパケットをＲＬＰセグメントまたはパケット中にフラグメント化（セグメント化）する役目を負う。さらにＲＬＰは、受信器においてのＲＬＰセグメントの再組み立て、順次パケットからの再順序付け、送信中にセグメントが失われた際の再送信を行う役目を負う。
【００１７】
メッセージ暗号化
暗号化および／または認証／完全性は、ＲＬＰセグメント上で実行されてよい。たとえば、よく知られているカウンタモード（ＣＴＲ）暗号化が、ＲＬＰセグメントの暗号化に使用されてよい。
【００１８】
暗号化されるべきＲＬＰセグメント（たとえばメッセージ、データ、音声など）は通常平文と呼ばれ、暗号化プロセスの結果は暗号文と呼ばれる。しばしば暗号化プロセスは、暗号文を得るために平文に対して暗号化アルゴリズムを実行することを必要とする。データ暗号化標準（ＤＥＳ）、高度暗号化標準（ＡＥＳ）などの多くの暗号化アルゴリズムは、暗号化プロセス中に鍵の使用を必要とする。暗号化鍵は、暗号化アルゴリズムの中で暗号文を生成するために使用されるビット列である。暗号化鍵は、通信の送信側および受信側の双方に知られていて、暗号化鍵は受信側で暗号文を平文に復号化するために使用される。
【００１９】
ＡＮとＡＴの間で送信される情報のフレームの暗号化が必要となる無線通信環境での暗号化の場合、同じ情報（すなわち、同じ平文）が２つの異なるフレーム中に送信される際に問題が生じる。その環境では、２つのフレームのそれぞれについて同じ暗号文が作成される。そのような場合、暗号文上の情報は、漏洩されたという。そのような漏洩された暗号文によって発生しうるリプレイ攻撃を阻止するために、暗号同期（ｃｒｙｐｔｏｓｙｎｃ）を使用する暗号化技術が開発されている。暗号同期は、たとえば、暗号化のための暗号同期の使用後毎に漸増するカウント値を含む。この方式では、時が経つにつれて暗号同期が変化する。暗号同期の典型的な用途においては、暗号化アルゴリズムが暗号同期に、あたかもその暗号同期が平文であるかのように適用される。その結果もたらされる出力は、マスクとして参照される。マスクはその後、暗号化用の情報（たとえばＲＬＰセグメント）についての排他的論理和演算が行われて暗号文を生成する。暗号化鍵と同様に、暗号同期は、送信側および受信側の双方に知られており、暗号同期は、受信側において暗号文を平文に復号化するために使用される。
【００２０】
アプリケーションパケット暗号化
本発明の実施形態によるメッセージの完全性をよりよく理解するために、メッセージの完全性に適用されるアプリケーションパケットの暗号化法について簡潔に説明する。
【００２１】
図１は本発明の例示の実施形態による論理暗号化方式の流れ図であり、図２はこのプロセスを図表で示す例である。
【００２２】
例示の実施形態において、アプリケーションパケットの無線リンクプロトコル（ＲＬＰ）セグメントは、他のアプリケーションパケットのＲＬＰセグメントが挟まれることなく暗号化のために送信されると仮定されている。説明のみの目的で、６４，０００バイトのアプリケーションパケットはＲＬＰストリームの９００１番目のバイト上で送信され、およびＲＬＰセグメントは８バイトの倍数であることもまた仮定されている。言い換えると、ＲＬＰセグメントは、ブロックサイズの倍数である。当業者には理解されるように、アプリケーションパケットのサイズ、ＲＬＰバイトストリーム、およびＲＬＰセグメントのサイズはすべて変更されてよい。
【００２３】
図１および図２を参照すると、送信器は、６４，０００バイトの長さのアプリケーションパケットまたはデータパケットをブロックサイズの倍数、たとえば、８バイトの平文ブロックＭ１−Ｍ８０００に論理的に分割する（ステップＳ１００）。図２はブロックＭ１からブロックＭ８を示す。
【００２４】
２つの引数（入力）（たとえば鍵ｋおよびバイト番号に基づく暗号同期値）を持つ高度暗号化標準（ＡＥＳ）を使用して、ステップＳ１１０で、第１の疑似ランダムブロック（ビット）ＡＥＳｋ（０，９００１）−ＡＥＳｋ（０，９０４９）を生成しうる。図２では、名称（すなわちＴＹＰＥ「０」）が第１の疑似ランダムビットを他の疑似ランダムビットと区別するために使用されている。下を参照されたい。
【００２５】
さらに詳細には、第１の疑似ランダムビットＡＥＳｋ（０，９００１）−ＡＥＳｋ（０，９０４９）が以下のように記述されてよい：
第１の疑似ランダムビット（ＯＵＴＰＵＴ）＝ＡＥＳ（ｋ，ＩＮＰＵＴ）
【００２６】
ＡＥＳに対する暗号同期値（ＩＮＰＵＴ）は、ＴＹＰＥ（たとえば８ビット）およびＣＯＵＮＴＥＲ（たとえば６４ビット）の２つの部分に分割されてよく、ＩＮＰＵＴビットの残余は、ゼロに設定されてよい。一般的に知られているように、すべてのＩＮＰＵＴ値がＡＥＳに対して重複することがないことを保証するために、ＣＯＵＮＴＥＲ値は特定のＴＹＰＥ値について重複すべきではない。また、「ＴＹＰＥ」が、様々な疑似ランダムビットを生成するためにＡＥＳの用途を区別するために使用される。ＢＹＴＥ＿ＮＵＭＢＥＲが特定のストリームについて重複することは決してないため、第１の疑似ランダムビットを生成するためにＲＬＰストリーム中のバイト番号をＣＯＵＮＴＥＲ値として使用することができる。したがって、鍵ｋおよび暗号同期値は、１２８ビットの出力を生成するために使用可能である。暗号同期値のサイズは変更されてよく、暗号同期値は、他の入力（たとえばフローＩＤ、リセットカウンタなど）を含みうる。以下にさらに詳しく述べる。
【００２７】
次にステップＳ１２０で、図２に示すように、送信器は平文ブロックＭ１からＭ８に対して第１の疑似ランダムビットＡＥＳｋ（０，９００１）−ＡＥＳｋ（０，９０４９）との排他的論理和演算を行い（ＸＯＲが行われ）、暗号化された（暗号文）ブロックＣ１−Ｃ８を生成する。
【００２８】
カウンタモード（ＣＴＲ）の暗号化法を、上のＲＬＰセグメントを暗号化するために説明したが、他のよく知られている暗号化法、たとえば出力フィードバック（ＯＦＢ）モード、暗号フィードバック（ＣＦＢ）モードなども使用されうる。
【００２９】
メッセージの完全性
アプリケーションパケット、より具体的にはＲＬＰセグメントが暗号化されると、アプリケーションパケットについての認証タグを生成するために本発明の例示の実施形態による完全性プロセスをＲＬＰセグメントに対して実行することができる。
【００３０】
また、２つの引数（入力）、たとえば、鍵ｋおよび暗号同期値を備える高度暗号化標準（ＡＥＳ）を使用して、第２の疑似ランダムビットＡｉを生成することができる。
【００３１】
第２の疑似ランダムビットＡｉはそれぞれ、６４ビット（８バイト）である。Ａｉは、「スーパーブロック」として知られているある数のデータブロックについて使用され、たとえばデータブロックの数は５１２とし、各データブロックは８バイトとすることができる。スーパーブロックを形成するデータブロックの数は変更されてよい。
【００３２】
詳細には、高度暗号化標準（ＡＥＳ）（たとえば多項式評価汎用ハッシュに基づく完全性）、鍵ｋおよびＳｕｐｅｒＢｌｏｃｋＮｕｍｂｅｒ  ｉに基づく暗号同期値を使用して、第２の疑似ランダムビットＡＥＳｋ（１，ＳｕｐｅｒＢｌｏｃｋＮｕｍｂｅｒ  ｉ）を生成することができる。名称、すなわちＴＹＰＥ「１」は、第２の疑似ランダムビットを他の疑似ランダムビット（たとえば第１の疑似ランダムビット）と区別するために使用される。
【００３３】
各スーパーブロックについてランダムハッシュキーＡｉが生成され、アプリケーションパケットは何らかの次数の多項式として扱われる。鍵Ａｉは、特定のスーパーブロックについてのみ有効である。鍵Ａｉの冪は、スーパーブロック内で特定のブロックにのみ使われる。
Ａｉ＝ＡＥＳ（１，ｓｕｐｅｒｂｌｏｃｋｎｕｍｂｅｒ  ｉ）、ここでｉ＝ｆｌｏｏｒ（ＲＬＰｂｙｔｅｎｕｍｂｅｒ／５１２×６４）
【００３４】
たとえばアプリケーションパケットは、暗号化されたブロックＣ１中で開始し、暗号化されたブロックＣｎ中で終了する。少し異なる説明をすると、ＲＬＰセグメントは、ある一定のＲＬＰバイト番号およびＲＬＰブロック番号Ｂで開始し、ここでＢはｃｅｉｌｉｎｇ（ＲＬＰｂｙｔｅｎｕｍｂｅｒ／８）である。ＲＬＰブロック番号はスーパーブロックＳ中に確定的にマップされ、ブロック番号ｂはスーパーブロックＳ内で確定的にマップされ、すなわちＢ←→（Ｓ，ｂ）となり、ここでＳ＝ｃｅｉｌｉｎｇ（Ｂ／５１２）、ｂ＝Ｂ−（Ｓ−１）５１２である。
【００３５】
アプリケーションパケットが、スーパーブロックＳ、ブロック番号ｂ中で開始し、スーパーブロックＳ２、ブロック番号ｂ２中で終了すると仮定する。したがって、次の式が完全性タグを計算するために使用される：
ＴＡＧ＝Ｃ１（ＡＳ）ｂ−１＋Ｃ１（ＡＳ）ｂ＋．．．Ｃ５１２−ｂ＋１（ＡＳ）５１２
＋Ｃ５１２−ｂ＋２（ＡＳ＋１）＋Ｃ５１２−ｂ＋３（ＡＳ＋１）２＋．．．Ｃ１０２４−ｂ＋１（ＡＳ＋１）５１２＋Ｃ（Ｓ２−Ｓ１）５１２−ｂ（ＡＳ２）＋．．．
Ｃ（Ｓ２−Ｓ１）５１２−ｂ＋ｂ２（ＡＳ２）ｂ２＋ＡＥＳ（２，ＬａｓｔＢｙｔｅＮｕｍｂｅｒ）６４ビット
【００３６】
本発明の例示の実施形態において、ＲＬＰセグメントがＲＬＰバイト番号９０００において開始し、ＲＬＰセグメントバイト番号９２３９において終了すると仮定する。また、ビットストリームが１において開始し、進み続けると仮定する。したがって、スーパーブロック１は、ビットストリーム１で開始し、ビットストリーム４０９６（スーパーブロック中の５１２ブロック）で終了し、スーパーブロック２は、ビットストリーム４０９７で開始し、ビットストリーム８１９２で終了し、スーパーブロック３は、ビットストリーム８１９３で開始し、ビットストリーム１２，２８８で終了し、以後も同様である。
【００３７】
第１のブロックはＲＬＰバイト番号９００１またはＲＬＰブロック番号Ｂ＝９００１／８＝１１２６で開始し、末尾ブロックは、ＲＬＰバイト番号９２４０またはＲＬＰブロック番号Ｂ＝９２４０／８＝１１５５で終了する。先頭および末尾ＲＬＰバイト番号を知ることにより、ＲＬＰセグメントがスーパーブロック３内で開始し終了すると決定できる。先頭および末尾ブロック番号は、先頭Ｂを（Ｓ，ｂ）＝（３，１０２）にマッピングし、末尾Ｂを（Ｓ，ｂ）＝（３，１３１）にマッピングすることによって決定できる。
【００３８】
したがって、次の式が部分タグを計算するために使用される：
部分タグ＝Ｃ１（Ａ３）１０２＋Ｃ２（Ａ３）１０３＋．．．＋Ｃ３０（Ａ３）１３１
【００３９】
部分タグは、アプリケーションパケット中の各ＲＬＰセグメントについて計算される。各部分タグが計算された後に、部分タグは累積器に送信される。最終ＲＬＰセグメントの最終部分タグが計算された後に、すべての部分タグは、累積されたタグを第３の疑似ランダムビットＡＥＳ（２，ＬａｓｔＢｙｔｅＮｕｍｂｅｒ）６４ビットの最下位ビット（ｌｓｂ）とＸＯＲすることにより累積され、さらに暗号化される。
【００４０】
図３は、本発明の例示の実施形態による完全性（認証）タグ生成の流れ図である。図４Ａは、プロセスを図表で示す例である。
【００４１】
第１に、ステップＳ２００で、上述のように送信器が第２の疑似ランダムビットＡｉを生成する。次いでステップＳ２２０で、送信器が、ＲＬＰセグメントが最終ＲＬＰセグメントであるかを決定する。ＲＬＰセグメントのヘッダ中のフラグが、先頭セグメント、中間セグメント、または最終ＲＬＰセグメントを表示するために設定されてよい。ＲＬＰセグメントが最終ＲＬＰセグメントでない場合は、ステップＳ２３０で、部分タグ（たとえば６４ビットの部分タグ）が送信器中の累積器（図示せず）に送信される。送信器はまた、ステップＳ２４０で、ＲＬＰセグメントを受信器に送る。
【００４２】
ＲＬＰセグメントが最終ＲＬＰセグメントである場合は、ステップＳ２３５で、最終部分タグもまた累積器に送信される。最終部分タグを累積器に送るプロセスは、非最終部分タグを累積器に送るプロセスと同じである。図４Ｂに示すように、最終部分タグが累積器に送られた後に、ステップＳ２４５で部分タグを追加して累積されたタグが形成され、６４ビットの累積されたタグが生成される。理解されるように、その代わりに、部分タグは、各部分タグが生成された後に、部分的に累積されたタグに追加されてよい。次いでステップＳ２５０で、送信器は、累積されたタグを第３の疑似ランダムビットＡＥＳｋ（２，ＬａｓｔＢｙｔｅＮｕｍｂｅｒ）の最下位ビット（ｌｓｂ）とＸＯＲすることによって累積されたタグを暗号化して、認証タグを生成する。第３の疑似ランダムビットの形成は上記の説明から容易に分かるので、簡潔にするために第３の疑似ランダムビットの生成の説明は割愛する。
【００４３】
ステップＳ２６０で、ＲＬＰセグメントを再送信する場合のために、認証タグもまたメモリに送付される。ステップＳ２７０で、認証タグは、最終ＲＬＰセグメントに添付されて復号化のために受信器に送信される。メモリは、ＲＡＭまたは中央処理装置（ＣＰ）に制御される任意の他の記憶装置であってよく、あるいはメモリ装置は、特定用途向け集積回路（ＡＳＩＣ）の一部でも、それによって制御されてもよい。アプリケーションパケットの最終ＲＬＰパケットについてのみ認証タグが記憶される。
【００４４】
図３の実施形態に対して、それによって与えられる全体の教示から逸脱することなく多くの変形が可能であることが理解されよう。たとえばステップＳ２１０およびステップＳ２２０は、逆順で実施可能であり、または並行して実行可能である。他の例で、ステップＳ２６０およびステップＳ２７０は並行して、および／または連続して実行可能である。
【００４５】
再送信
一般的に知られているように、受信器は、送信器すなわちトランスミッタから送信されたＲＬＰセグメントの全部は受信しない可能性がある。受信器が送信されたＲＬＰセグメントの全部は受信しない可能性がある理由は多々ある。簡潔にするためにＲＬＰセグメントが失われる理由の詳細は割愛する。受信器がＲＬＰセグメントの全部を受信しないときは、その後受信されなかったＲＬＰセグメントの再送信が送信器によって行われてよい。
【００４６】
送信器中の中央処理装置がＲＬＰセグメントをハードウェアに送信および再送信のために送るとき、中央処理装置は、あるＲＬＰセグメントが再送信かを示すビットも送信する。再送信を要求するプロセスは、当業界でよく知られている。したがって、簡潔にするために説明を割愛する。
【００４７】
図５を参照すると、ステップＳ３００で、送信器すなわちトランスミッタは、ＲＬＰセグメント再送信のリクエストを受信する。ステップＳ３１０で、送信器は、再送信リクエストがアプリケーションパケットの最終ＲＬＰセグメントについてか、または非最終ＲＬＰセグメントについてかを決定する。リクエストが非最終ＲＬＰセグメントについての場合は、ステップＳ３２０で、ＲＬＰセグメントが暗号化されて再送信される。
【００４８】
ステップＳ３１０で、アプリケーションパケットの最終ＲＬＰセグメントについてのリクエストの場合は、ステップＳ３３０で、ＣＰ／ＲＡＭに記憶されていた累積された認証タグが暗号化されて最終ＲＬＰセグメントに添付される。ステップＳ３４０で、暗号化された最終ＲＬＰセグメントは、暗号化された認証タグとあわせて受信器に再送信される。
【００４９】
選択肢として、ステップＳ３１０とＳ３３０の間で、最終ＲＬＰセグメントは、さらに再フラグメント化されてよい。たとえばトランスミッタが、送信条件に基づいて、負荷を低減するためにすべての最終ＲＬＰセグメントがより小さなフラグメントにさらに分割されるべきであると決定してよい。より小さなセグメントのそれぞれは、異なるタイムスロット上で送信される。ここで、より小さなフラグメントの最終のもののみに、暗号化された認証タグが再送信の前に付加される。
【００５０】
復号化およびインライン完全性検査
受信器がすべてのＲＬＰセグメントを認証タグを含めて適切に受信する際に、受信器は、ＲＬＰセグメントが暗号化されている場合はそれを復号化して完全性検査を実行しなければならない。
【００５１】
図６は、本発明の例示の実施形態による復号化およびインライン完全性検査の方法を示す流れ図である。ここで「インライン」とは、すべてのＲＬＰセグメントが受信されるのを待つのではなく、ＲＬＰセグメントが受信器によって受信されるにつれて完全性の計算が行われることを意味する。
【００５２】
ＲＬＰセグメントの部分タグを生成するステップは、メッセージの完全性のセクションで上に述べたものと同様である。また、Ａｉが、スーパーブロックレベルで使用される。ＲＬＰセグメントの先頭ＲＬＰバイト番号および末尾ＲＬＰバイト番号を知ることにより、スーパーブロックおよびスーパーブロック内のブロックを、部分タグの計算のために決定することができる。
【００５３】
すべてのＲＬＰセグメントが受信器で受信された後に、ステップＳ４００で、第４の疑似ランダムビットが生成される。図３のステップＳ２００と同様に、ＡＥＳが第４の疑似ランダムビットを生成するために使用されうる。
【００５４】
ステップＳ４１０で、部分タグが受信されたＲＬＰセグメントについて生成される。部分タグは、６４ビットの部分タグでありうる。次いでステップＳ４２０で、受信器が、ＲＬＰセグメントが最終ＲＬＰセグメントであるかを決定する。ＲＬＰセグメントが最終ＲＬＰセグメントでない場合は、ステップＳ４３０で、ＲＬＰセグメントは復号化され、部分タグとあわせて受信器中のメモリに送信される。トランスミッタと同様に、受信器のメモリは、ＲＡＭまたは中央処理装置（ＣＰ）によって制御される任意の他の記憶装置であってよく、あるいはメモリ装置は、特定用途向け集積回路（ＡＳＩＣ）の一部でも、それによって制御されてもよい。また図３について上述したステップと同様に、部分タグ生成ステップとＲＬＰセグメントが最終ＲＬＰセグメントであるかを決めるステップは、逆順にしてよい。
【００５５】
受信器が、ステップＳ４２０でそのＲＬＰセグメントが最終ＲＬＰセグメントであると決定する場合は、ステップＳ４４０で最終ＲＬＰパケットが復号化される。また、ステップＳ４４０で、最終ＲＬＰセグメントの部分タグが第５の疑似ランダムビットＡＥＳｋ（２，ＬａｓｔＢｙｔｅＮｕｍｂｅｒ）のｌｓｂとＸＯＲされ、ステップＳ２７０からの認証タグとあわせてメモリに送信される。第５の疑似ランダムビットの生成の説明は、簡潔にするために割愛する。さらに、第４のおよび第５の疑似ランダムビットを生成する方法は、それぞれ上述の第２のおよび第３の疑似ランダムビットを生成する方法と同様であることは当業者には明白であろう。また選択肢として、３２ビットの値に低減するために、計算されたタグに対して第２のハッシュを実行することができる。
【００５６】
中央処理装置（ＣＰ）は、すべてのＲＬＰセグメントを組み立ててアプリケーションパケットを形成する。ＣＰはまた、ステップＳ４３０およびＳ４４０中で受信されたすべての部分タグを加算する。計算された部分タグの合計が受信された認証タグに等しければ、ステップＳ４５０で、アプリケーションパケットは検証される。
【００５７】
上述の例示の実施形態において、完全性法、暗号化法、および復号化法は、ブロックサイズの倍数、たとえば、６４ビット（８バイト）であるＲＬＰセグメントに関して説明された。言い換えると、ＲＬＰセグメントは６４ビットの標準ブロックサイズである。以下の例示の実施形態において、標準ブロックサイズではない（たとえば６４の倍数のビットではない）ＲＬＰパケットについて説明する。簡潔にするために標準ＲＬＰセグメントブロックサイズと非標準ＲＬＰセグメントブロックサイズの間で異なる態様（ステップ）についてのみ説明する。
【００５８】
ブロックサイズの非倍数
アプリケーションパケットのＲＬＰセグメントがブロックサイズの倍数ではない、たとえば６４の倍数のビットではないと仮定し、ビット列の数が与えられる場合は、６４の倍数のビットである先頭バイトは識別可能である。６４の倍数のビットである先頭バイトが識別されれば、６４ビット値に対して汎用ハッシュを実行しうる。
【００５９】
理解されるように、「６４の倍数のビット」の前のビットおよび末尾のビットは適切に管理されなければならない。６４の倍数のビットではないＲＬＰセグメントは、６４ビットの暗号文ブロックＣｉを完成するためにＲＬＰセグメントの先頭の前にゼロを付加することができおよび／またはＲＬＰセグメントの末尾にゼロを付加することができる。
【００６０】
加算と乗算は、ガロア体（２６４）に基づいて計算されてよく、または変形のために他の体を使用し、たとえば６４ビットよりも大きいモジュレータプライム上で作業がなされてよい。
【００６１】
暗号化および部分タグ生成の残りのプロセスは、上の図１〜図４Ｂについて述べたプロセスと同様である。さらに認証タグ生成の方法、ＲＬＰパケットの復号化、ＲＬＰパケットの再送信、および上述した検証も同様である。図５〜図６とその説明を参照されたい。
【００６２】
可変長アプリケーションパケット
アプリケーションパケットもまた、様々のバイト長を有しうる。したがって、本発明の例示の実施形態がこれらのアプリケーションパケットにどのように適用可能かについての説明をここで行う。簡潔にするために上述の例示の実施形態と異なる態様についてのみ説明する。
【００６３】
アプリケーションパケットは、可変のバイト長を有しうる。従来技術において、可変のバイト長を備えるアプリケーションパケットは、長さ（ブロックの数）のパラメータを汎用ハッシュの計算の部分、またはタグ暗号化の入力に含めて処理される可能性がある。たとえば、パディングが、最終の部分的に充填されたブロックを充填するために使用されうる。しかし、ＲＬＰセグメントが異常受信されたときにその長さが不明であるために、この方法は例示の実施形態では使用できない。
【００６４】
先頭バイトおよび最終バイトのバイト番号は、バイト長値を代替するために使用されてよい。Ｃ０値は、先頭バイト番号に設定することができ、このことはＣ０×Ａ０の関係に影響する可能性がある。たとえばＡ０は、疑似ランダムの、あらかじめ計算された、固定値である可能性があり、あるいはＡ０は、たとえば疑似ランダムストリームＡｉ中のＡ１に先行する６４ビット値である可能性があり、Ｃ０は、アプリケーションパケットに先行する先頭ビットである可能性がある。
【００６５】
Ａ０が、６４の倍数のビットの境界に存在しない任意のＣ０（先頭バイト番号）についての疑似ランダムストリームＡｉ中のＡ１に先行する６４ビット値であると仮定すると、Ａ０は、先頭バイト番号を包含するブロックに先行する６４ビット疑似ランダムブロックに設定される。先行するブロックがないために、追加するステップも、ＲＬＰフローの最先頭部（たとえばバイト０、１、２および３）で必要である。説明すると、Ａ０は第６の疑似ランダムビットの最終バイトＡＥＳｋ（３，０）として設定され、または０  ｍｏｄ  ２６４に先行する値であるＡ０＝ＡＥＳｋ（１，２６４−１）として設定されてよい。ＲＬＰストリームが２６４個の６４ビットのブロックに到達することは実際上不可能であることに留意されたい。そのために、ＡＥＳに対するすべてのバイト番号入力は６４ビットであると仮定される。したがって部分６４ビットタグを生成するためには、Ｃ０は先頭バイト番号（６４ビット）、Ａ０は疑似ランダムストリームＡｉ中のＡ１に先行する６４ビットのマスク（たとえばＡ０＝先行するＡＥＳｋ（１，．．．）出力ビットの最終６４ビット）である。ＲＬＰフローの最先頭の８バイト用のＣ０についてのＡ０は、上述のように指定されて生成される。
【００６６】
暗号化されたタグ（認証タグ）を第７の疑似ランダムビットＡＥＳｋ（２，ＬａｓｔＢｙｔｅＮｕｍｂｅｒ）を使用して生成するとき、異なるバイト番号で終了するアプリケーションパケットは、異なる暗号化タグを有する。また、第７の疑似ランダムビットを生成する方法は、上述の第３のおよび第５の疑似ランダムビットを生成する方法と同様でありうる。タグの暗号化のためには、１２８ビットのブロック番号は使用されず、ＡＥＳ入力としての厳密な最終バイト番号が使用できる。２つの異なるメッセージが同じタグを生成する可能性はある（たとえば６４の倍数のビット長のメッセージＭと０値のバイトが後続するメッセージＭ）。しかし各メッセージは、各メッセージについてランダム文字列が追加されるために、異なる暗号化が行われる。
【００６７】
６４の倍数ではないビットにおいて開始、終了するが、同じアプリケーションパケットに属するＲＬＰセグメントについては、ＡｉはＲＬＰセグメントの先頭バイト、および次のＲＬＰセグメントの先頭バイトで再使用されてよい。図８を参照すると、６４の倍数ではないビットおいて終了するアプリケーションパケット、および６４の倍数ではないビットおいて開始する次のアプリケーションパケットが説明されている。
【００６８】
ＲＬＰパケットは、８バイトＣｉを終了するために、０によってパディングされてよい。ここでＡｉは、両方のアプリケーションパケットについて再使用されてよい。言い換えると、Ａｉは、第１のアプリケーションパケットの末尾で使用され、第２のアプリケーションパケットの先頭で再使用される。
【００６９】
第２のアプリケーションパケットの先頭バイトは、現行のｉに基づく８バイトのＡｉを使用し続け、ここでｉは（ＬａｓｔＢｙｔｅＮｕｍｂｅｒ／８）に等しい。第１のアプリケーションパケットの末尾バイト（たとえば８Ｘ＋１、８Ｘ＋２または８Ｘ＋３バイト）では、最終バイトに関連付けられた６４ビットＡｉ（すなわちｉは（ＬａｓｔＢｙｔｅＮｕｍｂｅｒ／８）に等しい）が使われる。
【００７０】
本発明の例示の実施形態は、「オンザフライ（ｏｎ  ｔｈｅ  ｆｌｙ）」で、データが受信されるにつれ、すべてのアプリケーションパケットを再組み立てするのを待つ必要なく、メッセージ認証タグの検証を行うことができる。例示の実施形態は、バイトレベルの暗号化、認証処理、および異常処理を可能にする。
【００７１】
本発明の例示の実施形態をこのように説明したが、本例示の実施形態が多くの形式で変形されうることは明白である。そのような変形は本発明からの逸脱とみなされるべきではなく、すべてのそのような変形は本発明の範囲に含められることが意図されている。
【図１】
2010510756.tif 000003
【図２】
2010510756.tif 000004
【図３】
2010510756.tif 000005
【図４Ａ】
2010510756.tif 000006
【図４Ｂ】
2010510756.tif 000007
【図５】
2010510756.tif 000008
【図６】
2010510756.tif 000009
【図７】
2010510756.tif 000010
【国際調査報告】
2010510756.tif 000011