JP2008301417A - 検証サーバ、プログラム及び検証方法 - Google Patents

Abstract

【課題】認証局で更新された公開鍵及び複数のハッシュアルゴリズムを効率的に管理する技術を提供すること。
【解決手段】
認証局において更新された公開鍵及びハッシュアルゴリズムにより一意に定まる識別子を識別子情報記憶領域１３１ｂに記憶しておき、検証処理部１３２ｃは、受信した検証要求を識別子情報記憶領域１３１ｂに記憶されている識別子と照合し、対応する識別子が存在する場合には、検証を行うことが可能と判断して処理を続行する。
【選択図】図４

Description

公開鍵証明書の検証を行う技術に関する。

電子文書など電子データを送付する際に、対象となるデータに対して、送信者の電子署名と公開鍵証明書を添付することで、受信者が、受信データに添付された電子署名（以下「署名」ともいう）と公開鍵証明書（以下「証明書」ともいう）の有効性の確認を行い、送付されたデータが改ざんされていないことと、確かに本人から送られた電子データであることを確認することができる。

公開鍵証明書の発行と有効性の確認は、公開鍵基盤において行われ、その標準仕様はＲＦＣ３２８０（Internet X.509 Public Key Infrastructure Certificate and CRL Profile）等にて規定されている。

証明書は、その有効期間が終了する前に、証明書の記載内容に変更があった場合や、対応する秘密鍵が危殆化した場合等には、当該証明書を発行した認証局（Certificate Authority：以下「ＣＡ」ともいう）により失効され、無効となる。このため受信者は、当該証明書の有効性確認において、当該証明書が失効しているか否かを確認する。

失効しているか否かの確認には、当該認証局が発行する証明書失効リスト（Certificate Revocation List：以下「ＣＲＬ」という）を用いる。ＣＲＬには、当該認証局が発行した有効期間内の証明書のうち、失効された証明書のシリアルナンバーが記載され、当該認証局の署名が付されており、ＣＲＬは、当該認証局によって定期的に発行されている。受信者は、当該認証局から当該ＣＲＬを取得し、当該証明書のシリアルナンバーが、ＣＲＬに記載されているかどうかを確認する。シリアルナンバーがＣＲＬに記載されている場合は、当該証明書が失効され無効であると判断し、記載されていない場合には、当該公開鍵証明書が失効されていないと判断する。

しかしながら、認証局が発行する証明書の枚数が多数あり、かつ失効する証明書が多い場合、ＣＲＬの容量が膨大になってしまうため、受信者がＣＲＬを取得するために時間がかかってしまう等、証明書の有効性確認処理に時間がかかってしまうことがあった。これに対応するために、オンラインで当該証明書が失効しているかどうかの確認要求を受け付けて、これに応答するサービスをサーバ（以下「検証サーバ」とよぶ）で行うことができ、その標準仕様は非特許文献１にて規定されている。

検証サーバは、予め認証局が発行するＣＲＬを定期的に取り込み、証明書の失効確認をする受信者が利用する端末装置から証明書の失効確認要求（以下「検証要求」とよぶ）を受け付けたら、当該証明書のシリアルナンバーが予め取り込んだＣＲＬに記載されているかどうかを調べ、当該証明書が失効されているかどうかを端末装置に応答する。検証サーバから端末装置へ送付される応答電文（以下「検証結果」とよぶ）には、当該検証サーバの署名及び証明書が付与さる。これにより端末装置の利用者は、当該検証サーバによって確かに送付された検証結果であることを確認できる。

Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）、Ｘ．５０９ Ｉｎｔｅｒｎｅｔ Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｐｒｏｔｏｃｏｌ − ＯＣＳＰ（ＲＦＣ２５６０）、ｐａｇｅ ４「２．５ Ｒｅｓｐｏｎｓｅ Ｐｒｅ−ｐｒｏｄｕｃｔｉｏｎ」、［online］、１９９９年６月、［平成１８年１月２３日検索］、インターネット＜URL：http://ietf.org/rfc/rfc2560.txt＞

非特許文献１では、認証局の鍵更新が行われた場合や、端末が利用するハッシュアルゴリズムが複数存在する場合には、検証対象証明書がどの認証局（認証局は、認証局の名称及び公開鍵で特定できる）に対応付くものか、複数のハッシュアルゴリズムのうちどのハッシュアルゴリズムを使用するのか等、認証局の鍵の世代やハッシュアルゴリズムを適切に管理しておかなければ、検証サーバで、証明書の検証を行うことができなくなってしまうこともある。

そこで、本発明は、検証サーバにおいて、認証局の鍵の世代及び複数のハッシュアルゴリズムを効率的に管理する技術を提供することを目的とする。

以上の課題を解決するため、本発明は、認証局の鍵情報（公開鍵）及びハッシュアルゴリズムにより一意に定まる識別情報を記憶しておく。

例えば、本発明は、公開鍵証明書の検証を行う検証サーバであって、認証局の鍵情報毎及びハッシュアルゴリズム毎に一意に定まる第一識別情報を、記憶する記憶部と、検証要求に含まれる認証局の鍵情報、および、当該検証要求を作成するときに用いられたハッシュアルゴリズム、により定まる第二識別情報に対応する第一識別情報が前記記憶部に記憶されている場合には、当該検証要求に対する検証を行うことができると判断する処理部と、を備えること、を特徴とする。

このことにより、認証局の鍵の世代及び複数のハッシュアルゴリズムを効率的に管理することができ、ＣＡが鍵更新を行っている場合や、端末装置が複数のハッシュアルゴリズムを使用する場合にも、当該検証要求に対応するＣＲＬを効率的に特定し、失効しているかどうかを確認できる。

以上のように、本発明によれば、認証局で更新された公開鍵及び複数のハッシュアルゴリズムを効率的に管理することができ、端末装置からの検証要求を受け付けてから応答をするまでの時間を短縮することができる。

図１は、本発明の一実施形態である検証システム１００の構成図である。

図示するように、検証システム１００は、端末装置１１０と、ＣＡ装置１２０と、検証サーバ１３０と、を備えており、端末装置１１０、ＣＡ装置１２０及び検証サーバ１３０は、ネットワーク１５０を介して相互に情報を送受信することができるようにされている。

