私有云上虚拟TPM 的可信热迁移方案研究*

潘利华，兰清程，李雪兵，石元兵，张舒黎，任玉霞

（1.中电科网络安全科技股份有限公司，四川 成都 610065；2.可信云计算与大数据四川省重点实验室，四川 成都 610065）

0 引言

随着云计算的快速发展及大量应用，安全问题越来越受到重视，基于可信平台模块（Trusted Platform Module，TPM）[1]构建可信计算体系，能够保证云计算基础环境的完整性。同时，为了将信任链传递到虚拟机中，充分保障虚拟机的可信性，通常还为虚拟机提供虚拟TPM（virtual TPM，vTPM）。但TPM 本身是一种芯片接口规范，通常和一个物理平台强绑定，不支持在物理平台之间迁移。在云计算的应用场景中，若为每个虚拟机（Virtual Machine，VM）提供一个相应的vTPM，则vTPM 和传统的物理TPM（Physical TPM，pTPM）相比，除了要为VM 提供和pTPM 一样的功能接口，还要求vTPM 能够随着VM 的迁移而迁移，因此，需要一种VM-vTPM 迁移协议。

文献[2]提出了包含vTPM 迁移在内的功能要求、安全目标和参考的体系架构，但没有给出具体的协议设计和实现方案。文献[3-5]提出的vTPM迁移协议设计都没有对迁移请求来源做合法性检查，容易遭到拒绝服务攻击。文献[3-6]提出的vTPM 虚拟证书链扩展设计，不可避免地都需要在vTPM 迁移后重新生成部分密钥和证书。此外，以上文献基本停留在协议设计阶段，缺乏实际的实现方法。文献[7]在当时的开源组件基础之上提出了一种vTPM 热迁移的具体实现方法，主要解决了vTPM 数据从源平台传递到目标平台的具体实现，但缺乏考虑数据传递过程中的安全，且随着开源组件新版本的发布，当时的实现方法已不能完全适用于当下的开源组件。

本文在现有的开源组件基础之上，设计了一种新的基于内核的虚拟机（Kernel-based Virtual Machine，KVM）平台下的vTPM 热迁移协议及实现方法，主要贡献如下：（1）提出的vTPM虚拟证书链扩展设计可以避免vTPM 迁移后密钥和证书的重新生成；（2）提出的vTPM迁移协议设计及其实现方法包括对参与迁移方的双向远程可信证明和对vTPM 实例数据传输的安全保护，协议设计中对迁移请求来源的合法性检查能有效减轻源平台和目标平台在迁移过程中遭受的拒绝服务攻击。

本文结构如下：第1 节介绍TPM和虚拟化技术有关的背景知识；第2 节描述开源组件QEMU 中TPM 的实现方法并重点分析其在vTPM 热迁移方面存在的安全问题；第3 节提出一种改进后的VMvTPM 热迁移协议设计及实现方法；第4 节分析热迁移设计方案的安全性；第5 节给出结论和下一步研究重点。

1 背景知识

1.1 TPM

可信计算体系的可信根包括可信度量根、可信存储根和可信报告根，TPM 是可信计算平台的硬件可信根，它负责可信计算平台的安全控制和密码运算等功能。依据TCG 规范，可信根被无条件信任。基于可信根，在可信计算平台环境的每个转换过程中保持信任传递。可信根中的可信报告根（Root of Trust for Reporting，RTR）可以理解为背书密钥[8]（Endorsement Key，EK）及认证身份密钥[9]（Attestation Identity Key，AIK）。EK 密钥由TPM 厂商植入，在TPM中具有唯一性，TPM厂商证书签发机构（Certificate Authority，CA）为EK 密钥签发的EK证书可以用于建立并维持可信平台身份。AIK 密钥及AIK 证书可实现平台自身的身份证明，生成、提供完整性报告，保护报告值。

1.2 虚拟TPM

