一种云环境中的虚拟机回滚安全模型

A Security Model for Virtual Machine Rollback in Cloud Environments

摘要: 虚拟机(VM)回滚可能会被滥用来对系统发动攻击，导致无论是否使用可信计算技术(TPM)，云环境安全问题始终存在，对云计算安全提出严峻挑战。本文报告了在使用TPM环境中和不使用TPM环境中实施成功的攻击实验，分析了导致云安全问题的根本原因，提出一种基于回滚弹性虚拟TPM (rvTPM)的虚拟机回滚安全解决方案。rvTPM基于Xen环境设计实现并测试，实验结果表明：rvTPM在确保虚拟机回滚安全的前提下，不会对云计算环境造成任何明显的性能损失。

Abstract: Virtual machine (VM) rollback may be misused to launch attacks on the system, leading to persistent security problems in cloud environments, regardless of whether Trusted Platform Module (TPM) is utilized or not. This poses a serious challenge to the security of the cloud. This paper reports successful attack experiments conducted in both TPM-enabled and non-TPM-enabled environments, analyzes the fundamental causes of cloud security issues, and proposes a secure solution for virtual machine rollback based on rollback-resilient virtual TPM (rvTPM). rvTPM is designed and implemented based on Xen environments. The experimental results demonstrate that rvTPM provides a secure solution for virtual machine rollback without causing any significant performance degradation in cloud computing environments.

1. 引言

虚拟机(VM)是云计算的基石[1]，但虚拟化也带来一系列新的安全漏洞问题[2]-[8]。通常的虚拟机回滚机制安全方案[8]要求用户禁用虚拟机回滚机制或虚拟机暂停/恢复功能。另一种解决方案[9]要求用户自主分析，以便判断是否有虚拟机回滚攻击的行为发生，而这在实际应用中无法落实。在未使用TPM的环境中，攻击可归因于回滚虚拟机时应用程序状态的丢失，攻击者可以在应用程序毫无察觉的情况下回滚其状态。在采用TPM技术的环境中，安全威胁的识别可归因于虚拟机的实际运作状态与由虚拟TPM (vTPM)记录的虚拟机状态之间存在的差异，即VM-vTPM的不匹配情况[10]。

Garfinkel和Rosenblum较早发现虚拟机回滚可能带来严重的安全后果[11]。Xia等人提出一种解决虚拟机回滚的安全模型，然而其威胁模型假设管理程序是恶意的[9]。鉴于恶意管理软件能够在未征得云服务用户同意的情况下，擅自对虚拟机执行快照拍摄、挂起及恢复等操作，解决方案应聚焦于开发一个精简、专注且可信的管理程序。这样的管理程序能够为虚拟机提供防护，使其免遭恶意通用管理程序的侵害。相比SaaS供应商和云用户可能发起的攻击，假设通用管理程序可信，威胁模型将更切合实际。在虚拟机环境中拍摄和恢复快照的相关研究主要集中在如何实现虚拟机回滚[5] [12]-[17]，然而针对不使用vTPM的环境，无法在使用vTPM的云环境中使用。Parno等人[18] [19]研究了如何实现程序状态的高效、鲁棒回滚，使回滚操作不会导致系统崩溃。Gofman等人[20]观察到虚拟机快照机制可能会被滥用来检索敏感数据，建议对于涉及敏感数据的进程不使用快照机制，然而这种解决方案无法解决VM-vTPM之间的差异。Goldman等人[21]研究了如何通过使用计数器来防止重放攻击，计数器在每次vTPM操作后都会增加。这意味着虚拟机回滚后，vTPM功能会因为计数器的减少而受到破坏。England等人[22]建议将vTPM移入管理程序，以保护计数器不被回滚。

本文探讨了虚拟机回滚过程中的一个固有特定安全漏洞，该漏洞被广泛用于攻击恢复等事件[2] [9] [13] [14]，展示了如何利用虚拟机回滚机制对有或没有TPM的云环境发起攻击的过程，并提出基于回滚弹性虚拟TPM (rvTPM)的安全方案，旨在赋予应用程序识别自身状态是否受到虚拟机回滚操作影响的能力。为了有效利用TPM进行问题解决，应用程序开发者需熟悉使用rvTPM编程。rvTPM对应用程序编程人员透明，因此rvTPM既不会对应用程序进行任何修改，也不要求对客户操作系统(OS)进行任何修改，简单有效且确保云计算环境性能不明显下降。

