基于密鑰狀態散列樹的密鑰存儲管理方案

王祥宇，馬建峰，苗銀賓，張凱，伍祈應

（西安電子科技大學網絡與信息安全學院，陜西 西安 710071）

1 引言

隨著云計算和大數據時代的到來，越來越多的云租戶將數據外包到云服務器以減輕本地數據的存儲和計算開銷[1]。同時，為了解決數據機密性和可檢索性之間的矛盾，密文檢索技術[2,3]受到產業界和學術界的廣泛關注。

由于數據的多源性（云數據來自多個數據擁有者），密文檢索系統中不同的數據塊通常采用不同的密鑰進行加密以保障數據安全。然而海量云數據的加密存儲會帶來巨大的密鑰存儲管理問題。一方面，對海量數據進行加密會產生大量的密鑰，這些密鑰也會占用大量的存儲空間，降低密鑰存儲開銷對云密文檢索系統是一個巨大挑戰。另一方面，由于加密每個文件使用的密鑰不一樣，在使用過程中，解密者如何在大量密鑰中快速調用相應的數據解密密鑰也是一個重要問題。

目前，已經有了一些相對成熟的密鑰管理系統。其中，單層派生關系（SDE, single-layer derivation equation）方案根據訪問權限對用戶進行分類并生成不同的密鑰派生樹，每種派生樹對應一個用戶掌管的密鑰合集，通過密鑰派生的方法來避免用戶存儲大量的加密密鑰[4～6]。但是SDE方案只是在單授權者情況下減少了需要管理的密鑰的數量，當授權者數量增加時，每個用戶掌管的密鑰也會增加，特別是當授權者數量很龐大時會產生海量密鑰。建立在 SDE方案基礎上的雙層派生關系（DDE, double-layer derivation equation）方案縮減了權限控制更新時的成本消耗[7,8]，但該方案的缺陷與 SDE方案類似，都是在授權者數量很龐大的時候，無法有效減小用戶掌管密鑰的數量。

目前，在國內外安全研究領域中，許多方面都使用到了密鑰派生的相關概念。除了上面提到的SDE與DDE方案中用到了密鑰派生的思想，還有一些使用到了密鑰樹思想的研究方案[9～12]。

樹是非線性的數據結構，由一個集合以及在該集合上定義的一種關系構成。集合中的元素稱為樹的節點，所定義的關系稱為父子關系。父子關系在樹的節點之間建立了一個層次結構。在這種層次結構中有一個節點具有特殊的地位，這個節點稱為該樹的根節點，或稱為樹根。樹的這種結構特點能夠將多個節點信息集中于某個節點上。如圖1所示，通過將密鑰映射到樹的節點，建立密鑰派生樹，就能夠實現將多個密鑰信息集中于單個節點密鑰上，大大降低密鑰存儲管理開銷。

圖1 密鑰派生樹結構示意

文獻[13,14]在基于狀態密鑰樹的安全群組密鑰分發協議研究中提出了狀態密鑰樹的思想，該方法通過數學公式的計算來推導密鑰派生樹，減少了系統密鑰的存儲開銷，但該方案會引入較大的計算開銷。文獻[15]針對高性能計算集群（HPC, high performance computing cluster）系統文件加密提出的Horus方案也使用密鑰樹進行密鑰管理，大大減少了密鑰的計算和存儲開銷。然而，隨著密鑰撤銷次數的增加，此方案的密鑰派生樹的結構會向線性改變，密鑰存儲和管理開銷會越來越大。

針對以上問題，本文提出了一種基于密鑰狀態散列樹的密鑰存儲管理方案。該方案使用密鑰狀態散列樹結構進行密鑰派生，可以在不引入額外計算開銷的前提下大大降低密鑰存儲開銷。與此同時，與 Horus方案相比，所提方案解決了由于密鑰撤銷帶來密鑰派生樹結構改變而增大密鑰存儲管理開銷的難題。表1顯示了在密鑰撤銷情況下本文所提方案與Horus方案的密鑰樹情況對比，可以看到，本文所提方案的密鑰樹結構和數量不隨密鑰撤銷而變化，因此，密鑰存儲開銷不變，與Horus方案相比可以保證良好的性能。

