JP4631281B2 - 無線アドホック通信システム、端末、その端末における属性証明書発行提案方法及び属性証明書発行依頼方法並びにそれらの方法を端末に実行させるためのプログラム - Google Patents

Description

本発明は、無線アドホック通信システムに関し、特に端末権限認証証明書を用いてネットワークへのアクセス権限を認証させる無線アドホック通信システム、当該システムにおける端末、および、これらにおける処理方法ならびに当該方法をコンピュータ（端末）に実行させるプログラムに関する。

電子機器の小型化、高性能化が進み、簡単に持ち運び利用することが可能となったことから、必要になったその場で端末をネットワークに接続し、通信を可能とする環境が求められている。その一つとして、必要に応じて一時的に構築されるネットワーク、すなわち無線アドホックネットワーク技術の開発が進められている。この無線アドホックネットワークでは、特定のアクセスポイントを設けることなく、各端末（例えば、コンピュータ、携帯情報端末（ＰＤＡ：Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｃｅ）、携帯電話等）が自律分散して相互に接続される。

一般に、あるネットワーク資源に対して接続する権限を有しない機器がアクセスすることを防ぐために、端末権限認証証明書を利用した権限管理が行われている。この端末権限認証証明書の一例として、属性証明書が２０００年３月にＸ．５０９バージョン３により新たに定義され、２００２年４月より標準化過程の仕様書（Ｓｔａｎｄａｒｄ Ｔｒａｃｋ ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ））としてプロファイル（属性証明書に含まれるデータフィールドの内容の定義）がまとめられている。属性証明書をネットワーク資源へのアクセス許可証として利用することにより、ネットワーク資源に接続する権限を確認し、接続資格を保有している端末だけに接続を許可することができる。なお、本明細書では、端末権限認証証明書の一例として属性証明書について説明するが、例えば、ＸＭＬ言語等により端末権限を記述しておき、権限を有する機関がそれに署名を付することにより作成されたようなものであっても本発明における端末権限認証証明書として機能し得る。

従来の通信システムにおいては、認証に用いられるデータはネットワーク上の特定の装置において集中管理されている。例えば、一つの公開鍵管理装置を複数の無線通信交換システムにより共有し、ある無線通信交換システムのサービスエリアに移動端末が移動すると公開鍵管理装置にその移動端末の公開鍵を要求する技術が提案されている（例えば、特許文献１参照。）。
特開平１０−１１２８８３号公報（図１）

従来の通信システムでは認証に用いられるデータは集中管理されているが、無線アドホック通信システムにおいては端末は常に移動し、その時々によってネットワークを構成する端末が異なり、そのような集中管理を行う装置が常に存在するとは限らない。また、無線媒体の性質上、そのような集中管理を行う装置への通信路が常に確保されているとは限らないため、集中管理に適さない。

そこで、本発明の目的は、無線アドホック通信システムにおいて、端末権限認証証明書の発行を自律分散して行うことにある。特に、本発明は、ネットワークを構成する全ての無線端末が管理情報（例えば、ビーコン等）を送信する無線ネットワークにおいて有用である。

上記課題を解決するために本発明の請求項１記載の無線アドホック通信システムは、複数の端末により構成される無線アドホック通信システムであって、端末権限認証証明書を有しない旨を示すビーコン情報を含む信号を送信する第１の端末と、上記信号に応答して、端末権限認証証明書発行依頼メッセージを送信するように上記第１の端末に対して端末権限認証証明書発行提案メッセージを送信する第２の端末とを具備する。これにより、第１の端末からの信号をトリガーとして第２の端末との間で端末権限認証証明書の発行処理を展開させるという作用をもたらす。

また、本発明の請求項２記載の端末は、ビーコン情報を含む信号を受信するための受信手段と、この受信手段が他の端末から所定のビーコン情報を含む信号を受信すると端末権限認証証明書発行メッセージを送信するように当該他の端末に対して端末権限認証証明書発行提案メッセージを送信する端末権限認証証明書発行提案手段とを具備する。これにより、ビーコン情報を含む信号をトリガーとして端末権限認証証明書の発行処理を展開させるという作用をもたらす。

また、本発明の請求項３記載の端末は、請求項２記載の端末において、上記受信手段が受信した上記他の端末からの上記信号より当該他の端末の端末識別情報を取得する手段をさらに具備し、上記端末権限認証証明書発行提案手段が上記端末識別情報に基づいて上記提案メッセージを送信する。これにより、端末権限認証証明書発行依頼を提案すべき端末を確認した上で提案を行わせるという作用をもたらす。

また、本発明の請求項４記載の端末は、請求項２記載の端末において、上記端末権限認証証明書発行提案手段が上記他の端末に対して上記端末権限認証証明書発行依頼メッセージの送信を提案する際に上記端末の公開鍵証明書を併せて提示するものである。これにより、端末権限認証証明書発行依頼の提案をした端末の本人性を、ビーコン情報を含む信号の送信端末に確認させるという作用をもたらす。

また、本発明の請求項５記載の端末は、ビーコン情報を含む信号を受信する受信手段と、この受信手段が他の端末から所定のビーコン情報を含む信号を受信すると当該他の端末を所有者とする端末権限認証証明書を発行して当該端末権限認証証明書を含む端末権限認証証明書発行提案メッセージを当該他の端末に対して送信する端末権限認証証明書発行提案手段とを具備する。これにより、ビーコン情報を含む信号をトリガーとして、端末権限認証証明書発行依頼に先立って端末権限認証証明書を発行させるという作用をもたらす。

また、本発明の請求項６記載の端末は、請求項５記載の端末において、上記受信手段が受信した上記他の端末からの上記信号より当該他の端末の端末識別情報を取得する手段をさらに具備し、上記端末権限認証証明書発行提案手段は、上記端末識別情報に基づいて上記端末権限認証証明書発行提案メッセージを送信する。これにより、端末権限認証証明書発行依頼を提案すべき端末を確認した上で端末権限認証証明書の受領を行わせるという作用をもたらす。

また、本発明の請求項７記載の端末は、請求項５記載の端末において、上記端末権限認証証明書発行提案手段が、上記他の端末に対して上記端末権限認証証明書発行提案メッセージを送信する際に上記端末の公開鍵証明書を併せて提示するものである。これにより、端末権限認証証明書発行の提案をした端末の本人性を、ビーコン情報を含む信号の送信端末に確認させるという作用をもたらす。

また、本発明の請求項８記載の端末は、ビーコン情報を含む信号を受信するための受信手段と、この受信手段が他の端末からビーコン情報を含む信号を受信した場合において当該他の端末が端末権限認証証明書を有する旨を上記信号が示していなければ端末権限認証証明書発行依頼メッセージを送信するように当該他の端末に対して端末権限認証証明書発行提案メッセージを送信する端末権限認証証明書発行提案手段とを具備する。これにより、ビーコン情報を含む信号の送信端末が端末権限認証証明書を有していない場合に当該信号をトリガーとして端末権限認証証明書の発行処理を展開させるという作用をもたらす。

また、本発明の請求項９記載の端末は、請求項８記載の端末において、上記受信手段が受信した上記他の端末からの上記信号より当該他の端末の端末識別情報を取得する手段をさらに具備し、上記端末権限認証証明書発行提案手段は上記端末識別情報に基づいて上記提案メッセージを送信するものである。これにより、端末権限認証証明書発行依頼を提案すべき端末を確認した上で提案を行わせるという作用をもたらす。

また、本発明の請求項１０記載の端末は、請求項８記載の端末において、上記端末権限認証証明書発行提案手段が、上記他の端末に対して上記端末権限認証証明書発行依頼メッセージの送信を提案する際に上記端末の公開鍵証明書を併せて提示する。これにより、端末権限認証証明書発行依頼の提案をした端末の本人性を、ビーコン情報を含む信号の送信端末に確認させるという作用をもたらす。

また、本発明の請求項１１記載の端末は、請求項１０記載の端末において、上記端末権限認証証明書発行依頼メッセージを受信するための端末権限認証証明書発行依頼受信手段と、この端末権限認証証明書発行依頼受信手段が上記他の端末から上記端末権限認証証明書発行依頼メッセージを受信すると当該他の端末に関する情報を表示して確認を促す確認手段と、上記確認がなされた場合には上記他の端末に対して端末権限認証証明書を発行し、上記確認が拒否された場合には上記他の端末に対して端末権限認証証明書発行依頼の拒否を通知する端末権限認証証明書発行依頼拒否メッセージを送信する端末権限認証証明書発行手段とをさらに具備する。これにより、端末権限認証証明書発行依頼端末を確認した上で端末権限認証証明書を発行させるという作用をもたらす。

