基于CP-ABE算法的區(qū)塊鏈數(shù)據(jù)訪問控制方案

邱云翔，張紅霞，曹琪，章建聰，陳興蜀，金泓鍵

基于CP-ABE算法的區(qū)塊鏈數(shù)據(jù)訪問控制方案

邱云翔1，張紅霞2，曹琪2，章建聰1，陳興蜀2，金泓鍵2

（1. 華信咨詢設(shè)計研究院有限公司，浙江 杭州 310000；2. 四川大學(xué)網(wǎng)絡(luò)空間安全學(xué)院，四川 成都 610065）

與公有鏈不同，聯(lián)盟區(qū)塊鏈超級賬本Fabric額外集成了成員管理服務(wù)機制，能夠提供基于通道層面的數(shù)據(jù)隔離保護。但這種數(shù)據(jù)隔離保護機制在通道內(nèi)同步的仍是明文數(shù)據(jù)，因此存在一定程度的數(shù)據(jù)泄露風(fēng)險。另外，基于通道的數(shù)據(jù)訪問控制在一些細(xì)粒度隱私保護場景下也不適用。為了解決上述提及的聯(lián)盟鏈超級賬本中存在的數(shù)據(jù)隱私安全問題，提出了一種基于CP-ABE算法的區(qū)塊鏈數(shù)據(jù)訪問控制方案。結(jié)合超級賬本中原有的Fabric-CA模塊，提出的方案在實現(xiàn)用戶級細(xì)粒度安全訪問控制區(qū)塊鏈數(shù)據(jù)的同時，還能夠?qū)崿F(xiàn)對CP-ABE方案中用戶屬性密鑰的安全分發(fā)。對該方案進行的安全分析表明，該方案實現(xiàn)了ABE用戶屬性私鑰安全分發(fā)和數(shù)據(jù)隱私性保護的安全性目標(biāo)，性能分析部分也說明了所提方案具有良好的可用性。

區(qū)塊鏈；超級賬本；CP-ABE；數(shù)據(jù)訪問控制

1 引言

聯(lián)盟區(qū)塊鏈超級賬本[1]（Hyperledger）是Linux基金會發(fā)起的區(qū)塊鏈技術(shù)項目，該項目致力于發(fā)展跨行業(yè)的商用區(qū)塊鏈平臺技術(shù)。區(qū)別于人們熟知的公有鏈，如比特幣[2]和以太坊[3-4]等，超級賬本技術(shù)額外融合了成員管理服務(wù)機制[5]，實現(xiàn)了更加適于商用的身份管理、網(wǎng)絡(luò)隱私、保密以及審查等功能。

傳統(tǒng)的區(qū)塊鏈網(wǎng)絡(luò)中，默認(rèn)情況下整個網(wǎng)絡(luò)中的數(shù)據(jù)對每個節(jié)點和用戶來說都是可見的，這就帶來了一定的數(shù)據(jù)隱私安全隱患：在某些應(yīng)用場景下，某些敏感的數(shù)據(jù)并不能以明文方式在整個網(wǎng)絡(luò)中進行同步。為了解決網(wǎng)絡(luò)節(jié)點數(shù)據(jù)的透明性帶來的安全隱私問題，聯(lián)盟區(qū)塊鏈超級賬本增加了對多通道的支持[6]，使同一通道中的節(jié)點共同維護一份賬本，不同通道中的數(shù)據(jù)相互隔離。通過這種多通道數(shù)據(jù)隔離機制，超級賬本技術(shù)大大增強了數(shù)據(jù)隱私保護的力度。但在默認(rèn)情況下，通道中的數(shù)據(jù)對同一通道中的節(jié)點來說仍是完全可見的，因此這種機制仍然存在以下問題。①數(shù)據(jù)泄露風(fēng)險：節(jié)點一旦被攻擊者攻破，其中的明文數(shù)據(jù)就會被攻擊者全數(shù)掌握。②數(shù)據(jù)隱私保護粒度過粗：這種基于通道的粗粒度數(shù)據(jù)隱私保護方式在某些細(xì)粒度數(shù)據(jù)訪問控制場景中并不適用。因此，需要一種更加細(xì)粒度的數(shù)據(jù)安全訪問控制機制。

