JP4700388B2 - 原本保証方法および原本保証システム - Google Patents

Description

本発明は、文書データが改ざんされていないことを検証するために、その文書データに対して電子署名を行った結果である署名データの原本性を保証する原本保証方法および原本保証システムに関する。

文書データに対する電子署名（以下、署名という）のデータを生成したときに、その署名データを履歴として記録しておき、新たな署名データを生成するときには、その時点における最新の署名データを新たな署名データに反映させることにより、署名データ間に論理的な連鎖関係（以下、署名チェーンという）を構築する技術（以下、ヒステリシス署名という）がある。記録された履歴の中に、確実に改ざんされていないことが保証されている署名データ（以下、公開署名データという）を定期的に作成し、公開することにより、各署名データの有効期限が切れた後でも文書データの原本性を確保することができる（特許文献１参照）。なお、複数の署名チェーンに属する公開署名データをまとめて信頼ポイントという。
特開２００１−３３１１０４号公報（段落００３６〜００４０、図４）

しかしながら、署名チェーン上において、何らかの原因で所定の署名データＡが消失したり、破壊されたりした場合、「署名データＡから過去に遡って最も近い署名データ」（署名データＡより１つ古い署名データ）からの、「署名データＡから過去に遡って最も近い公開署名データ」より１つ新しい署名データまでの各署名データの信頼性を確保できなくなるという問題がある。

また、ヒステリシス署名を生成するクライアント（以下、署名生成クライアントという）と、署名履歴を管理するサーバ（以下、履歴管理サーバという）とは、同一筐体であった。これは、署名データの生成と同時に署名履歴を格納することにより、署名チェーンに矛盾を生じさせないためである。署名生成クライアントや履歴管理サーバを複数の筐体に分けると、署名履歴の管理が煩雑になるため、複数の署名履歴を一括して管理する履歴管理サーバが必要となる。

そこで、署名チェーンに矛盾を生じさせず、署名データの生成と署名履歴の管理とを別の筐体で実現する場合、署名生成クライアントにおいて、署名データを生成するときに履歴管理サーバから前の署名データを取得し、その前の署名データと対象文書とから署名データを生成し、その署名データを即時に履歴管理サーバに送信しなければならないという問題がある。この場合、署名生成クライアントと履歴管理サーバとの間にオンラインによる通信手段を用意しなければならなかった。

本発明は、前記問題に鑑み、ヒステリシス署名において、署名データの消失や破壊が発生しても、その署名データに連鎖する他の署名データの信頼性を確保する手段を提供することを課題とする。また、署名データの生成と署名履歴の管理とを別の筐体で実現する場合、筐体間の通信を削減する手段を提供することを課題とする。

前記課題を解決する本発明は、文書データに対する電子署名を行う際に、その文書データをもとに算出したハッシュ値である第１の情報および前回の電子署名の結果である署名データをもとに算出したハッシュ値である第２の情報を含む情報から電子署名の署名値を算出し、前記第１の情報、前記第２の情報、前記署名値およびその署名値に関する証明書を含む情報を、新たな電子署名の結果である署名データとして第１の記憶部に追加記憶し、それによって前記署名データ間の論理的な連鎖関係を示す署名チェーン情報を生成する１以上の署名生成クライアントと、前記署名生成クライアントが生成した署名チェーン情報を入力し、その署名チェーン情報を第２の記憶部に記憶し、その記憶した署名チェーン情報が示す論理的な連鎖関係を有してつながる複数の署名データのなかから、改ざんされていないことを保証すべき署名データを公開署名データとして取得し、その取得した公開署名データからハッシュ値を算出し、前記公開署名データに固有の署名ＩＤ、および、前記ハッシュ値を算出したアルゴリズムに固有のオブジェクトＩＤを前記第２の記憶部に記憶し、前記公開署名データに固有の署名ＩＤ、前記オブジェクトＩＤおよび前記ハッシュ値を、当該署名ＩＤに対応する公開署名データが改ざんされていないことを保証する信頼ポイント情報として外部に公開する履歴管理サーバと、を含んで構成される原本保証システムにおいて、所定の署名データの原本性を保証する原本保証方法であって、前記履歴管理サーバの処理部は、前記署名チェーン情報から公開署名データを取得する場合に、最新の署名データから前回公開した公開署名データまでに対して、前後する２個の署名データのうち、新しい署名データに含まれる前記第２の情報と、古い署名データから新たに求めた第２の情報とを比較することによって、前後する署名データ間の整合性を順次検証するステップと、前記比較の結果、新しい署名データに含まれる前記第２の情報と古い署名データから新たに求めた第２の情報とが一致して整合性が継続すると判定されたときに、前記複数の署名データのなかから、前記最新の署名データを公開署名データと特定して取得するステップと、前記比較の結果、新しい署名データに含まれる前記第２の情報と古い署名データから新たに求めた第２の情報とが一致せず整合性が途切れたと判定されたときに、前記複数の署名データのなかから、その整合性が連続する２以上の署名データのうちの最新の署名データ、および、前後が途切れた１の署名データを公開署名データと特定して取得するステップと、を含んで実行することを主な特徴とする。なお、本発明は、原本保証システムを含む。

本発明によれば、ヒステリシス署名において、署名データの消失や破壊が発生しても、その署名データに連鎖する他の署名データの信頼性を確保することができる。また、署名データの生成と署名履歴の管理とを別の筐体で実現する場合、筐体間の通信を削減することができる。

以下、本発明を実施するための最良の形態について図面を参照して詳細に説明する。

≪システム（ハードウェア）の構成と概要≫
図１は、本発明の実施の形態に係る原本保証システムの構成を示す図である。図１を参照して、原本保証システム１のハードウェア構成について説明する。

