JP2014053797A

JP2014053797A - 電子文書管理装置及び電子文書管理プログラム

Info

Publication number: JP2014053797A
Application number: JP2012197351A
Authority: JP
Inventors: Shigeo Uchida; 茂生内田
Original assignee: Toshiba Corp; Toshiba TEC Corp
Current assignee: Toshiba Corp; Toshiba TEC Corp
Priority date: 2012-09-07
Filing date: 2012-09-07
Publication date: 2014-03-20
Also published as: US20140075200A1

Abstract

【課題】電子ファイル（ＰＤＦファイル）内にＣＲＬを埋め込まなくても電子ファイルの有効性を検証することができる電子文書管理装置を提供する。
【解決手段】ネットワークに接続されたサーバ装置を含み、認証局及びタイムスタンプ局との間で通信可能な文書管理装置であって、電子ファイルに電子署名を作成する電子署名作成部と、タイムスタンプ局にタイムスタンプの発行を依頼し、タイムスタンプを取得するタイムスタンプ取得部と、電子ファイルの妥当性を確認するため、公開鍵証明書を含む検証情報を認証局から取得する検証情報取得部と、作成された電子署名と、取得したタイムスタンプ及び検証情報とを電子ファイルに埋め込むファイル埋め込み部と、埋め込んだファイルを保管するファイル保管部と、を備える。
【選択図】図２

Description

本発明の実施形態は、電子文書の原本性を保証する電子文書管理装置及び電子文書管理プログラムに関する。

従来、紙文書をスキャンして電子化した後、その電子文書の原本性を保証するために電子署名とタイムスタンプを付与する方法がある。電子署名により本人確認や改竄の検知ができる。またタイムスタンプにより、その時刻に確かに文書が存在したことを証明することができる。

ところが、上記方式では電子署名の署名者の公開鍵証明書や、タイムスタンプを発行するタイムスタンプ認証局の公開鍵証明書の有効期限を超えると保証できなくなってしまう。このため、有効期限を超える前に文書の正当性を検証してタイムスタンプを付与する長期保証の仕組みが考案されている。

このような従来技術を開示したものとして、非特許文献１や非特許文献２が知られている。非特許文献１のPAdES Basicと非特許文献２のPAdES LTVという仕様を組み合わせることで、ＰＤＦファイルの長期保証を実現できる。更に、PAdES Basicにおいては、電子署名の公開鍵証明書を検証するための情報をＰＤＦファイルに埋め込むことが仕様として決められている。

しかしながら、検証するための情報として電子署名の公開鍵証明書の失効リスト（ＣＲＬ）を埋め込む場合、ＣＲＬのファイルサイズが数百ＫＢになることもあるため、ＣＲＬのファイルサイズが大きいと、元のＰＤＦファイルのサイズとは関係なく、埋め込んだＰＤＦファイルのサイズも大きくなってしまうという問題点がある。

ETSI TS 102 778-2 V1.2.1 Electronic Signatures and Infrastructures (ESI);PDF Advanced Electronic Signature Profiles;Part 2: PAdES Basic - Profile based on ISO 32000-1 (PAdES Basic) ETSI TS 102 778-4 V1.1.2 Electronic Signatures and Infrastructures (ESI);PDF Advanced Electronic Signature Profiles;Part 4: PAdES Long Term - PAdES-LTV Profile (PAdES LTV)）

発明が解決しようとする課題は、電子ファイル（例：ＰＤＦファイル）内にＣＲＬを埋め込まなくても電子ファイルの有効性を検証することができる電子文書管理装置及び電子文書管理プログラムを提供することにある。

実施形態の電子文書管理装置は、ネットワークに接続されたサーバ装置を含み、認証局及びタイムスタンプ局との間で通信可能な文書管理装置であって、電子ファイルに電子署名を作成する電子署名作成部と、前記タイムスタンプ局にタイムスタンプの発行を依頼し、前記タイムスタンプ局から発行されたタイムスタンプを取得するタイムスタンプ取得部と、前記電子ファイルの妥当性を確認するため、公開鍵証明書を含む検証情報を前記認証局から取得する検証情報取得部と、前記電子署名作成部により作成された前記電子署名と、前記タイムスタンプ取得部にて取得した前記タイムスタンプと、前記検証情報取部により取得した検証情報とを前記電子ファイルに埋め込むファイル埋め込み部と、前記埋め込んだファイルを保管するファイル保管部と、を備える。

