系统安全性最佳实践

本部分包含可确保核心 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 保护机制。您可以只上传应用进行扫描而无需将应用发布到 Google Play。
  • 请勿在发布 build 上预装载侧重于诊断或修复的工具。仅按需安装这些工具以解决特定问题。此外，这些工具不得处理或上传任何特定于账号的数据。

开发工具

开发工具（如调试、测试和诊断工具）通常可以揭示设备如何运行、收集了哪些数据，从而在设备上产生意外的安全漏洞。若要确保开发工具不会进入正式版 build，请执行以下操作：

  • 在使用系统映像之前，制作内部调试和测试工具哈希的黑名单并扫描 build 以检测是否存在这些 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) 或等同命令，则应使用此类命令。对于嵌入式 MultiMediaCard (eMMC) 设备，这意味着使用 Secure Erase 或 Secure Trim 命令。对于 eMMC 4.5 及更高版本，这意味着先使用常规的 Erase 或 Trim 命令，然后再执行 Sanitize 操作。
  • 如果底层块存储设备不支持 BLKSECDISCARD，则必须改用 ioctl(BLKDISCARD)。在 eMMC 设备上，这是一个常规的 Trim 操作。
  • 如果 BLKDISCARD 不受支持，可以将块存储设备中的数据重写为全零。
  • 用户必须能够要求在刷写分区之前先清除用户数据。例如，Nexus 设备使用 fastboot oem lock 命令清除用户数据。
  • 设备可以通过 eFuse 或类似机制记录设备是处于解锁还是重新锁定状态。不过，我们强烈建议重新锁定引导加载程序并随后恢复出厂设置，这样应该能恢复完整的设备功能。

这些要求旨在确保在完成解锁操作时所有数据都已被销毁。未能实现这些保护措施会被视为存在中级安全漏洞。

将设备解锁后，可以使用 fastboot oem lock 命令重新将其锁定。使用新的自定义操作系统时，如果锁定引导加载程序，为用户数据提供的保护与使用原始设备制造商操作系统时提供的保护相同（例如，如果设备被再次解锁，用户数据将会被擦除）。

设备测试

设备应在装运前由具备资质的渗透测试员进行审核。渗透测试应确认设备是否遵循本文提供的安全指导以及内部原始设备制造商 (OEM) 安全指导。

安全性测试

使用 AOSP 提供的安全测试工具。具体而言：

  • 在开发期间使用内存安全工具：如果支持使用 MTE，则使用 MTE（ARMv9 及更高版本），否则使用 HWASan。在启用这些工具的情况下，运行尽可能多的测试。
  • 在生产环境中使用 GWP-ASan 和 KFENCE，以便进行内存安全问题概率性检测。