(57)【要約】【課題】アドホック・モードで三者以上の間でネットワークを構成するときの暗号鍵の共有・設定を行なう方法であって、通信相手の公開鍵の特定を人間が容易に行なう方法が明らかではなかった。【解決手段】ホスト２０２、２０３、２０４は、無線通信により他のホストを検出し、公開鍵証明書に基づいてホストあるいはユーザの識別を行なう。各ホストは、正当な公開鍵証明書の情報と総数を表示し、ユーザが確認すると、他のホストとの間で、公開鍵暗号に基づく会議鍵共有プロトコルを実行する。【選択図】　　　　図２
2004072470.tif 000002
【特許請求の範囲】
【請求項１】
無線通信によりノードを検出し、公開鍵証明書に基づいてホストあるいはユーザの識別を行なう手段と、正当な公開鍵証明書の情報と総数を表示する手段と、公開鍵暗号に基づく会議鍵共有プロトコルを実行する手段を有することを特徴とする情報通信装置。
【請求項２】
前記表示手段は、表示された正当な公開鍵証明書の情報と総数を、その情報通信装置のユーザと他の情報通信装置のユーザが視認可能とすることを特徴とする請求項１の情報通信装置。
【請求項３】
無線通信によりノードを検出し、公開鍵証明書に基づいてホストあるいはユーザの識別を行なう手段と、公開鍵証明書に記載された所属名称が一致するか否かを判別する手段と、公開鍵暗号に基づく会議鍵共有プロトコルを実行する手段を有することを特徴とする情報通信装置。
【請求項４】
無線通信によりノードを検出し、公開鍵証明書に基づいてホストあるいはユーザの識別を行ない、正当な公開鍵証明書の情報と総数を表示し、公開鍵暗号に基づく会議鍵共有プロトコルを実行することを特徴とする会議鍵共有プログラム。
【請求項５】
前記表示工程では、表示された正当な公開鍵証明書の情報と総数を、その情報通信装置のユーザと他の情報通信装置のユーザが視認可能とすることを特徴とする請求項４の会議鍵共有プログラム。
【請求項６】
無線通信によりノードを検出し、公開鍵証明書に基づいてホストあるいはユーザの識別を行ない、公開鍵証明書に記載された所属名称が一致するか否かを判別し、公開鍵暗号に基づく会議鍵共有プロトコルを実行することを特徴とする会議鍵共有プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、無線通信に基づき情報通信システムを構成する情報通信装置に関する。
【０００２】
【従来の技術】
ＩＰｖ６の登場により、従来はネットワークに接続することが考えられなかった装置がネットワークに接続する場面が考えられてきた。例えば、ディジタルカメラである。一方、安価な無線通信が普及しつつある。典型的な例はＩＥＥＥ　８０２．１１（通称、無線ＬＡＮ）やＢｌｕｅｔｏｏｔｈであり、これらを組み込んだ装置は無線で装置同士の間で直接に情報の送受信を行なえる。これをアドホック・モードと呼ぶ。
【０００３】
従って、無線に基づくアドホック・モードで通信が行なわれるＩＰｖ６ネットワークを構成することが現実的になってきた。
【０００４】
ところが、無線は傍受が容易であるので、機密を要する場合にはなんらかの手段で通信内容を保護する必要がある。そのために、アドホック・モードでネットワークを構成するときにどの装置と通信するべきかを間違えずに判断し、正しい通信相手との間で保護された通信を行なう必要がある。
【０００５】
無線ＬＡＮの場合は上述の機密保護のようなセキュリティを確保するための手段として、ＷＥＰ（Ｗｉｒｅｄ　Ｅｑｕｉｖａｌｅｎｔ　Ｐｒｉｖａｃｙ）と呼ばれる暗号通信機能、ＭＡＣアドレスによるアクセス制限、ＳＳＩＤ（同じ無線ＬＡＮネットワークのグループ名）の設定を使うことができるが、いずれも十分なセキュリティを提供できないという課題があった。ＷＥＰを改良して暗号化の強度を強める方法が提案されているが、暗号化鍵は人手により設定する必要があり、その鍵の更新や配送の際に人間が介在しなければならず、使い勝手も悪かった。使い勝手については、Ｂｌｕｅｔｏｏｔｈも同様である。
【０００６】
三者以上の間で共有する暗号化鍵は会議鍵と呼ばれる。会議鍵を共有する一つの方法は、その参加者のだれかが暗号化鍵を定め、それを口頭で別の参加者に伝える、あるいはそれを記述した紙やフロッピー（Ｒ）ディスク、ＰＣカード（メモリー）等の物体を参加者の間で物理的に回覧する方法である。
【０００７】
しかし、口頭で伝える場合は、０ｘｄａ７６ｆ０９ｂａ６３ｃ４０ｅｆのように充分に大きい複雑な値を伝えることが面倒なので、総当たりで突き止めるのが容易な小さい弱い鍵（例えば、１０進数４桁の９８７６等）を用いる傾向があり、かつ盗聴者に盗み聞きされる可能性がある。鍵を記述した紙を回覧する場合は、その鍵を装置に入力しなければならないが、装置によっては入力手段が使いにくいので、やはり小さな弱い鍵を使う傾向が残る。機械が自動的にデータを読み取れるフロッピー（Ｒ）ディスク等の物理メディアを回覧する場合は、充分大きい値を用いることが可能で盗み聞きや盗み見もされにくいが、全てのホストに共通の読み取り機構が存在しない可能性がある。
【０００８】
このように、人手による鍵の運用の煩雑さや共通の読み取り装置の不在という課題があった。
【０００９】
人手に頼らずに、安全ではない通信路上で鍵共有を行なう方式に関しては、二者間で暗号化の鍵を共有する方法としてＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送法が有名であり、ＩＰｓｅｃ等で実際に使われているが、三者以上の間で暗号化の鍵を共有することはできない。
【００１０】
会議鍵を共有する方法は、岡本龍明と白石旭による特許、特公平５−４６７３１、暗号鍵配送方式、あるいは、Ｍｉｋｅ　ＢｕｒｍｅｓｔｅｒとＹｖｏ　Ｄｅｓｍｅｄｔによる論文、Ａ　ｓｅｃｕｒｅ　ａｎｄ　ｅｆｆｉｃｉｅｎｔ　ｃｏｎｆｅｒｅｎｃｅ　ｋｅｙ　ｄｉｓｔｒｉｂｕｔｉｏｎ　ｓｙｓｔｅｍ、　Ａｄｖａｎｃｅｓ　ｉｎ　Ｃｒｙｐｔｏｌｏｇｙ−ＥＵＲＯＣＲＹＰＴ’９４　（ＬＮＣＳ　９５０）、Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ、ｐｐ．２７５−２８６、１９９５等のようにいくつか存在し、認証も行なえ、安全であると主張されている。しかし、それらの方式は暗号通信をする相手の本物の公開鍵が判明しているという前提の上で、会議鍵共有と認証を実現するものであり、あらかじめ通信相手が固定している拠点間テレビ会議のような用途向きである。
【００１１】
つまり、無線ネットワークのように不特定多数がアクセスできるような環境に応用するためには通信相手の公開鍵の特定を行なわなければならない。
【００１２】
【発明が解決しようとする課題】
アドホック・モードで三者以上の間でネットワークを構成するときの暗号鍵の共有・設定を行なう方法であって、通信相手の公開鍵の特定を人間が容易に行なう方法が明らかではなかった。
【００１３】
【課題を解決するための手段】
上記課題を解決するために、本出願に関わる第１の発明における情報通信装置は、無線通信により他ノードを検出し公開鍵証明書に基づいて他ホストの識別を行なう手段と、正当な公開鍵証明書の情報と総数を管理する手段と、正当な公開鍵証明書の情報と総数を表示する手段と、公開鍵暗号に基づく会議鍵共有プロトコルを実行する手段を有する。
【００１４】
上記識別手段によって他ホストの識別を確実に行なうことが可能となり、上記管理手段および表示手段によって本来は参加できてはいけないホストの存在を検出してユーザがそれを認識することが容易となり、上記実行手段によって暗号的に安全な会議鍵を自動的に共有することが可能となる。
【００１５】
上記課題を解決するために、本出願に関わる第２の発明における情報通信装置は、無線通信により他ノードを検出し公開鍵証明書に基づいて他ホストの識別を行なう手段と、正当な公開鍵証明書の情報と総数を管理する手段と、正当な公開鍵証明書の情報と総数を表示する手段と、公開鍵暗号に基づく会議鍵共有プロトコルを実行する手段と、表示された正当な公開鍵証明書の総数をその場の参加者全員が視認可能な情報共有手段を有する。
【００１６】
上記識別手段によって他ホストの識別を確実に行なうことが可能となり、上記管理手段および表示手段によって本来は参加できてはいけないホストの存在を検出してユーザがそれを認識することが容易となり、上記共有手段によって参加者全員が同一の総数を確認することが可能となり、上記実行手段によって暗号的に安全な会議鍵を自動的に共有することが可能となる。
【００１７】
上記課題を解決するために、本出願に関わる第３の発明における情報通信装置は、無線通信により他ノードを検出し公開鍵証明書に基づいて他ホストの識別を行なう手段と、正当な公開鍵証明書の情報と総数を表示する手段と、公開鍵証明書に記載された所属名称が一致するか否かを判別する手段と、公開鍵暗号に基づく会議鍵共有プロトコルを実行する手段を有する。
【００１８】
上記識別手段によって他ホストの識別を確実に行なうことが可能となり、上記管理手段および判別手段によって同一の所属に属するホストを自動選別することが可能となり、上記実行手段によって暗号的に安全な会議鍵を自動的に共有することが可能となる。
【００１９】
【発明の実施の形態】
（第１の実施の形態）
本実施の形態では、アドホック・モードでＩＰｖ６プロトコルを実行する複数のホスト（ノード）からなるネットワークを対象とする会議鍵共有方式を説明する。アドホック・モードを対象とするが、任意のホストが任意のホストと直接にリンクを確立できる程度に近接した環境を想定する。直接にリンクを確立できるとは、データリンク・レイヤーで通信相手との直接通信が行なえる状況が実現することを意味する。無線ＬＡＮでもＢｌｕｅｔｏｏｔｈでも、アドホック・モードで通信可能な相手が検出された場合、その相手はＭＡＣアドレス（ネットワーク・インターフェイスに付与された一意な識別子）で識別されるが、無線なので電波は周囲に放射され、電波の傍受のみを行なう悪意を持つホストが存在し、その存在は必ずしも検出されないと仮定する。
【００２０】
ＭＡＣアドレスからＩＰｖ６アドレスを自動的に構成する方法などのＩＰｖ６のアドレスに関する詳細は、ＲＦＣ　２３７３　“ＩＰ　Ｖｅｒｓｉｏｎ　６　Ａｄｄｒｅｓｓｉｎｇ　Ａｒｃｈｉｔｅｃｔｕｒｅ、”ＲＦＣ　２３７４“ＡｎＩＰｖ６　Ａｇｇｒｅｇａｔａｂａｌｅ　Ｇｌｏｂａｌ　Ｕｎｉｃａｓｔ　Ａｄｄｒｅｓｓ　Ｆｏｒｍａｔ、”ＲＦＣ　２３７５“ＩＰｖ６　Ｍｕｌｔｉｃａｓｔ　Ａｄｄｒｅｓｓ　Ａｓｓｉｇｎｍｅｎｔ、”ＲＦＣ　２４５０“Ｐｒｏｐｏｓｅｄ　ＴＬＡ　ａｎｄ　ＮＬＡ　Ａｓｓｉｇｎｍｅｎｔ　Ｒｕｌｅ、”ＲＦＣ　２４６１“Ｎｅｉｇｈｂｏｒ　Ｄｉｓｃｏｖｅｒｙ　ｆｏｒ　ＩＰ　Ｖｅｒｓｉｏｎ　６　（ＩＰｖ６）、”ＲＦＣ　２４６２“ＩＰｖ６　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ、”等に記述されているので、詳細についてはそちらを参照することとし以降では本発明に関連のある事柄についてのみ説明する。
【００２１】
ホスト同士が近接した環境においてアドホック・モードで通信可能な状況を想定しているので、通信可能な相手のＭＡＣアドレスやＩＰｖ６アドレスは装置が自動的に検出、設定することができる。従って、ネットワーク・レイヤーの通信が行なえる状態を前提として実施の形態を説明する。
【００２２】
図２は、本形態が適用される想定環境を模式的に示したものである。図２は、アドホック・モードの無線通信によって形成されたネットワーク２０１と、そこに接続可能なホスト（ノード）２０２、２０３、２０４、２０５を表わす。図２ではホスト２０２、２０３、２０４が会議鍵を共有しようとしており、ホスト２０５は盗聴者の支配下にあるホストとする。
【００２３】
ネットワーク２０１は、全てのホストがお互いに直接通信できる範囲を示すが、全てのホストがお互いに視認できているとは限らず、例えばホスト２０５は他のホスト達とは壁で隔てられた場所で密かに無線を盗聴しており、他のホスト達およびそれらを使うユーザ達はホスト２０５と盗聴者の存在に気が付かない状況をも考慮している。
【００２４】
図３は、ホスト（ノード）の一般的な構成を示す。図３からわかるように、ホスト３００は、ネットワーク・インターフェイス（無線アンテナおよび変調・復調・多重化・分離等の信号処理回路を含む）３０１、ＣＰＵ３０３、ＲＯＭ３０４、ＲＡＭ３０５、ＨＤ（ハードディスク）３０６、電源３０７、外部とのインターフェイス３０８、バス３１０を有する計算機であり、無線通信のためのハードウェアとディスプレイ３０２と入力デバイス（キーボードやボタン、ポインティングデバイス等）３０９を有するものとする。例えば、Ｂｌｕｅｔｏｏｔｈが埋め込まれたノートＰＣやＰＤＡ、ディジタルカメラが典型例である。外部との（非無線）入出力インターフェイス３０８は、ホストの筐体に設けられている入出力デバイスの機能を補うために使われるが、低価格ディジタルカメラのように、これを持たないホストもありうる。
【００２５】
なお以下の処理内容（手順）は、装置もしくはプログラムとして実現され、その装置を有するホストが実行する（もしくはそのプログラムがＲＯＭ３０４もしくはＨＤ３０６に格納されたホストが実行する）。例えば、プログラムとして実現される場合は、そのプログラムをＣＰＵ３０３がＲＯＭ３０４もしくはＨＤ３０６から読み込み、必要に応じてＲＡＭ３０５を計算のための空間として利用しながらバス３１０を介してネットワーク・インターフェイス３０１からパケットを送り出す、というような動作を行なう。このような動作は計算機としての一般的な動作なので、誤解される恐れのない範囲で詳細は省略し、ホストがパケットを送る、というように手順の本質を説明する。
【００２６】
また、無線通信なのでパケットを送る際に変調や多重化等の信号処理やアンテナから電磁波を放射する等の電気的・電子的な処理が行なわれるが、それらの処理は無線通信における一般的な処理であり、かつ前述のようにネットワーク・レイヤーの通信が行なえる状態を前提としているので、無線通信処理自体に関する詳細は省略する。
【００２７】
本発明の実施の形態においては、公開鍵証明書を利用する。公開鍵証明書は、公開鍵暗号の公開鍵とその持ち主の対応を保証するデータで、対応関係を確認した者によって作成されたディジタル署名である。公開鍵証明書が世の中で使われるためには、証明書を発行する者が信頼されている第三者でなければならず、証明書の正当性、つまり第三者が作成したディジタル署名の正当性を確認するためには、第三者の公開鍵が広く知られていなければならない。このような第三者を認証局と呼び、商用サービスを提供している認証局としてＶｅｒｉＳｉｇｎなどがある。
【００２８】
なお、公開鍵証明書のフォーマットとしてＸ．５０９ｖ３が使われることが多い。Ｘ．５０９ｖ３は、ＲＦＣ（Ｒｅｑｕｅｓｔ　Ｆｏｒ　Ｃｏｍｍｅｎｔ）としてＲＦＣ２４５９、Ｉｎｔｅｒｎｅｔ　Ｘ．５０９　Ｐｕｂｌｉｃ　Ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ　Ｃｅｒｔｉｆｉｃａｔｅ　ａｎｄ　ＣＲＬ　Ｐｒｏｆｉｌｅ、に仕様が示されている。Ｘ．５０９ｖ３の証明書に含めることができる項目には、その証明書の持ち主の名前（国名、組織名、氏名、電子メールアドレス等）や公開鍵、証明書の発行者名称等の必須項目がある。それらに加えて、オプションとして項目を追加でき、例えば持ち主の別名や電子メールアドレス、ＤＮＳ（Ｄｏｍａｉｎ（Ｎａｍｅｓｅｒｖｅｒ）Ｓｙｓｔｅｍ）の名前、ＵＲＩ（ｕｎｉｆｏｒｍ　ｒｅｓｏｕｒｃｅ　ｉｄｅｎｔｉｆｉｅｒ）、ＩＰアドレス等を証明書に含めることができる。それらの詳細はＲＦＣ２４５９に記述されている。
【００２９】
本実施の形態においては、各ホスト２０２、２０３、２０４のＲＡＭ３０４にはそれを所有もしくは使用するユーザの公開鍵証明書、その公開鍵証明書に対応する秘密鍵、認証局の公開鍵が格納されており、後述の会議鍵を共有するプロトコルを実行するプログラムがそれらにアクセスできるものとする。以下では、ユーザの証明書をホストの証明書と呼ぶ。
【００３０】
アドホック・モードで通信してネットワークを形成し、通信相手を認証し、会議鍵を共有するプロトコルを実行するプログラムを、アドホック会議鍵共有プログラムと呼ぶことにする。各ホスト（ノード）２０２、２０３、２０４において、ＣＰＵ３０３により、アドホック会議鍵共有プログラムが動作する。このプログラムの動作を図１のフローチャートを参照して説明する。
【００３１】
プログラムは、起動されると開始指示を受け取るまで待機する。ステップＳ１０１で入力デバイス３０９から開始指示を受け取ったならば、ステップＳ１０２でネットワーク・インターフェイス３０１から自ホストの証明書を送信する。アドホック・モードで通信しているので、送信されたデータ（証明書）は電波の届く範囲に存在する他のホスト全てに受け取られる。図２の場合、ホスト２０２が送信したデータは、ホスト２０３、ホスト２０４、ホスト２０５に受け取られる。ホストは、この自ホストの証明書に、自ホストの存在を他ホストに知らせるためのデータを付加して、送信する。
【００３２】
ステップＳ１０３で、無線通信により他ホスト（ノード）を検出し、他ホストの証明書を受信する。ホストは、ステップＳ１０３の処理を所定時間の間、行なう。各ホストは、この所定時間の間に、他のホストが、自ホストを検出できるように、ステップＳ１０１の開始指示を行なう。会議鍵を共有するホストのうち、最初に自ホストの証明書を送信したホスト以外のホストでは、ステップＳ１０２での自ホストの証明書の送信と、ステップＳ１０３での他ホストの検出、他ホストの証明書の受信は、順序が逆になる。
【００３３】
また、ステップＳ１０２での自ホストの証明書の送信と、ステップＳ１０３での他ホストの検出は、逆でもよい。逆にした形態では、ステップＳ１０１での開始指示があると、所定時間の間、他ホストを検出するための処理を行ない、その後、自ホストの証明書を送信すると共に、他ホストの証明書を受信する。他ホストを検出するための処理では、例えば、他ホストに応答信号を要求する要求信号を送信し、応答信号を受信して、応答信号を送信した他ホストを検出する。
【００３４】
受け取った他ホストの証明書の正当性を認証局の公開鍵を用いてステップＳ１０４で確認する。ここで、公開鍵証明書に基づいてホストあるいはユーザの識別を行なう。ステップＳ１０５で、正当性が確認された公開鍵証明書を送ってきたホストの情報（公開鍵証明書に含まれている）とその総数をディスプレイ３０２に表示する。ここでは自ホストの情報も表示に含める。
【００３５】
ホストの情報としては、そのデータリンク識別情報（ＭＡＣアドレス）やネットワーク識別番号（ＩＰｖ６アドレス）、ユーザの名前（証明書の持ち主の名前）が表示できる。前述したＸ．５０９ｖ３の公開鍵証明書の場合、そのオプションにホストの種類、例えば製造者名と機種名称を含めておけば、それも表示できる。
【００３６】
さらに、ホストのデータリンク識別番号あるいはネットワーク識別番号をも証明書に含める形態では、証明書を運んできたパケットの送信元のデータリンク識別番号あるいはネットワーク識別番号と比較することにより、データの送信元を偽って偽の証明書を相手に受け取らせるような攻撃を防ぐことも可能となる。
【００３７】
ステップＳ１０５で表示する内容として（自ホストも含む）総数が重要である。事前に指示がない限り、ホストにとって、検出された他ホストがこれから通信すべきホストなのか、あるいは関係のないホスト（会議鍵共有プロトコルに紛れ込んで盗聴を試みるホスト）なのかを判断できない。その場での通信相手とホストの状況を把握して判断できるのはユーザなので、ユーザがホストに指示を与えなければならない。証明書に含まれるユーザの名前も表示されるので、データリンク識別番号あるいはネットワーク識別番号だけが表示される場合に比べて人間にとって理解しやすくなっているが、表示されているホストの情報の全てをユーザ全員が見て、確認するとは限らない。
【００３８】
それに対して、その場にあるホストを視認して総数を数え、表示と一致していることを確認することは簡単であり、その場のユーザ同士で声を出して確認することや総数の不一致の検出も容易である。
【００３９】
また、例えばユーザの名前をアルファベット順でソートし、その順に各ホストに番号を振り、自ホストには目印を表示する形態では、どのホストにおいても同じ順の番号が振られ、どのホストが何番かを確認してその情報を共有することも容易になる。すなわち、総数を確認し、ホストと番号の対応関係を確認することで、盗聴者のホストが会議鍵共有プロトコルに紛れ込もうとする攻撃を確実に検出できる。
【００４０】
ステップＳ１０６で、表示をしながらユーザからのＯＫの入力を待つ。ホスト２０２のディスプレイ３０２において、ホスト２０３、２０４の情報、及び、総ホスト数“３”（ホスト２０２を含む）が表示された場合には、ユーザはＯＫを入力する。また、ホスト２０３、２０４、２０５の情報、及び、総ホスト数“４”が表示された場合には、ユーザはＮＧを入力する。ＯＫの入力がなくタイムアウトが発生しない間は表示をしながらユーザからのＯＫの入力を待つ（ステップＳ１０９のいいえ）。ユーザからＮＧの入力を受け取った、あるいはタイムアウトが来たら（ステップＳ１０９のはい）、異常終了する。ユーザは、入力デバイス３０９からＯＫまたはＮＧを入力する。
【００４１】
ユーザからＯＫの入力を受け取った（ステップＳ１０６のはい）ならば、ネットワーク・インターフェイス３０１を用いて、それらのホストとの間で、公開鍵暗号に基づく会議鍵共有プロトコルをステップＳ１０７で実行する。この会議鍵共有プロトコルの詳細は後で述べる。この会議鍵共有プロトコルを実行するためには、正当性が確認された全てのホストにおいて、ＯＫが入力される必要がある。会議鍵共有プロトコルを実行したら、共有した会議鍵の検証をステップＳ１０８で実行し、正常終了する。
【００４２】
以上のように、本形態では、アドホック・モードによる無線通信ネットワーク２０１に接続可能なホストは、無線通信により他のホストを検出し、公開鍵証明書に基づいてホストあるいはユーザの識別を行なう。例えば、ホスト２０２は、正当な公開鍵証明書の情報と総数を表示し、ユーザが確認すると、他のホスト２０３、２０４との間で、公開鍵暗号に基づく会議鍵共有プロトコルを実行する。以降、ホスト２０２、２０３、２０４は、共有した会議鍵を用いて、暗号通信を行なう。
【００４３】
会議鍵共有プロトコルは、公開鍵暗号に基づく、任意の安全なプロトコルを採用できる。公開鍵証明書に基づく公開鍵暗号あるいはディジタル署名と、会議鍵共有プロトコルと、共有した会議鍵の検証方法は、それぞれ複数の方式が存在するので、それらの方式とその組み合わせの個数の実現方法がある。本実施の形態では、ホスト２０２（を所有または使うユーザ）の公開鍵証明書にはディジタル署名用の公開鍵が記載されているものとし、前述のＭｉｋｅ　ＢｕｒｍｅｓｔｅｒとＹｖｏ　Ｄｅｓｍｅｄｔによる論文、Ａ　ｓｅｃｕｒｅ　ａｎｄ　ｅｆｆｉｃｉｅｎｔ　ｃｏｎｆｅｒｅｎｃｅ　ｋｅｙ　ｄｉｓｔｒｉｂｕｔｉｏｎ　ｓｙｓｔｅｍ、　Ａｄｖａｎｃｅｓ　ｉｎ　Ｃｒｙｐｔｏｌｏｇｙ−ＥＵＲＯＣＲＹＰＴ‘９４（ＬＮＣＳ　９５０）、Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ、ｐｐ．２７５−２８６、１９９５の３．３で述べられているＡＢｒｏａｄｃａｓｔ
Ｓｙｓｔｅｍを会議鍵共有プロトコルとして採用し、ステップＳ１０８で実行する共有した会議鍵の検証にＩＰｓｅｃを利用する場合を説明する。
【００４４】
ｎ個のホストをＵ＿１、Ｕ＿２、．．．、Ｕ＿ｎと表わし、それぞれが使う変数には対応する添字をつける。ＡＢｒｏａｄｃａｓｔ　Ｓｙｓｔｅｍでは各ホストが行なう処理は同一なので、Ｕ＿ｉを主語にして記述する。Ｕ＿０＝Ｕ＿ｎとする。整数Ａ、Ｂ、Ｃに対して、Ａ＾Ｂ　ｍｏｄ　ＣはＡをＢ乗した結果をＣで割った余りを意味する。各ホストが共通で用いる素数をｐ、ｑとし、Ｚｐ＝｛０、１、．．．、ｐ−１｝のある要素をｇ、ただしｇの指数はｑとする。
【００４５】
（Ｓｔｅｐ　１）Ｕ＿ｉは、乱数ｒ＿ｉをＺｑ＝｛０、１、．．．、ｑ−１｝からランダムに選び、ｚ＿ｉを計算し、ディジタル署名用の公開鍵を用いて、ｚ＿ｉに対するディジタル署名を生成し、ｚ＿ｉとそれに対するディジタル署名を他のホストに送る。
【００４６】
ただし、ｚ＿ｉ＝ｇ＾（ｒ＿ｉ）ｍｏｄ　ｐである。
【００４７】
（Ｓｔｅｐ　２）Ｕ＿ｉは、他の（ｎ−１）個のホストＵ＿ｊから送られてきたｚ＿ｊとディジタル署名の対応が正しいか否かを、Ｕ＿ｊの公開鍵証明書に記載されたディジタル署名用の公開鍵を用いて確認する。本形態では、他のホストＵ＿ｊの公開鍵証明書は、ステップＳ１０３で受信されている。全て正しいならば、Ｕ＿ｉはｘ＿ｉを計算し、それを他のホストに送る。
【００４８】
ただし、ｘ＿ｉ＝（ｚ＿（ｉ＋１）／ｚ＿（ｉ−１））＾（ｒ＿ｉ）ｍｏｄ　ｐである。なお、ｚ＿（ｉ＋１）は、ホストＵ＿（ｉ＋１）から、ｚ＿（ｉ−１）は、ホストＵ＿（ｉ−１）から送られてきた計算結果である。
【００４９】
（Ｓｔｅｐ　３）Ｕ＿ｉは、他の（ｎ−１）個のホストからｘ＿ｊを受け取り、Ｋ＿ｉを計算する。
【００５０】
ただし、Ｋ＿ｉ＝（ｚ＿（ｉ−１））＾（ｎ＊ｒ＿ｉ）＊（ｘ＿（ｉ））＾（ｎ−１）＊（ｘ＿（ｉ＋１））＾（ｎ−２）＊．．．＊ｘ＿（ｉ−２）ｍｏｄ　ｐである。ｚ＿（ｉ−１）は、ホストＵ＿（ｉ−１）から、ｘ＿（ｉ＋１）は、ホストＵ＿（ｉ＋１）から送られてきた計算結果である。
【００５１】
（Ｓｔｅｐ　４）Ｕ＿ｉは、Ｋ＿ｉをｐｒｅ−ｓｈａｒｅｄ　ｋｅｙとして用いてＩＰｓｅｃのＥＳＰ（ｅｎｃａｐｓｕｌａｔｉｉｎｇ　ｓｅｃｕｒｉｔｙ　ｐａｙｌｏａｄ）プロトコル（ＩＰパケットの暗号化プロトコル）を他の（ｎ−１）個のホストと実行する。ペイロードデータには、送信元アドレス（Ｕ＿ｉ）と宛先アドレス、ｐｒｅ−ｓｈａｒｅｄ　ｋｅｙ（Ｋ＿ｉ）を含める。
【００５２】
（Ｓｔｅｐ　５）Ｕ＿ｉは、他の（ｎ−１）個のホストから送られてきたデータを、Ｋ＿ｉをｐｒｅ−ｓｈａｒｅｄ　ｋｅｙとして用いて復号し、送信元アドレス（Ｕ＿ｊ）と宛先アドレス（Ｕ＿ｉ）、ｐｒｅ−ｓｈａｒｅｄ　ｋｅｙ（Ｋ＿ｉ）が含まれており、かつそれらが正当な値であることを確認する。
【００５３】
このＫ＿ｉが、各ホストで共有される会議鍵である。
【００５４】
なお、上式を展開して変形すればＫ＿ｉ＝ｇ＾（ｒ＿１＊ｒ＿２＋ｒ＿２＊ｒ＿３＋．．．＋ｒ＿ｎ＊ｒ＿１）ｍｏｄ　ｐとなっていることが確認できる。
【００５５】
（第２の実施の形態）
第１の実施の形態では、各ホストが全く同じ処理をする対称な方法であった。本実施の形態では、１台のホストが特別な役割を果たし、残りの他のホストは同じ処理を行なう、非対称な方法を説明する。
【００５６】
特別なホストを特別ホスト、残りの他のホストを一般ホストと呼ぶことにする。本実施の形態におけるアドホック会議鍵共有プログラムの動作を図４と図５のフローチャートを参照して説明する。図４は特別ホストのＣＰＵ３０１の動作を、図５は一般ホストのＣＰＵ３０１の動作を表わしたものである。
【００５７】
図４に示すように、特別ホストのアドホック会議鍵共有プログラムは起動されると、開始指示を受け取るまで待機する。ステップＳ４０１で入力デバイス３１０から開始指示を受け取ったならば、ステップＳ４０２でネットワーク・インターフェイス３０１から自ホストの証明書を送信する。この送信の際に、自ホストが特別ホストであるとの宣言データも一緒に送信する。ステップＳ４０３で、無線通信により他ホスト（ノード）を検出し、他ホストの証明書を受信する。
【００５８】
ある形態では、ネットワーク・インターフェイス３０１から他のホストを検出するための問合せ信号を送信し、他のホストがその問合せ信号に応答して送信した応答信号をネットワーク・インターフェイス３０１で受信する。また、ある形態では、問合せ信号に、自ホストの証明書及び自ホストが特別ホストであるとの宣言データを含め、応答信号に他ホストの証明書を含める。なお、問合せ信号を送信したホストが特別ホストであるという規則が定められている形態では、問合せ信号に自ホストが特別ホストであるとの宣言データは含める必要はない。他の形態では、応答信号を送信した他ホストに（又は、不特定の相手へのブロードキャストとして）、ネットワーク・インターフェイス３０１から、自ホストの証明書及び自ホストが特別ホストであるとの宣言データを送信し、また、応答信号を送信した他ホストに、他ホストの証明書の送信を要求する。なお、問合せ信号を送信したホストが特別ホストであるという規則が定められている形態では、自ホストが特別ホストであるとの宣言データは必要ない。
【００５９】
受け取った他ホストの証明書の正当性を認証局の公開鍵を用いてステップＳ４０４で確認する。ここで、公開鍵証明書に基づいてホストあるいはユーザの識別を行なう。
【００６０】
ステップＳ４０５で、正当性が確認された証明書を送ってきたホストの中の１台の公開鍵証明書の情報をディスプレイ３０２に表示する。その証明書が、会議鍵を共有しようとしているホストの中の１台の証明書であることが確認できたならば、特別ホストのユーザがＯＫの入力をするので、プログラムはステップＳ４０６でその入力を待つ。ＯＫの入力がなくタイムアウトが発生しない間は表示をしながらユーザからのＯＫの入力を待つ（ステップＳ４１１のいいえ）。ユーザからＮＧの入力を受け取った、あるいはタイムアウトが来たら（ステップＳ４１１のはい）、異常終了する。ユーザは、入力デバイス３０９からＯＫまたはＮＧを入力する。
【００６１】
ユーザからＯＫの入力を受け取った（ステップＳ４０６のはい）ならば、ステップＳ４０７で、そのホストとの間で二者間鍵共有を行なう。ある形態では、この一般端末と二者間で暗号通信を行なう場合、特別ホストは、この二者間鍵共有で共有した共有鍵を用いて、暗号通信を行なう。
【００６２】
この鍵共有は、例えば公開鍵証明書とＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送法を組み合わせた通信相手の認証も行なえる方法であるとする。具体的には、第１の実施の形態と同じ数学的設定として、二者はそれぞれ乱数ｒを生成して　ｚ＝ｇ＾ｒ　ｍｏｄ　ｐ　を計算し、ｚに対するディジタル署名を生成して、ｚとその署名を通信相手に送る。通信相手から受け取ったｚとその署名の対応が正しいことを公開鍵証明書の公開鍵で確認して、相手から受け取ったｚと自分が生成した乱数ｒからＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送法に基づく共有鍵を求める。
【００６３】
ステップＳ４０４で正当性を確認したが表示していないホストの証明書が存在するならば（ステップＳ４０８のいいえ）、そのホスト（の中の１台）についてステップＳ４０５、ステップＳ４０６、ステップＳ４０７を繰り返す。ステップＳ４０４で正当性を確認したホストの証明書の表示が全て終了したら、自ホスト（特別ホスト）を含むホストの総数を表示して、ユーザからの確認終了の入力をステップＳ４０８で待つ。以上のステップＳ４０５からステップＳ４０８までの処理の繰り返しにおける任意の時点で確認終了が入力されることがあり、かつＮＧも入力されうる。いずれのタイミングにせよ、ＮＧの入力を受け取ったならば（ステップＳ４１１のはい）、異常終了する。
【００６４】
ステップＳ４０８（もしくはステップＳ４０５からステップＳ４０８までの処理の繰り返しにおけるある時点）で、入力デバイス３０９から確認終了の入力があったならば、それまでに二者間鍵共有プロトコルを行なったホストと特別ホストの間で、公開鍵暗号に基づく会議鍵共有プロトコルを実行し（ステップＳ４０９）、ステップＳ４１０で、共有した会議鍵の検証を行なう。例えば、第１の実施の形態で述べた方法でもよいし、他の方法でもよい。
【００６５】
図５に示すように、一般ホストのアドホック会議鍵共有プログラムは起動されると、開始指示を受け取るまで待機する。ステップＳ５０１で開始指示を受け取ったならば、ステップＳ５０２でネットワーク・インターフェイス３０１から自ホストの証明書を送信する。一般ホストは、この自ホストの証明書に、自ホストの存在を他ホストに知らせるためのデータを付加して、送信する。ある形態では、特別ホストの証明書を受信すると、ステップＳ５０１の開始指示を受け取ったものとして、ステップＳ５０２進み、自ホストの証明書を送信する。一般ホストは、特別ホストの証明書に付加されている特別ホストの宣言データを受信すると、特別ホストの存在を検出する。他の一般ホストも、同様に、自ホストの証明書を送信するので、ステップＳ５０３で他ホストを検出し、他ホストの証明書を受信する。ステップＳ５０２における自ホストの証明書の受信と、ステップＳ５０３における他ホストの検出、他ホストの証明書の受信は、順番が逆になる場合もある。
【００６６】
受け取った他ホストの証明書の正当性を認証局の公開鍵を用いてステップＳ５０４で確認する。ステップＳ５０５で、自ホストを含むホストの総数を表示し、特別ホストと二者間鍵共有を行なう。この二者間鍵共有は、特別ホストが図４のステップＳ４０７で行なう二者間鍵共有に対応する。ある形態では、この一般ホストは、特別ホストと暗号通信を行なう場合、この二者間鍵共有で共有された共有鍵を用いて、暗号通信を行なう。
【００６７】
ステップＳ５０６で会議鍵共有プロトコルを実行し、ステップＳ５０７で共有した会議鍵の検証を実行する。このステップＳ５０６の会議鍵共有プロトコルは、特別ホストが図４のステップＳ４０９で行なう会議鍵共有プロトコルに対応する。ある形態では、会議鍵共有プロトコルとして、第１の実施の形態で述べた方法を採用するが、特別ホストが会議鍵共有プロトコルの（Ｓｔｅｐ１）を実行して送信したｚ＿ｉとディジタル署名を受信すると、会議鍵共有プロトコルの（Ｓｔｅｐ１）を実行する。以上の過程においてエラーがあった場合は（ステップＳ５０８のいいえ）、異常終了する。エラーが無かった場合は（ステップＳ５０８のはい）、正常終了する。
【００６８】
以降、会議通信を行なう場合、特別ホスト、一般ホストは、共有した会議鍵を用いて、暗号通信を行なう。
【００６９】
本実施の形態においても、第１の実施の形態と同様に、会議鍵共有プロトコルとしては、公開鍵暗号に基づく、任意の安全な方式を採用でき、公開鍵証明書に基づく公開鍵暗号あるいはディジタル署名と、会議鍵共有プロトコルと、共有した会議鍵の検証方法は、それぞれ複数の方式が存在するので、それらの方式とその組み合わせの個数の実現方法がある。
【００７０】
特に、特別ホストがプロジェクタのように同一の情報をその場の参加者全員（特別ホストのユーザと一般ホストのユーザ）に視認可能にする装置であり（あるいは、入出力インターフェイスにプロジェクタが接続された装置であり）、証明書に記載されている情報をスクリーンに投影する形態では、その場の全員で確認することが可能であり、一人のみが確認する場合に比べて信頼性が増す。しかも、このような特別ホストが１台あれば、ディスプレイや入力デバイスが使いにくい他の一般ホストがネットワークに参加する場合に、使いにくいディスプレイや入力デバイスの使用を避けることができ、操作性の優れたネットワークへの参加方法を提供できる。
【００７１】
しかも、本実施の形態では特別ホストと一般ホストそれぞれとの間で二者間鍵共有をも行なうので（ステップＳ４０７、Ｓ５０５）、ある一般ホストが、表示を見せるのはかまわないが、他のホスト（ユーザ）にはデータとしては渡したくない内容がある場合に、二者間で共有した鍵を用いて、その一般ホストが特別ホストであるプロジェクタとの間の暗号化した通信路を利用することが可能であり、プロジェクタを特別ホストとして機能させると有効である。
【００７２】
（第３の実施の形態）
第１の実施の形態と第２の実施の形態では、少なくとも一人のユーザが必ず（他のホストを所有あるいは使用するユーザの）証明書の正しさを一つ一つ確認していた。この方法は、事前に打ち合わせをしておけない相手、例えば初対面の相手を含めた参加者の間で会議鍵を共有する場合に有効であった。これに対し、事前に打ち合わせをしておける相手、例えば、同じ会社の社員や同じ部署の同僚、大学の研究室やサークルの仲間のような、所属先が共通な参加者の間で会議鍵を共有したい場合に有効な形態を説明する。
【００７３】
本実施の形態では、公開鍵証明書の中に所属先名称を含める。商用の認証局の代りに所属先組織の内部で管理・運営している私設認証局を用いる例を説明する。ある部署のリーダーが管理する認証局が、その部署の構成員それぞれに対して、部署の名称と構成員の名前を含む公開鍵証明書を発行する。
【００７４】
各ホストのＣＰＵ３０３において動作するアドホック会議鍵共有プログラムの動作を図６のフローチャートを参照して説明する。
【００７５】
プログラムは、起動されると開始指示を受け取るまで待機する。開始指示の際には、部署の名称が入力され、その部署の構成員との会議鍵を共有する指示がプログラムに与えられる。ステップＳ６０１で入力デバイス３０９から部署名称と開始指示を受け取ったならば、ステップＳ６０２でネットワーク・インターフェイス３０１から自ホストの証明書を送信する。ホストは、この自ホストの証明書に、自ホストの存在を他ホストに知らせるためのデータを付加して、送信する。
【００７６】
ステップＳ６０３で、無線通信により他ホスト（ノード）を検出し、他ホストの証明書を受信する。ホストは、ステップＳ６０３の処理を所定時間の間、行なう。各ホストは、この所定時間の間に、他のホストが、自ホストを検出できるように、ステップＳ６０１の開始指示を行なう。会議鍵を共有するホストのうち、最初に、自ホストの証明書を送信したホスト以外のホストでは、ステップＳ６０２での自ホストの証明書の送信と、ステップＳ６０３での他ホストの検出、他ホストの証明書の受信は、順序が逆になる。
【００７７】
また、ステップＳ６０２での自ホストの証明書の送信と、ステップＳ６０３での他ホストの検出は、逆でもよい。逆にした形態では、ステップＳ６０１での開始指示があると、所定時間の間、他ホストを検出するための処理を行ない、その後、自ホストの証明書を送信すると共に、他ホストの証明書を受信する。他ホストを検出するための処理では、例えば、他ホストに応答信号を要求する要求信号を送信し、応答信号を受信して、応答信号を送信した他ホストを検出する。
【００７８】
受け取った他ホストの証明書の正当性を認証局の公開鍵を用いてステップＳ６０４で確認する。ここで、公開鍵証明書に基づいてホストあるいはユーザの識別を行なう。本実施の形態においては、受け取った証明書の中に含まれる部署の名称が、開始指示の際に入力された部署の名称と一致しているか否かの確認も正当性の確認に含まれる。また、他の形態では、ステップＳ６０１において、部署に所属し、その会議に参加する人数（又は、ホストの数）を入力し、ステップＳ６０４において、部署の名称と、人数（又は、ホストの数）を確認する。あるいは、部署の名称の代わりに、人数（又は、ホストの数）を確認する。
【００７９】
ステップＳ６０５で、正当性が確認された証明書を送ってきたホストの情報とその総数と所属先名称を表示する。ここでは自ホストの情報も表示に含める。
【００８０】
ステップＳ６０６で、それらのホストとの間で、公開鍵暗号に基づく会議鍵共有プロトコルを実行する。会議鍵共有プロトコルを実行したら、共有した会議鍵の検証をステップＳ６０７で実行し、正常終了する。例えば、第１の実施の形態で述べた方法でもよいし、他の方法でもよい。以降、ホスト２０２、２０３、２０４は、共有した会議鍵を用いて、暗号通信を行なう。
【００８１】
第１の実施の形態、第２の実施の形態と異なり、本実施の形態ではユーザが他のホストの証明書の情報を確認するステップは設けられていない。しかし、ステップＳ６０１で部署名称が入力されているので、その部署に所属していない相手が会議鍵共有プロトコルに紛れ込むことはない。
【００８２】
【発明の効果】
以上説明したように、本出願に関わる発明によれば、盗聴に対して安全な、アドホック・モードによる三者以上での会議鍵共有を、ユーザの利便性を損なわずに行なえる。公開鍵証明書に記載されている名称と証明書の総数を表示してホストを識別するので、参加させてはいけないノードを検出することがユーザにとって容易である。
【００８３】
ディスプレイが必ずしも見易いものでなくても、その場のホストの総数を各ユーザが確認するだけで盗聴者（ホスト）がネットワークにまぎれこむことを検出できる。見易いディスプレイが全てのホストに搭載されている場合は、全てのホストのユーザが他のホストのユーザの証明書情報を容易に確認できるので、さらに安心感が増す。
【００８４】
プロジェクタのように多人数で情報を共有できるホストが存在する場合は、複数のユーザが同一の情報を視認して確認できるので、信頼性と利便性はさらに高い。
【００８５】
事前に所属先名称を証明書に含めておけば、所属先が同一の相手との会議鍵共有を実行することが可能であり、ユーザが判断する処理を無くすことができる。
【００８６】
公開鍵暗号に基づく任意の会議鍵共有プロトコルを利用できるので、装置が鍵更新を実行可能であり、ユーザが毎回鍵を設定する負担が無い。また、プログラムが鍵の生成を行なうので、ユーザがいちいち会議鍵を設定する場合と比べて鍵の紛失や横流しが起る可能性は小さくなり、安全性が高い。
【図面の簡単な説明】
【図１】第１の実施の形態におけるホストの動作を説明するフローチャートである。
【図２】想定環境の模式図である。
【図３】ノードの構成である。
【図４】第２の実施の形態における特別ホストの動作を説明するフローチャートである。
【図５】第２の実施の形態における一般ホストの動作を説明するフローチャートである。
【図６】第３の実施の形態における同一所属ホストの動作を説明するフローチャートである。
【符号の説明】
２０１　アドホック・モードによる無線通信ネットワーク
２０２　ホスト
２０３　ホスト
２０４　ホスト
２０５　ホスト
【図１】
2004072470.tif 000003
【図２】
2004072470.tif 000004
【図３】
2004072470.tif 000005
【図４】
2004072470.tif 000006
【図５】
2004072470.tif 000007
【図６】
2004072470.tif 000008