共计 8275 个字符，预计需要花费 21 分钟才能阅读完成。

title: 远程证明_01_云数据中心的大规模虚拟机的远程证明 date: 2022-05-12 00:29:12.443 updated: 2022-05-22 22:10:06.922 url: /archives/yczm01 categories:

• 论文阅读
• 远程证明 tags:
• 可信计算
• 远程证明

原文信息

1. 文章标题：Remote Attestation of Large-scale Virtual Machines in the Cloud Data Center
2. 文章中文翻译：云数据中心的大规模虚拟机的远程证明
3. 文章等级：CCF C
4. 文章发表时间：2021
5. 文章作者：Jie Cheng, Kun Zhang and Bibo Tu
6. 完整引用：Cheng J, Zhang K, Tu B. Remote Attestation of Large-scale Virtual Machines in the Cloud Data Center[C]//2021 IEEE 20th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom). IEEE, 2021: 180-187.
7. 全文请查看：全文链接

0 摘要中的信息

0.1 文章要解决的问题

在云数据中心中，如果进行大规模虚拟化环境的验证会造成TPM瓶颈和网络拥塞，导致远程验证效率低下。

0.2 文章提出解决方法

该文提出了 CloudTA，一种可扩展的远程证明架构。

1. CloudTA 对每个云服务器上的所有虚拟机进行分组，并引入完整性测量组（IMG）来测量虚拟机并按组生成可信证据。
2. 随后，云服务器上报物理平台和VM组的可信证据进行组验证，减少延迟，提高效率。
3. 此外，CloudTA设计了一个混合高并发通信框架，通过结合主动请求和定期报告来支持大规模虚拟机的远程证明。

评估结果表明，CloudTA具有良好的效率和可扩展性，可以支持万台虚拟机的远程认证。

1 引入原因

TPM Quote是一个耗时的操作，使用频繁，成为attestation的瓶颈；此外，很多虚拟机与评估者交互，容易造成网络拥塞，影响鉴证效率。有研究提出了一种基于hypervisor的 VM 远程证明 ，VM 不再直接与评估者交互，而是hypervisor上的代理获取 VM 的个人可信信息。最后，目标平台将其和虚拟机的可信信息发送给评估者进行验证。这种方法通过绑定主机和虚拟机有效地避免了身份问题，并且可以同时验证多个虚拟机，在一定程度上减少了验证冗余，提高了可扩展性。但是，每个 VM 仍然需要 TPM Quote 操作；因此，TPM 的瓶颈影响了证明的效率。总之，目前的方法不支持大规模虚拟机的远程证明。

此外，虚拟机的增加和动态特性对远程认证中的通信框架提出了更高的要求。主动请求的方法是，评估人员向特定平台发起请求，然后平台使用其可信证据进行响应。这种方法保证了及时响应，但无法实现实时验证。同时，主动报告方式是目标平台主动向评估人员报告其可信证据，确保实时验证，但无法及时响应，当大量平台同时报告时，会增加评估人员的负载压力。这两种方法都更适用于目标平台数量较少的场景。

为了支持大规模虚拟机的远程认证，该文提出了一种可扩展的体系结构CloudTA。CloudTA将每个云服务器上的VM视为一个组，并基于Tboot和IMA，在云服务器中引入了完整性度量组（IMG）。IMG通过一个小组来衡量虚拟机的完整性。之后，它将测量值聚合到TPM的特定PCR中，并将其记录到虚拟机测量日志（VM ML），建立分层连接，并将信任扩展到VM。此外，在高并发混合通信框架的支持下，云服务器将云主机组和物理平台的可信证据一起报告给认证服务器，通过现有的远程认证协议进行验证。

总结贡献：

1. 通过分组IMG实现批量远程证明
2. 实现了一个高并发混合通信框架CloudTA 可以支持上万虚拟机同时证明

2 相关工作

利用了IMA，二进制完整性度量。

2.1 远程证明

