基于Merkle樹的安全云存儲系統①

鄭李偉,王雪平

(復旦大學 計算機科學技術學院,上海 200082)

隨著數據量越來越大,越來越多的企業、個人有了上云的需求.最近幾年云存儲方面的產業也飛速發展,各大廠商紛紛推出自己的云存儲產品[1].而用戶們也喜歡使用云存儲產品,因為云存儲產品不需要太多的投入就可以解放本地的存儲空間,而且具有良好的擴展性[2].

然而云存儲也有壞處:讓用戶失去了對文件的控制權[3].如果存儲方不是絕對安全的,那么就可能引發安全性方面的問題[4].例如,云存儲環境中常見的是以明文方式存儲文件,這樣的做法缺少了完整性檢查、控制訪問機制.而且,如果把敏感數據存儲在他人的云存儲環境里,就可能出現泄密問題,進而可能引發安全事故.

但是,大多數的云存儲服務商都要求用戶以明文存儲,并信任他們的服務器和管理員.然而,事實上他們的服務并不那么可靠,云存儲泄密事件屢見不鮮.過去一段時間,許多采用亞馬遜網絡服務公司的AWS S3 簡單云存儲服務的企業,其中包括道瓊斯、威瑞森、聯邦快遞和特斯拉等公司都發生了數據泄露的安全事故.雖然在大多數情況下并不一定是亞馬遜公司云平臺的問題.例如聯邦快遞和特斯拉公司,這兩家公司的AWS S3 存儲服務器沒有設定密碼進行保護,導致其關鍵數據暴露無遺.所以,無論云存儲服務的提供商是否值得信賴,都應該有健全的安全機制來保證用戶的數據安全.

為此,一些存儲系統提出了自己的解決方案[5,6].這些存儲系統保證云存儲安全性的主要手段是加密文件[7].他們將數據的訪問控制權交給數據擁有者,其他用戶想要訪問數據,需要先與數據擁有者聯系[8],這樣的做法在一定程度上提高了安全性,但是這樣也引入了新的問題:第一,數據擁有者有了更高的數據管理門檻,甚至可能需要提供在線服務,這可能讓用戶流失.第二,隨著數據擁有者分享的用戶增多,對分享用戶的管理也會越來越復雜.第三,將數據分享給其他用戶后,其他用戶可能會做出超出分享權限的操作.

針對現有的情況來看,安全云存儲系統主要需要解決的問題是在保證數據不會被服務提供者和其他只擁有部分權限的用戶竊取的情況下,讓系統的開銷盡可能小.以保證用戶能在保證安全的情況下繼續低成本的使用云產品服務.

本文基于以下假設:第一,數據需要存儲在不可信的云存儲服務器上,這個云存儲服務器可能會破壞、竊取用戶的數據.第二,一些惡意用戶可能會竊取其他用戶的數據或者執行超出自己權限范圍的操作[9].根據以上假設,本文提出了一套新的安全云存儲系統.

這套安全云存儲系統將文件轉化為一個基于Merkle 樹設計的Merkle-B+樹來存儲.Merkle-B+樹的各結點上存儲著通過CTR 模式的AES 分組加密算法加密形成的文件密文.基于這樣的設計,當發生對文件的修改時,不需要對所有文件內容都進行重加密和重哈希,只需要對其中被修改的部分重加密和重哈希即可,這樣既保證了文件的安全性,又降低了完整性檢查帶來的重哈希以及文件重加密的開銷.本系統還通過非對稱的讀寫密鑰的分發實現了文件讀寫權限的分離.并且本系統用密鑰來實現文件的讀寫分享等功能,不需要依賴可信第三方也不需要要求客戶端長時間在線.本文設計的安全存儲系統有安全性高、加解密速度快、文件額外占用空間少、管理和使用成本低等特點.

本文第1 節介紹系統設計的目標,第2 節介紹系統設計中的關鍵技術和具體實現,第3 節給出系統的性能測試結果并與其他系統進行比較,第4 節進行總結和展望.

1 相關工作

如引言所說,現有的安全存儲系統保證安全性的主要手段就是加密文件.而主要的研究方向在于:(1)實現現有的存儲系統難以實現的功能.如對加密文件的內容進行檢索等功能.(2)降低加密文件所帶來的開銷.本文的研究方向在于第二點,即提出一種開銷更低的安全存儲系統.

相關工作介紹如下:CFS[10]是早期的安全存儲系統.它通過在磁盤上架設一層虛擬磁盤,在每次往磁盤中寫的時候就對文件進行加密,從磁盤中讀的時候就對文件解密的方式來實現安全存儲.而CFS 的訪問控制就是通過分享這個加密文件的密鑰來實現的.這就導致CFS 只能實現粗粒度的分享而無法實現讀寫權限的分離.

