虚拟化技术是指将各种计算机资源通过转化后呈现出来的方法, 由于它能够最大化利用物理设备为用户节约成本而被广泛利用.云计算^[1-5]是虚拟化技术的应用场景之一.在虚拟化技术的支持下, 云计算可以提供更为灵活可变、可扩展的服务平台.然而对于这种虚拟平台, 用户怎样确定虚拟平台提供的资源和服务是安全的, 怎样确保虚拟平台是可信的, 这是一个至关重要的问题.而可信计算^[6-9]是保障计算平台可信的基础手段, 它通过提供数据保护、身份证明以及完整性测量、存储与报告等功能, 以提高计算平台整体的可信性.因此, 将可信计算技术融入虚拟平台, 已成为云安全研究领域的一大热点^[10-40].

可信基于证明, 只有证明才能在不可信的环境中建立信任关系^[16-19].一般可信终端的远程证明是TPM完整性度量报告, 即:从物理TPM出发, 沿着信任链一直认证到应用程序, 以确保整个终端是可信的^{[11, 20]}.TCG推荐了两种证明方案:其一是PCA方案, 其二是DAA方案.而对于虚拟平台的远程证明, 国内外学者的研究正逐步展开^[36-40].在云环境中, 当分配给云租户的客户虚拟机作为一个通用的可信终端时, 其远程证明与TCG架构下可信终端远程证明具有较大的相似性, 其证明既可以采用PCA也可以采用DAA, 如果vTPM(virtualization trusted platform module)能够按照TCG规范正确设计和执行, 那么远程证明者就能够相信客户虚拟机的软件配置和完整性度量报告^{[22, 23]}.然而, vTPM与TPM(trusted platform module)并不完全相同, vTPM是软件, 且基于云环境, 一般云环境包括IaaS(infrastructure as a service)层、PaaS(platform as a service)层、SaaS(software as a service)层, 相互是彼此独立的, 从运行状态角度看, 每个层次内的运行节点是动态化的, 物理平台和虚拟机管理器任何时候都可能发生变化.显然, 可信虚拟平台的远程认证需要将信任链从物理TPM扩展到了虚拟机上, 如果将现有的认证方法运用于可信虚拟平台, 认证只会从vTPM出发直到虚拟机上的应用程序.因此, 原样将可信终端远程证明已有的研究成果移植到可信虚拟平台是不行的.另外, 尽管TCG在发布的《Virtualized Trusted Platform Architecture Specification》1.0版中有可信虚拟平台的远程证明方案, 不过该远程证明方案仅是个框架^[6], 并没有具体实施方案, 还存在一些难以遇见的困难.

针对以上不足, 本文提出了一种自顶向下的可信虚拟平台远程证明实施方案——TVP-PCA.该方案是在虚拟机中设置一个认证代理, 在虚拟机管理器中新增一个认证服务, 挑战方首先通过顶层的认证代理证明虚拟机环境可信, 然后通过底层的认证服务证明运行于物理平台上的虚拟机管理器可信, 顶层和底层证明合起来确保了整个虚拟平台的可信.

1 相关工作

对于可信终端的远程证明, 到现在为止取得了较多研究成果, TCG组织一直是这一工作积极的主导者和推动者.TCG最初采用的是EK证书证明身份平台, 由于直接使用背书密钥会暴露平台身份信息, 所以在TCG规范1.1版本中, 为避免平台身份信息泄露, 提出使用PCA方案进行远程证明.在该方案中, 可信平台需要向CA申请AIK证书, 导致CA中心会负载过大.文献[21]对PCA方案进行了优化, 提出用证书和令牌标识可信计算平台并直接使用令牌证明平台身份方案, 平台申请一次证书即可以利用该证书多次申请身份令牌, 然后直接使用令牌进行身份证明.文献[22]认为:一般的终端可信只需满足信任链以及相关软件配置的可信证明, 并不能保证终端运行环境的可信.针对此问题, 提出一种可信终端运行环境远程证明方案, 通过对终端的静态环境和动态环境两方面的证明来保证终端运行环境的可信, 该方案本质上属于PCA范畴.文献[23]提出将Privacy CA应用于无线网络环境终端平台可信性的远程认证, 可以正确验证移动节点的可信.文献[24]提出将可信第三方运用于移动互联网下MTT的远程认证.2004年, E.Brickell等人提出DAA方案^[25], 通过采用零知识证明以及群签名等技术, 使得证明方只需要申请一次证书就可以在不暴露平台的真实身份信息前提下, 向不同的挑战方证明自己的平台是一个可信平台.该协议不需要可信第三方的在线参与, 同时又保证了可信平台的匿名性.TCG在TPM规范V1.2中采用此方案, 但此方案一次证明至少需要3次零知识证明, 因而具有性能较差、效率低、复杂度较大等特点.为了提高DAA方法的效率和性能, 文献[26, 27]提出通过降低签名过程中可信平台模块的计算量来对其进行优化, 文献[26]的具体办法是通过缩短签名长度, 文献[27]的具体办法是通过用椭圆曲线的点加和标量乘取代椭圆曲线离散对数.文献[28]针对现有DAA方案存在计算开销大和无法满足跨域匿名认证需求的不足, 提出基于身份的直接匿名认证机制, 采用代理签名和直接匿名证明技术实现移动互联网下可信移动平台(TMP)的跨域匿名认证.该机制具有匿名性、无关联性和高性能等性质的同时, 能够抵抗平台的伪装攻击、替换攻击和重放攻击等敌手攻击行为.杨力在文献[29]中提出:将DAA运用于无线网络可信接入的远程证明, 由外地网络代理服务器直接验证平台身份和完整性, 借助本地网络代理服务器验证用户身份, 既安全高效又能满足无线移动网络需求.之后, 他在文献[30]中运用代理签名技术和直接匿名证明方法, 实现对移动终端在多可信域之间漫游时的可信计算平台认证, 接着还提出通过引入会话密钥协商机制, 抵抗重放攻击和平台伪装攻击^[31].文献[32]用DAA方法实现了对可信终端动态运行环境的可信证据收集代理, 该代理能够为其终端动态环境的可信性提供客观、全面的运行时可信证据, 并且通过特定的可信性评估模型监控终端的运行状态.文献[33, 34]还把可信第三方引入直接匿名认证方法以提高认证效率.特别地, 文献[34]提出的TMP-UAA模型还能够有效地解决直接匿名认证中存在的R攻击及跨信任域问题.文献[35]也是将DAA应用于移动平台可信证明, 提出了基于TrustZone安全技术可信移动平台体系结构, 这个框架结构能够兼容DAA方案和曲线, 还具有较高的计算速度.除此以外, 国内外众多研究机构和学者提出了许多不同的远程证明方法, 其中, 研究成果最多的是基于属性的远程证明^[22], 这方面的成果评述读者可参考文献[22].

