蔣家昊，張 璇,2,3+，鄧宏鏡，王 杰，黃河祥

(1.云南大學 軟件學院，云南 昆明 650000；2.云南大學 云南省軟件工程重點實驗室，云南 昆明 650000；3.云南大學 教育部跨境網(wǎng)絡空間安全工程研究中心，云南 昆明 650000)

0 引言

目前，由于互聯(lián)網(wǎng)通信技術(shù)和物聯(lián)網(wǎng)技術(shù)的快速發(fā)展，大數(shù)據(jù)已經(jīng)滲透到生活中，良好的數(shù)據(jù)交互方式為各部門、各企業(yè)提供了便捷的數(shù)據(jù)共享，企業(yè)或政府部門可以利用大數(shù)據(jù)技術(shù)挖掘海量數(shù)據(jù)中的潛在價值，以幫助自身提高服務質(zhì)量、了解用戶意愿、推動產(chǎn)業(yè)升級[1]。在實際應用中，部門之間往往通過云服務器、物聯(lián)網(wǎng)等方法進行數(shù)據(jù)交互，從而使存儲和計算資源得到充分利用。然而，這些訪問方式仍然存在安全隱患，集中式管理方法可能導致數(shù)據(jù)泄露，無法保障數(shù)據(jù)訪問的安全性。例如，在邊境口岸出入境業(yè)務流程中，面向國際貿(mào)易的出入境人員首先需要申請各種許可證書，其需要在公安局、海關(guān)部門、工商局、交管等多個不同部門之間往返，這些部門間需要經(jīng)常共享和訪問數(shù)據(jù)，如何確保數(shù)據(jù)的一致性、真實性、完整性和合法性顯得尤為重要。

目前，面向多部門間的訪問控制模型均基于單一的訪問控制技術(shù)，如基于角色的訪問控制(Role-Based Access Control, RBAC)、基于屬性的訪問控制(Attribute-Based Access Control, ABAC)等，然而這些技術(shù)各有弊端。例如，RBAC缺乏對管理員授權(quán)操作的限制，容易濫用角色權(quán)限，ABAC容易暴露敏感屬性。為了提高多部門多企業(yè)間數(shù)據(jù)共享的安全性，改善現(xiàn)有訪問控制模型的不足，本文面向邊境口岸的出入境信息共享業(yè)務，基于HyperledgerFabric聯(lián)盟鏈，混合基于屬性、能力的訪問控制技術(shù)，提出一種基于區(qū)塊鏈的多部門數(shù)據(jù)共享訪問控制方法CABAC(capability-attribute based access control)。CABAC模型在繼承ABAC模型靈活性的基礎(chǔ)上引入能力令牌，通過不同角色各自具有的屬性分配相應的訪問權(quán)限，并生成相應的能力令牌，用戶可以根據(jù)訪問策略將自身擁有的能力令牌委派給其他用戶，獲得能力令牌的用戶便能對訪問對象執(zhí)行相應的操作。相比現(xiàn)有的訪問控制模型，該模型優(yōu)化了繁瑣重復的身份驗證過程，允許具有相同屬性的用戶之間進行能力委派，具有更好的靈活性。同時，與其他基于能力的訪問控制(Capability-Based Access Control, CBAC)模型不同，本文的能力令牌用單個能力劃分，一個用戶可以同時擁有多個能力令牌，因此在權(quán)限委派上具有更細的粒度。

本文的主要貢獻如下：

(1)首次提出混合基于屬性和能力訪問控制模型的數(shù)據(jù)共享訪問控制方案，通過開發(fā)鏈碼在實施訪問控制的前提下引入CBAC，以更細的粒度進行訪問能力的生成與委派，目前尚未有類似的方案。

(2)針對面向多部門的出入境場景提出基于HyperledgerFabric聯(lián)盟鏈和星際文件系統(tǒng)(InterPlanetary File System, IPFS)的無中心安全信息存儲管理框架，對信息業(yè)務管理流程進行建模、闡述和分析，同時提供了標準可信的業(yè)務操作流程，能夠保證多部門協(xié)同過程中的數(shù)據(jù)不可篡改，而且業(yè)務流程按照約定的順序執(zhí)行，更符合多部門間數(shù)據(jù)共享的要求。

