JP2022092105A - 情報処理プログラム、情報処理方法、情報処理装置および情報処理システム - Google Patents

Abstract

【課題】電子文書に付加する証明書の情報量を抑えて伝送効率の悪化を回避すること。【解決手段】企業Ａ（署名装置２０１）は、送付者（利用者端末２０２）からの署名要求に応じて、認証企業Ｘ（認証サーバ２０５）から、企業Ａや企業Ａの代表者（署名者）としてのＣｒｅｄｅｎｔｉａｌを取得する。企業Ａ（署名装置２０１）は、ＣｒｅｄｅｎｔｉａｌからＰｒｏｏｆを作成し、ＰｒｏｏｆをＰｒｏｏｆ（１）とＰｒｏｏｆ（２）とに分割する。企業Ａ（署名装置２０１）は、ＩＤ流通基盤２２０を介して、Ｐｒｏｏｆ（２）を検証企業Ｙ（検証サーバ２０４）に送信する。企業Ａ（署名装置２０１）は、電子文書ＤにＰｒｏｏｆ（１）を付加して、企業Ａの秘密鍵で署名（電子署名Ｓ）を行い、「電子文書Ｄ＋Ｐｒｏｏｆ（１）＋電子署名Ｓ」を送付者（利用者端末２０２）に送信する。【選択図】図１２

Description

本発明は、情報処理プログラム、情報処理方法、情報処理装置および情報処理システムに関する。

近年、デジタル化されたアイデンティティ情報（ＩＤ情報）を、証明書として本人の同意のもとに安心・安全・簡単に流通させる、分散型のＩＤ流通基盤が注目されている。ＩＤ流通基盤のユースケースとしては、例えば、文書に組織や代表者の電子署名を付与して送付し、相手側で電子署名を用いて文書の真正性を検証するものがある。

先行技術としては、端末が、電子割符を用いて原データから複数の分割データを生成し、一部の分割データを証明サーバに送信し、他の分割データを保管サーバに送信し、証明サーバが、分割データの非改ざんを証明する証明情報を生成し、証明情報と時刻情報を含む証拠情報を生成し、分割データと証拠情報を関連付けて記憶するものがある。また、クライアント端末から送られてくる電子文書を原本性保証電子保存装置に保存し、クライアント端末から送られてくる電子文書参照要求に応じて、原本性保証電子保存装置に保存されている該当する電子文書を読み出して、クライアント端末に送る技術がある。

特開２０１３－１７９５６９号公報 特開２００４－０１３４８８号公報

しかしながら、従来技術では、電子文書の真正性を検証するにあたり、署名者の属性を確認したり、その正しさを検証したりすることが難しい。例えば、署名者の属性を証明する証明書を電子文書に添付することが考えられるが、電子文書に対する証明書の情報量が増加して、伝送効率の悪化を招くという問題がある。

一つの側面では、本発明は、電子文書に付加する証明書の情報量を抑えて伝送効率の悪化を回避することを目的とする。

１つの実施態様では、電子文書に対する署名要求に応じて、前記電子文書のデータ量に基づいて、署名者の属性情報と当該属性情報を証明するための証明情報とを含む証明書情報から、第１の部分証明書情報と第２の部分証明書情報とを作成し、前記電子文書および前記第１の部分証明書情報に対する電子署名を生成し、生成した前記電子署名を前記電子文書および前記第１の部分証明書情報に付与して、前記電子文書の提出元に送信し、前記電子文書の提出元と提出先とを接続する経路とは異なる別の経路を用いて、前記署名者の証明書情報の真正性を検証する検証装置に前記第２の部分証明書情報を送信する、情報処理プログラムが提供される。

本発明の一側面によれば、電子文書に付加する証明書の情報量を抑えて伝送効率の悪化を回避することができるという効果を奏する。

図１は、実施の形態にかかる情報処理方法の一実施例を示す説明図である。 図２は、情報処理システム２００のシステム構成例を示す説明図である。 図３は、署名装置２０１のハードウェア構成例を示すブロック図である。 図４は、検証サーバ２０４のハードウェア構成例を示すブロック図である。 図５は、マッチングテーブル２３０の記憶内容の一例を示す説明図である。 図６は、Ｃｒｅｄｅｎｔｉａｌの具体例を示す説明図である。 図７は、Ｐｒｏｏｆの具体例を示す説明図である。 図８は、証明情報の具体例を示す説明図である。 図９は、署名装置２０１の機能的構成例を示すブロック図である。 図１０は、Ｐｒｏｏｆ（１）の組合せパターン例を示す説明図である。 図１１は、検証サーバ２０４の機能的構成例を示すブロック図である。 図１２は、情報処理システム２００の動作例を示す説明図である。 図１３は、電子署名の付与例および検証例を示す説明図である。 図１４Ａは、Ｐｒｏｏｆの再構成例を示す説明図（その１）である。 図１４Ｂは、Ｐｒｏｏｆの再構成例を示す説明図（その２）である。 図１４Ｃは、Ｐｒｏｏｆの再構成例を示す説明図（その３）である。 図１５は、Ｐｒｏｏｆの検証依頼を行う際の操作例を示す説明図である。 図１６は、情報処理システム２００の検証処理手順の一例を示すシーケンス図（その１）である。 図１７は、情報処理システム２００の検証処理手順の一例を示すシーケンス図（その２）である。 図１８は、情報処理システム２００の検証処理手順の一例を示すシーケンス図（その３）である。 図１９は、署名装置２０１のＰｒｏｏｆ分割処理の具体的な処理手順の一例を示すフローチャートである。 図２０は、検証サーバ２０４の検証処理の具体的な処理手順の一例を示すフローチャートである。

以下に図面を参照して、本発明にかかる情報処理プログラム、情報処理方法、情報処理装置および情報処理システムの実施の形態を詳細に説明する。

（実施の形態）
図１は、実施の形態にかかる情報処理方法の一実施例を示す説明図である。図１において、情報処理装置１０１は、電子署名を用いて電子文書の真正性を検証するにあたり、署名者の属性を確認し、その正しさを検証可能にするコンピュータである。電子文書は、電子的形態で使用されるコンテンツである。

例えば、電子文書は、各種アプリケーションによって作成される文書や画像である。また、電子文書は、紙の文書などをスキャナにより読み込んで電子データとして保存したものであってもよい。電子署名は、データ（電子文書）の真正性（正当性）を証明するための情報である。電子署名は、例えば、公開鍵暗号方式を利用することによって実現することができる。

ここで、電子署名を用いて電子文書の真正性を検証するにあたり、署名者の属性を把握した上で、電子文書の正しさを担保したい場合がある。例えば、ある企業の請求書を発行する際に、その企業の代表者の署名が必要であるとする。この場合、署名者の属性を確認できなければ、請求書が改ざんされていないことは確認できても、本当に代表者の署名であるかどうかわからない。

すなわち、電子署名を付与しただけでは、署名者の属性を確認したり、その正しさを検証したりすることができない。このため、例えば、署名者の属性を証明する証明書情報を電子文書に添付することが考えられる。証明書情報は、署名者の属性情報と、当該属性情報を証明するための証明情報とを含む。

属性情報は、ヒトやモノが持つ固有の性質・特徴に関する情報（名前、性別、年齢、職業、役職など）である。証明情報は、属性情報を証明するための情報であり、例えば、複数の変数群を含む。証明書情報の検証は、例えば、属性情報と、証明情報と、証明書の発行者の公開鍵とをもとに、ゼロ知識証明と呼ばれるプロトコルを用いて行われる。

しかしながら、証明情報は、データ量（サイズ）が大きくなる傾向がある。例えば、証明情報は、元の電子文書や属性情報に比べて１０倍程度のデータ量となることが多い。このため、電子文書に証明書情報を付与すると、電子文書に対するデータ量が大きくなり、通信のオーバーヘッドが増加して伝送効率が低下する。

そこで、本実施の形態では、電子文書の真正性を検証するにあたり、署名者の属性を確認し、その正しさを検証可能にするとともに、電子文書に付加する証明書の情報量を抑えて伝送効率の悪化を回避する情報処理方法について説明する。以下、情報処理装置１０１の処理例について説明する。

（１）情報処理装置１０１は、電子文書に対する署名要求に応じて、電子文書のデータ量に基づいて、証明書情報から第１の部分証明書情報と第２の部分証明書情報とを作成する。ここで、署名要求は、電子文書に対して電子署名を付与するよう要求するものである。署名要求には、署名対象となる電子文書が含まれる。

証明書情報は、署名者の属性情報と、当該属性情報を証明するための証明情報とを含む。証明書情報は、例えば、認証機関により発行される署名者の属性証明書情報（Ｃｒｅｄｅｎｔｉａｌ）に基づき作成されるＰｒｏｏｆである。属性証明書情報は、利用者（署名者）の属性証明書を示す情報である。

属性証明書情報は、例えば、利用者がアイデンティティ情報に結びついた正当な者であることを証明するための情報である。アイデンティティ情報は、例えば、利用者を定義する属性（属性と属性値）の集合である。属性は、例えば、氏名、住所、生年月日、マイナンバー、年齢、職業、役職、経歴などである。

認証機関は、利用者（署名者）のアイデンティティ情報を管理する機関であり、例えば、特定の企業（認証企業）や、企業内の特定の部署である。より詳細に説明すると、例えば、証明書情報は、属性証明書情報の一部の情報を開示したものであってもよく、属性証明書情報の一部の情報を秘匿化したものであってもよく、属性証明書情報がある条件を満たすかを証明したものであってもよい。

具体的には、例えば、情報処理装置１０１は、証明書情報を属性情報と証明情報とに分割し、属性情報の要約値と証明情報の要約値とを生成する。要約値は、例えば、データ（属性情報、証明情報）に対してハッシュ関数（暗号学的一方向性ハッシュ関数）を用いて生成されるハッシュ値である。

暗号学的一方向性ハッシュ関数を用いて生成されるハッシュ値は、生成元のデータからしか生成することができない唯一の情報となり、生成されたハッシュ値から元のデータを復元することができないという特徴を有する。また、ハッシュ関数によれば、例えば、データを一定のサイズ（長さ）に圧縮することができる。

そして、情報処理装置１０１は、電子文書のデータ量に対する第１の部分証明書情報のデータ量の割合が所定値以下となるように、属性情報、証明情報、属性情報の要約値および証明情報の要約値を、第１の部分証明書情報と第２の部分証明書情報とに分割する。所定値は、任意に設定可能であり、例えば、２０％程度の値に設定される。

図１の例では、電子文書１１０の提出元１０２からの署名要求に応じて、電子文書１１０のデータ量に対する第１の部分証明書情報１２１のデータ量の割合が所定値以下となるように、証明書情報１２０から第１の部分証明書情報１２１と第２の部分証明書情報１２２とが作成された場合を想定する。

（２）情報処理装置１０１は、第１の部分証明書情報および電子文書に対する電子署名を生成する。具体的には、例えば、情報処理装置１０１は、電子文書に第１の部分証明書情報を付加し、署名者の秘密鍵に基づいて、第１の部分証明書情報を付加した電子文書に対する電子署名を生成する。

より詳細に説明すると、例えば、情報処理装置１０１は、ハッシュ関数を用いて、第１の部分証明書情報を付加した電子文書のハッシュ値を算出する。そして、情報処理装置１０１は、署名者の秘密鍵を用いて、算出したハッシュ値を暗号化することにより、電子署名を生成する。

図１の例では、署名者１０４の秘密鍵に基づいて、第１の部分証明書情報１２１を付加した電子文書１１０に対する電子署名１３０が生成される。なお、情報処理装置１０１は、署名者１０４の秘密鍵に基づいて、電子文書１１０、第１の部分証明書情報１２１のそれぞれに対する電子署名を生成することにしてもよい。

