基于訪問代理的數(shù)據(jù)加密及搜索技術研究

王國峰，劉川意，韓培義，潘鶴中，方濱興

?

基于訪問代理的數(shù)據(jù)加密及搜索技術研究

王國峰1，劉川意2，韓培義1，潘鶴中1，方濱興2

（1. 北京郵電大學網(wǎng)絡空間安全學院，北京 100876；2. 哈爾濱工業(yè)大學（深圳）計算機科學與技術學院，廣東 深圳 518055）

針對云應用程序數(shù)據(jù)機密性問題，提出一種訪問代理執(zhí)行的密文搜索方案。此方案不需要修改云應用程序且不改變用戶使用習慣，具有很強的可適用性。首先從功能性、效率性和安全性等方面分析了基于訪問代理的密文搜索方案，并指出其所面臨的關鍵問題，包括代理間索引和密文的安全分享，并設計解決方案。實驗結果表明，此方案可有效保護云服務用戶數(shù)據(jù)，實現(xiàn)多種搜索功能，且具有很高的效率性和安全性。

云安全；數(shù)據(jù)保護；密文搜索；密文分享

1 引言

根據(jù)云安全聯(lián)盟（CSA）的報告[1]，數(shù)據(jù)泄露是云計算面臨的重要威脅之一。2016年上半年，共有974個公開披露的數(shù)據(jù)泄露事件，導致5.44億條數(shù)據(jù)記錄被竊取[2]。在數(shù)據(jù)外包到云服務之前將敏感數(shù)據(jù)加密是解決數(shù)據(jù)泄露的一個有效措施[3]。

然而，在客戶端加密數(shù)據(jù)勢必與云應用程序的數(shù)據(jù)計算功能產(chǎn)生沖突，其中搜索是最常見的計算功能之一。目前，密文搜索（SE, searchable encryption）方案需要在查詢功能、安全性和效率之間做出不同的權衡和取舍。Oblivious RAM（ORAM）[4]可以很好地滿足安全性和查詢功能的需求，但對于大規(guī)模的實際應用來說效率極其低下。確定性加密可最大限度地提高效率，但不具有很高的安全性。許多研究人員專注于基于加密索引的密文搜索技術，其包括以下步驟：用戶生成加密文檔和可搜索的加密索引；加密的文件和加密的索引上傳到云服務器；為了搜索某關鍵字，用戶生成一個對應的搜索陷門（trapdoor）；使用陷門，云服務器可以搜索加密索引并返回對應的加密文檔。本文將這種方法稱為云端執(zhí)行的密文搜索（CESE, cloud executed SE）方案。CESE方案可以很好地滿足效率性和安全性。然而，CESE方案往往會失去一些查詢表達能力[5]，并且需要修改當前的云應用程序。

近年來，產(chǎn)業(yè)界開始提倡云訪問安全代理（CASB, cloud access security broker）技術[6]，其中訪問代理透明地位于云應用程序和用戶之間。在敏感數(shù)據(jù)傳入云端之前，CASB對其攔截并加密，實現(xiàn)數(shù)據(jù)保護。然而，目前大多數(shù)CASB解決方案都來自工業(yè)界，技術細節(jié)不是公開的。本文針對云應用程序提出了訪問代理執(zhí)行的密文搜索（BESE, broker executed SE）方案，并從查詢功能、性能和安全性方面對BESE方案做了系統(tǒng)的定量分析。為了不失一般性，選擇3個常見的搜索功能作為代表，即多關鍵字排序搜索、模糊搜索和動態(tài)更新[7]。從定量比較和安全分析方面可以看出，BESE方案是保護云應用程序數(shù)據(jù)的有效解決方案。

然而，并不是把密文搜索的體系結構一改，所有的問題就都自然而然地解決了。在實用性方面，本文指出了BESE方案面臨的一些重要問題，這些問題在其他基于訪問代理執(zhí)行的密文搜索方案中均未涉及，總結如下。

1) 不同訪問代理間的索引分享。例如，位于代理1下的用戶1，遷移到代理2下并想使用原來位于代理1下的索引進行搜索。

2) 不同訪問代理間的密文分享。例如，位于代理1下的用戶1，想要和位于代理2下的用戶2分享部分數(shù)據(jù)。然而，由于數(shù)據(jù)在1下加密，故需要在代理1與2之間安全地分享密鑰。

為了解決上述挑戰(zhàn)，本文提出一種索引分享方案以及一種結合身份加密（IBE）和公鑰加密（PKE）的雙層加密方案，以在代理之間安全地分享索引和加密密鑰。最后本文在實際云應用程序上對BESE方案進行了評估，并對實驗結果進行了評價。

2 相關工作

2.1 加密系統(tǒng)

在用戶和客戶端之間，ShadowCrypt[8]以瀏覽器插件模式運行，以執(zhí)行加密和解密功能。但ShadowCrypt僅支持文本輸入數(shù)據(jù)，不支持移動平臺。Lau等[9]提出了基于移動平臺的用戶和應用層之間的7.5層的M-Aegis。但M-Aegis也是只支持文本數(shù)據(jù)，而BESE方案支持非文本數(shù)據(jù)和移動平臺數(shù)據(jù)。

在客戶端和服務器端之間，Mylar[10]基于Meteor JavaScript框架保護數(shù)據(jù)免受惡意服務器管理員的竊取，影響了后向兼容性。Virtru作為另一個瀏覽器插件執(zhí)行電子郵件加密，使網(wǎng)絡郵件提供商無法訪問用戶的數(shù)據(jù)。Virtru僅支持Gmail等電子郵件，無法適應其他云應用程序。BESE方案也處于客戶端和服務器端之間，但可以透明地與多個云應用程序集成。

在服務器端和數(shù)據(jù)庫之間，CryptDB[11]將數(shù)據(jù)加密后上傳到數(shù)據(jù)庫，并可對加密數(shù)據(jù)執(zhí)行查詢請求，從而有效防護有惡意的數(shù)據(jù)庫管理員。CryptDB無法防護服務器破壞程序。同時查詢請求可能需要多次加密和解密操作。相比之下，BESE方案可以有效地保護數(shù)據(jù)隱私，防止云服務器破壞程序。

2.2 密文搜索

