基于區(qū)塊鏈的身份信息共享認證方案*

黑一鳴, 劉建偉, 管曄瑋

北京航空航天大學 網(wǎng)絡空間安全學院, 北京100191

1 引言

在當今時代, 各行業(yè)機構為方便用戶管理和服務都需要獲取并認證用戶的身份信息. 目前大多數(shù)認證方案都是為了保障認證的效率和準確率[1,2], 而忽視了身份信息的隱私性和安全性. 從用戶隱私角度來看,用戶并不清楚身份信息獲取者的實際需求, 一旦信息獲取者超越其訪問權限, 非法獲取用戶額外的身份信息, 則用戶個人隱私難以受到保護. 從便捷性角度來看, 用戶每到一個新場景下都要重新注冊并認證身份信息, 這導致用戶很多冗余操作, 且工作效率不高. 從數(shù)據(jù)安全角度來看, 用戶身份數(shù)據(jù)是是分布在各機構服務器上的, 由于他們的存儲安全性參差不齊, 一旦出現(xiàn)信息泄漏或個別服務器故障, 后果非常嚴重.

綜合來看, 可控權限的安全身份信息共享認證問題亟待解決.

2005 年, Sahai 和Waters 為了解決上述的身份信息隱私性和安全性的問題, 在身份基加密方案[3]的基礎上提出了屬性基加密方案[4]. 該方案較好地解決了用戶隱私信息保護問題, 并且可以實現(xiàn)細粒度的訪問控制.

2008 年, 中本聰提出比特幣網(wǎng)絡[5], 區(qū)塊鏈技術正式進入人們視野, 區(qū)塊鏈中比較有代表性的技術是智能合約技術[6]. 智能合約是一種允許在沒有第三方參與的情況下, 以代碼方式形成、驗證或執(zhí)行合同的計算機協(xié)議[7]. 其透明化和程序化的特點適合于完成數(shù)據(jù)存儲、數(shù)據(jù)訪問和數(shù)據(jù)更新操作. 目前最主流的智能合約系統(tǒng)是以太坊[8].

1.1 本文貢獻

第一, 本方案基于屬性基加密技術, 由可信注冊機構設置各行業(yè)機構的身份信息訪問權限, 防止用戶不必要的隱私暴露.

第二, 本文使用區(qū)塊鏈的智能合約技術實現(xiàn)身份信息共享和更新, 避免了身份信息多次重復注冊填寫,方便了信息共享及身份認證工作.

第三, 本方案使得身份信息注冊標準化, 基于區(qū)塊鏈的分布式存儲結構, 相對普通中心化存儲服務器模型的魯棒性更高.

第四, 本方案在自行搭建的以太坊私鏈上進行了性能測試工作, 實驗結果表明了本方案具有可行性.

1.2 相關研究工作

1997 年, Szabo[6]提出了智能合約的概念, 他指出計算機代碼可以替代機械設備進行復雜交易的處理, 但當時缺乏可信的運行環(huán)境, 并沒有得到重視. 直到區(qū)塊鏈技術的流行才推動了它的發(fā)展. 目前智能合約技術已經應用到了很多方面, 其中包括商品拍賣交易[9]、共享經濟[10]和商品交易[11]等. 盡管如此,智能合約仍處于較為初級的階段, 存在著很多問題. 首先, 智能合約的開發(fā)需要一定的編程能力, 沒有相關學習背景的用戶難以參與合約編寫和審計. 另外, 智能合約還存在異常處理脆弱[11]、數(shù)據(jù)來源不可靠[12]、隱私易泄露[9,13]等安全隱患. 針對智能合約開發(fā)壁壘問題, 現(xiàn)有比較好的解決方案有半自動合約開發(fā)[14]和形式化驗證. 針對智能合約的安全性問題, 可使用OYENTE[12]和Hawk[9]工具進行檢測.