Cepheus[11]率先提出了鎖盒子的概念.在用戶間進行文件分享時,需要依賴一個可信的密鑰服務器(可信第三方)來存儲用戶信息并依賴此可信第三方進行身份認證和訪問控制.

Corslet[12]在Cepheus 的基礎上進行了進一步的優化創新.它通過鎖盒子和Merkle樹的使用,將文件明文的hash 值和加密文件的密鑰統一起來,而且使得在對文件進行修改時,只需要對文件中被修改的文件塊進行重加密和重哈希即可,可以實現高效的重加密和重哈希.但是Corslet 依然需要引入一個可信第三方來實現訪問控制和身份認證.

SiRiUS[13]使用非對稱密鑰進行權限控制.在SiRiUS中,文件是被整體加解密的,完整性校驗也是對整個文件明文去計算哈希來保證的,當發生權限撤銷、文件修改時,就需要對文件整體進行重新加密和重新哈希,性能開銷較大.

Plutus[8]提供了組共享、懶惰撤銷、隨機訪問、文件名加密等功能.但Plutus 的密鑰分享方式門檻很高:當用戶想訪問某文件時,需要向文件擁有者索要密鑰,這時文件擁有者必須在線才能完成密鑰的分發.

綜上所述,現有的安全存儲系統在高效的加解密方式和不需要可信第三方兩者之間只能實現其中一項.故本文提出了一種新的安全存儲系統,可以既實現高效的加解密又不需要可信第三方.

2 設計目標

2.1 虛擬磁盤

本系統架設在底層文件系統之上,與底層文件系統相互獨立,當要從底層文件系統中讀或者要向底層文件系統中寫的時候,文件經過本系統會自動解密或者加密,然后從底層文件系統中讀出或者寫入.這樣就形成了一個虛擬的磁盤,用戶在使用的時候感覺不到加密解密的存在,仿佛在使用一個安全的虛擬磁盤.這樣的做法提高了系統的易用性,降低了用戶的使用門檻和管理成本.

2.2 文件共享和不依賴服務器的訪問控制

本系統使用安全易用的密鑰實現文件共享機制.不需要依賴可信第三方也不需要要求用戶長時間在線來保證文件的分享.文件擁有者可以分享文件給其他用戶,而且可以選擇僅分享讀權限或分享讀寫權限.從服務提供方的角度來看,不需要可信第三方,可以大大降低運營成本,從而可以為用戶提供更加便宜的產品.從用戶的角度來看,不需要用戶長時間在線來保證文件的分享,這樣降低了用戶的使用門檻和使用成本,更加簡單易用.

2.3 端到端的保密性而且具備完整性保護

本系統保證只有合法的被授權的用戶可以獲得數據明文,非法的用戶、服務器管理員、底層文件系統管理員都無法獲取數據明文.而且本系統有完整性保護,對數據的非法篡改可以被用戶察覺,從而保證用戶得到的數據都是正確的[12].端到端的保密性是為了保證文件的明文不會被服務提供方竊取.完整性檢查用來檢測是否有只讀用戶對文件進行了寫操作,從而保證用戶只能做自己權限內的事,不能做超出權限范圍的事.以上兩點保證了存儲系統的安全性.

2.4 輕量級的密鑰管理

本系統可以讓客戶端不需要存儲密鑰,降低被攻擊而泄密的風險,具有較高的安全性,也降低了用戶管理密鑰的成本.而且密鑰的使用和存放對用戶是透明的,對于用戶來說更加易用,使用成本更低.對于每一個文件只會產生一個對稱密鑰用來加密,一方面,這樣加解密更快,另一方面,這樣文件產生的密鑰數較少,方便密鑰管理,讓密鑰管理的成本更低,也更加節約存儲空間.

2.5 性能

本系統對文件的加解密都使用的是對稱密鑰,這樣速度更快.而且本系統通過將文件分塊化處理,使用分塊化處理的方法讓文件被修改后只需要重加密其中被修改的文件塊,并只需要對這些塊重新進行哈希計算,而不需要對整個文件進行重加密和重哈希計算.所以,表現出較高的性能.

3 系統設計與實現

3.1 總體設計

為下文描述方便,本文所用術語的縮寫及含義如表1 術語表.另外,系統的整體結構如圖1 系統結構圖.

圖1 系統結構圖

表1 術語表

