(57)【要約】      （修正有）【課題】ユーザの利便性を向上し、かつセキュアな認証方式を提供することが可能な情報処理装置を提供する。【解決手段】情報処理装置は、生体情報センサ２０８で読み取った生体情報により、ユーザのログイン処理を実行する。次に情報処理装置は、ネットワーク上のサービスを利用する際に行われる認証処理に必要となる秘密鍵と、該秘密鍵に対応する公開鍵を生成し、生成された秘密鍵をログイン処理の際に読み取った生体情報に関連付けてＴａｍｐｅｒ  Ｍｏｄｕｌｅ（ＴＰＭ）２０６に格納する。その後、情報処理装置は、ログイン処理の際に読み取った生体情報に対応する認証情報ＩＤと、該生体情報に関連付けてＴＰＭ２０６に格納された秘密鍵に対応する公開鍵とをネットワーク上のサービスに登録する要求を発行する。【選択図】図２
2019096077.tif 000002
【特許請求の範囲】
【請求項１】
生体認証のための認証モジュールと、該認証モジュールにより認証処理を行う際に必要なユーザの生体情報を格納する耐タンパー性を備える記憶手段と、ユーザの生体情報を読み取る生体情報センサと、を有する情報処理装置であって、
前記生体情報センサで読み取った生体情報により、前記ユーザのログイン処理を実行する実行手段と、
ネットワーク上のサービスを利用する際に行われる認証処理に必要となる秘密鍵と、該秘密鍵に対応する公開鍵を生成する生成手段と、
前記生成された秘密鍵を前記ログイン処理の際に読み取った生体情報に関連付けて前記記憶手段に格納する格納手段と、
当該生体情報に対応する識別情報と、該生体情報に関連付けて前記記憶手段に格納された秘密鍵に対応する公開鍵と、を前記ネットワーク上のサービスに登録する要求を発行する登録手段と、を有することを特徴とする情報処理装置。
【請求項２】
前記ネットワーク上のサービスからのリクエストに従い、前記ユーザに生体情報の提示を求める画面を表示する表示手段をさらに有し、
前記画面に従い、前記ユーザにより提示された生体情報を前記生体情報センサで読み取った場合には、前記格納手段は前記生成手段により生成された秘密鍵を当該読み取った生体情報に関連付けて前記記憶手段に格納し、
前記登録手段は、当該生体情報に対応する識別情報と、該生体情報に関連付けて前記記憶手段に格納された秘密鍵に対応する公開鍵と、を前記ネットワーク上のサービスに登録する要求を発行することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記表示手段は、前記ログイン処理で生体情報による認証処理が行われていない場合に、前記画面を表示することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記表示手段は、前記ネットワーク上のサービスから認証処理に必要な情報の指定があった場合に、前記画面を表示することを特徴とする請求項２または３に記載の情報処理装置。
【請求項５】
前記表示手段は、前記ネットワーク上のサービスからのリクエストに従い、前記ユーザに複数の生体情報の提示を求める場合、前記複数の生体情報のうち、前記ログイン処理の際に読み取られた生体情報を除く生体情報の提示を求める画面を表示することを特徴とする請求項２乃至４のいずれか一項に記載の情報処理装置。
【請求項６】
前記ネットワーク上のサービスを利用する際に、前記認証モジュールを用いた前記生体情報センサで読み取った生体情報を用いた生体認証に成功した場合に、当該生体認証に利用された生体情報に関連付けて前記記憶手段に格納された秘密鍵と、前記ネットワーク上のサービスから受信したパラメータとを用いて署名データを作成する作成手段をさらに有し、
前記作成された署名データは、前記ネットワーク上のサービスで検証されることを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
【請求項７】
前記実行手段は、前記情報処理装置へのユーザのログイン状態と、前記ユーザのログイン処理の際に用いられた認証方法とを前記記憶手段に格納し、管理することを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
【請求項８】
前記ネットワーク上のサービスから、複数の生体情報による生体認証がリクエストされた場合、
前記生成手段は、当該複数の生体情報について共通の秘密鍵と公開鍵を生成し、
前記格納手段は、前記生成された秘密鍵を、各生体情報に対して関連付けて格納し、さらに、各生体情報に対してそれぞれの種類を関連付けて格納し、
前記登録手段は、各生体情報の識別情報として共通の値を付与し、該生体情報の識別情報と、前記公開鍵と、を前記ネットワーク上のサービスに登録する要求を発行することを特徴とする請求項１乃至７のいずれか一項に記載の情報処理装置。
【請求項９】
前記情報処理装置は、スマートフォン、タブレット、ウェアラブル端末、ノート型パソコンを含むことを特徴とする請求項１乃至８のいずれか一項に記載の情報処理装置。
【請求項１０】
生体認証のための認証モジュールと、該認証モジュールにより認証処理を行う際に必要なユーザの生体情報を格納する耐タンパー性を備える記憶手段と、ユーザの生体情報を読み取る生体情報センサと、を有する情報処理装置における方法であって、
前記生体情報センサで読み取った生体情報により、前記ユーザのログイン処理を実行する実行工程と、
ネットワーク上のサービスを利用する際に行われる認証処理に必要となる秘密鍵と、該秘密鍵に対応する公開鍵を生成する生成工程と、
前記生成された秘密鍵を前記ログイン処理の際に読み取った生体情報に関連付けて前記記憶手段に格納する格納工程と、
当該生体情報に対応する識別情報と、該生体情報に関連付けて前記記憶手段に格納された秘密鍵に対応する公開鍵と、を前記ネットワーク上のサービスに登録する要求を発行する登録工程と、を有することを特徴とする方法。
【請求項１１】
請求項１乃至９のいずれか一項に記載の各手段としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークサービスにおいて、セキュアな認証方式を提供し、かつ、ユーザの利便性を向上するための技術に関する。
【背景技術】
【０００２】
近年、生体認証を含む新たな認証システムとして、ＦＩＤＯ（Ｆａｓｔ  Ｉｄｅｎｔｉｔｙ  Ｏｎｌｉｎｅ）がある。生体認証で用いられる指紋や静脈といった生体情報は、外部に情報が流出してしまった場合に、従来のＩＤ／パスワード認証におけるパスワードと異なり、情報を書き換えることができないため、情報漏洩が致命的になる。
【０００３】
これに対して、ＦＩＤＯは、予めユーザの手元のデバイスとＷｅｂサービスを提供するサーバとの間で登録処理を行っておく。登録処理では、サービスの提供を受けるデバイスにはユーザの生体認証と紐付いた秘密鍵が保存され、サーバにはその生体認証に紐付く認証識別情報や秘密鍵のペアとなる公開鍵などの情報が登録される。そして、認証はインターネットを経由してサーバ上で行うのではなく、ユーザの手元のデバイス上で行い、ネットワーク上には秘密鍵で署名された認証結果が流れる。つまり、生体情報がネットワーク上を流れることがないため、情報漏洩のリスクが少ないと言える。
【０００４】
特許文献１は、携帯端末が自装置内に予め登録されている端末認証用情報をＭＦＰに自動的に送信し、ＭＦＰは、該端末認証用情報とＭＦＰ内の正規の端末認証用情報とを照合して端末認証処理を自動的に実行する通信システムを開示している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１７−１０３５４６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１の通信システムでは、携帯端末において、端末認証用情報をＭＦＰごとに登録しておく必要があり、利用するＭＦＰごとに登録作業を行うのは、ユーザにとって手間がかかる。また、特許文献１の通信システムでは、ＭＦＰを利用する際に、端末認証に加え、生体認証が行われるが、生体認証に関して予め実行される登録作業については考慮されていない。
【０００７】
本発明は、ユーザの利便性を向上し、かつセキュアな認証方式を提供することが可能な情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明の一実施形態の情報処理装置は、生体認証のための認証モジュールと、該認証モジュールにより認証処理を行う際に必要なユーザの生体情報を格納する耐タンパー性を備える記憶手段と、ユーザの生体情報を読み取る生体情報センサと、を有する情報処理装置であって、前記生体情報センサで読み取った生体情報により、前記ユーザのログイン処理を実行する実行手段と、ネットワーク上のサービスを利用する際に行われる認証処理に必要となる秘密鍵と、該秘密鍵に対応する公開鍵を生成する生成手段と、前記生成された秘密鍵を前記ログイン処理の際に読み取った生体情報に関連付けて前記記憶手段に格納する格納手段と、当該生体情報に対応する識別情報と、該生体情報に関連付けて前記記憶手段に格納された秘密鍵に対応する公開鍵と、を前記ネットワーク上のサービスに登録する要求を発行する登録手段と、を有する。
【発明の効果】
【０００９】
本発明の情報処理装置によれば、ユーザの利便性を向上し、かつセキュアな認証方式を提供することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施形態におけるシステムの全体構成例を示す図である。
【図２】各装置のハードウェア構成例を示す図である。
【図３】各装置の機能構成の一例を示す図である。
【図４】携帯端末へのログイン処理を示すフローチャートである。
【図５】第１実施形態において携帯端末が表示するＵＩの一例を示す図である。
【図６】オーセンティケータをサービスに登録する処理のシーケンスを示す図である。
【図７】オーセンティケータの登録時に使用するパラメータの一例を示す図である。
【図８】第１実施形態に係るクレデンシャル作成処理を示すフローチャートである。
【図９】サービスを利用する際の認証処理のシーケンスを示す図である。
【図１０】生体認証時に使用するパラメータの一例を示す図である。
【図１１】第２実施形態に係るクレデンシャル作成処理を示すフローチャートである。
【図１２】第２実施形態において携帯端末が表示するＵＩの一例を示す図である。
【発明を実施するための形態】
【００１１】
以下、本発明を実施するための形態について図面などを参照して説明する。
なお、本発明はネットワークを介して外部システムから提供されるサービスがユーザを認証するために、ユーザの手元にあるデバイス（情報処理装置）上で生体認証を行い、その結果を以ってサービスがユーザを認証する仕組みに関するものである。これは、サービスにユーザの手元にあるデバイスでの生体認証に紐付く情報、例えば、認証識別情報、公開鍵などをあらかじめ登録しておくことで実現することができる。このような仕組みの一例としてＦＩＤＯを挙げたが、本発明はＦＩＤＯに限定したものではないことをあらかじめ断わっておく。
【００１２】
［第１実施形態］
＜システム構成＞
図１は、本発明の一実施形態におけるシステムの全体構成例を示す図である。
図１に示すシステムは、携帯端末１０１、およびサーバ１０２を備える。携帯端末１０１は、スマートフォン、タブレット、ウェアラブル端末、ノート型パソコン等を含む情報処理装置である。サーバ１０２は、サービスを提供する外部システムであって、複数台の装置により構成されていてもよく、一部または全部を仮想マシンやストレージなどのリソースを用いて構築してもよい。
【００１３】
携帯端末１０１とサーバ１０２とは、ネットワーク１０３を介して接続される。ネットワーク１０３は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれかである。
【００１４】
また、ネットワーク１０３は、これらの組み合わせにより実現される、いわゆる通信ネットワークである。また、ネットワーク１０３は、上述したネットワーク回線に加え、例えば、ＮＦＣ（Ｎｅａｒ  Ｆｉｅｌｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）やＢｌｕｅｔｏｏｔｈ（登録商標）等の近距離無線通信なども含む。ネットワーク１０３は、データの送受信が可能であればよい。
【００１５】
＜携帯端末のハードウェア構成＞
図２（Ａ）は、携帯端末１０１のハードウェア構成例を示す図である。
システムバス２０１は、各処理部２０２〜２１０を相互に接続する。ＣＰＵ２０２は、ＲＯＭ２０４および記憶装置２０５に格納されているＯＳ（オペレーティングシステム）などのプログラムを実行し、システムバス２０１を介して各処理部２０２〜２１０を総括的に制御する。該プログラムは、後述する各フローチャートを実現するプログラムも含む。
【００１６】
ＲＡＭ２０３は、ＣＰＵ２０２のメモリやワークエリアとして機能する。記憶装置２０５は、ソリッドステートドライブ（ＳＳＤ）やＳＤメモリカードなどの記憶装置であり、外部記憶装置として機能する。Ｔａｍｐｅｒ  Ｍｏｄｕｌｅ（ＴＰＭ）２０６は、機密情報を処理したり格納したりする目的で、格納したデータを外部から読み取られることを防ぐ耐タンパー性を備えた記憶手段である。
【００１７】
本実施形態では、ＴＰＭ２０６には、生体情報センサ２１１にて読み取られた指紋や虹彩、静脈の情報等の生体情報そのものの他に、生体情報に関連付けられた各種情報が格納される。各種情報とは、例えば、生体情報の特徴量や、生体情報について生成された秘密鍵等である。以降、生体情報、および生体情報と関連付けられた各種情報を生体情報と呼ぶことにする。
【００１８】
ネットワークＩ／Ｆ２０７は、ＷｉＦｉなどを用いて外部のネットワーク機器と片方向または双方向にデータをやり取りする。生体情報センサ２０８は、ユーザの生体情報を読取るセンサであり、例えばユーザの指紋、虹彩、静脈、声紋、顔等の生体情報を読み取り信号に変換する。なお、生体情報は、これらに限られるものではない。生体情報センサ２０８は、専用の読み取り機や、カメラ、マイクなどを用いて実現され、携帯端末１０１が生体情報センサ２０８を複数備えていてもよい。
【００１９】
タッチパネル２０９は、表示と入力の２つの機能を備えており、アプリケーションの画面やキーボードなどを表示したりするとともに、ユーザが画面に手や専用のペンで圧力を加えることにより、触れられた画面位置情報を外部へ信号情報として出力する。出力された信号情報をアプリケーションが利用することで、ユーザはタッチパネル２０９を通じてアプリケーションを操作することができる。
【００２０】
生体情報センサ２０８とタッチパネル２０９とは、重ねて実装することが可能であり、タッチパネル２０９への操作により利用者の指紋情報を読み取ることも可能である。近接通信Ｉ／Ｆ２１０は、ＮＦＣやＢｌｕｅｔｏｏｔｈ等の近接通信用の通信方式に対応したネットワークＩ／Ｆである。
【００２１】
＜サーバの内部構成＞
図２（Ｂ）は、サーバ１０２のハードウェア構成例を示す図である。
サーバ１０２は、一般的な情報処理装置のハードウェアで構成することができる。ＣＰＵ２４１は、ＲＯＭ２４３に格納されているプログラムや、外部メモリ２５０からＲＡＭ２４２にロードされたＯＳ（オペレーティングシステム）やアプリケーション等のプログラムを実行する。すなわち、ＣＰＵ２４１が、読み取り可能な記憶媒体に格納されたプログラムを実行することにより、後述する各フローチャートの処理を実行する各処理部として機能する。
【００２２】
ＲＡＭ２４２は、ＣＰＵ２４１のメインメモリであり、ワークエリア等として機能する。キーボードコントローラ２４４は、キーボード２４８や不図示のポインティングデバイスからの操作入力を制御する。ポインティングデバイスは、例えば、マウス、タッチパッド、タッチパネル、トラックボールなどである。ディスプレイコントローラ２４５は、ディスプレイ２４９の表示を制御する。
【００２３】
ディスクコントローラ２４６は、各種データを記憶するハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）等の外部メモリ２５０へのデータアクセスを制御する。ネットワークＩ／Ｆ２４７は、ネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。また、ネットワークＩ／Ｆは、ＮＦＣやＢｌｕｅｔｏｏｔｈなどの近接通信用の通信方式にも対応し、携帯端末１０１等と通信し、データのやり取りを行う。システムバス２５１は、各処理部２４１〜２５０を相互に接続する。
【００２４】
＜携帯端末の機能構成＞
図３（Ａ）は、携帯端末１０１の機能構成の一例を示す図である。
携帯端末１０１は、ログインアプリケーション３００、連携アプリケーション３１０、オーセンティケータ（Ａｕｔｈｅｎｔｉｃａｔｏｒ）３２０を有する。ログインアプリケーション３００、連携アプリケーション３１０、およびオーセンティケータ３２０は、ＣＰＵ２０２が、ＲＯＭ２０４に格納されたプログラムをＲＡＭ２０３に読み出して実行することで実現される。
【００２５】
ログインアプリケーション３００は、ユーザの携帯端末１０１へのログイン処理を実行する。ログイン処理の詳細は、後述する。ログインアプリケーション３００は、表示部３０１および端末ユーザ認証制御部３０２から構成される。表示部３０１は、タッチパネル２０９を介してユーザにＵＩ（ユーザインタフェース）を提供するためのソフトウェアモジュールである。表示部３０１は、タッチパネル２０９を介して、例えば、携帯端末１０１のユーザを認証するための画面を表示したり、ユーザの操作を受け付けたりする。
【００２６】
端末ユーザ認証制御部３０２は、表示部３０１から受け取った認証に関するイベントをオーセンティケータ３２０に渡したり、オーセンティケータ３２０から認証結果を受け取ったりするためのソフトウェアモジュールである。なお、本実施形態では、ログインアプリケーション３００は、ＯＳに標準搭載されていることを想定しているが、これに限られるものではない。例えば、ログインアプリケーション３００は、ユーザによってインストールされたアプリケーションであってもログインアプリケーション３００と同等の機能を有するアプリケーションであれば代替え可能である。
【００２７】
連携アプリケーション３１０は、サーバ１０２と連携して、認証機能やサーバ１０２のサービスをユーザに提供する。連携アプリケーション３１０は、携帯端末１０１にインストールされたネイティブアプリケーションやＷｅｂブラウザである。連携アプリケーション３１０は、表示部３１１、通信部３１２、オーセンティケータ登録制御部３１３、およびサービス認証制御部３１４から構成される。
【００２８】
表示部３１１は、タッチパネル２０９を介してユーザにＵＩ（ユーザインタフェース）を提供するためのソフトウェアモジュールである。表示部３１１は、オーセンティケータ３２０をサーバ１０２に登録するための画面や図３（Ｂ）を用いて後述するサーバ１０２のサービス３７０が提供する機能を利用するための画面を表示する。通信部３１２は、ネットワークＩ／Ｆ２０７を介してサーバ１０２などの外部の装置と通信するためのソフトウェアモジュールである。
【００２９】
オーセンティケータ登録制御部３１３は、オーセンティケータ３２０に対して後述するクレデンシャルの作成要求を行うソフトウェアモジュールである。なお、本実施形態では、オーセンティケータ登録制御部３１３は、連携アプリケーション３１０に含まれるが、これに限られるものではない。例えば、オーセンティケータ登録制御部３１３を、連携アプリケーション３１０とは独立して構成し、連携アプリケーション３１０が、独立したオーセンティケータ登録制御部３１３を呼び出すようにしてもよい。
【００３０】
また、オーセンティケータ登録制御部３１３は、ＯＳに標準搭載されていてもよい。このように、オーセンティケータ登録制御部３１３をアプリケーションから独立させることで、連携アプリケーション３１０だけでなく、他のアプリケーションがオーセンティケータ登録制御部３１３を呼び出せるような構成にすることができる。
【００３１】
サービス認証制御部３１４は、サーバ１０２などからの要求を受けて、オーセンティケータ３２０に対して生体認証処理を要求したり、認証時にサーバ１０２に対して送信するリクエストを生成したりする。また、サービス認証制御部３１４は、生体認証処理の結果を受け取る。サービス認証制御部３１４が行う具体的な処理フローに関しては後述する。なお、サービス認証制御部３１４に関してもオーセンティケータ登録制御部３１３と同様に、連携アプリケーション３１０から独立して構成してもよい。
【００３２】
オーセンティケータ３２０は、生体情報センサ２０８により読み取った生体情報を用いた生体認証のための認証モジュールである。オーセンティケータ３２０は、オーセンティケータ登録処理部３２１、端末ユーザ認証処理部３２２、サービス認証処理部３２３、生体情報要求部３２４、端末ユーザ情報格納部３２５、およびサービス認証情報格納部３２６から構成される。
【００３３】
オーセンティケータ登録処理部３２１は、連携アプリケーション３１０のオーセンティケータ登録制御部３１３等からクレデンシャルの作成要求を受け付け、ペアの鍵（秘密鍵および公開鍵）の作成やクレデンシャルの作成を行うソフトウェアモジュールである。端末ユーザ認証処理部３２２は、ログインアプリケーション３００の端末ユーザ認証制御部３０２から認証要求を受け付け、端末ユーザ情報格納部３２５に格納されている情報を用いて認証を行うソフトウェアモジュールである。
【００３４】
サービス認証処理部３２３は、連携アプリケーション３１０のサービス認証制御部３１４などから生体認証要求を受け付けて、生体情報センサ２０８により読み取った生体情報を用いた生体認証を行うソフトウェアモジュールである。生体情報要求部３２４は、生体情報の入力を受け付けるためのＵＩを、タッチパネル２０９を介してユーザに提供するソフトウェアモジュールである。
【００３５】
端末ユーザ情報格納部３２５は、携帯端末１０１のユーザ情報などをＴＰＭ２０６に対して格納するソフトウェアモジュールである。端末ユーザ情報格納部３２５に格納されるユーザ情報は、例えば、後述する表Ａに示す情報である。サービス認証情報格納部３２６は、認証情報などをＴＰＭ２０６に対して格納するソフトウェアモジュールである。認証情報は、例えば、後述する表Ｂに示す情報である。なお、本実施形態では、ログインアプリケーション３００と、オーセンティケータ３２０は、別個のアプリケーションとして構成しているが、１つのアプリケーションとして構成してもよい。
【００３６】
＜サーバの機能構成＞
図３（Ｂ）は、サーバ１０２の機能構成の一例を示す図である。
サーバ１０２では、サービス３７０が動作する。サービス３７０は、サーバ１０２が有するＲＯＭ２４３に格納されているプログラムを、ＣＰＵ２４１がＲＡＭ２４２に読み出して実行することで実現される。
【００３７】
サービス３７０は、レガシー認証処理部３７１、オーセンティケータ情報処理部３７２、通信部３７３、プレゼンテーション部３７４、ユーザ情報格納部３７５、オーセンティケータ情報格納部３７６、およびトークン管理部３７７から構成される。なお、本実施形態では、生体認証と区別するために、ユーザＩＤとパスワードの一致を検証する認証をレガシー認証と記載する。
【００３８】
レガシー認証処理部３７１は、通信部３７３が受信したレガシー認証要求に含まれるユーザＩＤとパスワードとが、ユーザ情報格納部３７５に格納されているユーザＩＤとパスワードと一致するかを検証するソフトウェアモジュールである。オーセンティケータ情報処理部３７２は、通信部３７３が受信したクレデンシャルを用いて、オーセンティケータ３２０に関する情報を、オーセンティケータ情報格納部３７６に格納するソフトウェアモジュールである。また、オーセンティケータ情報処理部３７２は、通信部３７３が受信した後述するアサーション情報（Ａｓｓｅｒｔｉｏｎ）を検証する。
【００３９】
通信部３７３は、ネットワークＩ／Ｆ２４７を介して、携帯端末１０１などの外部の装置と通信するためのソフトウェアモジュールである。例えば、通信部３７３は、携帯端末１０１から各種要求を受け付ける。プレゼンテーション部３７４は、通信部３７３が受信したオーセンティケータ３２０の登録を行うための画面など、各種画面の取得要求に応じて、ＨＴＭＬやＣＳＳ、ＪａｖａＳｃｒｉｐｔ（登録商標）などを生成するソフトウェアモジュールである。
【００４０】
ユーザ情報格納部３７５は、表Ｃや表Ｆを用いて後述するユーザに関する情報（ユーザ情報）を、外部メモリ２５０や外部のストレージシステム（不図示）に格納するソフトウェアモジュールである。オーセンティケータ情報格納部３７６は、表Ｅを用いて後述するオーセンティケータ３２０に関する情報（オーセンティケータ情報）を外部メモリ２５０や外部のストレージサービスに格納するソフトウェアモジュールである。トークン管理部３７７は、後述するトークンの発行や検証を行うソフトウェアモジュールである。
【００４１】
＜携帯端末が管理するテーブル＞
以下、表Ａおよび表Ｂを用いて、携帯端末１０１がＴＰＭ２０６に格納する各種データについて説明する。詳細には、表Ａおよび表Ｂに示すテーブルデータは、携帯端末１０１が有するオーセンティケータ３２０の端末ユーザ情報格納部３２５およびサービス認証情報格納部３２６がＴＰＭ２０６に格納するデータである。
【００４２】
【表１】
2019096077.tif 000003
【００４３】
表Ａの端末ユーザ情報テーブルは、携帯端末１０１が管理する端末ユーザ情報テーブルの一例である。端末ユーザ情報格納部３２５がＴＰＭ２０６に格納し、管理する。端末ユーザ情報管理テーブルは、１つのレコードが１つの端末ユーザの情報のエントリを示す。ユーザＩＤ列には、レガシー認証等で使用する、携帯端末１０１がユーザを一意に識別するためのＩＤを格納する。
【００４４】
パスワード列には、ユーザが携帯端末１０１にログインするためにユーザを認証するためのパスワードを格納する。生体情報ＩＤ列には、生体情報の特徴量に対応するＩＤを格納する。携帯端末１０１は、ユーザが入力したパスワード、または生体情報に対応する生体情報ＩＤが一致した場合に携帯端末１０１へのログインを許可する。ユーザＩＤ、パスワード、および生体情報ＩＤは、携帯端末１０１にユーザ登録する際に設定する。携帯端末１０１へのログイン処理の詳細は、図４を用いて後述する。
【００４５】
ログイン状態列には、現在ユーザがログインしているか否かを示す情報を格納する。認証方法列には、ユーザがどの認証方法でログインしたかを示す情報を格納する。例えば、生体認証の１つである指紋認証でログインした場合、認証方法列には、指紋認証であることを示す情報として、例えば、「ｆｉｎｇｅｒｐｒｉｎｔ」が格納される。ログイン状態列および認証方法列に対応する情報を格納する手順については図４を用いて後述する。
【００４６】
【表２】
2019096077.tif 000004
【００４７】
表Ｂのサービス認証情報管理テーブルは、１つのレコードが１つの認証情報のエントリを示す。表Ａのレコードは、オーセンティケータ３２０をサービスに登録する際に作成され、表Ｂに追加される。認証情報ＩＤ列には、各認証情報を一意に識別するためのＩＤを格納する。サービスＩＤ列には、生体情報を用いた認証機能を利用するサービスを一意に識別するためのＩＤを格納する。
【００４８】
本実施形態では、サービスＩＤとしてサーバ、サービスのドメイン名、詳細にはトップレベルドメインおよびセカンドレベルドメインの情報を使用する。例えば、サービス３７０のＵＲＬがｈｔｔｐ：//ｗｗｗ.ｓｅｒｖｉｃｅ.ｃｏｍであった場合に、該サービス３７０のサービスＩＤは、ｓｅｒｖｉｃｅ.ｃｏｍとする。
【００４９】
秘密鍵列には、生体情報について作成されたペアの鍵のうち、秘密鍵を格納する。秘密鍵列に対応する（ペアとなる）公開鍵は、サービスＩＤ列に示されるサービスに登録される。生体情報ＩＤ列には、生体情報の特徴量に対応するＩＤを格納する。サービス認証情報管理テーブルの各列に対応する情報を格納する手順、および公開鍵をサービス３７０に格納する手順については後述する。
【００５０】
＜サーバが管理するテーブル＞
以下、表Ｃ〜表Ｆを用いて、サーバ１０２が格納する各種データについて説明する。詳細には、表Ｃ〜表Ｆに示すテーブルデータは、サーバ１０２が有するサービス３７０の各ソフトウェアモジュールが、外部メモリ２５０や外部のストレージシステムに格納するデータである。
【００５１】
【表３】
2019096077.tif 000005
【００５２】
表Ｃのユーザ情報管理テーブルは、サービス３７０のユーザ情報格納部３７５が管理するデータである。ユーザ情報管理テーブルは、１つのレコードがサービス３７０の１つのユーザ情報のエントリを示す。ユーザＩＤ列には、サービス３７０のユーザを一意に識別するためのＩＤを格納する。パスワード列には、ユーザを認証するためのパスワードを格納する。メールアドレス列には、ユーザのメールアドレスを格納する。なお、ユーザ情報管理テーブルには、ユーザ情報として、メールアドレス以外にもユーザの住所など、ユーザに関する属性情報を格納してもよい。
【００５３】
【表４】
2019096077.tif 000006
【００５４】
表Ｄのａｔｔｅｓｔａｔｉｏｎチャレンジ管理テーブルは、サービス３７０のユーザ情報格納部３７５が管理するデータである。ａｔｔｅｓｔａｔｉｏｎチャレンジ管理テーブルは、１つのレコードが１つのａｔｔｅｓｔａｔｉｏｎチャレンジの情報のエントリを示す。ａｔｔｅｓｔａｔｉｏｎチャレンジは、チャレンジレスポンス認証を行うための検証用データとして利用するパラメータであり、ユーザごとに発行される。
【００５５】
ａｔｔｅｓｔａｔｉｏｎチャレンジの発行処理については後述する。ａｔｔｅｓｔａｔｉｏｎチャレンジ列には、ａｔｔｅｓｔａｔｉｏｎチャレンジの値を格納する。ユーザＩＤ列には、ａｔｔｅｓｔａｔｉｏｎチャレンジを発行したユーザのユーザＩＤを格納する。有効期限列には、ａｔｔｅｓｔａｔｉｏｎチャレンジの有効期限を格納する。
【００５６】
【表５】
2019096077.tif 000007
【００５７】
表Ｅのオーセンティケータ情報管理テーブルは、サービス３７０のオーセンティケータ情報格納部３７６が管理するデータである。オーセンティケータ情報管理テーブルは、１つのレコードが１つのオーセンティケータ情報を示す。オーセンティケータ３２０の登録を行うと、オーセンティケータ情報管理テーブルにレコードが追加される。認証情報ＩＤ列には、登録されたオーセンティケータ３２０がサービス認証情報管理テーブル（表Ｂ）にて管理されている認証情報の認証情報ＩＤ列の値が格納される。
【００５８】
公開鍵列には、オーセンティケータ３２０が作成し、サービス認証情報管理テーブル（表Ｂ）にて管理する秘密鍵に対応する（ペアになる）公開鍵を格納する。すなわち、サービス認証情報管理テーブル（表Ｂ）とオーセンティケータ情報管理テーブル（表Ｅ）において認証情報ＩＤの値が同一の秘密鍵と公開鍵では、表Ｂの秘密鍵で暗号化されたデータは、表Ｅの公開鍵で復号化できるということである。ユーザＩＤ列には、サービス３７０がユーザを一意に識別するためのＩＤを格納する。
【００５９】
【表６】
2019096077.tif 000008
【００６０】
表Ｆのトークン管理テーブルは、サービス３７０のユーザ情報格納部３７５が管理するデータである。トークンは、本実施形態において、後述する生体情報を用いた一連の認証処理が成功した結果、サービス３７０が発行する。連携アプリケーション３１０は、サービス３７０を利用する際に、発行されたトークンを付与して要求を送信することで、サービス３７０が提供する機能を利用することができる。
【００６１】
トークン管理テーブルは、１つのレコードが１つのトークンの情報を示す。トークン列には、トークンを格納する。ユーザＩＤ列には、サービス３７０がユーザを一意に識別するためのＩＤを格納する。有効期限列には、トークンの有効期限を格納する。サービス３７０は、ユーザからの要求に付与されたトークンが、トークン管理テーブルのトークン列に存在し、有効期限列の有効期限を過ぎていない場合に、該要求を受け付ける。
【００６２】
＜携帯端末のログイン処理＞
次に、図４および図５（Ａ）を用いて、携帯端末１０１のログイン処理について説明する。
図４は、携帯端末１０１のログイン処理を説明するためのフローチャートである。
まず、ステップＳ４０１で、ログインアプリケーション３００の表示部３０１は、ログイン画面を表示する。
【００６３】
図５（Ａ）は、ステップＳ４０１にて表示されるログイン画面の一例である。
ログイン画面５００は、ログインアプリケーション３００の表示部３０１が表示するＵＩである。テキストボックス５０１は、携帯端末１０１のユーザＩＤを入力するためのテキストボックスである。テキストボックス５０２は、パスワードを入力するためのテキストボックスである。ボタン５０３は、テキストボックス５０１および５０２に入力されたユーザＩＤおよびパスワードを用いたログイン要求を受け付けるためのボタンである。
【００６４】
ボタン５０４は、指紋などの生体情報の読み取りを行うためのボタンであり、生体情報センサ２０８を備える。なお、生体情報として、静脈、虹彩、声紋、顔などの情報を利用でき、いずれかに限定するものではない。ここでは、生体情報のいずれか、または任意の複数の生体情報の組み合わせを、生体認証に用いる生体情報として入力するように携帯端末１０１を構成する。
【００６５】
また、ボタン５０４は、指紋などの生体情報の読み取りを行うとともに、該生体情報を用いたログイン要求を受け付けるためのボタンである。このように、本実施形態では、携帯端末１０１は、ユーザＩＤおよびパスワードを用いたログインと、生体情報を用いたログインとが行える。なお、携帯端末１０１へのログイン方法は、これらに限られるものではなく、例えば、ＰＩＮコードによるログイン等、その他の方法を用いたログイン要求を受け付けるようにしてもよい。
【００６６】
図４の説明に戻る。ステップＳ４０２で、表示部３０１は、認証イベントを検知したか判断する。なお、本実施形態では、認証イベントは、ログイン画面５００において、ボタン５０３の押下が検知された場合、またはボタン５０４が指を検知した場合に発生する。認証イベントを検知した場合は、処理はステップＳ４０３に進み、認証イベントを検知していない場合は、認証イベントの監視を続ける。
【００６７】
ステップＳ４０３で、表示部３０１は、認証イベントがボタン５０３の押下の検知によるものか、ボタン５０４による指の検知によるものかを判断する。認証イベントがボタン５０３の押下の検知による場合、表示部３０１は、端末ユーザ認証制御部３０２を介して、オーセンティケータ３２０の端末ユーザ認証処理部３２２に対して、ログイン画面５００に入力されたユーザＩＤおよびパスワードを渡す。そして、処理はステップＳ４０４に進む。
【００６８】
一方、認証イベントがボタン５０４による指の検知による場合、表示部３０１は、端末ユーザ認証制御部３０２を介して、オーセンティケータ３２０の端末ユーザ認証処理部３２２に対して、生体認証を要求する。そして処理はステップＳ４０５に進む。
【００６９】
ステップＳ４０４で、オーセンティケータ３２０の端末ユーザ認証処理部３２２は、ステップＳ４０３で渡されたユーザＩＤおよびパスワードを用いてレガシー認証を行う。具体的には、端末ユーザ認証処理部３２２は、ステップＳ４０３で渡されたユーザＩＤおよびパスワードの組み合わせが、端末ユーザ情報格納部３２５が管理する端末ユーザ情報テーブル（表Ａ）に格納されているか検証することによりユーザの認証を行う。
【００７０】
ステップＳ４０５で、表示部３０１は、ボタン５０４が備える生体情報センサ２０８を介して、生体情報の読み取りを行う。そして、表示部３０１は、読み取られた生体情報を、端末ユーザ認証制御部３０２を介して、オーセンティケータ３２０の端末ユーザ認証処理部３２２に渡す。
【００７１】
ステップＳ４０６で、オーセンティケータ３２０の端末ユーザ認証処理部３２２は、ステップＳ４０５で渡された生体情報を用いて生体認証を行う。具体的には、端末ユーザ認証処理部３２２は、ステップＳ４０５で渡された生体情報の特徴量から、端末ユーザ情報格納部３２５が管理する端末ユーザ情報テーブル（表Ａ）に格納されている生体情報ＩＤを特定することによりユーザの認証を行う。
【００７２】
ステップＳ４０７で、端末ユーザ認証処理部３２２は、ステップＳ４０４またはステップＳ４０６の認証が成功であったか判断する。認証が成功であった場合、処理はステップＳ４０８に進み、認証が失敗であった場合、認証に失敗した旨を示す情報をログインアプリケーション３００の端末ユーザ認証制御部３０２に渡す。そして、処理はステップＳ４１０に進む。
【００７３】
ステップＳ４０８で、端末ユーザ認証処理部３２２は、端末ユーザ情報格納部３２５を介して、端末ユーザ情報テーブル（表Ａ）のログイン状態列および認証方法列を更新する。例えば、認証イベントがボタン５０４にて指を検知したことにより発生した場合、ログイン状態列はログインしていることを示す「ｌｏｇｉｎ」に更新し、認証方法列は指紋認証であったことを示す「ｆｉｎｇｅｒｐｒｉｎｔ」に更新する。
【００７４】
ステップＳ４０９で、携帯端末１０１のＯＳは、ホーム画面（不図示）を表示して図４に示す処理を終了する。ホーム画面には、連携アプリケーション３１０やその他のアプリケーションを呼び出すためのボタン等が配置される。Ｓ４１０で、ログインアプリケーション３００の表示部３０１は、ログインに失敗したことを示すＵＩ（不図示）を表示し、図４に示す処理を終了する。
【００７５】
＜オーセンティケータの登録処理＞
次に、図５（Ｂ）〜図８を用いて、携帯端末１０１のオーセンティケータ３２０をサーバ１０２のサービス３７０に登録する処理について説明する。
なお、オーセンティケータの情報をサービスに登録することを、単にオーセンティケータの登録と呼ぶ。
【００７６】
図５（Ｂ）は、携帯端末１０１の連携アプリケーション３１０のトップ画面の一例を示す図である。
連携アプリケーション３１０のトップ画面５３０は、連携アプリケーション３１０の表示部３１１が表示するＵＩである。図４のステップＳ４０９にて表示されたホーム画面（不図示）において、連携アプリケーション３１０を呼び出すボタンの押下が検知されると、表示部３０１がトップ画面５３０を表示する。
【００７７】
トップ画面５３０は、ボタン５３１、およびボタン５３２から構成される。ボタン５３１は、サーバ１０２のサービス３７０にオーセンティケータ３２０を登録するためのボタンである。ボタン５３１が押下されると、サービス３７０への登録要求を受け付ける。ボタン５３２は、サーバ１０２のサービス３７０への生体認証の要求を受け付けるためのボタンである。サービス３７０における生体認証処理については、図９を用いて後述する。連携アプリケーション３１０の表示部３１１は、ボタン５３１が押下されたことを検知すると、図５（Ｃ）に示すレガシー認証画面を表示する。
【００７８】
図５（Ｃ）は、レガシー認証画面の一例を示す図である。
レガシー認証画面５７０は、連携アプリケーション３１０の表示部３１１が表示するＵＩである。レガシー認証画面５７０は、テキストボックス５７１および５７２、ボタン５７３から構成される。テキストボックス５７１は、サーバ１０２のサービス３７０におけるユーザＩＤを入力するためのテキストボックスである。
【００７９】
テキストボックス５７２は、パスワードを入力するためのテキストボックスである。ボタン５７３は、テキストボックス５７１および５７２に入力されたユーザＩＤおよびパスワードを用いたレガシー認証の要求を受け付けるためのボタンである。連携アプリケーション３１０の表示部３１１が、ボタン５７３が押下されたことを検知すると、図６に示す処理が開始する。
【００８０】
図６は、携帯端末１０１のオーセンティケータ３２０をサーバ１０２のサービス３７０に登録する処理のシーケンスを示す図である。
ステップＳ６０１で、連携アプリケーション３１０の通信部３１２は、レガシー認証画面５７０に入力されたユーザＩＤおよびパスワードをパラメータとして、サーバ１０２のサービス３７０にレガシー認証の要求を送信する。
【００８１】
ステップＳ６０２で、サービス３７０のレガシー認証処理部３７１は、受信したＩＤおよびパスワードの検証を行う。レガシー認証の結果がエラーであった場合、レガシー認証処理部３７１は、連携アプリケーション３１０に認証エラーを返却する。なお、図６において、レガシー認証は成功したものとする。
【００８２】
ステップＳ６０３で、サービス３７０のトークン管理部３７７は、トークンを発行し、ユーザ情報格納部３７５は、該トークンに関する情報をトークン管理テーブル（表Ｆ）で管理する。ステップＳ６０４で、サービス３７０の通信部３７３は、ステップＳ６０３で発行されたトークンを連携アプリケーション３１０に返却する。
【００８３】
ステップＳ６０５で、連携アプリケーション３１０の通信部３１２は、サービス３７０に、オーセンティケータ登録の要求を送信する。なお、オーセンティケータ登録の要求には、ステップＳ６０４で発行されたトークンが含まれる。以降の処理において、連携アプリケーション３１０からサービス３７０への要求には同様にトークンが含まれる。
【００８４】
ステップＳ６０６で、サービス３７０のオーセンティケータ情報処理部３７２は、登録パラメータ７００を作成する。なお、ステップＳ６０６の処理は、トークン管理部３７７がステップＳ６０５の要求に含まれるトークンの有効性の検証を行い、トークンが有効である場合に実行される。トークンの有効性は、ステップＳ６０５の要求に含まれるトークンが、トークン管理テーブル（表Ｆ）に存在し、かつ有効期限を過ぎていない場合に、該トークンが有効であると判断される。
【００８５】
登録パラメータは、サーバ１０２がオーセンティケータ３２０の登録処理を実行する際に使用するデータである。連携アプリケーション３１０を介してオーセンティケータ３２０が該登録パラメータを受け取り、登録パラメータに含まれるデータを用いてクレデンシャルを作成する。そして、サーバ１０２は、連携アプリケーション３１０を介してクレデンシャルを受け取り、該クレデンシャルに基づき、連携アプリケーション３１０からの登録要求が不正な要求でないことを検証する。以下、登録パラメータについて説明する。
【００８６】
図７は、オーセンティケータ３２０の登録において、携帯端末１０１とサーバ１０２との通信に含まれるパラメータの一例を示す図である。
ここで、図７（Ａ）を用いて登録パラメータについて説明する。登録パラメータ７００は、アカウント情報７０１、暗号化パラメータ７０２、ａｔｔｅｓｔａｔｉｏｎチャレンジ７０３、および認証拡張領域７０４から構成される。
【００８７】
アカウント情報７０１には、サービス３７０における、ステップＳ６０２のレガシー認証で特定したユーザＩＤや、該ユーザＩＤと紐づくメールアドレスなどユーザに関する属性情報が格納される。暗号化パラメータ７０２には、サービス３７０がサポートしている暗号化アルゴリズムなど、登録する認証情報に関する属性情報が格納される。ａｔｔｅｓｔａｔｉｏｎチャレンジ７０３には、チャレンジレスポンス認証を行うために利用する検証用データが格納される。
【００８８】
検証用データすなわちａｔｔｅｓｔａｔｉｏｎチャレンジ７０３は、ステップＳ６０６にて登録パラメータを作成する際に作成され、ａｔｔｅｓｔａｔｉｏｎチャレンジ管理テーブル（表Ｄ）にユーザＩＤや有効期限などと関連付けて格納される。認証拡張領域７０４には、サービス３７０が連携アプリケーション３１０やオーセンティケータ３２０等の動作を制御するために利用する、サービス３７０が指定可能な拡張パラメータが格納される。
【００８９】
図６の説明に戻る。ステップＳ６０７で、サービス３７０の通信部３７３は、連携アプリケーション３１０に対してクレデンシャル作成の要求を送信する。なお、該要求には、ステップＳ６０６で作成された登録パラメータ７００を含める。ステップＳ６０８で、連携アプリケーション３１０のオーセンティケータ登録制御部３１３は、オーセンティケータ３２０に対して、クレデンシャル作成の要求を送信する。クレデンシャル作成の要求には、Ａｕｔｈ登録パラメータを含める。以下、Ａｕｔｈ登録パラメータについて説明する。
【００９０】
図７（Ｂ）は、Ａｕｔｈ登録パラメータの一例を示す図である。
Ａｕｔｈ登録パラメータ７２０は、登録パラメータ７００、サービスＩＤ７２１、およびＷｅｂＯｒｉｇｉｎ７２２から構成される。登録パラメータ７００は、サービス３７０からステップＳ６０７にて受信した登録パラメータ７００である。
【００９１】
サービスＩＤ７２１は、表Ｂ等で説明した、オーセンティケータ３２０の登録対象のサービス３７０を一意に識別するためのＩＤである。ＷｅｂＯｒｉｇｉｎ７２２は、プロトコルとホスト名とポートの組み合わせであり、本実施形態ではサービス３７０のＯｒｉｇｉｎが格納される。
【００９２】
図６の説明に戻る。ステップＳ６０９で、オーセンティケータ３２０は、クレデンシャル作成処理を行う。以下、オーセンティケータ３２０におけるクレデンシャル作成処理について説明する。
【００９３】
図８は、オーセンティケータ３２０が実行するクレデンシャル作成処理について説明するフローチャートである。
ステップＳ８０１で、オーセンティケータ登録処理部３２１は、端末ユーザ認証処理部３２２を介して、ユーザが携帯端末１０１に生体認証でログインしているかを判断する。詳細には、端末ユーザ認証処理部３２２は、端末ユーザ情報格納部３２５を介して端末ユーザ情報テーブル（Ａ）を参照し、現在ログインしているユーザが生体認証でログインしていることを確認する。
【００９４】
例えば、端末ユーザ情報テーブル（表Ａ）のログイン状態列の値がｌｏｇｉｎであり、認証方法列の値が、生体認証の１つである指紋認証を示すｆｉｎｇｅｒｐｒｉｎｔであった場合、ユーザが生体認証でログインしていると判断する。ユーザが生体認証でログインしている場合、処理はステップＳ８０２に進み、生体認証でログインしていない場合、処理はステップＳ８０３に進む。
【００９５】
ステップＳ８０２で、オーセンティケータ登録処理部３２１は、端末ユーザ認証処理部３２２を介して、端末ユーザ情報テーブル（表Ａ）から生体認証でログインしているユーザの生体情報ＩＤを取得する。ステップＳ８０３で、生体情報要求部３２４は、ユーザに生体情報の入力（提示）を促す同意画面を表示する。
【００９６】
図５（Ｄ）は、同意画面の一例を示す図である。
同意画面５９０は、オーセンティケータ３２０の生体情報要求部３２４が表示するＵＩである。同意画面５９０では、オーセンティケータ３２０をサービス３７０に登録するために必要となる生体情報の入力示をユーザに促す。ボタン５９１は、ユーザが生体情報の入力に同意せずに処理をキャンセルするためのボタンである。ボタン５０４は、上述したように、指紋などの生体情報の読み取りを行うためのボタンであり、生体情報センサ２０８を備える。
【００９７】
図８の説明に戻る。ステップＳ８０４で、生体情報要求部３２４は、ボタン５０４が生体情報の入力を検知するまで監視する。生体情報が入力された場合、処理はステップＳ８０５へ進む。ステップＳ８０５で、生体情報要求部３２４は、ボタン５０４が備える生体情報センサ２０８が読み取った生体情報の特徴量と該生体情報を一意に識別するための生体情報ＩＤを作成する。
【００９８】
ステップＳ８０６で、オーセンティケータ登録処理部３２１は、秘密鍵および公開鍵のペアを作成する。そして、オーセンティケータ登録処理部３２１は、サービス認証情報格納部３２６に対してＴＰＭ２０６に格納されているサービス認証情報管理テーブル（表Ｂ）に、以下の情報を格納する。
【００９９】
ステップＳ８０２で取得またはステップＳ８０５で作成した生体情報ＩＤと、ステップＳ８０６で作成した鍵ペアのうち秘密鍵と、クレデンシャル作成の要求に含まれるＡｕｔｈ登録パラメータ７２０のサービスＩＤ７２１とを関連付けて認証情報として格納する。また、格納された認証情報には、各認証情報を一意に識別するためのＩＤが作成され、認証情報ＩＤとしてサービス認証情報管理テーブル（表Ｂ）に格納される。ステップＳ８０７で、オーセンティケータ登録処理部３２１は、クレデンシャルを作成し、図８に示す処理を終了する。以下、クレデンシャルについて説明する。
【０１００】
図７（Ｃ）は、クレデンシャルの一例を示す図である。
クレデンシャル７４０は、認証情報ＩＤ７４１、アルゴリズム７４２、公開鍵７４３、およびａｔｔｅｓｔａｔｉｏｎ７４４から構成される。認証情報ＩＤ７４１は、ステップＳ８０６でサービス認証情報管理テーブル（表Ｂ）に格納した認証情報ＩＤであり、公開鍵７４３は、ステップＳ８０６で作成された鍵ペアの公開鍵である。
【０１０１】
アルゴリズム７４２には、ステップＳ８０６において鍵ペアを作成する際に利用したアルゴリズムを格納する。また、ａｔｔｅｓｔａｔｉｏｎ７４４は、クレデンシャル作成の要求に含まれるＡｕｔｈ登録パラメータ７２０のａｔｔｅｓｔａｔｉｏｎチャレンジ７０３をステップＳ８０６にて生成された秘密鍵を用いて暗号化したデータである。
【０１０２】
図６の説明に戻る。ステップＳ６１０で、オーセンティケータ登録処理部３２１は、連携アプリケーション３１０に対して、ステップＳ８０７で作成したクレデンシャル７４０を返却する。ステップＳ６１１で、連携アプリケーション３１０の通信部３１２は、サービス３７０に対して、ステップＳ６１０で受信したクレデンシャル７４０を送信する。ステップＳ６１２で、サービス３７０のオーセンティケータ情報処理部３７２は、受信したクレデンシャル７４０を用いて、オーセンティケータ登録処理を行う。以下、オーセンティケータ情報処理部３７２が実行するクレデンシャルの登録処理について説明する。
【０１０３】
オーセンティケータ情報処理部３７２は、クレデンシャル７４０に含まれるａｔｔｅｓｔａｔｉｏｎ７４４を、同じクレデンシャル７４０に含まれる公開鍵７４３で復号し、不正な登録要求でないことを検証する。さらに、オーセンティケータ情報処理部３７２は、ａｔｔｅｓｔａｔｉｏｎチャレンジ管理テーブル（表Ｄ）において、ａｔｔｅｓｔａｔｉｏｎ７４４を公開鍵７４３で復号した値と同一の値をａｔｔｅｓｔａｔｉｏｎチャレンジ列にもつレコードを特定する。
【０１０４】
そして、オーセンティケータ情報処理部３７２は、特定したレコードのユーザＩＤをクレデンシャル７４０と関連付けるユーザＩＤとする。そして、オーセンティケータ情報処理部３７２は、クレデンシャル７４０に含まれる認証情報ＩＤ７４１および公開鍵７４３と、クレデンシャル７４０と関連付けるユーザＩＤとをオーセンティケータ情報管理テーブル（表Ｅ）に格納（登録）する。最後に、サービス３７０の通信部３７３は、連携アプリケーション３１０に対して正常にオーセンティケータ３２０の登録処理が完了した旨を通知する。
【０１０５】
このように、オーセンティケータの登録処理において、ステップＳ８０１およびＳ８０２の処理を行うことにより、ユーザが携帯端末１０１に生体認証でログインしている場合、ユーザは、該登録処理において生体情報の提示を行う必要がなくなる。例えば、ＦＩＤＯを用いたサービス提供システムでは、サービスを利用するために、サービスごとにオーセンティケータの登録を行う必要があり、サービスごとにその都度、生体情報の提示が求められる。
【０１０６】
しかし、本実施形態によれば、ユーザが携帯端末１０１に生体認証でログインしている場合、ログイン時に提示した生体情報を用いてオーセンティケータの登録が行われるため、ユーザは度々生体情報の提示を求められることがなくなる。このため、ユーザの利便性が向上する。
【０１０７】
＜サービスの認証処理＞
次に、図９および図１０を用いて、オーセンティケータ登録後のサービス３７０における認証処理について説明する。
以下、ユーザがサービス３７０を利用するために携帯端末１０１の連携アプリケーション３１０にログインする際にサービス３７０がユーザを認証する場合について説明する。連携アプリケーション３１０の表示部３１１が、連携アプリケーション３１０のトップ画面５３０のボタン５３２が押下されたことを検知すると、図９に示す処理が開始する。
【０１０８】
図９は、サーバ１０２のサービス３７０における認証処理のシーケンスを示す図である。
ステップＳ９０１で、連携アプリケーション３１０の通信部３１２は、サーバ１０２のサービス３７０に対して、生体認証パラメータの取得要求を行う。
【０１０９】
ステップＳ９０２で、サービス３７０のオーセンティケータ情報処理部３７２は、生体認証パラメータを作成する。生体認証パラメータは、サービス３７０が連携アプリケーション３１０のユーザの認証を行う際に使用するデータである。以下、生体認証パラメータについて説明する。
【０１１０】
図１０は、生体情報を用いた認証処理において、携帯端末１０１とサーバ１０２との通信に含まれるパラメータの一例を示す図である。
ここで、図１０（Ａ）を用いて生体認証パラメータについて説明する。生体認証パラメータ１０００は、Ａｓｓｅｒｔｉｏｎチャレンジ１００１およびＡｓｓｅｒｔｉｏｎ拡張領域１００２から構成される。
【０１１１】
Ａｓｓｅｒｔｉｏｎチャレンジ１００１には、チャレンジレスポンス認証を行うために利用する検証用データが格納される。Ａｓｓｅｒｔｉｏｎ拡張領域１００２には、サービス３７０が連携アプリケーション３１０やオーセンティケータ３２０等の動作を制御するために利用する、サービス３７０が指定可能な拡張パラメータが格納される。
【０１１２】
図９の説明に戻る。ステップＳ９０３で、サービス３７０の通信部３７３は、オーセンティケータ情報処理部３７２がステップＳ９０２で作成した生体認証パラメータ１０００を、連携アプリケーション３１０に返却するとともに、生体認証を要求する。ステップＳ９０４で、連携アプリケーション３１０のサービス認証制御部３１４は、オーセンティケータ３２０に対して、生体認証の要求を送信する。生体認証の要求には、Ａｕｔｈ生体認証パラメータを含める。以下、Ａｕｔｈ生体認証パラメータについて説明する。
【０１１３】
図１０（Ｂ）は、Ａｕｔｈ生体認証パラメータの一例を示す図である。
Ａｕｔｈ生体認証パラメータ１０１０は、生体認証パラメータ１０００、サービスＩＤ１０１１、およびＷｅｂＯｒｉｇｉｎ１０１２から構成される。生体認証パラメータ１０００は、サービス３７０からステップＳ９０４にて受信した生体認証パラメータ１０００である。サービスＩＤ１０１１およびＷｅｂＯｒｉｇｉｎ１０１２は、図７（Ｂ）のＡｕｔｈ登録パラメータ７２０のサービスＩＤおよびＷｅｂＯｒｉｇｉｎと同様である。
【０１１４】
図９の説明に戻る。ステップＳ９０５で、オーセンティケータ３２０の生体情報要求部３２４は、ユーザに対して生体情報の要求を行う。生体情報の要求では、ユーザに生体情報の入力を求める画面（不図示）が表示される。ステップＳ９０６で、オーセンティケータ３２０のサービス認証処理部３２３は、生体認証を行う。すなわち、ステップＳ９０５で取得された生体情報と、ＴＰＭ２０６に格納された生体情報との照合を行う。
【０１１５】
具体的には、サービス認証処理部３２３が、サービス認証情報管理テーブル（表Ｂ）において、ステップＳ９０５で取得された生体情報の特徴量と一致するレコードが生体情報ＩＤ列に存在するか判断する。生体情報の特徴量は、指紋のパターン・虹彩の模様・静脈の形・声紋など個人に対してユニークであるものを、ユニーク性を損なわないような値に変換したものである。
【０１１６】
生体認証では、個人に対してユニークな該特徴量を用いて個人を特定する。生体認証に失敗した場合、認証が失敗したことを連携アプリケーション３１０に通知し、連携アプリケーション３１０は、ユーザに対して生体認証に失敗したことを示すエラーメッセージ（不図示）を表示する。なお、図９において、生体認証は成功したものとする。ステップＳ９０７で、サービス認証処理部３２３は、Ａｓｓｅｒｔｉｏｎを作成する。Ａｓｓｅｒｔｉｏｎは、サービス３７０において、ユーザが不正な要求を行っていないことの検証に用いられるデータである。以下、Ａｓｓｅｒｔｉｏｎについて説明する。
【０１１７】
図１０（Ｃ）は、Ａｓｓｅｒｔｉｏｎの一例を示す図である。Ａｓｓｅｒｔｉｏｎ１０２０は、認証情報ＩＤ１０２１および署名１０２２から構成される。以下、サービス認証処理部３２３が、Ａｓｓｅｒｔｉｏｎ１０２０を構成する認証情報ＩＤ１０２１および署名１０２２を取得し、Ａｓｓｅｒｔｉｏｎ１０２０を作成する手順を説明する。
【０１１８】
ステップＳ７１７において、オーセンティケータ３２０のサービス認証処理部３２３がステップＳ９０５で表示した画面を介して取得した生体情報と、ＴＰＭ２０６に格納された生体情報との照合を行う。照合アルゴリズムは、特徴点抽出法やパターンマッチング法などが用いられるが、本発明では照合アルゴリズムを特に限定するものではない。
【０１１９】
具体的には、サービス認証処理部３２３は、取得した生体情報を基に、サービス認証情報格納部３２６が管理するサービス認証情報管理テーブル（表Ｂ）からレコードを特定する。取得した生体情報を示す生体情報ＩＤが特定されることから、サービス認証情報管理テーブル（表Ｂ）において、該生体情報に対応する認証情報ＩＤ１０２１および秘密鍵が特定される。すなわち、オーセンティケータ３２０が生体認証を実行し、認証成功であれば、秘密鍵が取り出される。
【０１２０】
そして、サービス認証処理部３２３は、Ａｕｔｈ生体認証パラメータ１０１０に含まれるＡｓｓｅｒｔｉｏｎチャレンジ１００１を、特定した秘密鍵を用いて署名１０２２（署名データ）を作成する。また、サービス認証処理部３２３は、特定した認証情報ＩＤ１０２１、作成した署名１０２２を含むＡｓｓｅｒｔｉｏｎ１０２０を作成する。
【０１２１】
図９の説明に戻る。ステップＳ９０８で、サービス認証処理部３２３は、ステップＳ９０７で作成したＡｓｓｅｒｔｉｏｎ１０２０を、連携アプリケーション３１０に返却する。ステップＳ９０９で、連携アプリケーション３１０の通信部３１２は、Ａｓｓｅｒｔｉｏｎ１０２０をサーバ１０２に送信する。
【０１２２】
ステップＳ９１０で、サービス３７０のオーセンティケータ情報処理部３７２は、ステップＳ９０９で受信したＡｓｓｅｒｔｉｏｎ１０２０の妥当性の検証を行う。具体的には、オーセンティケータ情報処理部３７２は、Ａｓｓｅｒｔｉｏｎ１０２０に含まれる署名１０２２を、Ａｓｓｅｒｔｉｏｎ１０２０に含まれる認証情報ＩＤ１０２１で特定できる公開鍵を用いて復号化する。
【０１２３】
そして、復号化した値が、ステップＳ９０２で作成した生体認証パラメータ１０００に含まれるＡｓｓｅｒｔｉｏｎチャレンジ１００１と一致するかの検証を行う。なお、公開鍵の特定には、オーセンティケータ情報管理テーブル（表Ｅ）を用いる。ステップＳ９１１で、サービス３７０のトークン管理部３７７は、ステップＳ９１０でＡｓｓｅｒｔｉｏｎ１０２０の検証を行ったユーザにトークンを発行し、該トークンに関する情報をトークン管理テーブル（表Ｆ）に格納する。
【０１２４】
ステップＳ９１２で、サービス３７０の通信部３７３は、ステップＳ９１１で発行したトークンを連携アプリケーション３１０に返却する。以降の処理において、連携アプリケーション３１０は、ステップＳ９１２で受信したトークンをサービス３７０への要求に含めることで、サービス３７０が提供する機能を利用することが可能となる。
【０１２５】
［第２実施形態］
第１実施形態では、オーセンティケータ登録時に必要な生体情報が１つの場合について説明した。これに対して、本実施形態では、オーセンティケータ登録時に、サーバ１０２のサービス３７０から複数の生体情報による生体認証を求められる場合について説明する。図６、図７、図１１、および図１２を用いて第１実施形態と異なる部分について説明する。
【０１２６】
図６に示すオーセンティケータ３２０をサービス３７０に登録する処理において、第１実施形態と異なる部分は、ステップＳ６０６の登録パラメータ作成の処理とステップＳ６０９のクレデンシャル作成の処理である。ステップＳ６０６で、サービス３７０のオーセンティケータ情報処理部３７２は、登録パラメータ７００を作成する。ここで、本実施形態と第１実施形態との差異は、本実施形態において作成する登録パラメータ７００の認証拡張領域７０４に、オーセンティケータ３２０に要求する生体認証の種類を指定する点である。
【０１２７】
例えば、サービス３７０が指紋認証と顔認証を要求する場合、認証拡張領域７０４には下記のような情報が格納される。
{ ’biometrics’ : [ ’fingerprint’, ’face’ ] }
このように、サービス３７０は、認証拡張領域７０４を利用してオーセンティケータ３２０に複数の生体情報の登録を要求する。
【０１２８】
次に、Ｓ６０９で、オーセンティケータ３２０のオーセンティケータ登録処理部３２１は、クレデンシャル７４０を作成する。ここで、本実施形態において実行するクレデンシャル作成処理について説明する。
図１１は、本実施形態において、オーセンティケータ３２０が実行するクレデンシャル作成処理について説明するフローチャートである。
【０１２９】
ステップＳ１１０１は、図８に示した第１実施形態におけるクレデンシャル作成処理のステップＳ８０１と同じ処理である。オーセンティケータ登録処理部３２１は、端末ユーザ認証処理部３２２を介して、ユーザが携帯端末１０１に生体認証でログインしているかを判断する。ユーザが生体認証でログインしているユーザが生体認証でログインしている場合、処理はステップＳ１１０２に進み、生体認証でログインしていない場合、処理はステップＳ１１０５に進む。
【０１３０】
ステップＳ１１０２で、オーセンティケータ登録処理部３２１は、ユーザが携帯端末１０１へのログインに用いた生体情報の種類と、ステップＳ６０６で作成された登録パラメータ７００の認証拡張領域７０４で指定された生体情報の種類が一致するか判断する。ユーザが携帯端末１０１へのログインに用いた生体情報の種類は、端末ユーザ認証処理部３２２を介して、端末ユーザ情報テーブル（表Ａ）からログイン状態列の値がｌｏｇｉｎのレコードの、認証方法列の値から取得できる。
【０１３１】
ログインに用いた生体情報の種類と認証拡張領域７０４で指定された生体情報の種類とが一致する場合は、処理はステップＳ１１０３に進み、一致しない場合、処理はステップＳ１１０５に進む。ステップＳ１１０３で、オーセンティケータ登録処理部３２１は、端末ユーザ認証処理部３２２を介して、端末ユーザ情報テーブル（表Ａ）から生体認証でログインしているユーザの生体情報ＩＤを取得する。
【０１３２】
ステップＳ１１０４で、オーセンティケータ登録処理部３２１は、ステップＳ６０６で作成された登録パラメータ７００の認証拡張領域７０４で指定された生体情報の種類に対応する生体情報ＩＤを取得済みか判断する。例えば、携帯端末１０１にログインした際に用いた生体情報の種類が指紋情報であり、ステップＳ６０６で作成された登録パラメータ７００の認証拡張領域７０４で指定された生体情報の種類が指紋情報および顔情報であったとする。この場合、顔情報に対応する生体情報ＩＤが取得できていないと判断する。
【０１３３】
生体情報ＩＤが取得済みであると判断した場合、処理はステップＳ１１０８に進み、生体情報ＩＤが取得されていないと判断した場合、処理はステップＳ１１０５に進む。ステップＳ１１０５で、生体情報要求部３２４は、ユーザに生体情報の入力を促す生体情報の要求画面を表示する。
【０１３４】
図１２は、生体情報の要求画面の一例を示す図である。
要求画面１２０２は、オーセンティケータ３２０の生体情報要求部３２４が表示するＵＩである。要求画面１２０２は、ボタン１２０３およびボタン１２０４から構成される。ボタン１２０３は、ユーザに対して指紋情報の登録を要求するためのボタンである。生体情報要求部３２４は、ボタン１２０３が押下されたことを検知すると、生体情報の入力をユーザに促す図５（Ｄ）の同意画面５９０に遷移する。
【０１３５】
そして、上述したボタン５０４において指が添えられると指紋情報が生体情報センサ２０８により読み取られる。なお、すでに指紋情報に対応する生体情報ＩＤが取得済みの場合、要求画面１２０２にボタン１２０３は表示されない。ボタン１２０４は、ユーザに対して顔情報の登録を要求するためのボタンである。
【０１３６】
生体情報要求部３２４は、ボタン１２０４が押下されたことを検知すると、カメラ１２０１を起動し、顔情報を読み取る。カメラ１２０１は、生体情報センサ２０８を備え、オーセンティケータ３２０は、カメラ１２０１により読み取られた顔情報を取得する。なお、すでに顔情報に対応する生体情報ＩＤが取得済みの場合、要求画面１２０２にボタン１２０４は表示されない。
【０１３７】
なお、要求画面１２０２は一例であり、これに限られるものではない。要求画面１２０２には、ボタン１２０３やボタン１２０４以外の、他の生体情報を登録するためのボタンを表示してもよい。要求画面１２０２には、ステップＳ６０６で作成された登録パラメータ７００の認証拡張領域７０４で指定された生体情報の種類にそれぞれ対応する登録ボタンが表示される。
【０１３８】
図１１の説明に戻る。ステップＳ１１０６で、生体情報要求部３２４は、ボタン５０４やカメラ１２０１等を介して生体情報の入力を検知するまで監視する。生体情報が入力された場合、処理はステップＳ１１０７に進む。ステップＳ１１０７で、生体情報要求部３２４は、ボタン５０４やカメラ１２０１等が備える生体情報センサ２０８が読み取った生体情報の特徴量と該生体情報を一意に識別するための生体情報ＩＤを作成する。
【０１３９】
ステップＳ１１０８で、オーセンティケータ登録処理部３２１は、秘密鍵および公開鍵のペアを作成する。そして、オーセンティケータ登録処理部３２１は、サービス認証情報格納部３２６に対してＴＰＭ２０６に格納されているサービス認証情報管理テーブル（表Ｇ）に、各種情報を格納する。以下、表Ｇを用いて、本実施形態において、サービス認証情報管理テーブルに格納する各種情報について説明する。
【０１４０】
【表７】
2019096077.tif 000009
【０１４１】
表Ｇのサービス認証情報管理テーブルは、本実施形態において、認証情報に含まれる各種情報を格納するテーブルである。表Ｇと、表Ｂに示した第１実施形態におけるサービス認証情報管理テーブルとの差異は、表Ｇには認証方法列が追加されている点である。認証方法列には、認証情報を作成する際に用いた生体情報の種類が格納されている。
【０１４２】
例えば、ステップＳ６０６で作成された登録パラメータ７００の認証拡張領域７０４で指定された生体情報の種類が指紋情報と顔情報の場合、ステップＳ１１０８では、表Ｇの１行目と２行目に示すように２つのエントリが書き込まれる。２つのエントリで異なるのは、認認証方法列と生体情報ＩＤ列の値である。すなわち、本実施形態では、登録パラメータ７００において、複数の生体認証の種類が指定された場合、該登録パラメータ７００に基づいて作成される複数のクレデンシャルの認証情報ＩＤおよび公開鍵は共通の値を使用する。
【０１４３】
このように、オーセンティケータを登録する対象のサービスにおいて、認証時に２つ以上の種類の生体認証を要求する場合、サービス認証情報管理テーブルにおいて、対応するエントリの認証情報ＩＤや秘密鍵を共通の値にしておく。これにより、対象のサービスにおいて、複数の生体認証が必要であることがわかる。表Ｂに示す例では、サービスＩＤが「service.com」に対して、１行目のエントリと２行目のエントリが示すように、指紋認証と顔認証が必要であることが判断できる。
【０１４４】
また、複数のエントリにおいて共通の認証情報ＩＤおよび秘密鍵が使用されることから、秘密鍵に対応する公開鍵も共通のものが使用される。すなわち、ステップＳ６１０において、サービス３７０に返却されるクレデンシャルは、サービス認証情報管理テーブルにおいて、該当の複数のエントリに対して共通のものである。
【０１４５】
図１１の説明に戻る。ステップＳ１１０９で、オーセンティケータ登録処理部３２１は、クレデンシャル７４０を作成し、図１１に示す処理を終了する。
【０１４６】
このように、本実施形態によれば、複数の生体情報による生体認証を要求するサービスに対してオーセンティケータを登録する場合であっても、ユーザが携帯端末１０１にログインした際に提示した生体情報を用いてユーザの登録作業に係る負荷を軽減できる。
【０１４７】
［その他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【０１４８】
以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。
【図１】
2019096077.tif 000010
【図２】
2019096077.tif 000011
【図３】
2019096077.tif 000012
【図４】
2019096077.tif 000013
【図５】
2019096077.tif 000014
【図６】
2019096077.tif 000015
【図７】
2019096077.tif 000016
【図８】
2019096077.tif 000017
【図９】
2019096077.tif 000018
【図１０】
2019096077.tif 000019
【図１１】
2019096077.tif 000020
【図１２】
2019096077.tif 000021