JP2010503326A - インフラストラクチャベースの無線マルチホップネットワークにおけるセキュリティ認証及び鍵管理 - Google Patents

Abstract

無線マルチホップネットワークにおけるセキュリティ認証及び鍵管理スキームのシステム、並びに方法をホップバイホップセキュリティモデルと共に提供する。本スキームは、メッシュＡＰネットワークに導入された８０２．１１ｒの鍵階層構造を採用する。この方法において、トップの鍵所有者（Ｒ０ＫＨ）は、認証プロセスの後、各サプリカントの無線デバイスに対してトップペアマスタ鍵（ＰＭＫ＿０）を生成及び保持する。全てのオーセンティケータＡＰは、レベル１の鍵所有者（Ｒ１ＫＨ）の役割を受け持ち、Ｒ０ＫＨから次のレベルのペアマスタ鍵（ＰＭＫ＿１）を受け取る。リンクレベルデータ保護鍵は、８０２．１１ｉの４段階ハンドシェークを通じてＰＭＫ＿１から生成される。

Description

本発明は主に無線通信に関し、特にインフラストラクチャベースの無線マルチホップネットワークにおけるセキュリティ認証及び鍵管理に関する。

通常、インフラストラクチャベースの無線ネットワークは、固定の有線ゲートウェイを有する通信ネットワークを含む。多くのインフラストラクチャベースの無線ネットワークは、有線ネットワークに接続された固定基地局と通信する移動体端末又はホストを採用している。移動体端末は、無線リンクを通して基地局と通信しながら移動することができる。移動体端末が特定の基地局の通信範囲から離れたとき、その移動体端末は新しい基地局へ接続、即ち「ハンドオーバー」され、その新しい基地局を通じて有線ネットワークと通信を開始する。

セルラーネットワークや衛星ネットワークなどのインフラストラクチャベースの無線ネットワークに比べ、アドホックネットワークは自己形成機能を有するネットワークであり、固定インフラストラクチャがなくとも運用が可能である。場合によっては、アドホックネットワークは、完全に移動ノードのみで構成されることもある。通常、アドホックネットワークは、地理的に分布し、かつ１つ以上のリンク（例えば、無線周波数通信チャンネル）によって互いに無線接続される複数の移動体端末（「ノード」とも言う）を含む。ノードは、インフラストラクチャベースのネットワーク又は有線ネットワークの補助が無くとも、無線媒体を通して互いに通信できる。

無線通信ネットワークがより広く普及されるにつれ、セキュリティは、プロバイダ及びエンドユーザの両者にとって主な関心事となっている。これは、データが多数のノードによって受信及び操作可能な状態に置かれているため、セキュリティ環境下の移動体無線ネットワークの使用が大きな問題に直面していることからしても明らかである。無線ネットワークにて用いられる無線リンクは、送信される信号及びネットワーク上を流れるデータを盗聴者及び／又は自称ハッカーにさらされている。故に、無線マルチホップネットワークにおいて、メッシュ装置の各リンクは、マルチホップ認証及び鍵管理プロセスを介して確立される固有のセキュリティ接続を有する必要がある。そして、確立されたセキュリティ接続によって、リンク上のエアーフレームが保護される。

本発明のいくらかの実施形態による例示的なインフラストラクチャベースの無線マルチホップネットワークを示す図。 本発明のいくらかの実施形態による例示的なメッセージフォーマットを示す図。 本発明のいくらかの実施形態による鍵配布及び役割認可プロセスを示すフローチャート。 本発明のいくらかの実施形態による認証手続きを示す図。 本発明のいくらかの実施形態による図１におけるネットワークの各要素の間で交換される認証メッセージを示すメッセージフローチャート。 本発明のいくらかの実施形態による、図５におけるメッセージ交換をより詳細に示す図。

添付の図面は、同一、又は機能的に類似する要素に対しては同一の符号を付しており、下記の詳細な説明と共に本明細書の一部を構成しながら、さらには本発明に従う様々な実施形態を示し、かつ本発明に従う原理及び利点に対する説明を提供する。

図面の要素は簡略かつ明瞭に図示されており、必ずしも正確な縮図を必要としないことを、当業者は認識するであろう。たとえば、図面における一部の要素は、本発明の実施形態に対する理解を向上させるため、他の要素より拡大されている場合がある。

本発明による詳細な実施形態を説明するに先立って、本実施形態は、主としてセキュリティ認証及び鍵管理に関する方法のステップ及び装置要素の組み合わせに属することが認識されるであろう。従って、本発明によって利益を得る分野の当業者にとって容易に明らかとなる開示を不明瞭としないように、該ステップ及び装置要素を、図面において従来の記号を用いて適切に示し、本発明の実施形態を理解するに適切な具体的な詳細のみを表す。

本書において、第１及び第２、並びに上下などの関係語は、任意の物体又は行為を他の物体又は行為と区別するためにのみ用いられるもので、実際に両者間におけるそのような関係及び順序の成立を要求、或いは暗示する訳ではない。「備える」若しくはそれに類似する任意の表現は、非排他的な包括、即ち、ある要素の一群を備えるプロセス、方法、品目、又は装置が、該要素のみならず、また明示的に記載されていない他の要素を含む要素の一群も含むものである。また、「〜を備える」の表現によって先行する要素は、別途の制限なしでも、要素を構成するプロセス、方法、品目、又は装置における付加的な同一要素の存在を排除しない。