そして、検証システム１００においては、端末装置１１０は、検証サーバ１３０に証明書の検証要求を行い、ＣＡ装置１２０は、証明書の発行及び失効処理を行い、検証サーバ１３０は、証明書の検証を行う。

図２は、端末装置１１０の概略図である。

端末装置１１０は、記憶部１１１と、処理部１１２と、通信部１１３と、入出力部１１４と、を有する。

記憶部１１１は、ユーザが作成した電子文書を保持する電子文書記憶領域１１１ａと、署名を生成するための秘密鍵、当該秘密鍵と対になる公開鍵の証明書、および、端末装置１１０を利用するユーザが信頼するＣＡのＣＡ証明書、を記憶する鍵情報記憶領域１１１ｂと、他の端末装置１１０から受け取った署名付き電子文書及び証明書を記憶する検証対象記憶領域１１１ｃと、を有する。

処理部１１２は、電子文書に対して署名を付与し、署名付き文書を作成する署名付き文書作成部１１２ａと、書名付き電子文書の署名および証明書の検証を行う検証部１１２ｂと、端末装置の各部を統括的に制御する制御部１１２ｃと、を有する。

通信部１１３は、ネットワーク１５０を介して他の装置と情報の送受信を行う。

入出力部１１４は、端末装置１１０のユーザが作成した電子文書や他の端末１１０から受け取った電子文書の入出力やユーザからの指示を受け付ける。

このような構成において、制御部１１２ｃは、入出力部１１４を介してユーザから、電子文書記憶領域１１１ａに保持してある電子文書を他のユーザの端末装置１１０に送信すべき旨の指示を受け付けると、当該電子文書を電子文書記憶領域１１１ａから読み出し、これを文書作成部１１２ａに渡す。

文書作成部１１２ａは、鍵情報記憶領域１１１ｂに記憶されている秘密鍵を用いて、渡された当該電子文書に対する署名を生成する。そして、渡された電子文書に生成した署名を付して署名付き電子文書を作成する。

そして、制御部１１２ｃは、文書作成部１１２ａで作成された署名付き電子文書と、鍵情報記憶領域１１１ｂに記憶されている証明書と、を、通信部１１３を介して、ユーザから指示された送信先の端末装置１１０へ送信する。

また、制御部１１２ｃは、通信部１１３を介して、他の端末装置１１０から署名付き電子文書と証明書を受け取ると、これらを関連づけて検証対象記憶領域１１１ｃに記憶すると共に、これらの署名付き電子署名と証明書の検証要求を検証部１１２ｂに通知する。

これを受けて、検証部１１２ｂは、検証対象記憶領域１１１ｃに記憶されている署名付き電子文書の署名を、当該署名付き電子文書に対応付けて記憶されている証明書を用いて検証する。そして、検証部１１２ｂは、署名付き電子文書の署名検証に使用した当該証明書を検証対象証明書として鍵情報記憶領域１１１ｂに記憶する。

また、検証部１１２ｂは、鍵情報記憶領域１１１ｂに記憶した検証対象証明書を、ユーザが信頼するＣＡのＣＡ証明書を用いて検証する。ここで、検証部１１２ｂは、当該検証対象証明書の検証処理において、当該検証対象証明書の署名の検証や、有効期間が切れていない事の確認や、その他制限事項の検証や、当該検証対象証明書が失効しているかどうかを確認する。

検証部１１２ｂは、当該検証対象証明書が失効しているかどうかの確認を行うために、検証サーバ１３０に対して検証要求を送信する。そして、全ての検証が成功し、かつ、検証サーバ１３から当該証明書が失効されていない旨の検証結果を受信した場合に、当該検証対象証明書が有効であり、署名付き電子文書が正当なものと扱い、必要に応じて入出力部１１４から署名付き文書の署名及び証明書の検証結果を出力する。

図３は、ＣＡ装置１２０の概略図である。

図示するように、ＣＡ装置１２０は、記憶部１２１と、処理部１２２と、通信部１２３と、入出力部１２４と、を備える。

記憶部１２１は、後述する発行部１２２ａが発行した証明書を記憶する証明書データベース（以下、証明書ＤＢという）１２１ａと、証明書ＤＢ１２１ａに保持されている各証明書の発行先が記憶された発行先管理リストを記憶する発行先情報記憶領域１２１ｂと、ＣＲＬを記憶するＣＲＬ記憶領域１２１ｃと、を有する。

処理部１２２は、証明書を発行する発行部１２２ａと、発行部１２２ａが発行した証明書の管理を行う管理部１２２ｂと、ＣＡ装置１２０の各部を統括的に制御する制御部１２２ｃと、を有する。

通信部１２３は、ネットワーク１５０を介して他の装置と情報の送受信を行う。

入出力部１２４は、証明書等の入出力やＣＡ装置１２０の操作者からの指示の受付や処理結果の出力を行う。

このような構成において、制御部１２２ｃは、入出力部１２４あるいは通信部１２３を介して証明書の発行依頼を受け付けると、その旨を発行部１２２ａに伝える。

このような発行依頼を受けて、発行部１２２ａは、これに対する証明書を作成する。この際、ＣＡの秘密鍵で証明書に署名をする。そして、作成した証明書を入出力部１２４あるいは通信部１２３を介して、郵送あるいは通信により、証明書の発行依頼元に渡す。

また、管理部１２２ｂは、この証明書を証明書ＤＢ１２１ａに登録すると共に、その発行先（つまり発行依頼元）の情報を、発行先情報記憶領域１２１ｂに記憶されている発行先リストに格納する。

そして、制御部１２２ｃは、入出力部１２４あるいは通信部１２３を介して、証明書の失効依頼を受け付けると、その旨を管理部１２２ｂに伝える。これを受けて、管理部１２２ｂは、失効対象の証明書を証明書ＤＢ１２１ａから削除すると共に、当該証明書の発行先の情報を、発行先情報記憶領域１２１ｂに記憶されている発行先管理リストから削除する。

さらに、管理部１２２ｂは、失効依頼により証明書ＤＢ１２１ａから削除した証明書のシリアルナンバーを記述した失効証明書リスト（ＣＲＬ）を、定期的に作成し、これをＣＲＬ記憶領域１２１ｃに格納する。なお、作成したＣＲＬには、ＣＡ装置１２０が発行した証明書のうち、有効期限内にもかかわらず失効した証明書のシリアルナンバーと、当該証明書が失効した日時と、当該証明書が失効した理由がリストとして記述される。さらに、次回のＣＲＬ作成予定時刻が記述され、ＣＡ装置１２０の秘密鍵を用いて署名が付与される。

