(57)【要約】【課題】さまざまなシステム構成のバイオメトリクスに対して、ユーザの希望やサーバのポリシーに応じた本人認証を提供する。【解決手段】サーバとクライアントの双方が、機能として備える生体認証を含んだ本人認証方法を管理し、サーバとクライアントが、所有する本人認証方法を交換してサーバのアプリケーションのポリシーとユーザの希望に合致した本人認証方法を選択する。さらに、サーバが、クライアントでの生体照合を認める場合は、選択結果に追加する。また、プライバシー保護のため、クライアントからサーバへ送付する生体情報の利用範囲を限定する要求情報送付する。また、クライアントで生体照合を行う方法を選択した場合、照合結果と基準となったテンプレートをサーバに通知する。また、サーバが信用する本人認証機能を持つ他のサーバに生体照合を依頼する場合、当該他のサーバの情報を追加する。【選択図】  図１
2004348308.tif 000002
【特許請求の範囲】
【請求項１】
情報サービスを提供するサーバと、前記情報サービスを享受するクライアントの間で行う本人認証システムであって、
前記サーバは、実施可能な生体認証方法を前記クライアントに通知し、
前記クライアントは実施可能な生体認証方法を選択して通知し、
前記サーバは、自サーバのセキュリティポリシーに合致する生体認証方法を、選択され通知された中から決定して、クライアントに通知し、
前記クライアントは、前記決定された生体認証方法に従う生体情報を前記サーバへ送付し、
前記サーバは、送付された前記生体情報により生体照合を実行して本人認証する。
【請求項２】
情報サービスを提供するサーバと、前記情報サービスを享受するクライアントの間で行う本人認証システムであって、
前記サーバは、実施可能な生体認証方法を前記クライアントに通知し、
前記クライアントは実施可能な生体認証方法を選択して返信し、
前記サーバは、自サーバのセキュリティポリシーに合致する生体認証方法を、選択され通知された中から決定して、チャレンジコードと共にクライアントに通知し、
前記クライアントは、前記決定された生体認証方法に従う生体情報と、公開鍵暗号のユーザ秘密鍵にて前記サーバからの前記チャレンジコードを暗号化した結果とを前記サーバへ送付し、
前記サーバは、公開鍵暗号に基づくユーザ公開鍵により前記暗号化データを復号化して前記チャレンジコードを検証し、
当該生体情報により生体照合を実行して本人認証する。
【請求項３】
請求項２に記載の本人認証システムであって、
前記クライアントは、前記サーバが実施可能な生体認証方法として、前記クライアントでの生体認証が含まれることが通知された場合に、前記クライアントが持つ生体認証方法を前記選択結果に追加して返信する。
【請求項４】
請求項２に記載の本人認証システムであって、
前記クライアントは、前記生体照合において、前記クライアントのユーザに関わる生体情報の利用範囲を限定する要求情報を添付して前記サーバへ送付する。
【請求項５】
請求項２に記載の本人認証システムであって、
前記クライアントで生体照合を行う方法を選択した場合、前記クライアントでの生体照合で本人と確認された場合に、公開鍵暗号におけるユーザ秘密鍵で前記サーバからのチャレンジコードを暗号化し、生体照合の結果とともに、照合の基準となった登録情報を前記サーバへ送付し、前記サーバでユーザの登録情報の有効性を確認する。
【請求項６】
請求項２に記載の本人認証システムであって、
前記サーバは、前記サーバの生体認証方法を通知する情報に、認証サーバの生体認証方法の情報を追加する。
【請求項７】
請求項２に記載の本人認証システムであって、
前記サーバのセキュリティポリシーの判定基準に、前記クライアントに関わる安全性保証レベルを用いる。
【請求項８】
請求項２に記載の本人認証システムであって、
前記サーバで設定するセキュリティポリシーの判定基準として、生体照合方法における他人受入率を用いる。
【請求項９】
請求項２に記載の本人認証システムであって、
前記サーバで設定するセキュリティポリシーの判定基準として、本人認証のために入力された情報の質により評価した結果である安全性を用いる。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、非対面でサービスを提供するサーバ装置と、情報サービスを受けるクライアント装置の間の本人認証プロトコルに関する。
【０００２】
【従来の技術】
ブロードバンドや携帯電話の普及により非対面の認証の安全性への要求が高まっている。この要求に基づき、従来、高セキュリティのエリアの入退室に利用されていた生体認証技術を応用した認証システムが提案されている。
【０００３】
上記に関連する従来技術として、以下がある。
【０００４】
従来の生体認証と連携した本人認証では、ＰＣと接続するインターフェース（ＵＳＢ）を持った名刺大の筐体に静電容量方式の指紋入力機能と指紋登録機能と指紋認証機能と公開鍵暗号機能（ＰＫＣＳ）に準拠した機能を持っており、あらかじめ筐体に登録した指紋情報に基づいた指紋照合の結果により筐体内の秘密鍵を活性化し、その活性化した秘密鍵を用いてＰＫＩによる本人認証や署名を行っている（例えば、非特許文献１に記載の装置を参照。）。
【０００５】
また、複数のバイオメトリクスの登録データを一元管理して照合する認証サーバを設置し、認証サーバでは、認証を提供する電子決裁やＥＲＰアプリケーション毎に認証手段の組合せポリシーをＡＮＤやＯＲで設定する機能を持ち、端末の認証では、端末のソフトを介して認証に必要なテンプレートをダウンロードして端末にて本人認証する。また、端末ソフトでは、別途インストールした本人認証や署名を行うＰＫＩの端末ソフトと連動する（例えば、非特許文献２に記載のシステム）。
【０００６】
また、ＰＫＩと連携したバイオメトリクスの認証において、バイオメトリクスの登録データとＰＫＩの証明書を関連付ける情報を持ち、バイオメトリクス登録データとＰＫＩの証明書の情報について、ユーザの同一性の確認を行う上でバイオメトリクスの認証を行う本人認証システムが提案されている（例えば、特許文献１参照）。
【０００７】
また、Ｘ．５０９の拡張領域にバイオメトリクステンプレートデータのフィールドを設け、バイオメトリクスデータを格納したのＰＫＩ証明書の書式について提案しているものもある（非特許文献３参照。）。
【０００８】
【非特許文献１】
「Ｂｉｏ−Ｋｅｙｓ  Ｓｏｎｙ  ＦＩＵ−７１０」，ＰＣ  Ｍａｇａｚｉｎｅ，Ｖｏｌ．２０，Ｎｏ．１１，ＰＰ．  １７４（２００１／７／１２）
【非特許文献２】
Ｍａｎｄｙ  Ａｎｄｒｅｓｓ，「Ｃｅｎｔｒａｌｉｚｅｄ  ｓｅｃｕｒｉｔｙ  ｋｅｙ  −  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｓｕｉｔｅ  ４．０  ｍｅａｎｓ  ｍａｎａｇｉｎｇ  ｍｕｌｔｉｐｌｅ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｓｃｈｅｍｅｓ  ｉｓ  ｅａｓｙ  ａｎｄ  ｃｈｅａｐ」，ＩｎｆｏＷｏｒｌｄ，  Ａｕｇ．１３，２００１，  Ｖｏｌ．２３，ｉ３３，ｐ４４
【特許文献１】
特開２０００−２１５２８０号公報
【非特許文献３】
Ｓ．Ｓａｎｔｅｓｓｏｎ他，「Ｉｎｔｅｒｎｅｔ  Ｘ．５０９  Ｐｕｂｌｉｃ  Ｋｅｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  Ｑｕａｌｉｆｉｅｄ  Ｃｅｒｔｉｆｉｃａｔｅｓ  Ｐｒｏｆｉｌｅ」，ＲＦＣ３０３９，Ｐａｇｅ１１（２００１／１）
【０００９】
【発明が解決しようとする課題】
従来技術では、次のような課題がある。
【００１０】
非特許文献１の技術では、指紋照合の結果を受けて、サーバとＰＫＩの本人認証を行うが、サーバ側では、クライアント側で実行した秘密鍵の持ち主の認証をどのように実行しているか不明である。このため、アプリケーションが要求するセキュリティポリシーを判断できない。また、秘密鍵の持ち主認証方法が、トークンに実装された単一のバイオメトリクスに限定されるため、マスユーザに展開した場合に、対応できない場合があるという生体認証特有の問題がある。
【００１１】
非特許文献２の技術は、組織内ネットワークを対象にしたシステムであり、あらかじめ組織が導入したバイオメトリクスに限定して、ネットワークアプリケーションサーバにバイオメトリクス認証機能を提供する。このため、インターネットなどの公衆網を介した不特定多数のユーザを対象とした場合のバイオメトリクス認証を想定した場合に、それぞれのユーザの要求に応える本人認証を実現できない。また、ユーザのプライバシー情報である生体情報をネットワークで転送する必要があり、プライバシー保護に問題がある。また、認証ポリシーは、認証サービスを行うサーバに管理されており、サービスを提供するアプリケーションのポリシーを動的にコントロールできない。
【００１２】
特許文献１の技術は、クライアントでのバイオメトリクスを認証するシステムであり、さまざまなバイオメトリクス認証モデルのシステムに対応していない。
【００１３】
非特許文献３は、証明書にフィールドを定義したのみで、様々な特有な問題（経年変化や未対応など）のあるバイオメトリクスと連携した本人認証をどのように実行するか何も定義していない。
【００１４】
【課題を解決するための手段】
本発明は、サーバとクライアントの双方が、それぞれが機能として所有する生体認証を含んだ本人認証方法を管理し、サーバとクライアントとの間のセッションにおいて、お互いの所有する本人認証方法を交換してサーバのアプリケーションのポリシーとユーザの希望に合致した本人認証方法を選択する本人認証システムを提供する。
【００１５】
また、サーバのポリシーによって、クライアントでの生体照合まで行う本人認証方法を認める場合は、この本人認証方法を選択に追加してもよい。
【００１６】
また、プライバシーを保護するため、クライアントからサーバへ送付する情報に生体情報の利用範囲を限定する要求情報を添付してもよい。
【００１７】
また、クライアントで生体照合を行う方法を選択した場合、照合の結果と照合の基準となった登録情報をサーバに通知してもよい。
【００１８】
また、サーバが信用する本人認証サーバ機能を持つ他のサーバに生体認証を依頼する場合、生体認証方法として、上記他のサーバの情報を追加してもよい。
【００１９】
【発明の実施の形態】
本発明の実施の形態を以下の順で説明する。
（１）システム構成
（２）本人認証モデル
（３）生体認証プロトコル
（４）クライアントの機能構成
（５）サーバの機能構成
（６）認証サーバの機能構成
（７）各種情報の設定画面の例
（１）システム構成
図１に本実施例全体のシステム構成を示す。
【００２０】
本実施例のシステムは、望ましくは公開鍵基盤上に構築されており、各装置やサーバ装置はインターネットなどの通信網（以下、インターネットという）に接続され、相互にＩＰ（インターネットプロトコル）で通信できるようになっている。
【００２１】
各ユーザはそれぞれのユーザが所有する端末装置（以下、クライアントという）１１０より、インターネット１２０に接続し、各サーバ装置（以下、ＡＰサーバという）１４０へサービスを要求する。インターネット１２０へは、公開鍵を認証する認証局装置（以下、ＣＡ（Ｃｅｒｔｉｆｉｃａｔｅ  Ａｕｔｈｏｒｉｔｙ）という）１５０、生体認証の登録情報（以下、テンプレートという）を認証するバイオメトリック認証局装置（以下、ＢＣＡ（Ｂｉｏｍｅｔｒｉｃ  Ｃｅｒｔｉｆｉｃａｔｅ  Ａｕｔｈｏｒｉｔｙ）という）１６０、生体照合をＡＰサーバ１４０の依頼で代行する認証サーバ装置（以下、認証サーバという）１７０などが接続されている。
【００２２】
クライアント１１０が備える生体認証機能はそれぞれの方法により、次の３つの場合がある。
・認証情報取得機能１１１と個人情報格納機能１１２をクライアント１１０が持つ。
・認証情報取得機能１１１のみをクライアント１１０が持つ。
・認証情報取得機能１１１と照合機能１１３と個人情報格納機能１１２をクライアント１１０が持つ。
【００２３】
各ＡＰサーバ１４０は、各ユーザに対してサービスを提供しており、それぞれのサービスに対する本人認証ポリシーを管理し、クライアント１１０から提示された情報に基づいて本人認証を実行する機能を備える。
【００２４】
ＣＡ１５０は、ユーザやクライアント１１０、ＡＰサーバ１４０、ＢＣＡ１６０、認証サーバ１７０の公開鍵を認証し、その証明書を発行する。
【００２５】
ＢＣＡ１６０は、ユーザの生体認証のためのテンプレートを認証し、その証明書を発行する。
【００２６】
認証サーバ１７０は、ＡＰサーバ１４０に代わってさまざまな生体認証機能を用意し、ＡＰサーバ１４０へ生体認証結果を提供する。
【００２７】
本実施例は、このように生体認証方法の多様性に対して、ＡＰサーバ１４０へサービスを要求するユーザが正当な権限を持つ人物か確認を行うため、公開鍵による電子認証と生体認証を連携させるプロトコルを提供する。
【００２８】
図１に示す各装置の機能構成を図２に示す。各装置は、処理装置（ＣＰＵ）２１０に接続された、情報入力装置２４０、表示装置２２０、記憶装置２５０、通信装置２３０から構成されている。処理手順（プログラム）は記憶装置２５０に記憶されており、処理装置２１０はプログラムを呼び出し、実行することにより、表示装置２２０を用いてユーザへ操作要求を行ったり、情報入力装置２４０からユーザからの入力を受け付けたり、通信装置２３０により外部装置と情報のやり取りを行ったり、各装置が備えるその他の機能を実現したりする。
【００２９】
上記プログラムは，あらかじめ記憶装置２５０に格納されているか，可搬型記憶媒体または通信媒体（通信ネットワークまたは通信ネットワークを伝播する搬送波）を介して他の装置から記憶装置２５０に格納されてもよい。
（２）本人認証モデル
（２−１）ＰＫＩの本人認証モデル
公開鍵基盤を用いたクライアント１１０とＡＰサーバ１４０との間の本人認証モデルについて説明する。
【００３０】
ユーザはあらかじめ、公開鍵と対となる秘密鍵（ｐｒｉｖａｔｅ  ｋｅｙ）を生成し、ＣＡ１５０に認証を受け、公開鍵証明書を発行して貰う。ユーザのクライアント１１０は、認証された公開鍵と対となる秘密鍵を保管している。
【００３１】
本人認証では、クライアント１１０よりサービスを要求されたＡＰサーバ１４０が、乱数生成機能が生成したチャレンジコードをクライアント１１０へ送付し、クライアント１１０の署名機能が秘密鍵でチャレンジコードを暗号化してデジタル署名を生成し、ＡＰサーバ１４０へ返送する。ＡＰサーバ１４０は、証明書の公開鍵を使って復号したデータがチャレンジコードと一致するか検証することにより、サービスを要求した証明書の人物であるか確認する。
【００３２】
この本人認証は、本人だけが秘密鍵を持っていることを認証の拠り所とした、所有物による本人認証となっている。
（２−２）クライアント照合型の生体認証モデル
生体認証の照合処理をクライアント１１０側で行う処理のモデルを図３に示す。このモデルは生体認証のテンプレートの管理方法により次の２つに分けられる。
・クライアント１１０側でテンプレートを管理するクライアント管理方法
・サーバ側（ＢＣＡ１６０での管理も含む）で各ユーザのテンプレートを一括管理するサーバ管理方法。
【００３３】
クライアント管理方法では、あらかじめＢＣＡ１６０に認証されたテンプレート１５をクライアント１１０にインストールしておく。このテンプレート１５と認証情報取得機能１１１が収集した生体情報とを照合機能１１３が照合し、本人認証結果をＡＰサーバ１４０へ送付する。
【００３４】
サーバ管理方法では、同様にＢＣＡ１６０に認証されたテンプレート１５を認証時にクライアント１１０へ送付し、このテンプレート１５と認証情報取得機能１１１が収集した生体情報とを照合機能１１３が照合し、本人認証結果をＡＰサーバ１４０へ送付する。
（２−３）サーバ照合型の生体認証モデル
生体認証の照合処理を（アプリケーション）サーバ側で行う処理のモデルを図４に示す。このモデルは生体認証のテンプレートの管理方法により次の２つに分けられる。
・サーバ側（ＢＣＡでの管理も含む）で各ユーザのテンプレートを一括管理するサーバ管理方法。
・クライアント１１０側で各ユーザがテンプレートを管理するクライアント管理方法
サーバ管理方法では、クライアント１１０の認証情報取得機能１１１が収集された生体情報とユーザのＩＤをＡＰサーバ１４０へ送付し、ＡＰサーバ１４０では、ユーザのＩＤにより検索したテンプレート１５と生体情報とを照合機能１１３が照合することで本人認証を行う。
【００３５】
クライアント管理方法では、クライアント１１０の認証情報取得機能１１１が収集した生体情報とテンプレートとをＡＰサーバ１４０へ送付し、ＡＰサーバ１４０は、送付されたテンプレート１５と生体情報を照合することで本人認証を行う。
【００３６】
ここで、テンプレート１５はＢＣＡ１６０により、あらかじめ認証されていることとする。
（２−４）課題
（２−１）で示したＰＫＩの本人認証と、（２−２）（２−３）で示した生体認証を単純に併用しただけでは、以下の問題がある。
・生体認証とＰＫＩの本人認証と、それぞれ付与したＩＤの人物の同一性が保証されていない。
・（２−２）（２−３）で説明したように、さまざまな生体認証方法が提案されており、それぞれの生体認証方法を運用時に選択して本人認証するためのプラットフォーム（プロトコル）がない。
・クライアント１１０側で生体認証を完了するモデルでは、アプリケーションを提供する側で、どのような本人認証が行われて本人であると判定されたかを知るプラットフォーム（プロトコル）がない。
【００３７】
これらの課題に対し、本実施例は、クライアント側とサーバ側の持つ機能について折衝し本人認証を行う生体認証機能を決定するプロトコルを明確にし、そのための折衝機能を備えるシステムを提供する。また、生体認証とＰＫＩの本人認証で付与されたＩＤの同一性については、たとえば、特許文献１に開示されているＢＣＡによるデジタル署名により保証する。
（３）クライアント機能構成
図５にクライアント１１０の機能構成を示す。
【００３８】
クライアント１１０は、通信機能２０１、暗号機能２０２、証明書や秘密鍵の管理機能２０３、認証方法交渉機能２０４、認証方法設定機能２０５、認証方法管理機能２０６、クライアント１１０が持つ認証機能２１００、２２００、２３００、２４００などから構成されている。クライアント１１０が持つ認証機能として、次の４種類の場合がある。
・テンプレート格納機能２１２と照合機能２１３と認証情報取得機能２１１を持ち、クライアントで照合を行う認証機能２１００。
・テンプレート格納機能２２２と認証情報取得機能２２１を持ち、サーバで照合を行う認証機能２２００。
・認証情報取得機能２３１を持ち、サーバで照合を行う認証機能２３００。
・照合機能２４３と認証情報取得機能２４１を持ち、サーバから転送されたテンプレートを使ってクライアントで照合を行う認証機能２４００。
【００３９】
クライアント１１０が、異なる認証機能を重複して所有したり、ある構成に関して欠落したりするので、本実施例はクライアント１１０の構成に関わらずにサーバ−クライアント間の本人認証を成立させるもので、サーバの状況によって、認証機能を選択する。
【００４０】
図６にクライアント１１０のもつ認証機能の管理テーブルを示す。この管理テーブルは、各ベンダの各認証機能を一意に特定するＩＤと、認証モデルのタイプとで構成されている。認証モデルは、次の４つのタイプに分類される。
・タイプＳ：サーバ側でテンプレートを管理し、サーバで照合するタイプ
・タイプＣ：クライアントでテンプレートを管理し、クライアントで照合するタイプ
・タイプＤ：サーバ側でテンプレートを管理し、クライアントで照合するタイプ
・タイプＡ：クライアントでテンプレートを管理し、サーバで照合するタイプ
それぞれの認証機能がどのモデルで本人認証を行うか、で識別を行う。
【００４１】
図７にクライアント１１０を利用するユーザによる、認証機能に関する設定項目を示す。認証機能に関する設定項目は、次の５つからなる。
・ユーザ情報：ユーザを一意に識別するＩＤやユーザの証明書情報（例えば、発行したＣＡ名＋シリアル番号）
・テンプレート情報：ユーザが所有するテンプレートとその数
・優先テンプレート：ユーザが最も照合に使いたいテンプレート
・プライバシーモード：生体情報について、秘匿通信を行うかどうかを指定
・利用範囲限定の宣言：アプリケーションに対して、生体情報の利用範囲を要求するアプリケーションを利用するための本人認証に限定する宣言をするかどうかを指定
上記、クライアント１１０の持つテンプレート情報の管理テーブルを図８に示す。テンプレート管理テーブルは、テンプレートを一意に識別するＩＤ（テンプレート発行機関ＢＣＡとそのシリアル番号）と、そのテンプレートの人物のユーザＩＤと、テンプレートを照合する認証機能を一意に特定するＩＤからなる。
（４）サーバ機能構成
図９にＡＰサーバ１４０の機能構成を示す。ＡＰサーバ１４０は、通信機能３０１、暗号機能３０２、証明書や秘密鍵などの管理機能３０３、認証方法交渉機能３０４、認証方法設定機能３０５、認証方法管理機能３０６、ＡＰサーバ１４０の持つ認証機能３１０、３２０、３３０、認証機能の結果を判定する機能３０７を持つ。ＡＰサーバ１４０で機能を持つ認証機能は、次の３種類がある。
・テンプレート管理機能３１２と照合機能３１３とを持ち、サーバで照合する第１の認証機能。
・テンプレート管理機能３２２のみを持ち、クライアント１１０で照合する第２の認証機能。
・照合機能３３０のみを持ち、クライアント１１０から送付されたテンプレートと生体情報をサーバで照合する第３の認証機能。
【００４２】
クライアント１１０でテンプレートを管理して照合する場合は、ＡＰサーバ１４０では対応する認証機能を持つ必要はない。
【００４３】
クライアント１１０と同様に、本実施例はそれぞれの機能構成に依存せずに、サーバ−クライアント間で本人認証を成立させることを特徴としており、クライアントの状況によって、認証機能を選択する。
【００４４】
なお、認証サーバ１７０もＡＰサーバ１４０と同様の構成を備える。
【００４５】
図１０にＡＰサーバ１４０が持つ認証方法（アルゴリズム）の管理するためのテーブルを示す。この管理テーブルは、方法アルゴリズムを一意に識別するＩＤと、テンプレートの管理タイプとで構成される。テンプレートの管理タイプには、次の３つがある。
・タイプＳ：ＡＰサーバ１４０で管理するタイプ
・タイプＣ：クライアントで管理するタイプ
・タイプＯ：ＢＣＡなど他のサーバで管理するタイプ
図１１にＡＰサーバ１４０の本人認証方法に関する安全レベルを設定するテーブルを示す。本テーブルは、アルゴリズムＩＤと照合タイプと照合アルゴリズムの安全レベルからなる。このテーブルにより、ＡＰサーバ１４０が提供するアプリケーションのポリシーに応じて認証方法の安全レベルを選択できる。ここで、安全レベルとして、次の例がある。
・照合ソフトの識別性能（他人受入率など）によるレベル付け
・照合ソフトが実装されたクライアント１１０の安全性評価レベル（ＩＳＯ１５４０８のＥＡＬなど）
・照合ソフトの認証モデルによるレベル付け
これらを勘案して、各ＡＰサーバ１４０のポリシーによって、それぞれの照合ソフトの安全レベルを設定する。
【００４６】
図１２にＡＰサーバ１４０のポリシーを設定するテーブルを示す。このテーブルは次のような構成となっている。
・サービスＩＤ：  ＡＰサーバ１４０の提供するサービスを識別するコード
・要求する認証モデル：このサービスが要求する認証モデル
・要求する安全レベル：このサービスが要求する安全性レベル（例えば、ＩＳＯ１５４０８のＥＡＬなど）
・要求するＦＡＲ：このサービスが要求するＦＡＲ値
・有効性検証フラグ：このサービスにおける有効性検証の処理内容
また、上記に、
・入力された画像などの生体情報の質に関するレベル：画質レベルを考慮したポリシー
を追加しても良い。
【００４７】
このようなＡＰサーバのセキュリティポリシーを満たすため、それぞれの生体認証アルゴリズムは次のような機能を持つ。
（ａ）入力された画像の画質のノイズレベルをＳ／Ｎ比として出力する機能。通常の利用した場合のノイズレベルと比較して、著しく変動がある入力画像を排除する効果がある。
（ｂ）連続して収集した画像の変動量を出力する機能。通常の場合の変動量と比較して、変動がない場合、写真などの偽造として入力画像を排除する効果がある。
（ｃ）入力された特徴の過不足を出力する機能。顔照合の場合、顔の構造が過不足なく入力されているか評価することで、照合確度を上げることが期待できる。
（５）認証プロトコル
本実施例の認証フローを図１３に示す。
【００４８】
まず、クライアント１１０からサービス要求８１１が、ＡＰサーバ１４０へ送付される。
【００４９】
本実施例のプロトコルを実装したＡＰサーバ１４０が、要求されたサービスが本人認証を必要とするサービスかどうか判定する（８２１）。本人認証が必要なサービスであれば、ＡＰサーバ１４０が持つ認証方法のリストを含む本人認証要求８３１をクライアント１１０へ送付する。
【００５０】
クライアント１１０では、上記認証方法のリストから、クライアント１１０が管理する認証情報取得機能で対応できる認証方法を選択する。さらに、クライアント１１０が管理する照合機能を選択されたリストに追加する（８０１）。もし、作成したリストのうち、最も優先的に照合に使いたいテンプレートを使った認証方法があれば、リストの最上位に並び替える。このようにして作成した本人認証スペック８１２をＡＰサーバ１４０へ返送する。
【００５１】
ＡＰサーバ１４０は、要求されたサービスに最も適した認証方法をポリシー管理テーブルにより決定する。安全性レベルおよびＦＡＲを満たす認証方法が多数ある場合で、ユーザ希望の認証方法（リスト最上位の認証方法）があれば、ユーザ希望の認証方法を選択する（８２２）。クライアント１１０で付け足された認証方法の安全性レベルが不明の場合は方法、当該認証方法を開発したベンダやその性能を認証するＢＣＡなどのＦＡＲの情報をオンラインで入手し、安全性レベルを満たすかどうかを判定する。
【００５２】
以上で決定された本人認証方法とアプリケーションで生成したチャレンジコードをクライアント１１０へ通知する。上記のポリシーに適合する認証方法がない場合は、セッションの終了を通知する（８３２）。
【００５３】
クライアント１１０では、決定された認証方法に従って、認証情報を収集する（８０２）。
【００５４】
クライアント１１０でテンプレートを管理・照合する認証方法の場合は、８０２で収集した
認証情報を照合する（８０３）。
【００５５】
クライアント１１０で、チャレンジコードと８０２で収集した認証情報に対して、テンプレートのユーザの秘密鍵で署名を生成する（８０４）。
【００５６】
収集した認証情報とユーザ署名８１３を、クライアント１１０からアプリケーションへ返送する。
【００５７】
ＡＰサーバ１４０は、証明書の正当性、ユーザ署名８１３、テンプレートの正当性などを署名検証処理により検証する（８２３）。
【００５８】
さらに、ＡＰサーバ１４０では、証明書、テンプレートの有効性を認証局、ＢＣＡの情報により検証する（８２４）
ＡＰサーバ１４０でテンプレートを管理・照合する場合は、テンプレートと送付された認証情報を照合する（８２５）。
【００５９】
照合の結果情報と８２３、８２４の検証結果より、ＦＡＲを満たす照合スコアであったか、有効な情報で検証が行われたかを確認し、サービスを提供して良いか判定する（８２６）。
【００６０】
ＡＰサーバ１４０からクライアント１１０へ認証結果を通知する。８２６で、サービスを提供してよいと判定すれば、サービスを提供する（８３３）。
【００６１】
図１４に、ＡＰサーバ１４０・クライアント１１０以外にテンプレートが管理されている場合を示す。図１３とは、ステップ８０５が追加されていることと、ステップ８２４の代りにステップ８２７が実行されるという点である。図１３と同じ番号を付している他のステップは、重複しているため説明を省略する。
【００６２】
ステップ８０２の後、クライアント１１０で照合する認証方法の場合で、クライアント１１０でテンプレートを管理していない場合は、テンプレートを管理するＢＣＡなどへテンプレートを要求し、送付してもらう（８０５）。その後で、ステップ８０２で収集した認証情報を照合する（８０３）。
【００６３】
ステップ８２３の後、クライアント１１０よりテンプレートが送付された場合、ＢＣＡが管理するテンプレートの有効性情報に基づき、有効性を検証する（８２４）
ＡＰサーバ１４０では、ステップ８２３の後、ＡＰサーバ１４０で照合する場合で、テンプレートがＢＣＡなど他のサーバで管理している場合には、テンプレートをＢＣＡへ要求して、送信してもらう（８２７）。その後に、クライアント１１０から送付された認証情報の照合（８２５）に移る。
【００６４】
ＡＰサーバ１４０からの本人認証を要求する通信データ８３１を図１５に示す。この本人認証要求する通信データ８３１は、次のようなデータで構成されている。
【００６５】
データ識別コード：この本人認証を要求する通信データを識別するコード
サービス要求情報：ユーザが要求したサービスのセッション情報
要求する本人認証モデル：ＡＰサーバ１４０が要求する本人認証モデルを指定する情報。例えば、０：ＰＫＩ認証だけを実行、１：クライアント１１０で生体照合を実行、２：ＡＰサーバ１４０で生体照合を実行、３：クライアント、ＡＰサーバ１４０のどちらかで生体照合を実行と指定
認証方法のリスト数：ＡＰサーバ１４０の持つ認証方法の数
認証方法のリスト：上記の認証方法のリスト。例えば、認証方法を一意に指定するＩＤとその照合モデルのフラグなどを列記
クライアント１１０からのクライアント１１０の持つ機能を反映した本人認証要求の返答データ８１２を図１６に示す。この本人認証要求の返答データ８１２は、次のようなデータで構成されている。
【００６６】
データ識別コード：この本人認証要求の返信データを識別するコード
サービス要求情報：ユーザが要求したサービスのセッション情報
認証方法のリスト数：ＡＰサーバ１４０の認証方法の中からクライアント１１０で生体を取得可能な認証方法に、クライアント照合する認証モデルをＡＰサーバ１４０が許す場合のクライアント１１０で生体取得し照合できる認証方法を追加した数
認証方法のリスト：上記の認証方法のリスト。例えば、認証方法を一意に指定するＩＤとその照合モデルのフラグなどを列記
ＡＰサーバ１４０からの本人認証方法の決定通知データ８３２を図１７に示す。この本人認証方法の決定通知データは、次のようなデータで構成されている。
【００６７】
データ識別コード：この本人認証方法の決定通知データを識別するコード
サービス要求情報：ユーザが要求したサービスのセッション情報
決定した認証方法：本セッションで照合する認証方法。
【００６８】
チャレンジコード：ＰＫＩによる本人認証のためのＡＰサーバ１４０が発生した乱数。
【００６９】
クライアント１１０からのユーザ署名と認証情報の通信データ８１３を図１８に示す。この通信データは、次のようなデータで構成されている。
【００７０】
データ識別コード：このクライアントか１１０らの通信データを識別するコード
サービス要求情報：ユーザが要求したサービスのセッション情報
決定した認証方法：本セッションで照合する認証方法。
【００７１】
認証情報：認証情報は次の３つの場合がある。
【００７２】
１）テンプレートをＡＰサーバ１４０で管理して、ＡＰサーバ１４０で照合するモデルの場合、クライアント１１０で収集した生体情報
２）クライアント１１０で照合するモデルの場合、クライアント１１０で照合した照合結果とテンプレート
３）テンプレートをクライアント１１０で管理して、ＡＰサーバ１４０で照合するモデルの場合、クライアント１１０で収集した生体情報と、テンプレート
ユーザ署名：ユーザの秘密鍵でチャレンジコードを暗号化して生成した署名。
以上の通信データを構成するデータとチャレンジコードに対する署名を添付しても良い。
【００７３】
ＡＰサーバ１４０からの本人認証結果の通知データ８３３を図１９に示す。この結果通知データは、次のようなデータで構成される。
【００７４】
データ識別コード：この本人認証結果の通知データを識別するコード
サービス要求情報：ユーザが要求したサービスのセッション情報
行った認証方法：本セッションで行った認証方法
結果：本セッションで行った認証結果。例えば、０：本人認証成功、１：ＰＫＩによる認証失敗、２：生体テンプレート失敗、３：生体照合失敗
ＡＰサーバ１４０の署名：以上の結果に対する、ＡＰサーバ１４０の秘密鍵による署名
（６）認証サーバを介した場合の認証プロトコル
多数のユーザが生体認証方法を使用する場合、単一の生体認証では、対応できずにユーザの可用性を損なうおそれがある。このため、複数の認証方法をＡＰサーバ１４０で用意することが望ましい。しかし、ＡＰサーバ１４０が様々な認証方法を持つと、構築コストがかかるため、様々な認証方法を用意する認証サーバに照合処理を委託してもよい。また、全ての照合処理を認証サーバへ委託すると処理時間がかかるので、部分的に認証サーバへ委託してもよい。以下、認証サーバへ生体照合を委託するプロトコルを示す。
【００７５】
ＡＰサーバ１４０は、あらかじめ認証サーバとの間に信用関係を構築しておく必要がある。本実施例では、認証サーバの照合結果をＡＰサーバ１４０が信用することを前提としている。
【００７６】
ＡＰサーバ１４０は、予め、認証サーバの持つ認証方法に関する情報を入手しておき、認証サーバの持つ認証方法について、セキュリティポリシーを決定しておく。
【００７７】
また、クライアント１１０からＡＰサーバ１４０が信用関係を構築していない認証サーバを介した認証方法を提案されることも想定される。この場合は、提案された認証サーバが信用できるか、ＰＫＩの枠組みで検証を行ったうえ、認証サーバへ照合を委託することも考えられる。この場合、認証サーバとクライアント１１０が結託して、なりすましを試みることも想定されるので、信頼のおける組織から、（ＰＫＩの）認証を受けた認証サーバであることが、信用の条件である。ＡＰサーバ１４０では、これらの信用に関するポリシーの設定をしておく必要がある。また、未知の認証サーバの持つ認証方法がアプリケーションの安全性ポリシーに合致するかを検証する必要がある。このため、他人を受け入れる確率ＦＡＲの要件を満たしているか、信頼できる評価結果により、判断する。この仕組みは、本出願人による特願２００２−５０８８４号に開示する認証方法により可能である。
【００７８】
図２０に認証サーバに生体の照合を委託する場合の処理フローを示す。以下、図１３に示す処理フローとの相違点である、
照合ステップ８２５を認証サーバに委託する点について説明する。また、本人認証要求８３１は、ＡＰサーバ１４０が持つ認証方法、および、認証サーバの持つ認証方法のリストを含む。
【００７９】
ステップ８２４の後、認証サーバで照合するため、テンプレートと送付された
認証情報を認証サーバへ送付する（９５２）。
【００８０】
認証サーバでは、受信したテンプレートと認証情報を照合（９４１）し、結果をＡＰサーバ１４０へ返送し（９６２）、ステップ８２６に進む。
【００８１】
（７）各種情報の設定画面の例
各種情報の設定画面の例を示す。
【００８２】
図２３にクライアント１１０における各ユーザの設定画面の例を示す。
【００８３】
個人情報として、個人を特定する氏名や住所の他、ＰＫＩの公開鍵の証明書情報が表示される。複数の機関から、証明書の発行を受けるため、証明書ごとにこの設定画面を切り替えて表示できるようになっている。
【００８４】
テンプレート情報として、切り替え表示された個人ＩＤに対して発行されたテンプレートを全て表示できるようにしている。また、ユーザが希望するテンプレートの優先度の順に表示されており、テンプレートを指定した上で優先順位上昇、下降ボタンを押下することで、変更可能になっている。
【００８５】
セキュリティ情報として、チェックボックスにより、秘匿通信および利用範囲限定宣言を指定できるようになっている。
【００８６】
図２４にＡＰサーバ１４０におけるアプリケーションのセキュリティポリシーの設定画面の例を示す。
【００８７】
ＡＰサーバ１４０が持つアプリケーションごとに、クライアント１１０に要求する安全性レベル（ＥＡＬ保証レベルなど）や認証に要求するＦＡＲ、認証モデル、テンプレートの有効性検証の必要性を設定できるようになっている。
【００８８】
図２５にＡＰサーバ１４０における認証方法のセキュリティポリシーの設定画面の例を示す。ＡＰサーバ１４０が許可する認証方法について、それぞれのＦＡＲや照合タイプ、安全性レベルをサーバ事業者のポリシーに応じて設定できるようになっている。
【００８９】
上記各実施例の本人認証システムによれば、次のような顕著な効果を奏する。
【００９０】
まず、ＡＰサーバ１４０と、サービスの提供を受けるクライアント１１０において、それぞれが持つ本人認証方法を管理し、サービス提供のセッションに先立ち、ＡＰサーバ１４０のポリシーとユーザの希望に沿った本人認証方法を選択できる。
【００９１】
また、ＡＰサーバ１４０のポリシーが、クライアント１１０で生体照合を行う本人認証方法を認める場合は、選択肢に追加できる。
【００９２】
また、プライバシーを保護するため、クライアント１１０からＡＰサーバ１４０へ送付する情報に、生体情報の利用範囲を上記サービス利用のための認証処理に限定する要求情報を添付できる。
【００９３】
また、クライアントで生体照合を行う方法を選択した場合、照合の結果と照合の基準となったテンプレートをサーバに通知できる。
【００９４】
また、サーバが信用する本人認証サーバ機能を持つ他のサーバに生体認証を依頼する場合、サーバの生体認証方法として、そのサーバの情報を追加できる。
【００９５】
【発明の効果】
以上により、不特定多数の参加するネットワークにおける情報サービスの授受において、クライアントとサーバのそれぞれの機器構成に依らずに、サーバポリシーに応じた本人認証を実現できる。
【図面の簡単な説明】
【図１】実施例におけるシステム全体の構成図である。
【図２】実施例におけるクライアント１１０の構成図である。
【図３】実施例における、クライアント側で生体照合を行う第１の生体認証モデルの説明図である。
【図４】実施例における、サーバ側で生体照合を行う第２の生体認証モデルの説明図である。
【図５】実施例におけるユーザのクライアント１１０の機能構成を示すブロック図である。
【図６】実施例におけるユーザクライアント１１０にて所有する本人認証アルゴリズムを管理するテーブルである。
【図７】実施例におけるユーザクライアント１１０の設定項目のテーブルである。
【図８】実施例におけるユーザクライアント１１０で所有するユーザテンプレートの管理テーブルである。
【図９】実施例におけるＡＰサーバ１４０の機能構成を示すブロック図である。
【図１０】ＡＰサーバ１４０にて所有する本人認証アルゴリズムを管理するテーブルである。
【図１１】ＡＰサーバ１４０の各本人認証方法に関して安全レベルに関してポリシーを設定するテーブルである。
【図１２】ＡＰサーバ１４０のサービスごとに安全性レベルを設定する項目のテーブルである。
【図１３】クライアントとＡＰサーバ１４０との間で行われる本人認証の第１の全体処理フローである。
【図１４】クライアントとＡＰサーバ１４０の間で行われる本人認証において、テンプレートが照合を実行する装置以外に格納されている場合の第２の全体処理フローである。
【図１５】ＡＰサーバ１４０からクライアントへ本人認証を要求するメッセージの項目を示すテーブルである。
【図１６】図１５のメッセージに対してクライアントのレスポンスメッセージの項目を示すテーブルである。
【図１７】実施例における図１６のメッセージに対するクライアントへの返答とチャレンジコードを含むメッセージの項目を示すテーブルである。
【図１８】実施例における図１７のメッセージに対するサーバへのレスポンスメッセージの項目を示すテーブルである。
【図１９】実施例における図１８のメッセージに対するクライアントの本人認証結果を含む通知メッセージの項目を示すテーブルである。
【図２０】実施例におけるクライアントとＡＰサーバ１４０との間の本人認証において、認証サーバがアプリケーションの生体認証処理を代行する場合の第３全体処理フローである。
【図２１】実施例における認証サーバが生体認証処理を代行する場合のＡＰサーバ１４０から認証サーバへの認証情報を送付するメッセージの項目を示すテーブルである。
【図２２】実施例における認証サーバが生体認証処理を代行する場合の認証サーバから照合結果をＡＰサーバ１４０への通知メッセージの項目を示すテーブルである。
【図２３】クライアント１１０のユーザによる設定画面例である。
【図２４】サーバにおけるアプリケーションごとのセキュリティポリシーの設定画面例である。
【図２５】サーバにおける各認証方法のセキュリティポリシーの設定画面例である。
【符号の説明】
１１０・・・ユーザクライアント１１０、１２０・・・インターネット（公衆網）、１４０・・・ＡＰサーバ、１５０・・・ＣＡ、１６０・・・バイオメトリック認証局ＢＣＡ、１７０・・・認証サーバ。
【図１】
2004348308.tif 000003
【図２】
2004348308.tif 000004
【図３】
2004348308.tif 000005
【図４】
2004348308.tif 000006
【図５】
2004348308.tif 000007
【図６】
2004348308.tif 000008
【図７】
2004348308.tif 000009
【図８】
2004348308.tif 000010
【図９】
2004348308.tif 000011
【図１０】
2004348308.tif 000012
【図１１】
2004348308.tif 000013
【図１２】
2004348308.tif 000014
【図１３】
2004348308.tif 000015
【図１４】
2004348308.tif 000016
【図１５】
2004348308.tif 000017
【図１６】
2004348308.tif 000018
【図１７】
2004348308.tif 000019
【図１８】
2004348308.tif 000020
【図１９】
2004348308.tif 000021
【図２０】
2004348308.tif 000022
【図２１】
2004348308.tif 000023
【図２２】
2004348308.tif 000024
【図２３】
2004348308.tif 000025
【図２４】
2004348308.tif 000026
【図２５】
2004348308.tif 000027