ここで説明される本発明の実施形態は、非プロセッサ回路と併せて、１つ以上の既存のプロセッサと、１つ以上のプロセッサが本発明のセキュリティ認証及び鍵管理機能の一部又は全部を実行できるように制御する固有のプログラム命令とから構成されてもよい。非プロセッサ回路は、無線受信機、無線送信機、信号ドライバ、クロック回路、電源回路、ユーザ入力装置を備えてもよいが、それに限られる訳ではない。これらの機能は、セキュリティ認証及び鍵管理の実行方法のステップとして解釈されてもよい。若しくは、そのような機能の一部又は全部は、プログラム命令を全く記憶していない機械状態により実行されてもよいし、あるいは１つ以上の特定用途向けの集積回路（ＡＳＩＣ）において、各々の機能又は特定機能の組み合わせがカスタム論理として実行されてもよい。勿論、前記２つの方法の組み合わせを採用してもよい。よって、これらの機能を実行するための方法及び手段をここで説明する。さらに当業者は、例えば利用可能な時間、現在の技術、及び費用上の都合により多大な努力や設計上の変更などを要するとしても、ここで示されたコンセプト及び原理に従えば、最小限の実験のみでそのようなソフトウェア命令、プログラム、及び集積回路を容易に生産可能となるであろう。

本発明は、ホップバイホップセキュリティモデルを有するインフラストラクチャベースの無線マルチホップネットワーク用のセキュリティ認証及び鍵管理スキームを提供する。本発明の基本構成用途は、ＩＥＥＥ ８０２．１１ｉ及びＩＥＥＥ ８０２．１ｘである。高速ハンドオフ用として、８０２．１１ｒの特徴を含む。

ＩＥＥＥ ８０２．１ｘは、管理オーバーヘッドを最少にしながら、ほとんど無制限のスケーラビリティを提供する新規技術である。この技術によれば、ユーザ又はオペレーターごとに異なる認証方法を選ばせることも可能になる。本発明において、トンネルトランスポート層セキュリティ（ＴＴＬＳ）は、相対的にセキュリティが強固であり、かつ設置費用がより安価であるため、ユーザ及びデバイス認証用として用いられる。デバイスについては、トランスポート層セキュリティ（ＴＬＳ）認証を選択することもできる。

集中型認証及び８０２．１１ｒのサポートについては、８０２．１１ｒの鍵階層構造に関するトップレベルの鍵所有者（Ｒ０ＫＨ）は、有線ネットワークに位置するように設計されている。トップレベル（レベル０）の鍵所有者とレベル２の鍵所有者（Ｒ１ＫＨ）との間のメッセージ送信は、レイヤー２又はインターネットプロトコル（ＩＰ）レイヤーのいずれかにおいて生じる。

本発明において、８０２．１１ｒに基づく鍵階層構造は、レベル１の鍵所有者の役割を担うメッシュアクセスポイント内から選ばれる。よって、複数の鍵所有者の間におけるセキュリティ管理メッセージフローが提供される。鍵管理は、両８０２．１１ｉ及び８０２．１１ｒと互換性のある無線局をサポートし、また、多数の可能なサービスセットＩＤ（ＳＳＩＤ）が配置された仮想アクセスポイントもサポートする。レベル０とレベル１の鍵所有者との間のセキュリティメッセージフローは、レイヤー２またはレイヤー３を通じて送信されるが、これはレベル０の鍵所有者の位置に依存する。全てのレベル０鍵所有者が、レベル１の鍵所有者と共にレイヤー２の同セグメントに位置する場合、レイヤー２の通信が用いられ、さもなければレイヤー３の通信が用いられるべきである。鍵配布鍵（ＫＤＫ）は、初期認証プロセスにて生成され、トップレベル鍵所有者から次のレベルの鍵所有者へ送信される鍵素材をセキュアなものとするために使用される。レベル１の鍵所有者Ｒ１ＫＨの役割は、認証サーバからの認可情報に基づいて、トップレベルの鍵所有者により認可される。

無線マルチホップネットワークにおけるセキュリティ認証及び鍵管理スキームに関するシステム及び方法が、ここにおいてホップバイホップセキュリティモデルと共に提供される。本スキームは、メッシュアクセスポイント（ＡＰ）ネットワークに導入された８０２．１１ｒの鍵階層構造を採用する。この方法では、トップレベルの鍵所有者（Ｒ０ＫＨ）は、認証プロセスの後、各サプリカントの無線デバイスに対するトップペアマスタ鍵（ＰＭＫ＿０）を生成及び保持する。全オーセンティケータアクセスポイント（ＡＰ）は、レベル１の鍵所有者（Ｒ１ＫＨ）としての役割を担い、かつトップレベルの鍵所有者Ｒ０ＫＨから次のレベルのペアマスタ鍵（ＰＭＫ＿１）を受け取る。リンクレベルデータの保護鍵は、８０２．１１ｉの４段階ハンドシェークなどの４段階ハンドシェークを通じて、ＰＭＫ＿１から生成される。

図１は、本発明のいくらかの実施形態による例示的なインフラストラクチャベースの無線マルチホップネットワーク１００を示す。図１のネットワーク１００において、鍵所有者間においてレベル２の通信チャンネルが用いられ、トップレベルの鍵所有者Ｒ０ＫＨは、中央イーサネット（登録商標）スイッチに取り付けられている。よって、トップレベルの鍵所有者Ｒ０ＫＨは、制御された全てのインテリジェントアクセスポイント（ＩＡＰ）とメッシュアクセスポイント（ＭＡＰ）デバイスと同じレベル２セグメントに位置する。また、遠隔アクセスダイアルアップユーザーサービス（ＲＡＤＩＵＳ）のクライアントと８０２．１Ｘの認証コードも、本発明の実施形態によるネットワーク１００において実行される。

ＩＰレイヤー通信チャンネルをトップレベルの鍵所有者Ｒ０ＫＨ及びレベル１の鍵所有者Ｒ１ＫＨに対して用いた場合、Ｒ０ＫＨは任意の位置に存在してもよいことを、当業者は認識するであろう。例示的な実施形態によると、Ｒ０ＫＨは、ネットワーク管理システムと同じホスト内に位置する。同一のＲ０ＫＨに接続されるすべてのＲ１ＫＨデバイスは、全ビーコンフレーム内に存在するモビリティドメイン識別子（ＭＤＩ）を介して識別される。

