基于Intel SGX 的安全數(shù)據(jù)去重方法*

張新宇, 咸鶴群, 盧 倩, 田呈亮

1. 青島大學計算機科學技術學院, 青島 266071

2. 中國科學院信息工程研究所信息安全國家重點實驗室, 北京 100093

1 引言

云存儲作為一項能夠為用戶提供強大的數(shù)據(jù)管理和存儲能力的云服務, 現(xiàn)已成為企業(yè)單位以及個人存儲和管理數(shù)據(jù)的主要手段. 隨著云存儲規(guī)模的不斷增長, 越來越多重復的數(shù)據(jù)被存儲到云服務器上, 這將造成云存儲資源的極大浪費. 為了解決這一問題, 云服務提供商通常會采用數(shù)據(jù)去重技術來刪除云服務器上的冗余數(shù)據(jù), 而只保留對應文件的一份副本.

用戶將個人數(shù)據(jù)外包給云服務器, 就意味著必須無條件地信任云服務提供商, 那么用戶便會擔心個人數(shù)據(jù)的機密性是否會受到損害. 將數(shù)據(jù)先加密再上傳至云服務器便成為解決這一問題的有效方法. 傳統(tǒng)的加密方案會因為用戶密鑰的不同而使相同的明文產(chǎn)生不同的密文, 這給數(shù)據(jù)去重帶來了困難.

Douceur 等人提出了收斂加密(convergent encryption, CE)[1]. CE 使用明文的哈希散列值作為密鑰, 相同的明文經(jīng)CE 后會得到相同的密文, 在數(shù)據(jù)的機密性得到保護的同時, 數(shù)據(jù)去重效率也得到了保障. 盡管CE 簡易高效, 但當數(shù)據(jù)熵較低時, 容易受到字典攻擊或者離線窮舉攻擊的威脅, 并且CE 無法達到語義安全的要求[2]. Bellare 等人提出了消息鎖定加密(message-locked encryption, MLE)[3,4]. 在此基礎上進行加解密的密鑰來自于消息本身, 但仍未從根本上實現(xiàn)語義安全的加密.

有些研究者提出可信第三方服務器(trusted third party, TTP) 可以協(xié)助云服務器實現(xiàn)安全的數(shù)據(jù)去重[5–9]. 首先, TTP 的引入會降低數(shù)據(jù)去重的效率, 其次, TTP 在現(xiàn)實場景中極難部署, 因此實用價值不高. 現(xiàn)階段, 尋求一種能夠擺脫TTP 的安全加密數(shù)據(jù)去重方法便成為了熱點問題.

2015 年, Liu 等人首次提出了一種無需TTP 的數(shù)據(jù)去重方案[10], 每一個用戶在上傳文件之前, 首先運行口令認證密鑰交換(password authenticated key exchange, PAKE) 協(xié)議與其他用戶交互以獲取文件加密密鑰, 但這需要建立在用戶實時在線的前提下. Stanek 等人提出數(shù)據(jù)流行度(popularity) 概念[11],將數(shù)據(jù)劃分為非流行數(shù)據(jù)與流行數(shù)據(jù). 非流行數(shù)據(jù)的機密程度較高, 因此采用語義安全的加密算法進行保護. 而流行數(shù)據(jù)的機密程度較低, 采用高效的CE 即可. 劃分數(shù)據(jù)流行度在一定程度上提高了數(shù)據(jù)去重的效率, 但針對非流行數(shù)據(jù)的去重仍然是一個較難解決的問題. 2018 年, Stanek 等人在現(xiàn)有方案的基礎上進行了拓展, 提出了新的門限數(shù)據(jù)去重方案[12], 設計了一套門限密碼系統(tǒng), 提高了非流行數(shù)據(jù)的安全性, 但是需要借助TTP 作索引服務. 張曙光等人提出一種無需TTP 的安全數(shù)據(jù)去重方法[13], 采用PAKE 和雙線性映射生成冗余性辨識算法, 并運用同態(tài)加密算法, 使得初始上傳者能夠?qū)⒚荑€安全地傳遞給后續(xù)上傳者, 然而執(zhí)行PAKE 協(xié)議會產(chǎn)生額外的通信開銷. Liu 等人利用CE 和基于身份的廣播加密技術相結(jié)合設計出一種客戶端數(shù)據(jù)去重方案KeyD[14], 通過數(shù)據(jù)所有者與云服務提供商之間的交互即可實現(xiàn)安全的數(shù)據(jù)去重, 但數(shù)據(jù)所有者的身份隱私存在威脅. Tian 等人提出了一種隨機的客戶端數(shù)據(jù)去重方案[15], 該方案使用隨機的數(shù)據(jù)去重方法來防止外部敵手發(fā)起的合謀攻擊和離線窮舉攻擊, 并根據(jù)兩個文件標簽存儲每個數(shù)據(jù)以抵抗重復偽造攻擊. 此外, 方案借助于動態(tài)密鑰加密密鑰樹, 實現(xiàn)了更有效的所有權管理和數(shù)據(jù)共享. 范永開團隊提出了一種基于可信執(zhí)行環(huán)境(trusted execution environment, TEE) 的安全數(shù)據(jù)去重方案[16]. TEE 被認為是一種基于硬件安全的用戶安全執(zhí)行環(huán)境. 在TEE 中運行的程序受到保護, 而多媒體執(zhí)行環(huán)境(rich execution environment, REE) 中的應用程序不能訪問TEE 中的程序. 由于TEE的特殊性, 標簽生成、密鑰管理等敏感操作都限制在TEE 中執(zhí)行, 從而擺脫了對TTP 的依賴.

