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

Abstract

【課題】情報処理装置の初期化に際して、外部のサーバに登録された情報処理装置の登録情報を、ユーザの負担を低減しつつ確実に解除することが可能な情報処理装置を提供する。【解決手段】携帯端末１０７は、生体認証のためのオーセンティケータと、生体認証に必要なユーザの生体情報と該生体情報について生成された秘密鍵とを記憶する記憶手段を有する。ＯＳの初期化に際して、秘密鍵のペアとなる公開鍵を含む登録情報が登録されるサーバ１０１に対して、登録解除ＵＲＬを用いて登録解除要求Ｓ７０６を送信する。サーバから、認証パラメータ返却Ｓ７０８がされたならば、生体情報センサにより読み取られた生体情報を用いたオーセンティケータによる生体認証Ｓ７１０の認証成功に応じて取り出された秘密鍵により生成されたＡｓｓｅｒｔｉｏｎが送信Ｓ７１２される。サーバは、Ａｓｓｅｒｔｉｏｎ検証Ｓ７１３に成功した場合、登録解除処理Ｓ７１４を行う。【選択図】図７

Description

本発明は、サーバに登録された携帯端末やＰＣ、プリンタなどのデバイスの登録情報を解除する方法に関する。

近年、生体認証を含む新たな認証システムとして、ＦＩＤＯ（Ｆａｓｔ Ｉｄｅｎｔｉｔｙ Ｏｎｌｉｎｅ）が注目されている。生体認証で用いられる指紋や静脈といった生体情報は、外部に情報が流出してしまった場合に、従来のＩＤ／パスワード認証におけるパスワードと異なり、情報を書き換えることができないため情報漏洩が致命的になる。

これに対して、ＦＩＤＯは予めユーザの手元の端末とＷｅｂサービスを提供するサーバとの間で登録処理を行っておく。登録処理では、端末にはユーザの生体認証と紐付いた秘密鍵が保存され、サーバにはその生体認証に紐付く認証識別情報や秘密鍵のペアとなる公開鍵などの情報が登録される。そして、認証はインターネットを経由してサーバ上で行うのではなく、ユーザの手元のデバイス上で行い、ネットワーク上には秘密鍵で署名された認証結果が流れる。つまり、生体情報がネットワーク上を流れることがないため、情報漏洩のリスクが少ないと言える。

ＰＣやプリンタなどの機器の情報を管理装置（サーバ）にあらかじめ登録しておくことで、機器を管理するシステムが存在する。このようなシステムでは、ＦＩＤＯと同様に、登録時に作成した秘密鍵と公開鍵を用いて認証することが多い。そして、管理装置が機器から情報を取得し、あるいは、機器側のイベント発生時に管理装置に対して機器情報が送信されるなどして機器情報を管理している。

このような構成のシステムは、例えば、機器の廃棄やリプレイスなどに際して機器がサーバの管理下から外れるときには、管理ユーザはサーバから対象の機器の登録を解除する必要がある。しかし、廃棄される機器が多い場合や機器が点在している場合などに、廃棄対象の機器と実際の機器が一致することを確認した上で登録解除処理を行うのは、確認作業に時間を要する上に、確認漏れも起こりやすい。

特許文献１は、ネットワーク環境下において、資産管理サーバが自身に登録された資産機器に対して定期的に情報を取得することを試み、機器情報が取得できないと判断した場合、ユーザに対象機器の廃棄確認を行う資産管理システムを開示している。

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

ＦＩＤＯのようなサーバにユーザの認証情報に紐付く情報や、機器情報などを登録してＷｅｂ上のサービスを利用するシステムにおいても、端末を廃棄する際などにはサーバから端末の登録を解除することが望ましい。なぜなら、サービスが提供するアカウントに不要になった登録情報が残り続けてしまうだけでなく、一つのアカウントに登録できる端末数に上限が設けられている場合もあるからである。

しかしながら、解除処理を行うにあたり、端末のユーザはどのサービスに登録したかを忘れてしまっていたり、そもそもＦＩＤＯのような認証システムを利用していることを意識していなかったりする可能性もあるため、確実に登録を解除することは難しい。

特許文献１では、管理装置が機器の情報を定期的に取得することでユーザに廃棄確認を行うため、機器と管理装置がＷＡＮやＬＡＮなどで常時接続しているようなネットワークの接続形態を想定している。しかし、ＦＩＤＯのような認証システムの場合、個人向けのスマートフォンやＰＣなどでの利用が多く、電源が切られていたり、オフライン状態であったりすることも多々あるため、必ずしも常時接続しているとは限らない。

また、スマートフォンやＰＣの場合、Ｗｅｂブラウザやネイティブアプリケーションを介してＷｅｂサーバと通信するが、プラットフォームの性質上、アプリケーションを常時起動し、サーバと常時通信するのが難しいアプリケーションも存在する。

本発明は、情報処理装置の初期化に際して、外部のサーバに登録された情報処理装置の登録情報を、ユーザの負担を低減しつつ確実に解除することが可能な情報処理装置の提供を目的とする。

本発明の一実施形態の情報処理装置は、生体情報センサにより読み取った生体情報を用いた生体認証のための認証モジュールと、前記認証モジュールにより認証処理を行う際に必要なユーザの生体情報と該生体情報について生成された秘密鍵とを記憶する耐タンパー性を備える記憶手段と、を有する情報処理装置であって、前記情報処理装置のＯＳの初期化に際して、前記秘密鍵のペアとなる公開鍵を含む登録情報が登録される外部のサーバに対して、該登録情報の登録解除のための要求先の情報を用いて、前記登録解除の要求を送信する要求手段を有し、前記サーバから登録解除のための認証要求を受信した際に、前記生体情報センサにより読み取られた生体情報を用いた前記認証モジュールによる生体認証での認証成功に応じて取り出された前記秘密鍵により、署名が生成され、該署名が前記サーバに送信されることで検証に成功した場合に、前記サーバで、前記登録情報についての登録解除が行われる。

本発明の情報処理装置によれば、情報処理装置の初期化に際して、外部のサーバに登録された情報処理装置の登録情報を、ユーザの負担を低減しつつ確実に解除することができる。

システムのネットワーク構成を示す図である。 サーバ、ＰＣ、および携帯端末のハードウェア構成例を示す図である。 携帯端末およびＰＣのソフトウェア構成例を示す図である。 オーセンティケータをサーバに登録する処理のシーケンスを示す図である。 オーセンティケータの登録時に使用するパラメータの一例を示す図である。 オーセンティケータの登録時に表示される画面の一例を示す図である。 オーセンティケータの登録解除を行う処理のシーケンスを示す図である。 登録解除に関わる認証時に使用するパラメータの一例を示す図である。 携帯端末において初期化を行う際の画面遷移の一例を示す図である。 携帯端末の初期化後にサービスが表示する画面の一例を示す図である。 システムのネットワーク構成およびソフトウェア構成を示す図である。 携帯端末の初期化に伴う動作を示すフローチャートである。 携帯端末の初期化にサービスが表示する画面の一例を示す図である。

以下、本発明を実施するための形態について図面などを参照して説明する。
なお、本発明はＷｅｂ上のサービスがユーザを認証するために、ユーザの保有する端末上で生体認証を行い、その結果を以ってサービスがユーザを認証する仕組みに関するものである。これは、Ｗｅｂ上のサービスにユーザの保有する端末での生体認証に紐付く情報、例えば、認証識別情報、公開鍵などをあらかじめ登録しておくことで実現することができる。このような仕組みの一例としてＦＩＤＯを挙げたが、本発明はＦＩＤＯに限定したものではないことをあらかじめ断わっておく。

［第１実施形態］
図１は、本システムのネットワーク構成例を示す図である。
情報処理装置１０４は、光回線などでプロバイダ１０３と通信し、プロバイダ１０３を介してインターネット１０２と繋がるＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）やプリンタ、複合機などの情報処理装置である。本実施形態では、情報処理装置１０４をＰＣ１０４として説明を進める。

情報処理装置１０７は、基地局１０６と無線で通信し、コアネットワーク１０５を介してインターネット１０２と繋がる端末で、例えばタブレットやスマートフォン、ノートＰＣなどである。情報処理装置１０７には、無線通信機能を備えたデスクトップＰＣやプリンタなども含まれる。本実施形態では、情報処理装置１０７を携帯端末１０７として説明を進める。

サーバ１０１は、インターネット１０２を介し、各情報処理装置にＷｅｂコンテンツやＷｅｂ ＡＰＩを提供するシステムである。なお、以下、ＰＣ１０４や携帯端末１０７などのサーバ１０１に対するクライアント装置を単にデバイスと呼ぶ。

図２（Ａ）は、サーバ１０１、ＰＣ１０４のハードウェア構成例を示す図である。
ＣＰＵ２０１は、ＲＡＭ２０２をワークメモリとして、ＲＯＭ２０３および記憶装置２１０に格納されたプログラムを実行し、内部バス２１１を介して後述する各構成を制御する。キーボードコントローラ２０４は、キーボード２０８や不図示のポインティングデバイス（マウス、タッチパッド、タッチパネル、トラックボールなど）からの操作入力を制御する。