1 相關(guān)工作

1.1 中心化的訪問控制

訪問控制技術(shù)最早可以追溯到1960年代提出的多級安全概念，由許多規(guī)則和法規(guī)組成，旨在對訪問計算、存儲、服務等資源設置條件，以確保安全訪問信息。隨著技術(shù)的發(fā)展，出現(xiàn)了自主訪問控制(Discretionary Access Control, DAC)和強制訪問控制(Mandatory Access Control, MAC)，然后產(chǎn)生RBAC[2-3]和ABAC[4]。RBAC將用戶映射到角色，通過角色享有許可，通過定義不同角色與其之間的關(guān)系來規(guī)范用戶的行為，然而在開放的網(wǎng)絡環(huán)境中，RBAC無法適應復雜的環(huán)境，且存在角色爆炸問題；ABAC針對復雜信息系統(tǒng)中的細粒度訪問控制和大規(guī)模用戶動態(tài)擴展問題，將實體屬性的概念聯(lián)系在一起，通過對主體、客體、權(quán)限和環(huán)境統(tǒng)一建模進行訪問控制。GUSMEROLI等[5]提出CBAC模型，訪問權(quán)限以令牌(token)的形式存在，通過為實體賦予權(quán)限實施訪問控制，同時支持權(quán)限的委派和撤銷。然而，以上模型均基于中心化的架構(gòu)，用戶無法得知自己數(shù)據(jù)被使用的情況。隨著云端技術(shù)與區(qū)塊鏈技術(shù)的成熟，傳統(tǒng)訪問控制模型的弊端逐漸顯露出來。

1.2 基于區(qū)塊鏈的訪問控制

