(57)【要約】【課題】不正なＡＰＩ呼び出しを検出できる情報処理装置等を提供する。【解決手段】情報処理装置は、実行部と測定部と署名部とを有する。実行部は、サービスを提供する提供サーバから、サービスをユーザに提供するアプリを取得してブラウザ上で実行すると共にアプリの取得元を検証する。実行部は、ユーザを認証する認証サーバに対してアプリが送信するユーザの認証要求に応じたデータを認証サーバから受信してデータへの署名要求を実行する。測定部は、署名要求を実行する際に、署名要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定する。署名部は、データとアプリの取得元と測定結果とに基づいて、秘密鍵または公開鍵を用いて署名データを生成する。また、実行部は、生成された署名データを認証サーバに送信し、提供サーバが登録済みの測定結果と一致する照合結果を認証サーバから受信した場合に、サービスをユーザに提供する。【選択図】図１
2019129385.tif 000002
【特許請求の範囲】
【請求項１】
サービスを提供する提供サーバから、該サービスをユーザに提供するアプリを取得してブラウザ上で実行するとともに前記アプリの取得元を検証し、前記ユーザを認証する認証サーバに対して前記アプリが送信する前記ユーザの認証要求に応じたデータを前記認証サーバから受信し、受信した前記データへの署名要求を実行する実行部と、
前記署名要求を実行する際に、前記署名要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定する測定部と、
前記データと、検証された前記アプリの取得元と、測定された前記親子関係を示す測定結果とに基づいて、秘密鍵または公開鍵を用いて署名データを生成する署名部と、を有し、
前記実行部は、生成された前記署名データを前記認証サーバに送信し、前記提供サーバが登録済みの測定結果と一致する照合結果を前記認証サーバから受信した場合に、前記サービスを前記ユーザに提供する、
ことを特徴とする情報処理装置。
【請求項２】
前記測定部は、前記アプリの取得元を検証出来ない前記ブラウザ上で前記アプリが実行されている場合、該ブラウザに表示されているオブジェクトの取得元が、前記アプリが申告する取得元と一致する該オブジェクトの情報を前記親子関係に含める、
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記署名部は、前記署名要求時に取得した前記ユーザの生体情報と、登録済みの前記ユーザの生体情報とを照合し、照合結果が一致する場合に前記署名データを生成する、
ことを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
サービスを提供する提供サーバから、該サービスをユーザに提供するアプリを取得してブラウザ上で実行するとともに前記アプリの取得元を検証する実行部と、
前記アプリを実行する際に、前記アプリからの認証要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定する測定部と、
測定された前記親子関係を示す測定結果と、登録済みの前記親子関係を示す測定結果とを照合し、照合結果が一致する場合に、前記認証要求を受け付ける認証部と、
を有することを特徴とする情報処理装置。
【請求項５】
サービスを提供する提供サーバから該サービスをユーザに提供するアプリを取得してブラウザ上で実行する端末装置から、前記ユーザの認証要求を受信すると、該ユーザの認証要求に応じたデータを前記端末装置に送信する送信部と、
前記端末装置において前記アプリを実行して前記ユーザの登録を行う場合に前記アプリからの認証要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定した測定結果を、登録済み測定結果として記憶する記憶部を参照して、前記端末装置から受信した署名データに含まれる前記測定結果と、前記記憶部に記憶された前記登録済み測定結果とを照合し、照合結果が一致する場合に、前記提供サーバに前記サービスの提供を許可する許可部と、
を有することを特徴とする認証サーバ。
【請求項６】
サービスを提供する提供サーバから、該サービスをユーザに提供するアプリを取得してブラウザ上で実行するとともに前記アプリの取得元を検証し、前記ユーザを認証する認証サーバに対して前記アプリが送信する前記ユーザの認証要求に応じたデータを前記認証サーバから受信し、受信した前記データへの署名要求を実行し、
前記署名要求を実行する際に、前記署名要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定し、
前記データと、検証した前記アプリの取得元と、測定した前記親子関係を示す測定結果とに基づいて、秘密鍵または公開鍵を用いて署名データを生成し、
生成した前記署名データを前記認証サーバに送信し、前記提供サーバが登録済みの測定結果と一致する照合結果を前記認証サーバから受信した場合に、前記サービスを前記ユーザに提供する、
処理をコンピュータが実行することを特徴とする認証制御方法。
【請求項７】
サービスを提供する提供サーバから、該サービスをユーザに提供するアプリを取得してブラウザ上で実行するとともに前記アプリの取得元を検証し、
前記アプリを実行する際に、前記アプリからの認証要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定し、
測定した前記親子関係を示す測定結果と、登録済みの前記親子関係を示す測定結果とを照合し、照合結果が一致する場合に、前記認証要求を受け付ける、
処理をコンピュータが実行することを特徴とする認証制御方法。
【請求項８】
サービスを提供する提供サーバから該サービスをユーザに提供するアプリを取得してブラウザ上で実行する端末装置から、前記ユーザの認証要求を受信すると、該ユーザの認証要求に応じたデータを前記端末装置に送信し、
前記端末装置において前記アプリを実行して前記ユーザの登録を行う場合に前記アプリからの認証要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定した測定結果を、登録済み測定結果として記憶する記憶部を参照して、前記端末装置から受信した署名データに含まれる前記測定結果と、前記記憶部に記憶された前記登録済み測定結果とを照合し、照合結果が一致する場合に、前記提供サーバに前記サービスの提供を許可する、
処理をコンピュータが実行することを特徴とする認証制御方法。
【請求項９】
サービスを提供する提供サーバから、該サービスをユーザに提供するアプリを取得してブラウザ上で実行するとともに前記アプリの取得元を検証し、前記ユーザを認証する認証サーバに対して前記アプリが送信する前記ユーザの認証要求に応じたデータを前記認証サーバから受信し、受信した前記データへの署名要求を実行し、
前記署名要求を実行する際に、前記署名要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定し、
前記データと、検証した前記アプリの取得元と、測定した前記親子関係を示す測定結果とに基づいて、秘密鍵または公開鍵を用いて署名データを生成し、
生成した前記署名データを前記認証サーバに送信し、前記提供サーバが登録済みの測定結果と一致する照合結果を前記認証サーバから受信した場合に、前記サービスを前記ユーザに提供する、
処理をコンピュータに実行させることを特徴とする認証制御プログラム。
【請求項１０】
サービスを提供する提供サーバから、該サービスをユーザに提供するアプリを取得してブラウザ上で実行するとともに前記アプリの取得元を検証し、
前記アプリを実行する際に、前記アプリからの認証要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定し、
測定した前記親子関係を示す測定結果と、登録済みの前記親子関係を示す測定結果とを照合し、照合結果が一致する場合に、前記認証要求を受け付ける、
処理をコンピュータに実行させることを特徴とする認証制御プログラム。
【請求項１１】
サービスを提供する提供サーバから該サービスをユーザに提供するアプリを取得してブラウザ上で実行する端末装置から、前記ユーザの認証要求を受信すると、該ユーザの認証要求に応じたデータを前記端末装置に送信し、
前記端末装置において前記アプリを実行して前記ユーザの登録を行う場合に前記アプリからの認証要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定した測定結果を、登録済み測定結果として記憶する記憶部を参照して、前記端末装置から受信した署名データに含まれる前記測定結果と、前記記憶部に記憶された前記登録済み測定結果とを照合し、照合結果が一致する場合に、前記提供サーバに前記サービスの提供を許可する、
処理をコンピュータに実行させることを特徴とする認証制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、認証サーバ、認証制御方法および認証制御プログラムに関する。
【背景技術】
【０００２】
従来、生体認証サービスでは、例えば、サーバに生体情報を登録し、銀行のＡＴＭ（Automatic  Teller  Machine）に設置された生体認証装置で取得した生体情報をサーバに送信して照合することが行われている。この場合、生体情報の管理やサイバー攻撃からの防御等の運用コストが大きく、サービス提供者の負担となっている。これに対し、近年、端末側で生体情報を照合して照合結果をサーバ側に送信することが提案されている。この様な仕様としては、例えばＦＩＤＯ（Fast  IDentity  Online）が挙げられる。
【０００３】
端末で生体情報を照合する場合、ＦＩＤＯのＡＰＩ（Application  Programming  Interface）についてセキュア実装が不可欠となる。もし、端末上の任意のアプリに自由にＡＰＩの呼び出しを許可すると、ユーザの成り済ましを行うような悪意あるアプリに対してもＦＩＤＯのＡＰＩの利用を許してしまい、ユーザに対してアカウントの乗っ取り等の被害が発生することになる。このため、ＡＰＩにアクセスできるアプリを限定することで、悪意あるアプリから保護することになる。この様な保護策としては、例えば、大きく分けて、以下の手法１〜３に示すような方法がある。手法１は、ＡＰＩをＳＤＫ（Software  Development  Kit）として提供しアプリ内に内蔵する手法である。手法２は、パスワードを持つアプリだけにＡＰＩアクセスを許可する手法である。手法３は、特定のコード署名を持つアプリだけにＡＰＩアクセスを許可する手法である。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１６−１３９９１０号公報
【非特許文献】
【０００５】
【非特許文献１】“FIDO  Alliance”、［Online］，［平成３０年１月１１日検索］、インターネット＜https://fidoalliance.org/specifications/overview/>
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、近年では、アプリが端末のＯＳ（Operating  System）上で動作するネイティブアプリから、ブラウザ上で動作するＷｅｂアプリにシフトしてきており、上述の保護策が使えない場合が増加している。Ｗｅｂアプリに上述の手法１〜３を適用しようとすると、例えば、手法１では、Ｗｅｂアプリはサーバからダウンロードされる一方、ＦＩＤＯのＡＰＩは端末に実装されるので、ＷｅｂアプリにＦＩＤＯのＡＰＩを内蔵することが困難である。手法２では、Ｗｅｂアプリのコードが解析されやすく、パスワードが丸見えになる危険性がある。手法３では、ブラウザがＷｅｂアプリに代わって代理アクセスするので、ＡＰＩ側からＷｅｂアプリのチェックをすることが難しい。従って、Ｗｅｂアプリでは、不正なＡＰＩ呼び出しを検出することが困難である。
【０００７】
一つの側面では、不正なＡＰＩ呼び出しを検出できる情報処理装置、認証サーバ、認証制御方法および認証制御プログラムを提供することにある。
【課題を解決するための手段】
【０００８】
一つの態様では、情報処理装置は、実行部と、測定部と、署名部とを有する。実行部は、サービスを提供する提供サーバから、該サービスをユーザに提供するアプリを取得してブラウザ上で実行するとともに前記アプリの取得元を検証する。また、実行部は、前記ユーザを認証する認証サーバに対して前記アプリが送信する前記ユーザの認証要求に応じたデータを前記認証サーバから受信し、受信した前記データへの署名要求を実行する。測定部は、前記署名要求を実行する際に、前記署名要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定する。署名部は、前記データと、検証された前記アプリの取得元と、測定された前記親子関係を示す測定結果とに基づいて、秘密鍵または公開鍵を用いて署名データを生成する。また、実行部は、生成された前記署名データを前記認証サーバに送信し、前記提供サーバが登録済みの測定結果と一致する照合結果を前記認証サーバから受信した場合に、前記サービスを前記ユーザに提供する。
【発明の効果】
【０００９】
不正なＡＰＩ呼び出しを検出できる。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施例の認証システムの構成の一例を示す図である。
【図２】図２は、ＦＩＤＯＡＰＩの実装の一例を示す図である。
【図３】図３は、成り済まし攻撃の一例を示す図である。
【図４】図４は、手法１〜３の一例を示す図である。
【図５】図５は、ネイティブアプリとＷｅｂアプリの一例を示す図である。
【図６】図６は、Ｗｅｂアプリに手法２，３を適用した場合の一例を示す図である。
【図７】図７は、ブラウザがＷｅｂアプリをチェックする場合の一例を示す図である。
【図８】図８は、情報の改変の一例を示す図である。
【図９】図９は、古いブラウザでＷｅｂアプリを実行する場合の一例を示す図である。
【図１０】図１０は、実施例の端末装置の構成の一例を示すブロック図である。
【図１１】図１１は、測定結果記憶部の一例を示す図である。
【図１２】図１２は、照合ＤＢの一例を示す図である。
【図１３】図１３は、署名データの構成の一例を示す図である。
【図１４】図１４は、署名データの構成の他の一例を示す図である。
【図１５】図１５は、提供サーバ側でブロックする場合の一例を示す図である。
【図１６】図１６は、測定結果の照合の一例を示す図である。
【図１７】図１７は、端末装置側でブロックする場合の一例を示す図である。
【図１８】図１８は、オブジェクトの取得元に基づいてブロックする場合の一例を示す図である。
【図１９】図１９は、実施例の登録処理の一例を示すシーケンス図である。
【図２０】図２０は、実施例の測定処理の一例を示すフローチャートである。
【図２１】図２１は、実施例の認証処理の一例を示すシーケンス図である。
【図２２】図２２は、認証制御プログラムを実行するコンピュータの一例を示す図である。
【発明を実施するための形態】
【００１１】
以下、図面に基づいて、本願の開示する情報処理装置、認証サーバ、認証制御方法および認証制御プログラムの実施例を詳細に説明する。なお、本実施例により、開示技術が限定されるものではない。また、以下の実施例は、矛盾しない範囲で適宜組みあわせてもよい。
【実施例】
【００１２】
図１は、実施例の認証システムの構成の一例を示す図である。図１に示す認証システム１０は、端末装置１００と、提供サーバ２００と、認証サーバ３００とを有する。なお、認証システム１０では、端末装置１００、提供サーバ２００および認証サーバ３００の数は限定されず、任意の数の端末装置１００、提供サーバ２００および認証サーバ３００を有するようにしてもよい。端末装置１００と提供サーバ２００との間、端末装置１００と認証サーバ３００との間、および、提供サーバ２００と認証サーバ３００との間は、ネットワークＮを介して、相互に通信可能に接続される。かかるネットワークＮには、有線または無線を問わず、インターネットを始め、ＬＡＮ（Local  Area  Network）やＶＰＮ（Virtual  Private  Network）などの任意の種類の通信網を採用できる。また、ネットワークＮを介する通信は、例えば、ＴＬＳ（Transport  Layer  Security）／ＳＳＬ（Secure  Sockets  Layer）等によって暗号化されるようにしてもよい。
【００１３】
認証システム１０は、端末装置１００において提供サーバ２００が提供するサービスを利用する際に、端末装置１００で生体情報を照合して照合結果を認証サーバ３００に送信することで端末装置１００のユーザ認証を行うシステムの一例である。端末装置１００は、提供サーバ２００が提供するサービスをユーザが利用するための情報処理装置である。端末装置１００は、例えば、スマートフォン等の移動体通信端末等や可搬型のパーソナルコンピュータ等の各種端末を用いることができる。また、端末装置１００は、例えば、据置型のパーソナルコンピュータ等の端末を用いてもよい。
【００１４】
端末装置１００では、例えば、ブラウザ２０上で提供サーバ２００から取得したアプリ２１が実行される。アプリ２１は、端末装置１００のＡＰＩを呼び出す中継プログラム２２を介して、セキュリティで保護された実行空間２３内の署名エンジン２４に対してユーザ認証のための署名要求を行う。署名エンジン２４内では、署名要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定する測定機構２５によって、当該親子関係が測定される。署名エンジン２４は、秘密鍵２６を用いて測定機構２５の測定結果を含む署名データを生成し、中継プログラム２２を介してアプリ２１に出力する。アプリ２１は、署名データを認証サーバ３００に送信することで署名データに含まれる測定結果の照合を依頼する。
【００１５】
提供サーバ２００は、各種サービスを提供するサーバである。提供サーバ２００は、端末装置１００からサービス要求を受信すると、Ｗｅｂアプリを端末装置１００に送信し、ユーザ認証および測定結果の照合の後に各種サービスをユーザに提供する。
【００１６】
認証サーバ３００は、端末装置１００から受信する認証要求を処理するサーバである。また、認証サーバ３００は、端末装置１００から受信するユーザの署名データを登録したり、認証時の署名データを登録時の署名データと照合したりするサーバである。署名データには、例えば、上述の測定結果等が含まれる。認証サーバ３００は、例えば、認証部３０１と照合データベース（以下、ＤＢともいう。）３０２とを有する。認証部３０１は、端末装置１００から受信した署名データの検証や、照合ＤＢ３０２に記憶された測定結果と署名データ内の測定結果との照合を行う。認証サーバ３００は、照合によってユーザの確認が取れた場合には、提供サーバ２００に対して、その旨の確認情報を送信する。つまり、認証部３０１は、送信部および許可部の一例である。
【００１７】
すなわち、端末装置１００は、サービスを提供する提供サーバ２００から、サービスをユーザに提供するアプリを取得してブラウザ上で実行するとともにアプリの取得元を検証する。端末装置１００は、ユーザを認証する認証サーバ３００に対してアプリが送信するユーザの認証要求に応じたチャレンジ（データ）を認証サーバ３００から受信し、受信したチャレンジへの署名要求を実行する。端末装置１００は、署名要求を実行する際に、署名要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定する。端末装置１００は、チャレンジと、検証されたアプリの取得元と、測定された親子関係を示す測定結果とに基づいて、秘密鍵または公開鍵を用いて署名データを生成する。端末装置１００は、生成された署名データを認証サーバ３００に送信し、提供サーバ２００が登録済みの測定結果と一致する照合結果を認証サーバ３００から受信した場合に、サービスをユーザに提供する。これにより、端末装置１００は、不正なＡＰＩ呼び出しを検出できる。
【００１８】
また、認証サーバ３００は、サービスを提供する提供サーバ２００からサービスをユーザに提供するアプリを取得してブラウザ上で実行する端末装置１００から、ユーザの認証要求を受信すると、ユーザの認証要求に応じたデータを端末装置１００に送信する。また、認証サーバ３００は、端末装置１００においてアプリを実行してユーザの登録を行う場合にアプリからの認証要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定した測定結果を、登録済み測定結果として記憶する記憶部を有する。また、認証サーバ３００は、記憶部を参照して、端末装置１００から受信した署名データに含まれる測定結果と、記憶部に記憶された登録済み測定結果とを照合し、照合結果が一致する場合に、提供サーバ２００にサービスの提供を許可する。これにより、認証サーバ３００は、不正なＡＰＩ呼び出しを検出できる。
【００１９】
ここで、図２から図９を用いて、端末側で生体認証を行う場合の課題の詳細について説明する。図２は、ＦＩＤＯＡＰＩの実装の一例を示す図である。図２に示すように、例えば、ＦＩＤＯのＡＰＩ（以下、ＦＩＤＯＡＰＩともいう。）は、端末のアプリがサービスにログインする場合に、Ｌさんの生体情報を照合し、Ｌさんの確認結果をアプリに返す。サービス側では、Ｌさんの確認結果が真である場合に、Ｌさん向けのサービスを端末に提供する。この場合、ＦＩＤＯＡＰＩは、セキュア実装が不可欠となる。例えば、セキュア実装を行わない場合、つまり、端末上の任意のアプリに自由にＡＰＩの呼び出しを許可した場合、悪意あるアプリによって攻撃を受けてしまう。この様な攻撃の一例を図３に示す。
【００２０】
図３は、成り済まし攻撃の一例を示す図である。図３に示すように、端末に悪意あるアプリがインストールされてしまった場合、悪意あるアプリは、ユーザを悪意あるサービスに誘導する（ステップＳ１）。悪意あるサービスは、悪意あるアプリを介して、ユーザであるＬさんにサービスＡへのログインと勘違いさせて生体認証を行い（ステップＳ２）、悪意あるサービスに認証情報を送信する（ステップＳ３）。悪意あるサービスは、詐取した認証情報を用いてＬさんに成り済ましてサービスＡにログインし、Ｌさん向けサービスを利用する（ステップＳ４）。従って、Ｌさんは、勝手にサービスＡを利用されてしまい、被害が発生することになる。このため、図４に示す手法１〜３の様な保護策を用いて、ＦＩＤＯＡＰＩにアクセスできるアプリを限定することで、悪意あるアプリから保護する。
【００２１】
図４は、手法１〜３の一例を示す図である。なお、図４に示す手法１〜３は、上述の手法１〜３に対応する。図４に示すように、手法１は、ＡＰＩをＳＤＫとして提供しアプリ内に内蔵する手法である。手法２は、パスワードを持つアプリだけにＡＰＩアクセスを許可する手法である。手法３は、特定のコード署名を持つアプリだけにＡＰＩアクセスを許可する手法である。一方、近年では、アプリが端末のＯＳ上で動作するネイティブアプリから、ブラウザ上で動作するＷｅｂアプリにシフトしてきており、上述の手法１〜３が使えない場合が増加している。
【００２２】
図５は、ネイティブアプリとＷｅｂアプリの一例を示す図である。図５に示すように、ネイティブアプリは、端末にユーザが事前にインストールしたアプリを実行することで、サービスを提供する。これに対し、Ｗｅｂアプリは、サービス実行時にサービスを提供するサーバからアプリをダウンロードしてブラウザ上で実行することで、サービスを提供する。このため、手法１では、Ｗｅｂアプリはサーバからダウンロードされる一方、ＦＩＤＯＡＰＩは端末に実装されるので、ＷｅｂアプリにＦＩＤＯＡＰＩを内蔵することが困難である。
【００２３】
図６は、Ｗｅｂアプリに手法２，３を適用した場合の一例を示す図である。図６に示すように、手法２では、Ｗｅｂアプリのコードが解析されやすく、パスワードが丸見えになる危険性がある。手法３では、ブラウザがＷｅｂアプリに代わって代理アクセスするので、ＦＩＤＯＡＰＩ側からＷｅｂアプリのチェックをすることが困難である。このため、Ｗｅｂアプリでは、上述の手法１〜３の保護策を用いることが出来ず、不正なＡＰＩ呼び出しを検出することが困難である。これに対し、ブラウザにアプリがアクセスするＡＰＩをチェックする機構を組み込むことがＷ３Ｃ（World  Wide  Web  Consortium）で検討されている。なお、以下の説明では、ネイティブアプリとＷｅｂアプリとを区別する場合を除いて、Ｗｅｂアプリのことを単にアプリともいう。
【００２４】
図７は、ブラウザがＷｅｂアプリをチェックする場合の一例を示す図である。図７に示すように、ブラウザに組み込まれたＡＰＩアクセスチェック機構は、アプリがサービスＡのトークン（認証情報）を要求すると、アプリをチェックしてサービスＡに対応するアプリからのアクセスであることをＦＩＤＯＡＰＩに出力する。このため、例えば、悪意あるアプリが悪意あるサービスＢに対応するアプリであった場合、ＡＰＩアクセスチェック機構は、アプリがサービスＡのトークンを要求すると、アプリをチェックしてサービスＢに対応するアプリからのアクセスであることをＦＩＤＯＡＰＩに出力する。すると、ＦＩＤＯＡＰＩは、アプリが要求するサービスＡのトークンと、チェック結果のサービスＢとが異なるため、ＡＰＩの使用をブロックする。従って、端末は、悪意あるサービスＢを提供するサイトに接続したとしても、ＦＩＤＯＡＰＩの不正利用を防止することができる。
【００２５】
ところが、図７に示す様なＡＰＩアクセスチェック機構を組み込んだブラウザを用いても、例えば、Ｗｉｎｄｏｗｓ（登録商標）の様に、ＯＳ側でコード署名がないアプリの実行が許されていれば、チェックを回避することができる場合がある。チェックの回避方法としては、例えば、ＡＰＩアクセスチェック機構から出力される情報自体が改変されてしまうことが考えられる。
【００２６】
図８は、情報の改変の一例を示す図である。図８に示すように、ブラウザとＦＩＤＯＡＰＩとの間に悪意あるＤＬＬ（Dynamic  Link  Library）が存在する場合がある。この場合、ＡＰＩアクセスチェック機構がサービスＢからのアクセスであると出力しても、悪意あるＤＬＬがサービスＡからのアクセスであると改変することが可能である。従って、この端末のユーザは、成り済ましの被害を受けることになる。
【００２７】
図９は、古いブラウザでＷｅｂアプリを実行する場合の一例を示す図である。図９に示すように、Ｗｉｎｄｏｗｓでは、レガシーシステムとの互換性の観点から、古いブラウザ、例えばＩＥ（Internet  Explorer（登録商標））等が利用され続けている。このため、この様な古いブラウザをアプリが騙してＦＩＤＯＡＰＩにアクセスするリスクも存在する。この場合、古いブラウザは、悪意あるアプリに騙されてサービスＡからのアクセスであるとＦＩＤＯＡＰＩに出力する。従って、この端末のユーザは、悪意あるＤＬＬ等によって改変が行われなくても、成り済ましの被害を受けることになる。
【００２８】
次に、端末装置１００の構成について説明する。図１０は、実施例の端末装置の構成の一例を示すブロック図である。図１０に示すように、端末装置１００は、通信部１１０と、表示操作部１１１と、生体認証部１１２と、記憶部１２０と、制御部１３０とを有する。なお、端末装置１００は、図１０に示す機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや音声出力デバイス等の機能部を有することとしてもかまわない。
【００２９】
通信部１１０は、例えば、ＬＴＥ（Long  Term  Evolution）等の移動体通信および無線ＬＡＮ等の通信モジュールやＮＩＣ（Network  Interface  Card）等によって実現される。通信部１１０は、ネットワークＮを介して提供サーバ２００および認証サーバ３００と有線または無線で接続され、提供サーバ２００および認証サーバ３００との間で情報の通信を司る通信インタフェースである。通信部１１０は、制御部１３０から入力されたサービス要求およびサービスの提供に関する各種情報を提供サーバ２００に送信する。また、通信部１１０は、制御部１３０から入力されたレガシー認証情報、登録要求および認証要求を認証サーバ３００に送信する。また、通信部１１０は、提供サーバ２００から受信したアプリ、レガシー認証情報およびサービスの提供に関する各種情報を制御部１３０に出力する。また、通信部１１０は、認証サーバ３００から受信したチャレンジおよび保存成功情報を制御部１３０に出力する。
【００３０】
表示操作部１１１は、各種情報を表示するための表示デバイス、および、ユーザから各種操作を受け付ける入力デバイスである。例えば、表示操作部１１１は、表示デバイスとして液晶ディスプレイ等によって実現される。また、例えば、表示操作部１１１は、入力デバイスとして、タッチパネル等によって実現される。つまり、表示操作部１１１は、表示デバイスと入力デバイスとが一体化される。表示操作部１１１は、ユーザによって入力された操作を操作情報として制御部１３０に出力する。
【００３１】
生体認証部１１２は、指紋、虹彩、静脈等の生体情報を取得するセンサである。生体認証部１１２は、例えば指紋センサである場合、取得した指紋の情報を生体情報として制御部１３０に出力する。
【００３２】
記憶部１２０は、例えば、ＲＡＭ（Random  Access  Memory）、フラッシュメモリ（Flash  Memory）等の半導体メモリ素子、ハードディスクや光ディスク等の記憶装置によって実現される。記憶部１２０は、生体情報記憶部１２１と、秘密鍵記憶部１２２と、測定結果記憶部１２３とを有する。また、記憶部１２０は、制御部１３０での処理に用いる情報を記憶する。
【００３３】
生体情報記憶部１２１は、端末装置１００のユーザによって予め登録される生体情報を記憶する。生体情報記憶部１２１には、例えば、指紋を登録するアプリによって生体認証部１１２で取得された指紋の情報が、ユーザの生体情報として記憶される。
【００３４】
秘密鍵記憶部１２２は、例えば、サービスへのユーザ登録時において、生体情報に基づいて検証されたユーザに対応するようにサービス毎に生成された秘密鍵と公開鍵とのペアのうち、秘密鍵を記憶する。なお、秘密鍵記憶部１２２は、公開鍵を秘密鍵と合わせて記憶するようにしてもよい。また、生成された秘密鍵は、署名データの生成に用いる。なお、秘密鍵記憶部１２２は、端末装置１００の製造時に、ＦＩＤＯＡＰＩを構成するソフトウェア部品・ハードウェア部品が正常に動作しているときだけ機能する秘密鍵を予め記憶するようにしてもよい。また、秘密鍵記憶部１２２は、図１に示す秘密鍵２６に対応する。
【００３５】
測定結果記憶部１２３は、署名要求に対応するＡＰＩを呼び出したプログラムの親子関係の測定結果を、サービス名、ユーザ名および公開鍵等と対応付けて記憶する。図１１は、測定結果記憶部の一例を示す図である。図１１に示すように、測定結果記憶部１２３は、「サービス名」、「ユーザ名」、「公開鍵」、「測定１」、「測定２」といった項目を有する。
【００３６】
「サービス名」は、例えば、提供サーバ２００から提供されるサービスのＵＲＬ（Uniform  Resource  Locator）を示す情報である。「サービス名」は、ＵＲＬの他にも、提供サーバ２００が提供するサービスを特定できる情報であれば、他の情報であっても構わない。「ユーザ名」は、端末装置１００のユーザであって、提供サーバ２００から提供されるサービスに登録したユーザ名を示す情報である。「公開鍵」は、提供サーバ２００から提供されるサービスへのユーザ登録時に生成された公開鍵を示す情報である。「測定１」は、署名要求に対応するＡＰＩを呼び出したプログラムの親子関係の測定結果を示す情報である。なお、ｃｍｄ．ｅｘｅは、ＡＰＩアクセスチェック機構の一例である。「測定２」は、アプリの取得元を検証出来ないブラウザ上でアプリが実行された場合における、ブラウザに表示されているオブジェクトの情報である。オブジェクトの情報は、例えば、アプリのサイズおよびハッシュ値に基づいて算出したアプリＩＤ（Identifier）を用いることができる。
【００３７】
ここで、認証サーバ３００側において、測定結果記憶部１２３と同様の測定結果を記憶する照合ＤＢ３０２について説明する。照合ＤＢ３０２は、端末装置１００で測定された、署名要求に対応するＡＰＩを呼び出したプログラムの親子関係の測定結果を、サービス名、ユーザ名および公開鍵等と対応付けて記憶する。図１２は、照合ＤＢの一例を示す図である。図１２に示すように、照合ＤＢ３０２は、「サービス名」、「ユーザ名」、「公開鍵」、「登録時の署名検証鍵」、「測定１」、「測定２」といった項目を有する。
【００３８】
照合ＤＢ３０２の「サービス名」、「ユーザ名」、「公開鍵」、「測定１」の各項目は、測定結果記憶部１２３と同様の情報を記憶するので、その説明を省略する。「登録時の署名検証鍵」は、端末装置１００の製造時にベンダが提供するプリセットされたＦＩＤＯＡＰＩが正常に動作しているときだけに機能する秘密鍵とペアとなる公開鍵を示す情報である。なお、「登録時の署名検証鍵」は、オプション扱いとし、照合ＤＢ３０２に設けなくてもよい。「測定２」は、測定結果記憶部１２３と同様の情報を記憶するが、提供サーバ２００から取得したオブジェクトの情報であるアプリＩＤを用いることができる。
【００３９】
図１０の説明に戻って、制御部１３０は、例えば、ＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）等によって、内部の記憶装置に記憶されているプログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）等の集積回路により実現されるようにしてもよい。
【００４０】
制御部１３０は、実行部１３１と、中継部１３５と、測定部１３６と、署名部１３７とを有し、以下に説明する情報処理の機能や作用を実現または実行する。また、実行部１３１では、ブラウザ１３２が実行され、ブラウザ１３２上でアプリ１３３が実行される。さらに、ブラウザ１３２には、上述のＡＰＩアクセスチェック機構に対応する検証部１３４が組み込まれている。また、制御部１３０の内部構成は、図１０に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。なお、ブラウザ１３２およびアプリ１３３は、図１に示すブラウザ２０およびアプリ２１に対応する。また、検証部１３４および中継部１３５は、図１に示す中継プログラム２２に対応する。さらに、測定部１３６および署名部１３７は、図１に示す測定機構２５および署名エンジン２４に対応する。
【００４１】
ブラウザ１３２は、例えばユーザの操作に基づくサービス要求を、通信部１１０およびネットワークＮを介して、提供サーバ２００に送信する。ブラウザ１３２は、サービス要求に対応するアプリを、ネットワークＮおよび通信部１１０を介して、提供サーバ２００から受信して取得する。ブラウザ１３２は、取得したアプリを実行するとともに、検証部１３４に対してアプリの取得元の検証を指示する。
【００４２】
アプリ１３３は、ブラウザ１３２で取得して実行されたアプリである。まず、アプリ１３３におけるユーザ登録時について説明する。アプリ１３３は、ユーザに対してレガシー認証の操作を求める。なお、レガシー認証は、例えば、メールアドレスおよびパスワードの入力による認証や、ＳＮＳ（Social  Networking  Service）による認証を用いることができる。アプリ１３３は、ユーザの操作に基づいて、提供サーバ２００との間でレガシー認証情報を送受信してレガシー認証を行う。
【００４３】
アプリ１３３は、レガシー認証が完了すると、通信部１１０およびネットワークＮを介して、登録要求を認証サーバ３００に送信する。アプリ１３３は、ネットワークＮおよび通信部１１０を介して、認証サーバ３００から登録要求に対応するチャレンジを受信する。アプリ１３３は、受信したチャレンジへの署名要求を中継部１３５に出力する。つまり、アプリ１３３は、中継部１３５を介してＦＩＤＯＡＰＩを呼び出す。
【００４４】
アプリ１３３は、署名部１３７からユーザ登録用の署名データが入力されると、通信部１１０およびネットワークＮを介して、入力された署名データを認証サーバ３００に送信する。アプリ１３３は、提供サーバ２００が認証サーバ３００から保存成功情報を受信した場合に、提供サーバ２００の指示に基づいて、ユーザにサービスを提供する。
【００４５】
次に、アプリ１３３におけるユーザ認証時について説明する。アプリ１３３は、実行されると、通信部１１０およびネットワークＮを介して、認証要求を認証サーバ３００に送信する。アプリ１３３は、ネットワークＮおよび通信部１１０を介して、認証サーバ３００から認証要求に対応するチャレンジを受信する。アプリ１３３は、受信したチャレンジへの署名要求を中継部１３５に出力する。つまり、アプリ１３３は、中継部１３５を介してＦＩＤＯＡＰＩを呼び出す。
【００４６】
アプリ１３３は、署名部１３７からユーザ認証用の署名データが入力されると、通信部１１０およびネットワークＮを介して、入力された署名データを認証サーバ３００に送信する。アプリ１３３は、提供サーバ２００が認証サーバ３００から確認情報を受信した場合に、提供サーバ２００の指示に基づいて、ユーザにサービスを提供する。
【００４７】
検証部１３４は、ブラウザ１３２からアプリの取得元の検証が指示されると、実行中のアプリ１３３がＦＩＤＯＡＰＩを呼び出す際に、アプリ１３３の取得元を検証する。検証部１３４は、例えば、サービスＡに対応するアプリ１３３が署名要求を中継部１３５に出力する際に、つまりＦＩＤＯＡＰＩを呼び出す際に、アプリ１３３が対応するサービスＡの情報を取得する。検証部１３４は、取得したサービスＡの情報を検証情報として中継部１３５に出力する。なお、検証部１３４は、ブラウザ１３２が古い場合等、アプリ１３３の取得元を検証出来ない場合には、検証出来ない旨の検証情報を中継部１３５に出力する。また、検証部１３４は、ブラウザ１３２が古い場合には、ブラウザ１３２とは別に設けるようにしてもよい。
【００４８】
中継部１３５は、ブラウザ１３２上で動作するアプリ１３３から、端末装置１００に実装されたＡＰＩを呼び出す機能部である。中継部１３５は、アプリ１３３から署名要求が入力され、検証部１３４から検証情報が入力されると、ＦＩＤＯＡＰＩを呼び出して、署名要求を署名部１３７に出力する。また、中継部１３５は、検証情報を測定部１３６に出力する。
【００４９】
測定部１３６は、中継部１３５から検証情報が入力されると、つまり中継部１３５がＦＩＤＯＡＰＩを呼び出すと、ＦＩＤＯＡＰＩを呼び出したプログラムの親子関係を測定する。測定部１３６は、カレントプログラムの呼び出し元のプログラムＩＤを取得し、プログラムＩＤに対応するプログラム名をＯＳから取得して測定結果記憶部１２３の「測定１」欄に測定結果として記憶する。すなわち、測定部１３６は、測定したプログラムの親子関係を測定結果として測定結果記憶部１２３の「測定１」欄に記憶する。プログラムＩＤは、例えば、アプリ１３３を「１」、ブラウザ１３２を「２」、中継部１３５に対応する中継プログラムを「３」とすることができる。この場合、中継プログラムの親ＩＤは、ブラウザ１３２の「２」となる。ブラウザ１３２の親ＩＤは、アプリ１３３の「１」となる。アプリ１３３の親ＩＤは、例えばＯＳの「０」となる。この場合の測定結果は、｛アプリ→ブラウザ→中継プログラム→ＡＰＩ｝となる。
【００５０】
測定部１３６は、親ＩＤが「０」であるか否かを判定する。測定部１３６は、親ＩＤが「０」でないと判定した場合には、カレントプログラムに親ＩＤを代入し、カレントプログラムの呼び出し元のプログラムＩＤの取得、プログラム名の取得および記憶を繰り返す。測定部１３６は、親ＩＤが「０」であると判定した場合には、ユーザ登録時であるか否か、つまり、登録フェーズであるか否かを判定する。
【００５１】
測定部１３６は、登録フェーズでないと判定した場合には、測定結果に基づいて、ＡＰＩ呼び出しに不正があるか否かを判定する。測定部１３６は、ＡＰＩ呼び出しに不正があると判定した場合には、エラー情報を生成して測定結果に付加する。なお、エラー情報は、例えば、ＡＰＩ呼び出しに不正なプログラムが介在する場合と、ブラウザ１３２が登録時と異なる種類のブラウザである場合とが挙げられる。測定部１３６は、ＡＰＩ呼び出しに不正がないと判定した場合には、測定結果にエラー情報を付加しない。
【００５２】
なお、エラー情報は、認証サーバ３００における測定結果の照合時に用いる。エラー情報は、例えば、ブラウザ１３２が登録時と異なる場合には、ユーザの確認と、異なるブラウザによるＡＰＩ呼び出しの親子関係の妥当性と、アプリの取得元とサービス提供元の一致とが取れればサービスの提供を許可し、不正なプログラムが介在する場合には、サービスの提供を許可しないといった制御に用いることができる。また、測定部１３６は、端末装置１００側で不正なＡＰＩ呼び出しをブロックする場合、測定結果記憶部１２３を参照し、測定された親子関係を示す測定結果と、登録済みの親子関係を示す測定結果とを照合し、照合結果が一致する場合に、認証要求を受け付けるようにしてもよい。つまり、測定部１３６は、認証部の一例である。
【００５３】
測定部１３６は、検証情報に基づいて、アプリ１３３の検証が可能であるか否かを判定する。すなわち、測定部１３６は、中継部１３５から入力された検証情報が、検証出来ない旨の検証情報であるか否かを判定する。測定部１３６は、アプリ１３３の検証が可能であると判定した場合には、測定結果記憶部１２３を参照し、測定結果を署名部１３７に出力する。この場合、測定結果には、測定結果記憶部１２３の「測定１」欄の測定結果が含まれる。
【００５４】
測定部１３６は、アプリ１３３の検証が可能でないと判定した場合には、ブラウザ１３２で表示されているオブジェクトを取得する。測定部１３６は、取得したオブジェクトの送信元、つまりオブジェクトの取得元が、アプリ１３３が申告する取得元と一致するか否かを判定する。測定部１３６は、取得元が一致しないと判定した場合には、全てのオブジェクトの取得元がチェック済みであるか否かを判定する。
【００５５】
測定部１３６は、全てのオブジェクトの取得元がチェック済みでない場合には、残りのオブジェクトの取得元について、アプリ１３３が申告する取得元と一致するか否かの判定を繰り返す。測定部１３６は、全てのオブジェクトの取得元がチェック済みである場合には、アプリ１３３に対して不正なＡＰＩ呼び出しである旨のエラーを返す。
【００５６】
測定部１３６は、取得元が一致すると判定した場合には、当該オブジェクトを測定し、測定結果を測定結果記憶部１２３の「測定２」欄に記憶する。つまり、測定部１３６は、オブジェクトに対応するアプリ１３３のサイズおよびハッシュ値に基づいて算出したアプリＩＤを測定結果として、測定結果記憶部１２３の「測定２」欄に記憶する。また、測定部１３６は、測定結果記憶部１２３を参照し、測定結果を署名部１３７に出力する。この場合、測定結果には、測定結果記憶部１２３の「測定１」および「測定２」欄の測定結果が含まれる。
【００５７】
署名部１３７には、中継部１３５から署名要求が入力され、測定部１３６から測定結果が入力される。署名部１３７は、署名要求に応じて生体認証部１１２から生体情報を入力するようにユーザに促す。署名部１３７は、生体認証部１１２から生体情報が入力されると、生体情報記憶部１２１を参照し、予め登録されたユーザの生体情報と照合する。署名部１３７は、照合結果が真である場合には、測定結果に基づいて、署名データを生成する。署名部１３７は、照合結果が偽である場合には、アプリ１３３に照合結果が偽である旨のエラーを返す。
【００５８】
すなわち、署名部１３７は、ユーザ登録時には、ユーザの秘密鍵および公開鍵のペアを生成し、署名要求に含まれるチャレンジと、測定結果と、生成した公開鍵とを含むデータを秘密鍵で署名した署名データを生成する。また、署名部１３７は、ユーザ登録後のユーザ認証時には、署名要求に含まれるチャレンジと、測定結果とを含むデータを秘密鍵で署名した署名データを生成する。なお、署名部１３７は、登録時においては、生成した秘密鍵による署名に代えて、例えば、端末装置１００の製造時に設定した署名部１３７の秘密鍵で署名して署名データを生成してもよい。署名部１３７は、生成した署名データをアプリ１３３に出力する。
【００５９】
署名部１３７は、ユーザ登録時であるか否か、つまり、登録フェーズであるか否かを判定する。署名部１３７は、登録フェーズでないと判定した場合には、署名に関する処理を終了する。署名部１３７は、登録フェーズであると判定した場合には、認証サーバ３００から送信される保存成功情報の受信を所定時間待機する。署名部１３７は、所定時間内に認証サーバ３００から保存成功情報が返ってきたか否かを判定する。署名部１３７は、保存成功情報が返ってきたと判定した場合には、測定結果を測定結果記憶部１２３に記憶し、署名に関する処理を終了する。署名部１３７は、保存成功情報が返ってきていないと判定した場合には、そのまま署名に関する処理を終了する。
【００６０】
ここで、図１３および図１４を用いて署名データの構成について説明する。図１３は、署名データの構成の一例を示す図である。認証サーバ３００でも構成チェックを行う場合、図１３に示すように、署名部１３７は、署名要求に含まれるチャレンジ５１に対して、当該チャレンジ５１と、測定結果（”ｐａｔｈ”の部分）とを含む署名データ５２を生成する。
【００６１】
図１４は、署名データの構成の他の一例を示す図である。認証サーバ３００が既に正解のプログラム構成ＩＤリストを有する場合、図１４に示すように、署名部１３７は、署名要求に含まれるチャレンジ５３に対して、当該チャレンジ５３と、プログラム構成を一意に表すＩＤとを含む署名データ５４を生成する。なお、正解のプログラム構成ＩＤリストとは、登録された測定結果のリストの一例である。また、プログラム構成を一意に表すＩＤは、例えば、測定結果（図１３の”ｐａｔｈ”の部分に相当）に対してハッシュ関数を用いて算出することができる。
【００６２】
続いて、図１５から図１８を用いて、不正なＡＰＩ呼び出しのブロックのバリエーションを説明する。図１５は、提供サーバ側でブロックする場合の一例を示す図である。図１５の例では、端末装置１００は、ＡＰＩを呼び出したプログラムの親子関係を測定し、測定結果として｛アプリ→ブラウザ名→ＡＰＩアクセスチェック機構→ＤＬＬ→ＦＩＤＯＡＰＩ｝を得る。端末装置１００は、チャレンジと測定結果とを含む署名データを認証サーバ３００に送信する。なお、図１５では、提供サーバ２００と認証サーバ３００とをまとめてサービスＡとして記載している。
【００６３】
図１６は、測定結果の照合の一例を示す図である。図１６に示すように、認証サーバ３００は、照合ＤＢ３０２の登録された測定結果（トークン登録時）と、受信した署名データの測定結果（トークン呼び出し時）とを照合する。図１５および図１６の例では、認証サーバ３００は、悪意あるＤＬＬが測定結果に含まれるので、矛盾を検知してブロックする。つまり、認証サーバ３００は、提供サーバ２００に対してサービスの提供を許可しない。提供サーバ２００は、認証サーバ３００の許可が得られないので、サービス提供をブロックする。
【００６４】
図１７は、端末装置側でブロックする場合の一例を示す図である。図１７の例では、認証サーバ３００への署名データの送信は行わず、端末装置１００の測定部１３６は、ＡＰＩ呼び出しに不正があると判定した場合には、アプリ１３３にエラーを返してサービス提供をブロックする。なお、例えば、ユーザ登録時と異なるブラウザを用いた場合には、そのブラウザでユーザ登録を再度行うことで、以後サービスの提供を受けることができる。
【００６５】
図１８は、オブジェクトの取得元に基づいてブロックする場合の一例を示す図である。図１８の例では、端末装置１００の測定部１３６は、アプリ１３３の検証が可能でないと判定した場合、ブラウザ１３２で表示されているオブジェクトを取得する。測定部１３６は、オブジェクトの取得元が、アプリ１３３が申告する取得元と一致しない場合、アプリ１３３にエラーを返してサービス提供をブロックする。すなわち、アプリからの申告では、サービスＡへのアクセスであるのに対し、測定・照合結果は、サービスＢへのアクセスであることから、端末装置１００側で矛盾を検知してサービス提供をブロックする。または、端末装置１００は、測定・照合結果をサービスＡ側に送信し、サービスＡ側でサービス提供をブロックする。
【００６６】
次に、実施例の認証システム１０の動作について説明する。まず、ユーザ登録時の登録処理について説明する。図１９は、実施例の登録処理の一例を示すシーケンス図である。
【００６７】
端末装置１００のブラウザ１３２は、例えばユーザの操作に基づくサービス要求を提供サーバ２００に送信する（ステップＳ１１）。提供サーバ２００は、端末装置１００からサービス要求を受信すると、アプリを端末装置１００に送信する（ステップＳ１２）。ブラウザ１３２は、サービス要求に対応するアプリを、提供サーバ２００から受信して取得する。ブラウザ１３２は、取得したアプリをアプリ１３３として実行するとともに（ステップＳ１３）、検証部１３４に対してアプリ１３３の取得元の検証を指示する。
【００６８】
アプリ１３３は、実行が開始されると、ユーザに対してレガシー認証の操作を求める。アプリ１３３は、ユーザの操作に基づいて、提供サーバ２００との間でレガシー認証情報を送受信してレガシー認証を行う（ステップＳ１４）。アプリ１３３は、レガシー認証が完了すると、登録要求を認証サーバ３００に送信する（ステップＳ１５）。認証サーバ３００は、端末装置１００から登録要求を受信すると、当該端末装置１００に対してチャレンジを送信する（ステップＳ１６）。
【００６９】
端末装置１００のアプリ１３３は、認証サーバ３００から登録要求に対応するチャレンジを受信する。アプリ１３３は、受信したチャレンジへの署名要求を中継部１３５に出力する（ステップＳ１７）。
【００７０】
検証部１３４は、ブラウザ１３２からアプリの取得元の検証が指示されると、アプリ１３３が署名要求を中継部１３５に出力する際に、アプリ１３３が対応するサービスの情報を取得する。つまり、検証部１３４は、アプリ１３３の取得元を測定する（ステップＳ１８）。検証部１３４は、測定したアプリ１３３の取得元、つまり取得したサービスの情報を検証情報として中継部１３５に出力する。
【００７１】
中継部１３５は、アプリ１３３から署名要求が入力され、検証部１３４から検証情報が入力されると、ＦＩＤＯＡＰＩを呼び出して、署名要求を署名部１３７に出力する。また、中継部１３５は、検証情報を測定部１３６に出力する。
【００７２】
署名部１３７は、署名要求が入力されると、署名要求に応じて生体認証部１１２から生体情報を入力するようにユーザＭに促す。署名部１３７は、生体認証部１１２から生体情報が入力されると、生体情報記憶部１２１を参照し、予め登録されたユーザＭの生体情報と照合する（ステップＳ１９）。
【００７３】
測定部１３６は、中継部１３５から検証情報が入力されると、つまり中継部１３５がＦＩＤＯＡＰＩを呼び出すと、ＦＩＤＯＡＰＩを呼び出したプログラムの親子関係を測定する測定処理を実行する（ステップＳ２０）。ここで、図２０を用いて測定処理について説明する。図２０は、実施例の測定処理の一例を示すフローチャートである。
【００７４】
測定部１３６は、カレントプログラムの呼び出し元の親ＩＤを取得して親ＩＤのプログラム名を取得して記憶する（ステップＳ２０１）。測定部１３６は、親ＩＤが「０」であるか否かを判定する（ステップＳ２０２）。測定部１３６は、親ＩＤが「０」でないと判定した場合には（ステップＳ２０２：否定）、カレントプログラムに親ＩＤを代入し（ステップＳ２０３）、ステップＳ２０１に戻る。
【００７５】
測定部１３６は、親ＩＤが「０」であると判定した場合には（ステップＳ２０２：肯定）、登録フェーズであるか否かを判定する（ステップＳ２０４）。測定部１３６は、登録フェーズであると判定した場合には（ステップＳ２０４：肯定）、ステップＳ２０７に進む。
【００７６】
測定部１３６は、登録フェーズでないと判定した場合には（ステップＳ２０４：否定）、測定結果に基づいて、ＡＰＩ呼び出しに不正があるか否かを判定する（ステップＳ２０５）。測定部１３６は、ＡＰＩ呼び出しに不正がないと判定した場合には（ステップＳ２０５：否定）、測定結果にエラー情報を付加せずに、ステップＳ２０７に進む。測定部１３６は、ＡＰＩ呼び出しに不正があると判定した場合には（ステップＳ２０５：肯定）、エラー情報を生成して測定結果に付加し（ステップＳ２０６）、ステップＳ２０７に進む。
【００７７】
測定部１３６は、検証情報に基づいて、アプリ１３３の検証が可能であるか否かを判定する（ステップＳ２０７）。測定部１３６は、アプリ１３３の検証が可能であると判定した場合には（ステップＳ２０７：肯定）、測定結果記憶部１２３を参照し、測定結果を署名部１３７に出力し、ステップＳ２１３に進む。
【００７８】
測定部１３６は、アプリ１３３の検証が可能でないと判定した場合には（ステップＳ２０７：否定）、ブラウザ１３２で表示されているオブジェクトを取得する（ステップＳ２０８）。測定部１３６は、取得したオブジェクトの取得元が、アプリ１３３が申告する取得元と一致するか否かを判定する（ステップＳ２０９）。測定部１３６は、取得元が一致しないと判定した場合には（ステップＳ２０９：否定）、全てのオブジェクトの取得元がチェック済みであるか否かを判定する（ステップＳ２１０）。
【００７９】
測定部１３６は、全てのオブジェクトの取得元がチェック済みでない場合には（ステップＳ２１０：否定）、ステップＳ２０８に戻る。測定部１３６は、全てのオブジェクトの取得元がチェック済みである場合には（ステップＳ２１０：肯定）、アプリ１３３に対して不正なＡＰＩ呼び出しである旨のエラーを返し（ステップＳ２１１）、測定処理を終了する。
【００８０】
一方、ステップＳ２０９において、測定部１３６は、取得元が一致すると判定した場合には（ステップＳ２０９：肯定）、当該オブジェクトを測定し（ステップＳ２１２）、測定結果を記憶してステップＳ２１３に進む。また、測定部１３６は、測定結果記憶部１２３を参照し、測定結果を署名部１３７に出力する。
【００８１】
署名部１３７は、ステップＳ１９の照合結果が真である場合には、測定結果に基づいて、チャレンジと、測定結果（ＡＰＩ呼び出しにおける親子関係や、アプリの取得元、アプリＩＤ等）と、公開鍵とを含む署名データを生成する（ステップＳ２１３）。署名部１３７は、生成した署名データをアプリ１３３に出力する。
【００８２】
署名部１３７は、登録フェーズであるか否かを判定する（ステップＳ２１４）。署名部１３７は、登録フェーズでないと判定した場合には（ステップＳ２１４：否定）、測定処理を終了し、元の処理に戻る。署名部１３７は、登録フェーズであると判定した場合には（ステップＳ２１４：肯定）、認証サーバ３００から送信される保存成功情報の受信を所定時間待機する。
【００８３】
署名部１３７は、所定時間内に認証サーバ３００から保存成功情報が返ってきたか否かを判定する（ステップＳ２１５）。署名部１３７は、保存成功情報が返ってきたと判定した場合には（ステップＳ２１５：肯定）、測定結果を測定結果記憶部１２３に記憶し（ステップＳ２１６）、測定処理を終了して元の処理に戻る。署名部１３７は、保存成功情報が返ってきていないと判定した場合には（ステップＳ２１５：否定）、測定処理を終了して元の処理に戻る。
【００８４】
図１９の説明に戻って、アプリ１３３は、署名部１３７からユーザ登録用の署名データが入力されると、入力された署名データを認証サーバ３００に送信する（ステップＳ２１）。
【００８５】
認証サーバ３００は、端末装置１００から署名データを受信すると（ステップＳ２２）、署名データに含まれる測定結果および公開鍵を照合ＤＢ３０２に記憶する（ステップＳ２３）。認証サーバ３００は、測定結果および公開鍵を照合ＤＢ３０２に記憶すると、端末装置１００および提供サーバ２００に対して保存成功情報を送信する（ステップＳ２４）。
【００８６】
提供サーバ２００は、認証サーバ３００から保存成功情報を受信すると（ステップＳ２５）、端末装置１００に対してユーザＭ向けサービスを提供するように指示する。端末装置１００は、提供サーバ２００の指示に従ってユーザＭ向けサービスを提供する（ステップＳ２６）。これにより、端末装置１００は、ユーザＭの測定結果および公開鍵を認証サーバ３００に登録できるとともに、提供サーバ２００からサービスの提供を受けることができる。
【００８７】
続いて、ユーザ認証時の認証処理について説明する。図２１は、実施例の認証処理の一例を示すシーケンス図である。なお、端末装置１００でアプリを実行するまでのステップＳ１１〜Ｓ１３までの処理は、登録処理と同様であるので、その説明を省略する。
【００８８】
アプリ１３３は、実行が開始されると、認証要求を認証サーバ３００に送信する（ステップＳ３１）。認証サーバ３００は、端末装置１００から認証要求を受信すると、当該端末装置１００に対してチャレンジを送信する（ステップＳ３２）。
【００８９】
端末装置１００のアプリ１３３は、認証サーバ３００から認証要求に対応するチャレンジを受信する。アプリ１３３は、受信したチャレンジへの署名要求を中継部１３５に出力する（ステップＳ３３）。
【００９０】
検証部１３４は、ブラウザ１３２からアプリの取得元の検証が指示されると、アプリ１３３が署名要求を中継部１３５に出力する際に、アプリ１３３が対応するサービスの情報を取得する。つまり、検証部１３４は、アプリ１３３の取得元を測定する（ステップＳ３４）。検証部１３４は、測定したアプリ１３３の取得元、つまり取得したサービスの情報を検証情報として中継部１３５に出力する。
【００９１】
中継部１３５は、アプリ１３３から署名要求が入力され、検証部１３４から検証情報が入力されると、ＦＩＤＯＡＰＩを呼び出して、署名要求を署名部１３７に出力する。また、中継部１３５は、検証情報を測定部１３６に出力する。
【００９２】
署名部１３７は、署名要求が入力されると、署名要求に応じて生体認証部１１２から生体情報を入力するようにユーザＭに促す。署名部１３７は、生体認証部１１２から生体情報が入力されると、生体情報記憶部１２１を参照し、予め登録されたユーザＭの生体情報と照合する（ステップＳ３５）。
【００９３】
測定部１３６は、中継部１３５から検証情報が入力されると、つまり中継部１３５がＦＩＤＯＡＰＩを呼び出すと、ＦＩＤＯＡＰＩを呼び出したプログラムの親子関係を測定する測定処理を実行する（ステップＳ２０）。
【００９４】
アプリ１３３は、署名部１３７からユーザ認証用の署名データが入力されると、入力された署名データを認証サーバ３００に送信する（ステップＳ３６）。
【００９５】
認証サーバ３００は、端末装置１００から署名データを受信すると（ステップＳ３７）、照合ＤＢ３０２を参照し、公開鍵で署名を検証して改竄がないことを確認する（ステップＳ３８）。その後、認証サーバ３００は、署名データに含まれる測定結果と、照合ＤＢ３０２の登録済みの測定結果とを照合する（ステップＳ３９）。認証サーバ３００は、照合結果が一致したらユーザＭの確認情報を提供サーバ２００に送信する（ステップＳ４０）。なお、認証サーバ３００は、照合結果が一致しない場合には、提供サーバ２００にサービスの提供を許可しない。
【００９６】
提供サーバ２００は、認証サーバ３００から確認情報を受信すると（ステップＳ４１）、端末装置１００に対してユーザＭ向けサービスを提供するように指示する。端末装置１００は、提供サーバ２００の指示に従ってユーザＭ向けサービスを提供する（ステップＳ４２）。これにより、端末装置１００は、不正なＡＰＩ呼び出しを検出できるとともに、提供サーバ２００からサービスの提供を受けることができる。すなわち、端末装置１００は、ＡＰＩ呼び出しが自由に行えるＷｉｎｄｏｗｓにおいても、Ｗｅｂアプリからの不正なＡＰＩ呼び出しを検出し、ユーザの成り済ましを防止できる。従って、端末装置１００としてＷｉｎｄｏｗｓ端末を用いても、端末で生体情報を照合するＦＩＤＯを適用することができる。
【００９７】
このように、端末装置１００は、サービスを提供する提供サーバ２００から、サービスをユーザに提供するアプリを取得してブラウザ上で実行するとともにアプリの取得元を検証する。また、端末装置１００は、ユーザを認証する認証サーバ３００に対してアプリが送信するユーザの認証要求に応じたデータを認証サーバ３００から受信し、受信したデータへの署名要求を実行する。また、端末装置１００は、署名要求を実行する際に、署名要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定する。また、端末装置１００は、データと、検証されたアプリの取得元と、測定された親子関係を示す測定結果とに基づいて、秘密鍵または公開鍵を用いて署名データを生成する。また、端末装置１００は、生成された署名データを認証サーバ３００に送信し、提供サーバ２００が登録済みの測定結果と一致する照合結果を認証サーバ３００から受信した場合に、サービスをユーザに提供する。その結果、端末装置１００は、不正なＡＰＩ呼び出しを検出できる。
【００９８】
また、端末装置１００は、アプリの取得元を検証出来ないブラウザ上でアプリが実行されている場合、ブラウザに表示されているオブジェクトの取得元が、アプリが申告する取得元と一致するオブジェクトの情報を親子関係に含める。その結果、端末装置１００は、古いブラウザにおいても、不正なＡＰＩ呼び出しを検出できる。
【００９９】
また、端末装置１００は、署名要求時に取得したユーザの生体情報と、登録済みのユーザの生体情報とを照合し、照合結果が一致する場合に署名データを生成する。その結果、端末装置１００は、提供されるサービスのセキュリティを向上させることができる。
【０１００】
また、端末装置１００は、サービスを提供する提供サーバ２００から、サービスをユーザに提供するアプリを取得してブラウザ上で実行するとともにアプリの取得元を検証する。また、端末装置１００は、アプリを実行する際に、アプリからの認証要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定する。また、端末装置１００は、測定された親子関係を示す測定結果と、登録済みの親子関係を示す測定結果とを照合し、照合結果が一致する場合に、認証要求を受け付ける。その結果、端末装置１００は、端末装置１００側で不正なＡＰＩ呼び出しを検出できる。
【０１０１】
また、認証サーバ３００は、サービスを提供する提供サーバ２００からサービスをユーザに提供するアプリを取得してブラウザ上で実行する端末装置１００から、ユーザの認証要求を受信すると、ユーザの認証要求に応じたデータを端末装置１００に送信する。また、認証サーバ３００は、端末装置１００においてアプリを実行してユーザの登録を行う場合にアプリからの認証要求に対応するＡＰＩを呼び出したプログラムの親子関係を測定した測定結果を、登録済み測定結果として記憶する記憶部を有する。また、認証サーバ３００は、記憶部を参照して、端末装置１００から受信した署名データに含まれる測定結果と、記憶部に記憶された登録済み測定結果とを照合し、照合結果が一致する場合に、提供サーバ２００にサービスの提供を許可する。その結果、認証サーバ３００は、認証サーバ３００側で不正なＡＰＩ呼び出しを検出できる。
【０１０２】
なお、上記実施例では、端末装置１００側で生体情報を照合して照合結果を認証サーバ３００側に送信する手法としてＦＩＤＯを挙げたが、これに限定されない。例えば、端末装置１００側で生体認証を行うものであれば、各種の手法を用いてもよい。
【０１０３】
また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、検証部１３４と中継部１３５とを統合してもよいし、測定部１３６と署名部１３７とを統合してもよい。また、図示した各処理は、上記の順番に限定されるものでなく、処理内容を矛盾させない範囲において、同時に実施してもよく、順序を入れ替えて実施してもよい。
【０１０４】
さらに、各装置で行われる各種処理機能は、ＣＰＵ（またはＭＰＵ、ＭＣＵ（Micro  Controller  Unit）等のマイクロ・コンピュータ）上で、その全部または任意の一部を実行するようにしてもよい。また、各種処理機能は、ＣＰＵ（またはＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行されるプログラム上、またはワイヤードロジックによるハードウェア上で、その全部または任意の一部を実行するようにしてもよいことは言うまでもない。
【０１０５】
ところで、上記の各実施例で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することで実現できる。そこで、以下では、上記の各実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図２２は、認証制御プログラムを実行するコンピュータの一例を示す図である。
【０１０６】
図２２に示すように、コンピュータ４００は、各種演算処理を実行するＣＰＵ４０１と、データ入力を受け付ける入力装置４０２と、モニタ４０３とを有する。また、コンピュータ４００は、記憶媒体からプログラム等を読み取る媒体読取装置４０４と、各種装置と接続するためのインタフェース装置４０５と、他の情報処理装置等と有線または無線により接続するための通信装置４０６とを有する。また、コンピュータ４００は、各種情報を一時記憶するＲＡＭ４０７と、フラッシュメモリ４０８とを有する。また、各装置４０１〜４０８は、バス４０９に接続される。
【０１０７】
フラッシュメモリ４０８には、図１０に示した実行部１３１、ブラウザ１３２、アプリ１３３、検証部１３４、中継部１３５、測定部１３６および署名部１３７の各処理部と同様の機能を有する認証制御プログラムが記憶される。また、フラッシュメモリ４０８には、生体情報記憶部１２１、秘密鍵記憶部１２２、測定結果記憶部１２３、および、認証制御プログラムを実現するための各種データが記憶される。入力装置２０２は、例えば、コンピュータ４００のユーザから操作情報等の各種情報の入力を受け付ける。モニタ４０３は、例えば、コンピュータ４００のユーザに対して表示画面等の各種画面を表示する。インタフェース装置４０５は、例えば指紋認証を行う生体認証装置４１０等が接続される。通信装置４０６は、例えば、図１０に示した通信部１１０と同様の機能を有しネットワークＮと接続され、提供サーバ２００、認証サーバ３００および他の情報処理装置と各種情報をやりとりする。
【０１０８】
ＣＰＵ４０１は、フラッシュメモリ４０８に記憶された各プログラムを読み出して、ＲＡＭ４０７に展開して実行することで、各種の処理を行う。また、これらのプログラムは、コンピュータ４００を図１０に示した実行部１３１、ブラウザ１３２、アプリ１３３、検証部１３４、中継部１３５、測定部１３６および署名部１３７として機能させることができる。
【０１０９】
なお、上記の認証制御プログラムは、必ずしもフラッシュメモリ４０８に記憶されている必要はない。例えば、コンピュータ４００が読み取り可能な記憶媒体に記憶されたプログラムを、コンピュータ４００が読み出して実行するようにしてもよい。コンピュータ４００が読み取り可能な記憶媒体は、例えば、ＣＤ−ＲＯＭやＤＶＤ（Digital  Versatile  Disc）、ＵＳＢ（Universal  Serial  Bus）メモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリ、ハードディスクドライブ等が対応する。また、公衆回線、インターネット、ＬＡＮ等に接続された装置にこの認証制御プログラムを記憶させておき、コンピュータ４００がこれらから認証制御プログラムを読み出して実行するようにしてもよい。
【符号の説明】
【０１１０】
１０  認証システム
１００  端末装置
１１０  通信部
１１１  表示操作部
１１２  生体認証部
１２０  記憶部
１２１  生体情報記憶部
１２２  秘密鍵記憶部
１２３  測定結果記憶部
１３０  制御部
１３１  実行部
１３２  ブラウザ
１３３  アプリ
１３４  検証部
１３５  中継部
１３６  測定部
１３７  署名部
２００  提供サーバ
３００  認証サーバ
３０１  認証部
３０２  照合ＤＢ
Ｎ  ネットワーク
【図１】
2019129385.tif 000003
【図２】
2019129385.tif 000004
【図３】
2019129385.tif 000005
【図４】
2019129385.tif 000006
【図５】
2019129385.tif 000007
【図６】
2019129385.tif 000008
【図７】
2019129385.tif 000009
【図８】
2019129385.tif 000010
【図９】
2019129385.tif 000011
【図１０】
2019129385.tif 000012
【図１１】
2019129385.tif 000013
【図１２】
2019129385.tif 000014
【図１３】
2019129385.tif 000015
【図１４】
2019129385.tif 000016
【図１５】
2019129385.tif 000017
【図１６】
2019129385.tif 000018
【図１７】
2019129385.tif 000019
【図１８】
2019129385.tif 000020
【図１９】
2019129385.tif 000021
【図２０】
2019129385.tif 000022
【図２１】
2019129385.tif 000023
【図２２】
2019129385.tif 000024