云計算中基于屬性的分層密鑰交換協議

邵藝雯 趙一鳴

(復旦大學軟件學院 上海 201203)

0 引 言

隨著信息時代數據的飛速增長，數據共享越來越成為人們生活中不可或缺的部分，云服務器則是實現數據共享最重要的應用平臺。因為云服務器不完全受信任，所以需要加密和訪問控制[1-3]來保護數據安全性和隱私性。

2012年Xu等[4]提出了基于屬性的加密在云服務器上實現細粒度文件共享的方案，將基于屬性的加密和分層加密密鑰管理相結合，對不同安全等級的用戶生成相應等級的密鑰，從而使得用戶可以根據不同優先級解密密文，但該方案不具備可投射性等特征。

2016年Vladimir等[5]提出了對通用策略的基于屬性密鑰交換(后文簡稱ABKE)，通過將基于屬性的證書[6-10]和基于屬性的加密[11-14]相結合，主要目標為：在服務器和客戶端之間通過交互的方式，只有當客戶端的屬性集滿足服務器的訪問策略時，兩者才能建立共享密鑰。該方案具有屬性隱私、抗碰撞等優點。但該方案不具備細粒度的特征，因此不支持云環境中不同優先級的分層訪問特征。

隨著海量數據的分權限訪問在云環境中越來越重要，滿足細粒度、抗碰撞、屬性隱私等特征的文件共享具備非常廣泛的應用場景。以云環境中的個人健康記錄(PHR)為例，患者數據的安全等級不同，主治醫生和醫學研究者訪問權限也不同。假設患者的信息包括私人信息和醫療記錄兩部分，私人信息安全等級較高，而醫療記錄等級較低。通過基于屬性的分層密鑰交換，主治醫生可以獲取高安全等級密鑰,從而同時解密私人信息和醫療記錄，而醫學研究者只能獲取較低安全等級密鑰，解密部分數據，即醫療記錄。在這樣的實際應用場景中，不僅要保證數據的有效獲取并用于醫學治療與研究，也要最大程度地保證患者的隱私信息。類似的，在軍事機構以及大小型企業數據共享系統等一系列應用場景中，當不同用戶具有不同優先級時，上傳到云環境中的加密數據也需要實現分層的文件共享效果。

為了在云環境中同時實現細粒度的數據訪問、屬性隱私、可投射性以及不可鏈接的性質，本文在Xu和Vladimir兩者的基礎上，提出基于屬性的分層密鑰交換協議(后文簡稱為H-ABKE)。通過更改基于屬性的密鑰交換，結合單向函數鏈，用于云計算中細粒度的文件共享，并使其同時滿足分層、屬性隱私、抗碰撞及不可鏈接的優點。

本文的主要貢獻在于將基于屬性的密鑰交換與分層密鑰管理結合，引入單向函數鏈[4]與循環算法，提出了云環境中基于屬性的分層密鑰交換協議。

1 預備知識

1.1 亂碼電路

亂碼電路[5]是基于屬性的密鑰交換主要構件之一。定義一個可驗證的亂碼機制[15-17]，由一系列函數元組構成：G=(Gb,Ev,Ve)。

評估算法Ev(GC,{Xj}j∈[m])：一個確定性算法，用于計算當輸入線標簽為{Xj}j∈[m]時亂碼電路GC的值，也就是判斷該標簽是否滿足亂碼電路。

一個可驗證的亂碼機制必須滿足三個安全特性：

1) 正確性：一個正確的亂碼電路GC輸出結果必須與原始電路C的結果一致。

2) 真實性：評估者僅僅可以得到其輸入對應的值，除此以外不能得到任何其他的值。

3) 可證實性：檢驗亂碼電路GC是否真正實現了給定的明文電路。一旦驗證通過，即Ve的結果為接受，那么該亂碼電路就不可能再產生錯誤值。

1.2 屬性選擇加密

