無線セキュリティ処理の電力効率化用にトランスポート層のセキュリティプロトコルを拡張する方法
【課題】ＩＥＴＦトランスポートプロトコル（ＴＬＳ）およびＩＰｓｅｃ規格のセキュリティ面を拡張させて、無線デバイスに、電力効率のよい、流線型のセキュリティパケット処理を可能にする。
【解決手段】方法は、プロセッサが既存の暗号化処理エンジン（ＡＥＳ−ＣＣＭ）を用いてＴＬＳおよびＩＰｓｅｃセキュリティ処理を行うことを可能とする。ＷＬＡＮおよびＴＬＳセキュリティ用に処理されるパケットはパイプライン方式で処理され、現行のマルチループ処理を必要とせず、各パケットを処理するときの消費電力を低減できる。加えて、ホスト／チップセットの複合体を、ＷＮＩＣの全てのセキュリティ処理が終了したところで起こすことができる。
【解決手段】方法は、プロセッサが既存の暗号化処理エンジン（ＡＥＳ−ＣＣＭ）を用いてＴＬＳおよびＩＰｓｅｃセキュリティ処理を行うことを可能とする。ＷＬＡＮおよびＴＬＳセキュリティ用に処理されるパケットはパイプライン方式で処理され、現行のマルチループ処理を必要とせず、各パケットを処理するときの消費電力を低減できる。加えて、ホスト／チップセットの複合体を、ＷＮＩＣの全てのセキュリティ処理が終了したところで起こすことができる。
【発明の詳細な説明】
【背景技術】
【０００１】
本発明の実施形態は、無線通信デバイスにおける暗号化処理を向上させる装置、システムおよび方法に係る。
【０００２】
ＷｉＦｉホットスポット等の無線アクセスポイント（ＡＰ）は、空港、ホテル、喫茶店、等の多くのロケーションで公共ＷＬＡＮアクセスを提供し、無線クライアントにネットワークアクセス（例えばインターネットアクセス）を提供している。無線クライアントのなかには、暗号化等のセキュリティ手段を実装して、不正アクセス、盗聴、または正当なユーザへのなりすまし等の問題を防いでいる人もある。セキュリティ手段は、ネットワーク層におけるセキュリティプロトコル、および／または、物理層におけるセキュリティ処理として実装することができる。無線クライアントデバイスは、暗号化処理を行う１を超える数のプロセッサを有しうる。
【０００３】
本発明の実施形態は、無線クライアントにおけるセキュリティ処理の実装を向上させる方法に係る。
【図面の簡単な説明】
【０００４】
【図１】無線暗号とネゴシエーションするＴＬＳセッションを示す。
【０００５】
【図２】リンク層の無線およびＴＬＳ通信用の効率的なセキュリティ処理パケットフローのアーキテクチャを示す。
【０００６】
【図３】レイヤ２の無線セキュリティアルゴリズムとネゴシエーションする際の、ＴＬＳ標準プロトコルフローの追加分を示す。
【０００７】
【図４】本発明の実施形態をサポートするよう修正されたＴＬＳプロトコルメッセージフォーマットを示す。
【発明を実施するための形態】
【０００８】
以下の記載において、多数の詳細を述べる。しかし、本発明の実施形態は、これら詳細なしに実施可能である。他の場合には、公知な回路、構造、よび技術については詳細に示さず、本記載の理解を曖昧にしないようにしている。以下の用語集は、ここで利用する用語を定義しており、利用されるコンテキストで異なる意味が割り当てられている場合を除いてこの定義が当てはまる。ここで定義されていない用語については、「The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition」を参照されたい。
【表１】
【０００９】
ＷｉＦｉは、モバイルおよび固定通信デバイス両方に利用可能な無線通信技術である。モバイル無線技術は、ＩＥＥＥ規格８０２．１１の「Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications」およびその修正版（ここでは「ＩＥＥＥ.８０２.１１」または「８０２.１１」と称される）に規定されている。ＩＥＥＥ８０２.１１の趣意は、ポータブルまたはハンドヘルドであったり、ローカルエリア内の移動車両に搭載されるような、急速な配置を必要とする自動マシン、機器、またはステーションに無線接続を提供することである。この規格はさらに、法組織に対して、ローカルエリア通信用の１以上の周波数帯へのアクセスを規格化する手段を提供する。
【００１０】
無線ネットワーク用のセキュリティメカニズムは、元のＩＥＥＥ８０２．１１規格への修正版であり、今は公開されているＩＥＥＥ８０２．１１-２００７規格に組み込まれているＩＥＥＥ８０２．１１ｉに規定されている。
【００１１】
ＩＥＥＥ８０２．１１ｒ―２００８、あるいは、ｆａｓｔＢＳＳ（fast Basic Service Set）遷移は、ＩＥＥＥ８０２．１１規格の修正版であり、連続接続を搭載した移動する無線デバイスに対して、１つの基地局から別の基地局へとシームレスに管理された高速且つセキュアなハンドオフを提供する。ＩＥＥＥ８０２．１１ｒは、セキュリティ・キー・ネゴシエーション・プロトコルを再定義しており、無線リソースのネゴシエーションおよび要求の両方を可能とする。
【００１２】
ＩＥＥＥ８０２．１１修正版７「Interworking with External Networks」は、「ＩＥＥＥ８０２．１１ｕ」または「８０２．１１ｕ」と称されうる。ＩＥＥＥ８０２．１１ｕは、外部ネットワークとのＷＬＡＮインターワークをサポートする８０２.１１への改良点を規定しており、より高いレイヤ機能の実行を促す。ＩＥＥＥ８０２．１１ｕは、外部ネットワークからの情報転送を向上させ、ネットワーク選択を助け、緊急サービスを可能とする。
【００１３】
固定無線通信デバイスが利用する無線技術は、ＩＥＥＥ規格８０２．１６「Air Interface for Fixed Broadband Wireless Systems」およびその修正版（ここでは「ＩＥＥＥ.８０２.１６」または「８０２.１６」と称される）に規定されている。ここで利用される「無線」、「無線技術」、および類似した用語は、そうではないと明記しない限り８０２．１１または８０２．１６のことである。
【００１４】
ＩＥＥＥ８０２．１６の趣意は、マルチメディアサービスをサポートする固定ブロードバンド無線アクセス（ＢＷＡ）システムの空気インタフェースを規定することである。メディアアクセスコントロール層（ＭＡＣ）は、主に、ポイントツーマルチポイント・アーキテクチャをサポートしており、オプションとしてメッシュトポロジーをサポートしている。ＭＡＣは、マルチプル物理層（ＰＨＹ）仕様をサポートするよう構成され、仕様各々は特定の動作環境に適合している。１０‐６６ＧＨｚの動作周波数では、ＰＨＹはシングルキャリア変調に基づく。直接見えるラインを利用せずに伝播が行われる１１ＧＨｚ未満の周波数では、直交周波数分割多重（つまり、無線ＭＡＮ−ＯＦＤＭまたは「ＯＦＤＭ」）、直交周波数分割マルチプルアクセス（つまり、無線ＭＡＮ−ＯＦＤＭＡまたは「ＯＦＤＭＡ」）、および、シングルキャリア変調を利用する直交周波数分割（つまり、無線ＭＡＮ−ＳＣａまたは「シングルキャリア変調」）という３つの選択肢がある。
【００１５】
ＩＥＥＥ８０２．１６ｅは、車両スピードで移動する加入ステーションをサポートして、固定およびモバイルブロードバンド無線アクセスを組み合わせたシステムを規定するＩＥＥＥ Ｓｔｄ８０２．１６への改良点を規定している。固定ＩＥＥＥ８０２．１６の加入者機能が損なわれることはない。
【００１６】
ＩＥＥＥ８０２．１６ｍは、ＩＥＥＥ８０２．１６への修正案であり、高度な次世代モバイルネットワークのセルラー層の要件に見合う高度な空気インタフェースを提供して、同時に、レガシー無線機器へのサポートも継続して可能とする。
【００１７】
ＷｉＦｉホットスポットは、例えば空港、ホテル、喫茶店、等の多くのロケーションで公共ＷＬＡＮアクセスを提供し、インターネットアクセス、ビデオストリーミング（例えばＩＰ ＴＶ）、ＩＭＳ、およびオンラインゲーム等の様々なサービスを提供してよい。盗聴、なりすまし、不正アクセス等の問題を防ぐセキュリティの必要性が叫ばれている。セキュリティは、２つ以上のネットワークモデル層に提供されうる。
【００１８】
ネットワーク可能な無線デバイスには、無線ネットワークインタフェースカード（ＷＮＩＣ）が含まれる。無線デバイス上の従来のパケット処理は、ＷＮＩＣ上で無線セキュリティ処理を行い、ＴＬＳ（またはＩＰＳｅｃ）パケットが無線デバイスのメインプロセッサ上で処理され、その後、無線デバイス内の異なる暗号化プロセッサへと送られて、セキュリティ処理を受け、無線デバイスのメインプロセッサへ送り返されて、アプリケーション（例えばブラウザ）へ、さらに送られる。
【００１９】
ＩＥＴＦ ＴＬＳ／ＳＳＬセキュリティプロトコルは、セキュリティ処理アルゴリズムを、低位な層における無線セキュリティ処理に用いられるプロトコルとは離れた、より高位な層で利用する（例えば、ＩＥＥＥ８０２.１１ｉ、８０２.１１ｒ、８０２.１６ｅ、および８０２.１６ｍにその規定がある）。これは、きめの粗いクライアント処理（例えばラップトップコンピュータのトランスポート層のセキュリティ用）には適しているが、ＴＬＳ層において既存のセキュリティ法を、より低度な層で処理される通信パケットに適用することには無理がある、というのも、このような方法ではパケットセキュリティ処理オーバヘッドが増えるからである。無線デバイスでＴＬＳ／ＳＳＬセキュリティプロトコルを用いて各パケットを処理することには、ホストと暗号機能を実装したプロセッサとの間で、および別個のＷＮＩＣプロセッサとの間で、複雑な、マルチループパスを実行することが含まれうる。ここで利用されるプロセッサ（利用されるコンテキストで異なる意味が示されている場合を除いて）は、処理機能を実装するそれぞれ別個の処理チップ、または、同じチップに物理的に位置するそれぞれ独立した処理コアを含みうる。
【００２０】
セキュリティ処理段階の増加は、ＴＬＳ規格がクライアントに対して、無線レイヤ２（つまり、ネットワーク層）セキュリティ暗号とのネゴシエーションを許可していないことが原因である。ＴＬＳ規格では、トランスポート層セキュリティ処理は、暗号機能を実行するプロセッサ（例えばホストプロセッサまたはラップトップ）上で実行されるソフトウェアアルゴリズムにより行われる。通常、無線パケットおよびセキュリティ処理は、別々の無線プロセッサ上で行われる。この処理タスクの分断により、無線デバイスの電力消費全体が劣化する、というのも、信号（データパケットおよび状態を含む）が、１つのチップセットから別のチップセットへと駆動される必要があるからである。さらに、セキュリティ処理を行っている間、これらプロセッサの幾らかを低電力消費に長い間しておくことができないことが多い。
【００２１】
低電力、ウルトラモバイルデバイス（例えば、ＭＩＤ（Mobile Internet Device）／ＵＭＰＣ（Ultra-Mobile PC）デバイス）では、各通信パケットの処理に必要とされる電力消費および待ち時間は、セキュリティ処理段階の増加により、顕著に増える。これは、バッテリを短命にして、必要な放熱量が増えるので望ましくない。
【００２２】
上述の問題を克服するべく、本発明の実施形態は、ＩＥＴＦ ＴＬＳまたはＩＥＴＦ ＩＰｓｅｃ規格のセキュリティ面を拡張させて、ＭＩＤアーキテクチャに、電力効率の良い、流線型のセキュリティパケット処理を行わせることを目指す。トランスポート層セキュリティプロトコルは、インターネットのユビキタス・アプリケーション・セキュリティ・プロトコルであり、銀行取引、イントラネットセキュリティ、ウェブサービス等で利用されている。本発明の実施形態は、さらに、セキュリティ処理に利用される時間の少なくとも一部の間に、無線デバイスの少なくとも一部を低電力消費モードにすることにより、無線デバイスの電力消費を低減するという利点を有する。特に、ホスト／チップセットの複合体をこのような低電力状態にして、ＷＮＩＣの全てのセキュリティ処理が終了したところで起こして高電力状態とすることができる。
【００２３】
特に、本発明の実施形態は、第１のネットワーク層と、第１のネットワーク層とは異なる第２のネットワーク層とにおける通信セキュリティを、第１のプロセッサを持つ無線クライアントに提供する方法であって、第１のネットワーク層に関連付けられた第１のコントローラから、第１のネットワーク層でのセキュリティ処理用にセキュリティアルゴリズムを取得する段階と、第２のネットワーク層に関連付けられた第２のコントローラと、第２のネットワーク層でのセキュリティ処理へのセキュリティアルゴリズムの利用についてネゴシエーションする段階とを備え、無線クライアントでの第１のネットワーク層および第２のネットワーク層におけるセキュリティ処理は、第１のプロセッサで行われる方法を提供してよい。
【００２４】
さらに、方法は、第１のコントローラからセキュリティアルゴリズムを取得する段階、および、第２のコントローラとネゴシエーションする段階のうち少なくとも一部を行う間、無線クライアントの少なくとも一部を低電力レベルで動作させる段階をさらに備える。
【００２５】
オプションとして、方法においては、第１のネットワーク層はリンク層であり、第２のネットワーク層はネットワーク層であってよい。例えば第２のネットワーク層は、ＴＬＳまたはＩＰｓｅｃであってよい。
【００２６】
さらに方法では、第１のコントローラからセキュリティアルゴリズムを取得する段階が、第１層セキュリティ用にセキュリティアルゴリズムを、無線クライアントが、第１のコントローラに対して要求する段階と、セキュリティアルゴリズムを、無線クライアント内のＴＬＳスタックへ送る段階とを備えてよい。
【００２７】
またさらに方法では、第２のコントローラとネゴシエーションする段階が、第２のコントローラに対して、第２のコントローラが無線クライアントと通信する際のネットワーク層セキュリティを提供する用途向けに、セキュリティアルゴリズムを提示する段階と、第２のコントローラからセキュリティアルゴリズム証明を受信する段階と、無線クライアントを、第１層セキュリティ処理および第２層セキュリティ処理用の両方にセキュリティアルゴリズムを利用するよう構成する段階とを有してよい。
【００２８】
例えば、方法のセキュリティアルゴリズムは、ＡＥＳ−ＣＣＭまたはＡＥＳ−ＧＣＭであってよい。
【００２９】
セキュリティアルゴリズムをＴＬＳスタックへ送る段階は、セキュリティアルゴリズムをＴＬＳセッションの最優先セキュリティアルゴリズムとする段階をさらに有する、またはセキュリティアルゴリズムをＴＬＳスタック内に構成する段階をさらに有する。
【００３０】
現在のところ、ＴＬＳプロトコルは、ＴＬＳ用のＡＥＳ−ＣＣＭ（Advanced Encryption Standard / Cipher Block Chaining-Message Authentication Code）セキュリティアルゴリズムを含むというオプションがない。概して、ここで用いられるセキュリティアルゴリズムは暗号（cipher）と称される。暗号はセキュリティプロトコルの一部である。概して、セキュリティプロトコルは、認証、キーアサート、活性チェック（liveness check）、および関連機能を含む。ＡＥＳ−ＣＣＭ暗号は、８０２.１１および８０２.１６で幅広く利用されているが、ＡＥＳ‐ＧＣＭ等の他の暗号も利用可能である。本発明の実施形態は、暗号化ネゴシエーション中にレイヤ２暗号（例えばＡＥＳ−ＣＣＭ、ＡＥＳ−ＧＣＭ等）の、ＴＬＳプロトコルへの追加を記載しており、これにより、ＩＥＥＥ８０２.１１およびＩＥＥＥ８０２.１６を実装するプロセッサが、既存のレイヤ２暗号化処理エンジン（ＡＥＳ−ＣＣＭおよびＡＥＳ−ＧＣＭ）を利用してＴＬＳセキュリティ処理を行うことができるようになる。ここで利用されるエンジンは、ルックアップおよび／または分類ロジックのセットであり、ファームウェアおよび／またはハードウェアに実装され、各ネットワーク層でパケットのプロトコルタイプおよびセキュリティタイプを検出する。
【００３１】
本発明の実施形態によるＷＬＡＮおよびＴＬＳセキュリティ用に処理されるパケットは、パイプライン方式で処理され、現行のマルチループ処理を必要としない。これは、各パケットを処理するときの消費電力を低減できるというメリットがある。さらに、セキュリティ処理をＷＮＩＣで行う間、無線デバイスの他の処理部分を節電モードとしておき、セキュリティ処理が完了してから節電モードを解除することができるので、無線デバイスのさらなる節電およびバッテリ寿命の延命が可能である。基本的なパケット処理分析に基づいて、本発明は、小型の低電力デバイス（例えばＭＩＤ／ＵＭＰＣプラットフォーム、および／または、８０２.１１、８０２.１６または他の無線アクセスプロトコルを介したインターネットアクセスを可能とするモバイルフォンまたはスマートフォン）の利用におけるバッテリ寿命を向上させる。
【００３２】
本発明の実施形態は、それぞれ異なるプロトコル層についてセキュリティを処理する多数のエンジンを利用する必要性がないので、無線デバイスに対して良い影響を及ぼすＴＬＳプロトコルの変更である。本発明の実施形態は、シングル・クロスレイヤ・セキュリティ・プロセッサを導入する。従来の無線製品は、全ての無線（レイヤ２）、ＩＰｓｅｃ（レイヤ３）、およびＴＬＳ（レイヤ４）セキュリティ処理に対して単一のまたは統一されたセキュリティ処理を有さない。
【００３３】
本発明の実施形態は、入力パケットのネットワークセキュリティの効率的な多層処理のために、ネットワーク階層の多層にまたがって分断するパイプラインモードを提供する。このパイプラインモードにより、シングルプロセッサチップのセキュリティエンジンによりシングルパスにおけるセキュリティ処理が可能となる。本発明の実施形態は、パイプライン間に、ディープ・パケット・ルックアップ・エンジンを追加する。当業者であれば理解するように、ディープパケット（「ＤＰ」）ルックアップは、一連のパケット処理によりパケットヘッダおよびペイロード両方のコンテンツを分析することで動作する。この結果、ＤＰによりネットワーク利用を分析して、ネットワーク性能を最適化する機能が提供され、これにより、ネットワークオペレータは、より効果的にネットワークのトラフィックフローを管理することができるようになる。
【００３４】
本発明の一実施形態は、ＡＥＳ−ＣＣＭをＴＬＳプロトコルに追加することで、少なくとも以下の有利な効果を生じる。（１）ＡＥＳ−ＣＣＭは、より効率的なセキュリティアルゴリズムであり、ＷＮＩＣによるレイヤ２で行われるセキュリティ処理と比べて、セキュリティパケットの処理スループットまたは処理速度を向上させることができ、ＡＥＳ−ＣＣＭ暗号処理をＴＬＳプロトコルに加えることで、ＴＬＳパケット処理待ち時間が全体的に向上する。また、ＡＥＳ−ＣＣＭ暗号処理には、パケット毎に５つのブロック暗号処理しか必要とされないので、セキュリティ暗号処理の終了後にパケット拡張が最小となる、というさらなる利点も生じる。暗号および復号は両方とも、１つのブロックの暗号の暗号機能（one block cipher encryption function）を必要とする。暗号化および認証は、ハードウェアにより同時に行うことができ、認証チェックを行う前に暗号化が完了している必要はない。（２）ＡＥＳ−ＣＣＭの利用により、データの機密保持用のＡＥＳ−ＣＴＲモードと、整合性および認証用のＣＢＣ−ＭＡＣ（Cipher Block Chaining Message Authentication Code）を組み合わせることができる。ＡＥＳ−ＣＴＲおよびＣＢＣ−ＭＡＣは、当業者に公知な動作モードである。ＡＥＳ−ＣＴＲおよびＣＢＣ−ＭＡＣを組み合わせる技術も当業者に公知である（例えば、R.Housley（RSA Laboratories所属）著「Counter with CBC-MAC (CCM) AES Mode of Operation」、ＮＩＳＴへの公共提出参照）。（３）ＡＥＳ−ＣＣＭは、さらに、同アルゴリズムの一貫として、暗号化およびＭＩＣ（Message Integrity Code）計算を行うことができる。これにより、現在のＴＬＳのような暗号化とメッセージの認証とを別々に行う必要がなくなる。これに対して、ＳＨＡ整合性セキュリティアルゴリズムを利用して暗号化を行う従来の方法では、ＡＥＳを利用する方法よりもコンピューティングの面で比較的高価になる。（４）ＷＮＩＣが既にＡＥＳ−ＣＣＭ処理機能をサポートしている限りにおいては、ＡＥＳ−ＣＣＭをＴＬＳプロトコル規格に追加することにより、既存のＷＮＩＣハードウェアを利用しつつＷＮＩＣハードウェアを拡張して、ＴＬＳセキュリティを実行することができるようになる。
【００３５】
以下に、図１を参照ながら、プロトコルコンポーネント、プロトコルメッセージフロー、および拡張行動を含む本発明の第１の実施形態を示す。図１は、例示的なネットワークレベル図を示しており、クライアントがＴＬＳセキュリティで保護された任意のアプリケーションサーバでＴＬＳセッションを開始して、ＴＬＳ拡張を利用するときのネットワークの主要なコンポーネントを示す。図１は、無線クライアント３が遠隔ＴＬＳサーバ２と、無線層が利用するものと同じ暗号セット（cryptographic cipher suites）についてネゴシエーションする本発明の一実施形態を示す。ここで言う暗号セットは（利用されるコンテキストから異なる意味が明確な場合を除いて）、メッセージを保護する、関連する暗号化アルゴリズムのファミリー（ＡＥＳ、ＤＥＳ等）のことである。ＴＬＳサーバ２は、アプリケーション・セキュリティ・サーバの一実施形態である。ＴＬＳスタックとは、ＴＬＳプロトコルパケットを処理するマシン上の汎用ソフトウェアおよび／またはハードウェアコンポーネントのことである。本発明の実施形態は、非ＴＬＳプロトコル用のアプリケーション・セキュリティ・サーバの利用により、非ＴＬＳプロトコルを利用するネットワークでも実施可能である。
【００３６】
図１を参照すると、ＷＬＡＮコントローラ４が、５で示されている無線アクセスポイントＡＰを制御する。さらなるアクセスポイント（不図示）も、ＷＬＡＮコントローラ４により制御されてよい。ＷＬＡＮコントローラ４およびアクセスポイント５は、互換性のある技術である（例えば、８０２.１１および８０２.１６両方）。無線クライアント３は、ラップトップＰＣとして示されているが、ＩＥＥＥ８０２.１１および／または８０２.１６と互換性のある無線通信機能を有する任意の通信デバイスであってよい。本発明の実施形態は、他の無線技術規格にも適用可能である点を理解されたい。無線クライアント３は、少なくとも１つのアクセスポイント（例えばＡＰ５）と通信８している。
【００３７】
無線クライアント３は、ＡＰ５から暗号を受け取る（例えばリンク層で利用するＡＥＳ−ＣＣＭ−１２８暗号）。しかし、本実施形態はこの暗号に限定されず、全ての現行の暗号およびセキュリティモード、無線またはＴＬＳセットに将来導入される暗号、および、ＡＥＳの他のセキュリティモードへの適用が可能である。ここで利用される「モード」は（利用されるコンテキストから異なる意味が明確な場合を除いて）、暗号を特定の目的に利用することである（例えば、ＡＥＳを暗号化のみに利用することが１つのモードであり、ＡＥＳを暗号化と認証とに利用することが第２のモードである、等）。
【００３８】
無線クライアント３は、ＴＬＳプロトコル（クライアント無線ドライバ等の様々なソフトウェアコンポーネント（不図示）、ＴＬＳスタック（不図示）、およびインタープロセッサ通信に利用されるソフトウェアドライバを含む）を実装する。ＴＬＳスタックは、無線クライアント３内のプロトコル処理コンポーネントのセットである。無線クライアント３がリンク層暗号をＡＰ５から取得した後で、無線クライアント３のリンク層ドライバは、この暗号を無線クライアント３のＴＬＳスタックへ送り、この暗号をＴＬＳセッションに相応しい暗号として配置する。プラットフォームは多くのレイヤ２の暗号（例えばＡＥＳ−ＣＣＭおよびＡＥＳ−ＧＣＭ）をサポートしうるが、ＡＰ５との間で単一のレイヤ２の暗号のみをネゴシエーションしてもよい。または、単一のレイヤ２の暗号のみをサポートする複数のプラットフォームでは、サポートされるレイヤ２の暗号の情報を無線クライアント３のＴＬＳスタック内に構成することもできる。「暗号をＴＬＳスタックに構成する」ということは、暗号をＴＬＳスタックへ送ることと同等であってよい。
【００３９】
そして無線クライアントは、遠隔アプリケーションサーバとの間でＴＬＳセッションを開始してよい。無線クライアント３がこのセッションを開始すると、無線クライアント３は、ＡＰ５から取得した暗号（例えばＡＥＳ−ＣＣＭ−１２８暗号）を、ＴＬＳサーバ２が受諾する暗号として提示する。
【００４０】
ＴＬＳサーバ２は、その後、無線クライアント３が提示する暗号を処理し、暗号がＴＬＳサーバ２によりサポートされている場合には、無線クライアントが提示する暗号を、トランスポート層セキュリティ用の暗号として受諾する。
【００４１】
無線クライアント３およびＴＬＳサーバ２は、ＡＰ５から取得した暗号（例えばＡＥＳ−ＣＣＭ−１２８暗号）を用いて、この暗号を用いて通信リンクを開始することにより、アプリケーショントランスポート層セキュリティを構築する。
【００４２】
無線クライアント３はさらに、同じセキュリティ処理エンジンを自身の無線プロセッサで用いて、レイヤ２（ネットワーク層）およびレイヤ４（トランスポート層）セキュリティ処理セキュリティを並行して処理してよい。この並行セキュリティ処理は、暗号により互いに関連付けられるが、必ずしも時間的に同時に行われる必要はない。オプションとして、別個のセキュリティ処理エンジンを利用することもできる（例えば、マルチコアＣＰＵとともに実装される無線クライアントのような場合において）。
【００４３】
上述の第１の実施形態によると、無線クライアント３は、トランスポート層（レイヤ４）およびネットワーク層（レイヤ２）における両方の無線セキュリティ用のパケットを処理することができ、これには無線クライアント３のメインプロセッサを起こす必要がなく、メインプロセッサを介して暗号化パケットをルーティングする必要もない。
【００４４】
図２は、本実施形態の方法による無線およびＴＬＳ処理の効率的なセキュリティ処理パケットフローを行うための無線クライアント内のアーキテクチャを示す。アーキテクチャは、マルチコアプラットフォーム１０（つまり、多数の独立した処理コアを有するプロセッサ）に関して記載されているが、これは、マルチコアプラットフォーム１０が本発明の実施形態を記載する上で最も柔軟性が大きい、という理由による。本実施形態で説明される機能は、例えば、１以上の仮想化および／または仮想プラットフォーム等の様々な種類のプロセッサ（つまり、仮想技術を利用するプラットフォームであり、仮想化は同じソフトウェアを異なるハードウェア上で動かせる技術である）マルチコアプロセッサ、システムオンチップ、またはマルチチップソリューションで、相互利用可能である。この実行は、アプリケーションサーバ１、ＴＬＳサーバ２、ＷＬＡＮコントローラ４、および／または、無線クライアント３が、これらの種類のプロセッサのいずれとも、本発明の第１の実施形態の方法に影響を及ぼすことなく、実装可能であるという意味で相互利用可能である。
【００４５】
図２のアーキテクチャは、パイプラインモードを用いてスタックの異なる層のパケットを処理するＣｏｍｍｓプロセッサ１２のセキュリティ処理エンジン１１を特徴とする。Ｃｏｍｍｓプロセッサ１２は通信エンジンである。図２の様々なエンジンは、マルチコアプロセッサ内の複数のコアの任意の組み合わせに実装可能である。パイプラインモードは、パケット処理に必要な処理段階の幅広い機能パイプラインのことである。パイプラインモードでは、多層セキュリティ用の全てのパケットを処理するセキュリティ・パイプライン・アーキテクチャを利用し、各パケットは上層の存在について検査される。本実施形態ではレイヤ２およびレイヤ４セキュリティ処理が示されている。これはさらに、レイヤ２およびレイヤ３（つまりＩＥＴＦ ＩＰｓｅｃ）セキュリティ処理にも適用される。当業者であれば、ここで開示する方法を、レイヤ２およびレイヤ３通信を処理するよう適合することには、１パケット内の異なるフィールドを検査して、処理する層に適切な異なるセキュリティカプセル化処理（security encapsulation processing）を適用することが含まれることを理解する。全てのセキュリティプロトコル（例えばレイヤ２、３、および４）は、通常、別のセキュリティプロトコルが利用するフレームフォーマットとは異なるフレームフォーマットを有している。
【００４６】
レイヤ２セキュリティ暗号がインタフェース２０１経由でひとたび構築されると、無線クライアント３のドライバは、セキュリティアソシエーション（暗号化キーとパケットカウンタとを含む）を、セキュリティアソシエーションキャッシュ１３にインストールする。セキュリティアソシエーションは、セキュアな通信をサポートする２つのネットワーク実体間の共有セキュリティ情報の構築である。
【００４７】
次に、本実施形態では、レイヤ２無線ドライバ（例えば８０２.１１ドライバ２２、８０２.１６ドリアバ２４）が、レイヤ２（例えばＡＥＳ−ＣＣＭ）でネゴシエーションされたセキュリティアルゴリズムを、インタフェース２０２を介してＴＬＳプロセッサ１９へ送る。ＴＬＳプロセッサ１９は、ＴＬＳセキュリティハンドシェークをレイヤ４で実行する間に、インタフェース２０３へ送る、またはそこから来るパケットに対して無線セキュリティアルゴリズム（つまりレイヤ２）を利用する。
【００４８】
ＷＬＡＮコントローラ４が割り当て選択された暗号がＴＬＳサーバ２に提示され受諾された場合、ＴＬＳプロセッサ１９は、ＴＬＳセキュリティアソシエーションを、インタフェース２０４経由でセキュリティアソシエーションキャッシュ１３へインストールする。
【００４９】
次に、無線フレームプロセッサ１４は、無線セキュリティ（つまりレイヤ２）プロトコルハンドシェークが完了すると、インタフェース２０５経由で、セキュリティアソシエーションキャッシュ１３へ、セキュリティアソシエーション（例えば８０２.１１の対の暫定キー（ＰＴＫ）をインストールする。
【００５０】
この後で、インタフェース２０６経由でｃｏｍｍｓプロセッサ１２に到達する無線パケットは、無線フレームプロセッサ１４による処理を受けるが、この処理には、無線フレーム内の全てのフィールドがプロトコルと矛盾なく、正確な順序で送信されることを少なくとも保証することが含まれる。処理されたパケットは、無線フレームプロセッサ１４によりインタフェース２０７経由で、セキュリティ処理エンジン１７（Ｃｏｍｍｓプロセッサ１２内にある）へ送信される。この送信に関して、セキュリティ処理エンジン１７は、レイヤ２無線セキュリティアソシエーションをセキュリティアソシエーションキャッシュ１３からインタフェース２１５経由でフェッチする。セキュリティ処理エンジン１７は、セキュリティアソシエーションキャッシュ１３から各パケットについてフェッチされたセキュリティアソシエーションを用いてパケットを復号する。セキュリティ処理エンジン１７が復号した無線フレームは、無線フレームプロセッサ14へ、インタフェース２０８を介して送り返される。
【００５１】
無線フレームの復号の後で、無線フレームプロセッサ１４は、そのフレームをプロトコルに準拠するように処理する（例えば、全てのフィールドの順序を正確に揃え、それらが有効な値を含み、および、両側がプロトコルパケット処理において整合することなど）。そして、無線フレームプロセッサ１４は、復号され、正当性が確認された（validated）フレームを、ディープパケット検査エンジン１５へ、インタフェース２０９を介して送り、そこで、パケットに上位プロトコルヘッダがあるか否かを検査し、ＴＬＳ（またはＩＰｓｅｃ）パケットを特定する。
【００５２】
パケットがＴＬＳパケットである場合には、そのパケットを、インタフェース２１０を介して、Ｃｏｍｍｓプロセッサ１２内のＴＬＳ記録層セキュリティ処理エンジン１６へ送る。パケットがＴＬＳパケットでない場合には、パケットタイプに合致した別個のセキュリティ処理エンジン（不図示）による処理を受ける。ＴＬＳ記録層セキュリティ処理エンジン１６は、プロトコルヘッダに矛盾がないかを、パケットを復号目的で送信する前に検証する。
【００５３】
その後パケットを、インタフェース２１１経由でセキュリティ処理エンジン１７へ送るが、これは、無線フレームセキュリティ処理で利用されたのと同じセキュリティ処理エンジンである。セキュリティ処理エンジン１７は、セキュリティアソシエーションキャッシュ１３から取得したＴＬＳセキュリティアソシエーションを利用する。パケットのＴＬＳセキュリティ処理が終わったら（パケットの復号およびメッセージ認証チェックを含む）、処理されたパケットを、インタフェース２１２を介してＴＬＳ記録層セキュリティエンジン１６へ送り返す。
【００５４】
復号された無線フレーム全体が、インタフェース２１３経由で、無線ドライバ（例えば８０２.１１ドライバ２２）へ渡される。８０２.１１ドライバ２２は、より多くのフレーム処理を行う（例えば、検証の必要な全てのフィールドの処理）。このようなフィールド検証は、プロトコルフィールド値のチェック等を含み、このフレームを上位層プロトコル処理用に送信する。８０２.１１ドライバ２２、無線クライアント３、およびＡＰ５は、ロバスト・セキュリティ・ネットワーク・アソシエーション（ＲＳＮＡ）機能ネゴシエーション２３を、暗号、利用する認証の種類、導出するキーの種類等のセキュリティパラメータのネゴシエーションメカニズムとして利用する。他の無線ドライバ（例えば、８０２.１６ドライバ２４）も、ＲＳＮＡ機能ネゴシエーション２３同様の機能を行うセキュリティ機能ネゴシエーション２５を有する。
【００５５】
その後、無線パケットを、インタフェース２１４を介して、ＴＣＰ／ＩＰネットワークプロセッサ２１へ送り、上位層処理を行う。ＴＬＳスタックはこのパケットを取得して、上位アプリケーション（例えばブラウザ）へ転送する。無線クライアント３のＴＬＳスタックは、ＴＣＰ／ＩＰネットワークプロセッサ２１に実装することができ、あるいは、別個のプロセッサに実装することもできる。
【００５６】
ここで記載した実施形態を拡張して、８０２.１６（ＡＥＳ−ＣＣＭ）、３Ｇ、ＬＴＥ、および、ＴＬＳセキュリティプロトコルが利用するリンク内の他の無線技術に利用される暗号を含めることができる。例えば、８０２.１６無線技術を利用する場合には、ＴＬＳ記録層セキュリティエンジン１６は、復号されたフレーム全体を、インタフェース２１３ａ経由で８０２.１６ドライバへ送る。無線パケットはその後ＴＣＰ／ＩＰネットワークプロセッサ２１へ送られ（インタフェースは図２には示されていない）、上位層処理を行う。
【００５７】
図３は、本発明の実施形態によるプロトコルメッセージフローを示す。無線クライアント３およびＴＬＳサーバ２は、ＴＬＳセキュリティプロトコルのセキュリティ処理アルゴリズムについてネゴシエートして、これを無線８０２.１１／８０２.１６レイヤ２フレーム処理に用いる。
【００５８】
プロトコルはＴＬＳプロトコルについて説明したが、拡張してＩＥＴＦ ＩＰｓｅｃおよび他のトランスポート層セキュリティプロトコルを利用することもできる。本実施形態に利用可能な暗号は、ＡＥＳ−ＣＣＭ−１２８、ＡＥＳ−ＣＣＭ−１９２、ＡＥＳ−ＣＣＭ−２５６、および、これら暗号とその他の非対称認証アルゴリズム（例えばＲＳＡ、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ、ＤＳＡ等）の任意の組み合わせを含むことができるが、これらに限定されない。例えば、ＡＥＳ−ＣＣＭ暗号を暗号化に利用して、他の非対称認証アルゴリズム（例えばＲＳＡ、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ等）のいずれかを実体認証に利用することもできる。暗号化、メッセージ整合性／認証、実体認証、および、再生保護は、セキュリティの重要な部分である。選択可能なアルゴリズムは、セキュリティポリシーに応じてセキュリティ・アドミニストレータにより構成される。
【００５９】
図３を参照すると、まず、無線クライアント３のＷＮＩＣが、ＴＬＳサーバ２のＴＬＳスタックへ、メッセージ３０１を介して、８０２.１１ＲＳＮＡセキュリティハンドシェークの一貫としてネゴシエーションされた無線暗号化アルゴリズムを伝播させる。通常、ハンドシェーク（つまり「ネゴシエーション」）は、送信機と受信機同士が、自身内のサポートされているセキュリティパラメータ全てを、ハンドシェークメッセージを介して交換しあうことを含む。送信機および受信機は、全てのオプションのうち最も好適なものを選択して（優先度順にリストされている）、互いに交換する。
【００６０】
無線クライアント３内のＴＬＳクライアントスタックは、ＴＬＳ−Ｃｌｉｅｎｔ−Ｈｅｌｌｏメッセージ３０１または同等物を介した通信セッションの構築の際に、レイヤ２暗号をＴＬＳサーバ２への優先度が最も高いオプションとして利用する。または、レイヤ２暗号は、ハンドシェーク中に決定される、ＴＬＳサーバ２が利用可能なただ一つの優先度を有するセキュリティオプションであってもよい。
【００６１】
ＴＬＳサーバ２は、このセキュリティ暗号のオプションを、後続のＴＬＳセキュリティセッションでの利用のために受諾する。これは、ＴＬＳサーバ２がこの同意をＴＬＳ−Ｓｅｒｖｅｒ−Ｈｅｌｌｏメッセージ３０２で示すことで行われる。同意の後で、ＴＬＳサーバ２は、自身のセキュリティ証明書を無線クライアント３にメッセージ３０３を介して送信し、無線クライアント３も、オプションとして、自身のセキュリティ証明書をＴＬＳサーバ２にメッセージ３０９を介して送信してもよい。セキュリティ証明書の交換は、証明書およびＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅメッセージにより、ＴＬＳプロトコルの一貫として行われる。
【００６２】
無線クライアント３およびＴＬＳサーバ２は、ネゴシエーションされた暗号（例えばＡＥＳ−ＣＣＭ−１２８アルゴリズム）のＴＬＳセッションキーを計算する。無線クライアント３は、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージ３０４をＴＬＳサーバ２へ送り、ＡＥＳ−ＣＣＭ―１２８セキュリティアソシエーションの設定を示す。ＴＬＳサーバ２は、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージ３０６を無線クライアント３に送信することで応答して、対応するＡＥＳ−ＣＣＭ−１２８セキュリティアソシエーションの設定を示す。
【００６３】
無線クライアント３は、ＴＬＳ完了メッセージ３０５をＴＬＳサーバ２に送り、これは、無線セキュリティに適しているのと同じ暗号で暗号化されている（例えば、ＡＥＳ−ＣＣＭ‐１２８）。ＴＬＳサーバ２は、ＴＬＳ完了メッセージ３０７を、クライアントとの間でネゴシエーションしたものと同じ暗号セットおよびキーで暗号化して、（例えばＡＥＳ−ＣＣＭ−１２８）、無線クライアント３へ送る。ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージおよびＴＬＳ完了メッセージは、ＴＬＳプロトコルの一貫として公知である。同じ暗号が無線クライアント３およびＴＬＳサーバ２に設定された後で、暗号が保護するメッセージ３０８を交換することができる。
【００６４】
図４は、本発明の実施形態を実装するのに利用される新たなＴＬＳメッセージフォーマットを示す。示されているメッセージは、ＴＬＳプロトコル規格に追加されうる新たなまたは修正されたフィールドを含む。
【００６５】
Ｃｌｉｅｎｔ Ｈｅｌｌｏ Ｍｅｓｓａｇｅ４０１は、無線リンク層プロトコルがネゴシエーションしたセキュリティアルゴリズムを示す１以上のフィールド４０１ａの挿入により修正されている。
【００６６】
Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｍｅｓｓａｇｅ４０２は、ＴＬＳサーバ２のセキュリティポリシーについて構成された場合に無線クライアント３が優先度に応じて提案するセキュリティアルゴリズムを示すフィールド４０２ａの挿入により修正されている。
【００６７】
ＴＬＳ保護されたペイロードメッセージ４０３は、パケット番号、臨時値、およびキー識別子等のＡＥＳ−ＣＣＭセキュリティプロトコルパラメータを示すフィールド４０３ａの挿入により修正されている。新たなパケット番号を各新たなパケットに利用して、新たな臨時値を各パケットについて計算する必要がある。
【００６８】
ＴＬＳ保護されたペイロードメッセージ４０３は、ＷＬＡＮ保護されたペイロードメッセージ４０４の一部を形成する。ＷＬＡＮ保護されたペイロードメッセージ４０４には、特定の選択暗号（例えばＡＥＳ−ＣＣＭ）を有する通常のレイヤ２（例えば８０２.１１）セキュリティ処理以外に、新たな修正が必要ない。他の暗号を利用する場合には（例えばＡＥＳ−ＧＣＭ）、ＡＥＳ−ＧＣＭ暗号を利用してメッセージ４０４をセキュアにする必要がある。
【００６９】
図４はさらに、ＴＬＳプロトコルセキュリティ用のＴＬＳ保護されたペイロードメッセージ４０３内の暗号化され整合性が保護されたペイロード４０５、および、レイヤ２（例えば８０２.１１）セキュリティ用のＷＬＡＮ保護されたペイロードメッセージ４０４内の暗号化され整合性が保護されたペイロード４０６を示す。整合性の保護は、ＭＩＣ（Message Integrity Code）フィールドに実装される。図４は、さらに、Ｃｌｉｅｎｔ ＨｅｌｌｏメッセージおよびＳｅｒｖｅｒ Ｈｅｌｌｏメッセージのネゴシエーション中に利用されるＡＥＳ−ＣＣＭセキュリティアルゴリズムの識別子（例えば暗号ＩＤ）、および、データペイロードで配信されるＡＥＳ−ＣＣＭパラメータを含むフィールドも示している。
【００７０】
システムの色々な側面ではハードウェア実装およびソフトウェア実装間には余り区別がなく、ハードウェアまたはソフトウェアのいずれを利用するかは、概して費用対効果の間のトレードオフであるデザイン選択の範疇である（しかし、常にではなく、ハードウェアかソフトウェアかの選択が重要なコンテキストもある）。ここに記載した処理および／またはシステムおよび／またはその他の技術を実現しうる様々な手段が存在しており（例えば、ハードウェア、ソフトウェア、および／またはファームウェア）、好適な手段は、処理および／またはシステムおよび／またはその他の技術を配置するコンテキストに応じて変化しうる。例えば、実装者が速度と精度を最優先させる場合には、ハードウェアおよび／またはファームウェアという手段を主に採用するであろうし、柔軟性を最優先させたい場合には、実装者は主にソフトウェア実装を採用するであろうし、または、実装者はハードウェア、ソフトウェア、および／またはファームウェアの組み合わせを採用することもあろう。
【００７１】
上述では、デバイスおよび／またはプロセスの様々な実施形態を、ブロック図、フローチャート、および／または例示を利用して記載してきた。ブロック図、フローチャート、および／または例示が１以上の機能および／または動作を含む限り、当業者であれば、このブロック図、フローチャート、および／または例示内の各機能および／または動作が、個々に、または集合的に、幅広い範囲のハードウェア、ソフトウェア、ファームウェア、または実質的にこれらの任意の組み合わせにより実装可能であることを理解する。一実装例では、ここで記載した主題の複数の部分を、特定用途向けＩＣ（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、または他の集積フォーマットにより実装することが可能である。しかし、当業者であれば、ここに記載した実施形態の複数の側面が、全体的にまたは部分的に、集積回路内で、１以上のコンピュータで実行される１以上のコンピュータプログラムとして（例えば、１以上のコンピュータシステムで実行される１以上のプログラムとして）、１以上のプロセッサで実行される１以上のプログラムとして（例えば、１以上のマイクロプロセッサで実行される１以上のプログラムとして）、ファームウェアとして、または実質的にこれらの任意の組み合わせにより、同等的に実装可能であることを理解するであろうし、また、回路設計および／またはソフトウェアおよび／またはファームウェアのコード記述が、この開示に鑑みて当業者の技術的裁量の範囲にあることを理解しよう。加えて、当業者であれば、ここで記載した主題のメカニズムが、様々な形態のプログラムプロダクトによる配信が可能であること、および、ここで記載した主題に関する例示実施形態が、実際に配信を行う信号伝送媒体の特定の種類に関わらず適用可能であることを理解しよう。信号伝送媒体の例には、フロッピー（登録商標）ディスク、ハードディスクドライブ、コンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、デジタルテープ、コンピュータメモリ等の記録型媒体、および、デジタルおよび／またはアナログ通信媒体（例えば、繊維ファイバーケーブル、導波路、有線通信リンク、無線通信リンク）等の送信型媒体が含まれるが、これらに限定されない。
【００７２】
当業者であれば、デバイスおよび／またはプロセスを、ここで示した方法で記載して、記載されたデバイスおよび／またはプロセスを、後に技術的慣例を用いて、データ処理システムへと統合することが通例であることを理解する。つまり、ここで記載されたデバイスおよび／またはプロセスの少なくとも一部は、合理的な量の実験によりデータ処理システムへと統合することができる。当業者であれば、通常のデータ処理システムは、システムユニット筐体、ビデオ表示デバイス、揮発性および不揮発性メモリ等のメモリ、マイクロプロセッサおよびデジタル信号プロセッサ等のプロセッサ、オペレーティングシステム、ドライバ、グラフィックユーザインタフェース、およびアプリケーションプログラム等のコンピュータ実体、タッチパッドおよび／またはスクリーン等の１以上の対話デバイス、および／または、フィードバックループおよび制御モータを含む制御システム（感知位置および／または速度のフィードバック、コンポーネントおよび／または量の移動および／または調節を司る）のうち１以上を含むことを理解する。典型的なデータ処理システムは、データコンピューティング／通信および／またはネットワークコンピューティング／通信システムに通常見られるような、任意の適切な市販のコンポーネントを利用して実装可能である。
【００７３】
ここで記載された主題は、他のコンポーネントを含む場合があり、または、他のコンポーネントと接続される場合がある。このような示されたアーキテクチャは、あくまで例示であり、実際には、多くの他のアーキテクチャを実装しても同じ機能を達成することができる。概念的には、同じ機能を行うコンポーネントの任意の配置を効果的に「関連付ける」ことで、所望の機能を行う。故に、任意の２つのコンポーネントを組み合わせて特定の機能を行うことも、アーキテクチャまたは中間コンポーネントに関わらず、互いに「関連付け」を行って、所望の機能を達成している、とみなされる。同様に、このように関連付けられた任意の２つのコンポーネントは、所望の機能を達成するべく互いに「機能的に接続された」、または「機能的に連結された」、とみなすことができ、このように関連付けられた任意の２つのコンポーネントを、所望の機能を達成するべく互いに「機能的に連結可能」であるとみなすことができる。機能的に連結可能な特定の例には、物理的に係合可能な、および／または、物理的に相互作用可能なコンポーネント、および／または、無線で相互作用可能な、および／または、無線で相互作用するコンポーネント、および／または、論理的に相互作用する、および／または、論理的に相互作用可能なコンポーネントが含まれるが、これらに限定されない。
【００７４】
ここで利用した複数および／または単数の用語の実質的全てについて、当業者であれば、コンテキストおよび／または用途に応じて適宜、複数から単数へ、および／または、単数から複数へ変更して考えてもよいことを理解するであろう。様々な単数／複数の順序は、明瞭化を期す目的で明示されている場合が多い。
【００７５】
当業者であれば、ここで利用した用語の大半が、特に添付請求項（例えば添付請求項の本体）で利用する用語の大半が、「オープン」形式の用語を意図していること（例えば、「含む（including）」が、「含むが、それに限定されない」という意味であり、「持つ（having）」が、「少なくとも持つ」という意味であり、「含む（includes）」が、「含むが、それに限定されない」という意味である、等）を理解するであろう。さらに当業者であれば、導入される請求項の記載に特定の数が意図されている場合には、この意図は請求項に明確に記載されるべきであり、このような記載がないことは、このような意図がないことを意味することを理解するであろう。例えば、理解の助けとして、以下の添付請求項は、「少なくとも１つの」、および「１以上の」といった言い回しを用いて請求項の記載を導入している。しかし、このような言い回しの利用があるからといって、不定冠詞「ａ」または「ａｎ」による請求項の記載の導入によって、このように導入される請求項の記載を含む特定の請求項を、そのような記載を１つだけ含む発明に限定しようとする意図はない、これは、同じ請求項が、「１以上の」または「少なくとも１つの」という導入の言い回しを含み、不定冠詞「ａ」または「ａｎ」を含む場合にも同様であり（例えば、「ａ」または「ａｎ」は、通常「少なくとも１つの」または「１以上の」を意味するとして解釈される）、同じことは、請求項の記載を導入するのに利用される定冠詞の利用についても当てはまる。加えて、特定の数の導入請求項の記載を明示したとしても、当業者であればこのような記載が通常は、少なくともその記載された数であること解釈されることを理解する（例えば、「２つの記載」という記載は、他の修飾語がなくても、通常は少なくとも２つの記載、または２以上の記載、の意味である）。さらには、「少なくともＡ、ＢおよびＣ等の１つ」といった言い回しに類似した慣用句は、概して当業者がこの慣用句について想到する意味で捉えられるべきである（例えば、「少なくともＡ、ＢおよびＣのうち１つを持つシステム」という言い回しは、Ａのみ、Ｂのみ、Ｃのみ、ＡおよびＢ，ＡおよびＣ、ＢおよびＣ、および／または、Ａ、Ｂ、およびＣ、等をそれぞれ持つシステム含むが、これらに限定されない）。さらには、「少なくともＡ、ＢおよびＣ等の１つ」といった言い回しに類似した慣用句は、概して当業者がこの慣用句について想到する意味で捉えられるべきである（例えば、「少なくともＡ、ＢおよびＣのうち１つを持つシステム」という言い回しは、Ａのみ、Ｂのみ、Ｃのみ、ＡおよびＢ，ＡおよびＣ、ＢおよびＣ、および／または、Ａ、Ｂ、およびＣ、等をそれぞれ持つシステム含むが、これらに限定されない）。さらに、当業者は、実質的に、２つ以上の代替的な用語を表す論理和的な用語および／または言い回しが、明細書であっても、請求項であっても、図面であっても、それら用語の１つ、いずれか、または両方を含む可能性が考慮されるべきである。例えば、「ＡまたはＢ」という言い回しは、「Ａ」または「Ｂ」または「ＡおよびＢ」という可能性を含むこととして理解されたい。
【００７６】
特許、特許出願、および非特許文献を含むがそれらに限られない全ての参照の全体を、ここに参照として組み込む。
【００７７】
ここに開示した実施形態の様々な側面、および他の側面および実施形態は、当業者には明らかである。ここに開示した実施形態の様々な側面は、例示を意図しており、限定を意図しておらず、真の範囲および精神は以下の請求項が示している。
【００７８】
本願が開示された数値範囲内の任意の範囲をサポートする幾らかの数値範囲による限定を開示している場合であっても、発明の実施形態が開示された数値範囲による実行が可能である理由から、明細書には正確な範囲の限定を一語一句違わずに示さない場合がある。最後に、本願でもし言及された特許および刊行物があればその開示全体を参照によりここに組み込むことにする。
【背景技術】
【０００１】
本発明の実施形態は、無線通信デバイスにおける暗号化処理を向上させる装置、システムおよび方法に係る。
【０００２】
ＷｉＦｉホットスポット等の無線アクセスポイント（ＡＰ）は、空港、ホテル、喫茶店、等の多くのロケーションで公共ＷＬＡＮアクセスを提供し、無線クライアントにネットワークアクセス（例えばインターネットアクセス）を提供している。無線クライアントのなかには、暗号化等のセキュリティ手段を実装して、不正アクセス、盗聴、または正当なユーザへのなりすまし等の問題を防いでいる人もある。セキュリティ手段は、ネットワーク層におけるセキュリティプロトコル、および／または、物理層におけるセキュリティ処理として実装することができる。無線クライアントデバイスは、暗号化処理を行う１を超える数のプロセッサを有しうる。
【０００３】
本発明の実施形態は、無線クライアントにおけるセキュリティ処理の実装を向上させる方法に係る。
【図面の簡単な説明】
【０００４】
【図１】無線暗号とネゴシエーションするＴＬＳセッションを示す。
【０００５】
【図２】リンク層の無線およびＴＬＳ通信用の効率的なセキュリティ処理パケットフローのアーキテクチャを示す。
【０００６】
【図３】レイヤ２の無線セキュリティアルゴリズムとネゴシエーションする際の、ＴＬＳ標準プロトコルフローの追加分を示す。
【０００７】
【図４】本発明の実施形態をサポートするよう修正されたＴＬＳプロトコルメッセージフォーマットを示す。
【発明を実施するための形態】
【０００８】
以下の記載において、多数の詳細を述べる。しかし、本発明の実施形態は、これら詳細なしに実施可能である。他の場合には、公知な回路、構造、よび技術については詳細に示さず、本記載の理解を曖昧にしないようにしている。以下の用語集は、ここで利用する用語を定義しており、利用されるコンテキストで異なる意味が割り当てられている場合を除いてこの定義が当てはまる。ここで定義されていない用語については、「The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition」を参照されたい。
【表１】
【０００９】
ＷｉＦｉは、モバイルおよび固定通信デバイス両方に利用可能な無線通信技術である。モバイル無線技術は、ＩＥＥＥ規格８０２．１１の「Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications」およびその修正版（ここでは「ＩＥＥＥ.８０２.１１」または「８０２.１１」と称される）に規定されている。ＩＥＥＥ８０２.１１の趣意は、ポータブルまたはハンドヘルドであったり、ローカルエリア内の移動車両に搭載されるような、急速な配置を必要とする自動マシン、機器、またはステーションに無線接続を提供することである。この規格はさらに、法組織に対して、ローカルエリア通信用の１以上の周波数帯へのアクセスを規格化する手段を提供する。
【００１０】
無線ネットワーク用のセキュリティメカニズムは、元のＩＥＥＥ８０２．１１規格への修正版であり、今は公開されているＩＥＥＥ８０２．１１-２００７規格に組み込まれているＩＥＥＥ８０２．１１ｉに規定されている。
【００１１】
ＩＥＥＥ８０２．１１ｒ―２００８、あるいは、ｆａｓｔＢＳＳ（fast Basic Service Set）遷移は、ＩＥＥＥ８０２．１１規格の修正版であり、連続接続を搭載した移動する無線デバイスに対して、１つの基地局から別の基地局へとシームレスに管理された高速且つセキュアなハンドオフを提供する。ＩＥＥＥ８０２．１１ｒは、セキュリティ・キー・ネゴシエーション・プロトコルを再定義しており、無線リソースのネゴシエーションおよび要求の両方を可能とする。
【００１２】
ＩＥＥＥ８０２．１１修正版７「Interworking with External Networks」は、「ＩＥＥＥ８０２．１１ｕ」または「８０２．１１ｕ」と称されうる。ＩＥＥＥ８０２．１１ｕは、外部ネットワークとのＷＬＡＮインターワークをサポートする８０２.１１への改良点を規定しており、より高いレイヤ機能の実行を促す。ＩＥＥＥ８０２．１１ｕは、外部ネットワークからの情報転送を向上させ、ネットワーク選択を助け、緊急サービスを可能とする。
【００１３】
固定無線通信デバイスが利用する無線技術は、ＩＥＥＥ規格８０２．１６「Air Interface for Fixed Broadband Wireless Systems」およびその修正版（ここでは「ＩＥＥＥ.８０２.１６」または「８０２.１６」と称される）に規定されている。ここで利用される「無線」、「無線技術」、および類似した用語は、そうではないと明記しない限り８０２．１１または８０２．１６のことである。
【００１４】
ＩＥＥＥ８０２．１６の趣意は、マルチメディアサービスをサポートする固定ブロードバンド無線アクセス（ＢＷＡ）システムの空気インタフェースを規定することである。メディアアクセスコントロール層（ＭＡＣ）は、主に、ポイントツーマルチポイント・アーキテクチャをサポートしており、オプションとしてメッシュトポロジーをサポートしている。ＭＡＣは、マルチプル物理層（ＰＨＹ）仕様をサポートするよう構成され、仕様各々は特定の動作環境に適合している。１０‐６６ＧＨｚの動作周波数では、ＰＨＹはシングルキャリア変調に基づく。直接見えるラインを利用せずに伝播が行われる１１ＧＨｚ未満の周波数では、直交周波数分割多重（つまり、無線ＭＡＮ−ＯＦＤＭまたは「ＯＦＤＭ」）、直交周波数分割マルチプルアクセス（つまり、無線ＭＡＮ−ＯＦＤＭＡまたは「ＯＦＤＭＡ」）、および、シングルキャリア変調を利用する直交周波数分割（つまり、無線ＭＡＮ−ＳＣａまたは「シングルキャリア変調」）という３つの選択肢がある。
【００１５】
ＩＥＥＥ８０２．１６ｅは、車両スピードで移動する加入ステーションをサポートして、固定およびモバイルブロードバンド無線アクセスを組み合わせたシステムを規定するＩＥＥＥ Ｓｔｄ８０２．１６への改良点を規定している。固定ＩＥＥＥ８０２．１６の加入者機能が損なわれることはない。
【００１６】
ＩＥＥＥ８０２．１６ｍは、ＩＥＥＥ８０２．１６への修正案であり、高度な次世代モバイルネットワークのセルラー層の要件に見合う高度な空気インタフェースを提供して、同時に、レガシー無線機器へのサポートも継続して可能とする。
【００１７】
ＷｉＦｉホットスポットは、例えば空港、ホテル、喫茶店、等の多くのロケーションで公共ＷＬＡＮアクセスを提供し、インターネットアクセス、ビデオストリーミング（例えばＩＰ ＴＶ）、ＩＭＳ、およびオンラインゲーム等の様々なサービスを提供してよい。盗聴、なりすまし、不正アクセス等の問題を防ぐセキュリティの必要性が叫ばれている。セキュリティは、２つ以上のネットワークモデル層に提供されうる。
【００１８】
ネットワーク可能な無線デバイスには、無線ネットワークインタフェースカード（ＷＮＩＣ）が含まれる。無線デバイス上の従来のパケット処理は、ＷＮＩＣ上で無線セキュリティ処理を行い、ＴＬＳ（またはＩＰＳｅｃ）パケットが無線デバイスのメインプロセッサ上で処理され、その後、無線デバイス内の異なる暗号化プロセッサへと送られて、セキュリティ処理を受け、無線デバイスのメインプロセッサへ送り返されて、アプリケーション（例えばブラウザ）へ、さらに送られる。
【００１９】
ＩＥＴＦ ＴＬＳ／ＳＳＬセキュリティプロトコルは、セキュリティ処理アルゴリズムを、低位な層における無線セキュリティ処理に用いられるプロトコルとは離れた、より高位な層で利用する（例えば、ＩＥＥＥ８０２.１１ｉ、８０２.１１ｒ、８０２.１６ｅ、および８０２.１６ｍにその規定がある）。これは、きめの粗いクライアント処理（例えばラップトップコンピュータのトランスポート層のセキュリティ用）には適しているが、ＴＬＳ層において既存のセキュリティ法を、より低度な層で処理される通信パケットに適用することには無理がある、というのも、このような方法ではパケットセキュリティ処理オーバヘッドが増えるからである。無線デバイスでＴＬＳ／ＳＳＬセキュリティプロトコルを用いて各パケットを処理することには、ホストと暗号機能を実装したプロセッサとの間で、および別個のＷＮＩＣプロセッサとの間で、複雑な、マルチループパスを実行することが含まれうる。ここで利用されるプロセッサ（利用されるコンテキストで異なる意味が示されている場合を除いて）は、処理機能を実装するそれぞれ別個の処理チップ、または、同じチップに物理的に位置するそれぞれ独立した処理コアを含みうる。
【００２０】
セキュリティ処理段階の増加は、ＴＬＳ規格がクライアントに対して、無線レイヤ２（つまり、ネットワーク層）セキュリティ暗号とのネゴシエーションを許可していないことが原因である。ＴＬＳ規格では、トランスポート層セキュリティ処理は、暗号機能を実行するプロセッサ（例えばホストプロセッサまたはラップトップ）上で実行されるソフトウェアアルゴリズムにより行われる。通常、無線パケットおよびセキュリティ処理は、別々の無線プロセッサ上で行われる。この処理タスクの分断により、無線デバイスの電力消費全体が劣化する、というのも、信号（データパケットおよび状態を含む）が、１つのチップセットから別のチップセットへと駆動される必要があるからである。さらに、セキュリティ処理を行っている間、これらプロセッサの幾らかを低電力消費に長い間しておくことができないことが多い。
【００２１】
低電力、ウルトラモバイルデバイス（例えば、ＭＩＤ（Mobile Internet Device）／ＵＭＰＣ（Ultra-Mobile PC）デバイス）では、各通信パケットの処理に必要とされる電力消費および待ち時間は、セキュリティ処理段階の増加により、顕著に増える。これは、バッテリを短命にして、必要な放熱量が増えるので望ましくない。
【００２２】
上述の問題を克服するべく、本発明の実施形態は、ＩＥＴＦ ＴＬＳまたはＩＥＴＦ ＩＰｓｅｃ規格のセキュリティ面を拡張させて、ＭＩＤアーキテクチャに、電力効率の良い、流線型のセキュリティパケット処理を行わせることを目指す。トランスポート層セキュリティプロトコルは、インターネットのユビキタス・アプリケーション・セキュリティ・プロトコルであり、銀行取引、イントラネットセキュリティ、ウェブサービス等で利用されている。本発明の実施形態は、さらに、セキュリティ処理に利用される時間の少なくとも一部の間に、無線デバイスの少なくとも一部を低電力消費モードにすることにより、無線デバイスの電力消費を低減するという利点を有する。特に、ホスト／チップセットの複合体をこのような低電力状態にして、ＷＮＩＣの全てのセキュリティ処理が終了したところで起こして高電力状態とすることができる。
【００２３】
特に、本発明の実施形態は、第１のネットワーク層と、第１のネットワーク層とは異なる第２のネットワーク層とにおける通信セキュリティを、第１のプロセッサを持つ無線クライアントに提供する方法であって、第１のネットワーク層に関連付けられた第１のコントローラから、第１のネットワーク層でのセキュリティ処理用にセキュリティアルゴリズムを取得する段階と、第２のネットワーク層に関連付けられた第２のコントローラと、第２のネットワーク層でのセキュリティ処理へのセキュリティアルゴリズムの利用についてネゴシエーションする段階とを備え、無線クライアントでの第１のネットワーク層および第２のネットワーク層におけるセキュリティ処理は、第１のプロセッサで行われる方法を提供してよい。
【００２４】
さらに、方法は、第１のコントローラからセキュリティアルゴリズムを取得する段階、および、第２のコントローラとネゴシエーションする段階のうち少なくとも一部を行う間、無線クライアントの少なくとも一部を低電力レベルで動作させる段階をさらに備える。
【００２５】
オプションとして、方法においては、第１のネットワーク層はリンク層であり、第２のネットワーク層はネットワーク層であってよい。例えば第２のネットワーク層は、ＴＬＳまたはＩＰｓｅｃであってよい。
【００２６】
さらに方法では、第１のコントローラからセキュリティアルゴリズムを取得する段階が、第１層セキュリティ用にセキュリティアルゴリズムを、無線クライアントが、第１のコントローラに対して要求する段階と、セキュリティアルゴリズムを、無線クライアント内のＴＬＳスタックへ送る段階とを備えてよい。
【００２７】
またさらに方法では、第２のコントローラとネゴシエーションする段階が、第２のコントローラに対して、第２のコントローラが無線クライアントと通信する際のネットワーク層セキュリティを提供する用途向けに、セキュリティアルゴリズムを提示する段階と、第２のコントローラからセキュリティアルゴリズム証明を受信する段階と、無線クライアントを、第１層セキュリティ処理および第２層セキュリティ処理用の両方にセキュリティアルゴリズムを利用するよう構成する段階とを有してよい。
【００２８】
例えば、方法のセキュリティアルゴリズムは、ＡＥＳ−ＣＣＭまたはＡＥＳ−ＧＣＭであってよい。
【００２９】
セキュリティアルゴリズムをＴＬＳスタックへ送る段階は、セキュリティアルゴリズムをＴＬＳセッションの最優先セキュリティアルゴリズムとする段階をさらに有する、またはセキュリティアルゴリズムをＴＬＳスタック内に構成する段階をさらに有する。
【００３０】
現在のところ、ＴＬＳプロトコルは、ＴＬＳ用のＡＥＳ−ＣＣＭ（Advanced Encryption Standard / Cipher Block Chaining-Message Authentication Code）セキュリティアルゴリズムを含むというオプションがない。概して、ここで用いられるセキュリティアルゴリズムは暗号（cipher）と称される。暗号はセキュリティプロトコルの一部である。概して、セキュリティプロトコルは、認証、キーアサート、活性チェック（liveness check）、および関連機能を含む。ＡＥＳ−ＣＣＭ暗号は、８０２.１１および８０２.１６で幅広く利用されているが、ＡＥＳ‐ＧＣＭ等の他の暗号も利用可能である。本発明の実施形態は、暗号化ネゴシエーション中にレイヤ２暗号（例えばＡＥＳ−ＣＣＭ、ＡＥＳ−ＧＣＭ等）の、ＴＬＳプロトコルへの追加を記載しており、これにより、ＩＥＥＥ８０２.１１およびＩＥＥＥ８０２.１６を実装するプロセッサが、既存のレイヤ２暗号化処理エンジン（ＡＥＳ−ＣＣＭおよびＡＥＳ−ＧＣＭ）を利用してＴＬＳセキュリティ処理を行うことができるようになる。ここで利用されるエンジンは、ルックアップおよび／または分類ロジックのセットであり、ファームウェアおよび／またはハードウェアに実装され、各ネットワーク層でパケットのプロトコルタイプおよびセキュリティタイプを検出する。
【００３１】
本発明の実施形態によるＷＬＡＮおよびＴＬＳセキュリティ用に処理されるパケットは、パイプライン方式で処理され、現行のマルチループ処理を必要としない。これは、各パケットを処理するときの消費電力を低減できるというメリットがある。さらに、セキュリティ処理をＷＮＩＣで行う間、無線デバイスの他の処理部分を節電モードとしておき、セキュリティ処理が完了してから節電モードを解除することができるので、無線デバイスのさらなる節電およびバッテリ寿命の延命が可能である。基本的なパケット処理分析に基づいて、本発明は、小型の低電力デバイス（例えばＭＩＤ／ＵＭＰＣプラットフォーム、および／または、８０２.１１、８０２.１６または他の無線アクセスプロトコルを介したインターネットアクセスを可能とするモバイルフォンまたはスマートフォン）の利用におけるバッテリ寿命を向上させる。
【００３２】
本発明の実施形態は、それぞれ異なるプロトコル層についてセキュリティを処理する多数のエンジンを利用する必要性がないので、無線デバイスに対して良い影響を及ぼすＴＬＳプロトコルの変更である。本発明の実施形態は、シングル・クロスレイヤ・セキュリティ・プロセッサを導入する。従来の無線製品は、全ての無線（レイヤ２）、ＩＰｓｅｃ（レイヤ３）、およびＴＬＳ（レイヤ４）セキュリティ処理に対して単一のまたは統一されたセキュリティ処理を有さない。
【００３３】
本発明の実施形態は、入力パケットのネットワークセキュリティの効率的な多層処理のために、ネットワーク階層の多層にまたがって分断するパイプラインモードを提供する。このパイプラインモードにより、シングルプロセッサチップのセキュリティエンジンによりシングルパスにおけるセキュリティ処理が可能となる。本発明の実施形態は、パイプライン間に、ディープ・パケット・ルックアップ・エンジンを追加する。当業者であれば理解するように、ディープパケット（「ＤＰ」）ルックアップは、一連のパケット処理によりパケットヘッダおよびペイロード両方のコンテンツを分析することで動作する。この結果、ＤＰによりネットワーク利用を分析して、ネットワーク性能を最適化する機能が提供され、これにより、ネットワークオペレータは、より効果的にネットワークのトラフィックフローを管理することができるようになる。
【００３４】
本発明の一実施形態は、ＡＥＳ−ＣＣＭをＴＬＳプロトコルに追加することで、少なくとも以下の有利な効果を生じる。（１）ＡＥＳ−ＣＣＭは、より効率的なセキュリティアルゴリズムであり、ＷＮＩＣによるレイヤ２で行われるセキュリティ処理と比べて、セキュリティパケットの処理スループットまたは処理速度を向上させることができ、ＡＥＳ−ＣＣＭ暗号処理をＴＬＳプロトコルに加えることで、ＴＬＳパケット処理待ち時間が全体的に向上する。また、ＡＥＳ−ＣＣＭ暗号処理には、パケット毎に５つのブロック暗号処理しか必要とされないので、セキュリティ暗号処理の終了後にパケット拡張が最小となる、というさらなる利点も生じる。暗号および復号は両方とも、１つのブロックの暗号の暗号機能（one block cipher encryption function）を必要とする。暗号化および認証は、ハードウェアにより同時に行うことができ、認証チェックを行う前に暗号化が完了している必要はない。（２）ＡＥＳ−ＣＣＭの利用により、データの機密保持用のＡＥＳ−ＣＴＲモードと、整合性および認証用のＣＢＣ−ＭＡＣ（Cipher Block Chaining Message Authentication Code）を組み合わせることができる。ＡＥＳ−ＣＴＲおよびＣＢＣ−ＭＡＣは、当業者に公知な動作モードである。ＡＥＳ−ＣＴＲおよびＣＢＣ−ＭＡＣを組み合わせる技術も当業者に公知である（例えば、R.Housley（RSA Laboratories所属）著「Counter with CBC-MAC (CCM) AES Mode of Operation」、ＮＩＳＴへの公共提出参照）。（３）ＡＥＳ−ＣＣＭは、さらに、同アルゴリズムの一貫として、暗号化およびＭＩＣ（Message Integrity Code）計算を行うことができる。これにより、現在のＴＬＳのような暗号化とメッセージの認証とを別々に行う必要がなくなる。これに対して、ＳＨＡ整合性セキュリティアルゴリズムを利用して暗号化を行う従来の方法では、ＡＥＳを利用する方法よりもコンピューティングの面で比較的高価になる。（４）ＷＮＩＣが既にＡＥＳ−ＣＣＭ処理機能をサポートしている限りにおいては、ＡＥＳ−ＣＣＭをＴＬＳプロトコル規格に追加することにより、既存のＷＮＩＣハードウェアを利用しつつＷＮＩＣハードウェアを拡張して、ＴＬＳセキュリティを実行することができるようになる。
【００３５】
以下に、図１を参照ながら、プロトコルコンポーネント、プロトコルメッセージフロー、および拡張行動を含む本発明の第１の実施形態を示す。図１は、例示的なネットワークレベル図を示しており、クライアントがＴＬＳセキュリティで保護された任意のアプリケーションサーバでＴＬＳセッションを開始して、ＴＬＳ拡張を利用するときのネットワークの主要なコンポーネントを示す。図１は、無線クライアント３が遠隔ＴＬＳサーバ２と、無線層が利用するものと同じ暗号セット（cryptographic cipher suites）についてネゴシエーションする本発明の一実施形態を示す。ここで言う暗号セットは（利用されるコンテキストから異なる意味が明確な場合を除いて）、メッセージを保護する、関連する暗号化アルゴリズムのファミリー（ＡＥＳ、ＤＥＳ等）のことである。ＴＬＳサーバ２は、アプリケーション・セキュリティ・サーバの一実施形態である。ＴＬＳスタックとは、ＴＬＳプロトコルパケットを処理するマシン上の汎用ソフトウェアおよび／またはハードウェアコンポーネントのことである。本発明の実施形態は、非ＴＬＳプロトコル用のアプリケーション・セキュリティ・サーバの利用により、非ＴＬＳプロトコルを利用するネットワークでも実施可能である。
【００３６】
図１を参照すると、ＷＬＡＮコントローラ４が、５で示されている無線アクセスポイントＡＰを制御する。さらなるアクセスポイント（不図示）も、ＷＬＡＮコントローラ４により制御されてよい。ＷＬＡＮコントローラ４およびアクセスポイント５は、互換性のある技術である（例えば、８０２.１１および８０２.１６両方）。無線クライアント３は、ラップトップＰＣとして示されているが、ＩＥＥＥ８０２.１１および／または８０２.１６と互換性のある無線通信機能を有する任意の通信デバイスであってよい。本発明の実施形態は、他の無線技術規格にも適用可能である点を理解されたい。無線クライアント３は、少なくとも１つのアクセスポイント（例えばＡＰ５）と通信８している。
【００３７】
無線クライアント３は、ＡＰ５から暗号を受け取る（例えばリンク層で利用するＡＥＳ−ＣＣＭ−１２８暗号）。しかし、本実施形態はこの暗号に限定されず、全ての現行の暗号およびセキュリティモード、無線またはＴＬＳセットに将来導入される暗号、および、ＡＥＳの他のセキュリティモードへの適用が可能である。ここで利用される「モード」は（利用されるコンテキストから異なる意味が明確な場合を除いて）、暗号を特定の目的に利用することである（例えば、ＡＥＳを暗号化のみに利用することが１つのモードであり、ＡＥＳを暗号化と認証とに利用することが第２のモードである、等）。
【００３８】
無線クライアント３は、ＴＬＳプロトコル（クライアント無線ドライバ等の様々なソフトウェアコンポーネント（不図示）、ＴＬＳスタック（不図示）、およびインタープロセッサ通信に利用されるソフトウェアドライバを含む）を実装する。ＴＬＳスタックは、無線クライアント３内のプロトコル処理コンポーネントのセットである。無線クライアント３がリンク層暗号をＡＰ５から取得した後で、無線クライアント３のリンク層ドライバは、この暗号を無線クライアント３のＴＬＳスタックへ送り、この暗号をＴＬＳセッションに相応しい暗号として配置する。プラットフォームは多くのレイヤ２の暗号（例えばＡＥＳ−ＣＣＭおよびＡＥＳ−ＧＣＭ）をサポートしうるが、ＡＰ５との間で単一のレイヤ２の暗号のみをネゴシエーションしてもよい。または、単一のレイヤ２の暗号のみをサポートする複数のプラットフォームでは、サポートされるレイヤ２の暗号の情報を無線クライアント３のＴＬＳスタック内に構成することもできる。「暗号をＴＬＳスタックに構成する」ということは、暗号をＴＬＳスタックへ送ることと同等であってよい。
【００３９】
そして無線クライアントは、遠隔アプリケーションサーバとの間でＴＬＳセッションを開始してよい。無線クライアント３がこのセッションを開始すると、無線クライアント３は、ＡＰ５から取得した暗号（例えばＡＥＳ−ＣＣＭ−１２８暗号）を、ＴＬＳサーバ２が受諾する暗号として提示する。
【００４０】
ＴＬＳサーバ２は、その後、無線クライアント３が提示する暗号を処理し、暗号がＴＬＳサーバ２によりサポートされている場合には、無線クライアントが提示する暗号を、トランスポート層セキュリティ用の暗号として受諾する。
【００４１】
無線クライアント３およびＴＬＳサーバ２は、ＡＰ５から取得した暗号（例えばＡＥＳ−ＣＣＭ−１２８暗号）を用いて、この暗号を用いて通信リンクを開始することにより、アプリケーショントランスポート層セキュリティを構築する。
【００４２】
無線クライアント３はさらに、同じセキュリティ処理エンジンを自身の無線プロセッサで用いて、レイヤ２（ネットワーク層）およびレイヤ４（トランスポート層）セキュリティ処理セキュリティを並行して処理してよい。この並行セキュリティ処理は、暗号により互いに関連付けられるが、必ずしも時間的に同時に行われる必要はない。オプションとして、別個のセキュリティ処理エンジンを利用することもできる（例えば、マルチコアＣＰＵとともに実装される無線クライアントのような場合において）。
【００４３】
上述の第１の実施形態によると、無線クライアント３は、トランスポート層（レイヤ４）およびネットワーク層（レイヤ２）における両方の無線セキュリティ用のパケットを処理することができ、これには無線クライアント３のメインプロセッサを起こす必要がなく、メインプロセッサを介して暗号化パケットをルーティングする必要もない。
【００４４】
図２は、本実施形態の方法による無線およびＴＬＳ処理の効率的なセキュリティ処理パケットフローを行うための無線クライアント内のアーキテクチャを示す。アーキテクチャは、マルチコアプラットフォーム１０（つまり、多数の独立した処理コアを有するプロセッサ）に関して記載されているが、これは、マルチコアプラットフォーム１０が本発明の実施形態を記載する上で最も柔軟性が大きい、という理由による。本実施形態で説明される機能は、例えば、１以上の仮想化および／または仮想プラットフォーム等の様々な種類のプロセッサ（つまり、仮想技術を利用するプラットフォームであり、仮想化は同じソフトウェアを異なるハードウェア上で動かせる技術である）マルチコアプロセッサ、システムオンチップ、またはマルチチップソリューションで、相互利用可能である。この実行は、アプリケーションサーバ１、ＴＬＳサーバ２、ＷＬＡＮコントローラ４、および／または、無線クライアント３が、これらの種類のプロセッサのいずれとも、本発明の第１の実施形態の方法に影響を及ぼすことなく、実装可能であるという意味で相互利用可能である。
【００４５】
図２のアーキテクチャは、パイプラインモードを用いてスタックの異なる層のパケットを処理するＣｏｍｍｓプロセッサ１２のセキュリティ処理エンジン１１を特徴とする。Ｃｏｍｍｓプロセッサ１２は通信エンジンである。図２の様々なエンジンは、マルチコアプロセッサ内の複数のコアの任意の組み合わせに実装可能である。パイプラインモードは、パケット処理に必要な処理段階の幅広い機能パイプラインのことである。パイプラインモードでは、多層セキュリティ用の全てのパケットを処理するセキュリティ・パイプライン・アーキテクチャを利用し、各パケットは上層の存在について検査される。本実施形態ではレイヤ２およびレイヤ４セキュリティ処理が示されている。これはさらに、レイヤ２およびレイヤ３（つまりＩＥＴＦ ＩＰｓｅｃ）セキュリティ処理にも適用される。当業者であれば、ここで開示する方法を、レイヤ２およびレイヤ３通信を処理するよう適合することには、１パケット内の異なるフィールドを検査して、処理する層に適切な異なるセキュリティカプセル化処理（security encapsulation processing）を適用することが含まれることを理解する。全てのセキュリティプロトコル（例えばレイヤ２、３、および４）は、通常、別のセキュリティプロトコルが利用するフレームフォーマットとは異なるフレームフォーマットを有している。
【００４６】
レイヤ２セキュリティ暗号がインタフェース２０１経由でひとたび構築されると、無線クライアント３のドライバは、セキュリティアソシエーション（暗号化キーとパケットカウンタとを含む）を、セキュリティアソシエーションキャッシュ１３にインストールする。セキュリティアソシエーションは、セキュアな通信をサポートする２つのネットワーク実体間の共有セキュリティ情報の構築である。
【００４７】
次に、本実施形態では、レイヤ２無線ドライバ（例えば８０２.１１ドライバ２２、８０２.１６ドリアバ２４）が、レイヤ２（例えばＡＥＳ−ＣＣＭ）でネゴシエーションされたセキュリティアルゴリズムを、インタフェース２０２を介してＴＬＳプロセッサ１９へ送る。ＴＬＳプロセッサ１９は、ＴＬＳセキュリティハンドシェークをレイヤ４で実行する間に、インタフェース２０３へ送る、またはそこから来るパケットに対して無線セキュリティアルゴリズム（つまりレイヤ２）を利用する。
【００４８】
ＷＬＡＮコントローラ４が割り当て選択された暗号がＴＬＳサーバ２に提示され受諾された場合、ＴＬＳプロセッサ１９は、ＴＬＳセキュリティアソシエーションを、インタフェース２０４経由でセキュリティアソシエーションキャッシュ１３へインストールする。
【００４９】
次に、無線フレームプロセッサ１４は、無線セキュリティ（つまりレイヤ２）プロトコルハンドシェークが完了すると、インタフェース２０５経由で、セキュリティアソシエーションキャッシュ１３へ、セキュリティアソシエーション（例えば８０２.１１の対の暫定キー（ＰＴＫ）をインストールする。
【００５０】
この後で、インタフェース２０６経由でｃｏｍｍｓプロセッサ１２に到達する無線パケットは、無線フレームプロセッサ１４による処理を受けるが、この処理には、無線フレーム内の全てのフィールドがプロトコルと矛盾なく、正確な順序で送信されることを少なくとも保証することが含まれる。処理されたパケットは、無線フレームプロセッサ１４によりインタフェース２０７経由で、セキュリティ処理エンジン１７（Ｃｏｍｍｓプロセッサ１２内にある）へ送信される。この送信に関して、セキュリティ処理エンジン１７は、レイヤ２無線セキュリティアソシエーションをセキュリティアソシエーションキャッシュ１３からインタフェース２１５経由でフェッチする。セキュリティ処理エンジン１７は、セキュリティアソシエーションキャッシュ１３から各パケットについてフェッチされたセキュリティアソシエーションを用いてパケットを復号する。セキュリティ処理エンジン１７が復号した無線フレームは、無線フレームプロセッサ14へ、インタフェース２０８を介して送り返される。
【００５１】
無線フレームの復号の後で、無線フレームプロセッサ１４は、そのフレームをプロトコルに準拠するように処理する（例えば、全てのフィールドの順序を正確に揃え、それらが有効な値を含み、および、両側がプロトコルパケット処理において整合することなど）。そして、無線フレームプロセッサ１４は、復号され、正当性が確認された（validated）フレームを、ディープパケット検査エンジン１５へ、インタフェース２０９を介して送り、そこで、パケットに上位プロトコルヘッダがあるか否かを検査し、ＴＬＳ（またはＩＰｓｅｃ）パケットを特定する。
【００５２】
パケットがＴＬＳパケットである場合には、そのパケットを、インタフェース２１０を介して、Ｃｏｍｍｓプロセッサ１２内のＴＬＳ記録層セキュリティ処理エンジン１６へ送る。パケットがＴＬＳパケットでない場合には、パケットタイプに合致した別個のセキュリティ処理エンジン（不図示）による処理を受ける。ＴＬＳ記録層セキュリティ処理エンジン１６は、プロトコルヘッダに矛盾がないかを、パケットを復号目的で送信する前に検証する。
【００５３】
その後パケットを、インタフェース２１１経由でセキュリティ処理エンジン１７へ送るが、これは、無線フレームセキュリティ処理で利用されたのと同じセキュリティ処理エンジンである。セキュリティ処理エンジン１７は、セキュリティアソシエーションキャッシュ１３から取得したＴＬＳセキュリティアソシエーションを利用する。パケットのＴＬＳセキュリティ処理が終わったら（パケットの復号およびメッセージ認証チェックを含む）、処理されたパケットを、インタフェース２１２を介してＴＬＳ記録層セキュリティエンジン１６へ送り返す。
【００５４】
復号された無線フレーム全体が、インタフェース２１３経由で、無線ドライバ（例えば８０２.１１ドライバ２２）へ渡される。８０２.１１ドライバ２２は、より多くのフレーム処理を行う（例えば、検証の必要な全てのフィールドの処理）。このようなフィールド検証は、プロトコルフィールド値のチェック等を含み、このフレームを上位層プロトコル処理用に送信する。８０２.１１ドライバ２２、無線クライアント３、およびＡＰ５は、ロバスト・セキュリティ・ネットワーク・アソシエーション（ＲＳＮＡ）機能ネゴシエーション２３を、暗号、利用する認証の種類、導出するキーの種類等のセキュリティパラメータのネゴシエーションメカニズムとして利用する。他の無線ドライバ（例えば、８０２.１６ドライバ２４）も、ＲＳＮＡ機能ネゴシエーション２３同様の機能を行うセキュリティ機能ネゴシエーション２５を有する。
【００５５】
その後、無線パケットを、インタフェース２１４を介して、ＴＣＰ／ＩＰネットワークプロセッサ２１へ送り、上位層処理を行う。ＴＬＳスタックはこのパケットを取得して、上位アプリケーション（例えばブラウザ）へ転送する。無線クライアント３のＴＬＳスタックは、ＴＣＰ／ＩＰネットワークプロセッサ２１に実装することができ、あるいは、別個のプロセッサに実装することもできる。
【００５６】
ここで記載した実施形態を拡張して、８０２.１６（ＡＥＳ−ＣＣＭ）、３Ｇ、ＬＴＥ、および、ＴＬＳセキュリティプロトコルが利用するリンク内の他の無線技術に利用される暗号を含めることができる。例えば、８０２.１６無線技術を利用する場合には、ＴＬＳ記録層セキュリティエンジン１６は、復号されたフレーム全体を、インタフェース２１３ａ経由で８０２.１６ドライバへ送る。無線パケットはその後ＴＣＰ／ＩＰネットワークプロセッサ２１へ送られ（インタフェースは図２には示されていない）、上位層処理を行う。
【００５７】
図３は、本発明の実施形態によるプロトコルメッセージフローを示す。無線クライアント３およびＴＬＳサーバ２は、ＴＬＳセキュリティプロトコルのセキュリティ処理アルゴリズムについてネゴシエートして、これを無線８０２.１１／８０２.１６レイヤ２フレーム処理に用いる。
【００５８】
プロトコルはＴＬＳプロトコルについて説明したが、拡張してＩＥＴＦ ＩＰｓｅｃおよび他のトランスポート層セキュリティプロトコルを利用することもできる。本実施形態に利用可能な暗号は、ＡＥＳ−ＣＣＭ−１２８、ＡＥＳ−ＣＣＭ−１９２、ＡＥＳ−ＣＣＭ−２５６、および、これら暗号とその他の非対称認証アルゴリズム（例えばＲＳＡ、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ、ＤＳＡ等）の任意の組み合わせを含むことができるが、これらに限定されない。例えば、ＡＥＳ−ＣＣＭ暗号を暗号化に利用して、他の非対称認証アルゴリズム（例えばＲＳＡ、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ等）のいずれかを実体認証に利用することもできる。暗号化、メッセージ整合性／認証、実体認証、および、再生保護は、セキュリティの重要な部分である。選択可能なアルゴリズムは、セキュリティポリシーに応じてセキュリティ・アドミニストレータにより構成される。
【００５９】
図３を参照すると、まず、無線クライアント３のＷＮＩＣが、ＴＬＳサーバ２のＴＬＳスタックへ、メッセージ３０１を介して、８０２.１１ＲＳＮＡセキュリティハンドシェークの一貫としてネゴシエーションされた無線暗号化アルゴリズムを伝播させる。通常、ハンドシェーク（つまり「ネゴシエーション」）は、送信機と受信機同士が、自身内のサポートされているセキュリティパラメータ全てを、ハンドシェークメッセージを介して交換しあうことを含む。送信機および受信機は、全てのオプションのうち最も好適なものを選択して（優先度順にリストされている）、互いに交換する。
【００６０】
無線クライアント３内のＴＬＳクライアントスタックは、ＴＬＳ−Ｃｌｉｅｎｔ−Ｈｅｌｌｏメッセージ３０１または同等物を介した通信セッションの構築の際に、レイヤ２暗号をＴＬＳサーバ２への優先度が最も高いオプションとして利用する。または、レイヤ２暗号は、ハンドシェーク中に決定される、ＴＬＳサーバ２が利用可能なただ一つの優先度を有するセキュリティオプションであってもよい。
【００６１】
ＴＬＳサーバ２は、このセキュリティ暗号のオプションを、後続のＴＬＳセキュリティセッションでの利用のために受諾する。これは、ＴＬＳサーバ２がこの同意をＴＬＳ−Ｓｅｒｖｅｒ−Ｈｅｌｌｏメッセージ３０２で示すことで行われる。同意の後で、ＴＬＳサーバ２は、自身のセキュリティ証明書を無線クライアント３にメッセージ３０３を介して送信し、無線クライアント３も、オプションとして、自身のセキュリティ証明書をＴＬＳサーバ２にメッセージ３０９を介して送信してもよい。セキュリティ証明書の交換は、証明書およびＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅメッセージにより、ＴＬＳプロトコルの一貫として行われる。
【００６２】
無線クライアント３およびＴＬＳサーバ２は、ネゴシエーションされた暗号（例えばＡＥＳ−ＣＣＭ−１２８アルゴリズム）のＴＬＳセッションキーを計算する。無線クライアント３は、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージ３０４をＴＬＳサーバ２へ送り、ＡＥＳ−ＣＣＭ―１２８セキュリティアソシエーションの設定を示す。ＴＬＳサーバ２は、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージ３０６を無線クライアント３に送信することで応答して、対応するＡＥＳ−ＣＣＭ−１２８セキュリティアソシエーションの設定を示す。
【００６３】
無線クライアント３は、ＴＬＳ完了メッセージ３０５をＴＬＳサーバ２に送り、これは、無線セキュリティに適しているのと同じ暗号で暗号化されている（例えば、ＡＥＳ−ＣＣＭ‐１２８）。ＴＬＳサーバ２は、ＴＬＳ完了メッセージ３０７を、クライアントとの間でネゴシエーションしたものと同じ暗号セットおよびキーで暗号化して、（例えばＡＥＳ−ＣＣＭ−１２８）、無線クライアント３へ送る。ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージおよびＴＬＳ完了メッセージは、ＴＬＳプロトコルの一貫として公知である。同じ暗号が無線クライアント３およびＴＬＳサーバ２に設定された後で、暗号が保護するメッセージ３０８を交換することができる。
【００６４】
図４は、本発明の実施形態を実装するのに利用される新たなＴＬＳメッセージフォーマットを示す。示されているメッセージは、ＴＬＳプロトコル規格に追加されうる新たなまたは修正されたフィールドを含む。
【００６５】
Ｃｌｉｅｎｔ Ｈｅｌｌｏ Ｍｅｓｓａｇｅ４０１は、無線リンク層プロトコルがネゴシエーションしたセキュリティアルゴリズムを示す１以上のフィールド４０１ａの挿入により修正されている。
【００６６】
Ｓｅｒｖｅｒ Ｈｅｌｌｏ Ｍｅｓｓａｇｅ４０２は、ＴＬＳサーバ２のセキュリティポリシーについて構成された場合に無線クライアント３が優先度に応じて提案するセキュリティアルゴリズムを示すフィールド４０２ａの挿入により修正されている。
【００６７】
ＴＬＳ保護されたペイロードメッセージ４０３は、パケット番号、臨時値、およびキー識別子等のＡＥＳ−ＣＣＭセキュリティプロトコルパラメータを示すフィールド４０３ａの挿入により修正されている。新たなパケット番号を各新たなパケットに利用して、新たな臨時値を各パケットについて計算する必要がある。
【００６８】
ＴＬＳ保護されたペイロードメッセージ４０３は、ＷＬＡＮ保護されたペイロードメッセージ４０４の一部を形成する。ＷＬＡＮ保護されたペイロードメッセージ４０４には、特定の選択暗号（例えばＡＥＳ−ＣＣＭ）を有する通常のレイヤ２（例えば８０２.１１）セキュリティ処理以外に、新たな修正が必要ない。他の暗号を利用する場合には（例えばＡＥＳ−ＧＣＭ）、ＡＥＳ−ＧＣＭ暗号を利用してメッセージ４０４をセキュアにする必要がある。
【００６９】
図４はさらに、ＴＬＳプロトコルセキュリティ用のＴＬＳ保護されたペイロードメッセージ４０３内の暗号化され整合性が保護されたペイロード４０５、および、レイヤ２（例えば８０２.１１）セキュリティ用のＷＬＡＮ保護されたペイロードメッセージ４０４内の暗号化され整合性が保護されたペイロード４０６を示す。整合性の保護は、ＭＩＣ（Message Integrity Code）フィールドに実装される。図４は、さらに、Ｃｌｉｅｎｔ ＨｅｌｌｏメッセージおよびＳｅｒｖｅｒ Ｈｅｌｌｏメッセージのネゴシエーション中に利用されるＡＥＳ−ＣＣＭセキュリティアルゴリズムの識別子（例えば暗号ＩＤ）、および、データペイロードで配信されるＡＥＳ−ＣＣＭパラメータを含むフィールドも示している。
【００７０】
システムの色々な側面ではハードウェア実装およびソフトウェア実装間には余り区別がなく、ハードウェアまたはソフトウェアのいずれを利用するかは、概して費用対効果の間のトレードオフであるデザイン選択の範疇である（しかし、常にではなく、ハードウェアかソフトウェアかの選択が重要なコンテキストもある）。ここに記載した処理および／またはシステムおよび／またはその他の技術を実現しうる様々な手段が存在しており（例えば、ハードウェア、ソフトウェア、および／またはファームウェア）、好適な手段は、処理および／またはシステムおよび／またはその他の技術を配置するコンテキストに応じて変化しうる。例えば、実装者が速度と精度を最優先させる場合には、ハードウェアおよび／またはファームウェアという手段を主に採用するであろうし、柔軟性を最優先させたい場合には、実装者は主にソフトウェア実装を採用するであろうし、または、実装者はハードウェア、ソフトウェア、および／またはファームウェアの組み合わせを採用することもあろう。
【００７１】
上述では、デバイスおよび／またはプロセスの様々な実施形態を、ブロック図、フローチャート、および／または例示を利用して記載してきた。ブロック図、フローチャート、および／または例示が１以上の機能および／または動作を含む限り、当業者であれば、このブロック図、フローチャート、および／または例示内の各機能および／または動作が、個々に、または集合的に、幅広い範囲のハードウェア、ソフトウェア、ファームウェア、または実質的にこれらの任意の組み合わせにより実装可能であることを理解する。一実装例では、ここで記載した主題の複数の部分を、特定用途向けＩＣ（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、または他の集積フォーマットにより実装することが可能である。しかし、当業者であれば、ここに記載した実施形態の複数の側面が、全体的にまたは部分的に、集積回路内で、１以上のコンピュータで実行される１以上のコンピュータプログラムとして（例えば、１以上のコンピュータシステムで実行される１以上のプログラムとして）、１以上のプロセッサで実行される１以上のプログラムとして（例えば、１以上のマイクロプロセッサで実行される１以上のプログラムとして）、ファームウェアとして、または実質的にこれらの任意の組み合わせにより、同等的に実装可能であることを理解するであろうし、また、回路設計および／またはソフトウェアおよび／またはファームウェアのコード記述が、この開示に鑑みて当業者の技術的裁量の範囲にあることを理解しよう。加えて、当業者であれば、ここで記載した主題のメカニズムが、様々な形態のプログラムプロダクトによる配信が可能であること、および、ここで記載した主題に関する例示実施形態が、実際に配信を行う信号伝送媒体の特定の種類に関わらず適用可能であることを理解しよう。信号伝送媒体の例には、フロッピー（登録商標）ディスク、ハードディスクドライブ、コンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、デジタルテープ、コンピュータメモリ等の記録型媒体、および、デジタルおよび／またはアナログ通信媒体（例えば、繊維ファイバーケーブル、導波路、有線通信リンク、無線通信リンク）等の送信型媒体が含まれるが、これらに限定されない。
【００７２】
当業者であれば、デバイスおよび／またはプロセスを、ここで示した方法で記載して、記載されたデバイスおよび／またはプロセスを、後に技術的慣例を用いて、データ処理システムへと統合することが通例であることを理解する。つまり、ここで記載されたデバイスおよび／またはプロセスの少なくとも一部は、合理的な量の実験によりデータ処理システムへと統合することができる。当業者であれば、通常のデータ処理システムは、システムユニット筐体、ビデオ表示デバイス、揮発性および不揮発性メモリ等のメモリ、マイクロプロセッサおよびデジタル信号プロセッサ等のプロセッサ、オペレーティングシステム、ドライバ、グラフィックユーザインタフェース、およびアプリケーションプログラム等のコンピュータ実体、タッチパッドおよび／またはスクリーン等の１以上の対話デバイス、および／または、フィードバックループおよび制御モータを含む制御システム（感知位置および／または速度のフィードバック、コンポーネントおよび／または量の移動および／または調節を司る）のうち１以上を含むことを理解する。典型的なデータ処理システムは、データコンピューティング／通信および／またはネットワークコンピューティング／通信システムに通常見られるような、任意の適切な市販のコンポーネントを利用して実装可能である。
【００７３】
ここで記載された主題は、他のコンポーネントを含む場合があり、または、他のコンポーネントと接続される場合がある。このような示されたアーキテクチャは、あくまで例示であり、実際には、多くの他のアーキテクチャを実装しても同じ機能を達成することができる。概念的には、同じ機能を行うコンポーネントの任意の配置を効果的に「関連付ける」ことで、所望の機能を行う。故に、任意の２つのコンポーネントを組み合わせて特定の機能を行うことも、アーキテクチャまたは中間コンポーネントに関わらず、互いに「関連付け」を行って、所望の機能を達成している、とみなされる。同様に、このように関連付けられた任意の２つのコンポーネントは、所望の機能を達成するべく互いに「機能的に接続された」、または「機能的に連結された」、とみなすことができ、このように関連付けられた任意の２つのコンポーネントを、所望の機能を達成するべく互いに「機能的に連結可能」であるとみなすことができる。機能的に連結可能な特定の例には、物理的に係合可能な、および／または、物理的に相互作用可能なコンポーネント、および／または、無線で相互作用可能な、および／または、無線で相互作用するコンポーネント、および／または、論理的に相互作用する、および／または、論理的に相互作用可能なコンポーネントが含まれるが、これらに限定されない。
【００７４】
ここで利用した複数および／または単数の用語の実質的全てについて、当業者であれば、コンテキストおよび／または用途に応じて適宜、複数から単数へ、および／または、単数から複数へ変更して考えてもよいことを理解するであろう。様々な単数／複数の順序は、明瞭化を期す目的で明示されている場合が多い。
【００７５】
当業者であれば、ここで利用した用語の大半が、特に添付請求項（例えば添付請求項の本体）で利用する用語の大半が、「オープン」形式の用語を意図していること（例えば、「含む（including）」が、「含むが、それに限定されない」という意味であり、「持つ（having）」が、「少なくとも持つ」という意味であり、「含む（includes）」が、「含むが、それに限定されない」という意味である、等）を理解するであろう。さらに当業者であれば、導入される請求項の記載に特定の数が意図されている場合には、この意図は請求項に明確に記載されるべきであり、このような記載がないことは、このような意図がないことを意味することを理解するであろう。例えば、理解の助けとして、以下の添付請求項は、「少なくとも１つの」、および「１以上の」といった言い回しを用いて請求項の記載を導入している。しかし、このような言い回しの利用があるからといって、不定冠詞「ａ」または「ａｎ」による請求項の記載の導入によって、このように導入される請求項の記載を含む特定の請求項を、そのような記載を１つだけ含む発明に限定しようとする意図はない、これは、同じ請求項が、「１以上の」または「少なくとも１つの」という導入の言い回しを含み、不定冠詞「ａ」または「ａｎ」を含む場合にも同様であり（例えば、「ａ」または「ａｎ」は、通常「少なくとも１つの」または「１以上の」を意味するとして解釈される）、同じことは、請求項の記載を導入するのに利用される定冠詞の利用についても当てはまる。加えて、特定の数の導入請求項の記載を明示したとしても、当業者であればこのような記載が通常は、少なくともその記載された数であること解釈されることを理解する（例えば、「２つの記載」という記載は、他の修飾語がなくても、通常は少なくとも２つの記載、または２以上の記載、の意味である）。さらには、「少なくともＡ、ＢおよびＣ等の１つ」といった言い回しに類似した慣用句は、概して当業者がこの慣用句について想到する意味で捉えられるべきである（例えば、「少なくともＡ、ＢおよびＣのうち１つを持つシステム」という言い回しは、Ａのみ、Ｂのみ、Ｃのみ、ＡおよびＢ，ＡおよびＣ、ＢおよびＣ、および／または、Ａ、Ｂ、およびＣ、等をそれぞれ持つシステム含むが、これらに限定されない）。さらには、「少なくともＡ、ＢおよびＣ等の１つ」といった言い回しに類似した慣用句は、概して当業者がこの慣用句について想到する意味で捉えられるべきである（例えば、「少なくともＡ、ＢおよびＣのうち１つを持つシステム」という言い回しは、Ａのみ、Ｂのみ、Ｃのみ、ＡおよびＢ，ＡおよびＣ、ＢおよびＣ、および／または、Ａ、Ｂ、およびＣ、等をそれぞれ持つシステム含むが、これらに限定されない）。さらに、当業者は、実質的に、２つ以上の代替的な用語を表す論理和的な用語および／または言い回しが、明細書であっても、請求項であっても、図面であっても、それら用語の１つ、いずれか、または両方を含む可能性が考慮されるべきである。例えば、「ＡまたはＢ」という言い回しは、「Ａ」または「Ｂ」または「ＡおよびＢ」という可能性を含むこととして理解されたい。
【００７６】
特許、特許出願、および非特許文献を含むがそれらに限られない全ての参照の全体を、ここに参照として組み込む。
【００７７】
ここに開示した実施形態の様々な側面、および他の側面および実施形態は、当業者には明らかである。ここに開示した実施形態の様々な側面は、例示を意図しており、限定を意図しておらず、真の範囲および精神は以下の請求項が示している。
【００７８】
本願が開示された数値範囲内の任意の範囲をサポートする幾らかの数値範囲による限定を開示している場合であっても、発明の実施形態が開示された数値範囲による実行が可能である理由から、明細書には正確な範囲の限定を一語一句違わずに示さない場合がある。最後に、本願でもし言及された特許および刊行物があればその開示全体を参照によりここに組み込むことにする。
【特許請求の範囲】
【請求項１】
第１のネットワーク層と、前記第１のネットワーク層とは異なる第２のネットワーク層とにおける通信セキュリティを、第１のプロセッサを持つ無線クライアントに提供する方法であって、
第１のネットワーク層に関連付けられた第１のコントローラから、前記第１のネットワーク層でのセキュリティ処理用にセキュリティアルゴリズムを取得する段階と、
第２のネットワーク層に関連付けられた第２のコントローラと、前記第２のネットワーク層でのセキュリティ処理への前記セキュリティアルゴリズムの利用についてネゴシエーションする段階と
を備え、
前記無線クライアントでの前記第１のネットワーク層および前記第２のネットワーク層における前記セキュリティ処理は、前記第１のプロセッサで行われる
方法。
【請求項２】
第１のコントローラからセキュリティアルゴリズムを取得する段階、および、第２のコントローラとネゴシエーションする段階のうち少なくとも一部を行う間、前記無線クライアントの少なくとも一部を低電力レベルで動作させる段階をさらに備える請求項１に記載の方法。
【請求項３】
前記第１のネットワーク層はリンク層であり、前記第２のネットワーク層はネットワーク層である請求項１に記載の方法。
【請求項４】
前記第２のネットワーク層は、ＴＬＳおよびＩＰｓｅｃからなる群から選択されるいずれか一つを含む請求項１に記載の方法。
【請求項５】
第１のコントローラからセキュリティアルゴリズムを取得する段階は、
前記無線クライアントが、第１層セキュリティ用に前記セキュリティアルゴリズムを、前記第１のコントローラに対して要求する段階と、
前記セキュリティアルゴリズムを、前記無線クライアント内のＴＬＳスタックへ送る段階と
を有する請求項１に記載の方法。
【請求項６】
前記第２のコントローラとネゴシエーションする段階は、
前記第２のコントローラに対して、前記第２のコントローラが前記無線クライアントと通信する際のネットワーク層セキュリティを提供する用途向けに、前記セキュリティアルゴリズムを提示する段階と、
前記第２のコントローラからセキュリティアルゴリズム証明を受信する段階と、
第１層セキュリティ処理および第２層セキュリティ処理の両方に前記セキュリティアルゴリズムを利用するよう前記無線クライアントを構成する段階と
を有する請求項１に記載の方法。
【請求項７】
前記セキュリティアルゴリズムは、ＡＥＳ−ＣＣＭおよびＡＥＳ−ＧＣＭからなる群から選択される請求項１に記載の方法。
【請求項８】
前記セキュリティアルゴリズムを前記ＴＬＳスタックへ送る段階は、さらに、前記セキュリティアルゴリズムをＴＬＳセッションの最優先セキュリティアルゴリズムとする段階を含む請求項５に記載の方法。
【請求項９】
前記セキュリティアルゴリズムを前記ＴＬＳスタックへ送る段階は、前記セキュリティアルゴリズムを前記ＴＬＳスタック内に構成する段階をさらに含む請求項５に記載の方法。
【請求項１０】
ネットワークスタックの第１のネットワーク層および第２のネットワーク層のパケットを、無線デバイスプロセッサを用いて処理する方法であって、前記第１のネットワーク層は前記第２のネットワーク層とは異なり、前記方法は、
第１のネットワーク層に関連付けられた第１のコントローラから、前記第１のネットワーク層でのセキュリティ処理用にセキュリティアルゴリズムを取得する段階と、
無線クライアントのセキュリティアソシエーションキャッシュへ、前記セキュリティアルゴリズムのセキュリティ情報を持つセキュリティアソシエーションをインストールする段階と、
第２のネットワーク層に関連付けられた第２のコントローラと、前記第２のネットワーク層でのセキュリティ処理への前記セキュリティアルゴリズムの利用についてネゴシエーションする段階と、
受信した無線パケットを、第１のネットワーク層で前記セキュリティアソシエーションを利用して、前記無線デバイスプロセッサにより処理して、第１のネットワーク処理されたパケットを生成する段階と、
前記第１のネットワーク処理されたパケットを、第２のネットワーク層で前記セキュリティアソシエーションを利用して、前記無線デバイスプロセッサにより処理して、第２のネットワーク処理されたパケットを生成する段階と、
前記第２のネットワーク処理されたパケットをネットワークアプリケーションに提供する段階と
を備える方法。
【請求項１１】
前記無線クライアントの少なくとも一部を、予め定められた処理ステップ中に低電力レベルで動作させる段階をさらに備える請求項１０に記載の方法。
【請求項１２】
前記第１のネットワーク層はリンク層であり、前記第２のネットワーク層はネットワーク層である請求項１０に記載の方法。
【請求項１３】
前記受信した無線パケットを前記第１のネットワーク層で処理する段階は、さらに、
前記受信した無線パケットを第１のネットワーク層フレームプロセッサにより処理して、フレーム処理されたパケットを生成する段階と、
前記フレーム処理されたパケットを、前記第１のネットワーク層のセキュリティアソシエーションを利用して第１のネットワーク層復号フレームを生成するｃｏｍｍｓセキュリティ処理エンジンへ送る段階と、
前記第１のネットワーク層復号フレームを第１のネットワーク層フレームプロセッサへ提供して、フレーム処理されたフレームを生成する段階と、
前記フレーム処理されたフレームをディープパケット検査エンジンへ提供し、上位プロトコルヘッダまたは上位レベルパケットの識別子を捜す段階と
を有する請求項１０に記載の方法。
【請求項１４】
前記第１のネットワーク処理されたパケットを第２のネットワーク層で処理する段階は、さらに、
前記第１のネットワーク処理されたパケットを第２のネットワーク層セキュリティエンジンへ提供し、第２のネットワーク層済みパケットを生成する段階と、
ＴＬＳネットワーク層処理済みのパケットを、前記第２のネットワーク層のセキュリティアソシエーションを利用して第２層復号フレームを生成するｃｏｍｍｓセキュリティ処理エンジンへ提供する段階と、
前記第２層復号フレームを第１のネットワーク層無線ドライバへ提供する段階と
を有する請求項１０に記載の方法。
【請求項１５】
ネットワーク通信プロトコルのセキュリティプロトコルを利用して、第１の層および第２の層のセキュリティを提供する方法であって、
無線クライアントが、第１層セキュリティ用にセキュリティアルゴリズムを、ネットワークアクセスポイントに対して要求する段階と、
前記ネットワークアクセスポイントから、割り当てられた第１層セキュリティアルゴリズムを受信する段階と、
前記割り当てられた第１層セキュリティアルゴリズムをスタックに格納する段階と、
前記割り当てられた第１層セキュリティアルゴリズムを利用するべく第２層セキュリティアルゴリズムを構成する段階と
を備える方法。
【請求項１６】
前記ネットワーク通信プロトコルは、ＴＬＳおよびＩＰｓｅｃからなる群から選択されるいずれか一つを含む請求項１５に記載の方法。
【請求項１７】
前記セキュリティアルゴリズムは、ＡＥＳ−ＣＣＭおよびＡＥＳ−ＧＣＭからなる群から選択される１タイプである請求項１５に記載の方法。
【請求項１８】
前記セキュリティアルゴリズムは非対称認証アルゴリズムと組み合わせられる請求項１７に記載の方法。
【請求項１９】
第２層通信を構成する前記段階は、さらに、
ＴＬＳ−Ｃｌｉｅｎｔ−Ｈｅｌｌｏメッセージを、前記第２層セキュリティアルゴリズムを最優先セキュリティオプションとして利用して送信する段階と、
ＴＬＳサーバから、前記ＴＬＳサーバが前記第２層セキュリティアルゴリズムを後続のＴＬＳセキュリティセッションで利用することを受諾した旨を示すＴＬＳ−Ｓｅｒｖｅｒ−Ｈｅｌｌｏメッセージを受信する段階と、
証明書メッセージとＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅメッセージとを利用して、前記ＴＬＳサーバからセキュリティ証明書を受信する段階と、
証明書メッセージとＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅメッセージとを利用して、前記無線クライアントのセキュリティ証明書を前記ＴＬＳサーバへ送信する段階と、
前記第１層セキュリティアルゴリズムで利用するＴＬＳセッションキーを計算する段階と、
前記第１層セキュリティアルゴリズムを利用するよう前記無線クライアントおよび前記ＴＬＳサーバを適合させる段階と
を有する請求項１５に記載の方法。
【請求項２０】
第１のネットワーク層と、前記第１のネットワーク層とは異なる第２のネットワーク層とにおける通信セキュリティを提供する無線クライアントであって、
第１のネットワーク層に関連付けられた第１のコントローラから、前記第１のネットワーク層でのセキュリティ処理用にセキュリティアルゴリズムを取得する第１のインタフェースと、
第２のネットワーク層に関連付けられた第２のコントローラと、前記第２のネットワーク層でのセキュリティ処理への前記セキュリティアルゴリズムの利用についてネゴシエーションする第２のインタフェースと、
前記無線クライアントで、前記第１のネットワーク層および前記第２のネットワーク層におけるセキュリティ処理を行うプロセッサと
を備える無線クライアント。
【請求項２１】
前記セキュリティ処理の少なくとも一部を行う間、前記無線クライアントの少なくとも一部は低電力レベルで動作する請求項２０に記載の無線クライアント。
【請求項１】
第１のネットワーク層と、前記第１のネットワーク層とは異なる第２のネットワーク層とにおける通信セキュリティを、第１のプロセッサを持つ無線クライアントに提供する方法であって、
第１のネットワーク層に関連付けられた第１のコントローラから、前記第１のネットワーク層でのセキュリティ処理用にセキュリティアルゴリズムを取得する段階と、
第２のネットワーク層に関連付けられた第２のコントローラと、前記第２のネットワーク層でのセキュリティ処理への前記セキュリティアルゴリズムの利用についてネゴシエーションする段階と
を備え、
前記無線クライアントでの前記第１のネットワーク層および前記第２のネットワーク層における前記セキュリティ処理は、前記第１のプロセッサで行われる
方法。
【請求項２】
第１のコントローラからセキュリティアルゴリズムを取得する段階、および、第２のコントローラとネゴシエーションする段階のうち少なくとも一部を行う間、前記無線クライアントの少なくとも一部を低電力レベルで動作させる段階をさらに備える請求項１に記載の方法。
【請求項３】
前記第１のネットワーク層はリンク層であり、前記第２のネットワーク層はネットワーク層である請求項１に記載の方法。
【請求項４】
前記第２のネットワーク層は、ＴＬＳおよびＩＰｓｅｃからなる群から選択されるいずれか一つを含む請求項１に記載の方法。
【請求項５】
第１のコントローラからセキュリティアルゴリズムを取得する段階は、
前記無線クライアントが、第１層セキュリティ用に前記セキュリティアルゴリズムを、前記第１のコントローラに対して要求する段階と、
前記セキュリティアルゴリズムを、前記無線クライアント内のＴＬＳスタックへ送る段階と
を有する請求項１に記載の方法。
【請求項６】
前記第２のコントローラとネゴシエーションする段階は、
前記第２のコントローラに対して、前記第２のコントローラが前記無線クライアントと通信する際のネットワーク層セキュリティを提供する用途向けに、前記セキュリティアルゴリズムを提示する段階と、
前記第２のコントローラからセキュリティアルゴリズム証明を受信する段階と、
第１層セキュリティ処理および第２層セキュリティ処理の両方に前記セキュリティアルゴリズムを利用するよう前記無線クライアントを構成する段階と
を有する請求項１に記載の方法。
【請求項７】
前記セキュリティアルゴリズムは、ＡＥＳ−ＣＣＭおよびＡＥＳ−ＧＣＭからなる群から選択される請求項１に記載の方法。
【請求項８】
前記セキュリティアルゴリズムを前記ＴＬＳスタックへ送る段階は、さらに、前記セキュリティアルゴリズムをＴＬＳセッションの最優先セキュリティアルゴリズムとする段階を含む請求項５に記載の方法。
【請求項９】
前記セキュリティアルゴリズムを前記ＴＬＳスタックへ送る段階は、前記セキュリティアルゴリズムを前記ＴＬＳスタック内に構成する段階をさらに含む請求項５に記載の方法。
【請求項１０】
ネットワークスタックの第１のネットワーク層および第２のネットワーク層のパケットを、無線デバイスプロセッサを用いて処理する方法であって、前記第１のネットワーク層は前記第２のネットワーク層とは異なり、前記方法は、
第１のネットワーク層に関連付けられた第１のコントローラから、前記第１のネットワーク層でのセキュリティ処理用にセキュリティアルゴリズムを取得する段階と、
無線クライアントのセキュリティアソシエーションキャッシュへ、前記セキュリティアルゴリズムのセキュリティ情報を持つセキュリティアソシエーションをインストールする段階と、
第２のネットワーク層に関連付けられた第２のコントローラと、前記第２のネットワーク層でのセキュリティ処理への前記セキュリティアルゴリズムの利用についてネゴシエーションする段階と、
受信した無線パケットを、第１のネットワーク層で前記セキュリティアソシエーションを利用して、前記無線デバイスプロセッサにより処理して、第１のネットワーク処理されたパケットを生成する段階と、
前記第１のネットワーク処理されたパケットを、第２のネットワーク層で前記セキュリティアソシエーションを利用して、前記無線デバイスプロセッサにより処理して、第２のネットワーク処理されたパケットを生成する段階と、
前記第２のネットワーク処理されたパケットをネットワークアプリケーションに提供する段階と
を備える方法。
【請求項１１】
前記無線クライアントの少なくとも一部を、予め定められた処理ステップ中に低電力レベルで動作させる段階をさらに備える請求項１０に記載の方法。
【請求項１２】
前記第１のネットワーク層はリンク層であり、前記第２のネットワーク層はネットワーク層である請求項１０に記載の方法。
【請求項１３】
前記受信した無線パケットを前記第１のネットワーク層で処理する段階は、さらに、
前記受信した無線パケットを第１のネットワーク層フレームプロセッサにより処理して、フレーム処理されたパケットを生成する段階と、
前記フレーム処理されたパケットを、前記第１のネットワーク層のセキュリティアソシエーションを利用して第１のネットワーク層復号フレームを生成するｃｏｍｍｓセキュリティ処理エンジンへ送る段階と、
前記第１のネットワーク層復号フレームを第１のネットワーク層フレームプロセッサへ提供して、フレーム処理されたフレームを生成する段階と、
前記フレーム処理されたフレームをディープパケット検査エンジンへ提供し、上位プロトコルヘッダまたは上位レベルパケットの識別子を捜す段階と
を有する請求項１０に記載の方法。
【請求項１４】
前記第１のネットワーク処理されたパケットを第２のネットワーク層で処理する段階は、さらに、
前記第１のネットワーク処理されたパケットを第２のネットワーク層セキュリティエンジンへ提供し、第２のネットワーク層済みパケットを生成する段階と、
ＴＬＳネットワーク層処理済みのパケットを、前記第２のネットワーク層のセキュリティアソシエーションを利用して第２層復号フレームを生成するｃｏｍｍｓセキュリティ処理エンジンへ提供する段階と、
前記第２層復号フレームを第１のネットワーク層無線ドライバへ提供する段階と
を有する請求項１０に記載の方法。
【請求項１５】
ネットワーク通信プロトコルのセキュリティプロトコルを利用して、第１の層および第２の層のセキュリティを提供する方法であって、
無線クライアントが、第１層セキュリティ用にセキュリティアルゴリズムを、ネットワークアクセスポイントに対して要求する段階と、
前記ネットワークアクセスポイントから、割り当てられた第１層セキュリティアルゴリズムを受信する段階と、
前記割り当てられた第１層セキュリティアルゴリズムをスタックに格納する段階と、
前記割り当てられた第１層セキュリティアルゴリズムを利用するべく第２層セキュリティアルゴリズムを構成する段階と
を備える方法。
【請求項１６】
前記ネットワーク通信プロトコルは、ＴＬＳおよびＩＰｓｅｃからなる群から選択されるいずれか一つを含む請求項１５に記載の方法。
【請求項１７】
前記セキュリティアルゴリズムは、ＡＥＳ−ＣＣＭおよびＡＥＳ−ＧＣＭからなる群から選択される１タイプである請求項１５に記載の方法。
【請求項１８】
前記セキュリティアルゴリズムは非対称認証アルゴリズムと組み合わせられる請求項１７に記載の方法。
【請求項１９】
第２層通信を構成する前記段階は、さらに、
ＴＬＳ−Ｃｌｉｅｎｔ−Ｈｅｌｌｏメッセージを、前記第２層セキュリティアルゴリズムを最優先セキュリティオプションとして利用して送信する段階と、
ＴＬＳサーバから、前記ＴＬＳサーバが前記第２層セキュリティアルゴリズムを後続のＴＬＳセキュリティセッションで利用することを受諾した旨を示すＴＬＳ−Ｓｅｒｖｅｒ−Ｈｅｌｌｏメッセージを受信する段階と、
証明書メッセージとＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅメッセージとを利用して、前記ＴＬＳサーバからセキュリティ証明書を受信する段階と、
証明書メッセージとＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅメッセージとを利用して、前記無線クライアントのセキュリティ証明書を前記ＴＬＳサーバへ送信する段階と、
前記第１層セキュリティアルゴリズムで利用するＴＬＳセッションキーを計算する段階と、
前記第１層セキュリティアルゴリズムを利用するよう前記無線クライアントおよび前記ＴＬＳサーバを適合させる段階と
を有する請求項１５に記載の方法。
【請求項２０】
第１のネットワーク層と、前記第１のネットワーク層とは異なる第２のネットワーク層とにおける通信セキュリティを提供する無線クライアントであって、
第１のネットワーク層に関連付けられた第１のコントローラから、前記第１のネットワーク層でのセキュリティ処理用にセキュリティアルゴリズムを取得する第１のインタフェースと、
第２のネットワーク層に関連付けられた第２のコントローラと、前記第２のネットワーク層でのセキュリティ処理への前記セキュリティアルゴリズムの利用についてネゴシエーションする第２のインタフェースと、
前記無線クライアントで、前記第１のネットワーク層および前記第２のネットワーク層におけるセキュリティ処理を行うプロセッサと
を備える無線クライアント。
【請求項２１】
前記セキュリティ処理の少なくとも一部を行う間、前記無線クライアントの少なくとも一部は低電力レベルで動作する請求項２０に記載の無線クライアント。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１０−１５８００６（Ｐ２０１０−１５８００６Ａ）
【公開日】平成２２年７月１５日（２０１０．７．１５）
【国際特許分類】
【外国語出願】
【出願番号】特願２００９−２８６９９３（Ｐ２００９−２８６９９３）
【出願日】平成２１年１２月１７日（２００９．１２．１７）
【出願人】（５９１００３９４３）インテル・コーポレーション (1,101)
【Ｆターム（参考）】
【公開日】平成２２年７月１５日（２０１０．７．１５）
【国際特許分類】
【出願番号】特願２００９−２８６９９３（Ｐ２００９−２８６９９３）
【出願日】平成２１年１２月１７日（２００９．１２．１７）
【出願人】（５９１００３９４３）インテル・コーポレーション (1,101)
【Ｆターム（参考）】
[ Back to top ]