2. 虚拟机回滚

如图1所示，假设云计算环境为用户提供计算资源，软件服务供应商(SaaS) Isaac通过SaaS VM向用户提供软件服务，用户Peggy运行用户虚拟机来构建个人网站。

Figure 1. An example of a cloud environment using the current virtual machine rollback mechanism (regardless of whether TPM technology is used) for attacks

图1. 利用当前虚拟机回滚机制(无论是否使用TPM技术)进行攻击的云环境示例

2.1. 攻击方式1

成功地重用被泄露的密码。如图1所示，假设Peggy使用本地计算机(或智能手机)中的电子邮件客户端，连接到位于云端的Isaac提供的SaaS虚拟机中的Java Apache邮件企业服务器[23]。假设服务器通过密码pw和基于密码的安全身份验证协议对Peggy进行身份验证。具体攻击场景如下。

a) 20:10：Peggy的密码pw被侵入本地计算机的恶意软件破坏，这导致密码信息可能被泄露给了未授权的第三方。

b) 20:20：Peggy本地计算机中的恶意软件被检测并清除。鉴于密码pw可能已经遭到泄露，Peggy遵循服务器的密码更新流程，将其密码更新为一个新的密码pw'。

c) 20:30：拥有虚拟机回滚权限(但无其他权限)的攻击者回滚SaaS虚拟机到20:15时的状态(当时pw为有效密码)。或者，SaaS虚拟机出于合法目的回滚[11]。由于这些回滚操作，攻击者都可能利用密码pw验证服务器，从而冒充Peggy。

该攻击可以在Amazon EC2平台上成功实施，其中SaaS虚拟机的操作系统为Amazon LinuxAMI，内核为3.10.34-37.137.amzn1.x86 64，实例类型为t1.micro，有1个虚拟CPU和0.615GB内存，服务器为Apache James 2.3.2。攻击只需要回滚SaaS虚拟机的权限，不需要其他权限。

2.2. 攻击方式2

TPM能够确保系统的可信引导，向远程验证方证实当前状态，以及对敏感数据进行加密和解密操作[24]。鉴于每台实体计算机都装有一个独立的TPM，云服务环境中必须实现TPM的虚拟化，这样才能保证每台虚拟机都能够利用到TPM(即vTPM)。在合法的使用场景中，虚拟机通常需要回滚到早期状态[11]。然而，目前的VTPM/TPM设计并未考虑到vTPM/TPM的状态回滚问题。这就可能导致记录在VTPM中的虚拟机状态与实际虚拟机在执行回滚操作后的状态不一致。这种状态差异，即VM-VTPM差异，可能被恶意利用来发起安全攻击。

图1展示了恶意的SaaS服务提供商Isaac如何通过虚拟机回滚功能来盗取用户Peggy的敏感数据的过程。在掌握了SaaS软件的源代码的情况下，Isaac有能力植入后门，进而对Peggy发起攻击。

a) 21:00：SaaS虚拟机的客户端操作系统和其对应的vTPM均处于state₀，即vTPM记录的状态精确反映了虚拟机状态。Isaac为处于state₀的SaaS虚拟机拍摄快照。

b) 21:10：新的SaaS软件补丁发布。Isaac更新软件并重启虚拟机。此时虚拟机处于state₁，vTPM状态也是state₁。Isaac通过远程验证向Peggy证明虚拟机处于state₁(即SaaS软件中的漏洞已被修补)。

c) 21:20：Isaac将SaaS虚拟机回滚至state₀，但vTPM的状态没有随之更新，即虚拟机与vTPM存在差异。vTPM可能会向Peggy证明SaaS虚拟机处于state₁状态，而它实际上处于state₀。因此，这个不一致可能被利用来窃取Peggy在SaaS虚拟机中的敏感数据。

