張曉均，劉 慶，鄭 爽，王 鑫，薛婧婷，王世雄

（1.西南石油大學(xué) 計算機科學(xué)學(xué)院 網(wǎng)絡(luò)空間安全研究中心，成都 610500；2.軍事科學(xué)院，北京 100091）

0 概述

隨著移動互聯(lián)網(wǎng)行業(yè)的飛速發(fā)展，用戶需要存儲的數(shù)據(jù)量呈爆炸式增長，為降低本地數(shù)據(jù)的管理成本，將數(shù)據(jù)外包到云已成為普遍趨勢［1-3］。由于數(shù)據(jù)對云及訪問云存儲的用戶是可見的，因此也給用戶帶來了數(shù)據(jù)隱私和安全等重要問題［4-6］。為防止云用戶敏感數(shù)據(jù)的泄露，在外包之前需要對數(shù)據(jù)進行加密，然而加密會破壞數(shù)據(jù)的原始結(jié)構(gòu)，這將限制對加密數(shù)據(jù)進行特定檢索的靈活性［7］，難以滿足移動智能終端應(yīng)用的輕量級要求。為保證云上密文數(shù)據(jù)的有效共享，提高數(shù)據(jù)檢索精度和效率，亟須設(shè)計一種既能保證數(shù)據(jù)隱私又能提高檢索正確性的可搜索加密數(shù)據(jù)共享方案。

現(xiàn)有的可搜索加密技術(shù)分為對稱可搜索加密（SSE）和公鑰可搜索加密（SPKE）兩類。在SSE 方案中，數(shù)據(jù)發(fā)送方和數(shù)據(jù)接收方通過共享同一個密鑰對密文文件之間關(guān)聯(lián)的關(guān)鍵詞和搜索陷門進行加密并執(zhí)行加密查詢。最早的SSE 方案由SONG 等［8］提出，其采用順序掃描的方式進行關(guān)鍵詞匹配，搜索時間與文檔長度呈線性關(guān)系。近年來，一些可以保證前后向安全性［9-10］、防止文件注入攻擊［11］等滿足更高安全性的SSE 方案相繼被提出，但也在存儲空間和計算復(fù)雜度上有了更大的開銷。SPKE 方案使用數(shù)據(jù)接收方的私鑰生成搜索陷門和使用對應(yīng)的公鑰生成加密文件的關(guān)鍵詞密文來進行加密查詢。最早的SPKE 方案由BONEH 等［12］提出，即支持單關(guān)鍵字搜索的公鑰加密方案（PEKS）。在PEKS 中，用戶需要通過安全信道將陷門傳到云服務(wù)器進行匹配搜索，安全性和效率還有待提高。隨后，文獻［13］結(jié)合SM9 密碼算法構(gòu)造了基于身份的可搜索加密方案，使用系統(tǒng)參數(shù)相對較小的非對稱雙線性運算提高了計算速度和安全效率，但無法使用戶之間的身份得到驗證。文獻［14］提出一種適用于移動設(shè)備的輕量級公鑰認證加密方案，該方案允許對手自適應(yīng)選擇攻擊目標，但沒有對服務(wù)器返回的密文數(shù)據(jù)進行完整性校驗。文獻［15］提出一種支持隱私保護的可搜索加密方案，其可對基于屬性的加密數(shù)據(jù)提供關(guān)鍵字搜索，并具有隱藏的訪問策略，但搜索計算開銷與系統(tǒng)中存在的屬性數(shù)量成線性關(guān)系。文獻［16］設(shè)計了一種用于IIoT 環(huán)境的無證書可搜索公鑰加密方案，但該方案存在離線關(guān)鍵詞猜測攻擊的風(fēng)險［17］。

