远程证明_04_虚拟化环境的安全认证

63次阅读

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

title: 远程证明_04_虚拟化环境的安全认证 date: 2022-05-26 22:07:48.437 updated: 2022-05-29 23:44:45.679 url: /archives/远程证明04虚拟化环境的安全认证 categories:

远程证明 tags:
可信计算
远程证明

原文信息

文章标题：Secure Attestation of Virtualized Environments
文章中文翻译：虚拟化环境的安全认证
文章等级：CCF C
文章发表时间：2020
文章作者：Eckel M, Fuchs A, Repp J, et al.
完整引用：Eckel M, Fuchs A, Repp J, et al. Secure attestation of virtualized environments[C]//IFIP International Conference on ICT Systems Security and Privacy Protection. Springer, Cham, 2020: 203-216.
全文请查看：全文链接

1 介绍

OPEN CIT
pTPM vTPM

本文分析了现有的虚拟环境认证方法。我们对现有的单独认证方法进行了改进，增强了它对中继攻击的抵御能力。我们实现了Lauer和Kuntze提出的基于虚拟机监控程序的认证方法，以及我们改进的独立认证方法。最后，我们通过在生产级硬件上的性能度量来评估这两种方法的可行性。

2 相关工作

现有的关于认证虚拟化环境的研究主要集中在提供虚拟化环境的隔离认证或单个虚拟机的认证。有些人提出了更复杂的解决方案，试图构建一个可信的虚拟机监视器(VMM)。

这些方法之一是来自Garfinkel等人的Terra。Terra通过虚拟机之间的隔离来保护虚拟机。它在加载单个内存块之前测量它们，并允许对外部评估人员进行远程认证。这种内存自省方法是计算密集型的，需要大量的主存。然而，Terra构建了许多其他工作的基础，这些工作进一步阐述了保护VM内存的想法，如Cerberus和TrustVisor。

其他方法，如Azab等人的基于hypervisor的完整性测量代理(HIMA)，测量运行在VM中的程序和服务。在被hypervisor执行之前，VM系统调用和硬件中断被拦截和分析。它需要hypervisor上的NX位(无执行位)支持，以便在测量的内存页执行之前标记它们。HIMA要求将程序的所有内存页加载到内存中。因此，必须对操作系统进行更改。HIMA需要大量的计算能力，必须仔细评估其适用性。

目前已有基于CPU的认证方式实现软件完整性保护，如Bastion、HyperWall等。这些CPU扩展允许在软件模块执行之前测量和验证它们，Zhang等人在中分析了它们对云解决方案的适用性。

由于基于TPM的内存验证技术很慢，因此希望以资源高效的方式为vm提供TPM功能。中的工作在VMM中引入了一个抽象层，在pTPM中添加了上下文切换功能。这给vm提供了一种错觉，即具有对真实pTPM的独占访问权。这种方法的问题是，与多个vm共享一个物理TPM会使pTPM成为瓶颈。随着Berger等人引入vtpm, vm的认证发生了一定的变化。有了vtpm，就可以在软件中为每个VM提供自己的TPM, TPM被安全地固定在pTPM中。自从2006年引入vTPM以来，Berger等人对它的实现做了细微的改变，将它变成了一个hypervisor扩展。因此，不需要额外的管理VM。由于vtpm的有效性，许多研究人员现在关注于集成vtpm来验证运行在vm中的软件。vm和vtpm的迁移是研究的另一个热点。

现有的大多数研究将vm和hypervisor的认证分开处理，几乎没有将这些认证绑定在一起的研究。验证者通过远程认证验证虚拟机的完整性后，才会信任虚拟机。但是，如果底层管理程序受到威胁，VM的完整性和可信性也可能受到威胁。如果攻击者设法破坏管理程序，她可能能够提取或操纵敏感信息，例如篡改VM主内存。

TCG (Trusted Computing group)的虚拟化平台工作组定义了一个深度认证方案，用于链接vm和hypervisor的认证。在《Remote and deep attestations to mitigate threats in cloud mash-up services》.中，Celesti等人描述了如何使用远程和深度认证来构建联邦云环境。

Lauer和Kuntze提出了基于hypervisor的认证(HYPA)[12]。它向管理程序添加了一个认证管理器(ATAMAN)，它直接读取运行的vTPM实例的内部状态。该方法属于自底向上的认证方法，目的是在运行数十或数百个虚拟机的情况下提高虚拟机认证的可伸缩性。