原本保証システム１は、署名生成クライアント２および履歴管理サーバ３が、ネットワーク４を介して接続されて構成される。署名生成クライアント２は、文書データを入力し、記憶するとともに、その文書データに対する署名を生成し、その署名データを記憶する。ここでは、特に、１つ前の署名データを含めた署名を行うヒステリシス署名を適用する。署名生成クライアント２は、ＰＣ（Personal Computer）などによって実現される。一方、履歴管理サーバ３は、署名生成クライアント２から署名履歴を受信し、その署名履歴から信頼ポイント情報を作成し、公開する。そして、外部から署名データの検証依頼を受けて、その署名データの検証を行うことによって、その署名データに対応する文書データの原本性の検証を可能とする。履歴管理サーバ３は、サーバ用コンピュータによって実現される。ネットワーク４は、署名生成クライアント２および履歴管理サーバ３を接続するネットワークであり、例えば、社内ＬＡＮ（Local Area Network）などによって実現される。なお、署名生成クライアント２および履歴管理サーバ３の間は、必ずしもネットワーク接続に限られることはなく、例えば、ＣＤ−Ｒ（Compact Disc Recordable）などの媒体を利用して署名履歴などのデータの移行を行ってもよい。

署名生成クライアント２は、処理部２１、入力部２２、記憶部２３および通信部２４を含んで構成される。処理部２１は、入力部２２、記憶部２３および通信部２４に接続され、署名生成クライアント２全体を制御する。処理部２１は、ＣＰＵ（Central Processing Unit）が所定のメモリに格納されたプログラムを実行することによって実現される。入力部２２は、署名の対象となる文書データを入力し、その文書データを処理部２１に渡す。入力部２２は、画像データを入力するスキャナ、テキストデータを入力するキーボード、画像データを入力してテキストデータに変換するＯＣＲ（Optical Character Reader）などによって実現される。また、文書データの情報源としては、記憶媒体やインタネットなどが考えられる。記憶部２３は、署名データ、署名生成や署名検証に使用されるハッシュ化アルゴリズムなどを記憶する。記憶部２３は、フラッシュメモリやハードディスク装置などの不揮発性記憶装置によって実現される。通信部２４は、ネットワーク４に接続され、ネットワーク４を介して履歴管理サーバ３との通信を行う。通信部２４は、ネットワーク接続機器などによって実現される。

履歴管理サーバ３は、処理部３１、記憶部３２および通信部３３を含んで構成される。処理部３１は、記憶部３２および通信部３３に接続され、履歴管理サーバ３全体を制御する。処理部３１は、ＣＰＵが所定のメモリに格納されたプログラムを実行することによって実現される。記憶部３２は、署名データ、署名検証に使用されるハッシュ化アルゴリズムなどを記憶する。記憶部３２は、フラッシュメモリやハードディスク装置などの不揮発性記憶装置によって実現される。通信部３３は、ネットワーク４に接続され、ネットワーク４を介して署名生成クライアント２との通信を行う。通信部３３は、ネットワーク接続機器などによって実現される。

≪処理部（プログラム）の構成と概要≫
図２は、本発明の実施の形態に係る処理部の構成を示す図である。図２を参照して、処理部２１および処理部３１のプログラム構成について説明する。図２（ａ）に示すように、署名生成クライアント２の処理部２１のプログラムは、クライアント用アプリケーションプログラム部（以下、クライアントＡＰ部という）２１１、署名生成処理部２１２、署名検証処理部２１３および暗号化処理部２１４を含んで構成される。クライアントＡＰ部２１１は、文書データの入力、その文書に対する署名データの生成、その署名データの検証などの一連の業務処理を行うアプリケーションプログラムである。署名生成処理部２１２は、クライアントＡＰ部２１１からコールされて起動され、クライアントＡＰ部２１１から入力した文書データなどから署名データを生成し、その署名データを出力するプログラムである。署名検証処理部２１３は、クライアントＡＰ部２１１からコールされて起動され、クライアントＡＰ部２１１から入力した文書データや署名値などについて単体検証を行い、その単体検証の結果を出力するプログラムである。

暗号化処理部２１４は、署名生成処理部２１２および署名検証処理部２１３からコールされて起動され、入力した文書データや署名データをハッシュ化し、そのハッシュ値を出力するプログラムである。また、署名生成処理部２１２から入力した署名データのハッシュ値を秘密鍵によって暗号化し、その暗号化後の署名値を出力するプログラムである。なお、署名生成処理部２１２および署名検証処理部２１３は、クライアントＡＰ部２１１に対してＡＰＩ（Application Program Interface）によって提供される。また、暗号化処理部２１４は、署名生成処理部２１２および署名検証処理部２１３に対してＡＰＩによって提供される。

次に、図２（ｂ）に示すように、履歴管理サーバ３の処理部３１のプログラムは、サーバ用アプリケーションプログラム部（以下、サーバＡＰ部という）３１１、署名検証処理部３１２、暗号化処理部３１３およびＤＢ（Data Base）アクセス処理部３１４を含んで構成される。サーバＡＰ部３１１は、信頼ポイント情報の作成、記憶、公開や署名データの検証などの一連の業務処理を行うアプリケーションプログラムである。署名検証処理部３１２は、サーバＡＰ部３１１からコールされて起動され、サーバＡＰ部３１１から入力した文書データや署名データなどについて単体検証またはヒステリシス検証を行い、その検証結果を出力するプログラムである。暗号化処理部３１３は、署名検証処理部３１２からコールされて起動され、署名検証処理部３１２から入力した署名データをハッシュ化し、そのハッシュ値を出力するプログラムである。

ＤＢアクセス処理部３１４は、サーバＡＰ部３１１からコールされて起動され、記憶部３２に構築されたＤＢにアクセスして、サーバＡＰ部３１１から入力したデータを格納したり、格納されたデータをサーバＡＰ部３１１に出力したりするプログラムである。ＤＢアクセス処理部３１４は、データベースアクセス用のＡＰＩであるＯＤＢＣ（Open Data Base Connectivity）およびデータベース管理システム（ＤＢＭＳ、Data Base Management System）を介してＤＢにアクセスする。なお、署名検証処理部３１２およびＤＢアクセス処理部３１４は、サーバＡＰ部３１１に対してＡＰＩによって提供される。また、暗号化処理部３１３は、署名検証処理部３１２に対してＡＰＩによって提供される。

