JP2018014622A - 署名検証システム、署名検証方法及びプログラム - Google Patents

Abstract

【課題】秘密鍵の紛失や漏洩が発生した場合にも、継続的なトランザクション生成を可能とするシステムを、ユーザの利便性を低下させずに提供する。【解決手段】プロセッサとメモリを備えた計算機で署名を検証する署名検証システムであって、ユーザの生体情報を取得する生体情報取得部と、前記生体情報に所定の処理を加えて公開テンプレート証明書を生成する公開テンプレート証明書生成部と、秘密鍵と公開鍵のペアを生成する鍵ペア生成部と、前記生体情報を鍵として前記公開鍵へ生体署名を付与することで公開鍵証明書を生成する公開鍵証明書生成部と、前記公開テンプレート証明書と前記公開鍵証明書と署名を含むトランザクションを受け付けて、前記公開テンプレート証明書で前記公開鍵証明書の正当性を検証し、さらに前記公開鍵証明書で前記署名を検証する検証部と、を有する。【選択図】図１０

Description

本発明は、Ｐ２Ｐ（Peer-to-peer）ネットワーク上で分散型台帳管理を実現するブロックチェーン（署名検証）システムに関する。

Ｐ２Ｐネットワーク上で分散型台帳管理を実現する技術として、ブロックチェーンがある。ブロックチェーンでは、記録情報を含むトランザクションを作成し、それを電子署名に基づき鎖状に繋ぐことで、記録情報の一貫性を確保している。

ブロックチェーンの一例として、非特許文献１で開示されたＢｉｔｃｏｉｎに代表される、記録情報を保証するユーザが自らの秘密鍵でトランザクションに対して電子署名を付与することでチェーンを形成するシステムがある。このようなブロックチェーンシステムでは、トランザクション内に含まれる公開鍵に基づき、トランザクションに対する電子署名を検証することで、正規のユーザがトランザクションを生成したことを判定する。

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

ＮＡＫＡＭＯＴＯ, Ｓａｔｏｓｈｉ 著、"Bitcoin: A peer-to-peer electronic cash system." 、２００８年発行

ブロックチェーンシステムでは、ユーザが自らの秘密鍵を用いて電子署名を生成することでトランザクションを生成するため、当該秘密鍵を紛失した場合、正しいトランザクションを生成することができなくなり、継続的にシステムを利用することが困難となる。また、秘密鍵の盗難に遭った場合は、秘密鍵を取得した第三者が不正にトランザクションを生成することが可能となり、なりすましを行うことが可能となる。

このような課題に対する自明かつ有効な解として、紛失や盗難が起きにくい形で秘密情報を管理する方式が挙げられる。紛失や盗難が起きにくい情報に基づき公開鍵暗号を実現する方式として、特許文献１で開示されている生体署名がある。生体署名は、指紋、静脈、顔などに代表される生体情報を鍵として、メッセージに対する署名生成や署名検証を実現する技術である。生体情報は人間の身体的な特徴をセンシングしたものであるため、公知または周知の公開鍵暗号の秘密鍵に比べて、紛失や盗難が発生しにくい。

しかしながら、ブロックチェーンシステムのユースケースによっては、頻繁にトランザクションの生成を行う必要がある場合や、人が介在せず自動的にトランザクション生成を行う必要がある場合がある。このような場合は、トランザクション生成の度にユーザの電子署名を必要とする。生体署名ではトランザクション生成の度に生体情報を入力することになるので、ユーザの利便性が低下する可能性があった。

本発明の目的は、秘密鍵の紛失や漏洩が発生した場合にも、継続的なトランザクション生成を可能とするシステムを、ユーザの利便性を低下させずに実現することである。

本発明は、プロセッサとメモリを備えた計算機で署名を検証する署名検証システムであって、ユーザの生体情報を取得する生体情報取得部と、前記生体情報に所定の処理を加えて公開テンプレート証明書を生成する公開テンプレート証明書生成部と、秘密鍵と公開鍵のペアを生成する鍵ペア生成部と、前記生体情報を鍵として前記公開鍵へ生体署名を付与することで公開鍵証明書を生成する公開鍵証明書生成部と、前記公開テンプレート証明書と前記公開鍵証明書と署名を含むトランザクションを受け付けて、前記公開テンプレート証明書で前記公開鍵証明書の正当性を検証し、さらに前記公開鍵証明書で前記署名を検証する検証部と、を有する。

本発明によれば、ユーザの既存秘密鍵の紛失または漏洩が発生した際には、ユーザが公開鍵失効申請書を発行することで、既存の秘密鍵を用いたトランザクション生成を無効化し、新たな秘密鍵と新たな公開鍵のペアを生成し、生体情報を鍵として新たな公開鍵に生体署名を付与することで新たな公開鍵証明書を発行し、その後、新たな秘密鍵を用いてトランザクションの生成を行うことで、既存の秘密鍵を使わずに継続的に署名検証システムを利用することが可能になる。

本発明の実施例１を示し、ブロックチェーンシステムの一例を示すブロック図である。 本発明の実施例１を示し、公開テンプレート証明書発行の処理手順を示すフローチャートである。 本発明の実施例１を示し、初期登録の処理手順を示すフローチャートである。 本発明の実施例１を示し、ブロックチェーンシステムにおけるトランザクション生成及びトランザクション検証の処理手順を示すフローチャートである。 本発明の実施例１を示し、新トランザクション生成の処理手順を示すフローチャートである。 本発明の実施例１を示し、トランザクション検証の処理手順を示すフローチャートである。 本発明の実施例１を示し、公開鍵失効の処理手順を示すフローチャートである。 本発明の実施例１を示し、鍵再発行の処理手順を示すフローチャートである。 本発明の実施例１を示し、公開テンプレート証明書のデータ構造を示す図である。 本発明の実施例１を示し、公開鍵証明書のデータ構造を示す図である。 本発明の実施例１を示し、公開鍵失効申請書のデータ構造を示す図である。 本発明の実施例１を示し、証明書失効リストのデータ構造を示す図である。 本発明の実施例１を示し、生体署名を活用したブロックチェーンのデータ構造を示す図である。 本発明の実施例１を示し、署名端末、検証端末、公開テンプレートリポジトリのハードウェア構成を示すブロック図である。 本発明の実施例２を示し、ブロックチェーンシステムの一例を示すブロック図である。 本発明の実施例２を示し、公開テンプレート証明書発行の処理手順を示すフローチャートである。 本発明の実施例２を示し、公開鍵失効の処理手順を示すフローチャートである。 本発明の実施例２を示し、公開テンプレート証明書のデータ構造を示す図である。 本発明の実施例２を示し、公開鍵証明書のデータ構造を示す図である。 本発明の実施例２を示し、公開鍵失効申請書のデータ構造を示す図である。 本発明の実施例３を示し、ブロックチェーンシステムの一例を示すブロック図である。 本発明の実施例３を示し、ブロックチェーンシステムで行われる登録処理の一例を示すシーケンス図である。 本発明の実施例３を示し、ブロックチェーンシステムで行われるトランザクションの検証処理の一例を示すシーケンス図である。 本発明の実施例３を示し、ブロックチェーンシステムで行われる鍵の再発行処理の一例を示すシーケンス図である。 本発明の実施例４を示し、生体署名を活用したブロックチェーンのデータ構造を示す図である。

以下、本発明の実施形態を添付図面に基づいて説明する。

本実施例は、ブロックチェーンシステム（生体署名システム）のユーザが自らの秘密鍵の紛失または漏洩時に、ユーザの生体情報を鍵とする生体署名を用いることで、秘密鍵を失効（無効化）させて新たな秘密鍵を再発行し、継続的にブロックチェーンシステムを利用することを可能とするシステムである。

以降、図面を参照して手順を説明する。

図１は、本発明の実施例１の、ブロックチェーンシステムの構成の一例を示すブロック図である。ブロックチェーンシステムは、署名端末１０００と、検証端末１１０００と、公開テンプレートリポジトリ１２００と、ユーザ端末１３００と、これらの端末を相互に接続するネットワーク１００、を含む。

この図において、署名端末１０００は、通信部１０１０と、生体情報取得部１０２０と、公開テンプレート生成部１０３０と、鍵ペア生成部１０４０と、公開鍵証明書生成部１０５０と、記録情報取得部１０６０と、ハッシュ値生成部１０６１と、署名生成部１０７０と、新トランザクション生成部１０７１と、公開鍵失効申請書生成部１０８０、鍵格納部１０９１、公開テンプレート証明書格納部１０９２を含んで構成される。

通信部１０１０は、ネットワーク１００を介して検証端末１１００と、公開テンプレートリポジトリ１２００の間で通信を行う。

生体情報取得部１０２０は、例えば、指紋センサ、静脈センサ、カメラなどを介して、ユーザから指紋、静脈、顔画像などの生体情報を取得する。なお、生体情報を取得するセンサとして携帯電話やスマートフォンの指紋センサや静脈センサやカメラを用いることができる。

公開テンプレート生成部１０３０は、特許文献１の方式に従い、生体情報取得部１０２０で取得した生体情報に対して一方向性（不可逆）変換を施すことで、公開テンプレートを生成する。なお、一方向性変換としては、公知または周知の変換処理を適用すれば良い。

鍵ペア生成部１０４０は、公知または周知の公開鍵暗号（ＲＳＡ、ＤＳＡ、など）を用いて、秘密鍵と公開鍵のペアを生成する。

公開鍵証明書生成部１０５０は、鍵ペア生成部１０４０で生成された公開鍵に対して、生体情報取得部１０２０で取得した生体情報を鍵とする生体署名を付与することで公開鍵証明書を生成する。

記録情報取得部１０６０は、トランザクション内に書き込む記録情報を入力装置からの入力などから取得する。