図に示すように、ネットワーク１００は、１つ以上のメッシュアクセスポイント１３５−ｎ（ＭＡＰ）を含む。１つ以上のメッシュアクセスポイント１３５−ｎ（ＭＡＰ）は、１つ以上のインテリジェントアクセスポイント１３０−ｎ（ＩＡＰ）から１つ以上の無線加入者デバイス１４０−ｎ（ＳＤ、局（ＳＴＡ）とも言う）へデータパケットをルーティングするために使用される。そして、１つ以上のＩＡＰ１３０−ｎは、中央ルーター１１５とトップレベルの鍵所有者（Ｒ０ＫＨ）１２０とに通信可能に接続された中央イーサネット（登録商標）スイッチ１２５へパケットをルーティングする。中央ルーター１１５は、有線基幹回線１１０を介して認証サーバ１０５へ接続されている。図面では加入者デバイス（ＳＤ）から有線ネットワーク１２５へのパスのみを示しているが、加入者デバイス１４０−１及び加入者デバイス１４０−２のような２つの隣接するデバイス間の相互通信が可能である限り、網目状の接続が構築可能であることは当業者に認識されるであろう。

認証サーバ１０５は、Ｒ０ＫＨ１２０に認証サービスを提供する。それに関して下記のように説明する。通常、認証サーバ１０５は、オーセンティケータの代わりにサプリカントの証明書を確認するために必要な認証機能を実行し、オーセンティケータのサービスへアクセスする権限がサプリカントにあるか否かを示す。本発明の一実施形態において、認証サーバ１０５は、ホストの物理的セキュリティを提供する有線ネットワークセクション内に位置している。例えば、認証サーバ１０５は、拡張認証プロトコル−ＴＴＬＳ／拡張認証プロトコル−ＴＬＳ（ＥＡＰ−ＴＴＬＳ／ＥＡＰ−ＴＬＳ）が利用可能な集中型認証用のＲＡＤＩＵＳサーバであってもよい。

当業者にとって認識されるように、ネットワーク１００における加入者デバイス１４０−ｎは、暗号化データの送受信を要求されてもよい。オーセンティケータのシステムが提供するサービスへのアクセスを要求する／望むネットワーク１００におけるデバイスはサプリカントと見なされる。一方、オーセンティケータが保護するサービスへのアクセスを必要とする／望むデバイス（サプリカント）を認証するデバイスは、オーセンティケータと見なされる。オーセンティケータは、認証結果に基づき、アクセスを強制的に制御する。

当業者にとって認識されるように、ネットワーク１００における各ノード（即ち、ＩＡＰ１３０−ｎ、ＭＡＰ１３５−ｎ、ＳＤ１４０−ｎ）は、メッシュネットワークに接続する前に、ネットワーク１００に認証される。認証における証明書は、例えば、パスワード、加入者識別モジュール（ＳＩＭ）カードＩＤ、又は他のＩＤに基づくものであり、特定のノードに対する固有の情報として認証サーバ１０５に保存されている。各ノードは、Ｒ０ＫＨ１２０とセキュアな接続を確立しているワンホップメッシュＭＡＰ又はＩＡＰに対する認証にために、認証サーバ１０５とのこのような関係を使用する。Ｒ０ＫＨ１２０は、認証サーバ１０５により提供される認証サービスを用いる。また、認証サーバ１０５は、Ｒ０ＫＨ１２０へ暗号化されたセッションマスタ鍵素材を配布することにより、隣接ノードと信頼関係を確立すべく認証を行っている特定のノードを補助する。Ｒ０ＫＨ１２０は、レベル０及びレベル１のペアマスタ鍵（ＰＭＫ＿０、ＰＭＫ＿１）を生成する。さらに、Ｒ０ＫＨ１２０は、ＰＭＫ＿０を保持し、ＰＭＫ＿１は、レベル１の鍵所有者の役割を担うオーセンティケータのＭＡＰまたはＩＡＰへ送信する。

本発明の一実施形態において、ネットワーク１００は、ＩＥＥＥ ８０２．１１ｒの操作性を包含する。８０２．１１ｒは、高速基本サービスセット（ＢＳＳ）遷移を提供する。よって、８０２．１１ｒはある基地局から他の基地局への高速ハンドオフを切れ目無く実行し、移動中の車両に対する接続性を促進する。８０２．１１ｒ規格に対して現在想定されている優先的用途は、標準セルラーネットワークの代わりに、或いはセルラーネットワークに加えて、無線インターネットネットワークと通信可能な携帯電話によるＶＯＩＰ（ボイスオーバーＩＰ、又はインターネット電話）である。

８０２．１１ｒは、アクセスポイントの間を移動する移動体クライアントの転換プロセスを改善する。該プロトコルは、遷移に先立って無線クライアントが新しいアクセスポイントにてセキュリティ及びサービスの質（ＱｏＳ）の状態を確保できるようにし、接続性の損失及び使用障害を最小限に抑える。たとえ該プロトコルに完全に替えるとしても、セキュリティ面における脆弱性は生じない。これによって、現在の基地局及びアクセスポイントの機能を保持する。８０２．１１ｒは、候補となるアクセスポイントと通信し、セキュリティ接続を確立して、かつＱｏＳリソースを保存するように、移動体クライアントをローミングするための機構を提供する。

本発明によると、図１のネットワーク１００において、８０２．１１ｒに基づく鍵階層構造はメッシュＡＰに適用され、これにより１つ以上の移動体ＡＰに対する高速ハンドオフを可能とする。この鍵階層構造にて、トップレベル鍵のＰＭＫ＿０は、認証サーバ１０５から受け取ったマスタ鍵素材からＲ０ＫＨ１２０において生成される。次のレベルで、ＰＭＫ＿１は、ＰＭＫ＿０からＲ０ＫＨ１２０において生成され、Ｒ１ＫＨに送信される。ペア一時鍵（ＰＴＫ）は、８０２．１１ｉの４段階ハンドシェークを通じて、サプリカントとオーセンティケータとの間でＰＭＫ＿１から生成される。本発明のいくらかの実施形態によると、トップレベルの鍵所有者Ｒ０ＫＨ１２０は有線ネットワークセクションに位置しながら、また中央イーサネット（登録商標）スイッチ１２５に取り付けられている。他の全てのメッシュアクセスポイント（ＭＡＰ）１３５−ｎ及びＩＡＰ１３０−ｎは、レベル１の鍵所有者としての役割を担うことになる。

