劉永志 秦桂云 劉蓬濤 胡程瑜,3,4 郭山清,3,4

1 （山東大學(xué)網(wǎng)絡(luò)空間安全學(xué)院 山東青島 266237）

2 （山東政法學(xué)院網(wǎng)絡(luò)空間安全學(xué)院 濟(jì)南 250014）

3 （密碼技術(shù)與信息安全教育部重點(diǎn)實(shí)驗(yàn)室（山東大學(xué)） 濟(jì)南 250100）

4 （泉城實(shí)驗(yàn)室 濟(jì)南 250103）（liuyongzhi@mail.sdu.edu.cn）

云存儲(chǔ)具有低成本、可擴(kuò)展、部署快、容量大等優(yōu)勢(shì)，越來越多的企業(yè)和組織傾向于把數(shù)據(jù)存放在云端，這使云存儲(chǔ)成為未來數(shù)據(jù)存儲(chǔ)的發(fā)展方向.然而，為了保護(hù)數(shù)據(jù)隱私，數(shù)據(jù)發(fā)送到云服務(wù)器存儲(chǔ)之前，通常需要進(jìn)行加密處理.為了解決在密文數(shù)據(jù)上的搜索問題，可搜索加密（searchable encryption, SE）技術(shù)應(yīng)運(yùn)而生.作為可搜索加密的一個(gè)分支，公鑰可搜索加密（public key encryption with keyword search, PEKS）體制[1]主要用于解決對(duì)稱可搜索加密（symmetric searchable encryption, SSE）中復(fù)雜的密鑰管理問題，以滿足接收方對(duì)存儲(chǔ)在云服務(wù)器中的不同發(fā)送方的數(shù)據(jù)進(jìn)行關(guān)鍵詞搜索的需求.

PEKS 方案的框架如圖1 所示，在這個(gè)場(chǎng)景中，有云服務(wù)器、文件發(fā)送方和文件接收方3 個(gè)行為主體.一個(gè)完整的搜索過程為：文件發(fā)送方使用文件接收方的公鑰生成關(guān)鍵詞的PEKS密文，并將PEKS密文連同文件密文一起發(fā)送給云服務(wù)器；文件接收方通過自己的私鑰生成對(duì)某個(gè)關(guān)鍵詞的搜索陷門，將其發(fā)送給云服務(wù)器；由云服務(wù)器執(zhí)行匹配算法進(jìn)行搜索，最后將搜索結(jié)果返回給文件接收方；根據(jù)搜索結(jié)果，文件接收方可以選擇性地下載文件密文，并在本地進(jìn)行解密以獲取原文件.

Fig.1 PEKS system framework圖1 PEKS 系統(tǒng)框架

雖然已有大量的研究工作在一定程度上解決了PEKS 在效率、安全性方面的問題，但PEKS 仍然面臨一些安全性和實(shí)用性方面的挑戰(zhàn).在安全性方面，PEKS 方案容易受到關(guān)鍵詞猜測(cè)攻擊（keyword guessing attack，KGA）[2]，也較少考慮確定性陷門生成算法導(dǎo)致的搜索模式泄露以及前向安全等安全問題.在實(shí)用性方面，由于數(shù)據(jù)需要在云用戶之間共享，例如，一個(gè)接收方可能會(huì)將從發(fā)送方得到的數(shù)據(jù)分享給另一個(gè)用戶，因此，有必要考慮關(guān)鍵詞搜索能力的轉(zhuǎn)移，在多用戶環(huán)境下構(gòu)建PEKS 方案，即需要考慮關(guān)鍵詞密文的重加密.總之，如何提高當(dāng)前PEKS 方案的安全性和實(shí)用性，是研究人員必須考慮的問題.

針對(duì)PEKS 方案面臨的安全性和實(shí)用性問題，本文提出了一種基于軟件防護(hù)擴(kuò)展（software guard extensions，SGX）的公鑰認(rèn)證可搜索加密（public key authenticated encryption with keyword search，PAEKS）方案，主要貢獻(xiàn)有4 個(gè)方面：

1）修改了PAEKS 原始模型中的陷門生成算法定義，使之更符合云存儲(chǔ)的實(shí)際應(yīng)用場(chǎng)景；給出了PAEKS 方案的增強(qiáng)安全性定義，包括一個(gè)允許敵手詢問挑戰(zhàn)關(guān)鍵詞密文的密文不可區(qū)分性定義、一個(gè)陷門不可區(qū)分性定義和一個(gè)搜索模式隱私性定義.滿足這3 種安全性定義的PAEKS 方案可抵抗關(guān)鍵詞猜測(cè)攻擊并能對(duì)外部攻擊者隱藏陷門中的關(guān)鍵詞隱私信息.

2）設(shè)計(jì)了一個(gè)基于SGX 的支持單關(guān)鍵詞搜索的公鑰認(rèn)證可搜索加密方案PAEKS-SGX.該方案借鑒Naor-Yung 構(gòu)造選擇密文攻擊下的不可區(qū)分（indistinguishability under chosen ciphertext attack，IND-CCA）安全性的公鑰加密方案的范式[3]，關(guān)鍵詞密文由關(guān)鍵詞、文件發(fā)送方對(duì)關(guān)鍵詞的簽名在2 個(gè)不同公鑰下的公鑰加密（public key encryption，PKE）密文以及一個(gè)零知識(shí)證明構(gòu)成.驗(yàn)證階段由運(yùn)行在云服務(wù)器的飛地搜索程序完成，文件接收方私鑰經(jīng)過可信信道傳遞到飛地中.我們對(duì)方案進(jìn)行了正式的安全性分析，通過分析證明，當(dāng)所使用的公鑰加密方案具有選擇消息攻擊下的不可區(qū)分性（indistinguishability under chosen message attack，IND-CPA）、簽名方案具有選擇消息攻擊下的存在不可偽造性（existential unforgeability under chosen message attack，EUF-CMA）以及零知識(shí)證明方案具有完備性、可靠性和零知識(shí)性等特性時(shí)，本文方案具有密文不可區(qū)分性、陷門不可區(qū)分性以及搜索模式隱私性等.

3）在真實(shí)環(huán)境中進(jìn)行了完整的實(shí)驗(yàn)，并和其他方案進(jìn)行了全方面的對(duì)比.實(shí)驗(yàn)結(jié)果表明，PAEKSSGX 是可行且有效的，同時(shí)在效率方面表現(xiàn)出色.

4） PAEKS-SGX 可以很方便地進(jìn)行擴(kuò)展，從而支持多關(guān)鍵詞搜索等復(fù)雜搜索、搜索能力的分享傳遞以及一些更高的安全性.作為示例，本文介紹了如何擴(kuò)展方案支持多關(guān)鍵詞搜索、如何擴(kuò)展方案到多用戶場(chǎng)景以及如何支持前向安全性.

1 相關(guān)工作

1.1 公鑰（認(rèn)證）可搜索加密

2004 年，Boneh 等人[1]將SE 技術(shù)應(yīng)用到公鑰場(chǎng)景中，提出了PEKS 的概念，并基于身份基加密（identity-based encryption， IBE）方 案 構(gòu) 造 了 第1 個(gè)PEKS 方案.2005 年，Abdalla 等人[4]完善了PEKS 的一致性定義，提出了PEKS 方案與匿名IBE 方案之間的轉(zhuǎn)化關(guān)系，并探討了IBE 和PEKS 之間的安全關(guān)系.

2006 年，Byun 等人[2]指出PEKS 體制存在的關(guān)鍵詞猜測(cè)攻擊隱患，即當(dāng)關(guān)鍵詞空間遠(yuǎn)小于密鑰空間時(shí)，攻擊者可以用自行生成的PEKS 密文來匹配用戶的搜索陷門，以獲知用戶搜索的關(guān)鍵詞.之后，Baek 等人[5]在2008 年提出指定驗(yàn)證人的PEKS 方案（searchable public-key encryption scheme with a designated tester，dPEKS），在生成關(guān)鍵詞密文的同時(shí)使用了云服務(wù)器公鑰，使得只有指定的云服務(wù)器具有進(jìn)行關(guān)鍵詞密文和陷門匹配的權(quán)限.該方案在隨機(jī)預(yù)言機(jī)模型中被證明是安全的.Fang 等人[6]提出了一個(gè)更加高效的dPEKS 方案，并在標(biāo)準(zhǔn)模型下證明其安全性.2012 年，Xu 等人[7]提出使用模糊關(guān)鍵詞陷門進(jìn)行初次搜索，并對(duì)返回的結(jié)果再利用精確關(guān)鍵詞陷門進(jìn)行2 次匹配來抵御關(guān)鍵詞猜測(cè)攻擊.2010 年，Rhee 等人[8]在dPEKS 中引入陷門不可區(qū)分的概念，給出了dPEKS 的正式安全模型.但是，dPEKS 方案并不是通過阻止攻擊者構(gòu)造關(guān)鍵詞密文來抵抗關(guān)鍵詞猜測(cè)攻擊，其安全性定義中一般假設(shè)指定驗(yàn)證人是可信的，因此，在實(shí)際使用中，dPEKS 方案無法阻止內(nèi)部攻擊者（指定驗(yàn)證人）自己構(gòu)造關(guān)鍵詞密文來進(jìn)行關(guān)鍵詞猜測(cè)攻擊.

