面向云存儲的數(shù)據(jù)加密系統(tǒng)與技術研究

韓培義，劉川意，王佳慧，段少明，潘鶴中，方濱興

（1.北京郵電大學網(wǎng)絡空間安全學院，北京 100876；2.哈爾濱工業(yè)大學（深圳）計算機科學與技術學院，廣東 深圳 518055；3.鵬城實驗室網(wǎng)絡空間安全研究中心，廣東 深圳 518040；4.國家信息中心信息與網(wǎng)絡安全部，北京 100045）

1 引言

當前，隨著云計算的飛速發(fā)展，越來越多的個人或企業(yè)選擇使用云存儲應用。與此同時，云存儲數(shù)據(jù)安全事件頻頻發(fā)生。2019 年，云存儲服務商MEGA 泄露87 GB 數(shù)據(jù)，其中含7.7 億個郵箱。亞馬遜云存儲服務曾泄露大量商業(yè)數(shù)據(jù)、軍事敏感信息以及多達150 萬名公民的醫(yī)療數(shù)據(jù)[1]。針對云存儲數(shù)據(jù)安全問題，一個最直接有效的方法是將用戶隱私數(shù)據(jù)加密后上傳至云端。這樣，云服務商只能看到密文，數(shù)據(jù)控制權完全掌握在用戶手中。然而，在實際應用中針對基于瀏覽器的云存儲應用進行加密面臨著如下挑戰(zhàn)。

1) 自動化適配云服務應用

網(wǎng)絡安全公司 Skyhigh Networks 和 Cipher Cloud[2]提出了云訪問安全代理（CASB,cloud access security broker）[3]技術，該技術通過逆向分析云服務應用協(xié)議來適配各類云服務，進而對上云數(shù)據(jù)進行加密。面對眾多軟件即服務（SaaS,software as a service），目前的技術需要人工逐個分析云服務協(xié)議進行適配，不僅工作量巨大而且容易出錯。這種方式耗時耗力，并且一旦協(xié)議發(fā)生變動，數(shù)據(jù)加密功能就會失效。因此，如何實現(xiàn)自動化地識別和適配云服務是一大技術挑戰(zhàn)。

2) 數(shù)據(jù)加密的同時確保云服務功能

實現(xiàn)數(shù)據(jù)加密和確保云服務原有功能是一對矛盾體。如果只是將加密數(shù)據(jù)上傳到云中，云平臺將淪為一個僅支持數(shù)據(jù)上傳和下載的數(shù)據(jù)池，無法發(fā)揮云服務對數(shù)據(jù)計算、管理和挖掘的優(yōu)勢。傳統(tǒng)的端到端加密客戶端如PGP（pretty good privacy）需要用戶在上傳文件之前使用它來加密文件。盡管該方法簡單有效，但用戶需要不斷切換應用和加密客戶端，難以管理密鑰。安全中間層技術[4]通過提供UI（user interface）中間層用原始文件上傳功能替換可加密的文件上傳功能，使云應用成為“啞巴存儲”，導致原有大規(guī)模存儲和文檔搜索功能失效。

針對上述挑戰(zhàn)，本文提出了面向瀏覽器云存儲應用的自動化數(shù)據(jù)加密系統(tǒng)——CloudCrypt。面對類型繁多的云服務應用，CloudCrypt 需要盡可能地減少工作量，同時支持適配成千上萬的云應用。因此，CloudCrypt 采用JavaScript 動態(tài)程序分析技術來監(jiān)聽各類云應用客戶端程序的文件上傳行為，識別其文件操作請求并加密文件內(nèi)容。該技術可將敏感數(shù)據(jù)安全隔離，并從根本上解決云應用適配難的問題。針對數(shù)據(jù)加密影響云服務原有功能問題，CloudCrypt 集成了基于安全網(wǎng)關執(zhí)行的密文搜索功能（PESE,proxy executed searchable encryption）。PESE 不需要云提供商配合以及對云服務進行改造，在實現(xiàn)數(shù)據(jù)加密保護的同時最大限度地保持云應用原有的搜索功能。

本文主要創(chuàng)新點總結(jié)如下。

1) 提出了面向瀏覽器云存儲應用的自動化數(shù)據(jù)加密系統(tǒng)——CloudCrypt。該系統(tǒng)可自動化適配各類云存儲應用，具有良好的擴展性。

2) CloudCrypt 系統(tǒng)集成的基于安全網(wǎng)關執(zhí)行的密文搜索功能不需要對云應用進行修改，在保證敏感數(shù)據(jù)安全的同時最大限度地保持云應用原有的搜索功能。

