云环境下可信系统架构与虚拟证书链生成研究

Research on Trusted System Architecture and Virtual Certificate Chain in Cloud Environment

摘要: 本文提出了基于独立可信虚拟域(Domain Trusted, Domain T)的可信虚拟机系统架构，降低了现有系统中可信计算基(Trusted Computing Base, TCB)的大小，在保持Xen的Credit调度算法不变的情况下提高了vTPM (virtual TPM)计算性能。在此基础上，本文引入Domain T域身份密钥tEK，相比现有方法，在符合可信计算组织(Trusted Computing Group, TCG)主要规范的条件下生成了虚拟可信证书，为vTPM提供了信任根。最终测试结果表明，本系统在降低特权域TCB大小、提高vTPM计算性能的同时，提供了有效的客户虚拟机证书生成和身份认证的能力。

Abstract: This paper proposed a trusted virtual machine system architecture based on independent Domain T, reduced the TCB size of existing systems, and increased vTPM computing performance with Xen’s Credit scheduling algorithm unchanged. On this basis, by introducing the identity key of Domain T, it generated virtual trusted certificate under TCG main specifications, and provided a trusted root for vTPM. Finally, the test results show that the system reduces TCB size of Domain 0, improves vTPM computing performance, and provides client virtual machines with the capability of certificate generation and identity authentication.

1. 引言

云计算是互联网时代一种备受关注的计算服务方式 [1] ，它通过虚拟化系统将计算资源虚拟化后供用户按需调用。然而，不同用户的虚拟资源可能被绑定到相同的物理资源上，不同的虚拟机可能会访问相同的物理设备 [2] 。此外，用户将计算任务委托给云服务商，也就失去了对计算环境和隐私数据的控制权。因此，云计算必须提供有效的安全措施，增强平台可靠性，降低安全风险。

可信计算作为保证系统安全的一项重要技术，通过可信平台模块(Trusted Platform Module, TPM)来保障计算机系统的完整性，极大地提高了操作系统的抗攻击能力 [3] 。目前，应用于云环境下的TPM的虚拟化方案主要包括TPM硬件环境扩展 [4] ，TPM的半虚拟化 [5] ，以及软件式的TPM虚拟化。其中，TPM硬件环境扩展方案通过扩展TPM上下文为客户虚拟机提供专用的TPM环境，但需要TPM硬件支持；TPM半虚拟化方案通过一个软件TPM访问中间层来控制TPM调度及TPM对虚拟机的认证，但需要更改部分设备接口。相比而言，软件式TPM虚拟化方案以软件的形式为虚拟机提供了接近于物理TPM的接口，被大多数应用所采用 [6] - [12] 。

以Xen为代表的云平台虚拟机监控系统通过软件式方案实现了虚拟TPM，为客户虚拟机提供了可信计算能力。TCB的大小是一个可信平台最重要的安全因素之一，然而Xen将vTPM及其管理器设计在特权域Domain 0当中，一方面特权域会由于集成过多功能而导致TCB过大，一旦遭受攻击将使得客户虚拟机系统无法正常工作；另一方面，可信计算的计算需求也会和特权域中的其他请求一起抢占vCPU时间片，影响vTPM运算性能。

此外，以软件式方案实现的虚拟TPM没有受硬件保护的信任根(Core Root of Trust for Measurement, CRTM)，无法证明其自身的可信性。现有的虚拟可信证书生成方法大都通过硬件TPM的AIK密钥签发vAIK证书，以TPM担保vTPM的可信性。然而根据TCG规范，AIK密钥不能对TPM外部数据进行加密。同时AIK密钥生命周期短，vAIK证书随时有可能随AIK密钥的失效而突然失效。

因此，针对云环境下虚拟机监控系统存在的问题，本文对Xen的虚拟可信平台系统架构进行了改进，独立出一个可信计算专用虚拟域Domain T。在此基础上，为进一步解决vTPM没有信任根无法生成vAIK证书链的问题，引入了Domain T的tEK域身份证书，使虚拟证书链的生成过程符合TCG相关规范要求。经过对上述方案的实现，本文可以构建起可信的虚拟云计算平台，并充分验证了系统的有效性。

