本部分包含有关确保核心 Android 操作系统和设备安全的建议。
生物特征识别身份验证
请谨慎获取、存储和处理 生物特征数据以进行用户身份验证。您应该：
- 在采用任何其他形式的身份验证（包括生物特征识别）之前，强制执行主要身份验证方法。
- 在使用被动生物特征识别方式（例如，面部识别）进行涉及身份验证绑定密钥的交易（例如，付款）时，要求明确确认以表明意图。
- 每 72 小时要求进行主要身份验证方法。
- 对所有生物特征数据和处理使用完全安全的管道。
- 切勿将生物特征数据（包括原始传感器测量值和衍生特征）发送到设备外。如果可能，请将此数据保存在安全的隔离环境中，例如可信执行环境 (TEE)或安全元件。
具有生物特征识别功能的设备应支持 BiometricPrompt API，该 API 为应用开发者提供了一个通用且一致的接口，以便在其应用中利用基于生物特征识别的身份验证。强生物特征识别技术只能与 BiometricPrompt 集成，并且集成必须遵循Android 兼容性定义文档 (CDD) 指南。
如需了解更多生物特征识别指南，请参阅生物特征识别 HAL 实施指南。
SELinux
SELinux 提供了 Android 大部分安全模型的定义和强制执行。正确使用 SELinux 对于 Android 设备的安全性至关重要，并且可以帮助减轻安全漏洞的影响。因此，所有 Android 设备都应实施强大的 SELinux 策略。
- 实施最小权限策略。
- 避免授予
CAP_DAC_OVERRIDE、CAP_SYS_ADMIN和CAP_NET_ADMIN权限。 - 请勿将系统数据记录到 SD 卡。
- 对驱动程序访问使用提供的类型，例如
gpu_device、audio_device等。 - 对进程、文件和 SELinux 类型使用有意义的名称。
- 确保不使用默认标签，并且不向其授予访问权限。
- 设备专用策略应占设备上运行的总体策略的 5% 到 10%。20% 以上范围的自定义几乎肯定包含权限过高的域和无效策略。不必要的大型策略会浪费内存，因需要更大的启动映像而浪费磁盘空间，并对运行时策略查找时间产生负面影响。
SELinux 策略的动态加载
请勿在 Android 设备上动态加载 SELinux 策略。这样做可能会导致以下问题：
- 阻止接受关键安全补丁程序。
- 暴露通过重新加载策略来 root 设备的可能性。
- 暴露针对策略更新程序的人为中间攻击的媒介。
- 由于策略更新错误而导致设备变砖。
后门
Android 应用不应有任何后门或访问系统或数据的方式，以绕过正常的安全机制。这包括由开发者已知的密钥控制的诊断、调试、开发或保修维修特殊访问权限。为防止后门：
- 使用行业认可的应用漏洞扫描工具扫描所有第三方应用。
- 对所有具有敏感访问权限的代码（包括第三方库）执行代码审核。
- 通过将应用上传到 Google Play 进行扫描，从而利用 Google Play Protect。您可以上传应用进行扫描，而无需发布到 Google Play。
- 请勿在发布版本中预加载以诊断或维修为中心的工具。仅按需安装这些工具以解决特定问题。此外，这些工具不得操作或上传任何帐户专用的数据。
开发工具
调试、测试和诊断工具等开发工具通常会在您的设备上创建意外的安全漏洞，从而泄露其运行方式及其收集的数据。为确保开发工具不会进入生产版本：
- 制定内部调试和测试工具哈希值的黑名单，并在使用系统映像之前扫描构建以查找这些 APK。
- 使用行业认可的应用漏洞扫描工具扫描所有第一方应用。
- 聘请第三方应用安全测试公司来评估所有关键的设备端诊断应用，尤其是在任何重大更新之前，特别是当应用由第三方开发时。
- 确保只有用户可以在支持会话期间通过口头或聊天方式启用该工具。存储同意记录，并在收集必要的诊断信息后禁用该工具。
- 将此工具的使用记录存储在用户在其运营商帐户中可以访问的日志中。
- 确保该工具收集的任何个人身份信息 (PII) 或设备遥测数据均应遵守与国家/地区相关的匿名化、保留和删除实践。应仅收集与支持呼叫相关的数据。此数据应在每次通话后删除。
- 确保未经用户明确同意，不使用可用于间谍软件的技术，例如击键记录、麦克风使用或摄像头使用。利用这些可能侵犯隐私的方法的应用应非常清楚地披露，并附带用户必须同意的隐私政策。未经用户明确同意，不应启用此类应用。
以下是在实施披露和同意时可参考的一些其他建议：
应用内披露
- 直接在应用内显示应用的正常使用情况。不要要求用户导航到菜单或设置中。
- 描述正在收集的数据类型，并解释数据的使用方式。
- 理想情况下，不要将此信息嵌入隐私政策或服务条款中。不要将其与个人或敏感数据收集无关的其他披露内容一起包含在内。
征求同意
- 同意必须是明确肯定的。不要将离开披露内容的行为（包括点击离开或按返回或主屏幕按钮）视为同意。
- 以清晰明确的方式呈现同意对话框。
- 需要肯定的用户操作（例如，点击接受或说出命令）才能接受。
- 在获得明确肯定同意之前，请勿收集个人或敏感数据。
- 请勿使用自动关闭或过期的消息。
AOSP 中的嵌入式功能
在 AOSP 中嵌入其他功能通常会产生意外的行为和后果；请谨慎操作。
- 确保在用户想要使用不同的默认应用（例如，搜索引擎、网络浏览器、启动器）时提示用户，并披露发送设备外数据。
- 确保 AOSP APK 使用 AOSP 证书签名。
- 运行回归测试并保留变更日志，以确定 AOSP APK 是否已添加代码。
安全更新
Android 设备应在发布后至少两年内获得持续的安全支持。这包括接收解决已知安全漏洞的定期更新。
- 与硬件合作伙伴（例如您的 SoC 供应商）合作，为您的 Android 设备上的所有组件制定适当的支持协议。
- 确保可以以最少的用户交互安装安全更新，以增加用户在其 Android 设备上接受和安装更新的可能性。强烈建议实施无缝系统更新或等效的安全功能。
- 确保您了解 Android 安全公告中声明的 Android 安全补丁程序级别 (SPL) 的累积要求。例如，使用 2018-02-01 安全补丁程序级别的设备必须包含与该安全补丁程序级别关联的所有问题，以及针对所有先前安全公告中报告的所有问题的修复程序。
动态内核更新
请勿动态修改关键系统组件。虽然有一些研究表明动态内核更新有助于防范紧急威胁，但目前评估的成本超过了收益。相反，创建强大的 OTA 更新方法以快速分发漏洞保护。
密钥管理
维护良好的密钥管理策略和实践，以确保签名密钥的安全性。
- 请勿与外部方共享签名密钥。
- 如果签名密钥泄露，请生成新密钥并双重签名所有后续应用。
- 将所有密钥存储在高安全性模块硬件或需要多重身份验证才能访问的服务中。
系统映像签名
系统映像的签名对于确定设备完整性至关重要。
- 请勿使用公开密钥对设备进行签名。
- 以符合行业标准处理敏感密钥的方式管理设备签名密钥，包括提供有限且可审核访问权限的硬件安全模块 (HSM)。
可解锁的启动加载程序
许多 Android 设备都支持解锁，使设备所有者可以修改系统分区或安装自定义操作系统。常见用例包括安装第三方系统映像以及在设备上执行系统级开发。例如，要解锁 Google Nexus 或 Pixel 上的系统映像，用户可以运行 fastboot oem unlock，这将显示以下消息：
作为最佳实践，可解锁的 Android 设备必须在解锁前安全地擦除所有用户数据。未能正确删除解锁时的所有数据可能会使物理位置接近的攻击者能够未经授权访问机密的 Android 用户数据。为防止用户数据泄露，支持解锁的设备必须正确实施解锁。
- 在用户确认解锁命令后，设备必须立即开始数据擦除。
unlocked标志必须在安全删除完成后才能设置。 - 如果无法完成安全删除，则设备必须保持锁定状态。
- 如果底层块设备支持，则应使用
ioctl(BLKSECDISCARD)或等效命令。对于嵌入式多媒体卡 (eMMC) 设备，这意味着使用安全擦除或安全 Trim 命令。对于 eMMC 4.5 及更高版本，这意味着使用普通擦除或 Trim，然后执行清理操作。 - 如果底层块设备不支持
BLKSECDISCARD，则必须改用ioctl(BLKDISCARD)。在 eMMC 设备上，这是一个普通的 Trim 操作。 - 如果不支持
BLKDISCARD，则可以用全零覆盖块设备。 - 用户必须可以选择要求在刷写分区之前擦除用户数据。例如，Nexus 设备使用
fastboot oem lock命令来擦除用户数据。 - 设备可以通过 eFuse 或类似机制记录设备是否已解锁和/或重新锁定。但是，我们强烈建议，使用后续恢复出厂设置重新锁定启动加载程序应恢复设备的全部功能。
这些要求确保在完成解锁操作后销毁所有数据。未能实施这些保护措施被视为中等安全漏洞。
可以使用 fastboot oem lock 命令随后重新锁定已解锁的设备。锁定启动加载程序为新自定义操作系统提供与原始设备制造商操作系统相同的用户数据保护（例如，如果设备再次解锁，则会擦除用户数据）。
设备渗透测试
设备在发货前应由 компетентный 渗透测试人员进行审查。渗透测试应确定设备是否遵循此处提供的安全指南以及 OEM 内部安全指南。
安全测试
使用 AOSP 提供的安全测试工具。特别是：
- 在开发期间使用内存安全工具：在支持 MTE 的情况下（ARMv9 及更高版本）使用 MTE，在不支持的情况下使用 HWASan。尽可能多地在启用这些工具的情况下运行测试。
- 在生产环境中使用 GWP-ASan 和 KFENCE 以概率方式检测内存安全问题。