薛金紅, 田秀霞, 宋 謙, 田福糧

(上海電力大學(xué) 計算機(jī)科學(xué)與技術(shù)學(xué)院, 上海 200090)

隨著云計算的迅猛發(fā)展,越來越多的企業(yè)、個人將數(shù)據(jù)遷移到了云端,并利用云數(shù)據(jù)庫管理系統(tǒng)數(shù)據(jù)。與傳統(tǒng)數(shù)據(jù)庫相比,云數(shù)據(jù)庫的可擴(kuò)展性與靈活性較好,效率更高,但在數(shù)據(jù)安全保障方面存在很大不足。為了解決數(shù)據(jù)存儲的安全問題,一般將數(shù)據(jù)加密后存儲,即使攻擊者獲得數(shù)據(jù)訪問權(quán)限,仍能保證數(shù)據(jù)的機(jī)密性。如果使用傳統(tǒng)加密算法(AES,3DES)加密數(shù)據(jù),用戶每次檢索、計算和分析數(shù)據(jù)都必須把密文傳回客戶端,進(jìn)行解密后再做處理,勢必會向客戶端傳回大量無用密文,使得數(shù)據(jù)庫只起到存儲介質(zhì)的作用,浪費了其本身的能力資源,顯著降低了效率。直接在加密數(shù)據(jù)上執(zhí)行數(shù)據(jù)庫操作,是在密文數(shù)據(jù)庫進(jìn)行查詢處理的另一途徑。

2011年P(guān)APO R A等人[1-2]提出的CryptDB是一個經(jīng)典的基于可信中間代理、不可信數(shù)據(jù)庫系統(tǒng)的密文數(shù)據(jù)庫。典型的CryptDB系統(tǒng)由應(yīng)用程序、數(shù)據(jù)庫代理、未修改的數(shù)據(jù)庫系統(tǒng)3部分組成,其中間代理充當(dāng)媒介,操控、改寫收到的SQL指令和數(shù)據(jù)庫返回的結(jié)果集合,數(shù)據(jù)庫系統(tǒng)中增加CryptDB用戶自定義函數(shù)(User Define Function,UDF)模塊,輔助實現(xiàn)復(fù)雜密文操作(如數(shù)據(jù)聚合、兩列連接、關(guān)鍵字搜索等)。最重要的是,CryptDB是分離式架構(gòu),易于部署,兼容性好,非常適用于云數(shù)據(jù)庫應(yīng)用場景。

然而,CryptDB系統(tǒng)中密鑰信息是以明文形式存儲在代理服務(wù)器,安全性較低。本文提出通過用戶口令加密密鑰信息來增強(qiáng)密鑰安全性,同時以中間代理間接驗證用戶身份這一方法,有效地管理了代理服務(wù)器資源。

1 研究現(xiàn)狀

1978年RIVEST R L等人[3]提出了全同態(tài)加密(Fully Homomorphic Encryption,FHE),嘗試在加密數(shù)據(jù)上進(jìn)行計算。2009年GENTRY C[4]基于理想格理論設(shè)計出了第一個全同態(tài)構(gòu)造,后續(xù)嘗試優(yōu)化以改善其性能[5]。但由于其公鑰太大,生成時間長,效率低下,不具有實用價值,用全同態(tài)加密解決密文查詢問題還有待進(jìn)一步的研究。

CryptDB以洋蔥加密方式[1-2]拆分明文列為多密文列,每個密文列承擔(dān)不同的運算操作功能,并組合多種支持?jǐn)?shù)據(jù)庫操作的密碼學(xué)技術(shù)(如隨機(jī)加密、確定性加密、保序加密、可搜索加密及Join等),每個洋蔥逐層嵌套加密,使得數(shù)據(jù)庫的安全性從里到外逐層增強(qiáng)、功能逐層減弱,最大化保證數(shù)據(jù)的安全性;而且,與明文數(shù)據(jù)庫相比,CryptDB數(shù)據(jù)庫開銷小,吞入量下降少,實現(xiàn)了系統(tǒng)安全、功能和性能三者之間的兼顧和平衡。

