Androidプラットフォームのセキュリティモデル

The Android Platform Security Model を翻訳したものです

アブストラクト

Androidは、最も広く導入されているエンドユーザー向けオペレーティングシステムです。通信、ナビゲーション、メディア消費、娯楽、金融、健康、およびセンサー、アクチュエーター、カメラ、またはマイクへのアクセスを含むその使用例が増えているため、その基礎となるセキュリティモデルは、さまざまな実務上の脅威に対処する必要があります。セキュリティを専門としない専門家にとっては有用なシナリオです。このモデルでは、エンドユーザーのセキュリティ、プライバシー、使いやすさ、アプリケーション開発者の保証、およびハードウェアの制約が厳しいシステムのパフォーマンスの間で困難なバランスをとる必要があります。基本的な設計原則の多くがシステムアーキテクチャ全体、アクセス制御メカニズム、および緩和技術を暗黙のうちに知らせてきましたが、Androidセキュリティモデルはこれまで正式に公開されていません。本稿は、抽象モデルを文書化し、その意味を議論することを目的としています。脅威モデルとそれが動作するAndroidエコシステムのコンテキストの定義に基づいて、過去と現在のAndroid実装におけるさまざまなセキュリティ対策がどのように連携してこれらの脅威を軽減するかを分析します。セキュリティモデルを適用する際にいくつかの特別な場合があります。そして我々は抽象モデルからのそのような意図的な逸脱について議論します。

キーワード

Android、セキュリティ、オペレーティングシステム、非公式モデル

1 はじめに

この記事の執筆時点では、Androidが最も広く導入されているエンドユーザーオペレーティングシステムです。月に20億以上のアクティブデバイスがあり[9]、インターネットサービスをモバイルで使用する傾向が一般的になっている現在、Androidは、グローバルユーザーがデジタルサービスとやり取りするための最も一般的なインターフェイスです。さまざまなフォームファクタ（たとえば、電話、タブレット、ウェアラブル、テレビ、モノのインターネット、自動車、その他の特殊用途のカテゴリを含む）で、通信、メディアの消費、エンターテイメントから、幅広い分野へのユースケースが増え続けています。財政、健康、そして物理的なセンサー/アクチュエーター。これらのアプリケーションの多くはますますセキュリティとプライバシーを重視するようになっています。OSとしてのAndroidは、開発者だけでなくユーザーにも十分かつ適切な保証を提供する必要があります。

ユーザー（アプリケーション開発者、コンテンツ制作者、サービスプロバイダ、および雇用者）のさまざまな（そして時々矛盾する）ニーズと要望のバランスをとるために、Androidは基本的にリリースされたAndroid 9.0に基づいて2019年3月に更新されました。複数当事者の同意モデル：すべての関係者がそれに同意した場合にのみ、行動が発生します。いずれかの当事者が同意しない場合、その訴訟は阻止されます。これは、従来のオペレーティングシステムが実装しているセキュリティモデルとは異なります。これは、ユーザーアクセス制御に焦点を当てており、他の利害関係者を明示的に考慮していません。

マルチパーティモデルは最初からAndroidプラットフォームのアーキテクチャとデザインを暗黙のうちに知らせてきましたが、過去のリリースから集めた経験に基づいて洗練され拡張されました。このホワイトペーパーは、Androidセキュリティモデルを文書化し、エコシステムの制約と歴史的発展の文脈でその影響を体系的に分析することを目的としています。具体的には、次のような貢献をします。

セキュリティ原則とAndroidが動作するより幅広いコンテキストに基づいて、Androidセキュリティモデルを動機付けし、初めて定義します。このホワイトペーパーで説明および分析した中核的な3者間の同意モデルは、初期のバージョンから暗黙のうちにAndroidセキュリティメカニズムに情報を提供してきたため、以前は存在していましたが正式に公開されていない知識を体系化します。
脅威モデルを定義し、セキュリティモデルがそれにどのように対処するかを定義し、必要な特殊なケースの取り扱いと同様に、その意味合いについても議論します。
AOSP（Androidオープンソースプロジェクト、Androidプラットフォームのリファレンス実装）が、さまざまなレイヤーで相互作用する複数のセキュリティ対策に基づいてセキュリティモデルを強化する方法について説明します。
現在実施されているギャップと、この実装の将来の改善の可能性を特定します。

このホワイトペーパーでは、Androidプラットフォーム自体のセキュリティとプライバシー対策、つまりAOSPの一部であるユーザーデバイスで実行されるコードに焦点を当てています。Google Playに提出されたGoogle Playおよびアプリケーション上のアプリケーション（オプトインサービスとしてアプリの確認またはセーフブラウジング）やGoogle Playのポリシーやその他の法的枠組みの形で補完的なセキュリティサービスがあります。これらは現在の論文の範囲外ですが、関連した研究によってカバーされています[6、28、50、93]。ただし、Google Playのポリシー変更の1つとして、セキュリティ面で大きなプラスの影響があることが明示的に指摘されています。Playでは、新しいアプリやアプリのアップデートで最新のAndroid APIレベルをターゲットにする必要があります。過去にセキュリティ問題を抱えていました[35]。

以下では、最初にAndroidセキュリティの原則、およびAndroidセキュリティモデルの基礎となるエコシステムのコンテキストと脅威の分析について説明します（セクション2）。それから、私たちは中心的なセキュリティモデル（セクション3）と異なったOS層（セクション4）の上のOSアーキテクチャと実施メカニズムの形でその実装を定義します。特に明記されていない限り、すべての実装固有のセクションは最初のリリース時のAndroid Pie（9.0）を参照していることに注意してください（[79]を参照）。4.1－4.3（Jelly Bean）、4.4（KitKat）、5.x（Lollipop）、6.x（Marshmallow）、7.x（Nougat）、8.x（Oreo）というコード名ではなく、Androidバージョン番号を参照します。すべての表は、Androidのリリース4.xから9.0までのAOSPコードベース全体に対するセキュリティ関連の変更の分析に基づいており、コードの進化は約7年間にわたります。

2 Androidの背景

セキュリティモデルを紹介する前に、エコシステム要件とプラットフォームセキュリティの原則の両方の観点から、セキュリティモデルを運用するために必要なコンテキストについて説明します。

2.1 エコシステムのコンテキスト

設計上の決定のいくつかは、単独では存在しない、より大きなエコシステムを考慮に入れる必要があります。成功したエコシステムは、それが成長したときにすべての当事者が利益を得るものですが、最低レベルの相互信頼も必要とします。これは、メインパーティ（エンドユーザー、アプリケーション開発者、オペレーティングシステム）が相互に有益な契約条件を定義できる、デフォルトで安全な環境をプラットフォームが構築する必要があることを意味します。これらの当事者が合意に達することができない場合、最も信頼できるオペレーションを構築することはその行動を拒否することです（デフォルトは拒否）。以下に紹介するAndroidプラットフォームのセキュリティモデルはこの概念に基づいています。

このセクションは包括的なものではありませんが、セキュリティモデルに直接影響するAndroidエコシステムの側面について簡単に要約しています。

Androidはエンドユーザー向けのオペレーティングシステムです。Androidは柔軟性を追求していますが、主な焦点は一般的なユーザーです。明らかな含意は、消費者向けOSとして、それはユーザにとって有用でありそして開発者にとって魅力的でなければならないということです。

エンドユーザーの焦点は、ユーザーインターフェイスとワークフローはデフォルトで安全である必要があり、セキュリティやプライバシーを危険にさらす可能性のある操作に対しては明示的な意図が必要であることを意味します。これはまた、OSが技術的に詳細なセキュリティやプライバシーの決定を、それらを作成するのに十分なスキルや経験のない非専門家ユーザーにオフロードしてはならないことを意味します[5]。

Androidのエコシステムは莫大です。さまざまな統計によると、ここ数年の間に、グローバルで非常に多様なユーザーベースの大多数がすでにモバイルデバイスを使用してインターネットリソースにアクセスしていました（米国で63％、全世界で56％、アジアで68％、インドで80％以上）。さらに、さまざまなフォームファクタで何万ものAndroidデバイスを製造している何百という異なるOEM（相手先商標製造会社、すなわちデバイス製造業者）がある[80]（標準的なスマートフォンおよびタブレット、時計、眼鏡、カメラ、およびこれらに限定されない）。他の多くのモノのインターネットデバイスタイプ、ハンドヘルドスキャナー/ディスプレイおよび他の特別な目的のワーカーデバイス、テレビ、自動車など）。これらのOEMの中には詳細な技術的専門知識を持っていない、ただし、ハードウェアとファームウェアの開発はODM（Original Device Manufacturers）に依存してから、デバイスを自社ブランドで再パッケージ化するか、単にラベルを付け直します。ファームウェアを認定する必要があるのは、Googleサービス統合と一緒に出荷されるデバイスだけですが、単にAOSPをベースにしたデバイスは、許可または登録なしで作成できます。したがって、すべてのOEMを一覧にした単一のレジスタは存在せず、新しいハードウェアの概念が継続的に開発されているため、一覧は常に変化しています。1つの含意は、APIや他のインターフェースの変更がデバイスエコシステムの大幅な変更につながり、これらのユースケースのほとんどに到達するまでに時間がかかることです。しかし、単にAOSPをベースにしたデバイスは、許可または登録なしで作ることができます。したがって、すべてのOEMを一覧にした単一のレジスタは存在せず、新しいハードウェアの概念が継続的に開発されているため、一覧は常に変化しています。1つの含意は、APIや他のインターフェースの変更がデバイスエコシステムの大幅な変更につながり、これらのユースケースのほとんどに到達するまでに時間がかかることです。しかし、単にAOSPをベースにしたデバイスは、許可または登録なしで作ることができます。したがって、すべてのOEMを一覧にした単一のレジスタは存在せず、新しいハードウェアの概念が継続的に開発されているため、一覧は常に変化しています。1つの含意は、APIや他のインターフェースの変更がデバイスエコシステムの大幅な変更につながり、これらのユースケースのほとんどに到達するまでに時間がかかることです。

ただし、Androidアプリとの互換性を宣伝するために商標名としてAndroidを使用するデバイスは、Compatibility Test Suite（CTS）に合格する必要があります。この多種多様なデバイス用のアプリケーションを作成するとき、開発者はこの互換性に依存しています。他のプラットフォームとは異なり、Androidは任意のソースからのアプリのインストールを明示的にサポートしているため、さまざまなアプリストアの開発やGoogle Play以外でのアプリの存在につながりました。そのため、ごく一部のデバイスにインストールされている、または古いAndroid APIリリースをターゲットにしている、非常に特殊な目的を持つアプリの長い末尾があります。APIの定義と変更は、Androidエコシステムの一部である膨大な数のアプリケーションを考慮する必要があります。

アプリはどの言語でも作成できます。アプリがプロセスワークフロー用に明確に定義されたJava言語APIを使用してAndroidフレームワークとインターフェースする限り、ランタイムサポートの有無にかかわらず、コンパイルまたは解釈された任意のプログラミング言語で作成できます。Androidは現在、基本的なプロセスライフサイクル制御のためにJava以外の言語のAPIをサポートしていません。それらを並行してサポートする必要があり、フレームワークがより複雑になり、エラーが発生しやすくなるためです。この制限は直接制限するものではありませんが、初期プロセスを開始して基本的なOSサービスとインターフェースをとるには、アプリに少なくとも小さなJava言語ラッパーが必要です。セキュリティメカニズムに対するこの柔軟性の重要な意味は、コンパイル時のチェックやビルド環境での他の仮定に頼ることができないということです。したがって、Androidのセキュリティは、アプリの境界を越えたランタイム保護に基づいている必要があります。

2.2 Androidのセキュリティ原則

最初から、Androidはこのオープンエコシステムにおいて、多くの関係者間の暗黙の契約と見なすことができる、いくつかの基本的なセキュリティとプライバシーの原則を想定していました。

アクターは作成したデータへのアクセスを制御する データ項目を作成するすべてのアクターは、データ表現のこの特定のインスタンスに対する暗黙のうちに制御を許可されます。これは、ファイルシステムまたはメモリ内のデータを保護する技術的な行為を指すことに注意してください。しかし、法的な意味でのデータに対する所有権を自動的に意味するものではありません。

同意は通知され、意味を持つ いかなる行動にも同意するアクターは、その行動とその影響についての情報に基づいて決定を下す権限を与えられなければならず、そしてこの同意を許可または拒否する意味のある方法を持たなければなりません。これはユーザーと開発者の両方に当てはまりますが、同意を強制する（欠いている）技術的に非常に異なる手段が適用されます。データ項目を作成したアクターからだけでなく、関係するすべてのアクターからの同意が必要です。同意の決定は強制されるべきであり、自己管理的ではありません。

