基于区块链的链下数据保护系统优化

赵长明， 薛莹， 张倩

(陕西警官职业学院,新型网络金融犯罪侦查研究中心，陕西,西安 710043)

0 引言

为应对不断发生的个人数据外泄事件，区块链技术与智能合约技术被逐步应用到个人数据保护系统的设计中。匿名地址技术改变了数据在系统中真实地址被直接获取的现状[1]。在本设计的系统方案中，被授权的第三方服务仅能得到被加密的地址，而其想要访问的数据是在资源服务访问后向其提供的，这种方式杜绝了通过数据地址进行攻击的威胁，大大提高了数据的安全性。

1 当前链下数据保护系统存在的问题

当下的个人数据保护系统总体结构如图1所示，通过图1可以清晰地了解数据交互的过程并从中发现问题所在。这是一个通用的系统结构，基于内容各异的方案选择对应的算法。该结构包含4个模块：User(用户)、DC(Data Controller 数据管理员)、TP(Third Party 第三方服务)、RS(Resourse Server 资源服务)。其中，DC能够管理用户的访问权限，TP的目标是获取数据。通过图1可以看出TP获取用户数据的流程如下。

图1 数据保护系统总体结构

步骤一：若TP想要获取User的数据，必须首先得到User的同意，即图1中流程①。

步骤二：若用户同意TP访问其数据，则将访问请求和结果传递至DC，DC对TP和User同时进行身份验证，通过后向TP发送访问授权并在链上作对应的记录，即图1中流程②和③。

步骤三：TP获取授权后到RS中进行访问，即图1中流程④。

步骤四：RS验证TP所获授权，通过后按TP的请求反馈对应数据，即图1中流程④。

流程①中，TP向用户发出数据访问的申请，如果用户同意，则它会将自己连同TP的签名一同发送给DC，由DC进行验证，如此便降低了DC的负载；流程②中，如果DC检测到TP的身份是非法的，则会驳回TP的访问请求，验证失败，授权不通过。可见TP必须通过DC的检测并被赋予访问权限，才能拥有整个系统认可的合法身份。若没有流程②，那么验证授权的请求只能同时发送给SP和DC，经DC确认其合法性。由此可见，DC验证的过程应优先进行。

每条链下数据就是一个存储文件，它们分散于IPFS存储系统中，被编辑后地址也随之改变。地址是访问这些分散存储文件的唯一途径信息，若是使用传统的存储方式，文件的访问方式则是固定的[2-3]。在流程③中，TP的访问申请通过后就会获取用户数据的访问途径。

如此即使用户中断TP的访问过程，但TP已经记录了数据地址，继续访问并不十分困难。本文将提出一个可行的方案来解决系统当前存在的问题，即TP获取的仅是用户数据的加密地址，它获取访问令牌后连同加密地址提交给RS，RS解密地址后将数据发送给TP。

2 链下数据保护系统优化实现

2.1 优化思路

经过改进的系统结构如图2所示。

图2 改进后的系统结构

在C/S模式下，用户的数据由服务器S进行管理，S的职责是接收TP的数据访问申请以及用户发送来的授权，在这里用户就是DS(Data Subject 数据主体)，则S即是DS和TP的权限管理员。一旦TP存在非法行为，就会创建一个不会被删除的记录。在本文中将RS特性假定为“Honest but curious”，也就是即使RS怀疑结果但仍忠实地履行协议。区块链具有伪匿名的性质，在此基础上RS的服务职责可以被假定为仅辨识DS以太坊地址和对DS加密地址进行解析，RS接到DS匿名发送的数据后获取真实地址，由其它加密软件完成加密操作，加密后的地址和解密密码由RS保存，真实地址在DS中，RS向AC提供加密地址，向RS提供解密密码。此时DS的以太坊地址和密码存储为表或键值的形式，与真实身份和地址没有任何关联。如此一来RS在没有获取加密地址的情况下就不能访问用户的数据，只有在接收到TP发来的DS数据访问请求时，才能在其获得访问令牌的情况下获得DS身份与被加密的地址，通过解密密码解析加密地址后向TP提供所需数据。

