[Android] Android Security Arch Overview

[carloscn]

本文来源于以下的文献，对其进行整理：

• https://source.android.com/docs/security?hl=zh-cn
• https://developer.android.com/quality/privacy-and-security
• https://github.com/OWASP/owasp-mastg/blob/master/Document/0x02a-Frontispiece.md
• https://mas.owasp.org/MASTG/Intro/0x01-Foreword/
• Book -- Android Security Internals An In-Depth Guide to Android's Security Architecture

1. Android Security Arch

1.1 Security Model

在信息安全领域，依赖单一的安全机制往往是不足够的，因为每种机制都可能有其局限性和潜在的漏洞。因此，系统安全性更多地依赖于多种机制的组合，这种方法被称为“防御深度”（defense in depth）。一个全面的、多层次的安全策略被认为是保护信息系统安全的最佳实践。因此，有必要拿出一些篇幅，解释Android的安全模型，以联合Android的所有安全话题。

"Android的Security Model"（Android的安全模型）指的是Android操作系统用于保护设备和数据安全的一系列策略、机制和技术。这个安全模型旨在防止恶意软件攻击和未授权访问，同时确保用户数据的隐私和完整性。

1.1.1 Android Arch

Android 软件堆栈是指构成 Android 操作系统的各个软件层级和组件。这个堆栈包括从底层的硬件抽象层到用户界面的各个部分。下面是一个简单的概述：

1. Linux 内核：Android 基于 Linux 内核，它处理诸如系统安全、内存管理、进程管理、网络堆栈和驱动程序等核心系统功能。
2. 硬件抽象层（HAL）：这一层为上层的 Android 框架提供标准接口，用于访问硬件功能。每种硬件（如摄像头、蓝牙模块等）都有自己的接口。
3. 原生用户空间（Native Userspace）：这一层包括各种系统库，它们支持 Android 的核心功能，如图形处理、数据存储和网页浏览等。
4. Android 运行时（ART）和 Dalvik 虚拟机：这些是 Android 的应用运行环境。ART 为应用程序提供了垃圾回收、编译和执行环境。
5. Java API 框架：这层提供了构建 Android 应用所需的各种 API。开发者可以利用这些 API 访问设备功能，如用户界面、资源管理等。
6. 系统应用：这包括一系列内置的 Android 应用，如电话、联系人、短信等。

整个堆栈工作在一起，使 Android 设备能够运行各种应用程序和服务，同时为最终用户提供丰富的交互体验。每一层都在为更高层提供服务，同时依赖更低层的功能和资源。

1.1.2 Android Security Topics

基于Android Stack 和 https://source.android.com/docs/security?hl=zh-cn 以下为整理出来的基于Android架构的安全话题。

2. Security Checklist for APPs

根据Android Security Arch，我们对APP做以下要求。该要求为 https://mas.owasp.org/MASTG/Intro/0x01-Foreword/ OWASP开源组织设计。我们分别从以下维度做限制，分别考虑，架构层级的设计、数据保密性和隐私、使用密码学算法、认证管理、网络安全、以及抗逆向工程的要求。

2.1 Architecture, Design and Threat Modeling Requirements

在理想的世界中，安全性会在开发的所有阶段中得到考虑。然而，在现实中，安全性通常只在软件开发生命周期的后期阶段才被考虑。除了技术控制之外，移用安全验证标准（MASVS）要求实施确保在规划移动应用架构时显式地解决安全问题的流程，并且知道所有组件的功能和安全角色。

“V1”类别列出了与应用的架构和设计相关的要求。为了涵盖诸如威胁建模、安全的软件开发生命周期或密钥管理等主题，应该参考相应的OWASP项目和/或其他标准。

