云计算平台完整性验证方法、客户端、远程端及系统

摘要

本发明公开了一种云计算平台完整性验证方法，该方法包括：步骤A：客户端利用可信平台模块TPM对在该客户端上运行的软件和/或硬件进行完整性度量；步骤B：当所述客户端启动安全相关的应用时，向远程端发送包含根据步骤A得到的度量值的消息，请求所述远程端对该客户端的平台的完整性进行验证；步骤C：响应于接收到来自所述客户端的验证请求，所述远程端创建基于可信任执行技术TXT的硬件隔离环境，在该硬件隔离环境中对接收到的度量值进行解密和分析以得到验证结果，并将该验证结果发送给所述客户端；步骤D：所述客户端对从所述远程端接收的所述验证结果进行解密和分析，以确定当前客户端平台是否具有高完整性。

说明书

技术领域

本发明涉及云计算平台完整性验证，其中涉及可信计算组织(Trusted Computing Group，简称TCG)的可信平台模块和Intel的可信执行技术，属 于可信计算与云计算安全领域。

背景技术

云计算等新型计算模式的出现对计算机系统提出了新的挑战，其资源与 服务的集中化特性使得如何提高云计算平台的可信性，可扩展性与可用性成 为当前国际研究热点。

云计算的第三方计算特征对云平台的安全与可信提出了新的挑战。可 信计算的概念最初由可信计算组织(Trusted Computing Group，简称TCG) 引入到计算平台中。该技术试图从完整性验证的角度来解决大规模计算平台 的安全性问题。TCG认为：如果从一个初始的“可信根”出发，在平台计算 环境的每一次转换时，“信任”可以通过传递的方式保持下去而不被破坏， 那么平台上的计算环境就始终是可信的。TCG v1.2规范定义了从平台加电到 操作系统装载可信传递过程的完整性度量，但是并没有将信任传递延伸到应 用程序。另一方面，完整性的验证机制需要扩展给使用平台的用户来验证其 所属的虚拟机的可信性，以此来确保安全敏感度高的程序运行环境的可信 性。

2004年IBM华盛顿研究中心的Reiner Sailer等人提出了IMA完整性度 量架构，在文献1“Design and Implementation of a TCG-based Integrity Measurement Architecture(USENIX2004)”中，第一次将可信传递过程从 BIOS延伸到应用层。

IMA属于静态完整性度量，它最大的问题就是不能对系统运行时的完整 性做出任何的保证。2006年，IBM华盛顿研究中心的另一篇文章“PRIMA： Policy Reduced Integrity Measurement Architecture(SACMAT2006)”提出了 一种基于信息流的完整性度量方法PRIMA，对不同类型实体间的信息流进 行完整性度量。

前面所述的工作都没有对远程验证方的验证过程添加任何保护措施，而 是简单地假设远程验证方可信，客户端完全信任从远程验证端发送过来的验 证结果。事实上，这种假设是很脆弱的。如果远程验证方被攻击，那么验证 过程的输出结果就可能会被篡改。但是，如果客户端仍然坚持信任收到的验 证结果，就会导致对完整性状态的误判，从而造成经济损失或者隐私泄密等 安全问题。

基于AMD的安全虚拟机技术(SVM，类似于Intel的可信执行技术)， 文献3“Flicker:An Execution Infrastructure for TCB Minimization(EuroSys 2008)”为安全敏感代码如何在完全隔离环境下执行提供了一个公共基础设 施Flicker，而且能够对代码的执行向远程端提供一个有意义的、细粒度的认 证。最后，将Flicker应用到多种类型的应用中。

发明内容

为解决现有技术中存在的不足，本发明的目的在于提供一种云计算平台 完整性验证方法、客户端、远程端以及系统。

为了实现上述目的，本发明的一个方面提供一种云计算平台完整性验证 方法，该方法包括：步骤A：客户端利用可信平台模块TPM对在该客户端 上运行的软件和/或硬件进行完整性度量；步骤B：当所述客户端启动安全相 关的应用时，向远程端发送包含根据步骤A得到的度量值的消息，请求所述 远程端对该客户端的平台的完整性进行验证；步骤C：响应于接收到来自所 述客户端的验证请求，所述远程端创建基于可信任执行技术TXT的硬件隔 离环境，在该硬件隔离环境中对接收到的度量值进行解密和分析以得到验证 结果，并将该验证结果发送给所述客户端；步骤D：所述客户端对从所述远 程端接收的所述验证结果进行解密和分析，以确定当前客户端平台是否具有 高完整性。

