JP7269486B2 - 情報処理装置、情報処理方法及び情報処理プログラム - Google Patents

Description

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

従来、オンラインバンキングやネットショッピングなどインターネットを経由してサービスにログインするために本人確認が行われるケースがある。近年、FIDO Alliance（Fast IDentity Online Alliance）により、生体認証などを利用した新しいオンライン認証技術の標準化が進められており、オンラインバンキングサービスなどにおいて採用されている。FIDO Allianceにより標準化が進められている認証方式では、生体情報などを用いたローカル認証とネットワークを経由した公開鍵暗号による署名検証の組み合わせにより、インターネットに生体情報などの機密情報を流さずにセキュアな認証を実現している。なお、ローカル認証は、ユーザが利用している端末やスマートフォンなどの外部認証器（ローカル）に登録データを保持し、端末や外部認証器内で行う認証を意味する。

ＦＩＤＯ２．０に準拠した認証（非特許文献２）において生体認証を行うためにブラウザのJavaScript（登録商標）から認証器にアクセスする場合、ＣＴＡＰ（Client-to-Authenticator Protocol）プロトコルを用い、認証器に対してＵＳＢ（Universal Serial Bus）／ＢＬＥ（Bluetooth（登録商標） Low Energy）／ＮＦＣ（Near Field Communication）のようなブリッジインタフェースを経由して接続できる。

特開２００９－１１８１１０号公報

"FIDO Alliance"、［Online］、［平成３０年１１月２２日検索］、インターネット＜https://fidoalliance.org/specifications/overview/＞ "FIDO Alliance"、［Online］、［平成３０年１１月２２日検索］、インターネット＜https://fidoalliance.org/fido2/＞

しかしながら、上記のようにブラウザがブリッジインタフェースを経由して認証器に接続する場合、悪意のあるアプリが、ＣＴＡＰプロトコルにより認証器にアクセスして攻撃するおそれがある。これを防止するために、ＣＴＡＰ接続する際にユーザにＰＩＮ入力を要求して接続元を認証することもできるが、手間が増えることでユーザの利便性が低下するおそれがある。

１つの側面では、本発明は、不正なプログラムからの認証器への接続を防止することが可能な情報処理装置、情報処理方法及び情報処理プログラムを提供することを目的とする。

一つの態様では、情報処理装置は、ブラウザがブリッジインタフェースを経由して認証器に接続するときに、前記ブラウザの情報を取得して、取得した前記ブラウザの情報から一意の識別情報を生成して前記ブラウザに送信し、生成した前記一意の識別情報と前記ブラウザの情報とを関連付けて記憶部において管理する管理部と、前記ブラウザから前記一意の識別情報を取得し、前記記憶部を参照して、取得した前記一意の識別情報に対応する前記ブラウザの情報を取得する取得部と、前記取得部が取得した前記ブラウザの情報を前記認証器に送信して、前記ブラウザの情報に署名を付すように依頼する依頼部と、前記認証器から署名付きのブラウザの情報を取得し、取得した前記署名付きのブラウザの情報を認証サーバに送信する送信部と、前記認証サーバによる前記署名付きのブラウザの情報を用いた認証結果に基づいて、前記ブラウザと前記認証器の接続可否を制御する制御部と、を備えている。

不正なプログラムからの認証器への接続を防止することができる。

一実施形態に係る認証システムの構成を概略的に示す図である。 一実施形態に係る認証システムによるユーザ認証処理を示す図である。 認証システムが有する各装置の構成を示す図である。 端末装置の機能ブロック図である。 アクセス制御処理の手順（その１）を示す図である。 アクセス制御処理の手順（その２）を示す図である。 アクセス制御処理の手順（その３）を示す図である。 検証部により実行される検証処理（Ｓ５２）を示すフローチャートである。 図９（ａ）は、Platformアプリ側（プロセス間通信のサーバ側）のポート番号とアドレス情報を示す図であり、図９（ｂ）は、Polyfill側（プロセス間通信のクライアント側）のポート番号とアドレス情報を示す図であり、図９（ｃ）はＴＣＰ接続一覧情報を示す図である。 図１０（ａ）は、管理情報テーブルを示す図であり、図１０（ｂ）は、ホワイトリストを示す図である。 情報処理プログラムを実行するコンピュータの一例を示す図である。 図１２（ａ）は、一実施形態の作用効果を説明するための図であり、図１２（ｂ）は、比較例を説明するための図である。 変形例１を示す図である。 変形例２に係る認証システムを示す図である。 変形例２に係るブラウザ及び測定アプリの機能ブロック図である。 図１６（ａ）、図１６（ｂ）は、変形例２に係るホワイトリストの一例を示す図である。 変形例２に係る管理情報テーブルの一例を示す図である。 変形例２に係るアクセス制御処理の手順（その１）を示す図である。 変形例２に係るアクセス制御処理の手順（その２）を示す図である。 変形例２に係るログの一例を示す図である。

以下、一実施形態に係る認証システムついて、図１～図１２（ｂ）に基づいて詳細に説明する。図１は、一実施形態に係る認証システム１０の構成の一例を示す図である。

図１に示すように、本実施形態の認証システム１０は、情報処理装置としての端末装置１００と、外部認証器４００と、提供サーバ２００と、認証サーバ３００とを有する。なお、認証システム１０では、端末装置１００、外部認証器４００、提供サーバ２００および認証サーバ３００の数は限定されず、任意の数の端末装置１００、外部認証器４００、提供サーバ２００および認証サーバ３００を有することとしてもよい。端末装置１００と提供サーバ２００との間、端末装置１００と認証サーバ３００との間、および、提供サーバ２００と認証サーバ３００との間は、ネットワークＮを介して、相互に通信可能に接続される。かかるネットワークＮには、有線または無線を問わず、インターネットを始め、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。また、ネットワークＮを介する通信は、例えば、ＴＬＳ（Transport Layer Security）／ＳＳＬ（Secure Sockets Layer）等によって暗号化されるようにしてもよい。また、端末装置１００と外部認証器４００は、ＮＦＣ（Near Field Communication）、ＢＬＥ（Bluetooth（登録商標） Low Energy）、ＵＳＢ（Universal Serial Bus）などにより接続される。

認証システム１０は、端末装置１００において提供サーバ２００が提供するサービスを利用するに、外部認証器４００で生体情報を照合し、ユーザ認証処理を行い、その認証結果を端末装置１００を介して認証サーバ３００に送信することで端末装置１００のユーザ認証を行うシステムの一例である。端末装置１００は、提供サーバ２００が提供するサービスをユーザが利用するための情報処理装置である。端末装置１００は、例えば、生体センサ等が内蔵されていない据え置き型のパーソナルコンピュータなどであるものとし、外部認証器４００は、例えば指紋センサなどを有するスマートフォンであるものとする。

図２は、認証システム１０によるユーザ認証処理を示す図である。図２に示すように、認証システム１０では、（１）オンラインサービスへの登録時に、外部認証器４００が新しい鍵のペア（公開鍵、秘密鍵）を生成し、秘密鍵は外部認証器４００が保持し、公開鍵は認証サーバ３００に事前登録する。次いで、（２）端末装置１００からログイン要求をすると、（３）認証サーバ３００が端末装置１００を介して外部認証器４００にチャレンジコードを送信する。次いで、（４）端末装置１００がユーザに対してログイン要求を行うと、（５）ユーザは、外部認証器４００の指紋センサ等を用いて生体認証を行う。このとき、外部認証器４００は、外部認証器４００で保持する生体データを用いて認証（ローカル認証）を行い、認証に成功した場合には、（６）秘密鍵によりチャレンジコードに署名を行い、端末装置１００経由で署名付きのチャレンジコードを認証サーバ３００に送信する。そして、（７）認証サーバ３００は、署名付きのチャレンジコードを公開鍵で検証することで認証を行い、認証に成功した場合に、ユーザのログインを許可する。本実施形態では、上記のようなユーザ認証処理を行っていることから、ネットワークＮに生体情報などの機密情報を流さなくてもよく、セキュアな認証が可能となっている。

