JP6841781B2 - 認証サーバ装置、認証システム及び認証方法 - Google Patents

Description

本発明は、電子署名を生成・検証する認証サーバ装置、認証システム及び認証方法に関するものである。

インターネット上でサービスを提供するサービス事業者が通信相手のユーザを認証する際に、生体情報そのものを秘密鍵として、任意のメッセージ（電子文書）に対して署名を生成することのできるシステムとして、特開２０１３−１２３１４２号公報（特許文献１）に記載の技術がある。この公報には「登録時にユーザの生体情報の特徴量に対して所定の秘密鍵を埋め込み、対応する公開鍵と組にして生体証明書を発行する。署名時にはユーザの生体情報の署名用特徴量に対して、新たに一時秘密鍵と一時公開鍵のペアを生成し、一時秘密鍵を用いてメッセージに対する署名を作成し、署名用特徴量に一時秘密鍵を埋め込んでコミットメントを作成し、前記一時公開鍵と前記署名と前記コミットメントの組を生体署名とし、生体署名検証時には署名を一時公開鍵で検証し、生体証明書とコミットメントと一時公開鍵から差分秘密鍵と差分公開鍵を生成して対応を検証する。」という記載がある。

また、サービスユーザのチャレンジ・レスポンス認証に用いる秘密鍵を、ネットワークを流通させず、端末の紛失や変更に伴う消失も端末の追加に伴う追加もなく、サービス毎に管理する認証システムとして、特開２０１６−１３９９１０号公報（特許文献２）記載の技術がある。この公報には、「認証鍵管理装置が、事前認証ＩＤに対応するユーザの事前認証を行って、認証されたユーザの利用登録の要求を受信した認証サーバから公開鍵の生成の要求があった場合に、鍵認証に用いられる公開鍵および秘密鍵を生成し、生成された公開鍵を認証サーバに送信し、生成された秘密鍵を事前認証ＩＤと対応付けして記憶し、認証サーバと認証クライアントとの間の鍵認証において秘密鍵を用いて暗号化されるチャレンジを受信した場合に、チャレンジに応答するレスポンスをチャレンジおよび秘密鍵を用いて生成する。」という記載がある。

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

インターネット上で提供されているサービスにおいて、個人端末の紛失や盗難の際には、ユーザの個人情報の漏洩を防止するために、公開鍵とユーザの生体情報から生成した秘密鍵を失効させる運用が一般的である。そのため、秘密鍵と公開鍵が失効されると、新たな公開鍵・秘密鍵を登録しない限り、ユーザはその情報で認証を行っていたサービスを再開することができない。しかし、特許文献１では、ユーザが認証に用いる個人端末を紛失又は盗難等によって消失させた場合の対応については、深く検討されておらず、ユーザがサービスを再開させるまでには手続負担が大きい。

また、特許文献２では、ユーザの利便性や個人情報の安全性の観点から、二つの課題がある。その一つは、端末消失時には、利用者が使用していたサービスの鍵管理サーバにアクセスするための秘密情報がなくなるため、利用者が携帯電話店で新たな端末へ秘密情報の再登録を行う必要があり、ユーザの利便性に課題がある。また、二つ目の課題は、サービスの全ユーザ分の秘密情報をサーバ上で管理するため、万が一サーバ上の情報が漏洩した場合には影響範囲が広い。そのため、秘密鍵の管理に対して、厳重なセキュリティ対策などに運用コストがかさむことになる。

そこで、本発明では、秘密情報をサーバ側で管理することなく、サービス再開までのユーザの手続負担を軽減し、端末紛失後であっても、複数のサービスにおける個人認証を成立させることを目的とする。

上記課題を解決するために、代表的な本発明の認証サーバ装置の一つは、登録端末、認証端末及びサービス提供サーバとネットワークを介して接続された認証サーバである。認証サーバは、記憶装置と処理装置とを具備する。前記処理装置は、利用者が通知した登録端末に格納されている公開鍵と秘密鍵復元用情報を失効させる。また、前記処理装置は前記記憶装置から予備の公開鍵と予備の秘密鍵復元用情報を取得し、前記予備の公開鍵に対して公開鍵証明書を発行する。また、前記処理装置は、前記認証端末から前記登録端末の端末情報及び読取センサ情報が含まれる秘密鍵復元用情報取得要求を受信する。また、前記処理装置は、前記記憶装置に格納されている秘密鍵復元用情報から、当該利用者の前記予備の秘密鍵復元用情報を取得し、前記認証端末に送信する。また、前記処理装置は、前記認証端末から前記予備の秘密鍵復元用情報及び前記認証端末で読取った生体情報から生成された秘密鍵による署名値を受信する。また、前記処理装置は、前記署名値を前記記憶装置に格納された前記予備の公開鍵証明書で検証し、検証結果を前記サービス提供サーバに送信する。

秘密情報をサーバ側で管理することなく、サービス再開までのユーザの手続負担を軽減し、端末紛失後も、複数のサービスにおける個人認証を簡便に成立させることができる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本発明の第１実施形態に係るハードウェアの全体システム構成を示す図である。 本発明の第１実施形態に係る登録端末と認証サーバ装置における利用登録処理を示すシーケンス図である。 本発明の第１実施形態に係る認証サーバ装置における再発行処理を示すシーケンス図である。 本発明の第１実施形態に係る認証端末と認証サーバ装置とサービス提供サーバにおける認証処理を示すシーケンス図である。 本発明の第１実施形態に係る認証サーバ装置の証明書発行情報記憶部で管理する証明書管理テーブルの情報を示した図である。 本発明の第１実施形態に係る認証サーバ装置の予備情報記憶部で管理する予備情報管理テーブルの情報を示した図である。 本発明の第１実施形態に係る認証サーバ装置の証明書発行情報記憶部で管理する端末情報管理テーブルの情報を示した図である。 従来の技術における認証方法を示す図である。 本発明の第２実施形態に係る証明書失効・再発行シーケンスを示す図である。 本発明の第２実施形態に係る認証処理シーケンスを示す図である。

以下、図面を参照して、従来例及び本発明の第１実施形態について説明する。なお、この実施形態により本発明が限定されるものではない。また、図面の記載において、同一部分には同一の符号を付して示している。

まず、図８を参照して、従来の技術における認証方法について説明する。

図８は、従来の技術における認証方法を示す図である。図８に示されている通り、まず、登録時に、クライアント（ユーザ）から取得した生体情報（指静脈パターン等）から、特徴量が一般的に知られている方法で抽出される。次に、既存の鍵生成アルゴリズム（RSA等）を用いて、秘密鍵と秘密鍵に対応する公開鍵とが生成される。この秘密鍵及び生体情報から抽出した特徴量を、一方向変換させることで公開テンプレートが生成され、この公開テンプレートは認証サーバに保管される。それと同時に、生成された秘密鍵及び公開鍵に基づいて、この公開鍵の有効化を要求する公開鍵証明書発行要求が生成され、認証サーバに保存される。そして、認証時には、ユーザの生体情報と認証サーバに保管されている公開テンプレートを合わせることで復元した秘密鍵によって生成された署名を、認証サーバから通知されるチャレンジコードと比較することでユーザ認証が行われる。

