Reading Notes 2015-07-08

OAuth Privacy BigData ReadingNote

---

Content

The articles below have not been read！

---

1. OAuth Demystified for Mobile Application Developers

CCS'14

• 阅读

OAuth是一个被广泛应用在Website上面的网络授权的协议。

1. 目前大多的授权提供商例如，Facebook，Google等都为了用户的授权需求重新修改了OAuth。
2. 很多的开发者也将OAuth运用在了移动平台上面。

文章的贡献主要在一下两个方面：

1. 从OAuth协议文档的内部的研究该协议在移动平台开发者来说会产生的模糊和未指明的地方
2. 测试了超过600个热门的移动应用，来研究开发者将会如何实现这授权以及这些授权的实际目标。测试结果令人担忧，只有149个应用使用了OAuth协议，然后其中89%的应用并没有正确的使用OAuth协议。

在文章中，指出了每个容易让移动开发者误解的OAuth协议流的安全关键部分。

---

2. The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Systems

CCS'12

• 阅读

数百万的用户通过使用他们的Facebook帐号来登入其他的依赖第三方的网站。这个基于网络的SSO模式已经在OAuth2.0中实现了。虽然OAuth在先前的实验方法中证明了其安全性，但是在实际的应用中的安全性如何仍然是一个开放的问题。本章通过测试3个大的OAuth身份证明提供商（eg,. Facebook， Microsoft, and Google)以及96个热门的依赖第三方网站。发现了数个安全的漏洞，这些漏洞能够让攻击者在没有或者权限的情况下，访问被害人的用户资料，社会关系图，甚至在依赖第三方的网站上面模仿被害人。进一步的研究发现这些问题都是由于实现的简化的目的而牺牲了安全性的设计引起的。文章提出的设计提高了IdPs与RPs授权设计的安全性

---

3. Mechanized Network Origin and Path Authenticity Proofs

CCS'14

• 阅读

对于安全可靠的网络服务而言，一个安全的路由的架构是十分重要的。源端的授权以及路径的验证是建立安全可靠网络服务的基础两个基础。虽然以及有一些协议实现了这些基础，但是他们并没有正式的分析了他们的安全保证。

文章提出了证明技术来检查加密协议（eg,.密钥交换协议）来分析网络协议。本章提出了LS，LS是一个程序逻辑，LS能够论证在不安全环境下程序的执行状况。文章也实现了协议特定的数据结构，预测以及公理系统。为了分析一个使用chanined MAC（连续的消息验证码）的源端以及路径验证的source-routing协议。我们通过构造Coq.证明来展示一个协议是否满足目的的需求。本文是最早公理化源端以及路径的授权属性，以及公理化的证明手段。使得连续的消息验证码能够提供要求的授权的属性。

---

4. Founding Digital Currency on Secure Computation

CCS'14

• 阅读

现在绝大部分的数字货币以及相关的记账模式都与现在Bitcoin的模式类似，无论是集中式的或者是完全分布式的。集中式提供了审计功能，但是将所有的身份数据以及所有的事务的隐私都被一个组织控制了。而分布式的模式能够个很好的保护隐私但是不能提供审计功能。

文章设计了一个隐私保护与主动安全的分布式总账以及相关的是事务协议（能够实现一个可审计的数据货币，这些货币继承了总账的隐私以及安全特性）。一个我们需要解决的主要技术是如何克服总账大小的持续增长，货币流通，以及总账需要长时间保存。文章通过减少分布式（隐私共享）存储轨迹，贷款以及主动更新总账来保证长时间的隐私和安全性。

---

5. Self-service Cloud Computing

CCS'12

• 阅读

现代的云计算架构都是使用虚拟机监控器（VMM），这些VMM 都有一个大且复杂的有高权限的管理域来监控其它的客户虚拟机的状态。面向管理域的攻击或者对于管理域的错误的使用可以破坏用户虚拟机的安全与隐私。并且传统的VMM限制用户对于自身虚拟机的权限，例如用户只能依赖云系统提供商来部署一些入侵检测系统以及基于自省的安全工具。

