JP5018315B2 - 無線通信システム、無線通信装置、無線通信装置の認証方法、および、プログラム - Google Patents

Description

本発明は、無線通信システムに関し、特に複数の無線通信装置が自律分散してネットワークを形成する無線通信システム、無線通信装置、および、これらにおける処理方法ならびに当該方法をコンピュータに実行させるプログラムに関する。

無線技術を用いてネットワークを構成する態様として、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１ｉでは、インフラストラクチャ（Infrastructure）型無線ＬＡＮ（Local Area Network）システムが定義されている。このインフラストラクチャ型無線ＬＡＮシステムでは、アクセスポイント（ＡＰ：Access Point）等と呼ばれる無線通信装置の統括的な制御下でネットワークが形成される。

このＩＥＥＥ８０２．１１ｉでは、インフラストラクチャ型無線ＬＡＮシステムの他に、ＩＢＳＳ（Independent Basic Service Set）型無線ＬＡＮシステムが定義されている。このＩＢＳＳ型無線ＬＡＮシステムでは、特定のアクセスポイントによる統括的制御は行われず、無線端末として動作する任意の無線通信装置同士が自律分散して直接非同期の無線通信を行うことによりネットワークが形成される。

また、ＩＥＥＥ８０２．１１ｓにおいて定義されているメッシュ（Mesh）型無線ＬＡＮシステムにおいても、無線通信装置同士が自律分散して直接非同期の無線通信を行うことによりネットワークが形成される。このメッシュ型無線ＬＡＮシステムでは、直接電波が届かない範囲に存在する無線通信装置に対して他の無線通信装置を経由することによって、マルチホップによる通信が行われる。以下では、ＩＢＳＳ型無線ＬＡＮシステムおよびメッシュ型無線ＬＡＮシステムを自律分散型無線ＬＡＮシステムと総称する。

これらインフラストラクチャ型無線ＬＡＮシステムおよび自律分散型無線ＬＡＮシステムの何れにおいても、セキュリティ機能を向上させるための手法として、ＩＥＥＥ８０２．１Ｘの認証サーバ（ＡＳ：Authentication Server）を利用した認証方式が想定されている。インフラストラクチャ型無線ＬＡＮシステムでは、全ての無線端末の認証情報は認証サーバで集中管理され、アクセスポイントが認証サーバへの認証プロキシとなって、無線端末と認証サーバとの間の認証プロトコルシーケンスを取り次ぐという具合に、各端末の役割を明示的に決めることができる。このように、他の無線端末のために認証サーバへの認証プロキシとして動作するエンティティをオーセンティケータ（Authenticator）と呼び、オーセンティケータを介して認証処理を受けるエンティティをサプリカント（Supplicant）と呼ぶ。一方、自律分散型無線ＬＡＮシステムにおいては、個々の無線端末の役割は明示的には定められていないため、何れかの無線端末がオーセンティケータおよび認証サーバの役割を有し、他の無線端末がサプリカントの役割を有する。

しかし、これらＩＥＥＥ８０２．１１ｉおよび８０２．１１ｓでは、ＩＥＥＥ８０２．１Ｘの使用を想定しているものの、具体的な認証プロトコルは定められていない。そこで、ＩＥＴＦ（Internet Engineering Task Force）では、ＩＥＥＥ８０２．１Ｘの上位に位置する認証プロトコルとして、ＥＡＰ（Extensible Authentication Protocol）を採用することで、柔軟性および拡張性を提供している。

ＥＡＰでは、暗号化プロトコルと組み合わせることにより、具体的な認証方式を実現することができる。ここでは、暗号化プロトコルとしてＴＬＳ（Transport Layer Security）を利用する場合を想定する。暗号化プロトコルとしてＴＬＳを利用したＥＡＰによる認証方式は、ＥＡＰ−ＴＬＳ認証方式と呼ばれる。このＥＡＰ−ＴＬＳ認証方式は、認証サーバおよびクライアントの相互で電子証明書（公開鍵証明書）を利用した認証を行う方式である。認証サーバおよび各端末に対して認証機関（ＣＡ：Certification Authority）が予め公開鍵証明書を発行しておく必要があるが、パスワードなどに頼らないシステムであり、安全性も非常に高いことが知られている（例えば、非特許文献１参照。）。
B. Aboba and D. Simon: "PPP EAP TLS Authentication Protocol", RFC 2716, Network Working Group, IETF（http://www.ietf.org/rfc/rfc2716.txt）

しかし、ＥＡＰ−ＴＬＳ認証方式では、認証サーバにとって信頼する認証機関により発行された公開鍵証明書であれば、その公開鍵証明書を有する者からの接続は全て許可するようになっており、特定の者にのみ認証を許可するような仕組みにはなっていない。

特定の者に限った許可を実現するためには、何らかの認証情報を管理する必要があるが、そのような管理は一般に煩雑になる。特に、自律分散型無線ＬＡＮシステムでは、無線端末は移動する可能性もあり、その時々によってネットワークを構成する端末が異なるため、そのような管理のための通信路が常に確保されているとは限らない。すなわち、自律分散型無線ＬＡＮシステムにおいて認証相手を制御するためには、無線端末の認証情報を効率的に分散して管理する必要がある。

そこで、本発明は、自律分散型無線ＬＡＮシステムにおいて認証相手を制御して、セキュアなネットワークを形成することを目的とする。

本発明は、上記課題を解決するためになされたものであり、その第１の側面は、複数の無線通信装置が自律分散してネットワークを形成する無線通信システムにおいて、上記複数の無線通信装置の各々は、所定の条件を満たす他の無線通信装置から当該他の無線通信装置の識別情報を取得する識別情報取得手段と、上記取得された他の無線通信装置の識別情報を保持する識別情報保持手段と、上記他の無線通信装置の認証を行う際に上記他の無線通信装置の証明書における識別情報が上記識別情報保持手段に保持されていることを条件として上記認証を継続する認証手段とを具備することを特徴とする無線通信システムである。これにより、予め識別情報が取得された無線通信装置に限定して認証処理を継続させて、セキュアなネットワークを形成させるという作用をもたらす。

また、本発明の第２の側面は、複数の無線通信装置が自律分散してネットワークを形成する無線通信システムにおける無線通信装置であって、所定の条件を満たす他の無線通信装置から当該他の無線通信装置の識別情報を取得する識別情報取得手段と、上記取得された他の無線通信装置の識別情報を保持する識別情報保持手段と、上記他の無線通信装置の認証を行う際に上記他の無線通信装置の証明書における識別情報が上記識別情報保持手段に保持されていることを条件として上記認証を継続する認証手段とを具備することを特徴とする無線通信装置である。これにより、予め識別情報が取得された無線通信装置に限定して認証処理を継続させて、セキュアなネットワークを形成させるという作用をもたらす。