3) 實現(xiàn)了CloudCrypt 系統(tǒng)并將其應用于郵件、存儲、辦公等10 個典型云應用，并通過實驗對其性能、可擴展性等進行了詳細的測試評估。實驗表明，CloudCrypt 系統(tǒng)既可透明地加密數(shù)據(jù)，又可支持云應用原有的搜索功能，且引入性能代價較小。

2 相關工作

本節(jié)主要介紹針對面向云存儲服務的數(shù)據(jù)加密系統(tǒng)相關工作。目前，在工業(yè)界與學術界均推出了一系列面向云存儲服務的敏感數(shù)據(jù)加密系統(tǒng)。本節(jié)將討論各個數(shù)據(jù)加密系統(tǒng)的優(yōu)勢與劣勢，詳情如表1所示。

1) 文件加密工具

文件加密工具是使用傳統(tǒng)密碼算法如AES-256對文件進行加解密。用戶需要在文件上云前使用文件加密工具如PGP 對自己的文件進行加密，確保敏感數(shù)據(jù)以加密形式存儲在不可信的云存儲服務商中。然而，這種方法導致云服務無法處理加密文件，喪失其重要功能如搜索、文檔編輯、文檔預覽等。同時，用戶在使用云端的文件時需要將整個文件下載并解密，還需要維護每個文件對應的密鑰，由于管理密鑰繁雜，因此大大影響了用戶的使用習慣。

表1 各個數(shù)據(jù)加密系統(tǒng)對比

2) 安全中間層

安全中間層[5]是一種可以給用戶提供安全中間層來查看和交互敏感數(shù)據(jù)的技術。具體來說，該方法使用UI 中間層如iFrame、Shadow DOM 等來覆蓋應用程序的原始UI 界面，進而在中間層上實現(xiàn)保護數(shù)據(jù)的功能來覆蓋和替換原始功能。

MessageGuard[6-7]和 Virtru[8]利用瀏覽器中的iFrames 組件，實現(xiàn)了一個可替代原有應用文件上傳功能的UI 中間層，來保護敏感文件數(shù)據(jù)。盡管可對文件數(shù)據(jù)進行加密，卻需要一個額外的文件存儲服務器來存儲加密數(shù)據(jù)，也喪失了原有的文件搜索功能。ShadowCrypt[9]作為一個瀏覽器插件，基于瀏覽器的Shadow DOM 機制構建了安全隔離的文本輸入/輸出環(huán)境。ShadowHPE[10]在ShadowCrypt的基礎上利用Shadow DOM 與DOM 樹技術，提出了可支持格式保全加密且支持文本加密功能更穩(wěn)定的方法。然而，ShadowCrypt 與ShadowHPE 均只支持文本數(shù)據(jù)的加密，無法支持文件數(shù)據(jù)。M-Aegis[11]通過創(chuàng)建一個名為Layer 7.5 (L-7.5)的透明UI 中間層來截獲并加解密用戶輸入文本數(shù)據(jù)，在不改變用戶使用習慣的同時確保用戶敏感信息的安全性。M-Aegis 同樣只支持文本數(shù)據(jù)。

3) 云訪問安全代理

云訪問安全代理（CASB）[3]受到工業(yè)界的廣泛追捧，連續(xù)多年被Gartner 評為網(wǎng)絡安全十大創(chuàng)新性技術之首[12]。該技術被以Skyhigh Networks、CipherCloud 為代表的“獨角獸”創(chuàng)新企業(yè)所采用，并推出了基于CASB 架構的數(shù)據(jù)加密產(chǎn)品。CASB位于云服務用戶與云服務提供商之間，可對上云數(shù)據(jù)進行加密保護。然而，該技術需要開發(fā)者對云服務應用協(xié)議進行逆向分析和適配，耗時耗力。同時，協(xié)議一旦發(fā)生更新，CASB 將無法識別和解析最新協(xié)議，導致數(shù)據(jù)加密功能失效。在實際中，該技術需要大量的人工維護工作，且數(shù)據(jù)加密功能不穩(wěn)定。

4) 其他數(shù)據(jù)加密系統(tǒng)

