JP5907830B2 - 署名生成検証システム及び署名検証装置 - Google Patents

Description

本発明は、電子文書に対してその完全性の保証と作成者の証明を目的に電子署名を作成・検証する電子署名システムに関する。

電子署名は、電子文書に対する偽造・改ざんの防止（完全性の保証）や、個人認証を目的として、広く利用されている。従来の電子署名システムにおいて、署名者はあらかじめ自分の秘密鍵と公開鍵のペアを生成し、公開鍵を公開しておく。秘密鍵は署名者のみが利用でき、他者に対しては秘密となるよう、一般的にはＩＣカード等に格納して署名者自身が管理する。署名者は任意の電子文書に対して、秘密鍵を利用して署名を生成することができ、検証者は公開鍵を用いて署名と電子文書の組が正しい（偽造・改ざんされていない）事を検証することができる。このような電子署名のアルゴリズムとしては、例えばＲＳＡ署名、ＤＳＡ、ＥｌＧａｍａｌ署名、Ｓｃｈｎｏｒｒ署名、楕円ＤＳＡ、楕円ＥｌＧａｍａｌ署名、楕円Ｓｃｈｎｏｒｒ署名などがある。

しかし電子署名システムにおいて公開鍵の所有者が詐称された場合、署名の正当性は失われてしまう。例えば署名者Ａが作成・署名した文書に対して、不正者Ｂが改ざんを加えた後に、Ａの署名をＢ自身の署名に置き換え、更にＢ自身の公開鍵をＡの公開鍵と偽って公開すると、署名検証者は不正者Ｂの改ざんした文書を、署名者Ａが作成した正当な文書として受け入れてしまう。

このような問題を回避するためのシステムとして、ＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）が利用されている(非特許文献１)。ＰＫＩでは、公開鍵とその所有者（主体者）ＩＤ等の情報の組に対して、信頼できる第三者機関（認証局）による署名が付与され、証明書として発行される。検証者はまず署名者の証明書に含まれる認証局の署名を検証したのち、証明書に含まれる公開鍵を用いて電子文書の署名を検証する。さらに認証局の公開鍵の正当性を保証するため、認証局の公開鍵に対して、より上位の認証局の署名を付与する。このようにPKIでは信頼の依存関係を一般的に木構造で構築し、最上位の認証局の証明書は全検証者が信頼するものとして、全体の信頼性を担保する方法が採られている。

また、主に電子メールに対する暗号化および署名を目的とするソフトウェアおよび規格として、ＰＧＰ(Ｐｒｅｔｔｙ Ｇｏｏｄ Ｐｒｉｖａｃｙ)が利用されている(非特許文献２)。ＰＧＰでは上記の問題に対するＰＫＩとは別の解決策として、以下に述べるＷｅｂ−ｏｆ−ｔｒｕｓｔという考え方を採用している。ＰＧＰのユーザは、自分の秘密鍵を用いて他の任意のユーザの公開鍵に対し署名を付与することができる。例えばユーザＡは、ユーザＢを何らかの方法で本人確認した上で、ユーザＢの公開鍵に対して署名を付与する。またユーザＣは、ユーザＡを何らかの方法で本人確認し、その公開鍵を信頼しているものとする。このときユーザＢがユーザＣに対して、ユーザＢの秘密鍵で署名を付与したメールおよび、ユーザＡの秘密鍵で署名が付与されたユーザＢの公開鍵を送付したとする。ユーザＣはユーザＢを知らない（信頼していない）としても、ユーザＡの公開鍵を信頼しているため、ユーザＢの署名付公開鍵をユーザＡの公開鍵で検証することにより、ユーザＢの公開鍵およびそれを用いて検証される電子メールの正当性を確認することができる。このように、「信頼できるユーザによって署名されている公開鍵は信頼できる」という考え方がＷｅｂ−ｏｆ−ｔｒｕｓｔである。

また、公開鍵をユーザＩＤそのもの（例えばユーザのメールアドレス）とする電子署名方式（ＩＤ−ｂａｓｅ署名）が提案されている（非特許文献３）。ＩＤ−ｂａｓｅ署名では、ユーザＩＤそのものが当該ユーザの公開鍵の役割を果たす。このため公開鍵に対して証明書を発行する必要はない。しかしながら、署名者は秘密鍵生成局（Ｐｕｂｌｉｃ Ｋｅｙ Ｇｅｎｅｒａｔｏｒ ： ＰＫＧ） と呼ばれる信頼できる第三者から、ユーザＩＤに対応する秘密鍵を生成・交付してもらう必要がある。このときＰＫＧは、申請者が当該ユーザＩＤを持つ本人であることを何らかの方法で確認する必要がある。

また、特許文献１では、ＰＫＩにおいて利用者が公開鍵を登録する際の本人確認手続きを簡素化することを目的に、バイオメトリクス情報Ｂと秘密情報Ｒを用いて公開鍵暗号の秘密鍵ＳＫを生成し、認証局から公開鍵証明書の発行を受ける際の本人確認として以下の処理を行う方法を開示している。すなわち秘密情報Ｒと利用者の第１のバイオメトリクス情報Ｂを用いて生成されたＲＳＡ公開鍵方式における秘密鍵ＳＫについて、利用者の第２のバイオメトリクス情報Ｂ’を求め、第２のバイオメトリクス情報Ｂ’を用いて、秘密鍵ＳＫが、秘密情報Ｒと第１のバイオメトリクス情報Ｂから生成されたことを検証する。