vTPM 具有TPM 的完整功能，此外，面对云计算环境特性，还提供系列vTPM 生命周期管理，包括安全迁移、快照等功能。vTPM 实例添加到VM 后，在客户机操作系统（Guest OS）中与使用pTPM 同样的方式方法使用vTPM，vTPM 使Guest OS 能够创建和存储专用密钥。对VM 的Guest OS 运行环境进行完整性保护，启用vTPM 可大大降低VM 的安全风险。vTPM 安全性应尽可能满足文献[2]等提及的可信计算相关标准规范，如vTPM 实例及vTPM 中的用户密钥、数据由pTPM 提供存储保护，迁移时由vTPM 管理器执行双向可信验证、数据机密性和数据完整性保护等功能。到目前为止，QEMU 等开源组件已经支持vTPM 功能，但还存在诸多安全缺陷，在后面章节会进一步分析开源组件QEMU 中的TPM 实现方式及其安全性问题。

1.3 QEMU

QEMU 是一个支持纯软件方式实现CPU 虚拟化、内存虚拟化和I/O 虚拟化等功能的用户空间程序，采用了硬件辅助虚拟化的KVM 技术，QEMU可以将CPU 和内存等虚拟化工作交由KVM 处理，自己则处理大多数I/O 虚拟化的功能，进而实现极高的虚拟化效率。此外，VM 的配置、创建、运行时的用户操作环境、跟用户之间的交互和一些针对VM 的特殊技术如动态迁移等是由QEMU 实现的。

QEMU 是众多不同种类Hypervisor 中的一种，不同Hypervisor 技术提供的VM 管理工具参数众多且差异较大。因此，在实际使用中，还需要一套对VM 进行管理的统一的编程接口。目前在Linux系统下与QEMU 广泛配合使用的管理接口程序是Libvirt，Libvirt 基于UNIX Socket 方式使用QMP 协议与QEMU 进行控制信息交互，已成为当下云计算平台环境中的虚拟化底层管理接口的事实标准程序。

1.4 虚拟机热迁移

虚拟机热迁移，也叫动态迁移或在线迁移，是在VM 运行同时进行迁移。虚拟机热迁移实现方式中，运行时的内存数据拷贝方法有预拷贝内存Precopy、内存后拷贝Post-copy、混合拷贝Hybridcopy 这3 种方式。源节点和目标节点间的数据传输通道有Libvirtd 隧道、HV 原生两种传输方式，迁移管理控制有受管理点对点迁移（一般是源节点主动控制）、受管理直接迁移（云管理平台控制）、不受管理直接迁移（如系统直接对HV 进行管理）、人工命令等方式。热迁移一般采用镜像实例文件共享的存储方式，不需要迁移镜像文件，只需将运行时内存数据搬移到对端。目前，大多数云平台基于Libvirtd 采用受管理点对点方式进行热迁移。

2 QEMU 中TPM 的开源实现

当前qemu-7.2.0[10]已经能够创建带有TPM功能的VM，其TPM实现分成前端和后端。前端是向VM 提供仿真硬件接口如TPM TIS[11]，后端连接宿主机上的TPM设备。如图1 所示，依据连接QEMU 后端的宿主机上的TPM设备的类型，可以将QEMU 中的TPM 实现方式分为TPM passthrough和TPM emulator 两种。

图1 QEMU 中的TPM 实现方式

2.1 TPM passthrough

TPM passthrough，也称TPM 直通方式，是直接将宿主机上的pTPM 提供给VM 使用的方式。优点是能为VM 提供硬件安全级别的TPM设备，缺点是pTPM 只能被该VM 独占，宿主机上的其他应用程序和其他VM 不能使用pTPM，而且此方式也不支持迁移。因此，在实际应用中很少使用。

2.2 TPM emulator

TPM emulator 即TPM 全虚拟化实现方式，连接QEMU 后端的是宿主机上的软件仿真程序SWTPM，在SWTPM 和QEMU 之间传递两类消息：一类是标准的TPM 命令消息，另一类是对vTPM 实例进行重置、初始化和迁移等操作的控制消息。该方式的优点是支持VM-vTPM 的迁移，并对宿主机上的VM-vTPM 个数也没有限制，但当前开源组件中的TPM 全虚拟化实现方式还存在如下几个明显缺陷。

（1）vTPM 跟pTPM 完全脱离。

