王 崢,孫 梟

(太原理工大學信息與計算機學院，山西 晉中 030600)

1 引言

云計算作為一種網(wǎng)絡資源，被廣泛應用于人們的日常生活中。然而隨著物聯(lián)網(wǎng)技術(shù)的快速發(fā)展，數(shù)據(jù)爆發(fā)式地增長，海量數(shù)據(jù)被存儲到云服務器上。傳統(tǒng)的云計算模式面臨計算過于集中、系統(tǒng)效率低下等問題[1]。2012年，思科提出了霧計算的概念，將網(wǎng)絡計算從云計算中心擴展到了網(wǎng)絡邊緣，為物聯(lián)網(wǎng)提供了更加高效的服務[2]。然而數(shù)據(jù)存儲在云端或霧節(jié)點中，在為人們提供便利的同時，也帶來了數(shù)據(jù)的安全性問題[3，4]。為了保護數(shù)據(jù)的隱私，在上傳數(shù)據(jù)之前，需將其進行加密。密文策略屬性加密CP-ABE(Ciphertext-Policy Attribute-Based Encryption)[5]將解密規(guī)則嵌入到加密算法中，不僅保證了數(shù)據(jù)的安全性，而且還實現(xiàn)了一對多靈活的訪問控制，被認為是云存儲系統(tǒng)中的首選安全方案。

近年來，移動設備更加普及(如智能手機、筆記本電腦等)，然而大多數(shù)CP-ABE方案[6-10]中密鑰與密文的長度隨屬性數(shù)量線性增長，較大的存儲開銷無疑限制了該方案在資源有限的物聯(lián)網(wǎng)設備上的實際應用。因此，學者們在方案的輕量化改進方面進行了許多工作。Emura等人[11]提出了第1個密文定長的方案;Guo等人[12]實現(xiàn)了密鑰定長；Odelu等人[13]同時實現(xiàn)了密鑰與密文定長。但是,上述方案中的訪問策略僅支持(n,n)門限，難以實現(xiàn)靈活的策略表達。Herranz等人[14]提出了一種密文定長的方案，且支持(t,n)門限訪問，但加密階段需要n+t+1次指數(shù)運算，解密階段需要O(t2)次指數(shù)運算。為了解決效率低下的問題，Chen等人[15]提出了一種固定計算開銷的方案;唐忠原等人[16]提出了一種密鑰與密文都定長的方案，引入RSA算法的思想，簡化了加解密計算，但方案的安全性相對較低。

現(xiàn)有的CP-ABE方案大多是基于雙線性映射實現(xiàn)的，然而加解密過程中配對操作的次數(shù)與訪問策略中的屬性數(shù)量呈線性正相關(guān)。因此，對于移動終端而言，較長的加解密時間極大地影響了用戶體驗。計算外包是一種降低客戶端計算負擔的有效方法，在傳統(tǒng)云存儲中，Green等人[17]首次提出了解密外包的新范式;Li等人[18]與王樹蘭等人[19]都提出了可驗證的外包解密方案，且分別固定了密文與密鑰的長度，但均未實現(xiàn)加密外包；Ma等人[20]將復雜的加解密計算分別外包給加解密服務提供商，客戶端只需進行一次模冪運算，但同時增加了通信開銷與安全風險。隨著霧計算技術(shù)的逐漸成熟，霧節(jié)點層被加入到基于云存儲的物聯(lián)網(wǎng)系統(tǒng)，云霧架構(gòu)隨之形成。Zuo等人[21]提出了一種適用于霧計算的外包解密方案，且具有選擇密文攻擊下的不可區(qū)分性IND-CCA(INDistinguishability under Chosen-Ciphertext Attack)安全。Zhang等人[22]將與訪問策略相關(guān)的加密計算與部分解密計算外包給霧節(jié)點，但存儲開銷較大的問題并未得到改善。