在HYPA进程中，验证者向hypervisor发送一个认证请求(参见图1)。作为回报，它接收一个认证响应(9)，包括所有运行的vm(2-7)以及hypervisor本身的认证(8)。

Attestation Manager直接访问正在运行的vTPM实例以读取其内部状态，即vPCR。此外，它还从每个虚拟机内部读取虚拟存储的测量日志（vSML）。所有的vPCR和vSML被编译成一个数据结构，然后进行散列。由此产生的摘要被作为限定数据（nonce）传递给TPM Quote操作的管理程序证明，使用pTPM。认证管理器在hypervisor的范围内运行，因此，它是hypervisor认证的一部分。整个验证结果包括带有vPCR和vSML的数据结构，以及hypervisor的证明。Verifier同时验证hypervisor和VM的认证。

基于管理程序的证明方法的主要好处是，与单个虚拟机的证明相比，其可扩展性有了巨大的提高。这体现在减少了证明协议的开销，以及减少了I/O操作。然而，它非常具有侵入性，需要访问当前运行的vTPM实例，以及访问虚拟机内部，即vSMLs。

虚拟机和管理程序的单独认证（SEPA）是Lauer和Kuntze在中描述的另一种方法。验证者向单个虚拟机（参见图2）发送一个验证请求，并收到一个验证结果（2）。然后验证者使用相同的nonce向管理程序发送验证请求（3），并收到验证结果（4）。通过使用相同的nonce，在虚拟机和管理程序之间实现了一个弱层链接。

正如作者所述，SEPA方法不是资源节约的，并使pTPM成为连续VM认证期间的瓶颈。每个单独的VM认证还需要额外的管理程序认证，这大大降低了这种方法的可伸缩性。另一个问题是层链接不是很强，Verifier需要不断更新VM运行的管理程序的信息。由于这种层链接既不是强制的，也不是可验证的，它破坏了pTPM和vTPM的强认证声明。Lauer和Kuntze提出了一种改进VM和hypervisor之间链接的方法，即向VM提供一个秘密值N，用于生成远程认证数据。虚拟机终止后，通过虚拟机与hypervisor之间的安全通道，向hypervisor提供一个秘密值N。然后，系统管理程序使用这个秘密值进行认证。这种方法的缺点是，Verifier不能平等对待VM和hypervisor。它需要更改来宾操作系统和管理程序。因此，使实现复杂化并降低了可伸缩性。

SEPA不需要更改现有的软件组件或协议，因此可以轻松地集成到现有的认证解决方案中。从Verifier的角度来看，可以平等地对待vm和hypervisor。在只运行少量虚拟机的系统中，这种方法代表了一种可行的认证解决方案。然而，我们注意到Lauer和Kuntze提出的单独认证会受到中继攻击。

还有其他更复杂的云完整性验证技术，但它们依赖于前面描述的技术。在下一节中，我们将介绍我们的参考体系结构，我们将使用它进一步评估SEPA和HYPA方法。

3 参考系统架构

我们的参考架构是基于英特尔和Hytrust在中提出的架构，该架构将数据分割成工作包来并行处理它们（参见图3）。我们建议使用虚拟机来实现这一目的，它可以根据当前的需求灵活地生成和拆分。工作流编排系统处理工作包的分配和调度。我们假设主机系统和虚拟机是由同一方拥有和运营的。

在将可能敏感的工作包委托给VM处理之前，工作流编排确保VM是可信的。这个过程很复杂，需要对特定VM的配置有深入的了解。这就是为什么Verifier专用于这个任务。它对主机和虚拟机进行验证，为工作流业务流程提供最新的完整性信息。验证者维护一个参考完整性测量(RIMs)数据库，代表已知的良好系统配置。通过与系统当前的运行状态进行比较，验证者可以判断主机和虚拟机是否可信。

基准库

主机配备pTPM，运行Linux操作系统。它们有一个支持tpm的BIOS和引导加载程序，并支持用于引导时间完整性的Measured boot，以及用于运行时完整性的Linux integrity Measurement Architecture (IMA)。虚拟机管理程序支持分配给虚拟机的vtpm，如QEMU/KVM。vTPM在hypervisor上下文中执行，一个vTPM被分配给一个VM。vtpm提供与ptpm相同的功能。然而，他们缺乏真实随机数生成器(TRNG)以及来自TPM制造商的背书密钥证书(EK Cert)。此外，它们不能提供与pTPM相同的安全保证，因为它们只是软件。