近年來，工業(yè)界也涌現(xiàn)出一些針對云應用數(shù)據(jù)加密系統(tǒng)的研究工作。CryptDB[13]是一個部署在服務器端和數(shù)據(jù)庫服務器之間的代理服務器，將數(shù)據(jù)加密后存儲到數(shù)據(jù)庫，并對加密數(shù)據(jù)執(zhí)行查詢操作，可有效防范內(nèi)部惡意數(shù)據(jù)庫管理員。ARX[14]提出了針對MongoDB 的數(shù)據(jù)庫加密系統(tǒng)，可支持豐富的復雜密文計算功能。然而，CryptDB 與ARX均無法阻止惡意云服務器竊取用戶敏感數(shù)據(jù)行為。Mylar[15]提供了一種基于Meteor JavaScript 的Web框架，由云服務開發(fā)者調(diào)用該框架編程接口來實現(xiàn)用戶數(shù)據(jù)的加密。Mylar 假設云服務商是可信的，因此難以防范云服務商。DataBlinder[16]針對軟件服務開發(fā)商提供分布式數(shù)據(jù)訪問中間件的方式，確保其開發(fā)的軟件服務上云數(shù)據(jù)的安全性。另外，該方法需要對云服務應用進行改造。即使云服務商提供了數(shù)據(jù)保護，對于用戶來說依然是不可信的。

另外，在密文搜索研究方面，Song 等[17]提出了第一個密文搜索方案，該方案通過對密文進行順序掃描，進而對搜索關鍵字與密文進行比較，返回包含關鍵字的密文文件，但搜索準確率較低且計算開銷較大。Goh[18]提出了基于Bloom Filter 的安全索引機制的密文搜索方法，但搜索準確率較差。Curtmola 等[19]提出了基于反向索引的密文搜索方案，提升了搜索效率和準確率，然而，該方案只支持精準關鍵字搜索。Xia 等[20]提出了基于樹的多關鍵字排序密文搜索方案，可達到亞線性搜索時間，但存在一定的敏感信息泄露。Li 等[21]采用了提前預設基于通配符的關鍵字模糊集合的密文搜索方案，在建立索引和搜索過程中時間消耗較大。

3 CloudCrypt 系統(tǒng)

3.1 設計目標

面對越來越多的云服務，本文期望得到一個通用的可自動化適配支持各類云應用的數(shù)據(jù)加密系統(tǒng)，其需要滿足的設計目標如下。

1) 提供一個安全隔離數(shù)據(jù)加密環(huán)境，以抵御惡意或被攻陷的云提供商。

2) 支持透明加密并保留豐富的功能如搜索。同時，盡可能地不改變用戶習慣。

3) 盡可能以最小代價擴展適配不同的云應用。

3.2 威脅模型

在本文威脅模型中，從以下3 個方面進行威脅分析。

1) 云服務商

云服務商被認為是誠實且好奇的，存在偷窺或竊取用戶隱私的動機，如通過分析用戶數(shù)據(jù)實現(xiàn)商業(yè)目的，被黑客攻陷控制來竊取用戶隱私數(shù)據(jù)。

2) 網(wǎng)絡中間件

部署在企業(yè)內(nèi)網(wǎng)與云服務器之間的網(wǎng)絡中間件在接收用戶上傳敏感數(shù)據(jù)時，可以被攻擊成為惡意中間人，進而在通信鏈路上攔截和解析獲取敏感數(shù)據(jù)。

3) CloudCrypt

在本文威脅模型中，CloudCrypt 部署在企業(yè)內(nèi)部網(wǎng)絡，CloudCrypt 的加密密鑰存儲在可信模塊（TPM,trusted platform module）[22]中。TPM 被認為是可信的，因此，惡意內(nèi)部攻擊者將無法獲取存儲在CloudCrypt TPM 中對應的密鑰，難以解密密文。另外，CloudCrypt 不針對側(cè)信道攻擊提供防御和保護能力。

3.3 CloudCrypt 系統(tǒng)架構

CloudCrypt 部署在企業(yè)與云服務提供商之間來保護上云的敏感數(shù)據(jù)。CloudCrypt 采用基于JavaScript 動態(tài)程序分析技術透明加密用戶敏感文件數(shù)據(jù)。如圖1 所示，CloudCrypt 由如下幾個重要組件構成。

1) 安全網(wǎng)關

CloudCrypt 基于安全網(wǎng)關開發(fā)，安全網(wǎng)關作為中間人可截獲瀏覽器和云服務應用之間的HTTP/HTTPS 網(wǎng)絡流量。對于企業(yè)來說，通過安全網(wǎng)關截獲HTTP/HTTPS 請求是合理的，因為企業(yè)需要保證企業(yè)內(nèi)部員工上傳至云服務的企業(yè)敏感數(shù)據(jù)的安全性。

2) 協(xié)議解析器