2013 年,Intel 推出一種新的硬件安全技術英特爾軟件防護擴展(Intel software guard extension,Intel SGX)[17]. Intel SGX 是Intel 架構新的擴展, 這些擴展允許應用程序?qū)崿F(xiàn)一個被稱為飛地(Enclave) 的安全容器, 在應用程序的地址空間中劃分出一塊被保護的區(qū)域, 為容器內(nèi)的代碼和數(shù)據(jù)提供機密性和完整性的保護, 免受擁有特殊權限的惡意軟件的破壞[18]. Dang 等人在Intel SGX 架構上提出了一種安全的服務器端數(shù)據(jù)去重方案[19], 研究了一個三層體系結(jié)構, 不僅減少了服務器端數(shù)據(jù)去重方案帶來的帶寬開銷, 還在保護數(shù)據(jù)機密性的基礎上保護了所有權和平等信息, 但是由于采用了三層體系結(jié)構, 需要額外借助企業(yè)/集團級的服務器作為中間輔助, 造成了額外的通信和存儲開銷. Ren 等人通過引入Intel SGX 設計了一種改進的數(shù)據(jù)去重方案[20], 避免了傳統(tǒng)MLE 方案中加密原語帶來的昂貴計算開銷, 提高了數(shù)據(jù)去重效率, 實現(xiàn)了效率和安全性的共同提升. 但其仍然借助了密鑰服務器作為TTP.

本文基于Intel SGX 提出了一種安全數(shù)據(jù)去重方案, 在客戶端使用Enclave 安全容器實現(xiàn)了TTP 的功能, 借助Intel SGX 提供的遠程認證和數(shù)據(jù)密封[21]提高了方案的安全性.

本文的主要貢獻表現(xiàn)在以下三個方面:

(1) 提出了一種基于Intel SGX 的安全數(shù)據(jù)去重方案. 利用Intel SGX 提供的Enclave 安全容器作為可信執(zhí)行環(huán)境, 執(zhí)行敏感操作, 克服了傳統(tǒng)方案對TTP 的依賴, 實現(xiàn)無任何TTP 的安全去重.

(2) 首次設計了云服務器與客戶端之間的具體安全通信機制. 借助Intel SGX 提供的遠程認證機制,構建了云服務器到客戶端Enclave 之間端到端的安全通信信道, 提高了數(shù)據(jù)通信的安全性.

(3) 設計了客戶端敏感信息的安全存儲方法. 基于Intel SGX 的數(shù)據(jù)密封機制, 使用與硬件相關信息綁定的安全密鑰, 實現(xiàn)本地設備上的隱私信息的安全存儲, 能夠有效抵抗外部敵手.