ハッシュ値生成部１０６１は、記録情報取得部１０６０で取得した記録情報やその他の情報を所定のハッシュ関数へ入力することで、ハッシュ値を生成する。

署名生成部１０７０は、ハッシュ値生成部１０６１で生成されたハッシュ値に対して、秘密鍵を用いて署名値を生成する。

新トランザクション生成部は、公開鍵証明書生成部１０５０で生成された公開鍵証明書と、公開テンプレート証明書（後述）と、記録情報取得部１０６０で取得した記録情報と、ハッシュ値生成部１０６１で生成されたハッシュ値と、署名生成部１０７０で生成された署名などを含む新トランザクションを生成する。

公開鍵失効申請書生成部１０８０は、公開鍵証明書生成部１０５０で生成された公開鍵証明書から公開鍵失効申請書を生成する。

次に、検証端末１１００は、通信部１１１０と、公開鍵証明書検証部１１２０と、ハッシュ値生成部１１６１と、署名検証部１１４０を含んで構成される。

公開鍵証明書検証部１１２０は、署名端末１０００の公開鍵証明書生成部１０５０で生成された公開鍵証明書を公開テンプレートを用いて正当性を検証する。

署名検証部１１４０は、署名端末１０００の署名生成部１０７０で生成された署名値を公開鍵証明書を用いて正当性を検証する。

通信部１１１０は、ネットワーク１００を介して署名端末１０００と、公開テンプレートリポジトリ１２００の間で通信を行う。

次に、公開テンプレートリポジトリ１２００は、通信部１２１０と、公開テンプレート証明書生成部１２２０と、公開鍵失効申請書検証部１２３０と、証明書失効リスト生成部１２４０と、公開テンプレート証明書格納部１２９０と、証明書失効リスト格納部１２９１を含んで構成される。

公開テンプレート証明書生成部１２２０は、署名端末１０００の公開テンプレート生成部１０３０で生成された公開テンプレートから公開テンプレート証明書を生成する。

公開鍵失効申請書検証部１２３０は、署名端末１０００の公開鍵失効申請書生成部１０８０で生成された公開鍵失効申請書を、公開テンプレート証明書生成部１２２０で生成された公開テンプレート証明書で正当性を検証する。

証明書失効リスト生成部１２４０は、署名端末１０００の公開鍵失効申請書生成部１０８０で生成された公開鍵失効申請書に基づき、証明書失効リスト９３００（図９Ｄ）を生成する。

公開テンプレート証明書格納部１２９０は、公開テンプレート証明書生成部１２２０で生成された公開テンプレート証明書を格納する。

証明書失効リスト格納部１２９１は、証明書失効リスト生成部１２４０で生成された証明書失効リスト９３００を格納する。通信部１２１０は、ネットワーク１００を介して署名端末１０００と、検証端末１１００との間で通信を行う。

ユーザ端末１３００は、ユーザＢが利用する計算機で、署名端末１０００を利用するユーザＡがトランザクションを送信する送信先となる。ユーザ端末１３００は、署名端末１０００と同様の構成の計算機である。

本発明の実施例１の処理手順を、図２〜図１１を参照しながら説明する。

図２は、本発明の実施例１の、公開テンプレート証明書の初期登録の処理手順を示したフローチャートである。本処理は、署名端末１０００がユーザから生体情報を取得し、公開テンプレートリポジトリ１２００が公開テンプレート証明書を生成することで、その後ブロックチェーンシステムを利用可能とする処理である。以降、各手順を説明する。

署名端末１０００にて、初期登録を行う（Ｓ２０１０）。初期登録の具体的な手順は、図３を参照して後ほど説明する。この手順により、公開テンプレートを生成する。

署名端末１０００は、公開テンプレートを公開テンプレートリポジトリ１２００へ送信する（Ｓ２０２０）。この際、署名端末１０００は、ユーザ名や、公開テンプレートを生成するために用いた生体署名アルゴリズムなど、公開テンプレート証明書を生成するために必要となる情報も同時に送信する。なお、改ざん防止のため、それらの情報に対して生体署名を付与しても良い。

公開テンプレートリポジトリ１２００は、公開テンプレートを受信し（Ｓ２１１０）、受信した公開テンプレートに対するシリアル番号を発行する（Ｓ２１２０）。シリアル番号は公開テンプレートに対して一意に付与される番号であり、重複しないように公開テンプレートリポジトリ１２００にて管理される。

公開テンプレートリポジトリ１２００は、公開テンプレートに対して署名を付与し、公開テンプレート証明書を生成して登録する（Ｓ２１３０）。公開テンプレート証明書のデータ構造は、図９Ａを参照して後ほど説明する。本実施例１では、公開テンプレートリポジトリ１２００が信頼できる第三者機関として機能しており、不正は行われないことを仮定する。

このため、公開テンプレートに対する署名は、公開テンプレートリポジトリ１２００が保管する認証局の秘密鍵を用いて生成される。これにより、公開テンプレート証明書は認証局の秘密鍵を持たない第三者には生成困難となり、不正な公開テンプレート証明書が発行されてなりすましなどが発生することを防止することが可能となる。

公開テンプレートリポジトリ１２００は、ステップＳ２１３０で生成された公開テンプレート証明書を署名端末１０００に送信し（Ｓ２１４０）、署名端末１０００は公開テンプレート証明書を受信する（Ｓ２０３０）。

署名端末１０００は、ステップＳ２０３０で受信した公開テンプレート証明書を、公開テンプレート証明書格納部１０９２に格納する（Ｓ２０４０）。

以上により、公開テンプレート証明書の初期登録が完了する。

次に、図２のステップＳ２０１０で行われる初期登録処理の具体的な手順を、図３を参照して説明する。

署名端末１０００の生体情報取得部１０２０にて、ユーザの生体情報を取得する（Ｓ３０１０）。署名端末１０００には、指紋センサ、静脈センサ、カメラなどの生体センサが接続されており、これらのセンサを使って、生体情報取得部１０２０はユーザの指紋、静脈、顔画像などの生体情報を取得する。

公開テンプレート生成部１０３０は、ステップＳ３０１０で取得した生体情報に対して一方向性変換を施すことで、公開テンプレートを生成する（Ｓ３０２０）。この変換には、生体情報に含まれる誤差を補正して、一意のデータを生成し、得られたデータを鍵として暗号処理を行う、バイオメトリック暗号方式を採用する。この変換として用いることができる方式としては、例えばＦｕｚｚｙ Ｃｏｍｍｉｔｍｅｎｔ、Ｆｕｚｚｙ Ｖａｕｌｔや、特許文献１に開示されている生体署名などがある。以降では、特許文献１に開示されている生体署名を前提として説明する。

生体署名では、生体情報に対して一方向性変換を施すことで公開テンプレートを生成する。公開テンプレートを第三者が取得しても生体情報を復元することは非常に困難であり、公開鍵と同様に公開情報として扱うことができる。

署名端末１０００の鍵ペア生成部１０４０は、秘密鍵と公開鍵の鍵ペアを生成する（Ｓ３０３０）。この鍵ペアは、公知または周知のＲＳＡ暗号、ＤＳＡ暗号、Ｅｌｇａｍａｌ暗号などの公開鍵暗号に基づき生成される。

署名端末１０００の公開鍵証明書生成部１０５０は、ステップＳ３０３０で得られた公開鍵に対して、ステップＳ３０１０で取得した生体情報を鍵とする生体署名を付与することで、公開鍵証明書を生成する（Ｓ３０４０）。公開鍵証明書のデータ構造については、図９Ｂを参照して後ほど説明する。

署名端末１０００は、ステップＳ３０３０で生成した秘密鍵およびステップＳ３０４０で生成した公開鍵証明書を鍵格納部１０９１に格納する（Ｓ３０５０）。

以上により、鍵ペアと公開鍵証明書が生成されてステップＳ２０１０の初期登録処理が完了する。

図４は、図２に示す初期登録が完了した後実施される、ブロックチェーンシステムにおけるトランザクション生成と検証の手順を示した図である。本処理では、署名端末１０００において初期登録を終えた後、既存トランザクションに対して新たなトランザクションを生成し、検証端末１１００において新たなトランザクションの正当性を検証する。以降、図を参照して手順を説明する。

署名端末１０００にて、既存トランザクションを受信する（Ｓ４０１０）。既存トランザクションは、ブロックチェーンシステムにおいて過去に生成されたトランザクションであり、これから生成する新トランザクションの１つ前に位置するものである。

例えば、ブロックチェーンを使った仮想通貨の場合、既存トランザクションは他人から自分への送金を示すトランザクションであり、新トランザクションはその送金された仮想通貨を他人へ送金するトランザクションとなる。

既存トランザクションと新トランザクションのデータ構造については、図１０を参照して後ほど説明する。また、既存トランザクションはネットワーク（Ｐ２Ｐネットワーク）１００から通信部１０１０を介して取得する。なお、事前に既存トランザクションを収集しておき、署名端末１０００における記録装置から読み込むことで既存トランザクションを取得しても良い。

署名端末１０００は、ステップＳ４０１０で受信した既存トランザクションの次に繋がるトランザクションとして、新トランザクションを生成する（Ｓ４０１１）。新トランザクション生成の詳細な手順については、図５を参照して後ほど説明する。

署名端末１０００は、ステップＳ４０１０で受信した既存トランザクションとＳ４０１１で生成した新トランザクションを、通信部１０１０を用いて検証端末１１００へ送信する（Ｓ４０３０）。

検証端末１１００は、ステップＳ４０３０で送信された既存トランザクションと新トランザクションを、通信部１１１０を用いて受信する（Ｓ４２１０）。なお、図４では簡略化のため署名端末１０００と検証端末１１００が直接通信を行って必要なデータをやり取りしているが、実際のブロックチェーンシステムでは、署名端末１０００及び検証端末１１００は多数の端末が接続されたネットワーク１００に接続されており、データは他の端末を経由して送受信される。