存儲服務器SS 負責存放文件,在用戶視角中的一個文件,在存儲服務器中被存儲為一棵Merkle-B+樹.Merkle-B+樹上不僅存儲有文件的密文還有文件明文的哈希值,其中明文的哈希值用來實現完整性檢驗.Merkle-B+樹的具體實現在后面詳細介紹.每個用戶會有一對公私鑰——UEK 和UDK.其中UDK 是通過用戶的密碼直接生成的,而UEK 是和UDK 匹配的公鑰,直接存放在SS 上.因此,UDK 只在使用時由用戶鍵入密碼后直接生成.這樣CL 本地就不需要存儲UDK,提高了系統的安全性.當需要使用UEK 時可以直接從SS處獲得UEK.FSK 是一個對稱密鑰,用來加解密文件,使用對稱密鑰來加解密文件速度比非對稱密鑰更快,可以達到更高的效率.RHSK 和RHDK 用來加解密Merkle-B+樹的根結點,以此來實現讀寫權限的分離.這部分內容之后會詳細介紹.

3.2 Merkle-B+樹設計和分組加密算法

本文基于Merkle 樹[14]設計了Merkle-B+樹來完成存儲文件、進行完整性檢驗等功能.如圖2,Merkle-B+樹分為葉子節點和非葉子節點.其中,葉子節點有6 個部分組成:hash 部分、CTR 部分、文件內容部分、指向父節點的指針、指向下一個葉子節點的指針、指向前一個葉子結點的指針.其中hash 部分記錄了文件內容明文的哈希值.系統使用AES 的CTR 加密模式,CTR 部分存儲CTR 數.本系統將一個文件分成多個塊,最小的加解密和哈希計算粒度是文件塊,每個文件塊的密文存儲在一個結點的文件內容區域上.非葉子結點由4 個部分組成:hash 部分、指向父節點的指針、指向下一個非葉子節點的指針、指向上一個非葉子結點的指針.其中hash 部分值的計算方法如下:

圖2 Merkle-B+樹結構圖

其中,||表示拼接.上層結點的hash 部分是下層節點的hash 部分的拼接的hash 值.這樣的Merkle-B+樹設計可以讓文件有以下好處:

(1)輕量級的重加密.通過將文件分塊,這樣在對文件進行修改后,只需要對其中的一部分進行重加密,而不需要對整個文件繼續重加密.這樣加快了加密速度,實現了一種輕量級的重加密.

(2)輕量級的重哈希.為了實現完整性檢驗的功能,原來對文件進行修改后需要對全文進行重哈希,這樣才能通過比對哈希值的方式來確認文件的完整性,從而發現是否有用戶篡改了文件內容.這樣就意味著在對一個文件的部分繼續進行修改后需要對全文進行一次哈希計算,這樣開銷較大.將文件組織成Merkle-B+樹后,可以只對被修改的塊進行重哈希,然后按照樹的結構一層層向上重哈希就可以.這樣將O(n)的重哈希時間就降低到了O(logn)的時間.而且因為B+樹的度較大,樹高較小,這樣在實際進行重加密時所消耗的時間只會更小.

(3)能夠適應多種場景.Merkle-B+樹的樹高、度等參數都是可以由用戶進行自定義調節的,可以由用戶自己調節來適應各種應用場景.滿足各種時間和空間的要求.

Merkle-B+樹的使用過程在訪問協議部分介紹.

本系統為了能讓文件能夠分塊,采用AES 分組加密算法的CTR 加密模式.采用CTR 加密模式是因為:

(1)CTR 加密模式不需要對文件進行填充,方便文件塊的處理而且節約空間開銷.

(2)支持并行計算,可以充分利用CPU 資源來加速加密、解密.

(3)相同的明文加密后呈現為不同的密文,不容易被統計攻擊,具有更好的安全性.

如圖2所示,每個葉子節點上不止存儲著文件的密文,還存儲著CTR 數值.當用戶要對文件進行解密的時候,可以用FSK 加密CTR 值后得到用來加解密文件的對稱密鑰FFK,然后用FFK 對文件進行加解密.其中,FSK 是在文件上傳時隨機生成的,對一個文件的所有文件塊進行加解密都使用同一個FSK 密鑰.

至此,文件被組織成Merkle-B+樹的形式,文件分塊存儲在Merkle-B+樹中.

3.3 完整性保護和讀寫權限分離的實現

完整性檢查如上文在Merkle-B+介紹中所說的那樣,由Merkle-B+的hash 部分來完成,具體使用方法在訪問協議部分介紹.而讀寫權限分離的實現是通過密鑰來實現的,即,是否具有某種權限是由是否具有某種密鑰來決定的.

文件在上傳時會生成一個FSK、一個RHSK、一個RHDK.其中FSK 用來進行加密文件.而RHSK 和RHDK 用來加密和解密Merkle-B+樹的根結點,這樣就可以利用完整性檢驗來實現讀寫權限分離的.

