本文作者

关杏元：华夏银行新技术研究中心应用技术负责人

陈浩栋 黄淼：北京冲量在线科技有限公司

**一、为什么需要可信执行环境 TEE 的互联互通？**数据对于信息化社会的建设而言，其重要性如同工业化建设中的石油一样不言而喻。无论是城市治理、金融风控、医药研究还是公众生活的方方面面，数据资源的流通和利用都将如石油一样为数字社会发展提供源源不断的能量。在过去，受限于数据安全和隐私信息保护等众多顾虑，社会上数据在不同机构间的共享与协作始终无法在合法合规且充分保护公民的前提下大规模开展。近年来，随着隐私计算思想的发展与成熟，为解决这一矛盾提供了一条可行的技术路径。可信执行环境 Trusted Execution Environment（以下简称 TEE）就是隐私计算技术中的典型代表之一，因其优异的性能和强大的可拓展性在政务、金融、运营商等众多场景中得到了广泛应用。TEE 技术以基于 CPU 硬件生成的可信任根为基础，实现了对隐私数据完整性和安全性的全面保护，可以抵御操作系统甚至是 BIOS 级别的入侵。由于 TEE 技术对于硬件信任根的依赖，因此不同芯片厂商对于 TEE 技术的支撑和实现就变得至关重要。TEE 技术发展至今，出现了 Intel SGX、ARM TrustZone、AMD SEV、Intel TXT 等多种技术架构，国内的芯片厂商如海光、兆芯、飞腾、鲲鹏等也纷纷推出了如 Hygon CSV、ZX-TCT、FT-TrustZone 等完全自主可控的 TEE 技术实现，并且集成到了各自面向市场的主流 CPU 芯片产品中。多样化的 TEE CPU 芯片市场给了应用该技术的需求方更加灵活自主的选择空间，大部分情况下都无需为了部署基于 TEE 的服务而准备额外的硬件，且能够满足政府、军工、银行、运营商等关键系统的信创需求。冲量在线作为国内领先的隐私计算服务商，在落地和应用 TEE 技术的过程中发现不同架构芯片混合使用的情况在大部分机构和企业中普遍存在，特别是在数据中心已经成熟的银行业务，他们在过去都大规模使用国外 X86 架构芯片，而在信创大背景下开始增加国产芯片的采购。如何充分利旧已有资源并将新增资源快速投入生产使用，成为了机构与企业在建设信息系统时的重要考量，而面向数据共享与使用的隐私计算平台也不例外。如何实现 TEE 在不同芯片架构之间的互联互通、降低 TEE 技术在跨机构协作中的落地成本、充分发挥各类芯片在不同场景中的算力优势，并能够利用已有的大规模算力储备，提供超大规模数亿数量级的数据流通和联合建模能力，这些都是 TEE 在推广应用中亟待解决的问题。 通过与合作伙伴的联合探索，冲量在线已经推出了一套面向不同 TEE 可信硬件的互联互通解决方案，并在运营商、金融、政务等场景中率先开展了落地实践。

二、TEE 互联互通技术方案的核心需求与难点

TEE 互联互通方案基于多种不同的 TEE 硬件，该方案可以类比为由 TEE 模块构成的微服务，在保障数据互联和隐私计算中各个业务模块的功能和运作方式保持一致的情况下，通过不同 TEE 硬件支持的开发语言和系统环境来进行实现。 硬件差异给上层业务模块带来的影响，主要体现在跨 TEE 间的交互方面。通常来讲，同构 TEE 模块之间的交互主要是解决以下 2 个问题：a. TEE 模块之间的互认证，确认对端 TEE 模块的身份以及通过远程验证确认 TEE 模块的安全性b. 根据应用层的 API 接口进行通信异构 TEE 兼容方案，需要在不同 TEE 模块之间的交互过程中同样解决以上 2 个问题。即系统需要提供异构 TEE 远程验证机制和应用层统一接口规范，这其中异构 TEE 的远程验证相对而言有更高的技术复杂度。

三、融合区块链实现去中心化的跨厂商 TEE 互认证

远程验证 RA (Remote Attestation)是可信执行环境机密计算中的关键技术之一，提供了一种远程审计设备可信状态的手段。目前主流的计算芯片厂商发布的 TEE 技术，如国产海光、国产兆芯、国产飞腾、国产鲲鹏、Intel、AMD、ARM 等，各类 TEE 的验证方法会有差异，但远程验证的标准流程是统一的：1. 第一步：挑战者发起认证请求；2. 第二步：待认证 TEE 平台根据自身 TEE 技术，生成独特的 TEE 认证报告；3. 第三步：返回认证报告给挑战者；4. 第四步：挑战者根据待认证平台的 TEE 技术类型，校验认证报告；