また、この第２の側面において、上記識別情報保持手段は、上記取得された他の無線通信装置の識別情報に関連付けて上記他の無線通信装置の認証可否に関する情報を認証可否情報として保持し、上記認証手段は、上記他の無線通信装置の認証を行う際に上記他の無線通信装置の証明書における識別情報と上記識別情報保持手段に保持された識別情報とが一致し且つ上記認証可否情報が認証可能である旨を示していることを条件として上記認証を継続するようにしてもよい。これにより、識別情報保持手段に識別情報が保持された無線通信装置に対して個別に認証の可否を設定させるという作用をもたらす。

また、この第２の側面において、上記認証手段は、上記認証可否情報が認証を認めない旨を示す情報の場合であっても、ユーザに対して認証継続の可否判断を促すための情報を提示した後、認証を継続する旨の入力がなされると、上記条件に合致するか否かを問わず上記認証を継続してもよい。これにより、ユーザの意思を確認し、ユーザが中止不要と判断した場合には認証シーケンスを継続させるという作用をもたらす。

また、この第２の側面において、上記識別情報保持手段に保持される上記他の無線通信装置の識別情報は当該他の無線通信装置の装置名を含み、上記他の無線通信装置の証明書は上記他の無線通信装置の公開鍵証明書であって、上記証明書における識別情報は上記他の無線通信装置の装置名を含んでもよい。この公開鍵証明書は、Ｘ．５０９フォーマットの公開鍵証明書を利用することができる。

また、この第２の側面において、上記識別情報保持手段に保持される上記他の無線通信装置の識別情報は当該他の無線通信装置の電話番号を含み、上記証明書における識別情報は当該他の無線通信装置の電話番号を含んでもよい。これにより、携帯電話端末としての機能を有する通信装置において、電話帳を識別情報保持手段として機能させるという作用をもたらす。

本発明によれば、自律分散型無線ＬＡＮシステムにおいてセキュアなネットワークを形成することができるという優れた効果を奏し得る。

（１）第1の実施の形態
次に本発明の第１の実施の形態について図面を参照して詳細に説明する。

図１は、本発明の第１の実施の形態における通信装置１００の一構成例を示す図である。この通信装置１００は、通信制御部１０１と、無線ネットワークインターフェース１０２と、無線通信設定データ保持部１０３と、近隣端末リスト１０４と、経路テーブル１０５と、アクセス制御リスト１０７と、同期ボタン１０９とを備え、無線アドホックネットワーク１９０を介して他の通信装置と通信を行う。

通信制御部１０１は、通信装置１００全体の制御を行うものである。他の通信装置との間で行われる認証処理もこの通信制御部１０１によって実行される。

無線ネットワークインターフェース１０２は、無線アドホックネットワーク１９０との間のやりとりを行うインターフェースである。

無線通信設定データ保持部１０３は、無線通信を行うための設定データを保持するものである。設定データとしては、例えば、無線アドホックネットワーク１９０を識別するためのサービスセット識別子（ＳＳＩＤ：Service Set IDentifier）、ＲＳＮ（Robust Security Network：強固なセキュリティネットワーク）のために用いられる暗号や公開鍵証明書などのセキュリティ設定データ、通信装置１００のＭＡＣアドレス、通信装置１００の装置名等が保持される。

近隣端末リスト１０４は、無線アドホックネットワーク１９０において通信装置１００の近隣に存在する通信装置（近隣端末）の一覧を含むリストである。通信制御部１０１は、他の通信装置から定期的に送信されるビーコンを受信することにより、この近隣端末リスト１０４に最新の状態が反映されるよう制御する。

経路テーブル１０５は、無線アドホックネットワーク１９０において他の通信装置に到達するための経路の一覧を含むテーブルであり、具体的には、最終的な送信先となる通信装置の識別子およびその送信先に宛てたフレームを中継する通信装置の識別子を保持する。

アクセス制御リスト１０７は、認証を行う相手について個別に認証可否を示す認証情報の一覧を含むリストである。通信制御部１０１は、このアクセス制御リスト１０７を参照して、認証相手について個別に認証許否を実行する。

同期ボタン１０９は、アクセス制御リスト１０７へ認証情報を追加するためのユーザインターフェースである。この同期ボタン１０９が押下された際、他の通信装置においても同様に同期ボタンが押下されると、当該他の通信装置の認証情報がアクセス制御リスト１０７へ追加される。

図２は、本実施の形態で利用される公開鍵証明書６１０の構成を示す図である。図２（ａ）のように、公開鍵証明書６１０は、署名前証明書６１１と、署名アルゴリズム６１８と、署名６１９とに大別される。署名前証明書６１１は、シリアル番号６１２と、発行者情報（issuer Distinguished Name）６１４と、有効期限６１５と、所有者情報（subject Distinguished Name）６１６と、所有者公開鍵６１７とを含む。

シリアル番号６１２は、公開鍵証明書のシリアル番号であり、認証機関（ＣＡ）によって採番される。発行者情報６１４は、公開鍵証明書の発行者である認証機関に関する識別情報である。この発行者情報６１４とシリアル番号６１２とにより公開鍵証明書は一意に識別される。有効期限６１５は、公開鍵証明書の有効期限である。所有者情報６１６は、公開鍵証明書の所有者に関する識別情報である。所有者公開鍵６１７は、所有者情報６１６に示される所有者の公開鍵である。

署名６１９は公開鍵証明書に対する認証局による署名であり、署名アルゴリズム６１８はこの署名６１９のために使用された署名アルゴリズムである。署名アルゴリズムは、メッセージダイジェストアルゴリズムと公開鍵暗号アルゴリズムの２つにより構成される。メッセージダイジェストアルゴリズムは、ハッシュ関数（要約関数）の一つであり、署名前証明書６１１のメッセージダイジェストを作成するためのアルゴリズムである。ここで、メッセージダイジェストとは、入力データ（署名前証明書６１１）を固定長のビット列に圧縮したものであり、拇印や指紋（フィンガープリント）等とも呼ばれる。メッセージダイジェストアルゴリズムとしては、ＳＨＡ−１（Secure Hash Algorithm 1）、ＭＤ２（Message Digest #2）、ＭＤ５（MESSAGE Digest #5）等が知られている。公開鍵暗号アルゴリズムは、メッセージダイジェストアルゴリズムにより得られたメッセージダイジェストを認証機関の秘密鍵により暗号化するためのアルゴリズムである。この公開鍵暗号アルゴリズムとしては、素因数分解問題に基づくＲＳＡや離散対数問題に基づくＤＳＡ等が知られている。このように、署名前証明書６１１のメッセージダイジェストを認証機関の秘密鍵により暗号化したものが署名６１９となる。

