近日，Linux基金会宣布全球多家巨头企业成立机密计算联盟（Confidential Computing Consortium），在对于数据安全和隐私担忧的不断增长下，基于可信执行环境技术的机密计算作为一种可行的解决方案，成为互联网巨头关注的焦点。蚂蚁金服很早就关注此类技术，并基于机密计算打造了蚂蚁金服新一代可信编程中间件SOFAEnclave，为金融业务保驾护航。

机密计算是蚂蚁安全计算的一环，也是金融级云原生的一块重要版图，蚂蚁金服表示：相信未来机密计算将和HTTPS一样，成为云计算的标配。

1. 引言

互联网金融本质上是对大量敏感数据的处理以及由此沉淀的关键业务智能。近年来涌现出来的新业态更是将数据处理的范畴从单方数据扩展到了涉及合作方的多方数据。另一方面，从GDPR到HIPAA，数据隐私监管保护的范围愈加扩大，力度日益增强。可见，对金融数据和关键业务智能的安全保护，不仅是互联网金融业务的基础，也是其创新发展的依托，更是攸关合规的关键因素。

近年来迅速发展的机密计算技术是一种创新的数据隔离和加密处理技术，其重要特点是，TCB(trusted computing base可信计算基)中仅包含应用自身和基础硬件，即使OS kernel、Hypervisor、甚至BIOS等特权软件都已经遭到破坏甚至本来就是恶意的，敏感数据和代码依然能安全无虞。蚂蚁金服在自身的实践过程中，基于机密计算底层技术发展出金融级的机密计算中间件，确保金融应用数据和代码的机密性和完整性，为关键业务提供易用、安全、集群化的计算环境。

本文从机密计算的技术背景、关键问题、蚂蚁的技术突破、以及典型应用场景等方面展开。

2. 机密计算的技术背景

随着云计算的快速发展，越来越多的关键性服务和高价值数据被迁移到了云端。云安全也因此成为学术界和工业界关注的一个焦点。

近年来，云安全领域最重要的一项技术进展名为机密计算（Confidential Computing）。机密计算填补了当前云安全的一项空白——使用中数据（Data-in-use）的加密。过去通行的做法是对数据在存储中（比如硬盘）和传输中（比如网络）加密，而在使用中（比如内存）解密，以便处理。而机密计算可以保护使用中数据的机密性和完整性。

目前，多家云计算巨头都在不约而同地推广这项技术：微软已于2017年7月宣布开始接受Azure机密计算的早期试用申请；IBM于2017年12月宣布IBM云数据保护（Cloud Data Guard）的预览版；谷歌也于2018年5月开源了名为Asylo的机密计算框架。

那么，机密计算究竟是如何实现的呢？

实际上，上述所有云计算巨头在实现机密计算时都离不开一种称为“可信执行环境（TEE）”的技术。

顾名思义，TEE提供一种与不可信环境隔离的安全计算环境，正是这种隔离和可信验证机制使得机密计算成为可能。

TEE一般是直接基于硬件实现的，比如Intel SGX，AMD SEV，ARM TrustZone，以及RISC-V Keystone等；基于虚拟化技术也可以构造TEE，比如微软的VSM，Intel的Trusty for iKGT & ACRN，但尚不能匹敌硬件TEE的安全性。

其中，Intel软件防护拓展（Software Guard Extensions，简称SGX）是目前商用CPU中最为先进的TEE实现，它提供了一套新的指令集使得用户可以定义称为Enclave的安全内存区域。CPU保证Enclave与外界隔离，从而保护其中的代码和数据的机密性、完整性和可验证性。不同于之前的TEE实现，比如ARM TrustZone，SGX每个APP都可以有自己独立的TEE，甚至可以创建多个TEE，而TrustZone是整个系统有一个TEE；这里也省去了向设备厂商申请将TA装入TEE的过程。由于SGX的先进性，目前云端机密计算领域甚至已公认用Enclave这个词来指代TEE。

图1 典型TEE安全特性和使用流程[1]

典型的Enclave达到的安全目标可以用CIA概括，即机密性（Confidentiality）、完整性（Integrity）和真实性（Authenticity）。在实现上具有以下基本要求：

Enclave内存保护

Enclave内存只有Enclave本身的代码可以访问。CPU通过内存隔离和加密来防止对安全内存的软件攻击和硬件嗅探。SGX更通过内存控制器的integrity tree防止了对Enclave内存的物理篡改。

Enclave的可信验证

