馬 娜，戚 湧，嚴(yán) 悍

(南京理工大學(xué) 計算機(jī)科學(xué)與工程學(xué)院，江蘇 南京 210094)

0 引 言

出行數(shù)據(jù)作為智能交通系統(tǒng)(intelligent transportation systems，ITS)的基礎(chǔ)數(shù)據(jù)，涉及出行者個人隱私，通常由ITS終端設(shè)備采集上傳到數(shù)據(jù)中心，被各機(jī)構(gòu)所共享，共享過程中不乏出現(xiàn)非法用戶攻擊ITS、竊取出行者隱私的現(xiàn)象，使出行者人身和財產(chǎn)安全受到嚴(yán)重威脅[1,2]。因此，如何在共享環(huán)境下進(jìn)行出行數(shù)據(jù)隱私保護(hù)已經(jīng)成為ITS發(fā)展急需解決的重要問題?，F(xiàn)有方案大都采用數(shù)據(jù)聚合[3]、數(shù)據(jù)加密[4]、匿名認(rèn)證[5]等方法，盡管可以緩解部分隱私保護(hù)問題，并不能完全確保數(shù)據(jù)共享中的個人隱私安全。

區(qū)塊鏈作為一種分布式數(shù)據(jù)庫[6]，可以為數(shù)據(jù)共享提供機(jī)密性和完整性保障，是一種解決共享環(huán)境隱私保護(hù)問題的新渠道[7]，目前已被用在金融[8,9]、醫(yī)療[10,11]、智能交通[12-14]等領(lǐng)域。但大部分都是基于比特幣或以太坊進(jìn)行研究，交易驗證速率較慢，難以滿足現(xiàn)實場景中的性能需求。許可區(qū)塊鏈Hyperledger Fabric(以下簡稱Fabric)具有高安全性和高擴(kuò)展性，可以滿足多數(shù)情況下的吞吐量需求[15]。因此，本文提出一種基于Fabric的出行數(shù)據(jù)隱私保護(hù)方法，對出行數(shù)據(jù)的上傳與查詢進(jìn)行隱私保護(hù)，從而提高共享環(huán)境下出行者的個人隱私安全。

1 基于Fabric的出行數(shù)據(jù)隱私保護(hù)模型

Fabric作為主流的許可區(qū)塊鏈開源項目，以認(rèn)證授權(quán)的方式限制節(jié)點、用戶的加入，有助于增強(qiáng)區(qū)塊鏈交易數(shù)據(jù)的隱私安全。因此，本文采用Fabric平臺構(gòu)建出行數(shù)據(jù)隱私保護(hù)模型。

如圖1所示，模型主要分為4個模塊，分別是客戶端模塊、Web服務(wù)與中間件模塊、智能合約模塊以及Fabric區(qū)塊鏈數(shù)據(jù)庫模塊。

圖1 基于Fabric的出行數(shù)據(jù)隱私保護(hù)模型

1.1 客戶端模塊

客戶端模塊分為數(shù)據(jù)上傳終端和數(shù)據(jù)訪問終端。數(shù)據(jù)上傳終端包括ITS中能夠采集出行數(shù)據(jù)的所有終端設(shè)備，如車載GPS設(shè)備、視頻檢測器等；數(shù)據(jù)訪問終端包括需要訪問或監(jiān)控出行數(shù)據(jù)的所有終端系統(tǒng)，如出行服務(wù)提供商的交通數(shù)據(jù)訪問系統(tǒng)、公安部門的交通監(jiān)測系統(tǒng)等。所有客戶端用戶都需要在Fabric中進(jìn)行注冊登記，執(zhí)行客戶端請求前需要驗證當(dāng)前用戶的身份有效性。

1.2 Web服務(wù)與中間件模塊

Web服務(wù)負(fù)責(zé)基礎(chǔ)業(yè)務(wù)邏輯支撐，提供出行數(shù)據(jù)相關(guān)業(yè)務(wù)處理。中間件負(fù)責(zé)提供便攜式數(shù)據(jù)交互接口，簡化Fabric與Web服務(wù)之間的操作邏輯，從而滿足快速、高并發(fā)的客戶端請求。當(dāng)Web服務(wù)收到客戶端請求時，中間件驗證當(dāng)前用戶身份，身份有效則調(diào)用智能合約模塊，執(zhí)行客戶端請求。

1.3 智能合約模塊