2 預備知識

2.1 Intel SGX

Intel SGX 提供了兩個安全功能: 認證和密封[21]. Intel SGX 利用基于硬件的認證機制, 使挑戰(zhàn)者能夠檢查特定軟件是否已通過加密安全地加載Enclave. 通過認證機制, 挑戰(zhàn)者可以與Enclave 建立一個端到端的安全信道, 以傳輸敏感數(shù)據(jù). 數(shù)據(jù)密封機制可以用來保護存儲在Enclave 之外的數(shù)據(jù), Intel SGX利用基于硬件信息生成的加密密鑰來安全地加密和存儲敏感數(shù)據(jù), 確保只有在恢復受信任的環(huán)境時才能恢復數(shù)據(jù).

在Intel SGX 中, 通過認證機制, 挑戰(zhàn)者可以確信正確的軟件已經(jīng)在已啟用Intel SGX 的平臺上的Enclave 內(nèi)安全運行. 認證機制包括在同一平臺上的兩個Enclave 之間創(chuàng)建認證(本地認證), 以及擴展本地認證以向平臺外的第三方提供認證(遠程認證).

在實例化Enclave 時, 硬件提供對其中數(shù)據(jù)機密性和完整性的保護, 這些數(shù)據(jù)是在Enclave 內(nèi)維護的.但是, 當Enclave 進程退出時, Enclave 將被銷毀, 并且Enclave 內(nèi)的全部數(shù)據(jù)將會丟失. 如果要在以后重用數(shù)據(jù), 則Enclave 必須作出特殊處理, 以便安全地將數(shù)據(jù)存儲在Enclave 之外. Intel SGX 提供了數(shù)據(jù)密封機制, 用戶可以請求特殊的密鑰, 這個密鑰能夠結(jié)合Enclave 信息和硬件信息做到獨一無二, 用來保護存儲在Enclave 之外的數(shù)據(jù).

2.2 收斂加密

收斂加密[1]是解決云服務器端加密數(shù)據(jù)去重的有效途徑. 對于外包數(shù)據(jù)M, CE 計算它的哈希散列值K=H(M) 作為密鑰, 并使用K對M進行對稱加密得到密文C= Enc(K,M), 其中Enc 為確定的對稱加密函數(shù). 然后CE 計算T=H(C) 作為M的標簽用作去重檢查的依據(jù). CE 簡易高效, 有效地解決了由于用戶密鑰不同而導致相同明文被加密為不同密文, 從而引起去重效率降低的難題. 但是, 當數(shù)據(jù)熵較低時, CE 很容易遭受離線窮舉攻擊. 即攻擊者通過窮舉M′的內(nèi)容, 并通過計算其哈希散列值作為密鑰加密M′, 進一步加密計算得到密文C′及標簽T′, 通過比較C′=C,T′=T, 如果等式成立, 那么原數(shù)據(jù)M的內(nèi)容便遭到了泄露. 盡管CE 存在一定的問題, 它仍然是加密數(shù)據(jù)安全去重方向的一個經(jīng)典思路, 近年來的絕大多數(shù)優(yōu)秀方案都是基于CE 改進而來的.

2.3 所有權證明

所有權證明(PoW) 的目的是讓云服務器能夠驗證一個客戶端用戶是否真正擁有某份文件, 這樣就避免了惡意客戶端在知曉部分文件內(nèi)容的情況下成功地欺騙云服務器的威脅. Halevi 等人最早提出了PoW的概念并實現(xiàn)了一種基于默克爾哈希樹(merkle hash tree, MHT) 的PoW 方案[22]. 云服務器為每份文件創(chuàng)建一棵獨立的MHT, 并只保留其根結(jié)點的數(shù)據(jù). 通過PoW 發(fā)起挑戰(zhàn), 客戶端根據(jù)挑戰(zhàn)內(nèi)容計算并返回有效的兄弟結(jié)點路徑. 云服務器使用客戶端返回的信息重新構建MHT′, 當root(MHT′)=root(MHT)時, PoW 驗證成功.

