JP5328141B2 - 通信装置、通信装置の制御方法、コンピュータプログラム - Google Patents

Description

本発明は、通信装置、通信装置の制御方法、コンピュータプログラムに関する。

従来、盗聴や改竄を防止するために通信データを暗号化することが行われている。特に、無線通信においては盗聴が容易なため安全な通信路を確保することが重要となっている。

例えば無線ＬＡＮのインフラストラクチャモードにおいては、通信端末とアクセスポイントはＷＥＰ（Ｗｉｒｅｄ Ｅｑｕｉｖａｌｅｎｔ Ｐｒｉｖａｃｙ）という標準規格を実装している。ＷＥＰでは、通信端末とアクセスポイントに事前に暗号鍵を設定し、毎回の通信においてその暗号鍵を使うことによって安全性を保障しようとする。しかし、この方式では、暗号鍵が常に固定であり、ＷＥＰで採用されている暗号アルゴリズムの強度も高くないため安全性が保証できない場面が様々指摘されている。

この問題を解消するために、ＷＰＡ（Ｗｉ−Ｆｉ Ｐｒｏｔｅｃｔｅｄ Ａｃｃｅｓｓ）という標準規格が策定された。ＷＰＡでは、暗号アルゴリズムの強度を向上させるとともに、通信端末がネットワークに参加するセッション度に毎回暗号鍵を生成することで安全性を高めている。

インフラストラクチャモードではアクセスポイントを介して、他の通信端末にデータを送信するため、アクセスポイントとのみ直接に通信する。よって、アクセスポイントとの通信の安全性のみを保障すればよい。一方、アドホックモードにおいては、アクセスポイントが存在しないため、通信したい相手と直接通信を行う。即ち、各端末が、他の端末と暗号通信するためには、他の端末毎の暗号鍵を保有するか、ネットワーク全体で共通の暗号鍵を利用する必要がある。

各端末が、他の端末毎の暗号鍵を保有する場合は、端末数が増えれば増えるほど、暗号鍵の管理が複雑かつ困難になる。

ネットワーク全体で共通の暗号鍵を利用する場合は、端末毎の鍵管理の負荷は減る。

例えば特許文献１には、アドホックモードにおける暗号鍵の使用方法について言及されている。
特開２００６−３３２８９５号公報

しかしながら、共通の暗号鍵を利用する場合、ネットワークに新規に参加する新規端末にも同じ暗号鍵を配付するのは困難であるという問題がある。

無線ＬＡＮのＷＰＡには、複数の端末で共有する暗号鍵として、グループ鍵がある。このグループ鍵は、４ウェイハンドシェイクおよびグループキーハンドシェイクを実施することで、４ウェイハンドシェイクを開始した端末から他方の端末に送られる。しかしながら、アドホックモードでは、４ウェイハンドシェイクを開始する端末が決められていない。

また、アドホックモードでは、ネットワークに存在する端末を集中的に管理する仕組みが無い。よって、ネットワークに既に参加している端末は、グループ鍵を保有していない端末を把握していない。そのため、ネットワークに既に参加している端末が、グループ鍵を保有していない端末を見つけ出し、４ウェイハンドシェイクを開始することは困難である。

また、ネットワークに新規に参加する端末から４ウェイハンドシェイクを開始すると、新規端末がグループ鍵を配付することになり、今までネットワークで利用されていたグループ鍵を新規端末に配付することはできない。

本発明は、アドホックモードのような環境であっても、ネットワークに新規に参加する通信装置との間で、暗号鍵を共有できるようにすることを目的とする。

本発明の一態様は、暗号鍵を提供する提供装置、もしくは提供装置が提供する暗号鍵を受理する受理装置として動作し、他の装置との間で暗号鍵を共有するための共有処理を行う第１の通信装置であって、前記第１の通信装置が参加しているネットワークに存在する複数の装置間で行われた暗号鍵の共有処理において前記第１の通信装置が提供装置として動作したか否かを確認する確認手段と、前記ネットワークに新たに参加する第２の通信装置の識別情報と前記第１の通信装置の識別情報とを比較する比較手段と、前記確認手段による確認結果と、前記比較手段による比較結果とに基づいて、前記第１の通信装置と前記第２の通信装置との暗号鍵の共有処理において前記第１の通信装置が提供装置として動作するか否かを決定する決定手段と、前記確認手段により前記第１の通信装置が受理装置として動作したことを確認した場合、前記ネットワークに存在する複数の装置間で行われた暗号鍵の共有処理で提供装置として動作した第３の通信装置に対して、前記第２の通信装置の情報を通知する第１の通知手段と、を有することを特徴とする。
また、本発明の他の態様は、暗号鍵を提供する提供装置、もしくは提供装置が提供する暗号鍵を受理する受理装置として動作し、他の装置との間で暗号鍵を共有するための共有処理を行う第１の通信装置であって、前記第１の通信装置が参加しているネットワークに存在する複数の装置間で行われた暗号鍵の共有処理において前記第１の通信装置が提供装置として動作したか否かを確認する確認手段と、前記ネットワークに新たに参加する第２の通信装置の識別情報と前記第１の通信装置の識別情報とを比較する比較手段と、前記確認手段による確認結果と、前記比較手段による比較結果とに基づいて、前記第１の通信装置と前記第２の通信装置との暗号鍵の共有処理において前記第１の通信装置が提供装置として動作するか否かを決定する決定手段と、前記確認手段により前記第１の通信装置が受理装置として動作したことを確認した場合、前記第２の通信装置に対して暗号鍵の共有処理の拒否を通知する通知手段と、を有することを特徴とする。
また、本発明の他の態様は、暗号鍵を提供する提供装置、もしくは提供装置が提供する暗号鍵を受理する受理装置として動作する第１の通信装置であって、暗号鍵を共有するための暗号鍵共有処理を他の装置と実行する実行手段と、前記第１の通信装置と前記第３の通信装置の間で実行された第１の暗号鍵共有処理における前記第１の通信装置の役割を確認する確認手段と、ネットワークに新たに参加する第２の通信装置の識別情報と前記第１の通信装置の識別情報とを比較する比較手段と、前記確認手段による確認結果と、前記比較手段による比較結果とに基づいて、前記第１の通信装置と前記第２の通信装置との間で実行する第２の暗号鍵共有処理における前記第１の通信装置の役割を決定する決定手段と、前記第１の暗号鍵共有処理において前記第１の通信装置が前記提供装置として動作し、かつ、前記第２の暗号鍵共有処理において前記第１の通信装置が提供装置として動作しない場合、新たな提供装置となった前記第２の通信装置を識別するための情報を前記第３の通信装置に通知または前記第１の暗号鍵共有処理において暗号鍵を受理する受理装置として動作した前記第３の通信装置を識別するための情報を前記第２の通信装置に通知する通知手段と、を有することを特徴とする。

本発明により、ネットワークに新規に参加する通信装置と既に暗号鍵の共有処理を実行している通信装置とが適切な役割において暗号鍵の共有処理を実行することができる。

以下、本発明に係る通信装置について、図面を参照しながら詳細に説明する。以下では、ＩＥＥＥ８０２．１１シリーズに準拠した無線ＬＡＮシステムを用いた例について説明するが、本発明は他の通信方式に適用することもできる。

本実施形態に好適な事例におけるハードウェア構成について説明する。