表1 密鑰撤銷情況下方案對比

2 技術架構與安全威脅分析

本節分別介紹了所提密鑰存儲管理方案的技術架構以及安全威脅。

2.1 技術架構

本文密鑰存儲管理方案的技術架構如圖 2所示，系統分為3個部分：用戶、私有云和公有云。

圖2 技術架構

系統流程如下所示。

1) 用戶將自己的明文數據發送到私有云。

2) 私有云根據明文數據建立安全索引并加密數據上傳到公有云進行存儲。

3) 需要某一類數據時，用戶向私有云發送明文搜索請求。

4) 私有云將其轉換為搜索陷門后發送到公有云。

5) 公有云根據陷門和索引搜索到相應的密文結果返回給私有云。

6) 私有云對數據進行解密，將明文結果返回給用戶。

在這個架構中，私有云用來分擔用戶在文件加密和搜索過程中的計算開銷；公有云用來存儲加密的數據并提供密文搜索服務，這符合一般的可搜索加密系統。私有云一般為高性能計算集群（HPC），以OpenStack為例，集群中包含控制節點、網絡節點、存儲節點和許多計算節點。

為了使云端無法獲得除搜索模式外的任何與原始數據相關的數據，用戶必須自己管理加密密鑰。密鑰分配過程在私有云中完成。方案采用了經典的客戶端—服務器模型，客戶端向密鑰分配服務器（KDS, key distribution server）請求密鑰，并使用 KDS返回的密鑰進行數據加密、解密。客戶端運行在私有云當中的計算節點上，直接與用戶進行交互；KDS可以運行在私有云的控制節點或其他計算節點。當密鑰需求大時，也可以單獨地設置密鑰分發中心（KDC, key distribution center）。本文中的KDS運行在控制節點上，客戶端運行在計算節點上，KDC由其他計算節點組成。

2.2 安全威脅假設

所提方案對安全威脅做出了以下假設。

1) 攻擊者可能獲得公有云存儲的密文數據。惡意的云服務提供商可能會嘗試解密用戶的數據；外部攻擊者可能攻破公有云服務器，獲得其中所有數據的訪問權。

2) 攻擊者可能攻破某一解密計算節點。通常可搜索加密系統會假設私有云是完全可信的。但是，對安全威脅做一個更強的假設，假設攻擊者（如惡意的用戶）可以入侵私有云的計算集群并控制某一客戶端，但是不能入侵所有客戶端，假設 KDS和網絡節點是安全的。這個假設在現實中是常見的，因為 HPC上運行的客戶端程序是直接與用戶進行交互的，給予用戶很大的操作權限，惡意的用戶可能利用客戶端進行非法操作。而網絡節點和控制節點掌管 HPC的控制和通信，通常由高權限的管理員進行管理，普通用戶沒有控制權限，很難攻破。

3 密鑰存儲管理方案設計

圖3展示了本文所提密鑰存儲管理系統的密鑰分配過程。文件的加密和解密過程全部由運行在私有云上的客戶端完成，分為文件加密上傳和文件下載解密2個部分。

圖3 系統密鑰分配過程

文件加密上傳過程如下。

1) KDS和用戶分別公開自己的公鑰KUKDS和KUA，將私鑰秘密保存。用戶選擇根密鑰Kr、密鑰狀態散列樹的深度d和分支數b以及訪問權限列表作為保險箱配置，將明文保險箱和文件發送給客戶端。

2) 客戶端將明文保險箱和密鑰請求發送給KDS。

3) KDS根據配置生成密鑰，返回給客戶端，如果達到性能瓶頸，則使用空閑計算節點生成 KDC進行密鑰分發。

4) 客戶端使用 KDS返回的密鑰加密對應文件，使用2個公鑰KUA和KUKDS分別加密保險箱，將加密的保險箱和文件發送到公有云進行存儲。

文件下載解密過程如下。

5) 客戶端收到加密的文件后，向KDS請求解密密鑰。

