Android15安全架构/基于硬件信任跟/DICE和DPE简介

文摘   2024-11-14 07:24   上海  

最近在努力完善一个超大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 支持。



DICE证书链


(广告时间)

Arm架构类课程:


安全热销大课程:


安全类经典课程:


其它课程:


铂金VIP课程介绍


之最介绍

  • 招牌课程:Truszone标准版、Trustzone高配版

  • 销量前三课程:ARM三期、Secureboot、Android15安全架构

  • 持续更新的课程:ARM三期、铂金VIP

  • 非常好非常好但又被忽视的课程:CA/TA开发

  • 近期更新/力推的课程/重点课程:optee系统架构从入门到精通


说点心里话:

  • 1、不要再说课贵了,你看看咱这是啥课?别家的能比不?请不要拿通用的linux、android、python、C语言和咱这专业课比。

  • 2、咱们的VIP是数十门课程的集合。不要拿别人一门课程的价格对标咱这20门课程价格。

  • 3、这些知识很多人都会,但拿出来讲的有多少人? 愿意拿出来讲的有多少人?讲的又有多少人?

  • 4、价格都是认真计算的,并非随意定价。都是根据内容质量、核心知识点、时长和节数计算而来。从来不无缘无故涨价(涨价是需要理由的,如课程内容增加了....)。咱靠的是内容质量长期服务,而不是运营和营销(无脑涨价)。 

  • 5、如果你刷到此处,可能是老粉/铁粉,记得点赞、评论哦。感谢您的支持。

Arm精选
ARMv8/ARMv9架构、SOC架构、Trustzone/TEE安全、终端安全、SOC安全、ARM安全、ATF、OPTEE等
 最新文章