特許 5755720 高スループット無線通信のための低減したパケットロスを備えた鍵取り替えのための無線デバイス及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5755720

(24)【登録日】2015年6月5日

(45)【発行日】2015年7月29日

(54)【発明の名称】高スループット無線通信のための低減したパケットロスを備えた鍵取り替えのための無線デバイス及び方法

(51)【国際特許分類】

   H04W 12/04 20090101AFI20150709BHJP

【ＦＩ】

   H04W12/04

【請求項の数】18

【全頁数】17

(21)【出願番号】特願2013-270720(P2013-270720)

(22)【出願日】2013年12月27日

(62)【分割の表示】特願2012-544563(P2012-544563)の分割

【原出願日】2010年11月29日

(65)【公開番号】特開2014-57380(P2014-57380A)

(43)【公開日】2014年3月27日

【審査請求日】2014年1月23日

(31)【優先権主張番号】12/643,009

(32)【優先日】2009年12月21日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】593096712

【氏名又は名称】インテル コーポレイション

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】チイ，エミリー エイチ．

(72)【発明者】

【氏名】リオンダス，ヘルベルト

(72)【発明者】

【氏名】ウォーカー，ジェシー アール．

(72)【発明者】

【氏名】ジャルフォン，マルク

(72)【発明者】

【氏名】ステイシー，ロバート ジェイ．

【審査官】 古市 徹

(56)【参考文献】

【文献】 特表２０１２−５３１８１７（ＪＰ，Ａ）

【文献】 米国特許第０７２４５７２４（ＵＳ，Ｂ１）

【文献】 特開２００７−１０４３１０（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４ − ７／２６

Ｈ０４Ｗ ４／００ − ９９／００

(57)【特許請求の範囲】

【請求項1】

処理回路とメモリと物理レイヤ回路とを有する無線通信デバイスであって、
４ウェイ・ハンドシェイクの第１のメッセージで、前記デバイスがユニキャスト通信に拡張鍵IDの値の使用をサポートするか否かを示すために、0又は1を含む拡張鍵IDフィールドを備えたRSN IE（robust security network information element）を送信し、
前記４ウェイ・ハンドシェイクの第２のメッセージで、鍵ID KDE（key ID key data encapsulation）を受信し、
前記４ウェイ・ハンドシェイクの第３のメッセージで、前記拡張鍵IDを使用する合意を示すために、前記鍵ID KDEを送信し、
鍵取り替え確認メッセージの受信の前の受信のための新たな鍵をインストールする
ように構成される無線通信デバイス。

【請求項2】

前記メモリは、ユニキャストトラヒックを有するパケットを暗号化及び解読する際に使用される複数のユニキャスト鍵を格納するように構成される、請求項１に記載の無線通信デバイス。

【請求項3】

前記複数のユニキャスト鍵は、前の４ウェイ・ハンドシェイクから導かれた鍵を含む、請求項２に記載の無線通信デバイス。

【請求項4】

前記４ウェイ・ハンドシェイクは、EAPOL（Extensible Authentication Protocol over Local area network）鍵フレームを有する、請求項１に記載の無線通信デバイス。

【請求項5】

少なくとも２つのアンテナを更に有する、請求項１に記載の無線通信デバイス。

【請求項6】

４ウェイ・ハンドシェイクの第１のメッセージで、デバイスがユニキャスト通信に拡張鍵IDの値の使用をサポートするか否かを示すために、0又は1を含む拡張鍵IDフィールドを備えたRSN IE（robust security network information element）を送信するステップと、
前記４ウェイ・ハンドシェイクの第２のメッセージで、鍵ID KDE（key ID key data encapsulation）を受信するステップと、
前記４ウェイ・ハンドシェイクの第３のメッセージで、前記拡張鍵IDを使用する合意を示すために、前記鍵ID KDEを送信するステップと、
鍵取り替え確認メッセージの受信の前の受信のための新たな鍵をインストールするステップと
を有する無線通信方法。

【請求項7】

ユニキャストトラヒックを有するパケットを暗号化及び解読する際に使用される複数のユニキャスト鍵を格納するステップを更に有する、請求項６に記載の方法。

【請求項8】

前記複数のユニキャスト鍵は、前の４ウェイ・ハンドシェイクから導かれた鍵を含む、請求項７に記載の方法。

【請求項9】

前記４ウェイ・ハンドシェイクは、EAPOL（Extensible Authentication Protocol over Local area network）鍵フレームを有する、請求項６に記載の方法。

【請求項10】

処理回路とメモリと物理レイヤ回路とを有する第１の無線通信デバイスであって、
４ウェイ・ハンドシェイクの第１のメッセージで、第２の無線通信デバイスから、前記第２のデバイスがユニキャスト通信に拡張鍵IDの値の使用をサポートするか否かを示すために、0又は1を含む拡張鍵IDフィールドを備えたRSN IE（robust security network information element）を受信し、
前記４ウェイ・ハンドシェイクの第２のメッセージで、鍵ID KDE（key ID key data encapsulation）を前記第２の無線通信デバイスに送信し、
前記４ウェイ・ハンドシェイクの第３のメッセージで、前記第２の無線通信デバイスから、前記拡張鍵IDを使用する合意を示すために、前記鍵ID KDEを受信し、
鍵取り替え確認メッセージの受信の前の受信のための新たな鍵をインストールする
ように構成される無線通信デバイス。

【請求項11】

前記メモリは、ユニキャストトラヒックを有するパケットを暗号化及び解読する際に使用される複数のユニキャスト鍵を格納するように構成される、請求項１０に記載の第１の無線通信デバイス。

【請求項12】

前記複数のユニキャスト鍵は、前の４ウェイ・ハンドシェイクから導かれた鍵を含む、請求項１１に記載の第１の無線通信デバイス。

【請求項13】

前記４ウェイ・ハンドシェイクは、EAPOL（Extensible Authentication Protocol over Local area network）鍵フレームを有する、請求項１０に記載の第１の無線通信デバイス。

【請求項14】