6) KDS向公有云請求對應文件的加密保險箱，使用自己的私鑰解密保險箱。

7) 根據保險箱中的權限列表判斷客戶端是否有得到密鑰的權限。沒有則終止，有則根據根密鑰Kr以及派生樹結構進行密鑰派生，將密鑰發送給客戶端。如果達到性能瓶頸，則使用空閑計算節點生成KDC進行密鑰分發。

8) 客戶端根據接收到的密鑰解密文件，發送給用戶。

本文將詳細介紹密鑰存儲管理過程中的密鑰計算過程、根密鑰的安全存儲機制及密鑰交換協議以及密鑰分發集群KDC的設計。

3.1 密鑰計算過程

本文設計的密鑰存儲管理系統采用帶密鑰的散列樹作為密鑰派生結構，如圖4所示。一個密鑰樹管理了大量的文件加密密鑰，它們的加密密鑰全部由根密鑰派生而來，低層次的密鑰控制更小范圍的文件。葉子節點的的值就是對單個文件塊的密鑰。同一層次上的密鑰控制的文件大小應該是相同的。為了盡量減少存儲開銷，每一層的分支數都是相同的。這樣，不需要存儲整個樹形結構，只需要存儲其層數和每個節點的葉子節點分支數即可推算整個樹的結構。

圖4 派生樹結構

3.1.1 密鑰派生過程

密鑰派生樹建立時，將密鑰狀態散列樹的根節點設置為根密鑰Kr，所有節點的狀態Sx,y均為 0，表示從未撤銷過。用父節點密鑰值和狀態值來計算出各子節點的密鑰值，即計算帶密鑰的散列樹中第x層中第y個節點對應的密鑰值為

其中，Kparent是K(x,y)的父節點對應的密鑰，其為已知密鑰，H()是 SHA-256摘要算法，|| 代表串聯運算，這里使用x||y是為了保證所有分塊密鑰互不相同，在Sx,y前增加“*”是為了避免直接串聯可能導致的2個密鑰相同問題。

例如，圖 4中的K2,3由K1,1計算得出，即以此類推，最終所有的分塊密鑰都可以由根密鑰Kr計算得出。

3.1.2 密鑰撤銷過程

當用戶對帶密鑰和狀態的散列樹中某些節點進行密鑰撤銷操作時，首先將對應節點的密鑰撤銷狀態值+1，表示這個節點進行過一次撤銷，并根據密鑰計算過程中的公式重新計算密鑰，作為文件加密密鑰，分配給新用戶，新用戶用這個密鑰加密自己的文件。而原有用戶的密鑰無法解密這些文件，保證了新用戶文件的安全。

在實際系統中，狀態值S的存儲數據類型存在數據溢出，當密鑰更新次數超過Sx,y的數域時，在計算式中的Sx,y前面多添加一個“*”，式(1)變為

并且令對應的Sx,y= 0。再次超過數域時，重復此過程，保證系統可以一直運行。

3.2 根密鑰的安全存儲機制及密鑰交換協議

本文使用保險箱（Lockboxes）保證了根密鑰的安全性以及使用時的高效性[16]。根密鑰是安全存儲在公有云中的，私有云只承擔密鑰派生的計算開銷，不需要承擔存儲開銷。在這個過程中，涉及根密鑰在公有云和私有云不同計算節點之間的分配。

為了滿足分配中的需求，本文為密鑰存儲管理系統設計了密鑰交換協議，協議符號含義如表2所示，密鑰交換協議如圖5所示。密鑰交換分為文件加密上傳以及文件下載解密這2個過程。當一個新的文件群f被建立時，進行如下步驟。1) 用戶新建明文保險箱 ＜Kr,BS,P0,P1… ＞作為文件群加密配置發送給客戶端。

表2 密鑰交換協議符號對照

圖5 密鑰交換協議

2) 客戶端首先將明文保險箱發送給 KDS并請求文件加密密鑰，然后使用KUA和KUKDS分別加密根密鑰，在完成加密之后將加密保險箱發送給公有云進行存儲。