基于上述提到的粗粒度數(shù)據(jù)訪問及數(shù)據(jù)加密問題，在超級賬本官方的版本更新中也提出了相應(yīng)的解決方案，即數(shù)據(jù)對稱加密上鏈[7]：通過對明文數(shù)據(jù)進行對稱加密然后上鏈的方式，使只有擁有對稱解密密鑰的用戶才能獲取真正的明文數(shù)據(jù)。這從一定程度上解決了細(xì)粒度數(shù)據(jù)隱私保護的問題。但在實際應(yīng)用中，為了達(dá)到細(xì)粒度安全訪問控制的需求，該方案要求每份上鏈數(shù)據(jù)都需要維護獨立的密鑰，且需要單獨將該密鑰分發(fā)給訪問控制策略中包含的所有接收者。這一過程中涉及大量密鑰生成、分發(fā)與管理操作，使這一方案并不高效。超級賬本官方提出的另一種解決方案是隱私數(shù)據(jù)機制[8]：通過在授權(quán)的組織節(jié)點中傳遞和同步真正的明文數(shù)據(jù)，非授權(quán)的組織節(jié)點間傳遞和同步數(shù)據(jù)哈希值的做法，該機制可以將數(shù)據(jù)隱私保護細(xì)化到通道中的組織層面，即可以實現(xiàn)通道中某些組織間的私密數(shù)據(jù)共享，一定程度上解決了本文的問題。但是，在默認(rèn)情況下，由于在授權(quán)的節(jié)點之間同步的數(shù)據(jù)仍是明文數(shù)據(jù)，這種機制并未根本上解決數(shù)據(jù)泄露帶來的安全性問題。另外，正如上述提到的，隱私數(shù)據(jù)機制只能將對數(shù)據(jù)的訪問控制細(xì)化到組織層面，在一些希望實現(xiàn)基于組織中用戶訪問控制的場景中，這種機制其實并不能滿足本文的需求。

本文針對超級賬本Fabric目前存在的細(xì)粒度數(shù)據(jù)隱私保護需求，設(shè)計了一種基于CP-ABE算法的區(qū)塊鏈數(shù)據(jù)訪問控制方案，主要貢獻如下。

1) 基于CP-ABE算法，提出了一種適用于超級賬本Fabric網(wǎng)絡(luò)的數(shù)據(jù)訪問控制機制，在保證數(shù)據(jù)不被泄露的同時能夠?qū)崿F(xiàn)基于用戶的最細(xì)粒度的數(shù)據(jù)訪問控制。

2) 基于超級賬本中已有的Fabric-CA模塊，實現(xiàn)CP-ABE用戶屬性密鑰的動態(tài)生成和安全分發(fā)等操作。在不影響超級賬本原有結(jié)構(gòu)和運行機制的前提下，通過非對稱加密算法對用戶屬性密鑰進行加密傳輸，解決了傳統(tǒng)加密方案中廣泛存在的密鑰分發(fā)問題。

2 背景技術(shù)

2.1 區(qū)塊鏈和超級賬本

2.1.1 區(qū)塊鏈和超級賬本技術(shù)簡介

區(qū)塊鏈的概念源于比特幣[2]，其有效地解決了去中心化分布式場景中節(jié)點間的信任問題[9]。從本質(zhì)上來說，區(qū)塊鏈?zhǔn)且环N特殊的數(shù)據(jù)結(jié)構(gòu)，通過結(jié)合多種密碼學(xué)技術(shù)和分布式網(wǎng)絡(luò)技術(shù)，區(qū)塊鏈將一個個數(shù)據(jù)塊以鏈的方式組織起來。同時，區(qū)塊鏈?zhǔn)褂命c對點傳輸技術(shù)和共識機制（如PoW[10]、PoS[11-12]等），使多個節(jié)點之間保存相同的數(shù)據(jù)內(nèi)容，并利用這種冗余機制來實現(xiàn)數(shù)據(jù)的不可篡改性和持久性。區(qū)塊鏈網(wǎng)絡(luò)嚴(yán)格按照“少數(shù)服從多數(shù)”的機制保證節(jié)點間數(shù)據(jù)的一致性，這意味著攻擊者必須控制超過半數(shù)的區(qū)塊鏈節(jié)點（51%攻擊[13]）才能實現(xiàn)非法修改或刪除已經(jīng)存在于鏈上的記錄，而這種攻擊方式在大規(guī)模部署的分布式區(qū)塊鏈網(wǎng)絡(luò)中幾乎不可能實現(xiàn)，因此一般認(rèn)為存儲在區(qū)塊鏈中的數(shù)據(jù)是安全的。同時，以以太坊為代表的區(qū)塊鏈網(wǎng)絡(luò)集成了智能合約，使更加復(fù)雜和高級的分布式應(yīng)用得以實現(xiàn)。因為區(qū)塊鏈技術(shù)的去中心化、上鏈數(shù)據(jù)不可篡改、交易內(nèi)容可追溯以及智能合約實現(xiàn)等特性，學(xué)術(shù)界和工業(yè)界開展了很多的研究工作，目前區(qū)塊鏈技術(shù)在金融服務(wù)、征信和權(quán)屬管理、資源共享、供應(yīng)鏈管理、隱私保護以及公共網(wǎng)絡(luò)服務(wù)等場景中有廣泛的應(yīng)用[14]。