（３）情報処理装置１０１は、生成した電子署名を、電子文書および第１の部分証明書情報に付与して、電子文書の提出元に送信する。また、情報処理装置１０１は、電子文書の提出元と提出先とを接続する経路とは異なる別の経路を用いて、検証装置１０５に第２の部分証明書情報を送信する。

電子文書の提出元は、提出先に電子文書（例えば、ある企業Ａの請求書）を送付する送付者（例えば、ある企業Ａの従業員）に相当する。電子文書の提出先は、提出元から送付された電子文書を受信する受信者（例えば、ある企業Ａの経理担当者や、請求先の企業Ｂの従業員）に相当する。検証装置１０５は、署名者の証明書情報（属性情報）の真正性を検証する検証者に相当する。

情報処理装置１０１と検証装置１０５は、電子文書の提出元と電子文書の提出先とを接続する経路とは異なる別の経路によって接続される。別の経路は、例えば、ＩＤ流通基盤によって提供される。ＩＤ流通基盤は、デジタル化されたアイデンティティ情報を、安心・安全・簡単に流通させるためのプラットフォームである。

検証装置１０５は、電子文書の提出先から第１の部分証明書情報を受信し、情報処理装置１０１から第２の部分証明書情報を受信する。そして、検証装置１０５は、受信した第１の部分証明書情報と、受信した第２の部分証明書情報とに基づいて、証明書情報の真正性を検証する。

図１の例では、第１の部分証明書情報１２１を付加した電子文書１１０に電子署名１３０が付与されて、電子文書１１０の提出元１０２に送信される。また、電子文書１１０の提出元１０２と提出先１０３とを接続する経路とは異なる別の経路を用いて、検証装置１０５に第２の部分証明書情報１２２が送信される。

このように、情報処理装置１０１によれば、電子署名を用いて電子文書の真正性を検証するにあたり、署名者の属性を確認可能にするとともに、その正しさを検証可能にすることができる。また、証明書情報を２つに分割することで、電子文書に付加する証明書の情報量を抑えることができる。

図１の例では、電子文書１１０の真正性を検証するにあたり、電子文書１１０の提出先１０３において、署名者の属性や、その正しさを確認することが可能となる。また、証明書情報１２０を２つに分割することで、電子文書１１０に付加する証明書の情報量を抑えて、伝送効率の悪化を回避することができる。

（情報処理システム２００のシステム構成例）
つぎに、実施の形態にかかる情報処理システム２００のシステム構成例について説明する。情報処理システム２００は、図１に示した情報処理装置１０１を含むコンピュータシステムの一例である。情報処理システム２００は、例えば、デジタル化されたアイデンティティ情報（ＩＤ情報）を、証明書として本人の同意のもとに流通させるＩＤ流通基盤に適用される。

以下の説明では、図１に示した情報処理装置１０１を、情報処理システム２００内の署名装置２０１に適用した場合を例に挙げて説明する。また、署名者の属性証明書情報を「Ｃｒｅｄｅｎｔｉａｌ（クレデンシャル）」と表記し、属性証明書情報から作成される証明書情報を「Ｐｒｏｏｆ（プルーフ）」と表記する場合がある。

図２は、情報処理システム２００のシステム構成例を示す説明図である。図２において、情報処理システム２００は、署名装置２０１と、利用者端末２０２と、利用者端末２０３と、検証サーバ２０４と、認証サーバ２０５と、を含む。情報処理システム２００において、署名装置２０１、利用者端末２０２、利用者端末２０３および検証サーバ２０４は、有線または無線のネットワーク２１０を介して接続される。ネットワーク２１０は、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどである。また、署名装置２０１、検証サーバ２０４および認証サーバ２０５は、ＩＤ流通基盤２２０に含まれる。ＩＤ流通基盤２２０において、署名装置２０１、検証サーバ２０４および認証サーバ２０５は、専用のネットワークを介して接続される。ＩＤ流通基盤２２０は、１つのプラットフォームであり、例えば、クラウドにより実現される。

ここで、署名装置２０１は、電子文書に署名（電子署名）を行うコンピュータである。署名装置２０１は、例えば、署名者が使用するＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）である。

利用者端末２０２は、電子文書の提出元（送付者）となる利用者が使用するコンピュータである。利用者端末２０３は、電子文書の提出先（受信者）となる利用者が使用するコンピュータである。利用者端末２０２，２０３は、例えば、ＰＣ、タブレットＰＣなどである。図１に示した提出元１０２は、例えば、利用者端末２０２に相当する。図１に示した提出先１０３は、例えば、利用者端末２０３に相当する。

検証サーバ２０４は、マッチングテーブル２３０を有し、署名者のＰｒｏｏｆ（証明書情報）の真正性を検証するコンピュータである。図１に示した検証装置１０５は、例えば、検証サーバ２０４に相当する。マッチングテーブル２３０の記憶内容の一例については、図５を用いて後述する。

認証サーバ２０５は、利用者（署名者）のＣｒｅｄｅｎｔｉａｌ（属性証明書情報）を管理するコンピュータである。認証サーバ２０５は、例えば、認証企業（認証機関）のサーバである。Ｃｒｅｄｅｎｔｉａｌの具体例については、図６を用いて後述する。また、Ｃｒｅｄｅｎｔｉａｌから作成されるＰｒｏｏｆの具体例については、図７を用いて後述する。

なお、図２の例では、署名装置２０１、利用者端末２０２（提出元）、利用者端末２０３（提出先）、検証サーバ２０４および認証サーバ２０５を、それぞれ１台のみ表記したが、これに限らない。例えば、情報処理システム２００には、署名装置２０１、利用者端末２０２（提出元）、利用者端末２０３（提出先）、検証サーバ２０４および認証サーバ２０５が、それぞれ複数台含まれていてもよい。

（署名装置２０１のハードウェア構成例）
つぎに、署名装置２０１のハードウェア構成例について説明する。

図３は、署名装置２０１のハードウェア構成例を示すブロック図である。図３において、署名装置２０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、メモリ３０２と、ディスクドライブ３０３と、ディスク３０４と、通信Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０５と、ディスプレイ３０６と、入力装置３０７と、可搬型記録媒体Ｉ／Ｆ３０８と、可搬型記録媒体３０９と、を有する。また、各構成部はバス３００によってそれぞれ接続される。

ここで、ＣＰＵ３０１は、署名装置２０１の全体の制御を司る。ＣＰＵ３０１は、複数のコアを有していてもよい。メモリ３０２は、例えば、ＲＯＭ、ＲＡＭおよびフラッシュＲＯＭなどを有する記憶部である。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ３０１のワークエリアとして使用される。メモリ３０２に記憶されるプログラムは、ＣＰＵ３０１にロードされることで、コーディングされている処理をＣＰＵ３０１に実行させる。

ディスクドライブ３０３は、ＣＰＵ３０１の制御に従ってディスク３０４に対するデータのリード／ライトを制御する。ディスク３０４は、ディスクドライブ３０３の制御で書き込まれたデータを記憶する。ディスク３０４としては、例えば、磁気ディスク、光ディスクなどが挙げられる。

通信Ｉ／Ｆ３０５は、通信回線を通じてネットワーク（例えば、図２に示したネットワーク２１０、ＩＤ流通基盤２２０）に接続され、ネットワークを介して外部のコンピュータ（例えば、利用者端末２０２、検証サーバ２０４、認証サーバ２０５）に接続される。そして、通信Ｉ／Ｆ３０５は、ネットワークと自装置内部とのインターフェースを司り、外部装置からのデータの入出力を制御する。

ディスプレイ３０６は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する表示装置である。ディスプレイ３０６としては、例えば、液晶ディスプレイや有機ＥＬ（Ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどを採用することができる。

入力装置３０７は、文字、数字、各種指示などの入力のためのキーを有し、データの入力を行う。入力装置３０７は、キーボードやマウスなどであってもよく、また、タッチパネル式の入力パッドやテンキーなどであってもよい。

可搬型記録媒体Ｉ／Ｆ３０８は、ＣＰＵ３０１の制御に従って可搬型記録媒体３０９に対するデータのリード／ライトを制御する。可搬型記録媒体３０９は、可搬型記録媒体Ｉ／Ｆ３０８の制御で書き込まれたデータを記憶する。可搬型記録媒体３０９としては、例えば、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）－ＲＯＭ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリなどが挙げられる。

なお、署名装置２０１は、上述した構成部のうち、例えば、ディスクドライブ３０３、ディスク３０４、可搬型記録媒体Ｉ／Ｆ３０８、可搬型記録媒体３０９を有していなくてもよい。また、図２に示した利用者端末２０２，２０３についても、署名装置２０１と同様のハードウェア構成により実現することができる。

（検証サーバ２０４のハードウェア構成例）
つぎに、検証サーバ２０４のハードウェア構成例について説明する。

図４は、検証サーバ２０４のハードウェア構成例を示すブロック図である。図４において、検証サーバ２０４は、ＣＰＵ４０１と、メモリ４０２と、ディスクドライブ４０３と、ディスク４０４と、通信Ｉ／Ｆ４０５と、可搬型記録媒体Ｉ／Ｆ４０６と、可搬型記録媒体４０７と、を有する。また、各構成部は、バス４００によってそれぞれ接続される。

ここで、ＣＰＵ４０１は、検証サーバ２０４の全体の制御を司る。ＣＰＵ４０１は、複数のコアを有していてもよい。メモリ４０２は、例えば、ＲＯＭ、ＲＡＭおよびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭがＯＳのプログラムを記憶し、ＲＯＭがアプリケーションプログラムを記憶し、ＲＡＭがＣＰＵ４０１のワークエリアとして使用される。メモリ４０２に記憶されるプログラムは、ＣＰＵ４０１にロードされることで、コーディングされている処理をＣＰＵ４０１に実行させる。

ディスクドライブ４０３は、ＣＰＵ４０１の制御に従ってディスク４０４に対するデータのリード／ライトを制御する。ディスク４０４は、ディスクドライブ４０３の制御で書き込まれたデータを記憶する。ディスク４０４としては、例えば、磁気ディスク、光ディスクなどが挙げられる。

通信Ｉ／Ｆ４０５は、通信回線を通じてネットワーク（例えば、図２に示したネットワーク２１０、ＩＤ流通基盤２２０）に接続され、ネットワークを介して外部のコンピュータ（例えば、図２に示した署名装置２０１、利用者端末２０３）に接続される。そして、通信Ｉ／Ｆ４０５は、ネットワークと装置内部とのインターフェースを司り、外部のコンピュータからのデータの入出力を制御する。通信Ｉ／Ｆ４０５には、例えば、モデムやＬＡＮアダプタなどを採用することができる。

可搬型記録媒体Ｉ／Ｆ４０６は、ＣＰＵ４０１の制御に従って可搬型記録媒体４０７に対するデータのリード／ライトを制御する。可搬型記録媒体４０７は、可搬型記録媒体Ｉ／Ｆ４０６の制御で書き込まれたデータを記憶する。

なお、検証サーバ２０４は、上述した構成部のほかに、例えば、入力装置、ディスプレイ等を有することにしてもよい。また、検証サーバ２０４は、上述した構成部のうち、例えば、ディスクドライブ４０３、ディスク４０４、可搬型記録媒体Ｉ／Ｆ４０６、可搬型記録媒体４０７を有していなくてもよい。また、図２に示した認証サーバ２０５についても、検証サーバ２０４と同様のハードウェア構成により実現することができる。

（マッチングテーブル２３０の記憶内容）
つぎに、図５を用いて、検証サーバ２０４が有するマッチングテーブル２３０の記憶内容について説明する。マッチングテーブル２３０は、例えば、図４に示した検証サーバ２０４のメモリ４０２、ディスク４０４などの記憶装置により実現される。