（2）在VM 和vTPM 实例之间没有一对一的强绑定关系。

（3）vTPM 实例在磁盘空间的文件系统上的存储没有得到有效保护。

（4）VM-vTPM 的迁移实现方式存在如下安全问题。

①底层平台未进行双向可信证明：VM 在进行冷或热迁移时，迁移源和迁移目的双方未进行可信证实，迁移双方均无法判定对方平台的可信性，VM-vTPM 可能被迁移到不受信任的平台，信任关系无法保持。

②迁移保护密钥未得到有效保护：QEMU 跟SWTPM两进程之间的控制消息包括对vTPM实例信息的收集和恢复，支持对vTPM 实例信息的机密性和完整性保护，但保护密钥是以明文形式存放在源端和目标端的配置文件中，配置文件在源端和目的端之间的传输方式有多种不同安全级别的实现方式，使含有保护密钥的明文信息的配置文件有在网络上明文流转的风险。

③秘密信息未受到pTPM 保护：由于开源组件中的TPM emuloter 方式跟pTPM 完全脱离，vTPM实例信息在源端和目的端之间的传递未能受到pTPM 的有效防护。

目前开源组件中仅TPM emulator 方式支持vTPM 的迁移，本文剩余部分将针对目前开源组件中的vTPM 热迁移实现方法中的①②和③共3 点安全问题，提出一种新的vTPM 热迁移实现方案，并对改进后的方案做安全性评估。

3 VM-vTPM 可信热迁移解决方案

3.1 场景描述

私有云是云计算服务提供商（Private Cloud Provider，P）为特定组织在其内部建设的专有云计算系统。假设源服务器（Source Server，S）进行计划性停机维护或者出于负载均衡的考虑，为了不中断S 上VM 正在运行的业务，P 需要将正在运行的VM 从S 移动到目标服务器（Destination Server，D）。本文的研究场景如图2 所示，S和D 都支持pTPM且预先部署了EK 密钥和EK 证书，并假设EK 密钥和EK 证书是可以信任的，S 和D 上的每个VM都和一个纯软件实现的vTPM绑定在一起并形成VM-vTPM。P 需要将正在运行的VM-vTPM 从S 迁移到D，迁移过程中要考虑以下几点安全问题：（1）保证VM-vTPM 在迁移期间未被未授权篡改或损坏，并且关于VM-vTPM 任何有价值的信息都不能泄露给未授权者；（2）迁移请求必须是可信任的实体P 发起的；（3）迁移双方S 和D 的身份是可信的，并保证基础环境的完整性。

图2 研究场景

3.2 vTPM 证书链扩展设计

本节先介绍vTPM 证书链扩展的背景知识，然后提出证书链扩展设计方案。

3.2.1 vTPM 证书链扩展的背景知识

传统的服务器和pTPM是一对一的，在服务器上加入了虚拟化技术之后，服务器上会运行多个VM，每个VM 都有各自的vTPM。如果vTPM 是纯软件方式实现的，就需要在pTPM 和服务器上的多个vTPM 之间建立一种对应关系，并将信任链从物理平台扩展到虚拟平台。现有方法主要采用证书链来进行扩展，因此证书链的扩展设计至关重要。VM-vTPM 从源平台迁移到目标平台之前需要先基于扩展的证书链对迁移双方进行可信证实，在迁移完成后可能需要重新生成部分密钥和证书。好的证书链扩展设计应尽量减少密钥和证书的再生，以降低vTPM 迁移设计的复杂度。

3.2.2 vTPM 证书链扩展的设计方案

本节提出的证书链设计可以避免在VM-vTPM迁移完成后密钥和证书的再生，也能提供对vTPM实例的可信证明能力和对vTPM 管理器组件的可信证明能力。如图3 所示，所提设计引入了vTPM 管理器、可信第三方（Trusted Third Party，TTP）、SK 密钥、MIK 密钥和MIK 证书。

图3 vTPM 证书链扩展