ディスプレイコントローラ２０５は、ディスプレイ２０９の表示を制御する。ディスクコントローラ２０６は、各種データを記憶するハードディスク（ＨＤ）、フレキシブルディスク（ＦＤ）等の記憶装置２１０へのデータアクセスを制御する。ネットワークインタフェース２０７は、ＬＡＮなどのネットワークに接続されて、ネットワークに接続された他の機器との通信を制御する。ハードウェアを構成する各部２０１〜２０７は、内部バス２１１を介して接続されている。

図２（Ｂ）は、携帯端末１０７のハードウェア構成例を示す図である。
図２（Ｂ）の携帯端末１０７は、サーバ１０１やＰＣ１０４を構成する基本的なハードウェアに加え、無線通信機能をさらに備える。ＣＰＵ２２１、ＲＡＭ２２２、ＲＯＭ２２３は、図２（Ａ）のＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３と同様の機能を有する。

記憶装置２２４は、ソリッドステートドライブ（ＳＳＤ）やＳＤメモリカードなどの記憶装置であり、記憶装置２１０と同様に各種データを記憶する。ネットワークインタフェース２２５は、ネットワークに接続された他の機器との通信の制御に加え、無線通信機能を備える。

Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ（ＴＰＭ）２２６は、機密情報を処理したり格納したりする目的で、格納したデータを外部から読み取られることを防ぐ耐タンパー性を備えた記憶手段である。ＴＰＭ２２６は、生体情報センサ２２７で入力した生体情報や携帯端末１０７内で生成した秘密鍵を記憶すると共に、記憶している生体情報と入力された生体情報とを検証する機能を有する。なお、ＰＣ１０４がＴＰＭ２２６を有していてもよい。

生体情報センサ２２７は、ユーザの指紋、静脈、顔などの生体情報を読み取るセンサである。タッチパネル２２８は、ディスプレイ機能とポインティング機能の両方を備えた装置であり、ディスプレイに表示されたオブジェクトをユーザが指やタッチペンなどで操作することができる。なお、タッチパネル２２８は、一部ないしは全面が指紋や静脈などの生体情報センサになっているようなタッチパネルでもよく、その場合、タッチパネル２２８に生体情報センサ２２７が備わっている構成となる。

図３（Ａ）はＰＣ１０４、携帯端末１０７のソフトウェア構成例を示す図である。
以下、携帯端末１０７のハードウェア構成をもとに説明を進めるが、ＰＣ１０４についても同様である。連携アプリケーション３１０および初期化アプリケーション３２０は、ＣＰＵ２２１が、ＲＯＭ２２３に格納されたプログラムをＲＡＭ２２２に読み出して実行することで実現される。

連携アプリケーション３１０は、サーバ１０１と連携して、認証機能やサーバ１０１のサービスをユーザに提供する。連携アプリケーション３１０は、携帯端末１０７にインストールされたネイティブアプリケーションやＷｅｂブラウザである。表示部３１１は、タッチパネル２２８を介してユーザにＵＩを提供するためのソフトウェアモジュールである。通信部３１２は、ネットワークインタフェース２２５を介してサーバ１０１などの外部の機器と通信するためのソフトウェアモジュールである。

オーセンティケータ登録制御部３１３は、オーセンティケータ３３０に対して後述するクレデンシャルの作成要求を行うソフトウェアモジュールである。なお、本実施形態では、オーセンティケータ登録制御部３１３は、連携アプリケーション３１０に含まれるが、これに限られるものではない。例えば、オーセンティケータ登録制御部３１３を、連携アプリケーション３１０とは独立して構成し、連携アプリケーション３１０が、独立したオーセンティケータ登録制御部３１３を呼び出すようにしてもよい。

また、オーセンティケータ登録制御部３１３は、ＯＳに標準搭載されていてもよい。このように、オーセンティケータ登録制御部３１３をアプリケーションから独立させることで、連携アプリケーション３１０だけでなく、他のアプリケーションがオーセンティケータ登録制御部３１３を呼び出せるような構成にすることができる。

オーセンティケータ認証制御部３１４は、オーセンティケータ３３０に対して認証処理を要求したり、認証時にサーバ１０１に対して送信するリクエストを生成したりする。オーセンティケータ認証制御部３１４が行う具体的な処理フローに関しては後述する。なお、オーセンティケータ認証制御部３１４に関してもオーセンティケータ登録制御部３１３と同様に、連携アプリケーション３１０から独立して構成してもよい。

初期化アプリケーション３２０は、携帯端末１０７内のデータをＯＳレベルで初期化するアプリケーションである。ＯＳレベルで初期化とは、初期化によって、ユーザがインストールしたアプリケーションとそれに関連するデータ、およびＯＳの基本設定情報などが削除されることをいう。なお、初期化により、ＴＰＭ２２６に格納されている生体情報や携帯端末１０７内で生成した秘密鍵なども削除される。

本実施形態では、初期化アプリケーション３２０は、ＯＳに標準搭載されていることを想定しているが、ユーザによってインストールされたアプリケーションであっても初期化アプリケーションと同等の機能を有するアプリケーションであれば代替可能である。

表示部３２１は、ユーザからの初期化要求を受けて、初期化に関する操作を行うためのＵＩをユーザに提供する。初期化部３２２は、携帯端末１０７の初期化処理を実行する。オーセンティケータ認証情報取得部３２３は、ＴＰＭ２２６に格納された各種データを取得する。オーセンティケータ認証情報取得部３２３の詳細については、後述する。

オーセンティケータ３３０は、生体情報センサ２２７により読み取った生体情報を用いた生体認証のための認証モジュールである。オーセンティケータ登録処理部３３１は、連携アプリケーション３１０のオーセンティケータ登録制御部３１３などからクレデンシャルの作成要求を受け付け、ペアの鍵（秘密鍵および公開鍵）の作成やクレデンシャルの作成を行うソフトウェアモジュールである。

生体認証処理部３３２は、連携アプリケーション３１０のオーセンティケータ認証制御部３１４などから生体認証要求を受け付けて、生体情報センサ２２７により読み取った生体情報を用いた生体認証を行うソフトウェアモジュールである。認証情報格納部３３３は、認証情報などをＴＰＭ２２６に対して格納するソフトウェアモジュールである。認証情報は、例えば、後述する表Ａや表Ｂに示す情報である。生体情報要求部３３４は、生体情報の入力を受け付けるためのＵＩを、タッチパネル２２８を介してユーザに提供するソフトウェアモジュールである。

＜携帯端末１０７側のテーブルの例＞
以下、表Ａおよび表Ｂを用いて、携帯端末１０７がＴＰＭ２２６に格納する各種データについて説明する。詳細には、表Ａおよび表Ｂが示すテーブルデータは、携帯端末１０７が有するオーセンティケータ３３０の認証情報格納部３３３がＴＰＭ２２６に格納するデータである。

表Ａの認証情報管理テーブルは、１つのレコードが１つの認証情報のエントリを示す。表Ａのレコードは、オーセンティケータ３３０をサービスに登録する際に作成され、表Ａに追加される。認証情報ＩＤ列には、各認証情報を一意に識別するためのＩＤを格納する。サービスＩＤ列には、後述するサーバ１０１が備えるサービスを一意に識別するためのＩＤを格納する。本実施形態では、サービスＩＤとしてサービス３４０のドメイン名を使用する。

ユーザＩＤ列には、レガシー認証等で使用する、サービス３４０がユーザを一意に識別するためのＩＤを格納する。秘密鍵列には、作成されたペアの鍵のうち、秘密鍵を格納する。秘密鍵に対応する（ペアとなる）公開鍵は、サービスＩＤ列に示されるサービスに登録される。生体情報ＩＤ列には、生体情報の特徴量に対応するＩＤを格納する。認証情報管理テーブルの各列に対応する情報を格納する手順、および公開鍵をサービス３４０に格納する手順については後述する。

表ＢのＡＰＩ管理テーブルは、サービス３４０にオーセンティケータ３３０の登録解除を要求する際に利用するテーブルである。なお、ＡＰＩ管理テーブルは、表Ａに結合された１つのテーブルとしてもよい。ＡＰＩ管理テーブルは、１つのレコードが認証情報ごとの各サービスに対する登録解除のＡＰＩのエントリを示している。表Ａと同様に、表Ｂのレコードは、オーセンティケータ３３０をサービスに登録する際に作成され、表Ｂに追加される。

認証情報ＩＤおよびサービスＩＤの各列は、表Ａの各列と同様である。アプリＩＤ列には、オーセンティケータ３３０をサービス３４０に登録した際に使用した連携アプリケーション３１０を一意に特定するアプリケーションＩＤ（以下、アプリＩＤ）を格納する。アプリＩＤは、連携アプリケーション３１０のオーセンティケータ登録制御部３１３が、後述するクレデンシャルの作成要求をオーセンティケータ３３０に行う際に渡される。

アプリＩＤは、携帯端末１０７内でアプリケーションごとに一意な値であり、携帯端末１０７にインストールされた他のアプリケーションから、アプリＩＤに対応するアプリケーションを起動するために用いられる。アプリＩＤ等のアプリケーションを識別するためのＩＤを用いて、あるアプリケーションから別のアプリケーションを起動する技術として、ＵＲＬスキーム、インテント等がある。