3) KDS返回給客戶端進行文件加密。需要注意的是，在步驟2)中，如果KDS性能達到瓶頸，則把明文保險箱發送給新建的 KDC增加密鑰分發能力。

當一個私有云的客戶端計算節點Ci受到用戶的下載解密文件群f中的某一部分時，進行如下步驟。

4) KDS從公有云得到加密的保險箱

5) KDS通過＜P0,1P…＞判斷Ci是否擁有訪問權限。如果客戶端Ci被允許訪問，KDS使用自己的私鑰解密保險箱中的根密鑰由 KDS通過Kr和帶密鑰的散列樹配置BS來計算。如果需要，將明文保險箱發送給新建的KDC進行密鑰分發。

6) KDS返回密鑰給客戶端進行文件解密。

這個協議的主要優勢是KDS可以從本質上保持無狀態，因此可以獲得高并行性和安全性。需要注意的是，對于文件在密鑰樹中位置連續的情況，可以將權限內的密鑰樹中最高的節點密鑰以及密鑰樹結構發送給客戶端，客戶端自行進行密鑰派生，因為只進行一次通信，大大節省了通信開銷，稱之為快速方式。如圖 4中的密鑰樹結構，若客戶端同時請求K3,6和K3,7，則可以直接將K2,3發送給客戶端，由客戶端自行計算分塊密鑰。

3.3 密鑰分發集群KDC的設計

由于本文設計的密鑰存儲管理系統中，密鑰管理功能與其他系統中數據管理功能是不相關的，所以密鑰管理功能可以作為一組進程實現在一個或多個無狀態的計算節點上，構成一個密鑰分發中心。如果 KDC到達了瓶頸，可以通過添加更多的節點來進行擴展。為了實現密鑰派生，KDC必須得到保險箱內容并確定用戶訪問權限。

在文件加密上傳時，KDC可以直接從客戶端得到由文件擁有者提供的明文保險箱；在文件解密時，KDC可以從KDS獲得解密的保險箱。確定用戶的訪問權限的方法與之相似，可以通過保險箱中預先設定好的訪問權限控制列表。

4 方案安全性與性能分析

本節對所提方案的安全性進行分析，并對方案使用真實數據集在真實環境下進行了詳細的性能測試。

4.1 方案安全性分析

對于攻擊者竊取公有云中數據的這種情況，在本文所提方案中數據不會明文存儲在云端。因此，即使云服務器被攻破，也不能獲得明文數據。只有通過文件的加密密鑰解密文件，文件才是可讀的。但是，要想得到加密密鑰首先要得到根密鑰，而要想得到根密鑰必須首先解鎖保存密鑰的保險箱，保險箱只有通過合法用戶的私鑰才能打開[16]。

對于攻擊者控制某些客戶端計算節點這種情況。如前文所述，每個客戶端只有它們擁有訪問權限文件的密鑰。由于散列函數的單向性，客戶端無法得到這些密鑰的父密鑰，也就無法“擴展”相同級別的密鑰從而得到權限范圍之外的文件訪問能力。這種方法在擁有大量節點的大規模高性能計算集群里十分有效，每個節點可能只需要訪問整個文件群的 1%。如果系統中一個節點被攻破，入侵者就只獲得了一小塊數據[15]。

4.2 方案性能分析

本文所提密鑰管理方案使用C語言進行開發；密鑰交換協議利用Socket使用UDP來實現；使用OpenSSL中的 SHA-256散列函數作為密鑰派生的散列函數；為了滿足細粒度的文件加密，使用AES的 XTS模式來進行文件加密，源代碼同樣來自OpenSSL。XTS-AES是一種可調整分組密碼，非常適合對那些被分割成固定長度（具體長度不限）的數據單元進行加密[17]。

為了貼合實際使用環境，在OpenStack集群中對本文所提方案進行了測試。采用PC機來模擬客戶端，使用KVM虛擬機模擬私有云中的多個計算節點和公有云服務器。測試環境配置如表3所示，KVM虛擬機只顯示CPU的核數。

表3 測試環境配置

