JP2005304093A - 暗号化通信のための鍵配付方法及びシステム - Google Patents

Abstract

【課題】
通信元端末が、複数の通信先端末と暗号化通信を行う場合には、通信元端末は、それぞれの通信先端末と鍵を共有し、また、それぞれの通信先端末を認証する必要がある。したがって、通信元端末の処理負荷が大きい。
【解決手段】
管理サーバ１０と、検証サーバ２０を設置する。端末３０と端末４０は、暗号化通信のための利用可能な設定情報を管理サーバ１０に登録しておく。暗号化通信を行う際には、管理サーバ１０が、登録された設定情報から一致するものを探し、端末３０と端末４０が利用可能な当該暗号化通信用の鍵を生成し、一致した設定情報と共に配付する。また、管理サーバ１０は検証サーバ２０と連携して、端末３０と端末４０を認証する。端末３０は
、管理サーバ１０が端末４０を認証した結果を信頼し、端末４０は、管理サーバ１０が端末３０を認証した結果を信頼することで、それぞれ通信相手端末を認証する必要がなくなる。
【選択図】図１

Description

本発明は、暗号化通信のための鍵を、通信元端末と通信先端末に、配付する方法およびシステムに関する。

ネットワークを通じて通信元端末装置と通信先端末装置（以下、端末装置を端末という
）が暗号化通信を行う場合には、データを暗号化して送受信する。通信元端末と通信先端末は、あらかじめ、通信元端末と通信先端末の間の暗号化通信、のための設定情報と鍵を共有し、共有した設定情報と鍵を用いて暗号化通信を行う。

例えば、公開鍵暗号を用いて、鍵を共有する場合には、以下のように行う。

通信元端末は、通信先端末の公開鍵を取得し、通信先端末と暗号化通信を行うための鍵を生成し、当該公開鍵を用いて、当該暗号化通信用の鍵、を暗号化し、通信先端末に送信する。また、通信先端末は、当該公開鍵で暗号化された、当該暗号化通信用の鍵を、通信元端末より受信し、通信先端末の秘密鍵で復号する。

上記の方法では、通信元端末が、複数の通信先端末と暗号化通信を行うためには、それぞれの通信先端末と、当該暗号化通信のための設定情報と鍵を共有する必要があり、通信元端末の負荷が大きくなるという課題があった。

そこで、ネットワーク上に、前記暗号化通信用の、設定情報と、鍵を、通信元端末と通信先端末に配付するサーバ装置（以下、サーバという）を設置し、通信元端末と通信先端末は、当該サーバから配付された、前記暗号化通信用の設定情報と鍵を用いて、暗号化通信を行う技術が提案されている（非特許文献１）。

また、ネットワークを通じた通信で、通信相手の正当性を確認するためには、通信を行う前に、通信相手を認証する必要がある。通信相手を認証する方法の一つに、電子署名を用いる方法がある。具体的には、通信を行う通信元端末と通信先端末が、お互いに電子署名を付与したＩＤと公開鍵証明書を交換し、受け取った電子署名と公開鍵証明書を検証することにより通信相手を認証する。

Mark Baugher 外３名、"MSEC Group Key Management Architecture <draft-ietf-msec-gkmarch-07.txt> "、[online]、January 30，2003、IETF(Internet Engineering Task Force)、Ｐ.３−１３、[平成１６年４月２日検索]、インターネット＜URL:http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-07.txt＞

通信元端末が、複数の通信先端末と暗号化通信を行うためには、それぞれの通信先端末と、当該暗号化通信のための設定情報と鍵を共有する必要があり、通信元端末の負荷が大きくなる。

例えば、通信元端末が、公開鍵暗号を用いて、通信先端末と暗号化通信のための鍵を共有するためには、通信元端末は、通信先端末の公開鍵の取得、暗号化通信のための鍵の生成、取得した公開鍵を用いた暗号化通信のための鍵の暗号化、の処理が必要であり、通信元端末の負荷が大きい。

この課題を解決するために、上記非特許文献１の技術を用いた場合、サーバが、通信元端末と通信先端末間の、暗号化通信用の設定情報と鍵を生成し、通信元端末と通信先端末に配付することになる。ただし、端末は配付された設定情報や鍵をサポートしているとは限らない。通信元端末あるいは通信先端末は、サポートしていない設定情報や鍵を配付された場合、通信元端末と通信先端末の間で、暗号化通信を行うことができない。

また、通信元端末と通信先端末は、通信相手の正当性を確認するためには、それぞれ通信相手を認証する処理を行う。しかしながら、通信元端末が、複数の通信先端末と暗号化通信を行う場合には、通信先端末をそれぞれ認証し、通信相手の正当性を確認する必要があり、通信元端末の処理負荷が大きくなる。

本発明は、ネットワーク上に、端末間通信を管理する、管理サーバを配した通信システムを提供する。

本発明の通信システムでは、以下のステップを行うことにより、通信元端末と通信先端末が、通信元端末と通信先端末の間の暗号化通信、で利用する鍵を共有する。

あらかじめ、通信元端末と通信先端末が、それぞれ利用可能な前記暗号化通信のための設定情報を、管理サーバに登録しておく。

通信元端末が、通信先端末に接続する際には、管理サーバに通知し、管理サーバは、通信元端末と通信先端末の設定情報から一致するものを探す。

管理サーバは、一致した設定情報に基づき、暗号化通信用の、鍵あるいは、鍵の種となる情報を生成し、一致した設定情報とともに、通信元端末と通信先端末に配付する。通信元端末と通信先端末は、管理サーバから設定情報と鍵の種となる情報を配付された場合は
、鍵の種となる情報から鍵を生成し、管理サーバから配付された設定情報と、生成あるいは送付された鍵を用いて暗号化通信を行う。

また、上記通信システムは、管理サーバが、通信元端末と通信先端末とを電子署名を用いて認証することで、通信元端末と通信先端末が、お互いに相手を認証したとみなす、ことを特徴とする。

管理サーバは、通信元端末から通信先端末との通信を要求された場合に、両端末の認証を行い、認証に成功した場合に、両端末間の通信を許可する。管理サーバが当該通信を許可した後に、通信元端末は通信先端末に接続することができる。

さらに、管理サーバは、公開鍵証明書を検証する検証サーバ装置（以下、検証サーバという）に通信元端末と通信先端末の公開鍵証明書の検証を依頼しても良い。