（1）vTPM 管理器：负责为VM 创建vTPM 实例，并基于该vTPM 实例为其创建虚拟机背书密钥（virtual Endorsement Key，vEK），并且参与VMvTPM 热迁移的迁移引擎（Migration Engine，ME）也是vTPM 管理器的功能构件的组成部分。

（2）TTP：负责为vEK 密钥和MIK 密钥签发证书，同时对vTPM 管理器的可信性做验证和担保。

（3）SK 密钥：是pTPM 创建的不能复制的签名密钥。

（4）MIK 密钥：是本设计中为vTPM 管理器特别新增的一种密钥，是EK 密钥下的子密钥，其特点是不能复制，能对任意数据做加密、解密和验签运算，但签名运算受到TTP 的签名管控。

（5）MIK 证书：是TTP 为MIK 密钥签发的证书，证书的扩展项中包含了可信任的迁移控制器（Migration Controller，MC）的IP 和公钥等标识信息，还包含了SK 密钥的公钥信息。

具体流程如下：

（1）vTPM管理器需要调用pTPM创建MIK密钥，之后vTPM 管理器基于MIK 密钥、EK 密钥、EK 证书、平台配置寄存器（Platform Configuration Register，PCR）（含平台度量日志）和平台证书，向TTP申请MIK证书，其中PCR 用于创建物理平台及vTPM 管理器的可信凭据。

（2）TTP 利用pTPM 制造商的根证书验证EK 证书的有效性。基于平台厂商的根证书验证平台证书的有效性；基于EK 公钥验证pTPM 确是EK 密钥创建者的真实性；基于MIK 公钥和EK 公钥验证MIK 密钥确受到pTPM 物理保护的真实性；对vTPM 管理器利用pTPM 提供的可信凭据做可信判定，得出vTPM管理器及其所在底层物理平台的可信性结论。如果可信，才为vTPM 管理器的MIK 密钥颁发MIK 证书。

（3）vTPM 管理器为VM 创建相应的vTPM 实例，然后创建该vTPM 实例上的vEK 密钥，再基于vEK 密钥、MIK 密钥和MIK 证书，向TTP 申请为该vTPM 实例颁发vEK 证书。

（4）TTP首先检查MIK 证书的合法性，进而确定vTPM 管理器的身份合法性；其次基于MIK 公钥验证vTPM 管理器确是MIK 密钥所有者的真实性；最后为vEK 密钥颁发vEK 证书，并以一种只能由vTPM 管理器利用pTPM 才能解密的方式将vEK 证书传递给vTPM 管理器。

3.3 VM-vTPM 可信热迁移方案

3.3.1 设计方案综合概述

VM-vTPM 热迁移整体方案如图4 所示，MC集成到P 的管理应用程序中，ME 集成到D 和S 的vTPM 管理器中并作为VM 管理器的一部分，只有vTPM 管理器可以直接调用pTPM。方案大致流程为：（1）P 收到预迁移请求；（2）P 调用MC，并联合TTP，对S 和D 做双向远程证明；（3）如果S 和D可信，先由P 触发，然后S 和D 将依次收到迁移请求，并且S 和D 要对收到的迁移请求消息做比对检查，检查包括待迁移虚拟机标识IDVM等信息的有效性；（4）在参与VM-vTPM 热迁移的各方（P、S 和D）之间都架设一条加密传输通道；（5）在加密传输通道内完成VM-vTPM 数据的热迁移。本文接下来对流程中的双向远程证明、加密传输通道构建和VM-vTPM 数据传递作进一步阐述。

图4 VM-vTPM 热迁移方案设计

3.3.2 双向远程证明阶段

如图5 所示，MC 收到预迁移请求后，分别向S 和D 上的ME 发起可信验证请求，由ME 向MC返回底层平台的可信凭据，本阶段的最后，如果S和D 是可信的，会从MC 收到IDVM和对方的MIK证书。

具体交互过程如下文所述。

