分享嘉宾：张韬博士 腾讯 工程师
编辑整理：Liyao DataFun
出品平台：DataFunTalk

导读： 本文是由腾讯可信计算团队带来的分享，主题是大数据协同中的隐私与可靠性保护，将介绍数据分析场景下的一些安全性和应用性的冲突，比较几款简典的可信计算硬件。还将分享团队关于可信的分布式计算系统的一些想法和实践，并介绍结合区块链为可信的数据协同提供数据用法用量的存证和追溯的能力。

今天的介绍会围绕下面四点展开：

• 数据协同中的安全问题
• 可信执行环境(TEE) 简介
• TEE 上的分布式计算
• 区块链协调的数据协同

01 数据协同中的安全问题

在传统的数据协同场景中，我们通常会面临如下问题：

如果有多方数据协同，各参与方通常是把数据脱敏之后以明文的形式来汇合进行计算。虽然有脱敏过程，但是数据的一些关键特征仍然会公开给其他的参与方。在数据成为重要的生产资料，并且法律行业规范以及用户越来越重视个人信息保护的今天，这种做法就不再会被市场接受了。

但是也不能为了隐私保护而不去做协同。数据只在自己的私有环境中使用也会存在问题，单一平台无法获得全面的数据。比如在保险的风险评估中，关于经济能力的数据体现在银行或者金融机构的平台上，而身体健康相关的信息则体现在一些医疗机构的数据上。如果要全面评估投保风险，就需要结合医疗机构和金融机构两方的数据来进行联合分析。

传统的密码学算法，其实也能够提供一些隐私保护的数据协同，包括多方安全计算、MPC系列的算法、联邦学习以及同态加密，但是很多时候联邦学习会由同态加密和MPC算法来协同地去构造联邦学习的协议或算法。密码算法虽然有比较强的安全性等级和强大的协同能力，但是在使用时，普遍存在性能相对较低的问题，并且对于特定的场景，通常需要专门去设计密码算法或者密码学算法组成的协议，用来支持特定场景的隐私数据交互，这样就存在兼容性的问题，设计实践的成本就会比较高。

数据算力外包到其他的算力资源平台上，会存在分布式计算外包计算的情况。在这样情况下，数据会离开数据拥有者的环境去进行协同，数据的隐私保护也是相当重要的。

02 可信执行环境TEE简介

1. TEE安全特性

针对上述问题，为了解决安全性和应用性的冲突，可信执行环境可以提供比较好的解决方案。 可信执行环境在保护数据隐私和数据处理逻辑的完整性的同时，在性能方面也能提供与非可信环境相当的性能 。可信执行环境在计算过程中overhead是较少的，性能损耗只有百分之5到10左右的量级，是可以接受的性能损耗。

可信执行环境提供内存隔离以及内存的加密，使使用中的数据得到隐私保护 。在节点间协同时，可以使用传统的安全信道，比如说TLS协议或者应用层的加密来保护传输中数据的隐私。在持久化的场景，可信计算会有私有机制跟硬件派生出来的密钥来加密数据并且存储到可信域外。只有同一个可信应用才能够去解密这些数据，因此能够保证可信域内外的安全。

在可靠性方面，可信执行环境提供了远程证明， 可以保证可信应用的代码逻辑是没有被篡改的 。内存隔离也可以防止外部进程对运行中的可信进程进行状态的篡改，在最终结果输出时，可信执行环境可以为结果做签名或者MAC之类的认证，来证明结果确实是来自可信执行环境。

可信执行环境在机密性、可靠性和可用性上都能够兼顾。但也存在 缺陷 ，比如它的安全性是不可证明的，相对于密码算法安全性较低，但是是可以接受的安全性和可用性的折中方案。

2. TEE硬件

几种比较典型的可信执行环境硬件包括：

• Intel SGX

配套基础设施完善，有比较完善自洽的远程证明（IAS、DCAP），可以证明保证运行在可信环境内的可信进程的代码逻辑是没有被篡改的，是与用户审计过的代码一致的。Intel提供了比较完善的开发者接入的外围工具。并且其产品普及度比较高，服务器已批量生产，并且第二代SGX在内存资源和算力资源上都有大幅提升。

• ARM TrustZone

设计上与SGX有所不同，可信应用运行在TrustedOS上，有较强的信任假设，需要信任固件预置的TrustedOS，这样攻击面就相对更大一些。原生的TrustZone缺乏远程证明等基础设施，华为鲲鹏服务器上搭载了华为自研的远程证明机制。

• RISC-V Keystone/Sanctum、蓬莱

设计方案与SGX相似，安全性与可靠性也与SGX相当，但暂未推出成熟的服务器，市场普及度上还未达到商用的程度。

• AMD SEV

专注于虚拟机隔离场景，攻击面比SGX更大，但在牺牲一定程度的安全性的条件下，业务逻辑更容易接入。当前远程证明存在安全漏洞，不具备逻辑完整性的保护。寄存器、IO存在数据泄露的漏洞。资源调度仍然依赖Hypervisor，不能保证业务逻辑可靠性。