SPKE 自提出以來在許多場景中得到了成功應(yīng)用，如加密數(shù)據(jù)過濾［18］、物聯(lián)網(wǎng)數(shù)據(jù)保護［19］等。然而，雖然SPKE 在安全性、密鑰管理和數(shù)據(jù)共享的靈活性方面較SSE 有一定優(yōu)勢，但部署到云上時容易受到各種攻擊，如關(guān)鍵詞猜測攻擊（KGA）。離線的KGA 可分為外部攻擊者在云服務(wù)管理之外發(fā)起的KGA 和云服務(wù)管理內(nèi)部攻擊者發(fā)起的內(nèi)部KGA［20］。目前，研究者［21-23］已經(jīng)提出了一些抵抗外部KGA 的方案，一類在接收者和云服務(wù)器之間建立一條安全信道，另一類是限制未經(jīng)授權(quán)的攻擊者進行測試。與抵抗外部KGA 相比，抵抗內(nèi)部KGA 會更加困難，因為用于關(guān)鍵詞測試的云服務(wù)器是“誠實而好奇”的，它可以在正常運行測試算法并返回給用戶的同時猜測出關(guān)鍵詞，內(nèi)部攻擊者很難被發(fā)現(xiàn)。因此，設(shè)計一種實用有效的方案來解決SPKE 中的內(nèi)部/外部KGA 問題是一項具有挑戰(zhàn)的任務(wù)。

本文提出一種云存儲系統(tǒng)中支持隱私保護的可驗證數(shù)據(jù)分享方案DSS-SPP-CSS。結(jié)合橢圓曲線上的加密算法和消息認證碼技術(shù)設(shè)計關(guān)鍵詞索引生成算法和搜索陷門生成算法，同時設(shè)計具有同態(tài)特性的密文數(shù)據(jù)簽名生成算法，驗證用戶所接收加密數(shù)據(jù)的完整性。在此基礎(chǔ)上，根據(jù)可證明安全理論，驗證本文方案在選擇關(guān)鍵詞攻擊下滿足密文不可區(qū)分性和搜索陷門不可區(qū)分性。

1 系統(tǒng)模型與工作流程

1.1 系統(tǒng)模型

本文方案系統(tǒng)模型如圖1 所示，其由可信中心、云服務(wù)器、數(shù)據(jù)發(fā)送方、數(shù)據(jù)接收方等4個不同的實體組成。

圖1 本文方案系統(tǒng)模型Fig.1 System model of the proposed scheme

1）可信中心：可信的權(quán)威認證機構(gòu)，主要負責設(shè)置系統(tǒng)的公共參數(shù)。

2）數(shù)據(jù)發(fā)送方：作為數(shù)據(jù)擁有者，在數(shù)據(jù)外包至云服務(wù)器之前對數(shù)據(jù)及其關(guān)鍵詞進行加密，同時產(chǎn)生加密文件對應(yīng)的文件名和同態(tài)數(shù)字簽名，共同上傳至云服務(wù)器進行存儲。

3）數(shù)據(jù)接收方：作為數(shù)據(jù)使用者，根據(jù)搜索的關(guān)鍵詞生成搜索陷門，將其發(fā)送至云服務(wù)器進行檢索，并根據(jù)云服務(wù)器返回的檢索結(jié)果驗證密文數(shù)據(jù)的完整性。

4）云服務(wù)器：云服務(wù)器存儲數(shù)據(jù)發(fā)送方上傳的關(guān)鍵詞索引、數(shù)據(jù)文件密文及其文件名和數(shù)字簽名，并為數(shù)據(jù)接收方提供基于關(guān)鍵詞的密文搜索服務(wù)。當數(shù)據(jù)接收方向云服務(wù)器發(fā)送搜索陷門時，它會快速執(zhí)行搜索與測試并返回對應(yīng)的加密文件給數(shù)據(jù)接收方；同時，為確保云存儲密文數(shù)據(jù)的完整性，云服務(wù)器基于數(shù)據(jù)接收方的挑戰(zhàn)信息，產(chǎn)生完整性驗證證明信息并返回給數(shù)據(jù)接收方。

1.2 工作流程

本文方案工作流程如圖2 所示，其中包括系統(tǒng)初始化、密鑰生成、加密與簽名產(chǎn)生、搜索陷門生成、云服務(wù)器搜索測試、完整性驗證等6 個步驟。

圖2 本文方案工作流程Fig.2 Workflow of the proposed scheme

1）系統(tǒng)初始化（SystemInit）：可信中心以安全參數(shù)λ為輸入，設(shè)置基于橢圓曲線的循環(huán)群的相關(guān)參數(shù)、抗碰撞哈希函數(shù)，并選擇消息認證碼等系統(tǒng)參數(shù)，將以上參數(shù)作為全局參數(shù)Ω公開。

2）密鑰生成（KeyGen）：以全局參數(shù)Ω作為輸入，數(shù)據(jù)發(fā)送方和數(shù)據(jù)接收方分別計算對應(yīng)的公私鑰對（vs，qs）和(vr，qr)。

