基于PBFT的獼猴桃溯源聯盟鏈應用訪問控制方案

景 旭 邢勝飛

(西北農林科技大學信息工程學院， 陜西楊凌 712100)

0 引言

目前，區塊鏈以其公開透明、去中心化、不可篡改的特性，在銀行、能源、物聯網、健康、媒體等多個不同領域得到了應用[1]。根據不同的開放程度，區塊鏈分為公有鏈、私有鏈和聯盟鏈。公有鏈是一種完全開放的區塊鏈，幾乎沒有保護交易隱私，需要消耗大量的算力維護分布式賬本[2]。私有鏈是一個集中的區塊鏈，鏈上數據的訪問權限由單個組織控制，主要用于內部數據管理和特定組織的審計[3]。聯盟鏈由多個機構組成的聯盟構成，聯盟指定的成員進行賬本的生成、共識、維護，聯盟鏈可以完全公開也可以僅有內部人員訪問[4]。相比于公有鏈存在資源浪費、效率低下以及私有鏈存在中心化程度高的問題，聯盟鏈具有易擴大規模、成本較低、吞吐量較高的優勢[5]，尤其是被廣泛應用于供應鏈溯源領域。國內外學者已經從信息存儲與查詢[6]、隱私加密[7]、共識算法[8]、多鏈[9]、身份認證[10]、智能合約[11]等技術應用層面探討了聯盟鏈為供應鏈溯源帶來的優勢。文獻[12-15]都涉及到將供應鏈環節數據存儲到聯盟鏈上，保證溯源信息的安全性、完整性，但是沒有深入探討溯源系統用戶管理，增加了監管追責的難度，同時給數據的隱私性帶來了巨大的挑戰。訪問控制技術是保障數據安全和隱私最常用的方法之一，能夠很好地處理主體人員、客體數據以及業務流程之間的關系，因此研究聯盟鏈應用的訪問控制對于推動聯盟鏈的推廣和應用具有重要意義。

作為訪問控制的重要模型之一，由于能滿足聯盟鏈環境中細粒度訪問控制的需求，基于屬性的訪問控制(Attribute-based access control, ABAC)被廣泛應用。ABAC將主體和客體的屬性作為基本的決策要素，靈活利用請求者所具有的屬性集合決定是否賦予其訪問權限，能夠很好地將策略管理和權限判定相分離[16]。文獻[17-23]以ABAC為基礎，將屬性信息以及訪問控制策略以事務的方式存儲到聯盟鏈上；當主體發出訪問請求時，聯盟鏈記賬節點執行查詢處理，將權限相關信息返回到策略決策點；策略決策點決定是否允許主體執行操作。訪問控制過程順利執行的前提是聯盟鏈環境真實可信。聯盟鏈的準入機制表明節點的加入與退出需要滿足一定的條件并得到許可，但是并不能保證節點行為的可信性。聯盟鏈除了要面對由網絡中斷、機器宕機以及分布式拒絕服務攻擊等因素造成節點失效的崩潰故障外，還可能存在惡意節點篡改數據、發送錯誤數據以及故意拒絕響應請求等拜占庭故障。拜占庭故障的常見原因是敵對影響，例如惡意軟件注入和物理設備捕獲[24]。發生拜占庭故障的節點稱為拜占庭節點。相比崩潰故障，拜占庭故障更為嚴重。拜占庭節點可以將偽造的屬性信息以及訪問控制策略發送到策略決策點，導致策略決策點無法獲取到真實的數據而做出錯誤的決策，影響用戶訪問授權操作。

實用拜占庭容錯算法(Practical Byzantine fault tolerance, PBFT)是一種確保分布式系統與拜占庭故障節點一致性的通用解決方案[25]，將傳統拜占庭容錯算法的時間復雜度從指數級降低到多項式級[26]。針對拜占庭節點的惡意行為，當系統中拜占庭節點的數量不超過節點總數1/3的前提條件下，利用PBFT解決此類問題有可行性。

本文以ABAC為基礎，面向獼猴桃溯源，提出一種基于PBFT的獼猴桃溯源聯盟鏈應用訪問控制方案。訪問控制策略和屬性信息以交易的方式存儲在聯盟鏈上，確保權限的公開透明；用戶發起訪問請求后，基于PBFT對存儲在鏈上的訪問控制策略以及屬性信息進行查詢驗證，確保查詢結果的真實可信。以期提升獼猴桃溯源聯盟鏈應用的容錯率和可用性，推動聯盟鏈在農產品溯源的廣泛應用。

1 獼猴桃溯源聯盟鏈應用架構

獼猴桃產業鏈各環節參與的企業主體眾多，一般包括農資電商、生產合作社、加工企業、電商平臺等組織。農資電商主要業務包括向農資生產商采購農資、存儲、銷售等。生產合作社主要的業務包括向農資電商采購農資、種植、打藥、施肥、采摘、質檢、存儲、銷售等。加工企業主要業務包括向生產合作社采購獼猴桃、加工、存儲、銷售等。電商平臺主要業務包括向加工企業采購獼猴桃成品、存儲以及銷售等。除此之外，監管機構監察產業鏈的所有環節，保證獼猴桃產品的質量安全。各個組織相互獨立、相互合作，構成聯盟鏈中的聯盟單位。組織間的數據共享通過聯盟鏈實現。每個組織由多個部門組成，分別承擔不同的業務。各部門分工明確，部門人員各司其職，保證獼猴桃產業鏈的生產有序。