検証サーバが当該公開鍵証明書を検証することで、通信元端末と通信先端末をより確実に認証することができる。

本発明によれば、通信元端末は、通信元端末と通信先端末の間の暗号化通信、のための設定情報や鍵を、通信先端末と、共有するための処理を行う必要がない。

さらに、通信元端末と通信先端末は、確実に暗号化通信を行うことができる。

また、本発明によれば、通信元端末と通信先端末は、通信相手を直接認証する必要がなく、処理負荷が軽減される。

以下、本発明の実施の形態を詳細に説明する。なお、これによって本発明が限定されるものではない。

図１は、本発明の実施の一形態に係わる鍵配付システムの構成を示すブロック図である
。

図１の鍵配付システムは、ネットワーク５０に端末３０、端末４０、管理サーバ装置（
以下、管理サーバという）１０、検証サーバ装置（以下、検証サーバという）２０、が接続している。

端末３０、端末４０はそれぞれ、信頼する認証局からそれぞれに発行された公開鍵証明書３１０、４１０を端末内に保管している。さらに、当該端末間の暗号化通信のための設定情報登録申請機能３０１、４０１と、当該端末のネットワーク上の位置を特定するアドレスを登録するためのアドレス登録申請機能３０２、４０２と、当該端末間の暗号化通信を要求し、必要な鍵や設定情報を管理サーバ１０から受信する鍵・設定情報受信機能３０３、４０３と、当該端末間で暗号化通信を行う対端末通信機能３０４、４０４と、対管理サーバ通信機能３０５、４０５を備えている。

管理サーバ１０は、信頼する認証局から発行された公開鍵証明書１１０と、端末３０と端末４０が暗号化通信を行うための設定情報DB１１１と、端末３０と端末４０のネットワーク上の位置を特定するアドレスDB１１２、を保管している。本実施例においては、上記端末アドレスとして、ＩＰアドレスを用いる。

さらに、管理サーバ１０は、端末３０と端末４０の間の暗号化通信のための鍵を生成する鍵生成機能１０２と、端末３０あるいは端末４０からの設定情報の登録申請を受けて、設定情報を登録する設定情報登録機能１０３と、端末３０から端末４０へ接続する際に、端末３０と端末４０が登録している設定情報から一致するものを探す設定情報探索機能１０４と、端末３０と端末４０の間の暗号化通信のための、鍵や設定情報を配付する、鍵・設定情報配付機能１０５と、端末３０あるいは端末４０からのアドレスの登録申請を受けて、アドレスをアドレスDB１１２に登録するアドレス登録機能１０６と、アドレスDB１１２から端末のアドレスを検索するアドレス検索機能１０７と、端末の認証と通信を行う対端末通信機能１０８と、検証サーバ２０と通信を行う対検証サーバ通信機能１０９を備えている。

検証サーバ２０は、管理サーバ１０が、端末３０や端末４０を認証する際に、公開鍵証明書の有効性を確認する証明書検証機能２０１と、管理サーバ１０と通信を行う対管理サーバ通信機能２０２を備えている。

なお、図１に示す管理サーバ１０と、検証サーバ２０、端末３０、端末４０、の各装置と、これら装置が備える各機能は、例えば、図１１に示すような、ＣＰＵ６１と、メモリ６２と、ハードディスク等の外部記憶装置６３と、インターネットなどのネットワークやＬＡＮ（以下、ネットワークという）５０を介して他装置と通信を行うための通信装置６４と、キーボードやマウス等の入力装置６５と、モニタやプリンタ等の出力装置６６と、可搬性を有する記憶媒体６８から情報を読み取る読取装置６７と、これらの各装置間のデータ送受を行うインタフェース６０とを備えた、電子計算機において、ＣＰＵ６１がメモリ６２上にロードされた所定のプログラムを実行することにより、実現できる。

これらのプログラムは、あらかじめ、上記電子計算機内のメモリ６２または外部記憶装置６３に格納されていても良いし、必要なときに、上記電子計算機が利用可能な、着脱可能な記憶媒体６８または通信媒体（ネットワークやＬＡＮ５０など、またはそれらの上を伝搬する搬送波やデジタル信号など）を介して、導入されてもよい。

なお、本実施例では、端末は、図１１に示されるような構成により実現できるとしているが、本発明はそれに限定されるものではない。図１に示す端末３０と端末４０、の各機器は、ネットワーク５０と接続することのできる通信装置を備えた機器であってもよい。例えば、ルータ、ＰＣ、携帯電話、ＰＤＡ、テレビ、冷蔵庫なども、端末となりうる。

次に本実施の形態による通信システムの動作について説明する。

本実施の形態における通信システムは、まず、端末３０が、ネットワーク５０を介して
、管理サーバ１０とセキュアな通信路を確立する。

ここでは、端末３０が管理サーバ１０との間で暗号化通信路を確立し、暗号化通信を行い、通信を終えるまでの動作を示す。当該通信路を確立する際、端末３０は管理サーバ１０に端末３０の公開鍵証明書を送り、管理サーバ１０は当該公開鍵証明書の有効性の検証を検証サーバ２０に要求し、管理サーバ１０は、検証サーバ２０による当該公開鍵証明書の有効性の検証結果を元に、端末３０を認証する。

まず、端末３０と、管理サーバ１０は、図２に示すフローに従い、公開鍵証明書３１０と公開鍵証明書１１０を交換する。

対管理サーバ通信機能３０５は、管理サーバ１０との間の暗号化通信のための、一つ以上のパラメータの候補を管理サーバ１０に送信する（ステップ１０００）。暗号化通信の
ためのパラメータには、通信データの暗号化に用いる暗号化アルゴリズムの種類、鍵の長さ、通信データの改ざん検知に用いるハッシュ関数の種類、などが含まれる。

対端末通信機能１０８は、端末３０から送られてきた暗号化通信パラメータの候補を受信する（ステップ１００２）。

管理サーバ１０は、受信したパラメータの候補の中から、管理サーバが利用可能なパラメータを一つ選択し、対端末通信機能１０８により、選択したパラメータを端末３０に送信する（ステップ１００４）。

対管理サーバ通信機能３０５は、管理サーバ１０が選択したパラメータを受信する（ステップ１００６）。

以上のステップ１０００からステップ１００６により、端末３０と管理サーバ１０は、パラメータを共有する。