協(xié)議解析器主要用于識別HTTP/HTTPS 等協(xié)議，解析請求內(nèi)容格式如HTML、鍵值對、multipart等。它通過解析協(xié)議和內(nèi)容，提取重要文件內(nèi)容，傳至JavaScript 注入模塊或數(shù)據(jù)加解密模塊等。

3) 請求轉(zhuǎn)發(fā)器

請求轉(zhuǎn)發(fā)器是安全網(wǎng)關的一個重要組件，主要作為代理轉(zhuǎn)發(fā)各類請求。

圖1 系統(tǒng)架構

4) JavaScript 注入模塊

JavaScript 注入模塊接收到云應用Web 頁面后，將JavaScript 代碼片段注入網(wǎng)頁的頭部。JavaScript代碼片段用來針對JavaScript 執(zhí)行環(huán)境中的API 函數(shù)設置鉤子函數(shù)，進而實現(xiàn)程序的動態(tài)分析。

5) 數(shù)據(jù)加解密模塊

數(shù)據(jù)加解密模塊用于對敏感文件數(shù)據(jù)進行對稱加密，每個加密數(shù)據(jù)塊均會帶有加密標識和密鑰ID，便于識別密文數(shù)據(jù)和快速獲取密文對應的密鑰。

6) 密鑰管理模塊

密鑰管理模塊基于屬性加密的密鑰管理機制來管理加密文件密鑰，詳見第3.6 節(jié)。

7) JavaScript 包裝器

JavaScript 包裝器由XMLHttpRequest 包裝器和FileReader 包裝器組成，均是針對JavaScript API 如XMLHttpRequest[23]和FileReader[24]設置鉤子函數(shù)的JavaScript 腳本代碼。其中，XMLHttpRequest 包裝器可截獲客戶端JavaScript 程序發(fā)起的網(wǎng)絡請求并對文件上傳請求進行識別。FileReader 包裝器通過捕獲讀取文件I/O 來加密文件。

舉例如下。Alice 通過瀏覽器訪問一云存儲應用頁面，頁面訪問請求經(jīng)過CloudCrypt 時，CloudCrypt會將JavaScript 包裝器代碼注入頁面的頭部。注入代碼后的頁面會在瀏覽器中執(zhí)行，JavaScript 包裝器會首先執(zhí)行，提前安裝鉤子函數(shù)來修改原始JavaScript API。它將捕獲云應用客戶端對JavaScript API 函數(shù)和對象的調(diào)用。算法1 描述了CloudCrypt的工作流。

算法1CloudCrypt 工作流

輸入瀏覽器B，云存儲服務器C，CloudCrypt系統(tǒng)F

1) while 接收瀏覽器發(fā)起HTTP/HTTPS連接c do

2) if c 請求部分包含HTML 頁面 then

3) c.response?inject_js_wrapper(c.response)

4) if c.request 為文件上傳請求 then

5) c.request ?proxy_encryption(request)

6) if c.response 包含密文then

7) c.response ? proxy_decryption(response)

8) 轉(zhuǎn)發(fā)請求(c)

算法1 首先接收一個HTTP/HTTPS來自客戶端的連接（步驟1)）。訪問云服務的初始請求往往包含應用頁面，inject_js_wrapper 函數(shù)主要用于注入JavaScript 包裝器到網(wǎng)頁的頭部，JavaScript 包裝器在瀏覽器中執(zhí)行并重寫JavaScript API（步驟3)）。其中，XMLHttpRequest 包裝器用來截獲網(wǎng)絡流量，而FileReader 包裝器用來捕獲所有的文件讀寫操作。proxy_encryption 函數(shù)是網(wǎng)關加密函數(shù)。CloudCrypt 將會根據(jù)應用請求中的加密標記來決定是否需要加密請求中的文件內(nèi)容，若存在加密標記，則提取出文件內(nèi)容并加密，再將密文重寫至應用請求內(nèi)容中（步驟6)）。proxy_decryption 函數(shù)是網(wǎng)關解密函數(shù)。當應用響應請求中包含有加密文件標識時，安全網(wǎng)關將會從加密文件標識中提取出加密文件的密鑰ID，進而得到對應的密鑰，利用密鑰對密文解密并將解密后的明文內(nèi)容重寫至響應請求內(nèi)容中。最后返回給客戶端（步驟7)）。

3.4 自動化數(shù)據(jù)加密技術實現(xiàn)

CloudCrypt 中最重要的設計目標是自動化適配各類云應用。CloudCrypt 需要自適應地識別各類云服務的文件上傳請求。本節(jié)首先討論2 個可行方案，然后再介紹本文使用的方案：基于JavaScript 動態(tài)程序分析技術實現(xiàn)自動識別文件上傳請求。