従って、この公開鍵証明書の署名６１９を認証局の公開鍵により復号することによってメッセージダイジェストが得られる。公開鍵証明書の利用者は、署名前証明書６１１のメッセージダイジェストを自身で作成し、それを認証局の公開鍵により復号されたメッセージダイジェストと比較することにより、署名前証明書６１１の内容が改ざんされていないことを検証できる。

図２（ｂ）は、所有者情報６１６として保持される識別情報の内訳を示す図である。ここでは、一例として、国名（Ｃ：Country Name）６２１、組織名（Ｏ：Organization Name）６２２、部門名（ＯＵ：Organization Unit Name）６２３、および、一般名（ＣＮ：Common Name）６２４が示されている。

国名６２１は、所有者の国籍を示すものである。組織名６２２は、所有者の所属する組織名を示すものである。部門名６２３は、所有者の所属する組織内の部門名を示すものである。一般名６２４は、所有者の一般的な名称を示すものであり、例えば、その通信装置に付与された装置名やＵＲＬ（Uniform Resource Locator）アドレス等が用いられる。

図３は、本実施の形態におけるアクセス制御リスト１０７の一構成例を示す図である。このアクセス制御リスト１０７の各エントリは、その項目として識別情報７１２および認証可否７１３の各フィールドを関連付けて保持している。

識別情報７１２は、そのエントリに該当する装置の識別情報を保持するフィールドである。登録の際には、対象者の公開鍵証明書６１０に含まれる所有者情報６１６の全ての要素または一部の要素を保持する。この例では、相手の通信装置に付与された装置名「ＤＳＣ−Ｔ９＿００２」等が含まれている。

認証可否７１３は、そのエントリに該当する装置の認証が可能であるか、または、その認証を拒否すべきであるかを示すフィールドである。

なお、ここでは、識別情報７１２に対してその認証可否７１３を関連付けて保持するようにしたが、アクセス制御リスト１０７の構成はこれに限定されない。例えば、認証可否７１３のフィールドを設けずに、認証可能な通信装置の装置名のみを識別情報７１２に保持するようにして、通信制御部１０１は識別情報７１２に装置名が保持されている通信装置の認証を全て許可するように構成してもよい。

本実施の形態における処理は、アクセス制御リストに互いの通信装置の識別情報を登録する第１のフェーズと、通信装置同士で互いの公開鍵証明書の所有者情報がアクセス制御リストのエントリに合致するかを確認して相互認証する第２のフェーズとに大別される。

第１のフェーズにおける識別情報の登録のためには、互いの通信装置の装置名等を直接キーボード等の入力装置によって入力して、アクセス制御リスト１０７を編集してもよい。また、そのような入力装置を使用することなく、相手の通信装置を特定してもよい。相手の通信装置の特定手法としては、本来の通信手段である無線ＬＡＮのインターフェースを用いるインバンド（In-Band）方式や、それ以外のＮＦＣ（Near-Field Communication）、ＵＳＢ（Universal Serial Bus）メモリスティックおよび有線ケーブルといった他のネットワークインターフェースや外部メモリを用いるアウトオブバンド（Out-of-Band）方式などの様々な方式が考えられる。以下では、同期ボタンを利用したインバンド方式による実現例について説明するが、以下に説明する手法に関しては、特開２００４−３２８０９３号公報に記載された手法と同様であるため、概略のみを説明することとする。

図４は、本実施の形態における無線通信システムの各通信装置の識別情報の登録の様子を示す図である。通信装置Ａ１１０には装置名として「ＤＳＣ−Ｔ９＿００１」が付与されており、通信装置Ｂ１２０には装置名として「ＤＳＣ−Ｔ９＿００２」が付与されている。また、通信装置Ａ１１０およびＢ１２０には、それぞれ同期ボタン１１９または１２９が設けられている。

それぞれの通信装置にはＸ．５０９フォーマットの公開鍵証明書が特定の認証機関（ＣＡ）から発行されて備えられているものとする。また互いが公開鍵証明書の正当性を検証できるように、公開鍵証明書発行認証機関（ＣＡ）のサーバ公開鍵証明書、ならびに、そのサーバ公開鍵証明書をチェーン認証するために必要な上位の認証機関の公開鍵証明書も保有しているものとする。

図４（ａ）の初期状態では、それぞれのアクセス制御リスト１１７および１２７には何れの通信装置も登録されていない。そこで、図４（ｂ）のように、通信装置Ａ１１０およびＢ１２０を互いに一定の距離内に近づけた状態で、それぞれの同期ボタン１１９および１２９が押下されると、図４（ｃ）のようにアクセス制御リスト１１７および１２７に互いの装置名が保持されるようになる。すなわち、通信装置Ａ１１０のアクセス制御リスト１１７には通信装置Ｂ１２０の装置名「ＤＳＣ−Ｔ９＿００２」が保持され、通信装置Ｂ１２０のアクセス制御リスト１２７には通信装置Ａ１１０の装置名「ＤＳＣ−Ｔ９＿００１」が保持される。

図５は、本実施の形態における無線通信システムの各通信装置間の識別情報の登録手順例を示す図である。通信装置Ａ１１０において、同期ボタン１１９が時刻Ｔ１からＴ２の間、押下されたものとする。これにより、時間Ｔ（＝Ｔ２−Ｔ１）および通信装置Ａ１１０の装置名（＝「ＤＳＣ−Ｔ９＿００１」）が通信装置Ｂ１２０に送信される。通信装置Ｂ１２０がこれらを受信した時刻をＳ３とする。

また、通信装置Ｂ１２０において、同期ボタン１２９が時刻Ｓ１からＳ２の間、押下されたものとする。これにより、時間Ｓ（＝Ｓ２−Ｓ１）および通信装置Ｂ１２０の装置名（＝「ＤＳＣ−Ｔ９＿００２」）が通信装置Ａ１１０に送信される。通信装置Ａ１１０がこれらを受信した時刻をＴ３とする。