また、制御部１２２ｃは、通信部１２３を介して、他装置よりＣＲＬ取得要求を受け取ると、ＣＲＬ記憶領域１２１ｃに記憶されているＣＲＬを、通信部１２３を介して、問い合わせをした他装置に送信する。

図４は、検証サーバ１３０の概略図である。

図示するように、検証サーバ１３０は、記憶部１３１と、処理部１３２と、通信部１３３と、入出力部１３４と、を備える。

記憶部１３１は、設定情報記憶領域１３１ａと、識別子情報記憶領域１３１ｂと、失効情報記憶領域１３１ｃと、検証結果情報記憶領域１３１ｄと、鍵情報記憶領域１３１ｅと、を有する。

設定情報記憶領域１３１ａには、検証サーバ１３０で検証を行う際に必要となる情報が記憶される。

例えば、本実施形態においては、ＣＡ証明書やハッシュアルゴリズム等の検証を行う際の情報、および、ＣＲＬ更新タイミングや署名付き検証結果データの有効期間等の各種設定情報、が記憶されている。

識別子情報記憶領域１３１ｂには、各々のＣＡ毎に、更新した各々の鍵と、各々のハッシュアルゴリズムと、から特定される識別子（ＣＡ識別子）を特定する情報が記憶される。

例えば、本実施形態においては、図５（ＣＡ識別子テーブル１６０の概略図）に示すようなＣＡ識別子テーブル１６０が記憶される。

図示するようにＣＡ識別子テーブル１６０は、対応するハッシュアルゴリズム毎に、各々のＣＡ毎に更新された各々の公開鍵を有するＣＡ証明書毎に特定されるＣＡ識別子が各々の欄に格納される。

具体的には、ＣＡ識別子テーブル１６０は、対応するハッシュアルゴリズム毎に設けられた列であるハッシュアルゴリズムＯＩＤ列１６１ａ、１６１ｂと、検証サーバ１３０で検証を行うＣＡ装置１２０毎に設けられた行であるＣＡ識別子行１６２ａ、１６２ｂ、１６２ｃと、が形成されており、さらに、各ハッシュアルゴリズムＯＩＤ列１６１ａ、１６１ｂには、更新された公開鍵毎に設けられた列である公開鍵列１６３ａ、１６３ｂ、１６３ｃが形成されている。

このようなＣＡ識別子テーブル１６０において、各々の列と行で特定される欄には、ＣＡ識別子行１６２ａ、１６２ｂ、１６２ｃ、および、公開鍵列１６３ａ、１６３ｂ、１６３ｃ、で特定されるＣＡ証明書に記述される主体者名（subject）と公開鍵（subjectPublicKeyInfo）のハッシュ値をハッシュアルゴリズムＯＩＤ列１６１ａ、１６１ｂに対応するハッシュアルゴリズムで計算し、この二つのハッシュ値のペア（ここでは、「主体者名のハッシュ値」／「公開鍵のハッシュ値」のようにして連結している）がＣＡ識別子として格納される。

そして、これらの欄の内、予め定められたハッシュアルゴリズムを用いて、最新の公開鍵のハッシュ値を算出したものを格納している欄に格納されるＣＡ識別子を基準ＣＡ識別子とする。なお、本実施形態においては、ＣＡ識別子テーブル１６０のハッシュアルゴリズムＯＩＤ１列１６１ａに格納されているＣＡ識別子の内、最新の公開鍵に対応するものを基準ＣＡ識別子としているがこのような態様に限定されるわけではない。

なお、図５のＣＡ識別子テーブル１６０では、検証サーバ１３０が対応するハッシュアルゴリズムは２種類あり、さらに検証サーバ１３０はＣＡ１、ＣＡ２、ＣＡ３の３つのＣＡに対応するパターンの例を示している。ＣＡ１は鍵更新を行って３世代の鍵のＣＡ証明書が登録されており（１６２ａの行）、ＣＡ２は鍵更新を行って２世代の鍵のＣＡ証明書が登録されており（１６２ｂの行）、ＣＡ３は鍵更新が行われておらず、一つの鍵のＣＡ証明書が登録されている（１６２ｃの行）場合に、全ての証明書に関してＣＡ識別子を計算し、ＣＡ識別子テーブル１６０を作成した場合の例である。

失効情報記憶領域１３１ｃには、失効した証明書を識別する情報が記憶される。

本実施形態においては、失効情報記憶領域１３１ｃに、図６（失効情報テーブル１７０の概略図）に示すような失効情報テーブル１７０が記憶される。

図示するように失効情報テーブル１７０は、ＣＡ識別子列１７０ａと、ＣＲＬ有効期間列１７０ｂと、失効した証明書のシリアルナンバー列１７０ｃと、証明書失効日時列１７０ｄと、証明書の失効理由列１７０ｅと、を備え、ＣＡ装置１２０からＣＲＬを受信する毎に当該ＣＡ装置１２０に対応する行が更新される。

ＣＡ識別子列１７０ａの対応する欄には、各々のＣＡを識別する情報が格納される。本実施形態においては、基準ＣＡ識別子が格納される。

ＣＲＬ有効期間列１７０ｂの対応する欄には、ＣＡ識別子列１７０ａで特定されるＣＡ装置１２０から受信した最新のＣＲＬの有効期間を特定する情報が格納される。

失効した証明書のシリアルナンバー列１７０ｃの対応する欄には、失効した証明書のシリアルナンバーを特定する情報が格納される。

証明書失効日時列１７０ｄの対応する欄には、失効した証明書のシリアルナンバー列１７０ｃで特定される証明書の失効した日時を特定する情報が格納される。

証明書の失効理由列１７０ｅの対応する欄には、失効した証明書のシリアルナンバー列１７０ｃで特定される証明書の失効理由を特定する情報が格納される。

検証結果情報記憶領域１３１ｃには、署名付き検証結果データがＣＡ毎に記憶される。