また、本発明の請求項１２記載の端末は、請求項１１記載の端末において、端末権限認証証明書発行端末の公開鍵証明書を保持する端末権限認証証明書発行端末リストテーブルをさらに具備し、上記端末権限認証証明書発行手段が、上記端末権限認証証明書の発行に際して上記端末権限認証証明書発行端末リストテーブルに保持された上記端末権限認証証明書発行端末の公開鍵証明書を上記他の端末に送信する。これにより、他の端末における端末権限認証証明書の検証を容易にするという作用をもたらす。

また、本発明の請求項１３記載の端末は、請求項１１記載の端末において、端末権限認証証明書の失効リストを保持する端末権限認証証明書失効リストテーブルをさらに具備し、上記端末権限認証証明書発行手段が、上記端末権限認証証明書の発行に際して上記端末権限認証証明書失効リストテーブルに保持された上記端末権限認証証明書失効リストを上記他の端末に送信する。これにより、他の端末において端末権限認証証明書の検証を行う際に失効している端末権限認証証明書を排除させるという作用をもたらす。

また、本発明の請求項１４記載の端末は、ビーコン情報を含む信号を受信するための受信手段と、この受信手段が他の端末からビーコン情報を含む信号を受信した場合において当該他の端末が端末権限認証証明書を有する旨を上記信号が示していなければ当該他の端末を所有者とする端末権限認証証明書を発行して当該端末権限認証証明書を含む端末権限認証証明書発行提案メッセージを当該他の端末に対して送信する端末権限認証証明書発行提案手段とを具備する。これにより、ビーコン情報を含む信号の送信端末が端末権限認証証明書を有していない場合に、当該信号をトリガーとして、端末権限認証証明書発行依頼に先立って端末権限認証証明書を発行させるという作用をもたらす。

また、本発明の請求項１５記載の端末は、請求項１４記載の端末において、上記受信手段が受信した上記他の端末からの上記信号より当該他の端末の端末識別情報を取得する手段をさらに具備し、上記端末権限認証証明書発行提案手段が上記端末識別情報に基づいて上記端末権限認証証明書発行提案メッセージを送信するものである。これにより、端末権限認証証明書発行依頼を提案すべき端末を確認した上で端末権限認証証明書の受領を行わせるという作用をもたらす。

また、本発明の請求項１６記載の端末は、請求項１４記載の端末において、上記端末権限認証証明書発行提案手段が、上記他の端末に対して上記端末権限認証証明書発行提案メッセージを送信する際に上記端末の公開鍵証明書を併せて提示するものである。これにより、端末権限認証証明書発行の提案をした端末の本人性を、ビーコン情報を含む信号の送信端末に確認させるという作用をもたらす。

また、本発明の請求項１７記載の端末権限認証証明書発行提案方法は、ビーコン情報を含む信号を受信する手順と、上記信号の送信元端末が端末権限認証証明書を有する旨を上記信号が示していなければ端末権限認証証明書発行依頼メッセージを送信するように上記送信元端末に対して端末権限認証証明書発行提案メッセージを送信する手順とを具備する。これにより、ビーコン情報を含む信号の送信端末が端末権限認証証明書を有していない場合に当該信号をトリガーとして端末権限認証証明書の発行処理を展開させるという作用をもたらす。

また、本発明の請求項１８記載の端末権限認証証明書発行提案方法は、請求項１７記載の端末権限認証証明書発行提案方法において、上記他の端末からの上記信号より当該他の端末の端末識別情報を取得する手順をさらに具備し、上記端末識別情報に基づいて上記提案メッセージを送信するものである。これにより、端末権限認証証明書発行依頼を提案すべき端末を確認した上で提案を行わせるという作用をもたらす。

また、本発明の請求項１９記載の端末権限認証証明書発行提案方法は、ビーコン情報を含む信号を受信する手順と、上記信号の送信元端末が端末権限認証証明書を有する旨を上記信号が示していなければ当該送信元端末を所有者とする端末権限認証証明書を発行して当該端末権限認証証明書を含む端末権限認証証明書発行提案メッセージを当該送信元端末に対して送信する手順とを具備する。これにより、ビーコン情報を含む信号の送信端末が端末権限認証証明書を有していない場合に、当該信号をトリガーとして、端末権限認証証明書発行依頼に先立って端末権限認証証明書を発行させるという作用をもたらす。

本発明によれば、無線アドホック通信システムにおいて、端末権限認証証明書の発行を自律分散して行うことができるという優れた効果を奏し得る。

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

図１は、本発明の実施の形態における無線アドホック通信システムにおいて使用される無線端末３００の構成例を示す図である。無線端末３００は、通信処理部３２０と、制御部３３０と、表示部３４０と、操作部３５０と、スピーカ３６０と、マイク３７０と、メモリ６００とを備え、これらの間をバス３８０が接続する構成となっている。また、通信処理部３２０にはアンテナ３１０が接続されている。通信処理部３２０は、アンテナ３１０を介して受信した信号からネットワークインターフェース層（データリンク層）のフレームを構成する。また、通信処理部３２０は、ネットワークインターフェース層のフレームをアンテナ３１０を介して送信する。

制御部３３０は、無線端末３００全体を制御する。例えば、通信処理部３２０により構成されたフレームを参照して所定の処理を行う。表示部３４０は、所定の情報を表示するものであり、例えば、液晶ディスプレイ等が用いられ得る。操作部３５０は、無線端末３００に対して外部から操作指示を行うためのものであり、例えば、キーボードやボタンスイッチ等が用いられ得る。スピーカ３６０は、音声を出力するものであり、無線端末３００の利用者に対して注意を喚起したり他の端末と音声情報のやりとりを行うために用いられる。マイク３７０は、無線端末３００に対して外部から音声入力を行うものであり、他の端末と音声情報のやりとりを行ったり操作指示を行うために用いられる。

メモリ６００は、属性証明書の発行端末に関する情報を保持する属性証明書発行端末リストテーブル６１０と、無線端末３００自身のアクセス権限を示す属性証明書を保持する属性証明書テーブル６２０と、失効した属性証明書に関する情報を保持する属性証明書失効リストテーブル６３０と、無線端末３００自身の生成鍵に関する情報として公開鍵と秘密鍵と公開鍵証明書とを保持する生成鍵テーブル６５０とを格納する。

図２は、本発明の実施の形態における属性証明書発行端末リストテーブル６１０の構成例である。この属性証明書発行端末リストテーブル６１０は、過去に属性証明書を発行した実績のある端末に関する情報を保持するものであり、属性証明書発行端末の端末識別子６１１のそれぞれに対応して、公開鍵証明書６１２を保持している。端末識別子６１１は、ネットワーク内において端末を一意に識別するものであればよく、例えば、イーサネット（登録商標）におけるＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス等を用いることができる。公開鍵証明書６１２は、対応する端末識別子６１１により識別される端末の公開鍵証明書である。公開鍵証明書とは、証明書所有者（サブジェクト）の本人性を証明するものであり、証明書所有者の公開鍵を含む。この公開鍵証明書は証明書発行者たる認証局（ＣＡ：Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）によって署名される。

図３は、属性証明書発行端末リストテーブル６１０に保持される公開鍵証明書６１２のフォーマット７１０を示す図である。この公開鍵証明書のフォーマット７１０は、大きく分けて、署名前証明書７１１と、署名アルゴリズム７１８と、署名７１９とから構成される。署名前証明書７１１は、シリアル番号７１２と、発行者７１４と、有効期限７１５と、所有者７１６と、所有者７１６と、所有者公開鍵７１７とを含む。

シリアル番号７１２は、公開鍵証明書のシリアル番号であり、認証局によって採番される。発行者７１４は、公開鍵証明書の発行者たる認証局の名前である。この発行者７１４とシリアル番号７１２とにより公開鍵証明書は一意に識別される。有効期限７１５は、公開鍵証明書の有効期限である。所有者７１６は、公開鍵証明書の所有者の名前である。所有者公開鍵７１７は、所有者７１６の公開鍵である。

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

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