在屬性選擇加密[5](下文簡稱為ASE)中，明文由消息組合構成，客戶端的屬性決定能夠被解密的子集。這就確保了數據使用者只能解密出自己對應的屬性集合。每個客戶端擁有一個m位的向量χ∈{0,1}m，其中χ[j]=1，當且僅當其擁有第j個屬性。任何人可以基于其公鑰對2m個消息進行解密：

客戶端只能對x1,χ[1],x2,χ[2],…,xm,χ[m]解密成功。在ASE中，n表示安全參數，m表示屬性向量的長度，客戶端收到對應公鑰，一個ASE機制由概率多項式時間算法元組構成：

初始化Setup(1n,m)：以屬性集大小m和安全參數n為輸入，輸出為主驗證密鑰和主私鑰(mVK,mSK)，以及公共參數PP。

密鑰生成GenCert(mSK,χ)：輸入為主私鑰mSK和屬性向量χ，輸出與屬性集對應的、經驗證的密鑰對(pkχ,skχ)。

驗證Vrfy(mVK,pkχ)：以主驗證密鑰mVK和公鑰pkχ為輸入，當且僅當pkχ是有效的公鑰時，該算法輸出1，否則為0。

加密Enc(pkχ，x)：以公鑰pkχ和向量x為輸入，該算法輸出為密文c。其中，x是大小為的消息集合，形式如下：

解密Dec(skχ,c)：輸入為私鑰skχ和密文c，輸出基于屬性集χ的m個明文。

1.3 單向函數鏈

本文使用單向函數鏈來實現分層的性質[4]。假設加密哈希函數H:{0,1}*→{0,1}ρ，那么單向函數鏈可定義為：

Keyi=H(Keyi-1)i∈[1,n-1]

單向函數鏈可以構造分層密鑰結構。在已知Keyi-1的條件下，密鑰Keyi可以通過計算Keyi-1的哈希值生成。較高安全等級的密鑰可以生成較低安全等級密鑰，反之則不然。同時，定義安全等級SC={yi|i∈[0,n-1]}。用戶可以根據其密鑰Keyi對安全等級為yi及以下的數據內容進行解密。

1.4 輔助函數

1)Fcom函數[17]：運行commitment協議，主要內容如下：發送者輸入為(commit,sid,i,m)，若沒有格式為(sid,i,m)的消息被存儲，那么存儲(sid,i,m)并發送(committed,sid,i,|m|)給接收者。當發送者輸入為(reveal,sid,i)時，如果格式為(sid,i,m)的消息被存儲，那么發送(reveal,sid,i,m)給接收者，函數終止。

2)Ftosscoin函數[5]：生成隨機密鑰，當輸入為(toss,sid)時，若格式為(sid)的消息未存儲，那么存儲(sid)，否則選取r←{0,1}n，并發送(tossed,sid,r)。

3)Fsetup函數[5]：為系統中的參與方Pi生成密鑰對。在長度參數m初始化之后，Fsetup函數運行算法(PP,mVK,mSK)←Setup(1n,m)，存儲(mVK,mSK)：一旦收到Pi發的(generate,sid,Xi)，Fsetup驗證是否有(i,Xi)格式的消息存儲記錄，若存在記錄，發送(result,sid,⊥)給Pi；若該記錄不存在，則運行(pkχ,skχ)←GenCert(mSK,Xi)算法，存儲(i,Xi)并發送(result,sid,mVK,pkχ,skχ)給參與方Pi。

2 基于屬性的分層密鑰交換協議

2.1 基本思路

為了在云環境中實現細粒度、屬性隱私、抗碰撞、不可鏈接以及可投射性等特征，本文提出了基于屬性的分層密鑰交換協議。協議整體框架為數據擁有者將不同安全等級的數據分別根據相應密鑰進行加密后上傳到服務器，只有當數據訪問者的屬性集合滿足擁有者某一等級的訪問策略時，才能滿足密鑰交換的條件，從而對該安全等級及以下等級的數據內容進行解密。以云環境中細粒度的PHR數據共享為例，假設數據M包括兩部分，分別為:

私人信息m0：包括患者姓名、年齡、住址、聯系電話等，安全等級為y0。

醫療記錄m1：包括醫療檢查結果、治療方案以及治療記錄等，安全等級為y1。

主治醫生需要同時訪問m0和m1來進行診斷，而醫學研究者為了相關領域研究目的僅需要獲取數據m1。訪問策略為T0={“醫學研究者”AND“主治醫生”}，T1= {“醫學研究者”}。其中，主治醫生一定是醫學研究者，反之則不然。為了保證數據M在云環境中安全地進行共享，私人信息和醫療記錄將分別根據密鑰Key0與Key1進行加密，通過H-ABKE中的分層密鑰交換，用戶根據其屬性集獲取對應等級密鑰。主治醫生的屬性集滿足訪問策略T0，將獲取對應密鑰Key0，并通過單向函數鏈獲取Key1，從而對私人信息m0和醫療記錄m1解密。而醫學研究者僅滿足訪問策略T1，獲取對應密鑰Key1，解密醫療記錄m1。

H-ABKE基本框架如圖1所示。

圖1 H-ABKE框架

此外，H-ABKE通過單向函數鏈和密鑰管理機制來體現分層的特征，實現細粒度的文件訪問。單向函數鏈作用在于實現細粒度的訪問控制。圖2是分層訪問策略[18]與單向函數鏈的一個實例：分層訪問結構T包括三個子訪問策略，由高到低分別為T0-T1-T2，對應安全等級為y0-y1-y2，密鑰為Key0-Key1-Key2，若用戶屬性集滿足T0，則可以獲取密鑰Key0，進而通過單向函數生成Key1和Key2；若用戶僅擁有Attr c，只滿足訪問策略T2，獲取密鑰Key2。

圖2 分層訪問策略與單向函數鏈

H-ABKE協議的實現思路為將基于屬性的密鑰交換運用于云環境的數據共享中，在數據擁有者和訪問者之間以一種交互的方式實現屬性隱私、抗碰撞、不可鏈接以及抗碰撞等性質。為了保護屬性隱私，數據擁有者需要將訪問策略發送給訪問者進行計算，ASE確保了訪問者解密得到的明文，即加密電路的輸入線標簽，要與其屬性集相匹配。

數據擁有者基于Key={Key0,Key1,Key2}對文件進行加密，數據訪問者則根據其相應屬性集合分別對訪問策略T的一部分或整個進行解密。如用戶1的屬性{Attra,b,c}滿足整個訪問策略，則可以獲取密鑰Key0，進而通過單向函數鏈獲取Key1和Key2。

本文系統中有四個角色，整體模型如下：

1) 數據擁有者：為了保護數據隱私，需要在上傳數據到云服務器之前對其進行加密，使得只有滿足數據擁有者訪問策略的用戶才可以對其進行解密，從而實現訪問控制。此外，數據擁有者確定數據訪問策略，并可以對其不斷更新。

2) 數據使用者：從云服務中獲取文件，但只有滿足擁有者訪問策略的情況下才能進行解密。同時，不管是否在授權范圍內，用戶都會試圖盡可能訪問更多數據內容。惡意用戶可能會串通，通過共享私人信息來試圖解密其授權以外的數據。

3) 授權中心：負責將屬性和密鑰分發給用戶，是一個受信任的機構。

4) 云服務提供商：運行大量連接的服務器，具有強大的運算能力和存儲能力，為用戶提供各項服務。但同時也會對數據內容產生好奇，是一個半信任機構。此外，本文假設所有用戶和服務器間的交流信道是安全的，如SSL。