図５は、マッチングテーブル２３０の記憶内容の一例を示す説明図である。図５において、マッチングテーブル２３０は、ａ＿ｈａｓｈ、ｂ＿ｈａｓｈ、ａおよびｂのフィールドを有し、各フィールドに情報を設定することで、マッチングデータ（例えば、マッチングデータ５００－１～５００－３）をレコードとして記憶する。

ここで、ａ＿ｈａｓｈは、Ｐｒｏｏｆに含まれる属性情報のハッシュ値である。ｂ＿ｈａｓｈは、Ｐｒｏｏｆに含まれる証明情報のハッシュ値である。ａは、Ｐｒｏｏｆに含まれる属性情報である。ｂは、Ｐｒｏｏｆに含まれる証明情報である。

例えば、マッチングデータ５００－１は、ａ＿ｈａｓｈ「ｘｘｘ１」とｂ＿ｈａｓｈ「ｙｙｙ１」とを示す。マッチング情報５００－１のａおよびｂの各フィールドは空白である。

（Ｃｒｅｄｅｎｔｉａｌの具体例）
つぎに、図６を用いて、Ｃｒｅｄｅｎｔｉａｌの具体例について説明する。

図６は、Ｃｒｅｄｅｎｔｉａｌの具体例を示す説明図である。図６において、Ｃｒｅｄｅｎｔｉａｌ６００は、認証サーバ２０５から発行されるＣｒｅｄｅｎｔｉａｌ（属性証明書情報）の一例である。Ｃｒｅｄｅｎｔｉａｌ６００は、署名者の属性を証明する情報である。

ここでは、署名者の属性として、役職「社長」、氏名「富士太郎」、住所「川崎市中原区ＸＸＸ」、生年月日「１９８８／１／１」、マイナンバー「１２３４５６…」、年齢「３２」が示されている。また、Ｃｒｅｄｅｎｔｉａｌ６００には、電子署名の仕組みに基づき、発行者（例えば、認証企業）の秘密鍵で署名「ＸＸＸＸ」が付与されている。

（Ｐｒｏｏｆの具体例）
つぎに、図７を用いて、Ｐｒｏｏｆの具体例について説明する。

図７は、Ｐｒｏｏｆの具体例を示す説明図である。図７において、Ｐｒｏｏｆ７００は、図６に示したＣｒｅｄｅｎｔｉａｌ６００から作成されるＰｒｏｏｆ（証明書情報）の一例である。Ｐｒｏｏｆ７００は、属性情報７１０と、証明情報７２０とを含む。

属性情報７１０は、開示属性の情報７１１と、秘匿属性の情報７１２と、条件証明の情報７１３とを含む。開示属性の情報７１１は、Ｃｒｅｄｅｎｔｉａｌ６００のうち開示する情報である。秘匿属性の情報７１２は、Ｃｒｅｄｅｎｔｉａｌ６００のうち開示する必要のない属性を墨塗処理により秘匿した情報である。

条件証明の情報７１３は、Ｃｒｅｄｅｎｔｉａｌ６００に含まれる年齢が３０才以上であるかという条件を満たすことを証明した情報（範囲証明）である。証明情報７２０は、属性情報７１０を証明するための情報（複数の変数群）である。証明情報７２０の具体例については、図８を用いて後述する。

図８は、証明情報の具体例を示す説明図である。図８において、証明情報８００（例えば、図７に示した証明情報７２０に相当）は、ＺＫＰ（ゼロ知識証明）のレスポンス群を含む。ｐｒｉｍａｒｙ＿ｐｒｏｏｆは、属性に関するＺＫＰのレスポンス群である。ｒｅｖｅａｌｅｄ＿ａｔｔｒｉｂｕｔｅｓは、開示属性を示す。

ｎａｍｅ＃１：ｖａｌｕｅ＃１等は、個々の開示属性の値を示す。個々の開示属性の値のビット数は、個々の開示属性の値に依存する。ｕｎｒｅｖｅａｌｅｄ＿ａｔｔｒｉｂｕｔｅｓは、秘匿属性を示す。ｍｊ＿ｈａｔ＃１等は、個々の秘匿属性のＺＫＰのレスポンスを示す。個々の秘匿属性のＺＫＰのレスポンスのビット数は、例えば、５９２［ｂｉｔ］である。

ｃｒｅｄｅｎｔｉａｌ＿ｓｉｇａｎｔｕｒｅ＿ＺＫＰは、Ｃｒｅｄｅｎｔｉａｌの署名（Ａ，ｖ，ｅ）のＺＫＰのレスポンスを示す。ｃｒｅｄｅｎｔｉａｌ＿ｓｉｇａｎｔｕｒｅ＿ＺＫＰのビット数は、例えば、５５６４［ｂｉｔ］である（ａ＿ｐｒｉｍｅ：２０４８［ｂｉｔ］、ｅ＿ｈａｔ：４５６［ｂｉｔ］、ｖ＿ｈａｔ：３０６０［ｂｉｔ］）。

ｐｒｅｄｉｃａｔｅ＿ａｔｔｒｉｂｕｔｅは、条件証明を示す。ｕ＿ｈａｔ１，，ｕ＿ｈａｔ４等は、各条件証明に対するＺＫＰのレスポンスを示す。ｐｒｅｄｉｃａｔｅ＿ａｔｔｒｉｂｕｔｅのビット数は、例えば、８５１５［ｂｉｔ］である（ｕ＿ｈａｔ１，，ｕ＿ｈａｔ４：２３６８［ｂｉｔ］、ｒ＿ｈａｔ１，，ｒ＿ｈａｔ４：２３８８［ｂｉｔ］、ｒ＿ｈａｔ＿ｄｅｌｔａ：６７２［ｂｉｔ］、ａｌｆａ＿ｈａｔ：２７８７［ｂｉｔ］）。

ｎｏｎ＿ｒｅｖｏｃ＿ｐｒｏｏｆは、非失効証明のＺＫＰのレスポンスを示す。ｎｏｎ＿ｒｅｖｏｃ＿ｐｒｏｏｆ（ｘ＿ｌｉｓｔ）のビット数は、例えば、１４３３６［ｂｉｔ］である。ａｇｇｒｅｇａｔｅｄ＿ｐｒｏｏｆは、チャレンジｈａｓｈを示す。ａｇｇｒｅｇａｔｅｄ＿ｐｒｏｏｆ（ｃ＿ｈａｓｈ）のビット数は、例えば、２５６［ｂｉｔ］である。

証明情報８００によれば、ＺＫＰ（ゼロ知識証明）レスポンスとチャレンジｈａｓｈから、ＺＫＰプロトコルにより証明属性の正しさを検証することができる。

（署名装置２０１の機能的構成例）
図９は、署名装置２０１の機能的構成例を示すブロック図である。図９において、署名装置２０１は、受付部９０１と、取得部９０２と、作成部９０３と、分割部９０４と、生成部９０５と、第１の通信部９０６と、第２の通信部９０７と、を含む。取得部９０２～第２の通信部９０７は制御部となる機能であり、具体的には、例えば、図３に示したメモリ３０２、ディスク３０４、可搬型記録媒体３０９などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、通信Ｉ／Ｆ３０５により、その機能を実現する。各機能部の処理結果は、例えば、メモリ３０２、ディスク３０４などの記憶装置に記憶される。

受付部９０１は、電子文書に対する署名要求を受け付ける。署名要求は、電子文書に対して電子署名を付与するよう要求するものである。署名要求には、署名対象となる電子文書が含まれる。以下の説明では、署名対象となる電子文書を「電子文書Ｄ」と表記する場合がある。

具体的には、例えば、受付部９０１は、図２に示した利用者端末２０２から署名要求を受信することにより、電子文書Ｄに対する署名要求を受け付ける。また、受付部９０１は、図３に示した入力装置３０７を用いたユーザの操作入力により、電子文書Ｄに対する署名要求を受け付けることにしてもよい。

取得部９０２は、認証機関により発行される署名者のＣｒｅｄｅｎｔｉａｌ（属性証明書情報）を取得する。具体的には、例えば、取得部９０２は、電子文書Ｄに対する署名要求に応じて、図２に示した認証サーバ２０５（例えば、認証企業）から、ＩＤ流通基盤２２０経由で、Ｃｒｅｄｅｎｔｉａｌ６００（図６参照）を取得する。

ただし、署名者のＣｒｅｄｅｎｔｉａｌは、例えば、電子文書Ｄに対する署名要求に先だって、予め取得されることにしてもよい。

作成部９０３は、署名者のＣｒｅｄｅｎｔｉａｌに基づいて、署名者のＰｒｏｏｆ（証明書情報）を作成する。Ｐｒｏｏｆは、署名者の属性情報と、当該属性情報を証明するための証明情報とを含む。属性情報は、例えば、Ｃｒｅｄｅｎｔｉａｌに含まれる属性の情報（開示属性）、Ｃｒｅｄｅｎｔｉａｌに含まれる属性の情報を秘匿化した情報（秘匿属性）およびＣｒｅｄｅｎｔｉａｌに含まれる属性の情報が特定の条件を満たすことを証明する情報（条件証明）のうちの少なくともいずれかを含む。

具体的には、例えば、作成部９０３は、入力装置３０７を用いたユーザの操作入力により、取得されたＣｒｅｄｅｎｔｉａｌ６００に基づいて、開示する必要のない属性を秘匿したり、ある条件を満たすかを証明したりすることで、Ｐｒｏｏｆ７００（図７参照）を作成する。

なお、署名装置２０１は、Ｃｒｅｄｅｎｔｉａｌをもとに作成されたＰｒｏｏｆを、他のコンピュータや可搬型記録媒体Ｉ／Ｆ３０８などから取得することにしてもよい。

分割部９０４は、電子文書Ｄのデータ量に基づいて、Ｐｒｏｏｆ（証明書情報）から、第１の部分証明書情報と第２の部分証明書情報とを作成する。以下の説明では、Ｐｒｏｏｆから作成される第１の部分証明書情報を「Ｐｒｏｏｆ（１）」と表記し、Ｐｒｏｏｆから作成される第２の部分証明書情報を「Ｐｒｏｏｆ（２）」と表記する場合がある。

具体的には、例えば、分割部９０４は、Ｐｒｏｏｆを属性情報と証明情報とに分割し、属性情報のハッシュ値と証明情報のハッシュ値とを生成する。そして、分割部９０４は、電子文書Ｄのデータ量に対するＰｒｏｏｆ（１）のデータ量の割合が所定値α以下となるように、属性情報、証明情報、属性情報の要約値および証明情報の要約値を、Ｐｒｏｏｆ（１）とＰｒｏｏｆ（２）とに分割する。

この際、分割部９０４は、例えば、第１の組合せ（ａ，ｂ）、第２の組合せ（ａ，ｂ＿ｈａｓｈ）および第３の組合せ（ａ＿ｈａｓｈ，ｂ＿ｈａｓｈ）のうち、第１の組合せ（ａ，ｂ）または第２の組合せ（ａ，ｂ＿ｈａｓｈ）を、第３の組合せ（ａ＿ｈａｓｈ，ｂ＿ｈａｓｈ）よりも優先してＰｒｏｏｆ（１）とする。

また、分割部９０４は、第１の組合せ（ａ，ｂ）を、第２の組合せ（ａ，ｂ＿ｈａｓｈ）および第３の組合せ（ａ＿ｈａｓｈ，ｂ＿ｈａｓｈ）よりも優先してＰｒｏｏｆ（１）とすることにしてもよい。ただし、ａは、属性情報である。ｂは、証明情報である。ａ＿ｈａｓｈは、属性情報のハッシュ値である。ｂ＿ｈａｓｈは、証明情報のハッシュ値である。

ここで、図１０を用いて、Ｐｒｏｏｆ（１）の組合せパターンについて説明する。

