论文阅读（二）

 

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

 

1. Privilege-Based Remote Attestation: Towards Integrity Assurance for Lightweight Clients

   1. 摘要

远程证实是用来确保远程用户证实被证实平台的完整性。二进制证实方式需要挑战者获取被证实平台所有可能的好的配置。本文提出基于特权的证实方法，通过忽略挑战者不需要的信息，减少了挑战者需要知道的可能的配置。对于这些被忽略的服务，挑战者确保他们没有特权来影响已使用的服务，为了实现这一点，被证实平台将解析二进制，找到调用的系统的API，从而度量软件的特权。

 

出发点：

• 挑战者需要知道所有可能的配置文件，考虑软件版本问题，这个已知的好的配置将会非常庞大，而且也不适合更新
• 不同的client依赖于不同的服务，因此，一个client可能并不需要知道其他的service的配置

 

定义：

一个软件的特权指的是一个软件模块访问一个资源或者至关重要的系统功能的可能性。

 

PRIBA与其他证实方式的对比：

• IMA：不适合动态配置，挑战者必须维护一个复杂的已知的好的配置list，在考虑软件升级情况下，list将变得十分庞大
• PBA：将配置映射为属性，由TTP负责映射，或者考虑到隐私保护，采用环签名的方式防止配置信息暴露。然而，在不使用TTP的情况下，同样无法解决庞大的好的配置的问题。
• 信息流图：采用MAC，所有的应用被分为高完整性与低完整性，因此只要保证高完整性成功证实，而低完整性无法沿着信息流图指向高完整性程序即可。减少list，但是依赖于事先定义的安全策略。

 

1. 架构

1. 度量

 

    度量进程：

 

    度量列表：module1是特权模块，只需要由IMA进行度量，module2是普通模块，故被二进制度量外，还需要进行特权度量：标注要访问的资源（网络、文件）及操作。

1. 验证

与普通二进制度量不同，基于特权的度量方式仅仅只考虑client需要的service的列表，并且确保其他模块不会对其有所更改。

交互协议：

<name, type, FileConsistency, NetworkAccess, Dependency>

name: 唯一标识

Type：privilege、non-privilege

FileConsistency: Path, AccessMode

 

二进制验证仅仅只需要将值与预期值对比，对于含有文件或者网络规则，验证进程首先生成特权模块列表，获取所有modules的交互协议，获取dependency。

相当于对于每个模块，建立起一个允许其他进程可以如何访问他的资源的规则，

 

1. A Feather-weight Virtual Machine for Windows Applications

   1. 摘要

许多容错与防干扰的系统要求在一个真实的可能永久崩溃的环境中执行不安全的程序。虚拟化技术完美地满足这个要求，因为其提供了一个真实隔离的执行环境。本文针对windows应用程序，提出了一个OS层面上的VM架构——feather-weight VM(FVM)，在这个架构下，VM能够与host共享许多的资源，而且相互之间是隔离的。实现这个的关键技术是命名空间的虚拟化，一种在OS系统调用接口上将资源重命名来隔离VM。通过copy-on-write机制，FVM允许大量的VM在物理上共享资源，在逻辑上相互之间隔离。主要挑战在于，由于windows上存在大量的命名空间与进程间通信，FVM应该怎样满足强隔离性。实验证明了FVM相对于现有的虚拟化技术，更加灵活、要求更少的系统资源、低的启动以及运行开销。

1. 出发点

传统的VM通过资源映射、指令解释等方案实现虚拟化，开销大，占用的系统资源多，本文通过命名空间，减少创建"VM"的延迟开销，减少每个占用的资源，从而能够启动更过的VM。资源重命名可以会引起大量的文件备份，FVM通过copy on write机制使得共享的足够多，而减少备份的开销。

 

1. 架构

 

    当VM刚创建的时候，与host一样共享整个的系统资源，当VM中的一个进程p通过FVM层发起不同的请求时，FVM会进行不同的重定向：

