远程证明_02_TRIGLA V：公共云中虚拟机运行时完整性的远程验证_自我总结

61次阅读

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

title: 远程证明_02_TRIGLA V：公共云中虚拟机运行时完整性的远程验证_自我总结 date: 2022-05-15 23:08:18.466 updated: 2022-05-15 23:10:34.113 url: /archives/yczm02zj categories:

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

1《TRIGLAV: Remote Attestation of the Virtual Machine’s Runtime Integrity in Public Clouds》， CCFC，2021。

1.1 要解决的问题

这篇论文提出了一种协议TRIGLAV，可以让租户建立VM中软件及其软件配置的运行时完整性的信任。

文章中提到，vTPM不能直接运用在云中，因为攻击者可以篡改vTPM和VM之间的通信，例如重新配置网络，发动中间人攻击，重置TPM。

这篇文章提出的这种远程证明协议，可以在不改动VM中运行的程序，可以限制主机操作系统中管理员的活动，租户可以使用不支持可信硬件的设备连接到VM进行认证，当租户通过SSH登录到VM时，隐式的发生了对虚拟机的认证。

传统vTPM设计中所存在的问题：

1）Hypervisor通过4个字节的标识符标识vTPM，通过Hypervisor将VM的通信路由到对应的vTPM实例上，攻击者可以修改网络包，实现vTPM的错误路由，这个链路不安全，该篇文章提出使用TLS解决这个问题（图1a）。
2）要经过Hypervisor，但是Hypervisor和vTPM之间缺乏认证，存在中间人攻击，攻击者可以配置hypervisor，使其通过中介软件与vTPM进行通信，从而拦截通信（图1b）。然后，可以放弃任意的测量或执行TPM重置攻击。
3）攻击者还可以入侵客户机操作系统，伪装成正常的VM，修改其中的TPM驱动，将TPM请求重定向到远程的TPM上。这种情况下，验证者无法知道，连接到的是底层的vTPM还是远程的TPM，因为在虚拟机内的验证者无法与vTPM建立安全通信。该文通过了TEE认证协议，在vTPM和验证者之间建立了一个安全的信道，并利用它交换了一个秘密，验证者就可以唯一地识别vTPM实例了。

1.2 TRIGLAV 架构

它由以下四个部分组成。(A)虚拟机VM，(B)管理虚拟机的Hypervisor，使其能够访问物理资源并与其他虚拟机隔离，(C)实现管理程序运行时完整性执行和认证的可信计算组件，(D)TRIGLAV，在TEE内执行的软件，允许租户认证并执行虚拟机的完整性。文章中采用的可信执行环境TEE是SGX。

1）云服务提供者先启动云节点，启动TRIGLAV。然后在租户的请求下，创建一个虚拟机VM实例。
2）接下来，租户tenant首先与TRIGLAV建立信任，这是远程证明第一个被信任的组件。（如何建立信任？）租户请求TRIGLAV检查虚拟机监控程序Hypervisor是否符合策略。（这个策略下面会提到）该策略包含租户特定的信任约束，例如完整性度量等。
3）TRIGLAV使用IMA和TPM来验证平台的运行时完整性是否符合策略，然后生成虚拟机VM的公私钥，并将公钥返回给租户。TRIGLAV保护对私钥的访问，即仅当平台与策略中定义的状态匹配时，它才允许VM使用私钥。
4）最后，租户和VM建立信任。租户通过验证VM是否可以使用与之前获得的公钥相对应的私钥。对于VM认证租户，使用租户的SSH私钥以标准方式进行身份验证。将租户的SSH公钥嵌入到虚拟机的映像中，或在虚拟机部署期间提供。

1.3 VM启动过程

上述架构中如何解决Hypervisor和vTPM之间的问题，如何避免中间人攻击呢？因为Hypervisor不像TRIGLAV在TEE内，所以TRIGLAV无法使用TEE证明来验证Hypervisor的身份，因此该篇文章提出，TRIGLAV通过要求管理程序在建立连接时出示一个秘密来确认管理程序的身份。这个秘密是TRIGLAV在TEE内生成的一个秘密，并使用硬件TPM密封。

TRIGLAV 在TEE需要生成多个模拟TPM，因为多个VM不能共享一个硬件的TPM。当TRIGLAV被Hypervisor请求时，会生成一个新的模拟vTPM实例，该实例通过一个单独的TCP端口访问。Hypervisor会将连接到的模拟TPM，并将其作为一个标准的字符设备暴露给虚拟机VM。