ここで、公開テンプレートを用いて、生体署名技術と公開鍵認証基盤を併せた仕組みを公開型生体認証基盤（Public Biometric Infrastructure、又はPBIと呼ぶこともある）と呼ぶ。ＰＢＩでは、ユーザの生体情報及び秘密鍵を一方向変換させた状態（元に戻らない形）で格納し、登録局（サーバ等）に保管することで、ユーザは国民ID基盤、「手ぶら」の決済サービス、パスワードレスのクラウド認証、フィジカルセキュリティなどにおける生体認証を個々のサービスへの登録なしで使うことができる。公開テンプレートは「秘密鍵復元用情報」または「PBIテンプレート」と呼ぶこともある。

[認証システムの構成]
図1は、本発明の第１実施形態に係るハードウェアの全体システム構成を示す図である。図1に示すように、本システムは、認証サーバ１１０と、登録端末１２０と、認証端末１３０と、サービス提供サーバ１４０と、ネットワーク（インターネット、LAN等）１５０とから構成される。認証サーバ１１０と、登録端末１２０と、認証端末１３０と、サービス提供サーバ１４０とがネットワーク１５０を介して接続されてもよい。

サービス提供サーバ１４０は、ネットワーク１５０を介してWebサービス等をユーザに提供するサーバ装置である。一例として、認証サーバ（または認証サーバ装置と呼ぶこともある）１１０は、銀行や金融機関が運用するWebサーバ装置であって、オンラインバンキング等のサービスをユーザ（利用者と呼ぶこともある）に提供するものであってもよい。

認証サーバ１１０は、ネットワーク１５０を介してサービス提供サーバ１４０によって提供されたサービスと、利用登録を行った登録ユーザ（以下、ユーザ）との間に行われる認証処理を行う装置である。具体的には、認証サーバ１１０は認証処理に用いられる公開テンプレートの登録、公開鍵証明書の発行、署名の検証等の機能を有してもよい。

登録端末１２０は、ユーザが利用する端末装置であって、サービス提供サーバ１４０が提供するサービスに既に登録されている端末である。前述のように、本発明はユーザ端末を紛失したり、盗難された場合（以下、「消失」ともいう。）の対応の利便性を高めたものであるため、登録端末１２０は例えば紛失や盗難された（つまり、元の所有者から離れた）端末であることもある。一例として、登録端末１２０は携帯電話、スマートフォン、タブレットPC等の個人端末であってもよい。あるいは、登録端末１２０はATMや券売機等の、不特定多数のユーザに利用される共有端末であってもよい。

認証端末１３０は、ユーザが登録端末１２０を消失した場合に、認証を行い、通常のサービスを再開するために利用する端末である。一例として、認証端末１３０は、ATMや銀行等に設置される窓口端末であってもよい。また、認証端末１３０は、ユーザが登録端末１２０で使用していたサービスを引き継ぐ対象の端末であってもよい。例えば、登録端末１２０が紛失・盗難された場合において、認証端末１３０はユーザが新しく入手した個人端末（スマートフォン等）であってもよい。また、認証端末１３０は登録端末１２０と同一物であってもよい（すなわち、ユーザが登録端末１２０を一旦失くしたが、その後失くした登録端末１２０を発見し、その発見した登録端末１２０を用いて改めてサービスを再開しようとする場合）。

[認証サーバの構成]
前述のように、認証サーバ１１０は、ネットワーク１５０を介して、サービス提供サーバ１４０によって提供されるサービス、及び、利用登録を行った登録ユーザとの間に行われる通信に対して認証処理を行う装置である。図１に示すように、認証サーバ１１０は、認証処理の各機能を実施する処理装置１０２と、当該認証処理に用いられる情報を記憶する記憶装置１０４とを含む。

処理装置１０２は本発明の実施形態に係る各機能を実施するための機能部を含む。具体的には、処理装置１０２は、公開テンプレート登録（図３参照）や公開鍵証明書再発行（図４参照）における各工程を実施する証明書管理部１１１と、認証処理（図５参照）における各工程を実施する認証処理部１１６を含む。更に、証明書管理部１１１は、認証端末１３０から、後述する公開鍵取得要求（または秘密鍵復元用情報取得要求と呼ぶこともある）を受信する申請受付部１１２と、公開鍵証明書等を発行する証明書発行部１１３と、登録端末（例えば紛失した端末）に格納されている公開鍵と公開テンプレート等を失効させる証明書失効部１１４と、証明書の失効情報を外部に提供する失効情報提供部１１５から構成される。

また、認証処理部１１６は、予備情報記憶部１２６に格納されている予備の公開テンプレートを認証端末に送信する登録情報提供部１１７と、認証端末（例えば、窓口端末）１３０からユーザの生体情報によって生成された署名値を受信する署名検証部１１８と、署名値を予備情報記憶部１２６に格納された予備の公開鍵証明書で検証する証明書検証部１１９と、検証結果をサービス提供サーバに１４０に送信する認証結果作成部１５１とから構成される。後述するように、認証処理部１１６は、証明書発行情報記憶部１２７に記憶されている「本番」として設定された証明書を用いて認証を行います（証明書再発行後の認証時も同様である）。

認証サーバ１１０は、装置内部のCPU（Central Processing Unit）等の演算処理装置がメモリに記憶された制御プログラムを実行することによって、上記記載の各機能部として機能する。

記憶装置１０４は予備情報記憶部１２６と証明書発行情報記憶部１２７とを含む。予備情報記憶部１２６は、認証端末１３０に対して予備の公開鍵を再発行する手順に用いられる予備の証明書発行要求と、予備の公開テンプレートを格納する記憶装置である（図６参照）。なお、証明書発行要求には公開鍵が含まれる。例えば、図６に示されるように、登録時に予め登録された公開テンプレートや証明書発行要求を含む予備情報管理テーブルは記憶装置１０４の予備情報記憶部１２６に格納されてもよい。証明書発行情報記憶部１２７は、認証端末１３０に対応する証明書の状態を管理する情報を格納する記憶装置である（図５参照）。さらに図５に記載の証明書や公開テンプレートを格納する記憶装置である。例えば、図５に示されるように、複数の個人端末に対応する複数の証明書の状態（有効、無効、失効、保留等）を管理する証明書管理テーブルは証明書発行情報記憶部１２７に格納されてもよい。記憶装置１０４の予備情報記憶部１２６と証明書発行情報記憶部１２７は、例えば、RAM（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現されてもよい。

[サービス提供サーバ１４０の構成]
前述の通り、サービス提供サーバ１４０は、ネットワーク１５０を介してWebサービス等をユーザに提供するサーバ装置である。サービス提供サーバ１４０は、登録端末１２０や認証端末１３０からのサービス要求に応じて、認証サーバ１１０に認証処理を要求する認証要求を発行し、送信する認証要求部１４１と、認証処理の終了時に認証サーバ１１０から送信される認証結果に応じて、サービスのアクセスを許可又は却下する業務処理部１４２とから構成される。