• p创建/a/b =>创建vm1/a/b
• p打开/a/b =>vm1/a/b不存在，创建并打开；vm1/a/b存在，访问为r，读取/a/b，访问为w，copy /a/b到vm1/a/b，打开vm1/a/b。
• 尝试去读或写，根据规则2
• p删除/a/b =>不删除/a/b，而是将文件名/a/b加入每个VM的数据结构中
• p进行进程间通信 =>如果两个进程不是在同一个VM中，阻塞

为了实现强隔离，FVM要能够标识系统资源的类型。File/registry/kernel object/network address/inter-process communication confinement/daemon service

 

 

VM state:在VM停止运行之后能够重新获取的信息，如：VM id, IP, root file directory, root registry hive, object directory, logs, policies.

VM Operation: CreateVM, CopyVM, ConfigureVM, StartVM, StopVM, SuspendVM, ResumeVM, DeleteVM, CommitVM

缺陷：

• 不可信的应用
• 守护进程服务很难备份
• 可能通过资源命名区分VM与host，进而攻击

1. 其他

来自知乎：

Copy-on-Write简称COW，好处就是能保证数据的完整性，掉电的话容易恢复。基本的原理是：当我要修改数据块A的内容的时候，我先把A读出来，写到B块里，如果写的过程掉电了，原来A的内容还在，如果是还写到原来的位置上，那么写入的数据究竟写了多少就不确定了，会不会破坏原来的数据也不好说。很多老的文件系统都不支持COW，比如FAT家族都不支持，但主流的文件系统都多多少少支持一点COW，比如BTRFS，NTFS等。其实COW对于用户数据来说，并不是特别重要，多数文件系统也不能承诺掉电以后究竟能恢复多少数据（我印象里只有tffs能做到恢复）。COW的好处是对文件系统元数据的保护，元数据包括文件名、文件大小、属性、路径结构等等，这些数据如果损坏，轻则丢失文件，重则分区完蛋。比如在FAT分区上，如果在大规模删除、复制文件的时候突然断电，文件夹结构可能就有破坏的风险，而如果支持COW的话，文件系统能很容易回滚数据到前一个状态（虽然也会丢失文件），保证文件系统自身结构稳定。

COW是一定会降低性能的，因为访问的数据量不同，还可能要扫描元数据的bitmap之类的东西，当然设计合理的话用户基本感觉不到（NTFS最早的版本就被用户抱怨说速度太慢，好像就是这个原因）。跟COW相关的还有一个叫Allocate-on-flush或者Delayed Allocation，大概可以称为申请时刷新或者延迟分配，好处就是降低碎片，坏处就是有点费内存。

1. Design and Implementation of an Efficient Framework for Behaviour Attestation Using N-Call Slides

   1. 摘要

本文设计与实现了针对企业中心应用程序的基于行为的证实方案。远程证实是用来度量一个特定平台的可信，过去的远程证实技术大部分基于hash的度量方式，这种方式虽然有效，但是不能度量一个应用的恶意行为，这些行为可能由缓冲区溢出，或者用户的错误配置导致。为了解决这个问题，运行中的动态行为度量必须执行。在这种考虑下，基于行为的证实方式得以提出，但是他们都面临着效率以及如何在挑战者端验证的问题。在本文中，我们设计并且实现了一个系统调用的滑动窗架构，能够用来减少对应用程序行为的度量，同时也能证实目标平台的可信。我们与先前未更改的系统调用做对比，表明本文在性能上的优势.

1. 背景

安全模型被分为两种：多级安全与多方安全。前者是信息流图按照层级，后者则不管层级、只管数据的完整性与机密性。

IMA的缺陷：

• 不能度量应用程序的运行时状态
• 应用程序的一点小的改变将会导致整个平台不可信
• 在目标应用程序与不可信的输入等之间没有隔离机制，没有办法度量一个特定应用程序的完整性。

PRIMA是对IMA的扩展，尝试解决IMA的缺陷，能够通过信息流的方式，借助SELinux策略，实现了CW－Lite模型，仅仅度量与目标应用程序相关的应用，以减少ML。但是PRIMA依旧存在一些缺陷：

• 依赖于hash
• 无法确定应用程序的动态行为
• SELinux必须可信

DBA（动态行为证实）运行时度量内核数据结构，通过图表示检测异常。缺陷：