図１は、本実施形態における通信装置の構成例を表すブロック図である。１０１は通信装置全体を示す。１０２は、記憶部１０３に記憶される制御プログラムを実行することにより装置全体を制御する制御部である。制御部１０２は、他の通信装置との間での暗号鍵交換のシーケンス制御も行う。１０３は制御部１０２が実行する制御プログラムと、通信パラメータ等の各種情報を記憶する記憶部である。後述する動作フローチャート、シーケンスチャートの各種動作は、記憶部１０３に記憶された制御プログラムを制御部１０２が実行することにより行われる。１０４は無線通信を行うための無線部である。１０５は各種表示を行う表示部でありＬＣＤやＬＥＤのように視覚で認知可能な情報の出力、あるいはスピーカなどの音出力が可能な機能を有する。１０７はアンテナ制御部、そして１０８はアンテナである。

図３は、本実施形態における通信装置が実行するソフトウェア機能ブロックの構成例を表すブロック図である。

３０１は端末全体を示している。３０２は各種通信にかかわるパケットを受信するパケット受信部である。３０３は各種通信にかかわるパケットを送信するパケット送信部である。３０４はプローブリクエストなどの機器検索信号の送信を制御する検索信号送信部である。後述するプローブリクエストの送信は、検索信号送信部３０４により行われる。また、受信したプローブリクエストに対する応答信号であるプローブレスポンスの送信も検索信号送信部３０４により行われる。

３０５は他の端末からのプローブリクエストなどの機器検索信号の受信を制御する検索信号受信部である。後述するプローブリクエストの受信は、検索信号受信部３０５により行われる。また、プローブレスポンスの受信も検索信号受信部３０５により行われる。なお、プローブレスポンスには、プローブレスポンスを送信する機器の各種情報（自己情報）が付加されている。

３０６は他の通信装置との間でのセッション鍵、グループ鍵の交換処理におけるシーケンス制御などを司る鍵交換制御部である。本実施形態において例示する、ＷＰＡ鍵交換処理における４ウェイハンドシェイクおよびグループキーハンドシェイクの各メッセージの処理は、鍵交換制御部３０６により行われる。

ここで、ＷＰＡ（Ｗｉ−Ｆｉ Ｐｒｏｔｅｃｔｅｄ Ａｃｃｅｓｓ）の４ウェイハンドシェイクおよびグループキーハンドシェイクについて簡単に説明する。４ウェイハンドシェイクおよびグループキーハンドシェイクは、本実施形態では、暗号鍵の交換処理として説明するが、一方の通信装置から他方の通信装置に暗号鍵、もしくは暗号鍵に関する情報を提供して暗号鍵を共有する共有処理と言う事もできる。

４ウェイハンドシェイクおよびグループキーハンドシェイクは、認証側機器（オーセンティケータ）と被認証側機器（サプリカント）との間で実行される。なお、以下の説明では、認証側機器（オーセンティケータ）を認証側、被認証側機器（サプリカント）を被認証側として説明する。

４ウェイハンドシェイクでは、認証側、被認証側とで共有鍵（事前共有鍵）を事前に共有しておき、セッション鍵の生成には、この事前共有鍵を利用する。

まず、認証側が乱数（第１の乱数）を生成し、生成した第１の乱数を含むメッセージ１を被認証側に送信する。

このメッセージ１を受信した被認証側は、自身でも乱数（第２の乱数）を生成する。そして、被認証側は、自身で生成した第２の乱数と、認証側から受信した第１の乱数と、事前共有鍵と、からセッション鍵を生成する。

セッション鍵を生成した被認証側は、第２の乱数と、自身の暗号・認証サポート情報（ＷＰＡＩＥもしくはＲＳＮＩＥ）と、を含むメッセージ２を認証側に送る。

メッセージ２を受信した認証側では、自身で生成した第１の乱数と、被認証側から受信した第２の乱数と、事前共有鍵と、から、セッション鍵を生成する。この段階で、認証側と被認証側とは、第１の乱数、第２の乱数、事前共有鍵が同じであれば、同じセッション鍵を生成したことになる。

セッション鍵を生成した認証側は、自身の暗号・認証サポート情報（ＷＰＡＩＥもしくはＲＳＮＩＥ）とセッション鍵のインストール指示を含むメッセージ３を被認証側に送信する。

メッセージ３の送受信を契機に認証側および被認証側は、セッション鍵をインストールすることができる。

メッセージ３を受信した被認証側は、メッセージ３を受信したことを通知するためのメッセージ４を認証側に送信する。

このように、４ウェイハンドシェイクは、認証側と被認証側との間でメッセージ１からメッセージ４を送受信することで、暗号鍵であるセッション鍵を交換（実際には、セッション鍵を生成するための乱数交換）する。この交換により暗号鍵をネットワークで共有化することができる。

なお、セッション鍵のインストールはメッセージ４の送受信を契機することもできる。

グループキーハンドシェイクでは、認証側は、４ウェイハンドシェイクで交換したセッション鍵を用いてグループ鍵を暗号化する。そして、認証側は、この暗号化したグループ鍵を含むメッセージ１を被認証側に送信する。グループ鍵は、グループ通信を行うための暗号鍵である。そのため、既に他の通信装置と共有しているグループ鍵を被認証側とも共有する場合は、そのグループ鍵を送信する。他の通信装置と共有しているグループ鍵が無い、また、他の通信装置と共有しているグループ鍵を被認証側とは共有しない場合は、認証側がグループ鍵を生成し、生成したグループ鍵を被認証側に送信する。

被認証側は、受信したメッセージ１に含まれるグループ鍵をセッション鍵で復号し、メッセージ１を受信したことを通知するためのメッセージ２を認証側に送信する。

このように、グループキーハンドシェイクは、認証側と被認証側との間でメッセージ１及びメッセージ２を送受信することで、グループ通信時の暗号鍵であるグループ鍵を共有化することができる。

以上のように、認証側は、暗号鍵を提供する提供装置、被認証側は、認証側（提供装置）が提供する暗号鍵を受ける受信装置（受理装置、受取装置）、と言い換えることもできる。

なお、４ウェイハンドシェイクおよびグループキーハンドシェイクは、ＩＥＥＥ８０２．１１ｉにおいて規格化されているので、詳細については、ＩＥＥＥ８０２．１１ｉ規格を参照されたい。

３０７は鍵交換制御部３０６において交換されたセッション鍵、グループ鍵を保存する暗号鍵保存部である。他の通信装置との間で鍵交換が実施済みであるか否かは、暗号鍵保存部３０７に情報が保存されていることで判定ができる。

３０８は乱数生成部である。前述の鍵交換制御部３０６においてセッション鍵を生成する際の乱数情報を生成するのが乱数生成部３０８である。また、グループ鍵を生成する際にも、乱数生成部３０８において生成した乱数を利用してもよい。

なお、全ての機能ブロックはソフトウェアもしくはハードウェア的に相互関係を有するものである。また、上記機能ブロックは一例であり、複数の機能ブロックが１つの機能ブロックを構成するようにしてもよいし、何れかの機能ブロックが更に複数の機能を行うブロックに分かれてもよい。

図２は、端末Ａ２２、端末Ｂ２３、端末Ｃ２４、および端末Ａ２２と端末Ｂ２３が構成するアドホックネットワーク２１を示した図である。

各端末は、ＩＥＥＥ８０２．１１無線ＬＡＮ通信機能を備えており、無線ＬＡＮアドホック（以下、アドホック）通信により無線通信を行い、先に説明した図１、図３の構成を有する。

図２は、最初に端末Ａ２２（以下、端末Ａと称す）と端末Ｂ２３（以下、端末Ｂと称す）との間で暗号鍵の交換が完了しているものとする。本実施の形態においては、端末Ａと端末Ｂとの間で行われた暗号鍵の交換処理において、端末Ａはオーセンティケータであり、端末Ｂはサプリカントであったものとする。また、各端末間で共有する暗号鍵を統一するために、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスが最大である端末がオーセンティケータになり、暗号鍵の交換処理を行うものとする。なお、ＭＡＣアドレスの大小関係は、辞書式順序により比較、判定されるものとする。

