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

Abstract

【課題】 アドホックネットワークにおける鍵共有処理において速やかに役割を決定する
【解決手段】 第１の通信装置は、参加するネットワークに存在する複数の装置間で行われた暗号鍵の共有処理において提供装置として動作した第２の通信装置の識別情報を取得する。そして、取得した第２の通信装置の識別情報と、前記第１の通信装置の識別情報との比較結果に基づいて、前記第１の通信装置が提供装置、受理装置のいずれで動作するかを決定する。
【選択図】 図２

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

本発明は、暗号鍵を提供する提供装置、もしくは提供装置が提供する暗号鍵を受理する受理装置として動作し、他の装置との間で暗号鍵を共有するための共有処理を行う第１の通信装置であって、前記第１の通信装置が参加するネットワークに存在する複数の装置間で行われた暗号鍵の共有処理において提供装置として動作した第２の通信装置の識別情報を取得する取得手段と、前記取得手段により取得した第２の通信装置の識別情報と、前記第１の通信装置の識別情報との比較結果に基づいて、前記第１の通信装置が提供装置、受理装置のいずれで動作するかを決定する決定手段と、を有することを特徴とする。

また、本発明は、暗号鍵を提供する提供装置、もしくは提供装置が提供する暗号鍵を受理する受理装置として動作し、他の装置との間で暗号鍵を共有するための共有処理を行う第１の通信装置の制御方法であって、前記第１の通信装置が参加するネットワークに存在する複数の装置間で行われた暗号鍵の共有処理において提供装置として動作した第２の通信装置の識別情報を取得する取得工程と、前記取得工程において取得した第２の通信装置の識別情報と、前記第１の通信装置の識別情報との比較結果に基づいて、前記第１の通信装置が提供装置、受理装置のいずれで動作するかを決定する決定工程と、を有することを特徴とする。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここで図４のシーケンス図を説明する。

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

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

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

比較した結果、端末Ｂは、端末Ｂ＞端末ＣというＭＡＣアドレスの大小関係があることを判定する。そして端末Ｂは、端末Ｃに向けて、前オーセンティケータの情報（ＭＡＣアドレス等）を通知する（Ｆ４０４）。

ここで、前オーセンティケータとは、新規端末が参加しようとするネットワーク内に既に存在している端末間で行われた暗号鍵の交換処理において、オーセンティケータとして動作した端末のことを指す。本シーケンスにおいては、端末Ａと端末Ｂとの間で行われた鍵交換処理において、オーセンティケータとして動作した端末Ａが前オーセンティケータである。

端末Ｃは、Ｆ４０４で受信した前オーセンティケータのＭＡＣアドレス（即ち端末ＡのＭＡＣアドレス）と、自端末のＭＡＣアドレスを比較する（Ｆ４０５）。ここでは、端末Ｃは端末Ａ＞端末ＣというＭＡＣアドレスの大小関係があることを判定し、端末Ａがオーセンティケータとなり、端末Ｃがサプリカントとなることを決定する。そして、端末Ｃは４ウェイハンドシェイクの開始を要求するため、端末ＡにむけてＥＡＰＯＬ−ＳＴＡＲＴを送信する（Ｆ４０６）。ここで、ＥＡＰＯＬ−ＳＴＡＲＴとは、認証の開始を要求するために用いられるメッセージであるが、本実施形態においては、暗号鍵の交換処理の開始を要求するためのメッセージとして用いるものとする。

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

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

なお、Ｆ４０４で前オーセンティケータ端末Ａの情報を受信した場合に、端末Ｃは直ちにＭＡＣアドレスの比較（Ｆ４０５）を行わず、前オーセンティケータ端末Ａを指定してユニキャストでプローブリクエストを送信するようにしてもよい。この場合、前オーセンティケータ端末Ａからのプローブレスポンスを受信した場合に、Ｆ４０５以降の処理をするようにすることにより、前オーセンティケータがネットワークに存在するか否かを確認してから、暗号鍵の交換処理を行うことができる。前オーセンティケータ端末Ａからのプローブレスポンスを一定時間受信できない場合は、電波障害等により通信不能になっているか、前オーセンティケータがネットワークから離脱していることが考えられる。従って、この場合は、一定時間経過後に再度端末Ａに対してプローブリクエストを送信し、端末Ａの存在が確認できた場合に暗号鍵の交換処理を行うようにする。所定回数プローブリクエストを送信しても、レスポンスがない場合、端末Ａとの暗号鍵の交換処理を中止し、端末Ｃから端末Ｂに対してＥＡＰＯＬ−ＳＴＡＲＴを送信することにより端末Ｃと端末Ｂとの間で暗号鍵の交換処理を行うようにする。

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

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

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

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

