JP2011055269A - 情報処理装置、及び情報処理方法 - Google Patents

Abstract

【課題】 電子文書に含まれる複数のパートそれぞれの第一のハッシュ値と、電子文書の全体に対する第二のハッシュ値とを電子署名として外部機器に送信する際、メモリなどの資源が乏しい環境、及び電子署名生成のための外部の機器がない環境で実現する。
【解決手段】 符号化された情報を必要なときに逐次処理していくことで、メモリ資源の消費を低減する。
【選択図】 図４

Description

本発明は、例えば電子署名として電子文書のハッシュ値を外部機器に送信する技術に関するものである。

近年、さまざまな文書が電子データとして扱われるようになり、電子データの重要性が増大している。電子データはコピーや編集が容易であることが長所であるが、逆に改竄も容易である。電子データの改竄を検出するために電子署名と呼ばれる技術があり、すでに広く使われている。

ＸＰＳ（ＸＭＬ Ｐａｐｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ、非特許文献１参照）も電子データフォーマットの一つであり、電子署名を含めることができる。ＸＰＳファイルは、「パート」と呼ばれるデータを複数集め、Ｚｉｐ形式でまとめたものとなっている。電子署名パートもＸＰＳファイル中の１つのパートとして含まれている。電子署名パートの書式はＸＭＬ電子署名仕様（非特許文献２参照）を基にしており、更にいくつかの制限を加えたものである。

ＸＰＳの電子署名を含む文書（以下、電子署名文書）は図１に示す構成になっている。電子署名文書１０１全体はＳｉｇｎａｔｕｒｅ要素となっている。Ｓｉｇｎａｔｕｒｅ要素の先頭にはＳｉｇｎｅｄＩｎｆｏ要素１０２があり、さらにその中にＲｅｆｅｒｅｎｃｅ要素（又は参照要素）１０３がある。この中にはＯｂｊｅｃｔ要素１０５のハッシュ値が格納されている。ＳｉｇｎａｔｕｒｅＶａｌｕｅ要素１０４には署名値１１１が格納されている。署名値１１１はＳｉｇｎｅｄＩｎｆｏ要素１０２のハッシュ値を、署名者の秘密鍵で暗号化したものである。Ｏｂｊｅｃｔ要素１０５はＭａｎｉｆｅｓｔ要素１０６を含み、さらにその中には通常複数個のＲｅｆｅｒｅｎｃｅ要素が含まれる。これらのＲｅｆｅｒｅｎｃｅ要素は署名の対象となるパート１つにつき１つ作成され、署名対象パートのハッシュ値が含まれている。なお、通常、ＸＰＳ文書に含まれるＸＭＬデータは名前空間宣言や名前空間プレフィックスを持つが、本明細書中では省略している。

これら各要素の関係から、パート１０９、パート１１０の情報から電子署名文書１０１を作成するには、まずＯｂｊｅｃｔ要素の作成とハッシュ値の計算を行う必要がある。その後、ＳｉｇｎｅｄＩｎｆｏ要素の作成、ＳｉｇｎｅｄＩｎｆｏ要素のハッシュ値計算および暗号化、さらにＳｉｇｎａｔｕｒｅＶａｌｕｅの作成となる。しかし、この手順では電子署名文書全体を一旦（計算書理に必要な）メモリに保持しなければならない。これは、ＳｉｇｎｅｄＩｎｆｏ要素およびＳｉｇｎａｔｕｒｅＶａｌｕｅ要素の作成にはＯｂｊｅｃｔ要素が完成する必要があるが、そのＯｂｊｅｃｔ要素がＳｉｇｎａｔｕｒｅＶａｌｕｅ要素より後ろにあるためである。仮にＯｂｊｅｃｔ要素が先頭であれば、Ｏｂｊｅｃｔ要素のハッシュ値を計算してハッシュ値のみ保持し、Ｏｂｊｅｃｔ要素そのものは先に外部機器に送信してメモリ上から破棄することができる。しかし、各要素の順序はＸＭＬ電子署名仕様およびＸＰＳ仕様で定められており変更することはできない。

このことは署名対象パートが少ない場合には大きな問題とはならないが、多いときにはメモリやハードディスクなどの記憶装置に収まらなくなる可能性がある。前述のとおり署名対象パート１つにつき１つのＲｅｆｅｒｅｎｃｅ要素が作成されてＯｂｊｅｃｔ要素内に格納されるため、署名対象パートが多いとＯｂｊｅｃｔ要素が肥大していく。特に、計算資源の少ない小型機器ではメモリや外部記憶装置に収まらなくなり、多くのパートからなるＸＰＳ文書に対して署名を付与できなくなるという問題があった。

