论文阅读（三）

 

所有论文笔记请戳：http://blog.csdn.net/lwyeluo/article/details/54017718

 

 

1. SGX

SGXIntel开发的新的处理器技术，可以在计算平台上提供一个可信的空间，保障用户关键代码和数据的机密性和完整性，从SGX提出后，其吸引了一批系统和网络安全的研究者，NCCGroupSGX方面的资料进行了一个初步的总结，对研究者学习SGX技术具有很好的引导作用。这里主要根据该博文对SGX进行简单的整理。

目前并没有基于SGX的产品出现，不过学术界已经给出了一些应用来说明SGX的强大，相信工业界也正在开发对应的产品。SGX能将安全应用依赖的可信计算基TCB减小到仅包含CPU和安全应用本身，将不可信的复杂OS和虚拟机监控器VMM排除在安全边界之外。

 

SGX Intel Software Guard Extensions，顾名思义，其是对因特尔体系（IA）的一个扩展，用于增强软件的安全性。这种方式并不是识别和隔离平台上的所有恶意软件，而是将合法软件的安全操作封装在一个enclave中，保护其不受恶意软件的攻击，特权或者非特权的软件都无法访问enclave，也就是说，一旦软件和数据位于enclave中，即便操作系统或者和VMM Hypervisor）也无法影响enclave里面的代码和数据。Enclave的安全边界只包含CPU和它自身。SGX enclave也可以理解为一个可信执行环境TEE Trusted Execution Environment）。不过其与ARM TrustZone TZ）还是有一点小区别的，TZCPU划分为两个隔离环境（安全世界和正常世界），两者之间通过SMC指令通信；而SGXCPU可以运行多个安全enclaves，并发执行亦可。当然，在TZ的安全世界内部实现多个相互隔离的安全服务亦可达到同样的效果。

 

相关文献资料

---Intel发布了三个博客给出了SGX的设计目标（总共8个设计目标），作为理解SGX的背景材料比较重要：

1Intel? SGX for Dummies (Intel? SGX Design Objectives) : September 2013, Matthew Hoekstra

2Intel? SGX for Dummies – Part 2 : June 2014, Matthew Hoekstra

3Intel? SGX for Dummies – Part 3 : September 2014, Matthew Hoekstra

 

SGX是一系列的系统指令，为应用程序留出数据与代码的私有区域。动机有以下八点：

1. 允许应用程序开发者保护程序的敏感程序，避免被非授权的访问，或者被运行在更高层的特权恶意软件修改。
2. 在不破坏合法系统软件来调度与管理平台资源的前提下，允许应用程序来保护敏感代码与数据的机密性与完整性。
3. 允许计算设备的用户保持对平台的控制，支持自由安装与卸载应用程序及服务。
4. 允许平台来度量一个应用程序的可信代码，生成处理器对应的签名证实报告，这个报告包含度量值与其他证明该程序在一个可信环境中初始化的证书。
5. 允许使用常见的工具与处理器来开发可信应用程序。
6. 允许根据应用程序处理器的能力来据丁可信应用程序的性能。
7. 允许软件开发商使用自己选择的分发通道，来分发或者更新应用程序。
8. 允许应用程序定义代码与数据的安全区域，即使在攻击者能够物理控制平台或者内存攻击的情况下，依旧能够维护机密性。

 

---SGX本身的运行机制可以通过如下资料了解（前三篇是Intel2013HASP workshop上一连出三篇介绍SGX的文章）：

4Innovative Instructions and Software Model for Isolated Execution: June 2013, Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos Rozas, Hisham Shafi, Vedvyas Shanbhogue and Uday Savagaonkar, Intel Corporation

5Using Innovative Instructions to Create Trustworthy Software Solutions

6Innovative Technology for CPU Based Attestation and Sealing

7Intel? Software Guard Extensions(Intel? SGX) Instructions and Programming Model: June 2013, Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos Rozas, Vedvyas Shanbhogue and Uday Savagaonkar, Intel Corporation

8Intel? Software Guard Extensions(Intel? SGX): November 2013, Carlos Rozas, Intel Labs (given at CMU)