Song等[12]提出了第一個可實用的密文搜索方案，其搜索操作簡單，但云端需要全文掃描，計算量與數(shù)據(jù)大小成正比。另外，云端可以使用查詢統(tǒng)計信息來獲得額外的信息。Goh[13]使用Bloom Filter設計了一種安全的索引方案，實現(xiàn)密文搜索功能。但是，該方案由于使用Bloom Filter，可能導致搜索結果不正確。另外，它不是一個亞線性搜索方案。Curtmola等[14]構建基于反向索引的密文搜索機制，大大提高了搜索效率和密文搜索的安全性。但它只能支持精確的關鍵字搜索，文檔無法動態(tài)更新。根據(jù)文獻[14]，搜索模式意味著給定2個具有相同結果的搜索陷門，是否可以確定2個陷門對應相同的關鍵字。訪問模式是指查詢結果中可能泄露的信息。如果密文沒有泄露明文信息，則密文搜索方案為“選擇明文攻擊”（CPA, chosen plaintext attack）安全。如果用戶一次生成所有查詢，搜索過程中密文和索引不會泄露除訪問模式和搜索模式之外的任何有關文本和查詢的信息，則密文搜索方案是“非自適應選擇關鍵字攻擊”（CKA1, non-adaptive chosen keyword attack）安全。在CKA1的基礎上，“自適應選擇關鍵字攻擊”（CKA2, adaptive chosen keyword attack）安全允許用戶根據(jù)已查詢的陷門和返回的搜索結果進行查詢。

近年來，支持高級搜索功能的密文搜索方案得到進一步發(fā)展。Xia等[15]提出了一種基于樹的多關鍵字排序搜索方案，滿足亞線性搜索時間。它是一種CKA1安全方案，會泄露訪問模式和一定量的相關性分數(shù)。方案中關鍵字字典的大小是固定的，不能動態(tài)地改變。如果將新關鍵字添加到字典中，則必須更新整個索引。文檔更新操作要求用戶存儲完整的索引以生成更新信息，并將更新信息發(fā)送給云端。Li等[16]通過預先設定各關鍵字基于通配符的模糊集合來構建模糊搜索方案。此方案是一種CKA1安全方案，允許加密索引泄露一定的編輯距離信息。它構建基于通配符的模糊集合，索引需要耗費一定的空間，且查詢需要耗費一定的時間。Kamara等[17]設計動態(tài)更新機制，但需要維護復雜的數(shù)據(jù)結構。該方案在特定的條件下是CKA2安全的，但它泄露搜索模式和訪問模式，并且在更新過程中泄露某些關鍵字出現(xiàn)在特定文檔中的信息。Boneh等[18]通過使用非對稱加密算法實現(xiàn)多用戶密文搜索（PEKS），這種方案會帶來很高的時間開銷。Liu等[19]提出了基于PEKS的密文搜索（SPKS）方案，允許云服務提供商參與部分解密，而不需要知道明文的具體內(nèi)容。

上述所有密文搜索方案都要修改當前的云端編程接口。對于每個搜索功能，CESE方案需要生成一個特定結構的索引，然后用特定算法加密索引并上傳到云端。為了搜索，用戶需要生成特定的陷門，然后云端可以使用特定的算法對加密的索引執(zhí)行特定的查詢。它們給云端應用程序帶來了額外的負擔，同時在一個加密索引上實現(xiàn)多個功能是不切實際的。BESE方案可以適用于多個云應用程序，而不需要修改云服務和用戶程序。

2.3 密鑰分享

如果數(shù)據(jù)用不同的密鑰加密，密文分享就需要相應的密鑰分享。常用的密鑰分享機制是PKE和IBE。2個知名的PKE證書驗證方案是證書吊銷列表（CRL）和在線證書狀態(tài)協(xié)議（OCSP）。但是，在撤銷大量證書的情況下，2種方案的效率都很低[20]。“Novomodo”系統(tǒng)[21]提升了效率，但它帶來第三方證書狀態(tài)查詢的問題。為了消除第三方證書狀態(tài)查詢，IBE方案是一種有效的方式。Shamir[22]提出了基于身份的加密，并引入了基于身份的簽名方案。但是，這并不是可完全實用的方案。Boneh等[23]提出了基于Weil對的可實用方案。然而，IBE本身具有私鑰托管問題：私鑰授權方可以解密用戶的密文數(shù)據(jù)。為了解決這個問題，基于證書的加密[20]和無證書公鑰加密[24]結合IBE和PKE來實現(xiàn)雙重加密，Lewko等[25]設計了一個支持多個授權方的方案。為了安全地跨代理分享密鑰，并可方便地實現(xiàn)密鑰更新，本文設計了實用的TLES方案，結合IBE和PKE各自的優(yōu)勢安全地在訪問代理間分享密鑰，并對其性能做了測試。

3 BESE方案

3.1 系統(tǒng)模型

如圖1所示，BESE方案由用戶、云服務和訪問代理3個關鍵角色組成。CESE方案中密文搜索功能由云端執(zhí)行，而BESE方案中搜索功能在訪問代理的索引服務器中執(zhí)行。云服務的用戶可對文件進行上傳、搜索、下載、分享等操作。訪問代理對用戶和云服務之間的應用層（HTTP或HTTPS）連接進行處理，以保護用戶的敏感數(shù)據(jù)。訪問代理對用戶的明文數(shù)據(jù)和文件標識符進行索引實現(xiàn)搜索功能，其中文件標識符指向云服務中的加密數(shù)據(jù)。

3.2 威脅模型

圖1 BESE和CESE系統(tǒng)模型

在本文的威脅模型中，云服務器被認為是誠實但好奇的，即遵循服務協(xié)議，但是有竊取用戶敏感數(shù)據(jù)的動機。在CESE密文搜索方案中，盡管用戶的數(shù)據(jù)已經(jīng)被加密，但云服務器也可通過分析加密數(shù)據(jù)和索引，統(tǒng)計查詢請求和結果獲得其他的敏感信息。BESE方案確保整個搜索過程以安全的方式進行，數(shù)據(jù)在被檢索的同時，向云端和攻擊者泄露盡可能少的信息。而在BESE方案中，訪問代理位于客戶端，是可被充分信任的，同時確保訪問代理內(nèi)的通道和索引服務器是安全的，不會受到外部訪問和攻擊。訪問代理以外的鏈路（包括云服務器和其他訪問代理）被認為是不受信任的，需要受到防護。敏感數(shù)據(jù)在傳遞給云端之前由訪問代理加密，從而有效防止云服務器竊取用戶私有信息。另外，即使云服務器和其他訪問代理聯(lián)系，它們也無法恢復明文，因為它們無法獲得位于用戶訪問代理中的相應密鑰。在訪問代理之外，即使用戶賬戶被攻擊者竊取，攻擊者也只能得到加密數(shù)據(jù)。如圖2所示，訪問代理主要由以下4個部分組成。

3.3 BESE系統(tǒng)架構

在BESE系統(tǒng)架構中，訪問代理是其主要組成部分，它通過分析網(wǎng)絡協(xié)議識別和加密用戶的敏感數(shù)據(jù)。