メモリなどの計算資源が乏しいあるいは非力な環境での電子署名の作成方法としては、電子署名の作成を計算資源の豊富な外部の機器に任せる、という方法がある（例えば、特許文献１参照）。

特開２００２−０９１３０３号公報

Ｓｔａｎｄａｒｄ ＥＣＭＡ−３８８Ｏｐｅｎ ＸＭＬ Ｐａｐｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ｈｔｔｐ：／／ｗｗｗ．ｅｃｍａ−ｉｎｔｅｒｎａｔｉｏｎａｌ．ｏｒｇ／ｐｕｂｌｉｃａｔｉｏｎｓ／ｓｔａｎｄａｒｄｓ／Ｅｃｍａ−３８８．ｈｔｍ） ＸＭＬ Ｓｉｇｎａｔｕｒｅ Ｓｙｎｔａｘ ａｎｄ Ｐｒｏｃｅｓｓｉｎｇ（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００２／ＲＥＣ−ｘｍｌｄｓｉｇ−ｃｏｒｅ−２００２０２１２／）

しかしながら、外部の機器を利用する方法では署名値を計算する際に使われる秘密鍵を外部に出さなくてはならなくなるという課題がある。秘密鍵はその電子署名の署名者を判別する重要な情報であるため、外部の機器に出すことはセキュリティの面を考慮すると回避する必要がある場合がある。また、この方法では外部の機器がない状況では電子署名を作成できず、利便性が損なわれるという課題もある。そこで本発明は複数のデータ（パート）各々に対してハッシュ値を持つような形式の電子署名を、メモリなどの資源が乏しい環境、及び電子署名のための外部の機器がない環境で作成可能とすることを目的とする。

本発明の電子署名作成装置は、複数のパートにより構成される電子文書の電子署名を生成する電子署名生成装置であって、前記パートのハッシュ値と前記ハッシュ値を生成するための情報とを含むハッシュ要素を生成するハッシュ要素生成手段と、符号化テーブルに基づいて前記ハッシュ要素を符号化し、記憶装置に記憶する記憶手段と、前記記憶装置に記憶されている符号化された前記ハッシュ要素を逐次読み出し、前記符号化テーブルに基づいて読み出された前記ハッシュ要素を復号化し、復号化された前記ハッシュ要素に基づいて、既に読み出されたハッシュ要素の全てに対するハッシュ値を更新する更新手段と、前記更新されたハッシュ要素の全てに対するハッシュ値を用いた暗号化処理を行なうことにより、前記電子文書の電子署名を生成する署名生成手段と、を有することを特徴とする。

本発明により、複数のデータ（パート）各々に対するハッシュ値を持つような形式の電子署名を、メモリなどの資源が乏しい環境、及び電子署名のための外部の機器がない環境で作成可能となる。

ＸＰＳの電子署名パートの構成を示した図である。 第１の実施形態のスキャナのハードウェア構成を示したブロック図である。 第１の実施形態のソフトウェア構成を示した図である。 第１の実施形態の電子署名生成処理の全体フローを示した図である。 Ｒｅｆｅｒｅｎｃｅ要素退避処理のフローを示した図である。 第１の実施形態が生成する電子署名を示した図である。 各コンテントタイプと第１の実施形態での命名規則を示したテーブルである。 ＸＰＳの電子署名で使われるＳｏｕｒｃｅＴｙｐｅと符号を示したテーブルである。 符号化Ｒｅｆｅｒｅｎｃｅ要素のフォーマットを示した図である。 Ｏｂｊｅｃｔ要素のハッシュ値計算のフローを示した図である。 Ｒｅｆｅｒｅｎｃｅ要素の例を示した図である。 ハッシュ生成部の処理を詳細に記述したフローを示した図である。

（実施例１）
本実施形態の電子署名生成装置を構成するスキャナ装置（情報処理装置）の構成について、図２のブロック図を参照して説明する。スキャナ装置は単一の装置で実現してもよいし、必要に応じた複数の装置に各機能を分散して実現するようにしてもよい。複数の装置で構成される場合は、互いに通信可能なようにＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）やＷｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ）などで接続されている。