図１０は、Ｐｒｏｏｆ（１）の組合せパターン例を示す説明図である。図１０において、（ｉ）は、属性情報と証明情報とからなる第１の組合せ（ａ，ｂ）を示す。（ｉｉ）は、属性情報と証明情報のハッシュ値とからなる第２の組合せ（ａ，ｂ＿ｈａｓｈ）を示す。（ｉｉｉ）は、属性情報のハッシュ値と証明情報のハッシュ値とからなる第３の組合せ（ａ＿ｈａｓｈ，ｂ＿ｈａｓｈ）を示す。

総データ量は「（ｉｉｉ）→（ｉｉ）→（ｉ）」の順に大きくなるものの、（ｉ）および（ｉｉ）には属性情報そのものが含まれる。所定値αを「α＝０．２（２０％）」とする。この場合、分割部９０４は、例えば、電子文書Ｄのデータ量に対するＰｒｏｏｆ（１）のデータ量の割合が０．２以下（２０％以下）となるように、「（ｉ）→（ｉｉ）→（ｉｉｉ）」の順に優先して、Ｐｒｏｏｆ（１）とする。

Ｐｒｏｏｆ（１）の組合せパターンが（ｉ）の場合、Ｐｒｏｏｆ（２）は、（ａ＿ｈａｓｈ，ｂ＿ｈａｓｈ）となる。Ｐｒｏｏｆ（１）の組合せパターンが（ｉｉ）の場合、Ｐｒｏｏｆ（２）は、（ａ＿ｈａｓｈ，ｂ）となる。Ｐｒｏｏｆ（１）の組合せパターンが（ｉｉｉ）の場合、Ｐｒｏｏｆ（２）は、（ａ，ｂ）となる。

生成部９０５は、電子文書ＤおよびＰｒｏｏｆ（１）に対する電子署名を生成する。具体的には、例えば、生成部９０５は、電子文書ＤにＰｒｏｏｆ（１）を付加する。つぎに、生成部９０５は、ハッシュ関数を用いて、Ｐｒｏｏｆ（１）を付加した電子文書Ｄのハッシュ値を算出する。そして、生成部９０５は、署名者の秘密鍵を用いて、算出したハッシュ値を暗号化することにより、電子署名を生成する。

以下の説明では、Ｐｒｏｏｆ（１）を付加した電子文書Ｄに対する電子署名を「電子署名Ｓ」と表記する場合がある。なお、電子署名Ｓの生成例については、図１３を用いて後述する。

第１の通信部９０６は、生成された電子署名Ｓを電子文書ＤおよびＰｒｏｏｆ（１）に付与して、電子文書Ｄの提出元に送信する。ここで、電子文書Ｄの提出元は、提出先に電子文書Ｄを送付する送付者に相当する。電子文書Ｄの提出元は、例えば、電子文書Ｄに対する署名要求の要求元である利用者端末２０２である。

具体的には、例えば、第１の通信部９０６は、Ｐｒｏｏｆ（１）を付加した電子文書Ｄに電子署名Ｓを付与する。そして、第１の通信部９０６は、ネットワーク２１０を介して、要求元である利用者端末２０２に署名応答を送信する。署名応答には、Ｐｒｏｏｆ（１）を付加した電子文書Ｄと、当該電子文書Ｄに付与された電子署名Ｓとが含まれる。

利用者端末２０２は、例えば、署名応答を受信すると、ネットワーク２１０を介して、署名応答に含まれるＰｒｏｏｆ（１）を付加した電子文書Ｄと、当該電子文書Ｄに付与された電子署名Ｓとを、電子文書Ｄの提出先となる利用者端末２０３に送信する。電子文書Ｄの提出先は、提出元から送付された電子文書Ｄを受信する受信者に相当する。提出先への送信は、例えば、電子メール等で行われる。

第２の通信部９０７は、電子文書Ｄの提出元と提出先とを接続する経路とは異なる別の経路を用いて、検証サーバ２０４にＰｒｏｏｆ（２）を送信する。検証サーバ２０４は、Ｐｒｏｏｆの真正性を検証する検証装置の一例である。具体的には、例えば、第２の通信部９０７は、ネットワーク２１０とは異なる別の経路であるＩＤ流通基盤２２０経由で、検証サーバ２０４にＰｒｏｏｆ（２）を送信する。

これにより、Ｐｒｏｏｆの一部（Ｐｒｏｏｆ（２））がＩＤ流通基盤２２０経由で送信されるため、電子文書Ｄに対する証明書の情報量を抑えて、ネットワーク２１０を介した通信のオーバーヘッドが増加するのを防ぐことができる。ＩＤ流通基盤２２０は、クラウド等で実現されるため、インターネット等のネットワーク２１０に比べて、Ｐｒｏｏｆ（２）のやり取りにともなう通信量の増加が問題になりにくい。

（検証サーバ２０４の機能的構成例）
図１１は、検証サーバ２０４の機能的構成例を示すブロック図である。図１１において、検証サーバ２０４は、第１の通信部１１０１と、登録部１１０２と、第２の通信部１１０３と、検証部１１０４と、を含む。第１の通信部１１０１～検証部１１０４は制御部となる機能であり、具体的には、例えば、図４に示したメモリ４０２、ディスク４０４、可搬型記録媒体４０７などの記憶装置に記憶されたプログラムをＣＰＵ４０１に実行させることにより、または、通信Ｉ／Ｆ４０５により、その機能を実現する。各機能部の処理結果は、例えば、メモリ４０２、ディスク４０４などの記憶装置に記憶される。

第１の通信部１１０１は、電子文書Ｄの提出元と提出先とを接続する経路とは異なる別の経路を用いて、署名装置２０１からＰｒｏｏｆ（２）を受信する。具体的には、例えば、第１の通信部１１０１は、ネットワーク２１０とは異なる別の経路であるＩＤ流通基盤２２０経由で、署名装置２０１からＰｒｏｏｆ（２）を受信する。

登録部１１０２は、署名装置２０１からＰｒｏｏｆ（２）を受信した場合、マッチングデータを登録する。例えば、Ｐｒｏｏｆ（２）を（ａ＿ｈａｓｈ，ｂ＿ｈａｓｈ）とする。この場合、登録部１１０２は、ａ＿ｈａｓｈとｂ＿ｈａｓｈとを対応付けて、図５に示したマッチングテーブル２３０に登録する。この結果、新たなマッチングデータ（例えば、マッチングデータ５００－１）がレコードとして記憶される。

また、Ｐｒｏｏｆ（２）を（ａ＿ｈａｓｈ，ｂ）とする。この場合、登録部１１０２は、ハッシュ関数を用いて、ｂ（認証情報）からｂ＿ｈａｓｈを算出する。ただし、署名装置２０１において、Ｐｒｏｏｆ（１），Ｐｒｏｏｆ（２）を作成する際に用いられたハッシュ関数と同じ関数を用いる。そして、登録部１１０２は、ａ＿ｈａｓｈとｂ＿ｈａｓｈとｂとを対応付けて、マッチングテーブル２３０に登録する。この結果、新たなマッチングデータ（例えば、マッチングデータ５００－２）がレコードとして記憶される。

また、Ｐｒｏｏｆ（２）を（ａ，ｂ）とする。この場合、登録部１１０２は、ハッシュ関数を用いて、ａ（属性情報）からａ＿ｈａｓｈを算出する。また、登録部１１０２は、ハッシュ関数を用いて、ｂ（認証情報）からｂ＿ｈａｓｈを算出する。そして、登録部１１０２は、ａ＿ｈａｓｈとｂ＿ｈａｓｈとａとｂとを対応付けて、マッチングテーブル２３０に登録する。この結果、新たなマッチングデータ（例えば、マッチングデータ５００－３）がレコードとして記憶される。

第２の通信部１１０３は、電子文書Ｄの提出先からＰｒｏｏｆ（１）を受信する。具体的には、例えば、第２の通信部１１０３は、ネットワーク２１０を介して、利用者端末２０３から検証依頼を受信する。検証依頼は、署名者のＰｒｏｏｆの真正性の検証を依頼するものである。検証依頼には、Ｐｒｏｏｆ（１）が含まれる。

検証依頼は、さらに、電子文書Ｄの検証を依頼するものであってもよい。この場合、検証依頼には、例えば、Ｐｒｏｏｆ（１）を付加した電子文書Ｄと、当該電子文書Ｄに付与された電子署名Ｓとが含まれる。すなわち、検証サーバ２０４は、利用者端末２０３から、Ｐｒｏｏｆの真正性の検証依頼とともに、電子文書Ｄの真正性の検証依頼を受け付けることにしてもよい。

検証部１１０４は、電子文書Ｄの提出先から受信したＰｒｏｏｆ（１）と、署名装置２０１から受信したＰｒｏｏｆ（２）とに基づいて、Ｐｒｏｏｆの真正性を検証する。具体的には、例えば、検証部１１０４は、電子文書Ｄの提出先からの検証依頼に応じて、受信したＰｒｏｏｆ（１）とＰｒｏｏｆ（２）とからＰｒｏｏｆを再構成する。そして、検証部１１０４は、再構成したＰｒｏｏｆの属性情報と証明情報とから、Ｐｒｏｏｆを検証する。

Ｐｒｏｏｆの検証は、例えば、属性情報（図７参照）と、証明情報（図８参照）と、Ｃｒｅｄｅｎｔｉａｌの発行者の公開鍵とをもとに、既存のゼロ知識証明と呼ばれるプロトコルを用いて行われる。ゼロ知識証明では、ＺＫＰ（ゼロ知識証明）レスポンスとチャレンジｈａｓｈから、ＺＫＰプロトコルにより証明属性の正しさを検証する。

より詳細に説明すると、例えば、検証部１１０４は、証明属性およびチャレンジｈａｓｈを、ＺＫＰレスポンスで決められた演算方法（例えば、ＡＮＤ、ＯＲ）で演算して得られる値とＺＫＰレスポンスとから、証明属性の正しさを検証する（（証明属性，チャレンジｈａｓｈ）→ＺＫＰレスポンス）。

なお、Ｐｒｏｏｆの真正性を検証する際の検証サーバ２０４の動作例については、図１４Ａ～図１４Ｃを用いて後述する。

また、検証部１１０４は、電子署名Ｓを用いて、電子文書Ｄの真正性を検証することにしてもよい。具体的には、例えば、検証部１１０４は、利用者端末２０３から、Ｐｒｏｏｆの真正性の検証依頼とともに、電子文書Ｄの真正性の検証依頼を受け付けた場合、Ｐｒｏｏｆの真正性を検証するとともに、電子文書Ｄの真正性を検証する。

より詳細に説明すると、例えば、検証部１１０４は、Ｐｒｏｏｆ（１）が付加された電子文書Ｄのハッシュ値を算出する。つぎに、検証部１１０４は、署名者の公開鍵を取得し、取得した公開鍵を用いて、電子文書Ｄに付与された電子署名Ｓを復号する。そして、検証部１１０４は、復号して得られたハッシュ値と、算出したハッシュ値とを比較する。

ここで、ハッシュ値が一致する場合、検証部１１０４は、検証ＯＫ（検証成功）とする。検証ＯＫは、電子文書Ｄ（電子文書Ｄ＋Ｐｒｏｏｆ（１））が改ざんされていない正しい情報であることを示す。一方、ハッシュ値が一致しない場合には、検証部１１０４は、検証ＮＧ（検証失敗）とする。検証ＮＧは、電子文書Ｄ（電子文書Ｄ＋Ｐｒｏｏｆ（１））が正しい情報ではないことを示す。例えば、電子文書ＤまたはＰｒｏｏｆ（１）の少なくともいずれかが改ざんされると、検証ＮＧとなる。

なお、電子文書Ｄの真正性を検証する際の検証サーバ２０４の動作例については、図１３を用いて後述する。