9Intel? Software Guard Extensions Programming Reference Rev 2 (#329298-002): October 2014

---Technische Universit?t Darmstadt (CASED)Ahmad-Reza Sadeghi作了一个关于嵌入式系统安全的讲座，其中对Intel SGX这块也有一个报告，总结的很不错，如下：

10Trusted Execution Environments Intel SGX

 

---SGX的基本运行方式和原理后，用户最关心的就是SGX能有什么实际应用了，大家都知道PC"WinTel"时代，也就是微软和因特尔密不可分的关系，最先实用SGX的就是微软了，值得关注的是微软的VC3Haven，文章分布参考如下链接：

11VC3: Trustworthy Data Analytics in the CloudOctober 2014

12Shielding applications from an untrusted cloud with Haven OSDI 2014

 

---作为安全方向的新技术，由于还没有实用的系统和产品，分析其安全性就是比较重要的一步，下面资料是关于SGX技术的一些安全分析：

13Intel Software Guard Extensions (SGX) Is Mighty Interesting: July 2013, Rich Mogull - Discusses the positive applications against malware, hypervisors and potential to replace HSMs.

14Thoughts on Intel's upcoming Software Guard Extensions (Part 1): August 2013, Joanna Rutkowska – Initial high-level thoughts on the functionality provided and how it compliments existing Intel technologies.

15Thoughts on Intel's upcoming Software Guard Extensions (Part 2): September 2013, Joanna Rutkowska – Lower-level thoughts on good and bad applications for SGX.

16SGX: the good, the bad and the downright ugly: January 2014, Shaun Davenport & Richard Ford -

 

SGX的模拟器与CPU

 

SGX技术有一定理解后，会忍不住想要亲自试试该技术，不过目前好像还没有支持SGXCPU出现，而且模拟器也很难找到。不过，模拟器是肯定存在的，不然微软也无法评估VC3Haven的原型实现了。从Intel发布的文献以及VC3Haven的论文中，可以发现，IntelSGX模拟器，并提供给了微软，而微软嫌性能不够，自己也开发了一套软件SGX模拟器（不过提供的安全保障不强）。因此，想要尝试SGX的模拟器，与Intel和微软联系，要到模拟器是不错的选择。

 

Georgia Institute of Technology也有一个项目，是用QEMUSGX，可以参考Intel SGX Emulation using QEMU

 

至于目前市场上是否存在支持SGXSGX2CPU，答案也比较明显，暂时没有。

 

[1] Intel? Software Guard Extensions (SGX): A Researcher's Primer.https://www.nccgroup.trust/en/blog/2015/01/intel-software-guard-extensions-sgx-a-researchers-primer/

 

1. The Protection of Information in Computer Systems

   1. 摘要

本文介绍了保护计算机信息不被未授权使用或者修改的机制，更注重于叙述支持信息保护相关的所必要的结构（软硬件）。本文分三部分进行描述，第一部分是目标功能、设计原则、基本保护与认证机制的实例；第二部分熟悉基于描述符的计算机架构，深入说明现代保护架构的原则、能力系统与访问控制列表系统之间的关系、对保护子系统与保护客体的一个简要分析。第三部分回顾之前的工作、现在的研究进展，并为将来工作给出建议。

1. 信息保护的基本原则

   1. 保护研究的思考

      1. 普遍观察

对于所有用户不应该拥有同一的权利的应用，必须要有一些机制能够确保计算机系统实现了预期的授权结构。

公司社团信息保护示例：对于航空座位预订系统，一个预订代理被授权来接受与取消预订，登机代理被授权来给出乘客预订信息，航空公司可能不希望预订代理来给出预订列表，而是从一个法律机构来拿到。

网上仓库存货管理系统：生成存货信息报告，报告包括公司信息，与工作（存货）质量等。需要保护不被公司外部获知，隐私保护（授权访问）。

Privacy与security：Privacy为私人数据能够在什么时候、地点分发给谁；security为控制想要修改、使用计算机或者信息的用户或其他人。

三种类型的安全问题：

1. 未授权信息发布
2. 未授权信息修改
3. 未授权使用拒绝

针对这些安全问题的一些安全技术做法：

1. 给文件打上标签，描述授权的用户（保护）
2. 通过口令等方式验证用户身份（认证）
3. 防护计算机避免电磁辐射窃听
4. 信息加密
5. 为有这台计算机的房子上锁
6. 控制谁能修改计算机系统
7. 使用一些冗余的电路、反复核对来维护安全
8. 证明软硬件符合预期

   1. 信息保护的功能层次

根据功能属性对这些安全保护机制进行分类：

1. 未受保护的系统：
2. all-or-nothing system：提供用户之间的隔离，有时允许共享信息
3. 受控共享：明确控制谁能访问系统上存储的每个数据项，可能提供授权用户访问列表，控制读写执行等操作。
4. user-programmed共享控制：标准机制里没有提供的访问约束，如在某个时间点能够访问某个数据项，两个用户同意后才能修改某数据。这种情况下，应该提供一个用户定义的受保护客体与子系统。保护子系统是一些程序、数据的集合，要求只有子系统的程序才能直接访问这些程序或数据。
5. 往信息中put字符串：前面三个是分发信息的条件，当前这点是信息分发之后的控制，如输出的数据打上某些安全级别标签

   1. 设计原则

保护机制的八个设计原则示例：

1. 成本：尽可能简单、小巧。
2. 保守设置（Fail-safe defaults）：访问控制决策是允许什么操作，而不是排除什么操作。即默认是不允许的。
3. 完全仲裁（Complete mediation）：对任何客体的任何访问都应该仲裁。
4. 开放设计（Open design）：被更多的人review，而增强安全
5. 特权分离：两个密钥才能解锁的保护机制比一个要好
6. 最小特权：使用最少的必要的特权来完成任务
7. 最少公共机制（Least common）：Minimize the amount of mechanism common to more than one user and depended on by all users.每一个公共的机制增加用户之间信息传递的潜在风险
8. 心理上可接受

传统的物理安全系统还暗示着应引入另外两种原则：

1. 工作因素（work factor）：对于攻击者来说，回避这些机制的成本与可获取资源的价值对比
2. 折衷记录（Compromise recording）：一个信息被破坏的可靠的记录，能够被更复杂的安全机制来利用

1. 技术支持

   1. 开发计划

   2. 信息保护概要

   3. 虚拟机隔离

一种使得虚拟机进行隔离的机制是描述符寄存器（descriptor register，DR），如下图。DR控制内存的哪些部分能够被访问，包括两个部分：base、bound。DR中的值为描述子（descriptor）。为保护描述子，控制谁能够使用描述子，最常见的做法是在处理器中增加一个特权位（privileged state bit），只有在该位为ON时才能改变描述子。图1中的S为supervisor，拥有这个特权。Supervisor程序维护一个描述子的表，每个是一个虚拟的处理器。

这样，虚拟处理器的实现有三层保护机制：

1. 不同程序不同信息：描述子确保其安全
2. 描述符寄存器：特权位确保其安全
3. 特权位：supervisor程序就是一个保护子系统

1. 认证机制

认证机制与保护机制不同，请求方是用户而不是程序，所以不能物理控制。最常见的做法是用户口令。

口令的缺点：

1. 知道用户习惯的很容易猜中口令，系统生成随机数当作口令很难记忆
2. 远程使用时，口令必须经过传递（故借助加解密系统）

所以很多系统使用不可伪造的物体来代替口令。

口令与不可伪造物体方法存在同样的问题：机器认证用户，用户没有认证机器。

1. 信息共享

信息共享保护机制的两类实现：

1. List-oriented：用户有唯一标识，信息（客体）维护授权用户列表。
2. Ticket-oriented：信息有唯一标识，用户有不可伪造的标识集合，每一个代表能够访问某个信息。

List-oriented要求客体遍历扫描，Ticket-oriented为用户访问前扫描，在应用程序拥堵情况下，后者更好。一个客体维护的表size为1，或者对应的ticket只有一个，就是完全隔离。

借助VM隔离的机制，可以通过两个描述子来共享信息，如图2所示。这样需要注意：

1. 如果虚拟处理器P1能够覆盖共享的数学程序，这可能影响虚拟处理器P2正常工作。

   解决方案：为描述子增加读写位，控制读写权限

2. 共享数学程序修改自身代码时要注意临时结果在内存中的位置，因为有可能同时独立执行。
3. 应该能够扩展到有多个共享程序。

   解决方案：能力系统（ticket-oriented）与ACL系统（list-oriented）

4. supervisor能够知道哪些能够使用共享程序。

1. 基于描述子的保护系统

   1. 地址与保护分离

段（Segment）：用来给内存地址区域提供唯一标识。每个段有一个不同的地址描述子（addressing descriptor），如图5所示。内存系统的所有用户都有相同的地址描述子，段描述子（保护描述子）有特权位用来决定用户特权。

1. 能力系统

如下图所示，假定每个处理器有4个保护描述子，A控制处理器，省略地址描述子。

1. Sego: Pervasive Trusted Metadata for Efficiently Verified Untrusted System Services

   1. 摘要

Sego是一个基于hypervisor的系统，目的在于为可信的应用程序提供隐私与完整性保证，即使在guest OS compromised的情况下。Sego验证操作系统的服务，如文件系统，而不是尝试去替换他们，通过在所有系统设备上联系可信的元数据与用户数据，sego验证系统服务的效率更高。本文在真实的工作环境中评估了sego的性能，实现了一个kernel fault injector来验证sego文件系统崩溃与恢复协议。

 

    目前一个趋势是移除特权软件的信任，比如说操作系统或者hypervisor。一旦特权软件是不可信的，系统服务的安全问题有两种方式来确保：

1. 替代：如haven等将可信软件的某些地址空间链接到受保护的存储区域中。
2. 验证：运行中验证行为是否与某个标准相匹配。

替代的好处在于应用程序完全控制它的软件可信计算基。缺点在于大量的库存在脆弱性，易受攻击。

这两种方式都会需要guest OS/hypervisor检查用户层程序使用的内存页，降低系统性能。

 

贡献：

1. 在可信元数据与不可信数据仍然耦合的情况下，建立一个模型来实现安全计算
2. 针对依赖不可信操作系统所提供的日志文件系统的应用程序，设计了一个高效的安全数据恢复协议
3. 原形实验与评估

    

威胁模型：

sego认为guest操作系统是不可信的。假设guest OS能够读或者修改用户应用程序内存的任意位置；能够拦截与操控任意IO设备路由进来的数据；当应用程序从系统调用或者中断返回时，能够修改控制流；攻击者能够crash OS来破坏应用程序。如应用程序在应用安全设置更新前，能够crash OS。

Sego依赖于可信的hypervisor，假设硬件忠实地执行hypervisor的代码。一旦一个应用程序信任其他应用程序，sego不进行保护。Sego不保证OS一直可用。

 

架构如图一所示。可信应用程序在high-assurance process(HAP)中执行。在启动OS之后，sego hypervisor通过一种HAP能够证实自身的初始代码与数据的方式来启动HAP，如TPM或者软件SGX。在HAP启动之后，hypervisor确保HAP的进程上下文、可信的地址空间与OS隔离。Hypervisor使用硬件嵌套页表来确保HAP地址空间（包括代码与数据）的隐私与完整性，HAP的地址页表称为S-pages，一旦guest OS尝试访问，抛出页表错，控制权移交给hypervisor。

libsego用来处理系统调用，可以看成是对C运行库的一个很小的修改。

每个HAP有一个不可信的trampoline代码，用来与OS进行交互。

一个流程为：HAP调用open，libsego将路径转换为一个标识符（OID），发起hypercall，由hypervisor判断是否允许，若允许libsego将参数复制给Tramp，tramp发起系统调用，获取返回值之后，libsego验证结果。

 

    Sego中的页表分为三种状态：

1. 不可信：sego不维护不可信块的元数据
2. 保留：能够被不可信的特权软件直接访问，但只包含部分元数据。
3. S-pages：不能被不可信特权软件访问，sego维护OID与offset。

转换关系对应的sego接口如下表。

 

    针对OS crash的情况，sego提供了对安全持久化存储的快速恢复功能。这种安全文件模型相对于普通文件来说：非稀疏的、非shrinking、要求同步。

    表二描述了hypervisor与OS对不同类型的s-files的不一致。

1. myTrustedCloud: Trusted Cloud Infrastructure for Security-critical Computation and Data Management

   1. 摘要

云计算提供了一个优化的基础设施来利用与共享计算与数据资源，同时允许按需使用模型，有效地最大化利用率。云计算同样提供了计算资源短暂的突然之间的扩展，对很多有时间和经济约束的社团来说极为重要。

本文中给出了一个示例，用来将可信计算技术整合到云（Eucalyptus）中。

 

云在使用时的问题：

1. 无法确保虚拟机的可信
2. 无法确保数据上传与管理的可信

原因在于依赖于一个不可信的基础设施来实例化VM、挂载块设备以及从web服务中获取数据对象。用户不能证实虚拟机，也不能证实他们上传的镜像是否与仓库中的一致。

一个解决方案是私有云，但是私有云要求在硬件、管理以及软件资源上有更多的投资。

 

Use case

1. 架构

    VM的完整性依赖于三个组件：VM，node controller（NC），storage controller（SC）。

    分三步进行证实：

1. 证实VM：确保VM上运行可信的程序与可信的配置
2. 证实NC：确保只有预期的软件栈能够操作VM
3. 证实SC：确保VM被绑定在可信的虚拟存储上

用户初始化三个不同的证实会话，验证所有组件的完整性，整合为一个最终的证实流程。这样做有两个问题：

1. 将云内部基础设施暴露给用户，扩宽攻击面，违背了VM与hypervisor的隔离原则
2. TTP的单点故障

deep quote（Towards Platform-Independent Trusted Computing）：用户仅仅初始化一个证实会话，返回的ticket里包括了这三部分的证实结果。

1.     NC的证实架构

    NC的初始化过程：

1. BIOS中支持TPM，度量物理系统的初始化过程。
2. Trusted Grub用来度量bootstrapping配置、内核与initrd镜像以及kernel启动参数。
3. Kernel里拥有IMA，度量模块、应用程序与相关的配置文件。

    libTPMs：vTPM的后端驱动

    seaBIOS：为每个VM实例化vTPM，度量初始的虚拟的硬件组件

    OpenPTS：实现VM的证实过程

    由于NC中kernel的内核被qemu直接加载，因而不存在boot loader。这样VM的kernel不能再加载前被度量，hash值也无法存入到vTPM中。为了解决这个问题，本文对qemu的配置firmware进行修改，以便于存储加载的内核的内存地址。Seabios解析这些内存地址，通过修改后的QEMU的IO来度量加载的模块并获取hash值，之后将这些hash值写入vTPM中。

1. SC的证实架构

1. Trusted Tamper-Evident Data Provenance

   1. 摘要

数据来源经常使用在安全设计和数据分析上，由于起源日志提供了数据变化的证据，起源日志的完整性对于整个取证进程的完整性来说也是十分重要的。然而，很少有解决方案能够完全满足这些信任要求。本文中，我们提出了一个使用TPM来实现证据防篡改，并且保护数据完整性与机密性的框架。同时，为了保证可用性，我们将来源日志可信存储在备份的服务器上。

 

将数据来源作为证据应该满足五个要求：admissibility, authenticity, completeness, reliability, believability.

1. Trusted Virtual Containers on Demand∗

   1. 摘要

基于TPM的可信计算技术希望使用硬件与密码学变换来向远程第三方提供一个计算平台的可信验证。然而，传统的可信计算方式受到可扩展性与灵活性的限制。本文通过在OpenSolaris中使用TPM来解决这些缺陷：内核按需创建轻量级的容器，使用DTrace或者其他工具来扩展证实到更多细微运行时属性，并举例说明了本文原型应用场景。

 

传统可信计算的缺陷：

• 可扩展性：一个可信环境能够多快构建？一个单虚拟主机上能够建立多少个可信环境？
• Expressiveness：如何处理运行时的动态属性？
• 灵活性：远程方是否可以协商对其来说更加重要的属性？

 

相关工作：

Towards Expressiveness:

• 基于属性的证实方式，缺陷：依靠TTP将配置映射到属性；假设OS是策略中立（？）
• 基于编程语义的证实方式
• 作者实验室：compartmented attestation将证实绑定在SELinux上，但是比较复杂，很难使用。（看参考文献）

Towards Scalability

• Trusted virtual domains将可信环境扩展到多个机器上。缺点：（？）；每个VM还需要证实他们自己的软件栈，证实庞大。

Towards Flexibility

• 虚拟化将该问题转化为配置不同的VM，然而，这样要求要证实所需要的虚拟化环境。

Solaris Zones/Containers

    相对于VM来说更加轻量级、启动更快、开销更少。

DTrace为特权程序提供了一个轻量级的方式来检测其他程序的的执行。

 

1. Verifying Cloud Services: Present and Future

   1. 摘要

随着基于云的服务越来越受到私人以及企业的欢迎，云消费者依旧缺乏一种工具能够用来证实这些服务按照预期在工作。这些工具应该要考虑诸如功能正确性、服务可用性、可靠性、性能、安全保证等属性。本文我们调研了在这些方面现有的现有的工作，标识在现有云技术中中提供证实工具的鸿沟。本文也讨论如何打破这些鸿沟所面临的挑战以及可能的研究方向。

云计算用户关注的问题：

1. 可信软件与服务器身份：服务运行在一系列正确的服务器集合，并拥有正确软件栈上
2. 功能正确行：服务启动之后，行为是否与所希望的一致
3. 性能与可靠：效率如何？可靠？可用？
4. 安全：服务遵守安全策略

    

应对这些问题的几个研究领域

1. 验证强服务身份（Verification of Strong Identities）

云服务提供商不能保证分发给用户的服务与实现一致。有可能有云管理员的误操作、其他云租户的误用，这些都有可能导致服务的误配置。问题为如何允许云服务商证实部署的服务是否符合预期，可能的技术是可信计算。

1. 验证云服务的功能属性（Verification Functional Properties of Cloud Services）

用户需要得到保证：云服务与云提供商给出的功能标准一致。本文给出了一个方案允许用户能够可扩展地验证服务的完整性，而不需要依赖于一个中心签证机构，或者访问真正的实现代码。基本思想是将验证过程解耦成三个阶段：test suite generation（黑盒子测试技术，覆盖标准里给出的行为）/test suite execution/validation of the results（样本测试）。

1. 验证云存储服务（Verification of Cloud Storage Services）
2. 性能与可靠
3. 面向安全的非功能属性验证

 

各个研究领域的相关工作、挑战与可能的方案

1. 验证强服务标识

要解决的问题：云提供商如何确保在云节点上运行的软件与实现的服务之间有个强的身份标识。

假定S是CSP给出的服务实现，S'是云主机上的服务实例，如何确保在整个生命周期内满足S＝S'。

为了满足强服务标识，云提供商应当给出可信容器。可信容器承载服务，并将其与其他租户或者云管理员隔离开来。当迁移发生时，验证目的地是否是一个可信容器，再通过加密通道迁移数据。

可信容器的实现语义可通过特权软件系统，特权软件系统使得管理员与其他租户都不能访问服务实例的状态。CloudVisor借助嵌套的虚拟化技术来保护Xen的guest VM的完整性与机密性。问题因而转化为如何让远程第三方验证云节点执行了一个可信的软件系统。这点可以通过可信计算的远程证实实现。

 

现有工作：

• IaaS上的强软件标识：

  架构：Santos（Towards Trusted Cloud Computing. In HotCloud, 2009）

  加固的hypervisor：CloudVisor（CloudVisor: Retrofitting Protection of Virtual Machines in Multi-tenant Cloud with Nested Virtualization. In SOSP, 2011）

• 借助可信计算的系统：

  Schiffman给出一个系统允许从云外部对云节点的hypervisor与VM镜像执行远程证实（Seeding Clouds with Trust Anchors. In WCCS, 2010.）

  其改进版本是Excalibur，防止由于TPM效率导致的瓶颈问题，并将数据seal到策略上，使得只有满足这些策略的节点才能unseal。如将VM镜像seal在CloudVisor上，则只有运行CloudVisor的节点才能实例化这个VM镜像。（Policy-Sealed Data: A New Abstraction For Building Trusted Cloud Services. In USENIX Security, 2012）

• 实现可信容器的系统：

  Nexus 在进程层次上提供可信容器概念，不需要运行VMM。(Logical Attestation: AnAuthorization Architecture for Trustworthy Computing. In SOSP, 2011.）

  Maniatis将可信容器作为沙箱，更适合网页应用程序的隔离。（Do You Know Where Your Data Are? Secure DataCapsules for Deployable Data Protection. In HotOS, 2011.）

   

  面对的挑战：

• 高层级PaaS容器概念：
• 与PaaS back-end集成
• 分布式与迁移PaaS服务实例

1. Attestation Transparency: Building secure Internet services for legacy clients

   1. 摘要

网络服务提供了丰富的功能，然而他们的使用引起了用户对隐私、安全以及完整性的担心。这是由于缺少如何确保server端正在运行的符合用户预期。在最坏的情况下，这些服务可能受到内部攻击。我们使用远程证实来确保服务的规划设计。我们讨论了证书透明性来分发关于服务是否存在、服务正在处理什么事件等的信息。总之，本文给出了一个允许传统的客户端来获取网络服务的安全保证。

 

问题：

在桌面平台上，用户能够知道运行的软件是不是他们所希望的版本，知道软件的行为与机制来防止对他们数据的非授权访问以及非授权修改。云服务不能提供相似的保证，从而引起了用户对隐私、安全以及完整性的担心。

本文聚焦于如何防止内部攻击，方法是使用透明性来抵御未授权的访问。使用硬件支撑的密封存储来确保用户的数据以加密的方式存储，构建机制来确保内部不能修改或者往软件中加入后门。

 

贡献：

1. 内部攻击保护：给出了如何构建安全网络服务。这些服务提供对计算与用户数据的完整性与机密性，能够抵御内部攻击，功能能够被远程证实。
2. 策略与更新机制：允许服务更新，对于用户来说这是透明的，同时确保服务的完整性与机密性。
3. 传统的客户端支持：证实透明性来防止服务提供者秘密地改变他们的服务。

 

1. 架构

   1. 威胁模型

假设承载这些服务的服务器使用了一些安全的enclave技术，用来防止敌手访问或者修改enclave中的数据或者代码。允许敌手拥有主动的网络攻击者的所有能力，能够控制承载这些服务机器的所有non-enclave软件，能够运行自己的软件来伪装成真实的服务。假设用户的客户端是安全的。

1. 设计

将所有的服务代码运行在enclave中，包括TLS session的建立、请求处理以及存储。使用seal存储来防止恶意内部攻击者来读取或者修改数据。在数据离开enclave前为数据加密。

利用证书透明来分发这些与independently-auditable的证实。Certificate Transparency（后面简称CT）是google提倡的为了提高SSL/TLS上更高信赖度的新技术。现在已被RFC化（RFC6962），用于防止证书的误发行的技术而备受注目。CT是起着每当CA机构签发证书，将所有的证书的签发行为都记录到审计日志作用的。主要是网站运营者，域名管理者之类的可以通过这个审计日志服务器来确认自己的域名对应的证书有无被其他CA机构签发，以此来防止非正常签发的可信证书被他人滥用。

虽然CT看起来仅仅起着提高证书的可信赖度，但并不意味着没有CT的其他的证书检测不可信。

1. 策略模型

为了证实这个服务，必须要证实1）服务的代码正确的实现了预期的行为2）在这个机器上没有其他的程序能够有接口来操作这个服务的代码或者观察它的内存。Enclave保证了第二点，对于第一点来说，如何为大多数普通用户设计模型？

1. 安全服务设计

安全服务架构如图3所示，提供的接口：

1. 通过TLS提供安全网络接口
2. 安全存储接口
3. 证实接口
4. IPC接口

1. Remote attestation for low-end embedded devices- the prover's perspective

   1. 摘要

嵌入式设备的大规模使用使得其越来越成为黑客攻击的目标。针对嵌入式的普遍的黑客攻击方式是是通过远程的恶意程序。一个有效地防御措施是远程证实，在这种机制中，允许一个可信的，通常是一个远程的验证者来检测一个不可信的、有可能被攻击的设备prover的内部状态。

尽管有很多的先前工作，远程证实依旧是一个很热的研究问题。大部分的证实机制也仅仅考虑这种verifier是可信的而prover是不可信的场景。与之相反的场景（prover是良性的，而verifier是不可信的）通常被回避。本文考虑到了prover的安全，包括假扮verifier、DDoS攻击以及重放攻击，所有的这些攻击方式将会导致对prover的证实功能的未授权的调用。我们认为针对这些问题对prover的保护必须是任何远程证实方法的一个很重要的部分。我们针对这种场景构建了一个新的roaming敌手模型，并给出了面临这种威胁的一些trade-offs。我们同时也给出了在最小化额外要求的需要确定的新的特征与方法。

 

1. 出发点：

攻击者有可能可以通过证实协议来对prove进行攻击。比如说伪造的verifier能够一直调用证实协议来引起prover的DDoS攻击，这种攻击方式消耗prover资源，影响prover的主要工作模块或者服务。

1. 贡献：

本文标识并且分析对运行在低端嵌入式设备上的prover的DOS攻击。首先，本文给出了证实协议如何来应对一个使用已知技术的外部敌手。然后，我们调研了一个更老练的roaming敌手来攻击prover并且通过一种标准的证实方法无法检测的方式来操作prover。这种攻击更加危险，因为roaming敌手能够擦除所有他出现的痕迹。之后，我们证实了两种通过在低端嵌入式设备上加上很小的硬件假设，来减轻roaming敌手威胁的两种方式，并且进行具体实现。

 

这篇的相关工作挺重要的~可以一个个看~

 

1. 敌手模型：

verifier（Vrf）向prover（Prv）发起证实请求（attreq），Prv上有一个可信的anchor来度量Prv的状态，这个anchor与Vrf有一个共享密钥（K_attest）。

如果敌手伪造Vrf导致Prv执行证实，这会产生一些额外的开销。

首先，执行证实来计算一个响应包括了计算针对整个内存的消息认证码（MAC），表一是使用SHA1-HMAC计算耗时。对512KB的RAM进行hash消耗754.032ms（怎么算的。。。。）。

其次，目前的低端设备证实技术假设在运行证实的过程中不能发生中断。因此，对证实的恶意调用对prover的主功能模块是不利的。

这种DoS攻击的主要原因是执行证实的prover与verifier的工作负载是不对称的。

 

敌手：

不能执行物理攻击。

1. 外部敌手Adv_ext：可以控制Prv与Vrf之间的所有交互。能够丢弃、插入、延迟消息，但是不能操纵Prv的内部状态。
2. Roaming敌手Adv_roam：除了外部敌手的能力之外，还能够用恶意程序来感染Prv并且可能擦除自身痕迹。假设其主要目的是为了实现DoS。可以分三步实现：1）偷听Vrf-Prv之间的证实交互消息。2）通过恶意程序攻击Prv，改变其本地状态，擦除自身痕迹。这一步通常改变的是Prv的动态数据，这种是不能被序列化得证实方式检测到3）回复之前的请求信息。

1. 对策

   1. 应对Adv_ext

      1. 认证Verifier请求

两种方式：公钥或者对称密钥

公钥加密对于嵌入式设备来说成本太高。表一中显示了使用ECC进行verify的时间是170ms，因而对于这种方式可以说在某种程度上本身就是造成了DoS。所以排除使用公钥加密。

对称加密来验证SHA1的HMAC能够在0.43ms完成。块加密方式比如AES更快，使用轻量级的块加密，如speck，能减少到0.015ms。

1. 处理reply

几种检测重放、重排序以及延时的攻击：

1. nonces：检测replay，需要维护nonce的history
2. counters：证实请求拥有一个单调增的计数器，prover每次接收当且仅当包的counter=自身的counter+1，检测重排序
3. Timestamps：假设有同步机制来实现时间戳，检测replay、reordered、delay攻击

1. 应对Adv_roam

应对Adv_ext的方式在应对Adv_roam是不可行的

1. counters：可以修改prover维护的counter，比如说减一，从而进行重放攻击
2. Timestamps：可以重置prover自身的时钟

相对而言，timestamps攻击要求更高，比如说将时钟后退t，那么必须延迟t时重发请求，而且重置时间会引起与外部的不一致，可能会被发现。

1. 保护密钥、counter与时钟

为了应对Adv_roam，必须保护密钥、counter与时钟。K_attest必须维护机密性、不可修改以及对正确的Code_attest可读。Counter与时钟必须写保护。这些保护需要有很小的硬件安全机制支持。

1. 实现

限制对系统关键资源（密钥、counter、时钟）的访问原语称为执行感知的内存访问控制（EA-MAC）。有很多先前的方式用来解决这个问题。

实现原型基于三个组件：ROM、EA-MAC、安全boot。Figure1是两个原型版本，均基于TrustLite证实架构。EA-MPU的内存访问控制规则将保护系统组件，如确保只有Code_attest能够读写counter。系统通过secure boot启动，确保启动时系统软件是可信的，从而设置EA-MPU规则并锁定以不允许修改。Code_attest同样写在ROM中，从而不能改变。

 

 

1. Things, Trouble, Trust: On Building Trust in IoT Systems

   1. 摘要

物联网目前面临着很多大量的安全和隐私挑战，其中一个突出的问题是如何在远程的IoT设备上建立可信。针对这个问题一个典型的方案是利用远程证实，远程证实是一个不同的安全服务，目的在于弄清一个可能被攻击到的远程设备的当前状态。远程证实覆盖了从重量级的基于硬件的安全技术，到相对轻量级的基于软件的技术范围，也包括了一些混杂了软件（控制流完整性）、以及硬件特征（PUFs）等的技术。本文从IoT的视角上调研了艺术级的证实技术的landscape，并且说明其中的大多数方案将在IoT可信建立中担任重要的角色。

1. 介绍

IoT一个重要的特征在于它包括了大量了低成本的、资源受限的设备，大量的设备引起的这些约束导致了重要的安全和隐私挑战。一个重要的挑战在于面对恶意软件的脆弱性。尽管恶意软件不是一个新的威胁，IoT却加宽、放大了攻击表面。这些威胁清晰的催发了验证远程IoT设备是否处于一个预料之中的状态。

本文两个主要目标：

1. 提供一个对在IoT中完成证实的overview
2. 展示多种类型的证实能够适应这种环境设定

 

证实可以分为这两个方面：

1. 获取prover的当前状态的进程（度量进程）
2. 将证据传输给verifier的协议

 

威胁模型：

最普遍的威胁模型是一个受到攻击的prover想要谎报当前状态给verifier，对应有很多种敌手类型：

1. 远程敌手：利用恶意软件远程影响prover
2. 本地敌手：偷听、妨碍prover的通信过程
3. 物理非侵入式敌手：能够执行侧信道攻击
4. 秘密的物理侵入式敌手：能够物理地抓取prover存储的任何信息
5. 物理侵入式敌手：除了物理抓取prover存储的任何信息外，还能够修改状态或者硬件组件

 

当代的针对于IoT设备的研究聚焦于如何减轻远程敌手的威胁。这主要有三个原因：

1. 最普遍的类型，由于来源于远程，最容易防卫
2. 潜在攻击范围最大
3. IoT设备不能承受安全硬件的开销

 

1. 基于安全硬件的证实

基于TPM的证实除了对物理侵入式敌手外，其他都能防御

 

1. 动态可信根

基于TPM的证实一个很大缺点在于：TPM Quote时有着潜在的大量的度量值，这使得验证一个quote极耗时间。动态可信根DRTM就是用来解决这个问题。DRTM允许读两个呢从用户指定的任何点开始。在DRTM启动之后，平台将执行一个局部的CPU重置，重置PCR的子集到一个初始状态。

 

1. 基于SGX的证实

对DRTM的概念进行扩展，SGX为应用程序软件提供了一个硬件加强的隔离执行环境。Enclave隔离并且保护程序内容，避免被其他软件干扰，并且提供了enclave之间或者与远程的证实方式。

 

1. 基于属性的证实

之前提到的几种方式均属于二进制证实，因为证实证据基于软件二进制。二进制的证实方式是很脆弱的，任何配置的改变或者软件升级将会导致不同的二进制hash值，即使prover依旧是处于一个可信的状态。验证者因此要求维护一个所有可信值得列表。为了减轻这个约束的影响，基于属性的证实方式将二进制度量转换为对于系统属性的一些陈述。

 

基于硬件的证实方式要求有一个明确的可信anchors，比如TPM或者SGX功能的CPU。然而，由于成本以及复杂性的考虑，IoT系统基本不可能拥有这些trust anchors.

 

1. 基于软件的证实方式

基于软件的方式没有硬件可信根，因而，不能假设prover上有安全的地方来保存secrets，也不能依赖于prover执行了可信的代码。相反，基于软件的证实方式利用侧信道信息，一如说执行某个特定计算prover所需要的时间。

许多文献里研究了基于软件的证实方式，Pioneer使用一个函数计算了设备的内存的校验值，这种方式会有运行时的反作用，因为这个函数的每次使用带来了额外的时间消耗，比如说延迟。基于时间的校验值也应该被应用到嵌入式设备中，然而也存在许多脆弱点。

通常来说，所有现有的基于软件的证实技术对敌手能力作出了很强的假设，也仅仅在verifier与prover直接通信的情况下才有效。这是因为：

1. Multi-hop必然会导致来回传输的延迟，对于任何基于时间的度量都会引入误差
2. Verifier必须能够检测到本地敌手的攻击，以防其与被攻击的prover合谋。

如果能够保证这两点，基于软件的证实方式同样能够应对上面提到的所有敌手模型。值得注意的是，基于软件证实在网络环境中不可行。

 

1. 混合证实

为了克服软件证实带来的限制，大量混合证实方案被提出。混合证实的目标在于，在最小修改硬件的情况下能够应对除了物理侵入式敌手外的所有类型敌手，而且是在网络环境中。

1. 最小化可信anchors

SMART架构为低端设备提供了动态可信根，没有指定特殊的内存管理或者保护特征。SMART架构有四个组件：

1. 在ROM中的一个证实只读内存代码区域
2. ROM中保存的一个只能被SMART访问的密钥存储区域
3. MCU访问控制，使得非SMART不能访问安全密钥存储以及中断SMART代码执行
4. 如果这些组件有报错，则进行充值与内存擦除

对于verifier来说，ROM中的证实代码会计算prover的内存的校验值，并返回给verifier。

 

TrustLite是低端嵌入式系统中的一个普遍的安全架构，允许一些特殊软件模块（trustlets）与OS独立的隔离。TrustLite给出了EAMPU（执行感知的内存保护单元）作为内存保护。EAMPU确定只有trustlet的代码能够访问trustlet内容。

 

TyTAN通过允许在运行时动态加载与卸载应用程序、实时调度保证与安全的IPC等提供了更灵活地架构。

 

1. 基于PUF的证实

基于软件证实方式要求prover与verifier直接相连，也不能验证底层硬件。而对于SMART、TrustLite而言，如果考虑到物理敌手，由于能够直接获取到prover的key，敌手很容易来伪造或者克隆prover。

PUF（Physically Unclonable Function）是一个特殊的物理结构，能够利用芯片制造商的侧信道，根据每个输入生成一个唯一的与硬件相关的输出。PUF能够将正式绑定到一个特定prover的指定硬件上，因而可以在混合证实进行利用以替换掉访问受限的设备密钥。

然而，环境对于PUF的影响较大，比如说电力供应波动等。PUF要求：

1. 一个低成本、低消耗的PUF的注册过程
2. 维护一个很大的PUF数据库

1. 基于控制流图的证实

代码的可信还包括运行时行为，静态的证实方案只考虑二进制代码的可信而忽略他们的运行时，从而不能检测到劫持程序的控制流从而使得软件崩溃的错误，比如说修改堆栈来转移控制流。有论文中给出了使用代码重用技术的内存攻击方式，在不用注入恶意代码的情况下，使得良性代码带上恶意程序。

本文作者尝试着在嵌入式设备上提供一个运行时的证实机制，该机制能够提供对程序执行路径精确的证实。程序的执行路径能够被加密成执行指令的分支、或者是累积哈希。在这两种情况中，执行路径都可以被认为是软件执行的指纹。

运行时证实相对于其他运行时防卫技术有一些优势，比如说控制流图完整性（CFI）。CFI强制实施以确保没有违背控制流情况发生，而运行时证实将报告执行的控制流。

1. 挑战

   1. 能够处理大量的IoT设备
   2. 处理异构设备
   3. 嵌入式设备资源受限

   1. 可扩展性

大多数论文聚焦于一个prover与一个verifier，事实是有很多情况要求一个verifier证实一个prover组（集群）。

第一个尝试解决集群证实的论文是SEDA: Scalable Embedded Device Attestation。对应的两点要求是：1）能够提供一个比对每个节点进行证实更有效的方式来证实一个集群，2）与现有的完整性证实方案独立。

初始化阶段：D8加入集群，对所有邻居进行join协议，这将与每个邻居建立一对证实密钥。

证实的原则是递归进行。Verifier选择一个节点，如D1，发送一个nonce，D1产生一个会话标识q。通过attdev协议，D1将证实请求（N，q）发送给所有邻居，等待回复，以此类推，从而形成一个以D1为根的树，证实报告将从叶子节点汇聚到根节点。

1. prover的视角

真实环境中，敌手可能扮演成verifier，形成对prover的未认证的证实，从而进行DDoS攻击。