一実施形態に係る電子文書管理装置のシステム構成図一実施形態における文書管理サーバの構成を示すブロック図。一実施形態における認証局の階層構造を示す説明図。一実施形態に文書管理サーバの処理を示すフローチャート。一実施形態における公開鍵証明書の検証処理を示すフローチャート。一実施形態における検証情報の作成処理を示すフローチャート。一実施形態における電子署名とタイムスタンプの検証処理を示すフローチャート。第２の実施形態におけるＣＲＬを文書管理サーバへの保管する際の検証処理を示すフローチャート。

以下、発明を実施するための実施形態について、図面を参照して説明する。尚、各図において同一箇所については同一の符号を付す。

（第１の実施形態）
図１は、第１の実施形態に係る電子文書管理装置のシステム構成図である。図１では、スキャナを含む画像形成装置１０と、文書を保管しておく文書管理サーバ２０と、文書管理サーバ２０と、複数の認証局（ＣＡ：Certificate Authority）３１，３２…３ｎと、タイムスタンプ局（ＴＳＡ：Time Stamp Authority）４１と、これらを接続するネットワークを含む。ネットワークは、文書管理サーバ２０と認証局（ＣＡ）３１，３２…３ｎ及びタイムスタンプ局４１との間についてはインターネット１００であり、画像形成装置１０と文書管理サーバ２０間は、インターネットやＬＡＮ（Local Area Network）１５などである。

画像形成装置１０は、例えばＭＦＰ（Multi-Function Peripherals）である。ＭＦＰ１０の本体の上部には操作部１１が設けられている。操作部１１は、各種のキー（例えばテンキー、クリアキー、スタートキーなど）や、液晶などのタッチパネル式の表示部を含む。またＭＦＰ１０の上部には、原稿台が設けられ、原稿台上に自動原稿送り装置（ＡＤＦ: Auto Document Feeder）が設けられている。さらにＭＦＰ１０には、スキャナ１２とプリンタ部１３を有している。スキャナ１２は、原稿台に置かれた原稿やＡＤＦにて送られた原稿を読取るものである。操作者はスキャナ１２により文書をスキャンし、スキャンして得た画像を文書管理サーバ２０に送信することができる。

文書管理サーバ２０は、スキャナ１２によってスキャンされた画像を取得する。また取得した画像がＰＤＦ（Portable Document Format）ファイルか否かを判定し、ＰＤＦファイル以外の場合にはＰＤＦファイルへ変換する機能を有する。また文書管理サーバ２０は、認証局３１，３２，…３ｎ及びタイムスタンプ局４０とインターネット１００を介して通信を行う。

認証局３１，３２，…３ｎは、電子署名に使用される公開鍵証明書を発行するとともに、公開鍵証明書の検証に必要となる失効情報（ＣＲＬ）を公開する。またタイムスタンプ局４０は、タイムスタンプサービスを提供する。

図２は、文書管理サーバ２０の構成を示すブロック図である。図２に示すように、文書管理サーバ２０は、中央処理装置であるＣＰＵ２１１を含む制御部２１と、ＲＯＭ２２、ＲＡＭ２３、ＨＤＤ制御ユニット２４、ネットワークインターフェース（Ｉ／Ｆ）２５、入力装置２６、出力装置２７、ＣＤ−ＲＯＭ制御ユニット２８を有する。上記の各回路ユニットは、バスライン２９を介して接続されている。

制御部２１のＣＰＵ２１１は、ＲＯＭ２２等に記憶されたプログラムにしたがって文書管理サーバ２０の全体の動作を制御する。また制御部２１は、電子署名作成部２１２と、タイムスタンプ局４１から発行されたタイムスタンプを取得するタイムスタンプ取得部２１３と、公開鍵証明書を含む検証情報を認証局３１，３２…から取得する検証情報取得部２１４と、電子署名と、タイムスタンプと、検証情報とを電子ファイルに埋め込むファイル埋込部２１５を含む。さらに検証情報を利用して、電子ファイル等の有効性を検証する検証部２１６を含む。

