JP2007060594A - 情報処理方法及び装置、並びにコンピュータプログラム及びコンピュータ可読記憶媒体 - Google Patents

Abstract

【課題】 被署名データの受信前、或いは受信している途中で署名の検証処理を可能とする。
【解決手段】 送受信部１３２で署名データと、被署名データを構成する複数の部分被署名データのうち、少なくとも１つの部分被署名データを受信する。署名検証部１３４で前記署名データ、及び部分被署名データを用いて署名を検証する。制御部１３１で前記署名検証部１３４による署名検証結果に応じて、送受信部１３２、出力部１３５、操作部１３６のいずれかを制御する。
【選択図】 図１３

Description

本発明は、署名検証処理に関するものである。

近年、コンピュータとそのネットワークの急速な発達及び普及により、文字データ、画像データ、音声データなど、多種の情報がデジタル化されている。

デジタルデータは、経年変化などによる劣化がなく、いつまでも完全な状態で保存できる一方、容易に複製や編集・加工を施すことが可能である。

こうしたデジタルデータの複製、編集、加工はユーザにとって大変有益である反面、デジタルデータの保護が大きな問題となっている。そのため、セキュリティ技術は急速に重要性を増している。

そこで、送信されてきたデータが改ざんされたかどうかを受信者が検出するために、改ざん防止用の付加データを検証する方式としてデジタル署名という技術が提案されている。デジタル署名技術は、データ改ざんだけではなく、インターネット上でのなりすまし、否認などを防止する効果も持ち合わせている。

デジタル署名技術を、予め、デジタルデータに適用して送信し、当該（デジタル署名が付加された）デジタルデータを受信した際に、適用されているデジタル署名の検証処理を実行する。そして、検証処理が失敗した場合には、受信したデジタルデータを破棄するようなシステムが提案されている。（特許文献１参照）
特許文献１によれば、一旦、デジタル署名の検証が失敗した（改竄されている可能性のある）デジタルデータが、再び再利用（編集、或いは転送など）されることを防止することが可能となる。
特開２００３−１３２０２８号公報

しかしながら、従来技術によれば、デジタルデータが改竄されているか否かは、（署名生成の対象となった）被署名データの全てを受信した後に検証可能となるが、被署名データを受信する前、或いは受信している途中で検証することは困難であった。このため、たとえ、デジタルデータが偽造されていたり、或いは、被署名データが改竄されていたとしても、これらを判断するためには、全ての被署名データを受信する必要があり、効率的ではなかった。

本発明は、かかる問題点に鑑みなされたものであり、被署名データの受信前、或いは受信している途中で、デジタルデータの正当性を検証可能とする技術を提供することを目的とする。

上記課題を解決するため、本発明の情報処理装置は、署名データと、被署名データを構成する複数の部分被署名データのうち、少なくとも１つの部分被署名データを受信する受信手段と、前記署名データ、及び部分被署名データを用いて署名を検証する署名検証手段と、前記署名検証手段による署名検証結果に応じて、前記受信手段を制御する制御手段を有することを特徴とする。

また、本発明の情報処理装置は、分割された部分データが所定の順を有する部分データを入力する入力手段と、第１の部分データの検証データと、前記第１の部分データの次の順である第２の部分データとから、前記第２の部分データの検証データを生成する生成手段と、前記第２の部分データと前記第２の部分データの検証データとを送信する送信手段を有することを特徴とする。

本発明によれば、被署名データの受信前、或いは受信している途中で署名の検証処理が可能である。また、検証処理に応じて機器の制御を実行可能となり、効率的に電子データを通信できる。

まず、デジタル署名、ハッシュ関数、公開鍵暗号、及び公開鍵認証基盤について簡単に説明する。

［デジタル署名］
まず、デジタル署名について説明する。図１０は、署名作成処理および署名検証処理を表す模式図であり，この図を基に説明を行う。デジタル署名データ生成にはハッシュ関数と公開鍵暗号とが用いられる。これは、秘密鍵をＫｓ（１０６）、公開鍵をＫｐ（１０８）とすれば、送信者は、入力データＭ（１０１）にハッシュ処理１０２を施して固定長データであるダイジェストＨ（Ｍ）（番号１０３３）を算出する。その後、秘密鍵Ｋｓで固定長データＨ（Ｍ）に変換処理１００４を施してデジタル署名データＳ（１００５）を作成し、その後、デジタル署名データＳと入力データＭとを受信者に送信する。

受信者は、検証処理１０１２において，デジタル署名データＳ（１０１０）を公開鍵Ｋｐ（１０１１）で変換（復号）処理１００７を施したデータと、入力データＭ（１００７）にハッシュ処理１００８を施したデータ１００９とが一致するかどうか検証する。そして、上記検証の結果（１０１３）が一致していないならば、データＭの改ざんが行われたことを検出できる。

デジタル署名にはＲＳＡ、ＤＳＡ（詳細は後述）などの公開鍵暗号方式が用いられている。これらのデジタル署名の安全性は、秘密鍵を所有者以外のエンティティが、署名を偽造、もしくは秘密鍵を解読することが計算的に困難であることに基づいている。

［ハッシュ関数］
次に、ハッシュ関数について説明する。ハッシュ関数は署名対象データを非可逆に圧縮して署名付与処理時間を短縮するためにデジタル署名処理とともに利用される。つまり、ハッシュ関数は任意の長さのデータＭに処理を行い、一定の長さの出力データを生成する機能を持っている。ここで、出力Ｈ（Ｍ）を平文データＭのハッシュデータと呼ぶ。

特に、一方向性ハッシュ関数は、データＭを与えた時、Ｈ（Ｍ’）＝Ｈ（Ｍ）となる平文データＭ’の算出が計算量的に困難であるという性質を持っている。上記一方向性ハッシュ関数としてはＭＤ２、ＭＤ５、ＳＨＡ−１などの標準的なアルゴリズムが存在する。

［公開鍵暗号］
次に、公開鍵暗号について説明する。公開鍵暗号は２つの異なる鍵を利用し、片方の鍵で暗号処理したデータは、もう片方の鍵でしか復号処理できないという性質を持っている。上記２つの鍵のうち、一方の鍵は公開鍵と呼ばれ、広く公開するようにしている。また、もう片方の鍵は秘密鍵と呼ばれ、本人のみが持つ鍵である。

公開鍵暗号方式を用いたデジタル署名としては、ＲＳＡ署名、ＤＳＡ署名、Ｓｃｈｎｏｒｒ署名などが挙げられる。ここでは例としてＲＳＡ署名と、ＤＳＡ署名を説明する。

［ＲＳＡ署名］
まず、ＲＳＡ署名について説明する。素数ｐ、ｑを生成しｎ＝ｐｑとおく。λ（ｎ）をｐ−１とｑ−１の最小公倍数とする。λ（ｎ）と素な適当なｅを選び，ｄ＝１／ｅ（ｍｏｄ λ（ｎ））とおく。公開鍵をｅおよびｎとし、秘密鍵をｄとする。また、Ｈ（）をハッシュ関数とする。
［ＲＳＡ署名作成］ 文書Ｍに対する署名の作成手順
ｓ：＝Ｈ（Ｍ）＾ｄ（ｍｏｄ ｎ）を署名データとする。
［ＲＳＡ署名検証］ 文書Ｍに対する署名（ｓ、Ｔ）の検証手順
（Ｍ）＝ｓ＾ｅ（ｍｏｄ ｎ）かどうか検証する。

［ＤＳＡ署名］
次に、ＤＳＡ署名について説明する。ｐ、ｑを素数とし、ｐ−１はｑを割り切るとする。ｇをＺ＿ｐ＊（位数ｐの巡回群Ｚ＿ｐから０を省いた乗法群）から任意に選択した、位数ｑの元（生成元）とする。Ｚ＿ｐ＊から任意に選択したｘを秘密鍵とし、それに対する公開鍵ｙをｙ：＝ｇｘ ｍｏｄ ｐとおく。Ｈ（）をハッシュ関数とする。
［ＤＳＡ署名作成］ 文書Ｍに対する署名の作成手順
１）αをＺ＿ｑから任意に選択し、Ｔ：＝（ｇα ｍｏｄ ｐ）ｍｏｄ ｑとおく。
２）ｃ：＝Ｈ（Ｍ）とおく。
３）ｓ：＝α―１（ｃ＋ｘＴ）ｍｏｄ ｑとおき、（ｓ、Ｔ）を署名データとする。
［ＤＳＡ署名検証］ 文書Ｍに対する署名（ｓ、Ｔ）の検証手順
Ｔ＝（ｇｈ（Ｍ）ｓ＾−１ ｙ Ｔｓ＾−１ ｍｏｄ ｐ）ｍｏｄ ｑかどうか検証する。

［公開鍵認証基盤］
次に、公開鍵認証基盤について説明する。クライアント・サーバ間の通信においてサーバのリソースにアクセスする際には、利用者認証が必要であるが、その手段の一つとしてＩＴＵ−Ｕ勧告のＸ．５０９等の公開鍵証明書がよく用いられている。公開鍵証明書は公開鍵とその利用者との結びつけを保証するデータであり、認証機関と呼ばれる信用のおける第３者機関によるデジタル署名が施されたものである。例えば、ブラウザで実装されているＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）を用いた利用者認証方式は、ユーザの提示してきた公開鍵証明書内に含まれる公開鍵に対応する秘密鍵をユーザが持っているかどうか確認することで行われる。