通信装置Ａ１１０は、「｜Ｔ３−Ｔ２｜＜Ｃ２」かつ「｜Ｔ−Ｓ｜＜Ｃ１」であれば、通信装置Ｂ１２０の認証を許可して（３１１）、通信装置Ｂ１２０の装置名をアクセス制御リスト１１７に追加する（３１２）。すなわち、同期ボタン１１９の解除から一定期間Ｃ２内に、通信装置Ｂ１２０から同期ボタン１２９の押下の情報を受け取り、かつ、押下期間の差が一定長Ｃ１に収まっていれば、ほぼ同時期に互いの同期ボタンが押下されたものと判断する。

同様に、通信装置Ｂ１２０は、「｜Ｓ３−Ｓ２｜＜Ｃ２」かつ「｜Ｔ−Ｓ｜＜Ｃ１」であれば、通信装置Ａ１１０の認証を許可して（３２１）、通信装置Ａ１１０の装置名をアクセス制御リスト１２７に追加する（３２２）。

ここでは、ボタンが同時に押下されたことを装置名の登録条件とする例について説明したが、この登録の条件はこれに限定されるものではない。例えば、電波強度判定部を設けて、一方の通信装置からの認証要求の電波強度が閾値以上である旨を電波強度判定部が判定したことを登録条件としてもよい。また、絶対方位を計測する電子コンパスを設けて、通信装置が所定の向き（例えば、対向して位置している状態）にある旨を電子コンパスが判定したことを登録条件としてもよい。

次に本発明の第１の実施の形態における第２のフェーズである相互認証について説明する。このフェーズにおける処理は、従来から規格が策定されているＩＢＳＳ型の無線ＬＡＮシステムにおける場合と、現在、例えば、ＩＥＥＥ８０２．１１ｓにおいて規格化が進められているメッシュ型の無線ＬＡＮシステムにおける場合とで、一部異なったものとなるため、以下、各ネットワークにおける処理毎に分けて説明を行う。

（ａ）ＩＢＳＳ型の無線ＬＡＮシステムにおける処理
図６は、本発明の第１の実施の形態におけるＩＢＳＳ型無線ＬＡＮシステムの各通信装置間の相互認証手順例を示す図である。ＩＥＥＥ８０２．１１ｉに定義されているＩＢＳＳ型無線ＬＡＮシステムでは、ＩＥＥＥ８０２．１Ｘの認証処理をＥＡＰ−ＴＬＳ認証方式により実現する場合、各通信装置がサプリカントとオーセンティケータおよび認証サーバの双方の役割を入れ替えて相互認証を行うことになっている。すなわち、はじめの認証処理においてオーセンティケータおよび認証サーバとなった通信装置がサプリカントに、サプリカントとなった通信装置がオーセンティケータおよび認証サーバになって、再度、認証処理を実行することで、お互いが認証し合う構成となっている。

すなわち、最初に通信装置Ａ１１０がサプリカントとしての役割を有し、通信装置Ｂ１２０がオーセンティケータおよび認証サーバとしての役割を有して、認証シーケンス５１０を行う。そして、その後、通信装置Ａ１１０がオーセンティケータおよび認証サーバとしての役割を有し、通信装置Ｂ１２０がサプリカントとしての役割を有して、認証シーケンス５３０を行う。

図７は、本発明の第１の実施の形態におけるＩＢＳＳ型無線ＬＡＮシステムの認証シーケンス（５１０）の手順例を示す図である。この例では、上述のように、通信装置Ａ１１０がサプリカントとしての役割を有し、通信装置Ｂ１２０がオーセンティケータおよび認証サーバとしての役割を有する。

まず、オーセンティケータおよび認証サーバとしての役割を有する通信装置Ｂ１２０は、サプリカントとしての役割を有する通信装置Ａ１１０に対して、ＩＥＥＥ８０２．１ＸのフレームボディにおいてＥＡＰプロトコルによって通信装置Ａ１１０の識別情報を要求する（５１１）。これに応答して、通信装置Ａ１１０は、自身の識別情報（ＭｙＩＤ）を通信装置Ｂ１２０に返信する（５１２）。

通信装置Ａ１１０の識別情報を確認すると、通信装置Ｂ１２０はＴＬＳによる暗号化プロトコルの開始を通信装置Ａ１１０に通知する（５１３）。これにより、通信装置Ａ１１０は、ＴＬＳのクライアントハロー（ClientHello）メッセージを通信装置Ｂ１２０に送信する（５１４）。このクライアントハローメッセージには、後続の鍵交換の際の鍵のシードとなる２８バイトの乱数（ClientHell.random）が含まれる。

通信装置Ａ１１０からのクライアントハローメッセージを確認すると、通信装置Ｂ１２０は、ＴＬＳのサーバハロー（ServerHello）メッセージを通信装置Ａ１１０に送信する（５１５）。このサーバハローメッセージには、後続の鍵交換の際の鍵のシードとなる２８バイトの乱数（ServerHello.random）が含まれる。

また、通信装置Ｂ１２０は、サーバハローメッセージに続いて、ＴＬＳのサーバ証明（ServerCertificate）メッセージを通信装置Ａ１１０に送信する。このサーバ証明メッセージには、通信装置Ｂ１２０の公開鍵証明書が含まれる。

また、通信装置Ｂ１２０は、サーバ証明メッセージに続いて、ＴＬＳのサーバ鍵交換（ServerKeyExchange）メッセージを通信装置Ａ１１０に送信する。このサーバ鍵交換メッセージは、通信装置Ａ１１０がプリマスター鍵（premaster_secret）を生成するのに必要となる暗号情報を送信するものである。

また、通信装置Ｂ１２０は、サーバ鍵交換メッセージに続いて、ＴＬＳの証明要求（CertificateRequest）メッセージを通信装置Ａ１１０に送信する。この証明要求メッセージは、通信装置Ａ１１０に対して公開鍵証明書を要求するものである。

また、通信装置Ｂ１２０は、証明要求メッセージに続いて、サーバハロー終了（ServerHelloDone）メッセージを通信装置Ａ１１０に送信する。このサーバハロー終了メッセージは、サーバハローメッセージおよびそれに関連するメッセージの終了を通知するものである。

その後、通信装置Ａ１１０およびＢ１２０は、上述のようにして交換された乱数およびプリマスター鍵に基づいて、マスター鍵をそれぞれ生成する（５２１）。

そして、通信装置Ａ１１０は、ＴＬＳのクライアント証明（ClientCertificate）メッセージを通信装置Ｂ１２０に送信する（５１６）。このクライアント証明メッセージには、通信装置Ａ１１０の公開鍵証明書が含まれる。