また、あるアプリケーションからアプリＩＤを用いて別のアプリケーションを起動する際に、パラメータを使用して該別のアプリケーションを起動することも可能である。なお、連携アプリケーション３１０がネイティブアプリケーションの場合、アプリＩＤとして表Ｂの１、２行目のようにネイティブアプリケーションのアプリＩＤが格納される。また、連携アプリケーション３１０がＷｅｂブラウザの場合、アプリＩＤとして表Ｂの３行目のようにＷｅｂブラウザのアプリＩＤが格納される。

登録解除ＵＲＬ列には、オーセンティケータ３３０の登録解除を要求するための要求先（ＵＲＬ）を格納する。登録解除を要求する際に、連携アプリケーション３１０は、登録解除ＵＲＬ対して要求を送信する。登録解除ＵＲＬは、オーセンティケータ３３０をサービス３４０に登録する際に、該サービス３４０から連携アプリケーション３１０を介して渡される。なお、登録解除ＵＲＬは、サービス３４０からレスポンスとして渡されるものであり、サービス３４０によってはサポートしていない場合もある。したがって、表Ｂの２行目のように登録解除ＵＲＬが存在しない（ｎｕｌｌ）場合もある。

なお、表ＢはＡＰＩ管理テーブルの一例であり、上述した列の他にデータを格納してもよい。例えば、登録解除ＵＲＬにＵＲＬパラメータを持たせたい場合などを考慮して、ＡＰＩ管理テーブルを拡張してもよい。

図３（Ｂ）は、サーバ１０１のソフトウェアの構成例を示す図である。
サービス３４０は、Ｗｅｂサービスであり、ＣＰＵ２０１が、ＲＯＭ２０３に格納されたプログラムをＲＡＭ２０２に読み出して実行することで実現される。なお、本実施形態では、生体認証と区別するために、ユーザＩＤとパスワードの一致を検証する認証をレガシー認証と記載する。

レガシー認証処理部３４１は、通信部３４３が受信したレガシー認証要求に含まれるユーザＩＤとパスワードとが、ユーザ情報格納部３４４に格納されているユーザＩＤとパスワードと一致するかを検証するソフトウェアモジュールである。

オーセンティケータ情報処理部３４２は、通信部３４３が受信したクレデンシャルを用いて、オーセンティケータ３３０に関する情報を、オーセンティケータ情報格納部３４５に格納するソフトウェアモジュールである。また、オーセンティケータ情報処理部３４２は、通信部３４３が受信した後述するアサーション情報（Ａｓｓｅｒｔｉｏｎ）を検証する。

通信部３４３は、ネットワークインタフェース２０７を介して、携帯端末１０７などの外部の機器と通信するためのソフトウェアモジュールである。例えば、通信部３４３は、携帯端末１０７から各種要求を受け付ける。ユーザ情報格納部３４４は、表Ｃを用いて後述するユーザ情報を、記憶装置２１０や外部のストレージシステム（不図示）に格納するソフトウェアモジュールである。

オーセンティケータ情報格納部３４５は、表Ｅを用いて後述するオーセンティケータ３３０に関する情報（オーセンティケータ情報）を記憶装置２１０や外部のストレージシステム（不図示）に格納するソフトウェアモジュールである。拡張リクエスト処理部３４６は、携帯端末１０７から送信された登録解除の要求を受け付け、該要求を処理するためのソフトウェアモジュールである。要求を受け付けるタイミングや処理の内容についての詳細は後述する。

プレゼンテーション部３４７は、通信部３４３が受信したオーセンティケータの登録および解除を行うためなどの各種画面の取得要求に応じて、ＨＴＭＬやＣＳＳ、ＪａｖａＳｃｒｉｐｔ（登録商標）などを生成するソフトウェアモジュールである。トークン管理部３４８は、後述するトークンの発行や検証を行うソフトウェアモジュールである。

＜サーバ１０１側のテーブルの例＞
以下、表Ｃ〜表Ｆを用いて、サーバ１０１が格納する各種データについて説明する。詳細には、表Ｃ〜表Ｆに示すテーブルデータは、サーバ１０１が有するサービス３４０の各ソフトウェアモジュールが、記憶装置２１０や外部のストレージシステム（不図示）に格納するデータである。

表Ｃのユーザ情報管理テーブルは、サービス３４０のユーザ情報格納部３４４が管理するデータである。ユーザ情報管理テーブルは、１つのレコードが１つのユーザ情報を示す。ユーザＩＤ列には、サービス３４０のユーザを一意に識別するためのＩＤを格納する。パスワード列には、ユーザを認証するためのパスワードを格納する。メールアドレス列には、ユーザのメールアドレスを格納する。なお、ユーザ情報管理テーブルには、ユーザ情報として、メールアドレス以外にもユーザの住所など、ユーザに関する属性情報を格納してもよい。

表Ｄのａｔｔｅｓｔａｔｉｏｎチャレンジ管理テーブルは、サービス３４０のユーザ情報格納部３４４が管理するデータである。ａｔｔｅｓｔａｔｉｏｎチャレンジ管理テーブルは、１つのレコードが１つのａｔｔｅｓｔａｔｉｏｎチャレンジの情報を示す。ａｔｔｅｓｔａｔｉｏｎチャレンジは、チャレンジレスポンス認証を行うための検証用データとして利用するパラメータであり、ユーザごとに発行される。

ａｔｔｅｓｔａｔｉｏｎチャレンジの発行処理については後述する。ａｔｔｅｓｔａｔｉｏｎチャレンジ列には、ａｔｔｅｓｔａｔｉｏｎチャレンジの値を格納する。ユーザＩＤ列には、ａｔｔｅｓｔａｔｉｏｎチャレンジを発行したユーザのユーザＩＤを格納する。有効期限列には、ａｔｔｅｓｔａｔｉｏｎチャレンジの有効期限を格納する。

表Ｅのオーセンティケータ情報管理テーブルは、サービス３４０のオーセンティケータ情報格納部３４５が管理するデータである。オーセンティケータ情報管理テーブルは、１つのレコードが１つのオーセンティケータ情報を示す。オーセンティケータ３３０の登録を行うと、オーセンティケータの情報管理テーブルにレコードが追加される。認証情報ＩＤ列には、登録されたオーセンティケータ３３０が認証情報管理テーブル（表Ａ）にて管理する認証情報の認証情報ＩＤ列の値が格納される。

デバイス名列には、オーセンティケータ３３０が搭載されているデバイスの名前を格納する。デバイス名は、ユーザが設定可能な属性である。公開鍵列には、オーセンティケータ３３０が作成し、認証情報管理テーブル（表Ａ）にて管理する秘密鍵に対応する（ペアになる）公開鍵を格納する。

すなわち、認証情報管理テーブル（表Ａ）とオーセンティケータ情報管理テーブル（表Ｅ）において認証ＩＤの値が同一の秘密鍵と公開鍵では、表Ａの秘密鍵で暗号化されたデータは、表Ｅの公開鍵で復号化できるということである。ユーザＩＤ列には、サービス３４０がユーザを一意に識別するためのＩＤを格納する。

表Ｆのトークン管理テーブルは、サービス３４０のユーザ情報格納部３４４が管理するデータである。トークンは、本実施形態において、後述する生体情報を用いた一連の認証処理が成功した結果、サービス３４０が発行する。連携アプリケーション３１０は、サービス３４０を利用する際に、発行されたトークンを付与して要求を送信することで、サービス３４０が提供するサービスを利用することができる。

トークン管理テーブルは、１つのレコードが１つのトークンの情報を示す。トークン列には、トークンを格納する。ユーザＩＤ列には、サービス３４０がユーザを一意に識別するためのＩＤを格納する。有効期限列には、トークンの有効期限を格納する。サービス３４０は、ユーザからの要求に付与されたトークンが、トークン管理テーブルのトークン列に存在し、有効期限列の有効期限を過ぎていない場合に、該要求を受け付ける。

次に、図４〜図６を用いて、デバイスのオーセンティケータ３３０をサーバ１０１のサービス３４０に登録する処理について説明する。
以下、デバイスが携帯端末１０７の場合について説明するが、デバイスがＰＣ１０４であっても同様である。なお、オーセンティケータ３３０の情報をサービス３４０に登録することを、単にオーセンティケータの登録と呼ぶ。

図４は、サービス３４０にオーセンティケータ３３０を登録する処理のシーケンスを示す図である。
まず、Ｓ４０１で、携帯端末１０７の連携アプリケーション３１０からサーバ１０１のサービス３４０に対して、登録画面を要求する。なお、登録画面とは、連携アプリケーション３１０がＷｅｂブラウザの場合はＨＴＭＬやＪａｖａＳｃｒｉｐｔなどのファイルであり、登録に際して必要となる画面をデバイスにおいて表示させるためのデータである。