第２の通信部１１０３は、電子文書Ｄの提出先（受信者）に検証結果を送信する。具体的には、例えば、第２の通信部１１０３は、ネットワーク２１０を介して、検証要求の要求元である利用者端末２０３に検証結果を送信する。検証結果には、例えば、Ｐｒｏｏｆが正しいものであるか否かを示す検証結果（検証ＯＫまたは検証ＮＧ）が含まれる。

また、検証結果には、例えば、Ｐｒｏｏｆに含まれる属性情報（または、属性情報および証明情報）が含まれる。これにより、利用者端末２０３（受信者）において、署名者の属性およびその真正性を確認することが可能となる。

ただし、Ｐｒｏｏｆ（１）の組合せパターンが（ｉ）または（ｉｉ）の場合、検証結果に属性情報を含めないことにしてもよい。Ｐｒｏｏｆ（１）の組合せパターンが（ｉ）または（ｉｉ）の場合、Ｐｒｏｏｆ（１）に属性情報そのものが含まれているため、利用者端末２０３（受信者）において、Ｐｒｏｏｆ（１）を受信したタイミング、すなわち、Ｐｒｏｏｆの検証前に属性情報を確認することが可能である。

また、電子文書Ｄの真正性の検証依頼を受け付けた場合には、検証結果には、さらに、電子文書Ｄが正しいものであるか否かを示す検証結果（検証ＯＫまたは検証ＮＧ）も含まれる。ただし、電子署名Ｓを用いた電子文書Ｄの真正性の検証は、利用者端末２０３（受信者）において行われることにしてもよい。

（情報処理システム２００の動作例）
つぎに、情報処理システム２００の動作例について説明する。ここでは、電子文書Ｄの送付者（提出元）を「企業Ａの従業員」とし、送付者が電子文書Ｄを所属企業である企業Ａ（署名装置２０１）に送って署名を要求する場合を想定する。電子文書Ｄは、例えば、請求書である。また、Ｃｒｅｄｅｎｔｉａｌを発行する認証機関を「認証企業Ｘ」とし、電子文書Ｄ（電子署名Ｓ）やＰｒｏｏｆを検証する検証者を「検証企業Ｙ」とする。

図１２は、情報処理システム２００の動作例を示す説明図である。図１２において、送付者（利用者端末２０２）は、電子文書Ｄを含む署名要求を企業Ａ（署名装置２０１）に送信する。企業Ａ（署名装置２０１）は、署名要求に応じて、認証企業Ｘ（認証サーバ２０５）から、企業Ａや企業Ａの代表者（署名者）としてのＣｒｅｄｅｎｔｉａｌを取得する。ただし、Ｃｒｅｄｅｎｔｉａｌは、予め取得されていてもよい。

企業Ａ（署名装置２０１）は、ＣｒｅｄｅｎｔｉａｌからＰｒｏｏｆを作成し、ＰｒｏｏｆをＰｒｏｏｆ（１）とＰｒｏｏｆ（２）とに分割する。企業Ａ（署名装置２０１）は、ＩＤ流通基盤２２０を介して、Ｐｒｏｏｆ（２）を検証企業Ｙ（検証サーバ２０４）に送信する。

企業Ａ（署名装置２０１）は、電子文書ＤにＰｒｏｏｆ（１）を付加して、企業Ａの秘密鍵で署名（電子署名Ｓ）を行う。電子署名Ｓの付与例については、図１３を用いて後述する。企業Ａ（署名装置２０１）は、「電子文書Ｄ＋Ｐｒｏｏｆ（１）＋電子署名Ｓ」を送付者（利用者端末２０２）に送信する。

送付者（利用者端末２０２）は、ネットワーク２１０を介して、電子メール等により、「電子文書Ｄ＋Ｐｒｏｏｆ（１）＋電子署名Ｓ」を受信者（利用者端末２０３）に送信する。受信者（利用者端末２０３）は、受信した「電子文書Ｄ＋Ｐｒｏｏｆ（１）＋電子署名Ｓ」を検証企業Ｙ（検証サーバ２０４）に送信して、電子文書Ｄ（電子署名Ｓ）とＰｒｏｏｆの検証を依頼する。

なお、受信者（利用者端末２０３）において、検証企業Ｙ（検証サーバ２０４）への検証依頼を行う際の操作例については、図１５を用いて後述する。

検証企業Ｙ（検証サーバ２０４）は、受信者（利用者端末２０３）から受信したＰｒｏｏｆ（１）と、企業Ａ（署名装置２０１）から受信したＰｒｏｏｆ（２）とのマッチングを取ってＰｒｏｏｆを再構成し、Ｐｒｏｏｆの検証を行う。Ｐｒｏｏｆの再構成例については、図１４Ａ～図１４Ｃを用いて後述する。

また、検証企業Ｙ（検証サーバ２０４）は、企業Ａの公開鍵に基づいて、電子署名Ｓ（電子文書Ｄ）の検証を行う。電子署名Ｓ（電子文書Ｄ）の検証例については、図１３を用いて後述する。そして、検証企業Ｙ（検証サーバ２０４）は、受信者（利用者端末２０３）に検証結果を送信する。検証結果には、例えば、Ｐｒｏｏｆの検証結果と、電子署名Ｓ（電子文書Ｄ）の検証結果と、Ｐｒｏｏｆに含まれる属性情報とが含まれる。

これにより、電子署名Ｓを用いて電子文書Ｄの真正性を検証するにあたり、署名者（企業Ａや企業Ａの代表者）の属性を確認可能にするとともに、その正しさを検証可能にすることができる。

（電子署名Ｓの付与例および検証例）
つぎに、図１３を用いて、電子署名Ｓの付与例および検証例について説明する。

図１３は、電子署名の付与例および検証例を示す説明図である。図１３において、電子署名Ｓを付与するにあたり、企業Ａ（署名装置２０１）は、電子文書ＤにＰｒｏｏｆ（１）を付加して、「電子文書Ｄ＋Ｐｒｏｏｆ（１）」のハッシュ値を算出する。つぎに、企業Ａ（署名装置２０１）は、自身の秘密鍵を用いて、算出したハッシュ値を暗号化することにより、電子署名Ｓを生成する。そして、企業Ａ（署名装置２０１）は、生成した電子署名Ｓを、Ｐｒｏｏｆ（１）を付加した電子文書Ｄに付与する。

図１３において、電子署名Ｓ（電子文書Ｄ）を検証するにあたり、検証企業Ｙ（検証サーバ２０４）は、「電子文書Ｄ＋Ｐｒｏｏｆ（１）」のハッシュ値を算出する。ただし、企業Ａ（署名装置２０１）において、電子署名Ｓを生成する際に用いられたハッシュ関数と同じ関数を用いる。

つぎに、検証企業Ｙ（検証サーバ２０４）は、企業Ａの公開鍵を取得し、取得した公開鍵を用いて、電子署名Ｓを復号する。そして、検証企業Ｙ（検証サーバ２０４）は、復号して得られたハッシュ値と、算出したハッシュ値とを比較する。

ここで、ハッシュ値が一致する場合、検証企業Ｙ（検証サーバ２０４）は、検証ＯＫ（Ｐｒｏｏｆ（１）が付加された電子文書Ｄが正しいものである）とする。一方、ハッシュ値が一致しない場合には、検証企業Ｙ（検証サーバ２０４）は、検証ＮＧ（Ｐｒｏｏｆ（１）が付加された電子文書Ｄが正しいものではない）とする。

（Ｐｒｏｏｆの再構成例）
つぎに、図１４Ａ～図１４Ｃを用いて、Ｐｒｏｏｆの再構成例について説明する。

図１４Ａ～図１４Ｃは、Ｐｒｏｏｆの再構成例を示す説明図である。まず、図１４Ａにおいて、Ｐｒｏｏｆ（１）の組合せパターンが（ｉ）の場合について説明する。この場合、Ｐｒｏｏｆ（１）には、ａ（属性情報：ｐｐｐ１）とｂ（証明情報：ｑｑｑ１）とが含まれる。一方、Ｐｒｏｏｆ（２）には、ａ＿ｈａｓｈ（属性情報のハッシュ値：ｘｘｘ１）とｂ＿ｈａｓｈ（証明情報のハッシュ値：ｙｙｙ１）とが含まれる。

検証企業Ｙ（検証サーバ２０４）は、企業Ａ（署名装置２０１）からＰｒｏｏｆ（２）を受信すると、ａ＿ｈａｓｈ（属性情報のハッシュ値：ｘｘｘ１）とｂ＿ｈａｓｈ（証明情報のハッシュ値：ｙｙｙ１）とを対応付けて、マッチングテーブル２３０に登録する。この結果、マッチングデータ５００－１（図５参照）がレコードとして記憶される。

検証企業Ｙ（検証サーバ２０４）は、受信者（利用者端末２０３）からＰｒｏｏｆ（１）を含む検証依頼を受信すると、Ｐｒｏｏｆ（１）に含まれるａ（属性情報）のハッシュ値（ａ＿ｈａｓｈ）を算出する。また、検証企業Ｙ（検証サーバ２０４）は、Ｐｒｏｏｆ（１）に含まれるｂ（証明情報）のハッシュ値（ｂ＿ｈａｓｈ）を算出する。

つぎに、検証企業Ｙ（検証サーバ２０４）は、マッチングテーブル２３０を参照して、算出したａ＿ｈａｓｈとｂ＿ｈａｓｈとに対応するマッチングデータを検索する。ここで、マッチングデータが検索された場合、検証企業Ｙ（検証サーバ２０４）は、Ｐｒｏｏｆを再構成する。

例えば、マッチングデータ５００－１が検索された場合、検証企業Ｙ（検証サーバ２０４）は、Ｐｒｏｏｆ（１）に含まれるａ（属性情報：ｐｐｐ１）とｂ（証明情報：ｑｑｑ１）とから、ａとｂより成るＰｒｏｏｆを再構成する。そして、検証企業Ｙ（検証サーバ２０４）は、再構成したＰｒｏｏｆの属性情報：ｐｐｐ１と証明情報：ｑｑｑ１とから、Ｐｒｏｏｆを検証する。

なお、ａ＿ｈａｓｈとｂ＿ｈａｓｈとに対応するマッチングデータが検索されなかった場合、検証企業Ｙ（検証サーバ２０４）は、Ｐｒｏｏｆの検証結果を検証ＮＧとする。例えば、送付者（提出元）などによりＰｒｏｏｆ（１）が改ざんされると、マッチングテーブル２３０から対応するマッチングデータが検索されず、検証ＮＧとなる。

つぎに、図１４Ｂにおいて、Ｐｒｏｏｆ（１）の組合せパターンが（ｉｉ）の場合について説明する。この場合、Ｐｒｏｏｆ（１）には、ａ（属性情報：ｐｐｐ２）とｂ＿ｈａｓｈ（証明情報のハッシュ値：ｙｙｙ２）とが含まれる。一方、Ｐｒｏｏｆ（２）には、ａ＿ｈａｓｈ（属性情報のハッシュ値：ｘｘｘ２）とｂ（証明情報：ｑｑｑ２）とが含まれる。

検証企業Ｙ（検証サーバ２０４）は、企業Ａ（署名装置２０１）からＰｒｏｏｆ（２）を受信すると、ｂ（認証情報：ｑｑｑ２）からｂ＿ｈａｓｈ（証明情報のハッシュ値：ｙｙｙ２）を算出する。そして、検証企業Ｙ（検証サーバ２０４）は、ａ＿ｈａｓｈ（属性情報のハッシュ値：ｘｘｘ２）とｂ＿ｈａｓｈ（証明情報のハッシュ値：ｙｙｙ２）とｂ（証明情報：ｑｑｑ２）とを対応付けて、マッチングテーブル２３０に登録する。この結果、マッチングデータ５００－２（図５参照）がレコードとして記憶される。