2001 年, Boneh[15]提出了身份基加密(Identity-based Encryption, IBE). Nico D?ttling 和Sanjam Garg[14]于2017 年提出了變色龍加密方案, 利用變色龍哈希函數(shù)壓縮公鑰, 提高了IBE 的效率. 該類加密方案以用戶身份作為公鑰, 其存在用戶隱私暴露等安全問題. Sahai 和Waters 為解決IBE 存在的問題, 提出了屬性基加密[4]的方案. 在該方案中, 用戶不需要公開自己所有的身份信息, 確保了用戶信息的隱私性和安全性. 另外, 解密者需要滿足屬性條件才能正確解密, 確保了數(shù)據(jù)的保密性. 2006 年, Goyal等人[16]提出了密鑰策略屬性基加密方案(KP-ABE). 將用戶的密鑰與系統(tǒng)的訪問控制策略相聯(lián)系, 密文與用戶的屬性集相聯(lián)系. 2016 年, Wang[17]等人對KP-ABE 中的密鑰生成過程和解密過程進行了優(yōu)化, 用訪問受限樹來描述訪問策略, 給出了一種密鑰生成效率高, 解密成本低的KP-ABE 方案. 但該類方案中, 用戶對數(shù)據(jù)的訪問控制能力較弱. 2007 年, Bethencourt 等人[18]提出密文策略屬性基加密方案(CP-ABE). 與KP-ABE 相反, 該方案將密文與系統(tǒng)的訪問控制策略相聯(lián)系, 密鑰與用戶的屬性集相聯(lián)系.后來Goyal 等人[19]給出了CP-ABE 的安全性證明并改進了該方案, 使其支持更高級的訪問結構. Liang等人[20]改進了Goyal 等人的方案, 給出了更快的加解密算法且其生成的密文長度更短. 然而, 這些方案的密文長度均取決于屬性集的大小. Zhou 和Huang[21]提出的方案不僅能獲得固定長度的密文, 訪問結構也不會呈指數(shù)增加. 上述的方案中, 密文總是和顯式的訪問結構綁定發(fā)送, 這樣會泄露訪問控制結構中的敏感信息. 2012 年, Lai[22]提出了一種能夠部分隱藏訪問結構的CP-ABE 方案, 并在完全安全模型下證明了該方案的安全性. 2013 年, Hur[23]對此提出了新的方案, 該方案對訪問策略進行盲化處理, 保護了訪問策略, 該方案在通用群模型下被證明是安全的. 2017 年, Qiu 等人[24]針對基于屬性的可檢索加密方案, 提出了訪問策略保護方案, 使用非對稱雙線性映射實現(xiàn)了訪問策略的隱藏, 能夠抵抗關鍵字猜測攻擊. 隨著訪問策略控制算法的逐漸成熟, 密鑰濫用成為一個新的亟待解決的問題. 密鑰濫用包括非法密鑰共享和密鑰濫發(fā)兩種情況. 其中非法密鑰分享指的是用戶故意泄露自己的屬性密鑰信息; 非法密鑰分發(fā)指的是屬性中心濫發(fā)屬性密鑰. 在當前的ABE 方案中, 屬性中心分配給用戶的私鑰往往僅和用戶屬性有關, 而不包含用戶的獨有特征信息, 導致密鑰濫用現(xiàn)象相當普遍, 這對ABE 方案的安全性和可靠性造成了嚴重的威脅. Zhang 等人[25]給出了一個能實現(xiàn)黑盒追溯的CP-ABE 方案, 該方案不僅支持靈活且細粒度的用戶屬性撤銷操作且能快速追溯泄露屬性密鑰的惡意用戶. 2017 年, Yu 等人[26]介紹了一種可問責CP-ABE 方案. 該方案將用戶身份嵌入到屬性密鑰中, 支持第三方公開追溯泄露密鑰者的身份且能準確判斷是惡意用戶還是屬性中心需要對泄露的密鑰負責. 2018 年, Jiang[27]提出一個結合了秘密分享技術的ABE 方案, 在實現(xiàn)追蹤泄露密鑰用戶的同時解決了屬性密鑰的濫發(fā)的問題. 在現(xiàn)實生活中, 用戶的屬性密鑰往往是由多個屬性中心進行管理的. 為了契合實際應用的場景, 2007 年, Chase[28]實現(xiàn)了多屬性授權中心的ABE 方案: 用戶的密鑰由多個授權中心分配, 單個或少數(shù)中心非法的密鑰分發(fā)行為無法影響整個系統(tǒng)的安全性, 在一定程度上增強了系統(tǒng)的魯棒性. 但其存在兩個問題, 一是方案中存在一個中央授權機構, 其行為不可控(可能是惡意的). 二是該方案僅支持有限集合的屬性, 不利于權限的擴展. 文獻[29] 中方案展示了一個無中央授權機構的ABE 架構. 在該方案中, 所有的屬性中心都彼此獨立地為用戶發(fā)放各自管理的屬性密鑰. 針對第二個問題, Yang 等人[30]利用合數(shù)階雙線性群, 提出了一種支持權限擴展的多授權中心ABE 方案, 并利用雙系統(tǒng)加密方法證明該方案是安全的.

