虚拟化与密码技术应用: 现状与未来*

付 裕, 林璟锵, 冯登国

1.中国科学技术大学 网络空间安全学院, 合肥 230027

2.中国科学院 软件研究所, 北京 100190

1 引言

虚拟化技术是一种典型的资源管控技术, 将计算机系统的计算、存储等资源抽象成为隔离的运行环境,供多个独立运行的用户态程序或客户虚拟机使用.利用虚拟化技术, 计算机系统可以按需为不同的任务分配资源, 使其共同运行在同一硬件设备上.狭义的虚拟化技术, 通常指虚拟机监控器Hypervisor 为客户虚拟机提供的隔离运行环境; 本文所阐述的技术范围, 是广义的虚拟化, 泛指在计算机系统中, 高特权级组件对计算、存储等资源抽象成为隔离的运行环境, 供低特权组件运行使用, 既包括Hypervisor 提供的虚拟化运行环境, 也包括操作系统提供的用户态程序运行环境.进一步, 利用CPU 硬件安全特性创建的多种可信执行环境(trusted execution environment, TEE) 也可视为由广义的虚拟化技术创建的运行环境.相比普通用户态程序或虚拟机的运行环境, 可信执行环境具有更多特性, 包括内存加密、完整性验证、远程证明等基于密码学原理的安全特性, 能够防范更多攻击威胁.基于以上考虑, 本文讨论的范围包括了操作系统、虚拟化系统和可信执行环境的相关密码应用安全技术研究.

本文从不同方面系统地梳理了虚拟化与密码技术应用的结合研究: 正如第2 节所述, 一方面是使用密码技术缓解虚拟化系统面临的安全风险, 另一方面, 虚拟化技术也给密码技术应用带来了新的机遇.在早期的计算机系统中, 由于CPU 不带有专门硬件安全特性, 第3 节介绍了以软件形式实现的用户态程序或客户虚拟机内存加密、可信启动以及虚拟化环境加密权限的相关研究, 可以缓解虚拟化面临的多种系统安全风险; 同时, 利用虚拟化技术, 也可以为密码技术应用提供更多额外安全保障, 例如密钥安全和密码计算调用安全等.第4 节主要介绍了应用于TEE 的基于密码技术的硬件安全特性, 以及相应的攻防研究, 涉及Intel SGX、AMD SEV 和ARM TrustZone 等.第5 节是总结和展望.

2 虚拟化与密码技术应用: 共生发展

作为基础性的信息安全技术, 密码技术可以为各种信息系统提供安全解决方案.在虚拟化系统中, 密码技术可用于解决如下安全威胁.首先, 通过内存加密保护客户虚拟机, 获得更高安全强度的隔离保护效果, 缓解来自于共存的客户虚拟机甚至Hypervisor 的非授权访问[1,2]; 类似地, 内存加密也用于保护用户态程序免受来自于共存程序、操作系统的非授权访问; 同时, 也可以解决可能的外部物理攻击[3–5]的威胁.其次, 实现用户态程序或客户虚拟机的代码完整性验证, 进一步包括可信启动和远程验证[6,7], 从而避免高特权组件的恶意篡改.然后, 在完整性验证的基础上, 还可以为客户虚拟机分配不同密钥, 用于安全的数据长期存储[6].

虚拟化系统的任务隔离和特权分级, 也有利于密码计算的安全执行.在密码算法的常见实现中, 密钥通常以明文出现在计算机系统的内存.在隔离运行环境中执行密码算法, 能够更好地保护运行期的密钥数据, 抵御多种不同类型的攻击.例如, Windows 操作系统的密码服务框架CSP (cryptographic service provider)[8]和CNG (cryptography API next generation)[9], 在操作系统内核中实现了密码算法, 供用户态程序调用.Linux 操作系统的/dev/random 和/dev/urandom 为密码计算提供了设计完善的随机数生成器, 并在内核中保护随机数发生器的敏感内部状态信息.类似地, 在Hypervisor 中实现虚拟TPM 等密码设备, 能够获得更多的安全保障, 确保只有授权的客户虚拟机或客户程序能够调用密码计算[10,11].

总体而言, 基于密码技术的安全方案, 可用于虚拟化环境的客户虚拟机或用户态程序, 使其具有更多、更高的安全特性; 这些安全特性, 可以是虚拟化系统以软件形式实现的, 也可以是依赖于CPU 的硬件安全特性.同时, 密码算法在虚拟化系统的隔离运行环境中执行, 有利于密钥等敏感安全参数的保护, 也能够利用虚拟化系统的特权分级, 更彻底地实施密码计算服务所需要的安全措施.图1 总结了密码技术和虚拟化系统相互依赖、提升安全性的技术点.

图1 密码技术应用和虚拟化系统相互支撑、提升安全性Figure 1 Security from mutual integrations of applied cryptography and virtualization systems

3 虚拟化系统的密码技术应用: 软件解决方案

本节介绍在虚拟化系统中以软件形式实现的、利用密码技术的安全方案, 主要包括用户态程序和客户虚拟机的内存加密、虚拟化环境加密权限管理、虚拟TPM 以及利用虚拟化特性的密码计算.

3.1 内存加密

相比于非易失性存储的存储加密(例如, QEMU 镜像文件加密[12]、TrueCrypt 全磁盘加密[13]、数据库加密TDE 等), 内存加密进一步关注运行期的内存数据安全问题: (1) 由于操作系统内存交换机制导致内存数据被交换到外部的、易受攻击的存储器; (2) 用户态程序或客户虚拟机的运行期内存数据所面临的各种内存信息泄露攻击.

文献[14] 修改操作系统的Pager 程序, 对物理内存和外部扩展存储器交互的数据进行实时的加解密操作.修改后的Pager 程序会自动加密交换出的内存页, 从外部存储器读入内存页时解密数据; 而且, 使用操作系统内核熵池生成密钥, 并定期更新.Hypnoguard[15]保护操作系统睡眠时的内存数据: 在系统进入ACPI S3/suspend-to-RAM 状态时, 生成临时对称密钥, 加密全部内存数据, 并且用TPM 芯片来保护该对称密钥.在系统唤醒时, 进入Intel TXT (trusted execution technology) 执行状态, 用户输入正确口令后才会从TPM 芯片解密获得对称密钥, 并解密内存数据.