基于上述問題，本文在霧環(huán)境中構(gòu)建了一個支持計算外包的微型CP-ABE方案。該方案不僅可以使密鑰與密文長度恒定，而且還支持(t,n)門限訪問，策略表達能力更強。此外，該方案還支持可驗證的加解密計算外包，減少了客戶端的加解密時間，系統(tǒng)效率更高，適用于資源有限的移動設備。

2 相關(guān)知識

2.1 雙線性映射

設G1,G2和GT是階為素數(shù)p的乘法循環(huán)群，g和h分別是G1和G2的生成元。若映射e:G1×G2→GT為一個雙線性映射，則它滿足如下性質(zhì)：

雙線性：對任意a,b∈Zp，e(ga,hb)=e(g,h)ab成立。

非退化性：e(g,h)≠1。

可計算性：存在一個有效的算法能夠計算出e(g,h)。

2.2 aMSE-DDH難題

構(gòu)造雙線性配對群G={G1,G2,GT,p,e}，假設f(x)和g(x)為群Zρ[x]上互質(zhì)的多項式，g0和h0分別是G1和G2的生成元,α和γ是群Zp上的隨機數(shù)。給定下述參數(shù):

aMSE-DDH難題就是判斷S是GT上的隨機數(shù)或者S=e(g0,h0)γf(α)。若對任意τ多項式時間攻擊者，解決此難題的最大優(yōu)勢為ε，那么稱它為(τ,ε)困難問題。

2.3 訪問樹

訪問樹是以樹狀圖的方式表達訪問控制策略，樹中存在2種節(jié)點：一種是葉子節(jié)點,代表屬性，另一種是非葉子節(jié)點,代表關(guān)系函數(shù)。只有屬性集合滿足策略的用戶才能夠成功解密密文。

Figure 1 Access tree

2.4 安全模型

本文所提方案的安全模型通過挑戰(zhàn)者B與攻擊者A交互進行的攻擊游戲來定義：

(1)初始化階段：A提交挑戰(zhàn)訪問結(jié)構(gòu)T*給B。

(2)系統(tǒng)建立階段：B輸入安全參數(shù)1k，生成公共參數(shù)PK和主密鑰MSK，并將PK發(fā)送給A。

(3)查詢階段1：A能夠向B發(fā)起如下查詢：

①任意屬性集合Ai的密鑰。

②密文Encrypt[Ti,Mi]的解密。

(4)挑戰(zhàn)階段：如果A沒有查詢過屬性集A(T*?A)的密鑰，那么A將消息M0和M1發(fā)送給B。B隨機選擇c′∈{0,1}，然后利用T*將消息Mc′加密，生成挑戰(zhàn)密文Encrypt[T*,Mc′]發(fā)送給A。

(5)查詢階段2：A重復對密鑰和密文查詢，但是有如下要求：

①不能查詢屬性集A(T*?A)的密鑰。

②不能查詢密文Encrypt[T*,Mc′]的解密。

(6)猜測階段：A提出猜測c′g∈{0,1}。如果c′g=c′，那么A取勝。

上述游戲中，A的優(yōu)勢ε=Pr[c′g=c′]-1/2。

定義1若任意τ多項式時間的A在進行至多qs次密鑰查詢和qd次解密查詢后，ε對于1k可忽略，則該方案具有(τ,qs,qd,ε)selective-IND-CCA安全。

3 系統(tǒng)描述與方案構(gòu)造

3.1 系統(tǒng)描述

本文所提方案的系統(tǒng)模型如圖2所示，包括5個不同的實體：可信授權(quán)機構(gòu)TA(Trusted Authority)、云服務器CS(Cloud Server)、霧節(jié)點FN(Fog Node)、數(shù)據(jù)擁有者DO(Data Owner)和數(shù)據(jù)用戶DU(Data User)。

Figure 2 System model