図４は、属性証明書テーブル６２０に保持される属性証明書のフォーマット７２０を示す図である。この属性証明書は、大きく分けて、属性証明情報７２１と、署名アルゴリズム７２８と、署名７２９とから構成される。属性証明情報７２１は、所有者公開鍵証明書識別子７２３と、発行者７２４と、シリアル番号７２２と、有効期限７２５とを含む。

所有者公開鍵証明書識別子７２３は、属性証明書の所有者の公開鍵証明書を識別するためのものである。具体的には、公開鍵証明書７１０（図３）の発行者７１４とシリアル番号７１２とにより識別する。なお、この公開鍵証明書識別子７２３は、所有者を識別する機能を有するものであればよく、例えば、所有者のＭＡＣアドレスなどを利用するようにしてもよい。発行者７２４は、属性証明書の発行者たる属性認証局（ＡＡ：Ａｔｔｒｉｂｕｔｅ ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）の名称であり、例えば、発行者のＭＡＣアドレスなどを利用することができる。シリアル番号７２２は、属性証明書のシリアル番号であり、属性証明書の発行者たる属性認証局によって採番される。このシリアル番号７２２と発行者７２４とにより属性証明書は一意に識別される。有効期限７２５は、属性証明書の有効期限である。

署名７２９は属性証明書に対する属性認証局による署名であり、署名アルゴリズム７２８はこの署名７２９のために使用された署名アルゴリズムである。署名アルゴリズムの内容については、前述の公開鍵証明書の署名アルゴリズム７１８と同様であり、属性証明情報７２１のメッセージダイジェストを属性認証局の秘密鍵により暗号化したものが署名７２９となる。

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

図５は、本発明の実施の形態における属性証明書失効リストテーブル６３０の構成例である。この属性証明書失効リストテーブル６３０は、失効した属性証明書に関する情報を保持するものであり、失効した属性証明書の属性証明書識別子６３１と、その失効した失効時刻６３２との対を保持している。端末を紛失した場合や盗難に遭った場合等に属性証明書を強制的に失効させるために、属性証明書失効リスト（ＡＲＬ：Ａｔｔｒｉｂｕｔｅ ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）が発行される。属性証明書識別子６３１と失効時刻６３２との対は、属性証明書失効リストの各失効リストエントリから抽出されて保持される。属性証明書識別子６３１は、失効した属性証明書を識別するためのものであり、具体的には、属性証明書７２０（図４）の発行者７２４とシリアル番号７２２とにより識別する。

図６は、属性証明書失効リスト７３０のフォーマットを示す図である。この属性証明書失効リストは、大きく分けて、署名前失効リスト７３１と、署名アルゴリズム７３８と、署名７３９とから構成される。署名前失効リスト７３１は、署名前失効リストの発行者７３４と、０個以上の失効リストエントリ７３５とを含む。失効リストエントリ７３５は、失効した属性証明書の属性証明書識別子７３６と、その失効した失効時刻７３７との対である。この失効リストエントリ７３５における属性証明書識別子７３６と失効時刻７３７との対が、属性証明書失効リストテーブル６３０（図５）における属性証明書識別子６３１と失効時刻６３２との対に該当する。

署名７３９は属性証明書失効リストに対する発行者による署名であり、署名アルゴリズム７３８はこの署名７３９のために使用された署名アルゴリズムである。署名アルゴリズムの内容については、前述の公開鍵証明書の署名アルゴリズム７１８と同様であり、署名前失効リスト７３１のメッセージダイジェストを発行者の秘密鍵により暗号化したものが署名７３９となる。

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

なお、無線アドホック通信システムにおいては、属性証明書失効リストを集中管理する固定サーバの存在を仮定することは困難であるため、ネットワークを構成する全ての端末が属性証明書失効リストを発行し得るものとする。属性証明書失効リストを発行した端末は、他の端末に属性証明書失効リストをブロードキャスト配布することにより、他の端末においても属性証明書の有効性を検証することができる。また、ネットワークに再接続した際に、各端末が属性証明書失効リストを相互に交換し、属性証明書失効リストテーブル６３０を併合することにより最新の状態を維持する。なお、属性証明書失効リスト発行の際には、発行者を容易に認証できるよう、公開鍵証明書および属性証明書を添付することが望ましい。

次に本発明の実施の形態における無線アドホック通信システムの動作について図面を参照して説明する。本発明の実施の形態では、端末がネットワーク資源に接続するためには、端末が属性証明書の発行を受ける「初期登録」の手順（図７または図１５）と、端末が属性証明書を用いて認証を行う「相互認証」の手順（図１８）とを踏むこととしている。これら図７、図１５および図１８における各処理は、無線端末３００における制御部３３０により実現される。

図７は、本発明の実施の形態における初期登録の手順の第１の実施例を示す図である。ここで、端末Ａ（１００）は既にネットワークに参入している属性証明書発行端末であり、端末Ｂ（２００）は新規にネットワークに参入しようとしている端末である。

無線アドホック通信システムにおける各端末は、他の端末に自己の存在を知らせるために定期的にビーコンを送信する。本発明の実施の形態において、ビーコンは、標識信号としてのビーコン情報のみを含む信号だけではなく、ビーコン情報に何らかのデータ情報が付加された信号をも含む。この図７の例では、端末Ｂが送信（２０１）したビーコン２０１１を端末Ａが受信し（１０１）、端末Ａが送信（１０２）したビーコン１０２２を端末Ｂが受信している（２０２）。これにより、端末Ａおよび端末Ｂは、以下のようなビーコンのフレーム構成により、互いの端末識別子を把握する。

これらビーコン２０１１および１０２２のフレーム構成は図８の通りである。ビーコンフレーム８１０は、ヘッダ部８１１と、ペイロード部８１２とから構成される。また、ヘッダ部８１１は、始点端末識別子８１３と、終点端末識別子８１４と、送信端末識別子８１５と、受信端末識別子８１６と、フレーム種別８１７と、属性証明書の有無８１８とを含む。始点端末識別子８１３は、このフレームを最初に発信した端末の端末識別子である。なお、端末識別子は、前述のようにネットワーク内において端末を一意に識別するものであればよく、例えば、イーサネット（登録商標）におけるＭＡＣアドレス等を用いることができる。終点端末識別子８１４は、このフレームの最終宛先の端末の端末識別子である。ビーコンフレーム８１０では、この終点端末識別子８１４にはブロードキャストアドレス（例えば、全てのビットに１）が設定される。

送信端末識別子８１５および受信端末識別子８１６は、フレームを中継する際に用いられる。無線アドホック通信システムにおいては、ネットワーク内の全ての端末が直接通信できるとは限らず、電波の届かない端末へフレームを送信したい場合には他の端末を介してマルチホップにより通信経路を確立しなければならない。この場合にフレームの送受信を行う端末間で使用されるのが送信端末識別子８１５および受信端末識別子８１６である。

フレーム種別８１７は、フレームの種別を示すものであり、ここでは、ビーコンフレームであることを示す。属性証明書の有無８１８は、ネットワーク資源にアクセスする権限を示す属性証明書をビーコンフレームの送信元端末が有しているか否かを示すものである。図７の初期登録シーケンスでは、端末Ｂは属性証明書を有していないため、この属性証明書の有無８１８には「有していない」旨が示される。なお、このビーコンフレームの一例では、ペイロード部８１２のデータ８１９には他の情報は含まれない。

端末Ａは、端末Ｂから送信されたビーコン２０１１を受信（１０１）すると、ビーコンフレーム８１０の始点端末識別子８１４および属性証明書の有無８１８をチェックする。始点端末である端末Ｂが属性証明書を有していないと判断すると、端末Ａは属性証明書発行依頼をするよう端末Ｂに対して提案する属性証明書発行提案メッセージ１０３２を送信（１０３）する。なお、ここでは属性証明書発行提案メッセージを自動送信することを想定してビーコンに示される属性証明書の有無を検証しているが、端末Ａはこの属性証明書の有無をチェックせずに任意のタイミングで端末Ｂに対して属性証明書発行提案メッセージを作成し、送信するようにしてもよい。