比較した結果、端末Ａは、端末Ｃ＜端末ＡというＭＡＣアドレスの大小関係があることを判定する。そして端末Ａは、端末Ｃに向けて前オーセンティケータ（端末Ｂとの鍵交換処理においてオーセンティケータとして動作した端末Ａ）の情報（ＭＡＣアドレス等）を通知する（Ｆ５０４）。

端末Ｃは、Ｆ５０４で受信したオーセンティケータのＭＡＣアドレス（即ち端末ＡのＭＡＣアドレス）と、自端末のＭＡＣアドレスを比較する（Ｆ５０５）。ここでは、端末Ｃは端末Ａ＞端末ＣというＭＡＣアドレスの大小関係があることを判定し、端末Ａがオーセンティケータとなり、端末Ｃがサプリカントとなることを決定する。そして、端末Ｃは４ウェイハンドシェイクの開始を要求するため、端末ＡにむけてＥＡＰＯＬ−ＳＴＡＲＴを送信する（Ｆ５０６）。

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

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

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

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

まず、端末Ａからプローブレスポンスの返信があった場合は、端末ＣはＭＡＣアドレスの大小関係が端末Ａ＞端末Ｃであることが分かるため、結果として図５と同じシーケンスとなる。

同様に、端末Ｂからプローブレスポンスの返信があった場合は、端末Ｂは図４のＦ４０３で、ＭＡＣアドレスの大小関係が端末Ｃ＞端末Ｂであることを判定し、前オーセンティケータである端末Ａの情報を端末Ｃに送信する。その結果として、先に説明した図４と同じシーケンスとなる。

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

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

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

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

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

比較した結果、端末Ｂは、端末Ｃ＞端末ＢというＭＡＣアドレスの大小関係があることを判定する。そして、端末Ｃに向けて、前オーセンティケータ（端末Ｂとの鍵交換処理においてオーセンティケータとして動作した端末Ａ）の情報（ＭＡＣアドレス等）を通知する（Ｆ６０４）。

端末Ｃは、端末Ｂからの通知に含まれる端末ＡのＭＡＣアドレスと自端末のＭＡＣアドレスを比較し（Ｆ６０５）、端末Ｃ＞端末Ａであると判定する。これにより、端末Ｃは自身がオーセンティケータとなることを決定し、端末Ａへ４ウェイハンドシェイクのメッセージ１を送信する（Ｆ６０６）。端末Ａと端末Ｃが通信可能であれば、以下４ウェイハンドシェイクを続行し、引き続きグループキーハンドシェイクを実施する（Ｆ６０７〜Ｆ６１１）。

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

サプリカント情報の通知を受けた端末Ｃは、各サプリカントとの間で新たに暗号鍵の交換処理を実施する（Ｆ６１３〜Ｆ６１８）。

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

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

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

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

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

比較した結果、端末Ａは、端末Ｃ＞端末ＡというＭＡＣアドレスの大小関係があることを判定する。そして、端末Ａは、端末Ｃに向けて前オーセンティケータ（端末Ｂとの鍵交換処理においてオーセンティケータとして動作した端末Ａ）の情報（ＭＡＣアドレス等）を通知する（Ｆ７０４）。

端末Ｃは、端末Ａからの通知に含まれる端末ＡのＭＡＣアドレスと自端末のＭＡＣアドレスを比較し（Ｆ７０５）、端末Ｃ＞端末Ａであると判定する。これにより、端末Ｃは自身がオーセンティケータになることを決定し、端末Ａへ４ウェイハンドシェイクのメッセージ１を送信する（Ｆ７０６）。

端末Ａと端末Ｃが通信可能であれば、以下４ウェイハンドシェイクを続行し、引き続きグループキーハンドシェイクを実施する（Ｆ７０７〜Ｆ７１１）。

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

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

以上で説明した処理シーケンスを実現するための、各端末の動作フローチャートについて説明する。図８は、既存ネットワーク２１に存在する端末（以下、既存端末）のうち、新規端末からのプローブリクエストに対して応答する端末の動作フローチャートを示した図である。

同様に、新規端末Ｃの動作フローチャートを示したのが図９である。

まず図８について説明を行う。

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

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