少なくとも２つのアンテナを更に有する、請求項１０に記載の第１の無線通信デバイス。

【請求項15】

４ウェイ・ハンドシェイクの第１のメッセージで、デバイスがユニキャスト通信に拡張鍵IDの値の使用をサポートするか否かを示すために、0又は1を含む拡張鍵IDフィールドを備えたRSN IE（robust security network information element）を受信するステップと、
前記４ウェイ・ハンドシェイクの第２のメッセージで、鍵ID KDE（key ID key data encapsulation）を送信するステップと、
前記４ウェイ・ハンドシェイクの第３のメッセージで、前記拡張鍵IDを使用する合意を示すために、前記鍵ID KDEを受信するステップと、
鍵取り替え確認メッセージの受信の前の受信のための新たな鍵をインストールするステップと
を有する無線通信方法。

【請求項16】

ユニキャストトラヒックを有するパケットを暗号化及び解読する際に使用される複数のユニキャスト鍵を格納するステップを更に有する、請求項１５に記載の方法。

【請求項17】

前記複数のユニキャスト鍵は、前の４ウェイ・ハンドシェイクから導かれた鍵を含む、請求項１６に記載の方法。

【請求項18】

前記４ウェイ・ハンドシェイクは、EAPOL（Extensible Authentication Protocol over Local area network）鍵フレームを有する、請求項１５に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

実施例は、無線通信に関する。或る実施例は、無線ネットワークでの鍵取り替え（rekeying）動作に関する。或る実施例は、IEEE802.11標準の１つによる鍵取り替え動作のための４ウェイ・ハンドシェイク（four-way handshake）に関する。或る実施例は高スループットの無線ネットワークでのビデオストリーミングに関する。

【背景技術】

【0002】

多くの無線ネットワークでは、パケットは、セキュリティを提供するために、暗号化鍵で暗号化されている。特定の条件が発生すると、暗号化鍵は更新され、新たな鍵が生成される。

【発明の概要】

【発明が解決しようとする課題】

【0003】

鍵取り替え処理の間に、局が異なる鍵を使用している短い期間が存在する可能性がある。その結果、幾つかのパケットは解読できず、破棄される必要がある。このパケットのロスは、特にビデオストリーミングのような非常に高いスループットの状況で問題になる。この理由は、ビデオでの分断を生じる可能性があるからである。このパケットロスはまた、伝送制御プロトコル（TCP：transmission control protocol）のスロースタートアルゴリズムに影響を与える可能性がある。

【0004】

従って、非常に高いスループットの無線通信に適した低減したパケットロスを備えた鍵取り替えのための無線デバイス及び方法の一般的なニーズが存在する。

【図面の簡単な説明】

【0005】

【図1】或る実施例による無線通信ネットワーク

【図2】或る実施例による低減したパケットロスを備えた鍵取り替えの手順

【図3】或る実施例による無線デバイスのブロック図

【図4】或る実施例による鍵取り替え中にパケットを受信する手順を示すフローチャート

【発明を実施するための形態】

【0006】

以下の説明及び図面は、当業者が特定の実施例を実行可能にできるように、特定の実施例を十分に示している。他の実施例は、構造的、論理的、電気的、処理的及び他の変更を組み込んでもよい。或る実施例の部分及び特徴は、他の実施例の部分及び特徴に含まれてもよく、代用されてもよい。請求項に記載する実施例は、これらの請求項の全ての利用可能な均等物を含む。

【0007】

図１は、或る実施例による無線通信ネットワークである。無線通信ネットワーク100は、認証側102及び要求側104のような２つ以上の無線デバイスを含んでもよい。認証側102及び要求側104は、IEEE802.11通信標準の１つのような１つ以上の無線通信技術に従って無線チャネルを通じて通信してもよい。或る実施例では、認証側102は、アクセスポイント（AP）でもよく、要求側104は、移動局（STA）でもよい。

【0008】

認証側102及び要求側104は、暗号化鍵を使用して暗号化されたパケットを通信してもよい。暗号化鍵は、認証側102と要求側104との間の成功した認証処理の間に生成されてもよい。暗号化鍵は、認証側102と要求側104との間の次の鍵取り替え処理を通じて更新されてもよい。鍵取り替え処理は、以下に詳細に説明する４ウェイ・ハンドシェイクを含んでもよい。

【0009】

実施例によれば、鍵取り替え動作の間のパケットロスの低減を支援するために、認証側102は、鍵取り替え確認メッセージの受信の前の受信のために新たな鍵をインストールしてもよい。認証側102はまた、鍵取り替え確認メッセージの受信後まで、送信のための新たな鍵の使用を遅らせてもよい。実施例によれば、要求側104は、鍵取り替え確認メッセージの送信前の受信のために新たな鍵をインストールしてもよく、鍵取り替え確認メッセージの送信後まで、送信のための新たな鍵の使用を遅らせてもよい。認証側102及び要求側104の双方による受信のための新たな鍵の早期のインストールにより、新たな鍵及び古い鍵の双方が受信したパケットを解読する際の使用に同時に有効（アクティブ）になることを可能にする。このように、鍵取り替え動作の間のパケットロスが低減され得る。これらの実施例について、以下に詳細に説明する。

【0010】

或る実施例では、鍵取り替え処理は、４ウェイ・ハンドシェイク103の一部でもよく、鍵取り替え確認メッセージは、４ウェイ・ハンドシェイクの第４（４番目）のメッセージでもよい。或る実施例では、新たな鍵は、４ウェイ・ハンドシェイクの間に交換された情報から要求側104及び認証側102の双方により生成された非対称鍵でもよい。これらの実施例について、以下に詳細に説明する。

【0011】