聯盟鏈的準入機制確保參與的多方實體存在一定的信任前提和利益約束，任何用戶只有獲取到聯盟鏈證書頒發機構(Certificate authority, CA)頒發的公鑰證書(Public key certificate, PKC)才具有與聯盟鏈交互的權限[27]。以Hyperledger Fabric為例，該架構為客戶端提供了2種角色，分別是普通用戶和管理員，普通用戶一般發起與應用有關的業務交易，管理員則發起與系統相關的配置交易[28]。聯盟鏈提供的身份認證技術無法完全滿足獼猴桃溯源場景中的復雜需求。

屬性證書(Attribute certificate, AC)由屬性權威(Attribute authority, AA)頒發，是一個包含序列號、發行人、持有人、有效期、屬性信息以及屬性權威數字簽名等的證書文件[29]。它主要用于用戶的權限管理，與PKC相關聯，但認證方式、生存期不同[30]，生命周期比較短。因此，本文利用AC輕量、靈活、可驗證的特點，存儲與權限相關的用戶屬性，確保屬性信息的真實、有效。權限更新時不會產生大量的證書撤銷列表(Cerificate revocation list, CRL)，減輕了證書管理的負擔。獼猴桃溯源聯盟鏈應用架構如圖1所示。

圖1 獼猴桃溯源聯盟鏈應用架構Fig.1 Kiwifruit traceability consortium blockchain application architecture

在圖1中，農資電商、生產合作社、加工企業、電商平臺、監管機構等組織作為實體節點加入聯盟鏈網絡。組織內涉及到的用戶如下：

(1)數據生產者：管理獼猴桃產業鏈各個環節的鏈上鏈下業務數據，實現上下游企業間的數據流通。

(2)監管人員：監督獼猴桃產業鏈各個生產環節，對出現質量問題的獼猴桃商品溯源與追責。

(3)管理員：負責權限以及證書管理，根據實際需求為數據制定相關訪問控制策略，并發布到聯盟鏈上。

(4)消費者：獼猴桃產業鏈的最終服務對象，可以從聯盟鏈上查詢獼猴桃商品的部分溯源信息。

獼猴桃溯源聯盟鏈應用中的所有用戶都需要向CA、AA登記注冊PKC以及AC。PKC唯一標識用戶在聯盟鏈網絡中的身份。AC主要用于權限管理。用戶訪問系統資源時，需要滿足訪問控制策略。

2 獼猴桃溯源聯盟鏈應用訪問控制

2.1 訪問控制設計思想

獼猴桃溯源聯盟鏈應用訪問控制的主要設計思想包括：

(1)基于公鑰基礎設施(Public key infrastructure, PKI)和特權管理設施(Privilege management infrastructure, PMI)的證書管理體系。獼猴桃溯源應用所使用的聯盟鏈網絡以Hyperledger Fabric為底層框架，通過成員服務提供者(Membership service provider, MSP)管理身份證書，通過PMI中的AC管理權限。管理流程包括：首先，為農資電商、生產合作社、加工企業、電商平臺、監管機構等組織各部署一個peer節點，承擔本組織記賬節點角色；其次，為每個組織部署一個CA，負責為本組織中的實體頒發身份證書；最后，為每個組織部署一個AA，承擔組織AC頒發機構以及查詢驗證節點角色。管理員將各組織AA的公鑰存儲到聯盟鏈上，AA節點需要從鏈上讀取其它組織AA的公鑰，形成節點索引表保存在本地。用戶都向本組織AA節點申請AC，并存儲到聯盟鏈上，以便于其它組織AA驗證。AA節點向本組織CA申請證書，獲得向記賬節點查詢數據的權限。用戶發出訪問請求后，各組織AA在向本組織記賬節點查詢權限信息時進行可信驗證。

(2)基于PBFT的獼猴桃溯源訪問控制方案。組織用戶訪問溯源系統資源時，需要所有AA節點通過PBFT查詢驗證用戶屬性、數據屬性、訪問控制策略，確保訪問控制的可信性；將查詢驗證結果作為執行用戶請求的判定標準；驗證結果中有超過節點總數2/3的節點允許用戶執行操作，則命令系統執行該請求；否則，系統拒絕執行用戶請求。

2.2 訪問控制分層模型

在基于PBFT的獼猴桃溯源聯盟鏈應用中，基于聯盟鏈中的PKC作為用戶身份憑證，以ABAC為基礎，引入AC管理用戶權限，基于PBFT提高訪問控制過程的容錯率，實現獼猴桃溯源的訪問控制方案。實現該方案的智能合約主要包括身份證書管理合約(Public key certificate management contract, PKCMC)、屬性證書管理合約(Attribute certificate management contract, ACMC)、訪問控制策略管理合約(Access control policy management contract, ACPMC)、數據屬性管理合約(Date attribute management contract, DAMC)、訪問控制合約(Access control policy, ACC)等。訪問控制分層模型如圖2所示。