可以看到，远程验证在技术上采取的是挑战响应的模式，对于异构 TEE，只需根据不同 TEE 技术的要求，把生成报告和验证报告的逻辑一一对应即可。

生成的报告内会包含应用的度量值以及相关信任根的签名，验证报告时对度量值以及信任根签名做校验即可。

由于需要不同的 TEE 之间互验证，涉及到不同 TEE 的验证机制。如果不改动系统架构，那么各方的 TEE 模块都要集成多套验证逻辑。一方面这会造成互验证的工程复杂度提高，另一方面也不利于系统后期维护。若系统需要新增一类 TEE 节点，那么需要所有 TEE 节点升级来支持新的 TEE 远程验证逻辑。为了解决上述问题，可信计算平台独立出一个 TEE 远程验证代理模块 validator。由这个模块收敛所有远程验证差异化逻辑，其他 TEE 端借助 validator 模块完成与对端的远程验证。使得各个 TEE 端不需要特别地兼容异构 TEE 的认证逻辑。validator 本身是由 TEE 实现的，以此保证其自身验证逻辑的正确性。而各个 TEE 端在交互通信前，需要向对端发起远程验证。远程验证由 validator 代理完成，远程验证的结果由 validator 进行背书确认。由于各个数据参与方同时也是联盟链的成员机构，彼此之间可通过联盟链存证监管与审计数据。validator 对系统内各方所有 TEE 节点采取白名单验证机制，验证过程中验证报告需要与节点度量预期值、节点身份、TEE 背书身份进行校对。这些签注信息、度量信息可去中心化存证在联盟链中。如此可保证验证过程中所有静态输入都可被各个参与方监督检查。以此改造，可以将 N（N 个节点）x N（N 套远程验证机制）的工程复杂度压缩到 N（N 个节点）x 1 (1 套远程验证机制）。

四、跨厂商 TEE 远程验证流程

具体的远程验证机制说明如下（以 SGX 节点与海光 CSV 节点的双向远程验证为例，本方案可支持主流的计算芯片厂商发布的 TEE 技术，包括国产海光、国产兆芯、国产飞腾、国产鲲鹏、Intel、AMD、ARM 等）： (1) 在异构 TEE 节点接入时，需要进行节点注册，获取 Validator 根证书以及用于远程验证的 AK 证书（下图灰色流程块）； (2) 双向远程验证是两个异构或者同构 TEE 节点互相进行远程验证的过程，类似于 TLS 双向认证，以海光节点验证 SGX 节点的单向认证为例来说明（上图蓝色流程块）； (3) 海光节点作为挑战者，向 SGX 节点发起远程验证，并附加一个随机 nonce 以防止重放攻击； (4) SGX 节点随即先生成一份 Intel SGX 类型的本地报告，然后把此报告以及 TEE 类型、nonce 值、AK 证书、使用 AK 证书对应的私钥对请求的签名一并发给 Validator，以此来请求 Validator 对本地报告背书并给出远程验证报告； (5) Validator 收到请求后，首先会验证 AK 证书以及签名，从而确认请求节点的合法性，然后根据 TEE 类型，调用对应的验证逻辑对本地报告进行验证，最后再使用 Validator 根私钥对本地报告以及 nonce 签发一个远程验证报告，此报告内包含：Validator 根证书的签名、本地报告、nonce 值，并把此远程验证报告返回给 SGX 节点； (6) SGX 节点拿到 Validator 背书的远程验证报告后，可以使用在节点注册阶段获取的 Validator 根证书验证下报告的签名，确认未被篡改，然后把此报告返回给挑战者海光节点； (7) 海光节点收到 SGX 节点的远程验证报告后，只需要在本地使用 Validator 根证书验证下报告的签名，并确认 nonce 与之前发给 SGX 节点的一致，即可完成对 SGX 节点的远程验证； (8) 对于 SGX 节点验证海光节点（上图绿色流程块），流程与海光节点验证 SGX 节点基本一致，差异仅在于节点生成本地报告环节以及 Validator 验证报告环节，对于海光节点，生成的报告是海光独有的格式，而 Validator 在验证时，会根据海光的验证逻辑进行验证。

五、TEE 互联互通解决方案的核心优势

1>效率提升：支持用户已有算力的再次利用2>灵活度高：可根据数据流通的场景需要灵活选择 TEE 方案，发挥各自方案的差异化优势3>用户友好：不同厂商提供的 TEE 方案可以互联互通，共同参与数据流通，用户不需要另行单独采购4>性能优越：可支持超大数据量的机器学习建模，支持跨网跨域通信

六、国产化芯片 TEE 技术的进展