(1)可信授權(quán)機構(gòu)：TA被其他實體完全信任，所有屬性都由它管理。TA負責系統(tǒng)建立，為整個系統(tǒng)生成公共參數(shù)PK和主密鑰MSK，并分別為FN和DU生成霧節(jié)點密鑰FKA和用戶密鑰UKA。

(2)云服務器：CS擁有巨大的存儲空間和豐富的計算資源，但它并不是完全可信的。CS接收DO加密的數(shù)據(jù)后代為存儲，并為DU提供下載數(shù)據(jù)的服務。

(3)霧節(jié)點：FN是一些性能相對較弱、地理位置分散的各種功能計算機，也不是完全可信的。每個FN都與CS相連，在加密階段，F(xiàn)N首先接收DO上傳的訪問策略P,并生成部分加密密文CT′返回給DO,當DO進行完全加密生成密文CT之后，將CT上傳至CS存儲。在解密階段，F(xiàn)N下載CT并進行預解密生成部分解密密文M′，然后發(fā)送給DU。

(4)數(shù)據(jù)擁有者：DO是希望將數(shù)據(jù)上傳至CS存儲的一方，本文主要是指資源有限的移動設備。DO利用訪問樹制定訪問策略將數(shù)據(jù)加密成密文，進而實現(xiàn)一對多的訪問控制。

(5)數(shù)據(jù)用戶：DU是希望訪問存儲在CS中數(shù)據(jù)的一方，也是指資源有限的移動設備。只有自身屬性滿足訪問策略的DU才能夠解密密文獲得數(shù)據(jù)。

3.2 方案構(gòu)造

本文所提方案的總體框架如圖3所示，包含4個階段，分別是系統(tǒng)建立階段、密鑰生成階段、數(shù)據(jù)加密階段和數(shù)據(jù)解密階段。所有階段都由多項式時間的算法來實現(xiàn)，下面對各個階段的算法實現(xiàn)進行詳細說明。算法中各變量的含義說明如表1所示。

共包含以下6個算法：

算法1Setup(1k,U)→(PK,MSK)/*該算法由TA執(zhí)行*/

Table 1 Variable definition

Figure 3 Total framework of the proposed scheme

輸入：系統(tǒng)安全參數(shù)1k和全局屬性集合U。

輸出：公共參數(shù)PK和主密鑰MSK。//PK是公開的，MSK由TA保存

Step1構(gòu)造雙線性群BG=(G1,G2,GT,p,e)，并計算e(g,h)。

Step2隨機選取α,r,s∈Zp，并計算gα，hi=hαi，ui=hαir，vi=hαis,i=1,2,…,n。

Step4生成主密鑰MSK={g,α,r,s}和公共參數(shù)PK={BG,e(g,h),gα,hi,ui,vi,H1,H2}。

算法2KeyGen(PK,MSK,A)→(FKA,UKA)//該算法由TA執(zhí)行

輸入：公共參數(shù)PK、主密鑰MSK和用戶屬性集合A。

輸出：霧節(jié)點密鑰FKA和用戶密鑰UKA。

Step2選取2個隨機數(shù)k1,σ∈Zp，計算可得k2=(1/f(α,A)-k1s)/r。

Step3生成霧節(jié)點密鑰FKA={gk1/σ,gk2/σ}和用戶密鑰UKA=σ。

算法3Encrypt.Fog(PK,T)→CT′/*該算法由FN執(zhí)行*/

輸入：公共參數(shù)PK和訪問樹T。

輸出：部分加密密文CT′。

Step1設T由m個子樹構(gòu)成，將T轉(zhuǎn)換為T1=b11b12…b1n,…,Tm=bm1bm2…bmn。