在可信虚拟平台的远程证明方面, TCG虚拟化平台工作组已发布了《Virtualized Trusted Platform Architecture Specification》1.0版^[6], 其中也包含了可信虚拟平台的远程证明框架, 但并没有具体实施方案.除此以外, 一些学者对此也展开了研究.文献[36]提出了一种在可信云环境中证明虚拟软件服务的框架, 通过虚拟客户机中运行一个可信测量模块, 测量平台状态值和可信平台中已经有的状态表值做对比, 来确定软件服务是否可信.这个框架可以有效地检测用户级应用的可信, 但不足的是, 没有对VMM进行可信证明.文献[37]提出一种对可信云环境中保证客户虚拟机可信的方法, 认证虚拟化架构中的可信网络接口、可信辅助存储器、可信执行环境.但是该方法中认为, 虚拟机管理操作系统是不重要的, 并不对虚拟机管理操作系统做可信验证.文献[38]针对现有虚拟机身份证明方案中身份权威信息公开问题, 提出云环境虚拟机匿名身份证明方案, 该方案可以实现对身份权威信息的隐藏, 避免位置信息暴露, 做到真正的结构透明性和位置无关.但是该文献并没有提出对平台配置信息的证明方案.文献[39]提出一种基于TrustZone的可信移动终端云服务安全接入方案, 利用ARM TrustZone硬件隔离技术构建可信移动终端, 保护云服务客户端及安全敏感操作在移动终端的安全执行.另外, 文献[40]也提出了一种可测量云环境中SaaS的可信认证框架, 该认证更强调对攻击者的精确定位.然而, 这两种架构都忽略对基础设施服务和平台服务没有提出相关的检测方法.

综上, 一方面, 对于已有的可信终端远程证明研究成果, 只能用于有一个逻辑运行实体的可信证明, 不能直接用于虚拟化平台, 因为虚拟化平台同时有多个逻辑运行实体; 另一方面, 在可信虚拟平台的远程证明方面, 尽管TCG在发布了的Virtualized Trusted Platform Architecture Specification 1.0版中有可信虚拟平台的远程证明框架, 不过该远程证明方案仅是个框架, 并没有具体实施方案, 还存在一些难以遇见的困难.而其他学者对可信虚拟平台远程证明的研究成果并不完全是TCG规范定义的可信证明, 均不能完全满足规范Virtualized Trusted Platform Architecture Specification 1.0版.

2 云环境中可信虚拟平台远程证明方案——TVP-PCA

我们提出的可信虚拟平台远程证明方案TVP-PCA实施过程如图 1所示, 该方法中共包含6个实体:挑战者、TPM、vTPM、虚拟机认证代理、虚拟机管理器认证服务、证书中心(CA).其中, 挑战者是资源请求方, 要求提供资源的一方即可信虚拟平台是可信的, 通过对可信虚拟平台请求的可信证据对其进行可信验证, 从而做出访问决策; TPM是一个具有存储功能、密码生成和管理的小型片上系统SoC(system on chip), 它作为可信计算平台的信任根, 可以为平台提供身份证明、平台度量、安全存储等; vTPM是具有和TPM相同功能的软件产品, 在虚拟化技术下, 作为虚拟机的信任根, 为虚拟机提供平台身份证明信息; 虚拟机认证代理主要负责代替vTPM向挑战者通信并提供虚拟机的可信证据, 挑战者向代理发送远程认证请求, 代理收到请求后, 转交vTPM提供的可信证据给挑战者, 完成对虚拟机的远程认证; 虚拟机管理器认证服务主要是代替TPM向挑战者通信, 并提供运行在物理平台之上的虚拟机管理器的可信证据, 挑战者向服务发送远程认证请求, 服务收到请求后, 转交TPM提供的可信证据给挑战者, 完成对运行与物理平台之上的虚拟机管理器的远程认证; 证书中心是负责为提供EK证书的TPM和vTPM颁发AIK证书, 还有为虚拟机认证代理和虚拟机管理器认证服务等可信软件颁发安全证书.

由于可信虚拟平台可以认为是两层结构:虚拟机和运行于物理平台上的虚拟机管理器.远程认证时采取自顶向下的方法, 即先对顶层的虚拟机进行远程认证, 再对运行于物理平台之上的虚拟机管理器进行远程认证.本文提出的TVP-PCA方法具体包括3个阶段:第一个阶段是完成虚拟机认证代理和虚拟机管理器认证服务的初始化(步骤1~步骤4), 虚拟机认证代理从CA处获得代理证书Cert_V, 虚拟机管理器认证服务从CA处得到服务证书Cert_S; 第二阶段是虚拟机远程证明阶段(步骤5~步骤10), 当挑战者向虚拟机认证代理提出平台远程证明请求时, 认证代理需要返回虚拟机可信证据即签名的vAIK证书和vPCR值, 代理在收到请求之后, 从vTPM获得vAIK证书和vPCR值, 其中, vAIK证书是vTPM向CA中心申请的, 代理把收到的可信证据用Cert_V签名发给挑战者, 挑战者对可信证据进行验证完成虚拟机的可信认证; 第三个阶段是运行于物理平台之上的虚拟机管理器证明阶段(步骤11~步骤16), 挑战者向虚拟机管理器认证服务提出远程认证请求时, 认证服务需要返回可信证据, 即认证服务签名的AIK证书和PCR值, 服务在收到请求之后, 从TPM获得AIK证书和PCR值, 其中, AIK证书是TPM向CA中心申请的, 服务把收到的可信证据用Cert_S签名发给挑战者, 挑战者对可信证据进行验证, 完成运行于物理平台之上的虚拟机管理器的可信认证.

下面, 我们将详细介绍初始化阶段、虚拟机远程证明阶段、运行于物理平台之上的虚拟机管理器证明阶段的证明过程.为了更加专注本文所要解决的问题, 我们作如下假设.

●    TPM和vTPM是整个虚拟平台的TCB;

●    VMAgent, VMMService和vTPM是稳定的和安全的, 它们受TPM保护, 抗恶意攻击, 对云平台或虚拟机的稳定性和安全性影响在本文中暂不考虑;

●    Challenger是诚实的, 即, 挑战方确实是想验证虚拟平台及虚拟机的可信性而发出验证请求.

2.1 初始化阶段协议

初始化阶段包括两部分.

●   其一是虚拟机认证代理的初始化, 如图 2所示, 主要功能是获取代理证书.

我们用VMAgent代表虚拟机认证代理, (K_{pub_vmAgent}, K_{pri_vmAgent})表示虚拟机认证代理的密钥对, URL_vmAgent是VMAgent的域名.具体交互过程如下.

1.  VMAgent→CA:ID_v||K_{pub_vmAgent};

2.  CA→VMAgent:Cert_V=[ID_v||K_{pub_vmAgent}||URL_vmAgent||T₀₀||Sig_{pri_CA}(ID_v||K_{pub_vmAgent}||URL_vmAgent||T₀₀)].

在步骤1中, VMAgent向CA发送证书请求, 发送的具体内容:VMAgent标识符ID_v以及VMAgent的公钥K_{pub_vmAgent}; 步骤2中, CA给虚拟机认证代理签发证书并公开, 证书中的信息有代理的标识符ID_v, K_{pub_vmAgent}, URL_vmAgent和时间戳T₀₀, 虚拟机认证代理初始化过程完成.

●   其二是虚拟机管理器认证服务初始化, 如图 3所示, 主要功能是获取认证服务证书.

我们用VMMService代表虚拟机管理器认证服务, CA表示证书中心, (K_{pub_CA}, K_{pri_ CA})标识CA用户签名验证的密钥对, (K_{pub_vmmService}, K_{pri_vmmService})表示虚拟机管理器认证服务的密钥对, URL_vmmService是VMMService的域名.具体交互过程如下.

1.  VMMService→CA:ID_s||K_{pub_vmmService};

2.  CA→VMMService:Cert_S=[ID_s||K_{pub_vmmService}||URL_vmmService||T₁₀||Sig_{pri_CA}(ID_s||K_{pub_vmmService}||URL_vmmService|| T₁₀)].