文章介绍了一个新型Self-service Cloud Computing模式，SSC模式克服了上文中提到的两个缺点（1）特权域容易被攻击（2）用户不能自定义自己的虚拟机。SSC将管理员的管线分离为一个系统范围的管理域Sdom0和每个用户独有的管理域Udom0。每一个用户对于他自身的虚拟机有最高的权限，因此用户能够自由的组件自己的虚拟机。Sdom0不能获得用户虚拟机的任意信息（代码，数据，计算信息）。因此保护了用户虚拟机的隐私与安全。SSC允许用户和云系统提供者都能设置可信的监控服务。作者通过修改Xen虚拟机监控器实现了SSC，并且通过许多的例子证明了SSC的实用性。

---

6. On the Control Plane of a Self-service Cloud Platform

SoCC'14

• 阅读

Self-Service cloud Platform，SSC是最近提出的一个模型，这个模型能够提升公共个云平台用户数据的安全性以及隐私性。它能让用户灵活的部署安全服务，例如用户自己部署自省虚拟机来监控用户的工作虚拟机，并且禁止云操作者监听和修改客户虚拟机。SSC通过修改hypervisor的权限模型来达到以上的需求。

本文主要提出了基于SSC云平台的控制面板的设计，控制面板作为接口存在于在租户与云之间以及云主机之间。文章中介绍了SSC控制面板的新型的特性，例如指定虚拟机之间的依赖关系（A虚拟机能够dumpB虚拟机的内存）， 快速部署网络的middlebox，以及新的VM迁移协议。文章中介绍了SSC控制面板的设计以及实现。

6.1 Security

在SSC系统上面，每一个用户的VM必须有一个对应的Udom0，Udom0是所有的特权的来源，他负责管理和保护所有的客户虚拟机的安全。（一个用户对应一个Udom0，一个Udom0对应多个UdomU或者SD）例如,Udom0有I/O后端，能够产生SD，并且保存有用户的SSL私钥。

由于传统的控制面板并没有SSC的抽象概念，因此对待Udom0就和一个普通的用户虚拟机实例是一样的。如果简单的使用这样的软件来创建一个基于SSC的云平台的控制面板，云基础设施提供商将会很容易受到恶意客户机的攻击。这些恶意的客户虚拟机能够使用策略创建多个虚拟机，强迫云将这些虚拟机放到不同的物理节点上面（例如，这些虚拟机要求大量的资源）。
通过这个方式他们能够

1. 估计云的物理主机数
2. 绘制云的机器分布图
3. 反向工程破解云的迁移策略以及VM的放置策略。

然而SSC的控制面板能够处理这样的云特权模型的管理抽象概念。SSC的控制面板能够给客户端一个单独的控制的接口。这些接口就像是服务的前端把控制命令转发给单独的Udom0实例，然而并不会把这些Udom0暴露给用户。同时SSC管理面板让管理VM的放置，迁移以及客户虚拟机之间的通信对用户都是透明的。

6.2 Security Implications

由于虚拟机之间的依赖关系，例如虚拟机A作为虚拟机B的网络后端处理网络请求。这样的依赖关系就带来了云系统中的虚拟机的放置的限制。虚拟机A和B必须存在同一个物理节点上面。这样的限制可能会被恶意的用户利用发动probe-respone attack，通过不停的发送GRANT_PRIVILEGE命令要求多个虚拟机。当达到物理机器的上限的时候云管理将会拒绝请求，这样暴露了物理机器的配置（解决方案，事先定义一个Cluster）。

---

7. A Practical, Targeted, and Stealthy Attack Against WPA Enterprise Authentication

NDSS'13

• 阅读