登録画面には、各種プログラムやデータを含みうる。Ｓ４０２で、サービス３４０は、Ｓ４０１の要求に対してレガシー認証を行うための画面を返却する。Ｓ４０３で、連携アプリケーション３１０は、表示部３１１を介してレガシー認証画面を表示し、ユーザからＩＤ／パスワードを受け付ける。そして、連携アプリケーション３１０は、表示部３１１を介してユーザから受け付けたＩＤ／パスワードをサービス３４０に送信する。

Ｓ４０４で、サービス３４０のレガシー認証処理部３４１は、受信したＩＤ／パスワードの検証を行う。レガシー認証の結果がエラーで合った場合、レガシー認証処理部３４１は、連携アプリケーション３１０に認証エラーを返却する。なお、図４において、レガシー認証は成功したものとする。Ｓ４０５で、サービス３４０のトークン管理部３４８は、トークンを発行し、ユーザ情報格納部３４４は、該トークンに関する情報をトークン管理テーブル（表Ｆ）で管理する。

Ｓ４０６で、オーセンティケータ情報処理部３４２は、登録パラメータを作成する。登録パラメータは、サーバ１０１がオーセンティケータ３３０の登録処理を実行する際に使用するデータである。連携アプリケーションを介してオーセンティケータ３３０が該登録パラメータを受け取り、登録パラメータに含まれるデータを用いてクレデンシャルを作成する。そして、サーバ１０１は、連携アプリケーション３１０を介してクレデンシャルを受け取り、該クレデンシャルに基づき、連携アプリケーション３１０からの登録要求が不正な要求でないことを検証する。以下、登録パラメータについて説明する。

図５は、オーセンティケータ３３０の登録において、携帯端末１０７とサーバ１０１との通信に含まれるパラメータの一例を示す図である。
ここで、図５（Ａ）を用いて登録パラメータについて説明する。登録パラメータ５１０は、アカウント情報５１１、暗号化パラメータ５１２、ａｔｔｅｓｔａｔｉｏｎチャレンジ５１３、認証拡張領域５１４から構成される。

アカウント情報５１１には、サービス３４０における、Ｓ４０４のレガシー認証で特定したユーザＩＤや、該ユーザＩＤと紐付くメールアドレスなどユーザに関する属性情報が格納される。暗号化パラメータ５１２には、サービス３４０がサポートしている暗号化アルゴリズムなど、登録する認証情報に関する属性情報が格納される。ａｔｔｅｓｔａｔｉｏｎチャレンジ５１３には、チャレンジレスポンス認証を行うために利用する検証用データが格納される。

検証用データすなわちａｔｔｅｓｔａｔｉｏｎチャレンジ５１３は、Ｓ４０６にて登録パラメータを作成する際に作成され、ａｔｔｅｓｔａｔｉｏｎチャレンジ管理テーブル（表Ｄ）にユーザＩＤや有効期限などと紐付けて格納される。認証拡張領域５１４には、サービス３４０がオーセンティケータ３３０等の動作を制御するために利用する、サービス３４０が指定可能な拡張パラメータが格納される。本実施形態では、拡張パラメータとして表Ｂに示した登録解除ＵＲＬが認証拡張領域５１４に格納される。

図４の説明に戻る。Ｓ４０７で、サービス３４０の通信部３１２は、プレゼンテーション部３４７が作成したオーセンティケータの登録画面を連携アプリケーション３１０に返却する。Ｓ４０７にて返却されるデータには、登録画面を表示するための各種プログラムやデータの他、Ｓ４０５で発行されたトークンおよびＳ４０６で作成された登録パラメータ５１０が含まれる。

Ｓ４０８で、連携アプリケーション３１０のオーセンティケータ登録制御部３１３は、オーセンティケータ３３０に対して、クレデンシャルの作成要求を行う。作成要求は、連携アプリケーション３１０の表示部３１１が、オーセンティケータ３３０の登録画面を読み込んだ際に実行される。例えば、オーセンティケータ３３０の登録画面を読み込んだ時に発生するｏｎｌｏａｄイベントでＳ４０８の処理を実行する。クレデンシャルの作成要求には、登録要求パラメータを含める。以下、登録要求パラメータについて説明する。

図５（Ｂ）は、登録要求パラメータ５２０の一例を示す図である。
登録要求パラメータ５２０は、登録パラメータ５１０、サービスＩＤ５２１、およびアプリＩＤ５２２から構成される。登録パラメータ５１０は、サービス３４０からＳ４０７にて受信した登録パラメータ５１０である。

サービスＩＤ５２１は、表ＡやＢで説明した、オーセンティケータの登録対象のサービス３４０を一意に識別するためのＩＤである。アプリＩＤ５２２は、表Ｂで説明した、オーセンティケータ３３０をサービス３４０に登録する際に使用する連携アプリケーション３１０を一意に特定するためのＩＤである。なお、アプリＩＤは、連携アプリケーション３１０が作成する。

図４の説明に戻る。Ｓ４０９で、オーセンティケータ３３０の生体情報要求部３３４は、ユーザに対して、生体認証に用いる生体情報の入力を求める画面が表示される。以下、Ｓ４０９で表示される画面について説明する。

図６は、オーセンティケータ３３０の登録中に連携アプリケーション３１０の表示部３１１に表示される画面の一例を示す図である。
同意画面６１１では、オーセンティケータ３３０をサービス３４０に登録するために、携帯端末１０７を操作するユーザに生体情報の入力を促す。ボタン６１２は、ユーザが生体情報の入力に同意せず、サービス３４０への登録をキャンセルするためのボタンである。

ボタン６１３は、指紋などの生体情報の読み取りを行うためのボタンであり、生体情報センサ２２７を備える。なお、生体情報として、静脈、虹彩、声紋、顔画像などの情報を利用でき、いずれかに限定するものではない。ここでは、生体情報のいずれか、または任意の複数の生体情報の組み合わせを、生体認証に用いる生体情報として入力するように携帯端末１０７を構成する。

図４の説明に戻る。Ｓ４１０で、オーセンティケータ登録処理部３３１は、読み取った生体情報の特徴量と生体情報を一意に識別するための生体情報ＩＤを作成する。Ｓ４１１で、オーセンティケータ登録処理部３３１は、公開鍵および秘密鍵のペアを作成する。そして、オーセンティケータ登録処理部３３１は、認証情報格納部３３３に対してＴＰＭ２２６に格納されている認証情報管理テーブル（表Ａ）に、以下の情報を格納する。

すなわち、Ｓ４１０で作成した生体情報ＩＤとＳ４１１で作成した鍵ペアのうち秘密鍵とを、クレデンシャルの作成要求に含まれる登録要求パラメータ５２０のサービスＩＤおよびユーザＩＤと紐付けて認証情報として格納する。また、格納された認証情報には、各認証情報を一意に識別するためのＩＤが作成され、認証情報管理テーブル（表Ａ）に格納される。

さらに、オーセンティケータ登録処理部３３１は、ＡＰＩ管理テーブル（表Ｂ）に、認証情報ＩＤ、サービスＩＤ、アプリＩＤ、登録解除ＵＲＬを格納する。アプリＩＤおよび登録解除ＵＲＬについても、サービスＩＤと同様に、登録要求パラメータ５２０に含まれる。Ｓ４１２で、オーセンティケータ登録処理部３３１は、クレデンシャルを作成する。以下、クレデンシャルについて説明する。

図５（Ｃ）は、クレデンシャルの一例を示す図である。
クレデンシャル５３０は、認証情報ＩＤ５３１、アルゴリズム５３２、公開鍵５３３、ａｔｔｅｓｔａｔｉｏｎ５３４、およびオーセンティケータ名５３５から構成される。認証情報ＩＤ５３１は、Ｓ４１１で認証情報管理テーブル（表Ａ）に格納した認証情報ＩＤであり、公開鍵５３３は、Ｓ４１１で作成された鍵ペアの公開鍵である。

アルゴリズム５３２には、Ｓ４１１において鍵ペアを作成する際に利用したアルゴリズムを格納する。また、ａｔｔｅｓｔａｔｉｏｎ５３４は、クレデンシャルの作成要求に含まれる登録要求パラメータのａｔｔｅｓｔａｔｉｏｎチャレンジ５１３をＳ４１１にて作成された秘密鍵を用いて暗号化したデータである。オーセンティケータ名５３５は、オーセンティケータ３３０の名称であり、オーセンティケータ３３０が作成する。

Ｓ４１３で、オーセンティケータ登録処理部３３１は、連携アプリケーション３１０に対して、Ｓ４１２で作成したクレデンシャル５３０を返却する。Ｓ４１４で、連携アプリケーション３１０の通信部３１２は、サービス３４０に対して、Ｓ４１３で受信したクレデンシャル５３０を送信する。

Ｓ４１５で、サービス３４０のオーセンティケータ情報処理部３４２は、受信したクレデンシャル５３０を用いて、オーセンティケータの登録処理を行う。以下、オーセンティケータ情報処理部３４２が実行するクレデンシャルの登録処理について説明する。

