JP7099975B2 - 認証情報管理サーバ装置、認証情報管理システム及び認証情報管理方法 - Google Patents

Description

本発明は、認証情報管理サーバ装置、認証情報管理システム及び認証情報管理方法に関する。

近年、インターネットの利用者は、パソコンやスマートフォン、タブレット端末等の複数の端末を用いて、オンラインバンキングやネットショッピング等の各種ウエブサービスを利用している。ウエブサービスを利用する際には、利用者の認証が必要であり、一般的には、利用者ＩＤ（IDentifier、識別子）とパスワードが用いられる。
しかしながら、安易に設定したパスワードが第三者に推測されてしまう、第三者の不正アクセスによりウエブサービスサーバからパスワードが漏洩してしまうなどして、パスワードが漏洩する事例が多発している。

パスワード認証に替わる利用者認証技術としては、公開鍵暗号を用いたウエブサービスの利用者認証技術も開発されている。斯かる認証技術では、利用者認証の前段階として、利用者が所有する端末が公開鍵暗号の秘密鍵と公開鍵のペアを生成して、秘密鍵を端末に保管し、公開鍵をウエブサービスサーバに登録する。そして、公開鍵をウエブサービスサーバに登録する際に、ウエブサービスサーバが利用者の本人認証を行うこととしている。
ウエブサービスサーバが利用者を認証する際には、ウエブサービスサーバが乱数を生成して利用者の端末に送信し、利用者の端末が秘密鍵を用いて乱数に対して生成した署名をウエブサービスサーバに送信し、ウエブサービスサーバがこの署名を検証する。この署名検証が成功すれば、利用者認証が成功したことになり、利用者はウエブサービスを利用することができる。

しかし、この認証方法では、秘密鍵が不正に持ち出されたり利用されたりすることがないように、端末のセキュア領域に秘密鍵が保管されることが必要である。秘密鍵がセキュア領域に保管されることで、秘密鍵情報が漏洩したり、正規の秘密鍵所有者以外に利用されたり、マルウェアのような不正なプログラムからアクセスされたりすることを防ぐことができる。
しかしながら、秘密鍵が端末のセキュア領域から一切取り出せないとすると、正規の利用者が別の端末からウエブサービスサーバにアクセスすることができないという問題が生じる。すなわち、複数の端末からウエブサービスを利用することが困難になってしまう。

上記の問題を解決するために、ユーザが複数の端末を利用する場合に、端末のセキュア領域に保管される秘密鍵を予め複製しておき、他の端末に送信することで、初期の端末とは別の端末を用いて認証処理を可能にする技術が提案されている。
例えば、本人確認レベルに応じた端末間の秘密鍵複製を可能とするシステムとして、特開２０１８－１３３７３９（特許文献１）に記載の技術がある。この公報には、「本人確認サービスＸサーバ２０ａは、所定の本人確認手続きに従って端末１０ａと端末１０ｂの所有者を確認して、所有者と本人確認レベルと公開鍵とを含んだ所有者証明書１２ａを端末１０ａに、所有者証明書１２ｂを端末１０ｂに発行する。端末１０ａから端末１０ｂに秘密鍵１１ａを複製するときには、端末１０ａは、自身が保有する証明書の所有者と本人確認レベルが同一の所有者証明書を端末１０ｂが保有していることと、当該本人確認レベルが秘密鍵１１ａに関連付けられている本人確認レベルに一致していることとを確認した後に、所有者証明書１２ｂに含まれる公開鍵で暗号化して秘密鍵を送信する。」という記載がある。

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

しかしながら、上記先行技術では、複数の端末で認証を行うことが提案されているものの、端末間での秘密鍵の複製に際して、秘密鍵が通信時に漏洩してしまうリスクが存在するため、各端末に厳重なセキュリティ対策が必要となり、実装負荷が高い。

そこで、本発明は、ユーザが複数の端末を利用する状況において、ユーザの登録負担を減らし、秘密鍵の漏洩リスクを削減し、各ウエブサービスに対応した認証鍵（公開鍵）でオンライン本人確認を実現することを目的とする。

上記課題を解決するために、代表的な本発明の認証情報管理サーバ装置の一つは、通信ネットワークを介して、ユーザ端末と、ウエブサーバ装置とが接続されており、ウエブサーバ装置が提供するサービスに対する登録処理を行う登録処理部と、ウエブサーバ装置が提供するサービスに対する認証処理を行う認証処理部と、サービスへの登録処理及び認証処理の際に用いる認証情報テーブルを格納する認証情報記憶部と、を備え、認証情報テーブルは、ウエブサーバ装置が提供するサービス毎に、少なくともユーザを特定するためのユーザ情報と、公開鍵と、ユーザの生体情報に基づいて生成された秘密鍵復元用情報とを管理する。

本発明は、ユーザが複数の端末を利用する状況において、ユーザの登録負担を減らし、秘密鍵の漏洩リスクを削減し、各ウエブサービスに対応した認証鍵（公開鍵）でオンライン本人確認を実現することができる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

本発明に係る認証情報管理システムの構成を示す図である。 本発明に係る、ユーザが新たなサービスのアクセスを要求する際の登録処理を示すシーケンス図である。 本発明に係る、ユーザが登録済みのサービスのログインを行う際の認証処理を示すシーケンス図である。 本発明の実施例１に係る認証情報テーブルの構成を示す図である。 本発明の実施例１に係る生体情報の登録処理を示すシーケンス図である。 本発明の実施例１に係る登録応答電文の生成処理を示すシーケンス図である。 本発明の実施例１に係る認証応答電文の生成処理を示すシーケンス図である。 本発明の実施例２に係る認証情報テーブルの構成を示す図である。 本発明の実施例２に係る生体情報の登録処理を示すシーケンス図である。 本発明の実施例２に係る登録応答電文の生成処理を示すシーケンス図である。 本発明の実施例２に係る認証応答電文の生成処理を示すシーケンス図である。

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

[本発明の概要]
上述したように、ユーザが複数の端末を利用する状況において、ウエブサービスの追加を安全かつ円滑に行うことを目的とする。よく知られているように、ユーザが新しいウエブサービスを追加するための登録、又は登録済みのサービスのログインを行う際には、本人認証を行う必要がある。ここでは、本人認証とは、サービスの提供を受ける資格を持つ、当該個人であると主張するユーザの真正性を確認する行為を示す。
本発明では、ウエブサービスの円滑な登録及びログインを実現するためには、ユーザの認証情報を含む認証テーブルをサーバ側で保管する。この認証情報の中には、ユーザのＩＤ，サービスを特定するサービス識別子、公開鍵、公開鍵を特定する識別子、及びユーザの生成情報に基づいて生成され、秘密鍵を復元するための「秘密鍵復元情報」等を含む。
ユーザが、新しいウエブサービスの追加に伴う登録、又は登録済みのサービスへのログインを要求するときに、このサーバ側で保管されている秘密鍵復元情報を用いて秘密鍵を復元することで、この秘密鍵での本人認証を行うことができる。
本発明では、この秘密鍵復元用情報がサーバ側で保管されるため、秘密鍵を端末で保管する必要はなく、実装負荷の高い厳重なセキュリティ対策を端末で適用する必要もない。また、ユーザの生体情報を一回取得するだけで、複数の公開鍵や秘密鍵復元情報等を生成して、サーバ側で保管することができる。そのため、ユーザが新しいサービスの追加を要求するたびに、予め保管されている公開鍵を特定のサービス識別子に対して割り当てることで当該サービスへのアクセスをユーザに提供することができるため、ユーザの登録負担を減らすことができる。

本発明の一態様は、公開型生体認証基盤（Ｐｕｂｌｉｃ Ｂｉｏｍｅｔｒｉｃ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ、又は「ＰＢＩ」と呼ぶこともある）に関する。ＰＢＩでは、ユーザの生体情報及び秘密鍵を一方向変換させた状態（元に戻らない形）で、「公開テンプレート」として格納し、登録局（サーバ等）に保管することにより、ユーザは国民ＩＤ基盤、「手ぶら」の決済サービス、パスワードレスのクラウド認証、フィジカルセキュリティなどにおける生体認証を、個々のサービスへの登録を行うことなく、活用することができる。
なお、この「公開テンプレート」をユーザの生体情報の特徴量と合成することで、当該ユーザの秘密鍵を復元することができる。本発明の「秘密鍵復元情報」は、ＰＢＩによる公開テンプレートであってもよく、ユーザの生体情報そのものを暗号化した生体情報テンプレートであってもよい。従って、以下では、「公開テンプレート」や「生体情報テンプレート」等の表現を用いて本発明の実施例を説明するが、この「公開テンプレート」と「生体情報テンプレート」は両方とも、秘密鍵復元用情報の一種である。
以下では、本発明に係るシステム構成及び各種処理の詳細を説明する。

まず、図１～図３を参照して、本発明の実施例１及び実施例２の共通の部分について説明する。

[認証システム１００の構成]
図１は、本発明に係る実施例を実現するための認証システム１００のハードウェアの全体構成を示す図である。

