Intel SGX技术详细解释（非常棒）

太过爱你忘了你带给我的痛 2022-02-03 04:05 1899阅读 0赞

[http://www.jos.org.cn/html/2018/9/5594.htm\#b18][http_www.jos.org.cn_html_2018_9_5594.htm_b18]

随着信息技术的迅速发展与广泛应用, 人类社会已经进入了一个崭新的互联网时代.一方面, 人们享受着互联网科技带来的便利; 另一方面, 由网络和信息系统构成的网络空间也面临着日益严峻的安全问题.信任是网络空间中安全交互的基础, 但随着软件复杂度和攻击水平的提高, 移动环境和云平台的安全对硬件和平台安全机制的需要更加迫切, 基于硬件的可信执行环境必不可少.以处理器安全为核心的硬件安全技术竞相发展, 应用广泛的主流技术包括虚拟化技术如Intel VT(Intel virtualization technology)与AMD SVM(AMD secure virtual machine)技术、基于可信平台模块(trusted platform module, 简称TPM)的可信计算技术如Intel TXT(Intel trusted execution technology)、嵌入式平台ARM TrustZone安全扩展等.其中:虚拟化技术基于特权软件hypervisor对系统资源进行分配与监控, 极大提升了资源利用率, 但hypervisor潜在的软件漏洞可能威胁到整个系统; 基于TPM的可信架构在程序加载时进行完整性度量, 却难以保障程序运行时的可信执行; TrustZone为程序提供了两种隔离的执行环境, 但需要硬件厂商的签名验证才能运行在安全执行环境, 这一特性使得多数软件开发者望而却步.

2013年, Intel推出SGX(software guard extensions)指令集扩展, 旨在以硬件安全为强制性保障, 不依赖于固件和软件的安全状态, 提供用户空间的可信执行环境, 通过一组新的指令集扩展与访问控制机制, 实现不同程序间的隔离运行, 保障用户关键代码和数据的机密性与完整性不受恶意软件的破坏.不同于其他安全技术, SGX的可信计算基(trusted computing base, 简称TCB)仅包括硬件, 避免了基于软件的TCB自身存在软件安全漏洞与威胁的缺陷, 极大地提升了系统安全保障; 此外, SGX可保障运行时的可信执行环境, 恶意代码无法访问与篡改其他程序运行时的保护内容, 进一步增强了系统的安全性; 基于指令集的扩展与独立的认证方式, 使得应用程序可以灵活调用这一安全功能并进行验证.作为系统安全领域的重大研究进展, Intel SGX是基于CPU的新一代硬件安全机制, 其健壮、可信、灵活的安全功能与硬件扩展的性能保证, 使得这项技术具有广阔的应用空间与发展前景.目前, 学术界和工业界已经对SGX技术展开了广泛的研究, Intel也在其最新的第六代CPU中加入了对SGX的支持.

本文重点分析了Intel SGX技术的基本原理及关键技术, 并深入讨论了针对SGX的侧信道攻击和防御; 同时, 将该技术与其他可信计算技术进行了对比分析, 也着重分析了其优势和不足, 并进一步讨论了该技术的相关学术研究工作和商业应用模型; 最后, 结合当前可信计算领域存在的安全问题和该技术在安全方面的优势, 展望了该技术的未来发展方向和应用需求.

1 SGX架构概述1.1 SGX技术概述

Intel SGX\[[1][], [2][]\]是Intel架构新的扩展, 在原有架构上增加了一组新的指令集和内存访问机制\[[3][]\].这些扩展允许应用程序实现一个被称为enclave的容器, 在应用程序的地址空间中划分出一块被保护的区域, 为容器内的代码和数据提供机密性和完整性的保护, 免受拥有特殊权限的恶意软件的破坏.SGX整体架构如[图 1][1 1]所示.

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;"><img alt="" src="http://www.jos.org.cn/html/2018/9/PIC/rjxb-29-9-2778-1.jpg" width="200"></td> 
   <td style="vertical-align:middle;">Fig. 1&nbsp;Architecture description of SGX图 1&nbsp;SGX整体架构</td> 
  </tr> 
 </tbody> 
</table>

SGX的实现需要处理器、内存管理部件、BIOS、驱动程序、运行时环境等软硬件协同完成.除了提供内存隔离与保护安全属性, SGX架构还支持远程认证和密封的功能, 可用于安全软件应用和交互协议的设计.

1.2 SGX的设计目标

(1) 允许应用程序开发者保护敏感数据不被未授权访问或者更高特权级别软件的修改\[[4][]\-[6][]\];

(2) 使得应用程序能够拥有保护敏感代码和数据的机密性与完整性的能力, 而不会中断这些资源被合法程序和系统调度、使用和管理的能力;

(3) 使得计算设备的消费者能够控制自己平台, 并且具有自由安装和卸载应用与服务的能力;

(4) 使得平台能够度量应用程序的可信代码, 生成签名验证, 并且度量和认证过程的代码都能够在可信赖的环境中正确的初始化;

(5) 使得可信应用程序的开发过程中能够使用原来的工具和流程;

(6) 允许可信应用程序的性能能够随着处理器的能力增强而得到扩展;

(7) 使得软件代理商能够使用它们选择的分发通道来分发、更新可信应用程序;

(8) 使得应用程序可以定义一个安全代码和数据区域, 这一区域可以维护其机密性, 即使攻击者能够物理上控制这个平台以及产生对内存的直接攻击, 也能够有效加以抵御.

2 SGX关键技术2.1 Enclave安全容器

Enclave是一个被保护的内容容器, 用于存放应用程序敏感数据和代码\[[7][]\].SGX允许应用程序指定需要保护的代码和数据部分, 在创建enclave之前, 不必对这些代码和数据进行检查或分析, 但加载到enclave中去的代码和数据必须被度量.当应用程序需要保护的部分加载到enclave后, SGX保护它们不被外部软件所访问.Enclave可以向远程认证者证明自己的身份, 并提供必需的功能结构用于安全地提供密钥.用户也可以请求独有的密钥, 这个密钥通过结合enclave身份和平台的身份做到独一无二, 可以用来保护存储在enclave之外的密钥或数据.

所有的enclave都驻留在EPC(enclave page cache)中, 这是系统内一块被保护的物理内存区域, 用来存放enclave和SGX数据结构\[[8][]\].EPC布局由平台具体实现决定, 如果CPU支持SGX架构并在加密保护的DRAM (dynamic random access memory)中实现EPC, 那么它也支持BIOS保留一段叫PRM(processor reserved memory)的内存范围.BIOS通过配置一组范围寄存器分配PRM.具体的PRM和EPC布局和平台有关, 并取决于BIOS设置, 下[图 2][2 1]是一个PRM和EPC布局的例子.

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;"><img alt="" src="http://www.jos.org.cn/html/2018/9/PIC/rjxb-29-9-2778-2.jpg" width="200"></td> 
   <td style="vertical-align:middle;">Fig. 2&nbsp;Sample layout of PRM图 2&nbsp;PRM布局示例</td> 
  </tr> 
 </tbody> 
</table>

Enclave具有如下特征.

(1) 具有自己的代码和数据;

(2) 提供机密性保护;

(3) 提供完整性保护;

(4) 具有可控的入口点;

(5) 支持多线程;

(6) 对应用程序内存具有最高访问权限.

Enclave的结构如[图 3][3 1]所示, 其中, TCS(thread control structure)保存着进入或退出enclave时恢复enclave线程的特殊信息.每一个enclave中的执行线程都和一个TCS相关联, 它需要4K字节对齐, 由多个部分组成, 例如保留位(RESERVED)、标志位(FLAGS)、状态保存区偏移量(state save area offset, 简称OSSA)等.

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;"><img alt="" src="http://www.jos.org.cn/html/2018/9/PIC/rjxb-29-9-2778-3.jpg" width="200"></td> 
   <td style="vertical-align:middle;">Fig. 3&nbsp;Schematic diagram of enclave图 3&nbsp;Enclave示意图</td> 
  </tr> 
 </tbody> 
</table>

2.2 Enclave保护机制

针对enclave的保护机制主要包括两个部分:一是enclave内存访问语义的变化, 二是应用程序地址映射关系的保护, 这两项功能共同完成对enclave的机密性和完整性的保护.

2.2.1 内存访问语义

在系统内分配一块被保护的物理内存区域EPC, 用来存放enclave和SGX数据结构\[[9][]\].必须保证内存保护机制在物理上锁住EPC内存区域, 将外部的访问请求视为引用了不存在的内存, 使得外部的实体(直接存储器访问、图像引擎等)无法访问.对于使用MOV等指令访问enclave内部的页面的情况, 硬件将执行下列的检查.

(1) 处理器当前运行在enclave mode中;

(2) 访问地址在enclave地址空间;

(3) 物理地址在EPC内存中;

(4) EPCM(enclave page cache map)检查, 请求访问的页属于正在运行的enclave(只有enclave内的代码才能访问该enclave的内容).

系统在SGX调用前, 必须处于保护模式, 且需要支持分页.SGX所提供的内存保护机制, 在保护模式所提供的段保护、页保护机制基础上进行进一步的内存保护, 访问地址由虚拟地址转换为物理地址进行访问.对内存的访问可分为如下5种类型, 如[图 4][4 1]所示.

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;"><img alt="" src="http://www.jos.org.cn/html/2018/9/PIC/rjxb-29-9-2778-4.jpg" width="200"></td> 
   <td style="vertical-align:middle;">Fig. 4&nbsp;Memory access control of SGX图 4&nbsp;SGX的内存访问控制</td> 
  </tr> 
 </tbody> 
</table>

(1) 运行于非enclave模式的处理器访问PRM之外的内存, 按照保护模式下的机制进行访问;

(2) 运行于非enclave模式的处理器访问PRM内部内存, 将被视为引用了不存在的内存;

(3) 处理器运行于enclave模式, 访问的页面不在enclave的虚拟地址空间, 但是处于EPC的区域范围内, 则CPU将这次访问视为引用了不存在的内存;

(4) 处理器运行于enclave模式, 硬件允许enclave代码访问处理器保留内存(PRM)外部的地址;

(5) 如果页面在enclave的虚拟地址空间外, 且指向PRM页面, 硬件将阻止访问并且发出异常.

简而言之, enclave外部的应用程序不能访问enclave内存; enclave内部的代码在EPC范围内只能访问属于自己的内存区域, 不能访问别的enclave内存; 对于PRM以外的内存, 则按照系统中其他的保护机制进行访问.这样的内存保护机制, 防止了enclave内部运行的程序被其他恶意软件盗取隐私信息和篡改.

2.2.2 地址映射保护

EPC内存以页为单位进行管理, 页的控制信息保存在硬件结构EPCM里, 一个页面对应一个EPCM表项, 类似于操作系统内的页表, 管理着EPC页面的基本信息, 包括页面是否已被使用、该页的拥有者、页面类型、地址映射和权限属性等\[[10][]\].EPCM结构在CPU地址映射过程中用于执行enclave页面的访问控制, 逻辑上而言, 它在保护模式的段保护和页保护机制的基础上增加了一层安全的访问控制.EPCM结构由PMH(page miss handler)硬件模块访问, 这个模块通过查询页表(系统软件维护的)、范围寄存器、EPCM来进行内存访问.EPCM逻辑结构图如[图 5][5]所示.

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;"><img alt="" src="http://www.jos.org.cn/html/2018/9/PIC/rjxb-29-9-2778-5.jpg" width="200"></td> 
   <td style="vertical-align:middle;">Fig. 5&nbsp;Logical structure of EPCM图 5&nbsp;EPCM逻辑结构</td> 
  </tr> 
 </tbody> 
</table>

2.2.3 Enclave机密性和完整性保护

应用程序在申请创建一个enclave时, 需要进行页面分配、复制程序代码与数据和度量操作, 创建过程的最后一步需要对enclave的完整性进行验证, 判断特权软件在创建过程中是否篡改了程序数据, 如分配了多余的页、将恶意代码复制进来, 或是篡改了复制的数据等.通过对每个添加的页面内容进行度量, 最终得到一个创建序列的度量结果, 保存在enclave的控制结构中.然后, SGX通过一条初始化指令将这个结果与enclave所有者签名的证书中的完整性值进行比较:如果匹配, 则将证书中的所有者公钥进行哈希, 作为密封身份保存在enclave控制结构中; 如果不匹配, 则说明创建过程存在问题, 指令返回失败结果.

成功进行了初始化指令之后, 才能进入enclave执行程序, 此后SGX提供的内存保护和地址映射保护使得外界无法访问enclave内存, 从而保证了enclave的机密性和完整性, 远程的认证者可以通过enclave的完整性度量值和其密封身份, 确保其正确地创建.[图 6][6 1]对这个过程进行了描述, 其中, 较粗箭头表示请求的操作, 细箭头表示具体步骤.

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;"><img alt="" src="http://www.jos.org.cn/html/2018/9/PIC/rjxb-29-9-2778-6.jpg" width="200"></td> 
   <td style="vertical-align:middle;">Fig. 6&nbsp;Process of establishing protection图 6&nbsp;Enclave建立保护的过程</td> 
  </tr> 
 </tbody> 
</table>

2.3 SGX认证

SGX提出了两种类型的身份认证方式:一种是平台内部enclave间的认证, 用来认证进行报告的enclave和自己是否运行在同一个平台上; 另一种是平台间的远程认证, 用于远程的认证者认证enclave的身份信息.

当enclave向平台上其他enclave报告身份时, 先获取当前的enclave的身份信息和属性、平台硬件TCB信息, 附加上用户希望交互的数据, 生成报告结构; 然后获取目标enclave的报告密钥, 对报告结构生成一个MAC标签, 形成最终的报告结构, 传递给目标enclave, 由目标enclave验证请求报告身份的enclave跟自己是否运行于同一平台.

为了实现远程认证, 需要引入一个特殊的引用(quoting)enclave.同一平台enclave之间的验证使用的是对称密钥, 不适用于远程认证, 因此, 平台间的认证采用非对称密钥机制.由引用enclave创建平台认证的签名密钥EPID(enhanced privacy identification), 这个密钥不仅代表平台, 还代表着底层硬件的可信度, 并且绑定处理器固件的版本, 当enclave系统运行时, 只有引用enclave才能访问到EPID密钥.

远程认证的过程中, 假设远程认证方*B*要认证enclave*A*, *A*先执行EREPORT指令, 将*A*的身份和附加信息组合生成REPORT结构, 利用引用enclave(称其为*Q*)的报告密钥生成一个MAC, 连同报告结构一起发给*Q*, *Q*通过该结构验证*A*是否运行于同一平台, 然后将它封装为一个引用结构体QUOTE, 并使用EPID进行签名, 将QUOTE和签名一同发给远程认证者.报告结构还需提供额外的用户数据域, 可用来传递用户自定义的信息, 以支持更复杂的交互方式.

3 SGX在云安全中的应用进展3.1 基于SGX构建云端应用安全隔离执行环境

当前, 云计算环境需要可信计算的支持, 云环境的构建通常使用传统分层的安全模型来保护特权程序免受不可信的用户程序的攻击, 但是却不能保护用户程序的数据被特权软件所访问和篡改.这导致云环境下的用户只能被动地相信云服务供应商的硬件和软件的可靠性, 以及管理人员不会去窃取自己的私密数据.

目前, 保护云计算环境安全的方法主要有3种.

●  第1种是基于特定的硬件保护关键的秘密信息, 如密钥的安全.该方法难以保证整个应用程序的安全, 且密钥通常会以明文的形式在不可信节点上使用;

●  第二种是基于可信的VMM(virtual machine manager)来保护应用程序, 该方法需要整个VMM可信, 并且无法防止特权用户窃取用户隐私数据;

●  第3种方法是基于密文数据的计算, 如密文检索, 但该方法在性能方面存在局限性.

文献\[[11][]\]利用Intel SGX技术为用户程序提供一个安全的隔离执行环境, 从而防止用户数据被特权软件访问, 或是受到基于硬件的攻击(如内存扫描).方案基于Drawbridge\[[12][]\]沙箱机制, 为用户程序的运行提供了一个Picoprocess容器\[[13][]\], 从而保证运行在里面的用户程序无法对外界系统造成破坏; 再在容器中创建一个enclave, 将用户程序、System Library和Shield module放进enclave中, 以防止这些数据和代码被外界的特权软件或恶意程序访问和篡改.System Library通过Downcalls和Upcalls的方式与Drawbridge主机进行交互, 用来完成用户程序需要的系统功能, Shield module模块配合检查函数的参数和返回的结果, 进而保护用户程序的安全执行\[[14][], [15][]\].

由于操作系统自身可能是不可信的, 因此方案中设计了一个System Library库, 用来将操作系统的系统调用进行封装, 并在应用程序运行时将其一起放到enclave中供应用程序使用, System Library自身实现了全部的系统调用.

为了保护用户程序和System Library的代码和数据不被enclave外的恶意软件攻击, 设计了Shield module, 该模块通过仔细地检查参数和函数调用的返回值来进行保护.Shield module自身包含了一些典型的内核函数:内存管理、进程调度、文件系统操作等.

3.2 基于SGX技术构建安全容器

基于容器的虚拟化现在越来越流行, 已经有不少的多租户环境开始使用容器来实现应用程序的性能隔离. Docker\[[16][]\]或者Kubernete\[[17][]\]提供的容器只需要占用较少的资源就能提供快速的启动和比由hypervisor监控的虚拟机提供更高的I/O性能.但是, 现有的容器隔离机制专注于保护其免受不可信容器的访问, 然而租户需要保护应用程序数据的机密性和完整性, 以防止未经授权的其他容器, 或更高级的系统软件(如操作系统内核和管理程序等)访问.这便需要有硬件机制能够保护用户级软件免受特权级系统软件的影响.Intel SGX的出现恰好满足这一需求.使用SGX来构建安全容器面临着两个挑战:(1)尽量减少enclave中可信计算基的大小; (2)尽量减少性能开销.

因此, 文献\[[18][http_www.jos.org.cn_html_2018_9_5594.htm_b18]\]提出了SCONE, 一种用于Docker的安全容器环境, 其利用Inter CPU提供的SGX机制来保护Docker容器内进程免受外部攻击.SCONE的设计主要实现了:

(1) 一个较小的可信计算基;

(2) 更低的性能消耗:SCONE提供了一个安全C语言静态库接口用于透明的加解密I/O数据; 降低了因线程同步和系统调用导致的高性能消耗; 支持用户级线程和异步系统调用.

通过实验评估表明:SCONE能够通过SGX保护未被修改的应用程序, 并实现0.6~1.2倍的吞吐量.

3.3 基于SGX构建云端大数据安全可信计算环境

MapReduce\[[19][]\]的出现有力推动了大数据技术和应用的发展, 使其成为目前大数据处理最成功的计算技术.由于大数据计算通常会租用公共计算设施, 如公有云, 因此, 如何在MapReduce计算过程中确保用户数据不被泄露, 解决大数据计算中数据的安全和隐私, 是目前亟需要解决的问题\[[20][], [21][]\].

目前, 对于大数据安全通常采用的是基于密码的保护机制, 如全同态加密机制、安全多方计算或零知识证明的机制, 然而这些方式目前都因受到性能的制约而没有大规模实用.另外一些方法, 如数据库加密机制, 如CtrptDB\[[22][]\]和Cipherbase\[[23][]\], 只能对数据库进行保护, 却不能保护计算中的代码和数据.基于此, 文献\[[19][]\]提出了基于SGX技术构建大数据安全可信计算环境, 确保数据在计算和存储中的安全.

该方案主要需解决以下3个关键问题.

(1) 利用SGX构建最小可信计算基

为增加方案的实用性, 本方法需要运行在未修改过的Hadoop上, 因此系统的可信计算基不包括Hadoop, OS和hypervisor.用户编写map和reduce代码, 并且将它们进行加密, 之后上传到云端.在每一个工作节点上, 云操作系统将这些代码加载进一个隔离的enclave中之后, enclave内的代码会执行密钥交换协议, 解密出map和reduce函数, 从而运行分布式计算处理用户数据.

(2) 保证整个分布式计算的完整性

SGX只能在本地计算节点上为程序和数据构建安全执行环境, 如何在分布式大数据处理过程中确保代码和数据的安全可信是需要解决的关键问题.本方案提出了一个高效的分布式作业执行协议来保证MapReduce作业的正确性和机密性.每个计算节点为正在运行的程序产生一个安全的摘要信息, 之后再将这些摘要进行收集整合, 通过验证最后结果中的最终摘要信息, 用户可以检查云服务提供商是否干扰了计算的执行.

(3) 保护用户程序免受非法内存访问攻击

SGX技术允许用户程序访问系统的全部地址空间, 因此, 不安全的内存访问可能会泄露数据或者带来其他的安全威胁.如何限制enclave内部程序的内存访问, 减轻由于应用程序本身的缺陷而导致其遭受非法内存访问攻击, 是需要解决的一个问题.该项目基于GCC开发了安全增强的编译器\[[24][]\], 在代码编译过程中增加额外参数, 将其地址空间限定在有效范围内, 从而有效地将需要保证完整性的代码放到一个独立的区域中, 并且对该区域中变量的读写访问都将进行检查.只有通过检查, 才能真正访问到用户数据.

3.4 基于SGX技术实现NFV的状态保护

网络功能虚拟化(network function virtualization, 简称NFV)通过软硬件解耦及功能抽象, 使网络设备功能不再依赖于专用硬件, 资源可以充分灵活共享, 实现新业务的快速开发和部署, 并基于实际业务需求进行自动部署、弹性伸缩、故障隔离和自愈等.NFV网元是有状态的\[[25][]\], 例如, 内容分发网络从远程服务器缓存浏览器内容并且把它们发送至客户端.类似地, 入侵检测系统和入侵防御系统都有逐流或者多流(共享)状态来应对入侵.在现今NFV的部署方式中, 攻击者可以通过访问共享的物理资源来窃取网络应用的状态信息.这篇文献中, 作者提出一种保护方案(S-NFV), 即是利用SGX对NFV产生的状态进行安全隔离保护.但该方案较简单, 仅在模拟环境OpenSGX中验证了保护Snort\[[26][]\]应用程序流状态安全的方案.

4 SGX的漏洞及防御4.1 SGX侧信道攻击4.1.1 威胁模型

侧信道攻击主要目标是攻击enclave数据的机密性.攻击者来自non-enclave部分, 包括应用程序和系统软件.系统软件包括OS, hypervisor, SMM(system management mode), BIOS等特权级软件.

侧信道攻击一般假设攻击者知道enclave初始化时候的代码和数据, 并且知道内存布局.内存布局包括虚拟地址、物理地址以及他们之间的映射关系.有些侧信道攻击假设攻击者知道enclave的输入数据, 并且可以反复触发enclave, 进行多次观察记录.侧信道攻击还假设攻击者知道运行enclave平台的硬件配置、特性和性能, 比如CPU、TLB(translation lookaside buffer)、Cache、DRAM、页表、中断以及异常等各种系统底层机制.

4.1.2 侧信道的攻击面

Enclave和non-enclave共享大量的系统资源, 这就给侧信道攻击留下了非常大的攻击面.经过对现有资料的总结和系统结构的分析, 我们把SGX的攻击面总结在[图 7][7 1]里面.

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;"><img alt="" src="http://www.jos.org.cn/html/2018/9/PIC/rjxb-29-9-2778-7.jpg" width="200"></td> 
   <td style="vertical-align:middle;">Fig. 7&nbsp;Attack surface of SGX side channel图 7&nbsp;Intel SGX侧信道的攻击面</td> 
  </tr> 
 </tbody> 
</table>

如[图 7][7 1]所示, enclave的运行过程中会用到:

(1) CPU内部结构.比如pipeline, BPB(branch prediction buffer)等等.这些结构不能够直接访问, 但是如果可以间接利用\[[27][]\], 仍然可能泄露enclave的控制流或数据流;

(2) TLB.TLB包括iTLB, dTLB和L2 TLB.如果Hyper-Threading打开, 两个逻辑核共享一个物理核, 这个时候会大大增加侧信道攻击的可能;

(3) Cache.Cache包括L1instructionCache, L1dataCache, L2Cache和L3Cache(又叫LLCCache);

(4) DRAM.DRAM包括channels, DIMMs(dual inline memory module), ranks, banks.每个banks又包括rows, columns和rowbuffer;

(5) 页表(page table).页表可以通过权限控制来触发缺页异常, 也可以通过页表的状态位来表明CPU的某些操作.

对于不同的攻击面, 攻击者需要了解具体的细节和工作原理, 其中比较重要的参考文档就是Intel的手册\[[28][], [29][]\].目前, SGX已经部署在SkyLake的机器上面.因此, 我们需要对SkyLake的一些硬件和性能细节重点掌握.文档\[[30][]\]对SkyLakei7-6700的一些CPU细节和性能做了一个比较全面的介绍和测量.

目前, 文献\[[31][]\]发现了Intel文档的一处描述和实际实验有冲突, 在这里需要重点说明一下.具体来讲, Intel CPU开发手册指出, SkyLake机器在打开Hyper-Threading之后的TLB的配置信息如[图 8][8 1]所示, 然而根据文献\[[31][]\]的实验, 这个Intel文档对于TLB partition的描述是不准确的.实验结果表明, iTLB是fixedpartition, 其他(dTLB和L2 TLB)都是dynamicpartition.

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;"><img alt="" src="http://www.jos.org.cn/html/2018/9/PIC/rjxb-29-9-2778-8.jpg" width="200"></td> 
   <td style="vertical-align:middle;">Fig. 8&nbsp;Configuration of TLB in SkyLake图 8&nbsp;SkyLake的TLB配置</td> 
  </tr> 
 </tbody> 
</table>

4.1.3 侧信道攻击

侧信道攻击的主要手段是通过攻击面获取数据, 推导获得控制流和数据流信息, 最终获取enclave的代码和数据的信息, 比如加密密钥、隐私数据等等.我们这里不一一列举具体的工作, 而是试图从攻击面的角度, 全面地介绍侧信道攻击.本节下面的内容就从典型的攻击面, 包括页表、TLB、Cache、DRAM以及CPU内部结构, 描述目前已知的侧信道攻击.

4.1.3.1 基于页表的攻击

最早的SGX侧信道攻击就是基于页表的攻击\[[32][], [33][]\], 这类利用页表对enclave页面的访问控制权, 设置enclave页面为不可访问.这个时候任何访问都会触发缺页异常, 从而能够区分enclave访问了哪些页面.按照时间顺序把这些信息组合, 就能够反推出enclave的某些状态和保护的数据.该类典型的攻击包括controlled- channel攻击\[[32][]\]和pigeonhole攻击\[[33][]\].这类攻击的缺点就是精度只能达到页粒度, 无法区分更细粒度的信息.但是在某些场景下, 这类攻击已经能够获得大量有用信息.例如[图 9][9 1]所示, 这类基于页表的侧信道攻击可以获得libjpeg处理的图片信息.经过还原, 基本上达到人眼识别的程度.pigeonhole攻击也展示了大量对现有的安全库的攻击, 如[图 10][10 1]所示.

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;"><img alt="" src="http://www.jos.org.cn/html/2018/9/PIC/rjxb-29-9-2778-9.jpg" width="200"></td> 
   <td style="vertical-align:middle;">Fig. 9&nbsp;Attack effect of Controlled-channel attack to libjepg图 9&nbsp;Controlled-channel攻击对libjpeg的攻击效果</td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;"><img alt="" src="http://www.jos.org.cn/html/2018/9/PIC/rjxb-29-9-2778-10.jpg" width="200"></td> 
   <td style="vertical-align:middle;">Fig. 10&nbsp;Attack effect of Pigeonhole attack to the security library图 10&nbsp;Pigeonhole攻击对安全库的攻击效果</td> 
  </tr> 
 </tbody> 
</table>

后来, 基于页表的攻击有了新的变种.这些侧信道攻击主要利用页表的状态位\[[31][]\].如[图 11][11 1]所示, 一个页表项有很多位, 有些是用来做访问控制, 比如P, RW, US, XD; 有些则标识状态, 比如D(dirtybit)和A(accessbit).如果Abit被设置, 则表明该页表指向的页面已经被访问; 如果D bit被设置, 则表明该页表指向的页面发生了写操作.通过监控观察这些状态位, 攻击者就可以获取和controlled-channel/pigeonhole攻击类似的信息.

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;"><img alt="" src="http://www.jos.org.cn/html/2018/9/PIC/rjxb-29-9-2778-11.jpg" width="200"></td> 
   <td style="vertical-align:middle;">Fig. 11&nbsp;Typical format of PTE图 11&nbsp;典型的页表项的格式(x64系统)</td> 
  </tr> 
 </tbody> 
</table>

4.1.3.2 基于TLB的攻击

目前还没有完全基于TLB的攻击, 但是已经出现TLB作为辅助手段的侧信道攻击, 我们会在混合侧信道攻击的章节(第4.1.3.6节)里面介绍.关于TLB的两点重要信息, 我们需要了解, 希望对提出新的基于TLB的侧信道攻击和防御有所帮助.

(1) TLB的层次结构.目前, SkyLake的机器分为L1和L2两层, 不同层次出现TLB miss的时间代价不同;

(2) TLB对代码和数据的区分.L1区分代码(iTLB)和数据(dTLB), 两者直接有Cachecoherence的保证; .L2不区分代码和数据.

4.1.3.3 基于Cache的攻击

传统侧信道有很多基于Cache的攻击\[[34][]\-[38][]\].在SGX的环境里面, 大部分侧信道技术仍然适用, 而且可以做得更好.原因在于:在SGX环境里面仅依赖CPU, 因此当操作系统, 甚至是BIOS都是恶意的情况下, 攻击者可以控制整个系统的资源.文献\[[39][]\]证明, SGX易受Cache-timing攻击.他们实现了一种基于Cache的Prime & Probe算法, 能够识别Cache行粒度上的enclave代码访问的内存位置, 并在相同的Hyper-threading核心上运行enclave和攻击线程, 使得攻击线程和enclave共享内存.通过这种方法, 能够在不到10秒的时间获得加密程序的AES密钥.但是另一方面, SGX能很好地防御利用Flush+ Reload的Cache攻击.因为EPC页面一次只属于一个enclave, 这就导致攻击者和enclave程序不能共享代码, 也就使得Flush+Reload变得不可能.

在攻击者能控制整个系统资源的情况下, 可以有针对地调度资源, 减少侧信道的噪音, 增加侧信道的成功率.降低噪音的策略大体可以有一下几种\[[39][]\-[42][]\].

(1) 核隔离(coreIsolation).这个方法的主要目标就是让enclave独自占有一个核(不允许其他程序运行在该核上面);

(2) 缓存隔离(cacheIsolation).尽量使用L1或者L2级别的Cache进行侧信道攻击.L3的Cache被所有的核共用, 会引入不必要的噪音;

(3) 不间断运行(uninterrupted execution).也就是不触发或尽量少触发AEX(asynchronous enclave exit), 因为AEX和后续的ISR(interrupt service routines)都会使用Cache, 从而引入不必要噪音.少触发AEX就是要使用中断绑定(interruptaffinity)和时钟频率; 不触发AEX基本上就是让系统软件(比如OS)屏蔽所有中断.

除了降低噪音, 攻击者还可以提高攻击的精度, 大体策略有:

(1) 高精度时钟.可以采用APIC(advanced programmable interrupt controller)提供的高精度时钟和硬件TSC(time stamp counter);

(2) 放大时间差异.比如, 攻击者可以配置侧信道攻击代码所在的CPU以最高频率运行, 而对enclave所在的CPU进行降频处理.

基于Cache的侧信道攻击可以进行细粒度的监控.最小粒度可以做到一个Cacheline, 即64个字节.由于粒度更小, 基于Cache的侧信道可以比基于页表的侧信道以及后面介绍的基于DRAM的侧信道获得更多的信息.

4.1.3.4 基于DRAM的攻击

在讲解基于DRAM的侧信道之前, 我们首先了解一些DRAM的基本知识.DRAM一般由channel, DIMM, rank, bank等部分构成, 如[图 12][12 1]所示.每个bank又由columns和rows组成, 并且还有一个rowbuffer用来缓存最近访问过的一个row.在访问DRAM的时候, 如果访问地址已经被缓存在rowbuffer当中(情况*A*), 就直接从buffer里面读取; 否则, 需要把访问地址对应的整个row都加载到rowbuffer当中(情况*B*).当然, 如果rowbuffer之前缓存了其他row的内容, 还需要先换出rowbuffer的内容再加载新的row(情况*C*).*A*, *B*, *C*对应的3种情况, 访问速度依次递减(情况*A*最快, 情况*C*最慢).这样, 通过时间上的差异, 攻击者就可以了解当前访问的内存地址是否在rowbuffer里面以及是否有被换出.文献\[[42][]\]在侧信道攻击过程中用到了基于DRAM的侧信道信息.另外, 文献\[[43][]\]介绍了更多基于DRAM的攻击细节, 不过, 该文献不是在SGX环境下的攻击.

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;"><img alt="" src="http://www.jos.org.cn/html/2018/9/PIC/rjxb-29-9-2778-12.jpg" width="200"></td> 
   <td style="vertical-align:middle;">Fig. 12&nbsp;Typical format of DRAM图 12&nbsp;典型的DRAM的格式</td> 
  </tr> 
 </tbody> 
</table>

基于DRAM的侧信道攻击有一些不足\[[31][]\].

●  enclave使用的内存通常都在缓存里面, 只有少部分需要从DRAM里面去取;

●  DRAM的精度不够.例如, 一个页面(4KB)通常分布在4个DRAM row上面, 这样, 基于DRAM的侧信道攻击的精度就是1KB, 仅仅比基于页表的侧信道攻击好一些, 远远不及基于Cache的侧信道攻击的精度;

●  DRAM里面存在很难避免的噪音干扰.因为一个DRAM row被很多页面使用, 同时, 同一个bank不同row的数据读取也会对时间测量造成干扰, 使得误报时常发生.

4.1.3.5 基于CPU内部结构的攻击

CPU内部有大量的结构是在enclave和non-enclave之间共用的.这就给侧信道攻击提供了大量的攻击面素材.比如, 文献\[[27][]\]里面提出使用BPB来实现侧信道攻击.具体来讲, 在enclave和non-enclave切换的时候, BPB里面存留的跳转预测记录并没有被清除.这样使得non-enclave可以构造一个程序, 测试这些跳转预测记录.如果预测成功, 则执行时间较短; 反之, 如果预测失败, 则执行时间较长.通过时间上的差异, 攻击者就可以推测enclave之前运行的跳转分支, 进而获得enclave运行的控制流图.通过控制流图, 攻击者又可以进一步推测隐私数据, 比如加密密钥等.这个攻击的强大之处在于, 它几乎可以还原整个控制流.这样细粒度的信息使得该攻击可以泄露很多信息.该文献也进行了大量实验, 充分展示了这个攻击的强大.实验表明, 这个攻击可以泄露字符串信息、RSA私钥以及网络数据等等.

目前, 对以CPU内部结构为攻击面的工作才刚刚开始, 仅仅有一个工作发表.相信通过进一步研究, 还会有其他的攻击面被陆续发掘.

从设计上来讲, SGX可以避免这类侧信道攻击.具体来讲, 在enclave到non-enclave的切换过程中, CPU清除这些共用的内部结构体.这样, non-enclave就不会得到任何残留的记录.但在具体实现的时候还要注意一些细节, 比如清除的时间也必须是稳定不变的.如果enclave运行的差异会导致清除操作的时间差异, 攻击者很可能据此推导出enclave的某些运行状态.

4.1.3.6 混合侧信道攻击

混合侧信道攻击是同时采集多个侧信道攻击面的信息, 或通过多个攻击面共同作用放大差异增加准确度.比较典型的做法包括:

(1) TLB和页表混合攻击.比如TLB miss的时候会加载页表, 这个时候CPU会设置页表的Accessbit.文献\[[31][]\]就在Hyper-Threading的情况下触发大量的TLB miss, 再通过观察页表的A bit进行侧信道攻击;

(2) Cache和DRAM混合攻击.基于DRAM的攻击只能精确到row(一个row通常8KB)的粒度.为了增强这类攻击的效果, 文献\[[31][]\]提出了这个Cache-DRAM攻击来增加空间精度, 把精度提高到了一个Cacheline(64B).

除了结合两个攻击面的侧信道攻击, 还可以采用多个攻击面相结合的侧信道攻击.这类混合攻击目前在SGX的环境下还没有看到相关工作.不过, 之前CCS’16的文献\[[44][]\]使用了3个攻击面(i.e., TLB、页表和Cache)的混合.我们相信, 类似的攻击也可以在SGX的环境下使用.

4.1.4 未来可能的侧信道攻击

未来, 新的侧信道攻击可能来自两个方面.

●  第一就是发掘新的混合侧信道攻击.前面列出的经典的混合侧信道攻击, 他们往往是用两种攻击面信息.因此, 我们可以考虑多个攻击面结合的侧信道攻击.以往的混合侧信道攻击往往专注于内存管理和地址转换等方面, 新的侧信道攻击可以结合其他方面的信息, 进行一些新的尝试;

●   Enclave所有和non-enclave共享的资源都可能成为潜在的侧信道攻击面.因此, 发掘新的侧信道攻击的第2个途径就是发现新的共享资源, 比如未被发掘的CPU内部共享结构.这些新的共享资源可能来自一些新的硬件特性, 如Intel PT(processor trace), Intel TSX(transactional synchronization extensions), Intel MPX(memory protection extensions), Intel CAT(cache allocation technology)等等.

4.2 SGX侧信道防御

目前, 已经有很多文献给出了防御SGX侧信道攻击的方案, 有些只是大体的思路, 有些则已经有成型的设计和实现.我们在这里主要介绍防御的思路和方法, 不涉及设计和实现的细节.首先, 我们把这些方法涉及的层次分为源码级别、系统级别和硬件级别.

4.2.1 源码层次的解决方案

这类方法的主要思想就是通过修改源码, 编写出能够防御侧信道的代码实现.这里的核心思想就是隐藏控制流和数据流.

这类方法的探索已经在一些密码算法中有所涉及, 比如利用exponentblinding\[[45][]\]来增强RSA算法, 利用bitslicing增强DES和AES算法\[[46][], [47][]\].在机器学习领域, 也有人做了尝试.ObliviousML\[[48][]\]修改了机器学习的算法, 使用obliviousassignmentsandcomparisons来隐藏控制流, 使用obliviousarrayaccess(即*k*\-anonymity)来隐藏数据流.文献Raccoon\[[49][]\]也采用了类似的方法, 使用obliviousstore隐藏if-else控制流, 使用ORAM(oblivious random access memory)来隐藏数据流, 从而抵御侧信道攻击.但是目前, 这些技术还很难在一个通用的计算环境下实现, 比如looptripcount, longjump以及break等问题.

4.2.2 系统层次的解决方案

系统层次的解决方案主要是利用一些系统特性来防御或检测SGX侧信道攻击.这里有几个思路可以参考.

(1) 随机化技术(randomization).随机化技术可以应用在控制流和数据流上面, 这将大大增加侧信道攻击的代价.防御效果与随机化粒度以及随机化频率有关;

(2) 检测可疑异常和中断.T-SGX\[[50][]\]利用TSX技术来检测中断和缺页异常, 从而抵御最原始的controlled- channel攻击\[[32][]\].但是现在已经出现不需要触发AEX的侧信道攻击;

(3) 检测时间异常.目前, Déjá Vu系统\[[51][]\]也使用了TSX技术来保护enclave自己的时钟.如果攻击者中断或减缓enclave的运行, enclave就可以通过自己的时钟检测出时间上的异常.目前, 绝大多数侧信道攻击都会引起enclave的显著性能下降.因此, 检测时间异常还是一个比较有效的方案;

(4) Cache隔离.目前, Intel推出了CAT技术, 允许对Cache进行粗粒度的隔离.这个技术已经被使用在云计算平台上面\[[52][]\]防御侧信道攻击, 但是还没有看到在SGX环境里面的应用.把CAT应用到SGX的一个很大的障碍是enclave在用户空间无法有效地检测或验证CAT的配置.

4.2.3 硬件层次的解决方案

硬件层次的解决方案还处于探索阶段.加入侧信道防御, 将会显著增加硬件复杂度, 影响功耗和性能.这也可能是Intel在最初推出SGX的时候没有加入侧信道防御的一个原因.硬件解决方案可能有以下两种.

(1) 硬件分割(partition).类似于ARM里面的TrustZone, 有自己的Cache, memory等一系列硬件资源, 物理上与non-enclave分离;

(2) 硬件隔离(isolation).类似于Intel CAT技术, 可以单独为每一个enclave提供一个动态隔离出的Cache.当enclave销毁的时候, 隔离出的Cache可以被收回.这里一个很重要的要求就是, enclave必须可以验证这个功能的有效性.

Sanctum\[[53][]\]已经做了一些尝试, 但是还不够彻底, 还会遭受攻击\[[41][]\].

4.3 SGX程序机密性问题

在文献\[[54][]\]中, 作者基于自动定理证明和信息流分析, 提出了一套SGX的使用规范, 设计了Moat这一检测工具, 通过在汇编语言层面对程序进行分析, 从而检测应用程序是否存在泄露SGX区域中秘密信息的可能.

4.4 SGX多线程同步漏洞

在文献\[[55][]\]中, 展示了在使用SGX后以往被视为无害的同步漏洞可能会变为严重的安全漏洞.通过在enclave代码中利用UAF(use-after-free)和TOCTTOU(time-of-check-to-time-of-use)漏洞, 一个攻击者可以劫持它的控制流或者绕过访问控制\[[56][], [57][]\].

文献\[[55][]\]提出AsyncShock, 一个利用运行于SGX的多线程代码的同步漏洞的工具.AsyncShock只能通过操作用于执行enclave代码的线程调度来达到这一的目标.它允许一个攻击者通过在enclave页强制分割错误来中断线程.

5 SGX技术的挑战与展望5.1 SGX与其他相关技术对比分析5.1.1 TPM/TCM

TPM/TCM提供度量、签名、加解密、密封等功能, 其主要用于系统和应用程序的静态完整性度量, 无法确保运行态的安全.SGX除了提供程序加载时的完整性验证外, 还保证程序运行时安全, 缓解针对程序运行时的攻击\[[58][]\-[60][]\].

5.1.2 Intel TXT

Intel TXT\[[61][]\]基于TPM动态可信度量根, 通过一组安全扩展, 为系统创建一个被保护的环境, 其在设计时缺乏对SMM的考虑导致可被绕过, 而SMM恶意代码无法绕过SGX硬件保护机制去访问受保护的模块.

5.1.3 硬件虚拟化

Intel VT/AMD SVM硬件虚拟化技术提供操作系统级别的隔离环境, SGX则针对用户空间提供程序粒度的隔离.虚拟化技术通过特权分级制度保证隔离, 其安全性依赖于特权软件的安全性, 若VMM出现安全漏洞, 平台的安全性将难以保证.而SGX提供硬件隔离的执行环境, 不依赖于固件和特权软件的安全性, 特权软件也无法访问普通程序被保护的内存\[[62][], [63][]\].

5.1.4 TrustZone技术

TrustZone技术是由ARM公司提出的嵌入式平台安全技术, 在尽量不影响原有处理器设计的情况下, 通过物理隔离保护安全内存、加密块、键盘和显示器等外设.其将系统的硬件和软件资源划分为两个执行环境——安全环境(secure world)和普通环境(normal world)\[[64][]\].每个执行环境都有自己的系统软件和应用软件、内存区及外围设备.通过TrustZone的硬件逻辑, 建立一个隔离的TEE为安全敏感应用提供安全服务, 使得安全环境的资源不能被普通环境的组件访问, 将其与普通环境隔离开来.TrustZone技术已经得到广泛的研究与应用:文献\[[65][]\]介绍了利用TrustZone构建移动平台TEE的方法; 文献\[[66][]\]利用TrustZone技术提供的代码隔离技术可以实现可信白名单, 确保目标设备只能执行符合白名单策略的授权代码; 文献\[[67][]\]设计了对移动嵌入式内核完整性保护方案, 保障内核的可信性.TrustZone与可信计算技术相结合方面也已经有不少的研究成果:文献\[[68][], [69][]\]基于TrustZone中实现了符合TPM规范的应用于移动平台的DAA(direct anonymous attestation)协议, 为移动平台的安全应用提供快速有效的匿名身份认证服务; 文献\[[70][]\]提出一套可信操作的TEEM方案, 利用TrustZone技术实现了TPM1.2模拟器的安全隔离, 保障了可信操作的安全性.在实际应用中, 苹果、华为和三星等公司也基于TrustZone开发了指纹识别和安全支付等应用.

TrustZone和SGX的不同之处在于:TrustZone中, 通过CPU将系统划分为两个隔离环境, 两者之间通过SMC指令通信, 一旦Secure world中存在恶意程序, 那么将危害整个系统的安全; 而SGX中, 一个CPU可以运行多个安全enclaves, 并发执行, 即使某个enclave中存在恶意程序, 它也不能访问和危害其他enclave的被保护内容.

5.2 SGX技术的优势与不足5.2.1 优势

与现有的几种硬件安全技术相比, Intel SGX主要有3大优势:一是通过内存加密技术保护程序运行态的安全, 使得通过内存泄漏攻击获取关键信息的难度增大; 二是将系统的可信计算基缩小到CPU, 相比以往将整个操作系统或特权软件(如hypervisor等)视为可信计算基, 可以避免更多的系统攻击带来的危害; 三是支持虚拟化技术、容器技术, 可用性更强.

5.2.2 SGX的不足之处

(1) 由于enclave处于用户态, 其自身无法执行系统调用, 需要与不可信区域进行交互(运行库的支持有限, 接口的安全性).在执行系统调用前需要退出enclave, 执行完成后将结果返回到enclave中, 增大了安全风险和系统开销;

(2) Enclave中的数据和处理过程, 如果依赖于外部数据, 则存在一定的安全隐患.例如:通过一些不合法输入, 可以发起对可信区的缓冲区溢出攻击, 这些攻击可能会改变可信区中程序的执行流程、获取可信区中的敏感信息;

(3) SGX本身无法抵御侧信道攻击;

(4) SGX提供的enclave可使用内存太小, 当程序数量和规模增大时, 需要换进换出页面.为了保证安全性, 需要对页面进行完整性和机密性保障, 导致系统开销大;

(5) 使用SGX提供的enclave时需要对程序进行改造, 当程序规模大时, 带来的编程成本高.

5.3 SGX研究和应用需求展望

自2013年Intel推出SGX技术以来, SGX技术便受到了学术界和工业界的极大关注.目前, 除SGX自身安全问题研究外, SGX技术已经被学术界和工业界应用到了很多领域.第3节中我们介绍了目前SGX在云计算安全相关领域的研究工作, 此外, SGX已经被用于构建可信的身份认证环境\[[71][]\]、可信的网络通信通道\[[72][]\]、可信的系统审计\[[73][]\]、高效安全的密文计算机制\[[74][]\]、保护AI程序和数据安全\[[75][]\]等方面.基于以上研究进展, 我们提出了SGX在云计算相关研究领域的进一步应用需求和研究方向.

5.3.1 可信计算与SGX技术的结合

目前, 可信云主要依赖于在服务器中部署TPM\[[76][], [77][]\], 利用它的信任链以及完整性度量技术, 保障平台的可信启动、操作系统可信、虚拟机可信等.但这种保护是静态的, TPM无法动态保护系统内存中的密钥等隐私数据的安全.SGX技术可以对软件运行时的环境进行硬件隔离, 安全系数高, 将其应用于可信环境构建中, 与可信计算技术\[[78][]\]相结合, 可以保障可信应用运行时的安全性.然而, 如何将TPM与SGX技术进行结合, 从而构建更安全的可信计算环境, 是目前需要进一步研究的问题.

5.3.2 利用SGX技术构建可信云安全环境

随着云计算的兴起与发展, 虚拟化技术得到了广泛的研究与应用.虚拟化技术为云平台实现资源抽象、隔离以及资源的按需分配提供技术支撑.在云虚拟化架构中, 虚拟机是系统资源虚拟化的直观体现, 也与云用户密切相关.

目前, 一些研究工作将可信计算和虚拟化技术相结合, 提出了虚拟可信平台模块的概念, 它通过模拟硬件TPM的功能为每个虚拟机分配一个vTPM设备\[[79][], [80][]\], 进而为虚拟机提供可信计算服务\[[81][]\-[83][]\].然而这种安全更多关注的是虚拟机的静态安全, 对于虚拟机内应用程序的动态安全却无法通过这种方案得到根本保证; 同时, 虚拟机动态迁移是构建可靠的云平台的重要需求之一\[[84][]\-[88][]\].通过动态迁移技术, 可以将虚拟机从负载过高的主机迁移到负载较小的主机, 以实现负载均衡; 当某一主机出现问题时, 可以通过迁移将该主机的虚拟机迁移至其他主机, 保障虚拟化平台的安全可靠.以前对于虚拟机动态迁移的研究大都集中在提升性能方面, 主流的虚拟化平台包括Xen\[[89][]\], KVM\[[90][]\]都有适用于自身平台的完善的动态迁移技术, 但是随着网络空间安全的日益严峻\[[91][]\], 虚拟机迁移的安全问题也开始受到人们的重视.

因此, 如何结合Intel SGX技术构建可信云执行环境, 实现虚拟机的可信启动、可信执行、虚拟可信根的安全保护以及虚拟机及其虚拟可信根的安全迁移, 是未来一个值得研究的方向.

5.3.3 利用SGX技术构建虚拟网元可信执行环境

在云虚拟网络中, 网络功能主要不再仅以硬件的方式出现, 取而代之的是数量众多并且可复用的虚拟网元(virtual network function, 简称VNF).然而, 如何保护这些虚拟网元自身的安全, 是云虚拟网络安全面临的一个难题.SGX为这一问题的解决提供了硬件基础.

基于上述SGX技术在云环境中应用的构想, 如[图 13][13 1], 可以构建基于SGX的虚拟网元可信执行环境构建方案.通过SGX技术为虚拟网络功能构建安全可信的执行环境.主要的思路是:将虚拟网络功能中涉及安全隐私的主要代码和数据, 如密码操作、安全策略等放到enclave中执行和加密保护; 同时, 基于SGX对虚拟网元进行身份认证、授权和网络通信监管, 构建达到与单独隔离硬件接近的安全执行环境.

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;"><img alt="" src="http://www.jos.org.cn/html/2018/9/PIC/rjxb-29-9-2778-13.jpg" width="200"></td> 
   <td style="vertical-align:middle;">Fig. 13&nbsp;Protected cloud architectures of NFV based on the SGX图 13&nbsp;基于SGX的NFV保护云环境架构</td> 
  </tr> 
 </tbody> 
</table>

5.3.4 利用SGX技术构建面向云的可信外包计算

外包计算的安全与隐私, 是近几年来的研究热点问题.通过将计算外包到云中, 一个计算能力有限的用户可以利用云计算强大的计算能力实现更高效更快捷的计算服务.然而, 如何保护外包数据和计算过程的安全与隐私, 是目前需要解决的问题.传统的方式是利用密文检索等方法, 在保护数据隐私的同时实现安全的计算.然而密文检索目前只能在密文数据上实现简单的计算, 此外, 性能目前仍然是制约密文检索技术被应用的瓶颈.SGX为保护外包计算的安全与隐私提供了一条新的途径.目前, 该方面的研究工作刚刚起步\[[75][]\], 如何基于SGX构建可信的外包计算环境, 解决多方授权的外包计算安全, 以及针对具体应用构建可实用的安全外包计算服务, 实现外包计算中数据安全隐私保护, 是目前需要进一步研究的问题.

5.3.5 SGX与ORAM的结合

云计算中, 用户的数据访问模式可以泄露用户的隐私.为解决这一问题, 目前, 研究者利用不经意随机存取(ORAM)保护云平台中用户数据访问模式的隐私.然而, 目前ORAM方案效率较低, 无法实际应用.SGX拥有较小的可信基, 同时具有较高的性能和安全性.如何结合SGX和各种ORAM机制\[[92][]\], 例如Path ORAM和Circuit ORAM, 实现更安全的用户数据访问模式隐私保护, 是值得关注和研究的问题.

6 结束语

本文对SGX的技术原理、侧信道攻击以及在云安全领域的应用和未来研究方向进行了深入分析和总结.首先介绍了该技术的基础架构, 并且对其安全框架进行了详细分析; 接着, 深入剖析了其技术原理, 同时, 针对SGX自身安全, 深入讨论了SGX侧信道攻击及其防御; 此外, 文中也将该技术与其他可信计算技术进行了分析对比, 在此基础上, 指出了SGX技术自身的优势和不足, 并进一步介绍了SGX在云计算安全相关领域的应用; 最后, 本文提出SGX在云安全相关领域的未来应用需求和研究方向.

**参考文献**

<table> 
 <tbody> 
  <tr> 
   <td>[1]</td> 
   <td> <p>Wang JW, Jiang Y, Li Q, Yang Y. Survey of research on SGX technology application. Journal of Network New Media, 2017, 6(5): 3–9(in Chinese with English abstract). [<a href="http://dx.doi.org/10.3969/j.issn.2095-347X.2017.05.002" rel="nofollow">doi:10.3969/j.issn.2095-347X.2017.05.002</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[2]</td> 
   <td> <p>Intel Corporation. Intel® software guard extensions programming reference. Rev. 2. 2014. Ref. #329298-002.</p> </td> 
  </tr> 
  <tr> 
   <td>[3]</td> 
   <td> <p>Shaun D, Richard F. SGX: The good, the bad and the downright ugly. 2014.</p> </td> 
  </tr> 
  <tr> 
   <td>[4]</td> 
   <td> <p>Intel Corporation. Intel® SGX for dummies (Intel® SGX design objectives). 2013.&nbsp;<a href="https://software.intel.com/en-us/blogs/2013/09/26/protecting-application-secrets-with-intel-sgx" rel="nofollow">https://software.intel.com/en-us/blogs/2013/09/26/protecting-application-secrets-with-intel-sgx</a></p> </td> 
  </tr> 
  <tr> 
   <td>[5]</td> 
   <td> <p>Intel Corporation. Intel® SGX for dummies-Part 2. 2014.&nbsp;<a href="https://software.intel.com/en-us/blogs/2014/06/02/intel-sgx-fordummies-part-2" rel="nofollow">https://software.intel.com/en-us/blogs/2014/06/02/intel-sgx-fordummies-part-2</a></p> </td> 
  </tr> 
  <tr> 
   <td>[6]</td> 
   <td> <p>Intel Corporation. Intel® SGX for dummies-Part 3. 2014.&nbsp;<a href="https://software.intel.com/en-us/blogs/2014/09/01/intel-sgx-fordummies-part-3" rel="nofollow">https://software.intel.com/en-us/blogs/2014/09/01/intel-sgx-fordummies-part-3</a></p> </td> 
  </tr> 
  <tr> 
   <td>[7]</td> 
   <td> <p>Prof. Dr. -Ing. Sadeghi AR. Trusted Execution Environments Intel SGX. Germany: Technische Universität Darmstadt (CASED).</p> </td> 
  </tr> 
  <tr> 
   <td>[8]</td> 
   <td> <p>Intel Corporation. Intel® software guard extensions (Intel® SGX). Intel Labs., 2013.&nbsp;<a href="https://software.intel.com/sgx" rel="nofollow">https://software.intel.com/sgx</a></p> </td> 
  </tr> 
  <tr> 
   <td>[9]</td> 
   <td> <p>Intel Corporation. Intel® software guard extensions (Intel® SGX) SDK for Linux*&nbsp;OS., 2017.</p> </td> 
  </tr> 
  <tr> 
   <td>[10]</td> 
   <td> <p>Rich M. Intel software guard extensions (SGX) is mighty interesting. 2013.&nbsp;<a href="https://securosis.com/blog/intel-software-guardextensions-sgx-is-mighty-interesting" rel="nofollow">https://securosis.com/blog/intel-software-guardextensions-sgx-is-mighty-interesting</a></p> </td> 
  </tr> 
  <tr> 
   <td>[11]</td> 
   <td> <p>Baumann A, Peinado M, Hunt G. Shielding applications from an untrusted cloud with haven. ACM Trans. on Computer Systems, 2015, 33(3): 1–26.&nbsp;<a href="http://cn.bing.com/academic/profile?id=04c657304bab7c72baef3b5f37f32519&amp;encoded=0&amp;v=paper_preview&amp;mkt=zh-cn" rel="nofollow">http://cn.bing.com/academic/profile?id=04c657304bab7c72baef3b5f37f32519&amp;encoded=0&amp;v=paper_preview&amp;mkt=zh-cn</a></p> </td> 
  </tr> 
  <tr> 
   <td>[12]</td> 
   <td> <p>Porter DE, Boyd-Wickizer S, Howell J, Olinsky R, Hunt GC. Rethinking the library OS from the top down. ACM Sigplan Notices, 2011, 46(3): 291–304. [<a href="http://dx.doi.org/10.1145/1961296" rel="nofollow">doi:10.1145/1961296</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[13]</td> 
   <td> <p>Howell J, Parno B, Douceur JR. How to run POSIX apps in a minimal picoprocess. In: Proc. of the USENIX Conf. on Technical Conf. 2013. 321-332.</p> </td> 
  </tr> 
  <tr> 
   <td>[14]</td> 
   <td> <p>Baumann A, Lee D, Fonseca P, Glendenning L, Lorch JR, Bond B, Olinsky R, Hunt GC. Composing OS extensions safely and efficiently with bascule. In: Proc. of the 8th ACM European Conf. on Computer Systems. 2013. 239-252.</p> </td> 
  </tr> 
  <tr> 
   <td>[15]</td> 
   <td> <p>Tsai CC, Arora KS, Bandi N, Jain B, Jannen W, John J, Kalodner HA, Kulkarni V, Oliveira D, Porter DE. Cooperation and security isolation of library OSes for multi-process applications. In: Proc. of the 9th European Conf. on Computer Systems. 2014. 1-14.</p> </td> 
  </tr> 
  <tr> 
   <td>[16]</td> 
   <td> <p>Merkel D. Docker:Lightweight Linux containers for consistent development and deployment. Linux Journal, 2014: 239.<a href="http://d.old.wanfangdata.com.cn/Periodical/ranj201411015" rel="nofollow">http://d.old.wanfangdata.com.cn/Periodical/ranj201411015</a></p> </td> 
  </tr> 
  <tr> 
   <td>[17]</td> 
   <td> <p>Bernstein D. Containers and cloud:From LXC to docker to kubernetes. IEEE Cloud Computing, 2014, 1(3): 81–84. [<a href="http://dx.doi.org/10.1109/MCC.2014.51" rel="nofollow">doi:10.1109/MCC.2014.51</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[18]</td> 
   <td> <p>Arnautov S, Trach B, Gregor F, Knauth T, Martin A, Priebe C, Lind J, Muthukumuran D, O'Keeffe D, Stillwell M, Goltzche D, Eyers D, Kapitza R, Pietzuch P, Fetzer C. SCONE: Secure Linux containers with Intel SGX. In: Proc. of the 12th USENIX Symp. on Operating Systems Design and Implementation (OSDI). 2016</p> </td> 
  </tr> 
  <tr> 
   <td>[19]</td> 
   <td> <p>Schuster F, Costa M, Fournet C, Gkantsidis C. VC3: Trustworthy data analytics in the cloud using SGX. In: Proc. of the Security and Privacy. IEEE, 2015. 38-54.</p> </td> 
  </tr> 
  <tr> 
   <td>[20]</td> 
   <td> <p>Dean J, Ghemawat S. Mapreduce:Simplified data processing on large clusters. Communications of the ACM, 2008, 51(1): 107–113. [<a href="http://dx.doi.org/10.1145/1327452" rel="nofollow">doi:10.1145/1327452</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[21]</td> 
   <td> <p>Dill S, Kumar R, Mccurley KS, Rajagopalan S, Sivakumar D, Tomkins A. Self-Similarity in the Web. ACM Trans. on Internet Technology (TOIT), 2002, 2(3): 205–223. [<a href="http://dx.doi.org/10.1145/572326.572328" rel="nofollow">doi:10.1145/572326.572328</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[22]</td> 
   <td> <p>Popa RA, Redfield CMS, Zeldovich N, Balakrishnan H. CryptDB: Protecting confidentiality with encrypted query processing. In: Proc. of the ACM Symp. on Operating Systems Principles 2011(SOSP 2011). Cascais, 2011. 85-100.</p> </td> 
  </tr> 
  <tr> 
   <td>[23]</td> 
   <td> <p>Arasu A, Blanas S, Eguro K, Kaushik R, Kossmann D, Ramamurthy R, Venkatesan R. Orthogonal security with cipherbase. In: Proc. of the Cidr. Asilomar, 2015.</p> </td> 
  </tr> 
  <tr> 
   <td>[24]</td> 
   <td> <p>Nagarakatte S, Zhao JZ, Martin MMK, Zdancewic S. CETS:Compiler-enforced temporal safety for C. ACM SIGPLAN Notices, 2010, 45(8): 31–40.&nbsp;<a href="http://d.old.wanfangdata.com.cn/Periodical/xdyjljy200706019" rel="nofollow">http://d.old.wanfangdata.com.cn/Periodical/xdyjljy200706019</a></p> </td> 
  </tr> 
  <tr> 
   <td>[25]</td> 
   <td> <p>Shih MW, Kumar M, Kim T, Gavrilovska A. S-NFV: Securing NFV states by using SGX. In: Proc. of the 2016 ACM Int'l Workshop on Security in Software Defined Networks &amp; Network Function Virtualization. 2016. 45-48.</p> </td> 
  </tr> 
  <tr> 
   <td>[26]</td> 
   <td> <p>Roesch M. Snort-lightweight intrusion detection for networks. In: Proc. of the 13th USENIX Conf. on System Administration (LISA'99). 1999. 229-238.</p> </td> 
  </tr> 
  <tr> 
   <td>[27]</td> 
   <td> <p>Lee S, Shih MW, Gera P, Kim T, Kim H, Peinado M. Inferring fine-grained control flow inside SGX enclaves with branch shadowing. In: Proc. of the 26th USENIX Security Symp. 2016.</p> </td> 
  </tr> 
  <tr> 
   <td>[28]</td> 
   <td> <p>Intel Corporation. Intel x64 and ia-32 architectures optimization reference manual. 2016.</p> </td> 
  </tr> 
  <tr> 
   <td>[29]</td> 
   <td> <p>Intel Corporation. Intel 64 and IA-32 architectures software developer's manual combined volumes: 1, 2a, 2b, 2c, 2d, 3a, 3b, 3c, 3d and 4. 2017.</p> </td> 
  </tr> 
  <tr> 
   <td>[30]</td> 
   <td> <p>7-Zip LZMA benchmark. Intel skylake benchmark.&nbsp;<a href="https://www.7-cpu.com/" rel="nofollow">https://www.7-cpu.com</a></p> </td> 
  </tr> 
  <tr> 
   <td>[31]</td> 
   <td> <p>Wang WH, Chen GX, Pan XR, Zhang YQ, Wang XF, Bindschaedler V, Tang HX, Gunter CA. Leaky cauldron on the dark land: Understanding memory side-channel hazards in SGX. In: Proc. of the 2017 ACM SIGSAC Conf. on Computer and Communications Security (CCS 2017). 2017. 2421-2434.</p> </td> 
  </tr> 
  <tr> 
   <td>[32]</td> 
   <td> <p>Xu YZ, Cui WD, Peinado M. Controlled-Channel attacks: Deterministic side channels for untrusted operating systems. In: Proc. of the 2015 IEEE Symp. on Security and Privacy (SP 2015). 2015. 640-656.</p> </td> 
  </tr> 
  <tr> 
   <td>[33]</td> 
   <td> <p>Shinde S, Chua ZL, Narayanan V, Saxena P. Preventing page faults from telling your secrets. In: Proc. of the 11th ACM on Asia Conf. on Computer and Communications Security (ASIA CCS 2016). 2016. 317-328.</p> </td> 
  </tr> 
  <tr> 
   <td>[34]</td> 
   <td> <p>Liu FF, Yarom Y, Ge Q, Heiser G, Lee RB. Last-Level cache side-channel attacks are practical. In: Proc. of the IEEE Symp. on Security and Privacy. IEEE Computer Society, 2015. 605-622.</p> </td> 
  </tr> 
  <tr> 
   <td>[35]</td> 
   <td> <p>Yarom Y, Falkner K. FLUSH+RELOAD: A high resolution, low noise, L3 cache side-channel attack. In: Proc. of the 23rd USENIX Conf. on Security Symp. 2014. 719-732.</p> </td> 
  </tr> 
  <tr> 
   <td>[36]</td> 
   <td> <p>Lipp M, Gruss D, Spreitzer R, Maurice C, Mangard S. ARMageddon: Cache attacks on mobile devices. In: Proc. of the 25th USENIX Security Symp. (USENIX Security 2016). 2016. 549-564.</p> </td> 
  </tr> 
  <tr> 
   <td>[37]</td> 
   <td> <p>Gruss D, Maurice C, Wagner K, Mangard S. Flush+Flush: A fast and stealthy cache attack. In: Proc. of the 13th Conf. on Detection of Intrusions and Malware &amp; Vulnerability Assessment (DIMVA). 2016.</p> </td> 
  </tr> 
  <tr> 
   <td>[38]</td> 
   <td> <p>Gruss D, Spreitzer R, Mangard S. Cache template attacks: Automating attacks on inclusive last-level caches. In: Proc. of the 24th USENIX Conf. on Security Symp. 2015. 897-912.</p> </td> 
  </tr> 
  <tr> 
   <td>[39]</td> 
   <td> <p>Götzfried J, Eckert M, Schinzel S, Müller T. Cache attacks on Intel SGX. In: Proc. of the 10th European Workshop on Systems Security (EuroSec 2017). 2017. 1-6.</p> </td> 
  </tr> 
  <tr> 
   <td>[40]</td> 
   <td> <p>Moghimi A, Irazoqui G, Eisenbarth T. Cachezoom: How SGX amplifies the power of cache attacks. In: Proc. of the Conf. on Cryptographic Hadware and Embedded Systems (CHES 2017). 2017. 69-90.</p> </td> 
  </tr> 
  <tr> 
   <td>[41]</td> 
   <td> <p>Brasser F, Müller U, Dmitrienko A, Kostianinen K, Capkun S, Sadeghi AR. Software grand exposure: SGX cache attacks are practical. In: Proc. of the 11th USENIX Workshop on Offensive Technologies (WOOT 2017). 2017.</p> </td> 
  </tr> 
  <tr> 
   <td>[42]</td> 
   <td> <p>Schwarz M, Weiser S, Gruss D, Maurice C, Mangard S. Malware guard extension: Using SGX to conceal cache attacks. In: Proc. of the Detection of Instrusions and Malware, and Vulnerability Assessment. 2017. 3-24.</p> </td> 
  </tr> 
  <tr> 
   <td>[43]</td> 
   <td> <p>Pessl P, Gruss D, Maurice C, Schwarz M, Mangard S. DRAMA: Exploiting DRAM addressing for cross-CPU attacks. In: Proc. of the 25th USENIX Security Symp. 2016.</p> </td> 
  </tr> 
  <tr> 
   <td>[44]</td> 
   <td> <p>Gruss D, Maurice C, Fogh A, Lipp M, Mangard S. Prefetch side-channel attacks: Bypassing SMAP and kernel ASLR. In: Proc. of the 2016 ACM SIGSAC Conf. on Computer and Communications Security. 2016. 368-379.</p> </td> 
  </tr> 
  <tr> 
   <td>[45]</td> 
   <td> <p>Kocher PC. Timing attacks on implementations of diffie-hellman, RSA, DSS, and other systems. In: Proc. of the 16th Annual Int'l Cryptology Conf. on Advances in Cryptology. 1996. 104-113.</p> </td> 
  </tr> 
  <tr> 
   <td>[46]</td> 
   <td> <p>Biham E. A fast new DES Implementation in software. In: Proc. of the Int'l Workshop on Fast Software Encryption. 1997. 260-272.</p> </td> 
  </tr> 
  <tr> 
   <td>[47]</td> 
   <td> <p>Matsui M. How far can we go on the x64 processors? In: Proc. of the Int'l Workshop on Fast Software Encryption. 2006. 341-358.</p> </td> 
  </tr> 
  <tr> 
   <td>[48]</td> 
   <td> <p>Ohrimenko O, Schuster F, Fournet C, Mehta A, Nowozin S, Vaswani K, Costa M. Oblivious multi-party machine learning on trusted processors. In: Proc. of the 25th USENIX Security Symp. (USENIX Security 2016). 2016. 619-636.</p> </td> 
  </tr> 
  <tr> 
   <td>[49]</td> 
   <td> <p>Rane A, Lin C, Tiwari M. Raccoon: Closing digital side-channels through obfuscated execution. In: Proc. of the 24th USENIX Security Symp. (USENIX Security 2015). 2015. 431-446.</p> </td> 
  </tr> 
  <tr> 
   <td>[50]</td> 
   <td> <p>Shih MW, Lee S, Kim T, Peinado M. T-SGX: Eradicating controlled-channel attacks against enclave programs. In: Proc. of the 2017 Annual Network and Distributed System Security Symp. (NDSS). 2017.</p> </td> 
  </tr> 
  <tr> 
   <td>[51]</td> 
   <td> <p>Chen S, Zhang XK, Reiter MK, Zhang YQ. Detecting privileged side-channel attacks in shielded execution with Déjá Vu. In: Proc. of the 2017 ACM on Asia Conf. on Computer and Communications Security. 2017. 7-18.</p> </td> 
  </tr> 
  <tr> 
   <td>[52]</td> 
   <td> <p>Liu FF, Ge Q, Yarom Y, Mckeen F, Rozas C, Heiser G, Lee RB. CATalyst: Defeating last-level cache side channel attacks in cloud computing. In: Proc. of the 2016 IEEE Int'l Symp. on High Performance Computer Architecture (HPCA). 2016. 406-418.</p> </td> 
  </tr> 
  <tr> 
   <td>[53]</td> 
   <td> <p>Costan V, Lebedev I, Devadas S. Sanctum: Minimal hardware extensions for strong software isolation. In: Proc. of the 25th USENIX Security Symp. (USENIX Security 2016). 2016. 857-874.</p> </td> 
  </tr> 
  <tr> 
   <td>[54]</td> 
   <td> <p>Sinha R, Rajamani S, Seshia SA, Vaswani K. Moat: Verifying confidentiality of enclave programs. In: Proc. of the ACM SIGSAC Conf. on Computer and Communications Security. 2015. 1169-1184.</p> </td> 
  </tr> 
  <tr> 
   <td>[55]</td> 
   <td> <p>Weichbrodt N, Kurmus A, Pietzuch P, Kapitza R. AsyncShock: Exploiting synchronisation bugs in Intel SGX enclaves. In: Proc. of the Computer Security (ESORICS 2016). 2016. 440-457.</p> </td> 
  </tr> 
  <tr> 
   <td>[56]</td> 
   <td> <p>Savage S, Burrows M, Nelson G, Sobalvarro P, Anderson T. Eraser: A dynamic data race detector for multi-threaded programs. In: Proc. of the 16th ACM Symp. on Operating Systems Principles. 1997. 27-37.</p> </td> 
  </tr> 
  <tr> 
   <td>[57]</td> 
   <td> <p>Checkoway S, Shacham H. Iago attacks: Why the system call API is a bad untrusted RPC interface. In: Proc. of the Int'l Conf. on Architectural Support for Programming Languages and Operating Systems. 2013. 253-264.</p> </td> 
  </tr> 
  <tr> 
   <td>[58]</td> 
   <td> <p>GB/T 29827-2013. Information security technology-Trusted computing specification-motherboard function and interface of trusted platform. 2013(in Chinese with English abstract).</p> </td> 
  </tr> 
  <tr> 
   <td>[59]</td> 
   <td> <p>GB/T 29828-2013. Information security technology-Trusted computing specification-trusted connect architecture. 2013(in Chinese with English abstract).</p> </td> 
  </tr> 
  <tr> 
   <td>[60]</td> 
   <td> <p>GB/T 29829-2013. Information security techniques-Functionality and interface specification of cryptographic support platform for trusted computing. 2013(in Chinese with English abstract).</p> </td> 
  </tr> 
  <tr> 
   <td>[61]</td> 
   <td> <p>Intel Corporation. Intel Trusted Execution Technology:Hardware-Based Technology for Enhancing Server Platform Security. White Paper, 2012.</p> </td> 
  </tr> 
  <tr> 
   <td>[62]</td> 
   <td> <p>Shi L, Zou DQ, Jin H. Virtualization of Xen. Wuhan: Huazhong University of Science and Technology Press, 2009.</p> </td> 
  </tr> 
  <tr> 
   <td>[63]</td> 
   <td> <p>Sheng QN. Technology status and development trend of virtual trusted platform. Netinfo Security, 2010(4): 34–36(in Chinese with English abstract). [<a href="http://dx.doi.org/10.3969/j.issn.1671-1122.2010.04.014" rel="nofollow">doi:10.3969/j.issn.1671-1122.2010.04.014</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[64]</td> 
   <td> <p>ARM. ARM security technology: Building a secure system using TrustZone technology. ARM Limited, 2009.&nbsp;<a href="http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf" rel="nofollow">http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf</a></p> </td> 
  </tr> 
  <tr> 
   <td>[65]</td> 
   <td> <p>Verma A. Get into the Zone:Building Secure Systems with ARM TrustZone Technology. White Paper, Texas Instruments, 2013.<a href="http://cn.bing.com/academic/profile?id=1afb077e5abd66d276565763960d3ee5&amp;encoded=0&amp;v=paper_preview&amp;mkt=zh-cn" rel="nofollow">http://cn.bing.com/academic/profile?id=1afb077e5abd66d276565763960d3ee5&amp;encoded=0&amp;v=paper_preview&amp;mkt=zh-cn</a></p> </td> 
  </tr> 
  <tr> 
   <td>[66]</td> 
   <td> <p>Zhang YJ, Feng DG, Qin Y, Yang B. A trustzone-based trusted code execution with strong security requirements. Journal of Computer Research &amp; Development, 2015, 52(10): 2224–2238(in Chinese with English abstract). [<a href="http://dx.doi.org/10.7544/issn1000-1239.2015.20150582" rel="nofollow">doi:10.7544/issn1000-1239.2015.20150582</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[67]</td> 
   <td> <p>Ge XY, Vijayakumar H, Jaeger T. Sprobes: Enforcing kernel code integrity on the TrustZone architecture. In: Proc. of the Computer Science. 2014. 1793-1795.</p> </td> 
  </tr> 
  <tr> 
   <td>[68]</td> 
   <td> <p>Yang B, Feng DG, Qin Y, Zhang QY, Xi L, Zheng CW. Research on direct anonymous attestation scheme based on trusted mobile platform. Journal of Computer Research &amp; Development, 2014, 51(7): 1436–1445(in Chinese with English abstract).<a href="http://d.old.wanfangdata.com.cn/Periodical/jsjyjyfz201407007" rel="nofollow">http://d.old.wanfangdata.com.cn/Periodical/jsjyjyfz201407007</a></p> </td> 
  </tr> 
  <tr> 
   <td>[69]</td> 
   <td> <p>Chen LQ, Dietrich K, Löhr H, Sadeghi AR, Wachsmann C, Winter J. Lightweight anonymous authentication with TLS and DAA for embedded mobile devices. In: Proc. of the Int'l Conf. on Information Security. 2011. 84-98.</p> </td> 
  </tr> 
  <tr> 
   <td>[70]</td> 
   <td> <p>Feng W, Feng DG, Wei G, Qin Y, Zhang QY, Chang DX. TEEM: A user-oriented trusted mobile device for multi-platform security applications. In: Proc. of the Int'l Conf. on Trust and Trustworthy Computing. 2013. 133-141.</p> </td> 
  </tr> 
  <tr> 
   <td>[71]</td> 
   <td> <p>Gu JJ. Intel® Hardware-based Security Technologies Bring Differentiation to Biometrics Recognition Applications Part 1. 2015.</p> </td> 
  </tr> 
  <tr> 
   <td>[72]</td> 
   <td> <p>Jain P, Desai S, Kim S, Shih MW, Lee JH, Choi C, Shin Y, Kim T, Kang BB, Han D. OpenSGX: An open platform for SGX research. In: Proc. of the Network and Distributed System Security Symp. 2016.</p> </td> 
  </tr> 
  <tr> 
   <td>[73]</td> 
   <td> <p>Karande V, Bauman E, Lin Z, Khan L. SGX-Log: Securing system logs with SGX. In: Proc. of the 2017 ACM on Asia Conf. on Computer and Communications Security. 2017.</p> </td> 
  </tr> 
  <tr> 
   <td>[74]</td> 
   <td> <p>Fisch BA, Vinayagamurthy D, Boneh D, Gorbunov S. Iron: Functional encryption using Intel SGX. In: Proc. of the 2017 ACM SIGSAC Conf. on Computer and Communications Security. 2017. 765-782.</p> </td> 
  </tr> 
  <tr> 
   <td>[75]</td> 
   <td> <p>Ding Y, Duan R, Li L, Cheng YQ, Zhang YL, Chen TH, Wei T, Wang H. POSTER: Rust SGX SDK: Towards memory safety in Intel SGX enclave. In: Proc. of the 2017 ACM SIGSAC Conf. on Computer and Communications Security. 2017. 2491-2493.</p> </td> 
  </tr> 
  <tr> 
   <td>[76]</td> 
   <td> <p>Trusted Computing Group. Trusted platform module (TPM). 2010.&nbsp;<a href="https://trustedcomputinggroup.org/work-groups/trustedplatform-module/" rel="nofollow">https://trustedcomputinggroup.org/work-groups/trustedplatform-module/</a></p> </td> 
  </tr> 
  <tr> 
   <td>[77]</td> 
   <td> <p>Wang J, Shi Y, Peng GJ, Zhang HG, Zhao B, Yan F, Yu FJ, Zhang LQ. Survey on key technology development and application in trusted computing. China Communications, 2016, 13(11): 70–90. [<a href="http://dx.doi.org/10.1109/CC.2016.7781720" rel="nofollow">doi:10.1109/CC.2016.7781720</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[78]</td> 
   <td> <p>Shen CX, Zhang HG, Wang HM, Wang J, Zhao B, Yan F, Yu FJ, Zhang LQ, Xu MD. Research and development of trusted computing. Science China Press:Information Science, 2010, 40(2): 139–166(in Chinese with English abstract).<a href="http://d.old.wanfangdata.com.cn/Periodical/wjfz201108059" rel="nofollow">http://d.old.wanfangdata.com.cn/Periodical/wjfz201108059</a></p> </td> 
  </tr> 
  <tr> 
   <td>[79]</td> 
   <td> <p>Berger S, Cáceres R, Goldman KA, Perez R, Sailer R, Doom LV. vTPM: Virtualizing the trusted platform module. In: Proc. of the Conf. on USENIX Security Symp. 2006. 305-320.</p> </td> 
  </tr> 
  <tr> 
   <td>[80]</td> 
   <td> <p>Shi Y, Zhao B, Zhang HG. A security-improved scheme for virtual TPM based on KVM. Wuhan University Journal of Natural Sciences, 2015, 20(6): 505–511. [<a href="http://dx.doi.org/10.1007/s11859-015-1126-5" rel="nofollow">doi:10.1007/s11859-015-1126-5</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[81]</td> 
   <td> <p>Chen XQ, Gao XP, Wan H, Wang SM, Long X. Application-Transparent live migration for virtual machine on network security enhanced hypervisor. China Communications, 2011, 8(3): 32–42.&nbsp;<a href="http://cn.bing.com/academic/profile?id=ba8f958964b14df6568fd6bde18156e6&amp;encoded=0&amp;v=paper_preview&amp;mkt=zh-cn" rel="nofollow">http://cn.bing.com/academic/profile?id=ba8f958964b14df6568fd6bde18156e6&amp;encoded=0&amp;v=paper_preview&amp;mkt=zh-cn</a></p> </td> 
  </tr> 
  <tr> 
   <td>[82]</td> 
   <td> <p>Shetty J, Anala MR, Shobha G. A survey on techniques of secure live migration of virtual machine. Int'l Journal of Computer Applications, 2012, 39(12): 34–39. [<a href="http://dx.doi.org/10.5120/4875-7305" rel="nofollow">doi:10.5120/4875-7305</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[83]</td> 
   <td> <p>Nagin K, Hadas D, Dubitzky Z, Glikson A, Loy I, Rochwerger B, Schour L. Inter-Cloud mobility of virtual machines. In: Proc. of the Int'l Conf. on Systems and Storage. 2011. 1-12.</p> </td> 
  </tr> 
  <tr> 
   <td>[84]</td> 
   <td> <p>Patil VP, Patil GA. Migrating process and virtual machine in the cloud: Load balancing and security perspectives. Int'l Journal of Advanced Computer Science &amp; Information Technology, 2012, 1(1).</p> </td> 
  </tr> 
  <tr> 
   <td>[85]</td> 
   <td> <p>Bin Sulaiman NA, Masuda H. Evaluation of a secure live migration of virtual machines using ipsec implementation. In: Proc. of the Int'l Conf. on Advanced Applied Informatics. Iiai: IEEE, 2014. 687-693.</p> </td> 
  </tr> 
  <tr> 
   <td>[86]</td> 
   <td> <p>Fan W, Kong B, Zhang ZJ, Wang TT, Zhang J, Huang WQ. Security protection model on live migration for KVM virtualization. Ruan Jian Xue Bao/Journal of Software, 2016, 27(6): 1402–1416(in Chinese with English abstract).<a href="http://www.jos.org.cn/jos/ch/reader/view_abstract.aspx?flag=1&amp;file_no=5009&amp;journal_id=jos" rel="nofollow">http://www.jos.org.cn/jos/ch/reader/view_abstract.aspx?flag=1&amp;file_no=5009&amp;journal_id=jos</a> [<a href="http://dx.doi.org/10.13328/j.cnki.jos.005009" rel="nofollow">doi:10.13328/j.cnki.jos.005009</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[87]</td> 
   <td> <p>Wang W, Zhang Y, Lin B, Wu XX, Miao K. Secured and reliable VM migration in personal cloud. In: Proc. of the Int'l Conf. on Computer Engineering and Technology. 2010. V1-705-V1-709.</p> </td> 
  </tr> 
  <tr> 
   <td>[88]</td> 
   <td> <p>Aslam M, Gehrmann C, Bjorkman M. Security and trust preserving VM migrations in public clouds. IEEE, In: Proc. of the Int'l Conf. on Trust, Security and Privacy in Computing and Communications. 2012. 869-876.</p> </td> 
  </tr> 
  <tr> 
   <td>[89]</td> 
   <td> <p>Xen Open Source Community. Xen project.&nbsp;<a href="http://www.xenproject.org/" rel="nofollow">http://www.xenproject.org/</a></p> </td> 
  </tr> 
  <tr> 
   <td>[90]</td> 
   <td> <p>KVM (kernel-based virtual machine).&nbsp;<a href="https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine" rel="nofollow">https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine</a></p> </td> 
  </tr> 
  <tr> 
   <td>[91]</td> 
   <td> <p>Zhang HG, Han WB, Lai XJ, Lin DD, Ma JF, Li JH. Survey on cyberspace security. Science China Information Sciences, 2015, 58(11): 1–43.</p> </td> 
  </tr> 
  <tr> 
   <td>[92]</td> 
   <td> <p>Sasy S, Gorbunov S, Fletcher CW. ZeroTrace: Oblivious memory primitives from Intel SGX. In: Proc. of the Symp. on Network and Distributed System Security (NDSS). 2018.</p> </td> 
  </tr> 
  <tr> 
   <td>[1]</td> 
   <td> <p>王进文, 江勇, 李琦, 杨芫. SGX技术应用研究综述. 网络新媒体技术, 2017, 6(5): 3–9. [<a href="http://dx.doi.org/10.3969/j.issn.2095-347X.2017.05.002" rel="nofollow">doi:10.3969/j.issn.2095-347X.2017.05.002</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[58]</td> 
   <td> <p>GB/T 29827-2013. 信息安全技术可信计算规范可信平台主板功能接口. 2013.</p> </td> 
  </tr> 
  <tr> 
   <td>[59]</td> 
   <td> <p>GB/T 29828-2013. 信息安全技术可信计算规范可信连接架构. 2013.</p> </td> 
  </tr> 
  <tr> 
   <td>[60]</td> 
   <td> <p>GB/T 29829-2013. 信息安全技术可信计算密码支撑平台功能与接口规范. 2013.</p> </td> 
  </tr> 
  <tr> 
   <td>[62]</td> 
   <td> <p>石磊, 邹德清, 金海. Xen虚拟化技术. 武汉: 华中科技大学出版社, 2009.</p> </td> 
  </tr> 
  <tr> 
   <td>[63]</td> 
   <td> <p>沈晴霓. 虚拟可信平台技术现状与发展趋势. 信息网络安全, 2010(4): 34–36. [<a href="http://dx.doi.org/10.3969/j.issn.1671-1122.2010.04.014" rel="nofollow">doi:10.3969/j.issn.1671-1122.2010.04.014</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[66]</td> 
   <td> <p>张英骏, 冯登国, 秦宇, 杨波. 基于Trustzone的强安全需求环境下可信代码执行方案. 计算机研究与发展, 2015, 52(10): 2224–2238. [<a href="http://dx.doi.org/10.7544/issn1000-1239.2015.20150582" rel="nofollow">doi:10.7544/issn1000-1239.2015.20150582</a>]</p> </td> 
  </tr> 
  <tr> 
   <td>[68]</td> 
   <td> <p>杨波, 冯登国, 秦宇, 张倩颖, 奚瓅, 郑昌文. 基于可信移动平台的直接匿名证明方案研究. 计算机研究与发展, 2014, 51(7): 1436–1445.<a href="http://d.old.wanfangdata.com.cn/Periodical/jsjyjyfz201407007" rel="nofollow">http://d.old.wanfangdata.com.cn/Periodical/jsjyjyfz201407007</a></p> </td> 
  </tr> 
  <tr> 
   <td>[78]</td> 
   <td> <p>沈昌祥, 张焕国, 王怀民, 王戟, 赵波, 严飞, 余发江, 张立强, 徐明迪. 可信计算的研究与发展. 中国科学:信息科学, 2010, 40(2): 139–166.<a href="http://d.old.wanfangdata.com.cn/Periodical/wjfz201108059" rel="nofollow">http://d.old.wanfangdata.com.cn/Periodical/wjfz201108059</a></p> </td> 
  </tr> 
  <tr> 
   <td>[86]</td> 
   <td> <p>范伟, 孔斌, 张珠君, 王婷婷, 张杰, 黄伟庆. KVM虚拟化动态迁移技术的安全防护模型. 软件学报, 2016, 27(6): 1402–1416.<a href="http://www.jos.org.cn/jos/ch/reader/view_abstract.aspx?flag=1&amp;file_no=5009&amp;journal_id=jos" rel="nofollow">http://www.jos.org.cn/jos/ch/reader/view_abstract.aspx?flag=1&amp;file_no=5009&amp;journal_id=jos</a> [<a href="http://dx.doi.org/10.13328/j.cnki.jos.005009" rel="nofollow">doi:10.13328/j.cnki.jos.0050</a></p> </td> 
  </tr> 
 </tbody> 
</table>

[http_www.jos.org.cn_html_2018_9_5594.htm_b18]: http://www.jos.org.cn/html/2018/9/5594.htm#b18
[1]: http://www.jos.org.cn/html/2018/9/5594.htm#b1
[2]: http://www.jos.org.cn/html/2018/9/5594.htm#b2
[3]: http://www.jos.org.cn/html/2018/9/5594.htm#b3
[1 1]: http://www.jos.org.cn/html/2018/9/5594.htm#Figure1
[4]: http://www.jos.org.cn/html/2018/9/5594.htm#b4
[6]: http://www.jos.org.cn/html/2018/9/5594.htm#b6
[7]: http://www.jos.org.cn/html/2018/9/5594.htm#b7
[8]: http://www.jos.org.cn/html/2018/9/5594.htm#b8
[2 1]: http://www.jos.org.cn/html/2018/9/5594.htm#Figure2
[3 1]: http://www.jos.org.cn/html/2018/9/5594.htm#Figure3
[9]: http://www.jos.org.cn/html/2018/9/5594.htm#b9
[4 1]: http://www.jos.org.cn/html/2018/9/5594.htm#Figure4
[10]: http://www.jos.org.cn/html/2018/9/5594.htm#b10
[5]: http://www.jos.org.cn/html/2018/9/5594.htm#Figure5
[6 1]: http://www.jos.org.cn/html/2018/9/5594.htm#Figure6
[11]: http://www.jos.org.cn/html/2018/9/5594.htm#b11
[12]: http://www.jos.org.cn/html/2018/9/5594.htm#b12
[13]: http://www.jos.org.cn/html/2018/9/5594.htm#b13
[14]: http://www.jos.org.cn/html/2018/9/5594.htm#b14
[15]: http://www.jos.org.cn/html/2018/9/5594.htm#b15
[16]: http://www.jos.org.cn/html/2018/9/5594.htm#b16
[17]: http://www.jos.org.cn/html/2018/9/5594.htm#b17
[19]: http://www.jos.org.cn/html/2018/9/5594.htm#b19
[20]: http://www.jos.org.cn/html/2018/9/5594.htm#b20
[21]: http://www.jos.org.cn/html/2018/9/5594.htm#b21
[22]: http://www.jos.org.cn/html/2018/9/5594.htm#b22
[23]: http://www.jos.org.cn/html/2018/9/5594.htm#b23
[24]: http://www.jos.org.cn/html/2018/9/5594.htm#b24
[25]: http://www.jos.org.cn/html/2018/9/5594.htm#b25
[26]: http://www.jos.org.cn/html/2018/9/5594.htm#b26
[7 1]: http://www.jos.org.cn/html/2018/9/5594.htm#Figure7
[27]: http://www.jos.org.cn/html/2018/9/5594.htm#b27
[28]: http://www.jos.org.cn/html/2018/9/5594.htm#b28
[29]: http://www.jos.org.cn/html/2018/9/5594.htm#b29
[30]: http://www.jos.org.cn/html/2018/9/5594.htm#b30
[31]: http://www.jos.org.cn/html/2018/9/5594.htm#b31
[8 1]: http://www.jos.org.cn/html/2018/9/5594.htm#Figure8
[32]: http://www.jos.org.cn/html/2018/9/5594.htm#b32
[33]: http://www.jos.org.cn/html/2018/9/5594.htm#b33
[9 1]: http://www.jos.org.cn/html/2018/9/5594.htm#Figure9
[10 1]: http://www.jos.org.cn/html/2018/9/5594.htm#Figure10
[11 1]: http://www.jos.org.cn/html/2018/9/5594.htm#Figure11
[34]: http://www.jos.org.cn/html/2018/9/5594.htm#b34
[38]: http://www.jos.org.cn/html/2018/9/5594.htm#b38
[39]: http://www.jos.org.cn/html/2018/9/5594.htm#b39
[42]: http://www.jos.org.cn/html/2018/9/5594.htm#b42
[12 1]: http://www.jos.org.cn/html/2018/9/5594.htm#Figure12
[43]: http://www.jos.org.cn/html/2018/9/5594.htm#b43
[44]: http://www.jos.org.cn/html/2018/9/5594.htm#b44
[45]: http://www.jos.org.cn/html/2018/9/5594.htm#b45
[46]: http://www.jos.org.cn/html/2018/9/5594.htm#b46
[47]: http://www.jos.org.cn/html/2018/9/5594.htm#b47
[48]: http://www.jos.org.cn/html/2018/9/5594.htm#b48
[49]: http://www.jos.org.cn/html/2018/9/5594.htm#b49
[50]: http://www.jos.org.cn/html/2018/9/5594.htm#b50
[51]: http://www.jos.org.cn/html/2018/9/5594.htm#b51
[52]: http://www.jos.org.cn/html/2018/9/5594.htm#b52
[53]: http://www.jos.org.cn/html/2018/9/5594.htm#b53
[41]: http://www.jos.org.cn/html/2018/9/5594.htm#b41
[54]: http://www.jos.org.cn/html/2018/9/5594.htm#b54
[55]: http://www.jos.org.cn/html/2018/9/5594.htm#b55
[56]: http://www.jos.org.cn/html/2018/9/5594.htm#b56
[57]: http://www.jos.org.cn/html/2018/9/5594.htm#b57
[58]: http://www.jos.org.cn/html/2018/9/5594.htm#b58
[60]: http://www.jos.org.cn/html/2018/9/5594.htm#b60
[61]: http://www.jos.org.cn/html/2018/9/5594.htm#b61
[62]: http://www.jos.org.cn/html/2018/9/5594.htm#b62
[63]: http://www.jos.org.cn/html/2018/9/5594.htm#b63
[64]: http://www.jos.org.cn/html/2018/9/5594.htm#b64
[65]: http://www.jos.org.cn/html/2018/9/5594.htm#b65
[66]: http://www.jos.org.cn/html/2018/9/5594.htm#b66
[67]: http://www.jos.org.cn/html/2018/9/5594.htm#b67
[68]: http://www.jos.org.cn/html/2018/9/5594.htm#b68
[69]: http://www.jos.org.cn/html/2018/9/5594.htm#b69
[70]: http://www.jos.org.cn/html/2018/9/5594.htm#b70
[71]: http://www.jos.org.cn/html/2018/9/5594.htm#b71
[72]: http://www.jos.org.cn/html/2018/9/5594.htm#b72
[73]: http://www.jos.org.cn/html/2018/9/5594.htm#b73
[74]: http://www.jos.org.cn/html/2018/9/5594.htm#b74
[75]: http://www.jos.org.cn/html/2018/9/5594.htm#b75
[76]: http://www.jos.org.cn/html/2018/9/5594.htm#b76
[77]: http://www.jos.org.cn/html/2018/9/5594.htm#b77
[78]: http://www.jos.org.cn/html/2018/9/5594.htm#b78
[79]: http://www.jos.org.cn/html/2018/9/5594.htm#b79
[80]: http://www.jos.org.cn/html/2018/9/5594.htm#b80
[81]: http://www.jos.org.cn/html/2018/9/5594.htm#b81
[83]: http://www.jos.org.cn/html/2018/9/5594.htm#b83
[84]: http://www.jos.org.cn/html/2018/9/5594.htm#b84
[88]: http://www.jos.org.cn/html/2018/9/5594.htm#b88
[89]: http://www.jos.org.cn/html/2018/9/5594.htm#b89
[90]: http://www.jos.org.cn/html/2018/9/5594.htm#b90
[91]: http://www.jos.org.cn/html/2018/9/5594.htm#b91
[13 1]: http://www.jos.org.cn/html/2018/9/5594.htm#Figure13
[92]: http://www.jos.org.cn/html/2018/9/5594.htm#b92