本発明のいくらかの配備において、Ｒ０ＫＨ１２０は各ＩＡＰ１３０−ｎに含まれていてもよく、従ってＩＡＰ１３０−ｎと関連付けられた全てのＭＡＰ１３５−ｎは、そのＲ０ＫＨ１２０下でＲ１ＫＨとなる（図示しない）。ＩＰレイヤー通信チャンネルがＲ０ＫＨ及びＲ１ＫＨに対して用いられる場合、Ｒ０ＫＨ及びＲ１ＫＨは、レイヤー２の異なるセグメントに位置してもよい。

鍵所有者間のＥＡＰＯＬプロキシ
ノードとサーバ１０５との通信に用いられるプロトコルの一例としては、ＥＡＰ（拡張認証プロトコル）が挙げられる。ＥＡＰプロトコルは、メッセージのフォーマットと、多数の認証方法を支援する交換ハンドシェークを定義する。通常、ＥＡＰはポイント・ツー・ポイント・プロトコル（ＰＰＰ）又はＩＥＥＥ ８０２のデータリンクレイヤーを直接通過し、ＩＰを必要としない。ＥＡＰは重複削除及び再送信もサポートするが、下位レイヤーの順序保証に依存する。ＥＡＰ自体ではフラグメンテーションがサポートされない。しかしながら、個々のＥＡＰの方法は、例えば長い証明書データを複数のパッケージにて送信しなければならないＥＡＰ−ＴＬＳにおいては、フラグメンテーションをサポートすることもある。例えば、８０２．１Ｘの場合、認証サプリカントとＲ０ＫＨ１２０との間のＥＡＰメッセージは、ＥＡＰＯＬ（ＬＡＮ上で動作する拡張可能な認証プロトコル）のメッセージフォーマットにカプセル化される。ＥＡＰは、ユーザのパスワード、証明書に基づく認証、使い捨てパスワード、認証トークン、スマートカードなどの多数の認証機構をサポートする柔軟性および拡張性を備える。また、妥当な認証機構と折り合いをつけ、それを用い、またノード及び認証サーバ１０５にて鍵素材を生成するものを含む適切な認証機構とネゴシエートして、認証機構を使用する通信手段提供する。

ノードが、例えばＥＡＰＯＬ（ＬＡＮ上で動作する拡張可能な認証プロトコル）パケットを備えるＥＡＰ（拡張認証プロトコル）を用いた認証要求を送信するとき、認証手続きが開始される。認証プロセスは送受信される多数のＥＡＰＯＬパケットを含む、ＥＡＰ開始パケットで開始し、ＥＡＰ成功メッセージパケット又はＥＡＰ失敗メッセージパケットで終了する。認証サーバは認証対象である移動体デバイス（一般に、サプリカントと呼ばれる）の認証証明書を保存している。また、認証サーバは、他の認証サーバに接続し、自分が保有していないサプリカントの証明書を取得することも可能である。

８０２．１１ｒの鍵階層構造が鍵管理に用いられる場合、認証用のＥＡＰＯＬメッセージと鍵管理は、トップレベルの鍵所有者Ｒ０ＫＨと次のレベルの鍵所有者Ｒ１ＫＨとの間で送信されなければならない。

図２は、本発明のいくらかの実施形態の運用において用いられるメッセージフォーマット２００を示す。特に図２は、本発明のいくらかの実施形態によるＬ２鍵所有者通信フレームに対してのＥＡＰメッセージのカプセル化を説明している。メディアアクセスコントロール（ＭＡＣ）ヘッダ２０５は、各ホップのソース及び宛先ＭＡＣアドレスを含んでいる。アドホックルート（ＡＨＲ）ヘッダ２１０は、オーセンティケータのソース及び宛先ＭＡＣアドレス、及びメッシュルートエンディングデバイス（即ち、Ｒ１ＫＨ及びＲ０ＫＨ）を含んでいる。ＡＨＲヘッダ２１０のプロトコルＩＤ領域に位置する特別プロトコルＩＤは、ＥＡＰＯＬプロキシパケットを示すものである。サプリカントＭＡＣアドレス２２０もまた、メッセージフォーマット２００内で、ＡＨＲヘッダ２１０とＥＡＰＯＬパケット２３０との間に含まれている。メッセージフォーマット２００は、８０２．１１ｉ及び８０２．１１ｒのサプリカントを両方ともサポートするためのメッシュペイロードボディの第１バイトにおけるｉ／ｒフラグ２１５を備える。さらに、メッセージフォーマットは、仮想ＡＰをサポートするＳＳＩＤ情報アイテム２２５も有する。サプリカントＭＡＣアドレス２２０は、ＰＭＫ＿０及びＰＭＫ＿１を特定のサプリカントと結合するため、いずれのサプリカントデバイスがそれであるかをＲ０ＫＨ１２０が知るために必要である。ｉ／ｒフラグ２１５が８０２．１１ｉサプリカントを示すとき、Ｒ０ＫＨ１２０は８０２．１１ｉ規格に基づいてＰＭＫを生成し、Ｒ１ＫＨへＰＭＫを送信する。ｉ／ｒフラグ２１５が８０２．１１ｒサプリカントを示すとき、Ｒ０ＫＨ１２０は８０２．１１ｒの鍵階層構造に基づいてＰＭＫ＿０及びＰＭＫ＿１を生成し、ＰＭＫ＿１をオーセンティケータ（Ｒ１ＫＨ）へ送信する。ＳＳＩＤ２２５は、ＰＭＫ＿０及びＰＭＫ＿１の生成に必要である。仮想ＡＰに対しては、サプリカントは可能な複数のＳＳＩＤの中から１つのＳＳＩＤを選択することができる。