ＲＡＭ２３は、各種データの計算や加工等を行う際にデータの読み書きを行う。ＨＤＤ制御ユニット２４は、記憶装置であるＨＤＤを含み、各種の情報（例えば認証局３１，３２，…３ｎから得た公開鍵証明書、失効情報（ＣＲＬ）、及びタイムスタンプ局４０からのタイムスタンプ情報等）等を記憶するファイル保管部を構成する。ネットワークＩ／Ｆ２５は、文書管理サーバ２０をインターネット１００及びＬＡＮ１５に接続する装置である。

入力装置２６は、操作者が操作するキーボード、マウス等の入力デバイスで構成され、操作者の操作により入力信号を作成する。出力装置２７は、液晶ディスプレイ等の表示装置やプリンタ装置等である。ＣＤ−ＲＯＭ制御ユニット２８はＣＤ−ＲＯＭを含む。ＣＤ−ＲＯＭには、文書管理サーバ２０が実行する文書管理プログラムや検証プログラムが格納されており、ＣＤ−ＲＯＭ制御ユニット２８からＣＤ−ＲＯＭのプログラムを読み出す。また文書管理サーバ２０の制御部２１は、ＣＰＵ２１１の制御のもとにＣＤ−ＲＯＭから読み出したプログラムを実行する。

以下、実施形態に係る文書管理装置の動作について説明する。尚、以下の説明では、文書管理サーバ２０と認証局３１及びタイムスタンプ局４１の動作を説明するが、認証局（ＣＡ）とタイムスタンプ局（ＴＳＡ）は、複数局で構成される場合もあり、複数局で構成される場合についても同様の動作を行う。またタイムスタンプ局は、以下、ＴＳＡと呼ぶことにする。

先ず、事前準備として、電子署名を行う署名者（文書管理サーバ２０の操作者）は、信頼される認証局３１に対してユーザ登録の申請行い、予め承認をもらっておく。ユーザ登録の申請では、秘密鍵と公開鍵の鍵ペアを作成し、認証局３１に公開鍵を登録する。これにより、認証局３１に対して公開鍵証明書を要求することで、認証局３１から公開鍵証明書を発行してもらうことができる。

即ち、ＭＦＰ１０のスキャナ１２により原稿の文書をスキャンすると、スキャンした得られた画像データ（電子文書）は文書管理サーバ２０に送られる。ここで操作者がインターネット１００を介して電子文書などの電子データを送付する際に、文書管理サーバ２０は、対象となる電子データに、送信者（操作者）の電子署名と、認証局が発行する公開鍵証明書を添付する。電子データの送信者の電子署名には、送信者の秘密鍵が用いられる。その送信者の秘密鍵と対をなす公開鍵を、認証局３１が証明し署名した証明書が公開鍵証明書である。

一方、電子データの受信者は、受信データに添付された電子署名と公開鍵証明書の有効性を確認することにより、送信者から送付された電子データが改竄されていないことや、確かに送信者自身から送られた電子データであることを確認することができる。

また公開鍵証明書は、有効期間があり、有効期間が切れたとき、或いは有効期間が終了する前に、秘密鍵が漏洩したり、暗号アルゴリズムが破られたりした場合等には、その公開鍵証明書を発行した認証局により失効され無効となる。失効しているか否かの確認には、認証局が発行する公開鍵証明書の失効リスト（ＣＲＬ：Certificate Revocation List）を用いることができる。ＣＲＬには、認証局が発行した有効期間内の公開鍵証明書のうち失効した公開鍵証明書のＩＤと、失効日等が記載され、認証局の署名が付与されており、認証局によって定期的に更新して発行される。

したがって、認証局３１からＣＲＬを取得し、添付された公開鍵証明書のＩＤがＣＲＬに記載されているかどうかを確認し、ＩＤがＣＲＬに記載されている場合は、対応する公開鍵証明書は失効し、記載されていない場合には、公開鍵証明書の有効期限が切れていなければ、この公開鍵証明書は有効であると判断することができる。

また認証局３１による公開鍵証明書への署名には、認証局３１の秘密鍵が用いられ、その認証局３１の秘密鍵と対をなす公開鍵を他の認証局が証明する。したがって、認証局３１は階層構造となる。最上位層の認証局はルート認証局と呼ばれ、自ら証明した公開鍵証明書を発行する。