3. TEE接入方式

• TEE SDK

直接使用TEE原生SDK，SGX和TrustZone支持这种接入方式；应用级别接入，对业务有侵入式改造，虽然接入难度较大，但攻击面最小。

• libOS

借助库操作系统对指令集的转义，减少业务对硬件的感知；基础设施级别接入，业务少量感知，略微扩大了攻击面。

• 虚拟****化

包括用WebAssembly、Docker或VM接入，适用于AMD SEV；基础设施级别接入，业务可无感知，易用性上有提升，但扩大了攻击面。

03 TEE 上的分布式计算

使用TEE来打造协同计算能力， 首先要使可信节点间可以进行安全高效的通信 。

一般步骤就是每两个节点之间进行互相验证 ，保证与自己通信的其它节点都是安全可靠的。同时，交互时每两个节点间要协商出一个通信密钥，做加密和数据完整性的认证。用户在接入这种系统时，需要感知到他实际连接到哪一个硬件节点，实现远程证明，因此接入难度较大。并且交互复杂度会达到O(n^2^)，还需要维护其他节点信息。

为了解决多节点协同的问题，我们参考区块链分布式账本的存储理念，设计了一套 TEE节点间密钥共享的方案 ，在实现TEE节点协同计算，数据使用者无需感知实际对接的硬件或云虚拟机节点，透明接入。TEE算力也可以更灵活地在计算上进行调度。

结合以上密钥共享方案，我们 设计了TEE上的分布式计算系统 。首先要解决的问题是如何让分布式计算的框架去适配TEE硬件。以Spark为例，我们将其使用到的X86架构CPU指令改成对应的SGX的扩展指令，以此让Spark的节点运行在可信域中。在Spark架构中，参与数据的分发、计算的Driver、Executor节点需要接入前文提到的密钥共享方案，使业务数据密文能在这些节点间流通。用户在接入到Spark计算框架时，不需要感知到在与哪个可信硬件交互，只需要连接到被Spark框架调度到任意可信节点上的Driver，计算集群中的可信节点就都可以获得数据的解密能力，并且对接到密文数据库。

另外，我们 将可信计算远程证明的范围扩大到了Spark Executor代码逻辑 ，若是远程证明中发现Executor逻辑、版本与预期不符，则不会向这个Executor节点共享密钥。

在整个系统中，输入的数据和输出的数据都是加密的，为了配合分布式计算结构，数据存储会按字段加密，支持数据可拆分的能力。

上图将TEE与密码学算法在两个场景上进行了性能的比较。

首先在区块链隐私交易场景，不存在多节点协同问题，比对了基本的四则运算的性能。可以看到SGX隐私合约在性能上有着明显的优势。

第二个场景是隐私求交集的场景，也可以看到TEE的明显优势。

04 区块链协调的数据协同

TEE可以为数据协同提供隐私保护，同时保证计算过程的完整性和可靠性。而在数据的用法用量上，TEE则无法提供可追溯的监控机制。我们就需要引入区块链这样不可篡改的存证体系，来提供存证追溯的能力。常应用在数据交易中的计费，或数据使用中的审计、追责等场景中。

在系统中，分布式的计算集群要运行在可信执行环境内，配合密钥管理机制 。区块链可以运行在可信执行环境外，因为区块链本身并不存储大量的敏感数据，而只需要存储每次调度任务的状态和数据使用情况，这些数据在审计中是可以公开的。区块链对另外的使用者可以提供数据隔离，因此也不会存在审计数据泄漏的问题。

在发起任务时，可以将数据集哈希或签名存证到区块链上，在以后审计中可以通过哈希或签名来找到对应数据集，同时可以记录在任务中实际使用的数据量。

任务状态和结果上链，是为了后续监控以往任务的执行状况和准确度，以便动态优化计算集群中的模型。

这套设计方案应用在腾讯云数链通产品中（如上图架构所示） 。底层可信硬件包括Intel SGX和ARM TrustZone。区块链可以基于任何硬件去提供，我们仅对计算节点上的硬件做了限制。结合密钥管理和同步机制，可以用K8S将算力调度到不同的可信硬件上去。在区块链平台层，数链通支持长安链、Hyperledger Fabric或FISCO BCOS。分布式计算集群支持TensorFlow和Spark。

目前数链通的应用场景包括政务，各部门、各地区数据共享的场景，以及金融征信、风控等场景。

今天的分享就到这里，谢谢大家。

分享嘉宾

张韬 博士

腾讯计费平台部 工程师

张韬，密码学博士，研究领域主要包括密码学、隐私保护、匿名认证。以第一作者身份在领域内Top会议上发表过多篇论文。目前在腾讯主要负责区块链中的安全相关能力建设及可信计算相关协议、方案设计。