[登録端末の構成]
登録端末１２０は、ユーザから指紋や静脈等の登録用生体情報を取得するセンサ部（虹彩カメラ、汎用カメラ、指紋スキャナー等）１２１と、前記登録用生体情報から登録用特徴量を抽出する生体情報処理部１２２と、前記生体情報から登録情報（公開鍵及び公開テンプレート）を生成する登録情報作成部１２３と、前記登録情報を認証サーバ１１０に対して登録申請を行う登録申請部１２４と、認証情報（公開鍵と公開テンプレート）を記憶する認証情報部１２５とを含む。

[認証端末の構成]
認証端末１３０は、登録端末と同様に、ユーザから指紋や静脈等の登録用生体情報を取得するセンサ部１３１と、前記登録用生体情報から登録用特徴量を抽出する生体情報処理部１３２と、認証情報（公開鍵と公開テンプレート）を記憶する認証情報部１２５とを含む。更に、認証端末１３０は、認証サーバ１１０から登録情報を取得する登録情報取得部１３３と、サービスの認証を成立させるための電子署名を作成する署名作成部１３４と、サービスをユーザに提供するためのGUI（Graphical User Interface）等を制御する業務処理部１３５とを含む。

[登録シーケンス]
次に、図２を参照して、本実施形態における利用登録シーケンスについて説明する。図２は、本発明の第１実施形態に係る登録端末１２０と認証サーバ１１０における利用登録処理を示すシーケンス図である。

まず、ステップＳ２０１では、端末情報が取得される。ここで、端末情報とは、登録端末１２０を特徴づける情報であり、登録端末１２０の機種、製番、搭載しているセンサの種類等を示す情報を含む。端末情報は、登録端末１２０に備えられている端末情報取得部（図示せず）が実施する端末診断検査ツールによって取得されてもよい。一例として、端末診断検査ツールが行われた結果、登録端末１２０の機種が「Apricot Qfone」であり、製番が「XNSS-HSJW-3NGU-8XTJ」であり、搭載センサが「指紋スキャナー」であることを示す端末情報が端末情報取得部によって取得されてもよい（図７参照）。

次に、ステップＳ２０２では、生体情報（または読取センサ情報と呼ぶこともある）が取得される。ここで、生体情報とは、人間を一意に識別するために用いられる身体的な特徴や行動的な特徴を示すデータである。一例として、生体情報は指紋情報、指静脈情報、手の平静脈情報、掌形情報、虹彩情報、音声情報及び顔情報等を含む。生体情報は、登録端末１２０に搭載されているセンサ部１２１によって取得されてもよい。例えば、センサ部１２１はユーザの指を撮影することで指紋の画像を生体情報として取得してもよい。

次に、ステップＳ２０３では、ステップＳ２０２で取得した生体情報から特徴量が抽出されてもよい。ここでは、特徴量は、生体情報の特徴や特性を数式化したデータ構造（いわゆるメタデータ）であってもよい。特徴量は、登録端末１２０の生体情報処理部１２２によって抽出されてもよい。一例として、取得された生体情報が指紋画像である場合、生体情報処理部１２２は撮影された指紋の模様を数式的に示す指紋メタデータを特徴量として抽出してもよい。ここでは、生体情報の特徴量抽出は一般的に使われている手段で行われてもよい。

次に、ステップＳ２０４では、秘密鍵と公開鍵のペアが生成される。よく知られているように、公開鍵は、任意の文章に対して暗号文を作成するために使われており、秘密鍵はその暗号文からメッセージを復元するために使われている。前述のように、本発明において、秘密鍵及び公開鍵は登録情報作成部１２３によって作成されてもよい。なお、ここでは、生体情報から抽出した一つの特徴量に対して、秘密鍵と公開鍵のペアはｎ個生成されてもよい。後述するように、秘密鍵と公開鍵を複数個生成しておくことで、複数の公開テンプレートを作成することが可能となる。

ステップＳ２０５では、ステップＳ２０４で生成された秘密鍵とステップＳ２０３で抽出された特徴量は一方向変換される。具体的には、登録情報作成部１２３は所定の電子署名アルゴリズム（例えばSchnorr署名等）を用いて、ステップＳ２０４で取得した特徴量及び秘密鍵に対してソルト（乱数）を付加し、一方向変換（元の情報を復元することが不可能であることが数学的に証明されている変換）させることで公開テンプレート（秘密鍵復元用情報、あるいはPBIテンプレートと呼ぶこともある）を生成する。前述のとおり、ここでは、ステップＳ２０４で生成された複数の秘密鍵のそれぞれと、生体情報から抽出した特徴量とを一緒に一方向変換させることで、公開テンプレートを複数個生成してもよい。例えば、この手順が４回行われることで、４つの秘密鍵と４つの公開鍵と４つの公開鍵テンプレートが生成されてもよい。このように、ここで生成された複数個の公開テンプレート及びステップＳ２０４で生成された公開鍵を予備のものとして認証サーバ１１０に登録しておくことにより、後に、複数のサービスにおけるユーザ認証を成立させることが可能となる。

次に、ステップＳ２０６では、証明書発行要求が作成される。証明書発行要求は、ステップＳ２０５で生成された公開鍵を有効化させる証明書の発行を要求するものである。証明書発行は、登録端末１２０の登録情報作成部１２３によって生成されてもよい。また、証明書発行要求は、その証明書発行要求を一意に識別する証明書発行要求識別番号と対応付けられてもよい。なお、公開テンプレートと公開鍵がN個生成された場合、N個の証明書発行要求が作成されてもよい。

次に、ステップＳ２０７では、登録申請が送信される。登録申請とは、登録端末１２０で用意された登録情報（端末情報、公開鍵、公開テンプレート、証明書発行要求等）を認証サーバ１１０に登録する申請である。具体的には、登録端末１２０の登録申請部１２４は、端末情報（図７参照）、公開鍵テンプレート、証明書発行要求等の登録情報を含んだ登録申請を認証サーバ１１０に送信してもよい。

次に、ステップＳ２０８では、登録申請が受信される。例えば、図２に示すように、認証サーバ１１０の申請受付部１１２は登録端末１２０から送られる登録申請をネットワーク１５０を介して受信してもよい。

次にステップＳ２０９では、証明書発行要求検証が行われる。証明書発行要求検証とは、ステップＳ２０６で作成された証明書発行要求に付与された署名を証明書発行要求に記載された公開鍵で検証する処理である。ここでの証明書発行要求検証は、認証サーバ１１０の証明書検証部１１９によって行われてもよい。一例として、証明書検証部１１９は登録端末１２０から受信した登録情報を検証し、署名検証してもよい。