検証端末１１００は、当該既存トランザクション内に含まれる公開テンプレート証明書を用いてトランザクションの正当性の検証を行う（Ｓ４２２０）。トランザクションの検証では、既存トランザクションと新トランザクションの内容に不整合が存在せず、かつ確かに正規のユーザが生成したものであることを判定する。トランザクション検証の詳細な手順は、図６を参照して後ほど説明する。

検証端末１１００は、トランザクションの検証結果によって条件分岐を行い（Ｓ４２３０）、当該検証結果が成功のときのみ新トランザクションを承認する（Ｓ４２４０）。トランザクションの承認は、検証端末１１００が当該新トランザクションは適切なものであることを認める処理であり、具体的な手順は対象とするブロックチェーンシステムにより異なる。例えば、ブロックチェーンを用いた仮想通貨の一つであるビットコインの場合は、承認した新トランザクションをまとめた上で、ヘッダを追加してブロックを生成する。

以上により、ブロックチェーンシステムにおけるトランザクション生成と検証が完了する。

図５は、本発明の実施例１の、新トランザクション生成（Ｓ４０２０）の処理手順を示すフローチャートである。以降、図を参照して手順を説明する。

署名端末１０００は、新トランザクションに含める記録情報（メッセージ）を取得する（Ｓ５０１０）。記録情報は、ブロックチェーンシステムの中で承認を得る対象の情報であり、例えば仮想通貨の場合はユーザ間の通貨の取引であり、スマートコントラクトの場合は契約内容となる。

署名端末１０００のハッシュ値生成部１０６１は、新トランザクションに含まれる情報のハッシュ値を生成する（Ｓ５０２０）。

次に、署名端末１０００の新トランザクション生成部１０７１は、署名を付与するため、鍵格納部１０９１に格納されている秘密鍵を活性化させる（Ｓ５０３０）。秘密鍵の活性化は、鍵格納部１０９１が署名端末１０００内の補助記憶装置であれば、当該補助記憶装置から主記憶装置へ秘密鍵データを読み出すことで行われる。その際、秘密鍵がパスワードで暗号化されている場合は、ユーザからパスワードを受け付け、復号した上で秘密鍵を取り出す。また、秘密鍵がＩＣカードなどのスマートデバイスの中に格納されている場合は、パスワードをスマートデバイスへ入力することで秘密鍵を活性化させる。

署名端末１０００の署名生成部１０７０は、ステップＳ５０２０で生成したハッシュ値に対して、ステップＳ５０３０で活性化した秘密鍵を用いて署名を付与する（Ｓ５０４０）。署名生成部１０７０は、ステップＳ５０３０で活性化した秘密鍵が署名端末１０００の主記憶装置に格納された場合は、当該秘密鍵を用いて主記憶装置上で署名処理を行う。なお、秘密鍵がスマートデバイス内に格納されている場合は、ハッシュ値をスマートデバイス内に入力した上で、スマートデバイス内で署名生成を行い、その署名値を取得する。

新トランザクション生成部１０７１は、ステップＳ５０１０で取得した記録情報と、ステップＳ５０４０で生成した署名と、公開テンプレート証明書と公開鍵証明書を含む新トランザクションを生成する（Ｓ５０５０）。新トランザクションのデータ構造は、図１０を参照して後ほど説明する。

以上の手順により、新トランザクションの生成が完了する。

図６は、トランザクション検証（Ｓ４２５０）の処理手順を示すフローチャートである。本処理は、検証端末１１００が新トランザクションを受け付けて、当該新トランザクションに含まれる公開テンプレート証明書と、公開鍵証明書と、署名値の正当性をそれぞれ検証し、全ての検証に成功したときのみ、新トランザクションの検証成功とする。以降、図を参照して説明する。

検証端末１１００は、新トランザクションに含まれる公開テンプレート証明書の正当性を検証する（Ｓ６０１０）。公開テンプレート証明書には、ステップＳ２１３０で認証局の秘密鍵で生成した署名値が付与されており、本手順では当該署名値を認証局の公開鍵を用いて検証する。これにより、検証端末１１００は、公開テンプレート証明書が確かに認証局によって発行されたものであることを検証できる。

検証端末１１００は、公開テンプレート証明書の検証結果が成功であれば次のステップＳ６０３０に進み、失敗であればトランザクション検証結果に失敗を代入する（Ｓ６０５１）。

検証端末１１００は、新トランザクションに含まれる公開鍵証明書を、既存トランザクションに含まれる公開テンプレート証明書を用いて正当性を検証する（Ｓ６０３０）。公開鍵証明書にはステップＳ３０４０にて生体情報を鍵とする生体署名が付与されている。この生体署名が、確かに本人が付与したものか否かを、公開テンプレート証明書を用いて正当性を検証する。

これにより、検証端末１１００は、既存トランザクションに含まれる公開テンプレート証明書を生成したユーザと、新トランザクションに含まれる公開鍵証明書を生成したユーザが同一であることが検証できる。既存トランザクションに含まれる公開テンプレート証明書を生成したユーザは、仮想通貨の場合通貨の送り先に対応し、新トランザクションに含まれる公開鍵証明書を生成したユーザは、仮想通貨の場合通貨の送り元に対応する。

すなわち、仮想通貨の場合、この検証は、送金したいユーザが確かに過去に送金を受けて通貨を保有していることを示している。さらに、ステップＳ６０３０では、公開鍵証明書が証明書失効リストに含まれていないことを検証する。

証明書失効リストは、秘密鍵の紛失、盗難、その他の事由で、秘密鍵に対応する公開鍵証明書を無効にし、署名検証に失敗するようにするための仕組みである。証明書失効リストの発行手順は図７、証明書失効リストのデータ構造は図９Ｄにて、後ほど示す。

具体的には、検証端末１１００が、公開テンプレート証明書に含まれるシリアル番号と証明書失効リストに含まれる公開テンプレートシリアル番号とを比較し、その後公開鍵証明書と証明書失効リストに含まれる公開鍵シリアル番号とを比較し、両者が一致していれば公開テンプレートを用いて生体署名値（９３６４）の正当性の検証を行い、さらに証明書失効リストの署名値（９３７０）の正当性を検証する。検証端末１１００は、全ての検証に成功した場合、公開鍵証明書が失効していると判定し、検証失敗とする。

検証端末１１００は、ステップＳ６０３０の検証結果に基づき条件分岐を行い（Ｓ６０４０）、当該検証に成功した場合は、ステップＳ６０５０以降の処理に進み、当該検証に失敗した場合は、トランザクション検証結果に失敗を代入する（Ｓ６０５１）。

検証端末１１００のハッシュ値生成部１１６１は、新トランザクション内のデータからハッシュ値を生成する（Ｓ６０５０）。

検証端末１１００の署名検証部１１４０は、ステップＳ６０５０で生成したハッシュ値と公開鍵証明書を用いて、署名の正当性を検証する（Ｓ６０６０）。署名は、署名端末１０００がステップＳ５０４０にて新トランザクションのハッシュ値に対して秘密鍵を用いて生成したものであるため、検証端末１１００では秘密鍵に対応する公開鍵にて正当性の検証を行うことができる。

検証端末１１００は、当該検証にて、秘密鍵を持つユーザが新トランザクションを生成したことを検証し、さらに、新トランザクションの内容に後から改ざんが加えられていないことを検証する。

検証端末１１００は、ステップＳ６０６０の検証結果に基づき条件分岐を行い（Ｓ６０７０）、当該検証に成功した場合は、トランザクション検証結果に成功を代入し（Ｓ６０８０）、当該検証に失敗した場合はトランザクション検証結果に失敗を代入する（Ｓ６０５１）。検証端末１１００は、トランザクション検証結果を署名端末１０００に通知することができる。

以上により、検証端末１１００は、トランザクションの内容を検証する処理が完了する。

図２〜図６では、公開テンプレート証明書の初期登録を行い、新トランザクションを生成し、当該トランザクションを検証するまでの流れを示した。本発明は、ユーザの秘密鍵の紛失や盗難時にも、安全かつ継続的にブロックチェーンシステムを利用できるようにすることを目的としている。このため、図２〜図６の通常の処理手順に加えて、秘密鍵の紛失または盗難時に、秘密鍵に対応する公開鍵証明書の失効や新たな公開鍵証明書の発行を行う。

図７は、公開鍵証明書を失効させる際の処理手順を示したフローチャートである。以降、図を参照して手順を説明する。

署名端末１０００は、公開鍵証明書を失効させるユーザの公開テンプレート証明書を取得する（Ｓ７０１０）。この処理は、署名端末１０００の公開テンプレート証明書格納部１０９２に公開テンプレート証明書が格納されている場合は、署名端末１０００が、そのデータを読み出すことに相当する。また、公開テンプレート証明書のシリアル番号を入力された場合、または公開テンプレート証明書のシリアル番号のみを補助記憶装置に格納していた場合は、署名端末１０００が、当該シリアル番号に基づき公開テンプレートリポジトリ１２００へ問い合わせを行い、公開テンプレート証明書を取得する。

失効する公開鍵証明書を署名端末１０００が鍵格納部１０９１から取得する（Ｓ７０２０）。

署名端末１０００の公開鍵失効申請書生成部１０８０は、ステップＳ７０１０で取得した公開テンプレート証明書およびステップＳ７０２０で取得した公開鍵証明書を用いて、公開鍵失効申請書を生成する（Ｓ７０３０）。公開鍵失効申請書のデータ構造は、図９Ｃを用いて後ほど説明する。

署名端末１０００は、ステップＳ７０３０で生成した公開鍵失効申請書を公開テンプレートリポジトリ１２００へ送信する（Ｓ７０４０）。また、署名端末１０００は、トランザクションの送受信を行うユーザ端末１３００にも公開鍵失効申請書を送信しておく。これにより、公開テンプレートリポジトリ１２００やユーザ端末１３００は、署名端末１０００の現在の公開鍵証明書が失効したことを検証することができる。