図1に示すように、本システムは、ユーザ端末１１０Ａ、１１０Ｂ（端末１１０Ａと端末１１０Ｂとを特に区別する必要がない場合には、端末１１０と総称する）と、認証情報管理サーバ１２０と、ウエブサービスサーバ１３０Ａ、１３０Ｂ（ウエブサービスサーバ１３０Ａとウエブサービスサーバ１３０Ｂを特に区別する必要がない場合には、ウエブサービスサーバ１３０と総称する）と通信ネットワーク（インターネット、ＬＡＮ等）１４０とから構成される。

ユーザ端末１１０と、認証情報管理サーバ１２０と、ウエブサービスサーバ１３０とが通信ネットワーク１４０を介して接続されており、相互に通信可能である。
なお、図１では、ユーザ端末１１０とウエブサービスサーバ１３０をそれぞれ２つ例示しているが、本発明はこれに限定されず、１つでも、３つ以上でも、任意の数であってもよい。

[ユーザ端末１１０の構成]
ユーザ端末１１０（以下、「端末１１０」ということもある）は、ユーザが利用する端末装置である。ユーザは、ユーザ端末１１０を介して、ウエブサービスサーバ１３０が提供する様々なサービスをアクセスしたり、利用したりすることができる。ユーザ端末１１０は、例えば、スマートフォン、デスクトップコンピュータ、ノートブックコンピュータ、タブレット等、任意のデバイスであってもよい。

図１に示すように、ユーザ端末１１０は、ユーザから指紋や指静脈等の生体情報を取得する、カメラや指紋検出器等のセンサ１１１と、当該生体情報を用いて認証情報管理サーバ１２０に対して認証処理を行う認証モジュール１１２と、対象のサービスをアクセスしたり、利用したりするためのウエブブラウザ１１３及びアプリ１１４と、端末の秘密鍵や、ユーザの認証情報等を安全に保管するためのセキュア領域１１５とを含む。

[認証情報管理サーバ１２０の構成]
認証情報管理サーバ１２０は、端末１１０とウエブサービスサーバ１３０との間の認証処理に用いられる認証情報（図４及び図８参照）を管理するサーバ装置である。図１に示すように、認証情報管理サーバ１２０は、ユーザが新たなサービスへのアクセスを要求する際の登録処理（図２参照）を管理するための登録処理部１２１と、ユーザが登録済みのサービスへとログインする際の認証処理を管理する認証処理部１２２と、ユーザ毎に複数のユーザＩＤ、サービス識別子、公開鍵識別子、及び公開テンプレート識別子等の認証情報を保管する認証情報記憶部１２３とを含む。この認証情報記憶部１２３は、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、フラッシュメモリ（Ｆｌａｓｈ Ｍｅｍｏｒｙ）等の半導体メモリ素子、ハードディスク、光ディスク等の記憶装置によって実現されてもよい。

[ウエブサービスサーバ１３０の構成]
ウエブサービスサーバ１３０は、通信ネットワーク１４０を介して、ウエブサービスをユーザ端末１１０に提供するサーバ装置である。一例として、ウエブサービスサーバ１３０は、銀行や金融機関が運用するウエブサーバ装置であって、オンラインバンキング等のサービスをユーザに提供するものであってもよい。また、図１に示すように、ウエブサービスサーバ１３０は、サービスの登録やログインの処理を行う際のユーザ認証処理を行う認証部１３２と、この認証処理において発生する情報の送受信を管理する業務部１３１とを含む。

以上説明した認証システム１００の構成、本発明の実施例を実現するための構成の一例であり、本発明はこれに限定されない。

[登録処理２００]
次に、図２を参照して、本発明に係る公開鍵の登録処理２００について説明する。

図２は、ユーザが新たなサービス（未登録のサービス）の追加を要求する際の登録処理２００を示すシーケンス図である。ここでの登録処理２００とは、ユーザが、ウエブサービスサーバ１３０が提供するサービスを利用するために、公開鍵を、対象のサービスへ登録する処理である。
なお、以下では、ユーザＩＤやパスワード等の基本ユーザアカウント情報が予めウエブサービスサーバ１３０において登録されていることを前提として、本発明の処理について説明するが、ユーザアカウントがまだ登録されていない場合には、ユーザは既存のアカウント登録手段を用いて、ウエブサービスサーバ１３０に対して初期登録を行ってもよい。

まず、ステップＳ２０１では、端末１１０は、端末１１０のユーザが、ウエブサービスサーバが提供するサービスを使用したいとの旨を示す登録要求をウエブサービスサーバ１３０に送信する。この登録要求には、例えば、端末１１０のユーザがどのサービスを使用したいかを示す情報（サービスの識別子等）を含んでもよい。

次に、ステップＳ２０２では、ウエブサービスサーバ１３０の業務部１３１は、サービスを要求しているユーザを特定するために、ユーザＩＤやパスワード等のレガシー認証情報を要求するレガシー認証要求を端末１１０に送信する。

次に、ステップＳ２０３では、端末１１０は、端末１１０のユーザが入力したユーザＩＤやパスワード等のレガシー認証情報を含む電文を作成し、ウエブサービスサーバ１３０に送信する。

次に、ステップＳ２０４では、ウエブサービスサーバ１３０の業務部１３１は、ユーザが入力したユーザＩＤやパスワード等のレガシー認証情報を含む電文を検証する。当該検証が成功する場合には、サービスを要求しているユーザが特定され、本処理はステップＳ２０５に進む。当該検証が成功しない場合には、ウエブサービスサーバ１３０の業務部１３１は、ユーザのレガシー認証情報が誤っている旨を示す電文をユーザ端末１１０に返信し、ユーザの再入力が要求される。

ステップＳ２０５では、ウエブサービスサーバ１３０の業務部１３１は、検証したユーザの公開鍵の登録（つまり、ユーザが使用したいサービスへの登録）を要求する旨を示す登録処理要求を認証部１３２に送信する。

ステップＳ２０６及びステップＳ２０７では、ウエブサービスサーバ１３０の認証部１３２は、登録対象のサービスへのアクセスを付与するにあたって必要な本人認証を要求する登録要求電文を、業務部１３１を介してユーザ端末１１０に送信する。この登録要求電文は、端末１１０で署名値を生成するためのチャレンジコード（乱数）と、ユーザが所望するサービスを一意に特定するサービス識別子と、ポリシーとを含む。このポリシーとは、生体情報の種類（指静脈や指紋等）や、鍵のビット長等、認証手段の形式を規定するものである。

ステップＳ２０８では、端末１１０は、ウエブサービスサーバ１３０から受信した登録要求電文で指定される情報を含む登録応答電文を生成する。この登録応答電文には、ユーザ公開鍵と、ユーザが所望するサービスのサービス識別子と、ユーザＩＤと、受信したポリシーに従って構成されている生体情報センサの情報と、端末１１０の秘密鍵で証明した署名値とを含む。
なお、この処理の詳細については、図６を参照して後述する。

ステップＳ２０９及びＳ２１０では、端末１１０は、ステップＳ２０８で生成した登録応答電文を、業務部１３１を介してウエブサービスサーバ１３０の認証部１３２に送信する。

ステップＳ２１１では、ウエブサービスサーバ１３０の認証部１３２は、端末１１０から受信した登録応答電文に含まれる署名値を端末１１０の公開鍵に対して検証し、署名値が正しい（つまり、真に端末１１０で生成された）か否かを判定する。この検証が成功する場合には、ユーザの本人認証が承認され（すなわち、公開鍵が信頼できるものであると判定され）、本処理はステップＳ２１２へと進む。なお、この検証が成功しない場合には、ウエブサービスサーバ１３０の認証部１３２は、登録応答電文の情報が誤っている旨を示す電文をユーザ端末１１０に返信し、登録応答電文の再生成が要求される。

ステップＳ２１２では、ウエブサービスサーバ１３０の認証部１３２は、検証が成功した登録応答電文に含まれる公開鍵と公開鍵識別子をユーザＩＤに紐づけて格納し、ユーザが所望するサービスへと登録する。

ステップＳ２１３及びステップＳ２１４では、ウエブサービスサーバ１３０の認証部１３２は、ユーザの公開鍵の登録が完了した旨を示す登録完了通知を端末１１０に送信する。この時点では、ユーザは、所望するサービスへのアクセスが付与され、ウエブサービスサーバ１３０を介して、公開鍵が登録されたサービスを利用することができる。

これにより、ユーザが複数の端末を利用する状況において、ウエブサービスの追加を安全かつ円滑に行うことができる。

[認証処理３００]
次に、図３を参照して、本発明に係る認証処理３００について説明する。

図３は、本発明に係る、ユーザがサービスにログインを行う際の認証処理３００を示すシーケンス図である。ここでの認証処理３００とは、ユーザが、例えば図２の処理で登録処理を済ませたサービスを利用するために、生体情報を用いた本人認証を行い、当該サービスにログインする処理である。

まず、ステップＳ３０１では、端末１１０は、端末１１０のユーザが、ウエブサービスサーバ１３０が提供するサービス（例えば、図２の処理で登録処理を済ませたサービス）にログインしたい旨を示す認証要求をウエブサービスサーバ１３０に送信する。この認証要求は、例えば、端末１１０のユーザがどのサービスにログインしたいかを示す情報（サービスの識別子等）を含んでもよい。

