具有瀑布特征的可信虚拟平台信任链模型

齐　能，谭　良

(1.四川师范大学 计算机科学学院，成都 610101；　2.中国科学院 计算技术研究所，北京 100190)(*通信作者电子邮箱qihuaneng@163.com)

0　引言

随着云计算、大数据等大型计算应用环境在实际业务上更多的应用，具有提高效率、节约成本等优点的虚拟化技术得到工业界和学术界的高度关注，并得以快速应用和推广。如何保障虚拟化平台服务的可信[1-3]，确认虚拟化平台向用户提供可信任的资源和服务[4-6]，是目前亟待解决的问题。基于硬件信任根的可信计算技术作为保障信息系统安全的关键技术，通过构建从平台底层硬件到平台上层应用程序的信任链[7-8]，并结合可信远程证明向平台外部实体提供可信证明[9-11]。因此，利用可信计算技术保证虚拟机平台可信、构建可信虚拟平台(Trusted Virtualization Platform, TVP)环境并构建其信任链模型成为目前的研究热点。

TVP的概念首先由Berger等[12]提出，随后一些学者[13-16]针对如何构建具体应用场景的TVP功能应用以及抽象和统一的TVP概念取得了很多较好的研究成果，并且达成了一些基本的共识。目前，相关学者绝大多数都认为，在物理上，TVP作为一个可以支持虚拟化技术的可信计算物理主机，与一般的可信计算的区别在于：拥有在物理硬件可信平台模块(Trusted Platform Module, TPM)构建起来的虚拟可信信任根；可以为多个用户虚拟机(Virtual Machine, VM)提供可信虚拟信任环境。这种TVP的运行架构如图1所示。从功能上看，TVP架构主要分为四个层次：第一层为硬件信任根TVP，为整个架构提供信任的物理保证；第二层主要包括虚拟机监视器(Virtual Machine Monitor, VMM)，及构建于VMM之上的管理域，它们通常被认为是TVP的可信计算基(Trusted Computing Base, TCB)；第三层是虚拟信任根(virtual Root of Trust, vRT)，由于实现方案不同(如图1中(a)、(b)所示)，可作为传统信任链的扩展，或者利用动态度量信任根(Dynamic Root of Trusted Measurement, DRTM)机制启动；第四层是与用户紧密相关的用户虚拟机。

图1　TVP基本运行架构Fig. 1　Basic running architecture of TVP

尽管如此，上述的TVP基本运行架构以及信任链传递模型存在过粗且逻辑上不完全合理的问题，与云环境中虚拟化平台也不完全相符合。如图1所示，为了便于叙述，本文将图1中从TPM到第三层的信任链称为可信虚拟平台信任链，将第四层的信任链称为虚拟机信任链。具体问题表现在：

1)现有的TVP模型把整个第三层都作为TVP的TCB并作为虚拟机的vRT，显然是不精细的，且逻辑上也不完全合理的。第三层包括VMM以及DOM管理域(即宿主机Domain0，为方便描述，后文称为Dom0)，信任链为CRTM(Core Root of Trust for Measurement)→BIOS→BootLoader→VMM→DOM OS→Apps，DOM管理域包含OS及大量的应用程序，显然不能采用链式度量所有的应用程序并存储其平台配置寄存器(Platform Configuration Register， PCR)值。

2)虚拟平台信任链与虚拟机信任链是两条不同的信任链，即在整个TVP以及客户虚拟机启动过程中存在两条在度量层次和度量时间上完全分隔的信任链，一条是可信虚拟平台在启动时的信任链，另一条是客户虚拟机在启动时的信任链。

针对上述问题，本文提出了一种具有瀑布特征的TVP架构TVP-QT，并对TVP-QT信任链传递模型进行了构建，建立了拥有可信衔接点(Trusted-Joint Point, TJP)的TVP-QT及其完整的信任链模型。该模型以虚拟化硬件层物理TPM为起点，在可信虚拟化平台信任链和可信虚拟机信任链之间加入可信衔接点。当信任链从可信云平台传递到可信衔接点时，由可信衔接点负责对可信虚拟机的可信虚拟平台模块(virtualization Trusted Platform Module, vTPM)及相关组件进行度量，之后再将控制权交给vTPM，由vTPM负责对虚拟机的VBIOS(Virtual BIOS)、VMOS(OS of Virtual Machine)到VM应用进行度量。该模型中可信衔接点具有承上启下的瀑布特征，能满足云环境的层次性和动态性特征，保证了整个可信虚拟平台的可信性。

1　相关工作

目前针对TVP及其抽象模型以及信任链传递模型的研究得到了国内外学者的广泛关注，本文就目前对TVP、TVP信任链模型的研究进行了以下总结和分析。

对于TVP的研究，早在TVP概念出现之前，就出现了利用可信计算技术解决虚拟系统平台安全的方案，为TVP的发展提供了一些理论和构建基础，这些平台包括Terra[17]、PERSEUS[18]等，这些平台的主要思想是把底层计算平台分为两部分，包括运行着高安全性需求虚拟机的可信区域和其他不可信区域。随后，Berger等[12]首先提出构建TVP的基本组件vRT、vTPM等基本思想，并且构建了具体的TVP架构。根据文献[12]的vRT等概念，HP、IBM等研究机构分别提出并构建了相应的TVP[13-14]，其TVP架构可根据不同应用需求建立用户可定制的TVP，在很大程度上推动了TVP的发展。随后，Krautheim等[15]、王丽娜等[16]基于云计算环境建立了TVP，使其可以保护云计算环境下的虚拟机运行，以及保护虚拟机运行时上层服务软件的完整性、安全性。之后，常德显等[19]根据TVP的功能层次给出了包括虚拟机和虚拟可信根的TVP定义，并细分为VMM、Dom0、TPM、vRT等组件。Zhang等[20]提出一种具有可信域层次的TVP，通过采用可信云平台和可信虚拟机进行分离的TVP构建机制，实现了对可信云平台以及可信虚拟机的安全保障。Yu等[21]、池亚平等[22]、李海威等[23]提出的可信虚拟平台均为链式结构，存在信任链分离的问题。徐天琦等[24]、杨丽芳等[25]、蔡谊等[26]也分别利用可信计算技术构建TVP解决虚拟化平台服务器的安全性问题。总结起来，目前已有的研究成果把TVP的VMM和管理域都作为TCB，一起作为虚拟机的vRT，这显然存在过粗且逻辑上不完全合理的问题，因为管理域包含OS及大量的应用程序，不能采用链式度量所有的应用程序并存储其PCR值。