TU S等人[6]在CryptDB的基礎(chǔ)上設(shè)計了Monimi,引入根據(jù)查詢負(fù)載特點選擇數(shù)據(jù)庫物理布局的設(shè)計器和運行時選擇高效查詢計劃的計劃器,并結(jié)合多種優(yōu)化方法,如行預(yù)計算、空間高效加密、組同態(tài)加密等,提高了查詢執(zhí)行效率。LI J等人[7]提出了輕量型的密文數(shù)據(jù)庫L-EncDB,采用組合格式加密(Format-Preserving Encryption,FPE)、模糊查詢(Fuzzy Query Encryption,FQE)和保序加密(Order-Preserving Encryption,OPE)解析SQL查詢請求,但系統(tǒng)過度依賴函數(shù)實現(xiàn)功能,可擴(kuò)展性差。陳鶴等人[8]針對CryptDB洋蔥加密方式的不足提出了優(yōu)化改進(jìn)模型Crypt-JDBC密文數(shù)據(jù)庫,由JDBC充當(dāng)中間組件,將密文列分為主列和輔助列(保序列、搜索列、等值連接列)。主列采用雙向加密方法,可以解密出明文;輔助列采用單向加密方法,不可解密,支持各類運算操作。但取消了對用戶自定義函數(shù)的依賴,多層嵌套式密文不適用于該模型。BURKHALTER L等人[9]提出了加密時序數(shù)據(jù)庫TimeCrypt,是專為時間序列數(shù)據(jù)量身定做的,支持在大容量加密時序數(shù)據(jù)上的快速統(tǒng)計查詢,而且用戶可以根據(jù)預(yù)先定義的訪問策略以加密方式限制查詢和數(shù)據(jù)訪問范圍。

2 方案設(shè)計

PAPO R A等人[1-2,9]開放了CryptDB項目源碼,其前端用Mysql-Client替代,后端用Mysql-Server替代,數(shù)據(jù)庫代理由Mysql-Proxy充當(dāng)。Mysql-Proxy可通過lua腳本接口調(diào)用C鏈接庫擴(kuò)充邏輯,實現(xiàn)復(fù)雜功能。為方便描述,下面將Mysql-Client簡稱為客戶端,Mysql-Proxy簡稱為代理,Mysql-Server簡稱為數(shù)據(jù)庫。

2.1 問題描述

客戶端、代理和數(shù)據(jù)庫三者之間的交互分為3個階段,分別為連接認(rèn)證、查詢處理和斷開連接。

2.1.1 連接認(rèn)證

客戶端、代理及數(shù)據(jù)庫連接認(rèn)證流程步驟如圖1所示。

圖1 客戶端、代理和數(shù)據(jù)庫連接認(rèn)證流程

(1) 客戶端向代理發(fā)起TCP連接,建立傳輸通道。

(2) 代理向數(shù)據(jù)庫響應(yīng)初始握手包(包括協(xié)議版本號、數(shù)據(jù)庫軟件版本、服務(wù)器授權(quán)信息及服務(wù)器權(quán)能標(biāo)志等信息)。

(3) 客戶端回應(yīng)登錄驗證報文(包括賬號、密碼、默認(rèn)數(shù)據(jù)庫名稱及編碼方式等信息)。

(4) 代理向數(shù)據(jù)庫發(fā)出連接請求。

(5) 數(shù)據(jù)庫驗證賬號、密碼,并響應(yīng)驗證結(jié)果。

(6) 若驗證成功,代理讀取本地映射表,在內(nèi)存中加載SQL語句改寫邏輯,并向客戶端發(fā)送OK Packet;若驗證失敗,代理向客戶端發(fā)送ERR Packet。

2.1.2 查詢處理

連接成功后,當(dāng)客戶端發(fā)出明文查詢請求時,代理解釋、重寫SQL語句,加密明文數(shù)據(jù)后轉(zhuǎn)發(fā)到數(shù)據(jù)庫;當(dāng)數(shù)據(jù)庫返回密文結(jié)果集合后,代理解密數(shù)據(jù)并返回明文結(jié)果集合到客戶端。特別是當(dāng)查詢處理是數(shù)據(jù)庫定義(Data Definition Language,DDL)操作時,需要更新本地映射表。如當(dāng)創(chuàng)建表時,先將明文表名與密文表名、洋蔥加密存儲列表及對應(yīng)明文列名,密文列名、洋蔥層對應(yīng)密文查詢算法使用密鑰存入本地映射表,再將改寫后的SQL轉(zhuǎn)發(fā)到數(shù)據(jù)庫,生成密文表。具體查詢處理過程如圖2所示。