次に、ステップＳ３０２では、ウエブサービスサーバ１３０の業務部１３１は、ステップＳ３０１で送信された認証要求を受信し、認証部１３２に転送する。

次に、ステップＳ３０３及びＳ３０４では、ウエブサービスサーバ１３０の認証部１３２は、ログイン対象のサービスへのアクセスを付与するにあたって必要な本人認証を要求する認証要求電文を、業務部１３１を介してユーザ端末１１０に送信する。この認証要求電文は、端末１１０で署名値を生成するためのチャレンジコード（例えば、乱数、Ｓ／Ｋｅｙ方式のワンタイムパスワード等）と、ユーザが所望するサービスを一意に特定するサービス識別子とを含む。

次に、ステップＳ３０５では、端末１１０は、認証要求電文に指定される情報を含む認証応答電文を生成する。この認証応答電文には、ユーザの公開鍵の公開鍵識別子と、ユーザが所望するサービスのサービス識別子と、ユーザの生体情報から復元した秘密鍵で証明した署名値とを含む。
なお、この処理の詳細については、図７を参照して後述する。

ステップＳ３０６及びＳ３０７では、端末１１０は、ステップＳ３０５で生成した認証応答電文を、ウエブサービスサーバ１３０の業務部１３１を介して認証部１３２に送信する。

次に、ステップ３０８では、ウエブサービスサーバ１３０の認証部１３２は、端末１１０から受信した認証応答電文に含まれる署名値をユーザの公開鍵に対して検証し、署名値が正しいか否かを判定する。この検証が成功する場合には、ユーザの本人認証が承認され（すなわち、図２の登録処理において公開鍵を登録したユーザとログインを要求しているユーザが同一人物であると判定され）、本処理はステップＳ３０９へと進む。なお、この検証が成功しない場合には、ウエブサービスサーバ１３０の認証部１３２は、認証応答電文の情報が誤っている旨を示す電文をユーザ端末１１０に返信し、認証応答電文の再生成が要求される。

ステップＳ３０９及びステップＳ３１０では、ウエブサービスサーバ１３０の認証部１３２は、認証が承認された旨を示す通知を、業務部１３１を介して、端末１１０に送信する。この時点では、対象のサービスに対する認証処理が完了し、当該サービスへのアクセスがユーザに付与される。

これにより、ユーザは、例えば登録処理を行うために使用した端末と別の端末でも、ウエブサービスのログインに伴う認証処理を安全かつ容易に行うことができる。

以下では、図４～図７を参照して、本発明に係る実施例１について説明する。実施例１に係る認証情報テーブル、生体情報登録処理、登録応答電文の生成処理、及び認証応答電文の生成処理は、ウエブサービスサーバが公開型生体認証基盤（Ｐｕｂｌｉｃ Ｂｉｏｍｅｔｒｉｃ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ又はＰＢＩ）を対応するように構成されている場合を前提としている。しかし、本発明はそれに限定されず、ウエブサービスサーバが公開型生体認証基盤に対応しない場合にも適用可能である。その場合における本発明の構成や処理については、実施例２で後述する。

[認証情報テーブル４００の構成]
次に、登録処理及び認証処理に用いられる認証情報について説明する。

図４は、本発明の実施例１に係る認証情報テーブル４００の構成を示す図である。上述したように、認証情報テーブル４００は、例えば図１に示される認証情報管理サーバ１２０の認証情報記憶部１２３に格納され、ウエブサービスサーバが提供するサービスに対する登録処理及び認証処理が行われる際に参照される認証情報を保管するテーブルである。

図４に示すように、認証情報テーブル４００は、ユーザＩＤ４１０と、サービス識別子４２０と、公開鍵識別子４３０と、公開鍵４４０と、公開テンプレート識別子４５０と、公開テンプレート４６０と、状態情報４７０とから構成される。
なお、図４に示すように、認証情報テーブル４００は、１人のユーザに対して、サービス識別子４２０と、公開鍵識別子４３０と、公開鍵４４０と、公開テンプレート識別子４５０と、公開テンプレート４６０と、状態情報４７０とを含むセットを複数備えてよい。また、サービス登録を行う前に、登録及びログインの際に用いられる認証情報を複数管理することで、サービス毎に使い分けることが可能となり、サービスを追加するたびに生体情報による公開鍵の登録処理を繰り返す工程を削減することができる。

ユーザＩＤ４１０は、ウエブサービスサーバ（例えば、図１に示すウエブサービスサーバ１３０）のサービスを使用するユーザを一意に識別するための情報である。このユーザＩＤ４１０は、例えば、ユーザのアカウント情報，文字列、氏名等、ユーザを特定できるものであれば、任意の情報であってもよい。

サービス識別子４２０は、ウエブサービスサーバが提供しているサービスのうち、少なくとも１つのサービスを一意に識別するための情報である。このサービス識別子４２０は、例えば、サービスをアクセスするためのＵＲＬ，ＩＤ，文字列、名称等、サービスを特定できるものであれば、任意の情報であってもよい。

公開鍵識別子４３０は、認証情報テーブル４００において登録されている公開鍵のうち、特定の公開鍵を一意に識別するための情報である。この公開鍵識別子４３０は、例えば、ＩＤ，文字列（例えば「０００１」）、公開鍵の一部等、公開鍵を特定できるものであれば、任意の情報であってもよい。

公開鍵４４０は、ユーザの生体情報から抽出した特徴量に基づいて生成されたものであってもよく、既存の公開鍵暗号方式によって生成されたものであってもよい。
なお、本発明における公開鍵４４０の生成については、図５を参照して後述する。また、図４では、１つのユーザＩＤにつき、２つの公開鍵を例示しているが、本発明はそれに限定されない。公開鍵は、後述するように、ユーザの生体情報を一回取得するだけで任意の数が生成可能であるため、１つのユーザＩＤにつきｎ個の公開鍵を保管することができる。

公開テンプレート識別子４５０は、認証情報テーブル４００において登録されている公開テンプレートのうち、特定の公開テンプレートを一意に識別するための情報である。この公開テンプレート識別子４５０は、例えば、ＩＤ，文字列（例えば「Ａ００１」）等、公開テンプレートを特定できるものであれば、任意の情報であってもよい。

公開テンプレート４６０は、所定の電子署名アルゴリズムを用いて、ユーザから取得した生体情報による特徴量及び秘密鍵に対してソルト（乱数）を付加し、一方向変換させることで生成されたものである。この公開テンプレートは、例えば本発明に係る登録処理及び認証処理を行う際に、ユーザの特徴量と合成することで、ユーザの秘密鍵を端末側で復元することができる。その後、復元した秘密鍵に基づいた署名値を生成し、認証情報管理サーバに送信することで、ユーザの本人検証を行うことができる。
なお、公開テンプレート４６０の生成については、図５を参照して後述する。また、図４では、１つのユーザＩＤにつき、２つの公開テンプレートを例示しているが、本発明はそれに限定されない。公開テンプレートは、後述するように、ユーザの生体情報を一回取得するだけで任意の数が生成可能であるため、１つのユーザＩＤにつきｎ個の公開テンプレートを保管することができる。

状態情報４７０は、認証情報テーブル４００において対応付けられているサービス識別子４２０と、公開鍵識別子４３０と、公開鍵４４０と、公開テンプレート識別子４５０と、公開テンプレート４６０とが有効か無効かを示す情報である。状態情報４７０が有効の場合には、対応付けられている情報が使用可能であり、対応するサービスへのアクセスが登録済みのユーザに利用可能であることを示す。一方、状態情報４７０が無効の場合には、対応付けられている情報が使用不可であり、対応するサービスへのアクセスがユーザに提供されていないことを示す（例えば、特定の公開鍵がまだ割り当てられていない場合や、端末の紛失に伴って、サービスが失効された場合）。

このように構成された認証情報テーブル４００を認証情報管理サーバ（例えば、図１に示す認証情報管理サーバ１２０）に保管することで、ユーザが新しいサービスの追加を要求するたびに、予め保管されている公開鍵を特定のサービス識別子に対して割り当てることで当該サービスへのアクセスをユーザに提供することができ、ユーザの登録負担を減らすことができる。

[生体情報登録処理５００]
次に、図５を参照して、実施例１に係る生体情報の登録処理について説明する。図５は、ユーザ端末１１０で取得するユーザの生体情報に基づいた公開鍵及び公開テンプレートを認証情報管理サーバ１２０の認証情報記憶部１２３の認証情報テーブルに登録する処理を示す図である。

まず、ステップＳ５０１では、端末１１０のセンサ１１１は、ユーザからの生体情報を取得する。ここで、生体情報とは、人間を一意に識別するために用いられる身体的な特徴や行動的な特徴を示すデータである。一例として、生体情報は指紋情報、指静脈情報、手の平静脈情報、掌形情報、虹彩情報、音声情報及び顔情報等の身体的な生体情報や、歩行情報、指圧情報、端末１１０の持ち方に関する情報等の行動的な生体情報を含む。一例として、センサ１１１は、例えばユーザの指を撮影することで指紋の画像を生体情報として取得してもよい。

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

