AAOS SDV - 从设计上保证安全

在 Google，我们坚信产品应从设计之初就具备安全性，因此我们基于经过市场验证的现有平台，利用 Cuttlefish 等虚拟化技术，构建了适用于软件定义汽车的 Android Automotive 操作系统 (AAOS SDV)。虽然我们的版本公告侧重于功能，但本博文概述了一些安全概念。

基础：网域隔离

通过虚拟化隔离共存实例

当前将电子控制单元 (ECU) 整合到单个芯片中的趋势通过并行运行多个域来降低隔离度。

虽然 AAOS SDV 实例提供了内部隔离机制，但通常最好独立运行逻辑网域。例如，仪表板和信息娱乐系统有不同的要求。我们使用虚拟机并行运行多个实例，确保共享始终是显式的，而隔离是默认行为。

沿用的 Android 安全性

AAOS SDV 由 Microdroid 演变而来，后者是针对隐私保护虚拟机 (pVM) 进行了优化的极简 Android 版本。这种血统为 Android 平台工程师提供了他们已经熟悉的成熟安全功能。

进程隔离和默认拒绝

AAOS SDV 遵循 Android 基于用户 ID (UID) 的隔离模型，为每个应用设置沙盒。每项服务都在具有唯一 UID 的专用进程中运行，以管理访问权限、数据目录和其他限制。我们采用可移植操作系统接口 (POSIX) 功能来严格限制操作，并将其与安全增强型 Linux (SELinux) 结合使用，以强制执行“默认拒绝”策略。这种方法将每项服务限制在绝对最低要求范围内，这意味着缺少配置会阻止访问，而不是创建过度宽松的系统。我们对通信权限系统也采用了同样的策略，本文稍后会对此进行说明。

经过验证的漏洞管理

AAOS SDV 集成了 Android 成熟的安全响应和漏洞管理基础架构，可识别、分类、修复和披露安全发现结果。此生命周期包含持续的自动化扫描、年度深度渗透测试，以及通过 Android 安全漏洞报告流程获取合作伙伴提供的情报。安全团队会对发现的漏洞进行分类，根据风险分配严重级别，并跟踪修复过程直至完成。我们通过每月发布的 Android 安全公告协调披露和发布政策，并辅以严格的定期安全审核和全面的架构审核，以确保平台的长期弹性。

完整性：保护软件交付流程

除了保证进程隔离之外，安全平台还必须确保代码在执行前具有完整性。我们通过以下方法确保软件交付安全无虞：

经过身份验证的软件交付

AAOS SDV 提供两种安装方法。首先，我们会直接将软件安装到只读的 system、product 或 vendor 分区，这些分区会在每次启动时验证签名。这可以保护基本系统组件。

其次，我们使用 Android Pony EXpress (APEX) 软件包来提供服务。每个 APEX 都封装了软件及其依赖项，并将软件包视为具有强制签名验证的分区。在 AAOS SDV 中，APEX 将代码签名视为由硬件强制执行的持续性协定。APEX 通过四大核心支柱来确保缓解恶意代码执行：

1. 不可变存储

• 机制：Android 内核使用只读环回将 apex_payload.img 文件直接作为原始存储设备进行循环，并使用严格的 MS_RDONLY 标志进行装载。
• 为何更安全：由于文件不会解压到车辆的存储空间中，因此不会向操作系统公开写入路径。即使攻击者获得了 root 权限，也无法修改正在运行的 APEX 代码，因为文件系统层会拒绝所有写入命令。

2. 加密完整性

• 机制：加密签名会验证整个文件系统映像的 Merkle 树。
• 为什么更安全：内核会使用逐块 dm-verity 实时验证每个 4KB 数据块的签名。如果攻击者修改了闪存上的原始块，内核会检测到哈希不匹配，并立即停止执行。

3. 严格隔离

• 机制：此方法应用进程隔离部分中所述的进程隔离规则来创建沙盒，并将 APEX 装载为 /apex 下的专用分区。
• 为何更安全：每项服务都有自己的用户和数据目录，除非明确共享，否则访问会受到限制。通过创建专用分区，Android 建立了专用链接器命名空间，确保只有明确公开的库才能从非特权系统守护程序访问，从而最大限度地减少攻击面。

4. 原子恢复

• 机制：APEX 采用“活动/备份”设计，可实现双缓冲回滚。出厂时刷写的 APEX 仍保留在不可变的 /system 分区中，而更新则位于可变的 /data 分区中。
• 为何更安全：如果更新失败或看起来存在恶意，apexd 守护程序会在前期启动期间将其标记为“失败”。系统会立即将符号链接换回 /system 分区。这种原子恢复有助于确保系统不会一直处于损坏状态。