根據(jù)系統(tǒng)控制權(quán)和交易信息公開與否進行歸類[15]，區(qū)塊鏈可以分為公有鏈、私有鏈和聯(lián)盟鏈3類。公有鏈沒有任何準(zhǔn)入機制，任意節(jié)點都可以加入網(wǎng)絡(luò)中，且信息對整個系統(tǒng)公開，是完全去中心化的點對點系統(tǒng)，如比特幣和以太坊等。私有鏈目前多用于測試場景下，其與普通意義上的數(shù)據(jù)庫并無本質(zhì)上的區(qū)別，只適用于限定的機構(gòu)之內(nèi)。聯(lián)盟鏈則指的是區(qū)塊鏈中設(shè)計了特殊的準(zhǔn)入機制，交易信息只針對局部進行公開，區(qū)塊鏈節(jié)點通常需要通過合法的證書才能夠發(fā)起交易或訪問區(qū)塊鏈上的內(nèi)容，這樣的設(shè)計尤其適合于商業(yè)應(yīng)用場景，在保護商業(yè)隱私的同時，能夠解決跨機構(gòu)商業(yè)伙伴間的互信問題。

作為聯(lián)盟區(qū)塊鏈的代表技術(shù)，超級賬本區(qū)塊鏈并不是完全去中心化的，而是有若干組織機構(gòu)共同參與和管理，另外配置一個專用的證書授權(quán)機構(gòu)Fabric-CA來處理節(jié)點或用戶的接入身份權(quán)限問題。相比傳統(tǒng)公有鏈技術(shù)，超級賬本在擴展性和智能合約的功能完善性方面都有了大幅的提升。超級賬本支持拜占庭共識協(xié)議和基于Kafka的崩潰容錯共識協(xié)議，能夠?qū)崿F(xiàn)快速有效的交易共識。另外，超級賬本支持多種常規(guī)編程語言智能合約，如Go、Node.js和Java等。這也意味著在超級賬本區(qū)塊鏈上部署的智能合約，理論上能夠支持任何功能，使超級賬本在支撐商業(yè)應(yīng)用時不會受限于編程實現(xiàn)問題。

為了解耦功能，提升擴展性，F(xiàn)abric中設(shè)計了兩種類型的節(jié)點：排序節(jié)點（Orderer）和對等節(jié)點（Peer）。排序節(jié)點負(fù)責(zé)對交易按照規(guī)則進行排序并生成區(qū)塊，可由多個排序節(jié)點組成排序集群。排序節(jié)點間的共識可采用PBFT（實用拜占庭容錯）算法[16]或基于Kafka[17]的崩潰容錯算法等。對等節(jié)點負(fù)責(zé)驗證和同步數(shù)據(jù)，執(zhí)行智能合約（Fabric中又稱為鏈碼）等功能。根據(jù)節(jié)點功能的不同，對等節(jié)點又可以分為背書節(jié)點、記賬節(jié)點、主節(jié)點、錨節(jié)點等，節(jié)點身份可基于特定規(guī)則切換。功能松耦合、實現(xiàn)模塊化保證Fabric網(wǎng)絡(luò)具有良好的擴展性。

2.1.2 Fabric-CA簡介

超級賬本區(qū)塊鏈網(wǎng)絡(luò)屬于許可鏈類型，當(dāng)新用戶需要接入網(wǎng)絡(luò)時，需要從專門的機構(gòu)獲取合法證書，F(xiàn)abric-CA[18]用于實現(xiàn)這一機構(gòu)的所有功能。Fabric-CA由服務(wù)器（fabric-ca-server）和客戶端（fabric-ca-client）組件組成。它提供3個功能：一是注冊新用戶身份，注冊結(jié)果將作為用戶證書申請的憑據(jù)；二是簽發(fā)證書，即為合法的注冊票據(jù)生成證書；三是證書更新或撤銷，當(dāng)Fabric網(wǎng)絡(luò)中的用戶信息更新時，這一功能將更新對應(yīng)用戶的證書信息。

Fabric-CA架構(gòu)如圖1所示，新用戶可通過獨立的Fabric-CA客戶端或集成該客戶端的SDK程序與Fabric-CA服務(wù)端交互，其中所有通信都通過REST API進行。

2.1.3 超級賬本交易流程

典型的超級賬本Fabric交易流程如圖2所示。用戶在加入超級賬本網(wǎng)絡(luò)之前，可以向Fabric-CA注冊并獲取合法的證書，之后即可使用該證書通過命令行或Fabric-SDK與區(qū)塊鏈網(wǎng)絡(luò)交互。超級賬本支持多通道機制，每個通道維護著一個獨立的區(qū)塊鏈賬本，區(qū)塊根據(jù)通道ID進行分發(fā)，通道間數(shù)據(jù)完全隔離。用戶在發(fā)起交易時需指定通道ID（圖2中的Channel 1或Channel 2），并將交易提案發(fā)送給背書節(jié)點，背書節(jié)點處理請求后，向客戶端返回簽名后的背書響應(yīng)（圖2中1.）。隨后客戶端組合來自不同背書節(jié)點的背書響應(yīng)并將最終交易內(nèi)容發(fā)送至排序服務(wù)集群進行處理（圖2中2.）。在排序完成后，排序節(jié)點將根據(jù)交易所述通道，將其分發(fā)至該通道中的所有主節(jié)點，由主節(jié)點進行組織內(nèi)的區(qū)塊同步。最終收到交易后，各節(jié)點驗證交易內(nèi)容和簽名，并將合法的交易添加到區(qū)塊鏈賬本中。