通常では、新たな鍵は、鍵取り替え確認メッセージの受信後まで、受信のために認証側102によりインストール及び使用されない。通常では、新たな鍵は、鍵取り替え確認メッセージの送信後まで、受信のために要求側104によりインストール及び使用されない。これらのイベントは同期していないため、鍵取り替え処理の完了前に受信した幾つかのパケットは、適切に解読できない可能性がある。或る実施例によれば、受信のための新たな鍵の早期のインストール及び使用と、受信のための古い鍵の継続したサポートとにより、古い鍵又は新たな鍵のいずれかで暗号化されたパケットが適切に解読されることが可能になる。通常の鍵取り替え技術とは異なり、受信のための２つ以上の鍵が同時に有効になってもよく、受信したパケットを解読するために使用されてもよい。

【0012】

IEEE（Institute for Electrical and Electronic Engineer）の802.11iドラフト標準は、移動局とその関連するアクセスポイントとの間で相互認証及びユニキャストグループ鍵を確立するプロトコル（802.11iプロトコル）を規定している。802.11iプロトコルは、セッションの有効性（liveliness）を確認し、ユニキャスト鍵を確立してグループ鍵を確立するために、４ウェイ・ハンドシェイクを使用する。或る実施例は、鍵取り替え中に生じ得るパケットロスを低減するために、IEEE802.11の４ウェイ・ハンドシェイクの上の階層になってもよい。

【0013】

或る実施例では、認証側102は、アクセスポイントであり、要求側104は、移動局である。或る実施例では、アクセスポイント及び移動局は、IEEE802.11通信標準又はドラフト標準の１つに従って通信してもよい。或る実施例では、鍵取り替え動作は、ユニキャストパケットがアクセスポイントから移動局にストリーミングされるビデオストリーミングセッションを含む通信セッションの間に実行されてもよい。或る実施例では認証側102はアクセスポイントとして記載され、或る実施例では要求側104は移動局として記載されるが、実施例の範囲はこの点に限定されない。或る別の実施例では、認証側は移動局でもよく、要求側はアクセスポイントでもよい。他の別の実施例では、認証側及び要求側の双方が移動局でもよい。

【0014】

或る実施例では、鍵生成は、既存の鍵の差し迫った存続の終了により開始されてもよい。鍵は、所定の期間（例えば、12時間）の後に終了してもよい。鍵生成は、パケット番号の差し迫った消耗により開始されてもよい。各パケットは、リプレイ攻撃を検出するために、パケット番号を割り当てられる。パケット番号は、所与の鍵を使用して暗号化されたパケット毎に固有のものである。パケット番号空間が消耗する場合（すなわち、全てのパケット番号が割り当てられた場合）、新たな鍵が生成される。鍵取り替えは、セキュリティアソシエーション（security association）が壊れることを回避するために、これらのイベントのいずれかが生じる前に実行されてもよい。

【0015】

図２は、或る実施例による低減したパケットロスを備えた鍵取り替えの手順を示している。手順200において、要求側104及び認証側102は、確立されたセキュリティアソシエーションを有してもよく、１つ以上の暗号化鍵を使用してパケットを交換してもよい。鍵取り替えイベントの発生時に、動作222において、認証側102は、鍵取り替え処理を開始するために、鍵取り替え開始メッセージ201を送信してもよい。鍵取り替え開始メッセージ201の受信に応じて、動作242において、要求側104は、鍵取り替え開始応答メッセージ202を認証側102に送信してもよい。動作224において、認証側102は、鍵取り替え開始応答メッセージ202を受信してもよい。鍵取り替え開始応答メッセージ202の受信に応じて、認証側102は、受信のために新たな鍵を生成してインストールしてもよい。鍵取り替え開始メッセージ201で送信されて鍵取り替え開始応答メッセージ202で受信した情報は、新たな鍵を生成するために使用されてもよい。

【0016】

動作226において、認証側102は、鍵取り替え開始応答メッセージ202に応じて、応答確認メッセージ203を送信する。動作244において、要求側104は、応答確認メッセージ203を受信し、鍵取り替え確認メッセージ204の送信前の受信のために新たな鍵を生成してインストールしてもよい。応答確認メッセージ203は、交換が介入者攻撃（man-in-the-middle attack）を受けていないことを要求側104に示してもよい。要求側104及び認証側102の双方は、交換された情報のため、同じ新たな鍵を生成することができる。

【0017】

これらの実施例では、認証側102は、応答確認メッセージ203の送信前の受信のために新たな鍵をインストールしてもよく、要求側104は、鍵取り替え確認メッセージ204の送信前の受信のために新たな鍵をインストールしてもよい。このように、新たな鍵及び古い鍵の双方が受信のために使用されてもよい。これらの実施例について以下に詳細に説明し得る。

【0018】

或る実施例では、動作224において受信のために新たな鍵をインストールした後に、動作228において、送信のために古い鍵を使用し続けつつ、受信のために新たな鍵又は古い鍵のいずれかを使用してもよい。動作244において、要求側104は、鍵取り替え確認メッセージ204の送信前の受信のために新たな鍵をインストールしてもよく、鍵取り替え確認メッセージ204の送信後まで、送信のための新たな鍵の使用を遅らせてもよい。

【0019】

動作228の間に、認証側102は、鍵取り替え確認メッセージ204の受信前から始まり、鍵取り替え確認メッセージ204の受信後の所定の期間まで、要求側104から受信したパケットを解読するために、新たな鍵又は古い鍵のいずれかを使用してもよい。認証側102はまた、鍵取り替え確認メッセージ204の受信後まで、要求側104に送信するためのパケットを暗号化するために新たな鍵の使用を遅らせてもよい。或る実施例では、認証側102は、鍵取り替え確認メッセージ204の受信直後まで又は鍵取り替え確認メッセージ204の受信後の所定の期間まで、送信のためのパケットを暗号化するために新たな鍵の使用を遅らせてもよい。

【0020】

或る実施例では、要求側104は、動作246における鍵取り替え確認メッセージ204の送信直後まで又は動作246における鍵取り替え確認メッセージ204の送信後の所定の期間まで、動作248における送信のための新たな鍵をインストール及び／又は使用することを遅らせてもよい。或る別の実施例では、要求側104は、応答確認メッセージ203の受信後の所定の期間まで、送信のための新たな鍵の使用を遅らせてもよい。

【0021】