圖2 訪問控制分層模型Fig.2 Access control hierarchical model

在圖2中，模型從上至下分別為應用層、服務層、數據層，具體內容為：

(1)應用層：主要為獼猴桃溯源聯盟鏈應用中的各類用戶提供相應功能。

(2)服務層：是訪問控制模型的核心層，提供聯盟鏈服務以及聯盟鏈可信查詢服務，主要由網絡服務、智能合約以及認證服務3部分組成。①網絡服務：提供了P2P網絡、共識機制、創建區塊等服務。

通過聯盟鏈網絡將用戶AC、數據、訪問控制策略等發送到各節點；數據經過共識機制共識驗證后，以交易的形式發布到聯盟鏈上，保證各節點間數據的一致性。②智能合約：通過部署智能合約來實現邏輯功能，是實現溯源系統訪問控制的工具。PKCMC用來頒發和管理用戶的身份證書。ACMC用來頒發和管理用戶的屬性證書。ACPMC用來存儲和管理訪問控制策略。DAMC用來存儲和管理數據的屬性。ACC用來響應用戶對數據的訪問請求。③認證服務：提供確保訪問控制真實可信的手段。主要包括CA、AA的部署，以及組織AA基于PBFT查詢驗證屬性信息、訪問控制策略。

(3)數據層：主要提供數據存儲服務。為降低聯盟鏈的存儲壓力，所有業務數據存儲在鏈下的數據服務器，鏈上只存儲業務數據的唯一標識以及散列值。訪問控制策略、用戶屬性、AA公鑰等非業務數據的數據量較少，而且數據狀態較穩定，所以將原始數據直接存儲在聯盟鏈上。

2.3 訪問控制建模

在獼猴桃溯源聯盟鏈應用訪問控制分層模型中，主要包括證書申請以及訪問控制2個過程。

2.3.1證書申請

獼猴桃產業鏈各組織用戶都需要申請身份證書作為聯盟鏈溯源系統的準入憑證，申請屬性證書存儲個人的權限信息。證書申請過程如圖3所示。

圖3 證書申請過程Fig.3 Certificate application process

在圖3中，用戶登錄系統后，首先，將身份信息作為PKCMC的參數向Fabric-CA申請身份證書；其次，將身份證書的唯一標識以及其他屬性信息作為ACMC的參數向AA申請AC；最后，將AC以二進制的方式發布在聯盟鏈上。組織內的管理員根據實際需求為數據制定相應的訪問控制策略，并發布到聯盟鏈。

2.3.2訪問控制

用戶訪問系統的任何資源都需要滿足相應的訪問控制策略。訪問控制過程如圖4所示。

圖4 訪問控制過程Fig.4 Access control process

在圖4中，AA1、AA2、AA3、AA4、AA5分別表示獼猴桃溯源聯盟鏈中農資電商、生產合作社、加工企業、電商平臺以及監管機構等組織的查詢驗證節點。當前視圖的主節點為AA1，從節點為AA2、AA3、AA4、AA5。假設AA5是拜占庭節點，可以在看似正常情況下發生任意行為，本文用虛線箭頭表示AA5篡改真實數據并向其他節點發送錯誤請求消息，即f=1，f表示聯盟鏈網絡中拜占庭節點的數量。依據PBFT的共識過程，主要包括request(請求)、pre-prepare(預準備)、prepare(準備)、commit(確認)和reply(響應)等5個階段。主要步驟如下：

(1)request：用戶通過與客戶端交互，向AA1節點發送請求消息〈REQUEST,t,d,h,c〉，其中，t為時間戳，d為用戶發送的請求內容，h為d的消息摘要，c為用戶的身份信息。

(2)pre-prepare：AA1節點接收到請求消息后，調用ACC為d分配一個編號n，開始判決用戶的訪問請求。首先，根據d中的用戶證書唯一標識調用ACMC查詢存儲在本組織記賬節點中的用戶AC，根據d中的數據屬性調用DAMC訪問存儲在數據服務器中的數據。其次，根據c獲取AC對應AA的公鑰以驗證AC。然后，根據用戶屬性、數據屬性以及d調用ACPMC查詢存儲在本組織記賬節點的訪問控制策略，將訪問控制策略、用戶屬性以及數據屬性發送給ACC決策，生成訪問控制結果。最后，向其它組織AA節點發送預準備消息〈PRE-PREPARE,v,n,d,h,c,u,o,p,r,i〉，其中，v為當前視圖編號，u為用戶屬性，o為數據屬性，p為訪問控制策略，r為訪問控制結果，i為當前節點的編號。

(3)prepare：AA2、AA3、AA4、AA5收到AA1發送的預準備消息后，首先，對d重新生成摘要并與h比對，確保消息的完整性。其次，判決用戶的訪問請求，與AA1的判決過程相同。然后，向其它組織AA節點發送準備消息〈PREPARE,v,n,i,h,u,o,p,r〉。最后，收到來自非AA1的準備消息后，與AA1的預準備消息進行對比驗證，驗證的內容有v、n、u、o、p、r、h。當有2f+1個來自不同AA節點的準備消息與預準備消息一致時，進入確認階段。

