JP2015177359A

JP2015177359A - 無線通信装置、無線通信システム、及び無線通信方法

Info

Publication number: JP2015177359A
Application number: JP2014052468A
Authority: JP
Inventors: 加古　鎭治; Shinji Kako; 鎭治加古
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2014-03-14
Filing date: 2014-03-14
Publication date: 2015-10-05
Anticipated expiration: 2034-03-14
Also published as: JP6264112B2

Abstract

【課題】認証情報を容易に変更することである。
【解決手段】無線ＡＰ１０は、複数の無線端末と通信を行う。無線ＡＰ１０は、ＰＰ変更部１５と無線ＩＦ１２と鍵交換部１６とを有する。ＰＰ変更部１５は、複数の無線端末の認証情報の変更を決定する。無線ＩＦ１２は、ＰＰ変更部１５により上記認証情報の変更が決定された後に、複数の無線端末の内、少なくとも１つの無線端末２０からの通信要求を受信する。鍵交換部１６は、上記通信要求の送信元の無線端末２０に対し、上記変更の前の認証情報を用いて、変更後の認証情報を通知する。
【選択図】図１

Description

本発明は、無線通信装置、無線通信システム、及び無線通信方法に関する。

近年、Ｗｉ−Ｆｉ（登録商標）等を用いて、家庭内で無線通信を行うホームネットワークが利用されている。ホームネットワークでは、無線ＡＰ（Access Point）が、複数の機器（例えば、携帯端末、ＴＶ、パーソナルコンピュータ、ビデオカメラ等）との間で、無線通信を行うことにより、家庭内にネットワークを形成する。無線ＡＰは、ブロードバンドルータを介して、宅外のネットワークに有線接続される。無線ＡＰと複数の機器との間の無線通信のセキュリティは、例えば、複数の機器に１つの認証情報（例えば、パスフレーズ）を設定するＷＰＡ２−ＰＳＫ（Wi-Fi Protected Access2−Pre-Shared Key）により確保される。無線ＡＰは、上記認証情報に、長時間同一の情報を使用し続けると、該情報が外部に漏れて、ホームネットワークに対する不正アクセスが容易になることから、所定時間の経過に伴って、認証情報を変更する。

特開２００５−１３６８７０号公報特表２００９−５１４０８５号公報特開２００４−３５５３９６号公報

しかしながら、上述した様に、該認証情報は複数の機器に共通であるため、無線ＡＰは、認証情報を変更する際、接続する全ての機器の認証情報を変更する。これに伴い、無線ＡＰにおける認証情報の変更時点から、接続する全ての機器における認証情報の変更が完了するまでの間、無線ＡＰと複数の機器との間の無線通信は中断することとなる。従って、ユーザは、認証情報が更新されるまでの間、複数の機器の提供するサービスを享受することができない。例えば、携帯端末のユーザによる通話が途切れたり、ＴＶのユーザによる番組録画が停止したりすることがある。特に、近年ではＥＭＳ（Energy Management System）機器等の普及により接続機器数が増加していることから、このことが、認証情報の変更を躊躇させる要因となっていた。

開示の技術は、上記に鑑みてなされたものであって、認証情報を容易に変更することができる無線通信装置、無線通信システム、及び無線通信方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本願の開示する無線通信装置は、一つの態様において、複数の無線端末と通信を行う。前記無線通信装置は、決定部と受信部と通知部とを有する。前記決定部は、前記複数の無線端末の認証情報の変更を決定する。前記受信部は、前記決定部により前記認証情報の変更が決定された後に、前記複数の無線端末の内、少なくとも１つの無線端末からの通信要求を受信する。前記通知部は、前記通信要求の送信元の無線端末に対し、前記変更の前の認証情報を用いて、変更後の認証情報を通知する。

本願の開示する無線通信装置の一つの態様によれば、認証情報を容易に変更することができる。

図１は、無線通信システムの機能構成を示す図である。図２は、ＰＰ情報が“ＰＰ＃２”の場合における認証管理テーブルのデータ格納例を示す図である。図３は、ＰＰ情報が“ＰＰ＃２”の場合におけるＰＰ情報記憶部のデータ格納例を示す図である。図４は、無線ＡＰのハードウェア構成を示す図である。図５は、無線端末のハードウェア構成を示す図である。図６は、初期状態における認証管理テーブルのデータ格納例を示す図である。図７は、ＰＰ変更時におけるシーケンス図の前半部分である。図８は、ＰＣから無線ＡＰに対するＰＰ変更要求の構成例を示す図である。図９は、ＰＰ変更要求の受信時に無線ＡＰが実行する処理を説明するためのフローチャートである。図１０は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔ送信後における認証管理テーブルのデータ格納例を示す図である。図１１は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔの受信時に無線端末が実行する処理を説明するためのフローチャートである。図１２は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅの受信時に無線ＡＰが実行する処理を説明するためのフローチャートである。図１３は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅ受信後における認証管理テーブルのデータ格納例を示す図である。図１４は、ＰＰ変更時におけるシーケンス図の後半部分である。図１５は、ビデオカメラから無線ＡＰに対するＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔの構成例を示す図である。図１６は、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔの受信時に無線ＡＰが実行する処理を説明するためのフローチャートである。図１７は、無線ＡＰからビデオカメラに対するＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅの構成例を示す図である。図１８は、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅ送信後における認証管理テーブルのデータ格納例を示す図である。図１９は、ビデオカメラから無線ＡＰに対するＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔの構成例を示す図である。図２０は、ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔの受信時に無線ＡＰが実行する処理を説明するためのフローチャートである。図２１は、無線ＡＰからビデオカメラに対するＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅの構成例を示す図である。図２２は、無線ＡＰからビデオカメラに対するＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔの構成例を示す図である。図２３は、ビデオカメラから無線ＡＰに対するＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅの構成例を示す図である。図２４は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅ受信後における認証管理テーブルのデータ格納例を示す図である。図２５は、鍵状態記憶部の旧ＰＰ期限設定領域におけるデータ設定例を示す図である。図２６は、切替えＴＯ処理の実行後における認証管理テーブルのデータ格納例を示す図である。図２７は、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅ送信後における認証管理テーブルのデータ格納例を示す図である。図２８は、ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅ送信後における認証管理テーブルのデータ格納例を示す図である。図２９は、成りすまし検知時におけるシーケンス図の前半部分である。図３０は、成りすまし検知時に無線ＡＰが実行する処理を説明するためのフローチャートである。図３１は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔ送信後における認証管理テーブルのデータ格納例を示す図である。図３２は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅ受信後における認証管理テーブルのデータ格納例を示す図である。図３３は、成りすまし検知時におけるシーケンス図の後半部分である。図３４は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔ送信後における認証管理テーブルのデータ格納例を示す図である。図３５は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅ受信後における認証管理テーブルのデータ格納例を示す図である。図３６は、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅ送信後における認証管理テーブルのデータ格納例を示す図である。図３７は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅ受信後における認証管理テーブルのデータ格納例を示す図である。図３８は、無線ＡＰの実行する旧ＰＰ期限経過レコード削除処理を説明するためのフローチャートである。図３９は、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅ送信後における認証管理テーブルのデータ格納例を示す図である。図４０は、ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅ送信後における認証管理テーブルのデータ格納例を示す図である。

以下に、本願の開示する無線通信装置、無線通信システム、及び無線通信方法の実施例を、図面を参照しながら詳細に説明する。なお、以下の実施例により本願の開示する無線通信装置、無線通信システム、及び無線通信方法が限定されるものではない。

本願の開示する一実施例に係る無線通信システム１の構成を説明する。図１は、無線通信システム１の機能構成を示す図である。図１に示す様に、無線通信システム１は、無線ＡＰ１０と無線端末２０とを有する。無線ＡＰ１０は、有線ＩＦ（Inter Face）１１と無線ＩＦ１２とパケット転送部１３とパケット中継部１４とＰＰ（Pass Phrase）変更部１５と鍵交換部１６と鍵状態記憶部１７とを有する。無線端末２０は、無線ＩＦ２１とパケット送受信部２２と鍵交換部２３と鍵状態記憶部２４とＰＰ変更部２５と入出力制御部２６とを有する。これら各構成部分は、一方向又は双方向に、信号やデータの入出力が可能な様に接続されている。

無線ＡＰ１０の有線ＩＦ（Inter Face）１１は、有線による通信を行う。無線ＩＦ１２は、無線による通信を行う。パケット転送部１３は、受信されたパケットの転送を制御する。パケット中継部１４は、受信されたパケットの中継先を制御する。ＰＰ変更部１５は、無線端末２０のユーザからのＰＰ変更要求を受け付ける。鍵交換部１６は、暗号化通信のため、通信相手の無線端末２０との間における鍵情報の交換を制御する。鍵状態記憶部１７は、鍵情報と、通信相手の無線端末２０との間における鍵交換の状態とを記憶する。

鍵状態記憶部１７は、認証管理テーブル１７１を有する。図２は、ＰＰ情報が“ＰＰ＃２”の場合における認証管理テーブル１７１のデータ格納例を示す図である。図２に示す様に、認証管理テーブル１７１には、ＷＰＡ２−ＰＳＫ（ＡＥＳ：Advanced Encryption Standard）の「ＰＰ情報」として“ＰＰ＃２”が設定されている。また、装置識別情報に対応付けて、認証状況と旧ＰＰ情報と旧ＰＰ期限とが、対応する領域１７１ａ、１７１ｂ、１７１ｃ、１７１ｄ内に格納されている。装置識別情報は、無線ＡＰ１０と無線通信する装置（例えば、無線端末２０）の識別情報である。認証状況は、旧ＰＰから新ＰＰへ変更する際の無線ＡＰ１０での認証状況を、対応する装置毎に示す情報である。この認証状況には、例えば、認証済、切替え待ち、旧ＰＰ認証中、認証中がある。旧ＰＰ情報は、変更前のＰＰである。旧ＰＰ期限は、変更前のＰＰによる認証を認める期限（有効期限）である。