圖2 BESE架構

1) 過濾器：主要包括客戶端過濾器和服務端過濾器，用于識別特定的應用層協(xié)議。根據(jù)特征字段（URL、SNI等），調(diào)用相應的解析器邏輯。

2) 解析器：主要用于協(xié)議識別和語義分析。它通過分析請求內(nèi)容格式（如鍵值對、multi-part等）來識別敏感字段，并緩存要搜索的文件內(nèi)容。當從響應內(nèi)容中得到文件標識符（指向云端存儲的加密的文件數(shù)據(jù)）后，解析器將其與緩存的文件數(shù)據(jù)相關聯(lián)并建立可搜索的索引。

3) 加密/解密：加密模塊對敏感數(shù)據(jù)進行對稱加密，屬于同一文檔的密文數(shù)據(jù)具有相同的元數(shù)據(jù)，包括密鑰、代理、特征數(shù)據(jù)、頭長度等。特征數(shù)據(jù)是用于標識加密數(shù)據(jù)的符號串，以使解密模塊可以快速識別密文數(shù)據(jù)。解密模塊首先根據(jù)元數(shù)據(jù)中的特征數(shù)據(jù)找到密文，然后利用密鑰找到和密文對應的解密密鑰，解密得到明文數(shù)據(jù)。

4) 索引服務器/搜索器：索引服務器使用指向云端加密文件數(shù)據(jù)的文件標識符和緩存的文件數(shù)據(jù)建立搜索索引，并維護和管理索引數(shù)據(jù)。搜索器執(zhí)行搜索操作，并返回相應的文件標識符（可用于向云服務器請求加密的文件數(shù)據(jù)）。

加密、解密和搜索的執(zhí)行過程如下。

加密。①應用層文檔數(shù)據(jù)首先到達客戶端過濾器，過濾后到達解析器模塊。解析器分析請求數(shù)據(jù)并提取由加密模塊加密的敏感數(shù)據(jù)。②加密模塊首先生成一個對稱密鑰，將密鑰和密鑰存儲在數(shù)據(jù)庫中，然后用對稱密鑰加密數(shù)據(jù)并將密文有關的元數(shù)據(jù)附加到密文頭，最后它將加密的數(shù)據(jù)發(fā)送到云端。③訪問代理將加密文檔上傳到云端后，云端會返回文檔標識符。④使用緩存的文檔數(shù)據(jù)和文檔標識符，索引服務器索引數(shù)據(jù)并將其與文檔標識符相關聯(lián)。

解密。①云服務應用層數(shù)據(jù)首先到達服務端過濾器。②被過濾后，數(shù)據(jù)由解密模塊進行分析。解密模塊通過掃描特征數(shù)據(jù)來定位密文。③解密模塊根據(jù)密文元數(shù)據(jù)中的密鑰查詢數(shù)據(jù)庫獲取對應的對稱密鑰來解密數(shù)據(jù)，得到明文數(shù)據(jù)內(nèi)容，返回給用戶。

搜索。①用戶輸入關鍵字發(fā)起查詢請求。②訪問代理攔截并分析查詢請求獲取搜索關鍵字。訪問代理繼而使用搜索關鍵字向索引服務器發(fā)起搜索請求。索引服務器返回對應的文檔標識符，訪問代理將文檔標識符作為列表轉發(fā)給用戶。③此后，用戶可以根據(jù)指向云端相關加密文件的標識符選擇要下載的相關文檔。④當云端返回相關的加密文檔后，訪問代理解密并將明文數(shù)據(jù)轉發(fā)給用戶。

如上所述，訪問代理依次加密并發(fā)送上傳的文檔數(shù)據(jù)塊，而不是等待文檔的所有內(nèi)容被上傳后才進行加密并發(fā)送。在加密之前，同一文檔的數(shù)據(jù)被緩存在某一存儲結構中。當文檔的整個內(nèi)容上傳之后，云端返回指向加密文檔的文檔標識符。訪問代理使用緩存數(shù)據(jù)和文檔標識符建立本地索引，以支持加密文檔的搜索功能。算法1描述數(shù)據(jù)加密及索引建立的過程，其中，表示對稱加密方案，()表示關鍵字的倒排表，表中每個節(jié)點包含關鍵字的文檔D的文檔標識符(D)以及關鍵字在文檔D中的頻率（TF, term frequency）。逆向文檔頻率（IDF, inverse document frequency）指某關鍵字在所有文檔中出現(xiàn)的頻率，()表示關鍵字與其倒排表()之間的映射關系。

算法1 數(shù)據(jù)加密及索引建立 輸入 上傳數(shù)據(jù)文件Di，對稱密鑰k 輸出 文件Di對應的搜索索引 for 文件Di中每個上傳的數(shù)據(jù)塊M do 緩存文件Di中的數(shù)據(jù)內(nèi)容M； 利用對稱密鑰k加密M得到Ek(M)并上傳到云服務端。 文件的所有數(shù)據(jù)塊上傳完成后會從云端得到文檔標識符id(Di)；為緩存文件Di的所有數(shù)據(jù)內(nèi)容和文檔標識符id(Di)之間建立映射關系。 for 文件Di中的每個關鍵字wido if wi在字典W中 then 根據(jù)f(wj)獲取倒排表L(wj)，并將id(Di)、TF(wj, id(Di))添加到倒排表L(wj)中；更新字典W中的IDF(wj)值。 else 添加wj、IDF(wj)到字典W中；根據(jù)f(wj)初始化倒排表L(wj)，并將id(Di)、TF(wj, id(Di))添加到L(wj)中。 return 搜索索引I= (W, L)。

3.4 查詢表達能力

為了分析BESE的查詢表達能力，選擇3個具有代表性的搜索功能進行比較，即多關鍵字排序搜索、模糊搜索和動態(tài)更新。

3.4.1 多關鍵字排序搜索

圖3 BESE系統(tǒng)模型中多關鍵字排序和模糊搜索過程

在多關鍵字排序搜索中，代表文檔集合，代表包含多個關鍵字的查詢向量，正整數(shù)代表在查詢后返回具有和查詢向量最相關的個文檔。

在BESE中，索引在訪問代理中構建和搜索，而不是云服務器，故可以很方便地構建多關鍵字排序搜索方案，并可以有效地計算查詢向量與文檔的相關性分數(shù)。如圖3所示，訪問代理首先掃描文件集，構建包含所有關鍵字的字典，并計算各關鍵字出現(xiàn)在某文檔中的頻率和出現(xiàn)在所有文檔中的逆向文檔頻率值。為了對每個關鍵字進行快速搜索，訪問代理為每個關鍵字∈構建了具有長度|()|的倒排表()。算法2用于在文檔集上計算各文檔與查詢向量的相關性分數(shù)。數(shù)組保存了包含任意一個查詢詞的個文檔的分數(shù)，D,j表示(w)中的第個文檔。當?shù)玫阶罱K的個分數(shù)后，選擇具有最高分數(shù)的個文檔作為搜索結果。

