JP2021150681A - 情報処理システム、情報処理プログラムおよび情報処理方法 - Google Patents

Abstract

【課題】生体認証を実行する端末装置が変更されても認証強度が維持されるようにする。【解決手段】バックアップサーバ３００は、他の端末装置から、ユーザの秘密鍵Ｋｓと、他の端末装置における生体認証の認証強度を識別可能にする認証器情報Ｄａ１とを受信して記憶する。端末装置は、秘密鍵Ｋｓと認証器情報Ｄａ１とをバックアップサーバ３００から受信し、端末装置における生体認証の認証強度を識別可能にする認証器情報Ｄａ２と、受信した認証器情報Ｄａ１との比較結果に基づき、端末装置での認証強度が他の端末装置での認証強度以上である場合に、受信した秘密鍵Ｋｓを保存して使用可能な状態にし、サービスを利用する際に、ユーザの生体認証を実行し、認証に成功すると、認証サーバ１００がユーザを認証するための認証用データを、保存された秘密鍵Ｋｓで暗号化した状態で認証サーバ１００に送信する。【選択図】図７

Description

本発明は、情報処理システム、情報処理プログラムおよび情報処理方法に関する。

オンライン上のユーザ認証法として、ＦＩＤＯ（Fast IDentity Online）認証が注目されている。ＦＩＤＯ認証では、ユーザ側の端末装置が、ユーザの本人性を検証する「認証器」として動作する。本人性の検証は、生体認証など、ユーザによるパスワード入力を伴わない方法で行われる。そして、端末装置でユーザの本人性が検証されるとともに、端末装置と認証サーバとの間で公開鍵暗号化方式を用いたチャレンジ・レスポンス認証が行われることで、ユーザ認証が行われる。このような認証手順では、パスワード入力の排除によりユーザの利便性が向上するとともに、生体情報などのユーザの秘密情報が端末装置から認証サーバへ送信されないことにより、秘密情報の漏洩リスクが低下し、ユーザ認証の安全性も向上する。

ＦＩＤＯ認証に関しては、次のような提案がある。例えば、ＦＩＤＯ認証を用いたサービスを利用するための端末を変更する際、変更前後のいずれかの端末で、サービスへの通常の登録作業とは異なる移行作業を開始させ、ユーザに両端末での認証作業を繰り返し行わせることで、変更後の端末における登録作業を完了させるようにしたシステムが提案されている。また、新規端末の公開鍵に登録済み端末の秘密鍵で署名を行い、署名済みの公開鍵をキーストアで認証して新規端末の公開鍵を登録することで、新規端末をキーストアに登録する際に本人確認情報を提示しなくても容易に認証して登録できるようにした認証鍵共有システムが提案されている。

特開２０１８−１９７９９７号公報 特開２０１９−２９９１７号公報

ところで、ＦＩＤＯ認証においては、ユーザの秘密鍵が端末装置側に保存される。認証器として利用する端末装置を変更する場合には、変更前の端末装置に保存された秘密鍵が、セキュアな方法で変更後の端末装置に受け渡される。これにより、変更後の端末装置を用いて認証サーバのサービスを利用できるようになる。

ここで、認証サーバでのユーザの認証強度を一定以上に維持するためには、変更後の端末装置での生体認証の認証強度が、変更前の認証強度以上に維持される必要がある。しかし、上記のように秘密鍵が変更後の端末装置に受け渡されるだけでは、端末装置の変更後に生体認証の認証強度が維持されることを保証できないという問題がある。

１つの側面では、生体認証を実行する端末装置が変更されても認証強度を維持することが可能な情報処理システム、情報処理プログラムおよび情報処理方法を提供することを目的とする。

１つの案では、バックアップサーバと端末装置とを有する次のような情報処理システムが提供される。この情報処理システムにおいて、バックアップサーバは、認証サーバが提供するサービスを利用するためにユーザの生体認証を実行する他の端末装置から、サービスを利用するためのユーザの秘密鍵と、他の端末装置における生体認証の認証強度を識別可能にする第１の認証器情報とを受信して記憶する。端末装置は、秘密鍵と第１の認証器情報とをバックアップサーバから受信し、端末装置における生体認証の認証強度を識別可能にする第２の認証器情報と、受信した第１の認証器情報との比較結果に基づき、端末装置での認証強度が他の端末装置での認証強度以上である場合に、受信した秘密鍵を保存して使用可能な状態にし、サービスを利用する際に、ユーザの生体認証を実行し、認証に成功すると、認証サーバがユーザを認証するための認証用データを、保存された秘密鍵で暗号化した状態で認証サーバに送信する。

また、１つの案では、コンピュータに、認証サーバが提供するサービスを利用するためにユーザの生体認証を実行する他の端末装置から出力された、サービスを利用するためのユーザの秘密鍵と、他の端末装置における生体認証の認証強度を識別可能にする第１の認証器情報とを取得し、コンピュータにおける生体認証の認証強度を識別可能にする第２の認証器情報と、取得した第１の認証器情報との比較結果に基づき、コンピュータでの認証強度が他の端末装置での認証強度以上である場合に、受信した秘密鍵を保存して使用可能な状態にし、サービスを利用する際に、ユーザの生体認証を実行し、認証に成功すると、認証サーバがユーザを認証するための認証用データを、保存された秘密鍵で暗号化した状態で認証サーバに送信する、処理を実行させる情報処理プログラムが提供される。

さらに、１つの案では、コンピュータに、ユーザを認証するための認証用データを端末装置に送信して、ユーザの生体認証の実行を要求し、生体認証に成功した場合に端末装置から送信される、ユーザの秘密鍵によって暗号化された認証用データと、端末装置における生体認証の認証強度を識別可能にする認証器情報とを受信し、暗号化された認証用データをユーザの公開鍵で復号することでユーザの認証処理を実行するとともに、認証器情報に基づいて、生体認証の認証強度が所定の条件を満たすかを判定し、公開鍵を用いた復号によるユーザの認証処理に成功し、かつ、当該認証強度が所定の条件を満たす場合には、ユーザによる所定のサービスの利用を許可し、当該認証強度が所定の条件を満たさない場合には、ユーザによるサービスの利用を不許可にする、処理を実行させる情報処理プログラムが提供される。

また、１つの案では、上記の各情報処理プログラムを用いた処理と同様の処理をコンピュータが実行する情報処理方法が提供される。

１つの側面では、生体認証を実行する端末装置が変更されても認証強度を維持できる。

第１の実施の形態に係る情報処理システムの構成例および処理例を示す図である。 第２の実施の形態に係る認証システムの構成例を示す図である。 認証サーバのハードウェア構成例を示す図である。 ＦＩＤＯ認証について説明するための図である。 ユーザ端末変更時における処理手順の比較例を示す図である。 第２の実施の形態に係る認証システムの処理例を示す第１の図である。 第２の実施の形態に係る認証システムの処理例を示す第２の図である。 認証システム内の各装置が備える処理機能の構成例を示す図である。 ユーザデータベースのデータ構成例を示す図である。 鍵データベースのデータ構成例を示す図である。 ユーザ端末での鍵のバックアップ処理手順を示すフローチャートの例である。 鍵のバックアップ実行時における画面遷移例を示す図である。 ユーザ端末での鍵の復元処理手順を示すフローチャートの例（その１）である。 ユーザ端末での鍵の復元処理手順を示すフローチャートの例（その２）である。 生体認証器の構成情報の例を示す図である。 鍵の復元処理の実行時における画面遷移例を示す図である。 ユーザ端末でのログイン処理手順を示すフローチャートの例である。 認証サーバでのログイン受け付け処理手順を示すフローチャートの例（その１）である。 認証サーバでのログイン受け付け処理手順を示すフローチャートの例（その２）である。

以下、本発明の実施の形態について図面を参照して説明する。
〔第１の実施の形態〕
図１は、第１の実施の形態に係る情報処理システムの構成例および処理例を示す図である。図１に示す情報処理システムは、認証サーバ１、端末装置２，３およびバックアップサーバ４を含む。

認証サーバ１は、ユーザを認証し、認証に成功したユーザに対して所定のサービスを提供するサーバコンピュータである。端末装置２，３は、認証サーバ１が提供するサービスをユーザが利用するためのコンピュータである。本実施の形態では、当初、ユーザは端末装置２を使用してサービスを利用し、その後に、ユーザの使用端末が端末装置３に変更されるものとする。バックアップサーバ４は、サービスの利用のために端末装置に保存される鍵情報（後述する秘密鍵１１）をバックアップするためのサーバコンピュータである。

認証サーバ１が提供するサービスをユーザが端末装置を使用して利用するためには、ユーザに対応する秘密鍵１１および公開鍵１２の認証鍵ペアが使用される。ユーザが端末装置２を使用している状況では、秘密鍵１１が端末装置２に保存され、公開鍵１２が認証サーバ１に保存される。なお、公開鍵１２は、ネットワーク上の他の装置に保存され、認証サーバ１がその装置から公開鍵１２を取得するようにしてもよい。

端末装置２を使用してサービスを利用する場合、端末装置２は、ユーザの生体認証を実行し（ステップＳ１ａ）、認証に成功すると、認証サーバ１がユーザを認証するための認証用データを、秘密鍵１１で暗号化した状態で認証サーバ１に送信する（ステップＳ１ｂ）。認証サーバ１は、暗号化された認証用データを受信すると、受信したデータを公開鍵１２で復号することで検証し、ユーザを受け入れるか否かを判定する。

実際には、例えば、端末装置２がサービスの利用を認証サーバ１に要求すると、認証サーバ１が端末装置２に認証用データ（例えば、乱数によるチャレンジコード）を送信してユーザの生体認証を要求する。ステップＳ１ａの生体認証はこの要求に応じて実行され、ステップＳ１ｂでは、認証サーバ１から送信された認証用データが暗号化されて送信される。

また、端末装置２は、秘密鍵１１をバックアップサーバ４に送信して、バックアップさせる。このとき、端末装置２は、端末装置２に対応する認証器情報２１を、秘密鍵１１とともに送信する。バックアップサーバ４は、秘密鍵１１と認証器情報２１とを受信して記憶する（ステップＳ２）。

認証器情報２１とは、端末装置２における生体認証の認証強度を識別可能にする情報である。例えば、認証器情報２１は、端末装置２が備える生体センサや生体認証アプリケーションの識別情報を示す。この場合、例えば、識別情報ごとの認証強度がサーバ装置などの所定の記憶場所に記憶されており、認証器情報２１が示す識別情報をキーとして認証強度が記憶場所から取得される。また、認証器情報２１は、他人受入率（ＦＡＲ：False Acceptance Rate）の逆数や、本人拒否率（ＦＲＲ：False Rejection Rate）の逆数など、認証強度を直接的に示す数値であってもよい。

なお、秘密鍵１１と認証器情報２１のうち、少なくとも秘密鍵１１は、暗号化された状態でバックアップサーバ４に送信され、記憶されることが望ましい。
次に、ユーザの使用端末が端末装置３に変更されると、バックアップサーバ４にバックアップされたデータが端末装置３に受け渡される。すなわち、端末装置３は、秘密鍵１１と認証器情報２１をバックアップサーバ４から受信する（ステップＳ３ａ）。端末装置３は、端末装置３における生体認証の認証強度を識別可能にする認証器情報２２と、受信した認証器情報２１とを比較する。そして、端末装置３は、認証器情報２１，２２の比較結果に基づき、変更後の端末装置３での認証強度が変更前の端末装置２での認証強度以上である場合に、受信した秘密鍵１１を記憶部３ａに保存する（ステップＳ３ｂ）。これにより、秘密鍵１１は使用可能な状態になる。一方、変更後の端末装置３での認証強度が変更前の端末装置２での認証強度より低い場合には、秘密鍵１１は保存されずに破棄される。