或る実施例では、鍵取り替え確認メッセージ204の受信前の受信のために動作224において新たな鍵をインストールした後に、認証側102は、受信したユニキャストパケットで伝達される鍵識別子に基づいて、受信したユニキャストパケットを解読するために新たな鍵又は古い鍵のいずれかを選択してもよい。これらの実施例では、認証側102は、鍵取り替え確認メッセージ204の受信まで又は鍵取り替え確認メッセージ204の受信後の所定の期間まで、古い鍵での受信をサポートしてもよい。これらの実施例では、要求側104は、動作246における鍵取り替え確認メッセージ204の送信まで又は動作246における鍵取り替え確認メッセージ204の送信後の所定の期間まで、古い鍵での受信をサポートしてもよい。或る実施例では、所定の期間は、約60秒でもよいが、これは要件ではない。

【0022】

動作232において、認証側102は、新たな鍵で暗号化されたパケットを送信してもよく、古い鍵及び新たな鍵でのパケットの受信をサポートしてもよい。同様に、動作250において、要求側104は、新たな鍵で暗号化されたパケットを送信してもよく、古い鍵及び新たな鍵でのパケットの受信をサポートしてもよい。

【0023】

或る実施例では、鍵取り替え開始メッセージ201は４ウェイ・ハンドシェイク103のメッセージ１（M1：Message 1）でもよく、鍵取り替え開始応答メッセージ202は４ウェイ・ハンドシェイク103のメッセージ２（M2：Message 2）でもよく、応答確認メッセージ203は４ウェイ・ハンドシェイク103のメッセージ３（M3：Message 3）でもよく、鍵取り替え確認メッセージ204は４ウェイ・ハンドシェイク103のメッセージ４（M4：Message 4）でもよい。これらの実施例では、認証側102は、メッセージ２の受信後且つメッセージ３の送信前に受信したパケットを解読する際に使用するために新たな鍵をインストールしてもよい。認証側102はまた、メッセージ４の受信後まで、送信のためのパケットを暗号化するために新たな鍵の使用を遅らせてもよい。要求側104は、メッセージ３の受信後且つメッセージ４の送信前に受信したパケットを解読する際に使用するために新たな鍵をインストールしてもよい。要求側104は、メッセージ４の送信の直後又はメッセージ４の送信後の所定の期間まで、送信のためのパケットを暗号化する際に使用するための新たな鍵のインストールを遅らせてもよい。受信のための２つの鍵の同時使用をサポートする受信の場合とは異なり、新たな鍵が送信のためにインストールされた場合、もはや古い鍵は送信のためには使用されない。

【0024】

動作234において、４ウェイ・ハンドシェイク103が完了しなかった場合、認証側102は、新たな鍵をアンインストールしてもよい。動作252において、４ウェイ・ハンドシェイク103が完了しなかった場合、要求側104は、新たな鍵をアンインストールしてもよい。これらの実施例では、４ウェイ・ハンドシェイク103が完了しなかった場合、認証側102及び要求側104は、送信及び受信の双方について新たな鍵の更なる使用を抑制してもよい。認証側102は、鍵取り替え確認メッセージ204を受信したときに４ウェイ・ハンドシェイク103の成功を仮定し、肯定応答（ACK：acknowledgement）206を要求側104に送信してもよい。要求側104は、認証側102からの肯定応答206に受信に基づいて、４ウェイ・ハンドシェイク103の成功を仮定してもよい。

【0025】

或る実施例では、４ウェイ・ハンドシェイク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鍵フレームでもよい。

【0026】

或る通常の鍵取り替え処理では、前の鍵と同じ鍵IDでの新たな鍵のインストールは、前の鍵が新たな鍵により置換されたときに削除されることを生じる。或る実施例では、２つの鍵IDが使用されてもよく、各ハンドシェイクは、２つの鍵IDの間を交互にしてもよい。例えば、第１のハンドシェイクは、第１の鍵ID（例えば、鍵ID=0）で行われてもよく、次のハンドシェイクは、第２の鍵ID（例えば、鍵ID=1）で行われてもよい。このように、２つの鍵がインストールされてもよく、１つの鍵から他の鍵へのスムーズなハンドオーバを可能にしてもよい（例えば、受信のための鍵がインストールされ、その後、鍵が送信のために使用される）。次のハンドシェイク（例えば、第３のハンドシェイク）は、鍵ID=0を使用して古い鍵を置換した第１の鍵ID（例えば、鍵ID=0）で行われてもよい。

【0027】

図３は、或る実施例による無線デバイスのブロック図である。無線デバイス300は、要求側104（図１）又は認証側102（図１）のいずれかとしての使用に適してもよい。無線デバイス300は、物理レイヤ回路302と、処理回路304と、メモリ306とを含んでもよい。実施例によれば、処理回路304は、鍵取り替え動作を実行してもよく、メモリ306は、ユニキャストトラヒックを有するパケットを暗号化及び解読する際に使用するために少なくとも２つのユニキャスト鍵を格納するためのユニキャスト鍵ID空間を有してもよい。無線デバイス300が認証側102として動作する場合、処理回路304は、鍵取り替え確認メッセージ204の受信前の受信のために新たな鍵をインストールしてもよく、鍵取り替え確認メッセージ204の受信後まで、送信のための新たな鍵の使用を遅らせてもよい。無線デバイス300が認証側102として動作する場合、認証側102は、鍵取り替え確認メッセージ204の受信後の所定の期間に、受信のための古い鍵及び受信のための新たな鍵の使用をサポートし続ける。

【0028】

これらの実施例では、無線デバイス300が要求側104として動作する場合、処理回路304は、鍵取り替え確認メッセージ204の送信前の受信のために新たな鍵をインストールしてもよく、鍵取り替え確認メッセージ204の送信後まで、送信のための新たな鍵の使用を遅らせてもよい。無線デバイス300が要求側104として動作する場合、要求側104は、鍵取り替え確認メッセージ204の送信後の所定の期間まで、受信のための古い鍵及び受信のための新たな鍵の使用をサポートし続ける。