本発明によると、鍵所有者の中からメッセージをネットワークレイヤーにおいて送信するとき、ｉ／ｒ２１５、ＳＰＡ２２０、及びＳＳＩＤ２２５の領域に沿うＥＡＰＯＬフレーム２３０は、インターネットプロトコル（ＩＰ）パケットペイロード内に配置される。加えて、ＰＭＫ＿１の生成に必須である送信している鍵所有者のＭＡＣアドレスもまた、ＩＰペイロードに含まれている。

当業者にとって公知であるが、図２に示されているように、ＥＡＰＯＬフレーム２３０は、符号無しの２進数であるプロトコルバージョン２３５を含む。その値は、ＥＡＰＯＬプロトコルのバージョンに該当する。ＥＡＰＯＬフレーム２３０は、符号無しの２進数であるパケットタイプ２４０をさらに含んでおり、その値は以下のパケットタイプ（（１）ＥＡＰ−パケット、（２）ＥＡＰＯＬ−スタート、（３）ＥＡＰＯＬ−エグオフ、（４）ＥＡＰＯＬ−鍵、（５）ＥＡＰＯＬ−カプセル化−ＡＳＦ−警告）を決定するものである。ＥＡＰＯＬフレーム２３０は、符号無しの２進数であるパケットボディ長２４５もさらに含んでおり、その値は、パケットボディ領域における８ビットの長さを定義する。また、ＥＡＰＯＬフレーム２３０は、パケットタイプがＥＡＰ−パケットタイプやＥＡＰＯＬ−鍵の場合には表示され、そうでない場合には表示されないパケットボディ２５０も含んでいる。

当業者にとって公知であるが、図２に示されているように、ＥＡＰパケットボディ２５０は、ＥＡＰパケットのタイプを識別するコードフィールド２５５を含む。ＥＡＰコードは、１＝要求、２＝応答、３＝成功、４＝失敗のように割り当てられる。ＥＡＰパケット２５０は、要求と応答を整合を補助する識別子フィールド２６０をさらに含む。ＥＡＰパケットボディ２５０は、コード２５５、識別子２６０、長さ２６５、データフィールド２７５を備えるＥＡＰパケットの長さを示す長さフィールド２６５を含む。ＥＡＰパケットボディ２５０はさらにタイプフィールド２７０を含む。タイプフィールドは、要求又は応答の種類を示す。これは、識別タイプ又は特定の認証方法であってもよい。また、ＥＡＰパケットボディ２５０は、タイプデータフィールド２７５を含む。データフィールド２７５のフォーマットは、コードフィールド２５５及びタイプフィールド２７０によって決定される。

鍵配布鍵（ＫＤＫ）及び役割認可
当業者にとって認識されるように、ネットワーク１００におけるサプリカントデバイスには二種類ある。そのネットワーク１００における二種類のサプリカントデバイスは、ＭＡＰデバイス１３５−ｎ及びＳＴＡデバイス１４０−ｎである。本発明のいくらかの実施形態によると、ＭＡＰデバイス１３５−ｎは、８０２．１１ｒの鍵階層構造に対し、Ｒ１ＫＨとして機能する。トップの鍵所有者Ｒ０ＫＨ１２０からＲ１ＫＨへのＰＭＫ＿１の配布を保護するため、ペアＫＤＫは図３に示されるように、Ｒ０ＫＨ及びＭＡＰ／ＩＡＰの各ペアから生成される。

図３は、本発明のいくらかの実施形態による鍵配布及び役割認可プロセス３００を示すフローチャートである。図３に示されるように、その動作は、初期認証ステップ３０５から始まる。初期認証は、例えば、初期ＴＴＬＳ又はＴＬＳ認証であってもよい。次に、ステップ３１０にて、Ｒ０ＫＨ１２０は、認証されたサプリカントへの最終メッセージ「認証成功」において、認証サーバ１０５から認証属性を取得する。次に、ステップ３１５にて、認証されたサプリカントの役割属性がレベル１の鍵所有者であるか否かを判定する。認証されたサプリカントの役割属性がレベル１の鍵所有者である場合、処理はステップ３２０へ移行し、ＫＤＫを生成するために、Ｒ０ＫＨ及びサプリカントのＲ１ＫＨはＰＭＫ＿０に対して８０２．１１ｉ規格の４段階ハンドシェークを開始する。

次に、ステップ３２０にて、ＫＤＫは以下の式から生成される。
ＫＤＫ＝ＫＤＦ−ＫＤＫＬｅｎ（ＰＭＫ＿０，“ＫＤＫ鍵生成”，ＳＮｏｎｃｅ‖ＡＮｏｎｃｅ‖ＡＡ‖ＳＰＡ）
ここで、
・ＫＤＦ−２５６は８０２．１１ｒ規格のセクション８．５Ａ．３．において定義されている。

・ＳＮｏｎｃｅはＲ１ＫＨにより生成される乱数である。
・ＡＮｏｎｃｅはＲ０ＫＨにより生成される乱数である。
・上記両乱数は、４段階ハンドシェークによる最初の２つのメッセージ間に交換される。

・ＡＡはＲ０ＫＨのＭＡＣアドレスである。
・ＳＰＡはＲ１ＫＨのＭＡＣアドレスである。
当業者にとって認識されるように、Ｒ１ＫＨが移動する場合にも、Ｒ０ＫＨが新たなＫＤＫの４段階ハンドシェークを開始しない限り、ＫＤＫは同じ状態を維持する。