2. 相关技术研究

2.1. 可信计算技术

可信平台模块TPM是可信计算平台的可信核心。根据TCG的主要规格概范，TPM中包含7种类型的密钥 [13] 。其中，背书密钥(Endorsement Key, EK)是TPM的唯一标识，为避免平台身份暴露，仅被用于数据解密，不可进行其他直接操作。身份认证密钥(Attestation Identity Key, AIK)由EK生成，是EK的代替，负责对TPM内部数据与状态信息进行签名。AIK是一种RSA非对称密钥，其私钥受TPM保护而不可迁移，公钥则作为证书通过可信第三方(Trusted Third Party, TTP)发布。

在TPM的虚拟化解决方案上，Strasser [14] 提出的软件式TPM模拟器实现了物理TPM的绝大部分功能，但无法虚拟出多个TPM供每个虚拟机专用，只能面向单个平台环境。Perez [9] 提出将一个物理TPM映射成多个vTPM，为每个虚拟机提供一个单独的信任根，同时为了使vTPM具备远程证明能力还进一步设计了vTPM证书链的构建方法，但没有做进一步实现。Stumpf [10] 提出的可信虚拟平台方案实现了vTPM和物理TPM的绑定，并利用AIK生成了vAIK证书链，但其构建过程不符合TCG对AIK的签名规范。

2.2. Xen虚拟化技术

Xen是一个基于开源Linux内核代码的虚拟化系统，它首先将Hypervisor载入到Ring 0，然后授权一个特权域Domain 0协助Hypervisor参与对其它非特权域Domain U的管理。Xen还采用了前后端分离的设备驱动结构，前端驱动位于Domain U，接收操作系统发出的I/O请求，经由设备通道转发到后端；后端驱动位于Domain 0，通过本地驱动访问真实设备，将前端请求交给物理硬件处理。

为实现虚拟域的可信启动，使不同虚拟域各自进行独立的可信计算，Xen为每一个虚拟域提供了单独的vTPM，由管理器vTPM manager统一分配管理。在Xen的vTPM架构中，vTPM实例与Domain U一一对应，提供与物理TPM相同的功能；vTPM manager是一个运行在Domain 0里的守护进程，通过执行vTPM的扩展命令实现vTPM实例的创建、迁移、删除；vTPM设备驱动对为虚拟域应用程序使用TPM功能提供接口，为vTPM manager与Xen及其他虚拟域的数据传输提供支持。

Xen中的vCPU调度基于优先级的信用值(credit)。Credit调度算法是一种公平共享的非抢占式调度算法 [15] ，各个客户虚拟机按比例决定各自占用的CPU时间片，并控制单客户虚拟机的最大占比上限。因此，包括Domain 0在内各虚拟域的vCPU时间片都是有限的。vTPM manager和vTPM隶属于Domain 0，在域内计算需求互相竞争的情况下，可信计算相关的计算资源将无法得到公平保障。

3. 基于Domain T的虚拟机系统架构

3.1. 可信系统架构设计

本文从降低特权域TCB大小以及提升vTPM运行效率角度出发，将vTPM manager和vTPM实例迁移到独立的可信虚拟域Domain T中，提出基于Domain T的可信虚拟机系统架构如图1所示。

其中，可信虚拟域Domain T在结构上主要包含vTPM manager和vTPM实例两部分，是负责vTPM实例创建与管理的专用域。这一架构设计的优势性在于，一方面Domain T只支持vTPM相关功能，代码精简，有效地降低了TCB大小；另一方面，在Credit调度算法下能够提供更加公平的vCPU时间片保障，显著地提升了vTPM的计算性能。此外，Domain T的出现也为下文vTPM信任根的构建提供了基础。