无线的上网技术从根本上的改变了计算。能够让计算机在任意的时候，任意的地点，多样化的接入互联网。同时无线技术也带来了安全隐患。尽管不在同一个物理网络中，黑客也能接受信号发起未授权的连接。应为无线网络的重要性，有许多标准能够保护我们的无线网络。

在文章中，作者展现了一个新颖的高效的目标不同网络WPA Enterprise标准的evil twin attack。文章中展示了现在商用操作系统中用户无线管理接口界面的严重的设计缺陷。同时也强调了在无线网络的SSID与服务器端的授权证书之间的弱绑定问题。作者展示了攻击的实现以及讨论了相应的对策。并且在实验中没有一个用户能够检测到攻击。

---

8. Monitoring Integrity Using Limited Local Memory

TFIS 2013

• 阅读

系统完整性监控器（例如rootkit检测器）十分依赖从目标系统中获得的带代码和数据的页面的多少。为了防止被恶意软件或者被恶意的目标主机感染，最先进的系统完整性监控器利用虚拟化技术创建一个不被干扰的执行环境。因此虚拟化的架构也成为了TCB的一部分。然而现在VMM的代码结构已经非常的复杂了。并且这些代码还十分难以验证。

文章中作者介绍了一个新型的机器架构叫做LLM（Limited Local Memory）,LLM能为系统完整性监控创建一个备用防干扰的环境。在最近的多核架构上面实现了这个结构，并且每一个核心都有一个小的私有的内存空间。LLM架构设计有一个新型的安全分页机制，足够满足在没有硬件虚拟化的支持下启动一个防篡改的执行环境。作者通过在LLM架构中实现了一个rootkit检测器来证明该设计的可用性。这个rookkit检测器能够安全的检测目标虚拟机并且不会成为这个感染的受害者。

---

9. Cloud Computing Identity Management

SETLabs Briefings 2009

• 阅读

最新的技术使得多个服务商之间共同提供服务变得很便捷。用户很有可能有多个服务商的帐号，例如e-bay，Gmail，等等。每一个身份的可见性以及属性都必须被中心的可信策略框架所验证。IDM（Identity Management）在整个的云环境中都具有优势。云环境结合了各种各样的技术来满足多个软件和服务之间相互依赖的需求。这样的需求需要多个IDM。通过严谨的用户空间的共享策略，云中的多个不同的技术相互协作，并且像一个完整的个体一样工作。传统的IDM并不能满足云环境的需求。许多云系统的提供上都简化的所有权的IDM解决方案，但是这个方案有总所周知的问题。

9.1 UNDERSTANDING THE NEW DIMENSIONS OF IDM IN CLOUDS

云端的IDM必须管理——控制节点，动态的组合或者拆分机器，虚拟机的设备，服务的身份认证信息等等。云的部署是随着服务的开启和结束而动态变化的（IP是动态分配的），仅仅的管理用户和服务是不够的。目前的云系统需要能够动态的管理典型的IDM问题例如，分配资源，撤回资源，同步，权利，以及管理的生命周期等等。

---

10. On Fault Resilience of OpenStack

SoCC'13

• 阅读

云平台管理软件是云平台重要的组成元素。云平台管理软件管理云上面的各种资源。并且云平台管理软件的功能还在日益的加强，但是它的错误容忍却鲜有研究。本文展示了一个对于云平台管理软件OpenStack的错误容忍性的研究。作者建立了一个错误注入框架的原型。这个框架能够在处理外部命令时给OpenStack的服务之间的通信中注入错误，既可以在OpenStack的服务之间注入也能在OpenStack服务与外部服务之间注入。目前在两个不同版本的OpenStack中发现了23个bug。作者的发现展示了现有的云管理软件栈在错误容忍角度的设计与实现的缺陷。

---

11. Discretized Streams: Fault-Tolerant Streaming Computation at Scale

SOSP'13

• 阅读