3）加密與簽名產(chǎn)生（Encrypt-Sign）：數(shù)據(jù)發(fā)送方選擇通用的加密算法生成加密文件集合Λ={c1，c2，…，cm}，并產(chǎn)生加密文件對應(yīng)的文件名Δ={N1，N2，…，Nm}和同態(tài)簽名集合Σ={σ1，σ2，…，σm}，然后以全局參數(shù)Ω、數(shù)據(jù)發(fā)送方私鑰vs、數(shù)據(jù)接收方公鑰qr和關(guān)鍵詞ω作為輸入，輸出關(guān)鍵詞對應(yīng)的密文C，最后將(Λ，D，Σ，C)上傳至云服務(wù)器進行存儲。

4）搜索陷門生成（Trapdoor）：以全局參數(shù)Ω、數(shù)據(jù)接收方私鑰vr、數(shù)據(jù)發(fā)送方公鑰qs和關(guān)鍵詞ω'作為輸入，數(shù)據(jù)接收方輸出與關(guān)鍵詞關(guān)聯(lián)的搜索陷門Tω'，并產(chǎn)生完整性驗證挑戰(zhàn)信息，上傳至云服務(wù)器進行搜索。

5）云服務(wù)器搜索測試（Test）：云服務(wù)器根據(jù)全局參數(shù)Ω、關(guān)鍵詞密文C和搜索陷門Tω'進行搜索測試，若搜索陷門與關(guān)鍵詞密文匹配成功，則返回對應(yīng)的數(shù)據(jù)加密文件，并根據(jù)挑戰(zhàn)信息產(chǎn)生完整性驗證證明信息，發(fā)送給數(shù)據(jù)接收方。

6）完整性驗證（Verify）：完整性驗證是為了防止云服務(wù)提供商返回不誠實的反饋信息同時減少用戶的本地計算開銷，在數(shù)據(jù)接收方接收數(shù)據(jù)之前根據(jù)云服務(wù)器返回的完整性驗證證明信息對加密文件的搜索結(jié)果進行完整性驗證。此步驟以全局參數(shù)Ω為輸入，云服務(wù)器基于數(shù)據(jù)接收方的挑戰(zhàn)信息chal、加密文件ci和對應(yīng)的文件名Ni以及同態(tài)簽名(σi，Ri)產(chǎn)生完整性驗證證明信息(c，N，σ，R)返回給數(shù)據(jù)接收方，用于對云端加密數(shù)據(jù)的完整性驗證。

2 方案設(shè)計

本文方案中包含系統(tǒng)初始化（SystemInit）、密鑰生成（KeyGen）、加密與簽名產(chǎn)生（Encrypt-Sign）、搜索陷門生成（Trapdoor）、云服務(wù)器搜索測試（Test）、完整性驗證測試（Verify）等6 個多項式時間算法。

1）系統(tǒng)初始化（SystemInit）算法：首先選取一個安全參數(shù)λ作為輸入，然后按以下步驟生成全局系統(tǒng)參數(shù)。

3）加密與簽名產(chǎn)生（Encrypt-Sign）算法：在此算法中，數(shù)據(jù)發(fā)送方需要提取原始數(shù)據(jù)文件的關(guān)鍵詞，并產(chǎn)生對應(yīng)的關(guān)鍵詞密文，同時數(shù)據(jù)發(fā)送方需要生成原始文件密文及其對應(yīng)的同態(tài)數(shù)字簽名。

最后，數(shù)據(jù)發(fā)送方將每一個數(shù)據(jù)文件fi，i=1，2，…，m對應(yīng)的加密數(shù)據(jù)文件ci、關(guān)鍵詞密文C以及加密文件的同態(tài)數(shù)字簽名(σi，Ri)一起發(fā)送給云服務(wù)器。

4）搜索陷門生成（Trapdoor）算法：數(shù)據(jù)接收方選取目標關(guān)鍵詞ω'，利用自身私鑰vr=(vr，1，vr，2)及數(shù)據(jù)發(fā)送方的公鑰分量qs，1計算關(guān)鍵詞的搜索陷門Tω'=·MACd*(ω')，其 中d*=H1(xr·qs，1)，并將搜 索陷門Tω'發(fā)送給云服務(wù)器。

5）云服務(wù)器搜索測試（Test）算法：云服務(wù)器收到搜索陷門Tω'后，逐一對存儲的關(guān)鍵詞密文進行搜索測試，判斷方程H(Tω'·C1)=C2是否成立，若測試方程成立，則匹配成功，返回對應(yīng)的加密數(shù)據(jù)文件給數(shù)據(jù)接收方。