なお、記憶部３ａは、例えば、端末装置３が備える図示しない記憶装置の記憶領域として実現される。
ここで、認証器情報２１，２２の比較処理では、例えば、認証器情報２１と認証器情報２２とが同一の場合、端末変更前後で生体認証の認証強度は変化しないので、秘密鍵１１は記憶部３ａに保存される。また、例えば、認証器情報２１，２２が認証強度を直接的に示す数値である場合、認証器情報２２の値が認証器情報２１の値以上であれば、秘密鍵１１が記憶部３ａに保存される。また、例えば、認証器情報２１，２２が生体センサや生体認証アプリケーションの識別情報であり、これらが同一でない場合には、上記の記憶場所から認証器情報２１，２２のそれぞれに対応する認証強度の数値が取得されて比較されればよい。

その後、サービスを利用する際、端末装置３は、ユーザの生体認証を実行し（ステップＳ４ａ）、認証に成功すると、認証サーバ１がユーザを認証するための認証用データを、秘密鍵１１で暗号化した状態で認証サーバ１に送信する（ステップＳ４ｂ）。これらのステップＳ４ａ，Ｓ４ｂは、ステップＳ１ａ，Ｓ１ｂと同様の手順で実行されればよい。ただし、使用される認証用データは互いに異なっていてもよい。認証サーバ１は、暗号化された認証用データを受信すると、受信したデータを公開鍵１２で復号することで検証し、ユーザを受け入れるか否かを判定する。

以上の処理によれば、ユーザの使用端末が端末装置３に変更され、秘密鍵１１が端末装置３に受け渡される際に、変更前の端末装置２の認証器情報２１と変更後の端末装置３の認証器情報２２とは比較される。そして、その比較結果に基づき、変更後の端末装置３での認証強度が変更前の端末装置２での認証強度以上である場合に、秘密鍵１１が記憶部３ａに保存されて使用可能な状態になる。これにより、ユーザが変更後の端末装置３を使用してサービスを利用する際に、変更前の端末装置２を使用した場合と比較して、生体認証の認証強度が低下しないことが保証される。その結果、ユーザの使用端末が変更されても、認証サーバ１でのユーザの認証強度を維持することができる。

なお、上記の第１の実施の形態では、秘密鍵１１と認証器情報２１は、バックアップサーバ４を介して端末装置２から端末装置３に受け渡されていた。しかし、他の例として、バックアップサーバ４が使用されずに、可搬型記録媒体を介して、あるいはネットワークを介して直接的に、端末装置２から端末装置３に対して秘密鍵１１と認証器情報２１が受け渡されてもよい。

〔第２の実施の形態〕
図２は、第２の実施の形態に係る認証システムの構成例を示す図である。図２に示す認証システムは、認証サーバ１００、ユーザ端末２００、バックアップサーバ３００およびメタデータサーバ４００を含む。認証サーバ１００、ユーザ端末２００、バックアップサーバ３００およびメタデータサーバ４００は、ネットワーク５０を介して相互に接続されている。

認証サーバ１００は、ユーザを認証し、認証に成功したユーザに対して所定のサービスを提供するサーバコンピュータである。本実施の形態では、認証サーバ１００は、ユーザからのログイン要求に応じてユーザを認証し、ユーザの認証に成功した場合に、ユーザのログインを受け入れ、ログイン状態のユーザに対してＷｅｂサービスを提供する。

ユーザ端末２００は、ユーザによって利用される端末装置である。ユーザは、ユーザ端末２００を操作することで認証サーバ１００にログインする。ユーザ端末２００としては、例えば、パーソナルコンピュータ、タブレット端末、スマートフォンなどが適用される。

認証サーバ１００はＦＩＤＯサーバとして動作し、ユーザ端末２００はＦＩＤＯクライアントとして動作する。そして、ユーザの認証はＦＩＤＯ方式で行われる。特に、本実施の形態では、ユーザの生体情報を用いたＦＩＤＯ認証が行われる。すなわち、ユーザ端末２００は、生体認証によってユーザを認証する。生体認証を行うために、ユーザ端末２００は、ユーザの生体情報を検出するための生体センサ２０１を備えている。一方、認証サーバ１００は、ユーザ端末２００との間で、秘密鍵および公開鍵の認証鍵ペアとチャレンジ・レスポンスを用いたユーザ認証を行う。

なお、生体認証としては、例えば、指紋認証、静脈認証、虹彩認証、顔認証などの方式を適用可能である。この場合、生体センサ２０１は、例えば、撮像装置、または、赤外線などの発光装置と撮像装置とが組み合わされた装置として実現される。また、生体センサ２０１は、ユーザ端末２００に内蔵されていてもよいし、ＵＳＢ（Universal Serial Bus）ケーブルなどによってユーザ端末２００に外付けされていてもよい。

バックアップサーバ３００は、認証のためのユーザの情報がバックアップされるサーバコンピュータである。バックアップサーバ３００には、少なくとも、ユーザの秘密鍵がバックアップされる。

メタデータサーバ４００は、端末の認証器に関する情報を保持するサーバコンピュータである。メタデータサーバ４００は、少なくとも、生体認証を用いた認証器の識別情報および仕様情報を保持している。メタデータサーバ４００は、例えば、ＦＩＤＯアライアンスのサーバであり、この場合には、ＦＩＤＯアライアンスで認定された認証器の識別情報や仕様情報がメタデータサーバ４００に保持される。

ここで、以下の説明では、ユーザが認証サーバ１００にログインするために利用する端末装置を、ユーザ端末２００からユーザ端末２００ａに変更するものとする。ユーザ端末２００ａも、ユーザ端末２００と同様に、例えば、パーソナルコンピュータ、タブレット端末、スマートフォンなどとして実現される。ユーザ端末２００ａは、ユーザ端末２００と同じ機種である必要はない。また、ユーザ端末２００ａは、ユーザの生体情報を検出するための生体センサ２０１ａを備えている。生体センサ２０１ａも、生体センサ２０１と同じ機種である必要はない。

なお、図２に示した認証サーバ１００、ユーザ端末２００，２００ａ、バックアップサーバ３００は、それぞれ図１に示した認証サーバ１、端末装置２，３、バックアップサーバ４の一例である。

図３は、認証サーバのハードウェア構成例を示す図である。認証サーバ１００は、例えば、図３に示すようなコンピュータとして実現される。図３に示す認証サーバ１００は、プロセッサ１０１、ＲＡＭ（Random Access Memory）１０２、ＨＤＤ（Hard Disk Drive）１０３、グラフィックインタフェース（Ｉ／Ｆ）１０４、入力インタフェース（Ｉ／Ｆ）１０５、読み取り装置１０６およびネットワークインタフェース（Ｉ／Ｆ）１０７を備える。

プロセッサ１０１は、認証サーバ１００全体を統括的に制御する。プロセッサ１０１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）またはＰＬＤ（Programmable Logic Device）である。また、プロセッサ１０１は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。

ＲＡＭ１０２は、認証サーバ１００の主記憶装置として使用される。ＲＡＭ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）プログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。

ＨＤＤ１０３は、認証サーバ１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、ＳＳＤ（Solid State Drive）などの他の種類の不揮発性記憶装置を使用することもできる。

グラフィックインタフェース１０４には、表示装置１０４ａが接続されている。グラフィックインタフェース１０４は、プロセッサ１０１からの命令にしたがって、画像を表示装置１０４ａに表示させる。表示装置としては、液晶ディスプレイや有機ＥＬ（ElectroLuminescence）ディスプレイなどがある。

入力インタフェース１０５には、入力装置１０５ａが接続されている。入力インタフェース１０５は、入力装置１０５ａから出力される信号をプロセッサ１０１に送信する。入力装置１０５ａとしては、キーボードやポインティングデバイスなどがある。ポインティングデバイスとしては、マウス、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

読み取り装置１０６には、可搬型記録媒体１０６ａが脱着される。読み取り装置１０６は、可搬型記録媒体１０６ａに記録されたデータを読み取ってプロセッサ１０１に送信する。可搬型記録媒体１０６ａとしては、光ディスク、光磁気ディスク、半導体メモリなどがある。

ネットワークインタフェース１０７は、ネットワーク５０を介して他の装置との間でデータの送受信を行う。
以上のようなハードウェア構成によって、認証サーバ１００の処理機能を実現することができる。なお、ユーザ端末２００，２００ａ、バックアップサーバ３００およびメタデータサーバ４００についても、例えば、図３に示すような構成のコンピュータとして実現することができる。ただし、ユーザ端末２００には生体センサ２０１が接続され、ユーザ端末２００ａには生体センサ２０１ａが接続されている。

次に、図４、図５を用いて、認証システムにおける動作の比較例について説明する。
まず、図４は、ＦＩＤＯ認証について説明するための図である。図４を用いて、生体情報を用いたＦＩＤＯ認証の基本的な手順について説明する。また、図４では例として、ユーザ端末２００と認証サーバ１００との間の処理を示す。

ユーザ端末２００では、ユーザの秘密鍵と公開鍵とが生成される。そして、認証サーバ１００に対して公開鍵が事前に登録される（ステップＳ１１）。一方、ユーザ端末２００では、秘密鍵がセキュアな状態で記憶される。

その後、ユーザ端末２００から認証サーバ１００に対してユーザのログインが要求される（ステップＳ１２）。すると、認証サーバ１００は、ユーザ端末２００に対して生体認証によるユーザの認証を依頼する。このとき、認証サーバ１００は、乱数などによって一時的な数値であるチャレンジコードを生成し、ユーザ端末２００に送信する（ステップＳ１３）。

ユーザ端末２００は、認証依頼に応じて、ユーザに対して生体認証の操作を要求し（ステップＳ１４）、生体センサ２０１によってユーザの生体情報が読み取られると、生体情報に基づいてユーザの認証を行う（ステップＳ１５）。ユーザの認証に成功すると、ユーザ端末２００は、受信したチャレンジコードに対してユーザの秘密鍵を用いて署名する（チャレンジコードを秘密鍵で暗号化する）ことでレスポンスデータを生成し、認証サーバ１００に送信する（ステップＳ１６）。

認証サーバ１００は、受信したレスポンスデータを、ユーザの公開鍵を用いて検証する（ステップＳ１７）。具体的には、認証サーバ１００は、レスポンスデータをユーザの公開鍵で復号することでチャレンジコードを復元し、復元されたチャレンジコードとステップＳ１３で送信されたチャレンジコードとが一致するかを判定する。認証サーバ１００は、これらが一致した場合、認証に成功したと判定し、ユーザのログインを受け入れる（ステップＳ１８）。

以上の認証手順によれば、ユーザＩＤとパスワードとを用いた認証方法と比較して、次のような利点がある。まず、ユーザによるパスワードの入力操作が不要になることから、ユーザの利便性が向上する。これに加えて、生体情報などのユーザの秘密情報がユーザ端末２００から認証サーバ１００に送信されないことから、秘密情報の漏洩リスクが低下し、ユーザ認証の安全性も向上する。