対管理サーバ通信機能３０５は、管理サーバ１０の公開鍵証明書１１０の要求を管理サーバ１０に送信する（ステップ１００８）。

対端末通信機能１０８は、端末３０から送られてきた、公開鍵証明書１１０の要求を受信する（ステップ１０１０）。

管理サーバ１０は、ステップ１０１０で要求を受けた公開鍵証明書１１０を保持している場合（ステップ１０１２でYES）は、管理サーバ１０の公開鍵証明書１１０と、端末３
０の公開鍵証明書要求を、対端末通信機能１０８により、端末３０に送信する（ステップ１０１４）。

対管理サーバ通信機能３０５は、管理サーバ１０の公開鍵証明書１１０と、端末３０の公開鍵証明書の要求を、管理サーバ１０から受信する（ステップ１０１６）。

端末３０は、ステップ１０１６で要求を受けた公開鍵証明書３１０を保持している場合（ステップ１０１８でYES）は、対管理サーバ通信機能３０５により、端末３０の公開鍵
証明書３１０を、管理サーバ１０に送信する（ステップ１０２０）。

対端末通信機能１０８は、端末３０の公開鍵証明書３１０を、端末３０から受信する（
ステップ１０２２）。

対端末通信機能１０８は、端末３０の公開鍵証明書３１０の受信通知を、端末３０に送信する（ステップ１０２４）。

対管理サーバ通信機能３０５は、端末３０の公開鍵証明書３１０の受信通知を、管理サーバ１０より受信する（ステップ１０２６）。

対管理サーバ通信機能３０４は、ステップ１０１６で受信した公開鍵証明書１１０の有効期限、署名を検証することで、公開鍵証明書１１０を検証する（ステップ１０２８）。

端末３０は、公開鍵証明書１１０の検証に成功した場合には、（ステップ１０３０でYE
S）は、図３の処理へ進む。

上記ステップ１０１２または、ステップ１０１８または、ステップ１０３０でNOの場合は、図６のステップ１３１６（Ａ）へ進み、端末３０と管理サーバ１０の通信を終了する処理を行う。ただし、図６は端末３０から通信終了を要求する場合を示しており、ステップ１０１２から進む場合は、管理サーバ１０が通信終了要求を出すので、端末３０と管理サーバ１０との動作が入れ替わる。

次に、管理サーバ１０は、図３に示すフローに従い、検証サーバ２０に、端末３０の公開鍵証明書の検証を要求し、検証結果を受け取る。

対検証サーバ通信機能１０９は、検証サーバ２０に端末３０の公開鍵証明書３１０を送信する（ステップ１１００）。

対管理サーバ通信機能２０２は、公開鍵証明書３１０を、受信する（ステップ１１０２
）。

検証サーバ２０は、証明書検証機能２０１により、受信した公開鍵証明書３１０を検証する。なお、公開鍵証明書３１０の検証では、有効期限、署名、公開鍵証明書の失効状態を検証する（ステップ１１０４）。

公開鍵証明書３１０の検証１１０４が成功しなかった場合は（ステップ１１０６でNO）
、対管理サーバ通信機能２０２により、検証サーバ２０の署名を付与した、検証失敗通知を管理サーバ１０に送信する（ステップ１１０８）。

公開鍵証明書３１０の検証１１０４が成功した場合は（ステップ１１０６でYES）、対
管理サーバ通信機能２０２により、検証サーバ２０の署名を付与した、検証成功通知を管理サーバ１０に送信する（ステップ１１１０）。

管理サーバ１０は、対検証サーバ通信機能１０９により、ステップ１１０８あるいはステップ１１１０で送信された、検証失敗通知あるいは検証成功通知を受信し、通知に付与された検証サーバ２０の署名を検証することにより、通知が確かに検証サーバ２０から送付され、改ざんされていないことを確認する（ステップ１１１２）。

管理サーバ１０は、ステップ１１１２で、検証成功通知を受け取った場合は、図４の（
Ｄ）へ処理を進める。ステップ１１１２で検証失敗通知を受け取った場合は、端末３０との接続を終了するために、図６のステップ１３１６（Ａ）に進む。なお、管理サーバ１０が通信終了要求を出すので、図６の端末３０と管理サーバ１０との動作が入れ替わる。

次に、端末３０と管理サーバ１０は、図４に示すように、図２のステップで共有した情報に電子署名を添付して交換し、交換した電子署名を検証することで、相手を認証し、その後、鍵共有を行う。なお、共有情報としては、図２のステップで交換した情報の中で、任意のものを利用できる。

まず、端末３０は、共有情報に対して、電子署名を生成し、共有情報に電子署名を添付して、対管理サーバ通信機能３０５により、管理サーバ１０に送信する（ステップ１２００）。

対端末通信機能１０８は、共有情報と電子署名を端末３０から受信する（ステップ１２０２）。

管理サーバ１０は、受信した電子署名をステップ１０２２で受信した端末３０の公開鍵証明書３１０の公開鍵を用いて、検証する（ステップ１２０４）。

電子署名の検証に成功した場合は（ステップ１２０６でYES）、共有情報に対して、電
子署名を生成し、共有情報に電子署名を添付して、対端末通信機能１０８により、端末３０に送信する（ステップ１２０８）。

対管理サーバ通信機能３０５は、共有情報と電子署名を管理サーバ１０から受信する（
ステップ１２１０）。

端末３０は、受信した電子署名を、ステップ１０１６で受信した管理サーバ１０の公開鍵証明書１１０の公開鍵を用いて、検証する（ステップ１２１２）。

端末３０は、電子署名の検証に成功した場合は（ステップ１２１４でYES）、端末３０
と管理サーバ１０の間の暗号化通信用の、鍵生成ステップ１２１６へ進む。

端末３０は、ステップ１０００からステップ１００６で共有したパラメータを基に、管理サーバ１０と暗号化通信を行うための鍵を生成する（ステップ１２１６）。

管理サーバ１０も、ステップ１０００からステップ１００６で共有したパラメータを基に、端末３０と暗号化通信を行うための鍵を生成する（ステップ１２１８）。

ステップ１２０６またはステップ１２１４でNOの場合（電子署名の検証に失敗した場合
）は、接続を終了するために、図６のステップ１３１６（Ａ）に進む。ただし、図６は端末３０から通信終了を要求する場合を示しており、ステップ１２０６から進む場合は、管理サーバ１０から通信終了要求を出すので、端末３０と管理サーバ１０の動作が入れ替わる。

