基于區(qū)塊鏈的鏈下數(shù)據(jù)保護(hù)系統(tǒng)優(yōu)化

趙長明， 薛瑩， 張倩

(陜西警官職業(yè)學(xué)院,新型網(wǎng)絡(luò)金融犯罪偵查研究中心，陜西,西安 710043)

0 引言

為應(yīng)對不斷發(fā)生的個人數(shù)據(jù)外泄事件，區(qū)塊鏈技術(shù)與智能合約技術(shù)被逐步應(yīng)用到個人數(shù)據(jù)保護(hù)系統(tǒng)的設(shè)計中。匿名地址技術(shù)改變了數(shù)據(jù)在系統(tǒng)中真實地址被直接獲取的現(xiàn)狀[1]。在本設(shè)計的系統(tǒng)方案中，被授權(quán)的第三方服務(wù)僅能得到被加密的地址，而其想要訪問的數(shù)據(jù)是在資源服務(wù)訪問后向其提供的，這種方式杜絕了通過數(shù)據(jù)地址進(jìn)行攻擊的威脅，大大提高了數(shù)據(jù)的安全性。

1 當(dāng)前鏈下數(shù)據(jù)保護(hù)系統(tǒng)存在的問題

當(dāng)下的個人數(shù)據(jù)保護(hù)系統(tǒng)總體結(jié)構(gòu)如圖1所示，通過圖1可以清晰地了解數(shù)據(jù)交互的過程并從中發(fā)現(xiàn)問題所在。這是一個通用的系統(tǒng)結(jié)構(gòu)，基于內(nèi)容各異的方案選擇對應(yīng)的算法。該結(jié)構(gòu)包含4個模塊：User(用戶)、DC(Data Controller 數(shù)據(jù)管理員)、TP(Third Party 第三方服務(wù))、RS(Resourse Server 資源服務(wù))。其中，DC能夠管理用戶的訪問權(quán)限，TP的目標(biāo)是獲取數(shù)據(jù)。通過圖1可以看出TP獲取用戶數(shù)據(jù)的流程如下。

圖1 數(shù)據(jù)保護(hù)系統(tǒng)總體結(jié)構(gòu)

步驟一：若TP想要獲取User的數(shù)據(jù)，必須首先得到User的同意，即圖1中流程①。

步驟二：若用戶同意TP訪問其數(shù)據(jù)，則將訪問請求和結(jié)果傳遞至DC，DC對TP和User同時進(jìn)行身份驗證，通過后向TP發(fā)送訪問授權(quán)并在鏈上作對應(yīng)的記錄，即圖1中流程②和③。

步驟三：TP獲取授權(quán)后到RS中進(jìn)行訪問，即圖1中流程④。

步驟四：RS驗證TP所獲授權(quán)，通過后按TP的請求反饋對應(yīng)數(shù)據(jù)，即圖1中流程④。

流程①中，TP向用戶發(fā)出數(shù)據(jù)訪問的申請，如果用戶同意，則它會將自己連同TP的簽名一同發(fā)送給DC，由DC進(jìn)行驗證，如此便降低了DC的負(fù)載；流程②中，如果DC檢測到TP的身份是非法的，則會駁回TP的訪問請求，驗證失敗，授權(quán)不通過。可見TP必須通過DC的檢測并被賦予訪問權(quán)限，才能擁有整個系統(tǒng)認(rèn)可的合法身份。若沒有流程②，那么驗證授權(quán)的請求只能同時發(fā)送給SP和DC，經(jīng)DC確認(rèn)其合法性。由此可見，DC驗證的過程應(yīng)優(yōu)先進(jìn)行。

每條鏈下數(shù)據(jù)就是一個存儲文件，它們分散于IPFS存儲系統(tǒng)中，被編輯后地址也隨之改變。地址是訪問這些分散存儲文件的唯一途徑信息，若是使用傳統(tǒng)的存儲方式，文件的訪問方式則是固定的[2-3]。在流程③中，TP的訪問申請通過后就會獲取用戶數(shù)據(jù)的訪問途徑。

如此即使用戶中斷TP的訪問過程，但TP已經(jīng)記錄了數(shù)據(jù)地址，繼續(xù)訪問并不十分困難。本文將提出一個可行的方案來解決系統(tǒng)當(dāng)前存在的問題，即TP獲取的僅是用戶數(shù)據(jù)的加密地址，它獲取訪問令牌后連同加密地址提交給RS，RS解密地址后將數(shù)據(jù)發(fā)送給TP。

