JP2017059153A - リカバリシステム、サーバ装置、端末装置、リカバリ方法及びリカバリプログラム - Google Patents

Abstract

【課題】利便性に優れた鍵リカバリ方法をユーザに提供する。【解決手段】リカバリシステム１は、ユーザ端末１０１、代理装置５０及び認証サーバ１００を備える。ユーザ端末は、ユーザＵ０１の認証処理に対応する、ペアとなる秘密鍵Ｋ１０と公開鍵Ｋ１１を発行しＳ３、ユーザ端末１０が生成する署名の検証に用いられる公開鍵Ｋ１１を認証サーバへ送信するＳ４とともに、ユーザＵ０１の本人性を認証する代理装置へユーザＵ０１の認証に用いるリカバリ用の認証情報を送信するＳ５。代理装置は、代理装置による認証の結果に署名するための鍵である秘密鍵Ｋ５０と、ペアとなる公開鍵Ｋ５１を発行するＳ６とともに、秘密鍵Ｋ５０を用いて生成された署名を検証するために用いられる公開鍵Ｋ５１を、署名を検証する認証サーバへ送信するＳ７。認証サーバは、端末の公開鍵Ｋ１１とリカバリ用の公開鍵Ｋ５１とを対応付けて登録するＳ８。【選択図】図１Ａ

Description

本発明は、リカバリシステム、サーバ装置、端末装置、リカバリ方法及びリカバリプログラムに関する。

近年、通信ネットワークの普及が進み、ネットワークを介したサービスが盛んに提供されている。例えば、ユーザは、通信端末装置を用いて、ネットワークを介して提供されるサービスにログインし、サービスを利用する。この場合、ユーザは、サービスの利用にあたって本人認証が求められる。例えば、サービスにログインする際に、電子署名や暗号鍵等を用いて本人認証を行うことが一般的に行われている。

ここで、ネットワークにおける本人認証の技術として、正規のユーザに予め発行された鍵情報を安全に保管するための鍵リカバリ方法に係る技術が知られている（例えば、特許文献１）。

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

しかしながら、上記の従来技術では、利便性に優れたリカバリをユーザに提供することは難しい。例えば、ユーザにとっては、何らかの理由で所定のサービスに対する本人認証手段が制限された場合に、できる限り迅速に、かつ、安全性の高い手法で本人認証手段がリカバリされることが望ましい。

本願は、上記に鑑みてなされたものであって、利便性に優れたリカバリをユーザに提供することができるリカバリシステム、サーバ装置、端末装置、リカバリ方法及びリカバリプログラムを提供することを目的とする。

本願に係るリカバリシステムは、第１の端末装置と、第２の端末装置と、認証サーバとを含み、前記第１の端末装置は、前記第１の端末装置が生成する署名の検証に用いられる第１の鍵を前記認証サーバに送信するとともに、ユーザの本人性を認証する所定の認証装置に当該ユーザの認証に用いられる情報を送信する送信部と、前記登録部は、前記認証装置による認証の結果への署名の生成に用いられる第２の鍵を、当該認証装置内に登録させるとともに、前記第２の鍵を用いて生成された署名を検証するために用いられる第３の鍵を、当該署名を検証する認証サーバ内に登録させる登録部と、を備え、前記認証サーバは、前記第１の鍵と前記第３の鍵とを対応付けて記憶する記憶部を備え、前記第２の端末装置は、前記認証装置に前記ユーザの認証を実行させ、当該認証の結果を前記認証サーバに送信させる認証制御部と、前記認証制御部によって送信された認証の結果に付された署名が、前記３の鍵を用いて前記認証サーバによって検証される場合に、前記第１の鍵に関連する情報のリカバリを要求する要求部と、を備えたことを特徴とする。

実施形態の一態様によれば、利便性に優れたリカバリをユーザに提供することができるという効果を奏する。

図１Ａは、実施形態に係るリカバリ処理の一例を示す図（１）である。 図１Ｂは、実施形態に係るリカバリ処理の一例を示す図（２）である。 図２は、実施形態に係る認証方式を説明するシーケンス図（１）である。 図３は、実施形態に係る認証方式を説明するシーケンス図（２）である。 図４は、実施形態に係るリカバリシステムの構成例を示す図である。 図５は、実施形態に係るユーザ端末の構成例を示す図である。 図６は、実施形態に係る認証器記憶部の一例を示す図である。 図７は、実施形態に係る代理認証器記憶部の一例を示す図である。 図８は、実施形態に係る代理装置の構成例を示す図である。 図９は、実施形態に係る認証情報記憶部の構成例を示す図である。 図１０は、実施形態に係る認証サーバの構成例を示す図である。 図１１は、実施形態に係る登録情報記憶部の一例を示す図である。 図１２は、実施形態に係るリカバリ情報記憶部の一例を示す図である。 図１３は、実施形態に係る処理手順を示すシーケンス図である。 図１４は、変形例に係るリカバリシステムの構成例を示す図である。 図１５は、ユーザ端末の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願に係るリカバリシステム、サーバ装置、端末装置、リカバリ方法及びリカバリプログラムを実施するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係るリカバリシステム、サーバ装置、端末装置、リカバリ方法及びリカバリプログラムが限定されるものではない。また、各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

〔１．リカバリ処理の一例〕
まず、図１Ａ及び図１Ｂを用いて、実施形態に係るリカバリ処理の一例について説明する。図１Ａ及び図１Ｂでは、本願に係る端末装置に対応するユーザ端末１０と、本願に係るサーバ装置に対応する認証サーバ１００と、代理装置５０とを含むリカバリシステム１によって、一度認証サーバ１００によって認証されたユーザＵ０１の認証に関する情報（例えば、所定のサービスを利用するためのアカウント情報など）をリカバリするリカバリ処理が行われる例を示す。これらの各種装置は、所定のネットワーク（例えば、インターネット）を介して、有線又は無線により通信可能に接続される。

図１Ａは、実施形態に係るリカバリ処理の一例を示す図（１）である。図１Ａの例において、ユーザ端末１０_１は、ユーザＵ０１によって利用される情報処理端末である。ユーザＵ０１は、ユーザ端末１０_１を用いて、ネットワークを介して提供されるサービス、例えば、ウェブサーバから提供されるサービスを利用する。図１Ａでは、ユーザ端末１０_１は、例えばスマートフォンである。以下における説明では、ユーザ端末１０_１をユーザＵ０１と表記する場合がある。すなわち、以下では、ユーザＵ０１をユーザ端末１０_１と読み替えることもできる。

代理装置５０は、ユーザ端末１０_１が行う所定の処理を代理する情報処理装置である。なお、代理装置５０は、ユーザ端末１０_１のように個人で扱われる端末装置であってもよいし、所定の管理者によって管理されるサーバ装置であってもよい。

認証サーバ１００は、ユーザ端末１０_１から送信される情報を取得し、取得した情報に基づいてユーザＵ０１の本人認証を行うサーバ装置である。認証サーバ１００が取得する情報とは、例えば生体認証器等を用いて、ユーザ端末１０_１を利用しているユーザがユーザＵ０１本人であることをユーザ端末１０_１側が証明したことを示す情報である。認証サーバ１００は、取得した情報を特定の認証手順で処理することにより、ユーザＵ０１本人であることを認証する。そして、認証サーバ１００は、ユーザ端末１０_１を利用しているユーザがユーザＵ０１であると認証したことを示す情報（以下、「認証済み情報」と表記する）を生成する。ユーザ端末１０_１は、認証サーバ１００によって生成された認証済み情報が各種サービス（ウェブサーバ等）に送信されることにより、各種サービスへのログインや、サービス毎に発行されるサービスＩＤの利用や、ネットワークを介した決済など、本人認証を要するサービスを利用することが可能となる。

（認証サーバ１００の認証方式について）
ここで、本願で実現されるリカバリ処理の説明に先立ち、認証サーバ１００が所定の情報処理端末（以下、「クライアント２０」と表記する）を利用するユーザの本人認証を行う方式について、図２及び図３を用いて説明する。

認証サーバ１００は、クライアント２０の認証において、予め発行される公開鍵と秘密鍵との照合によって情報の確実性を担保する、いわゆる公開鍵暗号方式を基礎とした認証方式を採用する。すなわち、認証サーバ１００は、クライアント２０が有する各認証器に対して発行される公開鍵と秘密鍵のペアに基づいて認証を行う。認証器とは、クライアント２０がローカルにおいて本人認証を行うための機能（あるいは、当該機能を有する装置）をいう。ローカルにおける認証とは、インターネット等の広域ネットワーク（外部ネットワーク）の接続を要しない状況で行われる認証をいい、例えば、クライアント２０内部に備えられた機能を用いて行われる認証をいう。認証器は、例えば、ユーザの生体情報など、ユーザ本人を認証することが可能な情報について、予め登録を受け付ける。そして、認証器は、認証の際には、ユーザから生体情報等の入力を受け付け、登録データと入力データとの照合結果に基づいて本人認証を行う。具体的には、認証器には、指紋認証器や、虹彩認証器や、声紋認証器等が含まれる。なお、認証器は、クライアント２０内部にインストールされたソフトウェアにより実現されてもよいし、クライアント２０とＬＡＮ（Local Area Network）で接続される範囲内に存在するハードウェアにより実現されてもよい。すなわち、認証器には、インターネット等の広域ネットワークを介さない、例えば、クライアント２０に備えられたインターフェイスに直接接続されることによりクライアント２０と協働するようなハードウェア等も含まれる。このように、認証器とは、クライアント２０側で機能する認証機能、あるいは、認証手段と読み替えることもできる。

まず、認証サーバ１００がクライアント２０を認証対象として登録する手順について説明する。図２は、実施形態に係る認証方式を説明するシーケンス図（１）である。図２では、認証処理に先立ち、認証サーバ１００が認証を行うクライアント２０に関する登録を行う処理の流れを示している。

クライアント２０は、認証サーバ１００にアクセスし、認証器の登録を要求する（ステップＳ２１）。認証サーバ１００は、クライアント２０から送信された要求に応答して、認証器による認証を要求する（ステップＳ２２）。

クライアント２０を利用するユーザは、認証サーバ１００への登録を要求した認証器を動作させ、ローカルにおいて認証器による認証を実行する（ステップＳ２３）。例えば、認証に利用する認証器として指紋認証器をユーザが選択した場合には、ユーザは、所定の箇所に指をかざすことにより、認証処理を行う。認証器は、認証器内の登録データとユーザから入力されたデータとの照合を行う。そして、認証器は、ユーザを正規のユーザと確認できた場合、当該認証処理に対応する公開鍵と秘密鍵とを発行する（ステップＳ２４）。そして、クライアント２０は、発行された秘密鍵をクライアント２０内部に記憶するとともに、秘密鍵とペアになる公開鍵を認証サーバ１００に送信する（ステップＳ２５）。認証サーバ１００は、クライアント２０から公開鍵を受け取り、当該認証器と対応付けて公開鍵を記憶する（ステップＳ２６）。クライアント２０内部の秘密鍵は、原則としてアクセスを受け付けない領域に記憶され、登録を受けた認証器によるローカルでの認証が成功しない限り、アクセスが許可されないものとする。これにより、クライアント２０が備える認証器について、認証サーバ１００への登録が完了する。

続いて、図３について説明する。図３は、実施形態に係る認証方式を説明するシーケンス図（２）である。図３では、クライアント２０がサービスを利用する際など、実際に認証サーバ１００に認証処理を要求する場面における処理の流れを示している。

クライアント２０は、認証サーバ１００に、所定のアクセス制限付きサービスへのアクセスを要求する（ステップＳ３１）。なお、かかる要求は、例えば、ネットワークを介してサービスを行うウェブサーバ等を経由して送信される場合がある。すなわち、ユーザは、サービスを利用する過程において、接続先のウェブサーバから本人認証を求められる場合がある。この場合、ユーザが本人認証を行う旨を表明すると、かかる情報は、クライアント２０又は接続先のウェブサーバから認証サーバ１００に送信される。

要求を受け付けた認証サーバ１００は、クライアント２０に対して、予め登録された認証器による認証を要求する（ステップＳ３２）。要求を受け付けたクライアント２０のユーザは、予め登録された認証器によるローカルな認証を実行する（ステップＳ３３）。