為了在無需指定驗(yàn)證人的情形下解決PEKS 方案面臨的關(guān)鍵詞猜測(cè)攻擊問題，并解決dPEKS 方案無法抵抗內(nèi)部攻擊者（指定驗(yàn)證人）的關(guān)鍵詞猜測(cè)攻擊問題，2017 年，Huang 等人[9]提出了一個(gè)新的PAEKS的概念，即在生成關(guān)鍵詞密文時(shí)使用接收方公鑰和發(fā)送方私鑰，以保證服務(wù)器無法自己生成關(guān)鍵詞密文，從而有效地抵御關(guān)鍵詞猜測(cè)攻擊.隨后，Qin 等人[10]指出，Huang 等人[9]的PAEKS 的密文不可區(qū)分安全性不夠合理，不同于之前的PEKS，dPEKS 等，PAEKS 在關(guān)鍵詞密文生成時(shí)使用了發(fā)送方私鑰，而其單密文不可區(qū)分性不允許敵手在挑戰(zhàn)完之后繼續(xù)詢問挑戰(zhàn)關(guān)鍵詞的密文，所以并不能保證多密文不可區(qū)分性，從而存在安全隱患.因此，有必要重新考慮PAEKS 方案的密文不可區(qū)分性定義.Qin 等人[10]提出了多密文不可區(qū)分性定義.Huang 等人[9]和Qin等人[10]的PAEKS 方案的陷門生成算法都是確定性的，外部攻擊者可以通過2 個(gè)陷門是否相同來判斷搜索的關(guān)鍵詞是否相同.另外，文獻(xiàn)[9-10]中所使用的PAEKS 原始模型定義中，陷門生成算法需要用到發(fā)送方的公鑰.這并不符合云存儲(chǔ)的實(shí)際應(yīng)用場(chǎng)景，因?yàn)榻邮辗讲⒉恢谰唧w都有誰給他發(fā)送過數(shù)據(jù)（比如電子郵件），也就無法在生成搜索陷門時(shí)針對(duì)性地使用發(fā)送方公鑰.

在搜索能力共享（多用戶）方面，其基本的思路是利用代理重加密（proxy re-encryption, PRE）將關(guān)鍵詞密文轉(zhuǎn)換為新用戶的公鑰下的關(guān)鍵詞密文.Shao等人[11]將代理重加密和公鑰可搜索加密相結(jié)合，提出關(guān)鍵詞搜索代理重加密（proxy re-encryption with keyword search, PREKS）的加密原語，并在隨機(jī)預(yù)言機(jī)模型中證明了它的安全性.但是，該方案不能抵抗關(guān)鍵詞猜測(cè)攻擊.隨后，郭麗峰等人[12]給出一個(gè)有效的PAEKS 方案，該方案能夠抵制關(guān)鍵詞猜測(cè)攻擊，但需要指定驗(yàn)證人.在Shao 等人[11]的方案中，擁有重加密密鑰的代理能夠?qū)⑺嘘P(guān)鍵詞密文進(jìn)行重加密，為了限制代理的權(quán)限，F(xiàn)ang 等人[13]結(jié)合條件代理重加密（conditional proxy re-encryption, C-PRE），提出了關(guān)鍵詞搜索條件代理重加密（conditional proxy reencryption with keyword search, C-PREKS）的概念，然而文獻(xiàn)[13]的方案也無法抵御關(guān)鍵詞猜測(cè)攻擊.為了更進(jìn)一步限制代理的權(quán)限，實(shí)現(xiàn)細(xì)粒度的數(shù)據(jù)訪問控制，Chen 等人[14]將PREKS 與閾值密碼系統(tǒng)相結(jié)合，提出了關(guān)鍵詞搜索受限代理重加密（restricted proxy re-encryption with keyword search）的方案，但是此方案易受到關(guān)鍵詞猜測(cè)攻擊且陷門生成算法是確定的.

另外，很多方案不考慮針對(duì)外部攻擊者的陷門隱私性，關(guān)鍵詞陷門生成算法是確定性的，假如接收方和服務(wù)器之間不存在安全信道，這會(huì)導(dǎo)致外部攻擊者僅從2 次搜索的陷門就可以判斷接收方是否搜索的是同一關(guān)鍵詞.

1.2 軟件防護(hù)擴(kuò)展

可信執(zhí)行環(huán)境（trusted execution environment, TEE）是指通過軟硬件方法在中央處理器中構(gòu)建的一個(gè)安全區(qū)域，提供一個(gè)隔離的、安全的執(zhí)行環(huán)境，可以保證加載到該環(huán)境內(nèi)部的代碼和數(shù)據(jù)的安全性、機(jī)密性和完整性[15].常見的TEE[16]包括Intel 軟件防護(hù)擴(kuò)展、Intel 管理引擎（management engine, ME）、x86 系統(tǒng)管理模式（system management mode, SMM）、AMD內(nèi)存加密（memory encryption）技術(shù)、AMD 平臺(tái)安全處理器（platform security processor, PSP）和ARM TrustZone技術(shù).

軟件防護(hù)擴(kuò)展是Intel 推出的指令集擴(kuò)展，旨在以硬件安全為強(qiáng)制性保障，為用戶空間提供TEE[17].在SGX 中， 應(yīng) 用 程 序 運(yùn) 行 的TEE 被 稱 為 飛 地（enclave）.enclave 使 用 的 頁 面 和 數(shù) 據(jù) 結(jié) 構(gòu) 由CPU 內(nèi)部的內(nèi)存加密引擎（memory encryption engine，MEE）[18]加密存儲(chǔ)在安全區(qū)頁面緩存（enclave page cache，EPC）中，這是系統(tǒng)內(nèi)一塊被保護(hù)的物理內(nèi)存區(qū)域，EPC 的訪問控制由安全區(qū)頁面緩存映射（enclave page cache map，EPCM）負(fù)責(zé)，除enclave 外的任何軟硬件都無法直接訪問.

Intel SGX 定 義 了 一 個(gè) 新 的CPU 模 式.叫 作enclave 模式.當(dāng)CPU 訪問enclave 中的數(shù)據(jù)時(shí)，首先需要切換到enclave 模式，該模式下所有對(duì)內(nèi)存的訪問都會(huì)被嚴(yán)格檢查；當(dāng)enclave 主動(dòng)退出時(shí)，CPU 就會(huì)退回到non-enclave 模式，并清空CPU 寄存器以防止數(shù)據(jù)泄露，這2 種模式的切換通過調(diào)用ecall/ocall接口來實(shí)現(xiàn).當(dāng)enclave 被中斷或被異常打斷時(shí)，CPU也會(huì)強(qiáng)制退回到non-enclave 模式，并可以在中斷或異常處理完成之后重新進(jìn)入enclave.

Intel SGX 提供了一種enclave 安全性證明的技術(shù)，叫作SGX 遠(yuǎn)程認(rèn)證（SGX remote attestation）.通過 該技術(shù)，用戶不僅可以遠(yuǎn)程驗(yàn)證云服務(wù)器上enclave 的正確性和完整性，還可以和云服務(wù)器上enclave 通過Diffie-Hellman 密鑰交換協(xié)議建立一個(gè)安全的信道，實(shí)現(xiàn)秘密共享.

Intel SGX 還提 供了密封（sealing）策略，以確保在enclave 退出后保護(hù)數(shù)據(jù)的機(jī)密性和完整性.本質(zhì)上來講，密封策略是一種數(shù)據(jù)加密技術(shù)，它提供了2種加密策略：基于enclave 身份的策略MRENCLAVE和基于signing 身份的策略MRSIGNER.前者會(huì)生成該enclave 獨(dú)有的密鑰，該密鑰密封的數(shù)據(jù)只有同一版本的同一enclave 才能解密；后者會(huì)基于enclave 密封授權(quán)方的簽名密鑰來生成一個(gè)密鑰，該密鑰密封的數(shù)據(jù)可以在同一授權(quán)方授權(quán)的多個(gè)不同版本的enclave 之間共享.需要注意的是，這2 種密鑰的生成都需要輸入當(dāng)前設(shè)備的信息，這意味著密封的數(shù)據(jù)是無法從一臺(tái)設(shè)備共享給另一臺(tái)設(shè)備的.

1.3 基于Intel SGX 的公鑰可搜索加密方案

為了克服傳統(tǒng)的PEKS 方案存在的多方面安全隱患，Yoon 等人[19]提出了一種基于Intel SGX 的前向安全的PEKS 方案，他們定義了一個(gè)前向安全的PEKS 安全模型，并進(jìn)行了安全性證明.然而他們的方案存在5 點(diǎn)不足：

1）其安全模型不是標(biāo)準(zhǔn)的PEKS 安全模型，而僅僅是SSE 安全模型的平凡遷移；

2）生成PEKS 密文時(shí)使用了SSE 場(chǎng)景下的索引作為文件的標(biāo)識(shí)，這顯然是不合理的，因?yàn)槲募l(fā)送方將文件共享給文件接收方之后，文件的標(biāo)識(shí)應(yīng)該由云服務(wù)器來管理，而不是文件發(fā)送方；

3）生成陷門的用戶私鑰和該用戶的公鑰沒有任何關(guān)系，因此該方案并不能被稱作標(biāo)準(zhǔn)的PEKS 方案；

4）該方案的搜索算法只匹配了一個(gè)PEKS 密文，并不是完整的搜索過程，而即使修改完整，該過程也需要對(duì)系統(tǒng)中所有文件的所有PEKS 密文進(jìn)行遍歷，而不是在當(dāng)某個(gè)文件的某個(gè)PEKS 密文匹配成功后就不再對(duì)該文件剩余的PEKS 密文進(jìn)行匹配，因此在具體實(shí)現(xiàn)中該方案的效率很低；

5）在安全性上，該方案無法抵御關(guān)鍵詞猜測(cè)攻擊.

本文方案要充分考慮Yoon 等人[19]方案的不足，此外在具體方案實(shí)現(xiàn)上，我們還需要兼顧3 個(gè)問題：

1）兼容.enclave 是否支持本文方案所需的加密庫，比如OpenSSL，PBC 等.目 前Intel SGX 已 支 持Intel SGX SSL 和Intel GMP 這2 種庫，最終我們選擇使用Intel SGX SSL（集成了OpenSSL 1.1.1n）來實(shí)現(xiàn)本文方案.

2）內(nèi)存.enclave 可使用的EPC 被限制到128 MB，并且只有93 MB 能夠被應(yīng)用程序所使用，一旦超出這個(gè)限制大小，SGX 就會(huì)把一些EPC 頁轉(zhuǎn)化成不受保護(hù)的DRAM，這會(huì)引起很高的性能開銷.因此，需要在實(shí)驗(yàn)中進(jìn)一步降低應(yīng)用程序的內(nèi)存，具體的改進(jìn)方案在4.2 節(jié)有詳細(xì)介紹.