公開テンプレートリポジトリ１２００は、公開鍵失効申請書を受信し（Ｓ７１１０）、公開鍵失効申請書検証部１２３０が当該公開鍵失効申請書を検証する（Ｓ７１２０）。この検証では、公開鍵失効申請書検証部１２３０が公開鍵失効申請書に付与された署名値が正しいことを、公開テンプレート証明書を用いて検証する。

具体的には、公開鍵失効申請書検証部１２３０が公開鍵失効申請書に含まれる公開テンプレートシリアル番号を用いてユーザに対応する公開テンプレート証明書を取得する。さらに、公開鍵失効申請書検証部１２３０は、当該公開テンプレート証明書を用いて、公開鍵失効申請書に含まれる署名値の正当性を検証する。

公開鍵失効申請書検証部１２３０は、ステップＳ７１２０の検証結果に基づき条件分岐を行い（Ｓ７１３０）、検証に成功した場合には証明書失効リスト生成部１２４０が証明書失効リスト９３００を生成し、証明書失効リスト格納部１２９１に格納する（Ｓ７１４０）。証明書失効リストのデータ構造は、図９Ｄを参照して後ほど説明する。

以上により、公開鍵証明書の失効が完了する。公開テンプレートリポジトリ１２００が発行した証明書失効リストは、図６のステップＳ６０３０の公開鍵証明書検証にて検証に用いられ、公開鍵証明書が証明書失効リストに存在する場合は、検証に失敗する。これにより、秘密鍵の紛失、盗難、その他の理由で公開鍵証明書を失効させると、図４に示したステップＳ４２２０のトランザクション検証に失敗するため、トランザクションが承認されなくなる。これにより、第三者が秘密鍵を取得した場合でも、なりすましを行って不正にトランザクションを承認させることができなくなる。

図８は、本発明の実施例１の、公開鍵証明書を再発行する際の処理手順を示したフローチャートである。本処理では、図７で示した公開鍵証明書の失効（公開鍵失効申請書の生成）を行った後、署名端末１０００が新たに用いる新たな公開鍵証明書を生成する。なお、図７で示した公開鍵証明書の失効を行わなくても、公開鍵証明書の有効期限を迎えることで自動的に失効する場合もある。このような場合は、図７で示した公開鍵証明書の失効を行わずに、図８に示した公開鍵証明書の再発行を行うこともできる。また、公開鍵証明書が失効していない時点で図８に示した公開鍵証明書の再発行を行うこともできる。これは、異なる複数の公開鍵証明書を発行して、公開鍵に対応する秘密鍵を同一ユーザの複数の端末に格納する場合や、異なるユーザへ貸与する場合に行う。以降、図８を参照して説明する。

署名端末１０００は、公開テンプレート証明書を取得する（Ｓ８０１０）。この処理では、図７のステップＳ７０１０と同様に、署名端末１０００が公開テンプレート証明書格納部１０９２、または公開テンプレートリポジトリ１２００から公開テンプレート証明書を取得する。

署名端末１０００は、ユーザの生体情報を取得する（Ｓ８０２０）。この処理では、図３のステップＳ３０１０と同様に、生体情報取得部１０２０が生体センサによりユーザの指紋、静脈、顔画像などの生体情報を取得する。

署名端末１０００は、ステップＳ８０１０で取得した公開テンプレート証明書を用いて、ステップＳ８０２０で取得した生体情報の正当性を検証する（Ｓ８０３０）。当該検証では、署名端末１０００が、生体署名を用いて、公開テンプレート証明書を生成した際に元にした生体情報と、ステップＳ８０２０で取得した生体情報とが同一人物から取得したものであるかを検証し、同一人物の場合は検証成功とし、異なる人物の場合は検証失敗とする。

署名端末１０００は、ステップＳ８０３０の検証結果に基づき条件分岐を行い（Ｓ８０４０）、成功した場合はステップＳ８０５０以降の処理を行い、失敗した場合は再発行結果に「発行失敗」を代入し（Ｓ８０５１）、当該再発行結果を署名端末１０００の出力装置に表示する（Ｓ８０９０）。

ステップＳ８０４０の検証に成功した場合、署名端末１０００の鍵ペア生成部１０４０は、新秘密鍵と新公開鍵の新鍵ペアを生成する（Ｓ８０５０）。この処理はＳ３０３０と同様に、公知または周知の公開鍵暗号に基づき生成される。

署名端末１０００の公開鍵証明書生成部１０５０は、ステップＳ８０５０で生成した新公開鍵に基づき、新公開鍵証明書を生成する（Ｓ８０６０）。この処理では、図３のステップＳ３０４０と同様に、署名端末１０００が新公開鍵に対してステップＳ８０２０で取得した生体情報を鍵とする生体署名を付与する。

署名端末１０００は、ステップＳ８０５０で生成した新秘密鍵及び新公開鍵証明書を、鍵格納部１０９１に格納する（Ｓ８０７０）。また、署名端末１０００は、トランザクションの送受信を行うユーザ端末１３００に新公開鍵証明書を送信しておく。

署名端末１０００は、公開鍵証明書の再発行結果に「発行成功」を代入し（Ｓ８０８０）、再発行結果を署名端末１０００に表示する（Ｓ８０９０）。

以上により、公開鍵証明書の再発行（更新）が完了する。この処理により、署名端末１０００の鍵格納部１０９１内の秘密鍵及び公開鍵証明書がアップデートされ、以降の署名生成及び署名検証では新秘密鍵と新公開鍵証明書が用いられる。

この新秘密鍵を用いて生成したトランザクションは、新公開鍵証明書で正当性を検証することができる。このため、本実施例１では秘密鍵の紛失や漏洩時にも、新たに秘密鍵を発行して継続的にブロックチェーンシステムを利用することが可能となる。

上記処理により、署名端末１０００の公開鍵証明書生成部１０５０は、公開鍵失効申請書を生成した後に、鍵ペアを再発行するユーザの公開テンプレート証明書を公開テンプレート証明書格納部１０９２から取得する。そして、当該ユーザの生体情報を取得して、公開テンプレート証明書に含まれる公開テンプレート９０８０と生体情報の検証に成功すれば、鍵ペアと公開鍵証明書を再発行することで、当該ユーザはブロックチェーンシステムの利用を継続することができる。

図９Ａ〜図９Ｄは、公開テンプレート証明書、公開鍵証明書、公開鍵失効申請書、証明書失効リスト、それぞれのデータ構造を示した図である。

図９Ａは、公開テンプレート証明書９０００の一例を示す図である。公開テンプレート証明書９０００は、図２のステップＳ２１３０で生成されるデータである。基本的なデータ構造は、公開テンプレート９０８０に対してその他のヘッダ情報を付与して、署名値９０９１を付与したものであり、ＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）における公開鍵証明書の規格であるＸ．５０９に準拠している。以降、それぞれのデータについて説明する。

バージョン９０１０は公開テンプレート証明書のバージョンを文字列で示す。

公開テンプレートシリアル番号９０２０は、公開テンプレートリポジトリ１２００が公開テンプレートに対して一意に割り振る文字列であり、重複しないように付与される。

署名アルゴリズム９０３０は、公開テンプレート証明書に対して付与する署名値（９０９１）を生成するアルゴリズムを示す。

発行者９０４０は、公開テンプレート証明書を発行する主体、つまり認証局を示す。

有効期限９０５０は、公開テンプレート証明書の有効期限の日時を示す。

サブジェクト９０６０は、公開テンプレート証明書の主体者、つまり発行を依頼するユーザを示している。

生体署名アルゴリズム９０７０は、公開テンプレート９０８０を生成するアルゴリズムを示す。

公開テンプレート９０８０は、図３のステップＳ３０２０にて生成された公開テンプレートを示す。

署名アルゴリズム９０９０は、署名アルゴリズム９０３０と同じく、公開テンプレート証明書に対して付与する署名値（９０９１）を生成するアルゴリズムを示す。

署名値９０９１は、９０１０〜９０８０までのデータをハッシュ関数（例えば、ＳＨＡ１、ＳＨＡ２５６など）へ入力し、得られたハッシュ値を認証局の秘密鍵で変換して得られる値である。

以上が公開テンプレート証明書のデータ構造である。

図９Ｂは、公開鍵証明書のデータ構造の一例を示す図である。

公開鍵証明書９１００は、ステップＳ３０４０またはＳ８０６０で生成する、公開鍵に対して生体情報を鍵とする生体署名を付与したデータであり、ＰＫＩ（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）における公開鍵証明書の規格であるＸ．５０９に準拠している。以降、図を参照して説明する。

バージョン９１１０は公開テンプレート証明書のバージョンを表す文字列を示す。

公開テンプレートシリアル番号９１２０は、公開テンプレートリポジトリ１２００が公開テンプレートに対して一意に割り振るシリアル番号であり、重複しないように付与される。

公開鍵シリアル番号９１２１は、公開鍵に対して署名端末１０００の鍵ペア生成部１０４０が付与する一意の文字列であり、異なる公開鍵で重複しないように生成される。

生体署名アルゴリズム９１３０は、生体署名値９１９１を生成するアルゴリズムを示す。

発行者９１４０は、公開テンプレート証明書を発行する主体、つまり認証局を示す。

有効期限９１５０は、公開テンプレート証明書の有効期限の日時を示す。

サブジェクト９１６０は、公開テンプレート証明書の主体者、つまり発行を依頼するユーザを示している。

公開鍵アルゴリズム９１７０は、公開鍵９１８０を生成するアルゴリズムを示す。

公開鍵９１８０は、ステップＳ３０３０やＳ８０５０で生成する公開鍵を示す。

