JP5544175B2 - 原本性保証方法、管理サーバ、プログラムおよび記憶媒体 - 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）であり、図１６はヒステリシス署名生成処理におけるデータの流れを示すデータフロー図である。

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

前署名データ９５が取得可能であれば（ステップＳ６０２のＹｅｓ）、クライアントＡＰ部２１１は、署名検証処理部２１３をコールすることによって前署名データ９５の単体検証を行う（ステップＳ６０３）。ここで、図７を参照しつつ、署名検証処理部２１３による単体検証の具体的な内容について説明する。最初に、署名検証処理部２１３は、証明書６３の検証を行う。

証明書６３の検証とは、まず証明書６３に記載されている有効期限６３１と現在時刻を比較し、有効期限６３１が経過していないか否かを確認する処理でる。次に、署名検証処理部２１３は、認証局が公開している証明書失効リストを確認する。証明書失効リストとは、認証局が明示的に失効を示した証明書６３の一覧であり、秘密鍵の漏洩など何らかの理由により強制的に失効された証明書６３の一覧である。証明書失効リストは、一般にインターネットなどで認証局が公開している。署名検証処理部２１３は、さらに証明書６３の改ざん有無を確認する。証明書６３には認証局が付与した電子署名が搭載されているため、署名検証処理部２１３は、この電子署名の検証を行い、証明書６３の改ざん有無を確認する。この証明書６３の検証は、ネットワーク４に接続された外部の認証局に依頼してもよい。

次に、署名検証処理部２１３は、文書データのハッシュ値を検証する。署名対象外データ６２に記載されているオブジェクトＩＤに対応するハッシュ化アルゴリズムを持つ暗号化処理部２１４によって、文書データからハッシュ値を算出する。そして、その文書データのハッシュ値と、署名対象データ６１の文書データのハッシュ値６１２とを比較照合する。なお、文書データは、ステップＳ６０１で入力したものである。さらに、署名値６４の検証を行う。暗号化処理部２１４によって、署名対象データ６１から第１のハッシュ値を算出する。一方、公開鍵６３２を用いて、署名値６４から第２のハッシュ値に復号する。そして、第１のハッシュ値と第２のハッシュ値とを比較照合する。

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

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

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

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

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

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

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

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

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

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

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

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

図１１に戻って、サーバＡＰ部３１１は、ステップＳ７０３で取得した末端署名ＩＤから信頼ポイント情報８を作成し、記憶部３２に記憶する（ステップＳ７０４）。

最後に、公開ハッシュ値Ｈ１に対し、公開鍵証明書が有効期限内である秘密鍵にて電子署名Ｓ１を生成し、記憶部３２に記憶する（ステップＳ７０５）。以上が１回目の信頼ポイント作成処理である。

次に、ｎ回目（ｎ≧２）の信頼ポイント作成処理を図１２に示す。

まず、処理部３１のサーバＡＰ部３１１は、記憶部３３に格納された信頼ポイント情報を全て読み出し、公開ハッシュ値Ｈ_１、Ｈ_２、・・・、Ｈ_ｎ−１を計算する。具体的には、ｉ回目における信頼ポイント情報から、ｉ回目における公開署名ＩＤを全て読み出し、ｉ回目における公開署名をすべて記憶部３３から取得し、ｉ回目におけるオブジェクトＩＤおよびハッシュ化手順を用いて公開ハッシュ値Ｈ_ｉを算出する。このように１回目からｎ−１回目までの信頼ポイント情報から、Ｈ_１、Ｈ_２、・・・、Ｈ_ｎ−１までの各公開ハッシュ値を再度算出する。さらに１回目かｉ回目までの公開ハッシュ値の統合値Ｈ_１+Ｈ_２+・・・+Ｈ_ｎ−１を算出する（ステップＳ７１１）。Ｋ_ｎ−１に対し、ｎ−１回目の信頼ポイント作成処理で生成した署名Ｓ_ｎ−１にて署名検証を実施する（ステップＳ７１２）。

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

最後に、結合公開ハッシュ値Ｋ_ｎを生成し、Ｋ_ｎに対し、公開鍵証明書が有効期限内である秘密鍵にて電子署名Ｓ_ｎを生成し、記憶部３２に記憶する（ステップＳ７１８）。以上がｎ回目の信頼ポイント作成処理である。

なお、以上にて延べたとおり、ｎ回目の信頼ポイント作成処理を実施する場合、Ｓ_ｎ−１の署名検証に成功する必要があるため、Ｓ_ｎ−１を生成するときに用いた秘密鍵に対する公開鍵証明書が有効期限内で、ｎ回目の信頼ポイント作成処理を実施しなければならない点に留意する必要がある。

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

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