公開鍵証明書は認証機関による署名が施されていることで、公開鍵証明書内に含まれているユーザやサーバの公開鍵を信頼することができる。そのため、認証機関が署名作成のために用いられる秘密鍵が漏洩もしくは脆弱になった場合、この認証機関から発行されたすべての公開鍵証明書は無効になってしまう。認証機関によっては膨大な数の公開鍵証明書が管理されているため、管理コストを下げるためにさまざまな提案が行われている。後述する本発明によれば、発行する証明書数を抑え、かつ公開鍵リポジトリとしてのサーバアクセスを軽減する効果がある。

公開鍵証明書の一例であるＩＴＵ−Ｕ勧告Ｘ．５０９ｖ．３では被署名データとして証明対象となるエンティティ（Ｓｕｂｊｅｃｔ）のＩＤおよび公開鍵情報が含まれている。これらの被署名データにハッシュ関数を施したダイジェストに対して前述したＲＳＡアルゴリズムなどの署名演算により署名データが生成される。

また、被署名データにはｅｘｔｅｎｓｉｏｎｓというオプショナルなフィールドが設けられ、アプリケーション又はプロトコル独自の新しい拡張データを含ませることが可能である。図１１、Ｘ．５０９ｖ．３で規定されるフォーマットを示しているおり、以下、それぞれのフィールドに表示される情報を説明する。ｖｅｒｓｉｏｎはＸ．５０９のバージョンが入る。このフィールドはオプショナルであり、省略された場合はｖ１を表わす。ｓｅｒｉａｌＮｕｍｂｅは認証局がユニークに割り当てるシリアル番号が入る。ｓｉｇｎａｔｕｒｅは公開鍵証明書の署名方式が入る。ｉｓｓｕｅｒは公開鍵証明書の発行者である認証局のＸ．５００識別名が入る。ｖａｌｉｄｉｔｙは公開鍵の有効期限（開始日時と終了日時）が入る。ｓｕｂｊｅｃｔは本証明書内に含まれる公開鍵に対応する秘密鍵の所有者のＸ．５００識別名が入る。ｓｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏは証明する公開鍵が入る。ｉｓｓｕｅｒＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒ及びｓｕｂｊｅｃｔＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒはｖ２から追加されたオプショナルなフィールドであり、それぞれ認証局の固有識別情報、所有者の固有識別情報が入る。ｅｘｔｅｎｔｉｏｎｓはｖ３で追加されたオプショナルなフィールドであり、拡張型（ｅｘｔｎＩｄ）、拡張値（ｅｘｔｎＶａｌｕｅ）及びクリティカルビット（ｃｒｉｔｉｃａｌ）の３つ組の集合が入る。ｖ３拡張フィールドはＸ．５０９で定められた標準の拡張型だけでなく、独自の新しい拡張型も組み込むことが可能である。そのためｖ３拡張型をどう認識するかはアプリケーション側に依存することとなる。クリティカルビットはその拡張型が必須であるかまたは無視可能かを表わすものである。

（第１の実施の形態）
図１は本実施形態を用いたシステムイメージを示した図の一例である。図１が示すシステムイメージは、スキャナ１１と電子文書を生成するコンピュータ装置１２、電子文書を編集加工するコンピュータ装置１３、及び電子文書を印刷する印刷装置１４がネットワーク１５に接続されている。

図２は本実施形態を用いて図１のシステムイメージを実現した場合の構成を示すシステムブロック図である。

電子文書生成装置３１は、画像データが入力され、鍵情報を取得し、署名が付加される。署名が付加された画像データは電子文書として、ネットワーク３２を経由して、電子文書操作装置３３へ送信される。電子操作装置３３では、受信したデータを検証する他に、データの加工、編集、印刷の操作が行われる。

次に、図３を用いて、本実施の形態に適応可能なホストコンピュータについて説明する。図２は本実施形態に係る電子文書生成装置３１、及び電子文書操作装置３３として機能するホストコンピュータの基本構成を示すと共に、その周辺機器との関係を示す図である。同図において、ホストコンピュータ２１は、例えば一般に普及しているパーソナルコンピュータであり、ＨＤ２６、ＣＤ２７、ＦＤ２８、及びＤＶＤ２９などに蓄積したり、或いは、蓄積されている画像データをモニタ２２に表示したりすることが可能である。更に、ＮＩＣ２１０などを用いて、これらの画像データをインターネットなどを介して配布させることが可能である。また、ユーザからの各種指示等は、マウス２１３、及びキーボード２１４からの入力により行われる。ホストコンピュータ２１の内部では、ます２１６により後述する各ブロックが接続され、種々のデータの受け渡しが可能である。

図中、２２は、ホストコンピュータ２１からの種々の情報を表示することの出来るモニタである。

２３は、ホストコンピュータ２１内の各部の動作を制御、或いはＲＡＭ２５にロードされたプログラムを実行することのできるＣＰＵである。２４は、ＢＩＯＳやブートプログラムを記憶しているＲＯＭである。２５はＣＰＵ２３にて処理を行うために一時的にプログラムや処理対象の画像データを格納しておくＲＡＭであり、ここにＯＳやＣＰＵ２３が後述の各種処理を行うためのプログラムがロードされることになる。

２６は、ＲＡＭ等に転送されるＯＳやプログラムを格納したり、装置が動作中に画像データを格納したり、読出すために使用されるハードディスク（ＨＤ）である。２７は、外部記憶媒体の一つであるＣＤ−ＲＯＭ（ＣＤ−Ｒ）に記憶されたデータを読み込み或いは書き出すことのできるＣＤ−ＲＯＭドライブである。

２８は、ＣＤ−ＲＯＭドライブ２７と同様にＦＤ（フロッピー（登録商標）ディスク）からの読み込み、ＦＤへの書き出しができるＦＤドライブである。２９も、ＣＤ−ＲＯＭドライブ２７と同様にＤＶＤ−ＲＯＭからの読み込み、ＤＶＤ−ＲＡＭへの書き出しができるＤＶＤ−ＲＯＭ（ＤＶＤ−ＲＡＭ）ドライブである。尚、ＣＤ−ＲＯＭ、ＦＤ、ＤＶＤ−ＲＯＭ等に画像処理用のプログラムが記憶されている場合には、これらプログラムをＨＤ２６にインストールし、必要に応じてＲＡＭ２５に転送されるようになっている。

２１１は、ＲＡＭ２５、ＨＤ２６、ＣＤ−ＲＯＭ２７、ＦＤ２８、ＤＶＤ２９などに記憶されている画像データを、インターネットなどのネットワークに接続するＮＩＣ２１０にホストコンピュータ２１を接続するためのＩ／Ｆである。Ｉ／Ｆ２１１を介してホストコンピュータ２１は、Ｉ／Ｆ２１１を介してインターネットへデータを送信したり、インターネットからデータを受信する。

２１５は、ホストコンピュータ２１にマウス２１３やキーボード２１４を接続するためのＩ／Ｆで、Ｉ／Ｆ２１５を介してマウス２１３やキーボード２１４から入力された各種の指示がＣＰＵ２３に入力される。

［電子文書生成］
次に、本実施形態に適応可能な電子文書生成部について説明する。図４は本実施形態における電子文書生成装置を説明する機能ブロック図である。

電子文書生成装置３１は、紙文書４３を入力する紙文書入力部４４、紙文書を解析し中間電子文書を生成する中間電子文書生成部４５、中間電子文書および秘密鍵入力部４６から入力された秘密鍵より署名データを生成する署名データ生成部４７、中間電子文書と署名データを統合し電子文書を生成する電子文書アーカイブ部４９、電子文書を電子文書操作装置３３に送信する電子文書送信部４１０から構成される。

まず、中間電子文書生成部４５の詳細を説明する。図５は本実施形態における中間電子文書生成部における処理のフローを示す図である。

Ｓ５１で紙文書入力部から得られたデータを電子化する。図９（Ａ）は電子化したデータの一例である。Ｓ５０２は電子データを属性ごとに領域分割する。ここでいう属性とは、文字、写真、表、線画があげられる。

領域分割処理技術の具体例としては、ＵＳＰ５６８０４７８号公報記載の処理などがある。上例では文書画像中の黒画素塊、白画素塊の集合を抽出し、その形状、大きさ、集合状態等の特徴量から、文字、絵や図、表、枠、線といった特徴名で領域を抽出している。

例えば、図９（Ｂ）は抽出した特徴量をもとに属性を判別し、領域分割を行った結果であり、それぞれの領域の属性は、９２、９４、９５、９６は文字領域、９３はカラー写真領域となっている。

次にＳ５３では、前段階で得られた領域ごとに文書情報を生成する。文書情報とは属性、ページの位置座標等のレイアウト情報、分割された領域の属性が文字であれば文字コード列や、段落や表題などの文書論理構造等があげられる。

Ｓ５４では、前段階で得られた領域ごとに伝達情報を変換する。伝達情報とは、レンダリングに必要な情報のことである。具体的には解像度可変のラスタ画像、ベクタ画像、モノクロ画像、カラー画像、それぞれの伝達情報のファイルサイズである。また、分割された領域の属性が文字であれば、文字認識した結果のテキスト、個々の文字の位置、フォント、文字認識によって得られた文字の信頼度等が挙げられる。

図９（Ｂ）では、文字領域９２、９４、９５、９６はベクタ画像に、カラー写真領域９３はカラーラスタ画像に変換されるものとする。

次にＳ５５では、Ｓ５２で分割された領域とＳ５３で生成された文書情報とＳ５４で変換された伝達情報を関連付ける。関連付けた情報はツリー構造で記述される。

Ｓ５６では前段階までで生成されたデータ群を中間電子文書として保存する。保存の形式はツリー構造を表現可能な形式であればよい。本実施形態は構造化文書の一例であるＸＭＬで保存する。

