江炳城，何 倩，陳亦婷，劉 鵬

(1.認知無線電與信息處理教育部重點實驗室(桂林電子科技大學)，廣西 桂林 541004；2.廣西密碼學與信息安全重點實驗室(桂林電子科技大學)，廣西 桂林 541004；3.桂林電子科技大學 廣西云計算與大數(shù)據(jù)協(xié)同創(chuàng)新中心，廣西 桂林 541004)(*通信作者電子郵箱heqian@guet.edu.cn)

0 引言

云計算作為社會信息化發(fā)展過程中的一項新興技術，具有動態(tài)擴展、按需服務、按量計費等優(yōu)勢，為企業(yè)和個人提供了一個全新的服務模式。云數(shù)據(jù)庫是在軟件即服務(Software as a Service, SaaS)成為應用趨勢的大背景下發(fā)展起來的云計算技術，是部署和虛擬化在云計算環(huán)境中的數(shù)據(jù)庫[1]。隨著云計算的快速普及，更多的企業(yè)和個人選擇把數(shù)據(jù)外包到云端進行管理，用戶可以選擇租用云服務提供商的硬件設備并在其上搭建自己的數(shù)據(jù)庫系統(tǒng)，也可以選擇直接采用云服務提供商提供的數(shù)據(jù)庫即服務(Database as a Service, DaaS)，免去繁瑣的配置安裝工作，如谷歌的Cloud SQL、阿里云提供的關系型數(shù)據(jù)庫服務(Relational Database Service, RDS)等。以上兩種方式都將數(shù)據(jù)遷移到了云端進行管理，令用戶可以享受到云計算的廉價、便捷、彈性、可靠等優(yōu)點。云數(shù)據(jù)庫作為云計算的應用之一，具備云計算諸多優(yōu)點的同時也凸顯了云計算在數(shù)據(jù)安全保障方面的不足[2]。諸如谷歌員工窺探未成年人的G-mail 通信記錄和瑞士銀行泄露客戶資料等來自內部的數(shù)據(jù)泄露事件表明云服務提供商是不完全可信的[3]。數(shù)據(jù)安全和隱私保護方面的顧慮已經(jīng)成為阻礙用戶更廣泛采用云數(shù)據(jù)庫的一大因素。

云計算服務提供商不完全可信，可能為了某種利益而使用租戶數(shù)據(jù)。目前云平臺租戶模式有三種：統(tǒng)一客戶模式、多查詢者模式和多數(shù)據(jù)擁有者模式[4]。云數(shù)據(jù)庫作為一種典型的多租戶數(shù)據(jù)庫服務，主要以多查詢者模式和多數(shù)據(jù)擁有者模式為主。云數(shù)據(jù)庫中存放著許多企業(yè)租戶的內部數(shù)據(jù)，企業(yè)用戶通過云數(shù)據(jù)庫平臺獲取自己的數(shù)據(jù)，但不希望這些數(shù)據(jù)被企業(yè)內部其他部門的用戶任意訪問，更不希望被其他租戶竊取或者篡改，因此實現(xiàn)多租戶間的數(shù)據(jù)安全隔離和租戶內部用戶的隱私安全是云數(shù)據(jù)庫亟待解決的重要問題。

針對不同租戶的數(shù)據(jù)安全隔離問題，不少學者展開了相關研究。文獻[5]中提出了一個基于多租戶數(shù)據(jù)庫模式的彈性擴展表訪問控制模型，在數(shù)據(jù)表級別上實現(xiàn)了不同租戶的用戶細粒度訪問控制；但是無法防止云數(shù)據(jù)庫提供商對數(shù)據(jù)的窺視。文獻[6]中提出了一種共享數(shù)據(jù)庫共享數(shù)據(jù)表的多租戶數(shù)據(jù)隔離方法，通過租戶id進行兩階段映射來確保不同租戶之間的數(shù)據(jù)隔離；但是租戶id是由數(shù)據(jù)庫管理員(DataBase Administrator， DBA)提供的，存在DBA可以隨意獲取租戶的風險。文獻[7]中以基于角色訪問控制(Role Based Access Control, RBAC)策略為基礎，結合組織標簽和多種安全屬性的邏輯組合，提出一種靈活的訪問控制策略，既可保證不同企業(yè)租戶之間數(shù)據(jù)的強隔離，也可保證企業(yè)內部數(shù)據(jù)的適度隔離。文獻[8]中提出了一種基于目的訪問控制(Purpose Based Access Control, PBAC)和基于屬性基加密(Attribute Based Encryption, ABE)相結合的云數(shù)據(jù)訪問控制模型，在原有的PBAC模型基礎上加入了屬性目的集合的概念。已有的研究已經(jīng)能夠很好地實現(xiàn)在多租戶的云數(shù)據(jù)庫系統(tǒng)中不同租戶間的數(shù)據(jù)隔離,但是存在云數(shù)據(jù)庫管理者探查、泄露隱私數(shù)據(jù)的可能性，對租戶內部用戶隱私數(shù)據(jù)的訪問策略不夠靈活。