在可信虚拟域Domain T中，vTPM manager模块负责监听客户机系统对vTPM的热插拔请求，持久化地保存vTPM运行状态，与硬件TPM通信，以及创建和管理vTPM实例。当客户虚拟机在创建配置中

Figure 1. Xen trusted virtual machine system architecture based on Domain T

图1. 基于Domain T的Xen可信虚拟机系统架构

声明TPM参数时，vTPM manager会创建一个新的vTPM实例与客户虚拟机相对应。

vTPM实例模块负责处理客户机发来的可信计算请求。其中，部分需要与硬件TPM通信的请求会转发给vTPM manager统一处理，其余请求则通过仿真逻辑在vTPM内部计算后直接返回给客户机系统。

3.2. 关键技术实现

Xen的原有机制中，Domain U的vTPM前端驱动发出的命令由vTPM manager负责转发给与之关联的vTPM实例。当请求过多时，vTPM manager的处理能力就会成为限制vTPM和Domain U性能的瓶颈。本方案将这一流程优化，使Domain U中的vTPM前端驱动直接同Domain T中的vTPM后端驱动连接，省去了vTPM manager的转发环节。这一设计不仅保障了数据安全，也减轻了对vTPM manager的性能压力。

vTPM前后端驱动建立连接的基础是xend向XenStore分别写frontend和backend信息。XenStore中保存的frontend和backend信息如图2所示，vTPM manager监听着/local/domain/0/backend/vbd中的frontend键，vTPM前端驱动则监听着/local/domain/U/device/vbd中的backend键。当设备内容被写入到这两个位置后，两个监听的相关事件就会被触发。

由于每一个vTPM实例在监听vTPM前端驱动及与硬件TPM通信时都处于阻塞状态，为防止一个vTPM实例阻塞导致整个vTPM manager受到影响，本方案将vTPM实例独立地放在一个线程中运行，并将vTPM后端驱动放入vTPM实例线程中。在监听到XenBus热插入事件时，vTPM管理模块创建vTPM实例与前端驱动一一对应。vTPM线程创建完成后，初始化vTPM后端驱动模块并与Domain U中的vTPM前端驱动建立连接。vTPM后端驱动模块初始化流程伪代码如图3所示。

如图中伪代码所示，vTPM实例线程创建后，首先将XenStore中对应Domain U的后端驱动状态标记为XenbusStateInitWait，等待获取更多信息以连接前端。然后监听XenStore中backend/vtpm/domid/

Figure 2. “KEY-VALUE” structure preserved in XenStore

图2. XenStore中保存的“键-值”结构

Figure 3. Pseudocode of vTPM backend driver initializing process

图3. vTPM后端驱动初始化流程的伪代码

handle/frontend/state键值的变化，当前端驱动初始化完成时，state字段会变为XenbusStateConnected。接着，初始化后端驱动的配置信息，包括共享内存地址，授权引用信息等。最后将XenStore中后端驱动的状态改为XenbusStateConnected，标志着vTPM前后端驱动连接成功。

4. 基于tEK证书的虚拟可信证书生成方法

4.1. vTPM虚拟证书链扩展

由于vTPM中没有受硬件保护的CRTM，因此虚拟环境下也就不会有EK证书。当客户虚拟机进行远程证明时，vTPM所产生的vAIK无法证明自己与一个可信的vEK绑定，也无法证明自身的可信性。因此，必须建立从物理TPM到vTPM的证书链，将TPM的信任关系传递到vTPM上。

本文针对上文提出的可信系统架构引入Domain T域身份密钥tEK，建立起tEK-vEK-vAIK形式的证书链。在介绍证书链扩展方案前，首先对信任关系和可信证明的性质定义进行介绍：

定义1 信任关系：实体A信任B，记做 $ATrustB$ 。信任关系具有以下性质：

1) 自信任性： $ATrustA$ 。

2) 传递性： $ATrustB,BTrustC\Rightarrow ATrustC$ 。

