基于TEE的多客户端函数加密方案研究

Research on Multi-Client Functional Encryption Scheme Based on TEE

摘要: 随着云计算的兴起，对加密数据进行联合计算变的越来越重要。近年来，多客户端函数加密的发展使用户能够在不需要任何交互的情况下对私有输入进行联合计算。在云计算中，确保安全性与可靠性是极为重要的需求。针对多客户端函数加密方案出现的隐私安全问题，本文提出了一种基于TEE技术的去中心化多客户端函数加密方案。利用Python语言、开发环境PyCharm 2020.3.0版本、以及Python的PyCryptodome V3.10.1密码学库下对本文方案的关键算法或协议进行了仿真实验。综上试验结果及分析表明本方案在保障隐私安全的同时，具有较好的计算性能。这为在云计算环境中处理敏感数据提供了一种高效且安全的解决方案，因此具有一定的实际应用意义。

Abstract: With the rise of cloud computing, joint computing of encrypted data is becoming increasingly important. In recent years, the development of multi-client function encryption has enabled users to perform joint computations on private inputs without any interaction. In cloud computing, ensuring security and reliability is an extremely important requirement. Aiming at the privacy and security problems of multi-client function encryption schemes, this paper proposes a decentralized multi-client function encryption scheme based on Intel SGX technology. Using Python language, development environment PyCharm 2020.3.0 version, and Python PyCryptodome V3.10.1 cryptography library, the key algorithms or protocols of this scheme are simulated. In summary, the experimental results and analysis show that the scheme has good computational performance while protecting privacy and security. This provides an efficient and secure solution for processing sensitive data in the cloud computing environment, so it has certain practical application significance.

1. 引言

加密是用户在不安全的网络或存储站点上安全地共享数据的一种方法。在公钥密码学[1]出现之前，一个被广泛接受的观点是，两个用户之间想要秘密的进行通信，他们需要先建立一个互相都持有的秘密密钥$k$ ，即对称加密[2]。在传统的对称加密中，同一个密钥被用于加密和解密，这就要求通信双方在进行加密通信之前必须共享同一个密钥，这种方式对于一些小型组织来说是可以接受的，但是对于大型网络，比如由数十亿用户组成的Internet网络，显然是不可行的，因为密钥的分发和管理是一个复杂的问题。

函数加密(Functional Encryption, FE) [3]是一种新兴的加密范式，它以一种更加灵活的方式扩展了“All-or-Nothing”的公钥加密的要求，旨在解决传统加密方法无法提供的灵活性和功能性问题。函数加密的核心思想是允许对加密数据进行特定功能的计算，而不是只允许解密。然而，用户输入的数据可能很大，比如一个多维的向量，但函数加密的定义意味着输入的数据只能来自一方：即向量的所有坐标都是由一方提供的，并且是加密的。而在许多实际的应用场景中，数据可能是来自不同各方信息的集合，这些参与方之间可能互相并不信任。

多客户端函数加密(Multi-Client Functional Encryption, MCFE) [4]解决了前者独立生成密文的问题，采用去中心化的多客户端函数加密(Decentralized Multi-Client Functional Encryption, DMCFE) [5]来解决后者中心权威不可信时泄露客户端私有数据的问题。DMCFE移除了中央权威机构或主密钥。

一个理想的DMCFE方案，不仅要保障数据的机密性和完整性，还要满足抗攻击性和可用性的特点。而可信执行环境(Trusted Execution Environment, TEE) [6]可以很好的达到机密性和可验证性的需求，解决现有函数加密系统中出现的隐私安全和可实现性的问题。通过在TEE中执行DMCFE算法，可以确保用户数据在计算过程中得到安全保护，提高了数据隐私性，也相应提升了加密算法的可用性和实用性。

2. 技术背景

2.1. 加权阈值签名

椭圆曲线数字签名算法(Elliptic Curve Digital Signature Algorithm, ECDSA)，广泛用于保护数字信息的完整性和身份验证[7]。与传统的离散对数问题和大整数分解问题相比，椭圆曲线密码学因其抵御亚指数算法攻击的特性而在公钥密码学领域独具优势。以下是对ECDSA签名算法的形式化定义：