認証、及び再認証開始
図４は、本発明のいくらかの実施形態による認証手続き４００を示す。図４に示されるように、その動作は、ステップ４０５にてノード１３５−ｎの電源を入れることから開始される。次に、ステップ４１５にて、ノードは、ＭＡＰ１３５−ｎ又はＩＡＰ１３０−ｎのいずれかの隣接したデバイスからビーコンフレームをリスンし、又はスキャンする。次に、同ステップ４１５にて、ノードはＩＡＰ又はＭＡＰを選択し、認証サーバ１０５と接続しているデバイスを選択することにより認証プロセスを開始する。次に、ステップ４２０にて、選択された隣接するＭＡＰデバイスを用いたノードに対する第１認証が完了する。同ステップ４２５にて、第１認証の後、ノードは、同一のモビリティドメインにて認証されて、ＩＡＰと接続している他の隣接したＭＡＰデバイスと再認証を開始してもよい。これにより、本再認証は、完全認証トランザクションを回避するために、８０２．１１ｒの高速ハンドオフプロセスを用いる。

認証メッセージフロー
図５は、本発明のいくらかの実施形態による図１におけるネットワークの各要素間で交換される認証メッセージを示すメッセージフローチャート５００である。特に図５は、サプリカントデバイスとＲ１ＫＨ ＭＡＰ（又はＩＡＰ）との間の認証メッセージ交換を説明するメッセージフローチャート５００である。Ｒ１ＫＨ ＭＡＰの８０２．１ｘの制御ポートは、非認証デバイスから送られるそのようなメッセージからブロックされる。

Ｒ１ＫＨ ＭＡＰは、Ｒ０ＫＨとセキュアに接続されているＭＡＰ又はＩＡＰデバイスであり、既に認証済みであると見なされる。それは、サプリカントデバイスに対するＲ１ＫＨの役割を担うことになる。

図５によるチャート５００の例示的なシナリオにおいて、Ｒ１ＫＨ ＭＡＰ１ １３５−１及びＲ１ＫＨ ＭＡＰ２ １３５−２は既に認証済みであり、Ｒ０ＫＨ１２０とセキュアに接続されている。これらは、例えば図５のマルチホップパス５０５によって示されるように、Ｒ０ＫＨ１２０からマルチホップ離れていてもよい。本シナリオのサプリカント（即ち、デバイス１４０−１）は、サプリカントのワンホップ隣であるＲ１ＫＨ ＭＡＰ１ １３５−１及びＲ１ＫＨ ＭＡＰ２ １３５−２の両方に認証されていない。

本シナリオにおいて、Ｒ０ＫＨ１２０と認証サーバ１０５との間のメッセージは、ＲＡＤＩＵＳプロトコルに基づくユーザー・データグラム・プロトコル（ＵＤＰ）を通じて送信される。メッセージはＲＡＤＩＵＳプロトコルのセキュリティ機構の保護を受けている。さらに、本シナリオにおいて、Ｒ１ＫＨ１３５−１とＲ０ＫＨ１２０との間の認証メッセージはＥＡＰＯＬ（ＬＡＮ上で動作する拡張可能な認証プロトコル）プロキシ機構を介して送信され、鍵素材はＲ０ＫＨとＲ１ＫＨとの間に位置するＫＤＫにより保護される。Ｒ１ＫＨ１３５−１は仮想アクセスポイント（ＡＰ）の実行のためにサプリカント１４０−１が選択したＳＳＩＤのＲ０ＫＨ１２０を通知する。

図５に示されるように、サプリカント１４０−１が接続要求５１０を隣接したＭＡＰ１ １３５−１へ送信するとき、認証プロセスが開始される。その応答として、ＭＡＰ１ １３５−１は接続応答５１５を送信する。例えば、最初の２つの接続メッセージを通じて８０２．１ｘのＥＡＰ認証５２０が選択された場合、サプリカント１４０−１（サプリカントからのＥＡＰＯＬ−スタート）により８０２．１ｘの認証プロセスが開始される。８０２．１ｘのＥＡＰ認証が成功して完了すると、ＭＳＫはアクセス承認メッセージに含まれ、ＥＡＰ−成功パケットや他の認証属性と共に認証サーバ１０５からＲ０ＫＨ１２０へ送信される。ＭＳＫを取得した後、Ｒ０ＫＨ１２０は８０２．１１ｒ規格で説明されている通りに、ＰＭＫ＿０及びＰＭＫ＿１を演算する。

ＫＤＫ生成プロセスを実行させるか否かを判定するために、Ｒ０ＫＨ１２０は、バックエンド認証サーバ１０５から返ってきた認証属性からサプリカントの役割を確認する。サプリカント１４０−１がＲ１ＫＨ役割を有している場合、ＫＤＫ生成メッセージ交換５２５が実行される。そうでない場合、ＫＤＫ生成プロセスはサプリカント１４０−１に対して実行されない。

ＰＭＫ＿０及びＰＭＫ＿１に対する固有の名称を生成するため、Ｒ０ＫＨ１２０はＰＭＫ＿０及びＰＭＫ＿１の固有の名称の生成に用いられる乱数ＡＮｏｎｃｅを生成する。ＡＮｏｎｃｅは、ＰＭＫ＿１及びＰＭＫ＿１の名称と共に、メッセージ５３０としてＭＡＰ１ １３５−１へ送信される。ＡＮｏｎｃｅは、サプリカント１４０−１と共に、４段階ハンドシェークにおいてＭＡＰ１ １３５−１により用いられる。そして、サプリカント１４０−１は、同じ鍵の名称を生成するために同一のＡＮｏｎｃｅを用いる。

ＰＭＫ＿１ ５３０をＲ０ＫＨ１２０から受け取った後、ＭＡＰ１はサプリカント１４０−１と共に４段階ハンドシェーク５３５を開始し、ＰＴＫを生成してサプリカント１４０−１とＭＡＰ３ １３５−３の間のリンクを保護する（図５には示されていない）。従って、ＭＡＰ１ １３５−１及びサプリカント１４０−１は、セキュアリンク５４０を通じて通信することができる。