暗号鍵の交換により確立したネットワーク２１に対し、新たな通信装置である端末Ｃ２４（以下、端末Ｃと称す）が参加することを考える。

端末Ｃがネットワーク２１に参加するために、ブロードキャスト（探索する端末を指定しない）でプローブリクエストを送信すると、ネットワーク２１を構成する端末Ａまたは端末Ｂのいずれか一方がプローブレスポンスを返送する。ここで、ＩＥＥＥ８０２．１１無線ＬＡＮのアドホックネットワークにおいては、各端末がランダムにビーコンを送信する。ブロードキャストでプローブリクエストが送信された場合、プローブリクエストを受信する直前にビーコンを送信した端末がプローブレスポンスを返送することが規定されている。

処理シーケンスは、端末Ａまたは端末Ｂのどちらがプローブレスポンスの返送を行ったのかによって変わる。

また、プローブレスポンスの返送を行った端末が、端末Ｃからのプローブリクエストを受信したときに起動していた暗号鍵の交換処理の役割によっても、端末Ｃがネットワーク２１に参加する際の処理シーケンスは異なる。

図４は、各端末のＭＡＣアドレスの大小関係が、端末Ａ＞端末Ｂ＞端末Ｃであり、端末Ｃがプローブリクエストを送信した際に、端末Ｂからプローブレスポンスの返信があった場合の処理シーケンスを示した図である。

まず、端末Ａと端末Ｂから構成されているネットワーク２１に端末Ｃが参加を試みるために、端末Ｃはブロードキャストでプローブリクエストを送信する（Ｆ４０１）。

プローブリクエストを受信した端末Ａおよび端末Ｂのいずれか一方は、プローブレスポンスを端末Ｃに返送する。ここでは端末Ｂが直前にビーコンを送信しており、端末Ｂからプローブレスポンスが端末Ｃへ返送される（Ｆ４０２）。

プローブレスポンスを返送された端末Ｃは、自端末のＭＡＣアドレスとプローブレスポンスの送信元のＭＡＣアドレス（即ち端末ＢのＭＡＣアドレス）の大小関係を比較する。また、プローブレスポンスを返送した端末Ｂにおいても、自端末のＭＡＣアドレスとプローブレスポンス返送先のＭＡＣアドレス（即ちプローブリクエストの送信元である端末ＣのＭＡＣアドレス）を比較し、大小関係を判定する（Ｆ４０３）。

比較した結果、端末Ｂは、端末Ｃ＜端末ＢというＭＡＣアドレスの大小関係があることを判定する。また、端末Ｂは、端末Ａとの間で行った暗号鍵の交換処理で自端末が担った役割を確認する。前述したように、ＭＡＣアドレスは端末Ａ＞端末Ｂであり、端末Ｂはサプリカントとして動作したため、端末Ｂは端末Ｃとの関係においてもオーセンティケータの役割は担わない。仮に端末Ｂがオーセンティケータとなり、端末Ｃとの間で暗号鍵の交換処理を実行してしまうと、ネットワークとして暗号鍵が統一されなくなってしまうためである。そこで端末Ｂは、端末Ｃの役割を自らは決定せず、端末Ａに決定させる。よって端末Ｂは、端末Ｃとの間で暗号鍵の交換処理を行わないと判断し、端末Ｃに向けて鍵交換拒否通知を送信する（Ｆ４０４）。

更に端末Ｂは、端末Ａに向けて、端末Ｃがネットワークに参加した旨を通知するための新規端末情報通知を送信する（Ｆ４０５）。新規端末情報通知には、新規端末である端末ＣのＭＡＣアドレスを含めて送信する。

新規端末情報通知を受信した端末Ａは、新規端末情報通知に含まれる端末ＣのＭＡＣアドレスと、自端末のＭＡＣアドレスとを比較し、端末Ａ＞端末Ｃであることを判定する。その結果、端末Ａは引き続きオーセンティケータとして動作し、端末Ｃがサプリカントとして動作することを決定する。そして、端末Ａは端末Ｃへ４ウェイハンドシェイクのメッセージ１を送信する（Ｆ４０６）。

端末Ａと端末Ｃが通信可能であれば、４ウェイハンドシェイクを続行し、引き続きグループキーハンドシェイクを実施する（Ｆ４０７〜Ｆ４１１）。なお、端末Ａは端末Ｂとの間で行った暗号鍵交換処理によって端末Ｂに提供した暗号鍵（グループ鍵）を端末Ｃに送信する。これにより、ネットワーク全体として暗号鍵を統一することができる。

４ウェイハンドシェイクおよびグループキーハンドシェイクのメカニズムについては、前述したようにＩＥＥＥ８０２．１１ｉ規格の通りであるため、ここでの説明は割愛する。

図４においては、端末Ｃが送信したプローブリクエストに対して端末Ｂがプローブレスポンスを返信した場合について説明した。次に、端末Ａがプローブレスポンスを返送する場合のシーケンスについて図５を用いて説明する。

まず、端末Ａと端末Ｂから構成されているネットワーク２１に端末Ｃが参加を試みるために、端末Ｃはブロードキャストでプローブリクエストを送信する（Ｆ５０１）。

プローブリクエストを受信した端末Ａおよび端末Ｂのいずれか一方は、プローブレスポンスを端末Ｃに返送する。ここでは端末Ａが直前にビーコンを送信しており、端末Ａからプローブレスポンスが端末Ｃへ返送される（Ｆ５０２）。

プローブレスポンスを返送された端末Ｃは、自端末のＭＡＣアドレスとプローブレスポンスの送信元ＭＡＣアドレス（即ち端末ＡのＭＡＣアドレス）を比較し、大小関係を判定する。また、プローブレスポンスを返送した端末Ａにおいても、自端末のＭＡＣアドレスとプローブレスポンス返送先ＭＡＣアドレス（即ちプローブリクエストの送信元である端末ＣのＭＡＣアドレス）を比較し、大小関係を判定する（Ｆ５０３）。

比較した結果、端末Ａは、端末Ｃ＜端末ＡというＭＡＣアドレスの大小関係があることを判定する。また、端末Ａは、端末Ｂとの間で行った暗号鍵の交換処理で自端末が担った役割を確認する。前述したように、ＭＡＣアドレスは端末Ａ＞端末Ｂであり、端末Ａはオーセンティケータとして動作したため、端末Ａは端末Ｃとの関係においてもオーセンティケータとして動作し、端末Ｃがサプリカントとして動作することを決定する。端末Ａがオーセンティケータとなり、端末Ｃがサプリカントとなって暗号鍵の交換処理を実行することで、ネットワーク全体として暗号鍵を一致させることができるためである。

よって、端末Ａは引き続きオーセンティケータとして動作し、端末Ｃへ４ウェイハンドシェイクのメッセージ１を送信する（Ｆ５０４）。

端末Ａと端末Ｃが通信可能であれば、以下４ウェイハンドシェイクを続行し、引き続きグループキーハンドシェイクを実施する（Ｆ５０５〜Ｆ５０９）。ここでも、端末Ａは端末Ｂとの間で行った暗号鍵交換処理によって端末Ｂに提供した暗号鍵（グループ鍵）を端末Ｃに送信する。これにより、ネットワーク全体として暗号鍵を統一することができる。