Fabric中智能合約又稱為鏈碼(Chaincode)，其中用戶自定義數(shù)據(jù)接口稱為鏈碼函數(shù)(chaincode function，CCF)。智能合約模塊分為隱私數(shù)據(jù)鏈碼函數(shù)(private chaincode function，PCCF)和鏈碼函數(shù)控制(chaincode function control，CCFC)模塊?？紤]到Fabric區(qū)塊鏈數(shù)據(jù)庫中存儲的數(shù)據(jù)對所有接入節(jié)點和用戶可見，對于涉及個人隱私的敏感數(shù)據(jù)，采用加密技術(shù)隱藏數(shù)據(jù)的真實內(nèi)容。當(dāng)智能合約模塊接收到數(shù)據(jù)請求時，PCCF調(diào)用中間件對數(shù)據(jù)進(jìn)行加解密處理。鑒于Fabric中所有接入節(jié)點和用戶共享智能合約代碼，需要限制用戶對CCF的調(diào)用權(quán)限，由CCFC調(diào)用中間件獲取當(dāng)前客戶端用戶的身份證書，根據(jù)證書信息判斷請求的有效性，有效則執(zhí)行對應(yīng)鏈碼邏輯。

1.4 Fabric區(qū)塊鏈數(shù)據(jù)庫模塊

模型采用非關(guān)系型數(shù)據(jù)庫CouchDB作為Fabric數(shù)據(jù)存儲庫，以鍵-值形式記錄區(qū)塊鏈交易與用戶的相關(guān)信息，確保數(shù)據(jù)操作的高可伸縮性、高可用性以及高可靠性。CouchDB中存儲的信息包括用戶證書、出行數(shù)據(jù)、訪問權(quán)限等。

2 關(guān)鍵模塊設(shè)計與實現(xiàn)

2.1 Fabric區(qū)塊鏈數(shù)據(jù)庫和中間件設(shè)計

2.1.1 Fabric區(qū)塊鏈數(shù)據(jù)庫接口

(1)putRec(k,v)： 向CouchDB中添加一條鍵為k、 值為v的交易記錄，該接口通常在產(chǎn)生新的區(qū)塊鏈交易時被調(diào)用。

(2)getRec(k)： 根據(jù)鍵k從CouchDB中讀取一條記錄的最新狀態(tài)，該接口通常在請求查詢區(qū)塊鏈交易時被調(diào)用。

(3)getHis(k): 根據(jù)鍵k， 查詢CouchDB中的交易歷史修改記錄，該接口通常在查詢區(qū)塊鏈交易憑證時被調(diào)用。

(4)genCert(u)： 為用戶u生成身份證書，該接口通常在用戶注冊時被調(diào)用，除了認(rèn)證中心保存身份證書信息以外，CouchDB中也要進(jìn)行記錄，便于智能合約模塊驗證客戶端身份。

2.1.2 中間件接口

(1)getCert(u)： 查詢并解析用戶u的身份證書。當(dāng)智能合約模塊接收到數(shù)據(jù)請求時，先從CouchDB中讀取當(dāng)前客戶端的用戶身份證書，解析證書屬性，智能合約模塊根據(jù)屬性信息判斷該用戶是否具有CCF調(diào)用權(quán)限。以getCert(U) 為例，偽代碼如下：

//讀取用戶U的身份證書

identityCertU=getCreator(U)

//解析證書屬性

certU=analysisCert(identityCertU)

(2)genKey(k)： 生成密鑰k。 在本文模型中，生成密鑰指初始化智能合約時，采用最流行的高級加密標(biāo)準(zhǔn)[16](advanced encryption standard，AES)算法，生成256位的初始對稱密鑰。為確保數(shù)據(jù)存儲安全，每一次使用的密鑰都要經(jīng)過哈希加鹽。本文使用的AES256算法，安全性高，非常適合模型中的數(shù)據(jù)加密。

(3)encrypt(k,r)： 用密鑰k加密交易記錄r的部分屬性，即對r中隱私屬性PriAttr的相關(guān)信息進(jìn)行加密，得到含有密文的記錄。以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解密相關(guān)信息，得到屬性的真實內(nèi)容，解密過程與加密過程類似。

2.2 智能合約模塊

2.2.1 鏈碼消息交互過程

智能合約是基于預(yù)訂時間觸發(fā)、不可篡改、自動執(zhí)行的一段程序，具有自治性、強(qiáng)制性和自我驗證功能。Fabric中智能合約(鏈碼)是連接客戶端與Fabric區(qū)塊鏈數(shù)據(jù)庫的重要組件，分為系統(tǒng)鏈碼和用戶鏈碼。系統(tǒng)鏈碼負(fù)責(zé)交易背書、系統(tǒng)配置等邏輯處理，固化在系統(tǒng)中；用戶鏈碼由用戶編寫，負(fù)責(zé)執(zhí)行自定義處理邏輯，運(yùn)行在Docker容器中，與Peer節(jié)點通過gRPC連接，雙方通過發(fā)送Chaincode-Message消息進(jìn)行交互通信，交互過程如圖2所示。