对于TVP信任链模型的研究，主要包括三个方面。其一是通过对可信计算组织(Trusted Computing Group， TCG)链式信任链模型的扩展，实现TVP下可信度量以及信任传递。Scarlata等[27]提出在构建TVP时，通过可信测量构建从CRTM可信根到每个客户虚拟机的信任链，就可以证明每个客户虚拟机是可信的；这种信任链模型是不完善的，无法适应比较复杂的TVP环境。Krautheim等[28]对信任链扩展上提出了“Transitive Trust Chain”信任链模型，并且简要地指出了信任链传递过程为TPM→VMM→TVEM manager→TVEM→VM OS→应用程序(APP)，但是此种信任链模型没有详细描述特权域操作系统以及虚拟机操作系统的可信度量。Shen等[29]根据TCG动态度量方法提出了一种基于Xen的可信虚拟机在DRTM下的信任链构建，其具体的构建过程为：CPU→可信代码→Xen VMM→Dom0(→vTPM Manager→Domain Builder)→Guest OS→APP，此种信任链模型也存在Krautheim等[28]所提模型中的问题。其二是通过研究可信云平台和可信虚拟机两部分的信任链，构建TVP下的信任链模型。常德显等[19]提出的TVP信任链从功能层次可表示为：硬件TPM层→TCB层→vRT层→用户虚拟机层的信任链模型，此信任链模型对vRT及层次间的连接定义比较模糊。Zhang等[20]提出一种基于无干扰的可信域层次信任链模型，并且指出分别度量物理主机和VM的方式，即首先度量从物理的TPM到物理主机的应用程序，然后度量VM的vTPM和应用程序，此种信任链模型无法有效地在TVP下构建完整的链式信任链模型，不能向用户虚拟机呈现一条完整的信任链模型，文献[22-23]也存在此类问题。其三是树型或者星型的信任链模型。一部分学者认为TCG的链式信任链可信度量方式在虚拟化环境下是难以有效构建的。朱智强[30]、曲文涛[31]基于星型信任度量结构，提出基于信任根(Root of Trust, RT)对各个节点进行度量的模型及其改进，但是此种信任链模型也存在负担重的管理域(Management Domain， MD)节点。总结起来，目前针对TVP的信任链模型的共同问题是信任链模型过粗且逻辑上不合理，而且目前研究内容中的可信虚拟平台信任链与虚拟机信任链是两条在度量层次和度量时间上分离的信任链，不能向虚拟机用户展示一条从TPM到虚拟机应用的完整信任链。

综上所述，TVP基本运行架构以及信任链传递模型均有待改进。特别地，由于TVP具有层次性和动态性，已有的研究成果不能精细地描述虚拟化环境中复杂的信任链传递机制，且存在两条分离的信任链。

2　具有瀑布特征的TVP及信任链模型

为解决引言中提出的问题，本文提出了具有瀑布特征的TVP-QT及信任链模型。本文主要针对TVP-QT及信任链模型，而针对虚拟化平台固有的安全性机制，比如VMM的特权域操作、VM之间的隔离性等安全性机制，可参考Barthe等[32]给出的形式化描述与分析。本章将对TVP-QT的功能组件以及TVP-QT信任链信任属性进行定义，并在下一章利用文献[33]提出的安全逻辑形式化方法对信任链进行形式化分析。本文主要对文献[19]给出的定义进行扩展，其基本定义不再叙述。

2.1　TVP-QT信任模型

基于已有的TVP研究方案，本文提出的TVP-QT信任模型如图2所示。TVP-QT分为五个层次：第一层是硬件信任根TPM构成的可信虚拟平台底层。第二层主要包括VMM以及管理域Dom0的相关组件，包括VBOIS、VOSLoader、VMOS等组件，作为TVP-QT的可信计算基。把Dom0 Kernel看成是可信基，这比已有的TVP更合理，因为Dom0实际上是整个虚拟化平台的管理域，含大量的应用程序，这些管理程序无法采用TCG链式度量，也很容易受到攻击而改变[34-37]。第三层是重点设计的可信衔接点，可信衔接点位于Dom0，是Dom0的一组应用程序，包括vTPM实例的创建模块vTPM Builder、vTPM-VM映射组件vTPM-VM Binding以及VM的创建组件VM Builder，且作为vRT的一部分，在信任链上按照vTPM Builder→vTPM-VM Binding→VM Builder的顺序依次进行度量。可信衔接点可对TVP-QT的第一、第二层与第四、第五层进行有效衔接，保证TVP-QT信任链构建的连贯性，起到承上启下的作用，具有瀑布特征。第四层为vTPM，最上层为用户虚拟机层次，其运行时组件主要包括VBIOS、VOSLoader、VMOS、应用程序(APP)等相关组件。基于上述对TVP-QT的分析，本文依据文献[19]的基础定义进行扩展抽象定义。

图2　TVP-QT运行架构Fig. 2　Running architecture of TVP-QT

定义1TVP-QT主要包括两类功能组件：TVP-QT:={M, RT}。其中：M表示虚拟化平台所有主机类型集合，包括构成虚拟化平台的基本组件VMM、管理域内核、可信衔接点及用户虚拟机等；信任根(RT)是构建TVP信任环境的基础，也是TVP的核心组件，对TVP-QT来说，它包括硬件TPM、可信衔接点TJP和vTPM。

其中：M={m, vm}，m:={VMM, Dom0 Kernel, TJP}，vm:={vm1, vm2, …, vmn}；RT:={TPM, vRT}={TPM, (TJP, vTPM)}；并且m必须利用TPM进行可信度量来提供信任，vm利用TJP和vm对应的vTPM实例进行可信度量。可信衔接点TJP可以划分为TJP:={vTPM Builder, vTPM-VM Binding, VM Builder}，其中vTPM Builder表示与创建和管理vTPM实例相关的组件，并负责提供给vm运行时的vTPM标识以及端口；而vTPM-VM Binding则表示对vm和vTPM实例间绑定关系的相关组件；VM Builder表示与创建用户虚拟机相关的配置文件、组件等。在TVP-QT涉及到的vTPM架构中，每个vm必须与唯一对应的vTPM实例绑定。可信衔接点TJP的来源如表1所示，其中vTPM管理组件可由VMM上的vTPM组件提供，比如目前存在于Xen上的vTPM Manager。

表1　TJP功能组件来源Tab. 1　Resource of TJP’s components

相对于已有的TVP，本文提出的TVP-QT信任模型具有如下特点：

1)TVP-QT更加精细。已有的TVP把整个管理域作为TCB，TVP-QT模型仅把Dom0 Kernel、TJP及vTPM作为TCB。

2)TVP-QT在逻辑上更合理。一方面，TVP-QT可以按链式度量所有层次，更符合TCG的链式度量标准；另一方面，TVP-QT增加了TJP，从逻辑上比已有的TVP更加合理。

2.2　TVP-QT信任链及属性

本文依据TCG对信任链的基本定义和要求构建了基于TVP-QT的信任链模型，如图3所示，从外部实体来看，虚拟化平台仍然满足TCG最初建立信任环境的思想。

图3　虚拟化平台可信环境信任链构建与验证Fig. 3　Construction and validation of TVP-QT trust chain

本文将2.1节的可验证目标抽象为信任链的信任属性(Trusted Property, TP)，其抽象定义如下。

定义2TVP-QT的信任属性为一个二元组：TPTVP-QT:={TCTVP-QT,VerTVP-QT}，其中TCTVP-QT表示2.1节对TVP-QT信任链模型具体构建过程描述的各个组件序列，VerTVP-QT表示为需要对TVP-QT信任链模型进行远程认证的执行序列。