オーセンティケータ情報処理部３４２は、クレデンシャル５３０に含まれるａｔｔｅｓｔａｔｉｏｎ５３４を、同じクレデンシャル５３０に含まれる公開鍵５３３で復号し、不正な登録要求でないことを検証する。さらに、オーセンティケータ情報処理部３４２は、ａｔｔｅｓｔａｔｉｏｎチャレンジ管理テーブル（表Ｄ）において、ａｔｔｅｓｔａｔｉｏｎ５３４を公開鍵５３３で復号した値と同一の値をａｔｔｅｓｔａｔｉｏｎチャレンジ列にもつレコードを特定する。

そして、オーセンティケータ情報処理部３４２は、特定したレコードのユーザＩＤをクレデンシャル５３０と紐付けるユーザＩＤとする。そして、オーセンティケータ情報処理部３４２は、クレデンシャル５３０に含まれる認証情報ＩＤ５３１および公開鍵５３３と、クレデンシャル５３０と紐付けるユーザＩＤとをオーセンティケータ情報管理テーブル（表Ｅ）に格納（登録）する。最後に、サービス３４０の通信部３４３は、連携アプリケーション３１０に対して正常にオーセンティケータ３３０の登録処理が完了した旨を通知する。

次に、図７〜図９を用いて、デバイスの初期化が行われた際に、サーバ１０１において該デバイスのオーセンティケータ３３０の登録解除を行う処理について説明する。
以下、デバイスが携帯端末１０７の場合について説明するが、デバイスがＰＣ１０４であっても同様である。なお、サーバ１０１において、オーセンティケータの登録解除を行うと、サービス３４０に登録されたオーセンティケータ３３０の情報が削除される。

図７は、携帯端末１０７の初期化が行われた際に、サービス３４０に登録された携帯端末１０７のオーセンティケータ３３０の登録解除を行う処理のシーケンスを示す図である。
本実施形態では、携帯端末１０７において初期化を行うと、サーバ１０１のサービス３４０に登録されたオーセンティケータ３３０の登録が解除される。

本実施形態では、登録を解除する際には、登録に使用した携帯端末１０７自身の連携アプリケーション３１０を使用して解除処理が実行される。また、サービス３４０において登録を解除するためには、サービス３４０ごとに連携アプリケーション３１０の認証を行う。なお、携帯端末１０７では、全データの初期化が行われるが、図７に示すシーケンスでは、一部分のみを図示し、前後のシーケンスは省略する。

携帯端末１０７で初期化を実行する際に、まず、携帯端末１０７で初期化アプリケーション３２０が実行される。その後、Ｓ７０１で、初期化アプリケーション３２０のオーセンティケータ認証情報取得部３２３は、オーセンティケータ３３０に対して、認証情報の取得要求を行う。Ｓ７０２で、オーセンティケータ３３０の認証情報格納部３３３は、認証情報管理テーブル（表Ａ）とＡＰＩ管理テーブル（表Ｂ）に格納したデータを取得し、初期化アプリケーション３２０に返却する。

図９（Ａ）は、Ｓ７０２で取得したデータを基に、初期化アプリケーション３２０が表示する画面の一例である。
画面９１１は、携帯端末１０７の初期化に伴い、オーセンティケータ３３０の登録解除を行うか確認するための画面である。

画面９１２には、オーセンティケータ３３０が登録されたサービス３４０の一覧が表示される。ボタン９１３を押下すると、オーセンティケータ３３０の登録解除が行われる。ボタン９１４を押下すると、オーセンティケータ３３０の登録解除がキャンセルされる。なお、図９において、ボタン９１３が押下されたものとする。

図７の説明に戻る。以下、Ｓ７０３〜Ｓ７１６に示す登録解除処理が、ＡＰＩ管理テーブル（表Ｂ）において登録解除ＵＲＬが存在するレコード数分、繰り返される。まず、Ｓ７０３で、初期化アプリケーション３２０は、ＡＰＩ管理テーブル（表Ｂ）のアプリＩＤを利用して、登録解除を行わせる連携アプリケーション３１０を起動する。

なお、このとき、初期化アプリケーション３２０は、必要に応じてＳ７０２で受信した認証情報管理テーブル（表Ａ）およびＡＰＩ管理テーブル（表Ｂ）の各データをパラメータとして連携アプリケーション３１０に渡すことも可能である。

Ｓ７０６で、起動された連携アプリケーション３１０は、ＡＰＩ管理テーブル（表Ｂ）の登録解除ＵＲＬに対して登録解除を要求する。サーバ１０１のサービス３４０の拡張リクエスト処理部３４６は、登録解除の要求を受け付け処理する。

なお、連携アプリケーション３１０がＷｅｂブラウザ（Ｗｅｂアプリケーション）である場合、Ｗｅｂブラウザが起動した時点ではＵＩを持たない。このため、Ｓ７０４およびＳ７０５で、登録解除に必要となる画面を携帯端末１０７において表示させるためのＨＴＭＬやＪａｖａＳｃｒｉｐｔなどのプログラムやデータをサービス３４０に要求し、取得する。これら取得されるプログラムやデータを登録解除プログラムと呼ぶ。

また一方、連携アプリケーション３１０がネイティブアプリケーションの場合、既に携帯端末１０７にインストール済みのＵＩおよび登録解除プログラムを使用すればよいが、あらためてサービス３４０から登録解除プログラムを取得しても構わない。

Ｓ７０６で、連携アプリケーション３１０は、サービス３４０の登録解除ＵＲＬ宛に、登録解除を要求する。Ｓ７０７で、サービス３４０のオーセンティケータ情報処理部３４２は、認証パラメータを作成する。認証パラメータは、サービス３４０が連携アプリケーション３１０の認証を行う際に使用するデータである。以下、認証パラメータについて説明する。

図８は、オーセンティケータ３３０の登録解除において、携帯端末１０７とサーバ１０１との通信に含まれるパラメータの一例を示す図である。
ここで、図８（Ａ）を用いて認証パラメータについて説明する。認証パラメータ８１０は、Ａｓｓｅｒｔｉｏｎチャレンジ８１１およびＡｓｓｅｒｔｉｏｎ拡張領域８１２から構成される。

Ａｓｓｅｒｔｉｏｎチャレンジ８１１には、チャレンジレスポンス認証を行うために利用する検証用データが格納される。Ａｓｓｅｒｔｉｏｎ拡張領域８１２には、サービス３４０がオーセンティケータ３３０等の動作を制御するために利用する、サービス３４０が指定可能な拡張パラメータが格納される。

図７の説明に戻る。Ｓ７０８で、サービス３４０の通信部３１２は、オーセンティケータ情報処理部３４２がＳ７０７で作成した認証パラメータ８１０を連携アプリケーション３１０に返却する。Ｓ７０９で、連携アプリケーション３１０のオーセンティケータ認証制御部３１４は、オーセンティケータ３３０の生体認証処理部３３２に対して認証パラメータ８１０を渡し、認証要求を行う。

Ｓ７１０で、オーセンティケータ３３０の生体情報要求部３３４は、ユーザに対して生体認証の要求を行う。生体認証の要求では、ユーザに生体情報の入力を求める画面が表示される。以下、Ｓ７１０で表示される画面について説明する。

図９（Ｂ）は、オーセンティケータ３３０が生体認証を行う際に連携アプリケーション３１０の表示部３１１に表示される画面の一例である。
入力画面９２１は、オーセンティケータ３３０の登録解除の対象となるサービス３４０ごとに表示され、ユーザに対して生体認証に用いる生体情報の入力を要求する。図９（Ｂ）に示す例では、“Ｘ−ｍｏｂｉｌｅ”というサービス３４０に対する認証を要求している。

ボタン９２２を押下すると、入力画面９２１に表示されているサービス３４０に対する認証要求が中止され、該サービス３４０におけるオーセンティケータ３３０の登録解除がスキップされる。ボタン６１３は、図６で説明したように、指紋などの生体情報の読み取りを行うためのボタンであり、生体情報センサ２２７が備える。ユーザが、ボタン６１３を介して生体情報を入力すると、生体認証処理部３３２が該生体情報を取得する。

図７の説明に戻る。Ｓ７１０において、入力画面９２１（図６）を介してオーセンティケータ３３０の生体認証処理部３３２が生体情報を取得する。そして、生体認証処理部３３２は、アサーション情報を作成する。アサーション情報は、サーバ１０１において、登録解除要求を行ったユーザが不正な要求を行っていないことの検証に使われるデータである。以下、アサーション情報について説明する。

図８（Ｃ）は、アサーション情報の一例を示す図である。
アサーション情報８２０は、認証情報ＩＤ８２１および署名８２２から構成される。以下、生体認証処理部３３２が、アサーション情報８２０を構成する認証情報ＩＤ８２１および署名８２２を取得し、アサーション情報８２０を作成する手順を説明する。

Ｓ７１０において、入力画面９２１（図９）を介してオーセンティケータ３３０の生体認証処理部３３２が取得された生体情報を基に、認証情報格納部３３３が管理する認証情報管理テーブル（表Ａ）からレコードが特定される。具体的には、取得された生体情報を示す生体情報ＩＤが特定されることから、認証情報管理テーブル（表Ａ）において、該生体情報に対応する認証情報ＩＤ８２１および秘密鍵が特定される。すなわち、オーセンティケータ３３０が生体認証を実行し、認証成功であれば、秘密鍵が取り出される。