まず、署名検証処理部３１２は、記憶部３２のＤＢに格納された情報を読み出し、今までに生成された全ての信頼ポイント情報から公開ハッシュ値Ｈ_１，Ｈ_２，…，Ｈ_Ｎ（最後に実施した信頼ポイント作成処理がＮ回目とする）を算出する。次に結合公開ハッシュ値Ｋ_Ｎ＝Ｈ_１＋Ｈ_２＋…＋Ｈ_Ｎを求める（ステップＳ９０１）。結合公開ハッシュ値Ｋ_Ｎと署名Ｓ_Ｎを署名検証する（ステップＳ９０２）。結合公開ハッシュ値Ｋ_Ｎと署名Ｓ_Ｎの署名検証に成功した場合（ステップＳ９０３のＹｅｓ）、すべての公開署名データが改ざんされていないことが保証される。なぜならば、先に述べたとおり、Ｓ_ｉ生成時には必ずＫ_ｉ−１とＳ_ｉ−１の署名検証を実施しており、署名検証に成功したときのみＳ_ｉを生成しているからである。

次に、署名検証処理部３１２は、入力された署名データから署名ＩＤ：Ｍを抽出する（ステップＳ９０４）。これは、図７に示す署名データ６の構成に従って署名ＩＤ６１４を抽出し、その署名ＩＤ６１４の値をＭとするものである。そして、入力された署名データと、記憶部３２に記憶された署名情報５のうち、署名ＩＤ：Ｍの署名データとが一致するか否かをチェックする（ステップＳ９０５）。署名データ同士が一致した場合には（ステップＳ９０５のＹｅｓ）、署名ＩＤ：Ｍの署名データと同じチェーンに属し、未来方向の最も近くにある公開署名ＩＤ：Ｌを取得する（ステップＳ９０６）。

最後に、署名ＩＤ：Ｌを始点とし、署名ＩＤ：Ｍを終点とする入力情報を設定して、図１３に示すチェーン検証処理をコールする（ステップＳ９０７）。チェーン検証処理については、既に説明したとおりである。署名検証処理部３１２は、それらの検証結果を出力情報としてサーバＡＰ部３１１にリターンする。そして、サーバＡＰ部３１１は、それらの検証結果を受け取り、外部の検証依頼元に送信する。

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

以上本発明の実施の形態について、本発明の要点を図１および図２の例で示す。図１は２回目の信頼ポイント作成時の処理の概要図である。具体的にはＰ，Ｑ，Ｒの署名チェーンが存在する場合を示しており、信頼ポイント作成時には前回の信頼ポイント作成後に初めて生成された署名SigP−5、SigQ−4、SigR−3から未来方向にチェーン検証を実施し、最新の署名SigP−8、SigQ−6、SigR−4を公開署名とし、これらの公開署名から公開ハッシュ値H₂を生成する。次に、前回信頼ポイント作成時の公開ハッシュ値H₁と、H₁に対する電子署名S₁を署名検証する。検証に成功した場合のみ、結合公開ハッシュ値H₁+H₂を求め、これに対する電子署名S₂を生成し格納する。図２は最新の信頼ポイントが２回目の場合でSigP−1に対応する文書の署名検証時の概要図である。まずSigP−1から公開署名SigP−4までのチェーン検証を実施する。次に、公開署名から公開ハッシュ値H₁およびH₂を求め、結合公開ハッシュ値H₁+H₂を求め、これに対する電子署名S₂を署名検証する。これらの検証にすべて成功した場合、SigP−1およびS₁の有効期限が切れた後でも、改ざんされていないことが証明できる。ただし、検証した時点で電子署名S₂の有効期限が切れていない必要があることに留意する必要がある。

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

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

２・・・署名生成クライアント、３・・・履歴管理サーバ、４・・・ネットワーク、２１、３１・・・処理部、２２・・・入力部、２３、３２・・・記憶部、２１、３１・・・処理部、２４、３３・・・通信部。

Claims (12)

1. 管理サーバにより、文書データに対して電子署名を行った結果である署名データの原本性を保証する原本性保証方法であって、
   外部から所定の署名データの検証要求を受信する処理と、
   記憶部から、複数の前記署名データと該署名データの各々に対応したハッシュ化アルゴリズムを読み出す処理と、
   該署名データの各々から、前記対応するハッシュ化アルゴリズムを用いて、これに対する電子署名の有効期限が切れているハッシュ値を生成する処理と、
   該ハッシュ値のそれぞれを結合した結合ハッシュ値を生成する処理と、
   該結合ハッシュ値と、該結合ハッシュ値に対する有効期限内の電子署名とを検証する処理とを実施する、
   ことを特徴とする原本性保証方法。
2. 前記検証に成功した場合に、前記所定の署名データと同じ署名チェーン情報に属し、未来方向の最も近くにある公開署名データから前記所定の署名データまでに対して、前後する署名データ間の整合性を順次検証する処理を実施する、
   ことを特徴とする請求項１に記載の原本性保証方法。