認証器による認証が成功した場合、すなわち、ローカルにおいて本人認証が確認された場合、ユーザは、クライアント２０内部に記憶されている秘密鍵へのアクセスが可能となる。そして、クライアント２０は、認証器によって正規のユーザと認められたユーザしかアクセスすることのできない秘密鍵を用いて、認証の結果に関する情報に対する署名（所定のハッシュ値）を生成する。言い換えれば、クライアント２０は、予め発行されていた秘密鍵を用いて署名付き情報を生成する（ステップＳ３４）。このようにして生成される情報を、本願では、「認証結果情報」と表記する。

続いて、クライアント２０は、認証サーバ１００との間で規定される特定の認証手順（詳細は後述する）を用いて、生成した認証結果情報を送信する（ステップＳ３５）。認証サーバ１００は、秘密鍵とペアとなる公開鍵を用いて、送信された認証結果情報に付された署名を検証する（ステップＳ３６）。すなわち、認証サーバ１００は、認証結果情報に改竄がないこと、言い換えれば、適切な秘密鍵によって認証結果情報が生成されているか否かを検証する。このように、認証サーバ１００は、認証対象である認証器が適切な秘密鍵を保有していることを確認する。この確認ができた場合、認証サーバ１００は、認証結果情報に基づいてクライアント２０を利用するユーザが正規のユーザであることを認証する。そして、認証サーバ１００は、自身が認証したことを示し、ステップＳ３１においてアクセス要求したサービスの情報が含まれる、認証がなされた旨の情報（認証済み情報）をクライアント２０に送信する（ステップＳ３７）。認証がなされた旨の情報とは、例えば、認証クッキーである。

このように、上記認証方式によれば、クライアント２０は、一般的な認証で用いられることの多いパスワードやサービスＩＤなど、認証に用いる情報そのものをネットワークに送信しなくて済む。すなわち、クライアント２０から送信される情報はローカルでの認証結果を示した情報に過ぎず、第三者がクライアント２０から送信された情報を傍受したとしても、第三者は傍受した情報を利用することができない。このため、認証サーバ１００が採用する認証方式は、安全性の高い方式であるといえる。また、認証サーバ１００が採用する認証方式によれば、ユーザは、パスワードを記憶することを要しないため、ユーザの負担を軽減させることができる。

さらに、上記のように、認証サーバ１００は、クライアント２０から送信される認証結果情報の処理において、クライアント２０との間で規定される特定の認証手順を用いる。特定の認証手順とは、認証サーバ１００とクライアント２０との間で規定される認証手順であり、通信に関するプロトコルと読み替えることもできる。例えば、認証サーバ１００は、ＵＡＦ（Universal Authentication Framework）や、Ｕ２Ｆ（Universal Second Factor)といったプロトコルを用いる。これにより、認証サーバ１００とクライアント２０との通信は、より高い安全性が確保される。

図２及び図３を用いて説明してきたように、認証サーバ１００とクライアント２０の認証器との間で、特定のプロトコルを用いた公開鍵暗号方式を基礎とした認証方式による通信が確立する場合、クライアント２０は、パスワード等の認証情報そのものをネットワーク上に送信することなく、本人認証を認証サーバ１００に対して行うことができる。

しかしながら、上述した方式においては、リカバリ処理が困難になる可能性がある。通常、パスワード等を用いた認証方式であれば、パスワードの正解データは認証を行うサーバ側に保持される。このため、ユーザがパスワードを忘れた場合であっても、サーバ側の管理者等に連絡することで、認証に関する情報（例えば、所定のサービスのアカウント情報など）を復帰させることが可能である。ところが、上述した認証方式では、認証に用いる正解データ自体がクライアント２０内部に保持される。また、認証の結果に対して署名を行う秘密鍵も、クライアント２０内部に保持される。このため、例えば、ユーザがクライアント２０を紛失したり、盗難にあったりした場合には、不正な認証は防止できるものの、ユーザは、認証に関する情報をリカバリすることが困難である。これは、認証サーバ１００とのやりとりを行うための秘密鍵がなければ、ユーザは、認証サーバ１００による認証を受けられないからである。

そこで、本願に係る端末装置に対応するユーザ端末１０は、上述した認証方式に対応し、かつ、不測の事態が生じた場合には、認証に関する情報のリカバリを行うことができるような処理を行う。以下、図１Ａ及び図１Ｂの説明に戻り、本願に係るリカバリ処理の一例を流れに沿って説明する。

（リカバリ処理の流れ）
図１Ａに示す例では、ユーザＵ０１は、ユーザ端末１０_１を用いて所定のサービスを利用するため、認証サーバ１００による認証処理を所望するものとする。上記説明したように、認証サーバ１００による認証を受けるにあたり、ユーザＵ０１は、ローカルで本人認証を行うことが可能な認証器を認証サーバ１００に登録することを要する。ここでは、ユーザＵ０１は、認証サーバ１００に対して、ユーザ端末１０_１が備える指紋認証器を登録するものとする。なお、図１Ａに示す例では、指紋認証器は、ユーザ端末１０_１内部で実現される認証機能であり、例えば、ユーザ端末１０_１にインストールされたアプリケーション（アプリ）等により実現される。

図１Ａに示す例において、ユーザＵ０１は、認証サーバ１００に対して認証器の登録を要求する（ステップＳ０１）。認証サーバ１００は、認証器の登録の要求に応答して、認証器による本人認証をユーザ端末１０_１に要求する（ステップＳ０２）。

ユーザＵ０１は、ユーザ端末１０_１が備える指紋認証器を用いて、ユーザＵ０１を認証する。そして、ユーザ端末１０_１は、ユーザＵ０１の認証処理に対応する鍵であって、ペアとなる秘密鍵Ｋ１０と公開鍵Ｋ１１を発行する（ステップＳ０３）。そして、ユーザ端末１０_１は、秘密鍵Ｋ１０を保持するとともに、公開鍵Ｋ１１を認証サーバ１００に送信する（ステップＳ０４）。認証サーバ１００は、公開鍵Ｋ１１を所定の記憶領域に登録する。

今後、ユーザ端末１０_１が有する指紋認証器によるユーザＵ０１の認証処理が行われ、認証結果情報が認証サーバ１００に送信された場合には、認証サーバ１００は、公開鍵Ｋ１１を用いて認証結果情報の署名を検証する。すなわち、認証サーバ１００は、送信された認証結果情報が秘密鍵Ｋ１０を用いて署名されたことを確認する。これにより、認証サーバ１００は、ユーザ端末１０_１を利用するユーザがユーザＵ０１であることを認証する。

上記のように、ユーザＵ０１は、ユーザ端末１０_１が備える指紋認証器を登録することで、認証サーバ１００から認証を受けることができるようになる。そして、ユーザＵ０１は、認証サーバ１００への指紋認証器の登録と合わせて、認証処理のリカバリのため、代理装置５０に対して以下の処理を行う。

ユーザＵ０１は、代理装置５０を認証器として認証サーバ１００に取り扱わせるための処理を行う。言い換えれば、ユーザＵ０１は、認証サーバ１００へ登録を行った指紋認証器の代替として、代理装置５０が認証器として振る舞うことのできるような登録を行う。

まず、ユーザＵ０１は、代理装置５０にリカバリ用の認証情報を送信する（ステップＳ０５）。リカバリ用の認証情報とは、ユーザＵ０１の本人性を認証するために用いられる情報である。リカバリ用の認証情報は、ユーザＵ０１を識別することのできる識別情報であれば、どのような情報であってもよい。例えば、認証情報は、ユーザＵ０１の生体情報であってもよいし、ユーザＵ０１が通信回線業者と契約したＳＩＭカード（Subscriber Identity Module Card）の識別情報や、ユーザＵ０１が所有する任意のカード番号などであってもよい。ここでは、ユーザＵ０１は、リカバリ用の認証情報としてユーザ端末１０_１のＳＩＭカードを識別する情報を選択したものとする。

代理装置５０は、ユーザ端末１０_１からリカバリ用の認証情報を受け付ける。そして、代理装置５０は、受け付けたリカバリ用の認証情報をユーザＵ０１の認証のための正解データとして、ユーザＵ０１を認証する認証器として機能する。言い換えれば、代理装置５０は、認証サーバ１００からみた場合に、ユーザＵ０１をローカル側で認証する認証器であるように振る舞う。

代理装置５０は、ステップＳ０３と同様、ユーザＵ０１をリカバリ用の認証情報によって認証した認証の結果に署名するための鍵である秘密鍵Ｋ５０と、秘密鍵Ｋ５０とペアとなる公開鍵Ｋ５１とを発行する（ステップＳ０６）。

そして、代理装置５０は、認証サーバ１００に対して発行した公開鍵Ｋ５１を送信する（ステップＳ０７）。なお、認証サーバ１００に対して代理装置５０を認証器として登録する旨の要求は、ユーザ端末１０_１によって送信されてもよいし、代理装置５０から送信されてもよい。

そして、認証サーバ１００は、ユーザ端末１０_１から送信された公開鍵Ｋ１１と、代理装置５０から送信された公開鍵Ｋ５１とを、同一の認証対象であるユーザＵ０１と対応付けて登録する（ステップＳ０８）。これにより、ユーザＵ０１を認証する認証器に関して、認証サーバ１００への登録処理が完了する。

次に、図１Ｂの処理の流れについて説明する。図１Ｂは、実施形態に係るリカバリ処理の一例を示す図（２）である。図１Ｂは、ユーザ端末１０_１とは異なる端末であって、ユーザＵ０１から利用されるユーザ端末１０_２が、認証サーバ１００に対して認証処理を要求する場合の処理について示している。例えば、図１Ｂが示す状況とは、ユーザＵ０１が古くなったユーザ端末１０_１を処分し、新たにユーザ端末１０_２を購入した状況などである。この場合、秘密鍵Ｋ１０はユーザ端末１０_１内部に保持されているため、ユーザ端末１０_２は、秘密鍵Ｋ１０を取得することができない。すなわち、ユーザ端末１０_２は、認証サーバ１００から認証を受けるための手段を有しないことになる。

例えば、ユーザＵ０１は、所定のサービスのログインにはユーザ端末１０_１が備える指紋認証器によって認証を行っていたものとする。この場合、ユーザＵ０１は、秘密鍵Ｋ１０を失っていることから、ユーザ端末１０_２からでは、認証サーバ１００に対する認証処理を行うことができない。このため、ユーザＵ０１は、所定のサービスで利用していた個人のアカウント等、認証を行わなければ利用することのできない情報等をリカバリすることを所望する。言い換えれば、ユーザＵ０１は、認証サーバ１００によってユーザＵ０１が認証されることにより得られる権限のリカバリを所望する。そこで、ユーザＵ０１は、認証サーバ１００に対して、認証に関する情報のリカバリを要求する（ステップＳ１１）。

認証サーバ１００は、リカバリの要求に応答して、ユーザＵ０１に対して本人認証を要求する（ステップＳ１２）。すなわち、認証サーバ１００は、ユーザＵ０１の認証に関する情報のリカバリに際して、ユーザＵ０１の本人性を証明する情報を要求する。

そこで、ユーザＵ０１は、ユーザ端末１０_１が代理装置５０に登録しておいた認証情報を、ユーザ端末１０_２から送信する（ステップＳ１３）。例えば、ユーザＵ０１は、ユーザ端末１０_１からユーザ端末１０_２へ継承されたＳＩＭカードの識別情報等を代理装置５０に送信する。

代理装置５０は、ユーザ端末１０_２から送信された情報に基づいて、ユーザＵ０１を認証する（ステップＳ１４）。そして、代理装置５０は、認証の結果に対して秘密鍵Ｋ５０を用いて署名を付すことで、認証結果情報を生成する。代理装置５０は、生成した認証結果情報を認証サーバ１００に送信する（ステップＳ１５）。

認証サーバ１００は、代理装置５０から送信された認証結果情報を受信する。そして、認証サーバ１００は、秘密鍵Ｋ５０に対応する公開鍵Ｋ５１を用いて、認証結果情報に付された署名を検証する。そして、認証サーバ１００は、署名に改竄がないこと、すなわち、代理装置５０によってユーザＵ０１が間違いなく認証されたことを確認する。