方案1簡單地使用正則表達式來匹配各類云服務的文件上傳請求。但該方案需要分析每個云服務應用協(xié)議請求，形成對應的匹配規(guī)則。然而，一旦云服務協(xié)議更新，數(shù)據(jù)保護功能失效，這些匹配規(guī)則均需要及時更新。

方案2根據(jù)文獻[25]提出的程序內(nèi)字符串分析方法對JavaScript 代碼進行解析，進而提取文件上傳請求的URL 字符串、HTTP 方法和對應的請求內(nèi)容數(shù)據(jù)。由于云服務往往會將JavaScript 代碼壓縮和混淆，這種方法提取到字符串的準確率很低，很難應用于實際需求。

本文針對JavaScript 采用動態(tài)程序分析技術來監(jiān)聽它的文件上傳行為，捕獲其文件上傳請求和文件內(nèi)容。CloudCrypt 針對JavaScript 執(zhí)行環(huán)境中的API 函數(shù)設置鉤子函數(shù)來實現(xiàn)程序的動態(tài)分析。當瀏覽器加載云存儲應用的客戶端JavaScript 代碼時，首先會提前加載CloudCrypt 注入的JavaScript包裝器代碼。JavaScript 包裝器代碼通過設置API鉤子函數(shù)來修改瀏覽器中JavaScript 執(zhí)行環(huán)境，之后便可捕獲到JavaScript API 函數(shù)、對象方法等調(diào)用。

XMLHttpRequest 是客戶端JavaScript 程序向云服務應用發(fā)起網(wǎng)絡請求的基礎API。CloudCrypt 基于動態(tài)程序分析技術設置XMLHttpRequest API 鉤子函數(shù)，可攔截到云服務客戶端JavaScript 程序發(fā)起的所有網(wǎng)絡請求。而文件上傳請求與其他網(wǎng)絡請求最大的區(qū)別在于XMLHttpRequest API 函數(shù)調(diào)用對象類型。文件數(shù)據(jù)對象往往由 Blob、File、FormData、ArrayBuffer 表示。因此，CloudCrypt通過設置調(diào)用對象類型白名單，檢查每個網(wǎng)絡請求的調(diào)用對象類型，進而自動識別出云應用的文件操作請求。圖2 代碼片段描述了CloudCrypt 基于動態(tài)程序分析技術設置XMLHttpRequest API 鉤子函數(shù)。

圖2 JavaScript 包裝器代碼片段

3.5 密鑰管理技術實現(xiàn)

為了確保在不同用戶之間可實現(xiàn)透明加密和共享加密文件，CloudCrypt 引入了基于屬性加密的密鑰管理機制。在CloudCrypt 中，每個用戶擁有一個專門用于保護文件密鑰的主密鑰(pku,sku)，其中pku 是公鑰，sku 是私鑰，文件密鑰加密后稱為密鑰鎖。在實際應用中，用戶所擁有的密鑰存儲和管理在CloudCrypt 中進行，為了安全考慮，CloudCrypt 將密鑰存儲在TPM。

每個企業(yè)擁有每個員工的公鑰，本文需要一個機制來管理企業(yè)用戶的密鑰信息。公鑰機制（PKI,public key infrastructure）[26]在傳統(tǒng)密碼應用領域常常用來管理密鑰，而這種方式需要第三方密鑰管理中心。為了避免使用PKI，本文采用了IBE（identitybased encryption）[27]機制使Alice 可以直接用Bob的屬性（如郵件地址）作為公鑰加密數(shù)據(jù)，而不需要引入第三方來管理公鑰。

3.6 密文搜索技術實現(xiàn)

數(shù)據(jù)加密與數(shù)據(jù)可用本身是一對矛盾，數(shù)據(jù)加密后往往會犧牲一些云應用功能，其中典型的功能為搜索功能。密文搜索在一定程度上平衡了功能、性能和安全性3 個方面。大多數(shù)學術研究關注基于加密索引的密文搜索，即用戶將文檔加密，然后生成可搜索的加密索引并上傳至云服務器，再利用搜索關鍵字對應的搜索陷門（trapdoor）來對云服務器上的加密索引進行搜索，最后得到對應的加密文檔[17-21,28-31]。本文將這種方式稱為基于云端執(zhí)行的密文搜索（CESE,cloud executed searchable encryption）算法[32]。然而CESE算法需要服務商的配合并對云服務應用做較大改動，顯然在實際中很難實行。本文提出了一種基于安全網(wǎng)關執(zhí)行的密文搜索（PESE,proxy executed searchable encryption）算法。PESE 算法在安全網(wǎng)關處建立索引并關聯(lián)存儲在云服務器上的加密文檔標識符。