自從NAKAMOTO等[6]首次提出比特幣區(qū)塊鏈后，區(qū)塊鏈技術(shù)即被廣泛應用于金融、醫(yī)療、交通等領(lǐng)域。訪問控制技術(shù)可以很好地與區(qū)塊鏈技術(shù)結(jié)合，達到對共享數(shù)據(jù)、物聯(lián)網(wǎng)設備和公共服務的訪問控制。CRUZ等[7]將RBAC與以太坊智能合約結(jié)合，提出使用智能合約的基于角色的訪問控制(Role Based Access Control using Smart Contract, RBAC-SC)框架，采用智能合約創(chuàng)建和分配用戶角色，同時提出質(zhì)詢—響應協(xié)議對角色的所有權(quán)、分配權(quán)進行驗證；ZHU等[8]通過集成ABAC和區(qū)塊鏈技術(shù)，將基于事務的訪問控制(Transaction-Based Access Control, TBAC)運用于數(shù)字資產(chǎn)管理服務，開發(fā)了DAM-Chain數(shù)字資產(chǎn)管理平臺，能夠保存和發(fā)布主體與對象，發(fā)起訪問請求并授權(quán)。為了解決物聯(lián)網(wǎng)(Internet of Things, IoT)設備分布廣泛但資源有限，難以采用傳統(tǒng)方法抵御惡意攻擊的問題，ZHANG等[9]同樣提出一種RABAC方案，其在區(qū)塊鏈網(wǎng)絡中將節(jié)點分為授權(quán)節(jié)點和公共節(jié)點，將IoT設備與區(qū)塊鏈分開，引入授權(quán)節(jié)點充當區(qū)塊鏈客戶端，授權(quán)節(jié)點可以通過查詢部署過的鏈碼，檢索已經(jīng)注冊的訪問憑證，來驗證請求者的身份及訪問策略的有效性；NAKAMURA等[10]以CBAC為基礎(chǔ)，通過以單獨的能力作為基本單位來定義能力令牌，將傳統(tǒng)的能力令牌劃分為多個單獨的能力令牌，實現(xiàn)了更細粒度的訪問控制和更靈活的令牌管理；QI等[11]考慮區(qū)塊鏈分布式的基礎(chǔ)架構(gòu)將物聯(lián)網(wǎng)中的產(chǎn)品信息直接存儲在鏈上會導致數(shù)據(jù)管理的效率和隱私問題，開發(fā)了Cpds壓縮數(shù)據(jù)共享框架，通過鏈下的方式在參與者將數(shù)據(jù)提交到區(qū)塊鏈上之前對數(shù)據(jù)進行壓縮和加密，用戶使用時再根據(jù)策略解密，使大型工業(yè)系統(tǒng)通過安全有效的方式存儲和訪問大量產(chǎn)品數(shù)據(jù)；ZHANG等[12]為解決智能電網(wǎng)數(shù)據(jù)共享中的隱私保護和數(shù)據(jù)安全問題，提出一種具有隱私保護的多權(quán)限屬性加密方案；LYU等[13]提出一個基于區(qū)塊鏈的安全訪問控制框架，引入基于區(qū)塊鏈的訪問令牌機制實現(xiàn)對內(nèi)容的共享、審核和撤銷，同時引入布谷鳥過濾器提高驗證中令牌訪問查詢的效率；YANG等[14]提出一種基于屬性加密和區(qū)塊鏈技術(shù)的醫(yī)療數(shù)據(jù)共享方案，該方案結(jié)合基于屬性的加密和基于屬性的簽名，實現(xiàn)了數(shù)據(jù)隱私和細粒度的訪問控制機制；ULLAH等[15]提出一種基于區(qū)塊鏈的數(shù)據(jù)共享和訪問控制系統(tǒng)用于物聯(lián)網(wǎng)設備之間的通信，該系統(tǒng)通過訪問控制智能合約實現(xiàn)了物聯(lián)網(wǎng)中數(shù)據(jù)共享的信任、授權(quán)和認證；XU等[16]提出一種具有魯棒性的、基于身份的能力令牌管理策略，利用智能合約對訪問控制進行注冊、委派和撤銷；BANERJEE等[17]為了使用物聯(lián)網(wǎng)環(huán)境中的數(shù)據(jù)，提出具有恒定大小密鑰和密文的多權(quán)限屬性加密方案；LIANG等[18]為了解決集中式醫(yī)療服務系統(tǒng)中的信息孤島問題，提出一個基于輕量級信息共享的醫(yī)療區(qū)塊鏈系統(tǒng)，使用交織編碼器對原始電子病歷進行加密。不同于已有工作，本文提出一種混合訪問控制框架，在ABAC的基礎(chǔ)上結(jié)合CBAC，能夠以更細粒度的模式實現(xiàn)訪問能力的生成和委托，同時在數(shù)據(jù)存儲上引入IPFS來減輕區(qū)塊鏈的數(shù)據(jù)存儲壓力。

2 總體框架設計

本章介紹了CABAC框架，模擬了不同部門對邊境口岸出入境信息的訪問控制流程，通過制定適當?shù)脑L問策略和屬性也可將本框架拓展到其他領(lǐng)域。與現(xiàn)有工作不同的是，本文首次提出一種混合訪問控制框架，該框架在RABAC中引入CBAC，可在實施訪問控制的前提下以更細的粒度進行訪問能力的委派。

任何訪問控制系統(tǒng)的目的都是誰(主體)可以對什么資源(對象)進行什么操作(或設置權(quán)限)[5]，本文設計的訪問控制框架涉及如下元素：

S={si}，為系統(tǒng)中所有主體的集合；

O={oj}，為系統(tǒng)中所有對象的集合；

OP={opk}，為系統(tǒng)中聲明的操作的集合(如讀、寫、執(zhí)行)；

C={cl}，為系統(tǒng)中所有環(huán)境上下文的集合(如時間)；

CAP={capm}，為系統(tǒng)中所有能力令牌的集合。

訪問控制系統(tǒng)可以定義為

opk∈OP,cl∈C,capm∈CAP

for somei,j,k,l,m。

該規(guī)則表示任意一個訪問控制系統(tǒng)都能由連接了主體S、對象O、操作OP、環(huán)境上下文C和能力令牌CAP的規(guī)則集∑n定義。

