



第1章介绍了隐私计算,机密计算是隐私计算的一种方法。在本章中,我们将介绍机密计算的基础概念。需要说明的是,在本书中主要参考的是国际机密计算联盟(Confidential Computing Consortium,CCC)给出的定义。
根据机密计算联盟在“机密计算通用术语”(Common Terminology for Confidential Computing)白皮书中的定义,机密计算是指“ 在一个基于硬件、被证明的可信执行环境中进行计算以保护使用中的数据 ”。下面解释一下这个定义。如图2-1所示,数据分为三类:存储时的数据(Data at Rest)、传输中的数据(Data in Transit)和使用中的数据(Data in Use)。首先,机密计算的目的是保护 使用中的数据 。传输中的数据可以由网络安全传输协议保护,例如,安全传输层协议(TLS)、互联网安全协议(IPSec)、媒体访问控制安全(MACSec)等;存储时的数据可以由安全存储提供保护,例如,磁盘加密、文件加密、数据库访问控制等。其次,机密计算是基于硬件的,必须要有 特殊硬件支持 ,因为现有的普通硬件无法提供足够的保护,在计算执行过程中,代码和数据都是以明文的形式存在。机密计算需要基于硬件,这是由CCC对机密计算的定义得出的,但这并不代表只有基于硬件才能实现计算的机密性。例如,在第1章介绍的同态加密、安全多方计算、差分隐私等密码学方案也可以实现机密性,只是密码运算可能会带来性能损耗。使用一个类似虚拟机的高权限软件模块能够提供一个基于软件的机密方案,但这类纯软件方案无法抵御硬件物理攻击,我们将在第3章详细介绍机密计算的安全模型和威胁模型。最后,机密计算需要一个 可信执行环境 ,而且这个可信执行环境是 被证明的 (Attested)。
图2-1 数据的分类
针对机密计算,可信执行环境主要需要提供三类安全属性:
数据的机密性
(Confidentiality):未授权的实体不能在运行时读取TEE中的数据。
数据的完整性
(Integrity):未授权的实体不能在运行时添加、删除和篡改TEE中的数据。
代码的完整性
:未授权的实体不能在运行时添加、删除或篡改TEE中的代码。
不同的TEE可以提供其他的属性:
代码的机密性
:未授权的实体不能在运行时读取TEE中的代码。例如,如果使用者考虑到代码的知识产权,不想让其他人看到代码,哪怕是二进制代码,那么就需要TEE具有这个特性。如果执行的代码已经是开源代码,那么这个特性不是必需的。
认证的启动
(Authenticated Launch):某些TEE可以在启动时就对初始启动代码进行验证,例如签名校验。未知的启动代码会被TEE拒绝执行,这是认证的启动的优点。但是,认证的启动需要预先部署认证策略。以签名校验为例,需要部署签名实体的公钥,那么由谁来部署?怎么信任部署的公钥?如果公钥过期,或私钥被泄露,应如何更新部署?另外,签名校验需要考虑部署安全版本号(Security Version Number,SVN),以防回滚攻击(Rollback Attack)。例如,攻击者可以启用一份有已知安全漏洞的签名代码进行回滚攻击。由于认证策略部署的复杂性,这个特性并不是机密计算必需的。
可编程性
:有的TEE包含一份固定的代码来提供特定的功能,有的通用TEE可以让外部使用者加载任意代码。具体的情况由使用案例决定。
可证明性
(Attestability):TEE需要提供它自身代码和数据的来源以及当前的运行状态,这称为证据(Evidence),通常用代码和数据的度量值(Measurement)来表示。一个本地或者远程的验证者可以通过验证证据来判定这个TEE是不是可信的。由于证据需要在不安全的通道中传输,因此TEE硬件通常会提供密码学方案来保证证据的完整性,例如数字签名或消息认证码。
可恢复性
(Recoverability):有些TEE可以提供恢复机制。例如,在认证的启动过程中,如果一个模块发现签名校验失败,它可以自动加载一个已知的完好模块、自动更新,并重新加载。套用NIST SP800-193平台固件韧性恢复指南(Platform Firmware Resiliency Guidelines)的定义,在这类具有韧性恢复能力(Resiliency)的TEE中,通常需要定义各类可信根(Root-of-Trust,RoT)组件,包括检测可信根(Root-of-Trust for Detection,RTD)、更新可信根(Root-of-Trust for Update,RTU)和恢复可信根(Root-of-Trust for Recovery,RTRec)。
可证明性是国际可信计算联盟(Trusted Computing Group,TCG)提出的可信计算(Trusted Computing)的一个基本要求,核心思想是允许验证者验证一个系统上运行的程序确实是期望运行的。需要特别强调的是, 可证明性 是非常重要的特性。如果一个TEE无法提供可证明性,它就不能被称为机密计算的TEE。原因是如果没有可证明性,那么机密计算的使用者就无法知道TEE中数据和代码的真实来源,一份未知代码可能会导致数据泄露,那么机密性就无从谈起。我们将在第5章详细讨论可信计算以及TEE的证明模型。
注意 我们一般说TEE是一个 可信 (Trusted)的环境,但不代表TEE是 安全 (Secure)的环境。TEE的可证明性只是提供了代码和数据原始出处的证明,从而表明代码和数据是可信的。但是,TEE的可证明性不能证明代码没有任何安全漏洞,例如代码是否存在缓冲区溢出漏洞、侧信道脆弱性等。机密计算只能保证代码的完整性不会在运行时被恶意破坏,并向验证者提供证明。代码本身的安全性还是需要代码的提供者来保证。
在2023年OC3大会上,Schuster在主题演讲“Welcome Keynote and Introduction to Confidential Compating”中介绍了机密计算想要解决的问题、工作负载安全需求和机密计算中TEE的属性(如图2-2所示)。其中,TEE属性包括以下方面:
隔离
(Isolation):一个TEE必须和非TEE隔离,也要和其他TEE隔离。
运行时内存加密
(Runtime Memory Encryption):一个TEE必须对内存进行运行时加密,防止针对内存的线下攻击。
远程证明
(Remote Attestation):一个TEE必须要提供远程证明能力,以向第三方证明环境是被可信地建立起来的。
相信读者对第一项不会有任何异议,第三项的重要性之前已经阐述过。这里重点讨论第二项。运行时内存加密是机密计算引入的新的需求。目前,业界有些TEE只提供执行环境隔离,但是不提供运行时内存加密,例如ARM TrustZone。严格来说,ARM TrustZone并不算机密计算技术,所以ARMv9提出了机密计算架构(Confidential Compute Architecture,CCA)。但是,Open Enclave SDK还是对ARM TrustZone提供了支持。基于RISC-V的Key Stone方案只提供隔离功能,而把运行时内存加密作为可选项,可以由运行时软件完成或由独立的内存加密引擎(Memory Encryption Engine,MEE)完成。用户选择方案时要根据项目需求来确定。
图2-2 机密计算的安全需求和TEE属性
冯登国院士在2021年中国计算机大会上做了“从可信计算到机密计算”的报告,比较了可信计算与机密计算,如表2-1所示。
表2-1 可信计算与机密计算比较
机密计算和可信计算的本质区别在于要解决的安全问题不同。可信计算出现在21世纪初期,2003年成立的可信计算联盟致力于解决 系统平台的可信问题 ,依赖于一个硬件可信平台模块(Trusted Platform Module,TPM),生产商或用户可以决定在本地机器上允许运行哪些软件,可信计算并没有特别关注数据隐私。机密计算是21世纪20年代前后出现的技术,2019年成立的机密计算联盟致力于定义和加速机密计算的发展以及在工业界的采用,机密计算的核心目的是解决 使用中的数据安全问题 ,保护数据不被泄露,作为传输中的数据安全和存储时的数据安全的补充;同时,机密计算提供了 数据隐私保护 ,满足了目前日益增长的隐私需求。
根据机密计算联盟的定义,可以把现有的机密计算中的硬件TEE方案分为以下几类:
安全飞地
(Secure Enclave):借助CPU硬件的特性,用户可以创建一个飞地(Enclave)作为TEE。飞地在机密计算中指的是一个完全隔离的运行环境。在飞地中执行的代码和数据受到保护,与飞地外或其他飞地保持隔离。通常情况下,飞地是应用程序级别,如图2-3所示。例如,基于Intel软件保护扩展(Software Guard Extensions,SGX)创建的飞地称为SGX Enclave。
机密虚拟机
(Confidential Virtual Machine,CVM):用户可以创建一个完整的虚拟机作为TEE,如图2-4所示。例如,Intel可信域扩展(Trust Domain Extensions,TDX)、AMD安全加密虚拟化(Secure Encrypted Virtualization,SEV)、ARM机密计算架构(Confidential Compute Architecture,CCA)的机密领域管理扩展(Realm Management Extension,RME)、RISC-V机密虚拟机扩展(Confidential VM Extension,CoVE)采用的都是机密虚拟机方案。采用这种方案的原因是机密虚拟机可以为已有的应用程序提供最大的兼容性,只需对操作系统进行修改即可为应用程序提供机密计算的支持。
机密设备加速器
(Confidential Accelerator):在现有的用例中,有些应用依赖于硬件加速功能,例如,利用GPU进行AI计算加速。如果主机端的TEE需要硬件加速,那么在设备端就需要提供机密设备加速功能,如图2-5所示。例如,NVIDIA Hopper H100提供了基于机密设备的机密计算方案。
图2-3 安全飞地
图2-4 机密虚拟机
图2-5 机密设备加速器
最后,还有一种完全 隔离TEE (Isolated TEE)。例如,ARM TrustZone、RISC-V KeyStone、RISC-V MultiZone和RISC-V Penglai TEE等。图2-6给出了隔离TEE的示意图。从广义上看,还有一类安全处理器(Secure Processor)或安全芯片(Security Chip)也可以归入隔离TEE,例如Apple的T2安全芯片、Google的Titan M2安全芯片、Amazon的Nitro安全芯片以及TCG定义的可信计算模块(Trusted Platform Module,TPM)等。但是,这种安全芯片TEE只能运行厂商的特定程序,而不能完全开放给最终用户,在本书中不会讨论这类TEE。
图2-6 隔离TEE
这里有一个隐含的假设,那就是平台CPU的片上系统(System-On-Chip,SoC)自带内存控制器(Memory Controller,MC),或者CPU-SoC和MC的连接是可信的,不会受到攻击。我们可以让MC进行内存加密的动作,而不用相信DRAM。但是,如果MC在SoC外部,SoC与MC的连接不可信,那么就需要一种机制让MC变得可信,如图2-7所示。
图2-7 TEE和外部MC
我们将在第二部分讨论安全飞地和机密虚拟机方案,在第三部分讨论机密设备加速器方案。
机密计算联盟在“机密计算通用术语”白皮书中提出了软件打包模型(Packaging Model),即软件以什么样的形式在可信执行环境中运行,分为以下几类:
机密库
(Confidential Library):一个程序库,例如Enclave在TEE中执行。这个TEE中的程序为TEE外的应用提供服务。
机密进程
(Confidential Process):一个进程,例如可信应用(Trusted Application)在TEE中执行。
机密容器
(Confidential Container):一个符合开放容器标准(Open Container Initiative,OCI)的容器镜像(Container Image)在TEE中执行。
机密虚拟机
:一个虚拟机在TEE中执行。
无论哪种类型,TEE的目的都是保护在主机环境中执行的部分代码和数据,把它们和非TEE以及其他TEE中的代码和数据隔离开来。这些软件可以由硬件厂商提供,也可以由第三方软件厂商提供,例如由操作系统厂商(OSV)、云服务提供商(CSP)等提供。
需要注意的是,机密计算的软件打包模型并不一定要和硬件TEE分类一一对应。例如,机密虚拟机打包模型软件可以使用基于机密虚拟机的TEE,也可以使用安全飞地TEE。
目前,在机密计算联盟(CCC)中注册的机密计算项目有:Occlum和Gramine使用的是library OS方案,它们可以帮助开发者把已有的应用打包变成SGX机密库。Enarx提供了基于Web Assembly的运行时TEE,允许开发者部署已有的各种语言的应用,例如Rust、C/C++、C#、GO、Java、Python等。Enarx支持SGX机密库和SEV机密虚机AMD。Open Enclave SDK帮助构建基于TEE的应用,支持SGX机密库和TrustZone机密进程。
随着人工智能(AI)的迅速发展,安全问题特别是隐私问题备受关注,机密计算可以为机器学习提供机密性和完整性保护。Mo、Tarkhani和Haddadi在2024年发表的“Machine learning with confidential computing: a systematization of knowledge”一文中对机密计算辅助下的机器学习做了系统介绍。服务端中心化机器学习提供训练服务(Training as a Service,TaaS)和推理服务(Inference as a Service,IaaS),使用TEE可以保护部署的数据的隐私性和模型的知识产权。客户端的分布式机器学习提供设备端上推理(On-Device Inference,ODI)和设备端上个人化(On-Device Personalization,ODP),并作为联邦学习全局模型(Global Model)的提供方之一,使用TEE可以保护其部署的模型的知识产权。TEE在机器学习中的应用如图2-8所示。
图2-8 TEE在机器学习中的应用
由于额外的加密,引入机密计算可能会导致AI性能损失。IBM在IEEE Cloud 2024上发表了“Securing AI inference in the cloud: is CPU-GPU confidential computing ready?”一文,研究了使用Intel TDX系统和NVIDIA H100 GPU进行AI推理的性能。由于尚未采用TEE-IO硬件加密架构,CPU-GPU之间的通信只能采用软件加密的方式,这是一个性能瓶颈。研究表明,采用流水线处理(Pipelined Processing)可以缓解IO瓶颈,使用CPU-GPU TEE中的大语言模型(Large Language Model,LLM),推理的性能可以和非机密计算场景接近。