在步骤1中, VMMService向CA发送证书请求, 发送的具体内容:VMMService标识符ID_s以及VMMService的公钥K_{pub_vmmService}; 步骤2中, CA给虚拟机管理器认证服务签发证书并公开.Cert_S中的信息有认证服务的标识符ID_s, K_{pub_ vmmService}, URL_vmmService和时间戳T₁₀.至此, 虚拟机管理器认证服务初始化过程完成.

2.2 顶层虚拟机远程证明阶段协议

虚拟机远程证明阶段可以分为两个部分:其一是虚拟机向挑战者提供可信证明信息; 其二是挑战者对可信证据进行验证, 做出访问决策.

第1部分虚拟机向挑战者提供可信证明, 即, 虚拟机认证代理收集证明信息并交给挑战者.我们用Challenger代表挑战者, VMAgent代表虚拟机认证代理, vTPM代表虚拟机的可信平台模块, Cert_vEK表示vEK证书, K_s0是由Challenger选定的对称密钥, 用于和VMAgent之间的保密通信, (K_{pub_vAIK}, K_{pri_vAIK})表示vTPM的vAIK密钥对, Cert_vAIK表示vAIK证书, T₀₁是一个时间戳, vPCRs表示vTPM寄存器中的值, Challenger和VMAgent双方选择素数q以及q的一个原根a.为了方便协议叙述, Sig表示签名算法, Ver表示验证算法, 如图 4所示.

具体过程交互如下.

1.  Challenger→CA:ID_c||Y_c0, 其中, ${Y_{c0}} = {a^{{X_{c0}}}}$mod q, X_c0是Challenger的任选素数, X_c0 < q;

2.  CA→VMAgent:ID_c||Y_c0||Sig_{pri_CA}(ID_c||Y_c0).VMAgent验证CA对Challenger的签名Ver_{pub_CA}(Sig_{pri_CA}(ID_c||Y_c0)), 然后任选素数X_v0, 且X_v0 < q, 并计算${K_{s0}} = Y_{c0}^{{X_{v0}}}$mod q;

3.  VMAgent→CA:ID_v||Y_v0, 其中, ${Y_{v0}} = {a^{{X_{v0}}}}$mod q;

4.  CA→Challenger:ID_v||Y_v0||Sig_{pri_CA}(ID_v||Y_v0).

Challenger验证CA对VMAgent的签名Ver_{pub_CA}(Sig_{pri_CA}(ID_v||Y_v0)), 并计算${K_{s0}} = Y_{v0}^{{X_{c0}}}$mod q;

5.  Challenger→VMAgent:${E_{{K_{s0}}}}$(ID_c||N₀₁), VMAgent用K_s0解密得到ID_c, N₀₁;

6.  VMAgent→vTPM:ID_v||N₀₂||$Si{g_{Cer{t_V}}}$(ID_v||N₀₂), vTPM验证VMAgent的签名:

$ Ve{r_{pub\_vmAgent}}(Si{g_{Cer{t_V}}}(ID_v||{N_{02}})); $

7.  vTPM→CA:ID_vTPM||K_{pub_vAIK}||ID_v||N₀₃||$Si{g_{Cer{t_{vEK}}}}$(ID_vTPM||K_{pub_vAIK}||ID_v||N₀₃), CA验证vEK证书对信息的签名Ver_{pub_vEK}($Si{g_{Cer{t_{vEK}}}}$(ID_vTPM||K_{pub_vAIK}||ID_v||N₀₃));

8.  CA→vTPM:N₀₃||Sig_{pri_CA}(N₀₃)||Cert_vAIK, 其中:

$ Cer{t_{vAIK}} = [{K_{pub\_vAIK}}||I{D_{vTPM}}||{T_{01}}, Si{g_{pri\_CA}}({K_{pub\_vAIK}}||I{D_{vTPM}}||{T_{01}})], $

vTPM验证CA对N₀₃的签名Ver_{pub_CA}(Sig_{pri_CA}(N₀₃)), vTPM验证CA对vAIK证书的签名:

$ Ve{r_{pub\_CA}}(Si{g_{pri\_CA}}({K_{pub\_vAIK}}||I{D_{vTPM}}||{T_{01}})); $

9.  vTPM→VMAgent:vPCRs||N₀₂||$Si{g_{Cer{t_{vAIK}}}}$(vPCRs||N₀₂)||Cert_vAIK, VMAgent验证vAIK证书对信息的签名:

$ Ve{r_{pub\_vAIK}}(Si{g_{Cer{t_{vAIK}}}}(vPCRs||{N_{02}})); $

10.  VMAgent→Challenger:${E_{{K_{s0}}}}$(vPCRs||$Si{g_{Cer{t_{vAIK}}}}$(vPCRs)||Cert_vAIK||ID_v||vmFlag==1||N₀₁), 用K_s0解密信息, Challenger验证vAIK证书对vPCRs的签名Ver_{pub_vAIK}($Si{g_{Cer{t_{vAIK}}}}$(vPCRs));

下面, 我们对上述每一步进行详细解释.具体如下.

步骤 1. Challenge向CA发送请求信息, 发送的具体内容有:Challenge的标识符ID_c、公开秘钥Y_c0, 其中, ${Y_{c0}} = {a^{{X_{c0}}}}$mod q, X_c0是Challenger的任选素数, X_c0 < q;

步骤 2. CA向VMAgent转发请求信息, 发送的具体内容有:ID_c、Y_c0以及CA的签名Sig_{pri_CA}(ID_c||Y_c0).VMAgent收到信息后, 验证CA对Challenger的签名Ver_{pub_CA}(Sig_{pri_CA}(ID_c||Y_c0)), 然后任选素数X_v0, 且X_v0 < q, 并计算:

$ {K_{s0}} = Y_{c0}^{{X_{v0}}}{\rm{mod}}\ q; $

步骤 3. VMAgent向CA发送请求信息, 发送的具体内容有:VMAgent标识符ID_v, Y_v0, 其中, ${Y_{v0}} = {a^{{X_{v0}}}}$mod q;

步骤 4. CA向Challenger转发请求信息, 发送的具体内容包括:ID_v、Y_v0以及CA的签名Sig_{pri_CA}(ID_v||Y_v0). Challenger验证CA对VMAgent的签名Ver_{pub_CA}(Sig_{pri_CA}(ID_v||Y_v0)), 并计算${K_{s0}} = Y_{v0}^{{X_{c0}}}$mod q;

经过前面4步, Challenger和VMAgent之间获得一个共享的秘密密钥K_s0.这4步实际上是能防止中间人攻击的Diffle-Hellman算法.

步骤 5. Challenger用通信秘钥K_s0加密向VMAgent请求远程认证, 加密发送信息的具体内容为:Challenger标识符ID_c、现时N₀₁, VMAgent用K_s0解密获得信息内容;

步骤 6. VMAgent向vTPM发出可信证据信息请求, 发送的具体内容有:VMAgent标识符ID_v、现时N₀₂以及VMAgent证书Cert_V对信息的签名$Si{g_{Cer{t_V}}}$(ID_v||N₀₂), vTPM收到信息后验证VMAgent的签名:

$ Ve{r_{pub\_vmAgent}}(Si{g_{Cer{t_V}}}(I{D_v}||{N_{02}})); $