具体的に、本実施形態においては、図７（検証結果テーブル１８０の概略図）に示すような検証結果テーブル１８０が検証結果情報記憶領域１３１ｃに記憶される。

図示するように、検証結果テーブル１８０は、ＣＡ識別子列１８０ａと、最終利用日時列１８０ｂと、署名付き検証結果データ列１８０ｃと、を有する。

ＣＡ識別子列１８０ａの対応する欄には、各々のＣＡを識別する情報が格納される。本実施形態においては、基準ＣＡ識別子が格納される。

最終利用日時列１８０ｂの対応する欄には、後述する署名付き検証結果データ列１８０ｃの対応する欄に格納される署名付き検証結果データを最後に利用した日時を特定する情報が格納される。

署名付き検証結果データ列１８０ｃの対応する欄には、署名付き検証結果データが格納される。

鍵情報記憶領域１３１ｄには、検証サーバ１３０の秘密鍵を特定する情報が格納される。

処理部１３２は、管理部１３２ａと、失効情報管理部１３２ｂと、検証処理部１３２ｃと、制御部１３２ｄと、を有する。

管理部１３２ａは、ＣＡ証明書やハッシュアルゴリズムを設定情報記憶領域１３１ａへ登録するとともに、登録したＣＡ証明書とハッシュアルゴリズムからＣＡ識別子テーブル１６０に格納する情報を生成して対応する欄に格納する。

また、管理部１３２ａは、ＣＲＬ更新タイミングや署名付き検証結果データの有効期間等の各種設定情報を、設定情報記憶領域１３１ａに記憶する。

失効情報管理部１３２ｂは、通信部１３３を介してＣＡ装置１２０にアクセスし、ＣＲＬを取得し、取得したＣＲＬから失効情報テーブル１６０を生成して失効情報記憶領域１３１ｃに記憶する。

また、失効情報管理部１３２ｂは、設定情報記憶領域１３１ａに記憶されているＣＲＬ更新タイミングに従ってＣＲＬを再取得し、失効情報記憶領域１３１ｃに記憶されている失効情報テーブル１７０の対応する欄を更新する。

さらに、失効情報管理部１３２ｂは、ＣＲＬ更新のタイミングにおいて、検証結果情報記憶領域１３１ｄに記憶されている検証結果テーブル１８０の署名付き検証結果データを更新又は削除する。

検証処理部１３２ｃは、端末装置１１０から通信部１３３を介して受け付けた検証要求で特定される検証対象証明書に対応する署名付き検証結果データが、検証結果情報記憶領域１３１ｄに記憶されている検証テーブル１８０に格納されているか否かを検索し、対応する署名付き検証結果データがある場合には、当該署名付き検証結果データを、通信部１３３を介して端末装置１１０へ返信応答する。また、署名付き検証結果データが無い場合には、識別子情報記憶領域１３１ｂに記憶されているＣＡ識別子テーブル１６０と、失効情報記憶領域１３１ｃに記憶されている失効情報テーブル１７０と、を参照し、当該検証対象証明書が失効しているか否かを確認して、確認した結果に沿った署名付き検証結果データを作成し、通信部１３３を介して端末装置１１０へ返信応答するとともに、作成した署名付き検証結果データを検証結果情報記憶領域１３１ｄに記憶されている検証テーブル１８０に格納する。なお、署名付き検証結果データには、鍵情報記憶領域１３１ｅに記憶されている検証サーバ１３０の秘密鍵を用いて署名が付与され、検証サーバ１３０の証明書がとともに端末装置１１０へ送信される。

制御部１３２ｄは、検証サーバ１３０の各部を統括的に制御する。

以上のような検証サーバ１３０においては、操作者は、予め当該検証サーバ１３０が対応するＣＡのＣＡ証明書の登録と、当該検証サーバ１３０が受け付け可能なハッシュアルゴリズムの設定を行う。

検証サーバ１３０の操作者は、入出力部１３４を介してＣＡ証明書を検証サーバ１３０に入力する。これを受けて、管理部１３２ａは、当該ＣＡ証明書を設定情報記憶領域１３１ａに記憶する。検証サーバ１３０が複数のＣＡに対応する（ＣＡ装置１２０が発行するＣＲＬを取り込む）場合には、それら複数のＣＡのＣＡ証明書を、同様に記憶する。

また、ＣＡが鍵更新を行っており、複数のＣＡ証明書を持っている場合は、新しい鍵のＣＡ証明書と、古い鍵のＣＡ証明書（古い鍵が複数世代ある場合には、それらの鍵のＣＡ証明書のうち、有効期間内のもの全て）の記憶を同様に行う。

以上の結果、設定情報記憶領域１３１ａには、検証サーバ１３０が対応する全てのＣＡのＣＡ証明書と、それらＣＡが鍵更新を行っている場合には、有効期間内の全ての世代の鍵に関するＣＡ証明書が保持される。

また、検証サーバ１３０の操作者は、入出力部１３４を介して、当該検証サーバ１３０が受け付け可能なハッシュアルゴリズムのオブジェクト識別子（以下「ＯＩＤ」と記す）を入力する。これを受けて、管理部１３２ａは、当該ハッシュアルゴリズムのＯＩＤを設定情報記憶領域１３１ａに記憶する。

検証サーバ１３０が複数のハッシュアルゴリズムを受け付ける場合には、それら複数のハッシュアルゴリズムのＯＩＤの入力を受け付け、同様に記憶する。

なお、記憶された複数のハッシュアルゴリズムＯＩＤのうち一つは、基準ハッシュアルゴリズムとして登録する。

そして、検証サーバ１３０の管理部１３２ａは、ＣＡ証明書の登録と、ハッシュアルゴリズムの設定がなされたら、これらの情報を基に、図５に示すようなＣＡ識別子テーブル１６０を作成し、識別子情報記憶領域１３１ｂに記憶する。

以上に記載した端末装置１１０、ＣＡ装置１２０、検証サーバ１３０の各々は、例えば、図８（コンピュータ１９０の概略図）に示すような、ＣＰＵ１９１と、メモリ１９２と、ハードディスク等の外部記憶装置１９３と、ＣＤ−ＲＯＭ等の可搬性を有する記憶媒体１９４から情報を読み取る読み取り装置１９５と、キーボードやマウス等の入力装置１９６と、モニタやプリンタ等の出力装置１９７と、ＮＩＣ（Network Interface Card）等の通信装置１９８と、これらの各装置間のデータ送受を行う内部バス１９９と、を備えた、一般的なコンピュータ１９０上に構築可能である。