特開２００３−３２３１１６

カーライル・アダムス、スティーブ・ロイド著、鈴木優一 訳、「PKI 公開鍵インフラストラクチャの概念、標準、展開」、ピアソン・エデュケーション、2000年. Zimmermann， P. "The Official PGP User’s Guide，" Cambridge， MA： MIT Press， 1995 (second printing). Adi Shamir， "Identity-Based Cryptosystems and Signature Schemes，" Advances in Cryptology： Proceedings of CRYPTO 84， Lecture Notes in Computer Science， 7：47--53， 1984

PKIには以下に述べるように利便性とコストの課題がある。ＰＫＩを利用する場合、署名者は事前に認証局に対して本人性を証明し、審査を受ける必要がある。このため例えば窓口で身分証を提示する、あるいは郵送や電話で確認を行うなどの手続きが必要となる。これにともない認証局の運用コストが大きくなり、証明書の発行には一般に手数料が発生する。またＰＫＩは認証局を認証するための上位認証局や、更に上位の認証局を含む複雑なモデルとなるため、システム全体としての構築コストが莫大なものとなる問題がある。

ＩＤ−ｂａｓｅ署名においても、署名者は事前にＰＫＧに対して本人性を証明し、審査を受ける必要があるため、ＰＫＩと同様に利便性とコストの問題が発生する。

一方PGPには、信頼性の課題がある。ＰＧＰではＰＫＩの認証局のようにコストをかけて安全に運用されるＴＴＰ(Ｔｒｕｓｔｅｄ Ｔｈｉｒｄ Ｐａｒｔｙ)が存在せず、一般ユーザ自身が他人の公開鍵へ署名を付与し、Ｗｅｂ−ｏｆ−ｔｒｕｓｔの考え方で信頼の依存関係を広げ、システム全体の信頼性を担保しようとする。しかしユーザが他のユーザの公開鍵に署名を付与する際、きちんと本人確認を行うとは限らない。このためＩＤを詐称しているユーザの公開鍵に、正規ユーザが知らずに署名を付与してしまう危険性や、悪意を持つユーザのグループが互いの（詐称された）公開鍵に署名を付与しあう可能性もある。こうした脆弱性が、システム全体の信頼性を著しく低下させる可能性がある。

また特許文献１に記載の方法は、ＰＫＩにおいて事前に認証局に対して公開鍵を登録し、公開鍵証明書の発行を行う際に、非対面での本人確認を可能とすることで、利用者の利便性を多少改善できる効果がある。しかしながらいずれにしても認証局から事前に公開鍵証明書の発行を受ける必要があり、利便性・運用コストの課題は依然として残る。

ところで電子署名は本来、現実世界におけるサイン（手書き署名）・捺印の機能を電子的に実現することを主な目的としている。その対応関係において公開鍵証明書は、実印証明書またはサイン証明書に相当する。しかし現実世界における文書へのサイン・捺印は、必ずしもサイン登録や実印登録されていなくても有効であると（法的、あるいは社会通念的に）見なされる。これは、事後的にサイン照合や筆跡鑑定、印鑑照合等によって、ある程度の本人確認ができることが担保されているためである。このように現実世界では、事後的に何らかの方法で本人確認を可能とする物理的証跡（サイン等）を残すことにより、ある人物が意思を持って文書へ何らかの関与（作成、承認等）をしたことの保証とする、という方法論が採られている。しかしこの方法論は、電子的には実現できていない。これは電子署名における秘密鍵や公開鍵が、本質的に本人と不可分なものではないため、事前に何らかの本人確認を行って、公開鍵または秘密鍵と本人の紐付けを保証する必要があるためである。

本発明の目的は、現実世界におけるサイン・捺印と同様に、事前の本人確認を不要とすることで利便性とコストの課題を解決するとともに、必要に応じて事後的に確実な本人確認を行うことのできる、信頼性の高い電子署名システムを実現することにある。

本発明は以上の課題を解決するため、署名生成装置で生成された電子文書データと、電子署名および検証用データの組からなる署名データとを取得する署名付電子文書入力部と、検証用データを用いて電子文書データと電子署名の組の完全性を検証する完全性検証部と、検証用データがユーザ固有の情報である所定のユーザ証明情報に基づいて生成されたことを確認するための確認データを、ユーザ証明装置に送信し、ユーザ署名装置から送信された電子署名に基づいて本人確認を行う本人確認部と、完全性検証部による完全性の検証と、本人確認部による確認のいずれか一方または両方の結果に基づいて「受理」または「拒否」を出力する出力部とを備える署名検証装置と、ユーザ証明情報の入力を受け付けるユーザ証明情報入力部と、署名検証装置から受信した確認データに基づいて電子署名を作成し、電子署名を署名検証装置に送信する電子署名作成部とを備えるユーザ証明装置とを含む署名検証システムを提供する。