(4)commit：組織AA向其它節點發送確認消息〈COMMIT,v,n,i,S(u,o,p,r)〉，其中，S(u,o,p,r)為本節點對用戶屬性、數據屬性、訪問控制策略以及訪問控制結果的簽名。收到其它AA節點的確認消息后，通過i查找本地索引表中對應節點的公鑰，驗證確認消息的簽名和v、n、u、o、p、r。當有2f+1個確認消息通過驗證后，進入響應階段；否則，可信查詢失敗。

(5)reply：組織AA節點向客戶端發送響應消息〈REPLY,v,t,c,i,q,u,o〉，其中，q為用戶訪問請求的驗證結果。如果客戶端接收到至少f+1個相同的響應消息時，則根據q決定是否為用戶授權；否則，可信查詢失敗。

2.4 訪問控制管理函數

訪問控制管理函數通過將數學符號以及實體符號相結合來形式化地描述訪問控制流程，能夠準確地管理訪問控制過程[31]，為訪問控制智能合約的設計提供了基礎。管理員通過管理函數對數據進行有效管理，只有對各類數據做到高效和嚴格的管理，才能發揮最大的控制效能[32]。在獼猴桃溯源聯盟鏈應用訪問控制方案中，管理函數主要包括身份證書申請、屬性證書申請、訪問控制策略存儲到聯盟鏈、訪問授權等。管理函數由實體、屬性以及實體間關系組成。

實體是聯盟鏈溯源應用中實際參與訪問控制的集合，含義如表1所示。

表1 實體描述Tab.1 Entity description

屬性指實體與訪問控制相關的某些特征的集合。用戶、數據、訪問控制策略以及證書都有固有屬性。實體的屬性表示方法為：實體.attr，記為(屬性名，運算符，屬性值)，如s.attr=(ino=20152586)表示用戶的唯一標識為20152586。

實體間的關系是通過關系符號將各個實體集合連接起來，從而實現對實體屬性的操作。各實體之間的關系如下：

(1)(S,MKC):表示一對一的用戶與身份證書關系。如(s,pkc)∈(S,MKC)表示用戶擁有組織CA頒發的身份證書。

(2)(S,MAC):表示一對一的用戶與屬性證書的關系。如(s,ac)∈(S,MAC)表示用戶擁有組織AA頒發的AC。

(3)(s.attr,d.attr)：表示用戶屬性與數據屬性之間的關聯關系。

關系符號還包括∧、∪、?等。∧用于連接屬性需同時滿足的多個條件表達式。∪用于將單個實體合并到相應的實體集。?用于取實體集中任何一個實體的屬性。主要的管理函數定義如下：

(1)EnrollPKC(s,pkc)：為用戶頒發身份證書，ino唯一標識用戶。

條件:s∈S；

s.attr=(ino≠?∧ino≠?si.ino);

操作:MKC=MKC∪pkc, (s,pkc)∈(S,MKC).

(2)EnrollAC(s,ac)：為用戶頒發屬性證書，age、dep、role表示用戶的年齡、部門以及角色等。

條件: (s,pkc)∈(S,MKC)；

s.attr=(age,dep,role≠?);

s.attr=(ino≠?∧ino≠?si.ino);

操作:MAC=MAC∪ac, (s,ac)∈(S,MAC).

(3)UploadPolicy(p,P)：將訪問控制策略存儲在聯盟鏈上，on唯一標識訪問控制策略，con表示具體的訪問控制策略。

條件:p.attr(con≠?)；

p.attr=(no≠?∧no≠?pi.no);

操作:P=P∪p.

(4)ManageDate(r,s)：用戶發出請求r操作數據服務器中的數據。verify(ac,pk)表示使用AA的公鑰pk驗證用戶ac。query(Arr,p)表示根據用戶以及數據屬性集Arr查詢訪問控制策略。如果滿足訪問控制策略，則訪問數據Operation(D)。

條件: (s,pkc)∈(S,MKC)；

(s,ac)∈(S,MAC);

操作:s.attr=(ino≠?)=>ac;

s.attr=(age,dep,role≠?) (if verify(ac,pk));

d.attr=(attr1,attr2,…,attrn≠?);

Arr=(s.attr,d.attr);

Operation(D)(if query(Arr,p)).

3 獼猴桃溯源聯盟鏈應用訪問控制智能合約

獼猴桃溯源聯盟鏈訪問控制方案中主要涉及PKCMC、ACMC、ACPMC、DAMC、ACC等5個智能合約。

(1)PKCMC負責對用戶身份證書的頒發和管理，只有組織管理員有權執行。使用Hyperledger Fabric中CA頒發的證書作為聯盟鏈網絡的準入憑證。PKCMC主要定義的方法包括PublishPKC()、RevokePKC()、ReenrollPKC()，分別為用戶提供了頒發、撤銷、重新頒發身份證書的功能。以PublishPKC()為例，具體算法為：

PublishPKC(pkc.ino,pkc.pw, ca.name)

輸入: (pkc.ino, pkc.pw, ca.name)

輸出: ("Input Error/Register False/Enroll Success/Enroll Fail")