次に、ステップＳ５０３では、秘密鍵と公開鍵のペアが生成される。ここでの秘密鍵と公開鍵は、例えば、ユーザの生体情報から抽出した特徴量に基づいて生成されたものであってもよく、既存の公開鍵暗号方式によって生成されたものであってもよい。
なお、ここでは、生体情報から抽出した１つの特徴量に対して、秘密鍵と公開鍵のペアはｎ個生成されてもよい。後述するように、秘密鍵と公開鍵を複数生成しておくことで、複数の公開テンプレートを作成することが可能となる。

ステップＳ５０４では、ステップＳ５０５で生成された秘密鍵とステップＳ５０２で抽出された特徴量は一方向変換（元の情報を復元することが不可能であることが数学的に証明されている変換）される。具体的には、ユーザ端末１１０の認証モジュール１１２は、所定の電子署名アルゴリズム（例えばＳｃｈｎｏｒｒ署名等）を用いて、ステップ５０２で取得した特徴量及び秘密鍵に対してソルト（乱数）を付加し、一方向変換させることで公開テンプレート（秘密鍵復元用情報、又はＰＢＩテンプレートと呼ぶこともある）を生成する。
上述したように、ここでは、ステップＳ２０４で生成された複数の秘密鍵のそれぞれと、生体情報から抽出した特徴量とを一緒に一方向変換させることで、公開テンプレートを複数生成することができる。例えば、この手順が４回行われると、４つの秘密鍵と４つの公開鍵と４つの公開テンプレートが生成される。このように、サービスを追加する際に、予め登録しておいた公開テンプレートに対応する公開鍵をサービス識別子に対して割り当てることでユーザの登録負担を減らし、各ウエブサービスに対応した認証鍵（公開鍵）でオンライン本人認証を実現することができる。

次に、ステップＳ５０５では、端末１１０の認証モジュール１１２は、ステップＳ５０３で生成した公開鍵と、ステップＳ５０４で生成した公開テンプレートとを含む登録要求を生成し、認証情報管理サーバ１２０に送信する。

次に、ステップＳ５０６では、認証情報管理サーバ１２０は、ステップＳ５０５で送信された登録要求を受信する。

次に、ステップＳ５０７では、登録要求を受信した認証情報管理サーバ１２０の登録処理部１２１は、登録要求に含まれる公開鍵と、公開テンプレートとを、認証情報管理サーバ１２０の認証情報記憶部１２３の認証情報テーブル（例えば、図４の認証情報テーブル４００）に登録する。
なお、登録処理部１２１は、受信した公開テンプレートと公開鍵の数に応じて、この処理をｎ回行ってもよい。このように、図４に示す認証情報テーブルが生成される。

次に、ステップＳ５０８では、認証情報管理サーバ１２０の登録処理部１２１は、公開テンプレートと公開鍵が登録された旨を示す登録結果を端末１１０に送信する。

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

このように、実施例1では、ユーザの生体情報を取得し、生体情報の特徴量に基づいた公開鍵及び公開テンプレートを予め認証情報テーブルに保管している。これにより、ユーザが新しいサービスの追加を要求するたびに、予め保管されている公開鍵を特定のサービス識別子に対して割り当てることが可能となる。この結果、ユーザの新しいサービスへのアクセスを円滑に提供することができ、ユーザの登録負担を減らすことができる。

[登録応答電文の生成処理６００]
次に、図６を参照して、本発明の実施例１に係る登録応答電文の生成処理６００について説明する。

図６は、本発明の実施例１に係る登録応答電文の生成処理６００を示すシーケンス図である。ここでの登録応答電文の生成処理６００とは、ユーザが新しいサービスを追加する申請を行う際に、ウエブサービスサーバ１３０に対する本人認証を行うための登録応答電文を作成する処理である。具体的には、この処理では、ユーザは、予め登録された公開鍵を、認証情報テーブルにおいて所望のサービス識別子に対して割り当ててもらい、当該公開鍵を含む登録応答電文をウエブサービスサーバ１３０に送信することで、公開鍵が割り当てられたサービスへのアクセスを付与してもらうことができる。
なお、図６に示す登録応答電文の生成処理６００は、図２の「登録応答電文生成」（ステップＳ２０８）の詳細な処理に該当するものである。従って、ウエブサービスサーバが公開型生体認証基盤に対応している場合において、図２の公開鍵登録処理のＳ２０７が完了すると、図６に示す処理が始まり、図６に示す処理が完了すると、図２のＳ２０９に進む。

まず、ステップＳ６０１では、端末１１０は、認証情報管理サーバ１２０の認証情報テーブルにおいて（例えば、図５のＳ５０７で）予め登録された未使用の公開鍵を、（例えば、図２のＳ２０１で）指定したサービス識別子に対して割り当て（対応付ける）を要求する「公開鍵割り当て要求」を認証情報管理サーバ１２０の登録処理部１２１に送信する。この公開鍵割り当て要求には、当該要求を送信したユーザのユーザＩＤとサービス識別子が含まれる。

次に、ステップＳ６０２では、認証情報管理サーバ１２０の登録処理部１２１は、端末１１０から受信した公開鍵割り当て要求に含まれるユーザＩＤに対応し、未使用（すなわち、対応する公開鍵がまだ割り当てられていない）公開テンプレートを、認証情報管理サーバ１２０の認証情報記憶部１２３に格納される認証情報テーブルの中から選択する。

次に、ステップＳ６０３では、認証情報管理サーバ１２０の登録処理部１２１は、ステップＳ６０２で選択された公開テンプレートと、認証情報管理サーバ１２０で生成されたチャレンジコードとを含む認証要求を端末１１０に送信する。

次に、ステップＳ６０４では、端末１１０は、ステップＳ６０３で登録処理部１２１が送信した認証要求を受信し、公開テンプレート及びチャレンジコードを取得する。

次に、ステップＳ６０５では、端末１１０のセンサ１１１は、ユーザの生体情報を取得する。ここでの生体情報の取得は、例えば図５のステップＳ５０１と実質的に同様である。

次に、ステップＳ６０６では、端末１１０のセンサ１１１は、ステップＳ６０５で取得した生体情報から、生体情報の特徴量を抽出する。ここでの生体情報特徴量の取得は、例えば図５のステップＳ５０２と実質的に同様である。

次に、ステップＳ６０７では、端末１１０の認証モジュール１１２は、ステップＳ６０４で取得した公開テンプレートと、ステップＳ６０６で抽出した生体情報の特徴量とを合成することで、ユーザの秘密鍵を復元させる。

次に、ステップＳ６０８では、端末１１０の認証モジュール１１２は、ステップＳ６０７で復元した秘密鍵を、ステップＳ６０４で取得したチャレンジコードに対して証明することで、公開テンプレートを登録したユーザと、ステップ６０５で生体情報が取得されたユーザが同一人物であることを示す署名値を生成する。

次に、ステップＳ６０９では、端末１１０は、ステップＳ６０８で生成した署名値と、ユーザが使用したいサービスのサービス識別子とを含む認証応答を生成し、認証情報管理サーバ１２０に送信する。

次に、ステップＳ６１０では、認証情報管理サーバ１２０の登録処理部１２１は、ステップＳ６０９で生成された認証応答に含まれる署名値を端末１１０の公開鍵に対して検証し、署名値が正しい（つまり、真に端末１１０で生成された）か否かを判定する。この検証が成功する場合には、公開鍵の割り当てを要求しているユーザが登録済みのユーザと同一人物であると判定され、本処理はステップ６１１へと進む。
なお、この検証が成功しない場合には、認証応答の情報が誤っている旨を示す電文がユーザ端末１１０に返信され、認証応答の再生成が要求される。

次に、ステップＳ６１１では、認証情報管理サーバ１２０の登録処理部１２１は、認証情報テーブルにおいて、未使用の（すなわち、まだ割り当てられていない）公開鍵をステップＳ６０９で指定されたサービス識別子に対して割り当てる（対応付ける）。
なお、サービス識別子に対して公開鍵が割り当てられると、認証情報テーブルにおいて、当該のサービス識別子に対応する状況が「無効」から「有効」へと変更される。

次に、ステップＳ６１２では、認証情報管理サーバ１２０の登録処理部１２１は、公開鍵の識別子に対する割り当てが完了した旨を示し、ステップＳ６１１で割り当てられた公開鍵を含む割り当て完了通知を端末１１０へと送信する。

次に、ステップＳ６１３では、端末１１０は、ステップＳ６１２で送信された割り当て完了通知を受信し、公開鍵を取得する。

次に、ステップＳ６１４では、端末１１０は、ステップＳ６０４で取得した公開テンプレートとステップＳ６１３で取得した公開鍵をセキュア領域（例えば図１に示すセキュア領域１１５）に格納してもよい。ただし、端末１１０は公開テンプレートと公開鍵をセキュア領域に格納する必要はない。例えば、端末１１０は、公開鍵をＲＡＭ等のメモリに一時的に保存し、公開鍵の登録が完了した旨を示す登録完了通知を（例えば、図２のＳ２１４において）受信すると、当該公開テンプレートと公開鍵を削除してもよい。