無線端末２０の無線ＩＦ２１は、無線による通信を行う。パケット送受信部２２は、パケットの送受信を制御する。鍵交換部２３は、暗号化通信のため、通信相手の無線ＡＰ１０との間における鍵情報の交換を制御する。鍵状態記憶部２４は、鍵情報と、通信相手の無線ＡＰ１０との間における鍵交換の状態とを記憶する。ＰＰ変更部２５は、無線端末２０のユーザからのＰＰ変更要求を受け付ける。入出力制御部２６は、ユーザによる操作に従い、例えば機器情報の提供を制御する。

鍵状態記憶部２４は、ＰＰ情報記憶部２４１を有する。図３は、ＰＰ情報が“ＰＰ＃２”の場合におけるＰＰ情報記憶部２４１のデータ格納例を示す図である。図３に示す様に、ＰＰ情報記憶部２４１には、「ＰＰ情報」として、ＷＰＡ２−ＰＳＫ（ＡＥＳ）に則った“ＰＰ＃２”が格納されている。

図４は、無線ＡＰ１０のハードウェア構成を示す図である。図４に示す様に、無線ＡＰ１０は、ハードウェアの構成要素として、有線ＩＦ１０ａと無線ＩＦ１０ｂとパケット転送制御部１０ｃと制御部１０ｄと記憶部１０ｅとを有する。制御部１０ｄは、例えば、記憶部１０ｅに記憶されたプログラムを実行するＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＦＰＧＡ（Field Programmable Gate Array）等の集積回路である。記憶部１０ｅは、例えば、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）等のＲＡＭ、ＲＯＭ（Read Only Memory)、フラッシュメモリであり、上記プログラムやデータを記憶する。機能構成とハードウェア構成との対応関係に関し、有線ＩＦ１１と無線ＩＦ１２とパケット転送部１３とは、ぞれぞれ有線ＩＦ１０ａと無線ＩＦ１０ｂとパケット転送制御部１０ｃとにより実現される。また、パケット中継部１４とＰＰ変更部１５と鍵交換部１６とは制御部１０ｄにより実現され、鍵状態記憶部１７は記憶部１０ｅにより実現される。

図５は、無線端末２０のハードウェア構成を示す図である。図５に示す様に、無線端末２０は、ハードウェアの構成要素として、無線ＩＦ２０ａと制御部２０ｂと記憶部２０ｃと入出力部２０ｄとを有する。制御部２０ｂは、例えば、記憶部２０ｃに記憶されたプログラムを実行するＣＰＵ、ＤＳＰ、ＦＰＧＡ等の集積回路である。記憶部２０ｃは、例えば、ＳＤＲＡＭ等のＲＡＭ、ＲＯＭ、フラッシュメモリであり、上記プログラムやデータを記憶する。入出力部２０ｄは、例えば、キーボード、マウス、ボタン、ＬＣＤ（Liquid Crystal Display）等のディスプレイ、スピーカである。機能構成とハードウェア構成との対応関係に関し、無線ＩＦ２１は無線ＩＦ２０ａにより実現される。また、パケット送受信部２２と鍵交換部２３とＰＰ変更部２５とは、制御部２０ｂにより実現される。更に、鍵状態記憶部２４と入出力制御部２６とは、それぞれ記憶部２０ｃと入出力部２０ｄとにより実現される。

次に、動作を説明する。

まず、無線ＡＰ１０が、無線端末２０からの要求に応じてＰＰ情報を変更する処理について説明する。説明の前提として、無線ＡＰ１０と、その通信相手である無線端末２０との間の認証が、ＰＰ情報をＰＰ＃１として完了しているものとする。無線端末２０は、例えば、ＰＣ（Personal Computer）２０−１、ＴＶ２０−２、ビデオカメラ２０−３、携帯端末２０−４、センサ２０−５、エアコン２０−６である。これらの無線端末２０の内、ＰＣ２０−１、ＴＶ２０−２、センサ２０−５、エアコン２０−６は、ＷｉＦｉ（登録商標）通信中であり、ビデオカメラ２０−３、携帯端末２０−４は、ＷｉＦｉ（登録商標）停止中である。以下の説明では、各無線端末２０間で共通する構成要素には、末尾が同一の参照符号を用いると共に、その詳細な説明は省略する。

図６は、初期状態における認証管理テーブル１７２のデータ格納例を示す図である。図６に示す様に、認証管理テーブル１７２には、全ての無線端末２０の「認証状況」として“認証済”が格納されている。なお、この時点では、「旧ＰＰ情報」及び「旧ＰＰ期限」は格納されていない。

図７は、ＰＰ変更時におけるシーケンス図の前半部分である。図７において、実線は平文による通信を示し、破線は暗号鍵による暗号化通信を示す。また、ＫＥ＿ＰＰ＃ｎは、パスフレーズＰＰ＃ｎを基に生成された暗号鍵を示す。ＳＫ＿ＰＰ＃ｎは、上記ＫＥ＿ＰＰ＃ｎから生成された暗号鍵を示す。ＳＫ＿ＰＰ＃ｎ｛ｐａｙｌｏａｄ｝は、ｐａｙｌｏａｄをＳＫ＿ＰＰ＃ｎにより暗号化することを示す。更に、実線矢印の直上に、信号のメッセージタイプを記載し、直下に、信号のペイロードを記載している。

まずＳ１では、ユーザがＰＣ２０−１を操作し、無線ＡＰ１０のＰＰの変更を指示すると、ＰＣ２０−１のＰＰ変更部２５−１は、ＰＰ変更要求Ｓ１ａを無線ＡＰ１０へ送信する。図８は、ＰＣ２０−１から無線ＡＰ１０に対するＰＰ変更要求Ｓ１ａの構成例を示す図である。図８に示す様に、ＰＰ変更要求Ｓ１ａは、ユーザデータ、ＴＣＰ（Transmission Control Protocol）、ＩＰ（Internet Protocol）、Ｌ（Layer）２、Ｌ１の各情報を有する。これらの情報の内、ユーザデータ及びＴＣＰは、ＳＫ＿ＰＰ＃１により暗号化されている。

無線ＡＰ１０は、上記ＰＰ変更要求Ｓ１ａの受信に伴い、ＰＰ変更処理を実行する。

図９は、ＰＰ変更要求Ｓ１ａの受信時に無線ＡＰ１０が実行する処理を説明するためのフローチャートである。まずＴ１では、無線ＡＰ１０のＰＰ変更部１５は、現在時刻と旧ＰＰ有効期間とから、ＰＰ変更の要求元であるＰＣ２０−１の“旧ＰＰ期限”を算出する。Ｔ２では、ＰＰ変更部１５は、ＰＣ２０−１のＰＰ情報を、旧ＰＰ情報格納領域１７１ｃに“旧ＰＰ情報”として格納させる。Ｔ３では、ＰＰ変更部１５は、認証管理テーブル１７１から、「認証状況」が“認証中”のレコードを抽出する。該レコードが存在する場合（Ｔ４；Ｙｅｓ）には、ＰＰ変更部１５は、上記レコードの「旧ＰＰ情報」、「旧ＰＰ期限」、「認証状況」に対し、Ｔ２で格納された“旧ＰＰ情報”、Ｔ１で算出された“旧ＰＰ期限”、“旧ＰＰ認証中”をそれぞれ設定する（Ｔ５）。なお、上記レコードが存在しない場合（Ｔ４；Ｎｏ）には、Ｔ５の処理は省略される。

次に、ＰＰ変更部１５は、認証管理テーブル１７１から、「認証状況」が“認証済”のレコードを抽出する（Ｔ６）。該レコードが存在する場合（Ｔ７；Ｙｅｓ）には、ＰＰ変更部１５は、上記レコードの「旧ＰＰ情報」、「旧ＰＰ期限」、「認証状況」に対し、Ｔ２で格納された“旧ＰＰ情報”、Ｔ１で算出された“旧ＰＰ期限”、“切替え待ち”をそれぞれ設定する（Ｔ８）。Ｔ９では、ＰＰ変更部１５は、上記ＰＰ変更要求Ｓ１ａの有するＰＰ情報を、認証管理テーブル１７１のＰＰ情報（図２の左上）に、新ＰＰ情報として設定する。Ｔ１０では、鍵交換部１６は、上記レコードの装置識別情報の各装置に対し、上記新ＰＰ情報と、該新ＰＰ情報から生成された暗号鍵情報とを、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔにより送信する。なお、上記レコードが存在しない場合（Ｔ７；Ｎｏ）には、Ｔ８〜Ｔ１０の各処理は省略される。

図７に戻り、Ｓ２では、無線ＡＰ１０のＰＰ変更部１５は、「認証状況」が“認証済”である全ての無線端末２０（図６参照）に対し、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔを送信する。

図１０は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔ送信後における認証管理テーブル１７３のデータ格納例を示す図である。図１０に示す様に、認証管理テーブル１７３では、全ての無線端末２０の「認証状況」が“切替え待ち”に更新されている。また、全ての無線端末２０の「旧ＰＰ情報」が“ＰＰ＃１”に設定され、「旧ＰＰ期限」が“１０：００”に設定されている。