4 认证要求

Coker等人已经假设了基于远程认证的解决方案的需求。Lauer和Kuntze在中对它们进行了分析和扩展。这些要求中的第一个是认证信息的新鲜度，这要求保持测量时间和使用时间之间的差距尽可能小，以最大限度地减少使用过时信息的风险。下一个要求是认证的全面性，使验证者能够以可复制的、可问责的和全面的方式推断系统的状态。认证信息还必须以逻辑形式呈现，以帮助验证者随着时间的推移将多个认证关联起来，从而进一步改进对不当行为的检测。由于认证公开了关于目标系统的敏感信息，因此它们的公开必须仅限于有效的验证者。为了在认证中建立信任，验证者依赖于可确保报告数据真实性和完整性的交付机制的可信性。

在云认证方面，Lauer和Kuntze进一步要求vm和hypervisor之间的层链接，以便信任vm认证。因此，必须为VM和hypervisor提供有效的认证信息。为了确保VM在其指定的管理程序上运行，必须能够将这些关联起来。Lauer和Kuntze的另一个要求是认证方案的可扩展性，它针对的是具有大量虚拟机的系统。就基于tpm的认证而言，这意味着减少对pTPM的调用数量。

此外，我们提出了特定于实现的需求：实现复杂性（Implementation Complexity） 和 客户机独立性（Guest Independence）。

实现的复杂性：根据使用的认证方案和获取认证信息的方式，需要对客户OS或vTPM进行修改，这将增加开发成本。这也适用于在客户系统内安装其他软件，尽管这些并不像操作系统代码更改那样被认为是至关重要的。在典型的云环境中，客户希望根据应用程序需求选择软件和操作系统，而不是根据是否存在附加安全工具的实现。必须考虑到这些工具的影响和侵入性。越小、越少干扰的工具越容易移植。巨大的代码变化和对其他软件的依赖可能会在移植中产生更大的障碍。还必须考虑到软件所需的系统特权。
客户机独立性。为了减少攻击面，认证解决方案必须依赖尽可能少的附加基础设施。对其他基础设施的依赖关系也会影响解决方案的整体可靠性。增加实现的复杂性，导致系统变得更容易出错。不那么复杂的解决方案更容易维护。

5 安全独立的认证

在分析SEPA方法[12]时，我们发现VM和hypervisor之间的层链接机制存在缺陷。攻击者可以发起中继攻击来生成可验证的VM认证，从而欺骗验证者信任一个Bad VM。

我们假设一个威胁模型遵循[9]中Dolev和Yao的定义。攻击者完全控制网络，因此可以在网络上的任何地方读取、修改、插入或阻止消息。但是，她不能破坏任何底层的密码原语。而且，攻击者能够控制在VM中运行的系统，但不能控制hypervisor。

为了发起攻击，攻击者在目标系统的边界之外操作自己的虚拟机监控程序主机(Attacker Controlled System)，如图4所示。在该系统上，她运行VM的原始副本以及相应的vTPM，包括其配置和密钥。她进一步获得对原始系统上的虚拟机的访问，通过这种方式，她可以修改和运行内部被破坏的软件(参见图4中的bad VM)。

图4显示了中继攻击过程的时序图。每当验证者(V)向虚拟机发送它的认证请求时，Bad VM将这个请求转发给攻击者控制的系统上的原始虚拟机。从那里，VM将请求转发给它的vTPM, vTPM生成一个VmAttestation。VM将这个响应返回给Bad VM，Bad VM最终将VmAttestation转发给验证者。在原始系统上的hypervisor的后续认证中，将使用pTPM。验证者反过来验证两个认证，错误地认为Bad VM值得信任。

我们通过使用vTPM本身作为到管理程序的可信通道来解决中继问题。每当VM收到来自Verifier (V)的认证请求时，它会像往常一样在vTPM上触发TPM Quote操作(参见图5)。此时，为了缓解这一问题，我们让vTPM在hypervisor(3)上存储vTPM报价结果(VmAttestation~~hash~~)的散列。然后，继续正常的流程，VM将VM认证结果返回给验证者。