次に、ステップＳ６１５では、端末１１０は、ステップＳ６１３で取得した公開鍵と、ユーザが所望するサービスのサービス識別子と、ユーザＩＤと、受信したポリシーに従って構成されている生体情報センサの情報と、端末１１０の秘密鍵で証明した署名値とを含む登録応答電文を生成する。
その後、本処理は図２に示すステップＳ２０９へと進み、ステップＳ２０９～Ｓ２１４を行うことで、公開鍵をウエブサービスサーバに対して登録する。

このように、予め保管されている公開鍵を特定のサービス識別子に対して割り当てることで当該サービスへのアクセスをユーザに提供することができるため、ユーザの登録負担を減らすことができる。

[認証応答電文の生成処理７００]
次に、図７を参照して、本発明の実施例１に係る認証応答電文の生成処理７００について説明する。

図７は、本発明の実施例１に係る認証応答電文の生成処理７００を示すシーケンス図である。ここでの認証応答電文の生成処理７００とは、ユーザが、例えば図２の処理で登録処理を済ませたサービスを利用するために、生体情報を用いた本人認証を行い、当該サービスにログインするための認証応答電文を生成する処理である。
なお、図７に示す認証応答電文の生成処理７００は、図３の「認証応答電文生成」（ステップＳ３０５）の詳細な処理に該当するものである。従って、ウエブサービスサーバが公開型生体認証基盤に対応している場合において、図３の認証処理のＳ３０４が完了すると、図７に示す処理が始まり、図７に示す処理が完了すると、図３のＳ３０６に進む。

まず、ステップＳ７０１では、ユーザ端末１１０の認証モジュール１１２は、Ｓ３０４に含まれるサービス識別子に対応する公開テンプレートに関する公開テンプレート要求を、認証情報管理サーバ１２０の認証処理部１２２に送信する。この公開テンプレート要求には、ユーザのユーザＩＤと、対象のサービスを指定するサービス識別子が含まれる。

次に、ステップＳ７０２では、認証情報管理サーバ１２０の認証処理部１２２は、認証情報記憶部１２３から、ステップＳ７０２で受信した公開テンプレート要求に含まれるユーザＩＤとサービス識別子に対応付けられている公開テンプレートを取得する。

次に、ステップＳ７０３では、認証情報管理サーバ１２０の認証処理部１２２は、ステップＳ７０２で取得した公開テンプレートを含む公開テンプレート応答を端末１１０に送信する。

次に、ステップＳ７０４では、ユーザ端末１１０の認証モジュール１１２は、ステップＳ７０３で送信された公開テンプレート応答を受信し、公開テンプレートを取得する。

次に、ステップＳ７０５では、端末１１０のセンサ１１１は、ユーザの生体情報を取得する。ここでの生体情報の取得は、例えば図５のステップＳ５０１と実質的に同様である。

次に、ステップＳ７０６では、端末１１０のセンサ１１１は、ステップＳ７０５で取得した生体情報から、生体情報の特徴量を抽出する。ここでの生体情報特徴量の取得は、例えば図５のステップＳ５０２と実質的に同様である。

次に、ステップＳ７０７では、端末１１０の認証モジュール１１２は、ステップＳ７０４で取得した公開テンプレートと、ステップＳ７０６で抽出した生体情報の特徴量とを合成することで、ユーザの秘密鍵を復元させる。

次に、ステップＳ７０８では、端末１１０の認証モジュール１１２は、ステップＳ７０７で復元した秘密鍵を、図３のステップＳ３０４で取得したチャレンジコードに対して証明することで、公開テンプレートを登録したユーザと、ステップ７０５で生体情報が取得されたユーザが同一人物であることを示す署名値を生成する。

次に、ステップＳ７０９では、端末１１０の認証モジュール１１２は、ユーザの公開鍵の公開鍵識別子と、ユーザが所望するサービスを特定するサービス識別子と、端末１１０の秘密鍵で証明した署名値とを含む認証応答電文を生成する。
その後、本処理は図３に示すステップＳ３０６へと進み、ステップＳ３０６～Ｓ３１０を行うことで、登録済みのサービスにログインすることができる。

これにより、ユーザは、例えば登録処理を行うために使用した端末と別の端末でも、ウエブサービスのログインに伴う認証処理を安全かつ容易に行うことができる。

以下では、図８～図１１を参照して、本発明に係る実施例２について説明する。実施例２に係る認証情報テーブル、生体情報登録処理、登録応答電文の生成処理、及び認証応答電文の生成処理は、ウエブサービスサーバが公開型生体認証基盤（Ｐｕｂｌｉｃ Ｂｉｏｍｅｔｒｉｃ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ又はＰＢＩ）を対応するように構成されていない場合を前提としている。実施例２に係る処理により、本発明を任意のウエブサービスサーバに対して適用することが可能となり、ウエブサービスサーバの構成に依存せずに、複数の端末が利用される場合におけるサービス追加に伴う登録及び認証処理を円滑に行うことができる。

[認証情報テーブル８００の構成]
次に、登録処理及び認証処理に用いられる認証情報について説明する。

図８は、本発明の実施例２に係る認証情報テーブル８００の構成を示す図である。上述したように、認証情報テーブル８００は、例えば図１に示される認証情報管理サーバ１２０の認証情報記憶部１２３に格納され、ウエブサービスサーバが提供するサービスに対する登録処理及び認証処理が行われる際に参照される認証情報を保管するテーブルである。
なお、図８の認証情報テーブル８００の構成は、図４の認証情報テーブル４００の構成と実質的に同様であるため、以下では、認証情報テーブル８００と認証情報テーブル４００の異なる点を中心に説明し、同様の構成要素の説明を省略する。

認証情報テーブル８００は、公開テンプレートと、公開テンプレート識別子の代わりに、生体情報テンプレート８２０と、生体情報テンプレート識別子８３０とを有する点において、図４の認証情報テーブル４００と異なる。図８に示すように、認証情報テーブル８００は、ユーザＩＤ８１０と、生体情報テンプレート８２０と、生体情報テンプレート識別子８３０と、サービス識別子８４０と、公開鍵８５０と、公開鍵識別子８６０と、秘密鍵８６４と、秘密鍵識別子８６８と、状態情報８７０とから構成される。
なお、ユーザＩＤ８１０と、サービス識別子８４０と、公開鍵８５０と、公開鍵識別子８６０と、状態情報８７０とは、実質的に、図４の認証情報テーブル４００のユーザＩＤ４１０と、サービス識別子４２０と、公開鍵４４０と、公開鍵識別子４３０と、状態情報４７０とに同じであるため、その説明を省略する。

生体情報テンプレート８２０は、ユーザから取得した生体情報の特徴量そのものを所定の暗号方式で暗号化した情報である。この生体情報テンプレート８２０を、本発明に係る登録処理及び認証処理を行う際に、ユーザの端末で読み取った生体情報テンプレートと保管している生体情報テンプレートの照合を行うことにより、秘密鍵の保持者であるかを確認する。このため、生体情報テンプレート８２０は、秘密鍵をアクティベートするための「秘密鍵復元用情報」として機能する。
なお、この生体情報テンプレート８２０は、秘密鍵を生成するための特徴量そのもの含むため、この生体情報テンプレートを認証情報管理サーバに保管することは、ユーザの秘密鍵自体を認証情報管理サーバで保管することに等しい。この点において、生体情報テンプレート８２０は上述した公開テンプレートと異なる。
また、生体情報テンプレート８２０は、ユーザの生体情報のユニークな特徴量そのものを含むため、上述した公開テンプレートと異なり、１人のユーザに対して１つしか保管されない。
なお、生体情報テンプレート８２０の生成については、図９を参照して後述する。

生体情報テンプレート識別子８３０は、認証情報テーブル８００において登録されている生体情報テンプレートのうち、特定の生体情報テンプレートを一意に識別するための情報である。この生体情報テンプレート識別子８３０は、例えば、ＩＤ，文字列（例えば「０１２３４」）等、生体情報テンプレートを特定できるものであれば、任意の情報であってもよい。
また、上述したように、秘密鍵８６４は、ユーザの生体情報から抽出した特徴量に基づいて生成されたものであってもよく、既存の公開鍵暗号方式によって生成されたものであってもよい。この秘密鍵８６４は、例えば、後述する図９のステップＳ９０６でユーザ端末から送信される秘密鍵であってもよい。
秘密鍵識別子８６８は、認証情報テーブル８００において登録されている秘密鍵のうち、特定の秘密鍵を一意に識別するための情報である。この秘密鍵識別子８６８は、例えば、ＩＤ，文字列（例えば「Ａ１００」）、秘密鍵の一部等、秘密鍵を特定できるものであれば、任意の情報であってもよい。

実施例２においては、このように構成された認証情報テーブル８００を認証情報管理サーバ（例えば、図１に示す認証情報管理サーバ１２０）に保管することで、ユーザが新しいサービスの追加を要求するたびに、予め保管されている公開鍵を特定のサービス識別子に対して割り当てることができる。これにより、新しいサービスへのアクセスをユーザに円滑に提供することができ、ユーザの登録負担を減らすことができる。

[生体情報登録処理９００]
次に、図９を参照して、実施例２に係る生体情報の登録処理９００について説明する。図９は、ユーザ１１０で取得するユーザの生体情報に基づいた公開鍵及び生体情報テンプレートを認証情報管理サーバ１２０の認証情報記憶部１２３の認証情報テーブルに登録する処理を示す図である。