PESE 算法如算法2 所示，具體步驟介紹如下。

算法2PESE 算法

定義文檔D，對稱密鑰K，對稱加密算法E k(D)，文檔D標識符ID(D)，關鍵字w與索引L(w) 之間的映射函數(shù)f(wi)

建立索引

步驟1用戶上傳一個文檔D到云存儲服務器C1。

步驟2CloudCrypt 攔截上傳請求，提取出文檔內(nèi)容，使用一個密鑰K對文檔內(nèi)容進行加密，然后上傳加密文檔D′到云存儲服務器C1，并得到云存儲服務器C1返回的加密文檔標識符ID(D') 。

步驟3CloudCrypt 針對緩存在網(wǎng)關上的文檔D提取出關鍵字({w1,w2,…,wn})并建立搜索索引I={t1,t2,…,tn}。CloudCrypt 將搜索索引I加密后通過云存儲接口存儲至另一個云存儲服務器C2。

步驟4CloudCrypt 將索引I與索引文件標識符ID(I)以及加密文檔標識符ID(D')關聯(lián)起來。

步驟5用戶輸入搜索關鍵字w并發(fā)起查詢請求，CloudCrypt 接收到查詢請求并將搜索關鍵字w替換為密文搜索詞Tkw，并向云存儲服務器C2發(fā)起搜索查詢請求。

步驟6云存儲服務器C2返回對應的索引文件標識符ID，之后CloudCrypt 根據(jù)索引文件標識符與加密文檔標識符的映射關系表得到對應的加密文檔標識符ID′。

步驟7CloudCrypt 使用加密文檔標識符ID′向云存儲服務器C1發(fā)起請求，得到對應的加密文檔D'。

假設有m個文檔，每個文檔Di含有n個關鍵字({w1,w2,…,wn})，一次查詢可搜索關鍵字數(shù)量為k個，每個關鍵字的平均長度為l，每個關鍵字wi對應的索引倒排表長度為，一次索引更新變化的關鍵字個數(shù)為，那么文檔集索引倒排表總長度為。由于PESE 算法采用了在本地構建倒排索引的方式，因此，PESE 算法建立索引的時間復雜度為O(L)，建立索引的空間復雜度為O(m+n)，搜索時間復雜度為O(k)。文獻[29]僅支持單關鍵字搜索功能。文獻[30]支持多關鍵字搜索，但無法支持模糊搜索，且建立索引的時間復雜度為O(mn2)，建立索引的空間復雜度為O(mn)，搜索時間復雜度為O(θnlog(m))，其中θ為搜索結(jié)果中返回的文件數(shù)目。文獻[31]支持模糊搜索功能，其建立索引的時間與空間復雜度以及搜索時間復雜度均為O(mwle)，其中e為編輯距離。如表2 所示，PESE 算法在安全網(wǎng)關處構建索引并執(zhí)行搜索操作，可支持豐富的搜索功能，且在建立索引、搜索等維度上的時間與空間復雜度較低，具備較高的性能。

4 系統(tǒng)實現(xiàn)與評價

本節(jié)重點討論CloudCrypt 系統(tǒng)實現(xiàn)與實驗評估結(jié)果。實驗主要內(nèi)容和目的包括在5 個典型云應用中測試評估CloudCrypt 引入的額外開銷、PESE算法的密文搜索功能創(chuàng)建索引開銷與搜索性能效率以及對云應用功能的影響。

4.1 CloudCrypt 系統(tǒng)實現(xiàn)

本文的CloudCrypt 系統(tǒng)已在多家企業(yè)開始實際試用，后續(xù)考慮將CloudCrypt 開源。CloudCrypt是基于Squid[33]實現(xiàn)的，其中Squid 是一款支持HTTP/HTTPS/FTP 等協(xié)議的開源內(nèi)容緩存網(wǎng)關。而JavaScript 包裝器是基于 XMLHttpRequest 和FileReader 接口實現(xiàn)的。CloudCrypt 采用CTR 模式的AES 標準加密算法[34]來對敏感數(shù)據(jù)進行加密。CTR 模式的AES 加密算法確保明文與密文的長度相同。JavaScript 包裝器中采用了斯坦福實現(xiàn)的JavaScript 加密算法庫（SJCL,Stanford JavaScript Crypto Library）[35]進行加解密。在網(wǎng)關處采用OpenSSL 加密算法庫[36]來進行加解密。加密后的文件名稱為“YAB-098…7F6”，包括加密標志符和密鑰鎖ID?！甕AB’是加密標志符，用來表示該文件被CloudCrypt 已加密。密鑰鎖ID 是文件密鑰加密后的密文編碼。CloudCrypt 采用IBE 算法庫[37]來保護文件加密密鑰，詳見第3.6 節(jié)。對于基于安全網(wǎng)關執(zhí)行的密文搜索方案，本文實驗采用了常用的搜索引擎Elasticsearch 在安全網(wǎng)關處來構建索引并關聯(lián)云存儲上的密文文件。同時，本文也采用了HMAC-SHA-256[38]算法來生成搜索關鍵字。

4.2 實驗設置

本文實驗裝置主要由一個運行瀏覽器的虛擬機和一個運行CloudCrypt 系統(tǒng)的虛擬機組成。運行瀏覽器的虛擬機配置為英特爾i7 2.20 GHz 型號CPU 4 核，內(nèi)存為16 GB。運行CloudCrypt 的虛擬機配置為英特爾i72.20 GHz CPU 雙核，內(nèi)存為4 GB。

表2 PESE 算法與相關工作搜索效率的對比

4.3 性能測試

CloudCrypt 的核心功能為針對敏感數(shù)據(jù)的加解密。因此，本文首先評估加解密操作帶來的性能開銷。加解密操作階段主要發(fā)生在JavaScript 包裝器和安全網(wǎng)關處。JavaScript 包裝器在客戶端代碼讀取數(shù)據(jù)之前進行加密，安全網(wǎng)關在發(fā)送數(shù)據(jù)至云服務器之前對數(shù)據(jù)進行加密。本文實驗通過調(diào)用CloudCrypt 加解密接口來加密明文和解密密文，其文本數(shù)據(jù)大小從1 KB 遞增至100 MB，從而評估出數(shù)據(jù)加解密操作帶來的性能損耗。圖 3 為在JavaScript 包裝器和安全網(wǎng)關分別調(diào)用數(shù)據(jù)加解密操作100 次的平均時長。JavaScript 包裝器對一個100 MB 的文件進行加密總耗時為5 089.3 ms，因為大多數(shù)云服務應用的上傳文件服務均采用最大不超過10 MB 的文件分塊來上傳文件。而針對大小為100 KB的文件的加密帶來的額外開銷僅為 5.5 ms，因此，這個微小時間差對用戶體驗來講影響甚微。安全網(wǎng)關加密一個100 MB 的文件需要花費520.311 ms，解密一個100 MB 的文件需要花費1 631.370 ms。顯而易見，與上傳或下載一個文件所需總時長相比，加解密操作引入的時間開銷較小。

圖3 JS 包裝器與安全網(wǎng)關的加解密性能

在實驗中，本文選擇了5 個主流并被廣泛應用的云服務應用來評估CloudCrypt 帶來的實際性能開銷。其中，QQ 郵箱是目前主流的電子郵件服務，提供在郵件中傳送附件的功能；Box 和Dropbox 為大量的個人用戶和企業(yè)客戶提供了存儲、訪問和共享文件的功能；Google Docs 和Salesforce 是在企業(yè)客戶中最受歡迎的云辦公服務。由于在企業(yè)中使用網(wǎng)關來保護內(nèi)部網(wǎng)絡安全較普遍，因此本文直接對比普通網(wǎng)關與CloudCrypt 這2 個場景下的性能測試結(jié)果。實驗中分別在普通網(wǎng)關與CloudCrypt 這2 個場景下，將大小從1 KB～100 MB 不等的文件上傳至上述云服務應用，再從云服務器下載已被加密的文件重復10 次，最后計算平均耗時。圖4 顯示了系統(tǒng)性能測試結(jié)果，這些耗時通常在毫秒量級。通過比較在普通網(wǎng)關與CloudCrypt 場景下執(zhí)行同樣的加解密操作，觀察到CloudCrypt 應用在真實云服務應用時帶來的性能開銷較小。加解密操作造成的時間開銷不到11%。CloudCrypt 對于1 KB 文件的下載任務引入了10.52%的開銷，對于100 MB 的文件下載任務引入了9.23%的開銷，而其他文件大小的下載任務帶來的開銷要低得多。這種顯著的差異可能由于網(wǎng)絡環(huán)境的實時動態(tài)變化，導致對小文件的影響更大。此外，隨著文件數(shù)據(jù)大小的增加，大量的內(nèi)存操作發(fā)生在代碼中，從而導致性能降低。因此，持續(xù)的代碼優(yōu)化將會大大提高CloudCrypt的性能。

在PESE 算法中，CloudCrypt 在本地網(wǎng)關處對上傳的明文文檔構建明文索引，再將明文索引與存儲在云服務器上的密文文檔標識符進行關聯(lián)。本文實驗對PESE 算法與其他密文搜索相關工作支持的搜索功能進行了詳細分析，如表3 所示。與其他相關工作相比，PESE 密文搜索方案不需要云服務商配合，也不需要對云服務應用進行修改，并可支持豐富的搜索功能如多關鍵字、模糊搜索、結(jié)果排序等。

表3 PESE 算法與相關工作的密文搜索支持功能對比

本文實驗還著重針對基于安全網(wǎng)關執(zhí)行的密文搜索方案進行了詳細的性能測試。實驗采用esrally[39]對5 個文件集合來評測搜索性能的好壞。其中，這5 個文件集合分別為文件集1（8 697 882 個文件，總大小為1.21 GB）、文件集2（10 716 760 個文件、總大小為1.34 GB）、文件集3（11 961 342 個文件、總大小為1.48 GB）、文件集4（13 053 463 個文件、總大小為1.62 GB）和文件集5（17 647 279 個文件、總大小為2.2 GB）。如圖5 所示，當文件集大小和文件數(shù)目增大時，對應的索引大小緩慢增大，搜索性能緩慢下降。當文件集大小超過2 GB 時，其搜索性能可達11.09 ops/s，完全滿足實際使用需求。

圖4 系統(tǒng)性能測試結(jié)果

4.4 案例研究

本節(jié)主要討論CloudCrypt 在加密敏感數(shù)據(jù)時對云服務應用功能的影響程度。QQ 郵箱是騰訊公司開發(fā)的電子郵件應用，該應用提供郵件內(nèi)容輸入?yún)^(qū)域，包括郵件主題輸入?yún)^(qū)、郵件正文輸入?yún)^(qū)和郵件附件上傳區(qū)。QQ 郵箱的文件上傳功能在本文實驗中的云應用程序中是最復雜的，它會嚴格檢查文件大小和上傳文件塊大小，很難通過協(xié)議分析和代碼分析實現(xiàn)提取并加密文件的目的。CloudCrypt 通過JavaScript 動態(tài)程序分析技術注入的JavaScript包裝器可在客戶端代碼加載文件之前就對文件進行加密，從而確保上傳文件計算的MD5 校驗值與加密文件的MD5 校驗值一致。對于復雜應用QQ郵箱的無縫適配，充分表明CloudCrypt 具有可擴展性。然而，由于云服務器無法解析加密文件的格式內(nèi)容，用戶將無法預覽和編輯存儲在云中的PDF 和WORD 等類型文件。CloudCrypt 應用在Gmail 時，由于Gmail 需要解析正常原始文檔才能提供文檔編輯和預覽功能，因此加密郵件附件影響到了Gmail的文檔編輯功能。盡管喪失了文檔預覽和編輯功能，但卻阻止了云服務商偷窺和泄露用戶敏感文檔數(shù)據(jù)的惡意行為。