CPU支持对Enclave中数据和代码的测量，以及对Enclave合法性的本地或远程验证。有了测量和验证，本地的Enclave之间、客户端与远程Enclave之间，就可以认证身份，进而建立安全的通信信道。

如何开发受Enclave保护的应用程序呢？

以SGX为例，其中一种方法是利用Intel SGX SDK。如下图所示，基于SGX SDK的应用程序分为两部分：Enclave外的不可信组件（左边黄色部分）和Enclave内的可信组件（右边绿色部分）。两边可以通过跨Enclave的函数调用通信：不可信组件可以通过ECall调用可信组件中定义的函数；反之，可信组件也可以通过OCall调用不可信组件中定义的函数。

图2 Enclave编程模型[2]

3. 机密计算面临的关键问题

Enclave给我们带来了前文所谓CIA的安全保障，但是目前面临较大的易用性问题。主要体现在几个方面。

第一，需要将原有应用分割成两部分，一部分是enclave外的untrusted 部分，一部分在enclave里面作为trusted 部分；

第二，需要精心设计两部分之间的接口，规划好什么时候进入Enclave，什么时候退出Enclave——这存在一定技术门槛，而且比较繁琐容易出错；

第三，即使我们做了完美的分割， Enclave里面的环境相对于我们熟悉的通常的Linux运行环境来说是非常受限的。例如，enclave里面不能进行系统调用，libc、pthread不完整，没有openmp，多进程支持欠缺等等。

可见，把应用移植到Enclave里面是极具挑战的，在某些时候甚至是不可能做到的。而且，由于开发过程中必须考虑业务无关的繁杂琐细的方面，即使最终能完成应用开发移植目标，也会导致低下的开发效率，极高的开发成本，这对于快节奏的互联网业务来说是难以接受的。

机密计算走向工程实用面临的另一较大问题是，如何将机密计算从单节点向集群扩展。由于缺乏标准的做法，或者没有一个best practice作为参考，很多时候各个业务不得不各自从头造轮子，搭建跟业务逻辑过度耦合的Enclave集群基础设施。从而导致低下的开发效率和重复的资源投入。

另一方面，互联网业务日趋云原生化，越来越多地采用云原生的container->k8s->serverless技术栈，机密计算集群如何跟云原生技术栈相结合，目前仍然是较为棘手的问题。

4. SOFAEnclave：蚂蚁金服的机密计算创新

蚂蚁金服作为中国互联网金融领导企业，对于数据保护有大量的需求，因此围绕机密计算进行了丰富的业务创新和技术探索。本节针对上面提到的机密计算面临的关键问题，主要介绍蚂蚁金服在这方面的创新性成果，即SOFAEnclave机密计算中间件。

SOFAEnclave属于蚂蚁金服金融级分布式架构SOFAStack的一环，从2007年开始，SOFAStack 产生于蚂蚁金服内部需求，起初是为了解决高速发展下的业务问题。到 2019 年，已经历12年的业务锤炼，是一套成熟的金融级最佳实践。从2018年起，蚂蚁金服宣布将SOFAStack贡献给开源社区，目前已贡献出超过10个核心项目，受到社区广泛关注。

SOFAEnclave主要关注底层基础设施的安全防护，为数据和代码打造一层可信中间件。我们的总体目标是通过易用性的提升，向业务屏蔽Enclave开发挑战和机密计算集群复杂性，使业务保持原有开发部署习惯。用一句话总结就是，使业务只需关注业务。

图3 SOFAEnclave

SOFAEnclave的核心包括三部分，Enclave内核Occlum，云原生机密计算集群KubeTEE，以及安全测试和分析框架。这里主要介绍Occlum和KubeTEE。

4.1 Occlum LibOS：安全高效的机密计算内核

针对Enclave易用性问题，我们设计了一个名为Occlum的Enclave内核，并将其作为一个开源项目采用社区模式开发。类比操作系统内核，Occlum LibOS向 Enclave内的可信应用提供完整的系统服务，应用不需要分割和修改即可得到Enclave保护。

Occlum兼容POSIX编程接口，并支持多线程、OpenMP、和多进程；同时，Occlum实现了多进程隔离机制，使得多个可信应用之间可以相互隔离。Occlum使得开发者方便利用Enclave的 CIA能力，达到可用不可见、可用不可攻的效果，使数据保护能真正得到落实。

目前，Occlum可轻松支持大型人工智能框架，例如XGBoost、TensorFlow等，也可支持大型服务器应用例如Shell, GCC，Web Server等。Occlum具有如下技术特点：