3 系統(tǒng)與攻擊者模型

3.1 系統(tǒng)模型

在本文的方案中, 系統(tǒng)模型包含兩類主體, 如圖1 所示.

圖1 系統(tǒng)模型Figure 1 System model

(1) 客戶端用戶U: 客戶端用戶U通過購買或者租賃的方式獲得云服務器的存儲空間, 然后合法地將數(shù)據(jù)存儲至云服務器, 并在需要的時候能夠請求下載自己的數(shù)據(jù).

(2) 云服務器S: 云服務器S即云存儲服務的提供者, 不僅為用戶提供巨大的云存儲空間, 還擁有強大的計算能力. 由于用戶規(guī)模龐大,S通常使用數(shù)據(jù)去重來提高云存儲資源的利用率.

3.2 攻擊者模型

在本文的方案中, 考慮兩種可能的攻擊者: 內(nèi)部攻擊者和外部攻擊者.

(1) 內(nèi)部攻擊者: 由于云服務器S是誠實但是好奇的, 因此它能夠在用戶不知曉的情況下, 訪問用戶上傳的隱私數(shù)據(jù). 云服務器這種攻擊行為體現(xiàn)的意志可能來自云存儲服務提供商或其員工. 他們擁有云服務器強大的計算能力并且掌握著用戶數(shù)據(jù)的密文以及相當多的相關信息, 因此可能通過離線窮舉攻擊等方式嘗試破解密文.

(2) 外部攻擊者: 外部攻擊者通常被認為是一個試圖非法獲取其他用戶隱私數(shù)據(jù)的惡意用戶, 一方面,該類攻擊者可能通過遠程攻擊客戶端本地設備來獲取隱私數(shù)據(jù)的相關信息; 另一方面, 他可以截獲其他用戶與云服務器之間的通信. 除此之外, 他還可能試圖通過偽造身份驗證信息來欺騙云服務器.

4 方案設計

4.1 方案概述

本文設計實現(xiàn)了一種基于Intel SGX 的安全數(shù)據(jù)去重方案, 其中去重檢查所使用的依據(jù)信息, 加密文件所使用的收斂密鑰以及所有權證明所使用的驗證信息都是基于合法客戶端用戶掌握的隱私集合生成的.Intel SGX 的Enclave 安全容器作為可信執(zhí)行環(huán)境執(zhí)行敏感操作, 克服了傳統(tǒng)方案對TTP 的依賴. 遠程認證機制能夠構建云服務器到客戶端Enclave 之間端到端的安全通信信道, 以便云服務器安全地向客戶端Enclave 傳輸敏感信息. 數(shù)據(jù)密封機制能夠通過結(jié)合硬件信息生成的密封密鑰, 將隱私集合安全地存儲在用戶本地設備上, 有效抵御外部敵手的攻擊.

4.2 方案實現(xiàn)

4.2.1 初始設置

假設每一個合法客戶端用戶U都被分配了一個公共隱私集合Aα={a1,a2,··· ,am},|Aα| =m, 并且Aα被U使用Intel SGX 的數(shù)據(jù)密封機制安全地存儲在客戶端中. 在云服務器S上需要初始化一個記錄表R用來支持數(shù)據(jù)去重. 除此之外, 需要完成客戶端創(chuàng)建的EnclaveE與S之間的遠程認證, 以構建安全的通信信道, 進而保護后續(xù)操作中S向客戶端E中傳遞信息的機密性.

4.2.2 數(shù)據(jù)上傳

當U想要向S上傳一份文件F*時,U首先計算F*的哈希值標簽hF=H(F*), 然后將hF發(fā)送到E中, 在E中基于隱私集合Aα生成一個隱私密鑰kα=G(a1||a2||···||am,tdm),ai ∈Aα. 其中, tdm作為單向陷門函數(shù)G的陷門. 接著計算出一個身份驗證信息ξF= HMACkα(hF), 然后將ξF發(fā)送給S.上述操作流程如圖2 所示.

圖2 身份驗證信息生成過程Figure 2 Authentication information generation process