2 背景

2.1 符號定義

表1 符號定義Table 1 Notations

2.2 以太坊

當前支持智能合約的主流區(qū)塊鏈系統(tǒng)有以太坊、codius 和hyperledger 等. 以太坊是其中最為活躍的公有鏈系統(tǒng), 它提供了去中心化的以太坊虛擬機來處理智能合約, 具有圖靈完備性. 執(zhí)行以太坊合約中的函數(shù)需要消耗一定的交易費用gas.

以太坊上智能合約的運行原理如圖1 所示. 首先, 以太坊客戶端發(fā)送調用合約函數(shù)的指令給以太坊節(jié)點; 然后, 以太坊節(jié)點將該指令輸入其本地以太坊虛擬機, 按合約規(guī)則執(zhí)行指令并返回結果; 最后, 以太坊節(jié)點互相對比驗證運算結果, 根據(jù)系統(tǒng)共識機制將結果記錄到鏈上.

圖1 以太坊智能合約運行原理Figure 1 Execution principle of smart contracts on Ethereum

2.3 屬性基加密

屬性基加密方案的主要思路是: 用戶利用某特定屬性集進行加密. 解密時, 只有解密者的屬性集合滿足一定條件才能正確解密密文. 基本描述如下:

(1) (PK,MK) ←Setup(d): 該算法由授權機構執(zhí)行, 輸入安全參數(shù)d, 輸出系統(tǒng)公鑰PK 以及主私鑰MK.

(2) SK ←KeyGen(PK,MK,W): 該算法由授權機構執(zhí)行, 輸入系統(tǒng)公鑰PK、主私鑰MK, 用戶屬性集合W, 生成該用戶的私鑰SK.

(3) CT ←Encrypt(PK,W′,M): 該算法由發(fā)送方執(zhí)行, 利用系統(tǒng)公鑰PK、屬性集W′對消息M進行加密, 生成密文CT.

(4) M ←Decrypt(PK,SK,CT): 該算法由消息接收方執(zhí)行, 利用系統(tǒng)公鑰PK、私鑰SK 解密CT,生成明文消息M.

屬性基加密方案可分為兩類: KP-ABE 和CP-ABE. 它們均是在上述基本方案的基礎上做了一些改進. 本系統(tǒng)為保證發(fā)送者對信息的訪問控制能力, 將使用CP-ABE 方案. 在CP-ABE 方案中, 發(fā)送方可以用自己定義的訪問控制結構A 代替基本加密過程中的屬性集W′, 用戶私鑰仍舊通過屬性集W 進行生成. 在這個設定下, 解密方只有滿足了訪問結構才能正確解密. 其工作流程如圖2 所示.

3 方案構造

