以下、本発明に係る通信装置について、図面を参照しながら詳細に説明する。以下では、IEEE802.11シリーズに準拠した無線LANシステムを用いた例について説明するが、本発明は他の通信方式に適用することもできる。
本実施形態に好適な事例におけるハードウェア構成について説明する。
図1は、本実施形態における通信装置の構成例を表すブロック図である。101は通信装置全体を示す。102は、記憶部103に記憶される制御プログラムを実行することにより装置全体を制御する制御部である。制御部102は、他の通信装置との間での暗号鍵交換のシーケンス制御も行う。103は制御部102が実行する制御プログラムと、通信パラメータ等の各種情報を記憶する記憶部である。後述する動作フローチャート、シーケンスチャートの各種動作は、記憶部103に記憶された制御プログラムを制御部102が実行することにより行われる。104は無線通信を行うための無線部である。105は各種表示を行う表示部でありLCDやLEDのように視覚で認知可能な情報の出力、あるいはスピーカなどの音出力が可能な機能を有する。107はアンテナ制御部、そして108はアンテナである。
図3は、本実施形態における通信装置が実行するソフトウェア機能ブロックの構成例を表すブロック図である。
301は端末全体を示している。302は各種通信にかかわるパケットを受信するパケット受信部である。303は各種通信にかかわるパケットを送信するパケット送信部である。304はプローブリクエストなどの機器検索信号の送信を制御する検索信号送信部である。後述するプローブリクエストの送信は、検索信号送信部304により行われる。また、受信したプローブリクエストに対する応答信号であるプローブレスポンスの送信も検索信号送信部304により行われる。
305は他の端末からのプローブリクエストなどの機器検索信号の受信を制御する検索信号受信部である。後述するプローブリクエストの受信は、検索信号受信部305により行われる。また、プローブレスポンスの受信も検索信号受信部305により行われる。なお、プローブレスポンスには、プローブレスポンスを送信する機器の各種情報(自己情報)が付加されている。
306は他の通信装置との間でのセッション鍵、グループ鍵の交換処理におけるシーケンス制御などを司る鍵交換制御部である。本実施形態において例示する、WPA鍵交換処理における4ウェイハンドシェイクおよびグループキーハンドシェイクの各メッセージの処理は、鍵交換制御部306により行われる。
ここで、WPA(Wi−Fi Protected Access)の4ウェイハンドシェイクおよびグループキーハンドシェイクについて簡単に説明する。4ウェイハンドシェイクおよびグループキーハンドシェイクは、本実施形態では、暗号鍵の交換処理として説明するが、一方の通信装置から他方の通信装置に暗号鍵、もしくは暗号鍵に関する情報を提供して暗号鍵を共有する共有処理と言う事もできる。
4ウェイハンドシェイクおよびグループキーハンドシェイクは、認証側機器(オーセンティケータ)と被認証側機器(サプリカント)との間で実行される。なお、以下の説明では、認証側機器(オーセンティケータ)を認証側、被認証側機器(サプリカント)を被認証側として説明する。
4ウェイハンドシェイクでは、認証側、被認証側とで共有鍵(事前共有鍵)を事前に共有しておき、セッション鍵の生成には、この事前共有鍵を利用する。
まず、認証側が乱数(第1の乱数)を生成し、生成した第1の乱数を含むメッセージ1を被認証側に送信する。
このメッセージ1を受信した被認証側は、自身でも乱数(第2の乱数)を生成する。そして、被認証側は、自身で生成した第2の乱数と、認証側から受信した第1の乱数と、事前共有鍵と、からセッション鍵を生成する。
セッション鍵を生成した被認証側は、第2の乱数と、自身の暗号・認証サポート情報(WPAIEもしくはRSNIE)と、を含むメッセージ2を認証側に送る。
メッセージ2を受信した認証側では、自身で生成した第1の乱数と、被認証側から受信した第2の乱数と、事前共有鍵と、から、セッション鍵を生成する。この段階で、認証側と被認証側とは、第1の乱数、第2の乱数、事前共有鍵が同じであれば、同じセッション鍵を生成したことになる。
セッション鍵を生成した認証側は、自身の暗号・認証サポート情報(WPAIEもしくはRSNIE)とセッション鍵のインストール指示を含むメッセージ3を被認証側に送信する。
メッセージ3の送受信を契機に認証側および被認証側は、セッション鍵をインストールすることができる。
メッセージ3を受信した被認証側は、メッセージ3を受信したことを通知するためのメッセージ4を認証側に送信する。
このように、4ウェイハンドシェイクは、認証側と被認証側との間でメッセージ1からメッセージ4を送受信することで、暗号鍵であるセッション鍵を交換(実際には、セッション鍵を生成するための乱数交換)する。この交換により暗号鍵をネットワークで共有化することができる。
なお、セッション鍵のインストールはメッセージ4の送受信を契機することもできる。
グループキーハンドシェイクでは、認証側は、4ウェイハンドシェイクで交換したセッション鍵を用いてグループ鍵を暗号化する。そして、認証側は、この暗号化したグループ鍵を含むメッセージ1を被認証側に送信する。グループ鍵は、グループ通信を行うための暗号鍵である。そのため、既に他の通信装置と共有しているグループ鍵を被認証側とも共有する場合は、そのグループ鍵を送信する。他の通信装置と共有しているグループ鍵が無い、また、他の通信装置と共有しているグループ鍵を被認証側とは共有しない場合は、認証側がグループ鍵を生成し、生成したグループ鍵を被認証側に送信する。
被認証側は、受信したメッセージ1に含まれるグループ鍵をセッション鍵で復号し、メッセージ1を受信したことを通知するためのメッセージ2を認証側に送信する。
このように、グループキーハンドシェイクは、認証側と被認証側との間でメッセージ1及びメッセージ2を送受信することで、グループ通信時の暗号鍵であるグループ鍵を共有化することができる。
以上のように、認証側は、暗号鍵を提供する提供装置、被認証側は、認証側(提供装置)が提供する暗号鍵を受ける受信装置(受理装置、受取装置)、と言い換えることもできる。
なお、4ウェイハンドシェイクおよびグループキーハンドシェイクは、IEEE802.11iにおいて規格化されているので、詳細については、IEEE802.11i規格を参照されたい。
307は鍵交換制御部306において交換されたセッション鍵、グループ鍵を保存する暗号鍵保存部である。他の通信装置との間で鍵交換が実施済みであるか否かは、暗号鍵保存部307に情報が保存されていることで判定ができる。
308は乱数生成部である。前述の鍵交換制御部306においてセッション鍵を生成する際の乱数情報を生成するのが乱数生成部308である。また、グループ鍵を生成する際にも、乱数生成部308において生成した乱数を利用してもよい。
なお、全ての機能ブロックはソフトウェアもしくはハードウェア的に相互関係を有するものである。また、上記機能ブロックは一例であり、複数の機能ブロックが1つの機能ブロックを構成するようにしてもよいし、何れかの機能ブロックが更に複数の機能を行うブロックに分かれてもよい。
図2は、端末A22、端末B23、端末C24、および端末A22と端末B23が構成するアドホックネットワーク21を示した図である。
各端末は、IEEE802.11無線LAN通信機能を備えており、無線LANアドホック(以下、アドホック)通信により無線通信を行い、先に説明した図1、図3の構成を有する。
図2は、最初に端末A22(以下、端末Aと称す)と端末B23(以下、端末Bと称す)との間で暗号鍵の交換が完了しているものとする。本実施の形態においては、端末Aと端末Bとの間で行われた暗号鍵の交換処理において、端末Aはオーセンティケータであり、端末Bはサプリカントであったものとする。また、各端末間で共有する暗号鍵を統一するために、MAC(Media Access Control)アドレスが最大である端末がオーセンティケータになり、暗号鍵の交換処理を行うものとする。なお、MACアドレスの大小関係は、辞書式順序により比較、判定されるものとする。
暗号鍵の交換により確立したネットワーク21に対し、新たな通信装置である端末C24(以下、端末Cと称す)が参加することを考える。
端末Cがネットワーク21に参加するために、ブロードキャスト(探索する端末を指定しない)でプローブリクエストを送信すると、ネットワーク21を構成する端末Aまたは端末Bのいずれか一方がプローブレスポンスを返送する。ここで、IEEE802.11無線LANのアドホックネットワークにおいては、各端末がランダムにビーコンを送信する。ブロードキャストでプローブリクエストが送信された場合、プローブリクエストを受信する直前にビーコンを送信した端末がプローブレスポンスを返送することが規定されている。
処理シーケンスは、端末Aまたは端末Bのどちらがプローブレスポンスの返送を行ったのかによって変わる。
また、プローブレスポンスの返送を行った端末が、端末Cからのプローブリクエストを受信したときに起動していた暗号鍵の交換処理の役割によっても、端末Cがネットワーク21に参加する際の処理シーケンスは異なる。
図4は、各端末のMACアドレスの大小関係が、端末A>端末B>端末Cであり、端末Cがプローブリクエストを送信した際に、端末Bからプローブレスポンスの返信があった場合の処理シーケンスを示した図である。
まず、端末Aと端末Bから構成されているネットワーク21に端末Cが参加を試みるために、端末Cはブロードキャストでプローブリクエストを送信する(F401)。
プローブリクエストを受信した端末Aおよび端末Bのいずれか一方は、プローブレスポンスを端末Cに返送する。ここでは端末Bが直前にビーコンを送信しており、端末Bからプローブレスポンスが端末Cへ返送される(F402)。
プローブレスポンスを返送された端末Cは、自端末のMACアドレスとプローブレスポンスの送信元のMACアドレス(即ち端末BのMACアドレス)の大小関係を比較する。また、プローブレスポンスを返送した端末Bにおいても、自端末のMACアドレスとプローブレスポンス返送先のMACアドレス(即ちプローブリクエストの送信元である端末CのMACアドレス)を比較し、大小関係を判定する(F403)。
比較した結果、端末Bは、端末C<端末BというMACアドレスの大小関係があることを判定する。また、端末Bは、端末Aとの間で行った暗号鍵の交換処理で自端末が担った役割を確認する。前述したように、MACアドレスは端末A>端末Bであり、端末Bはサプリカントとして動作したため、端末Bは端末Cとの関係においてもオーセンティケータの役割は担わない。仮に端末Bがオーセンティケータとなり、端末Cとの間で暗号鍵の交換処理を実行してしまうと、ネットワークとして暗号鍵が統一されなくなってしまうためである。そこで端末Bは、端末Cの役割を自らは決定せず、端末Aに決定させる。よって端末Bは、端末Cとの間で暗号鍵の交換処理を行わないと判断し、端末Cに向けて鍵交換拒否通知を送信する(F404)。
更に端末Bは、端末Aに向けて、端末Cがネットワークに参加した旨を通知するための新規端末情報通知を送信する(F405)。新規端末情報通知には、新規端末である端末CのMACアドレスを含めて送信する。
新規端末情報通知を受信した端末Aは、新規端末情報通知に含まれる端末CのMACアドレスと、自端末のMACアドレスとを比較し、端末A>端末Cであることを判定する。その結果、端末Aは引き続きオーセンティケータとして動作し、端末Cがサプリカントとして動作することを決定する。そして、端末Aは端末Cへ4ウェイハンドシェイクのメッセージ1を送信する(F406)。
端末Aと端末Cが通信可能であれば、4ウェイハンドシェイクを続行し、引き続きグループキーハンドシェイクを実施する(F407〜F411)。なお、端末Aは端末Bとの間で行った暗号鍵交換処理によって端末Bに提供した暗号鍵(グループ鍵)を端末Cに送信する。これにより、ネットワーク全体として暗号鍵を統一することができる。
4ウェイハンドシェイクおよびグループキーハンドシェイクのメカニズムについては、前述したようにIEEE802.11i規格の通りであるため、ここでの説明は割愛する。
図4においては、端末Cが送信したプローブリクエストに対して端末Bがプローブレスポンスを返信した場合について説明した。次に、端末Aがプローブレスポンスを返送する場合のシーケンスについて図5を用いて説明する。
まず、端末Aと端末Bから構成されているネットワーク21に端末Cが参加を試みるために、端末Cはブロードキャストでプローブリクエストを送信する(F501)。
プローブリクエストを受信した端末Aおよび端末Bのいずれか一方は、プローブレスポンスを端末Cに返送する。ここでは端末Aが直前にビーコンを送信しており、端末Aからプローブレスポンスが端末Cへ返送される(F502)。
プローブレスポンスを返送された端末Cは、自端末のMACアドレスとプローブレスポンスの送信元MACアドレス(即ち端末AのMACアドレス)を比較し、大小関係を判定する。また、プローブレスポンスを返送した端末Aにおいても、自端末のMACアドレスとプローブレスポンス返送先MACアドレス(即ちプローブリクエストの送信元である端末CのMACアドレス)を比較し、大小関係を判定する(F503)。
比較した結果、端末Aは、端末C<端末AというMACアドレスの大小関係があることを判定する。また、端末Aは、端末Bとの間で行った暗号鍵の交換処理で自端末が担った役割を確認する。前述したように、MACアドレスは端末A>端末Bであり、端末Aはオーセンティケータとして動作したため、端末Aは端末Cとの関係においてもオーセンティケータとして動作し、端末Cがサプリカントとして動作することを決定する。端末Aがオーセンティケータとなり、端末Cがサプリカントとなって暗号鍵の交換処理を実行することで、ネットワーク全体として暗号鍵を一致させることができるためである。
よって、端末Aは引き続きオーセンティケータとして動作し、端末Cへ4ウェイハンドシェイクのメッセージ1を送信する(F504)。
端末Aと端末Cが通信可能であれば、以下4ウェイハンドシェイクを続行し、引き続きグループキーハンドシェイクを実施する(F505〜F509)。ここでも、端末Aは端末Bとの間で行った暗号鍵交換処理によって端末Bに提供した暗号鍵(グループ鍵)を端末Cに送信する。これにより、ネットワーク全体として暗号鍵を統一することができる。
図4、5では、各端末のMACアドレスの関係が端末A>端末B>端末Cの場合について説明したが、端末A>端末C>端末Bおよび端末C>端末A>端末Bという場合も考えられる。
ここで、各端末のMACアドレスの大小関係が、端末A>端末C>端末Bである場合を考える。
先ほど述べた端末A>端末B>端末Cの場合と同様に、プローブレスポンスの返送元は端末Aの場合と端末Bの場合との2通りが考えられる。
まず、端末Aからプローブレスポンスの返信があった場合を考える。この場合、端末AはMACアドレスの大小関係が端末A>端末Cであることを判定し、かつ、端末Aが端末Bとの間で行った暗号鍵の交換処理で担った役割はオーセンティケータである。従って、端末Aは引き続きオーセンティケータとして動作し、端末Cがサプリカントとして動作することを決定する。その結果として図5と同じシーケンスとなる。
次に、端末Bからプローブレスポンスの返信があった場合を考える。この場合、端末Bは図4のF403で、MACアドレスの大小関係が端末C>端末Bであることを判定する。また、端末Bが端末Aとの間で行った暗号鍵の交換処理で担った役割はサプリカントである。従って、端末Bは端末Cがどちらの役割を担うかを自らは決定しないこととし、端末Aと端末CとのMACアドレスの大小関係に依存することにする。もしこの時点で端末Cがオーセンティケータになることを端末Bが決定し、端末Cとの間で暗号鍵の交換処理を実行してしまうと、ネットワーク全体として暗号鍵が不一致となってしまうためである。
よって、端末Bは端末Cに対して鍵交換拒否通知を送信すると共に(F404)、端末Aに対して新規端末情報通知を送信する(F405)。そして、新規端末情報通知を受信した端末Aは、自端末のMACアドレスと端末CのMACアドレスを比較し、自端末がオーセンティケータ、端末Cがサプリカントとして端末Cとの間で鍵交換処理を行うことを決定する。その結果として、先に説明した図4と同じシーケンスとなる。
最後に、各端末のMACアドレスの大小関係が、端末C>端末A>端末Bである場合を考える。
この場合も、プローブレスポンスの返送元は端末Aの場合と端末Bの場合との2通りが考えられる。まず端末Bがプローブレスポンスを返送する場合について、図6のシーケンス図を用いて説明する。
まず、端末Aと端末Bから構成されているネットワーク21に端末Cが参加を試みるために、端末Cはブロードキャストでプローブリクエストを送信する(F601)。
プローブリクエストを受信した端末Aおよび端末Bのいずれか一方は、プローブレスポンスを端末Cに返送する。ここでは端末Bが直前にビーコンを送信しており、端末Bからプローブレスポンスが端末Cへ返送される(F602)。
プローブレスポンスを返送された端末Cは、自端末のMACアドレスとプローブレスポンスの送信元MACアドレス(即ち端末BのMACアドレス)を比較し、大小関係を判定する。また、プローブレスポンスを返送した端末Bにおいても、自端末のMACアドレスとプローブレスポンス返送先MACアドレス(即ちプローブリクエストの送信元である端末CのMACアドレス)を比較し、大小関係を判定する(F603)。
比較した結果、端末Bは、端末C>端末BというMACアドレスの大小関係があることを判定する。また、端末Bは、端末Aとの間で行った暗号鍵の交換処理において自端末が担った役割を確認する。前述したように、MACアドレスは端末A>端末Bであり、端末Bはサプリカントとして動作したことを確認する。従って端末Bは、端末Cがどちらの役割を担うかを自らは決定しないこととして、端末Aと端末CとのMACアドレスの大小関係に依存することにする。もしこの時点で、端末Cがオーセンティケータになることを端末Bが決定し、端末Cとの間で暗号鍵の交換処理を実行してしまうと、ネットワーク全体として暗号鍵が不一致となってしまうためである。よって端末Bは、端末Cに向けて鍵交換拒否通知を送信すると共に(F604)、端末Aに向けて、端末Cがネットワークに参加した旨を通知するための新規端末情報通知を送信する(F605)。
新規端末情報通知を受信した端末Aは、新規端末情報通知に含まれる端末CのMACアドレスと、自端末のMACアドレスとを比較し、端末A<端末Cであることを判定する。その結果、端末Aはサプリカントとして動作し、端末Cがオーセンティケータとして動作することを決定する。そして端末Aは、4ウェイハンドシェイクの開始を要求するため、端末CへEAPOL−STARTを送信する(F606)。
ここで、EAPOL−STARTとは、認証の開始を要求するために用いられるメッセージであるが、本実施形態においては、暗号鍵の交換処理の開始を要求するためのメッセージとして用いるものとする。
EAPOL−STARTを受信した端末Cは、端末Aへ4ウェイハンドシェイクのメッセージ1を送信する(F607)。端末Aと端末Cが通信可能であれば、以下4ウェイハンドシェイクを続行し、引き続きグループキーハンドシェイクを実施する(F608〜F612)。
端末Aはいままでのネットワークのオーセンティケータとしての役割を端末Cに引き継ぐために、端末Aが把握しているサプリカントの情報(本実施形態においては端末Bの情報)を端末Cに向けて通知する(F613)。
サプリカントの通知を受けた端末Cは、サプリカントである端末Bとの間で新たに暗号鍵の交換処理を実施する(F614〜F619)。ここでは、端末Cは、端末Aとの間で行った暗号鍵交換処理において端末Aへ提供した暗号鍵(グループ鍵)を端末Bに対しても送信する。これにより、ネットワーク全体として暗号鍵を統一することができる。
なお、F613で端末Cへサプリカント情報を通知する代わりに、端末Aが把握しているサプリカント端末Bに対して、新しいオーセンティケータが端末Cである旨を通知してもよい。この場合は、通知を受けたサプリカント端末Bが端末Cに対してEAPOL−STARTを送信することにより、端末Cとの間で暗号鍵の交換処理を行うことができる。
こうして、新規端末Cがオーセンティケータとなった場合でも、全ての既存端末との間で暗号鍵の交換処理を行うので、ネットワーク全体として暗号鍵を統一することができる。
次に、端末Aがプローブレスポンスを返送する場合のシーケンスについて図7を用いて説明する。
まず、端末Aと端末Bから構成されているネットワーク21に端末Cが参加を試みるために、端末Cはブロードキャストでプローブリクエストを送信する(F701)。
プローブリクエストを受信した端末Aおよび端末Bのいずれか一方は、プローブレスポンスを端末Cに返送する。ここでは端末Aが直前にビーコンを送信しており、端末Aからプローブレスポンスが端末Cへ返送される(F702)。
プローブレスポンスを返送された端末Cは、自端末のMACアドレスとプローブレスポンスの送信元MACアドレス(即ち端末AのMACアドレス)を比較し、大小関係を判定する。また、プローブレスポンスを返送した端末Aにおいても、自端末のMACアドレスとプローブレスポンス返送先MACアドレス(即ちプローブリクエストの送信元である端末CのMACアドレス)を比較し、大小関係を判定する(F703)。
比較した結果、端末Aは、端末A<端末CというMACアドレスの大小関係があることを判定する。
また、端末Aは、端末Bとの間で行った暗号鍵の交換処理において自端末が担った役割を確認する。前述したように、MACアドレスは端末A>端末Bであり、端末Aはオーセンティケータとして動作したため、端末Aは端末Cとの関係においてはサプリカントとなり、端末Cがオーセンティケータとなることを決定する。そして端末Aは、4ウェイハンドシェイクの開始を要求するために、端末Cへ向けてEAPOL−STARTを送信する(F704)。
EAPOL−STARTを受信した端末Cは、端末Aへ4ウェイハンドシェイクのメッセージ1を送信する(F705)。端末Aと端末Cが通信可能であれば、以下4ウェイハンドシェイクを続行し、引き続きグループキーハンドシェイクを実施する(F706〜F710)。
端末Aはいままでのネットワークのオーセンティケータとしての役割を端末Cに引き継ぐために、端末Aが把握しているサプリカントの情報(本実施形態においては端末Bの情報)を端末Cに向けて通知する(F711)。
サプリカントの通知を受けた端末Cは、各サプリカントとの間で新たに暗号鍵の交換処理を実施する(F712〜717)。ここでも端末Cは、端末Aとの間で行った暗号鍵交換処理において端末Aへ提供した暗号鍵(グループ鍵)を端末Bに対しても送信する。これにより、ネットワーク全体として暗号鍵を統一することができる。
なお、F711で端末Cに対してサプリカント情報を通知する代わりに、端末Aが把握しているサプリカント端末Bに対して、新しいオーセンティケータが端末Cである旨を通知してもよい。この場合は、通知を受けたサプリカント端末Bが、端末Cに対してEAPOL−STARTを送信することにより、端末Cとの間で暗号鍵の交換処理を行うことができる。
こうして、新規端末Cがオーセンティケータとなった場合でも、全ての既存端末との間で暗号鍵の交換処理を行うので、ネットワーク全体として暗号鍵を統一することができる。
以上で説明した処理シーケンスを実現するための、各端末の動作フローチャートについて説明する。
図8は、既存ネットワーク21に存在する端末(以下、既存端末)のうち、新規端末Cからのプローブリクエストに対して応答する端末の動作フローを示した図である。
既存端末(本実施の形態においては端末Aもしくは端末B)は、プローブリクエストを新規端末Cから受信する(S801)。プローブリクエストを受信した既存端末のうち、プローブリクエストを受信する直前にビーコンを送信した既存端末がプローブレスポンスを送信する(S802)。
プローブレスポンスを送信した既存端末は、プローブレスポンスの送信先端末である新規端末Cと、自端末のMACアドレスを比較する(S803)。
比較の結果、自端末のMACアドレスが新規端末のMACアドレスよりも大きい場合は、既存端末間で行った暗号鍵の交換処理で自端末が担った役割を確認する(S804)。
自端末がサプリカントとして動作していた場合、すなわち本実施形態では既存端末Bの場合は、新規端末Cの役割を自らは決定しないことを判定する。そして、既存端末Bは、新規端末Cへ鍵交換拒否通知を送信すると共に(S805)、自端末がサプリカントとして動作した際のオーセンティケータであった端末、すなわち本実施形態においては既存端末Aへ向けて、新規端末情報通知を送信する(S806)。
S804において、自端末がオーセンティケータとして動作していた場合、すなわち本実施形態では既存端末Aの場合、自端末はオーセンティケータとなり、新規端末Cがサプリカントとなることを決定する。そして、既存端末Aが新規端末Cへ向けて4ウェイハンドシェイクのメッセージ1を送信することによって、暗号鍵の交換処理を開始する(S807)。ここでは、既存端末AとBとの間で行われた暗号鍵交換処理によって、既存端末Bに提供した暗号鍵(グループ鍵)を新規端末Cへ送信する。これにより、新規端末を含めてネットワークに存在する各端末の暗号鍵を統一することができる。
また、S803におけるMACアドレスの比較の結果、自端末のMACアドレスが新規端末のMACアドレスよりも小さい場合を考える。この場合も、既存端末間で行った暗号鍵の交換処理で自端末が担った役割を確認する(S808)。
自端末がサプリカントとして動作していた場合、すなわち本実施形態では既存端末Bの場合、新規端末Cの役割を自らは決定しないことを判定する。そして既存端末Bは、新規端末Cへ鍵交換拒否通知を送信すると共に(S809)、自端末がサプリカントとして動作した際のオーセンティケータであった端末、すなわち本実施形態においては既存端末Aへ向けて新規端末情報通知を送信する(S810)。
その後、既存端末Aが行うMACアドレスの判定の結果、新規端末Cがオーセンティケータとなった場合、既存端末Bは、新規端末Cから4ウェイハンドシェイクのメッセージ1を受信する(S815)。もしくは、既存端末Bは、新規端末Cが新たにオーセンティケータになった旨の通知を既存端末Aから受信する(S815)。
新規端末Cから4ウェイハンドシェイクのメッセージ1を受信した場合は、既存端末Bは引き続き新規端末Cとの間で4ウェイハンドシェイク及びグループキーハンドシェイクを実施する(S816)。
また、新規端末Cが新たにオーセンティケータになった旨の通知を既存端末Aから受信した場合は、既存端末Bは新規端末Cに対してEAPOL−STARTを送信することによって、新規端末Cとの間で暗号鍵の交換処理を行う(S816)。
なおS816において、既存端末Bは、新規端末Cが既存端末Aとの間で行った暗号鍵交換処理によって、既存端末Aに提供した暗号鍵(グループ鍵)と同一の暗号鍵を新規端末Cから受信する。これにより、ネットワーク全体として暗号鍵が統一される。
S815でいずれのメッセージも受信しない場合は、既存端末Aが引き続きオーセンティケータとしての役割を担うことを決定した場合であり、既存端末Bは暗号鍵の交換処理を行う必要がないため、そのまま処理を終了する。
S808による判定結果において、自端末がオーセンティケータとして動作していた場合、すなわち本実施形態における既存端末Aの場合は、新規端末Cがオーセンティケータになり、自端末がサプリカントになることを決定する(S811)。そして既存端末Aは、新規端末Cへ向けてEAPOL−STARTを送信し(S812)、新規端末Cとの間で暗号鍵の交換処理を実施する(S813)。その後ネットワーク全体として暗号鍵を統一するために、既存端末Aは新規端末Cへ向けて、いままで自端末が把握していたサプリカントの情報、すなわち本実施形態における既存端末Bの情報を転送する(S814)。なお、S814については、既存端末Aは今まで自端末が把握していたサプリカント端末である既存端末Bに対して、新しいオーセンティケータである新規端末Cの情報を通知してもよい。
次に、図8のS806又はS810にて通知される新規端末情報通知を受信した端末(本実施形態においては既存端末A)の動作フローチャートについて、図10を用いて説明する。
既存端末Bとの暗号鍵交換処理でオーセンティケータとして動作した既存端末Aは、サプリカントとして動作していた既存端末Bから新規端末情報通知を受信する(S1001)。上述したように、新規端末情報には、新規端末CのMACアドレスが含まれている。
新規端末情報通知を受信すると、既存端末Aは、自端末のMACアドレスと、新規端末情報に含まれる新規端末CのMACアドレスとを比較する(S1002)。
S1002における比較の結果、自端末のMACアドレスの方が大きければ、既存端末Aが引き続きオーセンティケータとして動作し、新規端末Cがサプリカントとなることを決定する(S1003)。そして、既存端末Aは、新規端末Cへ向けて4ウェイハンドシェイクのメッセージ1を送信することにより、暗号鍵の交換処理を開始する(S1004)。ここでは、既存端末Aは、既存端末Bとの間で行われた暗号鍵交換処理によって既存端末Bに提供した暗号鍵(グループ鍵)と同一の暗号鍵を新規端末Cへ送信する。これによりネットワーク全体として暗号鍵を統一することができる。
一方、S1002におけるMACアドレスの比較の結果、自端末のMACアドレスの方が小さければ、新規端末Cがオーセンティケータとなり、既存端末Aがサプリカントとして動作することを決定する(S1005)。
そして、既存端末Aは新規端末Cへ向けてEAPOL−STARTを送信する(S1006)。既存端末Aと新規端末Cが通信可能であれば、引き続き4ウェイハンドシェイク、及びグループキーハンドシェイクを実施する(S1007)。その後、ネットワーク全体として暗号鍵を統一するために、既存端末Aは新規端末Cへ向けて、いままで自端末が把握していたサプリカントである既存端末Bの情報を転送する(S1008)。なお、S1008については、既存端末Aは今まで自端末が把握していたサプリカント端末である既存端末Bに対して、新しいオーセンティケータである新規端末Cの情報を通知してもよい。
引き続き、新規端末Cの動作フローチャートについて、図9を用いて説明する。
新規端末Cは、ブロードキャストでプローブリクエストを送信し(S901)、既存端末からプローブレスポンスを受信する(S902)。
プローブレスポンスを受信すると、新規端末Cは、プローブレスポンスの送信元端末と自端末のMACアドレスを比較する(S903)。
比較の結果、自端末のMACアドレスがプローブレスポンス送信元端末のMACアドレスよりも大きい場合は、新規端末Cはプローブレスポンス送信元端末から鍵交換拒否通知を受信するかを確認する(S904)。
鍵交換拒否通知を受信した場合は、新規端末Cは、プローブレスポンスの送信元端末以外の既存端末から、4ウェイハンドシェイクのメッセージ1、またはEAPOL−STARTの受信を待つ(S905)。ここでは、いずれかのメッセージを受信した場合において、当該メッセージの送信元端末のBSSID(ネットワーク識別子)が、プローブレスポンス送信元端末のBSSIDと同一である場合にS906に進む。これにより、プローブレスポンス送信元の端末と同一のネットワークに属する既存端末か否かを確認してから暗号鍵の交換処理を実行することができる。
どちらのメッセージも受信しない場合、又はいずれかのメッセージを受信したとしても、メッセージ送信元端末のBSSIDとプローブレスポンス送信元端末のBSSIDとが異なる場合は、S901に戻る。本実施形態においては、いずれかのメッセージの送信元端末は既存端末Aである。
S906において、新規端末Cは引き続き4ウェイハンドシェイクおよびグループキーハンドシェイクを実施し、既存端末Aとの間で暗号鍵の交換処理を完了する。なお、S905において、4ウェイハンドシェイクのメッセージ1を受信した場合は、新規端末Cはサプリカントとしての動作を行い、EAPOL−STARTを受信した場合はオーセンティケータとしての動作を行う。
その後、新規端末Cは、既存端末間で行われた鍵交換処理でサプリカントとして動作した端末(本実施形態では既存端末B)の情報通知を受信すると(S907)、S908に進む。そして、当該通知に含まれる既存端末Bに対して、4ウェイハンドシェークのメッセージ1を送信することにより、鍵交換処理を開始する(S908)。なお、S907において既存端末Bの情報を受信するのは、S906の暗号鍵交換処理において新規端末Cがオーセンティケータとして動作した場合である。この場合、S908において、新規端末CはS906の暗号鍵交換処理において既存端末Aへ提供した暗号鍵と同一の暗号鍵を既存端末Bへも送信する。
また、S907において、既存端末間で行われた鍵交換処理でサプリカントとして動作した端末(本実施形態では端末B)からEAPOL−STARTを受信した場合も、同様に既存端末Bとの間で鍵交換処理を実行する(S908)。
このような処理を行うことにより、新規端末Cがオーセンティケータとなった場合でも、ネットワーク全体として暗号鍵を統一することができる。
S904において、鍵交換拒否通知を受信しなかった場合は、新規端末Cは自端末の役割をオーセンティケータとし(S909)、暗号鍵の交換処理を実行する(S910)。
S903におけるMACアドレスの比較の結果、新規端末Cは、自端末のMACアドレスがプローブレスポンス送信元端末のMACアドレスよりも小さい場合は、自端末の役割をサプリカントとする(S911)。
そして、新規端末Cは既存端末から4ウェイハンドシェイクのメッセージ1の受信を待つ(S912)。ここで、4ウェイハンドシェイクのメッセージ1を受信した場合において、当該メッセージ1の送信元端末のBSSIDが、プローブレスポンス送信元端末のBSSIDと同一である場合にS913に進む。これにより、プローブレスポンス送信元端末と同一のネットワークに属する端末か否かを確認してから暗号鍵の交換処理を行うことができる。4ウェイハンドシェイクのメッセージ1を受信しない場合、又は受信したとしても当該メッセージ1の送信元端末のBSSIDがプローブレスポンス送信元端末のBSSIDと異なる場合は、S901に戻る。
S913において、新規端末Cは、当該メッセージ1の送信元端末との間で引き続き4ウェイハンドシェイクおよびグループキーハンドシェイクを実施し、暗号鍵の交換処理を完了させる(S913)。ここでは、新規端末Cは、既存端末間で行われた暗号鍵交換処理によって既存端末間で共有された暗号鍵と同一の暗号鍵を受信する。これにより、ネットワーク全体として暗号鍵が統一される。
以上のように、プローブレスポンスを送信する既存端末は、自端末が既存端末間で行われた鍵交換処理で担った役割に基づいて、新規端末との間で鍵交換処理を行うか否かを決定する。更に、新規端末と鍵交換処理を行うことを決定した既存端末は、自端末と新規端末間で行う鍵交換処理の役割を決定し、新規端末はその決定に従って動作する。このように、各端末が協調して動作を行うことにより、ネットワーク全体として暗号鍵を統一させることが容易となる。
なお、図9のS903におけるMACアドレスの比較処理は省略してもよい。この場合、新規端末Cは既存端末から4ウェイハンドシェイクのメッセージ1、又はEAPOL−STARTの受信を一定時間待機し、通知されたメッセージに応じて自端末の役割を決定すればよい。この場合、新規端末Cは、既存端末から4ウェイハンドシェイクのメッセージ1を受信した場合はサプリカントとして動作し、EAPOL−STARTを受信した場合はオーセンティケータとして動作すればよい。
また、図4から図7に示したシーケンス図は本発明の一例である。すなわち、図8から図10に示した判定フローに記載した趣旨を満たすものであれば、図4から図7に示したシーケンス図そのものでないものであっても本発明に含まれることはいうまでもない。
以上、本発明の好適な実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施例のみに限定する趣旨ではない。本発明の要旨を逸脱しない範囲で、実施形態は種々に変形することが可能である。
例えば、以上の実施形態の説明においては、WPAで規定されている鍵交換メッセージを用いたが、鍵交換の手法を限定するものではなく、同様の役割を行えるものであれば、いかなる鍵交換方法であっても構わない。
また、鍵交換処理における役割を決定するために、MACアドレスの大小関係を判定していたが、MACアドレス以外の識別情報を用いて判定を行っても良い。
また、上記各実施形態においては、2台の端末が既にネットワークに参加している場合に、新規端末Cがネットワークに参加する場合について説明したが、既存端末が3台以上存在する場合でも本発明は適用可能である。例えば、端末Cがネットワークに参加した後、新たに別の端末Dがネットワークに参加するために暗号鍵の交換処理を行う場合について考える。この場合、端末Cからのプローブリクエストに対してプローブレスポンスを返送する端末は、図8のS804、S808において、端末A、端末B、端末C間で行われた鍵交換処理での役割を判定する。そして判定結果に基づいて以降のフロー処理を行うことにより、ネットワーク全体として暗号鍵を統一することができる。
また、上記説明はIEEE802.11準拠の無線LANを例に説明した。本発明は、ワイヤレスUSB、MBOA、Bluetooth(登録商標)、UWB、ZigBee等の他の無線媒体において実施してもよい。また、有線LAN等の有線通信媒体において実施してもよい。
ここで、MBOAは、Multi Band OFDM Allianceの略である。また、UWBは、ワイヤレスUSB、ワイヤレス1394、WINETなどが含まれる。
本発明は前述の機能を実現するソフトウェアのプログラムコードを記録した記録媒体をシステムあるいは装置に供給し、システムあるいは装置のコンピュータ(CPU、MPU)が記録媒体に格納されたプログラムコードを読み出し実行するようにしてもよい。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、磁気テープ、不揮発性のメモリカード、ROM、DVDなどを用いることができる。
また、コンピュータが読み出したプログラムコードを実行することにより、前述の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOSが実際の処理の一部または全部を行い、前述の機能を実現してもよい。OSとは、オペレーティングシステムの略である。
さらに、記憶媒体から読み出されたプログラムコードを、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込む。そして、そのプログラムコードの指示に基づき、機能拡張ボードや機能拡張ユニットに備わるCPUが実際の処理の一部または全部を行い、前述の機能を実現してもよい。
以上のように、上記説明では、暗号鍵を提供する提供装置、もしくは提供装置が提供する暗号鍵を受理する受理装置として動作し、他の装置との間で暗号鍵を共有するための共有処理を行う第1の通信装置について説明した。前記第1の通信装置は、前記第1の通信装置が参加しているネットワークに存在する複数の装置間で行われた暗号鍵の共有処理において前記第1の通信装置が提供装置として動作したか否かを確認する。そして、前記第1の通信装置は、前記ネットワークに新たに参加する第2の通信装置の識別情報と前記第1の通信装置の識別情報とを比較する。そして、前記第1の通信装置は、確認結果と比較結果とに基づいて、前記第1の通信装置と前記第2の通信装置との暗号鍵の共有処理において前記第1の通信装置が提供装置として動作するか否かを決定する。
また、前記第1の通信装置が提供装置として動作したことを確認した場合、識別情報の比較結果に基づいて、前記第1の通信装置が前記提供装置として動作するか否かを決定する。
また、前記第1の通信装置が受理装置として動作したことを確認した場合、前記ネットワークに存在する複数の装置間で行われた暗号鍵の共有処理で提供装置として動作した第3の通信装置に対して、前記第2の通信装置の情報を通知する。なお、通知される前記第2の通信装置の情報は、前記第3の通信装置が前記第2の通信装置の役割を決定するために通知される。
また、前記第1の通信装置が受理装置として動作したことを確認した場合、前記第2の通信装置に対して暗号鍵の共有処理の拒否を通知する。
また、前記第1の通信装置は、ネットワークを検索するための検索信号を受信することが可能であり、前記検索信号を受信した場合に、提供装置として動作するか否かの決定が行われる。