本文提出了基于独立可信虚拟域(Domain Trusted, Domain T)的可信虚拟机系统架构,降低了现有系统中可信计算基(Trusted Computing Base, TCB)的大小,在保持Xen的Credit调度算法不变的情况下提高了vTPM (virtual TPM)计算性能。在此基础上,本文引入Domain T域身份密钥tEK,相比现有方法,在符合可信计算组织(Trusted Computing Group, TCG)主要规范的条件下生成了虚拟可信证书,为vTPM提供了信任根。最终测试结果表明,本系统在降低特权域TCB大小、提高vTPM计算性能的同时,提供了有效的客户虚拟机证书生成和身份认证的能力。 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,2,郭一清1,2,陈建中1,2
1北京工业大学计算机学院,北京
2可信计算北京市重点实验室,北京
收稿日期:2018年5月2日;录用日期:2018年5月22日;发布日期:2018年5月29日
本文提出了基于独立可信虚拟域(Domain Trusted, Domain T)的可信虚拟机系统架构,降低了现有系统中可信计算基(Trusted Computing Base, TCB)的大小,在保持Xen的Credit调度算法不变的情况下提高了vTPM (virtual TPM)计算性能。在此基础上,本文引入Domain T域身份密钥tEK,相比现有方法,在符合可信计算组织(Trusted Computing Group, TCG)主要规范的条件下生成了虚拟可信证书,为vTPM提供了信任根。最终测试结果表明,本系统在降低特权域TCB大小、提高vTPM计算性能的同时,提供了有效的客户虚拟机证书生成和身份认证的能力。
关键词 :可信平台模块,可信虚拟域,TPM证书,虚拟证书链
Copyright © 2018 by authors and Hans Publishers Inc.
This work is licensed under the Creative Commons Attribution International License (CC BY).
http://creativecommons.org/licenses/by/4.0/
云计算是互联网时代一种备受关注的计算服务方式 [
可信计算作为保证系统安全的一项重要技术,通过可信平台模块(Trusted Platform Module, TPM)来保障计算机系统的完整性,极大地提高了操作系统的抗攻击能力 [
以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相关规范要求。经过对上述方案的实现,本文可以构建起可信的虚拟云计算平台,并充分验证了系统的有效性。
可信平台模块TPM是可信计算平台的可信核心。根据TCG的主要规格概范,TPM中包含7种类型的密钥 [
在TPM的虚拟化解决方案上,Strasser [
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调度算法是一种公平共享的非抢占式调度算法 [
本文从降低特权域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实例。当客户虚拟机在创建配置中
图1. 基于Domain T的Xen可信虚拟机系统架构
声明TPM参数时,vTPM manager会创建一个新的vTPM实例与客户虚拟机相对应。
vTPM实例模块负责处理客户机发来的可信计算请求。其中,部分需要与硬件TPM通信的请求会转发给vTPM manager统一处理,其余请求则通过仿真逻辑在vTPM内部计算后直接返回给客户机系统。
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/
图2. XenStore中保存的“键-值”结构
图3. vTPM后端驱动初始化流程的伪代码
handle/frontend/state键值的变化,当前端驱动初始化完成时,state字段会变为XenbusStateConnected。接着,初始化后端驱动的配置信息,包括共享内存地址,授权引用信息等。最后将XenStore中后端驱动的状态改为XenbusStateConnected,标志着vTPM前后端驱动连接成功。
由于vTPM中没有受硬件保护的CRTM,因此虚拟环境下也就不会有EK证书。当客户虚拟机进行远程证明时,vTPM所产生的vAIK无法证明自己与一个可信的vEK绑定,也无法证明自身的可信性。因此,必须建立从物理TPM到vTPM的证书链,将TPM的信任关系传递到vTPM上。
本文针对上文提出的可信系统架构引入Domain T域身份密钥tEK,建立起tEK-vEK-vAIK形式的证书链。在介绍证书链扩展方案前,首先对信任关系和可信证明的性质定义进行介绍:
定义1 信任关系:实体A信任B,记做 A T r u s t B 。信任关系具有以下性质:
1) 自信任性: A T r u s t A 。
2) 传递性: A T r u s t B , B T r u s t C ⇒ A T r u s t C 。
定义2 可信证明:当实体B向挑战者提供的证明实体A信任B的证据 E v i B ,能够满足A信任B的标准要求 T r u s t S A , b 时,可得 A T r u s t B ,记做 E v i B E q u T r u s t S A , b ⇒ A T r u s t B 。
对于证书链的构建方法,目前已有一些研究成果。文献 [
针对 A I K 不能对外部数据签名的规定,文献 [
为解决 C e r t A I K 时效性问题,文献 [
因此,为了规避 C e r t A I K 时生命周期短的特性,同时满足 A I K p r i 对TPM内部数据签名的合规性要求,本文引入Domain T域身份密钥 t E K 。CA首先通过验证Domain T的完整性向Domain T签发 C e r t t E K ,之后由Domain T签发 C e r t v E K ,进而保证 C e r t v A I K 的合法性。
CA签发 C e r t t E K 必须建立在 C A T r u s t D o m T 的基础上。根据定义1的信任传递性特点,需要先证明 C A T r u s t T P M , T P M T r u s t D o m T 。
E v i T P M E q u T r u s t S C A , T P M ⇒ C A T r u s t T P M 的过程是标准的 签发过程,在此不再赘述。接下来证明 T P M T r u s t D o m T 成立的条件是 T r u s t S T P M , D o m T = { D o m T ∈ X e n , P C R [ 13 ] = S H A 1 ( D o m T ) } 。由于Domain T运行在Xen Hypervisor之上,本文将Domain T的度量包含在Xen的启动过程内,并将其摘要值扩展地写入PCR [
至此, C A T r u s t T P M , T P M T r u s t D o m T 的信任传递建立成立。
vTPM中 C e r t v E K , C e r t v A I K 生成的具体流程如下:
1) Domain T生成tEK密钥对,并向CA发送 C e r t t E K 请求。
2) CA向Domain T发送 C A p u b 以及一个随机数 n o n c e 。
3) Domain T利用该随机数 n o n c e 向平台TPM发起远程挑战。
4) TPM使用 A I K p r i 对物理PCR值、 n o n c e 进行签名,将签名结果 S i g n { P C R , n o n c e } A I K p r i 和 C e r t A I K 、度量日志一起返回给Domain T。
5) Domain T使用 C A p u b 对 t E K p u b 以及TPM发来的签名结果、 C e r t A I K 、度量日志进行签名,一起发给CA。
6) CA通过解密并比对TPM中PCR [
7) 当Domain T产生新的vTPM时,vTPM 随机生成vEK密钥对,Domain T通过 t E K p u b 签名 v E K p u b ,配合 C e r t t E K 一起形成 C e r t v E K 。
8) 当vTPM申请 C e r t v A I K 时首先向Domain T发送 C e r t v A I K 请求,由Domain T返回一个 t E K p u b 以及一个随机数 n o n c e 。
9) vTPM随机生成vAIK密钥对,然后将 v A I K p u b 、 C e r t v E K 和 n o n c e 经 t E K p u b 签名后发送给Domain T。
10) Domain T通过解密比对确认 C e r t v E K 有效后签发 C e r t v A I K 。
CA通过验证平台完整性即可验证Domain T的完整性,通过挑战平台完整性即可挑战 C e r t t E K 的有效性。这一过程不涉及AIK密钥对TPM外部数据的签名。 C e r t v E K 与 C e r t v A I K 由Domain T直接颁发,解决了 C e r t v A I K 与某一个 C e r t A I K 强绑定所导致的时效性差的问题。围绕 C e r t v A I K 的生成与签发,本文所提虚拟证书链构建方案与其他现有方法的优缺点对比如表1所示。
本文在Domain T的tEK证书申请过程中,采用Intel的OpenAttestation开源框架作为CA,通过在Domain T中新增GetCert命令人工地触发tEK证书申请流程。当Xen获得nonce随机数后,利用Tspi_Context_CreateObject函数构建一个PCR对象,利用Tspi_PcrComposite_SelectPcrIndex函数获取PCR [
此外,本文对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证书。
为验证vTPM虚拟证书链扩展的可用性,本文从虚拟平台的远程证明以及vTPM的计算性能两个维
需求对比 | AIK签名vAIK证书法 | SK签名vAIK证书法 | 环签名法 | tEK签名vEK证书法 |
---|---|---|---|---|
是否需要TTP参与 | 不需要 | 不需要 | 需要CA和PKG参与 | 需要CA和Domain T参与 |
CA如何验证 vAIK证书 | 需要知道AIK公钥,并通过AIK公钥解密加密值后比对内容合法性 | 需要知道SK公钥,并通过AIK证书验证SK合法性后再验证内容合法性 | 通过环签名验证 等式进行验证 | 向Domain T验证 AIK证书合法性 |
能否满足VM 远程证明需求 | 可以 | 可以 | 不可以,vPCR值与PCR值不完全相同 | 可以 |
是否依赖AIK证书 | 依赖 | 依赖 | 不依赖 | 不依赖 |
vAIK证书请求是否依赖TPM支持 | 依赖 | 依赖 | 不依赖 | 不依赖 |
表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架构能够满足可信虚拟机的正常运转要求。
本节测试虚拟平台远程证明能力的有效性,主要包括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的通信过程。
以上实验证明,本文所提Domain T架构以及tEK证书与vAIK证书的生成方案具备一定实用性。本节测试独立后的Domain T是否会对vTPM的计算性能产生影响。
在此本节对AIK-vAIK的证书生成方法进行了实现,在同等实验环境下测试在部署了Domain T和未
实验组 | 验证AIK证书及Domain T完整性 | 签发tEK证书 | 合计 |
---|---|---|---|
1 | 9.13 | 8.36 | 17.49 |
2 | 9.07 | 8.35 | 17.42 |
3 | 8.59 | 8.10 | 16.69 |
4 | 9.03 | 8.31 | 17.34 |
表2. tEK证书生成时间
实验组 | 生成AIK密钥并发送请求 | 获取nonce | 返回tEK签名数据 | 签发tEK证书 | 合计 |
---|---|---|---|---|---|
1 | 0.87 | 0.15 | 3.54 | 1.02 | 5.58 |
2 | 0.83 | 0.11 | 3.28 | 1.15 | 5.37 |
3 | 0.87 | 0.13 | 3.38 | 1.07 | 5.45 |
4 | 0.85 | 0.13 | 3.40 | 1.11 | 5.49 |
表3. vAIK证书生成时间
实验组 | 基于Domain T架构的Xen系统 | 原始Xen系统 |
---|---|---|
1 | 3.17 | 3.56 |
2 | 3.34 | 3.62 |
3 | 3.19 | 3.51 |
4 | 3.05 | 3.42 |
表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%。
本文以Xen系统为基础,提出了基于Domain T的可信虚拟机系统架构。通过迁出vTPM manager和vTPM实例降低了Domain 0的TCB大小,理论上可以保障Domain T的计算资源不被其他虚拟机的计算请求抢占,提高了vTPM性能。同时,本文的虚拟证书链生成方案通过引入Domain T域身份密钥tEK,解决了现有方法中用AIK签名TPM外部数据为vAIK证书背书的问题。最后,本文实现了相关原型系统,并验证了系统的有效性。
王 冠,郭一清,陈建中. 云环境下可信系统架构与虚拟证书链生成研究 Research on Trusted System Architecture and Virtual Certificate Chain in Cloud Environment[J]. 计算机科学与应用, 2018, 08(05): 738-747. https://doi.org/10.12677/CSA.2018.85082