if (pkc.ino != null && pkc.pw != null && ca.name != null)

then flag = Register(pkc.ino, pkc.pw, ca.name)∥如果參數合法，開始身份證書登記

else return "Input Error"∥返回輸入參數不合法的結果

end if

if (flag) then flag1 = Enroll(pkc.ino, pkc.pw)∥如果身份證書登記成功，開始身份證書注冊

else return "Register False"∥返回身份證書登記失敗的結果

end if

if flag1 then reture "Enroll Success"∥如果身份證書注冊成功，返回注冊成功的結果

else return "Enroll Fail"∥返回身份證書注冊失敗的結果

end if

算法中，PublishPKC()由證書登記Register()和證書注冊Enroll()兩部分組成。pkc.ino、pkc.pw以及ca.name分別表示申請證書所使用的用戶標識、口令、CA名稱。Input Error、Register False、Enroll Success、Enroll Fail是申請身份證書的4種不同結果，分別表示輸入不合法、登記失敗、注冊成功、注冊失敗。

(2)ACMC負責對用戶的AC頒發和管理，只有組織管理員有權執行。ACMC主要定義的方法包括PublishAC()、RevokeAC()、ReenrollAC()、QueryAC()、ReadAC()、ValidateAC()，分別為用戶提供了頒發、撤銷、重新頒發、查詢、讀取以及驗證AC的功能。以PublishAC()為例，具體算法為

PublishAC(pkc.sk, pkc.pk, pkc.ino, s.a, aa.name)

輸入: (pkc.sk, pkc.pk, pkc.ino, s.a, aa.name)

輸出: ("MesInput Error/PkcInput Error/Validate Error/Issue Success/Issue Fail")

if (pkc.ino != null && s.a != null && aa.name != null)

then reture R∥如果參數合法，返回一個隨機數

else return "MesInput Error"∥返回屬性信息輸入不合法的結果

end if

if (pkc.sk != null && pkc.pk != null)∥判斷用戶是否擁有身份證書

then Signature = Sign(R, pkc.sk)∥用戶用私鑰對隨機數簽名

else return"PkcInput Error"∥返回公私鑰輸入不合法的結果

end if

flag = Validate(Signature, pkc.pk)∥屬性權威驗證用戶的簽名

if (flag) then flag1 = Issue(pkc.ino, s.a, aa.name)∥如果驗證通過，頒發屬性證書

else return"Validate Error"∥返回簽名驗證失敗的結果

end if

if flag1 then UploadChain(pkc.ino, AC)∥將屬性證書寫入聯盟鏈

then reture "Issue Success"∥返回屬性證書簽發成功的結果

else return "Issue Fail"∥返回屬性證書簽發失敗的結果

end if

算法中，PublishAC()包含用戶身份認證和AC頒發兩個過程。s.a、pkc.sk、pkc.pk分別表示用戶的屬性信息、私鑰、公鑰。R表示AA返回的隨機數。aa.name表示AA的名稱。Signature表示用戶對R形成的簽名信息。用戶向AA提交個人屬性信息以及對應PKC的標識，請求頒發AC。AA返回一個隨機數，用戶用私鑰對該隨機數簽名，形成簽名信息。AA根據用戶的公鑰驗證簽名，若為真，則通過用戶身份認證，AA簽發AC，并把AC寫入聯盟鏈。MesInput Error、PkcInput Error、Validate Error、Issue Success、Issue Fail是申請AC的5種不同結果，分別表示屬性信息輸入不合法、公私鑰輸入不合法、簽名驗證失敗、簽發成功、簽發失敗。

(3)ACPMC負責存儲和管理訪問控制策略，只有組織管理員有權執行。訪問控制策略存儲在聯盟上，確保權限的公開透明。ACPMC主要定義的方法包括UploadACP()、DownloadACP()，分別為管理員提供了向聯盟鏈發布以及讀取訪問控制策略的功能。以UploadACP()為例，具體算法為

UploadACP(acp)

輸入: (acp)

輸出: ("Input Error/Upload False/Upload Success")

if (acp != null) then acphash = Hash(acp)∥如果參數合法，將訪問控制策略生成散列值

else return "Input Error"∥返回參數輸入不合法的結果

end if

txID = PutState(acphash, acp)∥將訪問控制策略以及散列值存儲到聯盟鏈

if (txID != null) then return "Upload Success"∥如果交易ID不為空，返回寫入賬本成功的結果

else return "Upload False"∥返回寫入賬本失敗的結果

end if

算法中，UploadACP()主要由HyperLedger Fabric SDK提供的PutState()方法實現。acp表示訪問控制策略，acphash是訪問控制策略的唯一標識，經過散列函數生成。Input Error、Upload False、Upload Success是存儲訪問控制策略的3種不同結果，分別表示輸入不合法、寫入賬本失敗、寫入賬本成功。

(4)DAMC用來存儲和管理業務數據，只有非組織管理員有權執行。業務數據存儲在鏈下的云服務器中，聯盟鏈存儲對應的散列值。DAMC主要定義的方法包括UploadDate()、DownloadDate()、AddDate()、UpdateDate()、QueryDate()，分別實現了業務數據的鏈上發布、鏈上查詢、鏈下添加、鏈下更新、鏈下查詢等功能。以DownloadDate()為例，具體算法為