例えば、ＣＰＵ１９１が外部記憶装置１９３からメモリ１９２上にロードされた所定のプログラムを実行することにより、以上に記載した各処理部を実現できる。また、通信部は、ＣＰＵ１９１が通信装置１９８を利用することにより、入出力部は、ＣＰＵ１９１が入力装置１９６や出力装置１９７や読み取り装置１９５を利用することにより、そして、記憶部は、ＣＰＵ１９１がメモリ１９２や外部記憶装置１９３を利用することにより実現することができる。

上記所定のプログラムは、予め外部記憶装置１９３に格納されていても良いし、コンピュータ１９０が利用可能な記憶媒体１９４に格納されており、読み取り装置１９５を介して、必要に応じて読み出され、あるいは、コンピュータ１９０が利用可能な通信媒体であるネットワークまたはネットワーク上を伝搬する搬送波を利用する通信装置１９８と接続された他の装置から、必要に応じてダウンロードされて、外部記憶装置１９３に格納されるものであってもよい。

図９は、検証サーバ１３０でＣＲＬの更新を行う際の処理を示すフローチャートである。

まず、検証サーバ１３０の失効情報管理部１３２ｂは、検証サーバ１３０の操作者によって予め設定情報記憶領域１３１ａに記憶されたＣＲＬ更新タイミングで特定される所定の期間を経過すると（Ｓ１０でＹｅｓ）、ＣＲＬ取得要求を、通信部１３３を介してＣＡ装置１２０に送信する（Ｓ１１）。これを受け付けたＣＡ装置１２０は、対応するＣＲＬを検証サーバ１３０へ送信する。

次に、検証サーバ１３０の失効情報管理部１３２ｂは、ＣＡ装置１２０からＣＲＬを受信すると（Ｓ１２でＹｅｓ）、ＣＲＬを初めて受信したか否かを確認する（Ｓ１３）。これは、失効情報テーブル１７０が失効情報記憶領域１３１ｃに記憶されているか否かで確認することができる。

そして、検証サーバ１３０の失効情報管理部１３２ｂは、ＣＲＬを初めて受信したばあいには（Ｓ１３でＹｅｓ）、失効情報テーブル１７０を生成して、受信したＣＲＬで特定される情報を対応する欄に格納して（Ｓ１４）、処理を終了する。

具体的には、失効情報管理部１３２ｂは、取得したＣＲＬに記述される発行者名（issuer）および認証局鍵識別子（authorityKeyIdentifier）の値をキーにして、設定情報記憶領域１３１ａに記憶されているＣＡ証明書の中から、対応するＣＡ証明書を特定し、当該ＣＡ証明書を取得する。そして、取得したＣＡ証明書から基準ハッシュアルゴリズムを用いてＣＡ識別子を計算し、生成した失効情報テーブル１７０のＣＡ識別子列１７０ａの対応する欄に格納する。

また、失効情報管理部１３２ｂは、取得したＣＲＬの有効期間（thisUpdate,nextUpdate）を、失効情報テーブル１７０の当該ＣＡ識別子に対応するＣＲＬ有効期間列１７０ｂの欄に格納し、当該ＣＲＬに記述される失効した証明書（revokedCertificates）のシリアルナンバーを失効情報テーブル１７０の当該ＣＡ識別子に対応する失効した証明書のシリアルナンバー欄１７０ｃに格納し、その失効日時（revocationDate）を証明書失効日時列１７０ｄの対応する欄に格納し、その失効理由（reasonCode）を証明書の失効理由列１７０ｅの対応する欄に格納する。なお、失効理由（reasonCode）については、その番号に対応する意味がRFC3280で規定されている。

次に、失効情報管理部１３２ｂは、受信したＣＲＬが更新されたかどうかを確認する（Ｓ１５）。すなわち、ＣＡから受信したＣＲＬの有効期間が、前回までに取得した当該ＣＡのＣＲＬの有効期間よりも新しくなっていた場合、当該ＣＡのＣＲＬが更新されたものとし、ステップＳ１６へ進む。一方、有効期間等のＣＲＬの情報が、前回までに取得した当該ＣＡのＣＲＬと変更していなければ、当該ＣＡのＣＲＬが更新されていないものとして、処理を終了する。

ステップＳ１５においてＣＲＬが更新されていた場合、失効情報管理部１３２ｂは、取得したＣＲＬを基に、失効情報テーブル１７０の更新を行う（Ｓ１６）。

具体的には、失効情報管理部１３１ｂは、取得したＣＲＬで特定される発行者名（issuer）および認証局鍵識別子（authorityKeyIdentifier）の値をキーにして、設定情報記憶領域に記憶されているＣＡ証明書の中から、対応するＣＡ証明書を特定し、特定したＣＡ証明書を取得する。そして、取得したＣＡ証明書から基準ハッシュアルゴリズムを用いてＣＡ識別子を算出する。

次に、失効情報管理部１３１ｂは、失効情報記憶領域１３１ｃに記憶されているＣＡ識別子テーブル１６０を参照し、算出したＣＡ識別子を検索し、対応する基準ＣＡ識別子を取得する。

そして、失効情報管理部１３１ｂは、取得した基準ＣＡ識別子をキーにして、失効情報記憶領域１３１ｃに記憶されている失効情報テーブル１７０のＣＡ識別子列１７０ａから対応するＣＡ識別子を検索する。なお、対応するＣＡ識別子が存在しない場合には、新たなＣＡのＣＲＬと判断し、失効情報テーブル１７０に新たな行を追加して、ＣＡ識別子列１７０ａの欄に格納する。

さらに、失効情報管理部１３１ｂは、取得したＣＲＬの有効期間（thisUpdate,nextUpdate）を、失効情報テーブル１７０の当該ＣＡ識別子に対応するＣＲＬ有効期間列１７０ｂの欄に格納し、当該ＣＲＬに記述される失効した証明書（revokedCertificates）のシリアルナンバー（userCertificate）を失効情報テーブル１７０の失効した証明書のシリアルナンバー列１７０ｃの欄に格納し、当該ＣＲＬの失効日時（revocationDate）を証明書失効日時列１７０ｄの欄に格納し、失効理由（reasonCode）を証明書の失効理由列１７０ｅの欄に格納する。