次にステップＳ２１０では、証明書が発行される。証明書（いわゆる公開鍵証明書）とは、公開鍵と、その所有者の同定情報（その他に、有効期間、発行者、署名アルゴリズム等の情報を含む）を結びつける証明書である。ここで、認証サーバ１１０の証明書発行部１１３は、登録端末１２０から受信した登録情報に基づいて、証明書発行要求で指定された証明書を発行してもよい。なお、ここで発行された複数の証明書の中から、証明書発行部１１３は１個又は複数（例えば、生体情報として指静脈のデータが取得された場合、それぞれの指の静脈に対して証明書を発行することができるため、ここでは複数の証明書を選択してもよい）の証明書を認証処理に用いられる「本番」の証明書として選択し、認証サーバの証明書発行情報記憶部１２７で管理されている証明書管理テーブルに設定されてもよい（図５参照）。

次にステップＳ２１１では、証明書発行要求及び公開テンプレート（PBIテンプレート）が予備の情報として保存される。具体的には、証明書発行要求は、公開テンプレートに対応付けられた状態で認証サーバ１１０の予備情報記憶部１２６で管理されている予備情報管理テーブルに格納されてもよい（図６参照）。この手順をN-1回繰り返すことで、認証に用いられる本番の証明書以外の証明書はそれぞれ予備情報管理テーブルに登録されることになる。従って、後述するように、登録端末１２０が消失した場合には、予備情報管理テーブルに登録されている予備の公開テンプレートを取得し、新たな証明書を発行することで、ユーザは通常のサービスを再開することが可能となる。
なお、本明細書では、「新たな公開鍵証明書」、「新たな公開鍵」及び「新たな秘密鍵復元用情報」との記載において、「新たな」との表現を用いているのは、予備情報管理テーブルに予め格納された予備の情報を用いて、証明書等を新たに発行していることによる。このため、本明細書では、新たに発行する証明書等の元情報を示す際には、「予備」という表現を用いて説明することもある。

次に、ステップＳ２１２では、登録結果が認証サーバ１１０の証明書管理部１１１から登録端末１２０へと送信される。登録結果は、登録端末１２０が認証サーバ１１０に送信した登録申請のデータのうち、どのデータが最終的に登録されたかを通知するものである。また、登録結果は、Ｓ２１０で発行した証明書のデータと、登録された証明書発行要求や公開テンプレートの識別番号等の情報を含んでもよい。例えば、ある登録結果は、ある証明書発行要求の識別番号が20150804＿5483Cであり、公開テンプレートの識別番号が20150804＿5483であり、登録日が２０１５年８月４日であることを示す情報を含んでもよい。

次に、ステップＳ２１３では、登録端末１２０は認証サーバ１１０から送信された登録結果を受信する。

次に、ステップＳ２１４では、登録端末が受信した登録結果に指定されている証明書及び公開テンプレート（PBIテンプレート）は登録端末１２０に保存される。このように、同じ公開鍵及び公開テンプレートが登録端末１２０と認証サーバ１１０の両方に格納されることになる。

[再発行シーケンス]
次に、図３を参照して、本発明の一実施形態に係る認証サーバにおける再発行処理を示すシーケンスについて説明する。前述のように、この再発行処理は例えば、ユーザが登録端末１２０を消失（紛失・盗難等）した場合に行われてもよい。

まず、ステップ３０１では、認証サーバ１１０は、認証端末１３０から公開鍵の再発行申請を受信する。再発行申請とは、認証サーバ１１０の予備情報記憶部１２６に保存されている予備の公開テンプレート及び公開鍵証明書（図６参照）の発行を要求する申請である。例えば、前述のように、登録端末１２０が消失した場合に、ユーザは新しい端末でサービスを再開するために、認証端末１３０を介して再発行申請を認証サーバ１１０に送信してもよい。

前述の通り、登録端末が消失した場合には、ユーザの個人情報の漏洩を防ぐため、公開鍵と秘密鍵が失効される運用が一般的である。従って、認証サーバ１１０が認証端末１３０から証明書の再発行申請を受信すると、ステップＳ３０２では、登録端末１２０で認証に用いられていた公開鍵と公開テンプレートを失効対象として特定する必要がある。そのため、証明書管理部１１１（又は証明書失効部１１４）は、登録端末１２０の端末情報（例えば、ユーザに入力されたユーザID及び端末の機種）に基づいて、証明書発行情報記憶部１２７に記憶されている公開鍵証明書発行情報の中から、失効する公開鍵と公開テンプレートを特定してもよい。１人のユーザの端末１台につき複数の証明書が登録されている場合（例えば、指ごとに異なる公開テンプレートが登録されたり、指静脈や虹彩は両方とも公開テンプレートが登録されたりしている場合）認証サーバ１１０が証明書の失効処理を複数回（例えばM回）繰り返して、そのユーザに該当する全ての公開テンプレートを失効対象として特定してもよい。

次に、ステップＳ３０３では、証明書管理部１１１の証明書失効部１１４は、ステップＳ３０２で特定した公開鍵と公開テンプレートに基づいて、登録端末１２０に格納されている証明書（つまり、公開鍵と公開テンプレート）を失効（つまり、無効化）させる。前述のように、一人のユーザに複数の公開鍵証明書が登録されている場合には、それらを一括で失効させてもよい。一例として、認証サーバ１１０は認証端末１３０から、ユーザID：11223に該当するユーザのための再発行申請を受信した場合、証明書失効部１１４は証明書管理テーブル（図５参照）に格納されているデータのうち、ユーザID：11223に該当する全ての公開テンプレート（例えば識別番号が２０１５０８０４＿５４８２のテンプレートと、識別番号が２０１７１２２５＿１５３４のテンプレートと、識別番号が２０１７１２２５＿１５３７のテンプレート）を特定し、一括で失効させてもよい。なお、再発行処理とは別に、予備情報記憶部１２６に格納された証明書や公開テンプレートの有効期限が満了した際、証明書失効部１１４は、これらの公開鍵及び公開テンプレートを一括で消去してもよい。

次に、ステップＳ３０４とステップＳ３０５では、証明書管理部１１１は証明書発行要求及び公開テンプレート（PBIテンプレート）をそれぞれ取得する。具体的には、証明書管理部１１１（または証明書発行部）は、認証サーバ１１０の予備情報記憶部１２６に格納されている予備情報管理テーブルの中から、前述の登録シーケンスにおいて登録された予備の公開鍵証明書発行要求及び予備の公開テンプレートを取得する。

次に、ステップＳ３０６では、ステップＳ３０４で取得した予備の公開鍵証明書発行要求及び予備の公開テンプレートに基づいて、新たな証明書を発行してもよい。前述の通り、ここで発行された証明書は、登録端末１２０でユーザが使用していたサービスに対して認証を行い、当該サービスを再開するために用いられるものである。また、ここで発行される公開鍵証明書の有効期限は、ステップＳ３０３で失効させられた証明書を同じ有効期限を有するように設定されてもよい。発行した新たな証明書と、Ｓ３０４で取得した予備の公開テンプレートを新たな公開テンプレートとして証明書発行情報記憶部に記憶する。
なお、証明書を発行した時点で、予備情報記憶部１２６から証明書発行要求は削除され、新たに発行された証明書は証明書発行情報管理記憶部１２７に保管される。また、選択された予備の公開テンプレートは、予備情報記憶部１２６から証明書発行情報管理記憶部１２７に移動することとなる。