図２において、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）２０１は、スキャナ装置２００全体を制御する。Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（ＲＯＭ）２０２は、変更を必要としないプログラムやパラメータを格納する。Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＲＡＭ）２０３は、外部装置などから供給されるプログラムやデータを一時記憶する。記憶装置２０４は、スキャナ装置２００に設置されたハードディスク、着脱可能なフレキシブルディスク（ＦＤ）やＣｏｍｐａｃｔ Ｄｉｓｃ（ＣＤ）などの光ディスク、磁気カードなどである。一般に、記憶装置２０４はＲＡＭ２０３に比べて大容量である一方、データへのアクセスに時間がかかる。このような特性の違いから、ＲＡＭ２０３は各種計算処理（例えば、符号化、復号化処理）に必要な記憶領域を提供し、記憶装置２０４は、データを一時退避するなどの機能を提供する。スキャン部２０５は、紙文書などを読み取って電子データとして出力する。ネットワークインターフェース２０６は、外部の機器と接続するためのインターフェースである。操作部２０７は、ユーザの操作を受け、データを入力するポインティグデバイスやキーボードなどの入力装置である。システムバス２０８は、ＣＰＵ２０１や操作部２０７のスキャナ装置２００内の各ユニットを通信可能に接続する。また、スキャナ装置はＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）等の情報処理装置の一部として構成されていてもよい。

スキャナ装置２００は、スキャン部２０５で紙原稿を読み取り、そのデータをＸＰＳ文書として生成、さらに電子署名を付けてネットワーク上の別の機器に送信することが可能である。以降、この場合を例として説明する。

本実施形態のソフトウェア構成を図３に示す。ハッシュ生成部３０１は、任意のデータからそのデータのハッシュ値を計算して生成する。ハッシュ生成部３０１が行うハッシュ関数は、データの分割処理、すなわち大きなデータであってもそれを分割して逐次処理し、一定のメモリサイズでデータ全体のハッシュ値を求めることが可能なアルゴリズムを利用している。このようなアルゴリズムには例えばＭＤ５（Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ ５）やＳＨＡ１（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ１）などがある。暗号化部３０２は、図１のＳｉｇｎｅｄＩｎｆｏ要素の署名値を作成する。暗号化処理のアルゴリズムには、通常ＲＳＡやＤＳＡなどの公開鍵暗号方式が用いられる。符号化処理部３０３は、符号化テーブル３０７を用いてＲｅｆｅｒｅｎｃｅ要素（又は参照要素）を符号化して圧縮を行う。Ｒｅｆｅｒｅｎｃｅ要素は、パートに関連する情報（例えば、パート名やパートのハッシュ値を生成するためのハッシュ値計算アルゴリズム）を含む。復号化部３０４は、符号化テーブル３０７を用いて符号化Ｒｅｆｅｒｅｎｃｅ要素を復号化する。ハッシュ保持部３０５は、ハッシュ生成部３０１が生成したハッシュ値を保持するメモリであり、例えば、ＲＡＭ２０３内のメモリ領域の一部である。前述のとおりハッシュ生成部３０１は、ハッシュ計算の逐次処理に対応しており、ハッシュ保持部３０５は、その処理過程の一時データを保持、及び更新することに使用される。ハッシュ保持部３０５は、例えば、ＲＡＭ２０３内のメモリ領域の一部である。符号化Ｒｅｆｅｒｅｎｃｅ要素保持部３０６は、符号化処理部３０３によって符号化されたＲｅｆｅｒｅｎｃｅ要素を保持するメモリであり、例えば、記憶装置２０４内のメモリ領域の一部である。ＸＰＳ文書生成部３０８は、電子署名パート以外のＸＰＳ文書パートを生成し、更に電子署名パートと組み合わせて電子署名付きＸＰＳ文書を生成する。ＸＰＳ文書生成部３０８は、ＯＣＲ機能、グラフィカルオブジェクト検出機能（ベクトル図形検出機能）や画像抽出機能等を有し、更に、抽出された文字列や画像に対してＸＰＳ文書パートを生成する。ＸＭＬ正規化部３０９は、ＸＭＬ文書を正規化する。ＸＭＬの正規化とは、ＸＭＬ文書の書式を統一するものであり、ハッシュ値の計算の前処理として使用されることがある。

ＸＰＳ文書生成部３０８の詳細について説明する。ＸＰＳ文書生成部３０８は、スキャン部２０５によって読み取られた紙原稿のデジタルデータからＸＰＳ文書を構成するパートを生成する。また、電子署名を付与する場合には電子署名に関する設定情報も出力する。生成されるパートの種類（コンテントタイプ）の一例を図７（ａ）に示す。コンテントタイプの識別子はＵＲＩの形式であり、図７（ａ）の３列目に示されている。ただし、本文書では便宜上１列目に示すコンテントタイプ略称を用いて説明する。この略称は説明の簡略化のためであり、実際のコンテントタイプの識別には常にＵＲＩが使われる。また、ｆｄｏｃやｘａｍｌのように、ＵＲＩが“ｘｍｌ”で終わるものはＸＭＬ形式である。