许多的大数据应用都必须具有实时的响应。这些应用由于需要在巨大的数据集上面运行所以需要并行的架构，并且这个并行架构能够自动的处理错误以及straggler。遗憾的是现在有的并行流处理模型并没有提供高效的错误恢复，需要热复制以及长时间的恢复而且并不会处理staggler。作者提出了一个新的处理模型，D-Stream（discretized stream）能够克服上面提到的几个问题。D-Stream对于传统的复制以及备份策略以及容忍straggler的模型提供了并行恢复策略的支持。在试验中只有亚秒级的延迟以及亚秒级的错误恢复时间。最终，D-Stream能处理批处理以及交互式的查询模型就像MapReduce。作者在Spark Streaming中实现了D-Stream。

12. A Transparent Rollback Recovery Algorithm for virtual Machines using Quasi-Synchronous Checkpoint

2013 International Conference on Cloud Computing and Big Data

• 阅读

12.1 Abstract

针对云环境中部署的虚拟机的特性，本文展示了一个选择信息记录的准同步的检查点算法。这个算法保持原有的创建检查点的间隙，通过VMM记入volatile信息记录，并且选择性的记录stable存储记录来保持全局的一致性。性能测试结果现实这个算法不仅保持了自动的检查点而且还降低了通信的开销以及存储空间的开销。这个算法适合云来管理虚拟资源以及虚拟机迁移。

12.2 Introduction

在大规模的分布式虚拟系统中一致检查点算法将会带来巨大的性能的降低:

1. 信息同步时的巨大开销
2. 检查点时间的巨大开销
3. 巨大的存储开销，以及存储竞争

准同步检查点算法允许进程独立的做检查点,并且通过信息的之间的关联性确定一个全局的一致检查点。传统准同步检查点的缺点有时需要强制的做检查点，增加了额外的开销。由于虚拟化带来的便利，能通过细粒度的信息记录来保持固有的检查点周期的同时减少系统的容错开销。

本文展示了一个基于选择信息记录的准同步的检查点算法。该算法能够将信息记录临时的存储在VMM上面来保持虚拟机的固有检查点见习，并且降低通信的开销。（stable信息的存储才能构造一个一致的系统状态，这些stable信息是选择记入的结果）

12.3 System Model and Basic Definitions

$C_{i,x}$代表进程$P_i$的第X个检查点。
Global Checkpoint（回滚线recovery line）

$$GC = \{C_{0,m_{0}},C_{1,m_{1}}\dots C_{n,m_{n}}\}$$
只有满足一下条件才能称之为全局一致检查点。（不能理解这个条件）
全局一致检查点能够保证没有孤儿信息的产生。

12.4 Quasi-Synchronous Checkpoint with Selective Message Logging

当网络负载很低的时候将检查点同步带stable存储中。
但是光靠定时的准同步检查点不能保持系统的一致。必须通过日志来解决孤儿信息的问题。物理机器上面的VMM将会展示存储接受的消息日志。并且从这些信息中选择被MI接受的日志项记录stable存储于此同时SI节点并不会存储任何信息在stable存储里。

12.4.1 The Protocol of VM

对于虚拟机而言，只需要定时的创建检查点，以及通过检查点的编号计算回滚线。

12.4.2 The Protocol of VMM

接受的信息日志（$Received\_MsgLog_i$）: 由$VM_i$接受的信息队列。存储在VMM的volatile存储里面。
固定的接受信息日志（$Stable\_Received\_MsgLog$）: 由MI（multi-interval）节点接受的信息。存储在VMM的volatile存储空间里，并且将会在一定的时间里面刷入stable内存。
$CSN_i$: $VM_i$当前的检查点序列号。
$INCNUM_i$: 历史上面node发生错误的次数，每次发生错误和回滚回复都将自动增加。
$next_i$: 表示基本的检查点的间隔。
$Rsn\_List_i$: 记录从上一个检查点到现在时间点的接受信息的RSN（received serial number）。
$Ckpt\_Set\_Vector$: 一个位向量，记录在下一个时间cycle里面需要创建检查点的节点。