出入境人員和各部門人員可以通過智能手機或個人電腦訪問區(qū)塊鏈網(wǎng)絡，從而執(zhí)行訪問控制，如圖1所示。圖中，本文所提框架由聯(lián)盟區(qū)塊鏈和IPFS組成，主要參與者有檢疫部門、交管部門、海關(guān)部門和公安部門。由于在邊境口岸出入境信息共享業(yè)務流程中涉及海量數(shù)據(jù)，包括圖片類型的數(shù)據(jù)(如許可證、車輛的照片等)，區(qū)塊鏈技術(shù)可以提供數(shù)據(jù)共享查詢通道，但是存在缺陷。例如區(qū)塊的大小限制了存儲在區(qū)塊鏈上的文件數(shù)量和類型，在比特幣區(qū)塊鏈中，每個區(qū)塊的大小僅為1 M，能夠存儲的信息十分有限，因此本文用IPFS以鏈下存儲的方式對區(qū)塊鏈的可存儲行進行拓展，將圖片文件存儲在IPFS中，同時將其返回的Hash值存儲到區(qū)塊鏈上，檢索時只需要對應文件的Hash值即可在IPFS中查詢到相應的文件。訪問控制部分主要涉及屬性管理合約(Attribute Management Contract, AMC)、策略管理合約(Policy Management Contract, PMC)、令牌生成合約(Token Generation Contract, TGC)、令牌管理合約(Token Management Contract, TMC)和訪問控制合約(Access Control Contract, ACC)5個智能合約。在訪問控制過程中，AMC負責存儲和管理主體和對象的屬性，PMC負責存儲和管理訪問控制策略，TGC負責根據(jù)策略生成相應的能力令牌，TMC負責存儲和管理已有的能力令牌，ACC負責基于以上信息響應訪問請求，智能合約的詳細設計見3.1節(jié)。

2.1 實現(xiàn)訪問控制的智能合約設計

在圖1所示的CABAC框架中涉及AMC，PMC，ACC，TGC，TDC 5個智能合約，其中AMC，PMC，ACC與RABAC有關(guān)，負責存儲和管理主體、對象屬性與訪問策略；TGC和TDC與CBAC有關(guān)，負責生成和委派相應的能力令牌。

(1)AMC負責對主體和對象的屬性進行存儲和管理。AMC由管理員部署，而且只有管理員有權(quán)限執(zhí)行它。在本文模擬的多部門系統(tǒng)中，主體可以為各個部門中的職員，管理員可以為各部門中的行政主管，如果主體為物聯(lián)網(wǎng)中的設備，則管理員可以為其擁有者。為了區(qū)分不同的主體，每個主體都有唯一的標識符指定其身份，對象同理。在本系統(tǒng)中，用HyperledgerFabric中證書頒發(fā)機構(gòu)CA頒發(fā)的證書作為身份標識信息，如表1中的“MI9ZT…”。表1所示為主體屬性和對象屬性的舉例展示，例如主體[MI9ZT…]的姓名為Alice，所屬部門為海關(guān)，所屬科室為稅務室，職位為主管等；對象[FU1B3]是姓名為“Bob”的物聯(lián)網(wǎng)設備，所屬部門為檢疫部門，所屬科室為食品檢驗處。AMC還定義了SubjectGet()，SubjectAdd()，SubjectDel()，ObjectGet()，ObjectAdd()，ObjectDel()方法，分別用于獲取、添加、刪除主體和對象的屬性。

表1 主體、對象的屬性