以上、中間電子文書生成部４５について説明した。

次に、署名データ生成部４７の詳細を説明する。図６は本実施形態における署名生成部における処理のフローを示す図である。

まず、Ｓ６１では、被署名データのダイジェスト値を、被署名データ毎に夫々生成する。ここで、被署名データとは、中間電子文書中に含まれる署名対象データのことであり、後述する図１２における伝達情報ａ（１２１）、伝達情報ｂ（１２２）、或いは文書情報（１２３）であると考えれば理解し易い。また、ダイジェスト値を生成するために、本実施形態ではハッシュ関数を適用する。

次に、Ｓ６２では、被署名データの識別情報を、被署名データ毎に夫々生成する。ここで、識別情報としては、被署名データをユニークに識別可能なものであれば良い。例えば、本実施形態では、被署名データの識別情報として、ＲＦＣ２３９６で規定されているＵＲＩを適用するものとするが、本発明はこれに限定されることなく、種々の値を識別情報として適用可能であることは明らかである。被署名データも識別情報を有しており、識別情報よりそれに対応する被署名データを特定することができる。

そして、Ｓ６３では、全ての署名対象データに対してＳ６１、及びＳ６２が適用されたか否かが判定される。全ての署名対象データに対してＳ６１、及びＳ６２が適用された場合には、処理をＳ６４に進め、さもなければ処理をＳ６１に進める。

Ｓ６４では、Ｓ６１で生成された被署名データのダイジェスト値、及びＳ６２で生成された被署名データ識別情報に対して、ハッシュ関数を用いてダイジェスト値を生成する。そして、生成されたダイジェスト値に対して、秘密鍵を用いて署名処理を実行して、署名値を算出する。署名値を算出するために、本実施形態ではデジタル署名を適用する。

続いて、Ｓ６５では、Ｓ６１で生成された被署名データのダイジェスト値、Ｓ６２で生成された被署名データ識別情報、及びＳ６４で生成された署名値を用いて署名データを構成し、署名生成処理を終了する。

ここで、本実施形態における、署名データの構成について図７を用いて説明する。図７は本実施形態に適用可能な署名データの構成の一例を示す図である。図７（Ａ）は、電子文書４１１全体の構成を示す図であり、７１は署名データ、７２は被署名データ１、及び７３は被署名データ２である。また、図７（Ｂ）は、図７（Ａ）中の署名データの詳細な構成を示す図であり、７４は署名値、７５は被署名データ１の識別情報、７６は被署名データ１のダイジェスト値、７７は被署名データ２の識別情報、７８は被署名データ２のダイジェスト値である。

図７（Ａ）に示す例では、２つの被署名データ１（７２）、及び被署名データ２（７３）に対して、一つの署名データ（７１）を生成した場合の電子文書４１１の構成例を示している。また、図７（Ｂ）は署名データ７１の詳細な構成例を示している。

図７（Ｂ）においては、被署名データ１の識別情報７５、及び被署名データ２の識別情報７６が前述したＳ６２で生成され、被署名データ１のダイジェスト値７６、及び被署名データ２のダイジェスト値７８が前述したＳ６１で生成される。署名値（７４）は、被署名データ１の識別情報７５、被署名データ１のダイジェスト値７６、被署名データ１の識別情報７７、被署名データ２のダイジェスト値７８からＳ６４において生成される。

続いて、電子文書アーカイブ部４９について図１２を用いて説明する。１２１、及び１２２は中間電子文書生成部４５で生成された中間電子文書の伝達情報、及び７３は文書情報である。また、１２４は署名データ生成部４７で生成された署名データである。署名データには、前述したように被署名データにあたる伝達情報や文書情報を指し示す識別情報を含んでいる。図１２（Ａ）でいうと、署名データ１２４には、伝達情報１２１を指し示す識別情報１２６、伝達情報１２２を指し示す識別情報１２７、文書情報１２３を指し示す識別情報１２８を埋め込む。

中間電子文書生成部で生成された中間電子文書および署名データ生成部で生成された署名データは図１２（Ａ）の例のように、伝達情報、文書情報、署名データが個々のデータとして存在している。電子文書アーカイブ部４９では図１２（Ａ）のそれらをひとつにアーカイブし電子文書を生成する。図１２（Ｂ）は中間電子文書と署名データをアーカイブ化したときの模式図であり、アーカイブデータ１２９は図４の電子文書４１１に該当する。

図１２（Ａ）と図１２（Ｂ）とでは、１２１と１２１３、１２２と１２１４、１２３と１２１２、１２４と１２１１が夫々対応している。

［電子文書操作］
次に、本実施形態に適応可能な電子文書操作装置３３について説明する。図１３は本実施形態に適応可能な電子文書操作装置３３を説明する機能ブロック図である。

本実施形態における電子文書操作装置は、送受信部１３２、公開鍵入力部１３３、署名検証部１３４、制御部１３１、出力部１３５、操作部１３６からなる。

ここで、送受信部１３２で受信される電子文書は前述した電子文書生成装置３１（図４）から送信された電子文書４１１と同じデータであると考えると理解し易い。特に、本実施形態においては、電子文書生成装置３１から送信された電子文書全体を、一度に電子文書受信部１３２で受信するのではなく、電子文書を構成する部分データ毎に受信するようにしている。この受信処理の詳細については後述する。

また、公開鍵入力部１３３は、前述した電子文書生成装置（図４）において署名生成部４７で用いられた秘密鍵に対応する鍵データを入力するようにする。尚、公開鍵は、図１１に示すような公開鍵証明書に含まれる公開鍵データを入力するようにしても良い。

署名検証部１３４において、入力された電子文書に含まれる署名が、公開鍵１３３を用いて検証される。更に、署名検証部１３４では、署名の検証結果に応じて制御部１３１を制御する。

制御部１３１は、送受信部１３２へデータの送受信の制御を行う。又は、出力部１３５へ受け取った電子文書の出力の制御を行う。もしくは、操作部１３６へ受け取った電子文書の加工や編集の制御を行う。

以降では、署名検証部１３４で実行される署名検証処理及び制御処理についての詳細を説明する。図８は本実施形態における署名検証部１３４、制御部１３１における処理のフローチャートである。

まず、Ｓ８１では、署名データを受信する。ここで署名データとは、前述した図７（Ａ）における署名データ（７１）のことである。このように、本実施形態では電子文書アーカイブ部４９においてアーカイブされた電子文書全体（即ち、７１、７２、及び７３）を一度に受信するのではなく、電子文書を構成する部分データ毎に受信するようにしている。Ｓ８１の段階では、被署名データ１、及び被署名データ２はまだ受信していないことに注意されたい。

次に、Ｓ８２では、受信した署名データを用いて署名データの検証処理を実行する。本実施形態における署名データ検証処理の詳細について図１４を用いて説明する。図１４は本実施形態における署名データ検証処理のフローを示すフローチャートである。

まず、Ｓ１４１では、Ｓ８１で受信した署名データに含まれる被署名データの識別情報、及び被署名データのダイジェスト値から、ハッシュ関数を用いてダイジェスト値を算出する。例えば、図７（Ｂ）に示す例では、被署名データ１の識別情報７５、被署名データ１のダイジェスト値７６、被署名データ２の識別情報７７、及び被署名データ２のダイジェスト値７８からダイジェスト値を生成する。

次に、Ｓ１４２では、Ｓ８１で受信した署名データに含まれる署名値を、公開鍵入力部１３３で入力された公開鍵を用いて復号する。例えば、図７（Ｂ）に示す例では、署名値７４が公開鍵を用いて復号される。

そして、Ｓ１４３では、Ｓ１４１で生成されたダイジェスト値と、Ｓ１４２で復号された値を比較する。

続いて、Ｓ８３では、Ｓ８２における署名データ検証処理の結果を判定し、検証処理が成功した場合（つまり、Ｓ１４１で生成されたダイジェスト値とＳ１４２で復号された値がＳ１４３で等しいと判定された場合）は処理をＳ８５に進める。検証処理が成功しなかった場合は、処理をＳ８４に進める。

Ｓ８４では、制御部１３１で電子文書操作装置３３の制御を行う。本実施形態においては、装置の制御として、電子文書生成装置３１に対して、これ以降のデータ送信処理を停止するような命令を送信し、電子文書操作装置３３がデータ受信処理を実行しないように送受信部１３２を制御する。

尚、本実施形態はこれに限定されることなく、種々の方法で装置を制御可能であることは明らかである。例えば、電子文書生成装置３１に対して、署名データの再送処理を実行するような命令を送信し、再送された署名データを用いて再度署名データの検証処理を実行するようにしてもよい。これは、最初の送信処理の際に、署名検証に成功しなかったことが伝送路途中での伝送誤りだった可能性をも考慮し、再度署名を検証し直す場合の制御として考えられる。そして、所定回数だけ再送処理を実行し、所定回数を超えて検証処理が失敗した場合には、受信停止処理を実行するようにしても良い。

さらにその他の装置の制御例としては、署名検証が正しいデータのみ出力し（例えば、プリント出力や、ディスプレイ出力）、署名検証が成功しなかった場合は、データ出力しないよう、出力部１３５を制御してもよい。

さらには、署名検証が正しいデータのみデータの編集や加工を行えるようにし、署名検証が成功しなかった場合は、データの編集や加工を行えないよう、操作部１３６を制御してもよい。

一方、Ｓ８５では、被署名データを受信する。ここで被署名データとは、前述した図７（Ｂ）における被署名データ１（７２）、及び被署名データ２（７３）のことである。特に、本実施形態では、複数の被署名データが存在する場合、（電子文書アーカイブ部４９でアーカイブされた）全ての被署名データを一度に受信するのではなく、被署名データ毎に受信するようにする。例えば、図７（Ａ）の場合、最初にＳ８５が実行される段階では、被署名データ１（７２）だけが受信されることに注意されたい。