系统建立：输入安全参数，输出算法的公开参数$param=\left\{E,G,P,p,q,h\right\}$ ，其中，E为定义在有限域$F_q$ 上的椭圆曲线，p为一个素数，G为椭圆曲线上所有整数点构成的加法群，P和q分别为群G的生成元和素数阶，h为输入映射到$Z_q^{\text{*}}$ 域上的杂凑函数，即$h:{\left\{0,1\right\}}^{\text{*}}\to Z_q^{\text{*}}$ 。$Z_q^{\text{*}}$ 域由整数集合$\left\{1,2,\cdots ,q-1\right\}$ 构成。

密钥生成：输入算法的公开参数param，输出签名私钥d和验证公钥Q，其中$d\in Z_q^{\text{*}}$ 为随机秘密值，公钥$Q=dP$ 公开可见。

签名生成：输入算法的公开参数param、用户私钥d和待签名消息m，输出签名$\sigma =\left(r,s\right)$ 。步骤如下。

1) 选择一个随机数$k\in Z_q^{\text{*}}$ ，计算$R=k\cdot P=\left(r_x,r_y\right)$ ，其中$r_x$ 和$r_y$ 分别为椭圆曲线上点R的横坐标和纵坐标。

2) 计算$r=r_x\mathrm{mod}q$ ，若$r=0$ ，则返回步骤(1)；否则，执行步骤(3)。

3) 计算$s^{\prime }=k^{-1}\left(e+dr\right)\mathrm{mod}q$ ，其中，$e=h\left(m\right)$ 为消息摘要。

4) 输出签名信息$\sigma =\left(r,s\right)$ ，其中$s=\min \left\{s^{\prime },q-s^{\prime }\right\}$ ，$\min \left\{\right\}$ 函数表示取集合中较小的数值。

签名验证：输入待验证的消息m和签名$\sigma$ ，输出验证结果“1”或“0”。具体步骤如下：

1) 解析签名$\sigma$ 获得$\left(r,s\right)$ ，计算摘要$e=h\left(m\right)$ 。

2) 计算$R_v=s^{-1}\left(eP+rQ\right)=\left(x_v,y_v\right)$ 。

3) 若$r=x_v\mathrm{mod}q$ ，输出1；否则输出0。

2.2. 多客户端函数加密

MCFE是一种密码学技术，旨在允许多个客户端合作执行加密计算，而不必暴露原始输入或中间结果[8]。这种技术通常涉及将计算任务分解成多个部分，然后由不同的客户端处理各自的部分，最终得到加密的结果。这样的方法有助于保护数据隐私，因为每个客户端只需处理其分配的部分，而无需了解整个计算的细节。MCEF常用于安全多方计算(Secure Multi-Party Computation, SMPC) [9]，其中多个参与方合作执行计算，同时保持输入数据的隐私。

MCFE：一个在一组包含n个发送方的消息M上的MCFE由以下四个算法组成：

1) $\text{Setup}\left(\lambda \right)$ ：输入安全参数$\lambda$ ，输出公共参数mpk、主密钥msk和n个客户端的加密密钥$e{k}_i$ ；

2) $\text{Encrypt}\left(e{k}_i,x_i,\ell \right)$ ：输入用户的加密密钥$e{k}_i$ ，要加密的值$x_i$ ，和一个标签$\ell$ ，输出密文$C_{\ell ,i}$ ；

3) $\text{DKeyGen}\left(msk,f\right)$ ：输入主密钥msk，函数$f:M^n\to R$ ，输出函数解密密钥$d{k}_f$ ；

4) $\text{Decrypt}\left(d{k}_f,\ell ,C\right)$ ：输入函数解密密钥$d{k}_f$ ，标签$\ell$ 和一个n维的密文$C$ ，如果$C$ 是关于标签$\ell$ ，$x={\left(x_i\right)}_i\in M^n$ 的有效加密，则输出$f\left(x\right)$ ；否则输出⊥。

