制造商关于 Android 长期安全性的指南

本指南介绍了 Google 推荐的最佳实践，用于应用通过 Android 兼容性测试套件 (CTS) 评估的安全补丁。本指南适用于支持期超过三年（例如汽车、电视、机顶盒和家用电器）的 Android 兼容 OEM 设备（制造商）。本指南不适用于最终用户（例如，车主）。

致谢和免责声明

本指南不具有法律或合同约束力，对 Google 或其他制造商均不构成约束，也不旨在成为一套要求。相反，本指南是一种教学辅助工具，用于介绍推荐的做法。

反馈

本指南并非旨在面面俱到；我们计划进行更多修订。请将反馈提交至 manufacturers-guide-android@googlegroups.com。

词汇表

术语 定义
ACC Android 兼容性承诺。以前称为 Android 反碎片协议 (AFA)。
AOSP Android 开源项目
ASB Android 安全公告
BSP 板级支持包
CDD 兼容性定义文档
CTS 兼容性测试套件
FOTA 固件无线下载
GPS 全球定位系统
MISRA 汽车工业软件可靠性协会
NIST 美国国家标准与技术研究院
OBD 车载诊断系统（OBD-II 在功能和标准化方面均优于 OBD-I）
OEM 原始设备制造商
OS 操作系统
SEI 软件工程研究所
SoC 片上系统
SOP 量产开始
SPL 安全补丁程序级别
TPMS 胎压监测系统

关于 Android 操作系统

Android 是一个基于 Linux 的开源完整软件堆栈，专为各种设备和外形尺寸而设计。自 2008 年首次发布以来，Android 已成为最流行的操作系统 (OS)，为 全球 14 亿多台设备 (2016) 提供支持。截至 2017 年 3 月，约 67% 的设备使用 Android 5.0 (Lollipop) 或更高版本（更多最新数据可在 Android 开发者信息中心中找到）。虽然绝大多数设备是手机和平板电脑，但 Android 在智能手表、电视和汽车车载信息娱乐 (IVI) 设备中的应用也日益普及。

Google Play 商店中提供的 Android 应用数量已达到 220 多万个 (2016)。Android 应用开发以 Android 兼容性计划为后盾，该计划通过兼容性定义文档 (CDD)定义了一系列要求，并通过兼容性测试套件 (CTS)提供了测试工具。Android 兼容性计划可确保任何 Android 应用都可以在任何支持该应用所需功能的 Android 兼容设备上运行。

Google 会定期发布新的操作系统版本、操作系统安全更新以及有关已发现漏洞的信息。制造商应查看Android 安全公告，以了解这些更新对 Android 操作系统支持的产品的适用性。有关 Android 安全性、兼容性和构建系统的回顾，请参阅以下内容

关于联网汽车（典型的长寿命产品）

随着 20 世纪 20 年代 AM 无线电的引入，汽车开始联网。从那时起，随着监管机构和汽车制造商转向电子设备以简化诊断和服务（例如，OBD-II 端口）、提高安全性（例如，TPMS）并达到燃油经济性目标，外部物理和无线连接的数量开始增长。下一波连接引入了驾驶员便利功能，例如遥控无钥匙进入、远程信息处理系统以及高级信息娱乐功能，例如蓝牙、Wi-Fi 和智能手机投射。如今，集成传感器和连接（例如，GPS）支持安全和半自动驾驶系统。

随着车辆连接数量的增加，车辆潜在攻击面的面积也在增加。连接带来了与消费电子产品类似的许多网络安全问题。但是，虽然重启、每日补丁更新和不明原因的行为对于消费电子产品来说是常态，但对于具有安全关键系统（如车辆）的产品来说，这些是不一致的。

制造商必须采取积极主动的方法，以确保在现场产品持续的安全性和安全态势。简而言之，制造商必须了解产品中已知的安全漏洞，并采取基于风险的方法来解决这些漏洞。

确保长期安全性