(2)PMC負責存儲和管理本文定義的訪問策略，與AMC相同，只能由管理員(對象的擁有者)執(zhí)行。在本文中，訪問策略定義為一組主體屬性(SA)、一組對象屬性(OA)、一組訪問能力(Cap)和一組環(huán)境上下文(Cxt)的組合，即在環(huán)境上下文Cxt下，具有SA屬性的主體可以對具有OA屬性的對象進行Cap操作。在訪問能力Cap中設置了兩個參數(shù)，第1個true/false代表是否具有該能力，第2個1/0代表是否可以對該能力進行進一步委派。在環(huán)境上下文Cxt中設置了一個參數(shù)Parm，如果Parm為0則不運用動態(tài)訪問控制，如果為1則需要再設置開始時間StartTime和結(jié)束時間EndTime，表示只有在這段時間內(nèi)才能訪問該對象。表2舉例說明了一個訪問控制策略，主體屬性SA={部門:海關(guān),科室:稅務室,職位:主管},對象屬性OA={部門:檢疫部門,科室:食品檢驗處},訪問能力Cap={Read,Write,Execute,Degelated},環(huán)境上下文Cxt={Parm:1,StartTime:1622505600,EndTime:1625043600}。其中StartTime和EndTime為Unix時間戳，代表在北京時間2021年6月1日8時～2021年6月30日17時，海關(guān)部門的稅務室主管可以對檢疫部門食品檢驗處的信息進行讀、寫和執(zhí)行操作，同時可以將這些能力進一步委派給下一個主體。與文獻[19]不同的是，由于訪問策略不針對某個特定主體或?qū)ο?，一個策略可以限定多個主體和對象之間的訪問控制，這些策略均以表格的形式存儲在PMC中，同時該合約中還定義了policyGet()，policyAdd()，policyDelete()，policyUpdate()方法，可以對訪問策略進行獲取、增加、刪除、和修改操作。

表2 訪問策略示例

續(xù)表2

(3)TGC負責在ACC通過主體的訪問請求后，根據(jù)訪問策略為其生成相應的能力令牌，同時提供了tokenGenerate()方法，用于生成能力令牌。本文參考NAKAMURA等[10]的工作，將傳統(tǒng)包含多個操作的能力令牌拆分為單獨的能力令牌，能力令牌不再以主體為單位，而是以一個單一的授權(quán)能力作為單位，即不像之前的CBAC方案為每個主體頒發(fā)一個能力令牌，而是為每一個授權(quán)的能力創(chuàng)建一個單獨的令牌。能力令牌的結(jié)構(gòu)定義為

CAPSo[IDs][IDo][OP]=

{IDp,{IDCh},Dep,DR}。

(1)

式中：IDs為主體的身份標識；IDo為訪問對象的身份標識；OP為一系列操作的集合，如讀取、寫入、執(zhí)行等，如果為NULL，則不允許對資源進行操作；IDp為給主體S賦予權(quán)限的父主體的身份標識；IDch為主體S賦予權(quán)限的子主體的身份標識；Dep為令牌在委托樹中的深度；DR表示是否可以進一步委派權(quán)限。

以表2為例，如果ACC通過主體的訪問請求，TGC則會為該主體生成相應的3個能力令牌，即讀(read)能力令牌、寫(write)能力令牌和執(zhí)行(execute)能力令牌。

(4)TMC負責存儲和管理主體已經(jīng)獲得的能力令牌。在主體獲得其授權(quán)的能力令牌后，若訪問策略中的委派參數(shù)為1，則允許主體進一步委派或撤銷其所有能力令牌。該方案具有更細的粒度，能夠允許主體委派和撤銷某個單一能力，主體間的委派關(guān)系以樹的數(shù)據(jù)結(jié)構(gòu)進行存儲。PMC提供了tokenGet()，tokenDelegate()方法，用于獲取主體已經(jīng)獲得的令牌和主體對自己已擁有令牌的委派，圖2所示為3個主體間的委派關(guān)系。主體A擁有讀、寫和執(zhí)行3個能力令牌，通過委派權(quán)限為True可以看出這3個能力均可委派給別的主體，主體A將讀和寫能力授予主體B，將執(zhí)行能力授予主體C，同時指定賦予主體B的“讀”能力可以進一步委派，而“寫”能力不可以進一步委派，賦予主體C的“執(zhí)行”能力可以進一步委派。讀、寫和執(zhí)行能力令牌中的子主體分別變?yōu)锽，B，C，而且B，C主體中的委派樹深度在委派完成后都變?yōu)?。

(5)ACC負責響應從主體到對象的訪問請求，在本框架中起決定作用。主體對某個對象發(fā)起訪問請求時，需要將請求信息以事務的形式發(fā)送給ACC的accessControl()方法，請求信息包括主體標識、對象標識和操作。當ACC收到該事務后，會從AMC中獲取主體和對象屬性，再從PMC中查詢是否有相應的訪問策略。隨后，ACC從TMC中查詢主體是否已經(jīng)具有對該對象的能力令牌，若該主體之前就曾獲得過訪問該對象的能力令牌，則ACC直接通過訪問請求；若主體未擁有能力令牌，則ACC基于這些屬性、訪問策略決定是允許該主體對對象的訪問申請，然后將響應結(jié)果返回給主體和對象。