6）完整性驗證（Verify）算法：不失一般性，這里假設(shè)同一個關(guān)鍵詞匹配成功的加密數(shù)據(jù)文件有n個，分別為c1，c2，…，cn。為了確保這些密文是正確存儲在云服務(wù)器端的，數(shù)據(jù)接收方需要進行完整性驗證。

（3）數(shù)據(jù)接收方在接收到云服務(wù)器返回的完整性證明響應(yīng)信息后，檢驗以下完整性驗證方程是否成立：σ·P=？qs，1·N+c·qs，2+R·u。若等式成立，表明數(shù)據(jù)接收方成功搜索的加密數(shù)據(jù)文件未遭到破壞，云服務(wù)器存儲的密文數(shù)據(jù)是完整的；否則，驗證不通過，表明數(shù)據(jù)發(fā)送方存儲在云服務(wù)器的加密數(shù)據(jù)文件的完整性遭到了破壞，數(shù)據(jù)接收方可以拒絕接收這些密文文件。

3 正確性證明

對本文方案進行正確性證明。假設(shè)ω為關(guān)鍵詞密文中關(guān)鍵詞的標識符，ω'為關(guān)鍵詞搜索陷門中關(guān)鍵詞的標識符，推導(dǎo)過程具體如下：

后續(xù)推導(dǎo)過程分以下2 種情況考慮：

1）如果是正確的數(shù)據(jù)發(fā)送方和正確的數(shù)據(jù)接收方，那么就可以得到d=d*，若式（1）的計算結(jié)果為不相等，則可判定數(shù)據(jù)發(fā)送方和數(shù)據(jù)接收方不匹配。因此，這一部分的設(shè)計可以有效檢測出外部惡意敵手想冒充合法用戶的情況。

2）當?shù)?）種情況為式（1）的正確計算結(jié)果時，若關(guān)鍵詞ω=ω'，則推導(dǎo)等式H(Tω'·C1)=C2成立，即關(guān)鍵詞密文和搜索陷門匹配成功；但若關(guān)鍵詞ω和ω'不相等，由于選取的是抗碰撞哈希函數(shù)，因此不難得出等式不成立的結(jié)果，保證了關(guān)鍵詞匹配的正確性。

若云服務(wù)器返回給數(shù)據(jù)接收方的云端密文數(shù)據(jù)未被篡改，則式（3）成立，即表明數(shù)據(jù)完整性驗證通過。

綜合以上兩種情況的推導(dǎo)，可以證明本文方案是正確的。

4 安全性分析

對本文方案進行安全性分析與證明。

定理1本文方案在選擇關(guān)鍵詞攻擊下滿足密文不可區(qū)分性。

證明：假設(shè)A1是針對所提出的選擇關(guān)鍵詞攻擊下滿足密文不可區(qū)分性（CIND-CKA）游戲的多項式時間攻擊者，AH是抗碰撞哈希函數(shù)的攻擊者，AECDLP是求解基于橢圓曲線離散對數(shù)困難問題（ECDLP）的攻擊者。

由5 個游戲Gamei，i=1，2，…，5 作為子游戲程序，且以A1作為攻擊者完成證明。本文將攻擊者A1在Gamei中正確猜測的事件定義為Xi，即b=bi。攻擊者將以最終輸出終止，然后將對其進行評估，以查看攻擊者是否“贏”。具體描述如下：

游戲1該游戲為原始敵手游戲CIND-CKA，因此，A1正確猜測的概率為：Adv(λ)A1=|Pr[X1]-1/2|。

游戲2該游戲與游戲1 相同，不同之處在于挑戰(zhàn)者 B 選 擇a，vr，1，vr，2∈來計算P'=a·P和qr=(qr，1，qr，2)=(vr，1·P，a·vr，2·P)，其中點P是群G的生成元，其他參數(shù)與游戲1 相同。由于游戲1 的參數(shù)與游戲2 的分布相同，顯然，游戲2 與游戲1 對A1來說是無法區(qū)分的，因此A1在這兩個游戲中猜測的概率相同，即Pr[X2]=Pr[X1]。