联网汽车通常具有一个或多个电子控制单元 (ECU)，其中包括多个软件组件，例如操作系统、库、实用程序等。制造商应跟踪此类组件并识别已知的已发布漏洞，并进行积极主动的分析，包括：

  • 定期根据通用漏洞披露 (CVE) 数据库评估产品。
  • 收集与产品相关的安全漏洞的情报。
  • 安全测试。
  • 积极分析 Android 安全公告。

操作系统和安全补丁更新示例（运行 Android 的 IVI）

图 1. 车辆生命周期内的主要操作系统和安全更新示例。

# 步骤 活动

①

 开发分支 制造商选择 Android 版本 (Android X)。在本示例中，“Android X”成为车辆量产开始 (SOP) 前两年将要出厂的基础。
② 首次发布 在 Android X 成为产品中出厂的首个操作系统版本之前的几个月，从 Android 安全公告 (ASB) 和制造商认为有价值的其他来源获取安全更新。y2 = Android X 版本的第二个安全公告，由制造商应用于（反向移植到）Android X。此更新随产品出厂，生产时钟从第一年开始计时，采用 Android X.y2。

在本示例中，制造商决定不出厂更新的 Android X+1 年度版本。原因包括添加新功能、解决新的安全漏洞和/或出厂需要更新 Android 版本的 Google 或第三方服务。反对使用最新版本出厂的原因是车辆开发和发布过程固有的时间不足，无法集成、测试和验证更改，包括遵守所有法规和认证要求。
③ 完整操作系统更新 量产开始后，制造商发布 Android X+2 操作系统更新，这比初始产品（Android X0）使用的版本晚两个 Android 版本。ASB 安全更新适用于 API 级别（截至出厂日期），因此更新以 X+2.y0 的形式发布，大约在量产开始后 1.25 年。此操作系统更新可能与已部署的产品兼容，也可能不兼容。如果兼容，则可以制定计划来更新已部署的车辆。

除非另有其他业务协议，否则进行完整操作系统更新的决定完全由制造商自行决定。
④ 安全更新 在车辆生产寿命的第二年，制造商修补了 Android X+2 操作系统。此决定基于制造商的风险评估。制造商选择发布版本 X+2 的第三个 ASB 安全更新作为更新的基础。接收安全更新的产品现在处于 (X+2.y3) 操作系统 + Android 安全补丁程序级别。

虽然制造商可以从任何单独的 ASB 中选择单个安全补丁程序，但他们必须修复公告中的所有必需问题才能使用与公告关联的 Android 安全补丁程序级别 (SPL)（例如，2017-02-05）。制造商有责任为受支持的产品执行反向移植和安全发布。
⑤ 完整操作系统更新 重复步骤 3（完整操作系统更新），第二个完整操作系统更新使产品升级到 Android X+4，这是车辆生产寿命的第三年。制造商现在正在平衡最新 Android 版本的更新硬件要求与产品中的硬件以及更新 Android 操作系统给用户带来的好处。制造商发布了没有安全更新的更新，因此产品现在处于 (X+4.y0) 操作系统 + Android 安全补丁程序级别。

在本示例中，由于硬件限制，X+4 将是为此产品提供的最后一个主要 Android 版本，尽管车辆 6 年以上的预期寿命仍然需要安全支持。
⑥ 安全更新 重复步骤 4（安全更新）。制造商的任务是从更高版本的 Android (X+6) 中获取 ASB 安全更新，并将部分或全部更新反向移植到 Android X+4。制造商有责任合并、集成和执行更新（或与第三方签订合同）。此外，制造商应注意，不再支持的 Android 版本中的安全问题未包含在 ASB 中。
⑦ 安全更新 在车辆生产生命周期的第八年，自步骤 5（完整操作系统更新）中的上次操作系统更新以来已发布了四个 Android 版本，自指定 Android X 以来已十年，对于早于 API 级别公开发布三年以上的版本，管理和反向移植安全补丁程序的负担完全由制造商承担。

安全最佳实践

为了增加安全漏洞攻击的难度，Google 建议并采用通用安全和软件工程最佳实践，如实施安全性中所述。