生体署名アルゴリズム９１９０は、上記９１３０と同じく、生体署名値９１９１を生成するアルゴリズムを示す。

生体署名値９１９１は、上記９１１０〜９１８０までのデータをハッシュ関数（例えば、ＳＨＡ１、ＳＨＡ２５６など）へ入力し、得られたハッシュ値に対して、生体情報を鍵とする生体署名を生成することで得られる値である。

以上が公開鍵証明書のデータ構造である。

図９Ｃは、公開鍵失効申請書のデータ構造の一例を示す図である。

公開鍵失効申請書９２００は、署名端末１０００の公開鍵失効申請書生成部１０８０にてステップＳ７０３０で生成されるものであり、公開テンプレートシリアル番号９２１０、公開鍵シリアル番号９２２０、失効日時９２３０に対して、生体情報を鍵とする生体署名を付与したデータである。

公開テンプレートシリアル番号９２１０、公開鍵シリアル番号９２２０は、それぞれ公開鍵証明書９１００の公開テンプレートシリアル番号９１２０と、公開鍵シリアル番号９１２１からコピーしたデータである。なお、公開テンプレートシリアル番号９２１０及び公開鍵シリアル番号９２２０は、公開鍵証明書９１００を特定する識別子として使用する。

失効日時９２３０は、公開鍵証明書を失効させる日時を記載しており、この日時以降、公開鍵証明書を用いた検証には失敗するようになる。

生体署名値９２４０は、上記９２１０〜９２３０のデータをハッシュ関数（例えば、ＳＨＡ１、ＳＨＡ２５６など）へ入力し、ハッシュ値を取得し、当該ハッシュ値に対して生体情報を鍵とする生体署名を生成することで得られる。

以上が公開鍵失効申請書のデータ構造である。

図９Ｄは、証明書失効リストのデータ構造の一例を示す図である。

証明書失効リスト９３００は、公開テンプレートリポジトリ１２００にてステップＳ７１４０で生成されるものであり、公開鍵失効申請書を１つまたは複数含み、ヘッダ及び署名値を付与したデータである。以降で図を参照して説明する。

バージョン９３１０は、証明書失効リストのバージョンを表す文字列を示す。

署名アルゴリズム９３２０は、証明書失効リストに対して付与される署名値９３８０の生成に用いる署名アルゴリズムを示す。

発行者９３３０は、証明書失効リストを発行する主体を示す文字列を示す。

今回の更新日時９３４０は、対象の証明書失効リストを発行した日時を示す。

次回の更新日時９３５０は、次に証明書失効リストが発行される日時を示す。

９３６１〜９３６４は、公開鍵失効申請書の９２１０〜９２４０に対応する。証明書失効リストでは、一定期間に受理した公開鍵失効申請書をまとめて、証明書失効リストに含める。

署名アルゴリズム９３７０は、上記９３２０と同様に、証明書失効リストに対する署名値９３８０を生成するために用いる署名アルゴリズムを示す。

署名値９３８０は、９３１０〜９３６４のデータをハッシュ関数（例えば、ＳＨＡ１、ＳＨＡ２５６など）に入力し、得られたハッシュ値に対して公開テンプレートリポジトリ１２００が保持する認証局の秘密鍵で署名を付与したものである。

以上が、証明書失効リストのデータ構造である。

図１０は、本実施例１が対象とするブロックチェーンのデータ構造を示した図である。図１０には既存トランザクション１００１０及び新トランザクション１０１１０が含まれる。

既存トランザクション１００１０は、ステップＳ４０１０にて受信するトランザクションであり、新トランザクション１０１１０は、ステップＳ５０５０にて生成するトランザクションである。以降、図を参照して各データについて説明する。

既存トランザクション１００１０は、ユーザＡからユーザＢに対する取引情報を記録したトランザクションであり、ユーザＡ（取引元）の公開鍵証明書１００２０と、ユーザＢ（取引先）の公開テンプレート証明書１００３０と、記録情報１００４０と、生成日時１００５０と、ハッシュ値１００６０と、ユーザＡの署名１００７０を含んで構成される。例えば、ブロックチェーンに基づく仮想通貨の場合、ユーザＡは送金元、ユーザＢは送金先に相当する。

ユーザＡの公開鍵証明書１００２０は、ステップＳ３０４０またはステップＳ８０６０で生成される公開鍵証明書である。なお、上記１００２０には公開鍵証明書をそのまま格納しても良いが、公開鍵証明書を何らかの規則性に従って変換したデータを入れ、公開鍵証明書を使うときに復元しても良い。また、１００２０に公開鍵証明書のシリアル番号のみを格納し、公開鍵証明書を使うときにはシリアル番号を使って公開鍵証明書を取得しても良い。

ユーザＢの公開テンプレート証明書１００３０は、ステップＳ２１３０で生成される公開テンプレート証明書である。なお、当該公開テンプレート証明書は、ユーザＡの公開鍵証明書１００２０と同様に、変換したデータやシリアル番号を格納しても良い。

記録情報１００４０は、ブロックチェーンシステムにより内容を保証する対象であり、例えば仮想通貨の場合は送金額、スマートコントラクトの場合は契約内容などが含まれる。

生成日時１００５０は、既存トランザクション１００１０を生成した日時を示す。

ハッシュ値１００６０は、既存トランザクションの前のトランザクション全体をハッシュ関数へ入力することで得られるハッシュ値である。

ユーザＡの署名１００７０は、既存トランザクションの内容（１００２０〜１００５０）と、ハッシュ値１００６０をハッシュ関数に入力して総合ハッシュ値を算出し、当該総合ハッシュ値に対して、ユーザＡの秘密鍵で署名を生成したものである。

新トランザクション１０１１０は、既存トランザクション１００１０の次に生成したトランザクションであり、ユーザＢからユーザＣへの取引を示す。

新トランザクション１０１１０に含まれる、ユーザＢの公開鍵証明書１０１２０と、ユーザＣの公開テンプレート証明書１０１３０と、記録情報１０１４０と、生成日時１０１５０と、前のトランザクションのハッシュ値１０１６０と、ユーザＢの署名１０１７０は、それぞれ既存トランザクション１００１０におけるユーザＡの公開鍵証明書１００２０、ユーザＢの公開テンプレート証明書１００３０、記録情報１００４０、生成日時１００５０、ハッシュ値１００６０、ユーザＡの署名１００７０と同様である。

新トランザクション１０１１０は、ステップＳ５０５０で生成された後、ステップＳ４２２０で検証される。新トランザクション検証時には、まず、検証端末１１００は、ユーザＣの公開テンプレート証明書１０１３０を認証局の公開鍵を用いて正当性を検証し、その後ユーザＢの公開テンプレート証明書１００３０を用いてユーザＢの公開鍵証明書１０１２０の正当性を検証し、その後ユーザＢの公開鍵証明書１０１２０を用いてユーザＢの署名１０１７０の正当性を検証する。この全ての検証に成功したとき、検証端末１１００はトランザクションを承認する。

公知のブロックチェーンシステムでは、既存トランザクションにユーザＢの公開鍵を格納し、新トランザクションにユーザＢの署名を格納した上で、それらを検証する。このため、既存トランザクションが生成された後、ユーザＢが自らの秘密鍵を紛失した場合、新トランザクションに署名を打つことができず、継続的にトランザクションを生成することができなかった。

本実施例１では、既存トランザクション１００１０にユーザＢの公開テンプレート証明書１００３０を格納し、新トランザクション１０１１０にユーザＢの公開鍵証明書１０１２０とユーザＢの署名１０１７０を格納した上で、それらを検証する。本実施例１におけるトランザクションの正当性の検証は、公開テンプレート証明書と公開鍵証明書、及び公開鍵証明書と署名、というように、２段階で構成されている。

このような２段階の検証手順を採用することで、ユーザＢは秘密鍵を紛失した場合でも、ユーザＢの生体情報を鍵として用いることで、公開鍵証明書を再発行することができる。生体情報はユーザＢの体内にある特徴であるため、通常の秘密鍵のように容易に紛失や漏洩が発生しにくい。

このため、ユーザＢは秘密鍵の紛失や漏洩により新たなトランザクションを生成できなくなるリスクを低減することが可能となる。また、通常時は秘密鍵のみを保持しておけば、公知のブロックチェーンシステムと同様にトランザクションを生成できるため、生体情報を利用しても前記従来例のようにユーザＢの利便性が低下することもない。

図１１は、ブロックチェーンシステムにおける、署名端末１０００及び公開テンプレートリポジトリ１２００、検証端末１１００のハードウェア構成を示すブロック図である。

この図において、符号１０はＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、符号２０は主記憶装置、符号３０は補助記憶装置、符号４０は入力装置、符号５０は出力装置、符号６０は通信装置である。

ＣＰＵ１０は、公開テンプレート生成部１０３０、鍵ペア生成部１０４０、公開鍵証明書生成部１０５０、ハッシュ値生成部１０６１、署名生成部１０７０、新トランザクション生成部１０７１、公開鍵失効申請書生成部１０８０、公開鍵証明書検証部１１２０、署名検証部１１４０、公開テンプレート証明書生成部１２２０、公開鍵失効申請書検証部１２３０、証明書失効リスト生成部１２４０に対応するプログラムを実行する。

主記憶装置２０は、コンピュータのメモリに相当する装置であり、公開テンプレート生成部１０３０、鍵ペア生成部１０４０、公開鍵証明書生成部１０５０、ハッシュ値生成部１０６１、署名生成部１０７０、新トランザクション生成部１０７１、公開鍵失効申請書生成部１０８０、公開鍵証明書検証部１１２０、署名検証部１１４０、公開テンプレート証明書生成部１２２０、公開鍵失効申請書検証部１２３０、証明書失効リスト生成部１２４０に対応するプログラムを格納する。これらのプログラムをＣＰＵ１０で実行することで、各々の処理が実現する。

