1. 背景介绍

为了控制风险，银行、证券、保险等机构需要在传统央行征信系统之外获取客户消费，小额信贷等额外标签数据作为风险控制的补充数据。这就形成了金融客户的外部数据采购需求。但是在数据采购时由于合规性要求以及保护自身商业机密的需要，金融机构往往无法输出其客户的ID、手机号等敏感信息（以下简称ID），否则客户信息可能泄露，造成用户信息为不法分子或者竞争对手利用。而在没有任何可关联信息的情况下，数据的供应方又无法了解金融机构要买什么数据，这就形成了供需的矛盾点。对于小型供应商而言，只能将自己所拥有的数据全数供应给银行，而银行获得数据后往往觉得这些数据的价值不大。对于拥有高价值数据的大型供应商而言，将自身全量数据卖给银行，风险和收益又不成正比。因此出现了数据供应方和需求方都想进行数据交易，而由于安全原因交易却无法实现的局面。

这种情况使得金融行业用户难以获得高价值的外部数据源，进而制约了其通过数据创新驱动业务发展的能力。例如银行开展小额信贷的场景中，如果依赖的外部数据源质量不高则会影响风控的效果。为了解决金融数据共享的矛盾，我们(TalkingData)设计了一套基于密码技术(cryptology)的既可以保护数据需求方商业机密又保障数据供应方数据安全同时还可以精确计量数据使用的数据共享方案。该方案具有安全、公平、实时、高效的特点，可以满足金融机构实时采购外部数据的需求。

2. 概览

2.1 问题分析

从上述背景介绍中可以看出，解决问题的关键是提供这样一种机制，在数据需求方不提供任何查询ID相关标识的情况下，数据供应方可以提供与待查ID相关的属性（标签）信息。那么这就需要供应方要么在每次查询时实时返回全量数据，让需求方自己挑；要么将全量数据预置到需求方一侧，让需求方自己挑。由于效率的原因，第一种方式在实际场景中很难应用。第二种方式则会对数据供应方带来以下挑战：

a) 在满足需求方使用要求的同时保证预置数据集中非银行客户的数据安全；
b) 双方同时认可的精准数据使用量计量；

只有解决了上述挑战，才能解除数据供应方的担忧，为金融行业的用户引入高质量的数据源。

2.2 如何破局

为了应对前述问题和挑战，我们针对交付的数据集以及供需双方必要的交互数据，提出了如下的设计。

首先，数据供应方需要对待交付的数据集进行预处理（为了简单起见，这里假设数据供应方的数据只有设备ID和对应的若干标签，其中设备ID可以以明文的方式给出，以便需求方进行选择；数据需求方感兴趣的数据是标签）。预处理主要是使用只有供应方知道的密钥对标签进行加密，然后就可部署到数据需求方一侧，完成交付。
其次，当数据需求方需要获取感兴趣的设备ID对应的标签时，将挑选出来的标签密文使用只有自己知道的密钥再次进行加密并回传给数据集对应的供应商，供应商对回传数据进行解密处理并将中间结果作为响应返给数据需求方；数据需求方在收到响应后再进行一次解密处理就可以获取所需的标签数据。

上述过程如下图所示：

到这里，各位看官就会有疑问了，既然供应商不知道数据内容，那么他是如何做到正确解密？我们都知道乘除法满足交换律，对一个数先乘后除还是反过来都不影响最终结果。假设明文是数字5，供应方先乘以4（加密），将得到的20交付给需求方，当需求方想知道20的明文时，先将20乘以8（二次加密），再将结果160提交给供应方；供应方这时显然已经不知道160代表什么，但是他知道这个数乘过4，所以他就用4除（解密），得到40返给需求方，需求方再将40除以8（二次解密）最终得到明文5。

可能各位又要问了，需求方只需比较一下提交给供应方的160和返回的结果40或者将明文5与收到的交付数据20进行比对不就可以知道供应方的秘密4了吗？这里先卖一个关子，我们实际实现时是通过选取两种支持“交换律”的高强度算法，并通过一系列操作确保需求方无法反推出供应方的秘密的，感兴趣各位可参考后面的原理部分。

2.3 效果分析

接下来我们简单分析一下是否能够达到设计预期，或者说能否解决数据共享中面临的问题和挑战：

部署到数据需求方一侧的数据集是经过加密，所以只要选择的加密算法强度足够高且供应方不泄露自己的密钥，数据需求方是无法破解标签密文的；
在交互过程中数据需求方没有主动泄露商业秘密，由于数据挑选的过程是在需求方一侧内部完成，并且与供应方交互的数据也不是由ID生成，因此不存在泄露的风险；
数据供应商无法猜测交互数据对应的ID，因为供应商收到的数据是经过需求方二次加密处理的，只要需求方选择的加密算法强度足够高且需求方不泄露自己的密钥，供应方同样是无法进行破解的，只要无法破解，供应商就无法根据自己的数据集去猜测需求方要查询的ID；
供需双方可以在毫无互信的情况下完成数据的交易，并且由于存在必要的交互，所以供应方可以做到精准计量；
交互过程中的数据经过了加密处理，而且没有ID相关的信息，所以即使被第三方监听到也毫无用处，而且第三方也无法进行篡改。这个机制也就保障了数据可以实时更新。