ＸＰＳでは任意のパート名を使用することが可能だが、ＸＰＳ文書生成部３０８は、図７（ｂ）の命名規則に従ってパート名を生成する。ｆｄｏｃやｆｄｓｅｑなどは１つのＸＰＳ文書につき１つのみ生成され、パート名は毎回同じものになる。ｆｐａｇｅはページ毎に１つ生成され、“１．ｆｐａｇｅ”、“２．ｆｐａｇｅ”のようにページ番号を持つ名前となる。ＪＰＧ、ＰＮＧ、ＴＩＦは画像ファイルであり、各ページに含まれる画像ごとに１つずつ生成される。名前はページ番号とページ内画像番号とからなる名前を持つ。例えば、１ページ目の最初のＪＰＧの画像データは“１−１．ＪＰＧ”、２ページ目の３番目のＰＮＧの画像データは“２−３．ＰＮＧ”などとなる。また、ｆｐａｇｅと画像データのディレクトリ名はそれぞれ固定のものである。ｏｄｔｔｆは１つのＸＰＳ文書につき１つだが、パート名はランダムな文字列であり文書毎に異なる。

ｒｅｌｓは、やや特殊な規則を持つ。ｒｅｌｓは通常他の特定のパートに付随するものであり、各ｆｄｏｃ、ｆｄｓｅｑ、ｆｐａｇｅパートに対して１つ生成される。パート名は”｛付随するパートのあるディレクトリ｝／＿ｒｅｌｓ／｛付随するパートのファイル名｝．ｒｅｌｓ”という名前になる。例えば”／Ｄｏｃｕｍｅｎｔｓ／１／Ｐａｇｅｓ／１．ｆｐａｇｅ”という名前のパートに対するｒｅｌｓパートの名前は”／Ｄｏｃｕｍｅｎｔｓ／１／Ｐａｇｅｓ／＿ｒｅｌｓ／１．ｆｐａｇｅ．ｒｅｌｓ”となる。また、他のパートに付随しないｒｅｌｓパートも文書に必ず１つ含まれている。これはＰａｃｋａｇｅＲｅｌａｔｉｏｎｓｈｉｐパートと呼ばれ、パート名は”／＿ｒｅｌｓ／．ｒｅｌｓ”である。なお、本実施形態ではこのＰａｃｋａｇｅＲｅｌａｔｉｏｎｓｈｉｐのことをｐｒｅｌと呼び、その他のｒｅｌｓパートとは区別する。

また、ＸＭＬ形式の文書の場合は、さらに正規化設定も出力される。正規化にはいくつかの方法があるが、ＸＰＳ文書生成部３０８は、ｒｅｌｓとｐｒｅｌ以外には正規化の設定は行わない。ｒｅｌｓとｐｒｅｌについてはＲｅｌａｔｉｏｎｓｈｉｐｓ Ｔｒａｎｓｆｏｒｍと標準ＸＭＬ正規化の２つが指定されるのが一般的であり、ＸＰＳ文書生成部３０８もこれに従う。Ｒｅｌａｔｉｏｎｓｈｉｐｓ ＴｒａｎｓｆｏｒｍはＸＰＳ仕様に含まれるアルゴリズムであり、さらにいくつかのオプションを持つ。このオプションはＳｏｕｒｃｅＴｙｐｅと呼ばれ、図８に示す１３個のオプションを１つ以上選択することが可能であるが、ｐｒｅｌは常に図８の１、５、１２がセットされている。標準ＸＭＬ正規化は、Ｗ３Ｃ標準の正規化である（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｍｌ−ｃ１４ｎ）。正規化のアルゴリズムおよびＳｏｕｒｃｅＴｙｐｅはすべてＵＲＩ形式で識別される。

以上のように、ＸＰＳ文書生成部３０８は、パート名、パートのデータ、コンテントタイプを出力し、さらにｒｅｌｓやｐｒｅｌの場合は正規化設定（ＳｏｕｒｃｅＴｙｐｅ含む）も出力する。また、ｆｐａｇｅと画像データは紙原稿を１枚スキャンする毎に生成され、さらに各ページにおいては最初にｆｐａｇｅが出力され、その後に画像データが生成される。従って、“１．ｆｐａｇｅ”より先に“２．ｆｐａｇｅ”が生成されたり、“２．ｆｐａｇｅ”より先に“２−１．ＪＰＧ”が生成されたりすることはない。

本実施形態の電子署名生成装置が、以上の規則で生成されるＸＰＳ文書の電子署名を生成する処理全体の流れを図４に示す。まず署名文書となるＳｉｇｎａｔｕｒｅ要素の初期設定を行う（Ｓ４０２）。この初期設定の結果を図６に示す。ＸＰＳ電子署名の書式にほぼ従っているが、ＤｉｇｅｓｔＶａｌｕｅ要素６１１、ＳｉｇｎａｔｕｒｅＶａｌｕｅ要素６１４、およびＭａｎｉｆｅｓｔ要素（６１６〜６１７）は空である。