• Client成为瓶颈
• 将数据发给远程用户有很大的网络开销

 

1. 问题陈述

基于hash的方式太严格，不适合检测远程系统的运行时状态，为了解决这个问题，有些学者提出了动态远程证实技术，基于系统调用的远程证实方式则通过抓取任意程序的运行时行为，并在远程端进行验证。由于系统调用太多，这种方式在使用时是不可行的，因此，需要给出一个能满足这种要求的证实方式：

• 在目标系统上运行的相关进程开销足够小，不能影响系统性能
• 为了减少网络传输开销，报告数据要足够小
• 实现构架是pluggable，能够被应用到其他技术中
• 证实不应该太严格，要能够支持良性改变
• 恶意程序的执行要能够检测到

1. 架构

架构图如下

包括：

1. Client Platform

   一个新的模块（EAM）：在创建窗口序列时直接建立LSM钩子，而不是在LSM钩子与系统调用之间做映射。与之前一个系统调用对应一次度量相比，本文采用建立LSM钩子对应的窗口的方式，之后度量这些窗口，最后才扩展。

   一个VFS用来以窗口的形式存储这些钩子。

1. 挑战者端

采用数据挖掘的方式获取训练集，从良性与恶意应用样本中进行训练。成功建立机器学习模型之后，产生一个nonce发送给目标平台，verification模块将检索最后的hash值与窗口的日志，确保日志的真实。

1. 良性程序节点

   用作机器学习模型的输入

   

2. 恶意程序节点

   用作机器学习模型的输入

1. PRIMA: Policy-Reduced Integrity Measurement Architecture

   1. 摘要

提出了PRIMA——一个基于信息流图控制的完整性度量方法。安全硬件目前的功能使得度量系统的完整性成为可能，并向远程第三方生成完整性证据。大量的方法因此提出，最简单的方案是度量加载的代码和静态的数据。这种方案存在两个缺陷：1）仅仅在加载进行度量不能精确反应运行时的行为，比如说一些不可信的网络数据的使用2）这种方案效率低，即使对目标应用不相关的实体也必须要能够被度量。传统的完整性度量方案基于信息流图，所有本文设计了PRIMA方法来度量信息流完整性，并证明这种方式能够达成我们的目标。PRIMA的原型实现基于IMA，并且使用SELinux来提供信息流。

（高完整性：来自可信的源，低完整性：可能来自不可信的源）

1. 出发点与模型思路

加载时度量的缺陷：

• 程序本身符合预期，但有不可信的输入
• 运行时动态变化
• 与目标应用程序相关的才需要是高完整性

信息流图完整性：

Biba完整性模型要求一个程序的代码或者数据只能被更高完整性的进程执行或读取。同时由于低完整性的程序不能修改高完整性程序，从而不需要被度量。Biba完整性模型使用信息流图能够保证：

• 可信主体：MAC策略里定义的可信主体子集，必须被远程第三方信任
• 可信代码、数据：可信主体执行的代码与相关静态数据必须对应于远程第三方已知的hash
• 信息流图：一个主体是可信的必须要求其信息流图来源于另外一个可信主体

例如：对于一个只关心公司应用的系统来说，如果公司应用程序本身是可信的，而且没有其他，诸如web浏览器等的client应用程序，向公司应用程序及其依赖的程序形成信息流图，那么就满足Biba模型。

Biba模型的缺陷：没有考虑到高完整性应用可能需要处理低完整性程序的输入，如sshd等需要接收网络输入。

Clark-Wilson模型更接近于本文思想：

• 初始验证：boot后系统状态时高完整性的
• 传输：操作高完整性的进程能够丢弃或升级他们接收的低完整性输入

本文弱化了Clark-Wilson模型，定义了CW-Lite模型：

• 仅仅只有接收低完整性数据的接口需要且必须过滤
• 不需要程序完备的形式化的证明，策略执行机制严格按照Biba模型，但是允许向过滤接口中输入低完整性数据

模型之间的区别如图二所示。因而，CW-Lite模型能够满足：