次に、ステップＳ３０７とステップＳ３０８では、証明書管理部１１１は、証明書発行情報記憶部１２７に保存されている証明書管理テーブル（図５参照）と予備情報記憶部１２６に保存されている予備情報管理テーブル（図６参照）をそれぞれ更新する。具体的に、証明書管理部１１１は、証明書管理テーブルにおいて、ステップＳ３０３で失効した証明書の状態を「有効」から「失効」に更新し、予備情報管理テーブルにおいて、新しく発行した証明書の元となった証明書発行要求を予備情報管理テーブルから削除し、証明書管理テーブルに当該証明書に該当するレコードを追加してもよい。なお、本実施形態では、元の証明書の失効と新たな証明書の発行は同時（１段階）に行われていたが、本発明はこれに限定されず、証明書の失効と発行を分けて二段階で行ってもよい（図９に示される第２実施形態参照）。

[認証シーケンス]
次に、図４を参照して、本発明の一実施形態に係る認証端末と認証サーバとサービス提供サーバにおける認証処理を示すシーケンスを説明する。前述した通り、この認証処理は、ユーザが再発行処理において発行された予備の公開テンプレートと公開鍵を用いて認証を要求する場合に行われてもよい。

まず、ステップＳ４０１では、認証端末１３０はサービス提供サーバ１４０にサービス要求を送信する。サービス要求とは、認証端末（つまり、ユーザ）からの、サービス提供サーバ１４０がネットワーク１５０を介して提供するサービスへのアクセスを要求するものである。例えば、ユーザは認証端末１３０を介して、銀行の管理するWebサーバ（サービス提供サーバ１４０）に対して、オンラインバンキングへのアクセスを求める要求をサービス要求として送信してもよい。

次に、ステップＳ４０２では、サービス提供サーバ１４０は認証端末１３０からのサービス要求を受信すると、認証要求を認証サーバ１１０に送信する。前述の通り、この認証要求とは、ステップＳ４０１でサービス提供サーバのサービスへのアクセスを要求したユーザに対して認証処理を要求するものである。

次に、ステップＳ４０３では、認証サーバ１１０は、ユーザ認証に用いられるチャレンジコードを認証端末１３０に送信する。このチャレンジコードとは、例えば、いわゆるワンタイムパスワード（S/Key方式）であってもよい。認証サーバ１１０がここで作成したチャレンジコードは、認証端末１３０に通知される。なお、ここでのチャレンジコードは特に限定されず、一般的にチャレンジ・レスポンス認証に用いられる周知の方法が使われてもよい。

次に、ステップＳ４０４とステップＳ４０５では、認証端末１３０が認証サーバ１１０からのチャレンジコードを受信すると、認証端末１３０は端末情報及びIDをユーザから取得する。具体的には、ユーザは登録端末（つまり、消失した端末）の情報（機種等）と、個人のユーザID（氏名、ユーザ番号等）とを認証端末１３０のGUI等を介して入力し、その後、この端末情報とIDは認証サーバ１１０に送信される。また、このステップでは、ユーザが使用する端末が変更された場合には、新しく入手した端末の情報（機種や型番等）を端末情報として提供してもよい。

次に、ステップＳ４０６では、認証サーバ１１０は認証端末１３０に新たな公開テンプレート及び新たな証明書を提供する。具体的には、認証サーバ１１０の認証処理部１１６は、ステップＳ４０４で認証端末から取得した登録端末の情報とユーザのIDに基づいて、証明書発行情報管理テーブルの中から当該ユーザに該当する新たな公開テンプレート及び新たな証明書を特定して、認証端末１３０に送信する。

次に、ステップＳ４０７では、認証端末１３０は認証サーバに提供された新たな公開テンプレートを取得する。

次に、ステップＳ４０８では、ユーザの生体情報が取得される。ここでは、生体情報は、図２に示されている登録シーケンスにおける生体情報取得と同様に、認証端末１３０に搭載されているセンサ部１３１によって取得されてもよい。例えば、センサ部１３１はユーザの手の平の静脈を撮影することで、手の平の静脈の画像を生体情報として取得してもよい。

次に、ステップＳ４０９では、ステップＳ４０８で取得された生体情報から、特徴量が抽出されてもよい。ここでは、図２に示されている登録シーケンスにおける特徴量取得と同様に、認証端末１３０は生体情報の特徴や特性を数式化したデータ構造（いわゆるメタデータ）をユーザの生体情報から抽出する。一例として、取得された生体情報が手の平の静脈の画像である場合、生体情報処理部１３２は撮影された手の平の静脈の模様を数式的に示す静脈メタデータを特徴量として抽出してもよい。

次に、ステップＳ４１０では、ステップＳ４０９で抽出した生体情報の特徴量に基づいて、新たな秘密鍵が復元される。具体的には、前述の通り、認証サーバ１１０から受信した新たな公開テンプレートとステップＳ４０９で抽出した特徴量を合わせることで新しい秘密鍵が復元される。したがって、この秘密鍵で署名を作成することで認証処理が成立する。

次に、ステップＳ４１１では、ステップＳ４１０で生成された新しい秘密鍵及びステップＳ４０７で認証サーバ１１０から受信した新たな公開テンプレートに基づいて、ステップＳ４０３で通知されたチャレンジコードに対する署名（レスポンス）が生成される。この署名（又は署名値と呼ぶこともある）とは、チャレンジ・レスポンス認証におけるレスポンスとなる情報である。ここでの署名は特に限定する必要はなく、一般的にチャレンジ・レスポンス認証に用いられる周知の方法が使われていてもよい。

次に、ステップＳ４１２では、新しい公開テンプレートと証明書が認証端末130に保存される。具体的には、新しい公開テンプレートと証明書が認証端末１３０の認証情報記憶部１３６に格納されることになる。このように、二回目以降の認証を行う際には、公開テンプレートを認証サーバ１１０から取得する必要はなく、認証情報記憶部１３６に格納されている公開テンプレートとユーザの生体情報を合わせることで認証処理を行うことができる。

次に、ステップＳ４１３では、認証サーバ１１０は、証明書発行情報記憶部１２７で管理される新たな公開鍵証明書で署名を検証する。具体的には、認証サーバ１１０の認証処理部１１６（又は署名検証部１１８）は、ユーザのIDに基づいて新たな証明書を特定し、証明書から公開鍵を読み出して、取り出した公開鍵を用いて認証端末１３０から送付された署名を復号化する。そして、認証処理部１１６は、署名を復号化したものとステップＳ４０３で生成したチャレンジコードを照合し、一致した場合にはユーザを認証する。

次に、ステップＳ４１４では、認証サーバ１１０は証明書の検証を行う。この証明書検証では、認証サーバ１１０は、署名を生成するために用いられた公開テンプレートの証明書の有効性を検証する。例えば、現在時刻が証明書に対応付けられた有効期限内であり、また失効情報に掲載されていない場合は、この証明書は有効だと判定され、その結果、この証明書に該当するユーザが認証される。ここでの証明書検証は特に限定する必要はなく、一般的に認証処理に用いられる周知の方法が使われていてもよい。