この属性証明書発行提案メッセージ１０３２のフレーム構成は図９の通りである。属性証明書発行提案フレーム８２０は、ヘッダ部８２１と、ペイロード部８２２とから構成される。ヘッダ部８２１は、始点端末識別子８２３と、終点端末識別子８２４と、送信端末識別子８２５と、受信端末識別子８２６と、フレーム種別８２７とを含む。これらヘッダ部８２１内の内容については、図８により説明したビーコンフレーム８１０と同様である。また、この属性証明書発行提案フレーム８２０では、ペイロード部８２２のデータ８２９として、送信元である端末Ａの公開鍵証明書８２９１が含まれる。この端末Ａの公開鍵証明書８２９１は、端末Ａの生成鍵テーブル６５０に予め格納されているものである。なお、データ８２９としては、公開鍵証明書８２９１の他に端末識別子等を含んでもよい。

端末Ｂは、端末Ａから送信された属性証明書発行提案メッセージ１０３２を受信すると、その内容から端末Ａを確認（２０３）する。例えば、属性証明書発行提案フレーム８２０の始点端末識別子８２３（図９）や公開鍵証明書８２９１における公開鍵の所有者７１６（図３）を表示部３４０（図１）に表示することにより、正しい属性証明書発行端末であるか否かの判断をユーザに促す。これにより、アドレス偽造等による悪意のある端末や意図しない端末の介入を防ぐことができる。送信元の端末Ａが信頼する端末であり且つ端末Ａに属性証明書を発行してもらうことを意図する場合には、ユーザは操作部３５０（図１）により確認操作を行う。

ユーザの確認（２０３）により提案が受諾されると、端末Ｂは属性証明書発行を依頼する属性証明書発行依頼メッセージ２０４１を端末Ａに送信（２０４）する。この属性証明書発行依頼メッセージ２０４１のフレーム構成は図９の通りであり、属性証明書発行提案メッセージ１０３２のフレーム８２０と同様である。ペイロード部８３２のデータ８３９として送信元である端末Ｂの公開鍵証明書８３９１が含まれる点も同様である。

なお、ユーザの確認（２０３）により提案が拒否された場合には、端末Ｂは属性証明書発行提案の拒否を通知する属性証明書発行提案拒否メッセージを端末Ａに送信するようにしてもよい。この属性証明書発行提案拒否メッセージのフレーム構成は図１０の通りである。属性証明書発行提案拒否フレーム８４０は、ヘッダ部８４１と、ペイロード部８４２とから構成される。ヘッダ部８４１は、始点端末識別子８４３と、終点端末識別子８４４と、送信端末識別子８４５と、受信端末識別子８４６と、フレーム種別８４７と、拒否理由種別８４８とを含む。これらヘッダ部８４１内の内容については、図８により説明したビーコンフレーム８１０と同様であるが、拒否理由種別８４８についてはこの属性証明書発行提案拒否フレーム８４０特有のものである。この拒否理由種別８４８には、例えば、ユーザによる取り消し、属性認証局として信頼しない等の事由がコード化されて示される。

端末Ａは、端末Ｂから送信された属性証明書発行依頼メッセージ２０４１を受信すると、その内容から端末Ｂを確認（１０４）する。例えば、属性証明書発行依頼フレーム８３０の始点端末識別子８３３（図９）や公開鍵証明書８３９１における公開鍵の所有者７１６（図３）を表示部３４０（図１）に表示することにより、自分の信頼できる端末であるか否かの判断をユーザに促す。送信元の端末Ｂが信頼する端末であれば、ユーザは操作部３５０（図１）により確認操作を行う。

ユーザにより確認がなされると、端末Ａは属性証明書を発行するために属性証明書発行メッセージ１０５２を端末Ｂに送信（１０５）する。この属性証明書発行メッセージ１０５２のフレーム構成は図１１の通りである。属性証明書発行フレーム８６０は、ヘッダ部８６１と、ペイロード部８６２とから構成される。ヘッダ部８６１は、始点端末識別子８６３と、終点端末識別子８６４と、送信端末識別子８６５と、受信端末識別子８６６と、フレーム種別８６７とを含む。これらヘッダ部８６１内の内容については、図９により説明した属性証明書発行提案フレーム８２０と同様である。また、この属性証明書発行フレーム８６０では、ペイロード部８６２のデータ８６９として、依頼元である端末Ｂを所有者として端末Ａにより署名された属性証明書８６９１が含まれる。端末Ａから属性証明書発行メッセージ１０５２を受信（２０５）した端末Ｂは、属性証明書発行フレーム８６０から属性証明書８６９１を抽出して、属性証明書テーブル６２０に格納する。

なお、ユーザにより確認（１０４）が拒否された場合には、端末Ａは属性証明書発行依頼の拒否を通知する属性証明書発行依頼拒否メッセージを端末Ｂに送信するようにしてもよい。この属性証明書発行依頼拒否メッセージのフレーム構成は図１０の通りであり、属性証明書発行提案拒否フレーム８４０と同様である。

図１２は、本発明の実施の形態における初期登録手順の第１の実施例の変形例を示す図である。この変形例では、属性証明書発行端末から属性証明書発行提案メッセージを送信する際に、属性証明書を発行してそのメッセージに添付しておくことにより、端末間でやりとりされるメッセージの数を減らすものである。ここで、端末Ａ（１００）が属性証明書発行端末であり、端末Ｂ（２００）が新規参入端末である点は、図７の第１の実施例と同様である。両端末がビーコンを送信し合う点も同様であり、端末Ｂが送信（２３１）したビーコン２３１１を端末Ａが受信（１３１）し、端末Ａが送信（１３２）したビーコン１３２２を端末Ｂが受信（２３２）することにより、端末Ａおよび端末Ｂは互いの端末識別子を把握する。これらビーコンのフレーム構成も第１の実施例と同様に図８で説明した通りである。

この図１２の実施例では、図７の第１の実施例とは異なり、ビーコンを受信した属性証明書発行端末である端末Ａ（１００）が、属性証明書発行依頼メッセージ（図７の２０４１）を受けることなく新規参入端末である端末Ｂ（２００）に対して属性証明書を発行し、属性証明書発行提案メッセージ１３３２のペイロード部のデータに含めて送信する。この属性証明書には、発行先である端末Ｂを所有者として端末Ａによる署名がなされる。この場合の属性証明書発行提案メッセージ１３３２のフレーム構成１８２０は図１３の通りであり、ペイロード部１８２２のデータ１８２９として発行先端末への属性証明書１８２９２を含んでいる点を除いて図９の属性証明書発行提案メッセージのフレーム構成８２０と同様の構成となっている。これにより、図７の第１の実施例と比べてメッセージ数を減らすことが可能となる。なお、属性証明書発行提案メッセージが属性証明書１８２９２を含むか否かは、端末Ｂ（２００）においてフレーム種別８２７または１８２７により判断するようにしてもよく、また、別途フィールドを設けてそのフィールドの内容により判断するようにしてもよい。

図１２の実施例では、端末Ｂ（２００）は、端末Ａ（１００）から送信（１３３）された属性証明書発行提案メッセージ１３３２を受信（２３３）すると、その内容から端末Ａ（１００）を確認する。例えば、属性証明書発行提案フレーム１８２０の始点端末識別子１８２３を表示することにより、正しい属性証明書発行端末であるか否かの判断をユーザに促す。これにより、アドレス偽造等による悪意のある端末や意図しない端末の介入を防ぐことができる。送信元の端末Ａ（１００）が信頼する端末であり且つ端末Ａ（１００）が発行した属性証明書を受け入れる場合には、ユーザは操作部３５０（図１）により確認操作を行う。端末Ａ（１００）からの属性証明書発行提案メッセージ１３３２を受け入れた端末Ｂ（２００）は、属性証明書発行提案フレーム１８２０のペイロード部１８２２から属性証明書１８２９２を抽出して、属性証明書テーブル６２０（図１）に格納する。

ユーザにより確認（２３３）がなされると、端末Ｂ（２００）は属性証明書発行提案メッセージ１３３２を受領する属性証明書発行提案受領メッセージ２３４１を端末Ａ（１００）に送信（２３４）する。この属性証明書発行提案受領メッセージ２３４１のフレーム構成１８３０は図１４の通りであり、基本的には図９の属性証明書発行依頼メッセージのフレーム構成と同様の構成になっている。