具體來說,將文件轉化為上文說的Merkle-B+樹后,用RHSK 來加密根節點,然后用UEK 加密RHSK得到RHSK 的密文.將FSK 的密文、RHSK 的密文、RHDK 的明文以及Merkle-B+樹存入SS.當用戶要讀取文件內容時,用戶可以從SS 處拿到FSK 密文,然后用UDK 解密FSK 密文.之后,用戶用FSK 明文去解密Merkle-B+樹,得到每一個文件塊的明文,拼接在一起就是文件內容.按照Merkle-B+樹的結構對每個文件塊重新計算hash 值進行驗證,并對每個結點的hash值進行拼接,一層層沿著路徑向上求hash 值,得到計算的RHV.使用RHDK 解密Merkle-B+樹的根哈希值,將該值與計算得到的RHV 進行比較,如果一致就代表文件沒有被篡改,如果不一致就代表文件被篡改了.這樣就實現了完整性保護.

而讀權限和寫權限用是否有將RHSK 分享給指定用戶來區分.因為如果用戶沒有RHSK 那么他只能通過SS 中存儲的RHDK 來解密得到RHV,即,沒有RHSK 的用戶只能進行RHV 比較,做到完整性檢驗來保證文件內容沒有被篡改過,卻不能對文件進行寫操作.如果沒有RHSK 的用戶篡改Merkle-B+上的文件內容,那么這個用戶會因為沒有RHSK 無法對RHV 進行加密,在之后用戶進行讀取RHV 并對RHV 使用RHDK 進行解密后,得到的結果就和計算RHV 不同,就可以發現文件被篡改了.這樣就保證了只有讀權限的用戶無法對文件內容進行篡改.而有RHSK 的用戶,即,具有寫權限的用戶在修改文件后,會修改RHV 并用RHSK 進行加密.這樣之后用戶進行讀取的時候,用RHDK 對密文解密得到的值就是正確的RHV,可以通過完整性檢驗.本系統使用每個葉子節點的哈希值保證了每個文件塊的完整性,又用非葉子結點保證了以此結點為根的子樹的完整性,所以,Merkle-B+樹的根結點就保證了整棵樹的完整性.又因為只有具有寫權限的用戶才具有RHSK 密鑰,這樣非法用戶一旦篡改了文件內容,就會立刻因為通不過完整性檢查而被發現.所以,可以說RHSK 密鑰保證了Merkle-B+樹的完整性,又因為Merkle-B+樹保存了所有文件塊的明文的哈希部分,所以,保證了加密文件的完整性.

采用Merkle-B+樹來進行完整性檢查和讀寫權限分離的好處如上面所說.當合法地修改文件某個或某些塊的內容時,只需要重新計算這些塊對應的葉子節點的哈希值,并沿著這些葉子節點通往根結點的路徑上所經過非葉子結點的哈希值.最后對更新后的根哈希用RHSK 重新加密.這樣的重加密的時間復雜度是logn級的.如果不使用Merkle-B+樹這樣的結構,就意味著當一個文件的部分被修改時,就需要對整個文件進行重哈希,這樣的開銷較大,特別對于大文件來說,開銷可能非常巨大.所以,使用Merkle-B+樹的方式是更好的.

3.4 文件共享和訪問控制的實現

文件的共享和訪問控制通過密鑰來實現.即,是否擁有對一個文件的讀權限、寫權限的根本區別在于是否擁有某種密鑰.當用戶A 想要分享文件的讀權限給用戶B 時,會從SS 處得到用自己UEK 加密的FSK,然后用自己的USK 解密,得到對應FSK 的明文,然后用用戶B 的UEK 進行加密,得到FSK 的密文上傳SS.這樣用戶B 就獲得了FSK,就可以用FSK 來解密Merkle-B+樹獲得文件內容并進行完整性檢驗.當用戶A 想要分享文件的寫權限給用戶B 時,會從SS 處得到用自己UEK 加密的FSK 和RHSK,用自己的USK 解密后,然后用用戶B 的UEK 來對FSK、RHSK 密鑰進行加密.之后將加密后的FSK、RHSK 上傳到SS 上.之后用戶B 可以從SS 得到用自己UEK 加密的FSK、RHSK,用USK 解密后得到FSK 和RHSK,就可以用FSK 來解密文件,得到文件明文.在修改文件內容,進行重加密和重哈希后,用RHSK 加密新的RHV,這樣就不會影響后續使用.