4.2.1 存儲開銷

存儲開銷分析如表 4所示。這里的傳統方案指的是逐個存儲加密密鑰的方案。從表4可以看出，相比于傳統的存儲方案，本文所提方案大大減小了密鑰存儲開銷。

表4 存儲開銷分析

本文以分支數為 2、4、6、8的散列樹為例，計算密鑰狀態散列樹的存儲開銷占原始方案存儲開銷的百分比，結果如圖6所示。

圖6 存儲開銷對比

從圖6可以看出，隨著帶密鑰和狀態的散列樹深度的增加，存儲開銷的減少越來越明顯；對于相同的深度，分支數越多，存儲開銷越小，最小的大約為原始方案的 0.2，達到一定深度后，存儲開銷趨于穩定。另外，需要注意的是，帶密鑰和狀態的散列樹的根密鑰由保險箱保護并存儲在公有云之中。當需要使用時，由公有云發送給私有云進行密鑰派生并解密文件，私有云不需要承擔根密鑰的存儲開銷，只承擔樹結構的存儲開銷和計算開銷。

4.2.2 計算開銷

本節對所提密鑰存儲管理方案的計算開銷和性能進行分析，包括密鑰派生I/O、密鑰分發I/O以及文件解密時間。首先，對密鑰狀態散列樹的密鑰派生I/O進行測試。

本文所提方案的密鑰派生I/O如圖7所示。從圖7可以看出，方案的密鑰派生I/O與派生樹（密鑰狀態散列樹）的深度有關，與派生樹每層的分支個數無關。深度越深，I/O越小，這是由于隨著深度的增加，需要進行的散列運算次數也在增加。

圖7 本文所提方案的密鑰派生I/O

為了更好地顯示方案的性能，使用本文所提方案與Horus方案[15]進行對比。Horus方案與本文所提方案類似，采用帶密鑰的散列樹來進行密鑰派生，但是，Horus方案沒有很好地解決密鑰撤銷問題。由于2種方案密鑰派生效率與分支數無關，為了更好地對比2種方案的密鑰派生效率，選取分支數b=4來進行對比測試，測試結果如圖8所示。柱狀圖分別表示Horus方案和本文所提方案的密鑰派生I/O，折線圖表示本文所提方案相比于Horus方案密鑰派生I/O的減少量。從圖7可以看出，本文所提方案比Horus方案的密鑰派生I/O低0.02～0.03，幾乎沒有影響。

圖8 密鑰派生I/O對比（分支=4）

圖9顯示了2種方案的密鑰分發I/O。從圖9可以看出，Horus方案和本文所提方案的密鑰分發 I/O幾乎一致，這是由于在分發過程中需要將派生出的密鑰發送到客戶端，通信開銷遠大于密鑰派生開銷，因此密鑰派生I/O的差距可以忽略不計。

圖9 密鑰分發I/O對比（分支=4）

圖10顯示了不同方案的解密時間開銷分析（1 000個文件，文件大小2 KB），圖中的Horus方案快速方案表示Horus方案的快速方式，即將高節點密鑰傳送給客戶端進行解密的方式，本文快速方案表示本文所提方案的快速方式。從圖 10可以看出，通信開銷占據了增加的解密時間開銷的大部分，而密鑰派生時間開銷非常小。使用快速方案，由于只有一次通信的時間開銷，可以達到與原始方案幾乎相同的時間。但是，快速方案要求解密的文件是連續的，這在實際場景中很難達到。

圖10 不同方案的解密時間開銷分析

云環境中存儲文件的復雜性很高，為了更好地反映本文所提密鑰存儲管理方案的性能，選取了不同大小的文件進行解密測試，文件大小從1 KB到32 KB，文件數量從100到100 000個。考慮到實際場景中文件連續性難以預估，不考慮快速方案，測試結果如圖11所示。圖11(a)～圖11(f)分別為文件大小為1～32 KB的測試結果。其中，柱狀圖表示原始方案、本文所提方案以及Horus方案的文件解密時間，折線圖表示2種方案相比于原始方案的文件解密計算時間增量。這里的原始方案指的是將所有密鑰全部存儲在用戶端的方案。從圖11可以看出，隨著文件的增大，本文所提方案和Horus方案相對于原始方案的文件解密時間增量逐漸降低，文件解密時間增量不受文件數量影響；2種方案的解密時間基本相同，測試圖中的波動來源于計算機性能的波動。