定义2 可信证明：当实体B向挑战者提供的证明实体A信任B的证据 $Ev{i}_B$ ，能够满足A信任B的标准要求 $Trust{S}_{A,b}$ 时，可得 $ATrustB$ ，记做 $Ev{i}_{B}EquTrust{S}_{A,b}\Rightarrow ATrustB$ 。

对于证书链的构建方法，目前已有一些研究成果。文献 [10] 提出 $AIK-vAIK$ 形式的证书链方案，绕过 $vEK$ 直接由 $Cer{t}_{AIK}$ 签发 $Cer{t}_{vAIK}$ 。该方案首先利用 $AIK$ 对 $vAIK$ 公钥、物理TPM的PCR值、随机数 $nonce$ 及时间戳进行签名，在此本文用 $Sig{n}_{\left\{vAI{K}_{pub},PCR,nonce,time\right\}}^{AI{K}_{pri}}$ 表示，然后将签名数据与 $Cer{t}_{AIK}$ 一同构成 $Cer{t}_{vAIK}$ 。由于 $Cer{t}_{vAIK}$ 是由 $Cer{t}_{AIK}$ 签发，因此实现了 $CATrustCer{t}_{AIK},Cer{t}_{AIK}TrustCer{t}_{vAIK}\Rightarrow CATrustCer{t}_{vAIK}$ 的信任传递。然而根据TCG规范， $AI{K}_{pri}$ 不能用于对TPM外部数据签名。此外由于 $Cer{t}_{AIK}$ 生命周期短，每次验证后都应当重新生成 $Cer{t}_{AIK}$ ，导致 $Cer{t}_{vAIK}$ 随 $Cer{t}_{AIK}$ 的失效而失效。

针对 $AIK$ 不能对外部数据签名的规定，文献 [16] 提出一种新密钥 $SK\left(Signaturekey\right)$ ，通过 $Sig{n}_{S{K}_{pub}}^{AI{K}_{pub}}$ ， $Sig{n}_{vAI{K}_{pub}}^{S{K}_{pub}}$ 的方式形成 $AIK$ 与 $vAIK$ 的间接签名。然而，该方案依然存在 $$ 时效性差的问题。

为解决 $Cer{t}_{AIK}$ 时效性问题，文献 [17] 引入私钥生成中心(Private Key Generation, PKG)，提出利用环签名证明VM的可信性。首先云平台利用隐私认证中心(Privacy Certification Authority, CA)向PKG证明可信性，PKG产生部分环签名密钥发给云平台，云平台再将部分环签名发给vTPM manager，最后vTPM manager将签名分发给vTPM。然而该方案的问题在于vTPM中的vPCR不完全等同于TPM中的PCR，当挑战者发起验证时会因为PKG中存储的是云平台PCR值，与vPCR值不匹配而导致验证失败。

因此，为了规避 $Cer{t}_{AIK}$ 时生命周期短的特性，同时满足 $AI{K}_{pri}$ 对TPM内部数据签名的合规性要求，本文引入Domain T域身份密钥 $tEK$ 。CA首先通过验证Domain T的完整性向Domain T签发 $Cer{t}_{tEK}$ ，之后由Domain T签发 $Cer{t}_{vEK}$ ，进而保证 $Cer{t}_{vAIK}$ 的合法性。

CA签发 $Cer{t}_{tEK}$ 必须建立在 $CATrustDomT$ 的基础上。根据定义1的信任传递性特点，需要先证明 $CATrustTPM,TPMTrustDomT$ 。

$Ev{i}_{TPM}EquTrust{S}_{CA,TPM}\Rightarrow CATrustTPM$ 的过程是标准的 $$ 签发过程，在此不再赘述。接下来证明 $TPMTrustDomT$ 成立的条件是 $Trust{S}_{TPM,DomT}=\left\{DomT\in Xen,PCR\left[13\right]=SHA1\left(DomT\right)\right\}$ 。由于Domain T运行在Xen Hypervisor之上，本文将Domain T的度量包含在Xen的启动过程内，并将其摘要值扩展地写入PCR [13] 中，因此 $Ev{i}_{DomT}EquTrust{S}_{TPM,DomT}$ 。