また、通信装置Ａ１１０は、クライアント証明メッセージに続いて、ＴＬＳのクライアント鍵交換（ClientKeyExchange）メッセージを通信装置Ｂ１２０に送信する。このクライアント鍵交換メッセージは、プリマスター鍵を設定するものである。

また、通信装置Ａ１１０は、クライアント鍵交換メッセージに続いて、ＴＬＳの証明検証（CertificateVerify）メッセージを通信装置Ｂ１２０に送信する。この証明検証メッセージは、通信装置Ａ１１０の公開鍵証明書を検証するためのものである。

また、通信装置Ａ１１０は、証明検証メッセージに続いて、ＴＬＳの暗号化ストラテジ変化（ChangeCipherSpec）メッセージを通信装置Ｂ１２０に送信する。この暗号化ストラテジ変化メッセージは、この後に続くデータが新たな暗号化ストラテジおよび新たな暗号鍵により通信されることを通知するものである。

また、通信装置Ａ１１０は、暗号化ストラテジ変化メッセージに続いて、ＴＬＳの完了（Finished）メッセージを通信装置Ｂ１２０に送信する。この完了メッセージは、鍵交換および認証処理が成功したことを通知するものである。

通信装置Ａ１１０からの完了メッセージに応答して、通信装置Ｂ１２０はＴＬＳの暗号化ストラテジ変化メッセージを通信装置Ａ１１０に送信する（５１７）。そして、通信装置Ｂ１２０はＴＬＳの完了メッセージを通信装置Ａ１１０に送信する。通信装置Ａ１１０は、これに対して、ＥＡＰプロトコルの応答を返信する（５１８）。

その後、通信装置Ａ１１０およびＢ１２０は、上述のようにして交換された乱数およびマスター鍵に基づいて、ＰＭＫ（Pairwise Master Key）をそれぞれ生成する（５２２）。そして、通信装置Ｂ１２０から通信装置Ａ１１０に対してＥＡＰプロトコルの成功を送信することにより（５１９）、ＥＡＰ−ＴＬＳ認証は終了する。

これに続いて、ＩＥＥＥ８０２．１１ｉにより定義された処理として、４−Ｗａｙハンドシェークが行われる（５２３）。この４−Ｗａｙハンドシェークは、ＥＡＰ−ＴＬＳ認証によって生成されたＰＭＫに基づいて、ＩＥＥＥ８０２．１１ｉとして必要な鍵を生成する処理である。この４−Ｗａｙハンドシェークは、通信装置Ｂ１２０によって起動される。

この図７の認証シーケンスは図６の認証シーケンス５１０に対応するものであり、図７の認証シーケンスの終了後は、通信装置Ａ１１０と通信装置Ｂ１２０との間で役割が交代した上で同様の認証シーケンス５３０が実行される。

図８は、本発明の第１の実施の形態における公開鍵証明書の受信時の処理手順例を示す図である。この処理は、図７の認証シーケンスにおいて、通信装置Ａ１１０が通信装置Ｂ１２０からサーバ証明メッセージにより公開鍵証明書を受信した際（５１５）、または、通信装置Ｂ１２０が通信装置Ａ１１０からクライアント証明メッセージにより公開鍵証明書を受信した際（５１６）に実行される。

まず、通信制御部１０１は、認証相手の公開鍵証明書から所有者情報６１６を取得する（ステップＳ９１１）。そして、その所有者情報６１６と一致するエントリがアクセス制御リスト１０７の識別情報７１２に存在する場合には（ステップＳ９１２）、その認証可否７１３において認証相手が認証可能になっているか否かが判断される（ステップＳ９１３）。認証相手が認証可能であれば、残りの認証シーケンスが継続される（ステップＳ９１４）。

一方、所有者情報６１６と一致するエントリがアクセス制御リスト１０７の識別情報７１２に存在しない場合（ステップＳ９１２）、もしくは、存在してもその認証可否７１３において認証相手が認証可能になっていない場合（ステップＳ９１３）には、認証に失敗したものとして、その認証シーケンスは中止される（ステップＳ９１５）。

（ｂ）メッシュ型の無線ＬＡＮシステムにおける処理
図９は、本発明の第１の実施の形態におけるメッシュ型無線ＬＡＮシステムの各通信装置間の相互認証手順例を示す図である。現在標準化が進められているＩＥＥＥ８０２．１１ｓにて提案されているメッシュ型無線ＬＡＮシステムでは、ＩＥＥＥ８０２．１Ｘの認証処理をＥＡＰ−ＴＬＳ認証方式により実現する場合、実際の認証処理に先立って実行されるスキャンフェーズにおいてサプリカントおよびオーセンティケータの役割について交渉が行われ、認証処理の前にその役割が決定していることを想定している。これにより、ＩＢＳＳ型無線ＬＡＮシステムのようにサプリカントとオーセンティケータおよび認証サーバとを入れ替えて２回に亘る認証処理を実行することは不要となっている。

この図９の認証シーケンスでは、図７の認証シーケンスとはデータの伝達方向が逆になる。すなわち、サプリカントとしての役割を有する通信装置Ａ１１０が、オーセンティケータおよび認証サーバとしての役割を有する通信装置Ｂ１２０に対して、ＩＥＥＥ８０２．１ＸのフレームボディにおいてＥＡＰプロトコルによって通信装置Ｂ１２０の識別情報を要求する（５５１）ことにより認証シーケンスが始まり、以降の手順においても全てのデータの伝達方向は逆になっている。

なお、この場合においても、（ｉ）サプリカントとして機能する通信装置Ａ１１０と、（ｉｉ）オーセンティケータおよび認証サーバとして機能する通信装置Ｂ１２０との双方において、上述の図８と同様の処理が実行されることとなる。なお、この際、サプリカント（通信装置Ａ１１０）においては図９のステップ５５５にてデータを受信した時点で図８の処理が実行され、オーセンティケータおよび認証サーバ（通信装置Ｂ１２０）においては図９のステップ５５６にてデータを受信した時点で図８の処理が実行されることとなる。

このように、本発明の第１の実施の形態によれば、各通信装置が認証相手の識別情報をそれぞれのアクセス制御リスト１０７に保持しておいて、相互認証の際に交換された公開鍵証明書の所有者情報と比較することにより、認証の許否を通信装置毎に個別に判断することができる。

（１−１）第１の実施の形態の変形例
次に、本発明の第１の実施の形態の変形例について説明する。