2 鏈下數(shù)據(jù)保護(hù)系統(tǒng)優(yōu)化實現(xiàn)

2.1 優(yōu)化思路

經(jīng)過改進(jìn)的系統(tǒng)結(jié)構(gòu)如圖2所示。

圖2 改進(jìn)后的系統(tǒng)結(jié)構(gòu)

在C/S模式下，用戶的數(shù)據(jù)由服務(wù)器S進(jìn)行管理，S的職責(zé)是接收TP的數(shù)據(jù)訪問申請以及用戶發(fā)送來的授權(quán)，在這里用戶就是DS(Data Subject 數(shù)據(jù)主體)，則S即是DS和TP的權(quán)限管理員。一旦TP存在非法行為，就會創(chuàng)建一個不會被刪除的記錄。在本文中將RS特性假定為“Honest but curious”，也就是即使RS懷疑結(jié)果但仍忠實地履行協(xié)議。區(qū)塊鏈具有偽匿名的性質(zhì)，在此基礎(chǔ)上RS的服務(wù)職責(zé)可以被假定為僅辨識DS以太坊地址和對DS加密地址進(jìn)行解析，RS接到DS匿名發(fā)送的數(shù)據(jù)后獲取真實地址，由其它加密軟件完成加密操作，加密后的地址和解密密碼由RS保存，真實地址在DS中，RS向AC提供加密地址，向RS提供解密密碼。此時DS的以太坊地址和密碼存儲為表或鍵值的形式，與真實身份和地址沒有任何關(guān)聯(lián)。如此一來RS在沒有獲取加密地址的情況下就不能訪問用戶的數(shù)據(jù)，只有在接收到TP發(fā)來的DS數(shù)據(jù)訪問請求時，才能在其獲得訪問令牌的情況下獲得DS身份與被加密的地址，通過解密密碼解析加密地址后向TP提供所需數(shù)據(jù)。

2.2 優(yōu)化實現(xiàn)

(1)由圖2可見，TP在訪問DS數(shù)據(jù)之前必須向AC提交申請，即流程①。

(2)AC驗證TP身份并向DS傳達(dá)其訪問請求，由DS決定是否接受，即流程②。

(3)若DS接受申請，則AC把訪問令牌與加密地址一同交給TP，即流程③。

(4)RS、AC同時驗證訪問令牌，即流程④。

(5)TP向RS出示訪問令牌與加密地址，RS驗證訪問令牌，通過后對加密地址進(jìn)行解析，找到對應(yīng)的數(shù)據(jù)并交給TP，即流程⑤。

在本系統(tǒng)中，每一個活動的模塊都有對應(yīng)的以太坊地址，id_TP即TP在系統(tǒng)中的身份，id_DS、id_AC則分別對應(yīng)DS、AC 。所有獲得授權(quán)的TP及其所具權(quán)限都詳細(xì)地記錄在一個列表中，以供DS對獲得授權(quán)的TP進(jìn)行查詢。僅DS能夠?qū)α斜碇械捻椖績?nèi)容進(jìn)行編輯，既可以新建、修改、刪除某TP的授權(quán)，也可以對其所獲具體授權(quán)項進(jìn)行修改。

一開始，DS允許AC對其數(shù)據(jù)進(jìn)行管理，向AC提供加密地址，向RS提供解密密碼。系統(tǒng)中用以顯示訪問授權(quán)內(nèi)容的列表A_list是由AC和DS共同創(chuàng)建的，它能夠說明TP、AC、DS三者的關(guān)系，其中的Address與A_list一一對應(yīng)。DS對TP的授權(quán)具體內(nèi)容由Address→TP_Policy的映射關(guān)系進(jìn)行說明。在有TP獲得授權(quán)后，列表中便新建一個TP項，鑒于存在多個TP被同時授權(quán)的情況，所以通過一個tps集合將獲得授權(quán)的TP集中存儲。在A_list[DS].Tps中查詢獲得授權(quán)的TP，其所具權(quán)限則在A_list[DS].Tp_Policy[TP]中查詢。在struct list里，用mflag來說明DS是否允許AC對其數(shù)據(jù)進(jìn)行管理，tpsflag顯示已獲授權(quán)的TP數(shù)，struct TP里的tpsflag則用以證明TP已獲授權(quán)。

2.3 算法設(shè)計

DS向TP授權(quán)時各組件交互流程如圖3所示。

圖3 DS向TP授權(quán)時各組件交互流程圖