游戲3該游戲與游戲2 相同，不同之處在于B 更改了他/她響應(yīng)A1密文查詢、搜索陷門查詢、測試查詢以及挑戰(zhàn)應(yīng)答的方式，如下所述：

在上述游戲中，如果B 能夠正確應(yīng)答各種預(yù)言查詢并完成挑戰(zhàn)，那么對A1而言，游戲2 和游戲3 將是難以區(qū)分的。因此，攻擊者A1在游戲2 和游戲3 中正確猜測的概率相同，即Pr[X3]=Pr[X2]。

游戲4該游戲與游戲3 相同，在以下任何事件發(fā)生時，B 都將終止游戲：

顯然，除非事件E1∨E2發(fā)生，否則游戲3 和游戲4對于攻擊者來說是無法區(qū)分的。根據(jù)文獻［24］中的差分引理可以得出|Pr[X3]-Pr[X4] |≤Pr[E1∨E2]。

如果發(fā)生E1，則必須有一個針對哈希函數(shù)H的抗碰撞性的攻擊者AH，即破壞哈希函數(shù)的抗碰撞性的攻擊者，因此，若Adv(λ)AH≥Pr[E1]，則AH具有獲勝的優(yōu)勢。同樣，如果發(fā)生E2，則必須有一個針對消息認證碼MAC 的抗碰撞性的攻擊者AMAC，即破壞消息認證碼的抗碰撞性的攻擊者。因此，若Adv(λ)AMAC≥Pr[E2]，則AMAC具有獲勝的優(yōu)勢。由此可得|Pr[X3]-Pr[X4]| ≤Pr[E1∨E2]≤Adv(λ)AMAC+Adv(λ)AH。

分析A1的優(yōu)勢，有：

根據(jù)以上游戲，可以得出以下結(jié)論：

由于哈希函數(shù)H和消息認證碼的抗碰撞性，以及ECDLP 問題是困難的，因 此Adv(λ)AMAC、Adv(λ)AH和Adv(λ)AECDLP是可以忽略的，由此可以證明本文方案在滿足選擇關(guān)鍵詞攻擊下是密文不可區(qū)分的。

定理2本文方案在選擇關(guān)鍵詞攻擊下滿足搜索陷門不可區(qū)分性。

證明：假設(shè)A2是針對所提出的在選擇關(guān)鍵詞攻擊下滿足搜索陷門不可區(qū)分性（TIND-CKA）游戲的多項式時間攻擊者，AH是抗碰撞哈希函數(shù)攻擊者，ACDH是求解計算型Diffie-Hellman（CDH）困難問題的攻擊者。

由攻擊者A2的5 個游戲Gamei，i=1，2，…，5 作為子游戲程序。這里將Xi定義為攻擊者A2猜測Gamei中的正確事件，即b=bi。攻擊者將以一些最終輸出終止，然后將對其進行評估，以查看攻擊者是否“贏”。具體描述如下：

游戲1該游戲為原始敵手游戲TIND-CKA，因此，攻擊者A2正確猜測的概率為Adv(λ)A2=|Pr[X1]-1/2|。

游戲2B 隨機選擇a，b，vr，2∈來計算qs，1=b·P和qr=(a·P，vr，2·P)，其中P是群G的生成元，其他參數(shù)與游戲1 相同。顯然，游戲1 和游戲2 于A2是無法區(qū)分的。因此，A2在這兩個游戲中正確猜測的概率相等，即Pr[X1]=Pr[X2]。

游戲3該游戲與游戲2 相同，不同之處在于B 更改了他/她對A2進行密文查詢、搜索陷門查詢、測試查詢和質(zhì)詢的響應(yīng)方式，如下所示：

1）密文查詢：A2使用關(guān)鍵詞ω∈KSω進行密文查詢，B 選擇隨機數(shù)t∈并返回關(guān)鍵詞密文C=(C1，C2)給A2，其中C1=t·qr，2，C2=H(t·MACd(ω)·P)，d=H1(b·a·P)。

2）搜索陷門查詢：A2使用關(guān)鍵詞進行搜索陷門查詢，B 返回搜索陷門Tω'=(vr，2)-1·MACd*(ω')，其中，ω'∈KSω，d*=H1(a·qs，1)=H1(a·b·P)。