図４、５では、各端末のＭＡＣアドレスの関係が端末Ａ＞端末Ｂ＞端末Ｃの場合について説明したが、端末Ａ＞端末Ｃ＞端末Ｂおよび端末Ｃ＞端末Ａ＞端末Ｂという場合も考えられる。

ここで、各端末のＭＡＣアドレスの大小関係が、端末Ａ＞端末Ｃ＞端末Ｂである場合を考える。

先ほど述べた端末Ａ＞端末Ｂ＞端末Ｃの場合と同様に、プローブレスポンスの返送元は端末Ａの場合と端末Ｂの場合との２通りが考えられる。

まず、端末Ａからプローブレスポンスの返信があった場合を考える。この場合、端末ＡはＭＡＣアドレスの大小関係が端末Ａ＞端末Ｃであることを判定し、かつ、端末Ａが端末Ｂとの間で行った暗号鍵の交換処理で担った役割はオーセンティケータである。従って、端末Ａは引き続きオーセンティケータとして動作し、端末Ｃがサプリカントとして動作することを決定する。その結果として図５と同じシーケンスとなる。

次に、端末Ｂからプローブレスポンスの返信があった場合を考える。この場合、端末Ｂは図４のＦ４０３で、ＭＡＣアドレスの大小関係が端末Ｃ＞端末Ｂであることを判定する。また、端末Ｂが端末Ａとの間で行った暗号鍵の交換処理で担った役割はサプリカントである。従って、端末Ｂは端末Ｃがどちらの役割を担うかを自らは決定しないこととし、端末Ａと端末ＣとのＭＡＣアドレスの大小関係に依存することにする。もしこの時点で端末Ｃがオーセンティケータになることを端末Ｂが決定し、端末Ｃとの間で暗号鍵の交換処理を実行してしまうと、ネットワーク全体として暗号鍵が不一致となってしまうためである。

よって、端末Ｂは端末Ｃに対して鍵交換拒否通知を送信すると共に（Ｆ４０４）、端末Ａに対して新規端末情報通知を送信する（Ｆ４０５）。そして、新規端末情報通知を受信した端末Ａは、自端末のＭＡＣアドレスと端末ＣのＭＡＣアドレスを比較し、自端末がオーセンティケータ、端末Ｃがサプリカントとして端末Ｃとの間で鍵交換処理を行うことを決定する。その結果として、先に説明した図４と同じシーケンスとなる。

最後に、各端末のＭＡＣアドレスの大小関係が、端末Ｃ＞端末Ａ＞端末Ｂである場合を考える。

この場合も、プローブレスポンスの返送元は端末Ａの場合と端末Ｂの場合との２通りが考えられる。まず端末Ｂがプローブレスポンスを返送する場合について、図６のシーケンス図を用いて説明する。

まず、端末Ａと端末Ｂから構成されているネットワーク２１に端末Ｃが参加を試みるために、端末Ｃはブロードキャストでプローブリクエストを送信する（Ｆ６０１）。

プローブリクエストを受信した端末Ａおよび端末Ｂのいずれか一方は、プローブレスポンスを端末Ｃに返送する。ここでは端末Ｂが直前にビーコンを送信しており、端末Ｂからプローブレスポンスが端末Ｃへ返送される（Ｆ６０２）。

プローブレスポンスを返送された端末Ｃは、自端末のＭＡＣアドレスとプローブレスポンスの送信元ＭＡＣアドレス（即ち端末ＢのＭＡＣアドレス）を比較し、大小関係を判定する。また、プローブレスポンスを返送した端末Ｂにおいても、自端末のＭＡＣアドレスとプローブレスポンス返送先ＭＡＣアドレス（即ちプローブリクエストの送信元である端末ＣのＭＡＣアドレス）を比較し、大小関係を判定する（Ｆ６０３）。

比較した結果、端末Ｂは、端末Ｃ＞端末ＢというＭＡＣアドレスの大小関係があることを判定する。また、端末Ｂは、端末Ａとの間で行った暗号鍵の交換処理において自端末が担った役割を確認する。前述したように、ＭＡＣアドレスは端末Ａ＞端末Ｂであり、端末Ｂはサプリカントとして動作したことを確認する。従って端末Ｂは、端末Ｃがどちらの役割を担うかを自らは決定しないこととして、端末Ａと端末ＣとのＭＡＣアドレスの大小関係に依存することにする。もしこの時点で、端末Ｃがオーセンティケータになることを端末Ｂが決定し、端末Ｃとの間で暗号鍵の交換処理を実行してしまうと、ネットワーク全体として暗号鍵が不一致となってしまうためである。よって端末Ｂは、端末Ｃに向けて鍵交換拒否通知を送信すると共に（Ｆ６０４）、端末Ａに向けて、端末Ｃがネットワークに参加した旨を通知するための新規端末情報通知を送信する（Ｆ６０５）。

新規端末情報通知を受信した端末Ａは、新規端末情報通知に含まれる端末ＣのＭＡＣアドレスと、自端末のＭＡＣアドレスとを比較し、端末Ａ＜端末Ｃであることを判定する。その結果、端末Ａはサプリカントとして動作し、端末Ｃがオーセンティケータとして動作することを決定する。そして端末Ａは、４ウェイハンドシェイクの開始を要求するため、端末ＣへＥＡＰＯＬ−ＳＴＡＲＴを送信する（Ｆ６０６）。

ここで、ＥＡＰＯＬ−ＳＴＡＲＴとは、認証の開始を要求するために用いられるメッセージであるが、本実施形態においては、暗号鍵の交換処理の開始を要求するためのメッセージとして用いるものとする。

ＥＡＰＯＬ−ＳＴＡＲＴを受信した端末Ｃは、端末Ａへ４ウェイハンドシェイクのメッセージ１を送信する（Ｆ６０７）。端末Ａと端末Ｃが通信可能であれば、以下４ウェイハンドシェイクを続行し、引き続きグループキーハンドシェイクを実施する（Ｆ６０８〜Ｆ６１２）。

端末Ａはいままでのネットワークのオーセンティケータとしての役割を端末Ｃに引き継ぐために、端末Ａが把握しているサプリカントの情報（本実施形態においては端末Ｂの情報）を端末Ｃに向けて通知する（Ｆ６１３）。

サプリカントの通知を受けた端末Ｃは、サプリカントである端末Ｂとの間で新たに暗号鍵の交換処理を実施する（Ｆ６１４〜Ｆ６１９）。ここでは、端末Ｃは、端末Ａとの間で行った暗号鍵交換処理において端末Ａへ提供した暗号鍵（グループ鍵）を端末Ｂに対しても送信する。これにより、ネットワーク全体として暗号鍵を統一することができる。

なお、Ｆ６１３で端末Ｃへサプリカント情報を通知する代わりに、端末Ａが把握しているサプリカント端末Ｂに対して、新しいオーセンティケータが端末Ｃである旨を通知してもよい。この場合は、通知を受けたサプリカント端末Ｂが端末Ｃに対してＥＡＰＯＬ−ＳＴＡＲＴを送信することにより、端末Ｃとの間で暗号鍵の交換処理を行うことができる。

こうして、新規端末Ｃがオーセンティケータとなった場合でも、全ての既存端末との間で暗号鍵の交換処理を行うので、ネットワーク全体として暗号鍵を統一することができる。

次に、端末Ａがプローブレスポンスを返送する場合のシーケンスについて図７を用いて説明する。

まず、端末Ａと端末Ｂから構成されているネットワーク２１に端末Ｃが参加を試みるために、端末Ｃはブロードキャストでプローブリクエストを送信する（Ｆ７０１）。