3）性能.non-enclave 模式切換到enclave 模式時(shí)，需要將enclave 外部應(yīng)用程序的上下文保存到TCS（thread control structure）數(shù)據(jù)結(jié)構(gòu)中.enclave 模式切換回non-enclave 模式時(shí)，也會(huì)釋放TCS 數(shù)據(jù)結(jié)構(gòu)，并清空CPU 寄存器.這2 種模式之間的切換會(huì)引起很高的運(yùn)行開銷，因此要嚴(yán)格控制這種切換的次數(shù).

2 預(yù)備知識(shí)

2.1 公鑰加密

公鑰加密方案[3]由3 個(gè)多項(xiàng)式時(shí)間算法組成，分別 為PKE.KeyGen，PKE.Enc，PKE.Dec.其 中，PKE.KeyGen是隨機(jī)密鑰生成算法，它以一個(gè)安全參數(shù)作為輸入，然后輸出一個(gè)公私鑰對(duì)（pk, sk）.PKE.Enc是概率加密算法，它接收消息m∈M和公鑰pk，并選擇隨機(jī)性，然后計(jì)算出密文c并輸出.PKE.Dec是確定性解密算法，它接收密文c和私鑰sk，解密成功是指輸出消息m；解密失敗，則輸出錯(cuò)誤符號(hào)“ ⊥”.

IND-ATK（ATK 為CPA 或 CCA）安全是指選擇明文攻擊下的不可區(qū)分性和選擇密文攻擊下的不可區(qū)分性，是公鑰加密體制下的2 個(gè)安全定義.對(duì)于一個(gè)公鑰加密方案PKE的敵手 A=（A1,A2），其優(yōu)勢(shì)是可忽略的（如果ATK 為CPA，敵手對(duì)解密預(yù)言機(jī)的訪問會(huì)被移除）.

2.2 簽 名

簽名方案[20]由3 個(gè)多項(xiàng)式時(shí)間算法組成，分別為S IG.KeyGen,S IG.S ign,S IG.Ver.其中，S IG.KeyGen是隨機(jī)密鑰生成算法，它以一個(gè)安全參數(shù)作為輸入，然后輸出一個(gè)公私鑰對(duì)（pk, sk）.SIG.S ig是簽名算法，它接收消息m∈M和私鑰sk，然后輸出一個(gè)簽名σ ←S IG.S ign(sk,m).S IG.Ver是確定性驗(yàn)證算法，它接收公鑰pk、消息m和簽名 σ，簽名有效輸出1；反之輸出0.

EUF-CMA 安全是指選擇消息攻擊下的不可偽造性，是指任何概率多項(xiàng)式時(shí)間的敵手 A攻擊一個(gè)簽名方案SIG=(S IG.KeyGen,S IG.S ign,S IG.Ver)的優(yōu)勢(shì)是可忽略的.

簽名預(yù)言機(jī)的工作原理為：

S ign(sk,m,Q)：

1）σ =Sign(sk,m)；

2）setQ=Q∪m；

3） r eturn σ.

2.3 非交互式零知識(shí)證明

設(shè)關(guān)系R是對(duì)（x, y）上的NP 關(guān)系，表示為L(zhǎng)R={y|?xs.t.(x,y)∈R}.關(guān)系R的一個(gè)非交互式零知識(shí)（noninteraction zero-knowledge, NIZK）[21]由3 個(gè)算法組成，分別為Setup, P , V.其中，Setup是參數(shù)設(shè)置算法，它以一個(gè)安全參數(shù)作為輸入，輸出一個(gè)公共參考串（common reference string），記為CRS； P是證明算法，它以y∈LR的證明x作為輸入，輸出一個(gè)使得R（x,y）=1 的參數(shù) π ←PCRS(x,y) ； V 是驗(yàn)證算法，它以y和π作為輸出，驗(yàn)證結(jié)果正確輸出1，反之輸出0.

零知識(shí)證明要求具備3 個(gè)安全特性：

1）完 備 性.對(duì) 于 任 意 的 (x,y)∈R，如 果CRS←S etup(λ)， π ←PCRS(x,y) ， 那么 V(y,π)=1.

2）可靠性.對(duì)于任何概率多項(xiàng)式時(shí)間的敵手A而言，

3）零知識(shí)性.存在一個(gè)有效的模擬器S=(S1,S2)，對(duì)于任何概率多項(xiàng)式時(shí)間的敵手A，使得其中，試驗(yàn)ExptA(λ)和ExptSA(λ)的定義為：

其中 S′CRS(x,y,AUX)=S2CRS(y,AUX).

3 基于Intel SGX 的公鑰認(rèn)證可搜索加密

3.1 PAEKS-SGX 模型

根據(jù)1.1 節(jié)的分析，我們修改了原始PAEKS 模型[1]的陷門生成算法，將其輸入中的發(fā)送方公鑰pkS修改為接收方公鑰pkR，使之更符合云存儲(chǔ)的實(shí)際應(yīng)用場(chǎng)景.如圖1 所示，一個(gè)公鑰認(rèn)證可搜索加密方案由6 部分組成.

1）PAEKS.S etup(λ).輸入安全參數(shù) λ，輸出全局公開參數(shù)pp.

2）PAEKS.KeyGenR(pp).輸入公開參數(shù)pp，輸出接收者的公私鑰對(duì) (pkR,skR）.

3）PAEKS.KeyGenS(pp).輸入 公 開 參 數(shù)pp，輸 出發(fā)送者的公私鑰對(duì) (pkS,skS）.

4）PAEKS.PAEKS(pkR,skS,w).輸 入 接 收 者 公 鑰pkR、 發(fā)送者私鑰skS和關(guān)鍵詞w，輸出關(guān)鍵詞w的密文CT.

5）PAEKS.Trapdoor(skR,pkR,w′).輸 入 接 收 者 私鑰skR、 接收者公鑰pkR和 關(guān)鍵詞w′，輸出w′的陷門Tw′.

6）PAEKS.Test(pkR,pkS,CT,Tw′).輸入接收者公鑰pkR、 發(fā) 送 者 公 鑰pkS、 關(guān) 鍵 詞 密 文CT←PAEKS.PAEKS(pkR,skS,w)和 陷 門Tw′←PAEKS.Trapdoor(skR,pkR,w′)， 如果w=w′，輸出1，否則輸出0.

在本文中，我們借鑒了文獻(xiàn)[9]中提出的PAEKS方案的安全性定義，并對(duì)之做了一定的修改：

首先，文獻(xiàn)[10]指出文獻(xiàn)[9]中的密文不可區(qū)分性（ciphertext indistinguishability，CI-security）定義存在瑕疵：不允許敵手獲得挑戰(zhàn)關(guān)鍵詞的密文，在生成密文時(shí)使用了發(fā)送者私鑰的情形下，這導(dǎo)致滿足密文不可區(qū)分性的PAEKS 方案并不一定滿足多密文不可區(qū)分性.因此，我們修改了文獻(xiàn)[9]中的密文不可區(qū)分性定義，在生成挑戰(zhàn)關(guān)鍵詞密文后，允許敵手繼續(xù)詢問挑戰(zhàn)關(guān)鍵詞的密文，從而使該定義可以涵蓋多密文不可區(qū)分性.密文不可區(qū)分性定義了選擇關(guān)鍵詞攻擊，滿足CI-security 可以保證敵手無法從關(guān)鍵詞密文中獲得任何關(guān)鍵詞相關(guān)信息.

其次，針對(duì)陷門的安全性，我們認(rèn)為，因?yàn)樵谖墨I(xiàn)[9]的陷門隱私性（trapdoor privacy，TP-security）定義的詢問階段2 中限制了敵手無法對(duì)挑戰(zhàn)關(guān)鍵詞進(jìn)行陷門和關(guān)鍵詞密文詢問，所以文獻(xiàn)[9]中的陷門隱私性定義無法完全涵蓋所有陷門隱私泄露情況，比如如果關(guān)鍵詞的陷門生成算法是確定性的，那么敵手就可以根據(jù)2 次搜索的陷門是否相同來判斷是否搜索的是同一關(guān)鍵詞.因此，我們將該定義改名為陷門不可區(qū)分性（trapdoor indistinguishability，TI-security），但保持正式定義不變.陷門不可區(qū)分性定義中隱含著允許敵手嘗試自己構(gòu)造關(guān)鍵詞密文，因此如果方案同時(shí)滿足密文不可區(qū)分性和陷門不可區(qū)分性，則方案可以抵抗關(guān)鍵詞猜測(cè)攻擊.進(jìn)一步地，為了涵蓋敵手通過比較2 個(gè)陷門而獲得的隱私信息，我們?cè)黾恿艘粋€(gè)新的安全性定義，即搜索模式隱私性（search pattern privacy，SP-privacy）.搜索模式隱私性可以確保敵手無法僅通過陷門來判斷搜索的是否是同一關(guān)鍵詞，從而避免向外部敵手泄露部分隱私.

CI-security 旨在防止外部攻擊者在不知道關(guān)鍵詞陷門的情況下獲取加密文件中所包含的關(guān)鍵詞信息.CI-security 由敵手 A 和挑戰(zhàn)者 C參與的游戲定義為5 個(gè)步驟：

1）系統(tǒng)建立.輸入安全參數(shù) λ，挑戰(zhàn)者 C執(zhí)行PAEKS.S etup(λ)生成公共參數(shù)pp，然后執(zhí)行

并將生成的 (pp,pkR,pkS) 發(fā) 送給敵手 A.

2）詢問階段1.A 可以進(jìn)行2 種詢問：

①關(guān)鍵詞密文詢問.A將想要查詢的關(guān)鍵詞w發(fā)送給 C ， C 執(zhí)行算法CT←PAEKS.PAEKS(pkR,skS,w)，并將CT發(fā)回 A.

②陷門詢問.A將想要查詢的關(guān)鍵詞w發(fā)送給 C，C執(zhí)行算法Tw←PAEKS.Trapdoor(skR,pkR,w) ，并將Tw發(fā)回 A.

3）挑戰(zhàn)階段.A發(fā)送2 個(gè)未在詢問階段1 查詢過的 關(guān) 鍵 詞w0，w1給 C ， C 隨 機(jī) 選 擇b∈{0,1}，執(zhí) 行 算 法C*←PAEKS.PAEKS(pkR,skS,wb) ， 并 將 生 成 的C*作 為挑戰(zhàn)密文發(fā)回 A.