当计时的timer时间到的时候VMM将会检查$Ckpt\_Set\_Vector$。控制VM做以下操作。

1. 当$Ckpt\_Set\_Vector$的对应位为1，该虚拟机做检查点并且存储在VMM中。
2. 当$Ckpt\_Set\_Vector$的对应位为0 ，这VMM将$Received\_MsgLog_i$保存为$Stable\_Received\_MsgLog$，并且更新$Rsn\_List_i$。
3. 所有的虚拟机给$next_i$一个增量。
4. VMM根据现有的情况更新一致的Rollback line。

---

13 Defending against VM Rollback Attack

DSN-W 2012

• 阅读

13.1 Abstract

最近关于如何防止虚拟机被恶意的hypervisor的攻击越来越受关注。但是很多解决这方面问题的先前工作都容易被rollback攻击。由于很难分辨正常的suspend/resume操作，迁移操作与回滚攻击。有一些先前的系统只是简单的禁止虚拟机的回滚，而另外一些则需要用户的过度参与。作者在这篇文章中提出了新的思想来解决这个问题。在一个小的TCB中记录所有的suspend/resume操作以及迁移操作的日志，用户通过对这个日志进行审计来检查恶意的回滚的同时限制Hypervisor对该虚拟机的操作

文章提出的解决方案需要有一个end user能够判断这个rollback是否是恶意的。所以作者将所有的回滚的时间的日志都安全的记录起来。通过审计用户能够检测可以的回滚并且向云管理员提供这些操作的必要性。或者更加高级的定义回滚的策略限制云管理进行操作。这个解决方案仍然需要很少的用户参与。

13.2 Related Work and Design

CloudVisor: 采用nested VMM技术来隔离hypervisor与用户虚拟机。这个小的hypervisor通过监视hypervisor与虚拟机之间的控制流检查是否是合法的操作，保护了用户虚拟机的隐私性和完整性。控制EPT（extended page table）隔离他们的内存区域。并且在每次hypervisor访问的时候加密这些页面。并且采用MHT（Merkel Hash Tree）来保护虚拟机磁盘镜像的完整性。

H-SVM: 采用物理硬件中的microcode程序来加强内存的保护。物理硬件将hypervisor要访问的页面全部都加密一遍，并且使用hash tree来保护用户机内存的完整性，hash树的根需要被存放在受保护的内存区域。

HyperWall: 这是另外一个相关的工作。它通过扩展物理硬件来支持细粒度的控制访问存储。每一个虚拟机需要明确自己的隐私页面以供物理硬件保护。

然后CloudVisor，H-SVM都不能防御防御上面提高的回滚攻击（通过回滚暴力破解，跳过安全检查等等）。回滚攻击能够以多种的形式发动，例如hypervisor能resume一个老的snapshot，或者将现有的虚拟机克隆到另外一个机器上面，控制不同的版本。要分辨回滚攻击和正常的回滚是很难的。而HyperWall完全不能做虚拟机的快照，由于hypervisor不能访问用户的内存。并且hypervisor也不能迁移虚拟机，只允许self-migration。HyperWall要求了很多的用户的参，并不实际。

系统要求回滚操作不能在一个Running Epoch中（每个Running Epoch 开始与 VM boot/resume 结束与VM shutdown/suspend）

作者在CloudVisor中添加了4个Hypercall：vmboot，vmshutdown，vmsuspend和vmresume。这些操作控制域并不能跳过。
日志的记录就是在以上这4个hypercall的过程中实现的。每个日志项是一个三元组｛操作，时间戳，快照版本｝时间戳由硬件时钟支持。快照的版本是由磁盘的哈希，内存的哈希，CPU状态的哈希构成的。为了放置log被篡改每一次日志项增加了都向TPM的NVRAM中增加新的度量。由于虚拟机可能被迁移，所以虚拟机的日志也是分布在整个系统当中的。审计的时候需要将所有的log放在一起进行审计。

---