プローブリクエストを受信した端末Ａおよび端末Ｂのいずれか一方は、プローブレスポンスを端末Ｃに返送する。ここでは端末Ａが直前にビーコンを送信しており、端末Ａからプローブレスポンスが端末Ｃへ返送される（Ｆ７０２）。

プローブレスポンスを返送された端末Ｃは、自端末のＭＡＣアドレスとプローブレスポンスの送信元ＭＡＣアドレス（即ち端末ＡのＭＡＣアドレス）を比較し、大小関係を判定する。また、プローブレスポンスを返送した端末Ａにおいても、自端末のＭＡＣアドレスとプローブレスポンス返送先ＭＡＣアドレス（即ちプローブリクエストの送信元である端末ＣのＭＡＣアドレス）を比較し、大小関係を判定する（Ｆ７０３）。

比較した結果、端末Ａは、端末Ａ＜端末ＣというＭＡＣアドレスの大小関係があることを判定する。

また、端末Ａは、端末Ｂとの間で行った暗号鍵の交換処理において自端末が担った役割を確認する。前述したように、ＭＡＣアドレスは端末Ａ＞端末Ｂであり、端末Ａはオーセンティケータとして動作したため、端末Ａは端末Ｃとの関係においてはサプリカントとなり、端末Ｃがオーセンティケータとなることを決定する。そして端末Ａは、４ウェイハンドシェイクの開始を要求するために、端末Ｃへ向けてＥＡＰＯＬ−ＳＴＡＲＴを送信する（Ｆ７０４）。

ＥＡＰＯＬ−ＳＴＡＲＴを受信した端末Ｃは、端末Ａへ４ウェイハンドシェイクのメッセージ１を送信する（Ｆ７０５）。端末Ａと端末Ｃが通信可能であれば、以下４ウェイハンドシェイクを続行し、引き続きグループキーハンドシェイクを実施する（Ｆ７０６〜Ｆ７１０）。

端末Ａはいままでのネットワークのオーセンティケータとしての役割を端末Ｃに引き継ぐために、端末Ａが把握しているサプリカントの情報（本実施形態においては端末Ｂの情報）を端末Ｃに向けて通知する（Ｆ７１１）。

サプリカントの通知を受けた端末Ｃは、各サプリカントとの間で新たに暗号鍵の交換処理を実施する（Ｆ７１２〜７１７）。ここでも端末Ｃは、端末Ａとの間で行った暗号鍵交換処理において端末Ａへ提供した暗号鍵（グループ鍵）を端末Ｂに対しても送信する。これにより、ネットワーク全体として暗号鍵を統一することができる。

なお、Ｆ７１１で端末Ｃに対してサプリカント情報を通知する代わりに、端末Ａが把握しているサプリカント端末Ｂに対して、新しいオーセンティケータが端末Ｃである旨を通知してもよい。この場合は、通知を受けたサプリカント端末Ｂが、端末Ｃに対してＥＡＰＯＬ−ＳＴＡＲＴを送信することにより、端末Ｃとの間で暗号鍵の交換処理を行うことができる。

こうして、新規端末Ｃがオーセンティケータとなった場合でも、全ての既存端末との間で暗号鍵の交換処理を行うので、ネットワーク全体として暗号鍵を統一することができる。

以上で説明した処理シーケンスを実現するための、各端末の動作フローチャートについて説明する。

図８は、既存ネットワーク２１に存在する端末（以下、既存端末）のうち、新規端末Ｃからのプローブリクエストに対して応答する端末の動作フローを示した図である。

既存端末（本実施の形態においては端末Ａもしくは端末Ｂ）は、プローブリクエストを新規端末Ｃから受信する（Ｓ８０１）。プローブリクエストを受信した既存端末のうち、プローブリクエストを受信する直前にビーコンを送信した既存端末がプローブレスポンスを送信する（Ｓ８０２）。

プローブレスポンスを送信した既存端末は、プローブレスポンスの送信先端末である新規端末Ｃと、自端末のＭＡＣアドレスを比較する（Ｓ８０３）。

比較の結果、自端末のＭＡＣアドレスが新規端末のＭＡＣアドレスよりも大きい場合は、既存端末間で行った暗号鍵の交換処理で自端末が担った役割を確認する（Ｓ８０４）。

自端末がサプリカントとして動作していた場合、すなわち本実施形態では既存端末Ｂの場合は、新規端末Ｃの役割を自らは決定しないことを判定する。そして、既存端末Ｂは、新規端末Ｃへ鍵交換拒否通知を送信すると共に（Ｓ８０５）、自端末がサプリカントとして動作した際のオーセンティケータであった端末、すなわち本実施形態においては既存端末Ａへ向けて、新規端末情報通知を送信する（Ｓ８０６）。

Ｓ８０４において、自端末がオーセンティケータとして動作していた場合、すなわち本実施形態では既存端末Ａの場合、自端末はオーセンティケータとなり、新規端末Ｃがサプリカントとなることを決定する。そして、既存端末Ａが新規端末Ｃへ向けて４ウェイハンドシェイクのメッセージ１を送信することによって、暗号鍵の交換処理を開始する（Ｓ８０７）。ここでは、既存端末ＡとＢとの間で行われた暗号鍵交換処理によって、既存端末Ｂに提供した暗号鍵（グループ鍵）を新規端末Ｃへ送信する。これにより、新規端末を含めてネットワークに存在する各端末の暗号鍵を統一することができる。

また、Ｓ８０３におけるＭＡＣアドレスの比較の結果、自端末のＭＡＣアドレスが新規端末のＭＡＣアドレスよりも小さい場合を考える。この場合も、既存端末間で行った暗号鍵の交換処理で自端末が担った役割を確認する（Ｓ８０８）。

自端末がサプリカントとして動作していた場合、すなわち本実施形態では既存端末Ｂの場合、新規端末Ｃの役割を自らは決定しないことを判定する。そして既存端末Ｂは、新規端末Ｃへ鍵交換拒否通知を送信すると共に（Ｓ８０９）、自端末がサプリカントとして動作した際のオーセンティケータであった端末、すなわち本実施形態においては既存端末Ａへ向けて新規端末情報通知を送信する（Ｓ８１０）。

その後、既存端末Ａが行うＭＡＣアドレスの判定の結果、新規端末Ｃがオーセンティケータとなった場合、既存端末Ｂは、新規端末Ｃから４ウェイハンドシェイクのメッセージ１を受信する（Ｓ８１５）。もしくは、既存端末Ｂは、新規端末Ｃが新たにオーセンティケータになった旨の通知を既存端末Ａから受信する（Ｓ８１５）。

新規端末Ｃから４ウェイハンドシェイクのメッセージ１を受信した場合は、既存端末Ｂは引き続き新規端末Ｃとの間で４ウェイハンドシェイク及びグループキーハンドシェイクを実施する（Ｓ８１６）。

また、新規端末Ｃが新たにオーセンティケータになった旨の通知を既存端末Ａから受信した場合は、既存端末Ｂは新規端末Ｃに対してＥＡＰＯＬ−ＳＴＡＲＴを送信することによって、新規端末Ｃとの間で暗号鍵の交換処理を行う（Ｓ８１６）。

なおＳ８１６において、既存端末Ｂは、新規端末Ｃが既存端末Ａとの間で行った暗号鍵交換処理によって、既存端末Ａに提供した暗号鍵（グループ鍵）と同一の暗号鍵を新規端末Ｃから受信する。これにより、ネットワーク全体として暗号鍵が統一される。

Ｓ８１５でいずれのメッセージも受信しない場合は、既存端末Ａが引き続きオーセンティケータとしての役割を担うことを決定した場合であり、既存端末Ｂは暗号鍵の交換処理を行う必要がないため、そのまま処理を終了する。

