138
-Android アプリケーション利用の安全性を高めるアプリケーション動作の「見える化」
林 里香†
後藤 厚宏†
†情報セキュリティ大学院大学 221-0835 神奈川県横浜市神奈川区鶴屋町 2-14-1 [email protected], [email protected] あらまし ユーザの意図しない動作をするAndroidアプリケーション（ここでは，これを“怪しいアプリ ケーション”と呼ぶ）が問題になっている．現状，怪しいアプリケーションを排除するためにユーザが できることは，ダウンロード時にアプリケーションが要求する権限をチェックすることのみであり，イン ストール後に怪しいアプリケーションを見分ける手段は提供されていない．この必要性とアプリケー ション動作の「見える化」について検討し，注意すべき動作が生じたことをリアルタイムにユーザに 通知する機能，注意すべき動作の履歴をユーザに提示する機能の追加を提案する．プロトタイプを 作成し，インストール後に怪しいアプリケーションを見分ける手段として有効であることを示す．Android Security Improvement by Visualization of Application Behavior
Rika Hayashi† Atsuhiro Goto† †Institute of Information Security
2-14-1 Tsuruya-cho, Kanagawa-ward, Yokohama 221-0835, JAPAN [email protected], [email protected]
Abstract Android applications which work out of users’ intention, “suspicious application”, are becoming from “annoying” to “threats”. However, it is very difficult for uses to exclude such suspicious applications because users can only verify the permissions required by those applications at installation. Therefore, it is necessary to provide users with information to judge suspicious applications even after installing them. Here, we propose the way to show users application behavior with two features. One is to inform application’s noteworthy behavior to users on the spot, and another is to show users the brief history of application’s noteworthy behavior. We’ve been developing an evaluation system and show that it is effective to add those features to judge suspicious applications after installing them.
1 はじめに
ユーザの意図しない動作をする Android ア プリケーションの存在がしばしば取り沙汰され， 安全性の確保が問題となっている． Android フォンの安全性を確保するための 対策には，端末内の情報の保管や情報へのア クセスを安全にしようとする対策，OS やハード ウェアを安全にしようとする対策，アプリケーシ ョン開発段階での脆弱性の作り込みを防止しよ うとする対策，提供するアプリケーションの安全 性を高めようとする対策，端末外部との通信を 安全にしようとする対策など，様々なアプローチ がある．これらは互いに競合するものではなく， 層状に重なることで，全体の安全性が高まって いく．本稿では，アプリケーション利用の安全性 向上という面から，安全性確保に寄与するため のシステムを提案する．提案システムは，アプ リケーション動作を「見える化」し，ユーザがア プリケーションの安全性／危険性を判断するた めの材料を提供する．安全性確保において，ユ ーザ自身が関わることができる割合を増やすこ とは，重要な要素である．139
2 Android アプリケーションの特徴
Android は，オープンソースのソフトウェアで ある．アプリケーションの開発環境は無償で提 供されており，豊富な API が用意されている． 開発者は，API を用いることで，端末の情報， 連絡先，位置情報等のセンシティブな情報を容 易に取得することができる．また，公式マーケッ トにおけるアプリケーションの公開・配布の敷居 も低い．このオープンな性質はAndroid の魅力 の一つであるが，一方で，怪しいアプリケーショ ンも多数存在する． その中には，開発者の故意によるものもあれ ば，意図せずに作りこまれたものもある．また， アプリケーション自体が怪しい動作をするもの もあれば，SDK (Software Development Kit) のような形で提供され，アプリケーションに組み 込まれたモジュールが怪しい動作をするものも ある．モジュールとして代表的なものには，広 告表示機能（Ad library）がある． Michael らの調査[1]によると，Android 端末 向けの10 万個のアプリケーションを調査した結 果，52,067 個のアプリケーションに Ad library が含まれており，48,139 個には，ユーザの位 置情報を取得する機能を持つAd library が含 まれていたとされている．また，位置情報の取 得だけでなく，電話帳の情報を取得する機能を 持つもの，外部サーバからコードをダウンロー ドして実行する機能を持つもの等も報告されて いる．3 Android のセキュリティ課題
Android では，セキュリティ機構として，サン ドボックス実行環境と，パーミッション機構が提 供されている． これにより，アプリケーションは，自分以外が 作成したファイルの読み書き，他のアプリケー ションへのアクセス，ネットワークアクセスや位 置情報の取得など特定の機能の利用を制限さ れている． アプリケーションがデフォルトで制限されてい る端末内の情報や機能を利用するためには， “パーミッション”が必要になる．パーミッションを 付与されることで，アプリケーションはその範囲 において，制限されていた情報や機能の利用 が可能になる．ここで，制限やパーミッション付 与の単位がアプリケーションごとであることに注 意しておく． パーミッションは，アプリケーションの作成時 に開発者の判断で使用が宣言され，宣言され たパーミッションは，ダウンロード時（インストー ル時）に“アプリケーションが要求する権限”とし てユーザに提示される．ユーザがアプリケーシ ョンをインストールすると，“権限”を付与するこ とに同意したとみなされ，アプリケーションに宣 言されていたパーミッションが一括で付与され る．この仕組みにより，パーミッションの付与の 判断はユーザに委ねられているが，インストー ル前に実際の動作を把握することは困難であり， 意図しない位置情報の追跡や情報漏洩等の潜 在的な危険性を認識することは難しい．加えて， インストール後に，ユーザが，アプリケーション の動作を把握・制御する手段は提供されていな い．このため，一度アプリケーションが端末内に 入り込むと，ユーザの意図しない動作をしてい たとしても，ユーザがそれに気づき，利用に際 して注意を払ったり，アンインストールするとい った対策をとることは極めて難しい．4 アプリケーション利用の安全性確保に
向けた取り組み
4.1 端末内の情報・動作の分析 端末内の情報，端末内で行われる動作と動 作の要素，アプリケーション利用の安全性確保 のための既存技術を整理しておく（図 1）．情報 と動作は，Android に定義されているパーミッ ション[2]を参考に挙げ，それらを分析した．情 報は22 個，動作は 65 個挙がった． 情報は， ア. 窃取されると金銭的な被害につながる可 能性のあるもの 例．連絡先データ，アカウント情報 イ. プライバシーに関わるもの 例．位置情報，ブックマーク140 -図1 端末内の情報・動作とアプリケーション利用の安全性確保のための既存技術 ウ. 勝手に変更されると危険につながる可能 性のあるもの 例．連絡先データ，ブックマーク （意図しない宛先への強制的な接続） エ. 勝手に変更されると利用に支障をきたす可 能性のあるもの 例．スリープ設定，タイムゾーン のように分類した． 動作は，例として，連絡先データの読み取り， 連絡先データの変更，メールの送受信などがあ る．挙がった動作から，動作の要素を抽出した． 動作の要素は， a. 誰が（どのアプリケーションが） b. どの情報に対して c. どの動作を d. いつ e. どのくらいの時間（1 回の継続時間） f. どのくらいの頻度で g. 何に利用する目的で である． 本稿では，前述の情報ア，イに対する読み取 り，情報ウ，エに対する書き込み，外部ネットワ ークとの通信を「注意すべき動作」とする．そし て，「怪しい動作」を「注意すべき動作がユーザ の明確な意図とは別に実行されること」とし，そ のような動作をするアプリケーションを「怪しい アプリケーション」と呼ぶ． 前述のように，現状は，アプリケーションイン ストール後に，ユーザが怪しいアプリケーション に気付くための材料は提供されていない．そこ で，本稿では，ユーザが怪しいアプリケーション に気付くための材料として，アプリケーションが 注意すべき動作を実行する様子を「見える化」 し，ユーザに示すシステムを提案する． 4.2 既存技術と提案システム アプリケーション利用の安全性を確保するた めには，さまざまな技術が検討されている．例 えば，情報の盗み見を困難にする暗号化，情報 の安全な保管や信頼できないアプリケーション の動作を分離する端末内の仮想化[3][4]，端末 のシンクライアント化[5]，権限の管理やアクセ ス制御により，意図しない動作を防止する OS のセキュア化[6][7]やハードウェアのセキュア 化[8]などがある． 提案システムは，アプリケーションの OS や ハードウェアレベルでの動作ではなく，ユーザ 視点で把握できる動作に焦点を当てている．提 案システムは既存の技術と共存するものである が，これらが主に動作の安全性を確保すること を目的としているのに対し，提案システムは，そ もそもどのアプリケーションがどの程度安全／
141 危険であるかをユーザが判断するための材料 を提供することを目的としている．この目的の 違いにより，図 1 に示すように，既存の技術は 主に動作の要素a, b, c に注目し, システム寄り の対策となっているのに対し，提案システムは 動作の要素d, e, f に視野を広げ，ユーザ寄りの 対策となっている． 尚，「見える化」には，情報をわかりやすく伝 えるためのユーザインタフェースの改良という 視点もあるが，本稿では，ユーザが怪しい動作 を見分けられるようにするにはどのような情報 を提供すべきかという，素材の選択，収集に焦 点を当てる． 4.3 先行研究 アプリケーションインストール後に，アプリケ ーションの動作をユーザが把握できるようにす る仕組みとして，以下のような提案がされてい る． ユーザに動作情報を提示する仕組みとして は，端末内の重要情報を追跡し，重要情報が 端末外へ出た際にユーザに通知し，詳細情報 を提示する仕組み[9]が提案されている． この提案では，情報漏えいの検知に主眼が 置かれている．ユーザが重要情報の扱いにつ いて，怪しいアプリケーションに気付く材料とし ては有効である．ただし，動作が生じた際に通 知する機能はないため，どのタイミングでどの ような動作が生じたかを把握することが難しい． また，詳細情報の内容が一般的に読み解くに は難しい点，提示される情報が情報漏えいを検 知した時点ごとの単体の情報のみである点は 工夫する余地がある． アプリケーション動作時に，ユーザがその動 作を把握したり，動作に関わったりできるように する仕組みとしては，外部送信パケットの内容 により外部ネットワークへのパケットの送信可 否をユーザに問い合わせる仕組み[10]，任意 の時点でのパーミッションの項目ごとの付与／ 停止や，アプリケーションがパーミッションを利 用する際に，独自の制約を適用する仕組み [11]，アプリケーションがパーミッションで保護さ れている API を呼び出した際に，ユーザの意 志に従って動作の許可／拒否を可能にする仕 組み[12]，任意の時点でのパーミッションの付 与／停止に加えて，パーミッションが使われる 順序に注目して危険な動作をポリシーとして設 定しておき，アプリケーション動作時にそれと照 らし合わせて危険な動作をユーザに警告し，ユ ーザが動作を停止できる仕組み[13]が提案さ れている． アプリケーションの動作の把握の単位は，ユ ーザに提示した際に，ユーザがそれを見てアプ リケーションの動作を把握できるものにする必 要がある．この点において，パーミッション単位 の把握では，一つのパーミッションで許可され る動作が複数ある場合や，通常，パーミッション で制限されている動作ではないが，状況によっ ては注意すべき動作である場合もある．よって， より細かな把握をするには，メソッド単位で動作 を捕捉したほうが良い． また，先行研究での提案では，アプリケーシ ョンが何らかの動作を起こした時にその動作を 制御することに主眼が置かれている．そのため， 動作の開始は捕捉されているが，終了処理が 「ない」ことを把握することはしていない．アプリ ケーション動作の怪しさの判断材料としては， 単体での動作の怪しさだけでなく，継続性（前 述の動作の要素 e）や反復性（前述の動作の要 素 f）も有効である．これらを示すためには，終 了処理を補足するとともに，ある程度の期間の 蓄積情報をもつ動作履歴の提示が必要にな る．
5 アプリケーション動作の「見える化」の
提案
5.1 提案システム概要 アプリケーションインストール後に，ユーザが 怪しいアプリケーションに気付くための材料を 提供するため，アプリケーションの動作を「見え る化」する．「見える化」のために2 つの機能を 追加する．一つは，動作時の通知機能，もう一 つは，動作履歴の提示機能である． 材料としてユーザに提供する情報は，4.1 節142 -で述べた動作の要素に従い，「a．どのアプリケ ーションが」，「b．どの情報に対して」，「c．どの 動作を」，「d．いつ」，「e．どのくらいの時間（1 回の継続時間）」，「f．どのくらいの頻度で」行っ たかを示す情報とする．動作時の通知機能によ り，a, b, c, d をリアルタイムに通知し，動作履歴 の提示機能により，a, b, c, d, e, f に関する情報 を提供する． 5.2 機能 1：動作時の通知 注意すべき動作が生じた際に，リアルタイム でユーザに通知する．これにより，ユーザは実 際にどのタイミングで注意すべき動作が起こっ ているかを知ることができ，その動作がユーザ の意図したものであるかを判断することができ る．また，ユーザが怪しいアプリケーションによ って被る不利益を小さくするために，通知した時 点で，ユーザの判断で動作を許可／拒否でき るようにする． 通知は，ステータスバーを利用する．ユーザ が通知領域をタップすれば動作を許可，何もし なければ（通知を無視すれば）動作を拒否した とみなす．これは，ユーザの意図しない動作を 積極的に停止する意図がある．これにより，ユ ーザの意図しない動作である可能性が高い， ユーザが動作時の通知に気付かなかった場合 でも，動作を停止することができる．通知手段と してポップアップではなく，ステータスバーを選 択したのには，他のアプリケーションの利用が 妨げられることによってユーザが感じる煩わし さを低減する狙いがある． 5.3 機能 2：動作履歴の提示 注意すべき動作について，動作履歴を提示す る．これにより，ユーザはアプリケーション動作 の継続や反復による動作の怪しさを判断するこ とができる． Android では，ログを閲覧する機能は提供さ れているが，通常，怪しいアプリケーションは有 用なログを出力しない．また，ログビューア等で 確認するにしても，簡単に読み解けるものでは ない．そこで，注意すべき動作が生じたときに 提案システム側で動作日時を記録し，後でユー ザにわかりやすく提示する．前述の動作の要素 「e．どのくらいの時間（1 回の継続時間）」を示 すために，動作の性質上，動作が継続する状 態がある場合，例えば，位置情報の取得や録 音，録画といった動作の場合には，アプリケー ションが何らかの処理を開始するための動作だ けでなく，終了するための動作も記録する．こ れは，例えば，ホーム画面への遷移等により， ユーザの意識的にはアプリケーションを閉じた 状態にあるにも関わらず，位置情報の取得を終 了せずに継続しているような状況を捕捉するの に役立つ． 5.4 提案システムの動作 図2 の「フック」，「管理機能」が提案システム で追加する部分である．「一般アプリ」とは，普 段ユーザが利用する一般的なアプリケーション を指す． 図2 提案システム 提案システムは，以下のように動作する． ① 一般アプリが注意すべき動作を生じる際に 呼び出すApplication Framework 層のメ ソッドにフックを設け，独自の管理機能に制 御を移す． ② 制御アプリ内で，メソッドの呼び出し日時の DB への記録とユーザへの動作の通知を 行う．動作の通知は，ステータスバーを利
143 用する． ③ 通知と同時に，ユーザに動作の許可／拒 否を問う．ユーザが通知領域をタップすれ ば動作を許可，何もしなければ（通知を無 視すれば）動作を拒否したとみなす．ユー ザの判断は，DB に記録する． ④ ユーザの判断を受け，動作が許可されれ ば，一般アプリが要求する動作を継続させ る． ⑤ ②③の記録から，動作履歴をユーザに提 示する．
6 プロトタイプによる検証と考察
6.1 プロトタイプによる検証 プロトタイプとして，動作時の通知機能，動作 履歴の提示機能をアプリケーションレベルで実 装し，自作した 3 パターンのアプリケーションで 怪しい動作が見分けられるかを試した． 自作したアプリケーションは，起動すると現在 地の緯度・経度を表示するアプリケーションで， それぞれ次のような動作をする． アプリ A：普通のアプリケーション．起動すると 位置情報の取得を開始し，ホーム画面への遷 移や他のアプリケーションの起動により，位置 情報の取得を終了する． アプリ B：怪しいかもしれないアプリケーション． 起動すると位置情報の取得を開始し，ホーム画 面への遷移や他のアプリケーションの起動後に も，位置情報の取得を継続する（終了処理がな い）． アプリC：怪しいアプリケーション．起動すると位 置情報の取得を開始し，ホーム画面への遷移 や他のアプリケーションの起動により，位置情 報の取得を終了する．ただし，意識的に起動し ていないタイミングで位置情報の取得を開始し， そのまま位置情報の取得を継続する． アプリ B は，動作履歴を見ることで，位置情 報の取得を終了していない，つまり，位置情報 が継続して取得されていることがわかる．アプ リ C は，意図しないタイミングで位置情報取得 開始の動作通知が出るため，怪しい印象を受 ける．また，動作履歴を見ると，位置情報の取 得拒否の履歴があるため，意図しないタイミン グで位置情報の取得が開始されようとしたこと がわかる． 一般的にこれらが怪しい動作かどうかは，ア プリケーションの意図する動作により異なる．よ って，最終的な判断はユーザに委ねられるが， プロトタイプで示したような情報は，ユーザの判 断材料として有効である． 6.2 考察 提案システムが提供する情報を材料とする 場合，怪しさの判断材料は，4.1 節で述べた動 作の要素「a．どのアプリケーションが」，「b．ど の情報に対して」，「c．どの動作を」，「d．いつ」， 「e．どのくらいの時間（1 回の継続時間）」，「f． どのくらいの頻度で」行ったかになる．動作時の 通知機能により，a, b, c, d をリアルタイムに通 知し，動作履歴の提示機能により，a, b, c, d, e, f に関する情報を提供する． 怪しい動作が単発で行われる場合には，「d． いつ」が大きな鍵になる．ユーザが意図しない タイミングで動作が起こった場合には，動作時 の通知により怪しい動作であると判断できる可 能性が高い．同時に，ユーザが通知領域をタッ プすれば動作を許可，何もしなければ（通知を 無視すれば）動作を拒否したとみなすため，ユ ーザが積極的に許可の判断をする場合，つま り，ユーザの意図に従った動作であるとユーザ が積極的に判断する場合を除き，注意すべき 動作の実行を止めることができる．よって，ユー ザが動作時の通知に気付かない場合でも，注 意すべき動作の実行を止めることができる．ま た，動作履歴の提示により，動作時の通知に気 付かずに実行が停止された場合でも，ユーザ にその状況を示すことができ，怪しさの有効な 判断材料となる． 怪しい動作が長時間継続して行われている 場合や繰り返し行われている場合には，動作履 歴の提示が効力を発揮する．継続性のある動 作，反復性のある動作は，継続されるほど，回 数が増えるほど，怪しい動作であった場合の影 響が大きくなっていく．これらの動作は，動作時144 -の通知に加えて，動作履歴の提示による判断 材料「e．どのくらいの時間（1 回の継続時間）」， 「f．どのくらいの頻度で」が加わることで，より明 確に動作の様子を捉えることができる．これに より，怪しい動作であるという判断が早期にでき れば，それだけ早く対応をとることができ，影響 を小さくすることにつながる． 以上のように提案システムが有効である状 況がある一方で，現状の提案システムでは対 応できない状況もある．提案システムの方法で は，ユーザが意図したタイミング（ユーザが意 図してボタンを押したタイミングなど）で不正な 動作をされた場合には，ユーザは怪しいと判断 できず，不正な動作が達成されてしまう．情報 の種類「ア. 窃取されると金銭的な被害につな がる可能性のあるもの」，例えば連絡先データ がこのタイミングで不正に取得され，かつ，外部 への送信もこのタイミングで行われた場合には， ユーザにとって大きな不利益となる． この点に関しては，メソッドへのフックにより， 引数をチェックすることは可能であるため，その 有効性を検討する余地がある．また，前述の例 のメール送信のような，動作が内包する情報の 中身が重要になる動作では，その前に情報を 取得する動作が生じる．よって，動作の実行順 序に注目し，動作時の通知を変えることも検討 する余地がある．加えて，外部送信時に送信内 容をチェックして送信可否を決定する仕組み， 例えば葛野の提案手法[10]など，他の対策と の組み合わせを検討する必要がある．
7 まとめ
本稿では，アプリケーションインストール後に， ユーザが怪しいアプリケーションに気付くため の材料を提供することを目的とし，アプリケーシ ョンが注意すべき動作を実行する様子を「見え る化」するシステムを提案した．現状では，一定 の条件下では，有効な判断材料を提供すること ができるが，対応できない状況もある． 今後は，まず，端末に提案システムを実装し， 一般に公開されているアプリケーションで動作 履歴を収集する．その後，その履歴をもとに， 「怪しさ」のランク付けや判断材料の充実など， 提案システムの改善を行う．また，他の対策と の組み合わせも検討していく．参考文献
[1] Grace, M., Zhou, W., Jiang, X. and Sadeghi, A.: Unsafe Exposure Analysis of Mobile In-App Advertisements. the 5th ACM Conference on Security and Privacy in Wireless and Mobile Networks, 2012. [2] Manifest.permission, http://developer.android.com/reference/and roid/Manifest.permission.html, (accessed 2012-08-23) [3] 個人データを保護するスマートフォン向け技術 を開発， http://panasonic.co.jp/corp/news/official.dat a/data.dir/jn120227-2/jn120227-2.html, (accessed 2012-08-23)
[4] VMware MVP (Mobile Virtualization Platform), http://www.vmware.com/jp/products/deskt op_virtualization/mobile.html, (accessed 2012-08-23) [5] スマートフォン向けシンクライアント技術， http://www.ntt.co.jp/RD/OFIS/active/2011p df/pdf/h_pf03.pdf, (accessed 2012-08-23) [6] SEAndroid, http://selinuxproject.org/page/SEAndroid, (accessed 2012-08-23)
[7] TOMOYO Linux on Android,
http://www.slideshare.net/haradats/tomoy o-linux-on-android, (accessed 2012-08-23) [8] TrustZone, http://www.arm.com/ja/products/processors /technologies/trustzone.php, (accessed 2012-08-23)
[9] Enck, W., Gilbert, P., Chun, B., et al.:
TaintDroid: An information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones. 9th USENIX Symposium on Operating Systems Design and
145 Implementation, 2010. [10] 葛野弘樹：Android アプリケーションに対する 情報フロー制御機構の提案. Computer Security Symposium, 2011.
[11] Nauman, M., Khan, S. and Zhang, X.: Apex: Extending Android Permission Model and Enforcement with User-defined Runtime Constraints. The Proceedings of the 5th ACM symposium on Information, Computer and Communications Security, 2011. [12] 川端秀明, 磯原隆将, 竹森敬祐ほか：Android
OS における機能や情報へのアクセス制御機 構の提案. Computer Security Symposium, 2011.
[13] Banuri, H., Alam, M., Khan, S., et al.: An Android Runtime Security Policy
Enforcement Framework. The 2010 International Workshop on Smartphone Applications and Services, 2010.
