JP4552785B2 - 暗号化通信管理サーバ - Google Patents

暗号化通信管理サーバ Download PDF

Info

Publication number
JP4552785B2
JP4552785B2 JP2005201047A JP2005201047A JP4552785B2 JP 4552785 B2 JP4552785 B2 JP 4552785B2 JP 2005201047 A JP2005201047 A JP 2005201047A JP 2005201047 A JP2005201047 A JP 2005201047A JP 4552785 B2 JP4552785 B2 JP 4552785B2
Authority
JP
Japan
Prior art keywords
communication
management server
encrypted communication
setting
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2005201047A
Other languages
English (en)
Other versions
JP2005304093A (ja
JP2005304093A5 (ja
Inventor
治 高田
孝宏 藤城
忠司 鍛
和義 星野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2005201047A priority Critical patent/JP4552785B2/ja
Publication of JP2005304093A publication Critical patent/JP2005304093A/ja
Publication of JP2005304093A5 publication Critical patent/JP2005304093A5/ja
Application granted granted Critical
Publication of JP4552785B2 publication Critical patent/JP4552785B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Description

本発明は、暗号化通信のための鍵を、通信元端末と通信先端末に、配付する方法およびシステムに関する。
ネットワークを通じて通信元端末装置と通信先端末装置(以下、端末装置を端末という
)が暗号化通信を行う場合には、データを暗号化して送受信する。通信元端末と通信先端末は、あらかじめ、通信元端末と通信先端末の間の暗号化通信、のための設定情報と鍵を共有し、共有した設定情報と鍵を用いて暗号化通信を行う。
例えば、公開鍵暗号を用いて、鍵を共有する場合には、以下のように行う。
通信元端末は、通信先端末の公開鍵を取得し、通信先端末と暗号化通信を行うための鍵を生成し、当該公開鍵を用いて、当該暗号化通信用の鍵、を暗号化し、通信先端末に送信する。また、通信先端末は、当該公開鍵で暗号化された、当該暗号化通信用の鍵を、通信元端末より受信し、通信先端末の秘密鍵で復号する。
上記の方法では、通信元端末が、複数の通信先端末と暗号化通信を行うためには、それぞれの通信先端末と、当該暗号化通信のための設定情報と鍵を共有する必要があり、通信元端末の負荷が大きくなるという課題があった。
そこで、ネットワーク上に、前記暗号化通信用の、設定情報と、鍵を、通信元端末と通信先端末に配付するサーバ装置(以下、サーバという)を設置し、通信元端末と通信先端末は、当該サーバから配付された、前記暗号化通信用の設定情報と鍵を用いて、暗号化通信を行う技術が提案されている(非特許文献1)。
また、ネットワークを通じた通信で、通信相手の正当性を確認するためには、通信を行う前に、通信相手を認証する必要がある。通信相手を認証する方法の一つに、電子署名を用いる方法がある。具体的には、通信を行う通信元端末と通信先端末が、お互いに電子署名を付与したIDと公開鍵証明書を交換し、受け取った電子署名と公開鍵証明書を検証することにより通信相手を認証する。
Mark Baugher 外3名、"MSEC Group Key Management Architecture <draft-ietf-msec-gkmarch-07.txt> "、[online]、January 30,2003、IETF(Internet Engineering Task Force)、P.3−13、[平成16年4月2日検索]、インターネット<URL:http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-07.txt>
通信元端末が、複数の通信先端末と暗号化通信を行うためには、それぞれの通信先端末と、当該暗号化通信のための設定情報と鍵を共有する必要があり、通信元端末の負荷が大きくなる。
例えば、通信元端末が、公開鍵暗号を用いて、通信先端末と暗号化通信のための鍵を共有するためには、通信元端末は、通信先端末の公開鍵の取得、暗号化通信のための鍵の生成、取得した公開鍵を用いた暗号化通信のための鍵の暗号化、の処理が必要であり、通信元端末の負荷が大きい。
この課題を解決するために、上記非特許文献1の技術を用いた場合、サーバが、通信元端末と通信先端末間の、暗号化通信用の設定情報と鍵を生成し、通信元端末と通信先端末に配付することになる。ただし、端末は配付された設定情報や鍵をサポートしているとは限らない。通信元端末あるいは通信先端末は、サポートしていない設定情報や鍵を配付された場合、通信元端末と通信先端末の間で、暗号化通信を行うことができない。
また、通信元端末と通信先端末は、通信相手の正当性を確認するためには、それぞれ通信相手を認証する処理を行う。しかしながら、通信元端末が、複数の通信先端末と暗号化通信を行う場合には、通信先端末をそれぞれ認証し、通信相手の正当性を確認する必要があり、通信元端末の処理負荷が大きくなる。
本発明は、ネットワーク上に、端末間通信を管理する、管理サーバを配した通信システムを提供する。
本発明の通信システムでは、以下のステップを行うことにより、通信元端末と通信先端末が、通信元端末と通信先端末の間の暗号化通信、で利用する鍵を共有する。
あらかじめ、通信元端末と通信先端末が、それぞれ利用可能な前記暗号化通信のための設定情報を、管理サーバに登録しておく。
通信元端末が、通信先端末に接続する際には、管理サーバに通知し、管理サーバは、通信元端末と通信先端末の設定情報から一致するものを探す。
管理サーバは、一致した設定情報に基づき、暗号化通信用の、鍵あるいは、鍵の種となる情報を生成し、一致した設定情報とともに、通信元端末と通信先端末に配付する。通信元端末と通信先端末は、管理サーバから設定情報と鍵の種となる情報を配付された場合は
、鍵の種となる情報から鍵を生成し、管理サーバから配付された設定情報と、生成あるいは送付された鍵を用いて暗号化通信を行う。
また、上記通信システムは、管理サーバが、通信元端末と通信先端末とを電子署名を用いて認証することで、通信元端末と通信先端末が、お互いに相手を認証したとみなす、ことを特徴とする。
管理サーバは、通信元端末から通信先端末との通信を要求された場合に、両端末の認証を行い、認証に成功した場合に、両端末間の通信を許可する。管理サーバが当該通信を許可した後に、通信元端末は通信先端末に接続することができる。
さらに、管理サーバは、公開鍵証明書を検証する検証サーバ装置(以下、検証サーバという)に通信元端末と通信先端末の公開鍵証明書の検証を依頼しても良い。
検証サーバが当該公開鍵証明書を検証することで、通信元端末と通信先端末をより確実に認証することができる。
本発明によれば、通信元端末は、通信元端末と通信先端末の間の暗号化通信、のための設定情報や鍵を、通信先端末と、共有するための処理を行う必要がない。
さらに、通信元端末と通信先端末は、確実に暗号化通信を行うことができる。
また、本発明によれば、通信元端末と通信先端末は、通信相手を直接認証する必要がなく、処理負荷が軽減される。
以下、本発明の実施の形態を詳細に説明する。なお、これによって本発明が限定されるものではない。
図1は、本発明の実施の一形態に係わる鍵配付システムの構成を示すブロック図である
図1の鍵配付システムは、ネットワーク50に端末30、端末40、管理サーバ装置(
以下、管理サーバという)10、検証サーバ装置(以下、検証サーバという)20、が接続している。
端末30、端末40はそれぞれ、信頼する認証局からそれぞれに発行された公開鍵証明書310、410を端末内に保管している。さらに、当該端末間の暗号化通信のための設定情報登録申請機能301、401と、当該端末のネットワーク上の位置を特定するアドレスを登録するためのアドレス登録申請機能302、402と、当該端末間の暗号化通信を要求し、必要な鍵や設定情報を管理サーバ10から受信する鍵・設定情報受信機能303、403と、当該端末間で暗号化通信を行う対端末通信機能304、404と、対管理サーバ通信機能305、405を備えている。
管理サーバ10は、信頼する認証局から発行された公開鍵証明書110と、端末30と端末40が暗号化通信を行うための設定情報DB111と、端末30と端末40のネットワーク上の位置を特定するアドレスDB112、を保管している。本実施例においては、上記端末アドレスとして、IPアドレスを用いる。
さらに、管理サーバ10は、端末30と端末40の間の暗号化通信のための鍵を生成する鍵生成機能102と、端末30あるいは端末40からの設定情報の登録申請を受けて、設定情報を登録する設定情報登録機能103と、端末30から端末40へ接続する際に、端末30と端末40が登録している設定情報から一致するものを探す設定情報探索機能104と、端末30と端末40の間の暗号化通信のための、鍵や設定情報を配付する、鍵・設定情報配付機能105と、端末30あるいは端末40からのアドレスの登録申請を受けて、アドレスをアドレスDB112に登録するアドレス登録機能106と、アドレスDB112から端末のアドレスを検索するアドレス検索機能107と、端末の認証と通信を行う対端末通信機能108と、検証サーバ20と通信を行う対検証サーバ通信機能109を備えている。
検証サーバ20は、管理サーバ10が、端末30や端末40を認証する際に、公開鍵証明書の有効性を確認する証明書検証機能201と、管理サーバ10と通信を行う対管理サーバ通信機能202を備えている。
なお、図1に示す管理サーバ10と、検証サーバ20、端末30、端末40、の各装置と、これら装置が備える各機能は、例えば、図11に示すような、CPU61と、メモリ62と、ハードディスク等の外部記憶装置63と、インターネットなどのネットワークやLAN(以下、ネットワークという)50を介して他装置と通信を行うための通信装置64と、キーボードやマウス等の入力装置65と、モニタやプリンタ等の出力装置66と、可搬性を有する記憶媒体68から情報を読み取る読取装置67と、これらの各装置間のデータ送受を行うインタフェース60とを備えた、電子計算機において、CPU61がメモリ62上にロードされた所定のプログラムを実行することにより、実現できる。
これらのプログラムは、あらかじめ、上記電子計算機内のメモリ62または外部記憶装置63に格納されていても良いし、必要なときに、上記電子計算機が利用可能な、着脱可能な記憶媒体68または通信媒体(ネットワークやLAN50など、またはそれらの上を伝搬する搬送波やデジタル信号など)を介して、導入されてもよい。
なお、本実施例では、端末は、図11に示されるような構成により実現できるとしているが、本発明はそれに限定されるものではない。図1に示す端末30と端末40、の各機器は、ネットワーク50と接続することのできる通信装置を備えた機器であってもよい。例えば、ルータ、PC、携帯電話、PDA、テレビ、冷蔵庫なども、端末となりうる。
次に本実施の形態による通信システムの動作について説明する。
本実施の形態における通信システムは、まず、端末30が、ネットワーク50を介して
、管理サーバ10とセキュアな通信路を確立する。
ここでは、端末30が管理サーバ10との間で暗号化通信路を確立し、暗号化通信を行い、通信を終えるまでの動作を示す。当該通信路を確立する際、端末30は管理サーバ10に端末30の公開鍵証明書を送り、管理サーバ10は当該公開鍵証明書の有効性の検証を検証サーバ20に要求し、管理サーバ10は、検証サーバ20による当該公開鍵証明書の有効性の検証結果を元に、端末30を認証する。
まず、端末30と、管理サーバ10は、図2に示すフローに従い、公開鍵証明書310と公開鍵証明書110を交換する。
対管理サーバ通信機能305は、管理サーバ10との間の暗号化通信のための、一つ以上のパラメータの候補を管理サーバ10に送信する(ステップ1000)。暗号化通信の
ためのパラメータには、通信データの暗号化に用いる暗号化アルゴリズムの種類、鍵の長さ、通信データの改ざん検知に用いるハッシュ関数の種類、などが含まれる。
対端末通信機能108は、端末30から送られてきた暗号化通信パラメータの候補を受信する(ステップ1002)。
管理サーバ10は、受信したパラメータの候補の中から、管理サーバが利用可能なパラメータを一つ選択し、対端末通信機能108により、選択したパラメータを端末30に送信する(ステップ1004)。
対管理サーバ通信機能305は、管理サーバ10が選択したパラメータを受信する(ステップ1006)。
以上のステップ1000からステップ1006により、端末30と管理サーバ10は、パラメータを共有する。
対管理サーバ通信機能305は、管理サーバ10の公開鍵証明書110の要求を管理サーバ10に送信する(ステップ1008)。
対端末通信機能108は、端末30から送られてきた、公開鍵証明書110の要求を受信する(ステップ1010)。
管理サーバ10は、ステップ1010で要求を受けた公開鍵証明書110を保持している場合(ステップ1012でYES)は、管理サーバ10の公開鍵証明書110と、端末3
0の公開鍵証明書要求を、対端末通信機能108により、端末30に送信する(ステップ1014)。
対管理サーバ通信機能305は、管理サーバ10の公開鍵証明書110と、端末30の公開鍵証明書の要求を、管理サーバ10から受信する(ステップ1016)。
端末30は、ステップ1016で要求を受けた公開鍵証明書310を保持している場合(ステップ1018でYES)は、対管理サーバ通信機能305により、端末30の公開鍵
証明書310を、管理サーバ10に送信する(ステップ1020)。
対端末通信機能108は、端末30の公開鍵証明書310を、端末30から受信する(
ステップ1022)。
対端末通信機能108は、端末30の公開鍵証明書310の受信通知を、端末30に送信する(ステップ1024)。
対管理サーバ通信機能305は、端末30の公開鍵証明書310の受信通知を、管理サーバ10より受信する(ステップ1026)。
対管理サーバ通信機能304は、ステップ1016で受信した公開鍵証明書110の有効期限、署名を検証することで、公開鍵証明書110を検証する(ステップ1028)。
端末30は、公開鍵証明書110の検証に成功した場合には、(ステップ1030でYE
S)は、図3の処理へ進む。
上記ステップ1012または、ステップ1018または、ステップ1030でNOの場合は、図6のステップ1316(A)へ進み、端末30と管理サーバ10の通信を終了する処理を行う。ただし、図6は端末30から通信終了を要求する場合を示しており、ステップ1012から進む場合は、管理サーバ10が通信終了要求を出すので、端末30と管理サーバ10との動作が入れ替わる。
次に、管理サーバ10は、図3に示すフローに従い、検証サーバ20に、端末30の公開鍵証明書の検証を要求し、検証結果を受け取る。
対検証サーバ通信機能109は、検証サーバ20に端末30の公開鍵証明書310を送信する(ステップ1100)。
対管理サーバ通信機能202は、公開鍵証明書310を、受信する(ステップ1102
)。
検証サーバ20は、証明書検証機能201により、受信した公開鍵証明書310を検証する。なお、公開鍵証明書310の検証では、有効期限、署名、公開鍵証明書の失効状態を検証する(ステップ1104)。
公開鍵証明書310の検証1104が成功しなかった場合は(ステップ1106でNO)
、対管理サーバ通信機能202により、検証サーバ20の署名を付与した、検証失敗通知を管理サーバ10に送信する(ステップ1108)。
公開鍵証明書310の検証1104が成功した場合は(ステップ1106でYES)、対
管理サーバ通信機能202により、検証サーバ20の署名を付与した、検証成功通知を管理サーバ10に送信する(ステップ1110)。
管理サーバ10は、対検証サーバ通信機能109により、ステップ1108あるいはステップ1110で送信された、検証失敗通知あるいは検証成功通知を受信し、通知に付与された検証サーバ20の署名を検証することにより、通知が確かに検証サーバ20から送付され、改ざんされていないことを確認する(ステップ1112)。
管理サーバ10は、ステップ1112で、検証成功通知を受け取った場合は、図4の(
D)へ処理を進める。ステップ1112で検証失敗通知を受け取った場合は、端末30との接続を終了するために、図6のステップ1316(A)に進む。なお、管理サーバ10が通信終了要求を出すので、図6の端末30と管理サーバ10との動作が入れ替わる。
次に、端末30と管理サーバ10は、図4に示すように、図2のステップで共有した情報に電子署名を添付して交換し、交換した電子署名を検証することで、相手を認証し、その後、鍵共有を行う。なお、共有情報としては、図2のステップで交換した情報の中で、任意のものを利用できる。
まず、端末30は、共有情報に対して、電子署名を生成し、共有情報に電子署名を添付して、対管理サーバ通信機能305により、管理サーバ10に送信する(ステップ1200)。
対端末通信機能108は、共有情報と電子署名を端末30から受信する(ステップ1202)。
管理サーバ10は、受信した電子署名をステップ1022で受信した端末30の公開鍵証明書310の公開鍵を用いて、検証する(ステップ1204)。
電子署名の検証に成功した場合は(ステップ1206でYES)、共有情報に対して、電
子署名を生成し、共有情報に電子署名を添付して、対端末通信機能108により、端末30に送信する(ステップ1208)。
対管理サーバ通信機能305は、共有情報と電子署名を管理サーバ10から受信する(
ステップ1210)。
端末30は、受信した電子署名を、ステップ1016で受信した管理サーバ10の公開鍵証明書110の公開鍵を用いて、検証する(ステップ1212)。
端末30は、電子署名の検証に成功した場合は(ステップ1214でYES)、端末30
と管理サーバ10の間の暗号化通信用の、鍵生成ステップ1216へ進む。
端末30は、ステップ1000からステップ1006で共有したパラメータを基に、管理サーバ10と暗号化通信を行うための鍵を生成する(ステップ1216)。
管理サーバ10も、ステップ1000からステップ1006で共有したパラメータを基に、端末30と暗号化通信を行うための鍵を生成する(ステップ1218)。
ステップ1206またはステップ1214でNOの場合(電子署名の検証に失敗した場合
)は、接続を終了するために、図6のステップ1316(A)に進む。ただし、図6は端末30から通信終了を要求する場合を示しており、ステップ1206から進む場合は、管理サーバ10から通信終了要求を出すので、端末30と管理サーバ10の動作が入れ替わる。
以上の処理で、端末30は管理サーバ10を認証し、管理サーバ10は、端末30を認証する。また、端末30と管理サーバ10は、端末30と管理サーバ10の間の暗号化通信に用いる鍵を共有する。
端末30と管理サーバ10はお互いに相手が認証できたら、通信コネクションを確立し
、暗号化通信を行う。
図5は、上記暗号化通信を行うためのコネクションを確立し、上記暗号化通信を行うステップを示したシーケンス図である。
対管理サーバ通信機能305は、管理サーバ10にデータ転送許可要求を送信し(ステップ1300)、対端末通信機能108は、これを受信する(ステップ1302)。
対端末通信機能108は、データ転送許可と、端末30に対するデータ転送許可要求を
、端末30へ送信し(ステップ1304)、対管理サーバ通信機能305は、これを受信
する(ステップ1306)。
対管理サーバ通信機能305は、データ転送許可を、管理サーバ10へ送信し(ステップ1308)、対端末通信機能108は、これを受信する(ステップ1310)。
上記処理により、端末30と、管理サーバ10は、お互いにデータ転送許可を出したので、コネクションが確立する(ステップ1312)。
コネクション確立後は、図2のステップ1000からステップ1006で共有した、前記暗号化通信のためのパラメータと、ステップ1216とステップ1218で生成した前記暗号化通信用の鍵を用いて、端末30と、管理サーバ10は、暗号化通信を行う(ステップ1314)。
端末30と管理サーバ10は、暗号化通信路が不要になったら、図6に示すシーケンスに従って、コネクションを終了する。 前記暗号化通信を終える場合には、まず、対管理サーバ通信機能305は、管理サーバ10との、通信終了要求を管理サーバ10に送信し(ステップ1316)、
対端末通信機能108は、これを受信する(ステップ1318)。
対端末通信機能108は、通信終了許可と、通信終了許可要求を端末30へ送信し(ステップ1320)、対管理サーバ通信機能305は、これらを受信する(ステップ132
2)。
対管理サーバ通信機能305は、通信終了許可を管理サーバ10へ送信し(ステップ1324)、対端末通信機能108は、これを受信する(ステップ1326)。
上記処理により、端末30と、管理サーバ10は、お互いに通信終了許可を出したので
、コネクションが終了する(ステップ1328)。
以上、図2から図6の動作により、端末30と管理サーバ10は、お互いに認証し、端末30と管理サーバ10の間の暗号化通信路を確立し、暗号化通信を行い、通信を終了することができる。
本実施の形態では、管理サーバ10が端末30を厳密に認証するために、図3に示す処理により、公開鍵証明書310の検証を検証サーバ20に要求している。
さらに、端末30が、管理サーバ10を厳密に認証するために、公開鍵証明書110の検証を、検証サーバ20に要求してもよい。ステップ1028とステップ1030に示す処理の代わりに、図3における端末30と管理サーバ10を入れ替えた処理を行うことにより、端末30は、検証サーバ20に、公開鍵証明書110の検証を要求することができる。
図7に示すフローでは、図2から図5の動作シーケンスにより確立した暗号化通信路を用いて、端末30が、管理サーバ10にアドレスと、他の端末と暗号化通信を行うための設定情報を登録する。
まず、端末30と管理サーバ10は、上記の、ステップ1000からステップ1030と、ステップ1100からステップ1114と、ステップ1200からステップ1218と、ステップ1300からステップ1312により、上記暗号化通信路を確立する(まとめてステップ2000と記述する)。
次に、端末30のアドレス登録申請機能302と、設定情報登録申請機能301は、端末30のアドレスの登録と、他の端末と暗号化通信を行うための設定情報の登録と、を対管理サーバ通信機能305を用いて、管理サーバ10に要求する(ステップ2002)。
なお、ステップ2002では、一つ以上の設定情報の登録要求を送信する。なお、設定情報には、例えば、通信データの暗号化に用いる暗号化アルゴリズムの種類、鍵の長さ、通信データの改ざん検知に用いるハッシュ関数の種類、などが含まれる。
対端末通信機能108は、当該アドレスと、暗号化通信用の設定情報を受信する(ステップ2004)。
管理サーバ10のアドレス登録機能106は、受信した当該アドレスを、図1のアドレス登録機能106により、アドレスDB112に登録する(ステップ2006)。詳細は後
述する。
設定情報登録機能103は、受信した当該設定情報を、設定情報DB111に登録する(
ステップ2008)。
管理サーバ10は、当該アドレスと、当該設定情報を登録したことを、端末30に通知するために、登録完了通知を、対端末通信機能108を用いて、端末30に送信し(ステップ2010)、対管理サーバ通信機能305は、これを受信する(ステップ2012)
端末30と管理サーバ10は、上記の、ステップ1316からステップ1326により
、コネクションを終了する(まとめて、ステップ2014と記述する)。
上記、図7の処理を行うことにより、端末30は、管理サーバ10に自分のアドレスと
、他の端末と暗号化通信を行うための設定情報を、登録することができる。
図7と同様の処理を行うことにより、端末40も、アドレス登録申請機能402と、設定情報登録申請機能401により、管理サーバ10に端末40のアドレスと、他の端末と暗号化通信を行うための設定情報を登録することができる。
端末40が登録する場合は、端末40と管理サーバ10は、図7の端末30を端末40に置き換えたフローを行う。
なお、端末30、端末40は、管理サーバ10に登録したアドレスや設定情報を削除することもできる。削除する場合は、図7の「登録」を「削除」と置き換えた処理を行う。
図7の処理では、端末30、40は、自端末に割り当てられたアドレスを管理サーバ10に登録する。端末30、40は、自端末に割り当てられたアドレスが変わった場合には
、最新のアドレスを登録するために、図7の処理を再度行う必要がある。
例えば、アドレスがIPアドレスであって、端末が動的にIPアドレス割り当てを受けている場合に、端末の電源をOFF、ONしたり、端末をリセットしたりすると、IPアドレスが変わる可能性がある。また、端末が、ネットワークとの接続を終了し、移動先で
、別のネットワークに接続する場合には、IPアドレスが変わる可能性がある。端末は、IPアドレスを変更した可能性がある場合には、再度、図7の処理を行うことにより、最新のIPアドレスを、管理サーバに登録する。
端末30と端末40が、図7のシーケンスで、ネットワーク上の位置(IPアドレス)と、他端末と間の暗号化通信用の設定情報とを、管理サーバ10に登録すると、端末30は図8と図9に示すフローに従い、管理サーバ10を介して端末40との接続処理を行う
端末30と管理サーバ10は、上記の、ステップ1000からステップ1030と、ステップ1100からステップ1114と、ステップ1200からステップ1218と、ステップ1300からステップ1312により、暗号化通信路を確立する(まとめてステップ2100と記述する)。
端末30の鍵・設定情報受信機能303は、対管理サーバ通信機能305により、端末40への接続要求を、管理サーバ10に送信し(ステップ2102)、対端末通信機能1
08は、これを受信する(ステップ2104)。なお、接続要求には、接続相手(端末4
0)を特定するIDのような情報(以下、端末IDという)が含まれる。端末IDには、ドメイン内で固定のものを使えばよい。例えば、端末名や、端末のMACアドレスを使うことができる。また、会社内のような閉じたドメインでは、端末のユーザのメールアドレスや、端末のSIP−URIや、端末のFQDN(完全修飾ドメイン名、Fully Qualifie
d Domain Name)のような情報を使うこともできる。
管理サーバ10は、端末30の接続先である端末40のアドレスを取得するため、図1のアドレス検索機能107により、端末IDをキーとして図1のアドレスDB112を検索する(ステップ2106)。
管理サーバ10は、図1の設定情報DB111を検索し、端末30と端末40の設定情報の候補を取得する。そして、図1の設定情報探索機能104により、取得した設定情報から一致するものを探す(ステップ2108)。
管理サーバ10は、端末30の設定情報と端末40の設定情報が一つ以上一致したら(
ステップ2110でYes)、端末40との間で、ステップ1000からステップ1030
と、ステップ1100からステップ1114と、ステップ1200からステップ1218と、ステップ1300からステップ1312により、暗号化通信路を確立する(まとめてステップ2112と記述する)。
ただし、管理サーバ10と端末40の間で暗号化通信路を確立するため、図2、図4、図5の端末30を管理サーバ10に置き換え、管理サーバ10を端末40に置き換えた処理が行われるものとし、管理サーバ10と端末40はそれらの処理に必要な上述の機能を備えるものとする。
さらに、ステップ2112では、管理サーバ10が検証サーバ20に端末40の公開鍵証明書の検証を要求するため、管理サーバ10は、図2のステップ1026から図3のCに進み、図3のDから図4のBに進む、また、端末40は、図2のCから図4のDに進む
ステップ2110で、設定情報が一致しない場合、図6のAに進み、設定情報が一致しないため接続不可である旨を図6の処理中のメッセージに記載し、端末30に通知し、端末30と管理サーバ10のコネクションを終了する。ただし、図6は端末30から通信の終了を要求する場合を示しており、ステップ2110から進む場合は、管理サーバ10が通信終了要求を出すので、端末30と管理サーバ10の動作が入れ替わる。
ステップ2112に続き、対端末通信機能108は、確立した暗号化通信路を用いて、端末40に、ステップ2104で受信した、端末30から端末40への接続要求を送信し(ステップ2114)、対管理サーバ通信機能405は、これを受信する(ステップ21
16)。
端末40は、現在通信が可能か否かのような自端末またはそのユーザの状態や、端末40の独自のポリシによるフィルタリング機能、により、受信した接続要求の許可あるいは拒否を判定する(ステップ2118)。
対管理サーバ通信機能405は、前記判定結果を、管理サーバ10に送信し(ステップ2120)、対端末通信機能108はこれを受信する(ステップ2122)。
対端末通信機能108は、受信した判定結果を、端末30に転送し(ステップ2124
)、対管理サーバ通信機能305は、これを受信する(ステップ2126)。
以上の処理により、端末30と管理サーバ10の間と、管理サーバ10と端末40の間に確立された暗号化通信路を用いて、端末30と端末40の間で接続可否の合意がとれる
次に、図9に示すフローに従い、管理サーバ10は、図8のステップ2108で探した
、一致する設定情報に従い、端末30と端末40の間の暗号化通信用、の鍵を生成し、端末30と端末40に当該暗号化通信用の鍵と設定情報を配付する。端末30と端末40は
、配付された鍵と設定情報を用いて暗号化通信路を確立する。
端末30と管理サーバ10と端末40は、ステップ2118で判定された接続可否の結果を判定する(ステップ2128、ステップ2130、ステップ2132)。なお、ステ
ップ2128、ステップ2130、ステップ2132の判定には、ステップ2118の判定結果が反映されるため、すべて同じ結果、(Yes)あるいは、(No)となる。
判定結果が(No)の場合は、端末30と管理サーバ10と端末40は、処理を終了する。
判定結果が(Yes)の場合は、管理サーバ10の鍵生成機能102は、ステップ2108
で探した、一致する設定情報に従って、端末30と端末40の間の暗号化通信用の鍵を生成する(ステップ2134)。なお、ステップ2134では、当該暗号化通信用の鍵の代
わりに、当該暗号化通信用の鍵の種となる情報を生成してもよい。
管理サーバ10は、鍵・設定情報配付機能105により、ステップ2134で生成した
、鍵あるいは鍵の種となる情報と、ステップ2108で探した、一致する設定情報とを、端末30と端末40に送信し(ステップ2138)、端末30と端末40は、鍵・設定情
報受信機能303、403により、これを受信する(ステップ2136、ステップ2140)。
端末30と端末40の対端末通信機能304、404は、受信した、端末30と端末40の間の暗号化通信用、の鍵と設定情報を利用して、暗号化通信路を確立する(ステップ2142)。
なお、管理サーバ10が、ステップ2134で、端末30と端末40の間の暗号化通信用、の鍵の種となる情報を生成し、ステップ2138で配付した場合は、鍵・設定情報受信機能303、403が、配付された、当該暗号化通信用、の鍵の種となる情報を用いて
、当該暗号化通信用の鍵を生成し、対端末通信機能304、404が、生成した鍵と、受信した設定情報を利用して、暗号化通信路を確立する。
端末30と端末40は、対端末通信機能304、404によって、確立した前記暗号化通信路を用いて、暗号化通信を行う(ステップ2144)。
以上の処理により、管理サーバ10は、端末30と端末40に、端末30と端末40の間の暗号化通信、に必要な、鍵または鍵の種となる情報、と設定情報を配付し、端末30と端末40が暗号化通信を行う。
端末30と端末40は、暗号化通信(ステップ2144)を終えると、図10に示すフローに従い、通信を終了する。
対管理サーバ通信機能305は、終了要求を管理サーバ10に送信し(ステップ2146)、対端末通信機能108が、これを受信する(ステップ2148)。
対端末通信機能108は、受信した終了要求を、端末40に転送し(ステップ2150
)、対管理サーバ通信機能405は、これを受信する(ステップ2152)。
対管理サーバ通信機能405は、終了許可を管理サーバ10に送信し(ステップ2154)、対端末通信機能108は、これを受信する(ステップ2156)。
対端末通信機能108は、受信した終了許可を、端末30に転送し(ステップ2158
)、対管理サーバ通信機能305は、これを受信する(ステップ2160)。
図10の以上の処理により、端末30と管理サーバ10は、図8のステップ2100で確立した、端末30と管理サーバ10の間の暗号化通信路、のコネクションを終了し(ステップ2162)、管理サーバ10と端末40は、図8のステップ2112で確立した、
管理サーバ10と端末40の間の暗号化通信路、のコネクションを終了する(ステップ2164)。
また、端末30と端末40は、図9のステップ2142で確立した、端末30と端末40の間の暗号化通信路、のコネクションを終了する(ステップ2166)。
なお、端末30と端末40は、通信を終了するために図10に示すフローを必ずしも行う必要はなく、図10のフローを行わずに、通信を終了してもよい。
図10のフローを行わない場合、端末30と管理サーバ10と端末40は、図10の処理を行う必要がないため、処理負荷が小さくなる。また、ステップ2100とステップ2112で確立した暗号化通信路を、ステップ2142の前に終了すれば、端末30と管理サーバの間と、管理サーバ10と端末40の間の通信リソースを節約できる。
また、端末30と管理サーバ10が、ステップ2100で確立した暗号化通信路を、ステップ2136とステップ2138の後に終了し、ステップ2144の後に、再度暗号化通信路を確立し、管理サーバ10と端末40が、ステップ2112で確立した暗号化通信路を、ステップ2138とステップ2140の後に終了し、ステップ2144の後に、再度暗号化通信路を確立してもよい。
その場合、ステップ2144の間、端末30と管理サーバ10、また、管理サーバ10と端末40は、暗号化通信路を確立しておく必要がなく、通信リソースを節約できる。
上記、図8の処理では、ステップ2100で暗号化通信路を確立するときに、端末30と管理サーバ10は、お互いに認証し、ステップ2112で暗号化通信路を確立するときに、管理サーバ10と端末40はお互いを認証するため、
端末30は、管理サーバ10を介して端末40の正当性を確認することができ、端末40は、管理サーバ10を介して端末30の正当性を確認することができる。
また、上記、図8,9の処理を行うことにより、管理サーバ10が、端末30と端末40があらかじめ登録した、端末30と端末40の間の暗号化通信用、の設定情報から一致するものを探索し、当該暗号化通信用の鍵または鍵の種となる情報と、設定情報を配付するため、端末30と端末40は、配付された鍵と設定情報を用いて暗号化通信を行うことができる。
本実施の形態では、管理サーバ10に端末30,40のユーザの個人情報を扱う機能を付加した場合に、端末30,40が管理サーバ10に送信するユーザの個人情報の漏洩を防ぐために、図7のステップ2000では、具体的には、図2から図6の処理を行うことにより、暗号化通信路を確立しているが、管理サーバ10が個人情報を扱わない場合には
、通信路を暗号化しなくてもよい。通信路を暗号化しない場合には、図2、図3、図4、図5、図6の暗号化通信路を確立するステップにおいて、図4のステップ1216と、ステップ1218と、を省略し、図5のステップ1314では、通信を暗号化しない。
次に、ここまでに示したフローの一部について、詳細を述べる。
図7のステップ2006では、端末30のアドレスを、図1のアドレスDB112に登録する。図12の表700は、アドレスDB112の例を示している。
以下、アドレスDB112の登録、検索について述べる。
端末30のアドレス登録申請機能302は、図2のステップ2002の登録要求送信で
、アドレスを管理サーバ10に送信する。
管理サーバ10のアドレス登録機能106は、ステップ2004で受信した端末30のアドレスを、ステップ2006で、アドレスDB112に登録する。
アドレスDB112は、例えば、図12に示す表700のように構成できる。表700は
、管理サーバ10がステップ2104で受信する接続要求に含まれる、端末を特定する情報(端末ID)と、アドレスと、のペアを保管する。
表700の例では、エントリ702、エントリ704に、端末30と端末40それぞれの端末IDとIPアドレスを保管している。なお、一つの端末につき、一つのエントリを保管する。すでに、表700の例に示す情報が、アドレスDB112に登録されている場合に、端末が再度IPアドレスの登録を行う場合は、アドレス登録機能106は、ステップ2006により、該当する端末に関わるエントリのIPアドレスの部分を更新する。
また、管理サーバ10のアドレス検索機能107は、図8のステップ2106で、端末30の接続要求先である端末40のアドレスを検索する。
ステップ2106では、図12のエントリ704を参照し、端末40のIPアドレス情報を取得する。
図7のステップ2008では、端末30、40が他端末との暗号化通信で利用可能な、一つ以上の、当該暗号化通信用、の設定情報を、図1の設定情報DB111に登録し、図8のステップ2108では、設定情報DB111を参照し、設定情報から一致するものを探す
以下、設定情報DB111の登録と、DB111に対する、一致する設定情報の探索について述べる。
端末の設定情報登録申請機能301は、ステップ2002の設定情報登録要求送信で、他端末との暗号化通信用、の設定情報の候補を一つ以上、管理サーバ10に送信する。なお、二つ以上の設定情報を登録する場合は、設定情報の候補に優先順位をつけて送信する
管理サーバ10の設定情報登録機能103は、ステップ2004で受信した、端末の前記暗号化通信用の設定情報の候補を、ステップ2008で、設定情報DB111に登録する
設定情報DB111は、例えば、図13の、端末30の設定情報の表800と端末40の設定情報の表810のように、端末ごとの表で構成することができる。
表800の例では、エントリ802、エントリ804、エントリ806に、端末30の設定情報の候補と優先順位のペアを保管している。
すでに、表800に示す情報が、設定情報DB111に登録されている場合に、端末が再度設定情報の候補の登録を行う場合は、管理サーバ10の設定情報登録機能103は、ステップ2008により、該当する端末に関わる表を更新する。
また、管理サーバ10の設定情報探索機能104は、図8のステップ2108で、端末30と端末40の暗号化通信用設定情報から一致するものを探す。
ステップ2108では、図13の表800と表810を参照し、設定情報から一致するものを探す。
まず、表800と表810のエントリから、設定情報の内容が一致するエントリを抽出する。図13の例では、エントリ802とエントリ814、エントリ804とエントリ812を抽出する。
なお、設定情報が一致するエントリがない場合には、探索に失敗する。
表800と表810のそれぞれの設定情報のエントリには、ステップ2002で送信した、情報(設定値)が記載されている。ステップ2108では、エントリに記載された設定値全てが一致するエントリを抽出する。例えば、一つのエントリ内に、通信データの暗号化に用いる暗号化アルゴリズムの種類、鍵の長さ、通信データの改ざん検知に用いるハッシュ関数の種類、を記載する場合、ステップ2108では、3つの設定値すべてが一致したエントリを抽出する。
エントリ内に記載する設定値は、例えば、暗号化アルゴリズム:アルゴリズムA、鍵の
長さ:64ビット以上、ハッシュ関数:関数Aあるいは関数B、のように設定値を調節可能とするように記載してもよい。この場合、ステップ2108で、暗号化アルゴリズム:アルゴリズムA、鍵の長さ:128ビット以上、ハッシュ関数:関数Bあるいは関数C、の設
定情報と比較すると、両者は全く同一ではないが、それぞれの設定可能範囲が重なるため
、例えば、暗号化アルゴリズム:アルゴリズムA、鍵の長さ:128ビット、ハッシュ関
数:関数Bを一致したエントリとすることができる。
複数項目の設定可能範囲が重なる場合には、予め決めた設定項目間の優先度に従って、設定値を決定しても良い。
一致したエントリが複数ある場合には、例えば、接続要求を受ける端末を、接続要求を出す端末よりも優先する、といった、あらかじめ定めておいた端末の優先順位に従い、設定情報を一組選択する。
図13の例では、接続要求を出す端末30より、接続要求を受ける端末40を優先するとあらかじめ決めた場合、管理サーバ10は、一致したエントリの中の端末40の優先順位欄(エントリ812の優先順位は1、エントリ814の優先順位は、2)を参照し、優先順位の高い設定Bを選択し、ステップ2108の設定情報の探索に成功する。
また、管理サーバが、一致したエントリの中から、予め定めておいた選択基準にしたがって設定情報を一組選択することもできる。
その場合、設定情報DB(表800や表810)には、優先順位欄はなくてもよい。端末は、一つ以上の設定情報を、設定情報DB111に登録し、管理サーバ10は、設定情報から一致するものを探し、一致した設定情報の中から、予め定めておいた選択基準にしたがって設定情報を一組選択する。
なお、選択基準は、例えば、高いセキュリティが求められる通信では、暗号化アルゴリズムの暗号強度を選択基準としたり、通信データの暗号化に用いる鍵の長さを選択基準としたりすることができる。また、通信性能を求める場合には、暗号化アルゴリズムの暗号化処理の軽さや、改ざん検知に用いるハッシュ関数の計算処理の軽さ、を選択基準としてもよい。
本実施の形態では、端末IDを指定した通信を例示しているが、端末を利用するユーザを通信相手として指定してもよい。
端末を利用するユーザを通信相手として指定する場合には、ユーザの持つ公開鍵証明書とユーザIDを、あらかじめ可搬性を有する記憶媒体68に入れておき、記憶媒体68を端末の読取装置67に挿入することで、ユーザの属性を端末に反映させることができる。
ユーザが、可搬性を有する記憶媒体68を、読み取り装置67より抜いた場合には、ユーザの属性は、端末に反映されなくなる。
ユーザの属性が端末に反映されると同時に、図7の処理を行って、ユーザIDと端末のアドレスを管理サーバ10に登録し、反映されなくなったと同時に、図7の「登録」を「
削除」と置き換えた処理を行えば、他端末からの接続時に、ユーザが端末を利用中であるか否かが判定でき、端末を利用中の場合には、ユーザがどの端末を利用しているかを、気にすることなく接続することができる。
本発明の一実施形態における通信システムの構成を示す図である。 端末30と管理サーバ10が、端末30と管理サーバ10の間の暗号化通信、のためのパラメータを共有し、公開鍵証明書を交換する処理手順を示すフローチャートである。 管理サーバ10が検証サーバ20に、端末30の公開鍵証明書の検証を要求し、検証サーバ20が検証結果を応答する処理手順を示すフローチャートである。 端末30と管理サーバ10が、電子署名を用いてお互いに相手を認証し、各々、端末30と管理サーバ10の間の暗号化通信用、の鍵を生成する処理手順を示すフローチャートである。 端末30と管理サーバ10がコネクションを確立し、暗号化通信を行うまでの処理手順を示すフローチャートである。 端末30と管理サーバ10がコネクションを終了する処理手順を示すフローチャートである。 端末30が管理サーバ10に、端末30のアドレスと、他の端末との暗号化通信用、の設定情報を登録する処理手順を示すフローチャートである。 端末30が、端末40と接続処理を行う際に、管理サーバ10が、端末30と端末40が登録した設定情報から一致するものを探す処理手順を示すフローチャートである。 管理サーバ10が、端末30と端末40の間の暗号化通信用、の鍵を生成し、端末30と端末40に配付する処理手順を示すフローチャートである。 端末30が、管理サーバ10を介して、端末40とのコネクションを終了する処理手順を示すフローチャートである。 管理サーバ10、検証サーバ20、端末30、端末40の各々のハードウェア構成例を示す図である。 管理サーバ10が保持するアドレスDB112の内容の例である。 管理サーバ10が保持する設定情報DB111の例である。
符号の説明
10:管理サーバ、20:検証サーバ、30、40:端末、110、310、410:公開鍵証明書、111:設定情報DB、112:アドレスDB。

Claims (17)

  1. 複数の通信装置間の暗号化通信を管理する暗号化通信管理サーバであって,
    各々の前記通信装置から,前記通信装置が使用可能な暗号鍵を生成するために設定値の決定が必要な複数の設定項目からなり,かつ,前記複数の設定項目に設定値の候補を格納した暗号化通信用設定情報を受信し,
    通信元装置となるいずれかの前記通信装置から,いずれかの前記通信装置を通信先装置として特定する情報を含む,当該通信先装置と暗号化通信を行うための接続要求を受信し,
    既に受信している前記暗号化通信用設定情報に含まれる,前記通信元装置から受信している第一の暗号化通信用設定情報と,前記通信先装置から受信している第二の暗号化通信用設定情報との,複数の設定項目のそれぞれに,前記通信元装置と通信先装置とが,共に使用可能な暗号鍵を生成する設定値が存在するか否かを調べ,
    前記調べた結果,前記通信元装置と前記通信先装置とが,共に使用可能な暗号鍵を生成する設定値が,前記第一の暗号化通信用設定情報と,前記第二の暗号化通信用設定情報と,の前記複数の設定項目のそれぞれに存在する場合に,前記存在する設定値に基づいて生成した前記暗号鍵と,前記暗号鍵を生成した設定値からなる暗号化通信用設定情報とを,前記通信元装置と,前記通信先装置とに,送信する
    ことを特徴とする暗号化通信管理サーバ。
  2. 請求項1に記載の暗号化通信管理サーバであって,
    前記第一の暗号化通信用設定情報は,さらに,通信データの改ざん検知方法を決定するために設定値の決定が必要な設定項目を含み,かつ,当該設定項目に,前記通信元装置が使用可能な通信データの改ざん検知方法を決定するための設定値の候補を含み,
    前記第二の暗号化通信用設定情報は,さらに,通信データの改ざん検知方法を決定するために設定値の決定が必要な設定項目を含み,かつ,当該設定項目に,前記通信先装置が使用可能な通信データの改ざん検知方法を決定するための設定値の候補を含み,
    当該暗号化通信管理サーバは,前記通信元装置と前記通信先装置とが共に使用可能な改ざん検知方法を決定する設定値が,前記第一の暗号化通信用設定情報と,前記第二の暗号化通信用設定情報との,通信データの改ざん検知方法を決定するために設定値の決定が必要な前記設定項目に存在するか否かを調べ,
    前記調べた結果,前記通信元装置と前記通信先装置とが共に使用可能な改ざん検知方法を決定する設定値が,前記第一の暗号化通信用設定情報と,前記第二の暗号化通信用設定情報との,通信データの改ざん検知方法を決定するために設定値の決定が必要な前記設定項目に存在する場合に,前記通信元装置と前記通信先装置とに送信する前記暗号化通信用設定情報に,前記改ざん検知方法を決定する設定値を含める
    ことを特徴とする暗号化通信管理サーバ。
  3. 請求項1または2に記載の暗号化通信管理サーバであって,
    前記通信元装置に対する第一の認証を行い,
    前記通信元装置に対する第一の認証に成功した場合に,前記接続要求を受信して,前記通信元装置と,受信した前記通信先装置とが共に使用可能な暗号鍵を生成するための設定値が,前記第一の暗号化通信用設定情報と,前記第二の暗号化通信用設定情報とに存在するか否かを調べ,
    前記調べた結果,前記通信元装置と受信した前記通信先装置とが共に使用可能な暗号鍵を生成するための設定値が,前記第一の暗号化通信用設定情報と,前記第二の暗号化通信用設定情報とに存在する場合に,前記通信先装置に対する第一の認証を行い,
    前記通信先装置に対する第一の認証に成功した場合に,前記暗号鍵と,前記暗号鍵を生成した設定値からなる暗号化通信用設定情報と,を前記通信元装置と,受信した前記通信先装置とに,送信する
    ことを特徴とする暗号化通信管理サーバ。
  4. 請求項1ないし3いずれか一に記載の暗号化通信管理サーバであって,
    前記通信元装置と受信した前記通信先装置とが共に使用可能な暗号鍵を生成するための設定値が,前記第一の暗号化通信用設定情報と,前記第二の暗号化通信用設定情報とに存在する場合に,受信した前記通信先装置へ,前記暗号化通信を行うための前記通信元装置との接続要求を送信し,
    前記通信先装置から,前記接続要求の許可または拒否を判定した判定結果を受信し,
    前記判定結果が許可である場合に,前記通信元装置と受信した前記通信先装置とに,前記暗号鍵と,前記暗号鍵を生成した設定値からなる暗号化通信用設定情報と,を送信する
    ことを特徴とする暗号化通信管理サーバ。
  5. 請求項1ないし4いずれか一に記載の暗号化通信管理サーバであって,
    前記通信元装置と受信した前記通信先装置とが共に使用可能な暗号鍵を生成する設定値が複数存在する前記設定項目については,予め定めている選択基準に従って,一つの設定値を選択する
    ことを特徴とする暗号化通信管理サーバ。
  6. 請求項5に記載の暗号化通信管理サーバであって,
    前記選択基準は,
    前記通信元装置と受信した前記通信先装置とについて優先される通信装置を定める通信装置間優先順位と,
    前記通信元装置と受信した前記通信先装置とが共に使用可能な暗号鍵を生成する設定値が複数存在する前記設定項目について,前記優先される通信装置が定める前記複数の設定値に対する優先順位と,に基づくものである
    ことを特徴とする暗号化通信管理サーバ。
  7. 複数の通信装置間の暗号化通信を管理する暗号化通信管理サーバであって,
    各々の前記通信装置から,前記通信装置が他の前記通信装置と送受信するデータの暗号化に用いる暗号鍵を生成するために設定値の決定が必要な複数の設定項目からなり,かつ,前記複数の設定項目に設定値の候補を格納した暗号化通信用設定情報を受信し,
    通信元装置となるいずれかの前記通信装置から,いずれかの前記通信装置を通信先装置として特定する情報を含む,当該通信先装置と暗号化通信を行うための接続要求を受信し,
    既に受信している前記暗号化通信用設定情報に含まれる,前記通信元装置から受信している前記第一の暗号化通信用設定情報と,前記通信先装置から受信している第二の暗号化通信用設定情報とに,格納されている設定値の候補の範囲が重なる複数の設定項目が存在するか否かを調べ,
    前記調べた結果,設定値の候補の範囲が重なる前記複数の設定項目が,前記第一の暗号化通信用設定情報と,前記第二の暗号化通信用設定情報とに存在する場合に,前記重なる範囲内の設定値に基づいて生成した前記暗号鍵と,前記暗号鍵を生成した設定値からなる暗号化通信用設定情報と,を前記通信元装置と,前記通信先装置とに,送信する
    ことを特徴とする暗号化通信管理サーバ。
  8. 請求項7に記載の暗号化通信管理サーバであって,
    前記第一の暗号化通信用設定情報は,さらに,前記暗号化通信における改ざん検知方法を決定するために設定値の決定が必要な設定項目を含み,かつ,当該設定項目に,前記通信元装置が使用可能な通信データの改ざん検知方法を決定する設定値の候補を含み,
    前記第二の暗号化通信用設定情報は,さらに,前記暗号化通信における改ざん検知方法を決定するために設定値の決定が必要な設定項目を含み,かつ,当該設定項目に,前記通信先装置が使用可能な通信データの改ざん検知方法を決定する設定値の候補を含み,
    当該暗号化通信管理サーバは,前記第一の暗号化通信用設定情報と,前記第二の暗号化通信用設定情報との,前記暗号化通信における改ざん検知方法を決定するために設定値の決定が必要な前記設定項目において,格納されている前記設定値の候補の範囲が重なるか否かを調べ,
    前記調べた結果,前記第一の暗号化通信用設定情報と,前記第二の暗号化通信用設定情報との,前記暗号化通信における改ざん検知方法を決定するために設定値の決定が必要な前記設定項目において,格納されている前記設定値の候補の範囲が重なる場合に,前記通信元装置と受信した前記通信先装置とに送信する前記暗号化通信用設定情報に,前記重なる範囲内の設定値を含める
    ことを特徴とする暗号化通信管理サーバ。
  9. 請求項7または8に記載の暗号化通信管理サーバであって,
    前記通信元装置に対する第一の認証を行い,
    前記通信元装置に対する第一の認証に成功した場合に,前記接続要求を受信して,前記第一の暗号化通信用設定情報と,前記第二の暗号化通信用設定情報とに,格納されている設定値の候補の範囲が重なる前記複数の設定項目が存在するか否かを調べ,
    前記調べた結果,設定値の候補の範囲が重なる前記複数の設定項目が,前記第一の暗号化通信用設定情報と,前記第二の暗号化通信用設定情報とに存在する場合に,前記通信先装置に対する第一の認証を行い,
    前記通信先装置に対する第一の認証に成功した場合に,前記暗号鍵と,前記暗号鍵を生成した設定値からなる暗号化通信用設定情報と,を前記通信元装置と,受信した前記通信先装置とに,送信する
    ことを特徴とする暗号化通信管理サーバ。
  10. 請求項7ないし9いずれか一に記載の暗号化通信管理サーバであって,
    格納されている設定値の候補の範囲が重なる設定項目が,前記第一の暗号化通信用設定情報と,前記第二の暗号化通信用設定情報とに存在する場合に,受信した前記通信先装置へ,前記暗号化通信を行うための前記通信元装置との接続要求を送信し,
    前記通信先装置から,前記接続要求の許可または拒否を判定した,判定結果を受信し,
    前記判定結果が許可である場合に,前記通信元装置と受信した前記通信先装置とに,前記暗号鍵と,前記暗号鍵を生成した設定値からなる暗号化通信用設定情報と,を送信する
    ことを特徴とする暗号化通信管理サーバ。
  11. 請求項7ないし10いずれか一に記載の暗号化通信管理サーバであって,
    重なる設定値の候補の範囲に複数の設定値が存在する前記設定項目については,予め定めている選択基準に従って,一つの設定値を選択する
    ことを特徴とする暗号化通信管理サーバ。
  12. 請求項11に記載の暗号化通信管理サーバであって,
    前記選択基準は,
    前記通信元装置と受信した前記通信先装置とについて優先される通信装置を定める通信装置間優先順位と,
    重なる設定値の候補の範囲に複数の設定値が存在する前記設定項目について,前記優先される通信装置が定める前記複数の設定値に対する優先順位と,に基づくものである
    ことを特徴とする暗号化通信管理サーバ。
  13. 請求項1ないし12いずれか一に記載の暗号化通信管理サーバであって,
    前記通信元装置に対する第二の認証を行い,
    前記通信元装置に対する第二の認証に成功した場合に,前記通信元装置の前記第一の暗号化通信用設定情報を受信し,
    前記通信先装置に対する第二の認証を行い,
    前記通信先装置に対する第二の認証に成功した場合に,前記通信先装置の前記第二の暗号化通信用設定情報を受信する
    ことを特徴とする暗号化通信管理サーバ。
  14. 請求項4または10に記載の暗号化通信管理サーバであって,
    前記判定結果が,前記接続要求の拒否である場合に,前記通信元装置に,要求された前記暗号化通信の拒否を通知する
    ことを特徴とする暗号化通信管理サーバ。
  15. 請求項5または11に記載の暗号化通信管理サーバであって,
    前記選択基準は,前記管理サーバが定める,前記暗号化通信に求められるセキュリティ強度,または,暗号化アルゴリズムの処理負荷の大きさである
    ことを特徴とする暗号化通信管理サーバ。
  16. 請求項1ないし15いずれか一に記載の暗号化通信管理サーバであって,
    前記暗号化通信用設定情報の前記複数の設定項目は,暗号化アルゴリズムの種類,と,鍵の長さ,を設定するものである
    ことを特徴とする暗号化通信管理サーバ。
  17. 請求項2または8に記載の暗号化通信管理サーバであって,
    前記暗号化通信における改ざん検知方法を決定する設定値は,ハッシュ関数の種類である
    ことを特徴とする暗号化通信管理サーバ。
JP2005201047A 2005-07-11 2005-07-11 暗号化通信管理サーバ Expired - Fee Related JP4552785B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2005201047A JP4552785B2 (ja) 2005-07-11 2005-07-11 暗号化通信管理サーバ

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005201047A JP4552785B2 (ja) 2005-07-11 2005-07-11 暗号化通信管理サーバ

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2004113732A Division JP3761557B2 (ja) 2004-04-08 2004-04-08 暗号化通信のための鍵配付方法及びシステム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2007100027A Division JP4631869B2 (ja) 2007-04-06 2007-04-06 暗号化通信のための鍵配付方法及びシステム

Publications (3)

Publication Number Publication Date
JP2005304093A JP2005304093A (ja) 2005-10-27
JP2005304093A5 JP2005304093A5 (ja) 2007-05-31
JP4552785B2 true JP4552785B2 (ja) 2010-09-29

Family

ID=35334986

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005201047A Expired - Fee Related JP4552785B2 (ja) 2005-07-11 2005-07-11 暗号化通信管理サーバ

Country Status (1)

Country Link
JP (1) JP4552785B2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4714482B2 (ja) 2005-02-28 2011-06-29 株式会社日立製作所 暗号通信システムおよび方法
US8417640B2 (en) 2005-10-31 2013-04-09 Research In Motion Limited Secure license key method and system
JP4770494B2 (ja) 2006-02-03 2011-09-14 株式会社日立製作所 暗号通信方法およびシステム
JP4823717B2 (ja) 2006-02-28 2011-11-24 株式会社日立製作所 暗号通信システム、端末状態管理サーバ、暗号通信方法、および端末状態管理方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000049766A (ja) * 1998-07-27 2000-02-18 Hitachi Ltd 鍵管理サーバシステム
JP2000324104A (ja) * 1999-05-10 2000-11-24 Matsushita Electric Works Ltd バーチャル通信ネットワークにおけるセキュリティーポリシー設定方法、セキュリティーポリシーマネージャ及びこれを用いたバーチャル通信ネットワークシステム
JP2003348077A (ja) * 2002-05-27 2003-12-05 Hitachi Ltd 属性証明書検証方法および装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5179591A (en) * 1991-10-16 1993-01-12 Motorola, Inc. Method for algorithm independent cryptographic key management
JPH05122217A (ja) * 1991-10-25 1993-05-18 Nippon Telegr & Teleph Corp <Ntt> 秘話通信方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000049766A (ja) * 1998-07-27 2000-02-18 Hitachi Ltd 鍵管理サーバシステム
JP2000324104A (ja) * 1999-05-10 2000-11-24 Matsushita Electric Works Ltd バーチャル通信ネットワークにおけるセキュリティーポリシー設定方法、セキュリティーポリシーマネージャ及びこれを用いたバーチャル通信ネットワークシステム
JP2003348077A (ja) * 2002-05-27 2003-12-05 Hitachi Ltd 属性証明書検証方法および装置

Also Published As

Publication number Publication date
JP2005304093A (ja) 2005-10-27

Similar Documents

Publication Publication Date Title
JP3761557B2 (ja) 暗号化通信のための鍵配付方法及びシステム
US10554420B2 (en) Wireless connections to a wireless access point
CN110537346B (zh) 安全去中心化域名系统
US8788811B2 (en) Server-side key generation for non-token clients
JP4961798B2 (ja) 暗号化通信方法及びシステム
US9130758B2 (en) Renewal of expired certificates
US9137017B2 (en) Key recovery mechanism
US20110296171A1 (en) Key recovery mechanism
US20200412554A1 (en) Id as service based on blockchain
US8397281B2 (en) Service assisted secret provisioning
US20110113240A1 (en) Certificate renewal using enrollment profile framework
US11218317B1 (en) Secure enclave implementation of proxied cryptographic keys
US11418329B1 (en) Shared secret implementation of proxied cryptographic keys
JP4552785B2 (ja) 暗号化通信管理サーバ
WO2019163040A1 (ja) アクセス管理システム、及びそのプログラム
JP4631869B2 (ja) 暗号化通信のための鍵配付方法及びシステム
JP3910611B2 (ja) 通信支援サーバ、通信支援方法、および通信支援システム
JP4690964B2 (ja) 通信支援システム
JP6334275B2 (ja) 認証装置、認証方法、認証プログラム、及び認証システム
KR100834576B1 (ko) P2p 네트워크에서 보안통신을 위한 키 관리 방법 및이를 위한 장치
JP4882860B2 (ja) アクセス制御システム
JP2019165291A (ja) 端末装置、通信路確立方法、端末装置用のプログラム、および、認証システム

Legal Events

Date Code Title Description
RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7421

Effective date: 20060421

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070406

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070406

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100622

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100705

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130723

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130723

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees