JP7351873B2 - 情報処理装置、情報処理方法および情報処理プログラム - Google Patents

Description

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

近年、利用者の認証を容易にするための技術が提案されている。例えば、ファイド（ＦＩＤＯ（登録商標））と呼ばれる認証技術が提案されている。

特開２０１５－２３０５２０号公報

しかしながら、ＦＩＤＯによる認証技術を容易に導入する点で改善の余地があった。具体的には、ＦＩＤＯによる認証技術を導入する場合、ＦＩＤＯに対応する機能を認証サーバに追加したり、改修したりする必要があり、ＦＩＤＯの導入に対する障壁となるおそれがあった。

本願は、上記に鑑みてなされたものであって、登録済の認証器が利用不能になったときのアカウントの復旧を可能とする情報処理装置、情報処理方法および情報処理プログラムを提供することを目的とする。

本願に係る情報処理装置は、ユーザを識別する識別子であるユーザＩＤと、別途配置されたＦＩＤＯ認証を行うための機能を有したＦＩＤＯサーバとの間で利用する前記ユーザの識別子である連携ＩＤとを紐付けて記憶して利用するユーザＩＤ管理部と、認証器のアテステーション情報、又は前記認証器によって生成されたアサーション情報を前記ＦＩＤＯサーバに送信して検証を依頼する送信部と、前記ＦＩＤＯサーバによって生成されるコンテキストであって、登録処理時のアテステーション情報の検証結果及び登録された認証手段に関する情報を含んだ認証登録コンテキスト、又は認証処理時のアサーション情報の検証結果及びユーザが行った認証手段の情報を含んだ認証結果コンテキストを読み取り、妥当性を検証するコンテキスト検証部と、前記ユーザが通常利用する第１認証器が使用不能になったときのバックアップ用の第２認証器の鍵ペアを生成するリカバリー鍵生成部と、前記第１認証器が使用不能になったときに、バックアップ用の前記第２認証器に権限を与えるための検証を行うリカバリー鍵検証部と、を備える。

実施形態の一態様によれば、登録済の認証器が利用不能になったときのアカウントの復旧を可能とすることができるという効果を奏する。

図１は、実施形態に係る認証システムの構成例を示す図である。 図２は、実施形態に係るＦＩＤＯサーバの構成例を示す図である。 図３は、実施形態に係る認証サーバの構成例を示す図である。 図４は、実施形態に係るサービス提供サーバの構成例を示す図である。 図５は、実施形態に係るユーザ端末の構成例を示す図である。 図６は、実施形態に係る公開鍵情報の一例を示す図である。 図７は、実施形態に係るユーザ情報の一例を示す図である。 図８は、実施形態に係る秘密鍵情報の一例を示す図である。 図９は、実施形態に係る認証システムによって実行される登録処理の一例を示すシーケンス図である。 図１０は、実施形態に係る認証システムによって実行される認証処理の一例を示すシーケンス図である。 図１１は、実施形態に係る認証システムによって実行される登録処理の一例を示すシーケンス図である。 図１２は、実施形態に係る認証システムによって実行される認証処理の一例を示すシーケンス図である。 図１３は、実施形態に係る認証システムによって実行される登録処理の一例を示すシーケンス図である。 図１４は、実施形態に係る認証システムによって実行される認証処理の一例を示すシーケンス図である。 図１５は、実施形態に係る認証システムによって実行されるリカバリー登録処理の一例を示すシーケンス図である。 図１６は、実施形態に係る認証システムによって実行されるリカバリー認証処理の一例を示すシーケンス図である。 図１７は、実施形態に係る認証システムによって実行されるリカバリー登録処理の一例を示すシーケンス図である。 図１８は、ハードウェア構成の一例を示す図である。

以下に、本願に係る情報処理装置、情報処理方法および情報処理プログラムを実施するための形態（以下、「実施形態」と記載する）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法および情報処理プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

（実施形態）
インターネット上の各種サービスは、典型的には、パスワードとＩＤ（Identifier）とを使用するリモート認証を採用している。リモート認証では、パスワードおよびＩＤが、インターネット等のネットワークを介して、クライアントデバイスから認証サーバに送信される。例えば、ユーザがサービスにログインする際に、ユーザは、パスワードと、ＩＤとを入力する。次に、認証サーバは、受信されたパスワードが認証サーバに記憶されたＩＤに関連付けられた適切なパスワードであるかを検証する。

リモート認証に関連する問題のうちの１つは、ユーザが複数のサービスの間で１つのパスワードを使いまわすことである。ユーザは、一般的に、電子メール、ＳＮＳ（Social Networking Service）、オンライン動画プラットフォーム、オンラインショッピング、オンラインバンキング等の、複数のサービスの複数のアカウントを有する。ユーザがサービスごとに異なるパスワードを設定した場合に、サービスごとに異なる複数のパスワードを覚えることは、ユーザにとって難しい場合がある。このため、ユーザは、複数のサービスにおいてパスワードを共通にすることがある。しかしながら、複数のサービスのうちの１つがパスワードを漏洩させた場合に、悪意のある者が、このパスワードを使用して複数のサービスのうちの他のサービスに、不正にアクセスする可能性がある。

上述したようなリモート認証に関連する問題を解決するために、ＦＩＤＯと呼ばれる認証技術が提案されている。ＦＩＤＯの認証形態では、ユーザの本人性が、スマートフォン等のユーザデバイスに内蔵または外付けされた認証器によって検証される。認証器の一例は、スマートフォンの生体認証機能である。このように、ＦＩＤＯ認証は、ローカル認証を採用している。

ローカル認証では、認証器は、認証器に保管された秘密鍵を使用することによって、本人性の検証結果に対して電子署名を行う。そして、電子署名付き検証結果が、インターネット上のサービスに、ユーザデバイスから送信される。インターネット上のサービスは、このサービスに登録された公開鍵を使用することによって、ユーザデバイスから送信された電子署名付き検証結果の妥当性を確認することができる。

上述のように、ＦＩＤＯ認証は、ユーザデバイスに内蔵または外付けされた認証器を使用したパスワードレス認証を可能にする。例えば、ユーザは、指紋等の生体情報をスマートフォンに入力することによって、ＦＩＤＯ認証を採用したサービスにおいて、パスワードレスログインを実行することができる。ＦＩＤＯ認証は、ユーザがパスワードを使用せずにサービスにログインすることを可能にするため、ＦＩＤＯ認証は、利便性や安全性の観点から好ましい。

しかしながら、サービス提供者がＦＩＤＯ認証を導入しようする場合、ＦＩＤＯ認証に対応する機能を認証サーバに追加したり、認証サーバを改修したりする必要がある。この場合、サービス提供者は、サービスの提供を一時的に停止させたり、ＦＩＤＯ認証が正常に動作するかの認定を受けたりする必要がある。このようなことが、ＦＩＤＯの導入に対する障壁となるおそれがあった。

また、ＦＩＤＯ認証では、ユーザのデバイス（認証器）を登録し、そのときにペアの公開鍵と秘密鍵を生成する。そして、秘密鍵を認証器に保管し、公開鍵をサーバに登録する。これによって、パスワードを用いることなく認証することができる。しかし、ユーザは、所有するデバイスを登録するタイプの認証（デバイスベース認証）であるため、デバイスを紛失したり、盗難されたり、故障したときに認証ができなくなってしまう。

そこで、本開示では、ＦＩＤＯ認証を行うための機能を有したＦＩＤＯサーバを認証サーバとは別に配置し、認証サーバがＦＩＤＯ認証の機能をＦＩＤＯサーバから呼び出せるようにした。また、認証器を有するデバイスの紛失、盗難、故障などにより登録済の認証器が利用不能になったとき、セキュアで柔軟なアカウントの復旧を可能とした。

図１は、実施形態に係る認証システムＳの構成例を示す図である。図１に示すように、実施形態に係る認証システムＳは、ＦＩＤＯサーバ１と、認証サーバ１０と、サービス提供サーバ２０と、ユーザ端末３０とを含む。ＦＩＤＯサーバ１と、認証サーバ１０と、サービス提供サーバ２０と、ユーザ端末３０とは、それぞれ不図示のネットワークと有線又は無線により接続される。ネットワークは、例えば、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）等のネットワークである。認証システムＳの構成要素は、ネットワークを介して互いに通信を行うことができる。なお、認証システムＳの構成要素の動作例については、図９以降で詳細に後述する。

ユーザ端末３０は、サービスを受けようとするユーザが扱う端末装置である。ユーザ端末３０は、スマートフォン、デスクトップ型ＰＣ、ノート型ＰＣ、タブレット型ＰＣ等の任意のタイプの端末装置を用いることができる。

また、ユーザ端末３０は、サービス提供サーバ２０にアクセスすることで、サービス提供サーバ２０が提供するサービスを利用することができる。本開示では、サービスを受けるためのユーザの登録および認証をＦＩＤＯ認証に行う。なお、登録処理および認証処理については、図９以降で詳細に後述する。

また、ユーザ端末３０は、ＦＩＤＯ認証のための認証器を有する。認証器は、例えば、ユーザの生体認証を行うための機能を有する。生体認証は、指紋、虹彩、顔等の生体情報を検知して行う。なお、認証器は、ユーザ端末３０に内蔵される場合に限らず、ユーザ端末３０に対してＵＳＢ（Universal Serial Bus）キー等で外付けされてもよい。また、認証器は、ユーザの本人性の検証結果に対して電子署名を行うための秘密鍵を保管している。この秘密鍵は、後述する公開鍵とともに鍵ペアとして認証器によって生成される。

サービス提供サーバ２０は、各種サービスを提供するサーバである。サービス提供サーバ２０が提供するサービスは、例えば、ブラウザや、インターネットショッピング、電子商店街等の電子商取引サービス等を含む。

サービス提供サーバ２０は、ユーザ端末３０がサービスへのアクセスを要求した場合に、ユーザの認証を認証サーバ１０に対して依頼し、認証サーバ１０によってユーザが認証された場合に、ユーザ端末３０によるサービスへのアクセスを承認する。

認証サーバ１０は、サービスへのアクセスを要求したユーザの本人性を認証するサーバである。認証サーバ１０は、ＦＩＤＯサーバ１の機能を利用することで、ＦＩＤＯ認証のための登録処理や、認証処理を実現する。具体的には、認証サーバ１０は、サービスにユーザを登録する登録処理において、ＦＩＤＯ認証に必要な鍵ペアを認証器に生成させるためのメッセージ作成をＦＩＤＯサーバ１に依頼したり、認証器のアテステーション情報の検証や、認証器から送信されるアサーション情報の検証をＦＩＤＯサーバ１に依頼する。

また、図１に示すように、認証サーバ１０は、ユーザＩＤ管理機能と、認証に関するコンテキスト読み取り・検証機能と、アサーション送信機能と、リカバリー鍵生成機能と、リカバリー鍵検証機能とを有する。

ユーザＩＤ管理機能とは、ユーザを識別する識別子であるユーザＩＤと、ＦＩＤＯサーバ１および認証サーバ１０の間で利用するユーザの識別子である連携ＩＤとを紐付けて記憶し、利用する機能である。

認証に関するコンテキスト読み取り・検証機能とは、ＦＩＤＯサーバ１によって生成される認証登録コンテキストや、認証結果コンテキストを読み取り、妥当性を検証する機能である。認証登録コンテキストは、登録処理時のアテステーション情報の検証結果や、登録された認証手段（生体認証等）に関する情報を含んだコンテキストである。認証結果コンテキストは、認証処理時のアサーション情報の検証結果や、ユーザが行った認証手段の情報等を含んだコンテキストである。

アサーション送信機能とは、認証器によって生成されたアサーション情報をＦＩＤＯサーバ１へ送信する機能である。アサーション情報とは、秘密鍵を用いて、認証器の認証結果に署名した情報である。具体的には、アサーション情報とは、署名付き認証結果の証明書である。

リカバリー鍵生成機能とは、通常利用する第１認証器に対して、第１認証器が使用不能になったときのバックアップ用の第２認証器の鍵ペアを生成する機能である。

リカバリー鍵検証機能とは、第１認証器が使用不能になったときに、バックアップ用の第２認証器に権限を与えるための検証を行う機能である。

ＦＩＤＯサーバ１は、ＦＩＤＯ認証に関する処理を行う情報処理装置である。ＦＩＤＯサーバ１は、認証サーバ１０と論理的に分離しており、同一ドメイン、あるいは、別ドメインに設置される。

図１に示すように、ＦＩＤＯサーバ１は、ＦＩＤＯメッセージ生成・検証機能と、認証に関するコンテキスト生成・送信機能と、連携ＩＤ管理機能と、リカバリー鍵生成機能とを有する。

ＦＩＤＯメッセージ生成・検証機能とは、ＦＩＤＯ認証に関するメッセージを生成したり、検証したりする機能である。ＦＩＤＯ認証に関するメッセージは、例えば、クレデンシャル生成オプションメッセージ（鍵ペアの生成指示メッセージ）や、アテステーション情報に関するメッセージ、アサーション情報に関するメッセージである。

認証に関するコンテキスト生成・送信機能とは、上述した認証登録コンテキストや、認証結果コンテキストを生成し、認証サーバ１０へ送信する機能である。連携ＩＤ管理機能とは、認証器によって生成された公開鍵を連携ＩＤと紐付けて記憶し、利用する機能である。

リカバリー鍵生成機能とは、通常利用する第１認証器に対して、第１認証器が使用不能になったときのバックアップ用の第２認証器の鍵ペアを生成する機能である。

このように、認証システムＳでは、ＦＩＤＯ認証に関する機能をＦＩＤＯサーバ１として認証サーバ１０から分離することで、サービス提供者は、認証サーバ１０にＦＩＤＯ認証に関する機能を追加する必要が無い。さらに、サービス提供者は、ＦＩＤＯサーバ１と連携するための機能を認証サーバ１０に導入するだけでよいため、認証サーバ１０の改変を最小限に抑えることができる。すなわち、情報処理装置であるＦＩＤＯサーバ１によれば、ＦＩＤＯによる認証技術を容易に導入することができる。

次に、図２～図５を参照して、認証システムＳにおける各装置の構成例について説明する。

図２は、実施形態に係るＦＩＤＯサーバ１の構成例を示す図である。図２に示されるように、ＦＩＤＯサーバ１は、通信部２と、制御部３と、記憶部４とを有する。

通信部２は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。通信部２は、有線または無線によりネットワーク網と接続される。

制御部３は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等のプロセッサによって、ＦＩＤＯサーバ１内部の記憶装置に記憶されている各種プログラム（情報処理プログラムの一例に相当）がＲＡＭ等を作業領域として実行されることにより実現される。また、制御部３は、コントローラ（controller）であり、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＧＰＧＰＵ（General Purpose Graphic Processing Unit）等の集積回路により実現されてもよい。

記憶部４は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図２に示されるように、記憶部４は、公開鍵情報４Ａを有する。なお、公開鍵情報４Ａの詳細については、図６で後述する。

図３は、実施形態に係る認証サーバ１０の構成例を示す図である。図３に示されるように、認証サーバ１０は、通信部１１と、制御部１２と、記憶部１３とを有する。

通信部１１は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。通信部２は、有線または無線によりネットワーク網と接続される。

制御部１２は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等のプロセッサによって、ＦＩＤＯサーバ１内部の記憶装置に記憶されている各種プログラム（情報処理プログラムの一例に相当）がＲＡＭ等を作業領域として実行されることにより実現される。また、制御部１２は、コントローラ（controller）であり、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＧＰＧＰＵ（General Purpose Graphic Processing Unit）等の集積回路により実現されてもよい。

記憶部１３は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図３に示されるように、記憶部１３は、ユーザ情報１３Ａを有する。なお、ユーザ情報１３Ａの詳細については、図７で後述する。

図４は、実施形態に係るサービス提供サーバ２０の構成例を示す図である。図４に示されるように、サービス提供サーバ２０は、通信部２１と、制御部２２と、記憶部２３とを有する。

通信部２１は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。通信部２は、有線または無線によりネットワーク網と接続される。

制御部２２は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等のプロセッサによって、ＦＩＤＯサーバ１内部の記憶装置に記憶されている各種プログラム（情報処理プログラムの一例に相当）がＲＡＭ等を作業領域として実行されることにより実現される。また、制御部２２は、コントローラ（controller）であり、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＧＰＧＰＵ（General Purpose Graphic Processing Unit）等の集積回路により実現されてもよい。

記憶部２３は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。

図５は、実施形態に係るユーザ端末３０の構成例を示す図である。図５に示されるように、ユーザ端末３０は、通信部３１と、制御部３２と、記憶部３３とを有する。

通信部３１は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。通信部２は、有線または無線によりネットワーク網と接続される。

制御部３２は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）等のプロセッサによって、ＦＩＤＯサーバ１内部の記憶装置に記憶されている各種プログラム（情報処理プログラムの一例に相当）がＲＡＭ等を作業領域として実行されることにより実現される。また、制御部３２は、コントローラ（controller）であり、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＧＰＧＰＵ（General Purpose Graphic Processing Unit）等の集積回路により実現されてもよい。

記憶部３３は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図５に示されるように、記憶部３３は、秘密鍵情報３３Ａを有する。なお、秘密鍵情報３３Ａの詳細については、図８で後述する。

（公開鍵情報４Ａ）
図６は、実施形態に係る公開鍵情報４Ａの一例を示す図である。公開鍵情報４Ａは、上述したように、ＦＩＤＯサーバ１の記憶部４に記憶される情報であり、認証器によって生成された公開鍵の情報を含む。

図６の例では、公開鍵情報４Ａは、「連携ＩＤ」、「認証サーバ」、「ユーザＩＤ」および「公開鍵」等の項目を有する。

「連携ＩＤ」は、連携している認証サーバ１０との間で利用するユーザの識別子である。「認証サーバ」は、連携している認証サーバ１０を識別する情報である。「ユーザＩＤ」は、認証サーバ１０によって発行されたユーザを識別する識別子である。「公開鍵」は、公開鍵の情報である。

（ユーザ情報１３Ａ）
図７は、実施形態に係るユーザ情報１３Ａの一例を示す図である。ユーザ情報１３Ａは、上述したように、認証サーバ１０の記憶部１３に記憶される情報であり、サービスを受けるための登録処理が完了したユーザに関する情報を含む。

図７の例では、ユーザ情報１３Ａは、「ユーザＩＤ」、「連携ＩＤ」、「属性情報」および「認証手段」等の項目を有する。

「ユーザＩＤ」は、ユーザを識別する識別子である。「連携ＩＤ」は、連携しているＦＩＤＯサーバ１との間で利用するユーザの識別子である。「属性情報」は、ユーザの属性に関する情報である。「認証手段」は、認証器による認証手段の情報である。

（秘密鍵情報３３Ａ）
図８は、実施形態に係る秘密鍵情報３３Ａの一例を示す図である。秘密鍵情報３３Ａは、上述したように、ユーザ端末３０の記憶部３３に記憶される情報であり、認証器によって生成された秘密鍵の情報を含む。

図８の例では、秘密鍵情報３３Ａは、「サービス」、「認証サーバ」および「秘密鍵」等の項目を有する。

「サービス」は、認証を受けるサービスを識別する情報である。「認証サーバ」は、認証サーバ１０を識別する情報である。「秘密鍵」は、秘密鍵の情報である。

次に、図９～図１４を用いて、認証システムＳの動作例について説明する。なお、以下では、図９および図１０を用いて、ＦＩＤＯサーバ１および認証サーバ１０が同一ドメインに配置される場合の動作例を説明し、図１１～図１４を用いて、ＦＩＤＯサーバ１および認証サーバ１０が別のドメインに配置される場合の動作例を説明する。

まず、図９および図１０を用いて、ＦＩＤＯサーバ１および認証サーバ１０が同一ドメインに配置される場合の動作例を説明する。言い換えれば、ＦＩＤＯサーバ１は認証サーバ１０のバックエンドのような位置づけで配置される。

〔同一ドメイン時の登録処理〕
まず、図９を参照して、実施形態に係る認証システムＳにおけるユーザの登録処理について説明する。図９は、実施形態に係る認証システムＳによって実行される登録処理の一例を示すシーケンス図である。なお、図９では、説明の便宜上、ユーザ端末３０および認証器を分けて示している。

図９に示す登録処理とは、認証が必要となるサービスに対してユーザの本人性を登録する処理である。図９に示すように、まず、ユーザ端末３０は、サービス提供サーバ２０に対して登録要求を送信する（ステップＳ１）。

つづいて、サービス提供サーバ２０は、認証サーバ１０に対してクレデンシャル生成要求を送信する（ステップＳ２）。クレデンシャル生成要求とは、認証器に鍵ペアを生成させることを要求することである。

つづいて、認証サーバ１０は、取得したクレデンシャル生成要求をＦＩＤＯサーバ１へ送信する（ステップＳ３）。つづいて、ＦＩＤＯサーバ１は、クレデンシャル生成要求に基づいて、鍵ペアの生成指示メッセージを作成する（ステップＳ４）。

つづいて、ＦＩＤＯサーバ１は、生成指示メッセージを認証サーバ１０へ送信する（ステップＳ５）。

つづいて、認証サーバ１０は、鍵ペアの生成指示メッセージをサービス提供サーバ２０へ送信する（ステップＳ６）。

つづいて、サービス提供サーバ２０は、鍵ペアの生成指示メッセージを、認証器に対して送信する（ステップＳ７）。つまり、ステップＳ１～Ｓ７において、制御部３は、ＦＩＤＯ認証ための認証器を有するユーザ端末３０から認証サーバ１０に送信されたＦＩＤＯ認証のための鍵ペアの生成要求を認証サーバ１０から取得し、生成要求に基づいて認証器に鍵ペアを生成させる生成指示を生成し、生成指示を認証サーバ１０を介して認証器へ通知する。すなわち、認証サーバ１０は、ＦＩＤＯ認証に関するメッセージ（生成指示や後述する取得指示）生成機能を有していないため、ＦＩＤＯ認証に関するメッセージ生成機能を有するＦＩＤＯサーバ１へメッセージ生成を依頼する。これにより、ＦＩＤＯ認証に関するメッセージ生成機能を認証サーバ１０に導入する必要がないため、ＦＩＤＯによる認証技術を容易に導入することができる。

つづいて、認証器は、ユーザ検証要求を送信する（ステップＳ８）。ユーザ検証要求は、ユーザに対して認証器による生体情報等の入力を要求することである。

つづいて、ユーザ端末３０は、ユーザの操作により認証器に対して生体情報等を入力する（ステップＳ９）。

つづいて、認証器は、鍵ペア（秘密鍵および公開鍵）を生成し（ステップＳ１０）、公開鍵をサービス提供サーバ２０へ送信する（ステップＳ１１）。

つづいて、サービス提供サーバ２０は、アテステーション情報およびユーザ情報（生体情報および公開鍵）を認証サーバ１０へ送信する（ステップＳ１２）。なお、サービス提供サーバ２０は、ステップＳ１２において、ユーザから同意を得て、ユーザに関する付加情報を送信してもよい。付加情報は、例えば、ユーザの位置情報（ユーザ端末３０の位置情報）を含む。また、付加情報は、ユーザの行動情報や、属性情報等が含まれてもよい。

つまり、ＦＩＤＯサーバ１の制御部３は、アテステーション情報とともに、付加情報を認証サーバ１０を介して取得する。

つづいて、認証サーバ１０は、アテステーション情報およびユーザ情報（生体情報および公開鍵）をＦＩＤＯサーバ１へ送信する（ステップＳ１３）。

つづいて、ＦＩＤＯサーバ１は、アテステーション情報の検証、連携ＩＤの付与、公開鍵の登録を行うとともに、アテステーション情報の検証結果に基づいてユーザの登録可否を示す認証登録コンテキストを生成する（ステップＳ１４）。

つづいて、ＦＩＤＯサーバ１は、認証登録コンテキストおよび連携ＩＤを認証サーバ１０へ送信する（ステップＳ１５）。つまり、ステップＳ１０～Ｓ１５において、制御部３は、生成指示に従って認証器で生成された鍵ペアのうち、公開鍵を認証サーバ１０を介して取得し、取得した公開鍵を連携ＩＤと紐付けて記憶するとともに、連携ＩＤを認証サーバ１０へ通知する。また、制御部３は、公開鍵を取得する際に、認証器のアテステーション情報を認証サーバ１０を介して取得し、アテステーション情報の検証結果に基づいて、ユーザの登録可否を示す認証登録コンテキストを生成して認証サーバ１０へ通知する。なお、ＦＩＤＯサーバ１は、付加情報を取得した場合には、公開鍵および連携ＩＤに付加情報を紐付けて記憶する。つまり、認証サーバ１０は、アテステーション情報や後述するアサーション情報の検証機能（アテステーション情報やアサーション情報の読取機能含む）を有していないため、アテステーション情報やアサーション情報の検証機能を有するＦＩＤＯサーバ１へアテステーション情報やアサーション情報の検証を依頼する。これにより、アテステーション情報やアサーション情報の検証機能を認証サーバ１０に導入する必要がないため、ＦＩＤＯによる認証技術を容易に導入することができる。

つづいて、認証サーバ１０は、認証登録コンテキストの検証および連携ＩＤをユーザＩＤに紐付けて保管する（ステップＳ１６）。

つづいて、認証サーバ１０は、認証登録コンテキストの検証の結果、問題無ければ、クレデンシャル生成応答をサービス提供サーバ２０へ送信する（ステップＳ１７）。つづいて、サービス提供サーバ２０は、登録が完了した旨を示す登録応答をユーザ端末３０へ送信する（ステップＳ１８）。

〔同一ドメイン時の認証処理〕
次に、図１０を参照して、実施形態に係る認証システムＳにおけるユーザの認証処理について説明する。図１０は、実施形態に係る認証システムＳによって実行される認証処理の一例を示すシーケンス図である。

図１０に示す認証処理とは、本人性を登録済のサービスに対してユーザがアクセス（あるいはログイン）を要求する場合に、ユーザの本人性を確認してアクセス（ログイン）を承認する処理である。図１０に示すように、まず、ユーザ端末３０は、サービス提供サーバ２０に対してアクセス（またはログイン）要求を送信する（ステップＳ１０１）。

つづいて、サービス提供サーバ２０は、認証サーバ１０に対してクレデンシャル取得要求を送信する（ステップＳ１０２）。クレデンシャル取得要求とは、ユーザＩＤの情報を含み、かかるユーザＩＤに対応するユーザの本人性の認証処理を依頼する要求（認証要求）である。

つづいて、認証サーバ１０は、取得したクレデンシャル取得要求を連携ＩＤとともにＦＩＤＯサーバ１へ送信する（ステップＳ１０３）。つづいて、ＦＩＤＯサーバ１は、クレデンシャル取得要求および連携ＩＤに基づいて、対応する公開鍵を選択し、選択した公開鍵に対応するユーザ情報（生体情報等の認証情報）の取得指示メッセージを作成する（ステップＳ１０４）。

つづいて、ＦＩＤＯサーバ１は、取得指示メッセージを認証サーバ１０へ送信する（ステップＳ１０５）。

つづいて、認証サーバ１０は、認証のためのユーザ情報の取得指示メッセージをサービス提供サーバ２０へ送信する（ステップＳ１０６）。

つづいて、サービス提供サーバ２０は、認証のためのユーザ情報の取得指示メッセージを、認証器に対して送信する（ステップＳ１０７）。つまり、ステップＳ１０１～Ｓ１０７において、制御部３は、ユーザ端末３０からアクセスを要求されたサービス提供サーバ２０から認証サーバ１０を介して対象のユーザに対応する連携ＩＤとともに認証要求を取得し、連携ＩＤに対応する認証情報の取得指示を生成し、取得指示を認証サーバ１０を介して認証器へ通知する。

つづいて、認証器は、取得指示に基づいてユーザ検証要求を送信する（ステップＳ１０８）。ユーザ検証要求は、ユーザに対して認証器による指定されたユーザ情報（生体情報等）の入力を要求することである。

つづいて、ユーザ端末３０は、ユーザの操作により認証器に対して生体情報等を入力する（ステップＳ１０９）。

つづいて、認証器は、入力された生体情報に基づいて、秘密鍵へアクセスし、アサーション情報を生成する（ステップＳ１１０）。具体的には、認証器は、入力された生体情報（認証情報）に、対応する秘密鍵を用いて署名した署名付き認証情報の証明書をアサーション情報として生成する。つづいて、認証器は、アサーション情報をサービス提供サーバ２０へ送信する（ステップＳ１１１）。

つづいて、サービス提供サーバ２０は、アサーション情報を認証サーバ１０へ送信する（ステップＳ１１２）。なお、サービス提供サーバ２０は、ステップＳ１１２において、ユーザから同意を得て、ユーザに関する付加情報を送信してもよい。付加情報は、例えば、ユーザの位置情報（ユーザ端末３０の位置情報）を含む。また、付加情報は、ユーザの行動情報や、属性情報等が含まれてもよい。

つまり、ＦＩＤＯサーバ１の制御部３は、アサーション情報とともに、付加情報を認証サーバ１０を介して取得する。

つづいて、認証サーバ１０は、アサーション情報をＦＩＤＯサーバ１へ送信する（ステップＳ１１３）。

つづいて、ＦＩＤＯサーバ１は、アサーション情報の検証を行うとともに、アサーション情報の検証結果に基づいてユーザの認証可否を示す認証結果コンテキストを生成する（ステップＳ１１４）。なお、ＦＩＤＯサーバ１は、アサーション情報と併せて付加情報を取得した場合には、付加情報の検証結果に基づく情報を認証結果コンテキストに含ませるようにする。

つづいて、ＦＩＤＯサーバ１は、認証結果コンテキストを認証サーバ１０へ送信する（ステップＳ１１５）。つまり、ステップＳ１１０～Ｓ１１５において、制御部３は、取得指示に従って認証器で取得された認証情報に秘密鍵を使って署名されたアサーション情報を認証サーバ１０を介して取得し、アサーション情報の検証結果に基づいて、ユーザの認証可否を示す認証結果コンテキストを生成して認証サーバ１０へ通知する。

つづいて、認証サーバ１０は、認証結果コンテキストの検証を行い、検証の結果、問題無ければ、サービスへのアクセス要求を承認し（ステップＳ１１６）、承認したことを示すクレデンシャル取得応答をサービス提供サーバ２０へ送信する（ステップＳ１１７）。つづいて、サービス提供サーバ２０は、アクセスが承認された旨を示すアクセス応答をユーザ端末３０へ送信するとともに（ステップＳ１１８）、ユーザ端末３０へサービスを提供する。

次に、図１１～図１４を用いて、ＦＩＤＯサーバ１および認証サーバ１０が別ドメインに配置される場合の動作例を説明する。ＦＩＤＯサーバ１および認証サーバ１０が別ドメインに配置される場合、認証サーバ１０は、サービス提供サーバ２０にリダイレクトさせることで各種要求をＦＩＤＯサーバ１へ送信することとなる。図１１および図１２では、このリダイレクト時に認証サーバ１０を明示しない場合の動作例を示し、図１３および図１４では、リダイレクト時に委任状によって認証サーバ１０を明示する場合の動作例を示す。

〔別ドメイン時の登録処理（その１）〕
まず、図１１を参照して、実施形態に係る認証システムＳにおけるユーザの登録処理について説明する。図１１は、実施形態に係る認証システムＳによって実行される登録処理の一例を示すシーケンス図である。

図１１に示すように、まず、ユーザ端末３０は、サービス提供サーバ２０に対して登録要求を送信する（ステップＳ２０１）。

つづいて、サービス提供サーバ２０は、認証サーバ１０に対してクレデンシャル生成要求を送信する（ステップＳ２０２）。

つづいて、認証サーバ１０は、取得したクレデンシャル生成要求をリダイレクト先（ＦＩＤＯサーバ１）の情報とともにサービス提供サーバ２０へ返信し（ステップＳ２０３）、サービス提供サーバ２０は、ＦＩＤＯサーバ１へクレデンシャル生成要求をリダイレクトする（ステップＳ２０４）。つづいて、ＦＩＤＯサーバ１は、クレデンシャル生成要求に基づいて、鍵ペアの生成指示メッセージを作成する（ステップＳ２０５）。

つづいて、ＦＩＤＯサーバ１は、鍵ペアの生成指示メッセージをサービス提供サーバ２０へ送信する（ステップＳ２０６）。

つづいて、サービス提供サーバ２０は、鍵ペアの生成指示メッセージを、認証器に対して送信する（ステップＳ２０７）。つづいて、認証器は、ユーザ検証要求を送信する（ステップＳ２０８）。つまり、ステップＳ２０１～Ｓ２０７において、制御部３は、ＦＩＤＯ認証ための認証器を有するユーザ端末３０から認証サーバ１０を介してサービス提供サーバ２０に送信されたＦＩＤＯ認証のための鍵ペアの生成要求をサービス提供サーバ２０から取得し、生成要求に基づいて認証器に鍵ペアを生成させる生成指示を生成し、生成指示をサービス提供サーバ２０を介して認証器へ通知する。すなわち、認証サーバ１０は、ＦＩＤＯ認証に関するメッセージ（生成指示や後述する取得指示）生成機能を有していないため、ＦＩＤＯ認証に関するメッセージ生成機能を有するＦＩＤＯサーバ１へサービス提供サーバ２０を介してメッセージ生成を依頼する。これにより、ＦＩＤＯ認証に関するメッセージ生成機能を認証サーバ１０に導入する必要がないため、ＦＩＤＯによる認証技術を容易に導入することができる。

つづいて、ユーザ端末３０は、ユーザの操作により認証器に対して生体情報等を入力する（ステップＳ２０９）。

つづいて、認証器は、鍵ペア（秘密鍵および公開鍵）を生成し（ステップＳ２１０）、公開鍵をサービス提供サーバ２０へ送信する（ステップＳ２１１）。

つづいて、サービス提供サーバ２０は、アテステーション情報およびユーザ情報（生体情報および公開鍵）をＦＩＤＯサーバ１へ送信する（ステップＳ２１２）。なお、サービス提供サーバ２０は、アテステーション情報とともに付加情報を送信してもよい。

つづいて、ＦＩＤＯサーバ１は、アテステーション情報の検証、連携ＩＤの付与、公開鍵の登録を行うとともに、アテステーション情報の検証結果に基づいて認証登録コンテキストを生成する（ステップＳ２１３）。

つづいて、ＦＩＤＯサーバ１は、認証登録コンテキストおよび連携ＩＤをリダイレクト先（認証サーバ１０）の情報とともにサービス提供サーバ２０へ送信（ステップＳ２１４）、サービス提供サーバ２０は、認証登録コンテキストおよび連携ＩＤを認証サーバ１０へリダイレクトする（ステップＳ２１５）。つまり、ステップＳ２１０～Ｓ２１５において、制御部３は、生成指示に従って認証器で生成された鍵ペアのうち、公開鍵をサービス提供サーバ２０を介して取得し、取得した公開鍵を連携ＩＤと紐付けて記憶するとともに、連携ＩＤをサービス提供サーバ２０を介して認証サーバ１０へ通知する。また、制御部３は、公開鍵を取得する際に、認証器のアテステーション情報をサービス提供サーバ２０を介して取得し、アテステーション情報の検証結果に基づいて、ユーザの登録可否を示す認証登録コンテキストを生成してサービス提供サーバ２０を介して認証サーバ１０へ通知する。つまり、認証サーバ１０は、アテステーション情報やアサーション情報の検証機能（アテステーション情報やアサーション情報の読取機能含む）を有していないため、アテステーション情報やアサーション情報の検証機能を有するＦＩＤＯサーバ１へサービス提供サーバ２０を介してアテステーション情報やアサーション情報の検証を依頼する。これにより、アテステーション情報やアサーション情報の検証機能を認証サーバ１０に導入する必要がないため、ＦＩＤＯによる認証技術を容易に導入することができる。

つづいて、認証サーバ１０は、認証登録コンテキストの検証および連携ＩＤをユーザＩＤに紐付けて保管する（ステップＳ２１６）。

つづいて、認証サーバ１０は、認証登録コンテキストの検証の結果、問題無ければ、クレデンシャル生成応答をサービス提供サーバ２０へ送信する（ステップＳ２１７）。つづいて、サービス提供サーバ２０は、登録が完了した旨を示す登録応答をユーザ端末３０へ送信する（ステップＳ２１８）。

〔別ドメイン時の認証処理（その１）〕
次に、図１２を参照して、実施形態に係る認証システムＳにおけるユーザの認証処理について説明する。図１２は、実施形態に係る認証システムＳによって実行される認証処理の一例を示すシーケンス図である。

図１１に示すように、まず、ユーザ端末３０は、サービス提供サーバ２０に対してアクセス（またはログイン）要求を送信する（ステップＳ３０１）。

つづいて、サービス提供サーバ２０は、認証サーバ１０に対してクレデンシャル取得要求を送信する（ステップＳ３０２）。このクレデンシャル取得要求には、ユーザＩＤの情報が含まれる。

つづいて、認証サーバ１０は、取得したクレデンシャル取得要求を連携ＩＤおよびリダイレクト先（ＦＩＤＯサーバ１）の情報とともにサービス提供サーバ２０へ返信し（ステップＳ３０３）、サービス提供サーバ２０は、クレデンシャル取得要求および連携ＩＤをＦＩＤＯサーバ１へリダイレクトする（ステップＳ３０４）。つづいて、ＦＩＤＯサーバ１は、クレデンシャル取得要求および連携ＩＤに基づいて、対応する公開鍵を選択し、選択した公開鍵に対応するユーザ情報（認証のための生体情報等）の取得指示メッセージを作成する（ステップＳ３０５）。

つづいて、ＦＩＤＯサーバ１は、取得指示メッセージをサービス提供サーバ２０へ送信する（ステップＳ３０６）。

つづいて、サービス提供サーバ２０は、認証のためのユーザ情報の取得指示メッセージを、認証器に対して送信する（ステップＳ３０７）。つまり、ステップＳ３０１～Ｓ３０７において、制御部３は、ユーザ端末３０からサービス提供サーバ２０に対してアクセスを要求された場合に、認証サーバ１０を介してサービス提供サーバ２０から対象のユーザに対応する連携ＩＤとともに認証要求を取得し、連携ＩＤに対応する認証情報の取得指示を生成し、取得指示をサービス提供サーバ２０を介して認証器へ通知する。

つづいて、認証器は、取得指示に基づいてユーザ検証要求を送信する（ステップＳ３０８）。つづいて、ユーザ端末３０は、ユーザの操作により認証器に対して生体情報等を入力する（ステップＳ３０９）。

つづいて、認証器は、入力された生体情報に基づいて、秘密鍵へアクセスし、アサーション情報を生成する（ステップＳ３１０）。具体的には、認証器は、入力された生体情報に基づいて、ユーザを認証して認証結果を生成するとともに、対応する秘密鍵を用いて認証結果に署名した署名付き認証結果の証明書をアサーション情報として生成する。つづいて、認証器は、アサーション情報をサービス提供サーバ２０へ送信する（ステップＳ３１１）。

つづいて、サービス提供サーバ２０は、アサーション情報をＦＩＤＯサーバ１へ送信する（ステップＳ３１２）。なお、サービス提供サーバ２０は、アサーション情報と併せて付加情報を送信してもよい。

つづいて、ＦＩＤＯサーバ１は、アサーション情報の検証を行うとともに、アサーション情報の検証結果に基づいて認証結果コンテキストを生成する（ステップＳ３１３）。

つづいて、ＦＩＤＯサーバ１は、認証結果コンテキストおよび連携ＩＤをリダイレクト先（認証サーバ１０）の情報とともにサービス提供サーバ２０へ送信し（ステップＳ３１４）、サービス提供サーバ２０は、認証結果コンテキストおよび連携ＩＤを認証サーバ１０へリダイレクトする（ステップＳ３１５）。つまり、ステップＳ３１０～Ｓ３１５において、制御部３は、取得指示に従って認証器で取得された認証情報に秘密鍵を使って署名されたアサーション情報をサービス提供サーバ２０を介して取得し、アサーション情報の検証結果に基づいて、ユーザの認証可否を示す認証結果コンテキストを生成してサービス提供サーバ２０を介して認証サーバ１０へ通知する。

つづいて、認証サーバ１０は、認証結果コンテキストの検証を行い、検証の結果、問題無ければ、サービスへのアクセス要求を承認し（ステップＳ３１６）、承認したことを示すクレデンシャル取得応答をサービス提供サーバ２０へ送信する（ステップＳ３１７）。つづいて、サービス提供サーバ２０は、アクセスが承認された旨を示すアクセス応答をユーザ端末３０へ送信するとともに（ステップＳ３１８）、ユーザ端末３０へサービスを提供する。

図１３および図１４を用いて、リダイレクト時に委任状によって認証サーバ１０を明示する場合の動作例について説明する。

〔別ドメイン時の登録処理（その２）〕
まず、図１３を参照して、実施形態に係る認証システムＳにおけるユーザの登録処理について説明する。図１３は、実施形態に係る認証システムＳによって実行される登録処理の一例を示すシーケンス図である。

図１３に示すように、まず、ユーザ端末３０は、サービス提供サーバ２０に対して登録要求を送信する（ステップＳ４０１）。

つづいて、サービス提供サーバ２０は、認証サーバ１０に対してクレデンシャル生成要求を送信する（ステップＳ４０２）。

つづいて、認証サーバ１０は、取得したクレデンシャル生成要求にＦＩＤＯサーバ１への委任状を添えて、リダイレクト先（ＦＩＤＯサーバ１）の情報とともにサービス提供サーバ２０へ返信し（ステップＳ４０３）、サービス提供サーバ２０は、ＦＩＤＯサーバ１へクレデンシャル生成要求をリダイレクトする（ステップＳ４０４）。この委任状は、ＦＩＤＯサーバ１に対してＦＩＤＯ認証の登録を委任することを明示的に示す情報であり、委任元である認証サーバ１０の情報を含む。つづいて、ＦＩＤＯサーバ１は、クレデンシャル生成要求に基づいて、鍵ペアの生成指示メッセージを作成する（ステップＳ４０５）。

つづいて、ＦＩＤＯサーバ１は、鍵ペアの生成指示メッセージをサービス提供サーバ２０へ送信する（ステップＳ４０６）。

つづいて、サービス提供サーバ２０は、鍵ペアの生成指示メッセージを、認証器に対して送信する（ステップＳ４０７）。つづいて、認証器は、ユーザ検証要求を送信する（ステップＳ４０８）。

つづいて、ユーザ端末３０は、ユーザの操作により認証器に対して生体情報等を入力する（ステップＳ４０９）。

つづいて、認証器は、鍵ペア（秘密鍵および公開鍵）を生成し（ステップＳ４１０）、公開鍵をサービス提供サーバ２０へ送信する（ステップＳ４１１）。

つづいて、サービス提供サーバ２０は、アテステーション情報およびユーザ情報（生体情報および公開鍵）をＦＩＤＯサーバ１へ送信する（ステップＳ４１２）。

つづいて、ＦＩＤＯサーバ１は、アテステーション情報の検証、連携ＩＤの付与、公開鍵の登録を行うとともに、アテステーション情報の検証結果に基づいて認証登録コンテキストを生成する（ステップＳ４１３）。

つづいて、ＦＩＤＯサーバ１は、認証登録コンテキストおよび連携ＩＤをリダイレクト先（認証サーバ１０）の情報とともにサービス提供サーバ２０へ送信（ステップＳ４１４）、サービス提供サーバ２０は、認証登録コンテキストおよび連携ＩＤを認証サーバ１０へリダイレクトする（ステップＳ４１５）。

つづいて、認証サーバ１０は、認証登録コンテキストの検証および連携ＩＤをユーザＩＤに紐付けて保管する（ステップＳ４１６）。

つづいて、認証サーバ１０は、認証登録コンテキストの検証の結果、問題無ければ、クレデンシャル生成応答をサービス提供サーバ２０へ送信する（ステップＳ４１７）。つづいて、サービス提供サーバ２０は、登録が完了した旨を示す登録応答をユーザ端末３０へ送信する（ステップＳ４１８）。

〔別ドメイン時の認証処理（その２）〕
次に、図１４を参照して、実施形態に係る認証システムＳにおけるユーザの認証処理について説明する。図１４は、実施形態に係る認証システムＳによって実行される認証処理の一例を示すシーケンス図である。

図１４に示すように、まず、ユーザ端末３０は、サービス提供サーバ２０に対してアクセス（またはログイン）要求を送信する（ステップＳ５０１）。

つづいて、サービス提供サーバ２０は、認証サーバ１０に対してクレデンシャル取得要求を送信する（ステップＳ５０２）。このクレデンシャル取得要求には、ユーザＩＤの情報が含まれる。

つづいて、認証サーバ１０は、取得したクレデンシャル取得要求を連携ＩＤおよびリダイレクト先（ＦＩＤＯサーバ１）の情報とともに、ＦＩＤＯサーバ１への委任状を添えて、サービス提供サーバ２０へ返信し（ステップＳ５０３）、サービス提供サーバ２０は、クレデンシャル取得要求および連携ＩＤをＦＩＤＯサーバ１へリダイレクトする（ステップＳ５０４）。この委任状は、ＦＩＤＯサーバ１に対してＦＩＤＯ認証の認証を委任することを明示的に示す情報であり、委任元である認証サーバ１０の情報を含む。つづいて、ＦＩＤＯサーバ１は、クレデンシャル取得要求および連携ＩＤに基づいて、対応する公開鍵を選択し、選択した公開鍵に対応するユーザ情報（認証のための生体情報等）の取得指示メッセージを作成する（ステップＳ５０５）。

つづいて、ＦＩＤＯサーバ１は、取得指示メッセージをサービス提供サーバ２０へ送信する（ステップＳ５０６）。

つづいて、サービス提供サーバ２０は、認証のためのユーザ情報の取得指示メッセージを、認証器に対して送信する（ステップＳ５０７）。

つづいて、認証器は、取得指示に基づいてユーザ検証要求を送信する（ステップＳ５０８）。つづいて、ユーザ端末３０は、ユーザの操作により認証器に対して生体情報等を入力する（ステップＳ５０９）。

つづいて、認証器は、入力された生体情報に基づいて、秘密鍵へアクセスし、アサーション情報を生成する（ステップＳ５１０）。具体的には、認証器は、入力された生体情報に基づいて、ユーザを認証して認証結果を生成するとともに、対応する秘密鍵を用いて認証結果に署名した署名付き認証結果の証明書をアサーション情報として生成する。つづいて、認証器は、アサーション情報をサービス提供サーバ２０へ送信する（ステップＳ５１１）。

つづいて、サービス提供サーバ２０は、アサーション情報をＦＩＤＯサーバ１へ送信する（ステップＳ５１２）。

つづいて、ＦＩＤＯサーバ１は、アサーション情報の検証を行うとともに、アサーション情報の検証結果に基づいて認証結果コンテキストを生成する（ステップＳ５１３）。

つづいて、ＦＩＤＯサーバ１は、認証結果コンテキストおよび連携ＩＤをリダイレクト先（認証サーバ１０）の情報とともにサービス提供サーバ２０へ送信し（ステップＳ５１４）、サービス提供サーバ２０は、認証結果コンテキストおよび連携ＩＤを認証サーバ１０へリダイレクトする（ステップＳ５１５）。

つづいて、認証サーバ１０は、認証結果コンテキストの検証を行い、検証の結果、問題無ければ、サービスへのアクセス要求を承認し（ステップＳ５１６）、承認したことを示すクレデンシャル取得応答をサービス提供サーバ２０へ送信する（ステップＳ５１７）。つづいて、サービス提供サーバ２０は、アクセスが承認された旨を示すアクセス応答をユーザ端末３０へ送信するとともに（ステップＳ５１８）、ユーザ端末３０へサービスを提供する。

ここで、図１５～図１７を用いて、認証システムＳにおけるリカバリーの動作例について説明する。なお、上述の説明では、ユーザ端末３０とＦＩＤＯサーバ１および認証サーバ１０との間にサービス提供サーバ２０が存在するが、図１５～図１７の説明では、サービス提供サーバ２０の記載および説明を省略している。また、以下では、図１５および図１６を用いて、ＦＩＤＯサーバ１および認証サーバ１０がリカバリーのための属性ベース署名用の秘密鍵を送付する場合の動作例を説明し、図１７を用いて、ＦＩＤＯサーバ１および認証サーバ１０がリカバリーのための属性ベース署名用の秘密鍵を生成するためのシードを送付する場合の動作例を説明する。

実施形態に係る認証システムＳは、通常使用する第１認証器に対してバックアップ用の第２認証器のリカバリー鍵ペアを生成する機能と、第１認証器を有するユーザ端末３０が利用不能であるときに第２認証器のリカバリー鍵ペアを検証する機能とを有する。そして、認証システムＳは、ＦＩＤＯ認証を導入したアカウントシステムにおいて、第１認証器の鍵ペアと第２認証器のリカバリー鍵ペアとの間に、属性ベース暗号技術を導入する。属性ベース暗号技術は、公開鍵暗号技術の一種であり、暗号文または鍵に属性を関連付け、特定の属性集合を持つユーザのみがリカバリーできる技術である。従来の公開鍵暗号方式では、秘密鍵の発行に応じて人数分の暗号処理が必要であった。しかし、属性ベース暗号では、ある１つの暗号文に対してリカバリー可能なユーザが複数存在できる。暗号文に、リカバリーできるユーザの情報（属性）を制御条件として組み込んで暗号化し、その属性（集合）を持っている人しか、暗号化データをリカバリーできなくする。

公開鍵暗号の応用として、公開鍵署名がある。公開鍵暗号では、公開鍵を使ってデータを暗号化し、その暗号化データを受け取った人は、公開鍵に対応する秘密鍵を使ってリカバリーする。秘密鍵がないとリカバリーすることができない。属性ベース暗号では、属性に合致する人しかリカバリーすることができない。一方、署名は、反対に、秘密鍵を使ってデータに署名し、受け取った人は、データの署名を公開鍵を使って検証する。属性ベース暗号に対応する署名は、属性ベース署名と呼んでおり、ＦＩＤＯ認証においても、公開鍵暗号における署名を検証することが基本である。認証システムＳは、属性ベース署名を応用する。

まず、図１５および図１６を用いて、ＦＩＤＯサーバ１および認証サーバ１０がリカバリーのための属性ベース署名用の秘密鍵を送付する場合の動作例を説明する。

〔リカバリー登録処理〕
ここで、図１５を参照して、実施形態に係る認証システムＳにおけるリカバリー登録処理について説明する。図１５は、実施形態に係る認証システムＳによって実行されるリカバリー登録処理の一例を示すシーケンス図である。なお、図１５では、利用中のユーザ端末３０の第１認証器と、バックアップ用のユーザ端末３０Ａの第２認証器とを示している。また、認証サーバ１０の処理は、ＦＩＤＯサーバ１の処理を含むものとする。

図１５に示すリカバリー登録処理とは、利用中のユーザ端末３０（第１認証器）の紛失時、盗難時、故障時などに、再認証するためのバックアップ用の第２認証器（ユーザ端末３０Ａ）を登録する処理である。図１５に示すように、まず、ユーザは、ユーザ端末３０を用いて、認証サーバ１０との間でＦＩＤＯ認証を行う（ステップＳ６０１）。このＦＩＤＯ認証は、例えば、図１０を用いて説明したユーザ認証処理により行う。

つづいて、ユーザは、ユーザ端末３０を用いて、認証サーバ１０に対してリカバリー要求を送信する（ステップＳ６０２）。リカバリー要求とは、第２認証器を第１認証器のバックアップ用の認証器として登録する要求することである。この場合、属性として、第２認証器の連携ＩＤを送信する。

但し、属性は、第２認証器の連携ＩＤに限定されるものではない。例えば、部長グループというように、人のグループに該当する情報を属性としてもよい。また、位置情報データ（時系列）セット、コンテキストデータセット、行動情報セットを属性としてもよい。また、属性は、属性証明書もあってよい。この場合、属性情報自体は、検証が必要なこともあるが、属性情報の検証を認証サーバ１０で実行してもよい。
側性としての位置情報の時系列データセットを機械学習し、所定の位置情報データセットが条件を満たす場合に、条件を満たしていることを検証したことを証明する位置情報証明書を認証サーバ１０に送付してもよい。

つづいて、認証サーバ１０は、取得したリカバリー要求の確認を第１認証器へ送信する（ステップＳ６０３）。ここで、認証サーバ１０は、第２認証器の連携ＩＤを第１認証器へ送信する。つづいて、第１認証器は、リカバリー要求の確認（第２認証器の連携ＩＤ）をユーザ端末３０へ送信する（ステップＳ６０４）。ユーザは、ユーザ端末３０を用いて、リカバリー要求の確認（ＦＩＤＯ認証）を行う（ステップＳ６０５）。

つづいて、ユーザは、ユーザ端末３０を用いて、リカバリー要求の確認の応答を第１認証器に送信する（ステップＳ６０６）。つづいて、第１認証器は、リカバリー要求の確認応答（リカバリー確認アサーション）を認証サーバ１０へ送信する（ステップＳ６０７）。

認証サーバ１０は、リカバリー確認応答に対して、マスター鍵およびリカバリー鍵ペア（公開鍵および公開鍵）を生成し、リカバリー公開鍵を登録する（ステップＳ６０８）。この場合、リカバリー鍵ペアは、属性ベース暗号に基づいて生成されたものである。

つづいて、認証サーバ１０は、リカバリー登録応答をユーザ端末３０へ送信する（ステップＳ６０９）。ユーザは、ユーザ端末３０に、例えば、ＵＳＢを介してバックアップ用のユーザ端末３０Ａを接続し、ユーザ端末３０とユーザ端末３０Ａとを通信可能な状態とする（ステップＳ６１０）。つづいて、ユーザは、ユーザ端末３０を用いて、リカバリー登録要求を第２認証器（ユーザ端末３０Ａ）へ送信する（ステップＳ６１１）。つづいて、第２認証器（ユーザ端末３０Ａ）は、リカバリー秘密鍵の生成要求を認証サーバ１０へ送信する（ステップＳ６１２）。

つづいて、認証サーバ１０は、リカバリー秘密鍵の生成要求に対する応答として、リカバリー秘密鍵を第２認証器へ送信する（ステップＳ６１３）。第２認証器は、リカバリー秘密鍵を登録して保管する（ステップＳ６１４）。つづいて、第２認証器は、リカバリー秘密鍵の登録が完了した旨を示す登録応答をユーザ端末３０へ送信する（ステップＳ６１５）。

〔リカバリー認証処理〕
次に、図１６を参照して、実施形態に係る認証システムＳにおけるリカバリー認証処理について説明する。図１６は、実施形態に係る認証システムＳによって実行されるリカバリー認証処理の一例を示すシーケンス図である。