（1）MC→MES：K1SymEnc(PCRs1||NMC1||Time1||)NMC1||Time1||MC.privsig1(NMC1||Time1)||TTP.prisig1(cpHashquote(PCRs1||NMC1||MameS.MIK)))||S.MIK.pubAsymEnc(K1)。其中，PCRs1是S 提供的可信凭据中要选定的PCR 值，NMC1是MC 生成的随机数，Time1是时间戳，TTP.prisig1是TTP 对S 上的MIK 密钥执行TPM2_Quote命令的签名增强授权。MES调用pTPM 中的MIK密钥解密出对称密钥K1，用K1解密取出PCRs1，NMC1，Time1，MC.privsig1和TTP.prisig1，用本地MIK证书中记录的可信任MC 的公钥值验证签名值MC.privsig1，用本地MIK 证书中记录的IP 信息和消息来源URL 中的IP 做比对检查，检查时间戳Time1的新鲜度，所有检查通过后才继续处理来自MC 的请求消息。

（2）MES→MC：K2SymEnc(S.MIK.privquotel(PCRs1||NMC1)||EventLogS||NS)||MC.pubAsymEnc(K2)，其中，NS是S 生成的随机数，S.MIK.privquotel是S 在签名增强授权TTP.prisig1下执行TPM2_Quote 命令后的输出结果（即可信凭据）。MC 用自己的私钥解密出对称密钥K2，用K2解密取出S.MIK.privquotel，EventLogS和NS，检查S.MIK.privquotel中的被签名数据包含的随机数NMC1在内的消息正确性，验证S.MIK.privquotel中的签名值，通过度量日志EventLogS、本地标准值数据库和PCR 度量值验证S 上底层平台环境的可信性，最终给出S 能否被信任的判定结论。

（3）MC→MED：K3SymEnc(PCRs2||NMC2||Time2||MC.privsig2(NMC2||Time2)||TTP.prisig2(cpHashquote(PCRs2||NMC2||MameD.MIK)))||D.MIK.pubAsymEnc(K3)。用和步骤1类似的办法，S 将可信凭据以安全的方式发送给MC。

（4）MED→MC：K4SymEnc(D.MIK.privquote2(PCRs2||NMC2)||EventLogD||ND)||MC.pubAsymEnc(K4)。用和步骤2类似的办法，最终给出D 能否被信任的判定结论。

（5）MC→MES：K5SymEnc(CertD.MIK||NS||MigReqS-＞D(IDVM)||MC.prisig3(CertD.MIK||NS||MigReqS-＞D(IDVM)))||S.MIK.pubAsymEnc(K5)。如果MC 判定S 是可信的，则MC 发送此消息给S。其中，CertD.MIK是D 的MIK证书，MigReqS-＞D(IDVM)是将虚拟机IDVM从S 迁移到D 的迁移预请求。MES调用pTPM 中的MIK 密钥解密出对称密钥K5，用K5解密取出CertD.MIK，NS，MigReqS-＞D(IDVM) 和MC.prisig3，用本地MIK证书中记录的可信任MC 的公钥值验证签名值MC.privsig3，检查随机数NS和步骤2 中的一致性，保存D 的MIK 证书CertD.MIK，记录迁移预请求MigReqS-＞D(IDVM)。

（6）MC→MED：K6SymEnc(CertS.MIK||ND||MigReqS-＞D(IDVM)||MC.prisig4(CertS.MIK||ND||MigReqS-＞D(IDVM)))||S.MIK.pubAsymEnc(K6)。用和步骤5 类似的办法，如果MC判定D是可信的，D对接收的数据检查都通过后，同样保存S 的MIK 证书CertS.MIK，并记录迁移预请求MigReqS-＞D(IDVM)。

3.3.3 构建加密传输通道

在目前的开源组件qemu-7.2.0[10]和libvirt-9.0.0[12]中的VM-vTPM 热迁移的具体实现包括了TLS 传输协议的实现，可以保障被传输数据的机密性和完整性。此外，也可以对目前开源组件中的TLS 协议实现进行改良，实现一种基于pTPM 的增强TLS 传输协议，改良方法参见文献[13]。

3.3.4 VM-vTPM 数据传输