そして、認証サーバ１００は、公開鍵Ｋ５１によって検証処理を行った場合、公開鍵Ｋ５１と対応付けられている公開鍵Ｋ１１に基づいて、公開鍵Ｋ１１を送信したユーザ端末１０_２側のユーザＵ０１を特定する（ステップＳ１６）。この特定により、認証サーバ１００は、ユーザ端末１０_２に対して要求した本人認証が確認できたものとして取り扱う。そして、認証サーバ１００は、公開鍵Ｋ１１によって検証が行われていた情報、すなわち、ユーザ端末１０_１によって認証が行われていた認証に関する情報をリカバリする。認証サーバ１００は、リカバリされた旨をユーザ端末１０_２に送信する（ステップＳ１７）。なお、認証サーバ１００は、ユーザＵ０１に関する情報をリカバリした後、今後ユーザ端末１０_２が行う認証に関して、ユーザ端末１０_２から新たな認証器の登録を受け付けるようにしてもよい。すなわち、認証サーバ１００は、ユーザ端末１０_１により生成された署名が公開鍵Ｋ１１で検証された場合、言い換えれば、認証サーバ１００にユーザＵ０１が認証された場合に、ユーザＵ０１に認められていた権限をユーザ端末１０_２に対してリカバリし、リカバリした権限を、新たに登録する認証器に委譲するようにしてもよい。これは、リカバリシステム１がユーザＵ０１に関する情報（ユーザＵ０１のアカウント情報や、サービス毎のユーザＩＤや、ユーザＵ０１がサービスに設定しておいたパスワード情報などを含む）をリカバリさせるとともに、新たな認証器で再発行される鍵に対して、かかる情報を対応付けることにより行われてもよい。

このように、リカバリシステム１が行う処理において、ユーザ端末１０_１は、代理装置５０による認証の結果に対する署名の生成に用いられる秘密鍵Ｋ５０を代理装置５０に登録させる。また、ユーザ端末１０_１は、秘密鍵Ｋ５０を用いて生成された署名を検証するために用いられる公開鍵Ｋ５１を、当該署名を検証する認証サーバ１００に登録させる。そして、ユーザ端末１０_２は、代理装置５０がユーザＵ０１を認証するために用いる情報である認証情報を代理装置５０に送信し、ユーザＵ０１を認証させる。そして、ユーザ端末１０_２は、送信した認証情報に基づいて生成された署名が、公開鍵Ｋ５１を用いて認証サーバ１００によって検証された場合に、予め認証サーバ１００に登録されていた公開鍵Ｋ１１に対応付けられている情報のリカバリを要求する。

すなわち、リカバリシステム１によれば、予め登録される公開鍵Ｋ１１と、リカバリ用の公開鍵Ｋ５１とを対応付けて記憶させる。公開鍵Ｋ１１は、認証サーバ１００による特定の認証手順を経て登録される認証器により発行される鍵であるから、かかる鍵はユーザを認証する手段として信頼される。そして、公開鍵Ｋ５１は、公開鍵Ｋ１１を発行した端末から発行を要求されることから、公開鍵Ｋ１１と同様の信頼性があるものといえる。このため、認証サーバ１００は、いずれかの公開鍵で検証できる署名を発行することが可能であれば、署名を発行した認証器（端末）を信頼し、その認証器によって認証されたユーザを信頼できる。このように、認証サーバ１００は、信頼されたユーザからの要求に基づき、情報をリカバリすることができる。また、端末を扱うユーザは、事前にリカバリ用の認証器を登録しておくことにより、端末を買い替えた場合や、紛失した場合など不測の事態が生じたとしても、新たな端末によって以前の認証に関する情報を迅速にリカバリすることができる。このように、リカバリシステム１によれば、安全性を確保するとともに、利便性に優れたリカバリをユーザに提供することができる。

なお、図１Ａ及び図１Ｂの例では、ユーザＵ０１は、リカバリ用の認証情報として、ＳＩＭカードの識別情報を送信する例を示した。この場合、ユーザＵ０１は、より安全性を高めるために、多要素認証を経ることを要する認証情報を送信するようにしてもよい。例えば、ユーザＵ０１は、ＳＩＭカードの識別情報とともにパスワードを設定することや、ハードウェアキーをユーザ端末１０_２に挿入しなければ代理装置５０にアクセスすることのできない設定などを適宜行ってもよい。

〔２．リカバリシステムの構成〕
次に、図４を用いて、リカバリシステム１の構成について説明する。図４は、実施形態に係るリカバリシステム１の構成例を示す図である。図４に例示するように、実施形態に係るリカバリシステム１には、ユーザ端末１０_１と、ユーザ端末１０_２と、代理装置５０と、認証サーバ１００とが含まれる。これらの各種装置は、ネットワークＮを介して、有線又は無線により通信可能に接続される。なお、図４に示したリカバリシステム１に含まれる各装置は、図示した数に限られない。

ユーザ端末１０_１及び１０_２は、例えば、デスクトップ型ＰＣ（Personal Computer）や、ノート型ＰＣや、タブレット端末や、スマートフォンを含む携帯電話機、ＰＤＡ（Personal Digital Assistant）等の情報処理端末である。なお、以下の説明において、ユーザ端末１０_１及び１０_２を区別する必要のない場合、「ユーザ端末１０」と表記する。

また、ユーザ端末１０には、眼鏡型や時計型の情報処理端末であるウェアラブルデバイス（Wearable device）も含まれてもよい。さらに、ユーザ端末１０には、情報処理機能を有する種々のスマート機器が含まれてもよい。例えば、ユーザ端末１０には、ＴＶ（Television）や冷蔵庫、掃除機などのスマート家電や、自動車などのスマートビークル（Smart vehicle）や、ドローン（Drone）、家庭用ロボットなどが含まれてもよい。

また、ユーザ端末１０は、認証器を備える。例えば、ユーザ端末１０がスマートフォンである場合、認証器は、スマートフォンにインストールされるアプリケーション等によって実現される。認証器は独立した装置であってもよく、例えば、ノート型ＰＣのＵＳＢインターフェイスに接続される指紋認証装置等であってもよい。

代理装置５０は、ユーザ端末１０の処理を代理する情報処理装置である。例えば、代理装置５０は、ユーザ端末１０を利用するユーザＵ０１を認証するための情報を受け付け、かかる情報に基づいてユーザＵ０１を認証する処理を代理する。言い換えれば、代理装置５０は、ユーザ端末１０が備える認証器の処理を代理する。なお、代理装置５０は、ユーザＵ０１が利用する端末のうち、ユーザ端末１０以外の端末であってもよい。

認証サーバ１００は、ユーザ端末１０を利用するユーザの本人認証を行うサーバ装置である。認証サーバ１００は、ユーザ端末１０又は代理装置５０から送信された認証結果情報を受信し、認証結果情報に署名した秘密鍵に対応する公開鍵を用いて署名を検証する。ユーザ端末１０を利用するユーザは、認証サーバ１００による署名の検証がなされた場合、認証サーバ１００から本人性を認証されたものとして取り扱われる。これにより、ユーザは、ウェブサーバ等が提供する制限付きサービス等を利用することが可能となる。

なお、認証サーバ１００は、各種ウェブページを提供するウェブサーバと通信を行ってもよい。ウェブサーバは、ユーザ端末１０からアクセスされた場合に、各種ウェブページを提供するサーバ装置である。ウェブサーバは、例えば、ニュースサイト、天気予報サイト、ショッピングサイト、ファイナンス（株価）サイト、路線検索サイト、地図提供サイト、旅行サイト、飲食店紹介サイト、ウェブブログなどに関する各種ウェブページを提供する。

ウェブサーバは、サービスの提供にあたり、ユーザの本人認証を要求する場合がある。この場合、認証サーバ１００は、ウェブサーバから、ユーザ端末１０を利用するユーザの本人認証の要求を受け付ける。例えば、ウェブサーバが決済サービスを提供する際に、ユーザ端末１０を利用しているユーザが間違いなくユーザＵ０１本人であると認証サーバ１００が認証しないときには、ウェブサーバは、ユーザ端末１０による決済サービスの実行を制限することができる。一方、ウェブサーバは、認証サーバ１００がユーザＵ０１を認証したことを示す情報をユーザ端末１０、あるいは、認証サーバ１００から受信した場合には、ユーザ端末１０を利用しているユーザがユーザＵ０１であると信頼する。この場合、ウェブサーバは、ユーザ端末１０による決済など、本人認証後でなければ許可しないような操作についても受け付けることができる。なお、認証サーバ１００は、上記で説明したようなウェブサーバの機能を兼ねてもよい。

〔３．ユーザ端末の構成〕
次に、図５を用いて、実施形態に係るユーザ端末１０の構成について説明する。図５は、実施形態に係るユーザ端末１０の構成例を示す図である。図５に示すように、ユーザ端末１０は、通信部１１と、入力部１２と、表示部１３と、検知部１４と、記憶部１５と、制御部１６とを有する。なお、ユーザ端末１０が有する各処理部の接続関係は、図５に示した接続関係に限られず、他の接続関係であってもよい。

（通信部１１について）
通信部１１は、ネットワークＮと有線又は無線で接続され、認証サーバ１００やウェブサーバ等との間で情報の送受信を行う。例えば、通信部１１は、ＮＩＣ（Network Interface Card）等によって実現される。

（入力部１２について）
入力部１２は、ユーザから各種操作を受け付ける入力装置である。例えば、入力部１２は、ユーザ端末１０に備えられた操作キー等によって実現される。また、入力部１２には、画像を撮影するための撮像装置（カメラ等）や、音声を集音する集音機器（マイク等）が含まれてもよい。

（表示部１３について）
表示部１３は、各種情報を表示するための表示装置である。例えば、表示部１３は、液晶ディスプレイ等によって実現される。なお、ユーザ端末１０にタッチパネルが採用される場合には、入力部１２の一部と表示部１３とは一体化される。

（検知部１４について）
検知部１４は、ユーザ端末１０に対する操作や、ユーザ端末１０における環境等を検知する。具体的には、検知部１４は、ユーザ端末１０に対するユーザＵ０１の操作や、ユーザ端末１０の所在する位置情報や、ユーザ端末１０と接続されている機器に関する情報等を検知する。検知部１４は、例えば、ユーザ端末１０に備えられる各種センサを利用して上記の情報を検知してもよい。

（記憶部１５について）
記憶部１５は、各種情報を記憶する。記憶部１５は、例えば、ＲＡＭ、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。記憶部１５は、認証器記憶部１５１と、代理認証器記憶部１５２とを有する。

（認証器記憶部１５１について）
認証器記憶部１５１は、認証器に関する情報を記憶する。図６は、実施形態に係る認証器記憶部１５１の一例を示す図である。図６に示した例では、認証器記憶部１５１は、「認証器ＩＤ」、「タイプ」、「認証ユーザ」、「秘密鍵」といった項目を有する。

「認証器ＩＤ」は、認証器を識別する識別情報を示す。なお、実施形態において、認証器ＩＤは、認証器の参照符号と一致するものとする。例えば、認証器ＩＤ「１６３Ａ」で示される認証器は、指紋認証器１６３Ａを示す。

「タイプ」は、認証器が行う認証方式のタイプを示す。例えば、タイプには、指紋や、虹彩や、声紋が含まれる。なお、認証器の認証方式は、上記に限られない。例えば、認証器は、ユーザの顔の画像データを用いて認証を行う顔認証器や、ユーザの心拍等をセンサによって検知する生体情報認証器であってもよい。また、認証器の認証方式は、生体情報を用いた認証方式に限られない。例えば、認証器は、ユーザＵ０１が所有する所定の物理キーをユーザ端末１０に接続することによって認証を行うハードウェア認証器であってもよいし、ユーザ端末１０に内蔵されるＳＩＭカード（Subscriber Identity Module Card）の内容を判定することで認証を行うＳＩＭカード認証器であってもよい。また、認証器は、パスワード等の所定の情報を入力することで認証を行う方式であってもよい。また、認証器は、ユーザ端末１０自体に与えられた識別番号（ＰＩＮ、Personal Identification Number）によって認証を行う方式であってもよい。