まず、ステップＳ９０１では、端末１１０のセンサ１１１は、ユーザからの生体情報を取得する。上述したように、ここでの生体情報とは、人間を一意に識別するために用いられる身体的な特徴や行動的な特徴を示すデータである。一例として、生体情報は指紋情報、指静脈情報、手の平静脈情報、掌形情報、虹彩情報、音声情報及び顔情報等の身体的な生体情報や、歩行情報、指圧情報、端末１１０の持ち方に関する情報等の行動的な生体情報を含む。

次に、ステップＳ９０２では、端末１１０のセンサ１１１は、ステップＳ９０１で取得した生体情報から、当該生体情報の特徴量を抽出する。上述したように、ここでは、特徴量とは、生体情報の特徴や特性を数式化したデータ構造（いわゆるメタデータ）を意味する情報である。一例として、取得された生体情報が指紋画像である場合、撮影された指紋の模様を数式的に示す指紋メタデータを特徴量として抽出してもよい。ここでは、生体情報の特徴量抽出は、既存の特徴量抽出の手段によって行われてもよい。

次に、ステップＳ９０３では、秘密鍵と公開鍵のペアが生成される。ここでの秘密鍵と公開鍵は、例えば、ユーザの生体情報から抽出した特徴量に基づいて生成されたものであってもよく、既存の公開鍵暗号方式によって生成されたものであってもよい。
なお、ここでは、生体情報から抽出した１つの特徴量に対して、秘密鍵と公開鍵のペアはｎ個生成されてもよい。

ステップＳ９０４では、認証モジュール１１２は、ステップＳ９０２で抽出した特徴量を所定の暗号方式で暗号化することで、保護化した生体情報テンプレートを生成する。このテンプレート保護技術として、例えば暗号化関数、落とし戸関数、秘密分数関数、ゼロ知識証明プロトコル、ブラインド署名、プロキシネットワーク、偽の情報、機械可読形式のプライバシー言語等、生体情報の種類によって保護手段を適宜に選択してもよい。

次に、ステップＳ９０５では、認証情報管理サーバ１２０は、端末１１０との間で安全な鍵共有セッションを開始する。
次に、ステップＳ９０６では、端末１１０の認証モジュール１１２は、ステップＳ９０３で生成した公開鍵と秘密鍵、ステップＳ９０４で生成した生体情報テンプレートとを含む登録要求を生成し、認証情報管理サーバ１２０に送信する。

次に、ステップＳ９０７では、認証情報管理サーバ１２０は、ステップＳ９０６で送信された登録要求を受信する。

次に、ステップＳ９０８では、登録要求を受信した認証情報管理サーバ１２０の登録処理部１２１は、登録要求に含まれる公開鍵と秘密鍵、生体情報テンプレートとを、認証情報管理サーバ１２０の認証情報記憶部１２３の認証情報テーブル（例えば、図８の認証情報テーブル８００）に登録する。
なお、登録処理部１２１は、受信した公開鍵の数に応じて、この処理をｎ回行ってもよい。このように、図８に示す認証情報テーブルが生成される。

次に、ステップＳ９０９では、認証情報管理サーバ１２０の登録処理部１２１は、生体情報テンプレートと公開鍵が登録された旨を示す登録結果を端末１１０に送信する。

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

このように、ユーザの生体情報を取得し、生体情報の特徴量に基づいた公開鍵と、生体情報そのものを暗号化した生体情報テンプレートを予め認証情報テーブルに保管しておくことで、ユーザが新しいサービスの追加を要求するたびに、予め保管されている公開鍵を特定のサービス識別子に対して割り当てることで当該サービスへのアクセスをユーザに提供することができる、ユーザの登録負担を減らすことができる。

[登録応答電文の生成処理１０００]
次に、図１０を参照して、本発明の実施例２に係る登録応答電文の生成処理１０００について説明する。

図１０は、本発明の実施例２に係る登録応答電文の生成処理１０００を示すシーケンス図である。ここでの登録応答電文の生成処理１０００とは、ユーザが新しいサービスを追加する申請を行う際に、ウエブサービスサーバ１３０に対する本人認証を行うための登録応答電文を作成する処理である。具体的には、この処理では、ユーザは、予め登録された公開鍵を、認証情報テーブルにおいて所望のサービス識別子に対して割り当ててもらい、当該公開鍵を含む登録応答電文をウエブサービスサーバ１３０に送信することで、公開鍵が割り当てられたサービスへのアクセスを付与してもらうことができる。
なお、図１０に示す登録応答電文の生成処理１０００は、図２の「登録応答電文生成」（ステップＳ２０８）の詳細な処理に該当するものである。従って、ウエブサービスサーバが公開型生体認証基盤に対応しない場合において、図２の公開鍵登録処理のＳ２０７が完了すると、図１０に示す処理が始まり、図１０に示す処理が完了すると、図２のＳ２０９に進む。

実施例２に係る登録応答電文の生成処理１０００では、公開テンプレートの代わりに、生体情報テンプレートを用いて本人認証を行う点において、実施例１に係る登録応答電文の生成処理と異なる。

まず、ステップＳ１００１では、端末１１０は、認証情報管理サーバ１２０の認証情報テーブルにおいて（例えば、図９のＳ９０８で）予め登録された未使用の公開鍵を、（例えば、図２のＳ２０１で）指定したサービス識別子に対して割り当て（対応付ける）を要求する公開鍵割り当て要求を認証情報管理サーバ１２０の登録処理部１２１に送信する。この公開鍵割り当て要求には、当該要求を送信したユーザのユーザＩＤとサービス識別子が含まれる。

次に、ステップＳ１００２では、認証情報管理サーバ１２０の登録処理部１２１は、端末１１０のユーザの本人認証を要求する認証要求を端末１１０に送信する。

次に、ステップＳ１００３では、端末１１０の認証モジュール１１２は、認証情報管理サーバ１２０の登録処理部１２１からの認証要求を受信すると、センサ１１１は、ユーザの生体情報を取得する。ここでの生体情報の取得は、例えば図９のステップＳ９０１と実質的に同様である。

次に、ステップＳ１００４では、端末１１０のセンサ１１１は、ステップＳ６０５で取得した生体情報から、生体情報の特徴量を抽出する。ここでの生体情報特徴量の取得は、例えば図９のステップＳ９０２と実質的に同様である。

次に、ステップＳ１００５では、端末１１０の認証モジュール１１２は、ステップＳ１００４で抽出した特徴量を所定の暗号方式で暗号化することで、保護化した生体情報テンプレートを生成する。このテンプレート保護技術として、例えば暗号化関数、落とし戸関数、秘密分数関数、ゼロ知識証明プロトコル、ブラインド署名、プロキシネットワーク、偽の情報、機械可読形式のプライバシー言語等、生体情報の種類によって保護手段を適宜に選択してもよい。

次に、ステップＳ１００６では、端末１１０の認証モジュール１１２は、ステップＳ１００５で生成した生体情報テンプレートと、ユーザが使用したいサービスのサービス識別子とを含む認証応答を生成し、認証情報管理サーバ１２０に送信する。

次に、ステップＳ１００７では、認証情報管理サーバ１２０の登録処理部１２１は、ステップＳ１００６で端末１１０から受信した生体情報テンプレートと、予め認証情報記憶部の認証情報テーブル（例えば、図８の認証情報テーブル８００）に登録された生体情報テンプレートとを照合し、一致するか否かを判定する。端末１１０から受信した生体情報テンプレートと、認証情報テーブルに登録された生体情報テンプレートとが一致する場合には、本人認証が成功し、本処理がステップＳ１００８に進む。
なお、端末１１０から受信した生体情報テンプレートと、認証情報テーブルに登録された生体情報テンプレートとが一致しない場合には、本人認証が失敗し、認証応答の情報が誤っている旨を示す電文がユーザ端末１１０に返信され、認証応答の再生成が要求される。

次に、ステップＳ１００８では、認証情報管理サーバ１２０の登録処理部１２１は、認証情報テーブルにおいて、未使用の（すなわち、まだ割り当てられていない）公開鍵をステップＳ１００６で指定されたサービス識別子に対して割り当てる。
なお、サービス識別子に対して公開鍵が割り当てられると、認証情報テーブルにおいて、当該のサービス識別子に対応する状況が「無効」から「有効」へと変更される。

次に、ステップＳ１００９では、認証情報管理サーバ１２０の登録処理部１２１は、公開鍵がサービス識別子に対して割り当てられた旨を示し、ステップＳ１００８で割り当てられた公開鍵を含む割り当て完了通知を端末１１０へと送信する。

次に、ステップＳ１０１０では、端末１１０の認証モジュール１１２は、ステップＳ１００９で送信された割り当て完了通知を受信し、公開鍵を取得する。

次に、ステップＳ１０１１では、端末１１０の認証モジュール１１２は、ステップＳ１０１０で取得した公開鍵をセキュア領域（例えば図１に示すセキュア領域１１５）に格納してもよい。ただし、端末１１０は公開鍵をセキュア領域に格納する必要はない。例えば、端末１１０は、公開鍵をＲＡＭ等のメモリに一時的に保存し、公開鍵の登録が完了した旨を示す登録完了通知を（例えば、図２のＳ２１４において）受信すると、当該公開鍵を削除してもよい。