なお、ユーザの確認（２３３）により提案が拒否された場合には、端末Ｂ（２００）は属性証明書発行提案の拒否を通知する属性証明書発行提案拒否メッセージを端末Ａに送信するようにしてもよい。この属性証明書発行提案拒否メッセージのフレーム構成８４０は図１０で説明したものと同様の構成である。

図１５は、本発明の実施の形態における初期登録の手順の第２の実施例を示す図である。端末Ａ（１００）が属性証明書発行端末であり、端末Ｂ（２００）が新規参入端末である点は、図７の第１の実施例と同様である。両端末がビーコンを送信し合う点も同様であり、端末Ｂが送信（２２１）したビーコン２２１１を端末Ａが受信し（１２１）、端末Ａが送信（１２２）したビーコン１２２２を端末Ｂが受信（２２２）することにより、端末Ａおよび端末Ｂは互いの端末識別子を把握する。これらビーコン２２１１および１２２２のフレーム構成も同様に図８の通りである。

この図１５の第２の実施例では、図７の第１の実施例とは異なり、ビーコンを受信した新規参入端末である端末Ｂが、属性証明書発行提案メッセージを受けることなく、属性証明書発行端末である端末Ａに対して属性証明書発行依頼メッセージ２２５１を送信（２２５）する。この属性証明書発行依頼メッセージ２０４１のフレーム構成８３０は図９により説明した通りである。この際、もしも属性証明書発行依頼メッセージ２２５１の送信先である端末Ａの公開鍵証明書を端末Ｂが有していない場合には、端末Ｂは公開鍵証明書要求メッセージ２２３１を送信することにより公開鍵証明書を端末Ａに要求する（２２３）。この公開鍵証明書要求メッセージ２２３１のフレーム構成１８７０は図１６の通りであり、図７の第１の実施例において説明した属性証明書発行提案メッセージ１０３２のフレーム８２０（図９）と同様である。但し、ペイロード部１８７２には公開鍵証明書は含まれない。

公開鍵証明書要求メッセージ２２３１を受信（１２３）した端末Ａは、生成鍵テーブル６５０（図１）に保持している自端末の公開鍵証明書を公開鍵証明書要求応答メッセージ１２４２により送信（１２４）する。これにより、端末Ｂは属性証明書発行端末である端末Ａの公開鍵証明書を受領（２２４）する。なお、この公開鍵証明書要求応答メッセージ１２４２のフレーム構成１８８０は図１７の通りであり、図７の第１の実施例において説明した属性証明書発行提案メッセージ１０３２のフレーム８２０（図９）と同様である。ペイロード部１８８２のデータとして送信元端末である端末Ａの公開鍵証明書１８８９が含まれる点も同様である。

端末Ａは、端末Ｂから送信された属性証明書発行依頼メッセージ２２５１を受信すると、その内容から端末Ｂを確認（１２５）する。例えば、属性証明書発行依頼フレーム８３０の始点端末識別子８３３（図９）や公開鍵証明書８３９１における公開鍵の所有者７１６（図３）を表示部３４０（図１）に表示することにより、自分の信頼できる端末であるか否かの判断をユーザに促す。送信元の端末Ｂが信頼する端末であれば、ユーザは操作部３５０（図１）により確認操作を行う。

ユーザにより確認がなされると、端末Ａは属性証明書を発行するために属性証明書発行メッセージ１２６２を端末Ｂに送信（１２６）する。これにより、端末Ｂは属性証明書を受領（２２６）する。なお、この属性証明書発行メッセージ１２６２のフレーム構成８６０は図１１により説明した通りである。

図１８は、本発明の実施の形態における相互認証の手順を示す図である。初期登録を終えた端末同士が互いの属性証明書を検証することにより相互認証を行う。本発明の実施の形態における無線アドホック通信システムでは、各端末は定期的にビーコンを送信し、他の端末に対して自己の存在を知らせる。以下では、端末Ｂのビーコンをトリガーとして端末Ａが認証要求を行うものと仮定するが、最終的に相互に認証が行われればよく、何れの端末のビーコンをトリガーとしてもよい。

まず、端末Ｂが、ネットワークに参入するためにビーコン２１１１を送信する（２１１）。このビーコン２１１１のフレーム構成は上述の図８の通りである。図７の初期登録シーケンスと異なり、この図１８の相互認証においては端末Ｂは属性証明書を有しているため、この属性証明書の有無８１８には「有している」旨が示される。

端末Ａは、端末Ｂから送信されたビーコン２１１１を受信すると（１１１）、ビーコンフレーム８１０の属性証明書の有無８１８をチェックする。端末Ｂが属性証明書を有していると判断すると、端末Ａは端末Ｂに対して端末Ａを認証するよう認証要求メッセージ１１２２を送信する（１１２）。この認証要求メッセージ１１２２のフレーム構成は図１９の通りである。認証要求フレーム８７０は、ヘッダ部８７１と、ペイロード部８７２とから構成される。ヘッダ部８７１は、始点端末識別子８７３と、終点端末識別子８７４と、送信端末識別子８７５と、受信端末識別子８７６と、フレーム種別８７７とを含む。これらヘッダ部８７１内の内容については、図９により説明した属性証明書発行提案フレーム８２０と同様である。また、この認証要求フレーム８７０では、ペイロード部８７２のデータ８７９として、送信元である端末Ａの公開鍵証明書８７９１および属性証明書８７９２が含まれる。端末Ａの公開鍵証明書８７９１は端末Ａの生成鍵テーブル６５０に予め格納されたものであり、端末Ａの属性証明書８７９２は端末Ａの属性証明書テーブル６２０に予め格納されたものである。

端末Ｂは、端末Ａから送信された認証要求メッセージ１１２２を受信すると、その内容から端末Ａを認証する（２１２）。具体的には、属性証明書発行端末リストテーブル６１０の公開鍵証明書６１２（図２）から属性認証局の公開鍵を抽出して、この公開鍵によって認証要求メッセージ１１２２に含まれる属性証明書８７９２の署名７２９（図４）を復号することにより署名時のメッセージダイジェストを得る。そして、属性証明書８７９２の属性証明情報７２１（図４）のメッセージダイジェストを新たに生成する。この新たに生成されたメッセージダイジェストが署名時のメッセージダイジェストと一致していることを確認する。もしこれらが一致しないとすれば、属性証明書は署名後に改ざんされた可能性があり、属性証明書の検証は失敗となる。両者が一致している場合には、さらに認証要求メッセージ１１２２に含まれる属性証明書８７９２の所有者公開鍵証明書識別子７２３（図４）が、認証要求メッセージ１１２２に含まれる公開鍵証明書８７９１の発行者７１４およびシリアル番号７１２（図３）に一致することを確認する。これが一致すれば、公開鍵証明書の所有者である端末Ａは属性証明書の所有者であることが確認できる。もしこれらが一致しないとすれば、属性証明書の所有者は端末Ａではなく、属性証明書の検証は失敗となる。

なお、この属性証明書の検証の際には、その属性証明書が属性証明書失効リストテーブル６３０に含まれていないことを確認する必要がある。属性証明書８７９２の発行者７２４およびシリアル番号７２２（図４）が属性証明書失効リストテーブル６３０の属性証明書識別子６３１（図５）に含まれている場合には、その属性証明書８７９２は失効時刻６３２を境に失効していることになる。従って、その場合には属性証明書の検証は失敗となる。

端末Ａの認証（２１２）に成功すると、端末Ｂは端末Ａの認証に成功したことを通知する認証成功メッセージ２１３１を端末Ａに送信する（２１３）。この認証成功メッセージ２１３１の認証応答フレーム構成は図２０の通りである。認証応答フレーム８８０は、ヘッダ部８８１と、ペイロード部８８２とから構成される。ヘッダ部８８１は、始点端末識別子８８３と、終点端末識別子８８４と、送信端末識別子８８５と、受信端末識別子８８６と、フレーム種別８８７とを含む。これらヘッダ部８８１内の内容については、図９により説明した属性証明書発行提案フレーム８２０と同様である。認証成功メッセージ２１３１の場合、フレーム種別８８７は認証成功フレームとなる。この認証応答フレーム８８０では、さらに応答理由種別８８８を含むが、認証成功の場合は特に必要はない。

