情報処理装置、及び情報処理方法
【課題】 電子文書に含まれる複数のパートそれぞれの第一のハッシュ値と、電子文書の全体に対する第二のハッシュ値とを電子署名として外部機器に送信する際、メモリなどの資源が乏しい環境、及び電子署名生成のための外部の機器がない環境で実現する。
【解決手段】 符号化された情報を必要なときに逐次処理していくことで、メモリ資源の消費を低減する。
【解決手段】 符号化された情報を必要なときに逐次処理していくことで、メモリ資源の消費を低減する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、例えば電子署名として電子文書のハッシュ値を外部機器に送信する技術に関するものである。
【背景技術】
【0002】
近年、さまざまな文書が電子データとして扱われるようになり、電子データの重要性が増大している。電子データはコピーや編集が容易であることが長所であるが、逆に改竄も容易である。電子データの改竄を検出するために電子署名と呼ばれる技術があり、すでに広く使われている。
【0003】
XPS(XML Paper Specification、非特許文献1参照)も電子データフォーマットの一つであり、電子署名を含めることができる。XPSファイルは、「パート」と呼ばれるデータを複数集め、Zip形式でまとめたものとなっている。電子署名パートもXPSファイル中の1つのパートとして含まれている。電子署名パートの書式はXML電子署名仕様(非特許文献2参照)を基にしており、更にいくつかの制限を加えたものである。
【0004】
XPSの電子署名を含む文書(以下、電子署名文書)は図1に示す構成になっている。電子署名文書101全体はSignature要素となっている。Signature要素の先頭にはSignedInfo要素102があり、さらにその中にReference要素(又は参照要素)103がある。この中にはObject要素105のハッシュ値が格納されている。SignatureValue要素104には署名値111が格納されている。署名値111はSignedInfo要素102のハッシュ値を、署名者の秘密鍵で暗号化したものである。Object要素105はManifest要素106を含み、さらにその中には通常複数個のReference要素が含まれる。これらのReference要素は署名の対象となるパート1つにつき1つ作成され、署名対象パートのハッシュ値が含まれている。なお、通常、XPS文書に含まれるXMLデータは名前空間宣言や名前空間プレフィックスを持つが、本明細書中では省略している。
【0005】
これら各要素の関係から、パート109、パート110の情報から電子署名文書101を作成するには、まずObject要素の作成とハッシュ値の計算を行う必要がある。その後、SignedInfo要素の作成、SignedInfo要素のハッシュ値計算および暗号化、さらにSignatureValueの作成となる。しかし、この手順では電子署名文書全体を一旦(計算書理に必要な)メモリに保持しなければならない。これは、SignedInfo要素およびSignatureValue要素の作成にはObject要素が完成する必要があるが、そのObject要素がSignatureValue要素より後ろにあるためである。仮にObject要素が先頭であれば、Object要素のハッシュ値を計算してハッシュ値のみ保持し、Object要素そのものは先に外部機器に送信してメモリ上から破棄することができる。しかし、各要素の順序はXML電子署名仕様およびXPS仕様で定められており変更することはできない。
【0006】
このことは署名対象パートが少ない場合には大きな問題とはならないが、多いときにはメモリやハードディスクなどの記憶装置に収まらなくなる可能性がある。前述のとおり署名対象パート1つにつき1つのReference要素が作成されてObject要素内に格納されるため、署名対象パートが多いとObject要素が肥大していく。特に、計算資源の少ない小型機器ではメモリや外部記憶装置に収まらなくなり、多くのパートからなるXPS文書に対して署名を付与できなくなるという問題があった。
【0007】
メモリなどの計算資源が乏しいあるいは非力な環境での電子署名の作成方法としては、電子署名の作成を計算資源の豊富な外部の機器に任せる、という方法がある(例えば、特許文献1参照)。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】特開2002−091303号公報
【非特許文献】
【0009】
【非特許文献1】Standard ECMA−388Open XML Paper Specification(http://www.ecma−international.org/publications/standards/Ecma−388.htm)
【非特許文献2】XML Signature Syntax and Processing(http://www.w3.org/TR/2002/REC−xmldsig−core−20020212/)
【発明の概要】
【発明が解決しようとする課題】
【0010】
しかしながら、外部の機器を利用する方法では署名値を計算する際に使われる秘密鍵を外部に出さなくてはならなくなるという課題がある。秘密鍵はその電子署名の署名者を判別する重要な情報であるため、外部の機器に出すことはセキュリティの面を考慮すると回避する必要がある場合がある。また、この方法では外部の機器がない状況では電子署名を作成できず、利便性が損なわれるという課題もある。そこで本発明は複数のデータ(パート)各々に対してハッシュ値を持つような形式の電子署名を、メモリなどの資源が乏しい環境、及び電子署名のための外部の機器がない環境で作成可能とすることを目的とする。
【課題を解決するための手段】
【0011】
本発明の電子署名作成装置は、複数のパートにより構成される電子文書の電子署名を生成する電子署名生成装置であって、前記パートのハッシュ値と前記ハッシュ値を生成するための情報とを含むハッシュ要素を生成するハッシュ要素生成手段と、符号化テーブルに基づいて前記ハッシュ要素を符号化し、記憶装置に記憶する記憶手段と、前記記憶装置に記憶されている符号化された前記ハッシュ要素を逐次読み出し、前記符号化テーブルに基づいて読み出された前記ハッシュ要素を復号化し、復号化された前記ハッシュ要素に基づいて、既に読み出されたハッシュ要素の全てに対するハッシュ値を更新する更新手段と、前記更新されたハッシュ要素の全てに対するハッシュ値を用いた暗号化処理を行なうことにより、前記電子文書の電子署名を生成する署名生成手段と、を有することを特徴とする。
【発明の効果】
【0012】
本発明により、複数のデータ(パート)各々に対するハッシュ値を持つような形式の電子署名を、メモリなどの資源が乏しい環境、及び電子署名のための外部の機器がない環境で作成可能となる。
【図面の簡単な説明】
【0013】
【図1】XPSの電子署名パートの構成を示した図である。
【図2】第1の実施形態のスキャナのハードウェア構成を示したブロック図である。
【図3】第1の実施形態のソフトウェア構成を示した図である。
【図4】第1の実施形態の電子署名生成処理の全体フローを示した図である。
【図5】Reference要素退避処理のフローを示した図である。
【図6】第1の実施形態が生成する電子署名を示した図である。
【図7】各コンテントタイプと第1の実施形態での命名規則を示したテーブルである。
【図8】XPSの電子署名で使われるSourceTypeと符号を示したテーブルである。
【図9】符号化Reference要素のフォーマットを示した図である。
【図10】Object要素のハッシュ値計算のフローを示した図である。
【図11】Reference要素の例を示した図である。
【図12】ハッシュ生成部の処理を詳細に記述したフローを示した図である。
【発明を実施するための形態】
【0014】
(実施例1)
本実施形態の電子署名生成装置を構成するスキャナ装置(情報処理装置)の構成について、図2のブロック図を参照して説明する。スキャナ装置は単一の装置で実現してもよいし、必要に応じた複数の装置に各機能を分散して実現するようにしてもよい。複数の装置で構成される場合は、互いに通信可能なようにLocal Area Network(LAN)やWide Area Network(WAN)などで接続されている。
【0015】
図2において、Central Processing Unit(CPU)201は、スキャナ装置200全体を制御する。Read Only Memory(ROM)202は、変更を必要としないプログラムやパラメータを格納する。Random Access Memory(RAM)203は、外部装置などから供給されるプログラムやデータを一時記憶する。記憶装置204は、スキャナ装置200に設置されたハードディスク、着脱可能なフレキシブルディスク(FD)やCompact Disc(CD)などの光ディスク、磁気カードなどである。一般に、記憶装置204はRAM203に比べて大容量である一方、データへのアクセスに時間がかかる。このような特性の違いから、RAM203は各種計算処理(例えば、符号化、復号化処理)に必要な記憶領域を提供し、記憶装置204は、データを一時退避するなどの機能を提供する。スキャン部205は、紙文書などを読み取って電子データとして出力する。ネットワークインターフェース206は、外部の機器と接続するためのインターフェースである。操作部207は、ユーザの操作を受け、データを入力するポインティグデバイスやキーボードなどの入力装置である。システムバス208は、CPU201や操作部207のスキャナ装置200内の各ユニットを通信可能に接続する。また、スキャナ装置はMFP(Multi Function Printer)等の情報処理装置の一部として構成されていてもよい。
【0016】
スキャナ装置200は、スキャン部205で紙原稿を読み取り、そのデータをXPS文書として生成、さらに電子署名を付けてネットワーク上の別の機器に送信することが可能である。以降、この場合を例として説明する。
【0017】
本実施形態のソフトウェア構成を図3に示す。ハッシュ生成部301は、任意のデータからそのデータのハッシュ値を計算して生成する。ハッシュ生成部301が行うハッシュ関数は、データの分割処理、すなわち大きなデータであってもそれを分割して逐次処理し、一定のメモリサイズでデータ全体のハッシュ値を求めることが可能なアルゴリズムを利用している。このようなアルゴリズムには例えばMD5(Message Digest 5)やSHA1(Secure Hash Algorithm1)などがある。暗号化部302は、図1のSignedInfo要素の署名値を作成する。暗号化処理のアルゴリズムには、通常RSAやDSAなどの公開鍵暗号方式が用いられる。符号化処理部303は、符号化テーブル307を用いてReference要素(又は参照要素)を符号化して圧縮を行う。Reference要素は、パートに関連する情報(例えば、パート名やパートのハッシュ値を生成するためのハッシュ値計算アルゴリズム)を含む。復号化部304は、符号化テーブル307を用いて符号化Reference要素を復号化する。ハッシュ保持部305は、ハッシュ生成部301が生成したハッシュ値を保持するメモリであり、例えば、RAM203内のメモリ領域の一部である。前述のとおりハッシュ生成部301は、ハッシュ計算の逐次処理に対応しており、ハッシュ保持部305は、その処理過程の一時データを保持、及び更新することに使用される。ハッシュ保持部305は、例えば、RAM203内のメモリ領域の一部である。符号化Reference要素保持部306は、符号化処理部303によって符号化されたReference要素を保持するメモリであり、例えば、記憶装置204内のメモリ領域の一部である。XPS文書生成部308は、電子署名パート以外のXPS文書パートを生成し、更に電子署名パートと組み合わせて電子署名付きXPS文書を生成する。XPS文書生成部308は、OCR機能、グラフィカルオブジェクト検出機能(ベクトル図形検出機能)や画像抽出機能等を有し、更に、抽出された文字列や画像に対してXPS文書パートを生成する。XML正規化部309は、XML文書を正規化する。XMLの正規化とは、XML文書の書式を統一するものであり、ハッシュ値の計算の前処理として使用されることがある。
【0018】
XPS文書生成部308の詳細について説明する。XPS文書生成部308は、スキャン部205によって読み取られた紙原稿のデジタルデータからXPS文書を構成するパートを生成する。また、電子署名を付与する場合には電子署名に関する設定情報も出力する。生成されるパートの種類(コンテントタイプ)の一例を図7(a)に示す。コンテントタイプの識別子はURIの形式であり、図7(a)の3列目に示されている。ただし、本文書では便宜上1列目に示すコンテントタイプ略称を用いて説明する。この略称は説明の簡略化のためであり、実際のコンテントタイプの識別には常にURIが使われる。また、fdocやxamlのように、URIが“xml”で終わるものはXML形式である。
【0019】
XPSでは任意のパート名を使用することが可能だが、XPS文書生成部308は、図7(b)の命名規則に従ってパート名を生成する。fdocやfdseqなどは1つのXPS文書につき1つのみ生成され、パート名は毎回同じものになる。fpageはページ毎に1つ生成され、“1.fpage”、“2.fpage”のようにページ番号を持つ名前となる。JPG、PNG、TIFは画像ファイルであり、各ページに含まれる画像ごとに1つずつ生成される。名前はページ番号とページ内画像番号とからなる名前を持つ。例えば、1ページ目の最初のJPGの画像データは“1−1.JPG”、2ページ目の3番目のPNGの画像データは“2−3.PNG”などとなる。また、fpageと画像データのディレクトリ名はそれぞれ固定のものである。odttfは1つのXPS文書につき1つだが、パート名はランダムな文字列であり文書毎に異なる。
【0020】
relsは、やや特殊な規則を持つ。relsは通常他の特定のパートに付随するものであり、各fdoc、fdseq、fpageパートに対して1つ生成される。パート名は”{付随するパートのあるディレクトリ}/_rels/{付随するパートのファイル名}.rels”という名前になる。例えば”/Documents/1/Pages/1.fpage”という名前のパートに対するrelsパートの名前は”/Documents/1/Pages/_rels/1.fpage.rels”となる。また、他のパートに付随しないrelsパートも文書に必ず1つ含まれている。これはPackageRelationshipパートと呼ばれ、パート名は”/_rels/.rels”である。なお、本実施形態ではこのPackageRelationshipのことをprelと呼び、その他のrelsパートとは区別する。
【0021】
また、XML形式の文書の場合は、さらに正規化設定も出力される。正規化にはいくつかの方法があるが、XPS文書生成部308は、relsとprel以外には正規化の設定は行わない。relsとprelについてはRelationships Transformと標準XML正規化の2つが指定されるのが一般的であり、XPS文書生成部308もこれに従う。Relationships TransformはXPS仕様に含まれるアルゴリズムであり、さらにいくつかのオプションを持つ。このオプションはSourceTypeと呼ばれ、図8に示す13個のオプションを1つ以上選択することが可能であるが、prelは常に図8の1、5、12がセットされている。標準XML正規化は、W3C標準の正規化である(http://www.w3.org/TR/xml−c14n)。正規化のアルゴリズムおよびSourceTypeはすべてURI形式で識別される。
【0022】
以上のように、XPS文書生成部308は、パート名、パートのデータ、コンテントタイプを出力し、さらにrelsやprelの場合は正規化設定(SourceType含む)も出力する。また、fpageと画像データは紙原稿を1枚スキャンする毎に生成され、さらに各ページにおいては最初にfpageが出力され、その後に画像データが生成される。従って、“1.fpage”より先に“2.fpage”が生成されたり、“2.fpage”より先に“2−1.JPG”が生成されたりすることはない。
【0023】
本実施形態の電子署名生成装置が、以上の規則で生成されるXPS文書の電子署名を生成する処理全体の流れを図4に示す。まず署名文書となるSignature要素の初期設定を行う(S402)。この初期設定の結果を図6に示す。XPS電子署名の書式にほぼ従っているが、DigestValue要素611、SignatureValue要素614、およびManifest要素(616〜617)は空である。
【0024】
Object要素はManifest要素の他にSignatureProperties要素(618〜625)等が含まれている。これらの属性はXPS仕様およびXML Signature仕様に従ったものであり、詳細については本実施形態では説明は省略する。 次に、XPS文書生成部308が生成した全てのパートに対して、S403からS406の間の処理、すなわち、S404、S405の処理を行う。まず、パートのハッシュ生成部301を使ってハッシュ値を求める(S404)。ハッシュのアルゴリズムはSHA1である。パート名・コンテントタイプ・ハッシュ値、relsの場合はさらに正規化設定の情報からReference要素を生成して保持する(S405)。S405の詳細を図5に示す。まず、パートの署名設定情報とハッシュ値からReference要素を生成する(S502)。
【0025】
Reference要素の例を図11に示す。図11からもわかるように、Reference要素には、ハッシュ値と、そのハッシュ値を生成するための情報(例えばハッシュ値計算アルゴリズム)とを含む。Reference要素はハッシュ要素とも呼ばれる。1101のURI属性が署名対象パートのパート名とコンテントタイプを表しており、‘?’で区切られている。つまり、パート名は“/Documents/1/_rels/FixedDocument.fdoc.rels”であり、コンテントタイプはrelsである。Transform要素(1103、1109)は正規化設定である。正規化アルゴリズムはAlgorithm属性で指定されており、それぞれRelationships Transformと標準XML正規化である。1104〜1107はSouceTypeであり、図8における6、11、8、5が指定されている。ハッシュ値計算のアルゴリズムはDigestMethod要素(1111)で指定されており、SHA1である。
【0026】
次に、Reference要素退避モードになっているかを確認する(S503)。Reference要素退避モードは、ユーザーが任意に設定する。例えば、ユーザーは情報処理単位でReference要素退避モードか否かを設定しても良いし、或いは、署名要素対象文書単位で設定しても良い。Reference退避モードでなければ保持しているReference要素(又はパート数)の数と所定数n(例えば、100個)とを比較・判断する(S505)。n個未満(又は所定数以下)であれば生成したReference要素をそのままメモリ中に保持しておき、処理を終了する。Reference要素の個数がn個以上の場合はReference要素退避モードをtrueにする。更に、すでに保持しているReference要素すべてを符号化し、符号化Reference要素保持部306に記憶(退避)する(S507)。また、今回生成されたReference要素も同様に符号化して記憶(退避)する(S508、S509)。S503において、Reference要素退避モードが、trueの場合(是の場合)も生成されたReference要素を符号化して符号化Reference要素保持部306に記憶(退避)する。S507における退避処理はS508およびS509の処理と同じである。符号化は符号化処理部303が、符号化テーブル307を用いて行う。符号化テーブルには図7(a)のテーブルと図7(b)のテーブルに示すパート名生成規則が含まれている。
【0027】
符号化はそのパートのコンテントタイプによって異なる方法となる。fdoc・fdseq・otf・coreprop・xaml・prelの場合は、図9(a)に示すフォーマットで保存する。記号Cはコンテントタイプであり、図7(a)の符号(1バイト)が用いられる。SHA1の場合は20バイトである。例えば、fdocの場合は[01 ダイジェスト値]となる。これらのパートのパート名は一意であるため保存する必要はない。
【0028】
fpageは図9(b)のフォーマットで保存する。記号Pはページ番号であり2バイト(16ビット)である。従って最大65535ページとなる。JPG・PNG・TIFは図9(c)のフォーマットで保存する。記号Pはページ番号、記号Nはページ内識別番号であり、それぞれ2バイトである。例えば”2−3.JPG”の場合は[11 00 02 00 03 ダイジェスト値]となる。
【0029】
odttfは図9(d)のフォーマットである。odttfのパート名は毎回異なる名前が生成されるため、パート名をそのまま保持する。記号PLはパート名の長さであり、記号PartNameはパート名である。
【0030】
なお、図9(a)から9(d)のフォーマットを使うパートは、正規化設定が一意であり、それらの情報は保存する必要はない。
【0031】
relsはやや特殊であり図9(e)のフォーマットである。記号STはSourceTypeであり2バイト、つまり16ビットである。この16ビットの下位ビットから順に図8のビットが対応する。また、前述のとおりrelsパートは他のパートに付随したものになっており、記号PartInfoはその対応するパートのフォーマットである。
【0032】
例えば、図11に示すrelsパートに対するReference要素の場合を考える。まず、コンテントタイプからこのパートがrelsであることがわかり、先頭バイトは21である。また前述のとおり、Relationships TransformのSourceType設定は図8における6、11、8、5である。2バイト(16ビット)下位6、11、8、5ビットを立てたものは0000100101100000である(0から数えるため実際には右から6、7、9、12ビット目が1)。これを16進数で表すと[09 60]である。PartInfoは付随パートの情報が必要だが、付随パートはパート名から判別でき、“/Documents/1/FixedDocument.fdoc”である。図7(b)から、付随するパートのコンテントタイプがfdocであることがわかる。fdocは図9(a)の形式で符号化し、コンテントタイプは01である。従って、図11のReference要素を符号化すると[21 09 06 01 ダイジェスト値]である。このようにして、relsのハッシュ値および署名設定情報を保存する。
【0033】
なお、本実施形態では1つのReference要素に関する情報をエントリと呼ぶ。符号化Reference要素保持部306は0個以上のエントリから構成される。
【0034】
すべての署名対象パートに対するReference要素の作成および符号化Reference要素の作成・退避が終われば、次にObject要素のハッシュ値生成処理S407を行う。この処理の詳細を図10に示す。まず、Object、Manifest開始タグ、つまり615、616を正規化してハッシュ生成部301に入力する(1002)。途中結果はハッシュ保持部305に格納される。正規化のアルゴリズムは607に記述されており、標準XML正規化である。また、1007、1009での正規化も同様である。Reference要素退避モードがtrueでない場合(署名対象パートがn、例えば100以下だった場合)は、Reference要素はすべてRAM203上にある。従ってこれをそのまま正規化し、ハッシュ生成部に入力する(1012)。
【0035】
退避されていた場合は、符号化Reference要素保持部306の末尾に達するまでエントリをRAM203に逐次読み出して(1005)、Reference要素を復号化し(1006)、ハッシュ生成部301に入力する(1007)。
【0036】
Reference要素の復号化にはコンテントタイプ、パート名、ダイジェスト値、relsの場合はさらにSourceTypeが必要である。コンテントタイプは各エントリの1バイト目に記述されている。その他の情報についてはコンテントタイプによって異なる。図9(a)のフォーマットの場合はパート名が決まっており容易に復号化できる。図9(b)のフォーマット(fpage)の場合は、最初のfpageの場合に”1.fpage”、以降はページ番号を増やして”2.fpage”、”3.fpge”とし、固定のディレクトリ名を加えればよい。図9(c)のフォーマット(JPG、PNG、TIF)の場合は、ページ番号はこれまで出現したfpageの数、ページ内識別番号は各ページ内で1、2、3……の順に増やしていくことで復号化できる。図9(d)(odttf)の場合は2バイト目にパート名の長さがあり、3バイト目以降にパート名が含まれている。図9(e)(rels)の場合は2バイト目にSourceTypeがあり、3バイト目以降に付随するパートのフォーマットでパート名、コンテントタイプなどの情報が含まれている。これらの情報から元のReference要素を復号化することが可能である。
【0037】
なお、符号化Reference要素保持部にある情報はこの段階では破棄されずに残っている。一方RAM203に逐次読みだされた符号化Reference要素および復号化されたReference要素は、ハッシュ生成部に入力した時点で破棄する。従ってすべての復号化されたReference要素をRAM203上に持つことなく処理することが可能である。
【0038】
図12は、S1007でのハッシュ生成部301の処理を示したフローである。S1005で読み込まれた復号化されたReference要素に対するハッシュ値を求める(S1201)。そして、求められたハッシュ値に基づいて、ハッシュ保持部305に保持されているハッシュ値を更新する(S1202)。具体的には、求められたハッシュ値を、ハッシュ保持部305に保持されているハッシュ値に合成することにより、ハッシュ保持部305に保持されているハッシュ値を更新する。そして、ハッシュ値が更新された後、S1005で読み込まれた復号化されたReference要素、及びそのハッシュ値はRAM203上から削除される(S1203)。
【0039】
S1004からS1008までの処理を全ての符号化Reference要素に対して実行する。Object要素に対するハッシュ値を求めるためには、全てのReference要素を復号化する必要があるが、上記のように「逐次的に」復号化することにより、大きなRAM203を用意する必要はない。
【0040】
全てのReference要素のハッシュ生成部への入力が終わると、以降のObject、つまり617から626までを正規化して入力する(1009)。さらに生成されたハッシュ値を取得し、ハッシュ保持部305に保持されているハッシュ値を更新することにより、Object要素全体のハッシュ値を生成する(1010)。このハッシュ値は611のDigestValue要素内に格納される。これで図10の処理、すなわちS407は完了である。
【0041】
SignedInfo要素が完成すると次に署名値の生成を行う(S408)。署名値は前述のとおりSignedInfo要素のハッシュ値を暗号化処理したものである。署名値は614のSignatureValue要素内に格納される。このときのハッシュ生成アルゴリズムと暗号化アルゴリズムはSignatureMethod要素605に記述されており、SHA1とRSAである。
【0042】
最後に電子署名送信を行う。この段階で署名文書の601から616までは完成された状態であり、このまま送信する(S409)。次に、符号化Reference要素保持部306から1エントリずつ読み出し、復号化して送信する(S410)。この復号化は先ほどの方法と同じである。また、退避モードがtrueでないときは当然RAM203上にあるReference要素をそのまま送信する。最後に617から627を送信し(S411)、処理は終了である。退避モードがtrueでないときは、符号化・復号化の処理がないため、計算処理は早くなる。
【0043】
以上の処理でRAM203上に置かれるのは、Manifest要素内のReference要素が省かれたSignature要素(図6)、n個以下のReference要素、その他いくつかの少量データのみである。
【0044】
なお、本実施例では図6および図11のようにXML文書そのものの形式で保持していたが、別のツリー形式で持つことも可能である。このようなツリー構造には例えばDOM(Document Object Model)がある。
【0045】
また、本実施例ではメモリ上のReference要素のカウント数nの閾値を例として100としたが、この所定数を減らすことでさらにメモリ使用量を削減することができる。閾値を1とすれば、メモリ上に置かれるReference要素を1つのみにして署名文書を作成することができる。このような処理を行うことで、計算資源の少ない機器においても大きな電子文書に対する電子署名の付与が可能となる。
【0046】
(その他の実施例)
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)がプログラムを読み出して実行する処理である。
【技術分野】
【0001】
本発明は、例えば電子署名として電子文書のハッシュ値を外部機器に送信する技術に関するものである。
【背景技術】
【0002】
近年、さまざまな文書が電子データとして扱われるようになり、電子データの重要性が増大している。電子データはコピーや編集が容易であることが長所であるが、逆に改竄も容易である。電子データの改竄を検出するために電子署名と呼ばれる技術があり、すでに広く使われている。
【0003】
XPS(XML Paper Specification、非特許文献1参照)も電子データフォーマットの一つであり、電子署名を含めることができる。XPSファイルは、「パート」と呼ばれるデータを複数集め、Zip形式でまとめたものとなっている。電子署名パートもXPSファイル中の1つのパートとして含まれている。電子署名パートの書式はXML電子署名仕様(非特許文献2参照)を基にしており、更にいくつかの制限を加えたものである。
【0004】
XPSの電子署名を含む文書(以下、電子署名文書)は図1に示す構成になっている。電子署名文書101全体はSignature要素となっている。Signature要素の先頭にはSignedInfo要素102があり、さらにその中にReference要素(又は参照要素)103がある。この中にはObject要素105のハッシュ値が格納されている。SignatureValue要素104には署名値111が格納されている。署名値111はSignedInfo要素102のハッシュ値を、署名者の秘密鍵で暗号化したものである。Object要素105はManifest要素106を含み、さらにその中には通常複数個のReference要素が含まれる。これらのReference要素は署名の対象となるパート1つにつき1つ作成され、署名対象パートのハッシュ値が含まれている。なお、通常、XPS文書に含まれるXMLデータは名前空間宣言や名前空間プレフィックスを持つが、本明細書中では省略している。
【0005】
これら各要素の関係から、パート109、パート110の情報から電子署名文書101を作成するには、まずObject要素の作成とハッシュ値の計算を行う必要がある。その後、SignedInfo要素の作成、SignedInfo要素のハッシュ値計算および暗号化、さらにSignatureValueの作成となる。しかし、この手順では電子署名文書全体を一旦(計算書理に必要な)メモリに保持しなければならない。これは、SignedInfo要素およびSignatureValue要素の作成にはObject要素が完成する必要があるが、そのObject要素がSignatureValue要素より後ろにあるためである。仮にObject要素が先頭であれば、Object要素のハッシュ値を計算してハッシュ値のみ保持し、Object要素そのものは先に外部機器に送信してメモリ上から破棄することができる。しかし、各要素の順序はXML電子署名仕様およびXPS仕様で定められており変更することはできない。
【0006】
このことは署名対象パートが少ない場合には大きな問題とはならないが、多いときにはメモリやハードディスクなどの記憶装置に収まらなくなる可能性がある。前述のとおり署名対象パート1つにつき1つのReference要素が作成されてObject要素内に格納されるため、署名対象パートが多いとObject要素が肥大していく。特に、計算資源の少ない小型機器ではメモリや外部記憶装置に収まらなくなり、多くのパートからなるXPS文書に対して署名を付与できなくなるという問題があった。
【0007】
メモリなどの計算資源が乏しいあるいは非力な環境での電子署名の作成方法としては、電子署名の作成を計算資源の豊富な外部の機器に任せる、という方法がある(例えば、特許文献1参照)。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】特開2002−091303号公報
【非特許文献】
【0009】
【非特許文献1】Standard ECMA−388Open XML Paper Specification(http://www.ecma−international.org/publications/standards/Ecma−388.htm)
【非特許文献2】XML Signature Syntax and Processing(http://www.w3.org/TR/2002/REC−xmldsig−core−20020212/)
【発明の概要】
【発明が解決しようとする課題】
【0010】
しかしながら、外部の機器を利用する方法では署名値を計算する際に使われる秘密鍵を外部に出さなくてはならなくなるという課題がある。秘密鍵はその電子署名の署名者を判別する重要な情報であるため、外部の機器に出すことはセキュリティの面を考慮すると回避する必要がある場合がある。また、この方法では外部の機器がない状況では電子署名を作成できず、利便性が損なわれるという課題もある。そこで本発明は複数のデータ(パート)各々に対してハッシュ値を持つような形式の電子署名を、メモリなどの資源が乏しい環境、及び電子署名のための外部の機器がない環境で作成可能とすることを目的とする。
【課題を解決するための手段】
【0011】
本発明の電子署名作成装置は、複数のパートにより構成される電子文書の電子署名を生成する電子署名生成装置であって、前記パートのハッシュ値と前記ハッシュ値を生成するための情報とを含むハッシュ要素を生成するハッシュ要素生成手段と、符号化テーブルに基づいて前記ハッシュ要素を符号化し、記憶装置に記憶する記憶手段と、前記記憶装置に記憶されている符号化された前記ハッシュ要素を逐次読み出し、前記符号化テーブルに基づいて読み出された前記ハッシュ要素を復号化し、復号化された前記ハッシュ要素に基づいて、既に読み出されたハッシュ要素の全てに対するハッシュ値を更新する更新手段と、前記更新されたハッシュ要素の全てに対するハッシュ値を用いた暗号化処理を行なうことにより、前記電子文書の電子署名を生成する署名生成手段と、を有することを特徴とする。
【発明の効果】
【0012】
本発明により、複数のデータ(パート)各々に対するハッシュ値を持つような形式の電子署名を、メモリなどの資源が乏しい環境、及び電子署名のための外部の機器がない環境で作成可能となる。
【図面の簡単な説明】
【0013】
【図1】XPSの電子署名パートの構成を示した図である。
【図2】第1の実施形態のスキャナのハードウェア構成を示したブロック図である。
【図3】第1の実施形態のソフトウェア構成を示した図である。
【図4】第1の実施形態の電子署名生成処理の全体フローを示した図である。
【図5】Reference要素退避処理のフローを示した図である。
【図6】第1の実施形態が生成する電子署名を示した図である。
【図7】各コンテントタイプと第1の実施形態での命名規則を示したテーブルである。
【図8】XPSの電子署名で使われるSourceTypeと符号を示したテーブルである。
【図9】符号化Reference要素のフォーマットを示した図である。
【図10】Object要素のハッシュ値計算のフローを示した図である。
【図11】Reference要素の例を示した図である。
【図12】ハッシュ生成部の処理を詳細に記述したフローを示した図である。
【発明を実施するための形態】
【0014】
(実施例1)
本実施形態の電子署名生成装置を構成するスキャナ装置(情報処理装置)の構成について、図2のブロック図を参照して説明する。スキャナ装置は単一の装置で実現してもよいし、必要に応じた複数の装置に各機能を分散して実現するようにしてもよい。複数の装置で構成される場合は、互いに通信可能なようにLocal Area Network(LAN)やWide Area Network(WAN)などで接続されている。
【0015】
図2において、Central Processing Unit(CPU)201は、スキャナ装置200全体を制御する。Read Only Memory(ROM)202は、変更を必要としないプログラムやパラメータを格納する。Random Access Memory(RAM)203は、外部装置などから供給されるプログラムやデータを一時記憶する。記憶装置204は、スキャナ装置200に設置されたハードディスク、着脱可能なフレキシブルディスク(FD)やCompact Disc(CD)などの光ディスク、磁気カードなどである。一般に、記憶装置204はRAM203に比べて大容量である一方、データへのアクセスに時間がかかる。このような特性の違いから、RAM203は各種計算処理(例えば、符号化、復号化処理)に必要な記憶領域を提供し、記憶装置204は、データを一時退避するなどの機能を提供する。スキャン部205は、紙文書などを読み取って電子データとして出力する。ネットワークインターフェース206は、外部の機器と接続するためのインターフェースである。操作部207は、ユーザの操作を受け、データを入力するポインティグデバイスやキーボードなどの入力装置である。システムバス208は、CPU201や操作部207のスキャナ装置200内の各ユニットを通信可能に接続する。また、スキャナ装置はMFP(Multi Function Printer)等の情報処理装置の一部として構成されていてもよい。
【0016】
スキャナ装置200は、スキャン部205で紙原稿を読み取り、そのデータをXPS文書として生成、さらに電子署名を付けてネットワーク上の別の機器に送信することが可能である。以降、この場合を例として説明する。
【0017】
本実施形態のソフトウェア構成を図3に示す。ハッシュ生成部301は、任意のデータからそのデータのハッシュ値を計算して生成する。ハッシュ生成部301が行うハッシュ関数は、データの分割処理、すなわち大きなデータであってもそれを分割して逐次処理し、一定のメモリサイズでデータ全体のハッシュ値を求めることが可能なアルゴリズムを利用している。このようなアルゴリズムには例えばMD5(Message Digest 5)やSHA1(Secure Hash Algorithm1)などがある。暗号化部302は、図1のSignedInfo要素の署名値を作成する。暗号化処理のアルゴリズムには、通常RSAやDSAなどの公開鍵暗号方式が用いられる。符号化処理部303は、符号化テーブル307を用いてReference要素(又は参照要素)を符号化して圧縮を行う。Reference要素は、パートに関連する情報(例えば、パート名やパートのハッシュ値を生成するためのハッシュ値計算アルゴリズム)を含む。復号化部304は、符号化テーブル307を用いて符号化Reference要素を復号化する。ハッシュ保持部305は、ハッシュ生成部301が生成したハッシュ値を保持するメモリであり、例えば、RAM203内のメモリ領域の一部である。前述のとおりハッシュ生成部301は、ハッシュ計算の逐次処理に対応しており、ハッシュ保持部305は、その処理過程の一時データを保持、及び更新することに使用される。ハッシュ保持部305は、例えば、RAM203内のメモリ領域の一部である。符号化Reference要素保持部306は、符号化処理部303によって符号化されたReference要素を保持するメモリであり、例えば、記憶装置204内のメモリ領域の一部である。XPS文書生成部308は、電子署名パート以外のXPS文書パートを生成し、更に電子署名パートと組み合わせて電子署名付きXPS文書を生成する。XPS文書生成部308は、OCR機能、グラフィカルオブジェクト検出機能(ベクトル図形検出機能)や画像抽出機能等を有し、更に、抽出された文字列や画像に対してXPS文書パートを生成する。XML正規化部309は、XML文書を正規化する。XMLの正規化とは、XML文書の書式を統一するものであり、ハッシュ値の計算の前処理として使用されることがある。
【0018】
XPS文書生成部308の詳細について説明する。XPS文書生成部308は、スキャン部205によって読み取られた紙原稿のデジタルデータからXPS文書を構成するパートを生成する。また、電子署名を付与する場合には電子署名に関する設定情報も出力する。生成されるパートの種類(コンテントタイプ)の一例を図7(a)に示す。コンテントタイプの識別子はURIの形式であり、図7(a)の3列目に示されている。ただし、本文書では便宜上1列目に示すコンテントタイプ略称を用いて説明する。この略称は説明の簡略化のためであり、実際のコンテントタイプの識別には常にURIが使われる。また、fdocやxamlのように、URIが“xml”で終わるものはXML形式である。
【0019】
XPSでは任意のパート名を使用することが可能だが、XPS文書生成部308は、図7(b)の命名規則に従ってパート名を生成する。fdocやfdseqなどは1つのXPS文書につき1つのみ生成され、パート名は毎回同じものになる。fpageはページ毎に1つ生成され、“1.fpage”、“2.fpage”のようにページ番号を持つ名前となる。JPG、PNG、TIFは画像ファイルであり、各ページに含まれる画像ごとに1つずつ生成される。名前はページ番号とページ内画像番号とからなる名前を持つ。例えば、1ページ目の最初のJPGの画像データは“1−1.JPG”、2ページ目の3番目のPNGの画像データは“2−3.PNG”などとなる。また、fpageと画像データのディレクトリ名はそれぞれ固定のものである。odttfは1つのXPS文書につき1つだが、パート名はランダムな文字列であり文書毎に異なる。
【0020】
relsは、やや特殊な規則を持つ。relsは通常他の特定のパートに付随するものであり、各fdoc、fdseq、fpageパートに対して1つ生成される。パート名は”{付随するパートのあるディレクトリ}/_rels/{付随するパートのファイル名}.rels”という名前になる。例えば”/Documents/1/Pages/1.fpage”という名前のパートに対するrelsパートの名前は”/Documents/1/Pages/_rels/1.fpage.rels”となる。また、他のパートに付随しないrelsパートも文書に必ず1つ含まれている。これはPackageRelationshipパートと呼ばれ、パート名は”/_rels/.rels”である。なお、本実施形態ではこのPackageRelationshipのことをprelと呼び、その他のrelsパートとは区別する。
【0021】
また、XML形式の文書の場合は、さらに正規化設定も出力される。正規化にはいくつかの方法があるが、XPS文書生成部308は、relsとprel以外には正規化の設定は行わない。relsとprelについてはRelationships Transformと標準XML正規化の2つが指定されるのが一般的であり、XPS文書生成部308もこれに従う。Relationships TransformはXPS仕様に含まれるアルゴリズムであり、さらにいくつかのオプションを持つ。このオプションはSourceTypeと呼ばれ、図8に示す13個のオプションを1つ以上選択することが可能であるが、prelは常に図8の1、5、12がセットされている。標準XML正規化は、W3C標準の正規化である(http://www.w3.org/TR/xml−c14n)。正規化のアルゴリズムおよびSourceTypeはすべてURI形式で識別される。
【0022】
以上のように、XPS文書生成部308は、パート名、パートのデータ、コンテントタイプを出力し、さらにrelsやprelの場合は正規化設定(SourceType含む)も出力する。また、fpageと画像データは紙原稿を1枚スキャンする毎に生成され、さらに各ページにおいては最初にfpageが出力され、その後に画像データが生成される。従って、“1.fpage”より先に“2.fpage”が生成されたり、“2.fpage”より先に“2−1.JPG”が生成されたりすることはない。
【0023】
本実施形態の電子署名生成装置が、以上の規則で生成されるXPS文書の電子署名を生成する処理全体の流れを図4に示す。まず署名文書となるSignature要素の初期設定を行う(S402)。この初期設定の結果を図6に示す。XPS電子署名の書式にほぼ従っているが、DigestValue要素611、SignatureValue要素614、およびManifest要素(616〜617)は空である。
【0024】
Object要素はManifest要素の他にSignatureProperties要素(618〜625)等が含まれている。これらの属性はXPS仕様およびXML Signature仕様に従ったものであり、詳細については本実施形態では説明は省略する。 次に、XPS文書生成部308が生成した全てのパートに対して、S403からS406の間の処理、すなわち、S404、S405の処理を行う。まず、パートのハッシュ生成部301を使ってハッシュ値を求める(S404)。ハッシュのアルゴリズムはSHA1である。パート名・コンテントタイプ・ハッシュ値、relsの場合はさらに正規化設定の情報からReference要素を生成して保持する(S405)。S405の詳細を図5に示す。まず、パートの署名設定情報とハッシュ値からReference要素を生成する(S502)。
【0025】
Reference要素の例を図11に示す。図11からもわかるように、Reference要素には、ハッシュ値と、そのハッシュ値を生成するための情報(例えばハッシュ値計算アルゴリズム)とを含む。Reference要素はハッシュ要素とも呼ばれる。1101のURI属性が署名対象パートのパート名とコンテントタイプを表しており、‘?’で区切られている。つまり、パート名は“/Documents/1/_rels/FixedDocument.fdoc.rels”であり、コンテントタイプはrelsである。Transform要素(1103、1109)は正規化設定である。正規化アルゴリズムはAlgorithm属性で指定されており、それぞれRelationships Transformと標準XML正規化である。1104〜1107はSouceTypeであり、図8における6、11、8、5が指定されている。ハッシュ値計算のアルゴリズムはDigestMethod要素(1111)で指定されており、SHA1である。
【0026】
次に、Reference要素退避モードになっているかを確認する(S503)。Reference要素退避モードは、ユーザーが任意に設定する。例えば、ユーザーは情報処理単位でReference要素退避モードか否かを設定しても良いし、或いは、署名要素対象文書単位で設定しても良い。Reference退避モードでなければ保持しているReference要素(又はパート数)の数と所定数n(例えば、100個)とを比較・判断する(S505)。n個未満(又は所定数以下)であれば生成したReference要素をそのままメモリ中に保持しておき、処理を終了する。Reference要素の個数がn個以上の場合はReference要素退避モードをtrueにする。更に、すでに保持しているReference要素すべてを符号化し、符号化Reference要素保持部306に記憶(退避)する(S507)。また、今回生成されたReference要素も同様に符号化して記憶(退避)する(S508、S509)。S503において、Reference要素退避モードが、trueの場合(是の場合)も生成されたReference要素を符号化して符号化Reference要素保持部306に記憶(退避)する。S507における退避処理はS508およびS509の処理と同じである。符号化は符号化処理部303が、符号化テーブル307を用いて行う。符号化テーブルには図7(a)のテーブルと図7(b)のテーブルに示すパート名生成規則が含まれている。
【0027】
符号化はそのパートのコンテントタイプによって異なる方法となる。fdoc・fdseq・otf・coreprop・xaml・prelの場合は、図9(a)に示すフォーマットで保存する。記号Cはコンテントタイプであり、図7(a)の符号(1バイト)が用いられる。SHA1の場合は20バイトである。例えば、fdocの場合は[01 ダイジェスト値]となる。これらのパートのパート名は一意であるため保存する必要はない。
【0028】
fpageは図9(b)のフォーマットで保存する。記号Pはページ番号であり2バイト(16ビット)である。従って最大65535ページとなる。JPG・PNG・TIFは図9(c)のフォーマットで保存する。記号Pはページ番号、記号Nはページ内識別番号であり、それぞれ2バイトである。例えば”2−3.JPG”の場合は[11 00 02 00 03 ダイジェスト値]となる。
【0029】
odttfは図9(d)のフォーマットである。odttfのパート名は毎回異なる名前が生成されるため、パート名をそのまま保持する。記号PLはパート名の長さであり、記号PartNameはパート名である。
【0030】
なお、図9(a)から9(d)のフォーマットを使うパートは、正規化設定が一意であり、それらの情報は保存する必要はない。
【0031】
relsはやや特殊であり図9(e)のフォーマットである。記号STはSourceTypeであり2バイト、つまり16ビットである。この16ビットの下位ビットから順に図8のビットが対応する。また、前述のとおりrelsパートは他のパートに付随したものになっており、記号PartInfoはその対応するパートのフォーマットである。
【0032】
例えば、図11に示すrelsパートに対するReference要素の場合を考える。まず、コンテントタイプからこのパートがrelsであることがわかり、先頭バイトは21である。また前述のとおり、Relationships TransformのSourceType設定は図8における6、11、8、5である。2バイト(16ビット)下位6、11、8、5ビットを立てたものは0000100101100000である(0から数えるため実際には右から6、7、9、12ビット目が1)。これを16進数で表すと[09 60]である。PartInfoは付随パートの情報が必要だが、付随パートはパート名から判別でき、“/Documents/1/FixedDocument.fdoc”である。図7(b)から、付随するパートのコンテントタイプがfdocであることがわかる。fdocは図9(a)の形式で符号化し、コンテントタイプは01である。従って、図11のReference要素を符号化すると[21 09 06 01 ダイジェスト値]である。このようにして、relsのハッシュ値および署名設定情報を保存する。
【0033】
なお、本実施形態では1つのReference要素に関する情報をエントリと呼ぶ。符号化Reference要素保持部306は0個以上のエントリから構成される。
【0034】
すべての署名対象パートに対するReference要素の作成および符号化Reference要素の作成・退避が終われば、次にObject要素のハッシュ値生成処理S407を行う。この処理の詳細を図10に示す。まず、Object、Manifest開始タグ、つまり615、616を正規化してハッシュ生成部301に入力する(1002)。途中結果はハッシュ保持部305に格納される。正規化のアルゴリズムは607に記述されており、標準XML正規化である。また、1007、1009での正規化も同様である。Reference要素退避モードがtrueでない場合(署名対象パートがn、例えば100以下だった場合)は、Reference要素はすべてRAM203上にある。従ってこれをそのまま正規化し、ハッシュ生成部に入力する(1012)。
【0035】
退避されていた場合は、符号化Reference要素保持部306の末尾に達するまでエントリをRAM203に逐次読み出して(1005)、Reference要素を復号化し(1006)、ハッシュ生成部301に入力する(1007)。
【0036】
Reference要素の復号化にはコンテントタイプ、パート名、ダイジェスト値、relsの場合はさらにSourceTypeが必要である。コンテントタイプは各エントリの1バイト目に記述されている。その他の情報についてはコンテントタイプによって異なる。図9(a)のフォーマットの場合はパート名が決まっており容易に復号化できる。図9(b)のフォーマット(fpage)の場合は、最初のfpageの場合に”1.fpage”、以降はページ番号を増やして”2.fpage”、”3.fpge”とし、固定のディレクトリ名を加えればよい。図9(c)のフォーマット(JPG、PNG、TIF)の場合は、ページ番号はこれまで出現したfpageの数、ページ内識別番号は各ページ内で1、2、3……の順に増やしていくことで復号化できる。図9(d)(odttf)の場合は2バイト目にパート名の長さがあり、3バイト目以降にパート名が含まれている。図9(e)(rels)の場合は2バイト目にSourceTypeがあり、3バイト目以降に付随するパートのフォーマットでパート名、コンテントタイプなどの情報が含まれている。これらの情報から元のReference要素を復号化することが可能である。
【0037】
なお、符号化Reference要素保持部にある情報はこの段階では破棄されずに残っている。一方RAM203に逐次読みだされた符号化Reference要素および復号化されたReference要素は、ハッシュ生成部に入力した時点で破棄する。従ってすべての復号化されたReference要素をRAM203上に持つことなく処理することが可能である。
【0038】
図12は、S1007でのハッシュ生成部301の処理を示したフローである。S1005で読み込まれた復号化されたReference要素に対するハッシュ値を求める(S1201)。そして、求められたハッシュ値に基づいて、ハッシュ保持部305に保持されているハッシュ値を更新する(S1202)。具体的には、求められたハッシュ値を、ハッシュ保持部305に保持されているハッシュ値に合成することにより、ハッシュ保持部305に保持されているハッシュ値を更新する。そして、ハッシュ値が更新された後、S1005で読み込まれた復号化されたReference要素、及びそのハッシュ値はRAM203上から削除される(S1203)。
【0039】
S1004からS1008までの処理を全ての符号化Reference要素に対して実行する。Object要素に対するハッシュ値を求めるためには、全てのReference要素を復号化する必要があるが、上記のように「逐次的に」復号化することにより、大きなRAM203を用意する必要はない。
【0040】
全てのReference要素のハッシュ生成部への入力が終わると、以降のObject、つまり617から626までを正規化して入力する(1009)。さらに生成されたハッシュ値を取得し、ハッシュ保持部305に保持されているハッシュ値を更新することにより、Object要素全体のハッシュ値を生成する(1010)。このハッシュ値は611のDigestValue要素内に格納される。これで図10の処理、すなわちS407は完了である。
【0041】
SignedInfo要素が完成すると次に署名値の生成を行う(S408)。署名値は前述のとおりSignedInfo要素のハッシュ値を暗号化処理したものである。署名値は614のSignatureValue要素内に格納される。このときのハッシュ生成アルゴリズムと暗号化アルゴリズムはSignatureMethod要素605に記述されており、SHA1とRSAである。
【0042】
最後に電子署名送信を行う。この段階で署名文書の601から616までは完成された状態であり、このまま送信する(S409)。次に、符号化Reference要素保持部306から1エントリずつ読み出し、復号化して送信する(S410)。この復号化は先ほどの方法と同じである。また、退避モードがtrueでないときは当然RAM203上にあるReference要素をそのまま送信する。最後に617から627を送信し(S411)、処理は終了である。退避モードがtrueでないときは、符号化・復号化の処理がないため、計算処理は早くなる。
【0043】
以上の処理でRAM203上に置かれるのは、Manifest要素内のReference要素が省かれたSignature要素(図6)、n個以下のReference要素、その他いくつかの少量データのみである。
【0044】
なお、本実施例では図6および図11のようにXML文書そのものの形式で保持していたが、別のツリー形式で持つことも可能である。このようなツリー構造には例えばDOM(Document Object Model)がある。
【0045】
また、本実施例ではメモリ上のReference要素のカウント数nの閾値を例として100としたが、この所定数を減らすことでさらにメモリ使用量を削減することができる。閾値を1とすれば、メモリ上に置かれるReference要素を1つのみにして署名文書を作成することができる。このような処理を行うことで、計算資源の少ない機器においても大きな電子文書に対する電子署名の付与が可能となる。
【0046】
(その他の実施例)
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)がプログラムを読み出して実行する処理である。
【特許請求の範囲】
【請求項1】
電子文書に含まれる複数のパートそれぞれの第一のハッシュ値と、前記電子文書の全体に対する第二のハッシュ値とを電子署名として外部機器に送信する情報処理装置であって、
前記複数のパートそれぞれに対して、前記パートに関連する情報と前記第一のハッシュ値とを含む参照要素を生成する参照要素生成手段と、
前記参照要素生成手段により生成された参照要素を、符号化テーブルに基づいて符号化し、記憶装置に記憶する記憶手段と、
前記記憶装置に記憶されている符号化された参照要素を逐次読み出し、前記符号化テーブルに基づいて復号化した参照要素を合成することにより、前記電子文書の全体に対する第二のハッシュ値を生成する生成手段と、
生成手段により生成された前記電子文書の全体に対する第二のハッシュ値を前記外部機器に送信し、その後、前記記憶装置に記憶されている符号化された参照要素を逐次復号化し、前記外部機器に送信する送信手段と
を有することを特徴とする情報処理装置。
【請求項2】
前記パートに関連する情報は、前記パートのパート名に関する情報であることを特徴とする請求項1に記載の情報処理装置。
【請求項3】
前記パートに関連する情報は、前記パートのハッシュ値を生成するためのハッシュ値計算アルゴリズムであることを特徴とする請求項1又は2に記載の情報処理装置。
【請求項4】
前記電子文書のパート数をカウントするカウント手段と、
前記カウント手段によりカウントされたパート数と所定数を比較することにより、前記参照要素生成手段により生成された参照要素を、前記符号化テーブルに基づいて符号化するか否かを判断する判断手段とを更に有し、
前記判断手段で前記符号化をしないと判断された場合、前記記憶手段は、前記参照要素生成手段により生成された参照要素を符号化することなしに記憶装置に記憶することを特徴とする請求項1乃至3のいずれか一項に記載の情報処理装置。
【請求項5】
コンピュータを請求項1に記載された各手段として機能させるためのプログラム。
【請求項6】
電子文書に含まれる複数のパートそれぞれの第一のハッシュ値と、前記電子文書の全体に対する第二のハッシュ値とを電子署名として外部機器に送信する情報処理方法であって、
前記複数のパートそれぞれに対して、前記パートに関連する情報と前記第一のハッシュ値とを含む参照要素を生成する参照要素生成工程と、
前記参照要素生成工程で生成された参照要素を、符号化テーブルに基づいて符号化し、記憶装置に記憶する記憶工程と、
前記記憶装置に記憶されている符号化された参照要素を逐次読み出し、前記符号化テーブルに基づいて復号化した参照要素を合成することにより、前記電子文書の全体に対する第二のハッシュ値を生成する生成工程と、
前記生成工程で生成された前記電子文書の全体に対する第二のハッシュ値を前記外部機器に送信し、その後、前記記憶装置に記憶されている符号化された参照要素を逐次復号化し、前記外部機器に送信する送信工程と
を有することを特徴とする情報処理方法。
【請求項1】
電子文書に含まれる複数のパートそれぞれの第一のハッシュ値と、前記電子文書の全体に対する第二のハッシュ値とを電子署名として外部機器に送信する情報処理装置であって、
前記複数のパートそれぞれに対して、前記パートに関連する情報と前記第一のハッシュ値とを含む参照要素を生成する参照要素生成手段と、
前記参照要素生成手段により生成された参照要素を、符号化テーブルに基づいて符号化し、記憶装置に記憶する記憶手段と、
前記記憶装置に記憶されている符号化された参照要素を逐次読み出し、前記符号化テーブルに基づいて復号化した参照要素を合成することにより、前記電子文書の全体に対する第二のハッシュ値を生成する生成手段と、
生成手段により生成された前記電子文書の全体に対する第二のハッシュ値を前記外部機器に送信し、その後、前記記憶装置に記憶されている符号化された参照要素を逐次復号化し、前記外部機器に送信する送信手段と
を有することを特徴とする情報処理装置。
【請求項2】
前記パートに関連する情報は、前記パートのパート名に関する情報であることを特徴とする請求項1に記載の情報処理装置。
【請求項3】
前記パートに関連する情報は、前記パートのハッシュ値を生成するためのハッシュ値計算アルゴリズムであることを特徴とする請求項1又は2に記載の情報処理装置。
【請求項4】
前記電子文書のパート数をカウントするカウント手段と、
前記カウント手段によりカウントされたパート数と所定数を比較することにより、前記参照要素生成手段により生成された参照要素を、前記符号化テーブルに基づいて符号化するか否かを判断する判断手段とを更に有し、
前記判断手段で前記符号化をしないと判断された場合、前記記憶手段は、前記参照要素生成手段により生成された参照要素を符号化することなしに記憶装置に記憶することを特徴とする請求項1乃至3のいずれか一項に記載の情報処理装置。
【請求項5】
コンピュータを請求項1に記載された各手段として機能させるためのプログラム。
【請求項6】
電子文書に含まれる複数のパートそれぞれの第一のハッシュ値と、前記電子文書の全体に対する第二のハッシュ値とを電子署名として外部機器に送信する情報処理方法であって、
前記複数のパートそれぞれに対して、前記パートに関連する情報と前記第一のハッシュ値とを含む参照要素を生成する参照要素生成工程と、
前記参照要素生成工程で生成された参照要素を、符号化テーブルに基づいて符号化し、記憶装置に記憶する記憶工程と、
前記記憶装置に記憶されている符号化された参照要素を逐次読み出し、前記符号化テーブルに基づいて復号化した参照要素を合成することにより、前記電子文書の全体に対する第二のハッシュ値を生成する生成工程と、
前記生成工程で生成された前記電子文書の全体に対する第二のハッシュ値を前記外部機器に送信し、その後、前記記憶装置に記憶されている符号化された参照要素を逐次復号化し、前記外部機器に送信する送信工程と
を有することを特徴とする情報処理方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【公開番号】特開2011−55269(P2011−55269A)
【公開日】平成23年3月17日(2011.3.17)
【国際特許分類】
【出願番号】特願2009−202682(P2009−202682)
【出願日】平成21年9月2日(2009.9.2)
【出願人】(000001007)キヤノン株式会社 (59,756)
【Fターム(参考)】
【公開日】平成23年3月17日(2011.3.17)
【国際特許分類】
【出願日】平成21年9月2日(2009.9.2)
【出願人】(000001007)キヤノン株式会社 (59,756)
【Fターム(参考)】
[ Back to top ]