当然这里还有一个遗留问题，供应方交付的数据集中包含了明文形式的ID，那么如何解决供应方的ID也匿名化后，需求方还能正确挑选标签的问题？由于篇幅的问题，这部分的介绍我们在另外的文章中给出。我们称之为供应方匿名方案。

3. 方案原理

本文前半部分简单描述了如何实现在数据需求方不提供ID的情况下获取相关数据的过程，后面的内容则是通过科学严谨的论述解释其中的原理。

3.1 密码基本概念

为了论述方案的原理，我们首先定义几个基本概念，这些概念可以帮我们更容易理解如何在不泄露自身信息的情况下，获取外部信息。

3.1.1 加密算法

加密至少包括一个加密算法，一个解密算法。在密钥key的帮助下，加密算法把明文m转换成密文c，解密算法把密文c转换回明文m。加解密可以用下面的公式表示：
加密(Encrypt)：E(m,key)->c解密(Decrypt)：D(c,key)=D(E(m,key),key)->m

3.1.2 同态加密

如果一个加密算法，对它输出的密文做计算后再解密得到结果，与先加密再解密后进行同样的计算得到的结果相同，则称该加密算法具有同态性。

假设函数f()代表某种计算，对数据m有f(m)->n。如果加密算法(E,D)满足：E(m,key)->c，f©->d，D(d,key)->n，则该加密算法为同态加密算法。我们可以简单把同态看做中学数学中的交换律，差别是交换律针对加法或者乘法这种只有一个步骤的简单运算，同态可能有多步计算。进一步的，有两个加密算法：

加密：E1(m,keya)->ca
解密：D1(ca,keya)->m
加密：E2(m,keyb)->cb
解密：D2(cb,keyb)->m
对于经过E1和E2顺序加密得到的密文cb=E2(E1(m,keya),keyb)，如果有m=D1(D2(cb,keyb),keyb)=D2(D1(cb,keya),keyb)，我们称这两个加密算法具有同态性，也就是说这两个算法的解密顺序可以交换。比如4个正整数a,b,c,d,我们有ab/c/d = ab/d/c

3.1.3 概率加密

使用概率加密算法对一个明文加密两次后，会产生不同的密文。
第一次加密：E(m,key)->c1，对应的解密D(c1,key)->m
第二次加密：E(m,key)->c2，对应的解密D(c2,key)->m
第三次加密：E(m,key)->c3，对应的解密D(c3,key)->m
…
从外部看，拿到c1，c2是无法区分它们是一个明文m生成的还是另一个明文m’生成的。概率加密从语义上看是安全的，可以防止选择明文攻击。

3.2 具体实现

假设m1,…,mn代表供应方提供的供需求方选择的标签。

第一步，供应方使用加密算法E1对所有标签加密生成与m1,…,mn对应的标签c1,…,cn，key是它自己选择的密钥。c1,…,cn被发给银行。

第二步，需求方选择它希望获得的标签mi对应的密文ci，使用加密算法E2对其加密生成二次加密后的密文ci*，并将ci*发给供应方。

第三步，供应方使用解密算法D1解密ci*得到ci**，并将ci发给需求方。假设两个加密算法是同态的，则D1解密正好抵消E1加密，得到的结果ci相当于E2加密的密文。

第四步，银行用D2解密ci**，获得自己想要的mi。

注意，这里描述的过程并不包含需求方如何知道哪个mi是自己要选择的，这需要每个为mi配ID，进而造成供应方信息的泄露。该问题会由供应方匿名方案解决。

我们把上面的加解密过程以简单的“乘除法”来代替，方案的过程如下图所示：

3.3 方案安全性分析

方案通过下面两个性质保证在需求方获取想要的mi的同时，供应方无法获取任何需求方所选mi有关的信息。

不可区分性：给定任意两个银行用E2加密生成的密文ci和cj，以及生成他们的原始密文ci和cj，供应商无法区分ci和cj分别是由ci还是cj生成。
非关联性：供应商在不关联ci*的情况下可以生成ci**。

不可区分性通过概率加密实现：
只要方案中选用的加密算法(E2,D2)是概率加密算法即可保证供应商收到的密文c*是不可区分的。

非关联性通过同态加密实现：