次に、ステップＳ１０１２では、端末１１０の認証モジュール１１２は、ステップＳ１０１０で取得した公開鍵と、ユーザが所望するサービスのサービス識別子と、ユーザＩＤと、受信したポリシーに従って構成されている生体情報センサの情報とを含む登録応答電文を生成する。
その後、本処理は図２に示すステップＳ２０９へと進み、ステップＳ２０９～Ｓ２１４を行うことで、公開鍵をウエブサービスサーバに対して登録する。

このように、予め保管されている公開鍵を特定のサービス識別子に対して割り当てることで当該サービスへのアクセスをユーザに提供することができるため、ユーザの登録負担を減らすことができる。

[認証応答電文の生成処理１１００]
次に、図１１を参照して、本発明の実施例２に係る認証応答電文の生成処理１１００について説明する。
図１１は、本発明の実施例２に係る認証応答電文の生成処理１１００を示すシーケンス図である。ここでの認証応答電文の生成処理とは、ユーザが、例えば図２の処理で登録処理を済ませたサービスを利用するために、生体情報を用いた認証処理を行い、当該サービスにログインするための認証応答電文を生成する処理である。
なお、図１１に示す認証応答電文の生成処理１１００は、図３の「認証応答電文生成」（ステップＳ３０５）の詳細な処理に該当するものである。従って、ウエブサービスサーバが公開型生体認証基盤に対応しない場合において、図３の認証処理のＳ３０４が完了すると、図１１に示す処理が始まり、図１１に示す処理が完了すると、図３のＳ３０６に進む。

実施例２に係る認証応答電文の生成処理１１００では、公開テンプレートの代わりに、生体情報テンプレートを用いて本人認証を行う点において、実施例１に係る認証応答電文の生成処理と異なる。

まず、ステップＳ１１０１では、ユーザ端末１１０の認証モジュール１１２は、秘密鍵を要求する秘密鍵要求を認証情報管理サーバ１２０の認証処理部１２２に送信する。この秘密鍵要求には、ユーザのユーザＩＤと、対象のサービスを指定するサービス識別子が含まれる。

次に、ステップＳ１１０２では、認証情報管理サーバ１２０の認証処理部１２２は、端末１１０のユーザの本人認証を要求する認証要求を端末１１０に送信する。

次に、ステップＳ１１０３では、端末１１０のセンサ１１１は、ユーザの生体情報を取得する。ここでの生体情報の取得は、例えば図９のステップＳ９０１と実質的に同様である。

次に、ステップＳ１１０４では、端末１１０のセンサ１１１は、ステップＳ１１０３で取得した生体情報から、生体情報の特徴量を抽出する。ここでの生体情報特徴量の取得は、例えば図９のステップＳ９０２と実質的に同様である。

次に、ステップＳ１１０５では、端末１１０の認証モジュール１１２は、ステップＳ１１０４で抽出した特徴量を所定の暗号方式で暗号化することで、保護化した生体情報テンプレートを生成する。このテンプレート保護技術として、例えば暗号化関数、落とし戸関数、秘密分数関数、ゼロ知識証明プロトコル、ブラインド署名、プロキシネットワーク、偽の情報、機械可読形式のプライバシー言語等、生体情報の種類によって保護手段を適宜に選択してもよい。

次に、ステップＳ１１０６では、端末１１０の認証モジュール１１２は、ステップＳ１１０５で生成した生体情報テンプレートと、ユーザが使用したいサービスのサービス識別子とを含む認証応答を生成し、認証情報管理サーバ１２０に送信する。

次に、ステップＳ１1０７では、認証情報管理サーバ１２０の登録処理部１２１は、ステップＳ１１０６で端末１１０から受信した生体情報テンプレートと、予め認証情報記憶部の認証情報テーブル（例えば、図８の認証情報テーブル８００）に登録された生体情報テンプレートとを照合し、一致するか否かを判定する。端末１１０から受信した生体情報テンプレートと、認証情報テーブルに登録された生体情報テンプレートとが一致する場合には、本人認証が成功し、本処理がステップＳ１１０８に進む。
なお、端末１１０から受信した生体情報テンプレートと、認証情報テーブルに登録された生体情報テンプレートとが一致しない場合には、本人認証が失敗し、認証応答の情報が誤っている旨を示す電文がユーザ端末１１０に返信され、認証応答の再生成が要求される。

次に、ステップＳ１１０８では、認証情報管理サーバ１２０は、端末１１０との間で安全な鍵共有セッションを開始する。この鍵共有セッションは、通信途中でデータが改竄されることや通信相手が入れ替わってしまうことがないことを保証する通信プロトコルである。ここでの鍵共有セッションは、例えば、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）やＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）等、適宜に選択されてもよい。

次に、ステップＳ１１０９では、認証情報管理サーバ１２０の登録処理部１２１は、ステップＳ１１０７で検証したユーザのユーザＩＤとサービス識別子に対応する秘密鍵を取得する。その後、登録処理部１２１は、復元した秘密鍵を既存の暗号方式で暗号化する。

次に、ステップＳ１１１０では、認証情報管理サーバ１２０の登録処理部１２１は、ステップＳ１１０９で暗号化した秘密鍵を含む秘密鍵応答を生成し、この秘密鍵応答をＳ１１０８で確立させた安全な鍵共有セッションを介して、端末１１０に送信する。

次に、ステップＳ１１１１では、端末１１０の認証モジュール１１２は、認証情報管理サーバ１２０からの秘密鍵応答を受信し、復号化し、秘密鍵を取得する。その後、認証モジュール１１２は、この秘密鍵を、図３のステップＳ３０４で取得したチャレンジコードに対して署名することで、生体情報テンプレートを登録したユーザと、ステップＳ１１０３で生体情報が取得されたユーザが同一人物であることを示す署名値が生成される。

次に、ステップＳ１１１２では、端末１１０の認証モジュール１１２は、ユーザの公開鍵の公開鍵識別子と、ユーザが所望するサービスを特定するサービス識別子と、秘密鍵で署名した署名値とを含む認証応答電文を生成する。
その後、本処理は図３に示すステップＳ３０６へと進み、ステップＳ３０６～Ｓ３１０を行うことで、対象のサービスにログインすることができる。

これにより、ユーザは、例えば登録処理を行うために使用した端末と別の端末でも、ウエブサービスのログインに伴う認証処理を安全かつ容易に行うことができる。

また、本発明の一態様は、公開鍵や公開テンプレートが保存されるユーザ端末が紛失されたり、盗難されたり（以下、「消失」という）した場合に、当該端末で利用中のサービスを停止させることに関する。具体的には、例えば図６又は図１０で特定のサービスの識別子に対して割り当てられた公開鍵を失効することで、消失した端末による不正アクセスを防ぐことができる。以下では、ユーザ端末が消失した場合の処理の詳細について説明する。

ウエブサービスサーバ（例えば図１に示すウエブサービスサーバ１３０）が提供するサービスの登録が完了した端末（以下、「登録端末」という）が消失した場合に、登録端末のユーザは、別の端末を介して、特定のサービスを指定する識別子とユーザＩＤとを含む失効要求を認証情報管理サーバ（例えば、図１に示す認証情報管理サーバ１２０）に送信する。
次に、当該失効要求を受信した認証情報管理サーバは、認証情報テーブル（例えば図４に示す認証情報テーブル４００又は図８に示す認証情報テーブル８００）において、このユーザＩＤに対応する秘密鍵復元用情報（例えば、公開テンプレート又は生体情報テンプレート）を特定し、当該秘密鍵復元用情報をユーザに送信する。
次に、ユーザは、上述した本人認証処理に従って、秘密鍵復元用情報に基づいて生成された署名値を含む認証応答を生成し、認証情報管理サーバに送信する。
当該認証応答を受信した認証情報管理サーバは、取得した署名値を検証する。検証が成功した場合には、認証情報管理サーバは、失効要求に含まれたサービス識別子に対して対応付けられた公開鍵を認証情報テーブルにおいて失効させる。公開鍵が失効されると、認証情報テーブルにおいて、当該公開鍵の状態が「有効」から「無効」へと変更される。従って、ウエブサービスサーバは、失効された公開鍵に対応するサービスの提供を停止する。
さらに、サービスを継続させる場合には、図６あるいは図１０に登録処理を行うことにより、当該サービス識別子に新たな公開鍵を割り当てる。

これにより、ユーザが利用する端末が消失した場合に、ユーザは、消失した端末で登録されていたサービスへのアクセスを容易に解除させることができるため、本人以外による不正アクセスを防止することができる。

以上、本発明の実施の形態について説明したが、本発明は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。

１００ 認証システム
１１０Ａ，１１０Ｂ ユーザ端末
１１１ センサ
１１２ 認証モジュール
１１３ ウエブブラウザ
１１４ アプリ
１１５ セキュア領域
１２０ 認証情報管理サーバ
１２１ 登録処理部
１２２ 認証処理部
１２３ 認証情報記憶部
１３０Ａ、１３０Ｂ ウエブサービスサーバ
１３１ 業務部
１３２ 認証部
１４０ 通信ネットワーク