正确性：假设mpk包含在msk中，同时也包含在所有的加密密钥$e{k}_i$ 以及函数解密密钥$d{k}_f$ 中。正确性属性表明，给出$\left(mpk,msk,{\left(e{k}_i\right)}_i\right)\leftarrow \text{SetUp}\left(\lambda \right)$ ，对于任何标签$\ell$ ，任何函数$f:M^n\to R$ ，和任一向量$x={\left(x_i\right)}_i\in M^n$ ，如果$C_{\ell ,i}\leftarrow \text{Encrypt}\left(e{k}_i,x_i,\ell \right)$ ，$i\in \left\{1,\cdots ,n\right\}$ ，函数解密密钥$d{k}_f\leftarrow \text{DKeyGen}\left(msk,f\right)$ ，那么$\text{Decrypt}\left(d{k}_f,\ell ,C_{\ell }={\left(C_{\ell ,i}\right)}_i\right)=f\left(x={\left(x_i\right)}_i\right)$ 。

3. 提出的方案

3.1. 方案的模型和形式化定义

本方案定义的系统模型如图1所示，其中包含了两类参与的实体，分别是客户端应用程序(Client Application, CA)和解密节点云平台(Decryption Node Cloud Platform, DNCP)，其中解密节点云平台又包括解密飞地(Decryption Enclave, DE)和函数飞地(Function Enclave, FE)。各实体的具体职责如下：

Figure 1. System model diagram

图1. 系统模型图

1) 客户端平台(Client Application)：由于本方案是去中心化的，没有可信第三方用于生成函数解密密钥以及系统所需的参数，因此在本文方案中，客户端负责系统的初始化过程，生成DMCFE算法所需要的私钥、加密密钥、密文以及解密密钥的验证密钥和公开参数。此外，还负责生成加权阈值ECDSA签名算法的签名密钥和验证密钥，用于在函数授权阶段使用签名密钥对函数F执行授权。

2) 解密节点云平台(Decryption Node Platform)：

解密飞地(DE)：DE与客户端平台通过远程认证的方式建立起一个安全信道，将在客户端生成的函数解密密钥通过安全信道传输到DE中，由于客户端生成的验证密钥是公开可见的，因此在DE中使用验证密钥对客户端生成的函数解密密钥执行验证。此外，对函数F的签名也在DE中使用签名算法生成的严密密钥进行验证。

函数飞地(FE)：由于FE与DE位于同一平台，因为FE与DE之间通过本地认证的方式建立起一个安全信道，DE将验证通过的函数解密密钥通过安全信道传输到FE中，除此之外，客户端通过与FE远程认证建立起安全信道，将在本地加密的数据通过安全信道传输到FE中，由密文的验证密钥在FE中对密文进行验证，若验证通过，将在FE中对密文执行解密算法，最后生成关于明文信息x的函数值$f\left(x\right)$ 发送给客户端。

3.2. 方案的具体构建

1) 系统初始化阶段

$\text{HW}\text{.Setup}\left(1^{\lambda }\right)\to params$ ：在系统初始化阶段，解密节点平台DN对HW安全硬件执行$\text{HW}\text{.Setup}\left(1^{\lambda }\right)$ 并记录输出的参数params。

$\text{Setup}\left(\lambda \right)\to pp$ ：在系统初始化阶段，由客户端平台运行初始化算法，生成全局公开参数pp以及客户端本地的公私钥对。各实体通过公共参数执行密钥生成算法生成各自的公私钥对。

2) 密钥生成阶段

${ℱ}_{Gen}\left(1^{\lambda },T,t\right)\to \left(vk,\left\{{\left[sk\right]}_i\right\}\right)$ ：本文的加权阈值ECDSA签名方案从将秘密签名密钥sk在所有参与方之间进行加权随机秘密共享(WRSS)开始。

$\text{VDMCFE}\text{.KeyGen}\left(\lambda \right)\to \left(s{k}_i,e{k}_i,v{k}_{CT},v{k}_{DK},pk\right)$ ：VDMCFE的密钥生成输入安全参数$\lambda$ ，输出私钥$s{k}_i$ 、加密密钥$e{k}_i$ 、密文的验证密钥$v{k}_{CT}$ ，函数解密密钥的验证密钥$v{k}_{DK}$ ，以及公钥pk。用于后续对数据的加密、函数解密密钥的生成，密文及密钥的验证等。

3) 函数授权阶段