2.2 多部門協(xié)同訪問控制流程建模

本文面向的業(yè)務場景主要涉及文件上傳和訪問控制流程兩個過程，本章將對這兩個業(yè)務過程進行建模。

2.2.1 區(qū)塊鏈/IPFS存儲數(shù)據(jù)流程

IPFS與區(qū)塊鏈的存儲數(shù)據(jù)流程如圖3所示，首先將文件上傳到IPFS，再將返回的存儲地址哈希值以事務的形式提交到區(qū)塊鏈中。

算法1contentaddressedhash。

Require:ImageFiles //網(wǎng)絡中節(jié)點上傳的圖片文件

1:file←request.file['upload'] //初始化IPFS

2:api←ipfsapi.connect['localhost',4 200] //存入IPFS的源文件

3:res←api.add(file) //返回二進制編碼

4:Hv←convert(file,binary) //創(chuàng)建源文件的二進制索引碼

5:digest←ch('sha 256').update(file).digest()

6:Mds←(digest.bytelength.toString(16),'hex') //返回基于內(nèi)容尋址的哈希值

7:content_addressed←combine(Hv,Mds,digest)

8:return content addressed hash

各部門上傳文件到IPFS的執(zhí)行流程如算法1所示[20]，算法描述如下：文件由網(wǎng)絡中的peer節(jié)點上傳，首先用ipfsapi.connect()方法建立與IPFS的連接，再調(diào)用add()方法將圖片文件存儲到IPFS中，文件將會被切分為碎片，每一個不超過256 kB，用convert()方法將其轉(zhuǎn)換為二進制格式后作為輸入進行一次SHA256哈希運算[13]得到一個digest值，將digest值轉(zhuǎn)換為十六進制得到該文件基于內(nèi)容尋址的哈希值。

2.2.2 訪問控制流程

整個訪問控制流程中各合約的交互過程如圖4所示。首先，主體將對目標對象的訪問信息以事務的方式發(fā)送給ACC，ACC接收到來自主體的信息后，從AMC中查詢并獲取主體和對象的屬性。接著，ACC從PMC中查詢是否有相應的訪問策略，否則將禁止訪問的結(jié)果返回給主體，是則從TMC中查詢該主體是否擁有訪問對象的能力令牌；如果主體之前就擁有該對象的能力令牌，則將允許訪問的結(jié)果返回給主體，否則調(diào)用TGC為其生成相應的能力令牌。最后，ACC將響應結(jié)果返回給主體。訪問控制流程如算法2所示。

算法2AccessControlProcess。

Require:Subject_ID,Object_ID,Operations

//訪問主體的ID，訪問對象的ID以及對訪問對象執(zhí)行的操作

1:AccessRequest←Acc.accessControl(Subject_ID,Object_ID,Operations) //AMC返回主體和對象的屬性

2:Subject_attributes←AMC.SubjectGet(Subject_ID)

3:Object_attributes←AMC.ObjectGet(Object_ID) //PMC返回匹配的訪問策略

4:AccessControlPolicy←PMC.policyGet(Subject_attributes，Object_attributes)

5:if AccessControlPolicy!=“”

6:Allowed_Capabilities←AccessControlPolicy.Capability

7:end if //查詢主體是否擁有訪問令牌

8:Subject.token←TMC.tokenGet(Subject_ID)

9:if Subject.token==“”

10:Subject.token←TGC.tokenGenerate(Allowed_Capabilities)

11:end if

12:return Subject.token

主體對對象發(fā)起的訪問控制流程如算法2所示，算法描述如下：主體首先調(diào)用ACC的accessControl()方法，將自身的ID、訪問對象的ID、對訪問對象進行的操作作為輸入，AMC調(diào)用SubjectGet()和ObjectGet()方法獲取主體與對象的屬性，隨后調(diào)用PMC中的policyGet()方法獲取相應的訪問策略，如果訪問策略不為空，則TMC調(diào)用tokenGet()方法查詢主體是否之前已經(jīng)獲得過對象的訪問能力令牌，如果為空，則調(diào)用tokenGenerate()方法為主體生成策略中定義的能力令牌，將結(jié)果返回給主體和對象。