在流程①TP將對DS數(shù)據(jù)的訪問申請?zhí)峤唤oAC；在流程②由DS決定是否允許TP訪問；在流程③若DS允許則將授權(quán)反饋到AC；在流程④AC在list中新建訪問項；在流程⑤TP獲得授權(quán)，AC把訪問令牌與加密地址一同交給TP。

以上過程對應(yīng)的算法設(shè)計如下。

輸入id_DS,id_TP,ACT//輸入DS地址和權(quán)限

輸出success

1.require(A_list[id_DS].mflag==1)

2.require(msg.sender==A_list[id_DS].DS)

3.require(A_list[id_DS].Tp[id_DS][id_TP].tpflag!=1)

4.A_list[id_DS][id_DS].push(TP)

5.A_list[id_DS].Tp[id_DS][id_TP].tp=TP

6.A_list[id_DS].Tp[id_DS][id_TP].act=at

7.A_list[id_DS].Tp[id_DS][id_TP].ds=msg.sender

8.A_list[id_DS].Tp[id_DS][id_TP].token=sha256(abi.encodePackedid_TP,act,block.timestamp)

9.A_list[id_DS].Tp[id_DS][id_TP].tpflag=1

10.A_list[id_DS].tpsflage++

9.return true

DS允許TP對其進(jìn)行訪問，就要說明TP的身份和訪問的具體內(nèi)容(CURD)；TP通知AC已通過DS的授權(quán)，此時通過步驟1AC首先確認(rèn)DS是否允許它對其數(shù)據(jù)進(jìn)行管理；通過步驟2、3檢查DS與A_list對應(yīng)的DS是否相同，同時確認(rèn)TP已獲授權(quán)；在步驟4中為已獲授權(quán)的TP創(chuàng)建tps列表項；通過步驟4-10所獲授權(quán)內(nèi)容進(jìn)行改動，發(fā)送success。

中斷TP訪問的算法設(shè)計如下。

輸入id_DS,id_TP//輸入DS和TP地址

輸出success

1.require(A_list[id_DS].flag==1)

2.require(msg.sender==A_list[id_DS].DS)

3.遍歷tps找出TP在列表中的索引i

4.delete A_list[id_DS].tps[id_DS][i]

5.delete A_list[id_DS].Tp[id_DS][Tp]

6.A_list[id_DS].tpsflage—

7.return true

若DS需要中斷的TP訪問，則通過步驟1確認(rèn)DS是否允許AC對其數(shù)據(jù)進(jìn)行管理；通過步驟2檢查DS與與A_list對應(yīng)的DS是否相同；通過步驟3確認(rèn)TP在列表中的對應(yīng)項；通過步驟4將TP所有有關(guān)項刪除，發(fā)送success。

3 應(yīng)用測試

3.1 系統(tǒng)應(yīng)用實現(xiàn)

通過remix編譯器的Java Script VM開發(fā)系統(tǒng)應(yīng)用界面，其如圖4所示。

圖4 系統(tǒng)運行測試界面

界面中的regMange是對個人數(shù)據(jù)進(jìn)行管理申請的函數(shù)，grant函數(shù)負(fù)責(zé)向TP發(fā)送授權(quán)，revoc函數(shù)則能夠撤銷這些授權(quán)。模塊測試過程如圖5和圖6所示。

圖5 AC協(xié)助DS管理數(shù)據(jù)

圖6 DS通過TP的訪問申請

在remix網(wǎng)絡(luò)環(huán)境下進(jìn)行測試，單次測試運行間隔為2 s。利用Caliper軟件進(jìn)行2次性能測試，第一次分成兩輪進(jìn)行，500次/輪，第二次分成三輪進(jìn)行，50次/輪，所獲結(jié)果分別如圖7和圖8所示。

圖7 第一次運行測試結(jié)果

圖8 第二次運行測試結(jié)果

由圖7和圖8可見，低延時數(shù)值在運行500次時較高，且tps通過數(shù)一直處在10的水平。

3.2 運行結(jié)果分析