「認証ユーザ」は、認証器が認証するユーザを示す。「秘密鍵」は、認証器の認証の結果に対して署名を行い、認証結果情報を生成するための鍵を示す。秘密鍵及びペアとなる公開鍵は、認証サーバ１００への認証器の登録の際に発行される。そして、秘密鍵は、ユーザ端末１０内に保持される。公開鍵は、ユーザ端末１０によって認証サーバ１００へ送信される。また、秘密鍵は、対応する認証器によるユーザの認証が成功しない限りアクセスできない領域に保持される。

すなわち、図６では、認証器ＩＤ「１６３Ａ」で識別される認証器（指紋認証器１６３Ａ）は、認証のタイプが「指紋」であり、認証するユーザは「ユーザＵ０１」であり、秘密鍵は「Ｋ１０」である一例を示している。

（代理認証器記憶部１５２について）
代理認証器記憶部１５２は、認証器を代理する外部装置に関する情報を記憶する。図７に、実施形態に係る代理認証器記憶部１５２の一例を示す。図７は、実施形態に係る代理認証器記憶部１５２の一例を示す図である。図７に示した例では、代理認証器記憶部１５２は、「代理認証器」、「認証ユーザ」、「判定要素」といった項目を有する。

「代理認証器」は、認証器を代理する機能を有する外部装置を示す。「認証ユーザ」は、代理認証器が認証するユーザを示す。

「判定要素」は、代理認証器が認証ユーザを認証するにあたり、認証に用いる情報を示す。すなわち、代理認証器は、判定要素の項目に挙げられた情報を判定することにより、認証ユーザの本人性を認証する。例えば、判定要素としては、ユーザ端末１０が利用する通信回線が挙げられる。通信回線は、具体的には、通信事業者が提供するＳＩＭカードの識別情報等である。すなわち、代理認証器は、ユーザ端末１０からネットワークＮを介して情報を送受信する際に、ＳＩＭカードの識別情報等を取得し、取得した情報によってユーザ端末１０のユーザＵ０１を認証する。すなわち、ＳＩＭカードは、１ユーザに固有の情報が割り当てられるため、ユーザを認証する判定要素となりうる。

また、代理装置５０が認証に用いる情報は、ユーザ端末１０から代理装置５０に対して、有線線方式、又は、近距離無線通信方式を用いて送信されるのが望ましい。これは、ユーザ端末１０と代理装置５０との通信が上記方式で行われることで、ユーザ端末１０から代理装置５０に送信される認証情報の内容が第三者に流出する蓋然性が低くなるとともに、ユーザ端末１０と代理装置５０とが同一ユーザにより扱われているという蓋然性が高くなるからである。

また、ユーザ端末１０と代理装置５０との間で上記のような近距離通信が成立すること自体を判定要素として扱ってもよい。例えば、ユーザ端末１０と代理認証器との間で、一方から音波を発し、他の一方は音波を受信する。このような通信が成立する場合、ユーザ端末１０と代理認証器とは、同一ユーザや、信頼されるユーザ同士で扱われているものと信頼されるため、ユーザを認証する判定要素となりうる。なお、近距離通信による判定は、音波の他に、ＮＦＣ（Near field radio communication）規格に則った近距離無線通信方式によって行われてもよい。この場合、ＮＦＣ通信によって、ユーザ端末１０と代理装置５０が互いを認識できること自体が、ユーザ端末１０と代理装置５０のユーザの同一性を判定する判定要素となりうる。また、近距離通信は、音波やＮＦＣ規格に則った無線通信に限られず、有線でユーザ端末１０と代理認証器とを接続されることにより成立させてもよい。その他、判定要素の例としては、臨時のパスコード等であってもよい。また、判定要素は、例えば、ユーザが所有するカードのカード番号等であってもよい。この場合、予め登録されていたカード番号をユーザが入力することにより判定が行われる。また、判定要素は、例えば、上記で例示した、認証器が認証に用いるいずれの情報であってもよい。

また、判定要素は、複数設定される場合もある。本人認証においては、一般的に、単独の判定要素よりも複数の判定要素を組み合わせた方が、認証強度が向上する。このため、代理認証器での認証においては、ユーザは、複数の判定要素を用いて認証処理を行わせるようにしてもよい。

すなわち、図７では、代理認証器「代理装置５０」が認証するユーザは「ユーザＵ０１」であり、ユーザＵ０１を判定する要素は「通信回線」と「近距離通信」に基づくことを示している。この場合、代理装置５０は、ユーザ端末１０から通信された際に、ユーザ端末１０が使用する通信回線に関する情報を取得し、識別するとともに、ユーザ端末１０との間に近距離通信が成立するか否かを判定する。すなわち、代理装置５０は、２種類の認証情報に基づいて、ユーザ端末１０を利用するユーザＵ０１を認証する。

（制御部１６について）
制御部１６は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、ユーザ端末１０内部の記憶装置に記憶されている各種プログラムがＲＡＭ（Random Access Memory）を作業領域として実行されることにより実現される。また、制御部１６は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

制御部１６は、ユーザ端末１０において行われるローカルでの認証処理や、認証器を機能させる処理や、代理装置５０や認証サーバ１００との情報の送受信など、各種処理を制御する。図５に示すように、制御部１６は、取得部１６１と、登録部１６２と、認証制御部１６３と、生成部１６４と、要求部１６５と、送信部１６６とを有し、以下に説明する情報処理の機能や作用を実現または実行する。例えば、制御部１６は、ＲＡＭを作業領域として上述したアプリを実行することにより、各種情報処理を実現する。なお、制御部１６の内部構成は、図５に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。

（取得部１６１について）
取得部１６１は、各種情報を取得する。例えば、取得部１６１は、認証サーバ１００や代理装置５０から送信される情報を受信する。また、取得部１６１は、認証サーバ１００や代理装置５０から送信される、ユーザ端末１０を利用するユーザの本人認証の要求を受信する。また、取得部１６１は、検知部１４が検知する各種情報を取得する。

（登録部１６２について）
登録部１６２は、認証に関する各種情報を登録する。また、登録部１６２は、リカバリに関する情報等について、代理装置５０や認証サーバ１００に対して所定の情報を登録する。この場合の登録とは、登録部１６２の指示に従い、代理装置５０や認証サーバ１００が自装置に対して所定の情報を登録することを含む。

例えば、登録部１６２は、ユーザ端末１０を利用するユーザＵ０１の本人性を認証する認証器に関する情報を認証器記憶部１５１に登録する。また、登録部１６２は、認証サーバ１００から認証を受けるため、ユーザ端末１０自身が備える認証器を認証サーバ１００に登録する。この場合、登録部１６２は、認証器に対応する秘密鍵を認証器記憶部１５１に登録する。また、登録部１６２は、秘密鍵を用いて生成される署名を検証する公開鍵を認証サーバ１００に送信し、登録させる。

また、登録部１６２は、ユーザＵ０１の認証に関する情報のリカバリのため、代理装置５０を代理認証器記憶部１５２に登録する。この場合、登録部１６２は、代理装置５０を認証器として扱うため、ユーザＵ０１の情報を代理装置５０に登録する。まず、登録部１６２は、ユーザＵ０１の認証に用いられる情報を代理装置５０に登録する。ユーザＵ０１の認証に用いられる情報とは、図７で示したユーザ端末１０の通信回線に関する情報等である。そして、登録部１６２は、代理装置５０がユーザＵ０１を認証した場合に、認証の結果への署名の生成に用いられる秘密鍵Ｋ５０と、当該署名を検証するための公開鍵Ｋ５１を発行させる。続いて、登録部１６２は、代理装置５０に対して、認証の結果への署名の生成に用いられる秘密鍵Ｋ５０を代理装置５０内に登録させる。また、登録部１６２は、認証サーバ１００に対して、署名の検証に用いられる公開鍵Ｋ５１を認証サーバ１００内に登録させる。なお、公開鍵Ｋ５１の認証サーバ１００への送信は、代理装置５０から行われてもよい。このように、登録部１６２は、ユーザＵ０１を認証する認証器として代理装置５０が扱われるよう、適宜、情報を各種装置に登録する。

そして、登録部１６２は、代理装置５０から認証サーバ１００へ送信された公開鍵Ｋ５１と、ユーザ端末１０側が既に送信していた公開鍵Ｋ１１とを対応付けて認証サーバ１００に登録させる。すなわち、登録部１６２は、公開鍵Ｋ５１を用いて検証される署名が、公開鍵Ｋ１１を用いて検証される署名と同一のユーザＵ０１を認証したことを示す署名であると特定されるよう、認証サーバ１００へ公開鍵Ｋ５１及び公開鍵Ｋ１１を登録する。これにより、認証サーバ１００は、公開鍵Ｋ５１を用いて署名を検証した場合に、公開鍵Ｋ１１を用いて署名を検証した場合に認証されるユーザであるユーザＵ０１を特定することができる。これにより、認証サーバ１００は、秘密鍵Ｋ５０がリカバリ用の認証結果情報として送信された場合に、公開鍵Ｋ５１を用いて署名を検証することで、対応付けられている公開鍵Ｋ１１に関連するユーザの情報をリカバリすることができる。

（認証制御部１６３について）
認証制御部１６３は、ユーザ端末１０を利用するユーザＵ０１の本人性の認証に関する処理を制御する。例えば、認証制御部１６３は、ユーザ端末１０が有する認証器を管理する。また、認証制御部１６３は、登録部１６２によって登録された認証器を動作させ、ユーザ端末１０を利用するユーザＵ０１の本人性を認証する。すなわち、認証制御部１６３は、実施形態において、指紋認証器１６３Ａ等の認証器としての機能を実現する。

また、認証制御部１６３は、代理装置５０が行う認証処理を制御する。例えば、認証制御部１６３は、代理認証器記憶部１５２を参照し、代理装置５０が行う認証処理に要する情報を取得する。そして、認証制御部１６３は、代理装置５０が行う認証処理に要する情報を送信部１６６に送り、代理装置５０に送信させる。

認証制御部１６３は、代理装置５０にユーザＵ０１の認証を実行させる場合に、少なくとも二種類以上の情報に基づいて、ユーザＵ０１の本人性を認証させるようにしてもよい。これにより、代理装置５０が行う認証処理が複数の判定要素により行われる多要素認証となるため、より認証強度を向上させることができる。

（生成部１６４について）
生成部１６４は、認証結果情報の生成を制御する。生成部１６４は、認証器記憶部１５１に記憶された認証器による認証の結果を取得する。そして、生成部１６４は、認証器による認証の結果から、認証サーバ１００によって処理される認証結果情報を生成する。

具体的には、生成部１６４は、認証器が認証を行った結果を取得する。そして、生成部１６４は、ユーザＵ０１が認証された結果に対して、認証器に対応する秘密鍵を用いて署名を生成する。そして、生成部１６４は、認証の結果に署名を付すことにより、認証の結果に対応する認証結果情報を生成する。例えば、生成部１６４は、認証制御部１６３が指紋認証器１６３Ａを用いて認証を行った場合には、認証の結果に対して秘密鍵Ｋ１０を用いて署名を付すことで、認証結果情報を生成する。かかる認証結果情報は、ユーザ端末１０において、ユーザＵ０１の本人認証処理が完了したことを示している。生成部１６４は、生成した認証結果情報を送信部１６６に送り、認証サーバ１００に送信させる。

（要求部１６５について）
要求部１６５は、認証サーバ１００に対して各種要求を行う。例えば、要求部１６５は、何らかの理由で、これまで使用していた認証器が使用できなくなった場合に、これまで使用していた認証器で認証を行うことにより利用できていた各種サービス等、認証に関連する情報のリカバリを認証サーバ１００に要求する。

具体的には、要求部１６５は、代理装置５０によって送信される認証結果情報、すなわち、代理装置５０で実行された認証処理の結果に付された署名が、公開鍵Ｋ５１を用いて認証サーバ１００によって検証される場合に、公開鍵Ｋ１１に関連する情報のリカバリを要求する。公開鍵Ｋ１１に関連する情報とは、例えば、ユーザＵ０１が認証サーバ１００に認証されることで、ウェブサービス等で利用可能になる情報のことをいう。具体的には、公開鍵Ｋ１１に関連する情報には、ユーザＵ０１に関する情報であって、所定のサービスで利用していたサービスアカウントや、ユーザＵ０１のＩＤ情報、ユーザＵ０１が設定しているパスワードに関する情報、各種ウェブサーバに格納されているユーザ情報へのアクセス権等が含まれる。また、本願のリカバリ処理には、公開鍵Ｋ１１に対応付けられたユーザＵ０１に関連する情報のみならず、ユーザＵ０１を認証する認証器に対する鍵の再発行処理も含まれる。

