基于區塊鏈的公平可靠密文檢索系統*

唐夢菲, 蔣 芃, 張芷璇, 李彥霖, 祝烈煌

北京理工大學 網絡空間安全學院, 北京 100081

1 引言

云計算因其便利訪問、彈性服務和按需付費等特點, 受到了廣泛關注, 數據存儲形式大多從本地存儲轉變為外包存儲, 來降低本地的存儲和計算代價. 用戶在將數據外包給第三方云服務器后, 失去了對這些存儲數據的直接控制, 導致數據極大程度上面臨各種威脅, 比如數據可能會被竊取和篡改等. 因此數據安全是外包存儲必須面臨的一個重要問題. 隨著《中華人民共和國數據安全法(草案)》的發布, 數據安全已然成為了國家網絡安全保障中的重要一環. 為了保護數據的機密性, 傳統的方法是采用先加密再存儲的方式, 這給數據的有效查詢和利用造成了一定的困難. 當用戶想要使用某個特定數據時, 若把服務器上所有密文下載到本地, 解密之后再進行搜索, 會造成巨大的時間與空間開銷; 若把密鑰給服務器, 讓服務器解密后再進行查詢, 數據的機密性無法得到保障.

可搜索加密機制(Searchable Encryption, SE) 應運而生[1]. 用戶首先使用SE 機制對數據進行加密并將密文存儲在服務器中, 當用戶需要搜索某個關鍵字時, 便將該關鍵字的搜索口令發送給云服務器, 云服務器將接收到的搜索口令與各個密文進行匹配, 若匹配成功則說明該密文中包含此關鍵字, 遍歷后云服務器將匹配成功的密文返回給用戶. 根據所使用的密碼學機制的不同, 現有的可搜索加密機制分為公鑰可搜索加密(Public key Encryption with Keyword Search, PEKS)[2]和對稱密鑰可搜索加密(Symmetrickey Searchable Encryption, SSE)[3]. 相比SSE 而言, PEKS 因無需復雜的密鑰管理且能實現數據共享,成為了國內外研究的熱點. 在PEKS 機制中, 數據以密文的形式存儲在服務器中, 用戶通過提供關鍵字陷門給服務器, 讓服務器能夠在對關鍵字相關信息一無所知的情況下檢索出相應的密文, 這種密文檢索方式可以有效進行密文形式的查詢, 同時保障了用戶的關鍵字隱私. 公平性和可靠性是用戶判斷數據查詢服務的重要標準. 本文中, 公平性指的是各個參與者能夠獲得自己應該獲得的酬勞, 并且酬勞分配結果能得到廣泛支持; 可靠性是指系統能夠在規定時間內正確地完成檢索任務. 通常的可搜索加密機制會默認服務器能夠誠實且嚴格地執行搜索協議, 然而, 各種利益訴求和軟件入侵都會引起服務器的惡意轉變, 導致其偏離搜索協議, 只返回部分檢索結果甚至是不正確的檢索結果, 而用戶所支付的費用不會被返還. 這種惡意服務器嚴重破壞了檢索過程中的公平性和可靠性. 如何面向惡意服務器實現公平可靠的密文檢索方案成為必須解決的問題.

2008 年, 中本聰[4]首次提出了區塊鏈的概念. 區塊鏈是以分布式時間戳服務器以及P2P 數據傳輸網絡為基礎構建的完全無需第三方的分布式賬本, 它的目標是實現一個只允許添加、不允許刪除的去中心化分布式賬本. 區塊鏈由全網節點共同維護, 共識機制無需可信的第三方, 分布式的網絡架構可以避免中心節點受到攻擊或破壞, 系統穩定性較高, 這些優勢能夠較好地用于解決數據可靠性的問題. Szabo[5]在1994 年提出了智能合約的概念, 智能合約是相互不信任的參與者之間的協議. Clack[6]提出區塊鏈可以作為底層技術用來支持智能合約, 可以讓智能合約在沒有第三方干涉的情況下進行可信交易. 智能合約內置了豐富的轉賬功能, 它的這些機制可以較好地判斷合約參與方的誠信并根據他們做出的行為分配相應的激勵, 從而可以較好地保障公平性.

為了解決目前PEKS 方案中出現的公平性和可靠性的問題, 本文將區塊鏈技術與公鑰可搜索加密技術相結合, 通過編寫智能合約來控制檢索各方的參與. 我們使用區塊鏈來管理和代替第三方服務器, 可以保障存儲的數據是可信的、不可篡改的, 可以解決原有的PEKS 方案及其優化版本的安全性需要依賴誠實服務器的問題. 此類基于區塊鏈的密文檢索系統可以應用在一些對可靠性要求較高的場景中, 如醫療檔案管理、學歷檔案管理和犯罪記錄等. 在一次搜索中, 把搜索數據過程中的交易記錄在區塊鏈中, 鏈中數據不可篡改并且所有節點都可驗證該交易, 而區塊鏈的共識機制保障了每個以太坊節點的一致性. 這種情形下, 交易的結果具有可靠性. 區塊鏈可以保障智能合約各個參與方的激勵發放是準確和可靠的, 那么搜索的公平性也就得到了保障. 現有的區塊鏈與可搜索加密方案結合的案例都是將區塊鏈與對稱密鑰可搜索加密機制相結合, 由于對稱密鑰可搜索加密機制的密鑰不可公開, 所以數據擁有者面臨著大量密鑰管理工作, 并且不支持加密數據的共享, 而區塊鏈由于共識機制的存在是面向共享的, 所以兩者的結合會喪失區塊鏈原有的共享性. 本文將區塊鏈與公鑰可搜索加密機制進行結合, 既可以利用區塊鏈的去中心化與不可篡改性保障數據的可靠與安全, 也可以在方案中繼續延續區塊鏈的共享性, 從而實現加密數據的可靠與共享之間的平衡.

本文旨在設計和實現一個基于區塊鏈公鑰可搜索加密系統(Blockchain-based PEKS), 此系統具有關鍵字隱私性、公平性和可靠性, 可以解決惡意服務器帶來的安全問題. 本文的貢獻主要有以下三點.

(1) 本文在PEKS 方案的基礎上, 結合區塊鏈技術, 提出了一個基于區塊鏈的公鑰加密可搜索方案通用架構.

(2) 本文采用了分層的形式, 利用智能合約構造了一個四層級化的基于區塊鏈公鑰可搜索加密系統.在系統設計中, 不同層具有不同的功能與角色, 每層之間的交互保證整個系統穩定運行, 從而實例化一個安全可靠的基于區塊鏈公鑰可搜索加密方案.