3）測試查詢：A2使用關(guān)鍵詞密文C和關(guān)鍵詞搜索陷門Tω'進行測試查詢，若H（Tω'·C1）=C2，則B 返回1，否則返回0。

4）挑戰(zhàn)：A2發(fā)送2 個他/她之前從未挑戰(zhàn)過的關(guān)鍵詞ω0和ω1給B，其中ω0≠ω1，B 計算關(guān)鍵詞搜索陷門Tωb'=（vr，2）-1·MACd*()，其中，b∈{0，1}，d*=H1(a·b·P)，然后將其返回給A2。

在上述游戲中，如果B 能夠響應(yīng)各種查詢并正確挑戰(zhàn)，那么游戲2 與游戲3 將于A2難以區(qū)分。因此，A2在游戲2 和游戲3 中猜測正確的概率相等，即Pr[X2]=Pr[X3]。

游戲4該游戲定義與定理1 證明中游戲4 相同，因此，存在抗碰撞的敵手A2的優(yōu)勢為|Pr[X3]-Pr[X4]| ≤Adv(λ)AMAC+Adv(λ)AH。

游戲5該游戲與游戲4 相同，不同之處在于B 在響應(yīng)陷門挑戰(zhàn)時選擇一個點Z∈G來計算Tωb'=(vr，2)-1·MACd*(ω'b)中的d*=H1(Z)而不是d*=H1(a·b·P)。B 在游戲5 中僅使用CDH 元組(H1，P，a·P，b·P，Z)，而不需要知道a和b的值即可響應(yīng)所有攻擊者的查詢和陷門挑戰(zhàn)。顯然，游戲4 和游戲5 是相同的，如果解決了CDH 問題，那么攻擊者ACDH可以通過不可忽略的優(yōu)勢來區(qū)分a·b·P和Z的值。假設(shè)攻擊者ACDH擁有贏得游戲5 的優(yōu)勢，則可得|Pr[X4]-Pr[X5] |≤Adv(λ)ACDH。

由于Z是群G的一個隨機元素，因此A2正確猜測的可能性是Pr[X5]=1/2。

分析A2的優(yōu)勢，有：

根據(jù)上述游戲，可以得出以下結(jié)論：

由于Adv(λ)AH、Adv(λ)AMAC和Adv(λ)ACDH是可以忽略的，因此可以證明本文方案滿足選擇關(guān)鍵詞攻擊情況下是陷門不可區(qū)分的。

定理3支持隱私保護的可驗證云端數(shù)據(jù)分享方案可確保云端密文數(shù)據(jù)的存儲正確性。

證明：本文方案在數(shù)據(jù)發(fā)送方上傳加密文件的同時，為每一份密文文件生成了一個同態(tài)數(shù)字簽名(σi，Ri)用于進行搜索結(jié)果的完整性驗證，其中σi=xsH2(Ni)+ysci+kiu∈。該簽名基于改進的BLS 短簽名算法設(shè)計完成，使用數(shù)據(jù)發(fā)送方的簽名私鑰vs=(vs，1，vs，2)對用戶的數(shù)據(jù)密文進行簽名，由于簽名私鑰只有數(shù)據(jù)發(fā)送方擁有，因此只有數(shù)據(jù)發(fā)送方才可以產(chǎn)生正確的簽名，從而通過完整性驗證，而非數(shù)據(jù)發(fā)送方的攻擊者（如惡意云服務(wù)器）若想偽造簽名，困難程度可歸約到求解橢圓曲線上的離散對數(shù)困難問題。顯然，成功偽造簽名的概率是可以忽略的，惡意云服務(wù)器試圖通過偽造數(shù)字簽名產(chǎn)生偽造的完整性驗證，證明信息達到欺騙用戶的目的是計算不可行的。因此，本文方案可確保云端密文數(shù)據(jù)的存儲正確性。

5 性能分析

將本文方案（DSS-SPP-CSS）與其他同樣用于云端密文數(shù)據(jù)分享的公鑰可搜索加密方案進行效率對比，包括PEKS［12］、PAEKS［25］、dIBAEKS［26］和CLEKS［27］。首先對各個方案的功能和特性進行對比，如表1 所示。比較結(jié)果顯示，DSS-SPP-CSS 方案能夠抵抗內(nèi)部關(guān)鍵詞猜測攻擊，而且能夠確保搜索的密文數(shù)據(jù)是正確存儲在云服務(wù)器的。