図６は、本発明のいくらかの実施形態による、図５にて既に説明した、ＥＡＰ−ＴＴＬＳである８０２．１ｘ認証の例示的な詳細なメッセージ交換６００を示す。図６に示されるように、８０２．１ｘ認証が選ばれた場合、サプリカント１４０−１はＥＡＰＯＬ−スタートフレーム６０５をＲ１ＫＨ ＭＡＰ １３５−１へ送信する。そして、Ｒ１ＫＨ１３５−１は該フレーム６１０をＲ０ＫＨ１２０に送信する。Ｒ０ＫＨ１２０は、サプリカント１４０−１と認証サーバ１０５との間で行われる全てのメッセージフローの制御を担当する。Ｒ１ＫＨ ＭＡＰ １３５−１は、ＥＡＰＯＬ−スタートに対する再試行状態機械を実行させ、Ｒ０ＫＨ１２０へ送る。最終メッセージＰＭＫ＿１ ＡＣＫ ６１５はＲ０ＫＨ１２０において状態機械を完了させる。Ｒ０ＫＨ１２０からＲ１ＫＨ１３５−１への最終メッセージ６２０は、ＰＭＫ＿１、Ｒ１Ｎａｍｅ及びＡｎｏｎｃｅを含んでいる。サプリカント１４０−１が８０２．１１ｉのデバイスである場合、８０２．１１ｉのＰＭＫのみがＲ１ＫＨ１３５−１へ送信される。

再認証（高速遷移）
図５に戻り、ＭＡＰ１ １３５−１の第１認証の後、サプリカント１４０−１は、認証サーバ１０５とセキュアに接続されており、同一のモビリティドメインに属する、隣接したＭＡＰデバイス１３５−ｎと共に、再認証（高速ハンドオフ）プロセスを開始する。再認証プロセスは、８０２．１１ｒの高速ＢＳＳ遷移（無線を通じた基礎機構）に従う。再認証要求は、Ｒ０Ｎａｍｅ、Ｒ１Ｎａｍｅ、ＳＮｏｎｃｅ、及び対応するトップレベルの鍵所有者の名称Ｒ０ＫＨ−ＩＤを含んでいる。Ｒ０Ｎａｍｅ及びＲ１Ｎａｍｅも、また含まれるようになる。

図５に示されるように、サプリカント１４０−１とＭＡＰ１ １３５−１との間で認証手続きが完了すると、サプリカント１４０−１は、次の隣接デバイスであるＲ１ＫＨ ＭＡＰ２ １３５−２と共に再認証手続きを開始する。例えば、第１ハンドオフ５４５と共に第１メッセージがサプリカント１４０−１からＭＡＰ２ １３５−２へ送信される。それに応答して、ＭＡＰ２ １３５−２は、Ｒ１Ｎａｍｅにより識別されたＰＭＫ＿１を保持していない場合、Ｒ０ＫＨ１２０に対応するＰＭＫ＿１を要求するＰＭＫ要求５５０をＲ０ＫＨ１２０へ送信する。ＰＭＫ＿１はＲ０ＫＨに、Ｒ０Ｎａｍｅも含まれるべきであると要求する。それに応答して、Ｒ０ＫＨ１２０は、ＰＭＫ＿１ ５５５をＭＡＰ２ １３５−２へ送信する。その後、ＭＡＰ２ １３５−２は、ＭＡＰ２ １３５−２が対応するＰＭＫ＿１を取得した場合、サプリカント１４０へ第２メッセージを送信する。サプリカント１４０−１及びＭＡＰ２ １３５−２は、第１ハンドオフメッセージ５６０を完了し、結果としてセキュアリンク５６５を得る。当業者にとって認識されるように、第１ハンドオフ再認証は、サプリカントの（隣接する）通信範囲において、複数のＭＡＰ又はＩＡＰデバイスに対して繰り返されてもよい。

前述した明細書において、本発明の特定の実施形態を説明した。しかしながら、当業者にとって認識されるように、以下に請求項に記載された本発明の範囲から逸脱しない限り、様々な変更又は改善が認められる。従って、本明細書及び図面は、限定的な意味ではなくむしろ例示的ものとして見なされるべきであり、そのような変更は全て本発明の範囲内に含まれることを意図している。利点、効果、問題の解決策、及び利点、効果利点、問題の解決策をもたらすか、或いはもたらすと予想される全ての要素は、任意又は全ての請求の範囲の決定的で、必要な、かつ本質的な特徴又は要素として解釈されるべきではない。本発明は添付した請求の範囲のみによって定義されるものであり、その請求の範囲は、本出願の係属中になされた補正と、発行された請求の範囲の全ての均等物とを含む。

Claims (11)

1. インフラストラクチャベースの無線マルチホップネットワークにおけるセキュリティ認証及び鍵管理方法であって、
   認証されたサプリカントの１つ以上の役割属性を認証サーバで判定する工程を含む前記サプリカントの初期認証工程と、
   トップレベルの鍵所有者により前記認証サーバから１つ以上の認証属性を取得する工程と、
   前記トップレベルの鍵所有者により、前記認証されたサプリカントの役割属性がレベル１の鍵所有者であるか否かを判定する工程と、
   前記認証されたサプリカントの役割属性がレベル１の鍵所有者であった場合、鍵配布鍵（ＫＤＫ）を生成するために、ペアマスタ鍵（ＰＭＫ＿０）を用いて前記トップレベルの鍵所有者と前記サプリカントとの間で４段階ハンドシェークを開始する工程と、
   前記認証されたサプリカントの役割属性がレベル１の鍵所有者ではない場合、前記トップレベルの鍵所有者からレベル１の鍵所有者へ、レベル１のペアマスタ鍵（ＰＭＫ＿１）を通信する工程と、
   前記レベル１の鍵所有者と前記サプリカントとの間にセキュアな通信リンクを生成するために、レベル１のペアマスタ鍵（ＰＭＫ＿１）を用いて前記レベル１の鍵所有者と前記ユーザとの間で４段階ハンドシェークを開始する工程と、
   前記セキュアリンクを用いて前記レベル１の鍵所有者と前記サプリカントとの間で通信する工程とを備える方法。