補助記憶装置３０は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などに代表される記憶装置であり、鍵格納部１０９１、公開テンプレート証明書格納部１０９２、公開テンプレート証明書格納部１２９０、証明書失効リスト格納部１２９１に相当する。各部が格納するデータは、補助記憶装置１１０３０上のデータとして蓄積される。

入力装置４０は、センサやマウスキーボードなどを含む。出力装置５０は、主記憶装置１１０２０上の情報を出力するディスプレイなどを含む。通信装置６０は、署名端末１０００、公開テンプレートリポジトリ１２００、検証端末１１００がネットワーク１００と通信する際に使用される。

ＣＰＵ１０は、各機能部のプログラムに従って処理することによって、所定の機能を提供する機能部として稼働する。例えば、ＣＰＵ１０は、公開テンプレート生成プログラムに従って処理することで公開テンプレート生成部１０３０として機能する。他のプログラムについても同様である。さらに、ＣＰＵ１０は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

各機能を実現するプログラム、テーブル等の情報は、補助記憶装置３０不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

以上、実施例１によれば、ユーザの生体情報から公開テンプレート証明書を生成し、秘密鍵と公開鍵のペアを生成し、ユーザの生体情報を鍵として公開鍵へ生体署名を付与することで公開鍵証明書を生成し、ユーザの署名生成時に、秘密鍵を使ってメッセージに対して署名を付与し、署名検証時に、公開テンプレート証明書で公開鍵証明書の正当性を検証し、さらに公開鍵証明書でユーザの署名の正当性を検証し、鍵更新時に、再度秘密鍵と公開鍵のペアを生成し、生体情報を鍵として公開鍵へ署名を付与することで公開鍵証明書を再発行することが可能となる。

また、トランザクション内に取引元の公開鍵証明書と、取引先の公開テンプレート証明書を含み、署名検証時には、既存（第１の）トランザクション１００１０の公開テンプレート証明書１００３０を用いて新（第２の）トランザクション１０１１０の公開鍵証明書１０１２０の正当性を検証し、その後、新トランザクション１０１１０に含まれる公開鍵証明書１０１２０を用いて、新トランザクション１０１１０に含まれるユーザ署名１０１７０の正当性を検証することで、ブロックチェーンシステムを構築できる。

さらに、公開テンプレート証明書に対して認証局の秘密鍵による署名を付与し、署名検証時には、認証局の秘密鍵に対応する認証局の公開鍵で正当性を検証することが可能となる。

第２の実施例は、ブロックチェーンシステムのユーザが自らの秘密鍵の紛失または漏洩時に、署名端末１０００で秘密鍵を失効させて新たな秘密鍵を再発行して、継続的にブロックチェーンシステムを利用することを可能とするシステムを、公開テンプレートリポジトリ１２００を利用せずに構成するものである。

前記実施例１では、公開テンプレートリポジトリ１２００を信頼できる第三者機関としておき、公開テンプレートリポジトリ１２００を介して公開テンプレート証明書や証明書失効リストの発行を行った。

このようなブロックチェーンシステムは、公開テンプレートリポジトリ１２００が認証局として機能することで、信頼性の高い公開テンプレート証明書や証明書失効リストを発行することができた。しかしながら、ブロックチェーンシステムは信頼できる第三者機関を置かずに低コストでトランザクションの管理を実現することも望まれており、運用に一定のコストを要する認証局の構築を行った場合、ブロックチェーンシステムの運用コストは増大する。

そこで本実施例２では、公開テンプレートリポジトリ１２００を利用せずに、前記実施例１と同様に秘密鍵の紛失または漏洩時に、秘密鍵を失効させて新たな秘密鍵を再発行し、継続的にトランザクション生成を可能とする。本実施例２は、前記実施例１の図２、図６、図７の処理と、図９Ａ〜図９Ｃのデータを変更し、図１の公開テンプレートリポジトリ１２００と図９Ｄの証明書失効リストを削除した。その他の構成は前記実施例１と同様である。以下、前記実施例１との差分について説明する。

図１２は、実施例２のブロックチェーンシステムの一例を示すブロック図である。図１２のブロックチェーンシステムにおいて、前記実施例１の公開テンプレートリポジトリ１２００で稼働していた公開テンプレート証明書生成部を署名端末１０００で稼働させ、公開鍵失効申請書９２００を署名端末１０００で保持する点が前記実施例１と相違する。

図１３は、実施例２の公開テンプレート証明書の初期登録の処理の一例を示すフローチャートである。本実施例２では、前記実施例１の図２の処理から公開テンプレートリポジトリ１２００の処理を削除し、署名端末１０００で公開テンプレート証明書の生成処理を実行する。

ステップＳ２０１０では、前記実施例１と同様に署名端末１０００が初期登録を行う。次に、公開テンプレート証明書生成部１０９０がステップＳ２０３５で公開テンプレート証明書を生成する。この処理は、公開テンプレート証明書生成部１０９０が公開テンプレートに対して署名を付与して公開テンプレート証明書を生成する。そして、ステップＳ２０４０では、公開テンプレート証明書生成部１０９０が公開テンプレート証明書を公開テンプレート証明書格納部１０９２へ登録する。

図１５は、実施例２の公開テンプレート証明書９０００の一例を示す図である。実施例２の公開テンプレート証明書９０００は、前記実施例１の図９Ａの公開テンプレートシリアル番号９０２０を削除したものである。

発行者９０４０は、公開テンプレート証明書を発行する主体として、前記実施例１の認証局に代わって署名端末１０００の識別子を格納する。また、公開テンプレート証明書の署名値９０９１は、認証局の署名に替わり、ユーザの生体情報（公開テンプレート）を鍵とする生体署名とする。このように公開テンプレート証明書に対して自己の生体署名を付与することで、第三者の改ざんを検知できるようになる。

また、前記実施例１の図６に示したトランザクション検証（Ｓ４２２０）では、公開テンプレート証明書検証Ｓ６０１０において、署名値９０９１を認証局の公開鍵を用いて検証した。本実施例２では、署名値９０９１を、公開テンプレート９０８０を用いて正当性を検証する。これにより、公開テンプレート証明書が改ざんされていないことが検証できる。本実施例２におけるＳ６０２０以降の処理は、実施例１と同様である。

図１４は、実施例２の公開鍵証明書を失効させ処理の一例を示すフローチャートである。前記実施例１の図７では、公開テンプレートリポジトリ１２００において公開鍵失効申請書の正当性の検証（Ｓ７１２０）を行い、検証に成功したときに証明書失効リストを発行した（Ｓ７１４０）。

本実施例２では、公開テンプレートリポジトリ１２００を削除したので、署名端末１０００がステップＳ７０５０にて公開鍵失効申請書を生成する。検証端末１１００は、生成した公開鍵失効申請書を格納しておき、トランザクションの検証時に活用する。

図１６は、実施例２の公開鍵証明書９１００を示す図である。

本実施例２では、前記実施例１の図９Ｂに示した公開鍵証明書９１００の公開テンプレートシリアル番号９１２０を公開テンプレート証明書に含めず、代わりに公開テンプレート９１２０Ａに公開テンプレート９０８０そのもの、または公開テンプレートのハッシュ値を格納する。その他の構成は前記実施例１と同様である。

図１７は、実施例２の公開鍵失効申請書９２００を示す図である。

本実施例２では、前記実施例１の図９Ｃに示した公開鍵失効申請書９２００の公開テンプレートシリアル番号９２１０を公開失効申請書に含めず、代わりに公開テンプレート９２１０Ａに公開テンプレート９０８０そのもの、または公開テンプレートのハッシュ値を格納する。その他の構成は前記実施例１と同様である。

また、本実施例２では、前記実施例１の図９Ｄに示した証明書失効リスト９３００を発行しない。

以上のように処理の手順を変更することで、本実施例２では公開テンプレートリポジトリ１２００を利用せずに、秘密鍵の紛失や漏洩時にも継続的に利用できるブロックチェーンシステムを実現する。

実施例２によれば、公開テンプレートを用いて公開テンプレート証明書に含まれる生体署名の正当性を検証することで、認証局を使用しないブロックチェーンシステムでもユーザの生体情報によって各証明書の正当性を検証することができ、認証局に要するコストを削減することが可能となる。

第３の実施例は、前記実施例１のブロックチェーンシステムに生体情報を取得して鍵ペアと公開テンプレートを生成する登録端末を加えたブロックチェーンシステムを示す。図１８は、実施例３のブロックチェーンシステムの一示すブロック図である。

ブロックチェーンシステムは、ユーザＡ〜Ｃの鍵と公開テンプレート証明書を登録する登録端末１４００と、トランザクションの正当性を検証する検証端末１１００と、公開テンプレート証明書を生成する公開テンプレートリポジトリ１２００と、トランザクションを生成するユーザ端末１３００−Ａ〜１３００−Ｃがネットワーク１００を介して接続される。

検証端末１１００と公開テンプレートリポジトリ１２００は、前記実施例１と同様である。ユーザ端末１３００−Ａ〜１３００−Ｃは、前記実施例１の署名端末１０００と同様であり、ユーザ端末の全体を符号１３００で表す。

登録端末１４００は、前記実施例１の署名端末１０００からトランザクションを生成するための機能部を省略したもので、図１に示した記録情報取得部１０６０、署名生成部１０７０、ハッシュ値生成部１０６１、新トランザクション生成部１０７１を省略した。その他の構成は前記実施例１と同様である。