(3) 基于上述所提出的具體方案, 本文實現了基于區塊鏈公鑰加密可搜索的原型系統, 并對原型系統進行了性能測試與分析, 證明了本文構造的可行性與實用性.

2 研究現狀

本節介紹公鑰可搜索加密PEKS、區塊鏈和智能合約等技術的研究現狀, 以支撐基于區塊鏈的公鑰可搜索加密系統的設計.

2.1 PEKS

PEKS 是在大型數據庫中檢索加密數據的方法之一. 為了解決加密數據上信息如何有效查詢利用的問題, Boneh 等人在2004 年提出了PEKS 模型來減少對稱可搜索加密面臨的復雜的密鑰問題[2]. 在PEKS 體系中, 發送方在進行數據加密時, 使用所發信息的關鍵字和接收方的公鑰來生成搜索密文; 而接收方解密時, 利用自己的私鑰以及關鍵字生成關鍵字陷門(Trapdoor) 以匹配搜索密文, 當Trapdoor 與密文匹配成功后, 服務器將相應的數據密文返回給接收方.

近年來, 各類學者就查詢方式和安全性兩個重要方面, 對PEKS 展開了研究. 查詢方式方面, Park[7]等人在2004 年提出了連接關鍵詞公鑰加密可搜索方案; Boneh 和Waters[8]在2007 年提出了在加密數據上的連接、交集、和范圍查詢; Yang 和Ma[9]在2016 年提出了增強查詢表達能力和支持多關鍵字組合密文檢索的方法; 而Zheng[10]等人和Jiang[11]等人提出了通過用戶屬性或指定關鍵字的方式來控制檢索的方法. 安全性方面, Byun[12]等人和Yau[13]等人指出基本PEKS 方案不能抵抗關鍵詞猜測攻擊(Keyword Guessing Attack, KGA). Rhee 等人[14,15]提出了指定測試器的PEKS 模型, 從而抵抗外部KGA; Jiang 等人[16]通過在可搜索密文中引入發送方身份驗證的方式, 實現了公鑰可搜索在外部攻擊下的安全性.

2.2 區塊鏈技術

2008 年中本聰在比特幣論壇首次提出區塊鏈的概念[4]. 區塊鏈是以分布式時間戳服務器以及P2P數據傳輸網絡為基礎構建的完全無需第三方的電子現金系統, 它的目標是實現一個只允許添加、不允許刪除的去中心化分布式賬本. 這個“賬本” 以一個線性鏈表作為基層結構, 該鏈表由若干區塊串聯組成, 每個區塊中記錄了本區塊的編號、簽名、時間戳、交易信息以及前一個區塊的哈希值. 網絡中的任何節點都能通過共識機制的確認向區塊鏈中申請添加一個新的區塊, 同時可用計算哈希值的方式驗證某區塊是否合法. 區塊鏈的結構如圖1 所示.

圖1 區塊鏈的基層結構Figure 1 Basic structure of blockchain

區塊鏈技術因其去中心化、高自治性等特點得以迅猛發展, 它的構造糅合了密碼學、計算機科學、數學等諸多領域的知識.

交易(Transaction): 交易是導致賬本狀態改變的一次操作, 由輸入、輸出和數字簽名三部分組成,一段時間內所有有效交易以某種結構(譬如Merkle 樹) 連接到一起, 由礦工填充入區塊.

區塊(Block): 區塊是對當前賬本狀態的一次共識, 記錄著某段時間發生的全部交易信息.

鏈(Chain): 區塊按照順序線性連接形成鏈, 記錄著整個賬本的所有交易和狀態變化.

共識協議(Consensus protocol): 區塊鏈因其去中心化的性質并沒有中央權威機構, 因此它依靠共識協議做出決策. 共識協議決定了記錄下一個區塊的礦工人選, 礦工們可以通過工作量證明(PoW) 或股權證明(PoS) 等方式來獲取新區快的寫入資格.

P2P 網絡(P2P network): 區塊鏈使用的P2P 網絡是一種分布式應用程序體系結構, 其網絡上的節點擁有相同的權力, 共同構成和維護整個網絡的服務與數據的傳輸和寫入. 這種去中心化的存儲和傳輸方式天生具有不可篡改的特點, 部分節點遭受攻擊也不會對整個系統造成大的影響.

哈希算法(Hash): 哈希算法是將變長輸入映射為定長輸出的二進制串的過程, 在加密和查找算法中應用廣泛. 在區塊鏈中, 數據的存儲依靠哈希算法產生哈希值, 譬如, 使用SHA256 算法產生Merkle 樹的結點信息, 使用Keccak-256 算法產生以太坊賬戶地址, 等等. 一個安全的哈希函數的輸出與隨機數串別無二致.

區塊鏈范式(Blockchain paradigm): 將區塊鏈看作一個基于交易的狀態機[4], 每個狀態包含了現實世界信息的數據, 譬如賬戶余額、隨機數等. 每次記錄交易之后, 狀態機將從創始狀態更新為最終狀態.假設區塊鏈當前狀態為a, 在記錄了事務Tx之后, 區塊鏈狀態變為at+1, 使用F表示區塊鏈執行的任意計算, 則事務Tx記錄前后的有效狀態轉換可以表示為:at+1=F(at,Tx).

2.3 以太坊智能合約

1994 年, Szabo 提出了智能合約的概念[5], Clack[6]討論了如何利用區塊鏈技術實現智能合約. 抽象地說, 智能合約是相互不信任的參與者之間的協議, 可以由區塊鏈的共識機制自動執行從而可以不再依賴于中心化的權威機構. Buterin[17]指出, 目前最適合實現智能合約的區塊鏈框架為以太坊. 以太坊[18]是基于P2P 網絡與密碼學建立起來的區塊鏈機制, 在以太坊中智能合約可以通過圖靈完備的編程語言來實現.

以太坊智能合約的正確執行是其有效性的必要條件, 否則敵手可能會通過篡改執行來從一個合法參與者中獲取非法利潤. 但是僅憑智能合約的正確執行還不足以確保合約的安全, Delmolino[19]和Luu[20]通過實際開發經驗和對以太坊智能合約的靜態分析發現了以太坊智能合約的幾個漏洞. 其中的一些漏洞在現實生活中被黑客利用來攻擊以太坊智能合約竊取利潤.