4）詢問階段2.在這一階段， A 可以繼續(xù)發(fā)送與詢問階段1 相同的詢問，但是在詢問陷門時(shí)所使用的關(guān)鍵詞w不能為w0或w1.

5）猜測(cè).敵手 A 猜測(cè) C 之前加密的是w0還 是w1，若猜對(duì)，則視為攻擊成功.

敵手 A在上述游戲中的優(yōu)勢(shì)可以定義為函數(shù):

定義1.如果對(duì)任何多項(xiàng)式時(shí)間敵手 A，存在一個(gè)可忽略的優(yōu)勢(shì) σ ，使得(λ)≤σ，那么PAEKS方案具備密文不可區(qū)分安全性.

TI-security 保證了內(nèi)外部攻擊者在拿到一個(gè)不知道關(guān)鍵詞的陷門時(shí)，無法獲取該關(guān)鍵詞陷門中所包含的關(guān)鍵詞信息.TI-security 由敵手 A 和挑戰(zhàn)者 C參與的游戲定為5 個(gè)步驟：

1）系統(tǒng)建立.輸入安全參數(shù) λ，挑戰(zhàn)者 C執(zhí)行PAEKS.S etup(λ)生成公共參數(shù)pp，然后執(zhí)行

并將生成的 (pp,pkR,pkS)發(fā) 送給敵手 A.

2）詢問階段1.A 可以進(jìn)行2 種詢問：

①關(guān)鍵詞密文詢問.A將想要查詢的關(guān)鍵詞w發(fā)送給 C ， C 執(zhí)行算法CT←PAEKS.PAEKS(pkR,skS,w)，并將CT發(fā)回 A.

②陷門詢問.A將想要查詢的關(guān)鍵詞w發(fā)送給 C，C執(zhí)行算法Tw←PAEKS.Trapdoor(skR,pkR,w) ，并將Tw發(fā)回 A.

3）挑戰(zhàn)階段.A發(fā)送2 個(gè)未在詢問階段1 查詢過的 關(guān) 鍵 詞w0，w1給 C ， C 隨 機(jī) 選 擇b∈{0,1}，執(zhí) 行 算 法T*←PAEKS.Trapdoor(skR,pkR,wb) ，并 將 生 成 的T*作為挑戰(zhàn)陷門發(fā)回 A.

4）詢問階段2.在這一階段， A 可以繼續(xù)發(fā)送與詢問階段1 相同的詢問，前提是所詢問的關(guān)鍵詞w不能為w0或w1.

5）猜 測(cè).敵手 A 猜 測(cè)T*是w0還 是w1的陷 門，若猜對(duì)，則視為攻擊成功.

敵手 A在上述游戲中的優(yōu)勢(shì)可以定義為函數(shù)：

定義2.如果對(duì)任何多項(xiàng)式時(shí)間的敵手 A，存在一個(gè)可忽略的優(yōu)勢(shì)，使得(λ)≤σ，那么PAEKS方案具備陷門不可區(qū)分安全性.

SP-privacy 保證了外部攻擊者在僅拿到2 個(gè)陷門的情況下，無法判斷2 個(gè)陷門是否對(duì)應(yīng)著同一個(gè)關(guān)鍵詞.SP-privacy 由敵手 A 和挑戰(zhàn)者 C參與的游戲定義為5 個(gè)步驟：

1）系 統(tǒng) 建 立.輸 入 安 全參數(shù) λ ，挑 戰(zhàn) 者 C執(zhí)行PAEKS.S etup(λ)生成公共參數(shù)pp，然后執(zhí)行

并將生成的 (pp,pkR,pkS)發(fā) 送給敵手 A.

2）詢問階段1.A 可以進(jìn)行2 種詢問：

①關(guān)鍵詞密文詢問.A將想要查詢的關(guān)鍵詞w發(fā)送給 C ， C 執(zhí)行算法CT←PAEKS.PAEKS(pkR,skS,w)，并將CT發(fā)回 A.

②陷門詢問.A將想要查詢的關(guān)鍵詞w發(fā)送給 C，C執(zhí)行算法Tw←PAEKS.Trapdoor(skR,pkR,w) ，并將Tw發(fā)回 A.

3）挑戰(zhàn)階段.A發(fā)送2 個(gè)未在詢問階段1 階段查詢過的關(guān)鍵詞w0，w1給 C ， C 隨機(jī)選擇b∈{0,1}，執(zhí)行算法T*←PAEKS.Trapdoor(skR,pkR,wb) ， 并將 生成的T*作為挑戰(zhàn)陷門發(fā)回 A.

4）詢問階段2.在這一階段， A 可以繼續(xù)發(fā)送與詢問階段1 相同的詢問，在關(guān)鍵詞密文詢問中，要求所詢問的關(guān)鍵詞w不能為w0或w1；而在陷門詢問中則沒有限制.

5）猜 測(cè).敵 手 A 猜測(cè)T*是w0還 是w1的陷門，若 猜對(duì)，則視為攻擊成功.

敵手 A在上述游戲中的優(yōu)勢(shì)可以定義為函數(shù)：

定義3.如果對(duì)任何多項(xiàng)式時(shí)間的敵手 A，存在一個(gè)可忽略的優(yōu)勢(shì)，使得(λ)≤σ，那么PAEKS方案具備搜索模式隱私性.

值得注意的是，在這3 個(gè)安全性定義中，均允許敵手訪問Test預(yù)言，該預(yù)言接收關(guān)鍵詞密文和陷門作為輸入，輸出匹配結(jié)果.

3.2 PAEKS-SGX 方案構(gòu)造

由于SGX 為程序提供了一個(gè)可靠的執(zhí)行環(huán)境執(zhí)行敏感操作，一個(gè)自然的構(gòu)造思路就是將私鑰加載到可信的執(zhí)行環(huán)境enclave 中，利用私鑰來解密公鑰加密的密文.這樣，如果關(guān)鍵詞密文和陷門都是由接收方公鑰加密的密文（各自包含發(fā)送方和接收方用私鑰對(duì)關(guān)鍵詞所做的簽名），那么就可以從密文中分別解密得到關(guān)鍵詞明文進(jìn)行比對(duì).PAEKS 方案不僅設(shè)計(jì)思路比較直接和簡(jiǎn)單，而且由于可以使用私鑰，所以很多擴(kuò)展功能就比較容易實(shí)現(xiàn)，如第5 節(jié)將介紹的面向多用戶場(chǎng)景的擴(kuò)展.但是，利用這個(gè)思路構(gòu)造PAEKS 方案的一個(gè)關(guān)鍵問題是：如果在關(guān)鍵詞密文和陷門生成時(shí)只使用公鑰加密1 次，那么在進(jìn)行安全性證明時(shí)，如果想要利用PAEKS 方案的敵手A來構(gòu)造一個(gè)公鑰加密方案的敵手 B ， 那么 B作 為 A的挑戰(zhàn)者，在不知道所挑戰(zhàn)的公鑰方案私鑰的前提下，該如何為 A生成陷門（這里的陷門隱含匹配算法所使用的enclave 程序）.而使用類似Naor-Yung 的INDCCA 公鑰加密方案“雙加密”構(gòu)造范式[3]，則可以在安全性證明時(shí)解決這個(gè)問題.

假設(shè)PKE=(KeyGen,Enc,Dec)是一個(gè)IND-CPA 安全公鑰密碼方案， ( P,V)是一個(gè)自適應(yīng)安全非交互零知識(shí)證明系統(tǒng)，S IG=(KeyGen,S ign,Ver)是一個(gè)EUFCMA 安全的簽名方案.在本文方案中，假設(shè)關(guān)鍵詞長(zhǎng)度相同①若長(zhǎng)度不同，可采用哈希函數(shù)將關(guān)鍵詞映射為長(zhǎng)度相同..PAEKS-SGX 方案（Setup,KeyGenR,KeyGenS,PAEKS,Trapdoor,Test）構(gòu)造為：

1）PAEKS.S etup(λ).選擇公鑰加密方案PKE，數(shù)字簽名方案SIG和非交互零知識(shí)證明系統(tǒng) (P,V)構(gòu)造如算法1 所示的enclave 搜索程序E(Csearch)，在服務(wù)器上建立enclave 執(zhí)行環(huán)境，其中的接收方私鑰為skR.sk1在搜索時(shí)由接收方與enclave 認(rèn)證后上傳到enclave 中.

2）PAEKS.KeyGenR(pp).執(zhí)行

設(shè)置接收者公私鑰對(duì)為

3）PAEKS.KeyGenS(pp).執(zhí)行

(pk,sk)←S IG.KeyGen(λ)，設(shè)置發(fā)送者公私鑰對(duì)為

4）PAEKS.PAEKS(pkR,skS,w).設(shè)pkR=(pk1,pk2,pk3,r←{0,1}poly(λ))是接收方的公鑰.假設(shè)w是文件中的一個(gè)關(guān)鍵詞，首先執(zhí)行sigw←S IG.S ign(skS,w)，然后計(jì)算PAEKS 密文CT=(C1,C2,Π)，其中

r1,r2是PKE.Enc算法使用的隨機(jī)性.

5）PAEKS.Trapdoor(skR,pkR,w′).設(shè)skR=(sk1,sk3)是接收方的私鑰.搜索某個(gè)關(guān)鍵詞w′時(shí)，計(jì)算搜索陷門Tw′=(,Π)，其中

r3,r4是PKE.Enc算法使用的隨機(jī)性，sigw′←S IG.S ign(sk3,w′)是 接收方利用私鑰sk3對(duì)w′的簽名.

6）PAEKS.Test(pkR,pkS,CT,Tw′).服務(wù)器將pkR,pkS,CT,Tw′傳 入enclave，執(zhí) 行enclave 搜 索 程 序E(Csearch)，獲取匹配結(jié)果.

算法1.enclave 搜索程序E(Csearch).

輸入：接收方的公鑰pkR=(pk1,pk2,pk3,r)，發(fā)送方的公鑰pkS=(pk,rS) ，接收方的私鑰skR.sk1，關(guān)鍵詞密文CT，搜索陷門Tw′；