加权阈值ECDSA签名算法将签名协议分为两个阶段：一个预签名协议，仅依赖于签名密钥的份额，另一个是依赖于实际消息的非交互式签名协议。客户端发出函数请求F，对F执行签名。

4) 加密阶段

$\text{VDMCFE}\text{.Encrypt}\left(e{k}_i,x_i,\ell ,m\right)\to C_{\ell ,i}$ ：客户端在本地执行加密算法，利用加密密钥$e{k}_i$ 对本地数据进行加密，客户端与FE通过远程认证的方式建立安全信道，生成的密文通过安全信道传输到FE中。

5) 解密密钥的生成及验证阶段

$\text{VDMCFE}\text{.DKeyGenShare}\left(s{k}_i,{\ell }_y,m,pk\right)\to d{k}_{i,y}$ ：客户端在本地执行函数解密密钥生成算法，利用私钥$s{k}_i$ 生成函数解密密钥$d{k}_{i,y}$ ，与DE通过远程认证建立起安全信道，客户端将函数解密密钥$d{k}_{i,y}$ 发送到DE，在DE内执行密钥的验证算法。

6) 密文的验证及解密阶段

$\text{VDMCFE}\text{.Verify}\left({\left(C_{\ell ,i}\right)}_{i\in \left[n\right]},v{k}_{CT},m\right)$ ：客户端对本地数据加密生成的密文，通过与FE远程认证建立的安全信道，将$C_{\ell ,i}$ 传输到FE。由$v{k}_{CT}$ 在FE内对$C_{\ell ,i}$ 执行验证，验证通过后，DE与FE通过本地认证的方式建立起安全信道，DE将解密密钥$d{k}_{f,i}$ 传输到FE，在FE内对密文解密，最后解密结果值$F\left(x\right)$ 发送给客户端。

4. 实验

4.1. 仿真设计

本方案运行在Intel Skylake i7-6700处理器，主频为3.40 GHz，内存为8 GiB的RAM，安装有Windows Server 2012 R2标准操作系统的平台上测试了原型实现。编程语言和版本Python 3.8、开发环境PyCharm 2020.3.0版本、以及Python的PyCryptodome V3.10.1密码学库下对本文的方案进行了仿真实现，并使用了Intel (R) SGX SDK 1.6和Intel (R) SGX PSW 1.6附加组件，给出了核心算法或协议的代码及运行结果。客户端仿真示意图如图2所示。

Figure 2. Client simulation diagram

图2. 客户端仿真示意图

在仿真实验中首先定义了RSA公钥加密类[10]、RSA签名类[11]及ECDSA签名类[12]。

1) 系统初始化阶段：客户端执行系统初始化Setup算法，生成全局公共参数，以及各个实体根据公共参数输出各自的公私钥对。如下是客户端执行初始化算法的核心代码，其执行结果如图3所示。

Figure 3. Result graph of client execution initialization algorithm

图3. 客户端执行初始化算法结果图

2) 签名密钥的生成阶段：客户端执行加权阈值ECDSA签名算法，生成各自的签名密钥和验证密钥。如下是客户端执行ECDSA签名算法的密钥生成阶段核心代码，其执行结果如图4所示。

Figure 4. Result graph of ECDSA key generation algorithm executed by the client

图4. 客户端执行ECDSA密钥生成算法结果图

3) 函数授权阶段：用户发送函数请求F，客户端使用各自的签名密钥对函数F执行签名授权过程。如下是客户端执行ECDSA签名算法签名阶段的核心代码，其执行结果如图5所示。

Figure 5. Result graph of ECDSA signature algorithm executed by the client

图5. 客户端执行ECDSA签名算法结果图

4) 客户端加密阶段：客户端使用加密密钥对本地数据进行加密，生成密文ct发送到函数飞地。如下是客户端执行加密算法的核心代码，其执行结果如图6所示。

Figure 6. Result graph of client executing encryption algorithm

图6. 客户端执行加密算法的结果图

5) 函数解密密钥生成及验证阶段：客户端使用自己的私钥生成部分函数解密密钥，并将函数解密密钥通过安全信道传输到解密飞地，在解密飞地内执行验证。如下是客户端执行函数解密密钥生成算法的核心代码，其执行结果如图7所示。