远程认证使评估人员能够验证目标平台的完整性。首先，评估师发送一个包含随机数（nonce）的认证请求。当收到此请求时，目标平台中的认证代理将收集可信证据，包括通过对PCR和nonce执行TPM Quote操作获得的ML和签名。平台随后将该证据报告给评估人员。然后，评估人员验证签名的正确性，以确定身份并获得可信的PCR。接下来，通过模拟PCR扩展并将模拟结果与可信的PCR 10匹配，可以进一步确定ML的真实性。如果验证结果是肯定的，评估人员通过将可信的ML与从原始正确系统收集的期望值进行比较，进一步判断平台的可信度。

PCR 10时IMA默认使用的PCR。

2.2 虚拟机的远程证明

在基于虚拟机监控程序的虚拟化环境中，设计并实现了vTPM（例如基于软件的vTPM、基于硬件的vTPM、基于para-vTPM、基于KVM的vTPM和基于属性的vTPM），以将信任扩展到虚拟机，并提供与物理TPM相同的使用模型和接口。通过vTPM为每个虚拟机构建一个独立的信任根，远程认证可以为虚拟机工作。然而，VM认证需要满足分层连接。换句话说，VM认证应该连接到其底层组件（例如，虚拟机监控程序或主机操作系统）的认证；否则，恶意虚拟机监控程序可能会损害VM的可信度，导致错误的验证结论。

VM的远程证明，需要将底层的宿主机一起证明，因为VM的可信不代表底层的可信，底层的hypervisor也需要得到证明。

三种虚拟机远程证明方法：

1. 第一种方法是评估者分别验证 VM 和Hypervisor。 通过在 VM 和Host中部署证明代理，评估人员可以使用传统的远程证明协议独立验证它们。 这两个证明共同确保了整个平台的可信度。 这种方法不需要太多更改，因此很容易集成到现有系统中。 但是，由于虚拟机和主机之间缺乏绑定，可能会出现身份问题。 TVP-PCA 使用链式信任决策算法和 MAC 地址决策算法来解决身份问题。 此外，每次验证VM时，这种方法都需要验证主机，导致频繁使用TPM Quote操作。 但是，TPM Quote 是一项耗时的操作。 频繁使用成为证明的瓶颈，影响效率。
2. 第二种方法是深度证明，评估者通过 VM 间接验证底层Hypervisor。 它将Hypervisor的完整性信息映射到虚拟机，然后通过虚拟机和评估者之间的远程证明来验证虚拟机和虚拟机管理程序。 这种方法绑定了主机和虚拟机来解决身份问题。 不幸的是，它提供的证据不够新鲜。
3. 第三种方法是基于Hypervisor的认证，评估人员通过Hypervisor验证Hypervisor和它之上的虚拟机集合。它在主机操作系统或虚拟机监控程序（Hypervisor）中添加了一个代理，以收集虚拟机的各个完整性信息。随后，主机将其自身和虚拟机的完整性信息报告给评估人员进行验证。这种方法将主机和虚拟机绑定在一起以避免身份问题，并且不需要像上述两种方法那样在每个虚拟机中部署认证代理，从而减少资源浪费。一个认证可以同时验证多个虚拟机，这也避免了主机验证的冗余。在[18]中，Hagen等人提出了这个框架，但没有给出具体的实现，该框架忽略了虚拟机及其可信证据之间的相关性。在[19]中，Wang等人提出了一种基于VMI的实现，通过虚拟机内省（VMI）获取虚拟机监控程序中虚拟机的可信证据。然而，这两种方案都需要在每个VM上执行TPM_Quote操作；因此，仍然存在物理TPM瓶颈问题，影响认证效率。

注：Hypervisor = 虚拟机监控程序

2.3 认证方法

两个主要的远程认证开源项目是英特尔开放认证（OAT）和IBM认证客户机服务器（ACS）

1. OAT采用主动请求（被动报告）方式；也就是说，认证服务器首先主动发送请求，然后目标平台用其可信证据进行响应。这种方法可以立即验证特定平台，但由于目标平台无法主动报告，因此无法实时检测其可信度的变化。
2. ACS采用主动报告方式；也就是说，目标平台主动向认证服务器报告其可信证据，确保实时性。但是，当服务器想要立即验证目标平台时，平台无法立即响应。此外，由于服务器需要逐个验证每个平台，当大量目标平台同时报告时，一些平台的活动报告过程可能会被阻塞，无法验证。

这两种方法都不支持云数据中心中大规模虚拟机的远程认证。

2.4 总结