• 可信主体
• 可信代码、数据
• 信息流图
• 初始化验证：加载时验证
• 过滤接口：高完整性进程利用低完整性输入将被验证
• 过滤主体：只有过滤主体能够拥有过滤接口

1. PRIMA

PRIMA生成：1）度量列表M；2）TPM签名的hash：H。被证实平台将M与H发给验证者。

1. 要求

   1. 可信主体：

      T ⊆ S，S为所有的MAC策略主体。Mi = Mi−1||mT，Hi+1 = H(Hi||H(mT ))

   2. 可信代码、数据：

      me = (c||s||r)，c是代码或数据的hash，s是主体名，r表示主体是否可信。Mi+1 = Mi||me，Mi+1 = Mi||me

   3. 信息流图：

      G = (S, E)，s2读了s1的对象，有边s1->s2。

      在使用标准SElinux MAC策略（P）时，Mi+1 = Mi ||mP，Hi+1 = H(Hi||H(mP ))，远程验证者验证P，构建图G。

   4. 初始化验证IPV：

      初始load相当于是可信代码、数据，不需要再额外进行度量了

   5. 过滤接口

      过滤接口属于可信主体，不需要再额外度量

   6. 过滤主体

      F ⊆ S， F∩ T = ∅，对可信主体做扩展

挑战者的验证要求：

1. 迭代计算判断度量列表是否正确，根据P获取G（S，E）
2. 对于可信代码、数据m_e，验证hash
3. 对P中的任意主体s：对于可信主体s，验证G中指向s边的主体；对于过滤主体，无要求；对于不可信主体，无要求
4. IPV必须可信
5. 连接过滤主体的可信主体，自身可信，而且过滤接口可信才激活过滤主体

1. 度量

除了代码与静态数据，还需要度量的：

• MAC策略
• 可信主体：与目标应用相关的可信主体
• 代码与主体之间的映射

   

PRIMA与IMA之间的区别：

1. Sancus: Low-cost trustworthy extensible networked devices with a zero-software Trusted Computing Base

   1. 摘要

本文提出了Sancus，一个针对网络嵌入式设备的安全架构，Sancus支持从远程安装软件，并且维持高安全保证。Sancus同样支持向远程用户证实一个特定的软件模块是否受到破坏，以及认证从软件模块到软件提供者的消息。软件模块能够安全地维护贝蒂状态，能够安全的与他们认为可信的软件模块通信。Sancus一个重要的特点在雨不需要信任任何软件设施。TCB仅仅是硬件，而且硬件开销很低。

我们描述了Sancus的设计，并且在一个FPGA的原型系统上实现并进行评估，这个原型是在MSP430处理器的基础上进行扩展，扩展对内存访问控制、加解密的硬件支持。此外也给出了一个这个设备的C编译器。

 

基于程序计数器的内存访问控制在参考文献43： Efficient iso- lation of trusted subsystems in embedded systems。

1. Efficient isolation of trusted subsystems in embedded systems

   1. 摘要

许多嵌入式设备有着很强的安全要求，因为他们需要处理机密性的数据或者支持安全事务。一个原型实例是付款终端，为了确保敏感数据，比如说加密密码不被泄漏，系统的安全部分当成一个隔离的芯片进行实现，从而与系统的其他部分进行隔离。

但是隔离也能通过软件进行实现，高端的计算平台有一些硬件来指出实现虚拟内存与VMM，然而，许多的嵌入式系统缺少这些硬件特征。

本文设计了一个普遍的、轻量级的硬件机制，能够支持共享同一个处理器与内存空间的多个子系统之间进行隔离。一个原型就是支持保护密钥的加密系统的软件实现。

 

贡献：

• 一个新的内存访问控制模型，访问内存依赖于程序计数器的值
• 基于这个内存访问控制模型的自我保护模块的设计：一个软件模块能够为模块处理的数据、如何被其他模块所调用提供很强的安全保证
• 对这个设计的一个粗略证明
• 几个应用场景的讨论

 

威胁模型：

    攻击者能够向系统的内存空间注入代码，不能进行物理攻击。

 

安全属性：