Ｓ８０３の比較により、自端末のＭＡＣアドレスが新規端末ＣのＭＡＣアドレスより大きい場合は、前オーセンティケータ端末の情報（ＭＡＣアドレス等）を新規端末Ｃに向けて送信する（Ｓ８０４）。なお、前述の各シーケンスにおいても説明したように、前オーセンティケータとは、新規端末Ｃが参加しようとするネットワーク内の既存端末ＡとＢにおいて暗号鍵の交換処理を行った際に、オーセンティケータとして動作した端末を示す。

従って、前オーセンティケータ端末は、既存端末Ａ自身である場合もある。

その後、既存端末ＡはＥＡＰＯＬ−ＳＴＡＲＴが新規端末Ｃから送信されるのを待ち受ける（Ｓ８０５）。ＥＡＰＯＬ−ＳＴＡＲＴを受信した場合は、既存端末Ａは新規端末Ｃとの間で４ウェイハンドシェイクおよびグループキーハンドシェイクを実施し、暗号鍵の交換処理を完了させる（Ｓ８０６）。

一方、Ｓ８０３の比較により、自端末のＭＡＣアドレスが新規端末ＣのＭＡＣアドレスより小さい場合は、前オーセンティケータ端末の情報（ＭＡＣアドレス等）を新規端末Ｃに向けて送信する（Ｓ８０７）。

その後、既存端末Ａは４ウェイハンドシェイクのメッセージ１が新規端末Ｃから送信されるのを待ち受ける（Ｓ８０８）。４ウェイハンドシェイクのメッセージ１を受信した場合は、既存端末Ａは新規端末Ｃとの間で残りの４ウェイハンドシェイクおよびグループキーハンドシェイクを実施し、暗号鍵の交換処理を完了させる（Ｓ８０９）。

次に、既存端末Ａが前オーセンティケータ端末であった場合、ネットワークとして暗号鍵を統一するために、新規端末Ｃへ向けて、いままで自端末が把握していたサプリカント（この場合は端末Ｂ）の情報を転送する（Ｓ８１０）。この場合、新たなオーセンティケータ端末Ｃが、既存端末Ａから転送された情報に基づいて、端末Ｂとの間で暗号鍵の交換処理を行う。

なお、Ｓ８１０については、既存端末Ａが把握しているサプリカント（この場合は端末Ｂ）に、新しいオーセンティケータ端末Ｃの情報を通知してもよい。この場合、端末Ｂから端末Ｃに対してＥＡＰＯＬ−ＳＴＡＲＴを送信し、これを契機として暗号鍵の交換処理を行う。

なお、既存端末Ａが前オーセンティケータ端末でない場合（すなわちサプリカント端末であった場合）、Ｓ８１０の処理は省略される。

次に新規端末の動作について図９を用いて説明を行う。

新規端末（本実施の形態においては端末Ｃ）は、ブロードキャストでプローブリクエストを送信する（Ｓ９０１）。そして新規端末Ｃは、プローブリクエストを受信した既存端末から、プローブレスポンスを受信する（Ｓ９０２）。ここでも、図８の説明と同様、端末Ａがプローブレスポンスを送信したものとして説明する。

新規端末Ｃは、プローブレスポンスの送信元端末Ａから、前オーセンティケータの情報（ＭＡＣアドレス等）の受信を待つ（Ｓ９０３）。受信しない場合は、当該ネットワークは、本実施形態に未対応のネットワークであるので、再度ネットワークの探索からやり直し、対応しているネットワークを探す。

一方、ここで、前オーセンティケータの情報を受信した場合は、端末Ｃは前オーセンティケータ端末のＭＡＣアドレスと自端末のＭＡＣアドレスを比較する（Ｓ９０４）。

なお、前オーセンティケータ端末のＭＡＣアドレスは、プローブレスポンス送信元端末ＡのＭＡＣアドレスと同一である場合もある。

なお、図４のシーケンスで説明したように、前オーセンティケータの情報を受信した場合に、当該前オーセンティケータに対してユニキャストでプローブレクエストを送信するようにしてもよい。これにより、前オーセンティケータがネットワークに存在するか否かを確認してから、暗号鍵の交換処理を行うことができる。

比較の結果、新規端末Ｃは自端末のＭＡＣアドレスが前オーセンティケータ端末のＭＡＣアドレスよりも大きい場合は、自端末の役割をオーセンティケータに決定する（Ｓ９０５）。

自端末の役割がオーセンティケータとして決定したため、新規端末Ｃはプローブレスポンスの送信元端末Ａとの間で４ウェイハンドシェイク、及びグループキーハンドシェイクを実施する（Ｓ９０６）。