ステップＳ１６で、失効情報テーブル１７０の更新処理が終了したら、失効情報管理部１３１ｃは、検証結果テーブル１８０の更新処理を行う（Ｓ１７）。この処理については、図１０のフローチャートを用いて具体的に説明する。

図９に示すＣＲＬ更新処理は、検証サーバ１３０が複数のＣＡに対応する場合には、そのＣＡの数だけＣＲＬの更新を繰り返し実施する。本実施形態においては、３つのＣＡに対応する場合を例示しているため、図９のフローチャートに示すＣＲＬ更新処理を３回実施する。

図１０は、検証サーバ１３０において検証結果テーブル１８０の更新処理を行う際のフローチャートである。

失効情報管理部１３２ｂは、ＣＲＬ更新処理で取得したＣＲＬに対応する本フローにおける未確認の署名付き検証結果データが検証結果テーブル１８０にあるかどうかを検索する（Ｓ２０）。

具体的には、失効情報管理部１３２ｂは、当該ＣＲＬの基準ＣＡ識別子をキーにして、検証結果テーブル１８０のＣＡ識別子列１８０ａを検索し、当該基準ＣＡ識別子に対応する署名付き検証結果データであって、本フローの未確認のものが存在するかどうかを確認する。

そして、失効情報管理部１３２ｂは、当該ＣＲＬに対応する未確認の署名付き検証結果データが検証結果テーブル１８０に存在しない場合（ステップＳ２０でＮｏ）、当該ＣＲＬに関して更新するデータが無いものと判断し、検証結果テーブルの更新処理を終了する。

一方、当該ＣＲＬに対応する未確認の署名付き検証結果データが検証結果テーブル１８０に存在する場合（ステップＳ２０でＹｅｓ）、ステップＳ２１に進み、ステップＳ２１では、失効情報管理部１３２ｂは、未確認の署名付き検証結果データを一つ特定し、特定した署名付き検証結果データにつき以下の処理を行う。

失効情報管理部１３２ｂは、ステップＳ２１で特定した署名付き検証結果データに対応する最終利用日時を検証結果テーブル１８０の最終利用日時列１８０ｂから取得し、設定情報記憶領域１３１ａに記憶されているキャッシュの有効期間以上に時間が経過しているかを確認する（Ｓ２２）。そして、キャッシュの有効期間以上に時間が経過している場合（ステップＳ２２でＹｅｓ）には、失効情報管理部１３２ｂは、当該署名付き検証結果データに関するデータを検証結果テーブル１８０から削除し（Ｓ２３）、ステップＳ２０に戻り、処理を繰り返す。

一方、キャッシュの有効期間以上時間が経過していなかった場合（ステップＳ２２でＮｏ）には、失効情報管理部１３２ｂは、ステップＳ２１で特定した署名付き検証結果データの内容を参照し、検証結果が「失効」を示す検証結果かどうかを確認する（Ｓ２４）。

そして、当該署名付き検証結果データの検証結果が「失効」である場合（ステップＳ２４でＹｅｓ）には、失効情報管理部１３２ｂは、当該署名付き検証結果データに記載されたＣＡ識別子及びシリアルナンバーに対応するデータが、失効情報テーブル１７０に存在するかどうかを検索する（Ｓ２５）。

失効情報テーブル１７０に当該署名付き検証結果データに対応するデータが存在しない場合（ステップＳ２５でＮｏ）、失効情報管理部１３２ｂは、当該署名付き検証結果データを検証結果テーブル１８０から削除し（Ｓ２６）、ステップＳ２０に戻り、処理を繰り返す。

一方、失効情報テーブル１７０に当該署名付き検証結果データに対応するデータが存在する場合（ステップＳ２５でＹｅｓ）、ステップＳ２９に進む。

また、当該署名付き検証結果データが「失効」でない場合（ステップＳ２４でＮｏ）、失効情報管理部１３２ｂは、当該署名付き検証結果データに記載されたＣＡ識別子及びシリアルナンバーに対応するデータが、失効情報テーブル１７０に存在するかどうかを検索する（Ｓ２７）。

そして、失効情報テーブル１７０に当該署名付き検証結果データに対応するデータが存在する場合（ステップＳ２７でＹｅｓ）、失効情報管理部１３２ｂは、当該署名付き検証結果データの検証結果を「失効」に変更し（Ｓ２８）、ステップＳ２９に進む。

一方、失効情報テーブル１７０に当該署名付き検証結果データに対応するデータが存在しない場合（ステップＳ２７でＮｏ）には、ステップＳ２９に進む。

そして、ステップＳ２９では、失効情報管理部１３２ｂは、当該署名付き検証結果データに記述されている当該署名付き検証結果データを作成した時間（producedAt）や、失効情報の有効期間（thisUpdate／nextUpdate）を更新し、さらに検証サーバ１３０の署名をしなおし、検証結果テーブルに格納し直す。

そして、失効情報管理部１３２ｂは、ステップＳ２０に戻り、処理を繰り返す。

以上の処理を行うことにより、検証結果ＤＢ９０に格納される検証結果データは更新され、不要な署名付き検証結果データは削除される。

図１１及び図１２は、検証サーバ１３０において証明書を検証する際の処理を示すフローチャートである。

まず、検証サーバ１３０は、端末装置１１０の検証部１１２ｂが生成した検証要求を、通信部１３３を介して受信する（Ｓ３０）。

次に、検証サーバ１３０の検証処理部１３２ｃは、識別子情報記憶領域１３１ｂに記憶されているＣＡ識別子テーブル１６０と、受信した検証要求を照合し（Ｓ３１）、対応するＣＡ識別子が存在するかどうかを確認する（Ｓ３２）。

具体的には、検証処理部１３２ｃは、当該検証要求に含まれる、検証対象証明書を特定する情報（CertID）のうち、ハッシュアルゴリズム（hashiAlgorithm）とＣＡ識別子情報（issuerNameHashおよびissuerKeyHash）をキーにして、ＣＡ識別子テーブル１６０を検索する。