综上所述，现有的虚拟机远程认证方案经常使用TPM Quote操作，而物理TPM成为认证的瓶颈，这使得它们只适用于有限数量的虚拟机。此外，基于vTPM的认证需要修改Guest OS，这可能会导致安全问题。它还需要管理大量vTPM，这可能会增加性能开销。因此，基于vTPM的认证不利于实际应用。此外，主动请求或主动报告的通信方式各有优缺点，更适合于少数设备的远程认证场景。总之，需要一种解决方案来实现云数据中心中大规模虚拟机的远程认证。

3 总体架构

这章介绍了问题的解决方案。

3.1 前提假设

• 云服务器配备了TPM，它根据TPM规范工作。
• 虚拟机映像可能已损坏，并且在虚拟机启动之前插入了恶意软件。
• 具有服务器物理权限的攻击方法（如冷启动攻击、硬件篡改）不在本文考虑的威胁范围内。
• 我们相信认证服务器是可信的，也就是说，它被正确地实现，安全地启动，并且在运行时受到保护

3.2 架构

如上图所示，这个架构中它包括两个主要实体：云服务器（Cloud Servers）和认证服务器（Attestation Servers）。

1. 云服务器：运行许多虚拟机，充当证明者，并提供可信的证据。 图 1 显示了 KVM+Qemu+TPM 的云服务器结构。 云服务器在现有Tboot和IMA的基础上增加了两个模块：Integrity Measurement Group（IMG）和Trusted Attestation Client（TAC）。 IMG 负责按组实施 VM 的完整性测量和管理，并为组生成可信证据。 TAC 主要负责通过收集器收集可信证据。 此外，基于混合高并发通信框架，通过通信模块与认证服务器建立连接，在远程证明中传输消息。
2. 认证服务器：认证服务器作为认证请求者和评估者，由三个基本模块组成。
   1. 通信模块（CM）负责建立与基于高并发混合通信框架的云服务器的连接以传递消息。
   2. Attestation模块负责验证物理平台和VM组的可信证据，并做出证明决策。 此外，它还需要来自隐私证书颁发机构（PCA）的证书来对云服务器进行身份验证。
   3. 管理和报告模块负责管理来自平台管理员的认证请求，并提供可视化界面查看验证结果。

3.3 完整工作流程

云服务器完整的完整性度量过程可以分解为以下几个部分：

1. 云服务器启动的完整性：从启动云服务器开始，到成功加载OS内核结束。它包括BIOS、GRUB和OS内核。
2. 虚拟机依赖项的完整性：指虚拟机监视器及其必要的文件或库。
3. 虚拟机启动的完整性：指虚拟机启动前的映像和引导配置。
4. 虚拟机运行时的完整性：从虚拟机启动开始，到虚拟机关闭结束。它包括虚拟机中运行的所有组件。

Tboot可以测量云服务器启动的完整性。然后，IMA可以测量应用层的所有组件。在Qemu KVM架构下，每个VM都是一个Qemu进程。因此，虚拟机依赖关系的完整性可以通过IMA来衡量。此外，IMG在虚拟机启动前测量虚拟机映像。最后，在运行时测量VM，这将在将来完成。

最后，在运行时测量VM，这将在将来完成 ,还没完成吗? 其次这里，可以看到是将PCR 12用于记录虚拟机 image Files，PCR 13用于 VM?

该体系结构的完整工作流程是：Tboot、IMA和IMG测量从服务器启动到虚拟机启动前的完整性，并生成相应的可信证据（PCRs、ML、VM-ML）。随后，在高并发混合通信框架的保证下，TAC定期收集该可信证据并将其报告给认证服务器。认证服务器收到该证据后，认证模块对其进行验证，管理和报告显示验证结果。

4 关键技术

4.1 IMG（Integrity Measurement by Group）

本小节详细介绍了如何按组测量虚拟机镜像的完整性，以生成虚拟机组的可信证据。在CloudTA中，我们将云服务器中的所有虚拟机分为一个组，并使用IMG对其进行测量。IMG结合了一个虚拟机管理工具（即Libvirt）来拦截所有的虚拟机管理指令并测量虚拟机镜像的完整性。它将这些测量结果存储在虚拟机测量日志（VM ML）中，并将其扩展到特定的PCR中，按组生成可信的证据；其中，VM ML记录了用于组验证的虚拟机的详细测量清单和必要的元数据，PCR保护了VM ML的可信度。