圖1 Fabric-CA架構(gòu)

Figure 1 The framework of Fabric-CA

圖2 Fabric交易流程

Figure 2 The transaction process of Fabric

2.2 屬性基加密技術(shù)

屬性基加密（ABE，attribute-based encryption）最早由Goyal等[19]在FIBE（fuzzy identity-based encryption）[20]的基礎(chǔ)上提出，目的是解決云存儲環(huán)境中數(shù)據(jù)的細(xì)粒度訪問控制問題和大規(guī)模用戶動態(tài)擴展問題[21]。ABE本質(zhì)上屬于非對稱加密技術(shù)，但其采用一對多的加密方式。根據(jù)解密策略的位置不同，ABE可以分為密鑰策略屬性基加密（KP-ABE，key policy attribute-based encryption）[19]和密文策略屬性基加密（CP-ABE，ciphertext policy attribute-based encryption）[22]。在KP-ABE中，密文的解密策略在密鑰生成時被嵌入用戶的私鑰中，相關(guān)屬性則在加密時被嵌入密文中，即訪問策略與密鑰相關(guān)聯(lián)；在CP-ABE中，解密策略在加密時被嵌入密文中，而用戶的屬性則在密鑰生成時被嵌入其私鑰中，即訪問策略與密文相關(guān)聯(lián)。不論KP-ABE還是CP-ABE，用戶都只能在私鑰和密文中嵌入的屬性集和訪問控制策略完全匹配時，才能解密該密文[23]。由于訪問控制策略與屬性集可能存在一對多的關(guān)系，因此ABE技術(shù)自然地實現(xiàn)了加密訪問控制功能。同時根據(jù)加密或密鑰生成時所指定策略的嚴(yán)格程度，ABE方案可以靈活地選擇密文訪問控制機制的粒度。以CP-ABE方案為例，通常情況下包含以下4種算法。

考慮到本文方案的應(yīng)用需求（即需要由上傳數(shù)據(jù)的用戶指定加密數(shù)據(jù)的用戶訪問控制列表），將解密策略嵌入密文中的方案CP-ABE更適合本文的應(yīng)用需求。

3 方案設(shè)計

3.1 總體方案框架

針對第1節(jié)提出的區(qū)塊鏈數(shù)據(jù)訪問控制問題，本文提出了一種基于CP-ABE算法實現(xiàn)區(qū)塊鏈數(shù)據(jù)訪問控制的方案。通過：①修改原有的用戶證書管理機構(gòu)Fabric-CA，來實現(xiàn)CP-ABE方案初始化以及用戶屬性私鑰的生成和分發(fā)；②將隱私數(shù)據(jù)通過CP-ABE方案加密上鏈，以實現(xiàn)隱私數(shù)據(jù)的加密訪問控制機制。該方案主要由證書頒發(fā)機構(gòu)Fabric-CA、區(qū)塊鏈網(wǎng)絡(luò)Fabric和客戶端Client組成，總體方案框架如圖3所示。

圖3 總體方案框架

Figure 3 The framework of scheme

Fabric-CA部分：通過利用已有的超級賬本Fabric-CA，該部分主要用于實現(xiàn)以下功能。

1) 用戶證書管理：原有區(qū)塊鏈網(wǎng)絡(luò)的用戶證書簽發(fā)與吊銷等操作。

2) CP-ABE系統(tǒng)初始化：主要包含公開參數(shù)和主密鑰的生成。

3) 用戶屬性密鑰SK生成與分發(fā)：為某一用戶生成并分發(fā)特定包含該用戶屬性的密鑰。

其中，用戶證書管理為超級賬本網(wǎng)絡(luò)中原有的功能，目前方案中增加了CP-ABE系統(tǒng)初始化以及用戶屬性密鑰生成與分發(fā)機制。

Fabric部分：該部分主要實現(xiàn)超級賬本網(wǎng)絡(luò)中原有的功能，包含交易背書、交易排序和交易驗證及上鏈等。在本文方案的實現(xiàn)過程中，該部分主要是將待存儲的密文通過背書、排序和節(jié)點驗證進行上鏈操作，將密文在整個通道中進行分布式存儲。