設計上/デフォルトで安全 コンポーネントは設計上安全であるべきです。つまり、オペレーティングシステムのコンポーネントまたはサービスをデフォルトで使用すると、セキュリティとプライバシーの前提が常に守られるはずですが、場合によっては一部のユースケースがブロックされる可能性があります。この原則は、モジュール、API、通信チャネル、そして一般的にあらゆる種類のインターフェースに適用されます。そのようなインターフェースの変形がより高い柔軟性のために提供されるとき（例えば、デフォルトの振る舞いを無効にするためにより多くのパラメータを持つ第二のインターフェース方法）、意図しないまたは意図的にこれらを乱用することは難しいはずです。このアーキテクチャーの原則は、デバイス製造元を含む開発者を対象としていますが、セキュリティがユーザーインターフェイスでどのように設計され表示されるかについては暗黙的にユーザーを含みます。 Androidは幅広い開発者を対象としており、意図的にアプリ開発への参入障壁を低く保っています。 APIを悪用して悪意のある敵対者を保護するだけでなく、本物のエラーを軽減します。インターフェース定義についての不完全な知識から、あるいは安全なシステム設計の経験が不足している開発者によって引き起こされたものです。多層防御アプローチのように、システムを設計上安全にするための唯一の解決策はありません。代わりに、これは新しいインタフェースを定義し、必要に応じて既存のインタフェースを廃止して削除するための指針となる原則と見なされます。

多層防御 オペレーティングシステムの許容できる振る舞いが、攻撃者がセキュリティモデルを迂回することなくそれらの目的のすべてを達成することを可能にする場合、堅牢なセキュリティシステムは十分ではない（例えば、アクセス制御モデルの下でアクセスするすべてのファイルのランサムウェア暗号化）。具体的には、上記の原則のいずれかに違反することは、（例えば構築時に装置外の検証に頼るのとは対照的に）そのような装置上の制御の迂回を必要とするはずです。

したがって、セキュリティシステムの主な目的は、そのモデルを強化することです。 Androidが多数の環境で動作している場合（脅威モデルについては下記を参照）、これは、デバイスが最新でなくても、単一の仮定に違反したり単一の実装バグが見つかった場合にすぐに失敗しないアプローチを意味します。詳細な防御は、個々の脆弱性を悪用することをより困難または不可能にし、攻撃者がその目的を達成するのに必要な脆弱性の数を増やすことによって特徴付けられます。攻撃者がセキュリティモデルを迂回するのを防ぐために、主に4つの一般的なセキュリティ戦略を採用しています。隔離と封じ込め、悪用の軽減、整合性、およびパッチの適用/更新です。それらの実装はセクション4でより詳細に議論されるでしょう。

2.3 脅威モデル

モバイルデバイスの脅威モデルは、定義上、モバイルデバイスが紛失または盗難にさらされやすく、予想される使用方法の一部として信頼できないネットワークに接続するという2つの主な理由で、デスクトップまたはサーバーオペレーティングシステムで一般的に使用されるモデルとは異なります。同時に、ほとんどの場合、ユーザーの近くにいることで、他の多くのカテゴリのデバイスよりもさらにプライバシーに敏感なデータにさらされます。最近の研究[73]は以前、この文書の範囲内でAndroidセキュリティモデルを議論するために採用したモバイルデバイス用の階層型脅威モデルを紹介しました。敵対者はAndroidデバイスに物理的にアクセスすることができます。すべてのモバイル機器やウェアラブル機器にとって、ある時点でそれらは敵対者の物理的な支配下に入る可能性があると想定しなければなりません。物、車、テレビなどの他のAndroidフォームファクタにも同じことが当てはまります。そのため、Androidデバイスは、脅威モデルの明示的な部分として、敵対者に直接アクセス可能であるか、または敵対者に物理的に近接していると想定しています。これには、紛失や盗難だけでなく、（テレビやタブレットなどの）デバイスを共有している複数の（良性だが潜在的に好奇心が強い）ユーザーも含まれます。物理的または近接アクセスによる特定の脅威を導き出します。

T1 敵対者を完全に物理的に支配している状態（国家レベルの攻撃者まで潜在的に高度に精巧になっている）。
T2 敵対者の完全な物理的管理下にある機器をロックした。例えば、追加の個人情報盗難のためにデータを盗み出そうとしている窃盗犯。
T3 Screenは許可されているが異なるユーザーの管理下にあるロック解除された（共有された）デバイス、例えば親密なパートナーの虐待、国境管理への自発的提出、または税関チェック
T4 敵対者に物理的に近接した（スクリーンロックまたはロック解除）装置（携帯電話、WiFi、Bluetooth、GPS、NFC、およびFMを含むすべての利用可能な無線通信チャネルを制御する想定機能付き）、例えばBluetoothによる直接攻撃[30] 。NFCは距離の規模のために他の近接無線攻撃とは別のカテゴリと見なすことができますが、物理的な制御ではなく、脅威の近接クラスに含めます。

ネットワーク通信は信頼できません。敵対者を完全に制御するネットワーク通信の標準的な前提は、Androidデバイスにも当てはまります。これには、通常のDolev-Yaoモデル[40]に要約されている、ネットワーク通信の最初のホップ（TLS接続や悪意のある偽のアクセスポイントを破るキャプティブWiFiポータルなど）が含まれます。短距離無線に対する追加のリレーの脅威（NFCやBLEワームホール攻撃など）。実用的には、主に2つのネットワークレベルの脅威について考えます。

T5 受動的な傍受およびトラフィック分析。ネットワーク内またはネットワーク間でのデバイスの追跡を含みます。たとえば、MACアドレスやその他のデバイスネットワーク識別子に基づいています。
T6 ネットワークトラフィックの積極的な操作、例えばTLS接続でのMITM。

これら2つの脅威は、攻撃の拡張性の点で[T4]（近距離無線攻撃）とは異なります。メジャーネットワーク内の単一のチョークポイントを制御すると、多数のデバイスを攻撃できますが、近位（ラストホップ）の無線攻撃では、ターゲットデバイスに物理的に接近する必要があります。

信頼できないコードがデバイス上で実行されます。他のモバイルオペレーティングシステムとの基本的な違いの1つは、Androidが意図的に（エンドユーザーによる明示的な同意を得て）任意のソースからのアプリケーションコードのインストールを許可し、中央インスタンスによるアプリケーションの検証を強制しないことです。これは、複数レベルの攻撃ベクトルを意味します（[73]を参照）。

T7 スパイウェアなど、悪意を持ってOSがサポートしているAPIを悪用する。
T8 OSのバグ、例えばカーネル、ドライバ、システムサービスの悪用[36.38、90]。
T9 デバイスにインストールされている他のアプリでサポートされているAPIの悪用[89]。
T10 Webからの信頼できないコード（つまりJavaScript）は、明示的な同意なしに実行されます。
T11 悪意のあるアプリにPIN /パスワードを入力するなど、ユーザーを混乱させるためのシステムまたは他のアプリのユーザーインターフェイスの模倣（標準の帯域内セキュリティインジケータは有効ではないという知識に基づく[39、81]）。
T12 例えば他のアプリからの機密データをスクリーンスクレイピングするために、システムまたは他のアプリのユーザーインターフェースからコンテンツを読むこと[58、63]。
T13 システムまたは他のアプリのユーザーインターフェースへの入力イベントの注入[51]。

信頼できないコンテンツはデバイスによって処理されます。信頼できないコードを直接実行することに加えて、デバイスは（複雑な構造という意味での）リッチメディアを含む、さまざまな信頼できないデータを処理します。これはデータとメタデータの処理に関する脅威に直接つながります。

T14 OSやアプリ、例えばメディアライブラリの中の信頼できないコンテンツを処理するコードを悪用する[88]。これは、入力データの取得元に応じて、ローカルとリモートの両方の攻撃対象になる可能性があります。
T15 標的型攻撃（信頼できるネットワーク上でも発生する可能性がある）に固有の識別子を悪用する。たとえば、スパム送信のための電話番号や電子メールアドレスの使用、ロケーションを含む他のデータセットとの関連付けなど。

3 Androidプラットフォームのセキュリティモデル

このセクションで説明されている基本的なセキュリティモデルはAndroidの設計を知らせ、洗練されていますが基本的には変更されていません。上記で説明したエコシステムのコンテキストと一般的なAndroidの原則を考慮すると、Androidセキュリティモデルは、アプリケーションのセキュリティ要件とプラットフォーム自体のセキュリティとユーザーのセキュリティおよびプライバシー要件のバランスを取ります。上記の脅威モデルには、すべての利害関係者に対する脅威が含まれています。Androidプラットフォームによるセキュリティモデルとその実施は、それらすべてに対処することを目的としています。Androidプラットフォームのセキュリティモデルは、5つのルールによって非公式に定義されています。

1 3者間の同意 3者の全てが合意しない限り、いかなる行動も実行されるべきではありません。つまり、ユーザー、プラットフォーム、および開発者（コンテンツプロデューサーやサービスプロバイダーなどの関係者を暗黙的に表す）です。いずれの当事者もその行動を拒否することができます。この3者間の同意は、ほとんどのセキュリティモデルの根底にある従来の2次元のサブジェクト（ユーザとアプリケーションプロセス）とオブジェクト（ファイル、ネットワークソケット、IPCイン??タフェース、メモリ領域、仮想データプロバイダなど）の対になります（[91]）。保護するオブジェクトの主なカテゴリとして（通常および疑似）ファイルに焦点を当てると、これらのファイルに対するデフォルトの制御は、それらの場所と作成者によって異なります。

共有記憶域内のデータはユーザーによって制御されます。
プライベートアプリディレクトリとアプリ仮想アドレススペースのデータはアプリによって制御されます。
特別なシステムの場所にあるデータはプラットフォームによって管理されています（例：許可された権限のリスト）。

ただし、3者間の同意の下で、1者が主にデータ項目を管理していても、他の2者が同意した場合にのみそれに基づいて行動する可能性があることを指摘することが重要です。データの管理も所有権を意味するわけではありません（これは技術的な概念ではなく法的概念であり、OSセキュリティモデルの範囲外です）。

2人の当事者のみが同意を必要とする場合（ユーザーが追加のアプリを使用せずにプラットフォーム/ OSサービスのみを使用する行為の場合）または第三者が導入される場合があることがあります。モバイルデバイス管理では、このポリシーはアクションへの同意についても考慮されます）。

2 エコシステムへのアクセスをオープンにする ユーザーと開発者はどちらも、単一のアプリケーションストアに限定されない、オープンエコシステムの一部です。開発者の集中審査やユーザーの登録は不要です。この点はセキュリティモデルにとって重要な意味を持ちます。一般的なアプリ間の対話は明示的にサポートされています。考えられるすべてのワークフローに対して特定のプラットフォームAPIを作成するのではなく、アプリ開発者は他のアプリに提供する独自のAPIを自由に定義できます。

3 セキュリティは互換性の要件 セキュリティモデルはAndroid仕様の一部です。Androidは、Compatibility Definition Document（CDD）[10]で定義されており、Compatibility（CTS）、Vendor（VTS）、およびその他のテストスイートによって強化されています。CDDに準拠せず、CTSに合格しないデバイスはAndroidではありません。このホワイトペーパーの範囲内では、サンドボックス化と分離の影響を受けないプロセスを開始できるようにシステムを変更することとして、発根を定義します。意図的で悪意のある、そのような応援は、CDDに違反する非準拠の変更の具体例です。そのため、CDD準拠のデバイスのみが考慮されています。多くのデバイスはブートローダのロック解除と変更されたファームウェアのフラッシュ2をサポートしていますが、セキュリティの保証が得られない場合、そのような変更はCDDでは互換性がないと考えられます。

4 出荷時設定にリセットすると、デバイスは安全な状態に戻る 永続的な侵害をもたらすセキュリティモデルのバイパスの場合、書き込み可能なデータパーティションを消去/再フォーマットするファクトリリセットは、完全性保護されたパーティションのみに依存する状態にデバイスを戻します。つまり、システムソフトウェアを再インストールする必要はありませんが、データパーティションを消去すると、デバイスはデフォルトの状態に戻ります。一般に、読み取り専用のデバイスソフトウェアは、箱から出して以来更新されている可能性がありますが、これは意図的に工場出荷時の状態にリセットされたものではありません。したがって、より具体的には、出荷時設定へのリセットは、検証済みブートによってカバーされるシステムコードのみに依存し、書き込み可能データパーティションには依存しない状態にAndroidデバイスを戻します。

