基于Fabric的出行数据隐私保护方法

马 娜，戚 湧，严 悍

(南京理工大学 计算机科学与工程学院，江苏 南京 210094)

0 引 言

出行数据作为智能交通系统(intelligent transportation systems，ITS)的基础数据，涉及出行者个人隐私，通常由ITS终端设备采集上传到数据中心，被各机构所共享，共享过程中不乏出现非法用户攻击ITS、窃取出行者隐私的现象，使出行者人身和财产安全受到严重威胁[1,2]。因此，如何在共享环境下进行出行数据隐私保护已经成为ITS发展急需解决的重要问题。现有方案大都采用数据聚合[3]、数据加密[4]、匿名认证[5]等方法，尽管可以缓解部分隐私保护问题，并不能完全确保数据共享中的个人隐私安全。

区块链作为一种分布式数据库[6]，可以为数据共享提供机密性和完整性保障，是一种解决共享环境隐私保护问题的新渠道[7]，目前已被用在金融[8,9]、医疗[10,11]、智能交通[12-14]等领域。但大部分都是基于比特币或以太坊进行研究，交易验证速率较慢，难以满足现实场景中的性能需求。许可区块链Hyperledger Fabric(以下简称Fabric)具有高安全性和高扩展性，可以满足多数情况下的吞吐量需求[15]。因此，本文提出一种基于Fabric的出行数据隐私保护方法，对出行数据的上传与查询进行隐私保护，从而提高共享环境下出行者的个人隐私安全。

1 基于Fabric的出行数据隐私保护模型

Fabric作为主流的许可区块链开源项目，以认证授权的方式限制节点、用户的加入，有助于增强区块链交易数据的隐私安全。因此，本文采用Fabric平台构建出行数据隐私保护模型。

如图1所示，模型主要分为4个模块，分别是客户端模块、Web服务与中间件模块、智能合约模块以及Fabric区块链数据库模块。

图1 基于Fabric的出行数据隐私保护模型

1.1 客户端模块

客户端模块分为数据上传终端和数据访问终端。数据上传终端包括ITS中能够采集出行数据的所有终端设备，如车载GPS设备、视频检测器等；数据访问终端包括需要访问或监控出行数据的所有终端系统，如出行服务提供商的交通数据访问系统、公安部门的交通监测系统等。所有客户端用户都需要在Fabric中进行注册登记，执行客户端请求前需要验证当前用户的身份有效性。

1.2 Web服务与中间件模块

Web服务负责基础业务逻辑支撑，提供出行数据相关业务处理。中间件负责提供便携式数据交互接口，简化Fabric与Web服务之间的操作逻辑，从而满足快速、高并发的客户端请求。当Web服务收到客户端请求时，中间件验证当前用户身份，身份有效则调用智能合约模块，执行客户端请求。

1.3 智能合约模块

Fabric中智能合约又称为链码(Chaincode)，其中用户自定义数据接口称为链码函数(chaincode function，CCF)。智能合约模块分为隐私数据链码函数(private chaincode function，PCCF)和链码函数控制(chaincode function control，CCFC)模块。考虑到Fabric区块链数据库中存储的数据对所有接入节点和用户可见，对于涉及个人隐私的敏感数据，采用加密技术隐藏数据的真实内容。当智能合约模块接收到数据请求时，PCCF调用中间件对数据进行加解密处理。鉴于Fabric中所有接入节点和用户共享智能合约代码，需要限制用户对CCF的调用权限，由CCFC调用中间件获取当前客户端用户的身份证书，根据证书信息判断请求的有效性，有效则执行对应链码逻辑。

1.4 Fabric区块链数据库模块

模型采用非关系型数据库CouchDB作为Fabric数据存储库，以键-值形式记录区块链交易与用户的相关信息，确保数据操作的高可伸缩性、高可用性以及高可靠性。CouchDB中存储的信息包括用户证书、出行数据、访问权限等。

2 关键模块设计与实现

2.1 Fabric区块链数据库和中间件设计

2.1.1 Fabric区块链数据库接口

(1)putRec(k,v)： 向CouchDB中添加一条键为k、 值为v的交易记录，该接口通常在产生新的区块链交易时被调用。

(2)getRec(k)： 根据键k从CouchDB中读取一条记录的最新状态，该接口通常在请求查询区块链交易时被调用。