そして、生体認証処理部３３２は、認証パラメータ８１０に含まれるＡｓｓｅｒｔｉｏｎチャレンジ８１１を、特定した秘密鍵を用いて暗号化した署名８２２を作成する。また、生体認証処理部３３２は、特定した認証情報ＩＤ８２１、作成した署名８２２を含むアサーション情報８２０を作成する。

ここで、図９（Ｃ）に示す画面が連携アプリケーション３１０の表示部３１１に表示される。
確認画面９３１は、携帯端末１０７において生体認証が完了した旨を知らせる画面である。ボタン９３２を押下すると、次の処理（Ｓ７１１）に進む。

図７の説明に戻る。Ｓ７１１で、生体認証処理部３３２は、Ｓ７１０で作成したアサーション情報８２０を、連携アプリケーション３１０に返却する。Ｓ７１２で、連携アプリケーション３１０の通信部３１２は、受信したアサーション情報８２０をサービス３４０に送信する。

Ｓ７１３で、サービス３４０のオーセンティケータ情報処理部３４２は、受信したアサーション情報８２０の検証を行う。具体的には、オーセンティケータ情報処理部３４２は、アサーション情報８２０に含まれる署名８２２を、アサーション情報８２０に含まれる認証情報ＩＤ８２１で特定される公開鍵を用いて復号化する。

そして、復号化した値が、Ｓ７０７で作成した認証パラメータ８１０に含まれるＡｓｓｅｒｔｉｏｎチャレンジ８１１と一致するかの検証を行う。なお、公開鍵の特定には、オーセンティケータ情報管理テーブル（表Ｅ）を用いる。

Ｓ７１４で、オーセンティケータ情報処理部３４２は、Ｓ７１３で検証した認証情報ＩＤ８２１を有するオーセンティケータ情報管理テーブル（表Ｅ）のレコードを削除するようにオーセンティケータ情報格納部３４５に対して要求する。オーセンティケータ情報格納部３４５は、削除を要求されたレコードを削除、すなわち登録を解除する。

Ｓ７１５で、オーセンティケータ情報処理部３４２は、連携アプリケーション３１０に対して、登録を解除した旨を返却する。Ｓ７１６では、連携アプリケーション３１０を終了し、オーセンティケータ３３０の登録解除の対象となっている次のサービス３４０に対してＳ７０３〜Ｓ７１５の処理を繰り返すために、初期化アプリケーション３２０に処理を戻す。

以上のように、本実施形態では、オーセンティケータ３３０の登録時に、登録解除ＵＲＬをデバイス側に格納しておくことで、デバイスの初期化をトリガにしてサービス側のオーセンティケータ３３０の登録を解除する仕組みを提供した。これにより、適切なタイミングで、サービス側に格納された自身のアカウントから、不要になったデバイスのオーセンティケータの登録情報を解除できる。

なお、本実施形態では、デバイスが初期化された場合に、連携アプリケーション３１０ごとに登録解除の処理を繰り返し行う例について説明した。しかし、例えば、連携アプリケーション３１０を単体でアンインストールした場合に、Ｓ７０４〜Ｓ７１５に相当する処理が実行されてもよい。また、本実施形態では、携帯端末１０７を例に説明したが、オーセンティケータを有するデバイスであれば、携帯端末１０７のハードウェアおよびソフトウェアと異なった構成であってもよい。

［第２実施形態］
第１実施形態では、デバイスを初期化する際に、該デバイスにおいてオーセンティケータ３３０を登録したサービス３４０ごとに認証を行うことで、オーセンティケータの登録を解除した。

しかし、単一のデバイスを複数のユーザで使用する場合、オーセンティケータを登録した全サービスから該オーセンティケータの登録を解除しようとすると、登録を行った全てのユーザそれぞれに対して生体認証を要求することになる。しかし、これは、デバイスを初期化するタイミングで、その場に全てのユーザが居合わせなくてはならず、現実的ではない。

デバイスの初期化によって、デバイスのＴＰＭに格納された秘密鍵などの情報も削除されるため、サービス側に登録されたオーセンティケータの情報は利用されなくなる。このため、本来ならば、サービスにおいて認証を行わずにオーセンティケータの登録を解除してしまっても構わないが、以下２点の課題がある。

まず、デバイスにおいて成りすましが可能であるため、認証を行わなかった場合、サービスからは成りすましによる登録解除の要求か否かを判断ができない点である。もう一点は、初期化を行ったユーザとは別のユーザにとっては、自身が知らない間に登録が解除されたようにみえる点である。

そこで、本実施形態では、１つのデバイスを複数のユーザで使用する場合に、デバイスの初期化に伴い、サービス３４０において不要となる、または無効となる登録情報の登録が解除されるように促す手段について説明する。なお、第１実施形態と共通の構成には同一の符号を付し、その説明を省略する。また、以下、デバイスが携帯端末１０７の場合について説明するが、デバイスがＰＣ１０４であっても同様である。

＜携帯端末１０７側のテーブルの例＞
以下、表Ｇおよび表Ｂ’を用いて、携帯端末１０７がＴＰＭ２２６に格納する各種データについて説明する。詳細には、表Ｇおよび表Ｂ’が示すテーブルデータは、携帯端末１０７が有するオーセンティケータ３３０の認証情報格納部３３３がＴＰＭ２２６に格納するデータである。

表Ｇのデバイスユーザ認証情報管理テーブルは、表Ａの認証情報管理テーブルを拡張したテーブルであり、オーセンティケータ３３０をサービスに登録する際にレコードが作成され、表Ｇに追加される。認証情報ＩＤ列は、表Ａの認証情報ＩＤと同様である。デバイスユーザＩＤ列には、携帯端末１０７のログインアカウントを一意に識別するためのＩＤを格納する。デバイスユーザＩＤは、サービス３４０にオーセンティケータ３３０を登録する処理のシーケンス（図４）のＳ４１１に相当する処理において、認証情報ＩＤに紐付けて格納される。

表Ｂ’のＡＰＩ管理テーブルは、第１実施形態の表Ｂと類似する。表Ｂと表Ｂ’との違いは、表Ｂの登録解除ＵＲＬ例の代わりに操作ＵＲＬ列を有する点である。操作ＵＲＬ列には、表Ｂ’の各レコードに対して行う操作の操作名と操作を要求するための要求先（ＵＲＬ）のセットであるキー・バリューのデータを格納する。

操作ＵＲＬは、第１実施形態における登録解除ＵＲＬと同様に、オーセンティケータ３３０をサービス３４０に登録する際に、該サービス３４０から連携アプリケーション３１０を介して渡される。詳細には、操作ＵＲＬは、サービス３４０から連携アプリケーション３１０に対してレスポンス（Ｓ４０７）として登録パラメータ５１０（図５）の認証拡張領域５１４に含めて渡される。そして、連携アプリケーション３１０が、オーセンティケータ３３０にクレデンシャルの作成要求（Ｓ４０８）を行う際に、該要求に含まれる登録要求パラメータ５２０としてオーセンティケータ３３０に渡される。

表Ｂ’において、操作ＵＲＬ列には、操作名が“ｄｅｒｅｇｉｓｔｅｒ”（解除）と、“ｎｏｔｉｆｙ”（通知）とがある。操作名が“ｄｅｒｅｇｉｓｔｅｒ”に対応する操作（ＵＲＬ）には、表Ｂの登録解除ＵＲＬと同様に、オーセンティケータ３３０の登録解除を要求するための要求先（ＵＲＬ）を格納する。 操作名が“ｎｏｔｉｆｙ”に対応する操作（ＵＲＬ）には、オーセンティケータの登録解除を促す通知の要求先（ＵＲＬ）を格納する。

例えば、デバイスユーザＩＤが“ｄｅｖｕｓｅｒ００１”のユーザが、携帯端末１０７を初期化する際に、オーセンティケータの登録解除を行う場合を考える。このとき、デバイスユーザ認証情報管理テーブル（表Ｇ）において、デバイスユーザＩＤが“ｄｅｖｕｓｅｒ００１”と紐付く認証情報ＩＤが特定される。そして、ＡＰＩ管理テーブル（表Ｂ’）において、該認証情報ＩＤを有するレコードに関しては、第１実施形態と同様に、登録解除の処理（図７）を行う。

具体的には、“ｄｅｖｕｓｅｒ００１”と紐付く認証情報ＩＤが示すＡＰＩ管理テーブル（表Ｂ’）のレコードに関しては、操作名が“ｄｅｒｅｇｉｓｔｅｒ”のＵＲＬに対して要求を送信することで、サービス３４０に登録解除の要求を送信できる。

しかし、携帯端末１０７を使用する“ｄｅｖｕｓｅｒ００１”以外のデバイスユーザＩＤを有するユーザのレコードに関しては、上述した理由によりＳ７１０を実行できない場合がある。そこで、デバイスユーザ認証情報管理テーブルにおいて、“ｄｅｖｕｓｅｒ００１”以外のデバイスユーザＩＤと紐付く認証情報ＩＤが示すＡＰＩ管理テーブル（表Ｂ’）のレコードに関しては、操作名が“ｎｏｔｉｆｙ”のＵＲＬに対して要求を送信する。