3.1 系統(tǒng)架構

本文方案的身份信息共享認證系統(tǒng)是由多個分布式職能域包含的節(jié)點組成的區(qū)塊鏈網(wǎng)絡, 系統(tǒng)架構如圖3 所示.

本方案中的職能域是根據(jù)機構的職能進行分類的, 例如醫(yī)院域是所有醫(yī)療節(jié)點的集合, 教育域是所有學校節(jié)點的集合. 而從宏觀上來看, 職能域又可以被分為注冊域和查詢域兩大類. 注冊域是可以進行User 身份信息注冊和身份信息更新的節(jié)點組成的域. 注冊域中有一個權限最高的可信節(jié)點(或者節(jié)點組)Center. 注冊域的其余節(jié)點都要在Center 進行注冊, 并由Center 頒發(fā)數(shù)字證書; 查詢域是可以進行身份信息查詢的節(jié)點所組成的域, 本方案中的所有職能域都屬于查詢域.

圖2 CP-ABE 方案Figure 2 Scheme of CP-ABE

圖3 系統(tǒng)架構Figure 3 System structure

3.2 區(qū)塊鏈構造

區(qū)塊鏈: 方案中的區(qū)塊鏈結構參照以太坊系統(tǒng). 在區(qū)塊中以智能合約作為交易的形式來記錄注冊的身份信息.

智能合約: 我們將方案中的合約命名為身份注冊合約, 合約的結構如圖4. 其功能是記錄注冊的身份信息, 并支持查詢域中節(jié)點的查詢及注冊域節(jié)點的更新.

圖4 身份注冊合約結構Figure 4 Structure of registration contract

本文的身份注冊合約可分為變量區(qū)和函數(shù)區(qū)兩部分. 變量區(qū)包括: (1) 全局變量. 包含映射結構VaildRegistrars (地址到布爾類型的映射, 用于標識合法的注冊域用戶) 和UsersMap (地址到用戶數(shù)據(jù)結構Struct 的映射). (2) 與用戶數(shù)據(jù)相關的Struct 結構: Certificate 為采用Base64 標準編碼的數(shù)字證書字符串, 這里的數(shù)字證書歸屬于對應用戶的注冊域節(jié)點; Tvalid為Unix 時戳, 代表注冊用戶的身份有效期;Sig(Tvalid) 為該注冊域節(jié)點對Tvalid的簽名; PropertyList 為屬性基加密后的用戶身份信息集合(以字符串形式存在), 其包含了用戶不同的加密身份信息.

函數(shù)區(qū)包括: (1) 注冊域節(jié)點執(zhí)行的注冊函數(shù), 有add() 和setStruct() 兩個函數(shù). add() 只能由Center 調用, 輸入一個注冊域節(jié)點的地址來實現(xiàn)鏈上注冊(即令該注冊域節(jié)點的地址在VaildRegistrars映射結果為true). setStruct() 只能由完成鏈上注冊的注冊域節(jié)點調用, 函數(shù)的輸入為用戶鏈上地址, 用戶的Struct 信息, 其目的是實現(xiàn)用戶身份數(shù)據(jù)的更新. (2) 查詢域節(jié)點執(zhí)行的查詢函數(shù). 包括獲取注冊特定用戶身份的注冊域節(jié)點信息的getInfo() 和獲得特定用戶加密身份信息的getProperty(). 函數(shù)的具體細節(jié)如下:

函數(shù)1 add()Input: a registered node’s address R.add Output: NULL 1 S = msg.sender 2 if S == Center.address then 3 VaildRegistrars[R.add] = true 4 end函數(shù)2 setStruct()Input: a user’s address U.add, a property list Pro, a digital certificate Certificate, a timer Tvalid, a digital signature Sig(Tvalid)Output: a Flag 1 S = msg.sender 2 if VaildRegistrars[S]==true then 3 UsersMap(U.add).PropertyList = Pro 4 UsersMap(U.add).Certificate = Certificate 5 UsersMap(U.add).Tvalid = Tvalid 6 UsersMap(U.add).Sig(Tvalid) = Sig(Tvalid)7 Flag = true 8 end 9 else 10 Flag = false 11 end 12 return Flag函數(shù)3 getInfo()Input: a user’s address U.add Output: Certificate, Tvalid, Sig(Tvalid)1 return UsersMap(U.add).Certificate,UsersMap(U.add).Tvalid,UsersMap(U.add).Sig(Tvalid)函數(shù)4 getProperty()Input: a user’s address U.add Output: a PropertyList 1 return UsersMap(U.add).PropertyList

節(jié)點: 方案中的所有節(jié)點均為記賬節(jié)點, 由獨立域中所有節(jié)點的服務器充當, 主要負責維護區(qū)塊鏈賬本. 記賬節(jié)點采用POW 共識機制, 將身份注冊合約打包并記錄在區(qū)塊內, 以獲取一定收益. 查詢域中的節(jié)點可以訪問合約中的數(shù)據(jù), 而只有注冊域中的節(jié)點才可以發(fā)布和更新身份注冊合約.

3.3 身份信息共享認證方案

本文的方案分為身份注冊合約發(fā)布、身份信息注冊、身份信息查詢認證和身份信息更新4 個部分. 身份注冊合約發(fā)布是Center 節(jié)點根據(jù)注冊域節(jié)點的信息部署或更新身份注冊合約的過程. 身份信息注冊是User 通過注冊域的節(jié)點將身份信息注冊到區(qū)塊鏈上成為Registrant 的過程. 身份信息查詢認證即需要獲取身份信息的節(jié)點根據(jù)Registrant 給出的地址信息到鏈上查詢, 并將查詢結果與Registrant 給出的信息對比驗證的過程. 身份信息更新即注冊域中的節(jié)點更新Registrant 身份信息的過程.

3.3.1 身份注冊合約發(fā)布

(1) 注冊域節(jié)點信息注冊. 節(jié)點到Center 申請成為注冊節(jié)點, Center 記錄所有注冊節(jié)點.

(2) 身份注冊合約部署. Center 發(fā)布身份注冊合約, 由記賬節(jié)點打包部署到區(qū)塊鏈上.

(3) 鏈上注冊. Center 調用add 函數(shù)添加合法的注冊域節(jié)點到VaildRegistrars 結構中.

3.3.2 身份信息注冊

身份注冊總體流程如圖5 所示.

(1) 信息填寫.

(i) User 在注冊域節(jié)點填報詳細的身份信息, 包括個人信息、家庭信息及生物認證信息等.

(2) 屬性基加密身份信息.

(ii) 注冊域節(jié)點根據(jù)身份信息分類標準(以個人信息、家庭信息和生物認證信息分類為例), 將注冊者身份信息分類.

(iii) 注冊域節(jié)點根據(jù)信息的分類情況采用不同的訪問控制結構對信息進行屬性基加密. 這里為保證加解密效率, 并壓縮存儲空間, 將采用混合加密的手段加密. 即使用屬性基加密手段加密一個AES 加密密鑰, 并用AES 算法加密各分類信息. 最后將兩部分拼接作為本次加密結果.

(3) 發(fā)布身份注冊信息.

(iv) 注冊域節(jié)點調用setStruct() 將屬性基加密后的信息發(fā)布到身份注冊合約中.

圖5 身份注冊流程圖Figure 5 Flow diagram of registration

3.3.3 身份信息查詢認證

身份信息查詢適應的場景是區(qū)塊鏈中的任意節(jié)點想查詢或核實某Registrant 身份信息. 這里我們假設查詢者已經向屬性密鑰授權中心提供自己的屬性集合, 并獲得了授權中心計算返回的相應解密屬性密鑰.

(1) 獲取Registrant 在鏈上的地址.