安全指南

安全方面的推荐做法包括：

  • 使用最新版本的外部库和开源组件。
  • 不要在操作系统的发布版本中包含侵入式调试功能。
  • 删除未使用的功能（以减少不必要的攻击面）。
  • 使用最小权限原则和其他Android 应用开发最佳实践。

软件开发指南

系统生命周期安全软件开发的推荐做法包括：

  • 执行威胁建模，以对资产、威胁和潜在缓解措施进行排名和识别。
  • 执行架构/设计审查，以确保安全可靠的设计。
  • 定期进行代码审查，以尽快识别反模式和错误。
  • 设计、实施和运行高代码覆盖率单元测试，包括：
    • 功能测试（包括负面测试用例）
    • 定期回归测试（以确保已修复的错误不会再次出现）
    • 模糊测试（作为单元测试套件的一部分）
  • 使用静态源代码分析工具（scan-build、lint 等）来识别潜在问题。
  • 使用动态源代码分析工具，例如 AddressSanitizer、UndefinedBehaviorSanitizer 和 FORTIFY_SOURCE（对于原生组件），以在系统开发期间识别和缓解潜在问题。
  • 制定软件源代码和发布配置/版本的管理策略。
  • 制定软件补丁程序的生成和部署的补丁程序管理策略。

安全反向移植政策

Google 目前为自API 级别公开发布之日起三年内发现和报告的安全漏洞提供积极的安全反向移植支持。积极支持包括以下内容：

  1. 接收和调查漏洞报告。
  2. 创建、测试和发布安全更新。
  3. 定期发布安全更新和安全公告详情。
  4. 按照既定指南执行严重性评估。

在 API 级别公开发布日期三年后，Google 建议遵循以下指南：

  • 对于 API 发布三年以上的操作系统安全更新，请使用第三方（例如 SoC 供应商或内核提供商）进行反向移植支持。
  • 使用第三方使用公开发布的 ASB 执行代码审查。虽然 ASB 识别了当前支持版本的漏洞，但制造商可以使用提供的信息将新发布的更新与以前的版本进行比较。此数据可用于执行影响分析，并可能为 API 发布三年以上的操作系统版本生成类似的补丁程序。
  • 在适当时，将安全更新上传到 Android 开源项目 (AOSP)。
  • 制造商必须协调处理供应商特定代码（例如，专有的设备特定代码）的安全更新。
  • 制造商应加入 NDA Android 安全公告合作伙伴预览通知组（需要签署法律协议，例如开发者 NDA）。公告应包括：
    • 公告
    • 按补丁程序级别（包括 CVE 和严重性）划分的问题摘要
    • 适当情况下的漏洞详情

其他参考资料

有关安全编码和软件开发实践的说明，请参阅以下内容：

Google 鼓励使用以下推荐的做法。

通常建议使用最新操作系统版本发布任何联网产品，制造商应尝试在发布产品之前使用最新的操作系统版本。虽然锁定版本对于在测试和验证之前推动稳定性是必要的，但制造商必须平衡从较旧操作系统版本获得的产品稳定性与具有较少已知安全漏洞和增强的安全保护措施的较新操作系统版本。

推荐的指南包括：

  • 由于车辆开发过程固有的较长开发周期，制造商可能需要使用操作系统版本 n-2 或更旧版本发布产品。
  • 通过无线下载 (OTA) 活动，使每个发布的 Android 操作系统版本都符合 Android 兼容性。
  • 为产品实施支持 Android 固件无线下载 (FOTA) 功能，以便进行快速、用户友好的更新。FOTA 应使用安全最佳实践来完成，例如代码签名以及产品与 IT 后端之间的 TLS 连接。
  • 提交独立识别的 Android 安全漏洞给 Android 安全团队。

注意：Google 已经考虑过在 Android 安全公告中加入设备类型或行业特定的通知。但是，由于 Google 不知道给定设备（汽车、电视、可穿戴设备、手机等）的内核、驱动程序或芯片组，因此 Google 无法确定性地为任何给定的安全问题标记设备类型。