算法2 BESE多關鍵字排序搜索 輸入關鍵字查詢向量Q，返回文檔數(shù)量n float Rscores[N] = 0; for each wj∈Q 獲取wj對應的IDF(wj) 和倒排表L(wj)； for 1 ≤i≤ |D(wj)|: 從倒排表L(wj)中獲取id(Di,j)和TF(wj,id(Di,j))； Rscores[id(Di,j)]+=TF(wj,id(Di,j))?IDF (wj)。 從Rscores[N]中得到與查詢最相關的n個文檔。

3.4.2 模糊搜索

與確切的關鍵字搜索不同，當關鍵字拼錯或格式有誤時，模糊搜索仍能找到近似的關鍵字并對其進行搜索。例如，原本需要檢索包含關鍵字“wood”的文檔，當將關鍵字拼寫為“woof”時仍能返回同樣正確的結果。

BESE構建的模糊搜索方案不必預先計算字典中每個關鍵字的模糊集合，可利用Levenshtein距離計算2個關鍵字的相似度。根據(jù)Levenshtein自動機[26]，對于長度為1的關鍵字1和長度為2的關鍵字2，則可以在時間復雜度(max(1,2))中判定2個關鍵字是否在編輯距離內(nèi)。使用該方案，給定一個編輯距離，如果在字典中有個不同的關鍵字，最長關鍵字的長度為，則一次模糊搜索的最大時間復雜度為()。進一步地，更快速的方法是為字典中的關鍵字構建一個關鍵字查找樹，然后可以在搜索某關鍵字時及早去除不相關的關鍵字。圖4為包含關鍵字“wood”“can”和“cash”的關鍵字查找樹。當查找與查詢詞“woof”Levenshtein距離不大于1的關鍵字時，按序測試這個樹中的字母，以確定是否需要繼續(xù)搜索。比較“ca”后，左側分支可以被去除，因為所有以“ca”開頭的關鍵字與“woof”的Levenshtein距離肯定大于1。最后，得到并搜索與“woof”的Levenshtein距離不大于1的關鍵字“wood”。

圖4 關鍵字“wood”“can”和“cash”的單詞查找樹

3.4.3 動態(tài)更新

實用的SE方案應支持密文數(shù)據(jù)的動態(tài)更新，即可以添加和刪除可搜索的加密文件。為了滿足動態(tài)更新功能，SE方案需支持向字典添加新的關鍵字的操作，并且可以對現(xiàn)有關鍵字的倒排表中的文檔標識符進行修改。

對于BESE建立的反向索引，在主索引上就地更新非常耗時[7]。如圖5所示，要快速添加新的文檔，BESE方案維護了2個索引：一個主索引和一個輔助索引。主索引存儲在磁盤中，輔助索引用于索引新文檔并保存在內(nèi)存中。當輔助索引消耗空間大于一定閾值時，它會被合并到主索引中。

圖5 BESE動態(tài)更新模型

當在BESE動態(tài)更新方案中搜索時，需要在主索引和輔助索引上分別處理搜索請求，然后合并結果。添加新文檔時，訪問代理程序中的索引服務器將為文檔構建輔助索引。刪除文檔時，將更新標識文檔被刪除的無效位向量，以表明文檔已被刪除。然后，索引服務器將在返回搜索結果之前根據(jù)無效位向量過濾掉已刪除的文檔。如果文檔內(nèi)容被更新，它將被刪除并重新插入文檔集中。

表1 性能對比

BESE方案需要索引服務器來管理索引并執(zhí)行查詢功能，并可以在反向索引結構中很好地實現(xiàn)多種搜索功能。它支持訪問代理中的多用戶交互。此外，它還可以適應多個云應用程序，而不需要修改云應用程序和用戶程序。

3.5 性能分析

Xia等[15]提出的多關鍵字排序搜索方案可實現(xiàn)亞線性搜索，但其索引建立、搜索和陷門操作均涉及矩陣運算，處理時間隨矩陣維數(shù)增加而增加。另外，用戶還需要額外的空間來存儲矩陣和索引。如果字典中關鍵字數(shù)量很大，那么計算時間會大大增加。此外，為了動態(tài)更新索引，用戶需要存儲整個明文索引。如果用戶沒有存儲索引，則需要從云中下載加密索引并解密，從而將花費更多的時間和吞吐量。而BESE使用反向索引進行搜索，可大大節(jié)省時間和空間消耗，實現(xiàn)最優(yōu)查詢效率。

Li等[16]提出的模糊搜索方案需要為文檔中的每個關鍵字創(chuàng)建一個模糊集，所以對于大型數(shù)據(jù)集，存儲開銷將顯著增加。

BESE方案不需要預先計算字典中每個關鍵字的模糊集，搜索時間的復雜度與字典中的基數(shù)和關鍵字長度有關。

Kamara等[17]提出的動態(tài)更新方案需要維護關鍵字—文檔數(shù)組和文檔—關鍵字數(shù)組，所以建立的索引將會消耗相當大的空間，以實現(xiàn)較高搜索效率和動態(tài)更新功能。在更新操作期間，需要對多個相應的指針進行同態(tài)加密操作。

BESE動態(tài)更新方案在添加或刪除文檔時不需要對主索引進行就地更新，而是建立一個小的輔助索引，從而大大減少了執(zhí)行時間。但是，添加文檔對應的臨時輔助索引會消耗一定的內(nèi)存。另外，主索引和輔助索引之間的合并過程需要消耗一定的時間。

通過以上對比可以看出，BESE方案在本地構建索引，并在訪問代理中執(zhí)行搜索操作，從而可支持多種搜索功能，且具有很高的性能。但是，BESE方案不可避免地在訪問代理中維護索引，從而為訪問代理帶來一定的空間開銷。

3.6 安全分析

常見的密文搜索方案往往允許泄露某些信息以獲得更好的性能。信息泄露情況使用泄露函數(shù)進行量化。泄露函數(shù)以一系列查詢作為輸入，并把攻擊者參與執(zhí)行搜索過程可學到的信息內(nèi)容作為輸出。一個密文搜索方案泄露的信息量取決于索引是如何構建和保存的以及如何根據(jù)陷門執(zhí)行查詢過程。

