利用備份與投票技術實作雲端儲存之即時行為違反證明技術
49
0
0
全文
(2) 摘 要 利用備份與投票技術實作雲端儲存之即時行為違反證明技術 簡偉智 這篇論文中我們研究如何開發一個有效率的即時稽核技術以及雲端儲存系 統使用的違反證明技術 (Proof of Violation；簡稱 POV)。POV 技術可以讓使用者 或是服務提供者做出密碼學的證據，可以用來證明服務提供者違反特性 (Properties)，或讓服務提供者證明自己的清白。POV 技術是讓雲端的使用者和服 務提供者擁有互相不可否認性的技術。即時的稽核會在每一次的檔案操作之後執 行，以確保可以即時發現服務提供者的違反行為。在目前所知的解決方法中，他 必須要在客戶端的裝置中保留檔案的雜湊值，客戶端儲存及同步這些檔案的雜湊 值會照成極大的負擔，而且當一個客戶端一段時間未做檔案操作，下一次檔案操 作前的同步動作會花上非常長的時間。 我們提出一個投票的方法讓客戶端的設備不需要保留任何的檔案的雜湊值。 利用多個獨立的服務提供者，客戶端不僅能即時的稽核、支援 POV 技術，又能 同時擁有多份的備份。實驗結果顯示，本論文提出的方法相較於之前的雲端儲存 即時稽核技術，平均來看能夠節省 8 倍的時間，遇到最糟的情況能夠節省超過 20 倍的時間。雲端儲存的服務提供者可以利用我們所提出的方法，將互相不可否認 性的保證加入他們的服務層級協議。 關鍵字 : 雲端儲存、行為違反證明機制、即時稽核、備份、投票 i.
(3) ABSTRACT Implementing Real-time POV for Cloud Storage by Replication and Voting by Wei-Chih Chien In this paper we study how to develop an efficient real-time auditing and proof of violation on cloud storage. Proof of violation can let user and service provider generate cryptographic proofs that used to proof service provider’s properties violate, or let service provider proof it’s innocence. Proof of violation are solutions for obtain mutual nonrepudiation between user and service provider. Real-time auditing perform on the end of every file operation so that the violation of the service provider can be found instantly. Existing solutions need to cache file’s hash value on client device. Storing and synchronize these file’s hash value are really huge overhead for client device. If a client device being offline in ages, synchronize to latest file’s hash value will speed a really long time. We propose a real-time proof of violation for cloud storage by replication and voting that let client device don’t need to cache any file’s hash value. Using multiple Independent service provider so that client device can real-time audit, support proof of violation, and having multiple file replication. Experimental results are presented that our scheme outperforms previous work 8 times by average, and in the worst case our scheme outperforms previous work by 20 times. Service providers of cloud storage can use the propose scheme to provide a mutual nonrepudiation guarantee in their service-level agreements.. Keyword: Cloud Storage, Proof of Violation, Real-time auditing, Replication, Voting ii.
(4) 致 謝 感謝黃冠寰教授指導我完成了碩士學位，在這兩年教導我許多雲端領域相關 知識，但更重要的是學習了報告的技巧，說服別人的方法以及研究的態度，訓練 我對各種事情抱持挑戰的精神，向科學家之路邁進。感謝我的父母與家人的支持， 減輕我在經濟上以及各個方面的壓力，讓我在研究的過程中無後顧之憂。我也要 感謝我的女朋友玉燕，我們彼此在各自的研究領域努力，也互相教學相長，讓讀 研究所的過程不孤單。 再來我要感謝實驗室的夥伴們，我的同學袁儀齡、廖柏翔、江浩群、陳佳均、 陳之中，學長姐傅詩凱、王子豪、葉上語、陳虹甫，博士班的學長黃鯤義，以及 學弟妹鄭安傑、歐陽亦凡，楊登堯、邱琬琇、張庭韶，大家在實驗室互相討論、 學習、訂便當吃燒臘、做許多奇奇怪怪的事情放鬆壓力。這些都是未來不會忘記 的回憶，祝福各位未來一切順利。 還有一路上遇到的需多師長與同學，雖然沒能一一列出姓名，但仍是非常感 謝大家在我的研究所學習之路上的幫助，才能照就今日的我，也祝福大家未來平 安順心。 簡偉智. 誌於. 國立臺灣師範大學資訊工程研究所 中華民國一零五年七月. iii.
(5) 目 錄 摘 要................................................................................................................................ i ABSTRACT .................................................................................................................... ii 致 謝.............................................................................................................................. iii 附表目錄......................................................................................................................... v 附圖目錄........................................................................................................................ vi 第一章 緒論................................................................................................................. 1 第二章 雲端儲存即時稽核協定................................................................................. 6 第一節 證明違約協定......................................................................................... 6 第二節 雲端儲存即時稽核協定......................................................................... 6 第三節 改良的雲端儲存即時稽核協定............................................................. 9 第三章 問題討論....................................................................................................... 13 第四章 實驗結果....................................................................................................... 15 第五章 相關研究....................................................................................................... 35 第六章 結論............................................................................................................... 39 參考著作....................................................................................................................... 40. iv.
(6) 附表目錄 表格 表格 表格 表格 表格 表格. 1 : 實驗使用的三個範例帳戶 .......................................................................... 15 2 : 建立 merkle tree 所需的時間 (單位:秒)................................................... 16 3 : 從已有檔案的雜湊值的資料建立 merkle tree 所需的時間 (單位:秒)... 16 4 : merkle tree 占用的容量大小 ....................................................................... 16 5 : 沒有使用 POV 技術的執行時間 (單位:秒) ............................................. 17 6 : 使用者和服務提供者在同一個網路區段中，本論文提出的方法，使用不 同數量的伺服器執行一次上傳的動作所花費的時間 (單位:秒) ..... 20 表格 7 : 使用者和服務提供者在同一個網路區段中，本論文提出的方法，使用不 表格. 表格. 表格 表格 表格. 表格. 表格 表格. 同數量的伺服器執行一次下載的動作所花費的時間 (單位:秒) ..... 21 8 : 使用者和服務提供者在同一個網路區段中，2014 Cloud Com 的方法，不 同數量的需要同步長度，執行一次上傳的動作所花費的時間 (單位: 秒) ......................................................................................................... 22 9 : 使用者和服務提供者在同一個網路區段中，2014 Cloud Com 的方法，不 同數量的需要同步長度，執行一次下載的動作所花費的時間 (單位: 秒) ......................................................................................................... 23 10 : 使用者和服務提供者在不同的網路區段中，本論文提出的方法，使用 不同數量的伺服器執行一次上傳的動作所花費的時間 (單位:秒) . 26 11 : 使用者和服務提供者在不同的網路區段中，本論文提出的方法，使用 不同數量的伺服器執行一次下載的動作所花費的時間 (單位:秒) . 27 12 : 使用者和服務提供者在不同的網路區段中，2014 Cloud Com 的方法， 不同數量的需要同步長度，執行一次上傳的動作所花費的時間 (單 位:秒) .................................................................................................... 29 13 : 使用者和服務提供者在不同的網路區段中，2014 Cloud Com 的方法， 不同數量的需要同步長度，執行一次下載的動作所花費的時間 (單 位:秒) .................................................................................................... 30 14 : 本篇論文提出方法與沒有使用 POV 技術的差距倍數......................... 33 15 : 2014 Cloud Com 提出方法與沒有使用 POV 技術的差距倍數 ............. 34. v.
(7) 附圖目錄 圖 圖 圖 圖 圖 圖. 以部分雜湊樹達成有效率的雲端儲存系統即時稽核 .................................... 7 雜湊樹圖示說明 ................................................................................................ 8 改良的雲端儲存即時稽核架構 ........................................................................ 9 在同一個網路區段中，沒有使用 POV 技術的執行時間 (單位:秒) ......... 18 在不同的網路區段中，沒有使用 POV 技術的執行時間 (單位:秒) ......... 18 使用者和服務提供者在同一個網路區段中，本論文提出的方法，使用不同 數量的伺服器執行一次上傳的動作所花費的時間 (單位:秒) ......... 20 圖 7 : 使用者和服務提供者在同一個網路區段中，本論文提出的方法，使用不同 圖. 圖. 圖 圖. 1: 2: 3: 4: 5: 6:. 數量的伺服器執行一次下載的動作所花費的時間 (單位:秒) ......... 21 8 : 使用者和服務提供者在同一個網路區段中，2014 Cloud Com 的方法，不同 數量的需要同步長度，執行一次上傳的動作所花費的時間 (單位: 秒) ......................................................................................................... 23 9 : 使用者和服務提供者在同一個網路區段中，2014 Cloud Com 的方法，不同 數量的需要同步長度，執行一次下載的動作所花費的時間 (單位: 秒) ......................................................................................................... 24 10 : 使用者和服務提供者在同一個網路區段中，比較以上三種方法，執行一 次上傳的動作所花費的時間 (單位:秒) ............................................. 25 11 : 使用者和服務提供者在同一個網路區段中，比較以上三種方法，執行一. 圖 12 : 圖 13 : 圖 14 :. 圖 15 :. 次下載的動作所花費的時間 (單位:秒) ............................................. 25 使用者和服務提供者在不同的網路區段中，本論文提出的方法，使用不 同數量的伺服器執行一次上傳的動作所花費的時間 (單位:秒) ..... 27 使用者和服務提供者在不同的網路區段中，本論文提出的方法，使用不 同數量的伺服器執行一次下載的動作所花費的時間 (單位:秒) ..... 28 使用者和服務提供者在不同的網路區段中，2014 Cloud Com 的方法，不 同數量的需要同步長度，執行一次上傳的動作所花費的時間 (單位: 秒) ......................................................................................................... 29 使用者和服務提供者在不同的網路區段中，2014 Cloud Com 的方法，不 同數量的需要同步長度，執行一次下載的動作所花費的時間 (單位:. 秒) ......................................................................................................... 30 圖 16 : 使用者和服務提供者在不同的網路區段中，比較以上三種方法，執行一 次上傳的動作所花費的時間 (單位:秒) ............................................. 31 圖 17 : 使用者和服務提供者在不同的網路區段中，比較以上三種方法，執行一 次下載的動作所花費的時間 (單位:秒) ............................................. 32. vi.
(8) 第一章. 緒論. 雲端儲存 (Cloud Storage) 是一種藉由網路來存取的線上儲存系統，資料皆儲 存於雲端的服務提供者所管理的虛擬化存放集區 (Virtualized Storage Pools)。服務 提供者操控巨大的資料中心，使用者若想將資料放在這些資料中心，就需要向服 務提供者購買或租賃儲存的容量。一些著名的雲端儲存系統有：Google Drive [1]、 Dropbox [2]、 OneDrive [3]、 iCloud [4]、 SugerSync [5]以及 Box [6]。 安全性 (Security) 和可靠性 (Reliability) 是雲端儲存的兩大主要考量。客戶 端常不會信任將他們的資料交給其他公司。最基礎的安全性的功能有：身分驗證 (Authentication) 、資訊的私密性 (Confidentiality)、完整性 (Integrity) 和不可否認 性 (Nonrepudiation)，其中前三項由使用密碼學的雲端儲存系統就可以簡單的實作 出來 [7]。因為密碼學演算法的保護，使用密碼學的雲端儲存系統擁有私密性； 每一個儲存在雲端儲存系統的檔案都可以對應到一個由使用者的私鑰建立的數 位簽章，這樣就能確認資料的完整性。然而，使用者仍然無法保證他的檔案不會 遺失或是否從雲端儲存系統收到的檔案不是最新的版本。試想下列的情況：因為 某種內部的錯誤或是惡意的安全性攻擊，使用者儲存於雲端儲存系統的一些資料 遭到損毀或刪除，服務提供者很有可能會利用之前備份的舊版本的檔案以及對應 的數位簽章回復檔案，便可以否認使用者最新版本的資料遺失。這樣的情況便稱 為回捲攻擊 (Roll-back Attack) [8]，可以明顯的看出否認性這個問題存在於使用者. 1.
(9) 和服務提供者之間。 有些系統考量雲端儲存系統本身就是不可信任的，因此提供一些方法來偵測 有沒有違反完整性、寫入的順序性 (Write Serializability) 以及讀取的新鮮性 (Read Freshness)，且不需要備份資料或是依賴信任的第三方 [9] [10] [11]。他們的 方法讓客戶端可以偵測出是否有來自任何有害的伺服器操作或惡意的使用者，企 圖做未經驗證的檔案存取。他們需要保存檔案的雜湊樹或是檔案的版本編號以偵 測是否有發生違反的動作。一般來說，這些方法只能拿來偵測違反動作的發生， 他們無法提供正式的證據給第三方來證明服務提供者曾發生違反的動作。 一個雲端儲存系統應有責任提供一些特性，如：完整性、寫入的順序性以及 讀取的新鮮性。然而，現今沒有任何的雲端儲存系統提供者在他們的服務層級協 議 (Service Level Agreement；SLAs) 中保證那些特性。譬如 Amazon S3 [12] 和 Azure [13] 的 SLAs 中保證他們每月可提供 99.9% 的可用性 (Availability)。如 果可用性降至 99.9% 以下，消費者就會有資格獲得賠償。然而，消費者無法在 可用性以外的特性違反時獲得賠償。譬如說，如果檔案遭到損毀或遺失，使用者 通常沒有任何明確的證據可以證明。因為消費者無法對遺失資料的風險做出明智 的決定，他們能做的就是希望這樣的服務可以減少。 如果我們要在一個 SLA 中對更多的特性提供保證，我們需要一個實用的方 法：當使用者做出錯誤的指控時，服務提供者可以證明自己是無辜的；當服務提 供者違反了一些指定的特性，使用者可以拿來證明服務提供者的錯誤 [7]。一旦 2.
(10) 雙方的不可否認性構築於這個方法上，使用者和服務提供者可以制定一個 SLA ， 讓服務的價格由不同等級的安全需求決定。服務提供者保證若使用者能證明資料 的安全性喪失或者被竄改時，將提供雙方約定的賠償金。 POV 這個技術能夠讓使用者或服務提供者提供一個精確的證據，來證明違 反特性的情況發生；或是讓服務提供者證明自己是無辜的 [14]。POV 這個技術 由三個元組 (Tuples) 組成：第一，他需要定義一組特性，服務提供者提供服務給 使用者時必須不能違反這組特性。第二，證據必須是基於密碼學的證據，使用簽 章將使用者和他們發出的請求和服務提供者全部結合在一起。第三，稽核能夠藉 由收集密碼學的證據來實現，證明特性是否違反。稽核可以偵測出服務提供者是 否違反了特性，或是服務提供者可以證明自己是否受到使用者錯誤的指控，也就 是說，使用具有 POV 服務的使用者無法栽贓給服務提供者。假若一個違反的事 件發生，客戶端和服務提供者可以利用密碼學的證據決定誰要來負責。並且，雙 方若有爭議發生，他們可以呈現證據給一個第三方 (如仲裁人或法官) 。POV 這 個技術完全滿足一個具負責任的雲端系統的需要。 研究將 POV 技術使用在雲端系統的是從基於 epoch 的技術開始的 [15] [16]。當一個 epoch 開始的時候，使用者和服務提供者之間交換的密碼學的證據 就會累積起來。接下來，隔了一段時間之後，累積的密碼學的證據就拿來執行稽 核。在這篇論文中 [16]，他採用文件目錄的雜湊樹和累積的密碼學的證據來實行 稽核的技術。通過稽核就可以證明在這個 epoch 期間內，沒有任何的檔案操作動 3.
(11) 作違反了服務的特性。在稽核結束後，累積的證據便可以捨棄，並開始一個新的 epoch。一個 epoch 可能是幾個小時或者是幾天，藉由設備的效能或是通訊的頻 寬等等原因所決定。 既然基於 epoch 的技術是可行的已經被論證，目前的問題就是只能在一個 epoch 結束時才偵測出特性的違反。考量以下情況：若儲存於雲端儲存系統中的 是一個公司要簽署的重要文件，使用到錯誤的版本可能會造成巨大的損失。基於 epoch 的 POV 技術只能在 epoch 結束的時候才能偵測出特性的違反，而不能在 每次下載檔案的時候偵測。因為有這樣的情況，驅使我們開發一種即時的 POV 技術，在每次的檔案操作當下都可以執行稽核。 在這之前本論文指導教授黃冠寰博士的一份研究提出了一個可以在每次檔 案操作時執行稽核的即時的 POV 技術 [14]，他提出了一個密碼學負責的協定， 利用四步驟的握手協議 [16]來收集密碼學的證據。為了滿足即時的稽核的需求， 下載的檔案的雜湊值應該暫存於客戶端的設備中。暫存於客戶端設備中的檔案的 雜湊值會藉由儲存於服務提供者那裡累積的證據來同步，客戶端就可以捨去交換 檔案的雜湊值的麻煩。比起儲存所有檔案的雜湊值，我們設計了只要儲存部份的 雜湊樹於客戶端的設備，如此便能節省記憶體的需求以及初始化的時間。然而， 收集密碼學的證據的負擔、同步雜湊值的負擔、以及儲存雜湊樹於多個客戶端設 備的負擔仍然無法避免。相較於沒有使用即時的 POV 技術的檔案操作，小檔案 (1~100kB)和大檔案(5~10MB)平均分別需要 70~100 倍以及 8~10 倍的時間來完成 4.
(12) 一個檔案寫入的操作。這驅使我們開發一個更有效率的方法。 在本論文中，我們提出一個投票的方法讓客戶端的設備不需要保留任何的檔 案的雜湊值。利用多個獨立的服務提供者，使用者每一次的操作都向所有服務提 供者發送請求指令，收集所有服務提供者的回傳資料後經比對能夠及時的確認資 料的完整性，而回傳資料上的簽章及密碼學的證據能夠達到 POV 的效果，當發 生問題時使用者和服務提供者雙方能夠以保留的證據稽核確認發生錯誤的是哪 一方。我們提出的方法不僅不用耗費大量時間同步，又能同時擁有多份的備份。 這篇論文的組織如下：在第二章我們介紹雲端儲存的即時稽核協定，包含之 前的做法以及本論文提出的新的方法。第三章討論一個雲端儲存系統可能會遭遇 的攻擊以及我們提出的方法如何解決此問題。第四章呈現各種檔案操作、各種檔 案大小和不同數量的伺服器等等動作與之前的方法所做的實驗數據比較。第五章 為之前相關的研究。最後第六章為結論以及未來展望。. 5.
(13) 第二章. 雲端儲存即時稽核協定. 第一節. 證明違約協定. 前一章提到為了讓服務提供者可以證明自己的清白或是讓使用者證明服務 提供者的確有出錯，過去的研究提出了 POV 技術，由三個元組組成：第一，他 需要定義一組特性，服務提供者提供服務給使用者時必須不能違反這組特性。第 二，證據必須是基於密碼學的證據，使用簽章將使用者和他們發出的請求和服務 提供者全部結合在一起。第三，稽核能夠藉由收集密碼學的證據來實現，證明特 性是否違反。稽核可以偵測出服務提供者是否違反了特性，或是服務提供者可以 證明自己是否受到使用者錯誤的指控。假若一個違反的事件發生，客戶端和服務 提供者可以利用密碼學的證據決定誰要來負責。並且，雙方若有爭議發生，他們 可以呈現證據給一個第三方 (如仲裁人或法官) 。. 第二節. 雲端儲存即時稽核協定. 一篇先前發表的論文提出了一個以部分雜湊樹達成有效率的雲端儲存系統 即時稽核技術(2014 CloudCom) [14]，在此提到這篇論文的原因，是因為本論文後 面提出的方法能夠有效的解決目前碰到的問題，因此先在此簡單介紹之前這篇論 文的架構與做法。此論文考慮一個用戶有多個裝置，可能會同時有許多的裝置向 服務提供者存取的情況。為了達到多個裝置的即時稽核，以及解決使用者與服務 提供者之間的不可否認性問題，此論文提出了一個機制，如圖 1 所示。. 6.
(14) 圖 1 : 以部分雜湊樹達成有效率的雲端儲存系統即時稽核. 首先，使用 merkle tree [17]。merkle tree 是一個對應檔案目錄的資料型態， 他的子節點為資料的雜湊值，樹的頂端為 root hash。圖 2 中的 (A) 是一個檔案 目錄，(B) 為他的 merkle tree，每一個檔案和資料夾都可以對應到一個雜湊值。 資料夾的雜湊值為：將資料夾內檔案的雜湊值連結 (concatenation) 起來，然後再 計算這個資料的雜湊值。使用者保留部分的 merkle tree，每一次請求讀寫檔案後 檢查 merkle tree 的 root hash 值是否和服務提供者回傳的一樣，才能確認服務提 供者沒有操作錯誤。. 7.
(15) 圖 2 : 雜湊樹圖示說明. 儲存伺服器儲存使用者的資料夾及檔案；稽核伺服器與使用者的裝置交換證 據以及 merkle tree，以達到與服務提供者同步的步驟；使用者必須儲存 merkle tree， 以及最後留下來的密碼學的證據，用來和稽核伺服器更新目前最新的狀態。最後 同步伺服器儲存最後一個使用者存取後的密碼學的證據以及 root hash，以防止服 務提供者更改檔案或是稽核時需要的資料。 以上的架構雖然能夠運作，但我們發現在一個特別的情況下，使用以上架構 的系統會遭遇到非常嚴重的延遲，使用者會因為這個問題，在未開始操作檔案的 上傳下載動作前要等待一段明顯的延遲時間。此問題發生在使用者的一個裝置上 線前，有其他的裝置操作了非常多次的動作之後，通常是因為此裝置一段時間未 始用。因為後來上線的裝置需要先將自己儲存的 merkle tree 更新，前面累積了數 百次、數千次的動作，merkle tree 需要重新計算大量的節點的 hash 值，因此在 還沒正式做指定的工作前，使用者必須等待一段很長的時間才能開始，此為以上 架構之最壞情況(worst-case)。 8.
(16) 第三節. 改良的雲端儲存即時稽核協定. 為了處理前面所提到的 worse-case，我們提出了一種全新的、更快速的架構， 能夠解決客戶端在真正檔案操作的動作前同步時間太長的問題，如圖 3 所示。. 圖 3 : 改良的雲端儲存即時稽核架構. 在這個新的架構中，一樣使用同步伺服器來儲存最後操作所留下的證據，即 服務提供者的回覆。但是在這個新的架構中，客戶端的設備完全不需要儲存任何 的 merkle tree 或證據資料，藉由利用多個各自獨立的服務提供者，收集他們回傳 的結果以即時的確認資料的版本是否正確。各個服務提供者的伺服器儲存使用者 的資料夾的 merkle tree，還有備份這次操作修改的檔案的前一個版本，為的是後 來稽核演算法的需要，利用備份的前一個版本的檔案記算出前一個版本的 merkle. 9.
(17) tree。在後面的章節會解釋稽核演算法的步驟。 我們的系統的安全性基於一個假設： 「同時有 k 個伺服器同時回傳錯誤結果 的機率是趨近於 0。」在此說明，因為我們可以選擇全世界不同地區的服務提供 者，不容易因為天然或人為的災害遺失所有伺服器上的資料；而不同的服務提供 者使用不同的演算法來備份使用者的資料，有心人士無法使用同一個方法來攻擊 各式各樣的系統，因此我們這個假設是十分合理的。有了這樣的假設，使用者可 以相信多數一樣結果的服務提供者是對的。每次的檔案操作請求後，收集各個服 務提供者的回覆並比較，若有不同的結果出現時，只要稽核與多數不同的服務提 供者就可以了 [18]。. 即時稽核溝通架構: 當每次設備 P 要向伺服器提出請求，都會遵循以下步驟： 步驟一 : Lock 同步伺服器。 步驟二 : 當設備 P 要存取他帳號(用戶 U)裡的檔案，他會發送一個請求訊息 (request message) Qi, Qi=(OPi, SNi, [OPi, SNi]pri(U))給各個伺服器。其中 OPi 為請求的格式，有操作的類別(讀取檔案、寫入檔案或稽核要求)、 目標檔案的路徑、目標檔案的雜湊值。SNi 為這次動作的序號。 步驟三 : 當一個伺服器收到 Qi 後，藉由驗證 [OPi]pri(U)電子簽章，以及檢查 OPi 裡面的檔案的 hash 值，確認是否為正確的請求。 10.
(18) 步驟四 : 如果 Qi 為寫入檔案 f，伺服器備份檔案 f 的 hash 值，使用 Qi 的 OPi 中 的檔案 hash 值更新 merkle tree。 步驟五 : 伺服器將檔案 f 的 hash 值和 merkle tree 的 roothash 值加入執行結果 Li。 步驟六 : 伺服器回傳一個回應訊息(acknoledgement message) ACKi 給設備 P，其 中 ACKi=(Li,Qi,[Li,Qi]pri(Server))。 步驟七 : 設備 P 收集所有伺服器回傳的 ACKi，確認所有的 ACKi 結果皆相同， 更新同步伺服器的 ACKi。 步驟八 : Unlock 同步伺服器。 步驟九 : 如果 Qi 為讀取檔案，向最近的伺服器下載檔案，確認 ACKi 中的 hash 值是否相同。 步驟十 : 如果 Qi 為寫入檔案，將檔案上傳到每一個伺服器。. 步驟二在請求訊息中加入了序號，是為了保障服務提供者端的安全。序號從 0 開始，和 i 是一樣的值。不同設備之間利用同步伺服器可以得到最新的序號， 因此整個系統共用一組序號就可以了。在請求訊息中加入序號能夠讓使用者無 法假造前一次動作的證據，有了這個序號，使用者的證據和服務提供者的證據 就必須一致，使用者不能任意拿出對他有利的版本再宣稱是最後的版本，因此 加上序號便能夠保護服務提供者端。 在步驟七中，使用者藉由檢查每一個伺服器回傳的結果是否相同，馬上可以 11.
(19) 知道系統是否發生錯誤，服務提供者是否給予不正確的檔案或證據，即時的啟動 稽核的機制。因此在這樣多個裝置的操作環境中，能夠防止回捲攻擊。 因為伺服器回傳的 ACK 中有包含 root hash，最後儲存在同步伺服器中，因 此可以確定在使用者未進行下一個請求前，服務提供者所儲存的資料是被驗證過 沒有問題的。接著使用者發出下一個請求，若在這個請求後伺服器回傳的結果是 錯誤的，就可以確定是在這一次的請求發生問題，使用稽核的演算法也就只要檢 查這一次的過程中哪裡出錯，就可以確定發生錯誤的是使用者或是服務提供者。 使用者要啟動稽核，首先需要向伺服器索取前一個版本的 merkle tree (MTi-1)，接 下來稽核演算法檢查完以下兩點，就能證明這次操作的過程是否有出錯： 1. 使用者檢查 MTi-1 的 root hash，應該要和儲存於同步伺服器中的前一版本證 據 (ACKi-1) 裡面的 root hash 一樣，如此一來才能確定服務提供者沒有給錯 誤的 merkle tree 給使用者。 2. 使用者以這次請求中的 OPi 裡面的 hash 值更新 MTi-1 ，也就是找到對應的 檔案位置，將 hash 值修改後，在由下往上重新計算到 root hash，這也就是 為什麼要完整的 merkle tree 的原因。於是更新後 MTi-1 的 root hash 應該要 和服務提供者現在的 root hash 是一樣的，若不同則表示這一次的請求是服務 提供者出了問題，因此才會和使用者重新驗算出的 root hash 值不相同。如此 一來，使用者就有足夠的證據能夠提供法院或是信賴的第三方，證明服務提 供者的錯誤，以獲得雙方約定的賠償。 12.
(20) 第三章. 問題討論. 在此研究中，有一項問題值得讓我們提出來討論。本研究的架構是設定能夠 提供給多個設備同時進行存取的操作，藉由同步伺服器的控制，讓設備之間動作 的紀錄不會有錯誤的順序，也不會讓多個設備同時讀寫同一個檔案時使系統發生 死結 (Deadlock)的狀況。但是使用者和服務提供者之間需要交換證據以及傳輸檔 案，考量可能會有各種不同效能、不同距離範圍、不同網路傳輸速度等種種原因， 傳輸檔案會耗費相當長的時間。若使用之前那篇以部分雜湊樹達成有效率的雲端 儲存系統即時稽核技術中的做法，使用者必須將檔案上傳給服務提供者或從服務 提供者處下載檔案之後，雙方才能確認這一次的操作完全正確，才能驗證對方提 供的證據正確，最後才可以 Unlock 同步伺服器。若傳送的檔案極大或是前面提 到的種種原因，照成一個請求的操作時間非常長久，又或者是有惡意的使用者了 解此架構如此的缺陷，故意地將檔案傳輸的速度減慢，一直重複這樣的動作使得 服務提供者的服務被霸佔，使其他真正想要使用服務的使用者無法使用，這樣的 攻擊稱之為 Slow Running Attack。 為了處理可能會發生 Slow Running Attack 的問題，本論文提出了和之前的 論文不同的方法。首先，為了讓雙方都能有一份互不可否認之證據，使用者先傳 送有自己簽章的請求，請求內包含這次操作的動作與選擇的檔案的雜湊值。服務 提供者收到請求和簽章後，先驗證簽章沒有問題，再紀錄本次使用者將要操作的 檔案的雜湊值，以確保之後的動作不會發生錯誤，接下來回傳回應訊息給使用者， 13.
(21) 就可以 Unlock 為其他設備服務了。能夠不用立即傳資料的原因是，使用者檢查 了服務提供者回傳的回應訊息的簽章和資訊後，雙方就都擁有對方對這次操作的 簽章，只要任何時間發生問題，都可以拿出這個證據來澄清自己的清白，或對方 的錯誤。因此經過交換證據後，使用者就可以慢慢的將資料傳到服務提供者的伺 服器上，服務提供者可以同時處理後面其他設備的請求，不會因為要處理一個非 常大的檔案而占用非常久的時間，每一個檔案的處理時間都是固定的，因此 Slow Running Attack 便不會發生了。 現今的雲端儲存系統有共享資料夾的功能，若使用者上傳下載的資料是另外 一個帳號的資料，使用原本的 Merkle tree 會有不足的地方。若碰到這樣的情況， 我們可以把共享的資料夾當做另外一個帳戶來處理，特別再建立另外一個 Merkle tree 處理這個特殊的情況，還是可以使用我們的方法提供雙方不可否認的密碼學 證據。或許不是最好的解決方法，但目前是能夠使用的，未來我們可以再討論是 否有更好的方法。. 14.
(22) 第四章. 實驗結果. 在這個章節中我們實作了一系列的實驗來證明本論文提出架構的可行性以 及詳細的執行時間，包含建立 merkle tree、不同距離、不同數量的伺服器的各種 步驟所需要花費的時間。首先先介紹我們實驗所使用的三個不同的帳戶，如表格 1 所示分別是(1) 帳戶 A，屬於檔案數目小以及容量小的範例，(2) 帳戶 B 為檔 案數目很多，但是每一個檔案的容量都不大，(3) 帳戶 C 為實際使用了 20 年的 一個資料夾，因此具有參考價值。. 總容量. 檔案數量. 資料夾數量. 帳戶 A. 777 MB. 48. 6. 帳戶 B. 145 MB. 54198. 188. 帳戶 C. 5.95 GB. 45089. 1459. 表格 1 : 實驗使用的三個範例帳戶. 接下來的實驗我們在兩個平台上面實作：(1) Linux Mint 17.3 系統，作為客 戶端的設備，(2) CentOS 6.6 系統，作為服務提供者端的伺服器。其中(1) Linux Mint 17.3 系統規格 CPU 為 2.13GHz Intel Core i3-330M 雙核心，8GB 的記憶體， 120GB 的固態硬碟空間。(2) CentOS 6.6 系統規格 CPU 為 3.30GHz Intel Xeon E5-2643 四核心，8GB 的記憶體，53GB 的硬碟空間以及 Java 版本 1.8.0_40。 15.
(23) 帳戶. A. B. C. 時間. 9.40653. 55.14738. 339.18192. 表格 2 : 建立 merkle tree 所需的時間 (單位:秒). 表格 2 為第一次建立帳號時，所有的檔案都還沒有算過雜湊值，所以必須要 計算所有檔案的雜湊值並彙整出 root hash 的時間。. 帳戶. A. B. C. 時間. 0.00333. 2.70313. 0.3342. 表格 3 : 從已有檔案的雜湊值的資料建立 merkle tree 所需的時間 (單位:秒). 但在實際使用的環境中，服務提供者不需要等到所有的檔案上傳後才計算 merkle tree，服務提供者可以在收到檔案的同時計算出檔案的雜湊值，因此較符 合真實使用環境的建立 merkle tree 的時間應該是已經有檔案的雜湊值之後再計 算，如表格 3 所示，服務提供者在收到使用者所有檔案之後，可以在幾秒鐘的時 間就準備好 merkle tree，因此初始的時間不會影響系統的效能。檔案的大小不會 影響執行時間，因為帳戶 B 的檔案數量最多，因此這次帳戶 B 需要的時間最久。. merkle tree 占用容量. A. B. C. 5.4 KB. 5.08 MB. 4.37 MB. 表格 4 : merkle tree 占用的容量大小 16.
(24) 接著表格 4 為產生完整 merkle tree 的容量大小，merkle tree 的容量大小由 檔案數量所決定，因此帳戶 B 仍然是最大的。而他只需要 5.08 MB 的 merkle tree 容量，這樣的容量並不會對客戶端的設備造成太大的負擔，而且在我們提出的方 法中客戶端的設備不需要一直保留 merkle tree ，只有在稽核計算時才會使用到， 其他的情況下不會占用客戶端設備的容量。. 接下來我們的實驗分別有在同一個網路區段以及不同的網路區段兩個環境 下的實驗，不同的網路區段為使用者和服務提供者之間相距 16 個 Hop 距離的環 境 (由 Traceroute 程式計算)。我們列出讀取及寫入檔案的相關實驗數據，首先我 們先列出沒有加上任何 POV 技術、單純讀取及寫入檔案的執行時間，有了這個 基底的時間我們才能夠比較之後的兩種方法的優劣。. 同一個網路區段. 不同的網路區段. 測試檔案大小. 上傳時間. 下載時間. 上傳時間. 下載時間. 小於 10 KB. 0.010608. 0.007845. 0.069273. 0.056629. 小於 100 KB. 0.014393. 0.013691. 0.121093. 0.087351. 小於 1 MB. 0.090440. 0.088570. 0.343584. 0.225566. 小於 10 MB. 0.367989. 0.354916. 1.375616. 0.699524. 表格 5 : 沒有使用 POV 技術的執行時間 (單位:秒) 17.
(25) 圖 4 : 在同一個網路區段中，沒有使用 POV 技術的執行時間 (單位:秒). 圖 5 : 在不同的網路區段中，沒有使用 POV 技術的執行時間 (單位:秒). 18.
(26) 從 表格 5 和 圖 4 可以看到在同一個網路區段內，沒有使用 POV 技術上 傳下載檔案，在我們的實驗環境中所需要花費的時間，檔案越大當然執行的時間 越長。而上傳時間和下載時間非常接近。 而從 表格 5 和 圖 5 則可以看到在不同的網路區段中，沒有使用 POV 技 術上傳下載檔案所需要花費的時間。上傳的時間會比下載的時間稍微久一點，這 是由我們實驗環境的網路速度所決定，接下來的實驗都是在同一個環境，可以以 這個基準比較。. 接下來我們先列出使用者和服務提供者在同一個網路區段中，這篇論文所提 出的方法以及 2014 Cloud Com [14] 提出的方法的執行時間。. 這篇論文所提出的方法之執行結果如下 : 表格 6 和 圖 6 列出服務提供者 使用不同數量的伺服器，上傳一個檔案所需要使用的時間，而 表格 7 和 圖 7 則是下載一個檔案所需要使用的時間。這些數據都是使用者和服務提供者在同一 個網路區段內的執行時間，因此演算法的好壞影響最後的結果較大，檔案傳輸的 時間在這裡就不是主要的變數。. 19.
(27) 測試檔案大小. 3 個伺服器. 5 個伺服器. 7 個伺服器. 9 個伺服器. 小於 10 KB. 0.046139. 0.067923. 0.101676. 0.108696. 小於 100 KB. 0.070739. 0.083563. 0.112895. 0.145049. 小於 1 MB. 0.153822. 0.166289. 0.200053. 0.203870. 小於 10 MB. 0.430937. 0.513879. 0.684666. 0.694259. 表格 6 : 使用者和服務提供者在同一個網路區段中，本論文提出的方法，使用不同數量的伺服器. 執行一次上傳的動作所花費的時間 (單位:秒). 圖 6 : 使用者和服務提供者在同一個網路區段中，本論文提出的方法，使用不同數量的伺服器執. 行一次上傳的動作所花費的時間 (單位:秒). 20.
(28) 測試檔案大小. 3 個伺服器. 5 個伺服器. 7 個伺服器. 9 個伺服器. 小於 10 KB. 0.042295. 0.054263. 0.064370. 0.078872. 小於 100 KB. 0.053583. 0.055442. 0.083961. 0.097507. 小於 1 MB. 0.146021. 0.159869. 0.195817. 0.202213. 小於 10 MB. 0.392072. 0.476251. 0.622665. 0.625499. 表格 7 : 使用者和服務提供者在同一個網路區段中，本論文提出的方法，使用不同數量的伺服器. 執行一次下載的動作所花費的時間 (單位:秒). 圖 7 : 使用者和服務提供者在同一個網路區段中，本論文提出的方法，使用不同數量的伺服器執. 行一次下載的動作所花費的時間 (單位:秒). 21.
(29) 2014 Cloud Com 的方法之執行結果 : 表格 8 和 圖 8 列出使用者在執行 一次上傳動作，執行前同步不同長度的 Chain Hash 所需要花費的時間，這就是 前面所提到這個方法的 Worst-case，隨著上傳檔案前需要同步的長度越長，執行 一次動作所需要的時間就越久。表格 9 和 圖 9 則列出下載動作的時間。這些 數據也是使用者和服務提供者在同一個網路區段內的執行時間。. 同步長度. 同步長度. 同步長度. 同步長度. 同步長度. 2. 10. 50. 100. 500. 小於 10 KB. 0.146783. 0.184138. 0.332988. 0.409002. 0.409002. 小於 100 KB. 0.194642. 0.209044. 0.341408. 0.491967. 0.491967. 小於 1 MB. 0.331595. 0.385494. 0.403481. 0.537866. 0.537866. 小於 10 MB. 0.501692. 0.518835. 0.576403. 0.819893. 0.819893. 測試檔案大小. 表格 8 : 使用者和服務提供者在同一個網路區段中，2014 Cloud Com 的方法，不同數量的需要同. 步長度，執行一次上傳的動作所花費的時間 (單位:秒). 22.
(30) 圖 8 : 使用者和服務提供者在同一個網路區段中，2014 Cloud Com 的方法，不同數量的需要同步. 長度，執行一次上傳的動作所花費的時間 (單位:秒). 同步長度. 同步長度. 同步長度. 同步長度. 同步長度. 2. 10. 50. 100. 500. 小於 10 KB. 0.121268. 0.249803. 0.331339. 0.515956. 1.675274. 小於 100 KB. 0.134563. 0.258717. 0.338794. 0.564519. 1.796222. 小於 1 MB. 0.279563. 0.302230. 0.440841. 0.588905. 1.994046. 小於 10 MB. 0.462677. 0.539638. 0.595140. 1.171150. 2.241951. 測試檔案大小. 表格 9 : 使用者和服務提供者在同一個網路區段中，2014 Cloud Com 的方法，不同數量的需要同. 步長度，執行一次下載的動作所花費的時間 (單位:秒). 23.
(31) 圖 9 : 使用者和服務提供者在同一個網路區段中，2014 Cloud Com 的方法，不同數量的需要同步. 長度，執行一次下載的動作所花費的時間 (單位:秒). 最後整理使用者和服務提供者在同一個網路區段中，將沒有使用 POV 的方 法、本篇論文提出的方法以及 2014 Cloud Com 的方法整理成圖 10 和圖 11 的比 較圖表。. 24.
(32) 圖 10 : 使用者和服務提供者在同一個網路區段中，比較以上三種方法，執行一次上傳的動作所. 花費的時間 (單位:秒). 圖 11 : 使用者和服務提供者在同一個網路區段中，比較以上三種方法，執行一次下載的動作所. 花費的時間 (單位:秒) 25.
(33) 接下來我們先列出使用者和服務提供者在不同的網路區段中，這篇論文所提 出的方法以及 2014 Cloud Com [14] 提出的方法的執行時間。 這篇論文所提出的方法之執行結果如下 : 表格 10 和 圖 12 列出服務提供 者使用不同數量的伺服器，上傳一個檔案所需要使用的時間，而 表格 11 和 圖 13 則是下載一個檔案所需要使用的時間。這些數據都是使用者和服務提供者在 不同的網路區段內的執行時間，主要的時間都是在檔案傳輸的部分。. 測試檔案大小. 3 個伺服器. 5 個伺服器. 7 個伺服器. 9 個伺服器. 小於 10 KB. 0.217563. 0.331341. 0.466655. 0.570460. 小於 100 KB. 0.245769. 0.410174. 0.479227. 0.660178. 小於 1 MB. 0.433338. 0.594532. 0.640597. 0.786688. 小於 10 MB. 1.636473. 1.972134. 2.011500. 2.163858. 表格 10 : 使用者和服務提供者在不同的網路區段中，本論文提出的方法，使用不同數量的伺服. 器執行一次上傳的動作所花費的時間 (單位:秒). 26.
(34) 圖 12 : 使用者和服務提供者在不同的網路區段中，本論文提出的方法，使用不同數量的伺服器. 執行一次上傳的動作所花費的時間 (單位:秒). 測試檔案大小. 3 個伺服器. 5 個伺服器. 7 個伺服器. 9 個伺服器. 小於 10 KB. 0.263332. 0.358435. 0.490343. 0.556110. 小於 100 KB. 0.270404. 0.396497. 0.567059. 0.597088. 小於 1 MB. 0.382264. 0.590987. 0.694622. 0.846141. 小於 10 MB. 0.823476. 1.086515. 1.208293. 1.278169. 表格 11 : 使用者和服務提供者在不同的網路區段中，本論文提出的方法，使用不同數量的伺服. 器執行一次下載的動作所花費的時間 (單位:秒). 27.
(35) 圖 13 : 使用者和服務提供者在不同的網路區段中，本論文提出的方法，使用不同數量的伺服器. 執行一次下載的動作所花費的時間 (單位:秒). 2014 Cloud Com 的方法之執行結果 : 表格 12 和 圖 14 列出使用者在執 行一次上傳動作，執行前同步不同長度的 Chain Hash 所需要花費的時間。表格 13 和 圖 15 則列出下載動作的時間。這些數據也是使用者和服務提供者在不同 的網路區段內的執行時間。. 28.
(36) 同步長度. 同步長度. 同步長度. 同步長度. 同步長度. 2. 10. 50. 100. 500. 小於 10 KB. 0.362766. 0.411929. 0.486570. 0.500776. 1.227709. 小於 100 KB. 0.377788. 0.416367. 0.508769. 0.563544. 1.375298. 小於 1 MB. 0.556890. 0.619318. 0.698361. 0.812837. 1.630702. 小於 10 MB. 1.525459. 1.882746. 1.929606. 1.962343. 2.753549. 測試檔案大小. 表格 12 : 使用者和服務提供者在不同的網路區段中，2014 Cloud Com 的方法，不同數量的需要. 同步長度，執行一次上傳的動作所花費的時間 (單位:秒). 圖 14 : 使用者和服務提供者在不同的網路區段中，2014 Cloud Com 的方法，不同數量的需要同. 步長度，執行一次上傳的動作所花費的時間 (單位:秒). 29.
(37) 同步長度. 同步長度. 同步長度. 同步長度. 同步長度. 2. 10. 50. 100. 500. 小於 10 KB. 0.388520. 0.374224. 0.524074. 0.646150. 2.269309. 小於 100 KB. 0.427226. 0.440348. 0.584122. 0.735439. 2.302957. 小於 1 MB. 0.574539. 0.687956. 0.772134. 0.914938. 2.519163. 小於 10 MB. 0.933868. 1.024385. 1.145598. 1.414567. 2.884841. 測試檔案大小. 表格 13 : 使用者和服務提供者在不同的網路區段中，2014 Cloud Com 的方法，不同數量的需要. 同步長度，執行一次下載的動作所花費的時間 (單位:秒). 圖 15 : 使用者和服務提供者在不同的網路區段中，2014 Cloud Com 的方法，不同數量的需要同. 步長度，執行一次下載的動作所花費的時間 (單位:秒). 30.
(38) 整理使用者和服務提供者在不同的網路區段中，將沒有使用 POV 的方法、 本篇論文提出的方法以及 2014 Cloud Com 的方法整理成圖 10 和圖 11 的比較 圖表。. 圖 16 : 使用者和服務提供者在不同的網路區段中，比較以上三種方法，執行一次上傳的動作所. 花費的時間 (單位:秒). 31.
(39) 圖 17 : 使用者和服務提供者在不同的網路區段中，比較以上三種方法，執行一次下載的動作所. 花費的時間 (單位:秒). 最後我們分析所有的數據，將本篇論文提出的方法以及 2014 Cloud Com 的 方法的結果除以沒有使用 POV 的時間計算方法之間的差距倍數，分別是 表格 14 和 表格 15，從數據中可以看到本篇論文提出方法，平均上傳差 3.97 倍、下載差 7.91 倍，最差的情況上傳差 6.99 倍、下載差 21.24 倍；而 2014 Cloud Com 方法 的平均上傳差 1.42 倍、下載差 1.88 倍，最差的情況上傳差 2.15 倍、下載差 4.08 倍。從平均來看本論文提出的方法比 2014 Cloud Com 的方法快 8 倍，最差的情 況時我們能夠比 2014 Cloud Com 的方法快超過 20 倍，大大的改善了之前的方 法。. 32.
(40) 測試檔案大小 3 個伺服器 5 個伺服器 7 個伺服器 9 個伺服器 小於 10 KB. 4.349552. 6.403042. 9.584967. 10.246768. 小於 100 KB. 4.914887. 5.805870. 7.843824. 10.077857. 小於 1 MB. 1.700816. 1.838656. 2.211983. 2.254196. 小於 10 MB. 1.171060. 1.396453. 1.860562. 1.886630. 小於 10 KB. 5.391663. 6.917309. 8.205786. 10.054378. 小於 100 KB. 3.913722. 4.049482. 6.132484. 7.121880. 小於 1 MB. 1.648657. 1.805003. 2.210875. 2.283095. 小於 10 MB. 1.104689. 1.341869. 1.754401. 1.762387. 小於 10 KB. 3.140669. 4.783127. 6.736478. 8.234973. 小於 100 KB. 2.029588. 3.387261. 3.957507. 5.451819. 小於 1 MB. 1.261228. 1.730382. 1.864455. 2.289650. 小於 10 MB. 1.189629. 1.433637. 1.462254. 1.573011. 小於 10 KB. 4.650108. 6.329503. 8.658827. 9.820191. 小於 100 KB. 3.095611. 4.539142. 6.491742. 6.835527. 小於 1 MB. 1.694689. 2.620022. 3.079470. 3.751199. 小於 10 MB. 1.177195. 1.553220. 1.727308. 1.827199. 同一個 網路區段 上傳時間. 同一個 網路區段 下載時間. 不同的 網路區段 上傳時間. 不同的 網路區段 下載時間. 表格 14 : 本篇論文提出方法與沒有使用 POV 技術的差距倍數. 33.
(41) 測試檔案. 同步長度. 同步長度. 同步長度. 同步長度. 同步長度. 大小. 2. 10. 50. 100. 500. 小於 10KB. 13.8372. 17.3586. 31.3907. 38.5566. 71.7224. 小於 100KB. 13.5235. 14.5242. 23.7208. 34.1815. 64.7598. 小於 1MB. 3.6664. 4.2624. 4.4613. 5.9472. 13.2474. 小於 10MB. 1.3633. 1.4099. 1.5664. 2.2280. 3.3754. 小於 10KB. 15.4590. 31.8444. 42.2383. 65.7729. 213.5602. 小於 100KB. 9.8285. 18.8967. 24.7455. 41.2323. 131.1957. 小於 1MB. 3.1564. 3.4123. 4.9773. 6.6491. 22.5139. 小於 10MB. 1.3036. 1.5205. 1.6768. 3.2998. 6.3168. 小於 10KB. 5.2368. 5.9465. 7.0240. 7.2290. 17.7228. 小於 100KB. 3.1198. 3.4384. 4.2015. 4.6538. 11.3574. 小於 1MB. 1.6208. 1.8025. 2.0326. 2.3658. 4.7461. 小於 10MB. 1.1089. 1.3687. 1.4027. 1.4265. 2.0017. 小於 10KB. 6.8608. 6.6083. 9.2545. 11.4102. 40.0731. 小於 100KB. 4.8909. 5.0412. 6.6871. 8.4194. 26.3645. 小於 1MB. 2.5471. 3.0499. 3.4231. 4.0562. 11.1682. 小於 10MB. 1.3350. 1.4644. 1.6377. 2.0222. 4.1240. 同一個 網路區段 上傳時間. 同一個 網路區段 下載時間. 不同的 網路區段 上傳時間. 不同的 網路區段 下載時間. 表格 15 : 2014 Cloud Com 提出方法與沒有使用 POV 技術的差距倍數 34.
(42) 第五章. 相關研究. 目前常見的一些雲端儲存系統，像是 Google Drive [1]， Dropbox [2]， iColud [4]， SugarSync [5]， OneDrive [3] 以及 Box [6]，他們沒有提供擁有雙方不可否 認性的 SLAs。欲將伺服器上被錯誤更改的檔案回復，有一種做法是基於將資料 備份到多個伺服器上 [19] [20] [21] [22] [23] [24]。例如 Plutus 是一個加密的儲存 系統，使用者不用依賴檔案伺服器是否能被信任，就可以分享機密的檔案 [19]。 所有的資料都被加密的形式儲存，而且所有金鑰的分配是以分散的方式管理。客 戶端的設備每一次讀寫都更改所有的備份檔，只要有足夠數量的備份檔，客戶端 的設備就可以將損毀的檔案回復。然而，這些系統沒辦法提供任何形式的 POV。 挑戰-回應協定 (challenge-response protocol) 和可檢索的證明 (proofs of retrievability, POR) 被提出來實行檔案系統的遠端完整性證明 [25] [26]。在這些 方法中，驗證者會定期地傳送一個請求給伺服器，伺服器需要計算指定的檔案的 驗證碼(checksum)，然後將結果回傳給驗證者。驗證者接者會拿自己儲存的驗證 碼來比較回傳的結果是否正確。最近提出的一些基於 POR 的遠端完整性證明提 供讓第三方的稽核者可以在遠端的伺服器上檢查資料的完整性 [27] [28]。稽核者 必須是一個被信任的組織(如政府)，才能在資料擁有者以及雲端伺服器之間提供 沒有偏頗的稽核結果。由於稽核是由稽核者來執行，當使用者的數量愈多時就需 要提供更多的伺服器。稽核者通常只會隨機的挑選各別的檔案或是檔案區塊，因 此他們沒有辦法證明所有的檔案都有被稽核過。此外，第三方的稽核者沒辦法偵 35.
(43) 測是否有違反寫入的順序性和讀取的新鮮性。 有些系統考量雲端儲存系統是無法信任的，因此他們提供不需要將資料備份 或使用信任的第三方的方法來偵測檔案的完整性、寫入的順序性以及讀取的新鮮 性是否被違反。SiRiUS 是一個安全的檔案系統，他是實作在分層設計的不安全 的網路之中 [9]。儲存在檔案伺服器上的檔案保留兩個部份：第一個部份包含檔 案的後設資料 (metadata, md-file)，另一個部份是加密後的資料 (d-file)。SiRiUS 利用一個雜湊樹來保證 md-file 的新鮮性。使用者客戶端的設備會建立一個包含 他所有 md-file 的雜湊樹。但是 SiRiUS 所保證的新鮮性只有在 md-file 上，因 此是有可能被發動回捲攻擊，將最新版本的 d-file 替換成較舊的版本。SUNDR 是一個設計成可將資料安全地儲存在不被信任的伺服器上的網路檔案系統。 SUNDR 讓客戶端設備可以偵測任何企圖以未經認証的方式修改檔案的惡意伺服 器操作或是惡意使用者 [10]。SUNDR 使用的協定是實作了一種稱為 fork consistency 的特性，他能夠保證客戶端的設備只要可以看到每個檔案的修改，就 可以偵測完整性和一致性發生的錯誤。客戶端的設備保留一個清單，其包含儲存 伺服器上的檔案五個版本的紀錄。當使用者 U 執行一個檔案操作，他的客戶端 的設備取得一個全域的 Lock，然後為每個使用者和群組下載最新版本的清單。 這些版本清單可以用來偵測是否違反。SUNDR 利用一個稱為 forking semantics 的方法處理違反偵測的問題，這個方法也被其他的研究所使用 [29] [30] [31]。上 述的解決方法保證完整性，並且在客戶端設備中增加一些額外的頻外 36.
(44) (out-of-band) 通訊來實現一致性的相關概念。Venus 系統解決的這個通訊的問題， 透過延遲建立操作的一致性直到他們結束後的一段時間 [32]。總的而言，上述的 這些方法只能支援偵測違反，他們沒有辦法提供一個方法來向第三方證明違反的 發生。 Iris 是一個雲端檔案系統，他提供即時的完整性檢查。他保證消費者可以在 任何時候驗證檢索的檔案是否違最新的版本，因此就可以預防回捲攻擊將檔案回 復成之前的狀態 [11]。Iris 被設計為可以讓企業所使用。一個集中且被信任的入 口網站置於企業信任的邊界，扮演著企業客戶端設備與雲端之間所有通訊的中介 的角色。入口網站保留最近被企業用戶所處理的檔案以及使用者檔案的雜湊樹。 此入口網站佈署了一個 semaphore 以確保共同處理暫留的雜湊樹，這可能會是這 個系統的瓶頸處。雖然他可以提供動態的 POR，Iris 仍無法提供 POV。 Yumerefendi 和 Chase 提出了一個框架，CATS，他能夠提供課責性 (accountability) 於網路儲存系統 [15]。CATS 伺服器從有效的寫入操作讀取回復 的結果來提供密碼學的證據。每一份 CATS 的請求和回復都包含了一個數位簽章， 用以證明發送者的唯一的身份驗證以及證明訊息的完整性。為了支援寫入的順序 性和讀取的新鮮性，當寫入者得到的寫入物件的版本戳章與目前完全一樣，如此 的寫入請求伺服器才會允許。CloudProof 能夠提供基於 epoch 的 POV [33]。使 用者不只能夠偵測完整性的違反、寫入的順序性、讀取的新鮮性，他們還能夠向 第三方提出以上違反事件發生的證明。使用簽章以及鏈雜湊值(chain hashing)， 37.
(45) CloudProof 的架構能夠提供不可否認以及寫入的順序性的特性。新鮮性是由定期 的稽核資料所保證。然而客戶端的設備如果對同一個帳戶做操作，就必須和設備 們交換取得最新的使用者端的證據，否則客戶端的設備就必須保留全部使用者端 的證據。 在我們先前的一篇研究 [34]，我們提出了一個新的方法，客戶端的設備不需 要儲存任何檔案的雜湊值。使用者帳號的檔案，將其雜湊值儲存成 FBHTree 的 格式，存放在服務提供者的伺服器。使用者帳號的原始資料夾和檔案結構利用索 引函式對應成 FBHTree。一個 FBHTree 是設計成儲存於一維的矩陣，因此我們 能夠非常快速的讀取或寫入裡面的內容。並且設計了多個步驟的握手協定，使得 服務提供者可以傳送一個 FBHTree 的片段給客戶端設備來提供即時的稽核以及 POV。實驗結果顯示此方法速度優於之前的研究，效能提升了一至兩個數量級。 這個方法在任何的情況下，都能比正常、沒有 POV 的檔案傳輸所需的兩倍時間 內完成檔案的操作傳輸。雲端儲存的服務提供者能夠使用這篇論文中提出的方法， 在他們的服務層級協議中提供一個互相不可否認的保證。但是本論文提出的方法 能夠同時將檔案備份數份，更增加了檔案的安全性，這是之前這篇論文無法做到 的優點。. 38.
(46) 第六章. 結論. 在這篇論文中，我們提出了一個新的方法，使雲端儲存系統能夠及時地發動 稽核以及 POV。我們考量一個使用者帳號的檔案可能由多個客戶端設備同時操作 存取等等動作的情況。客戶端的設備不需要暫存任何的檔案雜湊值或是檔案狀態 的資訊。 我們利用多個獨立的服務提供者，使用者每一次的操作都向所有服務提供者 發送請求指令，收集所有服務提供者的回傳資料後經比對能夠及時的確認資料的 完整性，而回傳資料上的簽章及密碼學的證據能夠達到 POV 的效果，當發生問 題時使用者和服務提供者雙方能夠以保留的證據稽核確認發生錯誤的是哪一方。 實驗結果顯示，本論文提出的方法相較於之前的雲端儲存即時稽核方法，平均來 看能夠節省 8 倍的時間，遇到最糟的情況能夠節省超過 20 倍的時間。而且本論 文提出的方法解決了之前方法會遭遇的一種最壞的情況，即使用者在長時間未上 線，下一次上線時要同步非常多動作所花的時間。 未來的研究方向，我們希望能夠將 FBHTree 套用到本論文的方法中，藉由 實驗觀察能不能增快 merkle tree 在更新檔案時的速度。另一方面我們希望可以將 系統中的同步伺服器，在本論文中同步伺服器的功能是確保各個設備之間動作的 順序性，若有新的演算法能不需依賴同步伺服器，將能使這個架構更彈性且降低 硬體成本。. 39.
(47) 參考著作 [1] "Google Drive," [Online]. Available: https://www.google.com/intl/en/drive/. [2] "Dropbox," [Online]. Available: https://www.dropbox.com/. [3] "OneDrive," [Online]. Available: https://onedrive.live.com/about/en/. [4] "iCloud," [Online]. Available: https://www.icloud.com/. [5] "SugarSync," [Online]. Available: https://www.sugarsync.com/. [6] "Box," [Online]. Available: https://www.box.com/. [7] S. Kamara and K. Lauter, "Cryptographic cloud storage," in Financial Cryptography and Data Security, Springer, 2010, pp. 136-149. [8] J. Feng, Y. Chen, D. Summerville, W.-S. Ku and Z. Su, "Enhancing cloud storage security against roll-back attacks with a new fair multi-party non-repudiation protocol," in Consumer Communications and Networking Conference (CCNC), 2011 IEEE, IEEE, 2011, pp. 521-522. [9] E.-J. Goh, H. Shacham, N. Modadugu and D. Boneh, "SiRiUS: Securing Remote Untrusted Storage.," in NDSS, vol. 3, 2003, pp. 131-145. [10] J. Li, M. N. Krohn, D. Mazieres and D. Shasha, "Secure untrusted data repository (SUNDR)," in OSDI, vol. 4, 2004, pp. 9-9. [11] E. Stefanov, M. van Dijk, A. Juels and A. Oprea, "Iris: A scalable cloud file system with efficient integrity checks," in Proceedings of the 28th Annual Computer Security Applications Conference, ACM, 2012, pp. 229-238. [12] "Amazon S3 Service Level Agreement," [Online]. Available: https://aws.amazon.com/s3/sla/. [13] "The SLA for individual Azure services," [Online]. Available: https://azure.microsoft.com/en-us/support/legal/sla/. [14] G.-H. Hwang, W.-S. Huang and J.-Z. Peng, "Real-time proof of violation for cloud storage," in Cloud Computing Technology and Science (CloudCom), 2014 IEEE 6th International Conference on, IEEE, 2014, pp. 394-399. [15] A. R. Yumerefendi and J. S. Chase, "Strong accountability for network storage," in ACM Transactions on Storage (TOS), vol. 3, ACM, 2007, p. 11. [16] G.-H. Hwang, J.-Z. Peng and W.-S. Huang, "A mutual nonrepudiation protocol for cloud storage with interchangeable accesses of a single account from multiple devices," in Trust, Security and Privacy in Computing and Communications (TrustCom), 2013 12th IEEE International Conference on, IEEE, 2013, pp. 40.
(48) 439-446. [17] R. C. Merkle, "A digital signature based on a conventional encryption function," in Advances in Cryptology—CRYPTO’87, Springer, 1987, pp. 369-378. [18] D. K. Gifford, "Weighted voting for replicated data," in Proceedings of the seventh ACM symposium on Operating systems principles, ACM, 1979, pp. 150-162. [19] M. Kallahalla, E. Riedel, R. Swaminathan, Q. Wang and K. Fu, "Plutus: Scalable Secure File Sharing on Untrusted Storage.," in Fast, vol. 3, 2003, pp. 29-42. [20] A. Adya, W. J. Bolosky, M. Castro, G. Cermak, R. Chaiken, J. R. Douceur, J. Howell, J. R. Lorch, M. Theimer and R. P. Wattenhofer, "FARSITE: Federated, available, and reliable storage for an incompletely trusted environment," ACM SIGOPS Operating Systems Review, vol. 36, no. SI, pp. 1-14, 2002. [21] G. R. Ganger, P. K. Khosla, M. Bakkaloglu, M. W. Bigrigg, G. R. Goodson, S. Oguz, V. Pandurangan, C. A. Soules, J. D. Strunk and J. J. Wylie, "Survivable storage systems," in DARPA Information Survivability Conference & Exposition II, 2001. DISCEX'01. Proceedings, vol. 2, IEEE, 2001, pp. 184-195. [22] A. Rowstron and P. Druschel, "Storage management and caching in PAST, a large-scale, persistent peer-to-peer storage utility," in ACM SIGOPS Operating Systems Review, vol. 35, ACM, 2001, pp. 188-201. [23] J. D. Strunk, G. R. Goodson, M. L. Scheinholtz, C. A. Soules and G. R. Ganger, "Self-securing storage: protecting data in compromised system," in Proceedings of the 4th conference on Symposium on Operating System Design & Implementation-Volume 4, USENIX Association, 2000, pp. 12-12. [24] A. Bessani, M. Correia, B. Quaresma, F. André and P. Sousa, "DepSky: dependable and secure storage in a cloud-of-clouds," ACM Transactions on Storage (TOS), vol. 9, no. 4, p. 12, 2013. [25] Y. Deswarte, J.-J. Quisquater and A. Saïdane, "Remote integrity checking," Proceedings of IICIS, vol. 140, pp. 1-11, 2003. [26] A. Juels and B. S. Kaliski Jr, "PORs: Proofs of retrievability for large files," in Proceedings of the 14th ACM conference on Computer and communications security, Acm, 2007, pp. 584-597. [27] Y. Zhu, H. Wang, Z. Hu, G.-J. Ahn, H. Hu and S. S. Yau, "Dynamic audit services for integrity verification of outsourced storages in clouds," in Proceedings of the 2011 ACM Symposium on Applied Computing, ACM, 2011, pp. 1550-1557. [28] K. Yang and X. Jia, "An efficient and secure dynamic auditing protocol for data storage in cloud computing," Parallel and Distributed Systems, IEEE 41.
(49) Transactions on, vol. 24, no. 9, pp. 1717-1726, 2013. [29] C. Cachin, A. Shelat and A. Shraer, "Efficient fork-linearizable access to untrusted shared memory," in Proceedings of the twenty-sixth annual ACM symposium on Principles of distributed computing, ACM, 2007, pp. 129-138. [30] M. Majuntke, D. Dobre, M. Serafini and N. Suri, "Abortable fork-linearizable storage," in Principles of Distributed Systems, Springer, 2009, pp. 255-269. [31] C. Cachin and M. Geisler, "Integrity protection for revision control," in Applied Cryptography and Network Security, Springer, 2009, pp. 382-399. [32] A. Shraer, C. Cachin, A. Cidon, I. Keidar, Y. Michalevsky and D. Shaket, "Venus: Verification for untrusted cloud storage," in Proceedings of the 2010 ACM workshop on Cloud computing security workshop, ACM, 2010, pp. 19-30. [33] R. A. Popa, J. R. Lorch, D. Molnar, H. J. Wang and L. Zhuang, "Enabling Security in Cloud Storage SLAs with CloudProof.," in USENIX Annual Technical Conference, vol. 242, 2011. [34] G.-H. Hwang and H.-F. Chen, "Efficient Real-time Auditing and Proof of Violation for Cloud Storage Systems," in 9th IEEE International Conference on Cloud Computing, San Francisco, USA, 2016.. 42.
(50)
相關文件
– The futures price at time 0 is (p. 275), the expected value of S at time ∆t in a risk-neutral economy is..
• Instead of uploading and downloading the dat a from cloud to client for computing , we shou ld directly computing on the cloud ( public syst em ) to save data transferring time.
The proof is suitable for R n if the statement is that every closed set in R n is the intersection of a countable collection of open sets.. All we need is to change intervals
EtherCAT ® 為德國 Beckhoff Automation GmbH 取得許可證之專利技術，亦為註冊商標。. EtherNet/IP™為
In Section 3, the shift and scale argument from [2] is applied to show how each quantitative Landis theorem follows from the corresponding order-of-vanishing estimate.. A number
To proceed, we construct a t-motive M S for this purpose, so that it has the GP property and its “periods”Ψ S (θ) from rigid analytic trivialization generate also the field K S ,
Given a shift κ, if we want to compute the eigenvalue λ of A which is closest to κ, then we need to compute the eigenvalue δ of (11) such that |δ| is the smallest value of all of
7.7 Representation of Functions by Power Series 7.8 Taylor and Maclaurin Series... Thm 7.4 (Absolute Value Thoerem) Let {a n } be a sequence of