図１１は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ２ａの受信時に無線端末２０が実行する処理を説明するためのフローチャートである。まずＴ１１では、無線端末２０の鍵交換部２３は、受信されたＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ２ａにＰＰ情報が有るか否かを判定する。ＰＰ情報が有る場合（Ｔ１１；Ｙｅｓ）、鍵交換部２３は、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ２ａのＰＰ情報を、ＰＰ情報記憶部２４１のＰＰ情報（図３参照）に設定する。なお、上記ＰＰ情報が無い場合（Ｔ１１；Ｎｏ）、Ｔ１２の処理は省略される。Ｔ１３では、鍵交換部２３は、無線ＡＰ１０に対し、上記ＰＰ情報と、該ＰＰ情報から生成された暗号鍵情報とを、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅにより返信する。

図７に戻り、Ｓ３では、無線端末２０（ＰＣ２０−１）の鍵交換部２３は、無線ＡＰ１０に対し、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ３ａを送信する。

図１２は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ３ａの受信時に無線ＡＰ１０が実行する処理を説明するためのフローチャートである。まずＴ２１では、無線ＡＰ１０の鍵交換部１６は、受信されたＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ３ａにＰＰ情報が有るか否かを判定する。ＰＰ情報が有る場合（Ｔ２１；Ｙｅｓ）、鍵交換部１６は、認証管理テーブル１７１を参照し、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ３ａの送信元（ＰＣ２０−１）に対応するレコードの認証状況が“切替え待ち”であるか否かを判定する（Ｔ２２）。“切替え待ち”である場合（Ｔ２２；Ｙｅｓ）、鍵交換部１６は、認証管理テーブル１７１に現時点で設定されているＰＰ情報と、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ３ａの有するＰＰ情報とが一致するか否かを判定する（Ｔ２３）。一致する場合（Ｔ２３；Ｙｅｓ）、鍵交換部１６は、認証管理テーブル１７１において、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ３ａの送信元（ＰＣ２０−１）に対応するレコードの認証状況を、“切替え待ち”から“認証済”に更新する。併せて、鍵交換部１６は、上記レコードの旧ＰＰ情報と旧ＰＰ期限とを初期化する（Ｔ２４）。

上記Ｔ２３における判定の結果、一致しない場合（Ｔ２３；Ｎｏ）、鍵交換部１６は、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ３ａの送信元である無線端末２０（ＰＣ２０−１）へ、上記ＰＰ情報と、該ＰＰ情報から生成された暗号鍵情報とを、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔにより送信する（Ｔ２５）。

なお、上記Ｔ２１においてＰＰ情報が無い場合（Ｔ２１；Ｎｏ）、あるいは、上記Ｔ２２において“切替え待ち”でない場合（Ｔ２２；Ｎｏ）には、以降の処理は省略される。

図７に戻り、Ｓ４では、無線ＡＰ１０と、無線端末２０としてのＰＣ２０−１との間で、変更後のＰＰ＃２による暗号化通信が開始される。

Ｓ５〜Ｓ１３では、ＰＣ２０−１以外の他の無線端末２０の内、ＷｉＦｉ（登録商標）通信中の無線端末２０（ＴＶ２０−２、センサ２０−５、エアコン２０−６）に関し、上述したＳ２〜Ｓ４と同様の処理が実行される。すなわち、無線ＡＰ１０は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ６ａ、Ｓ９ａ、Ｓ１２ａを、ＴＶ２０−２、センサ２０−５、エアコン２０−６から順次受けると、これらの無線端末２０を対象として、図１２に示した処理を実行する。その結果、ＴＶ２０−２、センサ２０−５、エアコン２０−６の認証状況は、“切替え待ち”から“認証済”に更新される。

図１３は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅ受信後における認証管理テーブル１７４のデータ格納例を示す図である。図１３に示す様に、認証管理テーブル１７４では、全ての無線端末２０の「認証状況」の内、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅの有った装置の識別情報に対応する「認証状況」が“認証済”に更新されている。また、上記識別情報に対応する「旧ＰＰ情報」及び「旧ＰＰ期限」は、初期化されている。

ここで、ユーザが、変更前のＰＰ情報であるＰＰ＃１の有効期限よりも前にビデオカメラ２０−３を起動すると、無線ＡＰ１０とビデオカメラ２０−３との間で、ＷｉＦｉ（登録商標）通信が再開される。

図１４は、ＰＰ変更時におけるシーケンス図の後半部分である。図１４において、実線は平文による通信を示し、破線は暗号鍵による暗号化通信を示す。また、ＫＥ＿ＰＰ＃ｎは、パスフレーズＰＰ＃ｎを基に生成された暗号鍵を示す。ＳＫ＿ＰＰ＃ｎは、上記ＫＥ＿ＰＰ＃ｎから生成された暗号鍵を示す。ＳＫ＿ＰＰ＃ｎ｛ｐａｙｌｏａｄ｝は、ｐａｙｌｏａｄをＳＫ＿ＰＰ＃ｎにより暗号化することを示す。更に、実線矢印の直上に、信号のメッセージタイプを記載し、直下に、信号のペイロードを記載している。

Ｓ１４では、無線端末２０（ビデオカメラ２０−３）の鍵交換部２３は、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ１４ａを、無線ＡＰ１０宛に送信する。図１５は、ビデオカメラ２０−３から無線ＡＰ１０に対するＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ１４ａの構成例を示す図である。図１５に示す様に、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ１４ａは、ＨＤＲ（HeaDdeR）、ペイロード、ＵＤＰ（User Datagram Protocol）、ＩＰ、Ｌ２、Ｌ１の各情報を有する。

無線ＡＰ１０は、上記ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ１４ａの受信に伴い、鍵交換処理を実行する。

図１６は、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ１４ａの受信時に無線ＡＰ１０が実行する処理を説明するためのフローチャートである。まずＴ３１では、鍵交換部１６は、上記ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ１４ａの送信元（ビデオカメラ２０−３）に対応するレコードを、認証管理テーブル１７１から抽出する。該レコードが存在する場合（Ｔ３２；Ｙｅｓ）には、鍵交換部１６は、上記レコードの「認証状況」が“認証済”であるか否かを判定する（Ｔ３３）。“認証済”でない場合（Ｔ３３；Ｎｏ）、鍵交換部１６は、上記レコードの「認証状況」に対し、“旧ＰＰ認証中”を設定する（Ｔ３４）。Ｔ３５では、鍵交換部１６は、ビデオカメラ２０−３の旧ＰＰ情報を、旧ＰＰ情報格納領域１７１ｃに“旧ＰＰ情報”として格納させる。Ｔ３６では、鍵交換部１６は、上記“旧ＰＰ情報”から生成された暗号鍵情報を、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅに設定し、ビデオカメラ２０−３に返信する。

図１７は、無線ＡＰ１０からビデオカメラ２０−３に対するＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ１５ａの構成例を示す図である。図１７に示す様に、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ１５ａは、ＨＤＲ、ペイロード、ＵＤＰ、ＩＰ、Ｌ２、Ｌ１の各情報を有する。

図１６に戻り、上記Ｔ３２における判定の結果、上記レコードが存在しない場合（Ｔ３２；Ｎｏ）には、鍵交換部１６は、認証管理テーブル１７１にレコードを追加する（Ｔ３７）。すなわち、鍵交換部１６は、装置識別情報格納領域１７１ａに、上記ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔの送信元である無線端末２０のＩＤを有し、かつ、認証状況格納領域１７１ｂに“認証中”の設定されたレコードを追加する。Ｔ３８では、鍵交換部１６は、上記ＰＰ情報から生成された暗号鍵情報を、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅに設定し、ビデオカメラ２０−３に返信する。

また、上記Ｔ３３における判定の結果、“認証済”である場合（Ｔ３３；Ｙｅｓ）には、鍵交換部１６は、上記レコードの「認証状況」に対し、“認証中”を設定する（Ｔ３９）。設定後は、鍵交換部１６は、上述したＴ３８の処理を実行する。

図１４に戻り、Ｓ１５では、無線ＡＰ１０の鍵交換部１６は、「認証状況」が“切替え待ち”であるビデオカメラ２０−３（図１３参照）に対し、旧ＰＰ＃１によるＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅの返信を行う。

図１８は、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅ送信後における認証管理テーブル１７５のデータ格納例を示す図である。図１８に示す様に、認証管理テーブル１７５では、ビデオカメラ２０−３の「認証状況」が、図１３に示した“切替え待ち”から“旧ＰＰ認証中”に更新されている。

図１４に戻り、Ｓ１６では、無線端末２０（ビデオカメラ２０−３）の鍵交換部２３は、上記ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅを受信すると、変更前の旧ＰＰ情報であるＰＰ＃１を用いて、ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ１６ａを、無線ＡＰ１０宛に送信する。図１９は、ビデオカメラ２０−３から無線ＡＰ１０に対するＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ１６ａの構成例を示す図である。図１９に示す例は、ＰＰ情報が“ＰＰ＃１”である場合の例である。図１９に示す様に、ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ１６ａは、ＨＤＲ、ペイロード、ＵＤＰ、ＩＰ、Ｌ２、Ｌ１の各情報を有する。これらの情報の内、ペイロードは、ＳＫ＿ＰＰ＃１により暗号化されている。なお、ＡＵＴＨ＿Ｎｒは、図１７に示した“Ｎｒ”を基に作成された認証用サインである。

無線ＡＰ１０は、上記ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ１６ａの受信に伴い、認証処理を実行する。

