一种可信虚拟平台底层环境验证方案

孙浩男 鹤荣育 郭 丽

1(解放军信息工程大学 河南 郑州 450001)2(河南省工业技术学校 河南 郑州 450001)

0 引 言

虚拟化技术增强了计算资源的利用率，提供强大的隔离能力，能够同时为多个用户提供不同服务。但是在虚拟化平台中，缺少对平台以及客户虚拟机的完整性度量，使得虚拟环境的安全性难以得到保证。可信计算技术为计算平台增加可信平台模块TPM(Trusted Platform Module)，为平台提供软、硬件保护机制，保障计算平台的完整性。通过虚拟化技术同可信计算结合，创建虚拟化可信平台模块vTPM，建立可信虚拟化平台，可为客户虚拟机提供完整性保护机制和密码服务。

虚拟可信平台通过物理平台状态寄存器PCR到虚拟平台状态寄存器vPCR的映射关系将信任链延伸至客户虚拟域，并通过一定的签证手段将证书链延伸至虚拟域，由此客户虚拟机能够应用TPM安全机制和密码服务。虚拟可信平台的用户在启动虚拟机后，需要先进行远程证明服务，在确定本机和底层环境可信的状态下，方可使用虚拟机。然而在复杂的虚拟化环境中，往往面临着众多的安全威胁，如恶意用户、外来入侵等。可信计算技术能够为虚拟环境提供完整性保护机制，但目前的vTPM构建方式(如IBM的vTPM构建方案)对平台的底层环境具有一定的威胁。现阶段，直接将PCR映射至vPCR的方式和虚拟机的远程证明机制会将底层平台配置信息直接泄露，为攻击者提供方便，使得平台更易遭受攻击。另外，除了确定底层环境可信，客户虚拟机还需要知道在平台中是否存在来自其他客户机的威胁、平台有哪些保护机制、平台是否符合规范等问题。而为获取用户的信任，将平台配置信息和安全策略配置信息直接发送用户同样会造成平台安全隐患。

针对现阶段可信虚拟平台存在的问题，本文从平台隐私保护出发，以XEN为虚拟平台，参照IBM的vTPM构建方案进行改进，改变物理PCR与vPCR映射方式，增加可信验证模块和访问控制策略，提供平台内部的底层平台完整性和安全策略的静态、动态验证服务，建立虚拟机用户对底层环境的信任关系，从而构建具有平台隐私保护的可信虚拟平台。本文方法仅适用于类似XEN的具有独立控制域的虚拟化环境。

1 相关内容

1.1 远程认证

在可信平台中，最基本的远程证明方法是由TCG提出的二进制远程证明方法[1-2]，但是在可信虚拟平台中，虚拟机直接使用该方法验证整个信任链(如IBM的vTPM构建方案)，会暴露可信平台软硬件配置。对于该问题，Sadeghi等[3]提出了基于属性的认证方法(PBA),通过可信第三方颁发属性证书的方式保证平台的隐私性，但存在属性证书被恶意转发、吊销困难的问题，灵活性较差，且具有可信第三方或平台与可信第三方交互过程中泄露平台隐私的风险。在虚拟化可信平台中，环境配置多变、信任关系复杂，为保证底层平台完整性和相关安全策略可信且对用户以及平台外部不可见，基于属性的认证方法并不完全适用于虚拟化平台底层环境的远程证明。

1.2 IBM的vTPM方案

对于可信虚拟平台的实现，IBM提出了基于XEN构建vTPM的方案。方案为客户虚拟机创建vTPM实例，使其能够提供硬件TPM保护功能，甚至能够进行远程证明服务[6]。在IBM的vTPM方案中，通过物理PCR到vPCR的映射，上层客户虚拟机能够进行虚拟环境的二进制远程证明。如图1所示，物理PCR[0-8]位存储BIOS、Bootloader、VMM的度量值，以此作为vTPM的可信基(TCB)，将PCR[0-8]位映射至vPCR，用户虚拟机对vPCR[0-8]可读、vPCR其余位可读写，vPCR[9]存储虚拟机的OS度量值，其余交由用户使用，可以存储虚拟机上层应用、文件等度量值。在虚拟机进行二进制远程证明时，可以通过vPCR的低、高位存储值验证底层环境完整性和其自身虚拟机的完整性。

图1 IBM方案:物理PCR-vPCR映射

IBM的vTPM方案，能够很好地扩展证书链、信任链，但是该方案在虚拟机进行远程证明的过程中，在获取和提交vPCR的低、高位存储值时，会导致底层平台的隐私信息泄露。