随后，验证者向hypervisor发送一个认证请求。hypervisor为VM使用最新的VmAttestation~~hash~~，并将其包含在hypervisor认证中。为了达到这个目的，hypervisor通过VmAttestation~~hash~~对来自Verifier的nonce的连接进行散列，从而创建一个复合nonce。这个复合nonce用于pTPM上的TPM Quote操作。结果返回给验证器。验证者验证虚拟机认证哈希是否匹配。为此，它创建一个从VM认证接收到的VM认证数据(VmAttestation)散列。Verifier与hypervisor完全相同地生成nonce，并将其与来自hypervisor认证数据的复合nonce进行比较。只有当复合认证匹配时，验证者才能确定收到了正确的虚拟机认证。通过这种方式，VM和hypervisor之间的层链接得到了显著改进。之后，Verifier继续验证VM和hypervisor的认证。

这种方式存在将指定给虚拟机的数据泄露给其他虚拟机或未经授权的第三方的风险。我们认为这种风险是最小的，因为认证方法确保VM和底层hypervisor主机都是值得信任的。可以使用加密和访问控制机制等其他安全措施来进一步保护转发的散列。不受信任的虚拟机监控程序可能会泄露从vTPM转发的信息，但会使用SEPA方案检测到。

6 实现

内存内省方法是计算密集型的，需要大量的主存，而且不容易实现。拦截从虚拟机到主机操作系统的系统调用需要更改hypervisor和主机操作系统。因为它们违反了我们的许多需求，所以我们不认为它们是我们实现的候选者。分层链接是至关重要的，我们选择SEPA和HYPA来实现，两者都符合我们的要求。

我们将SEPA和HYPA作为单一的概念验证来实现，扩展了英特尔的Open CIT 2.2。Open CIT提供主机启动时间认证功能，并使用Intel Trusted Execution Technology (TXT)建立硬件测量信任根(RTM)。支持VMware ESX、Citrix Xen、KVM (Kernel-based Virtual Machine)、Microsoft HyperV等hypervisor。认证信息通过web界面呈现。

Open CIT由两个主要组件组成：认证服务器(Attestation Server)和信任代理(Trust Agent)。认证服务器充当远程认证的验证者。它维护带有RIMs和认证结果的数据库，并通过REST API向依赖方公开这些结果。信任代理在任何经认证的计算机上运行，处理来自认证服务器的认证请求。即执行TPM Quote操作，收集并返回存储的测量日志(SMLs)。

我们向Open CIT添加了对验证VM的支持，包括HYPA和我们改进的SEPA层绑定机制，以将vm与其底层hypervisor关联起来。这需要同时更改信任代理和认证服务器。我们开发了一个vTPM实例管理器来为vm提供vTPM，使用QEMU和Stefan Berger的vTPM实现，以适应我们的需要。也就是说，对于HYPA，我们向hypervisor的Trust Agent添加了平台配置寄存器(PCR)读访问，对于SEPA，我们在hypervisor文件系统中存储VM认证散列。为了让HYPA访问vm中的vSML，我们使用hypervisor上的VirtIO与VM共享一个tempfs文件夹。此外，我们还添加了对IMA运行时完整性验证的支持。需要修改认证服务器、信任代理和虚拟机操作系统。

7 评估

在本节中，我们评估SEPA和HYPA认证方法。hypervisor主机使用libvirt、KVM和QEMU 2.6进行虚拟化。所有机器都运行Ubuntu 16.04。客户端虚拟机和hypervisor运行定制的Open CIT信任代理。为了比较SEPA和HYPA之间的性能度量，我们基于Open CIT为验证vm和hypervisor所执行的典型操作定义了评估场景:

验证所有虚拟机;
验证单个VM;
验证Hypervisor。

7.1 Evaluation Criteria 评估标准

执行时间。为了比较基于执行时间的认证方案，我们测量了每个场景的总体执行时间。这包括认证请求生成、响应处理、验证和网络传输。由于Open CIT在后端生成和验证TPM Quote响应会产生大量的开销，因此我们还要度量这两个事件完成所需的时间。
网络流量。对于每个评估场景，我们捕获三个后续认证的整个网络流量。对于从authentication Server到hypervisor主机或VM的每个连接，我们计算接收和传输的数据量、吞吐量率以及第一次和最后一次传输之间的时间。在总结中，我们只包括所有连接的累计数据量。
CPU和内存占用率。对于每次尝试进行3次验证，我们以兆字节为单位测量常驻(非交换)物理内存消耗以及CPU利用率的百分比。根据不同的场景，使用Linux top命令每100毫秒测量一次authentication Server和Trust Agent，计算平均值和峰值。有些任务占用超过100%的CPU，这意味着它们占用一个以上的CPU核。