輸出：匹配時(shí)為1，不匹配時(shí)為0.

①ifV(pkS.rS,(CT.C1,CT.C2),CT.Π)==0

② r eturn 0；

③endi f

④ifV(pkR.r,(Tw′.Tw1′,Tw′.Tw2′),Tw′.Π)==0

⑤ r eturn 0；

⑥end if

⑦w1||sigw1←PKE.Dec(skR.sk1,CT.C1)；

⑧ifSIG.Ver(pkS.pk,sigw1,w1)==false

⑨ return 0；

⑩else

?w2||sigw2←PKE.Dec(skR.sk1,Tw′.)；

?ifSIG.Ver(pkR.pk3,sigw2,w2)==false

? return 0；

?else

? ifw1==w2

? r eturn 1；

?else

? return 0；

?end if

?end if

?end if

3.3 安全性證明

定理1.PAEKS-SGX 方案具備密文不可區(qū)分安全性.

證明.我們通過如下一系列不可區(qū)分的游戲來證明.

Game0是PAEKS-SGX 的密文不可區(qū)分安全性CI游戲.

Game1除了挑戰(zhàn)者生成的enclave 搜索程序之外，其他和Game0完全相同.在這個(gè)游戲中，挑戰(zhàn)者生成enclave 搜 索 程 序E(C′search)而 不 是E(Csearch)，如 算 法2所示.在E(C′search)中，用接收方在生成公私鑰對(duì)時(shí)未使用的私鑰sk2代 替sk1， 解密CT.C2和Tw′.Tw2′.

Game2與Game1相比，除了 (P,V)替換成其模擬器（記作 Π′），其他和Game1完全相同.

不難看出，E(C′search)和E(Csearch)具有相同的功能.由于Intel SGX 的安全機(jī)制，僅從輸入輸出來看，E(Csearch)和E(C′search)是 不 可 區(qū) 分 的.因 此，Game0和Game1是無法區(qū)分的.

Game1和Game2也是無法區(qū)分的.因?yàn)槿绻嬖谝粋€(gè)敵手 A可以區(qū)分Game1和Game2，那么相當(dāng)于存在一個(gè)NIZK 的敵手 A′可以區(qū)分真實(shí)證明和模擬證明，這顯然是不成立的.

下面證明PAEKS-SGX 的敵手在Game2中的優(yōu)勢(shì)是可以忽略的.

假設(shè) A是Game2的一個(gè)敵手，它可以構(gòu)造一個(gè)IND-CPA 安全 的PKE 方案的敵手 B ， B在IND-CPA安全游戲中與它的挑戰(zhàn)者 C交互的同時(shí)，作為Game2的挑戰(zhàn)者與 A交互.具體構(gòu)造過程有5 個(gè)步驟：

1）系統(tǒng)建立.構(gòu)造如算法2 所示的enclave 搜索程序E(C′search)，在服務(wù)器上建立enclave執(zhí)行環(huán)境.挑戰(zhàn)者C執(zhí)行 (pk1,sk1)←PKE.KeyGen(λ)，生成的公鑰pk1發(fā)送給敵手 B，私鑰sk1由 C自行保管；敵手B執(zhí)行(pk2,sk2)←PKE.KeyGen(λ)，(pk3,sk3)←S IG.KeyGen(λ)和r←Sim1(λ)，私鑰B自行保管，接收者公鑰設(shè)為(pk1,pk2,pk3,r)，B生 成發(fā)送者公私鑰對(duì)(pkS,skS)，將公鑰(pk1,pk2,pk3,r,pkS)和構(gòu)造的enclave搜索程序E(C′search)發(fā) 送給敵手 A.

2）詢問階段1.A 可以向 B請(qǐng)求2 個(gè)詢問.

①關(guān)鍵詞密文詢問.A將想要查詢的關(guān)鍵詞w發(fā)送給 B ， B執(zhí) 行CT←PAEKS.PAEKS(pkR,skS,w)，并將CT發(fā)回 A.

②陷門詢問.A將想要查詢的關(guān)鍵詞w發(fā)送給 B，B 執(zhí) 行Tw←PAEKS.Trapdoor(skR,pkR,w)， 并 將Tw發(fā)回 A.注意這里還允許 A詢問Test操作的返回結(jié)果.

3）挑戰(zhàn)階段.首先 A發(fā)送2 個(gè)關(guān)鍵詞w0，w1給 B，B使 用 私 鑰skS對(duì)w0，w1簽 名 得 到sigw0,sigw1，并 將(w0||||sigw0,w1||||sigw1) 作為挑戰(zhàn)明文轉(zhuǎn)發(fā)給C.在 B 與C的交互中， B 作為敵手接收來自 C的挑戰(zhàn)密文C←PKE.Enc(pk1,w||sigw;r0)； 然 后 計(jì) 算C2←PKE.Enc(pk2,w0||sigw0;r1) ，Π′←S im2(C1,C2)； 最后以 A 挑戰(zhàn)者的身份 計(jì) 算CT=(C1,C2,Π′)，將CT作為PAEKS 的挑戰(zhàn)密文發(fā)送給 A.

4）詢問階段2.在這一階段， A 可以繼續(xù)執(zhí)行如詢問階段1 一樣的詢問，但是在詢問陷門時(shí)所使用的關(guān)鍵詞w不能為w0或w1.

5）猜測(cè).敵手 B輸出敵手 A的輸出內(nèi)容.

不難看出，如果 C 選擇 β=0（ 概率為 1/2），則此時(shí)B 為 A提供了一個(gè)完美的模擬；否則，通過非交互零知識(shí)證明系統(tǒng)的零知識(shí)性和可靠性， A在區(qū)分PAEKS 密文方面的優(yōu)勢(shì)可忽略.因此， B作為PKE 方案的IND-CPA 敵手，其優(yōu)勢(shì)相當(dāng)于Game2中敵手A優(yōu)勢(shì)的 1 /2.又因?yàn)樗诘腜KE 方案是IND-CPA 安全的，即 B的優(yōu)勢(shì)可忽略，所以敵手 A在Game2中的優(yōu)勢(shì)也是可以忽略的.由于Game2和Game0不可區(qū)分，因此密文不可區(qū)分性游戲Game0中敵手的優(yōu)勢(shì)可以忽略不計(jì).證畢.

算法2.enclave 搜索程序E(C′search).

輸入：接收方的公鑰pkR=(pk1,pk2,pk3,r)，發(fā)送方的公鑰pkS=(pk,rS) ，私鑰sk2， 關(guān)鍵詞密文CT，搜索陷門Tw′；

輸出：匹配時(shí)為1，不匹配時(shí)為0.

①ifV(pkS.rS,(CT.C1,CT.C2),CT.Π)==0

② r eturn 0；

③endif

④ifV(pkR.r,(Tw′.Tw1′,Tw′.Tw2′),Tw′.Π)==0

⑤ r eturn 0；

⑥end if

⑦w1||sigw1←PKE.Dec(sk2,CT.C2)；

⑧ifSIG.Ver(pkS.pk,sigw1,w1)==false

⑨ r eturn 0；

⑩else

?w2||sigw2←PKE.Dec(sk2,Tw′.Tw2′)；

?ifSIG.Ver(pkR.pk3,sigw2,w2)==false

? r eturn 0；

?else

? ifw1==w2

? r eturn 1；

?else

? r eturn 0；

?end if

?end if

?end if

定理2.PAEKS-SGX 具有陷門不可區(qū)分性.

證明.可以看出陷門的生成過程實(shí)際上就是Naor-Yung 的IND-CCA 公鑰加密構(gòu)造范式[3]中加密明文w′||sigw′的過程，而陷門不可區(qū)分性的定義與INDCCA 安全性的定義是類似的.所以在敵手無法自己構(gòu)造關(guān)鍵詞密文情況下，可以利用Naor-Yung 范式[3]的證明思路證明我們方案的陷門不可區(qū)分性.具體證明過程不再詳述.

接下來證明，若敵手嘗試構(gòu)造挑戰(zhàn)關(guān)鍵詞的密文并能通過挑戰(zhàn)陷門Tw’的測(cè)試，那么可以構(gòu)造一個(gè)具有EUF-CMA 安全性的簽名方案SIG 的敵手，從而打破簽名方案SIG 的EUF-CMA 安全性.由于簽名方案的敵手打破EUF-CMA 安全性的優(yōu)勢(shì)是可以忽略不計(jì)的，所以PAEKS-SGX 中敵手無法自己構(gòu)造關(guān)鍵詞密文.所以綜合可知PAEKS-SGX 具有陷門不可區(qū)分性.證畢.

下面我們介紹EUF-CMA 安全簽名方案敵手的具體構(gòu)造過程.

假設(shè) A是陷門不可區(qū)分性游戲的敵手，嘗試構(gòu)造挑戰(zhàn)關(guān)鍵詞的密文， B是我們想要構(gòu)造的EUFCMA 安全簽名方案的一個(gè)敵手，它在EUF-CMA 安全游戲中與它的挑戰(zhàn)者 C交互的同時(shí)，作為挑戰(zhàn)者與A交互.在EUF-CMA 安全性游戲中執(zhí)行算法(sk,pk)←S IG.KeyGen(λ)，生成的私鑰sk自行保存，公鑰pk發(fā)送給它的敵手 B.然后 B執(zhí)行

私鑰自行保存，將pkR=(pk1,pk2,pk3,r)作為接收方的公鑰發(fā)送給它的敵手 A.同樣， B還 要將pkS=pk作為發(fā)送方公鑰發(fā)送給敵手 A.當(dāng)敵手 A 向 B進(jìn)行關(guān)鍵詞密文詢問時(shí)， B向它的挑戰(zhàn)者 C詢問對(duì)該關(guān)鍵詞的簽名，然后生成關(guān)鍵詞密文；當(dāng)敵手 A 向 B進(jìn)行陷門詢問時(shí)，由于 B自己生成接收者的公私鑰對(duì)，所以直接利用接收者私鑰生成陷門.最終，對(duì)于挑戰(zhàn)陷門，如果敵手 A 通過構(gòu)造關(guān)鍵詞密文CT=(C1,C2,Π)，其中