步骤 7. vTPM向CA中心发送vAIK证书请求, 发送的具体内容有:vTPM标识符ID_vTPM、vAIK公钥K_{pub_vAIK}、VMAgent标识符ID_v、现时N₃及用vEK证书对信息的签名$Si{g_{Cer{t_{vEK}}}}$(ID_vTPM||K_{pub_vAIK}||ID_v||N₀₃), CA验证消息:

$ Ve{r_{pub\_vEK}}(Si{g_{Cer{t_{vEK}}}}(I{D_{vTPM}}||{K_{pub\_vAIK}}||I{D_v}||{N_{03}})); $

步骤 8. CA为vTPM生成vAIK证书Cert_vAIK并公开, Cert_vAIK具体内容有:ID_vTPM、K_{pub_vAIK}、时间戳T₀₁以及CA的签名Sig_{pri_CA}(K_{pub_vAIK}||ID_vTPM||T₀₁), CA中心向vTPM返回信息, 信息的具体内容为:现时N₀₃及CA的签名Sig_{pri_CA}(N₀₃)和vAIK证书Cert_vAIK, vTPM验证CA对vAIK证书的签名Ver_{pub_CA}(Sig_{pri_CA}(K_{pub_vAIK}||ID_vTPM||T₀₁))和CA对现时的签名Ver_{pub_CA}(Sig_{pri_CA}(N₀₃));

步骤 9. vTPM把收到的现时N₀₃和vTPM之前向CA发送请求时的现时N₀₃进行匹配, 如果匹配成功, 发送可信证据信息给VMAgent, 发送的具体内容有:vPCRs、现时N₀₂及vAIK对vPCRs的签名Sig_CertvAIK(vPCRs||N₀₂), VMAgent验证vTPM对信息的签名Ver_{pub_vAIK}(Sig_CertvAIK(vPCRs||N₀₂));

步骤 10. VMAgent收到信息后, 把收到的现时N₀₂和VMAgent之前向vTPM发送请求时的现时N₀₂进行匹配, 如果匹配成功, 就用通信秘钥K_s0加密可信证据信息发送给Challenger, 加密的可信证据信息内容有:vPCRs及Sig_CertvAIK(vPCRs)、VMAgent标识符ID_v、值为1的虚拟机标识符vmFlag、URLvmmService、现时N₀₁等.

第2部分是Challenger接收到VMAgent的返回值, 用K_s0解密得到这些信息.首先把收到的现时N₀₁和Challenger之前向VMAgent发送请求时的现时N₀₁进行匹配, 如果匹配成功, 则挑战者验证CA对vAIK证书的签名Ver_{pub_CA}(Sig_{pri_CA}(K_{pub_vAIK}||ID_vTPM||T₀₁)), 再用vAIK证书对验证vPCRs的签名Ver_{pub_vAIK}(Sig_CertvAIK(vPCRs|| N₀₂)), 最后根据vPCRs值做出对虚拟机可信决策.

对于此阶段, 有两个非常重要的关键点必须说明.

(1) Challenger如何确定对方是虚拟平台.当Challenger发送出的请求被VMAgent接收, 返回的信息中如果虚拟机标识符vmFlag的值为1, 则代表对方为虚拟机平台; 反之, 则为物理平台.如果对方是虚拟机平台, 要确保真正可信需要进一步证明该虚拟机所在的虚拟机管理器和物理平台是可信的;

(2) 如何确定虚拟机管理器所在平台的远程认证服务地址.当vmFlag的值为1时, 表明Challenger当前验证的是虚拟机, 按照设计的流程, Challenger应该继续验证运行于物理平台之上的虚拟机管理器, 因此, Challenger从公开的虚拟机管理器认证服务证书Cert_S中获得地址URL_vmmService, 通过该地址, 完成对运行于物理平台之上的虚拟机管理器进行远程认证.

2.3 底层运行于物理平台之上的虚拟机管理器证明阶段协议

运行于物理平台之上的虚拟机管理器证明阶段也可以分为两个部分:其一是运行于物理平台之上的虚拟机管理器向挑战者提供可信证明信息; 其二是挑战者对可信证据进行验证, 做出访问决策.

第1步运行于物理平台之上的虚拟机管理器向挑战者提供可信证明, 即, 虚拟机管理器认证服务收集信息并交给挑战者.我们用VMMService代表虚拟机管理器认证服务, K_S1是由挑战者选定的对称密钥, 用于和VMMService之间的保密通信, (K_{pub_vmmService}, K_{pri_vmmService})表示虚拟机管理器认证服务的密钥对, TPM代表可信平台模块, (K_{pub_EK}, K_{pri_EK})表示TPM的EK密钥对, Cert_EK表示EK证书, (K_{pub_AIK}, K_{pri_AIK})表示TPM的AIK密钥对, Cert_AIK表示AIK证书, T₁₁是一个时间戳, PCRs表示TPM寄存器中的值.Challenger和VMMService双方选择素数q₁以及q₁的一个原根a₁.如图 5所示:

具体过程交互如下。

1. Challenger→CA:ID_c||Y_c1, 其中, ${Y_{c1}} = a_1^{{X_{c1}}}$mod q₁, X_c1是Challenger的任选素数, X_c1 < q₁;

2. CA→VMMService:ID_c||Y_c1||Sig_{pri_CA}(ID_c||Y_c1).VMMService验证CA对Challenger的签名Ver_{pub_CA}(Sig_{pri_CA} (ID_c||Y_c1)), 然后任选素数X_s1, 且X_s1 < q₁, 并计算${K_{S1}} = Y_{c1}^{{X_{s1}}}$mod q₁;

3. VMMService→CA:ID_s||Y_s1, 其中, ${Y_{s1}} = a_1^{{X_{s1}}}$mod q₁;

4. CA→Challenger:ID_s||Y_s1||Sig_{pri_CA}(ID_s||Y_s1).Challenger验证CA对VMMService的签名Ver_{pub_CA}(Sig_{pri_CA} (ID_s||Y_s1)), 并计算${K_{s1}} = Y_{s1}^{{X_{c1}}}$mod q₁;

5. Challenger→VMMService:${E_{{K_{s1}}}}$(ID_c||N₁₁), VMMService用K_s1解密得到ID_c, N₁₁;

6. VMMService→TPM:ID_s||N₁₂||$Si{g_{Cer{t_S}}}$(ID_s||N₁₂), TPM验证VMMService的签名:

$ Ve{r_{pub\_vmmService}}(Si{g_{Cer{t_S}}}(I{D_s}||{N_{12}})); $

7. TPM→CA:ID_TPM||K_{pub_AIK}||ID_s||N₁₃||$Si{g_{Cer{t_{EK}}}}$(ID_TPM||K_{pub_AIK}||ID_s||N₁₃), CA验证EK证书对信息的签名:

$ Ve{r_{pub\_EK}}(Si{g_{Cer{t_{EK}}}}(I{D_{TPM}}||{K_{pub\_AIK}}||I{D_s}||{N_{13}})); $

8. CA→TPM:N₁₃||Sig_{pri_CA}(N₁₃)||Cert_AIK, 其中, Cert_AIK=[K_{pub_AIK}||ID_TPM||T₁₁, Sig_{pri_CA}(K_{pub_AIK}||ID_TPM||T₁₁)], TPM验证CA对N₁₃的签名Ver_{pub_CA}(Sig_{pri_CA}(N₁₃)), TPM验证CA对AIK证书的签名:

$ Ve{r_{pub\_CA}}(Si{g_{pri\_CA}}({K_{pub\_AIK}}||I{D_{TPM}}||{T_{11}})); $

9. TPM→VMMService:PCRs||N₁₂||$Si{g_{Cer{t_{AIK}}}}$(PCRs||N₁₂)||Cert_AIK, VMMService验证AIK证书对信息的签名:

$ Ve{r_{pub\_AIK}}(Si{g_{Cer{t_{AIK}}}}(PCRs||{N_{12}})); $

10. VMMService→Challenger:${E_{{K_{s1}}}}$(PCRs||Sig_CertAIK(PCRs)||Cert_AIK||ID_s||vmFlag==0||N₁₁), 用K_s1解密信息, Challenger验证签名Ver_{pub_AIK}||(Sig_{Cert AIK}(PCRs)).

下面, 我们对上述每一步进行详细解释.具体如下。

步骤 1. Challenger向CA发送请求信息, 发送的具体内容有:Challenger的标识符ID_c, Y_c1, 其中, ${Y_{c1}} = a_1^{{X_{c1}}}$mod q₁, X_c1是Challenger的任选素数, X_c1 < q₁;

步骤 2. CA向VMMService发送Challenge标识符ID_c、公开秘钥Y_c1, 发送的具体内容有:ID_c, Y_c1以及CA的签名Sig_{pri_CA}(ID_c||Y_c1), VMMService收到信息后, 验证CA对Challenger的签名Ver_{pub_CA}(Sig_{pri_CA}(ID_c||Y_c1)), 然后任选素数X_s1, 且X_s1 < q₁, 并计算${K_{s1}} = Y_{c1}^{{X_{s1}}}$mod q₁;

步骤 3. VMMService向CA发送请求信息, 发送的具体内容有:VMMService标识符ID_s, Y_s1, 其中:

$ {Y_{s1}} = a_1^{{X_{s1}}}{\rm{mod}}\;{q_1}; $

步骤 4. CA向Challenger返回VMMService标识符ID_s, Y_s1以及CA的签名Sig_{pri_CA}(ID_s||Y_s1), Challenger验证CA对VMMService的签名Ver_{pub_CA}(Sig_{pri_CA}(ID_s||Y_s1)), 并计算${K_{s1}} = Y_{s1}^{{X_{c1}}}$mod q₁;

经过前面4步, Challenger和VMMService之间获得一个共享的秘密密钥K_s1.这4步实际上是能防止中间人攻击的Diffle-Hellman算法.

步骤 5. Challenger用秘钥K_s1加密向VMMService发送的远程认证请求, 加密的具体内容为:Challenger标识符ID_c、现时N₁₁, VMMService用K_s1解密获得信息内容;

步骤 6. VMMService向TPM发出可信证据信息请求, 发送的具体内容有:VMMService标识符ID_s、现时N₁₂ 及VMMService对信息的签名$Si{g_{Cer{t_S}}}$(ID_s||N₁₂), TPM收到信息后, 验证VMMService的签名:

$ Ve{r_{pub\_{\rm{vmmService}}}}(Si{g_{Cer{t_S}}}(I{D_s}||{N_{12}})); $

步骤 7. TPM向CA中心发送AIK证书请求, 发送的具体内容有:TPM标识符ID_TPM、AIK公钥K_{pub_AIK}、VMMService标识符ID_s、现时N₁₃及用EK证书对信息的签名$Si{g_{Cer{t_{EK}}}}$(ID_TPM||K_{pub_AIK}||ID_s||N₁₃), CA验证EK证书签名的消息Ver_{pub_EK}($Si{g_{Cer{t_{EK}}}}$(ID_TPM||K_{pub_AIK}||ID_s||N₁₃));

步骤 8. CA为TPM生成AIK证书, 证书的具体内容有:ID_TPM、K_{pub_AIK}、时间戳T₁以及CA的签名Sig_{pri_CA}(K_{pub_AIK}||ID_TPM||T₁₁), CA中心向TPM返回信息, 信息的具体内容为:现时N₁₃、CA的签名Sig_{pri_CA}(N₁₃)和AIK证书Cert_AIK, TPM验证CA对AIK证书的签名Ver_{pub_CA}(Sig_{pri_CA}(K_{pub_AIK}||ID_TPM||T₁₁))和CA对现时的签名Ver_{pub_CA}(Sig_{pri_CA}(N₁₃));

步骤 9. TPM把收到的现时N₁₃和TPM之前向CA发送的现时N₁₃进行匹配, 如果匹配成功, 发送可信证据给VMMService, 发送的具体内容有:PCRs、现时N₁₂和AIK证书及AIK证书对PCRs的签名$Si{g_{Cer{t_{AIK}}}}$(PCRs||N₁₂), VMMService验证TPM对信息的签名Ver_{pub_AIK}(Sig_CertAIK(PCRs||N₁₂));

步骤 10. VMMService收到信息后, 把收到的现时N₁₂和VMMService之前向TPM发送的现时N₁₂进行匹配, 如果匹配成功, 就用通信秘钥K_s1加密可信证据信息发送给Challenger, 加密的可信证据信息内容有:PCRs及Sig_CertAIK(PCRs)、AIK证书、VMMService标识符ID_s、值为0的虚拟机标识符vmFlag、现时N₁₁等, Challenger用K_s1解密得到信息.

第2部分是Challenger接收到VMMService的返回值, 首先, 把收到的现时N₁₁和Challenger之前向VMMService发送的现时N₁₁进行匹配, 如果匹配成功, 则Challenger验证CA对AIK证书的签名Ver_{pub_CA}(Sig_{pri_CA} (K_{pub_AIK}||ID_TPM||T₁₁)), 再验证AIK证书对PCRs的签名Ver_{pub_AIK}||(Sig_CertAIK(PCRs)).此时, 挑战者对PCRs进行验证, 从而可以进行验证运行于物理平台之上的虚拟机管理器是否可信.

至此, Challenger已经完成对虚拟机和运行于物理平台之上的虚拟机管理器的认证.

3 TVP-PCA方案的可信判定

可信虚拟平台的远程证明方案的核心是判断问题.判定依赖于具体的策略, 该策略必须与虚拟终端实际环境相吻合.因此, 必须详细分析虚拟机的信任链、虚拟机管理器的信任链, 为远程证明的判定提供基础保证.为了方便文章叙述, 我们先形式化定义软件组件、信任根集等基本概念.

定义 1. 可信虚拟平台的软件组件定义为C={C₁, C₂}, 其中, C₁表示顶层虚拟机的软件组件集, C₂表示底层运行于物理硬件上的VMM及管理域的软件组件集.

我们用C_1i表示底层虚拟机的软件组件:C_1i={(c_1i-code, c_1i-d-code, c_1i-cofile), (c_1i-f, c_1i-v, c_1i-o)}.其中,

●    (c_1i-code, c_1i-d-code, c_1i-cofile)表示C_1i的代码特征:c_1i-code代表C_1i的源代码; c_1i-d-code代表C_1i的依赖, 如其依赖的静态库、动态库或第三方代码库; c_1i-cofile代表C_1i的策略配置文件;

●    (c_1i-f, c_1i-v, c_1i-o)表示C_1i的功能特征:c_1i-f表示C_1i的功能; c_1i-v表示测C_1i的版本号; c_1i-o表示C_1i的其他相关属性, 比如软件名、开发者、发布时间等.