认证是将测量值与期望值进行比较。因为虚拟机管理非常灵活，易于创建、启动、停止和删除。虚拟机的状态可能会发生变化，导致image的变化，而image的变化又会导致期望值的变化。因此，有必要在image变化之前，将测量结果记录为新的期望值。回到IMG，具体工作流程如下：

首先，我们选择当前系统中未使用的特定 PCR。 在本文中，我们选择 PCR 12。 由于 PCR 复位功能只能在云服务器启动时发生，我们记录 PCR 的历史值（PCR 12 history）。 我们还创建了一个空的 VM_ML。 其次，当对云服务器中的任何VM执行管理命令（创建、启动、停止和删除）时，通知IMG测量VM的映像。 随后，IMG 通过公式（1）将测量值（M_Val）扩展到 PCR 12，并通过公式（2）将相关元数据附加到 VM ML，从而为该组生成可信证据

在远程验证期间，云服务器向验证服务器报告以下数值。PCR12历史，VM ML，ML，Sign（PCRs，nonce）AIK，其中PCRs包括PCR12。在这种情况下，认证服务器会验证TPM的签名，然后获得可信的PCR12。然后，认证服务器通过执行公式（1）和用返回的摘要值扩展PCR12历史来重新计算模拟值来验证VM ML的可信度。如果模拟值等于可信的PCR12，则确定VM ML的可信度。因此，建立了一个一一对应的保护链，TPM保护PCR12，PCR12进一步保护VM ML。此外，受信任的VM ML被用于虚拟机的分组验证。

4.2 混合通信框架

本小节介绍了一个高并发的混合网络通信框架，用于在云服务器和认证服务器之间建立连接，以传输远程认证中的信息。

这种混合框架结合了主动请求和定期报告的通信方式，如图3所示。

1. 一方面，云服务器主动定期报告，认证服务器被设计成高并发的。云服务器中的报告人设置一个定时器，定期向认证服务器报告可信证据。认证服务器中的接收者收到报告后，通过线程池等技术并发地处理这些报告。
2. 另一方面，当证明服务器想验证特定云服务器或虚拟机的可信度时，它主动提出请求。认证服务器中的请求者向云服务器发送一个请求。当监听器收到请求时，它会触发报告者向证明服务器回应可信证据。在报告者处理完这个主动请求过程后，它继续等待下一个周期的定期报告。这确保了云服务器一次只能发送一份报告，避免了认证服务器收到报告时的混乱。

该框架将活动请求和定期报告相结合。在保证高并发性的前提下，不仅可以充分利用认证服务器的资源，支持大规模设备的验证，而且在需要时可以及时进行验证，实现高可扩展性和及时响应。

4.3 组验证

在证明服务器收到可信证据后，它做了一系列验证（更多细节显示在D小节），以确定VM_ML的可信度，它存储了VM组的可信信息。本小节讨论了如何基于可信的VM_ML实现对虚拟机的分组验证。

得出是否信任或不信任虚拟机的结论是验证VM_ML是否符合预期。在云数据中心至少有两台云服务器，每台服务器至少有一个虚拟机，也就是至少有两个虚拟机image。因此，我们构建一个虚拟机image期望搜索树（IET）。IET是一棵以T为根，以云服务器序列为子的搜索树。然后根据云服务器和云服务器上的虚拟机序列来构建搜索树。虚拟机序列与虚拟机image的期望值一一对应。例如，云数据中心有两个云服务器，每个云服务器上有三个虚拟机，如图4所示。其中，S1和S2代表服务器序列，I11和I12等代表虚拟机image的期望。

当云服务器向认证服务器注册时，根节点下会生成一个新的子节点S。此后，当证明服务器验证虚拟机的可信度时，它将通过二进制搜索算法从根节点搜索相应云服务器的子节点。在这个子节点下，每个虚拟机image都被更新和验证。目前，分组验证只实现了对虚拟机image的验证，以确保虚拟机启动时的可信度。因此，我们假设虚拟机在运行时是可信任的。如算法1所示，我们的方法根据VM ML条目中的状态来验证和更新VM的image。它在虚拟机启动前验证image的可信度，并在其他状态下更新image的预期。因此，云服务器上的所有虚拟机都根据VM_ML进行验证，以实现群体验证。