次に、ステップＳ４１５では、認証結果が作成される。認証結果とは、ステップＳ４１３及びステップＳ４１４の検証に応じて、ユーザ認証が成立するかどうかを示す通知書である。例えば、検証の結果、証明書及び署名が有効だと判定された場合には、認証が成立する旨を示すデータが認証結果として生成される。

次に、ステップＳ４１６では、端末情報が更新される。具体的には、ステップＳ４０４で受信した端末情報に基づいて、認証サーバ１１０で管理される端末情報管理テーブルが更新されてもよい。例えば、ステップＳ４０４で受信した端末情報は、ユーザが「Apricot Qfone 2」を新しい端末として入手したことを示す場合には、認証サーバ１１０は端末情報管理テーブルのレコードにおいて、ユーザ端末の機種が「Apricot Qfone 2」であることを反映させるように更新してもよい。また、図５の証明書管理テーブルにおいても、保存先５０８に関する情報(「保存先情報」とも言う。)は、新しい端末の機種を反映するように更新されてもよい。

次に、ステップＳ４１７では、サービス提供サーバ１４０は認証サーバ１１０から通知される認証結果を取得する。認証結果が、認証が成立したことを示す場合には、サービス提供サーバ１４０はステップＳ４０１で受信した認証端末のサービス要求を許可してもよい。

[証明書管理テーブルの構成]
次に、図５を参照して、本発明の一実施形態に係る認証サーバの証明書発行情報記憶部で管理する証明書管理テーブルについて説明する。

図５に示されている証明書管理テーブルは、ユーザ認証に用いられる公開鍵証明書の情報を管理するテーブルである。証明書管理テーブルは、認証サーバ１１０の証明書発行情報記憶部１２７に格納されてもよい。

図５に記載されている通り、証明書管理テーブルは、証明書の発行先（例えば、ユーザID,ユーザの名前、住所等）を識別する発行先情報５０１、証明書を識別する証明書シリアル番号５０２、証明書の状態（例えば有効、無効、失効、保留等）５０３、公開テンプレートを識別する公開テンプレート識別番号５０４、発行先ごとに登録している生体情報を表す生体情報（例えば虹彩情報、指静脈情報等）５０５、生体情報の種別（左手や右手等）５０６、端末に搭載されている各センサの種類を表すセンサ（虹彩カメラ、汎用カメラ等）５０７、及び証明書の保存先（特定の個人端末、サーバなどの保存先情報）５０８等の情報から構成されてもよい。例えば、保存先５０８の欄に示されているように、証明書が「端末A」や「端末C」等のユーザの端末（例えば登録端末１２０）に保存されてもよく、「サーバ」（例えば認証サーバ１１０）に保存されてもよい。

[予備情報管理テーブルの構成]
次に、図６を参照して、本発明の一実施形態に係る認証サーバの予備情報記憶部で管理する予備情報管理テーブルについて説明する。

図６に示されている予備情報管理テーブルは、事前に登録されている予備の証明書発行要求及び予備の公開テンプレートを管理するテーブルである。登録端末（例えば登録端末１２０）で初期登録を行う時に、ユーザから読み取った一つの生体情報から複数の証明書発行要求鍵と複数の公開テンプレートを生成し、これらを認証サーバ１１０の予備情報記憶部１２６に保管することで、登録端末１２０が消失した場合には、予備情報管理テーブルの中から予備の公開鍵及び予備の公開テンプレートを有効化し、再発行することで、サービスを再開することが可能となる。

図６に示されている通り、予備情報管理テーブルは、証明書の発行先（例えば、ユーザID,ユーザの名前、住所等）を識別する発行先情報６０１、証明書発行要求を識別する証明書発行要求識別番号、公開テンプレートを識別する公開テンプレート識別番号６０３、発行先ごとに登録している生体情報を表す生体情報（例えば虹彩情報、指静脈情報等）６０４、生体情報の種別（左手や右手）６０５、（虹彩カメラ、汎用カメラ等）６０６、及び予備の証明書発行要求及び予備の公開テンプレートを指定する登録日等の情報から構成されてもよい。

[端末情報管理テーブルの構成]
次に、図７を参照して、本発明の一実施形態に係る認証サーバの証明書発行情報記憶部で管理する端末情報管理テーブルについて説明する。

図７に示されている端末情報管理テーブルは、登録端末(例えば登録端末１２０)を特徴づける情報を管理するテーブルである。例えば、図７に示されている通り、端末情報管理テーブルは、登録端末１２０に備えられているセンサの種類(例えば虹彩カメラ、汎用カメラ、指紋センサ等)を表すセンサ７０１と、端末を識別する端末名（機種の名前、メーカー、製番等）７０２とから構成される。

上記のとおり、本発明に係る第１実施形態において、登録端末（例えば登録端末１２０）で初期登録を行う時に、ユーザから読み取った一つの生体情報から複数の公開鍵と複数の公開テンプレートを生成し、これらを認証サーバ１１０の予備情報記憶部１２６に保管することで、登録端末１２０が消失した場合には、予備情報管理テーブルの中から予備の公開鍵及び予備の公開テンプレートを有効化し、再発行することで、秘密情報をサーバ側で管理することなく、ユーザに再登録を実施させずに、個人認証を成立させることができる。その結果、サービス再開までのユーザの手続負担を軽減するというメリットが得られる。

また、登録端末１２０の端末情報に基づいて、公開鍵証明書発行情報から失効及び発行する公開鍵と公開テンプレートを特定することで、再発行処理を効率よく行うことができ、サービス再開までのユーザの手続負担を軽減することができる。

また、利用者の情報、証明書の識別情報、証明書の状態、公開テンプレートの識別情報、公開テンプレートの基になった生体情報の種類、生体情報の読取センサ情報及び保存先端末情報を公開鍵証明書発行情報として格納することで、公開鍵証明書の失効及び再発行が管理しやすくなる。

また、記憶装置に記憶されている公開鍵証明書発行情報の保存先を、認証端末１３０から送信される登録端末１２０の端末情報に基づいて更新することで、最新の端末情報を継続的に管理することが可能となる。

また、認証サーバ１１０の処理装置１０２は、登録端末１２０から、公開鍵を含んだ公開鍵証明書発行要求、公開テンプレート、端末情報、生体情報の読取センサ情報の少なくとも一つを含む情報を受信し、公開鍵証明書発行要求と公開テンプレートに対して、公開鍵証明書を発行し、登録端末１２０から受信した予備の公開鍵証明書発行要求と公開テンプレートを記憶装置に記憶し、登録端末１２０へ公開鍵証明書を発行したテンプレートを送信することで、ユーザに再登録を実施させずに、予備の公開テンプレートを有効化し、再発行することができる。

また、指静脈情報、手の平静脈情報、掌形情報、指紋情報、虹彩情報、音声情報及び顔情報等の生体情報に基づいて公開テンプレートを生成することで、ユーザの秘密情報をサーバ側で管理する必要がなくなり、セキュリティ対策の運用コストを抑えることができる。