Client部分：在原有的超級賬本網(wǎng)絡(luò)中，該部分主要用于實現(xiàn)交易的發(fā)起以及用戶的證書接收功能。本文方案在其原有功能之上增加了用戶屬性密鑰SK接收和CP-ABE數(shù)據(jù)加解密功能。用戶可通過Client與Fabric網(wǎng)絡(luò)以及Fabric-CA進行交互操作。

3.2 CP-ABE屬性集及策略定義

3.2.1 屬性定義

CP-ABE方案中僅擁有滿足策略屬性的密鑰才能對密文進行解密以獲取明文數(shù)據(jù)。由2.1.3節(jié)可知，超級賬本網(wǎng)絡(luò)中可以包括多個通道（如Channel1、Channel2和Channel3等），且每個通道中將包含多個組織（如Org1、Org2和Org3等），每個組織中又將包含多個用戶（如User1、User2和User3等）。作為超級賬本區(qū)塊鏈網(wǎng)絡(luò)可劃分的最小單位，用戶是CP-ABE方案屬性集中的最細(xì)粒度，其固有通道ID、組織ID和用戶ID這3個屬性，因此，本文將數(shù)據(jù)訪問控制中屬性定義的可選范圍如表1所示。

表1 用戶屬性定義

3.2.2 訪問控制策略定義

策略即屬性組成的訪問結(jié)構(gòu)。由3.2.1節(jié)可知，本文將屬性定義為通道ID、組織ID以及用戶ID這3種，原則上在形成訪問控制策略時，可以將這3種屬性隨意組合。例如，在實際的密文生成時，可以將策略P1定義為通道1組織1中的User1和通道2組織2中的全部用戶都可以訪問，P2定義為通道1組織1中的User1和通道1組織2中的全部用戶都可以訪問。通過將訪問控制策略和密文相結(jié)合，就可以達(dá)到數(shù)據(jù)訪問控制的目的。

由2.1.3節(jié)可知，超級賬本網(wǎng)絡(luò)的區(qū)塊分發(fā)是按通道ID進行分發(fā)的，由于通道之間是相互隔離的，即數(shù)據(jù)區(qū)塊只能被發(fā)往其中一個通道，通常不存在上鏈數(shù)據(jù)可以被多個通道同時訪問的情況。因而，上述提及的策略P1在實際的訪問控制中并不存在，即通道ID這一屬性并不能直接簡單地包含在訪問控制策略中。但在不考慮通道ID屬性作為訪問策略的選擇時，本文將策略定義為僅包含組織ID屬性或用戶ID屬性中的一個或組合形式，如通道1中的某個密文指定策略P為（組織ID = Org2），一旦通道1組織2中的用戶User1將獲取到的密文泄露給通道2組織2中的User2，由于用戶User2也包含屬性O(shè)rg2，因此User2可以成功解密該密文，從而造成數(shù)據(jù)泄露問題；再則，當(dāng)數(shù)據(jù)擁有者想要使加密密文對Channel1中的全部用戶都可解密時，在不考慮通道ID屬性作為訪問策略選擇時，就需要通過定義多個組織進行與操作，即策略的邏輯相比直接定義策略P為（通道ID = Channel1）更加復(fù)雜。因此，為更準(zhǔn)確地實現(xiàn)加密數(shù)據(jù)的數(shù)據(jù)訪問控制，用戶策略的指定需在通道層面就開始進行考慮。

為了將可用的訪問控制策略更加全面化和具體化地進行展示，如圖4所示，本文定義了3種通用策略：①特定通道內(nèi)的所有用戶均可解密；②特定通道內(nèi)的特定組織中的所有用戶均可解密；③特定通道內(nèi)的特定組織中的特定用戶可解密。

圖4 用戶通用策略

Figure 4 User common policy

通用策略1：通道ID=Channel*，即通道ID可以等于{ Channel* }集合中的任意通道，換言之，就是該通道下的所有用戶都可對基于該策略加密的密文進行解密從而訪問對應(yīng)明文數(shù)據(jù)。

通用策略2：(通道ID=Channel1)&&(組織ID=Org*)，即指定了通道ID此處只能為Channel1（但不限于Channel1，此處僅為具體示例），而組織ID可以在Channel1的組織集{ Org* }任意選擇其中一個，此時該組織下的所有用戶都可以對基于該策略加密的密文進行解密從而訪問對應(yīng)明文數(shù)據(jù)。

通用策略3：(通道ID=Channel1)&&(組織ID=Org1)&&（用戶ID=User*），即指定了通道ID此處只能為Channel1，組織ID在此處僅對應(yīng)Channel1中的Org1（不限于Org1，僅為示例），而用戶ID可以在Channel1中的Org1中形成的用戶集{ User* }任意選擇。此時，Channel1中的Org1下的某個用戶可對基于該策略進行加密的密文解密從而訪問對應(yīng)明文。