Ｏｂｊｅｃｔ要素はＭａｎｉｆｅｓｔ要素の他にＳｉｇｎａｔｕｒｅＰｒｏｐｅｒｔｉｅｓ要素（６１８〜６２５）等が含まれている。これらの属性はＸＰＳ仕様およびＸＭＬ Ｓｉｇｎａｔｕｒｅ仕様に従ったものであり、詳細については本実施形態では説明は省略する。 次に、ＸＰＳ文書生成部３０８が生成した全てのパートに対して、Ｓ４０３からＳ４０６の間の処理、すなわち、Ｓ４０４、Ｓ４０５の処理を行う。まず、パートのハッシュ生成部３０１を使ってハッシュ値を求める（Ｓ４０４）。ハッシュのアルゴリズムはＳＨＡ１である。パート名・コンテントタイプ・ハッシュ値、ｒｅｌｓの場合はさらに正規化設定の情報からＲｅｆｅｒｅｎｃｅ要素を生成して保持する（Ｓ４０５）。Ｓ４０５の詳細を図５に示す。まず、パートの署名設定情報とハッシュ値からＲｅｆｅｒｅｎｃｅ要素を生成する（Ｓ５０２）。

Ｒｅｆｅｒｅｎｃｅ要素の例を図１１に示す。図１１からもわかるように、Ｒｅｆｅｒｅｎｃｅ要素には、ハッシュ値と、そのハッシュ値を生成するための情報（例えばハッシュ値計算アルゴリズム）とを含む。Ｒｅｆｅｒｅｎｃｅ要素はハッシュ要素とも呼ばれる。１１０１のＵＲＩ属性が署名対象パートのパート名とコンテントタイプを表しており、‘？’で区切られている。つまり、パート名は“／Ｄｏｃｕｍｅｎｔｓ／１／＿ｒｅｌｓ／ＦｉｘｅｄＤｏｃｕｍｅｎｔ．ｆｄｏｃ．ｒｅｌｓ”であり、コンテントタイプはｒｅｌｓである。Ｔｒａｎｓｆｏｒｍ要素（１１０３、１１０９）は正規化設定である。正規化アルゴリズムはＡｌｇｏｒｉｔｈｍ属性で指定されており、それぞれＲｅｌａｔｉｏｎｓｈｉｐｓ Ｔｒａｎｓｆｏｒｍと標準ＸＭＬ正規化である。１１０４〜１１０７はＳｏｕｃｅＴｙｐｅであり、図８における６、１１、８、５が指定されている。ハッシュ値計算のアルゴリズムはＤｉｇｅｓｔＭｅｔｈｏｄ要素（１１１１）で指定されており、ＳＨＡ１である。

次に、Ｒｅｆｅｒｅｎｃｅ要素退避モードになっているかを確認する（Ｓ５０３）。Ｒｅｆｅｒｅｎｃｅ要素退避モードは、ユーザーが任意に設定する。例えば、ユーザーは情報処理単位でＲｅｆｅｒｅｎｃｅ要素退避モードか否かを設定しても良いし、或いは、署名要素対象文書単位で設定しても良い。Ｒｅｆｅｒｅｎｃｅ退避モードでなければ保持しているＲｅｆｅｒｅｎｃｅ要素（又はパート数）の数と所定数ｎ（例えば、１００個）とを比較・判断する（Ｓ５０５）。ｎ個未満（又は所定数以下）であれば生成したＲｅｆｅｒｅｎｃｅ要素をそのままメモリ中に保持しておき、処理を終了する。Ｒｅｆｅｒｅｎｃｅ要素の個数がｎ個以上の場合はＲｅｆｅｒｅｎｃｅ要素退避モードをｔｒｕｅにする。更に、すでに保持しているＲｅｆｅｒｅｎｃｅ要素すべてを符号化し、符号化Ｒｅｆｅｒｅｎｃｅ要素保持部３０６に記憶（退避）する（Ｓ５０７）。また、今回生成されたＲｅｆｅｒｅｎｃｅ要素も同様に符号化して記憶（退避）する（Ｓ５０８、Ｓ５０９）。Ｓ５０３において、Ｒｅｆｅｒｅｎｃｅ要素退避モードが、ｔｒｕｅの場合（是の場合）も生成されたＲｅｆｅｒｅｎｃｅ要素を符号化して符号化Ｒｅｆｅｒｅｎｃｅ要素保持部３０６に記憶（退避）する。Ｓ５０７における退避処理はＳ５０８およびＳ５０９の処理と同じである。符号化は符号化処理部３０３が、符号化テーブル３０７を用いて行う。符号化テーブルには図７（ａ）のテーブルと図７（ｂ）のテーブルに示すパート名生成規則が含まれている。