面向多租戶的云數(shù)據(jù)庫服務，本文設計并實現(xiàn)了一種面向多租戶云數(shù)據(jù)庫的屬性基加解密及查詢轉換的服務中間件。主要工作有：1)搭建一個多租戶MySQL云數(shù)據(jù)庫管理系統(tǒng)，為租戶提供高可用的數(shù)據(jù)庫服務；2)針對云數(shù)據(jù)庫管理者權限過高的安全隱患問題和租戶隱私數(shù)據(jù)的細粒度訪問控制，設計并實現(xiàn)了一種面向多租戶云數(shù)據(jù)庫的屬性基加解密及查詢轉換的服務中間件，為租戶的對稱密鑰提供屬性基加解密服務，保證數(shù)據(jù)的安全性，租戶可以靈活自主定義隱私保護數(shù)據(jù)的訪問控制策略，實現(xiàn)細粒度訪問控制；3)實驗驗證屬性基加解密及查詢轉換的服務中間件的有效性和可行性。

1 相關工作

云數(shù)據(jù)庫雖然對海量數(shù)據(jù)的存儲提供了便利，但同時也對數(shù)據(jù)的機密性和訪問控制等安全問題提出了新的挑戰(zhàn)：一方面，一些如企業(yè)財務數(shù)據(jù)、醫(yī)療病歷檔案、政府文件等敏感數(shù)據(jù)，必須經(jīng)過加密才能放在云數(shù)據(jù)庫中；另一方面，針對眾多的租戶，必須設置不同粒度的訪問控制，保證不同層次的租戶只能訪問授權限定范圍內的數(shù)據(jù)。因此，如何在云數(shù)據(jù)庫中對數(shù)據(jù)實現(xiàn)有效加密和應用不同粒度的訪問控制規(guī)則，就成為了新的研究熱點。

文獻[9]提出了一種通過采用元數(shù)據(jù)和特權訪問控制的方法來實現(xiàn)對云數(shù)據(jù)庫資源的可信授權訪問。該方法將每個虛擬機內存(Virtual Machine Memory， VMM)中的授權策略和云數(shù)據(jù)庫中的資源都構建成以圖表示的特權鏈，用來進行訪問和安全控制。文獻[10]重點研究了支持多個租戶在加密云數(shù)據(jù)庫上執(zhí)行SQL 查詢，并允許數(shù)據(jù)庫管理員對不同用戶設置不同級別的訪問權限。為了實現(xiàn)只有授權用戶才能對數(shù)據(jù)進行訪問，文中采用基于密鑰策略的屬性基加密(Key Policy Attribute Based Encryption, KP-ABE)策略，即每條策略都和用戶的解密密鑰關聯(lián)，分配給每個用戶的訪問策略就被內嵌到該用戶的解密密鑰中。因此，只有當一個用戶的解密密鑰中包含的訪問策略允許該用戶訪問某個數(shù)據(jù)時，該用戶才可以訪問該數(shù)據(jù)。

當前，基于密文策略的屬性基加密(Ciphertext Policy Attribute Based Encryption, CP-ABE)方法被認為是可用于云環(huán)境下訪問控制的一種方法。通過移動終端使用云數(shù)據(jù)庫服務將成為一種趨勢，而移動智能終端計算能力較弱、能量較低等問題導致不適合直接在用戶端進行加解密。另一方面，由于云數(shù)據(jù)庫的用戶基數(shù)大，而用戶也時常進行海量數(shù)據(jù)的訪問，解密工作同樣不適宜在數(shù)據(jù)庫服務器上運行，以免造成云數(shù)據(jù)庫服務質量的下降。2011年，Green等[11]提出了一種解密運算外包方案，該方案將密文傳給解密外包服務器，解密外包服務器對密文進行一次密文轉換獲得中間密文傳給用戶，能降低本地解密過程的計算量。2012年，Zhou等[12]提出了一種同時支持加密和解密外包的ABE方案。2013年，Lai等[13]實現(xiàn)外包解密的同時，支持對外包服務的正確性驗證。2015年，王皓等[14]給出了一個外包ABE方案的形式化定義，并構造了一個具體的外包CP-ABE方案。2016年，蔡孟飛等[15]提出一種面向移動云存儲的屬性基解密服務中間件，為移動終端提供代理屬性基解密服務，提高了解密速度。因此，在保證安全的情況下將加解密工作外包給第三方，是一種高效、經(jīng)濟的解決方案。