本実施例３のブロックチェーンシステムでは、ブロックチェーンシステムのユーザＡ〜Ｃは、まず、登録端末１４００で生体情報を取得して公開テンプレート証明書と鍵を登録する。次に、登録端末１４００から各ユーザＡ〜Ｃが使用するユーザ端末１３００−Ａ〜１３００−Ｃに各自の鍵と各証明書を送信して格納する。その後、各ユーザは公開鍵などの送受信を行ってからトランザクションの送信を行う。なお、鍵ペアと証明書の送信は、オフラインで行うようにしても良い。また、前記実施例１と同様に、公開鍵証明書をユーザ端末１３００で生成するようにしてもよい。

図１９は、ブロックチェーンシステムで行われる登録処理の一例を示すシーケンス図である。この処理は、前記実施例１の図２、図３と同様で、ユーザがブロックチェーンシステムを利用する初回に行う登録処理である。以下ではユーザＡの登録処理の一例を示す。

まず、登録端末１４００では生体情報取得部１０２０が、ユーザＡの生体情報を取得する（Ｓ３０１）。

公開テンプレート生成部１０３０は、ステップＳ３０１で取得した生体情報に対して一方向性変換を施すことで、公開テンプレートを生成する（Ｓ３０２）。公開テンプレート生成部１０３０は、生成した公開テンプレートを公開テンプレートリポジトリ１２００へ送信する（Ｓ３０３）。

登録端末１４００の鍵ペア生成部１０４０は、秘密鍵と公開鍵の鍵ペアを生成する（Ｓ３０４）。

登録端末１４００の公開鍵証明書生成部１０５０は、生成した公開鍵に対して、ステップＳ３０１で取得した生体情報を鍵とする生体署名を付与することで、公開鍵証明書を生成する（Ｓ３０５）。

登録端末１４００は、秘密鍵、公開鍵および公開鍵証明書を鍵格納部１０９１に格納する（Ｓ３０６）。

次に、公開テンプレートリポジトリ１２００では、公開テンプレート証明書生成部１２２０は受信した公開テンプレートに署名を付与して公開テンプレート証明書を生成する（Ｓ３０９）。本実施例３は前記実施例１と同様に認証局の秘密鍵を用いて署名する。

公開テンプレートリポジトリ１２００は、生成した公開テンプレート証明書を公開テンプレート証明書格納部１２９０へ登録し（Ｓ３１０）、さらに、公開テンプレート証明書を登録端末１４００に送信する（Ｓ３１１）。登録端末１４００は、公開テンプレート証明書を受信すると、公開テンプレート証明書格納部１０９２へ登録する（Ｓ３０７）。

次に、登録端末１４００は、ユーザＡが利用するユーザ端末１３００−Ａに、鍵ペアと公開鍵証明書と公開テンプレート証明書を送信する（Ｓ３０８）。ユーザ端末１３００−Ａは、受信した鍵ペアと公開鍵証明書を鍵格納部１０９１へ登録し、公開テンプレート証明書を公開テンプレート証明書格納部１０９２へ登録する（Ｓ３１２）。

次に、ユーザ端末１３００−Ａは、トランザクションを送信するユーザ端末１３００−Ｂ等へ公開鍵と公開テンプレートを送信する（Ｓ３１３）。ユーザ端末１３００−Ａは、受信した公開鍵と公開テンプレートを格納へ登録する（Ｓ３１４）。

以上により、鍵ペアと公開鍵証明書が生成されて登録処理が完了し、トランザクションを送受する準備が完了する。

図２０は、ブロックチェーンシステムで行われるトランザクションの検証処理の一例を示すシーケンス図である。この処理は、前記実施例１の図４〜図６と同様であり、図２０では、ユーザＢが送信した既存トランザクションをユーザＡが受信し、ユーザＡが新たなトランザクションを生成してユーザＣに送信する際に検証を行う例を示す。

まず、ユーザ端末１３００−Ｂが既存トランザクションを送信し、ユーザ端末１３００−Ａが受信する（Ｓ４０１）。なお、トランザクションの送信は、ブロックチェーンシステム内でブロードキャストし、公開鍵や公開テンプレートの送信にはＰ２Ｐネットワークを利用する。

ユーザ端末１３００−Ａは、既存トランザクションにユーザＡの署名を加えて新たなトランザクションを生成し（Ｓ４０２）、ユーザ端末１３００−Ｃを宛て先としてブロードキャストする（Ｓ４０３）。検証端末１１００は、ブロードキャストされた新トランザクションを受信して検証を開始する。

検証端末１１００は、新トランザクションに含まれる公開テンプレート証明書の正当性を検証する（Ｓ４０４）。公開テンプレート証明書には、認証局の秘密鍵で生成した署名値が付与されており、検証端末１１００では当該署名値を認証局の公開鍵を用いて正当性を検証する。これにより、検証端末１１００は、公開テンプレート証明書が確かに認証局によって発行されたものであることを検証できる。

次に、検証端末１１００は、新トランザクションに含まれる公開鍵証明書を、既存トランザクションに含まれる公開テンプレート証明書を用いて正当性を検証する（Ｓ４０５）。公開鍵証明書には生体情報を鍵とする生体署名が付与されている。この生体署名が、確かに本人が付与したものか否かを、公開テンプレート証明書を用いて正当性を検証する。

これにより、検証端末１１００は、既存トランザクションに含まれる公開テンプレート証明書を生成したユーザと、新トランザクションに含まれる公開鍵証明書を生成したユーザが同一であることが検証できる。さらに、ステップＳ４０５では、公開鍵証明書が証明書失効リスト９３００に含まれていないことを検証する。

次に、検証端末１１００では、署名の正当性の検証を行う（Ｓ４０６）。この処理は、前記実施例１に示した図６のステップＳ６０５０〜６０７０と同様であり、検証端末１１００はハッシュ値を生成して、生成したハッシュ値と公開鍵証明書を用いて、署名の正当性を検証する。

検証端末１１００は、公開テンプレート証明書と公開鍵証明書及び署名の検証結果をユーザ端末１３００−Ａ、１３００−Ｃに通知する。

以上により、検証端末１１００は、トランザクションの内容を検証することができる。

図２１は、ブロックチェーンシステムで行われる鍵の再発行処理の一例を示すシーケンス図である。この処理は、前記実施例１の図７、図８と同様であり、図２１では、ユーザＡが秘密鍵を紛失した例を示す。

ユーザ端末１３００−ＡのユーザＡは、秘密鍵を紛失したので（Ｓ５０１）、登録端末１４００で鍵の再発行処理を開始する。登録端末１４００は、ユーザＡの公開鍵証明書と公開テンプレート証明書を鍵格納部１０９１及び公開テンプレート証明書格納部１０９２から取得して公開鍵失効申請書を生成し（Ｓ５０２）、公開テンプレートリポジトリ１２００へ送信する（Ｓ５０３）。

公開テンプレートリポジトリ１２００は、公開鍵失効申請書の正当性を検証する（Ｓ５０３）。この検証は、公開テンプレートリポジトリ１２００が、公開鍵失効申請書に付与された署名値が正しいことを、公開テンプレート証明書を用いて検証する。検証が成功した場合、公開テンプレートリポジトリ１２００は、公開鍵失効リストを発行する（Ｓ５０４）。公開テンプレートリポジトリ１２００は、公開鍵失効リストを証明書失効リスト格納部１２９１へ登録し、登録端末１４００に送信する。

登録端末１４００は、公開鍵失効リストを受信した後に、ユーザＡの生体情報を取得する（Ｓ５０５）。登録端末１４００は、公開テンプレート証明書の生体署名を用いて、公開テンプレート証明書を生成した際に元にした生体情報と、取得した生体情報とが同一人物から取得したものであるかを検証し、同一人物の場合は検証成功とする。

検証が成功した場合には、登録端末１４００が、前記実施例１と同様に鍵ペアを生成し（Ｓ５０７）、公開鍵に署名を付与して公開鍵証明書を生成する（Ｓ５０８）。登録端末１４００は、鍵ペアと公開鍵証明書を鍵格納部１０９１へ登録してから（Ｓ５０９）、鍵ペアと公開鍵証明書をユーザＡのユーザ端末１３００−Ａに送信する（Ｓ５１０）。

ユーザ端末１３００−Ａは、古い鍵ペアと公開鍵証明書を削除し、受信した新たな鍵ペアと公開鍵証明書を鍵格納部１０９１へ登録する（Ｓ５１１）。次に、ユーザ端末１３００−Ａは、トランザクションの送受を行うユーザ端末１３００−Ｂに公開鍵を送信する（Ｓ５１２）。

ユーザ端末１３００−Ｂは、ユーザＡの古い公開鍵を削除して、新たに受信した公開鍵を鍵格納部１０９１へ登録する（Ｓ５１３）。

以上のように、本実施例３では、登録端末１４００を用いて取得したユーザの生体情報を鍵として公開鍵へ署名を付与することで公開鍵証明書を再発行することができる。本実施例３では、例えば、ブロックチェーンシステムを管理する組織に登録端末１４００を設置して、ブロックチェーンシステムの管理者などがユーザの本人確認を行ってから生体情報を取得することが可能となる。これにより、本人のなりすましによる登録を抑制することができる。

なお、登録端末１４００と公開テンプレートリポジトリ１２００は、ひとつの計算機で構成することができる。この場合、登録部（公開鍵証明書生成部１４５０、公開テンプレート証明書生成部１２２０、公開鍵失効申請書生成部１０８０）をひとつの計算機で提供することができる。あるいは、登録端末１４００と公開テンプレートリポジトリ１２００と検証端末１１００を、ひとつの計算機で構成してもよい。この場合、登録部と検証部（公開鍵証明書検証部１１２０）をひとつの計算機で提供することができる。

第４の実施例は、前記実施例１または実施例３のブロックチェーンシステムのトランザクションの一部を変更したもので、その他の構成は前記実施例１または実施例３と同様である。