而使用密鑰去實現文件共享和訪問控制必然意味著密鑰數量的增加,這就引入了如何有效的管理密鑰的問題[15].很多系統都提出了自己的密鑰管理方式[10].本文采用密鑰層級管理的方式來管理密鑰.層級結構如圖3 密鑰層級管理示意圖所示.在本系統中,密鑰分為2 個層級來進行組織和管理:用戶密鑰、其他密鑰.其中,其他密鑰包括FSK、RHDK 等密鑰.這樣就將系統所需的密鑰按照金字塔形式進行排列,用上層密鑰來加密、解密下層的密鑰,這樣用戶只需要管理上層密鑰,其他密鑰可以置于不可信的環境中.這樣就在保證系統安全性的前提下,用戶只需要保存少量密鑰就可以達到想要的效果,降低了用戶管理密鑰的成本.在本系統的密鑰層級中,用戶密鑰是密鑰體系的第一層,要想分發或獲取其他密鑰必須先經過用戶密鑰.這樣用戶就只需要管理用戶密鑰即可.又因為用戶密鑰中的公鑰UEK 是可以直接存放在SS 上的.所以,用戶只需要管理用戶密鑰的私鑰UDK 就可以了.這樣大大降低了用戶的管理成本.

圖3 密鑰層級管理示意圖

3.5 訪問協議

本系統能夠在保證安全性的前提下,實現輕量級的重加密和重哈希不僅和之前的系統架構、加密方法有關,還和訪問協議有關.下面介紹本系統的訪問協議:

(1)上傳文件.上傳文件的流程如下:

①對文件進行初始分塊,按塊分別計算hash 值.然后生成一個對稱密鑰FSK,取當前的CTR 算子,得到當前的CTR 數.用對稱密鑰FSK 對CTR 數進行加密,用得到的FFK 與文件明文進行異或來做加密.至此,得到了分塊的文件密文、分塊的明文hash 值和CTR 值.

②將分塊的明文hash 值按照Merkle-B+樹的層次關系沿著樹的路徑計算上層的非葉子結點的hash 值,并完成樹的構建.然后生成一對非對稱密鑰RHSK 和RHDK,用RHSK 加密Merkle-B+樹的根哈希值.形成最終的Merkle-B+樹上傳到SS.

③上傳用戶用自己的UEK 去加密FSK、RHSK,然后將加密后的FSK、RHSK 的密文以及RHDK 的明文上傳到SS.

(2)讀取文件.讀取文件的流程如下:

①從SS 處獲得加密后的FSK 密文以及RHDK明文,同時獲得Merkle-B+樹.用自己的UDK 解密FSK.用FSK 解密Merkle-B+樹葉子節點上的分塊文件密文,從而獲得文件明文.

②為了驗證文件是否被篡改過.需要進行完整性檢查.對每個文件塊明文求hash 值,然后按照樹的結點路徑層層向上計算出根hash 值.用RHDK 解密根哈希結點,比較兩者是否一致就可以判斷出是否被篡改過.

(3)寫文件.寫文件的流程如下:

①執行讀文件的過程.并從SS 處獲取用自己的UEK 加密的RHSK 密文.

②在用戶對文件進行修改后,將被修改的塊用FSK 密鑰加密CTR 數生成的密鑰來重新加密被修改的塊,來完成部分重加密.

③然后對這些塊的明文進行hash 計算,得到新的hash 值,按照結點的路徑層層向上更新結點的hash 值.對根hash 用RHSK 加密后形成新的Merkle-B+樹上傳到SS.

(4)分享讀權限.為了方便敘述,將分享權限的用戶稱為A,被分享權限的用戶稱為B.分享讀權限的流程如下:

①用戶A 從SS 處獲取用A 用戶的UEK 加密過的FSK 密鑰和用戶B 的UEK.

②A 用UDK 解密FSK 密文,得到FSK 明文,用用戶B 的UEK 加密FSK 明文,得到用戶B 加密的FSK 密鑰的密文.然后上傳到SS.

(5)分享寫權限.為了方便敘述,將分享權限的用戶稱為A,被分享權限的用戶稱為B.分享寫權限的流程如下:

①用戶A 從SS 處獲取用A 的UEK 加密過的FSK、RHSK 密文以及用戶B 的UEK.

②A 用UDK 解密FSK 密文和RUSK 密文,得到FSK、RHSK 明文,用B 的UEK 加密FSK、RHSK 明文,得到用B 的UEK 加密的FSK、RHSK 密鑰的密文.然后上傳到SS.

(6)權限撤銷.權限撤銷的流程如下:

①擁有文件所有權的用戶向SS 提出撤銷某用戶的權限.SS 刪除所有對應得FSK、RHSK、RHDK 以及Merkle-B+樹.

②重新執行上傳操作.

③重新分享給其他用戶權限.

3.6 性能調優