用戶在將上鏈數(shù)據(jù)進行加密時策略指定可直接使用上述3種通用策略，僅需將模塊中的對應(yīng)字段改成用戶想要指定的字段。除此之外，用戶還可以通過將通用策略2和通用策略3進行組合，實現(xiàn)更細(xì)粒度的數(shù)據(jù)訪問控制。

4 具體方案與評估

4.1 具體方案

表2 方案符號說明

圖5 方案整體工作流程

Figure 5 Overall work flow of the scheme

4.2 安全性分析

（2）數(shù)據(jù)隱私性保證

數(shù)據(jù)所有者對明文數(shù)據(jù)進行CP-ABE方案加密進而上鏈，故在整個Fabric網(wǎng)絡(luò)中僅對該數(shù)據(jù)密文可見。此外，如前所述，F(xiàn)abric-CA完全可信，有關(guān)密鑰產(chǎn)生對應(yīng)階段可信。數(shù)據(jù)所有者直接通過指定策略P對該數(shù)據(jù)的訪問權(quán)限進行限制，僅包含滿足策略P屬性的用戶才能對該數(shù)據(jù)進行解密進而訪問，不滿足該策略P對應(yīng)的解密屬性私鑰無法解密該密文，進而保證了數(shù)據(jù)隱私性。

4.3 性能分析

本節(jié)主要針對方案的實現(xiàn)性能進行分析。實驗環(huán)境使用Oracle VM VirtualBox 安裝的Ubuntu16.04 LTS 虛擬機，并分配了4 GB內(nèi)存和1個核心處理器。在對性能指標(biāo)進行選擇時，考慮到本文方案并未對原有超級賬本網(wǎng)絡(luò)的交易流程進行改動，只是將原來區(qū)塊鏈網(wǎng)絡(luò)中上鏈的明文數(shù)據(jù)替換成了經(jīng)CP-ABE加密后的密文數(shù)據(jù)，這種改動對于底層的交易流程來說是透明的，不會影響到超級賬本網(wǎng)絡(luò)原本的運行效率。因此，只需針對CP-ABE方案的性能指標(biāo)進行測量，本節(jié)主要對文獻[22]實現(xiàn)的CP-ABE方案進行用戶屬性私鑰生成時間和加解密時間的測量。

在本文設(shè)計的方案中，CP-ABE方案涉及的屬性私鑰最多包含3個屬性：通道ID、組織ID以及用戶ID。由文獻[19]可知，私鑰產(chǎn)生時間隨包含屬性個數(shù)的增加呈線性增長趨勢，在本文方案中考慮屬性最多為3個的前提下，經(jīng)過測量得出私鑰產(chǎn)生時間在0.031 5 s左右。同時考慮到在實際的超級賬本交易過程中，單個區(qū)塊最大能夠容納10 MB的數(shù)據(jù)，因此將實驗中最大的數(shù)據(jù)大小設(shè)置為10 MB。由圖6顯示，隨著需加解密數(shù)據(jù)大小的增加，對應(yīng)的加解密時間都在以線性的趨勢增加。在數(shù)據(jù)大小為最大即10 MB時，此時加密的時間在0.08 s左右，解密的時間在0.065 s左右。

圖6 數(shù)據(jù)大小對加解密時間的影響

Figure 6 Impact of data size on encryption and decryption time

通過對用戶屬性私鑰生成時間和需加解密數(shù)據(jù)大小對加解密時間的影響進行測量，發(fā)現(xiàn)這兩個操作實現(xiàn)的時間都是在可接受的范圍增量內(nèi)，因此，在原有超級賬本網(wǎng)絡(luò)運行機制上實現(xiàn)的基于CP-ABE算法的區(qū)塊鏈數(shù)據(jù)訪問控制機制具有良好的可行性。

4.4 方案的對比分析

本節(jié)將提出的方案與目前已有的超級賬本官方解決方案進行比較，分別從用戶級訪問控制粒度、數(shù)據(jù)隱私性、密鑰安全分發(fā)以及加/解密密鑰管理簡易進行對比。其中，用戶級訪問控制粒度說明該方案是否支持對超級賬本網(wǎng)絡(luò)最細(xì)訪問控制粒度即用戶級別的訪問控制功能；數(shù)據(jù)隱私性代表該方案是否對上鏈數(shù)據(jù)的隱私性進行保障；密鑰安全分發(fā)說明該方案是否保證了密鑰的安全分發(fā)特性；加/解密密鑰管理簡易性代表在保證加密密文安全性的前提下用戶是否不需要管理維護多個加/解密密鑰，即是否能夠擺脫“一密一鑰”的復(fù)雜操作。

表3 安全性和性能對比

注：“√”文獻方案支持此特性，“×”文獻方案不支持此特性，“—”表示文獻方案中無相應(yīng)的特性要求。

