一、背景及场景
1、现有技术中,数据价值随着拥有者的增加而减少:
在数据共享应用中,数据累积是让企业不想分享他数据的重要原因。当一份数据
只有自己有时他的市场价值为n,当企业不论是收费或免费将数据提供给另一个人时,他的
价值就变成了n/2,随着知道此数据的人数越来越多,价值直线下降,最终会变成一个公开
数据。
2、 查询本身就是一种数据:
参与数据交换的双方都会存在这种担忧,数据输出者的担忧很直接,他提供了自
己的数据,由于数据的可复制性,对方即知道了此数据。同样对于查询方而言一样存在这种
数据泄漏,当查询方向输出方查询用户a的数据时,输出方即知道了a这个用户在查询方的
业务场景中,而累积此数据便可使此类数据产生价值
3、互联网贷款场景案例:
在信贷场景中,由于放贷公司数据不完整,所以会向第三方购需数据,比如有一家
公司x,向信贷企业提供黑名单服务,x公司有一个用户逾期的库,信贷公司y想在x公司查询
用户a是否在黑名单库中。当x收到y公司请求时,便知道用户a正在y公司申请贷款,如果有
很多信贷公司都通过y公司来查询用户是否在黑名单中,那么y公司便可以知道一个用户是
否存在多头借贷的风险。
4、用户特征数据共享场景案例:
一个手机APP会根据不同的用户来显示不同的产品或广告,通常一个APP只有用户
的部分数据,为了达到更加精准的消息推送,需要有更广泛的用户标签。在数据市场中有很
多提供用户画像的公司,这些公司的输入为用户标识如:手机号、身份证号、手机设备码等。
需求方输入用户标识,提供方根据这些信息从自已的库中找到信息,输出给需求方。由于提
供用户画像公司知道请求APP的性质,如为交友类、贷款类、旅游类等,所以数据的提供方在
提供给需求方数据的同时,也知道了这个用户正在使用什么APP,对此数据按用户进行聚合
可以衍生出用户的其他特征。
二、方案:
步骤:
(1)所述的查询模块生成混淆数据,并对查询数据和混淆数据进行哈希计算;
(1.1)所述的哈希单元对用户标识ID进行md5计算;
(1.2)所述的第一混淆单元随机生成若干个假用户标识ID的md5码;
(2)所述的查询模块隐藏若干位后数据,向数据输出服务模块发起查询;
(2.1)所述的第一混淆单元对其生成的假md5码和哈希单元计算后的md5码隐藏若
干位数据,仅保留预设位数的号码;
(2.2)所述的第一查询单元将所述的保留预设位数的md5码的号码发生至数据输
出服务模块;
(3)所述的数据输出服务模块向数据库查询匹配数据,生成混淆数据;
(3.1)所述的第二查询单元在数据库中匹配满足条件的预设位数的md5码,并保存
至数据存储单元;
(3.2)所述的第二混淆单元随机生成若干个假md5码;
(4)所述的数据输出服务模块对真假数据进行加密并返回至查询模块;
(4.1)所述的加密单元对第二查询单元匹配到的md5码和第二混淆单元生成的假
md5码添加随机数,并通过公钥进行加密;
(4.2)所述的数据输出服务模块将加密后的数据返回至查询模块;
(5)所述的验证单元通过数据输出服务模块提供的随机数和公钥进行加密,在返
回数据中查询是否存在加密后的字符串,如果是,则对方包含该用户的数据;否则,对方不包含该用户的数据。
举例:
场景假设为需求方通过身份证号来供方查询指定用户是否为黑名单用户。
[1] 供方对身份证号进行散列,散列的算法要保证低碰撞率(假设我们以md5方式进行
散列)。供方对身份证号进行散列后作为查询key进行存储;
[2] 需方现在查询a用户是否在供方黑名单库中,先将身份证号进行md5,然后再随机
生成若干个假的身份证号的md5(比如9个),对这10个md5值去掉后面若干位,如:只保留前
面的7位;
[3] 将10个只有7位md5码的号码发送给供方,供方在自己库中匹配前7位符合的用户,
比如取到8位;
[4] 供方再随机生成若干个假的md5码(如13个),共20个号码,对这20个完整号码添加
随机数后用公钥进行加密,返回给需方;
[5] 需方取用户a的md5码用供方提供的随机数和公钥加密,然后在20个号码中查询是
否存在加密后的字符串;如果存在,则说明对方有此用户的数据,反之没有。
[6] 将身份证号md5的目的是为了增加枚举的成本,如果只隐藏身份证号的若干位,那
么一方面号码本身有明确信息,如前有地区信息,出生信息等;另一方面可以对缺失位进行
小范围的枚举。如果用md5后枚举难度为36^25(只显示7位那md5被隐藏了25位,每位有36种
可能);
[7] 发送请求时加入假信息目的是为了即使对方有完整的库,且前7位只匹配到1位,
那么也无法判断这1位是否是需方真正要查的那一位;