因為考慮到實際使用中會有很多用戶并發的訪問文件,所以,本系統實現了一套鎖機制來保證并發安全,支持多線程并發讀同一個文件[16].本系統使用惰性重加密、重哈希的方式來提高性能.比如,當對Merkle-B+樹進行修改時,不會馬上進行重加密和重哈希,而是等到用戶確認上傳或者確認保存的時候才會進行重加密和重哈希,這樣就減小了開銷.完整性檢查也是惰性的,只有當用戶打開文件的時候才會進行完整性檢查.檢查完畢之后會修改一個“是否完整”的標記,從而保證完整性檢查是惰性的且只做一次.另外,還有緩存機制,會將讀取過的明文緩存起來,再次讀取的時候可以從本地的緩存中直接讀取,省去了解密的過程,降低了系統開銷.

3.7 安全性分析

本系統采用加密的方式來保證系統的安全性.可以說是將系統的安全性委托給加解密的體系.與Corslet對比來看,兩個系統都是對文件進行切分后使用對稱密鑰來對文件進行加密.Corslet 在分享文件權限時依賴可信第三方,本系統通過非對稱密鑰體系來完成相同的功能,而這樣的非對稱加密方式本身就是一種安全性很高、工業界普遍采用的加密方式.而且兩系統在文件服務器上存儲的都是文件密文,不易被攻擊.所以,總體來看,本系統的安全性至少不會比Corslet 差.

4 性能測試實驗

在實驗部分中,本系統被架設在網絡文件系統NFS 上,之所以架設在網絡文件系統NFS 上,是因為NFS 可以很好的模擬實際使用場景.在實際使用中,當對文件執行寫操作時需要通過網絡將文件發送到服務器上,而執行讀操作時也需要通過網絡從服務器處獲取文件.而在NFS 客戶端上讀寫的同時,會把寫的內容通過網絡發送到NFS 服務器上,把需要讀的內容通過網絡從NFS 服務器上獲取過來.所以,NFS 服務器能很好的模擬實際情況.之后對架設了本系統、架設了Corslet 系統[12]、沒有架設任何系統的NFS 系統進行讀寫實驗,比較三者的讀寫耗時差異.在結果分析部分對多種現有的安全存儲系統進行綜合比較,并根據提出各系統的論文中,給出的各系統與未架設系統的NFS 文件系統上的讀寫耗時差異的結果,來進行定量的分析.

4.1 測試環境介紹

文中用2 臺服務器來對本系統進行性能測試.其中一臺作為NFS 服務器,另一臺作為NFS 客戶機,分別作為系統的服務器和客戶機.其中,服務器的配置為2 核CPU、2 GB 內存,客戶機的配置為4 核CPU,4 GB內存.兩臺機器以局域網連接.在加密算法的選擇上,使用AES-256 作為文件加密的加密算法,以CTR 加密模式作為本系統的AES 加密模式.以RSA-512 算法來生成RHSK 和RHDK 用來實現讀寫權限的區分.

4.2 多系統性能比較測試

在這部分中實現了本系統和Corslet 系統.比較架設了本系統的NFS 客戶端、架設了Corslet 系統的NFS客戶端、沒有架設任何系統的NFS 客戶端三者的讀寫文件速度.

4.2.1 大文件多系統性能比較測試

這部分中本系統先創建一個100 MB 的文件[17],然后以讀寫模式打開此文件,將文件平均分成若干塊,來生成對應的Merkle-B+樹.而Corslet 也按照相同的分塊粒度來對文件進行分塊.而未架設任何系統的NFS 客戶端則不對文件分塊.比較多種系統在不同切分方法下,在實驗中表現出來的從磁盤上讀取全部文件內容明文所消耗的時間、將全部文件明文轉化為密文并向磁盤寫入所消耗的時間、讀取文件后順序修改部分文件后將新文件重新寫入磁盤所消耗的時間、讀取文件后隨機修改部分文件后將新文件重新寫入磁盤所消耗的時間.實驗中計量的這4 個量分別代表了下載文件所消耗的時間、上傳新文件所消耗的時間、讀取文件并順序修改部分內容所消耗的時間、讀取文件并隨機修改部分內容所消耗的時間.將文件分為800 塊、160 塊的實驗結果如圖4、圖5所示.

圖4 大文件分800 塊的多系統各操作開銷比較圖

圖5 大文件分160 塊的多系統各操作開銷比較圖

可以看出與沒有架設任何系統的NFS 相比,無論是架設了Corslet 還是架設了本系統,在讀取、寫入、修改文件上增加的時間開銷都不大.這證明本系統和Corslet 系統都是在大文件讀寫環境下開銷較小的系統.而在寫入和修改操作上本系統相比Corslet 系統所消耗的時間的略少的原因是Corslet 系統以文件塊的hash 值作為文件塊的加密密鑰.所以,在將文本轉化為Corslet 中的鎖盒子結構[4]時,為了能夠把密鑰安全的存儲在不可信任的環境下,需要對所有文件塊的hash 值,即密鑰都進行加密.而本系統一個文件只生成一個FSK 密鑰,也只需要對FSK 進行一次加密.而求hash 值的動作兩者都有,這部分開銷基本一致.所以,在寫入上,因為本系統的密鑰加密次數相對較少,所以速度略快.而在修改上,也是因為Corslet 系統的密鑰是由文件塊的hash 值來充當的,所以,當一個文件塊發生修改就需要修改密鑰,而這樣的動作又需要對新hash 值,即新密鑰值,進行加密.因為加密次數較多,所以開銷更大,所消耗時間稍多.