攻击者针对未使用vTPM或TPM系统的攻击之所以有效，根本在于执行虚拟机回滚操作时，应用程序的当前状态可能会无法被追踪或恢复，因为应用程序状态已经回滚到较早状态。为应对这一挑战，必须开发相关机制使应用程序能够识别自身是否因虚拟机的回滚操作遭遇了状态的丢失或变更。为此，需要使应用程序能够检测虚拟机是否已回滚。通过研究，我们观察到如果只是回滚某些PCR值，而不是整个vTPM状态，同时添加一些永不重置的PCR，以便远程验证器检测回滚事件，可有效防止回滚攻击。

3. 模型设计

回滚弹性vTPM (rvTPM)使用TPM技术解决攻击问题，为了保护SaaS用户免受恶意SaaS供应商的侵害，用户应能够识别出存在问题的SaaS虚拟机是否经历了回滚操作。为实现这一点，需要依赖一个可信的独立实体来监控并记录虚拟机的回滚行为，同时向SaaS用户提供相应的证明，证实这些回滚行为确实已经发生或未发生过。

3.1. 回滚整个vTPM状态不安全

为了消除虚拟机与vTPM之间的差异，有研究建议回滚整个vTPM状态。然而，这种设计并不安全。首先，不应回滚整个vTPM实例，否则会破坏vTPM计数器的单调性。因此，有必要重放攻击[25]，建议只回滚那些衡量虚拟机完整性的PCR，以及那些用于TPM功能(如密封存储和远程证明)的PCR。其次，无法回滚系统持久存储(由TCG软件栈或TSS管理)中的密钥层次结构，由于当前注册的有效密钥(也就是应用程序正在使用的最新一代密钥)有丢失的风险，同时，在虚拟机执行回滚操作之后，那些未被注册且由TSS管理的密钥句柄(如已经不再使用或已经失效的受损密钥)可能会重新激活。再次，每次回滚操作后都必须刷新所有句柄，因为回滚操作后虚拟机的所有句柄仍然存在于vTPM中，如果不刷新句柄，它们就可以被用来发动攻击。

3.2. 如何检测回滚

为了检测回滚，建议添加PCR₂₄,…,PCR₃₁。如表1所示。

a) PCR₂₄、PCR₂₅和PCR₂₆被rvTPM用于记录虚拟机快照的信息。使用PCR_snap作为简称，其中$\text{snap}\in \left\{24,25,26\right\}$ 。

b) PCR₂₇、PCR₂₈和PCR₂₉被rvTPM用于追踪虚拟机从哪个状态回滚的信息。使用PCR_roll作为简称，其中$\text{roll}\in \left\{27,28,29\right\}$

c) PCR₃₀用于管理员记录和恢复vTPM实例。

d) PCR₃₁被应用程序用来检测虚拟机回滚。

e) PCR_0~23是原始PCR，简称为PCR_orig，其中$\text{orig}\in \left\{0,\text{1},\cdots ,\text{23}\right\}$ 。

Table 1. PCR function and permission table

表1. PCR功能及权限表

PCR	目的	重置权限	扩展权限
PCR24	快照拍摄时间	rvTPM	rvTPM
PCR25	快照拍摄时的uid	rvTPM	rvTPM
PCR26	记录拍摄快照时虚拟机状态	rvTPM	rvTPM
PCR27	虚拟机回滚时间	无	rvTPM
PCR28	虚拟机回滚时的uid	无	rvTPM
PCR29	记录回滚时虚拟机状态	无	rvTPM
PCR30	记录vTPM实例数据	无	rvTPM
PCR31	应用检测虚拟机状态	无	应用

由于两个虚拟机快照可能对应TCG [26]规定的相同PCR_orig值，而且应用程序可能会在某个快照下封存其敏感数据(即封存的敏感数据不得在任何其他快照下解封)，因此需要区分不同的快照。为此，让rvTPM使用PCR₄记录虚拟机快照的系统时间(管理程序时间戳)。当云用户封存其敏感数据时，用户可将数据封存在与PCR₂₄唯一值相对应的快照下。在进行第n次封存操作时，有下式成立：

${\text{PCR}}_{24}^n=\text{H}\left({\text{PCR}}_{24}^{n-1}\left|\right|\text{H}\left({\text{snapshot}}_{\text{time}}\right)\right)$ (1)