≪データの構成と概要≫
図３は、本発明の実施の形態に係る署名生成クライアントが生成するデータの構成を示す図である。ここで説明するデータは、署名情報５、署名データ６およびチェーン情報７であり、それぞれが記憶部２３に記憶される。署名情報５は、署名生成クライアント２の入力部２２が文書データを入力したときに、処理部２１がその文書データに対応して生成するものである。図３（ａ）に示すように、署名情報５は、署名ＩＤ５１および署名データ６を含んで構成される。署名ＩＤ５１は、署名情報５および署名データ６に固有の番号であり、さらに詳述すると、署名生成クライアント２に固有の番号および署名ごとにインクリメントされて付与される番号からなる。これは、署名ＩＤ５１が署名生成クライアント２において固有であるとともに、署名情報５を受信する履歴管理サーバ３においても固有である必要があるためである。署名データ６は、入力された文書データの原本性を将来に亘って保証するために、処理部２１が生成するものである。以上によると、署名情報５は、署名ＩＤ５１と署名データ６との対応関係を示すものであり、署名ＩＤ５１によって対応する署名データ６を特定することができる。

図３（ｂ）に示すように、署名データ６は、署名対象データ６１、署名対象外データ６２、証明書６３および署名値６４を含んで構成される。署名対象データ６１は、文字通り、署名の対象となるデータであり、そのデータ全体のハッシュ値を算出し、そのハッシュ値を秘密鍵によって暗号化したものが署名値６４となる。

署名対象データ６１は、オブジェクトＩＤ６１１、文書データのハッシュ値６１２、ヒステリシス署名のバージョン６１３、署名ＩＤ６１４、前署名ＩＤ６１５、前署名データのハッシュ値６１６および署名データの生成時刻６１７を含んで構成される。オブジェクトＩＤ６１１は、文書データのハッシュ値６１２を算出するハッシュ化アルゴリズムに固有の番号（ハッシュ化アルゴリズムの種類を示す番号）であり、ＲＦＣ（Request For Comments）に規定されている情報である。なお、ＲＦＣとは、インタネットの技術開発組織であるＩＥＴＦ（Internet Engineering Task Force）が公開している技術提案やコメントの文書のことである。文書データのハッシュ値６１２は、文書データから所定のハッシュ化アルゴリズムによって算出される。そのハッシュ化アルゴリズムは、プログラムとして記憶部２３に記憶されており、必要に応じて所定のメモリにロードされ、ＣＰＵによって実行される。

ヒステリシス署名のバージョン６１３は、署名データ６全体のデータ形式を示す。署名ＩＤ６１４は、署名ＩＤ５１と同様であるが、署名データ６の内部に記述されるデータとして、署名データ６の外部に付加される署名ＩＤ５１とは区別するために、符号を別にしている。前署名ＩＤ６１５は、署名チェーンにおいて署名データ６の１つ前（過去方向）につながっている署名データ（以下、前署名データという）の署名ＩＤである。前署名データのハッシュ値６１６は、前署名データから所定のハッシュ化アルゴリズムによって算出される。署名データの生成時刻６１７は、文字通り、署名データ６が生成された時刻を示す。なお、前署名ＩＤ６１５および前署名データのハッシュ値６１６は、記憶部２３に記憶された前署名データから求めるものとする。これらの過去の情報が署名対象データ６１に含まれるが故に、ヒステリシス署名と呼ばれるのである。

署名対象外データ６２は、文字通り、署名の対象とならないデータである。証明書６３は、暗号化に用いられた秘密鍵が署名者本人のものであり、かつ、その秘密鍵が改ざんされていないこと（換言すれば、公開鍵を用いることによって署名値６４が正しく復号できること）を証明するものである。証明書６３は、有効期限６３１および公開鍵６３２を含んで構成される。有効期限６３１は、証明書６３の有効期限であり、それが経過すると、公開鍵が秘密鍵に対応するものであることが保証されなくなる。公開鍵６３２は、署名値６４を復号して署名対象データ６１のハッシュ値にするときに使用される。署名値６４は、先に説明したように、署名対象データ６１のハッシュ値を算出し、そのハッシュ値を暗号化したものである。なお、本実施の形態では、ハッシュ化アルゴリズムは、署名生成クライアント２の暗号化処理部２１４および履歴管理サーバ３の暗号化処理部３１３がＡＰＩによって提供するものとする。

チェーン情報７は、署名生成クライアント２における署名チェーンに関する情報である。チェーン情報７は、図３（ｃ）に示すように、チェーンＩＤ７１および最新署名ＩＤ７２を含んで構成される。チェーンＩＤ７１は、署名チェーンに固有の番号であり、詳述すると、署名生成クライアント２が１つの署名チェーンを持つので、署名生成クライアント２に固有の番号となる。これは、チェーン情報７を受信する履歴管理サーバ３において固有である必要があるためである。最新署名ＩＤ７２は、署名チェーンにおける最新の署名データの署名ＩＤである。処理部２１のクライアントＡＰ部２１１は、文書データから署名データ６を生成するときに、最新署名ＩＤ７２を前署名ＩＤ６１５として用いるとともに、最新署名ＩＤ７２を１つインクリメントした値を署名ＩＤ６１４として用いる。そして、新たな署名データ６を生成した後に、最新署名ＩＤ７２自体の値を１つインクリメントする。

図４は、本発明の実施の形態に係る信頼ポイント情報の構成を示す図である。信頼ポイント情報は、履歴管理サーバ３が、署名生成クライアント２から受信した署名情報５およびチェーン情報７から公開すべき署名データ（以下、公開署名データという）を特定し、その公開署名データに関する情報をまとめたものである。信頼ポイント情報には、内部信頼ポイント情報８および公開信頼ポイント情報９の２つの形式がある。

内部信頼ポイント情報８は、記憶部３２に記憶される信頼ポイント情報の形式を示す。図４（ａ）に示すように、内部信頼ポイント情報８は、信頼ポイントＩＤ８１、公開署名ＩＤ８２、オブジェクトＩＤ８３およびハッシュ化手順８４を含んで構成される。信頼ポイントＩＤ８１は、内部信頼ポイント情報８に固有の番号である。公開署名ＩＤ８２は、公開署名データの署名ＩＤである。オブジェクトＩＤ８３は、信頼ポイント情報として公開するハッシュ値（以下、公開ハッシュ値という）を算出するハッシュ化アルゴリズムに固有の番号である。