本节提出的VM-vTPM 数据传输方法是在开源组 件qemu-7.2.0[10]、libvirt-9.0.0[12]、swtpm-0.8.0[14]和libtpms-0.9.6[15]的基础上改进的。本节主要阐述改进后的VM-vTPM 热迁移中的vTPM 实现设计，分为vTPM 实例在源平台和目标平台之间的热迁移管理控制流程、vTPM 实例在源平台和目标平台之间的传递和vTPM 实例在源平台上的收集和在目标平台上的恢复这3 个部分。

（1）vTPM 实例在源平台和目标平台之间的热迁移管理控制流程。在VM 的热迁移管理控制方式的基础上，为vTPM 的热迁移新增如下内容：

①S 传递给D 的VM 配置信息XML 文件中，增加示例中的vTPM迁移配置信息，其中：sym_mode 表示对称加密使用的分组模式，sym_def 表示对称加密算法名称，rmt_MIK_cert 表示对端MIK 证书存放路径。此XML 文件传递完成后，S和D 需要把对端的MIK 证书存放在rmt_MIK_cert 所指的文件路径中。示例：＜migration sym_mode=’cbc’sym_def=’sm4’ rmt_MIK_cert=’/home/rmt/MIK.cert’/＞。

②S 调用D 的迁移准备函数后，D 首先创建一个空白的vTPM 实例，等待vTPM 实例信息的迁入。

③提前在S 中新注册一个可迁移字段的TPM设备，S 会在迁移VM 运行中的状态数据时收集所有可迁移状态设备信息，通过加密传输通道传递到D 上的VM，新注册的TPM 设备的描述代码如下：

其中，name 字段是对TPM 设备的描述，函数tpm_emulator_pre_save 表示此设备状态数据的收集方法，即vTPM 实例在S 上的收集函数。函数tpm_emulator_post_load 表示设备状态数据的恢复方法，即vTPM 实例在D 上的恢复函数。

（2）vTPM 实例在源平台和目标平台之间的传递。将S 中的函数tpm_emulator_pre_save 收集到的vTPM实例信息通过加密传输通道传递给D，D 中的函数tpm_emulator_post_load 将收到的vTPM 实例信息恢复并载入到空白的vTPM 实例。

（3）vTPM 实例在源平台上的收集和在目标平台上的恢复。设计流程如图6 所示，进一步说明如下文所述。

图6 vTPM 实例的收集和恢复

①控制命令CMD_GET_STATEBLOB 和CMD_SET_STATEBLOB。在QEMU 和SWTPM 之间设置两类控制消息：CMD_GET_STATEBLOB 和CMD_SET_STATEBLOB。前者是请求SWTPM 收集并返回vTPM实例信息，后者是请求SWTPM 恢复特定TPM 实例。

②函数TPMLIB_GetState 和TPMLIB_SetState。libtpms.so 库以纯软件的方式仿照了pTPM 芯片的所有功能，对外提供的函数TPMLIB_GetState 和TPMLIB_SetState 可分别用于导出或载入vTPM 实例数据。

③vTPM 实例的导出和载入。vTPM 实例中的数据分为非易失性部分和易失性部分，前者是指“电源关闭”后仍需要保留的数据，包括种子、用户自定义NV、持久密钥、制造时间和固件版本等信息，后者是指“掉电”后会被抹去的数据，包括PCR 值、已加载的会话、临时密钥、使能配置标记和时钟状态等信息。vTPM 实例信息的导出是将所有非易失性数据和易失性数据串联在一起形成特定数据块，vTPM 实例信息的载入是将指定数据块进行拆分并恢复出各个非易失性数据和易失性数据的字段值。

④数据的安全密封和解封。当SWTPM处理控制命令CMD_GET_STATEBLOB 时，会调用函数TPMLIB_GetState 获取vTPM 实例，先对其安全密封，然后将密封后的数据返回给QEMU；当SWTPM处理控制命令CMD_SET_STATEBLOB 时，会将QEMU 发来的待恢复vTPM 实例数据先做安全解封，然后才调用函数TPMLIB_SetState 将解封后的vTPM实例载入到空白的vTPM 实例等待启用。vTPM 实例的安全密封和解封算法如下。