如表3所示，本文方案相比同類方案，不僅可以保證上鏈數(shù)據(jù)隱私性、支持基于用戶級別的最細(xì)訪問控制粒度，還在保證密鑰安全分發(fā)的前提下簡化了加/解密密鑰的管理工作，因此更加適用于超級賬本網(wǎng)絡(luò)的上鏈數(shù)據(jù)訪問控制實現(xiàn)。

5 結(jié)束語

本文分析了目前超級賬本區(qū)塊鏈網(wǎng)絡(luò)中存在的數(shù)據(jù)明文存儲以及數(shù)據(jù)訪問控制機制粗粒度問題，提出了一種基于CP-ABE算法的區(qū)塊鏈數(shù)據(jù)訪問控制方案，實現(xiàn)了基于用戶屬性的細(xì)粒度訪問控制目標(biāo)。同時，為了解決密鑰分發(fā)問題，本文基于超級賬本區(qū)塊鏈中原有的Fabric-CA模塊，通過添加對CP-ABE算法密鑰（包括系統(tǒng)初始化和用戶屬性私鑰）的生成支持，進一步利用非對稱加密算法實現(xiàn)了用戶屬性私鑰的安全分發(fā)。最后，對本文所提方案的安全性分析驗證了該方案的設(shè)計達(dá)到了用戶屬性私鑰安全分發(fā)和數(shù)據(jù)隱私保護的安全性目標(biāo)，實現(xiàn)了超級賬本區(qū)塊鏈網(wǎng)絡(luò)中隱私數(shù)據(jù)的細(xì)粒度訪問控制功能。性能分析部分也表明了本文方案的可用性。同時通過與已有類似方案進行對比，進一步說明了本文設(shè)計方案對超級賬本網(wǎng)絡(luò)的上鏈數(shù)據(jù)訪問控制實現(xiàn)的適用性。

[1] ANDROULAKI E, BARGER A, BORTNIKOV V, et al. Hyperledger fabric: a distributed operating system for permissioned blockchains[C]//European Conference on Computer Systems, 2018 : 1-15.

[2] NAKAMOTO S. Bitcoin: a peer-to-peer electronic cash system[R]. 2008.

[3] WOOD G. Ethereum: a secure decentralised generalised transaction ledger[R]. 2014.

[4] 閆鶯, 鄭凱, 郭眾鑫. 以太坊技術(shù)詳解與實戰(zhàn)[M]. 北京: 機械工業(yè)出版社, 2018.

YAN Y, ZHENG K, GUO Z X. Ethereum technical details and actual combat[M]. Beijing: China Machine Press, 2018.

[5] 陳劍雄, 張董朱. 深度探索區(qū)塊鏈Hyperledger技術(shù)與應(yīng)用[M]. 北京: 機械工業(yè)出版社, 2018 .

CHEN J X, ZHANG D Z. In-depth exploration of blockchain hyperledger technology and application[M]. BeiJing: China Machine Press, 2018.

[6] Channels. Hyperledger fabric channels[EB].

[7] Enccc_example. 2019 Hyperledger fabric enccc_example[EB].

[8] Private data. 2019 Hyperledger fabric private data[EB].

[9] 沈鑫, 裴慶祺, 劉雪峰. 區(qū)塊鏈技術(shù)綜述[J]. 網(wǎng)絡(luò)與信息安全學(xué)報, 2016, 2(11): 11-20.

SHEN X, PEI Q Q, LIU X F. Survey of block chain[J].Chinese Journal of Network and Information Security, 2016, 2(11): 11-20.

[10] JAKOBSSON M, JUELS A. Proofs of work and bread pudding protocols. in secure information networks: communications and multimedia security[C]//IFIP TC6/TC11 Joint Working Conference on Communications and Multimedia Security (CMS '99).1999.

[11] VASIN P. Blackcoin’s proof-of-stake protocol v2[EB].

[12] KING S, NADAL S. PPCoin: peer-to-peer crypto-currency with proof-of-stake[J]. Self-published Paper, 2012(8): 19.

[13] YE C. Analysis of security in blockchain: case study in 51%-attack detecting[C]//2018 5th International Conference on Dependable Systems and Their Applications (DSA). 2018.

[14] 章峰, 史博軒, 蔣文保. 區(qū)塊鏈關(guān)鍵技術(shù)及應(yīng)用研究綜述[J]. 網(wǎng)絡(luò)與信息安全學(xué)報, 2018, 4(4): 26-33.

ZHANG F, SHI B X, JIANG W B. Review of key technology and its application of blockchain[J]. Chinese Journal of Network and Information Security, 2018, 4(4):26-33.

[15] 中國信息通信研究院. 區(qū)塊鏈白皮書[R]. 2018.

China Academy of Information and Communication Technology. White paper of blockchain[R]. 2018.

[16] SUKHWANI H, MARTINEZ J M, CHANG X, et al. Performance modeling of PBFT consensus process for permissioned blockchain network (Hyperledger Fabric)[C]//Symposium on Reliable Distributed Systems. 2017: 253-255.