算法3TokenDelegationProcess。

Require:SubjectA_ID,SubjectB_ID,CapabilityToken

1:DelegationRequest←TMC.tokenDelegate(SubjectA_ID,SubjectB_ID,CapabilityToken,1,)

//主體A將自己的能力令牌委派給對象B

2:SubjectA.token←TMC.tokenGet(SubjectA_ID)

3:if CapabilityToken==SubjectA.token

4:if SubjectA.token.DelegationRight==1 //主體A的能力令牌是否可以進行委派

5:SubjectB.token←TGC.tokenGenerate(SubjectA.token.Capability)

6: SubjectB.token.Parent←SubjectA_ID

7:SubjectB.token.Dep+=1

8: SubjectB.token.DelegationRight←1

9: end if

10:end if

10:return SubjectB.token

主體間的令牌委派流程如算法3所示，算法描述如下：主體A想將自己的能力令牌CapabilityToken委派給主體B，使其擁有和自己同樣的能力。首先主體A調(diào)用TMC中的tokenDelegate()方法，將自己的ID、主體B的ID、想要委派的能力令牌、是否允許進一步委派作為輸入；然后TMC調(diào)用tokenGet()方法查詢主體A是否擁有該能力令牌，如果查詢結(jié)果與A的能力令牌匹配，則為B生成相同的能力令牌，并逐一修改令牌中的參數(shù)(父主體Parent、委派深度Dep、進一步委派權(quán)限D(zhuǎn)elegationRight)；最后將能力令牌返回主體B。

3 CABAC實驗分析

通過仿真實驗對本文所提CABAC框架的有效性進行驗證。實驗環(huán)境如下：操作系統(tǒng)為Ubuntu 18.04.5，CPU為Inter(R) Core(TM) i7-10700 CPU @ 2.90 GHz，內(nèi)存大小為16 GB，HyperledgerFabric版本為1.4.0，node.js版本為10.13.0，npm版本為6.4.1。測試區(qū)塊鏈網(wǎng)絡運行在單臺主機上，包括兩個CA和一個Orderer節(jié)點。

3.1 訪問控制實例

傳統(tǒng)的RABAC模型在訪問過程中通過主體和對象屬性決定是否允許訪問。由于混合了CBAC，相比基于單獨機制的訪問控制，本文方案在整個訪問流程中包含有關(guān)能力令牌生成與委派的相關(guān)步驟。通過生成細化到單獨操作的能力令牌，例如read操作能夠以更細粒度限制主體對訪問對象進行的操作，同時令權(quán)限的分配和管理更加靈活。

本章模擬了一個訪問控制過程實例：部門數(shù)據(jù)管理員將文件上傳到IPFS并獲取哈希值QmSyzwqkCnp8waXtx7BqUN15DWPAGg9gCWgYeH

n81MnrFK，如圖5所示；管理員為主體A添加主體屬性，如圖6所示；主體A對對象B發(fā)起訪問請求，獲得能力令牌并將該能力令牌委派給主體C。首先，ACC調(diào)用TGC中的tokenGeneration()ABI后，根據(jù)PMC中的訪問策略為主體生成相應的能力令牌。圖7所示為主體A的“read”能力令牌，該令牌表明主體A可以對對象B進行read操作，因為是新生成的令牌，所以沒有父主體，也沒有子主體，相應地在委派樹中的深度也為0。DelegationRight表明主體A可以將該令牌進行進一步委派。與NAKAMURA等[10]的方案不同的是，本文方案默認所有能力令牌的委派均可撤回。

主體A將該“read”能力令牌委派給主體C后，能力令牌的信息如圖8所示?？梢奃epth從0變成1，表示該令牌在委派樹中的深度為1，即有過一次委派關(guān)系。

最終ACC會返回訪問請求信息，如圖9所示。ACC通過與其他幾個合約交互驗證了主體A和對象B的屬性，并根據(jù)匹配的訪問策略賦予主體A“read”能力令牌，同時指定該“read”令牌可進一步委派。