図１０は、本発明の第１の実施の形態における通信装置の変形例としての携帯電話端末２００の一構成例を示す図である。この携帯電話端末２００は、通信制御部２０１と、無線ネットワークインターフェース２０２と、無線通信設定データ保持部２０３と、近隣端末リスト２０４と、経路テーブル２０５と、電話帳２０８とを備え、無線アドホックネットワーク２９０を介して他の通信装置（携帯電話端末）と通信を行う。

この携帯電話端末２００は、携帯電話端末に無線ネットワークインターフェース２０２を搭載することによりＶｏＷＬＡＮ（Voice over Wireless LAN）を実現する。すなわち、無線アドホックネットワーク２９０を経由することにより、固定電話やＩＰ電話等と接続して通話することができる。また、屋外においては通常の携帯電話として利用することができる。このような携帯電話と固定電話の融合はＦＭＣ（Fixed Mobile Convergence）と呼ばれる。

この携帯電話端末２００において、通信制御部２０１、無線ネットワークインターフェース２０２、無線通信設定データ保持部２０３、近隣端末リスト２０４、および、経路テーブル２０５は、図１の通信装置１００の場合と同様の機能を有している。

電話帳２０８は、通話のための発信に用いられる電話番号を含む一覧である。この変形例では、図１の例のようにアクセス制御リスト１０７に予め識別情報の登録を明示的に行わない代わりに、電話帳２０８をアクセス制御リスト１０７として用いる。これにより、識別情報の明示的な登録を行うことなく、それまでに蓄積された電話帳を利用することで、相互認証の準備を簡略化するものである。すなわち、公開鍵証明書の所有者情報６１６の一般名６２４に所有者の電話番号を保持しておくことにより、相互認証の際に交換された公開鍵証明書に含まれる電話番号（一般名６２４）を電話帳２０８から検索することができる。

携帯電話の電話帳に相手の携帯電話端末の電話番号を登録する際には、通常の使用形態が適用可能である。例えば、相手の電話番号を口頭で尋ねてダイヤル入力して保存してもよく、また、相手の携帯電話端末に自分の携帯電話端末から発呼することによって自分の携帯電話番号を相手の携帯電話端末に登録してもらう等の方法がある。

図１１は、本変形例における電話帳２０８の一構成例を示す図である。この電話帳２０８の各エントリは、その項目として名前８２１、電話番号８２２および認証可否８２３の各フィールドを関連付けて保持している。

名前８２１は、そのエントリに該当する人物の名前である。この名前８２１は、姓（family name）および名（first name）の両者の組合せでもよく、また、何れか一方でもよい。また、その人物を特定できるものであれば愛称（nickname）などであってもよい。

電話番号８２２は、そのエントリに該当する人物の電話番号である。

認証可否８２３は、そのエントリに該当する人物の認証が可能であるか、または、その認証を拒否すべきであるかを示すフィールドである。

基本的に電話帳に登録されている知人は信頼できるものとして認証を許可するように登録されるが、無線ネットワークインターフェース２０２を介して接続を許可したくない相手については認証可否８２３を認証拒否にしておくことにより、認証の許否を制御することができる。

この変形例においても、ＥＡＰ−ＴＬＳ認証方式による相互認証は、図６または図９の認証シーケンスによって行われる。その際、認証シーケンスにおいて、一方の通信装置が他方の通信装置からサーバ証明メッセージにより公開鍵証明書を受信した際、または、一方の通信装置が他方の通信装置からクライアント証明メッセージにより公開鍵証明書を受信した際には、図８の場合と同様に、公開鍵証明書のチェックが行われる。

なお、公開鍵証明書は、携帯電話端末の出荷時に設定しておくことが可能である。そして、その公開鍵証明書の所有者情報６１６の一般名６２４にその携帯電話端末の電話番号を保持しておくことにより、相互認証時の認証許否の判断に用いることが可能となる。

図１２は、本変形例における公開鍵証明書の受信時の処理手順例を示す図である。

まず、通信制御部２０１は、認証相手の公開鍵証明書から所有者情報６１６を取得する（ステップＳ９２１）。そして、その所有者情報６１６に含まれる電話番号（一般名６２４）と一致するエントリが電話帳２０８の電話番号８２２に存在する場合には（ステップＳ９２２）、その認証可否８２３において認証相手が認証可能になっているか否かが判断される（ステップＳ９２３）。認証相手が認証可能であれば、残りの認証シーケンスが継続される（ステップＳ９２４）。

一方、その所有者情報６１６に含まれる電話番号と一致するエントリが電話帳２０８の電話番号８２２に存在しない場合（ステップＳ９２２）、もしくは、存在してもその認証可否８２３において認証相手が認証可能になっていない場合（ステップＳ９２３）には、認証に失敗したものとして、その認証シーケンスは中止される（ステップＳ９２５）。

このように、本発明の第１の実施の形態の変形例によれば、相互認証の際に交換された公開鍵証明書の所有者情報に含まれる電話番号と携帯電話端末の電話帳２０８に含まれる電話番号とを比較することにより、認証の許否を携帯電話端末毎に個別に判断することができる。

（２）第２の実施の形態
次に本発明の第２の実施の形態について説明する。

上述した第１の実施の形態において、通信装置Ａ１１０（または通信装置Ｂ１２０）は、以下の何れかの状況が発生した場合に認証処理に失敗したものとみなして、認証シーケンスを中止する構成となっていた。
（状況１）：アクセス制御リスト１０７に、そもそも、識別情報が格納されていない状況（図８ステップＳ９１２「Ｎｏ」）
（状況２）：アクセス制御リスト１０７の認証可否７１３に格納されたステータスが認証拒否になっている状況（図８ステップＳ９１３「Ｎｏ」）

ここで、これらの各状況はアクセス制御リスト１０７内の情報に基づいて発生するものだが、そもそも、このリスト１０７はユーザが真に通信相手として選択した相手とのみ、通信を行うようにして、個人情報の流出等を防止しようという趣旨から設けられたものである。したがって、ユーザが自己の判断により、認証相手の通信装置と通信を行いたいと考えた場合、アクセス制御リスト１０７に格納された情報を無視して、認証シーケンスを継続させたとしても何の問題も生じないばかりでなく、このような場合にまで強制的に認証シーケンスを中止してしまうとユーザの利便性を損ねてしまう可能性すらある。

そこで、本実施の形態においては、上記図８の処理において、認証シーケンスを強制的に終了する前の段階において、一度、ユーザの意思を確認し、ユーザが中止不要と判断した場合には認証シーケンスを継続させる機能を通信装置に設けることとした。