V1		Architecture, design and threat modelling	L1	L2		参考
1.1	MSTG-ARCH-1	All app components are identified and known to be needed.	✓	✓		Architectural Information
1.2	MSTG-ARCH-2	Security controls are never enforced only on the client side, but on the respective remote endpoints.	✓	✓		Injection Flaws (MSTG-ARCH-2 and MSTG-PLATFORM-2)
1.3	MSTG-ARCH-3	A high-level architecture for the mobile app and all connected remote services has been defined and security has been addressed in that architecture.	✓	✓		Architectural Information
1.4	MSTG-ARCH-4	Data considered sensitive in the context of the mobile app is clearly identified.	✓	✓		Identifying Sensitive Data
1.5	MSTG-ARCH-5	All app components are defined in terms of the business functions and/or security functions they provide.		✓	N/A	Environmental Information
1.6	MSTG-ARCH-6	A threat model for the mobile app and the associated remote services has been produced that identifies potential threats and countermeasures.		✓	N/A	Mapping the Application
1.7	MSTG-ARCH-7	All security controls have a centralized implementation.		✓	N/A	Testing for insecure Configuration of Instant Apps (MSTG-ARCH-1, MSTG-ARCH-7)
1.8	MSTG-ARCH-8	There is an explicit policy for how cryptographic keys (if any) are managed, and the lifecycle of cryptographic keys is enforced. Ideally, follow a key management standard such as NIST SP 800-57.		✓	N/A	Cryptographic policy
1.9	MSTG-ARCH-9	A mechanism for enforcing updates of the mobile app exists.		✓	N/A	Testing enforced updating (MSTG-ARCH-9)
1.10	MSTG-ARCH-10	Security is addressed within all parts of the software development lifecycle.		✓	N/A	Security Testing and the SDLC
1.11	MSTG-ARCH-11	A responsible disclosure policy is in place and effectively applied.		✓	N/A
1.12	MSTG-ARCH-12	The app should comply with privacy laws and regulations.	✓	✓

V1		架构、设计和威胁建模	L1	L2		参考
1.1	MSTG-ARCH-1	已识别出所有应用组件，并确认它们是必需的。	✓	✓		Architectural Information
1.2	MSTG-ARCH-2	安全控制不仅仅在客户端强制执行，也要在相应的远端端点强制执行。	✓	✓		Injection Flaws (MSTG-ARCH-2 and MSTG-PLATFORM-2)
1.3	MSTG-ARCH-3	已定义移动应用及所有连接的远程服务的高层架构，并在该架构中解决了安全问题。	✓	✓		Architectural Information
1.4	MSTG-ARCH-4	清晰地识别了在移动应用上下文中被认为是敏感的数据。	✓	✓		Identifying Sensitive Data
1.5	MSTG-ARCH-5	所有应用组件都根据它们提供的业务功能和/或安全功能来定义。		✓	N/A	Environmental Information
1.6	MSTG-ARCH-6	已生成移动应用及其关联远程服务的威胁模型，识别出潜在威胁和对策。		✓	N/A	Mapping the Application
1.7	MSTG-ARCH-7	所有安全控制都有一个集中实施的机制。		✓	N/A	Testing for insecure Configuration of Instant Apps (MSTG-ARCH-1, MSTG-ARCH-7)
1.8	MSTG-ARCH-8	明确的密钥管理政策，强制执行密钥生命周期。理想情况下，遵循密钥管理标准，如NIST SP 800-57。		✓	N/A	Cryptographic policy
1.9	MSTG-ARCH-9	存在强制更新移动应用的机制。		✓	N/A	Testing enforced updating (MSTG-ARCH-9)
1.10	MSTG-ARCH-10	在软件开发生命周期的所有部分中都解决了安全问题。		✓	N/A	Security Testing and the SDLC
1.11	MSTG-ARCH-11	已经建立并有效执行的负责任披露政策。		✓	N/A
1.12	MSTG-ARCH-12	应用应遵守隐私法律和规定。	✓	✓

2.2 Data Storage and Privacy

这一章节主要讨论了在移动安全中保护敏感数据（如身份验证令牌和私人信息）的重要性，并探讨了Android在本地数据存储方面的API及其最佳实践。

尽管最好尽量减少或避免在本地存储敏感数据，但实际情况下，应用程序经常需要存储用户数据。例如，为了提升用户体验，应用程序可能在本地缓存身份验证令牌，减少每次启动时输入复杂密码的需要。应用程序还可能需要存储个人可识别信息（PII）和其他敏感数据。