弹性：内存安全开发

验证加载可保护系统免受外部修改，但平台弹性还取决于底层代码的构建方式。对于为 AAOS SDV 开发的新组件，我们优先考虑了内存安全。

Rust 作为主要语言

AAOS SDV 针对的是对可用性要求较高的小型系统；这会阻止在完整 Android 堆栈上进行构建，因此我们将范围限制在原生框架内。为了为分布式系统创建所需的基础设施，我们在现有基础设施的基础上开发了多个组件，并采用 Rust 作为主要语言。我们还使用 Rust 开发服务的业务逻辑，帮助合作伙伴编写安全的软件。Rust 旨在利用内存安全功能来帮助防范常见类型的内存安全漏洞，同时支持团队在编写原生代码时提高吞吐量。

分布式信任：网络和访问权限控制

软件定义车辆需要隔离域之间进行安全交互。AAOS SDV 网格配置架构通过对每个通信端点的版本和作者进行加密验证，解决了这一复杂性问题。

设备和网状网络配置

AAOS SDV Mesh 通过以数学方式将每个组件的网络身份与其实际二进制执行状态绑定来建立身份验证。此模型将隐式软件信任替换为基于硬件的验证。

网格身份验证旨在实现持续和加密。这可以防止出现以下情况：例如，车辆网关等服务仅因信息娱乐虚拟机具有正确的 IP 地址而信任已遭入侵的信息娱乐虚拟机。

硬件强制隔离和自动隔离协议可确保平台安全。SDV 网格中的对等设备使用基于 DICE 的身份验证和认证（详见下文），以帮助识别和遏制未经授权的代码执行或配置篡改。

基于 DICE 的 TLS，用于保护虚拟机之间的通信

让主播身份更具真实感

DICE（设备标识符组合引擎）的黄金法则：如果固件中的一行代码发生更改（即使是细微更新或恶意利用），派生的复合设备标识符 (CDI) 也会完全改变，从而生成完全不同的别名密钥。

DICE 和 TLS（传输层安全协议）集成，可解决零信任架构的根本挑战：在对机器进行身份验证的同时验证其软件完整性。

通过将 DICE 的由硬件支持标识与 TLS 的已加密握手相结合，接收机器可以验证调用方的身份及其确切的软件状态。

传统证书只能证明拥有密钥，无法检测固件篡改。DICE 通过测量启动分层来解决此问题：

• 唯一设备密钥 (UDS)：在制造过程中生成的随机加密密钥。只有第一阶段引导加载程序可以访问 UDS；所有其他软件和外部接口都无法访问 UDS。
• 分层测量（复合设备标识符）：硬件 ROM 通过将 UDS 与下一个固件层的确切代码和配置进行哈希处理来启动链。这会创建一个 CDI，然后随着每个后续层的启动而按顺序链接。

严格的访问权限控制可管理 AAOS SDV 网格内的服务交互。与所有 AAOS SDV 软件一样，这些访问权限控制会经过身份验证，并且其完整性会在设备级别以及通过基于 DICE 的身份验证在网格中的设备之间受到保护。

分层访问权限控制

AAOS SDV 采用纵深防御策略，可在不影响访问机制的情况下实现动态车辆更新。此模型依赖于两个主要信任层：

1. 服务级权限：定义给定虚拟机上的服务可以在整个网格中访问或公开的具体资源。
2. 虚拟机级权限：为特定虚拟机上托管的所有服务定义跨虚拟机通信边界。

此模型使 OEM 能够在安全性和可更新性之间取得平衡。对于非安全敏感型服务，宽松的虚拟机级政策允许通过轻量级 APEX 更新进行安装，而无需重新部署整个虚拟机。

相反，安全敏感信号的权限必须硬编码到每个虚拟机中。代价是，向新虚拟机引入安全敏感型服务时，需要在系统范围内更新虚拟机级权限。这就需要更新网格中的所有虚拟机。

总结

AAOS SDV 扩展了 Android 的安全架构，通过安全设计方法满足特定的汽车要求。该平台利用虚拟化技术实现域隔离，并强制执行“默认拒绝”访问政策，从而为软件定义车辆构建了一个弹性环境。通过硬件强制执行的已执行代码实时验证，来维护加密完整性。

该平台集成了持续的安全生命周期，从主动漏洞管理到通过 DICE 进行基于硬件的身份验证，一应俱全。这些多层防御机制使 OEM 能够在高级功能的可更新性与现代汽车环境所需的强大安全性之间取得平衡。如需了解技术规格和实现详情，请参阅 AAOS SDV 概览页面。