図２０は、ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ１６ａの受信時に無線ＡＰ１０が実行する処理を説明するためのフローチャートである。まずＴ４１では、鍵交換部１６は、上記ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ１６ａの送信元（ビデオカメラ２０−３）に対応するレコードを、認証管理テーブル１７１から抽出する。該レコードが存在する場合（Ｔ４２；Ｙｅｓ）には、鍵交換部１６は、上記レコードの「認証状況」が“認証済”または“切替え待ち”であるか否かを判定する（Ｔ４３）。“認証済”または“切替え待ち”でない場合（Ｔ４３；Ｎｏ）、鍵交換部１６は、上記ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ１６ａのペイロードを複合化し、送信元であるビデオカメラ２０−３の認証を行う（Ｔ４４）。

上記認証がＯＫの場合（Ｔ４５；Ｙｅｓ）、無線ＡＰ１０の鍵交換部１６は、上記ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ１６ａに対する応答信号として、ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅを、ビデオカメラ２０−３に返信する（Ｔ４６）。Ｔ４７では、鍵交換部１６は、上記レコードの「認証状況」が“認証中”であるか否かを判定する（Ｔ４７）。“認証中”でない場合（Ｔ４７；Ｎｏ）、鍵交換部１６は、ＰＰ情報と、該ＰＰ情報から生成された暗号鍵情報とを、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔにより送信する（Ｔ４８）。そして、鍵交換部１６は、上記レコードの「認証状況」に対し、“切替え待ち”を設定する（Ｔ４９）。

上記Ｔ４２における判定の結果、上記レコードが存在しない場合（Ｔ４２；Ｎｏ）あるいは、上記Ｔ４３における判定の結果、“認証済”または“切替え待ち”である場合（Ｔ４３；Ｙｅｓ）には、鍵交換部１６は、上記Ｔ４６と同様の処理を実行する。すなわち、鍵交換部１６は、上記ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅを、ビデオカメラ２０−３に返信する（Ｔ５０）。

上記Ｔ４５における判定の結果、上記認証がＮＧの場合（Ｔ４５；Ｎｏ）には、無線ＡＰ１０の鍵交換部１６は、上記ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ１６ａの送信元（ビデオカメラ２０−３）に対応するレコードを、認証管理テーブル１７１から削除する。その後、上述したＴ５０の処理に移行する。

上記Ｔ４７における判定の結果、“認証中”である場合（Ｔ４７；Ｙｅｓ）には、鍵交換部１６は、上記レコードの「認証状況」に対し、“認証済”を設定する（Ｔ５２）。

図１４に戻り、Ｓ１７では、無線ＡＰ１０の鍵交換部１６は、ビデオカメラ２０−３に対し、ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ１７ａを送信する。

図２１は、無線ＡＰ１０からビデオカメラ２０−３に対するＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ１７ａの構成例を示す図である。図２１に示す例は、ＰＰ情報が“ＰＰ＃１”である場合の例である。図２１に示す様に、ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ１７ａは、ＨＤＲ、ペイロード、ＵＤＰ、ＩＰ、Ｌ２、Ｌ１の各情報を有する。これらの情報の内、ペイロードは、ＳＫ＿ＰＰ＃１により暗号化されている。なお、ＡＵＴＨ＿Ｎｉは、図１５に示した“Ｎｉ”を基に作成された認証用サインである。

図１４に戻り、Ｓ１８では、無線ＡＰ１０と、無線端末２０としてのビデオカメラ２０−３との間で、変更前のＰＰ＃１による暗号化通信が開始される。

Ｓ１９では、無線ＡＰ１０の鍵交換部１６は、上記ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ１７ａに引き続き、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ１９ａを、ビデオカメラ２０−３に送信する。送信後は、鍵交換部１６は、認証管理テーブルを、認証管理テーブル１７４の状態（図１３参照）に更新する。

図２２は、無線ＡＰ１０からビデオカメラ２０−３に対するＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ１９ａの構成例を示す図である。なお、図２２に示す例は、旧ＰＰ情報が“ＰＰ＃１”であり、新ＰＰ情報が“ＰＰ＃２”である場合の例である。図２２に示す様に、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ１９ａは、ＨＤＲ、ペイロード、ＵＤＰ、ＩＰ、Ｌ２、Ｌ１の各情報を有する。これらの情報の内、ペイロードは、ＳＫ＿ＰＰ＃１により暗号化されている。

ビデオカメラ２０−３の鍵交換部２３−３は、変更前のＰＰ情報（ＰＰ＃１）により、上記ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ１７ａを受信する。これにより、鍵交換部２３−３は、変更前のＰＰ情報での認証が無線ＡＰ１０において完了したことを把握する。また、鍵交換部２３−３は、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ１９ａを受信すると、図１１に示した処理を実行する。これにより、変更後の新ＰＰ情報である“ＰＰ＃２”が、ＰＰ情報記憶部２４１（図３参照）に新たに格納される。

図１４に戻り、Ｓ２０では、無線端末２０（ビデオカメラ２０−３）の鍵交換部２３は、無線ＡＰ１０に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ２０ａを送信する。

図２３は、ビデオカメラ２０−３から無線ＡＰ１０に対するＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ２０ａの構成例を示す図である。なお、図２３に示す例は、旧ＰＰ情報が“ＰＰ＃１”であり、新ＰＰ情報が“ＰＰ＃２”である場合の例である。図２３に示す様に、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ２０ａは、ＨＤＲ、ペイロード、ＵＤＰ、ＩＰ、Ｌ２、Ｌ１の各情報を有する。これらの情報の内、ペイロードは、ＳＫ＿ＰＰ＃１により暗号化されている。

無線ＡＰ１０の鍵交換部１６は、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ２０ａ（図２３参照）を受信すると、図１２に示した処理を実行する。

図２４は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ２０ａ受信後における認証管理テーブル１７６のデータ格納例を示す図である。図２４に示す様に、認証管理テーブル１７６では、ビデオカメラ２０−３の「認証状況」が、図１８に示した“旧ＰＰ認証中”から“認証済”に更新されている。また、ビデオカメラ２０−３に対応する「旧ＰＰ情報」及び「旧ＰＰ期限」は、初期化されている。

図１４に戻り、Ｓ２１では、無線ＡＰ１０と、無線端末２０としてのビデオカメラ２０−３との間で、変更後のＰＰ＃２による暗号化通信が開始される。

Ｓ２２では、無線ＡＰ１０は、切替えＴＯ（Time Over）処理を実行する。すなわち、無線ＡＰ１０の鍵交換部１６は、図１２に示した処理を実行し、上記ＰＰ変更要求Ｓ１ａの受信時点から所定時間（例えば、１時間）が経過すると、切替え（ＰＰ情報の変更）の完了しなかった装置のレコードを削除する。図２５は、鍵状態記憶部１７の旧ＰＰ期限設定領域１７ａにおけるデータ設定例を示す図である。図２５に示す様に、旧ＰＰ期限設定領域１７ａには、ＰＰ変更要求が受信された時刻を起算時とする旧ＰＰ情報の有効期間（旧ＰＰ情報による認証が許容される時間）として、“１時間”が設定されている。

図２６は、切替えＴＯ処理の実行後における認証管理テーブル１７７のデータ格納例を示す図である。本実施例では、無線ＡＰ１０と携帯端末２０−４との間では、所定時間内に切替え処理が完了しなかったため、図２６では、有効期間の徒過により、認証管理テーブル１７７から、携帯端末２０−４のレコードが削除されている。

その後、ユーザが移動し、携帯端末２０−４を、無線ＡＰ１０の通信領域内に持ち込むと、ＷｉＦｉ（登録商標）通信が再開される。

図１４のＳ２３では、無線端末２０（携帯端末２０−４）の鍵交換部２３は、変更前のＰＰ情報であるＰＰ＃１により、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ２３ａを、無線ＡＰ１０宛に送信する。ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ２３ａは、図１５に示したＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ１４ａと同様の構成を有するため、その図示及び詳細な説明は省略する。

無線ＡＰ１０は、上記ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ２３ａを受信するが、この時点では、図２６に示した様に、認証管理テーブル１７７に携帯端末２０−４のレコードは存在しない。このため、無線ＡＰ１０の鍵交換部１６は、新しいＰＰ情報であるＰＰ＃２により、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ２４ａを、携帯端末２０−４宛に送信する（Ｓ２４）。ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ２４ａは、図１７に示したＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ１５ａと同様の構成を有するため、その図示及び詳細な説明は省略する。送信後は、鍵交換部１６は、認証管理テーブル１７７を更新する。

図２７は、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ２４ａ送信後における認証管理テーブル１７８のデータ格納例を示す図である。図２７に示す様に、認証管理テーブル１７８では、一旦削除された携帯端末２０−４の「認証状況」が、図２６に示した削除状態から“認証中”に再設定されている。

図１４に戻り、無線端末２０（携帯端末２０−４）の鍵交換部２３は、変更後のＰＰ情報であるＰＰ＃２により、上記ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ２４ａを受信する。Ｓ２５では、鍵交換部２３は、変更前のＰＰ情報であるＰＰ＃１を用いて、ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ２５ａを、無線ＡＰ１０宛に送信する。ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ２５ａは、図１９に示したＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ１６ａと同様の構成を有するため、その図示及び詳細な説明は省略する。

無線ＡＰ１０の鍵交換部１６は、変更前のＰＰ情報（ＰＰ＃１）による上記ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ２５ａの受信に伴い、図２０に示した認証処理を実行する。しかしながら、鍵交換部１６は、この時点では、変更後の新ＰＰ情報（ＰＰ＃２）による複合化ができないため、認証ＮＧ（図２０のＴ４５；Ｎｏ）となる（Ｓ２６）。