在算法1 和算法2 的伪代码中，输入参数sym_def、sym_mode 和rmt_MIK_cert 分别是从启动参数中获取的对称算法名称、分组模式和对端MIK 证书。算法中用到的Rmt.MIK.pub 和Rmt.SK.pub 分别表示对端的MIK 密钥和SK 密钥的公钥。此外，MIK 密钥和SK 密钥是pTPM 创建的不可复制密钥，当用本地MIK 密钥做加解密、用本地SK 密钥做签名时，均需要调用pTPM，由于SWTPM 本身不能直接调用pTPM，所以算法1 和算法2 需要借助vTPM 管理器即libmgtvtpms.so 库对外提供的相关函数间接调用pTPM，完成对相关密钥的使用。

4 安全性分析

本文的vTPM 证书链扩展设计中的MIK 证书由TTP 签发，证书的扩展项中设置了可信任MC 的IP和公钥等标识信息。当MC 分别和S、D 发起含有MC 签名值的远程可信证明请求时，S 和D 先基于MIK 证书中的可信任MC 的IP 和公钥信息对请求消息做合法性检查，检查通过后受理该验证请求。这样的设计可以减轻S 和D 在VM-vTPM 热迁移阶段遭受的拒绝服务攻击。

本文的VM-vTPM 迁移协议设计中的第一个阶段就是对S 和D 做基于pTPM 的双向远程可信证明，保证只有受信任的源平台才可以发起有效的迁移请求，只有受信任的目标平台才可以接收来自特定源平台对特定虚拟机的迁移请求。这符合在整个迁移过程中需要保持基础信任关系的要求。

本文的VM-vTPM 迁移协议设计中的第2 个阶段是在参与迁移的各方之间建立一条加密传输通道，可以用传统的TLS 协议，也可以用文献[15]中的基于pTPM 的增强TLS 协议。构建的加密传输通道可以满足后续待迁移的VM-vTPM 数据在远程传递过程中的机密性和完整性等基本安全要求。

本文的VM-vTPM 迁移协议设计中的第3 个阶段是VM-vTPM数据的正式传递，其中基于pTPM的vTPM 实例数据的安全密封和安全解封设计为vTPM 数据在远程传递过程中提供了基于pTPM 的硬件级别的机密性和完整性保护。S 上受pTPM 保护的不可复制密钥SK 对vTPM 数据的签名可以使D 对数据来源的身份真实性进行判断。

通过以上的综合分析可知，本文提出的协议设计能满足VM-vTPM 热迁移的基本安全要求。然而，仍然存在一些局限。

（1）如果向P 发起预迁移请求的管理员不受信任，或者攻击者获得了P 的管理员权限，将无法保证VM-vTPM 热迁移的安全性。

（2）如果在VM-vTPM 热迁移的进行过程中将恶意代码注入包括vTPM 管理器在内的可信组件中，比如S 和D 已经完成了双向远程可信证明并构建起了加密传输通道，vTPM 管理器遭到恶意代码注入攻击，则VM-vTPM 热迁移过程中的安全也会受到威胁。

（3）因为没有为包括vTPM管理器在内的可信组件的运行环境和其他组件的运行环境提供硬件级别的隔离环境，因此可信组件在运行时有可能遭到来自操作系统、硬件和其他应用程序的攻击。

5 结语

本文首先提出了一种vTPM 证书链扩展设计，是在VM 管理器中集成vTPM管理器，基于pTPM为vTPM管理器创建了可以加密但签名运算受到TTP签名管控的MIK 密钥；其次针对当前开源组件qemu-7.2.0[10]、libvirt-9.0.0[12]、swtpm-0.8.0[14]和libtpms-0.9.6[15]上的VM-vTPM 热迁移实现部分存在的安全问题，结合本文的vTPM 证书链扩展设计，新设计了一种VM-vTPM 热迁移协议并给出实际的实现方法，然后对其安全性进行了综合评估。

在未来的工作中将完成原型实现以便对本文中的热迁移协议和实现方法的性能进行评估，并进一步探讨vTPM 的硬件解决方案，还将引入新的硬件技术解决包括vTPM 管理器在内的可信组件运行时的安全问题，并重新评估本文所提的VM-vTPM 热迁移协议设计方案。