DownloadDate(Dateno)

輸入: (Dateno)

輸出:("Input Error/Download False/Download Success")

if (Dateno != null) then ChainHash = GetState(Dateno) ∥如果參數合法，從鏈上獲取數據散列值

else return "Input Error"∥返回參數輸入不合法的結果

end if

Date = QueryDate(Dateno) ∥查詢鏈下數據服務器中的原始數據

DateHash = Hash(Date)∥對鏈下原始數據生成散列值

if (ChainHash == DateHash) then return "Download Success"

∥如果鏈上散列值與鏈下散列值一致，返回查詢成功的結果

else return "Download False"∥返回查詢失敗的結果

end if

算法中，DownloadDate()主要由HyperLedger Fabric SDK提供的GetState()方法實現。Dateno表示數據唯一標識，ChainHash是存儲在聯盟鏈上的數據散列值，Date是存儲在云服務器中的數據屬性，DateHash是Date的鏈下散列值。DateHash與ChainHash的對比驗證，保證鏈上鏈下數據的一致性。Input Error、Download False、Download Success是查詢鏈上業務數據的3種不同結果，分別表示輸入不合法、查詢失敗、查詢成功。

(5)ACC用來響應用戶對數據的訪問請求，組織的任何用戶都有權執行。ACC定義的方法主要是AccessControl()，具體算法為

Grantaccess(Sno, Dateno, AAno)

輸入: ( Sno, Dateno, AAno)

輸出: ("MesInput Error/ResInput Error/ValidateAC Fail/Grant Success/Grant Fail")

if (Sno != null && Dateno != null && AAno != null)

then AC = ACMC.QueryAC(Sno)∥如果參數合法，從鏈上查詢屬性證書

Date = DAMC.QueryDate(Dateno)∥查詢鏈下數據服務器中的原始數據

else return "MesInput Error"∥返回參數輸入不合法的結果

end if

if (Date!= null && AC != null)

then AAPK = QueryAAPK(AAno)∥查詢屬性權威的公鑰

flag =ACMC.ValidateAC(AC, AAPK)∥驗證用戶屬性證書

else return "ResInput Error"∥返回屬性證書或者原始數據查詢失敗的結果

end if

if (flag)then SubAttr = ACMC.ReadAC(AC)∥如果屬性證書驗證通過，則讀取用戶屬性

else return "ValidateAC Fail"∥返回屬性證書驗證失敗的結果

end if

Result = ACPMC.DownloadACP(SubAttr, ObjAttr)∥查詢鏈上的訪問控制策略

If (Result) then reture "Grant Success"∥如果查詢到相應的訪問控制策略，則允許用戶訪問

else return "Grant Fail"∥返回拒絕訪問的結果

end if

算法中，AccessControl()主要由ACMC.QueryAC()、DAMC.QueryDate、QueryAAPK()、ACMC.ValidateAC()、ACMC.ReadAC()、ACPMC.DownloadACP()等方法組成。ACMC.QueryAC()是智能合約ACMC提供的AC查詢方法，可以查詢用戶存儲在聯盟鏈上的AC。DAMC.QueryDate是智能合約DAMC提供的原始數據查詢方法，可以獲取到存儲在鏈下數據服務器中的原始數據。QueryAAPK()提供了在本地索引表中查詢AA公鑰的功能。ACMC.ValidateAC()智能合約ACMC提供的AC驗證方法，利用AA公鑰驗證AC的合法性以及有效性。ACMC.ReadAC()是智能合約ACMC提供的AC讀取方法，用戶AC驗證通過后，解析讀取AC中的屬性信息。ACPMC.DownloadACP()是智能合約ACPMC提供的訪問控制策略查詢方法，可以決策用戶是否有相應的權限。Sno表示主體唯一標識，Dateno表示數據唯一標識，AAno表示AA節點編號，AAPK表示AA公鑰，SubAttr表示用戶屬性，Date表示數據屬性，Result表示訪問控制策略查詢結果。MesInput Error、ResInput Error、ValidateAC Fail、Grant Success、Grant Fail是判決訪問請求的5種不同結果，分別表示請求內容不合法、AC或者數據屬性查詢失敗、AC驗證失敗、允許訪問、拒絕訪問。

4 獼猴桃溯源聯盟鏈應用訪問控制測試與分析

本文選用農資電商、生產合作社、加工企業、電商平臺等4個組織負責獼猴桃溯源“產購儲加銷”全產業鏈各個環節。為使得全鏈條溯源更為全面，將消費者權益組織加入聯盟鏈網絡，在保護消費者權益的同時，為消費者從組織記賬節點查詢獼猴桃產品溯源信息提供了便利。以包含5個組織的獼猴桃溯源全產業鏈為例，評測基于PBFT的獼猴桃溯源聯盟鏈應用訪問控制方案的功能與性能。

4.1 測試環境