図１６に示すリカバリー認証処理とは、第１認証器を有するユーザ端末３０の紛失時、盗難時、故障時した場合に、登録済の第２認証器を有するユーザ端末３０Ａを用いて認証する処理である。図１６に示すように、ユーザは、第１認証器を有するユーザ端末３０を紛失、盗難、故障してしまう（ステップＳ７０１）。すると、まず、ユーザは、バックアップ用のユーザ端末３０Ａを用いて、第２認証器に対してリカバリー実施要求を送信する（ステップＳ７０２）。リカバリー実施要求とは、第２認証器をリカバリー用の認証器として登録する要求することである。

つづいて、第２認証器は、リカバリー実施要求を認証サーバ１０へ送信する（ステップＳ７０３）。つづいて、認証サーバ１０は、認証器検証要求を第２認証器へ送信する（ステップＳ７０４）。第２認証器は、認証器確認要求をユーザ端末３０Ａへ送信する（ステップＳ７０５）。つづいて、ユーザは、第２認証器を認証（ＦＩＤＯ認証）する（ステップＳ７０６）。つついて、ユーザは、ユーザ端末３０Ａを用いて、認証器確認応答を第２認証器へ送信する（ステップＳ７０７）。第２認証器は、認証器確認応答に対するアサーションを作成し、アサーションにリカバリー秘密鍵で署名する（ステップＳ７０８）。

つづいて、第２認証器は、認証器検証応答（署名付きアサーション）を認証サーバ１０へ送信する（ステップＳ７０９）。つづいて、認証サーバ１０は、リカバリー秘密鍵での署名を検証し、第２認証器のリカバリー権限（アクセス制御）を確認する（ステップＳ７１０）。つづいて、認証サーバ１０は、リカバリー応答を第２認証器へ送信する（ステップＳ７１１）。

つづいて、第２認証器は、リカバリー実施応答をユーザ端末３０Ａへ送信する（ステップＳ７１２）。つづいて、ユーザは、ユーザ端末３０Ａを用いて、リカバリー後処理を第２認証器へ送信する（ステップＳ７１３）。第２認証器は、リカバリー後処理を認証サーバ１０へ送信する（ステップＳ７１４）。つづいて、認証サーバ１０は、リカバリー後処理として、例えば、第１認証器の公開鍵の削除などの処理を行う（ステップＳ７１５）。認証サーバ１０は、リカバリー後処理応答を第２認証器へ送信する（ステップＳ７１６）。第２認証器は、リカバリー後処理応答をユーザ端末３０Ａへ送信する（ステップＳ７１７）。

次に、図１７を用いて、ＦＩＤＯサーバ１および認証サーバ１０がリカバリーのための属性ベース署名用の秘密鍵を生成するためのシードを送付する場合の動作例を説明する。

〔リカバリー登録処理〕
ここで、図１７を参照して、実施形態に係る認証システムＳにおけるリカバリー登録処理について説明する。図１７は、実施形態に係る認証システムＳによって実行されるリカバリー登録処理の一例を示すシーケンス図である。

図１７に示すように、まず、ユーザは、ユーザ端末３０を用いて、認証サーバ１０との間でＦＩＤＯ認証を行う（ステップＳ８０１）。このＦＩＤＯ認証は、例えば、図１０を用いて説明したユーザ認証処理により行う。

つづいて、ユーザは、ユーザ端末３０を用いて、認証サーバ１０に対してシード登録要求を送信する（ステップＳ８０２）。シード登録要求とは、第２認証器を第１認証器のバックアップ用の認証器として登録する要求することである。この場合、属性として、第２認証器の連携ＩＤを送信する。

つづいて、認証サーバ１０は、取得したシード登録要求の確認を第１認証器へ送信する（ステップＳ８０３）。ここで、認証サーバ１０は、第２認証器の連携ＩＤを第１認証器へ送信する。つづいて、第１認証器は、リカバリー要求の確認（第２認証器の連携ＩＤ）をユーザ端末３０へ送信する（ステップＳ８０４）。ユーザは、ユーザ端末３０を用いて、リカバリー要求の確認（ＦＩＤＯ認証）を行う（ステップＳ８０５）。

つづいて、ユーザは、ユーザ端末３０を用いて、リカバリー要求の確認の応答を第１認証器に送信する（ステップＳ８０６）。つづいて、第１認証器は、リカバリー要求の確認応答に対してシードを生成するとともに、リカバリー鍵ペア（公開鍵および公開鍵）を生成する（ステップＳ８０７）。第１認証器は、リカバリー確認応答（リカバリー確認アサーションおよびシード）を認証サーバ１０へ送信する（ステップＳ８０８）。

認証サーバ１０は、リカバリー確認応答に対して、マスター鍵およびリカバリー鍵ペア（公開鍵および公開鍵）を生成し、シードを保管する（ステップＳ８０９）。この場合、リカバリー鍵ペアは、属性ベース暗号に基づいて生成されたものである。

つづいて、認証サーバ１０は、リカバリー登録応答（シードのＵＲＬ）をユーザ端末３０へ送信する（ステップＳ８１０）。ユーザは、ユーザ端末３０に、例えば、ＵＳＢを介してバックアップ用のユーザ端末３０Ａを接続し、ユーザ端末３０とユーザ端末３０Ａとを通信可能な状態とする（ステップＳ８１１）。つづいて、ユーザは、ユーザ端末３０を用いて、リカバリー登録要求（シードのＵＲＬ）を第２認証器へ送信する（ステップＳ８１２）。つづいて、第２認証器は、シード要求を認証サーバ１０へ送信する（ステップＳ８１３）。

つづいて、認証サーバ１０は、シード要求に対するシード応答として、シードおよび秘密鍵の作成方法を第２認証器へ送信する（ステップＳ８１４）。第２認証器は、シードからリカバリー秘密鍵を生成し、生成した秘密鍵を登録して保管する（ステップＳ８１５）。つづいて、第２認証器は、リカバリー秘密鍵の登録が完了した旨を示す登録応答をユーザ端末３０へ送信する（ステップＳ８１６）。

リカバリー認証処理は、図１６で説明したものと同様である。

上述したリカバリー登録処理およびリカバリー認証処理において、第１認証器のバックアップ用として１つの第２認証器を用意したが、複数の認証器を用意してもよい。また、認証サーバ１０が属性ベース暗号に基づいたリカバリー鍵の生成機能と検証機能を有するものとしたが、第１認証器がその機能を有していてもよく、別の装置がリカバリー鍵の生成機能と検証機能を有していてもよい。すなわち、認証サーバ１０から第１認証器を経由した第２認証器への秘密鍵の送信は、様々な方法が考えられる。例えば、第１認証器に直接に秘密鍵を送付し、第１認証器と第２認証器の間ではＱＲコード（登録商標）などの２次元コードや各種の通信機器を用いて情報を共有してもよい。また、認証サーバ１０に秘密鍵アクセス用のサービスのＵＲＬを第１認証器を経由して第２認証器に通知し、第２認証器がそのＵＲＬにアクセスして入手してもよい。また、ＤＨ法（Ｄｉｆｆｉｅ－Ｈｅｌｌｍａｎ鍵共有法）のような情報共有方法を用いてもよい。そして、グループ署名技術も代替技術として採用可能である。また、第２認証器が複数の秘密鍵を格納してもよい。

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

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

例えば、図２に示した記憶部４、図３に示した記憶部１３、図５に示した記憶部２３、図６に示した記憶部３３それぞれの一部又は全部は、各装置によって保持されるのではなく、ストレージサーバ等に保持されてもよい。この場合、各装置は、ストレージサーバにアクセスすることで、各種情報を取得する。

〔ハードウェア構成〕
また、上述してきた実施形態に係るＦＩＤＯサーバ１は、例えば図１８に示すような構成のコンピュータ１０００によって実現される。図１８は、ハードウェア構成の一例を示す図である。コンピュータ１０００は、出力装置１０１０、入力装置１０２０と接続され、演算装置１０３０、一次記憶装置１０４０、二次記憶装置１０５０、出力ＩＦ（Interface）１０６０、入力ＩＦ１０７０、ネットワークＩＦ１０８０がバス１０９０により接続された形態を有する。

演算装置１０３０は、一次記憶装置１０４０や二次記憶装置１０５０に格納されたプログラムや入力装置１０２０から読み出したプログラム等に基づいて動作し、各種の処理を実行する。一次記憶装置１０４０は、ＲＡＭ等、演算装置１０３０が各種の演算に用いるデータを一時的に記憶するメモリ装置である。また、二次記憶装置１０５０は、演算装置１０３０が各種の演算に用いるデータや、各種のデータベースが登録される記憶装置であり、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ等により実現される。

出力ＩＦ１０６０は、モニタやプリンタといった各種の情報を出力する出力装置１０１０に対し、出力対象となる情報を送信するためのインタフェースであり、例えば、ＵＳＢ（Universal Serial Bus）やＤＶＩ（Digital Visual Interface）、ＨＤＭＩ（登録商標）（High Definition Multimedia Interface）といった規格のコネクタにより実現される。また、入力ＩＦ１０７０は、マウス、キーボード、およびスキャナ等といった各種の入力装置１０２０から情報を受信するためのインタフェースであり、例えば、ＵＳＢ等により実現される。

なお、入力装置１０２０は、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等から情報を読み出す装置であってもよい。また、入力装置１０２０は、ＵＳＢメモリ等の外付け記憶媒体であってもよい。