(i) 查詢者請求查詢Registrant 身份信息, Registrant 給出其在區(qū)塊鏈上的地址.

(2) 查詢者獲取Registrant 的身份信息.

(ii) 查詢者根據(jù)Registrant 的地址調用getInfo() 獲取相應注冊域節(jié)點的證書Certificate、有效期限Tvalid、期限簽名Sig(Tvalid).

(iii) 查詢者通過證書信息驗證注冊節(jié)點身份. 驗證通過后再驗證對期限簽名的有效性.

(iv)若步驟(iii)驗證通過, 則證明Registrant 身份有效. 查詢者調用合約中的getProperty()方法來獲取屬性基加密后的身份信息集合. 若驗證不通過, 則認定Registrant 身份無效, 結束查詢.

(3) 查詢者根據(jù)其解密屬性密鑰進行對鏈上獲取到的該Registrant 的身份信息進行解密操作, 獲得該查詢者被授權可以訪問到的數(shù)據(jù).

(4) 查詢者將其被授權訪問得到的數(shù)據(jù)與Registrant 當前給出的身份信息做比對, 以認證其身份.

3.3.4 身份信息更新

身份信息更新操作適應的場景是某注冊完成人的身份信息發(fā)生改變或者注冊信息過期.

(1) 注冊域的節(jié)點重新采集Registrant 身份信息.

(2) 注冊域節(jié)點對更新后的數(shù)據(jù)重新分類并進行屬性基加密操作.

(3) 注冊域節(jié)點調用合約的setStruct() 方法, 傳入待更新目標用戶的地址和該用戶的Struct 信息.

(4) 礦工先根據(jù)VaildRegistrars 結構核實函數(shù)調用者身份, 若調用者為注冊域節(jié)點, 則根據(jù)set-Struct() 方法傳入的參數(shù)進行更新. 否則, 不執(zhí)行更新操作.

4 性能分析

本實驗對方案中的身份注冊合約進行實際測試. 本方案的實驗硬件環(huán)境為Intel(R) Core(TM) i5-8300H CPU @ 2.3 GHz,RAM 為8 GB. 本方案的實驗軟件環(huán)境為geth-windows-amd64-1.8.8 和Ethereum-Wallet-win64-0-11-1. 基于以太坊搭建私有鏈, 設定困難為值為0x20000.

信息采集: 為滿足實驗測試的需求, 本方案采集數(shù)據(jù)包括三種類型: 個人信息, 家庭信息及生物特征信息. 其中個人信息包含姓名, 性別, 身份證號, 學歷. 家庭信息包括家庭成員信息, 家庭住址, 籍貫. 生物特征信息包括人臉特征和指紋特征.

本實驗采用目前常用的基于深度學習的ResNet 算法[31]提取用戶人臉信息. 我們采用1024 維度的特征提取參數(shù), 并以32 位浮點數(shù)進行保存, 獲得的人臉圖像的特征結果大小為4 KB. 本實驗基于指紋特征提取算法[32], 可在保證認假率小于0.0001% 且拒真率小于0.75% 的前提下, 獲得指紋特征大小為512 B. 我們設定個人信息數(shù)據(jù)量大小為400 B, 家庭信息數(shù)據(jù)大小為600 B. 綜合所有個人身份信息,總的單樣本數(shù)據(jù)量大小約為5.5 KB.

合約測試實驗: 本實驗利用solidity 實現(xiàn)了文中的身份注冊合約, 并在搭建的私鏈上完成了測試. 我們測試了部署身份注冊合約和執(zhí)行合約中各函數(shù)的gas 花費以評估本文方案經濟性. 在測試實際花費時,我們選擇了3Gwei (每gas 對應3Gwei 以太幣) 和6Gwei (每gas 對應6Gwei 以太幣) 兩種匯率, 并將實際花費最終統(tǒng)一換算為美元表示.