本発明によれば、事前の本人確認や鍵の登録等を必要とせずに、署名者が任意の電子文書に対して署名を付与するとともに、検証者が当該電子文書の完全性を検証し、更に必要に応じて署名作成者の本人確認、または複数の電子文書に対する署名が同一人物によって生成されたことの確認を、事後的に行うことが可能となる。

本実施例のシステム構成を示すブロック図である。 本実施例における署名生成処理を示す流れ図である。 本実施例における署名検証・署名者確認処理を示す流れ図である。 本実施例における署名検証・署名者同一性確認処理を示す流れ図である。 第三の本実施例における署名生成処理を示す流れ図である。 第三の本実施例におけるレスポンス生成処理を示す流れ図である。 第三の本実施例におけるレスポンス検証処理を示す流れ図である。 第三の本実施例における署名者同一性確認処理を示す流れ図である。 本実施例における署名生成装置、署名検証装置、ユーザ証明装置のハードウェア構成を示すブロック図である。

以下、図面を参照して、本発明の第一の実施例について説明する。
本実施例では、事前の本人確認や鍵の登録等を必要とせずに、署名者が任意の電子文書に対して署名を付与するとともに、検証者が当該電子文書の完全性を検証し、更に必要に応じて署名作成者の本人確認、または複数の電子文書に対する署名が同一人物によって生成されたことの確認（署名者同一性確認）を、（事後的に）行うことが可能な、電子署名生成・検証システムを例に説明する。本実施例のシステムは、例えばメールやＷｅｂページの作成者の証明、電子的な契約書への署名、ワークフローにおける承認、オフィス作業における成果物や作業ログに対する従事者の証明などに利用することができる。

図１に、本実施例における署名生成・検証システムのシステム構成を示す。
本システムは、電子文書に対して署名を生成する署名生成装置１００と、前記電子文書の完全性を前記署名を用いて検証するとともに必要に応じて前記署名を生成したユーザ（署名者）の本人確認を行う署名検証装置１１０と、本人確認の際に署名者が利用するユーザ証明装置１２０、署名者が所有するＩＣカード１３０とから構成される。

署名生成装置１００は、電子文書の入力を受け付ける電子文書入力部１０１と、署名者の証明情報（詳細は後述）の入力を受け付ける証明情報入力部１０３、電子文書に対して署名者の署名を生成する署名データ生成部１０４と、前記電子文書や前記署名データを出力する出力部１０５と、ネットワーク１４０を介した通信を行う通信部１０６とから構成される。出力部１０５は、前記電子文書や前記署名データをＵＳＢメモリ等の記録媒体へ出力したり、紙等の物理媒体に対してプリンタ等を介し文字あるいはバーコード等の形式で出力したり、あるいは前記通信部１０６と前記ネットワーク１４０を介して、署名検証装置１１０や、ストレージサーバ等へ送信してもよい。

署名検証装置１１０は、署名付電子文書を、ＵＳＢ等の記録媒体または紙等の物理媒体またはネットワーク経由で入力する、署名付電子文書入力部１１１と、電子文書が改ざんされていないこと（完全性）を検証する完全性検証部１１２と、必要に応じて署名者の本人確認を行う本人確認部１１３と、必要に応じて複数の電子文書に対する署名者が同一人物であることを確認する署名者同一性確認部１１４と、検証結果出力部１１５と、通信部１１６から構成される。

ユーザ証明装置１２０は前記署名生成装置１００と同様の構成を持ち、署名検証装置１１０と通信を行う。

前記証明情報は、各署名者のみが有する情報であり、かつ署名者毎に異なる情報であるとする。本実施例では、各署名者にはあらかじめＩＣカード１３０が発行されているものとし、前記ＩＣカード１３０には、予め鍵生成関数（Ｇｅｎ）によりカード毎にランダムに作成された公開鍵と秘密鍵のペア（Ｋｐ，Ｋｓ）１３１が記録されているものとする。 図８に、本実施例における署名生成装置１００、署名検証装置１１０、ユーザ証明装置１２０、のハードウェア構成を示す。これらは図のようにＣＰＵ８００、ＲＡＭ８０１、ＨＤＤ８０２、入力装置８０３、出力装置８０４、通信装置８０５とから構成することができる。

次に本実施例における署名生成処理フローを図２を用いて説明する。

署名生成装置１００は、電子文書入力部１０１を通して電子文書Ｍを取得する（Ｓ２０１）。前記電子文書は、例えばネットワークを介して受信してもよいし、ＵＳＢメモリ等の記録媒体から読み取ってもよい。あるいは前記署名生成装置１００の上で作成された電子文書を読み込んでもよい。

証明情報入力部１０３は、ＩＣカード１３０から秘密鍵と公開鍵のペア（Ｋｐ，Ｋｓ）１３１を読み込む（Ｓ２０２）。