密文搜索的安全定義如下。給定一個密文搜索方案，表示一個有狀態(tài)的概率多項式時間（PPT, probabilistic polynomial-time）攻擊者，是一個有狀態(tài)的PPT模擬器，1和2是在安全游戲中有狀態(tài)的泄露函數(shù)，為安全參數(shù)。定義Real()和Ideal,S()游戲如下。

Real()：挑戰(zhàn)者根據(jù)安全參數(shù)產(chǎn)生密鑰。給定數(shù)據(jù)文件，挑戰(zhàn)者利用數(shù)據(jù)和密鑰產(chǎn)生加密索引和加密數(shù)據(jù)，并將和發(fā)送給攻擊者。然后攻擊者進行多項式數(shù)量的自適應查詢，其中，對于每個查詢對應的關鍵字，攻擊者都會從挑戰(zhàn)者處接收到關鍵字對應的搜索陷門，最后返回一個比特作為游戲的輸出。

Ideal,S()：輸出數(shù)據(jù)文件。給定1()，產(chǎn)生并發(fā)送(I,C)到。然后攻擊者進行多項式數(shù)量的自適應查詢，對于每個查詢對應的關鍵字，模擬器接收2(,)并返回對應的陷門TD。最后，返回一個比特作為游戲的輸出。

如果對于任意PPT攻擊者，任意多項式和足夠大的，存在一個PPT模擬器，滿足以下條件。

則密文搜索方案對于自適應攻擊CKA2是(1,2)安全的。用同樣的方法可定義密文搜索方案對于非自適應攻擊CKA1是(1,2)安全的，但必須在游戲開始時就已經(jīng)選好了所有的查詢，即用戶的查詢獨立于搜索索引和以前的查詢結果。

1)1安全性：在BESE中，由于數(shù)據(jù)通過安全強度高的對稱加密方式加密，故攻擊者很難從密文中獲取額外的信息。由于索引是在訪問代理處產(chǎn)生和保存的，故攻擊者無法獲得索引，從而保證了索引的安全性，使攻擊者無法獲得更多的信息。

2)2安全性：在搜索過程中，查詢關鍵字交給訪問代理，并在訪問代理中執(zhí)行查詢，從而向云端隱藏了搜索模式。當執(zhí)行查詢獲得搜索結果（文檔標識符列表）后，用戶向云服務器發(fā)送其他請求以檢索特定文檔。這些請求可以嵌入其他的檢索中，從而混淆搜索請求和密文檢索請求之間的相關性，使云服務器不能得出一次查詢請求對應于哪些文件，從而在一定程度上向云端隱藏了訪問模式。

參考文獻[27-28]，如果攻擊者擁有加密文件的先驗知識，泄露搜索模式或訪問模式可能會泄露更多關于查詢或文檔的信息。而在BESE方案中，查詢過程在一定程度上隱藏了搜索模式和訪問模式，所以即使攻擊者擁有加密文件對應的所有明文，也不能推理得到查詢對應的關鍵字。

基于上述分析和比較可以看出，對于云應用程序，BESE方案比CESE方案更有優(yōu)勢。然而，BESE方案中仍然存在著諸多挑戰(zhàn)，且這些挑戰(zhàn)在大多數(shù)基于CASB的解決方案中沒有被提及和解決。

4 不同代理間索引的分享

在BESE方案中，與用戶相關的搜索索引位于其訪問代理內(nèi)，用戶如何跨代理搜索是需要解決的第一個問題?？紤]2種情況：1) 如果用戶僅在另一個代理中暫時進行搜索，則查詢請求可轉發(fā)給其原始代理，由原始代理處理該請求并返回文件標識符，查詢關鍵字和搜索結果使用代理之間共享的密鑰進行加密，以確保安全性；2) 如果用戶永久切換到另一個代理，則必須設計一個有效的方案將用戶相關的索引從原始代理遷移到現(xiàn)在所在的代理。以下部分將重點介紹此場景。

大多數(shù)以CASB為基礎的方案均未涉及不同訪問代理間索引遷移的問題，因此迫切需要一種將用戶相關索引從一個代理傳輸?shù)搅硪粋€代理的有效方式。在BESE方案中，屬于不同代理的索引服務器沒有連接。此外，索引組織與物理架構密切相關，因此，難以在不同索引服務器之間直接遷移索引。BESE采用的方法是在索引服務器中保留索引的源數(shù)據(jù)，然后對其進行過濾，并在另一個索引服務器中重新建立索引。此方案引入控制節(jié)點來協(xié)調(diào)傳輸過程，這里，源數(shù)據(jù)是一種JSON格式的結構化數(shù)據(jù)，根據(jù)原始文件內(nèi)容和用戶屬性生成，適用于建立索引。不同代理間索引的分享如圖6所示。如果原來在代理A的用戶遷移到代理B下工作，那么需要將用戶的索引從代理A傳送到代理B，過程如下所示。

1) 用戶使用用戶向代理B執(zhí)行身份驗證。

2)~4) 代理B檢查它是否包含與用戶相關的索引；如果沒有，則從控制節(jié)點請求用戶的索引。

5) 控制節(jié)點查詢哪個代理與用戶相關聯(lián)，并查詢到代理A。然后，控制節(jié)點使用用戶向代理A請求索引?？刂乒?jié)點最后更新用戶和代理之間的對應關系。

6) 代理A從控制節(jié)點接收與用戶相關索引的請求。

7)~9) 代理A首先向索引服務器發(fā)送請求，以過濾與用戶相關的索引源數(shù)據(jù)。

10)~11) 代理A使用代理之間共享的對稱密鑰加密源數(shù)據(jù)并將其轉發(fā)給代理B。之后，代理A刪除用戶的索引和相關信息。

圖6 不同代理間索引的分享

12)~15) 代理B接收加密數(shù)據(jù)，提取用戶的源數(shù)據(jù)，然后重新索引源數(shù)據(jù)。之后，用戶可以在代理B下進行搜索。

由于代理之間使用共享的對稱密鑰通過對稱加密方式加密索引，故可保證索引分享的安全性，使沒有密鑰的攻擊者難以破解密文得到明文索引。不同代理間的密鑰分享機制將在第5節(jié)介紹。當索引源數(shù)據(jù)的量很大時，此方案將導致一定的存儲和傳輸開銷。優(yōu)化方法按時間過濾并傳輸索引源數(shù)據(jù)，如最近2個月的索引數(shù)據(jù)。

5 不同代理間密鑰的分享