ところで、上記の認証手順では、ユーザの秘密鍵がユーザ端末２００に保存される。そのため、例えば、ユーザ端末２００の故障や変更に備えて、秘密鍵を安全にバックアップできることが望まれている。秘密鍵のバックアップ方法としては、例えば、パスワードを用いて秘密鍵を暗号化した状態で、外部装置に保存する方法が考えられる。そこで、次の図５では、この方法を用いて秘密鍵をバックアップサーバ３００にバックアップする場合の、認証システム全体の処理手順を例示する。

図５は、ユーザ端末変更時における処理手順の比較例を示す図である。この図５では、ユーザが利用する端末装置がユーザ端末２００からユーザ端末２００ａに変更される場合について例示する。

まず、ユーザがユーザ端末２００を用いて認証サーバ１００にログインできるようにするために、ユーザの公開鍵を認証サーバ１００に登録する処理が行われる。この処理では、認証サーバ１００からユーザ端末２００に対して認証鍵の登録が依頼される（ステップＳ２１ａ）。すると、ユーザ端末２００からユーザに対して生体認証の操作が要求され、生体センサ２０１によってユーザの生体情報が読み取られて、ユーザ端末２００によって生体認証が行われる（ステップＳ２１ｂ）。ユーザ端末２００は、ユーザの認証に成功すると、ユーザの秘密鍵Ｋｓおよび公開鍵Ｋｐを生成し、公開鍵Ｋｐを認証サーバ１００に登録する（ステップＳ２１ｃ）。

また、秘密鍵Ｋｓは、ユーザ端末２００内のセキュアな記憶領域に保存されるとともに、バックアップサーバ３００にバックアップされる。この処理では、ユーザ端末２００は、ユーザからパスワードの入力を受け付け、入力されたパスワードを用いて秘密鍵Ｋｓを暗号化し、暗号化された秘密鍵Ｋｓをバックアップサーバ３００に保存する（ステップＳ２１ｄ）。

その後、ユーザ端末２００を用いて認証サーバ１００にログインする場合には、図４に示した手順によって認証処理が行われる。すなわち、認証サーバ１００からユーザ端末２００に対して、生体認証によるユーザの認証が依頼される（ステップＳ２２ａ）。このとき、チャレンジコードが生成され、ユーザ端末２００に送信される。ユーザ端末２００は、ユーザの生体認証を実行し（ステップＳ２２ｂ）、認証に成功すると、チャレンジコードに対して秘密鍵Ｋｓを用いて署名することでレスポンスデータを生成し、認証サーバ１００に送信する。認証サーバ１００は、レスポンスデータを公開鍵Ｋｐを用いて検証し（ステップＳ２２ｃ）、正当性が確認されるとユーザのログインを受け入れる。

次に、ユーザが利用する端末装置がユーザ端末２００からユーザ端末２００ａに変更されたとする。この場合、変更後のユーザ端末２００ａは、暗号化された秘密鍵Ｋｓをバックアップサーバ３００からダウンロードし、パスワードを用いて秘密鍵Ｋｓを復元し、ユーザ端末２００ａ内のセキュアな記憶領域に保存する（ステップＳ２３ａ）。

ユーザ端末２００ａを用いてログインする場合には、変更前のユーザ端末２００を用いた場合と同様の認証処理が実行される。すなわち、認証サーバ１００からユーザ端末２００ａに対して、生体認証によるユーザの認証が依頼されるとともに、チャレンジコードが送信される（ステップＳ２３ｂ）。ユーザ端末２００ａは、ユーザの生体認証を実行し（ステップＳ２３ｃ）、認証に成功すると、チャレンジコードに対して秘密鍵Ｋｓを用いて署名することでレスポンスデータを生成し、認証サーバ１００に送信する。認証サーバ１００は、レスポンスデータを公開鍵Ｋｐを用いて検証し（ステップＳ２３ｄ）、正当性が確認されるとユーザのログインを受け入れる。

以上の処理によれば、ユーザの秘密鍵Ｋｓを安全にユーザ端末２００ａに移動させることができる。また、秘密鍵Ｋｓの移動後にはすぐに認証サーバ１００にログインでき、例えば、ユーザの鍵情報を生成し直して新たな公開鍵Ｋｐを認証サーバ１００に登録する、といった手間がかからない。

しかしながら、上記処理では次のような課題がある。
（課題１）ユーザが利用する端末装置が変更された場合には、同じ鍵情報を持つ端末装置が複数存在しないように、変更前のユーザ端末２００に保存された秘密鍵Ｋｓを無効化しなければならない。このような無効化のためにユーザの操作が必要になる場合、ユーザの手間が増え、ユーザにとっての利便性が低下する。

（課題２）ＦＩＤＯ認証では、ユーザの本人性の検証がユーザ端末側で実行される。このため、ユーザの認証強度は、ユーザ端末が備える生体センサやユーザ端末で利用される生体認証アルゴリズムの仕様に依存する。したがって、認証サーバ１００での認証強度を維持するためには、ユーザ端末の変更前後においてユーザ端末における生体認証の認証強度が低下しないことが求められる。しかし、図５の処理では、変更前後のユーザ端末において、生体センサや生体認証アルゴリズムが同じとは限らない。このため、変更後のユーザ端末２００ａにおける認証強度が、変更前の認証強度を維持していることを保証できない。

以上の課題に鑑み、第２の実施の形態に係る認証システムでは、以下の図６、図７に示すような処理が実行される。
図６は、第２の実施の形態に係る認証システムの処理例を示す第１の図である。本実施の形態に係る認証システムでは、前述の課題１に関し、次のような処理が実行される。

まず、事前処理として、認証サーバ１００には、ユーザの公開鍵Ｋｐに加えて、公開鍵Ｋｐ（および秘密鍵Ｋｓ）をユーザ端末に保存した時刻を示す鍵保存時刻Ｔｇ１も登録される。すなわち、認証サーバ１００からユーザ端末２００に対して認証鍵の登録が依頼される（ステップＳ３１ａ）。すると、ユーザ端末２００からユーザに対して生体認証の操作が要求され、生体センサ２０１によってユーザの生体情報が読み取られて、ユーザ端末２００によって生体認証が行われる（ステップＳ３１ｂ）。ユーザ端末２００は、ユーザの認証に成功すると、ユーザの秘密鍵Ｋｓおよび公開鍵Ｋｐを生成するとともに、そのときの時刻を示す鍵保存時刻Ｔｇ１を取得する。そして、ユーザ端末２００は、公開鍵Ｋｐと鍵保存時刻Ｔｇ１とを認証サーバ１００に登録する（ステップＳ３１ｃ）。

秘密鍵Ｋｓと鍵保存時刻Ｔｇ１は、ユーザ端末２００内のセキュアな記憶領域に保存される。また、秘密鍵Ｋｓは、暗号化された状態でバックアップサーバ３００に保存される（ステップＳ３１ｄ）。秘密鍵Ｋｓとともに鍵保存時刻Ｔｇ１もバックアップサーバ３００にバックアップされてもよい。なお、バックアップサーバ３００に保存するデータの暗号化は、図５と同様にパスワードを用いて行われてもよいが、例えば、ファジーコミットメント（Fuzzy Commitment）による生体情報を用いた暗号化が行われてもよい。

その後、ユーザ端末２００を用いて認証サーバ１００にログインする場合には、認証サーバ１００からユーザ端末２００に対して、生体認証によるユーザの認証が依頼されるとともに、チャレンジコードが送信される（ステップＳ３２ａ）。ユーザ端末２００は、ユーザの生体認証を実行する（ステップＳ３２ｂ）。そして、ユーザ端末２００は、認証に成功すると、チャレンジコードと鍵保存時刻Ｔｇ１とを含むデータセットに対して秘密鍵Ｋｓを用いて署名することでレスポンスデータを生成し、認証サーバ１００に送信する。認証サーバ１００は、レスポンスデータを公開鍵Ｋｐを用いて検証するとともに、鍵保存時刻Ｔｇ１を照合する（ステップＳ３２ｃ）。

具体的には、認証サーバ１００は、公開鍵Ｋｐを用いてレスポンスデータを復号し、チャレンジコードと鍵保存時刻Ｔｇ１を復元する。認証サーバ１００は、復元されたチャレンジコードと、ステップＳ３２ａで送信されたチャレンジコードとが一致することを確認する。さらに、認証サーバ１００は、復元された鍵保存時刻Ｔｇ１と、登録されていた鍵保存時刻Ｔｇ１とが一致することを確認する。これらの一致が確認されると、認証サーバ１００はユーザのログインを受け入れる。

次に、ユーザが利用する端末装置がユーザ端末２００からユーザ端末２００ａに変更されたとする。この場合、変更後のユーザ端末２００ａは、暗号化された秘密鍵Ｋｓをバックアップサーバ３００からダウンロードして秘密鍵Ｋｓを復元し、ユーザ端末２００ａ内のセキュアな記憶領域に保存する（ステップＳ３３ａ）。

ユーザ端末２００ａを用いてログインする場合には、認証サーバ１００からユーザ端末２００ａに対して、生体認証によるユーザの認証が依頼されるとともに、チャレンジコードが送信される（ステップＳ３３ｂ）。ユーザ端末２００ａは、ユーザの生体認証を実行する（ステップＳ３３ｃ）。ユーザ端末２００ａは認証に成功すると、秘密鍵Ｋｓを用いてレスポンスデータを生成する。

ここで、初回ログイン時には、ユーザ端末２００ａは、秘密鍵Ｋｓについての鍵保存時刻を、現在時刻を示す鍵保存時刻Ｔｇ２に更新し、ユーザ端末２００ａのセキュアな記憶領域に保存する。なお、２回目以降のログイン時には、保存された鍵保存時刻Ｔｇ２が利用されることになる。

ユーザ端末２００ａは、チャレンジコードと鍵保存時刻Ｔｇ２とを含むデータセットに対して秘密鍵Ｋｓを用いて署名することでレスポンスデータを生成し、認証サーバ１００に送信する。認証サーバ１００は、レスポンスデータを公開鍵Ｋｐを用いて検証するとともに、鍵保存時刻の照合を行う（ステップＳ３３ｄ）。

具体的には、認証サーバ１００は、公開鍵Ｋｐを用いてレスポンスデータを復号し、チャレンジコードと鍵保存時刻Ｔｇ２を復元する。認証サーバ１００は、復元されたチャレンジコードと、ステップＳ３３ｂで送信されたチャレンジコードとが一致することを確認する。さらに、認証サーバ１００は、復元された鍵保存時刻Ｔｇ２と、登録されていた鍵保存時刻Ｔｇ１とを比較する。ここで、初回ログイン時には、これらの時刻は一致せず、登録されていた鍵保存時刻Ｔｇ１の方が古い時刻（前の時刻）を示す。この場合、認証サーバ１００は、ログインに利用されたユーザ端末が変更されたと判断し、受信した鍵保存時刻Ｔｇ２によって、登録されていた鍵保存時刻Ｔｇ１を更新する。

この後、例えば、変更前のユーザ端末２００から認証サーバ１００に対してログインが要求されたとする。この場合、ステップＳ３２ａ〜Ｓ３２ｃと同様の処理が実行され、認証サーバ１００では、受信したレスポンスデータから鍵保存時刻Ｔｇ１が復元される。しかし、復元された鍵保存時刻Ｔｇ１は、認証サーバ１００に登録されている（更新されている）鍵保存時刻Ｔｇ２より前の時刻を示す。