Ｓ２７では、無線ＡＰ１０の鍵交換部１６は、変更後の新ＰＰ情報（ＰＰ＃２）を用いて、携帯端末２０−４に対し、ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ２７ａを送信する。ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ２７ａは、図２１に示したＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ１７ａと同様の構成を有するため、その図示及び詳細な説明は省略する。送信後は、鍵交換部１６は、認証管理テーブル１７１を、図２７に示した認証管理テーブル１７８の状態から、図２６に示した認証管理テーブル１７７の状態に、再び更新する。

無線端末２０（携帯端末２０−４）の鍵交換部２３は、変更後の新ＰＰ情報（ＰＰ＃２）を用いて、上記ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ２７ａを受信する。しかしながら、無線端末２０のユーザは、上記認証の結果がＮＧであるため、無線ＡＰ１０との間で、変更前のＰＰ情報（ＰＰ＃１）による通信が不可であることを知る（Ｓ２８）。そこで、ユーザが、新しいＰＰ情報であるＰＰ＃２を、携帯端末２０−４に設定する（Ｓ２９）と、無線端末２０（携帯端末２０−４）の鍵交換部２３は、変更後のＰＰ情報（ＰＰ＃２）に関し、上述したＳ２３〜Ｓ２５、Ｓ２７と同様の処理を実行する。

すなわち、図１４のＳ３０では、無線端末２０（携帯端末２０−４）の鍵交換部２３は、変更後のＰＰ情報であるＰＰ＃２により、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ３０ａを、無線ＡＰ１０宛に送信する。ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ３０ａは、図１５に示したＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ１４ａと同様の構成を有するため、その図示及び詳細な説明は省略する。

無線ＡＰ１０は、上記ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ３０ａを受信するが、この時点では、図２６に示した様に、認証管理テーブル１７７に携帯端末２０−４のレコードは存在しない。このため、無線ＡＰ１０の鍵交換部１６は、新しいＰＰ情報であるＰＰ＃２により、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ３１ａを、携帯端末２０−４宛に送信する（Ｓ３１）。ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ３１ａは、図１７に示したＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ１５ａと同様の構成を有するため、その図示及び詳細な説明は省略する。送信後は、鍵交換部１６は、認証管理テーブル１７１を、図２６に示した認証管理テーブル１７７の状態から、図２７に示した認証管理テーブル１７８の状態に、再び更新する。

図１４に戻り、無線端末２０（携帯端末２０−４）の鍵交換部２３は、変更後のＰＰ情報であるＰＰ＃２により、上記ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ３１ａを受信する。Ｓ３２では、鍵交換部２３は、変更後のＰＰ情報であるＰＰ＃２を用いて、ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ３２ａを、無線ＡＰ１０宛に送信する。ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ３２ａは、図１９に示したＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ１６ａと同様の構成を有するため、その図示及び詳細な説明は省略する。

無線ＡＰ１０の鍵交換部１６は、変更後のＰＰ情報（ＰＰ＃２）による上記ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ３２ａの受信に伴い、図２０に示した認証処理を実行する。現時点では、鍵交換部１６は、変更後の新ＰＰ情報（ＰＰ＃２）により複合化が可能なため、認証ＯＫ（図２０のＴ４５；Ｙｅｓ）となる（Ｓ３３）。

Ｓ３４では、無線ＡＰ１０の鍵交換部１６は、変更後の新ＰＰ情報（ＰＰ＃２）を用いて、携帯端末２０−４に対し、上記ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ３４ａを送信する。ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ３４ａは、図２１に示したＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ１７ａと同様の構成を有するため、その図示及び詳細な説明は省略する。送信後は、鍵交換部１６は、認証管理テーブル１７８を更新する。

図２８は、ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ３４ａ送信後における認証管理テーブル１７９のデータ格納例を示す図である。図２８に示す様に、認証管理テーブル１７９では、認証に成功した携帯端末２０−４の「認証状況」が、図２７に示した“認証中”から“認証済”に更新されている。

無線端末２０（携帯端末２０−４）の鍵交換部２３は、変更後の新ＰＰ情報（ＰＰ＃２）を用いて、上記ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ３４ａを受信する。無線端末２０のユーザは、上記認証の結果がＯＫであるため、無線ＡＰ１０との間で、変更後のＰＰ情報（ＰＰ＃２）による通信が可能であることを知る（Ｓ３５）。

Ｓ３６では、無線ＡＰ１０と、無線端末２０としての携帯端末２０−４との間で、変更後のＰＰ＃２による暗号化通信が開始される。これにより、旧ＰＰ情報から新ＰＰ情報への移行に際しての、ユーザへのサービス提供の中断が回避される。

以上で、無線ＡＰ１０が、無線端末２０からの要求に応じてＰＰ情報を変更する処理についての説明を終了する。

続いて、無線ＡＰ１０が、成りすまし等の攻撃検知時にＰＰ情報を変更する処理について説明する。説明の前提として、無線ＡＰ１０と、その通信相手である全ての無線端末２０との間の認証が、ＰＰ情報をＰＰ＃２として完了しているものとする。従って、認証管理テーブル１７１は、図２８に示した認証管理テーブル１７９の状態である。無線端末２０は、例えば、ＰＣ（Personal Computer）２０−１、ＴＶ２０−２、ビデオカメラ２０−３、携帯端末２０−４、センサ２０−５、エアコン２０−６である。これらの無線端末２０の内、ＰＣ２０−１、ＴＶ２０−２、センサ２０−５、エアコン２０−６は、ＷｉＦｉ（登録商標）通信中であり、ビデオカメラ２０−３、携帯端末２０−４は、ＷｉＦｉ（登録商標）停止中である。以下の説明では、各無線端末２０間で共通する構成要素には、末尾が同一の参照符号を用いると共に、その詳細な説明は省略する。

図２９は、成りすまし検知時におけるシーケンス図の前半部分である。図２９において、実線は平文による通信を示し、破線は暗号鍵による暗号化通信を示す。また、一点鎖線は、端点の装置（例えば、攻撃者ＰＣ３０、携帯端末２０−４）と無線ＡＰ１０との間の通信が途絶したこと（通信停止状態）を示す。また、ＫＥ＿ＰＰ＃ｎは、パスフレーズＰＰ＃ｎを基に生成された暗号鍵を示す。ＳＫ＿ＰＰ＃ｎは、上記ＫＥ＿ＰＰ＃ｎから生成された暗号鍵を示す。ＳＫ＿ＰＰ＃ｎ｛ｐａｙｌｏａｄ｝は、ｐａｙｌｏａｄをＳＫ＿ＰＰ＃ｎにより暗号化することを示す。更に、実線矢印の直上に、信号のメッセージタイプを記載し、直下に、信号のペイロードを記載している。

まずＳ４１では、ユーザが攻撃者ＰＣ３０を操作して、携帯端末２０−４のユーザに成りすまし、無線ＡＰ１０へ、ＳＫ＿ＰＰ＃２を送信する。その後、真のユーザにより、携帯端末２０−４の電源が投入される（Ｓ４２）と、無線端末２０（携帯端末２０−４）の鍵交換部２３は、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ４３ａを、無線ＡＰ１０宛に送信する（Ｓ４３）。ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ４３ａは、図１５に示したＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ１４ａと同様の構成を有するため、その図示及び詳細な説明は省略する。

無線ＡＰ１０は、上記ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ４３ａの受信により、攻撃者ＰＣ３０のユーザによる携帯端末２０−４への成りすましを検知し、ＰＰ変更処理を実行する。

図３０は、成りすまし検知時に無線ＡＰ１０が実行する処理を説明するためのフローチャートである。まずＴ６１では、無線ＡＰ１０の鍵交換部１６は、新ＰＰ情報“ＰＰ＃３”をランダムに生成する。次に、鍵交換部１６は、成りすまされた無線端末２０（携帯端末２０−４）に対応するレコードを、認証管理テーブル１７９から削除する（Ｔ６２）。

以下、無線ＡＰ１０の鍵交換部１６は、Ｔ６３〜Ｔ７０の各処理を実行するが、これらの処理は、上述した図９のＴ１〜Ｔ８の各処理と同様である。従って、その詳細な説明は省略する。

Ｔ７１は、鍵交換部１６は、Ｔ６１にて生成されたＰＰ情報を、認証管理テーブル１７１のＰＰ情報（図２の左上）に、新ＰＰ情報として設定する。Ｔ７２では、鍵交換部１６は、上記レコードの装置識別情報の各装置に対し、上記新ＰＰ情報と、該新ＰＰ情報から生成された暗号鍵情報とを、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔにより送信する。

上述した一連のＰＰ変更処理の完了後、無線ＡＰ１０は、攻撃者ＰＣ３０と、攻撃者ＰＣ３０の成りすました携帯端末２０−４との通信を停止する（Ｓ４４、Ｓ４５）。

無線ＡＰ１０の鍵交換部１６は、成りすまされた無線端末２０（携帯端末２０−４）を除いた、図２８に示した「認証状況」が“認証済”である全ての無線端末２０に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔを送信する。該送信は、新しいＰＰ情報であるＰＰ＃３により行われる。上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔは、図２２に示したＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ１９ａと同様の構成を有するため、その図示及び詳細な説明は省略する。送信後は、鍵交換部１６は、認証管理テーブル１７９を更新する。