如果保护不当，敏感数据可能变得容易受到攻击，存储位置可能包括设备或外部SD卡。识别移动应用处理的信息并分类哪些是敏感数据非常重要。可以参阅“移动应用安全测试”章节中的“识别敏感数据”部分，了解数据分类的详细信息。另外，Android开发者指南中的“存储数据的安全提示”一节提供了全面的见解。

敏感信息泄露的风险包括潜在的信息解密、社交工程攻击（如果泄露了PII）、账户劫持（如果泄露了会话信息或身份验证令牌）以及带有支付选项的应用程序利用。

除了数据保护外，还需要验证和清理来自任何存储源的数据。这包括检查正确的数据类型和实施加密控制（如HMAC）以确保数据完整性。

Android提供了多种数据存储方法，适用于用户、开发者和应用程序。常见的持久存储技术包括：

• 共享偏好设置
• SQLite数据库
• Firebase数据库
• Realm数据库
• 内部存储
• 外部存储
• Keystore

此外，其他可能导致数据存储的Android功能也应进行测试，包括：

• 日志功能
• Android备份
• 进程内存
• 键盘缓存
• 屏幕截图

以下是关于对于是数据存储和隐私的测试限制和checklist：

V2		Data Storage and Privacy
2.1	MSTG-STORAGE‑1	System credential storage facilities need to be used to store sensitive data, such as PII, user credentials or cryptographic keys.	✓	✓		Testing Local Storage for Sensitive Data (MSTG-STORAGE-1 and MSTG-STORAGE-2)
2.2	MSTG-STORAGE‑2	No sensitive data should be stored outside of the app container or system credential storage facilities.				Testing Local Storage for Sensitive Data (MSTG-STORAGE-1 and MSTG-STORAGE-2)
2.3	MSTG-STORAGE‑3	No sensitive data is written to application logs.	✓	✓		Testing Logs for Sensitive Data (MSTG-STORAGE-3)
2.4	MSTG-STORAGE‑4	No sensitive data is shared with third parties unless it is a necessary part of the architecture.	✓	✓		Determining Whether Sensitive Data is Sent to Third Parties (MSTG-STORAGE-4)
2.5	MSTG-STORAGE‑5	The keyboard cache is disabled on text inputs that process sensitive data.	✓	✓		Determining Whether the Keyboard Cache Is Disabled for Text Input Fields (MSTG-STORAGE-5)
2.6	MSTG-STORAGE‑6	No sensitive data is exposed via IPC mechanisms.	✓	✓		Determining Whether Sensitive Stored Data Has Been Exposed via IPC Mechanisms (MSTG-STORAGE-6)
2.7	MSTG-STORAGE‑7	No sensitive data, such as passwords or pins, is exposed through the user interface.	✓	✓		Checking for Sensitive Data Disclosure Through the User Interface (MSTG-STORAGE-7)
2.8	MSTG-STORAGE‑8	No sensitive data is included in backups generated by the mobile operating system.		✓	N/A	Testing Backups for Sensitive Data (MSTG-STORAGE-8)
2.9	MSTG-STORAGE‑9	The app removes sensitive data from views when moved to the background.		✓	N/A	Finding Sensitive Information in Auto-Generated Screenshots (MSTG-STORAGE-9)
2.10	MSTG-STORAGE‑10	The app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use.		✓	N/A	Checking Memory for Sensitive Data (MSTG-STORAGE-10)
2.11	MSTG-STORAGE‑11	The app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode.		✓	N/A	Testing the Device-Access-Security Policy (MSTG-STORAGE-11)
2.12	MSTG-STORAGE‑12	The app educates the user about the types of personally identifiable information processed, as well as security best practices the user should follow in using the app.		✓	N/A	Testing User Education (MSTG-STORAGE-12)
2.13	MSTG-STORAGE‑13	No sensitive data should be stored locally on the mobile device. Instead, data should be retrieved from a remote endpoint when needed and only be kept in memory.		✓	N/A
2.14	MSTG-STORAGE‑14	If sensitive data is still required to be stored locally, it should be encrypted using a key derived from hardware backed storage which requires authentication.		✓	N/A
2.15	MSTG-STORAGE‑15	The app’s local storage should be wiped after an excessive number of failed authentication attempts.		✓	N/A

3. APP实例分析