以上方案将操作系统视为整体, 进行内存加密保护.下面介绍用户态程序粒度的内存加密方案, 在操作系统正常运行时, 加密重要用户态程序的内存数据; 其中, 部分方案借助于ARM TrustZone 安全世界或Hypervisor, 使得操作系统在调度用户态程序的同时, 不能读取用户态程序的内存数据.

3.1.1 用户态程序内存加密

Cryptkeeper[16]和RamCrypt[17]依赖操作系统完成用户态程序粒度的内存加密: 将程序的数据内存页分成少量的明文页以及大部分的加密页, 当数据不在用时一直保存在加密页, 被访问时则由操作系统解密到明文页.Cryptkeeper 和RamCrypt 可以大幅度地减少敏感数据的暴露窗口.相比Cryptkeeper,RamCrypt 将密钥保护在寄存器中, 进一步防范内存信息的物理攻击(例如冷启动攻击和大部分内存信息泄露攻击).CryptMe[18]也支持用户态程序粒度的内存加密, 并进一步考虑了由于操作系统功能误用导致的内存敏感数据泄露: 用户态程序的数据在处理时, 必须是解密的明文状态, 所以CryptMe 将其切换到隔离保护的、更高特权的ARM TrustZone 安全世界来执行, 避免由于操作系统功能误用问题而泄露敏感数据.相应地, 内存数据加密密钥也保护在ARM TrustZone 安全世界.

Sentry[19]是用于移动设备的内存加密系统.考虑到移动设备的特殊性, Sentry 减少了实施内存加密功能的时间窗, 以提升效率: 因为设备丢失后的内存信息物理攻击是移动设备的主要安全威胁, 所以Sentry 仅在移动设备被锁定时加密重要用户态程序的全部内存数据, 在设备解锁时解密数据.为了抵抗物理攻击, Sentry 将密钥保护在片内iRAM 或片内Cache.

3.1.2 虚拟机内存数据加密和完整性

Overshadow、InkTag 和SP3完成了基于Hypervisor 的虚拟机内存数据安全: 对于虚拟机的操作系统来说, 运行在客户虚拟机上的用户态程序内存数据处于加密状态, 操作系统可以调度程序, 但是无法读取其内存数据明文.上述方案利用Hypervisor 加密位于虚拟机中的用户态程序内存数据, 使其免受恶意操作系统的威胁.

Overshadow[20]依据客户虚拟机的上下文为操作系统和应用程序呈现不同的内存页视图.当操作系统访问应用程序时, Hypervisor 呈现内存页的加密视图并计算摘要.当应用程序访问加密内存页时,Hypervisor 验证摘要, 然后解密内存页.相比于Overshadow, InkTag[21]进一步允许不同进程可以共享受保护的数据, 并且保证数据与摘要的一致性.

SP3[22]提出内存保护域(protection domain) 的概念, 一个保护域中的内存页访问权限与一组密钥相关联, 即依据访问权限决定是否可以使用密钥加密/解密内存页.保护域可以是一个或者多个进程.每一个保护域有唯一标识SID、KID 用于标识对称密钥, 然后SP3维护对称密钥的数据库及其权限位图, 权限位图指明SID 标识的域可以使用哪些对称密钥来解密对应的内存页(不同的内存页对应不同的密钥).KID 0 为操作系统的保护域保留, 使得操作系统访问的内存页总是处于加密状态.相比于Overshadow 无选择地加密整个应用程序, SP3可以有选择地加密应用程序的部分内存页, 并且SP3同时保留内存页的解密副本, 降低密码运算带来的延迟.

3.2 虚拟化环境的加密权限管理

回顾上文介绍的CryptMe 方案, 为了防止操作系统功能误用导致敏感数据泄露, CryptMe 把密钥保护在更高特权的ARM TrustZone 安全世界中.这种加密权限的管理安全技术思路也可以应用在虚拟化系统中.Overshadow、InkTag 和SP3使用Hypervisor 加密虚拟机内存数据, 其中隐含假设Hypervisor 是可信的.加密权限管理的安全解决方案,进一步考虑了Hypervisor 被攻击的情况,构建出比Hypervisor 更高特权的轻量级组件.该组件掌握加密能力, 限制Hypervisor 对虚拟机敏感数据的访问, 防御Hypervisor层面的潜在攻击.

CloudVisor[23]使用嵌套虚拟化[24]的思想进行权限管理的安全增强.CloudVisor 可以视为运行在最高特权级别的小型安全监控组件,监控Hypervisor 和客户虚拟机之间的交互,基于密码技术保护虚拟机数据的机密性和完整性(包括内存数据和磁盘数据).首先, CloudVisor 对Hypervisor 和虚拟机之间的控制转移进行额外的转换和保护.在发生虚拟机退出(VM exit) 中断时, CloudVisor 保护通用寄存器的数据, 只向Hypervisor 提供必要数据以限制暴露给Hypervisor 的信息.其次, CloudVisor 限制Hypervisor对虚拟机内存的管理.CloudVisor 跟踪每个物理页的所有权, 不允许Hypervisor 直接改写扩展页表: 当扩展页表更新时, CloudVisor 检查页所有权是否与页表所有权相匹配; 如果不匹配, CloudVisor 就加密内存页内容.最后, CloudVisor 在客户虚拟机访问虚拟磁盘时, 进行透明的加解密并对磁盘数据进行完整性校验.此外, CloudVisor 还维护每个客户虚拟机的I/O 访问权限表防止来自Hypervisor 的DMA 攻击.

