(57)【特許請求の範囲】
【請求項１】
要求側との通信セッション中の鍵取り替えのために認証側により実行される方法であって、
鍵取り替え確認メッセージの受信の前の受信のために新たな鍵をインストールするステップと、
前記鍵取り替え確認メッセージの受信後まで、送信のための前記新たな鍵の使用を遅らせるステップと
を有する方法。
【請求項２】
受信のために前記新たな鍵をインストールした後に、前記方法は、送信のために古い鍵を使用し続けつつ、受信のために前記新たな鍵又は古い鍵を使用するステップを更に有し、
前記要求側は、前記鍵取り替え確認メッセージの送信前の受信のために前記新たな鍵をインストールし、前記鍵取り替え確認メッセージの送信後まで、送信のための前記新たな鍵の使用を遅らせる、請求項１に記載の方法。
【請求項３】
前記要求側は、前記鍵取り替え確認メッセージの送信直後又は前記鍵取り替え確認メッセージの送信後の所定の期間まで、送信のための前記新たな鍵の使用を遅らせる、請求項２に記載の方法。
【請求項４】
前記鍵取り替え確認メッセージの受信前の受信のために前記新たな鍵をインストールした後に、受信したユニキャストパケットで伝達された鍵識別子に基づいて、受信したユニキャストパケットを解読するために前記新たな鍵又は古い鍵のいずれかを選択するステップを含む、請求項２に記載の方法。
【請求項５】
前記鍵取り替え確認メッセージは、鍵取り替えのための４ウェイ・ハンドシェイクの第４のメッセージであり、
前記方法は、
前記認証側が、前記４ウェイ・ハンドシェイクの第２のメッセージの受信後且つ前記４ウェイ・ハンドシェイクの第３のメッセージの送信前に受信したパケットを解読する際に使用するために前記新たな鍵をインストールと、
前記認証側が、前記第４のメッセージの受信後まで、送信のためのパケットを暗号化する際に使用するための前記新たな鍵の使用を遅らせるステップと
を更に有し、
前記要求側は、前記第３のメッセージの受信後且つ前記第４のメッセージの送信前に受信したメッセージを解読する際に使用するために前記新たな鍵をインストールし、
前記要求側は、前記第４のメッセージの送信直後又は前記第４のメッセージの送信後の所定の期間まで、送信のためのパケットを暗号化する際に使用するための前記新たな鍵のインストールを遅らせる、請求項２に記載の方法。
【請求項６】
前記４ウェイ・ハンドシェイクが完了しなかった場合、前記新たな鍵をアンインストールするステップを更に有する、請求項５に記載の方法。
【請求項７】
前記４ウェイ・ハンドシェイクは、IEEE802.11通信標準に従って、EAPOL（Extensible  Authentication  Protocol  over  Local  area  network）鍵フレームを交換することを有する、請求項５に記載の方法。
【請求項８】
前記鍵取り替え確認メッセージは、鍵取り替えのための４ウェイ・ハンドシェイクの第４のメッセージであり、
前記認証側は、ユニキャストトラヒックを通信する際に使用するための２つのユニキャスト鍵について提供されたユニキャスト鍵ID空間を有するメモリを有し、前記２つのユニキャスト鍵は、少なくとも前記古い鍵及び前記新たな鍵を有する、請求項２に記載の方法。
【請求項９】
前記古い鍵の削除を回避するために、順次の４ウェイ・ハンドシェイクの間に２つの鍵識別子の使用を交互にするステップを更に有する、請求項８に記載の方法。
【請求項１０】
受信したユニキャストパケットの鍵IDフィールドを読み取るステップと、
前記鍵IDフィールドから前記古い鍵又は前記新たな鍵のいずれかを識別するステップと、
前記受信したユニキャストパケットを解読するために前記識別された鍵を使用するステップと
を更に有する、請求項８に記載の方法。
【請求項１１】
前記メモリは、１つ以上の非ユニキャスト鍵のための非ユニキャスト鍵ID空間を更に含み、
前記方法は、
受信したパケットの媒体アクセス制御アドレスに基づいて、受信したパケットがユニキャストパケットであるか非ユニキャストパケットであるかを判定するステップと、
前記受信したパケットがユニキャストパケットであると判定された場合、前記ユニキャスト鍵の１つを識別するために、前記鍵IDフィールドに基づいて前記ユニキャスト鍵ID空間をインデックス付けするステップと、
前記受信したパケットが非ユニキャストパケットであると判定された場合、前記非ユニキャスト鍵の１つを識別するために、前記鍵IDフィールドに基づいて前記非ユニキャスト鍵ID空間をインデックス付けするステップと
を更に有する、請求項１０に記載の方法。
【請求項１２】
受信したユニキャストパケットの新規鍵ビットを読み取り、前記受信したユニキャストパケットを解読するために鍵を切り替えるか否かを判定するステップを更に有する、請求項８に記載の方法。
【請求項１３】
鍵取り替え動作の一部として前記新たな鍵を交渉するために、４ウェイ・ハンドシェイクを実行するステップを更に有し、
前記新たな鍵は、前記４ウェイ・ハンドシェイクの間に交換された情報から前記要求側と前記認証側との双方により生成された非対称鍵である、請求項８に記載の方法。
【請求項１４】
前記認証側はアクセスポイントであり、前記要求側は移動局であり、
前記アクセスポイント及び前記移動局は、IEEE802.11通信標準に従って通信する、請求項１３に記載の方法。
【請求項１５】
認証側との通信セッション中の鍵取り替えのために要求側により実行される方法であって、
前記認証側への鍵取り替え確認メッセージの送信前の受信のために新たな鍵をインストールするステップと、
前記鍵取り替え確認メッセージの送信後まで、送信のための前記新たな鍵の使用を遅らせるステップと、
前記鍵取り替え確認メッセージ後に受信のための古い鍵及び受信のための前記新たな鍵の双方の使用をサポートするステップと
を有する方法。
【請求項１６】
前記認証側は、前記鍵取り替え確認メッセージの受信前の受信のために前記新たな鍵をインストールし、前記鍵取り替え確認メッセージの受信後まで、送信のための前記新たな鍵の使用を遅らせ、
前記要求側及び前記認証側は、前記鍵取り替え確認メッセージの受信後に受信のための前記古い鍵及び受信のための前記新たな鍵の使用をサポートし続ける、請求項１５に記載の方法。
【請求項１７】
前記要求側は、前記鍵取り替え確認メッセージの送信後の所定の期間まで、受信のための前記古い鍵及び受信のための前記新たな鍵の使用をサポートし続け、
前記認証側は、前記鍵取り替え確認メッセージの受信後の所定の期間に受信のための前記古い鍵及び受信のための前記新たな鍵の使用をサポートし続ける、請求項１６に記載の方法。
【請求項１８】
前記要求側は、ユニキャストトラヒックを通信する際に使用するための２つのユニキャスト鍵について提供されたユニキャスト鍵ID空間を有するメモリを有し、前記２つのユニキャスト鍵は、少なくとも前記古い鍵及び前記新たな鍵を有し、
前記方法は、
受信したユニキャストパケットの鍵IDフィールドを読み取り、前記受信したユニキャストパケットを解読するために前記新たな鍵を使用するか前記古い鍵を使用するかを判定するステップ、又は
前記受信したユニキャストパケットの新規鍵ビットを読み取り、前記受信したユニキャストパケットを解読するために鍵を切り替えるか否かを判定するステップ
を有する、請求項１５に記載の方法。
【請求項１９】
前記鍵取り替え確認メッセージは、鍵取り替えのための４ウェイ・ハンドシェイクの第４のメッセージであり、
前記方法は、前記古い鍵の削除を回避するために、順次の４ウェイ・ハンドシェイクの間に２つの鍵識別子の使用を交互にするステップを更に有する、請求項１８に記載の方法。
【請求項２０】
鍵取り替え動作を実行する処理回路と、
ユニキャストトラヒックを有するパケットを暗号化及び解読する際に使用するための少なくとも２つのユニキャスト鍵を格納するユニキャスト鍵ID空間を有するメモリと
を有し、
無線デバイスが認証側として動作する場合、前記処理回路は、鍵取り替え確認メッセージの受信の前の受信のために新たな鍵をインストールし、前記鍵取り替え確認メッセージの受信後まで、送信のための前記新たな鍵の使用を遅らせ、
無線デバイスが認証側として動作する場合、前記認証側は、前記鍵取り替え確認メッセージの受信後の所定の期間に受信のための古い鍵及び受信のための前記新たな鍵の使用をサポートし続ける無線デバイス。
【請求項２１】
前記無線デバイスが要求側として動作する場合、前記処理回路は、前記鍵取り替え確認メッセージの送信前の受信のために前記新たな鍵をインストールし、前記鍵取り替え確認メッセージの送信後まで、送信のための前記新たな鍵の使用を遅らせ、
前記無線デバイスが要求側として動作する場合、前記要求側は、前記鍵取り替え確認メッセージの送信後の所定の期間まで、受信のための前記古い鍵及び受信のための前記新たな鍵の使用をサポートし続ける、請求項２０に記載の無線デバイス。
【請求項２２】
前記処理回路は、
受信したユニキャストパケットの鍵IDフィールドを読み取り、前記受信したユニキャストパケットを解読するために前記ユニキャスト鍵ID空間に格納された前記新たな鍵を使用するか前記古い鍵を使用するかを判定すること、又は
前記受信したユニキャストパケットの新規鍵ビットを読み取り、前記受信したユニキャストパケットを解読するために前記ユニキャスト鍵ID空間に格納された前記新たな鍵又は前記古い鍵の間を切り替えるか否かを判定すること
を実行する、請求項２１に記載の無線デバイス。
【請求項２３】
前記鍵取り替え確認メッセージは、鍵取り替えのための４ウェイ・ハンドシェイクの第４のメッセージであり、
前記４ウェイ・ハンドシェイクは、IEEE802.11通信標準に従って、EAPOL（Extensible  Authentication  Protocol  over  Local  area  network）鍵フレームを交換することを有する、請求項２２に記載の無線デバイス。
【請求項２４】
前記鍵取り替え確認メッセージは、鍵取り替えのための４ウェイ・ハンドシェイクの第４のメッセージであり、
前記認証側は、前記古い鍵の削除を回避するために、順次の４ウェイ・ハンドシェイクの間に２つの鍵識別子の使用を交互にする、請求項２２に記載の無線デバイス。
【請求項２５】
ビデオストリーミングセッション中に要求側により実行される鍵取り替え方法であって、
ストリーミングされるビデオを有し、第１の鍵で暗号化されたユニキャストパケットを受信するステップと、
鍵取り替え開始メッセージを受信し、鍵取り替え動作を開始するステップと、
認証側への鍵取り替え確認メッセージの送信前の受信のために第２の鍵をインストールするステップと、
受信したユニキャストパケットで伝達された鍵識別子に基づいて、受信したユニキャストパケットを解読するために前記第１又は第２の鍵を選択するステップと、
前記鍵取り替え確認メッセージの送信後の所定の期間まで、前記第１の鍵及び前記第２の鍵の双方での前記ユニキャストパケットの受信をサポートするステップと
を有する方法。
【請求項２６】
前記鍵取り替え確認メッセージの送信直後まで、送信のための前記第２の鍵のインストールを遅らせるステップを更に有する、請求項２５に記載の方法。
【請求項２７】
前記鍵取り替え確認メッセージの送信後の前記所定の期間の後に受信する際に使用するために前記第１の鍵をアンインストールするステップを更に有する、請求項２５に記載の方法。
【請求項２８】
前記鍵取り替え確認メッセージは、鍵取り替えのための４ウェイ・ハンドシェイクの第４のメッセージである、請求項２７に記載の方法。
【請求項２９】
前記第１の鍵の削除を回避するために、順次のハンドシェイクの間に２つの鍵識別子の使用を交互にするステップを更に有する、請求項２７に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
実施例は、無線通信に関する。或る実施例は、無線ネットワークでの鍵取り替え（rekeying）動作に関する。或る実施例は、IEEE802.11標準の１つによる鍵取り替え動作のための４ウェイ・ハンドシェイク（four-way  handshake）に関する。或る実施例は高スループットの無線ネットワークでのビデオストリーミングに関する。
【背景技術】
【０００２】
多くの無線ネットワークでは、パケットは、セキュリティを提供するために、暗号化鍵で暗号化されている。特定の条件が発生すると、暗号化鍵は更新され、新たな鍵が生成される。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
鍵取り替え処理の間に、局が異なる鍵を使用している短い期間が存在する可能性がある。その結果、幾つかのパケットは解読できず、破棄される必要がある。このパケットのロスは、特にビデオストリーミングのような非常に高いスループットの状況で問題になる。この理由は、ビデオでの分断を生じる可能性があるからである。このパケットロスはまた、伝送制御プロトコル（TCP：transmission  control  protocol）のスロースタートアルゴリズムに影響を与える可能性がある。
【０００４】
従って、非常に高いスループットの無線通信に適した低減したパケットロスを備えた鍵取り替えのための無線デバイス及び方法の一般的なニーズが存在する。
【図面の簡単な説明】
【０００５】
【図１】或る実施例による無線通信ネットワーク
【図２】或る実施例による低減したパケットロスを備えた鍵取り替えの手順
【図３】或る実施例による無線デバイスのブロック図
【図４】或る実施例による鍵取り替え中にパケットを受信する手順を示すフローチャート
【発明を実施するための形態】
【０００６】
以下の説明及び図面は、当業者が特定の実施例を実行可能にできるように、特定の実施例を十分に示している。他の実施例は、構造的、論理的、電気的、処理的及び他の変更を組み込んでもよい。或る実施例の部分及び特徴は、他の実施例の部分及び特徴に含まれてもよく、代用されてもよい。請求項に記載する実施例は、これらの請求項の全ての利用可能な均等物を含む。
【０００７】
図１は、或る実施例による無線通信ネットワークである。無線通信ネットワーク100は、認証側102及び要求側104のような２つ以上の無線デバイスを含んでもよい。認証側102及び要求側104は、IEEE802.11通信標準の１つのような１つ以上の無線通信技術に従って無線チャネルを通じて通信してもよい。或る実施例では、認証側102は、アクセスポイント（AP）でもよく、要求側104は、移動局（STA）でもよい。
【０００８】
認証側102及び要求側104は、暗号化鍵を使用して暗号化されたパケットを通信してもよい。暗号化鍵は、認証側102と要求側104との間の成功した認証処理の間に生成されてもよい。暗号化鍵は、認証側102と要求側104との間の次の鍵取り替え処理を通じて更新されてもよい。鍵取り替え処理は、以下に詳細に説明する４ウェイ・ハンドシェイクを含んでもよい。
【０００９】
実施例によれば、鍵取り替え動作の間のパケットロスの低減を支援するために、認証側102は、鍵取り替え確認メッセージの受信の前の受信のために新たな鍵をインストールしてもよい。認証側102はまた、鍵取り替え確認メッセージの受信後まで、送信のための新たな鍵の使用を遅らせてもよい。実施例によれば、要求側104は、鍵取り替え確認メッセージの送信前の受信のために新たな鍵をインストールしてもよく、鍵取り替え確認メッセージの送信後まで、送信のための新たな鍵の使用を遅らせてもよい。認証側102及び要求側104の双方による受信のための新たな鍵の早期のインストールにより、新たな鍵及び古い鍵の双方が受信したパケットを解読する際の使用に同時に有効（アクティブ）になることを可能にする。このように、鍵取り替え動作の間のパケットロスが低減され得る。これらの実施例について、以下に詳細に説明する。
【００１０】
或る実施例では、鍵取り替え処理は、４ウェイ・ハンドシェイク103の一部でもよく、鍵取り替え確認メッセージは、４ウェイ・ハンドシェイクの第４（４番目）のメッセージでもよい。或る実施例では、新たな鍵は、４ウェイ・ハンドシェイクの間に交換された情報から要求側104及び認証側102の双方により生成された非対称鍵でもよい。これらの実施例について、以下に詳細に説明する。
【００１１】
通常では、新たな鍵は、鍵取り替え確認メッセージの受信後まで、受信のために認証側102によりインストール及び使用されない。通常では、新たな鍵は、鍵取り替え確認メッセージの送信後まで、受信のために要求側104によりインストール及び使用されない。これらのイベントは同期していないため、鍵取り替え処理の完了前に受信した幾つかのパケットは、適切に解読できない可能性がある。或る実施例によれば、受信のための新たな鍵の早期のインストール及び使用と、受信のための古い鍵の継続したサポートとにより、古い鍵又は新たな鍵のいずれかで暗号化されたパケットが適切に解読されることが可能になる。通常の鍵取り替え技術とは異なり、受信のための２つ以上の鍵が同時に有効になってもよく、受信したパケットを解読するために使用されてもよい。
【００１２】
IEEE（Institute  for  Electrical  and  Electronic  Engineer）の802.11iドラフト標準は、移動局とその関連するアクセスポイントとの間で相互認証及びユニキャストグループ鍵を確立するプロトコル（802.11iプロトコル）を規定している。802.11iプロトコルは、セッションの有効性（liveliness）を確認し、ユニキャスト鍵を確立してグループ鍵を確立するために、４ウェイ・ハンドシェイクを使用する。或る実施例は、鍵取り替え中に生じ得るパケットロスを低減するために、IEEE802.11の４ウェイ・ハンドシェイクの上の階層になってもよい。
【００１３】
或る実施例では、認証側102は、アクセスポイントであり、要求側104は、移動局である。或る実施例では、アクセスポイント及び移動局は、IEEE802.11通信標準又はドラフト標準の１つに従って通信してもよい。或る実施例では、鍵取り替え動作は、ユニキャストパケットがアクセスポイントから移動局にストリーミングされるビデオストリーミングセッションを含む通信セッションの間に実行されてもよい。或る実施例では認証側102はアクセスポイントとして記載され、或る実施例では要求側104は移動局として記載されるが、実施例の範囲はこの点に限定されない。或る別の実施例では、認証側は移動局でもよく、要求側はアクセスポイントでもよい。他の別の実施例では、認証側及び要求側の双方が移動局でもよい。
【００１４】
或る実施例では、鍵生成は、既存の鍵の差し迫った存続の終了により開始されてもよい。鍵は、所定の期間（例えば、12時間）の後に終了してもよい。鍵生成は、パケット番号の差し迫った消耗により開始されてもよい。各パケットは、リプレイ攻撃を検出するために、パケット番号を割り当てられる。パケット番号は、所与の鍵を使用して暗号化されたパケット毎に固有のものである。パケット番号空間が消耗する場合（すなわち、全てのパケット番号が割り当てられた場合）、新たな鍵が生成される。鍵取り替えは、セキュリティアソシエーション（security  association）が壊れることを回避するために、これらのイベントのいずれかが生じる前に実行されてもよい。
【００１５】
図２は、或る実施例による低減したパケットロスを備えた鍵取り替えの手順を示している。手順200において、要求側104及び認証側102は、確立されたセキュリティアソシエーションを有してもよく、１つ以上の暗号化鍵を使用してパケットを交換してもよい。鍵取り替えイベントの発生時に、動作222において、認証側102は、鍵取り替え処理を開始するために、鍵取り替え開始メッセージ201を送信してもよい。鍵取り替え開始メッセージ201の受信に応じて、動作242において、要求側104は、鍵取り替え開始応答メッセージ202を認証側102に送信してもよい。動作224において、認証側102は、鍵取り替え開始応答メッセージ202を受信してもよい。鍵取り替え開始応答メッセージ202の受信に応じて、認証側102は、受信のために新たな鍵を生成してインストールしてもよい。鍵取り替え開始メッセージ201で送信されて鍵取り替え開始応答メッセージ202で受信した情報は、新たな鍵を生成するために使用されてもよい。
【００１６】
動作226において、認証側102は、鍵取り替え開始応答メッセージ202に応じて、応答確認メッセージ203を送信する。動作244において、要求側104は、応答確認メッセージ203を受信し、鍵取り替え確認メッセージ204の送信前の受信のために新たな鍵を生成してインストールしてもよい。応答確認メッセージ203は、交換が介入者攻撃（man-in-the-middle  attack）を受けていないことを要求側104に示してもよい。要求側104及び認証側102の双方は、交換された情報のため、同じ新たな鍵を生成することができる。
【００１７】
これらの実施例では、認証側102は、応答確認メッセージ203の送信前の受信のために新たな鍵をインストールしてもよく、要求側104は、鍵取り替え確認メッセージ204の送信前の受信のために新たな鍵をインストールしてもよい。このように、新たな鍵及び古い鍵の双方が受信のために使用されてもよい。これらの実施例について以下に詳細に説明し得る。
【００１８】
或る実施例では、動作224において受信のために新たな鍵をインストールした後に、動作228において、送信のために古い鍵を使用し続けつつ、受信のために新たな鍵又は古い鍵のいずれかを使用してもよい。動作244において、要求側104は、鍵取り替え確認メッセージ204の送信前の受信のために新たな鍵をインストールしてもよく、鍵取り替え確認メッセージ204の送信後まで、送信のための新たな鍵の使用を遅らせてもよい。
【００１９】
動作228の間に、認証側102は、鍵取り替え確認メッセージ204の受信前から始まり、鍵取り替え確認メッセージ204の受信後の所定の期間まで、要求側104から受信したパケットを解読するために、新たな鍵又は古い鍵のいずれかを使用してもよい。認証側102はまた、鍵取り替え確認メッセージ204の受信後まで、要求側104に送信するためのパケットを暗号化するために新たな鍵の使用を遅らせてもよい。或る実施例では、認証側102は、鍵取り替え確認メッセージ204の受信直後まで又は鍵取り替え確認メッセージ204の受信後の所定の期間まで、送信のためのパケットを暗号化するために新たな鍵の使用を遅らせてもよい。
【００２０】
或る実施例では、要求側104は、動作246における鍵取り替え確認メッセージ204の送信直後まで又は動作246における鍵取り替え確認メッセージ204の送信後の所定の期間まで、動作248における送信のための新たな鍵をインストール及び／又は使用することを遅らせてもよい。或る別の実施例では、要求側104は、応答確認メッセージ203の受信後の所定の期間まで、送信のための新たな鍵の使用を遅らせてもよい。
【００２１】
或る実施例では、鍵取り替え確認メッセージ204の受信前の受信のために動作224において新たな鍵をインストールした後に、認証側102は、受信したユニキャストパケットで伝達される鍵識別子に基づいて、受信したユニキャストパケットを解読するために新たな鍵又は古い鍵のいずれかを選択してもよい。これらの実施例では、認証側102は、鍵取り替え確認メッセージ204の受信まで又は鍵取り替え確認メッセージ204の受信後の所定の期間まで、古い鍵での受信をサポートしてもよい。これらの実施例では、要求側104は、動作246における鍵取り替え確認メッセージ204の送信まで又は動作246における鍵取り替え確認メッセージ204の送信後の所定の期間まで、古い鍵での受信をサポートしてもよい。或る実施例では、所定の期間は、約60秒でもよいが、これは要件ではない。
【００２２】
動作232において、認証側102は、新たな鍵で暗号化されたパケットを送信してもよく、古い鍵及び新たな鍵でのパケットの受信をサポートしてもよい。同様に、動作250において、要求側104は、新たな鍵で暗号化されたパケットを送信してもよく、古い鍵及び新たな鍵でのパケットの受信をサポートしてもよい。
【００２３】
或る実施例では、鍵取り替え開始メッセージ201は４ウェイ・ハンドシェイク103のメッセージ１（M1：Message  1）でもよく、鍵取り替え開始応答メッセージ202は４ウェイ・ハンドシェイク103のメッセージ２（M2：Message  2）でもよく、応答確認メッセージ203は４ウェイ・ハンドシェイク103のメッセージ３（M3：Message  3）でもよく、鍵取り替え確認メッセージ204は４ウェイ・ハンドシェイク103のメッセージ４（M4：Message  4）でもよい。これらの実施例では、認証側102は、メッセージ２の受信後且つメッセージ３の送信前に受信したパケットを解読する際に使用するために新たな鍵をインストールしてもよい。認証側102はまた、メッセージ４の受信後まで、送信のためのパケットを暗号化するために新たな鍵の使用を遅らせてもよい。要求側104は、メッセージ３の受信後且つメッセージ４の送信前に受信したパケットを解読する際に使用するために新たな鍵をインストールしてもよい。要求側104は、メッセージ４の送信の直後又はメッセージ４の送信後の所定の期間まで、送信のためのパケットを暗号化する際に使用するための新たな鍵のインストールを遅らせてもよい。受信のための２つの鍵の同時使用をサポートする受信の場合とは異なり、新たな鍵が送信のためにインストールされた場合、もはや古い鍵は送信のためには使用されない。
【００２４】
動作234において、４ウェイ・ハンドシェイク103が完了しなかった場合、認証側102は、新たな鍵をアンインストールしてもよい。動作252において、４ウェイ・ハンドシェイク103が完了しなかった場合、要求側104は、新たな鍵をアンインストールしてもよい。これらの実施例では、４ウェイ・ハンドシェイク103が完了しなかった場合、認証側102及び要求側104は、送信及び受信の双方について新たな鍵の更なる使用を抑制してもよい。認証側102は、鍵取り替え確認メッセージ204を受信したときに４ウェイ・ハンドシェイク103の成功を仮定し、肯定応答（ACK：acknowledgement）206を要求側104に送信してもよい。要求側104は、認証側102からの肯定応答206に受信に基づいて、４ウェイ・ハンドシェイク103の成功を仮定してもよい。
【００２５】
或る実施例では、４ウェイ・ハンドシェイク103は、IEEE802.11標準に従ってEAPOL（Extensible  Authentication  Protocol  over  Local  area  network）鍵フレームを交換することを有してもよい。これらの実施例では、４ウェイ・ハンドシェイク103はEAP（Extensible  Authentication  Protocol）の一部でもよく、EAPOL鍵フレームはIEEE802.11通信標準によるEAPOL鍵フレームでもよい。これらの実施例の幾つかでは、４ウェイ・ハンドシェイク103は、IEEE802.11n、IEEE802.11ac及び／又はIEEE802.11ad通信標準又は提案された標準に従って実行されてもよい。これらの実施例では、メッセージ１、メッセージ２、メッセージ３及びメッセージ４は、鍵種別サブフィールドが１に設定されたEAPOL鍵フレームでもよい。
【００２６】
或る通常の鍵取り替え処理では、前の鍵と同じ鍵IDでの新たな鍵のインストールは、前の鍵が新たな鍵により置換されたときに削除されることを生じる。或る実施例では、２つの鍵IDが使用されてもよく、各ハンドシェイクは、２つの鍵IDの間を交互にしてもよい。例えば、第１のハンドシェイクは、第１の鍵ID（例えば、鍵ID=0）で行われてもよく、次のハンドシェイクは、第２の鍵ID（例えば、鍵ID=1）で行われてもよい。このように、２つの鍵がインストールされてもよく、１つの鍵から他の鍵へのスムーズなハンドオーバを可能にしてもよい（例えば、受信のための鍵がインストールされ、その後、鍵が送信のために使用される）。次のハンドシェイク（例えば、第３のハンドシェイク）は、鍵ID=0を使用して古い鍵を置換した第１の鍵ID（例えば、鍵ID=0）で行われてもよい。
【００２７】
図３は、或る実施例による無線デバイスのブロック図である。無線デバイス300は、要求側104（図１）又は認証側102（図１）のいずれかとしての使用に適してもよい。無線デバイス300は、物理レイヤ回路302と、処理回路304と、メモリ306とを含んでもよい。実施例によれば、処理回路304は、鍵取り替え動作を実行してもよく、メモリ306は、ユニキャストトラヒックを有するパケットを暗号化及び解読する際に使用するために少なくとも２つのユニキャスト鍵を格納するためのユニキャスト鍵ID空間を有してもよい。無線デバイス300が認証側102として動作する場合、処理回路304は、鍵取り替え確認メッセージ204の受信前の受信のために新たな鍵をインストールしてもよく、鍵取り替え確認メッセージ204の受信後まで、送信のための新たな鍵の使用を遅らせてもよい。無線デバイス300が認証側102として動作する場合、認証側102は、鍵取り替え確認メッセージ204の受信後の所定の期間に、受信のための古い鍵及び受信のための新たな鍵の使用をサポートし続ける。
【００２８】
これらの実施例では、無線デバイス300が要求側104として動作する場合、処理回路304は、鍵取り替え確認メッセージ204の送信前の受信のために新たな鍵をインストールしてもよく、鍵取り替え確認メッセージ204の送信後まで、送信のための新たな鍵の使用を遅らせてもよい。無線デバイス300が要求側104として動作する場合、要求側104は、鍵取り替え確認メッセージ204の送信後の所定の期間まで、受信のための古い鍵及び受信のための新たな鍵の使用をサポートし続ける。
【００２９】
或る実施例では、受信のために新たな鍵及び古い鍵の双方の使用をサポートする場合、無線デバイス300は、受信したユニキャストパケットの鍵IDフィールドを読み取り、鍵IDフィールドから古い鍵又は新たな鍵のいずれかを識別してもよい。識別された鍵は、受信したユニキャストパケットを解読するために使用されてもよい。
【００３０】
或る実施例では、メモリ306は、１つ以上の非ユニキャスト（例えば、ブロードキャスト又はマルチキャスト）鍵のための非ユニキャスト鍵ID空間を含んでもよい。これらの実施例では、無線デバイス300は、受信したパケットの媒体アクセス制御（MAC：media-access  control）アドレスに基づいて、受信したパケットがユニキャストパケットであるか非ユニキャストパケットであるかを判定してもよい。非ユニキャストパケットは、１人より多くの受信者にアドレス指定されたパケットである。ユニキャストパケットは、１人の受信者にアドレス指定されたパケットである。無線デバイス300は、受信したパケットがユニキャストパケットである場合にユニキャスト鍵（例えば、２つ１組の鍵）の１つを識別するために、鍵IDフィールドに基づいてユニキャスト鍵ID空間をインデックス付けしてもよい。無線デバイス300は、受信したパケットが非ユニキャストパケットである場合に非ユニキャスト鍵（すなわち、グループ鍵）の１つを識別するために、鍵IDフィールドに基づいて非ユニキャスト鍵ID空間をインデックス付けしてもよい。これらの実施例では、受信したパケットのMACアドレスは、パケットがユニキャストパケットであるか非ユニキャストパケットであるかを示してもよい。パケットがユニキャストパケットである場合、ユニキャスト鍵空間からの鍵は、受信したパケットを解読するために使用されてもよい。パケットが非ユニキャストパケットである場合、非ユニキャスト鍵空間からの鍵は、受信したパケットを解読するために使用されてもよい。特定の鍵は、鍵IDに基づいて鍵空間から選択されてもよい。これらの実施例の幾つかでは、ユニキャストパケットの鍵IDは、例えばゼロ又は１でもよく、ユニキャスト鍵空間で鍵（例えば、古い鍵又は新たな鍵）をインデックス付けするために使用されてもよい。非ユニキャストパケットの鍵IDは、例えばゼロ、１、２又は３でもよく、非ユニキャスト鍵空間で複数の鍵のうち１つをインデックス付けするために使用されてもよい。MACアドレスの使用は、どの鍵空間をインデックス付けするかを判定するために使用されてもよい。例えば、非ユニキャストパケットは、ブロードキャスト又はマルチキャストパケットでもよい。これらの実施例では、通信がIEEE802.11標準の１つに従って実行される場合、IEEE802.11での０、１、２及び３の鍵IDの値の現在の定義が変更されてもよい。
【００３１】
或る別の実施例では、受信したユニキャストパケットの新規鍵ビットは、受信したユニキャストパケットを解読するために鍵を切り替えるか否かを判定するために読み取られてもよい。これらの別の実施例では、認証側102及び要求側104は、新たな鍵で暗号化されるユニキャストパケットを送信する場合に、新規鍵ビットを設定してもよい。これらの別の実施例では、鍵IDの値が規定される方法を変更するのではなく、現在又は通常の鍵IDの規定が使用されてもよい。これらの実施例では、新規鍵ビットは、鍵を切り替えることを受信機に示すトグル（toggle）として機能してもよい。これらの実施例では、通信は、IEEE802.11標準の１つに従って実行されてもよく、新規鍵ビットのために予約ビット（未使用ビット）が使用されてもよい。802.11における０、１、２及び３の鍵IDの値の現在の規定も使用されてもよい。これらの実施例では、新規鍵ビットが鍵を切り替えるために使用されるため、ゼロの鍵IDの値が全てのユニキャストパケットに使用されてもよく、１、２及び３の鍵IDの値が非ユニキャストパケットに使用されてもよい。
【００３２】
或る実施例では、認証側102がメッセージ１において拡張鍵IDフィールドを１に設定し、要求側104が拡張鍵IDの使用をサポートする場合、要求側104は、拡張鍵ID空間の使用を交渉してもよい。これらの実施例では、要求側104は、交渉されている鍵でパケットを受信するために使用する鍵IDを選択してもよく、メッセージ２の鍵IDフィールドにその値を指定してもよい。これらの実施例では、認証側102がメッセージ１において拡張鍵IDフィールドをゼロに設定した場合、要求側104は、メッセージ２に鍵ID  KDE（Key  Data  Encapsulation）を含めない。
【００３３】
認証側102が拡張鍵IDの使用をサポートしない場合、鍵ID  KDEを無視してもよい。要求側104がゼロに設定されたメッセージ２のRSN  IE拡張鍵IDフィールド又は存在しないKDEにより伝達されてもよい拡張鍵IDをサポートしない場合、認証側102は、排他的なユニキャスト鍵IDとしてゼロを使用し続けてもよい。そうでない場合、認証側102は、４ウェイ・ハンドシェイク103により交渉されている一時鍵（TK：temporary  key）を使用して、要求側104へのユニキャスト送信のために鍵IDを使用してもよい。認証側102はまた、交渉されているTKにより保護されたユニキャスト送信を受信するために使用する鍵IDを割り当ててもよく、これをメッセージ３の鍵ID  KDEに含めてもよい。認証側102はまた、メッセージ３で要求側104の値を繰り返してもよい。
【００３４】
メッセージ３において認証側102が鍵ID  KDEの存在により拡張鍵IDに対するサポートに合意したことを伝達した場合、要求側104は、認証側102の提案された鍵IDが、要求側104がメッセージ２で提案した値であることを検査してもよい。そうでない場合、４ウェイ・ハンドシェイク103が失敗してもよい。メッセージ３において認証102が鍵ID  KDEの存在により拡張鍵IDをサポートしないことを伝達した場合、要求側104は、交渉されているTKを用いて、要求側104が保護するユニキャストパケットにおいて提案された鍵IDを使用してもよい。要求側104は、メッセージ４においてKDEを認証側102に戻してもよい。これらの実施例では、認証側102は、メッセージ４がメッセージ３で送信されたKDEを含むことを検査してもよい。そうでない場合、４ウェイ・ハンドシェイク103が失敗してもよい。
【００３５】
これらの実施例では、有効なメッセージ２の受信に応じて、認証側102は、選択された鍵IDでの受信のために新たな鍵をインストールしてもよく、鍵ID  KDEで新たな鍵IDを示すメッセージ３を送信してもよい。有効なメッセージ３を受信すると、要求側104は、メッセージ３で受信した鍵IDを使用して受信するために新たな鍵をインストールしてもよく、メッセージ４を送信してもよい。認証側102は、新たな鍵を使用してパケット（例えば、MPDU）を待ち行列に入れ始めてもよい。
【００３６】
要求側104は、メッセージ４の送信後の所定の期間に古い鍵を使用したパケットの受信をサポートし続けてもよい。メッセージ４を受信すると、認証側102は、新たな鍵を使用してパケットを待ち行列に入れ始めてもよく、所定の期間に古い鍵を使用したパケットの受信をサポートし続けてもよい。或る実施例では、所定の期間は約60秒でもよい。
【００３７】
或る別の実施例では、第４のEAPメッセージの後に、要求側104及び認証側102の双方は、双方のデバイスの最大遅延より大きい時間遅延（例えば、しばしば数秒のオーダ）を有する切り替えタイマを開始してもよい。この期間の間に、要求側104及び認証側102の双方は、古い鍵を使用し続ける。切り替えタイマの時間遅延の後に、要求側104及び認証側102の双方は新たな鍵を使用して送信してもよく、少なくとも所定の期間の受信のために古い鍵及び新たな鍵の双方を使用し続けてもよい。
【００３８】
無線デバイス300は、複数の別個の機能要素を有するものとして示されているが、１つ以上の機能要素は結合されてもよく、デジタルシグナルプロセッサ（DSP：digital  signal  processors）及び／又は他のハードウェア要素を含む処理要素のようなソフトウェア構成の要素の組み合わせにより実現されてもよい。例えば、或る要素は、１つ以上のマイクロプロセッサ、DSP、特定用途向け集積回路（ASIC：application  specific  integrated  circuit）、無線周波数集積回路（RFIC：radio-frequency  integrated  circuit）、及びここに記載の機能を少なくとも実行する様々なハードウェア及び論理回路の組み合わせを有してもよい。或る実施例では、無線デバイス300の機能要素は、１つ以上の処理要素で実行する１つ以上の処理を示してもよい。
【００３９】
或る実施例では、無線デバイス300は、マルチキャリア通信チャネルで直交周波数分割多重（OFDM：orthogonal  frequency  division  multiplexed）通信信号を受信するように構成されてもよい。OFDM信号は、複数の直交サブキャリアを有してもよい。これらのマルチキャリアの実施例の幾つかでは、無線デバイス300は、WiFi（Wireless  Fidelity）デバイスを含み、無線アクセスポイント（AP：access  point）、基地局又は移動局のような無線ローカルエリアネットワーク（WLAN：wireless  local  area  network）通信局でもよい。或る実施例では、無線デバイス300は、2.4GHz周波数帯域、5GHz周波数帯域又は60GHz周波数帯域内で無線通信してもよい。或るブロードバンドのマルチキャリアの実施例では、無線デバイス300は、WiMAX（Worldwide  Interoperability  for  Microwave  Access）通信局のようなブロードバンド無線アクセス（BWA：broadband  wireless  access）ネットワーク通信局の一部でもよい。或る他のブロードバンドのマルチキャリアの実施例では、無線デバイス300は、3GPP（3rd  Generation  Partnership  Project）のUTRAN（Universal  Terrestrial  Radio  Access  Network）LTE（Long-Term-Evolution）通信局でもよい。これらのブロードバンドのマルチキャリアの実施例では、無線デバイス300は、直交周波数分割多元アクセス（OFDMA：orthogonal  frequency  division  multiple access）技術に従って通信するように構成されてもよい。
【００４０】
或る実施例では、無線デバイス300は、IEEE802.11-20007及び／又はIEEE802.11(n)標準及び／又はWLANの提案された仕様を含み、IEEE（Institute  of  Electrical  and  Electronics  Engineers）標準のような特定の通信標準に従って通信するように構成されてもよい。しかし、実施例の範囲はこの点に限定されず、無線デバイス300はまた、他の技術及び標準に従って通信を送信及び／又は受信するのに適合してもよい。或る実施例では、無線デバイス300は、無線メトロポリタンエリアネットワーク（WMAN：wireless  metropolitan  area  network）のIEEE802.16-2004、IEEE802.16(e)及び／又はIEEE802.16(m)標準（その変更及び進展を含む）に従って通信するように構成されてもよい。しかし、実施例の範囲はこの点に限定されず、無線デバイス300はまた、他の技術及び標準に従って通信を送信及び／又は受信するのに適合してもよい。或る実施例では、無線デバイス300は、UTRAN（Universal  Terrestrial  Radio  Access  Network）LTE通信標準に従って通信するように構成されてもよい。IEEE802.11及びIEEE802.16標準に関する更なる情報については、“IEEE  Standards  for  Information  Technology-Telecommunications  and  Information  Exchange  between  Systems”  −  Local  Area  Networks  −  Specific  Requirements  −  Part  11“Wireless  LAN  Medium  Access  Control  (MAC)  and  Physical  Layer  (PHY),  ISO/IEC  8802-11:  1999”及びMetropolitan  Area  Networks  −  Specific  Requirements  −  Part  16:“Air  Interface  for  Fixed  Broadband  Wireless  Access  Systems”,May  2005並びに関連する修正／バージョンを参照のこと。UTRAN  LTE標準に関する更なる情報については、3rd  Generation  Partnership  Project  (3GPP)  standards  for  UTRAN-LTE,  release  8,  March  2008（その変更及び進展を含む）を参照のこと。
【００４１】
或る他の実施例では、無線デバイス300は、スペクトル拡散変調（例えば、直接拡散符号分割多元アクセス（DS-CDMA：direct  sequence  code  division  multiple  access）及び／又は周波数ホッピング符号分割多元アクセス（FH-CDMA：frequency  hopping  code  division  multiple  access）、時間分割多重（TDM：time-division  multiplexing）変調及び／又は周波数分割多重（FDM：frequency-division  multiplexing）変調）のような１つ以上の他の変調技術を使用して送信された信号を通信するように構成されてもよい。しかし、実施例の範囲はこの点に限定されない。
【００４２】
或る実施例では、無線デバイス300は、パーソナルデジタルアシスタント（PDA：personal  digital  assistant）、無線通信機能を備えたラップトップ若しくはポータブルコンピュータ、ウェブタブレット、無線電話、無線ヘッドセット、ページャ、インスタントメッセージングデバイス、デジタルカメラ、アクセスポイント、テレビ、医療デバイス（例えば、心拍数モニタ、血圧モニタ等）、又は無線で情報を受信及び／又は送信し得る他のデバイスのような、ポータブル無線通信デバイスの一部でもよい。
【００４３】
或る実施例では、無線デバイス300は、通信のために２つ以上のアンテナ301を使用してもよい。アンテナ301は、例えば、ダイポールアンテナ、モノポールアンテナ、パッチアンテナ、ループアンテナ、マイクロストリップアンテナ、又はRF信号の送信に適した他の種類のアンテナを含み、指向性又は無指向性アンテナを有してもよい。或る実施例では、２つ以上のアンテナ301の代わりに、複数の開口を備えた単一のアンテナが使用されてもよい。これらの実施例では、各開口は、別のアンテナと考えられてもよい。或るMIMOの実施例では、アンテナ301は、空間ダイバーシチ及び通信局間で生じ得る異なるチャネル特性を利用するために事実上分離されてもよい。
【００４４】
図４は、或る実施例による鍵取り替え中にパケットを受信する手順である。手順400は、鍵取り替え動作の間に、無線デバイス300（図３）のような無線デバイスにより実行されてもよい。或る実施例では、手順400は、例えばビデオストリーミングセッション中に、要求側104（図１）により実行されてもよい。或る実施例では、要求側104は、ストリーミングされたビデオを有するユニキャストパケットを受信してもよい。ユニキャストパケットは、第１の鍵で暗号化されてもよい。要求側104は、鍵取り替え動作を開始するために鍵取り替え開始メッセージ201（図２）を受信してもよく、認証側102（図１）への鍵取り替え確認メッセージ204（図２）の送信前の受信のために第２の鍵をインストールしてもよい。
【００４５】
或る実施例では、動作402において、要求側104は、受信したユニキャストパケットの鍵IDフィールドを読み取り、受信したユニキャストパケットを解読するためにユニキャスト鍵ID空間に格納された新たな鍵を使用するか古い鍵を使用するかを判定してもよい。或いは、動作402において、要求側104は、受信したユニキャストパケットの新規鍵ビットを読み取り、受信したユニキャストパケットを解読するためにユニキャスト鍵ID空間に格納された新たな鍵又は古い鍵の間を切り替えるか否かを判定してもよい。
【００４６】
或る実施例では、動作404において、要求側104は、受信したパケットのMACアドレスを読み取り、受信したパケットがユニキャストパケットであるか非ユニキャストパケットであるかを判定してもよい。パケットが非ユニキャストパケットである場合、動作410が実行されてもよい。パケットがユニキャストパケットである場合、動作408が実行されてもよい。
【００４７】
動作408において、要求側104は、ユニキャスト鍵の１つを識別するために、鍵IDフィールドに基づいてユニキャスト鍵ID空間をインデックス付けしてもよい。動作410において、要求側104は、非ユニキャスト鍵の１つを識別するために、鍵IDフィールドに基づいて非ユニキャスト鍵ID空間をインデックス付けしてもよい。動作412において、パケットは、動作408又は410で判定された鍵で解読されてもよい。
【００４８】
要約は、読者が技術的開示の性質及び要旨を確認することを可能にすることを要約に求める37  C.F.R.  Section  1.72(b)に従うために提供されている。これは請求項の範囲又は意味を解釈するために使用されないという認識で提示されている。以下の請求項は、詳細な説明に援用され、各請求項は別々の実施例として独立する。
【図１】
0005452732.tif 000002
【図２】
0005452732.tif 000003
【図３】
0005452732.tif 000004
【図４】
0005452732.tif 000005