其中，PCR₂₄ = 0，H是TCG采用的标准加密哈希函数，||是连接词操作，而快照时间则是拍摄快照时的管理程序时间戳。由于PCR₂₄只能由rvTPM扩展或重置，因此任何虚拟机都无法对其进行操作。为防止出现上述VM-rvTPM差异，PCR₂₄将与虚拟机一起回滚。为了让云用户(或远程验证者)确定虚拟机何时被回滚以及回滚到何时，使用PCR₂₇记录虚拟机回滚的系统时间：

${\text{PCR}}_{27}^n=\text{H}\left({\text{PCR}}_{27}^{n-1}\left|\right|\text{H}\left(\text{rollback\_time}\left|\right|\text{snap\_shot}\right)\right)$ (2)

其中，${\text{PCR}}_{27}^0=0$ ，回滚时间是发生回滚时的管理程序时间戳。PCR₂₇只能由rvTPM扩展，不能被任何实体重置，从而防止它被任何虚拟机操纵。

由于SaaS虚拟机可由多个用户使用，而这些用户通过PCR_orig [26]拍摄了相同的SaaS虚拟机快照，并且需要区分不同用户的敏感数据可能被封存的快照，因此推荐利用用户ID (uid)辨识各用户的快照。为有效纳入该信息，提议增设PCR₂₅，当拍摄快照时，rvTPM会扩展PCR₂₅，以包含拍摄快照的用户的uid，具体如下：

${\text{PCR}}_{25}^n=\text{H}\left({\text{PCR}}_{25}^{n-1}\left|\right|\text{H}\left(\text{uid\_snap}\right)\right)$ (3)

其中，${\text{PCR}}_{25}^0=0$ 。PCR₂₅只能由rvTPM扩展或重置。为防止出现VM-vTPM差异如上所述，PCR₂₅将与相应的虚拟机一起回滚。

为了让云用户确定是谁将相关虚拟机回滚到谁的快照，添加PCR₂₈记录记录回滚虚拟机的用户的uid：

${\text{PCR}}_{28}^n=\text{H}\left({\text{PCR}}_{28}^{n-1}\left|\right|\text{H}1\left(\text{uid\_roll}\left|\right|\text{uid\_snap}\right)\right)$ (4)

其中，${\text{PCR}}_{28}^0=0$ 。PCR₂₈只能由rvTPM扩展，但不能重置。

当应用程序封存敏感数据时，数据必须与PCR_orig所代表的虚拟机状态绑定[26]。为确保这一点，添加了PCR₂₆来记录虚拟机状态，用$\text{VTPM\_snap}={\text{PCR}}_0\left|\right|\cdots \left|\right|{\text{PCR}}_{23}$ ，如下所示：

${\text{PCR}}_{26}^n=\text{H}\left({\text{PCR}}_{26}^{n-1}\left|\right|\text{H}\left(\text{vTPM\_snap}\right)\right)$ (5)

其中，${\text{PCR}}_{26}^0=0$ 。PCR₂₆只能由rvTPM扩展或重置。

与PCR₂₆类似，如果虚拟机从状态B(源状态)回滚到状态A(目的状态)，添加PCR₂₉，来记录这一回滚操作：

${\text{PCR}}_{29}^n=\text{H}\left({\text{PCR}}_{29}^{n-1}\left|\right|\text{H}\left({\text{vTPM\_snap}}^{\text{src}}\left|\right|{\text{vTPM\_snap}}^{\text{dest}}\right)\right)$ (6)

其中，${\text{PCR}}_{29}^0=0$ 。PCR₂₉只能由rvTPM扩展，但不能重置。

当云管理员需要还原整个vTPM实例时﹐需要记录vTPM实例数据(用vTPM数据表示)，记为vTPM_data。为了方便操作，添加PCR₂₉，使得：

${\text{PCR}}_{29}^n=\text{H}\left({\text{PCR}}_{29}^{n-1}\left|\right|\text{H}\left({\text{vTPM\_snap}}^{\text{src}}\left|\right|{\text{vTPM\_snap}}^{\text{dest}}\right)\right)$ (7)

PCR₃₀只能由rvTPM扩展，但不能重置。