3.2 區(qū)塊鏈網(wǎng)絡性能

3.2.1 存儲空間性能

本文使用的數(shù)據(jù)為云南省各口岸班車運營數(shù)據(jù)，包括20萬條記錄。

存儲空間壓縮比

(2)

式中：H為區(qū)塊鏈中每個區(qū)塊頭數(shù)據(jù)量的大??；iHash為事務在IPFS中的哈希值；N為區(qū)塊鏈中事務的數(shù)量；Tx為區(qū)塊鏈中每個事物的數(shù)據(jù)量。區(qū)塊頭為80 B，每個區(qū)塊平均包括500個交易，每個交易約為250 B。IPFS返回的哈希值只占46 B。由公式可以推出隨著交易數(shù)量的增加，數(shù)據(jù)的壓縮比明顯增加。圖10和圖11所示分別為數(shù)據(jù)壓縮比隨數(shù)據(jù)量的變化，以及區(qū)塊鏈直接存儲數(shù)據(jù)和存儲IPFS文件哈希值的數(shù)據(jù)量對比。可見，隨著數(shù)據(jù)量的增大，源數(shù)據(jù)與返回哈希值的占用存儲空間比越大，用IPFS進行鏈下存儲的優(yōu)勢越明顯。

3.2.2 訪問控制流程性能

本文方案與其他文獻方案在訪問控制流程中的功能比較如表3所示。

表3 訪問控制方案對比

由表3可見，ABAC[9]訪問控制方案在區(qū)塊鏈網(wǎng)絡中將節(jié)點分為授權(quán)節(jié)點AN和公共節(jié)點，當公共節(jié)點發(fā)起訪問請求時，授權(quán)節(jié)點AN將調(diào)用鏈碼記錄信息并響應訪問請求。AN不僅為物聯(lián)網(wǎng)設備分配屬性，還對訪問策略進行制定和決策，其通過查詢部署過的鏈碼檢索已經(jīng)注冊的訪問憑證，來驗證請求者的身份和訪問策略的有效性；CBAC[10]通過將單獨的能力作為基本單位定義能力令牌，將傳統(tǒng)的能力令牌劃分為多個單獨的能力令牌，實現(xiàn)了更細粒度的訪問控制和更靈活的令牌管理。本文方案結(jié)合ABAC和CBAC，既可指定訪問策略，也可劃分能力令牌，還能支持區(qū)塊鏈數(shù)據(jù)以鏈下方式存儲。

在不同操作下，CABAC方案中不同操作的平均耗時如圖12所示，其中橫軸坐標表示操作名稱，縱軸坐標表示平均耗時(單位：ms)。可見，本文方案中所有操作消耗的時間均在450 ms之內(nèi)，相比獲取屬性和委派能力令牌操作，生成能力令牌操作和最后的返回訪問結(jié)果操作需要花費更多的時間，但總體上可以接受。

4 結(jié)束語

為了實現(xiàn)部門與部門間的細粒度訪問控制，本文提出一種基于區(qū)塊鏈的多部門數(shù)據(jù)共享混合訪問控制方案，使用HyperledgerFabric聯(lián)盟鏈作為區(qū)塊鏈基礎(chǔ)架構(gòu)，通過編寫鏈碼進行訪問控制和權(quán)限的委派，同時利用IPFS以鏈下存儲的方式拓展區(qū)塊鏈的可存儲性，減輕了區(qū)塊鏈的數(shù)據(jù)存儲壓力，最后通過仿真實驗驗證了該方案的可行性。與現(xiàn)有基于區(qū)塊鏈的訪問控制方案相比，本文提出混合基于屬性和能力的訪問控制模型的數(shù)據(jù)共享訪問控制方案，能夠在實施訪問控制的前提下，以更細的粒度進行訪問能力的生成與委派。然而，本文方案未涉及基于屬性文件的加密，在數(shù)據(jù)安全性上有待提升。此外，在本文提出的令牌委派過程中，尚未對委派對象設置限制，容易出現(xiàn)隨意委派能力令牌的情況。這是未來進一步研究的內(nèi)容。