总结如下：

1）在管理程序生成一个虚拟机之前，它命令TRIGLAV生成一个模拟TPM。
2）TRIGLAV创建一个新的模拟TPM，生成一个秘密，使用硬件TPM将秘密密封。之后TRIGLAV将TCP端口和密封的秘密返回给管理程序。
3）管理者从硬件TPM中解封秘密。
4）并用这个秘密建立一个与模拟TPM的TLS连接。
5）Hypervisor创建了一个虚拟机。虚拟机启动后，固件和IMA会将完整性度量发送给模拟TPM。
6）为了防止回滚攻击，每次完整性测量都会导致模拟TPM增加基于硬件的单调计数器（MC），并将当前MC值存储在模拟TPM内存中（⑥）。

1.4 信任如何建立

租户通过三个步骤建立起对云中虚拟机的信任：

他验证TRIGLAV在TEE内执行，并在真正的硬件（提供TEE功能的CPU）上运行。
他通过利用TRIGLAV验证和执行主机和客户操作系统的运行时完整性，将信任扩展到管理程序和虚拟机。
他连接到虚拟机，确保它是由TRIGLAV提供和控制的虚拟机。

第一步信任建立使用基于TLS的SGX认证，通过第三方CA签署证书认证。

上述步骤中，租户需要验证VM是拥有SSH私钥的VM，而私钥从没有离开过TRIGLAV，相当于TRIGLV需要认证VM的来源，由VM来实现对VM的运行时完整性度量认证。一旦握手成功，就相当于租户建立了对VM的信任。

1.5 策略如何确保运行时完整性

通过1.4描述可以知道TRIGLAV通过策略实施机制来确保VM运行时的完整性符合策略。在主机操作系统上，TRIGLAV依靠IMA来防止主机内核加载到未经数字签名的内存文件中。具体来说，文件系统中的每个文件都有一个存储在其扩展属性中的数字签名。在内核将文件加载到内存之前，IMA 会验证云提供商发出的签名。签名验证所需的证书从 initramfs（由 DRTM 测量）加载到内核的密钥环。存在问题。

在Guest操作系统中，Guest OS内核中的IMA需要TRIGLAV批准才能将文件加载到内存中。

1.6 如何制定策略呢

我们现在知道，一个VM的完整性、策略是和一对SSH公私钥绑定的。每个租户都可以通过公私钥确定VM的完整性。

作者给了一个策略清单的示例：

它包含了Host和Guest两个部分，包含硬件TPM制造商的证书链的白名单（第4行），证书链被用来建立对底层硬件TPM的信任。Host内核的DRTM完整性度量（第6-8行），Guest内核的完整性度量（第14行），以及Guest OS 的合法运行时完整性度量（第16-18行，22行）。TRIGLAV将DRTM完整性度量值与TPM认证的PCR值进行比较，以确保加载具有启用完整性强化机制的正确的Hypervisor。TRIGLAV使用运行时完整性测量来验证是否只有预期的文件和软件被加载到客户操作系统内存中。专用证书（第22行）使完整性强制机制变得实用，因为它允许更多的文件被加载到内存中而不需要重新部署策略。具体来说，只要用相应的私钥对允许执行的软件进行签名，就可以让软件通过完整性强化机制（这个机制指的就是策略实施机制，因为不满足策略的软件是不会被加载入内存的）。额外的证书（第11、23行）允许操作系统的更新。

1.7 具体实现

Qemu+KVM作为Hypervisor，使用SGX作为TEE技术。

具体的TRIGLAV分为三个组件：监控服务、模拟TPM和单调计数器服务。

1）监控服务是利用Linux IMA和硬件TPM来收集主机操作系统的完整性测量的组件。每个主机操作系统只有一个监控服务在运行。在一个端口上暴露出由TLS保护的API，由租户来部署策略。这部分还包括，生成秘密、密封秘密、提供秘密给模拟TPM。
2）模拟TPM：一个基于软件的TPM仿真器，基于libtpms库。它暴露了一个基于TLS的API，允许QEMU进行连接。这个秘密就是1）中的秘密。
3）单调计数器服务（MCS）提供对硬件单调计数器（MC）的访问。他利用硬件TPM来提供MC功能。MCS依靠TPM证明与提供硬件MC的TPM芯片建立信任，并依靠加密和认证的通信渠道来保护与TPM芯片从飞地通信的完整性和保密性。MCS通过TLS暴露了一个REST API，允许其他enclave远程增加和读取硬件单调的计数器。