なお、端末Ａの属性証明書の検証（２１２）に失敗すると、端末Ｂは端末Ａの認証に成功したことを通知する認証失敗メッセージを端末Ａに送信することになる。この認証失敗メッセージの認証応答フレーム構成は図２０により説明した通りである。但し、認証失敗メッセージの場合、フレーム種別８８７は認証失敗フレームとなり、応答理由種別８８８には認証に失敗した理由として属性証明書のメッセージダイジェスト不一致、属性証明書失効等の事由がコード化されて示される。これら。認証成功メッセージ２１３１または認証失敗メッセージは端末Ａにおいて受信されて確認される（１１３）。

端末Ａの属性証明書の検証（２１２）に成功すると、さらに端末Ｂは端末Ａに対して端末Ｂを認証するよう認証要求メッセージ２１４１を送信する（２１４）。この認証要求メッセージ２１４１のフレーム構成は上述の図１９と同様であり、送信元である端末Ｂの公開鍵証明書８７９１および属性証明書８７９２が含まれる。

端末Ａは、端末Ｂから送信された認証要求メッセージ２１４１を受信すると、その内容から端末Ｂを認証する（１１４）。この認証の内容は既に説明した通りであり、属性証明書の検証、属性証明書の所有者の確認、および、属性証明書失効リストテーブル６３０の確認等を行う。

端末Ｂの認証（２１２）に成功すると、端末Ａは端末Ｂの認証に成功したことを通知する認証成功メッセージ１１５２を端末Ｂに送信する（１１５）。この認証成功メッセージ１１５２の認証応答フレーム構成は上述の図２０と同様である。また、端末Ｂの属性証明書の検証（２１２）に失敗した場合には、端末Ａは端末Ｂの認証に成功したことを通知する認証失敗メッセージを端末Ｂに送信することになる。この認証失敗メッセージの認証応答フレーム構成も図２０により説明した通りである。これら認証成功メッセージ１１５２または認証失敗メッセージは端末Ｂにおいて受信されて確認される（２１５）。

このようにして、端末Ａおよび端末Ｂにおいて互いの端末の認証に成功すると相互認証は完了する。この相互認証が完了した後、属性証明書発行端末リストテーブル６１０および属性証明書失効リストテーブル６３０の内容を相互に交換して併合する。また、新たに属性証明書発行端末になった端末は、自己の公開鍵証明書を全ての端末にブロードキャスト配布する。さらに、上述のように、属性証明書失効リストを発行した端末は、他の端末に属性証明書失効リストをブロードキャスト配布する。これらにより、ネットワークに接続中の各端末の属性証明書発行端末リストテーブル６１０および属性証明書失効リストテーブル６３０の内容の同一性が維持される。

次に本発明の実施の形態における無線アドホック通信システムの各端末の処理の流れについて図面を参照して説明する。

図２１は、図７の初期登録の第１の実施例における属性証明書発行端末の処理の流れを示す図である。まず、他の端末からビーコンを受信すると、そのビーコンの送信元端末が属性証明書を有している旨をそのビーコンが示しているか否かを判断する（ステップＳ９１１）。属性証明書を有している旨をそのビーコンが示していれば、属性証明書を発行する必要がないので、この初期登録の処理は行わずに終了する。属性証明書を有している旨をそのビーコンが示していなければ、ビーコンの始点端末識別子を確認して、送信元端末に対して属性証明書の発行を依頼することを提案する（ステップＳ９１２）。

その後、属性証明書の発行依頼があれば（ステップＳ９１３）、その依頼元端末に関する情報を表示して確認を促す（ステップＳ９１４）。その結果、依頼元端末が信頼できる端末として確認された場合には（ステップＳ９１５）、依頼元端末に対して属性証明書を発行する（ステップＳ９１６）。逆に、確認が拒否された場合には依頼元端末に対して属性証明書発行依頼の拒否を通知する（ステップＳ９１７）。

図２２は、図７の初期登録の第１の実施例における新規参入端末の処理の流れを示す図である。まず、属性証明書を有していない旨を示すビーコンを送信する（ステップＳ９２１）。その後、ビーコンに応答した他の端末からの属性証明書発行提案があると（ステップＳ９２２）、その提案をした端末の確認をユーザに促す（ステップＳ９２３）。送信元の端末が信頼する端末であればその端末に属性証明書を発行してもらうことを意図する確認がなされる（ステップＳ９２４）。この確認がなされるとその送信元端末に対して属性証明書の発行依頼を行う（ステップＳ９２５）。これにより、属性証明書の発行を受けることができる（ステップＳ９２６）。一方、この確認がされなければ初期登録の処理は完了せず、属性証明書は発行されない。

図２３は、図１２の初期登録の第１の実施例の変形例における属性証明書発行端末の処理の流れを示す図である。まず、他の端末からビーコンを受信すると、そのビーコンの送信元端末が属性証明書を有している旨をそのビーコンが示しているか否かを判断する（ステップＳ９７１）。属性証明書を有している旨をそのビーコンが示していれば、属性証明書を発行する必要がないので、この初期登録の処理は行わずに終了する。属性証明書を有している旨をそのビーコンが示していなければ、ビーコンの始点端末識別子を確認して、送信元端末に対して属性証明書を発行し（ステップＳ９７２）、その属性証明書を提案メッセージに含めて送信する（ステップＳ９７３）。

図２４は、図１２の初期登録の第１の実施例の変形例における新規参入端末の処理の流れを示す図である。まず、属性証明書を有していない旨を示すビーコンを送信する（ステップＳ９８１）。その後、ビーコンに応答した他の端末からの属性証明書発行提案があると（ステップＳ９８２）、その提案をした端末の確認（ステップＳ９８３）をユーザに促す。送信元の端末が信頼する端末であれば（ステップＳ９８４）、その端末が発行した属性証明書を受領して（ステップＳ９８５）、その属性証明書を受領した旨を示すメッセージを送信元の端末に送信する（ステップＳ９８６）。

図２５は、図１５の初期登録の第２の実施例における新規参入端末の処理の流れを示す図である。まず、受信したビーコンの始点端末識別子８１３（図８）を把握し、そのビーコンの送信元端末に属性証明書の発行を依頼するか否かを判断する（ステップＳ９５１）。発行を希望しない場合には、当該処理は終了する。もし、新規参入端末がビーコン送信元端末の公開鍵証明書を所持していない場合には（ステップＳ９５２）、ビーコン送信元端末に対して公開鍵証明書を要求し（ステップＳ９５３）、受領する（ステップＳ９５４）。

そして、公開鍵証明書に含まれる公開鍵がビーコン送信元端末のものであって、当該端末に属性証明書を発行してもらうと判断した場合には（ステップＳ９５５）、その送信元端末に対して属性証明書の発行依頼を行う（ステップＳ９５６）。これにより、属性証明書の発行を受けることができる。一方、公開鍵がビーコン送信元端末のものであることが確認できない場合には、属性証明書の発行依頼は行わない。

図２６は、図１５の初期登録の第２の実施例における属性証明書発行端末の処理の流れを示す図である。まず、他の端末から公開鍵証明書の要求があれば（ステップＳ９６１）、要求に応答して公開鍵証明書を送信する（ステップＳ９６２）。その後、属性証明書の発行依頼があれば（ステップＳ９６３）、その依頼元端末に関する情報を表示して確認を促す（ステップＳ９６４）。その結果、依頼元端末が信頼できる端末として確認された場合には（ステップＳ９６５）、依頼元端末に対して属性証明書を発行する（ステップＳ９６６）。逆に、確認が拒否された場合には依頼元端末に対して属性証明書発行依頼の拒否を通知する（ステップＳ９６７）。

図２７は、図１８の相互認証におけるビーコン受信端末の処理の流れを示す図である。まず、他の端末からビーコンを受信すると、そのビーコンの送信端末が属性証明書を有している旨をそのビーコンが示しているか否かを判断する（ステップＳ９３１）。属性証明書を有している旨をそのビーコンが示していなければ、相互認証を行うことができないため、この相互認証の処理は行わずに終了する。なお、この場合には属性証明書発行端末から属性証明書発行の提案がなされる。一方、属性証明書を有している旨をそのビーコンが示していれば、ビーコンの送信端末に対して認証要求を送信する（ステップＳ９３２）。この結果、ビーコンの送信端末において認証が失敗すると、この相互認証は完了せず（ステップＳ９３３）、両端末は互いにネットワークを構成することができない。一方、ビーコンの送信端末において認証が成功すると、反対にビーコン送信端末から認証要求が送信される。