從產生的密鑰數的角度看,Corslet 系統每個文件塊都會求hash 值,并以這個hash 值作為密鑰,而且這個密鑰需要加密后存儲在不可信任環境下,這樣一個文件就會產生多個密鑰,這樣多的密鑰不僅僅會像上面說的那樣,讓讀寫變慢.而且管理它們的成本也很高.而本系統整個文件只會產生一個密鑰,用同一個密鑰來對每個文件塊來進行加解密.這樣本系統在密鑰所需的空間上是占一定優勢的,而且密鑰數量更少就意味著更小的管理開銷和使用成本.

另外,可以看到無論是本系統還是Corslet 系統隨機寫入所消耗的時間相比順序寫入都較多一些.這是因為隨機寫入比順序寫入會涉及更多的文件塊,兩個系統都需要對更多的文件塊進行重加密、重哈希,所以所消耗的時間略長.另外,從按照800 塊進行劃分和按照160 塊進行劃分的實驗結果可以看出,劃分的塊數越多,在修改時表現的性能越好,因為每個塊更小,重加密和重哈希的開銷也更小.而且還可以看出分塊數量越少,那么在上傳和下載文件上的耗時和未架設安全存儲系統的NFS 文件系統相比差別越小.這是因為分塊數量越多,那么Merkle-B+樹的結點也越多,構建和讀取這樣一棵樹的開銷也更多.所以,對文件的切分越細,分成越多塊,文件上傳和下載所附加的額外開銷就越大,而文件在修改時所需要的額外開銷就越小.所以,用戶可以根據實際情況,調節分塊數量來滿足自己的特異性需求.

4.2.2 小文件多系統性能比較測試

這部分中本系統創建一個20 KB 的文件,然后以讀寫模式打開此文件,按照和大文件一樣的實驗方法進行實驗,結果如圖6、圖7所示.

圖6 小文件分160 塊的多系統各操作開銷比較圖

圖7 大文件分800 塊的多系統各操作開銷比較圖

可以看出在小文件環境下,無論是本系統還是Corslet 的開銷都是較大的.這主要是因為本系統在構建Merkle-B+樹時需要添加CTR 數等信息,而添加的這些信息所帶來的開銷與分塊個數有關而與文件大小無關的.所以,在大文件的情況下這些開銷相對文件讀寫而言很小.在這樣的分塊多但是文件小的場景下,這部分開銷相對來說占比較大.表現為圖中的讀寫所花費時間高于沒有架設任何系統的NFS 系統.另外,可以看到在修改操作下,本系統相對沒有架設任何系統的NFS 客戶端所花費的開銷多較多.這主要是因為在修改后需要重新計算hash 值,而重新計算hash 值的開銷也是與塊數量有關的,在這樣多分塊但是文件較小的場景下,這部分開銷占比較大.再加上本身修改操作包含寫操作,所以額外花費的開銷相對單純寫操作來說更大.

針對這種情況,可以采用添加緩存機制來進行優化.當一個文件不是第一次被讀取時,可以直接從緩存中讀取該文件的內容,而不需要再從磁盤上讀取,也不需要再進行密文的解密.這樣可以降低開銷,提高讀寫效率.

另外,可以看出在小文件下按照800 塊進行劃分和按照160 塊進行劃分最終消耗的時間差別不大.這是因為小文件情況下本身構建Merkle-B+樹和加解密的開銷的占比就較大,雖然劃分更細會給修改操作帶來了性能上的提升,會讓上傳和下載操作的性能降低,但是相對于本身占比就較大的Merkle-B+樹的構建開銷和加解密開銷,這樣的性能變化對于整體來說并不明顯.

4.3 結果分析

本系統和其他經典安全存儲系統的比較如表2所示.同時本文還通過比較安全存儲系統架設在NFS 文件系統前后,讀寫性能下降的程度作為量化比較安全存儲系統加密開銷的依據.

表2 安全存儲系統相關工作對比

SiRiUS 系統對文件加密使用的密鑰是非對稱密鑰,這樣就導致該系統的加解密速度較慢,而且該系統的加密粒度是文件級的,這樣對文件的一點局部修改就需要對整個文件全部進行重加密,開銷較大.所以最終該系統整體讀寫性能表現得較差.由提出SiRIUS 的文獻[13]的實驗結果可知,SiRiUS 部署在NFS 文件系統上之后與未部署前相比性能下降約80%.