當S接收到ξF后, 它首先檢查ξF是否已經(jīng)存儲在R中, 因此ξF便成為了數(shù)據(jù)去重檢查的依據(jù).如果在R中沒有存儲ξF, 即ξF對應的文件沒有存儲在S上,U便被視為對應文件的初始上傳者. 否則,U便被視作相應文件的一位后續(xù)上傳者.

(1) 初始上傳者情況

S生成一個驗證參數(shù)s并將其存儲到R中, 之后通過安全信道將s發(fā)送回E中. 當E接收到驗證參數(shù)s后, 它首先計算出一個收斂密鑰kc=E(hF,HMACkα(s)), 然后U在密鑰kc下使用確定性的加密方案加密文件F*得到密文CF.

與此同時, 在客戶端E中使用隱私集合Aα以及hF生成一個所有權證明初始值Am=⊕mi=1Ai, 其中Ai= HMAChF(ai). 隨后,E在本地刪除收斂密鑰kc, 然后將密文CF以及Am發(fā)送給S,S將Am以及代表密文CF存儲路徑的loc(CF) 一并存儲到R中. 至此, 初始上傳者的文件上傳操作已經(jīng)完成. 上述操作流程如圖3 所示.

圖3 文件上傳過程Figure 3 File upload process

(2) 后續(xù)上傳者情況

如果U被視為相應文件的一位后續(xù)上傳者, 那么S需要通過執(zhí)行PoW 驗證U對文件的所有權, 關于PoW 階段的操作流程如圖4 所示.

圖4 所有權證明過程Figure 4 PoW process

4.2.3 數(shù)據(jù)恢復

當合法客戶端U想要下載曾上傳到S上的文件時,U向S發(fā)送一個文件下載請求.S接收到下載請求后, 驗證U是否擁有訪問該文件的權限. 有關權限驗證的方法超出了我們方案的研究范圍, 因此在這里沒有具體討論. 文件下載恢復過程如圖5 所示. 如果U擁有文件的訪問權限,S將密文CF以及驗證參數(shù)s發(fā)送給U.U使用文件的哈希值標簽hF在客戶端E內(nèi)計算生成文件的收斂密鑰kc=E(hF,HMACkα(s)), 并利用kc解密CF獲取原始文件內(nèi)容. 否則,S便會拒絕U的下載請求并返回錯誤信號.

圖5 文件下載過程Figure 5 File download process

5 安全性分析

本文從身份驗證信息的安全性、密鑰的安全性、抵抗窮舉攻擊以及PoW 的安全性四個方面來分析驗證方案的安全性.

5.1 身份驗證信息的安全性

在本文方案中我們使用身份驗證信息ξF作為數(shù)據(jù)去重的檢查依據(jù),ξF通過隱私集合Aα以及文件哈希值標簽hF計算生成, 其作用是防止沒有權限的惡意用戶訪問文件.ξF的安全性可以從以下兩個方面來證明.

5.1.1 文件哈希值標簽的唯一性

對于一個安全的哈希函數(shù)H, 它應該具有三個基本特性:

(1) 單向性: 對于任一給定的消息M, 哈希函數(shù)H可以很容易地計算出對應的散列值HM. 然而給定散列值HM′, 找到消息M′使得H(M′)=HM′在計算上是不可行的.

(2) 抗弱碰撞性: 對于任一給定的消息M1, 試圖尋找一個消息M2使得H(M1)=H(M2) 在計算上是不可行的.

(3) 抗強碰撞性: 試圖尋找一對不同的消息M1和M2, 使得H(M1)=H(M2) 在計算上是不可行的.基于上述的三個性質(zhì), 可以認定文件F的哈希值標簽hF是唯一的.

5.1.2 隱私密鑰的安全性

本文方案中, 隱私密鑰kα=G(a1||a2||···||am,tdm),ai ∈Aα, 其中G是一個單向陷門函數(shù),G具有兩個性質(zhì):

(1) 對于任一給定的函數(shù)G定義域內(nèi)的x, 可以很容易地計算出y=G(x).

(2) 對于任一函數(shù)G值域內(nèi)的y, 除非掌握陷門z, 否則試圖計算出x使得G(x)=y是不可行的.