并通過Test成功判斷陷門中的關(guān)鍵詞，我們可知其中的簽名sigw必然可以用發(fā)送方公鑰進(jìn)行正確的驗(yàn)證，即敵手 A成功地對(duì)挑戰(zhàn)關(guān)鍵詞構(gòu)造了在發(fā)送者私鑰下的簽名sigw，即可打破簽名方案的EUF-CMA安全性.

定理3.PAEKS-SGX 具有搜索模式隱私性.

證明.首先，由于SGX 的安全特性，enclave 中的搜索程序是安全可靠的.其次，同定理2 的證明，可以看到關(guān)鍵詞w′的陷門實(shí)際上就是Naor-Yung 的IND-CCA 公鑰加密構(gòu)造范式中加密明文w′||sigw′后得到的密文[3].如果敵手僅通過關(guān)鍵詞陷門就能判斷陷門中是否是同一關(guān)鍵詞，那么實(shí)際上相當(dāng)于在利用Naor-Yung 范式構(gòu)造的IND-CCA 方案中可以通過挑戰(zhàn)密文區(qū)分挑戰(zhàn)明文，也就打破了Naor-Yung 范式的IND-CCA 安 全 性.因 此，PAEKS-SGX 具 有 搜 索 模式隱私性.證畢.

3.4 密鑰管理

由對(duì)PAEKS-SGX 的描述可以看到，我們構(gòu)造的enclave 搜索程序的正確運(yùn)行需要文件接收方的私鑰，因此如何對(duì)該私鑰進(jìn)行安全有效地管理，是需要考慮的一個(gè)重要問題.PAEKS-SGX 采用Intel SGX 遠(yuǎn)程認(rèn)證技術(shù)和Intel SGX 密封技術(shù)，給出了一個(gè)行之有效的解決方案.該方案中，接收方可以在初始時(shí)將其私鑰skR.sk1用私鑰傳遞過程發(fā)送到enclave 搜索程序中，然后enclave 可將該私鑰利用密封技術(shù)加密保存在硬盤中對(duì)應(yīng)存儲(chǔ)位置.當(dāng)后續(xù)再需要搜索時(shí)，enclave 可以從硬盤中將密封的接收方私鑰讀入enclave 并解封得到skR.sk1.

1）私鑰傳遞.通過Intel SGX 遠(yuǎn)程認(rèn)證技術(shù)，用戶可以和云服務(wù)器上的enclave 通過Diffie-Hellman 密鑰交換協(xié)議建立一個(gè)安全的信道，文件接收方可以通過此信道將私鑰發(fā)送到云服務(wù)器的enclave 搜索程序中.

2）私鑰保存.對(duì)于enclave 來說，其本身是沒有狀態(tài)的，當(dāng)云服務(wù)器關(guān)機(jī)、重啟或應(yīng)用程序退出時(shí)，enclave 就會(huì)被銷毀，此后，其中的所有內(nèi)容都會(huì)丟失，因此安全地將其中的數(shù)據(jù)如私鑰等保存到enclave 外的非可信內(nèi)存中是必要的.通過Intel SGX 密封技術(shù)，我們可以實(shí)現(xiàn)這個(gè)目的.在接收到文件接收方發(fā)送的私鑰之后，enclave 搜索程序可以使用MRENCLAVE或 MRSIGNER 將其加密，然后保存到enclave 之外的地方，比如硬盤中.

3）私鑰加載.在enclave 搜索程序中，可以調(diào)用ecall 接口從硬盤中讀取密封的私鑰，然后在enclave中進(jìn)行解密.為了降低ecall 引起的CPU 模式切換開銷，我們將最近使用的私鑰保存到私鑰緩沖區(qū)，每次調(diào)用ecall 接口讀取私鑰之前，先檢查所需的私鑰是否在緩沖區(qū)，然后再選擇是否去硬盤中讀取.同時(shí)為了節(jié)省enclave 的內(nèi)存使用，使用LRU（least recently used）策略來定期刷新私鑰緩沖區(qū).

3.5 PAEKS-SGX 方案實(shí)施架構(gòu)

PAEKS-SGX 方案具體實(shí)施時(shí)的整體架構(gòu)如圖2所示，該框架共有2 個(gè)行為主體，云服務(wù)器和用戶，其中，云服務(wù)器由云存儲(chǔ)、云應(yīng)用和enclave 搜索程序3 部分組成.

Fig.2 The architecture of PAEKS-SGX圖2 PAEKS-SGX 架構(gòu)

在云存儲(chǔ)中，我們只關(guān)注PAEKS-SGX 密文和密封的密鑰.在云應(yīng)用中，我們簡(jiǎn)單地將其劃分為主程序和文件加載器2 部分，其中主程序負(fù)責(zé)和enclave搜索交互，包括enclave 的創(chuàng)建、運(yùn)行、中斷、銷毀等，文件加載器負(fù)責(zé)從云存儲(chǔ)中讀取文件.在enclave 搜索程序中，為了更直觀地表示，我們將其抽象為匹配器和密鑰管理器2 部分，其中匹配器執(zhí)行公鑰可搜索加密的驗(yàn)證階段，密鑰管理器負(fù)責(zé)將云應(yīng)用發(fā)送的密鑰解封.用戶enclave 程序中，我們只表示了SGX 遠(yuǎn)程驗(yàn)證執(zhí)行器，將其用于與云服務(wù)器上的enclave 搜索程序進(jìn)行遠(yuǎn)程驗(yàn)證和建立安全信道來傳遞私鑰.

一般情況下，公鑰可搜索加密的驗(yàn)證階段可由圖2 中的過程①～⑥來表示：首先用戶向云服務(wù)器發(fā)送搜索陷門，云應(yīng)用從云存儲(chǔ)中讀取關(guān)鍵詞密文、用戶公鑰和密封的密鑰，并將它們發(fā)送給enclave.然后在enclave 中，密鑰管理器解封密鑰，匹配器執(zhí)行公鑰可搜索加密的驗(yàn)證算法，并將結(jié)果返回給云應(yīng)用.最后，云應(yīng)用銷毀enclave 搜索程序，并將搜索結(jié)果發(fā)送給用戶.

圖2 還表示了用戶enclave 程序和云服務(wù)器enclave 搜索程序之間的遠(yuǎn)程認(rèn)證過程.用戶可以通過遠(yuǎn)程認(rèn)證對(duì)運(yùn)行在云服務(wù)器上的enclave 搜索程序的初始化、結(jié)構(gòu)、代碼完整性等進(jìn)行驗(yàn)證，并可以將通過遠(yuǎn)程認(rèn)證建立安全信道來傳遞用戶私鑰.事實(shí)上，遠(yuǎn)程認(rèn)證需要使用云服務(wù)器上的一個(gè)身份公認(rèn)的特殊enclave，稱為引用（quoting）enclave，由它創(chuàng)建用于平臺(tái)認(rèn)證的EPID（enhanced privacy identification）.當(dāng)enclave 搜索程序收到用戶enclave 的遠(yuǎn)程認(rèn)證請(qǐng)求時(shí)，首先需要執(zhí)行EREPORT 指令，將身份和附加信息組合生成REPORT 結(jié)構(gòu)，并使用引用enclave 的報(bào)告密鑰（REPORT KEY）生成一個(gè)MAC 并交由引用enclave 驗(yàn)證身份.驗(yàn)證通過后，引用enclave 會(huì)將其封裝成引用結(jié)構(gòu)體QUOTE，并使用EPID 密匙進(jìn)行簽名.最后將QUOTE 及其簽名一并發(fā)送給用戶enclave.用戶enclave 便可以驗(yàn)證enclave 搜索程序的身份是否合法.為了突出本文方案的整體架構(gòu)，遠(yuǎn)程認(rèn)證的細(xì)節(jié)在圖2 中我們并沒有展開闡述.

4 實(shí)驗(yàn)結(jié)果與分析

本節(jié)將PAEKS-SGX 方案部署到真實(shí)環(huán)境中進(jìn)行測(cè)試，并和其他方案進(jìn)行對(duì)比，根據(jù)在關(guān)鍵詞密文生 成（PEKS/PAEKS）、陷 門 生 成（Trapdoor）、匹 配（Test）等方面的具體表現(xiàn)對(duì)PAEKS-SGX 進(jìn)一步分析.

4.1 實(shí)驗(yàn)環(huán)境及部署

測(cè)試環(huán)境配置為：支持Intel SGX 的主機(jī)，Windows 10，Intel?CoreTMi7-8700 CPU（6 核，3.20 GHz，12 MB 高速緩存），內(nèi)存16.0 GB（15.8 GB 可用），SGX SDK 2.14，Intel SGX Driver 2.15.

PAEKS-SGX 的具體實(shí)施過程為：

1）部署enclave 中的代碼，主要包括算法1 的實(shí)現(xiàn)代碼（匹配器的核心代碼），以及遠(yuǎn)程認(rèn)證、密鑰封裝和讀入封裝密鑰并解封的代碼（密鑰管理器的核心代碼）.

2）接收方執(zhí)行SGX 遠(yuǎn)程認(rèn)證建立安全信道，并將自己的私鑰通過安全信道發(fā)送給enclave，enclave將私鑰密封寫入相應(yīng)文件（注意，該操作只需要執(zhí)行1 次）.

3）當(dāng)接收方對(duì)某個(gè)關(guān)鍵詞進(jìn)行搜索時(shí)，過程有3 步：

①接收方在本地執(zhí)行陷門生成算法，生成待搜索關(guān)鍵詞的搜索陷門發(fā)送給云服務(wù)器.

②云服務(wù)器首先調(diào)用密鑰管理器程序，將接收方的私鑰密封文件作為輸入，執(zhí)行私鑰解封.需要說明的是，當(dāng)云服務(wù)器收到某個(gè)用戶的1 次搜索請(qǐng)求時(shí)，會(huì)使用收到的搜索陷門對(duì)所有文件的關(guān)鍵詞密文進(jìn)行匹配，即多次執(zhí)行匹配器程序.因?yàn)槠ヅ鋾r(shí)使用的用戶私鑰是相同的，所以，對(duì)于1 次搜索請(qǐng)求，解封過程只需執(zhí)行1 次，后續(xù)對(duì)所有關(guān)鍵詞密文的匹配則無需再次解封用戶私鑰.