第一步E1加密的结果ci是与m关联的部分，经过第二步E2加密后关联性已经被概率加密消除，如果第二步的E2加密与第一步的E1加密具有同态性，则E2加密不影响第三部D1解密，进而供应商可以在无需关联ci*与ci的情况下生成ci**。最后m再用 D2解密。这里的m可以是标签，也可以是后续操作中加密标签的中间密钥。

同样的，只要方案中选用的加密算法(E1,D1)是概率加密算法即可保证银行收到预置密文c和解密密文c**都是不可区分的。

由于每次获取ci**需要供应商参与，数据交易的计量是精确的，也就是供应商虽然不知道银行获取了哪个mi，但它知道银行获取了一个mi。

3.4 相关算法选择

我们选用支持同态乘特性的ElGamal算法和RSA算法作为具体实现。由于两种算法都是业界公开的算法，介绍的文章有很多，这里就不展开，下面主要描述我们选择这两种算法的考量。

可行性：我们看这两个算法的计算过程可以发现，ElGamal和RSA的加解密过程都只包含模乘法运算，对明文m先做ElGamal加密，再做RSA加密后的密文，先做ElGamal解密后做RSA解密和先做RSA解密后做ElGamal解密得到的结果是相同的。也就是说按照前面同态加密的定义，他们具有同态性，符合做(E1,D1)和(E2,D2)算法的条件。
安全性：ElGamal和RSA本身都是久经考验的概率加密(朴素RSA虽然不是概率的，但可以通过随机填充改造为概率的)算法，无论是在理论界还是在工业界基本没有人质疑他们本身的安全性。我们只使用ElGamal和RSA的组合而没有为我们的特定目标而创立算法的好处是我们自己不必去证明他的安全性；同时，即使是没有任何安全基础的用户在明白原理后，也容易相信方案的安全性。此外，在需要取得相关安全认证时，我们只需去认证方案，而不用去认证新密码算法。注意，这两种认证的流程和难度是差别非常大的。在金融领域，特定公开机构的认证是采购流程所必须的。
效率：首先，方案的执行过程分为预置和查询两个部分。在预置部分，供应方对数据做全量加密，将密文存储并前置到需求方环境下（交付过程包括后续的增量更新支持在线和离线方式）。存储量为原始数据量的2倍(由于ElGamal加密的密文会膨胀为明文的2倍)。在查询部分，供应方对需求方的每次查询请求做一次实时回应。所以，方案的计算、通信效率都是正比于查询数据量，存储效率正比于总数据量。这里可能有人会问，为什么不使用两次RSA，把存储效率再降低一倍呢？那是因为RSA本身满足同态性，但在JDK等公开的标准实现中却不满足。这就会造成RSA理论上是同态的，但程序员编程实现时却又不满足同态性。通常情况下，我们的程序实现要满足客户的代码审查要求，而不能去随意改动基础库的代码。于是，2倍密文膨胀的ElGamal就变成了最佳选择了。

4. 其它可能方案的对比

首先，我们看看现在现有金融领域是怎么做的，然后再看看还有哪些可能的方案。目前，由于没有有效的办法来解决数据安全采购问题，需求方采取的是对数据源全量采购的办法：即人工交付数据源在一段时间内的全部数据，再由相关数据部门做后续分析。其缺点除了小数据源效果不好，大数据源买不到之外，还有数据时效性不够强，多源数据汇集困难等问题。在互联网如此普及的时代只能采取离线方法实际上降低了需求方，尤其是小型银行的市场竞争力。

对于一个信息安全领域的研究人员来说，当看到如何在需求方不出任何信息情况下补充外部标签这一问题以后凭直觉想到的解决方案可能应该是：不经意传输。对我们来说同样也是如此。这里我们不介绍不经意传输的细节，只说原理。简单以银行举例，每次银行需要获取标签，供应方把自己所有的标签对应的ID和标签摆在银行面前，银行把所有的ID和标签拿到自己那里，选择一个自己想要的，然后丢弃所有其它的。这样供应商不知道银行拿了哪个，银行也只拿了他想要的那一个，既符合隐私保护需求，也可以精确计量。但是，这一方法的效率是非常低的，只是为了让银行安全获取一个标签，就需要供应商负担正比于数据总量的计算、通信、存储开销。对银行来说，还不如直接购买全部数据来得快。所以，我们在实验后得出的结论是，直接使用不经意传输在工程上是不合理的。于是，我们进一步结合k-匿名方法，对不经意传输做了改进，成百上千倍的提高了计算、通信、存储开销。我们可以通过在安全性和开销之间做权衡，在客户可接受安全性的前提下，尽量提高效率，但依然无法做到让它们正比于在线查询的次数。最终，我们使用了前面的基于同态的方法在保障数据安全的前提下实现效率的最优化。

下面的链接是我们针对这一方案的在线示例，分别模拟了需求方和供应方的操作。https://sdmk.talkingdata.com/#/home/datasecurity

创作场景

最佳实践：金融行业中，如何安全获取数据？