一方、かかる手法を採用した場合、ユーザが情報提示に気がつかない等の理由から、ユーザの選択を待つ間にＥＡＰ-ＴＬＳがタイムアウトしてしまう可能性がある。したがって、このような事態が発生した際における解決手法を事前に講じておくことが望ましい。なお、この際における、具体的な解決手法については任意であり、例えば、タイムアウト発生時に強制的に認証シーケンスを中止するようにしても良い。ただし、以下の説明においては、タイムアウト発生時、図７に示す認証シーケンスを再試行し、再度、ユーザに対する意思確認を行うものとして説明を行う。

かかる機能を実現するため、本実施の形態にかかる通信装置の通信制御部１０１が実行する、公開鍵証明書の受信時の処理手順例を図１３に示す。

なお、この処理は、（ａ）ＩＢＳＳ型の無線ＬＡＮシステムの場合、図７の認証シーケンスのステップ５１５、または、ステップ５１６にて実行されるものであり、（ｂ）メッシュ型の無線ＬＡＮシステムの場合、図９の認証シーケンスのステップ５５５、または、ステップ５５６にて実行されるものとなっている。また、この図１３においては、上記図８と同様の処理に同一のステップ番号を付している。

この図１３の処理において、通信制御部１０１は、まず、ステップＳ９１１の処理を実行し、認証相手の公開鍵証明書から得られた所有者情報６１６と一致するエントリがアクセス制御リスト１０７の識別情報７１２に存在し（ステップＳ９１２「ｙｅｓ」）、且つ、その認証可否７１３において認証相手が認証可能になっている場合（ステップＳ９１３「ｙｅｓ」）、残りの認証シーケンスを継続する（ステップＳ９１４）。

これに対して、上記状況（１）あるいは（２）に該当する場合（すなわち、ステップＳ９１２、あるいは、Ｓ９１３において「ｎｏ」と判定された場合）、通信制御部１０１は、認証シーケンスを継続させるか否かをユーザに選択させるための情報を出力する（ステップＳ９１１０）。なお、この際における情報の提示手法は任意であり、例えば、図示しない表示部に「認証に失敗しました。認証を継続しますか？」等のテキストと共に、その相手方通信端末に関する情報を表示させるようにしても良い。また、図示しないスピーカから音声を出力するようにしても良く、さらには、発光ダイオード等を点灯させて、その旨を提示するようにしても良い。

この提示後、所定の時間だけ、通信制御部１０１は、ユーザ入力を待機する状態となり（ステップＳ９１２０「ｎｏ」およびステップＳ９１３０「ｎｏ」）、ＥＡＰ−ＴＬＳがタイムアウトになると、ステップＳ９１３０にて「ｙｅｓ」と判定する。この結果、通信制御部１０１は認証シーケンスを一旦中止した後、図７の認証シーケンスを始めから、再試行するための処理を行い（ステップＳ９１４０）、処理を終了する。

一方、この情報提示に従い、ユーザが入力操作を行った場合、通信制御部１０１は、ステップＳ９１２０にて「ｙｅｓ」と判定し、当該入力操作が、認証を許可する旨の入力であったか否かを判定する（ステップＳ９１５０）。そして、ユーザ入力が認証を許可しない旨を示すものであった場合、通信制御部１０１は、ステップＳ９１５０にて「ｎｏ」と判定し、そのまま、処理を終了する。これに対して、ユーザが認証処理を許可する旨の入力操作を行った場合（ステップＳ９１５０「ｙｅｓ」）、通信制御部１０１は、当該通信相手に対応するアクセス制御リスト１０７の認証可否フィールド７１３に、「認証許可」を示す情報（例えば、フラグ）を格納して（ステップ９１６０）、処理をステップＳ９１４に進める。この結果、システム内において認証シーケンスが継続されることとなる。

また、このユーザの判断を仰ぐ手法は、図８の処理のみならず、上記図１２の処理に対しても同様に適用可能である。図１２の処理においてユーザの判断を仰ぐ場合の処理例を図１４に示す。なお、この図１４において、上記図１２と同様の処理に関しては、同様の符号を付してある。

図１４に示すように、この処理例の場合、ステップＳ９２２あるいはＳ９２３の何れかにおいて「ｎｏ」と判断されると、通信制御部２０１は、上記図１３のステップＳ９１１０と同様にユーザの意思確認のための情報をユーザに提示する（ステップＳ９２１０）。そして、通信制御部１０１は、所定時間、ユーザ入力を待機し（ステップＳ９２２０「ｎｏ」及びステップＳ９２３０「ｎｏ」）、ＥＡＰ−ＴＬＳがタイムアウトになった時点でステップＳ９２３０にて「ｙｅｓ」と判定する。この結果、通信制御部１０１は認証シーケンスを一旦中止した後、認証シーケンスを再試行するための処理を行い（ステップＳ９２４０）、処理を終了する。

一方、ユーザが入力操作を行った場合、通信制御部１０１は、ステップＳ９２２０にて「ｙｅｓ」と判定し、ステップＳ９２５０の処理を実行する。そして、例えば、ユーザが、認証を中止する旨の入力操作を行っていた場合（ステップＳ９２５０「ｎｏ」）、通信制御部２０１は、そのまま、認証シーケンスを終了させるのに対し、認証を許可する旨の入力操作を行った場合（ステップＳ９２５０「ｙｅｓ」）、通信制御部２０１は、当該通信相手に対応する電話帳２０８の認証可否フィールド７１３内に「認証許可」を示す情報（例えば、フラグ）を格納して（ステップ９２６０）、処理をステップＳ９２４に進める。この結果、システム内において、認証シーケンスが継続されることとなる。

このように、本発明の第２の実施の形態によれば、通信装置内のアクセス制御リスト、あるいは、電話帳内に格納された情報により、認証処理を継続する必要性が無い場合であっても、ユーザの意思に基づき認証シーケンスを継続させることが可能であるため、よりユーザフレンドリな認証処理を実現することが可能となる。

なお、本発明の第１および第２の実施の形態は本発明を具現化するための一例を示したものであり、以下に示すように特許請求の範囲における発明特定事項とそれぞれ対応関係を有するが、これに限定されるものではなく本発明の要旨を逸脱しない範囲において種々の変形を施すことができる。

すなわち、請求項１および２において、識別情報取得手段は例えば無線ネットワークインターフェース１０２または２０２に対応する。また、識別情報保持手段は例えばアクセス制御リスト１０７または電話帳２０８に対応する。また、認証手段は例えば通信制御部１０１または２０１に対応する。

また、請求項３において、認証可否情報は例えば認証可否７１３または８２３に対応する。

また、請求項５において、公開鍵証明書は例えばＸ．５０９フォーマットの公開鍵証明書６１０に対応する。

