JP4087126B2 - 安全性保証付き生体認証方法及び認証サービスを行う装置 - Google Patents
安全性保証付き生体認証方法及び認証サービスを行う装置 Download PDFInfo
- Publication number
- JP4087126B2 JP4087126B2 JP2002050884A JP2002050884A JP4087126B2 JP 4087126 B2 JP4087126 B2 JP 4087126B2 JP 2002050884 A JP2002050884 A JP 2002050884A JP 2002050884 A JP2002050884 A JP 2002050884A JP 4087126 B2 JP4087126 B2 JP 4087126B2
- Authority
- JP
- Japan
- Prior art keywords
- biometric
- authentication
- information
- user
- certificate
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、ユーザの提示する生体情報に基づいて本人認証を行う技術に関するものである。
【０００２】
【従来の技術】
本分野の従来技術例として、以下の文献がある。
（１）BS7799 Information security management
（２）Anil Jain,Ruud Bolle Sharath Pankanti:BIOMETRICS Personal Identification in Networked Society,Kluwer Academic Publishers(1999)
（３）特開2000−215280 本人認証システム
（４）特開平11-224236及び特開2000−92046 遠隔認証システム
（５）特開平11−306352 生体的特徴の認証精度推定方法及び装置、記録媒体
従来例（１）は、情報システムのセキュリティを管理するための運用準則について定めている。ここで情報システムにおけるユーザのアクセス権限を確認するパスワードの運用準則についても定めている。従来例（２）は、様々なバイオメトリクスを用いた本人認証技術について紹介している。 公知例（３）は、大規模なユーザに対して本人認証のための生体情報を登録したＩＣカードを発行するシステムについて記述している。公知例（４）は、バイオメトリクス情報を保護した上で確実に認証が受けられる遠隔認証システムについて記述している。公知例（５）は、複数の生体的特徴を用いて認証を行う場合に、統合的な認証精度の推定が可能な認証精度推定装置について記述している。
【０００３】
【発明が解決しようとする課題】
携帯電話を利用する大規模なユーザに対して、暗証番号による本人認証が一般的である。暗証番号は本人のみの記憶情報であることが前提の認証手段であるため、従来例（１）で述べているようにセキュリティを維持するためには、（１）他人が類推しにくい番号（誕生日や電話番号などではない）で、（２）定期的に更新する必要がある。このためユーザからすると覚えにくい番号を更新せねばならず、実運用上は十分なセキュリティが保たれていないという問題があった。
【０００４】
一方、本人認証手段として人間の生体特徴を利用するものが考えられるが、生体認証技術には、生体特徴を抽出できない未対応な人間も存在する場合もある。例えば指紋認証技術では、指紋が磨り減ってない人や、肌荒れでスキャンできない人が存在する。網膜認証では、糖尿病の人の網膜（血管）パターンを撮像できない。大規模なユーザに対してこのような未対応が存在する生体認証技術を画一的に提供することに問題がある。
【０００５】
また携帯電話を介して価値ある情報などを提供するサービスアプリケーションにおいては、価値に対する対価を正しく課金するために、ある程度のセキュリティを維持した本人認証手段が求められていた。
【０００６】
複数の生体情報を統合して認証精度を向上させる方式に関しては、従来、全ての生体情報において一致と判定された場合にのみ正当（本人）であると判定する方式（ＡＮＤ方式）や、いずれかの生体情報において一致と判定された場合に正当（本人）であると判定する方式（ＯＲ方式）、あるいは公知例（５）で述べているように確率論に基づいて各生体情報の照合結果を統合する方式がある。これらはいずれも認証に用いる生体情報の種別（指紋、顔など）を限った場合に、他人を誤って受入れる確率（ＦＡＲ）を下げると、本人を誤って拒否する確率（ＦＲＲ）が上がるといった関係にあり、両者を同時に下げることができないという問題があった。
【０００７】
また複数の生体情報を組合わせて認証を行う場合、従来方式では生体情報の入力回数がシステムによってあらかじめ固定されているか、または利用者によって認証開始時に指定される。従ってたとえ正当（本人）もしくは不当（他人）と判定するに十分な照合結果が得られていても、決められた回数の入力を利用者に要求しなくてはならず、利便性が低くなるという問題があった。
【０００８】
【課題を解決するための手段】
本発明は、ユーザの提示する生体情報に基づいて本人認証を行う認証技術において、ユーザからのサービス要求を受け付けたアプリケーションから本人認証のために要求される安全性要求レベルについての情報を受け取り、ユーザの端末から提示可能な生体認証手段についての情報を受け取り、受け取った生体認証手段の安全性保証レベルについての情報を取得し、安全性保証レベルが安全性要求レベルを満たす場合にユーザの提示する生体情報に基づいて本人認証を行う安全性保証付き生体認証技術を特徴とする。
【０００９】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【００１０】
図１に本発明のシステムの構成例を示す。各ユーザが所持する携帯型端末などのユーザ端末110は、認証情報取得部111と個人情報格納部112を持ち、無線通信網120と無線通信会社のＧＷ（ゲートウェイ）125を介してインターネット網130に接続されている。
【００１１】
インターネット網130には、アプリケーションサーバ140、公開鍵の信用性の保証を行う認証局ＣＡ（Certificate Authority）150、バイオメトリクスによる本人認証を行うための基準情報（テンプレート）の信用性の保証を行うバイオメトリクス認証局ＢＣＡ（Biometric Certificate Authority）160、ユーザ端末の持ち主を本人認証を実行してアプリケーションに結果を提供する認証サーバ170およびユーザ端末110が接続される。端末ベンダ180は、ユーザ端末110をユーザに提供しているベンダであり、その端末がインターネット網130に接続される。
【００１２】
本発明のシステムは、ユーザ端末110の認証情報取得部111に則したユーザのテンプレートを登録している。該当するユーザ端末110が複数の認証情報を取得する機能を持っている場合、複数のテンプレートを所持することも可能である。それぞれのテンプレートは、そのテンプレートの信用性と完全性を保証するための情報が付加されており、付加情報を合わせてバイオメトリクス証明書と呼ぶこととする。
【００１３】
またユーザ端末に格納するバイオメトリクス証明書を複数登録する場合は、ユーザの使い勝手や希望に応じて優先度を設定可能とすることで、より利便性の高い本人認証が可能となる。
【００１４】
図２にバイオメトリクス証明書を構成する情報の例を示す。データ201は、バイオメトリクス証明書の発行者の署名を検証するための公開鍵を特定する情報、例えば発行者の証明書のシリアル番号などである。データ202は、バイオメトリクス証明書の発行者の名前、例えばX.500名などである。データ203は、バイオメトリクス証明書の有効期限、例えば開始日時と終了日時などである。データ204は、バイオメトリクス証明書の発行者が発行した証明書の通し（シリアル）番号である。データ205は、バイオメトリクス証明書のテンプレートを生成したユーザを一意に特定する情報、例えばメイルID、携帯電話番号、CAが発行したユーザの証明書IDなどである。データ206は、バイオメトリクス証明書のテンプレートを用いた本人認証手段を特定する情報、例えばA社の指紋照合：A001、B社の顔照合：B002、C社の声紋照合：C002などとユニークに付番するなどである。データ207は、照合の基準となる情報（テンプレート）であり、ユーザ本人の生体情報あるいはその特徴を示す情報を格納する。データ208は、データ201〜207の完全性を保証するための情報、例えばMAC(Message Authentication Code)や発行者のデジタル署名などである。バイオメトリクス証明書は、テンプレートが本人のものであることを証明する電子文書である。
【００１５】
本実施例ではバイオメトリクス証明書はＢＣＡ160により発行され、データ208のデジタル署名はＢＣＡ160にて完全性が保証されたデータとなる。ＣＡ150は、発行者によって発行された証明書のディジタル署名を保証する。ＢＣＡの運用を信用することにより、認証サーバ170はバイオメトリクス証明書のテンプレートを使った本人認証の結果を保証することが可能となる。
【００１６】
本発明のシステムでは、本人認証手段ごとに安全性のレベルを保証した証明書を発行する。図３に本人認証手段（モーダル）証明書を構成する情報の例を示す。データ301は、モーダル証明書の発行者の署名を検証するための公開鍵を特定する情報、例えば発行者の証明書のシリアル番号である。データ302は、モーダル証明書の発行者の名前、例えばX.500名などである。データ303は、モーダル証明書の発行者が発行した証明書の通し（シリアル）番号である。データ304は、モーダル証明書の有効期限、例えば開始日時と終了日時などである。データ305は、本人認証の種別、例えば指紋、顔、署名、声紋、虹彩などである。データ306は、照合アルゴリズムを特定するユニークな名前、例えばA社の指紋照合：A001、B社の顔照合：B002、C社の声紋照合：C002などとユニークに付番するなどである。データ307は、安全性保証レベル、ここでは他人を誤って受け入れてしまう確率、ＦＡＲである。データ308は、データ301〜307の完全性を保証するための情報、例えばMACや発行者のデジタル署名などである。モーダル証明書は、データ305に示す本人認証手段による照合の結果としてスコアが得られたとき、そのスコアに対する照合アルゴリズムのＦＡＲを保証する証明書である。
【００１７】
本実施例では、照合アルゴリズムを開発したベンダなどにおいて、他人を誤って受け入れてしまう確率：ＦＡＲを下記公知例などにより評価し、安全性保証レベルとして求める。
（公知例）瀬戸洋一他：バイオメトリックス認証技術の精度評価の標準化活動、信学会誌Vol.83 No.8 pp.624-629(2000/8)
ここでデータ308のデジタル署名は次の２つの場合が考えられる。
（１）アルゴリズム開発ベンダ（端末ベンダ）180が署名する。
（２）ＢＣＡ160または第３者認証機関が署名する。
【００１８】
（１）は各ベンダが開発者責任により安全性レベルを保証する場合であり、（２）はベンダの評価作業など第３者機関により安全性レベルが保証される場合である。
【００１９】
本発明のシステムでは、バイオメトリクス証明書の発行者は、有効期限内に失効したバイオメトリクス証明書のリストを発行する。図４にバイオメトリクス証明書の失効リスト証明書の情報の例を示す。データ401は、失効リスト証明書の発行者の署名を検証するための公開鍵を特定する情報、例えば発行者の証明書のシリアル番号である。データ402は、失効リスト証明書の発行者の名前、例えばX.500名などである。データ403は、失効リスト証明書の発行者が発行した証明書の通し（シリアル）番号である。データ404は、失効リスト証明書の有効期限、例えば開始日時と終了日時である。データ405は、失効リスト証明書にリストアップしている失効したバイオメトリクス証明書の件数、ここではN件を示すNである。データ406は、失効したバイオメトリクス証明書のシリアル番号のリストであり、N件のシリアル番号を記述する。データ407は、データ401から406の完全性を保証するための情報、例えばMACや発行者のデジタル署名などである。
【００２０】
本発明のシステムでは、モーダル証明書の発行者は、有効期限内に失効したモーダル証明書のリストを発行する。図５にモーダル証明書の失効リスト証明書の情報の例を示す。データ501は、失効リスト証明書の発行者の署名を検証するための公開鍵を特定する情報、例えば発行者の証明書のシリアル番号である。データ502は、失効リスト証明書の発行者の名前、例えばX.500名などである。データ503は、失効リスト証明書の発行者が発行した証明書の通し（シリアル）番号である。データ504は、失効リスト証明書の有効期限、例えば開始日時と終了日時である。データ505は、失効リスト証明書にリストアップしている失効したモーダル証明書の件数、ここではN件を示すNである。データ506は、失効したバイオメトリクス証明書のシリアル番号のリストであり、N件のシリアル番号を記述する。データ507は、データ501から506の完全性を保証するための情報、例えばMACや発行者のデジタル署名などである。
【００２１】
図４及び図５の失効リストにより、認証サーバ170における各証明書の有効性判定が容易になる。
【００２２】
本発明の認証のフロー概要を図６及び図７に示す。ステップ601では、ユーザはユーザ端末110を介しアプリケーションサーバ140に対し、サービスを要求する。ステップ602では、アプリケーションサーバ140は、ユーザのサービス要求を受け付ける。ステップ603では、受け付けたサービスについて本人認証が必要であれば、ステップ604へ進む。必要でなければ、ステップ691へ進む。
【００２３】
ステップ604では、アプリケーションサーバ140は要求する安全性要求レベルを含んだ認証要求を認証サーバ170に対して行う（認証要求については図９にて詳細説明）。ステップ605では、認証サーバ170はアプリケーションサーバ140の認証要求を受け付ける。ステップ606では、認証サーバ170は、ユーザ端末110に対し認証要求を行う。ステップ607では、ユーザ端末110で認証要求を受け付ける。ステップ608では、ユーザ端末110にバイオメトリクス証明書が登録されていれば、ステップ609へ行く。登録されていなければ、ステップ660へ行く。ステップ609では、ユーザ端末110はバイオメトリクス証明書およびユーザの優先度を認証サーバ170へ送付する。ステップ610では、認証サーバ170はバイオメトリクス証明書およびユーザの優先度を受信する。ステップ611では、認証サーバ170はバイオメトリクス証明書の有効性を確認する（図８にて詳細説明）。有効であれば612へ行く。無効であれば、ユーザ端末110及びアプリケーションサーバ140に通知し、それぞれステップ650及びステップ670へ進む。
【００２４】
ステップ612では、認証サーバ170は、ユーザ端末110に生体認証情報を要求する。ステップ613では、ユーザ端末110は、生体認証情報要求を受け付け、ユーザに対して認証情報を要求し、生体認証情報を取得する。ステップ614では、ユーザ端末110は、認証情報を取得できればステップ615へ進む。取得できなければステップ660へ進む。ステップ615では、ユーザ端末110は、認証サーバ170へ認証情報を送付する。ステップ616では、認証サーバ170は、認証情報を受信する。ステップ617では、認証サーバ170は、ステップ610で得たバイオメトリクス証明書のテンプレートとステップ616で得た認証情報とにより、本人認証を実行する。本人と判定できれば、ステップ618へ進む。本人と判定できなければ、ユーザ端末110及びアプリケーションサーバ140に通知し、それぞれステップ650及びステップ670へ進む。ステップ618では、認証サーバ170は、本人認証結果に署名をつけてアプリケーションサーバ140へ送付する（図１０にて詳細説明）。ステップ619では、アプリケーションサーバ140は、本人認証結果を受信する。ステップ620では、アプリケーションサーバ140は本人認証結果の正当性・完全性を署名により検証し、検証できればステップ690へ行く。検証できなければ、ステップ650に進みユーザ端末にサービスを提供できないことを通知し、終了する。
【００２５】
ステップ650では、ユーザ端末110にサービスの提供をできない旨表示する。ステップ660では、ユーザ端末110は認証サーバ170に認証情報を取得できないことを通知し、サービスを提供できない旨表示する。ステップ661では、認証サーバ170はアプリケーションサーバ140に認証できない旨、通知する。ステップ662では、アプリケーションサーバ140はサービス提供処理を終了する。ステップ670では、認証サーバ170はアプリケーションサーバ140へ認証できないことを通知し、処理を終了する。アプリケーションサーバ140は、処理を終了する。
【００２６】
ステップ690では、アプリケーションサーバ140はユーザ端末110へサービスを提供する。ステップ691では、ユーザ端末110はサービスを受領する。
【００２７】
図６のフローでステップ617の照合処理において本人と判定できなかった場合、次の選択肢も適用できる。
（１）ユーザ端末110へ同じ組み合わせの認証情報を繰り返し要求する。ただし繰り返し回数は制限する。ステップ613へ戻る。
（２）複数のセキュリティレベルが合致した認証手段あるいは認証手段の組み合わせがある場合、認証手段あるいは認証手段の組み合わせを変更し要求する。
【００２８】
続いて図８に認証サーバ170におけるバイオメトリクス証明書の有効性検証の処理フローの例を示す。これはステップ611の処理の詳細を示すフローである。ステップ701では、ユーザ端末110よりユーザ端末が持つすべてのバイオメトリクス証明書を受信する。ステップ702では、各バイオメトリクス証明書の発行者名202および発行者証明書シリアル番号201により発行者の証明書を既に信頼確認済みの証明書データベース（DB）より検索し、バイオメトリクス証明書の完全性の検証を行う。ステップ703では、各バイオメトリクス証明書の失効者リストにステップ701で受信したバイオメトリクス証明書がリストアップされていないか確認する。ステップ704では、取得された各バイオメトリクス証明書に対応するモーダル証明書を図示しない証明書DBより取得する。モーダル証明書の正当性はすでに確認済みとする。ステップ705では、取得したモーダル証明書の安全性保証レベルとアプリケーションの安全性要求レベルとを突き合わせ、アプリケーションの要求するセキュリティレベルに合致した本人認証が可能か確認する（図１１にて詳細説明）。ステップ706では、ユーザ端末へ要求する認証情報のリストを生成し、ステップ612で認証情報として要求する。
【００２９】
ステップ705の処理により、アプリケーションの安全性要求レベルに従った本人認証手段の選択が可能となり、レベルの高いアプリケーションに対する認証に合わせてレベルの低いアプリケーションに適用することが無くなり、ユーザの利便性を確保することができる。
【００３０】
図９にステップ604の本人認証要求の情報の例を示す。データ801は、ユーザ端末とアプリケーションのセッションを一意に識別する番号である。データ802は、アプリケーションが提供するサービスにおいて、想定する本人認証リスクである。データ803は、本セッションにより提供されるサービスの額である。データ804は、アプリケーションが要求するＦＡＲ値である。データ805は、アプリケーションが要求するユーザ情報、例えばユーザＩＤやユーザ名、ユーザ属性情報などの情報でアプリケーションが必要な情報である。以上のデータでデータ804が設定されていれば、データ802、803はオプションデータである。またデータ804が設定されていない場合、認証サーバ170にてデータ802、803より要求ＦＡＲ値を決定する（図１２に詳細説明）。
【００３１】
図１０にステップ618で送付される本人認証結果情報の例を示す。データ901は、アプリケーションが要求した本人認証のセッションを一意に識別する番号である。データ902は、ユーザを一意に識別する情報、例えばユーザＩＤである。データ903は、要求に対応したユーザ情報（ユーザの許可の範囲）である。データ904は、結果の本人認証レベル（照合スコアに対応した他人受入率）である。データ905は、データ901〜904のデータの完全性を保証するデータ、例えばMACや認証サーバのデジタル署名である。
【００３２】
図１１に認証サーバ170におけるアプリケーション要求に対する適合性判定の処理フローの例を示す。これはステップ705の処理の詳細を示すフローである。ステップ1001では、ユーザ端末110より提示されたバイオメトリクス証明書の本人認証手段情報206を用いて、既に正当性・完全性を検証済みのモーダル証明書を取得し、ユーザ端末110より提示されたすべてのバイオメトリクス証明書の本人認証手段が保証するＦＡＲ値を取得する。ステップ1002では、それぞれ単独のＦＡＲ値および組み合わせて計算したＦＡＲ値のリストを作成する。ステップ1011では、アプリケーションの認証要求に従い、要求ＦＡＲを決定する（図１２に詳細説明）。ステップ1021では、アプリケーションの要求するＦＡＲ値とリストを比較し、要求を満たす本人認証手段を得る。要求を満たす本人認証手段が無ければステップ1031へ進む。ステップ1022では、要求を満たす本人認証手段をユーザ端末110に通知する。ステップ1031では、サービスを提供できない旨、ユーザ端末110に通知する。
【００３３】
ステップ1021にて要求を満たす本人認証手段および本人認証手段の組み合わせが複数ある場合は、次の基準により選択する。
・要求ＦＡＲを満たし、かつ最も近い本人認証手段および本人認証手段の組み合わせ、
・組み合わせ数がより少ない本人認証手段および本人認証手段の組み合わせ、
・ユーザ希望の優先度が高い本人認証手段および本人認証手段の組み合わせ。
【００３４】
この選択により、アプリケーションの安全性要求レベルに従った本人認証手段の選択が可能となり、安全性要求レベルの高いアプリケーションと同じ認証手段をレベルの低いアプリケーションに適用しなくてもよくなり、ユーザの利便性を確保することができる。
【００３５】
図１２にデータ804がない場合の要求ＦＡＲの決定方法の例を示す。次の基準で３つに安全性要求レベルを分類する。
Ｓ：リスクが天文学的に大きい。または社会的安全に寄与する。
Ｔ：リスクが大きい。または社会的信用に関わる。
Ｕ：リスクが小さい。または安全への要求がない。
Ｓレベルであれば0.00006%、Ｔレベルであれば0.01%、Ｕレベルであれば1.0%などと設定して決定する。以上の分類により、概算のＦＡＲレベルを決定することができる。
【００３６】
あるいは、以下の数式にて、要求ＦＡＲを概算することができる。
ＦＡＲ＝ＲＰＹ／（ＡＰＹ×ＣＰＹ×ＣＰＳ）
ここで、ＲＰＹ：年間許容リスク、ＡＰＹ：年間アクセス総数、ＣＰＹ：刑法犯発生確率、ＣＰＳ：セッションあたりのサービスの額、とする。
【００３７】
以上の式により、各サービス毎に細かなリスクおよびＦＡＲを設定することができ、効率的にセキュリティ設定が可能になる。
【００３８】
バイオメトリクスを用いた本人認証手段には、照合処理の本人である確度をスコアとして出力するものも多々あり、本人であるか否かはスコアに対して設定する閾値以上か否かによって判定されるため、閾値によってＦＡＲが異なることになる。このような場合、本人認証手段証明書には、複数のＦＡＲ値が記述されることとなる。
【００３９】
図１３にモーダル証明書に複数の閾値とその閾値で保証されるＦＡＲ値を記述する場合の内容の例を示す。データ1201は、モーダル証明書の発行者の署名を検証するための公開鍵を特定する情報、例えば発行者の証明書のシリアル番号である。データ1202は、モーダル証明書の発行者の名前、例えばX.500名などである。データ1203は、モーダル証明書の発行者が発行した証明書の通し（シリアル）番号である。データ1204は、モーダル証明書の有効期限、例えば開始日時と終了日時などである。データ1205は、本人認証の種別、例えば指紋、顔、署名、声紋、虹彩などである。データ1206は、照合アルゴリズムを特定するユニークな名前、例えばA社の指紋照合：A001、B社の顔照合：B002、C社の声紋照合：C002などとユニークに付番するなどである。データ1207は、設定可能な閾値の件数N件を示すNである。データ1208は、閾値とその閾値が保証するＦＡＲ値のリストであり、Ｎ件分の閾値と保証ＦＡＲ値を記述する。データ1209は、データ301〜307の完全性を保証するための情報、例えばMACや発行者のデジタル署名などである。
【００４０】
一つのモーダル証明書に複数の閾値と保証ＦＡＲ値の組み合わせを持つことにより、複数のセキュリティレベルを管理することができ、より細かな認証手段の組み合わせ設定が可能になる。
【００４１】
図１４に認証サーバ170の持つ各機能部のブロック図を示す。認証サーバ170は、モーダル（Ｍ）証明書管理部1310と、モーダル証明書を持たない場合に端末ベンダなどへモーダル証明書を要求するモーダル証明書要求部1311、要求を送信するデータ送信部1320と、端末ベンダの端末よりモーダル証明書を受信するデータ受信部1325と、受信したモーダル証明書の署名および有効性を検証するモーダル証明書検証部1312と、検証されたモーダル証明書1315を保管する記憶部を持つ。
【００４２】
また認証サーバ170は、アプリケーションサーバ140より認証要求を受信するデータ受信部1325、アプリケーションサーバ140の認証要求を受け付ける認証要求受付部1331、認証要求に従ってユーザ端末110へバイオメトリクス証明書または生体情報を要求する要求部1340、ユーザ端末110よりデータを受信するデータ受信部1325、受信したバイオメトリクス証明書の署名および有効性を検証するＢ証明書検証部1341、ユーザより送付されたバイオメトリクス証明書に対応するモーダル証明書の保証ＦＡＲ値によりアプリケーションサーバ140からの認証要求を満たせるか、どのような手段の組み合わせか選択する有効性検証部1342、ユーザ端末110よりデータ受信部1325を介して生体情報を受け付ける生体情報受付部1350、生体情報と対応するバイオメトリクス証明書を照合する生体照合部1351、認証結果をアプリケーションにデータ送信部1320を介して送信する認証結果送信部1352よりなる。
【００４３】
また認証結果送信部の結果により、課金を行う課金部1360を持つ。次のような課金が考えられる。
・アプリケーションの認証要求１回に対し課金を行う。
・ユーザへの認証サービス提供に対し課金を行う。
・アプリケーションの安全性要求レベルに応じて課金を行う。
以上のうち、認証要求レベルに応じた課金を行うことにより、セキュリティコストとリスクのバランスを取ることができ、生体認証技術の普及が期待できる。
【００４４】
さらに認証サーバ170にモーダル証明書の保証ＦＡＲ値の検証機能を持つ場合、生体照合部1351による照合スコアを照合ログ1370にもち、照合ログによりＦＡＲを検証する検証部1371を備える実施例について説明する。照合ログ1370は、他人の生体による照合スコア及び本人の生体情報による照合スコアを格納する。
【００４５】
図１５に認証サーバ170におけるモーダル証明書の保証ＦＡＲ値を検証するための照合ログを蓄える処理フローを示す。ステップ1410では、ユーザ端末110よりバイオメトリクス証明書を受け取る。このステップはステップ701に相当する。ステップ1420では、失効リスト1415を検索し一致した利用があれば次に進む。無ければステップ1470へ進む。ステップ1420はステップ703に相当する。ステップ1430では、ユーザ端末110へ生体情報を要求する。ステップ1440では、ユーザ端末110より取得した生体情報を受信する。この生体情報は、他人のユーザ端末110を取得するなど不正ユーザの生体情報の可能性がある。ステップ1450では、ステップ1440で受信した生体情報を用いて生体照合を行い、スコアを得る。ここは失効したバイオメトリクス証明書のテンプレートと不正ユーザの生体情報とを照合する処理であり、不一致の確率が高いが、他人を誤って受け入れる確率（ＦＡＲ）だけ一致の判定があり得る。ステップ1460では、照合スコアを他人照合のログとして記録し、処理終了する。ステップ1470では、通常の照合ルーチンを行う（図７、ステップ612以降）。
【００４６】
ここでは失効リストに挙がったバイオメトリクス証明書による照合を盗難や紛失などによる他人のなりすましと見なし、他人の生体情報による照合スコアを得る。ステップ1470においても、本人の生体情報による照合スコアを得ることも可能である。
【００４７】
図１６に認証サーバ170において特定の照合アルゴリズムについてのＦＡＲの検証フローを示す。ステップ1510では、図１３に示すモーダル証明書の閾値を入力する。また変数Ｎ，ＭについてＮ＝０、Ｍ＝０とする。ステップ1520では、モーダル証明書の照合アルゴリズム識別番号を検索キーに他人照合のログ1455を検索する。ステップ1530では、検索したスコアが閾値未満か否かを判定する。未満であればステップ1540へ進み、そうでなければステップ1545へ進む。ステップ1540では、件数Ｎ及び他人の生体情報を本人のものと誤った回数Ｍを各々インクリメントし（Ｎ＋＋，Ｍ＋＋）、ステップ1550へ進む。ステップ1545では、件数Ｎをインクリメント（Ｎ＋＋）する。ステップ1550では、次の照合ログがあれば、ステップ1520へ戻る。ステップ1560では、ＦＡＲ＝Ｍ／Ｎを計算する。ステップ1570では、モーダル証明書の保証ＦＡＲ値を下回っているか検証する。
【００４８】
以上の処理フローにおいて、Ｎの数が十分大きくないと、統計的に信頼性のある検証とならない。統計的な信頼性を確保するためには、Ｎは３／ＦＡＲ以上の数量が必要である。ステップ1570では、求めたＦＡＲが統計的な信頼性があるものか否かについても確認を行った上でバイオメトリクス証明書の数値を検証する。このような検証機能を持つことで、アプリケーションサーバ140へ安全性要求レベルを確実に保証できることをアピールできる。
【００４９】
本人の生体情報による照合（失効リストにない照合）のスコアのログについては、次のような解析が考えられる。
（１）他人による不正利用解析：ある端末のすべてのバイオメトリクス証明書の照合スコアが急激に低下した後、スコアに上昇が見られない。
（２）不適テンプレート解析：ある端末の特定のバイオメトリクス証明書の照合スコアが安定しない。
（３）偽造攻撃解析：多数の照合を繰り返しても照合スコアに全く変化が見られない。
【００５０】
（１）に対してはユーザに端末の状況を確認して、確かに不正利用されているのであれば、失効リストに登録しその期間の照合ログを他人照合ログとして蓄える。（２）に対してはユーザに対してそのテンプレートが該当ユーザに適していない旨通知し、他の手段を選択するように勧告する。（３）に対してはユーザの端末の状況を確認して、偽造攻撃への対策を立てる必要がある。例えば該当するモーダルを失効させるなど対策がある。
【００５１】
本発明は、またユーザ端末がその持ち主に関するモーダルの閾値および単独で用いた場合のＦＡＲ（異なる生体が誤って一致する確率）、ＦＲＲ（同一の生体が誤って不一致となる確率）の情報を保持し、この情報を認証時に認証サーバへ送り、認証に利用し、認証が成功した場合に認証サーバがＦＲＲの情報を更新することにより、利用者ごとに最適化された認証を行い、利便性を向上させたシステムを提供する。
【００５２】
図１７に認証サーバがない場合の認証処理のフローを示す。図６及び図７に示す認証処理のフローと比較すれば明らかなように、アプリケーションサーバ140が認証サーバ170の行う処理を実行する。この認証処理フローにはステップ618〜620に相当する処理がないが、ステップ620の正当性判定はアプリケーションサーバ140が認証サーバ170の行った本人判定の信用性を判定することになるので、認証サーバがない場合には不要となる。
【００５３】
図１８に利用者ごとに最適化した認証を行う場合に、バイオメトリクス証明書情報を構成する情報の例を示す。データ1701は、バイオメトリクス証明書の発行者の署名を検証するための公開鍵を特定する情報、例えば発行者の証明書のシリアル番号などである。データ1702は、バイオメトリクス証明書の発行者の名前、例えばX.500名などである。データ1703は、バイオメトリクス証明書の有効期限、例えば開始日時と終了日時などである。データ1704は、バイオメトリクス証明書の発行者が発行した証明書の通し（シリアル）番号である。データ1705は、バイオメトリクス証明書のテンプレートを生成したユーザを一意に特定する情報、例えば、メイルIDや携帯電話番号などである。データ1706は、バイオメトリクス証明書のテンプレートを用いた本人認証手段（モーダル）を特定する情報、例えばA社の指紋照合：A001、B社の顔照合：B002、C社の声紋照合：C002などとユニークに付番するなどである。
【００５４】
データ1707は、照合の基準となる情報（テンプレート）である。複数のモーダルを用いる場合は、各モーダルのテンプレートを保持する。データ1708は、当該モーダルの照合結果のスコアに対して、一致（照合成功）か不一致（照合失敗）かを判定するための閾値である。複数のモーダルを用いる場合は、各モーダルの閾値を保持する。データ1709は、当該モーダルのＦＡＲ値である。複数のモーダルを用いる場合は、各モーダルの保証ＦＡＲ値を保持する。データ1710は、過去において当該モーダルを用いて照合した結果、正当な持ち主（本人）が入力したにもかかわらず誤って不一致（本人拒否）となった回数である。複数のモーダルを用いる場合は、各モーダルの不一致回数を保持する。データ1711は、過去において当該モーダルを用いて照合を行った回数である。複数のモーダルを用いる場合は、各モーダルの照合回数を保持する。データ1712は、データ1701〜1711の完全性を保証するための情報、例えばMACや発行者のデジタル署名などである。
【００５５】
本発明は、また任意の生体情報を不定回数繰返し照合することにより、システム全体としてのＦＡＲ（他人を誤って受け入れる確率）が要求値以下となることを保証し、かつＦＲＲ（本人を誤って拒否する確率）も小さくし、また使用するモーダルを利用者が自由に選択可能とすることで利便性を向上させたシステムを提供する。
【００５６】
図１９及び図２０に生体情報を不定回数繰返し照合し、かつ利用者ごとに最適化した認証を行う場合の認証フローを示す。図１９及び図２０は、ユーザ端末110と認証サーバ170に関連する部分を記述したものであり、認証フローにおいてアプリケーションサーバ140に関連する部分は、図６及び図７と同じである。
【００５７】
ステップ1810では、認証サーバ170は、ユーザ端末110に対し認証要求を行う。ステップ1811では、ユーザ端末110は、認証要求を受け付ける。ステップ1812では、ユーザ端末110はバイオメトリクス証明書を認証サーバ170へ送付する。ここで送付するバイオメトリクス証明書は、図１８に示すバイオメトリクス証明書である。ステップ1813では、認証サーバ170は、バイオメトリクス証明書を受け付ける。ステップ1814では、認証サーバ170は、バイオメトリクス証明書の有効性を確認する。有効であればステップ1816へ行く。無効であればユーザ端末に通知し、ステップ1815へ進む。ステップ1815では、ユーザ端末110にサービスの提供をできない旨表示する。ステップ1816では、認証サーバは、アプリケーションが要求する安全性要求レベル（ＦＡＲ）を満たすよう、複数回の照合結果を統合した認証スコアに対する統合閾値（本人閾値および他人閾値）を計算する。具体的な計算方法は後述する。また照合回数の最大（N）を定める。ステップ1830では、認証サーバ170は、ユーザ端末110に対し生体情報を要求する。ステップ1831では、ユーザ端末110は生体情報の要求を受け付ける。ステップ1832では、ユーザ端末110で、利用者の生体情報を取得する。取得する生体情報の種別（指紋、顔など）は任意であり、利用者が自由に選択できる。同一の種別の生体情報を複数回繰り返して取得してもよい。ステップ1833では、ユーザ端末110は、生体情報を認証サーバ170へ送付する。ステップ1834では、認証サーバ170は、生体情報を受け付ける。
【００５８】
ステップ1835では、認証サーバ170は、バイオメトリクス証明書中のテンプレートと、ユーザ端末から送付された生体情報を照合し、バイオメトリクス証明書中の閾値を基準にして一致（照合成功）か不一致（照合失敗）かを判定する。ステップ1836では、ステップ1835の照合結果に従って認証スコアを更新する。認証スコアの具体的な計算方法は後述する。ステップ1837では、認証スコアが本人閾値以上ならばステップ1840へ進む。そうでなければステップ1850へ進む。ステップ1840では、認証サーバは、ユーザ端末110の利用者が正当である（本人である）と判定する。ステップ1841では、各モーダルに関してステップ1835で照合を行った回数および不一致回数を利用者のバイオメトリクス証明書に反映させる。ステップ1842では、認証サーバ170は、更新されたバイオメトリクス証明書の情報に認証サーバの署名を添付して、ユーザ端末110に送り返す。ステップ1843では、ユーザ端末110は、認証サーバ170から更新されたバイオメトリクス証明書を受け取り、ユーザ端末110内に保持しているバイオメトリクス証明書を置き換える。
【００５９】
ステップ1850では、認証スコアが、他人閾値以下ならばステップ1852に進み、そうでなければステップ1851に進む。ステップ1851では、照合回数が、システムの定める最大回数（Ｎ）以上ならば、ステップ1852へ進み、そうでなければステップ1830へ戻る。ステップ1852では、認証サーバ170は、ユーザ端末110の利用者が正当でない（他人である）と判定する。
【００６０】
i回目の照合に用いたモーダルをMiとしたとき、i回目の照合における一致、不一致の判定には、利用者のバイオメトリクス証明書中のモーダルMiに対応する閾値を用いる。この認証フローでは、図２に示すバイオメトリクス証明書とモーダル証明書の代わりに図１８に示すユーザごとに閾値を設定するバイオメトリクス証明書を使用する。
【００６１】
ステップ1836における認証スコアは、利用者が正当な人物である確率（本人確率）として計算する。具体的には、i回目の照合結果をxi(0：不一致、1：一致）、利用者のバイオメトリクス証明書中に記録された、モーダルMiのFARをFARMi、FRR（不一致回数／照合回数）をFRRMiとしたとき、n回の照合を繰り返した場合の本人確率Pnは、各照合が独立な試行であると仮定し、ベイズの定理を用いて、以下の式により計算する。
【００６２】
【数１】
【数２】
ステップ1816において、アプリケーションの安全性要求レベルをFARReqとしたとき、上記本人確率に対する本人閾値αを以下の式により計算する。
【００６３】
【数３】
システム全体としてのFARをFARTotal、FRRをFRRTotalとする。本システムが、利用者は正当であると判定した場合、その利用者が実際に正当である確率はα以上であるので、以下の式が成立する。
【００６４】
【数４】
（数３）、（数４）より、以下の式が導出される。
【００６５】
【数５】
ＦＲＲTotal≧０なので、（数５）より、
ＦＡＲTotal≦ＦＡＲReq （数６）
が導出される。
【００６６】
（数６）は、本実施例におけるシステムの安全性（FARTotal）が、アプリケーションの要求する安全性要求レベル（FARReq）を満たしていることを意味する。
【００６７】
またステップ1816において、最大照合回数（Ｎ）および他人閾値を適切に設定することで、本システムの利便性、すなわちＦＲＲと平均入力回数を調節する。
【００６８】
本発明の認証サーバは、インターネット上で生体認証に関わるデータをデータベース機能により管理し、インターネット上のアプリケーションサーバにより、認証サーバの生体認証機能が共用される一種のSAN（Storage Area Network）と位置付けることもできる。このことにより、従来、アプリケーションサーバで個々に管理していた個人認証情報を安全性の保証されたストレージサービスとして一括に管理・提供することで保守性や利便性を向上することが可能である。
【００６９】
【発明の効果】
本発明によれば、各端末の持ち主は自分に適した本人認証方式を選択することが可能となる。またサービスアプリケーションの提供者は、セキュリティレベルを保った本人認証を行うことにより、より安全なサービスの提供が可能となる。更に本発明の認証方式は、システムに要求された任意の安全性レベルを満たしながら、本人を誤って拒否する確率が低く利便性の高い本人認証が可能となる。
【図面の簡単な説明】
【図１】実施形態の本人認証システムの全体構成図である。
【図２】バイオメトリクス証明書の構成例を示す図である。
【図３】本人認証手段（モーダル）証明書の構成例を示す図である。
【図４】バイオメトリクス証明書の失効リスト証明書の例を示す図である。
【図５】モーダル証明書の失効リスト証明書の例を示す図である。
【図６】実施形態の本人認証のフローチャートである。
【図７】実施形態の本人認証のフローチャート（続き）である。
【図８】実施形態のバイオメトリクス証明書の有効性検証のフローチャートである。
【図９】アプリケーションサーバによる本人認証要求情報例を示す図である。
【図１０】認証サーバによる本人認証結果情報の例を示す図である。
【図１１】実施形態の認証サーバによるアプリケーションの安全性要求に対する適合性判定のフローチャートである。
【図１２】認証サーバにおける要求ＦＡＲ値の決定方法の一例を示す図である。
【図１３】モーダル証明書に複数の閾値とその閾値が保証するＦＡＲ値を記述する例を示す図である。
【図１４】実施形態の認証サーバの構成を示す図である。
【図１５】実施形態の認証サーバにおける保証ＦＡＲ値の検証の準備処理のフローチャートである。
【図１６】実施形態の認証サーバにおける保証ＦＡＲ値の検証処理のフローチャートである。
【図１７】実施形態の認証サーバがない場合の本人認証のフローチャートである。
【図１８】個人ごとに最適化された認証を行う場合のバイオメトリクス証明書の例を示す図である。
【図１９】実施形態の生体情報を不定回数繰返し照合する場合の本人認証のフローチャートである。
【図２０】実施形態の生体情報を不定回数繰返し照合する場合の本人認証のフローチャート（続き）である。
【符号の説明】
110・・・ユーザ端末、140・・・アプリケーションサーバ、170・・・認証サーバ
【発明の属する技術分野】
本発明は、ユーザの提示する生体情報に基づいて本人認証を行う技術に関するものである。
【０００２】
【従来の技術】
本分野の従来技術例として、以下の文献がある。
（１）BS7799 Information security management
（２）Anil Jain,Ruud Bolle Sharath Pankanti:BIOMETRICS Personal Identification in Networked Society,Kluwer Academic Publishers(1999)
（３）特開2000−215280 本人認証システム
（４）特開平11-224236及び特開2000−92046 遠隔認証システム
（５）特開平11−306352 生体的特徴の認証精度推定方法及び装置、記録媒体
従来例（１）は、情報システムのセキュリティを管理するための運用準則について定めている。ここで情報システムにおけるユーザのアクセス権限を確認するパスワードの運用準則についても定めている。従来例（２）は、様々なバイオメトリクスを用いた本人認証技術について紹介している。 公知例（３）は、大規模なユーザに対して本人認証のための生体情報を登録したＩＣカードを発行するシステムについて記述している。公知例（４）は、バイオメトリクス情報を保護した上で確実に認証が受けられる遠隔認証システムについて記述している。公知例（５）は、複数の生体的特徴を用いて認証を行う場合に、統合的な認証精度の推定が可能な認証精度推定装置について記述している。
【０００３】
【発明が解決しようとする課題】
携帯電話を利用する大規模なユーザに対して、暗証番号による本人認証が一般的である。暗証番号は本人のみの記憶情報であることが前提の認証手段であるため、従来例（１）で述べているようにセキュリティを維持するためには、（１）他人が類推しにくい番号（誕生日や電話番号などではない）で、（２）定期的に更新する必要がある。このためユーザからすると覚えにくい番号を更新せねばならず、実運用上は十分なセキュリティが保たれていないという問題があった。
【０００４】
一方、本人認証手段として人間の生体特徴を利用するものが考えられるが、生体認証技術には、生体特徴を抽出できない未対応な人間も存在する場合もある。例えば指紋認証技術では、指紋が磨り減ってない人や、肌荒れでスキャンできない人が存在する。網膜認証では、糖尿病の人の網膜（血管）パターンを撮像できない。大規模なユーザに対してこのような未対応が存在する生体認証技術を画一的に提供することに問題がある。
【０００５】
また携帯電話を介して価値ある情報などを提供するサービスアプリケーションにおいては、価値に対する対価を正しく課金するために、ある程度のセキュリティを維持した本人認証手段が求められていた。
【０００６】
複数の生体情報を統合して認証精度を向上させる方式に関しては、従来、全ての生体情報において一致と判定された場合にのみ正当（本人）であると判定する方式（ＡＮＤ方式）や、いずれかの生体情報において一致と判定された場合に正当（本人）であると判定する方式（ＯＲ方式）、あるいは公知例（５）で述べているように確率論に基づいて各生体情報の照合結果を統合する方式がある。これらはいずれも認証に用いる生体情報の種別（指紋、顔など）を限った場合に、他人を誤って受入れる確率（ＦＡＲ）を下げると、本人を誤って拒否する確率（ＦＲＲ）が上がるといった関係にあり、両者を同時に下げることができないという問題があった。
【０００７】
また複数の生体情報を組合わせて認証を行う場合、従来方式では生体情報の入力回数がシステムによってあらかじめ固定されているか、または利用者によって認証開始時に指定される。従ってたとえ正当（本人）もしくは不当（他人）と判定するに十分な照合結果が得られていても、決められた回数の入力を利用者に要求しなくてはならず、利便性が低くなるという問題があった。
【０００８】
【課題を解決するための手段】
本発明は、ユーザの提示する生体情報に基づいて本人認証を行う認証技術において、ユーザからのサービス要求を受け付けたアプリケーションから本人認証のために要求される安全性要求レベルについての情報を受け取り、ユーザの端末から提示可能な生体認証手段についての情報を受け取り、受け取った生体認証手段の安全性保証レベルについての情報を取得し、安全性保証レベルが安全性要求レベルを満たす場合にユーザの提示する生体情報に基づいて本人認証を行う安全性保証付き生体認証技術を特徴とする。
【０００９】
【発明の実施の形態】
以下、本発明の実施の形態について図面を用いて説明する。
【００１０】
図１に本発明のシステムの構成例を示す。各ユーザが所持する携帯型端末などのユーザ端末110は、認証情報取得部111と個人情報格納部112を持ち、無線通信網120と無線通信会社のＧＷ（ゲートウェイ）125を介してインターネット網130に接続されている。
【００１１】
インターネット網130には、アプリケーションサーバ140、公開鍵の信用性の保証を行う認証局ＣＡ（Certificate Authority）150、バイオメトリクスによる本人認証を行うための基準情報（テンプレート）の信用性の保証を行うバイオメトリクス認証局ＢＣＡ（Biometric Certificate Authority）160、ユーザ端末の持ち主を本人認証を実行してアプリケーションに結果を提供する認証サーバ170およびユーザ端末110が接続される。端末ベンダ180は、ユーザ端末110をユーザに提供しているベンダであり、その端末がインターネット網130に接続される。
【００１２】
本発明のシステムは、ユーザ端末110の認証情報取得部111に則したユーザのテンプレートを登録している。該当するユーザ端末110が複数の認証情報を取得する機能を持っている場合、複数のテンプレートを所持することも可能である。それぞれのテンプレートは、そのテンプレートの信用性と完全性を保証するための情報が付加されており、付加情報を合わせてバイオメトリクス証明書と呼ぶこととする。
【００１３】
またユーザ端末に格納するバイオメトリクス証明書を複数登録する場合は、ユーザの使い勝手や希望に応じて優先度を設定可能とすることで、より利便性の高い本人認証が可能となる。
【００１４】
図２にバイオメトリクス証明書を構成する情報の例を示す。データ201は、バイオメトリクス証明書の発行者の署名を検証するための公開鍵を特定する情報、例えば発行者の証明書のシリアル番号などである。データ202は、バイオメトリクス証明書の発行者の名前、例えばX.500名などである。データ203は、バイオメトリクス証明書の有効期限、例えば開始日時と終了日時などである。データ204は、バイオメトリクス証明書の発行者が発行した証明書の通し（シリアル）番号である。データ205は、バイオメトリクス証明書のテンプレートを生成したユーザを一意に特定する情報、例えばメイルID、携帯電話番号、CAが発行したユーザの証明書IDなどである。データ206は、バイオメトリクス証明書のテンプレートを用いた本人認証手段を特定する情報、例えばA社の指紋照合：A001、B社の顔照合：B002、C社の声紋照合：C002などとユニークに付番するなどである。データ207は、照合の基準となる情報（テンプレート）であり、ユーザ本人の生体情報あるいはその特徴を示す情報を格納する。データ208は、データ201〜207の完全性を保証するための情報、例えばMAC(Message Authentication Code)や発行者のデジタル署名などである。バイオメトリクス証明書は、テンプレートが本人のものであることを証明する電子文書である。
【００１５】
本実施例ではバイオメトリクス証明書はＢＣＡ160により発行され、データ208のデジタル署名はＢＣＡ160にて完全性が保証されたデータとなる。ＣＡ150は、発行者によって発行された証明書のディジタル署名を保証する。ＢＣＡの運用を信用することにより、認証サーバ170はバイオメトリクス証明書のテンプレートを使った本人認証の結果を保証することが可能となる。
【００１６】
本発明のシステムでは、本人認証手段ごとに安全性のレベルを保証した証明書を発行する。図３に本人認証手段（モーダル）証明書を構成する情報の例を示す。データ301は、モーダル証明書の発行者の署名を検証するための公開鍵を特定する情報、例えば発行者の証明書のシリアル番号である。データ302は、モーダル証明書の発行者の名前、例えばX.500名などである。データ303は、モーダル証明書の発行者が発行した証明書の通し（シリアル）番号である。データ304は、モーダル証明書の有効期限、例えば開始日時と終了日時などである。データ305は、本人認証の種別、例えば指紋、顔、署名、声紋、虹彩などである。データ306は、照合アルゴリズムを特定するユニークな名前、例えばA社の指紋照合：A001、B社の顔照合：B002、C社の声紋照合：C002などとユニークに付番するなどである。データ307は、安全性保証レベル、ここでは他人を誤って受け入れてしまう確率、ＦＡＲである。データ308は、データ301〜307の完全性を保証するための情報、例えばMACや発行者のデジタル署名などである。モーダル証明書は、データ305に示す本人認証手段による照合の結果としてスコアが得られたとき、そのスコアに対する照合アルゴリズムのＦＡＲを保証する証明書である。
【００１７】
本実施例では、照合アルゴリズムを開発したベンダなどにおいて、他人を誤って受け入れてしまう確率：ＦＡＲを下記公知例などにより評価し、安全性保証レベルとして求める。
（公知例）瀬戸洋一他：バイオメトリックス認証技術の精度評価の標準化活動、信学会誌Vol.83 No.8 pp.624-629(2000/8)
ここでデータ308のデジタル署名は次の２つの場合が考えられる。
（１）アルゴリズム開発ベンダ（端末ベンダ）180が署名する。
（２）ＢＣＡ160または第３者認証機関が署名する。
【００１８】
（１）は各ベンダが開発者責任により安全性レベルを保証する場合であり、（２）はベンダの評価作業など第３者機関により安全性レベルが保証される場合である。
【００１９】
本発明のシステムでは、バイオメトリクス証明書の発行者は、有効期限内に失効したバイオメトリクス証明書のリストを発行する。図４にバイオメトリクス証明書の失効リスト証明書の情報の例を示す。データ401は、失効リスト証明書の発行者の署名を検証するための公開鍵を特定する情報、例えば発行者の証明書のシリアル番号である。データ402は、失効リスト証明書の発行者の名前、例えばX.500名などである。データ403は、失効リスト証明書の発行者が発行した証明書の通し（シリアル）番号である。データ404は、失効リスト証明書の有効期限、例えば開始日時と終了日時である。データ405は、失効リスト証明書にリストアップしている失効したバイオメトリクス証明書の件数、ここではN件を示すNである。データ406は、失効したバイオメトリクス証明書のシリアル番号のリストであり、N件のシリアル番号を記述する。データ407は、データ401から406の完全性を保証するための情報、例えばMACや発行者のデジタル署名などである。
【００２０】
本発明のシステムでは、モーダル証明書の発行者は、有効期限内に失効したモーダル証明書のリストを発行する。図５にモーダル証明書の失効リスト証明書の情報の例を示す。データ501は、失効リスト証明書の発行者の署名を検証するための公開鍵を特定する情報、例えば発行者の証明書のシリアル番号である。データ502は、失効リスト証明書の発行者の名前、例えばX.500名などである。データ503は、失効リスト証明書の発行者が発行した証明書の通し（シリアル）番号である。データ504は、失効リスト証明書の有効期限、例えば開始日時と終了日時である。データ505は、失効リスト証明書にリストアップしている失効したモーダル証明書の件数、ここではN件を示すNである。データ506は、失効したバイオメトリクス証明書のシリアル番号のリストであり、N件のシリアル番号を記述する。データ507は、データ501から506の完全性を保証するための情報、例えばMACや発行者のデジタル署名などである。
【００２１】
図４及び図５の失効リストにより、認証サーバ170における各証明書の有効性判定が容易になる。
【００２２】
本発明の認証のフロー概要を図６及び図７に示す。ステップ601では、ユーザはユーザ端末110を介しアプリケーションサーバ140に対し、サービスを要求する。ステップ602では、アプリケーションサーバ140は、ユーザのサービス要求を受け付ける。ステップ603では、受け付けたサービスについて本人認証が必要であれば、ステップ604へ進む。必要でなければ、ステップ691へ進む。
【００２３】
ステップ604では、アプリケーションサーバ140は要求する安全性要求レベルを含んだ認証要求を認証サーバ170に対して行う（認証要求については図９にて詳細説明）。ステップ605では、認証サーバ170はアプリケーションサーバ140の認証要求を受け付ける。ステップ606では、認証サーバ170は、ユーザ端末110に対し認証要求を行う。ステップ607では、ユーザ端末110で認証要求を受け付ける。ステップ608では、ユーザ端末110にバイオメトリクス証明書が登録されていれば、ステップ609へ行く。登録されていなければ、ステップ660へ行く。ステップ609では、ユーザ端末110はバイオメトリクス証明書およびユーザの優先度を認証サーバ170へ送付する。ステップ610では、認証サーバ170はバイオメトリクス証明書およびユーザの優先度を受信する。ステップ611では、認証サーバ170はバイオメトリクス証明書の有効性を確認する（図８にて詳細説明）。有効であれば612へ行く。無効であれば、ユーザ端末110及びアプリケーションサーバ140に通知し、それぞれステップ650及びステップ670へ進む。
【００２４】
ステップ612では、認証サーバ170は、ユーザ端末110に生体認証情報を要求する。ステップ613では、ユーザ端末110は、生体認証情報要求を受け付け、ユーザに対して認証情報を要求し、生体認証情報を取得する。ステップ614では、ユーザ端末110は、認証情報を取得できればステップ615へ進む。取得できなければステップ660へ進む。ステップ615では、ユーザ端末110は、認証サーバ170へ認証情報を送付する。ステップ616では、認証サーバ170は、認証情報を受信する。ステップ617では、認証サーバ170は、ステップ610で得たバイオメトリクス証明書のテンプレートとステップ616で得た認証情報とにより、本人認証を実行する。本人と判定できれば、ステップ618へ進む。本人と判定できなければ、ユーザ端末110及びアプリケーションサーバ140に通知し、それぞれステップ650及びステップ670へ進む。ステップ618では、認証サーバ170は、本人認証結果に署名をつけてアプリケーションサーバ140へ送付する（図１０にて詳細説明）。ステップ619では、アプリケーションサーバ140は、本人認証結果を受信する。ステップ620では、アプリケーションサーバ140は本人認証結果の正当性・完全性を署名により検証し、検証できればステップ690へ行く。検証できなければ、ステップ650に進みユーザ端末にサービスを提供できないことを通知し、終了する。
【００２５】
ステップ650では、ユーザ端末110にサービスの提供をできない旨表示する。ステップ660では、ユーザ端末110は認証サーバ170に認証情報を取得できないことを通知し、サービスを提供できない旨表示する。ステップ661では、認証サーバ170はアプリケーションサーバ140に認証できない旨、通知する。ステップ662では、アプリケーションサーバ140はサービス提供処理を終了する。ステップ670では、認証サーバ170はアプリケーションサーバ140へ認証できないことを通知し、処理を終了する。アプリケーションサーバ140は、処理を終了する。
【００２６】
ステップ690では、アプリケーションサーバ140はユーザ端末110へサービスを提供する。ステップ691では、ユーザ端末110はサービスを受領する。
【００２７】
図６のフローでステップ617の照合処理において本人と判定できなかった場合、次の選択肢も適用できる。
（１）ユーザ端末110へ同じ組み合わせの認証情報を繰り返し要求する。ただし繰り返し回数は制限する。ステップ613へ戻る。
（２）複数のセキュリティレベルが合致した認証手段あるいは認証手段の組み合わせがある場合、認証手段あるいは認証手段の組み合わせを変更し要求する。
【００２８】
続いて図８に認証サーバ170におけるバイオメトリクス証明書の有効性検証の処理フローの例を示す。これはステップ611の処理の詳細を示すフローである。ステップ701では、ユーザ端末110よりユーザ端末が持つすべてのバイオメトリクス証明書を受信する。ステップ702では、各バイオメトリクス証明書の発行者名202および発行者証明書シリアル番号201により発行者の証明書を既に信頼確認済みの証明書データベース（DB）より検索し、バイオメトリクス証明書の完全性の検証を行う。ステップ703では、各バイオメトリクス証明書の失効者リストにステップ701で受信したバイオメトリクス証明書がリストアップされていないか確認する。ステップ704では、取得された各バイオメトリクス証明書に対応するモーダル証明書を図示しない証明書DBより取得する。モーダル証明書の正当性はすでに確認済みとする。ステップ705では、取得したモーダル証明書の安全性保証レベルとアプリケーションの安全性要求レベルとを突き合わせ、アプリケーションの要求するセキュリティレベルに合致した本人認証が可能か確認する（図１１にて詳細説明）。ステップ706では、ユーザ端末へ要求する認証情報のリストを生成し、ステップ612で認証情報として要求する。
【００２９】
ステップ705の処理により、アプリケーションの安全性要求レベルに従った本人認証手段の選択が可能となり、レベルの高いアプリケーションに対する認証に合わせてレベルの低いアプリケーションに適用することが無くなり、ユーザの利便性を確保することができる。
【００３０】
図９にステップ604の本人認証要求の情報の例を示す。データ801は、ユーザ端末とアプリケーションのセッションを一意に識別する番号である。データ802は、アプリケーションが提供するサービスにおいて、想定する本人認証リスクである。データ803は、本セッションにより提供されるサービスの額である。データ804は、アプリケーションが要求するＦＡＲ値である。データ805は、アプリケーションが要求するユーザ情報、例えばユーザＩＤやユーザ名、ユーザ属性情報などの情報でアプリケーションが必要な情報である。以上のデータでデータ804が設定されていれば、データ802、803はオプションデータである。またデータ804が設定されていない場合、認証サーバ170にてデータ802、803より要求ＦＡＲ値を決定する（図１２に詳細説明）。
【００３１】
図１０にステップ618で送付される本人認証結果情報の例を示す。データ901は、アプリケーションが要求した本人認証のセッションを一意に識別する番号である。データ902は、ユーザを一意に識別する情報、例えばユーザＩＤである。データ903は、要求に対応したユーザ情報（ユーザの許可の範囲）である。データ904は、結果の本人認証レベル（照合スコアに対応した他人受入率）である。データ905は、データ901〜904のデータの完全性を保証するデータ、例えばMACや認証サーバのデジタル署名である。
【００３２】
図１１に認証サーバ170におけるアプリケーション要求に対する適合性判定の処理フローの例を示す。これはステップ705の処理の詳細を示すフローである。ステップ1001では、ユーザ端末110より提示されたバイオメトリクス証明書の本人認証手段情報206を用いて、既に正当性・完全性を検証済みのモーダル証明書を取得し、ユーザ端末110より提示されたすべてのバイオメトリクス証明書の本人認証手段が保証するＦＡＲ値を取得する。ステップ1002では、それぞれ単独のＦＡＲ値および組み合わせて計算したＦＡＲ値のリストを作成する。ステップ1011では、アプリケーションの認証要求に従い、要求ＦＡＲを決定する（図１２に詳細説明）。ステップ1021では、アプリケーションの要求するＦＡＲ値とリストを比較し、要求を満たす本人認証手段を得る。要求を満たす本人認証手段が無ければステップ1031へ進む。ステップ1022では、要求を満たす本人認証手段をユーザ端末110に通知する。ステップ1031では、サービスを提供できない旨、ユーザ端末110に通知する。
【００３３】
ステップ1021にて要求を満たす本人認証手段および本人認証手段の組み合わせが複数ある場合は、次の基準により選択する。
・要求ＦＡＲを満たし、かつ最も近い本人認証手段および本人認証手段の組み合わせ、
・組み合わせ数がより少ない本人認証手段および本人認証手段の組み合わせ、
・ユーザ希望の優先度が高い本人認証手段および本人認証手段の組み合わせ。
【００３４】
この選択により、アプリケーションの安全性要求レベルに従った本人認証手段の選択が可能となり、安全性要求レベルの高いアプリケーションと同じ認証手段をレベルの低いアプリケーションに適用しなくてもよくなり、ユーザの利便性を確保することができる。
【００３５】
図１２にデータ804がない場合の要求ＦＡＲの決定方法の例を示す。次の基準で３つに安全性要求レベルを分類する。
Ｓ：リスクが天文学的に大きい。または社会的安全に寄与する。
Ｔ：リスクが大きい。または社会的信用に関わる。
Ｕ：リスクが小さい。または安全への要求がない。
Ｓレベルであれば0.00006%、Ｔレベルであれば0.01%、Ｕレベルであれば1.0%などと設定して決定する。以上の分類により、概算のＦＡＲレベルを決定することができる。
【００３６】
あるいは、以下の数式にて、要求ＦＡＲを概算することができる。
ＦＡＲ＝ＲＰＹ／（ＡＰＹ×ＣＰＹ×ＣＰＳ）
ここで、ＲＰＹ：年間許容リスク、ＡＰＹ：年間アクセス総数、ＣＰＹ：刑法犯発生確率、ＣＰＳ：セッションあたりのサービスの額、とする。
【００３７】
以上の式により、各サービス毎に細かなリスクおよびＦＡＲを設定することができ、効率的にセキュリティ設定が可能になる。
【００３８】
バイオメトリクスを用いた本人認証手段には、照合処理の本人である確度をスコアとして出力するものも多々あり、本人であるか否かはスコアに対して設定する閾値以上か否かによって判定されるため、閾値によってＦＡＲが異なることになる。このような場合、本人認証手段証明書には、複数のＦＡＲ値が記述されることとなる。
【００３９】
図１３にモーダル証明書に複数の閾値とその閾値で保証されるＦＡＲ値を記述する場合の内容の例を示す。データ1201は、モーダル証明書の発行者の署名を検証するための公開鍵を特定する情報、例えば発行者の証明書のシリアル番号である。データ1202は、モーダル証明書の発行者の名前、例えばX.500名などである。データ1203は、モーダル証明書の発行者が発行した証明書の通し（シリアル）番号である。データ1204は、モーダル証明書の有効期限、例えば開始日時と終了日時などである。データ1205は、本人認証の種別、例えば指紋、顔、署名、声紋、虹彩などである。データ1206は、照合アルゴリズムを特定するユニークな名前、例えばA社の指紋照合：A001、B社の顔照合：B002、C社の声紋照合：C002などとユニークに付番するなどである。データ1207は、設定可能な閾値の件数N件を示すNである。データ1208は、閾値とその閾値が保証するＦＡＲ値のリストであり、Ｎ件分の閾値と保証ＦＡＲ値を記述する。データ1209は、データ301〜307の完全性を保証するための情報、例えばMACや発行者のデジタル署名などである。
【００４０】
一つのモーダル証明書に複数の閾値と保証ＦＡＲ値の組み合わせを持つことにより、複数のセキュリティレベルを管理することができ、より細かな認証手段の組み合わせ設定が可能になる。
【００４１】
図１４に認証サーバ170の持つ各機能部のブロック図を示す。認証サーバ170は、モーダル（Ｍ）証明書管理部1310と、モーダル証明書を持たない場合に端末ベンダなどへモーダル証明書を要求するモーダル証明書要求部1311、要求を送信するデータ送信部1320と、端末ベンダの端末よりモーダル証明書を受信するデータ受信部1325と、受信したモーダル証明書の署名および有効性を検証するモーダル証明書検証部1312と、検証されたモーダル証明書1315を保管する記憶部を持つ。
【００４２】
また認証サーバ170は、アプリケーションサーバ140より認証要求を受信するデータ受信部1325、アプリケーションサーバ140の認証要求を受け付ける認証要求受付部1331、認証要求に従ってユーザ端末110へバイオメトリクス証明書または生体情報を要求する要求部1340、ユーザ端末110よりデータを受信するデータ受信部1325、受信したバイオメトリクス証明書の署名および有効性を検証するＢ証明書検証部1341、ユーザより送付されたバイオメトリクス証明書に対応するモーダル証明書の保証ＦＡＲ値によりアプリケーションサーバ140からの認証要求を満たせるか、どのような手段の組み合わせか選択する有効性検証部1342、ユーザ端末110よりデータ受信部1325を介して生体情報を受け付ける生体情報受付部1350、生体情報と対応するバイオメトリクス証明書を照合する生体照合部1351、認証結果をアプリケーションにデータ送信部1320を介して送信する認証結果送信部1352よりなる。
【００４３】
また認証結果送信部の結果により、課金を行う課金部1360を持つ。次のような課金が考えられる。
・アプリケーションの認証要求１回に対し課金を行う。
・ユーザへの認証サービス提供に対し課金を行う。
・アプリケーションの安全性要求レベルに応じて課金を行う。
以上のうち、認証要求レベルに応じた課金を行うことにより、セキュリティコストとリスクのバランスを取ることができ、生体認証技術の普及が期待できる。
【００４４】
さらに認証サーバ170にモーダル証明書の保証ＦＡＲ値の検証機能を持つ場合、生体照合部1351による照合スコアを照合ログ1370にもち、照合ログによりＦＡＲを検証する検証部1371を備える実施例について説明する。照合ログ1370は、他人の生体による照合スコア及び本人の生体情報による照合スコアを格納する。
【００４５】
図１５に認証サーバ170におけるモーダル証明書の保証ＦＡＲ値を検証するための照合ログを蓄える処理フローを示す。ステップ1410では、ユーザ端末110よりバイオメトリクス証明書を受け取る。このステップはステップ701に相当する。ステップ1420では、失効リスト1415を検索し一致した利用があれば次に進む。無ければステップ1470へ進む。ステップ1420はステップ703に相当する。ステップ1430では、ユーザ端末110へ生体情報を要求する。ステップ1440では、ユーザ端末110より取得した生体情報を受信する。この生体情報は、他人のユーザ端末110を取得するなど不正ユーザの生体情報の可能性がある。ステップ1450では、ステップ1440で受信した生体情報を用いて生体照合を行い、スコアを得る。ここは失効したバイオメトリクス証明書のテンプレートと不正ユーザの生体情報とを照合する処理であり、不一致の確率が高いが、他人を誤って受け入れる確率（ＦＡＲ）だけ一致の判定があり得る。ステップ1460では、照合スコアを他人照合のログとして記録し、処理終了する。ステップ1470では、通常の照合ルーチンを行う（図７、ステップ612以降）。
【００４６】
ここでは失効リストに挙がったバイオメトリクス証明書による照合を盗難や紛失などによる他人のなりすましと見なし、他人の生体情報による照合スコアを得る。ステップ1470においても、本人の生体情報による照合スコアを得ることも可能である。
【００４７】
図１６に認証サーバ170において特定の照合アルゴリズムについてのＦＡＲの検証フローを示す。ステップ1510では、図１３に示すモーダル証明書の閾値を入力する。また変数Ｎ，ＭについてＮ＝０、Ｍ＝０とする。ステップ1520では、モーダル証明書の照合アルゴリズム識別番号を検索キーに他人照合のログ1455を検索する。ステップ1530では、検索したスコアが閾値未満か否かを判定する。未満であればステップ1540へ進み、そうでなければステップ1545へ進む。ステップ1540では、件数Ｎ及び他人の生体情報を本人のものと誤った回数Ｍを各々インクリメントし（Ｎ＋＋，Ｍ＋＋）、ステップ1550へ進む。ステップ1545では、件数Ｎをインクリメント（Ｎ＋＋）する。ステップ1550では、次の照合ログがあれば、ステップ1520へ戻る。ステップ1560では、ＦＡＲ＝Ｍ／Ｎを計算する。ステップ1570では、モーダル証明書の保証ＦＡＲ値を下回っているか検証する。
【００４８】
以上の処理フローにおいて、Ｎの数が十分大きくないと、統計的に信頼性のある検証とならない。統計的な信頼性を確保するためには、Ｎは３／ＦＡＲ以上の数量が必要である。ステップ1570では、求めたＦＡＲが統計的な信頼性があるものか否かについても確認を行った上でバイオメトリクス証明書の数値を検証する。このような検証機能を持つことで、アプリケーションサーバ140へ安全性要求レベルを確実に保証できることをアピールできる。
【００４９】
本人の生体情報による照合（失効リストにない照合）のスコアのログについては、次のような解析が考えられる。
（１）他人による不正利用解析：ある端末のすべてのバイオメトリクス証明書の照合スコアが急激に低下した後、スコアに上昇が見られない。
（２）不適テンプレート解析：ある端末の特定のバイオメトリクス証明書の照合スコアが安定しない。
（３）偽造攻撃解析：多数の照合を繰り返しても照合スコアに全く変化が見られない。
【００５０】
（１）に対してはユーザに端末の状況を確認して、確かに不正利用されているのであれば、失効リストに登録しその期間の照合ログを他人照合ログとして蓄える。（２）に対してはユーザに対してそのテンプレートが該当ユーザに適していない旨通知し、他の手段を選択するように勧告する。（３）に対してはユーザの端末の状況を確認して、偽造攻撃への対策を立てる必要がある。例えば該当するモーダルを失効させるなど対策がある。
【００５１】
本発明は、またユーザ端末がその持ち主に関するモーダルの閾値および単独で用いた場合のＦＡＲ（異なる生体が誤って一致する確率）、ＦＲＲ（同一の生体が誤って不一致となる確率）の情報を保持し、この情報を認証時に認証サーバへ送り、認証に利用し、認証が成功した場合に認証サーバがＦＲＲの情報を更新することにより、利用者ごとに最適化された認証を行い、利便性を向上させたシステムを提供する。
【００５２】
図１７に認証サーバがない場合の認証処理のフローを示す。図６及び図７に示す認証処理のフローと比較すれば明らかなように、アプリケーションサーバ140が認証サーバ170の行う処理を実行する。この認証処理フローにはステップ618〜620に相当する処理がないが、ステップ620の正当性判定はアプリケーションサーバ140が認証サーバ170の行った本人判定の信用性を判定することになるので、認証サーバがない場合には不要となる。
【００５３】
図１８に利用者ごとに最適化した認証を行う場合に、バイオメトリクス証明書情報を構成する情報の例を示す。データ1701は、バイオメトリクス証明書の発行者の署名を検証するための公開鍵を特定する情報、例えば発行者の証明書のシリアル番号などである。データ1702は、バイオメトリクス証明書の発行者の名前、例えばX.500名などである。データ1703は、バイオメトリクス証明書の有効期限、例えば開始日時と終了日時などである。データ1704は、バイオメトリクス証明書の発行者が発行した証明書の通し（シリアル）番号である。データ1705は、バイオメトリクス証明書のテンプレートを生成したユーザを一意に特定する情報、例えば、メイルIDや携帯電話番号などである。データ1706は、バイオメトリクス証明書のテンプレートを用いた本人認証手段（モーダル）を特定する情報、例えばA社の指紋照合：A001、B社の顔照合：B002、C社の声紋照合：C002などとユニークに付番するなどである。
【００５４】
データ1707は、照合の基準となる情報（テンプレート）である。複数のモーダルを用いる場合は、各モーダルのテンプレートを保持する。データ1708は、当該モーダルの照合結果のスコアに対して、一致（照合成功）か不一致（照合失敗）かを判定するための閾値である。複数のモーダルを用いる場合は、各モーダルの閾値を保持する。データ1709は、当該モーダルのＦＡＲ値である。複数のモーダルを用いる場合は、各モーダルの保証ＦＡＲ値を保持する。データ1710は、過去において当該モーダルを用いて照合した結果、正当な持ち主（本人）が入力したにもかかわらず誤って不一致（本人拒否）となった回数である。複数のモーダルを用いる場合は、各モーダルの不一致回数を保持する。データ1711は、過去において当該モーダルを用いて照合を行った回数である。複数のモーダルを用いる場合は、各モーダルの照合回数を保持する。データ1712は、データ1701〜1711の完全性を保証するための情報、例えばMACや発行者のデジタル署名などである。
【００５５】
本発明は、また任意の生体情報を不定回数繰返し照合することにより、システム全体としてのＦＡＲ（他人を誤って受け入れる確率）が要求値以下となることを保証し、かつＦＲＲ（本人を誤って拒否する確率）も小さくし、また使用するモーダルを利用者が自由に選択可能とすることで利便性を向上させたシステムを提供する。
【００５６】
図１９及び図２０に生体情報を不定回数繰返し照合し、かつ利用者ごとに最適化した認証を行う場合の認証フローを示す。図１９及び図２０は、ユーザ端末110と認証サーバ170に関連する部分を記述したものであり、認証フローにおいてアプリケーションサーバ140に関連する部分は、図６及び図７と同じである。
【００５７】
ステップ1810では、認証サーバ170は、ユーザ端末110に対し認証要求を行う。ステップ1811では、ユーザ端末110は、認証要求を受け付ける。ステップ1812では、ユーザ端末110はバイオメトリクス証明書を認証サーバ170へ送付する。ここで送付するバイオメトリクス証明書は、図１８に示すバイオメトリクス証明書である。ステップ1813では、認証サーバ170は、バイオメトリクス証明書を受け付ける。ステップ1814では、認証サーバ170は、バイオメトリクス証明書の有効性を確認する。有効であればステップ1816へ行く。無効であればユーザ端末に通知し、ステップ1815へ進む。ステップ1815では、ユーザ端末110にサービスの提供をできない旨表示する。ステップ1816では、認証サーバは、アプリケーションが要求する安全性要求レベル（ＦＡＲ）を満たすよう、複数回の照合結果を統合した認証スコアに対する統合閾値（本人閾値および他人閾値）を計算する。具体的な計算方法は後述する。また照合回数の最大（N）を定める。ステップ1830では、認証サーバ170は、ユーザ端末110に対し生体情報を要求する。ステップ1831では、ユーザ端末110は生体情報の要求を受け付ける。ステップ1832では、ユーザ端末110で、利用者の生体情報を取得する。取得する生体情報の種別（指紋、顔など）は任意であり、利用者が自由に選択できる。同一の種別の生体情報を複数回繰り返して取得してもよい。ステップ1833では、ユーザ端末110は、生体情報を認証サーバ170へ送付する。ステップ1834では、認証サーバ170は、生体情報を受け付ける。
【００５８】
ステップ1835では、認証サーバ170は、バイオメトリクス証明書中のテンプレートと、ユーザ端末から送付された生体情報を照合し、バイオメトリクス証明書中の閾値を基準にして一致（照合成功）か不一致（照合失敗）かを判定する。ステップ1836では、ステップ1835の照合結果に従って認証スコアを更新する。認証スコアの具体的な計算方法は後述する。ステップ1837では、認証スコアが本人閾値以上ならばステップ1840へ進む。そうでなければステップ1850へ進む。ステップ1840では、認証サーバは、ユーザ端末110の利用者が正当である（本人である）と判定する。ステップ1841では、各モーダルに関してステップ1835で照合を行った回数および不一致回数を利用者のバイオメトリクス証明書に反映させる。ステップ1842では、認証サーバ170は、更新されたバイオメトリクス証明書の情報に認証サーバの署名を添付して、ユーザ端末110に送り返す。ステップ1843では、ユーザ端末110は、認証サーバ170から更新されたバイオメトリクス証明書を受け取り、ユーザ端末110内に保持しているバイオメトリクス証明書を置き換える。
【００５９】
ステップ1850では、認証スコアが、他人閾値以下ならばステップ1852に進み、そうでなければステップ1851に進む。ステップ1851では、照合回数が、システムの定める最大回数（Ｎ）以上ならば、ステップ1852へ進み、そうでなければステップ1830へ戻る。ステップ1852では、認証サーバ170は、ユーザ端末110の利用者が正当でない（他人である）と判定する。
【００６０】
i回目の照合に用いたモーダルをMiとしたとき、i回目の照合における一致、不一致の判定には、利用者のバイオメトリクス証明書中のモーダルMiに対応する閾値を用いる。この認証フローでは、図２に示すバイオメトリクス証明書とモーダル証明書の代わりに図１８に示すユーザごとに閾値を設定するバイオメトリクス証明書を使用する。
【００６１】
ステップ1836における認証スコアは、利用者が正当な人物である確率（本人確率）として計算する。具体的には、i回目の照合結果をxi(0：不一致、1：一致）、利用者のバイオメトリクス証明書中に記録された、モーダルMiのFARをFARMi、FRR（不一致回数／照合回数）をFRRMiとしたとき、n回の照合を繰り返した場合の本人確率Pnは、各照合が独立な試行であると仮定し、ベイズの定理を用いて、以下の式により計算する。
【００６２】
【数１】
【００６３】
【数３】
【００６４】
【数４】
【００６５】
【数５】
ＦＡＲTotal≦ＦＡＲReq （数６）
が導出される。
【００６６】
（数６）は、本実施例におけるシステムの安全性（FARTotal）が、アプリケーションの要求する安全性要求レベル（FARReq）を満たしていることを意味する。
【００６７】
またステップ1816において、最大照合回数（Ｎ）および他人閾値を適切に設定することで、本システムの利便性、すなわちＦＲＲと平均入力回数を調節する。
【００６８】
本発明の認証サーバは、インターネット上で生体認証に関わるデータをデータベース機能により管理し、インターネット上のアプリケーションサーバにより、認証サーバの生体認証機能が共用される一種のSAN（Storage Area Network）と位置付けることもできる。このことにより、従来、アプリケーションサーバで個々に管理していた個人認証情報を安全性の保証されたストレージサービスとして一括に管理・提供することで保守性や利便性を向上することが可能である。
【００６９】
【発明の効果】
本発明によれば、各端末の持ち主は自分に適した本人認証方式を選択することが可能となる。またサービスアプリケーションの提供者は、セキュリティレベルを保った本人認証を行うことにより、より安全なサービスの提供が可能となる。更に本発明の認証方式は、システムに要求された任意の安全性レベルを満たしながら、本人を誤って拒否する確率が低く利便性の高い本人認証が可能となる。
【図面の簡単な説明】
【図１】実施形態の本人認証システムの全体構成図である。
【図２】バイオメトリクス証明書の構成例を示す図である。
【図３】本人認証手段（モーダル）証明書の構成例を示す図である。
【図４】バイオメトリクス証明書の失効リスト証明書の例を示す図である。
【図５】モーダル証明書の失効リスト証明書の例を示す図である。
【図６】実施形態の本人認証のフローチャートである。
【図７】実施形態の本人認証のフローチャート（続き）である。
【図８】実施形態のバイオメトリクス証明書の有効性検証のフローチャートである。
【図９】アプリケーションサーバによる本人認証要求情報例を示す図である。
【図１０】認証サーバによる本人認証結果情報の例を示す図である。
【図１１】実施形態の認証サーバによるアプリケーションの安全性要求に対する適合性判定のフローチャートである。
【図１２】認証サーバにおける要求ＦＡＲ値の決定方法の一例を示す図である。
【図１３】モーダル証明書に複数の閾値とその閾値が保証するＦＡＲ値を記述する例を示す図である。
【図１４】実施形態の認証サーバの構成を示す図である。
【図１５】実施形態の認証サーバにおける保証ＦＡＲ値の検証の準備処理のフローチャートである。
【図１６】実施形態の認証サーバにおける保証ＦＡＲ値の検証処理のフローチャートである。
【図１７】実施形態の認証サーバがない場合の本人認証のフローチャートである。
【図１８】個人ごとに最適化された認証を行う場合のバイオメトリクス証明書の例を示す図である。
【図１９】実施形態の生体情報を不定回数繰返し照合する場合の本人認証のフローチャートである。
【図２０】実施形態の生体情報を不定回数繰返し照合する場合の本人認証のフローチャート（続き）である。
【符号の説明】
110・・・ユーザ端末、140・・・アプリケーションサーバ、170・・・認証サーバ
Claims (11)
- ユーザの提示する生体情報に基づいて本人認証を行う認証方法において、
ユーザからのサービス要求を受け付けたアプリケーションから本人認証のために要求される安全性要求レベルについての情報を受け取り、前記ユーザの端末から提示可能な生体認証手段についての情報を受け取り、受け取った前記生体認証手段の安全性保証レベルについての情報を取得し、前記安全性保証レベルが前記安全性要求レベルを満たす場合に前記ユーザの提示する生体情報に基づいて本人認証を行うことを特徴とする安全性保証付き生体認証方法。 - 前記安全性要求レベル及び前記安全性保証レベルは、各々他人を誤って受け入れる確率（ＦＡＲ）であることを特徴とする請求項１記載の安全性保証付き生体認証方法。
- 前記安全性保証レベルは他人を誤って受け入れる確率（ＦＡＲ）であり、前記安全性要求レベルは年間許容リスクから算出される許容できる他人受入率であることを特徴とする請求項１記載の安全性保証付き生体認証方法。
- 前記生体認証手段についての情報を、バイオメトリクス証明書として受け取り、受け取った前記バイオメトリクス証明書が失効した証明書として登録されているか否かを判定することを特徴とする請求項１記載の安全性保証付き生体認証方法。
- 受け取った前記バイオメトリクス証明書が失効した明細書として登録されている場合に、前記ユーザに要求して生体情報を受け取り、受け取った生体情報を前記バイオメトリクス証明書のテンプレートと照合し、その照合スコアを前記安全性保証レベルの検証のために登録することを特徴とする請求項４記載の安全性保証付き生体認証方法。
- 前記ユーザの端末から複数種の前記生体認証手段についての情報を受け取り、受け取った前記生体認証手段の安全性保証レベルについての情報を各々取得し、前記安全性保証レベルが前記安全性要求レベルを満たすような生体認証手段を選択し、選択された生体認証手段に関する生体情報を前記ユーザに要求することを特徴とする請求項１記載の安全性保証付き生体認証方法。
- ユーザの提示する複数の生体情報に基づいて本人認証を行う認証方法において、
ユーザからのサービス要求を受け付けたアプリケーションから本人認証のために要求される本人認証レベルについての情報を受け取り、前記本人認証レベルを満たすような本人閾値を計算し、前記ユーザの提示する生体情報と基準となるテンプレートとを照合してその照合結果から認証スコアを計算し、前記認証スコアが前記本人閾値を越えるまで前記ユーザによる生体情報の提示、照合及び本人閾値の計算を繰り返すことを特徴とする安全性保証付き生体認証方法。 - 前記ユーザの端末から複数種の生体認証手段についての精度に関する情報を受け取り、前記精度に関する情報を用いて、前記照合結果から前記認証スコアを計算することを特徴とする請求項７記載の安全性保証付き生体認証方法。
- 前記照合の際の基準となる閾値をユーザごとに設定することを特徴とする請求項７記載の安全性保証付き生体認証方法。
- ユーザの提示する生体情報に基づいて本人認証を行う装置において、
ユーザからのサービス要求を受け付けたアプリケーションから本人認証のために要求される安全性要求レベルについての情報を受信する手段と、前記ユーザの端末から提示可能な生体認証手段についての情報を受信する手段と、受け取った前記生体認証手段の安全性保証レベルについての情報をデータベースから取得する手段と、前記安全性保証レベルが前記安全性要求レベルを満たす場合に前記ユーザの端末から受信した生体情報に基づいて本人認証を行う手段とを有することを特徴とする認証サービスを行う装置。 - 前記生体認証手段についての情報はバイオメトリクス証明書に含まれる情報であり、さらに受け取った前記バイオメトリクス証明書が失効した証明書として登録されているか否かを判定する手段を有することを特徴とする請求項１０の認証サービスを行う装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002050884A JP4087126B2 (ja) | 2002-02-27 | 2002-02-27 | 安全性保証付き生体認証方法及び認証サービスを行う装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002050884A JP4087126B2 (ja) | 2002-02-27 | 2002-02-27 | 安全性保証付き生体認証方法及び認証サービスを行う装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003256376A JP2003256376A (ja) | 2003-09-12 |
| JP4087126B2 true JP4087126B2 (ja) | 2008-05-21 |
Family
ID=28662999
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002050884A Expired - Lifetime JP4087126B2 (ja) | 2002-02-27 | 2002-02-27 | 安全性保証付き生体認証方法及び認証サービスを行う装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4087126B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105099700A (zh) * | 2015-07-27 | 2015-11-25 | 中国联合网络通信集团有限公司 | 一种认证方法、服务器及*** |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005107592A (ja) * | 2003-09-26 | 2005-04-21 | Bank Of Tokyo-Mitsubishi Ltd | 認証方式選択システムおよび方法 |
| JP2005149093A (ja) * | 2003-11-14 | 2005-06-09 | Toppan Printing Co Ltd | アクセス権制御機能付記憶装置、アクセス権制御機能付記憶装置の制御プログラム、アクセス権制御方法 |
| JP4545480B2 (ja) * | 2004-04-28 | 2010-09-15 | 株式会社エヌ・ティ・ティ・ドコモ | 電子署名生成装置、ウェブサーバ、生体情報認証装置、及びユーザ認証システム |
| JP4331661B2 (ja) * | 2004-09-02 | 2009-09-16 | 東芝テック株式会社 | 個人認証装置 |
| WO2007023756A1 (ja) * | 2005-08-24 | 2007-03-01 | Nec Corporation | 本人認証システム、ユーザ端末、サービス事業者装置、信頼性保証サーバ、これらの動作方法と動作プログラム |
| JP4684100B2 (ja) * | 2005-12-26 | 2011-05-18 | 株式会社日立製作所 | 認証システムおよび認証方法 |
| US9112705B2 (en) | 2006-02-15 | 2015-08-18 | Nec Corporation | ID system and program, and ID method |
| JP4819542B2 (ja) | 2006-03-24 | 2011-11-24 | 株式会社日立製作所 | 脆弱性検証付きのバイオメトリクス認証システムおよび方法 |
| EP2012249A1 (en) | 2006-04-21 | 2009-01-07 | Mitsubishi Denki Kabushiki Kaisha | Authenticating server device, terminal device, authenticating system and authenticating method |
| EP2053777B1 (en) * | 2006-08-18 | 2016-01-13 | Huawei Technologies Co., Ltd. | A certification method, system, and device |
| JP5127469B2 (ja) * | 2008-01-11 | 2013-01-23 | 株式会社東芝 | サーバ装置、リファレンス保管装置及びリファレンス生成装置 |
| JP5204556B2 (ja) * | 2008-05-29 | 2013-06-05 | 株式会社日立製作所 | ワークフローサーバ、ワークフロー管理方法、ワークフロー管理プログラム、および、ワークフロー管理プログラムを記録した記録媒体 |
| JP4858579B2 (ja) * | 2009-06-29 | 2012-01-18 | 日本電気株式会社 | 認証代行システム |
| JP2011215753A (ja) * | 2010-03-31 | 2011-10-27 | Nomura Research Institute Ltd | 認証システムおよび認証方法 |
| US9621350B2 (en) * | 2011-06-30 | 2017-04-11 | Cable Television Laboratories, Inc. | Personal authentication |
| JP5753772B2 (ja) * | 2011-12-12 | 2015-07-22 | 株式会社日立製作所 | 生体認証システム |
| US8689310B2 (en) * | 2011-12-29 | 2014-04-01 | Ebay Inc. | Applications login using a mechanism relating sub-tokens to the quality of a master token |
| EP3101576B1 (en) * | 2014-01-31 | 2019-12-18 | Ricoh Company, Ltd. | Access control device, communication system, program, and access control method |
| KR102349452B1 (ko) * | 2015-03-05 | 2022-01-12 | 삼성전자주식회사 | 사용자 인증 방법 및 이를 지원하는 머리 착용형 장치 |
| JP6555983B2 (ja) * | 2015-08-27 | 2019-08-07 | Kddi株式会社 | 認証方式を決定する装置、方法及びプログラム |
| CN105303387B (zh) * | 2015-10-14 | 2021-01-15 | 珠海格力电器股份有限公司 | 空调器及其解锁方法 |
| WO2017079795A1 (en) * | 2015-11-09 | 2017-05-18 | Roger Hanna | A distributed user profile identity verification system for e-commerce transaction security |
| CN114596656B (zh) * | 2020-12-03 | 2023-09-19 | 中移互联网有限公司 | 电子通行证处理方法、装置及设备 |
-
2002
- 2002-02-27 JP JP2002050884A patent/JP4087126B2/ja not_active Expired - Lifetime
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105099700A (zh) * | 2015-07-27 | 2015-11-25 | 中国联合网络通信集团有限公司 | 一种认证方法、服务器及*** |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003256376A (ja) | 2003-09-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4087126B2 (ja) | 安全性保証付き生体認証方法及び認証サービスを行う装置 | |
| US7941835B2 (en) | Multi-mode credential authorization | |
| US7864987B2 (en) | Methods and systems for secured access to devices and systems | |
| US8352730B2 (en) | Biometric personal data key (PDK) authentication | |
| Matyáš et al. | Biometric authentication—security and usability | |
| JP4939121B2 (ja) | 各セキュリティチャレンジを特徴付ける１つ以上の誤り率を使用する遂次認証のための方法、システム、およびプログラム | |
| JP3668175B2 (ja) | 個人認証方法、個人認証装置および個人認証システム | |
| US20020112177A1 (en) | Anonymous biometric authentication | |
| US20030101348A1 (en) | Method and system for determining confidence in a digital transaction | |
| JP2017524998A (ja) | 本人照合を行うための方法およびシステム | |
| US20060204048A1 (en) | Systems and methods for biometric authentication | |
| JP4672357B2 (ja) | 認証システム | |
| JP2007080088A (ja) | 利用者認証装置 | |
| EP2254093A1 (en) | Method and system for confirming the identity of a user background of the invention | |
| JP5276554B2 (ja) | 生体情報認証装置および生体情報認証プログラム | |
| CN114036482A (zh) | 基于区块链的数据管理方法、电子设备、存储介质 | |
| JP2011118561A (ja) | 個人認証装置及び個人認証方法 | |
| JP4884052B2 (ja) | 生体認証システム | |
| JP2002366527A (ja) | 本人認証方法 | |
| JPH11306352A (ja) | 生体的特徴の認証精度推定方法及び装置、記録媒体 | |
| Uchenna et al. | Evaluation of a Fingerprint Recognition Technology for a Biometric Security System | |
| WO2007105201A2 (en) | System and method for authenticating a meeting | |
| JP2003091508A (ja) | 生体情報を用いた個人認証サービスシステム | |
| JP2005004253A (ja) | 個人識別システム | |
| AU2011204915B2 (en) | Multi-mode credential authentication |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040826 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070608 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080129 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080220 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110228 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4087126 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110228 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120229 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120229 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130228 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130228 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140228 Year of fee payment: 6 |
|
| EXPY | Cancellation because of completion of term |