Ｓ８０８による判定結果において、自端末がオーセンティケータとして動作していた場合、すなわち本実施形態における既存端末Ａの場合は、新規端末Ｃがオーセンティケータになり、自端末がサプリカントになることを決定する（Ｓ８１１）。そして既存端末Ａは、新規端末Ｃへ向けてＥＡＰＯＬ−ＳＴＡＲＴを送信し（Ｓ８１２）、新規端末Ｃとの間で暗号鍵の交換処理を実施する（Ｓ８１３）。その後ネットワーク全体として暗号鍵を統一するために、既存端末Ａは新規端末Ｃへ向けて、いままで自端末が把握していたサプリカントの情報、すなわち本実施形態における既存端末Ｂの情報を転送する（Ｓ８１４）。なお、Ｓ８１４については、既存端末Ａは今まで自端末が把握していたサプリカント端末である既存端末Ｂに対して、新しいオーセンティケータである新規端末Ｃの情報を通知してもよい。

次に、図８のＳ８０６又はＳ８１０にて通知される新規端末情報通知を受信した端末（本実施形態においては既存端末Ａ）の動作フローチャートについて、図１０を用いて説明する。

既存端末Ｂとの暗号鍵交換処理でオーセンティケータとして動作した既存端末Ａは、サプリカントとして動作していた既存端末Ｂから新規端末情報通知を受信する（Ｓ１００１）。上述したように、新規端末情報には、新規端末ＣのＭＡＣアドレスが含まれている。

新規端末情報通知を受信すると、既存端末Ａは、自端末のＭＡＣアドレスと、新規端末情報に含まれる新規端末ＣのＭＡＣアドレスとを比較する（Ｓ１００２）。

Ｓ１００２における比較の結果、自端末のＭＡＣアドレスの方が大きければ、既存端末Ａが引き続きオーセンティケータとして動作し、新規端末Ｃがサプリカントとなることを決定する（Ｓ１００３）。そして、既存端末Ａは、新規端末Ｃへ向けて４ウェイハンドシェイクのメッセージ１を送信することにより、暗号鍵の交換処理を開始する（Ｓ１００４）。ここでは、既存端末Ａは、既存端末Ｂとの間で行われた暗号鍵交換処理によって既存端末Ｂに提供した暗号鍵（グループ鍵）と同一の暗号鍵を新規端末Ｃへ送信する。これによりネットワーク全体として暗号鍵を統一することができる。

一方、Ｓ１００２におけるＭＡＣアドレスの比較の結果、自端末のＭＡＣアドレスの方が小さければ、新規端末Ｃがオーセンティケータとなり、既存端末Ａがサプリカントとして動作することを決定する（Ｓ１００５）。

そして、既存端末Ａは新規端末Ｃへ向けてＥＡＰＯＬ−ＳＴＡＲＴを送信する（Ｓ１００６）。既存端末Ａと新規端末Ｃが通信可能であれば、引き続き４ウェイハンドシェイク、及びグループキーハンドシェイクを実施する（Ｓ１００７）。その後、ネットワーク全体として暗号鍵を統一するために、既存端末Ａは新規端末Ｃへ向けて、いままで自端末が把握していたサプリカントである既存端末Ｂの情報を転送する（Ｓ１００８）。なお、Ｓ１００８については、既存端末Ａは今まで自端末が把握していたサプリカント端末である既存端末Ｂに対して、新しいオーセンティケータである新規端末Ｃの情報を通知してもよい。

引き続き、新規端末Ｃの動作フローチャートについて、図９を用いて説明する。

新規端末Ｃは、ブロードキャストでプローブリクエストを送信し（Ｓ９０１）、既存端末からプローブレスポンスを受信する（Ｓ９０２）。

プローブレスポンスを受信すると、新規端末Ｃは、プローブレスポンスの送信元端末と自端末のＭＡＣアドレスを比較する（Ｓ９０３）。

比較の結果、自端末のＭＡＣアドレスがプローブレスポンス送信元端末のＭＡＣアドレスよりも大きい場合は、新規端末Ｃはプローブレスポンス送信元端末から鍵交換拒否通知を受信するかを確認する（Ｓ９０４）。

鍵交換拒否通知を受信した場合は、新規端末Ｃは、プローブレスポンスの送信元端末以外の既存端末から、４ウェイハンドシェイクのメッセージ１、またはＥＡＰＯＬ−ＳＴＡＲＴの受信を待つ（Ｓ９０５）。ここでは、いずれかのメッセージを受信した場合において、当該メッセージの送信元端末のＢＳＳＩＤ（ネットワーク識別子）が、プローブレスポンス送信元端末のＢＳＳＩＤと同一である場合にＳ９０６に進む。これにより、プローブレスポンス送信元の端末と同一のネットワークに属する既存端末か否かを確認してから暗号鍵の交換処理を実行することができる。

どちらのメッセージも受信しない場合、又はいずれかのメッセージを受信したとしても、メッセージ送信元端末のＢＳＳＩＤとプローブレスポンス送信元端末のＢＳＳＩＤとが異なる場合は、Ｓ９０１に戻る。本実施形態においては、いずれかのメッセージの送信元端末は既存端末Ａである。

Ｓ９０６において、新規端末Ｃは引き続き４ウェイハンドシェイクおよびグループキーハンドシェイクを実施し、既存端末Ａとの間で暗号鍵の交換処理を完了する。なお、Ｓ９０５において、４ウェイハンドシェイクのメッセージ１を受信した場合は、新規端末Ｃはサプリカントとしての動作を行い、ＥＡＰＯＬ−ＳＴＡＲＴを受信した場合はオーセンティケータとしての動作を行う。

その後、新規端末Ｃは、既存端末間で行われた鍵交換処理でサプリカントとして動作した端末（本実施形態では既存端末Ｂ）の情報通知を受信すると（Ｓ９０７）、Ｓ９０８に進む。そして、当該通知に含まれる既存端末Ｂに対して、４ウェイハンドシェークのメッセージ１を送信することにより、鍵交換処理を開始する（Ｓ９０８）。なお、Ｓ９０７において既存端末Ｂの情報を受信するのは、Ｓ９０６の暗号鍵交換処理において新規端末Ｃがオーセンティケータとして動作した場合である。この場合、Ｓ９０８において、新規端末ＣはＳ９０６の暗号鍵交換処理において既存端末Ａへ提供した暗号鍵と同一の暗号鍵を既存端末Ｂへも送信する。

また、Ｓ９０７において、既存端末間で行われた鍵交換処理でサプリカントとして動作した端末（本実施形態では端末Ｂ）からＥＡＰＯＬ−ＳＴＡＲＴを受信した場合も、同様に既存端末Ｂとの間で鍵交換処理を実行する（Ｓ９０８）。

このような処理を行うことにより、新規端末Ｃがオーセンティケータとなった場合でも、ネットワーク全体として暗号鍵を統一することができる。

Ｓ９０４において、鍵交換拒否通知を受信しなかった場合は、新規端末Ｃは自端末の役割をオーセンティケータとし（Ｓ９０９）、暗号鍵の交換処理を実行する（Ｓ９１０）。

Ｓ９０３におけるＭＡＣアドレスの比較の結果、新規端末Ｃは、自端末のＭＡＣアドレスがプローブレスポンス送信元端末のＭＡＣアドレスよりも小さい場合は、自端末の役割をサプリカントとする（Ｓ９１１）。