远程挑战者(例如云用户)可以使用PCR_roll来验证虚拟机回滚事件，并判断SaaS供应商是否通过回滚事件欺骗他。然而，应用程序不能简单地使用PCR_roll来检测虚拟机回滚时其状态的丢失，因为它无法知道每个VM回滚事件的影响，也无法识别哪个虚拟机回滚操作可能会损坏其状态。所以需要添加PCR₃₁来允许应用程序记录自己的状态转换，如下所示：

${\text{PCR}}_{30}^n=\text{H}\left({\text{PCR}}_{30}^{n-1}\left|\right|\text{H}\left(\text{vTPM\_data}\right)\right)$ (8)

其中，${\text{PCR}}_{31}^0=0$ 。E_i表示第i个敏感操作(例如更改密码)对应的信息，该操作将改变应用程序的敏感状态。当应用程序状态发生变化时，它将有关其状态变化的敏感操作信息E_i记录到日志中并将E_i扩展到PCR₃₁，然后将秘密消息m_i(密码或私钥)密封到PCR₃₁。后面的应用程序可以通过测试哪个步骤的消息($m_1,m_2,\cdots ,m_n$ )可以解封来确定应用程序正在处理哪个状态。如果应用程序处于状态E_x，则当前PCR₃₁值应为$H\left(H\left({\text{PCR}}_{31}^0\left|\right|H\left(E_x\right)\right)\right)$ 。如果m_x消息能够成功解封，则表明应用程序处于状态E_x并且不是丢失状态，否则，应用程序能够察觉到虚拟机执行了回滚操作，因为其当前状态与存储在PCR₃₁中的真实状态存在差异。应用程序可以通过日志强制恢复与PCR₃₁的值匹配的状态，这个PCR只能由应用程序扩展但无法重置。

3.3. 安全分析

基于rvTPM的虚拟机回滚机制既不会被滥用而导致应用程序状态“丢失”，也不会被滥用而导致虚拟机与vTPM之间的差异。rvTPM旨在保障用户虚拟机中的应用程序能够借助PCR₃₁记录其历史状态，并赋予系统强制调整应用程序状态的能力。为了造成应用程序状态的“丢失”，能够回滚虚拟机的攻击者必须能够操纵PCR₃₁的值，使其与回滚操作后的应用程序状态相匹配。然而这是不可能的，因为PCR₃₁从不重置。

rvTPM可以确保在进行虚拟机回滚操作后，从相应的vTPM快照中恢复vTPM状态，还可以确保从一个状态到另一个状态的执行路径是唯一的。为了让攻击者造成VM-vTPM差异，攻击者必须确保SaaS虚拟机处于可信状态S_A，以便将证明传递给SaaS用户(否则，SaaS用户就会知道SaaS虚拟机不处于安全状态)。假设在成功执行验证后，攻击者将SaaS虚拟机拉回到易受攻击的状态S_B。使用服务后，用户将验证PCR_roll记录的服务时间内SaaS虚拟机的状态转换。因此，如果攻击者想消除攻击痕迹，必须通过操纵PCR_roll来欺骗云用户，使虚拟机通过可信状态路径运行。然而这是不可能的，因为PCR_roll只能由rvTPM扩展，而且永远不能重置。

4. 实验原型

实验原型系统以Linux 2.6.18为域0的Xen 3.3.1虚拟机管理程序上实施rvTPM。图2给出了rvTPM的四个模块。域0中的信息收集模块负责搜集回滚操作信息，而Xen中的信息注册模块记录和共享状态信息。回滚模块位于域0，负责执行快照和回滚操作。回滚日志模块位于域0，负责记录回滚操作。

Figure 2. Xen-based rvTPM system architecture, it mainly consists of four modules

图2. 基于Xen的rvTPM系统体系结构，它主要由四个模块组成

4.1. 信息收集模块

在拍摄快照或将虚拟机回滚到上一个快照时，会调用该模块来收集以下信息：1) 虚拟机名称；2) 对应的vTPM ID；3) 用户名：(iv)用户ID；4) 系统当前时间；5) vTPM快照的路径。该模块通过一个新定义的超级调用do_vtpm_rollback，由下面描述的信息注册模块提供，将收集到的信息添加到新添加的全局请求表中，全局请求表的结构是一个链表，每个条目代表一个请求。

4.2. 信息登记模块