署名データ生成部１０４は、前記電子文書Ｍに対して前記秘密鍵を用いて電子署名σ＝Ｓｉｇｎ（Ｍ，Ｋｓ）を生成し、前記公開鍵とペアにしたＳ＝（σ，Ｋｐ）を署名データとする（Ｓ２０３）。署名生成関数（Ｓｉｇｎ）、後述する署名検証関数（Ｖｅｒｉｆｙ）、前記鍵生成関数（Ｇｅｎ）としては、任意の電子署名アルゴリズム、例えばＲＳＡ署名やＤＳＡなどを用いてよい。

署名データ出力部は、前記署名データＳ＝（σ，Ｋｐ）を出力する（Ｓ２０４）。

次に本実施例において、前記電子文書Ｍの完全性を前記署名データＳを用いて検証するとともに、署名作成者の本人確認を行う際の処理フローを、図３を用いて説明する。

署名検証装置１１０は、署名付電子文書入力部１１１を通して電子文書Ｍおよび署名データＳ＝（σ，Ｋｐ）を取得する（Ｓ３００）。前記電子文書Ｍおよび前記署名データＳは、例えばネットワークを介して受信してもよいし、ＵＳＢメモリ等の記録媒体から読み取ってもよい。

完全性検証部１１２は、前記電子文書Ｍと前記署名データＳに含まれる電子署名σの組みを、前記署名データＳに含まれる前記公開鍵Ｋｐを用いて検証し、検証結果ｖ＝Ｖｅｒｉｆｙ（Ｍ，σ，Ｋｐ）（ｖ＝「成功」または「失敗」）を得る（Ｓ３０１）。

電子文書が改ざんされていないことのみを検証したい場合、署名検証装置１１０は前記検証結果ｖを出力し、処理を終了してもよい。
例えば電子的な契約書を交わす際、当事者がそれぞれ電子契約書に署名データを付与することを考える。契約時には、当事者が互いに署名データ付き電子契約書を交換しその完全性を検証することで契約成立とするが、仮に契約不履行となった場合には、裁判等で当事者（署名者）の本人確認を行う、といった運用が考えられる。この場合、契約時には上記ステップＳ３０１までで処理を終了し、契約不履行時の係争時等にステップＳ３０２以降の処理を実行する。

あるいは、例えばあるプロジェクトにおいて逐次的に発生する作業ログに対し、各従事者の署名データを付与してログサーバに集中管理するシステムを考える。本システムにおいて、平時はバッチ処理として定期的に前記作業ログの完全性検証のみを行うが、仮に事故等が発生した場合には事後的に当該事故に関わる作業従事者（署名者）の本人確認を行う、といった運用が考えられる。この場合、平時は前記ステップＳ３０１までで処理を終了し、システムの管理者による設定変更により、事故が発生したことを取得した場合にステップＳ３０２以降の処理を実行する。

以降は、このように事後的に署名者の本人確認を行う際の処理フローを説明する。以後、本人確認を行う対象人物（署名者と思われる人物）を候補者と呼ぶことにする。

本人確認部１１３は、ランダムなデータ（チャレンジコードＲ）を生成し、ユーザ証明装置１２０に対して送信する（Ｓ３０２）。チャレンジコードＲは、例えば時刻情報などをシードとして疑似乱数生成器を用いて生成することができる。

ユーザ証明装置１２０は、候補者から予め入力された証明情報から生成された前記公開鍵と秘密鍵のペア（Ｋｐ’，Ｋｓ’）１３１を取得する（Ｓ３０３）。

ユーザ証明装置１２０は、前記チャレンジコードＲに対し、前記秘密鍵Ｋｓを用いて電子署名σ’＝Ｓｉｇｎ（Ｒ，Ｋｓ’）を生成し、レスポンスとして電子署名を前記署名検証装置１１０に送信する（Ｓ３０４）。

署名検証装置１１０は前記レスポンスである電子署名σ’を受信し、本人確認部１１３が前記公開鍵Ｋｐを用いて、前記レスポンスである電子署名σ’が前記チャレンジコードＲに対する正しい電子署名であるかを検証し、検証結果ｖ’＝Ｖｅｒｉｆｙ（Ｒ，σ’，Ｋｐ）を得る（Ｓ３０５）。Ｋｓ＝Ｋｓ’であるときに限ってｖ’＝「成功」となることに注意する。

検証結果出力部１１５は、前記検証結果ｖおよび検証結果ｖ’がいずれも「成功」であった場合にのみ「受理」、そうでなければ「拒否」を出力する。

本実施例によれば、署名者は、本人確認を伴う公開鍵や秘密鍵の事前登録を必要とせずに、電子文書に対して署名データを生成することができ、検証者はその署名データを検証することで前記電子文書の完全性を検証するとともに、必要に応じて事後的に署名者の本人確認を行うことが可能となる。完全性の検証処理と本人確認処理に、同じ公開鍵Ｋｐを用いることにより、署名生成者（Ｋｓを所有している人物）と候補者（Ｋｓ’を所有している人物）の同一性を、（ＩＣカードが常に同一人物により所有されていることを前提に）検証することができる。

次に本実施例において、２つ以上の電子文書の完全性を検証するとともに、その署名データが同一の署名者により生成されたものか否かを検証する署名者同一性検証処理のフローを、図４を用いて説明する。