測試的結果如表2 所示. 由測試結果可以看出, 合約的部署花費以及執(zhí)行add、getInfo、getProperty等函數(shù)的花費較低, 其中getInfo、getProperty 這兩個查詢函數(shù)的調用不需要額外花費. 而由于setStruct函數(shù)在調用時需要傳入較大的數(shù)據(jù)量, 所以經濟性上相對較差.

為減少調用setStruct 函數(shù)時的花費, 本文也支持一種均衡的方案: 只向合約中傳輸一個存放了特定用戶Struct 信息的鏈接及該信息的哈希值, 而把實際的信息放到鏈下存儲. 采用該方案的gas 消耗僅為88 605. 但是此均衡方案需要執(zhí)行重定向和數(shù)據(jù)完整驗證操作, 所以在效率方面稍顯不足.

表2 注冊合約中不同函數(shù)的花費Table 2 Cost of diあerent functions in registration contract

效率測試實驗: 本實驗將比較普通加密存取和屬性基加密結合區(qū)塊鏈兩類方案, 以評估方案的效率情況. 第一類方案即方案一: 采用AES 加解密明文身份信息, 并基于數(shù)據(jù)庫進行存取對比操作; 第二類方案基于區(qū)塊鏈系統(tǒng)采用CP-ABE 和AES 結合的混合加解密方式, 即利用CP-ABE 加(解) 密AES 密鑰,并利用該密鑰對明文數(shù)據(jù)進行AES 加(解) 密. 其包含兩個具體方案, 它們的密文大小和數(shù)據(jù)加解密時間不同. 方案二: 加密手段采用文獻[33] 中的方案結合AES, 數(shù)據(jù)存儲查詢基于區(qū)塊鏈的智能合約. 方案三:數(shù)據(jù)存儲查詢與方案二相同, 解密手段采用文獻[34] 的方案結合AES.

下面對各個方案的加解密算法性能進行比較. 其中, 明文數(shù)據(jù)大小均為5.5 KB, 屬性基加密的系統(tǒng)屬性集大小為20, 用戶屬性集大小為20, 策略屬性集大小為5.

表3 不同方案的性能Table 3 Performance of diあerent schemes

結合表3 中的結果, 我們進行了各方案的整體信息存儲(包括數(shù)據(jù)加密和存儲過程) 與查詢(包括信息查詢和解密過程) 測試. 測試結果如圖6 和圖7 所示.

圖6 身份信息存儲耗時Figure 6 Time cost of storing identity information

圖7 身份信息查詢耗時Figure 7 Time cost of searching identity information

由圖6 和圖7 可見, 普通的AES 加密結合數(shù)據(jù)庫存儲的方案(即方案一), 在數(shù)據(jù)存儲和查詢性能上都要優(yōu)于后兩種方案. 但是, 單一的AES 加密無法滿足可控權限的身份信息共享需求. 方案三相對方案二的存儲耗時長, 但查詢耗時短, 且與方案一的查詢性能相近. 在本設計方案中, 一般來說數(shù)據(jù)存儲是一次性的, 而數(shù)據(jù)的查詢是多次進行的. 所以綜合上述情況, 我們認為方案三更加適合本文的需求.

5 總結

本文設計了基于區(qū)塊鏈的身份信息共享認證方案. 在數(shù)據(jù)存儲方面, 存儲的數(shù)據(jù)量稍大于傳統(tǒng)的基于AES 算法的數(shù)據(jù)存儲方案. 在數(shù)據(jù)查詢方面, 由于各區(qū)塊鏈節(jié)點都擁有全部注冊者身份信息, 因此減少了并發(fā)查詢的壓力. 在數(shù)據(jù)更新方面, 更新函數(shù)只能由更新域中的節(jié)點調用, 并且合約會根據(jù)更新時間戳進行判斷執(zhí)行更新操作, 每次只執(zhí)行最近的更新操作, 保證了全網(wǎng)一致的更新操作. 綜合實驗性能, 我們認為該方案具有較強的可行性.