信息收集模块收集的信息存储在请求表中。每个rvTPM模块都能通过超级调用do_vtpm_rollback编辑和检索请求表。为了应对可能出现的并发写入全局表的情况，使用自旋锁[27]确保独占访问。在模块尝试进行编辑请求表操作(如添加、移除或查询条目)时，若需获取锁，它会进入一个循环等待状态，直至锁变为可用。

4.3. 回滚模块

在进行虚拟机快照或将虚拟机回滚到之前的快照时，该模块会记录snap_time、uid_snap、vTPM_snap分别扩展到PCR_snap中的roll_time || snap_time,uid_roll || uid_snap, vTPM_snap^src || vTPM_snap^dest分别扩展到PCR_roll中。并更新日志以包含这些信息项，供远程验证使用。为确保快照和回滚过程的安全性，使用PCR_snap, PCR_roll表示快照。在此机制下，仅允许回滚至这些PCR所记录的状态，而PCR_roll则不允许回滚。一旦状态回滚，相关vTPM句柄将被清除，阻止应用程序利用这些句柄访问与回滚虚拟机无关的安全敏感资源(如密钥)。为了确保系统持久性存储不会回滚，将系统持久性存储的目录作为NFS运行，以便域0挂载和共享。由于域0不会回滚，系统持久存储最新状态。

当rvTPM管理器接到快照请求，它会查询新建立的全局表中的vTPM ID。若查询未发现相关信息，即表明用户未发起快照操作。反之，若找到数据，则说明信息收集与注册模块已成功搜集并记录了进行回滚所需的信息。在定位到先前注册的信息之后，rvTPM管理器将要求rvTPM扩展到PCR_snap，并提取PCR_orig和PCR_snap中的所有哈希值。rvTPM管理器将这些PCR值存储至一个特定文件中，并复制该文件到某个路径以便回滚。rvTPM管理器还会将rvTPM实例数据保存到该路径，以便管理员执行适当的维护任务。

首先，rvTPM管理器会利用vTPM的ID在全局表中搜索。若查询到相关信息，管理器便会将vTPM的快照复制至硬盘。在回滚过程中，由于会生成一个新的rvTPM实例，因此可以从已保存的快照中恢复出rvTPM的实例。启动过程如下：首先，用未回滚的信息创建vTPM实例；其次，检查rvTPM的启动类型。只要rvTPM的启动类型是TPM ST STATE，就会调用恢复和扩展PCR的功能；第三，在与上一步相同的功能中，确定是否是回滚请求，如果rvTPM实例是为其他目的而不是为恢复快照而创建的，则将通过搜索全局表再次确定；第四，一旦确定是回滚请求，该函数将替换PCR的值，从PCR₀…到PCR₂₆；第五，它将刷新所有与vTPM相关的句柄；第六，在执行了所有可能引起rvTPM实例数据变更的操作后，保存并存储rvTPM实例数据；最后，PCR₂₇…到PCR₂₉将被更新来记录此类回滚事件。

4.4. 回滚日志模块

使用新增的PCR_snap和PCR_roll，可以跟踪回滚事件。然而，尽管PCR中存在哈希值，但仍不足以恢复回滚历史。在用户执行拍摄快照或恢复至早期快照的操作时，rvTPM会在扩展PCR时记录日志。日志包括回滚时间(拍摄，恢复快照的时间)、执行的动作(快照或回滚)、用户ID、虚拟机名称、虚拟机快照的路径(拍摄或恢复到的快照)。日志将有助于远程验证和TPM_Quote操作。

5. 性能评估

实验平台基于一台配备四核1.99 GHz AMD Opteron处理器、4GB内存和v1.2 Broadcom TPM修订级别A2的服务器进行实验。软件环境为Ubuntu 8.04 LTS上的准虚拟化Xen 3.3.1，内核为2.6.18.8-xen。用户虚拟机运行相同的准虚拟化内核，域U分别为32M、64M、128M、256M、512M和lG内存和1个虚拟CPU内核。域0中运行NFS版本3服务器，保证rvTPM的系统持久存储。

5.1. 使用rvTPM的OpenSSH服务器

将rvTPM与OpenSSH服务集成[27]。rvTPM能让OpenSSH服务自动检测密钥丢失，并在虚拟机回滚事件中继续安全工作。为此，需要对OpenSSH服务器进行如下修改，该修改包含在ssh-keygen.c和sshd.c中。扩展PCR函数、密封函数和解除密封函数。