検証企業Ｙ（検証サーバ２０４）は、受信者（利用者端末２０３）からＰｒｏｏｆ（１）を含む検証依頼を受信すると、Ｐｒｏｏｆ（１）に含まれるａ（属性情報）のハッシュ値（ａ＿ｈａｓｈ）を算出する。つぎに、検証企業Ｙ（検証サーバ２０４）は、マッチングテーブル２３０を参照して、算出したａ＿ｈａｓｈと、Ｐｒｏｏｆ（１）に含まれるｂ＿ｈａｓｈ（証明情報のハッシュ値）とに対応するマッチングデータを検索する。ここで、マッチングデータが検索された場合、検証企業Ｙ（検証サーバ２０４）は、Ｐｒｏｏｆを再構成する。

例えば、マッチングデータ５００－２が検索された場合、検証企業Ｙ（検証サーバ２０４）は、Ｐｒｏｏｆ（１）に含まれるａ（属性情報：ｐｐｐ２）と、マッチングデータ５００－２に含まれるｂ（証明情報：ｑｑｑ２）とから、ａとｂより成るＰｒｏｏｆを再構成する。そして、検証企業Ｙ（検証サーバ２０４）は、再構成したＰｒｏｏｆの属性情報：ｐｐｐ２と証明情報：ｑｑｑ２とから、Ｐｒｏｏｆを検証する。

つぎに、図１４Ｃにおいて、Ｐｒｏｏｆ（１）の組合せパターンが（ｉｉｉ）の場合について説明する。この場合、Ｐｒｏｏｆ（１）には、ａ＿ｈａｓｈ（属性情報のハッシュ値：ｘｘｘ３）とｂ＿ｈａｓｈ（証明情報のハッシュ値：ｙｙｙ３）とが含まれる。一方、Ｐｒｏｏｆ（２）には、ａ（属性情報：ｐｐｐ３）とｂ（証明情報：ｑｑｑ３）とが含まれる。

検証企業Ｙ（検証サーバ２０４）は、企業Ａ（署名装置２０１）からＰｒｏｏｆ（２）を受信すると、ａ（属性情報：ｐｐｐ３）からａ＿ｈａｓｈ（属性情報のハッシュ値：ｘｘｘ３）を算出する。また、検証企業Ｙ（検証サーバ２０４）は、ｂ（認証情報：ｑｑｑ３）からｂ＿ｈａｓｈ（証明情報のハッシュ値：ｙｙｙ３）を算出する。

そして、検証企業Ｙ（検証サーバ２０４）は、ａ＿ｈａｓｈ（属性情報のハッシュ値：ｘｘｘ３）とｂ＿ｈａｓｈ（証明情報のハッシュ値：ｙｙｙ３）とａ（属性情報：ｐｐｐ３）とｂ（証明情報：ｑｑｑ３）とを対応付けて、マッチングテーブル２３０に登録する。この結果、マッチングデータ５００－３（図５参照）がレコードとして記憶される。

検証企業Ｙ（検証サーバ２０４）は、受信者（利用者端末２０３）からＰｒｏｏｆ（１）を含む検証依頼を受信すると、マッチングテーブル２３０を参照して、Ｐｒｏｏｆ（１）に含まれるａ＿ｈａｓｈ（属性情報のハッシュ値）とｂ＿ｈａｓｈ（証明情報のハッシュ値）とに対応するマッチングデータを検索する。ここで、マッチングデータが検索された場合、検証企業Ｙ（検証サーバ２０４）は、Ｐｒｏｏｆを再構成する。

例えば、マッチングデータ５００－３が検索された場合、検証企業Ｙ（検証サーバ２０４）は、マッチングデータ５００－３に含まれるａ（属性情報：ｐｐｐ３）とｂ（証明情報：ｑｑｑ３）とから、ａとｂより成るＰｒｏｏｆを再構成する。そして、検証企業Ｙ（検証サーバ２０４）は、再構成したＰｒｏｏｆの属性情報：ｐｐｐ３と証明情報：ｑｑｑ３とから、Ｐｒｏｏｆを検証する。

（Ｐｒｏｏｆの検証依頼を行う際の操作例）
つぎに、図１５を用いて、受信者（利用者端末２０３）から検証企業Ｙ（検証サーバ２０４）へのＰｒｏｏｆの検証依頼を行う際の操作例について説明する。

図１５は、Ｐｒｏｏｆの検証依頼を行う際の操作例を示す説明図である。図１５において、受信者の利用者端末２０３において、送付者（利用者端末２０２）から受信した電子文書１５００が表示されている。電子文書１５００は、電子文書Ｄの一例である。電子文書１５００には、電子署名１５１０が付与されている。

ここでは、送付者（利用者端末２０２）から受信者（利用者端末２０３）に送信されたＰｒｏｏｆ（１）に属性情報そのものが含まれている場合を想定する。

利用者端末２０３において、受信者の操作入力により、電子署名１５１０を選択すると、属性情報１５２０が表示される。属性情報１５２０は、電子署名１５１０の署名者の属性を示す情報（Ｐｒｏｏｆの一部）であり、送付者（利用者端末２０２）からのＰｒｏｏｆ（１）に含まれる。属性情報１５２０には、Ｐｒｏｏｆが未検証であることを示す未検証ボタン１５２１が表示されている。

属性情報１５２０によれば、受信者は、Ｐｒｏｏｆの検証を行う前に、電子署名１５１０の署名者の属性を確認することができる。ここでは、受信者は、電子文書１５００（企業Ａから企業Ｂへの請求書）に対して、企業Ａの代表者（社長）の署名が行われていることを確認することができる。

また、利用者端末２０３において、受信者の操作入力により、未検証ボタン１５２１を選択すると、Ｐｒｏｏｆの検証依頼が検証企業Ｙ（検証サーバ２０４）に送信される。この検証依頼は、電子文書１５００についての検証も依頼するものであってもよい。

また、利用者端末２０３において、検証企業Ｙ（検証サーバ２０４）から検証結果を受信すると、受信した検証結果（不図示）が表示される。これにより、受信者は、署名者の属性の正しさを確認することができる。ここでは、受信者は、電子文書１５００に対する署名者の属性（勤務先、役職、名前）が正しいか否かを確認することができる。検証企業Ｙ（検証サーバ２０４）から検証結果を受信すると、属性情報１５２０に含まれる未検証ボタン１５２１は非表示（あるいは、検証済み）となる。

なお、Ｐｒｏｏｆ（１）に属性情報が含まれていない場合、受信者は、検証企業Ｙ（検証サーバ２０４）からＰｒｏｏｆ等の検証結果とともに属性情報を受け取って、署名者の属性およびその正しさを確認することができる。この場合、受信者は、Ｐｒｏｏｆ等の検証結果を受け取ったタイミングで、署名者の属性およびその正しさを確認することができる。

（情報処理システム２００の検証処理手順）
つぎに、図１６～図１８を用いて、情報処理システム２００の検証処理手順について説明する。

図１６～図１８は、情報処理システム２００の検証処理手順の一例を示すシーケンス図である。図１６のシーケンス図において、まず、利用者端末２０２（提出元）は、電子文書Ｄに対する署名要求を署名装置２０１に送信する（ステップＳ１６０１）。署名装置２０１は、利用者端末２０２（提出元）から署名要求を受信すると、Ｃｒｅｄｅｎｔｉａｌ要求を認証サーバ２０５に送信する（ステップＳ１６０２）。

Ｃｒｅｄｅｎｔｉａｌ要求は、認証機関により発行される署名者のＣｒｅｄｅｎｔｉａｌ（属性証明書情報）を要求するものである。認証サーバ２０５は、署名装置２０１からＣｒｅｄｅｎｔｉａｌ要求を受信すると、署名者のＣｒｅｄｅｎｔｉａｌを取得する（ステップＳ１６０３）。

そして、認証サーバ２０５は、取得した署名者のＣｒｅｄｅｎｔｉａｌを含むＣｒｅｄｅｎｔｉａｌ応答を署名装置２０１に送信する（ステップＳ１６０４）。なお、署名者のＣｒｅｄｅｎｔｉａｌは、例えば、認証サーバ２０５が有する不図示の属性証明書ＤＢ（Ｄａｔａｂａｓｅ）に記憶されている。

つぎに、署名装置２０１は、受信した署名者のＣｒｅｄｅｎｔｉａｌに基づいて、署名者のＰｒｏｏｆ（証明書情報）を作成して（ステップＳ１６０５）、図１７に示すステップＳ１７０１に移行する。

図１７のシーケンス図において、まず、署名装置２０１は、電子文書Ｄのデータ量に基づいて、作成したＰｒｏｏｆをＰｒｏｏｆ（１）とＰｒｏｏｆ（２）とに分割するＰｒｏｏｆ分割処理を実行する（ステップＳ１７０１）。署名装置２０１のＰｒｏｏｆ分割処理の具体的な処理手順については、図１９を用いて後述する。

そして、署名装置２０１は、ＩＤ流通基盤２２０を介して、検証サーバ２０４にＰｒｏｏｆ（２）を送信する（ステップＳ１７０２）。つぎに、署名装置２０１は、電子文書ＤにＰｒｏｏｆ（１）を付加する（ステップＳ１７０３）。そして、署名装置２０１は、署名者の秘密鍵を用いて、Ｐｒｏｏｆ（１）を付加した電子文書Ｄのハッシュ値を暗号化することにより、電子署名Ｓを生成する（ステップＳ１７０４）。

つぎに、署名装置２０１は、署名応答を利用者端末２０２（提出元）に送信して（ステップＳ１７０５）、図１８に示すステップＳ１８０１に移行する。署名応答には、Ｐｒｏｏｆ（１）を付加した電子文書Ｄと、当該電子文書Ｄに付与された電子署名Ｓとが含まれる（電子文書Ｄ＋Ｐｒｏｏｆ（１）＋電子署名Ｓ）。

図１８のシーケンス図において、まず、利用者端末２０２（提出元）は、署名装置２０１から署名応答を受信すると、Ｐｒｏｏｆ（１）を付加した電子文書Ｄと、当該電子文書Ｄに付与された電子署名Ｓとを利用者端末２０３（提出先）に送信する（ステップＳ１８０１）。

利用者端末２０３（提出先）は、利用者端末２０２（提出元）からＰｒｏｏｆ（１）を付加した電子文書Ｄと、当該電子文書Ｄに付与された電子署名Ｓとを受信すると、検証サーバ２０４に検証依頼を送信する（ステップＳ１８０２）。検証依頼は、Ｐｒｏｏｆの検証を依頼するとともに、電子文書Ｄの検証を依頼するものである。

検証依頼には、Ｐｒｏｏｆ（１）を付加した電子文書Ｄと、当該電子文書Ｄに付与された電子署名Ｓとが含まれる（電子文書Ｄ＋Ｐｒｏｏｆ（１）＋電子署名Ｓ）。なお、Ｐｒｏｏｆ（１）に属性情報そのものが含まれている場合には、利用者端末２０３（提出先）は、この時点で、署名者の属性情報を表示可能である。

検証サーバ２０４は、利用者端末２０３（提出先）から検証依頼を受信すると、検証処理を実行する（ステップＳ１８０３）。検証サーバ２０４の検証処理の具体的な処理手順については、図２０を用いて後述する。そして、検証サーバ２０４は、利用者端末２０３（提出先）に検証結果を送信する（ステップＳ１８０４）。

利用者端末２０３（提出先）は、検証サーバ２０４から検証結果を受信すると、受信した検証結果を表示する（ステップＳ１８０５）。検証結果には、例えば、Ｐｒｏｏｆの検証結果と、電子文書Ｄ（電子署名Ｓ）の検証結果と、署名者の属性情報とが含まれる。

これにより、利用者端末２０３（提出先）において、受信者は、電子文書Ｄの真正性を確認するとともに、署名者の属性およびその正しさを確認することができる。