CaaS[25]改进Xen Hypervisor 构建了用户可控的密码服务.CaaS 将原本运行在特权域Dom0 的管理代码, 例如创建、迁移、销毁虚拟机等功能移入更小的受信域DomT, 并将Dom0 降级为非完全受信任的域; 同时将DomU (代表客户虚拟机) 与密码计算有关的敏感操作划分到独立的安全环境DomC 中.DomU 可以使用DomC 提供的加密服务.DomC 镜像数据加密的密钥只由DomT 获取, 抵抗来自Dom0的特权管理员的安全威胁.

3.3 虚拟密码设备

虚拟密码设备源自于如下的考虑: (1) 在Hypervisor 中, 将原有不支持多个操作系统或虚拟机访问的硬件密码设备扩展为支持多个操作系统或虚拟机; (2) 将密码计算的运行环境置于更高特权的组件(通常也意味着更少代码量和更少攻击面), 获得更进一步的安全保护; 例如, 将密码计算功能从操作系统内核转移到Hypervisor, 实现为虚拟密码设备.

可信平台模块TPM (trusted platform module)[26]是国际可信计算工作组提出的安全标准设备.TPM 可作为独立的芯片被连接到计算机系统, 提供了管理密钥、密码计算的独立空间, 以实现可信启动、完整性度量和验证、远程证明等安全功能.当TPM 应用于多客户虚拟机时, 单一的TPM 芯片难以同时满足多个虚拟机的性能和功能需求.在Hypervisor 中, 基于TPM 芯片, 配合软件功能可虚拟出多个软件TPM, 称为vTPM[27].vTPM 向客户虚拟机的操作系统和应用程序提供与硬件TPM 相同的使用模式和命令集, 使得为TPM 编写的软件可以继续在vTPM 上使用; vTPM 也与虚拟机的迁移等功能兼容.但是, vTPM 的敏感数据会受到各种安全威胁[28]: 使用TPM 芯片密封vTPM 敏感数据, 可以提供数据静态保护; SvTPM[29]在vTPM 架构的基础上, 在Hypervisor 不完全可信的情况下使用SGX 保证其运行时动态安全.

SECRIN[10]利用虚拟化管理系统的已有设备管理能力, 实现虚拟密码设备的有效安全管理, 包括:密钥在Hypervisor 完成密码计算, 运行为虚拟密码设备, 租户远程交互式地输入PBE (password-based encryption) 口令以实现虚拟密码设备的初始化, 集中管理虚拟密码设备与客户虚拟机之间的映射关系等,虚拟密码设备与虚拟机迁移完全兼容, 能够不间断提供服务.

3.4 利用虚拟化特性的密码计算功能

结合虚拟化系统, 可以更好地实施密码技术.TreVisor[30]方案结合TRESOR[31]和BitVisor[32]的技术优势, 利用Hypervisor 实现透明的磁盘加密, 保护密钥免受内存信息泄露攻击的威胁.TRESOR 磁盘加密系统将AES 对称密钥限定在Debug 寄存器中, 但是要求修改操作系统内核, 难以用在Windows等闭源系统.TreVisor 修改了BitVisor Hypervisor, 在其中实施磁盘外设的TRESOR 数据加密方案,Hypervisor 也将AES 对称密钥限定在Debug 寄存器中, 以保持TRESOR 原有设计的安全性.

如第3.3 节所述, 在虚拟化环境中, 客户虚拟机的大量密码计算依赖于Hypervisor 管理的密码设备(包括虚拟密码设备).通常用户态程序或者客户虚拟机在调用密码计算时, 需要拥有用户ID 和口令; 一旦用户ID 和口令泄露, 攻击者就可以调用密码计算.基于上述考虑, Hypervisor 还可以进一步实施对调用者透明的密码计算调用安全: 基于虚拟机自省[33], En-ACCI[34]在客户虚拟机调用密码计算时, 触发Hypervisor 检查该虚拟机的运行状态信息, 包括进程标识符、进程启动时间、用户标识符、用户组标识符、进程的文件和网络连接等, 根据预先设置的调用策略判定是否允许调用.TF-BIV 方案[11]进一步实现了更完善的虚拟机运行期代码完整性校验, 然后实施密码计算的调用安全, 使得只有特定的用户态程序可以调用密码计算, 且该用户态程序以及使用的相关共享代码都没有被篡改.

操作系统内核自动拥有所有用户态程序的网络流量监控能力, 可用于实施强制性的密码应用安全策略.TrustBase[35]由操作系统监控用户态程序的TLS 流量, 实施更为严格的数字证书验证, 避免用户态程序遗留的数字证书验证漏洞.类似地, Hypervisor 也拥有所有虚拟机的网络流量监控能力, vCert-Guard[36]也实施了类似的数字证书验证和撤销状态检查, 支持更便利的根CA 证书列表管理和更高效的证书撤销状态信息缓存.

4 可信执行环境的密码技术应用: 特性、演进和应用方案

第3 节阐述了在虚拟运行环境中应用密码技术, 获得更高安全保障的内存机密性、代码完整性、数据存储保护和远程证明等.上述安全特性也是可信执行环境TEE 所需要的安全特性.近年来各CPU 厂商也开始在CPU 硬件上引入TEE 支持, 为隔离的运行环境提供更多基于硬件安全特性的保障.相比于软件解决方案, 基于CPU 硬件安全特性的解决方案能够减少对操作系统和Hypervisor 的信赖、减少可信计算基TCB (trusted computing base) 代码.

目前主流的硬件TEE 方案, 包括有Intel SGX、AMD SEV、ARM TrustZone 以及RISC-V Key-Stone、Intel TDX、ARM CCA 等.主流云服务提供商已经支持创建TEE 功能的虚拟机或者用户态程序, 包括谷歌、亚马逊、微软、百度、阿里巴巴等.表1 对比了不同的CPU 硬件TEE 方案, 分别提供了不同的运行环境抽象和安全特性.从运行环境抽象的角度, Intel SGX 提供了应用程序的安全抽象, 保护应用程序粒度的敏感数据和代码.AMD SEV 则提供了虚拟机抽象, 将客户虚拟机视为整体, 保护该虚拟机中的所有应用程序和操作系统.ARM TrustZone 提供了物理机抽象, 即安全世界包含了隔离保护的CPU状态、内存和外设等, 抵抗来自于普通世界的安全威胁.其他TEE 方案也分别选择了不同的运行环境抽象, 应用程序和物理机抽象在应用中需要更多的开发适配工作, 而虚拟机抽象与已有的虚拟化系统架构更为匹配, 应用过程的开发适配较少.