以上の処理で、端末３０は管理サーバ１０を認証し、管理サーバ１０は、端末３０を認証する。また、端末３０と管理サーバ１０は、端末３０と管理サーバ１０の間の暗号化通信に用いる鍵を共有する。

端末３０と管理サーバ１０はお互いに相手が認証できたら、通信コネクションを確立し
、暗号化通信を行う。

図５は、上記暗号化通信を行うためのコネクションを確立し、上記暗号化通信を行うステップを示したシーケンス図である。

対管理サーバ通信機能３０５は、管理サーバ１０にデータ転送許可要求を送信し（ステップ１３００）、対端末通信機能１０８は、これを受信する（ステップ１３０２）。

対端末通信機能１０８は、データ転送許可と、端末３０に対するデータ転送許可要求を
、端末３０へ送信し（ステップ１３０４）、対管理サーバ通信機能３０５は、これを受信
する（ステップ１３０６）。

対管理サーバ通信機能３０５は、データ転送許可を、管理サーバ１０へ送信し（ステップ１３０８）、対端末通信機能１０８は、これを受信する（ステップ１３１０）。

上記処理により、端末３０と、管理サーバ１０は、お互いにデータ転送許可を出したので、コネクションが確立する（ステップ１３１２）。

コネクション確立後は、図２のステップ１０００からステップ１００６で共有した、前記暗号化通信のためのパラメータと、ステップ１２１６とステップ１２１８で生成した前記暗号化通信用の鍵を用いて、端末３０と、管理サーバ１０は、暗号化通信を行う（ステップ１３１４）。

端末３０と管理サーバ１０は、暗号化通信路が不要になったら、図６に示すシーケンスに従って、コネクションを終了する。 前記暗号化通信を終える場合には、まず、対管理サーバ通信機能３０５は、管理サーバ１０との、通信終了要求を管理サーバ１０に送信し（ステップ１３１６）、
対端末通信機能１０８は、これを受信する（ステップ１３１８）。

対端末通信機能１０８は、通信終了許可と、通信終了許可要求を端末３０へ送信し（ステップ１３２０）、対管理サーバ通信機能３０５は、これらを受信する（ステップ１３２
２）。

対管理サーバ通信機能３０５は、通信終了許可を管理サーバ１０へ送信し（ステップ１３２４）、対端末通信機能１０８は、これを受信する（ステップ１３２６）。

上記処理により、端末３０と、管理サーバ１０は、お互いに通信終了許可を出したので
、コネクションが終了する（ステップ１３２８）。

以上、図２から図６の動作により、端末３０と管理サーバ１０は、お互いに認証し、端末３０と管理サーバ１０の間の暗号化通信路を確立し、暗号化通信を行い、通信を終了することができる。

本実施の形態では、管理サーバ１０が端末３０を厳密に認証するために、図３に示す処理により、公開鍵証明書３１０の検証を検証サーバ２０に要求している。

さらに、端末３０が、管理サーバ１０を厳密に認証するために、公開鍵証明書１１０の検証を、検証サーバ２０に要求してもよい。ステップ１０２８とステップ１０３０に示す処理の代わりに、図３における端末３０と管理サーバ１０を入れ替えた処理を行うことにより、端末３０は、検証サーバ２０に、公開鍵証明書１１０の検証を要求することができる。

図７に示すフローでは、図２から図５の動作シーケンスにより確立した暗号化通信路を用いて、端末３０が、管理サーバ１０にアドレスと、他の端末と暗号化通信を行うための設定情報を登録する。

まず、端末３０と管理サーバ１０は、上記の、ステップ１０００からステップ１０３０と、ステップ１１００からステップ１１１４と、ステップ１２００からステップ１２１８と、ステップ１３００からステップ１３１２により、上記暗号化通信路を確立する（まとめてステップ２０００と記述する）。

次に、端末３０のアドレス登録申請機能３０２と、設定情報登録申請機能３０１は、端末３０のアドレスの登録と、他の端末と暗号化通信を行うための設定情報の登録と、を対管理サーバ通信機能３０５を用いて、管理サーバ１０に要求する（ステップ２００２）。
なお、ステップ２００２では、一つ以上の設定情報の登録要求を送信する。なお、設定情報には、例えば、通信データの暗号化に用いる暗号化アルゴリズムの種類、鍵の長さ、通信データの改ざん検知に用いるハッシュ関数の種類、などが含まれる。

対端末通信機能１０８は、当該アドレスと、暗号化通信用の設定情報を受信する（ステップ２００４）。

管理サーバ１０のアドレス登録機能１０６は、受信した当該アドレスを、図１のアドレス登録機能１０６により、アドレスDB１１２に登録する（ステップ２００６）。詳細は後
述する。

設定情報登録機能１０３は、受信した当該設定情報を、設定情報DB１１１に登録する（
ステップ２００８）。

管理サーバ１０は、当該アドレスと、当該設定情報を登録したことを、端末３０に通知するために、登録完了通知を、対端末通信機能１０８を用いて、端末３０に送信し（ステップ２０１０）、対管理サーバ通信機能３０５は、これを受信する（ステップ２０１２）
。

端末３０と管理サーバ１０は、上記の、ステップ１３１６からステップ１３２６により
、コネクションを終了する（まとめて、ステップ２０１４と記述する）。

上記、図７の処理を行うことにより、端末３０は、管理サーバ１０に自分のアドレスと
、他の端末と暗号化通信を行うための設定情報を、登録することができる。

図７と同様の処理を行うことにより、端末４０も、アドレス登録申請機能４０２と、設定情報登録申請機能４０１により、管理サーバ１０に端末４０のアドレスと、他の端末と暗号化通信を行うための設定情報を登録することができる。

端末４０が登録する場合は、端末４０と管理サーバ１０は、図７の端末３０を端末４０に置き換えたフローを行う。

なお、端末３０、端末４０は、管理サーバ１０に登録したアドレスや設定情報を削除することもできる。削除する場合は、図７の「登録」を「削除」と置き換えた処理を行う。

図７の処理では、端末３０、４０は、自端末に割り当てられたアドレスを管理サーバ１０に登録する。端末３０、４０は、自端末に割り当てられたアドレスが変わった場合には
、最新のアドレスを登録するために、図７の処理を再度行う必要がある。