14. Detecting VM Live Migration Using a Hybrid External Approach

CLOSER'13

• 阅读

虚拟机的热迁移也能够让攻击者发动新型的攻击形式。攻击者能够攻陷hypervisor，然后将受害虚拟机迁移出去获得更多的资源的控制权。在本文中作者展示了第一个检测虚拟机迁移的方法总结。分别有内部监视以及外部监视两种检测的方法。同时提出了一个混合的外部监控手段采用ICMP ping的延迟手段以及基于NTP的time-lag检测手段来检测虚拟机的迁移。作者的工作是基于Konig and Steinmetz在2011年发表的文章。

14.1 Related Work

关于滥用虚拟器迁移的问题在Oberheide等人在2008的论文上已经说明了。Oberheide等人描述了3个攻击方式：控制面板，数据面板以及迁移模块。

提及了第13号文章的相关工作，Akoush等人在2010年发表的工作说明了迁移的性能是与内存的变化率以及网络的速率相关的。
Konig与Sternmetz在2011年的工作表明了ICMP ping是一个检测虚拟机迁移的合适的办法。ping的往返时间在虚拟机迁移的时候会变得很大。以及在虚拟机迁移的结束时间ping包可能会丢失。Nirschl在2011年的工作证明了ping是能够用来检测虚拟机迁移的。Konig等人同时也发现了在内存变化率不大的情况下CPU的负载并不会很大程度的影响ICMP ping的往返时间。

针对迁移攻击的三种方法

1. 入侵hypervisor的迁移模块
2. 在hypervisor的网络中建立一个子网代理，这个子网代理支持在不同的子网中进行迁移。
3. 将虚拟机迁移往另外一个host。（没有理解）

虚拟机迁移测试手法的统计
内部方法

1. hypervisor检测，通过检测hypervisor的指纹，判断虚拟机的宿主虚拟机是否以及变了。Ferrie，2006
2. 硬件检测，一个硬件的benchmark能被用来测试物理硬件是否以及改变了。Sonnek and CHandra 2009
3. Time-lag检测，度量NTP时间来检测一个time的lag（延迟）。在迁移进程的两个步骤里面，虚拟机会停止一段时间。将会产生一个突然的time-lag。
4. 延迟的度量，konig and Steinmetz在2011年的工作里面提出了这个新方法。

外部方法
主要是监控机制并不是实现在特权虚拟机里面。检测的方法大都类似，但是具体的实现并不一样。

以上的方法有些能够在热迁移过程中或者是热迁移结束时检测。

14.2 Hybrid External Approach

作者将基于ICMP pingdedelay measurement以及基于NTP的time-lag度量来检测一个虚拟机的热迁移。

---

15. Process-Oriented Recovery for Operations on Cloud Applications

SoCC'13 Poster

Author： Min Fu

• 阅读

在对云应用做零星的操作的时候会反生服务失效的错误。例如 ，升级，重新部署配置，迁移，调度。他们中的很多是由进程的错误产生的。在现实的大规模的系统中进场有多个操作进程在并行发生，这样也将会加剧错误诊断和恢复的问题。现有的回滚恢复机制基本都是假设组件会随机的fail并且使用基于检查点的回滚恢复以及补偿行为[1],以及redundancy and rejuvenation方法[2]。这些回滚机制并不会考虑特定的操作进程，例如是由脚本运行的，还是人与云的API以及不确定的资源进行交互等等。另外的方法例如FATE/DESTINI就是针对由系统内部的协议实现的进程的，依赖于系统自身的系统来检测以及从bugs中恢复。我们针对的问题是对于外部的的零星的操作的。

作者的方法是显示的对操作进行建模和分析。作者将进程划分为有多个step组成的section。分离的标准可以由于不同的目的而发生改变，例如错误诊断，一致性检查，恢复。对于恢复来说，作者的初始化分类标准包括：