符号化はそのパートのコンテントタイプによって異なる方法となる。ｆｄｏｃ・ｆｄｓｅｑ・ｏｔｆ・ｃｏｒｅｐｒｏｐ・ｘａｍｌ・ｐｒｅｌの場合は、図９（ａ）に示すフォーマットで保存する。記号Ｃはコンテントタイプであり、図７（ａ）の符号（１バイト）が用いられる。ＳＨＡ１の場合は２０バイトである。例えば、ｆｄｏｃの場合は［０１ ダイジェスト値］となる。これらのパートのパート名は一意であるため保存する必要はない。

ｆｐａｇｅは図９（ｂ）のフォーマットで保存する。記号Ｐはページ番号であり２バイト（１６ビット）である。従って最大６５５３５ページとなる。ＪＰＧ・ＰＮＧ・ＴＩＦは図９（ｃ）のフォーマットで保存する。記号Ｐはページ番号、記号Ｎはページ内識別番号であり、それぞれ２バイトである。例えば”２−３．ＪＰＧ”の場合は［１１ ００ ０２ ００ ０３ ダイジェスト値］となる。

ｏｄｔｔｆは図９（ｄ）のフォーマットである。ｏｄｔｔｆのパート名は毎回異なる名前が生成されるため、パート名をそのまま保持する。記号ＰＬはパート名の長さであり、記号ＰａｒｔＮａｍｅはパート名である。

なお、図９（ａ）から９（ｄ）のフォーマットを使うパートは、正規化設定が一意であり、それらの情報は保存する必要はない。

ｒｅｌｓはやや特殊であり図９（ｅ）のフォーマットである。記号ＳＴはＳｏｕｒｃｅＴｙｐｅであり２バイト、つまり１６ビットである。この１６ビットの下位ビットから順に図８のビットが対応する。また、前述のとおりｒｅｌｓパートは他のパートに付随したものになっており、記号ＰａｒｔＩｎｆｏはその対応するパートのフォーマットである。

例えば、図１１に示すｒｅｌｓパートに対するＲｅｆｅｒｅｎｃｅ要素の場合を考える。まず、コンテントタイプからこのパートがｒｅｌｓであることがわかり、先頭バイトは２１である。また前述のとおり、Ｒｅｌａｔｉｏｎｓｈｉｐｓ ＴｒａｎｓｆｏｒｍのＳｏｕｒｃｅＴｙｐｅ設定は図８における６、１１、８、５である。２バイト（１６ビット）下位６、１１、８、５ビットを立てたものは００００１００１０１１０００００である（０から数えるため実際には右から６、７、９、１２ビット目が１）。これを１６進数で表すと［０９ ６０］である。ＰａｒｔＩｎｆｏは付随パートの情報が必要だが、付随パートはパート名から判別でき、“／Ｄｏｃｕｍｅｎｔｓ／１／ＦｉｘｅｄＤｏｃｕｍｅｎｔ．ｆｄｏｃ”である。図７（ｂ）から、付随するパートのコンテントタイプがｆｄｏｃであることがわかる。ｆｄｏｃは図９（ａ）の形式で符号化し、コンテントタイプは０１である。従って、図１１のＲｅｆｅｒｅｎｃｅ要素を符号化すると［２１ ０９ ０６ ０１ ダイジェスト値］である。このようにして、ｒｅｌｓのハッシュ値および署名設定情報を保存する。

なお、本実施形態では１つのＲｅｆｅｒｅｎｃｅ要素に関する情報をエントリと呼ぶ。符号化Ｒｅｆｅｒｅｎｃｅ要素保持部３０６は０個以上のエントリから構成される。

すべての署名対象パートに対するＲｅｆｅｒｅｎｃｅ要素の作成および符号化Ｒｅｆｅｒｅｎｃｅ要素の作成・退避が終われば、次にＯｂｊｅｃｔ要素のハッシュ値生成処理Ｓ４０７を行う。この処理の詳細を図１０に示す。まず、Ｏｂｊｅｃｔ、Ｍａｎｉｆｅｓｔ開始タグ、つまり６１５、６１６を正規化してハッシュ生成部３０１に入力する（１００２）。途中結果はハッシュ保持部３０５に格納される。正規化のアルゴリズムは６０７に記述されており、標準ＸＭＬ正規化である。また、１００７、１００９での正規化も同様である。Ｒｅｆｅｒｅｎｃｅ要素退避モードがｔｒｕｅでない場合（署名対象パートがｎ、例えば１００以下だった場合）は、Ｒｅｆｅｒｅｎｃｅ要素はすべてＲＡＭ２０３上にある。従ってこれをそのまま正規化し、ハッシュ生成部に入力する（１０１２）。