【0029】

或る実施例では、受信のために新たな鍵及び古い鍵の双方の使用をサポートする場合、無線デバイス300は、受信したユニキャストパケットの鍵IDフィールドを読み取り、鍵IDフィールドから古い鍵又は新たな鍵のいずれかを識別してもよい。識別された鍵は、受信したユニキャストパケットを解読するために使用されてもよい。

【0030】

或る実施例では、メモリ306は、１つ以上の非ユニキャスト（例えば、ブロードキャスト又はマルチキャスト）鍵のための非ユニキャスト鍵ID空間を含んでもよい。これらの実施例では、無線デバイス300は、受信したパケットの媒体アクセス制御（MAC：media-access control）アドレスに基づいて、受信したパケットがユニキャストパケットであるか非ユニキャストパケットであるかを判定してもよい。非ユニキャストパケットは、１人より多くの受信者にアドレス指定されたパケットである。ユニキャストパケットは、１人の受信者にアドレス指定されたパケットである。無線デバイス300は、受信したパケットがユニキャストパケットである場合にユニキャスト鍵（例えば、２つ１組の鍵）の１つを識別するために、鍵IDフィールドに基づいてユニキャスト鍵ID空間をインデックス付けしてもよい。無線デバイス300は、受信したパケットが非ユニキャストパケットである場合に非ユニキャスト鍵（すなわち、グループ鍵）の１つを識別するために、鍵IDフィールドに基づいて非ユニキャスト鍵ID空間をインデックス付けしてもよい。これらの実施例では、受信したパケットのMACアドレスは、パケットがユニキャストパケットであるか非ユニキャストパケットであるかを示してもよい。パケットがユニキャストパケットである場合、ユニキャスト鍵空間からの鍵は、受信したパケットを解読するために使用されてもよい。パケットが非ユニキャストパケットである場合、非ユニキャスト鍵空間からの鍵は、受信したパケットを解読するために使用されてもよい。特定の鍵は、鍵IDに基づいて鍵空間から選択されてもよい。これらの実施例の幾つかでは、ユニキャストパケットの鍵IDは、例えばゼロ又は１でもよく、ユニキャスト鍵空間で鍵（例えば、古い鍵又は新たな鍵）をインデックス付けするために使用されてもよい。非ユニキャストパケットの鍵IDは、例えばゼロ、１、２又は３でもよく、非ユニキャスト鍵空間で複数の鍵のうち１つをインデックス付けするために使用されてもよい。MACアドレスの使用は、どの鍵空間をインデックス付けするかを判定するために使用されてもよい。例えば、非ユニキャストパケットは、ブロードキャスト又はマルチキャストパケットでもよい。これらの実施例では、通信がIEEE802.11標準の１つに従って実行される場合、IEEE802.11での０、１、２及び３の鍵IDの値の現在の定義が変更されてもよい。

【0031】

或る別の実施例では、受信したユニキャストパケットの新規鍵ビットは、受信したユニキャストパケットを解読するために鍵を切り替えるか否かを判定するために読み取られてもよい。これらの別の実施例では、認証側102及び要求側104は、新たな鍵で暗号化されるユニキャストパケットを送信する場合に、新規鍵ビットを設定してもよい。これらの別の実施例では、鍵IDの値が規定される方法を変更するのではなく、現在又は通常の鍵IDの規定が使用されてもよい。これらの実施例では、新規鍵ビットは、鍵を切り替えることを受信機に示すトグル（toggle）として機能してもよい。これらの実施例では、通信は、IEEE802.11標準の１つに従って実行されてもよく、新規鍵ビットのために予約ビット（未使用ビット）が使用されてもよい。802.11における０、１、２及び３の鍵IDの値の現在の規定も使用されてもよい。これらの実施例では、新規鍵ビットが鍵を切り替えるために使用されるため、ゼロの鍵IDの値が全てのユニキャストパケットに使用されてもよく、１、２及び３の鍵IDの値が非ユニキャストパケットに使用されてもよい。

【0032】

或る実施例では、認証側102がメッセージ１において拡張鍵IDフィールドを１に設定し、要求側104が拡張鍵IDの使用をサポートする場合、要求側104は、拡張鍵ID空間の使用を交渉してもよい。これらの実施例では、要求側104は、交渉されている鍵でパケットを受信するために使用する鍵IDを選択してもよく、メッセージ２の鍵IDフィールドにその値を指定してもよい。これらの実施例では、認証側102がメッセージ１において拡張鍵IDフィールドをゼロに設定した場合、要求側104は、メッセージ２に鍵ID KDE（Key Data Encapsulation）を含めない。

【0033】

認証側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の値を繰り返してもよい。

【0034】

メッセージ３において認証側102が鍵ID KDEの存在により拡張鍵IDに対するサポートに合意したことを伝達した場合、要求側104は、認証側102の提案された鍵IDが、要求側104がメッセージ２で提案した値であることを検査してもよい。そうでない場合、４ウェイ・ハンドシェイク103が失敗してもよい。メッセージ３において認証102が鍵ID KDEの存在により拡張鍵IDをサポートしないことを伝達した場合、要求側104は、交渉されているTKを用いて、要求側104が保護するユニキャストパケットにおいて提案された鍵IDを使用してもよい。要求側104は、メッセージ４においてKDEを認証側102に戻してもよい。これらの実施例では、認証側102は、メッセージ４がメッセージ３で送信されたKDEを含むことを検査してもよい。そうでない場合、４ウェイ・ハンドシェイク103が失敗してもよい。

【0035】

これらの実施例では、有効なメッセージ２の受信に応じて、認証側102は、選択された鍵IDでの受信のために新たな鍵をインストールしてもよく、鍵ID KDEで新たな鍵IDを示すメッセージ３を送信してもよい。有効なメッセージ３を受信すると、要求側104は、メッセージ３で受信した鍵IDを使用して受信するために新たな鍵をインストールしてもよく、メッセージ４を送信してもよい。認証側102は、新たな鍵を使用してパケット（例えば、MPDU）を待ち行列に入れ始めてもよい。