ここで、本実施形態の認証システム１０では、上述したユーザ認証処理を行う機能とは別に、端末装置１００にインストールされた不正なプログラム（アプリ）からの外部認証器４００へのアクセスを防止する機能を備えている。以下においては、不正なプログラムからの外部認証器４００へのアクセスを防止する機能を中心に説明する。

図３には、認証システム１０が有する各装置の構成が示されている。図３に示すように、端末装置１００では、例えばブラウザ２０が提供サーバ２００から取得したJavaScriptなどのクライアントアプリ（Relying Partyアプリ）２２がブラウザ２０上で実行される。Relying Partyアプリ２２はJavaScriptなどによる認証ライブラリ（Polyfill）２４を含み、Polyfill２４はＯＳ（Operating System）上で動作する測定アプリ（Platformアプリ）２６との間でプロセス間通信を行う。また、Platformアプリ２６はＯＳのAPI(Platform API)から取得した情報を用い、ブリッジインタフェース２８を経由して外部認証器４００への接続を制御する。

外部認証器４００は、ＣＴＡＰ接続インタフェース４０、鍵管理部４２、署名部４４、ＧＵＩ（Graphical User Interface）制御部４６、データ生成部４８、生体認証ライブラリ５０を有する。

ＣＴＡＰ接続インタフェース４０は、ブリッジインタフェース２８を介して、ＣＴＡＰプロトコルを用いて端末装置１００と接続する。なお、ＣＴＡＰプロトコルは、ＦＩＤＯ２．０から採用される認証器にアクセスするためのプロトコルである。

鍵管理部４２は、秘密鍵を管理する。なお、鍵管理部４２は、秘密鍵として、前述した認証処理（図２）に用いる秘密鍵と、外部認証器４００へのアクセスを防止するために用いる秘密鍵とを別々に管理していてもよいし、各処理に用いることが可能な共通の秘密鍵を管理してもよい。

署名部４４は、ブリッジインタフェース２８から署名要求とともに呼出元アプリ情報が送信されてきたときに、署名処理を実行する。署名部４４は、この署名処理において、鍵管理部４２が管理する秘密鍵を利用する。また、署名部４４は、ユーザ認証処理（図２）において、後述するデータ生成部４８が認証ＯＫと判定した場合に、鍵管理部４２で管理されている認証用の秘密鍵を用いてチャレンジコードに署名を付す。そして、署名部４４は、署名付きのチャレンジコードを端末装置１００を介して認証サーバ３００に送信する。

ＧＵＩ制御部４６は、生体認証の入力用ダイアログを表示する。データ生成部４８は、生体センサから取得した画像から照合用データを生成する。また、データ生成部４８は、ユーザ認証処理（図２）において、生体認証ライブラリ５０に格納されている生体データと、生成した照合用データとを比較して、認証ＯＫ／ＮＧを判定する。

提供サーバ２００は、各種サービスを提供するサーバである。提供サーバ２００は、端末装置１００からサービス要求を受信すると、Ｗｅｂアプリを端末装置１００に送信し、認証サーバ３００によるユーザ認証の後に各種サービスをユーザに提供する。

認証サーバ３００は、端末装置１００から受信する認証要求を処理するサーバである。また、認証サーバ３００は、図３に示す検証部６０を有している。検証部６０は、外部認証器４００から端末装置１００を経由して署名付きの情報を取得すると、公開鍵を用いて検証を実行し、検証結果を端末装置１００に送信する。端末装置１００では、外部認証器４００に接続しようとしているブラウザが適切であるという検証結果を得た場合に、ブラウザ２０からの外部認証器４００へのアクセスを許可する旨を端末装置１００に通知する。これにより、不正なプログラムからの外部認証器４００へのアクセスを制御している。なお、認証サーバ３００では、公開鍵として、前述した認証処理（図２）に用いる公開鍵と、外部認証器４００への不正なアクセスを防止するために用いる公開鍵とを別々に管理していてもよいし、各処理に用いることが可能な共通の公開鍵を管理してもよい。

図４には、端末装置１００の機能ブロック図が示されている。図４に示すように、Polyfill２４は、送信部としてのサーバ検証連携部２４２と、ＩＤ取得部２４４と、を有する。また、Platformアプリ２６は、管理部としてのＩＤ発行部２６２と、アプリ情報取得部２６４と、取得部としてのＩＤ検証部２６６と、を有する。また、ブリッジインタフェース２８は、依頼部としての署名依頼部２８２と、アプリ情報取得依頼部２８４と、を有する。

サーバ検証連携部２４２は、認証サーバ３００の検証部６０と連携して、情報のやり取りを行う。

ＩＤ取得部２４４は、ブラウザ２０が外部認証器４００に接続するときに、Platformアプリ２６と情報のやり取りを行い、Platformアプリ２６のＩＤ発行部２６２において発行された身元証明ＩＤを取得する。また、ＩＤ取得部２４４は、取得した身元証明ＩＤを用いて、ブリッジインタフェース２８の署名依頼部２８２に対して署名依頼を送信する。

ＩＤ発行部２６２は、ブラウザ２０のプロセスＩＤを取得し、プロセスＩＤをアプリ情報取得部２６４に送信する。また、ＩＤ発行部２６２は、アプリ情報取得部２６４から送信されてくる呼出元アプリの情報（プロセス名）に基づいて、身元証明ＩＤを発行し、ＩＤ取得部２４４に通知する。ＩＤ発行部２６２では、身元証明ＩＤと、プロセス名と、プロセスＩＤとを図１０（ａ）に示す記憶部としての管理情報テーブル８０にて管理する。

アプリ情報取得部２６４は、ＩＤ発行部２６２から受信したプロセスＩＤに基づいて、呼出元アプリ情報（プロセス名）を取得し、ＩＤ発行部２６２に通知する。

ＩＤ検証部２６６は、ブリッジインタフェース２８のアプリ情報取得依頼部２８４から呼出元アプリ情報（プロセス名）の取得要求を受信すると、管理情報テーブル８０を参照して、取得要求に含まれる身元証明ＩＤを検証する。そして、ＩＤ検証部２６６は、管理情報テーブル８０から身元証明ＩＤに対応するプロセス名を取得するとともに、端末装置１００の最前面で実行されているアプリ情報（前面表示アプリ情報）を取得し、アプリ情報取得依頼部２８４に通知する。

署名依頼部２８２は、ＩＤ取得部２４４から身元証明ＩＤを用いた署名依頼を受信すると、アプリ情報取得依頼部２８４に対して、身元証明ＩＤを送信し、呼出元アプリ情報（プロセス名）の取得要求を行う。また、署名依頼部２８２は、アプリ情報取得依頼部２８４から身元証明ＩＤに対応するプロセス名と前面表示アプリ情報を取得した場合に、外部認証器４００の署名部４４に対して、プロセス名と前面表示アプリ情報を通知する。更に、署名依頼部２８２は、署名部４４において署名された署名付きのプロセス名と署名付きの前面表示アプリ情報を受信すると、受信した情報をサーバ検証連携部２４２に対して送信する。

アプリ情報取得依頼部２８４は、署名依頼部２８２から、身元証明ＩＤを伴う呼出元アプリ情報（プロセス名）の取得要求を受信した場合に、ＩＤ検証部２６６に対して身元証明ＩＤを通知する。また、アプリ情報取得依頼部２８４は、通知した身元証明ＩＤに対応するプロセス名と前面表示アプリ情報をＩＤ検証部２６６から取得すると、署名依頼部２８２に送信する。

（認証システム１０における外部認証器４００へのアクセス制御について）
以下、認証システム１０における外部認証器４００へのアクセス制御について、図５～図８に基づいて詳細に説明する。なお、図５～図８の処理は、端末装置１００と外部認証器４００が接続する前のタイミング（図２の（３）の前）において、実行される処理である。

図５には、アクセス制御処理の手順（その１）が示されている。