ネットワークＩＦ１０８０は、ネットワークＮを介して他の機器からデータを受信して演算装置１０３０へ送り、また、ネットワークＮを介して演算装置１０３０が生成したデータを他の機器へ送信する。

演算装置１０３０は、出力ＩＦ１０６０や入力ＩＦ１０７０を介して、出力装置１０１０や入力装置１０２０の制御を行う。例えば、演算装置１０３０は、入力装置１０２０や二次記憶装置１０５０からプログラムを一次記憶装置１０４０上にロードし、ロードしたプログラムを実行する。

例えば、コンピュータ１０００がＦＩＤＯサーバ１として機能する場合、コンピュータ１０００の演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラムを実行することにより、制御部３の機能を実現する。

〔効果〕
上述してきたように、実施形態に係る情報処理装置（ＦＩＤＯサーバ１）は、制御部３を備える。制御部３は、ＦＩＤＯ認証ための認証器を有するユーザ端末３０から送信されたＦＩＤＯ認証のための鍵ペアの生成要求を認証サーバ１０から取得し、生成要求に基づいて認証器に鍵ペアを生成させる生成指示を生成し、生成指示を認証サーバ１０を介して認証器へ通知する。制御部３は、生成指示に従って認証器で生成された鍵ペアのうち、公開鍵を認証サーバ１０を介して取得し、取得した公開鍵を連携ＩＤと紐付けて記憶するとともに、連携ＩＤを認証サーバ１０へ通知する。制御部３は、公開鍵を取得する際に、認証器のアテステーション情報を認証サーバ１０を介して取得し、アテステーション情報の検証結果に基づいて、ユーザの登録可否を示す認証登録コンテキストを生成して認証サーバ１０へ通知する。制御部３は、ユーザ端末３０からアクセスを要求されたサービス提供サーバ２０から認証サーバ１０を介して対象のユーザに対応する連携ＩＤとともに認証要求を取得し、連携ＩＤに対応する認証情報の取得指示を生成し、取得指示を認証サーバ１０を介して認証器へ通知する。制御部３は、取得指示に従って認証器で取得された認証情報に秘密鍵を使って署名されたアサーション情報を認証サーバ１０を介して取得し、アサーション情報の検証結果に基づいて、ユーザの認証可否を示す認証結果コンテキストを生成して認証サーバ１０へ通知する。制御部３は、アサーション情報とともに、ユーザに関する付加情報を取得し、アサーション情報および付加情報の検証結果に基づいて、ユーザの認証可否を示す認証結果コンテキストを生成する。付加情報は、少なくともユーザの位置情報を含む。このような構成により、ＦＩＤＯによる認証技術を容易に導入することができる。

また、上述してきたように、実施形態に係る実施形態に係る情報処理装置（ＦＩＤＯサーバ１）は、制御部３を備える。制御部３は、第１認証器を有するユーザ端末３０からバックアップ用の第２認証器のリカバリー登録要求を認証サーバ１０から取得し、登録要求に基づいて第２認証器のリカバリー鍵ペアを生成し、生成された鍵ペアのうちの、公開鍵を連携ＩＤと紐付けて記憶し、秘密鍵を第２認証器に保管する。第１認証器を有するユーザ端末３０が利用不能であるとき、制御部３は、第２認証器を有するユーザ端末３０Ａから送信された第２認証器のリカバリー実施要求を認証サーバ１０から取得し、リカバリー実施要求に基づいて第２認証器で取得された認証情報に秘密鍵を使って署名されたアサーション情報を取得し、アサーション情報の検証結果に基づいて、第２認証器のリカバリー権限を確認する。制御部３は、第２認証器のリカバリー権限を確認したリカバリー応答を第２認証器を介してユーザ端末３０Ａへ送信する。このような構成により、登録済の認証器が利用不能になったときのアカウントの復旧を可能とする。

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

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

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

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

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

１ ＦＩＤＯサーバ
２、１１、３１ 通信部
３、１２、３２ 制御部
４、１３、３３ 記憶部
１０ 認証サーバ
２０ サービス提供サーバ
３０ ユーザ端末
Ｓ 認証システム

Claims (7)

1. ユーザを識別する識別子であるユーザＩＤと、別途配置されたＦＩＤＯ認証を行うための機能を有したＦＩＤＯサーバとの間で利用する前記ユーザの識別子である連携ＩＤとを紐付けて記憶して利用するユーザＩＤ管理部と、
   認証器のアテステーション情報、又は前記認証器によって生成されたアサーション情報を前記ＦＩＤＯサーバに送信して検証を依頼する送信部と、
   前記ＦＩＤＯサーバによって生成されるコンテキストであって、登録処理時のアテステーション情報の検証結果及び登録された認証手段に関する情報を含んだ認証登録コンテキスト、又は認証処理時のアサーション情報の検証結果及びユーザが行った認証手段の情報を含んだ認証結果コンテキストを読み取り、妥当性を検証するコンテキスト検証部と、
   前記ユーザが通常利用する第１認証器が使用不能になったときのバックアップ用の第２認証器の鍵ペアを生成するリカバリー鍵生成部と、
   前記第１認証器が使用不能になったときに、バックアップ用の前記第２認証器に権限を与えるための検証を行うリカバリー鍵検証部と、
   を備えることを特徴とする情報処理装置。
2. 前記リカバリー鍵生成部は、前記第１認証器の鍵ペアと前記第２認証器のリカバリー鍵ペアとの間に属性ベース暗号技術を導入し、公開鍵を使ってデータを暗号化する際の暗号文に、リカバリーできるユーザの属性を制御条件として組み込んで暗号化可能にし、該属性を持っているユーザのみ前記公開鍵に対応する秘密鍵を使って暗号化データをリカバリー可能にする
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記リカバリー鍵生成部は、ユーザ端末から取得したリカバリー要求の確認としての前記第２認証器の連携ＩＤを前記第１認証器へ送信し、前記第１認証器からのリカバリー確認応答に対して、属性ベース暗号に基づいて前記第２認証器のリカバリー鍵ペアを生成するとともに、リカバリー登録応答を前記ユーザ端末へ送信する
   ことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記リカバリー鍵生成部は、前記ユーザ端末からリカバリー登録要求を受けた前記第２認証器からのリカバリー秘密鍵の生成要求に対する応答として、リカバリー秘密鍵を前記第２認証器へ送信する
   ことを特徴とする請求項３に記載の情報処理装置。
5. 前記リカバリー鍵検証部は、前記第１認証器が使用不能になったときの前記第２認証器からのリカバリー実施要求に対する応答として、認証器検証要求を前記第２認証器へ送信し、アサーションにリカバリー秘密鍵で署名した署名付きアサーションを認証器検証応答として前記第２認証器から受け取り、リカバリー秘密鍵での署名を検証し、前記第２認証器のリカバリー権限を確認し、リカバリー応答を前記第２認証器へ送信する
   ことを特徴とする請求項１から請求項４のいずれか一項に記載の情報処理装置。
6. コンピュータが実行する情報処理方法であって、
   ユーザを識別する識別子であるユーザＩＤと、別途配置されたＦＩＤＯ認証を行うための機能を有したＦＩＤＯサーバとの間で利用する前記ユーザの識別子である連携ＩＤとを紐付けて記憶して利用するユーザＩＤ管理工程と、
   認証器のアテステーション情報、又は前記認証器によって生成されたアサーション情報を前記ＦＩＤＯサーバに送信して検証を依頼する送信工程と、
   前記ＦＩＤＯサーバによって生成されるコンテキストであって、登録処理時のアテステーション情報の検証結果及び登録された認証手段に関する情報を含んだ認証登録コンテキスト、又は認証処理時のアサーション情報の検証結果及びユーザが行った認証手段の情報を含んだ認証結果コンテキストを読み取り、妥当性を検証するコンテキスト検証工程と、
   前記ユーザが通常利用する第１認証器が使用不能になったときのバックアップ用の第２認証器の鍵ペアを生成するリカバリー鍵生成工程と、
   前記第１認証器が使用不能になったときに、バックアップ用の前記第２認証器に権限を与えるための検証を行うリカバリー鍵検証工程と、
   を含むことを特徴とする情報処理方法。
7. ユーザを識別する識別子であるユーザＩＤと、別途配置されたＦＩＤＯ認証を行うための機能を有したＦＩＤＯサーバとの間で利用する前記ユーザの識別子である連携ＩＤとを紐付けて記憶して利用するユーザＩＤ管理手順と、
   認証器のアテステーション情報、又は前記認証器によって生成されたアサーション情報を前記ＦＩＤＯサーバに送信して検証を依頼する送信手順と、
   前記ＦＩＤＯサーバによって生成されるコンテキストであって、登録処理時のアテステーション情報の検証結果及び登録された認証手段に関する情報を含んだ認証登録コンテキスト、又は認証処理時のアサーション情報の検証結果及びユーザが行った認証手段の情報を含んだ認証結果コンテキストを読み取り、妥当性を検証するコンテキスト検証手順と、
   前記ユーザが通常利用する第１認証器が使用不能になったときのバックアップ用の第２認証器の鍵ペアを生成するリカバリー鍵生成手順と、
   前記第１認証器が使用不能になったときに、バックアップ用の前記第２認証器に権限を与えるための検証を行うリカバリー鍵検証手順と、
   をコンピュータに実行させることを特徴とする情報処理プログラム。

Images