圖2 查詢處理流程

圖2左側(cè)student表是明文表結(jié)構(gòu),右側(cè)table_1表是student表對應(yīng)生成的密文表結(jié)構(gòu)。在表table_1中,C1開頭的列是明文列Id拆分運算屬性生成的密文列,C2開頭的列是明文列Name對應(yīng)密文列,當(dāng)前Id列和Name列的DET洋蔥都處于最外層?？蛻舳税l(fā)出查詢請求:select id from student where Name=“bear”,CryptDB處理查詢流程如下。

(1) Name列為相等條件判定,為調(diào)整其DET洋蔥到DET層,代理向數(shù)據(jù)庫發(fā)出查詢請求:UPDATE table_1 SET C2-Eq = DECRYPT_RND(KT1,C2,Eq,RND,C2-Eq,C2-IV)。其中列C2-IV是明文列Name隨機(jī)層加密使用初始參數(shù)鹽值(IV)的值。

(2) 代理改寫查詢請求后轉(zhuǎn)發(fā)到數(shù)據(jù)庫:select C1-Eq,C1-IV from table_1 where table_1 =x2..7,其中x2..7是“bear”依次用K(T1,C2,Eq,DET)和K(T1,C2,Eq,JOIN)作為密鑰加密得到的值。

(3) 數(shù)據(jù)庫返回密文結(jié)果集合,代理依次用K(T1,C1,Eq,JOIN),K(T1,C1,Eq,DET),K(T1,C1,Eq,RND)作為密鑰逐層解密C1-Eq值,得出23后返回到客戶端。

2.1.3 斷開連接

客戶端向代理發(fā)出TCP斷開請求后,代理向數(shù)據(jù)庫發(fā)出TCP斷開連接、銷毀關(guān)聯(lián)對象、釋放系統(tǒng)資源指示,本次連接斷開。

2.1.4 問題分析

由以上對數(shù)據(jù)庫客戶端、代理、數(shù)據(jù)庫三者間交互過程的描述可知:支持密文查詢處理密碼學(xué)協(xié)議使用密鑰信息以明文形式存儲在代理服務(wù)器;連接驗證過程中代理沒有直接驗證用戶身份,自動在內(nèi)存中加載查詢語句改寫方式。

若攻擊者獲取數(shù)據(jù)庫賬號、密碼、代理IP及端口,即可成功連接數(shù)據(jù)庫,獲得數(shù)據(jù)訪問權(quán)限,就存在很大安全隱患。本文采用用戶口令加密密鑰信息,對系統(tǒng)加以改進(jìn),改進(jìn)后系統(tǒng)模型如圖3所示。需要注意的是,此處的用戶指所有數(shù)據(jù)擁有者,或者程序高級管理員。

圖3 改進(jìn)后系統(tǒng)

2.2 用戶身份認(rèn)證方案

用戶身份認(rèn)證方案包括3個環(huán)節(jié),分別為用戶口令傳遞、用戶口令初始化和用戶口令更新。

2.2.1 用戶口令傳遞

用戶口令由用戶設(shè)置,需從客戶端傳遞到代理。用戶口令傳遞方式有兩種:一是增加一條獨立協(xié)議,傳遞用戶口令;二是擴(kuò)展官方認(rèn)證報文,添加用戶口令字段。

方式1獨立于Mysql官方通信協(xié)議,增加專門協(xié)議傳遞用戶口令,靈活性高;方式2擴(kuò)展Mysql官方用戶認(rèn)證報文,連接認(rèn)證流程無需變動。因為方式2代碼改動量小,易于實現(xiàn),故本文選用方式2。Mysql-Client 4.0以上版本認(rèn)證報文遵守HandshakeResponse41協(xié)議,擴(kuò)展后協(xié)議記為HandshakeResponse42,結(jié)構(gòu)如下。

capability flags,CLIENT_PROTOCOL_41 always set