図５の処理では、まず、Polyfill２４のＩＤ取得部２４４が、Platformアプリ２６のＩＤ発行部２６２に対して、身元証明ＩＤの発行要求を実行する（Ｓ１０）。このとき、ＩＤ発行部２６２は、呼出元アプリ（ブラウザ２０）のプロセスＩＤを取得する。ＩＤ発行部２６２は、プロセスＩＤを取得する場合、Platformアプリ２６がWinSockを使ったソケット通信によりPolyfill２４とプロセス間通信を確立したときに、図９（ａ）に示すPlatformアプリ２６側（プロセス間通信のサーバ側）のポート番号とアドレス情報を取得する。また、ＩＤ発行部２６２は、図９（ｂ）に示すPolyfill２４側（プロセス間通信のクライアント側）のポート番号とアドレス情報を取得する。そして、図９（ｃ）に示すＴＣＰ接続一覧情報を参照して、プロセスＩＤを取得する。

ここで、図９（ｃ）のＴＣＰ接続一覧情報にはPlatformアプリ２６のＴＣＰ接続数とプロセス間通信のサーバのポート番号及びアドレス情報、クライアントのポート番号及びアドレス情報、接続元アプリのプロセスＩＤが含まれる。なお、図９（ｃ）の例では、図示が省略されているが、プロセス間通信のサーバのポート番号及びアドレス情報、クライアントのポート番号及びアドレス情報、接続元アプリのプロセスＩＤの組み合わせが６９個格納されているものとする。

ＩＤ発行部２６２は、図９（ａ）、図９（ｂ）で取得した情報を含むＴＣＰ接続のプロセスＩＤをＴＣＰ接続一覧情報の中から取得する。図９（ａ）～図９（ｃ）の例では、ＩＤ発行部２６２は、接続元アプリ（ブラウザ２０）のプロセスＩＤ＝１３３２を取得することができる。

次いで、ＩＤ発行部２６２は、アプリ情報取得部２６４に対して、取得したプロセスＩＤとともに、呼出元アプリ情報の取得要求を送信する（Ｓ１２）。

次いで、アプリ情報取得部２６４は、ＯＳ ＡＰＩを用いて、受信したプロセスＩＤに対応する呼出元アプリ情報（プロセス名）を取得する（Ｓ１４、Ｓ１６）。この場合、アプリ情報取得部２６４は、例えばWindows（登録商標）のプロセス情報取得ＡＰＩ（ＰＳＡＰＩ）を用いて、プロセスＩＤに対応するプロセス名（例えば、chrome.exeとする）を取得する。

次いで、アプリ情報取得部２６４は、取得した呼出元アプリ情報（プロセス名）をＩＤ発行部２６２に返信する（Ｓ１８）。そして、ＩＤ発行部２６２は、呼出元アプリ情報（プロセス名）から身元証明ＩＤを生成する（Ｓ２０）。具体的には、ＩＤ発行部２６２は、取得したプロセス名と、乱数生成関数と、を用いて一意な身元証明ＩＤを生成する。そして、ＩＤ発行部２６２は、身元証明ＩＤと、プロセスＩＤと、プロセス名とを紐づけて図１０（ａ）の管理情報テーブル８０において管理する。図１０（ａ）の管理情報テーブル８０においては、身元証明ＩＤと、プロセスＩＤと、プロセス名と、を対応付けて管理している。図１０（ａ）の例では、身元証明ＩＤ「１２３４５」と、プロセスＩＤ「１３３３２」と、プロセス名「chrome.exe」とが対応付けられている。

その後は、ＩＤ発行部２６２が、生成した身元証明ＩＤをPolyfill２４のＩＤ取得部２４４に返信する（Ｓ２２）。図５の処理が行われた後は、図６の処理に移行する。

図６には、アクセス制御処理の手順（その２）が示されている。

前述のように、Polyfill２４のＩＤ取得部２４４が、ＩＤ発行部２６２から身元証明ＩＤを受信すると（図５のＳ２２）、ＩＤ取得部２４４は、ブリッジインタフェース２８の署名依頼部２８２に対して身元証明ＩＤ（＝１２３４５）を送信する。これにより、ＩＤ取得部２４４は、呼出元アプリの署名依頼を行う（Ｓ３０）。

次いで、署名依頼部２８２は、アプリ情報取得依頼部２８４に対して身元証明ＩＤ（＝１２３４５）を送信することで、呼出元アプリ情報の取得要求を行う（Ｓ３２）。また、アプリ情報取得依頼部２８４は、Platformアプリ２６のＩＤ検証部２６６に対して身元証明ＩＤ（＝１２３４５）を送信することで、呼出元アプリ情報の取得要求を行う（Ｓ３４）。

ＩＤ検証部２６６は、身元証明ＩＤ（＝１２３４５）を取得すると、呼出元アプリ情報を特定する（Ｓ３６）。このとき、ＩＤ検証部２６６は、身元証明ＩＤ（＝１２３４５）について自身が発行したＩＤであるかを、図１０（ａ）の管理情報テーブル８０を用いて検証する。そして、ＩＤ検証部２６６は、受信した身元証明ＩＤが管理情報テーブル８０に存在していることを確認できた場合には、身元証明ＩＤに対応するプロセス名（chrome．exe）とＷｉｎｄｏｗｓのデスクトップ環境において最前面に配置されているウィンドウ（アプリ）の情報を取得する。以下においては、最前面に配置されているアプリの情報を「前面表示アプリ情報」と呼ぶ。前面表示アプリ情報を取得する際には、ＩＤ検証部２６６は、Ｗｉｎｄｏｗｓのデスクトップ環境において、ウィンドウが切り替わるときの一意の識別子（ウィンドウハンドル）を取得し、ウィンドウハンドルに基づき最前面のアプリ名を取得する。なお、ここでは、前面表示アプリ情報として、「chrome.exe」が取得されたものとする。ＩＤ検証部２６６は、プロセス名と前面表示アプリ情報を取得すると、ブリッジインタフェース２８のアプリ情報取得依頼部２８４にプロセス名と前面表示アプリ情報を返信する（Ｓ３８）。

アプリ情報取得依頼部２８４は、プロセス名と前面表示アプリ情報を受信すると、署名依頼部２８２に対してプロセス名と前面表示アプリ情報を送信する（Ｓ４０）。

次いで、署名依頼部２８２は、例えばＢＬＥで接続された外部認証器４００にＦＩＤＯのＣＴＡＰ通信により接続し、外部認証器４００の署名部４４にプロセス名と前面表示アプリ情報を送信して、署名依頼を実行する（Ｓ４２）。このとき、署名部４４は、鍵管理部４２で管理されている秘密鍵を用いてプロセス名（chrome.exe）と前面表示アプリ情報（chrome.exe）に署名を実行し、署名付きプロセス名と署名付き前面表示アプリ情報とを署名依頼部２８２に返信する（Ｓ４４）。

署名依頼部２８２は、署名付きプロセス名と署名付き前面表示アプリ情報とを受信すると、受信した情報をPolyfill２４のサーバ検証連携部２４２に送信する（Ｓ４６）。以上のようにして図６の処理が終了すると、図７の処理に移行する。

図７には、アクセス制御処理の手順（その３）が示されている。

図７の処理においては、Polyfill２４のサーバ検証連携部２４２が、署名依頼部２８２から受信した署名付きプロセス名と署名付き前面表示アプリ情報とを認証サーバ３００の検証部６０に送信する（Ｓ５０）。

検証部６０は、署名付きプロセス名と署名付き前面表示アプリ情報を受信すると、検証処理を実行する（Ｓ５２）。検証部６０は、検証処理において、図８のフローチャートに沿った処理を実行する。

図８の処理では、まず、ステップＳ６０において、検証部６０が、プロセス名（chrome.exe）の署名検証及び前面表示アプリ情報（chrome.exe）の署名検証を公開鍵を用いて実行する。

次いで、ステップＳ６２では、検証部６０が、検証に成功したか否かを判断する。このステップＳ６２の判断が肯定されると、ステップＳ６４に移行する。