図３１は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔ送信後における認証管理テーブル１７１０のデータ格納例を示す図である。図３１に示す様に、認証管理テーブル１７１０では、Ｔ６２において削除された携帯端末２０−４のレコードを除き、全てのレコードの「認証状況」が、図２８に示した“認証済”から“切替え待ち”に更新されている。また、携帯端末２０−４を除く全てのレコードの「旧ＰＰ情報」が“ＰＰ＃２”に再設定され、「旧ＰＰ期限」が“１１：００”に再設定されている。

具体的には、図２９のＳ４６では、無線ＡＰ１０の鍵交換部１６は、ＰＣ２０−１に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ４６ａを送信する。ＰＣ２０−１の鍵交換部２３−１は、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ４６ａの受信に伴い、図１１に示した処理を実行し、最新のＰＰ情報である“ＰＰ＃３”を、ＰＰ情報記憶部２４１（図３参照）に格納させる。

Ｓ４７では、無線端末２０（ＰＣ２０−１）の鍵交換部２３は、新ＰＰ情報“ＰＰ＃３”を用いて、無線ＡＰ１０に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ４７ａを送信する。無線ＡＰ１０の鍵交換部１６は、該ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ４７ａを受信すると、図１２に示した処理を実行する。これにより、無線ＡＰ１０と、無線端末２０としてのＰＣ２０−１との間で、変更後のＰＰ＃３による暗号化通信が開始される（Ｓ４８）。

同様に、Ｓ４９では、無線ＡＰ１０の鍵交換部１６は、ＴＶ２０−２に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ４９ａを送信する。ＴＶ２０−２の鍵交換部２３−２は、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ４９ａの受信に伴い、図１１に示した処理を実行する。Ｓ５０では、無線端末２０（ＴＶ２０−２）の鍵交換部２３は、新ＰＰ情報“ＰＰ＃３”を用いて、無線ＡＰ１０に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ５０ａを送信する。無線ＡＰ１０の鍵交換部１６は、該ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ５０ａを受信すると、図１２に示した処理を実行する。

受信後は、鍵交換部１６は、認証管理テーブル１７１０を更新する。

図３２は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ５０ａ受信後における認証管理テーブル１７１１のデータ格納例を示す図である。図３２に示す様に、認証管理テーブル１７１１では、全ての無線端末２０の「認証状況」の内、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅの有った装置（ＰＣ２０−１、ＴＶ２０−２）の識別情報に対応する「認証状況」が“認証済”に更新されている。また、上記識別情報に対応する「旧ＰＰ情報」及び「旧ＰＰ期限」は、初期化されている。

図２９に戻り、次のＳ５１〜Ｓ５３では、他の無線端末２０（ビデオカメラ２０−３、センサ２０−５、エアコン２０−６）に関し、上述したＳ４６と同様の処理が実行される。

まずＳ５４では、ユーザがＰＣ２０−１を操作し、無線ＡＰ１０のＰＰの変更を指示すると、ＰＣ２０−１のＰＰ変更部２５−１は、ＰＰ変更要求Ｓ５４ａを無線ＡＰ１０へ送信する。ＰＰ変更要求Ｓ５４ａは、図８に示したＰＰ変更要求Ｓ１ａと同様の構成を有するため、その図示及び詳細な説明は省略する。

無線ＡＰ１０のＰＰ変更部１５は、ＰＣ２０−１から上記ＰＰ変更要求Ｓ５４ａを受信すると、図９に示した処理を実行する。

図３３は、成りすまし検知時におけるシーケンス図の後半部分である。無線ＡＰ１０のＰＰ変更部１５は、図３２に示した認証管理テーブル１７１１の「認証状況」が“認証済”である全ての無線端末２０（ＰＣ２０−１、ＴＶ２０−２）に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ５５ａを送信する（Ｓ５５、Ｓ５８）。該送信は、新しいＰＰ情報であるＰＰ＃４により行われる。ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ５５ａは、図２２に示したＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ１９ａと同様の構成を有するため、その図示及び詳細な説明は省略する。

送信後は、鍵交換部１６は、認証管理テーブル１７１１を更新する。

図３４は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ５５ａ送信後における認証管理テーブル１７１２のデータ格納例を示す図である。図３４に示す様に、認証管理テーブル１７１２では、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ５５ａの送信先である無線端末２０（ＰＣ２０−１、ＴＶ２０−２）の「認証状況」が、図３２に示した“認証済”から“切替え待ち”に更新されている。また、ＰＣ２０−１、ＴＶ２０−２のレコードの「旧ＰＰ情報」が“ＰＰ＃３”に再設定され、「旧ＰＰ期限」が“１２：００”に再設定されている。

Ｓ５６では、無線端末２０（ＰＣ２０−１）の鍵交換部２３は、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ５５ａを受信すると、図１１に示した処理を実行し、最新のＰＰ情報である“ＰＰ＃４”を、ＰＰ情報記憶部２４１（図３参照）に格納させる。そして、鍵交換部２３は、新ＰＰ情報“ＰＰ＃４”を用いて、無線ＡＰ１０に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ５６ａを送信する。無線ＡＰ１０の鍵交換部１６は、該ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ５６ａを受信すると、図１２に示した処理を実行する。これにより、無線ＡＰ１０と、無線端末２０としてのＰＣ２０−１との間で、変更後のＰＰ＃４による暗号化通信が開始される（Ｓ５７）。

同様に、Ｓ５８では、無線ＡＰ１０の鍵交換部１６は、ＴＶ２０−２に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ５８ａを送信する。ＴＶ２０−２の鍵交換部２３−２は、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ５８ａの受信に伴い、図１１に示した処理を実行する。Ｓ５９では、無線端末２０（ＴＶ２０−２）の鍵交換部２３は、新ＰＰ情報“ＰＰ＃４”を用いて、無線ＡＰ１０に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ５９ａを送信する。無線ＡＰ１０の鍵交換部１６は、該ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ５９ａを受信すると、図１２に示した処理を実行する。

これに対し、無線ＡＰ１０の鍵交換部１６は、センサ２０−５から、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ６０ａを、旧ＰＰ情報“ＰＰ＃３”により受信すると、図１２に示した処理を実行する（Ｓ６０）。Ｓ６１では、無線ＡＰ１０の鍵交換部１６は、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ６０ａの送信元であるセンサ２０−５に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ６１ａを送信する。該送信は、新しいＰＰ情報であるＰＰ＃４により行われる。上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ６１ａは、図２２に示したＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ１９ａと同様の構成を有するため、その図示及び詳細な説明は省略する。Ｓ６２では、無線端末２０（センサ２０−５）の鍵交換部２３は、新ＰＰ情報“ＰＰ＃４”を用いて、無線ＡＰ１０に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ６２ａを送信する。無線ＡＰ１０の鍵交換部１６は、該ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ６２ａを受信すると、図１２に示した処理を実行する。

無線ＡＰ１０の鍵交換部１６は、エアコン２０−６に関しても、上述したセンサ２０−５と同様の処理を実行する。すなわち、無線ＡＰ１０の鍵交換部１６は、エアコン２０−６から、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ６３ａを、旧ＰＰ情報“ＰＰ＃３”により受信すると、図１２に示した処理を実行する（Ｓ６３）。Ｓ６４では、無線ＡＰ１０の鍵交換部１６は、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ６３ａの送信元であるエアコン２０−６に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ６４ａを送信する。該送信は、新しいＰＰ情報であるＰＰ＃４により行われる。上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ６４ａは、図２２に示したＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ１９ａと同様の構成を有するため、その図示及び詳細な説明は省略する。Ｓ６５では、無線端末２０（エアコン２０−６）の鍵交換部２３は、新ＰＰ情報“ＰＰ＃４”を用いて、無線ＡＰ１０に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ６５ａを送信する。無線ＡＰ１０の鍵交換部１６は、該ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ６５ａを受信すると、図１２に示した処理を実行する。

鍵交換部１６は、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ６５ａの受信後、認証管理テーブル１７１２を更新する。

図３５は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ６５ａ受信後における認証管理テーブル１７１３のデータ格納例を示す図である。図３５に示す様に、認証管理テーブル１７１３では、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ５６ａ、Ｓ５９ａ、Ｓ６２ａ、Ｓ６５ａの順次送信先である無線端末２０（ＰＣ２０−１、ＴＶ２０−２、センサ２０−５、エアコン２０−６）の「認証状況」が、図３４に示した“切替え待ち”から“認証済”に更新されている。これに伴い、上記無線端末２０の装置識別情報に対応する「旧ＰＰ情報」及び「旧ＰＰ期限」は、初期化されている。

その後、真のユーザが、旧ＰＰ情報（“ＰＰ＃２”、“ＰＰ＃３”）の有効期限内にビデオカメラ２０−３の電源を投入する（図３３のＳ６６）と、無線端末２０（ビデオカメラ２０−３）の鍵交換部２３は、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ６７ａを、無線ＡＰ１０宛に送信する（Ｓ６７）。ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ６７ａは、図１５に示したＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ１４ａと同様の構成を有するため、その図示及び詳細な説明は省略する。

無線ＡＰ１０は、上記ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ６７ａを受信すると、図１６に示した処理を実行するが、この時点では、図３５に示した様に、ビデオカメラ２０−３の「認証状況」は“切替え待ち”である。このため、無線ＡＰ１０の鍵交換部１６は、旧ＰＰ情報であるＰＰ＃２により、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ６８ａを、ビデオカメラ２０−３宛に送信する（Ｓ６８）。ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ６８ａは、図１７に示したＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ１５ａと同様の構成を有するため、その図示及び詳細な説明は省略する。送信後は、鍵交換部１６は、認証管理テーブル１７１３を更新する。