Claims (12)

1. 認証情報管理サーバ装置であって、
   前記認証情報管理サーバ装置は、
   通信ネットワークを介して、ユーザ端末と、ウエブサーバ装置と接続されており、
   前記ウエブサーバ装置が提供するサービスに対する登録処理を行う登録処理部と、
   前記ウエブサーバ装置が提供する前記サービスに対する認証処理を行う認証処理部と、
   前記サービスへの前記登録処理及び前記認証処理の際に用いる認証情報テーブルを格納する認証情報記憶部と、
   を備え、
   前記認証情報テーブルは、
   前記ウエブサーバ装置が提供するサービス毎に、少なくともユーザを特定するためのユーザ情報と、前記ユーザの公開鍵と、ユーザの生体情報に基づいて生成された秘密鍵復元用情報とを管理し、
   前記登録処理部は、
   前記ユーザ端末から、第１のユーザ情報と、前記ウエブサーバ装置が提供するサービスのうちの第１のサービスを指定する第１のサービス識別子とを含む登録要求を受信する場合、
   前記認証情報テーブルにおいて、前記第１のユーザ情報に対応する第１の秘密鍵復元用情報を特定し、前記ユーザ端末に送信し、
   前記ユーザ端末から、前記第１の秘密鍵復元用情報に基づいて生成された第１の署名値を含む認証応答を受信し、前記第１の署名値を検証し、
   前記検証が成功する場合、前記認証情報テーブルにおいて、前記第１のサービス識別子に対して、第１のユーザの第１の公開鍵を対応付け、前記第１の公開鍵を前記ユーザ端末に送信する、
   ことを特徴とする認証情報管理サーバ装置。
2. 前記認証処理部は、
   前記ユーザ端末から、前記第１のユーザ情報と、前記第１のサービス識別子とを含む認証要求を受信する場合、
   前記認証情報テーブルにおいて、前記第１のユーザ情報に対応する前記第１の秘密鍵復元用情報を特定し、前記ユーザ端末に送信する、
   ことを特徴とする、請求項１に記載の認証情報管理サーバ装置。
3. 前記認証処理部は、
   前記ユーザ端末から、前記第１のユーザ情報と、前記第１のサービス識別子とを含む失効要求を受信する場合、
   前記認証情報テーブルにおいて、前記第１のユーザ情報に対応する前記第１の秘密鍵復元用情報を特定し、前記ユーザ端末に送信し、
   前記ユーザ端末から、前記第１の秘密鍵復元用情報に基づいて生成された第１の署名値を含む認証応答を受信し、前記第１の署名値を検証し、
   前記検証が成功する場合、前記認証情報テーブルにおいて、前記第１のサービス識別子に対して対応付けられた第１の公開鍵を失効させる、
   ことを特徴とする、請求項１に記載の認証情報管理サーバ装置。
4. 前記認証情報テーブルは、
   ユーザ情報と、サービス識別子と、公開鍵と、公開鍵識別子と、秘密鍵復元用情報である公開テンプレートと、公開テンプレート識別子と、状態情報とを含む、
   ことを特徴とする請求項１に記載の認証情報管理サーバ装置。
5. 前記認証情報テーブルは、
   ユーザ情報と、サービス識別子と、公開鍵と、公開鍵識別子と、秘密鍵復元用情報である生体情報テンプレートと、生体情報テンプレート識別子と、秘密鍵と、秘密鍵識別子と、状態情報とを含む、
   ことを特徴とする請求項１に記載の認証情報管理サーバ装置。
6. 通信ネットワークを介して、ユーザ端末と、ウエブサーバ装置とが接続されており、
   前記ウエブサーバ装置が提供するサービスに対する登録処理を行う登録処理部と、
   前記ウエブサーバ装置が提供する前記サービスに対する認証処理を行う認証処理部と、
   前記サービスへの前記登録処理及び前記認証処理の際に用いる認証情報テーブルを格納する認証情報記憶部と、
   を備える認証情報管理サーバ装置において実行される認証管理方法であって、
   前記認証管理方法は、
   前記認証情報記憶部が、前記ウエブサーバ装置が提供するサービス毎に、少なくともユーザを特定するためのユーザ情報と、前記ユーザの公開鍵と、ユーザの生体情報に基づいて生成された秘密鍵復元用情報とを含むように、前記認証情報テーブルを構成する工程と、
   前記登録処理部が、前記ユーザ端末から登録要求を受信した場合に、前記認証情報テーブルに基づいて秘密鍵復元用情報を特定し、前記ユーザ端末に送信する工程と、
   を含む認証情報管理方法。
7. 前記ユーザ端末から、第１のユーザ情報と、前記ウエブサーバ装置が提供するサービスのうちの第１のサービスを指定する第１のサービス識別子とを含む登録要求を受信する工程と、
   前記認証情報テーブルにおいて、前記第１のユーザ情報に対応する第１の秘密鍵復元用情報を特定し、前記ユーザ端末に送信する工程と、
   前記ユーザ端末から、前記第１の秘密鍵復元用情報に基づいて生成された第１の署名値を含む認証応答を受信し、前記第１の署名値を検証する工程と、
   前記検証が通過する場合、前記認証情報テーブルにおいて、前記第１のサービス識別子に対して、第１のユーザの生体情報に基づいて生成された第１の公開鍵を対応付ける工程と、
   を前記登録処理部が行うことを更に含む、請求項６に記載の認証情報管理方法。
8. 前記ユーザ端末から、前記第１のユーザ情報と、前記第１のサービス識別子とを含む失効要求を受信する工程と、
   前記認証情報テーブルにおいて、前記第１のユーザ情報に対応する前記第１の秘密鍵復元用情報を特定し、前記ユーザ端末に送信する工程と、
   前記ユーザ端末から、前記第１の秘密鍵復元用情報に基づいて生成された第１の署名値を含む認証応答を受信し、前記第１の署名値を検証する工程と、
   前記検証が成功する場合、前記認証情報テーブルにおいて、前記第１のサービス識別子に対して対応付けられた第１の公開鍵を失効させる工程と、
   を前記認証処理部が行うことを更に含む、請求項７に記載の認証情報管理方法。
9. 前記認証情報テーブルは、
   ユーザ情報と、サービス識別子と、公開鍵と、公開鍵識別子と、秘密鍵復元用情報である公開テンプレートと、公開テンプレート識別子と、状態情報とを含む、
   ことを特徴とする請求項６に記載の認証情報管理方法。
10. 前記認証情報テーブルは、
    ユーザ情報と、サービス識別子と、公開鍵と、公開鍵識別子と、秘密鍵復元用情報である生体情報テンプレートと、生体情報テンプレート識別子と、秘密鍵と、秘密鍵識別子と、状態情報とを含む、
    ことを特徴とする請求項６に記載の認証情報管理方法。
11. 認証情報管理システムであって、
    前記認証情報管理システムにおいて、
    認証情報管理サーバ装置と、ユーザ端末と、ウエブサーバ装置とが通信ネットワークを介して接続されており、
    前記認証情報管理サーバ装置は、
    前記ウエブサーバ装置が提供するサービスに対する登録処理を行う登録処理部と、
    前記ウエブサーバ装置が提供する前記サービスに対する認証処理を行う認証処理部と、
    前記サービスへの前記登録処理及び前記認証処理の際に用いる認証情報テーブルを格納する認証情報記憶部と、
    を備え、
    前記認証情報テーブルは、
    前記ウエブサーバ装置が提供するサービス毎に、少なくともユーザを特定するためのユーザ情報と、前記ユーザの公開鍵と、前記ユーザの生体情報に基づいて生成された秘密鍵復元用情報とを管理するテーブルであり、
    前記登録処理部は、
    前記ユーザ端末から、第１のユーザ情報と、前記ウエブサーバ装置が提供するサービスのうちの第１のサービスを指定する第１のサービス識別子と、を含む登録要求を受信する場合、
    前記認証情報テーブルにおいて、前記第１のユーザ情報に対応する第１の秘密鍵復元用情報を特定し、前記ユーザ端末に送信し、
    前記ユーザ端末から、前記第１の秘密鍵復元用情報に基づいて生成された第１の署名値を含む認証応答を受信し、前記第１の署名値を検証し、
    前記検証が成功する場合、前記認証情報テーブルにおいて、前記第１のサービス識別子に対して、第１のユーザの第１の公開鍵を対応付け、前記第１の公開鍵を前記ユーザ端末に送信する、
    ことを特徴とする認証情報管理システム。
12. 前記認証処理部は、
    前記ユーザ端末から、前記第１のユーザ情報と、前記第１のサービス識別子と、を含む認証要求を受信する場合、
    前記認証情報テーブルにおいて、前記第１のユーザ情報に対応する前記第１の秘密鍵復元用情報を特定し、前記ユーザ端末に送信し、
    前記ユーザ端末は、
    受信した前記第１の秘密鍵復元用情報と、ユーザの生体情報とに基づいて生成された第１の署名値を含む認証応答を生成し、前記ウエブサーバ装置に送信する、
    ことを特徴とする、請求項１１に記載の認証情報管理システム。

Images