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实例。当客户虚拟机在创建配置中
![](//html.hanspub.org/file/18-1540995x9_hanspub.png)
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/
![](//html.hanspub.org/file/18-1540995x10_hanspub.png)
Figure 2. “KEY-VALUE” structure preserved in XenStore
图2. XenStore中保存的“键-值”结构
![](//html.hanspub.org/file/18-1540995x11_hanspub.png)
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,记做
。信任关系具有以下性质:
1) 自信任性:
。
2) 传递性:
。
定义2 可信证明:当实体B向挑战者提供的证明实体A信任B的证据
,能够满足A信任B的标准要求
时,可得
,记做
。
对于证书链的构建方法,目前已有一些研究成果。文献 [10] 提出
形式的证书链方案,绕过
直接由
签发
。该方案首先利用
对
公钥、物理TPM的PCR值、随机数
及时间戳进行签名,在此本文用
表示,然后将签名数据与
一同构成
。由于
是由
签发,因此实现了
的信任传递。然而根据TCG规范,
不能用于对TPM外部数据签名。此外由于
生命周期短,每次验证后都应当重新生成
,导致
随
的失效而失效。
针对
不能对外部数据签名的规定,文献 [16] 提出一种新密钥
,通过
,
的方式形成
与
的间接签名。然而,该方案依然存在
时效性差的问题。
为解决
时效性问题,文献 [17] 引入私钥生成中心(Private Key Generation, PKG),提出利用环签名证明VM的可信性。首先云平台利用隐私认证中心(Privacy Certification Authority, CA)向PKG证明可信性,PKG产生部分环签名密钥发给云平台,云平台再将部分环签名发给vTPM manager,最后vTPM manager将签名分发给vTPM。然而该方案的问题在于vTPM中的vPCR不完全等同于TPM中的PCR,当挑战者发起验证时会因为PKG中存储的是云平台PCR值,与vPCR值不匹配而导致验证失败。
因此,为了规避
时生命周期短的特性,同时满足
对TPM内部数据签名的合规性要求,本文引入Domain T域身份密钥
。CA首先通过验证Domain T的完整性向Domain T签发
,之后由Domain T签发
,进而保证
的合法性。
CA签发
必须建立在
的基础上。根据定义1的信任传递性特点,需要先证明
。
的过程是标准的
签发过程,在此不再赘述。接下来证明
成立的条件是
。由于Domain T运行在Xen Hypervisor之上,本文将Domain T的度量包含在Xen的启动过程内,并将其摘要值扩展地写入PCR [13] 中,因此
。
至此,
的信任传递建立成立。
vTPM中
生成的具体流程如下:
1) Domain T生成tEK密钥对,并向CA发送
请求。
2) CA向Domain T发送
以及一个随机数
。
3) Domain T利用该随机数
向平台TPM发起远程挑战。
4) TPM使用
对物理PCR值、
进行签名,将签名结果
和
、度量日志一起返回给Domain T。
5) Domain T使用
对
以及TPM发来的签名结果、
、度量日志进行签名,一起发给CA。
6) CA通过解密并比对TPM中PCR [13] 的值判断Domain T是否完整。若比对通过,则
向Domain T签发
。
7) 当Domain T产生新的vTPM时,vTPM 随机生成vEK密钥对,Domain T通过
签名
,配合
一起形成
。
8) 当vTPM申请
时首先向Domain T发送
请求,由Domain T返回一个
以及一个随机数
。
9) vTPM随机生成vAIK密钥对,然后将
、
和
经
签名后发送给Domain T。
10) Domain T通过解密比对确认
有效后签发
。
CA通过验证平台完整性即可验证Domain T的完整性,通过挑战平台完整性即可挑战
的有效性。这一过程不涉及AIK密钥对TPM外部数据的签名。
与
由Domain T直接颁发,解决了
与某一个
强绑定所导致的时效性差的问题。围绕
的生成与签发,本文所提虚拟证书链构建方案与其他现有方法的优缺点对比如表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的计算性能两个维
![](Images/Table_Tmp.jpg)
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和未
![](Images/Table_Tmp.jpg)
Table 2. tEK certificate generating time
表2. tEK证书生成时间
![](Images/Table_Tmp.jpg)
Table 3. vAIK certificate generating time
表3. vAIK证书生成时间
![](Images/Table_Tmp.jpg)
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证书背书的问题。最后,本文实现了相关原型系统,并验证了系统的有效性。