制造商应尽一切努力在产品周期增强期间使用最新的操作系统版本或所用版本的安全更新。可以在经常性的定期产品更新期间或针对解决质量和/或其他问题的热修复程序执行更新。推荐的做法包括：

  • 制定计划以解决驱动程序、内核和协议更新。
  • 利用行业适当的方法为已部署的车辆提供更新。

兼容性定义文档 (CDD)

兼容性定义文档 (CDD) 描述了设备被视为 Android 兼容设备的要求。CDD 是公开的，每个人都可以使用；您可以从 source.android.com 下载从 Android 1.6 到最新版本的 CDD 版本。

满足产品的这些要求涉及以下基本步骤：

  1. 合作伙伴与 Google 签署 Android 兼容性承诺 (ACC)。然后，将分配一名技术解决方案顾问 (TSC) 作为指导。
  2. 合作伙伴完成产品 Android 操作系统版本的 CDD 审查。
  3. 合作伙伴运行并提交 CTS 结果（如下所述），直到结果对于 Android 兼容性来说可以接受。

兼容性测试套件 (CTS)

兼容性测试套件 (CTS) 测试工具验证产品实现是否与 Android 兼容，以及是否包含最新的安全补丁程序。CTS 是公开的、开源的，每个人都可以使用；您可以从 source.android.com 下载从 Android 1.6 到最新版本的 CTS 版本。

发布给公众的每个 Android 软件版本（工厂安装和现场更新映像）都必须通过 CTS 结果证明 Android 兼容性。例如，如果设备运行 Android 7.1，则在创建和测试发布意向内部版本映像时，应参考最新对应的 CDD 7.1 版本和 CTS 7.1 版本。强烈建议制造商尽早且频繁地使用 CTS，以识别和纠正问题。

注意：签署其他协议（例如 Google 移动服务 (GMS)）的合作伙伴可能需要满足其他要求。

CTS 工作流程

CTS 工作流程涉及设置测试环境、运行测试、解释结果以及了解 CTS 源代码。以下指南旨在帮助 CTS 用户（例如，开发人员、制造商）有效且高效地使用 CTS。

  • 频繁运行测试。CTS 设计为可集成到您的构建系统中的自动化工具。频繁运行 CTS 可以帮助您在软件降级或回归发生时快速且尽早地发现缺陷。
  • 下载并检查 CTS 源代码。完整的 CTS 源代码是开源软件，任何人都可以下载和使用（下载的源代码是完全可构建和可运行的）。当设备上的测试失败时，检查源代码的相关部分可以帮助您确定原因。
  • 获取最新的 CTS。新的 Android 版本可以使用错误修复、改进和新测试来更新 CTS。经常查看CTS 下载并根据需要更新您的 CTS 程序。制造商和 Google 应就产品发布要通过的 CTS 版本达成一致，因为产品必须在某个时间点冻结，而 CTS 会继续刷新。

通过 CTS

对于 Android 兼容产品，Google 确保设备的 CTS 和 CTS 验证程序报告的测试结果可以接受。原则上，所有测试都必须通过。但是，因设备不符合 Android 兼容性要求以外的原因而失败的测试需经过 Google 审核。在此过程中：

  1. 制造商向 Google 提供拟议的 CTS 补丁程序、补丁程序验证和理由，以证明其论点。
  2. Google 检查提交的材料，如果接受，则更新相关的 CTS 测试，以便设备在 CTS 的下一个修订版本中通过测试。

如果在应用安全补丁程序后 CTS 测试突然失败，则制造商必须修改补丁程序，使其不会破坏兼容性，或者表明测试有误并提供测试修复程序（如上所述）。

CTS 仍然接受对测试修复程序的审核。例如，Android 4.4 继续接受修复程序（请参阅 https://android-review.googlesource.com/#/c/273371/）。

常见问题解答 (FAQ)

问：谁负责将安全更新应用于 Android 的特定实现？