2 可信虚拟环境验证方案

本文以XEN[4]为虚拟化平台建立可信虚拟环境，如图2所示，在原有IBM的可信虚拟平台的架构上增加可信验证模块，并制定一系列机制，从而构建具有平台配置信息保护能力的可信虚拟平台。XEN平台中，XEN内核代码运行于ring0层，操作系统代码运行于ring1层，应用运行于ring3层。本文在特权管理域Dom0中设计可信验证模块，在Dom0启动后首先启动该模块。

图2 可信虚拟环境验证模型

本文应用IBM方案中平台身份认证密钥AIK(Attestation Identity Keys)签发vTPM的虚拟平台身份认证密钥vAIK(Attestation Identity Keys)证书的方式扩展可信证书链，使vTPM具有良好的平台关联性；改变建立PCR到vPCR映射关系，保护底层配置信息；结合XEN安全模块XSM(Virtual Xen Security Modules)，增加强制访问控制策略；以可信验证模块为核心进行底层环境的完整性和安全策略验证，并与用户交互，在对底层平台配置信息隐私保护的基础上建立用户对底层平台的信任关系。

2.1 平台隐私保护

根据TCG规范，物理TPM的PCR的0～7位中存放BIOS和物理硬件的度量值。如图3所示，本文在PCR第8位中存放虚拟机监控器VMM(Virtual Machine Monitor)和dom0的度量值，在PCR第9位中存放可信验证模块的度量值，在PCR第10位中存放vTPM管理器和vTPM实例的度量值。PCR其余位可按需存放其他组件度量值，本文在PCR第11位存放XEN网络配置文件度量值，在PCR第12位存放安全策略配置文件度量值。

图3 PCR-vPCR映射

为了保护平台底层配置信息，不再将物理PCR中全部平台度量值映射到vPCR中，而只将PCR第9位(可信度量模块度量值)映射至vPCR。客户虚拟机只能获取可信验证模块度量值和度量日志。由此，虚拟客户机能够直接验证可信度量模块的完整性，但无法获取底层平台的配置信息，达到平台隐私保护的目的。

2.2 安全策略

XEN本身具备一定的安全措施，如：通过配置XSM的强制访问控制安全模块(SHype/ACM)[5]和Flask模块等方式，可对虚拟域等内容进行强制访问控制管理。本文在XEN平台上基于XSM的Flask模块配置强制访问控制策略，为用户提供一定的访问控制保障。

1988年，Brewer等[7]根据现实的商业策略提出了Chinese Wall安全模型。Chinese Wall模型是一种混合型安全模型，试图对相互竞争关系的客户进行保护。本文采用Chinese Wall安全模型的简单安全性规则，为虚拟平台提供粗粒度的访问控制，对虚拟机的启动进行控制。收集用户虚拟机的单位信息，根据用户虚拟机之间关系为其划分利益冲突类、公司数据集、客体。

客体：单个公司信息项(虚拟机)。例如某公司的数据库虚拟机、管理员虚拟机、员工虚拟机等。

公司数据集：一个公司的所有客体集合。

利益冲突类：有利益冲突的公司数据集的集合。

定义1O为客体集合(o∈O)，L为安全标签(x,y)，每个标签对应一个客体，x代表利益冲突集，y代表公司数据集。

简单安全性[8]：简单安全性读访问规则是允许一个用户访问与他曾经访问过的公司的没有利益冲突的公司信息。初始时，一个主体可以自由访问任意的某公司信息，不存在访问控制限制。一旦初始访问确定，则主体不能再访问该公司数据集的利益冲突类中的其他公司数据集。

本文中应用Chinese Wall安全策略，为客户虚拟机提供粗粒度的访问控制保护，主体为管理虚拟机启动/关闭的Dom0特权域，将访问的概念换为启动，在启动阶段进行限制，避免同一利益冲突类的不同公司数据集同时启动。

2.3 可信验证模块

可信验证模块是验证底层环境、保护平台隐私的核心模块。该模块经过Seal密封存储(与PCR[0-8]期望值绑定)、可信启动，并能够为用户验证底层环境完整性和安全策略，且保护配置信息使其不外泄，是建立用户对整个平台信任关系的关键模块。

2.4 二级远程证明