G是一個單向陷門函數(shù), 類似于密碼學中的非對稱加密, 已知x可以很容易地計算出y=G(x), 但除非掌握陷門值z, 否則在已知y的情況下想要求解x=G-1(y) 在計算上是不可行的, 這里的陷門值z可以看做非對稱加密中的私鑰. 如4.2.2 節(jié)所述, 身份驗證信息ξF= HMACkα(hF),ξF的生成需要兩個關鍵參數(shù), 一個是隱私密鑰kα, 另一個是文件哈希值標簽hF. 因此, 如果不能夠同時掌握kα和hF, 就不能通過身份驗證信息的檢查, 也就無法繼續(xù)進行后續(xù)的惡意訪問.

5.2 密鑰的安全性

本文方案中包含了兩種密鑰, 隱私密鑰kα和收斂密鑰kc. 在上節(jié)中我們已經(jīng)證明了隱私密鑰kα的安全性, 接下來我們對收斂密鑰kc的安全性給出證明.

在4.2.2 節(jié)中我們描述了kc的生成過程kc=E(hF,HMACkα(s)). 計算生成kc需要三個參數(shù): 哈希值標簽hF、驗證參數(shù)s、隱私密鑰kα. 已經(jīng)證明了hF和kα的安全性, 驗證參數(shù)s是由云服務器生成的, 并通過Intel SGX 創(chuàng)建的安全信道加密傳輸至客戶端Enclave, 外部敵手無法通過任何手段獲取到s.

假設存在一個外部敵手A1,A1能夠通過遠程損害客戶端機器來竊取用戶的隱私信息, 那么如果將密鑰存儲在本地環(huán)境中, 顯然A1可以輕易地得到. 為了防止這種情況的發(fā)生, 本文借助于Intel SGX的Enclave 安全容器來進行密鑰管理, 因而A1無法獲取到Enclave 中的密鑰. 同時,A1也無法知曉在Enclave 中使用的加密算法. 因此, 即使敵手A1窺探到存儲進Enclave 容器中的數(shù)據(jù), 也無法從中獲取任何有效信息.

5.3 抵抗窮舉攻擊

假設存在一個外部攻擊者A2,A2能夠?qū)Υ鎯υ谠品掌髦械拿芪男畔l(fā)動蠻力窮舉攻擊.A2發(fā)動蠻力窮舉攻擊的過程包括三個部分:

(1) 窮舉文件F的內(nèi)容獲取文件哈希值標簽hF, 使用CarF表示文件域基數(shù), 其大小與文件內(nèi)容大小成正比, 與文件的數(shù)據(jù)熵成正比, 計算分析可知A2窮舉文件內(nèi)容的過程的時間復雜度為O(2CarF), 即窮舉成功概率為1/2CarF;

(2) 窮舉隱私集合Aα內(nèi)容獲取隱私密鑰kα, 其中|Aα| =m, 那么A2成功窮舉得到隱私集合的概率為1/2m;

(3) 計算ξF=HMACkα(hF) 獲取身份驗證信息進行驗證.

本文提出的安全數(shù)據(jù)去重方案能夠有效地抵抗蠻力攻擊, 即敵手已知存儲在云服務器上的密文, 通過蠻力窮舉的方式猜測出原始數(shù)據(jù)信息, 成功的概率是可忽略的. 即

根據(jù)上述分析,A2能夠通過窮舉攻擊成功的概率為(1/2CarF)×(1/2m). 因此可以認定, 當需要存儲的文件體積較大, 并且文件的數(shù)據(jù)熵較高時, 在計算上是不可行的. 并且, 可以通過調(diào)整m的值來滿足上述要求. 因此, 本文方案可以有效地抵抗蠻力窮舉攻擊.

5.4 PoW 的安全性

在本文方案中, 當U被認為是一個后續(xù)上傳者, 那么S便會通過PoW 驗證U對文件的所有權. 所有權證明過程分為三個部分: 發(fā)起挑戰(zhàn)、生成證明、驗證結(jié)果.