（送信部１６６について）
送信部１６６は、各種情報を送信する。例えば、送信部１６６は、生成部１６４によって生成された認証結果情報を認証サーバ１００に送信する。また、送信部１６６は、認証サーバ１００から送信された認証済み情報を取得部１６１が取得した場合には、かかる認証済み情報を、サービスを提供するウェブサーバに送信してもよい。また、送信部１６６は、認証制御部１６３の指示に従い、代理装置５０に対して、代理装置５０がユーザＵ０１を認証するのに用いられる情報を送信する。この場合、送信部１６６は、上述のように、有線方式、又は、近距離無線通信方式を用いて、代理装置５０にユーザの認証に用いられる情報を送信するようにしてもよい。

〔４．代理装置の構成〕
次に、図８を用いて、実施形態に係るユーザ端末１０の構成について説明する。図８は、実施形態に係る代理装置５０の構成例を示す図である。図８に示すように、代理装置５０は、通信部５１と、記憶部５２と、制御部５３とを有する。なお、代理装置５０が有する各処理部の接続関係は、図８に示した接続関係に限られず、他の接続関係であってもよい。

（通信部５１について）
通信部１１は、ネットワークＮと有線又は無線で接続され、ユーザ端末１０や認証サーバ１００等との間で情報の送受信を行う。例えば、通信部１１は、ＮＩＣ等によって実現される。

（記憶部５２について）
記憶部５２は、各種情報を記憶する。記憶部５２は、例えば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。

（認証情報記憶部５２１について）
認証情報記憶部５２１は、ユーザの認証に関する情報を記憶する。図９に、実施形態に係る認証情報記憶部５２１の一例を示す。図９は、実施形態に係る認証情報記憶部５２１の一例を示す図である。図９に示した例では、認証情報記憶部５２１は、「認証ユーザ」、「判定要素」、「秘密鍵」といった項目を有する。

「認証ユーザ」は、代理装置５０が認証するユーザを示す。「判定要素」は、ユーザの認証に用いられる情報であり、図７の同一の項目に対応する。「秘密鍵」は、認証ユーザが認証された場合に、認証の結果に付す署名を生成するために用いられる秘密鍵を識別する情報を示す。

すなわち、図９では、代理装置５０が認証するユーザは「ユーザＵ０１」であり、認証に用いる判定要素は「通信回線」と「近距離通信」であり、ユーザＵ０１が認証された結果に付す署名を生成する秘密鍵は「Ｋ５０」である例を示している。

（制御部５３について）
制御部５３は、例えば、ＣＰＵやＭＰＵ等によって、代理装置５０内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部５３は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

制御部５３は、ユーザ端末１０において行われるローカルでの認証処理や、認証器を機能させる処理や、代理装置５０や認証サーバ１００との情報の送受信など、各種処理を制御する。図８に示すように、制御部５３は、受信部５３１と、登録部５３２と、認証部５３３と、生成部５３４と、送信部５３５とを有し、以下に説明する情報処理の機能や作用を実現または実行する。例えば、制御部５３は、ＲＡＭを作業領域として上述したアプリを実行することにより、各種情報処理を実現する。なお、制御部５３の内部構成は、図８に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。

（受信部５３１について）
受信部５３１は、各種情報を受信する。例えば、受信部５３１は、ユーザ端末１０から送信される認証に関する情報を受信する。また、受信部５３１は、ユーザ端末１０から送信される登録に関する情報を受信する。

（登録部５３２について）
登録部５３２は、各種情報を登録する。例えば、登録部５３２は、ユーザ端末１０から受信した認証に関する情報を認証情報記憶部５２１に登録する。また、登録部５３２は、代理装置５０が認証器として認証サーバ１００に登録された場合には、認証サーバ１００との通信で用いる秘密鍵Ｋ５０を認証情報記憶部５２１に登録する。

（認証部５３３について）
認証部５３３は、認証処理を実行する。例えば、認証部５３３は、ユーザ端末１０の要求に従い、ユーザＵ０１を認証する。この場合、認証部５３３は、ユーザ端末１０から送信される認証情報を判定することにより、ユーザＵ０１を認証する。

（生成部５３４について）
生成部５３４は、認証結果情報の生成を制御する。すなわち、生成部５３４は、認証部５３３によって認証処理が行われた際に、認証の結果に対して、秘密鍵Ｋ５０を用いて署名を付すことにより、認証結果情報を生成する。上述のように、認証結果情報は、認証サーバ１００が規定する特定の認証手順（プロトコル）で処理される情報であるため、生成部５３４は、かかる認証手順に則って認証結果情報を生成する。

（送信部５３５について）
送信部５３５は、各種情報を送信する。例えば、送信部５３５は、生成部５３４によって生成された認証結果情報を認証サーバ１００に送信する。

〔５．認証サーバの構成〕
次に、図１０を用いて、実施形態に係る認証サーバ１００の構成について説明する。図１０は、実施形態に係る認証サーバ１００の構成例を示す図である。図１０に示すように、認証サーバ１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、認証サーバ１００は、認証サーバ１００を利用する管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。

（通信部１１０について）
通信部１１０は、例えば、ＮＩＣ等によって実現される。通信部１１０は、ネットワークＮと有線又は無線で接続され、ネットワークＮを介して、ユーザ端末１０や代理装置５０との間で情報の送受信を行う。なお、通信部１１０は、ユーザ端末１０や代理装置５０から送信される認証結果情報を処理する場合には、安全性の高い特定の認証手順（プロトコル）に則って処理を行う。

（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。記憶部１２０は、登録情報記憶部１２１と、リカバリ情報記憶部１２２を有する。

（登録情報記憶部１２１について）
登録情報記憶部１２１は、認証サーバ１００に登録された認証器に関する情報を記憶する。ここで、図１１に、実施形態に係る登録情報記憶部１２１の一例を示す。図１１は、実施形態に係る登録情報記憶部１２１の一例を示す図である。図１１に示した例では、登録情報記憶部１２１は、「認証器ＩＤ」、「タイプ」、「認証ユーザ」、「公開鍵」といった項目を有する。

「認証器ＩＤ」、「タイプ」、「認証ユーザ」は、図６に示した同一の項目に対応する。「公開鍵」は、認証器の登録の際に認証器側（すなわち、ユーザ端末１０又は代理装置５０）から送信される鍵情報であり、同時に発行された秘密鍵と対になる鍵を示す。公開鍵は、認証器及び認証ユーザごとに対応付けられて記憶される。

すなわち、図１１では、認証器ＩＤ「１６３Ａ」で識別される認証器が登録されており、認証器のタイプは「指紋」であり、認証されるユーザは「ユーザＵ０１」であり、当該認証器がユーザＵ０１を認証する際に用いられる公開鍵は「Ｋ１１」であることを示している。

（リカバリ情報記憶部１２２について）
リカバリ情報記憶部１２２は、ユーザ端末１０に係る認証器と、認証器を代理する代理認証器との対応付けを記憶する。また、リカバリ情報記憶部１２２は、認証サーバ１００に認証されたユーザに関連する情報も含めて記憶するものとする。ここで、図１２に、実施形態に係るリカバリ情報記憶部１２２の一例を示す。図１２は、実施形態に係るリカバリ情報記憶部１２２の一例を示す図である。図１２に示した例では、リカバリ情報記憶部１２２は、「認証ユーザ」、「公開鍵」、「リカバリ用公開鍵」、「ユーザ情報」といった項目を有する。

「認証ユーザ」は、図６に示した同一の項目に対応する。「公開鍵」は、図１１に示した同一の項目に対応するが、ここでは、認証ユーザが同一である公開鍵は各々対応付けられて記憶されるものとする。例えば、図１１に示すように、ユーザＵ０１を認証する認証器であって、ユーザ端末１０が備える認証器は、「指紋認証器１６３Ａ」、「虹彩認証器１６３Ｂ」、「声紋認証器１６３Ｃ」が記憶されている。このため、リカバリ情報記憶部１２２には、各々に対応する公開鍵が対応付けられて記憶される。

「リカバリ用公開鍵」は、認証ユーザを認証する代理認証器に対応する鍵を示す。「ユーザ情報」は、認証サーバ１００に認証されたユーザに関する情報を示す。図１２では、ユーザ情報は、「Ａ０１」といった概念で示しているが、実際には、ユーザ情報には、認証サーバ１００に認証されたユーザＵ０１が各種サービスで利用していた情報が記憶される。例えば、ユーザ情報には、所定のサービスで利用していたサービスアカウントや、各種ウェブサーバに格納されているユーザ情報へのアクセス権等が記憶される。図１２に示すように、ユーザ情報は、認証ユーザに対応付けられるとともに、ユーザを認証する認証器の公開鍵や、代理認証器の公開鍵に対応付けられる。言い換えれば、ユーザを認証する認証器の公開鍵に関連する情報には、ユーザ情報が含まれる。

すなわち、図１２では、認証ユーザ「ユーザＵ０１」を認証する認証器の公開鍵は「Ｋ１１」、「Ｋ２１」及び「Ｋ３１」であり、代理認証器の公開鍵、すなわち、リカバリ用公開鍵は「Ｋ５１」であり、ユーザＵ０１のユーザ情報は「Ａ０１」である例を示している。

（制御部１３０について）
制御部１３０は、例えば、ＣＰＵやＭＰＵ等によって、認証サーバ１００内部の記憶装置に記憶されている各種プログラム（選択プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

図１０に示すように、制御部１３０は、受信部１３１と、登録部１３２と、検証部１３３と、実行部１３４と、送信部１３５とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図１０に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図１０に示した接続関係に限られず、他の接続関係であってもよい。

（受信部１３１について）
受信部１３１は、各種情報を受信する。例えば、受信部１３１は、認証サーバ１００における認証を所望するユーザ端末１０から、認証器の登録の要求を受信する。また、受信部１３１は、例えば、ユーザ端末１０がウェブサーバにアクセスし、アクセス先のウェブサーバが提供するサービスがユーザ端末１０に認証を要求する場合に、かかる認証要求をウェブサーバから受信する。この場合、受信部１３１が受け付けた認証要求に対応して、後述する送信部１３５は、ユーザ端末１０に認証を行わせる旨を示す要求を送信する。また、受信部１３１は、認証処理において、ローカルで行われた認証結果に基づいて生成される情報である認証結果情報を受信する。受信部１３１は、認証サーバ１００が規定する特定の認証手順を用いて、ユーザ端末１０から送信される認証結果情報を処理する。

（登録部１３２について）
登録部１３２は、認証器に関する情報を登録する。例えば、登録部１３２は、受信部１３１によって受信された情報に基づいて、登録を要求したユーザ端末１０が備える認証器を登録する。登録部１３２は、登録した情報を登録情報記憶部１２１に記憶する。

また、登録部１３２は、認証サーバ１００と認証器との間で対になる公開鍵と秘密鍵のうち、公開鍵を登録する。認証結果情報を検証する際には、検証部１３３は、登録部１３２によって登録された公開鍵を参照し、認証結果情報を検証する。

また、登録部１３２は、代理認証器に関する情報を登録する。例えば、登録部１３２は、ユーザ端末１０に係る登録部１６２によって制御された代理装置５０から、認証器の登録を受け付ける。そして、登録部１３２は、代理装置５０を認証器として、登録情報記憶部１２１に記憶する。また、登録部１３２は、代理装置５０をユーザ端末１０に関するリカバリ用の認証器として、リカバリ情報記憶部１２２に登録する。

（検証部１３３について）
検証部１３３は、認証結果情報を検証する。具体的には、検証部１３３は、ユーザ端末１０から送信された認証結果情報を解析し、認証結果情報に基づいて認証されるべきユーザを特定する。さらに、検証部１３３は、登録情報記憶部１２１を介して、認証結果情報の生成元である認証器に対応する秘密鍵を特定する。そして、検証部１３３は、認証結果情報に付された署名が、登録された認証器の秘密鍵によって作成された署名であるか否かを、秘密鍵に対応する公開鍵を用いて検証する。