在H-ABKE中，數據擁有者確定訪問策略，并將加密后的密文上傳到云服務器，數據訪問者獲取文件，但只有滿足某一安全等級的用戶才能對該安全等級以及較低等級的密文進行解密。

方案整體流程為系統初始化、新用戶授權、創建文件、基于屬性的分層密鑰交換、文件解密。

2.2 方案構造

方案流程如圖3所示。

圖3 H-ABKE流程

2.2.1 系統初始化

授權中心AC運行初始化算法Setup(1n,m)，以屬性集大小m和安全參數n為輸入，輸出為主驗證密鑰和主私鑰(mVK,mSK)，以及公共參數PP。

2.2.2 新用戶授權

在系統初始化之后，新用戶被賦予屬性集S，運行Fsetup算法，通過調用其中的GenCert(mSK,χ)生成該用戶的公鑰和私鑰。

2.2.3 新文件創建

用戶可以創建新文件并通過與授權中心交互對文件進行加密，隨后將密文上傳到云服務器。

1) 加密過程如下所示：根據安全等級SC，數據擁有者通過Ftosscoin函數生成最高安全等級密鑰Key0，隨后依據單向函數鏈Keyi=H(Keyi-1)，進一步生成單向分層密鑰鏈Key1,Key2,…,Keyn-1。

2) 需要上傳到云服務器上共享的數據將通過不同等級的對稱密鑰加密。安全等級為yi的數據將根據密鑰Keyi加密，對應的密文格式為{Datai}Keyi。之后數據擁有者將密文上傳到云服務器，并發送(commit1,sid,{Key0,Key1,…,Keyn-1})給授權中心AC。

2.2.4 基于屬性的分層密鑰交換

分層密鑰交換核心算法具體流程如下：

1) 數據擁有者公布一個分層的訪問策略(policy circuit)，授權中心AC檢查該訪問策略是否合法，若合法廣播給數據使用者，否則終止。

6) 數據使用者發送(commit2,sid,1,Z)給Fcom，Fcom發送(committed2,sid,1,|Z|)給數據擁有者。

8) 數據擁有者檢驗是否Z=1，若相等，發送(reveal1,sid,Keyi)給Fcom，Fcom發送給數據使用者對應其安全等級的文件加密密鑰Keyi，算法結束。否則i=i+1，返回步驟3進行下一次循環，直到滿足某一層訪問策略Ti，或i=n-1為止。

分層密鑰交換核心算法如下所示：

(pk',sk')←Unlink(pk,sk)if(?Vrfy(mVK,pk'?)= 1){ //for each access policy from higher security to lower for(int i = 0; i < n ; i++){ (GC,{X0j,X1j}j∈[m],{Z0,Z1})←Gb(1n,C) x={X0j,X1j}j∈[m] c←Enc(pk',x) Z←Ev(GC,{Xχj[i]i}i∈[m]) (commit2,sid,1,Z) //Owner sends label and r to user and user verify if(Ve(C,GC,{X0i,X1i}i?∈?[m])= reject){ quit }else { (reveal2,sid,1,Z) } if(Z=1){ (reveal1,sid,Keyi) } }}

2.2.5 文件解密

在密鑰交換之后，數據訪問者可以通過Keyi解密從而訪問共享文件。根據密鑰間的分層關系，該用戶可以生成所有較低等級的密鑰。假設訪問策略有三種安全等級，單向密鑰鏈為Key0-Key1-Key2，三種等級代表公司中的老板、部門經理、普通員工，那么部門經理在密鑰交換后獲取對應密鑰Key1，再根據哈希函數獲得密鑰Key2，進而對安全等級為y1和y2的文件進行解密。

3 安全性和效率分析

在云環境中實現細粒度的文件共享需要滿足以下安全性指標：

1) 屬性隱私：數據使用者的屬性永遠不會被暴露。唯一被了解到的信息就是該用戶的屬性集合是否滿足訪問策略，從而確定是否進行密鑰交換。除此之外，用戶屬性不會泄露。