上述等式證明了PoW 過程中S對U生成的證明的驗證結(jié)果. PoW 需要使用兩部分信息, 一個是S隨機選擇的隱私集合的m/2 元子集Y, 另一個是文件哈希值標簽hF.hF的唯一性已經(jīng)證明, 下面就集合Y的安全性開始討論. 在每次S發(fā)起挑戰(zhàn)時,S會隨機的從Z={1,2,··· ,m}中產(chǎn)生出一個m/2 元子集, 意味著每次執(zhí)行PoW 過程的挑戰(zhàn)與證明內(nèi)容都是不相同的. 假設存在一個外部敵手A3, 他能夠竊聽用戶與云服務器之間的通信內(nèi)容, 從而獲取相關信息試圖攻擊加密數(shù)據(jù). 在發(fā)起挑戰(zhàn)階段,S生成的挑戰(zhàn)是通過Intel SGX 創(chuàng)建的安全信道傳輸至客戶端的,A3無法獲取挑戰(zhàn)信息的內(nèi)容.U通過挑戰(zhàn)信息生成證明, 并將其返回給S. 在這一階段, 即使A3通過竊聽手段獲取到證明內(nèi)容, 也無法通過[Ym,Xm] 獲取到有關文件內(nèi)容的相關信息, 因而惡意敵手A3無法威脅PoW 的安全性.

6 性能評估

本方案采用C++ 語言, 利用OpenSSL[23]函數(shù)庫進行算法實現(xiàn). 實驗環(huán)境使用具有2.10 GHz 的6 核Intel(R) Core(TM) i5-8500T 處理器的DELL 臺式機模擬客戶端, 運行的操作系統(tǒng)是Windows 10,并使用具有2.10 GHz 的4 核Intel Core Processor 處理器模擬云服務器, 運行的操作系統(tǒng)是Windows Server 2012 R2.

在實驗中, 本文采用SHA-1 作為Hash 函數(shù), 利用HMAC-SHA-1 算法計算身份驗證信息, 基于AES-256 對稱加密算法對文件進行加解密.

實驗分為3 個部分:

(1) 性能分析. 從通信開銷和存儲開銷兩個方面分析本方案的性能, 并與其他優(yōu)秀方案進行比較.

(2) 計算開銷. 測試本方案在文件上傳過程中各階段所需的計算開銷. 然后, 測試本方案進行所有權證明所需的計算開銷. 最后, 測試本方案的總體計算開銷, 并與其他優(yōu)秀方案進行對比.

(3) 方案特點. 分析本方案的特點, 并與其他優(yōu)秀方案進行比較.

6.1 性能分析

本文從理論上對方案進行性能分析, 包括通信開銷與存儲開銷兩大方面, 并與當前優(yōu)秀方案進行對比.對于一份需要外包的數(shù)據(jù)M, 采用SC表示密文規(guī)模,ST表示標簽規(guī)模,Ss表示驗證參數(shù)規(guī)模,SξF表示身份驗證信息規(guī)模,SAm表示所有權證明初始值規(guī)模,Sh表示哈希規(guī)模,Ssk表示私鑰規(guī)模,Sk表示加密密鑰規(guī)模,St表示默克爾樹規(guī)模,SAα表示隱私集合規(guī)模,Std表示陷門規(guī)模,Sbm表示雙線性配對元素規(guī)模,SID表示用戶表示規(guī)模,Sblind表示盲簽名規(guī)模.

分析文件上傳過程所消耗的通信開銷并與Key-sharing[7]、stanek[12]與Dang[19]進行比較, 結(jié)果如表1 所示. 由于本方案無需TTP 的支持, 節(jié)省了大量的通信開銷.

表1 通信開銷比較Table 1 Communication overhead comparison

存儲開銷分析包含對云服務器端, 客戶端以及TTP 端的存儲開銷的分析, 由于本方案無需使用TTP,因此不需要額外的存儲開銷. 結(jié)果如表2 所示.

表2 存儲開銷比較Table 2 Storage overhead comparison

6.2 計算開銷

本文對方案的計算開銷進行了測試. 為了測試不同大小的文件在文件上傳過程中的計算開銷, 我們選取了5 組文件, 大小分別為16 MB、32 MB、64 MB、128 MB、256 MB, 分別測試每組文件在文件上傳過程各階段的計算開銷. 實驗數(shù)據(jù)均取10 次測試結(jié)果平均值進行記錄. 結(jié)果如圖6 所示.