そして、検証部１３３は、秘密鍵に対応する公開鍵による検証が確認された場合に、ユーザ端末１０から送信された認証結果情報を正規な認証情報として認める。そして、検証部１３３は、認証結果情報を認証したことを示す情報を送信部１３５に送り、ユーザ端末１０（あるいは代理装置５０）に送信させる。

なお、検証部１３３は、認証結果情報を生成した認証器が、所定の条件に合致しない場合、その認証結果情報で示されたユーザの本人性を認めないものとしてもよい。例えば、検証部１３３は、認証結果情報を生成した認証器が、登録部１３２が管理する登録情報記憶部１２１に記憶されていない場合や、送信された認証結果情報が認証サーバ１００の規定する特定の認証手順に則っていない場合などには、認証結果情報で示されたユーザの本人性を認証しないものとしてよい。

（実行部１３４について）
実行部１３４は、検証部１３３が検証した情報に基づいて、情報のリカバリを実行する。例えば、検証部１３３は、代理装置５０から送信された認証結果情報を検証することにより、ユーザＵ０１を認証する。この場合、実行部１３４は、ユーザ端末１０からリカバリに関する要求を受け付けていた場合、リカバリ情報記憶部１２２を参照する。そして、実行部１３４は、認証されたユーザＵ０１に基づいて、ユーザＵ０１を認証するために用いられる他の公開鍵に関する情報や、ユーザＵ０１のユーザ情報を特定する。そして、実行部１３４は、ユーザ端末１０からの要求に従い、ユーザＵ０１に関する情報のリカバリを実行する。

すなわち、実行部１３４は、代理装置５０に対応する公開鍵Ｋ５１を用いて検証された署名により認証されるユーザが、公開鍵Ｋ１１を用いて検証される署名により認証されるユーザと同一のユーザであるユーザＵ０１である場合に、ユーザ端末１０に係る要求部１６５によって要求されたリカバリを実行する。このように、実行部１３４は、認証が行われた認証元は異なるものの、同様の認証方式によりユーザＵ０１が認証されたことにより、要求されたリカバリを行うため、安全性の確保されたリカバリ処理を行うことができる。

なお、実行部１３４は、代理装置５０等、ユーザＵ０１の認証を代理する代理認証器の信頼性に応じて、要求部１６５から要求されたリカバリを実行するか否かを判定してもよい。例えば、代理装置５０の信頼性は、認証サーバ１００の管理者等により予め設定される。具体的には、代理装置５０の信頼性は、代理装置５０が行う認証方式、及び、代理装置５０とユーザ端末１０との通信方式等によって設定される。

例えば、代理装置５０が、複数の判定要素によってユーザＵ０１を認証する、いわゆる多要素認証を実行する場合には、代理装置５０の信頼性は高く設定される。言い換えれば、ユーザ端末１０に係る認証制御部１６３は、代理装置５０にユーザＵ０１の認証を実行させる場合に、少なくとも二種類以上の情報に基づいて、ユーザの本人性を認証させる。これにより、代理装置５０の信頼性は、１種類の判定要素を用いて認証を行う場合よりも高く設定される。

また、ユーザ端末１０と代理装置５０との通信方式によって、実行部１３４は、リカバリを実行するか否かを判定してもよい。例えば、ユーザ端末１０と代理装置５０の通信が、インターネット等の広域ネットワークを介する場合、ユーザ端末１０から代理装置５０に送信される認証情報は、第三者に傍受される可能性が高くなる。このため、代理装置５０が行う認証処理についても、信頼性が低下する。

一方で、ユーザ端末１０と代理装置５０の通信が有線方式や、近距離通信のみで行われる場合、ユーザ端末１０から代理装置５０に送信される認証情報の内容が第三者に流出する可能性が低くなる。このため、代理装置５０が行う認証処理について、信頼性が高く判定される。このような通信方式による信頼性の設定は、代理装置５０が、判定要素として近距離通信によってユーザＵ０１を認証する処理によって代替することが可能である。すなわち、代理装置５０が、ユーザＵ０１を認証する判定要素に近距離通信を用いている場合には、実行部１３４は、代理装置５０とユーザ端末１０との通信は信頼性の高いものであると取り扱ってもよい。

なお、実行部１３４は、例えば、認証サーバ１００の管理者の設定に従い、代理装置５０等の信頼性に独自の設定を行ってもよい。例えば、代理装置５０自体のセキュリティの状態や、代理装置５０の過去の認証の信頼性等に応じて、実行部１３４は、代理装置５０の信頼性の設定を行う。そして、実行部１３４は、代理装置５０に一定以上の信頼性がある場合に、代理装置５０の認証処理に基づいて、ユーザ端末１０の要求に応じたリカバリを行うようにしてもよい。これにより、実行部１３４は、一定の信頼のおける、安全性の確保されたリカバリ処理を行うことができる。

（送信部１３５について）
送信部１３５は、各種情報を送信する。例えば、送信部１３５は、サービスの利用に際してユーザ端末１０を利用するユーザの本人性の認証を行うことが求められた場合に、ユーザ端末１０に、認証を要求する旨の情報を送信する。また、送信部１３５は、認証結果情報を検証した検証部１３３によって、認証結果情報の送信元のユーザの本人性が認証された場合、認証済み情報をユーザ端末１０、あるいは代理装置５０に送信する。また、送信部１３５は、実行部１３４によってリカバリが実行された場合には、かかる情報をユーザ端末１０に送信する。

〔６．処理手順〕
次に、図１３を用いて、実施形態に係るリカバリシステム１による処理の手順について説明する。図１３は、実施形態に係る処理手順を示すシーケンス図である。

まず、ユーザ端末１０は、認証サーバ１００に対して、リカバリを要求する（ステップＳ１０１）。認証サーバ１００は、リカバリの要求に応答して、ユーザ端末１０に対して、ユーザ端末１０を利用するユーザＵ０１の本人認証を要求する（ステップＳ１０２）。

ここで、ユーザ端末１０は、予め代理の認証器として認証サーバ１００に登録しておいた代理装置５０にアクセスする。そして、ユーザ端末１０は、ユーザＵ０１を認証するための認証情報を代理装置５０に送信する（ステップＳ１０３）。

代理装置５０は、ユーザ端末１０の要求に従い、ユーザ端末１０側のユーザであるユーザＵ０１を認証する（ステップＳ１０４）。そして、代理装置５０は、認証サーバ１００が規定する特定の認証手順によって処理される情報である認証結果情報を生成する。そして、代理装置５０は、生成した認証結果情報を認証サーバ１００に送信する（ステップＳ１０５）。

認証サーバ１００は、代理装置５０から送信された認証結果情報を検証する。言い換えれば、認証サーバ１００は、認証結果情報に付された署名であって、代理装置５０に対応する秘密鍵Ｋ５０を用いて生成された署名を、公開鍵Ｋ５１を用いて検証する。

そして、認証サーバ１００は、代理装置５０から送信された認証結果情報に基づいて、ユーザＵ０１を認証する。そして、認証サーバ１００は、ユーザ端末１０と、代理装置５０との対応付けを参照する（ステップＳ１０６）。例えば、認証サーバ１００は、リカバリ情報記憶部１２２を参照することにより、代理装置５０の公開鍵Ｋ５１と、ユーザ端末１０に係る指紋認証器１６３Ａの公開鍵であるＫ１１との対応付けを参照する。

かかる対応付けを参照することにより、認証サーバ１００は、代理装置５０によって認証されたユーザＵ０１が、以前にユーザ端末１０を利用していたユーザＵ０１であることを認証する（ステップＳ１０７）。

そして、認証サーバ１００は、認証されたユーザＵ０１に関する情報のリカバリを実行する（ステップＳ１０８）。認証サーバ１００は、リカバリが実行された旨をユーザ端末１０に送信する（ステップＳ１０９）。これにより、ユーザ端末１０が認証サーバ１００に要求したリカバリが完了する。

〔７．変形例〕
上述したリカバリシステム１によるリカバリ処理は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、リカバリシステム１の他の実施形態について説明する。

〔７−１．代理装置〕
上記実施形態では、ユーザ端末１０のユーザＵ０１を認証する認証器を代理する装置として、代理装置５０を例として説明した。ここで、代理装置５０は、種々の装置により実現されてもよい。この点について、図１４を用いて説明する。

図１４は、変形例に係るリカバリシステム１の構成例を示す図である。図１４に示すように、変形例に係るリカバリシステム１では、代理装置５０の代わりに、家族端末３０や、友人端末３５や、店舗端末４０や、クラウドサーバ４５が含まれる。

家族端末３０は、例えば、ユーザ端末１０を利用するユーザＵ０１の家族が利用する端末である。友人端末３５は、例えば、ユーザＵ０１の友人が利用する端末である。言い換えれば、家族端末３０や友人端末３５は、ユーザＵ０１の関係者が利用する端末である。店舗端末４０は、例えば、所定の店舗（例えば、ユーザ端末１０が利用する回線を提供する回線提供会社が運営する店舗）に備えられる端末である。クラウドサーバ４５は、インターネット等を介して、ユーザ端末１０がアクセス可能なサーバ装置である。

例えば、ユーザＵ０１は、上記実施形態において説明したリカバリ処理において、代理装置５０の代わりに、家族端末３０や、友人端末３５や、店舗端末４０や、クラウドサーバ４５を利用してもよい。

例えば、ユーザＵ０１は、クラウドサーバ４５を代理装置５０の代わりに利用するものとする。この場合、ユーザＵ０１は、代理認証器として、予め認証サーバ１００にクラウドサーバ４５を登録する。例えば、ユーザＵ０１は、バックアップとして、クラウドサーバ４５上に指紋の登録データを保存する。リカバリ処理にあたり、ユーザ端末１０は、自身が備える認証器の代理として、クラウドサーバ４５に指紋データを送信し、認証を行わせる。クラウドサーバ４５は、認証の結果に対して署名を付し、認証サーバ１００に送信する。認証サーバ１００は、クラウドサーバ４５が送信した認証の結果と、予め認証サーバ１００のリカバリ情報記憶部１２２に登録されていた情報の対応付けができるか否かを参照する。そして、認証サーバ１００は、両者の対応が確認できた場合、ユーザ端末１０の要求に従ったリカバリを実行する。

このように、リカバリシステム１によれば、ユーザ端末１０を代理する装置として、ユーザＵ０１が利用する他の端末装置、ユーザＵ０１の関係者が利用する家族端末３０や友人端末３５、所定の事業者によって営業される店舗に設置される店舗端末４０、ネットワークＮを介して利用可能なクラウド上にあるクラウドサーバ４５のいずれかに、ユーザＵ０１の本人性の認証を実行させることができる。

すなわち、リカバリシステム１によれば、ユーザＵ０１は種々の端末を用いたリカバリ処理を行うことができるため、リカバリに際して柔軟な対応を採ることができる。なお、認証サーバ１００は、家族端末３０や友人端末３５等に対しても、各々の信頼性に応じて、リカバリを実行するか否かを判定してもよい。例えば、クラウドサーバ４５を利用する場合、ユーザＵ０１を認証するための認証情報（上記例では、指紋データ）がクラウド上に流出するおそれがある。このような場合、認証サーバ１００は、クラウドサーバ４５が行う処理について、他の端末が行う認証処理に比べて信頼性を低く扱ってもよい。一方、店舗端末４０は、事業者から提供されるため、一定の安全性が確保できていると想定される。すなわち、認証サーバ１００は、店舗端末４０によって実行される認証処理に対しては、クラウドサーバ４５が行う処理よりも信頼性を高く扱ってもよい。

〔７−２．認証器の形態〕
上記実施形態では、各認証器は、認証制御部１６３が実現する認証処理の一機能として実現される例を示した。しかし、認証器は、ユーザ端末１０と接続される認証装置（ハードウェア）として実現されてもよい。

この場合、認証器は、ユーザ端末１０と通信する機能を有するとともに、ユーザ端末１０から入力される指紋等の情報を取得する機能を備える。そして、認証器は、入力データと登録データとが照合した場合に、ユーザ端末１０がユーザＵ０１に利用されていることを認証する。そして、認証器は、認証の結果に基づいて、認証結果情報を生成する。そして、認証器は、認証サーバ１００から認証済み情報を受信し、かかる情報をユーザ端末１０に送信する。この場合、ユーザ端末１０に係る認証制御部１６３及び生成部１６４は、ユーザ端末１０に接続された認証器の動作を制御する。これにより、ユーザ端末１０は、ウェブサーバから提供される各種サービスを利用することができる。