max-packet size //最大包

haracter set //字符編碼

string[23] reserved (all[0]) //保留字段

string[NUL] username //用戶名

if capabilities & CLIENT_PLUGIN_AUTH_LENENC_CLIENT_DATA {

lenenc-int length of auth-response

string[n] auth-response

} else if capabilities & CLIENT_SECURE_CONNECTION {

length of auth-response

string[n] auth-response

} else {

string[NUL] auth-response

}

if capabilities & CLIENT_CONNECT_WITH_DB {

string[NUL] database

}

if capabilities & CLIENT_PLUGIN_AUTH {

string[NUL] auth plugin name

}

if capabilities & CLIENT_CONNECT_ATTRS {

lenenc-int length of all key-values

lenenc-str key

lenenc-str value

}

string[n] cryptdb-key

string[n] old-cryptdbkey

string[n]是可變長類型字符串,表1是HandshakeResponse42協(xié)議相對HandshakeResponse41協(xié)議的新增字段,用于實現(xiàn)用戶口令傳遞及更新。

表1 HandshakeResponse42協(xié)議新增字段

2.2.2 用戶口令初始化

客戶端首次連接代理,需要創(chuàng)建一個關(guān)聯(lián)數(shù)據(jù)庫。當(dāng)創(chuàng)建第一張表時,使用默認(rèn)用戶口令加密密文查詢算法,使用密鑰后再存儲,使用戶與用戶口令建立唯一對應(yīng)關(guān)系。如代理啟動服務(wù)后,終端下輸入以下命令啟動客戶端,連接代理:./mysql -u root -p200811 -h 127.0.0.1 -P 3307 --cryptdb_key=xxxxxx…xx。

其中xxxxxx…xx是默認(rèn)用戶口令值。

代理收到連接請求,客戶端直接返回OK Packet。成功連接后,客戶端依次發(fā)出以下查詢請求:

(1) create database cryptdb_test; //創(chuàng)建數(shù)據(jù)庫cryptdb_test;

(2) use cryptdb_test;

(3) create table student(Id int,Name Varchar(10));//創(chuàng)建表student。

查詢請求(3)中代理拆分明文Id列生成密文列為C1-IV,C1-Eq,C1-Ord,C1-Add。拆分Name列生成密文列為C2-IV,C2-Eq,C2-Ord,C2-Add,同時由主密鑰衍生密鑰種子值。最后向數(shù)據(jù)發(fā)出以下查詢請求:

create table_1 (C1-Eq BIGINT unsigned,C1-Ord BIGINT unsigned,C1-Add VARBINARY(256),C1-IV BIGINT(8) unsigned,C2-Eq VARBINARY(48),C2-Ord BIGINT unsigned,C2-Search VARBINARY(256),C2-IV BIGINT(8) unsigned)AUTO_INCREMENT=0 ENGINE=InnoDB。

數(shù)據(jù)庫執(zhí)行創(chuàng)建表操作,返回執(zhí)行結(jié)果,代理解密后,返回執(zhí)行結(jié)果到客戶端,至此用戶口令成功初始化。

2.2.3 用戶口令更新

用戶口令存在安全期限,長期不更換會給系統(tǒng)帶來一定的風(fēng)險,為此需要定期更新用戶口令。在擴(kuò)展認(rèn)證報文HandshakeResponse42協(xié)議中,當(dāng)old-cryptdbkey字段值不為空時,old-cryptdbkey字段代表舊用戶口令,cryptdb-key字段代表新用戶口令,用老口令解密得出密鑰信息,再使用新用戶口令加密密鑰信息后存儲在本地,至此用戶口令完成更新。如代理啟動服務(wù)后,終端下輸入以下命令啟動客戶端,連接代理:

./mysql -u root -p200811 -h 127.0.0.1 -P 3307 --cryptdb_key=xxxxxx…xx --old_cryptdbkey=yyyyyy…yy。

其中,xxxxxx…xx是新用戶口令值,yyyyyy…yy是老用戶口令值。