この場合、認証サーバ１００は、鍵保存時刻が整合しないことから、変更前のユーザ端末２００からのログイン要求であると判断して、ログインを拒否する（ステップＳ３４）。さらに、認証サーバ１００は、鍵保存時刻Ｔｇ１が鍵保存時刻Ｔｇ２より前の時刻を示すことから、ユーザ端末２００に対して秘密鍵Ｋｓを無効化するように要求する（ステップＳ３５）。ユーザ端末２００は、この無効化要求に応じて、自装置に保存されている秘密鍵Ｋｓを消去する。

このように、変更後のユーザ端末２００ａを用いたログインが１回でも実行された後に、変更前のユーザ端末２００からログインが要求された場合には、ログインが拒否されるとともに、変更前のユーザ端末２００上の秘密鍵Ｋｓが消去される。このため、ユーザが変更後のユーザ端末２００ａを通じたサービスの利用を開始すると、変更前のユーザ端末２００上の秘密鍵が自動的に無効化される。したがって、秘密鍵を無効化するための操作をユーザが特に行うことなく、変更前のユーザ端末２００上の秘密鍵Ｋｓを自動的に無効化することができ、ユーザの利便性が向上する。

また、変更後のユーザ端末２００ａを用いたサービスの利用が開始されると、変更前のユーザ端末２００を用いてサービスを利用することができなくなる。したがって、変更後のユーザ端末２００を用いた認証サーバ１００への不正アクセスを防止できる。

図７は、第２の実施の形態に係る認証システムの処理例を示す第２の図である。本実施の形態に係る認証システムでは、前述の課題２に関し、次のような処理が実行される。なお、図７では、図６と同じ処理には同じステップ番号を付して示している。

ユーザ端末２００においては、認証器情報Ｄａ１が使用される。認証器情報Ｄａ１は、ユーザ端末２００が備える生体認証器の認証強度（ユーザ端末２００における生体認証の認証強度）を識別することを可能にする情報である。認証器情報Ｄａ１は、例えば、生体認証器の識別情報を示す。この場合の例として、認証器情報Ｄａ１は、ユーザ端末２００の生体センサ２０１の機種名や、ユーザ端末２００で利用される生体認証アルゴリズム（例えば、後述する生体認証処理部による生体認証アルゴリズム）の識別情報を含むことができる。また、認証器情報Ｄａ１は、生体認証器の仕様（生体センサ２０１の仕様、生体認証アルゴリズムの仕様など）を示す情報であってもよい。

ユーザ端末２００から認証サーバ１００に対する公開鍵Ｋｐの事前登録処理では、まず、図６のステップＳ３１ａ，Ｓ３１ｂの処理が実行される。また、ユーザ端末２００においてユーザの認証に成功すると、図６のステップＳ３１ｃと同様に、ユーザの公開鍵Ｋｐが認証サーバ１００に送信される（実際には、鍵保存時刻Ｔｇ１も送信される）。ただし、図７の処理では、公開鍵Ｋｐとともに認証器情報Ｄａ１も認証サーバ１００に送信される。認証サーバ１００は、認証器情報Ｄａ１を検証する。この検証では、受信した認証器情報Ｄａ１が示す生体認証器の認証強度が、認証サーバ１００での認証ポリシーとしてあらかじめ決められた条件を満たすかが判定される。認証サーバ１００は、生体認証器の認証強度が条件を満たす場合に、受信した公開鍵Ｋｐを保存し、登録処理を完了させる（ステップＳ３１ｃ１）。

また、バックアップサーバ３００に対するバックアップ処理では、秘密鍵Ｋｓに加えて認証器情報Ｄａ１がバックアップサーバ３００に保存される（ステップＳ３１ｄ１）。認証器情報Ｄａ１は、秘密鍵Ｋｓとともに暗号化された状態で保存されてもよい。

その後、ユーザ端末２００を用いて認証サーバ１００にログインする場合には、図６のステップＳ３２ａ〜Ｓ３２ｃと同様の処理が実行される。なお、図７には示していないが、ステップＳ３２ｃでは実際には、鍵保存時刻Ｔｇ１の照合も行われる。

次に、ユーザが利用する端末装置がユーザ端末２００からユーザ端末２００ａに変更されたとする。この場合、変更後のユーザ端末２００ａは、暗号化された秘密鍵Ｋｓと認証器情報Ｄａ１とをバックアップサーバ３００からダウンロードし、秘密鍵Ｋｓを復元する。認証器情報Ｄａ１が暗号化されている場合、認証器情報Ｄａ１も復元される。ユーザ端末２００ａは、自装置の生体認証器の認証強度を識別可能な認証器情報Ｄａ２を取得し、ダウンロードされた認証器情報Ｄａ１と照合する（ステップＳ３３ａ１）。

ユーザ端末２００ａは、認証器情報Ｄａ２が示す認証強度が、認証器情報Ｄａ１が示す認証強度以上である場合に、認証強度を維持できると判断して、復元された秘密鍵Ｋｓをユーザ端末２００ａ内のセキュアな記憶領域に保存する。一方、認証器情報Ｄａ２が示す認証強度が、認証器情報Ｄａ１が示す認証強度より低い場合には、秘密鍵Ｋｓは保存されず、生体認証の方法を変更して認証強度を高めるようにユーザに通知される。

次に、ユーザ端末２００ａを用いて認証サーバ１００にログインする場合には、認証サーバ１００からユーザ端末２００ａに対して、生体認証によるユーザの認証が依頼されるとともに、チャレンジコードが送信される（ステップＳ３３ｂ）。ユーザ端末２００ａは、ユーザの生体認証を実行する（ステップＳ３３ｃ）。

生体認証に成功すると、チャレンジコードに署名することでレスポンスデータが生成される。ただし、端末変更後の初回ログインの場合には、ユーザ端末２００ａは、チャレンジコードと認証器情報Ｄａ２とを含むデータセットに対して秘密鍵Ｋｓを用いて署名することでレスポンスデータを生成し、認証サーバ１００に送信する。なお、実際には図６に示したように、署名対象のデータセットには鍵保存時刻Ｔｇ２も含まれる。

認証サーバ１００は、変更後のユーザ端末２００ａからの初回ログイン時には、レスポンスデータを公開鍵Ｋｐを用いて検証するとともに、認証器情報Ｄａ２を検証する（ステップＳ３３ｄ１）。なお、ユーザ端末２００ａからの初回ログインであることは、例えば、認証サーバ１００に登録されている鍵保存時刻と、ユーザ端末２００ａから送信された鍵保存時刻との比較結果から判断できる。

認証器情報Ｄａ２の検証では、受信した認証器情報Ｄａ２が示す生体認証器の認証強度が、認証ポリシーの条件を満たすかが判定される。認証サーバ１００は、復元されたチャレンジコードと送信されたチャレンジコードとが一致し、かつ、生体認証器の認証強度が条件を満たす場合に、認証に成功したと判断してユーザのログインを受け入れる。一方、認証サーバ１００は、復元されたチャレンジコードと送信されたチャレンジコードとが一致した場合でも、生体認証器の認証強度が条件を満たさない場合には、ログインを拒否する。

以上の処理によれば、変更後のユーザ端末２００ａは、バックアップされていた秘密鍵Ｋｓを復元する際に、変更前のユーザ端末２００についての認証器情報Ｄａ１と、変更後のユーザ端末２００ａについての認証器情報Ｄａ２とを照合する。そして、ユーザ端末２００ａは、認証器情報Ｄａ２が示す認証強度が認証器情報Ｄａ１が示す認証強度より低下しないと判定された場合にのみ、復元された秘密鍵Ｋｓをユーザ端末２００ａ内に保存する。

これにより、変更後のユーザ端末２００ａにおける生体認証の認証強度が、ユーザ端末の変更前より低下しないことが保証される。このため、ユーザ端末２００ａから認証サーバ１００にログインする際に、認証サーバ１００でのユーザ認証の認証強度が低下しないことも保証される。

また、変更後のユーザ端末２００ａから認証サーバ１００へのログインの際には、ユーザ端末２００ａについての認証器情報Ｄａ２が認証サーバ１００に送信される。認証サーバ１００は、変更後のユーザ端末２００ａからの初回ログインの際に、送信された認証器情報Ｄａ２に基づいてユーザ端末２００ａの認証強度を検証する。そして、認証サーバ１００は、送信された認証器情報Ｄａ２が示す認証強度が所定の条件を満たす場合にのみ、ログインを許可する。これにより、ログイン要求元のユーザ端末が変更された場合でも、認証サーバ１００でのユーザ認証の認証強度が低下しないことが保証される。

図７の例では、変更後のユーザ端末２００ａでの秘密鍵Ｋｓの復元・保存時と、認証サーバ１００に対する初回ログイン時の両方において、認証器情報に基づく認証強度の検証が行われる。これにより、認証強度の維持についての確実性が向上する。また、例えば、ユーザ端末２００ａで認証強度が検証されることにより、端末変更によって認証強度が低下する場合に、その旨を秘密鍵Ｋｓの復元時点でユーザに通知することができる。そのため、認証強度が不適切な状態で認証サーバ１００にログインを要求して、ログインを拒否されるという事態の発生が抑止される。したがって、認証強度の低下を未然に防止できるとともに、ユーザの利便性を向上させることもできる。

また、秘密鍵Ｋｓの復元・保存時と、初回ログイン時の一方においてのみ認証強度の検証が行われてもよい。秘密鍵Ｋｓの復元・保存時にのみ認証強度の検証が行われる場合、ログインの際に認証器情報Ｄａ２が認証サーバ１００に送信される必要はない。一方、初回ログイン時にのみ認証強度の検証が行われる場合、変更前のユーザ端末２００についての認証器情報Ｄａ１がバックアップサーバ３００にバックアップされる必要はない。

また、図７の例では、認証サーバ１００での認証強度の検証は、ユーザ端末の変更後の初回ログイン時にのみ実行されている。しかし、別の方法として、認証サーバ１００に対するログインが要求されるたびに、毎回、認証サーバ１００においてユーザ端末からの認証器情報に基づく認証強度の検証が実行されてもよい。

以下、本実施の形態に係る認証システムについて、さらに詳しく説明する。
図８は、認証システム内の各装置が備える処理機能の構成例を示す図である。
まず、認証サーバ１００は、記憶部１１０とＦＩＤＯサーバ１２０を備える。

記憶部１１０は、ＲＡＭ１０２やＨＤＤ１０３など、認証サーバ１００が備える記憶装置の記憶領域として実現される。記憶部１１０には、ユーザデータベース（ＤＢ）１１１と認証ポリシー１１２が記憶される。

ユーザデータベース１１１には、認証サーバ１００にログインするユーザに関する情報が登録される。ユーザに関する情報としては、例えば、公開鍵、鍵保存時刻、認証器情報が登録される。

認証ポリシー１１２には、認証強度に関する条件を示す情報が記述される。例えば、認証ポリシー１１２には、利用可能な生体センサの識別情報、利用可能な生体認証アルゴリズムの識別情報の少なくとも一方が記述される。あるいは、認証ポリシー１１２には、認証強度の下限値が記述されてもよい。この場合、認証強度を示す数値としては、例えば、他人受入率（ＦＡＲ）の逆数や、本人拒否率（ＦＲＲ）の逆数を適用可能である。

ＦＩＤＯサーバ１２０の処理は、例えば、認証サーバ１００が備えるプロセッサ１０１が所定のプログラムを実行することで実現される。ＦＩＤＯサーバ１２０は、ユーザに関する情報の登録処理や、ユーザからのログイン要求に応じた認証処理を実行する。

ここで、図９は、ユーザデータベースのデータ構成例を示す図である。図９に示すように、ユーザデータベース１１１は、ユーザごとのレコードを含む。各レコードには、ユーザを識別するアカウント名と、前述した公開鍵、鍵保存時刻および認証器情報が登録される。