2) 不可鏈接：對同一用戶來說，與其他用戶的交互不會鏈接到一起。

3) 抗碰撞：對敵手來說，給定某些用戶的不同屬性集，在其中任一用戶都不能滿足訪問策略的情況下，該敵手在概率多項式時間內也不能滿足該訪問策略。

4) 可投射性：用戶可以將自己屬性集中存在的某些屬性授權給其他用戶。

5) 細粒度：如果一個用戶有第i層的安全等級，那么他只能得到當前等級的密鑰，不能通過共享私人信息來獲取更高層密鑰。

以下將對本文的H-ABKE方案滿足以上五個特征進行證明：

定理1H-ABKE滿足屬性隱私、不可鏈接、可投射和抗碰撞的性質。

證明：Vladimir等人提出的基于屬性密鑰交換滿足以上性質，下面將證明H-ABKE與其安全強度相同，因此H-ABKE也滿足以上四個性質。

本文在基于屬性的密鑰交換基礎上，引入的額外因素為哈希函數和安全等級，以及針對分層訪問策略的從上到下循環算法，單向函數鏈和安全等級的具體內容分別如下所示：

Keyi=H(Keyi-1)i∈[1,n-1]

SC={yi|i∈[0,n-1]}

這些算法實現了分層密鑰交換的功能，與用戶屬性集沒有關聯，不會暴露任何與用戶有關的屬性，也不會對方案安全性造成影響，因此該方案與ABKE方案安全性相同。

定理2H-ABKE滿足細粒度的文件共享性質。

證明：為了保證數據擁有者的隱私性，不暴露其屬性，方案引入了ASE，使得數據擁有者在不知道訪問者屬性的情況下，將加密后的電路發送給使用者，讓其自行計算屬性集是否滿足訪問策略。這保證了數據使用者的隱私性，同時為了防止惡意訪問，ASE的加密算法中，Enc(pkχ,x)以公鑰pkχ和向量x為輸入，該算法輸出密文c。

因為每個用戶的公鑰pkχ不同，所以面對惡意用戶合謀攻擊時，解密算法Dec(skχ,c)中僅能解密出每對密文中的一個，即大小為2m的密文最終解密m個。

因此本方案具有抗碰撞的特征，數據擁有者通過訪問者的公鑰進行加密，不同用戶的公鑰不同，無法對密文進行解密。即使惡意用戶共享屬性信息，H-ABKE也會將其限制在當前等級。根據循環算法及密鑰鏈的單向性，用戶僅能生成較低安全等級的密鑰。

在效率方面，因為要實現分層的特征，所以引入了循環算法。對每個數據使用者來說，循環算法都將從最高等級的訪問策略開始，逐層判斷該用戶屬性集是否滿足該層策略，若滿足則獲取當前密鑰，算法終止，否則將繼續循環直到最后一層策略，或滿足某一層策略為止。這使得H-ABKE方案比原有ABKE效率要低，但要在ABKE基礎上實現分層的性質，該算法是必要的折衷。同時，加密電路的使用以及云環境中強大的計算能力，也使得H-ABKE方案的效率大大提升。除此之外，通過使用線下的隨機化以及批量驗證，也會很大程度降低線上工作量，從而進一步提高方案效率。

4 結 語

本文的主要貢獻在于將基于屬性的密鑰交換與單向函數鏈相結合，實現一種新的H-ABKE方案，使得ABKE在原有基礎上實現了分層的特性，從而在云環境中對不同安全等級的數據內容實現了細粒度的訪問控制。屬性選擇加密實現了屬性隱私、抗碰撞、不可鏈接、隱私性和可投射性，確保數據使用者對亂碼電路的計算結果正確有效。亂碼電路的主要優勢在于支持任意復雜的訪問策略，且非常高效。

未來該方案可針對私有訪問策略、證書撤回、多授權中心碰撞等方面展開進一步研究。