圖6 不同大小文件的計算開銷Figure 6 Computation overhead for different file size

可以看出, 文件哈希標簽生成階段、文件對稱加密階段以及文件上傳階段的平均計算開銷都隨著文件大小的增大而呈線性增長. 身份驗證信息生成階段的平均計算開銷比較短暫, 幾乎可以忽略不計. 除此之外, 在整個過程中, 文件對稱加密階段和文件上傳階段的平均計算開銷占比最高.

另外, 我們以上傳32 MB 大小文件為例, 測試了所有權證明所需要的計算開銷, 結(jié)果如圖7 所示.

圖7 所有權證明計算開銷Figure 7 Computation overhead for PoW

所有權證明過程分為三個階段: 初始化階段、證明階段以及驗證階段. 可以看出, 在所有權證明過程中, 計算開銷占比最大的是生成證明階段. 生成證明階段是在客戶端進行的, 而計算開銷較小的初始化階段以及驗證階段則是在云服務器端執(zhí)行.

為了評估性能, 將本方案與ClouDedup[5]、Key-sharing[7]與Dang[19]進行了對比. 其中ClouDedup[5]與Key-sharing[7]分別是需要借助TTP 來實現(xiàn)安全去重的先進方案; 而Dang[19]是擺脫了TTP 使用Intel SGX 的Enclave 作為安全執(zhí)行環(huán)境的安全去重方案. 我們測試了各方案的總體計算開銷并與本方案進行比較, 結(jié)果如圖8 所示. 實驗表明本方案的總體計算開銷相較于其他方案有著較好的表現(xiàn).

圖8 計算開銷比較Figure 8 Computation overhead comparison

6.3 方案特點

將本方案與一些代表性方案進行了比較, 結(jié)果如表3 所示.

表3 方案特點比較Table 3 Characteristic comparison

本文通過對能否擺脫TTP、是否改進收斂加密、是否考慮安全通信以及是否實現(xiàn)所有權證明四個方面對比了本方案與其他幾個方案的特點. 在ClouDedup[5]方案中, 需要借助TTP 來實現(xiàn)對用戶的身份驗證, 對數(shù)據(jù)塊簽名執(zhí)行訪問控制以及數(shù)據(jù)加解密. 在Key-sharing[7]方案中, 同樣需要借助TTP 來實現(xiàn)數(shù)據(jù)去重檢查、所有權證明以及密鑰管理等. TTP 的使用對方案的整體實用性產(chǎn)生了一定的限制.TEE[16]方案借助TEE 安全執(zhí)行環(huán)境實現(xiàn)了TTP 的功能, 雖然成功擺脫了TTP 的限制, 但本方案與之相比較, 還考慮了服務器與客戶端之間的安全通信問題, 進一步提高了安全性. SGXDedup[20]引入Intel SGX 卸載了傳統(tǒng)MLE 加密方案昂貴的計算開銷, 基于Intel SGX 的特性維護其安全性, 提高了數(shù)據(jù)去重效率, 但并未擺脫TTP. 通過上述比較可以看出, 本方案具有綜合優(yōu)勢.

7 結(jié)論

本文提出一種基于Intel SGX 的安全數(shù)據(jù)去重方案, 利用Enclave 安全容器作為安全執(zhí)行環(huán)境實現(xiàn)了TTP 的功能, 擺脫了TTP 的限制. 首次設計了云服務器與客戶端之間的具體安全通信機制, 利用Intel SGX 提供的遠程認證機制構建云服務器與客戶端Enclave 之間端到端的安全信道, 使得云服務器能夠安全地向客戶端傳遞敏感數(shù)據(jù)信息. 借助Intel SGX 提供的數(shù)據(jù)密封機制, 使用與硬件信息相結(jié)合生成的安全密鑰, 實現(xiàn)了本地設備上的隱私信息的安全存儲. 安全性分析與性能評估證實了本方案擁有較高的安全性以及實用價值.