ハッシュ化手順８４は、公開署名データから公開ハッシュ値９１（図４（ｂ）参照）を算出する手順を示すものである。例えば、公開署名データＡ、ＢおよびＣから公開ハッシュ値９１を算出する場合には、公開署名データＡ、ＢおよびＣを一体化して、その一体化したデータをハッシュ化する方法や、公開署名データＡ、ＢおよびＣをそれぞれハッシュ化し、その結果である３つのハッシュ値をまとめてさらにハッシュ化する方法などがある。また、ハッシュ化する公開署名データの順序は、必ずしもＡ、Ｂ、Ｃの順である必要はなく、異なる順序であってよい。このように、同じ公開署名データをハッシュ化するにも様々な手順が考えられるので、その手順を特定するのがハッシュ化手順８４である。ハッシュ化手順８４は、処理部３１のサーバＡＰ部３１１がヒステリシス検証を行う場合に、公開ハッシュ値９１と比較照合するために、公開署名データから改めてハッシュ値を算出するときに用いられる。なお、内部信頼ポイント情報８は、信頼ポイントを追加した日時や公開先の情報を含んでもよい。

公開信頼ポイント情報９は、新聞やインタネットなどで公開される信頼ポイント情報の形式を示す。図４（ｂ）に示すように、公開信頼ポイント情報９は、信頼ポイントＩＤ８１、公開署名ＩＤ８２、オブジェクトＩＤ８３および公開ハッシュ値９１を含んで構成される。信頼ポイントＩＤ８１、公開署名ＩＤ８２およびオブジェクトＩＤ８３は、内部信頼ポイント情報８からコピーされる情報であり、その説明は割愛する。公開ハッシュ値９１は、オブジェクトＩＤ８３に対応するハッシュ化アルゴリズムが、公開署名ＩＤ８２によって特定される１以上の署名データから内部信頼ポイント情報８のハッシュ化手順８４に従って算出したハッシュ値である。なお、本実施の形態では、ハッシュ化アルゴリズムは、履歴管理サーバ３の暗号化処理部３１３がＡＰＩによって提供するものとする。

≪システムの処理≫
続いて、図５ないし図８を参照して、本発明の実施の形態に係る原本保証システムの処理について説明する。原本保証システム１では、署名生成クライアント２において、文書データを入力、記憶した場合に、その文書データに対して署名データを生成し、登録する。そして、署名データ単体の有効期限が経過する前に、署名データの履歴を署名生成クライアント２から履歴管理サーバ３に送信する。履歴管理サーバ３において、受信した署名データの履歴から信頼ポイント情報を生成し、公開する。この場合、署名データの履歴（署名チェーン）が虫食いや矛盾により途切れていても、エラーになっていない署名データの原本性を保証することができるように信頼ポイント情報を生成する。その後、外部から履歴管理サーバ３に署名データの検証依頼が行われ、履歴管理サーバ３は、その署名データの原本性を検証し、その検証結果を外部に送信する。

まず、図５を参照して、署名生成クライアント２におけるヒステリシス署名生成処理について説明する（適宜図１、図２、図３および図９参照）。この処理は、署名生成クライアント２においてテキストデータや画像データが文書データとして入力された場合に行われる。なお、図５はヒステリシス署名生成処理を示すＰＡＤ（Problem Analysis Diagram）であり、図９はヒステリシス署名生成処理におけるデータの流れを示すデータフロー図である。

最初に、処理部２１のクライアントＡＰ部２１１は、入力部２２から文書データ９２（図９参照）を入力し、その文書データ９２を記憶部２３に記憶する（ステップＳ５０１）。次に、クライアントＡＰ部２１１は、前署名データ９５が取得可能であるか否かをチェックする（ステップＳ５０２）。具体的には、記憶部２３に記憶されているチェーン情報７から最新署名ＩＤ７２を読み出し、その最新署名ＩＤ７２を署名ＩＤ５１とする署名データ６をさらに記憶部２３の署名情報５から読み出す。そのとき、その署名データ６の読み出しができるか否かを確認する。

前署名データ９５が取得可能であれば（ステップＳ５０２のＹｅｓ）、クライアントＡＰ部２１１は、署名検証処理部２１３をコールすることによって前署名データ９５の単体検証を行う（ステップＳ５０３）。ここで、図３（ｂ）を参照しつつ、署名検証処理部２１３による単体検証の具体的な内容について説明する。最初に、証明書６３の検証を行う。有効期限６３１が経過していないか否かを確認し、証明書失効リストを確認し、さらに証明書の改ざん有無を確認する。この証明書６３の検証は、ネットワーク４に接続された外部の認証局に依頼してもよい。次に、文書データのハッシュ値を検証する。署名対象外データ６２に記載されているオブジェクトＩＤに対応するハッシュ化アルゴリズムを持つ暗号化処理部２１４によって、文書データからハッシュ値を算出する。そして、その文書データのハッシュ値と、署名対象データ６１の文書データのハッシュ値６１２とを比較照合する。なお、文書データは、ステップＳ５０１で入力したものである。さらに、署名値６４の検証を行う。暗号化処理部２１４によって、署名対象データ６１から第１のハッシュ値を算出する。一方、公開鍵６３２を用いて、署名値６４から第２のハッシュ値に復号する。そして、第１のハッシュ値と第２のハッシュ値とを比較照合する。

前署名データの単体検証がＯＫであれば（ステップＳ５０３のＹｅｓ）、まず、最新署名ＩＤ７２の値を前署名ＩＤ９７とし、前署名ＩＤ９７をインクリメントする（ステップＳ５０５）。そのインクリメントした後の値が、署名ＩＤとして署名生成処理部２１２に入力される。次に、前署名データのハッシュ値９６を取得する（ステップＳ５０６）。具体的には、暗号化処理部２１４によって、前署名データ９５から前署名データのハッシュ値９６を算出する。そして、署名データ６を生成する（ステップＳ５０７）。具体的には、クライアントＡＰ部２１１が署名生成処理部２１２をコールすることによって、署名生成処理部２１２が行う。図９に示すように、署名生成処理部２１２に入力される情報には、文書データ９２、署名対象情報９３、署名対象外情報９４、前署名データのハッシュ値９６および前署名ＩＤ９７がある。

