首页 华为云动态正文

【华为云技术分享】Intel SGX和ARM TrustZone浅析

云返利网 华为云动态 2020-08-22 06:28:24 10 0 华为云服务

我们先理解一下业界具有统一认识的一些概念:

安全启动:启动过程中,前一个部件验证后一个部件的数字签名,验证通过后,运行后一个部件,否则就中止或复位系统。因此它是一个防恶意篡改的手段。

可信启动:启动过程中,前一个部件度量(计算HASH值)后一个部件(通常在后一个部件被签名校验过之后),然后把度量安全的保存下来,比如扩展到TPM的PCR中。后续接入平台后,部件的度量会上报到认证平台,认证平台会有配置一个可信白名单,如果某个部件的版本信息不在白名单里,则认为此设备是不受信任的,因为它可能使用了一个虽然有签名,但可能BUG的版本。因此它是一个可信版本的管理手段。

安全启动/可信启动 是确保系统级别的安全手段,适用于有可信诉求的整机系统,终端设备如手机、STB、路由器等,当然也适用于通用服务器设备。

以上安全启动和可信启动的概念,网上以及公司W3有许多专家在讨论,可以自行进一步理解。然而,如果仅从字面要求试图实施时,我们又会发现许多新的问题,举个例子:安全启动时,确实每一级都被签名校验了,但确定安全吗? 某一级如操作系统1分钟前刚刚被校验过,1分钟后还是可信的吗?不见得,这个过程中,操作系统完全有可能已经被非法修改过了。

要做到相对更安全,要么能够做到Runtime的实时校验,即每次使用那一刻都要校验。如果做不到Runtime校验,那就想办法将校验过的数据安全保存起来…相关实现方案和技术其实在有前提的情况下已具备,这是另一个课题。

这个前提是指系统需要是不开放的嵌入式系统,因为不开放,可定制,提供特定的功能/服务,因此整机系统的保护是可行的,并且方案都是很成熟的。

那对于通用计算设备比如服务器产品是个什么样的情况呢? 基本上就是这么个事实:

  1. 系统“全局保护”越来越难以实现,且不切实际

原因是当前开源共享,并且是自由的大环境。操作系统开源,应用开源,用户自由地选择不同版本的操作系统和应用,一切都不在设备厂商的控制中。

2. “全局保护”不可行,那就将保护范围缩小到应用的部分片段--

这就是Intel SGX或ARM TrustZone的由来

因此,Intel SGX或ARM TrustZone是传统的系统保护手段不可行,通用系统设备的保护方案无法借鉴嵌入式系统的方案后,安全技术工作者转变思路后的产物。

接下来我们来理解一下基于这两种技术的应用的工作过程,但此文不讨论这两个安全方案的实现原理。

Intel SGX

网上有相当多的材料,并且都有一个特点:短小精悍。于是我们就看到了非常经典的一个图,足以说明SGX应用的工作原理:

  1. 应用在设计时,需要考虑所谓的trusted和untrusted两部分,trusted即为处理敏感数据的实现部分
  2. 实现应用,对于trusted部分,需要使用Enclave定义语言(EDL)来实现需要的逻辑。通过EDL实现的内容,将被执行在安全区域(Enclave)
  3. Enclave中的实现可被untrusted的代码调用,当被调用时,命令会通过底层驱动传递Enclave中;
  4. Enclave中的数据对外部不可见,也禁止外界的访问(包括系统高权限的代码也不可访问)
  5. 处理完之后,返回结果,但过程数据仍然在Enclave中;
  6. 获得返回后,应用的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应用实现的原理:

  1. 基础设施:与SGX不同的,TEE的功能,依赖于安全OS,首先要确保设备上已经部署了安全OS,并且要确保其是可信的;
  2. 设计应用,对于需要可信保护的处理过程,需要实现在单独的可应用中(TA);APP以及TA需要分别开发,物理上他们是两个程序;
  3. APP执行到安全处理部分时,它通过TEE标准接口向TA发消息;
  4. 调用需要进入内核态,通过驱动将消息送到TEE侧;
  5. TA收到消息后,来执行即定的数据处理逻辑
  6. 最后将结果返回到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年以后才可能产品化,这个世界变化太快,两年的时间实太是太久,暂不讨论。

转自鲲鹏社区

【关于云返利网】

云返利网是阿里云、腾讯云、华为云产品推广返利平台,在各个品牌云产品官网优惠活动之外,云返利网还提供返利。您可以无门槛获得阿里云、华为云、腾讯云所有产品返利,在官网下单后就可以领取,无论是自己用、公司用还是帮客户采购,您个人都可以获得返利。云返利网的目标是让返利更多、更快、更简单!详情咨询13121395187(微信同号)