數(shù)據(jù)在訪問代理處加密，即秘密密鑰在訪問代理中，所以只有訪問代理可以解密加密的數(shù)據(jù)。如果在代理A中的用戶A想要與另一個代理B下的用戶B分享一個文件，當用戶B從云端接收加密的文件后，無法解密文件，因為它是被代理A加密的。因此如何在不同代理之間分享用于解密數(shù)據(jù)的密鑰是密文分享需要解決的問題。

秘密密鑰必須在代理間安全地共享。為此，PKE方案[21]可有效保證密鑰的安全傳輸。但為了證明證書的合法性，PKE方案為證書設置了有效期。當證書過期或撤銷大量證書時，PKE方案效率低下，且會導致很多查詢證書狀態(tài)的請求。IBE方案[23]可有效解決證書驗證問題，但其具有私鑰托管問題，即私鑰生成器（PKG）可以解密用戶通過IBE加密的數(shù)據(jù)。BESE結合IBE和PKE實現(xiàn)雙層加密方案（TLES, two-layer encryption scheme），采用其各自的優(yōu)勢彌補各自的不足，保證密鑰在代理之間安全傳輸。最后，本文設計了一個可實用的TLES原型系統(tǒng)并測試了其性能。

為了實現(xiàn)TLES，BESE方案使用控制節(jié)點充當IBE方案的PKG。當訪問代理被初始化后，它使用自己的PKE公鑰—私鑰對及其身份向控制節(jié)點進行身份驗證。認證后，控制節(jié)點發(fā)出與身份相對應的IBE私鑰。控制節(jié)點還負責初始化和更新訪問代理基本信息，如訪問代理、訪問代理公鑰、密鑰等。

令I表示IBE公鑰，I表示IBE私鑰，P表示PKE公鑰，P表示PKE私鑰。如圖7所示，不同訪問代理之間的密鑰分享過程如下。

1)~3) 代理B從云端接收代理A加密的數(shù)據(jù)。

4) 代理B將密文元數(shù)據(jù)上傳到控制節(jié)點以請求解密密鑰。

5)~7) 控制節(jié)點獲取密文元數(shù)據(jù)，根據(jù)元數(shù)據(jù)中的代理查找到代理A，然后從代理A請求對應的密鑰。請求參數(shù)包括密鑰、代理B的時間參數(shù)B、代理B的身份B、代理B的PKE公鑰P-B。

8)~10) 代理A根據(jù)參數(shù)B、B得到I-B，并結合P-B雙重加密相應密鑰，將加密密鑰轉發(fā)給代理B。

11) 代理B使用IBE私鑰I-B和PKE私鑰P-B來解密接收到的消息并獲得相應的密鑰。

12) 代理B用解密密鑰解密密文以獲得明文。

為了描述密鑰產(chǎn)生分配的具體過程，給出以下數(shù)學化定義。{0, 1}表示所有有限的字符串的集合。{0,1}表示所有位字符串的集合。Z表示模為的加法群{0,1,,1}。Z=Z{}表示Z中除去單位元的集合。TLES方案使用雙線性對來構建。雙線性對的定義如下。

假設1和2是2個階為大素數(shù)的循環(huán)群。1是在有限域F上某一橢圓曲線上的點群，2是有限域F的子群，其中2。如果對于任意,∈1和任意,∈，映射(,)(,)，則映射:1×1→2被認為是雙線性的。

圖7 不同代理間密文數(shù)據(jù)的分享

根據(jù)文獻[21,23]中的安全性分析，TLES方案各模塊描述如下。

初始化：控制節(jié)點生成系統(tǒng)參數(shù),,,pub,,和主密鑰IBE，是公開的，可由各代理獲取。詳細過程如下。

2) 隨機選擇IBE使IBE∈Z，使pubIBE。

私鑰簽發(fā)：對于表征代理身份的字符串和時間參數(shù)，使用如下步驟生成私鑰。

2) 使IBEQ，其中IBE為主密鑰。控制節(jié)點使用代理的PKE公鑰加密私鑰，并將其轉發(fā)給代理。代理解密得到私鑰。

加密：使用和B加密∈{0,1}。

1) 將和連接并映射到點Q。

2) 從Z中隨機選擇。

解密。代理使用PKE私鑰和IBE私鑰解密密文獲得明文。

在TLES方案密鑰傳輸過程中，密鑰是被雙層加密傳輸?shù)?。即使控制?jié)點具有代理的IBE私鑰，也不能解密密文獲得密鑰，因為它不具有代理的PKE私鑰。如果一個代理被攻擊者替換了PKE公鑰，攻擊者具有了相應的PKE私鑰，但是沒有IBE對應的私鑰，因此攻擊者無法解密密文獲得密鑰。以上密鑰傳輸過程中，系統(tǒng)參數(shù)選擇、密鑰生成和加密過程等均遵循安全的IBE加密方案[23]和PKE加密方案[21]，可保證密鑰僅被發(fā)送方代理和接收方代理獲得，而控制節(jié)點和其他代理等攻擊者均無法破解雙重加密的密文以獲取密鑰。如上所述，TLES方案有效地確保了密鑰的安全傳輸，只有與匹配的代理可以獲得密鑰。利用時間參數(shù)，可以有效地更新代理的IBE私鑰以提高安全性。

6 實驗分析

實驗分析的主要內(nèi)容和目的包括各種云應用程序中訪問代理引入的額外開銷、不同代理之間的索引遷移以及密鑰分享的效率。

6.1 實驗設置

搭建一個原型系統(tǒng)來測試所提出的BESE方案的有效性和性能。所用的虛擬機的配置包括英特爾2.5 GHz雙核，內(nèi)存為4 GB，上行速度約為1 000 KB/s，下行速度約為7 500 KB/s。訪問代理仲裁用戶和云服務器之間的應用層連接，以保護用戶的私有數(shù)據(jù)。

對于索引構建、搜索和分享方案，集成常用的開源搜索引擎如Elastic Search來構建索引服務器。當需要將索引從一個代理遷移到另一個代理時，源代理首先從索引服務器遷移索引源數(shù)據(jù)，并將加密的源數(shù)據(jù)傳輸?shù)搅硪粋€代理，另一個代理使用Nginx反向代理來接收數(shù)據(jù)并對其進行解密得到源數(shù)據(jù)，然后將其轉發(fā)到索引服務器以重新建立索引。TLES借助OpenSSL庫和PBC庫實現(xiàn)。

6.2 案例研究

針對處理文本數(shù)據(jù)、文件數(shù)據(jù)或其他格式的數(shù)據(jù)，選擇3類真實云應用程序來測試BESE方案，包括電子郵件（QQ、163等）、網(wǎng)絡硬盤（百度網(wǎng)盤等）和企業(yè)資源規(guī)劃（ERP, enterprise resource planning）系統(tǒng)。實驗結果表明，BESE方案不影響電子郵件的正常功能。在網(wǎng)絡硬盤服務中，用戶無法對上傳的加密文件（如圖像和視頻）使用預覽功能。BESE還支持ERP服務，缺點是服務器無法計算加密的數(shù)字數(shù)據(jù)，這將在未來的工作中得到解決。