Plutus 系統采用共享密鑰的方式來進行密鑰分發.當其他用戶想要獲得文件的訪問權限時,需要向文件擁有者申請,此時要求文件擁有者必須在線,并在線的將文件密鑰分享給其他用戶.這樣的分享機制比較低效,它要求用戶必須實時在線才能完成密鑰分發.這就導致用戶的使用門檻和管理成本增加,不具有易用性.

Corslet 系統使用對稱密鑰來加解密文件.文件按照文件塊粒度進行分割來實現部分重加密機制.這都使得Corslet 的讀寫速度較快.但是Corslet 也存在需要可信第三方的問題,這使得Corslet 的運營和管理成本較高.另外,Corslet 以文件塊的hash 值作為密鑰,雖然這樣的做法可以將完整性檢查和密鑰統一起來,但是這就意味著一個文件會有文件塊數量個數的密鑰,密鑰數量的增大必然導致管理成本的增加,而且也意味著更大的空間開銷.從提出Corslet 系統的論文的實驗結果可知,將Corslet 部署在NFS 文件系統上之后大約讀寫性能下降5%.

Plutus 的創新在于系統實現了一些前人未曾實現的功能,但在性能上的表現不夠出色.從性能比較上看,本系統在性能上有明顯優勢.因為Plutus 對文件都是全文加密的,所以重加密和重哈希的開銷很大.而且Plutus 的文件分享要求文件擁有者必須長期在線.所以,從性能的角度和易用性角度來看,本系統有明顯優勢.

從實驗結果來看,本系統在文件的上傳、下載、修改上表現出來的性能與Corslet 相當,同樣是與沒有架設系統時相比讀寫性能下降大約5%.而且不需要像Corslet 那樣依賴可信第三方的介入,具有不依賴可信第三方的簡單性和易用性.而與SiRiUS 系統相比,SiRiUS 系統部署在NFS 文件系統后,NFS 文件系統性能下降約80%,而本系統僅下降約5%,所以本系統在讀寫性能上有較大優勢.故本系統是一種既實現高效的加解密又不需要依賴可信第三方的安全存儲系統.與其他的安全存儲系統相比,在使用成本、簡單性、文件加解密的開銷上有較大優勢.

相對于其他的安全存儲系統來說,本系統在不需要可信第三方的情況下,使文件發生修改后不需要對全文進行重加密和重哈希,而只需要對修改的部分文件塊進行重加密和重哈希,將重加密的開銷大大降低,而重哈希也只需要對修改塊進行重哈希計算,并沿著Merkle-B+樹到根節點的路徑重新計算哈希,將重哈希的復雜度從O(n)降低到O(logn).而且以一個對稱密鑰作為文件加解密密鑰,一方面相對非對稱密鑰來說這樣做文件的加解密速度更快.另一方面這樣讓一個文件只有一個密鑰,也避免了密鑰數量的膨脹.再者,也不需要像Corslet 那樣修改文件內容后需要再修改密鑰,使得在一次文件修改后需要隨之變化的內容盡可能少.所以本系統能在表現出速度上的高效的同時,也不會帶來太多的空間開銷.而這些設計都讓本系統在大文件場景下取得較好的結果.特別在大文件頻繁修改場景下,表現出來的性能更好.

而本系統也進行了一些工程上的優化,包括鎖機制、懶加載、緩存機制等,以此來降低在小文件場景下的開銷.綜合來看,本系統是可以保證用戶信息安全,而且還能夠表現出高性能的高效系統.

5 結論與展望

文中提出一種新的安全云存儲系統架構,確保用戶可以安全的將數據存儲在不信任的環境下,而且由于額外存儲的密鑰較少,所以不會帶來太大的空間開銷.而且本系統具有很好的擴展性,可以直接架設在文件系統之上,使用簡單,對用戶透明,用戶可以很方便的使用該系統.此外,本系統不依賴可信第三方,降低了系統的使用和管理門檻.另外,本系統還提供了豐富、高效的安全機制,包括私密性保護、完整性保護、文件訪問控制等.通過非對稱密鑰的分發實現了讀寫權限的分離,實現了更加精細的訪問控制.通過Merkle-B+樹的設計實現了修改文件時的輕量級重哈希和重加密,讓系統表現出較好的性能.實驗結果表明,架設了本系統的NFS 系統相對于沒有架設本系統的NFS 系統讀寫性能下降約5%.總的來說,本系統是可以保證用戶信息安全,而且還能夠表現出高性能的高效系統.

未來將進一步擴充高效實現安全存儲系統如文件去重、密文搜索等其他功能的方法.