次に、Ｓ８６では、受信した被署名データを用いて被署名データの検証処理を実行する。ここで、本実施形態における被署名データの検証処理の詳細について図１５を用いて説明する。図１５は本実施形態における被署名データの検証処理のフローを示すフローチャートである。

まず、Ｓ１５１では、Ｓ８５で受信した被署名データからハッシュ関数を用いてダイジェスト値を算出する。

そして、Ｓ１５２で、Ｓ８５で生成されたダイジェスト値と、前段のＳ８１で受信した署名データ中に含まれるダイジェスト値とを比較する。このとき、署名データに含まれる被署名データの識別情報より、被署名データの対応先を確認することができる。

次に、Ｓ８７では、Ｓ８６における被署名データ検証処理の結果を判定する。検証処理が成功した場合（つまり、Ｓ８５で生成されたダイジェスト値と、Ｓ８１で受信した署名データ中に含まれるダイジェスト値がＳ１５２で等しいと判定された場合）は処理をＳ８８に進め、さもなければ処理をＳ８４に進める。

そして、Ｓ８８では、全ての被署名データを受信したか否かを判定し、全ての被署名データを受信していない場合は、処理をＳ８５に進め、さもなければ検証処理を終了する。

以上説明した署名データ検証処理の例を、図１６を用いて説明する。図１６は本実施形態における署名データ検証処理の例を示す図である。図１６に示す例では、図１６（Ａ）に示すように（電子文書生成装置３１で生成された）文書データは、署名データ（１６１）、被署名データ１（１６２）、被署名データ２（１６３）、被署名データ３（１６４）、被署名データ４（１６５）から構成されている。

まず、図１６（Ｂ）に示すように、署名データ１６１だけが電子文書操作装置３３で受信され（Ｓ８１）、受信した署名データ１６１の検証処理を実行する（Ｓ８２）。検証処理が成功した場合には、続いて、図１６（Ｃ）に示すように、被署名データ１（１６２）を受信し（Ｓ８５）、受信した被署名データ１６２の検証処理を実行する（Ｓ８６）。そして、検証処理が成功した場合には、続いて、図１６（Ｄ）に示すように、被署名データ２（１６３）を受信し（Ｓ８５）、受信した被署名データ２（１６３）の検証処理を実行する（Ｓ８６）。以降、被署名データ３（１６４）、及び被署名データ４（１６５）の場合も同様の処理であるので、説明は省略する。

図１６に示すように、本実施形態では、署名データ、及び被署名データの全てを受信することなく、部分的な被署名データを順次受信し、受信した被署名データを用いて、リアルタイムに検証処理を実行し、検証結果に応じて、装置を制御することが可能となる。

本実施形態においては、例えば、（公開鍵に対応した秘密鍵を有する）正当な署名者によって署名がなされていない場合（即ち、電子文書が偽造されている場合）に、署名データの検証処理が失敗する。又は、署名データに含まれる被署名データのダイジェスト値、或いは被署名データの識別情報が改竄されている場合に、署名データの検証処理が失敗する。このような場合に、前述したように装置を制御することにより、（署名データの検証処理が失敗したような）偽造された被署名データを受信する必要がなくなり、効率的である。

また、署名値の生成において、被署名データのダイジェスト値や識別情報を、受信側で受信される順番にデータを並べて署名を生成することで、被署名データの欠落がないか、あるいは被署名データが正しい順番で受信されているかも検証することが可能である。

また、例えば、被署名データが改竄されている場合には、被署名データの検証処理が失敗する。こうした場合に、前述したように装置を制御することにより、それ以降の被署名データを受信する必要がなくなり、効率的である。

（第２の実施形態）
第１の実施形態では、最初に署名データを受信して署名データの検証を行い、その後、被署名データの検証を行った。第２の実施形態では、署名データも部分的に受信して、部分データが途中で削除されていないか、受信した部分データの順序は改竄されていないかを検証しながら、装置を制御するようにする。第１の実施形態では、複数の構成要素（つまり、文書情報や伝達情報）からなる電子文書の例を説明したが、動画像データを例に挙げ、部分データが順番を有するデータの例を考える。

＜全体構成の説明＞
まずはじめに、本実施形態におけるシステム概要例を図１７に示す。本実施形態におけるシステムは、画像配信サーバ３１０、画像ＤＢ３２０、及びネットワーク３３０、及び画像再生クライアント３４０から構成される。

図中、装置３１０は、画像再生クライアント３４０から受信した画像データの取得要求に応答し、画像ＤＢ３２０に蓄積されている画像データを配信する画像配信サーバである。また、本実施形態においては、画像データに加え、当該画像データが改竄されているか否かを画像再生クライアント３４０で検証可能な検証データを生成し、画像データと共に画像再生クライアント３４０へ送信する。

装置３４０は画像再生クライアントであって、画像配信サーバ３１０に対し所望の画像データの取得要求を送信し、画像配信サーバ３１０からネットワーク３３０経由で配信された画像データ再生を行う。また、本実施形態においては、画像データに加え、当該画像データに対応する検証データを受信し、画像データが改竄されているか否かの検証も行う。

装置３１０、及び装置３４０はインターネットなどのネットワーク３３０によって接続されており、各種データを互いに交換可能である。また、装置３１０、及び装置３４０は通常のパーソナルコンピュータ等の汎用装置で構わない。処理の流れを簡単に説明すると、次の通りである。

画像閲覧者は、画像再生クライアント３４０を利用して、所望の画像データを画像配信サーバ３１０に要求する。画像配信サーバ３１０は、画像再生クライアント３４０から要求された画像データを画像ＤＢ３２０から取得し、当該画像データを、部分データに分割する。同時に、分割された部分データに対応する検証データを生成する。そして、部分データ、及び生成した検証データを順に画像再生クライアント３４０に送信する。画像再生クライアント３４０は、部分データ、及び検証データを受信し、当該検証データを利用して、受信した部分画像データが正しい部分画像データか否かを検証する。更に、受信した部分データを再生し、再生後、当該部分データを消去する。

以上が、本実施形態におけるシステムの概要例である。

本実施形態に係る画像再生クライアント、及び画像配信サーバとして機能するホストコンピュータの基本構成は、第１の実施形態の図３と同様であるので、説明を省略する。

＜検証データ生成処理＞
次に、本実施形態に適応可能な検証データ生成処理部について図１８を用いて説明する。

図１８は、本実施形態における検証データ生成処理機能を説明する図である。図１８において、４１０は入力部、４２０は分割部、４３０は鍵取得部、４４０は検証データ生成部、４５０はハッシュ値保持部、４６０はハッシュ値生成部、４７０は出力部である。

図１８に示す検証データ生成処理機能は、前述した画像配信サーバ３１０（図１７）に搭載される一機能である。

まず、入力部４１０について説明する。入力部４１０は、画像データＤが画像ＤＢ３２０から入力され、入力されたデータＤが出力される。

本実施形態では、画像データＤとして、Ｍｏｔｉｏｎ ＪＰＥＧ、或いは、Ｍｏｔｉｏｎ ＪＰＥＧ ２０００などのようにフレーム毎に独立に圧縮符号化されている動画像データを対象とする。しかしながら、本発明はこれに限定されることなくＭＰＥＧなどのフレーム間相関を利用した種々の圧縮符号化する方式を適応可能であることは明らかである。

次に、分割部４２０について説明する。分割部４２０は、入力部４１０から出力された画像データＤが入力され、画像データＤが複数の部分データＤｉに分割され、分割されたＤｉが出力される。

本実施形態では、画像データＤはフレーム毎に分割されるものとする。即ち、部分データＤｉは画像データＤに含まれる各々のフレームデータを表す。しかしながら、本発明はこれに限定されることなく、複数のフレームの集合をＤｉとするなど、画像データＤを任意の単位で分割可能であることは明らかである。さらに、本実施形態では、部分データはフレーム順に所定の順序を有するものとする。

次に、鍵取得部４３０について説明する。鍵取得部４３０では、後述する検証データ生成処理部４４０における検証データ生成処理のために必要な鍵情報Ｋが取得され、出力される。

本実施の形態において、鍵取得部４３０において取得される鍵情報Ｋは、画像配信サーバ３１０と画像再生クライアント３４０とで安全に共有されている共有鍵であるとする。

次に、検証データ生成部４４０について説明する。検証データ生成処理部４４０では、前段の分割部４２０から出力された部分データＤｉ、及び鍵取得部４３から出力された鍵情報Ｋが入力され、鍵情報Ｋを利用して部分データＤｉに対応する検証データＶＤ０が生成され、生成された検証データＶＤ０が出力される。

検証データ生成処理は、分割部４２０で分割された部分データのうち最初のデータに対してだけ１度だけ実行される。即ち、本実施形態においては、第１フレームＤ０に対してだけ、検証データＶＤ０が生成される。

本実施形態では、例えば、以下の様に検証データＶＤ０を算出する。
ＶＤ０＝Ｆ（Ｋ、Ｄ０） （式１）
ここで、Ｆ（ｘ、ｙ）は、鍵ｘを用いてデータｙに対する検証データを生成する処理を示す。