③云服務(wù)器利用關(guān)鍵詞密文、搜索陷門、接收方公鑰以及文件對(duì)應(yīng)的發(fā)送方公鑰作為輸入，調(diào)用enclave 里的匹配器程序，得到搜索結(jié)果.

4.2 實(shí)驗(yàn)結(jié)果分析

PAEKS-SGX 實(shí)現(xiàn)中，本文的加密算法采用ElGamal公鑰加密算法，簽名算法采用ElGamal 簽名算法，零知識(shí)證明方案驗(yàn)證ElGamal 加密的2 個(gè)密文是在不同公鑰下對(duì)同一明文的加密密文.PAEKS-SGX 和所有對(duì)比方案（Boneh 等人[1]的方案、Huang 等人[9]的方案和Qin 等人[10]的方案）均采用256 b 安全強(qiáng)度.由于對(duì)比方案均基于雙線性配對(duì)實(shí)現(xiàn)，因此本文基于PBC 庫對(duì)雙線性群上的基本元素操作進(jìn)行測(cè)試，得出雙線性群上的基本操作時(shí)間，如表1 所示.

Table 1 Computation Time of Basic Element Operation表1 基本元素操作的計(jì)算時(shí)間

首先，我們分析用戶與SGX 進(jìn)行遠(yuǎn)程認(rèn)證，enclave 密封用戶私鑰所需的時(shí)間.測(cè)試結(jié)果顯示，該過程的平均用時(shí)為3.3 s.雖然時(shí)間達(dá)到了秒級(jí)，但由于在整個(gè)系統(tǒng)生命周期，對(duì)于一個(gè)用戶來說，該過程只需執(zhí)行1 次，所以我們認(rèn)為這個(gè)時(shí)間消耗是可以接受的.

接下來我們從關(guān)鍵詞密文生成（PEKS/PAEKS）、陷門生成（Trapdoor）、匹配（Test）這3 個(gè)階段對(duì)所有方案進(jìn)行測(cè)試.需要指出的是，在PAEKS 中，當(dāng)我們把關(guān)鍵詞長(zhǎng)度設(shè)定為256 b 且使用ElGamal 加密和簽名算法時(shí)，w||sigw的長(zhǎng)度是關(guān)鍵詞w長(zhǎng)度的3 倍，對(duì)w||sigw進(jìn)行ElGamal 加密時(shí)需要將其分為3 組，各組對(duì)應(yīng)1 個(gè)零知識(shí)證明.這也意味著在匹配算法中要合計(jì)驗(yàn)證6 次零知識(shí)證明，時(shí)間消耗比較大.而且此時(shí)實(shí)際的關(guān)鍵詞密文和陷門長(zhǎng)度也會(huì)擴(kuò)大3 倍，即6組ElGamal 加密的密文和3 組零知識(shí)證明.因此我們對(duì)方案做了改進(jìn)，在關(guān)鍵詞密文和陷門生成算法中，除了生成w||sigw的 密文外，還要計(jì)算Hash（w||sigw）的密文，其中Hash（·）是一個(gè)輸出長(zhǎng)度為256 b 的哈希函數(shù).我們不再計(jì)算針對(duì)w||sigw的密文的零知識(shí)證明，而是計(jì)算針對(duì)Hash（w||sigw）的密文的零知識(shí)證明.在enclave 里的匹配算法中，首先驗(yàn)證該零知識(shí)證明，在驗(yàn)證通過后解密得到w||sigw和Hash（w||sigw），然后利用哈希計(jì)算w||sigw的 哈希值，并與Hash（w||sigw）進(jìn)行比較，比較通過后再進(jìn)行簽名驗(yàn)證.通過這種改進(jìn)，匹配算法中零知識(shí)證明驗(yàn)證的次數(shù)變?yōu)?，關(guān)鍵詞密文和陷門變?yōu)? 組ElGamal 加密的密文加1 組零知識(shí)證明，實(shí)際長(zhǎng)度大約變?yōu)樵瓉淼?/2.各方案每個(gè)階段的執(zhí)行時(shí)間見圖3.如圖3 所示，在PEKS/PAEKS中，所有對(duì)比方案耗時(shí)均超過30 ms，而 PAEKS-SGX速度僅為1.15 ms；在Trapdoor 中，所有對(duì)比方案耗時(shí)均在12 ms 以上， PAEKS-SGX 僅耗時(shí)1.15 ms；在最受關(guān)注的Test 中， PAEKS-SGX 僅需2.00 ms 即可完成單次驗(yàn)證，而對(duì)比方案最快也需要6.51 ms.可見，PAEKS-SGX 在每個(gè)階段都具有明顯的速度優(yōu)勢(shì)，這和PAEKS-SGX 沒有使用雙線性群的元素操作有很大關(guān)系.

Fig.3 Comparison of time costs in different schemes圖3 不同方案耗時(shí)對(duì)比

在上面的測(cè)試中， PAEKS-SGX 的匹配算法并未包含enclave 讀取接收方的私鑰密封文件并解封的操作.下面我們考慮包含私鑰讀取和解封操作，并分析服務(wù)器收到1 次搜索請(qǐng)求后完成搜索過程所需的時(shí)間.設(shè)當(dāng)前待搜索的文件總數(shù)為N，每個(gè)文件的關(guān)鍵詞個(gè)數(shù)為M，我們首先測(cè)試了SGX 執(zhí)行私鑰解封（含讀入封裝文件的過程）的時(shí)間，其平均用時(shí)為4.5 ms.當(dāng)采用順序匹配的策略時(shí)，每個(gè)文件的關(guān)鍵詞匹配次數(shù)均值為M/2.所以，對(duì)比方案對(duì)1 個(gè)關(guān)鍵詞陷門執(zhí)行匹配的總時(shí)間均值為各自匹配算法的執(zhí)行時(shí)間乘以MN/2，即，均不小于6.51×MN/2 ms.而PAEKSSGX 對(duì)1 個(gè)關(guān)鍵詞陷門進(jìn)行匹配時(shí)，總的匹配時(shí)間均值=一次私鑰解封的時(shí)間+單個(gè)關(guān)鍵詞密文匹配時(shí)間×MN/2 = 4.5+2.00×MN/2 ms.當(dāng)MN較大時(shí)，一次私鑰解封的時(shí)間可以忽略不計(jì)，總匹配時(shí)間均值可視作2.00×MN/2 ms，所以PAEKS-SGX 在總的匹配時(shí)間上依然有著很大的優(yōu)勢(shì).

更進(jìn)一步地，我們根據(jù)關(guān)鍵詞的數(shù)量變化，測(cè)試了不同數(shù)量的關(guān)鍵詞時(shí)相應(yīng)算法的執(zhí)行時(shí)間，結(jié)果如圖4～6 所示.

Fig.4 Comparison of time cost of PEKS/PAEKS generation in different schemes圖4 不同方案生成PEKS/PAEKS 耗時(shí)對(duì)比

Fig.5 Comparison of time cost of Trapdoor generation in different schemes圖5 不同方案生成Trapdoor 耗時(shí)對(duì)比

Fig.6 Comparison of time cost of Test generation in different schemes圖6 不同方案生成Test 耗時(shí)對(duì)比

如圖4～6 所示，PAEKS-SGX 的優(yōu)勢(shì)是十分明顯的：在PEKS/PAEKS 生成階段生成1 000 個(gè)關(guān)鍵詞的密文時(shí)，PAEKS-SGX 耗時(shí)控制在1 s 左右，而其他方案則需要30 s 以上；Trapdoor 生成階段，PAEKS-SGX同樣具有領(lǐng)先其他方案至少10 倍以上的速度優(yōu)勢(shì)；而在Test 階段，匹配1 000 個(gè)（關(guān)鍵詞，陷門）對(duì)時(shí)，PAEKSSGX 相比起其他方案仍然具有明顯的速度優(yōu)勢(shì).

在方案的通信量分析方面，表2 給出了PAEKSSGX 和3 個(gè)對(duì)比方案的關(guān)鍵詞密文大小和搜索陷門的大小.結(jié)果顯示，PAEKS-SGX 的通信量比對(duì)比方案要大.但我們認(rèn)為，無論是關(guān)鍵詞密文大小還是陷門的大小都在幾百字節(jié)的量級(jí)，對(duì)于網(wǎng)絡(luò)通信和具有大容量存儲(chǔ)的云服務(wù)器來說，均是可接受的.

Table 2 Communication Overhead Comparison表2 通信量比較

5 方案擴(kuò)展

PAEKS-SGX 具有易擴(kuò)展的優(yōu)勢(shì)，一些新的功能只需在現(xiàn)有方案的基礎(chǔ)上稍加修改即可.下面我們介紹如何擴(kuò)展方案支持多關(guān)鍵詞搜索、如何擴(kuò)展方案到多用戶場(chǎng)景以及如何支持前向安全性.

5.1 多關(guān)鍵詞搜索

PAEKS-SGX 可以擴(kuò)展為支持多關(guān)鍵詞搜索功能.在進(jìn)行多關(guān)鍵詞搜索功能的擴(kuò)展時(shí)，首先，不能要求預(yù)先對(duì)關(guān)鍵詞排序；其次，不能在搜索陷門中暴露搜索的關(guān)鍵詞個(gè)數(shù)，即滿足搜索模式隱私性，且搜索陷門大小與待搜索的關(guān)鍵詞個(gè)數(shù)無關(guān).

1）基本思路.在生成關(guān)鍵詞密文的時(shí)候，用所有關(guān)鍵詞計(jì)算1 個(gè)布隆過濾器BFw，然后為這個(gè)布隆過濾器生成關(guān)鍵詞密文.生成搜索陷門的時(shí)候，同樣使用待搜索的多個(gè)關(guān)鍵詞計(jì)算1 個(gè)布隆過濾器BF.對(duì)BF生成陷門，將enclave 搜索程序E(Csearch)的部分代碼稍作修改，解密之后，將比對(duì)關(guān)鍵詞的過程改為布隆過濾器的按位與操作，即BFr=BFw&BF， 若BFr==BF，則輸出1，完成對(duì)1 個(gè)文件的匹配過程.詳見算法3.