認証要求を受信すると（ステップＳ９３４）、認証要求元のビーコン送信端末の認証を行う（ステップＳ９３５）。認証に成功すれば（ステップＳ９３６）、認証成功の旨を認証要求端末（ビーコン送信端末）に送信する（ステップＳ９３７）。一方、認証に失敗した場合には（ステップＳ９３６）、認証失敗の旨を認証要求端末に送信する（ステップＳ９３８）。

図２８は、図１８の相互認証におけるビーコン送信端末の処理の流れを示す図である。まず、属性証明書を有している旨を示すビーコンを送信する（ステップＳ９４１）。その後、ビーコンに応答した他の端末からの認証要求を受信すると（ステップＳ９４２）、認証要求元のビーコン受信端末の認証を行う（ステップＳ９４３）。認証に失敗した場合には（ステップＳ９４４）、認証失敗の旨を認証要求端末（ビーコン受信端末）に送信する（ステップＳ９４５）。一方、認証に成功した場合には（ステップＳ９４４）、認証成功の旨を認証要求端末に送信するとともに（ステップＳ９４６）、ビーコン受信端末に対して認証要求を送信する（ステップＳ９４７）。その後、ビーコン受信端末から認証要求に対する応答が送信される（ステップＳ９４８）。

次に本発明の実施の形態における無線アドホック通信システムの端末間の接続関係について図面を参照して説明する。

図２９は、端末同士が無線アドホック通信システムのネットワークを構成していく過程を示す図である。最初に端末Ａ（１００）が属性証明書発行端末として機能しているとすると、端末Ａの属性証明書発行端末リストテーブル６１０には端末Ａの公開鍵証明書（ＰＫ−Ａ）が保持され、端末Ａの属性証明書テーブルには端末Ａ発行の属性証明書（ＡＣ−Ａ）が保持される（図２９（ａ））。端末Ｂ（２００）がビーコンを送信すると、端末Ａから端末Ｂに対して属性証明書が発行され、初期登録の結果、端末Ｂの属性証明書発行端末リストテーブル６１０には端末Ａの公開鍵証明書（ＰＫ−Ａ）が保持され、端末Ｂの属性証明書テーブルには端末Ａ発行の属性証明書（ＡＣ−Ａ）が保持される（図２９（ｂ））。初期登録の後、相互認証が行われることにより、端末Ａと端末Ｂは無線アドホック通信システムのネットワークを構成する。

その後、端末Ｃがビーコンを送信すると、端末Ｂを介して端末Ａから端末Ｃに対して属性証明書が発行され、初期登録の後、例えば端末Ｂと相互認証を行うことにより端末Ｃは無線アドホック通信システムのネットワークに参入する（図２９（ｃ））。さらに、端末Ｃがビーコンを送信した場合も同様の手順を経て、端末Ｄは無線アドホック通信システムのネットワークに参入する（図２９（ｃ））。

そして、これまで属性証明書発行端末として機能していた端末Ａが何らかの要因によりネットワークから切断されると、他の端末が属性証明書発行端末として機能することになる。この属性証明書発行端末の選択基準としては種々のものが考えられるが、例えば、ある時点で中心位置に存在している端末や、電池の残容量が最も多い端末等を選択することができる。例えば、端末Ｂが属性証明書発行端末として選択されたとすると、端末Ｂは自己の公開鍵証明書（ＰＫ−Ｂ）を接続中の全端末にブロードキャスト配布する。各端末は、端末Ｂの公開鍵証明書（ＰＫ−Ｂ）を端末Ｂの端末識別子とともに属性証明書発行端末リストテーブル６１０に格納する（図２９（ｄ））。

図３０は、一旦切断された端末が無線アドホック通信システムのネットワークに再び参入する過程を示す図である。端末Ａが切断されて端末Ｂが属性証明書発行端末として機能するようになった後に、端末Ｅがビーコンを送信すると（図３０（ａ））、端末Ｂから端末Ｅに対して属性証明書が発行される。初期登録の結果、端末Ｅの属性証明書発行端末リストテーブル６１０には現行の属性証明書発行端末である端末Ｂの公開鍵証明書（ＰＫ−Ｂ）と過去の属性証明書発行端末である端末Ａの公開鍵証明書（ＰＫ−Ａ）が保持される。また、端末Ｅの属性証明書テーブルには端末Ｂ発行の属性証明書（ＡＣ−Ｂ）が保持される（図３０（ｂ））。

その後、端末Ａが再び接続する場合には、端末Ａは保持していた端末Ａ発行による属性証明書（ＡＣ−Ａ）により認証を行う。そして、相互認証後、端末Ｂとの間で属性証明書発行端末リストテーブル６１０の更新を行う。その結果、端末Ａの属性証明書発行端末リストテーブル６１０には新たに端末Ｂの公開鍵証明書（ＰＫ−Ｂ）が保持される（図３０（ｃ））。

このように、本発明の実施の形態によれば、ビーコンを受信した属性証明書発行端末がビーコンフレーム８１０の属性証明書の有無８１８（図８）をチェックして、ビーコン送信端末が属性証明書を有していないと判断した場合には、属性証明書の発行依頼を提案する属性証明書発行提案フレーム８２０（図９）をビーコン送信端末に対して送信することにより、これらを契機として属性証明書を自律分散して発行することができる。

なお、ここでは本発明の実施の形態を例示したものであり、本発明はこれに限られず、本発明の要旨を逸脱しない範囲において種々の変形を施すことができる。

また、ここで説明した処理手順はこれら一連の手順を有する方法として捉えてもよく、これら一連の手順をコンピュータ（端末）に実行させるためのプログラム乃至そのプログラムを記憶する記録媒体として捉えてもよい。

本発明の活用例として、例えば無線アドホック通信システムにおける端末間において端末権限認証証明書の発行を行う際に本発明を適用することができる。

本発明の実施の形態における無線アドホック通信システムにおいて使用される無線端末３００の構成例を示す図である。 本発明の実施の形態における属性証明書発行端末リストテーブル６１０の構成例である。 本発明の実施の形態における属性証明書発行端末リストテーブル６１０に保持される公開鍵証明書６１２のフォーマット７１０を示す図である。 本発明の実施の形態における属性証明書テーブル６２０に保持される属性証明書のフォーマット７２０を示す図である。 本発明の実施の形態における属性証明書失効リストテーブル６３０の構成例である。 本発明の実施の形態における属性証明書失効リスト７３０のフォーマットを示す図である。 本発明の実施の形態における初期登録の手順の第１の実施例を示す図である。 本発明の実施の形態におけるビーコンフレーム８１０の構成を示す図である。 本発明の実施の形態における属性証明書発行提案フレーム８２０および属性証明書発行依頼フレーム８３０の構成を示す図である。 本発明の実施の形態における属性証明書発行提案拒否フレーム８４０および属性証明書発行依頼拒否フレーム８５０の構成を示す図である。 本発明の実施の形態における属性証明書発行フレーム８６０の構成を示す図である。 本発明の実施の形態における初期登録の手順の第１の実施例の変形例を示す図である。 本発明の実施の形態における属性証明書発行提案フレーム１８２０の構成を示す図である。 本発明の実施の形態における属性証明書発行提案受領フレーム１８３０の構成を示す図である。 本発明の実施の形態における初期登録の手順の第２の実施例を示す図である。 本発明の実施の形態における公開鍵証明書要求フレーム８７０の構成を示す図である。 本発明の実施の形態における公開鍵証明書要求応答フレーム８８０の構成を示す図である。 本発明の実施の形態における相互認証の手順を示す図である。 本発明の実施の形態における認証要求フレーム８７０の構成を示す図である。 本発明の実施の形態における認証応答フレーム８８０の構成を示す図である。 本発明の実施の形態における初期登録の際の属性証明書発行端末の第１の実施例における処理の流れを示す図である。 本発明の実施の形態における初期登録の際の新規参入端末の第１の実施例における処理の流れを示す図である。 本発明の実施の形態における初期登録の際の属性証明書発行端末の第１の実施例の変形例における処理の流れを示す図である。 本発明の実施の形態における初期登録の際の新規参入端末の第１の実施例の変形例における処理の流れを示す図である。 本発明の実施の形態における初期登録の際の新規参入端末の第２の実施例における処理の流れを示す図である。 本発明の実施の形態における初期登録の際の属性証明書発行端末の第２の実施例における処理の流れを示す図である。 本発明の実施の形態における相互認証の際のビーコン受信端末の処理の流れを示す図である。 本発明の実施の形態における相互認証の際のビーコン送信端末の処理の流れを示す図である。 本発明の実施の形態において端末同士が無線アドホック通信システムのネットワークを構成していく過程を示す図である。 本発明の実施の形態において一旦切断された端末が無線アドホック通信システムのネットワークに再び参入する過程を示す図である。

