【华为云技术分享】Intel SGX和ARM TrustZone浅析
咱们先理解一下业界具备统一认识的一些概念：html
安全启动：启动过程当中，前一个部件验证后一个部件的数字签名，验证经过后，运行后一个部件，不然就停止或复位系统。所以它是一个防恶意篡改的手段。安全
可信启动：启动过程当中，前一个部件度量（计算HASH值）后一个部件（一般在后一个部件被签名校验过以后），而后把度量安全的保存下来，好比扩展到TPM的PCR中。后续接入平台后，部件的度量会上报到认证平台，认证平台会有配置一个可信白名单，若是某个部件的版本信息不在白名单里，则认为此设备是不受信任的，由于它可能使用了一个虽然有签名，但可能BUG的版本。所以它是一个可信版本的管理手段。服务器
安全启动/可信启动 是确保系统级别的安全手段，适用于有可信诉求的整机系统，终端设备如手机、STB、路由器等，固然也适用于通用服务器设备。网络
以上安全启动和可信启动的概念，网上以及公司W3有许多专家在讨论，能够自行进一步理解。然而，若是仅从字面要求试图实施时，咱们又会发现许多新的问题，举个例子：安全启动时，确实每一级都被签名校验了，但肯定安全吗？ 某一级如操做系统1分钟前刚刚被校验过，1分钟后仍是可信的吗？不见得，这个过程当中，操做系统彻底有可能已经被非法修改过了。多线程
要作到相对更安全，要么可以作到Runtime的实时校验，即每次使用那一刻都要校验。若是作不到Runtime校验，那就想办法将校验过的数据安全保存起来…相关实现方案和技术其实在有前提的状况下已具有，这是另外一个课题。架构
这个前提是指系统须要是不开放的嵌入式系统，由于不开放，可定制，提供特定的功能/服务，所以整机系统的保护是可行的，而且方案都是很成熟的。框架
那对于通用计算设备好比服务器产品是个什么样的状况呢？ 基本上就是这么个事实：性能
- 系统“全局保护”愈来愈难以实现，且不切实际
缘由是当前开源共享，而且是自由的大环境。操做系统开源，应用开源，用户自由地选择不一样版本的操做系统和应用，一切都不在设备厂商的控制中。学习
2. “全局保护”不可行，那就将保护范围缩小到应用的部分片断--加密
这就是Intel SGX或ARM TrustZone的由来
所以，Intel SGX或ARM TrustZone是传统的系统保护手段不可行，通用系统设备的保护方案没法借鉴嵌入式系统的方案后，安全技术工做者转变思路后的产物。
接下来咱们来理解一下基于这两种技术的应用的工做过程，但此文不讨论这两个安全方案的实现原理。
Intel SGX
网上有至关多的材料，而且都有一个特色：短小精悍。因而咱们就看到了很是经典的一个图，足以说明SGX应用的工做原理：
- 应用在设计时，须要考虑所谓的trusted和untrusted两部分，trusted即为处理敏感数据的实现部分
- 实现应用，对于trusted部分，须要使用Enclave定义语言（EDL）来实现须要的逻辑。经过EDL实现的内容，将被执行在安全区域（Enclave）
- Enclave中的实现可被untrusted的代码调用，当被调用时，命令会经过底层驱动传递Enclave中；
- Enclave中的数据对外部不可见，也禁止外界的访问（包括系统高权限的代码也不可访问）
- 处理完以后，返回结果，但过程数据仍然在Enclave中；
- 得到返回后，应用的untrusted部分按即定的过程继续执行。
咱们能够再看一下EDL的使用示例，这样能够了解应用开发的难易程度：
1 enclave { 2 // An EDL file can optionally import functions from 3 // other EDL files 4 from “other/file.edl” import foo, bar; // selective importing 5 from “another/file.edl” import *; // import all functions 6 // Include C headers, these headers will be included in the 7 // generated files for both trusted and untrusted routines 8 include "string.h" 9 include "mytypes.h" 10 // Type definitions (struct, union, enum), optional 11 struct mysecret { 12 int key; 13 const char* text; 14 }; 15 enum boolean { FALSE = 0, TRUE = 1 }; 16 // Export functions (ECALLs), optional for library EDLs 17 trusted { 18 //Include header files if any 19 //Will be included in enclave_t.h 20 //Trusted function prototypes 21 public void set_secret([in] struct mysecret* psecret); 22 void some_private_func(enum boolean b); // private ECALL (non-root ECALL). 23 }; 24 // Import functions (OCALLs), optional 25 untrusted { 26 //Include header files if any 27 //Will be included in enclave_u.h 28 //Will be inserted in untrusted header file 29 “untrusted.h” 30 //Untrusted function prototypes 31 // This OCALL is not allowed to make another ECALL. 32 void ocall_print(); 33 // This OCALL can make an ECALL to function 34 // “some_private_func”. 35 int another_ocall([in] struct mysecret* psecret) 36 allow(some_private_func); 37 }; 38 };
能够看到，EDL并非要求用户掌握学习一门新的语言，它的代码仍然是类POSIX API，C/C++库构成的，它也能够快速的将已有的实现迁移到Enclave中。
小结
SGX Enclave彻底使用了CPU的隔离能力，不可操做外设、中断等。EDL定义片断属于普通App的一部分，所以多核 、多线程均可以支持。EDL随时随地定义，部署很是灵活方便。可是EDL是定义在代码中的，经过版本的逆向工程，对于数据的处理逻辑，是有可能被窥探的。
ARM TrustZone
TrustZone是标准TEE实现的一种方案，GP的TEE架构和规范标准都是由ARM TrustZone 贡献。当咱们讲TrustZone时，能够理解为是在讲GP TEE。则于标准规范，就致使了与SGX不同的状况，TEE实现有大量的资料能够参考。如下是TEE应用实现的原理：
- 基础设施：与SGX不一样的，TEE的功能，依赖于安全OS，首先要确保设备上已经部署了安全OS，而且要确保其是可信的；
- 设计应用，对于须要可信保护的处理过程，须要实如今单独的可应用中（TA）；APP以及TA须要分别开发，物理上他们是两个程序；
- APP执行到安全处理部分时，它经过TEE标准接口向TA发消息；
- 调用须要进入内核态，经过驱动将消息送到TEE侧；
- TA收到消息后，来执行即定的数据处理逻辑。
- 最后将结果返回到APP，但过程数据仍然在TEE侧，
TrustZone 利用的是CPU时间片切换来模拟了安全世界，这两个世界能够将它理解成一个CPU上处理的两个进程，它们经过上下文切换来将CPU的时间片占满以利用CPU。从安全角度，仅仅分时复用或拟化，是不足以确保安全的，所以ARM另外定义了安全框架，从硬件级别两个世界，包括Timer、TRNG、TZPC、MMU、Cache等相关设备，不一样的芯片厂商会有本身的考虑，这个设备多是双份的，或者是动态切换以达到隔离目的（此处不方便贴上我司920的安全芯片框架）。同时，安全侧也须要有一个可信操做系统执行应用。从原理上，REE侧和TEE侧是对等的，所以并不会性能的差别。应用程序的开发，除了使用TEE定义的标准接口，依赖的都POSIX API，使用标准的开发语言。
在部署应用时，SGX只须要在代码中定义便可，在TrustZone中侧须要单独开发部署TA。通常设置厂商都会提供给应用开发者自行部署TA的方法，与SGX相比稍有一点不一样，但并非不可接受（我的观点），这也确实是SGX很明显的一个优点，因而乎，ARM后面有了Newmore这样一个概念。
但也正由于TA与APP是分离的，而且TEE侧是不可查看的，所以数据的处理过程很难以被窥探。
最后，还有一点，网上还有一种声音，认为SGX和TrustZone“没有什么用”，观点的理由是：
“且不说传统的攻击，如SQL注入、溢出攻击,使得攻击者能够直接控制非安全应用，进而经过定义的接口取得数据，即便没有这些漏洞，恶意软件经过其余途径入侵到了OS里面，它是否是能够远程注入一段代码到APP，而后调用接口获取数据？”
这里必需要反驳一下，之全部这个观点，是他没有理解SGX或TrustZone的真正的使用场景。正确的处理方式其实上面的过程描述中咱们已经提到了：
“处理完以后，返回结果，但过程数据仍然在Enclave中”
“最后将结果返回到APP，但过程数据仍然在TEE侧”
一个有价值的安全应用，并不会支持将敏感数据经过接口调用返回到非安全侧。
应用的安全与否，不管是SGX仍是TrustZone应用，确实很大程度上是依赖开发者的意识。SGX或者TrustZone，它们的价值在因而隐匿敏感数据自己，以及尽量的隐藏处理敏感数据的处理过程。只有以这个导向，在应用开发时才能有意识地向这个方向去努力。
咱们拿媒体数据举例，一看就会明白应该如何正确使用SGX或TrustZone---
高价值的媒体内容在网络传输时，它一般是被DRM加密保护的，只有凭证的订户才能够解密播放。盗版者自己可能就是个订户，在没有SGX、TrustZone等保护时，经过拷贝内存等手段就很容易实现盗版。但有这些技术后，加密的媒体流并不会在非安全侧解密，而是送往安全侧。注意，在SGX、TrustZone解完密以后的媒体，也并不会返回到安全侧，而是使用底层安全驱动，直接送往解码播放了，媒体数据直接在安全侧消费了。
以上是从应用开发者角度来比较SGX与TrustZone的差别。但事实上，二者彻底不是一个层面的东西，SGX更适合拿AMD的SEV来比较，由于这两种技术相似，都是基于所谓的realm技术（局部保护）来实现。ARM有最新的newmore方案，但目前还在验证的概念阶段，预计在2023年之后才可能产品化，这个世界变化太快，两年的时间实太是过久，暂不讨论。
转自鲲鹏社区