こういった処理が必要なアプリケーションとして、例えばあるプロジェクトにおいて逐次的に発生する作業ログに対し、各従事者の署名データを付与してログサーバに集中管理するシステムを考える。本システムにおいて、平時はバッチ処理として定期的に前記作業ログの完全性検証のみを行うが、仮にある作業の品質が著しく低い等の問題が発生した場合、当該作業の従事者が関わった他の作業を特定するために、２つ以上の作業ログに対する署名が同一人物によるものかを確認する必要がある。

署名検証装置１１０は、署名付電子文書入力部１１１を通して二つの電子文書Ｍ１、Ｍ２および二つの署名データＳ１＝（σ１，Ｋｐ１）、Ｓ２＝（σ２，Ｋｐ２）を取得する（Ｓ４００）。

完全性検証部１１２は、前記電子文書Ｍ１と前記署名データＳ１に含まれる電子署名σ１の組みを、前記署名データＳ１に含まれる前記公開鍵Ｋｐ１を用いて検証し、検証結果ｖ１＝Ｖｅｒｉｆｙ（Ｍ１，σ１，Ｋｐ１）（ｖ１＝「成功」または「失敗」）を得る。同様にｖ２＝Ｖｅｒｉｆｙ（Ｍ２，σ２，Ｋｐ２）を得る。（Ｓ４０１）。

次に署名者同一性確認部１１４は、前記公開鍵Ｋｐ１と前記公開鍵Ｋｐ２を比較し、同一の公開鍵であれば「成功」、そうでなければ「失敗」と判断する（Ｓ４０２）。

検証結果出力部１１５は、ｖ１、ｖ２および前記ステップＳ４０２の判断結果が全て「成功」であれば「受理」、そうでなければ「拒否」を出力する（Ｓ４０３）。

本実施例によれば、署名者は、本人確認を伴う公開鍵や秘密鍵の事前登録を必要とせずに、電子文書に対して署名データを生成することができ、検証者はその署名データを検証することで前記電子文書の完全性を検証するとともに、必要に応じて二つの文書に対する各々の署名が同一署名者によるものかを事後的に検証することが可能となる。二つの文書の完全性検証処理が、同一の公開鍵を用いて検証成功となることを確認することにより、それぞれの署名生成者（それぞの署名生成時に秘密鍵Ｋｓを所有していた人物）の同一性を、（ＩＣカードが常に同一人物により所有されていることを前提に）保証することができる。

次に第二の実施例として、署名者の証明情報を、署名者が記憶している秘密情報（例えばパスワード）とした場合を説明する。本実施例におけるシステム構成および処理フローは、以下の点を除いて第一の実施例と同様である。

第二の実施例においては、ＩＣカード１３０が不要となり、署名者証明情報取得ステップ（Ｓ２０２）および候補者証明情報取得ステップ（Ｓ３０３）が以下の通り変更となる。

証明情報入力部１０３は、署名者からパスワード入力を受け付け、前記パスワードをシードとして秘密鍵と公開鍵のペア（Ｋｐ，Ｋｓ）１３１を生成する（Ｓ２０２）。パスワードからの鍵生成方法としては、例えばＰＢＥなどの方法がある。

ユーザ証明装置１２０は、候補者からパスワード入力を受け付け、前記パスワードをシードとして秘密鍵と公開鍵のペア（Ｋｐ’，Ｋｓ’）１３１を生成する（Ｓ３０３）。

次に第三の実施例として、署名者の証明情報を、署名者の生体情報（例えば指紋や静脈、虹彩等の特徴データ）とする場合を説明する。本実施例におけるシステム構成および処理フローは、以下の点を除いて第一の実施例と同様である。

第三の実施例においては、ＩＣカード１３０が不要となり、署名者証明情報取得ステップ（Ｓ２０２）、署名データ生成ステップ（Ｓ２０３）、候補者証明情報取得ステップ（Ｓ３０３）、レスポンス生成・送信ステップ（Ｓ３０４）、レスポンス検証ステップ（Ｓ３０５）、署名者同一性確認ステップ（Ｓ４０２）が以下の通り変更となる。

なお生体情報はパスワード等と異なり、たとえ同一人物の同一生体から取得した特徴データであっても、取得する度に変動することに注意が必要である。これは生体情報を読み取る際の位置ずれや回転、歪み、照明環境等の変動、生体の経年変化など多様な要因に起因する。このため２つの特徴データが、ある距離基準において十分「近い」ならば、同一の生体（同一人物）であると判断する。

以下、図５を用いてステップＳ２０２、Ｓ２０３の詳細について説明する。

証明情報入力部１０３は、署名者の生体情報を取得する（Ｓ２０２）。

署名データ生成部１０４は、前記署名者の生体情報から特徴量Ｘを抽出する（Ｓ５００）。

署名データ生成部１０４は、所定の電子署名アルゴリズム（例えばＤＳＡやＳｃｈｎｏｒｒ署名）における公開鍵と秘密鍵のペア（Ｋｐ，Ｋｓ）をランダムに生成する（Ｓ５０１）。