2.2 优化实现

(1)由图2可见，TP在访问DS数据之前必须向AC提交申请，即流程①。

(2)AC验证TP身份并向DS传达其访问请求，由DS决定是否接受，即流程②。

(3)若DS接受申请，则AC把访问令牌与加密地址一同交给TP，即流程③。

(4)RS、AC同时验证访问令牌，即流程④。

(5)TP向RS出示访问令牌与加密地址，RS验证访问令牌，通过后对加密地址进行解析，找到对应的数据并交给TP，即流程⑤。

在本系统中，每一个活动的模块都有对应的以太坊地址，id_TP即TP在系统中的身份，id_DS、id_AC则分别对应DS、AC 。所有获得授权的TP及其所具权限都详细地记录在一个列表中，以供DS对获得授权的TP进行查询。仅DS能够对列表中的项目内容进行编辑，既可以新建、修改、删除某TP的授权，也可以对其所获具体授权项进行修改。

一开始，DS允许AC对其数据进行管理，向AC提供加密地址，向RS提供解密密码。系统中用以显示访问授权内容的列表A_list是由AC和DS共同创建的，它能够说明TP、AC、DS三者的关系，其中的Address与A_list一一对应。DS对TP的授权具体内容由Address→TP_Policy的映射关系进行说明。在有TP获得授权后，列表中便新建一个TP项，鉴于存在多个TP被同时授权的情况，所以通过一个tps集合将获得授权的TP集中存储。在A_list[DS].Tps中查询获得授权的TP，其所具权限则在A_list[DS].Tp_Policy[TP]中查询。在struct list里，用mflag来说明DS是否允许AC对其数据进行管理，tpsflag显示已获授权的TP数，struct TP里的tpsflag则用以证明TP已获授权。

2.3 算法设计

DS向TP授权时各组件交互流程如图3所示。

图3 DS向TP授权时各组件交互流程图

在流程①TP将对DS数据的访问申请提交给AC；在流程②由DS决定是否允许TP访问；在流程③若DS允许则将授权反馈到AC；在流程④AC在list中新建访问项；在流程⑤TP获得授权，AC把访问令牌与加密地址一同交给TP。

以上过程对应的算法设计如下。

输入id_DS,id_TP,ACT//输入DS地址和权限

输出success

1.require(A_list[id_DS].mflag==1)

2.require(msg.sender==A_list[id_DS].DS)

3.require(A_list[id_DS].Tp[id_DS][id_TP].tpflag!=1)

4.A_list[id_DS][id_DS].push(TP)

5.A_list[id_DS].Tp[id_DS][id_TP].tp=TP

6.A_list[id_DS].Tp[id_DS][id_TP].act=at

7.A_list[id_DS].Tp[id_DS][id_TP].ds=msg.sender

8.A_list[id_DS].Tp[id_DS][id_TP].token=sha256(abi.encodePackedid_TP,act,block.timestamp)

9.A_list[id_DS].Tp[id_DS][id_TP].tpflag=1

10.A_list[id_DS].tpsflage++

9.return true

DS允许TP对其进行访问，就要说明TP的身份和访问的具体内容(CURD)；TP通知AC已通过DS的授权，此时通过步骤1AC首先确认DS是否允许它对其数据进行管理；通过步骤2、3检查DS与A_list对应的DS是否相同，同时确认TP已获授权；在步骤4中为已获授权的TP创建tps列表项；通过步骤4-10所获授权内容进行改动，发送success。

中断TP访问的算法设计如下。

输入id_DS,id_TP//输入DS和TP地址

输出success

1.require(A_list[id_DS].flag==1)

2.require(msg.sender==A_list[id_DS].DS)

3.遍历tps找出TP在列表中的索引i

4.delete A_list[id_DS].tps[id_DS][i]

5.delete A_list[id_DS].Tp[id_DS][Tp]

6.A_list[id_DS].tpsflage—

7.return true

若DS需要中断的TP访问，则通过步骤1确认DS是否允许AC对其数据进行管理；通过步骤2检查DS与与A_list对应的DS是否相同；通过步骤3确认TP在列表中的对应项；通过步骤4将TP所有有关项删除，发送success。

