亚洲免费av电影一区二区三区,日韩爱爱视频,51精品视频一区二区三区,91视频爱爱,日韩欧美在线播放视频,中文字幕少妇AV,亚洲电影中文字幕,久久久久亚洲av成人网址,久久综合视频网站,国产在线不卡免费播放

        ?

        區(qū)塊鏈電子病歷中基于密鑰聚合的密文檢索方案

        2021-05-17 05:30:34牛淑芬王彩芬杜小妮
        計算機工程 2021年5期
        關(guān)鍵詞:用戶

        牛淑芬,韓 松,于 斐,王彩芬,杜小妮

        (1.西北師范大學 計算機科學與工程學院,蘭州 730070;2.深圳技術(shù)大學 大數(shù)據(jù)與互聯(lián)網(wǎng)學院,廣東 深圳 518118;3.西北師范大學 數(shù)學與統(tǒng)計學院,蘭州 730070)

        0 概述

        病歷是醫(yī)務人員對病人患病經(jīng)過和治療情況所作的文字記錄,是醫(yī)生診斷和治療疾病的依據(jù)。隨著醫(yī)院現(xiàn)代化建設的發(fā)展和計算機信息技術(shù)的普及,電子病歷(Electronic Medical Record,EMR)逐步取代紙質(zhì)病歷,在病人信息的收集、儲存、分析、傳遞和利用中得到廣泛應用,解決了紙質(zhì)病歷易丟失、易損壞等問題。對于疾病的研究[1],醫(yī)生或醫(yī)療機構(gòu)需對大量相同或類似的EMR 進行系統(tǒng)分析對比以找出準確的病因和更好的醫(yī)療辦法[2-4]。隨著大量EMR 的生成,不僅占用醫(yī)院本地服務器資源,而且難以進行數(shù)據(jù)共享和計算[5-7],因此越來越多的醫(yī)院選擇存儲空間大、計算效率高和響應速度快的云服務器進行存儲[8-10]。但是,如果云服務器受到攻擊或缺乏監(jiān)控,數(shù)據(jù)可能會被竊取、泄露或篡改,而且云服務器可能存在未經(jīng)授權(quán)訪問等安全問題,所以云服務器不能被用戶完全信任,而去中心化分布式存儲的區(qū)塊鏈技術(shù)[11-13]為EMR 提供了安全不可修改的記錄,然而很多EMR 文件數(shù)據(jù)由于具有高度保密性和敏感性,因此不能直接存儲在區(qū)塊鏈中,以太坊[14]是一個具備圖靈完備性的開源區(qū)塊鏈平臺,為實現(xiàn)EMR 在區(qū)塊鏈上的存儲提供了技術(shù)支持[15]。

        在文件上傳存儲前必須將數(shù)據(jù)文件進行加密,以保證數(shù)據(jù)的安全性和隱私性,但在搜索大量數(shù)據(jù)時,數(shù)據(jù)使用者需要將全部數(shù)據(jù)文件下載并解密,然后進行數(shù)據(jù)搜索,因此該方法的搜索效率極低。文獻[16]提出在密文上實現(xiàn)關(guān)鍵字搜索的可搜索加密(Searchable Encryption,SE)方案,該方案的搜索效率較高并保證了服務器執(zhí)行搜索操作時的隱私性和保密性,但在存放加密數(shù)據(jù)時對不同文檔通常使用不同的密鑰,用戶持有的密鑰會隨文檔數(shù)量的增多而增加,因此用戶必須生成大量的陷門進行搜索,導致工作效率低下。文獻[17]提出一種可搜索的聚合密鑰加密方案,解決了用戶持有大量不同密鑰時的復雜困難搜索問題,但在用戶得到數(shù)據(jù)后一般需要在相關(guān)文檔集上進行驗證,當用戶完成對大量文檔集的搜索后也會擁有大量的可驗證令牌,因此文獻[18]提出一種可驗證的可搜索聚合密鑰加密方案,該方案實現(xiàn)了對通過密鑰聚合得到數(shù)據(jù)的簡單快速驗證。本文提出一種面向區(qū)塊鏈電子病歷的基于密鑰聚合的密文檢索方案。該方案利用密鑰聚合技術(shù),當數(shù)據(jù)用戶請求多個文件數(shù)據(jù)時,僅需生成一個聚合陷門即可進行數(shù)據(jù)檢索,同時通過智能合約技術(shù)確保用戶進行數(shù)據(jù)驗證,從而得到正確完整的文件。

        1 基礎知識

        1.1 雙線性映射和困難性假設

        定義1令G1和G2為兩個階為素數(shù)p的乘法循環(huán)群,定義一個雙線性映射e:G1×G1→G2滿足如下性質(zhì):

        1)雙線性:對任意的u,v∈G1,存在a,b∈?*p,使得e(ua,vb)=e(u,v)ab。

        2)非退化性:存在u,v∈G1,使得e(u,v)≠1。

        3)可計算性:對任意的u,v∈G1,存在有效算法計算e(u,v)。

        定義2基于l階的雙線性Diffie-Hellman 指數(shù)假設(l-BDHE)問題給定包含(2l+1)個元素的向量作為輸入,輸出為。在本文中為便于描述,使用gi表示。

        1.2 同態(tài)向量哈希函數(shù)

        定義3設G是一個階為p的循環(huán)群,隨機選取公共參數(shù)g1,g2,…,gd∈G,則向量v=(v1,v2,…,vd)∈?p的哈希函數(shù)為:

        向量哈希函數(shù)滿足以下性質(zhì):

        1)同態(tài)性:對任意2 個向量m1、m2和2 個實數(shù)l1、l2,滿足。

        2)免碰撞性:不存在一個多項式時間的攻擊者偽造一個向量m3,同時滿足m3≠l1m1+l2m2且。

        定理1同態(tài)向量哈希函數(shù)在離散對數(shù)問題是困難問題假設下是安全的[19]。

        1.3 密鑰聚合的密文檢索方案

        為防止數(shù)據(jù)在上傳過程中的信息泄露,通常采用加密云存儲[20],具體方法為:在數(shù)據(jù)上傳至云端前數(shù)據(jù)擁有者將所有文件加密,加密數(shù)據(jù)只能被解密密鑰擁有者進行搜索和解密。假如文件擁有者希望通過云服務器安全共享敏感文件,同時擁有者希望向部分用戶授權(quán),使得用戶可以在擁有者提供的子集中搜索文件。針對該關(guān)鍵字搜索問題,文獻[21-22]提出可搜索加密技術(shù),保證了服務器執(zhí)行搜索時的隱私性和保密性。

        如圖1 所示,在傳統(tǒng)密文檢索方案中,Alice 對其不同的文檔集使用不同的密鑰加密并上傳至云服務器,當Bob 想獲取部分文檔S(|S|=m)的搜索時,Alice 需要將密鑰通過安全信道發(fā)送給Bob進行授權(quán)。為搜索S中的目標文檔,Bob 需要生成包含關(guān)鍵字w的大量陷門并提交給云服務器獲得文件進行結(jié)果驗證。當m足夠大時,對于Bob 而言,密鑰的分配和存儲以及陷門的生成會變得非常困難,這違背了使用云服務器存儲和計算的初衷。本文使用改進的聚合密鑰檢索方案,將大量計算和存儲轉(zhuǎn)移至云服務器且不會造成信息泄露。如圖2 所示,在聚合密鑰的密文檢索方案中,Alice 和Bob 只需發(fā)送一個聚合密鑰kagg和一個聚合陷門Tr,利用密鑰聚合技術(shù)將大量文件進行聚合并發(fā)送給用戶,用戶通過生成聚合陷門得到請求數(shù)據(jù)從而提高搜索效率。

        圖1 傳統(tǒng)密文檢索方案Fig.1 Traditional ciphertext retrieval scheme

        圖2 密鑰聚合的密文檢索方案Fig.2 Ciphertext retrieval scheme of key aggregation

        1.4 區(qū)塊鏈中的智能合約技術(shù)

        智能合約由密碼學家尼克·薩博于1995 年提出[23],是一套以數(shù)字形式定義的承諾,承諾控制著數(shù)字資產(chǎn)并包含了合約參與者約定的權(quán)利和義務。智能合約的工作理論遲遲沒有實現(xiàn),一個重要原因是因為缺乏能夠支持可編程合約的數(shù)字系統(tǒng)和技術(shù),區(qū)塊鏈技術(shù)的出現(xiàn)解決了該問題。區(qū)塊鏈系統(tǒng)中的每個節(jié)點用戶可以通過發(fā)布一筆交易創(chuàng)建智能合約[24],并利用編程方式將智能合約設置為自己的所有權(quán)轉(zhuǎn)移規(guī)則、交易方式和狀態(tài)轉(zhuǎn)換函數(shù)。本文利用以太坊區(qū)塊鏈中的智能合約技術(shù),并使用Solidity語言編寫智能合約,第三方數(shù)據(jù)用戶將結(jié)果提供給完成部署的智能合約以驗證醫(yī)療云服務器返回的檢索結(jié)果是否正確和完整,函數(shù)將正確的檢索結(jié)果返回給用戶,通過智能合約技術(shù)確保用戶獲得的文件數(shù)據(jù)未被云服務器惡意篡改或丟失信息。

        2 算法形式化定義和系統(tǒng)模型

        2.1 算法形式化定義

        算法形式化定義如下:

        1)系統(tǒng)建立SetUp(1λ)→params:輸入安全參數(shù)λ和公開的雙線性映射B=(p,G1,G2,e(·,·)),醫(yī)療云服務器運行該算法輸出系統(tǒng)參數(shù)params=(B,Ppub,H)。

        2)密鑰生成KeyGen(γ)→(pk,msk):輸入隨機數(shù)γ∈?*p,醫(yī)生執(zhí)行該算法輸出密鑰對、公鑰pk 和主密鑰msk。

        3)數(shù)據(jù)加密Encrypt(Dm,w,I,H)→(Cm,Cw,Δi,A,hi):輸入電子病歷文件Dm、關(guān)鍵字w和文件索引Im,醫(yī)生執(zhí)行該算法輸出加密文件Cm、關(guān)鍵字密文Cw和輔助值Δi并上傳至云服務器,同時輸出文件地址Ai。醫(yī)生對每一個Cmi∈Cm計算hi=H(Cmi),并將每一個Cmi∈Cm對應的文件地址Ai與hi共同構(gòu)建為新交易,同時將交易廣播至聯(lián)盟鏈。

        4)聚合密鑰提取Extract(msk,S)→kagg:輸入主密鑰msk 和集合S,通過醫(yī)院授權(quán)后醫(yī)生執(zhí)行該算法輸出聚合密鑰kagg。

        5)陷門生成Trapdoor(kagg,wi)→Tr:輸入聚合密鑰kagg和待搜索關(guān)鍵字wi,數(shù)據(jù)用戶執(zhí)行該算法輸出聚合陷門Tr。

        6)搜索驗證Test(Tr,Δi,S)→(Ai,Cmi):輸入陷門Tr、輔助值Δi和集合S,醫(yī)療云服務器執(zhí)行該算法進行搜索,當驗證結(jié)果為正確時則輸出密文文件Cmi和對應的文件地址Ai,否則檢索失敗。

        7)數(shù)據(jù)驗證Verify(A′i,h′i)→δ:輸入文件地址A′i和h′i,聯(lián)盟鏈通過智能合約執(zhí)行該算法進行驗證,若輸出結(jié)果為δ則代表驗證結(jié)果為正確,否則返回錯誤結(jié)果。

        2.2 系統(tǒng)模型

        本文電子病歷系統(tǒng)模型如圖3 所示,該系統(tǒng)主要包括患者、數(shù)據(jù)擁有者、數(shù)據(jù)用戶、醫(yī)療云服務器和聯(lián)盟鏈5 個實體:

        1)患者:患者在醫(yī)院就醫(yī)時需要用個人身份證/醫(yī)保卡進行醫(yī)院注冊,當患者在醫(yī)院注冊后,醫(yī)生會根據(jù)對患者的診斷創(chuàng)建其個人的電子病歷,本文中當患者在醫(yī)院就醫(yī)并創(chuàng)建了電子病歷,即默認患者將個人的電子病歷授權(quán)給了醫(yī)院和醫(yī)生。

        2)數(shù)據(jù)擁有者:數(shù)據(jù)擁有者指的是醫(yī)院和醫(yī)生。醫(yī)生在得到患者的授權(quán)后負責生成電子病歷,在電子病歷中提取并生成一系列關(guān)鍵字,將電子病歷和關(guān)鍵字進行加密并計算加密文件的哈希值,并將加密文件和加密的關(guān)鍵字共同上傳至醫(yī)療云服務器,然后將醫(yī)療云服務器返回的文件地址和密文的哈希值構(gòu)建為新交易廣播至聯(lián)盟鏈。

        3)數(shù)據(jù)用戶:數(shù)據(jù)用戶指的是醫(yī)療機構(gòu)和政府等權(quán)威機構(gòu),且包括醫(yī)院和醫(yī)生在內(nèi)的聯(lián)盟鏈中的成員。數(shù)據(jù)用戶向醫(yī)院進行數(shù)據(jù)請求,當醫(yī)院授權(quán)給醫(yī)生后,醫(yī)生生成相關(guān)文件的聚合密鑰,數(shù)據(jù)用戶將生成的聚合陷門發(fā)送給醫(yī)療云服務器得到數(shù)據(jù)文件,獲取數(shù)據(jù)后計算密文的哈希值并發(fā)送給聯(lián)盟鏈,同時通過智能合約驗證數(shù)據(jù)是否完整正確。

        4)醫(yī)療云服務器:醫(yī)療云服務器主要負責存儲醫(yī)生上傳的加密文件和加密關(guān)鍵字,并將存儲的數(shù)據(jù)文件地址返回給數(shù)據(jù)擁有者。當數(shù)據(jù)用戶上傳聚合陷門時,醫(yī)療云服務器會進行搜索驗證,只有當結(jié)果為正確時才會將數(shù)據(jù)文件和文件地址一起返回給數(shù)據(jù)用戶,否則檢索失敗。

        5)聯(lián)盟鏈:聯(lián)盟鏈節(jié)點負責將醫(yī)生上傳的對應密文哈希值和文件地址構(gòu)建的新交易進行驗證并打包放入?yún)^(qū)塊中,當用戶發(fā)送密文哈希值和相應的文件地址時,聯(lián)盟鏈通過已部署好的智能合約驗證用戶得到的數(shù)據(jù)正確性和完整性,當數(shù)據(jù)正確時觸發(fā)智能合約返回正確驗證結(jié)果,否則返回錯誤驗證。

        圖3 電子病歷系統(tǒng)模型Fig.3 System model of electronic medical record

        2.3 方案設計目標

        2.3.1 功能性需求

        本文方案需滿足以下3 個功能性需求:

        1)緊湊性,確保聚合密鑰的大小獨立于分享的文件數(shù)量。對于一組密鑰{ki}(i∈S),將其密鑰聚合Extract(msk,S)→kagg,在設計方案時需要在后續(xù)步驟不失效的情況下將密鑰集聚合為單個密鑰。

        2)可搜索性,使用戶提供的任何關(guān)鍵字在可搜索加密文檔上生成所需的陷門,即在減少密鑰數(shù)量的同時保留搜索功能。對于每一個包含關(guān)鍵字w的文檔集,要求其如果得到陷門Trapdoor(kagg,wi)→Tr,則應計算出Test(Tr,Δi,S)→(Ai,Cmi),并且通過驗證。

        3)安全授權(quán),通過聚合密鑰將關(guān)鍵字的搜索權(quán)委托給數(shù)據(jù)用戶。為確保任何擁有委托聚合密鑰的用戶都可以執(zhí)行關(guān)鍵字搜索,要求陷門生成算法的輸入是不能公開的,即這些輸入不應該依賴任何用戶的私人信息。

        2.3.2 安全性需求

        任何可搜索的聚合密鑰加密方案應滿足以下兩個安全性需求:

        1)聚合密鑰安全性,攻擊者無法搜索沒有數(shù)據(jù)擁有者授權(quán)的任意關(guān)鍵字,即攻擊者不能對已知聚合密鑰但無關(guān)的文檔進行關(guān)鍵字搜索,也不能根據(jù)已知密鑰為其他文檔集生成新的聚合加密密鑰。

        2)陷門和關(guān)鍵字安全性,攻擊者無法從陷門中確定檢索中使用的關(guān)鍵字,只能通過觀察獲得關(guān)鍵字信息,即用戶可能會要求不受信任的云服務器搜索敏感詞,但不會將該敏感詞透露給云服務器。

        3 基于密鑰聚合的密文檢索方案

        基于密鑰聚合的密文檢索流程具體如下:

        1)系統(tǒng)建立:醫(yī)療云服務器輸入安全參數(shù)λ和公開的雙線性映射B=(p,G1,G2,e(·,·)),定義一個雙線性映射e:G1×G1→G2和抗碰撞的哈希函數(shù)H:{0,1}*→G1,且循環(huán)群G1的階為p(2λ≤p≤2λ+1),隨機選取生成元g∈G1和,計算。假設n為醫(yī)療云服務器可存儲的最大電子病歷數(shù),醫(yī)療云服務器輸出系統(tǒng)參數(shù)params=(B,Ppub,H),其中。

        3)數(shù)據(jù)加密:醫(yī)生使用該算法加密數(shù)據(jù),將每個患者的電子病歷加密為Cm=,并將電子病歷中出現(xiàn)的所有癥狀提取生成一系列關(guān)鍵字w={w1,w2,…,wn}。為生成關(guān)鍵字密文,該算法需輸入文件索引Im∈{ 1,2,…,n},醫(yī)生需要進行以下操作:

        (2)對每一個關(guān)鍵字wi輸出所有關(guān)鍵字密文,并將Cm和Cw上傳至醫(yī)療云服務器,醫(yī)療云服務器向醫(yī)生返回每個文件在服務器中的存儲地址A={A1,A2,…,An}。

        圖4 聯(lián)盟鏈區(qū)塊數(shù)據(jù)結(jié)構(gòu)Fig.4 Consortium chain block data structure

        4)聚合密鑰提?。横t(yī)生使用該算法生成一個可搜索聚合加密密鑰kagg。當數(shù)據(jù)用戶向醫(yī)生請求相關(guān)電子病歷時,醫(yī)生需要先向醫(yī)院進行申請,在醫(yī)院對醫(yī)生授權(quán)后,對于任何包含關(guān)鍵字索引的文檔子集S?{1,2,…,n},醫(yī)生需要輸入主密鑰msk 并輸出聚合密鑰,為將電子病歷中關(guān)鍵字搜索權(quán)委托給數(shù)據(jù)用戶,需要將聚合密鑰kagg和集合S同時發(fā)送給數(shù)據(jù)用戶。

        5)陷門生成:數(shù)據(jù)用戶使用該算法生成可搜索的關(guān)鍵字陷門。當數(shù)據(jù)用戶得到聚合密鑰kagg后,對于聚合密鑰kagg所有相關(guān)的文檔,該算法將會對搜索關(guān)鍵字wi={w1,w2,…,wn}僅生成一個聚合陷門Tr且計算公式為。數(shù)據(jù)用戶在生成陷門后,將陷門Tr 以及集合S發(fā)送至醫(yī)療云服務器進行搜索驗證算法,只有通過搜索驗證,用戶才可以獲得數(shù)據(jù)。

        6)搜索驗證:云服務器使用該算法執(zhí)行關(guān)鍵字搜索。根據(jù)該算法輸入陷門Tr 與可搜索加密密鑰ki的輔助值Δi=(c1,c2,μ),云服務器進行計算驗證,當結(jié)果正確時向用戶返回加密的密文文件Cmi和相對應的文件地址Ai,若驗證結(jié)果錯誤則檢索失敗,其中,計算公式為,正確性驗證過程為:

        7)數(shù)據(jù)驗證:將服務器部署的智能合約相關(guān)變量和函數(shù)接口采用Solidity 語言編寫,智能合約提供一個函數(shù)接口進行數(shù)據(jù)驗證并保證數(shù)據(jù)用戶得到的文件未被云服務器篡改。當數(shù)據(jù)用戶得到云服務器返回的數(shù)據(jù)文件C′mi和相應的文件地址A′i,數(shù)據(jù)用戶通過公共參數(shù)計算h′i=H(C′mi)并將A′i和H(C′mi)發(fā)送給聯(lián)盟鏈,聯(lián)盟鏈節(jié)點通過地址找到包含此交易的相應區(qū)塊,并使用智能合約算法進行驗證,數(shù)據(jù)驗證階段的智能合約算法具體流程如算法1 所示,當H(C′mi)=H(Cmi)和A′i=Ai時,返回正確驗證結(jié)果δ,否則返回錯誤結(jié)果。

        算法1驗證階段的智能合約算法

        4 安全性分析

        為滿足本文方案的安全需求,假設醫(yī)療云服務器僅根據(jù)本文方案提供合法的服務,授權(quán)用戶可以嘗試訪問權(quán)限范圍內(nèi)或權(quán)限范圍外的數(shù)據(jù)。此外,涉及醫(yī)療云服務器的通信通道被認為是不安全的?;谝陨峡紤],本節(jié)將在聚合密鑰以及陷門和關(guān)鍵字安全性方面進行具體分析。

        4.1 聚合密鑰安全性分析

        本文要求任何擁有聚合密鑰的用戶都可以對集合S中的文檔進行關(guān)鍵字搜索,但不能對集合S之外的文檔進行關(guān)鍵字搜索。用戶也不能從已知的集合S中生成新的集合S′并生成其他的可搜索聚合加密密鑰。每個擁有聚合密鑰的數(shù)據(jù)用戶都可以成功地執(zhí)行關(guān)鍵字檢索。數(shù)據(jù)用戶將得到的聚合密鑰生成一個聚合陷門Tr,然后執(zhí)行搜索驗證算法進行關(guān)鍵字檢索,通過下式可以驗證檢索算法的正確性:

        由此可知,擁有聚合密鑰的數(shù)據(jù)用戶可以成功地執(zhí)行關(guān)鍵字檢索。攻擊者無法對任何不在聚合密鑰范圍內(nèi)的文檔執(zhí)行關(guān)鍵字檢索,即使服務器與惡意授權(quán)用戶串通,也無法對任何不在聚合密鑰范圍內(nèi)的文檔執(zhí)行關(guān)鍵字檢索。攻擊者A可能為云服務器或惡意授權(quán)用戶,此類攻擊者可能試圖對不在其聚合密鑰范圍內(nèi)的文檔執(zhí)行關(guān)鍵字搜索。從中可以看出,如果PS是由錯誤的文檔集j∈S′生成,則e(kagg,gt)與e(PS,gt)在等式中無法消除,因此必須在聚合密鑰相同的文檔集合S上進行計算?;谏鲜銮闆r,攻擊者可能使用目標集合S′作為輸入,但會因為文檔索引Im?S,在搜索驗證算法中返回錯誤結(jié)果。

        攻擊者無法通過已知的聚合密鑰為任何新文檔集合生成新的聚合密鑰。假設一個擁有文檔集合S′的聚合密鑰kagg的攻擊者A想要嘗試為一組新的集合S′生成新的聚合密鑰。A需要已知任意文檔j∈S′的值,即使A已知聚合密鑰的值,由于每個乘數(shù)的值由數(shù)據(jù)擁有者的主密鑰γ生成,因此A無法從獲得的kagg值中獲取其中每個加密的乘數(shù),因此攻擊者A無法從已知的聚合密鑰中為任何新的文檔集合生成新的聚合密鑰。

        4.2 陷門和關(guān)鍵字安全性分析

        假設攻擊者A可能會獲得相關(guān)信息來發(fā)起攻擊,例如當云服務器獲取到存儲的關(guān)鍵字密文、可搜索加密密鑰ki的輔助值Δi和提交的陷門Tr 等時,對于惡意的授權(quán)用戶假設擁有聚合密鑰以及可在文檔集合S中執(zhí)行關(guān)鍵字搜索的權(quán)力,然而即使云服務器能獲取到這些信息,本文方案仍具備查詢隱私安全性。

        4.2.1 陷門安全性

        假設攻擊者A在獲得提交的陷門Tr=kagg·后,只有取得聚合密鑰kagg才能在搜索時獲得關(guān)鍵字,在此情況下由于攻擊者A已知系統(tǒng)參數(shù)以及文檔集合S,為計算kagg,攻擊者A需先計算每一個文檔j∈S的,其中γ為數(shù)據(jù)擁有者的主密鑰且為保密值,而A計算得到γ的概率可以忽略不計,因此攻擊者A無法發(fā)起攻擊,可見本文方案具備陷門安全性。

        4.2.2 關(guān)鍵字安全性

        假設云服務器和攻擊者A試圖在存儲的數(shù)據(jù)中學習且假設已知以及cw=,A可能嘗試發(fā)起以下攻擊:

        1)從已知的c1和c2中檢索t的值,但在離散對數(shù)問題中A不能計算得到t的值。

        5 性能分析

        將本文方案與文獻[17-18,23]方案在區(qū)塊鏈應用、安全搜索、密鑰聚合和可驗證性方面進行對比,如表1 所示,其中,“√”表示具備該功能特性,“×”表示不具備該功能特性,文獻[17-18,23]方案的應用環(huán)境均為云服務器,而本文方案是云服務器和區(qū)塊鏈的結(jié)合。可以看出,文獻[17,23]方案不具備可驗證功能,而本文方案通過應用區(qū)塊鏈智能合約技術(shù)可驗證醫(yī)療云服務器是否惡意修改信息或丟失數(shù)據(jù),保證了用戶獲取文件的正確性和完整性,相比其他方案在區(qū)塊鏈應用、安全搜索、密鑰聚合和可驗證性方面更具優(yōu)勢。

        表1 4 種方案的功能特性對比Table 1 Comparison of functional characteristics of four schemes

        表2 為本文方案與文獻[17-18]方案的運算時間對比結(jié)果,其中,Tp表示雙線性映射配對運算時間,Te表示指數(shù)運算時間,Tm表示乘法運算時間,Th表示哈希函數(shù)運算時間。已知常用的密碼操作時間排序為Tp>Te>Tm>Th且雙線性映射配對Tp的運算時間遠大于其他密碼操作的時間。結(jié)合數(shù)據(jù)加密階段和數(shù)據(jù)搜索階段的運算時間可以看出,本文方案的整體運算時間最少。

        表2 3 種方案的運算時間對比Table 2 Comparison of computing time of three schemes

        為更準確地評估密文檢索方案的實際性能,本文基于2.60 GHz CPU、8 GB 內(nèi)存的聯(lián)想筆記本和Linux 虛擬機,并在真實數(shù)據(jù)集和由C 語言編寫的PBC 庫上進行模擬實驗。在實驗中,將最大文件值n設置為500,關(guān)鍵字個數(shù)設置為1、10、20、30、40 和50,實驗取50 次運行結(jié)果的平均值。為體現(xiàn)本文方案的性能優(yōu)勢,將本文方案和文獻[17]方案數(shù)據(jù)加密和數(shù)據(jù)搜索階段的時間開銷進行對比,如圖5、圖6 所示??梢钥闯?,因為本文方案利用多關(guān)鍵字加密算法,所以在數(shù)據(jù)加密階段的時間開銷隨著關(guān)鍵字的增加而增長,且在關(guān)鍵字個數(shù)大于10 時,本文方案的數(shù)據(jù)加密開銷低于文獻[17]方案。在數(shù)據(jù)搜索階段,本文方案和文獻[17]方案的時間開銷隨著關(guān)鍵字個數(shù)的增加成正相關(guān)變化,且時間開銷低于文獻[17]方案,可見本文方案的搜索效率更高,系統(tǒng)性能更優(yōu)。

        圖5 數(shù)據(jù)加密階段的時間開銷Fig.5 Time cost of data encryption phase

        圖6 數(shù)據(jù)搜索階段的時間開銷Fig.6 Time cost of data search phase

        6 結(jié)束語

        本文提出一種面向區(qū)塊鏈電子病歷的基于密鑰聚合的密文檢索方案。該方案基于云服務器和聯(lián)盟鏈進行構(gòu)建,將醫(yī)院醫(yī)生和醫(yī)療機構(gòu)、政府等權(quán)威機構(gòu)在內(nèi)的聯(lián)盟成員分別定義為數(shù)據(jù)擁有者和數(shù)據(jù)用戶,使數(shù)據(jù)加密上傳至醫(yī)療云服務器,并將數(shù)據(jù)密文哈希值打包至聯(lián)盟鏈,同時使用密鑰聚合技術(shù)對多個文件生成一個聚合陷門進行安全檢索,并利用聯(lián)盟鏈的智能合約技術(shù)實現(xiàn)數(shù)據(jù)驗證,防止醫(yī)療云服務器的惡意攻擊行為。通過理論分析與數(shù)值模擬實驗驗證了該方案的安全性與高效性。

        猜你喜歡
        用戶
        雅閣國內(nèi)用戶交付突破300萬輛
        車主之友(2022年4期)2022-08-27 00:58:26
        您撥打的用戶已戀愛,請稍后再哭
        關(guān)注用戶
        商用汽車(2016年11期)2016-12-19 01:20:16
        關(guān)注用戶
        商用汽車(2016年5期)2016-11-28 09:55:15
        兩新黨建新媒體用戶與全網(wǎng)新媒體用戶之間有何差別
        關(guān)注用戶
        商用汽車(2016年6期)2016-06-29 09:18:54
        關(guān)注用戶
        商用汽車(2016年4期)2016-05-09 01:23:12
        挖掘用戶需求尖端科技應用
        Camera360:拍出5億用戶
        100萬用戶
        亚洲男人精品| 亚洲av成人无码一二三在线观看| 无码一区二区三区免费视频| a级国产乱理论片在线观看 | 久久天天躁夜夜躁狠狠躁2022 | 国产毛片视频一区二区| 亚洲a∨国产av综合av下载| 国产AV无码专区亚洲AⅤ| 亚洲免费不卡av网站| 亚洲第一区二区精品三区在线| 免费国产a国产片高清网站| 播放灌醉水嫩大学生国内精品| 亚洲国产福利成人一区二区| 中文字幕色一区二区三区页不卡| 高级会所技师自拍视频在线| 精品深夜av无码一区二区| 亚洲AV综合久久九九| 亚洲中文字幕亚洲中文| 人禽杂交18禁网站免费| 纯爱无遮挡h肉动漫在线播放 | 国产成人无码免费看片软件| 在线观看国产精品91| 日本久久视频在线观看| 少妇被又大又粗又爽毛片 | 黑人巨茎大战俄罗斯美女| 中文字幕av日韩精品一区二区| 亚洲一区二区三区免费av在线| 好看的日韩精品视频在线| 亚洲伊人一本大道中文字幕| 亚洲日本天堂| 日韩极品免费在线观看| 伊人中文字幕亚洲精品乱码 | 亚洲成人中文| 视频福利一区二区三区| 米奇欧美777四色影视在线| 无遮挡边摸边吃奶边做视频免费| 白丝美女被狂躁免费视频网站| 日韩中文字幕熟女人妻| 黄桃av无码免费一区二区三区 | 成人不卡国产福利电影在线看| 久久久噜噜噜久久熟女|