以下、図８に戻って説明を続ける。
ユーザ端末２００は、記憶部２１０、ＦＩＤＯクライアント２２０、バックアップ処理部２３０および生体認証処理部２４０を備える。

記憶部２１０は、ユーザ端末２００が備える図示しない記憶装置の記憶領域として実現される。記憶部２１０には、鍵データベース（ＤＢ）２１１と設定情報２１２が記憶される。鍵データベース２１１には、ユーザの秘密鍵および鍵保存時刻が登録される。設定情報２１２は、ユーザ端末２００での生体認証処理に関する情報を含む。この設定情報２１２は、ユーザ端末２００の生体認証器についての認証器情報を取得するために用いられる情報であり、例えば、生体センサ２０１や生体認証アプリケーションの製造者、型名、仕様、生体認証アルゴリズムの仕様などの情報を含む。

ＦＩＤＯクライアント２２０、バックアップ処理部２３０および生体認証処理部２４０の処理は、例えば、ユーザ端末２００が備える図示しないプロセッサが所定のプログラムを実行することで実現される。

ＦＩＤＯクライアント２２０は、認証サーバ１００に対する公開鍵などの情報の登録処理や、認証サーバ１００にログインするための処理を実行する。バックアップ処理部２３０は、秘密鍵などの情報をバックアップサーバ３００に保存する処理や、バックアップサーバ３００にバックアップされた情報を取得して復元する処理を実行する。生体認証処理部２４０は、生体センサ２０１によって読み取られた生体情報に基づいてユーザの認証処理を実行する。

なお、以下の説明では、生体認証器についての認証器情報として、生体認証器の識別子が用いられるものとする。ここで、ユーザ端末２００の生体認証器とは、ＦＩＤＯ認証システム上の認証器（Authenticator）を示し、具体的には、生体センサ２０１と生体認証処理部２４０とを用いて実現される生体認証機能を指す。この場合、ユーザ端末２００が備える生体認証器の識別子とは、生体センサ２０１と生体認証処理部２４０とを用いて実現される生体認証機能を識別する情報（例えば、ベンダ名と型式名）を指す。ユーザ端末２００が備える生体認証器の識別子は、このような生体認証機能を実現するユーザ端末２００自体を識別する情報であってもよい。

ここで、図１０は、鍵データベースのデータ構成例を示す図である。鍵データベース２１１には、ユーザの秘密鍵および鍵保存時刻が、ユーザのアカウント名に対応付けて登録される。また、ログイン先のＷｅｂサイトが複数存在する場合（例えば、ログイン先の認証サーバが複数存在する場合）、鍵データベース２１１には、ログイン先のＷｅｂサイトごとに秘密鍵および鍵保存時刻が登録される。図１０はこの場合を示しており、「登録サイトＵＲＬ」は、ログイン先のＷｅｂサイトのＵＲＬ（Uniform Resource Locator）を示している。さらに、ユーザ端末２００が複数のユーザに利用される場合、これらの情報はユーザごとに鍵データベース２１１に登録される。

以下、図８に戻って説明を続ける。
ユーザ端末２００ａも、ユーザ端末２００と同様に、記憶部２１０ａ、ＦＩＤＯクライアント２２０ａ、バックアップ処理部２３０ａおよび生体認証処理部２４０ａを備える。記憶部２１０ａは、ユーザ端末２００ａが備える図示しない記憶装置の記憶領域として実現される。記憶部２１０ａには、鍵データベース２１１と同様のデータ構成を有する鍵データベース（ＤＢ）２１１ａと、ユーザ端末２００ａの生体認証処理に関する設定情報２１２ａが記憶される。

ＦＩＤＯクライアント２２０ａ、バックアップ処理部２３０ａおよび生体認証処理部２４０ａの処理は、例えば、ユーザ端末２００ａが備える図示しないプロセッサが所定のプログラムを実行することで実現される。ＦＩＤＯクライアント２２０ａ、バックアップ処理部２３０ａ、生体認証処理部２４０ａは、それぞれＦＩＤＯクライアント２２０、バックアップ処理部２３０、生体認証処理部２４０と同様の処理を実行する。ただし、生体認証処理部２４０ａは、生体センサ２０１ａによって読み取られた生体情報に基づいてユーザの認証処理を実行する。

なお、前述のように、以下の説明では、生体認証器についての認証器情報として、生体認証器の識別子が用いられるものとする。ここで、ユーザ端末２００ａの生体認証器とは、生体センサ２０１ａと生体認証処理部２４０ａとを用いて実現される生体認証機能を指す。この場合、ユーザ端末２００ａが備える生体認証器の識別子とは、生体センサ２０１ａと生体認証処理部２４０ａとを用いて実現される生体認証機能を識別する情報（例えば、ベンダ名と型式名）を指す。ユーザ端末２００ａが備える生体認証器の識別子は、このような生体認証機能を実現するユーザ端末２００ａ自体を識別する情報であってもよい。

バックアップサーバ３００は、記憶部３１０とサーバ処理部３２０を備える。
記憶部３１０は、バックアップサーバ３００が備える図示しない記憶装置の記憶領域として実現される。記憶部３１０には、バックアップデータベース（ＤＢ）３１１が記憶される。バックアップデータベース３１１には、ユーザごとのバックアップデータがユーザのアカウント名に対応付けて登録される。

サーバ処理部３２０の処理は、例えば、バックアップサーバ３００が備える図示しないプロセッサが所定のプログラムを実行することで実現される。サーバ処理部３２０は、ユーザ端末からの送信されたバックアップデータをバックアップデータベース３１１に登録する処理や、バックアップデータをバックアップデータベース３１１から読み出してユーザ端末に送信する処理を実行する。

図１１は、ユーザ端末での鍵のバックアップ処理手順を示すフローチャートの例である。図１１では例として、ユーザ端末２００のバックアップ処理部２３０および生体認証処理部２４０による処理について説明するが、ユーザ端末２００ａのバックアップ処理部２３０ａおよび生体認証処理部２４０ａも同様の処理を実行可能である。

また、バックアップサーバ３００にバックアップする秘密鍵の暗号化には、ファジーコミットメントによる生体情報を用いた暗号化手法が用いられるものとする。この手法によれば、秘密鍵を暗号化してバックアップを行った端末側のユーザと、その秘密鍵を復号して利用する端末側のユーザとの同一性を、生体認証を用いて保証することが可能となる。

［ステップＳ４１］バックアップ処理部２３０は、鍵のバックアップを要求するためのユーザによる操作入力を受けると、生体認証を行うようにユーザに通知するとともに、生体認証処理部２４０に認証処理の実行を依頼する。生体センサ２０１によってユーザの生体情報が読み取られると、生体認証処理部２４０は、その生体情報を取得してユーザの認証を実行する。例えば、生体認証処理部２４０は、取得した生体情報に基づく特徴情報と、あらかじめ登録されたユーザの生体情報に基づく特徴情報とを比較して、特徴情報間の類似度を算出する。生体認証処理部２４０は、類似度が所定の閾値以上である場合、認証成功と判定し、認証に成功したことをバックアップ処理部２３０に通知する。このように認証に成功した場合、処理がステップＳ４２に進められる。

［ステップＳ４２］ここでは図１０の例のように、鍵データベース２１１には登録サイトごとに情報が登録されているとする。バックアップ処理部２３０は、ステップＳ４１で得られた生体情報を用いて、次のような手順で登録サイトごとにファジーコミットメントのヘルパデータを生成する。

バックアップ処理部２３０は、鍵データベース２１１から登録サイトに対応する秘密鍵を取得する。バックアップ処理部２３０は、取得した秘密鍵を第１の誤り訂正符号化によって符号化データに変換し、乱数を生成して符号化データに加算する。バックアップ処理部２３０は、加算後のデータを第２の誤り訂正符号化によって符号化データに変換し、この符号化データに生体情報から抽出した特徴量ビットを加算することで、登録サイトに対応するヘルパデータを生成する。なお、ヘルパデータの生成過程における加算処理は、例えば、排他的論理和の計算によって行われる。

［ステップＳ４３］バックアップ処理部２３０は、登録サイトごとに、ヘルパデータと、登録サイトのＵＲＬと、鍵保存時刻とを含むデータセットを生成する。
［ステップＳ４４］バックアップ処理部２３０は、設定情報２１２に基づいて、ユーザ端末２００の生体認証器についての認証器情報を取得する。ここでは例として、認証器情報は、生体認証器の識別子を示すものとする。

［ステップＳ４５］バックアップ処理部２３０は、生成された各データセットに、ユーザのアカウント名および認証器情報を付加してバックアップサーバ３００に送信し、バックアップを要求する。バックアップサーバ３００のサーバ処理部３２０は、バックアップ要求に応じて、データセットおよび認証器情報を、アカウント名をキーにしてバックアップデータベース３１１に登録する。

なお、以上の処理例では秘密鍵が暗号化された状態でバックアップされるが、秘密鍵に加えて登録サイトのＵＲＬや鍵保存時刻、認証器情報も暗号化されてもよい。この場合、ヘルパデータの生成の際に、暗号化の対象データと秘密鍵とを組み合わせたデータに対して第１の誤り訂正符号化が実行されればよい。

図１２は、鍵のバックアップ実行時における画面遷移例を示す図である。図１１のような鍵のバックアップ処理が実行される際、ユーザ端末２００の表示装置には図１２に示すような画面が表示される。

まず、鍵管理のための画面５００が表示される。この画面５００には、ボタン５０１〜５０４が表示される。ボタン５０１は、鍵データベース２１１に登録されたＷｅｂサイトの一覧を表示させるための選択ボタンである。ボタン５０２は、鍵をバックアップするための選択ボタンである。ボタン５０３は、バックアップされた鍵を復元するための選択ボタンである。ボタン５０４は、登録された鍵をリセットするための選択ボタンである。

ボタン５０２に対する選択操作が行われることで、鍵のバックアップ処理が開始され、画面５１０が表示される。画面５１０には、鍵のバックアップを行うことが文字情報で表示され、さらにボタン５１１〜５１３が表示される。ボタン５１１は、バックアップ処理の実行を継続するための選択ボタンであり、ボタン５１２は、バックアップ処理の実行を中止するための選択ボタンである。ボタン５１３は、ボタン５０１と同様に、登録されたＷｅｂサイトの一覧を表示させるための選択ボタンであり、ユーザはボタン５１３に対する選択操作を行うことで、登録サイトを確認できる。

ボタン５１２に対する選択操作が行われると、生体認証を行うようにユーザに通知するための画面５２０が表示される。この画面５２０は、図１１のステップＳ４１で表示される画面の一例である。また、ユーザの生体情報が読み取られ、生体認証に成功し、バックアップサーバ３００へのバックアップが完了すると（図１１のステップＳ４５の処理が完了すると）、画面５３０が表示されて、バックアップが完了したことがユーザに通知される。

図１３、図１４は、ユーザ端末での鍵の復元処理手順を示すフローチャートの例である。図１３では例として、ユーザ端末２００ａのバックアップ処理部２３０ａおよび生体認証処理部２４０ａによる処理について説明するが、ユーザ端末２００のバックアップ処理部２３０および生体認証処理部２４０も同様の処理を実行可能である。

［ステップＳ５１］バックアップ処理部２３０ａは、鍵を復元するためのユーザによる操作入力を受けると、ユーザのバックアップデータがバックアップサーバ３００に存在するかを確認する。具体的には、バックアップ処理部２３０ａは、ユーザのアカウント名をバックアップサーバ３００に送信し、バックアップデータの存在確認を要求する。

