【机密计算技术】ARM 新一代机密计算架构 CCA

前言

        过去十年, TEE 主要用在移动端,可以称为机密计算 1.0,保障支付宝、微信、FIDO 支付类信任根上的安全,保障人脸、指纹等个人隐私的安全,保障高清媒体的数字版权 DRM。       

        2008 年,ARM 推出了 trustzone 技术,通过硬件设计将处理器运行状态隔离为安全(secure)状态和非安全(non-secure)状态,可以通过 tzc-400、tzc-380 等安全模块将内存分为安全内存和非安全内存。 基于Trustzone技术,厂商构建出了可信执行环境 TEE。

       未来十年,将会进入数据经济时代,敏感数据上云以及数据的跨境、流转是让数据释放更大价值的必经之路,作为隐私计算的主流技术方案,机密计算突然火起来,我们可以称之为机密计算 2.0

        2021年,时隔 13 年,ARM 推出了机密计算架构 CCA (Confidential Compute Architecture),在指令集架构下增加了的物理内存属性的划分。CCA 是ARM 针对机密计算提出新特性,也是ARM V9 架构的重要组成部分。CCA 能够为云、数据中心提供机密计算的底座,构成 ARM、x86 架构共存的计算平台。

1. 背景

        现代设备的应用软件变得越来复杂,同一台设备上可能运行不同的应用和服务,而且应用、服务、系统、固件等的提供者也各不相同,这就导致这些提供者的彼此信任的问题,例如:

  • 同一系统上,托管的应用程序彼此不信任
  • 应用不信任运行时的环境
  • 运行时环境(系统)不信任应用,这些应用可能会干扰和破坏系统和其他的服务
  • 安全服务不信任应用

        现有的 hypervisor 方案能够将应用运行在 vm 沙箱中,保护了系统免受应用的干扰和破坏,Trustzone 技术解决了安全服务免受非安全应用的干扰和破坏,但是以上的技术未能解决应用程序免受安全服务和运行时环境的干扰,即应用程序需要信任运行时环境

        ARM CCA通过一下几个方面,解决上述问题:

  • 最小的信任链:应用程序只需要信任自己,以及提供 CCA 安全保证的系统部分
  • 运行时验证可信度:部署在 CCA 中的应用程序可验证 CCA 固件的可信度
  • 可认证(Certifiable):CCA 硬件和固件实现的安全性,具有可开发、认证、检验的特点

ARM CCA 的厉害之处就是通过硬件机制和与相关固件配合,实现应用程序不必信任操作系统、hypervisor、安全服务,通过 CCA 提供的机制以及可信背书方实现信任链的缩小。

2. CCA 硬件架构

        我们可以看下 Trustzone 架构和 CCA 架构的异同点:

图 1 Trustzone 安全架构

扫描二维码关注公众号,回复: 15880361 查看本文章

图 2 CCA 安全架构

        CCA 仍然支持富操作系统+可信操作系统模式,系统模式仍然是 EL0~EL3,hypervisor 还叫 hypervisor,monitor 还是 monitor;

        CCA 在左侧增加了一个额外的隔离区,逻辑上和右侧的可信区域是对等的,我们称为 Realm(R)区域;在中间域有多个和 R 区域对应的 RVM(会用到 Realm 机密计算的 VM)。

        主要区别也可以说是编程模型上的区别:Trustzone 模型下通过将应用程序分割成普通业务逻辑 CA 和敏感业务逻辑 TA,来实现机密计算 1.0;而 CCA 可以将业务程序完全放入私密的 Realm 区域,而 RVM 里运行非机密的其他业务以及管理程序。

这个技术路线和 Intel SGX -> TDX 是异曲同工之妙~

 2.1 介绍

        CCA 硬件架构引入两种新的状态 Realm 和 Root,Realm 状态下运行机密计算程序,Root 运行 EL3 firmware。

        Armv9 硬件架构分为 4 种特权模式和 4 种状态:特权模式分别为EL3,EL2,EL1,EL0;状态分别为 Root,Realm,Secure, Non-Secure。状态控制寄存器位于 SCR_EL3 的 NS 和 NSE位,状态关系如图。

图 3 系统状态控制寄存器 

  • Root 状态包含 EL3 模式
  • Realm 状态包含 EL2,EL1,EL0 模式
  • Secure 状态包含 EL2,EL1,EL0 模式
  • Non-Secure 状态包含 EL2,EL1,EL0 模式

        物理内存的属性也为 4 种,分别是 Root PA, Realm PA,Secure PA, Non-Secure PA,访问权限如图。

图 4 内存访问控制 

2.2 内存管理

        ARM CCA 引入了颗粒保护表 Granule Protection Table (GPT) 和颗粒检查表 Granule Protection Check (GPC) 概念,以提供物理内存属性动态划分机制。GPT 是用于管理物理内存空间的属性的表,它只能由 EL3 模式下的 monitor 操作。GPC 是硬件层面的检查模块,在处理器在访问物理内存时,GPC 会根据 GPT 中的属性配置进行检查(SMMU 也引入了 GPC)。

图 5 GPC 颗粒检查器 

2.3 内存加密机制

        ARM CCA 提供内存加密机制,数据以密文的形式存在 DRAM 中,每个地址空间采用不同密钥,实现不同空间数据的隔离,MPE (Memory Protection Engine)对存取 DRAM 的数据进行加解密。

图 6 内存加密引擎 

2.4 中断机制

        ARM CCA 机制的引入,未改变 ARM GIC 模块。Non-Secure hypervisor 通过虚拟中断机制(vGIC),将中断分发到 Realm 中(hypervisor 像调度普通 VM 一样调度 Realm)。