Figure 7. Result graph of decryption key generation algorithm for client execution function

图7. 客户端执行函数解密密钥生成算法的结果图

6) 密文解密阶段：函数解密密钥通过本地认证传输到函数飞地，在函数飞地内对密文执行解密，最后生成的函数值f(x)发送给客户端。如下是函数飞地执行密文解密算法的核心代码，其执行结果如图8所示。

Figure 8. The result graph of the function enclave executing the ciphertext decryption algorithm

图8. 函数飞地执行密文解密算法的结果图

4.2. 性能测试

本文设计的方案计算了VDMCFE-HW.Setup，VDMCFE-HW.Keygen，VDMCFE-HW.Encryption，VDMCFE-HW.VerifyCT，VDMCFE-HW.DKeyGenShare，VDMCFE-HW.VerifyDK，VDMCFE-HW.DKeyComb和VDMCFE-HW.Decrypt算法的平均时间和标准差。表1包含了VDMCFE.Setup和VDMCFE.KeyGen算法运行的时间。

Table 1. VDMCFE algorithm runtime

表1. VDMCFE算法运行时间

创建飞地	52 ms
VDMCFE.Setup	2.1675 ms
VDMCFE.KeyGen	2.1781 ms
VDMCFE.Encrypt	2.1889 ms
Total	58.5345 ms

本方案评估了三种函数加解密算法的性能，分别是基于身份的加密(IBE)、order revealing encryption (ORE)和三输入DNF (3DNF)。为了展示原语的SGX辅助版本在性能上与纯加密版本(如配对的IBE、DNF和多线性映射3DNF)的比较，本文选择这些函数进行研究。表2总结了三种函数的解密时间，包括解密过程三个主要ecalls所花费时间的细分：创建飞地、DE本地认证、解密密文和函数评估。

Table 2. Time comparison of IBE, ORE, and 3DNF algorithms

表2. IBE，ORE和3DNF算法时间对比

Functionality	IBE [13]	ORE [14]	3DNF [15]
create enclave	13 ms	18.9 ms	17.6 ms
local attest	1.4 ms	1.6 ms	1.5 ms
decrypt & eval	0.89 ms	0.71 ms	0.84 ms
Total	15.29 ms	21.21 ms	19.94 ms

如表2所示，对于每个函数来说，创建enclave所需的时间比解密和评估它所需的时间长两个数量级。一旦函数enclave被创建并且对DE的本地认证完成，同一个enclave可以用来解密任意数量的输入密文元组。因此，对许多密文或密文元组进行解密的摊销成本远低于对单个输入进行解密的成本。在下图9中显示了对包含1000个输入的密文元组进行解密的摊销成本。

Figure 9. The average cost of decrypting 1000 ciphertext tuples

图9. 输入1000个密文元组运行解密的平均代价

实验数据表明，通过在计划平台上对IBE的解密时间进行测量，可获得关键结果。本研究还包含提出了基于ORE和3DNF相关的5Gen解密时间性能指标。本文认为无需在本方案平台上对ORE和3DNF的5Gen实施进行评估，因为它们相较于本方案基于SGX的实施而言性能慢了四个数量级。本系统成功地实现了多输入函数，使得原语的构建成为了可能。在没有安全硬件的情况下，这些原语此前无法被用于实际应用，本文方案填补了这一空白。

5. 结论

本文通过对目前函数加密方案中存在的安全及信任问题深入分析，并在可信执行环境的基础上提出了基于SGX的去中心化多客户端函数加密方案。本文通过引入DMCFE、加权阈值签名算法与上述SGX机制相结合来设计并实现安全方案。该方案旨在使用户代码及数据在分布式计算过程中始终保持加密状态，只有在可信执行环境中才解密执行，从而达到不向任何参与方透露信息的目的。最后基于Python语言、开发环境PyCharm 2020.3.0、以及Python的PyCryptodome V3.10.1密码学库对本文的方案进行了仿真实验。最后从计算代价、通信代价上对本方案关键算法的性能进行了对比分析。实验结果表明，本文提出的安全方案可以保证用户数据在分布式计算中的安全性，基本实现了预期目标。