只有虚拟机启动时验证，其他情况都是更新VM的值。

4.4 远程证明的过程

基于上述三个关键技术，本小节以定期报告过程为例，描述CloudTA的完整远程认证过程，如图5所示。

在步骤1中，云服务器中的TAC定期向认证服务器发送一个消息，请求一个随机数（nonce）。在步骤2中，认证服务器验证该云服务器是否已经注册。如果已经注册，认证服务器在步骤3中向TAC发送一个包含不可预测的随机数（nonce）的请求。

在步骤4中，TAC收集由Tboot和IMA生成的物理平台的可信证据和由IMG生成的虚拟机组的可信证据。TAC首先通过执行TPM Quote来收集TPM的签名，TPM Quote使用私钥AIKpriv来签署选定的PCRs和nonce，其中PCR指的是PCR0-7（Tboot）、PCR10（IMA）和PCR12（IMG），而nonce最初由认证服务器提供。接下来，TAC还收集了IMA和IMG的测量日志以及PCR12的历史值（即PCR12 history）。TAC在步骤5中对这些证据进行了回应。

在步骤6a中，认证服务器首先检索可信证书cert(AIKpub)以确定TPM的身份，然后验证签名以检测PCR的篡改。此外，它通过比较nonce是否与步骤3中的nonce匹配来验证响应的新鲜度，以防止重放攻击。

在步骤6b中，认证服务器通过遍历ML并重新计算PCR（模拟PCR扩展操作），并将模拟PCR与可信PCR10进行比较，来检查ML的可信度。此外，在步骤6c中，认证服务器通过方程（1），用VM ML中的测量值扩展PCR12的历史，计算出模拟PCR值。如果最终的模拟PCR等于可信的PCR12，则VM_ML被信任。

在步骤7中，认证服务器根据其从原始无恶意软件系统中收集到的预期验证ML，以确定物理平台的可信度。最后，认证服务器通过分组验证来验证虚拟机。

图6显示了远程验证的结果，其中另一个镜像用不同的配置替换了虚拟机（instance-00000037）。结果显示，一个证明可以验证多个虚拟机，而虚拟机（instance-00000037）是不被信任的。此外，当点击图6中的请求时，平台管理员会主动验证特定的云服务器。

5 评估

本节从效率和可扩展性方面对CloudTA系统进行评估。CloudTA的原型是基于IBM 2.0 ACS[21]。云服务器运行Ubuntu 18.04和64GB内存，集成了TPM模拟器（ibmtpm1637）来模拟TPM的功能，并安装了经过我们修改的Libvirt（4.0.0）来执行分组的完整性测量。验证服务器是Ubuntu 18.04，96GB内存，64个处理器核心。ACS的验证程序被修改以支持我们的分组验证。最后，一个基于半同步/半同步模型的混合高并发网络通信框架被实施，它结合了主动请求和定期报告。

本小节通过比较TVP-PCA、VMI RA和CloudTA三种方案来分析其效率。其中，TVP-PCA是一个分别验证虚拟机和管理程序的方案。VMI RA是一个通过VMI实现的基于hypervisor的方案。CloudTA是本文提出的一种基于分组验证的方案。表一显示了这三种方案在完整的虚拟机远程验证中的通信开销、验证的虚拟机数量以及TPM Quote的执行时间。在远程验证中，云服务器和验证服务器之间的数据交换被称为interaction。

(不考虑连接的创建和释放）。n是云服务器中的虚拟机数量。

可以看到TVP-PCA只能验证一个，需要两次TPM_Quote操作，VMI是验证n个虚拟机，需要n+1次，CloudTA则只需要1次。

最后验证了32个线程下的性能，可以支持10000个虚拟机的验证。

未来打算：将对KVM事件进行分析，并结合机器学习技术，在运行时对虚拟机进行分组验证，构建一个完整的大规模虚拟机远程认证系统。

6 总结工作

1. 采用基于Hypervisor的虚拟机的批量远程证明。IMG+TAC。
2. 做了一个高并发的通信框架，方便传输信息。