2 屬性基加密算法

2.1 理論基礎

雙線性映射：設G1、G2分別是階為p的加法群和乘法群，g為群G1的生成元。e:G1×G1→G2為滿足下列性質的雙線性對：

2)非退化性：?P,Q∈G1，滿足e(P,Q)≠1；

3)可計算性：對于P,Q∈G1，存在一個有效的計算方法e(P,Q)。

2.2 基于代理的屬性基加密算法

本服務中間件的屬性基加解密算法基于文獻[15]和文獻[16]提出的CP-ABE，主要包括：

1)初始化算法Setup(λ,P)={PK,MSK,PKx}：由屬性權威(Attribute Authority，AA)執(zhí)行，輸入安全參數(shù)λ和AA所管理的屬性全集P。算法選取一個階為p的循環(huán)群G，其生成元為g；一個映射函數(shù)ρ，該函數(shù)將P中的每一個屬性映射為G中的一個元素；并隨機從Zp中選取三個參數(shù)α,β,a。然后對于P中的每一個屬性x，設置屬性參數(shù)Vx∈Zp。算法輸出公鑰PK={g,e(g,g)α,ga,ρ}，屬性公鑰PKx={gVx}x∈P，主密鑰MSK={α,β,{Vx}x∈P}。

2)加密算法Encrypt(φ,PK,PKx,A)=CT：輸入PK、PKx、待加密消息φ以及訪問控制策略A，輸出密文(CipherText，CT)。算法根據(jù)訪問控制策略A生成一個線性秘密分享方案(Linear Secret Sharing Scheme， LSSS)矩陣Mn,k。然后隨機選取V=[s,y1,y2,…,yk-1]T，并計算λ=MV。另外隨機選取r1,r2,…,rn∈Zp。輸出CT={C=φ·e(g,g)αs,C′=gs,{Ci=gaλi·[gVxi·ρ(xi)]-ri,Di=gri}1≤i≤n}，其中xi為矩陣M第i行所對應的屬性。

3)私鑰生成算法Keygen(MSK,PK,PKx,S)={TK,SK}：輸入MSK、PK、PKx以及該用戶的屬性集S，輸出用戶私鑰SK以及轉換私鑰TK。隨機選取z∈Zp，輸出TK={K=gα/z·gaβ/z,L=gβ/z,{Kx=[gVx·ρ(x)]β/z}x∈S}，SK={z}。其中TK由服務中間件持有，SK由用戶持有。

5)解密算法Decrypt(CT′,SK)=φ：根據(jù)數(shù)據(jù)請求者的SK，中間件計算C/Rz=φ。

3 加解密及查詢轉換中間件

3.1 系統(tǒng)架構

應用屬性基加密的云數(shù)據(jù)庫隱私數(shù)據(jù)加密查詢的系統(tǒng)架構主要由數(shù)據(jù)庫服務提供者(DaaS Provider，DSP)、租戶(Tenant，TA)、租戶用戶(Tenant Users，TU)、屬性權威(AA)、加解密和查詢轉換中間件(Cryptography and Query Transformation Middleware，CQTM)組成，系統(tǒng)架構如圖1所示。

圖1 系統(tǒng)架構