為了更全面地反映本文密鑰存儲管理方案的性能，選取從1 KB到1 MB大小不等的1 000個文件，使用原始的密鑰管理方案以及本文所提方案和Horus方案分配密鑰，分別進行了文件解密測試，測試結果如圖12所示。

從圖 12可以看出，本文所提方案計算開銷與Horus方案基本相同，本文所提方案由于在密鑰派生過程中需要考慮撤銷狀態，計算時間略長。隨著文件的增大，文件解密計算時間增加的比例逐漸減小，在文件大于64 KB之后，計算時間增量小于0.2。可見，本文所提方案更適用于文件較大的存儲系統。

4.

2.3 密鑰撤銷

Horus方案采用新建密鑰樹的方式來解決密鑰撤銷問題，這將導致已有密鑰樹結構的改變以及密鑰樹數量的不斷增長。本文所提方案很好地解決了密鑰撤銷問題。假設初始密鑰派生樹數量為10個，對每個派生樹均進行不同程度的密鑰撤銷，圖 13顯示了2種方案的密鑰樹數量對比。從圖13可以看出，Horus方案的密鑰派生樹數量隨著每個密鑰派生樹撤銷比例的增加，增長趨勢呈現指數。在密鑰撤銷頻繁的系統中，這將帶來大量的密鑰樹管理開銷以及密鑰樹存儲開銷。

圖 14顯示了不同撤銷比例帶來的密鑰存儲開銷對比（以7層、4分支的密鑰樹為例）。從圖14可以看出，在撤銷比例小于 0.3時，Horus方案的密鑰存儲開銷略小于本文所提方案的密鑰存儲開銷。當撤銷比例大于 0.3后，Horus方案的密鑰存儲開銷開始快速增長，在撤銷比例達到 0.9時，Horus方案的存儲開銷是本文所提方案的7倍左右。

5 結束語

本文為解決海量多源數據加密帶來的密鑰存儲管理問題，提出了一種基于密鑰狀態散列樹的密鑰存儲管理系統。此方案使用密鑰狀態散列樹作為密鑰派生結構，只需要存儲根密鑰以及密鑰樹結構和撤銷狀態，分塊加密密鑰由這些參數派生計算得到，大大減少了密鑰存儲開銷。同時，通過保險箱

以及密鑰交換協議的設計，使密鑰存儲開銷由公有云來承擔，用戶只需要承擔很小的密鑰計算開銷。

圖11 不同文件大小解密測試

圖12 文件解密時間對比（1 000個文件）

圖13 不同撤銷比例密鑰樹數量對比

圖14 不同撤銷比例密鑰存儲開銷對比

經過詳細的測試證明，在合適的密鑰樹結構下，本文所提方案可以減少將近0.8的密鑰存儲開銷，并且這一開銷由公有云承擔，用戶只承擔較小的密鑰計算開銷。當解密的文件大于64 KB時，解密時間相較于逐一存儲密鑰的方案增加不超過 0.2。同時，本文所提方案解決了密鑰撤銷問題，與Horus方案相比，本文所提方案密鑰樹的結構與數量不隨撤銷比例而變化，在撤銷比例大于0.3時，密鑰存儲開銷優于前者。

[1] 曾文英, 趙躍龍, 尚敏. 云計算及云存儲生態系統研究[J]. 計算機研究與發展, 2011, 48(S1)∶234-239.ZENG W Y, ZHAO Y L, SHANG M. Research on cloud computing and cloud storage ecosystem[J]. Journal of Computer Research and Development, 2011, 48(S1)∶234-239.

[2] ABDALLA M, BELLARE M, CATALANO D, et al. Searchable encryption revisited∶ consistency properties, relation to anonymous ibe,and extensions[J]. Journal of Cryptology, 2008, 21(3)∶350-391.