(1)聯盟鏈網絡：選用Hyperledger Fabric 1.4.0搭建聯盟鏈。Org1.peer0、Org2.peer0、Org3.peer0、Org4.peer0、Org5.peer0等peer節點充當組織記賬節點，獨立部署1個order節點和5個CA證書。狀態數據庫采用levelDB。區塊的最大交易數為10筆，最大打包時間間隔為2s，最大字節數為10MB。

(2)拜占庭共識算法：采用corgi-kx的PBFT算法(https:∥github.com/corgi-kx/blockchain_ consensus_algorithm, 2019-12-1)，AA1、AA2、AA3、AA4、AA5充當查詢驗證節點。

(3)屬性證書：遵循X.509 v3標準，簽名算法選用RSA。

(4)性能測試工具：Hyperledger Caliper。它是一個通用的區塊鏈性能測試框架，允許用戶使用自定義的用例測試不同的區塊鏈解決方案，得到一組性能測試結果。

(5)系統環境：ubuntu虛擬機18.04，8 GB內存，50 GB存儲磁盤，處理器內核總數為2，帶寬為1 000 Mb/s。

4.2 功能測試

(1)訪問控制策略的數據結構

訪問控制策略P={U_age, U_dep, U_role，D_dep, D_tem, D_attr1, D_attr2，…，D_attrn，Operation}，其中，U_age、U_dep、U_role分別表示管理員的年齡、所屬部門以及角色；D_dep、D_tem分別表示業務數據的來源以及類別；D_attr1，…，D_attrn表示業務數據的屬性；Operation表示訪問能力。

假設生產合作社某一條訪問控制策略p1={大于25歲，種植部門，業務管理員，幼苗培育部門，溫室數據，日期，查詢}，表示年紀25歲以上的種植部門業務管理員有權查詢某一個時間段的幼苗培育部門中的溫室數據。

(2)訪問控制可信決策過程

以生產合作社種植部門的業務管理員查詢某一個時間段幼苗培育部門的溫室數據為例。溫室數據由物聯網設備直接寫入鏈下的數據庫中，由幼苗培育部門的業務管理員存儲到聯盟鏈。本次查詢是從鏈下的數據庫中獲取溫室數據并進行防偽驗證。業務管理員唯一標識為20152586，用戶屬性集為{大于25歲，種植部門，業務管理員}，訪問控制策略p1，用戶發起訪問請求的頁面如圖5所示。

圖5 用戶發起訪問請求界面Fig.5 User initiated an access request

在圖5中，業務管理員選擇數據的來源、類別以及時間范圍，即數據屬性集為{幼苗培育部門，溫室數據，2022-03-13 19:10_2022-03-14 21:10}，訪問能力為查詢操作。業務管理員發出查詢請求后，系統判決其是否具有相應權限，訪問控制過程的可信決策如圖6所示。

圖6 訪問控制過程的可信決策Fig.6 Trusted decisions for access control processes

從圖6可以看出，當種植部門的業務管理員發出訪問控制請求后，聯盟鏈各組織的的AA節點基于PBFT對訪問授權過程可信驗證，客戶端依據可信驗證結果決定業務管理員的權限。訪問控制請求內容由管理員唯一標識、數據類型、數據來源、日期、查詢操作構成。主節點AA1收到客戶端發來的請求消息后，執行過程如圖6a所示。從節點AA2、AA3、AA4、AA5收到AA1發來的預準備消息后，執行過程如圖6b～6e所示。各節點通過訪問請求內容獲取到的用戶屬性集為{32歲，種植部門，業務管理員}，數據屬性集為{幼苗培育部門，溫室數據，2022-03-13 19:10_2022-03-14 21:10}，訪問控制策略為{大于25歲，種植部門，業務管理員，幼苗培育部門，溫室數據，日期，查詢}。

基于PBFT，各節點對用戶屬性、數據屬性以及訪問控制策略可信驗證的具體工作流程如圖7所示。

圖7 節點工作流程Fig.7 Node workflow

在圖7中，首先，主從節點先后查詢驗證AC、讀取用戶屬性、讀取數據屬性以及決策訪問控制請求，并分別廣播預準備消息和準備消息到其他節點；其次，所有節點對比驗證準備消息與預準備消息，驗證通過后，使用私鑰對權限相關信息簽名，廣播確認消息到其他節點；最后，各節點驗證確認消息，根據確認結果，向客戶端發送回復消息。

根據訪問控制過程的可信決策結果可知，業務管理員擁有相應的操作權限，系統響應請求頁面如圖8所示。

圖8 系統響應請求頁面Fig.8 System responded to request page

在圖8中，頁面顯示的溫室數據是從鏈下數據庫中獲取到的原始數據，種植部門的業務管理員需要執行防偽驗證操作從聯盟鏈上查詢原始數據的散列值，與數據庫中現有數據實時生成的散列值進行對比驗證，確保原始數據的一致性。

以工作ID為82的溫室數據為例，防偽驗證的結果如圖9所示。

圖9 防偽驗證Fig.9 Anti-counterfeiting verification

從圖9可以看出，鏈上數據包含一個鍵值對(Key，Value)，其中，Key為溫室數據的記錄時間，唯一標識該數據，Value為數據的散列值。只有存儲到聯盟鏈上的數據才可以進行防偽驗證，確保鏈下數據的完整性。由驗證結果可知，鏈上數據的散列值與鏈下數據實時形成的散列值完全一致，說明該數據自上鏈以后未被篡改，查詢結果真實可信。