本发明的另一个方面提供一种在根据上述方法的云计算平台完整性验 证中使用的客户端。

本发明的还一个方面提供一种在根据上述方法的云计算平台完整性验 证中使用的远程端。

本发明的又一个方面提供一种云计算平台完整性验证系统，该系统包括 上述的客户端和远程端。

与现有的完整性验证方法相比，本发明可以提高验证过程的安全性和可 见性。

安全性：即使远程端的操作系统、应用程序都是恶意的，利用Intel TXT 技术构建的强隔离的执行环境，也能够保证完整性验证过程的安全。

可见性：客户端能够收到Intel TXT技术生成的一个认证，该认证表明 完整性验证过程是在相应的保护措施下进行的。也就是说，客户端对远程验 证端的执行过程是可见的，避免了盲目地相信来自远程验证端发送过来的验 证结果。

本发明的其他特征和优点将在随后的具体实施方式部分予以详细说明。

附图说明

附图是用来提供对本发明的进一步理解，并且构成说明书的一部分，与 下面的具体实施方式一起用于解释本发明，但并不构成对本发明的限制。在 附图中：

图1示出的是客户端的各主体之间度量的关系图；

图2示出的是客户端和远程端度量、验证的流程图；

图3示出的是客户端检查验证结果正确性的流程图。

具体实施方式

以下结合附图对本发明的具体实施方式进行详细说明。应当理解的是， 此处所描述的具体实施方式仅用于说明和解释本发明，并不用于限制本发 明。

本发明所述的平台完整性度量，客户端使用的可以是Linux操作系统并 具有vTPM的虚拟机，不限制远程验证端的平台(但必须支持可信平台模块 TPM和可信任执行技术，即TXT技术)。对客户端来说，启动过程可以分为 如下几个步骤：BIOS→GRUB→Linux Kernel→Dynamic library、Loadable Modules、User-level Processes。如图1所示，我们选择从GRUB的Stage(阶 段)2开始度量(即将GRUB视为可信根)。在GRUB以后的过程中，每个 功能实体在将控制权交给下一个功能实体前，先对下一个功能实体进行度 量。

之前的工作总是假设远程验证端是可信的，但是这种假设通常是不能够 被满足的。在本发明中远程验证端可以是不可信的，我们在远程验证端构造 了一个硬件隔离的执行环境，将其中的执行与平台上的其他软件完全地分 开。这样，即使操作系统和平台上的其他软件都是恶意的，也能够通过这种 硬件隔离的方式保证他们不会对隔离环境下代码的执行造成任何影响。远程 验证端利用TPM生成一个认证，它能够验证相应的代码是在这种保护措施 下执行的，这样就能够说服客户端信任得到的验证结果。

具体来说，本发明的一个实施方式提供一种云计算平台完整性验证方 法，包括：

A.如图1所示，客户端利用TPM对运行在它上面的Linux Kernel(内 核)、动态库、内核模块、可执行程序做完整性度量，其实现方法为：

A1，在GRUB Stage2中，使用TPM硬件提供的SHA-1引擎计算Linux Kernel的度量值，并将其存储到度量列表measurement_list_kernel中，并将 度量值扩展到寄存器PCR8中，然后再将控制权交给Kernel。

A2，在动态库、模块、可执行程序各自的加载阶段调用TPM的SHA-1 引擎分别计算每个动态库、模块、可执行程序的度量值，并将度量值按先后 顺序分别存入度量表measurement_list_sharedlib、measurement_list_mod、 measurement_list_exe中，并将度量值扩展到寄存器PCR9、PCR10、PCR11 中。

B.如图2所示，当客户端启动安全相关的应用时，会将自己在A1和 A2得到的度量表measurement_list_kernel、measurement_list_sharedlib、 measurement_list_mod、measurement_list_exe和PCR8-PCR11的值发送到远 程端，请求远程端对其平台的完整性进行验证，其实现方法为：

B1，如果客户端启动某一安全相关的应用，在其加载过程中，对该应用 以及它所依赖的共享库利用SHA-1引擎对其进行完整性度量，然后将度量 值保存到相应的度量表中，并扩展对应的PCR；

B2，为了防止重放攻击，客户端利用TPM硬件生成一个随机数并保存 在变量nonce_a中；

B3，客户端对A1和A2生成的measurement_list_kernel、 measurement_list_sharedlib、measurement_list_mod、measurement_list_exe、 PCR0-PCR11以及B2生成的随机数nonce_a打包，并用自己TPM的AIK私 钥部分对这一数据集签名；