用C_2i表示VMM及管理域的软件组件:C_2i={(c_2i-code, c_2i-d-code, c_2i-cofile), (c_2i-f, c_2i-v, c_2i-o)}.其中,

●    (c_2i-code, c_2i-d-code, c_2i-cofile)表示VMM及管理域软件C_2i的代码特征:c_2i-code代表C_2i的源代码; c_2i-d-code代表C_2i的依赖, 如其依赖的静态库、动态库或第三方代码库; c_2i-cofile代表C_2i的策略配置文件;

●    (c_2i-f, c_2i-v, c_2i-o)表示C_2i的功能特征:c_2i-f表示C_2i的功能, c_2i-v表示测组件C_2i的版本号, c_2i-o表示软件组件C_2i的其他相关属性.

依据定义1, 顶层虚拟机的软件组件集为C₁={c₁₁, c₁₂, …, c_1n, …}, VMM及管理域的软件组件集为

$ {C_2} = \{ {c_{11}}, {c_{22}}, \ldots , {c_{2n}}, \ldots \} . $

定义 2. 信任根集(trustedroot set)定义为TRS={TRS₁, TRS₂}, 其中, TRS₁是顶层虚拟机的信任根集, TRS₂是底层运行于物理硬件上的VMM及管理域的信任根集.信任根集为一个由特殊属性组成的集合, 包含所有其可信性无需进行证明的属性, 所以, TRS₁={vTPM}, TRS₂={TPM}.

定义 3. 完整性测量组件集定义为I={I₁, I₂}, 其中,

●    I₁是顶层虚拟机的完整性测量组件集, I₁={i₁₁, i₁₂, …, i_1n, …}, 其中, i_1n∈C₁;

●    I₂是底层运行于物理硬件上的VMM及管理域的完整性测量组件集, I₂={i₂₁, i₂₂, …, i_2n, …}, 其中, i_2n∈C₂.

定义 4.  Measure(i_n, i_n+1, PCR_n+1, SML_n+1)表示在完整性测量过程中, i_n对i_n+1的完整性进行测量, 其增量哈希值存储于PCR_n+1, 相对应的存储测量值日志为SML_n+1, n是正整数且0≤n≤23.当顶层虚拟机进行完整性测量时, 将哈希值存储在vPCR中, 对应的测量值日志存在vSML中, 当底层运行于物理硬件上的VMM及管理域进行完整性测量时, 将哈希值存储在PCR中, 对应的测量值日志存在SML中.

定义 5. 完整性验证函数Verify(i_n, i_n+1, PCR_n+1, LPCR_n+1)表示将i_n对i_n+1的完整性测量值PCR_n+1与可信策略库中对应的标准LPCR_n+1进行比较.当顶层虚拟机进行完整性验证时, 将PCR中的值和LPCR中的值对比:如果完全匹配, 返回TRUE; 否则, 返回FALSE.类似的, 当底层运行于物理硬件上的VMM及管理域进行完整性验证时, 将vPCR中的值和vLPCR中的值对比:如果完全匹配, 返回TRUE; 否则, 返回FALSE.

定义 6. 完整性传递函数Integrity(i_n, i_n+1)表示完整性能够从i_n有效地传递至i_n+1, 而不遭受破坏与损失.当顶层虚拟机进行完整性传递时, 将从i_1n有效地传递至i_1n+1, 而不遭受破坏与损失; 当底层运行于物理硬件上的VMM及管理域进行完整性验证时, 将从i_2n有效地传递至i_2n+1, 而不遭受破坏与损失.

3.1 顶层证明的可信判定

顶层证明是证明运行于虚拟机管理器之上的虚拟机的可信, 实质是指虚拟机满足基于完整性测量的虚拟机信任链传递.为了保证VMAgent可信, 我们扩展虚拟机的信任传递过程为:INIT→vBIOS→VMOS Loader→ VMOS→VMAgent→Application.如图 6所示, 该信任链将VMAgent作为可信平台链式度量的重要一环.这种方式是可行的, VMAgent的度量可由VMOS主导完成, 并由VMOS将VMAgent程序作为第1个应用程序首先启动.

在图 6中, 实现信任传递的相关参数主要包括:

(1) 系统配置:将完整性测量组件的哈希值存入vTPM的24个vPCR中;

(2) 虚拟机存储测量值日志(VM storage measurement log, 简称vSML), 其中包含了存储在vTPM中的所有测量值的事件结构以及被测量的软件组件的(c_1i-f, c_1i-v, c_1i-o).

由图 6可知, 虚拟机完整性测量组件集I₁={INIT, vBIOS, VMOSLoader, VMOS Kernel, VMAgent, Applications}, 显然, I₁⊂C₁.

根据以上分析, 我们得出顶层虚拟机的判定算法, 如图 7所示.图 7算法首先判断信任根集是不是空, 然后判断信任根集里TRS₁信任根是不是唯一.如果这两个条件均成立, 则调用Measure函数对INIT→vBIOS→VMOS Loader→VMOS→VMAgent→Application进行完整性测量, 并调用完整性验证函数Verify进行验证, 如果成立, 则调用Integrity进行完整性可信传递:如果最后完整性验证都通过, 则输出TRUE; 否则, 输出FALSE.

3.2 底层证明的可信判定

底层证明是证明虚拟机管理器的可信, 实质是指运行在物理设备之上的虚拟机管理器满足基于完整性测量的虚拟机管理器的信任链传递.在底层证明过程中, 虚拟机证明代理VMMService运行在虚拟机管理器之上, 起着非常重要的作用.为了保证VMMService可信, 我们扩展虚拟机的信任传递过程为CRTM→BIOS→OS Loader→OS→VMMService→Application.如图 8所示, 将VMMService作为可信平台链式度量的重要一环.这种方式是可行的, VMMService的度量可由OS主导完成, 并由OS将VMMService程序作为第1个应用程序首先启动.

在图 8中, 实现信任传递的相关参数主要包括:

(1) 系统配置:将完整性测量组件的哈希值存入TPM的24个PCR中;

(2) 存储测量值日志(storage measurement log, 简称SML), 其中包含了存储在TPM中的所有测量值的事件结构以及被测量的软件组件的(c_2i-f, c_2i-v, c_2i-o).

由图 8可知, 虚拟机管理器的完整性测量组件集I₂={CRTM, BIOS, OS Loader, OS Kernel, VMMService, Applications}.显然, I₂⊂C₂.

根据以上分析, 我们得出底层虚拟机管理器的判定算法, 如图 9所示.图 9算法首先判断信任根集是不是空, 然后判断信任根集里TRS₂信任根是不是唯一.如果这两个条件均成立, 则调用measure函数对CRTM→BIOS→ OS Loader→OS→VMMService→Application进行完整性测量, 并调用完整性验证函数Verify进行验证, 如果成立, 则调用Integrity进行完整性可信传递:如果最后完整性验证都通过, 则输出TRUE; 否则, 输出FALSE.

3.3 同一性可信判定

按照本文第2节设计的证明方案, 要证明整个虚拟平台的可信, 需要首先证明顶层虚拟机的可信, 然后证明底层物理平台上的虚拟机管理器的可信.在两个相对独立的逻辑运行实体上分阶段证明容易造成同一性问题, 即, 第一阶段的证明和第二阶段的证明是否是同一虚拟平台或同一物理平台.TCG虚拟化平台工作组在规范《Virtualized Trusted Platform Architecture Specification》1.0版中也明确指出这一问题.