5 アプリケーションにおいてはセキュリティが第一 ログインユーザーアカウントのコンテキストでアプリを実行する従来のオペレーティングシステムとの主な違いは、Androidアプリはユーザー操作の完全に承認されたエージェントとは見なされないことです。通常はサーバーやデスクトップOSによって実装されている従来のモデルでは、悪用するにはメインユーザーの完全な権限で悪意のあるコードを実行すれば十分であるため、セキュリティ境界を悪用する必要さえありません。ファイル暗号化ランサムウェア[59、84]（現在のユーザアカウントがアクセス権を持つすべてのファイルを単に書き換えるだけでOSセキュリティモデルに違反しない）や個人データの漏洩（ブラウザログイントークン[70]など）の例は多数あります。 ]、履歴またはその他の追跡データ、暗号通貨ウォレットキーなど）

サマリー 一見しただけでは、Androidセキュリティモデルは、マルチパーティの同意モデルを課さない従来のオペレーティングシステムと比較してユーザーに与える電力が少ないにもかかわらず、エンドユーザーに即座に利益があります。ユーザーが他のアプリによって制御されているデータにアクセスできるようにすることはできません。つまり、アプリケーション開発者の同意が必要です。プラットフォームによって強制されます。ユーザーの混乱を防ぐため、個人データの保護に役立ちます。

4 実装

Androidのセキュリティ対策はセキュリティモデルを実装しており、上記で概説した脅威に対処するように設計されています。このセクションでは、セキュリティ対策について説明し、「多層防御」および「設計による安全」というアーキテクチャ上のセキュリティ原則を考慮しながら、それらがどの脅威を軽減するかを示します。

4.1 同意

意味のある同意を与える方法は、潜在的な問題や制約だけでなく、アクターによっても大きく異なります。

4.1.1 開発者

従来のデスクトップオペレーティングシステムとは異なり、Androidは開発者が自分のアプリまたはアプリのデータに対する操作に同意することを保証します。これにより、関連性のないアプリがユーザーのデバイス上の他のアプリケーションにコードを挿入したりデータを盗んだりするような、大規模な種類の不正行為を防止できます。

ユーザーとは異なり、開発者への同意は署名したコードとシステムが実行するコードによって確認されます。例えば、アプリは、例えば組み込みの暗黙の意図的解決選択ダイアログ[11]のようなOS共有方法に基づいて、それぞれのメカニズムを提供することによって、データを共有するユーザーに同意することができます。もう1つの例はデバッグです。割り当てられた仮想メモリの内容はアプリによって制御されるため、外部プロセスからのデバッグは、アプリがそれに同意した場合にのみ許可されます（特にアプリのマニフェストのdebuggableフラグを使用）。

意味のある同意は、APIとその振る舞いが明確であることを保証し、開発者は自分のアプリケーションが他のコンポーネントとどのように相互作用したりデータを提供したりしているかを理解します。さらに、さまざまなスキルレベルの開発者はセキュリティの微妙な違いについて完全に理解していない可能性があります。その結果、APIもデフォルトで安全であり、誤ったセキュリティの後退を避けるために誤って使用することは困難です。

同意するのはアプリ開発者であり、他の関係者ではないことを保証するために、アプリケーションは開発者によって署名されます（またはキーローテーション機能を使用する場合は、以前にアプリによってこの機能が付与されたキー）。これは第三者を防ぎます。アプリストアを含みます。アプリの意図した動作を変更するためにコードやリソースを置き換えたり削除したりすることはできません。ただし、アプリ署名キーはインストール時に暗黙のうちに信頼されるため、転送中のアプリの置き換えや変更（アプリのサイドロードなど）は現在プラットフォームセキュリティモデルの範囲外であり、開発者の同意に違反する可能性があります。

4.1.2 プラットフォーム

プラットフォームは、開発者と同様にコード署名を介して同意しますが、目標はまったく異なります。プラットフォームは、システムが意図したとおりに機能することを保証するように動作します。これには、規制上または契約上の要件を強制すること、およびどのような行動が許容されるかについての慎重な姿勢をとることが含まれます。プラットフォームの同意は、アプリケーションと同じように、プラットフォームの署名キーと関連する権限を使用して、プラットフォームのアプリケーションと同様にシステムイメージを変更から保護する検証済みブート（詳細は下記を参照）によって実施されます。

4.1.3 ユーザー

意味のあるユーザーの同意を得ることは、意味のある同意を判断する上で、はるかに困難で微妙な課題です。これまでの10年間の開発における経験に基づいて洗練されてきましたが、いくつかの指針原則は常にAndroidの中核を成してきました。

過度のプロンプトを避ける ユーザーを過度に促すことは、迅速な疲労と失明につながります（[7]を参照）。すべてのアクションに対してyes / noプロンプトでユーザーにプロンプ??トを出しても、ユーザーは規則性があるためにプロンプ??トに気付かなくなるため、意味のある同意が得られません。
わかりやすい方法でプロンプトを出す 利用者は専門家ではないか、あるいは微妙なセキュリティの質問を理解していないと想定される（[48]参照）。技術者以外のユーザーが自分の決定の影響を理解できるように、プロンプトと開示を表現する必要があります。
広い粒度よりもピッカーとトランザクションの同意を優先する 可能であれば、セット全体ではなく特定のアイテムへのアクセスを制限します。たとえば、連絡先ピッカーを使用すると、連絡先アクセス許可を使用する代わりに、アプリケーションと共有する特定の連絡先を選択できます。これらは両方とも公開されるデータを制限するだけでなく、ユーザーに選択を明確かつ直感的な方法で提示します。
OSは難しい問題でユーザーに負担をかけてはいけない Androidは、許可されるにはリスクが高すぎると思われる行動を定期的に考え、パワーユーザーには役立つが平均的ユーザーには危険な機能を追加することを避けます。
以前に行った決定を元に戻す方法をユーザーに提供する ユーザーは間違いを犯す可能性があります。最もセキュリティが高く個人的に慣れ親しんでいるユーザーでも、時々間違ったボタンを押すことがあります。これは、疲れたり気が散ったりするときに起こります。そのような間違いやユーザーが単に考えを変えることを軽減するために、ユーザーは可能な限り前の決定を元に戻すことが容易であるべきです。これは、以前に許可された権限を拒否することから、デバイスからアプリを完全に削除することまで、さまざまです。

さらに、同意しているユーザーがそのデバイスの正当なユーザーであり、そのデバイスに物理的にアクセスできる他の人（[T1] - [T3]）ではないことを確認することが重要です。 Androidのロック画面の。モデルルール1の実装は、すべてのシステムレイヤで横断的です。

当事者間の同意をよりよく説明するために2つの例を使用します。

あるアプリから別のアプリにデータを共有するには、次のものが必要です。
- ユーザーが共有ダイアログでターゲットアプリを選択することによるユーザーの同意。
- アプリから許可したいデータ（画像など）との共有を開始することによるソースアプリの開発者の同意。
- 共有データを受け入れることによって、開発者がターゲットアプリに同意する。そして
- プラットフォームは、データアクセスを調停し、ターゲットアプリが明示的に共有されているアイテム以外のデータに同じリンクを介してアクセスできないようにすることで同意します。
MNO（Mobile Network Operator）設定オプションを変更するには、次のものが必要です。
- 設定ダイアログでオプションを選択してユーザーの同意を得ます。
- （MNOアプリ）開発者は、これらの設定項目を変更するためのオプションを実装することで同意します。バックエンドシステムでポリシーを問い合わせる可能性があります。そして
- たとえば、国の規制に基づくポリシーを検証し、設定がプラットフォームやネットワークの安定性に影響を与えないようにすることで、プラットフォームの同意を得ます。

4.2 認証