3. 管理サーバにより、文書データに対して電子署名を行った結果である署名データの原本性を保証する原本性保証方法であって、
   記憶部から、複数の署名データと該署名データの各々に対応したハッシュ化アルゴリズムを読み出す処理と、
   該読み出した署名データの各々から、前記対応するハッシュ化アルゴリズムを用いて、ハッシュ値（Ｈ_１、Ｈ_２、・・・、Ｈ_n−１）を生成する処理と、
   該生成したハッシュ値のそれぞれを結合した第１の結合ハッシュ値（Ｈ_１＋Ｈ_２＋・・・＋Ｈ_n−１）を生成する処理と、
   前記第１の結合ハッシュ値に対して、第１の電子署名（Ｓ_ｎ−１）を生成する処理と、
   該生成した第１の結合ハッシュ値と前記第１の電子署名とを検証する処理と、
   該検証が成功した場合、前記記憶部から読み出した対応署名データおよびハッシュ化アルゴリズムを用いて公開ハッシュ値（Ｈ_ｎ）を生成する処理と、
   前記第１の結合ハッシュ値に前記生成した公開ハッシュ値を結合した第２の結合ハッシュ値（Ｈ_１＋Ｈ_２+・・・＋Ｈ_ｎ）を生成する処理と、
   前記第２の結合ハッシュ値に対して、第２の電子署名（Ｓ_ｎ）を生成して前記記憶部に格納する処理と、
   外部からネットワークを介して所定の署名データの署名検証要求を受信すると、前記第２の結合ハッシュ値と前記第２の電子署名とを検証する処理とを実施する、
   ことを特徴とする署名データの原本性保証方法。
4. 文書データに対する電子署名を行う際に、前記文書データに固有の第１の情報および前回の電子署名の結果である署名データが論理的につながる署名チェーン情報を形成する１以上の署名生成クライアントとネットワークを介して接続された管理サーバにおける前記署名データの原本性保証方法であって、
   前記署名生成クライアントから前記署名チェーン情報を前記ネットワークを介して受信する処理と、
   該署名チェーン情報を記憶部に格納する処理と、
   該署名チェーン情報から公開すべき公開署名データを取得する処理と、
   該公開署名データから所定のハッシュ化アルゴリズムを用いてハッシュ値を算出し、前記公開署名データに固有の第２の情報、および、前記所定のハッシュ化アルゴリズムに固有の第３の情報を前記記憶部に格納する処理と、
   前記第２の情報、前記第３の情報および前記ハッシュ値を、前記第２の情報に対応する前記公開署名データが改ざんされていないことを保証する信頼ポイント情報として作成する処理と、
   １回目から前回までの各信頼ポイント情報における前記ハッシュ値を結合した結合公開ハッシュ値と、前回信頼ポイント情報作成時に生成した電子署名とを署名検証する処理と、
   該検証が成功した場合、１回目から今回までの各信頼ポイント情報における結合公開ハッシュ値に対する電子署名を生成し前記記憶部に格納する処理と、
   外部から前記ネットワークを介して署名データの署名検証要求を受信すると、前記１回目から今回までの各信頼ポイント情報における結合公開ハッシュ値と該結合公開ハッシュ値に対する電子署名とを検証する処理とを実施する、
   ことを特徴とする署名データの原本性保証方法。
5. 前記署名チェーン情報から前記公開署名データを取得する処理において、最新の署名データから前回公開した署名データまでに対して、前後する２個の署名データのうち、新しい署名データに含まれる前記第２の情報と、古い署名データから求めた第２の情報とを比較することによって、前後する署名データ間の整合性を順次検証し、該整合性が継続したときに、前記最新の署名データを公開署名データとし、前記整合性が途切れたときに、その整合性が連続する２以上の署名データのうちの新しい署名データ、または、前後が途切れた１の署名データを公開署名データとする 、
   ことを特徴とする請求項４に記載の署名データの原本性保証方法。
6. 文書データに対して電子署名を行った結果である署名データの原本性を保証する管理サーバであって、
   記憶部と処理部とを有し、
   前記処理部は、
   外部から所定の署名データの検証要求を受信し、
   記憶部から、複数の前記署名データと該署名データの各々に対応したハッシュ化アルゴリズムを読み出し、
   該署名データの各々から、前記対応するハッシュ化アルゴリズムを用いて、これに対する電子署名の有効期限が切れているハッシュ値を生成し、
   該ハッシュ値のそれぞれを結合した結合ハッシュ値を生成し、
   該結合ハッシュ値と、該結合ハッシュ値に対する有効期限内の電子署名とを検証する、
   ことを特徴とする管理サーバ。