本実施形態では、検証データ生成処理Ｆ（ｘ、ｙ）として、ＨＭＡＣ（Ｈａｓｈ−ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）を適応するものとする。ＨＭＡＣについては、当業者にとって公知の技術であるため、詳細な説明は省略する。尚、本実施形態では、検証データ生成処理としてＨＭＡＣを利用した方式を説明するが、本発明はこれに限定されることはない。例えば、ＣＭＡＣ（Ｃｉｐｈｅｒ−ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）などの種々のＭＡＣ生成アルゴリズムを適応可能である。

次に、検証データ保持部４５０について説明する。検証データ保持部４５０は、前段の検証データ生成部４４０で生成された検証データＶＤ０、或いは、後述するハッシュ値生成部４６で生成された検証データＶＤｉ（現部分データＤｉに対応する検証データＤＶｉ）が入力され、一旦、保持する。そして、保持されているハッシュ値ＶＤｉ−１（前部分データＤｉ−１に対応する検証データＶＤｉ−１）を後段のハッシュ値生成部４６に出力する。

即ち、検証データ保持部４５０は、ハッシュ値生成部４６０（或いは、検証データ生成部４４）で生成されたハッシュ値ＶＤｉ（或いは、検証データＶＤ０）を一旦保持し、次回のハッシュ値生成部４６０に提供するための一時記憶バッファの役割を果たす。

次に、ハッシュ値生成部４６０について説明する。ハッシュ値生成部４６０は、前段の分割部４２０で分割された分割データＤｉ、及び検証データ保持部４５０で保持されている検証データＶＤｉ−１が入力される。そして、部分データＤｉ、及び検証データＶＤｉ−１に応じてハッシュ値ＶＤｉが生成され、生成されたハッシュ値ＶＤｉが出力される。

本実施形態では、例えば、以下の様にハッシュ値ＶＤｉを算出する。
ＶＤｉ＝Ｈ（ＶＤｉ−１ｍｙ｜Ｄｉ） （式２）
ここで、Ｈ（・）はハッシュ関数、及びｘ｜ｙはｘとｙの連結を示す。

尚、本実施形態においては、ハッシュ値生成処理のためのハッシュ関数については特に限定せず、ＭＤ５やＳＨＡ−１などの種々のハッシュ関数を適用可能である。

次に、出力部４７０について説明する。出力部４７０は、ハッシュ値生成部４６０で生成された検証データＶＤｉ（或いは、前段の検証データ生成部４４０で生成された検証データＶＤ０）、及び分割部４２０で分割された部分データＤｉを出力する。

本実施形態では、出力部４７０は、ＮＩＣ２１０（図３）を用いて、ネットワーク３３（図１７）を介し、画像再生クライアント３４０（図１７）に送信するものとする。尚、本発明はこれに限定されることなく、出力部４７０において、一旦、ＲＡＭ３５、ＨＤ３６、ＣＤ３７、ＦＤ３８、ＤＶＤ３９などの記憶媒体に蓄積するようにしても良い。

また、出力部４７０では、検証データＶＤｉ、及び部分データＤｉが後述する画像再生クライアント３４０で対応付け可能なように出力する。本実施形態における、出力データの形式例を図１９を用いて説明する。本実施形態では、５１０に示すように、部分データＤｉにＶＤｉを連結させて出力するようにしたり、或いは、５２０に示すように、部分データＤｉのヘッダ中（図中、網掛けの部分）に記録して出力ようにすればよい。

次に、以上説明したような検証データ生成処理の流れを図２０を用いて説明する。図２０は本実施形態に適応可能な検証データ生成処理を説明するフローチャートである。

まず、ステップＳ６１０は、入力部４１０で入力された画像データＤを複数の部分データに分割する（図１８の４２０）。そして、ステップＳ６２０でパラメータｉを０に初期化する。ここでパラメータｉは部分データＤｉを特定するパラメータである。

次に、ステップＳ６３０では、ｉ＝０の場合は前述した式１（図１８の４４０）、及び、ｉ＞０の場合は前述した式２（図１８の４６０）を用いて検証データＶＤｉを算出する。ステップＳ６４０では、ｉ番目の検証データＶＤｉを生成するために必要となる（ｉ−１）番目の検証データＶＤｉ−１は、ステップＳ６３で算出した値を一時記憶バッファ（図１８の４５０）に保持しておく。

ステップＳ６５０は、部分データＤｉ、及び検証データＶＤｉを出力する（図１８の４７０）。その後、ステップＳ６６０で、パラメータｉがＮ−１以下か否かが判定される。ここでＮは画像データＤに含まれる部分データＤｉの総数である。パラメータｉがＮ−１以下の場合、ステップＳ６７０でパラメータｉを１だけ増加させ、ステップＳ６３０に進む。さもなければ、検証データ生成処理を終了する。

＜検証処理、及び方法＞
次に、本実施形態に適応可能な検証処理について図２１を用いて説明する。

図２１は、本実施形態における検証処理を説明する図である。図２１において、７１０は入力部、７２０は鍵取得部、７３０は検証データ生成部、７４０は検証データ保持部、７５０はハッシュ値生成部、７６０は判定部、７７０は部分データ再生部、７８０は部分データ消去部である。

図１８に示す検証処理機能は、前述した画像再生クライアント３４０（図１７）に搭載される一機能である。

まず、入力部７１０について説明する。入力部７１０では、部分データＤ’ｉ、及び検証データＶＤｉが入力される。ここで入力される部分データＤ’ｉ、及び検証データＶＤｉは、図１８における出力部４７０から出力されたデータであると考えれば理解しやすい。尚、本実施形態では、出力部４７０から部分データＤｉが出力された後、ネットワーク３３０上で改竄されている可能性があることを考慮し、Ｄｉとは異なる記号Ｄ’ｉを用いている。

次に、鍵取得部７２０について説明する。鍵取得部７２０では、後段の検証データ生成部７３０で検証データ生成処理のために必要な鍵情報Ｋが取得され、出力される。

鍵取得部７２０において取得される鍵情報Ｋは、図１８における鍵取得部４３０において取得された鍵情報Ｋと同じ情報である。

次に、検証データ生成部７３０について説明する。検証データ生成部７３０では、入力部７１０で入力された部分データＤ’ｉ、及び鍵取得部７２０で取得された鍵情報Ｋを入力し、鍵情報Ｋを用いて部分データＤ’ｉから検証データＶＤ’０が生成され、生成された検証データＶＤ’０が出力される。

検証データ生成処理７４０で実行される検証データ生成処理は、図１８における検証データ生成部４４０で実行された検証データ生成処理（即ち、式１）と同様の処理を適応するものとする。

次に、検証データ保持部７４０について説明する。検証データ保持部７４０は、前段の検証データ生成部７３０で生成された検証データＶＤ０、或いは、後述するハッシュ値生成部７５０で生成された検証データＶＤｉ（現部分データＤｉに対応する検証データＤＶｉ）が入力され、一旦、保持する。そして、保持されているハッシュ値ＶＤｉ−１（前部分データＤｉ−１に対応する検証データＶＤｉ−１）を後段のハッシュ値生成部４５０に出力する。

次に、ハッシュ値生成部７５０について説明する。ハッシュ値生成部７５０は、前段の入力部７１０で入力された部分データＤｉ、及び検証データ保持部７４０で保持されている検証データＶＤｉ−１が入力される。そして、部分データＤｉ、及び検証データＶＤｉ−１に応じてハッシュ値ＶＤｉが生成され、生成されたハッシュ値ＶＤｉが出力される。

ハッシュ値生成処理部７５０で実行されるハッシュ値生成処理は、図１８におけるハッシュ値生成処理部４６０で実行されたハッシュ値生成処理（即ち、式２）と同じ処理を適応する。

次に、判定部７６０について説明する。判定部７６０では、前段のハッシュ値生成部７５０から出力された検証データＶＤ’ｉ、及び入力部７１から出力された検証データＶＤｉを比較し、検証結果を出力する。

本実施形態においては、値ＶＤｉと値ＶＤ’ｉの値が一致していたら「部分データＤｉは正しいデータ（検証成功）」であると判定する。一方、値ＶＤｉと値ＶＤ’ｉが異なっていたら「部分データＤ’ｉは正しいデータではない（検証失敗）」と判定する。

本実施形態においては、判定部７６０における判定結果は、モニタ２２上に表示する。また、「検証失敗」と判定された場合には、後述する部分データ再生部７７における部分データ再生処理を停止させると共に、それ以降の部分データ再生処理を停止する。こうすることにより、改竄された（検証失敗した）画像データの再生を防止することができる。

次に、部分データ再生部７７０、及び部分データ消去部７８０について説明する。部分データ再生部７７０は、入力部７１０で入力された部分データＤ’ｉが入力され、部分データＤ’ｉをモニタ２２上などに再生する。部分データＤ’ｉが部分データ再生部７７０で再生された後、すぐさま、後段の部分データ消去部７８０で消去される。即ち、部分データＤ’ｉは画像再生クライアント３４０中には保持されない。

次に、以上説明したような検証データ生成処理の流れを図２２を用いて説明する。図２２は本実施形態に適応可能な検証データ生成処理を説明するフローチャートである。

まず、ステップＳ８１０ではパラメータｉを初期化する。ここで、パラメータｉは部分データＤｉを特定するパラメータである。そして、ステップＳ８２０では、検証データＶＤｉ、及び部分データＤ’ｉを受信する（図２１の７１０）。

次に、ステップＳ８３０では、ｉ＝０の場合は前述した式１（図２１の７３０）、及び、ｉ＞０の場合は前述した式２（図２１の７５０）を用いて検証データＶＤｉを算出する。ステップＳ８４では、ｉ番目の検証データＶＤｉを生成するために必要となる（ｉ−１）番目の検証データＶＤｉ−１は、ステップＳ８３０で算出した値を一時記憶バッファ（図２１の４５０）に保持しておく。