暗号化処理部２１４のハッシュ化アルゴリズムのオブジェクトＩＤが署名データ６のオブジェクトＩＤ６１１に設定される。また、暗号化処理部２１４によって文書データ９２から算出されたハッシュ値が文書データのハッシュ値６１２に設定される。署名対象情報９３には、ヒステリシス署名のバージョン、署名ＩＤおよび現在の時刻情報がある。現在の時刻情報は、署名生成クライアント２の内部時計による。これらの情報は、それぞれヒステリシス署名のバージョン６１３、署名ＩＤ６１４および署名データの生成時刻６１７に設定される。署名対象外情報９４には、署名の対象とならないデータおよび証明書がある。これらの情報は、それぞれ署名対象外データ６２および証明書６３に設定される。前署名データのハッシュ値９６は、そのまま前署名データのハッシュ値６１６に設定される。前署名ＩＤ９７は、そのまま前署名ＩＤ６１５に設定される。

さらに、署名生成処理部２１２は、暗号化処理部２１４によって署名対象データ６１全体からハッシュ値を算出し、そのハッシュ値を入力情報としてさらに暗号化処理部２１４をコールする。暗号化処理部２１４は、そのハッシュ値を秘密鍵によって暗号化し、その値を署名生成処理部２１２に出力する。署名生成処理部２１２は、暗号化処理部２１４から受けた値を署名データ６の署名値６４に設定する。

ステップＳ５０２で前署名データが取得できなかった場合（ステップＳ５０２のＮｏ）、新規の署名データを生成する（ステップＳ５０４）。また、ステップＳ５０３で前署名データの単体検証がＯＫでなかった場合（ステップＳ５０３のＮｏ）、新規の署名データを生成する（ステップＳ５０８）。ステップＳ５０４およびステップＳ５０８で行われる新規の署名データの生成は、過去の署名データを使わないものであり、ステップＳ５０７に示した処理から前署名データのハッシュ値９６および前署名ＩＤ９７の入力を除いた処理となる。この場合、最新署名ＩＤ７２の値をインクリメントした値を署名対象情報９３の署名ＩＤとして、署名生成処理部２１２の入力情報に設定する。そして、生成した署名データ６を登録する（ステップＳ５０９）。具体的には、署名ＩＤ５１および署名データ６を新たな署名情報５として記憶部２３に記憶する。そして、チェーン情報７の最新署名ＩＤ７２をインクリメントする。これによって、署名生成クライアント２において署名履歴が１つ追加されたことになる。

次に、図６および図７を参照して、履歴管理サーバ３における信頼ポイント追加処理について説明する（適宜図１、図２、図３、図４および図１０参照）。この処理は、署名データ６の証明書が失効する前にその署名データ６の原本性を保証するために、その署名データ６を含む署名履歴が各署名生成クライアント２から履歴管理サーバ３に送信された場合に行われる。換言すれば、署名データの生成と署名履歴の管理とを別の筐体で実現する場合に、署名データ６を生成するたびに情報の送受信を行う必要がないので、筐体間の通信を削減することができる。

署名生成クライアント２から履歴管理サーバ３に送信される署名履歴には、署名情報５およびチェーン情報７がある。履歴管理サーバ３において、処理部３１のサーバＡＰ部３１１は、通信部３３経由でそれらの情報を受信し、その受信した情報をＤＢアクセス処理部３１４経由で記憶部３２のＤＢに格納する。なお、図６は信頼ポイント追加処理を示すＰＡＤであり、図７はチェーン検証処理を示すＰＡＤであり、図１０は信頼ポイント追加処理において公開署名ＩＤを特定する処理を説明する図である。

図６に示すように、まず、処理部３１のサーバＡＰ部３１１は、信頼ポイントＩＤを採番する（ステップＳ６０１）。具体的には、記憶部３２に記憶されている最新の内部信頼ポイント情報８から信頼ポイントＩＤ８１を読み出し、その信頼ポイントＩＤ８１の値をインクリメントしたものを新たな信頼ポイントＩＤとする。次に、サーバＡＰ部３１１は、記憶部３２のＤＢに格納された情報を読み出し、その情報から形成される各チェーン（署名チェーン）の先頭から、以前に作成した公開署名データまでのチェーン検証を行う（ステップＳ６０２）。具体的には、各チェーンについて、Ｎをチェーンの先頭に位置する署名データの署名ＩＤとし、Ｍをそのチェーンにおいて以前に作成した公開署名データの署名ＩＤとする入力情報により、図７に示すチェーン検証処理をコールする。ここで、先頭に位置する署名データの署名ＩＤ：Ｎは、チェーン情報７の最新署名ＩＤ７２とする。以前に作成した公開署名データの署名ＩＤ：Ｍは、最新の内部信頼ポイント情報８から読み出した１以上の公開署名ＩＤ８２を最新署名ＩＤ７２と比較した場合に、署名ＩＤに含まれる署名生成クライアント２に固有の番号（チェーンＩＤ７１に対応する値）が一致した公開署名ＩＤ８２とする。これは、同じ署名チェーンに属する公開署名ＩＤ８２を特定するためである。

ここで、図７を参照して、チェーン検証処理について説明する。チェーン検証処理は、Ｎを始点となる署名ＩＤとし、Ｍを終点となる署名ＩＤとして、前後の署名ＩＤに対応する署名データのハッシュ値同士を比較することによって、前後する署名データ間の整合性を順次検証する処理である。図７に示すように、最初に、Ｎを署名ＩＤとする署名データ６を取得する（ステップＳ７０１）。具体的には、サーバＡＰ部３１１が、ＤＢアクセス処理部３１４をコールして所望の署名ＩＤを持つ署名データ６を入力する（以下同様）。そして、変数ｉをＮからＭ＋１まで１ずつ減算（デクリメント）しながら、各変数ｉについてステップＳ７０２ないしステップＳ７０６の一連の処理を行うように制御する（ステップＳ７０２）。

一連の処理では、まず、ｉ−１を署名ＩＤとする署名データ６を取得する（ステップＳ７０３）。次に、ｉを署名ＩＤとする署名データ６に含まれる前署名データのハッシュ値６１６と、ｉ−１を署名ＩＤとする署名データ６から算出したハッシュ値とを比較する（ステップＳ７０４）。２つのハッシュ値が一致すれば（ステップＳ７０５のＹｅｓ）、ｉおよびｉ−１を署名ＩＤとする署名データの組合せに対して「正常」を設定する（ステップＳ７０６）。一致しなければ（ステップＳ７０５のＮｏ）、その署名データの組合せに対して「エラー」を設定する（ステップＳ７０７）。なお、ステップＳ７０１およびステップＳ７０３において、所望の署名データ６が取得できなかった場合には、署名データの組合せに対して「エラー」を設定することになる。