圖5 基于安全網(wǎng)關執(zhí)行的密文搜索性能

本文實驗還將CloudCrypt 應用于典型的云存儲應用如Dropbox、Box、OneDrive、Google Drive、Mega.nz 上。CloudCrypt 支持對上傳至云存儲應用文件的加解密，它的引入導致文檔預覽和分享功能在一定程度有所喪失。企業(yè)更希望敏感數(shù)據(jù)流出時被加密，且更傾向于將CloudCrypt 應用在云辦公應用如Salesforce、Google Docs 和Slack中，可支持對Salesforce 和Google Docs 的上傳文件進行加密。而Salesforce 的文件導入功能由于無法解析加密文件而導致功能失效。Slack 通過WebSocket 連接來傳輸數(shù)據(jù)，在未來的工作中，本文方法可擴展基于WebSocket 的數(shù)據(jù)加密。

5 結(jié)束語

本文提出了一個通用的可自動化實現(xiàn)對基于瀏覽器云存儲應用數(shù)據(jù)保護的系統(tǒng)CloudCrypt。該系統(tǒng)不需要云提供商配合，在對敏感數(shù)據(jù)加密的同時還可最大限度地保持云服務原有的重要功能，在不影響用戶體驗的前提下確保用戶云上數(shù)據(jù)的機密性。本文實驗表明，CloudCrypt 引入代價較小，可支持大部分云服務應用。