検証データＶＤｉを生成した後、ステップＳ８５０で、検証データＶＤｉ、及びＶＤ’ｉが等しいか否かが判定される（図２１の７６０）。等しい場合、ステップＳ８６０で「検証成功」と表示し、処理をステップＳ８８０に進める。さもなければ、「検証失敗」と表示し、検証処理を終了する。さらに、検証失敗に連動させて、画像再生クライアント３４０の再生処理を停止させ、画像配信サーバ３１０から新たにデータを受信することを停止させる。

その後、ステップＳ８８０では、パラメータｉがＮ−１以下か否かが判定される。ここでＮは画像データＢに含まれる部分データＤｉの総数である。パラメータｉがＮ−１以下の場合、ステップＳ８９０でｉを１だけ増加させ、ステップＳ８２０に進む。さもなければ、検証処理を終了する。

＜検証結果例＞
ここで、以上説明したような検証データ生成処理、及び検証処理を用いた場合の検証結果について、具体的な例を用いて説明する。

まず、従来の方法を用いて、部分データの夫々に対応するデジタル署名が生成された場合の検証結果について説明する。

図２３において、２３１は、画像配信サーバにおいて生成される部分データＤｉ、及びデジタル署名ＶＤｉを示す。図２３に示す例では、画像データＤは５つの部分データＤ０〜Ｄ４に分割され、夫々に対応するデジタル署名ＶＤ０〜ＶＤ４が生成されている。夫々の部分データ、及びデジタル署名の下部には、対応するデジタル署名を生成する方法が示されている。図２３に示すように、部分データに対するデジタル署名は、サーバの秘密鍵Ｋを用いて、夫々の部分データＤ０〜Ｄ４に対してデジタル署名生成処理Ｆ（・）を施すことにより生成される。

２３２〜２３５は、クライアントにおいて受信した部分データＤ’’ｉ、及びデジタル署名ＶＤｉを示す。以降では、２３２〜２３５について順に説明する。

２３２は、サーバから送信された全ての部分データＤ’ｉ、及びデジタル署名ＶＤｉがネットワークの途中で改竄されることなくクライアントに配信された場合の例を示す。この場合、図に示すように、受信した部分データＤ’０〜Ｄ’４は夫々Ｄ０〜Ｄ４に等しいため、受信した部分データＤ’０〜Ｄ’４、及びデジタル署名ＶＤ０〜ＶＤ４を用いて検証処理を行った場合、全ての部分データについて「検証成功」となる。

２３３は、サーバから送信された部分データＤｉのうち、Ｄ’０、Ｄ’１、Ｄ’３、及びＤ’４は改竄されることなくクライアントに配信されたが、Ｄ＊２はネットワークの途中で改竄されて配信された場合の例を示す。この場合、（改竄されていない）部分データＤ’０、Ｄ’１、Ｄ’３及びＤ’４と、受信したデジタル署名ＶＤ０、ＶＤ１、ＶＤ３、及びＶＤ４を用いて検証処理を行った場合は「検証成功」となる。一方、部分データＤ＊２は改竄されていることから、受信した部分データＤ＊２、及びデジタル署名ＶＤ２を用いて検証を行った場合、「検証失敗」と判定することができる。

２３４は、サーバから送信された部分データＤｉのうち、部分データＤ’０、Ｄ’２、Ｄ’３，及びＤ’４は改竄されることなくクライアントに配信されたが、部分データＤ’１だけが配信されなかった場合の例を示す。この場合、（改竄されていない）部分データ部分データＤ’０、Ｄ’２、Ｄ’３，及びＤ’４、及び受信したデジタル署名ＶＤ０、ＶＤ２、ＶＤ３、及びＶＤ４を用いて検証処理を行った場合は「検証成功」となる。つまり、部分データＤ’１は受信されなかったにも関わらず、この方法では部分データＤ’１に対する一切の検証処理がなされないため、「検証失敗」とならない。

２３５は、サーバから送信された部分データＤｉのうち、部分データＤ’０、Ｄ’１、及びＤ’４は改竄されることなくクライアントに配信されたが、部分データＤ’３、及びＤ’４の順序が反対に配信された場合の例を示す。この場合、（改竄されていない）部分データＤ’０、及びＤ’１、及びＤ’４と、受信したデジタル署名ＶＤ０、ＶＤ１、及びＶＤ４を用いて検証処理を行った場合は「検証成功」となる。更に、部分データＤ’３とＤ’２は順序が反対に受信されたにも関わらず、部分データＤ’３、及びＤ’２と、受信したデジタル署名ＶＤ３、及びＶＤ２を用いて検証処理を行った場合も「検証成功」となってしまう。図２４は、本実施形態における検証データ生成処理例、及び検証結果例を説明する図である。

図中、２４１は画像配信サーバにおいて生成される部分データＤｉ、及び検証データＶＤｉを示す。図２４に示す例では、画像データＤは５つの部分データＤ１〜Ｄ４に分割され、夫々に対応する検証データＶＤ０〜ＶＤ４が生成されている。図中、夫々の部分データ、及び検証データの下部には、対応する検証データ生成処理（即ち、式１、或いは式２による演算処理）を示している。また、２４１においては、左側のデータから右側のデータへ、順に画像配信サーバから画像再生クライアントへ配信されるものとする。

また、２４２〜２４５は、画像再生クライアント３４０において受信した部分データＤ’ｉ、及び検証データＶＤｉを示す。ここで、２４２〜２４５について順に説明する。

２４２は、画像配信サーバ３１０から配信された全ての部分データＤｉ、及び検証データＶＤｉがネットワークの途中で改竄されることなく画像再生クライアント３４０に配信された場合の例を示す。この場合、図に示すように、受信した部分データＤ’０〜Ｄ’４は夫々Ｄ０〜Ｄ４に等しい。そのため、Ｄ’０〜Ｄ’４を用いて画像再生クライアント内で生成された検証データＶＤ’０〜ＶＤ’４は、夫々受信したＶＤ０〜ＶＤ４と等しくなり、全ての部分データについて「検証成功」となる。

２４３は、画像配信サーバ３１０から送信された部分データＤｉのうち、Ｄ’０、及びＤ’１は改竄されることなく画像再生クライアント３４０に配信されたが、Ｄ＊２はネットワークの途中で改竄されて配信された場合の例を示す。この場合、（改竄されていない）部分データＤ’０、及びＤ’１から生成された検証データＶＤ’０、及びＶＤ’１については、受信した検証データＶＤ０、及びＶＤ１と等しい値となり、「検証成功」となる。一方、部分データＤ＊２は改竄されていることから、部分データＤ＊２から生成された検証データＶＤ’２は、受信した検証データＶＤ２と等しい値とならない。結果として、部分データＤ＊２の時点で「検証失敗」と判定可能である。

２４４は、画像配信サーバ３１０から送信された部分データＤｉのうち、部分データＤ’０、Ｄ’２、Ｄ’３，及びＤ’４は改竄されることなく画像再生クライアント３４０に配信されたが、部分データＤ’１だけが配信されなかった場合の例を示す。この場合、（改竄されていない）部分データＤ’０から生成された検証データＶＤ’０については、受信した検証データＶＤ０と等しい値となり、「検証成功」となる。一方、部分データＤ’１は受信されないため、部分データＤ’０の次に配信されるのは部分データＤ’２である。すると、部分データＤ’２は改竄されてはいないが、対応する検証データＶＤ’２は前段の検証データＶＤ’０から生成されることになる。よって、このように生成された検証データＶＤ’２は、受信した検証データＶＤ２とは異なる値となる。結果として、部分データＤ’２の時点で「検証失敗」と判定可能である。つまり、本実施形態では、従来の方法ではできなかった「部分データがネットワークの途中で削除された」ことが検出できる。

２４５は、画像配信サーバ３１から送信された部分データＤｉのうち、部分データＤ’０、Ｄ’１、及びＤ’４は改竄されることなく画像再生クライアント３４０に配信されたが、部分データＤ’３、及びＤ’４の順序が反対に配信された場合の例を示す。この場合、（改竄されていない）部分データＤ’０、及びＤ’１から生成された検証データＶＤ’０、及びＶＤ’１については、受信した検証データＶＤ０、及びＶＤ１と等しい値となり、「検証成功」となる。一方、本来、部分データＤ’２が配信されるべきであるにも関わらず、部分データＤ’３が配信されているために、受信したデータデータＤ’３、及び前段の検証データＶＤ’１から生成される検証データＶＤ’２は、受信した検証データＶＤ２とは異なる値となる。結果として、部分データＤ’２の時点で「検証失敗」と判定可能である。つまり、本実施形態では、従来の方法ではできなかった「「部分データ同士の配信順序が改竄された」ことが検出できる。

以上説明した本実施形態によれば、全ての部分データ（即ち、画像データＤ）の受信が完了しなくても、夫々の部分データＤｉを受信したタイミングで、受信した部分データが改竄されているか否かを検証可能となる。また、受信した部分データＤｉの改竄に加え、部分データＤｉが配信される前に配信されるべき部分データＤｊ（ｊ＜ｉ）が削除されていないかどうか、及び、部分データＤｉが正しい順序で配信されたか否かを検証可能となる。更に、画像配信サーバ３１０における検証データ生成処理（図１８の４４０）は、最初の部分データＤ０に対してだけ実行し、残りの部分データＤｉ（ｉ＞０）に対しては、ハッシュ値生成処理（図１８の４６０）だけを実行すれば良いため、画像配信サーバ３１における検証データ生成処理を高速に実行することが可能となる。同様に、画像再生クライアント３４における検証データ生成処理（図２１の７３０）は、最初の部分データＤ０に対してだけ実行し、残りの部分データＤｉ（ｉ＞０）に対しては、ハッシュ値生成処理（図２１の７５０）だけを実行すれば良いため、画像再生クライアント３４０における検証処理を高速に実行することが可能となる。（通常、検証データ生成処理はハッシュ値生成処理よりも大きな処理量を必要とする。）
以下、本実施形態の変形例を説明する。説明していない箇所は、本実施形態と同様であるので、説明を省略する。