図３は、認証局３１の階層構造を示す説明図である。図３において、認証局３１は、ルート認証局ＣＡ１を最上位とする階層構造を持つグループを形成している。例えば、ルート認証局である認証局ＣＡ１は、下位の認証局ＣＡ２に対して公開鍵証明書を発行する。認証局ＣＡ２は、さらに下位の認証局ＣＡ３に対して公開鍵証明書を発行する。このような公開鍵証明書の発行は，最下位に位置する認証局まで繰り返される。即ち、下位の認証局が発行した公開鍵証明書が正しいものであることを、その上位の認証局が証明してくれる。

したがって、認証局３１が発行する公開鍵証明書は多数あり、失効する公開鍵証明書が多いとＣＲＬの容量も膨大になる。このため、署名者の公開鍵証明書からルート証明書までのパスに現れるすべてのＣＲＬが添付された電子データを受信する受信者にとっては、受信したいデータの容量よりも大きなサイズのＣＲＬも含めて保管しなければならず、ディスク容量を圧迫することになる。

第１の実施形態では、ＰＤＦファイル内にＣＲＬの代わりに公開鍵証明書を埋め込み、公開鍵証明書に含まれるＣＲＬ配布ポイントに記述されたＵＲＬ（Uniform Resource Locator）を参照することでＣＲＬを取得できるようにし、公開鍵証明書が失効しているかどうかを確認することができるようにしたものである。

次に、図４〜図６を用いて、第１の実施形の具体的な動作を説明する。図４は、文書管理サーバの処理を示すフローチャート、図５は、公開鍵証明書の検証処理を示すフローチャート、図６は、検証情報の作成処理を示すフローチャートである。図４〜図６は、主に電子署名作成部２１２、タイムスタンプ取得部２１３、検証情報取得部２１４、ファイル埋込部２１５の処理を示す。

図４の動作Ａ１において、文書管理サーバ２０はスキャナ１２によってスキャンされた画像を取得する。動作Ａ２では、取得した画像がＰＤＦファイルか否かを判定する。画像がＪＰＥＧファイルやＴＩＦＦファイル等のＰＤＦファイル以外の場合には、動作Ａ３にてＰＤＦファイルへ変換し、動作Ａ４に進む。もし、画像が複数枚存在する場合にはＰＤＦファイル一つにまとめておく。また動作Ａ２で、取得した画像がＰＤＦファイルであれば動作Ａ４に進む。

動作Ａ４で、文書管理サーバ２０はＰＤＦファイルを開き、ＰＤＦファイルに電子署名を付与する。動作Ａ５では、電子署名に関するデータをＰＤＦファイル内に埋め込むために、電子署名に必要なＰＤＦのオブジェクトを追加する。即ち、電子署名に関するデータをＰＤＦファイル内に埋め込む際には、どのようなタグを付けるか決められているため、決められたタグで埋め込む。次に動作Ａ６では、認証局３１から発行された署名者の公開鍵証明書を検証する。図５は、動作Ａ６の公開鍵証明書の検証方法示すフローチャートである。

図５において、動作Ａ２１では、公開鍵証明書から有効期限を取得する。動作Ａ２２では、取得した有効期限と現在時刻を比較し、有効期限が切れていないかを判断する。有効期限が切れていた場合には、公開鍵証明書は既に失効しているため、動作Ａ２３に進み、検証結果を「失効」として公開鍵証明書の検証処理を終了する。もし、有効期限が切れていないならば、動作Ａ２４において、公開鍵証明書を発行した認証局３１に対して失効リスト（ＣＲＬ）を問合せてＣＲＬを取得する。

取得したＣＲＬには、有効期限は切れていないものの、何らかの理由により失効した場合に認証局３１が発行した公開鍵証明書のＩＤ一覧が含まれている。そこで動作Ａ２５では、ＣＲＬの中に公開鍵証明書のＩＤが含まれているか否かを判断する。公開鍵証明書のＩＤが含まれているならば、当該の公開鍵証明書は既に失効しているため、動作Ａ２３に進み、検証結果を「失効」として公開鍵証明書の検証処理を終了する。もし、公開鍵証明書のＩＤが含まれていないならば、動作Ａ２６において公開鍵証明書は「有効」とし、動作Ａ２７に進む。