ステップＳ６４に移行すると、検証部６０は、ホワイトリスト検証及びプロセス名と前面表示アプリ情報の一致検証を実行する。ホワイトリスト検証においては、検証部６０は、ホワイトリスト８２（図１０（ｂ））を参照して、プロセス名（chrome.exe）がホワイトリスト８２に含まれているか否かを検証する。なお、ホワイトリスト８２は、外部認証器４００への接続が許可されているアプリ（ブラウザ）の名称（アプリ名）が予め登録されているリストである。また、一致検証においては、検証部６０は、プロセス名（chrome.exe）と前面表示アプリ名（chrome.exe）とが同一であるか否かを検証する。なお、検証部６０が検証において用いる情報は、プロセス名に限られるものではない。検証部６０は、例えば、ブラウザのバージョンや、ブラウザのタブ名などをホワイトリストにおいて管理し、現在表示しているブラウザのバージョンやブラウザのタブ名がホワイトリストに含まれているかを検証してもよい。このようにすることで、検証精度をより高めることができる。

次いで、ステップＳ６６では、検証部６０が、検証に成功したか否かを判断する。このステップＳ６６では、上記ホワイトリスト検証及び一致検証の両方に成功した場合に、判断が肯定される。ステップＳ６６の判断が肯定されると、検証部６０は、ステップＳ６８に移行する。

ステップＳ６８に移行すると、検証部６０は、検証結果を、外部認証器４００へのアクセス許可とする。

一方、ステップＳ６２又はステップＳ６６の判断が否定された場合には、ステップＳ７０に移行する。ステップＳ７０では、検証部６０は、検証結果を、外部認証器４００へのアクセス拒否とする。

ステップＳ６８又はステップＳ７０の処理が行われた後は、図８の全処理を終了する。

図７に戻り、上記のように検証処理（Ｓ５２）が終了すると、検証部６０は、サーバ検証連携部２４２に対して検証結果を送信する（Ｓ５４）。例えば、サーバ検証連携部２４２が、検証結果（アクセス許可）を受信すると、ブリッジインタフェース２８によって、ブラウザ２０から外部認証器４００へのアクセスが許可される。一方、サーバ検証連携部２４２が、検証結果（アクセス拒否）を受信すると、ブリッジインタフェース２８によって、ブラウザ２０から外部認証器４００へのアクセスが拒否される。このように本実施形態では、ブリッジインタフェース２８が、ブラウザ２０と外部認証器４００との接続可否を制御する制御部として機能している。

なお、本実施形態において図示した各部は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、サーバ検証連携部２４２とＩＤ取得部２４４とを統合してもよいし、ＩＤ発行部２６２とアプリ情報取得部２６４とＩＤ検証部２６６とを統合してもよい。また、図示した各処理は、上記の順番に限定されるものでなく、処理内容を矛盾させない範囲において、同時に実施してもよく、順序を入れ替えて実施してもよい。

さらに、各装置で行われる各種処理機能は、ＣＰＵ（またはＭＰＵ、ＭＣＵ（Micro Controller Unit）等のマイクロ・コンピュータ）上で、その全部または任意の一部を実行するようにしてもよい。また、各種処理機能は、ＣＰＵ（またはＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行されるプログラム上、またはワイヤードロジックによるハードウェア上で、その全部または任意の一部を実行するようにしてもよいことは言うまでもない。

ところで、本実施形態で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することで実現できる。そこで、以下では、本実施形態と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図１１は、情報処理プログラムを実行するコンピュータ５００の一例を示す図である。

図１１に示すように、コンピュータ５００は、各種演算処理を実行するＣＰＵ１９０と、データ入力を受け付ける入力装置１９５と、モニタ１９３とを有する。また、コンピュータ５００は、可搬型記憶媒体からプログラム等を読み取る可搬型記憶媒体用ドライブ１９９と、他の情報処理装置等と有線または無線により接続するための通信装置１９７とを有する。また、コンピュータ５００は、ＲＯＭ１９２、ＲＡＭ１９４、ＨＤＤ１９６を有する。これら、コンピュータ５００に含まれる各装置は、バス１９８に接続される。

ＲＯＭ１９２には、図４に示した端末装置１００の各部と同様の機能を有する情報処理プログラムが記憶される。また、ＲＯＭ１９２には、管理情報テーブル８０や、情報処理プログラムを実現するための各種データが記憶される。入力装置１９５は、例えば、コンピュータ５００のユーザから操作情報等の各種情報の入力を受け付ける。モニタ１９３は、例えば、コンピュータ５００のユーザに対して表示画面等の各種画面を表示する。通信装置１９７は、例えば、ネットワークＮと接続され、提供サーバ２００、認証サーバ３００および他の情報処理装置と各種情報をやりとりする。また、通信装置１９７は、外部認証器４００と接続される。

ＣＰＵ１９０は、ＲＯＭ１９２に記憶された各プログラムを読み出して、ＲＡＭ１９４に展開して実行することで、各種の処理を行う。また、これらのプログラムは、コンピュータ５００を図４に示した端末装置１００の各部として機能させることができる。

なお、上記の情報処理プログラムは、必ずしもＲＯＭ１９２に記憶されている必要はない。例えば、コンピュータ５００が読み取り可能な可搬型記憶媒体１９１に記憶されたプログラムを、コンピュータ５００が読み出して実行するようにしてもよい。可搬型記憶媒体としては、例えば、ＣＤ－ＲＯＭやＤＶＤ（Digital Versatile Disc）、ＵＳＢメモリ等が挙げられる。また、公衆回線、インターネット、ＬＡＮ等に接続された装置にこの情報処理プログラムを記憶させておき、コンピュータ５００がこれらから情報処理プログラムを読み出して実行するようにしてもよい。

以上、詳細に説明したように、本実施形態によると、ブラウザ２０がブリッジインタフェース経由により外部認証器４００に接続するときに、ＩＤ発行部２６２は、ブラウザ２０の情報（プロセスＩＤやプロセス名）を取得する。また、ＩＤ発行部２６２は、取得したプロセス名から身元証明ＩＤを生成してＩＤ取得部２４４に送信するとともに、生成した身元証明ＩＤとブラウザ２０のプロセスＩＤ、プロセス名とを関連付けて管理情報テーブル８０において管理する。また、ＩＤ検証部２６６は、ブリッジインタフェース２８経由でブラウザ２０から身元証明ＩＤを取得すると、管理情報テーブル８０を参照して、身元証明ＩＤに対応するプロセス名や前面表示アプリ情報を取得する。また、署名依頼部２８２は、ＩＤ検証部２６６が取得したプロセスＩＤや前面表示アプリ情報を外部認証器４００に送信して、署名依頼を行う。また、サーバ検証連携部２４２は、外部認証器４００から署名付きのプロセス名や署名付きの前面表示アプリ情報をブリッジインタフェース２８経由で取得して認証サーバ３００に送信する。そして、ブリッジインタフェース２８は、認証サーバ３００による認証結果に基づいて、ブラウザ２０と外部認証器４００との接続可否を制御する。すなわち、本実施形態では、身元証明ＩＤの発行を受けたブラウザ２０から署名依頼があったときに、ブラウザのプロセス名と前面表示アプリ情報に対して外部認証器４００により署名が行われる。そして、署名付きのプロセス名と署名付きの前面表示アプリ情報を認証サーバ３００で検証した結果、接続が許可できると判断されれば、ブラウザ２０から外部認証器４００へのアクセスが許可される。したがって、本実施形態では、図１２（ａ）において両矢印で示す箇所で信頼関係が結ばれ、ブラウザ２０の認証ライブラリ（Polyfill）２４と、外部認証器４００との間の信頼関係が結ばれることで、認証サーバ３００で認証されたブラウザ２０のみが外部認証器４００にアクセスできるようになる。このため、端末装置１００にインストールされた不正アプリ（バックグラウンドで動作するマルウエアのようなアプリ）が外部認証器４００にアクセスするのを防止することができる。この場合、ユーザにＰＩＮ入力を要求しなくてもよいため、ユーザの利便性低下を抑制することができる。