6.3 性能測試

首先，選擇一個典型的網(wǎng)絡電子郵件服務——騰訊QQ郵件作為測試程序。為了測試訪問代理引入的額外開銷，主要通過對比打開代理服務和沒有打開代理服務2種情況下發(fā)送和接收不同大小的電子郵件的時間開銷。如圖8所示，broker、解析、加密和元數(shù)據(jù)表示打開代理服務的數(shù)據(jù)傳輸和處理的時間，而normal表示沒有打開代理服務的數(shù)據(jù)傳輸和處理的時間。

圖8 發(fā)送QQ郵件

從圖8可以得出結論，代理在發(fā)送低于200 KB的電子郵件正文的情況下，平均增加15%的額外開銷。額外的開銷包括解析、加密、元數(shù)據(jù)和數(shù)據(jù)傳輸及處理所耗費的時間。在額外的開銷中，加密操作（包括密鑰生成、加密以及形成包含加密數(shù)據(jù)的新請求體）比解析或元數(shù)據(jù)操作花費更多的時間。另外，根據(jù)圖9的測試結果，在代理中處理接收到的加密郵件僅僅帶來平均10%的額外開銷，其中，解密操作比解析操作消耗更多的時間。

圖9 接收QQ郵件

為了測試文件加密，在百度網(wǎng)絡磁盤中發(fā)送和接收5種類型的文件：256 B文本、360 KB圖像、4.6 MB和10.3 MB文檔以及32.1 MB可執(zhí)行程序。測試結果如圖10所示。broker、緩存、加密和元數(shù)據(jù)表示打開代理服務的數(shù)據(jù)傳輸和處理的時間，而normal表示沒有打開代理服務的數(shù)據(jù)傳輸和處理的時間。緩存操作存儲原始數(shù)據(jù)以構建本地索引。從圖10可以看出，代理在發(fā)送文件時僅帶來2.5%~4.5%的額外成本，因為代理可以分別加密和發(fā)送大文件的各數(shù)據(jù)塊，而不是等到文件上傳完所有內(nèi)容后發(fā)送。圖11顯示接收加密文件時，代理帶來少于1％的額外開銷。綜上所述，代理加密或解密文件帶來的額外開銷較小。

使用基準框架Rally來評估BESE方案中索引的搜索效率，如表2所示。隨著文件集合大小和數(shù)量的增加，索引存儲空間增長和搜索性能下降都很緩慢。即使是大文件集合（如2.2 GB），索引僅占用1.7 GB的空間，查詢性能可達到每秒11次。

圖10 在百度網(wǎng)盤中上傳文件

圖11 在百度網(wǎng)盤中下載文件

表2 搜索性能評估

如果用戶在另一個代理中注冊，則相應地，需要將原始代理中用戶的相關索引傳送到另一個代理中。如圖12所示，對于不同大小的索引，測試了2個代理之間索引遷移的性能。實線表示將索引數(shù)據(jù)從一個代理遷移到另一個代理的總時間，包括導出所有索引源數(shù)據(jù)的時間、索引數(shù)據(jù)加密和傳輸時間以及數(shù)據(jù)解密和重新索引時間。虛線僅表示導出所有索引源數(shù)據(jù)的時間。實驗結果表明，索引遷移所消耗的總時間與索引大小成正比。隨著索引大小的增加，導出索引源數(shù)據(jù)的時間沒有太大變化，源數(shù)據(jù)重新索引占用更多的時間。

圖12 不同代理索引遷移開銷

在密鑰分享場景下，代理和控制節(jié)點之間的通信主要由套接字傳輸完成。使用OpenSSL庫生成4096位的PKE密鑰對，調(diào)用PBC庫生成IBE方案的雙線性對。TLES各個過程（包括系統(tǒng)參數(shù)生成、私鑰簽發(fā)、數(shù)據(jù)加密和數(shù)據(jù)解密）的性能測試如表3所示。從測試結果看出，解密時間要比加密時間長?？偟膩碚f，TLES方案引入的開銷是毫秒級的，對于用戶體驗來說是微不足道的。

表3 TLES各過程性能測試

7 結束語

本文首先提出了訪問代理執(zhí)行的密文搜索方案BESE，并分析其效率性和安全性。針對實際云應用程序的實驗進一步表明，BESE方案確實引入很低的開銷。為了實現(xiàn)密文搜索，BESE方案使用加密文件的標識符在訪問代理中建立搜索索引。為了在代理之間進行搜索，它實現(xiàn)了代理之間的索引分享方案。但是，當用戶從一個代理遷移到另一個代理時，用戶的原始代理仍然可以保留用戶的密鑰和索引。如果原始代理獲得與密鑰相關聯(lián)的加密數(shù)據(jù)，則仍然可以對其進行解密。這個問題將在未來的研究中利用數(shù)據(jù)重加密技術解決。為了在不同代理之間共享加密數(shù)據(jù)，提出了2層加密方案TLES來傳輸密鑰。當然，BESE仍然面臨諸多技術挑戰(zhàn)，需要進一步的研究和改進。例如，由于應用程序種類繁多，BESE需要自動匹配更多協(xié)議并構建數(shù)據(jù)索引以供搜索。另外，為了提升大數(shù)據(jù)量索引遷移的性能，需要進一步優(yōu)化索引分享方案。

[1] Cloud Security Alliance, Top Threats Working Group. CSA’s cloud computing top threats in 2016[R]. 2016.

[2] It’s all about identity theft - first half findings from the 2016 breach level index[R]. 2016.

[3] 王國峰, 劉川意, 潘鶴中, 等. 云計算模式內(nèi)部威脅綜述[J]. 計算機學報, WANG G F, LIU C Y, PAN H Z, et al. Survey on insider threats to cloud computing[J]. Chinese Journal of Computers, 2017, 40(2): 296-316.

[4] GOLDREICH O, OSTROVSKY R. Software protection and simulation on oblivious RAMs[J]. Journal of the ACM, 1996, 43(3): 431-473.

[5] B?SCH C, HARTEL P, JONKER W, et al. A survey of provably secure searchable encryption[J]. ACM Computing Surveys (CSUR), 2015, 47(2): 18.

[6] Gartner report: how to evaluate and operate a cloud access security broker[R]. 2015.

[7] SCHüTZE H. Introduction to information retrieval[C]//International Communication of Association for Computing Machinery Conference. 2008.