例えば、アドレスがＩＰアドレスであって、端末が動的にＩＰアドレス割り当てを受けている場合に、端末の電源をＯＦＦ、ＯＮしたり、端末をリセットしたりすると、ＩＰアドレスが変わる可能性がある。また、端末が、ネットワークとの接続を終了し、移動先で
、別のネットワークに接続する場合には、ＩＰアドレスが変わる可能性がある。端末は、ＩＰアドレスを変更した可能性がある場合には、再度、図７の処理を行うことにより、最新のＩＰアドレスを、管理サーバに登録する。

端末３０と端末４０が、図７のシーケンスで、ネットワーク上の位置（ＩＰアドレス）と、他端末と間の暗号化通信用の設定情報とを、管理サーバ１０に登録すると、端末３０は図８と図９に示すフローに従い、管理サーバ１０を介して端末４０との接続処理を行う
。

端末３０と管理サーバ１０は、上記の、ステップ１０００からステップ１０３０と、ステップ１１００からステップ１１１４と、ステップ１２００からステップ１２１８と、ステップ１３００からステップ１３１２により、暗号化通信路を確立する（まとめてステップ２１００と記述する）。

端末３０の鍵・設定情報受信機能３０３は、対管理サーバ通信機能３０５により、端末４０への接続要求を、管理サーバ１０に送信し（ステップ２１０２）、対端末通信機能１
０８は、これを受信する（ステップ２１０４）。なお、接続要求には、接続相手（端末４
０）を特定するＩＤのような情報（以下、端末ＩＤという）が含まれる。端末ＩＤには、ドメイン内で固定のものを使えばよい。例えば、端末名や、端末のＭＡＣアドレスを使うことができる。また、会社内のような閉じたドメインでは、端末のユーザのメールアドレスや、端末のＳＩＰ−ＵＲＩや、端末のＦＱＤＮ（完全修飾ドメイン名、Fully Qualifie
d Domain Name）のような情報を使うこともできる。

管理サーバ１０は、端末３０の接続先である端末４０のアドレスを取得するため、図１のアドレス検索機能１０７により、端末ＩＤをキーとして図１のアドレスDB１１２を検索する（ステップ２１０６）。

管理サーバ１０は、図１の設定情報DB１１１を検索し、端末３０と端末４０の設定情報の候補を取得する。そして、図１の設定情報探索機能１０４により、取得した設定情報から一致するものを探す（ステップ２１０８）。

管理サーバ１０は、端末３０の設定情報と端末４０の設定情報が一つ以上一致したら（
ステップ２１１０でYes）、端末４０との間で、ステップ１０００からステップ１０３０
と、ステップ１１００からステップ１１１４と、ステップ１２００からステップ１２１８と、ステップ１３００からステップ１３１２により、暗号化通信路を確立する（まとめてステップ２１１２と記述する）。

ただし、管理サーバ１０と端末４０の間で暗号化通信路を確立するため、図２、図４、図５の端末３０を管理サーバ１０に置き換え、管理サーバ１０を端末４０に置き換えた処理が行われるものとし、管理サーバ１０と端末４０はそれらの処理に必要な上述の機能を備えるものとする。

さらに、ステップ２１１２では、管理サーバ１０が検証サーバ２０に端末４０の公開鍵証明書の検証を要求するため、管理サーバ１０は、図２のステップ１０２６から図３のＣに進み、図３のＤから図４のＢに進む、また、端末４０は、図２のＣから図４のＤに進む
。

ステップ２１１０で、設定情報が一致しない場合、図６のＡに進み、設定情報が一致しないため接続不可である旨を図６の処理中のメッセージに記載し、端末３０に通知し、端末３０と管理サーバ１０のコネクションを終了する。ただし、図６は端末３０から通信の終了を要求する場合を示しており、ステップ２１１０から進む場合は、管理サーバ１０が通信終了要求を出すので、端末３０と管理サーバ１０の動作が入れ替わる。

ステップ２１１２に続き、対端末通信機能１０８は、確立した暗号化通信路を用いて、端末４０に、ステップ２１０４で受信した、端末３０から端末４０への接続要求を送信し（ステップ２１１４）、対管理サーバ通信機能４０５は、これを受信する（ステップ２１
１６）。

端末４０は、現在通信が可能か否かのような自端末またはそのユーザの状態や、端末４０の独自のポリシによるフィルタリング機能、により、受信した接続要求の許可あるいは拒否を判定する（ステップ２１１８）。

対管理サーバ通信機能４０５は、前記判定結果を、管理サーバ１０に送信し（ステップ２１２０）、対端末通信機能１０８はこれを受信する（ステップ２１２２）。

対端末通信機能１０８は、受信した判定結果を、端末３０に転送し（ステップ２１２４
）、対管理サーバ通信機能３０５は、これを受信する（ステップ２１２６）。

以上の処理により、端末３０と管理サーバ１０の間と、管理サーバ１０と端末４０の間に確立された暗号化通信路を用いて、端末３０と端末４０の間で接続可否の合意がとれる
。

次に、図９に示すフローに従い、管理サーバ１０は、図８のステップ２１０８で探した
、一致する設定情報に従い、端末３０と端末４０の間の暗号化通信用、の鍵を生成し、端末３０と端末４０に当該暗号化通信用の鍵と設定情報を配付する。端末３０と端末４０は
、配付された鍵と設定情報を用いて暗号化通信路を確立する。

端末３０と管理サーバ１０と端末４０は、ステップ２１１８で判定された接続可否の結果を判定する（ステップ２１２８、ステップ２１３０、ステップ２１３２）。なお、ステ
ップ２１２８、ステップ２１３０、ステップ２１３２の判定には、ステップ２１１８の判定結果が反映されるため、すべて同じ結果、(Yes)あるいは、(No)となる。

判定結果が(No)の場合は、端末３０と管理サーバ１０と端末４０は、処理を終了する。

判定結果が(Yes)の場合は、管理サーバ１０の鍵生成機能１０２は、ステップ２１０８
で探した、一致する設定情報に従って、端末３０と端末４０の間の暗号化通信用の鍵を生成する（ステップ２１３４）。なお、ステップ２１３４では、当該暗号化通信用の鍵の代
わりに、当該暗号化通信用の鍵の種となる情報を生成してもよい。