これにより、サービス３４０に対して、“ｄｅｖｕｓｅｒ００１”以外のデバイスユーザＩＤを有するユーザに対して、自身が登録した登録情報の解除を促す通知を行うようにサービス３４０に要求を送信できる。なお、上述した、“ｎｏｔｉｆｙ”のＵＲＬに対して要求を送信する処理は、Ｓ７０３〜Ｓ７１６の繰り返し処理が終わった後に、初期化アプリケーション３２０が、サービス３４０に対して行う。

すなわち、初期化アプリケーション３２０が、“ｎｏｔｉｆｙ”のＵＲＬに対して要求を送信する。送信された要求は、登録解除ＵＲＬに対する要求と同様に、サービス３４０の拡張リクエスト処理部３４６によって処理されるが、そこでの認証処理（Ｓ７１３）は行われない。

図１０は、“ｄｅｖｕｓｅｒ００１”以外のユーザへの通知の一例である。
詳細には、図１０は、携帯端末１０７の初期化後に、“ｄｅｖｕｓｅｒ００１”以外のユーザが、初期化された携帯端末１０７とは別のデバイスからサービス３４０にログインした際に表示される。

図１０（Ａ）は、サービス３４０が提供するＷｅｂサイトを表示した画面の一例である。アイコン１０１１は、ログインしたユーザに対するメールやメッセージなどの通知を表示するアイコンである。アイコン１０１１を押下すると、通知の詳細が表示される。

図１０（Ｂ）は、通知の詳細を表示する画面の一例である。通知画面１０２１に、サービス３４０が提供するＷｅｂサイトの通知内容を示す画面である。領域１０２２には、上述した通知の要求先（ＵＲＬ）に対して要求を送信した携帯端末１０７の情報が表示される。ボタン１０２３を押下すると、オーセンティケータ情報管理テーブル（表Ｅ）において、該当するオーセンティケータ３３０のレコードが削除され、サービス３４０に登録されたオーセンティケータ３３０の登録が解除される。ボタン１０２４を押下すると、何もせずに通知画面１０２１が閉じられる。

このように、本実施形態では、複数のユーザで共用しているデバイスを、あるユーザが初期化した際に、別のユーザがオーセンティケータを登録していたサービス３４０がある場合、該別のユーザに対して通知が行われる。これにより、不正に登録が解除されることを抑制しつつ、初期化に伴い登録していたオーセンティケータが不要になったことを通知することができる。

なお、本実施形態では、操作ＵＲＬとして、“ｄｅｒｅｇｉｓｔｅｒ”および“ｎｏｔｉｆｙ”を用いたが、これに限られるものではない。サービス３４０の登録情報などを操作するための要求先として“ｄｅｒｅｇｉｓｔｅｒ”および“ｎｏｔｉｆｙ”以外の操作にも用いることができる。また、要求を行う際の通信プロトコルとして、ｈｔｔｐやｈｔｔｐｓに限らず、連携アプリケーション３１０とサービス３４０とが対応していれば、別のプロトコルを使用することも可能である。

［第３実施形態］
第１実施形態では、デバイスを初期化する際に、オーセンティケータの登録を解除する処理（図７）について説明したが、登録されているサービス３４０が多い場合、初期化作業に時間がかかってしまい、ユーザの負担になる。

また、第１実施形態および第２実施形態で説明したような、登録解除ＵＲＬ等の操作ＵＲＬに、サービス３４０側が対応していない場合、デバイスを初期化するタイミングでオーセンティケータ３３０の登録を解除できない。また、登録解除ＵＲＬ等の操作ＵＲＬに、サービス３４０側が対応していない場合、デバイスの初期化に伴い不要になった登録情報があることを通知できない。このため、デバイスのユーザが自身で気付かない限り不要な登録情報がサービス３４０側に残り続ける可能性がある。

そこで、本実施形態では、デバイスに紐付いたサービス３４０とは異なる他のサービスのアカウントを使用して、登録解除ＵＲＬや操作ＵＲＬを使用せずに、ユーザにオーセンティケータの登録解除を促す手段について説明する。なお、第１実施形態と共通の構成には同一の符号を付し、その説明を省略する。また、以下、デバイスが携帯端末１０７の場合について説明するが、デバイスがＰＣ１０４であっても同様である。

図１１は、本実施形態におけるネットワーク構成と、サーバ１１０１および携帯端末１０７のソフトウェア構成例を示す図である。なお、サーバ１１０１のハードウェア構成は、サーバ１０１と同様であり、同一の構成には同一の符号を付す。

図１１に示すネットワーク構成は、図１の拡張であり、サーバ１１０１が追加されている。まず、サーバ１１０１について説明する。
サーバ１１０１は、サービス３４０を提供するサーバ１０１とは異なるサーバであり、ＰＣ１０４および携帯端末１０７を同一のアカウントで紐付け、様々なサービスを提供する。

サーバ１１０１は、提供するサービスの一例として、アカウントサービス１１１０を有する。アカウントサービス１１１０は、同期部１１１１、認証部１１１２、通信部１１１３、およびユーザ情報格納部１１１４から構成される。同期部１１１１は、通信部１１１３を介してＰＣ１０４や携帯端末１０７などの外部の機器と通信し、該機器とデータを共有するための同期機能を提供するソフトウェアモジュールである。

認証部１１１２は、ＰＣ１０４や携帯端末１０７と同期を行うために必要な認証機能を提供するソフトウェアモジュールである。認証部１１１２が提供する認証機能は、第１実施形態および第２実施形態で説明したサービス３４０が提供する認証機能とは異なり、認証機能が実現できればどのような手段を用いてもよい。通信部１１１３は、ＰＣ１０４や携帯端末１０７などの外部機器と通信するためのソフトウェアモジュールである。

ユーザ情報格納部１１１４は、ユーザのアカウントに紐付く様々な属性（データ）を格納するためのソフトウェアモジュールである。本実施形態において必要となるデータは、ユーザ情報格納部１１１４に格納されたり取得されたりする。ユーザ情報格納部１１１４が格納するデータの具体的な内容については、後述する。

ストレージサービス１１２０およびメールサービス１１３０は、サーバ１１０１が提供するその他のサービスの一例であり、これに限定されるものではない。サーバ１１０１は、この他にも様々なサービスを提供してもよい。

次に、携帯端末１０７のソフトウェア構成例について、図３と異なる点について説明する。携帯端末１０７は、連携アプリケーション３１０、初期化アプリケーション３２０、オーセンティケータ３３０に加えて、サービス管理部１１４０を備える。初期化アプリケーション３２０は、オーセンティケータ認証情報取得部３２３に加えて、同期部３２４を備える。

同期部３２４は、携帯端末１０７において初期化を行う際に、サーバ１１０１のアカウントサービス１１１０と同期処理を行うソフトウェアモジュールである。同期処理についての詳細は、後述する。

サービス管理部１１４０は、同期部１１４１、登録管理部１１４２、および監視部１１４３から構成される。同期部１１４１は、サーバ１１０１のアカウントサービス１１１０と通信し、データを共有するためのソフトウェアモジュールである。登録管理部１１４２は、サービス３４０に登録されたオーセンティケータ３３０であって、アカウントサービス１１１０が同一のアカウントで紐付ける他のデバイスのオーセンティケータ３３０の登録状態を管理するソフトウェアモジュールである。

サービス管理部１１４０の同期部１１４１とアカウントサービス１１１０の同期部１１１１とが同期することで、同一のアカウントで紐づけられたＰＣ１０４や携帯端末１０７などのデバイス間でオーセンティケータ３３０の登録状態を共有する。そして、共有したデータが、登録管理部１１４２で管理される。監視部１１４３は、オーセンティケータ３３０の登録情報が不要となったか監視し、不要となった場合に通知する機能を有するソフトウェアモジュールである。監視部１１４３の動作の詳細については、後述する。

＜サーバ１１０１およびデバイスで共有されるテーブルの例＞
以下、表Ｈを用いて、サーバ１１０１およびデバイスが共有する各種データについて説明する。詳細には、表Ｈが示すテーブルデータは、サーバ１１０１が有するアカウントサービス１１１０の各ソフトウェアモジュールが、記憶装置２１０や外部ストレージシステム（不図示）に格納するデータである。

また、表Ｈが示すテーブルデータは、携帯端末１０７やＰＣ１０４が有するサービス管理部１１４０の同期部１１４１により、サーバ１１０１と共有されるデータであり、携帯端末１０７やＰＣ１０４の記憶装置２２４または２１０に格納される。

表Ｈのオーセンティケータ初期化管理テーブルは、アカウントサービス１１１０のユーザのアカウントごとに作成され、アカウントサービス１１１０のユーザ情報格納部１１１４が管理するデータである。１つのレコードが１つのデバイスにおける初期化に関する情報のエントリを示す。初期化ＩＤ列には、デバイスを初期化した際に発行され、各初期化を一意に識別するためのＩＤを格納する。

