基于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交易數據的可審計性研究。