与IBM通过对PCR[0-8]到vPCR[0-8]的底层度量数据完全映射、由虚拟机进行远程证明的方案不同，本文采用虚拟机与底层分离的方式进行二级证明。如图4所示，由可信验证模块验证底层平台的完整性，由用户虚拟机与可信第三方交互验证上层虚拟机的完整性和平台身份，确保底层平台的配置信息不外泄。

图4 二级远程证明

2.4.1 客户虚拟机验证

客户机将自己的vTPM实例当作真实TPM，进行客户虚拟域的完整性二进制度量，记录度量日志。客户虚拟机与第三方认证中心CA(Certificate Authority)交互，确认vTPM身份无误后进行完整性的验证。通过远程验证，得到平台身份是否可信、虚拟域是否可信的结果。

2.4.2 平台底层环境验证

可信度量模块虽然经过seal处理(与PCR[0-8]期望值绑定)，但是并未绑定到上层的vTPM管理器和vTPM实例(PCR[10])，其次，客户虚拟机信任可信度量模块，但并不直接信任底层的全部组件是可信启动的。因此须由可信度量模块对底层环境进行完整性二进制验证，并将验证结果签名返回用户。

3 可信验证模块

在可信虚拟平台ring1层的特权域dom0中增加可信验证模块。该模块是可信虚拟环境验证方案的核心模块，负责建立上层用户对底层平台的信任关系。主要具有可信启动、验证底层平台完整性、平台策略验证机制。

如图5所示，可信验证模块由信息采集代理、验证代理、用户接口以及期望值库组成，各组件具体说明如表1所示。

图5 可信验证模块组件

组件说明信息采集代理采集用户信息、底层平台完整性度量和策略配置相关信息验证代理对完整性、策略进行验证计算用户接口为用户提供服务接口期望值库存储完整性度量期望值、安全策略配置标准值

3.1 可信启动

(1) 启动前平台环境自检:通过TPM将可信验证模块做seal操作，将PCR[0-8]期望值与其绑定，在VMM和dom0启动后进行unseal解封操作，如果模块能被释放，那么表示当前对应的PCR符合期望，可信验证模块能够确认底层环境安全。

(2) 启动可验证:在成功unseal操作后TPM度量可信验证模块，将度量值存在PCR第9位，启动可信验证模块。在客户虚拟机需要通过可信验证模块验证底层环境时，能够通过vPCR第9位和度量日志中可信验证模块的内容判断可信验证模块是否可信启动。

3.2 底层环境静态验证

3.2.1 底层平台完整性验证

客户虚拟机在信任可信度量模块后，可进行底层平台二进制完整性验证。可信验证模块执行本地底层环境的完整性验证，身份验证交由虚拟客户端完成。如图6所示。

图6 底层平台完整性验证模型

底层平台完整性验证如下：

(1) 客户虚拟机通过用户接口发送验证请求和随机数nonce到可信验证模块；

(2) 信息采集代理获取度量日志SML()；

(3) 信息采集代理请求并获取TPM使用AIK签名的PCR[0-10]；

(4) 信息采集代理获取在TPM存储区域的AIK身份证书；

(5) 验证代理根据收集到的SML()、PCR()验证SML()是否被篡改，并参照期望值库验证度量结果是否符合预期；

(6) 信息采集代理向TPM发送验证结果和随机数并请求获取AIK对其签名；

(7) 可信验证模块返回AIK签名过的验证结果和随机数给用户虚拟机；

(8) 用户验证随机数，并与CA交互，验证AIK证书，在确认本次会话以及平台身份无误后查看可信验证模块返回的验证结果，从而确定底层平台是否可信。

3.2.2 平台策略验证

在可信度量模块对底层环境度量结果进行验证通过后，可确认启动度量日志、安全策略配置文件未被篡改。可信验证模块根据用户的身份信息，结合虚拟域之间的关系，对访问控制策略进行验证：

(1) 信息采集代理、验证模块通过访问和检验平台启动引导配置文件，判断平台是否具有强制访问控制安全策略并已配置为强制启动。

(2) 信息采集代理收集具体客户虚拟机的身份信息、策略要求，验证代理通过期望库中的平台配置访问控制策略判断平台能否为当前客户虚拟机提供安全的访问控制保障。

(3) 信息采集代理收集当前已启动虚拟机与当前请求验证的虚拟机之间的关系，验证代理验证当前虚拟机的所处环境是否存在利益威胁：对于当前请求验证的虚拟机(x,y)，根据其他已启动的虚拟机集合O的标签，检测是否存在与当前虚拟机同属同一利益冲突集x、不同公司数据集y的虚拟机，若不存在则没有利益冲突。