以太坊漏洞主要來自三個層面: Solidity 編程語言、EVM 以太坊虛擬機[18]和區塊鏈. Solidity 編程語言是以太坊上支持智能合約編寫的編程語言, 編程人員的理解與Solidity 的實際語義的不一致產生了許多漏洞, 針對這些漏洞的攻擊有: DAO 攻擊[21]、“King of the Ether Throne”攻擊[22,23]和GovernMental攻擊[24,25]等. 智能合約漏洞的另一來源為EVM 以太坊虛擬機, 針對以太坊虛擬機安全漏洞的攻擊主要有: Rubixi[26,27]攻擊和GovernMental 攻擊[24,25]. 還有針對區塊鏈級別的攻擊: GovernMental 攻擊[24,25].

盡管Eyal[28]和Luu[20]還指出了區塊鏈的一致性協議的效率中存在一些安全漏洞, 但Garay[29]和Sompolinsky[30]的研究理論表明, 只要誠實的節點控制了區塊鏈網絡中大部分的計算資源, 那么區塊鏈的安全性還是可以得到保障.

2.4 基于區塊鏈的SSE

傳統的可搜索加密機制(SE) 存在重大缺陷, 需要依靠誠實的服務器來保證檢索過程的安全. 而區塊鏈作為一個新興技術, 具有不可篡改性和去中心化的性質, 能夠和SE 結合解決上述的缺陷.

迄今為止的相關研究中, 區塊鏈技術都是與對稱密鑰可搜索機制(SSE) 相結合. 在這個基礎之上, 相關工作主要被分為兩類: 一類是采用智能合約作為執行搜索匹配的實體, 借助智能合約的內在公平性避免傳統服務器的惡意行為, 從而保證搜索可靠性[31]; 另一類在原有的SSE 框架下增加區塊鏈系統作為一個額外的實體[32], 服務器仍然保留原有的搜索功能, 通過與區塊鏈的交易來保證服務器和用戶之間的利益公平.

SSE 在理論上對于數據的共享有一定的限制, 而區塊鏈的設計就是面向數據共享的, 所以兩者結合過程中會有一定沖突. 若把存儲與檢索都放在區塊鏈上, 智能合約承受不了如此大的計算量, 會變得緩慢和昂貴. 比如在上述提到的Hu 等人[31]在2018 年實現的基于區塊鏈的對稱密鑰可搜索系統, 在10 萬條數據中檢索一次平均耗時為24 分鐘.

為了避免SSE 理論上限制共享與區塊鏈面向共享的沖突, 本文把區塊鏈技術與公鑰可搜索加密(PEKS) 相結合, 并通過設計分層化的模型來避開前人工作中出現的檢索速度慢與開銷大的問題, 從而實現一個具有實用價值的公平可靠的基于區塊鏈公鑰可搜索加密系統.

3 預備知識

3.1 符號描述

符號標記如表1 所示.

表1 符號描述Table 1 Symbol description

3.2 PEKS

PEKS 方案由四個概率多項式時間算法構成, 分別為KeyGen(s)、PEKS(pk,W)、Trapdoor(sk,W)、Test(pk,s,TW). 具體算法構造如下:

? KeyGen(s). 輸入安全參數s. 隨機選取α ∈Z?p以及生成元g和構造群G1, 輸出公鑰pk =(g,h=gα), 私鑰sk=α.

? PEKS(pk,W). 輸入公鑰pk 和關鍵字W. 隨機選取r ∈Z?p, 計算t=e(H1(W),hr)∈G2, 輸出搜索密文PEKS(pk,W)=[gr,H2(t)].

? Trapdoor(sk,W). 輸入關鍵字W和私鑰sk. 輸出關鍵字的搜索口令TW=H1(W)α ∈G1.

? Test(pk,s,TW). 輸入公鑰pk、搜索密文CW和搜索口令TW, 其中CW= PEKS(pk,W) =[gr,H2(t)]. 令CW=[A,B], 判斷H2(e(TW,A))=B是否成立, 若成立, 則輸出1, 否則輸出0.

3.3 智能合約架構

以太坊智能合約[17]架構如圖2 所示. 以太坊在每個運作的節點上都運行著一個以太坊虛擬機(EVM), 可以用來執行完整的程序. 這些程序在以太坊中稱為智能合約(smart contract). 智能合約可以用來處理數據, 也內置了轉賬功能, 可以交易加密貨幣. 智能合約部署后放在以太坊公鏈上, 部署時會花費費用給礦工, 每次通過智能合約寫入或讀取計算結果需要提供交易費用, 計算能力由所有以太坊節點提供. 提供計算能力的任何節點都將以Ether 數字貨幣作為資源支付. 智能合約是在每個以太坊節點上執行并驗證的, 所以計算結果是可信任的.

圖2 以太坊智能合約架構Figure 2 Structure of Ethereum smart contracts

以太坊開發出了web3.js 和web3.py, 讓開發者可以用網頁技術來撰寫智能合約的操作界面. 這種網頁操作界面又被稱為分布式應用程序(DAPP). 以太坊提供了便于交易的加密貨幣—以太幣, 可通過智能合約解決交易上的信任問題, 同時也可撰寫DAPP 來提供友善的信息匯總與操作界面, 所以以太坊成為了一個非常理想的區塊鏈底層技術. 開發者通過開發的去中心應用DAPP 來和智能合約進行交互, 通過DAPP 瀏覽器調用智能合約, 從而達到和以太坊交互的目的.

而燃料系統(gas system) 是智能合約特有的交易政策. 執行智能合約需要消耗與執行指令數量相當的以太幣, 在智能合約中, 這些拿來消耗的以太幣被稱為燃料(gas). 當合約部署到以太坊上時, 需要附加一定數量的燃料. 當發送方調用智能合約發起交易時, 智能合約估算此交易需要花費的最大燃料, 只有當發送方的賬戶余額大于最大燃料時, 此交易才能被包含到區塊鏈中執行.

以太坊智能合約如今也存在著一定的局限性, 以太坊區塊鏈的速度和電腦執行的速度無法相比, 不適合快速交易; 無法滿足需要存儲較大數據的情境, 因為其上的存儲成本昂貴.

在本方案中我們把以太坊智能合約與密文檢索技術相結合, 把部分較大文件轉移到服務器上存儲來避開上述局限性.

4 問題描述

本文旨在設計一個基于區塊鏈的公鑰可搜索加密系統, 此系統具有關鍵字隱私性、公平性和可靠性,可以避免不可信云服務器帶來的安全問題, 提高加密數據的安全性.

4.1 系統模型

系統模型如圖3 所示, 主要的組成部分有: 數據擁有者, 智能合約, 用戶和服務器.

圖3 系統模型Figure 3 System model