つぎに、図１９を用いて、図１７に示したステップＳ１７０１の署名装置２０１のＰｒｏｏｆ分割処理の具体的な処理手順について説明する。ただし、所定値αを「α＝０．２（２０％）」とする。

図１９は、署名装置２０１のＰｒｏｏｆ分割処理の具体的な処理手順の一例を示すフローチャートである。図１９のフローチャートにおいて、まず、署名装置２０１は、Ｐｒｏｏｆを属性情報と証明情報とに分割する（ステップＳ１９０１）。そして、署名装置２０１は、分割した属性情報のハッシュ値を算出する（ステップＳ１９０２）。

つぎに、署名装置２０１は、分割した証明情報のハッシュ値を算出する（ステップＳ１９０３）。そして、署名装置２０１は、電子文書Ｄのデータ量に対する、属性情報のデータ量と証明情報のデータ量との合計値の割合が０．２以下であるか否かを判断する（ステップＳ１９０４）。

なお、図１９中のステップＳ１９０４において、Ｄは、電子文書Ｄのデータ量を示す。ａは、属性情報のデータ量を示す。ｂは、証明情報のデータ量を示す。ａ＿ｈａｓｈは、属性情報のハッシュ値のデータ量を示す。ｂ＿ｈａｓｈは、証明情報のハッシュ値のデータ量を示す。「ａ＋ｂ≦０．２＊Ｄ」は、電子文書Ｄのデータ量に対する、属性情報のデータ量と証明情報のデータ量との合計値の割合が０．２以下であることを示す。

ここで、０．２以下の場合（ステップＳ１９０４：Ｙｅｓ）、署名装置２０１は、Ｐｒｏｏｆ（１）を属性情報と証明情報とからなる組合せ（ａ，ｂ）とする（ステップＳ１９０５）。そして、署名装置２０１は、Ｐｒｏｏｆ（２）を属性情報のハッシュ値と証明情報のハッシュ値とからなる組合せ（ａ＿ｈａｓｈ，ｂ＿ｈａｓｈ）として（ステップＳ１９０６）、Ｐｒｏｏｆ分割処理を呼び出したステップに戻る。

また、ステップＳ１９０４において、０．２以下ではない場合（ステップＳ１９０４：Ｎｏ）、署名装置２０１は、電子文書Ｄのデータ量に対する、属性情報のデータ量と証明情報のハッシュ値のデータ量との合計値の割合が０．２以下であるか否かを判断する（ステップＳ１９０７）。

なお、図１９中のステップＳ１９０７において、「ａ＋ｂ＿ｈａｓｈ≦０．２＊Ｄ」は、電子文書Ｄのデータ量に対する、属性情報のデータ量と証明情報のハッシュ値のデータ量との合計値の割合が０．２以下であることを示す。

ここで、０．２以下の場合（ステップＳ１９０７：Ｙｅｓ）、署名装置２０１は、Ｐｒｏｏｆ（１）を属性情報と証明情報のハッシュ値とからなる組合せ（ａ，ｂ＿ｈａｓｈ）とする（ステップＳ１９０８）。そして、署名装置２０１は、Ｐｒｏｏｆ（２）を属性情報のハッシュ値と証明情報とからなる組合せ（ａ＿ｈａｓｈ，ｂ）として（ステップＳ１９０９）、Ｐｒｏｏｆ分割処理を呼び出したステップに戻る。

また、ステップＳ１９０７において、０．２以下ではない場合（ステップＳ１９０７：Ｎｏ）、署名装置２０１は、Ｐｒｏｏｆ（１）を属性情報のハッシュ値と証明情報のハッシュ値とからなる組合せ（ａ＿ｈａｓｈ，ｂ＿ｈａｓｈ）する（ステップＳ１９１０）。そして、署名装置２０１は、Ｐｒｏｏｆ（２）を属性情報と証明情報とからなる組合せ（ａ，ｂ）として（ステップＳ１９１１）、Ｐｒｏｏｆ分割処理を呼び出したステップに戻る。

これにより、Ｐｒｏｏｆを属性情報と証明情報とに分け、電子文書Ｄのデータ量に対して２０％以下になるように、Ｐｒｏｏｆ（１）に含める範囲を決定することができる。

つぎに、図２０を用いて、図１８に示したステップＳ１８０３の検証サーバ２０４の検証処理手順について説明する。

図２０は、検証サーバ２０４の検証処理の具体的な処理手順の一例を示すフローチャートである。図２０のフローチャートにおいて、まず、検証サーバ２０４は、署名者の公開鍵を取得する（ステップＳ２００１）。そして、検証サーバ２０４は、取得した公開鍵に基づいて、検証依頼に含まれる電子署名Ｓを用いて、電子文書Ｄの真正性を検証する（ステップＳ２００２）。

つぎに、検証サーバ２０４は、検証依頼に含まれるＰｒｏｏｆ（１）の組合せパターンに応じて、ａ＿ｈａｓｈとｂ＿ｈａｓｈとを取得する（ステップＳ２００３）。そして、検証サーバ２０４は、マッチングテーブル２３０から、取得したａ＿ｈａｓｈとｂ＿ｈａｓｈとの組合せに対応するマッチングデータを検索する（ステップＳ２００４）。

つぎに、検証サーバ２０４は、マッチングデータが検索されたか否かを判断する（ステップＳ２００５）。ここで、マッチングデータが検索された場合（ステップＳ２００５：Ｙｅｓ）、検証サーバ２０４は、ａ（属性情報）とｂ（証明情報）とを取得する（ステップＳ２００６）。

つぎに、検証サーバ２０４は、取得したａ（属性情報）とｂ（証明情報）とからＰｒｏｏｆを再構成する（ステップＳ２００７）。そして、検証サーバ２０４は、再構成したＰｒｏｏｆの属性情報と証明情報とから、Ｐｒｏｏｆの真正性を検証する（ステップＳ２００８）。

つぎに、検証サーバ２０４は、電子文書Ｄの真正性を検証した結果と、Ｐｒｏｏｆの真正性を検証した結果とに基づいて、検証結果を生成して（ステップＳ２００９）、検証処理を呼び出したステップに戻る。

また、ステップＳ２００５において、マッチングデータが検索されなかった場合（ステップＳ２００５：Ｎｏ）、検証サーバ２０４は、Ｐｒｏｏｆの検証結果を検証ＮＧとして（ステップＳ２０１０）、ステップＳ２００９に移行する。

これにより、電子署名Ｓを用いて電子文書Ｄの真正性を検証するとともに、Ｐｒｏｏｆの真正性を検証することができる。例えば、ａ＿ｈａｓｈとｂ＿ｈａｓｈとの組合せに対応するマッチングデータを検索することで、Ｐｒｏｏｆが改ざんされていないことを検証することができる。また、再構成したＰｒｏｏｆの属性情報と証明情報とから、Ｐｒｏｏｆの真正性を検証することで、改ざんされていない情報そのものが、証明されている情報であるかを検証することができる。

以上説明したように、実施の形態にかかる署名装置２０１によれば、電子文書Ｄに対する署名要求に応じて、電子文書Ｄのデータ量に基づいて、Ｐｒｏｏｆ（証明書情報）から、Ｐｒｏｏｆ（１）とＰｒｏｏｆ（２）とを作成することができる。また、署名装置２０１によれば、電子文書ＤおよびＰｒｏｏｆ（１）に対する電子署名Ｓを生成し、電子署名Ｓを電子文書ＤおよびＰｒｏｏｆ（１）に付与して、電子文書Ｄの提出元（利用者端末２０２）に送信し、ＩＤ流通基盤２２０を用いて、検証サーバ２０４にＰｒｏｏｆ（２）を送信することができる。ＩＤ流通基盤２２０は、電子文書Ｄの提出元（利用者端末２０３）と提出先（利用者端末２０３）とを接続する経路（ネットワーク２１０）とは異なる別の経路である。

これにより、電子署名Ｓを用いて電子文書Ｄの真正性を検証するにあたり、署名者の属性を確認可能にするとともに、その正しさを検証可能にすることができる。また、Ｐｒｏｏｆを２つに分割することで、電子文書Ｄに付加する証明書の情報量を抑えることができる。また、２つ揃って１つのＰｒｏｏｆとなるため、Ｐｒｏｏｆ（１）とＰｒｏｏｆ（２）とを、経路を分けて別々に送ることで、一方がハッキングされたとしても証明可能なＰｒｏｏｆ全体を知ることはできず、Ｐｒｏｏｆに対するセキュリティを高めることができる。

また、署名装置２０１によれば、電子文書Ｄのデータ量に対するＰｒｏｏｆ（１）のデータ量の割合が所定値α以下となるように、属性情報、証明情報、属性情報のハッシュ値および証明情報のハッシュ値を、Ｐｒｏｏｆ（１）とＰｒｏｏｆ（２）とに分割することができる。

これにより、Ｐｒｏｏｆを属性情報と証明情報とに分け、電子文書Ｄのデータ量に対して所定値以下になるように、Ｐｒｏｏｆ（１）に含める範囲を決定することができる。このため、Ｐｒｏｏｆ（１）の電子文書Ｄに対するデータ量が大きくなって、通信のオーバーヘッドが増加するのを防ぐことができる。なお、ＩＤ流通基盤２２０はクラウド等で実現され、インターネット等のネットワーク２１０に比べて、Ｐｒｏｏｆ（２）のやり取りにともなう通信量の増加が問題になりにくい。

また、署名装置２０１によれば、第１の組合せ（ａ，ｂ）、第２の組合せ（ａ，ｂ＿ｈａｓｈ）および第３の組合せ（ａ＿ｈａｓｈ，ｂ＿ｈａｓｈ）のうち、第１の組合せ（ａ，ｂ）または第２の組合せ（ａ，ｂ＿ｈａｓｈ）を、第３の組合せ（ａ＿ｈａｓｈ，ｂ＿ｈａｓｈ）よりも優先してＰｒｏｏｆ（１）とすることができる。

これにより、電子文書Ｄの提出先（受信者）において、Ｐｒｏｏｆの検証を行う前に、署名者の属性情報を確認することが可能となる。例えば、送付者からメール等で属性情報を含むＰｒｏｏｆ（１）を送ることで（組合せパターンが（ｉ）または（ｉｉ））、受信者は、ＩＤ流通基盤２２０にアクセスすることなく（検証サーバ２０４から属性情報を取得しなくても）、署名者の属性情報（属性名、属性値）を確認することができる。

また、署名装置２０１によれば、電子文書Ｄに対する署名要求に応じて、認証サーバ２０５から、ＩＤ流通基盤２２０経由で、署名者のＣｒｅｄｅｎｔｉａｌ（属性証明書情報）を取得し、取得したＣｒｅｄｅｎｔｉａｌに基づいて、署名者のＰｒｏｏｆを作成することができる。

これにより、認証機関により発行される署名者のＣｒｅｄｅｎｔｉａｌをもとに、開示する必要のない属性を秘匿したり、ある条件を満たすかを証明したりすることで、Ｐｒｏｏｆを作成することができる。

また、実施の形態にかかる検証サーバ２０４によれば、署名装置２０１からＰｒｏｏｆ（２）を受信し、電子文書Ｄの提出先からＰｒｏｏｆ（１）を受信し、受信したＰｒｏｏｆ（１）と、受信したＰｒｏｏｆ（２）とに基づいて、Ｐｒｏｏｆの真正性を検証することができる。

これにより、別ルートで得られるＰｒｏｏｆ（１）とＰｒｏｏｆ（２）からＰｒｏｏｆを再構成して、属性情報が証明されている正しい情報であるかを検証することができる。