表1 不同TEE 方案的特性对比Table 1 Comparison of different TEEs

基于CPU 硬件TEE 的应用研究, 是未来的重要方向之一.各种硬件TEE 方案的攻防技术, 也是广受关注的研究方向, 包括硬件TEE 方案自身的安全性(例如远程证明密钥泄露) 以及运行在TEE 环境中的用户态程序安全性(例如密码计算程序的密钥泄露).另外, 不同的硬件TEE 方案提供的安全特性并不一致, 也有大量的软件开发工作致力于“补齐” 不同方案之间的安全特性, 努力为上层应用系统提供统一的基础性安全防护.

下文针对不同的主流TEE 分别介绍相关研究, 并在最后简要介绍国产CPU 和异构计算单元的TEE方案.

4.1 Intel SGX 密码技术应用

4.1.1 SGX 基础功能

SGX(software guard extensions)[6]是Intel CPU 的安全扩展,通过一组安全指令创建隔离的运行环境(称为Enclave), 使得运行在Enclave 中的多种应用程序免受恶意软件以及物理攻击的威胁.SGX 提供了隔离、远程证明和数据密封等机制来保证数据和代码的机密性和完整性.SGX 将操作系统、Hypervisor等特权代码都列为不受信任的范畴, 仅需要信任CPU.

• 隔离(内存加密和完整性): SGX 保证Enclave 的外部实体无法访问Enclave 内部的数据、代码以及使用的寄存器.Enclave 同时具有内存加密和完整性验证的安全特性.Enclave 程序使用的内存区域位于处理器保留内存(processor reserved memory, PRM).PRM 由CPU 自动进行加密, 相应的密钥存储在CPU 内部.每个Enclave 程序有唯一标识的度量值, 由内存数据SHA-256 计算得到; 加载Enclave 时, 依据度量值可以判断程序是否被恶意篡改.

• 远程证明: 向第三方签发不可伪造的消息来证明Enclave 程序正确地运行在支持SGX 的平台上,并且Enclave 内的代码未被篡改.

• 数据密封: 使用只能由Enclave 程序自身访问的密封密钥对Enclave 输出的数据进行加密, 用于Enclave 程序的数据存储安全(存储在Enclave 外部).

4.1.2 SGX 虚拟化功能扩展

Intel 进一步引入了SGX 超额订阅扩展(SGX oversubscription extensions)[37], 提供了新的指令和虚拟化支持, 使得Hypervisor 能够更简单高效地实现内存超额订阅, 提高虚拟机密度.

但是, SGX 的设计不能与虚拟化平台直接适配.因此, 有相关研究工作完成了更全面的SGX 虚拟化功能支持.由于操作系统和Hypervisor 无法感知Enclave 的运行状态, 所以运行Enclave 的虚拟机失去了迁移能力.文献[38] 研究了支持SGX 的虚拟机迁移问题, 该方案可以安全地转储Enclave 内部状态,同时确保迁移后的每个Enclave 实例不会发生回滚或者生成多个实例.文献[39] 进一步考虑了经过密封密钥加密后的, 存储在Enclave 外部的持久数据迁移, 包括密封数据和单调计数器.

相比于虚拟机, Docker 容器[40]的安全性较弱但是具有性能优势.Scone 方案[41]使用SGX 构建安全容器, 将容器中的应用程序放到Enclave 运行, 提高数据和代码的安全性, 同时保持较低的性能开销.

4.1.3 SGX 应用

相比于虚拟机抽象, 应用程序抽象的SGX 需要受保护程序的二次开发, 移植工作量更多.例如, VC3方案[42]将SGX 用于MapReduce 框架, 文献[43] 将SGX 应用于TOR 匿名通信系统, SGX 也被用于机器学习[44]、数据库[45]、单点登录[46,47]、区块链[48–50]、多方安全计算[51]等不同系统.文献[52] 对SGX 的应用进行了总结.

为了使已有软件更方便地运行在SGX 环境, 有研究工作在Enclave 中部署运行时库, 从而支持未经修改的通用应用程序.Haven[53]在Enclave 中部署操作系统库LibOS 来支持不需修改的Windows 应用程序.Graphene-SGX 方案[54]则在Enclave 中部署支持Linux 应用程序的LibOS, Graphene-SGX还支持动态加载库的完整性、Enclave 级别的fork 以及安全的进程间通信.Occlum 方案[55]也是运行SGX Enclave 的LibOS, 实现了安全高效的多任务处理.Graphene-SGX 和Occlum 都已经开源发布.

目前, 已有厂商使用SGX 构建商用的机密计算平台, 例如, 基于SGX 构建的Apache Teaclave[56],微软Azure 机密计算[57]支持SGX (也支持AMD SEV); 蚂蚁集团和Intel 合作基于Analytics Zoo 和Occlum 搭建隐私保护机器学习平台[58].

4.1.4 基于SGX 构建安全密码方案

SGX 可以为密钥等敏感数据提供存储期和运行期的保护.SGX SSL[59]是Intel 基于SGX 实现的开源密码软件, 包括密码库、SGX SSL 可信库和SGX SSL 非可信库.其中, 密码库保证OpenSSL 的密码计算功能可以在Enclave 中运行, 更好地保护密钥等敏感数据, 可信库和非可信库分别在Enclave 内部和外部提供了相应的操作系统调用.当密码库的运行不涉及系统调用或是涉及的系统调用在Enclave 内部实现时, 密码计算不需要离开Enclave; 否则, 会跳转至Enclave 外部的SGX SSL 非可信库.