?數據擁有者(Data Owner, DO). 數據擁有者上傳搜索密文與編號至智能合約, 上傳數據密文至服務器. 接收自身數據被檢索帶來的收益.

?智能合約(Smart Contract, SC). 智能合約通過交易存儲數據擁有者上傳的搜索密文和編號.根據用戶的關鍵詞陷門檢索相應的密文, 并驗證密文的完整性與正確性, 并通過交易將檢索結果下發給用戶. 管理檢索過程中的費用的分配與發放.

?服務器(Server, S). 服務器接收數據擁有者存儲的數據密文與編號, 接收以太坊智能合約下發的密文編號, 檢索相應的密文, 并將結果上傳至智能合約等待驗證.

?用戶(User, U). 用戶設置搜索口令, 并將傭金上傳至智能合約中. 接收來自智能合約的驗證過的檢索結果.

在一次完整的存儲與檢索流程中, 首先數據擁有者先把搜索密文與搜索密文編號上傳至智能合約, 同時將數據密文與編號上傳至服務器中. 擁有權限的用戶就可以檢索到此文件, 用戶檢索文件時設置搜索口令, 并將傭金上傳至智能合約中. 智能合約根據搜索口令在搜索密文中進行檢索, 檢索到之后使用編號向服務器請求密文, 然后驗證服務器返回的密文的完整性, 根據驗證結果來分發傭金.

4.2 設計目標

關鍵字隱私性.服務器在僅提供密文的情況下不能知道任何明文相關的內容. 在數據擁有者未授權的情況下, 其他用戶不能查詢到此數據擁有者的數據; 數據檢索方除了查詢結果之外不能得知檢索關鍵詞的相關信息. 本方案基于PEKS 密文檢索方案保障關鍵字的隱私性. 用戶提供關鍵字陷門, 數據檢索方可通過陷門檢索出對應的密文, 此時盡管檢索方正確地檢索出了相應的結果, 但是對關鍵詞相關信息一無所知.

公平性.公平性是本文在密文檢索中引入的重要性質. 本文公平性保障靈感主要來源于現實世界中的交易財政政策. 我們的公平性主要保證以下兩點: 數據擁有者只要付費給檢索方就可以取得自己正確的檢索結果, 檢索方只要誠實地檢索數據并且返回正確的結果就可以掙得報酬. 當數據需要共享時, 用戶只要付費給檢索方和數據擁有者, 就可以取得自己正確的檢索結果, 數據擁有者如果想要共享自己的數據來獲取報酬的話, 只要公開令牌即可. 總的來說, 我們的公平性政策保證了各方能夠被激勵從而去做誠實并且正確的工作, 如果某方違背了協議, 他將得不到報酬.

可靠性.本文可靠性保障主要來源于區塊鏈的不可篡改機制. 篡改存儲在區塊鏈上的數據, 需要篡改此數據位置之后所有區塊的哈希和相關記錄, 理論上若要篡改數據需要控制51% 的節點, 此操作難度極高, 所以區塊鏈擁有不可篡改性. 密文保存在區塊鏈中使得其不能被篡改, 也就保障了數據是正確的和可靠的.

4.3 安全定義

本小節采用安全游戲的方式, 定義了基于區塊鏈PEKS 系統的安全模型.

(1) 關鍵字隱私性

關鍵字隱私性主要考慮抵抗選擇關鍵字攻擊的語義安全(semantic security against chosen keyword attack), 即敵手不會從密文中獲得關鍵字的任何信息. 若系統擁有關鍵字隱私性, 那么敵手A不會從密文中獲得關鍵字的任何信息. 其可以通過挑戰者C與敵手A之間的安全游戲進行定義. 在這個安全游戲中,A不是授權用戶, 所以A無法獲得某個密文的關鍵字. 在這個安全游戲中, 現允許A進行CKA, 并嘗試區分一個可檢索密文對應的關鍵字W0和W1. 敵手A與挑戰者C的安全游戲定義如下.

初始化階段: 挑戰者C運行KeyGen(s), 生成公鑰pk 和私鑰sk, 挑戰者C將公鑰pk 發送給敵手A.

詢問階段1: 敵手A向C詢問一系列關鍵字Wi ∈{0,1}i的陷門, 挑戰者C運行Trapdoor(sk,W)生成關鍵字陷門, 并將陷門告訴敵手A. 然后敵手A向挑戰者C詢問一系列與Wi對應的搜索密文, 挑戰者C執行PEKS(pk,W) 生成關鍵字密文, 并將其發送給攻擊者A.

挑戰階段: 敵手A隨機選取兩個不同的關鍵字W0、W1發送給挑戰者C,W0、W1要求是不能在詢問階段1 詢問過的關鍵字. 挑戰者隨機選取一個b ∈{0,1}生成挑戰密文C=PEKS(pk,Wb), 并將改挑戰密文發送給敵手A.

詢問階段2: 與詢問階段1 方式類似, 敵手A繼續向挑戰者C請求關鍵字陷門, 但是不允許詢問關鍵字W0、W1的陷門信息.

猜測階段: 敵手輸出一個b′∈{0,1}, 如果b=b′, 那么敵手A在安全游戲中獲勝, 否則失敗. 我們將敵手A贏得上述安全游戲的優勢定義為如下形式:

定義1基于區塊鏈的公鑰可搜索加密系統具有關鍵字隱私性, 如果對于任意概率多項式時間(Probabilistic Polynomial Time, PPT) 的敵手A, 其贏得上述安全游戲的優勢?是可忽略的, 即AdvCKAA

(2) 公平性

我們采用基于模擬的安全來定義系統的公平性. 系統的公平性分析是通過比較現實世界與理想世界中的交易執行情況來定義的. 在現實世界中, 用戶U通過我們系統中的智能合約來獲得服務, 而在理想世界中, 用戶通過一個理想的受信任的第三方來保證服務的準確性. 無論是現實世界還是理想世界, 都有一個特殊的環境Z, 它的作用是協調各個參與方的輸入與輸出.

?在理想世界中, 我們設置一個理想的受信任的第三方L.U可以被L所驗證, 也就是說L可以驗證出不誠實的參與者來保障整個交易的公平性. 我們將理想世界中交易輸出定義為IdealU,S(T,f,v(iu)), 其中T是由U發起的交易,f是服務費,v(iu) 是驗證函數, 其中iu 是U提供的輸入.

?在真實世界中,U可以被智能合約所驗證. 交互的公平性被我們系統中的一系列機制所保障. 我們將真實世界中交易的輸出定義為RealU,S(T,f,v(iu,is)).U執行sendRawTransaction() 來發起交易, 如果U發起交易失敗, 則交易被系統終止, 費用被返回給U. 如果U是一個誠實的用戶, 那么Verify() 將輸出“True”, 整個交易結束; 否則Verify() 輸出“False”, 同時,U的費用被退回.