(3)getHis(k): 根据键k， 查询CouchDB中的交易历史修改记录，该接口通常在查询区块链交易凭证时被调用。

(4)genCert(u)： 为用户u生成身份证书，该接口通常在用户注册时被调用，除了认证中心保存身份证书信息以外，CouchDB中也要进行记录，便于智能合约模块验证客户端身份。

2.1.2 中间件接口

(1)getCert(u)： 查询并解析用户u的身份证书。当智能合约模块接收到数据请求时，先从CouchDB中读取当前客户端的用户身份证书，解析证书属性，智能合约模块根据属性信息判断该用户是否具有CCF调用权限。以getCert(U) 为例，伪代码如下：

//读取用户U的身份证书

identityCertU=getCreator(U)

//解析证书属性

certU=analysisCert(identityCertU)

(2)genKey(k)： 生成密钥k。 在本文模型中，生成密钥指初始化智能合约时，采用最流行的高级加密标准[16](advanced encryption standard，AES)算法，生成256位的初始对称密钥。为确保数据存储安全，每一次使用的密钥都要经过哈希加盐。本文使用的AES256算法，安全性高，非常适合模型中的数据加密。

(3)encrypt(k,r)： 用密钥k加密交易记录r的部分属性，即对r中隐私属性PriAttr的相关信息进行加密，得到含有密文的记录。以encrypt(K0,R) 为例，伪代码如下：

//初始密钥哈希

K=hashKey(K0)

//如果R具有隐私属性Location和Phone

R.PriAttr.Location=encryptAttr(K,R.PriAttr.Location)

R.PriAttr.Phone=encryptAttr(K,R.PriAttr.Phone)

(4)decrypt(k,r)： 用密钥k解密交易记录r的部分属性，即从CouchDB查询得到r后，若r中含有PriAttr属性，就用k解密相关信息，得到属性的真实内容，解密过程与加密过程类似。

2.2 智能合约模块

2.2.1 链码消息交互过程

智能合约是基于预订时间触发、不可篡改、自动执行的一段程序，具有自治性、强制性和自我验证功能。Fabric中智能合约(链码)是连接客户端与Fabric区块链数据库的重要组件，分为系统链码和用户链码。系统链码负责交易背书、系统配置等逻辑处理，固化在系统中；用户链码由用户编写，负责执行自定义处理逻辑，运行在Docker容器中，与Peer节点通过gRPC连接，双方通过发送Chaincode-Message消息进行交互通信，交互过程如图2所示。

图2 链码与Peer节点之间的消息交互过程

步骤1 创建好gRPC连接后，链码向Peer节点发送REGISTER消息进行注册，等待接收Peer节点的回应消息，此时状态为created；

步骤2 Peer节点收到REGISTER消息后，将其注册到本地的Handler结构中，返回REGISTERED消息给链码，此时，Peer节点状态为established。链码收到REGISTERED消息后，不进行任何操作，更新状态为established，链码注册完成。

步骤3 Peer节点向链码发送READY消息，更新状态为ready。链码收到READY消息后也更新状态为ready。

步骤4 Peer节点向链码发送INIT消息，对链码进行初始化。

步骤5 链码容器收到INIT消息后，调用Init方法进行初始化，成功后返回COMPLETED消息给Peer节点，链码初始化完成，此时链码状态为可被调用状态。

步骤6 Peer节点向链码发送TRANSACTION消息，执行链码调用。

步骤7 链码收到TRANSACTION消息之后，调用Invoke方法，执行具体CCF，并向Peer节点发送数据库操作消息。

步骤8 Peer节点收到数据库操作消息后，执行相应的数据操作，并向链码返回RESPONSE消息。

步骤9 链码调用完成后发送COMPLETE给Peer节点。

步骤10 以上消息交互过程当中，Peer节点和链码会定期相互发送KEEPALIVE消息给对方，以确保彼此处于在线状态。

2.2.2 隐私数据链码函数

(1)隐私数据存储

步骤1 Peer节点向智能合约发送封装好的交易提案，请求调用隐私数据存储链码函数(write private data chaincode function，WPDCCF)，此时默认智能合约模块已完成初始化。

步骤2 智能合约收到交易提案后，根据提案中的请求信息验证当前用户的WPDCCF调用权限，权限有效则可以调用。