SGX 提供了基于CPU 硬件的代码完整性和数据密封以及远程证明, 使得攻击者难以窃取或利用其中的敏感数据, 可将其视为“信息技术原理” 的困难问题(不同于传统的数学原理困难问题), 从而构建高效的密码系统, 包括函数加密和基于身份的加密.IRON[60]基于SGX 构造函数加密系统, 使得用户只能获得与明文数据相关的函数值而不能获得具体的明文信息.IRON 系统包括: 基于SGX Enclave 构建的受信组件KME (key manager enclave) 以及数据使用者的DE (decryption enclave) 和FE (function enclave).当数据拥有者上传到KME 的加密数据被使用时, DE 通过公钥加密和签名算法与KME 交互,获得解密密钥, 然后通过安全信道将其传入FE 中.FE 使用解密密钥恢复出数据明文并计算相应的函数值.由于明文数据和计算涉及到的密钥被SGX Enclave 保护, 所以数据使用者无法获知相应的敏感数据.IRON 方案利用SGX 安全特性, 将复杂的函数加密算法替换为普通的公钥密码算法来提升性能.PoS 方案[61]使用类似的技术思想, 基于AES、HMAC 等高性能对称密码算法, 结合Enclave 来保证密钥的特定使用, 由此实现基于身份的公钥加密功能.SCB 方案[62]进一步将PoS 方案扩展至属性加密和环签名等.

4.1.5 攻击和防护

已有多种针对SGX 的攻击, 造成的后果也各有不同.SGX 提供了隔离的运行环境Enclave, 但是仍有侧信道攻击可以窃取运行在Enclave 中的密码软件的密钥; 另一方面, SGX 自身也使用密码技术确保Enclave 的安全性, SGX 的缺陷也使得攻击者可以获取SGX 机制自身的密钥(例如远程证明密钥、密封密钥等).

针对SGX 的侧信道攻击主要包括基于页表的侧信道攻击[63–66]、基于Cache 的侧信道攻击[67–71]和基于分支预测的侧信道攻击[72].文献[63,64] 表明基于页表的侧信道攻击可以获取Libgcrypt 软件的EdDSA 密钥; 文献[67–70] 给出了基于Cache 的侧信道攻击, 从多种不同的密码软件中获取AES 密钥和RSA 密钥; 文献[72] 给出了基于分支预测的侧信道攻击、获取Mbed TLS 的RSA 密钥.为了抵抗针对SGX 的侧信道攻击, 也有多种防护措施被提出, 包括异常检测[73,74]、随机化[75,76]、隔离增强[77]等方法, 也可以修改源码[78]隐藏Enclave 程序的控制流和数据流.文献[79,80] 总结了针对SGX 的侧信道攻击和防护措施.

瞬态执行攻击, 源于处理器为了优化性能而引入的乱序执行和预测执行, 攻击者可以通过微架构状态信息提取异常操作泄露的秘密数据.针对SGX 的瞬态执行攻击[81–84]可以获取SGX 自身使用的密钥,带来严重威胁.例如,文献[81]给出了获取远程证明密钥和启动密钥的攻击方法,文献[82]可以获取SGX远程证明密钥和密封密钥.瞬态执行攻击也可以获得受SGX 保护的密码软件密钥; 例如, 文献[84] 可以跨核提取受Enclave 保护的ECDSA 密钥.相应的缓解措施包括: 通过微码更新发布硬件补丁、在每条瞬态指令后插入lfence 指令, 或者是在芯片级别修改处理器结构.文献[80,85] 对瞬态执行攻击及防护措施给出了分析和总结.

针对数据密封的回滚攻击会破坏数据, 例如使用旧的密封数据替换新的密封数据.解决回滚攻击的方法是保证Enclave 状态的新鲜度(Freshness).Intel 推荐使用单调计算器[86]抵抗回滚攻击, ROTE[87]也提出了基于分布式系统的保护方案.

4.2 AMD SEV 密码技术应用

4.2.1 SEV 基础功能

SEV (secure encrypted virtualization) 是AMD 处理器的硬件扩展, 为不可信环境的虚拟机提供安全保护, 防止来自其他虚拟机和Hypervisor 的威胁.在SEV 之前, 2013 年提出的HyperCoffer 方案[88]就完成了虚拟机粒度的内存加密隔离.HyperCoffer 使用了支持AISE (address independent seed encryption) 算法和BMT (Bonsai Merkle tree) 算法[89]的安全处理器为虚拟机提供内存数据加密和完整性保护; 但是, HyperCoffer 只是在仿真器上实现.

目前, 支持SEV 特性的AMD 处理器已经被广泛使用, SEV 为虚拟机提供了内存加密、远程证明等功能.SEV 的内存加密功能由处理器SME (secure memory encryption) 引擎提供.在读写数据时,使用DRAM 控制器内置的AES 加密引擎自动对内存数据进行加解密.SEV 为每一个虚拟机生成独立的密钥, 集成了专门管理密钥的控制器SP (secure processor), SP 拥有独立的存储区域且该区域无法被Hypervisor 等特权组件访问.SEV 远程证明用以确保目标平台的真实性, 即虚拟机运行在真实的SEV 环境中, 且确保虚拟机的二进制代码未被篡改.

4.2.2 SEV 技术演进

AMD 于2016 年发布第一代SEV[90]技术文档.随后, 研究人员发现其中有多种设计漏洞, 包括未加密VMCB (vitrual machine control block)[91,92]、内存加密缺乏认证[93–95]、嵌套页表未保护[91,96,97]、I/O 未保护[98]以及ASID (address space identify) 滥用[99]等.VMCB 未加密使得Hypervisor 可以窥探虚拟机的执行状态甚至操控虚拟机的控制流.缺乏认证的内存加密是指由于缺乏身份认证, Hypervisor可以读取和更改SEV 虚拟机的内存、破坏完整性.嵌套页表未保护导致Hypervisor 可以在管理嵌套页表的过程中更改虚拟机的内存映射.I/O 未保护是指I/O 操作(例如DMA 访问) 会使用Hypervisor 与虚拟机共享的内存, 恶意Hypervisor 可以更改I/O 数据.最后, ASID 用于索引虚拟机密钥, 并且控制缓存行(cache line) 和TLB 条目(translation lookaside buffer entries) 的访问, ASID 滥用攻击可以修改虚拟机的ASID.文献[100] 对公开已知的SEV 漏洞有详细总结.需要说明的是, 第三代SEV-SNP 已经修复了VMCB 未加密以及完整性保护缺失等问题, 相应的攻击不再有效.