表1 不同方案的功能特征對比Table 1 Functional features comparison of different schemes

所有方案實現(xiàn)都運行在硬件環(huán)境為Intel Corei5 CPU 和8 GB DDR3 以及軟件環(huán)境為Windows 10操作系統(tǒng)的筆記本電腦上。本文使用C 語言編寫實驗?zāi)Ｐ?，主要用的庫為PBC 庫。實驗使用到的橢圓曲線構(gòu)造在Fp上，方程為y2=x3+x。群G中元素的比特長度為512 bit，q的比特長度為320 bit。

本文側(cè)重于公鑰可搜索加密功能對以上方案進行計算開銷評估，主要由關(guān)鍵詞密文生成計算開銷、搜索陷門生成計算開銷和測試算法計算開銷等3 部分組成。相關(guān)運算符號含義如表2 所示。

表2 運算符號Table 2 Operational symbols

不同方案各個階段的計算開銷比較見表3。對各方案的計算效率作進一步分析與比較，如圖3～圖5 所示?？梢钥闯?，DSS-SPP-CSS 方案在關(guān)鍵詞密文生成、搜索陷門生成、測試算法計算開銷上都有著明顯的性能優(yōu)勢，除了擁有密文數(shù)據(jù)分享功能外，其能有效抵抗內(nèi)部云服務(wù)器關(guān)鍵詞猜測攻擊。此外，本文方案還具備完整性驗證功能，當用戶檢索到密文文件后，會先對這些文件進行完整性驗證，并在驗證通過后進行密文文件的下載，從而有效保障云端加密文件的完整性，避免用戶產(chǎn)生無效開銷。

表3 不同方案各階段計算開銷對比Table 3 Computation overhead comparison in each stage of different schemes

圖3 關(guān)鍵詞密文生成計算開銷Fig.3 Computation overhead of keywords ciphertext generation

圖4 搜索陷門生成計算開銷Fig.4 Computation overhead of search trapdoor generation

圖5 測試算法計算開銷Fig.5 Computation overhead of test algorithm

從關(guān)鍵詞密文長度和搜索陷門長度兩個方面對比DSS-SPP-CSS 方案與其他方案的通信開銷。設(shè)置本文方案中哈希函數(shù)H1和哈希函數(shù)H2的映射值的長度為320 bit（文中用?1表示），其余方案的群中元素的長度與本文方案統(tǒng)一。不同方案的通信開銷如表4 所示，其中，LG代表群中元素的位長，Lq代表q的位長。圖6 給出了更直觀的通信開銷比較?？梢钥闯觯篋SS-SPP-CSS 方案在關(guān)鍵詞密文的通信開銷上優(yōu)于dIBAEKS、CLEKS 和PAEKS 方案，與PEKS 方案持平；在搜索陷門的通信開銷上，優(yōu)于PAEKS、CLEKS 和PEKS 方案，遠低于dIBAEKS 方案。由此可見，與對比方案相比，DSS-SPP-CSS 通信開銷更小，有助于減小端到端的延遲。

表4 不同方案的通信開銷對比Table 4 Communication overhead comparison of different schemes 單位：bit

圖6 各階段通信開銷Fig.6 Communication overhead in each stage

綜上所述，本文提出的DSS-SPP-CSS 方案具有輕量級的性能優(yōu)勢，適用于面向云存儲系統(tǒng)的移動終端應(yīng)用場景。

6 結(jié)束語

面向云端數(shù)據(jù)保密分享需求，本文提出基于橢圓曲線的公鑰可搜索加密方案DSS-SPP-CSS。該方案在選擇關(guān)鍵詞攻擊下滿足密文不可區(qū)分性和搜索陷門不可區(qū)分性，在隨機預(yù)言機模型下可以抵抗內(nèi)部關(guān)鍵詞猜測攻擊。性能分析結(jié)果表明，本文方案可以高效部署在云端加密數(shù)據(jù)分享應(yīng)用場景，具有輕量級的性能優(yōu)勢。下一步將設(shè)計基于模糊關(guān)鍵詞的可驗證公鑰可搜索加密算法，實現(xiàn)更靈活的數(shù)據(jù)保密分享功能。