7. 前記処理部は、
   前記検証に成功した場合に、前記所定の署名データと同じ署名チェーン情報に属し、未来方向の最も近くにある公開署名データから前記所定の署名データまでに対して、前後する署名データ間の整合性を順次検証する
   ことを特徴とする請求項６に記載の管理サーバ。
8. 文書データに対して電子署名を行った結果である署名データの原本性を保証する管理サーバであって、
   記憶部と処理部とを有し、
   前記処理部は、
   記憶部から、複数の署名データと該署名データの各々に対応したハッシュ化アルゴリズムを読み出し、
   該読み出した署名データの各々から、前記対応するハッシュ化アルゴリズムを用いて、ハッシュ値（Ｈ_１、Ｈ_２、・・・、Ｈ_n−１）を生成し、
   該生成したハッシュ値のそれぞれを結合した第１の結合ハッシュ値（Ｈ_１＋Ｈ_２＋・・・＋Ｈ_n−１）を生成し、
   前記第１の結合ハッシュ値に対して、第１の電子署名（Ｓ_ｎ−１）を生成し、
   該生成した第１の結合ハッシュ値と前記第１の電子署名とを検証し、
   該検証が成功した場合、前記記憶部から読み出した対応署名データおよびハッシュ化アルゴリズムを用いて公開ハッシュ値（Ｈ_ｎ）を生成し、
   前記第１の結合ハッシュ値に前記生成した公開ハッシュ値を結合した第２の結合ハッシュ値（Ｈ_１＋Ｈ_２+・・・＋Ｈ_ｎ）を生成し、
   前記第２の結合ハッシュ値に対して、第２の電子署名（Ｓ_ｎ）を生成して前記記憶部に格納し、
   外部からネットワークを介して所定の署名データの署名検証要求を受信すると、前記第２の結合ハッシュ値と前記第２の電子署名とを検証する、
   ことを特徴とする管理サーバ。
9. 文書データに対する電子署名を行う際に、その文書データに固有の情報および前回の電子署名の結果である署名データが論理的につながる署名チェーン情報を形成する１以上の署名生成クライアントとネットワークを介して接続された管理サーバであって、
   記憶部と処理部とを有し、
   前記処理部は、
   前記署名生成クライアントから前記署名チェーン情報を前記ネットワークを介して受信し、
   該署名チェーン情報を記憶部に格納し、
   該署名チェーン情報から公開すべき公開署名データを取得し、
   該公開署名データから所定のハッシュ化アルゴリズムを用いてハッシュ値を算出し、前記公開署名データに固有の第２の情報、および、前記所定のハッシュ化アルゴリズムに固有の第３の情報を前記記憶部に格納し、
   前記第２の情報、前記第３の情報および前記ハッシュ値を、前記第２の情報に対応する前記公開署名データが改ざんされていないことを保証する信頼ポイント情報として作成し、
   １回目から前回までの各信頼ポイント情報における前記ハッシュ値を結合した結合公開ハッシュ値と、前回信頼ポイント情報作成時に生成した電子署名とを署名検証し、
   該検証が成功した場合、１回目から今回までの各信頼ポイント情報における結合公開ハッシュ値に対する電子署名を生成し前記記憶部に格納し、
   外部から前記ネットワークを介して署名データの署名検証要求を受信すると、前記１回目から今回までの各信頼ポイント情報における結合公開ハッシュ値と該結合公開ハッシュ値に対する電子署名とを検証する、
   ことを特徴とする管理サーバ。
10. 前記処理部は、
    前記署名チェーン情報から公開署名データを取得する場合に、最新の署名データから前回公開した署名データまでに対して、前後する２個の署名データのうち、新しい署名データに含まれる第２の情報と、古い署名データから求めた第２の情報とを比較することによって、前後する署名データ間の整合性を順次検証し、前記整合性が継続したときに、前記最新の署名データを公開署名データとし、前記整合性が途切れたときに、その整合性が連続する２以上の署名データのうちの新しい署名データ、または、前後が途切れた１の署名データを公開署名データとする、
    ことを特徴とする請求項９に記載の管理サーバ。
11. コンピュータに、文書データに対して電子署名を行った結果である署名データの原本性を保証する処理を実行させるプログラムであって、
    外部から所定の署名データの検証要求を受信する処理と、
    記憶部から、複数の前記署名データと該署名データの各々に対応したハッシュ化アルゴリズムを読み出す処理と、
    該署名データの各々から、前記対応するハッシュ化アルゴリズムを用いて、これに対する電子署名の有効期限が切れているハッシュ値を生成する処理と、
    該ハッシュ値のそれぞれを結合した結合ハッシュ値を生成する処理と、
    該結合ハッシュ値と、該結合ハッシュ値に対する有効期限内の電子署名とを検証する処理とを前記コンピュータに実行させる、
    ことを特徴とするプログラム。
12. 請求項１１に記載のプログラムを記憶したことを特徴とするコンピュータ読み取り可能な記憶媒体。

Images