符号の説明

３００ 無線端末
３１０ アンテナ
３２０ 通信処理部
３３０ 制御部
３４０ 表示部
３５０ 操作部
３６０ スピーカ
３７０ マイク
３８０ バス
６００ メモリ
６１０ 属性証明書発行端末リストテーブル
６２０ 属性証明書テーブル
６３０ 属性証明書失効リストテーブル
６５０ 生成鍵テーブル
７１０ 公開鍵証明書
７２０ 属性証明書
７３０ 属性証明書失効リスト
８１０ ビーコンフレーム
８２０ 属性証明書発行提案フレーム
８３０ 属性証明書発行依頼フレーム
８４０ 属性証明書発行提案拒否フレーム
８５０ 属性証明書発行依頼拒否フレーム
８６０ 属性証明書発行フレーム
８７０ 認証要求フレーム
８８０ 認証応答フレーム
１８２０ 属性証明書発行提案フレーム
１８３０ 属性証明書発行提案受領フレーム
１８７０ 公開鍵証明書要求フレーム
１８８０ 公開鍵証明書要求応答フレーム

Claims (19)

1. 複数の端末により構成される無線アドホック通信システムであって、
   端末権限認証証明書を有しない旨を示すビーコン情報を含む信号を送信する第１の端末と、
   前記信号に応答して、端末権限認証証明書発行依頼メッセージを送信するように前記第１の端末に対して端末権限認証証明書発行提案メッセージを送信する第２の端末と
   を具備する無線アドホック通信システム。
2. ビーコン情報を含む信号を受信する受信手段と、
   この受信手段が他の端末から所定のビーコン情報を含む信号を受信すると端末権限認証証明書発行依頼メッセージを送信するように当該他の端末に対して端末権限認証証明書発行提案メッセージを送信する端末権限認証証明書発行提案手段と
   を具備する端末。
3. 前記受信手段が受信した前記他の端末からの前記信号より当該他の端末の端末識別情報を取得する手段をさらに具備し、
   前記端末権限認証証明書発行提案手段は、前記端末識別情報に基づいて前記提案メッセージを送信する
   請求項２記載の端末。
4. 前記端末権限認証証明書発行提案手段は、前記他の端末に対して前記端末権限認証証明書発行依頼メッセージの送信を提案する際に前記端末の公開鍵証明書を併せて提示する
   請求項２記載の端末。
5. ビーコン情報を含む信号を受信する受信手段と、
   この受信手段が他の端末から所定のビーコン情報を含む信号を受信すると当該他の端末を所有者とする端末権限認証証明書を発行して当該端末権限認証証明書を含む端末権限認証証明書発行提案メッセージを当該他の端末に対して送信する端末権限認証証明書発行提案手段と
   を具備する端末。
6. 前記受信手段が受信した前記他の端末からの前記信号より当該他の端末の端末識別情報を取得する手段をさらに具備し、
   前記端末権限認証証明書発行提案手段は、前記端末識別情報に基づいて前記端末権限認証証明書発行提案メッセージを送信する
   請求項５記載の端末。
7. 前記端末権限認証証明書発行提案手段は、前記他の端末に対して前記端末権限認証証明書発行提案メッセージを送信する際に前記端末の公開鍵証明書を併せて提示する
   請求項５記載の端末。
8. ビーコン情報を含む信号を受信するための受信手段と、
   この受信手段が他の端末からビーコン情報を含む信号を受信した場合において当該他の端末が端末権限認証証明書を有する旨を前記信号が示していなければ端末権限認証証明書発行依頼メッセージを送信するように当該他の端末に対して端末権限認証証明書発行提案メッセージを送信する端末権限認証証明書発行提案手段と
   を具備する端末。
9. 前記受信手段が受信した前記他の端末からの前記信号より当該他の端末の端末識別情報を取得する手段をさらに具備し、
   前記端末権限認証証明書発行提案手段は、前記端末識別情報に基づいて前記提案メッセージを送信する
   請求項８記載の端末。
10. 前記端末権限認証証明書発行提案手段は、前記他の端末に対して前記端末権限認証証明書発行依頼メッセージの送信を提案する際に前記端末の公開鍵証明書を併せて提示する
    請求項８記載の端末。
11. 前記端末権限認証証明書発行依頼メッセージを受信するための端末権限認証証明書発行依頼受信手段と、
    この端末権限認証証明書発行依頼受信手段が前記他の端末から前記端末権限認証証明書発行依頼メッセージを受信すると当該他の端末に関する情報を表示して確認を促す確認手段と、
    前記確認がなされた場合には前記他の端末に対して端末権限認証証明書を発行し、前記確認が拒否された場合には前記他の端末に対して端末権限認証証明書発行依頼の拒否を通知する端末権限認証証明書発行依頼拒否メッセージを送信する端末権限認証証明書発行手段と
    をさらに具備する請求項１０記載の端末。
12. 端末権限認証証明書発行端末の公開鍵証明書を保持する端末権限認証証明書発行端末リストテーブルをさらに具備し、
    前記端末権限認証証明書発行手段は、前記端末権限認証証明書の発行に際して前記端末権限認証証明書発行端末リストテーブルに保持された前記端末権限認証証明書発行端末の公開鍵証明書を前記他の端末に送信する
    請求項１１記載の端末。
13. 端末権限認証証明書の失効リストを保持する端末権限認証証明書失効リストテーブルをさらに具備し、
    前記端末権限認証証明書発行手段は、前記端末権限認証証明書の発行に際して前記端末権限認証証明書失効リストテーブルに保持された前記端末権限認証証明書失効リストを前記他の端末に送信する
    請求項１１記載の端末。
14. ビーコン情報を含む信号を受信するための受信手段と、
    この受信手段が他の端末からビーコン情報を含む信号を受信した場合において当該他の端末が端末権限認証証明書を有する旨を前記信号が示していなければ当該他の端末を所有者とする端末権限認証証明書を発行して当該端末権限認証証明書を含む端末権限認証証明書発行提案メッセージを当該他の端末に対して送信する端末権限認証証明書発行提案手段と
    を具備する端末。
15. 前記受信手段が受信した前記他の端末からの前記信号より当該他の端末の端末識別情報を取得する手段をさらに具備し、
    前記端末権限認証証明書発行提案手段は、前記端末識別情報に基づいて前記端末権限認証証明書発行提案メッセージを送信する
    請求項１４記載の端末。
16. 前記端末権限認証証明書発行提案手段は、前記他の端末に対して前記端末権限認証証明書発行提案メッセージを送信する際に前記端末の公開鍵証明書を併せて提示する
    請求項１４記載の端末。
17. ビーコン情報を含む信号を受信する手順と、
    前記信号の送信元端末が端末権限認証証明書を有する旨を前記信号が示していなければ端末権限認証証明書発行依頼メッセージを送信するように前記送信元端末に対して端末権限認証証明書発行提案メッセージを送信する手順と
    を具備する端末権限認証証明書発行提案方法。
18. 前記他の端末からの前記信号より当該他の端末の端末識別情報を取得する手順をさらに具備し、
    前記端末識別情報に基づいて前記提案メッセージを送信する
    請求項１７記載の端末権限認証証明書発行提案方法。
19. ビーコン情報を含む信号を受信する手順と、
    前記信号の送信元端末が端末権限認証証明書を有する旨を前記信号が示していなければ当該送信元端末を所有者とする端末権限認証証明書を発行して当該端末権限認証証明書を含む端末権限認証証明書発行提案メッセージを当該送信元端末に対して送信する手順と
    を具備する端末権限認証証明書発行提案方法。

Images