図２２は、実施例４のブロックチェーンのデータ構造の一例を示すブロック図である。前記実施例１の図１０に示したトランザクションのうち、公開テンプレート証明書１００３０、１０１３０に代わって、公開テンプレートシリアル番号（Ｓ／Ｎ）１００３１、１０１３１を用いるようにした点が、本実施例４における変更点である。

公開テンプレートシリアル番号１００３１（１０１３１）は、公開テンプレートリポジトリ１２００の公開テンプレート証明書の生成時に、公開テンプレート証明書に対応付けた値として付与することができる。あるいは、登録端末１４００で公開テンプレートを生成する際に、公開テンプレートに対応付けた値として付与することができる。公開テンプレートシリアル番号１００３１（１０１３１）は、ブロックチェーンシステム内でユニークな識別子であれば良い。

なお、公開テンプレートリポジトリ１２００は、公開テンプレート証明書と公開テンプレートシリアル番号を関連付けて公開テンプレート証明書格納部１２９０へ格納する。

既存トランザクション１００１０や新トランザクション１０１１０の正当性を検証する際には、例えば、検証端末１１００が、公開テンプレートシリアル番号１００３１（１０１３１）に対応する公開テンプレート証明書を公開テンプレートリポジトリ１２００に要求すればよい。

以上のように、公開テンプレート証明書に代わって、ユーザを特定する識別子として公開テンプレートシリアル番号１００３１（１０１３１）をトランザクションに設定することでトランザクションのサイズを抑制する。そして、検証端末１１００では、トランザクションを受け付けると、公開テンプレートシリアル番号１００３１を取得して公開テンプレートリポジトリ１２００に検索させて取得することができる。

＜まとめ＞
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。

また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１０ ＣＰＵ
２０ 主記憶装置
３０ 補助記憶装置
１０００ 署名端末
１０３０ 公開テンプレート生成部
１０４０ 鍵ペア生成部
１０５０ 公開鍵証明書生成部
１０６１ ハッシュ値生成部
１０７０ 署名生成部
１０７１ 新トランザクション生成部
１０８０ 公開鍵失効申請書生成部
１１００ 検証端末
１１２０ 公開鍵証明書検証部
１１４０ 署名検証部
１２００ 公開テンプレートリポジトリ
１２２０ 公開テンプレート証明書生成部
１２３０ 公開鍵失効申請書検証部
１２４０ 証明書失効リスト生成部

Claims (15)

1. プロセッサとメモリを備えた計算機で署名を検証する署名検証システムであって、
   ユーザの生体情報を取得する生体情報取得部と、
   前記生体情報に所定の処理を加えて公開テンプレート証明書を生成する公開テンプレート証明書生成部と、
   秘密鍵と公開鍵のペアを生成する鍵ペア生成部と、
   前記生体情報を鍵として前記公開鍵へ生体署名を付与することで公開鍵証明書を生成する公開鍵証明書生成部と、
   前記公開テンプレート証明書と前記公開鍵証明書と署名を含むトランザクションを受け付けて、前記公開テンプレート証明書で前記公開鍵証明書の正当性を検証し、さらに前記公開鍵証明書で前記署名を検証する検証部と、
   を有することを特徴とする署名検証システム。
2. 請求項１に記載の署名検証システムであって、
   前記トランザクションは、
   取引元の公開鍵証明書と取引先の公開テンプレート証明書とを含み、
   前記検証部は、
   第１のトランザクションの次に第２のトランザクションを受け付けて、前記第１のトランザクションの公開テンプレート証明書を用いて前記第２のトランザクションの公開鍵証明書を検証し、前記第２のトランザクションに含まれる公開鍵証明書を用いて前記第２のトランザクションに含まれる署名を検証することを特徴とする署名検証システム。
3. 請求項１に記載の署名検証システムであって、
   前記公開テンプレート証明書を第１の識別子と対応付けて格納する公開テンプレート証明書格納部をさらに有し、
   前記トランザクションは、
   前記公開テンプレート証明書に代わって、前記第１の識別子を格納し、
   前記検証部は、
   前記トランザクションの第１の識別子を取得して、前記公開テンプレート証明書格納部から前記第１の識別子に対応する公開テンプレート証明書を取得することを特徴とする署名検証システム。
4. 請求項１に記載の署名検証システムであって、
   前記トランザクションは、
   前記公開テンプレート証明書に認証局の秘密鍵で生成した署名値を含み、
   前記検証部は、
   前記認証局の公開鍵を用いて前記公開テンプレート証明書の前記署名値を検証することを特徴とする署名検証システム。
5. 請求項１に記載の署名検証システムであって、
   前記トランザクションは、
   前記公開テンプレート証明書に生体情報を鍵とする署名値と、前記生体情報から生成された公開テンプレートを含み、
   前記検証部は、
   前記トランザクションから前記公開テンプレートを取得し、当該公開テンプレートを用いて前記公開テンプレート証明書の前記署名値を検証することを特徴とする署名検証システム。
6. 請求項１に記載の署名検証システムであって、
   前記公開鍵証明書を特定する第２の識別子と、前記生体情報を鍵とする生体署名を付与した公開鍵失効申請書を発行する公開鍵失効申請書生成部をさらに有することを特徴とする署名検証システム。
7. 請求項６に記載の署名検証システムであって、
   前記公開鍵証明書生成部は、
   前記発行された公開鍵失効申請書に対応する公開テンプレート証明書を取得し、前記公開テンプレート証明書を利用するユーザの生体情報を取得し、前記公開テンプレート証明書を生成した生体情報と前記取得した生体情報が一致していれば、新たな鍵ペアと新たな公開鍵証明書を生成することを特徴とする署名検証システム。
8. 請求項１に記載の署名検証システムであって、
   前記計算機は、
   鍵ペアと公開鍵証明書を生成する登録端末と、トランザクションを受け付け検証する検証端末と、公開テンプレート証明書を生成する公開テンプレートリポジトリと、を含み。
   前記登録端末は、前記生体情報取得部と、前記鍵ペア生成部と、前記公開鍵証明書生成部とを有し、
   前記検証端末は、前記検証部を有し、
   前記公開テンプレートリポジトリは、前記公開テンプレート証明書生成部を有することを特徴とする署名検証システム。
9. プロセッサとメモリを備えた計算機で署名を検証する署名検証方法であって、
   前記計算機が、ユーザの生体情報を取得する第１のステップと、
   前記計算機が、前記生体情報に所定の処理を加えて公開テンプレート証明書を生成する第２のステップと、
   前記計算機が、秘密鍵と公開鍵のペアを生成する第３のステップと、
   前記計算機が、前記生体情報を鍵として前記公開鍵へ生体署名を付与することで公開鍵証明書を生成する第４のステップと、
   前記計算機が、前記公開テンプレート証明書と前記公開鍵証明書と署名を含むトランザクションを受け付ける第５のステップと、
   前記計算機が、前記トランザクションに含まれる前記公開テンプレート証明書で前記公開鍵証明書の正当性を検証し、さらに前記公開鍵証明書で前記署名を検証する第６のステップと、
   を含むことを特徴とする署名検証方法。
10. 請求項９に記載の署名検証方法であって、
    前記トランザクションは、
    取引元の公開鍵証明書と取引先の公開テンプレート証明書とを含み、
    前記第５のステップは、
    第１のトランザクションの次に第２のトランザクションを受け付けて、
    前記第６のステップは、
    前記第１のトランザクションの公開テンプレート証明書を用いて前記第２のトランザクションの公開鍵証明書を検証し、前記第２のトランザクションに含まれる公開鍵証明書を用いて前記第２のトランザクションに含まれる署名を検証することを特徴とする署名検証方法。
11. 請求項９に記載の署名検証方法であって、
    前記第２のステップは、
    前記公開テンプレート証明書を第１の識別子と対応付けて公開テンプレート証明書格納部へ格納し、
    前記トランザクションは、
    前記公開テンプレート証明書に代わって、前記第１の識別子を格納し、
    前記第６のステップは、
    前記トランザクションの第１の識別子を取得して、前記公開テンプレート証明書格納部から前記第１の識別子に対応する公開テンプレート証明書を取得することを特徴とする署名検証方法。
12. 請求項９に記載の署名検証方法であって、
    前記トランザクションは、
    前記公開テンプレート証明書に認証局の秘密鍵で生成した署名値を含み、
    前記第６のステップは、
    前記認証局の公開鍵を用いて前記公開テンプレート証明書の前記署名値を検証することを特徴とする署名検証方法。
13. 請求項９に記載の署名検証方法であって、
    前記トランザクションは、
    前記公開テンプレート証明書に生体情報を鍵とする署名値と、前記生体情報から生成された公開テンプレートを含み、
    前記第６のステップは、
    前記トランザクションから前記公開テンプレートを取得し、当該公開テンプレートを用いて前記公開テンプレート証明書の前記署名値を検証することを特徴とする署名検証方法。
14. 請求項９に記載の署名検証方法であって、
    前記計算機が、前記公開鍵証明書を特定する第２の識別子と、前記生体情報を鍵とする生体署名を付与した公開鍵失効申請書を発行する第７のステップをさらに含むことを特徴とする署名検証方法。
15. プロセッサとメモリを備えた計算機を制御するプログラムであって、
    トランザクションに含めるメッセージを取得する第１のステップと、
    前記トランザクションに含まれる情報のハッシュ値を生成する第２のステップと、
    前記ハッシュ値に対して予め生成した秘密鍵を用いて署名を付与する第３のステップと、
    生体情報に所定の処理を加えて予め生成された公開テンプレート証明書を取得する第４のステップと、
    前記生体情報を鍵として前記秘密鍵に対応する公開鍵へ生体署名を付与した公開鍵証明書を取得する第５のステップと、
    前記公開テンプレート証明書と、前記公開鍵証明書と、前記メッセージと、前記署名とを含むトランザクションを生成する第６のステップと、
    を前記計算機に実行させることを特徴とするプログラム。

Images