至此， $CATrustTPM,TPMTrustDomT$ 的信任传递建立成立。

vTPM中 $Cer{t}_{vEK},Cer{t}_{vAIK}$ 生成的具体流程如下：

1) Domain T生成tEK密钥对，并向CA发送 $Cer{t}_{tEK}$ 请求。

2) CA向Domain T发送 $C{A}_{pub}$ 以及一个随机数 $nonce$ 。

3) Domain T利用该随机数 $nonce$ 向平台TPM发起远程挑战。

4) TPM使用 $AI{K}_{pri}$ 对物理PCR值、 $nonce$ 进行签名，将签名结果 $Sig{n}_{\left\{PCR,nonce\right\}}^{AI{K}_{pri}}$ 和 $Cer{t}_{AIK}$ 、度量日志一起返回给Domain T。

5) Domain T使用 $C{A}_{pub}$ 对 $tE{K}_{pub}$ 以及TPM发来的签名结果、 $Cer{t}_{AIK}$ 、度量日志进行签名，一起发给CA。

6) CA通过解密并比对TPM中PCR [13] 的值判断Domain T是否完整。若比对通过，则 $CA$ 向Domain T签发 $Cer{t}_{tEK}$ 。

7) 当Domain T产生新的vTPM时，vTPM 随机生成vEK密钥对，Domain T通过 $tE{K}_{pub}$ 签名 $vE{K}_{pub}$ ，配合 $Cer{t}_{tEK}$ 一起形成 $Cer{t}_{vEK}$ 。

8) 当vTPM申请 $Cer{t}_{vAIK}$ 时首先向Domain T发送 $Cer{t}_{vAIK}$ 请求，由Domain T返回一个 $tE{K}_{pub}$ 以及一个随机数 $nonce$ 。

9) vTPM随机生成vAIK密钥对，然后将 $vAI{K}_{pub}$ 、 $Cer{t}_{vEK}$ 和 $nonce$ 经 $tE{K}_{pub}$ 签名后发送给Domain T。

10) Domain T通过解密比对确认 $Cer{t}_{vEK}$ 有效后签发 $Cer{t}_{vAIK}$ 。

CA通过验证平台完整性即可验证Domain T的完整性，通过挑战平台完整性即可挑战 $Cer{t}_{tEK}$ 的有效性。这一过程不涉及AIK密钥对TPM外部数据的签名。 $Cer{t}_{vEK}$ 与 $Cer{t}_{vAIK}$ 由Domain T直接颁发，解决了 $Cer{t}_{vAIK}$ 与某一个 $Cer{t}_{AIK}$ 强绑定所导致的时效性差的问题。围绕 $Cer{t}_{vAIK}$ 的生成与签发，本文所提虚拟证书链构建方案与其他现有方法的优缺点对比如表1所示。

4.2. vTPM虚拟证书链实现

本文在Domain T的tEK证书申请过程中，采用Intel的OpenAttestation开源框架作为CA，通过在Domain T中新增GetCert命令人工地触发tEK证书申请流程。当Xen获得nonce随机数后，利用Tspi_Context_CreateObject函数构建一个PCR对象，利用Tspi_PcrComposite_SelectPcrIndex函数获取PCR [13] 的值，并利用Tspi_TPM_Quote (AIK, PCRIndex, nonce)函数生成平台状态信息，最后将平台信息发送给Domain T。同时，OpenAttestation通过修改源码实现了PCR值比对和tEK证书签发的功能。