内存安全

内存安全问题是系统软件中最常见的安全隐患。竞态条件、缓冲区溢出、空指针、栈溢出、堆耗尽、释放后访问、或重复释放，这些术语都用于描述内存安全漏洞。微软2019年2月表示，在过去12年里，微软所有补丁中大约70%是针对内存安全漏洞的。因此，防范内存安全问题对系统软件的安全性和健壮性非常重要。

Occlum是业界首个内存安全的SGX LibOS。Occlum LibOS是基于保证内存安全的Rust语言开发，只包含极少量的Unsafe Rust、C和汇编代码（小于1000行）。这使得Occlum难以出现最底层的内存安全相关的bug和漏洞。因此，相比使用C/C++开发的传统SGX LibOS（如Graphene-SGX和SCONE），Occlum更值得开发者信赖，作为开发高安全应用的基础。

简单易用

Occlum LibOS使得Linux应用程序在只修改少量代码或者完全不修改代码的情况下运行于Enclave安全环境中。用户只需使用Occlum工具链（occlum-clang）编译应用程序，并使用名为occlum的命令行工具在SGX enclave中运行该应用程序。该命令行工具提供了诸多子命令，其中最重要的三个是：

occlum init：初始化Occlum的上下文

occlum build：制作Occlum的可信镜像和enclave

occlum run <program_name> <program_args>：在enclave中运行Occlum可信镜像中的一个程序

Occlum大大降低了为Enclave开发应用的开发成本。我们以一个最简单的Hello World为例说明。使用Intel SGX SDK开发的SGX Hello World工程包含10个左右的文件，300行左右的代码；使用百度的Rust SGX SDK需要200行左右的代码；Google的Asylo也需要100行左右的代码。相比之下，Occlum不要求用户给Linux版本Hello World（5行代码）增加任何额外的代码，并且只需三行命令即可将Linux版的Hello World程序运行于SGX enclave中，效果如下：

图4 3行命令在Enclave里跑5行代码的Hello World

高效多进程

任何应用程序在LibOS上都是作为进程运行的，而应用程序往往又由多个进程组成。因此，LibOS对多进程的高效支持就显得至关重要了。然而，现有SGX LibOS对多进程的支持并不能令人满意。闭源的SCONE只支持多线程，尚不支持多进程。开源的Graphene-SGX是目前最成熟的SGX LibOS，且能够支持多进程，但它的每个LibOS进程必须在一个单独的SGX enclave中运行，且每个enclave中必须运行一个独立的LibOS实例。这种N进程-N enclave的架构虽然保证了LibOS进程之间的强隔离，但也导致了性能和功能方面的问题：

进程启动慢：Graphene-SGX要为每个LibOS进程创建一个单独的enclave，而创建enclave的开销非常高，因此Graphene-SGX的LibOS进程启动极慢（比Linux启动进程慢接近10,000倍）。

IPC开销高：Graphene-SGX的每个LibOS进程都被一个enclave同外界完全隔离，因此LibOS进程间通信必须借助于enclave外的不可信缓存，并传输加密数据。加密解密大大增加了进程间通信的开销。

难保证一致性：Graphene-SGX有N个进程就有N个LibOS实例，而原则上来讲，这N个LibOS实例应该向上层的应用程序提供一致的OS状态，比如加密文件系统。但显然在多个LibOS实例之间同步文件系统的状态（比如每个文件块的密钥）是困难的。这也是为什么Graphene-SGX至今都未提供加密文件系统。

与Graphene-SGX不同，Occlum是一个单地址空间LibOS，即在同一个enclave中运行多个LibOS进程。该架构特别适用于多进程协作的使用场景，即多个互信的进程组成同一个应用或服务。这个“多进程共享enclave”的架构为Occlum的多进程支持带来了三个优势：

进程启动快：Occlum的进程启动比Graphene-SGX快13-6600倍（图4）；

IPC开销低：Occlum的进程间通信带宽是Graphene-SGX的3倍（图5）；

加密文件系统：Occlum支持对应用透明的、可写加密文件系统，保证文件系统的元数据与数据的机密性和完整性。

图5 进程启动时延比较程序大小分别为14KB、400KB和14MB

图6 进程间通信(pipe)带宽比较

4.2 KubeTEE：金融级云原生的机密计算集群

针对Enclave集群化方面的问题，我们思考如何能更高效和简洁的使用TEE资源提供机密计算服务，我们的解决方法是KubeTEE——结合云原生，提供机密计算集群服务。