ここで、比較例として、図１２（ｂ）には、ＡＳＭ（Authenticator Specific Module）がＦＩＤＯクライアントと認証器の間の接続を制御する例（ＦＩＤＯ ＵＡＦ環境）が示されている。この例では、ＦＩＤＯクライアントのブラウザプラグインがFacet IDを測定するとともに、ＡＳＭが経路情報を測定する。そして、認証器でFacet IDとプロセスＩＤに署名し、署名付きのデータを認証サーバの検証部で検証することとしている。しかしながら、本実施形態のように外部認証器４００との接続にＣＴＡＰ通信を用いると、ブラウザプラグインが利用できないため、図１２（ｂ）の方式を利用することはできない。これに対し、本実施形態のような方法を採用することで、端末装置１００と外部認証器４００とがＣＴＡＰ通信を行う場合であっても、不正なアプリからのアクセスを制限することが可能となっている。

なお、上記実施形態では、ＩＤ検証部２６６が、ステップＳ３６において、身元証明ＩＤに対応するプロセス名を取得する際に、前面表示アプリ情報を取得する場合について説明したが、これに限られるものではない。すなわち、ＩＤ検証部２６６は、ステップＳ３６において、プロセス名のみを取得することとしてもよい。この場合、外部認証器４００の署名部４４では、プロセス名に対して署名が実行され、認証サーバ３００では、署名付きのプロセス名を用いたホワイトリスト検証が行われる。このホワイトリスト検証に成功すれば、ブラウザ２０から外部認証器４００へのアクセスが可能となる。このようにしても、上記実施形態と同様の作用効果を得ることができる。

なお、上記実施形態では、外部認証器４００がスマートフォンである場合について説明したが、これに限らず、その他のBluetooth機器、ＮＦＣ搭載デバイス、ＵＳＢトークンなどを用いることもできる。

＜変形例１＞
図１３には、認証システムの変形例１が示されている。Windows8.1以降ではWindows Biometric Framework（ＷＢＦ）により内蔵認証器に接続できる。しかしながら、ＷＢＦ非対応の認証器を内蔵しているコンピュータでは、ブリッジインタフェースにより内蔵認証器に接続する必要がある。図１３には、このようなブリッジインタフェース（２８）により接続する内蔵認証器８００を有する端末装置６００が示されている。このような端末装置６００においても、Polyfill２４や、Platformアプリ２６、ブリッジインタフェース２８、内蔵認証器８００の署名部４４が上記実施形態と同様の処理を実行することで、不正なアプリからの内蔵認証器８００へのアクセスを防止することができる。なお、端末装置６００の各部の処理は、上記実施形態と同様であるため、説明は省略する。

＜変形例２＞
図１４には、認証システムの変形例２が示されている。本変形例２に係る認証システム１０’では、呼出元アプリの検証を情報処理装置としての端末装置１００’内の測定アプリ２６’が実行する。ここで、本変形例２においては、図１４と図３を比較するとわかるように、端末装置１００’からはブリッジインタフェースが省略されている。また、本変形例２の認証サーバ３００は、ホワイトリストを保持していない。更に、本変形例２の外部認証器４００’は、図３の外部認証器４００が有する機能に加えて、ＣＢＯＲパーサー部３４０、検証結果取得部３４２、及びアクセス制御部３４４の機能を有している。

また、本変形例２の端末装置１００’の認証ライブラリ（Polyfill）２４’は、図１５に示すように、上記実施形態の認証ライブラリ２４が有していたＩＤ取得部２４４を有していない。更に、本変形例２の端末装置１００’の測定アプリ（Platformアプリ）２６’は、図３のPlatformアプリ２６とは機能が異なっている。具体的には、図１５に示すように、Platformアプリ２６’は、アプリ情報取得部３６０と、生成部としてのＩＤ発行部３６２と、検証部３６４と、ＩＤ検証部３６６と、を有する。また、Platformアプリ２６’は、第１リストとしてのホワイトリスト３８２、第２リストとしてのホワイトリスト３８３、及び記憶部としての管理情報テーブル３８０、を有する。

ここで、ホワイトリスト３８２は、上記実施形態において認証サーバ３００が有していたホワイトリスト８２と同様のリストである。具体的には、ホワイトリスト３８２は、図１６（ａ）に示すように、外部認証器４００’への接続が許可されているアプリ（ブラウザ）の名称（アプリ名）が予め登録されているリストである。また、ホワイトリスト３８３は、図１６（ｂ）に示すように、ブラウザからの接続が許可されている提供サーバのアドレスが予め登録されているリストである。

管理情報テーブル３８０は、検証部３６４の検証結果を格納するテーブルであり、図１７に示すようなデータ構造を有する。なお、管理情報テーブル３８０の詳細については後述する。

（認証システム１０’における外部認証器４００’へのアクセス制御について）
次に、認証システム１０’における外部認証器４００’へのアクセス制御について、図１８～図２０に基づいて詳細に説明する。

図１８には、アクセス制御処理の手順（その１）が示されている。図１８の処理では、まず、Polyfill２４のサーバ検証連携部２４２が、Platformアプリ２６’にアクセスするときに、アプリ情報取得部３６０に対して、身元証明ＩＤの発行要求を実行する（Ｓ７１）。この場合、サーバ検証連携部２４２は、呼出元アプリ情報として、challenge、origin、type、プロセス名の情報をアプリ情報取得部３６０に送信する。ここで、challenge、origin、typeの詳細については、非特許文献２に開示されているが、challengeは、認証サーバから取得するランダムな値である。また、originは、ＵＲＬのスキーム、ホスト、ポートなどにより表される情報であり、例えば、「www.access-server1.co.jp:80」などである。typeは、登録か認証を表す文字列であり、例えば、「webauthn.create」や「webauthn.get」である。プロセス名は、呼出元アプリのプロセス名である。

次いで、ＩＤ発行部３６２が、アプリ情報取得部３６０から取得したchallenge、origin、typeからclientDataHashを生成し、身元証明ＩＤとする（Ｓ７２）。ここで、本変形例２では、上記実施形態の身元証明ＩＤ（プロセス名と乱数生成関数とを用いて生成される一意のＩＤ）の代わりに、非特許文献２に記載の「WebAuthn spec」に規定されているＡＰＩ(WebAuthn API)により取得可能なclientDataHashを身元証明ＩＤとして用いることとする。clientDataHashはchallenge、origin、typeから生成することができる。

次いで、検証部３６４は、呼出元アプリ情報をＩＤ発行部３６２から取得する（Ｓ７３）。そして、検証部３６４は、ホワイトリスト３８２、３８３を使って呼出元アプリ情報を検証し、身元証明ＩＤ（clientDataHash）を管理情報テーブル３８０において管理する。具体的には、検証部３６４は、ホワイトリスト３８２を参照して、サーバ検証連携部２４２から送られてきたプロセス名がホワイトリスト３８２に存在するか否かを確認する。また、検証部３６４は、Ｗｉｎｄｏｗｓのデスクトップ環境において最前面に配置されているウィンドウ（アプリ）の情報（前面表示アプリ情報）を上記実施形態と同様にして取得し、サーバ検証連携部２４２から送られてきたプロセス名と一致するかを確認する。更に、検証部３６４は、originから提供サーバ２０のアドレス情報を取得し、当該アドレス情報がホワイトリスト３８３に存在するかを確認する。そして、検証部３６４は、検証結果（ＯＫ／ＮＧ）それぞれを、身元証明ＩＤ（clientDataHash）と紐づけて管理情報テーブル３８０に格納する。なお、検証部３６４は、提供サーバ２０のアドレス情報をoriginから取得せずに、サーバ検証連携部２４２に提供サーバ２０のアドレス情報を要求するようにしてもよい。