バックアップサーバ３００のサーバ処理部３２０は、受信したアカウント名をキーとしてバックアップデータベース３１１を検索して、アカウント名に対応するバックアップデータの有無を確認し、確認結果をユーザ端末２００ａに通知する。

［ステップＳ５２］ユーザ端末２００ａのバックアップ処理部２３０ａは、ユーザのバックアップデータが存在するという通知を受けると、生体認証を行うようにユーザに通知するとともに、生体認証処理部２４０ａに認証処理の実行を依頼する。生体センサ２０１ａによってユーザの生体情報が読み取られると、生体認証処理部２４０ａは、その生体情報を取得してユーザの認証を実行する。生体認証処理部２４０ａは、ユーザの認証に成功すると、認証に成功したことをバックアップ処理部２３０ａに通知する。このように認証に成功した場合、処理がステップＳ５３に進められる。

［ステップＳ５３］バックアップ処理部２３０ａは、乱数を生成し、この乱数を前述の第２の誤り訂正符号化によって符号化データに変換する。バックアップ処理部２３０ａは、この符号化データに、ステップＳ５２で得られた生体情報から抽出した特徴量ビットを加算する（例えば、排他的論理和を計算する）ことで、クエリデータを生成する。

［ステップＳ５４］バックアップ処理部２３０ａは、バックアップサーバ３００に対してユーザのバックアップデータの送信を要求する。バックアップサーバ３００のサーバ処理部３２０は、ステップＳ５１で受信したアカウント名に対応付けられたバックアップデータをバックアップデータベース３１１から読み出して、ユーザ端末２００ａに送信する。これにより、ユーザ端末２００ａのバックアップ処理部２３０ａは、バックアップデータとして、ヘルパデータを含むデータセットと、認証器情報とをバックアップサーバ３００から受信する。

［ステップＳ５５］バックアップ処理部２３０ａは、受信した各データセットから登録サイトごとのヘルパデータを抽出し、登録サイトごとに、抽出されたヘルパデータと、ステップＳ５３で算出されたクエリデータとに基づいて秘密鍵を復元する。具体的には、バックアップ処理部２３０ａは、ヘルパデータとクエリデータとを加算する（例えば、排他的論理和を計算する）ことで秘密鍵を復号する。ここで、ヘルパデータ生成時およびクエリデータ生成時にそれぞれ使用された生体情報が類似していれば、前述の第１の誤り訂正符号化による符号化データによって乱数の差異が相殺され、第２の誤り訂正符号化による符号化データによって生体情報に基づく特徴量ビットの差異が相殺される。このため、生体情報同士が類似している場合（すなわち、ヘルパデータ生成時およびクエリデータ生成時のそれぞれにおける認証対象のユーザが同じ場合）、ヘルパデータとクエリデータとの加算によって、秘密鍵が復号される。

［ステップＳ５６］バックアップ処理部２３０ａは、秘密鍵の復元に成功した場合、処理を図１４のステップＳ６１に進め、秘密鍵の復元に失敗した場合、処理をステップＳ５７に進める。

［ステップＳ５７］バックアップ処理部２３０ａは、秘密鍵の復元に失敗したことをユーザに通知して、鍵の復元処理を終了する。このとき、バックアップ処理部２３０ａは、例えば、秘密鍵の復元に失敗した理由をユーザに提示してもよい。なお、このケースでの認証失敗の理由は、バックアップ時と復元時の各ユーザが同一でない（ユーザ認証失敗）か、または生体認証の種類が異なる（認証方法エラー）ことのいずれかである。

なお、秘密鍵の復元は登録サイトごとに実行されるので、実際には、秘密鍵の復元に失敗した登録サイトがあった場合にのみ、その登録サイトについてステップＳ５７が実行される。秘密鍵の復元に成功した登録サイトが１つでも存在する場合には、それらの登録サイトを処理対象としてステップＳ６１以降の処理が実行される。

以下、図１４を用いて説明を続ける。
［ステップＳ６１］バックアップ処理部２３０ａは、受信した各データセットから鍵保存時刻を抽出し、現在時刻と比較する。バックアップ処理部２３０ａは、抽出された鍵保存時刻が現在時刻より古い場合（前の時刻の場合）、処理をステップＳ６３に進める。一方、バックアップ処理部２３０ａは、抽出された鍵保存時刻が現在時刻と同じか、それより新しい場合（後の時刻の場合）には、処理をステップＳ６２に進める。ここでは、抽出された鍵保存時刻のうちの少なくとも１つが、現在時刻と同じかそれより新しい場合には、処理がステップＳ６２に進められる。

［ステップＳ６２］ステップＳ６１でＮｏと判定される場合、バックアップデータは改ざんされた不正データである可能性がある。このため、バックアップ処理部２３０ａは、不正データであるため復元に失敗したことをユーザに通知する。

［ステップＳ６３］バックアップ処理部２３０ａは、設定情報２１２ａに基づいて、ユーザ端末２００ａの生体認証器についての認証器情報を取得する。ここでは、図１１のステップＳ４４と同様に、認証器情報として生体認証器の識別子が取得される。バックアップ処理部２３０ａは、取得した認証器情報（ユーザ端末２００ａについての認証器情報）が、バックアップサーバ３００から受信した認証器情報と一致するかを判定する。これらの認証器情報が一致する場合、処理がステップＳ６７に進められ、一致しない場合、処理がステップＳ６４に進められる。

［ステップＳ６４］バックアップ処理部２３０ａは、ステップＳ６３で取得した、ユーザ端末２００ａの生体認証器についての認証器情報をメタデータサーバ４００に送信して、認証器情報に対応する生体認証器の構成情報の送信を要求する。要求された構成情報がメタデータサーバ４００から送信されると、バックアップ処理部２３０ａはこれを受信する。

なお、このステップＳ６４では、バックアップ処理部２３０ａは、ユーザ端末２００ａの生体認証器についての認証器情報だけでなく、バックアップサーバ３００から受信した認証器情報もメタデータサーバ４００に送信して、各認証器情報に対応する構成情報の送信を要求してもよい。この場合、バックアップ処理部２３０ａは、ユーザ端末２００ａの生体認証器についての構成情報と、変更前のユーザ端末の生体認証器についての構成情報とをメタデータサーバ４００から受信する。

［ステップＳ６５］バックアップ処理部２３０ａは、受信した構成情報に基づき、ユーザ端末２００ａの生体認証器の認証強度が所定の条件を満たすかを判定する。認証強度が条件を満たす場合、処理がステップＳ６７に進められ、認証強度が条件を満たさない場合、処理がステップＳ６６に進められる。

［ステップＳ６６］ステップＳ６５でＮｏと判定される場合、変更後のユーザ端末２００ａが備える生体認証器の認証強度が、所定の条件を満たしていない。このため、バックアップ処理部２３０ａは、生体認証の方法が認証強度の条件を満たしていない「認証方法エラー」であるために復元に失敗したことをユーザに通知する。

［ステップＳ６７］バックアップ処理部２３０ａは、現在時刻を取得し、取得した現在時刻を新たな鍵生成時刻として生成する。
［ステップＳ６８］バックアップ処理部２３０ａは、復元された秘密鍵を鍵データベース２１１ａに保存する。このとき、鍵データベース２１１ａには、登録サイトごとに、登録サイトのＵＲＬ、秘密鍵および新たな鍵生成時刻が登録される。バックアップ処理部２３０ａは、鍵の復元に成功したことをユーザに通知して、処理を終了する。

ここで、上記のステップＳ６５では、例えば、次のような条件判定処理が実行される。
例えば、ステップＳ６４で、ユーザ端末２００ａの生体認証器についての構成情報だけでなく、バックアップサーバ３００から受信した認証器情報についての構成情報が取得されたとする。この場合、バックアップ処理部２３０ａは、各構成情報に記述された認証強度を示す情報を比較して、端末変更後の生体認証器の認証強度が、端末変更前より低下しないかを判定する。認証強度が低下しない場合、ステップＳ６５では「条件を満たす」と判定され、認証強度が低下する場合、ステップＳ６５では「条件を満たさない」と判定される。

また、例えば、ステップＳ６４で、ユーザ端末２００ａの生体認証器についての構成情報のみ取得された場合、ステップＳ６５では、構成情報に記述された認証強度を示す情報に基づいて、その認証強度があらかじめ記憶された認証強度の閾値以上かが判定される。構成情報に基づく認証強度が閾値以上の場合、条件を満たすと判定される。この場合、比較対象となる閾値は、認証サーバ１００から通知されたものであってもよい。また、この場合、閾値は登録サイトごとに用意されていてもよい。この場合には、ステップＳ６５の条件判定処理は登録サイトごとに実行され、認証強度が条件を満たす登録サイトについてのみ、ステップＳ６８で秘密鍵および鍵生成時刻が登録されればよい。

図１５は、生体認証器の構成情報の例を示す図である。例えば、図１４のステップＳ６４である生体認証器の構成情報の送信が要求された場合、メタデータサーバ４００からは図１５に示す構成情報４１０が送信される。

構成情報４１０においては、第３行目の「１２３４＃５６７８」が、生体認証器の識別情報（ベンダ名およびモデル名）を示す。ステップＳ６４では、例えば、認証器情報としてこの識別情報が送信され、メタデータサーバ４００は、受信した識別情報をキーとしてこの識別情報に対応する生体認証器の構成情報４１０を検索し、送信する。

また、例えば、構成情報４１０の第６行目は生体認証器の認証アルゴリズムのプロトコルバージョンを示し、第９行目は生体認証器の暗号方式を示し、第１０行目は暗号化における鍵長（鍵のビット数）を示し、第１６行目はＦＡＲを示す。図１４のステップＳ６５では、これらの項目を認証強度の条件として用いることができる。例えば、下記のような条件を満たす場合に、ステップＳ６５で認証強度が条件を満たすと判定される。なお、下記の条件のうち１つだけが判定に用いられてもよいし、あるいは、２以上の条件が用いられて、それらのすべてを満たす場合にステップＳ６５で認証強度が条件を満たすと判定されてもよい。

（条件１）端末変更後の生体認証器について許可されるプロトコルバージョンが１以上あらかじめ設定され、ステップＳ６４で取得された構成情報に記述されたプロトコルバージョンが、設定されたプロトコルバージョンの１つとして含まれる。

（条件２）端末変更後の生体認証器について許可される暗号方式が１以上あらかじめ設定され、ステップＳ６４で取得された構成情報に記述された暗号方式が、設定された暗号方式の１つとして含まれる。

（条件３）ステップＳ６４で取得された構成情報に記述された鍵長が、所定の下限閾値以上である。
（条件４）ステップＳ６４で取得された構成情報に記述されたＦＡＲが、所定の上限閾値以下である。

なお、上記の認証強度の条件は、登録サイトごと（認証サーバごと）に個別に設定され得る。例えば、認証サーバ１００では、認証サーバ１００に固有の条件が認証ポリシー１１２に記述される。