Step3計算U′1=hrf(α,T1,…,U′m=hrf(α,Tm)和V′1=hsf(α,T1,…,V′m=hsf(α,Tm)。

Step4生成部分密文CT′，然后FN將其發(fā)送給DO。

算法4Encrypt.DO(PK,M,CT′)→CT//該算法由DO執(zhí)行

輸入：公共參數(shù)PK，待加密的明文消息M和部分密文CT′。

輸出：密文CT。

Step1隨機選取β∈Zp，并計算以下參數(shù):R,U1,…,Um,V1,…,Vm,C1,C2。

R=(gα)β=gαβ,

U1=U′β1=hrf(α,T1)β,…,Um=U′βm=hrf(α,Tm)β，

V1=V′β1=hsf(α,T1)β,…,Vm=V′βm=hsf(α,Tm)β，

C1=e(g,h)β·M，C2=H2(e(g,h)β)⊕M

Step2生成密文CT，CT={T1,…,Tm,U1,…,Um,V1,…,Vm,R,C1,C2},并將其發(fā)送至CS。

算法5Decrypt.Fog(PK,CT,FKA)→M′//該算法由FN執(zhí)行

輸入:公共參數(shù)PK、密文CT和霧節(jié)點密鑰FKA。

輸出:部分解密密文M′或⊥。

Step1若用戶屬性集合A與訪問樹T中的子樹都不匹配就直接中止，輸出⊥；否則計算A與T中所有子樹間的漢明距離d1,…,dm，并選取最小漢明距離dmin對應的子樹繼續(xù)后續(xù)步驟。

Step3計算X,Y,Z,W的值:

X=e(gk2/σ,Uj)=e(g,h)rf(α,Tj)βk2/σ,

Y=e(gk1/σ,Vj)=e(g,h)sf(α,Tj)βk1/σ,

W=X·Y=e(g,h)βF(α)/σ

Step4生成部分解密密文M′，M′={F0,Z,W,C1,C2},然后FN將其發(fā)送給DU。

算法6Decrypt.DU(PK,M′,UKA)→M//該算法由DU執(zhí)行

輸入：公共參數(shù)PK、部分解密密文M′和用戶密鑰UKA。

輸出：明文M或⊥。

4 安全性證明

在上述安全模型中，基于aMSE-DDH難題，采用反證法對本文所提方案的安全性進行證明。

假設存在一個攻擊者A能以(τ,qs,qd,ε)的優(yōu)勢攻破本文方案安全性，則可以構(gòu)造一個算法B以至少(τ′,ε′)的優(yōu)勢解決aMSE-DDH難題。A與B之間的交互如下所示：

(1)初始化：A將樹T*發(fā)送給B，假設T*=Tj=bj1bj2…bjn。

A可以查詢隨機模型H1和H2的值。B通過列表LH1和LH2分別存儲對H1和H2的查詢與返回的結(jié)果。若本次查詢已有先前的回應且輸出結(jié)果記錄在列表中，則B返回該結(jié)果。當面臨新的查詢時，B采取如下措施：

①查詢H1(i)的值。T*=bj1bj2…bjn，當bji=0時，B選擇g(x)的一個新根值返回給A；當bji=1時，B選擇f(x)的一個新根值返回給A(i∈[1,n])。

②查詢H2(ti)的值，B隨機選擇Qi∈{0,1}lM返回給A。

對于解密結(jié)果Encrypt[Ti,Mi]→CTi的查詢。若本次查詢出現(xiàn)在查詢列表中，B輸出相應的結(jié)果Mi，否則輸出⊥。

(4)挑戰(zhàn)：如果所有被查詢的密鑰都不能滿足T*，則A輸出挑戰(zhàn)消息(M0,M1)。B隨機選取b∈{0,1}，使用T*對消息Mb進行加密，生成挑戰(zhàn)密文CT*的步驟如下所示：

(5)查詢階段2：A重復查詢階段1的操作。限制條件是：

①沒有密鑰查詢滿足挑戰(zhàn)的訪問結(jié)構(gòu)。

②對于挑戰(zhàn)的密文沒有解密查詢。

(6)猜測：A輸出一個猜測b′∈{0,1}。若A已經(jīng)查詢過H2(S)的值，B輸出1;否則B輸出0，S是GT上的一個隨機數(shù)。

在猜測階段，若A能以優(yōu)勢ε獲勝，則S=e(g,h)β至少以ε+1/2優(yōu)勢存在于LH2中。只要S不存在LH2中,S就僅是一個隨機數(shù)，因此，S至多以qH2/p優(yōu)勢存在于LH2中，故B能夠以至少ε-qH2/p的優(yōu)勢分辨S是GT上的一個隨機數(shù)或者S=e(g0,h0)γf(α)。因此,本方案具有selective-IND-CCA安全。

5 性能評估

5.1 理論分析

5.1.1 功能比較

相關(guān)方案的功能比較如表2所示。

Table 2 Comparison of function

文獻[12]方案實現(xiàn)了密鑰定長，但密文長度并未固定，仍隨著屬性數(shù)量成倍增長，在具有海量用戶的應用場景中，會帶來巨大的密文存儲負擔，且該方案無任何計算外包能力，策略表達能力也相對較弱。文獻[13]方案與文獻[12]方案相比，實現(xiàn)了密文定長，但仍僅支持(n,n)門限訪問，策略表達相對單一，難以構(gòu)造靈活的訪問策略，且在計算效率方面也無任何提升。文獻[19]方案在文獻[12]方案的基礎上，增強了策略表達能力，使方案能夠?qū)崿F(xiàn)“與”門、“或”門和“門限”3種訪問策略，并將部分解密計算外包給云服務器。但是，鑒于云服務器現(xiàn)存的計算過于集中等問題，在處理大量外包計算任務時，系統(tǒng)效率相對較低，且該方案并不支持加密外包，也沒有固定密文的長度。

上述方案均不適用于霧計算環(huán)境，文獻[22]方案實現(xiàn)了霧環(huán)境中的加解密計算外包且支持(t,n)門限訪問，但密鑰與密文長度不能固定，隨著屬性數(shù)量的增加，造成了較大的存儲負擔。而本文所提方案實現(xiàn)了霧環(huán)境中的加解密部分外包，具有定長的密鑰與密文，且支持較為靈活的策略表達。

5.1.2 存儲成本比較

相關(guān)方案的存儲成本比較如表3所示。

Table 3 Comparison of storage cost

對于密鑰而言，文獻[22]方案中用戶密鑰的長度與用戶的屬性數(shù)量呈線性正相關(guān)，并不適用于資源有限的物聯(lián)網(wǎng)設備。文獻[12,13,19]方案與本文方案實現(xiàn)了密鑰長度恒定，但本文方案的密鑰存儲成本最小，僅為一個群元素的大小。

對于密文而言，文獻[12,19]方案密文長度與全局屬性數(shù)量呈線性正相關(guān)。文獻[22]方案密文長度隨訪問策略中的屬性數(shù)量線性增長。文獻[13]方案與本文方案中密文長度與屬性數(shù)量無關(guān)，但文獻[13]方案僅支持(n,n)門限訪問。當m=1時，本文方案與文獻[13]方案中的訪問策略相同，即僅支持(n,n)門限訪問。而當m≠1時，本文方案支持(t,n)門限訪問，如果文獻[13]方案想要實現(xiàn)與本文方案相同的策略表達，那么文獻[13]方案需要進行m次加密操作，密文長度等于3m|G|,大于本文方案。為了便于理解，此處舉例進行說明：假設制定如圖1的訪問策略，該策略可以轉(zhuǎn)換為6個僅支持“與”門的訪問策略。此時文獻[13]方案需要進行6次加密運算，密文存儲成本為3|G|·6=18|G|，而本文方案的密文存儲成本為(2·6+1)|G|=13|G|。因此，本文方案在密文存儲成本方面也優(yōu)于其他方案。

5.1.3 計算復雜度比較

相關(guān)方案中客戶端在加解密時的計算復雜度比較如表4所示。

Table 4 Comparison of computational complexity

通過上述對相關(guān)方案的比較與分析可以發(fā)現(xiàn)，本文方案的存儲成本與計算開銷均獨立于屬性數(shù)量，綜合性能更優(yōu)，適用于資源有限的物聯(lián)網(wǎng)設備。

5.2 實驗分析

為了驗證方案的有效性，本文通過實驗仿真將相關(guān)方案的客戶端加解密時間進行比較。以Java Paring-Based Cryptography library為基礎，選取超奇異曲線y2=x3+x在512-bit有限域上的160-bit橢圓曲線群，實現(xiàn)了相同的訪問控制策略，達到了80-bit安全級別。由于客戶端的智能移動設備種類較多，本節(jié)對相關(guān)方案在筆記本電腦和智能手機2種設備上的性能表現(xiàn)進行評估。電腦的實驗環(huán)境采用Windows 10操作系統(tǒng)，Eclipse IDE，Intel Core i7-4720HQ處理器，12 GB RAM；手機的實驗環(huán)境采用Android 10操作系統(tǒng)，Android IDE，Kirin 980處理器，8 GB RAM。所有實驗數(shù)據(jù)均為50次模擬取平均值，實驗結(jié)果如圖4～圖7所示。

在圖4和圖5中，隨著系統(tǒng)設置的屬性數(shù)量增加，文獻[12,13,19]方案數(shù)據(jù)擁有者加密所消耗的時間都線性增加，而文獻[22]方案與本文方案中的時間開銷都幾乎為一個定值。在本文方案中數(shù)據(jù)擁有者只需完成2m+1次指數(shù)運算、1次乘法運算和1次異或運算，這些計算均與屬性數(shù)量無關(guān)，加密過程中與訪問策略相關(guān)的大量復雜計算都已經(jīng)轉(zhuǎn)載到了霧節(jié)點，數(shù)據(jù)擁有者只需要完成剩余的少量計算即可，大幅度降低了數(shù)據(jù)擁有者的計算開銷。

Figure 4 Time of personal computer encryption

Figure 5 Time of mobile phone encryption

在圖6和圖7中，文獻[12,13]方案的用戶解密時間均與系統(tǒng)設置的屬性數(shù)量呈線性正相關(guān)。而本文方案與文獻[19,22]方案實現(xiàn)了解密外包服務，時間開銷幾乎保持不變，但本文方案與文獻[19]方案在電腦和手機上的解密效率最高。這是因為解密過程中多項式函數(shù)的生成與復雜的雙線性配對等操作都已經(jīng)外包給了霧節(jié)點，用戶只需進行2次指數(shù)運算、3次除法運算和1次異或運算，即可解密并完成驗證，大大減輕了用戶的計算負擔。當屬性數(shù)量增長到150個時，文獻[13]方案在手機上的解密時間接近1.5 s，而本文方案仍為10 ms左右，因此本文方案適用于具有海量用戶的應用場景。

Figure 6 Time of personal computer decryption

Figure 7 Time of mobile phone decryption

6 結(jié)束語

本文針對目前屬性加密方案中客戶端存儲與計算成本較高的問題，基于霧計算平臺提出了一種支持計算外包的微型訪問控制方案。首先，本文方案中密鑰與密文定長，加解密計算外包，減輕了終端設備的開銷。其次，數(shù)據(jù)擁有者定制了個性化的訪問策略，本文方案能夠為用戶提供高效的數(shù)據(jù)共享。再次，用戶通過簡單的哈希與異或運算就能夠檢驗外包解密結(jié)果正確與否。最后，經(jīng)證明本文方案具有selective-IND-CCA安全，即使霧節(jié)點與云服務器不可信，也能夠保障數(shù)據(jù)的隱私安全。但是，目前本文方案并未考慮到用戶與屬性撤銷的問題，而用戶與屬性通常是多對多的關(guān)系，復雜度較高，如何構(gòu)造一個高效的撤銷機制是接下來應研究的問題。