我們假定不誠實的用戶U′的目的是為了從服務方獲得免費的服務, 而不是惡意地消耗服務方的計算能力.

定義2基于區塊鏈的公鑰可搜索加密系統是公平的, 如果任意現實世界中的不誠實的用戶U?運行了時間t, 在理想世界中都存在一個用戶U?′運行了時間t′, 它們在任意的交易T, 驗證函數v(iu) 和服務費f, 在所有PPT 環境Z中都有:

5 基于區塊鏈的公鑰可搜索加密系統設計

為了讓智能合約與PEKS 密文檢索方案更好地交互, 本方案采用分層的形式構造了一個基于區塊鏈的公鑰可搜索加密系統. 在本方案的分層構造中, 不同層具有不同的功能與角色, 每層之間通過約定好的接口交互以保障整個系統穩定地運行, 從而實現一個安全可靠的設計方案.

5.1 系統概述

系統整體設計如圖4 所描述, 主要分為四層: 客戶端、檢索層、智能合約層和服務器.

圖4 基于區塊鏈的公鑰可搜索加密系統設計圖Figure 4 Blockchain-based public key encryption with keyword search system scheme

?客戶端(Client, C): 當數據擁有者存儲明文時, 客戶端接收數據擁有者的明文并傳入檢索層. 當用戶想要檢索明文時, 客戶端接收用戶的關鍵字與傭金并傳入檢索層. 接收來自檢索層傳入的明文, 將結果下發給用戶. 總的來說客戶端的作用是提供一個與用戶交互的平臺.

?檢索層(Retrieval, R): 接收客戶端傳入的明文并執行加密, 將數據密文與編號傳入服務器, 將搜索密文與編號傳入智能合約層, 將編號集合存為索引存儲在本層. 接收客戶端傳入的傭金與關鍵字, 生成搜索口令并把傭金傳入智能合約層. 接收來自智能合約層的搜索密文, 并用搜索口令檢索,將檢索結果傳入智能合約層. 接收來自智能合約層的數據密文, 解密并將明文傳入客戶端. 總的來說檢索層執行與密文檢索相關的算法.

?智能合約層(Smart content, SC): 存儲來自檢索層傳入的搜索密文與編號. 接收來自檢索層的傭金, 并作為押金暫時存放在智能合約, 再將搜索密文傳入檢索層. 接收來自檢索層的檢索結果,并且將對應的編號傳入服務器. 接收來自服務器的數據密文并且驗證此數據密文是否正確, 若正確則將傭金付給數據擁有者, 并將數據密文傳給檢索層. 總的來說智能合約層執行傭金的管理與發方.

?服務器層(Sever, S): 接收來自檢索層傳入的數據密文和編號并存儲. 接收來自智能合約的編號,并返回相應的數據密文傳入給智能合約層. 總的來說, 服務器負責存儲密文并誠實地返回密文.

5.2 方案構造

基于區塊鏈的公鑰可搜索加密方案包含以下7 個階段, 該方案基于PEKS[2]的構造來實現搜索口令的生成和密文檢索, 結合智能合約技術來處理各個賬戶之間的交易以保障方案的安全性和可靠性.

(1) 初始化階段

KeyGen(s)→(pk,sk), 系統初始化. 選擇一個安全參數s作為輸入, 隨機選取α ∈Z?p以及群G1和生成元g, 輸出公鑰pk 和私鑰sk 如下

智能合約初始化, 數據擁有者注冊得到賬戶$Bowner并設置檢索單價$offer, 用戶注冊得到賬戶$Buser, 用戶需向$Buser中存款, 智能合約設置押金賬戶$deposit. 智能合約交易相關的賬戶如表2 所示.

表2 交易涉及的各個賬戶及其含義Table 2 Accounts involved in the transaction

(2) 密文生成階段

Enc(m,W,pk)→(Cm,PEKS(pk,W)). 該算法由檢索層進行計算, 輸入為明文m、關鍵字W和公鑰pk, 輸出為數據密文Cm和搜索密文PEKS(pk,W). 計算密文, 明文m通過RSA 非對稱加密算法得到數據密文Cm. 計算搜索密文, 隨機選取r ∈Z?p, 首先計算t=e(H1(W),hr)∈G2, 得到搜索密文, 記為

數據擁有者將Cm與PEKS(pk,W) 進行編號, 得到對應的編號N. 將數據密文Cm與編號N進行哈希得到Hm. 將N添加至檢索層的檢索索引I中, 將數據密文Cm與編號N上傳至服務器進行存儲, 將PEKS(pk,W)、N與Hm上傳至智能合約等待查詢.

(3) 搜索口令生成階段

Trapdoor(sk,W′)→TW′. 該算法由檢索層進行計算, 把私鑰sk 與用戶想要檢索的關鍵字W′作為輸入, 輸出搜索口令如下

用戶將搜索口令上傳至檢索層,并用自身賬戶$Buser向智能合約的賬戶$deposit 存款$Buser→$deposit.

(4) 交易發布階段

sendRawTransaction($Buser,I)→txHash. 該算法由智能合約進行計算, $Buser為用戶的賬戶,I為檢索索引, 包含了所有搜索密文PEKS(pk,W) 對應的編號, 作為此交易的參數傳入.

首先檢查$Buser是否合法. 然后智能合約估算此次交易需要的費用$cost←$offer +Glimit×$gasprice, 并檢查押金賬戶$deposit 中用戶預存的押金是否滿足依次此次交易所需費用$cost, 若滿足則繼續發布交易, 過程如下.

首先使用$Buser對應的公鑰與secp256k1 橢圓曲線對傳入的參數I簽名. 然后使用RLP(Recursive Length Prefix), 遞歸長度前綴編碼對簽名數據進行編碼. 將此交易的指針指向其前一個區塊, 驗證該交易并將其廣播到P2P 網絡中. 最后的產生txHash 為交易ID. 若交易發布成功, 則將I中對應的搜索密文PEKS(pk,W) 集合上傳至檢索層.

若用戶預存的押金$deposit 不滿足此次交易所需費用$cost, 則終止交易, 并將$deposit 中預存的押金返回給用戶的賬戶$Buser.

(5) 檢索階段

Search(TW′,I)→N. 該算法由檢索層進行計算,I為檢索索引,TW′為搜索口令. 首先對于I, 向智能合約請求對應的搜索密文PEKS(pk,W) 集合.