一方、ユーザ端末での秘密鍵の復号時において、登録サイトごとに個別の条件を用いて認証強度を検証した場合、処理が煩雑になる。そこで、ユーザ端末での秘密鍵の復号時には、登録サイトごとの認証強度の条件を用いずに、単に端末変更後に認証強度が低下しないことが検証されてもよい。この場合、ステップＳ６５では、ユーザ端末２００ａの生体認証器についての構成情報と、バックアップサーバ３００から受信した認証器情報についての構成情報との比較結果に基づき、ユーザ端末２００ａでの認証強度が低下しない場合にＹｅｓと判定される。例えば、端末変更後における認証強度を示す数値（鍵長や、ＦＡＲの逆数など）が、端末変更前における同じ項目の数値以上となる場合に、ステップＳ６５でＹｅｓと判定される。

図１６は、鍵の復元処理の実行時における画面遷移例を示す図である。図１３、図１４のような鍵の復元処理が実行される際、ユーザ端末２００ａの表示装置には図１６に示すような画面が表示される。

まず、図１２と同様の鍵管理のための画面５００が表示され、ボタン５０３に対する選択操作が行われると、鍵の復元処理が開始される。このとき、例えば、図１３のステップＳ５１の処理が実行され、ユーザのバックアップデータがバックアップサーバ３００に存在した場合、画面５４０が表示される。画面５４０には、バックアップデータが存在することが文字情報で表示され、さらにボタン５４１〜５４３が表示される。ボタン５４１は、鍵の復元処理の実行を継続するための選択ボタンであり、ボタン５４２は、鍵の復元処理の実行を中止するための選択ボタンである。ボタン５４３は、ボタン５０１と同様に、登録されたＷｅｂサイトの一覧を表示させるための選択ボタンであり、ユーザはボタン５４３に対する選択操作を行うことで、登録サイトを確認できる。

ボタン５４１に対する選択操作が行われると、生体認証を行うようにユーザに通知するための画面５５０が表示される。この画面５５０は、図１３のステップＳ５２で表示される画面の一例である。ユーザの生体情報が読み取られ、生体認証に成功すると、図１３のステップＳ５３以降の処理が実行されて、鍵の復元処理が継続される。

ここで、秘密鍵の復元に成功し、図１４のステップＳ６８で秘密鍵（および鍵生成時刻）が鍵データベース２１１ａに保存されると、画面５６０が表示されて、鍵の復元が正常に完了したことがユーザに通知される。一方、秘密鍵の復元に失敗すると、画面５７０が表示される。画面５７０は、図１４のステップＳ６６が実行された場合に表示される画面の例であり、生体認証の方法を変えるようにユーザに通知するための文字情報が表示されている。

なお、前述のように、認証強度の条件についての判定により、鍵の復元の成否は登録サイトごとに異なる場合がある。この場合、鍵の復元処理が終了したとき、鍵の復元に成功した登録サイトの一覧や、復元に失敗した登録サイトの一覧が表示されてもよい。

図１７は、ユーザ端末でのログイン処理手順を示すフローチャートの例である。図１７では例として、ユーザ端末２００ａのＦＩＤＯクライアント２２０ａによる処理について説明するが、ユーザ端末２００のＦＩＤＯクライアント２２０も同様の処理を実行可能である。

［ステップＳ７１］ユーザにより、認証サーバ１００にログインするための操作が行われる。すると、ＦＩＤＯクライアント２２０ａは、ログイン要求をユーザのアカウント名とともに認証サーバ１００に送信する。

［ステップＳ７２］ＦＩＤＯクライアント２２０ａは、認証サーバ１００から、生体認証によるユーザの認証依頼をチャレンジコードとともに受信する。
［ステップＳ７３］ＦＩＤＯクライアント２２０ａは、生体認証を行うようにユーザに通知するとともに、生体認証処理部２４０ａに認証処理の実行を依頼する。生体センサ２０１ａによってユーザの生体情報が読み取られると、生体認証処理部２４０ａは、その生体情報を取得してユーザの認証を実行する。生体認証処理部２４０ａは、ユーザの認証に成功すると、認証に成功したことをＦＩＤＯクライアント２２０ａに通知する。このように認証に成功した場合、処理がステップＳ７４に進められる。

［ステップＳ７４］ＦＩＤＯクライアント２２０ａは、設定情報２１２ａに基づいて、ユーザ端末２００ａの生体認証器についての認証器情報を取得する。ここでは、図１１のステップＳ４４や図１４のステップＳ６３と同様に、認証器情報として生体認証器の識別子が取得される。

［ステップＳ７５］ＦＩＤＯクライアント２２０ａは、認証サーバ１００に対応する秘密鍵および鍵保存時刻を鍵データベース２１１ａから取得する。ＦＩＤＯクライアント２２０ａは、ステップＳ７２で受信したチャレンジコードと、鍵データベース２１１ａから取得した鍵保存時刻と、ステップＳ７４で取得した認証器情報とを含むデータセットに対して、鍵データベース２１１ａから取得した秘密鍵を用いて署名する。具体的には、データセットが秘密鍵によって暗号化され、これによってレスポンスデータが生成される。

［ステップＳ７６］ＦＩＤＯクライアント２２０ａは、生成されたレスポンスデータを認証サーバ１００に送信する。
［ステップＳ７７］ＦＩＤＯクライアント２２０ａは、認証サーバ１００からユーザの認証結果に応じた情報を受信する。認証に成功してログインが受け入れられた場合、その旨を通知する画面が表示され認証サーバ１００からサービスの提供が開始される。一方、認証に失敗したことが通知された場合、処理がステップＳ７８に進められる。

［ステップＳ７８］認証に失敗した理由に応じた処理が実行される。
例えば、ユーザ端末２００ａが変更前の端末であり、すでに新たなユーザ端末から認証サーバ１００に対するログインが実行済みの場合、認証サーバ１００からは鍵消去依頼が送信される。ＦＩＤＯクライアント２２０ａは、鍵消去依頼を受信すると、鍵データベース２１１ａに登録された、認証サーバ１００に対応する秘密鍵を消去する。

また、例えば、ユーザ端末２００ａの生体認証器の認証強度が認証ポリシー１１２に記載された条件を満たさない「認証方法エラー」の場合、その旨を通知する画面を表示するための表示情報が認証サーバ１００から送信される。ＦＩＤＯクライアント２２０ａは、受信した表示情報に基づく画面を表示装置に表示する。この画面には、例えば、生体認証の方法を変えて認証強度を高めるように促す情報が表示される。

図１８、図１９は、認証サーバでのログイン受け付け処理手順を示すフローチャートの例である。
［ステップＳ８１］認証サーバ１００のＦＩＤＯサーバ１２０は、ユーザ端末からログイン要求をユーザのアカウント名とともに受信する。

［ステップＳ８２］ＦＩＤＯサーバ１２０は、受信したアカウント名に対応するユーザの情報がユーザデータベース１１１に登録されていることを確認すると、乱数の発生によってチャレンジコードを生成し、ユーザ端末に送信する。

［ステップＳ８３］ＦＩＤＯサーバ１２０は、ユーザ端末からレスポンスデータを受信する。
［ステップＳ８４］ＦＩＤＯサーバ１２０は、ステップＳ８２で受信したアカウント名に対応する秘密鍵をユーザデータベース１１１から取得し、レスポンスデータを秘密鍵を用いて復号する。これにより、レスポンスデータからチャレンジコード、鍵保存時刻および認証器情報が復元される。

［ステップＳ８５］ＦＩＤＯサーバ１２０は、復元されたチャレンジコードが、ステップＳ８２で送信したチャレンジコードと一致するかを判定する。チャレンジコードが一致する場合、処理がステップＳ８７に進められ、チャレンジコードが一致しない場合、処理がステップＳ８６に進められる。

［ステップＳ８６］このケースでは、受信データが改ざんされるといった不正による認証エラーとなる。ＦＩＤＯサーバ１２０は、認証エラーであることを示す画面を表示するための表示情報をユーザ端末に送信して、その画面を通じて認証エラーであることをユーザに通知する。

［ステップＳ８７］ＦＩＤＯサーバ１２０は、ステップＳ８２で受信したアカウント名に対応する鍵保存時刻をユーザデータベース１１１から取得し、ステップＳ８４でレスポンスデータから復元された鍵保存時刻と比較する。

［ステップＳ８８］ユーザデータベース１１１から取得した鍵保存時刻（登録されている鍵保存時刻）より、レスポンスデータから復元された鍵保存時刻（受信した鍵保存時刻）の方が古い場合（前の時刻の場合）、処理がステップＳ８９に進められる。一方、受信した鍵保存時刻が、登録されている鍵保存時刻と同じか、それより新しい場合、処理が図１９のステップＳ９１に進められる。

［ステップＳ８９］このケースでは、例えば、ユーザ端末が変更され、ログイン要求元は変更前のユーザ端末であり、しかも変更後のユーザ端末から認証サーバ１００へのログインが１回以上成功している。そこで、ＦＩＤＯサーバ１２０は、ログイン要求元のユーザ端末に対して、認証サーバ１００に対応する秘密鍵を消去するように依頼する。これにより、変更前のユーザ端末が保持する秘密鍵が自動的に無効化され、そのユーザ端末からのログインが不可能になる。

なお、ステップＳ８８でＹｅｓと判定される場合、変更前のユーザ端末からの不正アクセスである可能性もある。ステップＳ８９でログインを受け入れないことにより、このような不正アクセスを阻止できる。

以下、図１９を用いて説明を続ける。
［ステップＳ９１］登録されている鍵保存時刻より、受信した鍵保存時刻の方が新しい場合、処理がステップＳ９２に進められる。一方、これらの時刻が同じ場合、処理がステップＳ９７に進められる。後者の場合、ユーザ端末から認証サーバ１００に対する２回目以降のログインとなり、ログインが許可される。

［ステップＳ９２］このケースは、ユーザ端末が変更されており、ログイン要求元は変更後のユーザ端末であって、変更後のユーザ端末からの初回ログインとなる。この場合、ＦＩＤＯサーバ１２０は次に、ステップＳ８２で受信したアカウント名に対応する認証器情報をユーザデータベース１１１から取得し、ステップＳ８４でレスポンスデータから復元された認証器情報と比較する。これらの認証器情報が同じ場合、処理がステップＳ９６に進められる。この場合、端末変更前後で生体認証の認証強度が変化しないため、ログインが許可される。一方、比較された認証器情報が互いに異なる場合、処理がステップＳ９３に進められる。

［ステップＳ９３］ＦＩＤＯサーバ１２０は、レスポンスデータから復元された認証器情報（変更後のユーザ端末についての認証器情報）をメタデータサーバ４００に送信して、対応する生体認証器の構成情報の送信を要求する。要求された構成情報がメタデータサーバ４００から送信されると、ＦＩＤＯサーバ１２０はこれを受信する。

［ステップＳ９４］ＦＩＤＯサーバ１２０は、受信した構成情報に基づき、ユーザ端末の生体認証器の認証強度が、認証ポリシー１１２に記述された条件を満たすかを判定する。この判定では、例えば、図１５で説明した条件１〜４の少なくとも１つが用いられればよい。条件１〜４のうち複数の条件が用いられる場合には、すべての条件を満たす場合に認証強度が条件を満たすと判定されればよい。認証強度が条件を満たす場合、処理がステップＳ９６に進められ、認証強度が条件を満たさない場合、処理がステップＳ９５に進められる。

［ステップＳ９５］このケースでは、生体認証器の認証強度が認証サーバ１００で定められる基準を満たしておらず、生体認証の方法が不適切である「認証方法エラー」となる。ＦＩＤＯサーバ１２０は、認証に失敗したことをユーザ端末に通知するとともに、例えば、生体認証の認証強度が不適切であることを示す文字情報や、生体認証の方法を変えるように促す文字情報を送信して、ユーザ端末に表示させる。