デバイス名列には、初期化を行ったデバイスの名前が格納される。サービスＩＤ列には、初期化を行う際にオーセンティケータ３３０が登録されていたサービス３４０を一意に識別するためのＩＤであり、表Ａに格納されるサービスＩＤと同様のＩＤである。通知フラグ列には、携帯端末１０７、ＰＣ１０４等のデバイスの監視部１１４３がオーセンティケータ３３０の登録情報が不要か判断するために使用するフラグを格納する。

図１２（Ａ）は、携帯端末１０７で初期化を実行する際の初期化アプリケーション３２０の動作の一部を示すフローチャートである。
なお、本実施形態では、携帯端末１０７にて初期化を実行する場合について説明するが、ＰＣ１０４にて初期化を実行する場合についても同様である。

ユーザが、携帯端末１０７の初期化アプリケーション３２０の機能である初期化処理を実行するとＳ１２１１が実行される。Ｓ１２１１で、初期化アプリケーション３２０のオーセンティケータ認証情報取得部３２３は、初期化の対象となっているデバイス、すなわち携帯端末１０７からデバイス名を取得する。

Ｓ１２１２で、オーセンティケータ認証情報取得部３２３は、認証情報格納部３３３を介して認証情報管理テーブル（表Ａ）に格納した全てのレコードのサービスＩＤ列の値を取得する。Ｓ１２１３で、オーセンティケータ認証情報取得部３２３は、初期化ＩＤを発行し、Ｓ１２１１で取得したデバイス名と、Ｓ１２１２で取得したサービスＩＤの一覧とを初期化ＩＤに紐付けた情報をアカウントサービス１１１０と同期する。すなわち、初期化ＩＤとデバイス名とサービスＩＤサービスＩＤの一覧とを初期化ＩＤと紐付けた情報がアカウントサービス１１１０に送信される。

アカウントサービス１１１０と同期すると、アカウントサービス１１１０のユーザ情報格納部１１１４では、同期された初期化ＩＤとデバイス名とサービスＩＤとに加え、通知フラグが付与されたオーセンティケータ初期化管理テーブル（表Ｈ）が作成される。なお、通知フラグのデフォルト値は、“ｔｒｕｅ”とする。

図１２（Ｂ）は、初期化を実行された携帯端末１０７とは異なるデバイスの連携アプリケーション３１０がサービス３４０にアクセスした際の、監視部１１４３の動作を示すフローチャートである。
なお、ここでサービス３４０にアクセスしたデバイスは、初期化処理を実行した携帯端末１０７と同一のアカウトに紐付けられたデバイスである。

そして、該デバイスの同期部１１４１が、アカウントサービス１１１０の同期部１１１１と同期することにより、オーセンティケータ初期化管理テーブル（表Ｈ）のデータがデバイスに同期される、すなわち取得されているものとする。デバイスの同期部１１４１が同期により取得したデータは、登録管理部１１４２が管理する。以下、この同期済みのデバイスを用いて、サービス３４０にアクセスした場合の処理のフローチャートを示す。

Ｓ１２２１で、デバイスの監視部１１４３は、連携アプリケーション３１０がアクセスしたサービスのドメイン名と、登録管理部１１４２で管理されているオーセンティケータ初期化管理テーブル（表Ｈ）に存在するサービスＩＤとが一致するか判断する。なお、上述したように、サービスＩＤは、サービス３４０のドメイン名に相当する。

アクセスしたサービスのドメイン名とオーセンティケータ初期化管理テーブルに存在するサービスＩＤとが一致する場合、処理はＳ１２２２に進み、一致しない場合、処理は終了する。Ｓ１２２２で、監視部１１４３は、オーセンティケータ初期化管理テーブルにおいて、Ｓ１２２１で一致したサービスＩＤを有するレコードの通知フラグ列の値が“ｔｒｕｅ”か判定する。

通知フラグ列の値が“ｔｒｕｅ”の場合、処理はＳ１２２３に進み、“ｔｒｕｅ”でない場合、処理は終了する。Ｓ１２２３で、監視部１１４３は、 連携アプリケーション３１０の表示部３１１にオーセンティケータ３３０の登録解除を促す表示を行うとともに、オーセンティケータ初期化管理テーブルの対象レコードの通知フラグを“ｆａｌｓｅ”に変更する。

図１３は、Ｓ１２２３にて連携アプリケーション３１０の表示部３１１に表示される、オーセンティケータ３３０の登録解除を促す表示の一例である。
本実施形態では、連携アプリケーション３１０にバナー１３１１を表示し、どのデバイスが初期化されたかや、それに伴い不要になったオーセンティケータの登録解除を促す表示を行う。

このように、あるアカウントを使用するデバイスのオーセンティケータ３３０の登録を行ったサービス３４０（Ｗｅｂサイト）に、該デバイスを初期化した後、同一のアカウントを用いる別のデバイスから初めてアクセスした際に、バナー１３１１が表示される。これにより、サービス３４０が登録解除ＵＬＲ等の操作ＵＲＬに対応していない場合であっても、ユーザに不要なオーセンティケータ３３０の登録解除を促すことができる。

このように、本実施形態によれば、アカウントサービス１１１０を利用して、同一のアカウントを使用するデバイス間でデバイスの初期化を監視し、初期化に伴い不要となる登録情報が存在するか判断する。これにより、オーセンティケータ３３０を登録しているサービス３４０が多数ある場合や、サービス３４０が登録解除ＵＲＬ等の操作ＵＲＬに対応していない場合であっても、ユーザに不要な登録情報の存在を知らせることができる。

［その他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

Claims (10)

1. 生体情報センサにより読み取った生体情報を用いた生体認証のための認証モジュールと、前記認証モジュールにより認証処理を行う際に必要なユーザの生体情報と該生体情報について生成された秘密鍵とを記憶する耐タンパー性を備える記憶手段と、を有する情報処理装置であって、
   前記情報処理装置のＯＳの初期化に際して、前記秘密鍵のペアとなる公開鍵を含む登録情報が登録される外部のサーバに対して、該登録情報の登録解除のための要求先の情報を用いて、前記登録解除の要求を送信する要求手段を有し、
   前記サーバから、登録解除のための認証要求を受信した際に、前記生体情報センサにより読み取られた生体情報を用いた前記認証モジュールによる生体認証での認証成功に応じて取り出された秘密鍵により、署名が生成され、
   該署名が前記サーバに送信されることで検証に成功した場合に、前記サーバで、前記登録情報についての登録解除が行われる、ことを特徴とする情報処理装置。
2. 前記登録解除のための要求先の情報は、前記登録情報がサーバに登録される際に該サーバから取得する、ことを特徴とする請求項１に記載の情報処理装置。
3. 前記登録解除のための要求先の情報は、前記認証モジュールが管理する、ことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記登録情報には、認証モジュールの識別情報がさらに含まれる、ことを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
5. 前記認証モジュールの識別情報は、前記情報処理装置のログインアカウントと紐付けて管理される、ことを特徴とする請求項４に記載の情報処理装置。
6. 前記要求手段は、前記情報処理装置のユーザであって、該情報処理装置のＯＳの初期化に際して該情報処理装置にログインしたユーザとは異なる他のユーザに対して、該他のユーザが外部のサーバに登録した登録情報の登録解除を行うように通知するための要求先の情報を用いて、前記通知の要求を送信する、ことを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
7. 前記登録解除を行うように通知するための要求先の情報は、前記登録情報がサーバに登録される際に該サーバから取得する、ことを特徴とする請求項６に記載の情報処理装置。
8. 前記情報処理装置のＯＳの初期化に際して、該情報処理装置が前記登録情報を登録した前記外部のサーバの一覧を含む情報を、アカウントを管理するサーバに送信する送信手段と、
   前記アカウントを管理する外部のサーバから、前記情報処理装置のアカウントと同一のアカウントにより紐付く他の情報処理装置の送信した前記外部のサーバの一覧を含む情報を取得する取得手段と、
   前記取得した情報に含まれるサーバの一覧にアクセスする際に、前記他の情報処理装置の登録情報の登録解除が必要であることを示す表示を行う表示手段と、をさらに備える、ことを特徴とする請求項１乃至７のいずれか一項に記載の情報処理装置。
9. 生体情報センサにより読み取った生体情報を用いた生体認証のための認証モジュールと、前記認証モジュールにより認証処理を行う際に必要なユーザの生体情報と該生体情報について生成された秘密鍵とを記憶する耐タンパー性を備える記憶手段と、を有する情報処理装置の制御方法であって、
   前記情報処理装置のＯＳの初期化に際して、前記秘密鍵のペアとなる公開鍵を含む登録情報が登録される外部のサーバに対して、該登録情報の登録解除のための要求先の情報を用いて、前記登録解除の要求を送信する要求工程を有し、
   前記サーバから、登録解除のための認証要求を受信した際に、前記生体情報センサにより読み取られた生体情報を用いた前記認証モジュールによる生体認証での認証成功に応じて取り出された秘密鍵により、署名が生成され、
   該署名が前記サーバに送信されることで検証に成功した場合に、前記サーバで、前記登録情報についての登録解除が行われる、ことを特徴とする制御方法。
10. 請求項１乃至８に記載の各手段としてコンピュータを機能させるためのプログラム。

Images