2017 年, AMD 发布了第二代版本SEV-ES[101]技术文档.相比于初代SEV, SEV-ES 最主要改进是将虚拟机控制块VMCB 的敏感部分加密存储到VMSA (virtual machine saving area), 用于与Hypervisor 通信的部分依旧保持明文.SEV-ES 使得Hypervisor 操控虚拟机控制流的能力受到限制, 但是完整性保护缺失问题仍未修复.2018 年, Fidelius[102]针对初代SEV 和第二代SEV-ES 存在的安全问题, 使用软件方式实施SEV 扩展, 抵抗来自Hypervisor 的威胁.Fidelius 的技术思路与3.2 节讨论的方案类似,使用代码更小的受信任组件限制不可信Hypervisor 访问虚拟机敏感数据的能力, 包括限制Hypervisor 的页表管理、隐藏VMCB 的敏感数据、禁止Hypervisor 直接访问ASID 以及I/O 数据加密等.

2020 年, AMD 发布了第三代SEV-SNP[7], 在第二代SEV-ES 的基础上进一步解决完整性保护缺失问题.SEV-SNP 引入Reverse Map Table (RMP) 和Page Validation.RMP 保证只有内存页的拥有者才可以向其中写入数据, 并且保证同一时刻同一个物理页只能被映射到一个虚拟机; RMP 可以有效抵抗内存数据重放、内存数据损坏和内存混叠(memory aliasing).Page Validation 保证同一时刻同一个虚拟机内存页只能被映射到一个物理内存页, 以此抵抗内存重映射.

SEV-SNP 仍会受到密文侧信道攻击[100,103]以及电压故障攻击[104]的威胁.密文侧信道攻击可以恢复出部分SEV 保护的明文数据.例如, 文献[100,103] 表明攻击者可以获取OpenSSL 的ECDSA 密钥,AMD 也发布了密文侧信道攻击的防护措施[105,106].电压故障攻击会带来更加严重的后果, 攻击者可以(使用调试API) 解密虚拟机的加密内存, 获取用于远程证明的密钥; 文献[104] 给出了建议的防御方案.

4.2.3 SEV 功能扩展及相关应用

不同的TEE 提供了不同的安全抽象和安全特性, 并且与特定的硬件平台绑定.vSGX[107]以软件方式在AMD SEV 平台上模拟SGX 功能,从硬件层面解耦TEE,使得用户可以依据自己的需求更自由地选择可信执行环境.vSGX 的核心思想是使用SEV 保护的虚拟机模拟出运行SGX 应用程序的可信执行环境.受保护的虚拟机被称为Enclave VM (EVM), 运行不可信应用程序的虚拟机被称为App VM (AVM).EVM 提供vSGX 服务, AVM 只需要安装vSGX 内核就可以调用SGX 指令.

相比于vSGX, HyperEnclave[108]更彻底地使用软件方式构建TEE (vSGX 仍然需要SEV 硬件支持), 构建出的执行环境也被称为Enclave.HyperEnclave 使用虚拟化扩展保证Enclave 与外部隔离(适用于当前的主流CPU 架构, 例如x86 架构的AMD 和Intel CPU, 也可以扩展至ARM 架构).并且,HyperEnclave 基于TPM 芯片构建可信根, 使得可信根与CPU 厂商解绑.可选的内存加密依赖于平台硬件或是已有的软件方案; 例如, 在AMD 平台上可以使用SEV 的SME 功能为HyperEnclave 提供内存加密.

SEV 已经在工业界得到广泛应用.谷歌基于SEV 构建机密虚拟机[109], 使用一系列的隔离和沙箱技术作为云计算基础架构的一部分, 并通过机密虚拟机的内存加密功能提高安全性.微软Azure 机密计算平台[57]也提供了受SEV 保护的虚拟机, 保护租户数据, 并支持已有系统的直接迁移.

4.3 ARM TrustZone 密码技术应用

4.3.1 TrustZone 基础功能

TrustZone[110]是ARM 处理器的硬件扩展, 它创建了两个相互隔离的、物理机抽象的运行环境, 分别称为普通世界(normal world) 和安全世界(secure world), 普通世界无法访问安全世界的资源, 包括内存区域和外设中断.在初始设计中, 安全世界和普通世界均有三个特权级.普通世界的特权级包括EL0、EL1 和EL2, 用户态应用程序运行在EL0 层, 操作系统运行在EL1 层, Hypervisor 运行在EL2 层.安全世界的特权级分为s-EL0、s-EL1 和s-EL3, 可信应用程序(trusted application, TA) 运行在s-EL0 层,TEE 操作系统内核运行在s-EL1 层.安全监视器Secure Monitor 运行在s-EL3 层, 负责安全世界与普通世界的切换.在ARMv8.4 架构之后, 安全世界新增s-EL2 特权级, 用以支持安全世界的虚拟化.

4.3.2 TrustZone 安全世界虚拟化功能扩展

在ARMv8.4 支持s-EL2 之前, 实现安全世界的虚拟化系统[111–113]面临技术挑战.vTZ[111]将多个虚拟机运行在宿主机的普通世界中, 每一个虚拟机包括一个虚拟的普通世界和一个虚拟的安全世界.vTZ 使用宿主机安全世界的Secured Memory Mapping 对多个虚拟机的安全世界实施隔离.宿主机的安全世界运行Secured World Switching (SWS): 当虚拟机有世界切换时, SWS 拦截和检查CPU 状态.TEEv[112]在安全世界中实现了轻量级的Hypervisor, 称为TEE-visor, 以管理安全世界中虚拟出的多个隔离TEE.TEE-visor 与TEE 操作系统内核运行在相同特权级.