動作Ａ２７では、公開鍵証明書を発行した認証局３１の正当性を確認するため、公開鍵証明書がルート証明書であるか否かを判断する。公開鍵証明書がルート認証局ＣＡ１の証明書（ルート証明書）であるならば、それは自己署名証明書であるため、その公開鍵証明書は有効であると判断し検証を終了する。もし、公開鍵証明書がルート証明書でないならば、その公開鍵証明書を発行した上位の認証局（ＣＡ２，ＣＡ３…）が存在するため、動作Ａ２８では、その公開鍵証明書に含まれる認証局の所在地に関する情報を利用して、該当する上位の認証局（ＣＡ）の公開鍵証明書を取得する。

そして動作Ａ２９では、動作Ａ２８で取得した認証局の公開鍵証明書を検証する。この検証処理は、図５の処理を再帰的に実行することになる。これをルート証明書に辿りつくか、検証結果が失効であると判断されるかのいずれかに到達するまで処理を繰り返す。

図４に戻って、動作Ａ７では、署名者の公開鍵証明書の検証結果が失効か有効かを判断する。検証結果が失効であると判断した場合、動作Ａ８に進み、公開鍵証明書が失効している旨のエラーを通知して、動作Ａ１８にてＰＤＦファイルをクローズして処理を終了する。もし、署名者の公開鍵証明書の検証結果が有効であると判断した場合、動作Ａ９に進み、ＰＤＦファイルの署名対象領域に対してハッシュ値を計算する。動作Ａ１０では、計算して得られたハッシュ値に対して、有効と判断された署名者の公開鍵証明書に対応する秘密鍵を用いて暗号化を行う。

次に、動作Ａ１１では、ＴＳＡ４１に対してハッシュ値を暗号化して得られたバイト列データを送って、タイムスタンプの発行を要求する。すると、動作Ａ１２において、ＴＳＡ４１は取得したデータからタイムスタンプやＴＳＡ４１の署名を含むタイムスタンプトークンを発行する。動作Ａ１２では、ＴＳＡ４１からタイムスタンプトークンを受信する。次に、動作Ａ１３では、タイムスタンプトークンの有効性を検証するため、タイムスタンプトークンからＴＳＡ４１の公開鍵証明書を取得し、ＴＳＡ４１の公開鍵証明書の有効性を検証する。

動作Ａ１３のＴＳＡ４１の公開鍵証明書の検証処理は、図５のフローチャートに準じた手順で行う。動作Ａ１４では、ＴＳＡ４１の公開鍵証明書の検証結果が失効であるか否かを判断する。検証結果が失効であると判断した場合、動作Ａ８に進み、ＴＳＡ４１の公開鍵証明書が失効している旨のエラーを通知して、動作Ａ１８にてＰＤＦファイルをクローズして処理を終了する。

もし、ＴＳＡ４１の公開鍵証明書の検証結果が有効であると判断したならば、動作Ａ１５において、後でＰＤＦファイルの有効性を検証するために必要となる署名者の検証情報を作成する。即ち、ＰＤＦファイルが有効であるか否かを示すため、ここでは公開鍵証明書を追加する。動作Ａ１５の署名者の検証情報の作成方法を図６に示す。

図６において、先ず動作Ａ３１では、署名者の公開鍵証明書をｄとする。次に動作Ａ３２では、検証情報として公開鍵証明書ｄを追加する。動作Ａ３３では、公開鍵証明書dがルート証明書か否かを判断し、ルート証明書であれば処理を終了し、ルート証明書でなければ、動作Ａ３４に進む。動作Ａ３４では、図５の署名者の公開鍵証明書の検証処理の過程で取得した公開鍵証明書を利用して、公開鍵証明書ｄを発行した上位のＣＡの公開鍵証明書を新たなｄとして設定する。そして、動作Ａ３２に進む。このようにして署名者の検証情報を作成する。

図４に戻って、動作Ａ１６では、ＴＳＡの公開鍵証明書の検証情報を作成する。この処理は、図６の処理手順（動作Ａ３１）において「署名者」を「ＴＳＡ」と置き換えて処理を行えばよい。