算法3.enclave 多關(guān)鍵詞搜索程序E(Csearchmul-kw).

輸入：接收方的公鑰pkR=(pk1,pk2,pk3,r)，發(fā)送方的公鑰pkS=(pk,rS) ，接收方的私鑰skR.sk1，關(guān)鍵詞密文CT，搜索陷門Tw′；

輸出：無.

① ifV(pkS.rS,(CT.C1,CT.C2),CT.Π)==0

② r eturn 0；

③end if

④ ifV(pkR.r,(Tw′.Tw1′,Tw′.Tw2′),Tw′.Π)==0

⑤ r eturn 0；

⑥end if

⑦BFw||sigBFw←PKE.Dec(skR.sk1,CT.C1)；

⑧ ifS IG.Ver(pkS.pk,sigBFw,BFw)==false

⑨ return 0；

⑩else

?BF||sigBF←PKE.Dec(skR.sk1,Tw′.Tw1′)；

? ifS IG.Ver(pkR.pk3,sigBF,BF)==false

? r eturn 0；

?else

? ifBFw&BF==BF

? r eturn 1；

?else

? r eturn 0；

?end if

?end if

?end if

2） PAEKS-SGX 的安全性.與單關(guān)鍵詞搜索的方案相比，多關(guān)鍵詞搜索的方案僅僅是將關(guān)鍵詞替換為布隆過濾器，然后對(duì)布隆過濾器生成關(guān)鍵詞密文、搜索陷門.因此不會(huì)影響方案的安全性.

需要指出的是，PAEKS-SGX 使用布隆過濾器存在假陽性率，且布隆過濾器的密文所需的存儲(chǔ)空間比單關(guān)鍵詞密文要大.例如，當(dāng)系統(tǒng)內(nèi)有1 000 個(gè)關(guān)鍵詞，假陽性率為10-6時(shí)，采用16 個(gè)不同的哈希函數(shù)，則對(duì)應(yīng)的關(guān)鍵詞密文大約需要3 KB 的存儲(chǔ)空間.雖然這個(gè)存儲(chǔ)空間比單關(guān)鍵詞密文的存儲(chǔ)空間（如32 B）要大得多，但當(dāng)1 個(gè)文件包含l個(gè)關(guān)鍵詞時(shí)，單關(guān)鍵詞搜索方案中的關(guān)鍵詞密文需要32lB 存儲(chǔ)空間，當(dāng)l=100 時(shí)，所需存儲(chǔ)空間與多關(guān)鍵詞方案基本相同.因此，我們認(rèn)為這個(gè)存儲(chǔ)空間的消耗是可以接受的.

5.2 多用戶場(chǎng)景

在傳統(tǒng)的公鑰可搜索加密場(chǎng)景中，文件發(fā)送方將數(shù)據(jù)分享給文件接收方后，只有文件接收方擁有合法的搜索能力，但有些情況下這也會(huì)帶來不便.

想象下面這個(gè)場(chǎng)景：文件接收方想在不下載文件的前提下，把從文件發(fā)送方收到的數(shù)據(jù)中的一部分分享給第2 個(gè)文件接收方，一方面要分享文件密文，另一方面還要分享關(guān)鍵詞密文，從而讓第2 個(gè)文件接收方有搜索能力.通常的云數(shù)據(jù)共享過程中，發(fā)送方會(huì)用一個(gè)對(duì)稱密鑰key對(duì)文件進(jìn)行分組加密，然后將key用接收方公鑰加密發(fā)送給接收方.當(dāng)接收方想將數(shù)據(jù)共享給另一個(gè)用戶時(shí)，只需將密鑰key用該用戶的公鑰加密發(fā)送給他即可.但是如何同時(shí)將文件搜索能力也分享給該用戶，是需要解決的問題.第1 個(gè)文件接收方不能把用于生成陷門的私鑰發(fā)給第2 個(gè)文件接收方，而重新生成的第2 個(gè)文件接收方可以搜索的關(guān)鍵詞密文則需要下載文件、抽取關(guān)鍵詞，會(huì)增加交互次數(shù)和通信負(fù)載.

上述場(chǎng)景中解決問題的關(guān)鍵在于關(guān)鍵詞密文的重加密，可以采用代理重加密的方式由云服務(wù)器將關(guān)鍵詞密文轉(zhuǎn)換為第2 個(gè)接收方可以搜索的密文.而在PAEKS-SGX 中，利用enclave 可以很方便地實(shí)現(xiàn)重加密過程.

如圖7 所示，上述場(chǎng)景共有4 個(gè)行為主體，分別是文件發(fā)送方、第1 個(gè)文件接收方、第2 個(gè)文件接收方和enclave 重加密程序，其中enclave 重加密程序的功能是將由第1 個(gè)文件接收方公鑰加密的關(guān)鍵詞密文轉(zhuǎn)換成由第2 個(gè)文件接收方公鑰加密的密文.第1個(gè)文件接收方將部分?jǐn)?shù)據(jù)的關(guān)鍵詞搜索能力分享給第2 個(gè)文件接收方的具體操作是一個(gè)簡(jiǎn)單的“解密再加密”的過程，即原始關(guān)鍵詞密文以及密封的第1個(gè)文件接收方私鑰由外部的非可信程序發(fā)送給enclave 重加密程序，在enclave 重加密程序中用第1個(gè)文件接收方的私鑰解密關(guān)鍵詞密文，再用第2 個(gè)文件接收方的公鑰加密得到新的關(guān)鍵詞密文.

Fig.7 Share of PAEKS-SGX ciphertext圖7 PEKS-SGX 密文共享

這樣，云服務(wù)器就擁有了第2 個(gè)文件接收方公鑰加密的關(guān)鍵詞密文，第2 個(gè)文件接收方也就擁有了合法的關(guān)鍵詞搜索能力.整個(gè)過程的安全性由enclave程序本身的安全特性所保證，核心操作也是在云端完成，無需多余的交互和通信負(fù)載.相比之前那些利用代理重加密的PEKS 方案，PAEKS-SGX 的這種擴(kuò)展能夠在無需指定驗(yàn)證人的情況下抵抗關(guān)鍵詞猜測(cè)攻擊，且滿足搜索模式隱私性，即陷門生成算法是隨機(jī)的.

5.3 前向安全性

前向安全性最早是在動(dòng)態(tài)對(duì)稱可搜索加密方案（dynamic symmetric searchable encryption, DSSE）的構(gòu)造中提出的，旨在確保用之前的搜索陷門無法搜索到新增加的文件.因?yàn)槲募⑷牍鬧22]這種攻擊方式的存在，如果DSSE 方案不具備前向安全性，敵手可以恢復(fù)所有文件所包含的關(guān)鍵詞，所以很多研究者都在研究如何構(gòu)造支持前向安全性的DSSE 方案.而實(shí)際上，文件注入攻擊更容易施加在傳統(tǒng)公鑰可搜索加密的場(chǎng)景，因?yàn)槲募⑷霑r(shí)只需要用接收者的公鑰即可，這其實(shí)相當(dāng)于一種關(guān)鍵詞猜測(cè)攻擊.但是，一個(gè)PEKS 方案可以抗關(guān)鍵詞猜測(cè)攻擊并不意味著一定具有前向安全性，因?yàn)榧词箶呈植荒苤鲃?dòng)進(jìn)行文件注入攻擊（如在公鑰認(rèn)證可搜索加密方案中），敵手依然可以根據(jù)接收者之前發(fā)送的陷門以及匹配結(jié)果判斷后續(xù)的文件是否跟前面的文件具有相同的關(guān)鍵詞，進(jìn)而當(dāng)關(guān)鍵詞空間較小的時(shí)候可以通過搜索頻率來推測(cè)關(guān)鍵詞信息[23].

由此分析可知，前向安全性依然需要在抗關(guān)鍵詞猜測(cè)攻擊的PEKS 方案中被考慮，即我們的公鑰認(rèn)證可搜索加密方案也需要考慮前向安全性.PAEKSSGX 的實(shí)現(xiàn)機(jī)制使得我們可以很方便地將其修改為具有前向安全性，只需要在關(guān)鍵詞密文和陷門生成時(shí)均加入時(shí)間戳信息，在匹配的時(shí)候?qū)饷艹龅臅r(shí)間戳作比較，如果陷門時(shí)間戳早于關(guān)鍵詞密文時(shí)間戳，則enclave 中直接返回0 即可.

6 結(jié)束語

針對(duì)PEKS 方案的抵抗關(guān)鍵詞猜測(cè)攻擊以及PEKS 方案的搜索能力共享（多用戶）等問題，本文首次提出了一個(gè)在正式公鑰認(rèn)證可搜索加密安全性模型下可證明安全的基于SGX 的PAEKS 方案，方案可抵抗關(guān)鍵詞猜測(cè)攻擊，具有搜索模式隱私性和易擴(kuò)展性，能夠很方便地?cái)U(kuò)展到多用戶情形，支持較為復(fù)雜的搜索功能以及增強(qiáng)的安全性.實(shí)驗(yàn)結(jié)果表明，相比于傳統(tǒng)的PEKS 方案以及傳統(tǒng)的PAEKS 方案，本文提出的PAEKS-SGX 具有較高的效率優(yōu)勢(shì).另外PAEKS-SGX 具有一定的通用性，可以基于任何可信執(zhí)行環(huán)境、任意IND-CPA 安全的公鑰加密算法及相應(yīng)的非交互零知識(shí)證明方法，在具體實(shí)施時(shí)根據(jù)實(shí)際的硬件支持情況選擇高效的對(duì)應(yīng)算法來實(shí)現(xiàn)整個(gè)方案.

作者貢獻(xiàn)聲明：劉永志負(fù)責(zé)完成實(shí)驗(yàn)和數(shù)據(jù)分析，并撰寫論文初稿；秦桂云負(fù)責(zé)方法調(diào)研，并參與部分論文撰寫；劉蓬濤參與方案的實(shí)驗(yàn)設(shè)計(jì)和論文修改；胡程瑜提出方案的概念、設(shè)計(jì)方法和證明思路，并修改論文；郭山清提出指導(dǎo)意見并參與論文修改.