(4) 信息采集代理请求TPM使用AIK对验证结果进行数字签名，并附AIK证书。

3.3 底层环境动态验证

虚拟化平台是一个不断挂载、关闭多个虚拟机的状态实时变化的平台，对于其完整性和安全策略的保障不应只停留在虚拟机的启动阶段。对于底层平台和某已启动的虚拟机而言，任一时刻其他的虚拟机的挂载都会造成系统状态的变化，因此需要提供实时的度量检验。

3.3.1 完整性动态度量验证

在系统中当有虚拟机挂载时，平台会度量其对应的可信根vTPM。物理PCR[10]负责记录虚拟机的可信根:vTPM实例的度量值,在vTPM被度量启动后，可信验证模块可对vTPM的度量结果进行验证。与静态验证类似，由信息采集代理PCR[10]采集度量值、日志，由验证代理验证完整性。

对于平台管理者而言，可以根据获取每个虚拟机启动时可信根的完整性检验结果，判定虚拟环境下由于挂载虚拟机产生的平台的状态变化是否存在威胁。通过实时验证，能够第一时间发现问题，阻止其启动。

对于客户虚拟机而言，能够通过可信验证模块反馈的验证结果实时地获取当前平台状态变化是否安全，并且不能获取其他虚拟机可信根的具体启动信息，保护各虚拟机隐私。

3.3.2 安全策略动态度量验证

可信验证模块动态获取已启动的虚拟机的标签，根据标签判断当前已启动的虚拟机之间是否存在利益冲突关系，实时验证策略的实施情况：

(1) 根据当前所有已启动虚拟机之间的关系，验证当前环境是否存在利益威胁：遍历所有已启动的虚拟机集合O的标签，判断对同一利益冲突集x，是否存在不同的公司数据集y，若不存在则没有利益冲突。

(2) 使用AIK对完整性和安全策略验证结果进行数字签名，并附AIK证书。

4 信任传递

可信虚拟环境平台通过主要通过二级远程证明方案进行信任传递，过程如图7所示。(1) 虚拟机对应vTPM的PCR[11-23]供用户使用，记录虚拟机映像、应用等度量值。用户可以使用vTPM与第三方CA进行自身的远程证明，首先判断上层虚拟机是否可信。(2) 在远程证明的过程中，通过vAIK的证书验证间接验证了TPM的AIK证书，判断了平台身份是否可信。(3) 由于vPCR[9]映射了可信验证模块的度量值，用户可验证该模块是否可信。(4) 在信任可信验证模块后，可信验证模块执行底层环境完整性的验证，用户可根据该模块提交的计算结果决定是否信任底层环境，底层环境包括BIOS、物理硬件(包括TPM)、VMM、Dom0、vTPM管理器、vTPM实例。(5) 验证平台是否强制启动了安全策略、当前虚拟机是否符合安全策略，建立对底层安全策略的信任关系。(6) 通过可信度量模块的动态度量机制，进一步建立用户对平台完整性、安全策略的实时信任关系。由此，能够达到在不泄露平台配置信息的条件下，建立用户对平台信任关系的目的。

图7 信任传递

4.1 虚拟机可信

在虚拟机操作系统中，vTPM提供与硬件TPM相同的功能和命令集，vPCR[11-23]存储虚拟机度量值，且TPM-CA为vTPM颁发过vAIK证书，虚拟机具备远程证明的能力，可通过与可信第三方交互进行远程证明，验证自身虚拟机是否可信。

4.2 平台身份可信

物理TPM经过平台外部的第三方CA签发AIK证书，TPM通过有效的AIK间接签证vTPM的vAIK证书。在客户虚拟机做远程验证时，通过第三方CA验证自身的vAIK证书的签证源的合法性；客户虚拟机在接收可信度量模块的计算结果后，也通过第三方CA确认AIK证书的合法性，从而信任计算结果发送方的身份。由此既可以验证平台的真实身份，也能判断平台是否具有真实的物理TPM模块，而不是采用软件模拟(如Tpm_emulator)的手段。

4.3 验证模块可信

可信验证模块的seal操作，目的在于确定模块在启动前的平台环境是否可信。由此建立可信验证模块对其自身启动环境(即底层环境)的信任关系。

客户虚拟机通过获取可信验证模块的启动度量信息，能够验证可信验证模块是否是可信启动的。由此建立客户虚拟机到可信验证模块的信任关系。

4.4 底层平台完整性可信

