AAOS SDV - 从设计上保证安全

在 Google，我们认为产品应从设计上保证安全，因此我们基于现有的、经过市场验证的平台构建了适用于软件定义车辆 (SDV) 的 Android Automotive 操作系统 (AAOS)，并利用了 Cuttlefish等虚拟化技术。虽然我们的发布公告侧重于介绍功能，但本博文概述了一些安全概念。

基础：网域隔离

通过虚拟化隔离共同托管的实例

目前，将电子控制单元 (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 标志装载该文件。
• 安全性更高的原因： 这不会向操作系统公开任何写入路径，因为文件不会解压缩到车辆的存储空间中。即使攻击者获得根权限，也无法修改正在运行的 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 网格通过将每个组件的网络身份以数学方式绑定到其实际二进制执行状态 来建立身份验证。此模型使用基于硬件的验证取代了隐式软件信任。

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

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

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

将主机身份扎根于现实

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

DICE 和 TLS（传输层安全协议） 集成在一起，以解决零信任架构的基本挑战：在验证机器的同时验证其软件完整性。

DICE 由硬件支持的标识和 TLS 的加密握手相结合，使接收机器能够验证调用方的身份及其确切的软件状态。

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

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

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

分层访问权限控制

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

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

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

相反，安全敏感型信号的权限必须硬编码到每个虚拟机中。这样做的缺点是，向新虚拟机引入安全敏感型服务需要更新虚拟机级权限系统。这需要更新网格中的所有虚拟机。

总结

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

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