1. 原子性的获得一组操作能够让恢复更加的简单。
2. 幂等的重新执行相同的操作或者参数化之后的操作来从错误中恢复。
3. 在回滚期间，细粒度的允许高层次重新执行已经完成的动作。
4. 在回滚过程中，允许执行替代的命令以达到同样的执行结果。

作者做出了一系列的声明代表了每个阶段执行的期望程序结果。作者使用了运行时的assertion评估以及监控系统[3]来检测每个section结束之后的错误并且在需要的时候出发回滚恢复操作。

作者在AWS的应用成立的一个典型的AMI驱动的rolling upgrade 进程上面应用了作者的方法。Netflix也有一个Asgard的工具支持这个进程。作者用他自己的分类方法将Asgard的内部回滚恢复组件与错误处理机制给分开了。作者同时也在一些section的结尾加入了能够触发日志的assertion评估。作者的程序能够更早检测到可能被Asgard遗漏的错误。作者发现Asgard并没有为re-executin设计相应的粒度以及idempotence幂等性所以在Asgard选中的代码段并不能执行基于re-execution的回滚恢复操作。我们为了从一些的错误中恢复设计了一些可以替代的外部命令。例如，对于一些意外停止的一些实例，可以重新启动它们或者kill这些实例然后依靠auto-scaling的组来重新启动他们。作者的回滚恢复的消耗明显低于Asgard。

现在，为了能够让操作者能够更加简单的设计与实现他们的原子操作的脚本，re-execution块以及为了恢复目的而设计的可替换的指令，作者开了patterns和frameworks。作者也将这些和assertion评估和监控框架进行了结合[4]。

---

16. Memoir: Practical State Continuity for Protected Modules

S&P'11

• 阅读

为了保护计算，一个安全的架构不仅需要保护那个软件，同样需要保护软件的操作时候的状态。如果软件回滚到一个正常但是老旧的版本，那么它很有可能发现错误。所以保护软件的状态不仅仅是保护状态的私密性与完整性。为了达到上上面说的目标，作者提出了Memoir，Memoir是第一能够保证软件模块状态的连续性的系统。换句话说，Memoir保护软件的状态保持持续并且不会被破坏。Memoir的最大贡献是在做到rollback resistance的同时并没有让系统更加的容易发生crash。Memoir实现了一个确定的模块，这个模块精确的将被保护模块的请求记录的总结存放在NVRAM里面。并且在发生crash的时候仅仅允许安全的命令重新执行。由于现在的硬件设备的NVRAM并不能频繁的进行读写，作者对这个问题也做出了优化。

作者为了确保其设计的正确性，作者给出了基于公理化的安全证明。作者还对Memoir的性能在真实的环境中进行了测试。

作者解决可信存储空间的不足，以及写入次数的限制，通过特别的数据结构将日志保护起来，只有在关机的时候才写入NVRAM。作者在基于Flicker的基础隔离了被保护的模块。

问题的解决有一下几个挑战：

1. 单调的计数器，防止回滚攻击的一个简单的方法就是在状态中添加一个可信的单调的计数器。如果在计数器跟新的时候发生了crash，但是这个新值却没有写入持久的存储之中，将使系统不能正常的使用。额外的，更具上面的讨论，物理的可信计算器也有许多的限制（计数太慢几秒一次）。
2. 允许重放，crash防止策略可能会允许不可信的代码重放它的输出。但是这个不可信的代码可能给出与前一次不同的输出，以发动重放攻击(两次不同的口令，进行暴力破解)。
3. 两步确认，能够达到crash抵抗的特性的标准的技术就是两步确认协议。这个一标准要求参与组件都展示的给出运行的过程个结果，当协调器获得了所有成员的输出结果之后会让所有的组件commit他们的操作。并且与这个协议的私密性和完整性相比它的原子性更加的重要。与其在NVRAM中存放单调的计数器，作者在其中存放的是上一次运行状态和输出的加密值的hash。不可信的系统如果想要被保护的模块去执行一个请求的话，需要提供现在的状态的密文，以及上一次的输出的密文。如果现在的状态和输出都一样匹配存放的VNRAM中的值，那么被保护的模块将会执行这个步骤。这个策略是可以的但是对于Memoir来说有两个大的问题，1）开销却很大，执行每个命令都需要访问TPM，2）两部确认协议将会引发基于旁路的回滚攻击[5]
4. 在加密数据上面的计算, 被保护模块允许任意的模块直接在明文的数据上面进行操作。

