基于密鑰狀態(tài)散列樹的密鑰存儲管理方案

王祥宇，馬建峰，苗銀賓，張凱，伍祈應(yīng)

（西安電子科技大學(xué)網(wǎng)絡(luò)與信息安全學(xué)院，陜西 西安 710071）

1 引言

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

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

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

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

樹是非線性的數(shù)據(jù)結(jié)構(gòu)，由一個集合以及在該集合上定義的一種關(guān)系構(gòu)成。集合中的元素稱為樹的節(jié)點，所定義的關(guān)系稱為父子關(guān)系。父子關(guān)系在樹的節(jié)點之間建立了一個層次結(jié)構(gòu)。在這種層次結(jié)構(gòu)中有一個節(jié)點具有特殊的地位，這個節(jié)點稱為該樹的根節(jié)點，或稱為樹根。樹的這種結(jié)構(gòu)特點能夠?qū)⒍鄠€節(jié)點信息集中于某個節(jié)點上。如圖1所示，通過將密鑰映射到樹的節(jié)點，建立密鑰派生樹，就能夠?qū)崿F(xiàn)將多個密鑰信息集中于單個節(jié)點密鑰上，大大降低密鑰存儲管理開銷。

圖1 密鑰派生樹結(jié)構(gòu)示意

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

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

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

2 技術(shù)架構(gòu)與安全威脅分析

本節(jié)分別介紹了所提密鑰存儲管理方案的技術(shù)架構(gòu)以及安全威脅。

2.1 技術(shù)架構(gòu)

本文密鑰存儲管理方案的技術(shù)架構(gòu)如圖 2所示，系統(tǒng)分為3個部分：用戶、私有云和公有云。

圖2 技術(shù)架構(gòu)

系統(tǒng)流程如下所示。

1) 用戶將自己的明文數(shù)據(jù)發(fā)送到私有云。

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

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

4) 私有云將其轉(zhuǎn)換為搜索陷門后發(fā)送到公有云。

5) 公有云根據(jù)陷門和索引搜索到相應(yīng)的密文結(jié)果返回給私有云。

6) 私有云對數(shù)據(jù)進(jìn)行解密，將明文結(jié)果返回給用戶。

在這個架構(gòu)中，私有云用來分擔(dān)用戶在文件加密和搜索過程中的計算開銷；公有云用來存儲加密的數(shù)據(jù)并提供密文搜索服務(wù)，這符合一般的可搜索加密系統(tǒng)。私有云一般為高性能計算集群（HPC），以O(shè)penStack為例，集群中包含控制節(jié)點、網(wǎng)絡(luò)節(jié)點、存儲節(jié)點和許多計算節(jié)點。

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

2.2 安全威脅假設(shè)

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

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

2) 攻擊者可能攻破某一解密計算節(jié)點。通?？伤阉骷用芟到y(tǒng)會假設(shè)私有云是完全可信的。但是，對安全威脅做一個更強的假設(shè)，假設(shè)攻擊者（如惡意的用戶）可以入侵私有云的計算集群并控制某一客戶端，但是不能入侵所有客戶端，假設(shè) KDS和網(wǎng)絡(luò)節(jié)點是安全的。這個假設(shè)在現(xiàn)實中是常見的，因為 HPC上運行的客戶端程序是直接與用戶進(jìn)行交互的，給予用戶很大的操作權(quán)限，惡意的用戶可能利用客戶端進(jìn)行非法操作。而網(wǎng)絡(luò)節(jié)點和控制節(jié)點掌管 HPC的控制和通信，通常由高權(quán)限的管理員進(jìn)行管理，普通用戶沒有控制權(quán)限，很難攻破。

3 密鑰存儲管理方案設(shè)計

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

圖3 系統(tǒng)密鑰分配過程

文件加密上傳過程如下。

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

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

3) KDS根據(jù)配置生成密鑰，返回給客戶端，如果達(dá)到性能瓶頸，則使用空閑計算節(jié)點生成 KDC進(jìn)行密鑰分發(fā)。

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