在s-EL2 之后, 可以利用s-EL2 特权级实现依赖于硬件特性的安全世界Hypervisor[114,115].Twin-Visor[114]实现了双Hypervisor 系统, 解耦了安全世界虚拟机的资源管理和保护机制: 普通世界的Hypervisor (称为N-visor) 负责资源管理, 安全世界的s-EL2 特权级小型Hypervisor (称为S-visor) 监控N-visor 的行为, 保护运行在安全世界的虚拟机.

4.3.3 基于软件内存加密的TrustZone 安全特性增强

TrustZone 提供隔离功能, 主要防范来自普通世界的特权攻击, 缺少内存加密功能, 也没有专门考虑物理攻击.有公开研究工作实现了软件内存加密, 将TrustZone 安全世界的密码计算限定在不同的SoC 环境, 以防范物理攻击和软件攻击, 包括限定在CPU 寄存器[116–119]、CPU Cache[120–123]以及片内内存(on-chip memory, OCM)[18,19,124–127]等.安全世界的内存敏感数据处于SoC 执行环境时以明文形式工作, 脱离SoC 执行环境时被加密.

Pager 是OP-TEE[127]内核的安全内存分页系统, 负责OP-TEE 内核其他组件和TA 的内存管理.它将OCM 设置为OP-TEE 系统的工作内存, 将DRAM 用作备份存储区.Pager 在OCM 上运行,OP-TEE 内核的其他组件和TA 的内存数据被加密后存储在DRAM 中.Pager 管理OCM 和DRAM之间的交换: 当需要使用存储在DRAM 中的数据时, Pager 解密相应内存页并执行完整性检查, 然后加载到OCM 中; 当OCM 中的内存页交换到DRAM 时, Pager 对其加密.CaSE[123]使用CPU Cache 构造SoC 执行环境: 被保护程序的代码、数据、堆栈都分配到片内Cache 中, 在片外内存中则以密文形式出现;当应用程序运行时, CaSE 将加密的应用程序加载到L2 Cache 中, 在Cache 内部验证和解密, 然后运行.

苹果也在SoC 上集成了专用安全子系统, 被称为安全飞地(secure enclave)[128].但是, 苹果的安全飞地与主处理器独立.安全飞地提供了内存保护引擎, 对于写入到安全飞地专用内存的数据, 内存保护引擎进行加密和认证.支持安全飞地的苹果设备还配有AES 引擎, 用以实现高速的文件加密.

4.3.4 基于TrustZone 实现安全密码系统

TrustOTP[129]在TrustZone 安全世界中实现了一次性口令OTP (one time password) 功能.TrustOTP 将OTP 和初始密钥的输入输出访问都限定在安全世界, 从而与运行在普通世界的Rich OS 隔离.TrustOTP 确保在Rich OS 出错、崩溃的情况下, OTP 仍然可用.TrustOTP 的代码镜像存储在只能从安全世界访问的非易失性存储器中, Rich OS 无法修改或删除.每当需要OTP 时, 用户可以触发硬件不可屏蔽中断将系统切换到安全世界, 然后输出OTP.

三星Galaxy S8、S9、S10、S20 和S21 设备在TrustZone 安全世界中实现了密钥管理和密码计算,通过硬件抽象层提供密码服务, 并向普通世界的应用程序提供密钥生成、密码计算(加密和签名等)、密钥存储等功能接口.当普通世界的应用程序请求生成密钥时, 运行在TrustZone 安全世界中的可信应用程序Keymaster TA 生成密钥并使用硬件AES 密钥进行封装, 然后将封装后的密钥返回给应用程序.在设计上, 应用程序只能保存封装后的密钥, 无法获取密钥明文; 但是, 上述系统实现存在缺陷, 有降级攻击和针对AES-GCM 工作模式的IV 重用攻击[130].

4.4 其他可信执行环境

以下简要介绍其他可信执行环境TEE, 基于密码技术的功能在其中发挥了重要作用.

4.4.1 RISC-V KeyStone

RISC-V 是开源的CPU 指令集架构, 定义了不同的特权模式: 运行用户进程的User-mode、运行OS 内核的Supervisor-mode 和直接访问物理资源的Machine-mode.目前, 已有多个RISC-V 架构的TEE 方案, 例如KeyStone[131]、Sanctum[132]和TIMBER-V[133]等.KeyStone 在Machine 层设计了Secure Monitor.Secure Monitor 使用物理内存保护(physical memory protection, PMP),构建了隔离的运行环境Enclave.每个Enclave 包括运行在User-mode 层的Enclave 应用程序(称为eapp) 和运行在Supervisor-mode 层的运行时RT.RT 提供系统调用接口、管理Enclave 的虚拟内存等, 为eapp 提供所需服务.KeyStone 可以支持多种插件, 包括内存加密[134]和完整性保护[89]插件, 用来保护离开Enclave的内存页.KeyStone 也实现了多种TEE 安全原语, 包括可信启动、随机数、可信计时器、远程证明、单调计数器和数据密封存储等.

4.4.2 Intel TDX

在SGX 之外,Intel 近年推出了新的TEE,称为信任域扩展TDX(trust domain extensions)[135].与AMD SEV 类似, TDX 提供了安全虚拟机抽象, 保留Hypervisor 的管理能力, 但是限制Hypervisor 访问虚拟机敏感数据的能力.Intel TDX 可以部署被称为TD (trust domain) 的、相互隔离的虚拟机.TDX为TD 虚拟机提供了内存加密和完整性保护、CPU 状态加密和完整性保护、远程证明、地址转换完整性保护、安全的中断和异常传递等特性.TD 虚拟机与Hypervisor 以及其他非TD 软件隔离, 免受软件攻击以及物理攻击的威胁.