署名データ生成部１０４は、前記秘密鍵Ｋｓを用いて前記電子文書Ｍに対する電子署名σ＝Ｓｉｇｎ（Ｍ，Ｋｓ）を生成する（Ｓ５０２）。

署名データ生成部１０４は、所定の埋め込み関数Ｅｍｂを用いて、前記特徴量Ｘに対して前記秘密鍵Ｋｓを埋め込み、コミットメントＣ＝Ｅｍｂ（Ｘ，Ｋｓ）を作成する（Ｓ５０３）。このとき前記コミットメントＣからは、前記特徴量Ｘおよび前記秘密鍵Ｋｓを推定することが十分に困難であるように埋め込む。埋め込み関数Ｅｍｂの具体例は後述する。

署名データ生成部１０４は、前記電子署名σ、前記公開鍵Ｋｐ、前記コミットメントＣを組として署名データＳ＝（σ，Ｋｐ，Ｃ）を作成する（Ｓ５０４）。

次に図６を用いてステップＳ３０３，Ｓ３０４の詳細を説明する。
ユーザ証明装置１２０は、候補者の生体情報を読み取る（Ｓ３０３）。
ユーザ証明装置１２０は、前記候補者の生体情報から特徴量Ｘ’を抽出する（Ｓ６００）。
ユーザ証明装置１２０は、所定の電子署名アルゴリズム（例えばＤＳＡやＳｃｈｎｏｒｒ署名）における公開鍵と秘密鍵のペア（Ｋｐ’，Ｋｓ’）をランダムに生成する（Ｓ６０１）。

ユーザ証明装置１２０は、前記秘密鍵Ｋｓ’を用いて前記チャレンジコードＲに対する電子署名σ’＝Ｓｉｇｎ（Ｒ，Ｋｓ’）を生成する（Ｓ６０２）。
ユーザ証明装置１２０は、所定の埋め込み関数Ｅｍｂを用いて、前記特徴量Ｘ’に対して前記秘密鍵Ｋｓ’を埋め込み、コミットメントＣ’＝Ｅｍｂ（Ｘ’，Ｋｓ’）を作成する（Ｓ６０３）。

ユーザ証明装置１２０は、前記電子署名σ’、前記公開鍵Ｋｐ’、前記コミットメントＣ’を組としてレスポンスＳ’＝（σ’，Ｋｐ’，Ｃ’）を作成し、署名検証装置１１０に送信する（Ｓ６０４）。

次に図７を用いてレスポンス検証ステップＳ３０５の詳細を説明する。以下のステップは本人確認部１１３が実行する。

本人確認部１１３はユーザ照明装置１２０からレスポンスＳ’＝（σ’，Ｋｐ’，Ｃ’）を受信する（Ｓ７００）。

本人確認部１１３は、前記電子署名σ’が前記チャレンジコードＲに対する正しい電子署名であるか否かを前記公開鍵Ｋｐ’を用いて検証し、検証結果Ｖｅｒｉｆｙ（Ｒ，σ’，Ｋｐ’）を得る（Ｓ７０１）。

本人確認部１１３は、前記署名データＳに含まれる前記コミットメントＣと、前記レスポンスＳ’に含まれる前記コミットメントＣ’とから、所定の関数Ｅｘｔを用いて、差分秘密鍵Ｋｄ＝Ｅｘｔ（Ｃ，Ｃ’）を計算する（Ｓ７０２）。このとき、前記特徴量Ｘと前記特徴量Ｘ’が十分近ければ（類似していれば）、前記差分秘密鍵Ｋｄが、前記秘密鍵Ｋｓと前記秘密鍵Ｋｓ’との間の「差」に相当する所定の演算結果に等しくなる（Ｋｄ＝Ｋｓ−Ｋｓ’）よう、所定の関数Ｅｘｔを構成する。関数Ｅｘｔの具体例は後述する。

本人確認部１１３は、前記署名データに含まれる前記公開鍵Ｋｐと、前記レスポンスに含まれる前記公開鍵Ｋｐ’を用いて、前記差分秘密鍵ＫｄがＫｄ＝Ｋｓ−Ｋｓ’の関係を満たすことを検証する（Ｓ７０３）。具体的な検証方法は後述する。Ｓ７０１およびＳ７０３のいずれの検証も成功した場合に限って、レスポンス検証ステップＳ３０５の結果を「成功」とする。

本実施例によれば、署名者が候補者と同一人物であるならば、前記特徴量Ｘと前記特徴量Ｘ’は十分近くなる（類似する）ことが見込まれる。このとき前記差分秘密鍵Ｋｄは前記秘密鍵Ｋｓと前記秘密鍵Ｋｓ’との「差」に一致し（ＫＳｄ＝ＫＳｅ−ＫＳｓ）、差分鍵検証（Ｓ７０３）に成功する。逆に署名生成ユーザと登録ユーザが異なる人物であるならば、前記登録用特徴量Ｘと前記署名用特徴量Ｘ’は近くない（類似しない）ことが見込まれる。このとき前記差分秘密鍵ＫＳｄは前記秘密鍵Ｋｓと前記秘密鍵Ｋｓ’との「差」に一致せず（Ｋｄ≠Ｋｓ−Ｋｓ’）、差分鍵検証（Ｓ７０３）に失敗する。