其中AA是整個系統(tǒng)的核心，負責系統(tǒng)的初始化、對稱密鑰和密鑰生成等一系列工作；數(shù)據(jù)的擁有者租戶TA將訪問控制策略上傳給加解密和查詢轉換中間件；加解密和查詢轉換中間件CQTM部署在云端，負責數(shù)據(jù)庫的對稱密鑰的加密解密工作和數(shù)據(jù)庫查詢的轉換工作。在整個系統(tǒng)中，云端主機都是忠誠但好奇的，即會正確執(zhí)行系統(tǒng)的命令，同時又會設法獲取數(shù)據(jù)信息。租戶用戶TU是DSP中數(shù)據(jù)庫數(shù)據(jù)的訪問者。在本系統(tǒng)架構中，涉及了兩種加密算法：基于屬性基加密算法和對稱加密算法。對稱加密算法采用MySQL提供的高級加密標準(Advanced Encryption Standard, AES)，可以直接對數(shù)據(jù)表的字段加密。而基于屬性基加密算法負責對AES算法的密鑰進行加密，生成密文CT。用戶只有通過屬性基解密算法解密CT得到對稱密鑰，才能對數(shù)據(jù)庫的隱私數(shù)據(jù)進行操作，包括寫入和讀取。

3.2 系統(tǒng)初始化

當租戶在云數(shù)據(jù)庫平臺成功訂閱數(shù)據(jù)庫服務后，屬性權威AA加解密及查詢轉換中間件CQTM為租戶進行初始化工作，具體步驟如下：

1)屬性權威AA為租戶生成PK、MSK、PKx并傳給中間件。

2)租戶上傳訪問控制策略A到中間件。

3)屬性權威AA為租戶分配一個128比特的對稱密鑰syn_key。

4)中間件執(zhí)行加密算法將syn_key加密，生成密文CT，并保存于CT關系表。

3.3 中間件的結構模型

加解密及查詢轉換中間件的結構模型包括加解密組件和查詢轉換組件。加解密組件負責加密和解密租戶獲取數(shù)據(jù)庫隱私數(shù)據(jù)所需的對稱密鑰，查詢轉換組件實現(xiàn)了查詢語句的轉換功能，將一般的SQL語句進行轉換，使其可以在加密后的云數(shù)據(jù)庫上正確執(zhí)行。結構模型如圖2所示。

圖2 加解密及查詢轉換中間件結構模型

4 中間件關鍵技術實現(xiàn)

4.1 加解密部件

加解密部件的結構模型如圖3所示，其中：數(shù)據(jù)庫設計包括CT關系表和TK-CT′ 關系表；功能模塊包括TK上傳模塊、加密模塊、代理解密模塊和解密模塊。

圖3 加解密部件

加密模塊：該模塊負責用戶對稱密鑰的加密。AA將PK、PKx和對稱密鑰傳給加密模塊，結合用戶上傳的訪問控制策略A，執(zhí)行加密算法Encrypt生成密文，并保存在CT關系表中。

TK上傳模塊：面向屬性權威AA提供服務。當AA發(fā)布某個用戶的TK到服務中間件后。該模塊將TK查詢TK-CT′關系表是否存在記錄，若沒有則保存該TK并向代理解密模塊發(fā)起解密請求。

代理解密模塊：當數(shù)據(jù)請求者首次請求數(shù)據(jù)時，代理解密模塊使用該用戶的TK，將對應文件的CT進行代理解密，并將結果CT′保存在TK-CT′關系表中。

解密模塊：查詢TK-CT′關系表得到CT′，和用戶的SK一同執(zhí)行解密算法Decrypt，得到對稱密鑰syn_key。

4.2 查詢轉換部件

查詢轉換部件負責將用戶的原始查詢語句轉換為定義在隱私字段上的查詢，以使得它們能夠在云數(shù)據(jù)庫上正確執(zhí)行。查詢轉換部件結構模型如圖4所示。

圖4 查詢轉換部件

字段類型轉換模塊：負責將要加密的字段的數(shù)據(jù)類型轉換成VARBINARY類型，并把加密的字段保存在加密字段表中。租戶可以按照自己的需求決定哪些字段需要加密存儲，而加密的字段信息會影響數(shù)據(jù)庫的定義，從數(shù)據(jù)庫的角度看，這種影響在于如何選擇字段的數(shù)值類型。例如表1未加密數(shù)據(jù)庫的表結構中，“start_date”字段是date類型，“ID_num”是bigint類型，而name 和address為varchar類型。然而，在需要進行AES加密的數(shù)據(jù)庫表結構中，需要把數(shù)據(jù)庫字段的數(shù)據(jù)類型設置為VARBINARY類型。

表1 數(shù)據(jù)庫表結構對比

4.3 查詢語句轉換算法