以上により、ＰＤＦファイルに埋め込むデータが揃うため、動作Ａ１７では、図６の処理手順により作成した検証情報を含めて該当するオブジェクトにデータを埋め込み、動作Ａ１８でＰＤＦファイルをクローズ処理することにより、電子署名とタイムスタンプを付与したＰＤＦファイルが作成される。

次に、図７を用いて上記の方法により作成されたＰＤＦファイルの有効性を検証する方法を説明する。図７は主に検証部２１６の処理を示す。

図７において、動作Ａ４１では、有効性を検証する対象となっているＰＤＦファイルをオープンする。次に動作Ａ４２で、ＰＤＦファイルに埋め込まれている電子署名データの有効性を検証するため、ＰＤＦファイルからタイムスタンプトークンを取得する。タイムスタンプトークンには、それを発行したＴＳＡの公開鍵証明書が含まれているため、動作Ａ４３では、タイムスタンプトークンを用いてＴＳＡの公開鍵証明書を検証する。

公開鍵証明書の有効性を検証する方法は、図５に示す通りであるが、動作Ａ４３の検証処理は、図５の動作Ａ２４の「ＣＲＬを取得」の処理のみが異なるため、その部分のみ説明する。即ち、ＰＤＦファイル内に埋め込まれているＴＳＡの検証情報をもとに、ＴＳＡからルート証明書までの公開鍵証明書を取得できるため、各公開鍵証明書に含まれるＣＲＬ配布ポイントに記述されたＵＲＬへアクセスして最新のＣＲＬを取得する。その後は、図５に記載されている処理に準じてＴＳＡの公開鍵証明書の検証を行う。

次に、図７の動作Ａ４４において、ＴＳＡの公開鍵証明書を検証した結果をもとに、有効か失効かを判断する。失効していると判断される場合は、動作４５に進み、公開鍵証明書は失効している旨のエラーを通知して、動作Ａ５４でＰＤＦファイルをクローズして処理を終える。もし、ＴＳＡの公開鍵証明書を検証した結果、有効であると判断される場合は、動作Ａ４６にて電子署名部分が改竄されているかどうかを検証する。

動作Ａ４６では、ＴＳＡの秘密鍵で暗号化されたデータをＴＳＡの公開鍵を使って復号した値を計算する。動作Ａ４７では、復号した値と電子署名のハッシュ値を計算して値を比較して、改竄の有無を判断する。比較した値が異なるならば改竄されているため、動作Ａ４８に進み、改竄有りの旨のエラーを通知して動作Ａ５４にてＰＤＦファイルをクローズして処理を終了する。もし、動作Ａ４７で比較した値が同じであれば改竄されていないため、動作Ａ４９ではＰＤＦファイルの有効性を検証するためにＰＤＦファイルから電子署名を取得する。

動作Ａ５０では、ＰＤＦファイルに含まれる署名者の公開鍵証明書を検証する。公開鍵証明書の有効性を検証する方法は、図５の処理に準じて行う。ここでは、図５の動作Ａ２４の「ＣＲＬを取得」の処理のみ異なるため、その部分のみ説明する。即ち、ＰＤＦファイル内に埋め込まれている署名者の検証情報からルート証明書までの公開鍵証明書を取得できるため、各公開鍵証明書に含まれるＣＲＬ配布ポイントに記述されたＵＲＬへアクセスして最新のＣＲＬを取得する。その後は、図５に記載されている通りの処理により署名者の公開鍵証明書の検証を行う。

次に、図７の動作Ａ５１において、署名者の公開鍵証明書を検証した結果をもとに、有効か失効かを判断する。失効していると判断される場合は、動作Ａ４５にて、公開鍵証明書は失効している旨のエラーを通知して、動作Ａ５４でＰＤＦファイルをクローズして処理を終える。もし、署名者の公開鍵証明書を検証した結果、有効であると判断される場合は、動作Ａ５２にてＰＤＦファイルの署名対象部分が改竄されているかどうかを検証する。

