(57)【要約】【課題】ユーザがアプリケーションの動作を事前に把握し、アプリケーションの動作を制御することができるAPI実行制御装置およびプログラムを提供する。【解決手段】API実行部１１は、アプリケーションがAPI（Application Program Interface）を実行しようとする動作を検出する。通知部１７は、この動作が検出された場合に、ユーザに通知を行う。実行制御部１６は、通知部１７がユーザに通知を行った後、ユーザによって入力された情報に基づいて、APIの実行を制御する。【選択図】図１
2013182500.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションがAPI（Application Program Interface）を実行しようとする動作を検出する検出部と、
前記動作が検出された場合に、ユーザに通知を行う通知部と、
前記通知部がユーザに通知を行った後、ユーザによって入力された情報に基づいて、前記APIの実行を制御する制御部と、
を備えたことを特徴とするAPI実行制御装置。
【請求項２】
前記APIの実行の制御内容を示す制御情報を記憶する記憶部と、
前記通知部がユーザに通知を行った後、ユーザによって入力された情報を前記制御情報として前記記憶部に格納する格納処理部と、をさらに備え、
前記制御部は、前記通知部がユーザに通知を行った後、ユーザによって入力された情報に基づいて前記APIの実行を制御し、前記動作が再度検出された場合に、前記記憶部に格納されている前記制御情報に基づいて前記APIの実行を制御する
ことを特徴とする請求項１に記載のAPI実行制御装置。
【請求項３】
前記動作が検出された場合に、前記APIを実行するメソッドの情報を取得する情報取得部をさらに備え、
前記格納処理部は、前記通知部がユーザに通知を行った後、ユーザによって入力された情報と、前記メソッドの情報とを関連付けて前記制御情報として前記記憶部に格納し、
前記制御部は、前記通知部がユーザに通知を行った後、ユーザによって入力された情報に基づいて前記APIの実行を制御し、前記動作が再度検出された場合に、前記情報取得部によって取得された前記メソッドの情報と同一の情報を含む前記制御情報を前記記憶部から読み出し、読み出した前記制御情報に基づいて前記APIの実行を制御する
ことを特徴とする請求項２に記載のAPI実行制御装置。
【請求項４】
前記制御部は、前記通知部がユーザに通知を行った後、ユーザによって入力された情報が前記APIの実行の許可を示している場合のみ前記APIの実行を許可し、前記動作が再度検出された場合に、前記記憶部に格納されている前記制御情報が前記APIの実行の許可を示しているときのみ前記APIの実行を許可することを特徴とする請求項２に記載のAPI実行制御装置。
【請求項５】
前記制御部は、前記通知部がユーザに通知を行った後、ユーザによって入力された情報がダミー情報を利用することを示している場合に、前記APIの実行結果として、前記ダミー情報を前記アプリケーションに返すように前記APIを制御し、前記動作が再度検出された場合に、前記記憶部に格納されている前記制御情報がダミー情報を利用することを示していれば、前記APIの実行結果として前記ダミー情報を前記アプリケーションに返すように前記APIを制御することを特徴とする請求項２に記載のAPI実行制御装置。
【請求項６】
前記格納処理部と前記制御部に対して同一のUID（User ID）が与えられていることを特徴とする請求項２〜請求項５のいずれか一項に記載のAPI実行制御装置。
【請求項７】
前記アプリケーションと前記検出部は同一のプロセスで処理を行い、
前記アプリケーションと、前記格納処理部および前記制御部とに対して異なるUID（User ID）が与えられ、
前記記憶部に格納されている前記制御情報にアクセスする権限が前記アプリケーションには与えられず、前記格納処理部および前記制御部には与えられている
ことを特徴とする請求項６に記載のAPI実行制御装置。
【請求項８】
前記制御部は、前記アプリケーションの動作中、バックグラウンドで動作していることを特徴とする請求項２〜請求項７のいずれか一項に記載のAPI実行制御装置。
【請求項９】
前記APIは、指定された引数に対応する情報をデータベースから取得するAPIであり、
前記通知部は、前記動作が検出され、かつ、前記動作の際に所定の引数が指定されている場合にユーザに通知を行う
ことを特徴とする請求項１〜請求項８のいずれか一項に記載のAPI実行制御装置。
【請求項１０】
前記通知部は、Activity、Service、BroadcastReceiver、ContentProviderの少なくともいずれかをアプリケーションの構成要素とするOS上で動作するアプリケーションであって、前記Activityを構成要素とするアプリケーションであることを特徴とする請求項１〜請求項９のいずれか一項に記載のAPI実行制御装置。
【請求項１１】
アプリケーションがAPI（Application Program Interface）を実行しようとする動作を検出する検出部と、
前記動作が検出された場合に、ユーザに通知を行う通知部と、
前記通知部がユーザに通知を行った後、ユーザによって入力された情報に基づいて、前記APIの実行を制御する制御部と、
としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションによるAPI（Application Program Interface）の実行を制御するAPI実行制御装置に関する。また、本発明は、本API実行制御装置としてコンピュータを機能させるためのプログラムにも関する。
【背景技術】
【０００２】
汎用OS（オペレーティングシステム）を用いたオープンプラットフォームを採用する、スマートフォンと呼ばれる携帯情報端末が普及している。また、スマートフォンに搭載される汎用OSとして、端末で管理される情報や機能を利用するための命令や関数の集合であるAPI が豊富に用意されているAndroid（登録商標）が注目を集めている。本明細書では一例として、Android（登録商標） OSを搭載したスマートフォンについて記載する。
【０００３】
スマートフォンは、誰もが自由にアプリケーションを開発して公開でき、公開されたアプリケーションをユーザが自由にインストールできるプラットフォームである。公開されたアプリケーションをスマートフォンに導入することにより、スマートフォンの様々な機能を柔軟かつ容易に拡張することができる。
【０００４】
しかし、アプリケーションの中には、ユーザに気づかれないように、端末内の情報を収集して外部に送信する悪性アプリケーション（マルウェア）が存在する。特に、正規のアプリケーションを装いつつ、こうした不正な振る舞いを行うアプリケーションはトロイの木馬と呼ばれており、ユーザがその脅威に気づくことは困難である。
【０００５】
スマートフォンには、電話やカメラを制御するAPIが設けられており、アプリケーションがAPIを利用して、発呼や、SMS（Short Message Service）通信、写真撮影を行うことができる。これらの行為を悪性アプリケーションが密かに行った場合、勝手な課金やプライバシの漏洩が発生する。
【０００６】
スマートフォンは、ユーザとの結びつきがPC（パーソナルコンピュータ）よりも緊密な機器であり、電話番号、メールアドレス、住所録、メールの送受信履歴、インターネットの閲覧履歴等の個人情報が集積している。また、端末の高機能化と、常に携帯される利用形態とから、従来のPCでは収集されなかった位置情報等の情報も容易に取得可能となり、情報が悪用される脅威に直面する。
【０００７】
Android（登録商標）では、アプリケーションが利用する機能群や情報群はパーミッションとして定義されている。パーミッションは、アプリケーションを実行可能な端末内の機能・情報の利用や設定の変更に係る権限である。アプリケーションのインストール時に、アプリケーションが使用するパーミッションがユーザに通知（宣言）され、ユーザによってインストールの可否が判断される。アプリケーションがインストールされた後、アプリケーションは、インストール時にユーザに通知したパーミッションにより許可されている範囲内で動作する。このような、パーミッションに基づいてアプリケーションの動作に制限を与える機構により、アプリケーションの不正な動作が防止される。なお、非特許文献１〜３には、アプリケーションのインストール時とインストール後に、アプリケーションが使用するパーミッションをユーザが変更することができるようにAndroid（登録商標）に改良を加えることが記載されている。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】M.Nauman, S.Khan, and X.Zhang, “Apex: Extending Android Permission Model and Enforcement with User-defined Runtime Constraints”, 5th ACM Symposium on Information, Computer and Communications Security, pp 328-332,2010
【非特許文献２】M. Ongtang, S. McLaughlin, W. Enck, and P. McDaniel, “Semantically Rich Application-Centric Security in Android”, ieee:Annual Computer Security Applications Conference,pp 340-349, 2009
【非特許文献３】H.Banuri, M.Alam, S.Khan, J.Manzoor, B.Ali, Y.Khan, M.Yaseen, M.N.Tahir, T.Ali and X.Zhaug, “Android Runtime Security Policy Enforcement Framework” The 2010 International Workshop on Smartphone Applications and Services, 2010
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかし、パーミッションに基づいてアプリケーションの動作に制限を与える機構では、アプリケーションのインストール時に承認したパーミッション、あるいはアプリケーションのインストール後に変更したパーミッションが、アプリケーションによって、いつ、どのように使用されているのかをユーザが知ることができないという課題がある。現在、許可されたパーミッションを用いて不正な動作を行う悪性アプリケーションが出現していることが問題となっている。ユーザが、アプリケーションをインストールするために、パーミッションを一度許可してしまうと、パーミッションを必要とする動作をアプリケーションが実行したとしても、ユーザにはそのことが通知されない。そのため、ユーザが情報漏えいなどの被害に気づくことが難しい。
【００１０】
マルウェアと呼ばれる悪性アプリケーションの中には、トロイの木馬と呼ばれる機能を持つアプリケーションがある。マルウェアが、本来の目的に沿って正しくパーミッションを使用しつつ、同じパーミッションを用いてバックグラウンドで不正な動作を行っている場合、マルウェアを検知することは極めて難しい。例えば、SMSクライアントアプリケーションが、外部への情報の送信に関するパーミッションであるSEND_SMSを宣言することは正しいと考えられる。しかし、SMSクライアントアプリケーションが正規の振る舞いをしつつ、ユーザの意図とは無関係にバックグラウンドで不正に外部へ情報を送信していた場合、ユーザが情報の送信に気づくことは極めて難しい。このため、ユーザが承認していない行為がアプリケーションによって、いつ、どのように実行されるのかを把握できる仕組みが必要となる。
【００１１】
上記の課題以外に、ユーザの誤操作に起因する課題もある。例えば、SMSクライアントアプリケーションの動作中に画面に表示されたボタンのうちSMSによりメッセージを送信するボタンをユーザが間違えて押しても、メッセージの送信動作を止めることができない。したがって、ユーザビリティの観点で、SMSによるメッセージの送信等が行われる前に、アプリケーションがこれから行う動作をユーザが確認でき、動作の実行の可否をユーザが選択できるようになると、ユーザの誤操作による不利益が発生しなくなる。
【００１２】
本発明は、上述した課題に鑑みてなされたものであって、ユーザがアプリケーションの動作を事前に把握し、アプリケーションの動作を制御することができるAPI実行制御装置およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明は、上記の課題を解決するためになされたもので、アプリケーションがAPI（Application Program Interface）を実行しようとする動作を検出する検出部と、前記動作が検出された場合に、ユーザに通知を行う通知部と、前記通知部がユーザに通知を行った後、ユーザによって入力された情報に基づいて、前記APIの実行を制御する制御部と、を備えたことを特徴とするAPI実行制御装置である。
【００１４】
また、本発明のAPI実行制御装置は、前記APIの実行の制御内容を示す制御情報を記憶する記憶部と、前記通知部がユーザに通知を行った後、ユーザによって入力された情報を前記制御情報として前記記憶部に格納する格納処理部と、をさらに備え、前記制御部は、前記通知部がユーザに通知を行った後、ユーザによって入力された情報に基づいて前記APIの実行を制御し、前記動作が再度検出された場合に、前記記憶部に格納されている前記制御情報に基づいて前記APIの実行を制御することを特徴とする。
【００１５】
また、本発明のAPI実行制御装置は、前記動作が検出された場合に、前記APIを実行するメソッドの情報を取得する情報取得部をさらに備え、前記格納処理部は、前記通知部がユーザに通知を行った後、ユーザによって入力された情報と、前記メソッドの情報とを関連付けて前記制御情報として前記記憶部に格納し、前記制御部は、前記通知部がユーザに通知を行った後、ユーザによって入力された情報に基づいて前記APIの実行を制御し、前記動作が再度検出された場合に、前記情報取得部によって取得された前記メソッドの情報と同一の情報を含む前記制御情報を前記記憶部から読み出し、読み出した前記制御情報に基づいて前記APIの実行を制御することを特徴とする。
【００１６】
また、本発明のAPI実行制御装置において、前記制御部は、前記通知部がユーザに通知を行った後、ユーザによって入力された情報が前記APIの実行の許可を示している場合のみ前記APIの実行を許可し、前記動作が再度検出された場合に、前記記憶部に格納されている前記制御情報が前記APIの実行の許可を示しているときのみ前記APIの実行を許可することを特徴とする。
【００１７】
また、本発明のAPI実行制御装置において、前記制御部は、前記通知部がユーザに通知を行った後、ユーザによって入力された情報がダミー情報を利用することを示している場合に、前記APIの実行結果として、前記ダミー情報を前記アプリケーションに返すように前記APIを制御し、前記動作が再度検出された場合に、前記記憶部に格納されている前記制御情報がダミー情報を利用することを示していれば、前記APIの実行結果として前記ダミー情報を前記アプリケーションに返すように前記APIを制御することを特徴とする。
【００１８】
また、本発明のAPI実行制御装置において、前記格納処理部と前記制御部に対して同一のUID（User ID）が与えられていることを特徴とする。
【００１９】
また、本発明のAPI実行制御装置において、前記アプリケーションと前記検出部は同一のプロセスで処理を行い、前記アプリケーションと、前記格納処理部および前記制御部とに対して異なるUID（User ID）が与えられ、前記記憶部に格納されている前記制御情報にアクセスする権限が前記アプリケーションには与えられず、前記格納処理部および前記制御部には与えられていることを特徴とする。
【００２０】
また、本発明のAPI実行制御装置において、前記制御部は、前記アプリケーションの動作中、バックグラウンドで動作していることを特徴とする。
【００２１】
また、本発明のAPI実行制御装置において、前記APIは、指定された引数に対応する情報をデータベースから取得するAPIであり、前記通知部は、前記動作が検出され、かつ、前記動作の際に所定の引数が指定されている場合にユーザに通知を行うことを特徴とする。
【００２２】
また、本発明のAPI実行制御装置において、前記通知部は、Activity、Service、BroadcastReceiver、ContentProviderの少なくともいずれかをアプリケーションの構成要素とするOS上で動作するアプリケーションであって、前記Activityを構成要素とするアプリケーションであることを特徴とする。
【００２３】
また、本発明は、アプリケーションがAPI（Application Program Interface）を実行しようとする動作を検出する検出部と、前記動作が検出された場合に、ユーザに通知を行う通知部と、前記通知部がユーザに通知を行った後、ユーザによって入力された情報に基づいて、前記APIの実行を制御する制御部と、としてコンピュータを機能させるためのプログラムである。
【発明の効果】
【００２４】
本発明によれば、アプリケーションがAPIを実行しようとする動作が検出された場合に、ユーザに通知が行われ、ユーザによって入力された情報に基づいて、APIの実行が制御されるので、ユーザがアプリケーションの動作を事前に把握し、アプリケーションの動作を制御することができる。
【図面の簡単な説明】
【００２５】
【図１】本発明の一実施形態による端末装置の構成を示すブロック図である。
【図２】本発明の一実施形態においてフックの対象となるAPIの一覧を示す参考図である。
【図３】本発明の一実施形態におけるAPI実行部の動作の手順を示すフローチャートである。
【図４】本発明の一実施形態における情報取得部の動作の手順を示すフローチャートである。
【図５】本発明の一実施形態におけるセキュリティポリシー判定部の動作の手順を示すフローチャートである。
【図６】本発明の一実施形態においてAPIが実行される状況の情報を示す参考図である。
【図７】本発明の一実施形態においてAPIを呼び出したメソッドが記述されたソースコードを示す参考図である。
【図８】本発明の一実施形態においてAPIを呼び出したメソッドを呼び出したメソッドが記述されたソースコードを示す参考図である。
【図９】本発明の一実施形態におけるソケット生成部の動作の手順を示すフローチャートである。
【図１０】本発明の一実施形態における起動部の動作の手順を示すフローチャートである。
【図１１】本発明の一実施形態における通知部の動作の手順を示すフローチャートである。
【図１２】本発明の一実施形態において表示されるメッセージを示す参考図である。
【図１３】本発明の一実施形態における格納処理部の動作の手順を示すフローチャートである。
【図１４】本発明の一実施形態における実行制御部の動作の手順を示すフローチャートである。
【図１５】本発明の一実施形態におけるデータベース参照APIの引数を示す参考図である。
【図１６】本発明の一実施形態におけるAPI実行部の動作の手順を示すフローチャートである。
【発明を実施するための形態】
【００２６】
以下、図面を参照し、本発明の実施形態を説明する。本明細書および図面では、便宜上、必要に応じてandroid（登録商標）という文字列を*andrd*という文字列で代用し、Android（登録商標）という文字列を*Andrd*という文字列で代用し、java（登録商標）という文字列を*jv*という文字列で代用している。すなわち、*andrd*という文字列はandroid（登録商標）という文字列と等価であり、*Andrd*という文字列はAndroid（登録商標）という文字列と等価であり、*jv*という文字列はjava（登録商標）という文字列と等価である。
【００２７】
図１は、本発明の一実施形態による端末装置の構成を示している。本実施形態の端末装置は、OS にAndroid（登録商標）を実装したスマートフォン等の装置として構成されている。図１に示すように端末装置は、アプリケーション１０、API実行部１１、情報取得部１２、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６、通知部１７、格納処理部１８、記憶部１９、入力部２０、表示部２１、通信部２２を有する。API実行部１１、情報取得部１２、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６、通知部１７、格納処理部１８は、本発明のAPI実行制御装置の一例であるAPI実行制御部３０を構成する。
【００２８】
アプリケーション１０は、SMSクライアントアプリケーション等であり、アプリケーションの処理として規定された各種の処理を行う。API実行部１１は、アプリケーション１０からの要求に応じてAPI１１ａを実行する。API１１ａは、OSであるAndroid（登録商標）で用意されているAPI（メソッド）である。API実行部１１は、アプリケーション１０からAPI１１ａの実行要求を受けたときにAPI１１ａを実行し、実行結果をアプリケーション１０に返す。
【００２９】
情報取得部１２は、アプリケーション１０がAPI１１ａを呼び出して実行しようとするときに、API１１ａを実行するメソッドの情報を含む各種情報を取得する。情報取得部１２が取得した情報は、コンテキストデータＣＤとして、記憶部１９内のセキュリティデータＳＤの記憶領域に格納される。セキュリティデータＳＤは、セキュリティポリシーＳＰ（制御情報）とコンテキストデータＣＤで構成される。セキュリティポリシーＳＰは、API１１ａの実行を制御するための、API１１ａの制御内容（実行の可否等）を示す情報を含むデータである。コンテキストデータＣＤは、情報取得部１２が取得した情報を含むデータである。セキュリティデータＳＤは記憶部１９に格納されており、セキュリティポリシー判定部１３、起動部１５、および格納処理部１８によって記憶部１９から適宜読み出されて参照される。
【００３０】
セキュリティポリシー判定部１３は、実行されるAPI１１ａに関する情報がセキュリティポリシーＳＰに登録されているか否かを判定する。セキュリティポリシーＳＰに情報が登録されている場合、セキュリティポリシー判定部１３は、セキュリティポリシーＳＰに登録されている情報に基づいた情報をAPI実行部１１に与える。また、セキュリティポリシーＳＰに情報が登録されていない場合、セキュリティポリシー判定部１３は、ソケット生成部１４に処理を引き渡す。
【００３１】
ソケット生成部１４は、入力部２０を介してユーザによって入力される情報を格納するためのソケットＳＫを生成する。起動部１５は、通常では停止している通知部１７および格納処理部１８を起動する。実行制御部１６は、入力部２０を介してユーザによって入力される情報に基づいて、API１１ａの実行を制御する。通知部１７は、アプリケーション１０がAPI１１ａを実行しようとしていることをユーザに通知する処理を行う。格納処理部１８は、入力部２０を介してユーザによって入力される情報をセキュリティポリシーＳＰおよびソケットＳＫに格納する処理を行う。
【００３２】
記憶部１９は、メモリで構成されており、OSのプログラムや、アプリケーションプログラム、端末装置が使用する各種データ等を記憶する。入力部２０は、ユーザが操作するキーやボタン等を有し、ユーザによって入力された情報を格納処理部１８に通知する。表示部２１は、通知部１７による処理の結果等を表示する。通信部２２は外部の通信装置と通信を行う。アプリケーション１０は、必要に応じて通信部２２を介して通信を行う。
【００３３】
API実行部１１、情報取得部１２、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６は、Android（登録商標）で提供されているアプリケーションフレームワーク（AplicationFramework）層で動作し、通知部１７、格納処理部１８はアプリケーション層で動作する。本実施形態のOSのプログラムでは、アプリケーションフレームワークで提供されている既存のクラスを定義しているコードに対して新たなコードが追加されている。
【００３４】
具体的には、本実施形態で制御の対象とするAPIを定義するクラス（TelephonyManagerクラス等）のコードに対して、API実行部１１および情報取得部１２が実行する処理を規定するコードが追加されている。また、アプリケーションのインストールおよびアンインストールの管理を行ったり、アプリケーションに適切なパーミッションが付与されているか否かの判定を行ったりするPackageManagerServiceクラスのコードに対して、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６の各部が実行する処理を規定するコードが追加されている。通知部１７、格納処理部１８はそれぞれアプリケーションの一部として構成されており、通知部１７、格納処理部１８が実行する処理を規定するコードがアプリケーションプログラムに含まれる。
【００３５】
本実施形態のOSのプログラムと、通知部１７、格納処理部１８を構成するアプリケーションのプログラムとをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータ（本実施形態の端末装置）に読み込ませ、実行させることにより、API実行部１１、情報取得部１２、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６、通知部１７、格納処理部１８は、各部に対して規定された処理を実行する。
【００３６】
ここで、「コンピュータ」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。
【００３７】
また、上述したプログラムは、このプログラムを記憶装置等に格納したコンピュータから、伝送媒体を介して、あるいは伝送媒体中の伝送波により他のコンピュータに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように、情報を伝送する機能を有する媒体のことをいう。また、上述したプログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能を、コンピュータに既に記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【００３８】
本実施形態では、アプリケーションフレームワーク層に実装されるAPI実行部１１および情報取得部１２と連携する処理を高速化するために、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６がアプリケーションフレームワーク層に実装されているが、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６をアプリケーションとして構成することも可能である。
【００３９】
上記の構成を有するAPI実行制御部３０は、アプリケーション１０が所定のAPI１１ａを実行しようとするときにユーザに通知を行い、入力部２０を介してユーザによって入力される情報に基づいて、API１１ａの実行を制御する。これによって、パーミッションを必要とする動作時等にユーザがアプリケーションの動作を事前に把握し、アプリケーションの動作を制御することができる。
【００４０】
次に、Android（登録商標）上で動作するアプリケーションの構成要素（コンポーネント）を説明する。Android（登録商標）上で動作するアプリケーションのコンポーネントとして、Activity、Service、BroadcastReceiver、ContentProviderの4つがある。アプリケーションのソースコードにおいて、クラスが継承するコンポーネントが記述されることにより、そのクラスで定義されているメソッドはそのコンポーネントを利用することが可能となる。以下、各コンポーネントについて説明する。
【００４１】
Activityは、ユーザに対して視覚的なインターフェイスを提供し、画面上でユーザと対話を行うコンポーネントである。アプリケーションを起動すると画面が表示される場合、Activityに記述されたプログラムが動作している。
【００４２】
Serviceは、画面を表示する機能を持たずに、バックグラウンドで処理を実行するコンポーネントである。例えば、ユーザが音楽を聞きながらブラウザを起動してインターネットの利用を楽しむ場合、音楽用アプリケーションがServiceを起動することにより、ユーザはインターネットの利用中に音楽を聞くことができる。
【００４３】
BroadcastReceiverは、Android（登録商標）が搭載された端末装置のシステム全体にブロードキャストされるINTENT（インテント）を受け取るコンポーネントである。例えば、電池残量が減ってきたときに、「残りのバッテリー残量が少ないです」というメッセージを含む画面を表示するアプリケーションでは、電池残量が変化するときに発行されるBroadcastIntentをBroadcastReceiverにより受け取ったアプリケーションがActivityを起動して画面を表示する。
【００４４】
ContentProviderは、アプリケーションが保持するデータを他のコンポーネントでも使用可能にするコンポーネントである。例えば、あるアプリケーションが電話帳のデータを取得したい場合、そのアプリケーションは、電話帳アプリケーションのContentProviderを利用して、電話帳に登録されている情報を取得する。
【００４５】
本実施形態の通知部１７および格納処理部１８はActivityで構成されている。Android（登録商標）のアプリケーションフレームワークで提供されているAlertDialogクラスのメソッド（API）を利用することで、アラートダイアログと呼ばれるダイアログを簡易に表示することができる。しかし、アプリケーション１０がAPI１１ａを実行しようとしたときにAPI実行部１１がAlertDialogクラスのメソッドを呼び出してアラートダイアログを表示するようにした場合、以下の課題がある。
【００４６】
Android（登録商標）の仕様では、アプリケーション１０がActivityによって動作し、API１１ａを呼び出して実行しようとする場合にはアラートダイアログを表示することができるが、アプリケーション１０がServiceによって動作し、API１１ａを呼び出して実行しようとする場合にはアラートダイアログを表示することはできない。本実施形態では、画面表示を行う機能を備えているActivityで構成されている通知部１７が画面表示を行うことによって、アプリケーション１０がServiceによって動作する場合でも、ユーザに通知を行うことができる。
【００４７】
次に、本実施形態の端末装置の動作を説明する。アプリケーション１０がAPI１１ａを呼び出すと、API実行部１１は、API１１ａが呼び出されたことを検出してAPI１１ａの実行に介入する（API１１ａをフックする）。
【００４８】
図２は、フックの対象となるAPIの一覧を示している。本実施形態では、TelephonyManagerクラス、LocationManagerクラス、PackageManagerServiceクラス、ContextImpleクラス、SmsManagerクラス、ContentResolverクラスのAPIがフックの対象となる。なお、図２に示すAPIは一例であり、これに限らない。APIはメソッドであるが、本実施形態で注目するメソッドを他のメソッドと区別するため、図２に示すメソッドをAPIと記載している。
【００４９】
TelephonyManagerクラスのAPIでフックの対象となるのは、端末を識別するIDであるIMEI（International Mobile Equipment Identity）を取得するgetDeviceIdや、端末のアプリケーションのバージョンを取得するgetDeviceSoftwareVersion、端末の電話番号を取得するgetLine1Number、SIM （Subscriber Identity Module）のシリアル番号を取得するgetSimSerialNumber、SIMの固有番号であるIMSI（International Mobile Subscriber Identity）を取得するgetSubscriberIdである。
【００５０】
LocationManagerクラスのAPIでフックの対象となるのは、位置情報を取得するgetLastKnownLocation、LocationListener、requestLocationUpdatesである。PackageManagerServiceクラスのAPIでフックの対象となるのは、アプリケーションに適切なパーミッションが付与されているか否かを判定するCheckUidPermissionである。ContextImpleクラスのAPIでフックの対象となるのは、端末にインストールされているアプリケーションの一覧を示す情報を取得するgetInstallPackagesである。
【００５１】
SmsManagerクラスのAPIでフックの対象となるのは、SMSによりメッセージを送信するsendTextMessageである。ContentResolverクラスのAPIでフックの対象となるのは、メモリ内のデータベースにアクセスして情報を取得するCursorである。
【００５２】
本実施形態では、TelephonyManagerクラスおよびLocationManagerクラスの各APIを情報取得APIと記載し、PackageManagerServiceクラスのCheckUidPermissionをパーミッション判定APIと記載する。また、本実施形態では、ContextImpleクラスのgetInstallPackagesを一覧取得APIと記載し、SmsManagerクラスのsendTextMessageを外部送信APIと記載し、ContentResolverクラスのCursorをデータベース参照APIと記載する。
【００５３】
図１ではAPI実行部１１とAPI１１ａが１つだけ描かれているが、API実行部１１とAPI１１ａの組は複数（上記のAPI と同数）あるものとする。例えば、アプリケーション１０が情報取得APIを呼び出した場合、複数用意されているAPI１１ａのうち情報取得APIであるAPI１１ａの実行に関して、そのAPI１１ａに対応するAPI実行部１１が処理を行い、アプリケーション１０がパーミッション判定APIを呼び出した場合、複数用意されているAPI１１ａのうちパーミッション判定APIであるAPI１１ａの実行に関して、そのAPI１１ａに対応するAPI実行部１１が処理を行う。
【００５４】
アプリケーション１０が所定のAPI１１ａを呼び出したとき、API実行部１１は、図３に示す処理を実行する。まず、API実行部１１は、API１１ａを実行する前に情報取得部１２に処理を指示する（ステップＳ１００）。続いて、API実行部１１は、セキュリティポリシー判定部１３または実行制御部１６から処理結果を受け取り、その処理結果に応じた処理を実行することによりAPI１１ａの実行を制御する（ステップＳ１０５）。ステップＳ１０５で行われる処理の詳細については後述する。続いて、API実行部１１は実行結果をアプリケーション１０に返す（ステップＳ１１０）。
【００５５】
API実行部１１から指示を受けた情報取得部１２は、図４に示す処理を実行する。まず、情報取得部１２は、API１１ａを呼び出したアプリケーション１０のパッケージの名称（パッケージ名）を特定するため、ContextクラスのgetPackageNameメソッドを実行し、パッケージ名を取得する（ステップＳ２００）。Android（登録商標）では、パッケージファイルの形式でアプリケーションが公開されている。パッケージファイルは、例えば拡張子が.apkのファイルであり、命令列を含む実行コード（例えば拡張子が.dex）、アプリケーションが利用する権限が定義されたマニフェストファイル（例えば拡張子が.xml）、アプリケーションが利用する画像ファイル（例えば拡張子が.jpg）等を含む。
【００５６】
続いて、情報取得部１２は、API１１ａがどのような状況で実行されるのかを解析するため、SystemクラスのcurrentMillisメソッドを実行し、API１１ａが呼び出された時刻を取得すると共に、Throwable クラスのgetStacktraceメソッドを実行し、クラス名、メソッド名、ファイル名、行番号が格納されたStackTraceElementクラスの配列を取得する（ステップＳ２０５）。
【００５７】
ステップＳ２０５で取得される配列に格納されているクラス名は、APIを呼び出したメソッドを定義するクラスの名称である。クラス名は、StackTraceElementクラスのgetClassNameメソッドを実行することで取得される。ステップＳ２０５で取得される配列に格納されているメソッド名は、APIを呼び出したメソッドの名称である。メソッド名は、StackTraceElementクラスのgetMethodNameメソッドを実行することで取得される。ステップＳ２０５で取得される配列に格納されているファイル名は、APIを呼び出したメソッドを実行するコードが記述されたソースファイルの名称である。ファイル名は、StackTraceElementクラスのgetFileNameメソッドを実行することで取得される。ステップＳ２０５で取得される配列に格納されている行番号は、APIを呼び出したメソッドを実行するコードが記述されたソースファイル内の行番号である。行番号は、StackTraceElementクラスのgetLineNumberメソッドを実行することで取得される。
【００５８】
メソッドが呼び出される毎に、そのメソッドの情報はメモリ内のスタック領域（スタックフレーム）にスタックトレースとして保存される。上記のgetClassNameメソッド等の各メソッドによって、スタックトレースからクラス名等の情報が取得される。
【００５９】
続いて、情報取得部１２はセキュリティポリシー判定部１３に処理を指示する（ステップＳ２１０）。このとき、情報取得部１２は、ステップＳ２００，Ｓ２０５で取得した情報をセキュリティポリシー判定部１３に与える。
【００６０】
情報取得部１２から指示を受けたセキュリティポリシー判定部１３は、図５に示す処理を実行する。まず、セキュリティポリシー判定部１３は、情報取得部１２から与えられた情報（情報取得部１２がステップＳ２００，Ｓ２０５で取得した情報）をコンテキストデータＣＤとして、記憶部１９内のセキュリティデータＳＤの記憶領域に格納する（ステップＳ３００）。
【００６１】
図６は、情報取得部１２がステップＳ２０５で取得した情報のうち、API１１ａが呼び出された時刻を除く情報の一例を示している。図６では、便宜上、１つのメソッド（API）の情報が４行に分かれて記載されており、各行の先頭には行番号が付与されている。図６の４行単位の情報によって１つの情報群が構成される。１〜４行目の情報で構成される情報群ｓｔ［０］は、呼び出されたAPI１１ａの情報を含む。４行目の「getMethodName()=」に続く文字列「getDeviceId」はAPI１１ａのメソッド名を示している。
【００６２】
５〜８行目の情報で構成される情報群ｓｔ［１］は、API１１ａ（getDeviceId）を呼び出したメソッドの情報を含む。５行目の「getClassName()=」に続く文字列「jp.sample.app.Sample」は、API１１ａを呼び出したメソッドが定義されているクラスの名称（クラス名）を示している。クラス名は、パッケージ名とクラス単体の名称との組合せとして示されている。例えば、５行目に記載されている「jp.sample.app.Sample」の「jp.sample.app」がパッケージ名であり、「Sample」がクラス単体の名称である。６行目の「getFileName()=」に続く文字列「Sample.*jv*」は、API１１ａを呼び出したメソッドを実行するコードが記述されたソースファイルの名称（ファイル名）である。７行目の「getLineNumber()=」に続く数字２７は、API１１ａを呼び出したメソッドを実行するコードが記述されたソースファイル内の行番号を示している。８行目の「getMethodName()=」に続く文字列「onCreate」は、API１１ａを呼び出したメソッドの名称（メソッド名）を示している。
【００６３】
情報群ｓｔ［１］が示すファイル名に対応するソースファイルは、API１１ａを呼び出したアプリケーション１０のソースファイルである。つまり、情報群ｓｔ［１］に含まれる情報は、API１１ａを呼び出したアプリケーション１０のソースファイルで記述されているメソッドの情報である。
【００６４】
図７は、API１１ａを呼び出したメソッドが記述されたソースコードの一例を示している。このソースコードは、情報群ｓｔ［１］に含まれる「Sample.*jv*」がファイル名であるソースファイルに記載されているコードである。このソースコードにおいて、Sampleクラス（情報群ｓｔ［１］に含まれる「jp.sample.app.Sample」に対応）で定義されているonCreateメソッド（情報群ｓｔ［１］に含まれる「onCreate」に対応）内で、情報群ｓｔ［０］が示すgetDeviceIdメソッド（API１１ａ）が呼び出されている。また、getDeviceIdメソッドを呼び出すコードは、情報群ｓｔ［１］に含まれる行番号に対応する２７行目に記載されている。
【００６５】
図６の９〜１２行目の情報で構成される情報群ｓｔ［２］は、情報群ｓｔ［１］が示すonCreateメソッドを呼び出したメソッドの情報を含む。９行目の「getClassName()=」に続く文字列「*andrd*.app.ActivityThread」は、onCreateメソッドを呼び出したメソッドが定義されているクラスの名称（クラス名）を示している。９行目に記載されている「*andrd*.app.ActivityThread」の「*andrd*.app」がパッケージ名であり、「ActivityThread」がクラス単体の名称である。１０行目の「getFileName()=」に続く文字列「ActivityThread.*jv*」は、onCreateメソッドを呼び出したメソッドを実行するコードが記述されたソースファイルの名称（ファイル名）である。１１行目の「getLineNumber()=」に続く数字１９４５は、onCreateメソッドを呼び出したメソッドを実行するコードが記述されたソースファイル内の行番号を示している。１２行目の「getMethodName()=」に続く文字列「handleCreateService」は、onCreateメソッドを呼び出したメソッドの名称（メソッド名）を示している。
【００６６】
図８は、onCreateメソッドを呼び出したメソッドが記述されたソースコードの一例を示している。このソースコードは、情報群ｓｔ［２］に含まれる「ActivityThread.*jv*」がファイル名であるソースファイルに記載されているコードである。このソースコードにおいて、ActivityThreadクラス（情報群ｓｔ［２］に含まれる「*andrd*.app.ActivityThread」に対応）で定義されているhandleCreateServiceメソッド（情報群ｓｔ［２］に含まれる「handleCreateService」に対応）内で、情報群ｓｔ［１］が示すonCreateメソッドが呼び出されている。また、onCreateメソッドを呼び出すコードは、情報群ｓｔ［２］に含まれる行番号に対応する１９４５行目に記載されている。
【００６７】
上記のように、情報群ｓｔ［ｎ＋１］の情報は、情報群ｓｔ［ｎ］（ｎは０以上の整数）が示すメソッド（API）を呼び出したメソッドの情報を含む。図６の情報群ｓｔ［３］〜ｓｔ［７］も同様である。なお、図６では、情報群ｓｔ［７］が示すメソッドを呼び出したメソッド等の情報は省略されている。図６に示す情報と、API１１ａが呼び出された時刻と、情報取得部１２がステップＳ２００で取得したパッケージ名との組合せがコンテキストデータＣＤとして保存される。
【００６８】
本実施形態では、アプリケーション１０からAPI１１ａが呼び出される毎に１つのコンテキストデータＣＤが生成され、保存される。例えば、第１のAPIが呼び出された後、第２のAPIが呼び出される場合、第１のAPIが呼び出されたときに第１のAPIに関するコンテキストデータＣＤが生成されて保存され、その後、第２のAPIが呼び出されたときに第２のAPIに関するコンテキストデータＣＤが生成されて保存される。
【００６９】
それぞれのコンテキストデータＣＤは、コンテキストデータＣＤに含まれる時刻によって区別される。あるいは、それぞれのコンテキストデータＣＤにシーケンス番号等のIDを付与し、そのIDによってそれぞれのコンテキストデータＣＤを区別してもよい。それぞれのコンテキストデータＣＤは、上記の情報群のうち複数の情報群（例えば情報群ｓｔ［０］，ｓｔ［１］，ｓｔ［２］）の情報を含む。コンテキストデータＣＤには、それぞれの情報群を識別する識別情報（例えば、ｓｔ［０］等の文字列）が含まれており、この識別情報によって各情報群が区別される。
【００７０】
情報取得部１２から与えられた情報をコンテキストデータＣＤとして保存した後、セキュリティポリシー判定部１３は記憶部１９内のセキュリティデータＳＤの記憶領域からセキュリティポリシーＳＰを読み出す（ステップＳ３０５）。続いて、セキュリティポリシー判定部１３は、呼び出されたAPI１１ａに関する情報がセキュリティポリシーＳＰに登録されているか否かを判定する（ステップＳ３１０）。
【００７１】
セキュリティポリシーＳＰには、API１１ａの実行制御情報と、パッケージ名と、コンテキストデータＣＤに含まれる情報群ｓｔ［１］のクラス名、メソッド名、行番号とを一組とした情報が登録される。セキュリティポリシーＳＰには、この一組の情報を登録の単位として複数組登録することが可能である。後述するように、格納処理部１８によって、セキュリティポリシーＳＰに対する情報の登録が行われる。
【００７２】
API１１ａの実行制御情報は、APIの実行の許可、APIの実行の拒否、ダミー情報の利用のいずれかを示す情報である。ダミー情報とは、API１１ａとして情報取得APIがアプリケーション１０によって呼び出された場合に、アプリケーション１０に対して返答する虚偽の情報である。例えば、位置情報を取得するAPI１１ａが呼び出された場合、端末装置の現在の位置と異なる位置の情報がダミー情報としてアプリケーション１０に対して返答される。
【００７３】
情報取得部１２から与えられた情報の一部（パッケージ名、コンテキストデータＣＤに含まれる情報群Ｓｔ［１］のクラス名、メソッド名、行番号）が、セキュリティポリシーＳＰに登録されている一組の情報（パッケージ名、クラス名、メソッド名、行番号）のいずれかと完全に一致した場合、呼び出されたAPI１１ａに関する情報がセキュリティポリシーＳＰに登録されている。また、情報取得部１２から与えられた情報の一部（パッケージ名、コンテキストデータＣＤに含まれる情報群Ｓｔ［１］のクラス名、メソッド名、行番号）が、セキュリティポリシーＳＰに登録されている一組の情報（パッケージ名、クラス名、メソッド名、行番号）のいずれとも一致しなかった場合、呼び出されたAPI１１ａに関する情報はセキュリティポリシーＳＰに登録されていない。
【００７４】
呼び出されたAPI１１ａに関する情報がセキュリティポリシーＳＰに登録されている場合、セキュリティポリシー判定部１３は、呼び出されたAPI１１ａに関してセキュリティポリシーＳＰに登録されている実行制御情報がダミー情報の利用を示しているか否かを判定する（ステップＳ３１５）。実行制御情報がダミー情報の利用を示している場合、セキュリティポリシー判定部１３は、API１１ａにダミー情報を利用させることを示す情報をAPI実行部１１に与える（ステップＳ３２０）。API実行部１１は、セキュリティポリシー判定部１３から与えられた情報に基づいて処理を実行する（図３のステップＳ１０５）。このとき、API実行部１１は、例えばダミー情報の格納場所として予め決められている場所から情報を読み出すAPIを実行してダミー情報を取得する。
【００７５】
実行制御情報がダミー情報の利用を示していない場合、セキュリティポリシー判定部１３は、実行制御情報がAPIの実行の許可を示しているか否かを判定する（ステップＳ３３０）。実行制御情報がAPIの実行の許可を示している場合、セキュリティポリシー判定部１３は、API１１ａの実行を許可することを示す情報をAPI実行部１１に与える（ステップＳ３３５）。API実行部１１は、セキュリティポリシー判定部１３から与えられた情報に基づいてAPI１１ａに処理を実行させる（図３のステップＳ１０５）。
【００７６】
また、実行制御情報がAPIの実行の許可を示していない場合、実行制御情報はAPIの実行の拒否を示している。この場合、セキュリティポリシー判定部１３は、API１１ａの実行を拒否することを示す情報をAPI実行部１１に与える（ステップＳ３４０）。API実行部１１は、セキュリティポリシー判定部１３から与えられた情報に基づいてAPI１１ａの処理を中止する（図３のステップＳ１０５）。
【００７７】
ステップＳ３１０において、呼び出されたAPI１１ａに関する情報がセキュリティポリシーＳＰに登録されていない場合、セキュリティポリシー判定部１３はソケット生成部１４に処理を指示する（ステップＳ３２５）。
【００７８】
本実施形態のセキュリティポリシーＳＰでは、メソッド名だけでなく、パッケージ名、クラス名、行番号が実行制御情報と関連付けられている。これによって、どのアプリケーションからAPI１１ａが呼び出されたのか、どのクラスで定義されているメソッドからAPI１１ａが呼び出されたのか、ソースファイル中のどの位置で記述されたメソッドからAPI１１ａが呼び出されたのかといった、API１１ａが実行される際の詳細な状況に応じて、API１１ａの実行を制御することができる。
【００７９】
セキュリティポリシー判定部１３から指示を受けたソケット生成部１４は、図９に示す処理を実行する。まず、ソケット生成部１４は、入力部２０を介してユーザによって入力される情報を格納するためのソケットＳＫを生成する（ステップＳ４００）。一例として、LocalServerSocketクラスのインスタンスを初期化する際にString型の名前を与えることでUnix（登録商標）ドメインソケットを生成することができる。ソケットＳＫには記憶部１９の記憶領域が使用される。ソケットＳＫを生成したソケット生成部１４は、起動部１５に処理を指示する（ステップＳ４０５）。このとき、ソケット生成部１４は、生成したソケットＳＫを識別するアドレス情報を起動部１５に通知する。
【００８０】
ソケット生成部１４から指示を受けた起動部１５は、図１０に示す処理を実行する。まず、起動部１５は、記憶部１９内のセキュリティデータＳＤの記憶領域からコンテキストデータＣＤを読み出す（ステップＳ５００）。このとき読み出されるコンテキストデータＣＤは、直近（最後）に呼び出されたAPI１１ａに関するコンテキストデータＣＤである。コンテキストデータＣＤに含まれる時刻が最も新しいコンテキストデータＣＤが、直近に呼び出されたAPI１１ａに関するコンテキストデータＣＤである。あるいは、コンテキストデータＣＤ毎にシーケンス番号が付与される場合、そのシーケンス番号から、直近に呼び出されたAPI１１ａに関するコンテキストデータＣＤを識別してもよい。
【００８１】
続いて、起動部１５は、ソケット生成部１４から通知されたアドレス情報を含むActivityのインテントを発行し、通知部１７および格納処理部１８を起動する（ステップＳ５０５）。通知部１７および格納処理部１８を起動するためのインテントにソケットＳＫのアドレス情報が含まれるため、通知部１７および格納処理部１８に情報を効率的に通知することができる。続いて、起動部１５は、実行制御部１６に処理を指示する（ステップＳ５１０）。
【００８２】
起動した通知部１７は、図１１に示す処理を実行する。まず、通知部１７は、API１１ａが実行されようとしていることを示すメッセージを表示部２１に表示する（ステップＳ６００）。このとき、例えばポップアップウィンドウが表示され、そのポップアップウィンドウにメッセージが表示される。続いて、通知部１７は、格納処理部１８に処理を指示する（ステップＳ６０５）。
【００８３】
API１１ａを実行しようとしているアプリケーション１０の種類や実行対象のAPI１１ａの種類を明示的にユーザに通知するため、アプリケーション１０やAPI１１ａを識別する情報がメッセージに含まれていてもよい。この場合、例えば起動部１５が発行するインテントに、コンテキストデータＣＤに含まれるパッケージ名および情報群Ｓｔ［０］のメソッド名が含まれ、このパッケージ名およびメソッド名がメッセージと共に表示される。
【００８４】
図１２は、表示されるメッセージの一例を示している。表示部２１の画面にウィンドウ２１０が表示されている。ウィンドウ２１０では、API１１ａを実行しようとしているアプリケーション１０のパッケージ名（Maps）と、実行対象のAPI１１ａのメソッド名（requestLocationUpdates）とを含むメッセージが表示され、どのアプリケーション１０がどのAPI１１ａを実行しようとしているのかがユーザに通知される。
【００８５】
また、ウィンドウ２１０では、ユーザがAPIの実行の許可／拒否を選択するためのボタン２１１，２１２が表示されている。ユーザが入力部２０を用いてボタン２１１を操作した場合には、APIの実行の許可を示す情報が入力され、ユーザが入力部２０を用いてボタン２１２を操作した場合には、APIの実行の拒否を示す情報が入力される。図１２では、ダミー情報の利用の許可／拒否を選択するためのボタンは表示されていないが、表示してもよい。
【００８６】
また、ウィンドウ２１０では、入力された情報をセキュリティポリシーＳＰに登録するか否かをユーザが選択するためのチェックボックス２１３が表示されている。ユーザが入力部２０を用いてチェックボックス２１３にチェックを入れると、入力された情報がセキュリティポリシーＳＰに登録され、次に同じAPI１１ａが実行されるときにセキュリティポリシーＳＰに基づいてAPI１１ａの実行が制御される。
【００８７】
通知部１７から指示を受けた格納処理部１８は、図１３に示す処理を実行する。まず、格納処理部１８は、入力部２０を介して入力される情報の監視を開始する（ステップＳ７００）。通知部１７によってメッセージが表示された後、メッセージを確認したユーザによって入力部２０が操作され、APIの実行の許可、APIの実行の拒否、ダミー情報の利用のいずれかを示す情報が入力される。格納処理部１８は、入力部２０を介してユーザによって情報が入力されたか否かを判定する（ステップＳ７０５）。情報が入力されていない場合、格納処理部１８はステップＳ７０５の判定を繰り返す。
【００８８】
また、情報が入力された場合、格納処理部１８は、ユーザによって入力された、APIの実行の許可、APIの実行の拒否、ダミー情報の利用のいずれかを示す実行制御情報を、起動部１５が発行したインテントにより通知されたアドレス情報が示すソケットＳＫに格納する（ステップＳ７１０）。続いて、格納処理部１８は、セキュリティポリシーＳＰに情報を登録するか否かを判定する（ステップＳ７１５）。
【００８９】
セキュリティポリシーＳＰに情報を登録する指示がユーザによって入力されていない場合、格納処理部１８は処理を終了する。また、セキュリティポリシーＳＰに情報を登録する指示がユーザによって入力された場合、格納処理部１８は、記憶部１９のセキュリティデータＳＤの記憶領域から、直近に呼び出されたAPI１１ａに関するコンテキストデータＣＤを読み出す（ステップＳ７２０）。格納処理部１８は、読み出したコンテキストデータＣＤに含まれる情報のうち、パッケージ名と、情報群ｓｔ［１］のクラス名、メソッド名、行番号と、ユーザによって入力された、APIの実行の許可、APIの実行の拒否、ダミー情報の利用のいずれかを示す実行制御情報とを、セキュリティポリシーＳＰとして、記憶部１９内のセキュリティデータＳＤの記憶領域に格納する（ステップＳ７２５）。上記の処理の終了後、ユーザ通知部１７および格納処理部１８は動作を停止する。
【００９０】
起動部１５から指示を受けた実行制御部１６は、図１４に示す処理を実行する。まず、実行制御部１６はソケットＳＫの監視を開始する（ステップＳ８００）。続いて、実行制御部１６は、ソケットＳＫに実行制御情報が格納されたか否かを判定する（ステップＳ８０５）。ソケットＳＫに実行制御情報が格納されていない場合、実行制御部１６はステップＳ８０５の判定を繰り返す。
【００９１】
また、ソケットＳＫに実行制御情報が格納された場合、実行制御部１６はソケットＳＫから実行制御情報を読み出す（ステップＳ８１０）。続いて、実行制御部１６は、ソケットＳＫから読み出した実行制御情報がダミー情報の利用を示しているか否かを判定する（ステップＳ８１５）。実行制御情報がダミー情報の利用を示している場合、実行制御部１６は、API１１ａにダミー情報を利用させることを示す情報をAPI実行部１１に与える（ステップＳ８２０）。API実行部１１は、実行制御部１６から与えられた情報に基づいて処理を実行する（図３のステップＳ１０５）。このとき、API実行部１１は、例えばダミー情報の格納場所として予め決められている場所から情報を読み出すAPIを実行してダミー情報を取得する。
【００９２】
実行制御情報がダミー情報の利用を示していない場合、実行制御部１６は、実行制御情報がAPIの実行の許可を示しているか否かを判定する（ステップＳ８２５）。実行制御情報がAPIの実行の許可を示している場合、実行制御部１６は、API１１ａの実行を許可することを示す情報をAPI実行部１１に与える（ステップＳ８３０）。API実行部１１は、実行制御部１６から与えられた情報に基づいてAPI１１ａに処理を実行させる（図３のステップＳ１０５）。
【００９３】
また、実行制御情報がAPIの実行の許可を示していない場合、実行制御情報はAPIの実行の拒否を示している。この場合、実行制御部１６は、API１１ａの実行を拒否することを示す情報をAPI実行部１１に与える（ステップＳ８３５）。API実行部１１は、実行制御部１６から与えられた情報に基づいてAPI１１ａの処理を中止する（図３のステップＳ１０５）。
【００９４】
上記のように、API実行制御部３０は、アプリケーション１０が所定のAPI１１ａを実行しようとするときにユーザに通知を行い、入力部２０を介してユーザによって入力される情報に基づいて、API１１ａの実行を制御する。これによって、パーミッションを必要とする動作時等にユーザがアプリケーションの動作を事前に把握し、アプリケーションの動作を制御することができる。また、API実行制御部３０は、同じアプリケーション１０によって所定のAPI１１ａが再度呼び出されるときには、セキュリティポリシーＳＰに登録されている実行制御情報に基づいて、API１１ａの実行を制御する。これによって、ユーザにとって手間となりうる確認の作業を省略することができる。
【００９５】
次に、本実施形態で用いる要素技術のうち、上記で説明していない他の要素技術の内容を説明する。
【００９６】
前述したように、本実施形態で制御の対象とするAPIを定義するクラス（TelephonyManagerクラス等）のコードに対して、API実行部１１および情報取得部１２が実行する処理を規定するコードが追加されている。API実行部１１および情報取得部１２は、アプリケーション１０がAPI１１ａを呼び出したときにアプリケーション１０と同一のプロセスで処理を行う。
【００９７】
また、前述したように、アプリケーションフレームワークで提供されているPackageManagerServiceクラスのコードに対して、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６の各部が実行する処理を規定するコードが追加されている。これにより、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６の各部は同一のプロセスで処理を行う。また、前述したように、通知部１７、格納処理部１８が実行する処理を規定するコードを含むアプリケーションプログラムが用意されている。これにより、通知部１７および格納処理部１８は同一のプロセスで処理を行う。
【００９８】
Android（登録商標）では、通常、UID（User ID）と呼ばれる、プロセス毎に異なるIDがプロセスに与えられ、UIDが異なるプロセス間ではリソースを共有することができない。セキュリティデータＳＤを共有するため、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６、通知部１７、格納処理部１８には、同一のUIDが与えられ、これらの各部は同一のプロセスで処理を行う。
【００９９】
本実施形態では、アプリケーション１０が直接セキュリティデータＳＤにアクセスしてセキュリティデータＳＤの内容を改竄できないようにするため、アプリケーション１０のプロセスと、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６、通知部１７、格納処理部１８のプロセスとには、異なるUIDが与えられる。また、アプリケーション１０のプロセスにはセキュリティデータＳＤにアクセスできるパーミッションが与えられておらず、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６、通知部１７、格納処理部１８のプロセスにはセキュリティデータＳＤにアクセスできるパーミッションが与えられている。上記によって、セキュリティデータＳＤの安全性を高めることができる。
【０１００】
上記のように同一のUIDを与える仕組みとして、sharedUserIdという仕組みがある。通知部１７、格納処理部１８の機能を実現するアプリケーションのパッケージファイルが生成される際に、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６の機能を実現するPackageManagerServiceクラスのコードで使用されているUIDと同一のUIDを使用するsharedUserIdのコードが、アプリケーションのソースファイルに含まれるマニフェストファイルに記述される。
【０１０１】
続いて、PackageManagerServiceクラスのコードのアセンブル（コンパイル）時に使用される鍵（プラットフォームキー）と同一の鍵を用いて、アプリケーションの全てのソースファイルに署名を施した後、アセンブルを行い、パッケージファイルを生成する。これによって、通知部１７および格納処理部１８に対して、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６に与えられるUIDと同一のUIDを与えることができる。したがって、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６、通知部１７、格納処理部１８は同一のプロセスで処理を行い、セキュリティデータＳＤを共有することができる。また、ソケットＳＫも共有することができる。
【０１０２】
本実施形態では、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６は、端末装置の起動後、バックグラウンドで動作する。したがって、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６は、アプリケーション１０の動作中でもバックグラウンドで動作している。
【０１０３】
アプリケーション１０によって呼び出されたAPI１１ａに関する情報がセキュリティポリシーＳＰに登録されている場合、ユーザによる確認が行われることなく、セキュリティポリシーＳＰに登録されている実行制御情報に基づいて、API１１ａの実行が制御される。これによって、アプリケーション１０による処理が中断する時間を短くし、処理速度が向上する。また、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６がバックグラウンドで動作することによって、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６の起動に必要な時間を省略することができるため、処理速度がより向上する。
【０１０４】
次に、本実施形態で制御の対象とする各APIに対して上記の制御を適用した例を説明する。
【０１０５】
（１）情報取得APIへの適用
従来、アプリケーションが情報を利用する動作をパーミッションにより完全には制御できないという課題がある。例えば、端末内の情報の取得に関するパーミッションであるREAD_PHONE_STATEは、IMEIや、電話番号、IMSI等の様々な情報へのアクセスを制限している。ユーザにとって、自身の電話番号がアプリケーションの開発者に知られるのは怖いので電話番号へのアクセスを許可しないが、IMEIへのアクセスを許可しても良いというケースが考えられる。しかしながら、パーミッションに基づいてアプリケーションの動作に制限を与える機構では、各情報へのアクセスを個別に制御する仕組みがない。また、インストールされているアプリケーションの一覧等の情報へのアクセスにはパーミッションによる制限がなく、制御を行えない情報も存在する。本実施形態で説明した制御を、IMEIを取得するAPIであるgetDeviceId等の各情報取得APIに対して個別に適用することにより、端末に格納されている情報毎に利用を制限することができる。
【０１０６】
（２）パーミッション判定APIへの適用
実行にパーミッションが必要なAPIをアプリケーションが実行する際、OSは、アプリケーションが適切なパーミッションを有しているか否かを判定する。具体的には、パーミッション判定API であるCheckUidPermissionが実行され、アプリケーションが適切なパーミッションを有しているか否かの判定が行われる。本実施形態で説明した制御をCheckUidPermissionに対して適用することにより、パーミッションが必要なアプリケーションの動作をユーザが制御することができる。
【０１０７】
（３）一覧取得APIへの適用
端末にインストールされているアプリケーションの一覧を示す情報を取得するAPIであるgetInstallPackagesにはパーミッションによる制限が設けられていない。このように、パーミッションによる制限がないAPIの実行を制限したい場合に、本実施形態で説明した制御を適用すればよい。本実施形態で説明した制御をgetInstallPackagesに対して適用することにより、アプリケーションが、端末にインストールされているアプリケーションの一覧を示す情報を取得する動作をユーザが制御することができる。
【０１０８】
（４）外部送信APIへの適用
本実施形態で説明した制御を、外部送信API であるsendTextMessageに対して適用することにより、SMSクライアントアプリケーションが正規の振る舞いをしつつ、ユーザの意図とは無関係にバックグラウンドで不正に外部へ情報を送信しようとする場合でも、情報漏洩に繋がる可能性がある動作が行われようとしていることをユーザが知ることができる。また、ユーザが誤って、メッセージを送信するボタンを押した場合でも、送信動作を行うかどうかを確認するためのメッセージが表示されるので、ユーザは、誤操作を行った場合には送信動作を中止することができる。
【０１０９】
（５）データベース参照APIへの適用
電話帳（アドレス帳）や通話履歴等の情報は、コンテンツプロバイダと呼ばれるデータベースで管理されている。アプリケーションは、コンテンツプロバイダから情報を取得する場合、データベース参照APIであるCursorの引数に、データベース内のアクセス先（データベース参照APIがアクセスするデータベース内の位置）を示す、URIと呼ばれる情報を指定する。アクセス先の情報毎に引数が異なる。
【０１１０】
図１５は、Cursorの引数の一例を示している。com.*andrd*.contactcontactsは、電話帳へのアクセスの際に指定される引数である。call_logは、通話履歴へのアクセスの際に指定される引数である。browserは、ブックマークへのアクセスの際に指定される引数である。smsは、SMSメッセージ本文へのアクセスの際に指定される引数である。com.*andrd*.calendarは、カレンダーへのアクセスの際に指定される引数である。本実施形態で説明した制御を、Cursorで指定される引数毎に適用することにより、データベースに格納されている情報毎に利用を制限することができる。
【０１１１】
図１６は、Cursorに対応したAPI実行部１１の動作を示している。まず、API実行部１１は、Cursorの引数に指定された情報の内容を確認する（ステップＳ９００）。続いて、API実行部１１は、指定された引数がcom.*andrd*.contactcontactsであるか否か、すなわち電話帳へのアクセスが要求されているか否かを判定する（ステップＳ９０５）。指定された引数がcom.*andrd*.contactcontactsである場合、処理はステップＳ９１０に進む。
【０１１２】
また、指定された引数がcom.*andrd*.contactcontactsでない場合、API実行部１１は、指定された引数がcall_logであるか否か、すなわち通話履歴へのアクセスが要求されているか否かを判定する（ステップＳ９２５）。指定された引数がcall_logである場合、処理はステップＳ９１０に進む。
【０１１３】
また、指定された引数がcall_logでない場合、API実行部１１は、指定された引数がbrowserであるか否か、すなわちブックマークへのアクセスが要求されているか否かを判定する（ステップＳ９３０）。指定された引数がbrowserである場合、処理はステップＳ９１０に進む。
【０１１４】
また、指定された引数がbrowserでない場合、API実行部１１は、指定された引数がsmsであるか否か、すなわちSMSメッセージの本文へのアクセスが要求されているか否かを判定する（ステップＳ９３５）。指定された引数がsmsである場合、処理はステップＳ９１０に進む。
【０１１５】
また、指定された引数がsmsでない場合、API実行部１１は、指定された引数がcom.*andrd*.contactcontactsであるか否か、すなわちカレンダーへのアクセスが要求されているか否かを判定する（ステップＳ９４０）。指定された引数がcom.*andrd*.contactcontactsである場合、処理はステップＳ９１０に進む。また、指定された引数がcom.*andrd*.contactcontactsでない場合、処理はステップＳ９４５に進む。
【０１１６】
処理がステップＳ９１０に進んだ場合、API実行部１１は、API１１ａを実行する前に情報取得部１２に処理を指示する（ステップＳ９１０）。続いて、API実行部１１は、セキュリティポリシー判定部１３または実行制御部１６から処理結果を受け取り、その処理結果に応じた処理を実行することによりAPI１１ａの実行を制御する（ステップＳ９１５）。続いて、API実行部１１は実行結果をアプリケーション１０に返す（ステップＳ９２０）。
【０１１７】
処理がステップＳ９４５に進んだ場合、API実行部１１はAPI１１ａに処理を実行させる（ステップＳ９４５）。続いて、API実行部１１は実行結果をアプリケーション１０に返す（ステップＳ９２０）。
【０１１８】
上述したように、本実施形態によれば、アプリケーションがAPIを実行しようとする動作が検出された場合に、ユーザに通知が行われ、ユーザによって入力された情報に基づいて、APIの実行が制御される。これによって、ユーザがアプリケーションの動作を事前に把握し、アプリケーションの動作を制御することができる。
【０１１９】
また、セキュリティポリシーＳＰに登録されている実行制御情報に基づいてAPIの実行が制御される。これによって、ユーザにとって手間となりうる確認の作業が頻繁に行われることを防止することができる。
【０１２０】
また、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６と、通知部１７および格納処理部１８とに同一のUIDが与えられている。これによって、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６、通知部１７、格納処理部１８が同一のプロセスで処理を行い、セキュリティデータＳＤを共有することができる。
【０１２１】
また、アプリケーション１０と、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６、通知部１７、格納処理部１８とに異なるUIDが与えられている。さらに、アプリケーション１０のプロセスにはセキュリティデータＳＤにアクセスできる権限（パーミッション）が与えられず、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６、通知部１７、格納処理部１８のプロセスにはセキュリティデータＳＤにアクセスできる権限（パーミッション）が与えられている。これによって、アプリケーション１０がセキュリティデータＳＤにアクセスすることを防止することができる。
【０１２２】
また、セキュリティポリシー判定部１３、ソケット生成部１４、起動部１５、実行制御部１６がバックグラウンドで動作することによって、処理速度が向上する。
【０１２３】
また、データベース参照APIの引数に応じてAPIの実行を制御することによって、データベースに格納されている情報毎に利用を制限することができる。
【０１２４】
また、Activityで構成されている通知部１７がユーザに通知を行うことによって、アプリケーション１０がServiceによって動作する場合でも、ユーザに通知を行うことができる。
【０１２５】
また、通知部１７および格納処理部１８を起動するために起動部１５が発行するインテントにソケットＳＫのアドレス情報が含まれるため、通知部１７および格納処理部１８に情報を効率的に通知することができる。
【０１２６】
以上、図面を参照して本発明の実施形態について詳述してきたが、具体的な構成は上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【符号の説明】
【０１２７】
１０・・・アプリケーション、１１・・・API実行部（検出部）、１２・・・情報取得部、１３・・・セキュリティポリシー判定部、１４・・・ソケット生成部、１５・・・起動部、１６・・・実行制御部（制御部）、１７・・・通知部、１８・・・格納処理部、１９・・・記憶部、２０・・・入力部、２１・・・表示部、２２・・・通信部、３０・・・API実行制御部
【図１】
2013182500.tif 000003
【図２】
2013182500.tif 000004
【図３】
2013182500.tif 000005
【図４】
2013182500.tif 000006
【図５】
2013182500.tif 000007
【図６】
2013182500.tif 000008
【図７】
2013182500.tif 000009
【図８】
2013182500.tif 000010
【図９】
2013182500.tif 000011
【図１０】
2013182500.tif 000012
【図１１】
2013182500.tif 000013
【図１２】
2013182500.tif 000014
【図１３】
2013182500.tif 000015
【図１４】
2013182500.tif 000016
【図１５】
2013182500.tif 000017
【図１６】
2013182500.tif 000018