また、認証器は、認証制御部１６３や生成部１６４の機能が一体化されたプログラム（アプリ）として実現されてもよい。認証器がアプリである場合、当該アプリは、ユーザの操作に従ってユーザ端末１０にインストールされることにより実行される。

〔７−３．代理認証器〕
上記実施形態では、代理認証器による認証処理は、リカバリ用に利用されるものとして説明した。しかし、代理認証器による認証処理は、必ずしもリカバリ用にのみ利用されるとは限らない。例えば、代理認証器による認証処理は、ユーザ端末１０が備える認証器のバックアップとして利用されてもよい。

なお、認証サーバ１００は、代理認証器により認証されたユーザＵ０１が所定のサービスを利用する場合、ユーザ端末１０が備える認証器により認証された場合と比べて、サービスの利用に制限を設けるようにしてもよい。例えば、認証サーバ１００は、所定のサービスのうち、認証強度が高い認証でしか受け付けないサービス（例えば、決済処理など）を受け付けないようにすることや、所定時間しかサービスへのログインを認めないとすることなど、所定のアクセスコントロールを行う。これにより、認証サーバ１００は、代理認証器による認証を認める一方で、認証処理に関する一定の安全性を確保することができる。

〔７−４．各装置の構成〕
上記実施形態では、ユーザ端末１０や、代理装置５０や、認証サーバ１００の構成例について図５、図８及び図１０を用いて説明した。しかし、リカバリシステム１に含まれる各装置は、必ずしも例示した構成によって実現されなくともよい。例えば、ユーザ端末１０は、図５で例示した全ての処理部を備えることを必ずしも要しない。すなわち、ユーザ端末１０は、表示部１３や検知部１４を必ずしも内部に備えていなくてもよい。また、ユーザ端末１０は、２以上の機器に分離されて図５に示す構成が実現されてもよい。例えば、ユーザ端末１０は、少なくとも検知部１４と認証制御部１６３と生成部１６４とを有する認証機器と、少なくとも通信部１１を有する通信機器とが分離された構成を有する、２台以上の機器により実現されてもよい。

〔７−５．リカバリシステムの動作〕
リカバリシステム１に含まれる各装置は、所定のアプリケーションを利用することで、各装置の通信状態等を検出し、リカバリ処理で実行される各処理を行ってもよい。

すなわち、ユーザ端末１０や、代理装置５０等には、ユーザ端末１０を管理する管理者（例えば、ユーザＵ０１）によって、共通するアプリケーションがインストールされる。ユーザ端末１０は、かかるアプリケーションの機能を制御することにより、代理装置５０に対して、認証情報の送受信や、認証処理の制御等を行うことができる。このように、共通するアプリケーションがリカバリシステム１に含まれる各装置にインストールされることにより、迅速かつ正確にリカバリ処理を実現することができる。

〔７−６．異なる鍵によるリカバリ〕
上記実施形態では、認証サーバ１００に送信された複数の公開鍵を対応付けることにより、リカバリ処理を実施する例を示した。ここで、認証サーバ１００は、認証処理において、対応付けられた公開鍵であれば他の秘密鍵を検証可能なように設定しておいてもよい。

すなわち、認証サーバ１００は、ユーザ端末１０から送信される公開鍵Ｋ１１と、代理装置から送信される公開鍵Ｋ５１とを対応付ける。なお、公開鍵Ｋ１１は、秘密鍵Ｋ１０を用いて生成された署名を検証し、公開鍵Ｋ５１は、秘密鍵Ｋ５０を用いて生成された署名を検証するものとする。このとき、認証サーバ１００は、対応付けられた公開鍵Ｋ１１とＫ５１のいずれかを用いて、秘密鍵Ｋ１０または秘密鍵Ｋ５０を用いて生成された署名を検証可能なように設定してもよい。かかる設定は、例えば、認証サーバ１００に認証器が登録される際に、認証サーバ１００の管理者等によって設定されてもよいし、ユーザ端末１０のユーザからの申請によって設定が行われてもよい。

すなわち、リカバリシステム１は、秘密鍵Ｋ１０とは異なる秘密鍵Ｋ５０を用いて、秘密鍵Ｋ１０を用いる場合と同じ認証プロトコルに従って、代理装置５０によるユーザの認証の結果への署名の生成を制御する生成部１６４と、秘密鍵Ｋ１０で生成される署名を検証するために用いられる公開鍵Ｋ１１を用いて、秘密鍵Ｋ５０を用いて生成された署名を検証した検証結果に基づいて、秘密鍵Ｋ１０に関する情報のリカバリを実行する実行部１３４と、によって構成されてもよい。なお、秘密鍵Ｋ１０を用いる場合と同じ認証プロトコルに従うとは、秘密鍵Ｋ１０を用いた、ユーザ端末１０と認証サーバ１００との間で行われる認証処理の一連の認証手順を意味する。言い換えれば、この場合の認証プロトコルとは、認証サーバ１００にユーザが認証されるために行われる一連の認証手順（方式）を示している。

また、実行部は、公開鍵Ｋ５１を用いて検証された署名により認証されるユーザが、秘密鍵Ｋ１０を用いて生成される署名により認証されるユーザと同一のユーザＵ０１である場合に、秘密鍵Ｋ１０に関する情報のリカバリを実行するようにしてもよい。秘密鍵Ｋ１０に関する情報とは、秘密鍵Ｋ１０とペアである公開鍵Ｋ１１に関する情報でもあり、すなわち、ユーザＵ０１に関する情報と言い換えることができる。また、この場合、リカバリシステム１内のいずれかの記憶部には、秘密鍵Ｋ５０に関する情報と、公開鍵Ｋ１１に関する情報とが対応付けて記憶される。秘密鍵Ｋ５０に関する情報とは、ペアとなる公開鍵Ｋ５１に関する情報を含み、公開鍵Ｋ１１に関する情報とは、ペアとなる秘密鍵Ｋ１０に関する情報を含む。このように、リカバリシステム１では、柔軟に鍵の対応付けを行うことにより、迅速なリカバリ処理を行うことができる。

〔８．ハードウェア構成〕
上述してきた実施形態に係るユーザ端末１０や、代理装置５０や、認証サーバ１００は、例えば図１５に示すような構成のコンピュータ１０００によって実現される。以下、ユーザ端末１０を例に挙げて説明する。図１５は、ユーザ端末１０の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に記憶されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を記憶する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、通信網５００（図４に示したネットワークＮに対応）を介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを、通信網５００を介して他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して生成したデータを出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に記憶されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が実施形態に係るユーザ端末１０として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部１６の機能を実現する。また、ＨＤＤ１４００には、記憶部１５内のデータが記憶される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から通信網５００を介してこれらのプログラムを取得してもよい。

〔９．その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図５に示した認証制御部１６３と、生成部１６４とは統合されてもよい。また、例えば、記憶部１５に記憶される情報は、ネットワークＮを介して、外部に備えられた記憶装置に記憶されてもよい。

また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

〔１０．効果〕
上述してきたように、実施形態に係るリカバリシステム１は、第１の端末装置であるユーザ端末１０_１と、第２の端末装置であるユーザ端末１０_２と、認証サーバ１００とを含む。ユーザ端末１０_１は、ユーザ端末１０_１自身が生成する署名の検証に用いられる第１の鍵（公開鍵Ｋ１１等）を認証サーバ１００に送信するとともに、ユーザの本人性を認証する所定の認証装置である代理装置５０に、ユーザの認証に用いる情報を送信する送信部１６６と、代理装置５０による認証の結果への署名の生成に用いられる第２の鍵である秘密鍵Ｋ５０を、代理装置５０内に登録させるとともに、秘密鍵Ｋ５０を用いて生成された署名を検証するために用いられる第３の鍵である公開鍵Ｋ５１を、当該署名を検証する認証サーバ１００内に登録させる登録部１６２と、を備える。認証サーバ１００は、公開鍵Ｋ５１と、ユーザ端末１０_１から送信される第１の鍵である公開鍵Ｋ１１等とを対応付けて記憶するリカバリ情報記憶部１２２を備える。ユーザ端末１０_２は、代理装置５０にユーザの認証を実行させ、当該認証の結果を認証サーバ１００に送信させる認証制御部１６３と、認証制御部１６３によって送信された認証の結果に付された署名が、公開鍵Ｋ５１を用いて認証サーバ１００によって検証される場合に、公開鍵Ｋ１１に関連する情報のリカバリを要求する要求部１６５とを備える。

このように、リカバリシステム１は、ユーザ端末１０_１と認証サーバ１００との間で行われる認証方式において、ユーザ端末１０_１が有する鍵とは異なる鍵を代理装置５０に登録する。ユーザ端末１０_１と、代理装置５０の鍵とが対応付けて記憶されることにより、代理装置５０によって行われる認証処理によって、ユーザ端末１０_１のユーザであるユーザＵ０１が特定される。そして、ユーザ端末１０_２は、このような登録状況のもと、代理装置５０による認証処理を行わせることにより、認証サーバ１００にユーザ端末１０_１が登録した鍵に関する情報、すなわち、認証サーバ１００によって認証されていたユーザＵ０１のアカウント情報等をリカバリさせる。すなわち、リカバリシステム１によれば、認証サーバ１００とユーザ端末１０_１との間で行われていた認証方式に関する鍵を対応付けることにより、ユーザ端末１０_２からユーザ端末１０_１における情報のリカバリの要求を受け付けることができる。これにより、リカバリシステム１によれば、ユーザ端末１０_１及び１０_２を利用するユーザは、ユーザ端末１０_１に係る認証の機能を失った場合でも、ユーザ端末１０_２を利用して、ユーザ端末１０_１の認証に関する情報のリカバリを要求することができるので、利便性に優れたリカバリをユーザに提供することができる。

また、認証サーバ１００は、公開鍵Ｋ５１を用いて検証された署名により認証されるユーザが、公開鍵Ｋ１１を用いて検証される署名により認証されるユーザと同一のユーザである場合に、ユーザ端末１０に係る要求部１６５によって要求されたリカバリを実行する実行部１３４をさらに備える。

このように、リカバリシステム１では、代理装置５０に対応する公開鍵Ｋ５１で検証される情報と、ユーザ端末１０_１がユーザを認証した場合に検証に用いられる公開鍵Ｋ１１との対応付けに基づいて、ユーザ端末１０_１に関する情報のリカバリをする。これにより、リカバリシステム１は、認証サーバ１００に対する認証処理に基づいて、リカバリする情報を的確に特定できるため、確実なリカバリ処理を行うことができる。

また、実行部１３４は、代理装置５０の信頼性に応じて、要求部１６５から要求されたリカバリを実行するか否かを判定する。

このように、リカバリシステム１では、ユーザ端末１０_１の認証を代理する装置の信頼性に応じて、リカバリの実行を決定できる。これにより、リカバリシステム１は、例えば、認証サーバ１００とユーザ端末１０_１との間では認証強度の高い認証が行われていたにもかかわらず、代理装置５０による認証処理の強度が低い状態で実行されることにより、安全性の確保されないリカバリが行われることを防止できる。すなわち、リカバリシステム１によれば、認証サーバ１００とユーザ端末１０_１との間で行われていたような認証方式と同程度の信頼性がなければ、代理装置５０からの認証処理によってユーザが特定されたとしても、かかる認証を認めないことができる。このため、リカバリシステム１によれば、リカバリの安全性が確保できる。

また、送信部１６６は、ユーザの認証に用いる情報として、少なくとも二種類以上の情報を送信する。認証制御部１６３は、代理装置５０にユーザの認証を実行させる場合に、少なくとも二種類以上の情報に基づいて、ユーザの本人性を認証させる。

このように、リカバリシステム１では、代理装置５０の認証に際して、複数の判定要素を用いる、いわゆる多要素認証を行わせることができる。これにより、代理装置５０による認証処理の強度が確保できるため、リカバリシステム１によれば、リカバリの安全性が確保できる。

また、送信部１６６は、有線方式、又は、近距離無線通信方式を用いて、代理装置５０にユーザの認証に用いる情報を送信する。