對于每個PEKS(pk,W), 執行Test(pk,CW,TW′), 其中CW= [A,B] = PEKS(pk,W). 判斷H2(e(TW′,A))=B是否成立, 若成立輸出1, 否則輸出0.

若Test(pk,CW,TW′) 輸出為1, 則表明檢索成功, 將對應的N下發給智能合約.

若不存在能使Test(pk,CW,TW′) 為1 的PEKS(pk,W), 則表明數據擁有者存儲的密文未包含用戶想要檢索的文檔. 此時將N置為?1, 并下發給智能合約.

(6) 驗證階段

Verify(Cm,N)→0|1. 該算法由智能合約進行計算. 當智能合約接收到來自檢索層的編號N時, 智能合約首先判斷N是否為?1, 若為?1, 則直接輸出0. 若N不為?1, 智能合約將N告訴服務器, 服務器中存儲了N與密文Cm的對應關系, 此時服務器可以直接返回對應的Cm.

此時智能合約需要驗證服務器是否返回了錯誤的密文或者數據是否被惡意破壞和篡改. 首先智能合約通過N得到存在本層的對應的Hm, 然后將Cm與N進行哈希運算得到Hm′, 若Hm′=Hm, 表明驗證成功, 輸出1, 否則輸出0.

(7) 賬戶更新階段

該流程由智能合約執行. 若Verify(Cm,N) 為1, 則計算$cost←$offer+G×$gasprice, 將$cost轉入至數據擁有者的賬戶$Bowner中, 此時$deposit←$deposit?$cost, 將$deposit 退回到用戶的賬戶$Buser中. 并將數據密文Cm傳入檢索層, 由檢索層解密后將明文m傳入客戶端.

若Verify(Cm,N) 為0, 則直接將$deposit 退回到用戶的賬戶$Buser中.

5.3 安全性分析

定理1如果底層的基于雙線性對的加密機制在PPT 時間內不能被攻破, 那么基于區塊鏈的公鑰可搜索加密系統在隨機預言機模型下具有關鍵字隱私性.

證明:在CKA 中, 現假設存在一個PPT 的敵手A, 它能以優勢?成功地攻破系統. 再構造一個模擬器B, 將系統的公鑰pk 告訴B.

初始化階段:B運行KeyGen() 獲得公鑰pk 與私鑰sk, 將公鑰pk 發送給敵手A.

?H-詢問階段:B得到一個初始為空的哈希列表L(wi,hi). 每當收到一個對應于wi的 ?H-詢問并通過訪問簽名預言機獲得一個δ(wi), 如果δ(wi) 已經在列表L中,B就返回對應的hi來作為敵手A的預處理關鍵字, 否則B將hi設置成如下形式.

然后B將(δ(wi),hi) 添加到L中, 并將ai返回給A.

詢問階段1:A發起一系列的詢問. 如果A詢問的是一個關鍵字wi對應的關鍵字密文或者陷門,B通過訪問簽名預言機獲得一個預處理的關鍵字hi, 然后B通過使用密鑰對(pk,sk) 得到關鍵字密文Cwi或者陷門Twi, 并將其發送給A.

挑戰階段: 一旦接收到來自A的挑戰關鍵字w0和w1,B隨機選取一個b ∈{0,1}, 并生成wb的關鍵字密文Cwb, 并將其返回給A.

詢問階段2:A繼續向B詢問關鍵字的密文或者陷門,B的響應行為類似于詢問階段1. 限制條件是A不能詢問有關w0或w1的信息.

猜測階段:A輸出一個猜測值b′∈{0,1}.

定理2如果區塊鏈不能在PPT 時間內攻破, 那么基于區塊鏈的公鑰可搜索加密系統是具有公平性的.

證明:我們考慮了在系統中存在不誠實用戶的情形. 對于在現實世界中的每一個不誠實的用戶 ?U,在理想世界中都存在著一個不誠實的用戶U, 它們兩個的輸出在計算上是不可區分的. 我們假定?U被給定了一個合法的區塊鏈賬戶, 但是它只想要通過不誠實的手段獲得免費的服務.U在理想世界中執行如下所示的算法1.

算法1 理想世界中交易的詳細流程理想世界中, 服務提供方S 與用戶U 和信任的第三方L 之間的交互流程.sendRawTransaction()? U 發起一個交易T, 交易金額是d, 由可信任第三方L 執行v(iu).? L 檢查T, 如果其是一個有效的交易, 受信任的第三方L 將T 執行, 如果T 是個無效的交易, 那么L 將會終止T,并且輸出False.Search()? 系統執行來自L 的交易T.? 服務執行完畢, 創建交易T′ 并將其回執給L.Verify()? L 使用驗證函數v(iu), 如果通過, L 接受交易T′, 否則L 拒絕交易T′.? 如果L 接受了交易T′, U 則從L 接收交易T′, U 獲得相應的服務, 并且輸出“True”.? 如果L 拒接了交易T′, U 將獲得其被退回的費用, L 終止整個交易, 并輸出“False”.

我們通過構造兩種混合的游戲可以得出模擬器和現實世界的輸出在計算上非常接近.

游戲H0由理想世界模擬器執行.

游戲H1為混合游戲, 其中沒有受信任的第三方, 而是讓U與區塊鏈系統進行交互.

我們將證明H0和H1在計算上是不可區分的. 因為工作證明算法在區塊鏈系統中穩定運行, 區塊鏈系統在交易中被視為是誠實的, 并且在區塊鏈系統中運行的所有交易都不能被篡改, 所以H0和H1是計算上不可區分的. 因此現實世界系統的輸出和理想世界中系統的輸出是計算上不可區分的, 并且不誠實的用戶?U不可能成功地偽造一個有效的交易. 因此, 系統的公平性得以保障.

定理3如果以太坊環境的安全性得到保障, 那么我們的方案是可靠的.

證明:假設以太坊環境是安全的, 那么交易發布之后, 交易相關信息會被記錄在區塊鏈中, 通過共識機制所有區塊鏈節點都能與相同的區塊鏈進行交互, 而惡意參與者無法控制以太坊區塊鏈上超過51% 的節點, 所以交易一旦發布就不能被篡改. 如果智能合約能夠在以太坊環境中得到正確執行, 那么檢索結果將會以區塊的形式存儲在區塊鏈中. 區塊鏈上的區塊是公開的且是不可篡改的, 所有以太坊節點都可以驗證該數據. 以太坊各個節點的一致性保證了在檢索過程中每個步驟執行的正確性和可靠性. 可靠性的另一方面由公平性支撐, 通過智能合約我們能保障交易各方能夠得到應得的激勵, 交易各方都承認檢索結果的公平性, 那么本方案的可靠性也得到了保障. 由于可靠性主要由以太坊環境和智能合約來實現, 其證明無法采用定理1 和定理2 的規約范式. 受文獻[31] 的啟發, 本文也采用了類似于文獻[31] 的方式來分析基于區塊鏈PEKS 系統的可靠性.

