馬 繼, 周 鳳, 田有亮,2,3
1(貴州大學 計算機科學與技術(shù)學院, 貴陽 550025)
2(貴州大學 公共大數(shù)據(jù)國家重點實驗室, 貴陽 550025)
3(貴州大學 密碼學與數(shù)據(jù)安全研究所, 貴陽 550025)
信任作為一個抽象的概念, 卻在不同領(lǐng)域之中都顯得十分重要[1], 在職場領(lǐng)域有調(diào)查指出, 職場失信的重災(zāi)區(qū)集中在招聘環(huán)節(jié), 個人履歷造假情況超過了半數(shù)以上.在傳統(tǒng)的履歷存證方法中, 通常需要委托第三方機構(gòu)進行候選人背景調(diào)查, 然后再由第三方機構(gòu)出具相關(guān)的調(diào)查報告, 比如A企業(yè)需要核實候選人B的履歷信息, 就需要第三方機構(gòu)在收到委托與授權(quán)后充當中心角色向C企業(yè)進行核實并返回調(diào)查報告[2]. 此過程涉及到多方的參與, 且對于最終履歷數(shù)據(jù)的管理呈現(xiàn)為以第三方機構(gòu)為核心的中心化結(jié)構(gòu), 這對候選人的履歷信息管理、真實性鑒別帶來了十分巨大的困難. 同時, 隨著云計算技術(shù)的崛起, 使用云存儲技術(shù)進行數(shù)據(jù)存儲是大勢所趨,而云服務(wù)器通常被認為是半誠實且好奇的[3], 這意味著它將誠實地執(zhí)行算法,但會嘗試學習盡可能多的私有信息. 因此, 如何安全的將真實可靠的履歷數(shù)據(jù)存放在云服務(wù)器中, 如何安全正確的將履歷數(shù)據(jù)進行共享, 仍舊是一個不小的難題. 區(qū)塊鏈[4]作為一種去中心化的存儲結(jié)構(gòu), 存儲在鏈上的數(shù)據(jù)具有不可篡改、公開透明、可溯源性等特征, 這些特性天然的適合需要保證數(shù)據(jù)可信度以及公開透明的應(yīng)用場景, 因此基于區(qū)塊鏈網(wǎng)絡(luò)進行信息共享是解決傳統(tǒng)信息共享中心化的途徑. 目前基于區(qū)塊鏈技術(shù)對人才履歷存證的相關(guān)研究較匱乏, 但在其他方面比如數(shù)字版權(quán)存證[5]、金融行業(yè)[6,7]、電子病歷共享[8]等方面均取得了巨大的進展. 上述研究與區(qū)塊鏈技術(shù)在人才履歷存證中的應(yīng)用需要考慮的因素基本相同, 即如何保證數(shù)據(jù)的真實性與安全性、如何保證用戶收到數(shù)據(jù)的正確性.
Song等人[9]為了節(jié)省本地存儲空間與保護數(shù)據(jù)安全, 首次提出了一種基于單關(guān)鍵字的可搜索加密(Searchable Encryption, SE)方案, 方案將所有文件加密后上傳到服務(wù)器進行存儲, 在需要對文件進行檢索時使用加密后的關(guān)鍵字與所存儲文件進行一一比較, 以發(fā)現(xiàn)是否存在所需文件, 但在數(shù)據(jù)較大時會限制檢索的效率. 基于此項研究, Cao等人[10]首次提出了基于多關(guān)鍵字的SE方案, 方案引入“坐標匹配”相似性度量以提升搜索效率并且實現(xiàn)在不同威脅模型下的系統(tǒng)安全性. Sun等人[11]最早開始研究有效搜索結(jié)果驗證問題,并提出了相應(yīng)的可驗證SE方案, 他們的方案使得用戶能夠進行安全的聯(lián)合關(guān)鍵詞搜索, 更新外包文件集并有效地驗證搜索結(jié)果的真實性. Naveed等人[12]提出了動態(tài)SE方案, 方案允許用戶使用服務(wù)器存儲加密文檔的動態(tài)集合, 然后在對這些加密文檔進行快速搜索的同時, 向服務(wù)器顯示最少的信息. Chen等人[8]基于區(qū)塊鏈提出了一種可驗證最終結(jié)果的SE數(shù)據(jù)共享方案,方案基于布爾表達式對鏈上數(shù)據(jù)進行搜索, 相比文獻[9]方案提升了文件搜索效率, 但一旦第三方獲取了數(shù)據(jù)索引的內(nèi)容可能會導致數(shù)據(jù)的泄露. Hu等人[13]結(jié)合區(qū)塊鏈技術(shù)首次提出了無需驗證最終結(jié)果正確性的SE數(shù)據(jù)共享方案, 方案引入押金機制, 確保了數(shù)據(jù)共享過程中的參與方在無需驗證結(jié)果的情況下收到正確的執(zhí)行結(jié)果, 實現(xiàn)了參與者之間的公平性與隱私保護.
本文結(jié)合區(qū)塊鏈與可搜索加密技術(shù)提出了一種基于區(qū)塊鏈的可搜索加密人才履歷共享方案, 去除傳統(tǒng)第三方機構(gòu), 解決了傳統(tǒng)人才履歷存證中數(shù)據(jù)管理中心化、履歷造假等問題. 所提方案首先基于區(qū)塊鏈不可篡改的特性, 結(jié)合云存儲技術(shù)對履歷數(shù)據(jù)實現(xiàn)鏈上鏈下協(xié)同存儲, 保證了履歷數(shù)據(jù)的真實性. 其次, 在履歷數(shù)據(jù)共享過程中, 利用區(qū)塊鏈去中心化的特性取代傳統(tǒng)第三方機構(gòu), 結(jié)合可搜索加密技術(shù)實現(xiàn)了參與方之間的公平性與數(shù)據(jù)存儲、更新時的隱私保護. 最后基于Hyperledger[14]聯(lián)盟鏈實現(xiàn)方案并對安全性和性能進行分析, 保證方案的正確性以及實際的可行性.
區(qū)塊鏈技術(shù)發(fā)展至今, 演化出了許多分支. 按照網(wǎng)絡(luò)結(jié)構(gòu)去中心化程度的不同可以分為:
公有鏈: 全網(wǎng)公開, 無用戶授權(quán)機制的區(qū)塊鏈, 節(jié)點可以自由出入網(wǎng)絡(luò), 以文獻[4]為代表;
聯(lián)盟鏈: 允許授權(quán)的節(jié)點加入網(wǎng)絡(luò), 可根據(jù)權(quán)限查看信息, 往往被用于機構(gòu)間的區(qū)塊鏈, 也稱為行業(yè)鏈,代表有文獻[14];
私有鏈: 所有網(wǎng)絡(luò)中的節(jié)點都掌握在單獨的個人或?qū)嶓w手中, 鏈上的數(shù)據(jù)不被其他任何人所知曉.
由于訪問聯(lián)盟鏈需要許可的特性, 現(xiàn)在已被廣泛應(yīng)用于銀行、保險、證券、商業(yè)協(xié)會等[15]. 聯(lián)盟鏈的記賬節(jié)點是提前在內(nèi)部預(yù)選的多個節(jié)點作為記賬節(jié)點,新塊的產(chǎn)生由預(yù)選記賬節(jié)點決定, 其他節(jié)點只參與交易過程, 但不過問記賬細節(jié), 因此聯(lián)盟鏈不需要通過工作量證明算法(Proof Of Work, POW)共識, 轉(zhuǎn)而更傾向于實用拜占庭算法(Practical Byzantine Fault Tolerance, PBFT)或委托權(quán)益證明(Delegated Proof Of Stake, DPOS)[16]共識算法來保證數(shù)據(jù)的正確性. 由于共識機制的更改, 聯(lián)盟鏈通常還具有更高的系統(tǒng)吞吐量, 更低的資源消耗, 還允許擁有權(quán)限的第三方通過開放的API查詢指定的數(shù)據(jù), 這些特性極大拓寬了區(qū)塊鏈的應(yīng)用領(lǐng)域.
智能合約[17]定義為“一套以數(shù)字形式定義的承諾,包括合約參與方可以在上面執(zhí)行這些承諾的協(xié)議”. 在比特幣以前, 智能合約由于缺少可信的運行環(huán)境, 并沒有在實際生產(chǎn)中實現(xiàn)和運用. 但是在區(qū)塊鏈系統(tǒng)中, 智能合約在共識和網(wǎng)絡(luò)的封裝之上, 可在不涉及第三方的情況下促進交易的可靠執(zhí)行, 并且所有交易都是可追蹤且不可逆的, 隱藏了區(qū)塊鏈網(wǎng)絡(luò)中各節(jié)點的復雜行為, 同時提供了區(qū)塊鏈應(yīng)用層的接口. 這意味著智能合約可提供優(yōu)于傳統(tǒng)合約法的安全性, 并降低與合約相關(guān)的交易成本, 這些特性與區(qū)塊鏈的結(jié)合同樣增加了區(qū)塊鏈的應(yīng)用場景.
可搜索加密問題最早源于文獻[9]: 假設(shè)用戶試圖將文件存放在誠實但好奇的服務(wù)器中, 以節(jié)約本地資源, 同時為保護文件隱私, 須采用某種加密方式將文件加密后存儲. 可搜索加密主要由4個算法組成[18]:
(1)加密: 用戶使用密鑰對明文進行加密并將所得密文上傳服務(wù)器.
(2)陷門生成: 用戶使用密鑰生成待查詢關(guān)鍵詞的陷門, 要求陷門不能泄露關(guān)鍵詞的任何信息.
(3)檢索: 服務(wù)器以陷門為輸入, 執(zhí)行檢索算法, 返回所有包含該陷門對應(yīng)關(guān)鍵詞的密文文件, 要求服務(wù)器除了能知道密文文件是否包含某個特定關(guān)鍵詞外,無法獲得更多信息.
(4)解密: 用戶使用密鑰解密服務(wù)器返回的密文文件, 獲得明文結(jié)果.
從密碼構(gòu)造角度可搜索加密現(xiàn)可劃分為兩大類,即對稱可搜索加密與非對稱可搜索加密. 其中, 對稱可搜索加密的構(gòu)造通?;趥坞S機函數(shù), 具有計算開銷小、算法簡單、速度快的特點, 除了加解密過程采用相同的密鑰外, 其陷門生成也需密鑰的參與. 相比于非對稱加密, 對稱加密的計算量小, 加密速度快, 當加密大量數(shù)據(jù)時其實現(xiàn)效率要比非對稱加密高6-10倍, 但密鑰的分發(fā)缺乏安全, 算法的安全性在很大程度上依賴于密鑰[19]. 非對稱可搜索加密使用兩種密鑰: 公鑰用于明文信息的加密和目標密文的檢索, 私鑰用于解密密文信息和生成關(guān)鍵詞陷門. 非對稱加密算法通常較為復雜, 加解密速度較慢, 然而其公私鑰相互分離的特點, 避免了在發(fā)送者與接收者之間建立安全通道: 發(fā)送者使用接收者的公鑰加密文件和關(guān)鍵詞, 檢索時, 接收者使用私鑰生成待檢索關(guān)鍵詞陷門, 服務(wù)器根據(jù)陷門執(zhí)行檢索算法后返回目標密文, 具有較高的實用性.
通過對傳統(tǒng)人才履歷存證流程的分析, 本文提出了一個基于區(qū)塊鏈的可搜索加密人才履歷共享方案,方案模型如圖1所示.
模型共包含4個實體, 分別是數(shù)據(jù)擁有者、用戶、云服務(wù)器以及區(qū)塊鏈, 表示為四元組(Cs,B,D,U). 其中Cs代表云服務(wù)器;B代表區(qū)塊鏈網(wǎng)絡(luò);D代表數(shù)據(jù)擁有者集合, 由負責生成人才履歷信息并將數(shù)據(jù)上鏈的用戶組成, 即:
U代表用戶集合, 由需要從鏈上獲取數(shù)據(jù)的參與方組成, 即:
模型改進了傳統(tǒng)履歷存證完全依靠人工方式的缺點, 去除了傳統(tǒng)履歷存證中的第三方機構(gòu), 進而減少了履歷造假的可能性. 并且模型對參與方進行了嚴格的身份權(quán)限控制: 數(shù)據(jù)擁有者需要通過身份認證才能獲得區(qū)塊鏈的準入權(quán)限, 而用戶在對數(shù)據(jù)進行搜索之前同樣需要獲得數(shù)據(jù)擁有者授權(quán)以獲得數(shù)據(jù)索引才能進行數(shù)據(jù)的搜索工作, 這樣的設(shè)計從源頭上解決了可能的數(shù)據(jù)造假問題, 相比傳統(tǒng)的履歷存證提升了效率與數(shù)據(jù)真實性. 完整的系統(tǒng)過程描述如下:
(1) 數(shù)據(jù)擁有者Di申請區(qū)塊鏈準入權(quán)限以加入集合D, 之后Di對已有數(shù)據(jù)運行第4節(jié)中算法以獲得加密后的密文C與數(shù)據(jù)索引I.
(2) 數(shù)據(jù)擁有者Di上傳密文C至云服務(wù)器Cs.
(3) 數(shù)據(jù)擁有者Di上傳索引I至區(qū)塊鏈網(wǎng)絡(luò)B.
(4) 用戶Uj向Di申請授權(quán)以獲得搜索標識Q.
(5)Di分別將搜索標識Q發(fā)往區(qū)塊鏈B及用戶Uj.
(6)Uj用標識Q向區(qū)塊鏈網(wǎng)絡(luò)B發(fā)起搜索請求.
(7)B執(zhí)行搜索算法之后返回數(shù)據(jù)索引給Uj.
(8)Uj使用數(shù)據(jù)索引向云服務(wù)器請求密文Cm.
(9) 云服務(wù)器返回對應(yīng)密文Cm給Uj.
在上述過程中, 搜索標識Q包含當次查詢所需的數(shù)據(jù)索引信息以及雙方的身份信息, 并且分別由數(shù)據(jù)擁有者以及用戶發(fā)往區(qū)塊鏈進行存儲備份, 再由智能合約調(diào)用搜索算法對Q進行相關(guān)數(shù)據(jù)搜索, 并假設(shè)最終結(jié)果將通過一個安全的通道傳輸給用戶.
在本節(jié)中, 將給出所提方案的具體構(gòu)造. 方案基于區(qū)塊鏈與可搜索加密技術(shù), 不僅可以保證履歷數(shù)據(jù)的真實性, 實現(xiàn)數(shù)據(jù)的隱私保護, 還具有公平性和健壯性.方案一共由3個多項式時間算法組成: 初始化, 查詢,更新. 我們定義了如下兩個偽隨機函數(shù), 其中λ是系統(tǒng)安全性參數(shù), *代表長度可為任意值. 假設(shè)所有數(shù)據(jù)存放在非關(guān)系型數(shù)據(jù)庫CouchDB中, 且涉及到的其他符號定義如表1所示.
表1 符號定義
在初始化階段, 數(shù)據(jù)擁有者首先將隨機生成兩個長度為λ的mk、sk以作為后續(xù)生成中間參數(shù)以及進行數(shù)據(jù)加密的密鑰. 然后對于已有的每份數(shù)據(jù), 將mk、sk以及整份數(shù)據(jù)作為算法的輸入, 輸出是數(shù)據(jù)的索引以及加密后的密文. 在對所有數(shù)據(jù)進行上述操作之后,將輸出的數(shù)據(jù)索引集合I發(fā)送到智能合約, 由智能合約進行索引的存儲, 將輸出的密文集合C存儲至云端.詳細的算法步驟見算法1.
算法1. Setup輸入: mk, sk, R輸出: I, C 1. the data owner init list L 2. for r∈R 3. K1←F(mk, 1|| rid); K2←F(mk, 2||r)s←-4. g {0,1}λ; d← id⊕G(K2, g); l←F(K1,1)5. add tuple (l, d||g)) to L 6. encrypt r with sk;7. end for 8. the data owner send L to the smart contract 9. the smart contract init list γ, γD and γU 10. for tuple (l, d||g) ∈ L 11. add (l, d||g) to γ;12. end for 13. end
在查詢階段, 用戶首先向數(shù)據(jù)擁有者發(fā)送申請授權(quán)請求以獲得特定數(shù)據(jù)的搜索標識Q. 數(shù)據(jù)擁有者先將Q發(fā)送至區(qū)塊鏈進行記錄, 然后再發(fā)送給用戶. 用戶在獲得Q之后將其發(fā)往區(qū)塊鏈進行數(shù)據(jù)查詢, 由智能合約調(diào)用搜索算法執(zhí)行當次數(shù)據(jù)搜索, 并判斷搜索結(jié)果的有效性, 同時將Q再次記錄到區(qū)塊鏈中. 在所有操作執(zhí)行完成之后由智能合約將數(shù)據(jù)索引返回給用戶.詳細的算法步驟見算法2.
算法2. Search輸入: Q輸出: Dataindex 1. the data owner sends Q to the smart contract and the user;2. the smart contract add Q to γD;3. the user sends Q to the smart contract to get data index;4. the smart contract:5. add Q to γU;6. l←F(K1, 1); d,g←Get(γ, l);7. if d=⊥ && g=⊥8. return false;9. else 11. id←d⊕G(K2, g);10. return id;11. end if 12. end
在更新階段中包含了在新區(qū)塊中新增履歷數(shù)據(jù)和更新已有數(shù)據(jù)兩個操作. 算法以mk、sk以及待操作的數(shù)據(jù)作為輸入, 首先按照初始化階段算法的思路對數(shù)據(jù)生成索引以及密文C, 然后再從操作集合O(新增add和更新update)中選取當次更新是做什么操作. 對所有數(shù)據(jù)進行上述操作之后, 將得到的索引以及密文集合分別發(fā)送至區(qū)塊鏈以及文件存儲系統(tǒng), 再由智能合約根據(jù)每條數(shù)據(jù)對應(yīng)的操作進行數(shù)據(jù)處理: 如果是新增操作, 則再插入一條數(shù)據(jù), 否則就對已有數(shù)據(jù)進行更新操作. 詳細的算法步驟見算法3.
算法3. Upgrade輸入: mk, sk, R輸出: I, C 1. the data owner init list LA;2. for r∈R 3. K1←F(mk, 1|| rid); K2←F(mk, 2||r);s←-4. g {0, 1}λ; d← id⊕G(K2, g); l←F(K1, 1);5. choose an operation o from list O;6. add tuple (l, d, g, o) to LA;7. encrypt r with sk;8. end for 9. the data owner send LA to the smart contract;10. the smart contract:11. for tuple (l, d, g, o) ∈ LA 12. if o= add 13. add (l, d||g) to γ;14. else 15. d′, g′←Get(γ, l);16. set d′=d, g′=g;17. update γ with tuple (l, d′||g′);18. end if 19. end for 20. end
本文所提出的方案主要關(guān)注查詢結(jié)果的準確性與公平性, 而沒有考慮訪問每條履歷信息更細粒度的權(quán)限控制問題, 這可以使用現(xiàn)有的方案來實現(xiàn), 例如使用ABE (Attribute-Based Encryption)算法來實現(xiàn)更細粒度的訪問控制[20,21].
上述方案通過引入?yún)^(qū)塊鏈與可搜索加密技術(shù)以保證人才履歷信息的真實性, 并且對于履歷數(shù)據(jù)的存儲與共享目標和文獻[8,13]所提出的目標類似, 我們實現(xiàn)了履歷數(shù)據(jù)在存儲過程中的保密性、數(shù)據(jù)共享時的公正性和方案的健壯性.
真實性: 履歷數(shù)據(jù)僅來自于上述模型中的數(shù)據(jù)擁有者, 由個人或企業(yè)直接向相應(yīng)的驗證方發(fā)起認證并獲得履歷數(shù)據(jù). 由于在進行履歷驗證的各環(huán)節(jié)中均需要進行身份認證, 并且數(shù)據(jù)一旦生成就會在區(qū)塊鏈中記錄下來, 減少了全過程的參與方, 實現(xiàn)了履歷數(shù)據(jù)存儲的去中心化, 降低了履歷造假的可能性, 提升了履歷信息的真實性.
健全性: 顯然在Hyperledger聯(lián)盟區(qū)塊鏈安全性保證的前提下, 本文所提方案實現(xiàn)了健全性. 因為智能合約代碼直接由Hyperledger聯(lián)盟區(qū)塊鏈執(zhí)行, 不受任何第三方的干擾, 同時區(qū)塊鏈的共識機制可以確保每個操作的正確執(zhí)行, 并且執(zhí)行后的結(jié)果會被永久的存儲在鏈上, 鏈上的所有節(jié)點都可以驗證數(shù)據(jù)的有效性.
公平性: 在此前的多方參與數(shù)據(jù)共享方案中存在的問題是: 如何保證數(shù)據(jù)擁有者給出正確的數(shù)據(jù)索引,以及如何確保用戶無法抵賴稱自己沒有收到索引. 針對這兩個問題, 在所提方案中, 當數(shù)據(jù)擁有者給出數(shù)據(jù)搜索標識Q時, 需先將其記錄在鏈上集合γD中; 用戶在進行數(shù)據(jù)搜索之前, 也需要將Q記錄在鏈上集合γU中, 即:
當其中一方試圖抵賴自己之前的操作時, 另一方可以選擇發(fā)起請求驗證交易并由智能合約執(zhí)行以下算法判斷撒謊者, 算法以驗證交易作為輸入, 首先判斷請求者身份:
若交易發(fā)起者是數(shù)據(jù)擁有者, 判斷集合γU中是否存在關(guān)于QD的數(shù)據(jù), 若存在, 則返回1表示用戶Uj撒謊, 否則返回null表示交易正常.
若交易發(fā)起者是用戶, 則判斷集合γD中是否存在關(guān)于QU的數(shù)據(jù), 若存在, 與QU進行比較, 數(shù)據(jù)不一致則返回0表示Di撒謊, 否則返回null表示交易正常;若不存在, 則返回0表示Di撒謊.
算法4. Sentence輸入: verify request輸出: 0|1|null 1. if requester ∈D 2. if find QD in γU 3. return 1 4. else 5. return null
6. end if 7. else 8. if find Qu in γD 9. if Qu≠Q(mào)u 10. return 0 11. else 12. return null 13. end if 14. else 15. return 0 16. end if 17. end
由于整個算法是由智能合約執(zhí)行, 由系統(tǒng)的健壯性可知, 鏈上所記錄的數(shù)據(jù)都是完全正確的, 因此無論是數(shù)據(jù)擁有者還是用戶, 任何一方提供的錯誤信息都將被發(fā)現(xiàn).
保密性: 為了證明方案的保密性, 我們使用一個在模擬者S和對手A之間的real-ideal模擬游戲來進行證明. 在此之前給出如下3個關(guān)于本文方案的狀態(tài)泄露函數(shù)SL=(SL1,SL2,SL3).
給定初始化輸入R,SL1被定義為初始化狀態(tài)泄露函數(shù):
同時它初始化一個空集合L, 一個密文集C, 并將他們進行存儲.
給定一個搜索輸入r,SL2被定義為:
其中,sp(r, L)表示搜索模式. 給定待搜索文檔r, 它將輸出搜索模式sp以及搜索標識Q.
給定一個更新輸入(id,r),SL3被定義為:
其中,ap(i,d,L)表示r關(guān)于L的新增模式;up(i,d,L)表示r關(guān)于L的更新模式.
定理1. 如果F和G是偽隨機的, 那么本文所提方案針對非自適應(yīng)攻擊是安全的.
證明: 我們假設(shè)S是多項式時間的模擬者, 那么對于任意同樣是多項式時間的對手來說, 真實執(zhí)行RealA(λ)的輸出和模擬執(zhí)行的IdealA, S(λ)的輸出在計算上是難以區(qū)分的. 模擬器通過給定的泄漏函數(shù)SL模仿真實協(xié)議來模擬對手的視角. 例如, 為了模擬初始化階段,S首先為每個搜索隨機的選擇k1,k2由搜索模式指定重復的次數(shù). 對于所有的文件,S按真實的初始化階段計算出l,d,g并將每一個鍵值對(l,d||g)加入到集合L中,再隨機的添加m個鍵值對到L中, 并最終創(chuàng)建出一個字典γ′. 類似的,S可以通過泄露函數(shù)SL模擬出搜索和更新請求. 因此, 由于F和G的偽隨機性, 我們的定理成立. 特別的, 方案可以通過使用隨機預(yù)言機以達到對自適應(yīng)攻擊的安全性[13,22].
為了驗證本文所提方法的安全性及性能, 我們使用了5臺搭載Intel(R) Xeon(R) Gold 6278C CPU, 8 GB RAM, 操作系統(tǒng)為 CentOS 7.6的云服務(wù)器作為實驗基礎(chǔ), 基于開源區(qū)塊鏈網(wǎng)絡(luò)Hyperledger Fabric 1.4.0, 構(gòu)建了一個包含3個order節(jié)點, 4個peer節(jié)點, 使用CouchDB作為WorldState數(shù)據(jù)庫, 智能合約由Java編寫的區(qū)塊鏈網(wǎng)絡(luò)作為基礎(chǔ)實驗環(huán)境, 使用了搭載Intel core i5-7500 CPU,16 GB RAM, Windows10 (64 bit)的本地主機模擬數(shù)據(jù)擁有者以及用戶進行所提方案的實驗仿真,同時忽略出塊時間對實驗結(jié)果的影響.
由于沒有足夠的履歷信息數(shù)據(jù)集支撐, 因此本次實驗選擇了由Rajkovic等人[23]建立的Nursery數(shù)據(jù)集進行實驗. 這是一個包含了12 960條純文本記錄的數(shù)據(jù)集, 為了滿足方案的條件, 我們?yōu)槊織l數(shù)據(jù)添加了文件id作為CouchDB數(shù)據(jù)庫的_id字段, 并且將每條文本下含的8個屬性進行調(diào)整以滿足履歷信息的數(shù)據(jù)格式. 實驗共從3方面進行, 包含了系統(tǒng)的安全性、搜索以及數(shù)據(jù)更新的性能. 整個方案的初始化階段可視作為更新操作的變體, 因此所需時間的多少可由初始化時具體的數(shù)據(jù)量估算, 此處沒有進行實驗.
針對方案的安全性, 我們設(shè)計了2組測試場景, 并分別對每種測試場景進行了系統(tǒng)安全性測試. 2組測試場景內(nèi)容如下:
場景1. 未取得授權(quán)時數(shù)據(jù)擁有者以及用戶對區(qū)塊鏈的操作.
預(yù)期結(jié)果: 所有操作均被拒絕.
場景2. 取得區(qū)塊鏈系統(tǒng)授權(quán)時數(shù)據(jù)擁有者以及用戶抵賴的情況.
預(yù)期結(jié)果: 雙方的抵賴操作均被發(fā)現(xiàn).
通過對場景1和場景2各進行100次實驗, 實驗結(jié)果表明, 參與者在未取得授權(quán)的情況下, 在系統(tǒng)模型的健全性以及Hyperledger Fabric網(wǎng)絡(luò)本身安全性的保證下, 所有的異常數(shù)據(jù)操作都被拒絕. 同時, 當取得授權(quán)的雙方在對區(qū)塊鏈做數(shù)據(jù)查詢時, 在系統(tǒng)公平性的保證下, 如果是數(shù)據(jù)擁有者提供錯誤的數(shù)據(jù)索引給用戶, 在出現(xiàn)異常時通過對鏈上存儲的數(shù)據(jù)索引進行檢驗即可發(fā)現(xiàn)錯誤的數(shù)據(jù)索引項; 如果用戶收到正確的數(shù)據(jù)索引卻意圖抵賴, 此時存在兩種情況: 一是用戶不進行數(shù)據(jù)查詢操作, 那么即使他獲得了數(shù)據(jù)索引也無法獲得任何的原始數(shù)據(jù)信息. 二是用戶進行數(shù)據(jù)查詢,除非使用正確的數(shù)據(jù)索引進行搜索, 否則仍舊無法獲得任何信息, 而一旦使用正確的信息進行搜索, 此過程將被區(qū)塊鏈系統(tǒng)記錄下來, 即用戶無法對此過程進行抵賴.
下面對本文所提方案的性能進行評估. 本文所提方案的時間開銷主要分為兩種類型: 搜索和更新操作的時間開銷. 其中搜索的時間開銷主要包含兩部分, 即實際數(shù)據(jù)搜索時間以及將數(shù)據(jù)標識Q上鏈備份的時間, 如圖2中曲線x所示, 當用戶首次向服務(wù)器發(fā)起查詢數(shù)據(jù)請求時, 由于用戶需要與區(qū)塊鏈網(wǎng)絡(luò)之間建立連接, 因此需要花費更多的時間. 更新操作所需時間僅包含在新塊中更新賬本狀態(tài)的時間, 因此整體消耗時間比數(shù)據(jù)搜索操作更低一些, 如圖2中曲線y所示.
圖2 方案時間開銷
根據(jù)上述實驗表明, 本文提出的基于區(qū)塊鏈的可搜索加密人才履歷共享方案, 在數(shù)據(jù)搜索方面和文獻[8,13]所提方案的搜索性能相比, 由于方案具備更加嚴格的搜索控制, 因而增加了部分開銷. 但在數(shù)據(jù)更新方面,由于本方案在數(shù)據(jù)更新時不需要做額外的狀態(tài)判斷,因此數(shù)據(jù)更新性能要優(yōu)于文獻[13], 提升了對數(shù)據(jù)的更新效率.
下面將本文提出的方案與現(xiàn)有方案進行比較. 表2將從方案的查詢模式、查詢內(nèi)容、是否支持對數(shù)據(jù)的動態(tài)更新等方面與其他方案進行對比.
表2 本方案與其他方案對比
Chen等人[8]提出的方案主要是針對電子病歷共享. 方案采用范圍查詢對位于鏈上的病歷數(shù)據(jù)進行搜索, 因而在數(shù)據(jù)量較少時擁有最快的搜索效率, 但是方案卻不支持對數(shù)據(jù)的動態(tài)更新, 導致方案的通用性較差.
Hu等人[13]提出的信息共享方案支持對通用數(shù)據(jù)的信息共享. 方案對鏈上數(shù)據(jù)進行單關(guān)鍵字搜索, 因此在搜索文本的數(shù)量較多時搜索性能會趨近于一個穩(wěn)定值; 同時方案還支持對數(shù)據(jù)的動態(tài)更新, 但是更新操作的開銷遠大于搜索操作開銷, 并且在多方參與時需進行額外調(diào)整以滿足多方之間的搜索公平性.
本文提出的信息共享方案主要是針對履歷信息進行共享, 方案通過對具體數(shù)據(jù)的搜索以實現(xiàn)查詢特定履歷數(shù)據(jù)的目的. 方案滿足在履歷數(shù)據(jù)發(fā)生變更時的數(shù)據(jù)動態(tài)更新操作, 并取締了數(shù)據(jù)更新時在區(qū)塊鏈上判斷的過程, 提升了數(shù)據(jù)更新效率. 同時, 利用智能合約執(zhí)行結(jié)果的正確性保證了在數(shù)據(jù)分享過程中雙方之間的公平性與結(jié)果正確性.
本文基于區(qū)塊鏈與可搜索加密技術(shù)對傳統(tǒng)人才履歷存證中存在的數(shù)據(jù)管理中心化、履歷造假等問題提出了一個新的解決方案. 方案利用區(qū)塊鏈取代傳統(tǒng)第三方機構(gòu), 結(jié)合鏈上鏈下協(xié)同存儲機制保證了履歷數(shù)據(jù)的真實性, 并基于可搜索加密技術(shù)實現(xiàn)了參與方之間的公平性與數(shù)據(jù)存儲、更新時的隱私保護. 通過對方案的安全性及性能進行分析與實驗, 表明方案在支持人才履歷共享的同時也滿足隱私需求以及擁有足夠的系統(tǒng)性能, 但同時對于惡意參與者的懲罰細節(jié)還有待進一步完善.