そして、当該検証要求に対応するＣＡ識別子が、ＣＡ識別子テーブル１６０に存在しない場合（ステップＳ３２でＮｏ）、検証処理部１３２ｃは、検証サーバ１３０では当該検証要求に対応する失効情報を持っていないと判断し、その旨を記す検証結果データを作成し（Ｓ３３）、図１２のステップＳ４３へ進む。

一方、当該検証要求に対応するＣＡ識別子が、ＣＡ識別子テーブル１６０に存在する場合（ステップＳ３２でＹｅｓ）、検証処理部１３２ｃは、当該ＣＡ識別子に対応する基準ＣＡ識別子をＣＡ識別子テーブル１６０から取得する（Ｓ３４）。

そして、検証処理部１３２ｃは、当該検証要求と、ステップＳ３４で取得した基準ＣＡ識別子をキーにして、検証結果テーブル１８０との照合を行う（Ｓ３５）。

具体的には、当該基準ＣＡ識別子をキーとして、検証結果テーブル１８０のＣＡ識別子列１８０ａを検索し、当該基準ＣＡ識別子に対応するＣＡ識別子を検索する。次に、当該ＣＡ識別子に対応する署名付き検証結果データの中から、検証要求に含まれる検証対象証明書を特定する情報（CertID）と、署名付き検証結果データに含まれる検証対象証明書を特定する情報（CertID）が同一の署名付き検証結果データがあるかどうかを確認する。

検証要求と同一のCertIDが含まれる署名付き検証結果データが、検証結果テーブル１８０に存在する場合（ステップＳ３６でＹｅｓ）、検証処理部１３２ｃは、その署名付き検証結果データを取得し（Ｓ３７）、ステップＳ４３へ進む。

一方、検証要求と同一のCertIDが含まれる署名付き検証結果データが、検証結果テーブル１８０に存在しない場合（ステップＳ３６でＮｏ）、検証処理部１３２ｃは、検証要求と失効情報テーブル１７０との照合を行う（Ｓ３８）。

具体的には、ステップＳ３４で取得した基準ＣＡ識別子をキーにして、失効情報テーブル１７０のＣＡ識別子列１７０ａを検索し、基準ＣＡ識別子と同一のＣＡ識別子を特定する。次に、当該検証要求に含まれる検証対象証明書のシリアル番号（CertIDのserialNumber）と、当該特定されたＣＡ識別子に対応する失効した証明書のシリアルナンバー列１７０ｃを比較し、検証対象証明書のシリアル番号が、失効情報テーブル１７０の失効した証明書のシリアルナンバー列１７０ｃに格納されているか否かを確認する。

当該検証要求に含まれる検証対象証明書のシリアル番号が失効情報テーブル１７０に存在する場合（ステップＳ３９でＹｅｓ）、検証処理部１３２ｃは、検証対象証明書は失効している旨の署名付き検証結果データを作成する（Ｓ４０）。

一方、当該検証要求に含まれる検証対象証明書のシリアル番号が失効情報テーブル１７０に存在しない場合（ステップＳ３９でＮｏ）、検証処理部１３２ｃは、検証対象証明書は失効していない旨の署名付き検証結果データを作成する（Ｓ４１）。

そして、検証処理部１３２ｃは、ステップＳ４０又はステップＳ４１で作成した書名付き検証結果データを、図１１のステップＳ３４で取得した基準ＣＡ識別子に対応付けて、検証結果テーブル１８０に格納する（Ｓ４２）。さらに、検証処理部１３２ｃは、検証結果テーブル１８０の対応する最終利用日時列１８０ｂの欄に、現在の時刻を格納する。

そして、ステップＳ４３において、検証処理部１３２ｃは、これまでのステップで作成した検証結果データを、通信部１３３を介して、端末装置１１０へ送信する。

以上のステップを実行することによって、検証サーバ１３０は、端末装置１１０からの検証要求を受け付けてから、検証結果データを応答するまでの処理を効率的に行うことが可能であり、応答時間を短縮することができる。

検証システムの構成図。 端末装置の概略図。 ＣＡ装置の概略図。 検証サーバの概略図。 ＣＡ識別子テーブルの概略図。 失効情報テーブルの概略図。 検証結果テーブルの概略図。 コンピュータの概略図。 検証サーバでＣＲＬの更新を行う際の処理を示すフローチャート。 検証サーバにおいて検証結果テーブルの更新処理を行う際のフローチャート。 検証サーバにおいて証明書を検証する際の処理を示すフローチャート。 検証サーバにおいて証明書を検証する際の処理を示すフローチャート。

符号の説明

１００ 検証システム
１１０ 端末装置
１２０ ＣＡ装置
１３０ 検証サーバ
１３１ 記憶部
１３２ 処理部
１３３ 通信部
１３４ 入出力部

Claims (15)

1. 公開鍵証明書の検証を行う検証サーバであって、
   認証局における鍵情報毎及びハッシュアルゴリズム毎に一意に定まる第一識別情報を、記憶する記憶部と、
   検証要求に含まれる認証局の鍵情報、および、当該検証要求を作成するときに用いられたハッシュアルゴリズム、により定まる第二識別情報に対応する第一識別情報が前記記憶部に記憶されている場合には、当該検証要求に対する検証を行うことができると判断する処理部と、
   を備えること、
   を特徴とする検証サーバ。
2. 請求項１に記載の検証サーバであって、
   前記第一識別情報は、認証局の鍵情報から、検証サーバで対応する全てのハッシュアルゴリズムにより算出された各々のハッシュ値であり、
   前記第二識別情報は、検証要求に含まれる認証局の鍵情報から、任意のハッシュアルゴリズムにより算出されたハッシュ値であること、
   を特徴とする検証サーバ。
3. 請求項１に記載の検証サーバであって、
   前記第一識別情報は、認証局の名称及び当該認証局の鍵情報から、検証サーバで対応する全てのハッシュアルゴリズムにより算出された各々のハッシュ値であり、
   前記第二識別情報は、検証要求に含まれる認証局の名称及び当該認証局の鍵情報から、任意のハッシュアルゴリズムにより算出されたハッシュ値であること、
   を特徴とする検証サーバ。
4. 請求項１に記載の検証サーバであって、
   前記認証局において更新された複数の鍵情報の各々に対応して、各々の第一識別情報を前記記憶部に記憶しておくこと、
   を特徴とする検証サーバ。