文件下載解密過程如下。

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

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

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

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

本文將詳細(xì)介紹密鑰存儲管理過程中的密鑰計算過程、根密鑰的安全存儲機制及密鑰交換協(xié)議以及密鑰分發(fā)集群KDC的設(shè)計。

3.1 密鑰計算過程

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

圖4 派生樹結(jié)構(gòu)

3.1.1 密鑰派生過程

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

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

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

3.1.2 密鑰撤銷過程

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

在實際系統(tǒng)中，狀態(tài)值S的存儲數(shù)據(jù)類型存在數(shù)據(jù)溢出，當(dāng)密鑰更新次數(shù)超過Sx,y的數(shù)域時，在計算式中的Sx,y前面多添加一個“*”，式(1)變?yōu)?/p>

并且令對應(yīng)的Sx,y= 0。再次超過數(shù)域時，重復(fù)此過程，保證系統(tǒng)可以一直運行。

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

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

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

表2 密鑰交換協(xié)議符號對照

圖5 密鑰交換協(xié)議

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

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

當(dāng)一個私有云的客戶端計算節(jié)點Ci受到用戶的下載解密文件群f中的某一部分時，進(jìn)行如下步驟。

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

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

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

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

3.3 密鑰分發(fā)集群KDC的設(shè)計

由于本文設(shè)計的密鑰存儲管理系統(tǒng)中，密鑰管理功能與其他系統(tǒng)中數(shù)據(jù)管理功能是不相關(guān)的，所以密鑰管理功能可以作為一組進(jìn)程實現(xiàn)在一個或多個無狀態(tài)的計算節(jié)點上，構(gòu)成一個密鑰分發(fā)中心。如果 KDC到達(dá)了瓶頸，可以通過添加更多的節(jié)點來進(jìn)行擴展。為了實現(xiàn)密鑰派生，KDC必須得到保險箱內(nèi)容并確定用戶訪問權(quán)限。

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

4 方案安全性與性能分析

本節(jié)對所提方案的安全性進(jìn)行分析，并對方案使用真實數(shù)據(jù)集在真實環(huán)境下進(jìn)行了詳細(xì)的性能測試。

4.1 方案安全性分析

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

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

4.2 方案性能分析

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

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

表3 測試環(huán)境配置

4.2.1 存儲開銷

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

表4 存儲開銷分析

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

圖6 存儲開銷對比

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

4.2.2 計算開銷

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

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

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

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

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

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

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

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

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

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

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

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

4.

2.3 密鑰撤銷

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

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

5 結(jié)束語

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

以及密鑰交換協(xié)議的設(shè)計，使密鑰存儲開銷由公有云來承擔(dān)，用戶只需要承擔(dān)很小的密鑰計算開銷。

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

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

圖13 不同撤銷比例密鑰樹數(shù)量對比

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

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

[1] 曾文英, 趙躍龍, 尚敏. 云計算及云存儲生態(tài)系統(tǒng)研究[J]. 計算機研究與發(fā)展, 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]. 西安電子科技大學(xué)學(xué)報自然科學(xué)版, 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] 付東來, 彭新光, 楊玉麗. 基于可信平臺模塊的外包數(shù)據(jù)安全訪問方案[J]. 電子與信息學(xué)報, 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] 田豐, 桂小林, 張學(xué)軍,等. 基于興趣點分布的外包空間數(shù)據(jù)隱私保護(hù)方法[J]. 計算機學(xué)報, 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] 周林, 矯文成, 吳楊, 等. 一種基于層簇式的衛(wèi)星網(wǎng)絡(luò)組密鑰管理方案[J]. 宇航學(xué)報, 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] 祝烈煌, 曹元大, 廖樂健. 基于狀態(tài)密鑰樹的安全群組密鑰分發(fā)協(xié)議[J]. 北京理工大學(xué)學(xué)報, 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.