以上述べたように、本実施例では電子文書の完全性を署名者が一時的に生成した秘密鍵Ｋｓ用いた署名σおよび、対応する公開鍵Ｋｐにより検証するとともに、署名者の特徴量Ｘに対して秘密鍵Ｋｓを不可分な形で埋め込んだコミットメントＣにより、事後的な本人確認を可能とする。コミットメントＣにより、署名σと生体特徴量Ｘとが、公開鍵Ｋｐを介して結びついていることに注意されたい。
本人確認時にも同様に、候補者がチャレンジコードに対して署名σ’を生成し、公開鍵Ｋｐ’およびコミットメントＣ’とともに署名検証装置１１０へ提示する。署名検証装置１１０はこれを検証すると同時に、コミットメントＣ，Ｃ’が同一の生体特徴量から作成されたか否かを公開鍵Ｋｐ、Ｋｐ’を用いて検証することにより、候補者が署名者本人であることを確認することができる。

次に図８を用いて署名者同一性確認ステップ（Ｓ４０２）の詳細を説明する。

まず本実施例では、ステップＳ４００において電子文書Ｍ１、Ｍ２とともに入力される署名データＳ１、Ｓ２は、Ｓ１＝（σ1，Ｃ１，Ｋｐ１）、Ｓ２＝（σ1，Ｃ２，Ｋｐ２）という形をしていることに注意する。ここで、コミットメントＣ１は第一の署名者の生体特徴量Ｘ１に対し、公開鍵Ｋｐ１に対応する秘密鍵Ｋｓ１を埋め込んだデータ（Ｃ１＝Ｅｍｂ（Ｘ１，Ｋｓ１））であり、コミットメントＣ２は第二の署名者の生体特徴量Ｘ２に対し、公開鍵Ｋｐ２に対応する秘密鍵Ｋｓ２を埋め込んだデータ（Ｃ２＝Ｅｍｂ（Ｘ２，Ｋｓ２））であるとする。

署名者同一性確認部１１４は、前記署名データＳ１に含まれる前記コミットメントＣ１と、前記署名データＳ２に含まれる前記コミットメントＣ２とから、所定の関数Ｅｘｔを用いて、差分秘密鍵Ｋｄ＝Ｅｘｔ（Ｃ１，Ｃ２）を計算する（Ｓ８００）。このとき、前記特徴量Ｘ１と前記特徴量Ｘ２が十分近ければ（類似していれば）、前記差分秘密鍵Ｋｄが、前記秘密鍵Ｋｓ１と前記秘密鍵Ｋｓ２との間の「差」に相当する所定の演算結果に等しくなる（Ｋｄ＝Ｋｓ１−Ｋｓ２）ことに注意する。

署名者同一性確認部１１４は、前記署名データＳ１に含まれる前記公開鍵Ｋｐ１と、前記署名データＳ２に含まれる前記公開鍵Ｋｐ２を用いて、前記差分秘密鍵ＫｄがＫｄ＝Ｋｓ１−Ｋｓ２の関係を満たすことを検証する（Ｓ８０１）。具体的な検証方法は後述する。Ｓ８００およびＳ８０１のいずれの検証も成功した場合に限って、署名者同一性確認ステップＳ３０５の結果を「成功」とする。

このように本実施例では、署名σ１、σ２、コミットメントＣ１、Ｃ２、公開鍵Ｋｐ１、Ｋｐ２、生体情報Ｘ１、Ｘ２を相互に関連させることにより、二つの署名が同一の人物により生成されたことを事後的に検証可能としている。

以下では、前記所定の関数Ｅｍｂ，Ｅｘｔの具体的な構成例について説明する。

登録用特徴量および署名用特徴量

はｎ次元の実数ベクトルとし、その間の距離はＬ１距離