ここで、管理情報テーブル３８０は、図１７に示すように、「clientDataHash（身元証明ＩＤ）」に対応付けて、「呼出元アプリ検証結果」、「プロセス名と前面表示アプリ情報一致検証結果」、「提供サーバ検証結果」が格納される。「呼出元アプリ検証結果」には、受信したプロセス名がホワイトリスト３８２に存在していれば「ＯＫ」、いなければ「ＮＧ」が格納される。「プロセス名と前面表示アプリ情報一致検証結果」には、受信したプロセス名と前面表示アプリ情報とが一致していれば「ＯＫ」、いなければ「ＮＧ」が格納される。「提供サーバ検証結果」には、提供サーバのアドレスがホワイトリスト３８３に存在していれば「ＯＫ」、いなければ「ＮＧ」が格納される。

以上のように、検証部３６４の検証結果が管理情報テーブル３８０に格納されると、検証部３６４は、検証処理完了をRelying Partyアプリ２２のPolyfill２４’に通知する（Ｓ７５）。

図１９には、アクセス制御処理の手順（その２）が示されている。図１９の処理においては、前述のように、ステップＳ７５の検証処理完了通知がRelying Partyアプリ２２に通知されると、Relying Partyアプリ２２は、非特許文献２記載の「WebAuthn spec」に規定のＡＰＩ(WebAuthn API)による接続方式に従い、外部認証器４００’のＣＴＡＰ接続インタフェース４０に接続する。このとき、Relying Partyアプリ２２はchallenge、origin、type情報を外部認証器に送信する（Ｓ７６）。

外部認証器４００’のＣＢＯＲパーサー部３４０は、ＣＴＡＰ接続インタフェース４０が受信したＣＢＯＲ形式データからclientDataHash情報をパースして、取得する（Ｓ７７）。そして、ＣＢＯＲパーサー部３４０は、検証結果取得部３４２経由でPlatformアプリ２６’のＩＤ検証部３６６にclientDataHashを送信する（Ｓ７８）。

次いで、Platformアプリ２６’のＩＤ検証部３６６は、管理情報テーブル３８０を参照し、外部認証器４００’の検証結果取得部３４２から受信したclientDataHashと一致するデータがあるかを検証する（Ｓ７９）。この検証の結果、一致するclientDataHashが管理情報テーブル３８０に存在していた場合には、当該clientDataHashに紐付く検証結果を管理情報テーブル３８０から取得して、外部認証器４００’の検証結果取得部３４２に返信する（Ｓ８０）。

次いで、外部認証器４００’のアクセス制御部３４４は、検証結果取得部３４２経由でclientDataHashに紐付く検証結果を取得すると、取得した全ての検証結果が「ＯＫ」のときに、外部認証器４００’によるＦＩＤＯの署名処理を許可し、１つでも「ＮＧ」のときには、署名処理を許可しないようにアクセス制御する（Ｓ８１）。そして、アクセス制御部３４４は、アクセス制御の結果をログ（図２０）に記録する（Ｓ８２）。なお、図２０のログには、タイムスタンプに紐付けて、取得した３つの検証結果と、署名処理の許可／不許可が記録される。このログは、例えば、外部認証器４００’をメンテナンスする作業者が参照することができる。

これまでの説明から明らかなように、本変形例２では、ＩＤ検証部３６６が、外部認証器４００’が生成したclientDataHashを受信して、該clientDataHashに紐づく検証結果を管理情報テーブル３８０から取得する取得部、及び外部認証器４００’に対して、取得結果を送信する送信部としての機能を有する。

以上説明したように、本変形例２によれば、ＩＤ発行部３６２は、ブラウザ２０が外部認証器４００’に接続するときに、アプリ情報取得部３６０がブラウザ２０から取得した情報（challenge、origin、type）を用いて、一意の識別情報（clientDataHash）を生成する（Ｓ７２）。また、検証部３６４は、ホワイトリスト３８２を参照して、clientDataHashがホワイトリスト３８２に格納されているかを検証し、検証結果をclientDataHashと紐づけて管理情報テーブル３８０に記憶する（Ｓ７４）。また、検証部３６４は、検証完了通知をブラウザ２０に送信する（Ｓ７５）。更に、ＩＤ検証部３６６は、ブラウザ２０から取得した情報（challenge、origin、type）を用いて外部認証器４００’が生成したclientDataHashを受信して（Ｓ７８）、受信したclientDataHashに紐づく検証結果を管理情報テーブル３８０から取得し、外部認証器４００’に対して、clientDataHashに紐付く検証結果を送信する（Ｓ８０）。この場合、外部認証器４００’のアクセス制御部３４４は、受信した検証結果に基づいてブラウザ２０との接続可否を制御する。これにより、本変形例２では、端末装置１００’内において不正なアプリからの外部認証器４００’へのアクセスを防止することができる。また、本変形例２では、身元証明ＩＤとして、ＦＩＤＯ認証において利用されるclientDataHashを用いることとしているため、ＦＩＤＯ認証において利用されない身元証明ＩＤを用いるような場合と比べて、システム開発の難易度を低減することができる。

また、本変形例２では、検証部３６４は、Ｗｉｎｄｏｗｓのデスクトップ環境において最前面に配置されているウィンドウ（アプリ）の情報（前面表示アプリ情報）を取得する。そして、検証部３６４は、取得した前面表示アプリ情報と、ブラウザ２０のプロセス名とが一致するかを確認し、確認結果を管理情報テーブル３８０に格納する。この場合、外部認証器４００’において、前面表示アプリ情報とブラウザ２０のプロセス名が一致しない場合に、ブラウザ２０の接続を許可しないようにすることで、端末装置１００’にインストールされた不正アプリ（バックグラウンドで動作するマルウエアのようなアプリ）が外部認証器４００’にアクセスするのを防止することができる。

また、本変形例２では、検証部３６４は、ホワイトリスト３８３を参照して、ブラウザ２０が接続する提供サーバ２００の情報がホワイトリスト３８３に格納されているかを検証し、検証結果を管理情報テーブル３８０に記憶する。この場合、外部認証器４００’において、ブラウザ２０が接続する提供サーバ２００の情報がホワイトリスト３８３に無い場合に、ブラウザ２０の接続を許可しないようにすることで、不正な提供サーバからの外部認証器４００’へのアクセスを防止することができる。