退避されていた場合は、符号化Ｒｅｆｅｒｅｎｃｅ要素保持部３０６の末尾に達するまでエントリをＲＡＭ２０３に逐次読み出して（１００５）、Ｒｅｆｅｒｅｎｃｅ要素を復号化し（１００６）、ハッシュ生成部３０１に入力する（１００７）。

Ｒｅｆｅｒｅｎｃｅ要素の復号化にはコンテントタイプ、パート名、ダイジェスト値、ｒｅｌｓの場合はさらにＳｏｕｒｃｅＴｙｐｅが必要である。コンテントタイプは各エントリの１バイト目に記述されている。その他の情報についてはコンテントタイプによって異なる。図９（ａ）のフォーマットの場合はパート名が決まっており容易に復号化できる。図９（ｂ）のフォーマット（ｆｐａｇｅ）の場合は、最初のｆｐａｇｅの場合に”１．ｆｐａｇｅ”、以降はページ番号を増やして”２．ｆｐａｇｅ”、”３．ｆｐｇｅ”とし、固定のディレクトリ名を加えればよい。図９（ｃ）のフォーマット（ＪＰＧ、ＰＮＧ、ＴＩＦ）の場合は、ページ番号はこれまで出現したｆｐａｇｅの数、ページ内識別番号は各ページ内で１、２、３……の順に増やしていくことで復号化できる。図９（ｄ）（ｏｄｔｔｆ）の場合は２バイト目にパート名の長さがあり、３バイト目以降にパート名が含まれている。図９（ｅ）（ｒｅｌｓ）の場合は２バイト目にＳｏｕｒｃｅＴｙｐｅがあり、３バイト目以降に付随するパートのフォーマットでパート名、コンテントタイプなどの情報が含まれている。これらの情報から元のＲｅｆｅｒｅｎｃｅ要素を復号化することが可能である。

なお、符号化Ｒｅｆｅｒｅｎｃｅ要素保持部にある情報はこの段階では破棄されずに残っている。一方ＲＡＭ２０３に逐次読みだされた符号化Ｒｅｆｅｒｅｎｃｅ要素および復号化されたＲｅｆｅｒｅｎｃｅ要素は、ハッシュ生成部に入力した時点で破棄する。従ってすべての復号化されたＲｅｆｅｒｅｎｃｅ要素をＲＡＭ２０３上に持つことなく処理することが可能である。

図１２は、Ｓ１００７でのハッシュ生成部３０１の処理を示したフローである。Ｓ１００５で読み込まれた復号化されたＲｅｆｅｒｅｎｃｅ要素に対するハッシュ値を求める（Ｓ１２０１）。そして、求められたハッシュ値に基づいて、ハッシュ保持部３０５に保持されているハッシュ値を更新する（Ｓ１２０２）。具体的には、求められたハッシュ値を、ハッシュ保持部３０５に保持されているハッシュ値に合成することにより、ハッシュ保持部３０５に保持されているハッシュ値を更新する。そして、ハッシュ値が更新された後、Ｓ１００５で読み込まれた復号化されたＲｅｆｅｒｅｎｃｅ要素、及びそのハッシュ値はＲＡＭ２０３上から削除される（Ｓ１２０３）。

Ｓ１００４からＳ１００８までの処理を全ての符号化Ｒｅｆｅｒｅｎｃｅ要素に対して実行する。Ｏｂｊｅｃｔ要素に対するハッシュ値を求めるためには、全てのＲｅｆｅｒｅｎｃｅ要素を復号化する必要があるが、上記のように「逐次的に」復号化することにより、大きなＲＡＭ２０３を用意する必要はない。

全てのＲｅｆｅｒｅｎｃｅ要素のハッシュ生成部への入力が終わると、以降のＯｂｊｅｃｔ、つまり６１７から６２６までを正規化して入力する（１００９）。さらに生成されたハッシュ値を取得し、ハッシュ保持部３０５に保持されているハッシュ値を更新することにより、Ｏｂｊｅｃｔ要素全体のハッシュ値を生成する（１０１０）。このハッシュ値は６１１のＤｉｇｅｓｔＶａｌｕｅ要素内に格納される。これで図１０の処理、すなわちＳ４０７は完了である。

ＳｉｇｎｅｄＩｎｆｏ要素が完成すると次に署名値の生成を行う（Ｓ４０８）。署名値は前述のとおりＳｉｇｎｅｄＩｎｆｏ要素のハッシュ値を暗号化処理したものである。署名値は６１４のＳｉｇｎａｔｕｒｅＶａｌｕｅ要素内に格納される。このときのハッシュ生成アルゴリズムと暗号化アルゴリズムはＳｉｇｎａｔｕｒｅＭｅｔｈｏｄ要素６０５に記述されており、ＳＨＡ１とＲＳＡである。