代理收到連接請求,向數(shù)據(jù)庫轉(zhuǎn)發(fā)連接請求,數(shù)據(jù)庫驗證結(jié)果OK,代理在內(nèi)存中加載SQL語句改寫方式,在此過程中用xxxxxx…xx解密密鑰信息,若解密成功,再用yyyyyy…yy加密密鑰信息后存儲在本地,代理再向客戶端發(fā)出OK Packet,至此用戶口令成功更新。

3 實 驗

實驗在Ubuntu12.04.1系統(tǒng)環(huán)境下進(jìn)行,Mysql-Client版本5.5.54,Mysql Proxy 版本0.8.4,Mysql server版本5.5.54,開發(fā)工具Qt Creator 3.4.1。

3.1 安全性分析

使用用戶口令加密密鑰信息后,密鑰信息以密文形式存儲在代理服務(wù)器外存,即使攻擊者得到加密的密鑰信息,密鑰安全性仍有一定保證。同時,在應(yīng)用連接代理過程中,加載查詢語句改寫方式中用戶口令要解密密鑰信息,達(dá)到了間接驗證用戶身份的效果。因此,本方案增強(qiáng)了CryptDB密鑰管理安全性,提高了系統(tǒng)整體的安全性。

3.2 時間復(fù)雜度分析

改進(jìn)后的系統(tǒng)記為CryptDB-1,以下實驗對比了CryptDB與CryptDB-1的執(zhí)行效率。以簡單增加表,插入數(shù)據(jù)為例,分別對比執(zhí)行5條,10條,20條,50條,60條語句的時間消耗。其中圖4描述了多次Create的總時間消耗情況。表2描述了執(zhí)行多次Create的單條平均消耗情況。

圖4 執(zhí)行多次Create消耗時間

表2 執(zhí)行多次Create單次平均消耗時間 ms

由圖4可以看出,創(chuàng)建表操作時,執(zhí)行相同條數(shù)CryptDB-1比CryptDB總消耗時間長;由表2可以發(fā)現(xiàn),隨著Create執(zhí)行次數(shù)的增加,CryptDB和CryptDB-1平均執(zhí)行一條的消耗時間也隨之增加,而且CryptDB-1比CryptDB平均執(zhí)行一條的消耗時間要長。因此,創(chuàng)建表CryptDB-1比CryptDB的執(zhí)行效率低。

圖5描述了執(zhí)行多次Insert的總時間消耗情況。表3描述了執(zhí)行多次Insert的單條平均時間消耗情況。

圖5 執(zhí)行多次Insert消耗時間

表3 執(zhí)行多次Insert單次平均消耗時間 ms

由圖5可以看出,CryptDB和CryptDB-1執(zhí)行多次Insert總消耗時間基本相同。由表3可以發(fā)現(xiàn),隨著執(zhí)行Insert次數(shù)的增加,CryptDB和CryptDB-1平均執(zhí)行一條的消耗時間都較短,同時CryptDB與CryptDB-1平均執(zhí)行一條的消耗時間基本相同,所以插入數(shù)據(jù)時,CryptDB和CryptDB-1執(zhí)行效率基本一致。

從上述實驗數(shù)據(jù)可以看出,在Create操作上,CryptDB-1比CryptDB效率低,原因是CryptDB-1中增加了用戶口令加密密鑰信息環(huán)節(jié),增加了時間消耗,使得系統(tǒng)效率降低。執(zhí)行Insert操作時,內(nèi)存中已加載SQL改寫方式,所以Insert操作時CryptDB-1效率保持一致,同理,執(zhí)行select,update,drop及delete操作時,CryptDB與CryptDB-1效率保持一致。

4 結(jié) 語

本文針對典型云密文數(shù)據(jù)庫CryptDB中密鑰信息以明文形式存儲、安全性低的特點,提出了使用用戶口令加密密鑰信息后以密文形式再存儲的方式,增強(qiáng)了密鑰管理的安全性。當(dāng)重新連接代理時,先解密密鑰信息,再在內(nèi)存中加載SQL語句改寫方式,在此過程中,代理間接驗證用戶身份,有效管理了代理服務(wù)器資源的訪問權(quán)限,顯著

提高了CryptDB系統(tǒng)整體的安全性,是數(shù)據(jù)庫技術(shù)與數(shù)據(jù)庫代理技術(shù)一次積極的融合。