定义 7. 可信虚拟平台远程证明的同一性问题, 是指顶层可信虚拟机的远程证明和底层可信虚拟机管理器的远程证明是否属于同一虚拟平台或同一物理平台.

同一性问题在可信虚拟平台远程证明中确实可能存在, 因为按照TVP-PCA方案, 当挑战者完成与顶层虚拟机交互证明后, 可能会获得下一阶段的伪冒VMMService域名URL_vmmService.在此, 我们可以假设如下3种情况.

情况1:有两个虚拟平台1和2, 均具有物理TPM, 虚拟机均含有vTPM.当挑战者按照TVP-PCA方案在验证虚拟平台1时, 虚拟平台1的VMAgent故意返回虚拟平台2的VMMService域名URL_vmmService.挑战者完成两阶段交互证明.

对于情况1, 我们认为是不必要考虑的.因为虚拟平台1本身就是可信的, 没有必要借助虚拟平台2来证明自己可信.

情况2:有两个虚拟平台1和2, 虚拟平台1无物理TPM, 但其虚拟机均含有vTPM; 虚拟平台2具有物理TPM, 其虚拟机也含有vTPM.当挑战者按照TVP-PCA方案在验证虚拟平台1时, 虚拟平台1的VMAgent返回的是虚拟平台2的VMMService域名URL_vmmService.挑战者也能顺利完成两阶段交互证明.具体如图 10所示.

为了防止这两种情况的发生, 我们提出信任链判定法.所谓信任链判定法就是通过在底层信任链和顶层信任链之间建立度量联系来判定同一性问题.根据图 6和图 8, 我们定义两条信任链的度量联系如下.

定义 8. 度量联系是指底层信任链的最后一个PCR值扩展到顶层信任链, 即满足等式:

$vPCR[0] = = Hash(PCR[last]||INIT). $

其中, vPCR[0]是顶层虚拟机信任链的第一个度量值, PCR[last]是底层信任链的最后一个度量值, INIT是顶层虚拟机的第一个被度量的组件.

根据以上分析, 我们得出同一性问题的信任链判定算法, 如图 11所示.

值得注意的是, 信任链判定算法只是一个必要条件, 即:Trusted_Chain(PCR[last], INIT)返回FALSE, 则顶层证明和底层证明一定存在同一性问题; 反之则不成立.下列的情况3可以说明这一点.

情况3:有两个虚拟平台1和2, 虚拟平台1无物理TPM, 但其虚拟机均含有vTPM; 虚拟平台2具有物理TPM, 其虚拟机含有vTPM.为了欺骗挑战者, 虚拟平台1事先作为挑战者对虚拟平台2进行验证, 获得虚拟平台2的PCR和域名, 并按度量联系重构顶层虚拟机信任链.之后, 虚拟平台1重复情况2的过程.挑战者也能顺利完成两阶段交互证明, 并成功通过信任链判定算法的检测.具体如图 12所示.

为了防止这种情况的发生, 我们提出MAC地址判定法.所谓MAC地址判定法, 就是通过在底层交互证明和顶层交互证明中传递数据包的MAC地址是否相同来判定同一性问题.从图 12可以看出:Challenger在进行顶层证明时的数据来源于虚拟平台1, 在进行底层证明时的数据来源于虚拟平台2, 两阶段接收的数据包的MAC地址一定是不同的.了便于叙述, 我们定义MAC解析函数.

定义 9.  MAC_Parser是MAC地址解析函数, 其函数原型为:mac_address MAC_Parser(send, recieve), 其中, 函数名是MAC_Parser, mac_address是返回类型.该函数需要两个输入参数:其一, send代表发送方; 其二, receive代表接受方.

根据以上分析, 我们得出同一性问题的MAC地址判定算法, 如图 13所示.

值得注意的是, 我们之所以没有采用两阶段接收数据包的IP地址来辨析情况3, 主要包括两方面原因:其一是虚拟平台的网络地址模式比较多, 容易发生混淆; 其二是通过IP地址无法判断两个阶段接收的数据是否来自同一虚拟平台.

3.4 TVP-PCA方案的可信判定算法

根据顶层证明的可信判定、底层证明的可信判定和同一性可信判定, 我们得出TVP-PCA方案总的可信判定算法.如图 14所示.

值得注意的是:其实无论是情况2还是情况3, 我们都可以直接采用MAC地址判定算法就能判定同一性问题.但由于信任链判判定算法的效率比MAC地址判别法的效率高, 所以在算法5中, 我们仍然先采用信任链判判定算法对同一性问题进行判定.如果Challenger在两阶段接收到的数据不满足信任链判判定算法, 直接返回FALSE, 就没有必要再采用MAC地址判定算法进行判定了, 可以提高算法5的效率.

4 TVP-PCA的特点和安全性分析 4.1 TVP-PCA的特点分析

(1) 一致性.对于虚拟平台的远程认证, TCG虚拟化平台工作组已发布了《Virtualized Trusted Platform Architecture Specification》1.0版中的认证思想是:通过两次认证, 包括顶层虚拟机认证阶段和底层虚拟机管理器和物理平台认证阶段.本文提出的TVP-PCA方案与TCG提出的方法具有一致性.

(2) 灵活性.如果挑战者请求虚拟机上的资源或服务, 需要先对虚拟机进行认证, 再对虚拟机管理器和物理平台进行认证; 如果挑战者请求虚拟机管理器上的资源或服务, 则可以只对虚拟机管理器和物理平台进行认证.

4.2 TVP-PCA的安全性分析

我们提出的方案TVP-PCA具有机密性、抗中间人攻击和抗重放攻击, 因而具有较高的安全性.对于本文提出的方法进行安全性分析, 具有以下3点.

(1) 具有机密性.

在顶层虚拟机远程认证阶段, Challenger和VMAgent之间的通信, 无论是Challenger向VMAgent发送远程证明请求信息, 还是VMAgent返回可信证据, 都用对称秘密密钥K_s0加密, 如果信息被截取, 攻击者会由于没有对称秘密密钥K_s0而无法获得信息的具体内容, 由此确保Challenger和VMAgent的通信安全.在底层远程认证阶段, Challenger和VMMService之间的通信, 无论是Challenger向VMMService发送远程证明请求信息, 还是VMMService返回可信证据, 都用对称秘密密钥K_s1加密, 如果信息被截取, 攻击者会由于没有对称秘密密钥K_s1而无法获得信息的具体内容, 由此确保Challenger和VMMService的通信安全.

(2) 具有抗中间人攻击.

中间人攻击是一种通过修改或者伪装发送消息而达到攻击目的的手段.首先, 在顶层远程认证阶段对称加密密钥K_s0的产生, 我们采用的是抗中间人攻击的DH协议, Challenger生成对称加密密钥K_s0所需要的Y_c0以及VMAgent生成对称加密密钥K_s0所需要的Y_v0均是通过CA签名交互, 中间人无法伪造和替换; 其次, 在底层远程认证阶段对称加密密钥K_s1的产生, 我们同样采用的是抗中间人攻击的DH协议, Challenger生成对称加密密钥K_s1所需要的Y_c1以及VMMService生成对称加密密钥K_s1所需要的Y_s1均是通过CA签名交互, 中间人同样无法伪造和替换; 第三, Challenger, VMAgent, vTPM, VMMService, TPM和CA等之间通信都是经过证书签名或加密的, 证书具有身份认证功能, 中间人无法伪造.