查詢語句轉換指將用戶的原始查詢語句轉換為帶有對稱密鑰的加密查詢語句，新的查詢語句可以在云數(shù)據(jù)庫上運行并可以訪問隱私數(shù)據(jù)。從應用服務和用戶的角度出發(fā)，查詢語句轉換模塊需要對用戶的查詢語句進行轉換來滿足數(shù)據(jù)庫的加密操作，算法描述如下：

輸入 查詢語句Q；

輸出 轉換后的查詢語句Tq。

FUNCTION queryTranslation(Q){

//向加解密部件請求對稱密鑰syn_key

syn_key=getSyn_key();

IFsyn_keyIS NULL THEN

RETURNTq=Q;

//無訪問權限，直接執(zhí)行Q

ELSE THEN

Field[]=getEncryptField();

Tq=translation(Q,syn_key,field[]);

END IF

}

上述算法完成后，查詢轉換模塊將轉換后的查詢語句Tq傳給數(shù)據(jù)庫執(zhí)行，并返回查詢結果給用戶。

租戶的一般查詢語句經(jīng)過查詢轉換模塊后語句結構將發(fā)生變化，查詢語句結構轉換前后對比如表2所示。

表2 查詢轉換前后的查詢語句對比

5 云數(shù)據(jù)庫應用

5.1 MySQL云數(shù)據(jù)庫構建

基于MySQL Cluster技術搭建一個多租戶的MySQL云數(shù)據(jù)庫,實現(xiàn)在Web門戶端進行租戶注冊登錄、創(chuàng)建實例。租戶可以在每個實例下創(chuàng)建下屬的用戶和數(shù)據(jù)庫，并對用戶授權數(shù)據(jù)庫的權限。普通用戶根據(jù)用戶名和密碼，即可在線登錄數(shù)據(jù)庫訪問和操作擁有權限的數(shù)據(jù)庫，實現(xiàn)數(shù)據(jù)庫即服務的功能。MySQL云數(shù)據(jù)庫包括以下三個模塊，軟件結構如圖5所示。

圖5 MySQL云數(shù)據(jù)庫軟件結構

1)租戶信息管理模塊：租戶信息管理端提供租戶的注冊登錄功能，租戶可以創(chuàng)建屬于自己的實例，在實例下可以創(chuàng)建多個子用戶和多個數(shù)據(jù)庫，可以根據(jù)需求對子用戶授權數(shù)據(jù)庫的訪問和操作權限。

2)在線數(shù)據(jù)庫管理模塊：用戶用已經(jīng)授權的賬號登錄數(shù)據(jù)庫管理界面，就可以對相應的數(shù)據(jù)庫進行增刪改查等操作。

3)MySQL存儲模塊： MySQL Cluster 自動將表分片(或分區(qū))到不同節(jié)點上，使數(shù)據(jù)庫可以便捷地進行橫向擴展，同時保持對應用程序完全應用透明。提供 99.999% 的可用性，確保了較強的故障恢復能力和在不停機的情況下執(zhí)行預定維護的能力。

5.2 數(shù)據(jù)寫入

數(shù)據(jù)寫入流程如圖6所示，具體如下：

1)屬性權威為TA生成一個128比特的對稱加密密鑰syn_key，并發(fā)送給服務中間件；

2)TA將自定義的訪問控制策略A傳給服務中間件；

3)加解密部件的加密模塊使用Encrypt算法對syn_key進行加密，生成CT，并保存至CT關系表中；

4)查詢轉換部件的字段類型轉換模塊將TA定義的需要加密的字段保存至加密字段表；

5)查詢轉換部件的查詢語句轉換模塊得到對稱密鑰和原始SQL語句，轉換為AES_ENCRYPT函數(shù)加密的語句，往數(shù)據(jù)庫寫入數(shù)據(jù)。

圖6 數(shù)據(jù)寫入流程

5.3 數(shù)據(jù)查詢

數(shù)據(jù)查詢流程如圖7所示，具體如下：

1)TU將要訪問的數(shù)據(jù)庫和數(shù)據(jù)表發(fā)給服務中間件。

2)服務中間件的加解密部件根據(jù)數(shù)據(jù)庫和表名加載CT，并查詢該TU的屬性集，測試屬性集是否滿足CT的訪問控制策略：若滿足，則繼續(xù)步驟3)；否則返回失敗提示信息給用戶，執(zhí)行步驟7)。

3)加解密部件加載當前用戶的TK，查詢TK-CT′關系表，若CT′為空，則執(zhí)行步驟4)，否則執(zhí)行5)。