そして、新規端末Ｃは既存端末から４ウェイハンドシェイクのメッセージ１の受信を待つ（Ｓ９１２）。ここで、４ウェイハンドシェイクのメッセージ１を受信した場合において、当該メッセージ１の送信元端末のＢＳＳＩＤが、プローブレスポンス送信元端末のＢＳＳＩＤと同一である場合にＳ９１３に進む。これにより、プローブレスポンス送信元端末と同一のネットワークに属する端末か否かを確認してから暗号鍵の交換処理を行うことができる。４ウェイハンドシェイクのメッセージ１を受信しない場合、又は受信したとしても当該メッセージ１の送信元端末のＢＳＳＩＤがプローブレスポンス送信元端末のＢＳＳＩＤと異なる場合は、Ｓ９０１に戻る。

Ｓ９１３において、新規端末Ｃは、当該メッセージ１の送信元端末との間で引き続き４ウェイハンドシェイクおよびグループキーハンドシェイクを実施し、暗号鍵の交換処理を完了させる（Ｓ９１３）。ここでは、新規端末Ｃは、既存端末間で行われた暗号鍵交換処理によって既存端末間で共有された暗号鍵と同一の暗号鍵を受信する。これにより、ネットワーク全体として暗号鍵が統一される。

以上のように、プローブレスポンスを送信する既存端末は、自端末が既存端末間で行われた鍵交換処理で担った役割に基づいて、新規端末との間で鍵交換処理を行うか否かを決定する。更に、新規端末と鍵交換処理を行うことを決定した既存端末は、自端末と新規端末間で行う鍵交換処理の役割を決定し、新規端末はその決定に従って動作する。このように、各端末が協調して動作を行うことにより、ネットワーク全体として暗号鍵を統一させることが容易となる。

なお、図９のＳ９０３におけるＭＡＣアドレスの比較処理は省略してもよい。この場合、新規端末Ｃは既存端末から４ウェイハンドシェイクのメッセージ１、又はＥＡＰＯＬ−ＳＴＡＲＴの受信を一定時間待機し、通知されたメッセージに応じて自端末の役割を決定すればよい。この場合、新規端末Ｃは、既存端末から４ウェイハンドシェイクのメッセージ１を受信した場合はサプリカントとして動作し、ＥＡＰＯＬ−ＳＴＡＲＴを受信した場合はオーセンティケータとして動作すればよい。

また、図４から図７に示したシーケンス図は本発明の一例である。すなわち、図８から図１０に示した判定フローに記載した趣旨を満たすものであれば、図４から図７に示したシーケンス図そのものでないものであっても本発明に含まれることはいうまでもない。

以上、本発明の好適な実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施例のみに限定する趣旨ではない。本発明の要旨を逸脱しない範囲で、実施形態は種々に変形することが可能である。

例えば、以上の実施形態の説明においては、ＷＰＡで規定されている鍵交換メッセージを用いたが、鍵交換の手法を限定するものではなく、同様の役割を行えるものであれば、いかなる鍵交換方法であっても構わない。

また、鍵交換処理における役割を決定するために、ＭＡＣアドレスの大小関係を判定していたが、ＭＡＣアドレス以外の識別情報を用いて判定を行っても良い。

また、上記各実施形態においては、２台の端末が既にネットワークに参加している場合に、新規端末Ｃがネットワークに参加する場合について説明したが、既存端末が３台以上存在する場合でも本発明は適用可能である。例えば、端末Ｃがネットワークに参加した後、新たに別の端末Ｄがネットワークに参加するために暗号鍵の交換処理を行う場合について考える。この場合、端末Ｃからのプローブリクエストに対してプローブレスポンスを返送する端末は、図８のＳ８０４、Ｓ８０８において、端末Ａ、端末Ｂ、端末Ｃ間で行われた鍵交換処理での役割を判定する。そして判定結果に基づいて以降のフロー処理を行うことにより、ネットワーク全体として暗号鍵を統一することができる。

また、上記説明はＩＥＥＥ８０２．１１準拠の無線ＬＡＮを例に説明した。本発明は、ワイヤレスＵＳＢ、ＭＢＯＡ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＵＷＢ、ＺｉｇＢｅｅ等の他の無線媒体において実施してもよい。また、有線ＬＡＮ等の有線通信媒体において実施してもよい。

ここで、ＭＢＯＡは、Ｍｕｌｔｉ Ｂａｎｄ ＯＦＤＭ Ａｌｌｉａｎｃｅの略である。また、ＵＷＢは、ワイヤレスＵＳＢ、ワイヤレス１３９４、ＷＩＮＥＴなどが含まれる。

本発明は前述の機能を実現するソフトウェアのプログラムコードを記録した記録媒体をシステムあるいは装置に供給し、システムあるいは装置のコンピュータ（ＣＰＵ、ＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行するようにしてもよい。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳが実際の処理の一部または全部を行い、前述の機能を実現してもよい。ＯＳとは、オペレーティングシステムの略である。

さらに、記憶媒体から読み出されたプログラムコードを、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込む。そして、そのプログラムコードの指示に基づき、機能拡張ボードや機能拡張ユニットに備わるＣＰＵが実際の処理の一部または全部を行い、前述の機能を実現してもよい。

以上のように、上記説明では、暗号鍵を提供する提供装置、もしくは提供装置が提供する暗号鍵を受理する受理装置として動作し、他の装置との間で暗号鍵を共有するための共有処理を行う第１の通信装置について説明した。前記第１の通信装置は、前記第１の通信装置が参加しているネットワークに存在する複数の装置間で行われた暗号鍵の共有処理において前記第１の通信装置が提供装置として動作したか否かを確認する。そして、前記第１の通信装置は、前記ネットワークに新たに参加する第２の通信装置の識別情報と前記第１の通信装置の識別情報とを比較する。そして、前記第１の通信装置は、確認結果と比較結果とに基づいて、前記第１の通信装置と前記第２の通信装置との暗号鍵の共有処理において前記第１の通信装置が提供装置として動作するか否かを決定する。

また、前記第１の通信装置が提供装置として動作したことを確認した場合、識別情報の比較結果に基づいて、前記第１の通信装置が前記提供装置として動作するか否かを決定する。

また、前記第１の通信装置が受理装置として動作したことを確認した場合、前記ネットワークに存在する複数の装置間で行われた暗号鍵の共有処理で提供装置として動作した第３の通信装置に対して、前記第２の通信装置の情報を通知する。なお、通知される前記第２の通信装置の情報は、前記第３の通信装置が前記第２の通信装置の役割を決定するために通知される。

また、前記第１の通信装置が受理装置として動作したことを確認した場合、前記第２の通信装置に対して暗号鍵の共有処理の拒否を通知する。

また、前記第１の通信装置は、ネットワークを検索するための検索信号を受信することが可能であり、前記検索信号を受信した場合に、提供装置として動作するか否かの決定が行われる。

端末のブロック構成図 ３台の端末によりアドホック ネットワークを形成した場合の構成図 端末内のソフトウェア機能ブロック図 端末Ａ、端末Ｂ、端末Ｃの動作を表すシーケンス図（その１） 端末Ａ、端末Ｂ、端末Ｃの動作を表すシーケンス図（その２） 端末Ａ、端末Ｂ、端末Ｃの動作を表すシーケンス図（その３） 端末Ａ、端末Ｂ、端末Ｃの動作を表すシーケンス図（その４） 既存端末Ａまたは既存端末Ｂの動作を表すフローチャート 新規端末Ｃの動作を表すフローチャート 前オーセンティケータであった端末の動作を表すフロー図

符号の説明

３０１ 通信装置
３０２ パケット受信部
３０３ パケット送信部
３０４ 検索信号送信部
３０５ 検索信号受信部
３０６ 鍵交換制御部
３０７ 暗号鍵保存部
３０８ 乱数生成部