a) 当为OpenSSH服务器生成新的主机服务器密钥对时，OpenSSH服务器会将其公钥扩展到PCRs1，在回滚过程中该公钥不可恢复。然后，OpenSSH服务器将主密钥封存在PCR下。ssh-keygen命令由ssh-keygen.c实现，对主函数稍作修改(添加扩展函数和封存函数)。

b) 在密钥使用前，通过解封操作验证其有效性。解封成功则密钥与PCR₃₁一致，不会发生回滚；否则，密钥与PCR₃₁不一致，由于PCR的值是不可恢复的，指示系统可能已回滚，密钥被恢复到了以前的密钥。创建sshd守护进程时，需在主函数中加载并解封主机密钥对。

c) 如果解封操作失败，即虚拟机已回滚到之前的状态，OpenSSH服务器应放弃当前使用的公钥和私钥对，转而从日志中恢复主机密钥对。使用rvTPM系统和更新后的OpenSSH服务器，可以有效防止会话密钥在回滚操作中泄露，从而在发生此类事件时通知管理员进行进一步的调查。因为OpenSSH服务器可以实时检测回滚操作。

5.2. 系统成本测量

使用不同内存下的不同域U配置进行实验，以测试rvTPM带来的成本。对于拍摄快照，测量了以下步骤的成本：1) 计算收集信息时的哈希值；2) 超级调用注册信息；3) 超级调用搜索信息；4) PCR扩展和保存vTPM快照；5) 复制vTPM快照。对于回滚，测量了以下步骤的成本：1) 计算收集信息时的哈希值；2) 超级调用注册信息；3) 超级调用搜索信息；4) 回滚vTPM；5) PCR扩展。

测试结果如图3，图4所示，在快照和回滚过程中，所有步骤的成本与内存大小并不呈线性关系，可以发现以下几点事实：首先，超级调用非常高效。在快照过程的第1步，对当前用户名、时间和vTPM_snap进行散列。其次，当前用户名和时间的字节数很少，因此计算哈希值花费很少。再次，vTPM快照的大小固定，因为24个PCR (PCR₀, … ,PCR₂₃)的大小固定。在回滚过程的第1步中，还对当前用户名、时间和vTPM快照进行哈希处理。区别是现在需要对当前虚拟机的vTPM快照以及要恢复到的快照的vTPM快照(其哈希值等于快照中的PCR₂₆)进行哈希处理，其大小也是固定的。在扩展PCR值过程中，将当前时间、用户ID和vTPM快照的散列分别扩展为PCR₂₄~PCR₂₆或PCR₂₇~PCR₂₉ (总共60字节)。

此外，如图5，图6所示，通过比较使用rvTPM的系统中快照和回滚功能与不使用rvTPM(但使用vTPM)的系统中对应功能的成本，可以发现rvTPM不会产生任何显著成本。

Figure 3. The time cost of rvTPM taking snapshots at different memory sizes

图3. rvTPM在不同内存大小下拍摄快照的时间成本

Figure 4. The time cost of rvTPM reverting snapshots at different memory sizes

图4. rvTPM在不同内存大小下的恢复快照的时间成本

Figure 5. Time cost for taking snapshots of corresponding system functions

图5. 系统对应功能拍摄快照的时间成本

Figure 6. Time cost for reverting snapshots of corresponding system functions

图6. 系统对应功能恢复快照的时间成本

6. 结论

云环境中的虚拟机回滚机制易导致恶意攻击，本文展示了使用和不使用TPM技术的情况下当前的虚拟机回滚机制发起攻击的根源在于状态信息被复用，并基于此设计了回滚弹性虚拟TPM (rvTPM)回滚机制，并分析了其安全性。原型系统基于Xen平台实现rvTPM，性能评估结果表明：rvTPM可以有效保证虚拟机回滚安全可靠且不会造成增加显著的效率成本。rvTPM的提出可以有效促进TPM技术在云计算环境中的广泛应用。

基金项目

广东省自然科学基金项目(2024A1515011502)，广东省科技计划项目(2019B010139001)。

NOTES

^*通讯作者。