＜変形例１＞
尚、本実施形態においては、夫々の部分データＤｉに対応する検証データＶＤｉは図１９に示すように部分データＤｉと共に送信するようにした。しかし、本発明はこれに限定されることなく、少なくとも、部分データＤｉを送信する前までに、対応する検証データＶＤｉが画像再生クライアント３４０に配信されているようにすれば良い。よって、例えば、予め、全ての検証データＶＤｉを画像配信サーバ３１０内で生成しておき、最初の部分データＤ０を送信する前に、まとめて画像再生クライアント３４０に送信することも可能である。

＜変形例２＞
尚、本実施形態においては、図２０のステップＳ６６０、及び図２２のステップＳ８８０に示すように、画像データＤに含まれる部分データＤｉの総数Ｎまで、繰り返し、処理を実行するようにした。しかし、本発明はこれに限定されることなく、ｎ＜＝Ｎを満たす任意の部分データＤｎで検証データ生成処理、或いは検証処理を終了することも可能である。これにより、例えば、画像閲覧者が画像再生クライアント３４０を用いて画像データを再生している途中、所望の時に、画像データの再生を終了できる。本実施形態によれば、この場合でも、再生した部分データまでが正しい部分データであったか否かを検証可能であることは明らかである。

＜変形例３＞
本実施形態においては、検証データとしてＭＡＣを使う例を示したが、本発明はこれに限定されることなく、種々の検証データを適応可能であることは明らかである。ここでは、検証データとしてデジタル署名を適応する場合の例を説明する。

まず、検証データとしてデジタル署名を適用する場合の、検証データ生成処理の構成は図１８と同様であるので詳細な説明は省略する。また、検証データ生成処理の流れは、図２０において、ステップＳ６３０において、鍵取得部４３０で取得された画像配信サーバ３１０の秘密鍵Ｋを利用して、部分データＤ０のデジタル署名を生成するようにすれば良い。（即ち、検証データＦ（ｘ，ｙ）としてデジタル署名生成処理が適応される。）図２０において、ステップＳ６３０以外の処理はＭＡＣを使う場合と同様であるので説明は省略する。

次に、検証データとしてデジタル署名を適用する場合の、検証処理の構成を図２５を用いて説明する。図２５は検証データとしてデジタル署名を適用する場合の検証処理の構成を示す図である。

図２５に示すように、検証データとしてデジタル署名を適用する場合の各部の構成は、図２１に示したような検証データとしてＭＡＣを適用する場合の構成と同じを適応可能であるので詳細な説明は省略する。ただし、デジタル署名を適用する場合、入力部１３１０、検証データ生成部１３３０、検証データ保持部１３４０、及び判定部１３６０の入出力データの関係が異なるため、これについて説明する。

図２５において、入力部１３１０から出力された１番目の検証データＶＤ０は検証データ生成部１３３０、及び検証データ保持部１３４０に入力される。（図２１と異なり、１番目の検証データＶＤ０は判定部１３６０には入力されない。）また、検証データ生成部１３３から出力された検証データＶＤ’’は判定部１３６０に入力される。（図２１と異なり、検証データ保持部１３４０には入力されない）。

次に、検証データとしてデジタル署名を適用する場合の、検証処理の流れを図２６を用いて説明する。図２６はデジタル署名を適応した場合の検証処理の流れを説明するフローチャートである。図２２の処理と同じ処理は説明を省略する。

まず、ステップＳ１４１０ではパラメータｉを初期化する。ここで、パラメータｉは部分データＤｉを特定するパラメータである。そして、ステップ１４２０では、検証データＶＤ０、及び部分データＤ’０を受信する（図２５の１３１０）。

次に、ステップＳ１４３０では、鍵取得部７２０で取得された画像配信サーバ３１０の公開鍵Ｋを利用して、検証データＶＤ０を復号し（図中Ｆ＾−１（・）で示す）、ＶＤ’０を生成する。更に、ステップＳ１４３０では、部分データＤ’０にハッシュ関数を施し、ハッシュ値ＶＤ’’０を算出する（図２５の１３３０）。

ステップＳ１４３０の後、ステップＳ１４４０では、ＶＤ’０とＶＤ’’０が等しいか否かが判定される（図２５の１３６０）。判定の結果、等しい場合、ステップＳ１４５０で「検証成功」と表示し、処理をステップＳ１４７０に進める。さもなければ、ステップＳ１４６０で「検証失敗」と表示し、検証処理を終了する。さらに、検証失敗に連動させて、画像再生クライアント３４０の再生処理を停止させ、画像配信サーバ３１０から新たにデータを受信することを停止させる。

そして、ステップＳ１４７０では、パラメータｉを１だけ増加させる。ステップＳ１４８０では、前述した式２を用いて検証データＶＤｉを算出する（図２５の７５０）。

尚、デジタル署名の生成処理、及びその検証処理は公知の技術であるため、詳細な説明は省略する。尚、本発明においては、デジタル署名生成処理、及びその検証処理のためのアルゴリズムは特に限定せず、ＲＳＡやＤＳＡなど種々のデジタル署名生成アルゴリズムを適応可能である。

（第３の実施の形態）
第２の実施例では、画像配信サーバ３１０から画像再生クライアント３４０へは、画像ＤＢ３２０に保持されている画像データＤの先頭（即ち、Ｄ０）から順に配信する場合の例を示した。しかしながら、本発明はこれに限定されることなく、画像データＤの所望の部分データから配信すること（即ち、頭出し再生機能）も可能である。そこで、本実施形態では、本発明において、画像データＤの所望の部分データから配信する場合の例を説明する。

本実施形態におけるシステム構成は、第２の実施例において図１７を用いて説明した構成と同じ構成とすることが可能であるので、詳細な説明は省略する。以降では、本実施形態における画像配信サーバ３１０内で実行される検証データ生成処理の構成、及び画像再生クライアント３４内０で実行される検証処理の構成を説明する。

まず、本実施形態に適応可能な検証データ生成処理部について図２７を用いて説明する。

図２７は、本実施形態における検証データ生成処理機能を説明する図である。図２７において、第２の実施形態の処理と同様の処理に関しての説明は省略する。ここでは、第２の実施形態と処理の異なる出力部１５７０、及び指定部１５８０について説明する。

まず、指定部１５８０について説明する。指定部１５８０では、所定の部分データを示すパラメータＭが指定され、出力される。ここでは、画像閲覧者がキーボード２１４、或いはマウス２１３などを用いて指定した所望の部分データを示すパラメータＭが、画像配信クライアント３１０に送信され、指定されると考えれば理解しやすい。

次に、出力部１５７０について説明する。出力部１５７０では、部分データＤｉ、検証データＶＤｉ、及びパラメータＭが入力され、パラメータＭに応じて部分データＤｉ、及び検証データＶＤｉが出力されるか否かが判定され、判定の結果に応じて部分データＤｉ、及び検証データＶＤｉが出力される。

本実施形態では、Ｍ＝ｉの場合、部分データＤｉ、検証データＶＤｉ、及び前段の検証データＶＤｉ−１を出力し、Ｍ＞＝ｉの場合、部分データＤｉ、検証データＶＤｉを出力し、Ｍ＜ｉの場合は何も出力しないように出力データを制御する。

以上、本実施形態に適応可能な検証データ生成処理部、及び方法について説明した。

一方、本実施の形態において、画像再生クライアント３４０内で実行される検証処理部の構成は、第２の実施形態において、図２１を用いて説明した構成と同じであるので詳細な説明は省略する。

次に、本実施の形態における、検証データ生成処理の流れ、及び検証処理、及び方法の流れを説明する。

まず、本実施形態における検証データ生成処理流れを図２８を用いて説明する。図２８は本実施形態に適応可能な検証データ生成処理を説明するフローチャートである。

図２８において、第２の実施形態の処理と同様の処理に関しての説明は省略する。以降では、第２の実施形態の処理と異なるステップＳ１０５０、ステップＳ１０６０、ステップＳ１０７０、及びステップＳ１０８０について説明する。

ステップＳ６３０において検証データＶＤｉが生成された後、ステップＳ１０５０では、パラメータｉがＭより大きいか否かが判定される。ここでＭは画像再生クライアント３４０によって指定される、画像データＤの最初の部分データＤＭを特定するパラメータである。即ち、部分データＤＭ以降の部分データが順次、画像配信サーバ３１０から画像再生クライアント３４０に配信されることになる。パラメータｉがＭよりも大きい場合には、処理をステップＳ１０７０に進め、ステップＳ１０７０において部分データＤｉ及び、対応する検証データＶＤｉを出力する（図２７の４７０）。さもなければ、処理をステップＳ１０６０に進める。

続いて、ステップＳ１０６０では、パラメータｉがＭに等しいか否かが判定される。パラメータｉがＭに等しい場合には、処理をステップＳ１０８０に進め、ステップＳ１０８０において、部分データＤｉ、対応する検証データＶＤｉ、及び前段で生成された検証データＶＤｉ−１が出力される（図２７の４７０）。さもなければ、処理をステップＳ１０９０に進める。

