Android15安全架构

最近在努力完善一个超大android安全架构的PPT，在制作DICE章节时，从网络上恶补了各种官方资料。遂把这些记录下来。希望对这块感兴趣的人能有一个帮助。同时也敬请大家期待Android安全架构的扫盲课程出现。

什么是DICE？什么是DPE？

DICE简介:

Android14开始导入TCG推出的DICE标准，可以准确地证明设备的完整性。

使用DICE，系统中的引导层和固件层都会从上一层接收一个唯一的密钥。这个密钥是由一层的密钥和下一层的测量值的加密组合构建的。

如果系统被黑客所恶意攻击，任何被利用的层的测量结果都会有不同，系统软件的篡改将导致该层的密钥不同，这意味着恶意代码无法访问任何受保护的数据。即：在DICE设备中，当引入恶意代码时，该设备将自动重新加密，并保护数据。

DICE 和 DICE 层叠是帮助创建认证方案和其他系统功能的概念：

○ 由可信计算组织 (TCG) 定义：设备标识符组成引擎

○ 设备配置了一个唯一设备密钥 (UDS)。

○ 在启动时，所有加载的组件都会被测量并记录测量值。

○ UDS 和第一次测量的组合衍生出复合设备标识符 (CDI) 值。

○ 之后，通过 CDI 和测量值的组合进一步衍生出更多的 CDI。

○ 软件组件可以分组。一组组件贡献一个 CDI 值。

○ 从 CDI 中可以衍生出更多的密钥（对称和非对称）。这些密钥可以用于认证和封装。

○ 一个组由一个证书表示。该证书由从其 CDI 衍生的密钥签名。

● 什么是 DPE：

○ 另一个由 TCG 规范（由 Google 主导）：DICE 保护环境

○ DPE 是用于存储和管理 DICE 密钥、执行 DICE 衍生和签署认证证书的隔离飞地的规范。

○ 它定义了在一个安全、隔离的环境中进行 DICE 计算的硬件和软件要求。

○ 服务器-客户端架构，其中所有引导加载程序组件都是执行 DPE 服务的实体的客户端。

DICE和DPE为何如此重要？

(1)Google 对基于 DICE 的 Android 认证方案感兴趣：

○ 证书的顺序创建了 DICE 证书链。它可以表示从不可变的引导加载程序到用户空间的所有软件组件。

○ 可以通过封装和解封操作将数据绑定到给定版本的软件组件。同一版本或更高版本的软件组件可以解封（解密）之前封装（加密）的数据。

(2)已经存在一个仅软件实现：

○ 通用和特定于 Android 的 DICE 库：Open-dice 仓库

○ 证书链（理想情况下）从不可变的引导加载程序开始。

○ 所有引导加载程序阶段都会进行 DICE 计算并创建证书。DICE 数据会传递给下一个阶段，后者会扩展前一阶段的数据，以此类推。

○ 已在 Pixel 6 及以后的设备上可用。

○ 没有可用的端到端开源参考实现（从 BL1 到 pVM 用户空间）。

(3)目标是将 Android DICE 证书链扩展到 pVMs，以适应新的认证用例，例如：向 pVM 提供密钥。

(4)与仅软件实现的 DICE 相比，DPE 提供了额外的安全保证。

DPE Service运行在哪里？

(1)DPE 规范对构成 DPE 的飞地或安全环境的具体实现细节没有硬性要求。

(2)运行时安全引擎（RSE）是一个隔离的执行环境，可以为 DICE 密钥提供安全保证。

(3)RSE 的功能：

○ 片上安全飞地

○ 作为信任根：安全启动、加载组件

○ 提供运行时服务

○ 基于 M 类架构

○ 面向系统其他部分的 MHU 接口

○ 加密加速

○ 侧信道和故障注入保护

○ 专用 SRAM；一次性可编程存储器 (OTP)；ROM 代码

○ 访问所有系统内存

RSE中的DPE支持

● DPE 的实现基于 DPE 规范（修订版 0.9）和 Open DICE 配置文件的组合。

● 在 DPE 规范未指定细节的地方，遵循 Open DICE（类似于 DPE 配置文件）。

● DPE 服务保持简单：

○ 减少命令支持：DeriveContext()、GetCertificateChain()、CertifyKey()、DestroyContext()

○ 无动态内存分配

○ 支持单一、简单的会话。

● DPE 命令是 CBOR 编码的。

● 软件组件可以通过 DeriveContext 的自定义参数（cert-id）分组为层。

● 生成了一个证书链，其根植于 RSE 的 ROM 代码，代表所有通过 DeriveContext 命令记录的组件。

● 目前专注于认证用例，计划添加封装功能。

● 在 TC2 平台上开发和测试，该平台包括 RSE（TF-M 项目的一部分）。

DPE的集成

● RSE 执行运行时的 DPE 服务。

● RSE 的早期引导加载程序测量结果存储在 SRAM 中，并由 DPE 在服务初始化时进行处理。

● 所有引导加载程序阶段（直到 NS BL）都有自己的 DPE 客户端库和 MHU 驱动程序。它们发送 CBOR 编码的命令。

● 所有软件组件（配置数据也可能是：dtb）都被测量并记录到 RSE 中。

● RSE 进行 DICE 计算和证书创建。

● 上下文句柄通过引导阶段之间的共享内存传递。

● 引导流程是单线程的，带有阻塞调用。

● 打算在七月份的 TC23 发布中展示这一点。

Hybrid solution

● 完整的解决方案（DPE 集成直至 pVM 用户空间）需要大量工作。受影响组件的责任分散在许多项目之间。在生态系统中需要大规模的合作才能完成。

● 混合解决方案旨在将基于硬件支持和仅软件的解决方案混合，以产生单个的 DICE 证书链。● RSE 固件、TF-A 和 NS 引导加载程序依赖于 RSE 中的 DPE 服务（硬件支持部分）。● NS 引导加载程序查询证书链和最后的 CDI 值。● NS 引导加载程序创建一个 Android DICE 交接 blob，并将其添加到 pvmfw 的配置数据中。● 这使得 Android 软件栈能够扩展导出的证书链以产生单个的证书链。它覆盖了不可变引导加载程序到用户空间的 TCB。● 好处：○ UDS 被配置到只有 RSE 可访问的 OTP 存储器中。AP 无法访问根密钥。○ 避免了围绕 Linux/pKVM/pvmfw/用户空间集成的实现复杂性和风险。○ 将 Android DICE 证书链扩展到整个软件栈。○ 仅软件的解决方案可以逐步升级为依赖于 RSE 中的 DPE 服务。● 缺点：○ 从安全性角度来看，不是理想的解决方案。● 目标是展示 DPE 并使合作伙伴能够在其基础上构建。● 然而，Linaro 正在努力在没有 DPE 能力的执行环境的平台上为 TF-A 添加 DICE 支持。