此外，本文对vTPM实例中TPM Emulator的工作流程进行了修改，在TPM Emulator创建完成vEK公钥后，改为向Domain T中的CertListener进程发送vEK证书申请，vAIK证书申请也被重定向到CertListener中。CertListener向vTPM返回vAIK证书后，vTPM利用Tspi_Key_LoadKey函数加载vAIK证书进入vTPM，并利用Tspi_TPM_ActivateIdentity函数激活vAIK证书。

5. 基于Domain T的虚拟机系统测试

为验证vTPM虚拟证书链扩展的可用性，本文从虚拟平台的远程证明以及vTPM的计算性能两个维

Table 1. Comparison of approaches to generate vAIK certificate

表1. vAIK证书生成方法比较

度出发，进行了系统有效性测试。本章实验采用Ubuntu 12.4作为宿主机的操作系统，宿主机中安装了4.9版本的Xen系统，其中Domain 0内核是Linux 3.7.1版本，Domain U内核是3.7.9版本。此外，宿主机主板上搭载了一块Infineon v1.2TPM芯片，TSS软件栈采用Trousers。

通过将vTPM manager和vTPM实例迁出特权域，特权域源码大小降低了1.73 MB，占Xen源代码大小的10.9%。经过迁移后的Domain T架构能够满足可信虚拟机的正常运转要求。

5.1. 客户机系统远程证明测试

本节测试虚拟平台远程证明能力的有效性，主要包括tEK证书和vAIK证书的生成能力。

首先对tEK证书的生成时间进行测试。生成tEK证书的时间由两部分组成：CA验证AIK证书及Domain T完整性时间，以及验证完成后签发tEK证书时间。如表2所示，生成tEK证书平均用时约17.24秒。由于证书签发流程较长，所以tEK证书生成时间也比较长，但考虑到该证书只在每次平台启动时申请一次，因此还是具备一定的实用性。

其次对vAIK证书的生成时间进行测试。如4.1节所述，vAIK签发流程如下：

1) vTPM生成vAIK密钥对，并向Domain T发送vAIK证书请求。

2) Domain T返回tEK公钥以及随机数nonce。

3) vTPM向Domain T发送tEK公钥签名后的vAIK公钥、vEK证书和nonce随机数。

4) Domain T使用tEK私钥解密，在检查nonce新鲜度和vEK证书有效性后签发vAIK证书。

如表3所示，生成vAIK证书平均用时约5.47 s。这一时间相比tEK证书生成时间更短，这是因为该过程涉及证书都在本地签发，省去了和硬件TPM的通信过程。

5.2. vTPM性能测试

以上实验证明，本文所提Domain T架构以及tEK证书与vAIK证书的生成方案具备一定实用性。本节测试独立后的Domain T是否会对vTPM的计算性能产生影响。

在此本节对AIK-vAIK的证书生成方法进行了实现，在同等实验环境下测试在部署了Domain T和未

Table 2. tEK certificate generating time

表2. tEK证书生成时间

Table 3. vAIK certificate generating time

表3. vAIK证书生成时间

Table 4. vAIK certificate comparative generating time

表4. vAIK证书对比生成时间

部署Domain T的Xen环境中，客户虚拟机生成vAIK证书所用的时长。

如表4所示，对比实验表明，在基于Domain T架构的Xen系统中，生成vAIK证书平均用时约3.19 s；未采用Domain T架构的Xen系统中，生成vAIK证书平均用时约3.53 s。相比改进前，独立后的Domain T架构在只安装一个客户虚拟机Domain U的情况下，vAIK证书的请求速度可以提高约9.63%。

6. 结束语

本文以Xen系统为基础，提出了基于Domain T的可信虚拟机系统架构。通过迁出vTPM manager和vTPM实例降低了Domain 0的TCB大小，理论上可以保障Domain T的计算资源不被其他虚拟机的计算请求抢占，提高了vTPM性能。同时，本文的虚拟证书链生成方案通过引入Domain T域身份密钥tEK，解决了现有方法中用AIK签名TPM外部数据为vAIK证书背书的问题。最后，本文实现了相关原型系统，并验证了系统的有效性。