答：直接提供设备的制造商负责。此实体不是 Google，Google 在 AOSP 中发布安全更新，而不是针对特定设备（例如汽车）。

问：Google 如何处理 Android 中的安全问题？

答：Google 不断调查问题并开发潜在的修复程序，Google 会将这些修复程序作为常规安全更新过程的一部分提供给所有受支持的 API 级别。自 2015 年 8 月以来，Google 一直保持定期发布公告和链接到 source.android.com 更新的节奏；Google 还在主要操作系统版本发布时发布安全更新。另请参阅安全反向移植政策。

问：如果制造商集成了来自 ASB 的所有 AOSP 补丁程序，但未集成来自同一公告中提及的 BSP 供应商的补丁程序，它是否仍然可以提高安全级别（例如，将相应的补丁程序应用于 platform/build）？?

答：要声明 Android 安全补丁程序级别 (SPL)，制造商必须解决 Android 安全公告（包括之前的公告）中发布的所有必需问题，并映射到特定的 Android SPL。例如，使用2017 年 3 月安全公告（2017-03-01 SPL）的制造商已解决 2017 年 3 月公告中记录的针对该 SPL 的所有必需问题以及所有先前的更新，包括针对所有先前 Android 安全公告的设备特定更新，包括与 2017-02-05 SPL 关联的设备特定更新。

问：当制造商不同意 BSP 供应商提供的安全更新，或者供应商未提供 ASB 强制要求的安全更新时，会发生什么情况？

答：ASB 描述了安全漏洞（通过 CVE 列表枚举），并且通常提供匹配的安全测试。目标是确保在设备上不再重现列出的漏洞，并且设备可以通过相关的安全测试。因此，问题不是关于采用 Google 或第三方供应商提供的安全更新，而是关于制造商证明设备不易受到 ASB 中 CVE 列表的攻击。制造商可以自由使用提供的安全更新，或者，如果他们有更适合其设备的更改，则可以使用该更改代替。

例如，考虑这样一种情况：Google 使用代码更改解决了 AOSP 安全漏洞，该代码更改允许组件保持完全正常运行并符合 CDD。如果制造商确定设备上不需要该组件，或者 CDD（或相关的认证测试）没有强制要求该组件，则制造商可以删除该组件以减少未来的维护需求并减少攻击面。虽然制造商未使用提供的安全更新，但它确实确保了设备不易受到安全公告中记录的 CVE 的攻击。但是，在偏离建议的安全更新时，制造商承担着错误地解决问题、引入新的安全漏洞或以其他方式降低最终版本的功能的风险。

虽然我们与所有 SoC 合作伙伴合作以确保 ASB 中所有问题都存在修复程序，但我们建议制造商为其设备的生命周期与 SoC 供应商签订服务协议。SoC 可能会比预期更早停止为芯片组提供服务，因此在设备芯片组选择之前建立协议是设备发布过程的重要组成部分。

最后，在无法直接获取或独立创建 ASB 中记录的问题的修复程序的情况下，制造商可以保持之前的 Android SPL，并仍然将新的可用修复程序添加到构建中。然而，这种做法最终会导致构建认证问题（因为 Android 确保认证设备上提供最新的安全补丁级别）。Google 建议提前与您的 SoC 合作，以避免这种做法。

问：如果制造商确定 ASB 项目不适用于他们的产品，是否仍然需要应用或修补该项目，才能满足其他 Google 要求或通过 CTS？

答：我们不要求必须采用补丁才能声明 Android 安全补丁级别 (SPL)；但我们确实要求制造商证明他们的构建版本不易受该问题的影响。

一个例子是，要修补的组件在制造商的系统中不存在，或者为了解决问题，组件已从制造商的系统中移除。在这种情况下，系统可能在不需要制造商采用补丁的情况下仍然合规。

这与制造商只想修复关键补丁，而不采用其他适用补丁（这将导致安全测试失败）的情况从根本上不同。在这种情况下，SPL 被认为未达到要求。