[8] HE W, AKHAWE D, JAIN S, et al. Shadowcrypt: encrypted Web applications for everyone[C]//The 2014 ACM SIGSAC Conference on Computer and Communications Security. 2014: 1028-1039.

[9] LAU B, CHUNG S, SONG C, et al. Mimesis aegis: a mimicry privacy shield–a system’s approach to data privacy on public cloud[C]//23rd USENIX Security Symposium (USENIX Security 14). 2014: 33-48.

[10] POPA R A, STARK E, VALDEZ S, et al. Building Web applications on top of encrypted data using Mylar[C]//11th USENIX Symposium on Networked Systems Design and Implementation (NSDI 14). 2014: 157-172.

[11] POPA R A, REDFIELD C, ZELDOVICH N, et al. CryptDB: protecting confidentiality with encrypted query processing[C]//The Twenty-Third ACM Symposium on Operating Systems Principles. 2011: 85-100.

[12] SONG D X, WAGNER D, PERRIG A. Practical techniques for searches on encrypted data[C]// 2000 IEEE Symposium on Security and Privacy. 2000: 44-55.

[13] GOH E J. Secure indexes[J]. International Association for Cryptologic Research Cryptology ePrint Archive, 2003: 216.

[14] CURTMOLA R, GARAY J, KAMARA S, et al. Searchable symmetric encryption: improved definitions and efficient constructions[J]. Journal of Computer Security, 2011, 19(5): 895-934.

[15] XIA Z, WANG X, SUN X, et al. A secure and dynamic multi-keyword ranked search scheme over encrypted cloud data[J]. IEEE Transactions on Parallel and Distributed Systems. 2016, 27(2): 340-352.

[16] LI J, WANG Q, WANG C, et al. Fuzzy keyword search over encrypted data in cloud computing[C]//INFOCOM. 2010: 1-5.

[17] KAMARA S, PAPAMANTHOU C, ROEDER T. Dynamic searchable symmetric encryption[C]// The 2012 ACM Conference on Computer and Communications Security. 2012: 965-976.

[18] BONEH D, CRESCENZO G D, OSTROVSKY R, et al. Public key encryption with keyword search[C]//International Conference on the Theory and Applications of Cryptographic Techniques. 2004:506-522.

[19] LIU Q, WANG G, WU J. Secure and privacy preserving keyword searching for cloud storage services[J]. Journal of Network and Computer Applications, 2012, 35(3):927-933.

[20] GENTRY C. Certificate-based encryption and the certificate revocation problem[C]//International Conference on the Theory and Applications of Cryptographic Techniques. 2003: 272-293.

[21] MICALI S. Scalable certificate validation and simplified pki management[C]//1st Annual PKI Research Workshop. 2002:15.

[22] SHAMIR A. Identity-based cryptosystems and signature schemes[C]// Workshop on the Theory and Application of Cryptographic Techniques. 1984: 47-53.

[23] BONEH D, FRANKLIN M. Identity-based encryption from the Weil pairing[C]//Annual International Cryptology Conference. 2001: 213-229.

[24] AL-RIYAMI S S, PATERSON K G. Certificateless public key cryptography[C]//International Conference on the Theory and Application of Cryptology and Information Security. 2003: 452-473.

[25] LEWKO A, WATERS B. Decentralizing attribute-based encryption[C]//Annual International Conference on the Theory and Applications of Cryptographic Techniques. 2011: 568-588.

[26] SCHULZ K U, MIHOV S. Fast string correction with Levenshtein automata[J]. International Journal on Document Analysis and Recognition, 2002, 5(1): 67-85.

[27] ISLAM M S, KUZU M, KANTARCIOGLU M. Access pattern disclosure on searchable encryption: ramification, attack and mitigation[C]//NDSS. 2012: 12.

[28] CASH D, GRUBBS P, PERRY J, et al. Leakage-abuse attacks against searchable encryption[C]// The 22nd ACM SIGSAC Conference on Computer and Communications Security. 2015: 668-679.

Research on technology of data encryption and search based on access broker

WANG Guofeng1, LIU Chuanyi2, HAN Peiyi1, PAN Hezhong1, FANG Binxing2

1. College of Cyberspace Security, Beijing University of Posts and Telecommunications, Beijing 100876, China 2. S chool of Computer Science and Technology, Harbin Institute of Technology (Shenzhen), Shenzhen 518055, China

Broker executed searchable encryption (BESE) scheme was proposed for the confidentiality issues of cloud application data. The scheme did not need to modify the cloud application or user habits, thus had strong applicability. Firstly, systematic and quantitative analysis on BESE scheme was conducted in terms of query expressiveness, performance and security. Then, the main challenges of BESE scheme including securely sharing index and encrypted data between brokers were pointed out, and corresponding schemes were proposed to address the above challenges. The experimental results show that the BESE scheme can effectively protect the user data in the cloud, achieve a variety of search functions, and has high efficiency and security.

cloud security, data protection, searchable encryption, encrypted data sharing

國家高技術研究發(fā)展計劃（“863”計劃）基金資助項目（No.2015AA016001）；國家重點研發(fā)計劃基金資助項目（No.2017YFB0801801）；國家科技重大專項基金資助項目（No.BB29100002）；國家科研發(fā)展咨詢基金資助項目（No.BA25500031, No.BB25500019）

The National High Technology Research and Development Program of China (863 Program) (No. 2015AA016001), The National Key Research and Development Program of China (No.2017YFB0801801), The National Science and Technology Major Project of China (No.BB29100002), The National Research Development Consulting Project (No.BA25500031, No. BB25500019)

TP302

A

2017?09?25；

2018?04?28

劉川意，cy-liu04@mails.tsinghua.edu.cn

10.11959/j.issn.1000?436x.2018114

王國峰（1988?），男，山東濟寧人，北京郵電大學博士生，主要研究方向為數(shù)據(jù)安全、云計算與云安全。

劉川意（1982?），男，四川樂山人，哈爾濱工業(yè)大學（深圳）副教授，主要研究方向為云計算與云安全、大規(guī)模存儲系統(tǒng)、數(shù)據(jù)保護與數(shù)據(jù)安全。

韓培義（1992?），男，山西呂梁人，北京郵電大學博士生，主要研究方向為數(shù)據(jù)安全、云安全。

潘鶴中（1991?），男，遼寧本溪人，北京郵電大學博士生，主要研究方向為數(shù)據(jù)安全、云安全。

方濱興（1960?），男，江西上饒人，中國工程院院士，哈爾濱工業(yè)大學（深圳）教授，主要研究方向為網(wǎng)絡與信息安全、內(nèi)容安全。