そして、前オーセンティケータ端末から、サプリカント端末の情報を受信すると（Ｓ９１０）、新規端末Ｃは当該サプリカント端末との間での４ウェイハンドシェイクおよびグループキーハンドシェイクを実施し、暗号鍵の交換処理を完了させる（Ｓ９１１）。なお、Ｓ９１０においてサプリカント端末の情報通知を受信する代わりに、サプリカント端末からのＥＡＰＯＬ−ＳＴＡＲＴを受信した場合は、当該サプリカント端末との間で４ウェイハンドシェイクおよびグループキーハンドシェイクを実施する（Ｓ９１１）。

Ｓ９０４におけるＭＡＣアドレスの比較の結果、新規端末Ｃは自端末のＭＡＣアドレスが前オーセンティケータ端末のＭＡＣアドレスよりも小さい場合は、自端末の役割をサプリカントに決定する（Ｓ９０７）。

自端末の役割をサプリカントに決定した場合、新規端末Ｃは前オーセンティケータ端末へ向けてＥＡＰＯＬ−ＳＴＡＲＴを送信する（Ｓ９０８）。

その後４ウェイハンドシェイクおよびグループキーハンドシェイクを実施し、暗号鍵の交換処理を完了させる（Ｓ９０９）。
以上が、既存ネットワークに新規参加を試みる端末の動作フローである。

以上のように、新規端末が既存端末から取得した前オーセンティケータの情報に基づいて、自端末がオーセンティケータになるかサプリカントになるかを決定することによって、ネットワーク全体として鍵を統一させることが容易となる。

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

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

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

また、上記実施形態においては、２台の端末ＡとＢが既にネットワークに参加している場合に、新規端末Ｃがネットワークに参加する場合について説明した。この場合、上述の前オーセンティケータは、端末Ａと端末Ｂとの間で行われた暗号鍵の交換処理においてオーセンティケータとして動作した端末Ａを指すものとして説明した。ここで、端末Ｃがネットワークに参加した後、新たに別の端末Ｄがネットワークに参加するために暗号鍵の交換処理を行う場合について説明する。この場合、図８のＳ８０４又はＳ８０７では、端末Ｃが参加する際に暗号鍵の交換処理を行った際にオーセンティケータとして動作した端末の情報が、前オーセンティケータ情報として新規端末Ｄに通知される。

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

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

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

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

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

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

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

また、前記第１の通信装置は、参加するネットワークを検索するための検索信号を送信し、前記検索信号に対する応答を送信した装置から前記第２の通信装置の識別情報を取得する。このように検索信号を送信することにより、参加するネットワークに存在する複数の装置間で行われた暗号鍵の共有処理が行われた際に提供装置として動作した通信装置の識別情報を取得することができる。

また、前記第１の通信装置が提供装置として動作することを決定した場合、前記第１の通信装置から前記第２の通信装置に対して、暗号鍵の共有処理を開始する。これにより、新規にネットワークに参加する通信装置が提供装置になり、以前に提供装置として動作していた通信装置との間で、暗号鍵の共有処理を行うことができる。

また、前記第１の通信装置が参加するネットワークに存在する複数の装置間で行われた暗号鍵の共有処理において受理装置として動作した第３の通信装置の識別情報を、前記第２の通信装置から受信する。そして、前記第１の通信装置から前記第３の通信装置に対して、暗号鍵の共有処理を開始する。これにより、ネットワークに存在する複数の通信装置間で共通の暗号鍵を共有することができる。

また、前記第１の通信装置が受理装置として動作することを決定した場合、前記第２の通信装置に対して、暗号鍵の共有処理の開始を要求する。これにより、以前に提供装置として動作した通信装置がそのまま提供装置として動作し、新規に参加する通信装置との間に暗号鍵を共有することができる。

本発明の実施形態における端末のブロック構成図 本発明の実施形態における３台の端末によりアドホック ネットワークを形成した場合の構成図 本発明の実施形態における端末内のソフトウェア機能ブロック図 第一の実施形態における端末Ａ，端末Ｂ，端末Ｃの動作を表すシーケンス図（その１） 第一の実施形態における端末Ａ，端末Ｂ，端末Ｃの動作を表すシーケンス図（その２） 第一の実施形態における端末Ａ，端末Ｂ，端末Ｃの動作を表すシーケンス図（その３） 第一の実施形態における端末Ａ，端末Ｂ，端末Ｃの動作を表すシーケンス図（その４） 第一の実施形態における端末Ａまたは端末Ｂの動作を表すフロー図 第一の実施形態における端末Ｃの動作を表すフロー図

符号の説明

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

Claims (8)

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

Images