• entry point的约束：软件模块能够安全地约束他们如何被调用。也就是说，软件模块的entry point是由模块提供者定义的，攻击者不能够随便跳转到模块的任意位置。
• 模块数据的安全：模块的敏感信息仅能够被这个模块读写
• 模块认证：模块能够认证其他模块的内存
• 模块之间的安全通信：模块能够有效的与他们认证的其他模块交互。消息的完整性与机密性必须能够保证。
• 最小化TCB

忽略程序本身的逻辑错误引起的攻击、忽略拒绝服务攻击

 

自我保护模块SPM：

• 三个段：SEntry（可以调用SPM的入口点）、SPulic（其他模块可读）、SSecret（敏感数据，不可信模块不可访问）
• 内存访问控制策略

SPM的创建与销毁如下图所示。创建：OS加载SPublic与Sentry；一个新的硬件指令setProtected创建SPM，定义三个段的边界，开启内存访问控制策略，清空SSecret；一个称为vault的模块初始化SSecret。Vault在boot后安装，并且不允许卸载。

    内存访问控制矩阵如表一所示：

 

硬件上的修改：

• setProtected
• isProtected：返回SPM的layout
• resetProtected

 

 

安全报告：

• Hash(SEntry || SPublic)
• SPM的layout
• CA的签名

验证过程：验证安全报告的签名，验证Sentry与SPublic的hash，使用isProteced验证SPM的layout

 

两个模块之间的认证协议：

• 单向

• 双向

• 双向，事件通知

 

    缺陷：

• 中断
• 交换
• DMA
• 分页
• 并发执行

1. Innovative Instructions and Software Model for Isolated Execution

   1. 摘要

近些年PC社区努力为开放平台提供一个安全解决方案。intel给出了一个新的技术来允许软件开发者在开放平台上开发和部署安全应用程序，允许应用程序在普通OS环境上执行并保证机密性与完整性。向ISA提供开发者可以自定义的强制实施容器硬件扩展，来完成这一目标，这些容器对OS不透明，但由OS管理。本文分析安全威胁与攻击，给出了ISA扩展，介绍了这个容器的编程模型。

 

SGX是增加到intel架构里的一系列新指令与内存访问控制的集合，允许应用程序实例化一个保护容器（enclave）。enclave是应用程序地址空间的一个保护区域，即使在特权恶意程序攻击下也能够保证程序的机密性与完整性。程序的代码与数据均被度量之后将保护区域加载到enclave中，一旦被加载，则不允许外部软件访问。

    对Intel架构的两个扩充：1. Enclave的内存访问控制语义修改2。地址空间映射的保护。

    要满足的安全属性：

• SGX提供对enclave的检测，以防一软件攻击、访问与更改数据、代码。
• SGX保护应用程序的机密性。
• SGX提供enclave实例之间的隔离。
• SGX能够应对重访攻击。

此外，允许只在enclave允许授权的位置执行，异常退出不会泄露enclave信息。

需要实现的目标：

• Enclave中的执行程序能够访问代码与数据，enclave外的访问会被禁止
• 虚拟地址到物理地址之间的转换应当与开发者开发时一致

   

1. SGX指令集

1. SGX数据结构

Enclave模式：改变内存访问语义，以执行额外的验证。

1. 访问验证流程

1. Using Innovative Instructions to Create Trustworthy Software Solutions

   1. 摘要

软件开发者在开发应用程序并保证重要数据的机密性时面对大量的挑战。由于应用程序开发需要大量的开发人员，即使在软件设计与实现阶段严格按照规范，也不能完全避免一些secret暴露给平台上的一些特权代码。Intel提出了一个新的安全技术，通过对应用程序生命周期内建立一个可信的域，来允许开发者控制敏感数据与代码。本文描述了这种技术如何保护私有信息。实例包括对本地进程的保护与云服务之间安全通信的建立。这将给出一个有用的软件设计模版来创建一个可信的软件。

1. 背景

SGX编程模型：

• enclave：应用程序地址空间内代码与数据的隔离区域。只有在当前enclave中执行的代码能够访问enclave中的数据
• measurement：在enclave初始化时代码与数据的hash值
• attestation：enclave向远程实体证明自身正确实例化的机制