圖2 鏈碼與Peer節(jié)點之間的消息交互過程

步驟1 創(chuàng)建好gRPC連接后，鏈碼向Peer節(jié)點發(fā)送REGISTER消息進(jìn)行注冊，等待接收Peer節(jié)點的回應(yīng)消息，此時狀態(tài)為created；

步驟2 Peer節(jié)點收到REGISTER消息后，將其注冊到本地的Handler結(jié)構(gòu)中，返回REGISTERED消息給鏈碼，此時，Peer節(jié)點狀態(tài)為established。鏈碼收到REGISTERED消息后，不進(jìn)行任何操作，更新狀態(tài)為established，鏈碼注冊完成。

步驟3 Peer節(jié)點向鏈碼發(fā)送READY消息，更新狀態(tài)為ready。鏈碼收到READY消息后也更新狀態(tài)為ready。

步驟4 Peer節(jié)點向鏈碼發(fā)送INIT消息，對鏈碼進(jìn)行初始化。

步驟5 鏈碼容器收到INIT消息后，調(diào)用Init方法進(jìn)行初始化，成功后返回COMPLETED消息給Peer節(jié)點，鏈碼初始化完成，此時鏈碼狀態(tài)為可被調(diào)用狀態(tài)。

步驟6 Peer節(jié)點向鏈碼發(fā)送TRANSACTION消息，執(zhí)行鏈碼調(diào)用。

步驟7 鏈碼收到TRANSACTION消息之后，調(diào)用Invoke方法，執(zhí)行具體CCF，并向Peer節(jié)點發(fā)送數(shù)據(jù)庫操作消息。

步驟8 Peer節(jié)點收到數(shù)據(jù)庫操作消息后，執(zhí)行相應(yīng)的數(shù)據(jù)操作，并向鏈碼返回RESPONSE消息。

步驟9 鏈碼調(diào)用完成后發(fā)送COMPLETE給Peer節(jié)點。

步驟10 以上消息交互過程當(dāng)中，Peer節(jié)點和鏈碼會定期相互發(fā)送KEEPALIVE消息給對方，以確保彼此處于在線狀態(tài)。

2.2.2 隱私數(shù)據(jù)鏈碼函數(shù)

(1)隱私數(shù)據(jù)存儲

步驟1 Peer節(jié)點向智能合約發(fā)送封裝好的交易提案，請求調(diào)用隱私數(shù)據(jù)存儲鏈碼函數(shù)(write private data chaincode function，WPDCCF)，此時默認(rèn)智能合約模塊已完成初始化。

步驟2 智能合約收到交易提案后，根據(jù)提案中的請求信息驗證當(dāng)前用戶的WPDCCF調(diào)用權(quán)限，權(quán)限有效則可以調(diào)用。

步驟3 WPDCCF根據(jù)提案參數(shù)創(chuàng)建隱私數(shù)據(jù)結(jié)構(gòu)體，封裝隱私屬性PriAttr和非隱私屬性PubAttr。

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

步驟4 調(diào)用中間件encrypt(k,r) 進(jìn)行加密處理，依次加密數(shù)據(jù)的PriAttr屬性信息。

步驟5 加密完成后，執(zhí)行putRec(k,v)， 將數(shù)據(jù)存儲至區(qū)塊鏈中，成功后向Peer發(fā)送完成消息。偽代碼如下：

算法1: 隱私數(shù)據(jù)查詢存儲函數(shù)

(1)Input:TravelRecord

(2)Output:Success

(3)begin

(4)//根據(jù)TravelRecord創(chuàng)建隱私數(shù)據(jù)結(jié)構(gòu)體

(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)隱私數(shù)據(jù)查詢

步驟1 Peer節(jié)點向智能合約發(fā)送交易提案，請求調(diào)用隱私數(shù)據(jù)查詢鏈碼函數(shù)(read private data chaincode function, RPDCCF)。

步驟2 收到交易提案后，智能合約驗證客戶端的RPDCCF調(diào)用權(quán)限，有效則可以調(diào)用該CCF。

步驟3 RPDCCF執(zhí)行g(shù)etRec(k)， 從數(shù)據(jù)庫中讀取記錄的當(dāng)前狀態(tài)。

步驟4 調(diào)用中間件decrypt(k,r) 執(zhí)行解密邏輯，解密該記錄的PriAttr屬性。

步驟5 將解密后的數(shù)據(jù)返回給Peer節(jié)點。偽代碼如下：

