成功地重用被泄露的密码。如 图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虚拟机的权限，不需要其他权限。

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，以便远程验证器检测回滚事件，可有效防止回滚攻击。

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

为了检测回滚，建议添加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\}$。

由于两个虚拟机快照可能对应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只能由应用程序扩展但无法重置。

基于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扩展，而且永远不能重置。

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

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

在进行虚拟机快照或将虚拟机回滚到之前的快照时，该模块会记录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₂₉将被更新来记录此类回滚事件。

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

将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服务器可以实时检测回滚操作。

使用不同内存下的不同域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不会产生任何显著成本。