図３６は、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ６８ａ送信後における認証管理テーブル１７１４のデータ格納例を示す図である。図３６に示す様に、認証管理テーブル１７１４では、送信先であるビデオカメラ２０−３の「認証状況」が、図３５に示した“切替え待ち”から“旧ＰＰ認証中”に更新されている。また、ビデオカメラ２０−３のレコードの内、「旧ＰＰ情報」及び「旧ＰＰ期限」が、それぞれ“ＰＰ＃２”及び“１１：００”に再設定されている。

図３３に戻り、無線端末２０（ビデオカメラ２０−３）の鍵交換部２３は、変更前のＰＰ情報であるＰＰ＃２により、上記ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ６８ａを受信する。Ｓ６９では、鍵交換部２３は、変更前のＰＰ情報であるＰＰ＃２を用いて、ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ６９ａを、無線ＡＰ１０宛に送信する。ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ６９ａは、図１９に示したＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ１６ａと同様の構成を有するため、その図示及び詳細な説明は省略する。

無線ＡＰ１０の鍵交換部１６は、変更前のＰＰ情報（ＰＰ＃２）による上記ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ６９ａの受信に伴い、図２０に示した認証処理を実行する。この時点では、鍵交換部１６は、変更前の旧ＰＰ情報（ＰＰ＃２）により複合化が可能なため、認証ＯＫ（図２０のＴ４５；Ｙｅｓ）となる（Ｓ７０）。

Ｓ７１では、無線ＡＰ１０の鍵交換部１６は、変更前の旧ＰＰ情報（ＰＰ＃２）を用いて、ビデオカメラ２０−３に対し、ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ７１ａを送信する。ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ７１ａは、図２１に示したＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ１７ａと同様の構成を有するため、その図示及び詳細な説明は省略する。

無線端末２０（ビデオカメラ２０−３）の鍵交換部２３は、変更前の旧ＰＰ情報（ＰＰ＃２）を用いて、上記ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ７１ａを受信する。無線端末２０のユーザは、上記認証の結果がＯＫであるため、無線ＡＰ１０との間で、変更前のＰＰ情報（ＰＰ＃２）による通信が可能であることを知る（Ｓ７２）。Ｓ７３では、無線ＡＰ１０と、無線端末２０としてのビデオカメラ２０−３との間で、変更前のＰＰ＃２による暗号化通信が開始される。これにより、旧ＰＰ情報から新ＰＰ情報への移行に際しての、ユーザへのサービス提供の中断が回避される。

Ｓ７４では、無線ＡＰ１０の鍵交換部１６は、ビデオカメラ２０−３に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ７４ａを送信する。ビデオカメラ２０−３の鍵交換部２３−３は、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔＳ７４ａの受信に伴い、図１１に示した処理を実行する。実行後は、鍵交換部２３−３は、変更後の新しいＰＰ情報であるＰＰ＃４を、ＰＰ情報記憶部２４１（図３参照）に格納させる。Ｓ７５では、鍵交換部２３は、新ＰＰ情報“ＰＰ＃４”を用いて、無線ＡＰ１０に対し、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ７５ａを送信する。無線ＡＰ１０の鍵交換部１６は、該ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ７５ａを受信すると、図１２に示した処理を実行する。

受信後は、鍵交換部１６は、認証管理テーブル１７１４を更新する。

図３７は、ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ７５ａ受信後における認証管理テーブル１７１５のデータ格納例を示す図である。図３７に示す様に、認証管理テーブル１７１５では、全ての無線端末２０の「認証状況」の内、上記ＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅＳ７５ａの有った装置（ビデオカメラ２０−３）の識別情報に対応する「認証状況」が“認証済”に更新されている。また、上記識別情報に対応する「旧ＰＰ情報」及び「旧ＰＰ期限」は、初期化されている。

図３３に戻り、次のＳ７６〜Ｓ８３では、新ＰＰ情報である“ＰＰ＃４”に関し、上述したＳ２９〜Ｓ３６（図１４参照）と同様の処理が実行される。

次に、無線ＡＰ１０は、図１２に示した処理を周期的（例えば、１分周期）に実行する。そして、無線ＡＰ１０は、旧ＰＰ期限経過レコード削除処理を実行する。図３８は、無線ＡＰ１０の実行する旧ＰＰ期限経過レコード削除処理を説明するためのフローチャートである。Ｔ８１では、無線ＡＰ１０の鍵交換部１６は、ＰＰ変更要求の受信時刻と現在時刻とを比較し、旧ＰＰ期限を経過したレコードを、認証管理テーブル１７１から削除する。すなわち、鍵交換部１６は、ＰＰ変更要求の受信時からの経過時間が、鍵状態記憶部１７の旧ＰＰ期限設定領域１７ａに設定された時間（例えば、１時間）に達すると、ＰＰ情報の変更（切替え）が行われなかった無線端末２０（携帯端末２０−４）のレコードを削除する。その結果、認証管理テーブル１７１は、図３７に示した状態となる。

ユーザは、現時点で、携帯端末２０−４が攻撃を受けたこと、及びＰＰ情報を新ＰＰ情報（ＰＰ＃４）に変更したことを知っているため、新しいＰＰ情報であるＰＰ＃４を、携帯端末２０−４に設定する（Ｓ７６）。Ｓ７７では、無線端末２０（携帯端末２０−４）の鍵交換部２３は、変更後のＰＰ情報であるＰＰ＃４により、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ７７ａを、無線ＡＰ１０宛に送信する。ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ７７ａは、図１５に示したＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ１４ａと同様の構成を有するため、その図示及び詳細な説明は省略する。

無線ＡＰ１０は、上記ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔＳ７７ａを受信するが、この時点では、図３７に示した様に、認証管理テーブル１７１５に携帯端末２０−４のレコードは存在しない。このため、無線ＡＰ１０の鍵交換部１６は、新しいＰＰ情報であるＰＰ＃４により、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ７８ａを、携帯端末２０−４宛に送信する（Ｓ７８）。ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ７８ａは、図１７に示したＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ１５ａと同様の構成を有するため、その図示及び詳細な説明は省略する。

送信後は、鍵交換部１６は、認証管理テーブル１７７を更新する。

図３９は、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ７８ａ送信後における認証管理テーブル１７１６のデータ格納例を示す図である。図３９に示す様に、認証管理テーブル１７１６では、一旦削除された携帯端末２０−４の「認証状況」が、図３７に示した削除状態から“認証中”に再設定されている。

図３３に戻り、無線端末２０（携帯端末２０−４）の鍵交換部２３は、変更後のＰＰ情報であるＰＰ＃４により、上記ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅＳ７８ａを受信する。Ｓ７９では、鍵交換部２３は、変更後のＰＰ情報であるＰＰ＃４を用いて、ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ７９ａを、無線ＡＰ１０宛に送信する。ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ７９ａは、図１９に示したＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ１６ａと同様の構成を有するため、その図示及び詳細な説明は省略する。

無線ＡＰ１０の鍵交換部１６は、変更後のＰＰ情報（ＰＰ＃４）による上記ＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔＳ７９ａの受信に伴い、図２０に示した認証処理を実行する。現時点では、鍵交換部１６は、変更後の新ＰＰ情報（ＰＰ＃４）により複合化が可能なため、認証ＯＫ（図２０のＴ４５；Ｙｅｓ）となる（Ｓ８０）。

Ｓ８１では、無線ＡＰ１０の鍵交換部１６は、変更後の新ＰＰ情報（ＰＰ＃４）を用いて、携帯端末２０−４に対し、ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ８１ａを送信する。ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ８１ａは、図２１に示したＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ１７ａと同様の構成を有するため、その図示及び詳細な説明は省略する。送信後は、鍵交換部１６は、認証管理テーブル１７１５を更新する。

図４０は、ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ８１ａ送信後における認証管理テーブル１７１７のデータ格納例を示す図である。図４０に示す様に、認証管理テーブル１７１７は、認証に成功した携帯端末２０−４の「認証状況」が、図３９に示した“認証中”から“認証済”に更新されている。

無線端末２０（携帯端末２０−４）の鍵交換部２３は、変更後の新ＰＰ情報（ＰＰ＃４）を用いて、上記ＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅＳ８１ａを受信する。無線端末２０のユーザは、上記認証の結果がＯＫであるため、無線ＡＰ１０との間で、変更後のＰＰ情報（ＰＰ＃４）による通信が可能であることを知る（Ｓ８２）。

Ｓ８３では、無線ＡＰ１０と、無線端末２０としての携帯端末２０−４との間で、変更後の最新ＰＰ＃４による暗号化通信が開始される。これにより、旧ＰＰ情報から新ＰＰ情報への移行に際しての、ユーザへのサービス提供の中断が回避される。

以上で、無線ＡＰ１０が、成りすまし等の攻撃検知時にＰＰ情報を変更する処理についての説明を終了する。

以上説明した様に、無線通信システム１は、複数の無線端末と、該複数の無線端末と通信を行う無線ＡＰ１０とを有する。無線ＡＰ１０は、複数の無線端末と通信を行う。無線ＡＰ１０は、ＰＰ変更部１５と無線ＩＦ１２と鍵交換部１６とを有する。ＰＰ変更部１５は、複数の無線端末の認証情報（ＰＰ情報）の変更を決定する。無線ＩＦ１２は、ＰＰ変更部１５により上記認証情報の変更が決定された後に、複数の無線端末の内、少なくとも１つの無線端末２０からの通信要求を受信する。鍵交換部１６は、上記通信要求の送信元の無線端末２０に対し、上記変更の前の認証情報を用いて、変更後の認証情報を通知する。また、無線端末２０は、ＰＰ変更部２５と鍵交換部２３とを有する。ＰＰ変更部２５は、無線ＡＰ１０に上記通信要求を送信する。鍵交換部２３は、無線ＡＰ１０から通知された上記変更後の認証情報を、上記変更の前の認証情報を用いて取得する。