また、実施の形態にかかる検証サーバ２０４によれば、電子文書Ｄの提出先から、Ｐｒｏｏｆ（１）が付加された電子文書Ｄと、当該電子文書Ｄに付与された電子署名Ｓとを受信し、電子署名Ｓを用いて、Ｐｒｏｏｆ（１）が付加された電子文書Ｄの真正性を検証することができる。

これにより、電子文書Ｄが改ざんされていない正しい情報であるかを検証することができる。また、Ｐｒｏｏｆ（１）が付加された電子文書Ｄに署名し、かつ、別途Ｐｒｏｏｆ（２）を取得しないとＰｒｏｏｆを再構成できないため、電子文書ＤからのＰｒｏｏｆの分離や改ざんを困難にすることができる。

これらのことから、実施の形態にかかる情報処理システム２００によれば、電子署名Ｓを用いて電子文書Ｄの真正性を検証するにあたり、署名者の属性を確認し、その正しさを検証可能にするとともに、電子文書Ｄに付加する証明書の情報量を抑えて伝送効率の悪化を回避することができる。

なお、本実施の形態で説明した情報処理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本情報処理プログラムは、ハードディスク、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ、ＵＳＢメモリ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本情報処理プログラムは、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）電子文書に対する署名要求に応じて、前記電子文書のデータ量に基づいて、署名者の属性情報と当該属性情報を証明するための証明情報とを含む証明書情報から、第１の部分証明書情報と第２の部分証明書情報とを作成し、
前記電子文書および前記第１の部分証明書情報に対する電子署名を生成し、
生成した前記電子署名を前記電子文書および前記第１の部分証明書情報に付与して、前記電子文書の提出元に送信し、
前記電子文書の提出元と提出先とを接続する経路とは異なる別の経路を用いて、前記署名者の証明書情報の真正性を検証する検証装置に前記第２の部分証明書情報を送信する、
処理をコンピュータに実行させることを特徴とする情報処理プログラム。

（付記２）前記作成する処理は、
前記電子文書のデータ量に対する第１の部分証明書情報のデータ量の割合が所定値以下となるように、前記属性情報、前記証明情報、前記属性情報の要約値および前記証明情報の要約値を、前記第１の部分証明書情報と第２の部分証明書情報とに分割する、ことを特徴とする付記１に記載の情報処理プログラム。

（付記３）前記作成する処理は、
前記属性情報と前記証明情報との第１の組合せ、前記属性情報と前記証明情報の要約値との第２の組合せ、および、前記属性情報の要約値と前記証明情報の要約値との第３の組合せのうち、前記第１の組合せまたは前記第２の組合せを、前記第３の組合せよりも優先して前記第１の部分証明書情報とする、ことを特徴とする付記２に記載の情報処理プログラム。

（付記４）前記証明書情報は、認証機関により発行される前記署名者の属性証明書情報に基づき作成される、ことを特徴とする付記１～３のいずれか一つに記載の情報処理プログラム。

（付記５）前記属性情報は、前記属性証明書情報に含まれる属性の情報、前記属性証明書情報に含まれる属性の情報を秘匿化した情報、および、前記属性証明書情報に含まれる属性の情報が特定の条件を満たすことを証明する情報のうちの少なくともいずれかを含む、ことを特徴とする付記４に記載の情報処理プログラム。

（付記６）前記署名者の証明書情報の真正性は、前記検証装置に送信された前記第２の部分証明書情報と、前記電子文書の提出先から前記検証装置に送信される第１の部分証明書情報とに基づき検証される、ことを特徴とする付記１～５のいずれか一つに記載の情報処理プログラム。

（付記７）前記電子文書の真正性は、前記電子署名に基づき検証される、ことを特徴とする付記１～６のいずれか一つに記載の情報処理プログラム。

（付記８）電子文書に対する署名要求に応じて、前記電子文書のデータ量に基づいて、署名者の属性情報と当該属性情報を証明するための証明情報とを含む証明書情報から、第１の部分証明書情報と第２の部分証明書情報とを作成し、
前記電子文書および前記第１の部分証明書情報に対する電子署名を生成し、
生成した前記電子署名を前記電子文書および前記第１の部分証明書情報に付与して、前記電子文書の提出元に送信し、
前記電子文書の提出元と提出先とを接続する経路とは異なる別の経路を用いて、前記署名者の証明書情報の真正性を検証する検証装置に前記第２の部分証明書情報を送信する、
処理をコンピュータが実行することを特徴とする情報処理方法。

（付記９）電子文書に対する署名要求に応じて、前記電子文書のデータ量に基づいて、署名者の属性情報と当該属性情報を証明するための証明情報とを含む証明書情報から、第１の部分証明書情報と第２の部分証明書情報とを作成し、
前記電子文書および前記第１の部分証明書情報に対する電子署名を生成し、
生成した前記電子署名を前記電子文書および前記第１の部分証明書情報に付与して、前記電子文書の提出元に送信し、
前記電子文書の提出元と提出先とを接続する経路とは異なる別の経路を用いて、前記署名者の証明書情報の真正性を検証する検証装置に前記第２の部分証明書情報を送信する、
制御部を有することを特徴とする情報処理装置。

（付記１０）電子文書に対する署名要求に応じて、前記電子文書のデータ量に基づいて、署名者の属性情報と当該属性情報を証明するための証明情報とを含む証明書情報から、第１の部分証明書情報と第２の部分証明書情報とを作成し、前記電子文書および前記第１の部分証明書情報に対する電子署名を生成し、生成した前記電子署名を前記電子文書および前記第１の部分証明書情報に付与して、前記電子文書の提出元に送信し、前記電子文書の提出元と提出先とを接続する経路とは異なる別の経路を用いて、前記第２の部分証明書情報を検証装置に送信する情報処理装置と、
前記情報処理装置から前記第２の部分証明書情報を受信し、前記電子文書の提出先から第１の部分証明書情報を受信し、受信した前記第２の部分証明書情報と、受信した前記第１の部分証明書情報とに基づいて、前記署名者の証明書情報の真正性を検証する検証装置と、
を含むことを特徴とする情報処理システム。

１０１ 情報処理装置
１０２ 提出元
１０３ 提出先
１０４ 署名者
１０５ 検証装置
１１０，１５００ 電子文書
１２０ 証明書情報
１２１ 第１の部分証明書情報
１２２ 第２の部分証明書情報
１３０，１５１０ 電子署名
２００ 情報処理システム
２０１ 署名装置
２０２，２０３ 利用者端末
２０４ 検証サーバ
２０５ 認証サーバ
２１０ ネットワーク
２２０ ＩＤ流通基盤
２３０ マッチングテーブル
３００，４００ バス
３０１，４０１ ＣＰＵ
３０２，４０２ メモリ
３０３，４０３ ディスクドライブ
３０４，４０４ ディスク
３０５，４０５ 通信Ｉ／Ｆ
３０６ ディスプレイ
３０７ 入力装置
３０８，４０６ 可搬型記録媒体Ｉ／Ｆ
３０９，４０７ 可搬型記録媒体
６００ Ｃｒｅｄｅｎｔｉａｌ
７００ Ｐｒｏｏｆ
７１０，１５２０ 属性情報
７２０，８００ 証明情報
９０１ 受付部
９０２ 取得部
９０３ 作成部
９０４ 分割部
９０５ 生成部
９０６，１１０１ 第１の通信部
９０７，１１０３ 第２の通信部
１１０２ 登録部
１１０４ 検証部

Claims (9)

1. 電子文書に対する署名要求に応じて、前記電子文書のデータ量に基づいて、署名者の属性情報と当該属性情報を証明するための証明情報とを含む証明書情報から、第１の部分証明書情報と第２の部分証明書情報とを作成し、
   前記電子文書および前記第１の部分証明書情報に対する電子署名を生成し、
   生成した前記電子署名を前記電子文書および前記第１の部分証明書情報に付与して、前記電子文書の提出元に送信し、
   前記電子文書の提出元と提出先とを接続する経路とは異なる別の経路を用いて、前記署名者の証明書情報の真正性を検証する検証装置に前記第２の部分証明書情報を送信する、
   処理をコンピュータに実行させることを特徴とする情報処理プログラム。
2. 前記作成する処理は、
   前記電子文書のデータ量に対する第１の部分証明書情報のデータ量の割合が所定値以下となるように、前記属性情報、前記証明情報、前記属性情報の要約値および前記証明情報の要約値を、前記第１の部分証明書情報と第２の部分証明書情報とに分割する、ことを特徴とする請求項１に記載の情報処理プログラム。
3. 前記作成する処理は、
   前記属性情報と前記証明情報との第１の組合せ、前記属性情報と前記証明情報の要約値との第２の組合せ、および、前記属性情報の要約値と前記証明情報の要約値との第３の組合せのうち、前記第１の組合せまたは前記第２の組合せを、前記第３の組合せよりも優先して前記第１の部分証明書情報とする、ことを特徴とする請求項２に記載の情報処理プログラム。
4. 前記証明書情報は、認証機関により発行される前記署名者の属性証明書情報に基づき作成される、ことを特徴とする請求項１～３のいずれか一つに記載の情報処理プログラム。
5. 前記署名者の証明書情報の真正性は、前記検証装置に送信された前記第２の部分証明書情報と、前記電子文書の提出先から前記検証装置に送信される第１の部分証明書情報とに基づき検証される、ことを特徴とする請求項１～４のいずれか一つに記載の情報処理プログラム。
6. 前記電子文書の真正性は、前記電子署名に基づき検証される、ことを特徴とする請求項１～５のいずれか一つに記載の情報処理プログラム。
7. 電子文書に対する署名要求に応じて、前記電子文書のデータ量に基づいて、署名者の属性情報と当該属性情報を証明するための証明情報とを含む証明書情報から、第１の部分証明書情報と第２の部分証明書情報とを作成し、
   前記電子文書および前記第１の部分証明書情報に対する電子署名を生成し、
   生成した前記電子署名を前記電子文書および前記第１の部分証明書情報に付与して、前記電子文書の提出元に送信し、
   前記電子文書の提出元と提出先とを接続する経路とは異なる別の経路を用いて、前記署名者の証明書情報の真正性を検証する検証装置に前記第２の部分証明書情報を送信する、
   処理をコンピュータが実行することを特徴とする情報処理方法。
8. 電子文書に対する署名要求に応じて、前記電子文書のデータ量に基づいて、署名者の属性情報と当該属性情報を証明するための証明情報とを含む証明書情報から、第１の部分証明書情報と第２の部分証明書情報とを作成し、
   前記電子文書および前記第１の部分証明書情報に対する電子署名を生成し、
   生成した前記電子署名を前記電子文書および前記第１の部分証明書情報に付与して、前記電子文書の提出元に送信し、
   前記電子文書の提出元と提出先とを接続する経路とは異なる別の経路を用いて、前記署名者の証明書情報の真正性を検証する検証装置に前記第２の部分証明書情報を送信する、
   制御部を有することを特徴とする情報処理装置。
9. 電子文書に対する署名要求に応じて、前記電子文書のデータ量に基づいて、署名者の属性情報と当該属性情報を証明するための証明情報とを含む証明書情報から、第１の部分証明書情報と第２の部分証明書情報とを作成し、前記電子文書および前記第１の部分証明書情報に対する電子署名を生成し、生成した前記電子署名を前記電子文書および前記第１の部分証明書情報に付与して、前記電子文書の提出元に送信し、前記電子文書の提出元と提出先とを接続する経路とは異なる別の経路を用いて、前記第２の部分証明書情報を検証装置に送信する情報処理装置と、
   前記情報処理装置から前記第２の部分証明書情報を受信し、前記電子文書の提出先から第１の部分証明書情報を受信し、受信した前記第２の部分証明書情報と、受信した前記第１の部分証明書情報とに基づいて、前記署名者の証明書情報の真正性を検証する検証装置と、
   を含むことを特徴とする情報処理システム。

Images