JP2004214751A - 証明書経路情報管理システム及び証明書経路管理方法 - Google Patents
証明書経路情報管理システム及び証明書経路管理方法 Download PDFInfo
- Publication number
- JP2004214751A JP2004214751A JP2002378941A JP2002378941A JP2004214751A JP 2004214751 A JP2004214751 A JP 2004214751A JP 2002378941 A JP2002378941 A JP 2002378941A JP 2002378941 A JP2002378941 A JP 2002378941A JP 2004214751 A JP2004214751 A JP 2004214751A
- Authority
- JP
- Japan
- Prior art keywords
- certificate
- information
- path
- route
- registration
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】迅速な証明書の検証を行うことが可能な証明書経路情報管理システムを提供することにある。
【解決手段】認証局が発行する証明書に関する登録情報を、証明書に関する経路を格納する経路情報リストに記憶する。証明書に関する経路検索依頼があると、経路情報リストをもとに、認証局のつながりを検索した後、認証局の経路情報を証明書の経路情報へ変換して、証明書経路の検索を行う。
【選択図】 図1
【解決手段】認証局が発行する証明書に関する登録情報を、証明書に関する経路を格納する経路情報リストに記憶する。証明書に関する経路検索依頼があると、経路情報リストをもとに、認証局のつながりを検索した後、認証局の経路情報を証明書の経路情報へ変換して、証明書経路の検索を行う。
【選択図】 図1
Description
【0001】
【発明の属する技術分野】
本発明は、公開鍵暗号基盤における証明書経路管理システムに関し、特に、証明書の経路検証に必要な証明書の格納場所情報を用いて証明書情報を取得する証明書経路管理システムに関する。
【0002】
【従来の技術】
公開鍵暗号基盤(Public Key Infrastructure:PKI)が、個人対企業間、企業対企業間などで安全に通信が行えるように導入されている。公開鍵暗号基盤では、電子署名、暗号、認証、否認防止のサービスが提供されており、これらサービスは利用者に発行された証明書を使用し実現されている。ここで、安全なPKIサービスが利用者間で実現されるために、受信者は送信者の送ったメッセージを受けると、受信者が信用する認証局から送信者証明書のまでのパス(経路)を何らかの方法で検証しなければならない。パス検証に関する基本的な処理は、まず検証者から検証処理に必要な証明書を取得する証明書構築という作業を行い、次にパスのつながりを検証するパス検証という作業を行う(例えば、特許文献1参照)。
【0003】
【特許文献1】
特開2001−350406号(第4ページ、図1)
【0004】
【発明が解決しようとする課題】
この作業でネックとなるのは、証明書の経路、すなわち証明書のつながりを発見するという作業である。現在この作業は、パス経路発見の効率を上げるために、出来るだけ一つの場所に必要な証明書のすべてが保存され、グラフ検索理論を使用し経路情報を発見しながらパス構築している。または様々な場所を総当りで検索しながら経路情報を発見しながらパス構築している。
【0005】
この場合の問題は、認証構造が複雑になると、経路情報の発見に時間を費やしてしまい、証明書の取得作業に時間がかかってしまうことである。認証構造が複雑化すれば、それぞれの認証局の証明書発行、失効、更新、破棄などが複雑に絡み合い、統一された格納場所の設置や統合された場所での証明書とその関連情報の管理、又はそれらを別の場所に一旦集めて統合化する作業は非現実的である。
【0006】
更に、証明書に基づく経路情報は証明書単位であり、発行される証明書毎に経路情報を管理し、また証明書更新時にはいくつかの証明書が新たに生成され、不要な証明書は削除されるため、経路情報管理が複雑になってしまう。
【0007】
本発明の目的は、既存証明書の保存場所の変更や証明書取得等の作業を行わず、証明書経路情報を管理するシステムを提供することにある。
【0008】
【課題を解決するための手段】
上記目的を達成するために本発明は、認証局が発行する証明書に関する登録情報を、証明書に関する経路を格納する経路情報リストに記憶する。証明書に関する経路検索依頼があると、経路情報リストをもとに、認証局のつながりを検索した後、認証局の経路情報を証明書の経路情報へ変換して、証明書経路の検索を行うという構成を採用する。
【0009】
【発明の実施の形態】
以下、本発明の一実施形態について画面を用いて説明する。
【0010】
まず、証明書の経路を検索する際の前提となる、その証明書を発行する認証局の接続状態について図13及び図14を用いて説明する。
【0011】
図13は、A、B、Cの3つの認証局が各々接続している状態を示す。図13において、ノード1301は認証局Aを、ノード1302は認証局Bを、そしてノード1303は認証局Cをそれぞれ表している。しかし実際には、ある認証局が他の認証局と接続されていると判断する基準は、それぞれが発行する証明書どうしが接続されているか否かということであり、その接続経路を検索する必要がある。
【0012】
図14は、各認証局の発行する証明書の接続状態を示す図である。図14において、ノードA/A1401は認証局Aが発行した自己署名証明書、ノードB/B1402は認証局Bが発行した自己署名証明書を示す(以下同様)。ノードA/B1405は認証局Bが認証局Aに対して発行した相互認証証明書、ノードA/C1407は認証局Cが認証局Aに対して発行した相互認証証明書を示す(以下同様)。ノードEE/A1410は、認証局Aがエンドエンティティ(EE)に対して発行したエンドエンティティ証明書を示す(以下同様)。ここで、エンドエンティティとは、ある認証局が発行した自己署名証明書を有する者を示す。
【0013】
ここで、認証局Aと認証局Bとのつながりを確認するためには、図14において、認証局Bの自己署名証明書B/B(ノード1402)→認証局Bが認証局Aに対して発行した相互認証証明書A/B(ノード1405)→認証局Aのエンドエンティティ証明書EE/A(ノード1410)という証明書経路を調べる必要がある。他の認証局間に関する経路も同様である。
【0014】
なお、図14において、ある認証局が発行する証明書が更新された場合は、更新後の証明書に関する各ノードとの接続状態が、図14にさらに加わることとなる。
【0015】
図1は、本発明の一実施例である証明書つながり検索支援システムの構成を示す。図1において、パス経路管理装置10、経路登録装置100、110、120、端末装置140及びディスク装置90、60、30が、ネットワーク40を介して接続されている。パス経路管理装置10、経路登録装置100、110、120及び端末装置140は、処理部であるプロセッサ13、記憶装置であるハードディスク12、データの送受信を行う通信制御部14等からなるパーソナルコンピュータ等の情報処理装置で構成される。ネットワーク40は、インターネットやその他の通信回線、また専用線を示している。
【0016】
経路登録装置A100、B110、C120は認証局に設置され、この経路登録装置は認証局が発行する証明書の格納場所を登録する処理を行う。経路登録装置A100は登録情報104を記憶するメモリ103、制御処理を行うプロセッサ105、通信制御部101、入力部102を有する。プロセッサ105は、入力部102から入力され登録される証明書の格納場所をメモリ103にある登録情報104に書き加え、パス経路管理装置10へ送信する情報を生成し、その情報は、通信制御部101を使って送信される。経路登録装置B110及びC120も同様の構成を有する。
【0017】
パス経路管理装置10は、データの送受信を行う通信制御部14、各種データを記憶するハードディスク12、およびこれら各部の制御や処理を行うプロセッサ13から構成される。プロセッサ13は、経路登録装置A100、B110、C120から送信される登録情報104を、通信制御部14を経由して受け取ると、その情報をハードディスク12内のパス経路情報リスト11へ格納する。新しい認証局からの登録であれば、パス経路情報リストに新たにノードを追加し、そこへ新しい認証局の登録情報104を格納する。現在の認証局からの更新依頼であれば、パス経路情報リストの中からその認証局のノードを検索し、更新データを格納する。このときパス経路情報リスト11は更新日をアップデートする。
【0018】
パス経路管理装置10は、端末装置140内に記憶され、証明書に関する経路検索依頼情報であるパス経路依頼情報143を、通信制御部14を経由して受け取ると、プロセッサ13は、ハードディスク12に記憶されているパス経路情報リスト11を呼び出し、属性データの相互認証証明書アドレス403(図4)の接続相手名を利用してグラフ検索を行い、まず認証局のつながりを確認する。認証局のつながりが確認されると、プロセッサ13は、図4に示す属性データの自己署名証明書アドレス401、リンク証明書アドレス402、及び相互認証証明書アドレス403の「相互認証証明書の格納場所」を用いて、認証局のつながりから証明書のつながりへと変換する。そして、その変換結果をパス経路検索結果情報602(図6)としてハードディスク12に格納し、通信制御部14を介して端末装置140へ送信する。
【0019】
端末装置140は、プロセッサ144、通信制御部141及びメモリ142を有する。プロセッサ144はパス経路依頼情報143を生成し、その情報を通信制御部141からパス経路管理装置10へ送信する。また端末装置140は、パス経路管理装置10からパス経路検索結果情報を受け取ると、プロセッサ144は証明書データ取得情報を生成し、ディスク装置A90、B60、C30に対して証明書データの取得処理を行う。
【0020】
本実施例においては、各認証局に設置される経路登録装置A100、B110、C120は、自分自身(認証局)の名前および自分自身が発行する証明書の格納場所アドレスを含む登録情報104を記憶しており、通信制御部101は、その登録情報104をパス経路管理装置10へ送信する。ここで、登録情報104は、自分自身の接続相手を特定するデータであり、証明書経路を特定するのに必要なデータを含む。
【0021】
この登録情報104は、パス経路管理装置10のパス経路情報リスト11へ格納され、証明書経路を検索する際のキーとなる属性データとして扱う。またパス経路情報リスト11は、ノードとそれに付属する属性データで構成される。詳細は図3に示す。
【0022】
図2は、経路登録装置100がパス経路管理装置10へ登録する登録情報104を示す図である。経路登録装置100は、パス経路管理装置10へ送信する登録情報として、以下のものを有する。ノード名201欄には認証局の名前を記憶する。登録日202欄には日付や時間を記憶する。自己署名証明書203欄には、現在自己署名証明書が格納されている場所とその自己署名証明書を特定するハッシュ情報、そしてオプションとして更新後に使用される自己署名書証明書が格納されている場所とその自己署名証明書を特定するハッシュ情報を記憶する。リンク証明書204欄は、証明書が更新された場合に、更新後に使用される新しい自己署名証明書との証明書つながりを示す情報を示すものであり、本欄には、新しい証明書の秘密鍵で現在の公開鍵を署名した証明書である現/新リンク証明書が格納されている場所、また更新後に使用される新しい自己署名証明書との証明書つながりを作るため現在の証明書の秘密鍵で新しい証明書の公開鍵を署名した証明書である新/現リンク証明書が格納されている場所を記憶する。経路接続相手205欄は、認証局が接続している相手を示すものであり、本欄には、接続相手名として認証局名と相互認証証明書の格納場所、相互認証証明書を特定するハッシュ情報、そして相互認証証明書のデータのどちらを取得するかを特定するforward情報を記憶する。更新日206欄には、日付情報を記憶する。ここで更新日とは、自己署名証明書を現在の自己署名証明書から新しい自己署名証明書へ更新作業を開始する日を示す。
【0023】
これらの情報の登録は、すべてのデータが必要ではなく、認証局が登録に必要なデータのみを設定することができる。
【0024】
図3は、パス経路管理装置10が保持するパス経路情報リスト11を示す。まずデータ構造としてリスト構造を生成し、その構造に属性データが追加情報として格納されている。ここではポインタを使用してデータのつながりを確保している。まず先頭ノードには更新日を示す更新ノード301があり、更新日データ305を持っている。その後のノードは登録された認証局名を特定するノード302、303、304がリスト化され、それぞれのノードには属性データを保有する。属性データの詳細については、以下の図4において説明する。
【0025】
図4は、パス経路情報リスト11(図3)のノード302、303、304、…が保有する属性データを示す。この属性データは、経路登録装置100がパス経路管理装置10に対して送信する登録情報104に含まれるデータである。自己署名証明書アドレス401は登録情報の自己署名証明書203を格納する。リンク証明書アドレス402は登録情報のリンク証明書204を格納する、相互認証証明書アドレス403は登録情報の経路接続相手205を格納する。このデータは複数持つことが可能である。更新作業開始日404は登録情報の更新日206を格納する。
【0026】
図5は、端末装置140がパス経路管理装置10へ依頼するパス経路依頼情報143の内容を示す。始点501には、認証局名(経路開始ノード)が記憶される。始点501は、経路情報の要求者が信頼する認証局を意味し、認証局の経路つながりを確認するにあたっての、経路の始まり(始点)となる認証局である。終点502にも、認証局名(経路終点ノード)が記憶される。終点502は、検索相手側が信頼する認証局である。鍵ハッシュ503は、経路情報の要求者が信頼する認証局の証明書を特定するハッシュ情報である。
【0027】
図6は、パス経路管理装置10が端末装置140へ返答するパス経路検索結果情報を示す。更新日601は、パス経路情報の更新日を意味し、端末装置140のキャッシュ情報と比較するための情報である。これにより、キャッシュ情報より新しいかどうか比較することができる。経路602は、各証明書の格納場所の経路情報が含まれる。この情報は複数含まれる場合がある。この情報に基づき、端末装置140は実際の証明書を取得することができる。
【0028】
図7は、グラフ検索後の検索結果情報を示す。この情報は、図3のパス経路情報リストと図5のパス経路依頼情報を使ってグラフ検索した結果である。この情報もリスト構造になっており、上が始点で下が終点を表している。ノード701は始点であり、ノード702は終点である。各ノードは属性データを有する。
【0029】
図8は、登録装置100からパス経路管理装置10に対する登録情報104の登録処理を示すフローチャートである。まず、ノード名201、登録日202、及び自己署名証明書203、リンク証明書204、複数設定可能な経路接続相手205、自己署名証明書の更新期間を示す更新日206を含む登録情報104(図2に示す)が、登録装置100からネットワーク40を経由して送信され、パス経路管理装置10がこの登録情報を受信する(ステップ810)。そして、ノード名201と図3に示すパス経路リストのノード302、303、304をチェックし、新規の認証局からの登録であるか、既存の認証局からの登録であるかをチェックする(ステップ820)。ノード名は、一般に証明書の発行者(issuer)領域に示されているissuer名を使用するが、その他のユニークに識別できるデータであれば何でもよい。但し、識別するために、これ以降同じデータを使用しなければならない。
【0030】
ステップ820におけるチェックの結果、新規の認証局からの登録であれば、パス経路リストのノード304以降に新しいノードを作成し(図3)、新しい属性データ構造を生成し、初期値としてNULLが設定される(ステップ830)。次に、パス経路管理装置10が受信した登録情報の中に、経路接続相手データ205があるか否かを判断し(ステップ831)、ある場合は、生成した属性データの相互認証証明書アドレス403欄(図4)に、接続相手名、相互認証証明書の格納場所、forward情報を格納する(ステップ832)。ここで、経路接続相手データ205の中にforward情報があれば、その経路接続相手名ノードの属性データ(図4)に含まれる相互認証証明書アドレス403の中の接続相手名が自分自身のノード名になっているものを検索し、その相互認証証明書アドレス403の相互認証証明書格納場所に、経路接続相手205の相互認証証明書の格納場所をセットし、そしてforward情報もセットしておく(ステップ834)。そして登録情報(図2)のうちの自己署名証明書データ203は、属性データの自己署名証明書アドレス401(図4)に、リンク証明書204はリンク証明書アドレス402に、更新日260は更新作業開始日404にそれぞれ格納する(ステップ836)。
【0031】
ステップ820の判断において、新規の認証局からの登録でない、つまり既存の認証局からの登録であれば(ステップ820)、その登録情報104のノード名201(図2)と同じであるノードをパス経路情報リスト11から検索し、そのノードの属性データに対して更新されるデータを格納する(ステップ840)。次に、その登録情報の中に経路接続相手データ205があるか否かを判断し(ステップ860)、ある場合は、ステップ832と同様に、生成した属性データの相互認証証明書アドレス403に、接続相手名、相互認証証明書の格納場所、forward情報を格納する(ステップ870)。相互接続相手データ205の中にforward情報がある場合は、ステップ834と同様の処理を行う(ステップ880)。また、登録情報に記載されているその他の情報を属性データへ格納する(ステップ890)。ステップ831とステップ860において複数の経路接続相手205が設定されている場合は、相互接続証明書アドレス403も複数存在するために、接続相手ごとに新たに格納領域が確保されそのデータが格納される。従って同じ格納領域に複数の経路接続相手のデータが格納されることはない。各経路に関するデータの格納が終了すると、パス経路情報リストの全体更新日305を登録日202に変更する(ステップ895)。これにより最新の経路情報リストが登録される。
【0032】
図9は、パス経路依頼情報取得からパス経路検索結果情報の送信までの処理の概要を示すフローチャートである。端末装置140は、証明書のつながりおよび証明書の格納場所を知るために、経路開始ノードである認証局の始点501、経路終点ノードである認証局の終点502、及び始点の自己署名証明書の鍵ハッシュデータ503を含むパス経路依頼情報143(図5参照)を送信し、パス経路管理装置10がこの情報を受信する(ステップ910)。そして経路開始ノードである始点501と経路終点ノードである終点502を検索キーとしてグラフ検索する(ステップ920)。その経路検索結果、認証局のつながりがあると判明すると、その認証局のつながりを証明書のつながりへ変換する。
【0033】
この後の処理は図10及び図11に示すフローチャートを使って詳しく説明する。
【0034】
図10において、まず、証明書のつながりを確認するために、パス経路管理装置10は、現在時刻が更新作業期間内であるかどうか判断する(ステップ1010)。これによって、現在の自己署名証明書の格納場所のみが必要なのか、現在の自己署名証明書並びに新しい自己署名証明書の格納場所を確認しなければいけないかを判断する。ステップ1010の判断において、もし更新作業期間外であれば、経路検索結果の先頭ノード701(図7)の属性データから、自己署名証明書アドレス401の現自己署名証明書の格納場所を、パス経路検索結果情報(図6)の経路602に格納する(ステップ1020)。この現自己署名証明書の格納場所を、パス経路検索結果情報の一番目経路とするのである。次に、次のノードがあるかどうかを判断する(ステップ1030)。次のノードがある場合は、パス経路検索結果情報(図6)に新たな経路領域を作成し、その領域の中に、現ノード701の属性データから、次のノードの名前と、相互接続名が一致する相互認証証明書の格納場所情報と、forward情報(forward情報が属性データの中に含まれている場合)を格納する(ステップ1040)。ここでまた次のノードがあるかどうか確認し(ステップ1030)、次のノードがあれば、ステップ1040とステップ1050を繰り返す。従って、これらの処理を、最後のノードになるまで繰り返す。ステップ1030において、次のノードがなければ、図9のステップ940へ進む。ステップ940では、ステップ920で検索した次の検索結果があるか否かを判断し、次の検索結果がある場合には、次の検索結果をもとに図10及び図11の処理を繰り返し、ステップ940において、次の検索結果がないと判断した場合は、図9〜図11においてパス経路情報リスト11から情報を抽出して作成したパス経路検索結果情報を端末装置140へ送信する(ステップ950)。
【0035】
図10のステップ1010において、現在時刻が更新作業期間内であれば、図11に示す処理を行う。更新作業期間内である場合は、パス経路管理装置10において、現在有効な自己署名証明書を信用するのか、それとも新しい自己署名証明書を信用するのかを判別しなければならない。更新作業期間内の場合は、信頼すべき自己署名証明書が複数存在する場合が考えられる。その場合、同じ認証局から異なる証明書が2枚発行されることがあり得る。そこで、どちらを信用するかということは、どちらの自己署名証明書から発行されているかを判断するという意味である。従って、どちらの自己署名証明書を信用するかを判別するためには、パス経路依頼情報143の鍵データ503に含まれる鍵ハッシュと、自己署名証明書アドレス401に含まれる鍵ハッシュを比較して、どちらの鍵を信用するのか判断する(ステップ1110)。このステップでの処理は、より具体的には、どちらの自己署名証明書から発行されたのかを判断し、その自己署名証明書の鍵データに含まれる鍵ハッシュからハッシュ値を計算し、その値をパス経路依頼情報(図5)に格納するという処理である。
【0036】
ステップ1110での判断の結果、現在有効な自己署名証明書を信用すると判断した場合は、先頭ノード701の属性データから自己署名証明書401の現自己署名証明書の格納場所を、パス経路検索結果情報(図6)の経路602に格納する(ステップ1120)。この現自己署名証明書の格納場所を一番目の経路として格納する。次に、新しい鍵で相互認証署証明書を発行しているかどうかを、先頭ノード701の属性データに含まれる自己署名証明書アドレス401の現自己署名証明書の鍵ハッシュと、相互認証証明書アドレス403の鍵ハッシュとを比べ判断する(ステップ1125)。もし新しい鍵で相互認証証明書が発行されている場合は、パス経路結果情報(図6)の経路に新たな経路領域を作成して、その領域に、先頭ノード701の属性データのリンク証明書アドレス402にある新/現リンク証明書の格納場所情報を格納する(ステップ1130)。つまり、この格納場所を、二番目の経路として格納する。
【0037】
次に、経路検索結果(図7)の現ノード701に次のノードがあるか否かを判断する(ステップ1160)。次のノードがあると判断した場合は、パス経路情報結果情報に新たな経路領域を作成し、その領域に、現ノード701の属性データから次のノードの名前と相互接続名が一致する相互認証証明書の格納場所と、forward情報(属性データの中にforward情報がある場合)を格納する(ステップ1170)。ここでまた次のノードがあるかどうか確認し、次のノードがある場合はステップ1170とステップ1180を繰り返す。次のノードがなければ、図9のステップ940へ進む。つまり、最後のノードになるまで、ステップ1170と1180の処理を繰り返す。
【0038】
また、ステップ1125において、新しい鍵で相互認証証明書が発行されていないと判断した場合には、上述したステップ1160の処理を行う。
【0039】
また、ステップ1110において、新しい自己署名証明書を信用すると判断した場合は、先頭ノード701の属性データ自己署名証明書401に含まれる新自己署名証明書の格納場所情報を、パス経路検索結果情報(図6)の経路602に格納する(ステップ1140)。次に、先頭ノード701の属性データに含まれる自己署名証明書アドレス401の新自己署名証明書の鍵ハッシュと相互認証証明書アドレス403の鍵ハッシュを比べ、新しい鍵で相互認証証明書を発行しているかどうかを判断する(ステップ1145)。その判断の結果、新しい鍵で相互認証証明書が発行されている場合は、上述するステップ1160の処理を行う。新しい鍵で相互認証証明書が発行されていない場合は、パス経路結果情報(図6)の経路に新たな経路領域を作成し、その領域に、先頭ノード701の属性データに含まれるリンク証明書アドレス402の現/新リンク証明書の格納場所を格納する(ステップ1150)。
【0040】
図10のステップ1030または図11のステップ1160において次のノードがないと判断した場合は、図9の処理に戻り、ステップ920で検索した次の検索結果があるかどうかを判断し(ステップ940)、次の検索結果がある場合には、図10または図11に示すフローチャートを繰り返し、次の検索結果がない場合には、図10または図11のフローチャートにおいて、パス経路情報リスト11から情報を抽出し作成したパス経路検索結果情報を、端末装置140へ送信する(ステップ950)。
【0041】
図12は、端末装置140がパス経路検索結果情報(図6)を取得した後、証明書データを取得する処理を示すフローチャートである。端末装置140は、パス経路管理装置10が送信したパス経路検索結果情報を受信する(ステップ1210)。次に、受信した経路情報から、順番に格納場所と任意のforward情報を取り出し、ネットワーク40を経由してディスク装置90、60、30に格納された証明書データを取得する(ステップ1220)。ここで、経路情報の中にforward情報が含まれているか否かを判断する(ステップ1230)。forward情報が含まれている場合は、forward属性の中の証明書を取り出す(ステップ1250)。forward情報が含まれていない場合は、reverse属性の中の証明書を取り出す(ステップ1240)。そして、次の経路情報があるか否かを検索し(ステップ1260)、次の経路があればステップ1220に戻り処理を繰り返す。もし次の経路がなければ処理を終了する。
【0042】
ここで、forward属性とreverse属性について説明する。相互認証証明書は、forward属性とreverse属性に分かれており、reverseとは、自分が信頼する自己署名証明書を発行する認証局から、他の認証局に発行された証明書を意味し、forwardとは、他の認証局から、自分が信頼する認証局へ発行された証明書を意味する。
【0043】
【発明の効果】
本発明によれば、証明書のパス構築に必要な証明書の格納場所を取得する際に、パス経路の検索時間を短縮することができるという効果を有する。
【図面の簡単な説明】
【図1】本発明の一実施形態である証明書経路管理システムのシステム構成を示す図である。
【図2】経路登録装置100の登録情報104を示す図である。
【図3】パス経路管理装置10が保持するパス経路情報リスト11を示す図である。
【図4】図3に示すノードが持つ属性データを示す図である。
【図5】端末装置140がパス経路管理装置10へ送信するパス経路依頼情報を示す図である。
【図6】パス経路管理装置10が端末装置140へ送信するパス経路検索結果情報を示す図である。
【図7】グラフ検索後の検索結果情報を示す図である。
【図8】経路登録装置100からのパス登録情報に基づく登録処理を示すフローチャートである。
【図9】パス経路依頼情報からパス経路を検索する処理を示すフローチャートである。
【図10】図9においてグラフ検索した後、証明書経路の検索に必要な証明書の格納場所を設定する処理を示すフローチャートである。
【図11】図9においてグラフ検索した後、更新時の証明書経路の検索に必要な証明書の格納場所を設定する処理を示すフローチャートである。
【図12】端末装置140がパス経路検索結果情報を受け取り、証明書を取得する処理を示すフローチャートである。
【図13】各認証局の接続状態を示す図である。
【図14】各認証局が発行した証明書の接続状態を示す図である。
【符号の説明】
10:パス経路管理装置、11:パス経路情報リスト、12:ハードディスク、13:プロセッサ、14:通信制御部、90:ディスク装置、100:経路登録装置、104:登録情報、140:端末装置、143:パス経路依頼情報
【発明の属する技術分野】
本発明は、公開鍵暗号基盤における証明書経路管理システムに関し、特に、証明書の経路検証に必要な証明書の格納場所情報を用いて証明書情報を取得する証明書経路管理システムに関する。
【0002】
【従来の技術】
公開鍵暗号基盤(Public Key Infrastructure:PKI)が、個人対企業間、企業対企業間などで安全に通信が行えるように導入されている。公開鍵暗号基盤では、電子署名、暗号、認証、否認防止のサービスが提供されており、これらサービスは利用者に発行された証明書を使用し実現されている。ここで、安全なPKIサービスが利用者間で実現されるために、受信者は送信者の送ったメッセージを受けると、受信者が信用する認証局から送信者証明書のまでのパス(経路)を何らかの方法で検証しなければならない。パス検証に関する基本的な処理は、まず検証者から検証処理に必要な証明書を取得する証明書構築という作業を行い、次にパスのつながりを検証するパス検証という作業を行う(例えば、特許文献1参照)。
【0003】
【特許文献1】
特開2001−350406号(第4ページ、図1)
【0004】
【発明が解決しようとする課題】
この作業でネックとなるのは、証明書の経路、すなわち証明書のつながりを発見するという作業である。現在この作業は、パス経路発見の効率を上げるために、出来るだけ一つの場所に必要な証明書のすべてが保存され、グラフ検索理論を使用し経路情報を発見しながらパス構築している。または様々な場所を総当りで検索しながら経路情報を発見しながらパス構築している。
【0005】
この場合の問題は、認証構造が複雑になると、経路情報の発見に時間を費やしてしまい、証明書の取得作業に時間がかかってしまうことである。認証構造が複雑化すれば、それぞれの認証局の証明書発行、失効、更新、破棄などが複雑に絡み合い、統一された格納場所の設置や統合された場所での証明書とその関連情報の管理、又はそれらを別の場所に一旦集めて統合化する作業は非現実的である。
【0006】
更に、証明書に基づく経路情報は証明書単位であり、発行される証明書毎に経路情報を管理し、また証明書更新時にはいくつかの証明書が新たに生成され、不要な証明書は削除されるため、経路情報管理が複雑になってしまう。
【0007】
本発明の目的は、既存証明書の保存場所の変更や証明書取得等の作業を行わず、証明書経路情報を管理するシステムを提供することにある。
【0008】
【課題を解決するための手段】
上記目的を達成するために本発明は、認証局が発行する証明書に関する登録情報を、証明書に関する経路を格納する経路情報リストに記憶する。証明書に関する経路検索依頼があると、経路情報リストをもとに、認証局のつながりを検索した後、認証局の経路情報を証明書の経路情報へ変換して、証明書経路の検索を行うという構成を採用する。
【0009】
【発明の実施の形態】
以下、本発明の一実施形態について画面を用いて説明する。
【0010】
まず、証明書の経路を検索する際の前提となる、その証明書を発行する認証局の接続状態について図13及び図14を用いて説明する。
【0011】
図13は、A、B、Cの3つの認証局が各々接続している状態を示す。図13において、ノード1301は認証局Aを、ノード1302は認証局Bを、そしてノード1303は認証局Cをそれぞれ表している。しかし実際には、ある認証局が他の認証局と接続されていると判断する基準は、それぞれが発行する証明書どうしが接続されているか否かということであり、その接続経路を検索する必要がある。
【0012】
図14は、各認証局の発行する証明書の接続状態を示す図である。図14において、ノードA/A1401は認証局Aが発行した自己署名証明書、ノードB/B1402は認証局Bが発行した自己署名証明書を示す(以下同様)。ノードA/B1405は認証局Bが認証局Aに対して発行した相互認証証明書、ノードA/C1407は認証局Cが認証局Aに対して発行した相互認証証明書を示す(以下同様)。ノードEE/A1410は、認証局Aがエンドエンティティ(EE)に対して発行したエンドエンティティ証明書を示す(以下同様)。ここで、エンドエンティティとは、ある認証局が発行した自己署名証明書を有する者を示す。
【0013】
ここで、認証局Aと認証局Bとのつながりを確認するためには、図14において、認証局Bの自己署名証明書B/B(ノード1402)→認証局Bが認証局Aに対して発行した相互認証証明書A/B(ノード1405)→認証局Aのエンドエンティティ証明書EE/A(ノード1410)という証明書経路を調べる必要がある。他の認証局間に関する経路も同様である。
【0014】
なお、図14において、ある認証局が発行する証明書が更新された場合は、更新後の証明書に関する各ノードとの接続状態が、図14にさらに加わることとなる。
【0015】
図1は、本発明の一実施例である証明書つながり検索支援システムの構成を示す。図1において、パス経路管理装置10、経路登録装置100、110、120、端末装置140及びディスク装置90、60、30が、ネットワーク40を介して接続されている。パス経路管理装置10、経路登録装置100、110、120及び端末装置140は、処理部であるプロセッサ13、記憶装置であるハードディスク12、データの送受信を行う通信制御部14等からなるパーソナルコンピュータ等の情報処理装置で構成される。ネットワーク40は、インターネットやその他の通信回線、また専用線を示している。
【0016】
経路登録装置A100、B110、C120は認証局に設置され、この経路登録装置は認証局が発行する証明書の格納場所を登録する処理を行う。経路登録装置A100は登録情報104を記憶するメモリ103、制御処理を行うプロセッサ105、通信制御部101、入力部102を有する。プロセッサ105は、入力部102から入力され登録される証明書の格納場所をメモリ103にある登録情報104に書き加え、パス経路管理装置10へ送信する情報を生成し、その情報は、通信制御部101を使って送信される。経路登録装置B110及びC120も同様の構成を有する。
【0017】
パス経路管理装置10は、データの送受信を行う通信制御部14、各種データを記憶するハードディスク12、およびこれら各部の制御や処理を行うプロセッサ13から構成される。プロセッサ13は、経路登録装置A100、B110、C120から送信される登録情報104を、通信制御部14を経由して受け取ると、その情報をハードディスク12内のパス経路情報リスト11へ格納する。新しい認証局からの登録であれば、パス経路情報リストに新たにノードを追加し、そこへ新しい認証局の登録情報104を格納する。現在の認証局からの更新依頼であれば、パス経路情報リストの中からその認証局のノードを検索し、更新データを格納する。このときパス経路情報リスト11は更新日をアップデートする。
【0018】
パス経路管理装置10は、端末装置140内に記憶され、証明書に関する経路検索依頼情報であるパス経路依頼情報143を、通信制御部14を経由して受け取ると、プロセッサ13は、ハードディスク12に記憶されているパス経路情報リスト11を呼び出し、属性データの相互認証証明書アドレス403(図4)の接続相手名を利用してグラフ検索を行い、まず認証局のつながりを確認する。認証局のつながりが確認されると、プロセッサ13は、図4に示す属性データの自己署名証明書アドレス401、リンク証明書アドレス402、及び相互認証証明書アドレス403の「相互認証証明書の格納場所」を用いて、認証局のつながりから証明書のつながりへと変換する。そして、その変換結果をパス経路検索結果情報602(図6)としてハードディスク12に格納し、通信制御部14を介して端末装置140へ送信する。
【0019】
端末装置140は、プロセッサ144、通信制御部141及びメモリ142を有する。プロセッサ144はパス経路依頼情報143を生成し、その情報を通信制御部141からパス経路管理装置10へ送信する。また端末装置140は、パス経路管理装置10からパス経路検索結果情報を受け取ると、プロセッサ144は証明書データ取得情報を生成し、ディスク装置A90、B60、C30に対して証明書データの取得処理を行う。
【0020】
本実施例においては、各認証局に設置される経路登録装置A100、B110、C120は、自分自身(認証局)の名前および自分自身が発行する証明書の格納場所アドレスを含む登録情報104を記憶しており、通信制御部101は、その登録情報104をパス経路管理装置10へ送信する。ここで、登録情報104は、自分自身の接続相手を特定するデータであり、証明書経路を特定するのに必要なデータを含む。
【0021】
この登録情報104は、パス経路管理装置10のパス経路情報リスト11へ格納され、証明書経路を検索する際のキーとなる属性データとして扱う。またパス経路情報リスト11は、ノードとそれに付属する属性データで構成される。詳細は図3に示す。
【0022】
図2は、経路登録装置100がパス経路管理装置10へ登録する登録情報104を示す図である。経路登録装置100は、パス経路管理装置10へ送信する登録情報として、以下のものを有する。ノード名201欄には認証局の名前を記憶する。登録日202欄には日付や時間を記憶する。自己署名証明書203欄には、現在自己署名証明書が格納されている場所とその自己署名証明書を特定するハッシュ情報、そしてオプションとして更新後に使用される自己署名書証明書が格納されている場所とその自己署名証明書を特定するハッシュ情報を記憶する。リンク証明書204欄は、証明書が更新された場合に、更新後に使用される新しい自己署名証明書との証明書つながりを示す情報を示すものであり、本欄には、新しい証明書の秘密鍵で現在の公開鍵を署名した証明書である現/新リンク証明書が格納されている場所、また更新後に使用される新しい自己署名証明書との証明書つながりを作るため現在の証明書の秘密鍵で新しい証明書の公開鍵を署名した証明書である新/現リンク証明書が格納されている場所を記憶する。経路接続相手205欄は、認証局が接続している相手を示すものであり、本欄には、接続相手名として認証局名と相互認証証明書の格納場所、相互認証証明書を特定するハッシュ情報、そして相互認証証明書のデータのどちらを取得するかを特定するforward情報を記憶する。更新日206欄には、日付情報を記憶する。ここで更新日とは、自己署名証明書を現在の自己署名証明書から新しい自己署名証明書へ更新作業を開始する日を示す。
【0023】
これらの情報の登録は、すべてのデータが必要ではなく、認証局が登録に必要なデータのみを設定することができる。
【0024】
図3は、パス経路管理装置10が保持するパス経路情報リスト11を示す。まずデータ構造としてリスト構造を生成し、その構造に属性データが追加情報として格納されている。ここではポインタを使用してデータのつながりを確保している。まず先頭ノードには更新日を示す更新ノード301があり、更新日データ305を持っている。その後のノードは登録された認証局名を特定するノード302、303、304がリスト化され、それぞれのノードには属性データを保有する。属性データの詳細については、以下の図4において説明する。
【0025】
図4は、パス経路情報リスト11(図3)のノード302、303、304、…が保有する属性データを示す。この属性データは、経路登録装置100がパス経路管理装置10に対して送信する登録情報104に含まれるデータである。自己署名証明書アドレス401は登録情報の自己署名証明書203を格納する。リンク証明書アドレス402は登録情報のリンク証明書204を格納する、相互認証証明書アドレス403は登録情報の経路接続相手205を格納する。このデータは複数持つことが可能である。更新作業開始日404は登録情報の更新日206を格納する。
【0026】
図5は、端末装置140がパス経路管理装置10へ依頼するパス経路依頼情報143の内容を示す。始点501には、認証局名(経路開始ノード)が記憶される。始点501は、経路情報の要求者が信頼する認証局を意味し、認証局の経路つながりを確認するにあたっての、経路の始まり(始点)となる認証局である。終点502にも、認証局名(経路終点ノード)が記憶される。終点502は、検索相手側が信頼する認証局である。鍵ハッシュ503は、経路情報の要求者が信頼する認証局の証明書を特定するハッシュ情報である。
【0027】
図6は、パス経路管理装置10が端末装置140へ返答するパス経路検索結果情報を示す。更新日601は、パス経路情報の更新日を意味し、端末装置140のキャッシュ情報と比較するための情報である。これにより、キャッシュ情報より新しいかどうか比較することができる。経路602は、各証明書の格納場所の経路情報が含まれる。この情報は複数含まれる場合がある。この情報に基づき、端末装置140は実際の証明書を取得することができる。
【0028】
図7は、グラフ検索後の検索結果情報を示す。この情報は、図3のパス経路情報リストと図5のパス経路依頼情報を使ってグラフ検索した結果である。この情報もリスト構造になっており、上が始点で下が終点を表している。ノード701は始点であり、ノード702は終点である。各ノードは属性データを有する。
【0029】
図8は、登録装置100からパス経路管理装置10に対する登録情報104の登録処理を示すフローチャートである。まず、ノード名201、登録日202、及び自己署名証明書203、リンク証明書204、複数設定可能な経路接続相手205、自己署名証明書の更新期間を示す更新日206を含む登録情報104(図2に示す)が、登録装置100からネットワーク40を経由して送信され、パス経路管理装置10がこの登録情報を受信する(ステップ810)。そして、ノード名201と図3に示すパス経路リストのノード302、303、304をチェックし、新規の認証局からの登録であるか、既存の認証局からの登録であるかをチェックする(ステップ820)。ノード名は、一般に証明書の発行者(issuer)領域に示されているissuer名を使用するが、その他のユニークに識別できるデータであれば何でもよい。但し、識別するために、これ以降同じデータを使用しなければならない。
【0030】
ステップ820におけるチェックの結果、新規の認証局からの登録であれば、パス経路リストのノード304以降に新しいノードを作成し(図3)、新しい属性データ構造を生成し、初期値としてNULLが設定される(ステップ830)。次に、パス経路管理装置10が受信した登録情報の中に、経路接続相手データ205があるか否かを判断し(ステップ831)、ある場合は、生成した属性データの相互認証証明書アドレス403欄(図4)に、接続相手名、相互認証証明書の格納場所、forward情報を格納する(ステップ832)。ここで、経路接続相手データ205の中にforward情報があれば、その経路接続相手名ノードの属性データ(図4)に含まれる相互認証証明書アドレス403の中の接続相手名が自分自身のノード名になっているものを検索し、その相互認証証明書アドレス403の相互認証証明書格納場所に、経路接続相手205の相互認証証明書の格納場所をセットし、そしてforward情報もセットしておく(ステップ834)。そして登録情報(図2)のうちの自己署名証明書データ203は、属性データの自己署名証明書アドレス401(図4)に、リンク証明書204はリンク証明書アドレス402に、更新日260は更新作業開始日404にそれぞれ格納する(ステップ836)。
【0031】
ステップ820の判断において、新規の認証局からの登録でない、つまり既存の認証局からの登録であれば(ステップ820)、その登録情報104のノード名201(図2)と同じであるノードをパス経路情報リスト11から検索し、そのノードの属性データに対して更新されるデータを格納する(ステップ840)。次に、その登録情報の中に経路接続相手データ205があるか否かを判断し(ステップ860)、ある場合は、ステップ832と同様に、生成した属性データの相互認証証明書アドレス403に、接続相手名、相互認証証明書の格納場所、forward情報を格納する(ステップ870)。相互接続相手データ205の中にforward情報がある場合は、ステップ834と同様の処理を行う(ステップ880)。また、登録情報に記載されているその他の情報を属性データへ格納する(ステップ890)。ステップ831とステップ860において複数の経路接続相手205が設定されている場合は、相互接続証明書アドレス403も複数存在するために、接続相手ごとに新たに格納領域が確保されそのデータが格納される。従って同じ格納領域に複数の経路接続相手のデータが格納されることはない。各経路に関するデータの格納が終了すると、パス経路情報リストの全体更新日305を登録日202に変更する(ステップ895)。これにより最新の経路情報リストが登録される。
【0032】
図9は、パス経路依頼情報取得からパス経路検索結果情報の送信までの処理の概要を示すフローチャートである。端末装置140は、証明書のつながりおよび証明書の格納場所を知るために、経路開始ノードである認証局の始点501、経路終点ノードである認証局の終点502、及び始点の自己署名証明書の鍵ハッシュデータ503を含むパス経路依頼情報143(図5参照)を送信し、パス経路管理装置10がこの情報を受信する(ステップ910)。そして経路開始ノードである始点501と経路終点ノードである終点502を検索キーとしてグラフ検索する(ステップ920)。その経路検索結果、認証局のつながりがあると判明すると、その認証局のつながりを証明書のつながりへ変換する。
【0033】
この後の処理は図10及び図11に示すフローチャートを使って詳しく説明する。
【0034】
図10において、まず、証明書のつながりを確認するために、パス経路管理装置10は、現在時刻が更新作業期間内であるかどうか判断する(ステップ1010)。これによって、現在の自己署名証明書の格納場所のみが必要なのか、現在の自己署名証明書並びに新しい自己署名証明書の格納場所を確認しなければいけないかを判断する。ステップ1010の判断において、もし更新作業期間外であれば、経路検索結果の先頭ノード701(図7)の属性データから、自己署名証明書アドレス401の現自己署名証明書の格納場所を、パス経路検索結果情報(図6)の経路602に格納する(ステップ1020)。この現自己署名証明書の格納場所を、パス経路検索結果情報の一番目経路とするのである。次に、次のノードがあるかどうかを判断する(ステップ1030)。次のノードがある場合は、パス経路検索結果情報(図6)に新たな経路領域を作成し、その領域の中に、現ノード701の属性データから、次のノードの名前と、相互接続名が一致する相互認証証明書の格納場所情報と、forward情報(forward情報が属性データの中に含まれている場合)を格納する(ステップ1040)。ここでまた次のノードがあるかどうか確認し(ステップ1030)、次のノードがあれば、ステップ1040とステップ1050を繰り返す。従って、これらの処理を、最後のノードになるまで繰り返す。ステップ1030において、次のノードがなければ、図9のステップ940へ進む。ステップ940では、ステップ920で検索した次の検索結果があるか否かを判断し、次の検索結果がある場合には、次の検索結果をもとに図10及び図11の処理を繰り返し、ステップ940において、次の検索結果がないと判断した場合は、図9〜図11においてパス経路情報リスト11から情報を抽出して作成したパス経路検索結果情報を端末装置140へ送信する(ステップ950)。
【0035】
図10のステップ1010において、現在時刻が更新作業期間内であれば、図11に示す処理を行う。更新作業期間内である場合は、パス経路管理装置10において、現在有効な自己署名証明書を信用するのか、それとも新しい自己署名証明書を信用するのかを判別しなければならない。更新作業期間内の場合は、信頼すべき自己署名証明書が複数存在する場合が考えられる。その場合、同じ認証局から異なる証明書が2枚発行されることがあり得る。そこで、どちらを信用するかということは、どちらの自己署名証明書から発行されているかを判断するという意味である。従って、どちらの自己署名証明書を信用するかを判別するためには、パス経路依頼情報143の鍵データ503に含まれる鍵ハッシュと、自己署名証明書アドレス401に含まれる鍵ハッシュを比較して、どちらの鍵を信用するのか判断する(ステップ1110)。このステップでの処理は、より具体的には、どちらの自己署名証明書から発行されたのかを判断し、その自己署名証明書の鍵データに含まれる鍵ハッシュからハッシュ値を計算し、その値をパス経路依頼情報(図5)に格納するという処理である。
【0036】
ステップ1110での判断の結果、現在有効な自己署名証明書を信用すると判断した場合は、先頭ノード701の属性データから自己署名証明書401の現自己署名証明書の格納場所を、パス経路検索結果情報(図6)の経路602に格納する(ステップ1120)。この現自己署名証明書の格納場所を一番目の経路として格納する。次に、新しい鍵で相互認証署証明書を発行しているかどうかを、先頭ノード701の属性データに含まれる自己署名証明書アドレス401の現自己署名証明書の鍵ハッシュと、相互認証証明書アドレス403の鍵ハッシュとを比べ判断する(ステップ1125)。もし新しい鍵で相互認証証明書が発行されている場合は、パス経路結果情報(図6)の経路に新たな経路領域を作成して、その領域に、先頭ノード701の属性データのリンク証明書アドレス402にある新/現リンク証明書の格納場所情報を格納する(ステップ1130)。つまり、この格納場所を、二番目の経路として格納する。
【0037】
次に、経路検索結果(図7)の現ノード701に次のノードがあるか否かを判断する(ステップ1160)。次のノードがあると判断した場合は、パス経路情報結果情報に新たな経路領域を作成し、その領域に、現ノード701の属性データから次のノードの名前と相互接続名が一致する相互認証証明書の格納場所と、forward情報(属性データの中にforward情報がある場合)を格納する(ステップ1170)。ここでまた次のノードがあるかどうか確認し、次のノードがある場合はステップ1170とステップ1180を繰り返す。次のノードがなければ、図9のステップ940へ進む。つまり、最後のノードになるまで、ステップ1170と1180の処理を繰り返す。
【0038】
また、ステップ1125において、新しい鍵で相互認証証明書が発行されていないと判断した場合には、上述したステップ1160の処理を行う。
【0039】
また、ステップ1110において、新しい自己署名証明書を信用すると判断した場合は、先頭ノード701の属性データ自己署名証明書401に含まれる新自己署名証明書の格納場所情報を、パス経路検索結果情報(図6)の経路602に格納する(ステップ1140)。次に、先頭ノード701の属性データに含まれる自己署名証明書アドレス401の新自己署名証明書の鍵ハッシュと相互認証証明書アドレス403の鍵ハッシュを比べ、新しい鍵で相互認証証明書を発行しているかどうかを判断する(ステップ1145)。その判断の結果、新しい鍵で相互認証証明書が発行されている場合は、上述するステップ1160の処理を行う。新しい鍵で相互認証証明書が発行されていない場合は、パス経路結果情報(図6)の経路に新たな経路領域を作成し、その領域に、先頭ノード701の属性データに含まれるリンク証明書アドレス402の現/新リンク証明書の格納場所を格納する(ステップ1150)。
【0040】
図10のステップ1030または図11のステップ1160において次のノードがないと判断した場合は、図9の処理に戻り、ステップ920で検索した次の検索結果があるかどうかを判断し(ステップ940)、次の検索結果がある場合には、図10または図11に示すフローチャートを繰り返し、次の検索結果がない場合には、図10または図11のフローチャートにおいて、パス経路情報リスト11から情報を抽出し作成したパス経路検索結果情報を、端末装置140へ送信する(ステップ950)。
【0041】
図12は、端末装置140がパス経路検索結果情報(図6)を取得した後、証明書データを取得する処理を示すフローチャートである。端末装置140は、パス経路管理装置10が送信したパス経路検索結果情報を受信する(ステップ1210)。次に、受信した経路情報から、順番に格納場所と任意のforward情報を取り出し、ネットワーク40を経由してディスク装置90、60、30に格納された証明書データを取得する(ステップ1220)。ここで、経路情報の中にforward情報が含まれているか否かを判断する(ステップ1230)。forward情報が含まれている場合は、forward属性の中の証明書を取り出す(ステップ1250)。forward情報が含まれていない場合は、reverse属性の中の証明書を取り出す(ステップ1240)。そして、次の経路情報があるか否かを検索し(ステップ1260)、次の経路があればステップ1220に戻り処理を繰り返す。もし次の経路がなければ処理を終了する。
【0042】
ここで、forward属性とreverse属性について説明する。相互認証証明書は、forward属性とreverse属性に分かれており、reverseとは、自分が信頼する自己署名証明書を発行する認証局から、他の認証局に発行された証明書を意味し、forwardとは、他の認証局から、自分が信頼する認証局へ発行された証明書を意味する。
【0043】
【発明の効果】
本発明によれば、証明書のパス構築に必要な証明書の格納場所を取得する際に、パス経路の検索時間を短縮することができるという効果を有する。
【図面の簡単な説明】
【図1】本発明の一実施形態である証明書経路管理システムのシステム構成を示す図である。
【図2】経路登録装置100の登録情報104を示す図である。
【図3】パス経路管理装置10が保持するパス経路情報リスト11を示す図である。
【図4】図3に示すノードが持つ属性データを示す図である。
【図5】端末装置140がパス経路管理装置10へ送信するパス経路依頼情報を示す図である。
【図6】パス経路管理装置10が端末装置140へ送信するパス経路検索結果情報を示す図である。
【図7】グラフ検索後の検索結果情報を示す図である。
【図8】経路登録装置100からのパス登録情報に基づく登録処理を示すフローチャートである。
【図9】パス経路依頼情報からパス経路を検索する処理を示すフローチャートである。
【図10】図9においてグラフ検索した後、証明書経路の検索に必要な証明書の格納場所を設定する処理を示すフローチャートである。
【図11】図9においてグラフ検索した後、更新時の証明書経路の検索に必要な証明書の格納場所を設定する処理を示すフローチャートである。
【図12】端末装置140がパス経路検索結果情報を受け取り、証明書を取得する処理を示すフローチャートである。
【図13】各認証局の接続状態を示す図である。
【図14】各認証局が発行した証明書の接続状態を示す図である。
【符号の説明】
10:パス経路管理装置、11:パス経路情報リスト、12:ハードディスク、13:プロセッサ、14:通信制御部、90:ディスク装置、100:経路登録装置、104:登録情報、140:端末装置、143:パス経路依頼情報
Claims (7)
- 認証局によって発行される証明書の検証を行うための経路情報を管理する証明書経路情報管理システムにおいて、
証明書の発行を行う認証局に設置され、その認証局が発行する証明書に関する登録情報を記憶する経路登録装置と、
証明書に関する経路情報を格納する経路情報リストを備え、該経路登録装置から送信される登録情報を前記経路情報リストに記憶する経路管理装置と、
検証対象の証明書に関する経路検索依頼情報を前記経路管理装置に送信する端末装置とを備え、
前記経路管理装置は、前記端末装置から受信した経路検索依頼情報をもとに、前記経路情報リストの中から証明書に関する経路情報を検索し、該検索結果を前記端末装置に送信することを特徴とする証明書経路情報管理システム。 - 前記端末装置は、前記経路管理装置から証明書に関する経路情報を受信した場合に、その証明書に関する情報を記憶する外部装置にアクセスして、その証明書に関する情報を取得することを特徴とする請求項1記載の証明書経路情報管理システム。
- 前記経路管理装置は、前記経路登録装置から送信された登録情報が、前記経路情報リストに既に含まれている情報であるか、又は新規情報であるかを判断し、前記経路情報リストの情報を更新することを特徴とする請求項1記載の証明書経路情報管理システム。
- 認証局が発行する証明書に関する証明書経路情報を管理する証明書経路管理装置において、
前記認証局が発行する証明書に関する登録情報を受信する送受信手段と、
証明書に関する経路情報を格納した経路情報リストを記憶する記憶手段と、
前記受信部が受信した登録情報を、前記記憶部に記憶した前記経路情報リストに追加する処理を行う処理手段とを備えることを特徴とする証明書経路管理装置。 - 前記送受信手段が証明書に関する経路検索依頼情報を受信した場合に、
前記処理手段は、該経路検索依頼情報に係る証明書に関する経路情報を前記経路情報リストの中から検索し、
前記送受信手段は、該検索結果を送信することを特徴とする請求項4記載の証明書経路管理装置。 - 認証局が発行する証明書に関する証明書経路情報を管理する証明書経路管理方法であって、
前記認証局が発行する証明書の登録情報を受信し、
証明書に関する証明書経路情報を格納した経路情報リストを記憶し、
前記受信した登録情報が新規の認証局からの登録情報であるか否かを判断し、
新規の認証局からの登録情報である場合は、前記経路情報リストに、前記新規の認証局に対応するノードを作成し、
前記受信した登録情報をそのノードの属性情報として追加することを特徴とする証明書経路管理方法。 - 前記証明書経路管理方法はさらに、
証明書に関する経路検索依頼情報であって、少なくとも経路の両端の認証局情報を含む経路検索依頼情報を受信し、
該経路の両端の認証局情報をもとに前記証明書に関する経路を検索することを特徴とする請求項6記載の証明書経路管理方法。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002378941A JP2004214751A (ja) | 2002-12-27 | 2002-12-27 | 証明書経路情報管理システム及び証明書経路管理方法 |
EP03003760A EP1434384A1 (en) | 2002-12-27 | 2003-02-19 | Certificate path information management system and certificate management device |
US10/378,114 US20040128503A1 (en) | 2002-12-27 | 2003-02-28 | Certificate path information management system and certificate management device |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002378941A JP2004214751A (ja) | 2002-12-27 | 2002-12-27 | 証明書経路情報管理システム及び証明書経路管理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004214751A true JP2004214751A (ja) | 2004-07-29 |
Family
ID=32463614
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002378941A Pending JP2004214751A (ja) | 2002-12-27 | 2002-12-27 | 証明書経路情報管理システム及び証明書経路管理方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US20040128503A1 (ja) |
EP (1) | EP1434384A1 (ja) |
JP (1) | JP2004214751A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100736091B1 (ko) | 2005-12-09 | 2007-07-06 | 삼성전자주식회사 | 복수의 인증서를 관리하는 장치 및 방법 |
JP2008177949A (ja) * | 2007-01-19 | 2008-07-31 | Seiko Epson Corp | 認証装置及び方法 |
JP2011160361A (ja) * | 2010-02-03 | 2011-08-18 | Mitsubishi Electric Corp | 証明書検証システム、経路制約情報生成装置、証明書検証装置および証明書検証方法 |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8019989B2 (en) * | 2003-06-06 | 2011-09-13 | Hewlett-Packard Development Company, L.P. | Public-key infrastructure in network management |
US7370206B1 (en) | 2003-09-04 | 2008-05-06 | Adobe Systems Incorporated | Self-signing electronic documents |
JP3894181B2 (ja) * | 2003-10-10 | 2007-03-14 | 株式会社日立製作所 | 公開鍵証明書検証の高速化方法、および装置 |
US20070043667A1 (en) * | 2005-09-08 | 2007-02-22 | Bahman Qawami | Method for secure storage and delivery of media content |
GB2431746B (en) | 2005-10-29 | 2010-09-08 | Hewlett Packard Development Co | A method of authorising a computing entity |
US8195945B2 (en) * | 2005-12-01 | 2012-06-05 | Sony Mobile Communications Ab | Secure digital certificate storing scheme for flash memory and electronic apparatus |
US20080244263A1 (en) * | 2007-03-29 | 2008-10-02 | Tc Trust Center, Gmbh | Certificate management system |
DE102009031143B3 (de) * | 2009-06-30 | 2010-12-09 | Siemens Aktiengesellschaft | Vorrichtung und Verfahren zum Erstellen und Validieren eines digitalen Zertifikats |
US8464249B1 (en) | 2009-09-17 | 2013-06-11 | Adobe Systems Incorporated | Software installation package with digital signatures |
CN103138922B (zh) * | 2011-11-24 | 2016-06-29 | 北大方正集团有限公司 | 一种数字内容传输的方法、系统及装置 |
CN115250194B (zh) * | 2022-01-10 | 2023-07-18 | 重庆科创职业学院 | 一种基于大数据终端设备的计算机网络安全通信方法 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6397329B1 (en) * | 1997-11-21 | 2002-05-28 | Telcordia Technologies, Inc. | Method for efficiently revoking digital identities |
US6134550A (en) * | 1998-03-18 | 2000-10-17 | Entrust Technologies Limited | Method and apparatus for use in determining validity of a certificate in a communication system employing trusted paths |
US6458794B2 (en) * | 1999-12-21 | 2002-10-01 | Icagen, Inc. | Potassium channel inhibitors |
JP3588042B2 (ja) * | 2000-08-30 | 2004-11-10 | 株式会社日立製作所 | 証明書の有効性確認方法および装置 |
JP2002099211A (ja) * | 2000-09-21 | 2002-04-05 | Sony Corp | 公開鍵証明書発行要求処理システムおよび公開鍵証明書発行要求処理方法 |
US20030074555A1 (en) * | 2001-10-17 | 2003-04-17 | Fahn Paul Neil | URL-based certificate in a PKI |
-
2002
- 2002-12-27 JP JP2002378941A patent/JP2004214751A/ja active Pending
-
2003
- 2003-02-19 EP EP03003760A patent/EP1434384A1/en not_active Withdrawn
- 2003-02-28 US US10/378,114 patent/US20040128503A1/en not_active Abandoned
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100736091B1 (ko) | 2005-12-09 | 2007-07-06 | 삼성전자주식회사 | 복수의 인증서를 관리하는 장치 및 방법 |
US8006084B2 (en) | 2005-12-09 | 2011-08-23 | Samsung Electronics Co., Ltd. | Apparatus and method for managing plurality of certificates |
JP2008177949A (ja) * | 2007-01-19 | 2008-07-31 | Seiko Epson Corp | 認証装置及び方法 |
JP2011160361A (ja) * | 2010-02-03 | 2011-08-18 | Mitsubishi Electric Corp | 証明書検証システム、経路制約情報生成装置、証明書検証装置および証明書検証方法 |
Also Published As
Publication number | Publication date |
---|---|
EP1434384A1 (en) | 2004-06-30 |
US20040128503A1 (en) | 2004-07-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8635449B2 (en) | Method of validation public key certificate and validation server | |
JP5576985B2 (ja) | 署名に用いる暗号アルゴリズムの決定方法、検証サーバおよびプログラム | |
US6134550A (en) | Method and apparatus for use in determining validity of a certificate in a communication system employing trusted paths | |
EP1185027B1 (en) | Certificate validity authentication method and apparatus | |
EP2129077B1 (en) | Validation server, validation method and program | |
JP3761557B2 (ja) | 暗号化通信のための鍵配付方法及びシステム | |
JP4895190B2 (ja) | 電子機器の認証に関する識別管理のためのシステム | |
US20030037234A1 (en) | Method and apparatus for centralizing a certificate revocation list in a certificate authority cluster | |
JP2004214751A (ja) | 証明書経路情報管理システム及び証明書経路管理方法 | |
JP2003258788A (ja) | 公開鍵暗号方式における登録局サーバの運用方法、その運用方法に用いられる登録局サーバ、及びその運用方法に用いられるプログラム | |
JP2004072717A (ja) | Crl発行通知機能付き認証基盤システム | |
EP1770585A2 (en) | Security method and system and computer-readable medium storing computer program for executing the security method | |
JP5425496B2 (ja) | 通信システム、証明書検証装置及びサービス提供方法 | |
KR100844436B1 (ko) | 지역적인 공개키 기반 구조를 갖는 지역분포형 로컬 씨에이시스템 | |
JP2007104044A (ja) | 認証情報提供システムおよび方法、プログラム | |
JP2020036228A (ja) | 情報処理装置、通信機器、および情報処理システム | |
US20050120207A1 (en) | Method and system for enabling PKI in a bandwidth restricted environment | |
JP6319817B2 (ja) | 検証装置及び電子証明書検証方法 | |
JP2014033395A (ja) | 証明書失効リスト管理システム、証明書失効リスト生成装置、検証装置及び電子証明書検証方法 | |
JP4057995B2 (ja) | Pki認証システムにおける代替証明書発行・検証システム | |
JP2004056635A (ja) | 証明書失効リストの更新装置、システム及び方法 | |
JP2006148454A (ja) | 信頼点証明書管理サーバ並びに情報端末及び情報通信システム | |
JP2005252500A (ja) | 属性証明書検証サーバ、認証システム、属性証明書検証方法、認証方法、属性証明書検証用プログラムおよび認証用プログラム | |
JP2007266894A (ja) | 属性証明書管理システム、属性証明書管理方法 | |
JP2002244558A (ja) | 認証システムアクセス装置及び公開鍵証明証取得方法及び公開鍵証明証無効化確認方法及び、認証システムアクセスプログラム及び公開鍵証明証取得プログラム及び公開鍵証明証無効化確認プログラム及び認証システムアクセスプログラムを格納した記憶媒体及び公開鍵証明証取得プログラムを格納した記憶媒体及び公開鍵証明証無効化確認プログラムを格納した記憶媒体 |