【0036】

要求側104は、メッセージ４の送信後の所定の期間に古い鍵を使用したパケットの受信をサポートし続けてもよい。メッセージ４を受信すると、認証側102は、新たな鍵を使用してパケットを待ち行列に入れ始めてもよく、所定の期間に古い鍵を使用したパケットの受信をサポートし続けてもよい。或る実施例では、所定の期間は約60秒でもよい。

【0037】

或る別の実施例では、第４のEAPメッセージの後に、要求側104及び認証側102の双方は、双方のデバイスの最大遅延より大きい時間遅延（例えば、しばしば数秒のオーダ）を有する切り替えタイマを開始してもよい。この期間の間に、要求側104及び認証側102の双方は、古い鍵を使用し続ける。切り替えタイマの時間遅延の後に、要求側104及び認証側102の双方は新たな鍵を使用して送信してもよく、少なくとも所定の期間の受信のために古い鍵及び新たな鍵の双方を使用し続けてもよい。

【0038】

無線デバイス300は、複数の別個の機能要素を有するものとして示されているが、１つ以上の機能要素は結合されてもよく、デジタルシグナルプロセッサ（DSP：digital signal processors）及び／又は他のハードウェア要素を含む処理要素のようなソフトウェア構成の要素の組み合わせにより実現されてもよい。例えば、或る要素は、１つ以上のマイクロプロセッサ、DSP、特定用途向け集積回路（ASIC：application specific integrated circuit）、無線周波数集積回路（RFIC：radio-frequency integrated circuit）、及びここに記載の機能を少なくとも実行する様々なハードウェア及び論理回路の組み合わせを有してもよい。或る実施例では、無線デバイス300の機能要素は、１つ以上の処理要素で実行する１つ以上の処理を示してもよい。

【0039】

或る実施例では、無線デバイス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）技術に従って通信するように構成されてもよい。

【0040】

或る実施例では、無線デバイス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（その変更及び進展を含む）を参照のこと。

【0041】

或る他の実施例では、無線デバイス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）変調）のような１つ以上の他の変調技術を使用して送信された信号を通信するように構成されてもよい。しかし、実施例の範囲はこの点に限定されない。

【0042】

或る実施例では、無線デバイス300は、パーソナルデジタルアシスタント（PDA：personal digital assistant）、無線通信機能を備えたラップトップ若しくはポータブルコンピュータ、ウェブタブレット、無線電話、無線ヘッドセット、ページャ、インスタントメッセージングデバイス、デジタルカメラ、アクセスポイント、テレビ、医療デバイス（例えば、心拍数モニタ、血圧モニタ等）、又は無線で情報を受信及び／又は送信し得る他のデバイスのような、ポータブル無線通信デバイスの一部でもよい。

【0043】

或る実施例では、無線デバイス300は、通信のために２つ以上のアンテナ301を使用してもよい。アンテナ301は、例えば、ダイポールアンテナ、モノポールアンテナ、パッチアンテナ、ループアンテナ、マイクロストリップアンテナ、又はRF信号の送信に適した他の種類のアンテナを含み、指向性又は無指向性アンテナを有してもよい。或る実施例では、２つ以上のアンテナ301の代わりに、複数の開口を備えた単一のアンテナが使用されてもよい。これらの実施例では、各開口は、別のアンテナと考えられてもよい。或るMIMOの実施例では、アンテナ301は、空間ダイバーシチ及び通信局間で生じ得る異なるチャネル特性を利用するために事実上分離されてもよい。

【0044】

図４は、或る実施例による鍵取り替え中にパケットを受信する手順である。手順400は、鍵取り替え動作の間に、無線デバイス300（図３）のような無線デバイスにより実行されてもよい。或る実施例では、手順400は、例えばビデオストリーミングセッション中に、要求側104（図１）により実行されてもよい。或る実施例では、要求側104は、ストリーミングされたビデオを有するユニキャストパケットを受信してもよい。ユニキャストパケットは、第１の鍵で暗号化されてもよい。要求側104は、鍵取り替え動作を開始するために鍵取り替え開始メッセージ201（図２）を受信してもよく、認証側102（図１）への鍵取り替え確認メッセージ204（図２）の送信前の受信のために第２の鍵をインストールしてもよい。

【0045】

或る実施例では、動作402において、要求側104は、受信したユニキャストパケットの鍵IDフィールドを読み取り、受信したユニキャストパケットを解読するためにユニキャスト鍵ID空間に格納された新たな鍵を使用するか古い鍵を使用するかを判定してもよい。或いは、動作402において、要求側104は、受信したユニキャストパケットの新規鍵ビットを読み取り、受信したユニキャストパケットを解読するためにユニキャスト鍵ID空間に格納された新たな鍵又は古い鍵の間を切り替えるか否かを判定してもよい。

【0046】

或る実施例では、動作404において、要求側104は、受信したパケットのMACアドレスを読み取り、受信したパケットがユニキャストパケットであるか非ユニキャストパケットであるかを判定してもよい。パケットが非ユニキャストパケットである場合、動作410が実行されてもよい。パケットがユニキャストパケットである場合、動作408が実行されてもよい。

【0047】

動作408において、要求側104は、ユニキャスト鍵の１つを識別するために、鍵IDフィールドに基づいてユニキャスト鍵ID空間をインデックス付けしてもよい。動作410において、要求側104は、非ユニキャスト鍵の１つを識別するために、鍵IDフィールドに基づいて非ユニキャスト鍵ID空間をインデックス付けしてもよい。動作412において、パケットは、動作408又は410で判定された鍵で解読されてもよい。

【0048】

要約は、読者が技術的開示の性質及び要旨を確認することを可能にすることを要約に求める37 C.F.R. Section 1.72(b)に従うために提供されている。これは請求項の範囲又は意味を解釈するために使用されないという認識で提示されている。以下の請求項は、詳細な説明に援用され、各請求項は別々の実施例として独立する。

【0049】

以上の実施例に関し、更に、以下の項目を開示する。

【0050】

（１）要求側との通信セッション中の鍵取り替えのために認証側により実行される方法であって、
鍵取り替え確認メッセージの受信の前の受信のために新たな鍵をインストールするステップと、
前記鍵取り替え確認メッセージの受信後まで、送信のための前記新たな鍵の使用を遅らせるステップと
を有する方法。

【0051】

（２）受信のために前記新たな鍵をインストールした後に、前記方法は、送信のために古い鍵を使用し続けつつ、受信のために前記新たな鍵又は古い鍵を使用するステップを更に有し、
前記要求側は、前記鍵取り替え確認メッセージの送信前の受信のために前記新たな鍵をインストールし、前記鍵取り替え確認メッセージの送信後まで、送信のための前記新たな鍵の使用を遅らせる、（１）に記載の方法。

【0052】

（３）前記要求側は、前記鍵取り替え確認メッセージの送信直後又は前記鍵取り替え確認メッセージの送信後の所定の期間まで、送信のための前記新たな鍵の使用を遅らせる、（２）に記載の方法。

【0053】

（４）前記鍵取り替え確認メッセージの受信前の受信のために前記新たな鍵をインストールした後に、受信したユニキャストパケットで伝達された鍵識別子に基づいて、受信したユニキャストパケットを解読するために前記新たな鍵又は古い鍵のいずれかを選択するステップを含む、（２）に記載の方法。

【0054】

（５）前記鍵取り替え確認メッセージは、鍵取り替えのための４ウェイ・ハンドシェイクの第４のメッセージであり、
前記方法は、
前記認証側が、前記４ウェイ・ハンドシェイクの第２のメッセージの受信後且つ前記４ウェイ・ハンドシェイクの第３のメッセージメッセージの送信前に受信したパケットを解読する際に使用するために前記新たな鍵をインストールと、
前記認証側が、前記第４のメッセージの受信後まで、送信のためのパケットを暗号化する際に使用するための前記新たな鍵の使用を遅らせるステップと
を更に有し、
前記要求側は、前記第３のメッセージの受信後且つ前記第４のメッセージの送信前に受信したメッセージを解読する際に使用するために前記新たな鍵をインストールし、
前記要求側は、前記第４のメッセージの送信直後又は前記第４のメッセージの送信後の所定の期間まで、送信のためのパケットを暗号化する際に使用するための前記新たな鍵のインストールを遅らせる、（２）に記載の方法。

【0055】

（６）前記４ウェイ・ハンドシェイクが完了しなかった場合、前記新たな鍵をアンインストールするステップを更に有する、（５）に記載の方法。

【0056】

（７）前記４ウェイ・ハンドシェイクは、IEEE802.11通信標準に従って、EAPOL（Extensible Authentication Protocol over Local area network）鍵フレームを交換することを有する、（５）に記載の方法。

【0057】

（８）前記鍵取り替え確認メッセージは、鍵取り替えのための４ウェイ・ハンドシェイクの第４のメッセージであり、
前記認証側は、ユニキャストトラヒックを通信する際に使用するための２つのユニキャスト鍵について提供されたユニキャスト鍵ID空間を有するメモリを有し、前記２つのユニキャスト鍵は、少なくとも前記古い鍵及び前記新たな鍵を有する、（２）に記載の方法。

【0058】

（９）前記古い鍵の削除を回避するために、順次の４ウェイ・ハンドシェイクの間に２つの鍵識別子の使用を交互にするステップを更に有する、（８）に記載の方法。

【0059】

（１０）受信したユニキャストパケットの鍵IDフィールドを読み取るステップと、
前記鍵IDフィールドから前記古い鍵又は前記新たな鍵のいずれかを識別するステップと、
前記受信したユニキャストパケットを解読するために前記識別された鍵を使用するステップと
を更に有する、（８）に記載の方法。

【0060】

（１１）前記メモリは、１つ以上の非ユニキャスト鍵のための非ユニキャスト鍵ID空間を更に含み、
前記方法は、
受信したパケットの媒体アクセス制御アドレスに基づいて、受信したパケットがユニキャストパケットであるか非ユニキャストパケットであるかを判定するステップと、
前記受信したパケットがユニキャストパケットであると判定された場合、前記ユニキャスト鍵の１つを識別するために、前記鍵IDフィールドに基づいて前記ユニキャスト鍵ID空間をインデックス付けするステップと、
前記受信したパケットが非ユニキャストパケットであると判定された場合、前記非ユニキャスト鍵の１つを識別するために、前記鍵IDフィールドに基づいて前記非ユニキャスト鍵ID空間をインデックス付けするステップと
を更に有する、（１０）に記載の方法。

【0061】

（１２）受信したユニキャストパケットの新規鍵ビットを読み取り、前記受信したユニキャストパケットを解読するために鍵を切り替えるか否かを判定するステップを更に有する、（８）に記載の方法。

【0062】

（１３）鍵取り替え動作の一部として前記新たな鍵を交渉するために、４ウェイ・ハンドシェイクを実行するステップを更に有し、
前記新たな鍵は、前記４ウェイ・ハンドシェイクの間に交換された情報から前記要求側と前記認証側との双方により生成された非対称鍵である、（８）に記載の方法。

【0063】

（１４）前記認証側はアクセスポイントであり、前記要求側は移動局であり、
前記アクセスポイント及び前記移動局は、IEEE802.11通信標準に従って通信する、（１３）に記載の方法。

【0064】

（１５）認証側との通信セッション中の鍵取り替えのために要求側により実行される方法であって、
前記認証側への鍵取り替え確認メッセージの送信前の受信のために新たな鍵をインストールするステップと、
前記鍵取り替え確認メッセージの送信後まで、送信のための前記新たな鍵の使用を遅らせるステップと、
前記鍵取り替え確認メッセージ後に受信のための古い鍵及び受信のための前記新たな鍵の双方の使用をサポートするステップと
を有する方法。

【0065】