步骤3 WPDCCF根据提案参数创建隐私数据结构体，封装隐私属性PriAttr和非隐私属性PubAttr。

PrivateRecord{PubAttr∶{a1,a2,…},PriAttr∶{b1,b2,…}}

步骤4 调用中间件encrypt(k,r) 进行加密处理，依次加密数据的PriAttr属性信息。

步骤5 加密完成后，执行putRec(k,v)， 将数据存储至区块链中，成功后向Peer发送完成消息。伪代码如下：

算法1: 隐私数据查询存储函数

(1)Input:TravelRecord

(2)Output:Success

(3)begin

(4)//根据TravelRecord创建隐私数据结构体

(5)NewRecord←PrivateRecord{

(6) PubAttr∶{a1,a2,…},PriAttr∶{b1,b2,…}}

(7)(RID,Record)←encrypt(K,NewRecord)

(8)putRec(RID,Record)

(9) return Success

(10)end

(2)隐私数据查询

步骤1 Peer节点向智能合约发送交易提案，请求调用隐私数据查询链码函数(read private data chaincode function, RPDCCF)。

步骤2 收到交易提案后，智能合约验证客户端的RPDCCF调用权限，有效则可以调用该CCF。

步骤3 RPDCCF执行getRec(k)， 从数据库中读取记录的当前状态。

步骤4 调用中间件decrypt(k,r) 执行解密逻辑，解密该记录的PriAttr属性。

步骤5 将解密后的数据返回给Peer节点。伪代码如下：

算法2: 隐私数据查询链码函数

(1)Input:RID

(2)Output:NewRecord

(3)begin

(4) // 根据RID从CouchDB中获取交易记录

(5)PrivateRecord←getRec(RID)

(6)NewRecord←decrypt(K,PrivateRecord)

(7) returnNewRecord

(8) end

2.2.3 链码函数权限控制

(1)设置访问控制矩阵

本文采用访问控制列表(access control list，ACL)机制控制用户对CCF的调用权限。ACL是一种普遍使用的访问控制机制，按照列表的方式存储访问控制矩阵(access control matrix，ACM)，从而验证主体的访问权限[17]。在本文模型中，根据用户注册时登记的身份信息(所属机构Org和用户角色Role)，每一个用户都对应一个有效CCF集合。如表1所示，每一行代表一个CCF对象，每一列代表一个用户主体，每一项代表用户对CCF的访问权限，例如，当机构为O2、 角色为R2时，该用户的有效CCF集合为 {RPDCCF,getRec,getHis}， 可调用集合内的所有CCF。

表1 访问控制矩阵

为提高PCCF的可用性和持久性，需要设置访问控制矩阵，对调用权限进行动态管理，使用add(acm,org,role,ccf) (添加新权限)、 update(acm,org,role,ccf) (更新权限)管理区块链中的权限信息，出现非法调用时通过getHis(k) 查询访问控制矩阵的历史修改记录，根据相关凭证进行追责，伪代码如下：

算法3： 设置访问控制矩阵

(1)Input:TypeOP,OrgU,RoleU,CCFName

(2)Output:Success

(3)begin

(4)//读取已有矩阵信息

(5)ACM←getRec("AccessControlMatrix")

(6) if(TypeOP为新增权限操作)

(7) {add(ACM,OrgU,RoleU,CCFName)

(8) putRec("AccessControlMatrix",ACM)}

(9)else if(TypeOP为更新权限操作)

(10) {update(ACM,OrgU,RoleU,CCFName)

(11) putRec("AccessControlMatrix",ACM)}

(12)else{无效操作类型}

(13)returnSuccess

(14)end

(2)验证CCF调用权限

在调用指定CCF之前，需要先查询区块链中已有的权限信息，执行getCCFs(org,role)， 获取当前用户的有效CCF集合，验证该用户的调用权限是否有效，有效则执行对应链码逻辑，否则返回访问受限信息，伪代码如下：

算法4: 验证CCF调用权限

(1)Input:CCFName,UID

(2)Output: 1或0

(3)begin

(4)//读取UID的身份证书

(5)CertU←getCert(UID)

(6)if(存在CertU)

(7) {ACM←getRec("AccessControlMartix")

(8) //根据CertU判断权限是否有效

(9)CCFs←getCCFs(ACM,CertU.Org,CertU.Role)

(10)if(CCFs包含CCFName){return 1}

(11)else{return 0}}