最後に電子署名送信を行う。この段階で署名文書の６０１から６１６までは完成された状態であり、このまま送信する（Ｓ４０９）。次に、符号化Ｒｅｆｅｒｅｎｃｅ要素保持部３０６から１エントリずつ読み出し、復号化して送信する（Ｓ４１０）。この復号化は先ほどの方法と同じである。また、退避モードがｔｒｕｅでないときは当然ＲＡＭ２０３上にあるＲｅｆｅｒｅｎｃｅ要素をそのまま送信する。最後に６１７から６２７を送信し（Ｓ４１１）、処理は終了である。退避モードがｔｒｕｅでないときは、符号化・復号化の処理がないため、計算処理は早くなる。

以上の処理でＲＡＭ２０３上に置かれるのは、Ｍａｎｉｆｅｓｔ要素内のＲｅｆｅｒｅｎｃｅ要素が省かれたＳｉｇｎａｔｕｒｅ要素（図６）、ｎ個以下のＲｅｆｅｒｅｎｃｅ要素、その他いくつかの少量データのみである。

なお、本実施例では図６および図１１のようにＸＭＬ文書そのものの形式で保持していたが、別のツリー形式で持つことも可能である。このようなツリー構造には例えばＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）がある。

また、本実施例ではメモリ上のＲｅｆｅｒｅｎｃｅ要素のカウント数ｎの閾値を例として１００としたが、この所定数を減らすことでさらにメモリ使用量を削減することができる。閾値を１とすれば、メモリ上に置かれるＲｅｆｅｒｅｎｃｅ要素を１つのみにして署名文書を作成することができる。このような処理を行うことで、計算資源の少ない機器においても大きな電子文書に対する電子署名の付与が可能となる。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (6)

1. 電子文書に含まれる複数のパートそれぞれの第一のハッシュ値と、前記電子文書の全体に対する第二のハッシュ値とを電子署名として外部機器に送信する情報処理装置であって、
   前記複数のパートそれぞれに対して、前記パートに関連する情報と前記第一のハッシュ値とを含む参照要素を生成する参照要素生成手段と、
   前記参照要素生成手段により生成された参照要素を、符号化テーブルに基づいて符号化し、記憶装置に記憶する記憶手段と、
   前記記憶装置に記憶されている符号化された参照要素を逐次読み出し、前記符号化テーブルに基づいて復号化した参照要素を合成することにより、前記電子文書の全体に対する第二のハッシュ値を生成する生成手段と、
   生成手段により生成された前記電子文書の全体に対する第二のハッシュ値を前記外部機器に送信し、その後、前記記憶装置に記憶されている符号化された参照要素を逐次復号化し、前記外部機器に送信する送信手段と
   を有することを特徴とする情報処理装置。
2. 前記パートに関連する情報は、前記パートのパート名に関する情報であることを特徴とする請求項１に記載の情報処理装置。
3. 前記パートに関連する情報は、前記パートのハッシュ値を生成するためのハッシュ値計算アルゴリズムであることを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記電子文書のパート数をカウントするカウント手段と、
   前記カウント手段によりカウントされたパート数と所定数を比較することにより、前記参照要素生成手段により生成された参照要素を、前記符号化テーブルに基づいて符号化するか否かを判断する判断手段とを更に有し、
   前記判断手段で前記符号化をしないと判断された場合、前記記憶手段は、前記参照要素生成手段により生成された参照要素を符号化することなしに記憶装置に記憶することを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
5. コンピュータを請求項１に記載された各手段として機能させるためのプログラム。
6. 電子文書に含まれる複数のパートそれぞれの第一のハッシュ値と、前記電子文書の全体に対する第二のハッシュ値とを電子署名として外部機器に送信する情報処理方法であって、
   前記複数のパートそれぞれに対して、前記パートに関連する情報と前記第一のハッシュ値とを含む参照要素を生成する参照要素生成工程と、
   前記参照要素生成工程で生成された参照要素を、符号化テーブルに基づいて符号化し、記憶装置に記憶する記憶工程と、
   前記記憶装置に記憶されている符号化された参照要素を逐次読み出し、前記符号化テーブルに基づいて復号化した参照要素を合成することにより、前記電子文書の全体に対する第二のハッシュ値を生成する生成工程と、
   前記生成工程で生成された前記電子文書の全体に対する第二のハッシュ値を前記外部機器に送信し、その後、前記記憶装置に記憶されている符号化された参照要素を逐次復号化し、前記外部機器に送信する送信工程と
   を有することを特徴とする情報処理方法。

Images