使用SGX，执行以下指令就能够为应用程序创建一个enclave：

1. ECREATE：分配虚拟内存区域来承载安全代码与数据
2. EADD：将重要的代码与数据页加入enclave
3. EEXTEND：更新enclave的measurement
4. EINIT：锁住enclave内容，确保只有enclave内代码能够访问enclave数据

SGX使用两个相关的证书来attestation：

• Report：验证本地平台上enclave的正确性
• Quote：向平台外的实体验证enclave的正确性

验证通过之后，server与enclave之间将会建立安全通道用于传输信息。

1. 实例

   1. 一次性密码（OTP）

对于传统的OTP，必须要能够生成硬件令牌并分发给用户，这会带来很多额外的开销。OTP的软件版本虽然在性能上有优势，但是被恶意程序攻击的风险很大。该实例给出了一个使用SGX来创建软件OTP的解决方案。

1. 架构

分为server与client两个实体，在client端安装OTP插件、生成共享密钥的步骤如下：

1. 用户向金融机构FI申请一个账号
2. FI询问用户是否安装OTP插件
3. 用户选择安装
4. OTP插件启动并实例化OTPenclave
5. 插件请求FI一个预共享密钥
6. 插件使用TLS等方式认证FI
7. FI使用证实方式验证OTP enclave，成功则建立安全通道
8. 使用短信或者电话等方式生成一个认证码（证明是一个有效的用户）
9. 用户将认证码输入OTP插件，转发给enclave，转发给FI
10. FI验证合法用户、正确enclave
11. FI生成随机的预共享密钥
12. FI向OTP enclave返回预共享密钥
13. OTP enclave使用seal存储预共享密钥

1. Enterprise Rights Management

2. Secure Video Conferencing

1. Innovative Technology for CPU Based Attestation and Sealing

   1. 摘要

Intel的SGX技术是对intel Architecture的扩展，用来生成保护软件的容器。在enclave内部，软件的代码、数据、栈被硬件执行的访问控制策略保护，避免对enclave内容的攻击。本文描述了向enclave准备secrets的组建，包括基于硬件的证实、enclave软件seal secrets并向外导出等。

 

软件声明周期：

 

。。。

1. SGX: the good, the bad and the downright ugly

SGX代表着"Software Guard Extensions"，它改变了长期保留的假设：不同的软件包之间如何同时共存，甚至在某些程度上，如何在一个不可信的平台上相互竞争争取内存资源。这对于不论是恶意软件开发者还是防御方都有很重大的意义。

第一篇描述SGX的文章发表在Joanna Rutkowska's Invisible Things博客上，这些博客描述了SGX这个新的指令能够做什么。

简单来说，SGX是将一些新的指令集写入intel的处理器中。这些新的指令更像是为云服务器所设计的。SGX的设计目的在于为应用程序提供安全的enclave，这些enclave能够确保运行在其中的代码或者数据不用担心被监测或者被修改。利用远程证实功能，SGX能够允许开发者在一个不可信的环境中建立可信根。

开发Intel SGX的主要动机能够被总结为以下八个方面：

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

如果intel能够实现这些目标，这将是一个巨大的突破，然而，尽管信任看起来是一个很好的事物，但是更像是一把双刃剑。

很明显，intel想要解决的问题是可信云计算。对应用程序设计者而言intel给出的use case是很直观的。如果软件与硬件能够通过某些方式"seal"，并且即使攻击者拥有机器的管理员特权时，依旧能够防止攻击者在主存中校验数据，这将保证云中被保护的数据的完整性与机密性，而且云承载的应用程序的算法与设计思想也不会暴露给外部。