按照定义1对TVP-QT中相应功能组件的定义，该TVP-QT信任属性可以进一步细分为：

TPTVP-QT:={(TCm,(TCTJP,TCvTPM),TCvm),

(Verm,(VerTJP,VervTPM),Vervm)}

由定义可知TVP-QT信任属性可以分为三类：m的信任属性TCm，vRT的信任属性TCvRT，以及vm的信任属性TCvm。其中TCvRT包含TCTJP和TCvTPM两个属性。下面对TVP-QT三类组件的信任属性进行分别阐述。

1)主机m的信任属性表示为TPm:={TCm,Verm}，其中，TCm表示基于硬件信任根构建的信任链，即CRTM→BIOS→OSLoader→VMM→Dom0 KernelTPM_Static，此部分信任链可基于硬件可信芯片TPM的可信度量，在TVP-QT信任链可信传递过程中没有其他程序代码加载或者执行。Verm:=Verify(m, TCm)表示对外验证主机m所声称的信任属性TCm，使远程验证者R相信TVP-QT平台主机m拥有这样的信任链属性TCm。

2)vRT的信任属性为TPvRT:={TCvRT, VervRT}。由定义1对vRT以及定义2对TVP-QT信任属性的定义：

TPvRT:={(TCTJP, VerTJP), (TCvTPM, VervTPM)}

其中，TCTJP表示基于硬件信任根构建的信任链衔接点，其信任传递的过程包括两种情况：其一是在m启动时，需要采用静态度量方式对TJP进行度量，其信任传递的过程为 (…→Dom0 Kernel→TJP)TPM_Static，完整地表示为:(CRTM→BIOS→OSLoader→VMM→Dom0 Kernel →vTPM Builder → vTPM-VM Binding→VM Builder)TPM_Static；其二是在创建vm时，为了保证TJP的可信(由于TJP是应用程序，恶意程序容易篡改)，从而使得信任关系可以传递到新建的vm, 需要采用动态度量方式对TJP重新度量验证，信任传递的过程为 (TJP)TPM_Dynamic，完整表示为:(vTPM Builder→vTPM-VM Binding→VM Builder)TPM_Dynamic。在这两种情况下，VerTJP:=Verify(TJP, TCTJP)表示对外验证可信衔接点所声称的信任属性TCTJP；TCvTPM表示用户虚拟机信任根vTPM。其中，TJP到vTPM的信任传递，既可以采用静态度量，也可以采用动态度量，其信任传递的过程为：(TJP→vTPM)TPM_Staic或(TJP→vTPM)TPM_Dynamic。VervTPM:=Verify(vTPM, VervTPM)表示对外验证vTPM所声称的信任属性TCvTPM。

3)vm的信任属性表示为TPvm:={TCvm,Vervm}，其中TCvm表示基于vTPM构建的信任链，在创建vm时需采用动态度量方式对TJP进行度量，vm从初始化到应用的可信启动过程为：(TJP)TPM_Dynamic→{INIT→VBIOS→VOSLoader→VMOS→APP}vTPM_Static。VerVM:=Verify(vm,TCvm)表示vm信任链的外部验证。

显然，相对于已有的TVP信任链模型，本文提出的TVP-QT信任链模型具有如下特点：

1)TVP-QT信任链模型具有瀑布特征。TJP将分离的两条信任链链接起来，保证TVP-QT信任链构建的连贯性，起到承上启下的作用。

2)TVP-QT信任链模型具有动态性和层次性。动态性主要体现在两个方面:其一，从时间上看ms的信任链和vm的信任链是两条分离的信任链；其二，可信衔接点TJP在ms启动时采用的是静态度量，而在vm创建时，需要动态度量。层次性主要体现在ms的信任链是基础，处于底层，而各vm的信任链是信任扩展，处于顶层。底层信任链和顶层信任链通过衔接点TJP链接，保证底层信任链到顶层信任链的信任扩展。

3)TVP-QT信任链模型利用构建的可信衔接点解决了虚拟平台信任链与虚拟机信任链的衔接问题。

3　基于扩展LS2的TVP-QT信任链分析

本文将采用已有的形式化分析方法“扩展安全逻辑(Logic of Secure System, LS2)”对TVP-QT信任链模型进行形式化分析。对LS2的具体内容可参考文献[19，33]。

3.1　基本假定

在对TVP-QT信任链属性进行形式化分析前，本文假定以下条件是成立的：1)TVP中的每个层次的镜像文件未受破坏，用户虚拟机可被可信度量；2)m支持 DRTM技术，能够动态度量TJP和vTPM；3)vTPM的平台身份密钥(Attestation Identity Key，AIK)已得到认证并颁发证书，具体实现方案参见vTPM[14]及 Trust Visor[38]等；4)远程挑战者 R 与本地TVP之间已经建立了安全信道[19]。

从2.2节的分析可知，本文对TVP-QT 信任链的信任属性分析验证主要包括三部分：

1)包括TJP在内的m信任链构建的验证及远程验证；

2)TJP动态度量验证及远程验证；

3)利用vTPM构建的vm信任链验证及远程证明。

在这三部分中，对3)的验证分析与文献[19]相同，具体过程可参见文献[19]，本文不再论述；下面本文只对1)、2)进行验证分析。

3.2　m信任链的本地验证及远程证明

3.2.1本地程序执行

根据2.2节对TVP中m信任属性TPm定义以及TPvRT中对TCTJP的定义，其信任链本地执行过程中涉及到的程序如下列程序1(Code Segment 1)所示。

Code Segment 1：

SRTM(m)≡b=read m.bios_loc

Extend m.pcr.s,b;

Jump b

BIOS(m)≡o=read m.os_loader_loc

Extend m.pcr.s,o;

Jump o

OSLoader(m)≡v=read m.vmm_loc

Extend m.pcr.s,v;

Jump v

VMM(m)≡d=read m.dom0_Kernel_loc

Extend m.pcr.s,d;

Jump d

Dom0 Kernel(m)≡vb=read m.tjp_loc

Extend t.pcr.s,t;

Jump vb

vTPMBuilder(m)≡vv=read m.vtpm-vm-binding_loc

Extend m.pcr.s,vv;

Jump vv

vTPMVM Binding(m)≡vmb=read m.vm-builder_loc

Extend m.pcr.s,vm;

Jump vmb

VMBuilder(m)≡o_app=read m. o_app _loc

Extend m.pcr.s, o_app;

Jump o_app

OtherAPP(m)≡…

程序执行流程：m首先从CRTM启动执行，它从主机内存地址m.bios_loc中读取BIOS的代码b，将其扩展到一个PCR中，之后执行指令Jump b；然后CRTM将控制权传递给m的BIOS，它从主机内存地址m.os_loader_loc中读取OS_Loader代码o，将其扩展到一个PCR中,之后执行指令Jump o，将控制权交给OSLoader；OSLoader继续按序从内存m.vmm_loc读取VMM的代码v，将其扩展到m.pcr.s[19]，然后转换控制权给VMM，VMM、Dom0 Kernel执行相似流程，直到可信衔接点TJP的加载。