図６に戻って、チェーン検証処理の結果から、各チェーンの末端署名ＩＤおよび虫食いチェーンの末端署名ＩＤを取得する（ステップＳ６０３）。チェーンの末端署名ＩＤは、原則的には先頭に位置する署名データの署名ＩＤであるが、それが読み出せなければ、先頭に最も近い、読み出し可能な署名データの署名ＩＤということになる。虫食いチェーンの末端署名ＩＤは、途中の署名データが読み出せなかったり、署名データ間に矛盾があったりした場合に、読み出しエラーや矛盾の原因となった署名データを除外することによってチェーンが不連続になるが、そのときに残ったチェーンの末端に位置する（最新の）署名データの署名ＩＤである。これらの末端署名ＩＤが、公開署名ＩＤ８２となる。そして、それらをまとめて信頼ポイントという。

具体的には、まず、先頭に最も近い、読み出し可能な署名データの署名ＩＤをチェーンの末端署名ＩＤとする。そして、過去に遡りながら、読み出し可能な署名データの中でも、連続するチェーンを形成する署名データのうち、最新の署名データの署名ＩＤを虫食いチェーンの末端署名ＩＤとする。ここで、連続するチェーンを形成するとは、前後の署名データのハッシュ値の比較結果が「正常」であると設定された組合せが連続することによって、チェーンが途切れないことをいう。なお、２以上の署名データが連続するチェーンではなく、前後が途切れた１つの署名データであっても、末端署名データとなりうる。

図１０は、署名チェーンに対して末端署名データを取得する処理を説明する図である。図１０（ａ）、（ｂ）ともに、チェーンごとに、Ｐ０を署名ＩＤとする署名データなど（以下、署名データＰ０などという）がつながっている様子を示している。そして、署名データＰ０、Ｑ０、Ｒ０が前回の公開署名データであり、それらがまとまって前回の信頼ポイントとなっている。図１０（ａ）に示すように署名チェーンが正常であれば、正に各チェーンの末端に位置する署名データＰ４、Ｑ３およびＲ２が末端署名データ、すなわち、公開署名データとなり、それらがまとまって信頼ポイントとなる。ここで、「署名チェーンが正常」とは、例えば、チェーン検証の結果、署名データＰ４とＰ３、Ｐ３とＰ２、Ｐ２とＰ１、Ｐ１とＰ０の組合せがそれぞれ「正常」であること（整合性がとれていること）をいう。この場合、署名データＰ４ないしＰ０が正常にチェーンされていることから、署名データＰ４を公開することによって、署名データＰ４ないしＰ０の原本性が保証されることになる。

これに対して、図１０（ｂ）に示すように署名チェーンが正常でない場合がある。図１０（ｂ）のチェーンＰは正常であるが、チェーンＱには虫食いが発生し、チェーンＲには矛盾が発生している。チェーンＱにおいては、署名データＱ３およびＱ５が読み出せない状態（虫食い）になっている。署名データＱ２、Ｑ１、Ｑ０のチェーンは正常である。そこで、その読み出せない署名データ以外の署名データの原本性を保証するために、末端の署名データＱ６、Ｑ４およびＱ２を公開署名データとする。

チェーンＲにおいては、読み出せない署名データはないが、署名データＲ４とＲ３との間でチェーン検証が「エラー」（矛盾）になっている。署名データＲ５、Ｒ４のチェーンは正常である。また、署名データＲ３、Ｒ２、Ｒ１、Ｒ０のチェーンも正常である。そこで、署名データＲ５ないしＲ１の原本性を保証するために、末端の署名データＲ５およびＲ３を公開署名データとする。そして、署名データＰ６、Ｑ６、Ｑ４およびＱ２、ならびに、Ｒ５およびＲ３をまとめて信頼ポイントとする。

図６に戻って、サーバＡＰ部３１１は、ステップＳ６０３で取得した末端署名ＩＤから内部信頼ポイント情報８を作成し、記憶部３２に記憶する（ステップＳ６０４）。さらに、その記憶した内部信頼ポイント情報８から公開信頼ポイント情報９を作成し、公開する（ステップＳ６０５）。ここで、公開とは、最終的には新聞などのメディアに公開されることが必要であるが、履歴管理サーバ３の処理としては、新聞社などのサーバに公開信頼ポイント情報９を送信することをいう。以上によれば、署名データの消失や破壊が発生しても、その署名データに連鎖する他の署名データの信頼性を確保することができる。

続いて、図８を参照して、履歴管理サーバ３における信頼ポイントを使用したヒステリシス検証処理について説明する（適宜図１、図２、図３および図４参照）。この処理は、外部から署名データの原本性を検証依頼するために、信頼ポイントＩＤ、公開ハッシュ値および署名データが履歴管理サーバ３に送信された場合に行われる。

最初に、処理部３１のサーバＡＰ部３１１は、外部から、例えば、ネットワーク４および通信部３３を介して署名データの検証依頼を受信する（ステップＳ８０１）。そして、受信した信頼ポイントＩＤ、公開ハッシュ値および署名データを入力情報として、署名検証処理部３１２をコールする。ステップＳ８０２ないしステップＳ８０９の処理は、署名検証処理部３１２によって行われる。

まず、署名検証処理部３１２は、入力された信頼ポイントＩＤから内部信頼ポイント情報を取得する（ステップＳ８０２）。具体的には、記憶部３２に記憶された内部信頼ポイント情報８のうち、入力された信頼ポイントＩＤが信頼ポイントＩＤ８１と一致する内部信頼ポイント情報８を取得する。次に、入力された署名データから署名ＩＤ：Ｍを抽出する（ステップＳ８０３）。これは、図３（ｂ）に示す署名データ６の構成に従って署名ＩＤ６１４を抽出し、その署名ＩＤ６１４の値をＭとするものである。そして、入力された署名データと、記憶部３２に記憶された署名情報５のうち、署名ＩＤ：Ｍの署名データとが一致するか否かをチェックする（ステップＳ８０４）。署名データ同士が一致した場合には（ステップＳ８０４のＹｅｓ）、署名ＩＤ：Ｍの署名データと同じチェーンに属する公開署名ＩＤ：Ｎを取得する（ステップＳ８０５）。具体的には、ステップＳ８０２で取得した内部信頼ポイント情報８に含まれる公開署名ＩＤ８２と署名ＩＤ：Ｍとを比較照合して、署名ＩＤの値のうち署名生成クライアント２に固有の番号（チェーンＩＤ７１に対応する値）が一致したとき、その公開署名ＩＤ８２を公開署名ＩＤ：Ｎとして特定する。