また、請求項６において、識別情報保持手段に保持される電話番号は例えば電話番号８２２に対応する。

また、請求項７または８において、識別情報取得手順は例えば手順３１１または３２１に対応する。また、識別情報保持手順は例えば手順３１２または３２２に対応する。また、認証手順は例えばステップＳ９１１乃至Ｓ９１５またはＳ９２１乃至Ｓ９２５に対応する。

なお、本発明の第１および第２の実施の形態において説明した処理手順は、これら一連の手順を有する方法として捉えてもよく、また、これら一連の手順をコンピュータに実行させるためのプログラム乃至そのプログラムを記憶する記録媒体として捉えてもよい。

本発明の第１の実施の形態における通信装置１００の一構成例を示す図である。 本発明の第１の実施の形態で利用される公開鍵証明書６１０の構成を示す図である。 本発明の第１の実施の形態におけるアクセス制御リスト１０７の一構成例を示す図である。 、本発明の第１の実施の形態における無線通信システムの各通信装置の識別情報の登録の様子を示す図である。 本発明の第１の実施の形態における無線通信システムの各通信装置間の識別情報の登録手順例を示す図である。 本発明の第１の実施の形態におけるＩＢＳＳ型無線ＬＡＮシステムの各通信装置間の相互認証手順例を示す図である。 本発明の第１の実施の形態におけるＩＢＳＳ型無線ＬＡＮシステムの認証シーケンス（５１０）の手順例を示す図である。 本発明の第１の実施の形態における公開鍵証明書の受信時の処理手順例を示す図である。 本発明の第１の実施の形態におけるメッシュ型無線ＬＡＮシステムの各通信装置間の相互認証手順例を示す図である。 本発明の第１の実施の形態における通信装置の変形例としての携帯電話端末２００の一構成例を示す図である。 本発明の第１の実施の形態の変形例における電話帳２０８の一構成例を示す図である。 本発明の第１の実施の形態の変形例における公開鍵証明書の受信時の処理手順例を示す図である。 本発明の第２の実施の形態における公開鍵証明書の受信時の処理手順例を示す図である。 本発明の第２の実施の形態の変形例における公開鍵証明書の受信時の処理手順例を示す図である。

符号の説明

１００、１１０、１２０ 通信装置
１０１、２０１ 通信制御部
１０２、２０２ 無線ネットワークインターフェース
１０３、２０３ 無線通信設定データ保持部
１０４、２０４ 近隣端末リスト
１０５、２０５ 経路テーブル
１０７、１１７、１２７ アクセス制御リスト
１０９、１１９、１２９ 同期ボタン
１９０、２９０ 無線アドホックネットワーク
２００ 携帯電話端末
２０８ 電話帳

Claims (8)

1. 複数の無線通信装置が自律分散してネットワークを形成する無線通信システムにおいて、
   前記複数の無線通信装置の各々は、
   所定の条件を満たす他の無線通信装置から当該他の無線通信装置の識別情報を取得する識別情報取得手段と、
   前記取得された他の無線通信装置の識別情報を保持する識別情報保持手段と、
   前記他の無線通信装置の認証を行う際に前記他の無線通信装置の証明書における識別情報が前記識別情報保持手段に保持されていることを条件として前記認証を継続する認証手段とを具備する
   無線通信システム。
2. 複数の無線通信装置が自律分散してネットワークを形成する無線通信システムにおける無線通信装置であって、
   所定の条件を満たす他の無線通信装置から当該他の無線通信装置の識別情報を取得する識別情報取得手段と、
   前記取得された他の無線通信装置の識別情報を保持する識別情報保持手段と、
   前記他の無線通信装置の認証を行う際に前記他の無線通信装置の証明書における識別情報が前記識別情報保持手段に保持されていることを条件として前記認証を継続する認証手段と
   を具備する無線通信装置。
3. 前記識別情報保持手段は、前記取得された他の無線通信装置の識別情報に関連付けて前記他の無線通信装置の認証可否に関する情報を認証可否情報として保持し、
   前記認証手段は、前記他の無線通信装置の認証を行う際に前記他の無線通信装置の証明書における識別情報と前記識別情報保持手段に保持された識別情報とが一致し且つ前記認証可否情報が認証可能である旨を示していることを条件として前記認証を継続する
   請求項２記載の無線通信装置。
4. 前記認証手段は、前記認証可否情報が認証を認めない旨を示す情報の場合であっても、ユーザに対して認証継続の可否判断を促すための情報を提示した後、認証を継続する旨の入力がなされると、前記条件に合致するか否かを問わず前記認証を継続する請求項３記載の無線通信装置。
5. 前記識別情報保持手段に保持される前記他の無線通信装置の識別情報は当該他の無線通信装置の装置名を含み、
   前記他の無線通信装置の証明書は前記他の無線通信装置の公開鍵証明書であって、前記証明書における識別情報は前記他の無線通信装置の装置名を含む
   請求項２記載の無線通信装置。
6. 前記識別情報保持手段に保持される前記他の無線通信装置の識別情報は当該他の無線通信装置の電話番号を含み、前記証明書における識別情報は当該他の無線通信装置の電話番号を含む
   請求項２記載の無線通信装置。
7. 複数の無線通信装置が自律分散してネットワークを形成する無線通信システムにおいて他の無線通信装置の識別情報を保持する識別情報保持手段を備える無線通信装置の認証方法であって、
   所定の条件を満たす他の無線通信装置から当該他の無線通信装置の識別情報を取得する識別情報取得手順と、
   前記取得された他の無線通信装置の識別情報を前記識別情報保持手段に保持させる識別情報保持手順と、
   前記他の無線通信装置の認証を行う際に前記他の無線通信装置の証明書における識別情報が前記識別情報保持手段に保持されていることを条件として前記認証を継続する認証手順と
   を具備する無線通信装置の認証方法。
8. 複数の無線通信装置が自律分散してネットワークを形成する無線通信システムにおいて他の無線通信装置の識別情報を保持する識別情報保持手段を備える無線通信装置上で動作するプログラムであって、
   所定の条件を満たす他の無線通信装置から当該他の無線通信装置の識別情報を取得する識別情報取得手順と、
   前記取得された他の無線通信装置の識別情報を前記識別情報保持手段に保持させる識別情報保持手順と、
   前記他の無線通信装置の認証を行う際に前記他の無線通信装置の証明書における識別情報が前記識別情報保持手段に保持されていることを条件として前記認証を継続する認証手順と
   をコンピュータに実行させるプログラム。

Images