算法2: 隱私數(shù)據(jù)查詢鏈碼函數(shù)

(1)Input:RID

(2)Output:NewRecord

(3)begin

(4) // 根據(jù)RID從CouchDB中獲取交易記錄

(5)PrivateRecord←getRec(RID)

(6)NewRecord←decrypt(K,PrivateRecord)

(7) returnNewRecord

(8) end

2.2.3 鏈碼函數(shù)權(quán)限控制

(1)設(shè)置訪問控制矩陣

本文采用訪問控制列表(access control list，ACL)機(jī)制控制用戶對CCF的調(diào)用權(quán)限。ACL是一種普遍使用的訪問控制機(jī)制，按照列表的方式存儲訪問控制矩陣(access control matrix，ACM)，從而驗證主體的訪問權(quán)限[17]。在本文模型中，根據(jù)用戶注冊時登記的身份信息(所屬機(jī)構(gòu)Org和用戶角色Role)，每一個用戶都對應(yīng)一個有效CCF集合。如表1所示，每一行代表一個CCF對象，每一列代表一個用戶主體，每一項代表用戶對CCF的訪問權(quán)限，例如，當(dāng)機(jī)構(gòu)為O2、 角色為R2時，該用戶的有效CCF集合為 {RPDCCF,getRec,getHis}， 可調(diào)用集合內(nèi)的所有CCF。

表1 訪問控制矩陣

為提高PCCF的可用性和持久性，需要設(shè)置訪問控制矩陣，對調(diào)用權(quán)限進(jìn)行動態(tài)管理，使用add(acm,org,role,ccf) (添加新權(quán)限)、 update(acm,org,role,ccf) (更新權(quán)限)管理區(qū)塊鏈中的權(quán)限信息，出現(xiàn)非法調(diào)用時通過getHis(k) 查詢訪問控制矩陣的歷史修改記錄，根據(jù)相關(guān)憑證進(jìn)行追責(zé)，偽代碼如下：

算法3： 設(shè)置訪問控制矩陣

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

(2)Output:Success

(3)begin

(4)//讀取已有矩陣信息

(5)ACM←getRec("AccessControlMatrix")

(6) if(TypeOP為新增權(quán)限操作)

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

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

(9)else if(TypeOP為更新權(quán)限操作)

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

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

(12)else{無效操作類型}

(13)returnSuccess

(14)end

(2)驗證CCF調(diào)用權(quán)限

在調(diào)用指定CCF之前，需要先查詢區(qū)塊鏈中已有的權(quán)限信息，執(zhí)行g(shù)etCCFs(org,role)， 獲取當(dāng)前用戶的有效CCF集合，驗證該用戶的調(diào)用權(quán)限是否有效，有效則執(zhí)行對應(yīng)鏈碼邏輯，否則返回訪問受限信息，偽代碼如下：

算法4: 驗證CCF調(diào)用權(quán)限

(1)Input:CCFName,UID

(2)Output: 1或0

(3)begin

(4)//讀取UID的身份證書

(5)CertU←getCert(UID)

(6)if(存在CertU)

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

(8) //根據(jù)CertU判斷權(quán)限是否有效