一方面避免了业务用户重复进行基础设施建设，另一方面用户注册账号即可使用机密计算集群服务，大大降低了机密计算门槛，提高了易用性和利用率。 KubeTEE为了更高效的使用物理资源，基于k8s + container更优雅地部署和管理机密计算镜像和EPC资源。基于k8s的容器调度能力，KubeTEE可以快速实现机密计算服务资源的横向扩缩容。概括来说，我们希望以一种更加云原生的方式来使用Enclave和机密计算集群资源。

1）提供基于Enclave Container的业务部署能力，基础设施运维和业务无感知升级等能力

2）提供Serverless机密计算服务，基于通用的机密计算资源池支持业务服务

3）基于通用的机密计算组件、中间件服务和研发流程结合提供平台化的业务开发能力

图7 KubeTEE系统架构

上图中描述了我们实现Serverless机密计算集群的过程，我们一方面提供最终态的机密计算服务，同时将过程中积累的组件抽象化为可复用模块，应对不同业务的定制化需求，提升机密计算业务的Enclave开发效率。

5. 典型应用场景

机密计算应用场景非常广泛，常见的应用有基于Enclave的版权保护、生物识别保护、基因数据处理、密钥保护、密钥管理系统、隐私保护的机器学习、加密数据分析、以及保密数据库等。其他如区块链隐私计算、区块链+AI、隐私边缘计算等都可以构建在机密计算技术基础上，以更好的服务应用场景。这一节结合互联网业务探讨两个略微复杂的应用场景。

基于Enclave的多方竞合学习

众所周知，人工智能能发展到今天，有两个原因：一个是算力的提高，另一个就是数据规模的增长。但是，单一机构的业务领域和业务受众是有限的，因此其数据积累一方面是不全面的，另一方面也是难以形成规模的。

为了发挥数据的更大价值，一个自然的想法就是汇聚多方数据进行集中挖掘。但是，机构之间出于业务保密以及行业竞争的顾虑，又不可能把自己的数据无保留分享给别人。

这导致了一种看似不可思议的矛盾局面：多个机构既竞争又合作，既数据共享又数据保密（图6）——我们将其称为多方竞合学习。

怎么解决这种矛盾呢？一种方案是，把各自加密的数据导入Enclave，在Enclave内解密、汇聚、并挖掘。具体实现细节可以参考蚂蚁金服共享智能团队的文章。

图8 多方竞合学习

AI模型安全保护

对外部署的AI模型携带大量知识产权，一旦被逆向或泄露，既会对技术护城河造成破坏，也会降低对抗性样本攻击的难度，导致安全问题。

应对这种威胁的一种方案是，使用方把AI模型和训练/预测数据加密存储，只有在使用时才将其输入Enclave，在Enclave里面解密，由Enclave中运行的AI框架处理，结果根据具体场景需求以明文返回或加密返回并在使用方本地解密。这要求Enclave能支持常见的AI框架，而要做到这一点极为挑战——一方面是因为这些AI框架一般使用了复杂的多线程、OpenMP等性能优化的运行环境，另一方面是因为Enclave又偏偏难以提供这些支撑环境。这就是为什么市面上很多Enclave支撑系统难以支持（或难以高效支持）AI框架的原因。

如前所述，Occlum LibOS在这方面取得了一定的进展，可以较为轻松的高效运行常见AI框架。

图9 AI模型安全保护

6. 总结与展望

机密计算方兴未艾，学术界的研究如火如荼，工业界的应用也日益丰富和实际。蚂蚁金服在机密计算领域是技术的探索者和业务的先行者，我们仍有诸多问题需要整个生态的合作。

我们正在逐步将SOFAEnclave里的模块贡献给开源社区，欢迎行业和学术同仁联系合作。希望合作伙伴向Occlum项目提出反馈并贡献代码，一起利用Occlum LibOS来支持更多实际应用，实现Enclave保护的安全容器Enclave Container。在KubeTEE方面，希望能与合作伙伴共建生态，维护可信应用和镜像仓库，推进机密计算集群方案的实用化标准化。

注：

[1] 图片来源https://keystone-enclave.org/files/keystone-risc-v-summit.pdf

[2] 图片来源 https://mp.weixin.qq.com/s/ZUscn47mxD3WqIJbN9mNAA

创作场景

下一代 HTTPS：蚂蚁金服推出新型可信中间件 SOFAEnclave