なお、上記実施形態では、端末装置１００側で生体情報を照合してユーザ認証処理を行い、その認証結果を認証サーバ３００側に送信する手法としてＦＩＤＯを挙げたが、これに限定されない。例えば、端末装置１００に接続された外部認証器４００において生体認証（ローカル認証）を行うものであれば、各種の手法を用いてもよい。なお、ローカル認証は、ユーザが利用している外部認証器に生体データを保持（登録）しておき、保持している生体データを用いて外部認証器内で認証を行うことを意味する。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
（付記１） ブラウザがブリッジインタフェース経由により認証器に接続するときに、前記ブラウザの情報を取得して、取得した前記ブラウザの情報から一意の識別情報を生成して前記ブラウザに送信し、生成した前記一意の識別情報と前記ブラウザの情報とを関連付けて記憶部において管理する管理部と、
前記ブラウザから前記一意の識別情報を取得し、前記記憶部を参照して、取得した前記一意の識別情報に対応する前記ブラウザの情報を取得する取得部と、
前記取得部が取得した前記ブラウザの情報を前記認証器に送信して、前記ブラウザの情報に署名を付すように依頼する依頼部と、
前記認証器から署名付きのブラウザの情報を取得し、取得した前記署名付きのブラウザの情報を認証サーバに送信する送信部と、
前記認証サーバによる前記署名付きのブラウザの情報を用いた認証結果に基づいて、前記ブラウザと前記認証器の接続可否を制御する制御部と、を備える情報処理装置。
（付記２） 前記取得部は、前記ブラウザの情報とともに、前記情報処理装置の表示部において最前面に表示されているアプリの情報を取得し、
前記依頼部は、前記取得部が取得した前記ブラウザの情報と前記アプリの情報とを前記認証器に送信して、前記ブラウザの情報と前記アプリの情報に署名を付すように依頼し、
前記送信部は、前記認証器から署名付きのブラウザの情報と署名付きのアプリの情報とを取得し、取得した情報を前記認証サーバに送信し、
前記制御部は、前記認証サーバによる前記署名付きのブラウザの情報と前記署名付きのアプリの情報とを用いた認証結果に基づいて、前記ブラウザと前記認証器の接続可否を制御する、
ことを特徴とする付記１に記載の情報処理装置。
（付記３） 前記制御部は、前記認証サーバの認証結果が、署名が付された前記ブラウザの情報が、前記認証器への接続が許可されているブラウザのリストに載っており、署名が付された前記ブラウザの情報と署名が付された前記アプリの情報とが一致していることを示す場合に、前記ブラウザと前記認証器の接続を許可する制御を実行する、ことを特徴とする付記２に記載の情報処理装置。
（付記４） 前記認証器を前記ブリッジインタフェースと共に内蔵することを特徴とする付記１～３のいずれかに記載の情報処理装置。
（付記５） ブラウザがブリッジインタフェース経由によりされた認証器に接続するときに、前記ブラウザの情報を取得して、取得した前記ブラウザの情報から一意の識別情報を生成して前記ブラウザに送信し、生成した前記一意の識別情報と前記ブラウザの情報とを関連付けて記憶部において管理し、
前記ブラウザから前記一意の識別情報を取得し、前記記憶部を参照して、取得した前記一意の識別情報に対応する前記ブラウザの情報を取得し、
取得した前記ブラウザの情報を前記認証器に送信して、前記ブラウザの情報に署名を付すように依頼し、
前記認証器から署名付きのブラウザの情報を取得し、取得した前記署名付きのブラウザの情報を認証サーバに送信し、
前記認証サーバによる前記署名付きのブラウザの情報を用いた認証結果に基づいて、前記ブラウザと前記認証器の接続可否を制御する、処理をコンピュータが実行することを特徴とする情報処理方法。
（付記６） 前記取得する処理では、前記ブラウザの情報とともに、前記情報処理装置の表示部において最前面に表示されているアプリの情報を取得し、
前記依頼する処理では、前記取得する処理において取得した前記ブラウザの情報と前記アプリの情報とを前記認証器に送信して、前記ブラウザの情報と前記アプリの情報に署名を付すように依頼し、
前記送信する処理では、前記認証器から署名付きのブラウザの情報と署名付きのアプリの情報とを取得し、取得した情報を前記認証サーバに送信し、
前記制御する処理では、前記認証サーバによる前記署名付きのブラウザの情報と前記署名付きのアプリの情報とを用いた認証結果に基づいて、前記ブラウザと前記認証器の接続可否を制御する、
ことを特徴とする付記４に記載の情報処理方法。
（付記７） 前記制御する処理では、前記認証サーバの認証結果が、署名が付された前記ブラウザの情報が、前記認証器への接続が許可されているブラウザのリストに載っており、署名が付された前記ブラウザの情報と署名が付された前記アプリの情報とが一致していることを示す場合に、前記ブラウザと前記認証器の接続を許可する制御を実行する、ことを特徴とする付記６に記載の情報処理方法。
（付記８）ブラウザがブリッジインタフェース経由により認証器に接続するときに、前記ブラウザの情報を取得して、取得した前記ブラウザの情報から一意の識別情報を生成して前記ブラウザに送信し、生成した前記一意の識別情報と前記ブラウザの情報とを関連付けて記憶部において管理し、
前記ブラウザから前記一意の識別情報を取得し、前記記憶部を参照して、取得した前記一意の識別情報に対応する前記ブラウザの情報を取得し、
取得した前記ブラウザの情報を前記認証器に送信して、前記ブラウザの情報に署名を付すように依頼し、
前記認証器から署名付きのブラウザの情報を取得し、取得した前記署名付きのブラウザの情報を認証サーバに送信し、
前記認証サーバによる前記署名付きのブラウザの情報を用いた認証結果に基づいて、前記ブラウザと前記認証器の接続可否を制御する、処理をコンピュータに実行させるための情報処理プログラム。
（付記９） ブラウザが認証器に接続するときに、前記ブラウザから取得した情報を用いて、一意の識別情報を生成する生成部と、
接続を許可するブラウザの識別情報を格納する第１リストを参照して、前記生成部が生成した前記識別情報が前記第１リストに格納されているかを検証し、検証結果を前記識別情報と紐づけて記憶部に記憶するとともに、検証完了通知を前記ブラウザに送信する検証部と、
ブラウザから取得した情報を用いて前記認証器が生成した一意の識別情報を受信して、該識別情報に紐づく検証結果を前記記憶部から取得する取得部と、
前記取得部の取得結果に基づいて前記ブラウザとの接続可否を制御する前記認証器に対して、前記取得結果を送信する送信部と、
を備える情報処理装置。
（付記１０） 前記検証部は、前記情報処理装置の表示部において最前面に表示されているアプリの情報を取得し、取得したアプリ情報と、前記ブラウザから取得した情報との一致検証を行い、該一致検証の結果も前記識別情報と紐づけて前記記憶部に記憶する、ことを特徴とする付記９に記載の情報処理装置。
（付記１１） 前記検証部は、前記ブラウザが接続する情報提供装置の情報を取得し、前記ブラウザが接続可能な情報提供装置の情報を格納する第２リストを参照して、取得した前記情報提供装置の情報が前記第２リストに格納されているかを検証し、該検証結果も前記識別情報と紐づけて前記記憶部に記憶する、ことを特徴とする付記９又は１０に記載の情報処理装置。
（付記１２） 前記一意の識別情報は、ＦＩＤＯ（Fast IDentity Online）認証において利用されるclientDataHashであることを特徴とする付記９～１１のいずれかに記載の情報処理装置。
（付記１３） ブラウザが認証器に接続するときに、前記ブラウザから取得した情報を用いて、一意の識別情報を生成し、
接続を許可するブラウザの識別情報を格納する第１リストを参照して、前記生成部が生成した前記識別情報が前記第１リストに格納されているかを検証し、検証結果を前記識別情報と紐づけて記憶部に記憶するとともに、検証完了通知を前記ブラウザに送信し、
ブラウザから取得した情報を用いて前記認証器が生成した一意の識別情報を受信して、該識別情報に紐づく検証結果を前記記憶部から取得し、
前記取得する処理の取得結果に基づいて前記ブラウザとの接続可否を制御する前記認証器に対して、前記取得結果を送信する、
処理をコンピュータが実行することを特徴とする情報処理方法。
（付記１４） 前記検証において、前記情報処理装置の表示部において最前面に表示されているアプリの情報を取得し、取得したアプリ情報と、前記ブラウザから取得した情報との一致検証を行い、該一致検証の結果も前記識別情報と紐づけて前記記憶部に記憶する、ことを特徴とする付記１３に記載の情報処理方法。
（付記１５） 前記検証において、前記ブラウザが接続する情報提供装置の情報を取得し、前記ブラウザが接続可能な情報提供装置の情報を格納する第２リストを参照して、取得した前記情報提供装置の情報が前記第２リストに格納されているかを検証し、該検証結果も前記識別情報と紐づけて前記記憶部に記憶する、ことを特徴とする付記９又は１０に記載の情報処理方法。
（付記１６） 前記一意の識別情報は、ＦＩＤＯ（Fast IDentity Online）認証において利用されるclientDataHashであることを特徴とする付記９～１１のいずれかに記載の情報処理方法。
（付記１７） ブラウザが認証器に接続するときに、前記ブラウザから取得した情報を用いて、一意の識別情報を生成し、
接続を許可するブラウザの識別情報を格納する第１リストを参照して、前記生成部が生成した前記識別情報が前記第１リストに格納されているかを検証し、検証結果を前記識別情報と紐づけて記憶部に記憶するとともに、検証完了通知を前記ブラウザに送信し、
ブラウザから取得した情報を用いて前記認証器が生成した一意の識別情報を受信して、該識別情報に紐づく検証結果を前記記憶部から取得し、
前記取得する処理の取得結果に基づいて前記ブラウザとの接続可否を制御する前記認証器に対して、前記取得結果を送信する、
処理をコンピュータに実行させるための情報処理プログラム。