2. 前記トップレベルの鍵所有者と前記レベル１の鍵所有者との間にＫＤＫを生成するための前記トップレベルの鍵所有者と前記レベル１の鍵所有者との間の４段階ハンドシェークは、８０２．１１ｉ規格の４段階ハンドシェークを備え、さらに、前記レベル１の鍵所有者と前記サプリカントとの間にペア一時鍵（ＰＴＫ）を生成するための前記レベル１の鍵所有者と前記サプリカントとの間の前記４段階ハンドシェークは、８０２．１１ｉ規格の４段階ハンドシェークを備える請求項１に記載のインフラストラクチャベースの無線マルチホップネットワークにおけるセキュリティ認証及び鍵管理方法。
3. 前記ＫＤＫは、以下の式から生成され、
   ＫＤＫ＝ＫＤＦ−ＫＤＫＬｅｎ（ＰＭＫ＿０，“ＫＤＫ鍵の生成”，ＳＮｏｎｃｅ‖ＡＮｏｎｃｅ‖ＡＡ‖ＳＰＡ）
   ここで、ＫＤＦ−２５６は所定の数値であり、
   ＳＮｏｎｃｅは前記サプリカントにより生成される乱数であり、
   ＡＮｏｎｃｅはトップレベルの鍵所有者により生成される乱数であり、
   前記両乱数は、４段階ハンドシェークによる最初の２つのメッセージ中に交換され、
   ＡＡはトップレベルの鍵所有者のＭＡＣアドレスであり、
   ＳＰＡは前記サプリカントのＭＡＣアドレスである請求項１に記載のインフラストラクチャベースの無線マルチホップネットワークにおけるセキュリティ認証及び鍵管理方法。
4. 前記初期認証工程は、最終「認証成功」メッセージの通信を含み、さらに、前記１つ以上の認証属性は、前記最終「認証成功」メッセージから得られる請求項１に記載のインフラストラクチャベースの無線マルチホップネットワークにおけるセキュリティ認証及び鍵管理方法。
5. 認証済みであり、かつ同じモビリティドメインにおける前記トップレベルの鍵所有者と接続している他のレベル１の鍵所有者を、前記サプリカントが再認証を開始する工程をさらに備え、該再認証工程は、
   高速ハンドオフプロセスを用いて前記サプリカントから前記他のレベル１の鍵所有者へメッセージを通信する工程と、
   前記レベル１のペアマスタ鍵（ＰＭＫ＿１）を前記トップレベルの鍵所有者から前記他のレベル１の鍵所有者へ通信する工程と、
   前記サプリカントと前記他のレベル１の鍵所有者との間にセキュアな通信リンクを生成するために、前記レベル１のペアマスタ鍵（ＰＭＫ＿１）を用いて、前記他のレベル１の鍵所有者と前記サプリカントとの間の前記ハンドオフプロセスを完了する工程と、
   前記セキュアリンクを用いて前記他のレベル１の鍵所有者と前記サプリカントの間に通信する工程とを備える請求項１に記載のインフラストラクチャベースの無線マルチホップネットワークにおけるセキュリティ認証及び鍵管理方法。
6. インフラストラクチャベースの無線マルチホップネットワークにおけるセキュリティ認証及び鍵管理のための、トップレベルの鍵所有者とレベル１の鍵所有者との間の通信方法であって、
   メッセージフォーマットを有するメッセージを通信する工程を備え、該メッセージフォーマットは、
   少なくとも１つのホップのソース及び宛先ＭＡＣアドレスを含むメディアアクセスコントロール（ＭＡＣ）ヘッダと、
   前記レベル１の鍵所有者及び前記トップレベルの鍵所有者のソース及び宛先ＭＡＣアドレスと、ローカルエリアネットワーク上で動作する拡張可能な認証プロトコル（ＥＡＰＯＬ）プロキシパケットを示すプロトコル識別とを含むアドホックルート（ＡＨＲ）ヘッダと、
   サプリカントＭＡＣアドレスと、
   ｉ／ｒフラグと、
   ＳＳＩＤとを備える方法。
7. 前記サプリカントＭＡＣアドレスは、いずれのサプリカントデバイスがペアマスタ鍵ＰＭＫ＿０及びＰＭＫ＿１と結合しているかを特定する請求項６に記載の方法。
8. ８０２．１１ｉのサプリカントを示す前記ｉ／ｒフラグは、前記ＰＭＫが８０２．１１ｉ規格に基づいて生成されたものであり、かつ該ＰＭＫがＲ１ＫＨへ送信されるべきものであることを特定する請求項６に記載の方法。
9. ８０２．１１ｒのサプリカントを示す前記ｉ／ｒフラグは、前記ＰＭＫ＿０及びＰＭＫ＿１が８０２．１１ｒの鍵階層構造に基づいて生成されたものであり、該ＰＭＫ＿１はオーセンティケータへ送信されるべきものであることを特定する請求項６に記載の方法。
10. 前記ＳＳＩＤは、仮想アクセスポイントに対するＰＭＫ＿０及びＰＭＫ＿１の生成に用いられ、さらに、サプリカントは、利用可能な複数のＳＳＩＤの中から１つのＳＳＩＤを選択する請求項６に記載の方法。
11. 前記メッセージは、レイヤー２及びレイヤー３を含む群から選択される通信レイヤーにて送信され、さらに、前記メッセージフォーマットがインターネットプロトコルパケットペイロードに配置される場合、Ｒ１ＫＨのＭＡＣアドレスがメッセージの内容に追加される請求項６に記載の方法。

Images