3 应用测试

3.1 系统应用实现

通过remix编译器的Java Script VM开发系统应用界面，其如图4所示。

图4 系统运行测试界面

界面中的regMange是对个人数据进行管理申请的函数，grant函数负责向TP发送授权，revoc函数则能够撤销这些授权。模块测试过程如图5和图6所示。

图5 AC协助DS管理数据

图6 DS通过TP的访问申请

在remix网络环境下进行测试，单次测试运行间隔为2 s。利用Caliper软件进行2次性能测试，第一次分成两轮进行，500次/轮，第二次分成三轮进行，50次/轮，所获结果分别如图7和图8所示。

图7 第一次运行测试结果

图8 第二次运行测试结果

由图7和图8可见，低延时数值在运行500次时较高，且tps通过数一直处在10的水平。

3.2 运行结果分析

在个人数据保护系统里，DS与TP的对应关系为多对多的形式，可利用Solidity语言中的mapping编程设计出第二层地址指向，即mapping(address=>mapping(address=>TP))TP，使TP地址能够与多个DS的TP_policy相对应，通过DS地址指向TP的TP_policy来说明TP所获取的DS授权。基于Solidity语言的msg.sender特性来确保仅由DS发出授权认证，在此情况下若采用其它语言或超级账本进行验证就必须重新编写合约代码。若增加系统的节点数量，分布式账本会更多，那么在只有很少的数据遭到改动的情况下是无法进行优势攻击的，区块链数据的安全性就得到了很好的保证。

4 案例应用

4.1 案例描述

为了验证本文系统的有效性和安全，以某比特币挖矿体系为例，研究本文系统在安全性和有效性上的优势。该体系由3个挖矿计算机、3个IoT传感器和5个以太坊全节点组成，还包括1个云存储服务器和2个常规用户。

本文系统通过2个智能合约对比特币挖矿体系进行数据保护，第一个智能合约包括财务功能、数据请求功能和注册传感器；当用户向体系请求数据时，本文系统通过运行状态创建第二个智能合约，并通过相关实体和群组消息传递共享第二个智能合约地址，在此过程中会检测人员身份。在第二个智能合约部署过程中，用户会将公钥作为构造函数值进行发送。当云服务器通过传感器数据临时地址对智能合约进行更新时，会通知用户应用程序，并从云服务器中下载请求的数据，检验完整性和签名后对数据进行解密。

4.2 案例分析

基于区块链的数据保护系统应用到比特币挖矿体系中，其安全性和有效性主要体现在计算成本上，因此，将本文系统与文献[6]和文献[7]的系统计算成本进行对比，如表1所示。

表1 3个系统计算成本对比

在表1中，G1和G2为2个阶为素数p>2k的加法群和乘法群，M和E分别表示G1中的点乘计算量和取幂计算量，P为配对操作计算量。由此看出，本文系统的综合计算成本与其他2个系统相当。

在案例应用过程中，使用的参数具有80位AES密钥规模安全级别，得到计算时间对比结果如表2所示。由此看出，虽然与其他2个系统的计算成本相当，但该系统计算时间上更短，尤其是最费时的解签密阶段，本系统计算时间具有一定优势。

表2 计算时间对比

为了进一步验证本系统安全性，将3个系统的密文长度和安全性规模进行对比，其结果如表3所示。其中，m为消息，|x|表示x的密文长度位数。由此看出，3个系统均满足安全性，而只有本文系统能够同时满足IND-CCA2和EUF-CMA安全性。相比其他2个系统，本文系统的第二级密文长度更短，因此本文系统的加密效率更高。

表3 密文长度和安全性规模对比

5 总结

本文所设计的区块链个人数据保护系统，解决了原有系统中普遍存在的问题，进一步提升了数据存储的安全性。在系统设计方案中，将数据的访问权限分散于各模块，AC接收加密地址，RS接收解密，而真正的数据地址则是由RS进行解密处理并提供给TP。通过案例可知，该系统相对于文献[6]和文献[7]数据保护系统来说，其有效性相当，而安全性和计算耗时方面具优势。