3. CCA 软件架构

        Realm 里可以运行机密计算系统和应用;

        RMM 是 Realm 的管理器,为 Realm 中的应用提供RSI 接口服务,同时为 Non-secure 的 hypervisor 提供服务;

        Monitor 是在原有的 TF-A 基础上增加了 GPT 的管理和 Realm 状态与 Non-secure 状态的上下文切换机制。

图 7 Realm 软件架构 

3.1 Realm

        hypervisor 能够动态的创建 Realm,Realm 初始化阶段可以通过 Realm 管理接口(Realm Management Interface,RMI),对运行环境进行证明(Attestation)。证明过程不依赖于非安全态的 hypervisor 和安全态的 TEE(在 1.0 时代,应用必须无条件相信这两个组件)。 Hypervisor 能够通过 RMM 创建,销毁,以及调度 Realm,但是无法更改 Realm 的指令和数据。

        Realm 的运行时环境既可以采用类 Linux 的常规操作系统,也可以采用 Enarx、Occlum、 Graphene 等库操作系统(libos)。

3.2 Monitor

        在非 CCA 架构下,EL3 模式运行的可信固件称为 TF-A(Trust Firmware for A Profile),针对 ARM CCA 机制,TF-A 完成如下修改:

  • 加载和运行 RMM 镜像
  • 切换 Non-secure,Secure,Realm 状态的上下文
  • 管理 GPT 页表

3.3 RMM

RMM(Realm Management Monitor)运行在 EL2 模式,主要负责如下功能:

  • 管理 Realm 的生命周期:包括 Realm 的创建与销毁。在运行/初始化的 Realm 的过程,Realm 可以通过 RSI 接口调用证明服务,完成运行时环境的证明
  • 管理 Realm 的 context:vcpu 的调度机制由 hypervisor 管理,即计算资源由非安全侧分配。进入 Realm 时,RMM 恢复 Realm 的上下文;退出 Realm 时,RMM 保存 Realm 的上下文状态。 Realm 通过共享内存与非安全侧通信
  • 管理内存: Realm 运行时的内存分为两类:
    • Protected ranges: Realm 的代码等运行的区域
    • Unprotected ranges: 共享存储区域,例如实现 virtio 的内存,非安全侧可以访问
  • 管理中断
    • ARM CCA特性的引入未改变 GIC 的原有机制,Realm 的中断是由 hypervisor GIC 虚拟中断实现,CCA 侧重的计算过程数据的安全性同时不影响非安全侧原有业务运行,所以对于 cpu 和中断的可用性并没有介入太多

4. 系统启动流程

        系统未引入 ARM CCA 机制时的系统启动流程中,BL2 运行在 EL3 或者 Secure EL0/EL1/EL2 模式,初始化 DRAM 等设备,并完成 BL31、BL32,、BL33 镜像的加载和校验。BL31完成 TEE 系统和 REE 系统的初始化。

图 8 非 CCA 启动流程 

        系统引入 ARM CCA 机制时的系统启动流程中,BL2 须运行在在 EL3 模式,初始化 DRAM 等设备,并完成 BL31、BL32、 BL33、RMM 镜像的加载和校验。BL31 完成 TEE 系统,RMM 系统和 REE 系统的初始化。

图 9 CCA 启动流程

5. 证明 Attestation

       证明是可信计算范畴的一个概念,以背书证书为基础,对软件、固件、配置数据等进行可靠声明以实现可信验证的技术方案。ARM CCA 提供 attestation 功能以确保 Realm 感知到运行平台的真实可信性。ARM CCA 推荐使用基于硬件安全增强 HES(HARDWARE ENFORCED SECURITY)模块保证平台的安全性。

图 10 CCA 证明流程 

        证明流程如图,整个动态收集的声明报告主要包括两部分:

  • TF-A 和 HES 提供的平台相关的声明
  • RMM 提供的 Realm 运行时的状态的声明

6. CCA 实现实例

        EL3 在 Root 状态下,运行 TF-A monitor;

        EL2 在 Realm、Non-secure、Secure状态下,分别运行 TF-RMM,Linux KVM 和 Hafnium SPM;

        EL1 在 Realm、Non-secure、Secure 状态下,分别运行 Linux VM、OS VM 和OP-TEE

图 11 CCA 实例 

       Linux KVM 可以通过 TF RMM 的 RMI 与 VM 进行交互,并对 VM 进行调度(Linux KVM创建两个 VM ,分别运行在各自独立的 Realm中)。

       通过 ARM CCA 提供的内存加密和 GPC 机制,系统能够保证 Non-secure hypervisor 无法获取 Realm 运行的数据。Realm 启动和运行的过程中,可以对运行环境进行证明,保证了运行环境的真实性。

7. 应用场景

7.1 数据中心

•  托管环境(hosting environment) 为物理服务器

•  Realm 为受保护的客户虚拟机或云服务实例

•  依赖方(reliant party) 为连接到Realm 以执行某些任务的远程客户端

  • 7.2 移动客户端

• 托管环境(hosting environment)可能是物理移动设备

• Realm 可能是受保护的客户应用程序或服务

• 依赖方(reliant party)可能是连接到Realm 以执行某些任务的远程服务。

8. 附录:CCA 生态

皮格马利翁效应心理学指出,赞美、赞同能够产生奇迹,越具体,效果越好~
“收藏夹吃灰”是学“器”练“术”非常聪明的方法,帮助我们避免日常低效的勤奋~

猜你喜欢

转载自blog.csdn.net/BillyThe/article/details/131892694