Claims (10)

1. 暗号鍵を提供する提供装置、もしくは提供装置が提供する暗号鍵を受理する受理装置として動作し、他の装置との間で暗号鍵を共有するための共有処理を行う第１の通信装置であって、
   前記第１の通信装置が参加しているネットワークに存在する複数の装置間で行われた暗号鍵の共有処理において前記第１の通信装置が提供装置として動作したか否かを確認する確認手段と、
   前記ネットワークに新たに参加する第２の通信装置の識別情報と前記第１の通信装置の識別情報とを比較する比較手段と、
   前記確認手段による確認結果と、前記比較手段による比較結果とに基づいて、前記第１の通信装置と前記第２の通信装置との暗号鍵の共有処理において前記第１の通信装置が提供装置として動作するか否かを決定する決定手段と、
   前記確認手段により前記第１の通信装置が受理装置として動作したことを確認した場合、前記ネットワークに存在する複数の装置間で行われた暗号鍵の共有処理で提供装置として動作した第３の通信装置に対して、前記第２の通信装置の情報を通知する第１の通知手段と、
   を有することを特徴とする第１の通信装置。
2. 前記第１の通知手段により通知される前記第２の通信装置の情報は、前記第３の通信装置が前記第２の通信装置の役割を決定するために通知されることを特徴とする請求項１記載の第１の通信装置。
3. 暗号鍵を提供する提供装置、もしくは提供装置が提供する暗号鍵を受理する受理装置として動作し、他の装置との間で暗号鍵を共有するための共有処理を行う第１の通信装置であって、
   前記第１の通信装置が参加しているネットワークに存在する複数の装置間で行われた暗号鍵の共有処理において前記第１の通信装置が提供装置として動作したか否かを確認する確認手段と、
   前記ネットワークに新たに参加する第２の通信装置の識別情報と前記第１の通信装置の識別情報とを比較する比較手段と、
   前記確認手段による確認結果と、前記比較手段による比較結果とに基づいて、前記第１の通信装置と前記第２の通信装置との暗号鍵の共有処理において前記第１の通信装置が提供装置として動作するか否かを決定する決定手段と、
   前記確認手段により前記第１の通信装置が受理装置として動作したことを確認した場合、前記第２の通信装置に対して暗号鍵の共有処理の拒否を通知する通知手段と、
   を有することを特徴とする第１の通信装置。
4. 暗号鍵を提供する提供装置、もしくは提供装置が提供する暗号鍵を受理する受理装置として動作する第１の通信装置であって、
   暗号鍵を共有するための暗号鍵共有処理を他の装置と実行する実行手段と、
   前記第１の通信装置と第３の通信装置の間で実行された第１の暗号鍵共有処理における前記第１の通信装置の役割を確認する確認手段と、
   ネットワークに新たに参加する第２の通信装置の識別情報と前記第１の通信装置の識別情報とを比較する比較手段と、
   前記確認手段による確認結果と、前記比較手段による比較結果とに基づいて、前記第１の通信装置と前記第２の通信装置との間で実行する第２の暗号鍵共有処理における前記第１の通信装置の役割を決定する決定手段と、
   前記第１の暗号鍵共有処理において前記第１の通信装置が前記提供装置として動作し、かつ、前記第２の暗号鍵共有処理において前記第１の通信装置が提供装置として動作しない場合、新たな提供装置となった前記第２の通信装置を識別するための情報を前記第３の通信装置に通知または前記第１の暗号鍵共有処理において暗号鍵を受理する受理装置として動作した前記第３の通信装置を識別するための情報を前記第２の通信装置に通知する通知手段と、
   を有することを特徴とする第１の通信装置
5. 前記確認手段により前記第１の通信装置が提供装置として動作したことを確認した場合、前記決定手段は、前記比較手段による比較結果に基づいて、前記第１の通信装置が前記提供装置として動作するか否かを決定することを特徴とする請求項１から４のいずれか１項に記載の第１の通信装置。
6. ネットワークを検索するための検索信号を受信する受信手段を有し、
   前記決定手段による決定は、前記検索信号を受信した場合に行われることを特徴とする請求項１から５のいずれか１項に記載の第１の通信装置。
7. 暗号鍵を提供する提供装置、もしくは提供装置が提供する暗号鍵を受理する受理装置として動作し、他の装置との間で暗号鍵を共有するための共有処理を行う第１の通信装置の制御方法であって、
   前記第１の通信装置が参加しているネットワークに存在する複数の装置間で行われた暗号鍵の共有処理において前記第１の通信装置が提供装置として動作したか否かを確認する確認工程と、
   前記ネットワークに新たに参加する第２の通信装置の識別情報と前記第１の通信装置の識別情報とを比較する比較工程と、
   前記確認工程における確認結果と、前記比較工程における比較結果とに基づいて、前記第１の通信装置と前記第２の通信装置との暗号鍵の共有処理において前記第１の通信装置が提供装置として動作するか否かを決定する決定工程と、
   前記確認工程において前記第１の通信装置が受理装置として動作したことを確認した場合、前記ネットワークに存在する複数の装置間で行われた暗号鍵の共有処理で提供装置として動作した第３の通信装置に対して、前記第２の通信装置の情報を通知する通知工程と、
   を有することを特徴とする制御方法。
8. 暗号鍵を提供する提供装置、もしくは提供装置が提供する暗号鍵を受理する受理装置として動作し、他の装置との間で暗号鍵を共有するための共有処理を行う第１の通信装置の制御方法であって、
   前記第１の通信装置が参加しているネットワークに存在する複数の装置間で行われた暗号鍵の共有処理において前記第１の通信装置が提供装置として動作したか否かを確認する確認工程と、
   前記ネットワークに新たに参加する第２の通信装置の識別情報と前記第１の通信装置の識別情報とを比較する比較工程と、
   前記確認工程における確認結果と、前記比較工程における比較結果とに基づいて、前記第１の通信装置と前記第２の通信装置との暗号鍵の共有処理において前記第１の通信装置が提供装置として動作するか否かを決定する決定工程と、
   前記確認工程における前記第１の通信装置が受理装置として動作したことを確認した場合、前記第２の通信装置に対して暗号鍵の共有処理の拒否を通知する通知工程と、
   を有することを特徴とする制御方法。
9. 暗号鍵を提供する提供装置、もしくは提供装置が提供する暗号鍵を受理する受理装置として動作する第１の通信装置の制御方法であって、
   暗号鍵を共有するための暗号鍵共有処理を他の装置と実行する実行工程と、
   前記第１の通信装置と前記第３の通信装置の間で実行された第１の暗号鍵共有処理における前記第１の通信装置の役割と、ネットワークに新たに参加する第２の通信装置の識別情報と、前記第１の通信装置の識別情報と、に基づいて、前記第１の通信装置と前記第２の通信装置との間で実行する第２の暗号鍵共有処理における前記第１の通信装置の役割を決定する決定工程と、
   前記第１の暗号鍵共有処理において前記第１の通信装置が前記提供装置として動作し、かつ、前記第２の暗号鍵共有処理において前記第１の通信装置が提供装置として動作しない場合、新たな提供装置となった前記第２の通信装置を識別するための情報を前記第３の通信装置に通知または前記第１の暗号鍵共有処理において暗号鍵を受理する受理装置として動作した前記第３の通信装置を識別するための情報を前記第２の通信装置に通知する通知工程と、
   を有することを特徴とする制御方法。
10. 請求項７から９いずれか１項に記載の制御方法を通信装置に実行させるためのコンピュータプログラム。

Images