3.2.2本地可信属性描述

由上文信任链传递程序执行过程可知，体现主机m信任链的是主机进行可信度量后唯一对应的PCR值。因此，基于定义2，可将m的本地信任传递属性归纳为：信任链加载的正确由PCR中度量值决定。即m的本地信任传递属性就是要求所有相应启动程序如BIOS、OSLoader、VMM、Dom0 Kernel、vTPM Builder、 vTPM-VM Binding、VM Builder等都能按确定的先后顺序加载。以LS2将这种顺序形式化表示为:

MeasuredBootSRTM(m,t)=

∃tS.∃tb.∃to.∃tv.∃td.∃tvb.∃tvv.∃tvmb.∃to_app∧

∃J.(tS

(Reset(m,J)@tS)∧(Jump(J,BIOS(m))@tb)∧

(Jump(J,OSLoader(m))@to)∧

(Jump(J,VMM(m))@tv)∧

(Jump(J,Dom0_Kernel(m))@td)∧

(Jump(J,vTPM-Builder(m))@tvb)∧

(Jump(J,vTPM-VMBinding(m))@tvv)∧

(Jump(J,VM-Builder(m))@tvvb)∧

(Jump(J,VM-Builder(m))@to_app)∧

(┐Reset(m)on(tS,t])∧(┐Jump(J)on(tS,tb))∧

(┐Jump(J)on(tB,to))∧(┐Jump(J)on(to,tv))∧

(┐Jump(J)on(tv,td))∧(┐Jump(J)on(td,tvb))∧

(┐Jump(J)on(tvb,tvv))∧(┐Jump(J)on(tvv,tvvb))∧

(┐Jump(J)on(tvvb,to_app))

上述公式表示：如果TVP的m基于信任链构建了本地信任环境，则其启动过程一定是从BIOS跳转到OSLoader，从OSLoader到VMM，从VMM到Dom0_Kernel，然后从Dom0_ Kernel到TJP，而在此期间不会有其他程序执行。为保证程序逐级加载顺序与PCR值相对应，必须证明信任链本地属性是成立的。

定理1如果m从CRTM启动运行，且与该m启动过程对应的PCR值为seq(BIOS(m),OSLoader(m),VMM(m),Dom0_Kernel(m), vTPM Builder(m), vTPM-VM Binding(m), VM Builder(m))，那么该m的本地信任链传递过程就是唯一的、正确的，即确定地从BIOS(m)到OSLoader(m)再到VMM(m)、Dom0 Kernel(m)、vTPM Builder(m)、 vTPM-VM Binding(m)、VM Builde(m)。该信任属性形式化表示为：

ProtectedSRTM(m)+Mem(m.pcr.s,seq(BIOS(m),

OSLoader(m),VMM(m),Dom0_Kernel(m),

vTPMBuilder(m),vTPM-VM Binding(m),

VM Builder(m)))⊃MeasuredBootSRTM(m,t)

证明本文按照以下步骤进行证明：

首先，由前提条件可知在时间点t，有Mem(m.pcr.s, seq(BIOS(m),OSLoader(m), VMM(m), Dom0_Kernel(m), vTPM Builder(m), vTPM-VM Binding(m), VM Builder(m)))成立，反复利用PCR公理即可直接得到在该序列中的所有子序列一定在时间t之前就出现在m.pcr.s中，即：

∃tS,t1,t2,t3,t4,t5,t6,J.(tS≤t1

(Mem(m.pcr.s,seq(BIOS(m),OSLoader(m),

VMM(m),Dom0_Kernel(m),vTPM Builder(m),

vTPM-VM Binding(m),VM Builder(m)))@t)∧

(Mem(m.pcr.s,seq(BIOS(m),OSLoader(m),

VMM(m),Dom0_Kernel(m),vTPM Builder(m),

vTPM-VM Binding(m)))@t6)∧(Mem(m.pcr.s,

seq(BIOS(m),OSLoader(m),VMM(m),

Dom0_Kernel(m),vTPM Builder(m))),@t5)∧

(Mem(m.pcr.s,seq(BIOS(m),OSLoader(m),

VMM(m),Dom0_Kernel(m)))@t4)∧(Mem(m.pcr.s,

seq(BIOS(m),OSLoader(m),VMM(m)))@t3)∧

(Mem(m.pcr.s,seq(BIOS(m),OSLoader(m)))@t2)∧

(Mem(m.pcr.s,seq(BIOS(m)))@t1)∧

Reset(m,J)@tS∧(┐Reset(m)on(tS,t))

(1)

接下来对程序1中信任链的执行过程进行说明，最先执行的操作是以CRTM为起点启动m，即Reset(m,J)，然后m执行第一个信任程序BIOS(m)。利用LS2规则，在某个时间tB，程序会跳转到b,此时内存位置被锁定，防止其他程序跳转[19]。即有以下属性(2)成立。

∀t′,b,o

(((Mem(m.pcr.s,seq(BIOS,b,o))@t′)∧(ts

∃tb·((ts

(IsLocked(m.pcr.s,J)@tb)

(2)

类似地，接下来的信任程序：OSLoader(m)、VMM(m)、Dom0_Kernel(m)、vTPM Builder(m)、vTPM-VM Binding(m)和VM Builder(m)也利用LS2规则，在某个时间to、tv、td、tvb、tvv、tvmb、to_app，程序会跳转到o、v、d、vb、vv、vmb、o_app，且其他时间不会有程序跳转，相应的内存位置(即PCR值)被该线程锁定，即有o、v等对应的类似式(2)的属性成立，限于篇幅，这些属性略。

根据式(2)及o、v、d等对应的属性可知，如果前提条件满足，那么m上执行程序的顺序一定是从BIOS(m)到OSLoader(m)再到VMM(m)、Dom0Kernel(m)、TJP(m)。

∃tS,tb,to,tv,td,tvb,tvv,tvmb,to_app

(tS

(┐Reset(m,I)on(tS,t])∧(Reset(m,J)@tS)∧

(Jump(J,BIOS(m))@tb)(┐Jump(J,BIOS(m))

on(tS,tb))∧(Jump(J,OSLoader(m))@to)∧

(┐Jump(J,OSLoader(m))on(tb,to))∧

(Jump(J,VMM(m))@tv)∧

(┐Jump(J,VMM(m))on(to,tv))∧

(Jump(J,Dom0_Kernel(m))@td)∧

(┐Jump(J,Dom0_Kernel(m))on(tv,td))∧

(Jump(J,vTPM-Builder(m))@tvb)∧

(┐Jump(J,vTPM-Builder(m))on(td,tvb))∧

(Jump(J,vTPM-VM Binding(m))@tvv)∧

(┐Jump(J,vTPM-Builder(m))on(tvb,tvv))∧

(Jump(J,VM Binding(m))@tvmb)∧

(┐Jump(J,VM Builder(m))on(tvv,tvmb))∧

(Jump(J,VM Binding(m))@to_app)∧

(┐Jump(J,VM Builder(m))on(tvmb,to_app))

(3)

定理1即得证。

可信计算技术提供的度量扩展机制能够保证只有程序得到正确的内存值时才能继续运行下一个程序，可确保程序是在无攻击者存在的情况下运行的。

3.2.3信任链远程验证

TVP-QT的m需要对外部挑战者证明自身的信任属性，需要证明MeasuredBootSRTM(m,t)成立，证明方法可参照上文以及文献[33]，本文在此仅对验证程序进行说明。m信任传递的远程验证过程中涉及到的程序，如程序2(Code Segment 2)所示。

Code Segment 2：

TPMSRTM(m)≡w=read m.pcr.s;

r=sign(PCR(s),w),AIK-1(m);

send r

Verifier(m)≡sig=recieve;

v=verify sig, AIK(m);

match v,(PCR(s),

seq(BIOS(m),OSLoader(m),VMM(m),

Dom0_Kernel(m),vTPM Builder(m),

vTPM-VM Binding(m),VM Builder(m)))

首先，m读取存储的PCR值，用AIK签名(AIK-1(m))并将其发送给远程验证者R。然后，R验证该签名，如果PCR值是匹配的，则说明m的可信属性是值得信任的。在此过程中R与m应是不同的实体，以保证该验证过程的有效性，避免验证过程的伪造。

这些前提条件形式化表示为:

{TPMSRTM(m),TPMDRTM(m)})}

(4)

3.3　可信衔接点TJP的本地验证及远程证明

本节根据2.2节对TVP-QT中的相关定义和说明，对可信衔接点TJP的动态度量机制进行本地验证和远程证明的形式化描述。

3.3.1本地程序执行

根据2.2节对TVP-QT中TJP信任属性TPTJP定义以及TPvRT中对TCTJP的定义，其信任链本地执行过程中涉及到的程序如程序3(Code Segment 3)所示。

Code Segment 3:

LatelaunchDTRM(vTPM-Builder) ≡vtb=read m.vTPM-Builder_loc;

Extend m.dpcr.d,m;

Jump vtb

…

vTPM-Builder(TJP)≡vvb=

read m.vTPM-VM-Binding_loc;

Extend m.dpcr.d,vvb;

Jump vvb

vTPM-VM Binding(TJP)≡vvmb=read m.VM-Builder_loc

Extend m.dpcr.d,vvmb;

Jump vvmb

VM-Builder(TJP)≡vtpmb=read m.vTPM_loc

Extend m.dpcr.d,vtpmB;

Jump vtpmb

vTPM(m)≡…

程序执行流程：首先确保TJP的vTPM-Builder能正常加载。然后利用DRTM度量TJP的三个组件vTPM Builder、vTPM-VM Binding、VM Builder，从主机内存地址中读取vTPM Builder的代码，将其扩展到一个PCR中[19]；之后执行命令Jump vtb将控制权交给vTPM Builder，按照上面的过程依次度量vTPM-VM Binding、VM Builder。

在此过程中，对TJP的动态度量必须在m启动之后且创建vm之前，否则会导致TJP无法按顺序正确度量。将其表示为:

Honest(TPMSRTM(m)≻TJPDRTM(m)∧

TJPDRTM(m)≻vTPMSRTM/DRTM(vm))

此外，TVP在启动m时，相应的线程K对必须能够对当前m对应的PCR值有锁控制，这种控制对潜在的攻击者也成立，表示为:

ProtectedSRTM(m)=∀t,K.(Reset(m,K)@t)⊃

(IsLocked((m.pcr.s,m.pcr.d),K)@)t

由于TJP 的vTPM Builder被抽象为一个单独的应用程序，利用Latelaunch(vTPM Builder)动态加载机制确保其可信执行，即KDRTM成立[27]。

3.3.2本地可信属性描述

基于定义2及TJP度量后的PCR和其中的每个组件存在的唯一性、确定性映射关系，可将TJP的本地信任传递属性归纳为：TJP信任链加载程序执行顺序的正确性由最终产生的PCR值决定。即TJP的本地信任传递属性就是要求所有相应启动程序如vTPM Builder、vTPM-VM Binding、VM Builder等都能按确定的先后顺序加载。以LS2将这种顺序形式化表示为:

MeasuredBootDRTM(TJP,t)=

∀I∈m.∃tvtb.∃tvvb.∃tvvmb.∃tvtpmb.

∃K.(tvtb

(Jump(K,vTPM Builder(TJP))@tvtb)∧

(Jump(K,vTPM-VM Binding(TJP))@tvvb)∧

(Jump(K,VM Builder(TJP))@tvvmb)∧

(Jump(K,vTPM(TJP))@tvtpmb)∧

(┐Reset(m)on(tvtb,t])(┐Jump(K)on(tvtb,tvvb))∧

(┐Jump(K)on(tvvb,tvvmb))∧

(┐Jump(K)on(tvvmb,tvtpmb))

(5)

式(5)表示：如果TVP基于信任链构建TJP信任环境，则其启动过程一定是从vTPM Builder跳转到vTPM-VM Binding，然后到VM Builder，在程序执行期间，程序启动序列都有唯一的PCR值，并且不会有其他应用程序或者组件执行。需要证明的信任链本地信任属性如下。

定理2如果TJP加载成功，且与该TJP加载过程对应的PCR值为seq(vTPM Builder(TJP),vTPM-VM Binding(TJP),VM Builder(TJP))，那么该TJP的本地信任链传递过程就是唯一的、正确的，即确定地从vTPM Builder(TJP)到vTPM-VM Binding(TJP)再到VM Builder(TJP)。该信任属性形式化表示为:

ProtectedDRTM(TJP)+

Mem(m.dpcr.d,seq(vTPM Builder(TJP),

vTPM-VM Binding(TJP),VM Builder(TJP)))⊃

MeasuredBootDRTM(TJP,t)

(6)

证明过程类似m的信任链本地可信属性的证明，在此不再叙述。

3.3.3信任链远程验证

TVP-QT的TJP 需要向R证明自己在信任链传递过程中进行可信度量的组件的信任属性及构建的可信执行环境，需要证明MeasuredBootDRTM(TJP,t)成立。

1)远程验证程序执行。

首先，根据 TCG 远程证明协议规范及在虚拟化平台中的实现，给出TJP 信任传递的远程验证过程中涉及到的程序，如程序4(Code Segment 4)所示。

Code Segment 4:

TPMDRTM(TJP)≡w=read m.pcr.d;

r=sign(PCR(s),w),AIK-1(m);

send r

Verifier(TJP)≡sig=recieve;

v=verify sig, AIK(m);

match v, (PCR(s),

seq(vTPM Builder(TJP),vTPM-VM

Binding(TJP),VM Builder(TJP)))

首先，m读取本地TJP的PCR值，用AIK签名(AIK-1(m))并将其发送给挑战者。然后，由远程验证者R验证签名，并用预期的度量值与收到的PCR值进行匹配，验证TJP是否拥有可信属性。在此过程中远程验证者与TJP所属的主机m应是不同实体。

这些前提条件形式化表示为:

2)信任链属性的远程验证。

根据远程证明协议执行流程，给出以下信任传递属性的远程证明目标。

定理3如果远程验证者确认TJP提供的度量值是唯一的、正确的，那么该TJP对应的PCR值一定是如下的确定序列seq(vTPM Builder(TJP),vTPM-VM Binding(TJP),VM Builder(TJP))，因为根据定理2可知，该序列表明该虚拟机的确执行了相应的信任链传递过程。

形式化表示为：

(Mem(m.pcr.d,seq(vTPM Builder(TJP),

vTPM-VMBinding(TJP),VM Builder(TJP)))@t)

(7)

ΓDRTM，ProtectedSRTM(m)

MeasureBootDRTM(m,t)

(8)

证明过程类似m的信任链远程验证的证明，在此不再叙述。

4　实例系统分析与讨论

本文基于Xen虚拟化平台对TVP-QT信任链进行实际的验证和分析，如图4所示。其中，vRT被分散在Dom0、vTPMmanager域和vTPM域。本章根据第2章中对TVP-QT信任链的描述，将TVP-QT信任链分为三部分，结合Xen 4.4系统，对这三部分信任链进行实际的分析与讨论。

对于第一部分，在Xen平台硬件加电启动之后，把CRTM作为整个信任链的起点，并由CRTM首先度量物理平台BIOS和其他有关BIOS的配置，然后BIOS获得系统的控制权并度量Xen的引导程序Grub，主要度量grub-xen(head.S, trampoline.S, x86_32.S)，Grub获得控制权后会根据Xen的镜像头信息获得入口地址Oxl0000后读入Xen的镜像，并对此镜像和_startxen()进行度量，然后把控制权交给Xen，Xen获得信任之后对Dom0相关组件进行度量，包括construct_dom0()、_start_32_、start_Kernel和LinuxOS镜像等。然后把控制权交给Dom0。至此，第一部分可信引导结束。

图4　基于Xen的TVP-QT系统Fig. 4　TVP-QT system based on Xen

对于第二部分，Dom0 Kernel获得控制权后首先度量TJP的vTPM Builder，包括Xen中创建vTPMManager域的配置文件(.cfg)、vTPM Manger域(主要是MiniOS镜像文件和vTPM Manger程序)以及启动vTPM的vtpm-common.sh、vtpm-impl.sh等组件。然后把控制权交给vTPM Builder，vTPM Builder获得控制权，对TJP的vTPM-VM Binding进行度量，包括Xen中xl、xenstore、vtpmd、tpm-xen、vtpm_manager_handle等针对vTPM-VM绑定的组件。随后vTPMBuilder把控制权交给vTPM-VM Binding，vTPM-VM Binding获得控制权后，对TJP的最后的组件VM Builder进行度量，包括Xen的xl、libxl(Xen4.1之后xl作为默认的管理工具)等创建虚拟机所需的组件以及创建虚拟机的配置文件(.cfg)和虚拟机的镜像文件(.img)。完成VM Builder可信度量后，VM Builder获得信任链控制权。至此，第二部分可信信任链传递结束。

对于第三部分，完成度量VM Builder后，可以采用两种方法对vTPM进行度量，其一是静态度量，其二是动态度量。如果采用静态度量，控制权在VM Builder;如果采用动态度量，则控制权在物理TPM。但无论是静态度量还是动态度量，度量的对象都是vTPM实例域，包括vTPM实例域的配置文件(.cfg)以及启动文件(.img)和Mini OS、tpm instance等组件。由于DRTM技术受硬件厂商所限制，利用静态度量方式对vTPM实例域进行可信度量。VM Builder完成对vTPM实例域的度量后，把控制权交给vTPM实例域，vTPM实例域获得控制权，对最后的DomU部分进行可信度量，包括DomU启动的内核所需启动信息页的有关的xen.h、start_info、qemu-dm、qemu-xen、pc-bios等组件和Linux镜像文件进行度量。需要说明的是，Xen中虚拟机有关的BIOS、引导等组件是利用封装在Xen中的Qemu实现的，所以需要对Xen中Qemu重要组件进行可信度量，如qemu-io、qemu-img等。在DomU启动相关组件完成度量之后，可信虚拟平台最后一部分信任链完成可信度量和信任传递。

以上述实例系统为例完整展示了本文建立的通用抽象模型。值得注意的是，本实例系统的信任链得以正确传递需要满足以下前提：

1)必须保障vRT:=TJP+vTPM自身的可信。在实例系统中，可信衔接点TJP包含的组件比较多，还涉及Dom0、vTPMManager和vTPM等域，需要度量的内容多，不允许出现遗漏，特别是TJP和vTPM关键的组件和配置文件必须是被度量的对象。

2)必须确保TJP中的vTPM Builder、vTPM-VM Binding、VM Builder三个管理程序在启动时按顺序执行。尽管vTPM Builder、vTPM-VM Binding和VM Builder是Dom0中的应用程序，但必须保证按顺序执行才能度量结果。

5　实验及结果分析

基于Xen实现了TVP-QT的原型系统，并进行仿真实现和结果分析，对TVP-QT信任链进行有效性验证和性能测试。下面对仿真实验的环境进行描述。

使用TPM-Emulator对TPM功能进行仿真模拟，实验的Xen VMM版本为Xen4.4.0[40-41]，实验物理平台的配置为Intel Core i3 @3.4 GHz处理器，内存为8 GB，物理存储为1 TB。Dom0采用Ubuntu LTS14.04，内核版本为Linux3.19.0，DomU使用类型为Ubuntu LTS14.04的半虚拟化虚拟机，内存为4 GB，并且部署不同的应用作为仿真实验的测试对比。

表2为TVP-QT实验环境所用物理平台和DomU类型为Ubuntu的具体配置信息。

表2　物理平台(Dom0)和用户虚拟机(DomU-Ubuntu)配置Tab. 2　Configure infomation of Dom0 and (DomU-Ubuntu)

本文实验按照云计算环境实际建立了Dom0，DomU(Ubuntu LTS14.04)以及实验所需的vTPMManager域和vTPM实例域，它们的配置文件和启动方式本文不再作详细叙述。

5.1　TVP-QT信任链构建

TVP-QT信任链利用哈希函数对信任链各层次的构建模块、功能组件或文件进行哈希值存储，计算Hash值作为新的完整性度量值存储到PCR中[29]，描述如下：

New PCRi=Hash(Old PCRi‖New Value)

其中：Hash函数选用SHA- 1，‖表示连接符号。在实验中成功运行虚拟机UbuntuTest1，按照表3的顺序对PCR进行存储。其中PCR[0]～PCR[7]存储TVP-QT信任链第一层到第二层TCB的可信度量信息；PCR[8]～PCR[10]分别存储信任链中可信衔接点三个重要的组件的度量信息；PCR[11]～PCR[15]存储vTPM实例域和用户虚拟机信任链度量信息。具体的存储情况如表3所示。

按照TVP-QT信任链顺序存储的信任链信息结果如图5所示。一旦程序或文件内容发生变化，下次执行该程序或者打开该文件时，用户虚拟机就可以根据PCR值的信息判断平台状态是否可信。

表3　仿真实验PCR存储情况Tab. 3　Storage of PCR in simulation experiment

图5　 信任链PCR信息Fig. 5　PCR information of trust chain

5.2　TVP-QT性能测试及分析

与已有的TVP信任链模型相比，TVP-QT信任链模型增加了可信衔接点TJP，需要对其独立度量并且带来额外的开销。对于底层m信任链的构建，TVP-QT信任链模型比已有的TVP信任链模型增加了对TJP的静态度量；对于顶层vm信任链的构建, TVP-QT信任链模型比已有的TVP信任链模型增加了对TJP的动态度量。

为此首先针对TVP-QT信任链构建过程中有关主机m的信任链构建进行性能测试和结果分析，并与传统的TVP架构(图1所示)进行对比分析。

本节性能测试的实验环境采用表1所描述实验环境，并且在Dom0和DomU分别安装一些常用软件来模拟云计算开发环境和云用户环境，比如Firefox[41]、WPS for Linux[42]、Wine[43]、Eclipse[44]等。下面本文分别针对在TVP-QT和传统TVP下m、vm的信任链构建实验，对性能方面进行对比和分析。

5.2.1 信任链构建的性能分析

传统TVP信任链中主机m的信任链构建过程为：

CRTM→BIOS→OSLoader→VMM→Dom0 OS Kernel →APP

TVP-QT中主机m的信任链构建过程为：

CRTM→BIOS→OSLoader→VMM→Dom0 OS Kernel →

vTPM Builder →vTPM-VM Binding→VM Builder→

other_app

对以上两条信任链进行10次实验，并记录每次的完成时间,结果如图6所示。由图6可知，虽然TVP-QT在主机m上比传统TVP多了TJP的静态度量，但是在时间上并没有太大的多余开销，对可信虚拟运行的影响不大。所以，TJP的引入可以在保证可信虚拟平台m相关组件实现完整度量的情况下，不会给平台带来太多的开销。

图6　m信任链构建时间Fig. 6　Construction time of m trust chain

5.2.2vm信任链构建的性能分析

传统TVP信任链中vm的信任链构建过程为:

INIT→VBIOS→VOSLoader→VMOS→APP

TVP-QT中主机vm的信任链构建过程为：

(TJP)TPM_Dynamic→vTPM→VBIOS→VOSLoader→

VMOS→APP

对以上两条信任链进行10次实验，并记录每次的完成时间，结果如图7所示。由图7可知，TVP-QT相比传统TVP下对vm的信任链构建过程，也仅仅多了由TJP带来的额外开销，可以保证对vm可信度量后的正常启动。

图7　vm信任链构建时间Fig. 7　Construction time of vm trust chain

综上对TVP-QT与TVP信任链构建过程的对比实验来看，带有可信衔接点TJP的可信虚拟平台TVP-QT能够保证在对整个平台带来足够小开销的情况下实现对平台的可信度量，保证了虚拟化环境的安全可信。

6　结语

利用可信计算技术构建可信虚拟平台并且构建信任链模型是目前解决云计算安全一个重要的研究方向。本文为了解决已有TVP模型过粗且逻辑不完全合理，而且还存在底层虚拟化平台和顶层用户虚拟机两条分离的信任链等问题，提出了一种具有可信衔接点的TVP-QT模型，对TVP-QT中的功能组件及其信任属性进行详细定义，并结合可信衔接点在TVP-QT建立从虚拟化平台硬件TPM开始的完整信任链模型TVP-QT。最后，本文基于Xen VMM实现了TVP-QT原型系统，并对TVP-QT信任链的构建过程进行了详细的描述，通过仿真实验对TVP-QT及其信任链的有效性和性能等进行了测试，验证了该信任链的正确性和有效性。

参考文献:

[1]林闯,苏文博,孟坤,等.云计算安全:架构、机制与模型评价[J].计算机学报,2013,36(9):1765-1784. (LIN C, SU W B, MENG K, et al. Cloud computing security: architecture, mechanism and modeling [J]. Chinese Journal of Computers, 2013, 36(9): 1765-1784.)

[2]俞能海,郝卓,徐甲甲,等.云安全研究进展综述[J]. 电子学报,2013,41(2):371-381. (YU N H, HAO Z, XU J J, et al. Review of cloud computing security [J]. Acta Electronica Sinica, 2013, 41(2): 371-381.)

[3]ALI M, KHAN S U, VASILAKOS A V. Security in cloud computing: opportunities and challenges [J]. Information Science, 2015, 305: 357-383.)

[4]XU P, CHEN H, ZOU D, et al. Fine-grained and heterogeneous proxy re-encryption for secure cloud storage [J]. Chinese Science Bulletin, 2014, 59(32): 4201-4209.

[5]XIANG S, ZHAO B, YANG A, et al. Dynamic measurement protocol in infrastructure as a service [J]. Tsinghua Science and Technology, 2014, 19(5): 470-477.

[6]YU F, ZHANG H, ZHAO B, et al. A formal analysis of trusted platform module 2.0 hash-based message authentication code authorization under digital rights management scenario [J]. Security and Communication Networks, 2015, 9(15): 2802-2815.

[7]谭良,徐志伟.基于可信计算平台的信任链传递研究进展[J].计算机科学,2008,35(10):15-18. (TAN L, XU Z W. Development of the transitive trusted chain based on TPM [J]. Computer Science, 2008, 35(10): 15-18.)

[8]徐明迪,张焕国,张帆,等.可信系统信任链研究综述[J].电子学报,2014,42(10):2024-2031. (XU M D, ZHANG H G, ZHANG F, et al. Survey on chain of trust of trusted system [J]. Acta Electronica Sinica, 2014, 42(10): 2024-2031.)

[9]谭良,陈菊,周明天.可信终端动态运行环境的可信证据收集机制[J]. 电子学报,2013,41(1):77-85. (TAN L, CHEN J, ZHOU M T. Trustworthiness evidence collection mechanism of running dynamic environment of trusted terminal[J]. Acta Electronica Sinica, 2013, 41(1): 77-85.)

[10]于爱民,冯登国,汪丹.基于属性的远程证明模型[J].通信学报,2010,31(8):1-8. (YU A M, FENG D G, WANG D. Property-based remote attestation model [J]. Journal on Communications, 2010, 31(8):1-8.)

[11]谭良,陈菊.一种可信终端运行环境远程证明方案[J].软件学报,2014,25(6):1273-1290. (TAN L, CHEN J. Remote attestation project of the running environment of the trusted terminal [J]. Journal of Software, 2014, 25(6): 1273-1290.)

[13]DALTON C I, PLAQUIN D, WEIDNER W, et al. Trusted virtual platforms: a key enabler for converged client devices [J]. ACM SIGOPS Operating Systems Review, 2009, 43(1): 36-43.

[15]KRAUTHEIM F J, PHATAK D S, SHERMAN A T. Introducing the trusted virtual environment module: a new mechanism for rooting trust in cloud computing [C]// TRUST’10: Proceedings of the 3rd International Conference on Trust and Trustworthy Computing， LNCS 6101. Berlin: Springer, 2010: 211-227.

[16]王丽娜,高汉军,余荣威,等.基于信任扩展的可信虚拟执行环境构建方法研究[J].通信学报,2011,32(9):1-8. (WANG L N, GAO H J, YU R W, et al. Research of constructing trusted virtual execution environment based on trust extension[J]. Journal on Communications, 2011, 32(9): 1-8.)

[17]GARFINKEL T, PFAFF B, CHOW J, et al. Terra: a virtual machine-based platform for trusted computing [C]// SOSP ’03: Proceedings of the Nineteenth ACM Symposium on Operating Systems Principles. New York: ACM, 2003: 193-206.

[18]PFITZMANN B, RIORDAN J, STÜBLE C, et al. The PERSEUS system architecture, IBM Research Report RZ 3335 (#93381)[R]. Zurich: IBM Research, 2001.

[19]常德显,冯登国,秦宇,等.基于扩展LS2的可信虚拟平台信任链分析[J].通信学报,2013,34(5):31-41. (CHANG D X, FENG D G, QIN Y, et al. Analyzing the trust chain of trusted virtualization platform based on the extended LS2[J]. Journal on Communications, 2013, 34(5): 31-41.)

[20]ZHANG L, CHEN X, LIU L, et al. Trusted domain hierarchical model based on noninterference theory [J]. The Journal of China Universities of Posts and Telecommunications, 2015, 22(4): 7-16.

[21]YU Z, ZHANG W, DAI H, et al. A trusted architecture for virtual machines on cloud servers with trusted platform module and certificate authority [J]. Journal of Signal Processing Systems, 2017, 86(2/3): 327-336.

[22]池亚平,李欣,王艳,等.基于KVM的可信虚拟化平台设计与实现[J]. 计算机工程与设计,2016,37(6):1451-1455. (CHI Y P, LI X, WANG Y, et al. KVM-based trusted virtualization platform design and implementation[J]. Computer Engineering and Design, 2016, 37(6): 1451-1455.)

[23]李海威,范博,李文锋.一种可信虚拟平台构建方法的研究和改进[J].信息网络安全,2015(1):1-5. (LI H W, FAN B, LI W F. Research and improvement on constructing method of a trusted virtualization platform [J]. Netinfo Security, 2015(1): 1-5.)

[24]徐天琦,刘淑芬,韩璐.基于KVM的可信虚拟化架构模型[J]. 吉林大学学报(理学版),2014,52(3):531-534. (XU T Q, LIU S F, HAN L. KVM-based trusted virtualization architecture model [J]. Journal of Jilin University (Science Edition), 2014， 52(3): 531-534.)

[25]杨丽芳,刘琳.基于虚拟机的可信计算安全平台架构设计[J].煤炭技术,2014,33(2):170-172. (YANG L F, LIU L. Design of trusted computing security platform architecture based on virtual machine [J]. Coal Technology, 2014, 33(2): 170-172.)

[26]蔡谊,左晓栋.面向虚拟化技术的可信计算平台研究[J].信息安全与通信保密,2013(6):77-79. (CAI Y, ZUO X D. Trusted computing platform for virtualization technology [J]. Information Security and Communications Privacy, 2013(6): 77-79.)

[27]SCARLATA V, ROZAS C, WISEMAN M, et al. TPM virtualization: building a general framework [M]// Trusted Computing. [S.l.]: Vieweg+Teubner, 2007, 2007: 43-56.

[28]KRAUTHEIM F J, PHATAK D S, SHERMAN A T. Introducing the trusted virtual environment module: a new mechanism for rooting trust in cloud computing [C]// TRUST 2010: Proceedings of the 3rd International Conference on Trust and Trustworthy Computing, LNCS 6101. Berlin: Springer, 2010: 211-227.

[29]SHEN C, ZHANG H, WANG H, et al. Research on trusted computing and its development [J]. Science China Information Sciences, 2010, 53(3): 405-433.

[30]朱智强.混合云服务安全若干理论与关键技术研究[D].武汉:武汉大学,2011:91-117. (ZHU Z Q. The research on some theories and key technologes of hybrid cloud computing security [D]. Wuhan: Wuhan University, 2011: 91-117.)

[31]曲文涛.虚拟机系统的可信检测与度量[D].上海:上海交通大学,2010. (QU W T. Trusted detect and measure for virtual machine system[D]. Shanghai: Shanghai Jiao Tong University, 2010.)

[32]BARTHE G, BETARTE G, CAMPO J D, et al. Formally verifying isolation and availability in an idealized model of virtualization [C]// FM 2011: Proceedings of the 17th International Symposium on Formal Methods, LNCS 6664. Berlin: Springer, 2011: 231-245.

[33]DATTA A, FRANKLIN J, GARG D, et al. A logic of secure systems and its application to trusted computing [C]// SP ’09: Proceedings of the 2009 30th IEEE Symposium on Security and Privacy. Washington, DC: IEEE Computer Society, 2009: 221-236.

[34]CHEN G, JIN H, ZOU D, et al. SafeStack: automatically patching stack-based buffer overflow vulnerabilities [J]. IEEE Transactions on Dependable and Secure Computing, 2013, 10(6): 368-379.

[35]VERMEULEN S. SELinux Cookbook [M]// Birmingham, UK: Packet Publishing, 2014: 2-9.

[36]VARMA P D K, RADHA V. Prevention of buffer overflow attacks using advanced stackguard [C]// Proceedings of 2010 International Conference on Advances in Communication, Network, and Computing. Washington, DC: IEEE Computer Society, 2010: 357-359.

[37]WANG Z, JIANG X. HyperSafe: a lightweight approach to provide lifetime hypervisor control-flow integrity [C]// SP ’10: Proceedings of the 2010 IEEE Symposium on Security and Privacy. Washington, DC: IEEE Computer Society, 2010: 380-395.

[38]McCUNE J M, LI Y, QU N, et al. TrustVisor: efficient TCB reduction and attestation [C]// SP ’10: Proceedings of the 2010 IEEE Symposium on Security and Privacy. Washington, DC: IEEE Computer Society, 2010: 143-158.

[39]TAKEMURA C, CRAWFORD L S. The Book of Xen: A Practical Guide for the System Administrator [M]. San Francisco, CA: No Starch Press, 2009: 2-15.

[40]Xen Project. The Xen Project, the powerful open source industry standard for virtualization [EB/OL]. [2017- 03- 22]. http://www.xenproject.org.

[41]Mozilla Firefox Ltd. The new, fast browser for Mac, PC and Linux | Firefox [EB/OL]. [2017- 04- 12]. https://www.mozilla.org/en-US/firefox/#.

[42]Kingsoft Office Software. Best office run on Linux platform, WPS Office for Linux [EB/OL]. [2017- 05- 05]. https://www.wps.com/linux?from=download_page.

[43]CodeWeavers Inc. WineHQ — Run Windows applications on Linux, BSD, Solaris and macOS [EB/OL]. [2017- 04- 12]. https://www.winehq.org/.

[44]The Eclipse Foundation. Eclipse [EB/OL]. [2017- 04- 02]. https://www.eclipse.org/downloads/.