ここで、署名ＩＤ：Ｍの署名データと同じチェーンに属し、未来方向の最も近くにある公開署名ＩＤ：Ｎを取得するようにしてもよい。例えば、あらかじめ内部信頼ポイント情報８に対して信頼ポイントを追加した日時を追加しておくことにより、その日時に基づいて、署名ＩＤ：Ｍの署名データ６に含まれる署名データの生成時刻６１７に未来方向に最も近い内部信頼ポイント情報８を特定し、その内部信頼ポイント情報８から署名ＩＤ：Ｍの署名データと同じチェーンに属する公開署名ＩＤを取得する。これによれば、チェーン検証の対象となる署名データの個数が少なくなるので、チェーン検証処理にかかる時間を短縮できる。また、署名データの虫食いや署名データ間の矛盾が発生する可能性が少なくなるので、ステップＳ８０７で行うチェーン検証の結果が正常になる可能性が高くなる。

続いて、署名検証処理部３１２は、入力された公開ハッシュ値と、信頼ポイントＩＤの署名データから算出したハッシュ値とが一致するか否かをチェックする（ステップＳ８０６）。この場合、ステップＳ８０２で取得した内部信頼ポイント情報８から１以上の公開署名ＩＤ８２を特定し、その特定した公開署名ＩＤ８２に対応する署名データ６からハッシュ値を算出する。そのハッシュ値の算出は、オブジェクトＩＤ８３に対応するハッシュ化アルゴリズムを持つ暗号化処理部３１３を用いて、ハッシュ化手順８４に従って行う。ハッシュ値同士が一致した場合には（ステップＳ８０６のＹｅｓ）、署名ＩＤ：Ｎを始点とし、署名ＩＤ：Ｍを終点とする入力情報を設定して、図７に示すチェーン検証処理をコールする（ステップＳ８０７）。チェーン検証処理については、既に説明したとおりである。

これによって、署名検証処理部３１２は、署名ＩＤ：ＮないしＭのチェーンが正常であるか、または、虫食いや矛盾を含むエラーであるかの検証結果を取得することができる。なお、ステップＳ８０４のチェックで署名データ同士が一致しなかった場合には（ステップＳ８０４のＮｏ）、エラー処理として「署名データ不一致」を検証結果とする（ステップＳ８０９）。また、ステップＳ８０６のチェックでハッシュ値同士が一致しなかった場合には（ステップＳ８０６のＮｏ）、エラー処理として「ハッシュ値不一致」を検証結果とする（ステップＳ８０８）。署名検証処理部３１２は、それらの検証結果を出力情報としてサーバＡＰ部３１１にリターンする。そして、サーバＡＰ部３１１は、それらの検証結果を受け取り、外部の検証依頼元に送信する（ステップＳ８１０）。

以上によれば、外部の検証依頼元は、履歴管理サーバ３から受信した検証結果が正常であれば、送信した署名データ６の原本性が保証されたことになり、さらに、その署名データ６内の文書データのハッシュ値６１２と、実際に文書データから算出したハッシュ値とを比較することによって、文書データの原本性を検証することができる。なお、外部の検証依頼元が文書データを履歴管理サーバ３に送信することにより、履歴管理サーバ３が文書データのハッシュ値を比較検証するようにしてもよい。

以上本発明の実施の形態について説明したが、図１に示す署名生成クライアント２および履歴管理サーバ３のそれぞれで実行されるプログラムをコンピュータによる読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、本発明の実施の形態に係る原本保証システムが実現されるものとする。なお、プログラムをインタネットなどのネットワーク経由でコンピュータシステムに提供するようにしてもよい。

以上本発明について好適な実施の形態について一例を示したが、本発明は前記実施の形態に限定されず、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。

本発明の実施の形態に係る原本保証システムの構成を示す図である。 本発明の実施の形態に係る処理部の構成を示す図であり、（ａ）は署名生成クライアントの処理部の構成を示し、（ｂ）は履歴管理サーバの処理部の構成を示す。 本発明の実施の形態に係る署名生成クライアントが生成するデータの構成を示す図であり、（ａ）は署名情報の構成を示し、（ｂ）は署名データの構成を示し、（ｃ）はチェーン情報の構成を示す。 本発明の実施の形態に係る信頼ポイント情報の構成を示す図であり、（ａ）は内部信頼ポイント情報を示し、（ｂ）は公開信頼ポイント情報を示す。 本発明の実施の形態に係るヒステリシス署名生成処理を示すＰＡＤである。 本発明の実施の形態に係る信頼ポイント追加処理を示すＰＡＤである。 本発明の実施の形態に係るチェーン検証処理を示すＰＡＤである。 本発明の実施の形態に係るヒステリシス検証処理を示すＰＡＤである。 本発明の実施の形態に係るヒステリシス署名生成処理におけるデータの流れを示すデータフロー図である。 本発明の実施の形態に係る信頼ポイント追加処理において公開署名ＩＤを特定する処理を説明する図である。

符号の説明

１ 原本保証システム
２ 署名生成クライアント
２３ 記憶部（第１の記憶部）
３ 履歴管理サーバ
３１ 処理部
３２ 記憶部（第２の記憶部）
４ ネットワーク
５ 署名情報（署名チェーン情報）
５１ 署名ＩＤ
６ 署名データ
６１２ 文書データのハッシュ値（第１の情報）
６１６ 前署名データのハッシュ値（第２の情報）
６４ 署名値
７ チェーン情報（署名チェーン情報）
８ 内部信頼ポイント情報（信頼ポイント情報）
８３ 公開署名ＩＤ（公開署名データに固有の署名ＩＤ）
８４ オブジェクトＩＤ
９ 公開信頼ポイント情報（信頼ポイント情報）
９１ 公開ハッシュ値（ハッシュ値）
９２ 文書データ

Claims (4)