4)加解密部件根據(jù)用戶的TK，使用Transform算法對CT代理解密，得到CT′，并將TK和CT′保存在TK-CT′關系表中。

5)加解密部件根據(jù)用戶的SK，通過Decrypt算法將CT′解密，得到對稱密鑰syn_key，并傳給用戶和查詢轉換部件。

6)服務中間件的查詢轉換部件將查詢語句和對稱密鑰轉換為數(shù)據(jù)庫執(zhí)行語句，對數(shù)據(jù)庫進行讀寫操作。

7)用戶可以訪問部分數(shù)據(jù)庫數(shù)據(jù)，對于加密的字段則無法獲取。

圖7 數(shù)據(jù)查詢流程

6 實驗分析

6.1 實驗環(huán)境

采用Java語言實現(xiàn)了整個面向多租戶云數(shù)據(jù)庫的屬性基加解密和查詢轉換中間件。實驗環(huán)境包括兩臺曙光服務器，在曙光W5801-G10上配置2臺VMware虛擬機，分別部署服務中間件和屬性權威。在曙光24000635部署5臺VMware虛擬機，安裝MySQL集群，包括一個管理節(jié)點和四個數(shù)據(jù)節(jié)點，MySQL集群模擬云數(shù)據(jù)庫環(huán)境。具體的硬件參數(shù)如表3所示。

表3 實驗設備

6.2 數(shù)據(jù)插入

數(shù)據(jù)經(jīng)過加密后存入數(shù)據(jù)庫，勢必對用戶的業(yè)務操作造成一定程度的影響。用戶90%以上的操作集中在數(shù)據(jù)插入和數(shù)據(jù)查詢，本文分別在普通數(shù)據(jù)庫dbemployees和加密數(shù)據(jù)庫dbemployeesAES執(zhí)行數(shù)據(jù)插入和數(shù)據(jù)讀取操作。

分別在普通數(shù)據(jù)庫dbemployees和加密數(shù)據(jù)庫dbemployeesAES執(zhí)行插入操作，耗時對比如表4所示，其中實驗場景I1、I2、I3、I4和I5分別表示以下五種場景：

1)I1-(Employees table)：插入一條只含18個字符的ID_num字段的記錄；

2)I2-(Employees table)：插入一條含ID_num和address字段的記錄,address的字符數(shù)不超過200；

3)I3-(Employees table)：批量完成插入10 000條記錄；

4)I4-(JobRoles table)：批量完成插入15 000條記錄；

5)I5-(Incomes table)：批量完成插入200 000條記錄。

表4 不同場景插入操作的耗時對比 ms

6.3 數(shù)據(jù)查詢

為了確認加密對查詢業(yè)務速度的影響，本實驗逐步增加查詢的復雜度。耗時對比如表5所示，其中實驗場景S1、S2、S3和S5分別表示以下四種場景：

S1:查詢一張表，以一個字段作為過濾條件，返回一行兩列的一條記錄。如查詢employees表中姓名是張三的身份證號和地址。

S2:查詢一張表，以一個字段作為過濾條件，返回若干行記錄，并按照某個字段降序排列。如查詢Incomes 2018年員工的每個月收入，按照員工號和月份降序輸出。

S3:查詢兩張表，按照某個字段過濾，返回若干行記錄。如聯(lián)合查詢employees和JobRoles表，返回manager是李四的員工的信息。

S4:查詢一張表，用日期來比較，返回若干條記錄。如查詢JobRoles表入職時間是2012年3月份之后的員工信息。

表5 不同場景查詢操作耗時對比 ms

實驗結果顯示：對于插入操作而言，數(shù)據(jù)加密和數(shù)據(jù)不加密的時間開銷沒有明顯的區(qū)別。主要的原因有：1)數(shù)據(jù)庫有不同的數(shù)據(jù)結構類型；2)加密的時間開銷很小，只占整個操作總時間的1%～2%；3)向數(shù)據(jù)庫插入加密數(shù)據(jù)以批處理執(zhí)行。對于查詢操作，加密數(shù)據(jù)庫的查詢時間明顯長于無加密的查詢，根據(jù)查詢語句的復雜程度，查詢時長增加10%～150%不等?？紤]用戶與數(shù)據(jù)庫的交互主要是查詢業(yè)務為主，未加密的數(shù)據(jù)庫查詢更具優(yōu)勢，然而這樣的優(yōu)勢差距并不足以影響用戶的使用體驗。