［ステップＳ９６］ＦＩＤＯサーバ１２０は、現在時刻を取得する。ＦＩＤＯサーバ１２０は、ユーザデータベース１１１においてステップＳ８１で受信したアカウント名に対応付けられた鍵保存時刻を、取得した現在時刻によって更新する。

［ステップＳ９７］ＦＩＤＯサーバ１２０は、ログインに成功したことをユーザ端末に通知する。
なお、上記の第２の実施の形態では、認証サーバ１００側がユーザ端末の認証器情報を保持し、図１９のステップＳ９２で、保持している認証器情報と受信した認証器情報とが比較される。しかし、他の例として、認証サーバ１００側がユーザ端末の認証器情報を保持しないようにしてもよい。この場合、ステップＳ９２の処理がスキップされる。ただし、認証サーバ１００側がユーザ端末の認証器情報を保持してステップＳ９２が実行されることで、端末変更の前後で生体認証器が変化しない場合には、ステップＳ９２でＹｅｓと判定され、ステップＳ９３でのメタデータサーバ４００との通信が不要になる。このため、ログイン時の処理を効率化できる。

また、図１９では、ステップＳ９１の判定により、端末変更後の初回ログインの場合のみ、ステップＳ９２〜Ｓ９４での認証強度の判定が実行される。しかし、他の例として、ステップＳ９１の判定処理を実行せず、常時ステップＳ９２〜Ｓ９４での認証強度の判定が実行されてもよい。この場合、認証強度の判定処理を効率化するために、認証サーバ１００側がユーザ端末の認証器情報を保持してステップＳ９２が実行される方が望ましい。

また、上記の第２の実施の形態では、秘密鍵をバックアップする際の暗号化方法としてファジーコミットメントが用いられた。これにより、認証サーバ１００に対するログイン時に加えて、秘密鍵のバックアップ時や復元時においても、ユーザがパスワードを入力する必要がなくなり、ユーザの操作性が向上する。ただし、これはあくまで一例であり、秘密鍵をバックアップする際の暗号化方法として他の方法が用いられてもよい。例えば、パスワード入力によって秘密鍵が暗号化されてもよい。

秘密鍵の暗号化方法としてファジーコミットメントが用いられる場合、生体認証の方式（用いられる生体情報の種類）はユーザ端末の変更前後で同じである、という制限がかかる。しかし、認証強度が低下しなければ、ユーザ端末の変更前後で生体認証の方式が異なってもよい。例えば、変更前のユーザ端末では指紋認証が行われ、変更後のユーザ端末では静脈認証が行われてもよい。したがって、例えば、ユーザ端末の変更前後で生体認証の方式が異なることが許容される場合には、秘密鍵をバックアップする際の暗号化方法として、生体認証の方式に依存しない方法が用いられればよい。

また、図８〜図１９の説明では、生体認証器の識別子は、生体センサと生体認証処理部とを用いて実現される生体認証機能を識別する情報とされていたが、他の例として、生体センサを識別する情報であってもよい。

なお、上記の各実施の形態に示した装置（例えば、認証サーバ１，１００、端末装置２，３、ユーザ端末２００，２００ａ、バックアップサーバ４，３００、メタデータサーバ４００）の処理機能は、コンピュータによって実現することができる。その場合、各装置が有すべき機能の処理内容を記述したプログラムが提供され、そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、磁気テープなどがある。光ディスクには、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク（Blu-ray Disc：ＢＤ、登録商標）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムまたはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムにしたがった処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムにしたがった処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムにしたがった処理を実行することもできる。

１ 認証サーバ
２，３ 端末装置
３ａ 記憶部
４ バックアップサーバ
１１ 秘密鍵
１２ 公開鍵
２１，２２ 認証器情報
Ｓ１ａ，Ｓ１ｂ，Ｓ２，Ｓ３ａ，Ｓ３ｂ，Ｓ４ａ，Ｓ４ｂ ステップ

Claims (10)

1. バックアップサーバと端末装置とを有する情報処理システムであって、
   前記バックアップサーバは、認証サーバが提供するサービスを利用するためにユーザの生体認証を実行する他の端末装置から、前記サービスを利用するための前記ユーザの秘密鍵と、前記他の端末装置における生体認証の認証強度を識別可能にする第１の認証器情報とを受信して記憶し、
   前記端末装置は、
   前記秘密鍵と前記第１の認証器情報とを前記バックアップサーバから受信し、
   前記端末装置における生体認証の認証強度を識別可能にする第２の認証器情報と、受信した前記第１の認証器情報との比較結果に基づき、前記端末装置での認証強度が前記他の端末装置での認証強度以上である場合に、受信した前記秘密鍵を保存して使用可能な状態にし、
   前記サービスを利用する際に、前記ユーザの生体認証を実行し、認証に成功すると、前記認証サーバが前記ユーザを認証するための認証用データを、保存された前記秘密鍵で暗号化した状態で前記認証サーバに送信する、
   情報処理システム。
2. 前記バックアップサーバは、前記他の端末装置における生体認証の際に取得された第１の生体情報を用いて暗号化された状態の前記秘密鍵を、前記他の端末装置から受信して記憶し、
   前記端末装置は、
   前記第１の認証器情報と暗号化された前記秘密鍵とを前記バックアップサーバから受信するとともに、前記ユーザの生体認証を実行し、
   認証に成功すると、当該生体認証の際に取得された第２の生体情報を用いて、暗号化された前記秘密鍵を復号し、
   復号に成功すると、前記第１の認証器情報と前記第２の認証器情報との比較処理を実行する、
   請求項１記載の情報処理システム。
3. 前記情報処理システムは前記認証サーバをさらに有し、
   前記認証サーバは、
   前記ユーザの公開鍵を記憶し、
   前記秘密鍵で暗号化された前記認証用データを受信すると、前記認証用データを前記公開鍵で復号することで前記ユーザの認証処理を実行する、
   請求項１または２記載の情報処理システム。
4. 前記端末装置は、暗号化された前記認証用データとともに前記第２の認証器情報を前記認証サーバに送信し、
   前記認証サーバは、
   前記第２の認証器情報に基づいて、前記端末装置での認証強度が所定の条件を満たすかを判定し、
   前記公開鍵を用いた復号による前記ユーザの認証処理に成功し、かつ、当該認証強度が前記所定の条件を満たす場合には、前記ユーザによる前記サービスの利用を許可し、
   当該認証強度が前記所定の条件を満たさない場合には、前記ユーザによる前記サービスの利用を不許可にする、
   請求項３記載の情報処理システム。
5. 前記端末装置は、前記バックアップサーバから受信した前記秘密鍵を保存した時刻を示す第２の時刻情報を、暗号化された前記認証用データとともに前記認証サーバに送信し、
   前記認証サーバは、
   前記公開鍵とともに、前記秘密鍵が前記他の認証サーバに保存された時刻を示す第１の時刻情報を記憶し、
   暗号化された前記認証用データと前記第２の時刻情報とを受信すると、受信した前記第２の時刻情報と記憶された前記第１の時刻情報とを比較し、
   前記公開鍵を用いた復号による前記ユーザの認証処理に成功し、かつ、当該認証強度が前記所定の条件を満たし、かつ、前記第２の時刻情報が前記第１の時刻情報より後の時刻を示す場合に、前記ユーザによる前記サービスの利用を許可するとともに、記憶された前記第１の時刻情報を前記第２の時刻情報に更新する、
   請求項３記載の情報処理システム。
6. 前記認証サーバは、
   記憶された前記第１の時刻情報が前記第２の時刻情報に更新された後に、前記サービスを利用するために前記他の端末装置から送信された前記第１の時刻情報を受信した場合、受信した前記第１の時刻情報と記憶された前記第２の時刻情報とを比較し、
   受信した前記第１の時刻情報が記憶された前記第２の時刻情報より前の時刻を示す場合に、前記他の端末装置が記憶している前記秘密鍵を消去するように前記他の端末装置に要求する、
   請求項５記載の情報処理システム。
7. コンピュータに、
   認証サーバが提供するサービスを利用するためにユーザの生体認証を実行する他の端末装置から出力された、前記サービスを利用するための前記ユーザの秘密鍵と、前記他の端末装置における生体認証の認証強度を識別可能にする第１の認証器情報とを取得し、
   前記コンピュータにおける生体認証の認証強度を識別可能にする第２の認証器情報と、取得した前記第１の認証器情報との比較結果に基づき、前記コンピュータでの認証強度が前記他の端末装置での認証強度以上である場合に、受信した前記秘密鍵を保存して使用可能な状態にし、
   前記サービスを利用する際に、前記ユーザの生体認証を実行し、認証に成功すると、前記認証サーバが前記ユーザを認証するための認証用データを、保存された前記秘密鍵で暗号化した状態で前記認証サーバに送信する、
   処理を実行させる情報処理プログラム。
8. コンピュータに、
   ユーザを認証するための認証用データを端末装置に送信して、前記ユーザの生体認証の実行を要求し、
   前記生体認証に成功した場合に前記端末装置から送信される、前記ユーザの秘密鍵によって暗号化された前記認証用データと、前記端末装置における前記生体認証の認証強度を識別可能にする認証器情報とを受信し、
   暗号化された前記認証用データを前記ユーザの公開鍵で復号することで前記ユーザの認証処理を実行するとともに、前記認証器情報に基づいて、前記生体認証の認証強度が所定の条件を満たすかを判定し、
   前記公開鍵を用いた復号による前記ユーザの認証処理に成功し、かつ、当該認証強度が前記所定の条件を満たす場合には、前記ユーザによる所定のサービスの利用を許可し、
   当該認証強度が前記所定の条件を満たさない場合には、前記ユーザによる前記サービスの利用を不許可にする、
   処理を実行させる情報処理プログラム。
9. コンピュータが、
   認証サーバが提供するサービスを利用するためにユーザの生体認証を実行する他の端末装置から出力された、前記サービスを利用するための前記ユーザの秘密鍵と、前記他の端末装置における生体認証の認証強度を識別可能にする第１の認証器情報とを取得し、
   前記コンピュータにおける生体認証の認証強度を識別可能にする第２の認証器情報と、取得した前記第１の認証器情報との比較結果に基づき、前記コンピュータでの認証強度が前記他の端末装置での認証強度以上である場合に、受信した前記秘密鍵を保存して使用可能な状態にし、
   前記サービスを利用する際に、前記ユーザの生体認証を実行し、認証に成功すると、前記認証サーバが前記ユーザを認証するための認証用データを、保存された前記秘密鍵で暗号化した状態で前記認証サーバに送信する、
   情報処理方法。
10. コンピュータが、
    ユーザを認証するための認証用データを端末装置に送信して、前記ユーザの生体認証の実行を要求し、
    前記生体認証に成功した場合に前記端末装置から送信される、前記ユーザの秘密鍵によって暗号化された前記認証用データと、前記端末装置における前記生体認証の認証強度を識別可能にする認証器情報とを受信し、
    暗号化された前記認証用データを前記ユーザの公開鍵で復号することで前記ユーザの認証処理を実行するとともに、前記認証器情報に基づいて、前記生体認証の認証強度が所定の条件を満たすかを判定し、
    前記公開鍵を用いた復号による前記ユーザの認証処理に成功し、かつ、当該認証強度が前記所定の条件を満たす場合には、前記ユーザによる所定のサービスの利用を許可し、
    当該認証強度が前記所定の条件を満たさない場合には、前記ユーザによる前記サービスの利用を不許可にする、
    情報処理方法。

Images