共通鍵自動配布システム、クライアント、第三者認証機関側サーバ、及び共通鍵自動共有方法
【課題】各メンバが自由に共通鍵の生成・更新・削除を行うことができ、共通鍵の管理者およびメンバによる特別な操作なく予め許可した範囲内で自動的に共通鍵を配信することができる共通鍵自動配布システム、クライアント、第三者認証機関側サーバ、及び共通鍵自動共有方法を提供する。
【解決手段】共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、各クライアントの存在を保証する第三者認証機関側サーバとを備えた。
【解決手段】共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、各クライアントの存在を保証する第三者認証機関側サーバとを備えた。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、共通鍵自動配布システム、クライアント、第三者認証機関側サーバ、及び共通鍵自動共有方法に関する。
【背景技術】
【０００２】
ファイルの内容をセキュアに保つため、一般にファイルの暗号化が行われている。
しかし、暗号化されたファイルをグループやプロジェクト内など、ある範囲で共有するためには、暗号化ファイルを共有するメンバ内で暗号化に使用した鍵を事前に共有する必要がある。
さらに、この暗号化に使用される鍵は、随時必要に応じて、新規に追加されたり、更新されたり、あるいは削除される。
このように、ファイルの暗号化に使用する鍵の運用を行う場合、新規生成、更新、削除などが行われるごとに、全てのメンバに対して反映する必要がある。
現状としては、このようなファイルの暗号化に使用する鍵（以下、共通鍵と記載）の運用については、以下の方式が考えられる。
【０００３】
○サーバを経由して配布する方式
本方式では、共通鍵をサーバに格納し、予め定められたスケジュールに基づき、クライアント側へ共通鍵を配布するか、クライアント側が任意のタイミング(PC起動時など)にサーバへアクセスして共通鍵を取得する方法が考えられる。
しかし、本方式では、共通鍵をサーバで一括管理するため、共通鍵の生成、配布はサーバ管理者に依存することになり、メンバが目的に合わせて自由に共通鍵を生成、更新、削除することが困難となる。
また、本方式では、共通鍵をサーバで一元管理しているため、サーバにアクセスできない状況では、メンバは共通鍵の取得ができなくなる。
【０００４】
○共通鍵をファイル形式で出力し、メールやファイルサーバなど経由して配布する方式
本方式では、共通鍵の管理者が共通鍵をファイル形式でエクスポートし、メンバに対してエクスポートしたファイルをメールやファイルサーバ経由で配布する。メンバはメールやファイルサーバ経由でファイルを入手し、入手したファイルをインポートすることで、共通鍵を取り込む。
本方式では、管理者、メンバともに手動での操作 （エクスポート−配布−入手−インポート）が必要となり、運用が煩雑になりやすい。また、この方式の場合、配布済みの共通鍵を削除するには、メンバに手動で削除するよう依頼する必要がある。
【０００５】
この他、共通鍵自動共有に関連する技術が特許文献１〜７に記載されている。
特許文献１に記載のグループ暗号方法は、通信網によって相互に接続された複数の端末と当該複数の端末からアクセス可能な記憶装置とを備え、複数の端末により複数のユーザによって共有される記憶装置上の情報の暗号化を行うグループ暗号方法であって、端末は、演算機能を備えた記憶媒体を接続可能とし、当該記憶媒体は予めユーザに配布され当該記憶媒体の所有者のユーザ識別情報およびマスタ鍵と呼ばれる秘密数値を記憶し、記憶装置への、任意の一つの端末からの情報の書き込みは、書き込む情報の開示先を示すユーザ識別情報のリストである宛先リストを生成すると共に、当該宛先リストを前記端末から当該端末に接続された記憶媒体に送信するステップと、記憶媒体において、受信した宛先リストが示す条件に当該記憶媒体内に記憶したユーザ識別情報が合致するか否かを検査するステップと、当該検査ステップにより、受信した宛先リストが示す条件に記憶媒体内のユーザ識別情報が合致する場合は、宛先リストと記憶媒体内に記憶したマスタ鍵とに基づいてグループ鍵を生成して端末に返送するステップと、端末において、データ鍵と呼ぶ乱数を生成し、当該データ鍵を用いて平文を暗号化して暗号文を生成するステップと、記憶媒体より返送されたグループ鍵を用いてデータ鍵を暗号化して暗号文鍵を生成するステップと、暗号文鍵、宛先リスト、および暗号文を、記憶装置に書き込むステップとにより行うものである。
【０００６】
このグループ暗号方法によれば、暗号者が作成した宛先リストと、復号者のＩＣカードに格納されたユーザ識別情報とを照合し、復号者が該宛先リストが示す条件に合致するかどうかにより、暗号文を復号化できるかどうかが決まる。暗号者が宛先リストに自分自身のみを指定すれば、その暗号者だけが復号化できることになり、また、複数のユーザを指定すれば、それら指定されたユーザだけが復号化できることになる。したがって、暗号者は個人的な情報と複数のユーザによって共有される情報とを同じように暗号化できるとしている。
【０００７】
特許文献２に記載のファイルの暗号化方法は、送信者側のコンピュータから１乃至複数の受信者側のコンピュータに送信されるファイルの暗号化方法において、送信者側のコンピュータが、共通鍵を用いてファイルを暗号化するステップと、認証機関のコンピュータに、所定のグループ毎に暗号化に用いた共通鍵の利用権限を設定登録するステップと、パスワードベースの暗号を用いて共通鍵を暗号化するステップと、暗号化したファイルと暗号化した共通鍵を１乃至複数の受信者側のコンピュータに送信するステップとを有するものである。
【０００８】
このファイルの暗号化方法によれば、パスワード方式とグループ鍵共有方式の双方の特徴を利用することにより、これらの利点を併せ持つグループ暗号を実現することができる。すなわち、暗号化ファイルを生成する毎にまたはグループを構成する毎にパスワードを発行する必要がなく、パスワードやグループ鍵の管理を非常に簡易にすることができるとしている。
【０００９】
特許文献３に記載の暗号鍵更新システムは、暗号化と復号とに同一の暗号鍵を用いる共通鍵方式によりデータを暗号化および復号しながら複数の装置が互いにデータを送受信する通信システムの暗号鍵更新システムであって、各装置が、複数の暗号鍵が記された電子的な暗号鍵リストを保持するリスト保持手段と、予め定められた規則に基づき、リスト保持手段に保持された暗号鍵リストに記される複数の暗号鍵の中から１つ以上の暗号鍵を選択する選択手段とを具備したものである。
【００１０】
この暗号鍵更新システムによれば、たとえば１年分の暗号鍵をすべての装置に予め配布しておき、各装置が、これらの中から暗号化および復号に用いる暗号鍵を他の装置と同じ規則で選択するようにしたため、その結果として、すべての装置が同期を取って暗号鍵を自動的に更新することが可能となり、ユーザに暗号鍵の入力や設定等の煩わしい作業を行わせることがないとしている。
【００１１】
特許文献４に記載の情報配信システムは、クライアントに受信済みの情報のバージョンをサーバに送信し、サーバ側で管理しているバージョンの情報構成リストと最新バージョンの情報との差異を抽出して更新部分だけを配信する、あるいは、クライアントから情報の構成を示す情報を送信し、サーバ側で比較することにより差異を抽出して更新部分だけを配信するものである。
【００１２】
この情報配信システムによれば、頻繁に更新される情報を多数の異なるバージョンを持つクライアントへ効率良く確実に配信することができるとしている。
【００１３】
特許文献５に記載の暗号通信路の確立方法は、第１の装置と第２の装置の間で共通鍵を用いて暗号化したメッセージを暗号通信するための暗号通信路の確立方法であって、第１の装置は、第１の装置に関連した第１の公開鍵、第１の公開鍵の証明情報、及び、第１の乱数を第２の装置へ送付し、第２の装置は第１の公開鍵の証明情報が真正であることを検証し、第２の装置は、第２の装置に関連した第２の公開鍵、第２の公開鍵の証明情報、及び、第２の乱数を第１の装置へ送付し、第１の装置は第２の公開鍵の証明情報が真正であることを検証する鍵情報交換手順と、第１の装置は、暗号通信路を確立するための共通鍵を生成し、共通鍵を第２の公開鍵を用いて暗号化し、暗号化された共通鍵を第２の装置へ送付し、第２の装置は暗号化された共通鍵を第２の公開鍵に対応した第２の秘密鍵で復号化する鍵共有手順と、第１の装置は、第２の乱数及び共通鍵のペアを攪拌し、第１の公開鍵に対応した第１の秘密鍵を用いて攪拌されたペアから第１の署名情報を作成し、第２の装置へ送付し、第２の装置は第１の署名情報を第１の公開鍵を用いて検証し、第２の装置は、第１の乱数及び共通鍵のペアを攪拌し、第２の公開鍵に対応した第２の秘密鍵を用いて攪拌されたペアから第２の署名情報を作成し、第１の装置へ送付し、第１の装置は第２の署名情報を第２の公開鍵を用いて検証する相互認証手順と、を有するものである。
【００１４】
この暗号通信路の確立方法によれば、装置間で公開鍵証明書及びチャレンジデータを交換するための２回のコマンドと、装置間でセクション鍵を共有するためのコマンドと、装置間で相互認証を行うコマンドとを実行することにより、暗号通信を行う装置間で、最小限の通信回数と処理時間で、相互認証を行い、安全な暗号通信路を確立することができるとしている。
【００１５】
特許文献６に記載の利用者情報の分散管理装置は、信頼できるピアから構成される信頼グループによるコミュニティにおける利用者情報の分散管理装置であって、コミュニティを構成する各ピアは、信頼グループ機能部とコミュニケーション機能部からなるコミュニティサービス装置を備え、信頼グループ機能部は信頼グループ管理手段とピア管理手段とログ解析手段と電子証明書生成手段を有し、コミュニケーション機能部は通信手段とログ管理手段と電子証明書管理手段を有し、信頼グループ管理手段は、他の信頼グループ管理手段と信頼グループの信頼できるピア情報の連絡を行い、信頼グループの信頼できるピア情報の一覧を管理し、電子証明書生成手段による電子証明書の発行のための共通鍵を信頼グループを構成する他の信頼できるピアと共有する機能を有し、ログ解析手段は、一般ピアから受信するログを解析し、不正がなければ、電子証明書生成手段に一般ピアへの電子証明書の発行を指示し、不正があれば、ピア管理手段に一般ピアの不正を通知する機能を有し、ピア管理手段は、ログ解析手段から、一般ピアの不正通知を受け、一般ピアの一般ピア一覧からの削除および不正ピア一覧への登録を行い、信頼グループ管理手段から宛先情報を得て、全ての他の信頼できるピアのピア管理手段に一般ピアの不正を通知し、信頼できるピアの管理する一般ピアに一般ピアの不正を通知する機能を有し、電子証明書生成手段は、ログ解析手段からの指示により、不正のない一般ピアに電子証明書およびコミュニティに共通で、電子証明書の解読に必要な公開鍵を発行する機能を有し、通信手段は、コミュニティの他の一般ピアとの通信のために、電子証明書管理手段から電子証明書を取得し、通信相手の他の前記一般ピアに送信し、通信相手から受信する電子証明書の正当性の判定を電子証明書管理手段に依頼する機能を有し、ログ管理手段は、信頼グループのピアのピア管理手段にログを定期的に送信し、電子証明書の更新要求を行う機能を有し、電子証明書管理手段は信頼グループのピアの電子証明書生成手段から電子証明書および電子証明書解読のための公開鍵を受信、管理し、電子証明書により通信相手の正当性を判定し、コミュニティへの一般ピアの新規参加のために参加要求を送信する機能を有するものである。
【００１６】
この利用者情報の分散管理装置によれば、信頼できるピアから構成される信頼グループによるコミュニティにおける利用者情報を分散管理することにより、利用者情報の管理に特定の設備を設ける必要がない、ログ解析による大規模なコミュニティにおける利用者の管理が可能、不正なピアをコミュニティから排除でき、コミュニティの安全性を維持することができる、利用者はコミュニティに安心して参加し、コミュニケーションを楽しむことができるとしている。
【００１７】
特許文献７に記載の通信ネットワークにおけるセキュリティは、通信リンクを介して、第１の通信装置と第２の通信装置との間にセキュリティ保護されたピアツーピア型の通信を確立する方法であって、各通信装置は、対応する通信装置と他の通信装置との間で事前に確立されたセキュリティアソシエーションのセットをそれぞれ格納しており、方法は、事前に確立されたセキュリティアソシエーションのセットにおいて共通のセキュリティアソシエーションを第１の通信装置及び第２の通信装置がそれぞれ有しているかを判定するステップと、第１の通信装置及び第２の通信装置が共通のセキュリティアソシエーションを有していると判定された場合、共通のセキュリティアソシエーションに基づいて第１の通信装置と第２の通信装置との間の通信リンクを保護し、一方で、共通のセキュリティアソシエーションを有していると判定されなかった場合、第１の通信装置と第２の通信装置との間に新しいセキュリティアソシエーションを確立して新しいセキュリティアソシエーションに基づき通信リンクを保護するステップと、保護された通信リンクを介して対応する鍵のデータを通信することにより、第１の通信装置及び第２の通信装置がそれぞれ有する事前に確立されたセキュリティアソシエーションのセットを、第１の通信装置及び第２の通信装置のうち対応する他方の通信装置に拡張するステップとを含むものである。
【００１８】
この通信ネットワークにおけるセキュリティによれば、２つの通信装置が通信リンクを介して初めて接続されるとき、これらの通信装置は、事前に確立された共通のセキュリティアソシエーションを有するかを判定する。事前に確立されたそのようなセキュリティアソシエーションが存在する場合、セキュリティアソシエーションは、２つの装置間の通信リンクを保護するための基礎として使用される。一方、セキュリティアソシエーションが存在しない場合、新しいセキュリティアソシエーション、好ましくは共有の秘密状態が、通信リンクを保護するために鍵交換プロトコルに基づいて確立される。鍵交換プロトコルは、パスワードによる認証を実行するプロトコルであることが好ましい。すなわち、少なくとも１つの装置にパスワードを入力するようにユーザに対して要求することが好ましい。その後、２つの装置は、それぞれ事前に確立されたセキュリティアソシエーションに関連付けられた鍵データを交換し、それにより、これらの事前のセキュリティアソシエーションを対応する他方の装置に拡張又は伝播する。その結果、各装置が他の装置とのセキュリティアソシエーションを確立しかつ他方の装置にセキュリティアソシエーションを伝播することを可能にするメカニズムが提供されるとしている。
【特許文献１】特開平１０−２６０９０３号公報
【特許文献２】特開２００５−２５２４４４号公報
【特許文献３】特開２００２−２９０３９６号公報
【特許文献４】再特ＷＯ２０００−０３３１９３号公報
【特許文献５】特開２００２−３３０１２５号公報
【特許文献６】特開２００６−１４８１９７号公報
【特許文献７】特表２００６−５２６３１４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１９】
しかしながら上述した技術では、鍵の更新の考慮がなく、サーバを必要とし、各メンバが自由に共通鍵の生成、更新、削除を行うことができず、共通鍵の管理者およびメンバによる特別な操作なく予め許可した範囲内で自動的に共通鍵を配信することができないという問題がある。
【００２０】
そこで、本発明の目的は、各メンバが自由に共通鍵の生成・更新・削除を行うことができ、共通鍵の管理者およびメンバによる特別な操作なく予め許可した範囲内で自動的に共通鍵を配信することができる共通鍵自動配布システム、クライアント、第三者認証機関側サーバ、及び共通鍵自動共有方法を提供することにある。
【課題を解決するための手段】
【００２１】
本発明のシステムは、共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、各クライアントの存在を保証する第三者認証機関側サーバとを備えたことを特徴とする。
【００２２】
本発明のクライアントは、共通鍵の生成、更新、削除、及び交換機能を有する複数のクライアントと、各クライアントに接続された第三者認証機関側サーバとを有する共通鍵自動共有システムに用いられるクライアントであって、各クライアントは、他のクライアントとの間でピアツーピア型の通信を行うことを特徴とする。
【００２３】
本発明の第三者認証機関側サーバは、共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、第三者認証機関側サーバとを有する共通鍵自動共有システムに用いられる第三者認証機関側サーバであって、第三者認証機関側サーバは、各クライアントの存在を保証することを特徴とする。
【００２４】
本発明の共通鍵自動共有方法は、ピアツーピア型の通信を用いて共通鍵の生成、更新、削除、及び交換を複数のクライアントが行い、各クライアントの存在を第三者認証機関側サーバが保証することを特徴とする。
【発明の効果】
【００２５】
本発明によれば、ピアツーピア型通信を用いた鍵交換を行うため、鍵交換、配信にサーバを必要としない。このため、クライアントが自由に共通鍵の作成・更新・削除を行うことができる。また、ピアツーピア型通信を用いた鍵交換および証明書を用いた本人確認を自動的に行うため、クライアントが意識することなく、所有することを許可されたメンバにのみ、鍵情報の交換・配信を行うことができる。
【発明を実施するための最良の形態】
【００２６】
［特 徴］
ファイルの暗号化に使用する共通鍵の配布において、鍵管理用サーバを使用せず、ピアツーピア型の通信で、予め定められた範囲に限定して自動的に配布可能とし、かつ、共通鍵の生成を各メンバで自由に行うことを可能とする。
【００２７】
本発明に係る共通鍵自動共有システムの一実施の形態は、共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、各クライアントの存在を保証する第三者認証機関側サーバとを備えたことを特徴とする。
【００２８】
上記構成によれば、ピアツーピア型通信を用いた鍵交換を行うため、鍵交換、配信にサーバを必要としない、このため、クライアントが自由に共通鍵の作成・更新・削除を行うことができる。また、ピアツーピア型通信を用いた鍵交換および証明書を用いた本人確認を自動的に行うため、クライアントが意識することなく、所有することを許可されたメンバにのみ、鍵情報の交換・配信を行うことができる。
【００２９】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、各クライアントは、公開鍵ペア及びクライアント情報を作成し、第三者認証機関側サーバに対して証明書の発行申請を行う証明書申請機能を有することを特徴とする。
【００３０】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、各クライアントは、第三者認証機関側サーバから返却された証明書及び公開鍵を登録する証明書登録機能を有することを特徴とする。
【００３１】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、各クライアントは、共通鍵の生成及び自ら生成した共通鍵の更新及び削除を行う鍵管理機能を有することを特徴とする。
【００３２】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、各クライアントは、共通鍵の配布対象の決定及び共通鍵交換要求の対象となるメンバ情報を登録するメンバ登録機能を有することを特徴とする。
【００３３】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、各クライアントは、メンバと互いに所有している共通鍵の交換を行う鍵交換機能を有することを特徴とする。
【００３４】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、各クライアントからの認証申請を受け付ける申請受付機能を有することを特徴とする。
【００３５】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、いずれかのクライアントから申請されたクライアント情報の真正性を確認する真正性確認機能を有することを特徴とする。
【００３６】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、各クライアントもしくは鍵に関する情報が正しいことを保証するために第三者認証機関側サーバ自身が持つ秘密鍵で署名を行い、証明書を作成する証明書作成機能を有することを特徴とする。
【００３７】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、署名したクライアント情報を、申請したクライアントに返却する証明書返却機能を有することを特徴とする。
【００３８】
本発明に係るクライアントの一実施の形態は、共通鍵の生成、更新、削除、及び交換機能を有する複数のクライアントと、各クライアントに接続された第三者認証機関側サーバとを有する共通鍵自動共有システムに用いられるクライアントであって、各クライアントは、他のクライアントとの間でピアツーピア型の通信を行うことを特徴とする。
【００３９】
本発明に係る第三者認証機関側サーバの一実施の形態は、共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、第三者認証機関側サーバとを有する共通鍵自動共有システムに用いられる第三者認証機関側サーバであって、第三者認証機関側サーバは、各クライアントの存在を保証することを特徴とする。
【００４０】
本発明に係る共通鍵自動共有方法の一実施の形態は、ピアツーピア型の通信を用いて共通鍵の生成、更新、削除、及び交換を複数のクライアントが行い、各クライアントの存在を第三者認証機関側サーバが保証することを特徴とする。
【００４１】
上記構成によれば、ピアツーピア型通信を用いた鍵交換を行うため、鍵交換、配信にサーバを必要としない。このため、クライアントが自由に共通鍵の作成・更新・削除を行うことができる。また、ピアツーピア型通信を用いた鍵交換および証明書を用いた本人確認を自動的に行うため、クライアントが意識することなく、所有することを許可されたメンバにのみ、鍵情報の交換・配信を行うことができる。
【００４２】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、各クライアントは、公開鍵ペア及びクライアント情報を作成し、第三者認証機関側サーバに対して証明書の発行申請を行うことを特徴とする。
【００４３】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、各クライアントは、第三者認証機関側サーバから返却された証明書及び公開鍵を登録することを特徴とする。
【００４４】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、各クライアントは、共通鍵の生成及び自ら生成した共通鍵の更新及び削除を行うことを特徴とする。
【００４５】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、各クライアントは、共通鍵の配布対象の決定及び共通鍵交換要求の対象となるメンバ情報を登録することを特徴とする。
【００４６】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、各クライアントは、メンバと互いに所有している共通鍵の交換を行うことを特徴とする。
【００４７】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、前記各クライアントからの認証申請を受け付けることを特徴とする。
【００４８】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、いずれかのクライアントから申請されたクライアント情報の真正性を確認することを特徴とする。
【００４９】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、各クライアントもしくは鍵に関する情報が正しいことを保証するために第三者認証機関側サーバ自身が持つ秘密鍵で署名を行い、証明書を作成することを特徴とする。
【００５０】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、署名したクライアント情報を、申請したクライアントに返却することを特徴とする。
【００５１】
なお、上述した実施の形態は、本発明の好適な実施の形態の一例を示すものであり、本発明はそれに限定されることなく、その要旨を逸脱しない範囲内において、種々変形実施が可能である。
【実施例】
【００５２】
次に本発明に係る実施例について図を参照して説明する。
［構 成］
図１は、本発明に係る共通鍵自動共有システムの一実施例を示す概念図である。
本共通鍵自動共有システムでは、共通鍵の生成・更新・削除、および、鍵交換などの機能を有するクライアント101〜103と、クライアント101〜103の存在を保証する信頼できる第三者認証機関側サーバ（以下、CAと表記する）104の２つで構成されている。
【００５３】
CA104の主な機能としては、以下の(a)〜(e)の機能が挙げられる。
(a)クライアント101〜103からの認証申請を受け付ける申請受付機能104-1
(b)申請されたクライアント情報の真正性を確認する真正性確認機能104-2
(c)そのクライアント情報が正しいことを保証するためにCA104のもつ秘密鍵で署名を行い、証明書を作成(d)する証明書作成機能104-3
(e)署名したクライアント情報を申請者に返却する証明書返却機能104-5
【００５４】
また、CA104では、CA自身の公開鍵（以下、CA公開鍵）および秘密鍵（以下、CA秘密鍵）が格納されている。CA公開鍵はクライアント101〜103が自由に取得できるように公開されている。また、CA秘密鍵は、証明書作成機能104-3のみがアクセスできるように、耐タンパな領域に厳重に管理される。
【００５５】
クライアント101〜103からの認証を受け付ける申請受付機能104は、クライアント101〜103が生成したクライアント情報を、メールやWeb、郵送などの情報伝達手段により取得する。
【００５６】
申請されたクライアント情報の真正性を確認する真正性確認機能は、申請受付機能104-1にて受け付けたクライアント情報について、情報に誤りが無いことを確認し、信頼できると判断した場合、証明書作成機能104-3に署名依頼を行う。
【００５７】
証明書作成機能104-3では、真正性確認機能104-2にて真正性が確認され、署名を依頼されたクライアント情報に対し、CA秘密鍵を用いて署名を行い証明書(電子証明書)を生成する。
証明書返却機能104-5では、証明書作成機能104-3により署名されたクライアント情報（以下、クライアント証明書と表記する）とCA公開鍵104-6とを、申請したクライアントに対して返信する。
【００５８】
クライアント101〜103の主な機能としては、以下の(a)〜(e)の機能がある。
(a)クライアントの公開鍵ペアやクライアント情報を作成しCAに対して証明書の発行申請を行う証明書申請機能（認証申請機能）102-4
(b)CAから返却されたクライアント証明書およびCA公開鍵を登録する証明書登録機能102-5
(c)共通鍵の生成や、自らが生成した共通鍵の更新・削除を行う鍵管理機能102-1
(d)共通鍵の配布対象の決定や、共通鍵交換要求の対象となるメンバ情報を登録するメンバ登録機能102-3
(e)メンバと互いに所有している共通鍵の交換を行う鍵交換機能102-2
【００５９】
図２は、図１に示したクライアントの構成図の一例である。
また、クライアント101〜103（図１参照）には、クライアント101〜103の公開鍵(以下、公開鍵と記載)および秘密鍵（以下、秘密鍵と記載）104-4、CA104から発行されたクライアント証明書、CA公開鍵104-6、メンバ登録したメンバのクライアント証明書を集めたメンバ情報リスト、鍵の配布状況が記録された所有鍵情報リストが格納されている。
さらに、ファイルの暗号化に使用する共通鍵の鍵情報は鍵管理部に格納されパスワード保護などにより厳重に管理されている。その他に、クライアント101〜103には、クライアント101〜103間で交換する情報の安全性を確保するための暗号化部213、復号部214やクライアント101〜103間で交換する情報の信頼性を保証するための検証部215を備える。
【００６０】
認証申請機能203(図１の認証申請機能102-4に対応）は、初期設定機能として動作し、クライアント101〜103の公開鍵ペアを生成する公開鍵ペア生成部203-1、クライアントの固有情報、組織情報、公開鍵情報などが記載されたクライアント情報リストを生成するクライアント情報生成部203-2、および、生成したクライアント情報をCA104(図１参照)へ認証申請する申請部203-3から構成される。
【００６１】
公開鍵ペア生成部203-1では、公開鍵ペアを生成し、それぞれクライアント公開鍵格納部217、クライアント秘密鍵格納部216へ格納する。クライアント秘密鍵格納部216は、鍵交換機能202(図１の鍵交換機能102-2に対応)、鍵管理機能206、復号部214のみがアクセスできるように、耐タンパな領域に厳重に管理される。
【００６２】
クライアント情報生成部203-2は、クライアントの氏名などの固有情報や会社組織情報、および、公開鍵ペア生成部203-1で生成したクライアント公開鍵などをクライアント情報として生成する。
【００６３】
申請部203-3は、クライアント情報生成部203-2で生成されたクライアント情報をCA104へ送付するとともに、CA104に対して証明書の発行申請を行う。
【００６４】
証明書登録機能204(図１の証明書登録機能102-5に対応)は、CA104によって発行されたクライアント証明書を受信する証明書受信部204-1、受信したクライアント証明書およびCA公開鍵を登録する登録部204-2で構成される。
【００６５】
証明書受信部204-1は、CA104によって発行されたクライアント証明書およびCA104より送付されたCA公開鍵を受信し、受信したクライアント証明書およびCA公開鍵を登録部204-2へと送付する。
【００６６】
登録部204-2は、送付されたクライアント証明書およびCA公開鍵をそれぞれ、クライアント証明書格納部211、および、CA公開鍵格納部212に格納する。また、メンバ情報リストを作成し、メンバ情報リスト格納部210へ格納する。
【００６７】
鍵管理機能206(図１の鍵管理機能102-1に対応)は、ファイルの暗号化に使用する共通鍵の鍵情報を生成する鍵情報生成部207、自らが生成した共通鍵の鍵情報を更新する鍵情報更新部219、及び自らが生成した共通鍵の鍵情報を削除する鍵情報削除部206で構成される。
【００６８】
さらに、鍵情報生成部207は、ユーザによる鍵生成命令によりファイルの暗号化に使用する共通鍵を生成する共通鍵生成部207-1、鍵表示名や有効期限など鍵の付加情報を入力する鍵情報入力部207-2、鍵の配布可能範囲を設定する配布範囲指定部207-3、生成した共通鍵・入力された鍵の付加情報・設定した配布可能範囲などの情報をまとめ鍵情報として生成する鍵情報合成部207-4、および、生成した鍵情報を所有鍵情報リストに反映する所有鍵情報リスト更新部208から構成される。
【００６９】
共通鍵生成部207-1では、ユーザへ暗号アルゴリズム、および、鍵長を選択させると共に、選択された内容に基づき、共通鍵を生成する。
【００７０】
鍵情報入力部207-2では、ユーザによる共通鍵の表示名や共通鍵の有効期限など、鍵の付加情報の入力を受け付ける。
配布範囲指定部207-3では、メンバ情報リスト格納部210からメンバ情報を入手する。クライアント101〜103(図１参照)は、取得したメンバ情報から個人や組織などの単位で生成した共通鍵の配布を許可する範囲を指定する。
【００７１】
鍵情報合成部207-4では、共通鍵生成部207-1で生成された共通鍵、鍵情報入力部207-2で入力された付加情報、および配布範囲指定部207-3で設定された配布可能範囲を収集すると共に、鍵情報ID、共通鍵ID、作成日、更新日、鍵作成者などの情報を付与し、鍵情報を作成する。
さらに、クライアント秘密鍵格納部216から秘密鍵を取得し、生成した鍵情報に対して署名を行い、鍵情報を鍵情報管理部220へ格納する。
【００７２】
所有鍵情報リスト更新部208では、所有鍵情報リスト格納部209から所有鍵情報リストを入手し、鍵情報合成部207-4で生成した鍵情報を所有鍵情報リストに追加・更新し、所有鍵情報リスト格納部209へ格納する。
【００７３】
鍵情報更新部219は、さらに、鍵情報管理部220から鍵情報を取得する鍵情報収集部219-1、鍵の暗号アルゴリズムや鍵長・鍵表示名や有効期限など鍵の付加情報や共通鍵の配布範囲を変更する鍵情報変更部219-2、および、変更した鍵情報を所有鍵情報リストに反映する所有鍵情報リスト更新部208から構成される。
【００７４】
鍵情報収集部219-1では、鍵情報管理部220からクライアント101〜103(図１参照)で作成した鍵情報のみを取得し、変更する鍵情報を選択する。
鍵情報変更部219-2では、共通鍵を更新する場合は共通鍵生成部207-1と連携し、有効期限などの付加情報を更新する場合は鍵情報入力部207-2と連携し、鍵の配布可能範囲を更新する場合は配布範囲指定部207-3と連携し、各情報を更新する。
さらに、更新日などを更新し、クライアント秘密鍵格納部216から秘密鍵を取得し、更新した鍵情報に対して署名を行い、鍵情報を鍵情報管理部220へ格納する。
所有鍵情報リスト更新部208では、所有鍵情報リスト格納部209から所有鍵情報リストを入手し、鍵情報変更部219-2で更新した鍵情報に基づき、所有鍵情報リストを更新し、所有鍵情報リスト格納部209へ格納する。
【００７５】
鍵情報削除部205は、さらに、鍵情報管理部220から鍵情報を取得する鍵情報収集部205-1、削除対象として選択された鍵情報の削除処理を行う鍵情報削除部205-2、および、削除処理した鍵情報を所有鍵情報リストに反映する所有鍵情報リスト更新部209から構成される。
【００７６】
鍵情報収集部219-1では、鍵情報管理部220からクライアント101〜103(図１参照)で作成した鍵情報のみを取得し、削除する鍵情報を選択する。
鍵情報削除部205-2では、削除対象の鍵情報に対して、共通鍵の削除、更新日の更新を行う。そして、クライアント秘密鍵格納部216から秘密鍵を取得し、更新した鍵情報に対して署名を行い、鍵情報を鍵情報管理部220へ格納する。
所有鍵情報リスト更新部208では、所有鍵情報リスト格納部209から所有鍵情報リストを入手し、鍵情報削除部205-2で削除した鍵情報に基づき、所有鍵情報リストを更新し、所有鍵情報リスト格納部209へ格納する。
【００７７】
メンバ登録機能201(図１のメンバ登録機能102-3に対応)は、さらに、メンバ情報リストの交換要求の送受信を行う、メンバ情報交換要求送受信部201-5、クライアント証明書の送受信を行うクライアント証明書送受信部202-4、メンバ情報リスト格納部210からメンバ情報リストを取得するメンバ情報リスト取得部201-3、取得したメンバ情報リストを送受信するメンバ情報リスト送受信部201-2、受信したメンバ情報リストを元に所有するメンバ情報リストを更新し、メンバ情報リスト格納部210へ格納するメンバ情報リスト更新部201-1から構成される。
【００７８】
メンバ情報交換要求送受信部201-5では、要求送信側クライアント(以下、要求者と記載)はネットワークを通じて他クライアントに対しメンバ情報リストの交換要求を送信する。また、要求受信側クライアント（以下、受信者と記載）は、交換要求を受信すると要求者に対し承諾の応答を返す。
要求者が受信者からの承諾応答を受信した場合、クライアント証明書送受信部202-3へクライアント証明書の送信を依頼する。
クライアント証明書送受信部202-2では、要求者はメンバ情報交換要求送受信部201-5での受信者からの承諾応答に従い、クライアント証明書格納部211からクライアント証明書を取得し、受信者に対して送付する。
受信者は、要求者から送付されたクライアント証明書を検証部215へ送付する。検証部215で正常と判断された場合、メンバ情報リスト取得部201-3へ取得要求をする。
【００７９】
メンバ情報リスト取得部201-3では、メンバ情報リスト格納部201からメンバ情報リストを、クライアント証明書格納部211からメンバ情報に記載されているリストメンバのクライアント証明書（以下、メンバクライアント証明書と記載）取得し、メンバ情報リスト送受信部201-2へ渡す。
【００８０】
メンバ情報リスト送受信部201-2では、メンバ情報リスト取得部201-3で取得したメンバ情報リストおよびメンバクライアント証明書を暗号化部に送付し、暗号化部213で暗号化されたメンバ情報リストおよびメンバクライアント証明書（暗号化済みメンバ情報と記載）を受け取り、要求者へ送信する。要求者では、暗号化済みメンバ情報を受信すると復号部214へ送付し、復号部214からメンバ情報リストおよびメンバクライアント証明書を取得し、メンバ情報リスト更新部201-1へ送付する。
【００８１】
メンバ情報リスト更新部201-1では、メンバ情報リスト格納部210から現在のメンバ情報リストを取得し、取得したメンバ情報リストと比較を行い、現在のメンバ情報リストに記載のないメンバのメンバクライアント証明書をクライアント証明書格納部211に登録するとともに、メンバ情報リストの更新を行い、メンバ情報リスト格納部210へ更新したメンバ情報リストを格納する。
【００８２】
鍵交換機能202は、さらに、鍵情報の交換要求の送受信を行う鍵情報交換要求送受信部202-1、クライアント証明書の送受信を行うクライアント証明書送受信部202-2、所有鍵情報リスト格納部209から所有鍵情報リストを取得し、送受信する所有鍵情報リスト送受信部202-3、取得した鍵情報リストをもとに送付対象の鍵情報を鍵情報管理部220から取得し送受信する鍵情報送受信部202-4、取得した鍵情報を基に鍵情報の登録を行う鍵情報登録部202-5、所有鍵情報リスト格納部209から所有鍵情報リストを取得し、登録した鍵情報を基に所有鍵情報リストを更新し格納する所有鍵情報リスト更新部208から構成される。
【００８３】
鍵情報交換要求送受信部202-1では、要求者はネットワークを通じて他クライアントに対し鍵情報の交換要求を送信する。また、受信者は、交換要求を受信すると要求者に対し承諾の応答を返す。要求者が受信者からの承諾応答を受信した場合、クライアント証明書送受信部202-2へクライアント証明書の送信を依頼する。
【００８４】
クライアント証明書送受信部202-2では、要求者は受信者からの承諾応答を受け、クライアント証明書格納部211からクライアント証明書を取得し、受信者に対して送付する。受信者は、要求者から送付されたクライアント証明書を検証部215へ送付する。検証部215で正常と判断された場合、受信者はクライアント証明書格納部211からクライアント証明書を取得し、要求者に対して送付すると共に、所有鍵情報リストの送信要求を行う。要求者は、受信者から送付されたクライアント証明書を検証部215へ送付し、検証部で正常と判断された場合、所有鍵情報リスト送受信部202-3へ所有鍵情報リストの送信依頼を行う。
【００８５】
所有鍵情報リスト送受信部202-3では、所有鍵情報リスト格納部209から所有鍵情報リストを取得し、暗号化部213へ送付する。続いて、暗号化部213から暗号化された所有鍵情報リスト（以下、暗号化済み所有鍵情報リストと記載）を取得し受信者へ送付する。受信者では、暗号化済み所有鍵情報リストを受信すると復号部214へ送付し、復号部214から復号された所有鍵情報リストを得る。さらに、所有鍵情報リスト格納部209から所有鍵情報リストを取得し、復号した所有鍵情報リストと比較して送付対象となる鍵情報の選定を行う。
【００８６】
鍵情報送受信部202-4では、所有鍵情報リスト送受信部202-3で選定された送付対象となる鍵情報を鍵情報管理部220から取得し、取得した鍵情報の配布可能範囲内であるか確認を行った後、暗号化部213へ送付する。暗号化部213から暗号化された鍵情報を受け取り、要求者へ送付する。要求者は暗号化された鍵情報を受け取ると、復号部214へ送付し、復号された鍵情報を取得する。
鍵情報登録部202-5では、取得した鍵情報を鍵情報管理部220に登録を行う。
所有鍵情報リスト更新部208では、所有鍵情報リスト格納部209から所有鍵情報リストを入手し、取得した鍵情報に基づき、所有鍵情報リストを更新し、所有鍵情報リスト格納部209へ格納する。
尚、図中218は通信部である。
【００８７】
［動 作］
次に、図２〜図１２を参照して本発明に係る共通鍵自動配布システムの実施例の動作について詳細に説明する。
本発明に係る共通鍵自動配布システムの動作は、大きく以下の(a)〜(d)の動作に分けられる。
(a)公開鍵ペアの作成やクライアント情報の登録などを行う初期設定
(b)ファイルの暗号化に使用する鍵情報の生成・更新・削除
(c)クライアント間における鍵情報の交換
(d)クライアント間におけるメンバ情報の交換
【００８８】
まず、初期設定の動作について図３、図４を参照して詳細に説明する。
図３は、図１に示した共通鍵自動配布システムに用いられるクライアント証明書の一例である。図４は、図１に示した共通鍵自動配布システムに用いられるクライアントの初期設定フローの一例である。
図４において、本発明に係る共通鍵自動配布システムに用いられるクライアント101〜103(図１参照)では、クライアント情報の生成を開始すると、公開鍵ペア生成部203-1にて、公開鍵と秘密鍵とのペアが生成され、それぞれクライアント公開鍵格納部217およびクライアント秘密鍵格納部216に格納される（ステップ(1)〜(3)）。
次に、クライアント情報生成部207にて、クライアント101〜103の固有情報（氏名やIDなど）や組織情報（会社名、部署名、役職など）に加え、クライアント公開鍵格納部217から公開鍵および公開鍵に関する情報を取得し、クライアント情報として図３に示すようなクライアント証明書を生成する。ただし、この時点では署名領域は未記入である（以下、本状態のクライアント証明書をクライアント情報と表記する：ステップ(4)〜(6)）。
【００８９】
続いて、申請部203-3にてクライアント情報をCA104(図１参照)に提出する。CA104への証明書発行申請は、メールやWeb、郵送などの情報伝達手段を用いて行われる（ステップ(7)）。
CA104では、クライアント101〜103が生成したクライアント情報を、メールやWeb、郵送などの情報伝達手段により申請受付機能104-1(図１参照)にて取得し、真正性確認機能104-2(図１参照)で、申請受付機能104-1にて取得したクライアント情報の各情報に誤りが無いことを確認し、信頼できると判断した場合、証明書作成機能104-3(図１参照)にてCA秘密鍵を用いて署名を行う。
本処理では、送付されたクライアント情報の署名領域部分に証明書発効日などの情報を記載し、クライアント証明書として生成する（ステップ(8)〜(11)）。
【００９０】
次に、証明書返却機能104-5にて、クライアント証明書をクライアント101〜103へ送付する。このとき、CA公開鍵についても合わせて送付する（図４ステップ(12)〜(13)）。
クライアント101〜103では、CA104から送付されたクライアント証明書およびCA公開鍵を証明書送受信部204-1にて受け取り（ステップ(14)）、登録部204-2にてクライアント証明書をクライアント証明書格納部211に登録し、CA公開鍵をCA公開鍵格納部212に登録すると共に、クライアント証明書の情報を元にメンバ情報リスト（図１１）を生成し、メンバ情報リスト格納部210に登録する（図４ステップ(15)〜(16)）。
図１１は、図１に示した共通鍵自動配布システムに用いられるメンバ情報リストの一例である。
【００９１】
次に、鍵の生成・更新・削除の動作について図５から図９を参照して詳細に説明する。
図５は、図１に示した共通鍵自動配布システムに用いられる鍵情報の一例を示す図である。図６は、図１に示した共通鍵自動配布システムに用いられるクライアントの鍵生成フローの一例を示す図である。図７は、図１に示した共通鍵自動配布システムに用いられるクライアントの鍵更新フローの一例を示す図である。図８は、図１に示した共通鍵自動配布システムに用いられるクライアントの鍵削除フローの一例を示す図である。図９は、図１に示した共通鍵自動配布システムに用いられる所有鍵情報リストの一例である。
【００９２】
鍵の生成では、図６に示すとおり、まず共通鍵生成部207-1(図２参照)にて暗号化アルゴリズムおよび鍵長を指定し（ステップS601）、鍵生成命令を行い(ステップS602)、共通鍵を生成する(ステップS603)。
続いて、鍵情報入力部207-2(図２参照)にて鍵の表示名や鍵の有効期限などの付加情報を入力する(ステップS604)。
【００９３】
次に、配布範囲指定部207-3(図２参照)にてメンバ情報リスト格納部210からメンバ情報リストを取得し(ステップS605)、本リストの情報を元に鍵の配布範囲の指定を行う(ステップS606)。
これら情報をもとに、鍵情報合成部207-4では図５に示すような鍵情報のうち署名値のないものを鍵情報仮生成として行い(ステップS607)、クライアント秘密鍵格納部216からクライアント秘密鍵を取得し(ステップS608)、鍵情報に署名を行い(ステップS609)、正式な鍵情報を生成する(ステップS610)。生成した鍵情報は鍵情報管理部220へ格納する(ステップS611)。
【００９４】
最後に、所有鍵情報リスト更新部208にて、所有鍵情報リスト格納部209から図９に示すような所有鍵情報リストを取得し(ステップS612)、生成した鍵情報リストを更新後(ステップS613)、所有鍵情報リスト格納部209へ再度格納する(ステップS614)。
【００９５】
鍵の更新では、図７に示すとおり、鍵情報収集部209-1にて鍵情報管理部220から鍵情報の鍵作成者となっている鍵のみを取得し(ステップS701)、取得した鍵情報から更新を実施する鍵情報を選択する(ステップS702)。
続いて、鍵情報変更部209-2で、共通鍵の更新を行う場合は、鍵情報生成部207の共通鍵生成部207-1に依頼を行い、共通鍵生成部207-1にて暗号化アルゴリズムおよび鍵長を指定および鍵生成命令を行う。すなわち、共通鍵を更新するか否かを判断し(ステップS703)、更新しない場合(ステップS703/NO)にはステップS706に進み、更新する場合(ステップS703/YES)には、暗号アルゴリズム、鍵長を指定し(ステップS704)、共通鍵を生成し(ステップS705)、ステップS706へ進む。付加情報を更新する場合は、鍵情報生成部207の鍵情報入力部207-2に依頼を行い、鍵情報入力部207-2にて鍵の表示名や鍵の有効期限などの付加情報の入力を行う。すなわち、ステップS706では付加情報を更新するか否かを判断し、更新しない(ステップS706/NO)にはステップS708に進み、更新する場合(ステップS706/YES)には、鍵の付加情報を入力し(ステップS707)、ステップS708に進む。
【００９６】
鍵情報の配布可能範囲を更新する場合は、鍵情報生成部207の配布範囲指定部に依頼を行い、配布範囲指定部にてメンバ情報リスト格納部210からメンバ情報リストを取得し、本リストの情報を元に鍵の配布範囲の指定を行う。すなわち、ステップS708では配布可能範囲を更新するか否かを判断し、更新しない場合(ステップS708/NO)にはステップS711に進み、更新する場合(ステップS708/YES)には、メンバ情報リストを取得し(ステップS709)、鍵の配布範囲を指定し(ステップS710)、ステップS711に進む。
【００９７】
最後に、鍵情報変更部219-2では、これら更新内容に基づき鍵情報を更新するとともに更新日の更新を行い(ステップS711)、クライアント秘密鍵格納部216から秘密鍵を取得し(ステップS712)、鍵情報への再署名を行い(ステップS713)署名値を修正し、これら更新処理を行った鍵情報を作成し(ステップS714)、更新した鍵情報を鍵情報管理部220へ格納する(ステップS715)。
【００９８】
続いて、所有鍵情報リスト更新部208にて、所有鍵情報リスト格納部209から図９に示すような所有鍵情報リストを取得し(ステップS716)、更新した鍵情報の更新部分を変更(リスト更新：ステップS717)後、所有鍵情報リスト格納部209へ再度格納する(ステップS718)。
鍵の削除では、図８に示すとおり、鍵情報収集部219-1にて鍵情報管理部220から鍵情報の鍵作成者となっている鍵のみを取得し(ステップS801)、取得した鍵情報から削除を実施する鍵情報を選択する(ステップS802)。
【００９９】
次に、鍵情報削除部205-2では鍵情報の共通鍵部分を削除し、暗号化・復号に使用できない状態にするとともに更新日の更新を行う(ステップS803)。
【０１００】
クライアント秘密鍵格納部216からクライアント秘密鍵を取得し(ステップS804)、鍵情報への再署名を行い(ステップS805)、署名値を修正し、これら削除処理を行った鍵情報を作成(ステップS806)、鍵情報管理部220へ格納する(ステップS807)。
【０１０１】
続いて、所有鍵情報リスト更新部208にて、所有鍵情報リスト格納部209から図９に示すような所有鍵情報リストを取得し(ステップS808)、削除した鍵情報の情報を変更（リスト更新：ステップS809）後、所有鍵情報リスト格納部209へ再度格納する(ステップS810)。
【０１０２】
次に、クライアント間における鍵情報の交換の動作について、図１０を参照して詳細に説明する。
図１０は、図１に示した共通鍵自動配布システムに用いられるクライアント間の鍵情報交換フローの一例である。
本実施例における説明では、鍵の交換要求を行う側をクライアントAとし、鍵の交換要求に応じて鍵情報を提供する側をクライアントBとする。
クライアントAの鍵情報交換要求送受信部202-1から他のクライアントに対し鍵情報交換の要求を送信する(ステップ(1))。
クライアントBの鍵情報交換要求送受信部202-1では、クライアントAからの鍵情報交換要求を受信すると、鍵情報交換承諾の応答をクライアントAへ返す(ステップ(2))。
クライアントAの鍵情報交換要求送受信部202-1で、クライアントBからの鍵情報交換承諾の応答を受信すると、クライアント証明書送受信部202-2にてクライアント証明書格納部211から自身のクライアント証明書（以下、クライアントA証明書と記載）を取得し、クライアントBへ送付する(ステップ(3))。
クライアントBのクライアント証明書送受信部202-2にて、クライアントA証明書を受信すると、クライアントA証明書を検証部215へ送付する。検証部215では、CA公開鍵格納部212からCA公開鍵を入手し、CA公開鍵を用いてクライアントA証明書がCAから正式に正しく発行され改ざんされていない証明書であるか否かの検証を行う(ステップ(4))。
検証結果が正常であった場合、クライアント証明書送受信部202-2では、クライアント証明書格納部211から自身のクライアント証明書（以下、クライアントB証明書と記載）を取得し、クライアントAへ送付すると共に、所有鍵情報リスト要求を行う。なお、検証部215での検証結果が正常でない場合は処理を終了する(ステップ(5))。
クライアントAのクライアント証明書送受信部202-2にて、クライアントB証明書および所有鍵情報リスト要求を受信すると、クライアントB証明書を検証部215に送付する。検証部215では、CA公開鍵格納部212からCA公開鍵を入手し、CA公開鍵を用いてクライアントB証明書がCAから正式に正しく発行され改ざんされていない証明書であるか否かの検証を行う(ステップ(6))。
検証結果が正常であった場合、所有鍵情報リスト送受信部202-3にて、所有鍵情報リスト格納部209から所有鍵情報リストを取得（以下、所有鍵情報リストAと記載）し、クライアントB証明書と共に暗号化部へ送付する。なお、検証部215での検証結果が正常でない場合は処理を終了する。暗号化部213では、クライアントB証明書からクライアントBの公開鍵を入手し、クライアントBの公開鍵で所有鍵情報リストAを暗号化し、所有鍵情報リスト送受信部202-3へ返却する(ステップ(7))。
【０１０３】
所有鍵情報リスト送受信部202-3は、暗号化された所有鍵情報リストAをクライアントBへ送付する(ステップ(8))。
クライアントBの所有鍵情報リスト送受信部202-3が、暗号化された所有鍵情報リストAを受信すると、所有鍵情報リスト送受信部202-3は復号部214へ送付する。復号部214では、クライアント秘密鍵格納部216から秘密鍵を取得して、暗号化された所有鍵情報リストAを復号し、所有鍵情報リスト送受信部202-3へ返却する(ステップ(9))。
【０１０４】
所有鍵情報リスト送受信部202-3では、所有鍵情報リスト格納部202-3から所有鍵情報リストを取得（以下、所有鍵情報リストBと記載）し、所有鍵情報リストAと比較を行い、クライアントAへの送付対象となる鍵情報を選定を行い(ステップ(10))、選定結果を鍵情報送受信部202-4へ通知する。なお、選定基準は以下の通り。
・所有鍵情報リストBにあり、所有鍵情報リストAにない鍵情報（パターンA）
・所有鍵情報リストA、B共に存在するが、所有鍵情報リストBにある鍵情報の方が更新日が新しい場合（パターンB）。
【０１０５】
鍵情報送受信部202-4では、取得した選定結果を基に鍵情報管理部220から該当する鍵情報を取得する。なお、パターンAに属する鍵情報の場合、鍵情報の配布可能範囲にクライアントAが該当するか否かの確認を行い、該当する鍵情報のみを取得する(ステップ(11))。
【０１０６】
鍵情報送受信部202-4では、取得した鍵情報をクライアントA証明書と共に暗号化部213へ送付し、暗号化部213では、クライアントA証明書からクライアントAの公開鍵を入手し、クライアントAの公開鍵で鍵情報を暗号化し、鍵情報送受信部202-4へ返却する(ステップ(12))。
鍵情報送受信部202-4は、暗号化された鍵情報をクライアントAへ送付する(ステップ(13))。
クライアントAの鍵情報送受信部202-4では、暗号化された鍵情報を受信すると、復号部214へ送付する。復号部214では、クライアント秘密鍵格納部216から秘密鍵を取得して、暗号化された鍵情報を復号し、鍵情報送受信部202-4へ返却する(ステップ(14))。
【０１０７】
鍵情報登録部202-5では、復号された鍵情報を鍵情報送信部202-4から受け取り、検証部215に送付する。検証部215では、クライアント証明書格納部211から、鍵情報の作成者に対応するクライアント証明書を取得し、クライアント証明書から公開鍵を取り出し鍵情報の検証を行う。検証結果が正常でない場合は鍵情報を破棄する。検証結果が正常な場合は、鍵情報管理部220へ登録する。登録方法は以下の(i)、(ii)の通り。
【０１０８】
(i)所有していない鍵情報は、鍵情報の配布可能範囲に該当していることを確認し登録
(ii)所有している鍵情報で、更新されている鍵は、鍵情報管理部220から該当の鍵情報を取得・更新し鍵情報を再登録。なお、更新されている鍵のパターンとしては、更新（鍵 情報のいずれかが変更されている）と削除（鍵情報の共通鍵が削除されている）
の２つがある。
鍵情報の登録が完了後、所有鍵情報リスト更新部208では、所有鍵情報リスト格納部209から所有鍵情報リストを取得し(ステップ(15))、鍵情報の登録内容を所有鍵情報リストに反映し、所有鍵情報リスト格納部209に再格納する(ステップ(16))。
【０１０９】
最後に、クライアント間におけるメンバ情報の交換の動作について、図１２を参照して詳細に説明する。
図１２は、図１に示した共通鍵自動配布システムに用いられるクライアント間のメンバ情報リスト交換フローの一例である。
本実施例における説明では、メンバ情報リストの交換要求を行う側をクライアントAとし、メンバ情報リストの交換要求に応じてメンバ情報を提供する側をクライアントBとする。
【０１１０】
クライアントAのメンバ情報交換要求送受信部201-5から他のクライアントに対しメンバ情報リスト交換の要求を送信する(ステップ(1))。
クライアントBのメンバ情報交換要求送受信部201-5では、クライアントAからのメンバ情報リスト交換要求を受信すると、メンバ情報リスト交換承諾の応答をクライアントAへ返す(ステップ(2))。
クライアントAのメンバ情報交換要求送受信部201-5で、クライアントBからのメンバ情報リスト交換承諾の応答を受信すると、クライアント証明書送受信部201-4にてクライアント証明書格納部211から自身のクライアント証明書（以下、クライアントA証明書と記載）を取得し、クライアントBへ送付する(ステップ(3))。
【０１１１】
クライアントBのクライアント証明書送受信部201-4にて、クライアントA証明書を受信すると、クライアントA証明書を検証部215へ送付する。検証部では、CA公開鍵格納部212からCA公開鍵を入手し、CA公開鍵を用いてクライアントA証明書がCAから正式に正しく発行され改ざんされていない証明書であるか否かの検証を行う(ステップ(4))。
検証結果が正常であった場合、メンバ情報リスト取得部201-3では、メンバ情報リスト格納部210からメンバ情報リストを取得する（以下、メンバ情報リストBと記載）と共に、クライアント証明書格納部211からメンバ情報リストBに記載されているメンバのクライアント証明書（以下、メンバクライアント証明書と記載）を取得する(ステップ(5))。
【０１１２】
続いて、メンバ情報リスト送受信部201-2では、取得したメンバ情報リストBおよびメンバクライアント証明書に加え、クライアントA証明書を暗号部213に送付し、クライアントA証明書からクライアントAの公開鍵を入手し、クライアントAの公開鍵でメンバ情報リストBおよびメンバクライアント証明書を暗号化し、メンバ情報リスト送受信部201-2へ返却する(ステップ(6))。
メンバ情報リスト送受信部201-2は、暗号化されたメンバ情報リストBおよびメンバクライアント証明書をクライアントAへ送付する(ステップ(7))。
【０１１３】
クライアントBのメンバ情報リスト送受信部201-2では、暗号化されたメンバ情報リストBおよびメンバクライアント証明書を受信すると、復号部214へ送付する。復号部214では、クライアント秘密鍵格納部216から秘密鍵を取得して、暗号化されたメンバ情報リストBおよびメンバクライアント証明書を復号し、メンバ情報リスト送受信部201-2へ返却する(ステップ(8))。
メンバ情報リスト更新部201-1では、復号されたメンバ情報リストBおよびメンバクライアント証明書をメンバ情報リスト送受信部201-2から受け取る共に、メンバ情報リスト格納部210から現在のメンバ情報リストを取得（以下、メンバ情報リストAと記載）し、メンバ情報リストAとメンバ情報リストBとの比較を行う。比較の結果、メンバ情報リストAに記載のないメンバのメンバクライアント証明書をクライアント証明書格納部211に登録するとともに、メンバ情報リストAに追加する。
最後に、更新されたメンバ情報リストAはメンバ情報リスト格納部210に格納される(ステップ(9))。
【０１１４】
本発明の効果は、以下の通りである。
・ピアツーピア型を用いた鍵交換を行うため、鍵交換・配信にサーバを必要としない。また、クライアントが自由に鍵の作成・更新・削除を行うことができる。
・ピアツーピア型を用いた鍵交換および証明書を用いた本人確認を自動的に行うため、クライアントが意識することなく、所有することを許可されたメンバにのみ、鍵情報の交換・配信を行うことができる。
【０１１５】
なお、上述した実施例は、本発明の好適な実施例の一例を示すものであり、本発明はそれに限定されることなく、その要旨を逸脱しない範囲内において、種々変形実施が可能である。
【０１１６】
ここで、前述した特許文献１〜７に記載の発明と本願との相違点について述べる。
＜特許文献１＞
特許文献１に記載の発明は、複数ユーザで共有するファイルを自動的に暗号化・復号するシステムだが、共有ディスク上のファイルの暗号化に限定されている点や暗号化に使用する鍵がクライアントの個別データを使用しており、鍵の更新などを考慮していない点が本願発明と異なる。
【０１１７】
＜特許文献２＞
特許文献２では暗号化ファイルに用いた鍵のグループ内での共有方法について述べているが、暗号化装置と認証装置を必要とするシステムであり、サーバ不要としクライアント間で鍵を交換する本願発明とは異なる。
【０１１８】
＜特許文献３＞
特許文献３には複数端末間における暗号化鍵の自動更新同期方式について記載されているが、暗号化鍵の利用目的が通信路の暗号化であり、あらかじめ事前に複数の鍵を送付して、ある一定のタイミングで使用する鍵を次のものへと変える形であり、共有するファイルの暗号化を目的とし、ピアツーピア型の通信でクライアント間で随時鍵の交換を行う本願発明とは異なる。
【０１１９】
＜特許文献４＞
特許文献４に記載の発明は、クライアントから入手したリストを基に、更新情報をサーバが供給している点で本願発明とは異なる。
【０１２０】
＜特許文献５＞
特許文献５に記載の発明は、公開鍵及びセッション鍵を用いた端末間の通信路の安全性を確保するものであり、ごく一般的な技術である。また、特許文献５に記載の発明は、リスト交換時における公開鍵を用いた暗号化による通信の保安性確保であり、本願発明とは異なる。
【０１２１】
＜特許文献６＞
特許文献６に記載の発明は、信頼できる端末のみと端末情報を交換し信頼できる端末グループを形成し、信頼できる端末グループ内で使用する鍵を共有しているのであり、任意のメンバ間で使用する共通鍵の配布範囲を指定する点で本願発明とは異なる。また、特許文献６に記載の発明は、交換するメンバの情報には配布範囲を指定するための補助的情報があるだけで、配布可能な範囲の情報は共通鍵情報自体が持つ点で本願発明とは異なる。
【０１２２】
＜特許文献７＞
特許文献７に記載の発明は、リストを交換することで互いに共有する情報を取得し、共有する情報を基に鍵共有を行っている点で本願発明とは異なる。
【図面の簡単な説明】
【０１２３】
【図１】本発明に係る共通鍵自動共有システムの一実施例を示す概念図である。
【図２】図１に示したクライアントの構成図の一例である。
【図３】図１に示した共通鍵自動配布システムに用いられるクライアント証明書の一例である。
【図４】図１に示した共通鍵自動配布システムに用いられるクライアントの初期設定フローの一例である。
【図５】図１に示した共通鍵自動配布システムに用いられる鍵情報の一例を示す図である。
【図６】図１に示した共通鍵自動配布システムに用いられるクライアントの鍵生成フローの一例を示す図である。
【図７】図１に示した共通鍵自動配布システムに用いられるクライアントの鍵更新フローの一例を示す図である。
【図８】図１に示した共通鍵自動配布システムに用いられるクライアントの鍵削除フローの一例を示す図である。
【図９】図１に示した共通鍵自動配布システムに用いられる所有鍵情報リストの一例である。
【図１０】図１に示した共通鍵自動配布システムに用いられるクライアント間の鍵情報交換フローの一例である。
【図１１】図１に示した共通鍵自動配布システムに用いられるメンバ情報リストの一例である。
【図１２】図１に示した共通鍵自動配布システムに用いられるクライアント間のメンバ情報リスト交換フローの一例である。
【符号の説明】
【０１２４】
１０１〜１０３ クライアント
１０２−１ 鍵管理機能
１０２−２ 鍵交換機能
１０２−３ メンバ登録機能
１０２−４ 認証申請機能
１０２−５ 証明書登録機能
１０４ 第三者認証機関側サーバ（ＣＡ）
１０４−１ 申請受付機能
１０４−２ 真正性確認機能
１０４−３ 証明書作成機能
１０４−４ ＣＡ秘密鍵
１０４−５ 証明書返却機能
１０４−６ ＣＡ公開鍵
【技術分野】
【０００１】
本発明は、共通鍵自動配布システム、クライアント、第三者認証機関側サーバ、及び共通鍵自動共有方法に関する。
【背景技術】
【０００２】
ファイルの内容をセキュアに保つため、一般にファイルの暗号化が行われている。
しかし、暗号化されたファイルをグループやプロジェクト内など、ある範囲で共有するためには、暗号化ファイルを共有するメンバ内で暗号化に使用した鍵を事前に共有する必要がある。
さらに、この暗号化に使用される鍵は、随時必要に応じて、新規に追加されたり、更新されたり、あるいは削除される。
このように、ファイルの暗号化に使用する鍵の運用を行う場合、新規生成、更新、削除などが行われるごとに、全てのメンバに対して反映する必要がある。
現状としては、このようなファイルの暗号化に使用する鍵（以下、共通鍵と記載）の運用については、以下の方式が考えられる。
【０００３】
○サーバを経由して配布する方式
本方式では、共通鍵をサーバに格納し、予め定められたスケジュールに基づき、クライアント側へ共通鍵を配布するか、クライアント側が任意のタイミング(PC起動時など)にサーバへアクセスして共通鍵を取得する方法が考えられる。
しかし、本方式では、共通鍵をサーバで一括管理するため、共通鍵の生成、配布はサーバ管理者に依存することになり、メンバが目的に合わせて自由に共通鍵を生成、更新、削除することが困難となる。
また、本方式では、共通鍵をサーバで一元管理しているため、サーバにアクセスできない状況では、メンバは共通鍵の取得ができなくなる。
【０００４】
○共通鍵をファイル形式で出力し、メールやファイルサーバなど経由して配布する方式
本方式では、共通鍵の管理者が共通鍵をファイル形式でエクスポートし、メンバに対してエクスポートしたファイルをメールやファイルサーバ経由で配布する。メンバはメールやファイルサーバ経由でファイルを入手し、入手したファイルをインポートすることで、共通鍵を取り込む。
本方式では、管理者、メンバともに手動での操作 （エクスポート−配布−入手−インポート）が必要となり、運用が煩雑になりやすい。また、この方式の場合、配布済みの共通鍵を削除するには、メンバに手動で削除するよう依頼する必要がある。
【０００５】
この他、共通鍵自動共有に関連する技術が特許文献１〜７に記載されている。
特許文献１に記載のグループ暗号方法は、通信網によって相互に接続された複数の端末と当該複数の端末からアクセス可能な記憶装置とを備え、複数の端末により複数のユーザによって共有される記憶装置上の情報の暗号化を行うグループ暗号方法であって、端末は、演算機能を備えた記憶媒体を接続可能とし、当該記憶媒体は予めユーザに配布され当該記憶媒体の所有者のユーザ識別情報およびマスタ鍵と呼ばれる秘密数値を記憶し、記憶装置への、任意の一つの端末からの情報の書き込みは、書き込む情報の開示先を示すユーザ識別情報のリストである宛先リストを生成すると共に、当該宛先リストを前記端末から当該端末に接続された記憶媒体に送信するステップと、記憶媒体において、受信した宛先リストが示す条件に当該記憶媒体内に記憶したユーザ識別情報が合致するか否かを検査するステップと、当該検査ステップにより、受信した宛先リストが示す条件に記憶媒体内のユーザ識別情報が合致する場合は、宛先リストと記憶媒体内に記憶したマスタ鍵とに基づいてグループ鍵を生成して端末に返送するステップと、端末において、データ鍵と呼ぶ乱数を生成し、当該データ鍵を用いて平文を暗号化して暗号文を生成するステップと、記憶媒体より返送されたグループ鍵を用いてデータ鍵を暗号化して暗号文鍵を生成するステップと、暗号文鍵、宛先リスト、および暗号文を、記憶装置に書き込むステップとにより行うものである。
【０００６】
このグループ暗号方法によれば、暗号者が作成した宛先リストと、復号者のＩＣカードに格納されたユーザ識別情報とを照合し、復号者が該宛先リストが示す条件に合致するかどうかにより、暗号文を復号化できるかどうかが決まる。暗号者が宛先リストに自分自身のみを指定すれば、その暗号者だけが復号化できることになり、また、複数のユーザを指定すれば、それら指定されたユーザだけが復号化できることになる。したがって、暗号者は個人的な情報と複数のユーザによって共有される情報とを同じように暗号化できるとしている。
【０００７】
特許文献２に記載のファイルの暗号化方法は、送信者側のコンピュータから１乃至複数の受信者側のコンピュータに送信されるファイルの暗号化方法において、送信者側のコンピュータが、共通鍵を用いてファイルを暗号化するステップと、認証機関のコンピュータに、所定のグループ毎に暗号化に用いた共通鍵の利用権限を設定登録するステップと、パスワードベースの暗号を用いて共通鍵を暗号化するステップと、暗号化したファイルと暗号化した共通鍵を１乃至複数の受信者側のコンピュータに送信するステップとを有するものである。
【０００８】
このファイルの暗号化方法によれば、パスワード方式とグループ鍵共有方式の双方の特徴を利用することにより、これらの利点を併せ持つグループ暗号を実現することができる。すなわち、暗号化ファイルを生成する毎にまたはグループを構成する毎にパスワードを発行する必要がなく、パスワードやグループ鍵の管理を非常に簡易にすることができるとしている。
【０００９】
特許文献３に記載の暗号鍵更新システムは、暗号化と復号とに同一の暗号鍵を用いる共通鍵方式によりデータを暗号化および復号しながら複数の装置が互いにデータを送受信する通信システムの暗号鍵更新システムであって、各装置が、複数の暗号鍵が記された電子的な暗号鍵リストを保持するリスト保持手段と、予め定められた規則に基づき、リスト保持手段に保持された暗号鍵リストに記される複数の暗号鍵の中から１つ以上の暗号鍵を選択する選択手段とを具備したものである。
【００１０】
この暗号鍵更新システムによれば、たとえば１年分の暗号鍵をすべての装置に予め配布しておき、各装置が、これらの中から暗号化および復号に用いる暗号鍵を他の装置と同じ規則で選択するようにしたため、その結果として、すべての装置が同期を取って暗号鍵を自動的に更新することが可能となり、ユーザに暗号鍵の入力や設定等の煩わしい作業を行わせることがないとしている。
【００１１】
特許文献４に記載の情報配信システムは、クライアントに受信済みの情報のバージョンをサーバに送信し、サーバ側で管理しているバージョンの情報構成リストと最新バージョンの情報との差異を抽出して更新部分だけを配信する、あるいは、クライアントから情報の構成を示す情報を送信し、サーバ側で比較することにより差異を抽出して更新部分だけを配信するものである。
【００１２】
この情報配信システムによれば、頻繁に更新される情報を多数の異なるバージョンを持つクライアントへ効率良く確実に配信することができるとしている。
【００１３】
特許文献５に記載の暗号通信路の確立方法は、第１の装置と第２の装置の間で共通鍵を用いて暗号化したメッセージを暗号通信するための暗号通信路の確立方法であって、第１の装置は、第１の装置に関連した第１の公開鍵、第１の公開鍵の証明情報、及び、第１の乱数を第２の装置へ送付し、第２の装置は第１の公開鍵の証明情報が真正であることを検証し、第２の装置は、第２の装置に関連した第２の公開鍵、第２の公開鍵の証明情報、及び、第２の乱数を第１の装置へ送付し、第１の装置は第２の公開鍵の証明情報が真正であることを検証する鍵情報交換手順と、第１の装置は、暗号通信路を確立するための共通鍵を生成し、共通鍵を第２の公開鍵を用いて暗号化し、暗号化された共通鍵を第２の装置へ送付し、第２の装置は暗号化された共通鍵を第２の公開鍵に対応した第２の秘密鍵で復号化する鍵共有手順と、第１の装置は、第２の乱数及び共通鍵のペアを攪拌し、第１の公開鍵に対応した第１の秘密鍵を用いて攪拌されたペアから第１の署名情報を作成し、第２の装置へ送付し、第２の装置は第１の署名情報を第１の公開鍵を用いて検証し、第２の装置は、第１の乱数及び共通鍵のペアを攪拌し、第２の公開鍵に対応した第２の秘密鍵を用いて攪拌されたペアから第２の署名情報を作成し、第１の装置へ送付し、第１の装置は第２の署名情報を第２の公開鍵を用いて検証する相互認証手順と、を有するものである。
【００１４】
この暗号通信路の確立方法によれば、装置間で公開鍵証明書及びチャレンジデータを交換するための２回のコマンドと、装置間でセクション鍵を共有するためのコマンドと、装置間で相互認証を行うコマンドとを実行することにより、暗号通信を行う装置間で、最小限の通信回数と処理時間で、相互認証を行い、安全な暗号通信路を確立することができるとしている。
【００１５】
特許文献６に記載の利用者情報の分散管理装置は、信頼できるピアから構成される信頼グループによるコミュニティにおける利用者情報の分散管理装置であって、コミュニティを構成する各ピアは、信頼グループ機能部とコミュニケーション機能部からなるコミュニティサービス装置を備え、信頼グループ機能部は信頼グループ管理手段とピア管理手段とログ解析手段と電子証明書生成手段を有し、コミュニケーション機能部は通信手段とログ管理手段と電子証明書管理手段を有し、信頼グループ管理手段は、他の信頼グループ管理手段と信頼グループの信頼できるピア情報の連絡を行い、信頼グループの信頼できるピア情報の一覧を管理し、電子証明書生成手段による電子証明書の発行のための共通鍵を信頼グループを構成する他の信頼できるピアと共有する機能を有し、ログ解析手段は、一般ピアから受信するログを解析し、不正がなければ、電子証明書生成手段に一般ピアへの電子証明書の発行を指示し、不正があれば、ピア管理手段に一般ピアの不正を通知する機能を有し、ピア管理手段は、ログ解析手段から、一般ピアの不正通知を受け、一般ピアの一般ピア一覧からの削除および不正ピア一覧への登録を行い、信頼グループ管理手段から宛先情報を得て、全ての他の信頼できるピアのピア管理手段に一般ピアの不正を通知し、信頼できるピアの管理する一般ピアに一般ピアの不正を通知する機能を有し、電子証明書生成手段は、ログ解析手段からの指示により、不正のない一般ピアに電子証明書およびコミュニティに共通で、電子証明書の解読に必要な公開鍵を発行する機能を有し、通信手段は、コミュニティの他の一般ピアとの通信のために、電子証明書管理手段から電子証明書を取得し、通信相手の他の前記一般ピアに送信し、通信相手から受信する電子証明書の正当性の判定を電子証明書管理手段に依頼する機能を有し、ログ管理手段は、信頼グループのピアのピア管理手段にログを定期的に送信し、電子証明書の更新要求を行う機能を有し、電子証明書管理手段は信頼グループのピアの電子証明書生成手段から電子証明書および電子証明書解読のための公開鍵を受信、管理し、電子証明書により通信相手の正当性を判定し、コミュニティへの一般ピアの新規参加のために参加要求を送信する機能を有するものである。
【００１６】
この利用者情報の分散管理装置によれば、信頼できるピアから構成される信頼グループによるコミュニティにおける利用者情報を分散管理することにより、利用者情報の管理に特定の設備を設ける必要がない、ログ解析による大規模なコミュニティにおける利用者の管理が可能、不正なピアをコミュニティから排除でき、コミュニティの安全性を維持することができる、利用者はコミュニティに安心して参加し、コミュニケーションを楽しむことができるとしている。
【００１７】
特許文献７に記載の通信ネットワークにおけるセキュリティは、通信リンクを介して、第１の通信装置と第２の通信装置との間にセキュリティ保護されたピアツーピア型の通信を確立する方法であって、各通信装置は、対応する通信装置と他の通信装置との間で事前に確立されたセキュリティアソシエーションのセットをそれぞれ格納しており、方法は、事前に確立されたセキュリティアソシエーションのセットにおいて共通のセキュリティアソシエーションを第１の通信装置及び第２の通信装置がそれぞれ有しているかを判定するステップと、第１の通信装置及び第２の通信装置が共通のセキュリティアソシエーションを有していると判定された場合、共通のセキュリティアソシエーションに基づいて第１の通信装置と第２の通信装置との間の通信リンクを保護し、一方で、共通のセキュリティアソシエーションを有していると判定されなかった場合、第１の通信装置と第２の通信装置との間に新しいセキュリティアソシエーションを確立して新しいセキュリティアソシエーションに基づき通信リンクを保護するステップと、保護された通信リンクを介して対応する鍵のデータを通信することにより、第１の通信装置及び第２の通信装置がそれぞれ有する事前に確立されたセキュリティアソシエーションのセットを、第１の通信装置及び第２の通信装置のうち対応する他方の通信装置に拡張するステップとを含むものである。
【００１８】
この通信ネットワークにおけるセキュリティによれば、２つの通信装置が通信リンクを介して初めて接続されるとき、これらの通信装置は、事前に確立された共通のセキュリティアソシエーションを有するかを判定する。事前に確立されたそのようなセキュリティアソシエーションが存在する場合、セキュリティアソシエーションは、２つの装置間の通信リンクを保護するための基礎として使用される。一方、セキュリティアソシエーションが存在しない場合、新しいセキュリティアソシエーション、好ましくは共有の秘密状態が、通信リンクを保護するために鍵交換プロトコルに基づいて確立される。鍵交換プロトコルは、パスワードによる認証を実行するプロトコルであることが好ましい。すなわち、少なくとも１つの装置にパスワードを入力するようにユーザに対して要求することが好ましい。その後、２つの装置は、それぞれ事前に確立されたセキュリティアソシエーションに関連付けられた鍵データを交換し、それにより、これらの事前のセキュリティアソシエーションを対応する他方の装置に拡張又は伝播する。その結果、各装置が他の装置とのセキュリティアソシエーションを確立しかつ他方の装置にセキュリティアソシエーションを伝播することを可能にするメカニズムが提供されるとしている。
【特許文献１】特開平１０−２６０９０３号公報
【特許文献２】特開２００５−２５２４４４号公報
【特許文献３】特開２００２−２９０３９６号公報
【特許文献４】再特ＷＯ２０００−０３３１９３号公報
【特許文献５】特開２００２−３３０１２５号公報
【特許文献６】特開２００６−１４８１９７号公報
【特許文献７】特表２００６−５２６３１４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１９】
しかしながら上述した技術では、鍵の更新の考慮がなく、サーバを必要とし、各メンバが自由に共通鍵の生成、更新、削除を行うことができず、共通鍵の管理者およびメンバによる特別な操作なく予め許可した範囲内で自動的に共通鍵を配信することができないという問題がある。
【００２０】
そこで、本発明の目的は、各メンバが自由に共通鍵の生成・更新・削除を行うことができ、共通鍵の管理者およびメンバによる特別な操作なく予め許可した範囲内で自動的に共通鍵を配信することができる共通鍵自動配布システム、クライアント、第三者認証機関側サーバ、及び共通鍵自動共有方法を提供することにある。
【課題を解決するための手段】
【００２１】
本発明のシステムは、共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、各クライアントの存在を保証する第三者認証機関側サーバとを備えたことを特徴とする。
【００２２】
本発明のクライアントは、共通鍵の生成、更新、削除、及び交換機能を有する複数のクライアントと、各クライアントに接続された第三者認証機関側サーバとを有する共通鍵自動共有システムに用いられるクライアントであって、各クライアントは、他のクライアントとの間でピアツーピア型の通信を行うことを特徴とする。
【００２３】
本発明の第三者認証機関側サーバは、共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、第三者認証機関側サーバとを有する共通鍵自動共有システムに用いられる第三者認証機関側サーバであって、第三者認証機関側サーバは、各クライアントの存在を保証することを特徴とする。
【００２４】
本発明の共通鍵自動共有方法は、ピアツーピア型の通信を用いて共通鍵の生成、更新、削除、及び交換を複数のクライアントが行い、各クライアントの存在を第三者認証機関側サーバが保証することを特徴とする。
【発明の効果】
【００２５】
本発明によれば、ピアツーピア型通信を用いた鍵交換を行うため、鍵交換、配信にサーバを必要としない。このため、クライアントが自由に共通鍵の作成・更新・削除を行うことができる。また、ピアツーピア型通信を用いた鍵交換および証明書を用いた本人確認を自動的に行うため、クライアントが意識することなく、所有することを許可されたメンバにのみ、鍵情報の交換・配信を行うことができる。
【発明を実施するための最良の形態】
【００２６】
［特 徴］
ファイルの暗号化に使用する共通鍵の配布において、鍵管理用サーバを使用せず、ピアツーピア型の通信で、予め定められた範囲に限定して自動的に配布可能とし、かつ、共通鍵の生成を各メンバで自由に行うことを可能とする。
【００２７】
本発明に係る共通鍵自動共有システムの一実施の形態は、共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、各クライアントの存在を保証する第三者認証機関側サーバとを備えたことを特徴とする。
【００２８】
上記構成によれば、ピアツーピア型通信を用いた鍵交換を行うため、鍵交換、配信にサーバを必要としない、このため、クライアントが自由に共通鍵の作成・更新・削除を行うことができる。また、ピアツーピア型通信を用いた鍵交換および証明書を用いた本人確認を自動的に行うため、クライアントが意識することなく、所有することを許可されたメンバにのみ、鍵情報の交換・配信を行うことができる。
【００２９】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、各クライアントは、公開鍵ペア及びクライアント情報を作成し、第三者認証機関側サーバに対して証明書の発行申請を行う証明書申請機能を有することを特徴とする。
【００３０】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、各クライアントは、第三者認証機関側サーバから返却された証明書及び公開鍵を登録する証明書登録機能を有することを特徴とする。
【００３１】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、各クライアントは、共通鍵の生成及び自ら生成した共通鍵の更新及び削除を行う鍵管理機能を有することを特徴とする。
【００３２】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、各クライアントは、共通鍵の配布対象の決定及び共通鍵交換要求の対象となるメンバ情報を登録するメンバ登録機能を有することを特徴とする。
【００３３】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、各クライアントは、メンバと互いに所有している共通鍵の交換を行う鍵交換機能を有することを特徴とする。
【００３４】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、各クライアントからの認証申請を受け付ける申請受付機能を有することを特徴とする。
【００３５】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、いずれかのクライアントから申請されたクライアント情報の真正性を確認する真正性確認機能を有することを特徴とする。
【００３６】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、各クライアントもしくは鍵に関する情報が正しいことを保証するために第三者認証機関側サーバ自身が持つ秘密鍵で署名を行い、証明書を作成する証明書作成機能を有することを特徴とする。
【００３７】
本発明に係る共通鍵自動共有システムの他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、署名したクライアント情報を、申請したクライアントに返却する証明書返却機能を有することを特徴とする。
【００３８】
本発明に係るクライアントの一実施の形態は、共通鍵の生成、更新、削除、及び交換機能を有する複数のクライアントと、各クライアントに接続された第三者認証機関側サーバとを有する共通鍵自動共有システムに用いられるクライアントであって、各クライアントは、他のクライアントとの間でピアツーピア型の通信を行うことを特徴とする。
【００３９】
本発明に係る第三者認証機関側サーバの一実施の形態は、共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、第三者認証機関側サーバとを有する共通鍵自動共有システムに用いられる第三者認証機関側サーバであって、第三者認証機関側サーバは、各クライアントの存在を保証することを特徴とする。
【００４０】
本発明に係る共通鍵自動共有方法の一実施の形態は、ピアツーピア型の通信を用いて共通鍵の生成、更新、削除、及び交換を複数のクライアントが行い、各クライアントの存在を第三者認証機関側サーバが保証することを特徴とする。
【００４１】
上記構成によれば、ピアツーピア型通信を用いた鍵交換を行うため、鍵交換、配信にサーバを必要としない。このため、クライアントが自由に共通鍵の作成・更新・削除を行うことができる。また、ピアツーピア型通信を用いた鍵交換および証明書を用いた本人確認を自動的に行うため、クライアントが意識することなく、所有することを許可されたメンバにのみ、鍵情報の交換・配信を行うことができる。
【００４２】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、各クライアントは、公開鍵ペア及びクライアント情報を作成し、第三者認証機関側サーバに対して証明書の発行申請を行うことを特徴とする。
【００４３】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、各クライアントは、第三者認証機関側サーバから返却された証明書及び公開鍵を登録することを特徴とする。
【００４４】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、各クライアントは、共通鍵の生成及び自ら生成した共通鍵の更新及び削除を行うことを特徴とする。
【００４５】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、各クライアントは、共通鍵の配布対象の決定及び共通鍵交換要求の対象となるメンバ情報を登録することを特徴とする。
【００４６】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、各クライアントは、メンバと互いに所有している共通鍵の交換を行うことを特徴とする。
【００４７】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、前記各クライアントからの認証申請を受け付けることを特徴とする。
【００４８】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、いずれかのクライアントから申請されたクライアント情報の真正性を確認することを特徴とする。
【００４９】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、各クライアントもしくは鍵に関する情報が正しいことを保証するために第三者認証機関側サーバ自身が持つ秘密鍵で署名を行い、証明書を作成することを特徴とする。
【００５０】
本発明に係る共通鍵自動共有方法の他の実施の形態は、上記構成に加え、第三者認証機関側サーバは、署名したクライアント情報を、申請したクライアントに返却することを特徴とする。
【００５１】
なお、上述した実施の形態は、本発明の好適な実施の形態の一例を示すものであり、本発明はそれに限定されることなく、その要旨を逸脱しない範囲内において、種々変形実施が可能である。
【実施例】
【００５２】
次に本発明に係る実施例について図を参照して説明する。
［構 成］
図１は、本発明に係る共通鍵自動共有システムの一実施例を示す概念図である。
本共通鍵自動共有システムでは、共通鍵の生成・更新・削除、および、鍵交換などの機能を有するクライアント101〜103と、クライアント101〜103の存在を保証する信頼できる第三者認証機関側サーバ（以下、CAと表記する）104の２つで構成されている。
【００５３】
CA104の主な機能としては、以下の(a)〜(e)の機能が挙げられる。
(a)クライアント101〜103からの認証申請を受け付ける申請受付機能104-1
(b)申請されたクライアント情報の真正性を確認する真正性確認機能104-2
(c)そのクライアント情報が正しいことを保証するためにCA104のもつ秘密鍵で署名を行い、証明書を作成(d)する証明書作成機能104-3
(e)署名したクライアント情報を申請者に返却する証明書返却機能104-5
【００５４】
また、CA104では、CA自身の公開鍵（以下、CA公開鍵）および秘密鍵（以下、CA秘密鍵）が格納されている。CA公開鍵はクライアント101〜103が自由に取得できるように公開されている。また、CA秘密鍵は、証明書作成機能104-3のみがアクセスできるように、耐タンパな領域に厳重に管理される。
【００５５】
クライアント101〜103からの認証を受け付ける申請受付機能104は、クライアント101〜103が生成したクライアント情報を、メールやWeb、郵送などの情報伝達手段により取得する。
【００５６】
申請されたクライアント情報の真正性を確認する真正性確認機能は、申請受付機能104-1にて受け付けたクライアント情報について、情報に誤りが無いことを確認し、信頼できると判断した場合、証明書作成機能104-3に署名依頼を行う。
【００５７】
証明書作成機能104-3では、真正性確認機能104-2にて真正性が確認され、署名を依頼されたクライアント情報に対し、CA秘密鍵を用いて署名を行い証明書(電子証明書)を生成する。
証明書返却機能104-5では、証明書作成機能104-3により署名されたクライアント情報（以下、クライアント証明書と表記する）とCA公開鍵104-6とを、申請したクライアントに対して返信する。
【００５８】
クライアント101〜103の主な機能としては、以下の(a)〜(e)の機能がある。
(a)クライアントの公開鍵ペアやクライアント情報を作成しCAに対して証明書の発行申請を行う証明書申請機能（認証申請機能）102-4
(b)CAから返却されたクライアント証明書およびCA公開鍵を登録する証明書登録機能102-5
(c)共通鍵の生成や、自らが生成した共通鍵の更新・削除を行う鍵管理機能102-1
(d)共通鍵の配布対象の決定や、共通鍵交換要求の対象となるメンバ情報を登録するメンバ登録機能102-3
(e)メンバと互いに所有している共通鍵の交換を行う鍵交換機能102-2
【００５９】
図２は、図１に示したクライアントの構成図の一例である。
また、クライアント101〜103（図１参照）には、クライアント101〜103の公開鍵(以下、公開鍵と記載)および秘密鍵（以下、秘密鍵と記載）104-4、CA104から発行されたクライアント証明書、CA公開鍵104-6、メンバ登録したメンバのクライアント証明書を集めたメンバ情報リスト、鍵の配布状況が記録された所有鍵情報リストが格納されている。
さらに、ファイルの暗号化に使用する共通鍵の鍵情報は鍵管理部に格納されパスワード保護などにより厳重に管理されている。その他に、クライアント101〜103には、クライアント101〜103間で交換する情報の安全性を確保するための暗号化部213、復号部214やクライアント101〜103間で交換する情報の信頼性を保証するための検証部215を備える。
【００６０】
認証申請機能203(図１の認証申請機能102-4に対応）は、初期設定機能として動作し、クライアント101〜103の公開鍵ペアを生成する公開鍵ペア生成部203-1、クライアントの固有情報、組織情報、公開鍵情報などが記載されたクライアント情報リストを生成するクライアント情報生成部203-2、および、生成したクライアント情報をCA104(図１参照)へ認証申請する申請部203-3から構成される。
【００６１】
公開鍵ペア生成部203-1では、公開鍵ペアを生成し、それぞれクライアント公開鍵格納部217、クライアント秘密鍵格納部216へ格納する。クライアント秘密鍵格納部216は、鍵交換機能202(図１の鍵交換機能102-2に対応)、鍵管理機能206、復号部214のみがアクセスできるように、耐タンパな領域に厳重に管理される。
【００６２】
クライアント情報生成部203-2は、クライアントの氏名などの固有情報や会社組織情報、および、公開鍵ペア生成部203-1で生成したクライアント公開鍵などをクライアント情報として生成する。
【００６３】
申請部203-3は、クライアント情報生成部203-2で生成されたクライアント情報をCA104へ送付するとともに、CA104に対して証明書の発行申請を行う。
【００６４】
証明書登録機能204(図１の証明書登録機能102-5に対応)は、CA104によって発行されたクライアント証明書を受信する証明書受信部204-1、受信したクライアント証明書およびCA公開鍵を登録する登録部204-2で構成される。
【００６５】
証明書受信部204-1は、CA104によって発行されたクライアント証明書およびCA104より送付されたCA公開鍵を受信し、受信したクライアント証明書およびCA公開鍵を登録部204-2へと送付する。
【００６６】
登録部204-2は、送付されたクライアント証明書およびCA公開鍵をそれぞれ、クライアント証明書格納部211、および、CA公開鍵格納部212に格納する。また、メンバ情報リストを作成し、メンバ情報リスト格納部210へ格納する。
【００６７】
鍵管理機能206(図１の鍵管理機能102-1に対応)は、ファイルの暗号化に使用する共通鍵の鍵情報を生成する鍵情報生成部207、自らが生成した共通鍵の鍵情報を更新する鍵情報更新部219、及び自らが生成した共通鍵の鍵情報を削除する鍵情報削除部206で構成される。
【００６８】
さらに、鍵情報生成部207は、ユーザによる鍵生成命令によりファイルの暗号化に使用する共通鍵を生成する共通鍵生成部207-1、鍵表示名や有効期限など鍵の付加情報を入力する鍵情報入力部207-2、鍵の配布可能範囲を設定する配布範囲指定部207-3、生成した共通鍵・入力された鍵の付加情報・設定した配布可能範囲などの情報をまとめ鍵情報として生成する鍵情報合成部207-4、および、生成した鍵情報を所有鍵情報リストに反映する所有鍵情報リスト更新部208から構成される。
【００６９】
共通鍵生成部207-1では、ユーザへ暗号アルゴリズム、および、鍵長を選択させると共に、選択された内容に基づき、共通鍵を生成する。
【００７０】
鍵情報入力部207-2では、ユーザによる共通鍵の表示名や共通鍵の有効期限など、鍵の付加情報の入力を受け付ける。
配布範囲指定部207-3では、メンバ情報リスト格納部210からメンバ情報を入手する。クライアント101〜103(図１参照)は、取得したメンバ情報から個人や組織などの単位で生成した共通鍵の配布を許可する範囲を指定する。
【００７１】
鍵情報合成部207-4では、共通鍵生成部207-1で生成された共通鍵、鍵情報入力部207-2で入力された付加情報、および配布範囲指定部207-3で設定された配布可能範囲を収集すると共に、鍵情報ID、共通鍵ID、作成日、更新日、鍵作成者などの情報を付与し、鍵情報を作成する。
さらに、クライアント秘密鍵格納部216から秘密鍵を取得し、生成した鍵情報に対して署名を行い、鍵情報を鍵情報管理部220へ格納する。
【００７２】
所有鍵情報リスト更新部208では、所有鍵情報リスト格納部209から所有鍵情報リストを入手し、鍵情報合成部207-4で生成した鍵情報を所有鍵情報リストに追加・更新し、所有鍵情報リスト格納部209へ格納する。
【００７３】
鍵情報更新部219は、さらに、鍵情報管理部220から鍵情報を取得する鍵情報収集部219-1、鍵の暗号アルゴリズムや鍵長・鍵表示名や有効期限など鍵の付加情報や共通鍵の配布範囲を変更する鍵情報変更部219-2、および、変更した鍵情報を所有鍵情報リストに反映する所有鍵情報リスト更新部208から構成される。
【００７４】
鍵情報収集部219-1では、鍵情報管理部220からクライアント101〜103(図１参照)で作成した鍵情報のみを取得し、変更する鍵情報を選択する。
鍵情報変更部219-2では、共通鍵を更新する場合は共通鍵生成部207-1と連携し、有効期限などの付加情報を更新する場合は鍵情報入力部207-2と連携し、鍵の配布可能範囲を更新する場合は配布範囲指定部207-3と連携し、各情報を更新する。
さらに、更新日などを更新し、クライアント秘密鍵格納部216から秘密鍵を取得し、更新した鍵情報に対して署名を行い、鍵情報を鍵情報管理部220へ格納する。
所有鍵情報リスト更新部208では、所有鍵情報リスト格納部209から所有鍵情報リストを入手し、鍵情報変更部219-2で更新した鍵情報に基づき、所有鍵情報リストを更新し、所有鍵情報リスト格納部209へ格納する。
【００７５】
鍵情報削除部205は、さらに、鍵情報管理部220から鍵情報を取得する鍵情報収集部205-1、削除対象として選択された鍵情報の削除処理を行う鍵情報削除部205-2、および、削除処理した鍵情報を所有鍵情報リストに反映する所有鍵情報リスト更新部209から構成される。
【００７６】
鍵情報収集部219-1では、鍵情報管理部220からクライアント101〜103(図１参照)で作成した鍵情報のみを取得し、削除する鍵情報を選択する。
鍵情報削除部205-2では、削除対象の鍵情報に対して、共通鍵の削除、更新日の更新を行う。そして、クライアント秘密鍵格納部216から秘密鍵を取得し、更新した鍵情報に対して署名を行い、鍵情報を鍵情報管理部220へ格納する。
所有鍵情報リスト更新部208では、所有鍵情報リスト格納部209から所有鍵情報リストを入手し、鍵情報削除部205-2で削除した鍵情報に基づき、所有鍵情報リストを更新し、所有鍵情報リスト格納部209へ格納する。
【００７７】
メンバ登録機能201(図１のメンバ登録機能102-3に対応)は、さらに、メンバ情報リストの交換要求の送受信を行う、メンバ情報交換要求送受信部201-5、クライアント証明書の送受信を行うクライアント証明書送受信部202-4、メンバ情報リスト格納部210からメンバ情報リストを取得するメンバ情報リスト取得部201-3、取得したメンバ情報リストを送受信するメンバ情報リスト送受信部201-2、受信したメンバ情報リストを元に所有するメンバ情報リストを更新し、メンバ情報リスト格納部210へ格納するメンバ情報リスト更新部201-1から構成される。
【００７８】
メンバ情報交換要求送受信部201-5では、要求送信側クライアント(以下、要求者と記載)はネットワークを通じて他クライアントに対しメンバ情報リストの交換要求を送信する。また、要求受信側クライアント（以下、受信者と記載）は、交換要求を受信すると要求者に対し承諾の応答を返す。
要求者が受信者からの承諾応答を受信した場合、クライアント証明書送受信部202-3へクライアント証明書の送信を依頼する。
クライアント証明書送受信部202-2では、要求者はメンバ情報交換要求送受信部201-5での受信者からの承諾応答に従い、クライアント証明書格納部211からクライアント証明書を取得し、受信者に対して送付する。
受信者は、要求者から送付されたクライアント証明書を検証部215へ送付する。検証部215で正常と判断された場合、メンバ情報リスト取得部201-3へ取得要求をする。
【００７９】
メンバ情報リスト取得部201-3では、メンバ情報リスト格納部201からメンバ情報リストを、クライアント証明書格納部211からメンバ情報に記載されているリストメンバのクライアント証明書（以下、メンバクライアント証明書と記載）取得し、メンバ情報リスト送受信部201-2へ渡す。
【００８０】
メンバ情報リスト送受信部201-2では、メンバ情報リスト取得部201-3で取得したメンバ情報リストおよびメンバクライアント証明書を暗号化部に送付し、暗号化部213で暗号化されたメンバ情報リストおよびメンバクライアント証明書（暗号化済みメンバ情報と記載）を受け取り、要求者へ送信する。要求者では、暗号化済みメンバ情報を受信すると復号部214へ送付し、復号部214からメンバ情報リストおよびメンバクライアント証明書を取得し、メンバ情報リスト更新部201-1へ送付する。
【００８１】
メンバ情報リスト更新部201-1では、メンバ情報リスト格納部210から現在のメンバ情報リストを取得し、取得したメンバ情報リストと比較を行い、現在のメンバ情報リストに記載のないメンバのメンバクライアント証明書をクライアント証明書格納部211に登録するとともに、メンバ情報リストの更新を行い、メンバ情報リスト格納部210へ更新したメンバ情報リストを格納する。
【００８２】
鍵交換機能202は、さらに、鍵情報の交換要求の送受信を行う鍵情報交換要求送受信部202-1、クライアント証明書の送受信を行うクライアント証明書送受信部202-2、所有鍵情報リスト格納部209から所有鍵情報リストを取得し、送受信する所有鍵情報リスト送受信部202-3、取得した鍵情報リストをもとに送付対象の鍵情報を鍵情報管理部220から取得し送受信する鍵情報送受信部202-4、取得した鍵情報を基に鍵情報の登録を行う鍵情報登録部202-5、所有鍵情報リスト格納部209から所有鍵情報リストを取得し、登録した鍵情報を基に所有鍵情報リストを更新し格納する所有鍵情報リスト更新部208から構成される。
【００８３】
鍵情報交換要求送受信部202-1では、要求者はネットワークを通じて他クライアントに対し鍵情報の交換要求を送信する。また、受信者は、交換要求を受信すると要求者に対し承諾の応答を返す。要求者が受信者からの承諾応答を受信した場合、クライアント証明書送受信部202-2へクライアント証明書の送信を依頼する。
【００８４】
クライアント証明書送受信部202-2では、要求者は受信者からの承諾応答を受け、クライアント証明書格納部211からクライアント証明書を取得し、受信者に対して送付する。受信者は、要求者から送付されたクライアント証明書を検証部215へ送付する。検証部215で正常と判断された場合、受信者はクライアント証明書格納部211からクライアント証明書を取得し、要求者に対して送付すると共に、所有鍵情報リストの送信要求を行う。要求者は、受信者から送付されたクライアント証明書を検証部215へ送付し、検証部で正常と判断された場合、所有鍵情報リスト送受信部202-3へ所有鍵情報リストの送信依頼を行う。
【００８５】
所有鍵情報リスト送受信部202-3では、所有鍵情報リスト格納部209から所有鍵情報リストを取得し、暗号化部213へ送付する。続いて、暗号化部213から暗号化された所有鍵情報リスト（以下、暗号化済み所有鍵情報リストと記載）を取得し受信者へ送付する。受信者では、暗号化済み所有鍵情報リストを受信すると復号部214へ送付し、復号部214から復号された所有鍵情報リストを得る。さらに、所有鍵情報リスト格納部209から所有鍵情報リストを取得し、復号した所有鍵情報リストと比較して送付対象となる鍵情報の選定を行う。
【００８６】
鍵情報送受信部202-4では、所有鍵情報リスト送受信部202-3で選定された送付対象となる鍵情報を鍵情報管理部220から取得し、取得した鍵情報の配布可能範囲内であるか確認を行った後、暗号化部213へ送付する。暗号化部213から暗号化された鍵情報を受け取り、要求者へ送付する。要求者は暗号化された鍵情報を受け取ると、復号部214へ送付し、復号された鍵情報を取得する。
鍵情報登録部202-5では、取得した鍵情報を鍵情報管理部220に登録を行う。
所有鍵情報リスト更新部208では、所有鍵情報リスト格納部209から所有鍵情報リストを入手し、取得した鍵情報に基づき、所有鍵情報リストを更新し、所有鍵情報リスト格納部209へ格納する。
尚、図中218は通信部である。
【００８７】
［動 作］
次に、図２〜図１２を参照して本発明に係る共通鍵自動配布システムの実施例の動作について詳細に説明する。
本発明に係る共通鍵自動配布システムの動作は、大きく以下の(a)〜(d)の動作に分けられる。
(a)公開鍵ペアの作成やクライアント情報の登録などを行う初期設定
(b)ファイルの暗号化に使用する鍵情報の生成・更新・削除
(c)クライアント間における鍵情報の交換
(d)クライアント間におけるメンバ情報の交換
【００８８】
まず、初期設定の動作について図３、図４を参照して詳細に説明する。
図３は、図１に示した共通鍵自動配布システムに用いられるクライアント証明書の一例である。図４は、図１に示した共通鍵自動配布システムに用いられるクライアントの初期設定フローの一例である。
図４において、本発明に係る共通鍵自動配布システムに用いられるクライアント101〜103(図１参照)では、クライアント情報の生成を開始すると、公開鍵ペア生成部203-1にて、公開鍵と秘密鍵とのペアが生成され、それぞれクライアント公開鍵格納部217およびクライアント秘密鍵格納部216に格納される（ステップ(1)〜(3)）。
次に、クライアント情報生成部207にて、クライアント101〜103の固有情報（氏名やIDなど）や組織情報（会社名、部署名、役職など）に加え、クライアント公開鍵格納部217から公開鍵および公開鍵に関する情報を取得し、クライアント情報として図３に示すようなクライアント証明書を生成する。ただし、この時点では署名領域は未記入である（以下、本状態のクライアント証明書をクライアント情報と表記する：ステップ(4)〜(6)）。
【００８９】
続いて、申請部203-3にてクライアント情報をCA104(図１参照)に提出する。CA104への証明書発行申請は、メールやWeb、郵送などの情報伝達手段を用いて行われる（ステップ(7)）。
CA104では、クライアント101〜103が生成したクライアント情報を、メールやWeb、郵送などの情報伝達手段により申請受付機能104-1(図１参照)にて取得し、真正性確認機能104-2(図１参照)で、申請受付機能104-1にて取得したクライアント情報の各情報に誤りが無いことを確認し、信頼できると判断した場合、証明書作成機能104-3(図１参照)にてCA秘密鍵を用いて署名を行う。
本処理では、送付されたクライアント情報の署名領域部分に証明書発効日などの情報を記載し、クライアント証明書として生成する（ステップ(8)〜(11)）。
【００９０】
次に、証明書返却機能104-5にて、クライアント証明書をクライアント101〜103へ送付する。このとき、CA公開鍵についても合わせて送付する（図４ステップ(12)〜(13)）。
クライアント101〜103では、CA104から送付されたクライアント証明書およびCA公開鍵を証明書送受信部204-1にて受け取り（ステップ(14)）、登録部204-2にてクライアント証明書をクライアント証明書格納部211に登録し、CA公開鍵をCA公開鍵格納部212に登録すると共に、クライアント証明書の情報を元にメンバ情報リスト（図１１）を生成し、メンバ情報リスト格納部210に登録する（図４ステップ(15)〜(16)）。
図１１は、図１に示した共通鍵自動配布システムに用いられるメンバ情報リストの一例である。
【００９１】
次に、鍵の生成・更新・削除の動作について図５から図９を参照して詳細に説明する。
図５は、図１に示した共通鍵自動配布システムに用いられる鍵情報の一例を示す図である。図６は、図１に示した共通鍵自動配布システムに用いられるクライアントの鍵生成フローの一例を示す図である。図７は、図１に示した共通鍵自動配布システムに用いられるクライアントの鍵更新フローの一例を示す図である。図８は、図１に示した共通鍵自動配布システムに用いられるクライアントの鍵削除フローの一例を示す図である。図９は、図１に示した共通鍵自動配布システムに用いられる所有鍵情報リストの一例である。
【００９２】
鍵の生成では、図６に示すとおり、まず共通鍵生成部207-1(図２参照)にて暗号化アルゴリズムおよび鍵長を指定し（ステップS601）、鍵生成命令を行い(ステップS602)、共通鍵を生成する(ステップS603)。
続いて、鍵情報入力部207-2(図２参照)にて鍵の表示名や鍵の有効期限などの付加情報を入力する(ステップS604)。
【００９３】
次に、配布範囲指定部207-3(図２参照)にてメンバ情報リスト格納部210からメンバ情報リストを取得し(ステップS605)、本リストの情報を元に鍵の配布範囲の指定を行う(ステップS606)。
これら情報をもとに、鍵情報合成部207-4では図５に示すような鍵情報のうち署名値のないものを鍵情報仮生成として行い(ステップS607)、クライアント秘密鍵格納部216からクライアント秘密鍵を取得し(ステップS608)、鍵情報に署名を行い(ステップS609)、正式な鍵情報を生成する(ステップS610)。生成した鍵情報は鍵情報管理部220へ格納する(ステップS611)。
【００９４】
最後に、所有鍵情報リスト更新部208にて、所有鍵情報リスト格納部209から図９に示すような所有鍵情報リストを取得し(ステップS612)、生成した鍵情報リストを更新後(ステップS613)、所有鍵情報リスト格納部209へ再度格納する(ステップS614)。
【００９５】
鍵の更新では、図７に示すとおり、鍵情報収集部209-1にて鍵情報管理部220から鍵情報の鍵作成者となっている鍵のみを取得し(ステップS701)、取得した鍵情報から更新を実施する鍵情報を選択する(ステップS702)。
続いて、鍵情報変更部209-2で、共通鍵の更新を行う場合は、鍵情報生成部207の共通鍵生成部207-1に依頼を行い、共通鍵生成部207-1にて暗号化アルゴリズムおよび鍵長を指定および鍵生成命令を行う。すなわち、共通鍵を更新するか否かを判断し(ステップS703)、更新しない場合(ステップS703/NO)にはステップS706に進み、更新する場合(ステップS703/YES)には、暗号アルゴリズム、鍵長を指定し(ステップS704)、共通鍵を生成し(ステップS705)、ステップS706へ進む。付加情報を更新する場合は、鍵情報生成部207の鍵情報入力部207-2に依頼を行い、鍵情報入力部207-2にて鍵の表示名や鍵の有効期限などの付加情報の入力を行う。すなわち、ステップS706では付加情報を更新するか否かを判断し、更新しない(ステップS706/NO)にはステップS708に進み、更新する場合(ステップS706/YES)には、鍵の付加情報を入力し(ステップS707)、ステップS708に進む。
【００９６】
鍵情報の配布可能範囲を更新する場合は、鍵情報生成部207の配布範囲指定部に依頼を行い、配布範囲指定部にてメンバ情報リスト格納部210からメンバ情報リストを取得し、本リストの情報を元に鍵の配布範囲の指定を行う。すなわち、ステップS708では配布可能範囲を更新するか否かを判断し、更新しない場合(ステップS708/NO)にはステップS711に進み、更新する場合(ステップS708/YES)には、メンバ情報リストを取得し(ステップS709)、鍵の配布範囲を指定し(ステップS710)、ステップS711に進む。
【００９７】
最後に、鍵情報変更部219-2では、これら更新内容に基づき鍵情報を更新するとともに更新日の更新を行い(ステップS711)、クライアント秘密鍵格納部216から秘密鍵を取得し(ステップS712)、鍵情報への再署名を行い(ステップS713)署名値を修正し、これら更新処理を行った鍵情報を作成し(ステップS714)、更新した鍵情報を鍵情報管理部220へ格納する(ステップS715)。
【００９８】
続いて、所有鍵情報リスト更新部208にて、所有鍵情報リスト格納部209から図９に示すような所有鍵情報リストを取得し(ステップS716)、更新した鍵情報の更新部分を変更(リスト更新：ステップS717)後、所有鍵情報リスト格納部209へ再度格納する(ステップS718)。
鍵の削除では、図８に示すとおり、鍵情報収集部219-1にて鍵情報管理部220から鍵情報の鍵作成者となっている鍵のみを取得し(ステップS801)、取得した鍵情報から削除を実施する鍵情報を選択する(ステップS802)。
【００９９】
次に、鍵情報削除部205-2では鍵情報の共通鍵部分を削除し、暗号化・復号に使用できない状態にするとともに更新日の更新を行う(ステップS803)。
【０１００】
クライアント秘密鍵格納部216からクライアント秘密鍵を取得し(ステップS804)、鍵情報への再署名を行い(ステップS805)、署名値を修正し、これら削除処理を行った鍵情報を作成(ステップS806)、鍵情報管理部220へ格納する(ステップS807)。
【０１０１】
続いて、所有鍵情報リスト更新部208にて、所有鍵情報リスト格納部209から図９に示すような所有鍵情報リストを取得し(ステップS808)、削除した鍵情報の情報を変更（リスト更新：ステップS809）後、所有鍵情報リスト格納部209へ再度格納する(ステップS810)。
【０１０２】
次に、クライアント間における鍵情報の交換の動作について、図１０を参照して詳細に説明する。
図１０は、図１に示した共通鍵自動配布システムに用いられるクライアント間の鍵情報交換フローの一例である。
本実施例における説明では、鍵の交換要求を行う側をクライアントAとし、鍵の交換要求に応じて鍵情報を提供する側をクライアントBとする。
クライアントAの鍵情報交換要求送受信部202-1から他のクライアントに対し鍵情報交換の要求を送信する(ステップ(1))。
クライアントBの鍵情報交換要求送受信部202-1では、クライアントAからの鍵情報交換要求を受信すると、鍵情報交換承諾の応答をクライアントAへ返す(ステップ(2))。
クライアントAの鍵情報交換要求送受信部202-1で、クライアントBからの鍵情報交換承諾の応答を受信すると、クライアント証明書送受信部202-2にてクライアント証明書格納部211から自身のクライアント証明書（以下、クライアントA証明書と記載）を取得し、クライアントBへ送付する(ステップ(3))。
クライアントBのクライアント証明書送受信部202-2にて、クライアントA証明書を受信すると、クライアントA証明書を検証部215へ送付する。検証部215では、CA公開鍵格納部212からCA公開鍵を入手し、CA公開鍵を用いてクライアントA証明書がCAから正式に正しく発行され改ざんされていない証明書であるか否かの検証を行う(ステップ(4))。
検証結果が正常であった場合、クライアント証明書送受信部202-2では、クライアント証明書格納部211から自身のクライアント証明書（以下、クライアントB証明書と記載）を取得し、クライアントAへ送付すると共に、所有鍵情報リスト要求を行う。なお、検証部215での検証結果が正常でない場合は処理を終了する(ステップ(5))。
クライアントAのクライアント証明書送受信部202-2にて、クライアントB証明書および所有鍵情報リスト要求を受信すると、クライアントB証明書を検証部215に送付する。検証部215では、CA公開鍵格納部212からCA公開鍵を入手し、CA公開鍵を用いてクライアントB証明書がCAから正式に正しく発行され改ざんされていない証明書であるか否かの検証を行う(ステップ(6))。
検証結果が正常であった場合、所有鍵情報リスト送受信部202-3にて、所有鍵情報リスト格納部209から所有鍵情報リストを取得（以下、所有鍵情報リストAと記載）し、クライアントB証明書と共に暗号化部へ送付する。なお、検証部215での検証結果が正常でない場合は処理を終了する。暗号化部213では、クライアントB証明書からクライアントBの公開鍵を入手し、クライアントBの公開鍵で所有鍵情報リストAを暗号化し、所有鍵情報リスト送受信部202-3へ返却する(ステップ(7))。
【０１０３】
所有鍵情報リスト送受信部202-3は、暗号化された所有鍵情報リストAをクライアントBへ送付する(ステップ(8))。
クライアントBの所有鍵情報リスト送受信部202-3が、暗号化された所有鍵情報リストAを受信すると、所有鍵情報リスト送受信部202-3は復号部214へ送付する。復号部214では、クライアント秘密鍵格納部216から秘密鍵を取得して、暗号化された所有鍵情報リストAを復号し、所有鍵情報リスト送受信部202-3へ返却する(ステップ(9))。
【０１０４】
所有鍵情報リスト送受信部202-3では、所有鍵情報リスト格納部202-3から所有鍵情報リストを取得（以下、所有鍵情報リストBと記載）し、所有鍵情報リストAと比較を行い、クライアントAへの送付対象となる鍵情報を選定を行い(ステップ(10))、選定結果を鍵情報送受信部202-4へ通知する。なお、選定基準は以下の通り。
・所有鍵情報リストBにあり、所有鍵情報リストAにない鍵情報（パターンA）
・所有鍵情報リストA、B共に存在するが、所有鍵情報リストBにある鍵情報の方が更新日が新しい場合（パターンB）。
【０１０５】
鍵情報送受信部202-4では、取得した選定結果を基に鍵情報管理部220から該当する鍵情報を取得する。なお、パターンAに属する鍵情報の場合、鍵情報の配布可能範囲にクライアントAが該当するか否かの確認を行い、該当する鍵情報のみを取得する(ステップ(11))。
【０１０６】
鍵情報送受信部202-4では、取得した鍵情報をクライアントA証明書と共に暗号化部213へ送付し、暗号化部213では、クライアントA証明書からクライアントAの公開鍵を入手し、クライアントAの公開鍵で鍵情報を暗号化し、鍵情報送受信部202-4へ返却する(ステップ(12))。
鍵情報送受信部202-4は、暗号化された鍵情報をクライアントAへ送付する(ステップ(13))。
クライアントAの鍵情報送受信部202-4では、暗号化された鍵情報を受信すると、復号部214へ送付する。復号部214では、クライアント秘密鍵格納部216から秘密鍵を取得して、暗号化された鍵情報を復号し、鍵情報送受信部202-4へ返却する(ステップ(14))。
【０１０７】
鍵情報登録部202-5では、復号された鍵情報を鍵情報送信部202-4から受け取り、検証部215に送付する。検証部215では、クライアント証明書格納部211から、鍵情報の作成者に対応するクライアント証明書を取得し、クライアント証明書から公開鍵を取り出し鍵情報の検証を行う。検証結果が正常でない場合は鍵情報を破棄する。検証結果が正常な場合は、鍵情報管理部220へ登録する。登録方法は以下の(i)、(ii)の通り。
【０１０８】
(i)所有していない鍵情報は、鍵情報の配布可能範囲に該当していることを確認し登録
(ii)所有している鍵情報で、更新されている鍵は、鍵情報管理部220から該当の鍵情報を取得・更新し鍵情報を再登録。なお、更新されている鍵のパターンとしては、更新（鍵 情報のいずれかが変更されている）と削除（鍵情報の共通鍵が削除されている）
の２つがある。
鍵情報の登録が完了後、所有鍵情報リスト更新部208では、所有鍵情報リスト格納部209から所有鍵情報リストを取得し(ステップ(15))、鍵情報の登録内容を所有鍵情報リストに反映し、所有鍵情報リスト格納部209に再格納する(ステップ(16))。
【０１０９】
最後に、クライアント間におけるメンバ情報の交換の動作について、図１２を参照して詳細に説明する。
図１２は、図１に示した共通鍵自動配布システムに用いられるクライアント間のメンバ情報リスト交換フローの一例である。
本実施例における説明では、メンバ情報リストの交換要求を行う側をクライアントAとし、メンバ情報リストの交換要求に応じてメンバ情報を提供する側をクライアントBとする。
【０１１０】
クライアントAのメンバ情報交換要求送受信部201-5から他のクライアントに対しメンバ情報リスト交換の要求を送信する(ステップ(1))。
クライアントBのメンバ情報交換要求送受信部201-5では、クライアントAからのメンバ情報リスト交換要求を受信すると、メンバ情報リスト交換承諾の応答をクライアントAへ返す(ステップ(2))。
クライアントAのメンバ情報交換要求送受信部201-5で、クライアントBからのメンバ情報リスト交換承諾の応答を受信すると、クライアント証明書送受信部201-4にてクライアント証明書格納部211から自身のクライアント証明書（以下、クライアントA証明書と記載）を取得し、クライアントBへ送付する(ステップ(3))。
【０１１１】
クライアントBのクライアント証明書送受信部201-4にて、クライアントA証明書を受信すると、クライアントA証明書を検証部215へ送付する。検証部では、CA公開鍵格納部212からCA公開鍵を入手し、CA公開鍵を用いてクライアントA証明書がCAから正式に正しく発行され改ざんされていない証明書であるか否かの検証を行う(ステップ(4))。
検証結果が正常であった場合、メンバ情報リスト取得部201-3では、メンバ情報リスト格納部210からメンバ情報リストを取得する（以下、メンバ情報リストBと記載）と共に、クライアント証明書格納部211からメンバ情報リストBに記載されているメンバのクライアント証明書（以下、メンバクライアント証明書と記載）を取得する(ステップ(5))。
【０１１２】
続いて、メンバ情報リスト送受信部201-2では、取得したメンバ情報リストBおよびメンバクライアント証明書に加え、クライアントA証明書を暗号部213に送付し、クライアントA証明書からクライアントAの公開鍵を入手し、クライアントAの公開鍵でメンバ情報リストBおよびメンバクライアント証明書を暗号化し、メンバ情報リスト送受信部201-2へ返却する(ステップ(6))。
メンバ情報リスト送受信部201-2は、暗号化されたメンバ情報リストBおよびメンバクライアント証明書をクライアントAへ送付する(ステップ(7))。
【０１１３】
クライアントBのメンバ情報リスト送受信部201-2では、暗号化されたメンバ情報リストBおよびメンバクライアント証明書を受信すると、復号部214へ送付する。復号部214では、クライアント秘密鍵格納部216から秘密鍵を取得して、暗号化されたメンバ情報リストBおよびメンバクライアント証明書を復号し、メンバ情報リスト送受信部201-2へ返却する(ステップ(8))。
メンバ情報リスト更新部201-1では、復号されたメンバ情報リストBおよびメンバクライアント証明書をメンバ情報リスト送受信部201-2から受け取る共に、メンバ情報リスト格納部210から現在のメンバ情報リストを取得（以下、メンバ情報リストAと記載）し、メンバ情報リストAとメンバ情報リストBとの比較を行う。比較の結果、メンバ情報リストAに記載のないメンバのメンバクライアント証明書をクライアント証明書格納部211に登録するとともに、メンバ情報リストAに追加する。
最後に、更新されたメンバ情報リストAはメンバ情報リスト格納部210に格納される(ステップ(9))。
【０１１４】
本発明の効果は、以下の通りである。
・ピアツーピア型を用いた鍵交換を行うため、鍵交換・配信にサーバを必要としない。また、クライアントが自由に鍵の作成・更新・削除を行うことができる。
・ピアツーピア型を用いた鍵交換および証明書を用いた本人確認を自動的に行うため、クライアントが意識することなく、所有することを許可されたメンバにのみ、鍵情報の交換・配信を行うことができる。
【０１１５】
なお、上述した実施例は、本発明の好適な実施例の一例を示すものであり、本発明はそれに限定されることなく、その要旨を逸脱しない範囲内において、種々変形実施が可能である。
【０１１６】
ここで、前述した特許文献１〜７に記載の発明と本願との相違点について述べる。
＜特許文献１＞
特許文献１に記載の発明は、複数ユーザで共有するファイルを自動的に暗号化・復号するシステムだが、共有ディスク上のファイルの暗号化に限定されている点や暗号化に使用する鍵がクライアントの個別データを使用しており、鍵の更新などを考慮していない点が本願発明と異なる。
【０１１７】
＜特許文献２＞
特許文献２では暗号化ファイルに用いた鍵のグループ内での共有方法について述べているが、暗号化装置と認証装置を必要とするシステムであり、サーバ不要としクライアント間で鍵を交換する本願発明とは異なる。
【０１１８】
＜特許文献３＞
特許文献３には複数端末間における暗号化鍵の自動更新同期方式について記載されているが、暗号化鍵の利用目的が通信路の暗号化であり、あらかじめ事前に複数の鍵を送付して、ある一定のタイミングで使用する鍵を次のものへと変える形であり、共有するファイルの暗号化を目的とし、ピアツーピア型の通信でクライアント間で随時鍵の交換を行う本願発明とは異なる。
【０１１９】
＜特許文献４＞
特許文献４に記載の発明は、クライアントから入手したリストを基に、更新情報をサーバが供給している点で本願発明とは異なる。
【０１２０】
＜特許文献５＞
特許文献５に記載の発明は、公開鍵及びセッション鍵を用いた端末間の通信路の安全性を確保するものであり、ごく一般的な技術である。また、特許文献５に記載の発明は、リスト交換時における公開鍵を用いた暗号化による通信の保安性確保であり、本願発明とは異なる。
【０１２１】
＜特許文献６＞
特許文献６に記載の発明は、信頼できる端末のみと端末情報を交換し信頼できる端末グループを形成し、信頼できる端末グループ内で使用する鍵を共有しているのであり、任意のメンバ間で使用する共通鍵の配布範囲を指定する点で本願発明とは異なる。また、特許文献６に記載の発明は、交換するメンバの情報には配布範囲を指定するための補助的情報があるだけで、配布可能な範囲の情報は共通鍵情報自体が持つ点で本願発明とは異なる。
【０１２２】
＜特許文献７＞
特許文献７に記載の発明は、リストを交換することで互いに共有する情報を取得し、共有する情報を基に鍵共有を行っている点で本願発明とは異なる。
【図面の簡単な説明】
【０１２３】
【図１】本発明に係る共通鍵自動共有システムの一実施例を示す概念図である。
【図２】図１に示したクライアントの構成図の一例である。
【図３】図１に示した共通鍵自動配布システムに用いられるクライアント証明書の一例である。
【図４】図１に示した共通鍵自動配布システムに用いられるクライアントの初期設定フローの一例である。
【図５】図１に示した共通鍵自動配布システムに用いられる鍵情報の一例を示す図である。
【図６】図１に示した共通鍵自動配布システムに用いられるクライアントの鍵生成フローの一例を示す図である。
【図７】図１に示した共通鍵自動配布システムに用いられるクライアントの鍵更新フローの一例を示す図である。
【図８】図１に示した共通鍵自動配布システムに用いられるクライアントの鍵削除フローの一例を示す図である。
【図９】図１に示した共通鍵自動配布システムに用いられる所有鍵情報リストの一例である。
【図１０】図１に示した共通鍵自動配布システムに用いられるクライアント間の鍵情報交換フローの一例である。
【図１１】図１に示した共通鍵自動配布システムに用いられるメンバ情報リストの一例である。
【図１２】図１に示した共通鍵自動配布システムに用いられるクライアント間のメンバ情報リスト交換フローの一例である。
【符号の説明】
【０１２４】
１０１〜１０３ クライアント
１０２−１ 鍵管理機能
１０２−２ 鍵交換機能
１０２−３ メンバ登録機能
１０２−４ 認証申請機能
１０２−５ 証明書登録機能
１０４ 第三者認証機関側サーバ（ＣＡ）
１０４−１ 申請受付機能
１０４−２ 真正性確認機能
１０４−３ 証明書作成機能
１０４−４ ＣＡ秘密鍵
１０４−５ 証明書返却機能
１０４−６ ＣＡ公開鍵
【特許請求の範囲】
【請求項１】
共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、前記各クライアントの存在を保証する第三者認証機関側サーバとを備えたことを特徴とする共通鍵自動共有システム。
【請求項２】
前記各クライアントは、公開鍵ペア及びクライアント情報を作成し、前記第三者認証機関側サーバに対して証明書の発行申請を行う証明書申請機能を有することを特徴とする請求項１記載の共通鍵自動共有システム。
【請求項３】
前記各クライアントは、前記第三者認証機関側サーバから返却された証明書及び公開鍵を登録する証明書登録機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項４】
前記各クライアントは、共通鍵の生成及び自ら生成した共通鍵の更新及び削除を行う鍵管理機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項５】
前記各クライアントは、共通鍵の配布対象の決定及び共通鍵交換要求の対象となるメンバ情報を登録するメンバ登録機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項６】
前記各クライアントは、メンバと互いに所有している共通鍵の交換を行う鍵交換機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項７】
前記第三者認証機関側サーバは、前記各クライアントからの認証申請を受け付ける申請受付機能を有することを特徴とする請求項１記載の共通鍵自動共有システム。
【請求項８】
前記第三者認証機関側サーバは、いずれかのクライアントから申請されたクライアント情報の真正性を確認する真正性確認機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項９】
前記第三者認証機関側サーバは、前記各クライアントもしくは前記鍵に関する情報が正しいことを保証するために前記第三者認証機関側サーバ自身が持つ秘密鍵で署名を行い、証明書を作成する証明書作成機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項１０】
前記第三者認証機関側サーバは、署名したクライアント情報を、申請したクライアントに返却する証明書返却機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項１１】
共通鍵の生成、更新、削除、及び交換機能を有する複数のクライアントと、前記各クライアントに接続された第三者認証機関側サーバとを有する共通鍵自動共有システムに用いられるクライアントであって、
前記各クライアントは、他のクライアントとの間でピアツーピア型の通信を行うことを特徴とするクライアント。
【請求項１２】
共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、第三者認証機関側サーバとを有する共通鍵自動共有システムに用いられる第三者認証機関側サーバであって、
前記第三者認証機関側サーバは、前記各クライアントの存在を保証することを特徴とする第三者認証機関側サーバ。
【請求項１３】
ピアツーピア型の通信を用いて共通鍵の生成、更新、削除、及び交換を複数のクライアントが行い、前記各クライアントの存在を第三者認証機関側サーバが保証することを特徴とする共通鍵自動共有方法。
【請求項１４】
前記各クライアントは、公開鍵ペア及びクライアント情報を作成し、前記第三者認証機関側サーバに対して証明書の発行申請を行うことを特徴とする請求項１３記載の共通鍵自動共有方法。
【請求項１５】
前記各クライアントは、前記第三者認証機関側サーバから返却された証明書及び公開鍵を登録することを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項１６】
前記各クライアントは、共通鍵の生成及び自ら生成した共通鍵の更新及び削除を行うことを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項１７】
前記各クライアントは、共通鍵の配布対象の決定及び共通鍵交換要求の対象となるメンバ情報を登録することを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項１８】
前記各クライアントは、メンバと互いに所有している共通鍵の交換を行うことを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項１９】
前記第三者認証機関側サーバは、前記各クライアントからの認証申請を受け付けることを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項２０】
前記第三者認証機関側サーバは、いずれかのクライアントから申請されたクライアント情報の真正性を確認することを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項２１】
前記第三者認証機関側サーバは、前記各クライアントもしくは前記鍵に関する情報が正しいことを保証するために前記第三者認証機関側サーバ自身が持つ秘密鍵で署名を行い、証明書を作成することを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項２２】
前記第三者認証機関側サーバは、署名したクライアント情報を、申請したクライアントに返却することを特徴とする請求項１４項記載の共通鍵自動共有方法。
【請求項１】
共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、前記各クライアントの存在を保証する第三者認証機関側サーバとを備えたことを特徴とする共通鍵自動共有システム。
【請求項２】
前記各クライアントは、公開鍵ペア及びクライアント情報を作成し、前記第三者認証機関側サーバに対して証明書の発行申請を行う証明書申請機能を有することを特徴とする請求項１記載の共通鍵自動共有システム。
【請求項３】
前記各クライアントは、前記第三者認証機関側サーバから返却された証明書及び公開鍵を登録する証明書登録機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項４】
前記各クライアントは、共通鍵の生成及び自ら生成した共通鍵の更新及び削除を行う鍵管理機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項５】
前記各クライアントは、共通鍵の配布対象の決定及び共通鍵交換要求の対象となるメンバ情報を登録するメンバ登録機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項６】
前記各クライアントは、メンバと互いに所有している共通鍵の交換を行う鍵交換機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項７】
前記第三者認証機関側サーバは、前記各クライアントからの認証申請を受け付ける申請受付機能を有することを特徴とする請求項１記載の共通鍵自動共有システム。
【請求項８】
前記第三者認証機関側サーバは、いずれかのクライアントから申請されたクライアント情報の真正性を確認する真正性確認機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項９】
前記第三者認証機関側サーバは、前記各クライアントもしくは前記鍵に関する情報が正しいことを保証するために前記第三者認証機関側サーバ自身が持つ秘密鍵で署名を行い、証明書を作成する証明書作成機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項１０】
前記第三者認証機関側サーバは、署名したクライアント情報を、申請したクライアントに返却する証明書返却機能を有することを特徴とする請求項２記載の共通鍵自動共有システム。
【請求項１１】
共通鍵の生成、更新、削除、及び交換機能を有する複数のクライアントと、前記各クライアントに接続された第三者認証機関側サーバとを有する共通鍵自動共有システムに用いられるクライアントであって、
前記各クライアントは、他のクライアントとの間でピアツーピア型の通信を行うことを特徴とするクライアント。
【請求項１２】
共通鍵の生成、更新、削除、及び交換機能を有し、ピアツーピア型の通信を行う複数のクライアントと、第三者認証機関側サーバとを有する共通鍵自動共有システムに用いられる第三者認証機関側サーバであって、
前記第三者認証機関側サーバは、前記各クライアントの存在を保証することを特徴とする第三者認証機関側サーバ。
【請求項１３】
ピアツーピア型の通信を用いて共通鍵の生成、更新、削除、及び交換を複数のクライアントが行い、前記各クライアントの存在を第三者認証機関側サーバが保証することを特徴とする共通鍵自動共有方法。
【請求項１４】
前記各クライアントは、公開鍵ペア及びクライアント情報を作成し、前記第三者認証機関側サーバに対して証明書の発行申請を行うことを特徴とする請求項１３記載の共通鍵自動共有方法。
【請求項１５】
前記各クライアントは、前記第三者認証機関側サーバから返却された証明書及び公開鍵を登録することを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項１６】
前記各クライアントは、共通鍵の生成及び自ら生成した共通鍵の更新及び削除を行うことを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項１７】
前記各クライアントは、共通鍵の配布対象の決定及び共通鍵交換要求の対象となるメンバ情報を登録することを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項１８】
前記各クライアントは、メンバと互いに所有している共通鍵の交換を行うことを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項１９】
前記第三者認証機関側サーバは、前記各クライアントからの認証申請を受け付けることを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項２０】
前記第三者認証機関側サーバは、いずれかのクライアントから申請されたクライアント情報の真正性を確認することを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項２１】
前記第三者認証機関側サーバは、前記各クライアントもしくは前記鍵に関する情報が正しいことを保証するために前記第三者認証機関側サーバ自身が持つ秘密鍵で署名を行い、証明書を作成することを特徴とする請求項１４記載の共通鍵自動共有方法。
【請求項２２】
前記第三者認証機関側サーバは、署名したクライアント情報を、申請したクライアントに返却することを特徴とする請求項１４項記載の共通鍵自動共有方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００９−２１２６８９（Ｐ２００９−２１２６８９Ａ）
【公開日】平成２１年９月１７日（２００９．９．１７）
【国際特許分類】
【出願番号】特願２００８−５２２１２（Ｐ２００８−５２２１２）
【出願日】平成２０年３月３日（２００８．３．３）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２１年９月１７日（２００９．９．１７）
【国際特許分類】
【出願日】平成２０年３月３日（２００８．３．３）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]