6.4 基于代理的屬性基解密性能

為了驗證代理解密算法能夠有效降低租戶獲取對稱密鑰的時間開銷，實驗分別測試了CT中屬性個數(shù)為2～20時使用原始屬性基解密和代理解密的時間開銷，結果如圖8所示。從實驗結果可以看出，通過使用中間件的代理解密模塊可以大幅度降低用戶解密密文獲取對稱密鑰的時間。通過分析可知，當在中間件采用代理加密時，無論CT中訪問控制策略如何復制，在首次解密初始化后，用戶獲取對稱密鑰只需中間件執(zhí)行一次指數(shù)運算和一次除法運算；而如果在中間件采用原始屬性基解密方案，則解密時間隨屬性個數(shù)的增加呈線性增長。

圖8 解密時間對比

6.5 方案分析

6.5.1 安全性分析

代理解密的過程，通過分析本文方案和文獻[16]方案的密鑰生成算法可知，本文方案的TK即為文獻[16]方案的私鑰的z次冪。本文方案中私鑰z由用戶持有，當進行代理解密時，輸出半解密密文CT′，如果解密代理想要獲得明文，必須獲得用戶私鑰，但這是不可能的。

當解密代理和數(shù)據(jù)庫租戶進行串謀時，由密鑰生成過程看出，數(shù)據(jù)庫租戶的每一個屬性同隨機數(shù)β/z進行綁定。假設租戶T1擁有屬性attr1和租戶T2擁有屬性attr2，當T1企圖獲得屬性attr2時，則通過與T2和解密代理進行串謀獲得屬性attr2，由轉換密鑰的結構可知，他們必須獲得PKattr2，然后計算出KT1,attr2=[gVattr2·ρ(x)]βT1/zT1構成T1新的轉換密鑰。盡管在T2的轉換密鑰中有KT2,attr2=[gVattr2·ρ(x)]βT2/zT2，同時能夠從私鑰中獲得zT2但是無法獲得βT2，因此該過程無法獲得PKattr2，則T1無法獲得attr2，所以解密代理能夠抗串謀攻擊。

6.5.2 時間復雜性分析

在CP-ABE方案中，指數(shù)運算te和配對運算tp是耗時最多的兩個運算，因此本文只討論指數(shù)運算和配對運算。假設訪問控制樹中屬性個數(shù)為n，租戶的屬性集為m。由第2章的密文生成算法Encrypt可知，生成密文CT={C=φ·e(g,g)αs,C′=gs,{Ci=gaλi·[gVxi·ρ(xi)]-ri,Di=gri}1≤i≤n} 。其中C=φ·e(g,g)αs執(zhí)行一次te，C′=gs執(zhí)行一次te，Ci=gaλi·[gVxi·ρ(xi)]-ri執(zhí)行兩次te，Di=gri執(zhí)行te運算，所以本文方案加密時間為(2+3n)te。

在解密過程中的時間開銷主要包括代理解密部分解密開銷2mtp+mte和加解密部件解密開銷te。屬性基加解密計算復雜度對比如表6所示。由表6可知，本文方案的加密性能與文獻[16]方案相當，優(yōu)于文獻[17]方案；采用代理機制之后，加解密部件的計算復雜度明顯降低，與文獻[16-17]的方案相比具有明顯優(yōu)勢。

表6 時間復雜度對比

7 結語

針對云數(shù)據(jù)庫中多租戶隱私數(shù)據(jù)的加密查詢問題，本文提出并實現(xiàn)了一種面向多租戶云數(shù)據(jù)庫的屬性基加解密和查詢轉換中間件?；诜罩虚g件，數(shù)據(jù)庫租戶可在不泄露信息的前提下，將屬性基加解密過程中的計算工作外包，租戶可以快速地獲取數(shù)據(jù)庫加密的對稱密鑰，將查詢語句轉換為AES_ENCRYPT函數(shù)加密的語句，實現(xiàn)數(shù)據(jù)庫的訪問查詢操作。整個過程對用戶而言是透明的，適合租戶在不同的操作終端上使用云數(shù)據(jù)庫服務。面向云數(shù)據(jù)庫服務測試了中間件的性能，結果表明，屬性基加解密及查詢轉換中間件可以縮短租戶獲取對稱密鑰的時間，對數(shù)據(jù)庫隱私數(shù)據(jù)的加密也能夠滿足實際應用的需求。