长期 Android 安全制造商指南

本指南介绍了 Google 推荐的应用由 Android 兼容性测试套件 (CTS) 评估的安全补丁的最佳做法。它适用于支持超过三 (3) 年的 Android 兼容 OEM 设备制造商(制造商),例如车辆、电视、机顶盒、家用电器等。本指南不适用于最终用户(例如,车主)。

致谢与免责声明

本指南不以法律或合同方式约束 Google 或其他制造商,也不打算作为一组要求。相反,本指南是描述推荐做法的指导性帮助。

反馈

本指南并不全面;计划进行更多修订。向制造商指南-android@googlegroups.com 提交反馈。

词汇表

学期定义
ACC Android 兼容性承诺。以前称为 Android 反碎片协议 (AFA)。
AOSP安卓开源项目
ASB Android 安全公告
BSP板级支持包
客户尽职调查兼容性定义文档
中旅兼容性测试套件
FOTA无线固件
全球定位系统全球定位系统
MISRA汽车工业软件可靠性协会
NIST美国国家标准与技术研究院
OBD车载诊断( OBD-II 是对 OBD-I 在能力和标准化方面的改进
OEM原始设备制造商
操作系统操作系统
SEI软件工程学院
SOC片上系统
标准作业程序开始生产
声压级安全补丁级别
胎压监测系统胎压监测系统

关于安卓操作系统

Android 是一个开源的、基于 Linux 的完整软件堆栈,专为各种设备和外形尺寸而设计。自 2008 年首次发布以来,Android 已成为最受欢迎的操作系统 (“OS”),为全球超过 1.4 亿台设备提供支持(2016 年)。截至 2017 年 3 月,这些设备中约有 67% 使用 Android 5.0 (Lollipop) 或更新版本( Android Dashboard上提供了最新数据)。虽然绝大多数设备是手机和平板电脑,但 Android 在智能手表、电视和汽车车载信息娱乐 (“IVI”) 设备方面正在增长。

Google Play 商店中可用的 Android 应用程序数量已达到2.2+ 万(2016 年)。 Android 应用程序开发由 Android 兼容性计划提供支持,该计划通过兼容性定义文档 (CDD)定义一组要求,并通过兼容性测试套件 (CTS)提供测试工具。 Android 兼容性程序确保任何 Android 应用程序都可以在任何支持应用程序所需功能的 Android 兼容设备上运行。

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

关于联网车辆(典型的长寿命产品)

1920 年代,随着 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 的第 0 年开始计时。

在此示例中,制造商决定发布更新的 Android X+1 年度版本。发布最新版本的原因包括添加新功能、解决新的安全漏洞和/或发布需要较新 Android 版本的 Google 或第三方服务。反对与最新版本一起发布的原因是车辆开发和发布过程缺乏集成、测试和验证更改所需的时间,包括符合所有法规和认证要求。

完整的操作系统更新在 SOP 之后,制造商发布 Android X+2 操作系统更新,这是在初始产品(Android X0)使用的版本之后的两个 Android 版本。 ASB 安全更新可用于 API 级别(截至发货日期),因此更新在 SOP 大约 1.25 年后以 X+2.y0 的形式发布。此操作系统更新可能与现场产品兼容,也可能不兼容。如果是,则可以制定计划来更新部署的车辆。

除非有其他业务协议,否则是否进行完整操作系统更新的决定完全由制造商自行决定。

安全更新在车辆的生产寿命两年内,制造商修补了 Android X+2 操作系统。该决定基于制造商的风险评估。制造商选择版本 X+2 的第三个 ASB 安全更新作为更新的基础。接收安全更新的产品现在处于 (X+2.y3) OS + Android 安全补丁级别。

虽然制造商可以从任何单独的 ASB 中选择单独的安全补丁程序,但他们必须修复公告中的所有必需问题才能使用与公告相关的 Android 安全补丁程序级别 (SPL)(例如,2017-02-05)。制造商有责任为受支持的产品执行反向移植和安全发布。

完整的操作系统更新重复第 3 步(完整操作系统更新),第二次完整操作系统更新将产品升级到 Android X+4,车辆的生产寿命为三年。制造商现在正在平衡最新 Android 版本的新硬件要求与产品中的硬件,并且用户可以从更新的 Android 操作系统中受益。制造商发布了没有安全更新的更新,因此该产品现在处于 (X+4.y0) OS + 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 级别公开发布后的三 (3) 年内为已发现和报告的安全漏洞的安全反向移植提供积极支持。主动支持包括以下内容:

  1. 接收和调查漏洞报告。
  2. 创建、测试和发布安全更新。
  3. 提供定期发布的安全更新和安全公告详细信息。
  4. 根据既定指南执行严重性评估。

自 API 级别公开发布之日起三年后,Google 建议遵循以下准则:

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

附加参考

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

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

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

推荐的指南包括:

  • 由于车辆开发过程固有的较长开发周期,制造商可能需要使用操作系统版本 n-2 或更早版本发布。
  • 通过无线 (OTA) 活动,为每个已发布的 Android 操作系统版本保持与 Android 兼容性的一致性。
  • 实施产品 Android Firmware-over-the-air (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将 CTS 版本从 Android 1.6 下载到最新版本。

向公众发布的每个版本的 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,它在 AOSP 中发布安全更新,而不是针对特定设备(例如车辆)。

问:Google 如何处理 Android 中的安全问题?

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

问:如果制造商集成了 ASB 的所有 AOSP 补丁,但没有集成同一公告中提到的 BSP 供应商的补丁,它是否仍然可以提高安全级别(例如,将相应的补丁应用于平台/构建)

答:要声明 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。