(3)鏈碼的核心操作

由訪問控制可信決策過程可看出，主節點AA1以及從節點AA2、AA3、AA4分別在預準備階段和準備階段到各自組織的記賬節點上查詢管理員屬性證書、鏈上的數據散列值以及訪問控制策略。通過Hyperledger Fabric的命令行模式直接調用ACMC.QueryAC()、DAMC.DownloadDate()以及ACPMC.DownloadACP()函數查詢管理員屬性證書、鏈上的數據散列值以及訪問控制策略，查詢結果與通過HyperLedger Fabric SDK調用鏈碼查詢出的結果保持一致，執行過程如圖10所示。

圖10 鏈碼的核心操作Fig.10 Core operation of chaincode

由圖10可以看出，聯盟鏈賬本上存儲管理員屬性證書的Key為20152586，Value為以字節形式表示的證書內容；賬本上存儲訪問控制策略p1的Key為05c9f82c6f69c39f10db7449859b5c33cf636c5 4075 3e4f423c296a4c32b8e0a，Value為{大于25歲，種植部門，業務管理員，幼苗培育部門，溫室數據，日期，查詢}；賬本上存儲溫室數據的Key為2022-03-13 19:42:41，Value為76e9da3cc23dca65a7c1c6 e65847a525da7fb3db7424a5dd76b77ec5863c88a6。

4.3 性能測試

4.3.1測試方案

通過模型共識過程可以看出，數據處理請求發出到響應的時間主要由區塊鏈查詢時間決定，因此，主要測試不同交易總量、交易發送率條件下的訪問控制策略鏈上查詢效率。用交易吞吐量以及平均時延作為主要性能評估指標。通過設置相應的基準測試用例以及相關的配置文件來模擬測試不同條件下的網絡性能。測試方案如下：

(1)基本參數為訪問控制策略p1。

(2)交易總量分別為1 000、2 000、3 000條，對應測試方案1、方案2和方案3。

(3)交易發送率分別為100、200、…、1 400、1 500 TPS，TPS表示每秒向系統提交的并發交易量。

(4)每輪重復10次，取均值作為交易吞吐量和平均時延的最終結果。

4.3.2測試與分析

(1)交易吞吐量是指區塊鏈網絡每秒成功處理的交易數，當一筆交易讀寫到區塊鏈上，該交易處理成功。訪問控制策略查詢的交易吞吐量測試結果如圖11所示。

圖11 訪問控制策略查詢的交易吞吐量Fig.11 Transaction throughput for access control policy queries

由圖11可以看出，3種方案在交易發送率達到300 TPS前，交易吞吐量線性上升；在交易發送率達到300 TPS后，交易吞吐量總體趨于穩定。這是由于隨著交易發送率越來越大，消息隊列堵塞，磁盤讀寫速度變慢造成的。當交易發送率為800、1 000、1 100 TPS時，3種方案的交易吞吐量達到最高值。當交易發送率相同時，向聯盟鏈提交交易總量越高，交易吞吐量越高。

(2)平均時延是指一筆交易從發起交易請求到收到交易處理結果所經歷的時間間隔。訪問控制策略查詢的平均時延測試結果如圖12所示。

圖12 訪問控制策略查詢的平均時延 Fig.12 Average latency for access control policy queries

由圖12可看出，3種方案在交易發送率400 TPS前平均時延波動較大；在交易發送率400 TPS后平均時延基本穩定。這是由于隨著交易發送率增加，消息隊列堵塞，導致磁盤讀寫速度變慢造成的。在相同交易發送率條件下，向聯盟鏈提交交易總量越高，平均時延越高。

5 結論

(1)針對基于屬性的聯盟鏈應用訪問控制模型可能存在拜占庭節點而導致屬性信息、訪問控制策略不可信的問題，以獼猴桃溯源為應用場景，利用屬性證書真實、有效、可驗證以及PBFT具備拜占庭容錯能力的特點，提出了基于PBFT的獼猴桃溯源聯盟鏈應用訪問控制方案。所有用戶申請AC，存儲與權限相關的屬性。管理員將訪問控制策略存儲在聯盟鏈上。用戶發出訪問請求后，組織AA調用智能合約查詢鏈上的AC、訪問控制策略以及數據服務器中的數據屬性，并基于PBFT查詢驗證用戶屬性、數據屬性、訪問控制策略的可信性，以決定是否為用戶授權。

(2)基于Hyperledger Fabric獼猴桃溯源應用的測試結果可以看出，通過訪問控制可信決策、核心鏈碼測試表明方案合理、可行；通過不同交易總量、交易發送率條件下的訪問控制策略鏈上查詢性能測試表明交易吞吐量和平均時延均能達到穩定狀態，交易吞吐量在交易發送率為300 TPS后趨于穩定，平均時延在交易發送率為400 TPS后趨于穩定，基本滿足聯盟鏈系統的應用需求。該方案具有良好的可用性和性能，保證了訪問控制過程的可信性以及一致性，提高了獼猴桃溯源應用的安全性、容錯性。