AAOS SDV - 从设计上保证安全

Google 认为，我们的产品应在设计上就具备安全性，因此我们基于现有的经过市场验证的平台构建了 Android Automotive 软件定义车辆操作系统 (AAOS SDV)，并利用了 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 标志进行装载。
• 为什么更安全：由于文件未解压缩到车辆的存储空间，因此不会向操作系统公开任何写入路径。即使攻击者获得了 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 网格通过将每个组件的网络身份以数学方式绑定到其实际二进制执行状态来建立身份验证。此模型使用硬件根验证取代了隐式软件信任。

网状身份验证旨在实现持续的加密身份验证。这样可以避免出现以下情况：例如，车辆网关等服务仅因某个受入侵的信息娱乐虚拟机具有正确的 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 概览页面。