7.2 评估结果

在评估过程中，我们观察了这些方案的预期行为。表1显示了这些场景的测量执行时间。我们为每个场景生成10个度量值，并将它们积累到单个表中。也就是说，组中的每个值都是特定场景中所有测量执行时间的算术平均值。

表1数据显示，如果对所有虚拟机都进行了校验，则HYPA比SEPA快，因为它只对hypervisor进行一次校验。如果只验证了一个VM，或者只验证了hypervisor，那么SEPA要快得多。一个有趣的观察结果是检索TPM Quote响应和验证它所需的时间。这似乎在很大程度上不受已认证虚拟机数量的影响，SEPA显示了一个异常的最大值。然而，在实践中，如果要求的认证更少，或者IMA sml的规模变得非常大，那么HYPA的规模就会更大。当达到某个认证请求阈值(取决于虚拟机数量)后，SEPA的效率将低于HYPA。

对于CPU利用率，表3显示SEPA的平均CPU利用率和峰值总是较小，但一次验证所有vm除外。与SEPA相比，HYPA执行的认证操作更少，因此需要更少的CPU时间进行认证验证。表3中描述的内存消耗显示了意外的行为。在大多数情况下，HYPA比SEPA更有效。理论上，HYPA在验证时应该需要更多内存，因为它同时验证hypervisor和vm。我们只能用JAVA的垃圾回收来解释这种行为，或者是一般的操作系统内存管理扰乱了我们的测量结果。

表2显示，SEPA更有效地利用网络，直到达到认证请求的阈值。如果向hypervisor主机添加了更多的客户机vm，或者一次请求了更多的认证，那么HYPA将变得更高效。我们还测试了vm或底层hypervisor主机的完整性是否会影响测量结果。然而，我们无法找到非整数系统更昂贵的相关性或指标。结果是如此接近和难以区分，以至于这些差异可能是由不同的噪杂源引起的，从而导致测量的抖动，例如网络通信、其他应用程序和服务的主机利用率、Java Just in Time (JIT)优化、垃圾收集或操作系统调度。

我们还监控了客户端的Trust Agent。我们看不出这些方案之间有什么明显的差别。两种方案之间的CPU利用率和内存消耗没有差异。这也可能是由JAVA的开销和垃圾收集引起的。从逻辑上说，当认证管理器以SML和PCR值(需要加载到内存中)的形式收集认证信息时，内存消耗应该会稍微多一些。

两种方案的Nonce生成时间不同。HYPA需要更多的时间来收集和组合所有认证信息。它总体上是稳定的，只对方案的整体性能有很小的影响。随着运行虚拟机数量的增加，HYPA Nonce生成时间越长。因此，HYPA可能会在hypervisor Trust Agent上遇到可伸缩性问题。但只有在有许多客户机和非常大的SML的情况下。SEPA只有在许多主机需要在网络上进行认证时才有扩展性问题，但在单个信任代理上没有。

我们的结论是，对于少量VM, SEPA的性能优于HYPA。随着虚拟机认证次数的增加，SEPA性能下降。正如预期的那样，HYPA在所有测试中显示出稳定的性能。支持目标系统上的这两种认证方案，就可以定义有效的组合。

8 未来工作和结论

本文分析了现有的基于可信计算的虚拟环境认证方法。我们发现现有的单独认证方法在概念上存在安全缺陷。

通过提出安全的独立认证，加强了hypervisor和VM层之间的层链接。改进了原有的单独认证方式的安全特性，为防止中继攻击提供了有效的对策。我们在生产级硬件上实现并评估了基于管理程序的认证方法以及安全的独立认证方法。通过性能度量，我们强调了我们的方法对于运行数量有限的vm的系统的可行性。此外，我们指出，通过只需要对管理程序软件进行最小的更改，我们的安全改进允许保持标准的认证协议。

未来的工作方向包括安全分离认证在虚拟网络设备、雾（fog）和边缘计算中的应用。随着容器技术的发展，我们的方法在完全成熟的机器虚拟化之外的适用性是另一个有趣的研究方向。

正文完