基于统一远程证明的 TEE 互联互通实践
导读： 今天分享的题目是基于统一远程证明流程的 TEE 互联互通实践。
主要内容分为四个部分：
-
TEE 互联互通背景介绍
-
TEE 及其远程证明流程
-
统一远程证明流程
-
TEE 互联互通整体思考
分享嘉宾｜肖俊贤 蚂蚁集团 高级技术专家
编辑整理｜任航琦 山东大学
出品社区｜DataFun
01/TEE 互联互通背景介绍
我们当前正在开展的 TEE 互联互通研究工作，是北京金融科技产业联盟内隐私计算互联互通总研究课题下的 7 个子课题中的一个，由工行和蚂蚁牵头进行推进，有十几家参与单位，目前已经接近于尾声。TEE 互联互通是在所有子课题下面唯一一个跟 TEE 技术背景更相关的课题，其他子课题更多偏向于隐私计算互联互通通用框架和密码学相关技术细节。TEE 互联互通子课题虽然也需要基于其他子课题的一些工作，继承其他子课题的研究成果，但更多关注 TEE 的特殊之处。
--
02/TEE 及其远程证明流程
TEE 从本质上讲，是一个保护运行时数据和代码安全的隔离环境。从中文的"可信执行环境"这一名字上也可见一斑。通常 TEE 都会基于硬件安全原语去实现。
从隔离的维度上来看，TEE 可分为三类：
① 基于体系结构的隔离，比如 ARM Trustzone， 多用于手机终端环境；
② 基于应用的隔离，现在商用场景下用的比较多的是 Intel SGX1/SGX2；
③ 基于虚拟化的隔离，未来可能会成为一种发展趋势，如英特尔正在推的 Intel TDX，海光 CSV。
相比于其它隐私计算技术，TEE 有着自己特别的地方，它是主流的隐私计算技术里面，唯一一个依赖于硬件安全的技术。它是在硬件提供的安全隔离的环境里面进行明文普通计算，所以具有更好的通用性和更好的计算性能。
从核心能力上来看，TEE 对外提供代码和数据的机密性、完整性的保护。这部分能力是通过 TEE 技术本身来保证的，上层的应用程序基本是感知不到的。另外 TEE 需要提供远程证明流程，来证明 TEE 本身环境的安全，以及运行在 TEE 里面的可信应用程序的完整性等，这也是唯一需要用户参与的流程。所以 TEE 互联互通子课题的研究更多的是围绕远程证明来开展。
远程证明这个概念不是 TEE 所特有的，这种技术已经发展了很多年，TEE 本身的远程证明流程也是遵循 IETF 中 RATS 的模型抽象。我们可以简单的理解，RATS 的核心部件有三个：Attester，Verifier 和 Relying Party。
Attester 负责提供证据来证明 TEE 的可信；Verifier 负责校验这些证据（实际方案中更多的是校验 TEE 平台部分）；校验结果交给 relying party 继续校验（实际方案中更多校验可信应用部分）。Verifier 和 Relying Party 也可以合并成一个实体，作为挑战方， 通过校验 Attester 提供的证据来证明 TEE 和应用是安全的，从而能够与其通信，以及做后续一些相应的动作。
从整个流程来上来讲，TEE 的远程证明流程还包含其他一些安全角色，比如 TEE 的方案提供商、设备的生产方等等。他们会提供一些输入来辅助远程证明的流程。RATS 规范实现了远程证明的概念上和流程上的抽象。但是没有涉及到具体实现和数据结构等这种细粒度的定义，所以不同 TEE 的实现方案中的远程证明流程，从编程接口、流程本身，还有数据结构等方面看都有很大的差异。这也就造成了我们在实际应用 TEE 的时候会出现互联互通的困难。所以我们提出了统一远程证明流程的概念， 在 RATS 的模型抽象的基础上，去做进一步的编程级别细化，从而更好地实现 TEE 互联互通。
--
03/统一远程证明流程
我们最开始研究 TEE 互联互通问题的动机也是因为有实际的生产需求，我们引入自研的 HyperEnclave 方案时，其实已经在使用 SGX1、SGX2 的方案。我们发现越来越多的 TEE 出现之后，应用从一个 TEE 的方案迁移到另一个 TEE 的方案，需要修改应用适配不同 TEE 方案，不管是在域内还是域外的场景下面，都有可能会碰到这个问题。
另外是在不同的 TEE 中的应用，它们彼此之间互相调用，也会出现这种互联互通的需求。我们需要统一的方案来解决通用性的问题。
基于以上背景，我们提出了 Unified Attestation 的方案。
主要的工作分为三块。第一块是 Unified Attestation Library ，在通用库或者通用中间件的角度去提供统一远程证明的生成和校验报告的接口，以及报告格式的封装，和对统一格式报告的校验规则的封装。另外，为了进一步简化远程证明流程，我们也提出了 Unified Attestation Service ，统一的远程证明代理服务，实现 TEE 平台差异和应用彻底隔离解耦。基于对远程证明流程的统一封装，我们进一步思考，可信应用程序基于远程证明会做什么事情？可能更多的是要去进行数据的交互以及流动。我们进一步为应用层提供更多的、更高阶的一些接口的抽象，也就是 Unified Attestation Workflow 部分的工作。
在研究TEE互联互通子课题的时候，我们也将 Unified Attestation 方案推荐给了课题组。课题组基于 Unified Attestation，进行了一系列的扩展，比如刚才提到的统一接口，我们对接口名称、接口参数做了一些调整，去兼容更多的 TEE 方案，还有报告格式部分，以及校验规则里面的 TEE 平台属性抽象的合集，也做了更多的扩展。
目前我们已经支持了 SGX1、SGX2、HyperEnclave、Kunpeng Trustzone 以及 CSV 五种 TEE 方案，并且进行了多家单位参与的实际验证，证明我们的方案是可以实际落地的。
--
04/TEE 互联互通整体思考
除了核心的统一远程证明部分，我们还有更多关于 TEE 互联互通的想法。
目前研究课题里面我们提出了 5 层的分层模型。比如在具体可信执行方案之下，有一层异构体系结构层，大部分的 TEE 方案是和体系结构做绑定的。蚂蚁提出的HyperEnclave 方案，是基于虚拟化、硬件加密引擎以及硬件可信根等等一些安全原语，实现跨 CPU 兼容的 TEE 方案。在统一远程证明之上，我们也考虑如何构建统一的安全信道，以及数据安全传输协议，以及基于数据安全协议去传输什么样的数据内容，比如做数据格式的统一，这样可以进一步帮助 TEE 应用互联互通。
总结下来，我们认为 TEE 的互联互通分为两个阶段的工作。第一个阶段要解决 TEE 内部的问题，也就是异构 TEE 兼容性的问题。最开始蚂蚁提出的 Occlum LibOS 的方案，就是在解决异构 TEE 编程模型上的抽象兼容问题。我们提出统一远程证明方案，也是在实现异构 TEE 的远程证明流程的抽象，为 TEE 后续的互联互通提供基础。这部分工作，我们也计划开源出去，希望接入更多的 TEE 方案，从而实现更大生态范围内的 TEE 互联互通。
第二个阶段就是在 TEE 内部的兼容性问题解决之后， 更多考虑应用层面的互联互通，希望做到应用对 TEE 零感知。这里面包含我们用统一的数据传输协议，把远程证明的动作封装起来，这样用户甚至不用再关心 TEE 远程证明流程了。还有上层的应用层数据统一，以及我们跟其他隐私计算互联互通子课题提到的管理面接口层面方案做更好的融合，这样能够更好地实现 TEE 系统之间的互联互通，以及实现 TEE 系统和其他隐私计算系统之间的互联互通。我们希望未来的隐私计算互联互通技术能够真正实现 TEE MPC FL 技术无感知。
注 ：Unified Attestation 方案目前已经开源（++https://github.com/jinzhao-dev/jinzhao-attest++），欢迎大家共建和交流。
今天的分享就到这里，谢谢大家。
分享嘉宾
**