管理サーバ１０は、鍵・設定情報配付機能１０５により、ステップ２１３４で生成した
、鍵あるいは鍵の種となる情報と、ステップ２１０８で探した、一致する設定情報とを、端末３０と端末４０に送信し（ステップ２１３８）、端末３０と端末４０は、鍵・設定情
報受信機能３０３、４０３により、これを受信する（ステップ２１３６、ステップ２１４０）。

端末３０と端末４０の対端末通信機能３０４、４０４は、受信した、端末３０と端末４０の間の暗号化通信用、の鍵と設定情報を利用して、暗号化通信路を確立する（ステップ２１４２）。

なお、管理サーバ１０が、ステップ２１３４で、端末３０と端末４０の間の暗号化通信用、の鍵の種となる情報を生成し、ステップ２１３８で配付した場合は、鍵・設定情報受信機能３０３、４０３が、配付された、当該暗号化通信用、の鍵の種となる情報を用いて
、当該暗号化通信用の鍵を生成し、対端末通信機能３０４、４０４が、生成した鍵と、受信した設定情報を利用して、暗号化通信路を確立する。

端末３０と端末４０は、対端末通信機能３０４、４０４によって、確立した前記暗号化通信路を用いて、暗号化通信を行う（ステップ２１４４）。

以上の処理により、管理サーバ１０は、端末３０と端末４０に、端末３０と端末４０の間の暗号化通信、に必要な、鍵または鍵の種となる情報、と設定情報を配付し、端末３０と端末４０が暗号化通信を行う。

端末３０と端末４０は、暗号化通信（ステップ２１４４）を終えると、図１０に示すフローに従い、通信を終了する。

対管理サーバ通信機能３０５は、終了要求を管理サーバ１０に送信し（ステップ２１４６）、対端末通信機能１０８が、これを受信する（ステップ２１４８）。

対端末通信機能１０８は、受信した終了要求を、端末４０に転送し（ステップ２１５０
）、対管理サーバ通信機能４０５は、これを受信する（ステップ２１５２）。

対管理サーバ通信機能４０５は、終了許可を管理サーバ１０に送信し（ステップ２１５４）、対端末通信機能１０８は、これを受信する（ステップ２１５６）。

対端末通信機能１０８は、受信した終了許可を、端末３０に転送し（ステップ２１５８
）、対管理サーバ通信機能３０５は、これを受信する（ステップ２１６０）。

図１０の以上の処理により、端末３０と管理サーバ１０は、図８のステップ２１００で確立した、端末３０と管理サーバ１０の間の暗号化通信路、のコネクションを終了し（ステップ２１６２）、管理サーバ１０と端末４０は、図８のステップ２１１２で確立した、
管理サーバ１０と端末４０の間の暗号化通信路、のコネクションを終了する（ステップ２１６４）。

また、端末３０と端末４０は、図９のステップ２１４２で確立した、端末３０と端末４０の間の暗号化通信路、のコネクションを終了する（ステップ２１６６）。

なお、端末３０と端末４０は、通信を終了するために図１０に示すフローを必ずしも行う必要はなく、図１０のフローを行わずに、通信を終了してもよい。

図１０のフローを行わない場合、端末３０と管理サーバ１０と端末４０は、図１０の処理を行う必要がないため、処理負荷が小さくなる。また、ステップ２１００とステップ２１１２で確立した暗号化通信路を、ステップ２１４２の前に終了すれば、端末３０と管理サーバの間と、管理サーバ１０と端末４０の間の通信リソースを節約できる。

また、端末３０と管理サーバ１０が、ステップ２１００で確立した暗号化通信路を、ステップ２１３６とステップ２１３８の後に終了し、ステップ２１４４の後に、再度暗号化通信路を確立し、管理サーバ１０と端末４０が、ステップ２１１２で確立した暗号化通信路を、ステップ２１３８とステップ２１４０の後に終了し、ステップ２１４４の後に、再度暗号化通信路を確立してもよい。

その場合、ステップ２１４４の間、端末３０と管理サーバ１０、また、管理サーバ１０と端末４０は、暗号化通信路を確立しておく必要がなく、通信リソースを節約できる。

上記、図８の処理では、ステップ２１００で暗号化通信路を確立するときに、端末３０と管理サーバ１０は、お互いに認証し、ステップ２１１２で暗号化通信路を確立するときに、管理サーバ１０と端末４０はお互いを認証するため、
端末３０は、管理サーバ１０を介して端末４０の正当性を確認することができ、端末４０は、管理サーバ１０を介して端末３０の正当性を確認することができる。

また、上記、図８，９の処理を行うことにより、管理サーバ１０が、端末３０と端末４０があらかじめ登録した、端末３０と端末４０の間の暗号化通信用、の設定情報から一致するものを探索し、当該暗号化通信用の鍵または鍵の種となる情報と、設定情報を配付するため、端末３０と端末４０は、配付された鍵と設定情報を用いて暗号化通信を行うことができる。

本実施の形態では、管理サーバ１０に端末３０，４０のユーザの個人情報を扱う機能を付加した場合に、端末３０，４０が管理サーバ１０に送信するユーザの個人情報の漏洩を防ぐために、図７のステップ２０００では、具体的には、図２から図６の処理を行うことにより、暗号化通信路を確立しているが、管理サーバ１０が個人情報を扱わない場合には
、通信路を暗号化しなくてもよい。通信路を暗号化しない場合には、図２、図３、図４、図５、図６の暗号化通信路を確立するステップにおいて、図４のステップ１２１６と、ステップ１２１８と、を省略し、図５のステップ１３１４では、通信を暗号化しない。

次に、ここまでに示したフローの一部について、詳細を述べる。

図７のステップ２００６では、端末３０のアドレスを、図１のアドレスDB１１２に登録する。図１２の表７００は、アドレスDB１１２の例を示している。

以下、アドレスDB１１２の登録、検索について述べる。

端末３０のアドレス登録申請機能３０２は、図２のステップ２００２の登録要求送信で
、アドレスを管理サーバ１０に送信する。

管理サーバ１０のアドレス登録機能１０６は、ステップ２００４で受信した端末３０のアドレスを、ステップ２００６で、アドレスDB１１２に登録する。

アドレスDB１１２は、例えば、図１２に示す表７００のように構成できる。表７００は
、管理サーバ１０がステップ２１０４で受信する接続要求に含まれる、端末を特定する情報（端末ＩＤ）と、アドレスと、のペアを保管する。