6 原型系統實現與性能評估

根據5.1 節系統設計的4 層架構, 我們使用了5000 多行代碼來實現系統的原型. 本方案原型基于以太坊平臺搭建, 使用的操作系統為Ubuntu 18.04. 客戶端使用了Django 框架與html5、Javascript 技術來保證其與后端的交互, 檢索層采用Python 3.0 編寫以實現加解密與搜索口令的生成, 主要使用pypbc庫、hashlib 庫和rsa 庫來實現PEKS 方案, 智能合約使用了Solidity 語言編寫, 為了實驗結果的準確并減少其它因素的干擾, 智能合約部署在以太坊私鏈中.

6.1 原型系統實現細節

對于PEKS 算法實現, 本方案采取一個固定的參數, 使雙線性映射固定下來, 便于后續操作能夠在同一參數的基礎上運行. 表3 為使用到的密碼學參數說明. 在密鑰生成函數KeyGen() 中, 輸入安全參數qbits 和rbits. 本方案選取的值為qbits = 512, rbits = 160, 這樣就將群G1和G2以及返回的params固定下來. 在實例化雙線性對對象時, 直接利用pypbc 庫中的Pairing() 函數, 將params 參數輸入, 生成雙線性對對象pairing. 同時, 對于群G1生成元的選取, 也直接調用pypbc 庫中的Element.random() 函數, 輸入之前生成的雙線性對對象pairing 以及群G2, 隨機生成. 本方案的哈希函數H1和H2直接引用hashlib 的庫hashlib.sha256 生成.

表3 PEKS 使用到的密碼學參數說明Table 3 Cryptography parameter description for PEKS

對于RSA 的實現, 本方案使用到了Python 中的rsa 庫. 對明文進行加密, 對密文進行解密. 對于密鑰對的生成, 調用函數rsa.newkeys(512) 隨機生成, 其中參數選擇512, 表示用來加密的數據長度為512 bits. 生成之后將文件以pem 格式保存下來. 對明文用RSA 加密函數之前先將明文進行utf-8 編碼. 對應的, 解密之后用utf-8 解碼.

對于智能合約的實現, 本方案的主要環境為以太坊. 本方案中的智能合約主要用來驗證檢索結果與費用分發. 對于搜索密文與編號的存儲, 智能合約主要采用了映射(mapping) 的數據結構, 把編號存為映射的鍵(key), 搜索密文存為映射的值(value). 同樣地, 智能合約通過mapping 將數據密文的哈希進行存儲, mapping 的key 位編號, value 為對應的數據密文哈希值. 當智能合約收到來自服務器返回的數據密文時, 智能合約首先在自己存儲的mapping 中找到對應的哈希值, 再將數據密文計算得出一個新的哈希,對比兩個哈希即可驗證服務器返回的結果是否正確. 通過調用各個參與方的轉賬函數即可實現費用的發放與收取.

6.2 性能測試與分析

本節分別在私鏈和公鏈環境中對系統的性能作出測試, 將從實驗部署、仿真過程和數據結果三個方面分別進行介紹.

6.2.1 實驗部署

本小節主要介紹私鏈以及公鏈上智能合約的部署.

(1) 私鏈上的部署

首先, 在以太坊環境中搭建了一條私鏈作為智能合約的運行環境, 此條私鏈的chainId 為528, 創世區塊的timestamp 為0x5ddf8f3e, difficulty 為0x002, 私鏈的端口為3333, rpc 端口為4444. 接著我們在此私鏈中部署了我們的智能合約, 部署后得到智能合約的地址為0xc4ca68caa8ecc4a46b475161e3161eb228b 0e01a. 關鍵參數如表4 所示.

表4 智能合約部署關鍵參數表Table 4 Smart contract deployment key parameter table

(2) 公鏈上的部署

實驗選擇了以太坊官方提供的公有測試鏈Ropsten 來進行智能合約的部署. 我們使用infura 作為代理節點, 使用remix 加metamask 進行了部署. 部署好后, 用戶地址和合約地址如下所示.

? 0x87E08e9E27D6c1645b773A37Ac4BD09773B3dd94

? 0x03fc28689d09d461d3b60dd75463ad457d5a67b5

6.2.2 仿真過程

實驗在具有4 個Intel i7-7500 內核的PC 上執行, 操作系統為Ubuntu 18.04, 內存為5.8 G. 在私鏈上的實驗過程中, 啟動服務器, 保持合約啟動狀態并持續地進行挖礦; 在公鏈上只需要啟動服務器, 保持infura 賬號登錄狀態. 然后分別使用Apache Bench 進行壓力測試. 主要測試點為本方案中存儲明文與密文檢索兩個關鍵功能模塊的功能完整性、可用性及性能. 在對每個功能模塊的測試實驗中, 將請求總數固定為600, 并固定傳輸數據長度, 改變系統面對的并發請求數量, 對用戶平均等待時間、服務器平均請求處理時間等指標進行統計與分析, 從而驗證本文方案的可行性. 實驗中涉及的參數如表5 所示.

表5 實驗相關參數Table 5 Experiment related parameters

公私鏈上實驗參數設置完全相同, 對應情況下的每次實驗都分為兩大組進行, 每組根據VU 的不同又分為15 組參數, 每組參數重復測試3 次取平均值, 總共進行了90 次測試. 在對消息發送模塊進行測試時,保持請求總數為600, 消息長度為4640 bytes, 改變VU 數量使其在10 到600 的范圍內遞增, 記錄每組數據下用戶平均等待時間、服務器平均請求處理時間、TPS 以及DTR 的值. 同樣地, 在對密文檢索模塊進行測試時, 保持請求總數為600, 消息長度為3247 bytes, 改變改變VU 數量使其在10 到600 的范圍內遞增, 并記錄上述性能參數數值.

6.2.3 實驗結果分析

(1) 私鏈實驗結果分析

圖5 和圖6 顯示了在其他條件不變的情況下, VU 數量從10 增加到600 時, 消息發送模塊用戶平均請求等待時間、服務器平均請求處理時間以及RPS 和DTR 的變化情況.