動作Ａ５２では、署名者の秘密鍵で暗号化されたデータを署名者の公開鍵を使って復号した値を計算する。動作Ａ５３では、復号した値と、ＰＤＦファイルの署名対象部分のハッシュ値を計算して値を比較して、値が異なるならば改竄されているため、動作Ａ４８で改竄有りの旨のエラーを通知し、動作Ａ５４でＰＤＦファイルをクローズして処理を終了する。もし、動作Ａ５３で比較した値が同じであれば改竄されていないため、ＰＤＦファイルの検証結果は有効であると判断し、動作Ａ５４でＰＤＦファイルをクローズして処理を終える。

このような処理を行うことにより、ＰＤＦファイル内にＣＲＬを埋め込まなくてもＰＤＦファイルの有効性を検証することができる。

つまり、ＰＤＦファイル内にＣＲＬの代わりに公開鍵証明書を埋め込む訳である。公開鍵証明書は、署名者の公開鍵証明書からルート証明書までのパスに出現するすべての認証局の公開鍵証明書である。したがって、各公開鍵証明書を検証して埋め込み、後で公開鍵証明書を検証する際に各公開鍵証明書に含まれるＣＲＬ配布ポイントに記述されたＵＲＬを参照して最新のＣＲＬを取得して、公開鍵証明書が失効しているかどうかを確認することができる。

尚、上記実施形態では、ＰＤＦファイルの作成時に署名者の検証情報とＴＳＡの検証情報をＰＤＦファイル内に埋め込んでいるが、ＴＳＡの検証情報は埋め込まずに検証時に動的に取得する方法も考えられる。

またＰＤＦファイルを検証するときにオフライン環境でも検証できるようにするため、署名者の検証情報として署名者の公開鍵証明書からルート証明書までの証明書チェーンに加えて、公開鍵証明書のＣＲＬを文書管理サーバ２０に保管してタイムスタンプを付与し、それらのＵＲＬも署名者の検証情報として追加しておいてもよい。これにより、ＰＤＦファイルの有効性を検証するときに、署名者の検証情報からＣＲＬを取得できるため、各公開鍵証明書の失効確認が可能となる。

（第２の実施形態）
第２の実施形態は、ＣＲＬを文書管理サーバ２０に保管し、文書管理サーバ２０上に保管した該当するＣＲＬへのＵＲＬを電子ファイル（ＰＤＦファイル）内に埋め込むようにしたものである。

第２の実施形態の処理は、図８のフローチャートに従って行われる。図８において、動作Ａ６１では、認証局３１からＣＲＬを取得するが、取得したＣＲＬが既に文書管理サーバ２０内に保管されているかどうかを検索する。検索条件は、ＣＲＬを配布した認証局３１の名称とＣＲＬの有効期限である。動作Ａ６２では、認証局名と有効期限が同じＣＲＬの有無を判断し、同じＣＲＬを発見した場合、新たに保管する必要はないため処理を終えるが、そうでない場合には、新たに保管する必要がある。また、ＣＲＬが改竄されていないことと、その時間に確かに存在したことを証明するため、動作Ａ６３で、ＣＲＬをＴＳＡへ送信する。

次の動作Ａ６４において、ＴＳＡよりタイムスタンプトークンを受信し、タイムスタンプを付与されたＣＲＬを受信すると、動作Ａ６５では、タイムスタンプトークンに含まれるＴＳＡの公開鍵証明書を検証する。そして、動作Ａ６６では、検証の結果、失効か有効かを判断する。検証の結果、失効していれば動作Ａ６７にて公開鍵証明書が失効している旨のエラーを通知して終了する。一方、検証の結果、有効であれば動作Ａ６８において、タイムスタンプを付与されたＣＲＬを文書管理サーバ２０に保管して終了する。

さらに、複数の文書を電子化する際、同じ秘密鍵を使ったり、異なる秘密鍵を使うが、その鍵ペアを登録した認証局が同じであったりする場合には、公開鍵証明書のＣＲＬは同じになるため、文書管理サーバ２０へ保管するＣＲＬを一つに纏めることができ、記憶領域の節約につながる。