表７００の例では、エントリ７０２、エントリ７０４に、端末３０と端末４０それぞれの端末ＩＤとＩＰアドレスを保管している。なお、一つの端末につき、一つのエントリを保管する。すでに、表７００の例に示す情報が、アドレスDB１１２に登録されている場合に、端末が再度ＩＰアドレスの登録を行う場合は、アドレス登録機能１０６は、ステップ２００６により、該当する端末に関わるエントリのＩＰアドレスの部分を更新する。

また、管理サーバ１０のアドレス検索機能１０７は、図８のステップ２１０６で、端末３０の接続要求先である端末４０のアドレスを検索する。

ステップ２１０６では、図１２のエントリ７０４を参照し、端末４０のＩＰアドレス情報を取得する。

図７のステップ２００８では、端末３０、４０が他端末との暗号化通信で利用可能な、一つ以上の、当該暗号化通信用、の設定情報を、図１の設定情報DB１１１に登録し、図８のステップ２１０８では、設定情報DB１１１を参照し、設定情報から一致するものを探す
。

以下、設定情報DB１１１の登録と、DB１１１に対する、一致する設定情報の探索について述べる。

端末の設定情報登録申請機能３０１は、ステップ２００２の設定情報登録要求送信で、他端末との暗号化通信用、の設定情報の候補を一つ以上、管理サーバ１０に送信する。なお、二つ以上の設定情報を登録する場合は、設定情報の候補に優先順位をつけて送信する
。

管理サーバ１０の設定情報登録機能１０３は、ステップ２００４で受信した、端末の前記暗号化通信用の設定情報の候補を、ステップ２００８で、設定情報DB１１１に登録する
。

設定情報DB１１１は、例えば、図１３の、端末３０の設定情報の表８００と端末４０の設定情報の表８１０のように、端末ごとの表で構成することができる。

表８００の例では、エントリ８０２、エントリ８０４、エントリ８０６に、端末３０の設定情報の候補と優先順位のペアを保管している。

すでに、表８００に示す情報が、設定情報DB１１１に登録されている場合に、端末が再度設定情報の候補の登録を行う場合は、管理サーバ１０の設定情報登録機能１０３は、ステップ２００８により、該当する端末に関わる表を更新する。

また、管理サーバ１０の設定情報探索機能１０４は、図８のステップ２１０８で、端末３０と端末４０の暗号化通信用設定情報から一致するものを探す。

ステップ２１０８では、図１３の表８００と表８１０を参照し、設定情報から一致するものを探す。

まず、表８００と表８１０のエントリから、設定情報の内容が一致するエントリを抽出する。図１３の例では、エントリ８０２とエントリ８１４、エントリ８０４とエントリ８１２を抽出する。

なお、設定情報が一致するエントリがない場合には、探索に失敗する。

表８００と表８１０のそれぞれの設定情報のエントリには、ステップ２００２で送信した、情報（設定値）が記載されている。ステップ２１０８では、エントリに記載された設定値全てが一致するエントリを抽出する。例えば、一つのエントリ内に、通信データの暗号化に用いる暗号化アルゴリズムの種類、鍵の長さ、通信データの改ざん検知に用いるハッシュ関数の種類、を記載する場合、ステップ２１０８では、３つの設定値すべてが一致したエントリを抽出する。

エントリ内に記載する設定値は、例えば、暗号化アルゴリズム：アルゴリズムA、鍵の
長さ：６４ビット以上、ハッシュ関数：関数Aあるいは関数B、のように設定値を調節可能とするように記載してもよい。この場合、ステップ２１０８で、暗号化アルゴリズム：アルゴリズムA、鍵の長さ：１２８ビット以上、ハッシュ関数：関数Bあるいは関数C、の設
定情報と比較すると、両者は全く同一ではないが、それぞれの設定可能範囲が重なるため
、例えば、暗号化アルゴリズム：アルゴリズムA、鍵の長さ：１２８ビット、ハッシュ関
数：関数Bを一致したエントリとすることができる。

複数項目の設定可能範囲が重なる場合には、予め決めた設定項目間の優先度に従って、設定値を決定しても良い。

一致したエントリが複数ある場合には、例えば、接続要求を受ける端末を、接続要求を出す端末よりも優先する、といった、あらかじめ定めておいた端末の優先順位に従い、設定情報を一組選択する。

図１３の例では、接続要求を出す端末３０より、接続要求を受ける端末４０を優先するとあらかじめ決めた場合、管理サーバ１０は、一致したエントリの中の端末４０の優先順位欄（エントリ８１２の優先順位は１、エントリ８１４の優先順位は、２）を参照し、優先順位の高い設定Ｂを選択し、ステップ２１０８の設定情報の探索に成功する。

また、管理サーバが、一致したエントリの中から、予め定めておいた選択基準にしたがって設定情報を一組選択することもできる。

その場合、設定情報ＤＢ（表８００や表８１０）には、優先順位欄はなくてもよい。端末は、一つ以上の設定情報を、設定情報ＤＢ１１１に登録し、管理サーバ１０は、設定情報から一致するものを探し、一致した設定情報の中から、予め定めておいた選択基準にしたがって設定情報を一組選択する。

なお、選択基準は、例えば、高いセキュリティが求められる通信では、暗号化アルゴリズムの暗号強度を選択基準としたり、通信データの暗号化に用いる鍵の長さを選択基準としたりすることができる。また、通信性能を求める場合には、暗号化アルゴリズムの暗号化処理の軽さや、改ざん検知に用いるハッシュ関数の計算処理の軽さ、を選択基準としてもよい。

本実施の形態では、端末ＩＤを指定した通信を例示しているが、端末を利用するユーザを通信相手として指定してもよい。

端末を利用するユーザを通信相手として指定する場合には、ユーザの持つ公開鍵証明書とユーザＩＤを、あらかじめ可搬性を有する記憶媒体６８に入れておき、記憶媒体６８を端末の読取装置６７に挿入することで、ユーザの属性を端末に反映させることができる。

ユーザが、可搬性を有する記憶媒体６８を、読み取り装置６７より抜いた場合には、ユーザの属性は、端末に反映されなくなる。

ユーザの属性が端末に反映されると同時に、図７の処理を行って、ユーザＩＤと端末のアドレスを管理サーバ１０に登録し、反映されなくなったと同時に、図７の「登録」を「
削除」と置き換えた処理を行えば、他端末からの接続時に、ユーザが端末を利用中であるか否かが判定でき、端末を利用中の場合には、ユーザがどの端末を利用しているかを、気にすることなく接続することができる。