（１６）前記認証側は、前記鍵取り替え確認メッセージの受信前の受信のために前記新たな鍵をインストールし、前記鍵取り替え確認メッセージの受信後まで、送信のための前記新たな鍵の使用を遅らせ、
前記要求側及び前記認証側は、前記鍵取り替え確認メッセージの受信後に受信のための前記古い鍵及び受信のための前記新たな鍵の使用をサポートし続ける、（１５）に記載の方法。

【0066】

（１７）前記要求側は、前記鍵取り替え確認メッセージの送信後の所定の期間まで、受信のための前記古い鍵及び受信のための前記新たな鍵の使用をサポートし続け、
前記認証側は、前記鍵取り替え確認メッセージの受信後の所定の期間に受信のための前記古い鍵及び受信のための前記新たな鍵の使用をサポートし続ける、（１６）に記載の方法。

【0067】

（１８）前記要求側は、ユニキャストトラヒックを通信する際に使用するための２つのユニキャスト鍵について提供されたユニキャスト鍵ID空間を有するメモリを有し、前記２つのユニキャスト鍵は、少なくとも前記古い鍵及び前記新たな鍵を有し、
前記方法は、
受信したユニキャストパケットの鍵IDフィールドを読み取り、前記受信したユニキャストパケットを解読するために前記新たな鍵を使用するか前記古い鍵を使用するかを判定するステップ、又は
前記受信したユニキャストパケットの新規鍵ビットを読み取り、前記受信したユニキャストパケットを解読するために鍵を切り替えるか否かを判定するステップ
を有する、（１５）に記載の方法。

【0068】

（１９）前記鍵取り替え確認メッセージは、鍵取り替えのための４ウェイ・ハンドシェイクの第４のメッセージであり、
前記方法は、前記古い鍵の削除を回避するために、順次の４ウェイ・ハンドシェイクの間に２つの鍵識別子の使用を交互にするステップを更に有する、（１８）に記載の方法。

【0069】

（２０）鍵取り替え動作を実行する処理回路と、
ユニキャストトラヒックを有するパケットを暗号化及び解読する際に使用するための少なくとも２つのユニキャスト鍵を格納するユニキャスト鍵ID空間を有するメモリと
を有し、
無線デバイスが認証側として動作する場合、前記処理回路は、鍵取り替え確認メッセージの受信の前の受信のために新たな鍵をインストールし、前記鍵取り替え確認メッセージの受信後まで、送信のための前記新たな鍵の使用を遅らせ、
無線デバイスが認証側として動作する場合、前記認証側は、前記鍵取り替え確認メッセージの受信後の所定の期間に受信のための古い鍵及び受信のための前記新たな鍵の使用をサポートし続ける無線デバイス。

【0070】

（２１）前記無線デバイスが要求側として動作する場合、前記処理回路は、前記鍵取り替え確認メッセージの送信前の受信のために前記新たな鍵をインストールし、前記鍵取り替え確認メッセージの送信後まで、送信のための前記新たな鍵の使用を遅らせ、
前記無線デバイスが要求側として動作する場合、前記要求側は、前記鍵取り替え確認メッセージの送信後の所定の期間まで、受信のための前記古い鍵及び受信のための前記新たな鍵の使用をサポートし続ける、（２０）に記載の無線デバイス。

【0071】

（２２）前記処理回路は、
受信したユニキャストパケットの鍵IDフィールドを読み取り、前記受信したユニキャストパケットを解読するために前記ユニキャストID空間に格納された前記新たな鍵を使用するか前記古い鍵を使用するかを判定すること、又は
前記受信したユニキャストパケットの新規鍵ビットを読み取り、前記受信したユニキャストパケットを解読するために前記ユニキャストID空間に格納された前記新たな鍵又は前記古い鍵の間を切り替えるか否かを判定すること
を実行する、（２１）に記載の無線デバイス。

【0072】

（２３）前記鍵取り替え確認メッセージは、鍵取り替えのための４ウェイ・ハンドシェイクの第４のメッセージであり、
前記４ウェイ・ハンドシェイクは、IEEE802.11通信標準に従って、EAPOL（Extensible Authentication Protocol over Local area network）鍵フレームを交換することを有する、（２２）に記載の無線デバイス。

【0073】

（２４）前記鍵取り替え確認メッセージは、鍵取り替えのための４ウェイ・ハンドシェイクの第４のメッセージであり、
前記認証側は、前記古い鍵の削除を回避するために、順次の４ウェイ・ハンドシェイクの間に２つの鍵識別子の使用を交互にする、（２２）に記載の無線デバイス。

【0074】

（２５）ビデオストリーミングセッション中に要求側により実行される鍵取り替え方法であって、
ストリーミングされるビデオを有し、第１の鍵で暗号化されたユニキャストパケットを受信するステップと、
鍵取り替え開始メッセージを受信し、鍵取り替え動作を開始するステップと、
認証側への鍵取り替え確認メッセージの送信前の受信のために第２の鍵をインストールするステップと、
受信したユニキャストパケットで伝達された鍵識別子に基づいて、受信したユニキャストパケットを解読するために前記第１又は第２の鍵を選択するステップと、
前記鍵取り替え確認メッセージの送信後の所定の期間まで、前記第１の鍵及び前記第２の鍵の双方での前記ユニキャストパケットの受信をサポートするステップと
を有する方法。

【0075】

（２６）前記鍵取り替え確認メッセージの送信直後まで、送信のための前記第２の鍵のインストールを遅らせるステップを更に有する、（２５）に記載の方法。

【0076】

（２７）前記鍵取り替え確認メッセージの送信後の前記所定の期間の後に受信する際に使用するために前記第１の鍵をアンインストールするステップを更に有する、（２５）に記載の方法。

【0077】

（２８）前記鍵取り替え確認メッセージは、鍵取り替えのための４ウェイ・ハンドシェイクの第４のメッセージである、（２７）に記載の方法。

【0078】

（２９）前記第１の鍵の削除を回避するために、順次のハンドシェイクの間に２つの鍵識別子の使用を交互にするステップを更に有する、（２７）に記載の方法。

【図1】

【図2】

【図3】

【図4】