２０ ブラウザ
２８ ブリッジインタフェース（制御部）
８０ 記憶部（管理情報テーブル）
８２ ホワイトリスト（ブラウザのリスト）
１００ 端末装置（情報処理装置）
２４２ サーバ検証連携部（送信部）
２６２ ＩＤ発行部（管理部）
２６６ ＩＤ検証部（取得部）
２８２ 署名依頼部（依頼部）
３６２ ＩＤ発行部（生成部）
３６４ 検証部
３６６ ＩＤ検証部（取得部、送信部）
３８０ 管理情報テーブル（記憶部）
３８２ ホワイトリスト（第１リスト）
３８３ ホワイトリスト（第２リスト）
４００ 外部認証器（認証器）
４００’ 外部認証器（認証器）

Claims (12)

1. ブラウザがブリッジインタフェースを経由して認証器に接続するときに、前記ブラウザの情報を取得して、取得した前記ブラウザの情報から一意の識別情報を生成して前記ブラウザに送信し、生成した前記一意の識別情報と前記ブラウザの情報とを関連付けて記憶部において管理する管理部と、
   前記ブラウザから前記一意の識別情報を取得し、前記記憶部を参照して、取得した前記一意の識別情報に対応する前記ブラウザの情報を取得する取得部と、
   前記取得部が取得した前記ブラウザの情報を前記認証器に送信して、前記ブラウザの情報に署名を付すように依頼する依頼部と、
   前記認証器から署名付きのブラウザの情報を取得し、取得した前記署名付きのブラウザの情報を認証サーバに送信する送信部と、
   前記認証サーバによる前記署名付きのブラウザの情報を用いた認証結果に基づいて、前記ブラウザと前記認証器の接続可否を制御する制御部と、を備える情報処理装置。
2. 前記取得部は、前記ブラウザの情報とともに、前記情報処理装置の表示部において最前面に表示されているアプリの情報を取得し、
   前記依頼部は、前記取得部が取得した前記ブラウザの情報と前記アプリの情報とを前記認証器に送信して、前記ブラウザの情報と前記アプリの情報に署名を付すように依頼し、
   前記送信部は、前記認証器から署名付きのブラウザの情報と署名付きのアプリの情報とを取得し、取得した情報を前記認証サーバに送信し、
   前記制御部は、前記認証サーバによる前記署名付きのブラウザの情報と前記署名付きのアプリの情報とを用いた認証結果に基づいて、前記ブラウザと前記認証器の接続可否を制御する、
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記制御部は、前記認証サーバの認証結果が、署名が付された前記ブラウザの情報が、前記認証器への接続が許可されているブラウザのリストに載っており、署名が付された前記ブラウザの情報と署名が付された前記アプリの情報とが一致していることを示す場合に、前記ブラウザと前記認証器の接続を許可する制御を実行する、ことを特徴とする請求項２に記載の情報処理装置。
4. 前記認証器を前記ブリッジインタフェースと共に内蔵することを特徴とする請求項１～３のいずれか一項に記載の情報処理装置。
5. ブラウザがブリッジインタフェースを経由して認証器に接続するときに、前記ブラウザの情報を取得して、取得した前記ブラウザの情報から一意の識別情報を生成して前記ブラウザに送信し、生成した前記一意の識別情報と前記ブラウザの情報とを関連付けて記憶部において管理し、
   前記ブラウザから前記一意の識別情報を取得し、前記記憶部を参照して、取得した前記一意の識別情報に対応する前記ブラウザの情報を取得し、
   取得した前記ブラウザの情報を前記認証器に送信して、前記ブラウザの情報に署名を付すように依頼し、
   前記認証器から署名付きのブラウザの情報を取得し、取得した前記署名付きのブラウザの情報を認証サーバに送信し、
   前記認証サーバによる前記署名付きのブラウザの情報を用いた認証結果に基づいて、前記ブラウザと前記認証器の接続可否を制御する、処理をコンピュータが実行することを特徴とする情報処理方法。
6. ブラウザがブリッジインタフェースを経由して認証器に接続するときに、前記ブラウザの情報を取得して、取得した前記ブラウザの情報から一意の識別情報を生成して前記ブラウザに送信し、生成した前記一意の識別情報と前記ブラウザの情報とを関連付けて記憶部において管理し、
   前記ブラウザから前記一意の識別情報を取得し、前記記憶部を参照して、取得した前記一意の識別情報に対応する前記ブラウザの情報を取得し、
   取得した前記ブラウザの情報を前記認証器に送信して、前記ブラウザの情報に署名を付すように依頼し、
   前記認証器から署名付きのブラウザの情報を取得し、取得した前記署名付きのブラウザの情報を認証サーバに送信し、
   前記認証サーバによる前記署名付きのブラウザの情報を用いた認証結果に基づいて、前記ブラウザと前記認証器の接続可否を制御する、処理をコンピュータに実行させるための情報処理プログラム。
7. ブラウザが認証器に接続するときに、前記ブラウザから取得した情報を用いて、一意の識別情報を生成する生成部と、
   接続を許可するブラウザの識別情報を格納する第１リストを参照して、前記生成部が生成した前記識別情報が前記第１リストに格納されているかを検証し、検証結果を前記識別情報と紐づけて記憶部に記憶するとともに、検証完了通知を前記ブラウザに送信する検証部と、
   ブラウザから取得した情報を用いて前記認証器が生成した一意の識別情報を受信して、該識別情報に紐づく検証結果を前記記憶部から取得する取得部と、
   前記取得部の取得結果に基づいて前記ブラウザとの接続可否を制御する前記認証器に対して、前記取得結果を送信する送信部と、
   を備える情報処理装置。
8. 前記検証部は、前記情報処理装置の表示部において最前面に表示されているアプリの情報を取得し、取得したアプリ情報と、前記ブラウザから取得した情報との一致検証を行い、該一致検証の結果も前記識別情報と紐づけて前記記憶部に記憶する、ことを特徴とする請求項７に記載の情報処理装置。
9. 前記検証部は、前記ブラウザが接続する情報提供装置の情報を取得し、前記ブラウザが接続可能な情報提供装置の情報を格納する第２リストを参照して、取得した前記情報提供装置の情報が前記第２リストに格納されているかを検証し、該検証結果も前記識別情報と紐づけて前記記憶部に記憶する、ことを特徴とする請求項７又は８に記載の情報処理装置。
10. 前記一意の識別情報は、ＦＩＤＯ（Fast IDentity Online）認証において利用されるclientDataHashであることを特徴とする請求項７～９のいずれか一項に記載の情報処理装置。
11. ブラウザが認証器に接続するときに、前記ブラウザから取得した情報を用いて、一意の識別情報を生成し、
    接続を許可するブラウザの識別情報を格納する第１リストを参照して、前記生成する処理により生成した前記識別情報が前記第１リストに格納されているかを検証し、検証結果を前記識別情報と紐づけて記憶部に記憶するとともに、検証完了通知を前記ブラウザに送信し、
    ブラウザから取得した情報を用いて前記認証器が生成した一意の識別情報を受信して、該識別情報に紐づく検証結果を前記記憶部から取得し、
    前記取得する処理の取得結果に基づいて前記ブラウザとの接続可否を制御する前記認証器に対して、前記取得結果を送信する、
    処理をコンピュータが実行することを特徴とする情報処理方法。
12. ブラウザが認証器に接続するときに、前記ブラウザから取得した情報を用いて、一意の識別情報を生成し、
    接続を許可するブラウザの識別情報を格納する第１リストを参照して、前記生成する処理により生成した前記識別情報が前記第１リストに格納されているかを検証し、検証結果を前記識別情報と紐づけて記憶部に記憶するとともに、検証完了通知を前記ブラウザに送信し、
    ブラウザから取得した情報を用いて前記認証器が生成した一意の識別情報を受信して、該識別情報に紐づく検証結果を前記記憶部から取得し、
    前記取得する処理の取得結果に基づいて前記ブラウザとの接続可否を制御する前記認証器に対して、前記取得結果を送信する、
    処理をコンピュータに実行させるための情報処理プログラム。

Images