1. 文書データに対する電子署名を行う際に、その文書データをもとに算出したハッシュ値である第１の情報および前回の電子署名の結果である署名データをもとに算出したハッシュ値である第２の情報を含む情報から電子署名の署名値を算出し、前記第１の情報、前記第２の情報、前記署名値およびその署名値に関する証明書を含む情報を、新たな電子署名の結果である署名データとして第１の記憶部に追加記憶し、それによって前記署名データ間の論理的な連鎖関係を示す署名チェーン情報を生成する１以上の署名生成クライアントと、
   前記署名生成クライアントが生成した署名チェーン情報を入力し、その署名チェーン情報を第２の記憶部に記憶し、その記憶した署名チェーン情報が示す論理的な連鎖関係を有してつながる複数の署名データのなかから、改ざんされていないことを保証すべき署名データを公開署名データとして取得し、その取得した公開署名データからハッシュ値を算出し、前記公開署名データに固有の署名ＩＤ、および、前記ハッシュ値を算出したアルゴリズムに固有のオブジェクトＩＤを前記第２の記憶部に記憶し、前記公開署名データに固有の署名ＩＤ、前記オブジェクトＩＤおよび前記ハッシュ値を、当該署名ＩＤに対応する公開署名データが改ざんされていないことを保証する信頼ポイント情報として外部に公開する履歴管理サーバと、
   を含んで構成される原本保証システムにおいて、所定の署名データの原本性を保証する原本保証方法であって、
   前記履歴管理サーバの処理部は、
   前記署名チェーン情報から公開署名データを取得する場合に、
   最新の署名データから前回公開した公開署名データまでに対して、前後する２個の署名データのうち、新しい署名データに含まれる前記第２の情報と、古い署名データから新たに求めた第２の情報とを比較することによって、前後する署名データ間の整合性を順次検証するステップと、
   前記比較の結果、新しい署名データに含まれる前記第２の情報と古い署名データから新たに求めた第２の情報とが一致して整合性が継続すると判定されたときに、前記複数の署名データのなかから、前記最新の署名データを公開署名データと特定して取得するステップと、
   前記比較の結果、新しい署名データに含まれる前記第２の情報と古い署名データから新たに求めた第２の情報とが一致せず整合性が途切れたと判定されたときに、前記複数の署名データのなかから、その整合性が連続する２以上の署名データのうちの最新の署名データ、および、前後が途切れた１の署名データを公開署名データと特定して取得するステップと、
   を含んで実行することを特徴とする原本保証方法。
2. 前記履歴管理サーバの処理部は、
   所定の署名データの原本性を検証する場合に、
   前記所定の署名データと論理的な連鎖関係を有してつながることにより同じ署名チェーン情報に属し、前記所定の署名データの作成時より後に追加した前記信頼ポイント情報のうち、最も古い信頼ポイント情報を特定し、当該信頼ポイント情報の署名ＩＤに対応する公開署名データから前記所定の署名データまでに対して、前後する署名データ間の整合性を順次検証するステップと、
   前記整合性が継続したときに、検証結果を正常とするステップと、
   前記整合性が途切れたときに、検証結果をエラーとするステップと、
   をさらに含んで実行することを特徴とする請求項１に記載の原本保証方法。
3. 文書データに対する電子署名を行う際に、その文書データをもとに算出したハッシュ値である第１の情報および前回の電子署名の結果である署名データをもとに算出したハッシュ値である第２の情報を含む情報から電子署名の署名値を算出し、前記第１の情報、前記第２の情報、前記署名値およびその署名値に関する証明書を含む情報を、新たな電子署名の結果である署名データとして第１の記憶部に追加記憶し、それによって前記署名データ間の論理的な連鎖関係を示す署名チェーン情報を生成する１以上の署名生成クライアントと、
   前記署名生成クライアントが生成した署名チェーン情報を入力し、その署名チェーン情報を第２の記憶部に記憶し、その記憶した署名チェーン情報が示す論理的な連鎖関係を有してつながる複数の署名データのなかから、改ざんされていないことを保証すべき署名データを公開署名データとして取得し、その取得した公開署名データからハッシュ値を算出し、前記公開署名データに固有の署名ＩＤ、および、前記ハッシュ値を算出したアルゴリズムに固有のオブジェクトＩＤを前記第２の記憶部に記憶し、前記公開署名データに固有の署名ＩＤ、前記オブジェクトＩＤおよび前記ハッシュ値を、当該署名ＩＤに対応する公開署名データが改ざんされていないことを保証する信頼ポイント情報として外部に公開する履歴管理サーバと、
   を含んで構成される原本保証システムであって、
   前記履歴管理サーバの処理部は、
   前記署名チェーン情報から公開署名データを取得する場合に、
   最新の署名データから前回公開した公開署名データまでに対して、前後する２個の署名データのうち、新しい署名データに含まれる前記第２の情報と、古い署名データから新たに求めた第２の情報とを比較することによって、前後する署名データ間の整合性を順次検証し、
   前記比較の結果、新しい署名データに含まれる前記第２の情報と古い署名データから新たに求めた第２の情報とが一致して整合性が継続すると判定されたときに、前記複数の署名データのなかから、前記最新の署名データを公開署名データと特定して取得し、
   前記比較の結果、新しい署名データに含まれる前記第２の情報と古い署名データから新たに求めた第２の情報とが一致せず整合性が途切れたと判定されたときに、前記複数の署名データのなかから、その整合性が連続する２以上の署名データのうちの最新の署名データ、および、前後が途切れた１の署名データを公開署名データと特定して取得する
   ことを特徴とする原本保証システム。
4. 前記履歴管理サーバの処理部は、
   所定の署名データの原本性を検証する場合に、
   前記所定の署名データと論理的な連鎖関係を有してつながることにより同じ署名チェーン情報に属し、前記所定の署名データの作成時より後に追加した前記信頼ポイント情報のうち、最も古い信頼ポイント情報を特定し、当該信頼ポイント情報の署名ＩＤに対応する公開署名データから前記所定の署名データまでに対して、前後する署名データ間の整合性を順次検証し、
   前記整合性が継続したときに、検証結果を正常とし、
   前記整合性が途切れたときに、検証結果をエラーとする
   ことを特徴とする請求項３に記載の原本保証システム。

Images