(3) 具有抗重放攻击.

在顶层认证阶段, Challenger向VMAgent发送信息中包含现时N₀₁, VMAgent返回的信息中也必须包含N₀₁, 所以Challenger可以通过对比N₀₁来确保不是重放信息; 同样, VMAgent向vTPM发送信息中包含现时N₀₂, vTPM返回的信息中也包含N₀₂, VMAgent通过对比N₀₂来确保不是重放信息; vTPM向CA发送信息中包含现时N₀₃, CA返回的信息中也包含N₀₃, vTPM通过对比N₀₃来确保不是重放信息.所以在顶层认证阶段是可以抗重放攻击的.在底层远程认证阶段, Challenger向VMMService发送信息中包含现时N₁₁, VMMService返回的信息中也必须包含N₁₁, 所以Challenger可以通过对比N₁₁来确保不是重放信息; 同样, VMMService向TPM发送信息中包含现时N₁₂, vTPM返回的信息中也包含N₁₂, VMMService通过对比N₁₂来确保不是重放信息; TPM向CA发送信息中包含现时N₁₃, CA返回的信息中也包含N₁₃, TPM通过对比N₁₃来确保不是重放信息.所以在底层认证阶段是可以抗重放攻击的.综上, 可以确保整个TVP-PCA方案的可以抗重放攻击的.

(4) 具有同一性.

本方案最大的特点之一, 就是解决了可信虚拟平台远程认证的同一性问题.我们通过信任链判定算法和MAC地址判定算法确定顶层远程证明和底层远程证明是否属于同一虚拟平台或同一物理平台.

5 基于XEN环境的TVP-PCA实验原型分析

该实验一共使用3台计算机.一台为普通PC机, CPU是Inter(R) Core(TM)2 Duo CPU E7500@2.93GHz, 内存4G, 虚拟机管理器是Xen 4.1.6.1, Dom0操作系统为Ubuntu 12.04.1LTS(内核3.2.0.29), DomU操作系统为Ubuntu 12.04.1LTS(内核3.2.0.29).在Dom0上运行虚拟机管理器认证服务VMMService, 在DomU上运行虚拟机认证代理VMAgent, TPM芯片用TPM模拟器代替, 具体为tpm_emulator-0.7.4.另外还有一台普通PC机做为挑战者Challenger, CPU是Inter(R) Core(TM)2 Duo CPU E7500@2.93GHz, 内存2G, 操作系统为Microsoft Windows 7 SP1.最后还有一台为服务器, 做为CA证书中心, CPU是Inter(R) Core(TM)2 Duo CPU E7500@2.93GHz, 内存2G, 操作系统为Windows Server 2008.具体如图 15所示.挑战者需要通过VMAgent提供的可信证据来证明DomU的可信, 通过VMMService提供的证据是证明VMM和Physical platform的可信, 从而确定整个虚拟平台的可信.在图 15中:Challenger是一个用java实现的代理进程, 可跨平台运行, 满足挑战者的多样性; VMAgent是一个基于vmlinuz的DomU内的守护进程, 配置的监听2020端口; VMMService是一个基于vmlinuz的Dom0内的守护进程, 配置的监听2021端口; vTPM是一个模拟实现, 采用的是TPM-emulator 0.7.4.所有其他实体与vTPM交互均通过vTPM manager, 这一点我们沿用Xen的方式.CA是用openssl模拟实现的, 配置的监听2022端口.鉴于篇幅, 我们将另外撰文介绍Challenger, VMAgent和VMMService的设计与实现.以下的实验结果均基于我们实现的Challenger, VMAgent和VMMService原型

5.1 实验结果

VMAgent和VMMService先按照本文3.1中介绍的方法进行初始化, Challenger远程认证虚拟平台时, 先按照第3.2节中介绍的方法通过VMAgent远程认证DomU, 再按照第3.3节中介绍的方法通过VMMService远程认证VMM和PhysicalPlatform.特别说明的是, 在顶层证明阶段Challenger和VMAgent双方选择的乘法群$Z_q^*$的素数q以及在底层证明阶段Challenger和VMMService双方选择的乘法群$Z_q^*$的素数q的大小很关键, 太小不安全, 太大又影响性能.根据参考文献[41, 42], q的范围可为150≤|q|≤180, |q|表示q的十进制位数.本文在编程实现时, q均取为150位的十进制数且q-1必须有一个大素数因子.X_c0和X_c1比q略小, 而且q, X_c0和X_c1用Miller-Rabin算法测试进行了素性测试^[43].如图 16为虚拟机认证代理VMAgent初始化运行结果图, 图 17为虚拟机管理器认证服务VMMService初始化运行结果图.

顶层远程认证阶段, Challenger和VMAgent通过交互来认证虚拟机的可信, 图 18为Challenger运行结果图, 图 19为VMAgent运行结果图.

底层远程认证阶段, Challenger和VMMService通过交互来认证运行于物理平台的虚拟机管理器的可信, 图 20为挑战者运行结果图, 图 21为虚拟机管理器认证服务运行结果图.

Challenger通过和VMAgent, VMMService的远程证明过程, 已经获得了虚拟机和运行在物理平台之上的虚拟机管理器的可信证据.最后, Challenger通过可信判定算法判定虚拟平台是否可信.图 22为Challenger的判定结果图.

5.2 TVP-PCA方法的性能分析

初始化过程VMAgent和VMMService分别与CA交互申请证书共需0.6s.虚拟机远程认证阶段共需耗时1.6s, 其中包括实体间信息传递和每次交互信息的现时验证共1.58s, vTPM读取vPCR值执行vPCRExtend和vPCRRead共0.02s, 虚拟机从虚拟机管理器证书中获取VMMService地址和Challenger与VMAgent通信时加解密所费时间极少对系统可以忽略不计.虚拟机管理器远程认证阶段和虚拟机远程证明阶段实体间操作过程相同, 所以耗时也为1.6s.最后, 挑战者进行可信判定耗时0.1s.因此, 用该方法实现虚拟平台远程认证共需时间为0.6+1.62+0.1=3.9s.以下为虚拟平台分别向4个挑战者进行远程认证的耗时图表, 每次在认证虚拟平台时让VMAgent和VMMService重新初始化, 以测试初始化过程的效率; 而在真正的使用过程中, 只需在启动后的第1次远程认证中进行初始化.

6 总结

本文总结了在可信云环境中远程证明方法现有的成果, 针对现有的可信终端远程证明方案, 包括隐私CA (privacy certification authority, 简称PCA)方案和直接匿名证明(direct anonymous attestation, 简称DAA)方案, 都并不能直接用于可信虚拟平台, 而且TCG发布的《Virtualized Trusted Platform Architecture Specification》1.0版中, 可信虚拟平台的远程证明方案仅仅是个框架.本文提出了一种自顶向下的可信虚拟平台远程证明实施方案——TVP-PCA, 该方案是在虚拟机中设置一个认证代理, 在虚拟机管理器中新增一个认证服务, 挑战方首先通过顶层的认证代理证明虚拟机环境可信, 然后通过底层的认证服务证明运行于物理平台上的虚拟机管理器可信, 顶层和底层证明合起来, 确保了整个虚拟平台的可信.文中有效解决了顶层证明和底层证明的同一性问题.实验表明:本方案不仅能证明虚拟机的可信, 而且还能证明虚拟机管理器和物理平台的可信, 因而证明了云环境中的虚拟机是真正可信的.