とする。距離が所定の閾値t以下（d(X，X')≦t）ならば一致（同一生体）とみなす。また格子点集合Ｌを、

と定義する。ここでKはtや|xi|より十分大きい所定の整数とする。更に整数ベクトルＹ∈Ｌに対して一つの整数zを対応させる関数intを以下のように定義する。

また上記の逆関数（整数zに対してベクトルYを対応させる関数）を、

と表記する。

前記所定の電子署名アルゴリズムとしては、Ｓｃｈｎｏｒｒ署名を用いる。Ｓｃｈｎｏｒｒ署名の秘密鍵Ｋｓ、公開鍵Ｋｐは以下のように生成される。まず秘密鍵Ｋｓはランダムに生成された整数とし、公開鍵Ｋｐは

とする。ここでpは十分大きな素数とし、gはpを法とする整数の剰余環Zpの乗法群の生成元とする。p，gは公開のパラメータとし、全ユーザに対して共通の値とする。
以上の準備のもとで、前記埋め込み関数Ｅｍｂを以下のように定義する。

また前記所定の関数Ｅｘｔを以下のように定義する。

ここで[v]は、実数ベクトルvに対して、vの各成分（実数）を整数に丸めた（最も近い整数に写像した）整数ベクトルを表す。また

は、１をｎ個並べたベクトルとする。このときCe，Csの作り方より、

が成立し、従ってd(X，X')≦tならば、

が成立する。ここで

とした。

前記所定の関数Ｄｉｆｆは以下のように定義する。

上記の定義より、差分鍵検証（ステップＳ７０３、Ｓ８０１）は、等式

が成立するか否かを確認すればよい。

１００ 署名生成装置
１０１ 電子文書入力部
１０３ 証明情報入力部
１０４ 署名データ生成部
１０５ 出力部
１０６ 通信部
１１０ 署名検証装置
１１１ 署名付電子文書入力部
１１２ 完全性検証部
１１３ 本人確認部
１１４ 署名者同一性確認部
１１５ 検証結果出力部
１１６ 通信部
１２０ ユーザ証明装置
１３０ ＩＣカード
１４０ ネットワーク
９００ ＣＰＵ
９０１ ＲＡＭ
９０２ ＨＤＤ
９０３ 入力装置
９０４ 出力装置
９０５ 通信装置

Claims (5)

1. 署名者のみが有する署名者証明情報を受け付ける署名者証明情報入力部と、前記署名者証明情報に基づいて秘密鍵と公開鍵のペアを生成し、前記秘密鍵を用いて電子文書データに対する第１の電子署名を生成する署名データ生成部と、前記第１の電子署名および前記公開鍵を署名データとし署名検証装置に送信する署名データ出力部と、を備える署名生成装置から、前記電子文書データと、前記第１の電子署名および前記公開鍵からなる署名データと、を取得する署名付電子文書入力部と、
   前記公開鍵を用いて前記電子文書データの改竄有無を検証する完全性検証部と、
   前記第１の電子署名を生成したユーザから予め入力された証明情報に基づき本人確認をするためのチャレンジコードをユーザ証明装置に送信し、前記ユーザ証明装置から送信された第２の電子署名に基づいて本人確認を行う本人確認部と、
   前記完全性検証部が前記公開鍵を用いて前記第２の電子書名につき改竄有無を検証した結果と、前記本人確認部による本人確認結果と、に基づいて「受理」または「拒否」を出力する出力部と、
   を備える署名検証装置と、
   前記証明情報の入力を受け付ける証明情報入力部と、
   受け付けた証明情報に基づき秘密鍵を生成し、当該秘密鍵と、前記署名検証装置から受信したチャレンジコードと、に基づいて第２の電子署名を作成し、当該第２の電子署名を前記署名検証装置に送信する電子署名作成部と、
   を備えるユーザ証明装置と、
   を備えることを特徴とする署名生成検証システム。
2. 前記署名データ生成部は、ランダムに秘密鍵と公開鍵のペアを生成し、前記秘密鍵を用いて前記電子文書データに対する前記第１の電子署名を生成し、前記署名者証明情報と前記秘密鍵とから検証用コミットメント情報を生成し、
   前記署名データ出力部は、前記署名データに前記検証用コミットメント情報を含めて前記署名検証装置に送信し、
   前記電子署名作成部は、前記本人確認部から前記チャレンジコードを受信し、ランダムに一時秘密鍵と一時公開鍵のペアを生成し、前記一時秘密鍵を用いて前記チャレンジコードに対する前記第２の電子署名を生成し、前記証明情報と前記一時秘密鍵とから一時コミットメント情報を生成し、前記チャレンジコードに対する前記第２の電子署名と、前記一時公開鍵と、前記一時コミットメント情報と、を生成し、前記第２の電子署名を前記署名検証装置へ送信し、
   前記本人確認部は、前記ユーザ証明装置に対してチャレンジコードを送信し、前記ユーザ証明装置から前記第２の電子署名を受信し、前記チャレンジコードに対する電子署名を前記一時公開鍵で検証し、前記検証用コミットメント情報と、前記一時コミットメント情報に対して所定の演算を施すことで差分秘密鍵を作成するとともに、前記公開鍵と、前記一時公開鍵と、前記差分秘密鍵との対応を検証するコミットメント確認を実施する、
   ことを特徴とする、請求項１に記載の署名生成検証システム。
3. 前記署名者証明情報は前記署名者のみが知る秘密情報であり、
   前記ユーザ証明情報は前記ユーザのみが知る秘密情報である、
   ことを特徴とする請求項２に記載の署名生成検証システム。
4. 前記署名者証明情報は前記署名者の生体から取得した生体情報であり、
   前記ユーザ証明情報は前記ユーザの生体から取得した生体情報である、
   ことを特徴とする請求項２に記載の署名生成検証システム。
5. 前記署名者証明情報は前記署名者の生体から取得した署名者生体情報であり、
   前記ユーザ証明情報は前記ユーザの生体から取得したユーザ生体情報であり、
   前記コミットメント確認では、前記署名者生体情報と前記ユーザ生体情報が十分類似している場合に成功となる、
   ことを特徴とする、請求項２に記載の署名生成検証システム。

Images