經測試, 整個實驗過程模擬用戶失敗的請求個數都是0, 也就是說, 正常情況下, 服務器對用戶請求的響應能力維持著較高的水平. 各個功能也能完整而穩定地運行.

圖5、圖6 可以直觀地展示出用戶等待時間與系統響應時間同時與DTR 有關. DTR 越高, TPS 越大, 用戶的請求等待時間越短. 另一方面, 當VU 在10 到600 范圍內變化時, 信息發送模塊用戶請求等待時間和服務器請求處理時間也隨VU 線性地增加, 相應的TPS 逐漸下降. 可以推測, 在并發數600 之內, 系統可以正常且完整地完成信息發送, 但是并發數增大時, 系統的響應時間會有一定延長.

圖5 私鏈信息發送模塊用戶等待和服務器處理時間Figure 5 Variation of user’s waiting time and server’s processing time with VU in information sending module on private chain

圖6 私鏈信息發送模塊TPS 和DTRFigure 6 Variation of TPS and DTR with VU in information sending module on private chain

圖7 和圖8 是當其他條件不變、VU 在10 到600 范圍內變化的情況下, 密文檢索模塊各性能參數的變化情況.

圖7 私鏈密文檢索模塊用戶等待和服務器處理時間Figure 7 Variation of user’s waiting time and server’s processing time with VU in ciphertext retrieval module on private chain

圖8 私鏈密文檢索模塊TPS 和DTRFigure 8 Variation of TPS and DTR with VU in ciphertext retrieval module on private chain

密文檢索模塊各參數隨VU 的變化與信息發送模塊的變化趨勢大同小異, 從圖7 和圖8 中可以看到,用戶的請求等待時間依然與DTR 呈負相關, 而TPS 與DTR 呈正相關. 當其他條件不變、VU 在10 到600 之內增加時, 用戶平均等待時間和服務器請求處理時間都隨之延長, 而DTR 隨之下降, TPS 也降低.需要說明的是, 服務器響應時間與用戶等待時間在很大程度上依賴于網絡上的數據傳輸速率, 因此在不同時刻、不同網段中使用同一套參數重復驗證時, 盡管數據由于網速的變化而大不相同, 但是各參數之間的依賴關系和變化趨勢依然不會改變.

(3) 公鏈實驗結果分析

在公鏈上, 控制其他條件不變并讓VU 從10 到600 變化, 分別對發送模塊和檢索模塊進行測試. 可以得到用戶平均請求等待時間、服務器平均請求處理時間以及RPS 和DTR 的變化情況. 其中, 圖9 和圖10 表示的是發送模塊的數據折線圖, 圖11 和圖12 記錄的則是檢索模塊的數據折線圖.

圖9 公鏈信息發送模塊用戶等待和服務器處理時間Figure 9 Variation of user’s waiting time and server’s processing time with VU in information sending module on public chain

圖10 公鏈信息發送模塊TPS 和DTRFigure 10 Variation of TPS and DTR with VU in information sending module on public chain

圖11 公鏈密文檢索模塊用戶等待和服務器處理時間Figure 11 Variation of user’s waiting time and server’s processing time with VU in ciphertext retrieval module on public chain

圖12 公鏈密文檢索模塊TPS 和DTRFigure 12 Variation of TPS and DTR with VU in ciphertext retrieval module on public chain

從圖中可以看到, 各指標隨并發數的變化趨勢并沒有受公私鏈改變的影響, 用戶等待時間與服務器響應時間也維持在相同的量級. 由此可以看出, 本文方案在公鏈上推行有一定的可行性.

在網絡狀況良好的情況下, 系統能夠穩定地完成數據的傳輸、加密和檢索, 但是隨著并發數增大, 系統依然面臨性能上的挑戰, 不過這依然無法掩蓋基于區塊鏈的密文檢索方案在大數據時代諸多領域的廣闊應用前景和無限的可能性.

6.3 實際應用場景

通過以上的測試可以得出, 系統在網絡狀況良好的情況下能夠穩定地完成數據的傳輸、加密和檢索.并且系統使用區塊鏈來管理第三方服務器, 具有公平性和可靠性, 同時本身的PEKS 方案具有關鍵字隱私性, 在網絡安全形勢愈發嚴峻的今天是非常值得推廣的.

但是, 由于區塊鏈是所有節點可驗證并且需要礦工挖礦來上傳數據的, 所以系統的存儲成本似乎看起來比較昂貴, 但是該系統仍然可以應用到許多的真實場景中. 例如, 個人的醫療檔案是非常重要的, 現實生活中醫生只有獲取到了病人的真實健康狀況才能夠做出正確的判斷; 個人學歷檔案或者是犯罪檔案也是不可被隨意篡改的, 并且需要很高的隱私性. 在這些場景中, 由于對數據的安全可靠要求異常苛刻, 所以為了檢索高可靠的密文, 高花費是值得的.

如圖13 所展示的, 基于區塊鏈的公鑰可搜索加密系統在個人學歷檔案場景中的應用.

圖13 系統在個人學歷檔案場景中的應用Figure 13 Application in personal education record system

系統中存儲公民的個人學歷, 個人學歷信息只有具有權限的校方才能夠修改, 并且修改頻率有一定的限制, 例如高中學歷校方每三年才能修改一次, 大學學歷校方每四年修改一次. 而在這種場景中每個人無法修改自己的學歷, 他們只能查看自己的學歷, 或者截圖以向外證明自己的學歷. 所以在個人學歷檔案場景中, 政府為每個公民憑借身份證號創建一個唯一的檔案賬戶, 檔案賬戶的私鑰分發給權威的校方機構,校方憑借私鑰可以修改公民的學歷檔案, 由于區塊鏈的不可篡改性, 除了有私鑰的校方可以修改檔案, 檔案不會被任何其他方篡改; 檔案賬戶的公鑰分發給公民本人, 公民使用此公鑰可以查看自己的學歷檔案,但不能作任何的修改.

7 結束語

為了解決目前PEKS 方案針對惡意服務器的搜索可靠性問題, 本文在PEKS 方案的基礎上, 結合區塊鏈技術, 提出了一個基于區塊鏈的公鑰加密可搜索系統. 具體而言, 采用分層的思想, 利用智能合約構造了一個四層級化的基于區塊鏈公鑰可搜索加密方案, 并對其進行了安全性分析, 證明了所提出的方案可以有效抵抗惡意服務器帶來的不良影響, 從而保障系統的關鍵字隱私性、公平性和可靠性. 基于上述方案,本文實現了基于區塊鏈公鑰加密可搜索的原型系統, 并對原型系統進行了性能測試與分析, 證明了本文構造的可行性與實用性.