このように、リカバリシステム１では、ユーザ端末１０と代理装置５０との間の通信を、有線方式、又は、近距離無線通信方式に限定することもできる。もともと、認証サーバ１００と、ユーザ端末１０_１との間で行われている認証においては、ユーザ端末１０_１が内部に備える認証器により認証が行われる。リカバリシステム１では、ユーザ端末１０と代理装置５０との間の通信を、有線方式、又は、近距離無線通信方式に限定することで、認証に用いる情報のネットワークへの流出が防止でき、認証サーバ１００とユーザ端末１０_１との間で行われていた認証と同程度の強度が確保できる。すなわち、リカバリシステム１によれば、安全性の確保されたリカバリを行うことができる。

また、要求部１６５は、公開鍵Ｋ１１に関連する情報として、公開鍵Ｋ１１によって検証される署名により特定されるユーザが所定のサービスで利用中のアカウントに関する情報のリカバリを要求する。

このように、リカバリシステム１によれば、ユーザは、ユーザ端末１０_１が認証サーバ１００に認証されることで利用可能であったアカウント等の情報について、リカバリを要求できる。すなわち、リカバリシステム１によれば、ユーザにとって利便性のよいリカバリを実行することができる。

また、認証制御部１６３は、所定の認証装置として、ユーザが利用する他の端末装置や、ユーザの関係者が利用する端末装置である家族端末３０や友人端末３５、所定の事業者によって営業される店舗に設置される端末装置である店舗端末４０、ネットワークを介して利用可能なクラウド上にある所定のサーバであるクラウドサーバ４５のいずれかに、ユーザの本人性の認証を実行させてもよい。

このように、リカバリシステム１では、ユーザ端末１０_１に代理する認証器として、様々な認証器をユーザが選択することができる。このため、リカバリシステム１は、ユーザにとって柔軟でユーザビリティに優れたリカバリ処理を提供することができる。

なお、リカバリシステム１において、ユーザ端末１０_１とユーザ端末１０_２は、同一の端末装置であってもよい。

例えば、ユーザ端末１０_１において、何らかの理由で秘密鍵Ｋ１０へのアクセス権を失う場合や、ユーザ端末１０_１が備える認証器を利用できなくなる場合も想定される。この場合、ユーザ端末１０_１が備える要求部１６５によってリカバリを要求したり、認証制御部１６３によって代理装置５０による認証処理を実行させたりすることができる。このように、リカバリシステム１によれば、柔軟なリカバリ処理を行うことができる。

また、リカバリシステム１は、以下のような構成により実現されてもよい。すなわち、リカバリシステム１は、第１の鍵（例えば、公開鍵Ｋ１１）とは異なる第２の鍵（例えば、秘密鍵Ｋ５０）を用いて、所定の認証手段（例えば、代理装置５０）によるユーザの認証の結果に付される署名の生成を制御する生成部（例えば、生成部１６４）を備える。また、リカバリシステム１は、第１の鍵と、第２の鍵を用いて生成された署名を検証するために用いられる第３の鍵と、が対応付けられている場合に、当該第２の鍵を用いて生成された署名を当該第３の鍵を用いて検証した検証結果に基づいて、当該第１の鍵に関する情報のリカバリを実行する実行部（例えば、実行部１３４）を備える。また、リカバリシステム１は、第１の鍵と第３の鍵とを対応付けて記憶する記憶部（例えば、リカバリ情報記憶部１２２）を備えていてもよい。また、この場合、生成部１６４は、第１の鍵を用いて検証される署名が生成される際と同じ認証プロトコルに従って、第２の鍵を用いて、所定の認証手段によるユーザの認証の結果に付される署名を生成してもよい。

このように、リカバリシステム１は、鍵の対応付けを行うことによって、生成部で生成された署名が所定の鍵で検証された場合に、その鍵と対応付けられている鍵に関する情報をリカバリすることができる。かかる構成によって、リカバリシステム１は、利便性に優れたリカバリをユーザに提供することができる。また、リカバリシステム１によれば、リカバリ用の認証手段に対しても、第１の鍵を用いる場合と同じ認証プロトコルを用いて処理を行うため、第１の鍵を用いる場合と同様の認証強度が確保された認証を経ることができ、安全性の高いリカバリを行うことができる。

以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、生成部は、生成手段や生成回路に読み替えることができる。

１ リカバリシステム
１０ ユーザ端末
２０ クライアント
３０ 家族端末
３５ 友人端末
４０ 店舗端末
４５ クラウドサーバ
５０ 代理装置
１００ 認証サーバ

Claims (16)

1. 第１の端末装置と、第２の端末装置と、認証サーバとを含むリカバリシステムであって、
   前記第１の端末装置は、
   前記第１の端末装置が生成する署名の検証に用いられる第１の鍵を前記認証サーバに送信するとともに、ユーザの本人性を認証する所定の認証装置に当該ユーザの認証に用いられる情報を送信する送信部と、
   前記認証装置による認証の結果への署名の生成に用いられる第２の鍵を、当該認証装置内に登録させるとともに、前記第２の鍵を用いて生成された署名を検証するために用いられる第３の鍵を、当該署名を検証する認証サーバ内に登録させる登録部と、を備え、
   前記認証サーバは、
   前記第１の鍵と前記第３の鍵とを対応付けて記憶する記憶部を備え、
   前記第２の端末装置は、
   前記認証装置に前記ユーザの認証を実行させ、当該認証の結果を前記認証サーバに送信させる認証制御部と、
   前記認証制御部によって送信された認証の結果に付された署名が、前記３の鍵を用いて前記認証サーバによって検証される場合に、前記第１の鍵に関連する情報のリカバリを要求する要求部と、
   を備えたことを特徴とするリカバリシステム。
2. 前記認証サーバは、
   前記第３の鍵を用いて検証された署名により認証されるユーザが、前記第１の鍵を用いて検証される署名により認証されるユーザと同一のユーザである場合に、前記要求部によって要求されたリカバリを実行する実行部、
   をさらに備えたことを特徴とする請求項１に記載のリカバリシステム。
3. 前記実行部は、
   前記認証装置の信頼性に応じて、前記要求部から要求されたリカバリを実行するか否かを判定する、
   ことを特徴とする請求項２に記載のリカバリシステム。
4. 前記送信部は、
   前記ユーザの認証に用いられる情報として、少なくとも二種類以上の情報を送信し、
   前記認証制御部は、
   前記認証装置に前記ユーザの認証を実行させる場合に、少なくとも二種類以上の情報に基づいて、前記ユーザの本人性を認証させる、
   ことを特徴とする請求項１〜３のいずれか一つに記載のリカバリシステム。
5. 前記送信部は、
   有線方式、又は、近距離無線通信方式を用いて、前記認証装置に前記ユーザの認証に用いられる情報を送信する、
   ことを特徴とする請求項１〜４のいずれか一つに記載のリカバリシステム。
6. 前記要求部は、
   前記第１の鍵に関連する情報として、当該第１の鍵によって検証される署名により特定される前記ユーザが所定のサービスで利用中のアカウントに関する情報のリカバリを要求する、
   ことを特徴とする請求項１〜５のいずれか一つに記載のリカバリシステム。
7. 前記認証制御部は、
   前記所定の認証装置として、前記ユーザが利用する他の端末装置、当該ユーザの関係者が利用する端末装置、所定の事業者によって営業される店舗に設置される端末装置、ネットワークを介して利用可能なクラウド上にある所定のサーバのいずれかに、当該ユーザの本人性の認証を実行させる、
   ことを特徴とする請求項１〜６のいずれか一つに記載のリカバリシステム。
8. 前記第１の端末装置と前記第２の端末装置は、同一の端末装置である、
   ことを特徴とする請求項１〜７のいずれか一つに記載のリカバリシステム。
9. 第１の鍵とは異なる第２の鍵を用いて、所定の認証手段によるユーザの認証の結果に付される署名の生成を制御する生成部と、
   前記第１の鍵と、前記第２の鍵を用いて生成された署名を検証するために用いられる第３の鍵と、が対応付けられている場合に、当該第２の鍵を用いて生成された署名を当該第３の鍵を用いて検証した検証結果に基づいて、当該第１の鍵に関する情報のリカバリを実行する実行部と、
   を備えたことを特徴とするリカバリシステム。
10. 前記実行部は、
    前記第３の鍵を用いて検証された署名により認証されるユーザが、前記第１の鍵を用いて検証される署名により認証されるユーザと同一のユーザである場合に、当該第１の鍵に関する情報のリカバリを実行する、
    ことを特徴とする請求項９に記載のリカバリシステム。
11. 前記第１の鍵と前記第３の鍵とを対応付けて記憶する記憶部、
    をさらに備えることを特徴とする請求項９又は１０に記載のリカバリシステム。
12. 前記生成部は、
    前記第１の鍵を用いて検証される署名が生成される際と同じ認証プロトコルに従って、前記第２の鍵を用いて、所定の認証手段によるユーザの認証の結果に付される署名を生成する、
    ことを特徴とする請求項９〜１１のいずれか一つに記載のリカバリシステム。
13. 端末装置が生成した署名を検証する第１の鍵と、当該端末装置を利用するユーザの本人性を認証する所定の認証装置が生成した署名を検証する第２の鍵とを対応付けて記憶する記憶部と、
    前記第１の鍵に関連する情報のリカバリの要求、及び、前記認証装置によるユーザの認証の結果を受信する受信部と、
    前記認証装置によるユーザの認証の結果に付された署名であって、前記第２の鍵を用いて検証される署名が、前記第１の鍵を用いて検証される署名と同一のユーザを認証したことを示す署名である場合に、前記受信部によって受信された要求に対応するリカバリを実行する実行部と、
    を備えたことを特徴とするサーバ装置。
14. 端末装置が生成する署名の検証に用いられる第１の鍵を認証サーバに送信するとともに、ユーザの本人性を認証する所定の認証装置に当該ユーザの認証に用いる情報を送信する送信部と、
    前記認証装置による認証の結果への署名の生成に用いられる第２の鍵を、当該認証装置内に登録させるとともに、前記第１の鍵を用いて生成された署名を検証するために用いられる第３の鍵を、当該署名を検証する認証サーバ内に登録させる登録部と、を備え、
    前記登録部は、
    前記第１の鍵と前記第３の鍵とを対応付けて前記認証サーバに登録させる、
    ことを特徴とする端末装置。
15. コンピュータが実行するリカバリ方法であって、
    第１の端末装置が生成する署名の検証に用いられる第１の鍵を認証サーバに送信するとともに、ユーザの本人性を認証する所定の認証装置に当該ユーザの認証に用いる情報を送信する送信工程と、
    前記認証装置による認証の結果への署名の生成に用いられる第２の鍵を、当該認証装置内に登録させるとともに、前記第２の鍵を用いて生成された署名を検証するために用いられる第３の鍵を、当該署名を検証する認証サーバ内に登録させる登録工程と、
    前記第１の鍵と前記第３の鍵とを対応付けて所定の記憶部に記憶する記憶工程と、
    前記認証装置に前記ユーザの認証を実行させ、当該認証の結果を前記認証サーバに送信させる認証制御工程と、
    前記認証制御工程によって送信された認証の結果に付された署名が、前記第３の鍵を用いて前記認証サーバによって検証される場合に、前記第１の鍵に関連する情報のリカバリを要求する要求工程と、
    を含んだことを特徴とするリカバリ方法。
16. 第１の端末装置が生成する署名の検証に用いられる第１の鍵を認証サーバに送信するとともに、ユーザの本人性を認証する所定の認証装置に当該ユーザの認証に用いる情報を送信する送信手順と、
    前記認証装置による認証の結果への署名の生成に用いられる第２の鍵を、当該認証装置内に登録させるとともに、前記第２の鍵を用いて生成された署名を検証するために用いられる第３の鍵を、当該署名を検証する認証サーバ内に登録させる登録手順と、
    前記第１の鍵と前記第３の鍵とを対応付けて所定の記憶部に記憶する記憶手順と、
    前記認証装置に前記ユーザの認証を実行させ、当該認証の結果を前記認証サーバに送信させる認証制御手順と、
    前記認証制御手順によって送信された認証の結果に付された署名が、前記第３の鍵を用いて前記認証サーバによって検証される場合に、前記第１の鍵に関連する情報のリカバリを要求する要求手順と、
    をコンピュータに実行させることを特徴とするリカバリプログラム。

Images