次に、図９を参照して、本発明の第２実施形態に係る証明書失効・再発行シーケンス及び認証処理シーケンスについて説明する。

図３に示されるように、本発明の第１実施形態に関わる証明書再発行においては、登録端末１２０（消失した端末）の認証に用いられた公開鍵証明書の失効と、予備情報管理テーブルから取得した新しい証明書の発行は同時に（一段階で）行われていたが、第２実施形態の証明書再発行シーケンスにおいては、登録端末１２０の公開鍵証明書の失効と、新しい証明書の発行は別々に（二段階で）行われてもよい。

例えば、図９に示されるように、登録端末１２０（消失した端末）の認証に用いられた公開鍵証明書を失効した後、証明書管理テーブルにおける新しい証明書の状態は、直ぐには「有効」と更新されず、「一時保留」に更新される。その後、ユーザが銀行やコンビニエンスストア等に設置される共有認証端末（認証端末１３０）で生体情報をかざすと認証処理が完了し、証明書管理テーブルにおける新しい証明書の状態が「一時保留」から「有効」となり、サービスの再開が可能となる。このようにすることで、公開鍵証明書の失効及び再発行を一連で行う場合よりも、本人確認を厳格に行うことができる。

具体的には、図９に示されるように、ステップ９０１では、認証サーバは、ユーザ（例えば図示されているAさん）から、登録端末に格納されている公開鍵と公開テンプレートを失効する失効申請を受け付け、その後、ステップ９０２では、証明書管理テーブルにおいて、該当する公開テンプレートの状態を「有効」から「失効」に変更することで失効させる。ステップ９０３では、認証サーバはユーザからの証明書再発行申請を受け付けすると、ステップ９０４では、予備情報記憶部（図９における「Aさんの予備データ」）から、新しい公開鍵及び公開テンプレートを取得する。

次に、ステップ９０５では、認証サーバは新しく取得した公開鍵に対して新たな公開鍵証明書を発行し、証明書管理テーブルにおいて、当該公開鍵証明書の状態を「無効」から「一時保留」に変更する。このように、ユーザは生体情報をかざさない限り「窓口の共有認証端末などで」、認証処理が完了せず、この新しく発行した公開鍵証明書でサービスを再開させることができない。証明書を発行した後、認証サーバは新しく発行した公開鍵証明書と公開テンプレートを証明書管理テーブルに登録し、「本番」認証処理時に使われる情報として設定してもよい。

次に、図１０を参照して、本発明の第２実施形態に係る認証処理シーケンスについて説明する。

図１０では、第２実施形態における認証処理のシーケンスが示される。ステップ９１１では、クライアント（認証端末１３０等」はユーザ（例えば図示されているAさん）から、ユーザID（氏名、ID番号等）を受信し、受信したユーザIDに基づいて、当該ユーザに該当する予備の公開テンプレートを求める公開テンプレート取得要求（または公開鍵復元用情報取得要求と呼ぶこともある）を認証サーバに送信する。認証サーバは公開テンプレート取得要求を受信すると、ステップ９１２では、「本番」認証処理時に使われる情報として設定された公開テンプレートを証明書管理テーブルにから特定し、クライアント側に送信する。ステップ９１３では、クライアントはこの公開テンプレートを取得する。

次に、ステップ９１４では、クライアントはユーザから生体情報を取得し、この生体情報から特徴量を抽出する。そして、ステップ９１５では、前述したように、この生体情報から抽出した特徴量と、ステップ９１３で取得した公開テンプレートを合わせることで、新しい秘密鍵が復元される。ステップ９１６では、この新しい秘密鍵を用いて、認証サーバから送信されたチャレンジコードに対して署名を作成する。ステップ９１７では、認証サーバはステップ９１６で作成した署名を新しく発行された公開鍵証明書の公開鍵で認証する。ステップ９１８では、認証サーバは、署名がチャレンジコードに一致するかどうかを確認する。ステップ９１７及びステップ９１８における検証が通った場合、認証サーバは、ステップ９１９では、証明書管理テーブルにおいて、当該公開鍵証明書の状態を「一時保留」から「有効」に更新する。その結果、この公開鍵証明書が使用可能となり、ユーザ認証が成立し、ユーザが求めたサービスを再開することができる。また、ここでの署名検証は認証端末によって行われてもよい。この場合、認証端末は、本人確認が完了したという旨の本人確認完了通知を認証サーバに送信し、この本人確認完了通知を受信した認証サーバは公開鍵証明書を有効化させてもよい。

このように、実施形態２においては、実施形態１と異なり、元の公開鍵証明書の失効と新しい公開鍵証明書の発行を分けて二段階で行うことによって、本人確認を厳格に行うことができ、情報セキュリティの点で優位性を有する。

１０２ 処理装置
１０４ 記憶装置
１１０ 認証サーバ
１１１ 証明書管理部
１１６ 認証処理部
１２０ 登録端末
１２６ 予備情報記憶部
１２７ 証明書発行情報記憶部
１３０ 認証端末
１４０ サービス提供サーバ
１５０ ネットワーク

Claims (10)

1. 登録端末、認証端末及びサービス提供サーバとネットワークを介して接続された認証サーバ装置であって、
   記憶装置と処理装置とを具備し、
   前記処理装置は、
   利用者が通知した前記登録端末に格納されている公開鍵と秘密鍵復元用情報を失効させ、
   前記記憶装置から新たな公開鍵と新たな秘密鍵復元用情報を取得し、前記新たな公開鍵に対して公開鍵証明書を発行し、
   前記認証端末から前記登録端末の端末情報及び読取センサ情報が含まれる秘密鍵復元用情報取得要求を受信し、
   前記記憶装置に格納されている秘密鍵復元用情報から、当該利用者の前記新たな秘密鍵復元用情報を取得し、前記認証端末に送信し、
   前記認証端末から前記新たな秘密鍵復元用情報及び前記認証端末で読取った生体情報から生成された秘密鍵による署名値を受信し、
   前記署名値を前記記憶装置に格納された前記新たな公開鍵証明書で検証し、検証結果を前記サービス提供サーバに送信する、
   ことを特徴とする認証サーバ装置。
2. 前記処理装置は、
   前記利用者から通知した前記登録端末の端末情報に基づいて、前記記憶装置に記憶されている公開鍵証明書発行情報から失効及び発行する公開鍵と秘密鍵復元用情報を特定する、
   ことを特徴とする請求項１に記載の認証サーバ装置。
3. 前記記憶装置は、
   前記公開鍵証明書発行情報として、
   前記利用者の情報、証明書の識別情報、証明書の状態、秘密鍵復元用情報の識別情報、秘密鍵復元用情報の基になった生体情報の種類、生体情報の読取センサ情報及び保存先端末情報の少なくとも一つを有する、
   ことを特徴とする請求項２に記載の認証サーバ装置。