認証は、システムがその所有者または正当なユーザーと確実に対話するためのゲートキーパー機能です。モバイルデバイスでは、認証の主な手段はロック画面を介して行われます。ロックスクリーンはセキュリティと使いやすさの間の明らかなトレードオフであることに注意してください。一方では、ユーザーは平均して1日に約50回、例外的な場合には最大200回の短い（10-250秒）対話のために電話のロックを解除します。[45,56］そしてロックスクリーンは明らかに装置との摩擦のない相互作用に対する直接的な障害です［54,55］。一方、ロック画面のないデバイスは、不正なユーザーによる不正使用にすぐに開放され（[T1] - [T3]）、OSは認証なしに確実にユーザーの同意を強制することはできません。

現在の形式では、モバイルデバイスのロック画面は主にバイナリモデルを強制します。電話全体にアクセスできるか、大部分の機能（特にすべてのセキュリティまたはプライバシーに敏感なもの）がロックされています。長い、セミランダムの英数字パスワード（安全性は高いがモバイルデバイスには使用できない）や、スワイプ専用のロック画面（使用可能だがセキュリティは提供されていない）のどちらも推奨できません。したがって、セキュリティと使いやすさの間で合理的なバランスをとることがロックスクリーンにとって非常に重要です。

この目的のために、最近のAndroidリリースは、安全な知識要素ベースの認証メカニズムが、提供するセキュリティのレベルに基づいて機能的に制限されている便利なモダリティによって裏付けられることができる階層型認証モデルを使用します。このようなモデルによってもたらされる追加の利便性は、ロックスクリーンの採用を促進し、ロックスクリーンの即時のセキュリティ上の利点と、基盤となるユーザー提供の資格情報の存在に依存するファイルベースの暗号化などの機能の両方から恩恵を受けます。Android 7.x以降、ロックスクリーンの採用を促進する例として、指紋センサーを搭載したデバイスの77％がセキュアロックスクリーンを有効にしているのに対し、フィンガープリントを搭載していないデバイスの50％のみがセキュアロックスクリーンを搭載しています。

Android 9.0以降、階層型認証モデルはモダリティを3層に分割します。

プライマリ認証モダリティ はナレッジファクタに制限され、デフォルトでPIN、パターン、およびパスワードが含まれます。一次認証では、電話機のすべての機能にアクセスできます。
二次認証モダリティ は、それらのなりすましおよび偽造者の受け入れ率によって定義されているように「強力な」バイオメトリクスであることが要求される[78]。脅威モデルで明示的な攻撃者を説明することは、安全でないロック解除方法の可能性を減らすのに役立ちます[75]。二次様式もいくつかの行動をとることを妨げられている。たとえば、ファイルベースまたはフルディスク暗号化のユーザーデータパーティション（初回起動時など）は復号化されず、72時間ごとにプライマリ認証にフォールバックする必要があります。
三次認証モダリティ とは、偽造防止基準を満たさない弱いバイオメトリクス、または信頼できるBluetoothデバイスとペアになった場合のロック解除、信頼できる場所でのロック解除などの代替のモダリティです。三次モダリティは二次モダリティのすべての制約を受けますが、さらにKeymaster認証バインドキーへのアクセス許可（支払いに必要なものなど）が制限されており、4時間のアイドル期間後はプライマリ認証へのフォールバックも必要です。

Androidのロック画面は現在、カーネル上のAndroidシステムコンポーネント、具体的にはKeyguardとそれぞれのロック解除方法（そのうちのいくつかはOEM固有のもの）によって実装されています。安全なロック画面のユーザ知識要素は、それらを保存されているテンプレートと照合し、保存の暗号化のための鍵を導出するために、Gatekeeper/Weaver（後述）に渡されます。1つの含意は、カーネルの侵害がロックスクリーンを回避することにつながる可能性があるということです。ただし、ユーザーが再起動後に初めてログインした後に限ります。

4.3 アイソレーションと封じ込め

セキュリティモデルを実施する上で最も重要な部分の1つは、デバイス上で既に実行されている潜在的に悪意のあるコードに対して実行時にそれを実施することです。Linuxカーネルは、Androidのセキュリティモデルの基礎となる多くの基盤と構造を提供します。プロセス分離は、サンドボックス化のための基本的なセキュリティプリミティブを提供します。ごくわずかな例外を除いて、プロセスの境界はセキュリティの決定が行われ実施される場所です。Androidは意図的にJavaセキュリティモデルのようなインプロセスコンパートメント化に依存しません。プロセスのセキュリティ境界は、プロセス境界とそのエントリポイントで構成され、ルール2を実装します。サンドボックス内で実行するためにアプリを検証したり事前処理したりする必要はありません。この境界を強化することは、次のようないくつかの方法で達成できます。

アクセス制御：パーミッションチェックの追加、パーミッションチェックの精度の向上、またはより安全なデフォルトへの切り替え（デフォルトの拒否など）
アタックサーフェスの削減：エントリポイントの数を減らす、すなわち最小特権の原則
封じ込め：特に信頼できないコンテンツを処理するコンポーネントを隔離したり権限を剥奪したりする
アーキテクチャーの分解 ：特権プロセスを特権の低いコンポーネントに分割し、攻撃対象領域を縮小します
懸念事項の分離：機能の重複を避ける

このセクションでは、さまざまなレイヤーのAndroidで使用されているさまざまなサンドボックス化とアクセス制御のメカニズム、およびそれらが全体的なセキュリティ体制をどのように向上させるかについて説明します。

4.3.1 パーミッション

Androidは、アクセス制御を実行するために3つの異なる許可メカニズムを使用します。

任意アクセス制御（DAC） ：プロセスは、オブジェクトに対するアクセス権を変更する（たとえば、全世界読み取りアクセスを許可する）ことによって、またはIPCを介してオブジェクトにハンドルを渡すことによって、所有するリソースへのアクセスを許可または拒否できます。Androidでは、これは、カーネルによって付与されたUNIXスタイルの権限とURIの権限付与を使用して実装されます。rootユーザーとして実行されているプロセスは、UNIXの許可を上書きするための広範な権限を持っていることが多くあります（MAC許可の対象です。下記参照）。URI許可付与は、アプリ間の対話のためのコアメカニズムを提供し、アプリが所有するデータの一部への選択的アクセスを許可することをアプリに許可します。
強制アクセス制御（MAC） ：システムには、許可されるアクションを規定するセキュリティポリシーがあります。ポリシーによって明示的に付与されたアクションのみが許可されています。Androidでは、これはSELinux [87]を使用して実装され、主にカーネルによって実施されます。Androidは、互換性テスト中にシステムコンポーネントを保護し、セキュリティモデルの要件を表明するためにSELinuxを幅広く利用しています。
Androidのパーミッション は、機密データやサービスへのアクセスをゲートします。施行は、主にユーザースペースでデータ/サービスプロバイダによって行われます（インターネットなどの著しい例外はあります）。許可はアプリのAndroidManifest.xml [12]で静的に定義されていますが、要求された許可すべてが許可されるわけではありません。Android 6.0では、アプリケーションのインストール時に要求されたすべての権限が付与されるという保証がなくなったため、大きな変更が加えられました。これは、インストール時にユーザーがそのような決定を下すのに十分な能力がないという認識の直接的な結果でした（[47、48、82、101]を参照）。

高レベルでは、Androidのパーミッションは、重要度の高いものから順に5つのクラスのいずれかに分類されます。

監査のみのパーミッション：これらは「通常の」保護レベルを持つインストール時の許可です。
ランタイムパーミッション：これらはランタイムプロンプトダイアログの一部としてユーザーが承認しなければならないパーミッションです。これらの許可は一般的に使用される機密ユーザーデータを保護しており、それらがアプリケーションの現在の機能にとってどれほど重要かに応じて、それらを要求するためのさまざまな戦略が推奨されます[24]。
特別なアクセスのパーミッション：ランタイムパーミッションよりも多くのリスクをさらす、またはより高いリスクの許可については、アプリケーションがランタイムプロンプトを表示できない、はるかに高い許可摩擦を持つ特別なクラスの許可が存在します。ユーザーがアプリケーションに特別なアクセス許可の使用を許可するには、ユーザーは設定に進み、手動でアプリケーションに許可を付与する必要があります。
特権アクセスのパーミッション：これらのアクセス許可は、プリインストールされた特権アプリケーション専用であり、運送会社請求などの特権アクションを許可します。
シグネチャのパーミッション：これらのパーミッションは、パーミッションを宣言するコンポーネントと同じキーで署名されたコンポーネント、例えばプラットフォーム署名キーにのみ利用可能です。これらは、ネットワークインターフェースの設定など、内部的または高度に特権的なアクションを保護することを目的としています。

許可の可否は2つの部分（レベル自体といくつかのオプションのフラグ）を持つprotectionLevel属性[13]によって定義されます。保護レベルは次のとおりです。

normal ：通常のアクセス許可とは、プライバシーやセキュリティ上のリスクをあまり引き起こさず、インストール時に自動的に付与されるものです。これらの権限は、主にアプリの動作を監査するために使用されます。
dangerous ：このprotectionLevelを持つアクセス許可はランタイムアクセス許可であり、アプリは両方ともマニフェストでそれらを宣言する必要があります。また、使用中にユーザーに許可するように要求する必要があります。監査と実施をサポートするためにきめ細かい粒度のこれらの権限は、permissionGroup属性を使用して論理的な権限にグループ化されています。実行時のアクセス許可を要求すると、グループは過剰なプロンプトを避けるために単一のアクセス許可として表示されます。
signature ：許可を定義するアプリケーション（プラットフォーム許可のプラットフォーム署名鍵）と同じ鍵で署名されている場合にのみ、アプリケーションにそのような許可が付与されます。アプリケーションが使用を許可されている場合、これらの許可はインストール時に付与されます。

さらに、権限の付与可能性を変更する多くの保護フラグがあります。例えば、BLUETOOTH_PRIVILEGED許可には、保護されたsignature

特権の特権があり、特権フラグは特権付きアプリケーションに許可を与えることを許可します（それらがプラットフォーム鍵で署名されていない場合でも）。

3つの許可メカニズムのそれぞれは、3つのパーティーのうちの1つがどのように同意を与えるか（ルール1）と大体一致しています。プラットフォームはMACを利用し、アプリはDACを利用し、ユーザーはAndroidの許可を与えることで同意します。許可は、法的な意味で同意を得るためのメカニズムではなく、監査可能性と管理を強化するための技術的手段であることを意図していることに注意してください。適用される法的要件を満たすのは、個人のユーザーデータを処理するアプリ開発者次第です。

4.3.2 アプリケーションサンドボックス

Android独自のDACアプリケーションサンドボックスでは、各アプリケーションに固有のUNIXユーザーID（UID）とそのアプリケーションが所有するディレクトリを提供することで、アプリケーション同士とシステムを分離しました。このアプローチは、物理ユーザーのUIDを使用してアプリケーションを実行するという従来のデスクトップアプローチとはまったく異なります。アプリごとの一意のUIDにより、権限の確認が簡単になり、プロセスごとのID（PID）の確認が不要になります。アプリに付与されている権限は、中央の場所（/data/system/packages.xml）に保存されています。他のサービスから問い合わせを受けるため。たとえば、アプリが位置情報サービスに位置情報を要求すると、位置情報サービスは許可サービスに問い合わせて、要求元のUIDに位置許可が付与されているかどうかを確認します。

UIDサンドボックスにはいくつかの欠点がありました。rootとして実行されているプロセスは本質的にサンドボックス化されておらず、システム、アプリ、プライベートアプリのデータを操作するための広範な権限を持っていました。同様に、システムUIDとして実行されているプロセスは、Androidの権限チェックから除外され、多くの特権操作を実行することが許可されていました。DACの使用は、アプリやシステムプロセスが安全なデフォルトを上書きし、シンボリックリンクのフォローやIPCやfork / execによるセキュリティ境界を越えたファイル/データの漏洩などの危険な動作の影響を受けやすくなることを意味します。さらに、DACメカニズムは、アクセス制御リスト（それぞれ単純なUNIXアクセスビット）をサポートするファイルシステム上のファイルにのみ適用できます。主な意味は、ファイルシステムのFATファミリです。（マイクロ）SDカードやUSBを介して接続されたメディアなどの拡張ストレージで依然として一般的に使用されているものは、DACの適用を直接サポートしていません。Androidでは、各アプリは外部ストレージデバイス上に既知のディレクトリを持ち、そこにアプリのパッケージ名がパスに含まれています（/sdcard/Android/data/com.example）。OSはすでにパッケージ名からUIDへのマッピングを保持しているので、これらのよく知られたディレクトリ内のすべてのファイルにUIDの所有権を割り当て、ネイティブにサポートしていないファイルシステム上に効果的にDACを作成できます。Android 4.4からAndroid 7.xまでは、このマッピングはFUSEを介して実装されていましたが、Android 8.0以降では、パフォーマンス向上のためにカーネル内のsdcardfsが実装されています。両方とも、効果的なDACを実装するためのアプリUIDのマッピングを維持するという点で同等です。各アプリには、アプリのパッケージ名がパスに含まれる外部記憶装置上の既知のディレクトリがあります（例：/sdcard/Android/data/com.example）。OSはすでにパッケージ名からUIDへのマッピングを保持しているので、これらのよく知られたディレクトリ内のすべてのファイルにUIDの所有権を割り当て、ネイティブにサポートしていないファイルシステム上に効果的にDACを作成できます。Android 4.4からAndroid 7.xまでは、このマッピングはFUSEを介して実装されていましたが、Android 8.0以降では、パフォーマンス向上のためにカーネル内のsdcardfsが実装されています。両方とも、効果的なDACを実装するためのアプリUIDのマッピングを維持するという点で同等です。各アプリには、アプリのパッケージ名がパスに含まれる外部記憶装置上の既知のディレクトリがあります（例：/sdcard/Android/data/com.example）。OSはすでにパッケージ名からUIDへのマッピングを保持しているので、これらのよく知られたディレクトリ内のすべてのファイルにUIDの所有権を割り当て、ネイティブにサポートしていないファイルシステム上に効果的にDACを作成できます。Android 4.4からAndroid 7.xまでは、このマッピングはFUSEを介して実装されていましたが、Android 8.0以降では、パフォーマンス向上のためにカーネル内のsdcardfsが実装されています。両方とも、効果的なDACを実装するためのアプリUIDのマッピングを維持するという点で同等です。これらのよく知られたディレクトリ内のすべてのファイルにUIDの所有権を割り当て、ネイティブにサポートしていないファイルシステム上に効果的にDACを作成することができます。Android 4.4からAndroid 7.xまでは、このマッピングはFUSEを介して実装されていましたが、Android 8.0以降では、パフォーマンス向上のためにカーネル内のsdcardfsが実装されています。両方とも、効果的なDACを実装するためのアプリUIDのマッピングを維持するという点で同等です。これらのよく知られたディレクトリ内のすべてのファイルにUIDの所有権を割り当て、ネイティブにサポートしていないファイルシステム上に効果的にDACを作成することができます。Android 4.4からAndroid 7.xまでは、このマッピングはFUSEを介して実装されていましたが、Android 8.0以降では、パフォーマンス向上のためにカーネル内のsdcardfsが実装されています。両方とも、効果的なDACを実装するためのアプリUIDのマッピングを維持するという点で同等です。

その欠点にもかかわらず、UIDサンドボックスは基礎を築き、それでもアプリを互いに分離する主要な強制メカニズムです。サンドボックスの制限を追加する強固な基盤となることが証明されています。これらの欠点は、部分的にはMACポリシーの追加によってだけでなく、実行時のアクセス許可や攻撃対象領域の削減など、他の多くのメカニズムも含めて、後続のリリースに比べていくつかの点で軽減されています（表1を参照）。

上記で定義されているように、ルート化は、DACルールを無効にする「root」ユーザー特権を付与するという意味で、特定のアプリケーションとそのプロセスがこのアプリケーションサンドボックスから抜け出すことを可能にすることを主な目的とします。これは意図的にMACの制限から免除されたプロセスで拡張された応援計画を導きました）。マルウェアは、一時的または恒久的な不正利用を通じてこれらの根ざし手法を適用しようとし、そのためアプリケーションサンドボックスを回避する可能性があります。

4.3.3 スシステムプロセスのサンドボックス

アプリケーションサンドボックスに加えて、AndroidはシステムプロセスのためのUIDサンドボックスの限定されたセットで起動しました。特に、Androidのアーキテクトは、信頼できないメディアコンテンツを処理することに内在するリスクを認識していたので、メディアフレームワークをUID AID_MEDIAに分離しました。UIDの分離を保証するその他のプロセスには、テレフォニースタック、WiFi、およびBluetoothが含まれます（表2を参照）。

4.3.4 カーネルのサンドボックス

Androidのユーザースペースにおけるセキュリティ強化の取り組みにより、カーネルは特権昇格攻撃のターゲットとしてますます魅力的になっています[95]。システムオンチップ（SoC）ベンダが提供するハードウェアドライバが、Android上のカーネルの脆弱性の大部分を占めています[98]。これらのドライバへのアプリ/システムアクセスの削減については上で説明しましたが、カーネル自体の中のサンドボックス化コードもさまざまなリリースにわたって大幅に改善されました（表3を参照）。

4.3.5 カーネルより下層のサンドボックス

カーネルに加えて、Androidデバイスのトラステッドコンピューティングベース（TCB）はブートローダー（通常は複数のステージに分割されています）から始まり、カーネルの下にトラステッド実行環境（TEE）、ハードウェアなどの他のコンポーネントを暗黙的に含みます。ドライバ、ユーザ空間コンポーネントinit、ueventd、vold [25]。現在の最先端技術を考えると、これらすべての合計が十分な複雑さを生み出し、そのうちのいくつかにバグを想定しなければならないことは明らかです。非常に機密性の高いユースケースでは、上記のカーネルお??よびシステムプロセスのバグに対する緩和策でも、潜在的な脆弱性に対する十分な保証を提供できない可能性があります。

したがって、我々は明示的にカーネルの侵害の可能性を考慮します（例えば[T2] - [T4]の物理アクセスに基づくいくつかのカーネルインタフェースを直接攻撃すること、または[T8]のユーザ空間コードから複数のバグを連鎖させること）特定のシナリオでは、脅威モデルの一部として設定ミス（例：不適切または過度に許容されるSELinuxポリシー[34]）、またはバイパス（例：ブートチェーンを変更して無効化されたセキュリティポリシーで別のカーネルをブートする）。明らかに、侵害されたカーネルでは、Androidはもはや互換性の要件を満たしておらず、ユーザーとアプリケーションのためのセキュリティとプライバシーの保証の多くはもはや成り立ちません。ただし、この仮定の下でも、依然としていくつかの脅威から防御することができます。

Keymaster はTEEにAndroidのキーストアを実装して暗号化キーの保存を保護し、ランタイムカーネルが危険にさらされた場合に使用します[14]。つまり、完全にセキュリティが侵害されたカーネルでも、攻撃者はKeymasterに格納されている重要な情報を読み取ることができません。アプリケーションはキーをKeymasterに保存すること、つまりユーザー認証（Gatekeeper / Weaverに関連付けられている）の後にのみアクセス可能にすること、および/またはこれらのキープロパティを検証するために認証証明書を要求することを明示的に要求できます。ルール3による互換性の検証を可能にします。
Strongbox Android 9.0以降で指定されたStrongboxは、Androidキーストアを独立した耐タンパーハードウェア（TRH）に実装して、より優れた分離を実現しています。これは強力な敵対者、例えばコールドブートメモリ攻撃[53]や、Specter / Meltdown [61、69]、Rowhammer [32、99]、Clkscrew [92]のようなハードウェアバグに対して[T1]と[T2]を軽減します。カーネルからTEEへの特権昇格ハードウェアの観点から見ると、メインアプリケーションプロセッサ（AP）は常に専用の安全なハードウェアよりもはるかに大きなアタックサーフェスを持つことになります。別のTRHを追加すると、サンドボックス化されたもう1つの防御層が深くなります。

表1：Androidリリースにおけるアプリケーションサンドボックス化の改善

リリース	改善	脅威を軽減
<=4.3	隔離されたプロセス：アプリは、Androidの権限や2つのバインダサービスへのアクセスなしで、プロセス内でサービスを実行することができます。たとえば、Chromeブラウザは信頼できないWebコンテンツをレンダリングするための独立したプロセスでレンダラを実行します。	[T10] は [T5] [T8] [T9] [T12] [T13]へアクセス
5.x	SELinux：SELinuxはすべてのユーザースペースで有効になり、アプリとシステムプロセスの分離が大幅に改善されました。アプリ間の分離は、依然として主にUIDサンドボックスを介して実施されます。SELinuxの大きな利点は、ポリシーの監査可能性/テスト容易性です。互換性テスト中にセキュリティ要件をテストする機能は、SELinuxの導入により劇的に向上しました。	[T8] [T14]
5.x	Webviewは、フルシステムOTAとは無関係に、更新可能なAPKに移行しました。	[T10]
6.x	実行時の許可が導入されました。これにより、危険な許可の要求がインストールから最初の使用に移りました（上記の許可クラスの説明を参照）。	[T7]
6.x	マルチユーザーサポート：SELinuxカテゴリは、物理ユーザー単位のアプリケーションサンドボックス用に導入されました。	[T3]
6.x	プライベートアプリデータのデフォルトの安全性を向上：アプリのホームディレクトリが0751のUNIXアクセス許可から0700に移動しました（targetSdkVersionに基づく）。	[T9]
6.x	ioctlシステムコールに対するSELinuxの制限：すべてのアプリに到達可能なカーネルの脆弱性の59％がioctl（）システムコールによるものであり、これらの制限によりユーザースペースコードによる潜在的なカーネルの脆弱性の到達可能性が制限されます[95、96]。	[T8] [T14]
6.x	debugfsへのアプリアクセスの削除（アプリにアクセス可能なすべてのカーネル脆弱性のうち9％）。	[T8] [T14]
7.x	hidepid=2：アプリがいつ起動されたかを推測するために使用されていた/proc/サイドチャネルを削除します。	[T11]
7.x	perf-event-hardening（アプリで到達可能なカーネルの脆弱性の11％はperf_event_open()を介して到達された）	[T8]
7.x	より安全なデフォルトの/procファイルシステムアクセス。	[T7] [T11]
7.x	MITM CA証明書は、デフォルトでは信頼されていません。	[T6]
8.x	/sysファイルシステムへのアクセスをより安全にします。	[T7] [T11]
8.x	すべてのアプリは、カーネルの攻撃対象領域を減らすことを目的としたseccompフィルタで動作します。	[T8] [T14]
8.x	すべてのアプリのWebビューは、独立したプロセスに移動します。	[T10]
8.x	平文のネットワークトラフィックを使用するには、アプリをオプトインする必要があります。	[T5]
9.0	アプリごとのSELinuxサンドボックス（targetSdkVersion=P以上のアプリの場合）。	[T9] [T11]

表2：Androidリリースにおけるシステムサンドボックス化の改善

リリース	改善	脅威を軽減
4.4	実施モードのSELinux：4つのルートプロセスのためのMAC制御： installd, netd, vold, zygote	[T7] [T8] [T14]
5.x	SELinux：すべてのユーザースペースプロセスでMACが有効	[T7] [T8]
6.x	SELinux：全プロセスでMACが有効
7.x	mediaserverがアーキテクチャ上で分離	[T7] [T8] [T14]
7.x	システムコンポーネントに対するioctlシステムコールの制限[96]	[T7] [T8] [T14]
8.x	Trebleアーキテクチャによる分離：HAL（Hardware Abstraction Layerコンポーネント）を別々のプロセスに移動し、パーミッションを減らし、ハードウェアドライバへのアクセスを制限します[33、97]	[T7] [T8] [T14]

表3：Androidリリースにおけるカーネルサンドボックス化の改善

リリース	改善	脅威を軽減
5.x	特権実行禁止（PXN）[3]：カーネルによるユーザースペースの実行を禁止します。`ret2user` スタイルの攻撃を防ぎます	[T8] [T14]
6.x	カーネルスレッドはSELinux実施モード(enforcing)に移行し、ユーザースペースファイルへのカーネルアクセスを制限しました	[T8] [T14]
8.x	特権アクセス禁止（PAN: Privileged Access Never）とPANエミュレーション：強化されたcopy-*-user()関数を通らずにカーネルがユーザー空間のメモリにアクセスするのを防ぎます[94]	[T8] [T14]

TEEまたはTRHにキーを格納して使用するだけでは、カーネルが危険にさらされているという前提の下でそれらを使用できなくするという問題を完全に解決することはできません。秘密鍵を必要とする暗号操作のためのオラクルとしてそれを使用してください。これが、鍵を認証に結び付けることができ、および／または、ユーザの同意なしに鍵がバックグラウンドで使用されないことを保証するためにＴＲＨによって検出可能なハードウェアボタンを押すことによるユーザプレゼンス検証を必要とする理由である。

GatekeeperはTEEでユーザーロック画面要素（PIN /パスワード/パターン）の検証を実装し、認証が成功すると、これを認証マスターキーへのアクセスを解放するためにKeymasterに伝えます[16]。WeaverはTRHに同じ機能を実装し、Strongboxと通信します。Android 9.0用に指定され、最初はGoogle Pixel 2およびPixel 3に実装され、 ‘Insider Attack Resistance’（IAR）と呼ばれるプロパティも追加しました。ユーザーのロック画面要素に関する知識なしで、実行中のWeaver/StrongboxコードへのアップグレードTRHでは、デバイス上の暗号化に使用された秘密を消去します[74、102]。つまり、内部のコード署名キーにアクセスしても、ユーザーの協力なしに既存のデータを抽出することはできません。

これもAndroid 9.0 [17]で導入されたProtected Confirmationは、[T11]と[T13]を部分的に軽減します。現在の範囲では、アプリはKeymasterまたはStrongboxに保存されているキーの使用法を、画面にメッセージが表示されていることを確認して（物理ボタンを押すことで）確認することができます。確認時に、アプリは表示されたメッセージのハッシュを受け取ります。これは、ユーザーがメッセージを確認したことをリモートで確認するために使用できます。保護された確認がアプリによって要求されたときにTEEを介して画面出力を制御することによって、（ユーザーの協力なしで）完全なカーネルの侵害でさえこれらの署名された確認を作成することはできません。

4.4 保存データの暗号化

セキュリティモデルを実施するための2番目の要素、特にルール1と3は、メインシステムカーネルが実行されていないかバイパスされている場合（たとえば、不揮発性ストレージから直接読み取ることによって）に必要です。

フルディスク暗号化（FDE）は、資格情報で保護されたキーを使用して、ユーザーデータパーティション全体を暗号化します。FDEはAndroid 5.0で導入されました、そして、[T1]に対して有効である間、それは多くの欠点を持っていました。コアデバイスの機能（緊急ダイヤラ、アクセシビリティサービス、アラームなど）は、パスワードを入力するまでアクセスできませんでした。Android 6.0で導入されたマルチユーザーサポートでは、ディスクアクセスの前にプライマリユーザーのパスワードが必要でした。

これらの欠点は、Android 7.0で導入されたファイルベースの暗号化（FBE）によって軽減されました。TEEまたはTRHを備えたデバイスでは、すべてのキーがこれらの安全な環境内で導出され、Androidカーネルお??よび上記のコンポーネントにアクセスできないハードウェアバインドの乱数を使用してユーザーナレッジファクタに絡み合います。共有デバイス上のユーザーごとのデータを暗号的に保護する[T3]。FBEを搭載したデバイスでは、ダイレクトブートと呼ばれる機能もサポートされています。これにより、ユーザーが資格情報を入力する前に緊急ダイヤラ、アクセシビリティサービス、アラーム、および通話の受信にアクセスできます。

ユーザーデータを効果的に消去することはマスターキーマテリアルを削除することだけを必要とするので、保存データの暗号化はルール4を強制するのに非常に役立ちます。

4.5 転送中のデータの暗号化

Androidは、すべてのネットワークが敵対的であり、攻撃を仕掛けるかまたはトラフィックを狙う可能性があると想定しています。ネットワークレベルの攻撃者がアプリのデータ保護を迂回しないようにするために、Androidはすべてのネットワークトラフィックをエンドツーエンドで暗号化する必要があると考えています。リンクレベルの暗号化が不十分です。これは主に[T5]と[T6]から保護します。

接続で暗号化が使用されるようにすることに加えて、Androidは暗号化が正しく使用されるようにすることに重点を置いています。TLSオプションはデフォルトで安全ですが、開発者がトラフィックをMITM攻撃に対して脆弱なままにするような方法で誤ってTLSをカスタマイズすることは容易であることがわかりました[43、44、52]。表4に、ネットワーク接続をデフォルトで安全にするという点での最近の改善点を示します。

4.6 エクスプロイト緩和

堅牢なセキュリティシステムは、ソフトウェアの脆弱性が存在することを想定し、それらに対して積極的に防御する必要があります。歴史的に、Androidのセキュリティ脆弱性の約85％は、安全でないメモリアクセスが原因です（[62、54]を参照）。このセクションでは、主にメモリの安全性の低下に対する緩和策について説明しますが、最良の防御策はJavaなどの言語によって提供されるメモリの安全性です。Androidフレームワークの大部分はJavaで書かれており、あらゆる種類のセキュリティバグからOSの大きな領域を効果的に防御します。

Androidは、ASLR [29、86]、RWXメモリの制限（例：W?X、[85]を参照）、バッファオーバーフロー保護（スタック用のスタックプロテクタ、およびヒープ用のアロケータ保護など）を含む、いくつかの緩和策の使用を義務付けています。Androidカーネルにも同様の保護が義務付けられています[94]。

上記の緩和策に加えて、Androidは積極的に追加の緩和策を展開しています。最初はリモートで到達可能なコード領域（例：メディアフレームワーク[26]）または重大度の高いセキュリティ脆弱性の歴史（例カーネル）を持ちます。Androidは、メディアフレームワークおよびその他のセキュリティに敏感なコンポーネントの整数オーバーフローの脆弱性から保護するために、プロダクションデバイスでLLVM未定義動作サニタイザ（UBSAN）を使用することを先導してきました。Androidは、メディア、Bluetooth、WiFi、NFC、パーサーなど、カーネルお??よびセキュリティに敏感なユーザースペースコンポーネントにLLVM制御フロー整合性（CFI）を展開しています[71]。

これらの緩和方法は、隔離および封じ込めメカニズムと連携して機能し、多くの防御層を形成します。1つの層が失敗したとしても、他のメカニズムは搾取チェーンの成功を防ぐことを目的としています。緩和メカニズムは、アプリが書かれている言語について追加の仮定を置くことなく、規則2と3を守るのにも役立ちます。

4.7 システムの完全性

最後に、システム（デバイスとも呼ばれる）の整合性は、攻撃者が永続的な足場を築くことに対する重要な防御策です。Android KitKat以来、AOSPはLinuxカーネルのdm-verityサポートを使用したVerified Bootをサポートしており、AndroidのTCB（Trusted Computing Base）とシステムコンポーネントにルール4を実装するための強力な整合性の強化を提供します。検証済みブート[19]はAndroid Nougat以降（50MiB /秒以上のAES暗号化を実行できないデバイスには免除が付与されています）から義務付けられており、ブートを検証することによってブートチェーンの変更を検出可能にします。

表4：Androidリリースにおけるネットワークサンドボックス化の改善

リリース	改善	脅威を軽減
6.x	意図しない平文の接続を防ぐために明示的にusesCleartextTrafficを使う[31]。	[T5] [T6]
7.x	TLSおよび平文の設定を宣言的にドメイン単位またはアプリケーション全体で指定してTLS接続をカスタマイズするためのネットワークセキュリティ設定[18]。	[T5] [T6]
9.0	DNS-over-TLS [60]は、平文で送信される機密データを削減し、ネットワークセキュリティ設定で平文トラフィックを使用することをアプリに選択させます。	[T5] [T6]

TEE、および追加のベンダー/ OEMパーティション、およびシステムパーティション上のブロックのオンアクセス検証を実行します[20]。つまり、以前のすべての防御層が失敗した後でも、攻撃者はTCBを恒久的に変更することはできず、カーネルのセキュリティが侵害されることになります。これはプライマリブートローダを信頼のルートとして引き継ぐことを前提としていることに注意してください。これは通常、ROMマスクで十分に単純なコードで実装されているので、その段階での重大なバグは起こりにくいです。

さらに、ハードウェアサポートによるロールバック保護により、既知の脆弱性を悪用され、悪用される可能性がある、正しく署名されているが古いシステムイメージが攻撃されるのを防ぐことができます。最後に、検証済みブート状態はdeviceLockedフィールドとVerifiedBootStateフィールドの主要な証明書証明書（Keymaster / Strongboxによって提供される）に含まれています。これは、アプリケーションによって検証でき、ブートの整合性をリモートで検証するためにバックエンドサービスに渡されます。

アプリケーションの整合性はAPK署名によって強化されます[22]。すべてのアプリは署名されており、新しいAPKが同じIDまたは元の署名者によって委任されたIDで署名されている場合にのみ更新プログラムをインストールできます。

Android 9.0では、更新可能なアプリのみが検証済みブートの対象になりません。アップデート可能なアプリの完全性は、インストール/アップデート中にAndroidのPackageManagerによってチェックされます。本ペーパーの執筆時点では、他のCPU用（さまざまな無線チップセット、GPU、タッチスクリーンコントローラなどを含むがこれらに限定されない）のファームウェアの整合性はAndroid Verified Bootの範囲外であり、通常はOEM固有のブートローダーによって処理されます。

4.8 パッチ

以前のすべての防御メカニズムと直交して、脆弱なコードはいずれかの層で発見された穴を埋めるために修正されるべきです。定期的なパッチ適用は別の防御層と見なすことができます。ただし、更新されたコードを巨大で多様なAndroidエコシステムに出荷することは難題です（これが多層防御戦略を適用する理由の1つです）。

2015年8月から、Androidは毎月のセキュリティ情報を公開し、セキュリティの脆弱性に対するパッチがGoogleに報告されました。エコシステムの多様性に対処するために、Androidデバイスの更新にかかる時間とコストを削減することを目的として、プロジェクトTrebleがAndroid 8.0で開始されました[72、76]。

2018年、Android Enterprise RecommendedプログラムとOEMとの一般契約により、90日間保証付きセキュリティアップデートの要件が追加されました[23]。

5 特別なケース

さまざまな当事者の特定のニーズのバランスをとるために抽象的セキュリティモデルからの意図的な逸脱を必要とする特別なケースがいくつかあります。このセクションではこれらのいくつかについて説明しますが、包括的なリストになることを意図していません。Androidセキュリティモデルを公に定義することの1つの目的は、AOSPの実装と私たちが説明したモデルを比較することによって、研究者が潜在的な追加のギャップを発見し、それらの特別な場合について会話することです。

パッケージの一覧表示：現在、オープンエコシステムの原則（ルール2）から派生した直接的なアプリ間通信には、アプリの検出が必要です。
VPNアプリは他のアプリのネットワークトラフィックを監視/ブロックすることができる あるアプリが別のアプリからのトラフィックを見て影響を与える可能性があるため（開発者の同意）、これは一般にアプリケーションサンドボックスモデルからの逸脱です。プライバシーやデータ使用制御の向上など、ユーザーに提供する価値のため、およびユーザーの同意が明確であるために、VPNアプリケーションには免除が与えられます。エンドツーエンドの暗号化を使用するアプリケーションの場合、平文のトラフィックはVPNアプリケーションで利用できず、アプリケーションサンドボックスの機密性が部分的に復元されます。
バックアップ：プライベートアプリディレクトリのデータはデフォルトでバックアップされます。アプリはマニフェストにフィールドを設定してオプトアウトすることができます。
エンタープライズ：Androidでは、いわゆるデバイス所有者（DO）またはプロファイル所有者（PO）のポリシーをデバイスポリシーコントローラー（DPC）アプリで実施することができます。DOはプライマリ/メインユーザーアカウントにインストールされ、POは作業プロファイルとして機能するセカンダリユーザーにインストールされます。仕事用プロファイルを使用すると、単一のデバイスで個人データと企業データを分離でき、Androidのマルチユーザーサポートに基づいています。この分離は、アプリを互いに保護しながらプロファイル間の大幅に厳密な分割を実装する、同じ分離方法と包含方法によって強化されています[8]。DPCは、同意モデルに第4者を紹介します。ポリシーが他のすべての者による同意に加えて（たとえば、POによって管理される作業プロファイル内で）アクションを許可する場合に限り、それを実行できます。個人的なプロファイルと仕事のプロファイルの区別は、最近のさまざまなユーザー知識要素のサポート（4.2項で説明したようにロック画面によって処理される）によって強化されています。POによって管理されているがフルデバイス制御（すなわち、DO）が行われていない作業プロファイルを持つデバイスでは、個人プロファイルのプライバシー保証は依然としてこのセキュリティモデルの下で保持する必要があります。
ファクトリリセット保護（FRP）：ファクトリリセットをまたいで永続データを格納しないことの例外です（ルール4）が、盗難およびファクトリリセットの脅威を軽減するためのモデルのこの部分からの意図的な逸脱です（[T1] [T2]）

6 関連研究

古典的なオペレーティングシステムのセキュリティモデルは主にdefに関係していますサブジェクト（ほとんどの場合、シングルユーザー、グループ、またはロール）によるオブジェクト（通常はOSによって制御されるファイルやその他のリソース、アクセス権と組み合わせて保護ドメインとも呼ばれる）へのアクセス制御（読み取り/書き込み/実行またはより細かい） [91]）。概念的には疎行列であるこれらの関係を効率的に実装するための最も一般的なデータ構造は、アクセス制御リスト（ACL）[83]と機能リスト（例えば[100]）です。最初の有名でよく定義されたモデルの1つはBell-LaPadulaマルチレベルセキュリティモデル[27]で、これはパーミッションを割り当てるためのプロパティを定義し、SELinuxのようなMACとType Enforcementスキームの抽象的な基礎と見なすことができます。その結果、Androidプラットフォームのセキュリティモデルは、これらの一般的なモデルと最小限の特権の原則に基づいて暗黙的に構築されています。

1つの根本的な違いは、古典的モデルはユーザーによって開始されたプロセスがそれらのアクションの代理であり、したがってユーザー特権で直接実行されると仮定し、より現代的なモデルはユーザーによって開始されたマルウェアの脅威を明確に認め、したがってそれらのアクションを区分化することを目的とします。多くのモバイルOS（以前の例としてSymbianを含む）は、ユーザーではなくプロセス（つまりアプリケーション）に権限を割り当てています。Androidは同等のアプローチを使用しています。本稿では他のモバイルOSとのより詳細な比較は対象外であり、他の調査[41]、[64]、[77]、およびAndroidセキュリティメカニズムの以前の分析およびマルウェアによる弱点の活用方法[4, 42, 46, 66-68, 103]を参照してください。

7 まとめ

本稿では、Androidプラットフォームのセキュリティモデルと、それが動作するために必要な複雑な脅威モデルとエコシステムについて説明しました。抽象的なルールの1つは、ほとんどの標準OSセキュリティモデルとは異なるという意味でのマルチパーティ同意モデルです。プラットフォームの実装、そして明らかにユーザーが持っているのと同じ意味で、アプリケーションはアクションに対して同等の拒否権を持つと暗黙的に考えています。これはユーザーの観点からは制限的に見えるかもしれませんが、悪意のあるアプリが他のアプリによって制御されているデータに悪用される可能性を事実上制限します。すべてのデータへのフィルタリングされていないアクセスを持つ強力なユーザーアカウントを回避することによって（最新のデスクトップ/サーバーOSのデフォルト）、ファイル暗号化ランサムウェアや直接データ漏洩などの脅威のクラス全体は実用的でなくなります。

AOSPは、Androidプラットフォームのセキュリティモデルと、「多層防御」および「デフォルトで安全」という一般的なセキュリティ原則を実装しています。さまざまなセキュリティメカニズムが複数の防御層として組み合わされています。重要な点は、セキュリティ関連のバグが存在しても、必ずしも標準のユーザースペースコードから到達可能なエクスプロイトにつながるとは限らないことです。現在のモデルとその実装はすでにAndroidのセキュリティとプライバシーの考慮事項の範囲内にある脅威モデルのほとんどをカバーしていますが、概念的に単純なセキュリティモデルにはいくつかの意図的な特別な場合があります。

キーストアは、ハードウェアまたは認証にバインドされたキーを要求するためのAPIフラグ/メソッドをすでにサポートしています。ただし、アプリはこれらのメソッドを明示的に使用してStrongboxのような改善の恩恵を受ける必要があります。TLS接続用のネットワークセキュリティ設定に似た宣言型の使用をサポートすることで、アプリケーションファイルまたはディレクトリの暗号化をより透過的にすると、アプリケーション開発者がこれらの機能を安全に使用するのが容易になります。
マルウェアは、検出された特定の脆弱性を悪用し、ペイロードをアプリストアでスキャンできないようにするために、インストールされているそれぞれのデバイスに応じて第2段階を動的にロードするのが一般的です。1つの潜在的な緩和策は、すべての実行可能コードに次のことを要求することです。a）それぞれのAndroidインスタンスによって信頼されている鍵によって署名される（例えば、ファームウェアに出荷されている公開鍵による）および/またはエンドユーザーによる追加またはb）アプリケーションバンドル自体（APKファイル）に含まれていないコードを実行時に動的にロードまたは作成する特別な権限を持っている。これによりコードの整合性をより適切に制御できますが、それでもこれらのアプリの作成に使用される言語やプラットフォームが制限されることはありません。この緩和策は実行可能コードに限定されることが認識されています。
高度な攻撃者は、OEMまたはベンダのコード署名キーにアクセスする可能性があります。そのような状況下でも、ユーザーにある程度のセキュリティとプライバシーの保証を依然として保持することは有益です。最近の例の1つは、TRH [102]の更新可能なコードに対する ‘Insider Attack Resistance’（IAR）の仕様と実装であり、同様の防御をより高いレベルのソフトウェアに拡張することが望ましい[74]。潜在的なアプローチは、例えば証明書の透明性[65]に匹敵する再現可能なファームウェアビルドまたはリリースされたファームウェアハッシュのログです。
W?Xメモリは、Androidを含む現在のほとんどのOSですでに標準の保護メカニズムです。しかし、実行可能であるが書き込み可能ではないページは通常はまだ読み取り可能であり、そのような読み取りアクセスは、例えばROPガジェットの場所をリークする可能性があります。改善の可能性としては、コードページへのアクセスを実行のみで、読み取りさえできないように制限すること（実行専用ページ）があります。
ハードウェアレベルの攻撃はより一般的になってきているので、例えばRAM関連の攻撃に対する追加の（ソフトウェアおよびハードウェア）防御は別の防御層を追加するでしょうが、おそらくパフォーマンスオーバーヘッドのトレードオフがあります。

ただし、そのような将来の作業はすべて、より広範なエコシステムへの影響を考慮して行う必要があり、Androidの基本的なセキュリティ原則に沿って維持する必要があります。

謝辞

私たちは、Androidプラットフォームのセキュリティの歴史の大部分と、このホワイトペーパーの以前の草稿に対する洞察に満ちた発言に対する彼女の影響力のある作業について、Dianne Hackbornに感謝します。また、Joel Galenson氏、Ivan Lozano氏、Paul Crowley氏、Shawn Willden氏、Jeff Sharkey氏、Xiaowen Xin氏のさまざまな部分へのインプットに感謝します。特に認証セクションへの直接の貢献にはVishwath Mohan氏に感謝します。私たちはまた、長年にわたってAndroidを改良してきた膨大な数のセキュリティ研究者（https://source.android.com/security/overview/cknowledgement ）と、この文書の以前のドラフトに非常に有益なフィードバックを寄せてくれた匿名のレビューアに感謝します。

参考文献

[1] url: https://www.stonetemple.com/mobile-vs-desktopusage-study/ (visited on 2018-07-30).
[2] url: http://gs.statcounter.com/platform-market-share/desktop-mobile-tablet (visited on 2018-07-30).
[3] url: https://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_execution (visited on 2018-07-30).
[4] Y. Acar, M. Backes, S. Bugiel, S. Fahl, P. McDaniel, and M. Smith. “SoK: Lessons Learned from Android Security Research for Appified Software Platforms”. In: 2016 IEEE Symposium on Security and Privacy (SP). May 2016, pp. 433. 451. doi: 10.1109/SP.2016.33.
[5] A. Adams and M. A. Sasse. “Users Are Not the Enemy”. In: Commun. ACM 42.12 (Dec. 1999), pp. 40.46. issn: 0001-0782. doi: 10.1145/322796.322806.
[6] A. Ahn. How we fought bad apps and malicious developers in 2017. Jan. 2018. url: https://android-developers.googleblog.com/2018/01/how-we-fought-bad-apps-and-malicious.html.
[7] B. B. Anderson, A. Vance, C. B. Kirwan, J. L. Jenkins, and D. Eargle. “From Warning to Wallpaper: Why the Brain Habituates to Security Warnings and What Can Be Done About It”. In: Journal of Management Information Systems 33.3 (2016), pp. 713.743. doi: 10.1080/07421222.2016.12439 47.
[8] Android Enterprise Security White Paper. Sept. 2018. url: https://source.android.com/security/reports/Google_Android_Enterprise_Security_Whitepaper_2018.pdf (visited on 2018-11-14).
[9] Android Security 2017 Year In Review. Mar. 2018. url: https://source.android.com/security/reports/Google_Android_Security_2017_Report_Final.pdf.
[10] AOSP. url: https://source.android.com/compatibility/cdd (visited on 2018-11-14).
[11] AOSP. url: https://developer.android.com/guide/components/intents-filters (visited on 2018-11-14).
[12] AOSP. url: https://developer.android.com/guide/topics/manifest/manifest-intro (visited on 2018-11-14).
[13] AOSP. url: https://developer.android.com/guide/topics/manifest/permission-element (visited on 2018-11-14).
[14] AOSP. url: https://source.android.com/security/keystore/ (visited on 2018-11-14).
[15] AOSP. url: https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec (visited on 2018-11-14).
[16] AOSP. url: https://source.android.com/security/authentication/gatekeeper (visited on 2018-11-14).
[17] AOSP. url: https://developer.android.com/preview/features/security#android-protected-confirmation (visited on 2018-11-14). https://developer.android.com/training/articles/security-android-protected-confirmation
[18] AOSP. url: https://developer.android.com/training/articles/security-config (visited on 2018-11-14).
[19] AOSP. url: https://source.android.com/security/verifiedboot/verified-boot (visited on 2018-11-14).
[20] AOSP. url: https://android.googlesource.com/platform/external/avb/+/pie-release/README.md (visited on 2018- 11-14).
[21] AOSP. url: https://developer.android.com/training/articles/security-key-attestation (visited on 2018-11-14).
[22] AOSP. url: https://source.android.com/security/apksigning/ (visited on 2018-11-14).
[23] AOSP. url: https://www.android.com/enterprise/recommended/requirements/ (visited on 2018-11-14).
[24] AOSP. Android platform permissions requesting guidance. url: https://material.io/design/platform-guidance/androidpermissions.html#request-types (visited on 2019-03-06).
[25] AOSP. Security Updates and Resources - Process Types. url: https://source.android.com/security/overview/updatesresources#process_types.
[26] D. Austin and J. Vander Stoep. Hardening the media stack. May 2016. url: https://android-developers.googleblog.com/2016/05/hardening-media-stack.html.
[27] D. Bell and L. LaPadula. Secure Computer System Unified Exposition and Multics Interpretation. Tech. rep. MTR-2997. MITRE Corp., July 1975.
[28] J. Bender. Google Play security metadata and offline app distribution. June 2018. url: https://android-developers.googleblog.com/2018/06/google-play-security-metadataand.html.
[29] S. Bhatkar, D. C. DuVarney, and R. Sekar. “Address Obfuscation: An Efficient Approach to Combat a Board Range of Memory Error Exploits”. In: Proc. USENIX Security Symposium - Volume 12. USENIX Association, 2003, pp. 8.8. url: http://dl.acm.org/citation.cfm?id=1251353.1251361.
[30] BlueBorne. 2017. url: https://go.armis.com/hubfs/BlueBorne%20-%20Android%20Exploit%20(20171130).pdf?t=1529364695784.
[31] C. Brubaker. Introducing nogotofail. a network traffic security testing tool. Nov. 2014. url: https://security.googleblog.com/2014/11/introducing-nogotofaila-network-traffic.html.
[32] P. Carru. Attack TrustZone with Rowhammer. Apr. 2017. url: http://www.eshard.com/wp-content/plugins/emailbefore-download/download.php?dl=9465aa084ff0f070a3acedb56bcb34f5.
[33] D. Cashman. SELinux in Android O: Separating Policy to Allow for Independent Updates. Linux Security Summit. 2017. url: https://events.static.linuxfound.org/sites/events/files/slides/LSS%20-%20Treble%20%27n%27%20SELinux.pdf.
[34] H. Chen, N. Li, W. Enck, Y. Aafer, and X. Zhang. “Analysis of SEAndroid Policies: Combining MAC and DAC in Android”. In: Proceedings of the 33rd Annual Computer Security Applications Conference. ACM, 2017, pp. 553.565. isbn: 978-1-4503-5345-8. doi: 10.1145/3134600.3134638.
[35] E. Cunningham. Improving app security and performance on Google Play for years to come. Dec. 2017. url: https://android-developers.googleblog.com/2017/12/improvingapp-security-and-performance.html.
[36] CVE-2017-13177. Aug. 2017. url: https://cve.mitre.org/cgibin/cvename.cgi?name=CVE-2017-13177 (visited on 2018-06-27).
[37] CVE-2017-17558: Remote code execution in media frameworks. June 2018. url: https://source.android.com/security/bulletin/2018-06-01#kernel-components (visited on 2018- 06-27).
[38] CVE-2018-9341: Remote code execution in media frameworks. June 2018. url: https://source.android.com/security/bulletin/2018-06-01#media-framework (visited on 2018-06- 27).
[39] R. Dhamija, J. D. Tygar, and M. Hearst. “Why Phishing Works”. In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. ACM, 2006, pp. 581.590. isbn: 1-59593-372-7. doi: 10.1145/1124772.1124861.
[40] D. Dolev and A. C.-c. Yao. “On the security of public key protocols”. In: IEEE Transactions on Information Theory 29 (2 1983), pp. 198.208. doi: 10.1109/TIT.1983.1056650.
[41] A. Egners, B. Marschollek, and U. Meyer. Hackers in Your Pocket: A Survey of Smartphone Security Across Platforms. Tech. rep. 2012,7. RWTH Aachen University, Jan. 2012. url: https://itsec.rwth-aachen.de/publications/ae_hacker_in_your_pocket.pdf.
[42] W. Enck, M. Ongtang, and P. McDaniel. “Understanding Android Security”. In: IEEE Security Privacy 7.1 (Jan. 2009), pp. 50.57. issn: 1540-7993. doi: 10.1109/MSP.2009.26.
[43] S. Fahl, M. Harbach, T. Muders, L. Baumgartner, B. Freisleben, and M. Smith. “Why Eve and Mallory Love Android: An Analysis of Android SSL (in)Security”. In: Proceedings of the 2012 ACM Conference on Computer and Communications Security. ACM, 2012, pp. 50.61. isbn: 978-1-4503-1651-4. doi: 10.1145/2382196.2382205.
[44] S. Fahl, M. Harbach, H. Perl, M. Koetter, and M. Smith. “Rethinking SSL Development in an Appified World”. In: Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security. ACM, 2013, pp. 49.60. isbn: 978-1-4503-2477-9. doi: 10.1145/2508859.2516655.
[45] H. Falaki, R. Mahajan, S. Kandula, D. Lymberopoulos, R. Govindan, and D. Estrin. “Diversity in Smartphone Usage”. In: Proc. 8th International Conference on Mobile Systems, Applications, and Services. ACM, 2010, pp. 179.194. isbn: 978-1-60558-985-5. doi: 10.1145/1814433.1814453.
[46] P. Faruki, A. Bharmal, V. Laxmi, V. Ganmoor, M. S. Gaur, M. Conti, and M. Rajarajan. “Android Security: A Survey of Issues, Malware Penetration, and Defenses”. In: IEEE Communications Surveys Tutorials 17.2 (2015), pp. 998.1022. issn: 1553-877X. doi: 10.1109/COMST.2014.2386139.
[47] A. P. Felt, S. Egelman, M. Finifter, D. Akhawe, and D. A. Wagner. “How to Ask for Permission”. In: HotSec. 2012.
[48] A. P. Felt, E. Ha, S. Egelman, A. Haney, E. Chin, and D.Wagner. “Android Permissions: User Attention, Comprehension, and Behavior”. In: Proceedings of the Eighth Symposium on Usable Privacy and Security. ACM, 2012, 3:1.3:14. isbn: 978-1-4503-1532-6. doi: 10.1145/2335356.2335360.
[49] E. Fernandes, Q. A. Chen, J. Paupore, G. Essl, J. A. Halderman, Z. M. Mao, and A. Prakash. “Android UI Deception Revisited: Attacks and Defenses”. en. In: Financial Cryptography and Data Security. Springer, Berlin, Heidelberg, Feb. 2016, pp. 41.59. isbn: 978-3-662-54969-8. doi: 10.1007/978- 3-662-54970-4_3.
[50] N. Fischer. Protecting WebView with Safe Browsing. Apr. 2018. url: https://android-developers.googleblog.com/2018/04/protecting-webview-with-safe-browsing.html.
[51] Y. Fratantonio, C. Qian, S. Chung, and W. Lee. “Cloak and Dagger: From Two Permissions to Complete Control of the UI Feedback Loop”. In: Proceedings of the IEEE Symposium on Security and Privacy (Oakland). May 2017.
[52] M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and V. Shmatikov. “The most dangerous code in the world: validating SSL certificates in non-browser software”. In: ACM Conference on Computer and Communications Security. 2012, pp. 38.49.
[53] J. A. Halderman, S. D. Schoen, N. Heninger, W. Clarkson, W. Paul, J. A. Calandrino, A. J. Feldman, J. Appelbaum, and E. W. Felten. “Lest We Remember: Cold-boot Attacks on Encryption Keys”. In: Commun. ACM 52.5 (May 2009), pp. 91.98. issn: 0001-0782. doi: 10.1145/1506409.1506429.
[54] D. Hintze, R.D. Findling, M. Muaaz, S. Scholz, and R. Mayrhofer. “Diversity in Locked and Unlocked Mobile Device Usage”. In: Proceedings of the 2014 ACM International Joint Conference on Pervasive and Ubiquitous Computing: Adjunct Publication (UbiComp 2014). ACM Press, 2014, pp. 379.384. isbn: 978-1-4503-3047-3. doi: 10.1145/2638728.2641697.
[55] D. Hintze, R. D. Findling, S. Scholz, and R. Mayrhofer. “Mobile Device Usage Characteristics: The Effect of Context and Form Factor on Locked and Unlocked Usage”. In: Proc. MoMM 2014: 12th International Conference on Advances in Mobile Computing and Multimedia. ACM Press, Dec. 2014, pp. 105.114. isbn: 978-1-4503-3008-4. doi: 10.1145/2684103. 2684156.
[56] D. Hintze, P. Hintze, R. D. Findling, and R. Mayrhofer. “A Large-Scale, Long-Term Analysis of Mobile Device Usage Characteristics”. In: Proc. ACM Interact. Mob.Wearable Ubiquitous Technol. 1.2 (June 2017), 13:1.13:21. issn: 2474-9567. doi: 10.1145/3090078.
[57] S. Hobarth and R. Mayrhofer. “A framework for on-device privilege escalation exploit execution on Android”. In: Proc. IWSSI/SPMU 2011: 3rd International Workshop on Security and Privacy in Spontaneous Interaction and Mobile Phone Use, colocated with Pervasive 2011. June 2011.
[58] Y. Jang, C. Song, S. P. Chung, T. Wang, and W. Lee. “A11Y Attacks: Exploiting Accessibility in Operating Systems”. In: Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2014, pp. 103. 115. isbn: 978-1-4503-2957-6. doi: 10.1145/2660267.2660295.
[59] A. Kharraz, W. Robertson, D. Balzarotti, L. Bilge, and E. Kirda. “Cutting the Gordian Knot: A Look Under the Hood of Ransomware Attacks”. In: Detection of Intrusions and Malware, and Vulnerability Assessment. Springer International Publishing, 2015, pp. 3.24. isbn: 978-3-319-20550-2.
[60] E. Kline and B. Schwartz. DNS over TLS support in Android P Developer Preview. Apr. 2018. url: https://androiddevelopers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html.
[61] P. Kocher, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y. Yarom. “Spectre Attacks: Exploiting Speculative Execution”. In: arXiv:1801.01203 - [cs] (2018). url: http://arxiv.org/abs/1801.01203.
[62] N. Kralevich. The Art of Defense: How vulnerabilities help shape security features and mitigations in Android. Black- Hat. 2016. url: https://www.blackhat.com/docs/us-16/materials/us-16-%20Kralevich-The-Art-Of-Defense-How-%20Vulnerabilities-Help-Shape-%20%5C%20Security-Features-And-Mitigations-In-Android.pdf.
[63] J. Kraunelis, Y. Chen, Z. Ling, X. Fu, and W. Zhao. “On Malware Leveraging the Android Accessibility Framework”. In: Mobile and Ubiquitous Systems: Computing, Networking, and Services. Springer International Publishing, 2014, pp. 512. 523. isbn: 978-3-319-11569-6.
[64] M. La Polla, F. Martinelli, and D. Sgandurra. “A Survey on Security for Mobile Devices”. In: 15 (Jan. 2013), pp. 446.471.
[65] B. Laurie, A. Langley, and E. Kasper. Certificate Transparency. 2013. url: https://www.rfc-editor.org/info/rfc6962 (visited on 2018-06-29).
[66] L. Li, A. Bartel, J. Klein, Y. L. Traon, S. Arzt, S. Rasthofer, E. Bodden, D. Octeau, and P. McDaniel. “I know what leaked in your pocket: uncovering privacy leaks on Android Apps with Static Taint Analysis”. In: arXiv:1404.7431 - [cs] (Apr. 2014). url: http://arxiv.org/abs/1404.7431.
[67] L. Li, T. F. Bissyande, M. Papadakis, S. Rasthofer, A. Bartel, D. Octeau, J. Klein, and L. Traon. “Static analysis of Android apps: A systematic literature review”. In: Information and Software Technology 88 (2017), pp. 67.95. issn: 0950-5849. doi: 10.1016/j.infsof.2017.04.001.
[68] M. Lindorfer, M. Neugschwandtner, L. Weichselbaum, Y. Fratantonio, V. v. d. Veen, and C. Platzer. “ANDRUBIS . 1,000,000 Apps Later: A View on Current Android Malware Behaviors”. In: 2014 Third International Workshop on Building Analysis Datasets and Gathering Experience Returns for Security (BADGERS). Sept. 2014, pp. 3.17. doi: 10.1109/BADGERS.2014.7.
[69] M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, S. Mangard, P. Kocher, D. Genkin, Y. Yarom, and M. Hamburg. “Meltdown”. In: arXiv:1801.01207 - [cs] (2018). url: http://arxiv.org/abs/1801.01207.
[70] T. Lodderstedt, M. McGloin, and P. Hunt. OAuth 2.0 Threat Model and Security Considerations. Jan. 2013. url: https://www.rfc-editor.org/info/rfc6819.
[71] I. Lozano. Compiler-based security mitigations in Android P. June 2018. url: https://android-developers.googleblog.com/2018/06/compiler-based-security-mitigations-in.html.
[72] I. Malchev. Here comes Treble: A modular base for Android. May 2017. url: https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html.
[73] R. Mayrhofer. “An Architecture for Secure Mobile Devices”. In: Security and Communication Networks (2014). issn: 1939- 0122. doi: 10.1002/sec.1028.
[74] R. Mayrhofer. “Insider Attack Resistance in the Android Ecosystem”. In: Enigma 2019. USENIX Association, Jan. 2019.
[75] R. Mayrhofer, S. Sigg, and V. Mohan. “Adversary Models for Mobile Device Authentication”. In: (). submitted for review.
[76] T. McDonnell, B. Ray, and M. Kim. “An Empirical Study of API Stability and Adoption in the Android Ecosystem”. In: 2013 IEEE International Conference on Software Maintenance. Sept. 2013, pp. 70.79. doi: 10.1109/ICSM.2013.18.
[77] I. Mohamed and D. Patel. “Android vs iOS Security: A Comparative Study”. In: 2015 12th International Conference on Information Technology - New Generations. Apr. 2015, pp. 725. 730. doi: 10.1109/ITNG.2015.123.
[78] V. Mohan. Better Biometrics in Android P. June 2018. url: https://android-developers.googleblog.com/2018/06/better-biometrics-in-android-p.html.
[79] V. Nanda and R. Mayrhofer. Android Pie a la mode: Security & Privacy. Dec. 2018. url: https://android-developers.googleblog.com/2018/12/android-pie-la-mode-securityprivacy.html.
[80] S. Pichai. Android has created more choice, not less. July 2018. url: https://blog.google/around-the-globe/googleeurope/android-has-created-more-choice-not-less/.
[81] P. Riedl, R. Mayrhofer, A. Moller, M. Kranz, F. Lettner, C. Holzmann, and M. Koelle. “Only play in your comfort zone: interaction methods for improving security awareness on mobile devices”. English. In: Personal and Ubiquitous Computing (Mar. 2015), pp. 1.14. issn: 1617-4909. doi: 10.1007/ s00779-015-0840-5.
[82] F. Roesner, T. Kohno, E. Moshchuk, B. Parno, H. J.Wang, and C. Cowan. “User-driven access control: Rethinking permission granting in modern operating systems”. In: Proceedings of the 2012 IEEE Symposium on Security and Privacy, ser. SP ‘12. 2012, pp. 224.238. doi: 10.1109/SP.2012.24.
[83] R. S. Sandhu and P. Samarati. “Access control: principle and practice”. In: IEEE Communications Magazine 32.9 (Sept. 1994), pp. 40.48. issn: 0163-6804. doi: 10.1109/35.312842.
[84] N. Scaife, H. Carter, P. Traynor, and K. R. B. Butler. “CryptoLock (and Drop It): Stopping Ransomware Attacks on User Data”. In: 2016 IEEE 36th International Conference on Distributed Computing Systems (ICDCS). June 2016, pp. 303. 312. doi: 10.1109/ICDCS.2016.46.
[85] A. Seshadri, M. Luk, N. Qu, and A. Perrig. “SecVisor: A Tiny Hypervisor to Provide Lifetime Kernel Code Integrity for Commodity OSes”. In: Proceedings of Twenty-first ACM SIGOPS Symposium on Operating Systems Principles. ACM, 2007, pp. 335.350. isbn: 978-1-59593-591-5. doi: 10.1145/ 1294261.1294294.
[86] H. Shacham, M. Page, B. Pfaff, E.-J. Goh, N. Modadugu, and D. Boneh. “On the Effectiveness of Address-space Randomization”. In: Proceedings of the 11th ACM Conference on Computer and Communications Security. ACM, 2004, pp. 298. 307. isbn: 1-58113-961-6. doi: 10.1145/1030083.1030124.
[87] S. Smalley and R. Craig. “Security Enhanced (SE) Android: Bringing Flexible MAC to Android”. en. In: Proc. of NDSS 2013. Apr. 2013, p. 18.
[88] Stagefright Vulnerability Report. 2015. url: https://www.kb.cert.org/vuls/id/924951.
[89] SVE-2018-11599: Theft of arbitrary files leading to emails and email accounts takeover. May 2018. url: https://security.samsungmobile.com/securityUpdate.smsb (visited on 2018- 06-27).
[90] SVE-2018-11633: Buffer Overflow in Trustlet. May 2018. url: https://security.samsungmobile.com/securityUpdate.smsb (visited on 2018-06-27).
[91] A. S. Tanenbaum and H. Bos. Modern Operating Systems. 4th. Prentice Hall Press, 2014. isbn: 013359162X, 9780133591620.
[92] A. Tang, S. Sethumadhavan, and S. Stolfo. “CLKSCREW: Exposing the Perils of Security-Oblivious Energy Management”. In: 26th USENIX Security Symposium (USENIX Security 17). USENIX Association, 2017, pp. 1057.1074. isbn: 978- 1-931971-40-9. url: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/tang.
[93] S. D. Tetali. Keeping 2 Billion Android devices safe with machine learning. May 2018. url: https://android-developers.googleblog.com/2018/05/keeping-2-billion-android-devices-safe.html.
[94] S. Tolvanen. Hardening the Kernel in Android Oreo. Aug. 2017. url: https://android-developers.googleblog.com/2017/08/hardening-kernel-in-android-oreo.html.
[95] J. Vander Stoep. Android: Protecting the Kernel. Linux Security Summit. 2016. url: https://events.static.linuxfound.org/sites/events/files/slides/Android-%20protecting% 20the%20kernel.pdf.
[96] J. Vander Stoep. Ioctl Command Whitelisting in SELinux. Linux Security Summit. 2015. url: http://kernsec.org/files/lss2015/vanderstoep.pdf.
[97] J. Vander Stoep. Shut the HAL up. July 2017. url: https://android-developers.googleblog.com/2017/07/shut-halup.html.
[98] J. Vander Stoep and S. Tolvanen. Year in Review: Android Kernel Security. Linux Security Summit. 2018. url: https://events.linuxfoundation.org/wp-content/uploads/2017/11/LSS2018.pdf.
[99] V. van der Veen, Y. Fratantonio, M. Lindorfer, D. Gruss, C. Maurice, G. Vigna, H. Bos, K. Razavi, and C. Giuffrida. “Drammer: Deterministic Rowhammer Attacks on Mobile Platforms”. en. In: ACM Press, 2016, pp. 1675.1689. isbn: 978-1-4503-4139-4. doi: 10.1145/2976749.2978406.
[100] R. Watson. New approaches to operatng system security extensibility. Tech. rep. UCAM-CL-TR-818. Cambridge University, Apr. 2012. url: http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-818.pdf.
[101] P. Wijesekera, A. Baokar, A. Hosseini, S. Egelman, D. Wagner, and K. Beznosov. “Android Permissions Remystified: A Field Study on Contextual Integrity”. In: 24th USENIX Security Symposium (USENIX Security 15). USENIX Association, 2015, pp. 499.514. isbn: 978-1-931971-232. url: https://www.usenix.org/conference/usenixsecurity15/technicalsessions/presentation/wijesekera.
[102] S. Willden. Insider Attack Resistance. May 2018. url: https://android-developers.googleblog.com/2018/05/insiderattack-resistance.html.
[103] Y. Zhang, M. Yang, B. Xu, Z. Yang, G. Gu, P. Ning, X. S. Wang, and B. Zang. “Vetting Undesirable Behaviors in Android Apps with Permission Use Analysis”. In: Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security. ACM, 2013, pp. 611.622. isbn: 978-1- 4503-2477-9. doi: 10.1145/2508859.2516689.