(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 數(shù)據(jù)存儲保密性

本文模型中所有出行數(shù)據(jù)存儲在區(qū)塊鏈上，非區(qū)塊鏈認(rèn)證用戶或節(jié)點不能共享數(shù)據(jù)。在WPDCCF中，上傳至區(qū)塊鏈的敏感信息都經(jīng)過AES加密處理，加解密速度快，密鑰經(jīng)過哈希加鹽，即使得到初始密鑰，也不能查看數(shù)據(jù)的真實內(nèi)容，可以確保數(shù)據(jù)存儲的絕對保密性。

3.2 數(shù)據(jù)訪問安全性

本文模型中所有用戶在訪問過程中都需要經(jīng)過從Web服務(wù)層到智能合約層的多層身份驗證，數(shù)據(jù)訪問安全性高。Web服務(wù)層驗證用戶身份是否有效，即是否已經(jīng)在區(qū)塊鏈中進(jìn)行登記注冊；智能合約層根據(jù)已頒發(fā)的身份證書，在CCFC模塊中判斷用戶是否具有CCF的調(diào)用權(quán)限。出現(xiàn)非法操作時，通過查詢訪問控制矩陣的歷史修改信息，可以進(jìn)行相關(guān)的法律追責(zé)。

4 實驗與結(jié)果分析

4.1 實驗方案

本文所提出模型主要面向區(qū)塊鏈用戶，控制不同用戶的數(shù)據(jù)訪問權(quán)限，因此，本實驗的目的是得到高并發(fā)請求、高負(fù)載情況下，本文模型、原生Fabric(無隱私保護(hù))以及Fabric中面向節(jié)點的隱私保護(hù)方法3種方法在處理客戶端請求時的性能測試結(jié)果，通過評估測試結(jié)果來驗證本文模型的可行性。測試指標(biāo)分為每秒處理事務(wù)(即請求)數(shù)(transactions per second，TPS)和每個事務(wù)的平均響應(yīng)時間(time per transaction，TPT)，TPS用于評估單位時間內(nèi)的可處理數(shù)據(jù)請求數(shù)，TPT用于評估指定并發(fā)量下處理一個數(shù)據(jù)請求所需要的時間。

本實驗主要針對用戶的上傳數(shù)據(jù)請求和訪問數(shù)據(jù)請求進(jìn)行測試，使用CPU規(guī)格為Intel(R)Core(TM) i7-6700@3.40 GHz、四核八線程的主機(jī)，模擬執(zhí)行10輪次、不同并發(fā)量的數(shù)據(jù)請求，計算各并發(fā)量下的平均TPS和平均TPT，最后對結(jié)果進(jìn)行分析。

4.2 實驗結(jié)果及分析

4.2.1 訪問數(shù)據(jù)請求測試結(jié)果

如圖3、圖4所示，橫軸表示訪問數(shù)據(jù)請求的并發(fā)量，縱軸表示各并發(fā)量下的平均TPS或平均TPT，并發(fā)量的范圍從0到5000依次增加，間隔為100。從圖3可以看出，相同并發(fā)量下，本文模型與原生Fabric(無隱私保護(hù))的單位時間可處理請求數(shù)目基本一致，都多于面向節(jié)點的隱私保護(hù)方法。從圖4可以看出，同一并發(fā)量下，本文模型與原生Fabric的平均響應(yīng)時間基本一致，都少于面向節(jié)點的隱私保護(hù)方法。并發(fā)量為1100～1900時，性能較為穩(wěn)定；并發(fā)量為2000時，平均響應(yīng)時間約為2.5 s。因此，基于Fabric的出行數(shù)據(jù)隱私保護(hù)模型在執(zhí)行訪問數(shù)據(jù)請求時，沒有降低Fabric本身的性能，并且性能明顯高于面向節(jié)點的隱私保護(hù)方法。

圖3 訪問數(shù)據(jù)請求平均TPS測試結(jié)果

圖4 訪問數(shù)據(jù)請求平均TPT測試結(jié)果

4.2.2 上傳數(shù)據(jù)請求測試結(jié)果

如圖5、圖6所示，橫軸表示上傳數(shù)據(jù)請求的并發(fā)量，縱軸表示各并發(fā)量下的平均TPS或平均TPT。并發(fā)量范圍從0到2000依次增加，間隔為100。從圖5可以看出，同一并發(fā)量下，本文模型與原生Fabric的單位時間可處理上傳數(shù)據(jù)請求數(shù)目基本一致，都遠(yuǎn)多于面向節(jié)點的隱私保護(hù)方法。如圖6所示，對于平均響應(yīng)時間的測試，本文模型與原生Fabric相差不大，都少于面向節(jié)點的隱私保護(hù)方法。并發(fā)量大于1500時，性能較為穩(wěn)定；并發(fā)量為2000時，平均響應(yīng)時間約為35 s。因此，基于Fabric的出行數(shù)據(jù)隱私保護(hù)模型在執(zhí)行上傳數(shù)據(jù)請求時，沒有降低Fabric性能。

圖5 上傳數(shù)據(jù)請求平均TPS測試結(jié)果

圖6 上傳數(shù)據(jù)請求平均TPT測試結(jié)果

5 結(jié)束語

本文提出了一種基于Fabric的出行數(shù)據(jù)隱私保護(hù)方法，考慮到Fabric平臺中交易數(shù)據(jù)、智能合約代碼對網(wǎng)絡(luò)中所有節(jié)點和用戶完全開放共享，本文利用AES算法加密出行數(shù)據(jù)，隱藏出行者敏感信息，使用訪問控制列表機(jī)制構(gòu)建訪問控制矩陣，限制客戶端用戶對CCF的調(diào)用權(quán)限，與Fabric既有隱私保護(hù)方法相比，提高了客戶端數(shù)據(jù)請求的響應(yīng)速率。本文方法目前存在的問題是不能對加密后的數(shù)據(jù)進(jìn)行安全審計，無法在未知加密內(nèi)容的情況下驗證數(shù)據(jù)合法性。因此接下來將進(jìn)行Fabric交易數(shù)據(jù)的可審計性研究。