B4，客户端使用远程端的AIK公钥部分对B3得到的签名后的数据加密；

B5，客户端将B4得到的加密后的数据发送给远程端，请求远程端对其 进行完整性验证。

C.如图2右边部分所示，远程端在收到客户端发送过来的验证请求后， 首先准备敏感代码执行需要的基于TXT技术的硬件隔离环境，然后在这种 硬件隔离的环境中对收到的度量表和PCR值进行解密、分析，得出验证结 果verify_result。其实现方法为：

C1，远程端在收到从客户端发送过来的消息后，远程端保存当前执行上 下文，并挂起当前的执行环境；

C2，远程端利用Intel TXT技术提供的特殊指令SENTER，禁用到某一 内存区域的DMA、禁用中断和调试访问等硬件保护措施，建立一个独立的 执行环境；

C3，远程验证端在C2得到的隔离的内存区域内利用自己的AIK私钥对 收到的密文进行解密，得到一个已签名的数据集；

C4，远程验证端利用客户端的AIK的公钥部分对C3得到的数据集进行 解密，得到度量列表measurement_list_kernel、measurement_list_sharedlib、 measurement_list_mod、measurement_list_exe、PCR8-PCR11和随机数 nonce_a；

C5，远程验证端将随机数nonce_a保存在变量nonce_c中。

C6，远程端将解密得到的measurement_list_kernel、measurement_list_ sharedlib、measurement_list_mod、measurement_list_exe与系统预留的可信程 序列表trusted_kernel、trusted_sharedlib、trusted_mod、trusted_exe进行比较， 判断收到的度量列表中的所有项是否都存在于对应的可信度量列表中，如果 是则说明客户端的平台具有高完整性verify_result＝1，否则，客户端平台不 具有高完整性verify_result＝0；

C7，远程端清理C2初始化的内存区域的残留数据，并将二进制可执行 的加解密和验证的代码、输入数据、输出数据传输到TPM中进行SHA-1运 算，生成度量值，并将度量值扩展到PCR17中；

C8，远程端恢复C1挂起的执行环境。

C9，远程端将C6得到的完整性验证结果、C7得到的PCR17与C5保 存在变量nonce_c中的随机数组合，并通过类似B3和B4的方法对数据集进 行签名、加密；

C10，远程端将C9得到的密文发送给客户端；

D.如图3所示，客户端对收到的验证结果进行解密、分析，得出当前 客户端平台是否具有高完整性。其实现方法为：

D1，客户端收到从远程端发送过来的消息后，对其进行解密；

D2，将解密后得到的随机数nonce_c与B2存放在变量nonce_a中的随 机数进行比较。若一致则说明收到的包是最新的验证结果，继续下一步判断。 否则，说明系统遭到重放攻击，暂时不能信任要执行的应用，需要重新做完 整性度量。

D3，计算安全敏感代码、发送给远程验证端的包、以及收到的验证结果 的SHA-1值，并用扩展的方式最终得到一个20字节的度量值 txt_measurement，将其与收到的PCR17做比较。如果一致则说明相应的代码 是在TXT的保护下执行的，继续下一步判断。否则，说明相应的代码没有 在TXT的保护下进行，直接终止该应用的启动。

D4，若上面的判断都通过，则说明本次收到的验证结果是最新的并且是 在TXT的保护下得到的验证结果，说明此验证结果可以信任。根据验证结 果若verify_result＝1此应用可信，则正常启动该应用。否则，终止该应用的 启动。

与现有的完整性验证方法相比，本发明的方案可以提高验证过程的安全 性和可见性。

安全性：即使远程端的操作系统、应用程序都是恶意的，利用Intel TXT 技术构建的强隔离的执行环境，也能够保证完整性验证过程的安全。

可见性：客户端能够收到Intel TXT技术生成的一个认证，该认证表明 完整性验证过程是在相应的保护措施下进行的。也就是说，客户端对远程验 证端的执行过程是可见的，避免了盲目地相信来自远程验证端发送过来的验 证结果。

以上结合附图详细描述了本发明的优选实施方式，但是，本发明并不限 于上述实施方式中的具体细节，在本发明的技术构思范围内，可以对本发明 的技术方案进行多种简单变型，这些简单变型均属于本发明的保护范围。

另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特 征，在不矛盾的情况下，可以通过任何合适的方式进行组合。为了避免不必 要的重复，本发明对各种可能的组合方式不再另行说明。

此外，本发明的各种不同的实施方式之间也可以进行任意组合，只要其 不违背本发明的思想，其同样应当视为本发明所公开的内容。