一种行程数据隐私化方法及系统

1.本发明属于计算机技术领域，尤其涉及一种行程数据隐私化方法及系统。


背景技术：

2.目前，在全国各地通行需要出示通信大数据行程卡，简称“行程卡”，是官方授权认证的行程数据记录查询服务。用户仅需填写实名认证的手机号码以及对应查询验证码，即可获取并展示本人在过去14天内所有停留超过4小时以上的城市旅行行程记录证明，且应用将根据行程历史地的实时疫情防控风险评级，显示行程历史地是否带有星号，最终分别获得的绿色、黄色或是红色的行程卡。
3.尽管当下行程卡已实现全国认证通行，为疫情信息化管控管理提供不少便利，但其实践过程依旧存在着一些信息安全问题。在行程码、健康码等信息辅助抗击疫情手段的应用实施上，往往出于公共安全的考虑，强制公开一些个人隐私数据，忽视了对个人信息数据的保护，如行程码的出示往往需要展示14天内所有的行程记录，尽管有很多的不相关行程记录是不必要验证的。个别地方的行程码，其进一步的收集个人信息数据以突破超出健康码防疫的使用范围特性，引发了民众对过度收集个人隐私数据的担忧。


技术实现要素：

4.为克服现有技术的缺陷，本发明针对防疫监管手段中，行程卡验证时存在的完整展示个人行程历史记录的个人信息泄露安全问题，提出了一种使用非交互式零知识证明技术面向疫情防控的行程数据隐私化监管方法。该方法涉及一种原型系统，分别是绝对可信任的第三方服务端，证明者客户端，验证者客户端，可完整实现行程数据证明和验证全过程数据的隐私化。是通过如下方案实现的：
5.一种行程数据隐私化方法，包括以下步骤：
6.步骤1、生成含有证明密钥和验证密钥的公共参考字符串；
7.步骤2、使用证明算法生成证明文件；
8.步骤3、使用验证算法验证所述证明文件。
9.一种行程数据隐私系统，包括：绝对信任的第三方服务器，证明者客户端和验证者客户端，其中：
10.证明者客户端发起证明请求，发送证明请求至绝对信任的第三方服务端，收到第三方服务端的证明密钥后，并生成证明文件返回给第三方服务端；
11.绝对信任的第三方服务端生成公共参考字符串，并分发证明密钥给证明者客户端，分发验证密钥给验证者客户端；
12.验证者客户端发起验证请求至绝对信任的第三方服务端，第三方服务端返回证明文件给验证者客户端，验证者客户端使用证明文件和验证密钥输入验证证明。
13.本发明的有益效果：证明者根据行程时空隐私数据生成一段不包含行程时空信息的证明文件，验证者根据这份证明文件以及当前中高风险城市名单判断证明者是否有中高
风险城市旅行史，然后对证明者执行相应对策。在这个过程中，证明者无需提供完整的行程时空隐私数据给验证者，而验证者也能验证证明者是否有中高风险城市旅居史。
附图说明
14.图1为本发明实施例的时空数据零知识证明框架示意图。
15.图2为本发明实施例的预处理零知识证明系统。
16.图3为本发明实施例的原型系统工作流程。
17.图4为本发明实施例的r1cs约束可视化示意图。
18.图5为本发明实施例的原型系统绝对信任第三方服务端。
19.图6为本发明实施例的示意原型系统证明者客户端。
20.图7为本发明实施例的示意原型系统验证者客户端。
具体实施方式
21.以下结合实施例对本发明作进一步的阐述，所述的实施例仅为本发明一部分的实施例，这些实施例仅用于解释本发明，对本发明的范围并不构成任何限制。
22.本发明所述的证明者及证明者客户端，证明者是需要被证明行程的个人，证明者客户端是个人所持有的智能终端，如手机。
23.本发明所述的验证者者及验证者客户端，验证者是证明个人行程的工作人员或终端设备，验证者客户端是工作人员所持有的智能终端，或者是具有验证功能的闸机。
24.本发明所述的绝对信任的第三方服务端，是绝对信任的服务器，与验证者客户端和证明者客户端通信。
25.本发明实施例中，涉及一种行程数据隐私化方法及系统，其中系统的运行环境是基于linux操作系统。
26.请参考图1，本发明实施例中的行程数据隐私化系统涉及时空数据零知识证明框架，框架底层平台选择使用linux操作系统。
27.libsnark层实际上就是整个libsnark库。当然本发明未必使用所有的libsnark功能。
28.预处理零知识证明接口层。preprocessing zero-knowledge succinct non-interactive argument of knowledge预处理的零知识证明系统所抽象出的接口。其中preprocessing指代该类证明系统在证明之前，需要预处理生成common reference string(crs)公共参考字符串。而实现该种证明系统有三种主流算法，分别是phgr13/bctv14a、groth16和gm17。预处理零知识证明系统工作流程从原理上可以简要概括为三个步骤：一、generate生成算法生成crs；二、prove证明算法生成证明文件proof；三、verify验证算法验证证明。那么与之对应，时空数据零知识证明框架中的预处理零知识证明接口层，在libsnark的基础上抽象出了三个接口，分别是setup公共参考字符串参数生成算法接口，prove证明生成算法接口，verify验证证明算法接口。也是在这一层，本发明从功能上实现了基本的预处理的零知识证明完整过程。
29.交互层，这是在预处理零知识证明接口层三个接口的基础上，构造出了绝对可信任第三方和数据流通的交互逻辑层。具体使用了google protocol buffers，grpc，qt等计
算机通讯交互及图形化展示技术，并使用cmake构建整个交互层功能。
30.最终，该框架在顶层的应用层，将零知识证明各方功能整合实现出了预处理零知识证明系统完整流程所需的三个角色，分别是绝对可信任的第三方服务端，证明者客户端，验证者客户端。
31.如图3所示，在本发明实施例中，一种行程数据隐私化方法，进一步包括如下步骤：
32.步骤1，生成公共参考字符串，即keypair。其中keypair分为proving key(pk)证明密钥和verifying key(vk)验证密钥。在这个生成过程(这个过程也称为setup)中，需要随机生成一些参数，这些参数也被称为“toxic waste”有毒废料。因为这些参数需要被即刻销毁，否则它们可能成为协议的攻击面，危害证明系统的安全。同时成对的公共参考字符串，将分别交付证明者prover和验证者verifier，成为完整证明过程所必要的材料。公共参考字符串是命题信息零知识化的重要辅助材料，也是非交互性，即将证明与验证过程分割独立，实现的重要一环。
33.步骤2，使用证明算法生成证明。在本发明中，证明者想证明其所持有的行程历史能够使时空数据多项式命题成立。在生成证明的过程中，证明者需要输入行程时空隐私证据，证明密钥和公共陈述，传给证明算法实现函数。
34.在本发明实施例中，时空数据多项式命题的实现通过公式实现。以广东省内21个地级市为例，使用布尔值编码将这21个城市设定成一个21维时空数据向量。对证明者而言，该向量的各个维度，若值为0，则代表无该城市到访历史，若值为1，则代表有该城市到访历史。同理，对验证者而言，该向量的各个维度，若值为0，则代表无需验证该城市，若值为1，则代表需要验证该城市。
35.那么容易得到，证明者持有的行程历史向量p，验证者待验证的行程历史向量v及当证明者无14天内待验证城市到访历史时的命题。时空数据多项式命题满足以下公式：
36.p＝[x1,x2,x3,......,x
n-1
,xn],n＝21,xi∈{0,1}
[0037]
v＝[y1,y2,y3,......,y
m-1
,ym],m＝21,yj∈{0,1}
[0038]
pv＝0。
[0039]
通过上述公式使证明者所持有的行程历史能够使待证明命题成立。
[0040]
步骤3，使用验证算法验证。将第二步生成的证明文件，第一步生成的验证密钥以及公共陈述作为验证算法实现函数的输入验证证明，即可在不暴露证明者行程隐私信息的情况下验证证明者行程满足步骤2中的证明命题。
[0041]
基于预处理零知识证明系统以及时空数据零知识证明框架。本研究原型系统设计了三个终端。分别是绝对可信任的第三方服务器server，证明者prover客户端，验证者verifier客户端。原型系统工作流程主要为以下六大步骤。
[0042]
证明者客户端发起证明请求，发送证明请求至绝对信任的第三方服务端。
[0043]
绝对信任的第三方服务端生成公共参考字符串，并分发证明密钥给证明者客户端,分发验证密钥给验证者客户端。
[0044]
证明者客户端生成证明文件，并返回给绝对信任第三方服务端。
[0045]
验证者客户端发起验证请求至绝对信任的第三方服务端。
[0046]
绝对信任的第三方服务端返回证明文件给验证者客户端。
[0047]
验证者客户端使用证明文件，验证密钥等输入验证证明。
[0048]
证明者客户端注册服务。在此服务中，绝对信任第三方服务端将收集证明者发送的姓名字符串，检索是否存在重复的姓名，若无重复，则将证明者客户端提交的姓名记录到第三方服务端数据库中。
[0049]
验证者客户端注册服务同理。在此服务中，绝对信任第三方服务端将收集验证者客户端发送的姓名字符串，检索是否存在重复的姓名，若无重复，则将验证者客户端提交的姓名记录到第三方服务端数据库中。
[0050]
公共陈述设置服务，以广东省为例，可设置广东省内21个地级市中，现定为中高风险城市的名单。
[0051]
获取公共陈述服务，这个服务是针对证明者客户端和验证者客户端共同构建的。因为，不仅证明者需要公共陈述作为生成证明的输入，而且验证者也同样需要公共陈述作为验证证明的输入。
[0052]
证明者客户端和验证者客户端配对服务，即将证明者客户端和验证者客户端配对。因为在一般的证明流程中，证明者客户端和验证者客户端是成对出现的，构建该服务，目的就是绑定需要证明验证的证明者客户端和验证者客户端作为一次完整证明的交互双方。
[0053]
公共参考字符串生成模块，则是在上一服务基础上，对该对证明者客户端和验证者客户端，依据r1cs电路生成一对临时的公共参考字符串即证明密钥和验证密钥。需要注意的是，针对每对公共参考字符串，都需要重新生成新的公共参考字符串，以确保信息安全性。
[0054]
本发明实施例中，将时空数据多项式命题转化为r1cs电路，申请了四个pb_variable_array数组变量，见表1。借助这四个数组变量，将命题扁平化成若干个二次方程式，转化成为一个个简单r1cs约束，如图4所示。
[0055][0056]
表1
[0057]
二次方程式表达如下：
[0058]
primary_inputs[i]*auxiliary_inputs[i]＝intermediate[i]，i＝0,1,...,n-1
[0059]
(intermediate[0] auxiliary_inputs[1])*1＝add_intermediate[0]
[0060]
(intermediate[i-1] intermediates[i 1])*1＝add_intermediate[i],i＝1,2,......,n-2add_intermediate[n-2]*1＝0
[0061]
如图5所示，第三方服务端包括以下几个部分：
[0062]
发送证明密钥至证明者客户端服务。则是在前两个服务的基础上，将临时生成的
证明密钥发送到配对好的证明者客户端上，并最终销毁该证明密钥，以确保系统信息安全。
[0063]
发送验证秘钥至验证者客户端服务。则是在发送证明密钥至证明者客户端服务的前两个服务的基础上，将临时生成的验证密钥发送到配对好的验证者客户端上，并最终销毁该验证密钥，以确保系统信息安全。
[0064]
从证明者客户端获取证明文件服务，即接收来及配对好的证明者发送来的证明文件序列化数据，并存储于服务端数据库中，同样也是基于证明者客户端和验证者客户端配对服务服务生产的证明者客户端和验证者客户端对。
[0065]
发送证明文件至验证者客户端服务，即发送存储于服务端数据库中的证明文件序列化数据，同样也是基于证明者客户端和验证者客户端配对服务服务生产的证明者客户端和验证者客户端对。最终销毁服务端数据库中的该证明文件，以确保系统信息安全。
[0066]
如图6所示，证明者客户端包括以下几个部分：
[0067]
证明者注册模块。证明者客户端发起注册请求，证明者需要提交自己的唯一认证的id字符串，并调用绝对信任第三方服务端对应服务证明者客户端注册服务实现功能。
[0068]
公共陈述获取模块，实现获取公共陈述输入功能。证明者客户端发起请求，并调用绝对信任第三方服务端对应服务，公共陈述获取服务，返回得到序列化的公共陈述数据。
[0069]
验证者配对模块，证明者客户端发起请求，调用绝对信任第三方服务端对应服务，与对应验证者客户端配对，并将配对信息存储于第三方服务端数据库中。
[0070]
证明密钥获取模块。证明者客户端发起请求，调用绝对信任第三方服务端对应服务发送证明密钥至证明者客户端服务，第三方服务端返回证明者客户端对应证明密钥序列化数据。
[0071]
时空行程隐私数据设置模块，实现设置证据witness(行程数据隐私)功能。对应的，证明者可以设置证明者的14天内广东省内活动城市名单。
[0072]
证明文件生成模块，根据证明密钥，公共陈述和行程时空隐私证据，生产证明文件。
[0073]
发送证明文件至第三方服务端模块，证明者客户端发起请求，绝对信任第三方服务端对应服务从证明者客户端获取证明文件服务，并最终销毁证明文件，以确保系统信息安全。
[0074]
如图7所示，验证者客户端包括以下部分：
[0075]
验证者注册模块，验证者客户端发起注册请求，验证者需要提交自己的唯一认证的id字符串，并调用绝对信任第三方服务端对应服务验证者客户端注册服务实现功能。
[0076]
公共陈述获取模块，实现获取公共陈述输入功能。验证者客户端发起请求，并调用绝对信任第三方服务端对应服务，公共陈述获取服务，返回得到序列化的公共陈述数据。
[0077]
证明者配对模块，验证者客户端发起请求，调用绝对信任第三方服务端对应服务，与对应证明者客户端配对，并将配对信息存储于第三方服务端数据库中。
[0078]
验证密钥获取模块。验证者客户端发起请求，调用绝对信任第三方服务端对应服务发送验证密钥至验证者客户端服务，第三方服务端返回验证者客户端对应验证密钥序列化数据。
[0079]
从第三方服务端获取证明文件模块。验证者客户端发起请求，调用绝对信任第三方服务端对应服务发送证明文件至第三方服务端模块，第三方服务端返回验证者客户端对
应证明文件序列化数据。
[0080]
验证证明模块。验证者客户端根据验证密钥，公共陈述以及证明文件，验证证明。
[0081]
本发明针对防疫监管手段中，行程卡验证时存在的完整展示个人14天行程历史记录的个人信息泄露安全问题，提出了一种使用非交互式零知识证明技术面向疫情防控的行程数据隐私化监管方法。现今的行程验证，往往需要完整的展示证明者近14天的完整行程时空信息。验证一方则是根据当地防控政策，判断并验证行程时空信息是否满足防疫政策，即验证证明者是否去过中高风险城市，再对证明者执行相对应政策。而在本发明的实践下，证明者根据行程时空隐私数据生成一段不包含行程时空信息的证明文件，验证者根据这份证明文件以及当前中高风险城市名单判断证明者是否有中高风险城市旅行史，然后对证明者执行相应对策。在这个过程中，证明者无需提供完整的行程时空隐私数据给验证者，而验证者也能验证证明者是否有中高风险城市旅居史。
[0082]
本发明通过非交互式零知识技术保护了像行程码这样的证明验证场景下个人时空行程隐私数据的信息安全。减小了不法分子盗取滥用公民信息的可能性。其是当部分感染人员个人相关信息被披露时，遭到“人肉”攻击，暴露了真实身份，甚至因此遭受网络暴力。且存在一些企业企图收集这些信息，进行商业上的应用分析，如大数据“杀熟”，这种行为显然是违背法制精神的。同时我们也要警惕境外的个人或组织对我国公民数据的非法收集。显然，个人信息一旦发生泄露，普通民众的合法权益乃至国家安全都极易受到损害。此外，安全保密的方式也能提高民众的参与抗击疫情的积极性与安全感。
[0083]
以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明，任何熟悉本专业的技术人员，在不脱离本发明技术方案范围内，当可利用上述揭示的技术内容作出些许更动或修饰为等同变化的等效实施例，但凡是未脱离本发明技术方案内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均仍属于本发明技术方案的范围内。