可信验证模块获取TPM的PCR度量值和度量日志，计算启动过程是否与预期相符。可信验证模块能够验证底层环境是否可信并将结果签名反馈给客户虚拟机。由此建立用户对底层环境信任关系，从而信任整个平台环境。

4.5 平台安全策略可信

客户虚拟机信任整个平台环境之后，经过可信度量模块对平台检测是否强制启动安全策略、检测对当前虚拟机是否具有正确的策略配置，并根据该虚拟机与当前的已启动的各虚拟机利益关系判断当前的安全状态。将结果签名反馈给客户虚拟机。

客户虚拟机信任整个平台环境，再根据可信度量模块反馈的策略检测结果，确定平台是否对其进行了有效的访问控制保护，且当前是否为安全的状态。

4.6 平台底层环境动态可信

在平台启动阶段静态度量验证结果和虚拟机启动阶段安全策略验证结果为可信的条件下，建立用户对平台的静态信任关系。

可信度量模块在此基础上对挂载虚拟机引起的虚拟平台环境变化进行动态度量验证，提供实时的验证机制：

(1) 动态完整性验证：对启动的虚拟机的可信根vTPM的度量值进行实时验证。

(2) 动态安全策略验证：对所有已启动的虚拟机进行策略的实时验证。

通过结果签名并反馈给用户，可进一步建立用户对平台的动态信任关系。

5 实验分析

本文对虚拟可信环境验证方案实现了原型系统。系统平台配置如下：物理TPM:STM v1.2;XEN虚拟化平台v4.4;Dom0内核版本:Linux 4.5.2;DomU内核版本:Linux 3.9.1。实验分别从PCR映射、底层平台静态、动态验证进行系统测试。

如图8所示，上部分为平台TPM的PCR[0-12],下部分为虚拟机node1的vPCR[0-12]。可以看到平台仅将PCR[9]映射至vPCR[9]，其余位按2.1节方案存储度量值。由此对上层用户屏蔽平台底层环境的度量信息。

图8 PCR映射实验

(1) 底层环境静态验证可信 底层环境静态验证包括在用户虚拟机启动时刻的底层完整性验证和平台安全策略验证。图9为虚拟机node1启动时的验证结果：进行静态完整性验证，检测当前已启动虚拟机的标签，判断是否对当前虚拟机构成利益威胁。其中标签vmA_r、vmB_r对应利益冲突集，domU1_t、domU3_t对应公司，可以看到在node1启动时，已有node2在运行，而node2与node1属不同利益冲突集，因此node2对node1没有利益威胁。静态环境验证结果：可信。

图9 底层环境静态验证

(2) 底层环境动态验证可信 底层环境静态验证包括在用户虚拟机启动后某时刻的底层完整性验证和平台安全策略验证。图10为虚拟机node1启动后某时刻请求动态验证的结果。可信验证模块与TPM交互，进行动态完整性验证，检测当前所有已启动虚拟机的标签，判断虚拟机之间是否存在利益冲突其中标签vmA_r、vmB_r对应利益冲突集，domU1_t、domU3_t对应公司，可以看到有node1、node2、node3在运行，node1、node3同属一个公司且与node2不在同一个利益冲突集内，因此node1、node2、node3相互之间不存在利益冲突。动态环境验证结果：可信。

图10 底层环境动态验证可信

(3) 底层环境动态验证不可信 在图10实验基础上，对安全策略进行篡改并重新加载，使得存在利益冲突的虚拟机可以同时挂载。图11为虚拟机node1启动后某一时刻请求动态验证的结果。由于安全策略被篡改，则动态完整性验证结果为不可信。标签vmA_r、vmB_r对应利益冲突集，domU1_t、domU2_t、domU3_t对应公司，此时有node1、node2、node4在运行，其中node1与node4同属一个利益冲突集内且隶属于不同的公司，因此node1与node4相互之间存在利益冲突，策略的验证结果为不可信。动态环境验证结果：不可信。

图11 底层环境动态验证不可信

6 结 语

本文在IBM的vTPM方案基础上，对平台隐私保护问题进行研究，提出一种可信虚拟平台底层环境验证方案。通过设计物理PCR到vPCR的映射方式、提出二级远程认证、建立可信环境验证模块进行底层平台静态和动态的完整性与安全策略验证等工作，从而在平台底层隐私保护的基础上，建立虚拟机用户对底层平台环境的信任关系。对于解决可信虚拟平台、云平台上的用户对平台底层信任问题和底层隐私保护问题有一定的参考价值。