在個人數(shù)據(jù)保護(hù)系統(tǒng)里，DS與TP的對應(yīng)關(guān)系為多對多的形式，可利用Solidity語言中的mapping編程設(shè)計出第二層地址指向，即mapping(address=>mapping(address=>TP))TP，使TP地址能夠與多個DS的TP_policy相對應(yīng)，通過DS地址指向TP的TP_policy來說明TP所獲取的DS授權(quán)。基于Solidity語言的msg.sender特性來確保僅由DS發(fā)出授權(quán)認(rèn)證，在此情況下若采用其它語言或超級賬本進(jìn)行驗證就必須重新編寫合約代碼。若增加系統(tǒng)的節(jié)點數(shù)量，分布式賬本會更多，那么在只有很少的數(shù)據(jù)遭到改動的情況下是無法進(jìn)行優(yōu)勢攻擊的，區(qū)塊鏈數(shù)據(jù)的安全性就得到了很好的保證。

4 案例應(yīng)用

4.1 案例描述

為了驗證本文系統(tǒng)的有效性和安全，以某比特幣挖礦體系為例，研究本文系統(tǒng)在安全性和有效性上的優(yōu)勢。該體系由3個挖礦計算機、3個IoT傳感器和5個以太坊全節(jié)點組成，還包括1個云存儲服務(wù)器和2個常規(guī)用戶。

本文系統(tǒng)通過2個智能合約對比特幣挖礦體系進(jìn)行數(shù)據(jù)保護(hù)，第一個智能合約包括財務(wù)功能、數(shù)據(jù)請求功能和注冊傳感器；當(dāng)用戶向體系請求數(shù)據(jù)時，本文系統(tǒng)通過運行狀態(tài)創(chuàng)建第二個智能合約，并通過相關(guān)實體和群組消息傳遞共享第二個智能合約地址，在此過程中會檢測人員身份。在第二個智能合約部署過程中，用戶會將公鑰作為構(gòu)造函數(shù)值進(jìn)行發(fā)送。當(dāng)云服務(wù)器通過傳感器數(shù)據(jù)臨時地址對智能合約進(jìn)行更新時，會通知用戶應(yīng)用程序，并從云服務(wù)器中下載請求的數(shù)據(jù)，檢驗完整性和簽名后對數(shù)據(jù)進(jìn)行解密。

4.2 案例分析

基于區(qū)塊鏈的數(shù)據(jù)保護(hù)系統(tǒng)應(yīng)用到比特幣挖礦體系中，其安全性和有效性主要體現(xiàn)在計算成本上，因此，將本文系統(tǒng)與文獻(xiàn)[6]和文獻(xiàn)[7]的系統(tǒng)計算成本進(jìn)行對比，如表1所示。

表1 3個系統(tǒng)計算成本對比

在表1中，G1和G2為2個階為素數(shù)p>2k的加法群和乘法群，M和E分別表示G1中的點乘計算量和取冪計算量，P為配對操作計算量。由此看出，本文系統(tǒng)的綜合計算成本與其他2個系統(tǒng)相當(dāng)。

在案例應(yīng)用過程中，使用的參數(shù)具有80位AES密鑰規(guī)模安全級別，得到計算時間對比結(jié)果如表2所示。由此看出，雖然與其他2個系統(tǒng)的計算成本相當(dāng)，但該系統(tǒng)計算時間上更短，尤其是最費時的解簽密階段，本系統(tǒng)計算時間具有一定優(yōu)勢。

表2 計算時間對比

為了進(jìn)一步驗證本系統(tǒng)安全性，將3個系統(tǒng)的密文長度和安全性規(guī)模進(jìn)行對比，其結(jié)果如表3所示。其中，m為消息，|x|表示x的密文長度位數(shù)。由此看出，3個系統(tǒng)均滿足安全性，而只有本文系統(tǒng)能夠同時滿足IND-CCA2和EUF-CMA安全性。相比其他2個系統(tǒng)，本文系統(tǒng)的第二級密文長度更短，因此本文系統(tǒng)的加密效率更高。

表3 密文長度和安全性規(guī)模對比

5 總結(jié)

本文所設(shè)計的區(qū)塊鏈個人數(shù)據(jù)保護(hù)系統(tǒng)，解決了原有系統(tǒng)中普遍存在的問題，進(jìn)一步提升了數(shù)據(jù)存儲的安全性。在系統(tǒng)設(shè)計方案中，將數(shù)據(jù)的訪問權(quán)限分散于各模塊，AC接收加密地址，RS接收解密，而真正的數(shù)據(jù)地址則是由RS進(jìn)行解密處理并提供給TP。通過案例可知，該系統(tǒng)相對于文獻(xiàn)[6]和文獻(xiàn)[7]數(shù)據(jù)保護(hù)系統(tǒng)來說，其有效性相當(dāng)，而安全性和計算耗時方面具優(yōu)勢。