従って、無線ＡＰ１０は、無線ＡＰ１０と無線通信する機器（例えば、無線端末２０）との通信を途絶させることなく、ＰＰ情報を変更することができる。その結果、無線ＡＰ１０は、ＰＰ情報を容易に変更することが可能となる。

また、無線ＡＰ１０において、ＰＰ変更部１５は、上記複数の無線端末の内、少なくとも１つの無線端末２０からの認証情報変更要求が受信された場合に、上記複数の無線端末の認証情報の変更を決定するものとしてもよい。これにより、無線ＡＰ１０は、無線端末２０からの要求に応じて、ＰＰ情報を容易に変更することができる。

更に、無線ＡＰ１０において、ＰＰ変更部１５は、上記複数の無線端末以外の無線端末による認証情報の不正使用（例えば、成りすまし）が検知された場合に、上記複数の無線端末の認証情報の変更を決定するものとしてもよい。これにより、無線ＡＰ１０は、例えば、攻撃者ＰＣ３０が無線ＡＰ１０に不正にアクセスした場合にも、ＰＰ情報を容易に変更することができる。

また、無線ＡＰ１０において、鍵交換部１６は、無線端末２０から受信された認証情報（ＰＰ情報）を用いて、無線端末２０に対する認証処理を実行するものとしてもよい。鍵交換部１６は、図１４のＳ２５〜Ｓ２７に示した様に、上記認証情報が変更前の認証情報である場合には、無線端末２０に対し、変更後の認証情報を用いて認証失敗を通知する。一方、鍵交換部１６は、図１４のＳ３２〜Ｓ３４に示した様に、上記認証情報が変更後の認証情報である場合には、無線端末２０に対し、上記変更後の認証情報を用いて認証成功を通知する。これにより、無線ＡＰ１０は、古い認証情報しかもたない無線端末２０に対し、新しい認証情報への更新を促し、新しい認証情報による無線端末２０の認証を行うことができる。その結果、無線ＡＰ１０と無線端末２０との間で、新しい認証情報の適用された無線通信が可能となる。

なお、上記実施例では、無線通信方式としてＷｉ−Ｆｉ（登録商標）を例示したが、例えば、ＷｉＭＡＸ（Worldwide interoperability for Microwave Access）、ＬＴＥ（Long Term Evolution）、Ｗ−ＣＤＭＡ（Wideband−Code Division Multiple Access）等、他の無線通信方式であってもよい。また、上記実施例では、ＰＤＵ（Protocol Data Unit）として、パケットを想定したが、これに限らない。例えば、ネットワーク種別に応じて、フレームや、ＡＴＭ（Asynchronous Transfer Mode）のセル等、他のＰＤＵに対して、上記実施例を適用してもよい。また、無線ＡＰ１０と無線通信可能な無線端末２０の数についても、６台に限らず、攻撃者ＰＣ３０を除いて２台以上であればよい。

更に、上記実施例では、ＰＰ情報が変更される契機として、無線端末２０からの通信要求の発生や不正使用の検知を例示したが、必ずしもこれらに限らない。例えば、最後の更新から所定期間（例えば、三ヶ月）の経過、無線ＡＰ１０の管理者による指示操作、装置故障や動作不良からの復旧、定期期間の満了等を契機として、ＰＰ情報が変更されるものとしてもよい。

また、無線通信システム１の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的態様は、図示のものに限らず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することもできる。例えば、無線ＡＰ１０のパケット転送部１３とパケット中継部１４、あるいは、無線端末２０の鍵交換部２３と鍵状態記憶部２４をそれぞれ１つの構成要素として統合してもよい。反対に、ＰＰ変更部１５に関し、認証情報変更要求が受信された場合に認証情報の変更を決定する部分と、認証情報の不正使用が検知された場合に認証情報の変更を決定する部分とに分散してもよい。更に、各種情報の格納部としての記憶部１０ｅを、無線ＡＰ１０の外部装置として、ネットワークやケーブル経由で接続する様にしてもよい。

１無線通信システム
１０無線ＡＰ
１０ａ有線ＩＦ
１０ｂ無線ＩＦ
１０ｃパケット転送制御部
１０ｄ制御部
１０ｅ記憶部
１１有線ＩＦ
１２無線ＩＦ
１３パケット転送部
１４パケット中継部
１５ＰＰ変更部
１６鍵交換部
１７鍵状態記憶部
１７ａ旧ＰＰ期限設定領域
２０無線端末
２０−１ＰＣ
２０−２ＴＶ
２０−３ビデオカメラ
２０−４携帯端末
２０−５センサ
２０−６エアコン
２０ａ無線ＩＦ
２０ｂ制御部
２０ｃ記憶部
２０ｄ入出力部
２１無線ＩＦ
２２パケット送受信部
２３鍵交換部
２４鍵状態記憶部
２５ＰＰ変更部
２６入出力制御部
３０攻撃者ＰＣ
１７１〜１７１７認証管理テーブル
１７１ａ〜１７１７ａ装置識別情報格納領域
１７１ｂ〜１７１７ｂ認証状況格納領域
１７１ｃ〜１７１７ｃ旧ＰＰ情報格納領域
１７１ｄ〜１７１７ｄ旧ＰＰ期限格納領域
２４１ＰＰ情報記憶部
Ｓ１ａＰＰ変更要求
Ｓ１４ａ、Ｓ２３ａ、Ｓ３０ａ、Ｓ４３ａ、Ｓ６７ａ、Ｓ７７ａ、ＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｑｕｅｓｔ
Ｓ１５ａ、Ｓ２４ａ、Ｓ３１ａ、Ｓ６８ａ、Ｓ７８ａＩＫＥ＿ＳＡ＿ＩＮＩＴＲｅｓｐｏｎｓｅ
Ｓ１６ａ、Ｓ２５ａ、Ｓ３２ａ、Ｓ６９ａ、Ｓ７９ａＩＫＥ＿ＡＵＴＨＲｅｑｕｅｓｔ
Ｓ１７ａ、Ｓ２７ａ、Ｓ３４ａ、Ｓ７１ａＩＫＥ＿ＡＵＴＨＲｅｓｐｏｎｓｅ
Ｓ２ａ、Ｓ１９ａ、Ｓ４６ａ、Ｓ４９ａ、Ｓ５５ａ、Ｓ５８ａ、Ｓ６１ａＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｑｕｅｓｔ
Ｓ３ａ、Ｓ６ａ、Ｓ９ａ、Ｓ１２ａ、Ｓ２０ａ、Ｓ４７ａ、Ｓ５０ａ、Ｓ５６ａ、Ｓ５９ａ、Ｓ６０ａ、Ｓ６２ａ、Ｓ６３ａＣＲＥＡＴＥ＿ＣＨＩＬＤＳＡＲｅｓｐｏｎｓｅ

Claims

複数の無線端末と通信を行う無線通信装置であって、
前記複数の無線端末の認証情報の変更を決定する決定部と、
前記決定部により前記認証情報の変更が決定された後に、前記複数の無線端末の内、少なくとも１つの無線端末からの通信要求を受信する受信部と、
前記通信要求の送信元の無線端末に対し、前記変更の前の認証情報を用いて、変更後の認証情報を通知する通知部と
を有することを特徴とする無線通信装置。
前記決定部は、前記複数の無線端末の内、少なくとも１つの無線端末からの認証情報変更要求が受信された場合に、前記複数の無線端末の認証情報の変更を決定することを特徴とする請求項１に記載の無線通信装置。
前記決定部は、前記複数の無線端末以外の無線端末による認証情報の不正使用が検知された場合に、前記複数の無線端末の認証情報の変更を決定することを特徴とする請求項１に記載の無線通信装置。
前記通知部は、前記無線端末から受信された認証情報を用いて、前記無線端末に対する認証処理を実行し、前記認証情報が変更前の認証情報である場合には、前記無線端末に対し、変更後の認証情報を用いて認証失敗を通知すると共に、前記認証情報が変更後の認証情報である場合には、前記無線端末に対し、前記変更後の認証情報を用いて認証成功を通知することを特徴とする請求項１に記載の無線通信装置。
複数の無線端末と、該複数の無線端末と通信を行う無線通信装置とを有する無線通信システムであって、
前記無線通信装置は、
前記複数の無線端末の認証情報の変更を決定する決定部と、
前記決定部により前記認証情報の変更が決定された後に、前記複数の無線端末の内、少なくとも１つの無線端末からの通信要求を受信する受信部と、
前記通信要求の送信元の無線端末に対し、前記変更の前の認証情報を用いて、変更後の認証情報を通知する通知部とを有し、
前記無線端末は、
前記無線通信装置に前記通信要求を送信する送信部と、
前記無線通信装置から通知された前記変更後の認証情報を、前記変更の前の認証情報を用いて取得する取得部と
を有することを特徴とする無線通信システム。
複数の無線端末と通信を行う無線通信装置が、
前記複数の無線端末の認証情報の変更を決定し、
前記認証情報の変更が決定された後に、前記複数の無線端末の内、少なくとも１つの無線端末からの通信要求を受信し、
前記通信要求の送信元の無線端末に対し、前記変更の前の認証情報を用いて、変更後の認証情報を通知する
ことを特徴とする無線通信方法。