以上説明したように、ｉ＜Ｍの場合には、検証データＶＤｉは生成するが出力はしない。そして、ｉ＝Ｍの場合に、部分データＤｉ、検証データＶＤｉ、及び前段（即ち、ｉ＝Ｍ−１）で生成された検証データＶＤｉ−１を出力する。その後、ｉ＞Ｍの場合には、部分データＤｉ、及び検証データＶＤｉを出力するようにする。

次に、本実施形態における検証処理の流れを図２９を用いて説明する。図２９は本実施形態に適応可能な検証処理を説明するフローチャートである。

図２９において、第２の実施形態の処理と同様の処理に関しての説明は省略する。以降では、第２の実施形態の処理と異なるステップＳ２９１、ステップＳ２９２、ステップＳ２９３及びステップＳ２９４について説明する。

ステップＳ２９１ではパラメータｉをＭに初期化し、続いてステップＳ２９２において、画像配信サーバ３１０から配信された、部分データＤ’ｉ、検証データＶＤｉ、及びＶＤｉ−１を受信する（図２１の７１０）。ステップＳ２９３では、前述した式２を用いて検証データＶＤｉを算出する（図２１の７５２９）。

一方、ステップＳ２９４では、画像配信サーバ３１０から配信された、部分データＤ’ｉ、及び検証データＶＤｉを受信する（図２１の７１０）。

以上説明したように、本実施形態では部分データＤＭ以降の部分データＤｉが画像配信サーバ３１０から画像再生クライアント３４０に配信されるため、画像再生クライアント３４０では、部分データＤＭ以降について検証処理を実行する。ここで、ｉ＝Ｍの場合に限り、ステップＳ１１２において、対応する検証データＶＤ’ｉを生成するために、部分データＤ’ｉ、及び検証データＶＤｉに加えてＶＤｉ−１を受信する。一方、ｉ＞Ｍの場合は、第２の実施形態と同様に、ステップＳ２９４において、部分データＤ’ｉ、及び検証データＶＤｉだけを受信するようにする。

ここで、以上説明したような検証データ生成処理、及び検証処理の例について、具体的な例を用いて説明する。

図３０は、本実施形態における検証データ生成処理、及び検証結果例を説明する図である。

図中、３００１は画像配信サーバ３１０において生成される部分データＤｉ、及び検証データＶＤｉを示す。図３０に示す例では、画像データＤは５つの部分データＤ１〜Ｄ４に分割され、夫々に対応する検証データＶＤ０〜ＶＤ４が生成されている。図中、夫々の部分データ、及び検証データの下部には、対応する検証データ生成処理（即ち、式１、或いは式２による演算処理）を示している。また、図３０に示す例では、部分データＤ２以降の部分データＤｉが画像配信サーバ３１０から画像再生クライアント３４０に送信されるものとする。

図３０に示すように、部分データＤ０、及び部分データＤ１は画像再生クライアント３４０には配信されない。（図中、点線で示されている。）また、対応する検証データＶＤ０、及び検証データＶＤ１は生成されるが、配信はされない。

一方、部分データＤ２（画像再生クライアント３４０によって要求された部分データの開始）を配信する際には、検証データＶＤ２に加え、前段で生成された検証データＶＤ１も合わせて配信するようにする。すると、画像再生クライアント３４０では、受信した部分データＤ’２、及び検証データＶＤ１から、検証データＶＤ’２を生成し、受信した検証データＶＤ２と比較することにより、受信した部分データＤ’２が正しい部分データか否かを検証可能となる。

更に、部分データＤ３、及びＤ４を配信する際には、夫々対応する検証データＶＤ３、及びＶＤ４を配信することにより、画像再生クライアント３４０は、受信した部分データＤ’３、及びＤ’４が正しい部分データか否かを検証可能となる。

以上、説明したように、本実施形態によれば、画像データＤの途中から配信される場合でも、配信された部分データと、配信された部分データの順序改竄されていないかを検証することができる。

（その他の実施形態）
また、上記実施形態では、ネットワークを構成するハードウェア等が含まれるものの、各処理部は実際はソフトウェアで実現できるものである。即ち、本発明の目的は、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または、記録媒体）を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（または、ＣＰＵやＭＰＵ）が、記憶媒体に格納されたプログラムコードを読み出し、実行することによっても達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が、上述した実施の形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体が本発明を構成することになる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現される場合に限られない。例えば、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、前述した実施形態の機能が実現される場合も含まれる。つまり、プログラムコードがメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって実現される場合も含まれる。

実施形態１におけるシステムイメージ図である。 実施形態１におけるシステム図である。 実施形態１におけるホストコンピュータを示す図である。 実施形態１における電子文書生成装置のブロック図である。 実施形態１における中間電子文書生成のフローチャートである。 実施形態１における署名データ生成のフローチャートである。 実施形態１における電子データ、及び署名データの構成図である。 実施形態１における署名検証のフローチャートである。 実施形態１における電子化データの一例を説明する図である。 実施形態１における署名生成処理、及び署名検証処理のブロック図である。 実施形態１における公開鍵証明書データの構成図である。 実施形態１における中間電子文書、及び電子化データを説明する図である。 実施形態１における電子文書操作装置のブロック図である。 実施形態１における署名データ検証処理のフローチャートである。 実施形態１における被署名データ検証処理のフローチャートである。 実施形態１における署名データ検証処理の例を示す図である。 実施形態２におけるシステム構成を示す図である。 実施形態２における検証データ生成処理のブロック図である。 実施形態２において部分データ、及び検証データのデータ構造を示す図である。 実施形態２における検証データ生成処理のフローチャートである。 実施形態２における検証処理のブロック図である。 実施形態２における検証処理のフローチャートである。 従来技術における検証処理結果の例を説明する図である。 実施形態２における検証処理結果の例を説明する図である。 実施形態２の変形例３における検証処理のブロック図である。 実施形態２の変形例３における検証処理のフローチャートである。 実施形態３における検証データ生成処理のブロック図である。 実施形態３における検証データ生成処理のフローチャートである。 実施形態３における検証処理のフローチャートである。 実施形態３における検証データ生成処理、及び検証処理結果の例を説明する図である。

Claims (12)

1. 署名データと、被署名データを構成する複数の部分被署名データのうち、少なくとも１つの部分被署名データを受信する受信手段と、
   前記署名データ、及び部分被署名データを用いて署名を検証する署名検証手段と、
   前記署名検証手段による署名検証結果に応じて、前記受信手段を制御する制御手段を有することを特徴とする情報処理装置。
2. 前記署名データは、署名値、被署名データの識別情報、前記被署名データのダイジェスト値を含み、前記署名値は前記被署名データの識別情報と前記部分被署名データから生成されたものであることを特徴とする請求項１に記載の情報処理装置。
3. 更に、前記受信した被署名データを出力する被署名データ出力手段を有し、
   前記制御手段は、前記被署名データ出力手段を制御することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記被署名データは前記署名データの識別情報を含むことを特徴とする請求項２又は３に記載の情報処理装置。
5. 分割された部分データが所定の順を有する部分データを入力する入力手段と、
   第１の部分データの検証データと、前記第１の部分データの次の順である第２の部分データとから、前記第２の部分データの検証データを生成する生成手段と、
   前記第２の部分データと前記第２の部分データの検証データとを送信する送信手段を有することを特徴とする情報処理装置。
6. さらに、検証データを保持する保持手段を有し、前記入力手段は前記所定の順で部分データを入力し、前記生成手段は前記入力された部分データと前記保持手段で保持された検証データに対して処理を行うことを特徴とする請求項５に記載の情報処理装置。
7. 請求項５又は、請求項６に記載の情報処理装置で生成された検証データを検証する情報処理装置であって、
   第２の部分データと第２の部分データの検証データを受信する受信手段と、
   第１の部分データの検証データを保持する保持手段と、
   前記第１の部分データの検証データと前記第２の部分データから、検証データを生成する生成手段と、
   前記生成手段で生成された検証データと、前記入力手段で入力された検証データより検証データを検証する検証手段と、
   前記検証手段による検証結果に応じて、前記受信手段を制御する制御手段を有することを特徴とする情報処理装置。
8. 署名データを受信する署名データ受信工程と、
   被署名データを構成する複数の部分被署名データのうち、少なくとも１つの部分被署名データを受信する部分被署名データ受信工程と、
   前記署名データ、及び部分被署名データを用いて署名を検証する署名検証工程と、
   前記署名検証工程による署名検証結果に応じて、前記被署名データの出力、または、被署名データの受信を制御する制御工程を有することを特徴とする情報処理方法。
9. 分割された部分データが所定の順を有する部分データを入力する入力工程と、
   第１の部分データの検証データと、前記第１の部分データの次の順である第２の部分データとから、前記第２の部分データの検証データを生成する生成工程と、
   前記第２の部分データと前記第２の部分データの検証データとを送信する送信工程を有することを特徴とする情報処理方法。
10. 請求項９に記載の情報処理方法で生成された検証データを検証する情報処理方法であって、
    第２の部分データと第２の部分データの検証データを受信する受信工程と、
    第１の部分データの検証データを保持する保持工程と、
    前記第１の部分データの検証データと前記第２の部分データから、検証データを生成する生成工程と、
    前記生成手段で生成された検証データと、前記入力手段で入力された検証データより検証データを検証する検証工程と、
    前記検証手段による検証結果に応じて、前記被署名データの出力、または、被署名データの受信を制御する制御工程を有することを特徴とする情報処理方法。
11. 請求項８〜１０の何れか１項に記載の情報処理方法を実行するコンピュータプログラム。
12. 請求項１１に記載のコンピュータプログラムを格納することを特徴とするコンピュータ可読記憶媒体。
    

Images