5. 請求項１に記載の検証サーバであって、
   前記記憶部には、前記第一識別情報が認証局毎に、基準識別情報に対応付けて記憶されており、
   前記記憶部には、前記基準識別情報に対応付けて、失効した公開鍵証明書を識別することのできる失効証明書識別情報が記憶されており、
   前記処理部は、前記検証要求から第二識別情報を取得して、取得した第二識別情報に対応する第一識別情報を前記記憶部から特定し、特定した第一識別情報に対応する基準識別情報を前記記憶部から特定し、特定した基準識別情報に対応する失効証明書識別情報を取得することにより、前記検証要求に添付された公開鍵証明書の識別情報に対応する失効証明書識別情報があるか否かで検証を行うこと、
   を特徴とする検証サーバ。
6. 請求項１に記載の検証サーバであって、
   前記記憶部には、前記第一識別情報が認証局毎に、基準識別情報に対応付けて記憶されており、
   前記記憶部には、前記基準識別情報に対応付けて、既に生成した検証結果データが記憶されており、
   前記処理部は、前記検証要求から第二識別情報を取得して、取得した第二識別情報に対応する第一識別情報を前記記憶部から特定し、特定した第一識別情報に対応する基準識別情報を前記記憶部から特定し、特定した基準識別情報に対応する検証結果データを取得し、前記検証要求に添付された公開鍵証明書を特定する情報と、取得した検証結果データに含まれる検証した公開鍵証明書を特定する情報と、が一致する検証結果データを特定し、特定した検証結果データを予め定められた方法で出力する処理を行うこと、
   を特徴とする検証サーバ。
7. 請求項６に記載の検証サーバであって、
   前記処理部は、失効した公開鍵証明書を識別することのできる失効証明書識別情報を取得する毎に、前記記憶部に記憶されている既に生成した検証結果データの内、有効期限の切れたものについては削除し、有効と判断された検証結果データであって、取得した失効証明書識別情報により失効したものについては、失効と判断する検証結果データに更新すること、
   を特徴とする検証サーバ。
8. コンピュータを、公開鍵証明書の検証を行う検証サーバとして機能させるプログラムであって、
   前記コンピュータを、
   認証局における鍵情報毎及びハッシュアルゴリズム毎に一意に定まる第一識別情報を、記憶する記憶手段、
   検証要求に含まれる認証局の鍵情報、および、当該検証要求を作成するときに用いられたハッシュアルゴリズム、により定まる第二識別情報に対応する第一識別情報が前記記憶手段に記憶されている場合には、当該検証要求に対する検証を行うことができると判断する処理手段、
   として機能させること、
   を特徴とするプログラム。
9. 請求項８に記載のプログラムであって、
   前記第一識別情報は、認証局の鍵情報から、検証サーバで対応する全てのハッシュアルゴリズムにより算出された各々のハッシュ値であり、
   前記第二識別情報は、検証要求に含まれる認証局の鍵情報から、任意のハッシュアルゴリズムにより算出されたハッシュ値であること、
   を特徴とするプログラム。
10. 請求項８に記載のプログラムであって、
    前記第一識別情報は、認証局の名称及び当該認証局の鍵情報から、検証サーバで対応する全てのハッシュアルゴリズムにより算出された各々のハッシュ値であり、
    前記第二識別情報は、検証要求に含まれる認証局の名称及び当該認証局の鍵情報から、任意のハッシュアルゴリズムにより算出されたハッシュ値であること、
    を特徴とするプログラム。
11. 請求項８に記載のプログラムであって、
    前記認証局において更新された複数の鍵情報の各々に対応して、各々の第一識別情報を前記記憶手段に記憶しておくこと、
    を特徴とするプログラム。
12. 請求項８に記載のプログラムであって、
    前記記憶手段には、前記第一識別情報が認証局毎に、基準識別情報に対応付けて記憶されており、
    前記記憶手段には、前記基準識別情報に対応付けて、失効した公開鍵証明書を識別することのできる失効証明書識別情報が記憶されており、
    前記処理手段は、前記検証要求から第二識別情報を取得して、取得した第二識別情報に対応する第一識別情報を前記記憶手段から特定し、特定した第一識別情報に対応する基準識別情報を前記記憶手段から特定し、特定した基準識別情報に対応する失効証明書識別情報を取得することにより、前記検証要求に添付された公開鍵証明書の識別情報に対応する失効証明書識別情報があるか否かで検証を行うこと、
    を特徴とするプログラム。
13. 請求項８に記載のプログラムであって、
    前記記憶手段には、前記第一識別情報が認証局毎に、基準識別情報に対応付けて記憶されており、
    前記記憶手段には、前記基準識別情報に対応付けて、既に生成した検証結果データが記憶されており、
    前記処理手段は、前記検証要求から第二識別情報を取得して、取得した第二識別情報に対応する第一識別情報を前記記憶手段から特定し、特定した第一識別情報に対応する基準識別情報を前記記憶手段から特定し、特定した基準識別情報に対応する検証結果データを取得し、前記検証要求に添付された公開鍵証明書を特定する情報と、取得した検証結果データに含まれる検証した公開鍵証明書を特定する情報と、が一致する検証結果データを特定し、特定した検証結果データを予め定められた方法で出力すること、
    を特徴とするプログラム。
14. 請求項１３に記載のプログラムであって、
    前記処理手段は、失効した公開鍵証明書を識別することのできる失効証明書識別情報を取得する毎に、前記記憶部に記憶されている既に生成した検証結果データの内、有効期限の切れたものについては削除し、有効と判断された検証結果データであって、取得した失効証明書識別情報により失効したものについては、失効と判断する検証結果データに更新すること、
    を特徴とするプログラム。
15. 認証局における鍵情報毎及びハッシュアルゴリズム毎に一意に定まる第一識別情報を、記憶する記憶部と、処理部と、を備える検証サーバにおいて公開鍵証明書の検証を行う検証方法であって、
    前記処理部が、検証要求に含まれる認証局の鍵情報、および、当該検証要求を作成するときに用いられたハッシュアルゴリズム、により定まる第二識別情報に対応する第一識別情報が前記記憶部に記憶されている場合には、当該検証要求に対する検証を行うことができると判断する過程を備えること、
    を特徴とする検証方法。

Images