上記したように、第２の実施形態では、署名者の公開鍵証明書からルート証明書までのパスに出現するすべての認証局の公開鍵証明書のＣＲＬをすべて取得して検証するが、ＣＲＬは、ＰＤＦファイル内には埋め込まずに、文書管理サーバ２０に保管する。そして、文書管理サーバ２０上に保管した該当するＣＲＬへのＵＲＬをＰＤＦファイル内に埋め込む。公開鍵証明書の検証時は、ＰＤＦファイルに埋め込んだＵＲＬを参照して文書管理サーバ２０にアクセスして該当するＣＲＬを取得して公開鍵証明書が失効しているかどうかを確認する。

第２の実施形態では、ＣＲＬを文書管理サーバ２０で集中管理することができ、ＰＤＦファイル毎にＣＲＬを埋め込む場合に比べてファイルサイズを削減できる。またＣＲＬを文書管理サーバ２０に保管する際にタイムスタンプを付与すれば、ＣＲＬが確かにその時刻に存在したことも証明でき、厳密な運用ができる。

尚、本発明のいくつかの実施形態を述べたが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これらの実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これらの実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１０…画像形成装置
１２…スキャナ
１５…ＬＡＮ
２０…文書管理サーバ
２１…制御部
２２１…ＣＰＵ
２１２…電子署名作成部
２１３…タイムスタンプ取得部
２１４…検証情報取得部
２１５…ファイル埋込部
２１６…検証部
２２…ＲＯＭ
２３…ＲＡＭ
２４…ＨＤＤ制御ユニット
２５…ネットワークインターフェース（Ｉ／Ｆ）
２６…入力装置
２７…出力装置
２８…ＣＤ−ＲＯＭ制御ユニット
２９…バスライン
３１，３２，３ｎ…認証局
４１…タイムスタンプ局（ＴＳＡ））
１００…インターネット

Claims

ネットワークに接続されたサーバ装置を含み、認証局及びタイムスタンプ局との間で通信可能な文書管理装置であって、
電子ファイルに電子署名を作成する電子署名作成部と、
前記タイムスタンプ局にタイムスタンプの発行を依頼し、前記タイムスタンプ局から発行されたタイムスタンプを取得するタイムスタンプ取得部と、
前記電子ファイルの妥当性を確認するため、公開鍵証明書を含む検証情報を前記認証局から取得する検証情報取得部と、
前記電子署名作成部により作成された前記電子署名と、前記タイムスタンプ取得部にて取得した前記タイムスタンプと、前記検証情報取部により取得した検証情報とを前記電子ファイルに埋め込むファイル埋め込み部と、
前記埋め込んだファイルを保管するファイル保管部と、を備えたことを特徴とする電子文書管理装置。
上記検証情報は、前記認証局から取得した前記公開鍵証明書の証明書チェーンと失効情報とを含む請求項１に記載の電子文書管理装置。
前記失効情報は、前記認証局が発行する公開鍵証明書の失効リスト（ＣＲＬ）へアクセスするためのＵＲＬであることを特徴とする請求項２に記載の電子文書管理装置。
前記ファイル保管部は、前記タイムスタンプが付与された前記失効リスト（ＣＲＬ）を保管し、前記失効情報は、前記ファイル保管部に保管された前記ＣＲＬへアクセスするＵＲＬである請求項２に記載の電子文書管理装置。
前記電子ファイルに埋め込まれた前記検証情報取得部が取得した前記検証情報を利用して、前記電子ファイルの有効性を検証する検証部を備えた請求項１記載の電子文書管理装置。
ネットワークに接続されたサーバ装置を制御して、認証局及びタイムスタンプ局と通信して文書管理を行うプログラムであって、コンピュータに、
電子ファイルに電子署名を作成する電子署名作成処理と、
前記タイムスタンプ局にタイムスタンプの発行を依頼し、前記タイムスタンプ局から発行されたタイムスタンプを取得するタイムスタンプ取得処理と、
前記電子ファイルの妥当性を確認するため、公開鍵証明書を含む検証情報を前記認証局から取得する検証情報取得処理と、
前記電子署名作成部により作成された前記電子署名と、前記タイムスタンプ取得部にて取得した前記タイムスタンプと、前記検証情報取部により取得した検証情報とを前記電子ファイルに埋込むファイル埋込処理と、
前記埋め込んだファイルをファイル保管部に保管する保管処理を実行させるための文書管理プログラム。