[17] KREPS J, NARKHEDE N, RAO J. Kafka: a distributed messaging system for log processing[C]//The NetDB. 2011 (11): 1-7.

[18] Certificate Authorities. 2019 Hyperledger fabric certificate authorities[EB].

[19] GOYAL V, PANDEY O, SAHAI A, et al. Attribute-based encryption for fine-grained access control of encrypted data[C]// Symposium on Computer and Communications Security. 2006: 89-98.

[20] BOLDYREVA A, GOYAL V, KUMAR V, et al. Identity-based encryption with efficient revocation[C]// Symposium on Computer and Communications Security. 2008: 417-426.

[21] 林素青. 支持訪問更新的可驗證外包屬性加密方案[J]. 網(wǎng)絡(luò)與信息安全學(xué)報, 2019, 5(1): 41-53.

LIN S Q. Verifiable outsourced attribute-based encryption with access update[J]. Chinese Journal of Network and Information Security, 2019, 5(1): 41-53.

[22] BETHENCOURT J, SAHAI A, WATERS B. Ciphertext-policy attribute-based encryption[C]//IEEE symposium on security and privacy (SP'07). 2007.

[23] 張興蘭, 崔遙. 基于群簽名的屬性加密方案[J]. 網(wǎng)絡(luò)與信息安全學(xué)報, 2019, 5(1): 19-25.

ZHANG X L, CU Y. Attribute-based encryption schema with group signatures[J]. Chinese Journal of Network and Information Security, 2019, 5(1): 19-25.

Blockchain data access control scheme based on CP-ABE algorithm

QIU Yunxiang1, ZHANG Hongxia2, CAO Qi2, ZHANG Jiancong1, CHEN Xingshu2, JIN Hongjian2

1. Huaxin Consulting Co.,Ltd., Hangzhou 310000, China 2. College of Cybersecurity, Sichuan University,Chengdu 610065, China

Different from the public chain, the consortium blockchain Hyperledger Fabric integrates the additional member management service(MSP) mechanism to provide channel-based data isolation protection. However, the data isolation protection mechanism still synchronizes the plaintext data within a channel, so there is a risk of data leakage. Besides, the channel-based data access control mechanism does not apply to some fine-grained privacy protection scenarios. To solve the problems of data privacy and security involved in the consortium chain Hyperledger mentioned above, a blockchain data access control scheme based on the CP-ABE algorithm was proposed. Based on the original existing Fabric-CA module in the Hyperledger, our scheme can realize the secure distribution of user attribute keys in the CP-ABE scheme while implementing the fine-grained security access control of blockchain data at the user level. The security analysis shows that the scheme achieves the security goals of ABE user attribute private key security distribution and data privacy protection. The performance analysis also shows that the proposed scheme has good usability.

blockchain, Hyperledger, CP-ABE, data access control

TP309.2

A

10.11959/j.issn.2096?109x.2020037

2019?12?10；

2020?02?07

章建聰，zhangjc@hxdi.com

中央高?；究蒲袠I(yè)務(wù)費基礎(chǔ)研究基金（SCU2018D018，SCU2018D022，2019SCU12069）

The Fundamental Research Funds for the Central Universities (SCU2018D018, SCU2018D022, 2019SCU12069)

邱云翔, 張紅霞, 曹琪, 等. 基于CP-ABE算法的區(qū)塊鏈數(shù)據(jù)訪問控制方案[J]. 網(wǎng)絡(luò)與信息安全學(xué)報, 2020, 6(3): 88-98.

QIU Y X, ZHANG H X, CAO Q, et al. Blockchain data access control scheme based on CP-ABE algorithm[J]. Chinese Journal of Network and Information Security, 2020, 6(3): 88-98.

邱云翔（1988? ），男，貴州六枝人，碩士，華信咨詢設(shè)計研究院有限公司工程師，主要研究方向為信息安全、數(shù)據(jù)安全。

張紅霞（1996? ），女，河北邢臺人，四川大學(xué)碩士生，主要研究方向為區(qū)塊鏈安全及應(yīng)用、網(wǎng)絡(luò)行為分析。

曹琪（1996? ），女，四川廣安人，四川大學(xué)碩士生，主要研究方向為區(qū)塊鏈安全及應(yīng)用、網(wǎng)絡(luò)行為分析。

章建聰（1975? ），女，浙江金華人，碩士，華信咨詢設(shè)計研究院有限公司高級工程師，主要研究方向為數(shù)據(jù)通信、信息安全。

陳興蜀（1968?），女，貴州六枝人，博士，四川大學(xué)教授、博士生導(dǎo)師，主要研究方向為云計算與大數(shù)據(jù)安全、可信計算與信息保障。

金泓鍵（1996? ），男，重慶人，四川大學(xué)碩士生，主要研究方向為區(qū)塊鏈安全及應(yīng)用、大數(shù)據(jù)分析。