[3] CURTMOLA R, GARAY J, KAMARA S, et al. Searchable symmetric encryption∶ improved definitions and efficient constructions[C]// ACM Conference on Computer and Communications Security (CCS).2006∶79-88.

[4] CUI Z, ZHU H, CHI L. Lightweight key management on sensitive data in the cloud[J]. Security & Communication Networks, 2013,6(10)∶1290-1299.

[5] ATALLAH M J, BLANTON M, FAZio N, et al. Dynamic and efficient key management for access hierarchies[J]. ACM Transactions on Information and System Security (TISSEC), 2009, 12(3)∶1-43.

[6] BLUNDO C, CIMATO S, VIMERCATI S D C D, et al. Efficient key management for enforcing access control in outsourced scenarios[C]//Emerging Challenges for Security. 2009∶ 364-375.

[7] CUI Z, ZHU H, SHI J, et al. Lightweight management of authorization update on cloud data[C]// International Conference on Parallel and Distributed Systems (ICPADS). 2014∶456-461.

[8] BESSANI A, CORREIA M, QUARESMA B, et al. DepSky∶ dependable and secure storage in a cloud-of-clouds[J]. ACM Transactions on Storage, 2011, 9(4)∶31-46.

[9] 馬華, 白翠翠, 李賓,等. 支持屬性撤銷和解密外包的屬性基加密方案[J]. 西安電子科技大學學報自然科學版, 2015, 42(6)∶6-10.MA H, BAI C C, LI B, et al. Attribute-based encryption scheme supporting attribute revocation and decryption outsourcing[J]. Journal of Xidian University (Natural Science), 2015, 42(6)∶6-10.

[10] 付東來, 彭新光, 楊玉麗. 基于可信平臺模塊的外包數據安全訪問方案[J]. 電子與信息學報, 2013, 35(7)∶1766-1773.FU D L, PENG X G, YANG Y L. Trusted platform module-based scheme for secure access to outsourced data[J]. Journal of Electronics& Information Technology, 2013, 35(7)∶1766-1773.

[11] 田豐, 桂小林, 張學軍,等. 基于興趣點分布的外包空間數據隱私保護方法[J]. 計算機學報, 2014, 37(1)∶123-138.TIAN F, GUI X L, ZHANG X J, et al. Privacy-preserving approach for outsourced spatial data based on POI distribution[J]. Chinese Journal of Computers, 2014, 37(1)∶123-138.

[12] 周林, 矯文成, 吳楊, 等. 一種基于層簇式的衛星網絡組密鑰管理方案[J]. 宇航學報, 2013, 34(4)∶559-567.ZHOU L, JIAO W C, WU Y, et al. A group key agreement protocol based on layer-cluster for satellite network[J]. Journal of Astronautics,2013, 34(4)∶ 559-567.

[13] WONG C K, GOUDA M, LAM S S. Secure group communications using key graphs[J]. IEEE/ACM Transactions on Networking, 2000,8(1)∶ 16-30.

[14] 祝烈煌, 曹元大, 廖樂健. 基于狀態密鑰樹的安全群組密鑰分發協議[J]. 北京理工大學學報, 2006, 26(9)∶805-808.ZHU L H, CAO Y D, LIAO L J. Secure group key distribution protocol based on the status key tree[J]. Transactions of Beijing institute of Technology, 2006, 26(9)∶805-808.

[15] LI Y, DHOTRE N S, OHARA Y, et al. Horus∶ fine-grained encryption-based security for large-scale storage[C]// Usenix Conference on File and Storage Technologies (FAST). 2013∶147-160.

[16] KALLAHALLA M, RIEDEL E, SWAMINATHAN R, et al. Plutus∶scalable secure file sharing on untrusted storage[C]//Usenix Conference on File and Storage Technologies. 2003∶29-42.

[17] MARTIN L. XTS∶ a mode of AES for encrypting hard disks[J]. IEEE Security & Privacy, 2010, 8(3)∶68-69.