本文是对 ACSAC '23 论文《Remote attestation of confidential VMs using ephemeral vTPMs》的总结，以及个人的理解和思考。

解决的问题

机密虚拟机（CVM）技术为虚拟机提供一个隔离环境，防止受到 hypervisor 等高特权软件的干扰。但是这样的隔离机制作用于虚拟机运行时，在虚拟机启动过程中，此时的完整性（intergrity）保护依赖于度量启动（measured boot）和运行时证明（runtime attestation）。运行时证明需要一个硬件信任根，在物理机上，TPM 芯片可以作为这样的信任根。然而在云计算环境中，云服务提供商通过设备模拟的方式给用户提供 vTPM，使用这样的模拟设备需要信任云服务提供商，这与 CVM 的威胁模型不符。

本文作者提出了一种方法，借助 AMD SEV-SNP 技术，在 CVM 内部模拟一个 vTPM，而无需信任 hypervisor。具备以下安全要求：

  • 隔离性：既与 guest 隔离又与 host 隔离。
  • 安全通信：与物理 TPM 的通信是硬件级隔离的，因此 vTPM 的通信也必须是安全的。
  • 持久化状态：物理 TPM 的状态在设备被制造时确定并受到硬件保护，vTPM 的状态应该应该由云租户来保存，与云服务提供商隔离。

设计与实现

SVSM-vTPM 的架构图和组件构成如下：

隔离性

作者利用了 SEV-SNP 所引入的 VMPL 机制：基于 AMD 官方的 VMPL0 管理程序：SVSM 进行扩展，来同时实现与 guest 与 host 的隔离。其中，由于 vTPM 涉及到一些对时钟、随机数生成和加密库的需求，而 SVSM 又是一个裸金属（bare-metal）程序，需要手动移植一些库函数。

安全通信

在 CVM 环境中用一块专门的内存空间（如一个页面）来完成 guest 内核与 vTPM 的通信：每当 guest 内核需要向 vTPM 发送请求时，就向该页面中写入数据，然后将触发虚拟机退出到 hypervisor，hypervisor 调度 VMPL0 的状态执行，VMPL0 中的 SVSM-vTPM 处理程序根据 CVM 的命令进行相应的响应。

上述通信过程的安全性由 SEV-SNP 特性所保证：guest 内核和 SVSM-vTPM 同属一个 CVM 环境中，内存是共享的，而对于 hypervisor 来说是加密的。因此即便 guest 内核与 SVSM-vTPM 的切换需要经过 hypervisor，这个过程仍然是安全的。而且 SEV-SNP 的硬件特性还确保了 hypervisor 在恢复虚拟机执行时只能恢复到 VMPL0 的上下文，从而防止 hypervisor 抑制 guest 内核发送的 TPM 请求，除非它让整个虚拟机都停止工作。

持久化状态

与物理 TPM 将它的状态保存在芯片内部的非易失性存储器不同，vTPM 必须依赖于一个磁盘中的文件（以下称为 NV 文件）来实现这样的持久化，并且与 vTPM 的模拟软件一样，NV 文件也必须位于可信环境中。

一种实现方式是：对 NV 文件进行加密，并由用户保存密钥，依赖于 CVM 安全启动机制，在 CVM 启动阶段进行注入。但这会带来一定的系统复杂性。

作者使用了一种更为简单实用的做法：短时 vTPM（Ephemeral vTPM）。该 vTPM 会在每次启动时创建新的种子和密钥，无需存储持久化的状态。

无持久状态的短时 vTPM 应用场景受限，对于那些需要跨重启周期使用相同密钥的应用场景（例如全盘加密、数据密封等），短时 vTPM 可能无法直接满足需求。

全盘加密

全盘加密（Full disk encryption, FDE）通过加密的方式保护磁盘数据，而加密密钥本身也需要进行加密并持久化保存，对磁盘密钥的加密通常由 TPM 中的存储根密钥（Storage root key, SRK）来完成。

而在短时 vTPM 中，没有持久化的 SRK，因此不能用传统方法实现 FDE。

作者实现基于短期的 eSRK 密钥实现对持久化磁盘密钥的保护所提出的方法，个人并没有太理解。疑惑的点在于：Kisk 是不是依据某种算法稳定生成的（每次都相同）？否则如何利用它来将固定的磁盘密钥 Dk 进行解密？上次运行时用 eSRKpub 进行加密的 Kisk，如何能在本次运行时用 eSRKpriv 进行解密？

这部分内容可能得等对 TPM 有一个更深入的理解后才能解答。