---

17. Multi-stage Replay with Crosscut

VEE'10

• 阅读

准确重放的应用：容错，精确诊断bug
重放的问题：在重放之前定义的记录规则下记录的重放记录并不能很好的完成终端用户的重放要求，这些记录往往包含的信息过少并不能准确的重放，或者这些记录包含了安全敏感的信息并不允许重放。Similarly,fixing the abstraction level at the time of recording often leads to asemantic mismatch with the end use of replay
本文的工作：对于不同的重放的需求允许定制重放信息的种类，Crosscut允许在时间和抽象层面上面划分日志
抽象层面包括：单个进程，应用，感兴趣的部件，并且排除了处理敏感信息的部件。文章认为带来问题的原因是系统在进行重放的时候并没有对记录下来的日志进行进一步的划分（细粒度处理）

Crosscut首先将在机器指令级别，综合地有效地做记录（这里的的记录可以进行全系统重放），记录不确定信息即外部的输入信息的开销往往小于5%，因此Crosscut记录下所有的信息之后根据需求重放。
Crosscut是如何处理日志的：

1. 可以挑出感兴趣的时间，应用，组件相关的日志
2. 可以挑出处理敏感信息的执行上下文环境，减轻隐私相关的问题
3. Crosscut可以按照抽象边界选择日志，例如内核类，用户类，中断类，程序类，甚至是单独的模块

本文贡献

1. 使用了多级重放的概念
2. 展示了如何使用relogging来生成一个更加有效的用户定制的日志
3. 本文实现了时间划分以及抽象划分两个基本功能，并且利用这两个基本功能达到多种不同的需求

---

18. Enabling Secure VM-vTPM Migration in Private Clouds

ACSAC'11

• 阅读

作者考虑的问题是解决在私有云中迁移基于vTPM的虚拟机的问题。并且给出了该解决方案在公有云中适用的详细调节，并且提出了一个适合于VM-vTPM迁移的vTPM密钥结构。并且之后在这个基础上提出的安全迁移的协议。
解决了如何为虚拟机提供可信计算功能的同时，并不阻碍虚拟机迁移的功能。
首先，明确了关于安全迁移的3个安全要求

1. 迁移初始化的授权
2. 迁移过程中实体间的可信链的保存
3. 迁移进程的隐秘性

其次，展示了现有的vTPM密钥结构要不是与物理的TPM耦合得太紧，不然就是耦合得过松。本文提出了一个新的密钥结构的设计，在物理TPM和vTPM之间的插入了一个中间层，并且提供密钥等级的逻辑隔离并且支持密钥迁移以及减少了对私有CA的依赖。本文是第一个提出设计符合迁移的vTPM的密钥结构，以及设计实现的VM-vTPM迁移规则。

安全迁移协议的要求

1. VM-vTPM的私密性以及完整性，不允许不安全的实体在VM-vTPM迁移的过程中得到任何的相关信息。所有的针对这个迁移的攻击都能被检测
2. 初始的授权，任何不可信的虚拟机没有办法迁移VM-vTPM。
3. 保存可信链。

作者的vTPM密钥结构，为了能够让迁移过程中重新生成的密钥数量尽可能的少，作者提出了在TPM与vTPM中新添加一层中间层。这个中间层由全局SRK（gSRK），一个一组连接TPM密钥以及vTPM相对密钥的的签名密钥（SK）。
作者进一步的将vTPM密钥划分为内部与外部密钥

---