(12)else{return 1}

(13)end

3 安全性分析

3.1 数据存储保密性

本文模型中所有出行数据存储在区块链上，非区块链认证用户或节点不能共享数据。在WPDCCF中，上传至区块链的敏感信息都经过AES加密处理，加解密速度快，密钥经过哈希加盐，即使得到初始密钥，也不能查看数据的真实内容，可以确保数据存储的绝对保密性。

3.2 数据访问安全性

本文模型中所有用户在访问过程中都需要经过从Web服务层到智能合约层的多层身份验证，数据访问安全性高。Web服务层验证用户身份是否有效，即是否已经在区块链中进行登记注册；智能合约层根据已颁发的身份证书，在CCFC模块中判断用户是否具有CCF的调用权限。出现非法操作时，通过查询访问控制矩阵的历史修改信息，可以进行相关的法律追责。

4 实验与结果分析

4.1 实验方案

本文所提出模型主要面向区块链用户，控制不同用户的数据访问权限，因此，本实验的目的是得到高并发请求、高负载情况下，本文模型、原生Fabric(无隐私保护)以及Fabric中面向节点的隐私保护方法3种方法在处理客户端请求时的性能测试结果，通过评估测试结果来验证本文模型的可行性。测试指标分为每秒处理事务(即请求)数(transactions per second，TPS)和每个事务的平均响应时间(time per transaction，TPT)，TPS用于评估单位时间内的可处理数据请求数，TPT用于评估指定并发量下处理一个数据请求所需要的时间。

本实验主要针对用户的上传数据请求和访问数据请求进行测试，使用CPU规格为Intel(R)Core(TM) i7-6700@3.40 GHz、四核八线程的主机，模拟执行10轮次、不同并发量的数据请求，计算各并发量下的平均TPS和平均TPT，最后对结果进行分析。

4.2 实验结果及分析

4.2.1 访问数据请求测试结果

如图3、图4所示，横轴表示访问数据请求的并发量，纵轴表示各并发量下的平均TPS或平均TPT，并发量的范围从0到5000依次增加，间隔为100。从图3可以看出，相同并发量下，本文模型与原生Fabric(无隐私保护)的单位时间可处理请求数目基本一致，都多于面向节点的隐私保护方法。从图4可以看出，同一并发量下，本文模型与原生Fabric的平均响应时间基本一致，都少于面向节点的隐私保护方法。并发量为1100～1900时，性能较为稳定；并发量为2000时，平均响应时间约为2.5 s。因此，基于Fabric的出行数据隐私保护模型在执行访问数据请求时，没有降低Fabric本身的性能，并且性能明显高于面向节点的隐私保护方法。

图3 访问数据请求平均TPS测试结果

图4 访问数据请求平均TPT测试结果

4.2.2 上传数据请求测试结果

如图5、图6所示，横轴表示上传数据请求的并发量，纵轴表示各并发量下的平均TPS或平均TPT。并发量范围从0到2000依次增加，间隔为100。从图5可以看出，同一并发量下，本文模型与原生Fabric的单位时间可处理上传数据请求数目基本一致，都远多于面向节点的隐私保护方法。如图6所示，对于平均响应时间的测试，本文模型与原生Fabric相差不大，都少于面向节点的隐私保护方法。并发量大于1500时，性能较为稳定；并发量为2000时，平均响应时间约为35 s。因此，基于Fabric的出行数据隐私保护模型在执行上传数据请求时，没有降低Fabric性能。

图5 上传数据请求平均TPS测试结果

图6 上传数据请求平均TPT测试结果

5 结束语

本文提出了一种基于Fabric的出行数据隐私保护方法，考虑到Fabric平台中交易数据、智能合约代码对网络中所有节点和用户完全开放共享，本文利用AES算法加密出行数据，隐藏出行者敏感信息，使用访问控制列表机制构建访问控制矩阵，限制客户端用户对CCF的调用权限，与Fabric既有隐私保护方法相比，提高了客户端数据请求的响应速率。本文方法目前存在的问题是不能对加密后的数据进行安全审计，无法在未知加密内容的情况下验证数据合法性。因此接下来将进行Fabric交易数据的可审计性研究。