SGX的核心思路在于创建enclave。Encalve是针对代码与数据的一个隔离的加密的区域，enclave只在处理器中进行解密，所以即使直接读取RAM也是安全的。

    创建enclave是很直观的，由于enclave的创建是一个特权指令，因此OS是创建它的主体。因此，我们希望存在一个接受用户层发起创建enclave的API，操作系统也能够在这个API中实现一系列的访问控制策略。然而，这种方式是不可取的，因为这意味着特权的应用能够利用这个API直接创建enclave。

    Enclave借助加密技术，密钥的生成与管理是确保安全的一个重要的方面。SGX enclave使用的密钥通过一个新的指令EGETKEY生成。这个密钥包括三个方面，首先是SGX的安全版本数，这是由于版本可能意味着一些指令的变更或升级，其次是设备的ID，这是与处理器绑定的128bit的唯一标识符，最后是owner epoch，这使得拥有者能够增加一些额外的标识。

    有着这些密钥，很多功能便成为可能。一个最主要的应用就是一个enclave能够可靠地证实给远程用户。EREPORT这个新的指令就创建一个enclave加密的报告，远程机器能够验证这个报告，判断是不是来自于SGX。

    当我们考虑调试行为的时候，使用enclave也是一件很有趣的事。一个enclave仅仅在它明确赞同这个activity时才能够调试。当enclave不选择调试时，整个enclave对于调试器来说看起来是一个"giant instruction"。这对于想要保护应用程序算法等的人员来说是一个好消息，对于逆向工程来说则是一个噩耗。

    

使用SGX的好处：

    SGX是一个保护应用程序隐私与安全的强大的工具，即使是应用程序运行在不可信的系统上。比如，在enclave中运行一个网页浏览器，能够防止拥有特权的恶意程序来获取浏览器里存储的个人信息。Enclave能够保证恶意软件很难从内存中获取密钥环口令。虚拟机能够使用enclave来避免hypervisor看到一些重要的信息，这些信息只有在证实远程服务器后才会解密。视频游戏能够将他们大多数的逻辑代码放入enclave中运行，来防止转化为wallhacks、aimbots等。内核能够更好地抵挡干扰与钩子。这些应用是举不尽的。

 

使用SGX的坏处：

    然而，SGX也是恶意软件可以利用的一个主要的武器。目前看起来SGX不会让可信任的杀毒开发商来访问enclave的内容，来确定enclave中的应用是否是安全应用。因此，恶意软件也能够自由地创建enclave来防止操作系统、hypervisor、杀毒软件知道恶意软件在运行。由于无处不在的连接，这些小的恶意程序能够通过一些隐藏的链接，下载更复杂的恶意软件包。

    另一方面，由于enclave不能够处理在enclave内的异常，杀毒软件可能仍然需要判断是否有恶意程序通过文件IO或者其他IO运行着。更进一步来说，操作系统能够仅仅允许白名单中存在的程序创建enclave，然而，如果恶意程序能够成功的运行在ring 0，那么整个SGX的功能就可以被恶意软件开发者利用。

    比如以下例子：

• 僵尸网络创建者

  普通的僵尸网络操作是很直白的：在感染一台计算机之后，僵尸网络将下载与更新恶意软件。通过SGX，攻击者能够创建一个enclave，与他们自己的服务器来执行远程证实，然后能够成功接收到服务器的数据，从而在enclave中运行他们的命令。更进一步，通过加密，这些行为不能够被其他方所检测到。

由于SGX，防御方不能够扫描内存中的恶意软件，也不能为他们认可的创建签名，也许唯一的检测方案就是检查程序运行之后的效果。

• 视频游戏黑客

  和视频游戏开发者一样，视频游戏黑客同样可以利用enclave。目前大多数的杀毒软件仅仅简单的检查已知恶意程序代码内存中的特征值，然而，黑客可以利用enclave来避免被杀毒软件发现。

   

The Ugly。。

 

总结：

    对于防御方来说，使用SGX的指令集能够很容易的找到一种让他们的程序更安全的方案。这些新的指令集依靠平台的真实状态，给出一个新的防御机制。对于一些研究数据保护的人来说，这是一个很强大的工具。然而，如果攻击者利用这个技术，这将会造成更严重的问题。

    目前很少有关于允许杀毒软件开发商来访问enclave的讨论，但是终究看起来是不可能的，除非杀毒软件开发商能够拥有绝对的可信。即使允许，黑客极有可能将攻击点放在如何侵入杀毒软件本身。

    从工业角度来说，厂商也担心SGX enclave中可能存在某些后门。