4. 前記処理装置は、
   前記記憶装置に記憶されている公開鍵証明書発行情報の保存先情報を、前記認証端末から送信される前記登録端末の端末情報に基づいて更新する、
   ことを特徴とする請求項１に記載の認証サーバ装置。
5. 前記処理装置は、
   前記登録端末から、公開鍵を含んだ公開鍵証明書発行要求、秘密鍵復元用情報、端末情報、生体情報の読取センサ情報の少なくとも一つを含む情報を受信し、
   公開鍵証明書発行要求と秘密鍵復元用情報に対して、公開鍵証明書を発行し、
   前記登録端末から受信した新たな公開鍵証明書発行要求と秘密鍵復元用情報を前記記憶装置に記憶し、
   前記登録端末へ前記公開鍵証明書を送信する、
   ことを特徴とする請求項１に記載の認証サーバ装置。
6. 前記生体情報は、
   指静脈情報、手の平静脈情報、掌形情報、指紋情報、虹彩情報、音声情報及び顔情報を含む、
   ことを特徴とする請求項１乃至５の何れか一項に記載の認証サーバ装置。
7. 登録端末と、認証端末と、認証サーバ装置と、サービス提供サーバとがネットワークを介して接続された認証システムであって、
   前記認証サーバ装置は記憶装置と処理装置とを具備し、
   前記処理装置は、
   利用者が通知した登録端末に格納されている公開鍵と秘密鍵復元用情報を失効させ、
   前記記憶装置から新たな公開鍵と新たな秘密鍵復元用情報を取得し、前記新たな公開鍵に対して公開鍵証明書を発行し、
   前記認証端末から前記登録端末の端末情報及び読取センサ情報が含まれる秘密鍵復元用情報取得要求を受信し、
   前記記憶装置に格納されている秘密鍵復元用情報から、当該利用者の前記新たな秘密鍵復元用情報を取得し、前記認証端末に送信し、
   前記認証端末から前記新たな秘密鍵復元用情報及び前記認証端末で読取った生体情報から生成された秘密鍵による署名値を受信し、
   前記署名値を前記記憶装置に格納された前記新たな公開鍵証明書で検証し、検証結果を前記サービス提供サーバに送信する、
   ことを特徴とする認証システム。
8. 前記登録端末と、前記認証端末と、前記認証サーバ装置と、前記サービス提供サーバとがネットワークを介して接続された認証システムであって、
   前記認証サーバ装置は前記記憶装置と前記処理装置とを具備し、
   前記処理装置は、
   利用者が通知した前記登録端末に格納されている公開鍵と秘密鍵復元用情報を失効させ、
   前記認証端末から、前記利用者の本人確認完了通知を受信し、
   前記本人確認完了通知を受信すると、前記記憶装置から新たな公開鍵と新たな秘密鍵復元用情報を取得し、前記新たな公開鍵に対して公開鍵証明書を発行し、
   前記認証端末から前記登録端末の端末情報及び読取センサ情報が含まれる秘密鍵復元用情報取得要求を受信し、
   前記記憶装置に格納されている秘密鍵復元用情報から、当該利用者の前記新たな秘密鍵復元用情報を取得し、前記認証端末に送信し、
   前記認証端末から前記新たな秘密鍵復元用情報及び前記認証端末で読取った生体情報から生成された秘密鍵による前記署名値を受信し、
   前記署名値を前記記憶装置に格納された前記新たな公開鍵証明書で検証し、検証結果を前記サービス提供サーバに送信する、
   ことを特徴とする請求項７に記載の認証システム。
9. 前記登録端末、前記認証端末及び前記サービス提供サーバとネットワークを介して接続された認証サーバの認証システムであって、
   前記記憶装置と前記処理装置とを具備し
   前記処理装置は、
   前記登録端末から公開鍵を含んだ公開鍵証明書発行要求、前記秘密鍵復元用情報、端末情報、生体情報の読取センサ情報の少なくとも一つを含む情報を受信する申請受付部と、
   前記公開鍵証明書発行要求と前記秘密鍵復元用情報に対して、公開鍵証明書を発行し
   前記登録端末から受信した新たな前記公開鍵証明書発行要求と秘密鍵復元用情報を前記記憶装置に記憶させ、
   前記登録端末へ発行した前記公開鍵証明書を送信する発行部と、
   前記利用者が通知して前記登録端末の端末情報に基づいて、前記記憶装置に記憶されている公開鍵証明書発行情報から、失効する公開鍵と秘密鍵復元用情報を特定し、
   特定した公開鍵と秘密鍵復元用情報に基づいて、前記利用者が通知した端末に格納されている公開鍵と秘密鍵復元用情報を失効する失効部と、
   前記記憶装置から前記新たな公開鍵と前記新たな秘密鍵復元用情報を取得し、前記新たな公開鍵に対して、失効した前記公開鍵及び前記秘密鍵復元用情報と同一の有効期限を有する公開鍵証明書を発行し、
   前記記憶装置に記憶されている公開鍵証明書発行情報の保存先情報を、前記認証端末から送信される前記登録端末の端末情報に基づいて更新する発行部と、
   前記認証端末から端末情報及び読取センサ情報が含まれる秘密鍵復元用情報取得要求を受信する申請受付部と、
   前記記憶装置に格納されている秘密鍵復元用情報から、当該利用者の前記新たな秘密鍵復元用情報を取得し、前記認証端末に送信する発行部と、
   前記認証端末から前記新たな秘密鍵復元用情報及び前記認証端末で読取った生体情報から生成された秘密鍵による前記署名値を受信する署名検証部と、
   前記署名値を前記記憶装置に格納された前記新たな公開鍵証明書で検証する証明書検証部と、
   検証結果を前記サービス提供サーバに送信する認証結果作成部と、
   前記公開鍵証明書の前記有効期限が満了した場合に、前記記憶装置に記憶された前記新たな公開鍵証明書発行要求と秘密鍵復元用情報を消去する失効部と、
   を有する請求項７に記載の認証システム。
10. 登録端末、認証端末及びサービス提供サーバとネットワークを介して接続された認証サーバの認証方法であって、
    認証サーバは記憶装置と処理装置とを具備し、
    前記処理装置によって、
    利用者が通知した登録端末に格納されている公開鍵と秘密鍵復元用情報を失効する工程と、
    前記記憶装置から新たな公開鍵と新たな秘密鍵復元用情報を取得し、前記新たな公開鍵に対して公開鍵証明書を発行する工程と、
    前記認証端末から前記登録端末の端末情報及び読取センサ情報が含まれる秘密鍵復元用情報取得要求を受信する受信工程と、
    前記記憶装置に格納されている秘密鍵復元用情報から、当該利用者の新たな秘密鍵復元用情報を取得し、前記認証端末に送信する工程と、
    前記認証端末から前記新たな秘密鍵復元用情報及び前記認証端末で読取った生体情報から生成された秘密鍵による署名値を受信する工程と、
    前記署名値を前記記憶装置に格納された前記新たな公開鍵証明書で検証し、検証結果を前記サービス提供サーバに送信する工程と、
    を含む認証方法。

Images