本発明の一実施形態における通信システムの構成を示す図である。 端末３０と管理サーバ１０が、端末３０と管理サーバ１０の間の暗号化通信、のためのパラメータを共有し、公開鍵証明書を交換する処理手順を示すフローチャートである。 管理サーバ１０が検証サーバ２０に、端末３０の公開鍵証明書の検証を要求し、検証サーバ２０が検証結果を応答する処理手順を示すフローチャートである。 端末３０と管理サーバ１０が、電子署名を用いてお互いに相手を認証し、各々、端末３０と管理サーバ１０の間の暗号化通信用、の鍵を生成する処理手順を示すフローチャートである。 端末３０と管理サーバ１０がコネクションを確立し、暗号化通信を行うまでの処理手順を示すフローチャートである。 端末３０と管理サーバ１０がコネクションを終了する処理手順を示すフローチャートである。 端末３０が管理サーバ１０に、端末３０のアドレスと、他の端末との暗号化通信用、の設定情報を登録する処理手順を示すフローチャートである。 端末３０が、端末４０と接続処理を行う際に、管理サーバ１０が、端末３０と端末４０が登録した設定情報から一致するものを探す処理手順を示すフローチャートである。 管理サーバ１０が、端末３０と端末４０の間の暗号化通信用、の鍵を生成し、端末３０と端末４０に配付する処理手順を示すフローチャートである。 端末３０が、管理サーバ１０を介して、端末４０とのコネクションを終了する処理手順を示すフローチャートである。 管理サーバ１０、検証サーバ２０、端末３０、端末４０の各々のハードウェア構成例を示す図である。 管理サーバ１０が保持するアドレスDB１１２の内容の例である。 管理サーバ１０が保持する設定情報DB１１１の例である。

符号の説明

１０：管理サーバ、２０：検証サーバ、３０、４０：端末、１１０、３１０、４１０：公開鍵証明書、１１１：設定情報DB、１１２：アドレスDB。

Claims (10)

1. 通信元端末と、通信先端末と、管理サーバとからなる通信システムであって、
   前記通信元端末は、管理サーバへ通信先端末との接続要求を送信し、
   前記管理サーバは、前記接続要求に基づき、前記通信元端末と前記通信先端末とが予め登録している暗号化通信用設定情報から一致するものを探索し、
   一致する暗号化通信用設定情報が探索できた場合に、前記通信元端末と前記通信先端末は、一致した前記暗号化通信用設定情報に基づいて生成された暗号化通信用の鍵を用いて暗号化通信を行う
   ことを特徴とする通信システム。
2. 請求項１に記載の通信システムにおいて、
   前記管理サーバは、前記接続要求を、前記通信先端末に送信し、
   前記通信先端末は、前記接続要求の可否判定を行う
   ことを特徴とする通信システム。
3. 請求項１に記載の通信システムにおいて、
   前記管理サーバは、一致した前記暗号化通信用設定情報をもとに、前記暗号化通信用の鍵を生成し、
   生成した前記暗号化通信用の鍵を前記通信元端末と前記通信先端末へ送信する
   ことを特徴とする通信システム。
4. 請求項１に記載の通信システムにおいて、
   前記管理サーバは、一致した前記暗号化通信用設定情報をもとに、前記暗号化通信用の鍵の種となる情報を生成し、
   生成した前記暗号化通信用の鍵の種となる情報を前記通信元端末と前記通信先端末へ送信し、
   前記通信元端末と前記通信先端末は、それぞれ、受信した、前記鍵の種となる情報から
   、前記暗号化通信用の鍵を生成することを特徴とする通信システム。
5. 請求項１に記載の通信システムにおいて、
   前記通信元端末と前記通信先端末は、各々、複数の前記暗号化通信用設定情報を、優先順位を付けて、前記管理サーバに登録し、
   前記管理サーバは、前記優先順位を参照して、前記複数の暗号化通信用設定情報の前記探索を行う
   ことを特徴とする通信システム。
6. 請求項１に記載の通信システムにおいて、
   前記通信元端末は、前記通信先端末との前記接続要求を送信するため、前記管理サーバとの間に暗号化通信路を確立し、
   前記管理サーバは、前記通信元端末による前記通信先端末との前記接続要求を送信するため、前記通信先端末との間に暗号化通信路を確立する
   ことを特徴とする通信システム。
7. 請求項６に記載の通信システムにおいて、
   さらに、検証サーバを備え、
   前記通信元端末が、前記管理サーバに、前記通信元端末の公開鍵証明書を送信し、
   前記管理サーバが、前記通信元端末の公開鍵証明書の検証を、前記検証サーバに要求し
   、
   前記検証サーバは、前記通信元端末の公開鍵証明書を検証し、検証結果を、前記管理サーバに応答し、
   前記管理サーバは、前記通信元端末の公開鍵証明書の検証が成功の場合に、前記通信元端末との間で前記暗号化通信路を確立する
   ことを特徴とする通信システム。
8. 請求項７において、前記通信先端末が、前記管理サーバに、前記通信先端末の公開鍵証明書を送信し、
   前記管理サーバが、前記通信先端末の公開鍵証明書の検証を、前記検証サーバに要求し
   、
   前記検証サーバは、前記通信先端末の公開鍵証明書を検証し、検証結果を、前記管理サーバに応答し、
   前記管理サーバは、前記通信先端末の公開鍵証明書の検証が成功の場合に、前記通信先端末との間で前記暗号化通信路を確立する
   ことを特徴とする通信システム。
9. 請求項８に記載の通信システムにおいて、
   前記通信元端末または、前記通信先端末は、前記管理サーバに、公開鍵証明書の送信を要求し、
   前記管理サーバが、要求された当該管理サーバの公開鍵証明書を、前記通信元端末または、前記通信先端末に送信し、
   前記通信元端末または、前記通信先端末は、前記管理サーバから、前記管理サーバの公開鍵証明書を受信し、前記管理サーバの公開鍵証明書の検証を行い、検証が成功の場合には、前記管理サーバとの間で前記暗号化通信路を確立する
   ことを特徴とする通信システム。
10. 請求項６に記載の通信システムにおいて、
    前記通信元端末および／または前記通信先端末は、前記暗号化通信路を用いて、
    前記暗号化通信用設定情報を前記管理サーバに登録する
    ことを特徴とする通信システム。
    

Images