Intel TDX 引入称为SEAM (secure-arbitration mode) 的CPU 模式, SEAM 外部的软件无法访问其内部数据, TDX Module 运行在SEAMRR (SEAM-range register) 标识的保留内存空间中.TDX Module 相当于不受Hypervisor 控制的可信中介, 帮助管理TD 虚拟机, Hypervisor 通过SEAMCALL调用TDX Module.TD 的内存加密建立在MKTME (multi-key total memory encryption) 基础上.在设备启动时, CPU 生成128-bit 临时密钥, 对物理内存进行AES-XTS 透明加密.MKTME 给不同的TD虚拟机分配不同的密钥, 软件或处理器接口无法访问密钥.每当TD 虚拟机创建时, Hypervisor 会划分出独立的一组内存页用于虚拟机控制结构、TD 的状态保存区域等.TDX Module 使用给TD 分配的密钥为相应的CPU 状态信息提供机密性和完整性保护.

4.4.3 ARM CCA

ARM 推出的安全虚拟机抽象 TEE 称为机密计算架构 CCA (confidential compute architecture)[136].CCA 同样保留原有Hypervisor 的管理能力, 但是限制Hypervisor 访问虚拟机敏感数据的能力.CCA 可以创建受保护的虚拟机运行空间, 被称为Realm, 引入了相应的CPU 硬件扩展RME(realm management extension) 和固件RMM (realm management monitor).RME 提供Realm 虚拟机运行所需的隔离环境, RMM 与Hypervisor 通信, 管理Hypervisor 的Realm 创建和运行请求.除了虚拟机隔离, CCA 也提供了远程证明机制.

在ARMv8 架构中, TrustZone 区分了普通世界和安全世界.ARMv9 进一步引入Realm 世界和Root 世界.Realm 世界与安全世界类似, 也有三个特权级, 分别是R-EL0、R-EL1 和R-EL2.Realm 虚拟机运行在R-EL0 和R-EL1 层, RMM 运行在R-EL2 层.另有Monitor 运行在Root 世界的EL3 层,保证不同世界的隔离, 并在必要时提供不同世界之间的通信.

4.4.4 国产CPU 的TEE 方案

海光CSV[137](China secure virtualization) 是x86 架构国产Hygon CPU 的硬件TEE 方案, 提供了安全虚拟机抽象.CSV1 使用SM4 算法加密虚拟机内存以实现不同虚拟机之间、虚拟机和Hypervisor之间的隔离; 不同虚拟机使用不同密钥.CSV2 增加了虚拟机状态加密, CSV3 增加了内存完整性保护.除了内存机密性和完整性保护, 海光CSV 也提供了可信启动、远程证明等功能.

鲲鹏TrustZone[138]是ARM 架构国产鲲鹏CPU 的TrustZone 技术.鲲鹏TrustZone 提供了物理机抽象, 划分出两个独立的运行环境, 分别为安全世界和普通世界, 实现了不同世界中的硬件和资源的隔离.此外, 鲲鹏TrustZone 还实现了远程证明功能, 这是ARMv8 TrustZone 不具备的.

4.4.5 异构计算单元TEE

为满足日益增长的多样化计算需求, 许多计算机系统配置了异构计算单元, 例如GPU、NPU 等加速器.但是, 大多数异构计算单元在设计时没有考虑安全性, 使得攻击者可以获取其内部的敏感数据.一些研究工作针对异构计算单元构建TEE 方案.针对服务器GPU, Graviton[139]通过改进GPU 上的指令处理器来保护GPU 内存数据.HIX[140]使用SGX Enclave 保护GPU 驱动程序及计算.工业界也推出了H100 GPU[141], 内置安全特性, 同时兼顾GPU 计算的机密性和性能.针对终端设备的GPU,StrongBox[142]利用ARM TrustZone 解决了共享内存GPU 面临的安全问题.此外, 也有研究工作针对通用加速器[143]、DNN 加速器[144]和NPU[145]构建TEE 方案, 更详细的内容可参考文献[146].

5 总结与展望

在传统应用场景上, 密码技术主要是用于传输安全和存储安全, 而虚拟化是典型的计算机系统技术方向, 虚拟化与密码技术应用的结合研究是为了实现普适通用的计算安全(既包括应用程序的计算, 也包括密码系统的计算).前文总结了二者结合研究的多个方面, 本文也展望未来可能的相关研究方向.首先,CPU 硬件TEE 的攻防研究.一方面, 各种功能复杂全面的TEE 特性可能存在安全漏洞, 会导致TEE特性的密码保护功能失效, 甚至泄露密钥; 运行在TEE 环境的程序也有可能因为侧信道攻击或者硬件漏洞而泄露重要敏感数据.相应的防御方案更是值得关注的研究重点.随着Intel TDX、ARM CCA 和RISC-V KeyStone 等推出和应用, 这一方面的研究值得持续关注.另一方面, 由于不同厂商、不同体系架构的TEE 特性不一致, 结合软件解决方案、“补齐” 安全特性的研究, 有利于TEE 技术的推广.

其次, 将更多的密码技术应用到虚拟的隔离运行环境, 不论是以软件解决方案还是CPU 硬件特性的形式, 都是非常有意义的尝试.很多时候, 是先有软件解决方案、仿真形式的研究, 完成初步探索, 然后是CPU 厂商的硬件实现.对于计算机系统资源管控的各种关键数据和配置, 以及存储外设和通信外设的相关数据, 未来应该实施更全面的机密性和完整性保护, 并且考虑动态性和更细粒度的安全保护.

再次, 随着计算机系统技术的发展, 出现了更多新型的虚拟隔离运行环境, 例如Docker 容器、浏览器的网站隔离、移动终端超级APP 运行的Mini-APP 等.各种异构计算单元, GPU、NPU 等, 也需要虚拟的隔离运行环境.这些新型虚拟隔离运行环境的安全需求有所差异, 在其中实施轻量级的、基于密码技术的安全方案, 有助于提升安全性.性能、兼容性和安全性的平衡, 将是其中的技术难点.

最后, 我们也应该更多借助虚拟运行环境的特性, 解决密码技术应用的相关问题.除了隔离特性和管控特性, 其他特性(例如, 远程证明、可信启动特性、外设数据密封、可信UI 界面等) 能够为普通应用程序带来有意义的安全价值, 也应该能够为密码技术的现实应用解决问题.