以詢答達成有效率的雲端儲存即時稽核系統

全文

(1)國立臺灣師範大學資訊工程研究所碩士論文. 指導教授：黃冠寰博士. 以詢答達成有效率的雲端儲存即時稽核系統. Real-time Auditing and Proof of Violation for Cloud Storage Systems Based on Transponder. 研究生：江浩群撰中華民國 105 年 7 月.

(2) 摘要由於網路科技的發達，雲端技術的應用也日趨增加。如：政府單位、私人企業及律師事務所等。各種不同的單位都可以把自身的資料儲存在雲端上面。使用雲端的好處除了可以在各種不同的地方使用同一份資料，還可以使多人共同編輯一份資料。雲端發展快速的同時也伴隨著安全性的問題，假設我們放在雲端上的資料可能被別人竊取、消失、或者被提供雲端服務的公司所洩漏，是否可以提出證據證明有發生過上述狀況？本實驗室過去研究提出一個方法來解決此問題，製作出了可以成為有效法律證據的電子證據。但該方法的證據都必須等到一段時間之後才能做稽核的動作，如果資料處理時發生錯誤必須等到稽核的時候才會發現。於是本研究把上述技術再加入即時稽核（Real-time Auditing），把過去在特定時間才能做稽核的問題解決。. 關鍵字：即時稽核、雲端儲存、雲端安全、不可否認性、證明違約. i.

(3) 目錄摘要................................................................................................................................. i 圖目錄.......................................................................................................................... iii 表目錄........................................................................................................................... iv 第一章緒論.................................................................................................................. 1 第一節簡介雲端運算.......................................................................................... 1 第二節雲端上的信任問題.................................................................................. 2 第三節章節介紹.................................................................................................. 3 第二章 POV 協定......................................................................................................... 4 第一節 Proof of Violation .................................................................................... 4 第二節雜湊值與雜湊鏈...................................................................................... 4 第三節 C&L Scheme & A REAL-TIME POV SCHEME.................................... 6 第三章詢答式即時稽核系統...................................................................................... 8 第一節系統架構.................................................................................................. 8 第二節訊息交換協定.......................................................................................... 9 第三節稽核........................................................................................................ 12 第四節證據縮減................................................................................................ 15 第四章第五章第六章第七章. 實驗結果........................................................................................................ 19 相關研究........................................................................................................ 27 結論................................................................................................................ 28 參考著作........................................................................................................ 29. ii.

(4) 圖目錄圖二-1 圖三-1 圖三-2 圖三-3 圖三-4 圖三-5. 雜湊鏈示意圖 ................................................................................ 6 系統架構 ........................................................................................ 8 訊息交換順序 ................................................................................ 9 訊息交換示意圖 .......................................................................... 10 完整證據 ...................................................................................... 13 Partial Hash Chain ........................................................................ 13. 圖三-6 圖三-7 圖三-8 圖三-9 圖三-10. 錯誤的 Partial Hash Chain ........................................................... 14 證據縮減前的證據 ...................................................................... 15 證據縮減後的證據 ...................................................................... 15 證據縮減範例 .............................................................................. 17 分割證據前後 .............................................................................. 18. iii.

(5) 表目錄表格表格表格表格表格表格. 四-1 讀取寫入比較表格(1 個 hop)................................................... 19 四-2 讀取寫入比較表格(13 個 hops) ............................................... 19 四-3 稽核所需時間 .......................................................................... 20 四-4 平均 Partial Hash Chain 長度-1 ................................................ 21 四-5 平均 Partial Hash Chain 長度-2 ................................................ 21 四-6 平均 Partial Hash Chain 長度-3 ................................................ 22. 表格表格表格表格表格. 四-7 平均 Partial Hash Chain 長度-4 ................................................ 22 四-8 平均 Partial Hash Chain 長度-5 ................................................ 23 四-9 平均 Partial Hash Chain 長度-6 ................................................ 23 四-10 平均 Partial Hash Chain 長度-7 .............................................. 24 四-11 平均 Partial Hash Chain 長度-8 .............................................. 24. 表格四-12 平均 Partial Hash Chain 長度-9 .............................................. 25 表格四-13 平均 Partial Hash Chain 長度-10 ............................................ 25 表格四-14 Partial Hash Chain 平均長度 ............................................... 26. iv.

(6) 第一章緒論第一節簡介雲端運算雲端運算(Cloud Computing)，是近代常使用的網路服務。目前雲端服務大至上分為三種服務模式：基礎設施即服務（Infrastructure as a Service，IaaS）、軟體即服務（Software as a Service，SaaS）、平台即服務（Platform as a Service，PaaS）。 IaaS 提供了使用者基礎的運算資源，例如處理器、儲存容量等等。如：Amazon GCE(Google Compute Engine)[1]、EC2[2]等；SaaS 提供使用者軟體服務，但不需控制作業系統或硬體端，只需要透過網際網路且不經安裝即可使用的服務方式，如：iCloud 及 Gmail；PaaS 提供使用者運作應用程式的環境，使用程式語言或程式庫等服務，但並不需要控制作業系統及硬體端，介於 IaaS 和 SaaS 之間，如： GAE（Goole App Engine）[3]。因此客戶端對三者之間的選擇如下述：IaaS 僅基礎建設服務，但是與上述應用程式服務是無關的。對於客戶端（Client）而言，假如客戶端已經寫了很多程式碼或軟體套件，倘若要安裝並運行在雲中，那麼客戶端就需要找 IaaS 層的服務。PaaS 則提供了一個應用程式開發的服務環境，假如客戶端有還沒建置軟體或想從頭開始自行開發建置，那麼客戶端應該去 PaaS 層尋找相關服務，因為這些軟體可能太昂貴或太複雜，使用 PaaS 服務將可大量降低成本、風險。SaaS 則提供了一個完整的應用程式作為服務，本文討論的雲端儲存空間應屬於 SaaS 層級。熱門的雲端儲存系統包括 Google Drive[4]、Dropbox[5]、 SugarSync[6]、SkyDrive[7]及 box[8]。 1.

(7) 第二節雲端上的信任問題在雲端服務的快速發展下，雲端服務面臨了使用者對雲端系統的信任度的問題。當使用者把一個檔案丟給雲端處理時，雲端服務是否真的是照使用者要求的方式去處理？存放在雲端儲存空間的檔案是否被竄改、或者遺失？重要的檔案是否會曝光？現行的雲端服務幾乎都會遇到這類型的問題。目前並沒有非常有效的方式去解決使用者對雲端不信任的問題[20][21]。現行系統大多強迫使用者相信雲端服務，頂多只留下了活動記錄 (Log)，或是單方面的計算結果，皆無足夠效力成為具有法律效用的「證據（Cryptographic. proof）」。使用者使用雲端服務時. 只能選擇相信雲端服務提供商（Service Provider），這對使用者是不公平的，使用起來十分沒有保障。萬一重要的文件被雲端服務提供商遺失或者竄改，使用者的損失可能會十分慘重。為了解決這類型的問題，過去研究提出了證明違約演算法（Proof of Violation，簡稱 POV）[9]，讓使用者及雲端服務提供商製造具有法律效力的證據。然而只是提出強而有力的證據是不夠的，因為有些情況必須在取得服務的同時，使用者就必須知道該次取得的服務內容是不是可信任的。假設一份兩間公司要簽約的文件放置在雲端儲存空間被雲端服務提供商竄改，等到兩間公司將文件印出，並簽約完成以後才發現文件內容被竄改，很可能對兩間公司造成巨大的損失。上述問題發生原因在於使用者必須等到稽核的時候才能知道文件是否被竄改，因此證明違約演算法必須具備即時稽核之功能，在每次提供服務的同時就做稽核。本實驗室過去提出的以部分雜湊樹達成有效率的雲 2.

(8) 端儲存系統即時稽核[10]研究已經能夠達到即時稽核的功能，不過該系統架構須架設同步伺服器，對該研究的介紹會在第二章第二節詳細討論。本研究的作法則不須架設同步伺服器。. 第三節章節介紹首先在第二章我們會介紹 POV 協定與其發展，說明為何需要 POV、現行的技術又為如何，及 POV 協定可能會遇到的問題。第三章會介紹本篇論文系統的做法，包含系統的架構、證據的產生、證據的縮減以及如何加快稽核。第四章為實驗結果及與其他方法的比較。第五章為相關的研究。第六章則為結論以及其未來的發展。. 3.

(9) 第二章 POV 協定第一節 Proof of Violation 由於我們沒辦法知道雲端服務提供商是否會遺失我們所儲存的檔案，又或者對我們儲存的檔案做惡意的修改，所以本實驗室過去研究提出在上個章節所提到的違約演算法。該演算法除了可以提供具有法律效用的「證據」，還有三項特性，並保障雲端儲存空間的四種安全性質。證明違約演算法有三項特性，第一，需要先定義其屬性(Properties)；第二，訊息要留做證據，且必須具有法律效力，每一則訊息都必須有使用者及服務提供商兩方的簽章，證明雙方都同意此訊息內容；第三，具有稽核(Audit) 機制，根據具有法律效力的證據，可證明是否有達到合約內容，稽核可以檢測是否有證明違約，並且也可以反駁若其中一方做出的虛假指控。雲端儲存空間上四種安全性質：保密性（Confidentiality）、完整性（Integrity）、寫入循序性（Write Serializability）以及讀取新鮮性（Read Freshness），合稱為 CIWF。使用者可以偵測雲端儲存空間是否違反 CIWF 來確保自身檔案的安全性。這個系統具有不可否認性，因為使用者所做的請求以及服務提供者維護資料的狀態都會被綁定在證據裡面。. 第二節雜湊值與雜湊鏈本研究提及之雜湊值(Hash Value)為將一筆資料放入 SHA256[22]方程式中 (此動作以下稱為取雜湊值)得到的值，稱為該資料的雜湊值。SHA256 為一不可. 4.

(10) 逆的方程式，且碰撞率極低，所以一般把 SHA256 當作一對一不可逆的方程式(檔案對映到檔案的雜湊值)。應用面以雲端儲存為例，使用者把資料存至雲端儲存空間後，使用者會留下該資料的雜湊值。日後使用者把資料從雲端下載後，使用者把下載的資料取雜湊值，並與當初保留的雜湊值比對，即可知道下載的資料與當初儲存至雲端儲存空間的資料是否相同，以保證資料的完整性。雜湊鏈(Hash Chain)為一將資料取雜湊值後鏈結起來的技術，可以保證資料的完整性及寫入的順序性。使用者向雲端寫入新的資料時，新寫入的資料會包含上一筆寫入的資料的雜湊值，而第一筆資料會包含一個初始化的雜湊值(Initial Hash，簡稱 IH)，藉此將每筆資料串接成雜湊鏈。如此一來使用者只需保留最後一筆資料的雜湊值即可保證雜湊鏈上每筆資料的完整性，最後一筆資料的雜湊值稱為該雜湊鏈最新的雜湊值(Chain Hash，簡稱 CH)。以圖二-1 為例，最後一筆寫入的資料為 Data3，由於使用者手中握有雜湊鏈最新的雜湊值（Data3 的雜湊值），因此可以確保 Data3 的完整性。又因為 Data3 中有 Data2 的雜湊值，Data2 的雜湊值表示為 Hash(Data2)，因此可以向前一筆資料(Data2)驗證其完整性，依此類推。由於寫入 Data3 必須包含 Data2 的雜湊值，因此 Data3 必須在 Data2 寫入後才能寫入，依此類推可排列出資料寫入的順序性，以圖二-1 為例，寫入的順序為 Data1、Data2、Data3。圖二－１中箭頭與括弧表示雜湊值為哪一筆資料的雜湊值。. 5.

(11) IH. Data1. Data2. Data3. Hash(IH). Hash(Data1). Hash(Data2). 圖二-1. 第三節. 雜湊鏈示意圖. C&L Scheme & A REAL-TIME POV SCHEME. 過去的稽核必須蒐集一段時間的證據再進行(稱為 Epoch Based Auditing)，無法在每次的服務請求同時做稽核的動作。本研究指的即時稽核是指在每次的服務請求同時就可以做稽核的動作，達到即時(Real-time)的效果。過去相關研究[11]，該方法不能抵禦來自雲端服務提供商的惡意攻擊(回捲式攻擊(roll-back attack[12]) 或是 replay attack[13])。雲端服務提供商回復版本較舊的資料以及相關的電子簽章. 去否認雲端服務提供商遺失最新版本的資料。因此 C&L Scheme[14]被提出，利用雜湊鏈結搭配嵌入 LSN（Local. Sequence. Number）、客戶識別名稱（ClientID）. 以及時代識別名稱（EpochID）於證據中，確保了雙方的不可否認性可以成功抵禦服務提供者發起的回捲式攻擊。但是此種做法的稽核必須呼叫所有的使用者上線，並取得所有使用者的最後一筆證據，因此並不能達到即時稽核。本實驗室過去提出的以部分雜湊樹達成有效率的雲端儲存系統即時稽核[10]研究已經能夠 6.

(12) 達到即時稽核的功能，該篇論文中提出了一個機制，將用戶整個資料夾以及檔案以雜湊樹(hash tree)方式儲存，稱為 Merkle tree，以及利用雜湊樹產生之 root hash 來確保整個架構的唯一性，而雲端服務提供商保存著每次與客戶端交換訊息所產生的證據，並交換 root hash，確保雙方狀態是一致的，用戶讀到的檔案也為最新且正確的。以上狀況在單一用戶是可行的，但是當有用戶使用其他設備時，目前資料夾的狀態就必須更新至其他設備，因此有一個同步伺服器的機制，讓其他設備先暫時無法向伺服器溝通，必須等待正在請求服務的設備與伺服器完成一個完整的運作(讀取或者寫入的動作 )，才可以解開同步伺服器，避免造成廣播（broadcasting）不完備的情形。雖然同步伺服器的機制會增加其他設備等待的時間，但是藉此讓許多設備透過同步伺服器之中交換證據，等到要做操作時才會更新設備所儲存之 Merkle tree，可以降低許多時間，以達到真正的即時稽核本篇的做法與上述兩個系統比起來更加完善，既可以達到即時稽核，又不需要架設同步伺服器的機制、Merkle tree 跟廣播（broadcasting）。比起 C&L Scheme，架構一樣卻可以達到即時稽核，且使用者不需要額外產生 LSN（Local. Sequence. Number）；比起以部分雜湊樹達成有效率的雲端儲存系統即時稽核，架構上更加輕量化，也就是說不需要架設同步伺服器及建立 Merkle tree。. 7.

(13) 第三章詢答式即時稽核系統第一節系統架構. Service Provider. A. B. C. 圖三-1. K. 系統架構. 本研究提出詢答式即時稽核系統(Transponder POV)，主要運用於雲端儲存空間，可以在每次讀寫服務的時候提出證據表明服務提供商沒有遺失、或者惡意的竄改客戶端所存放的資料。圖三-1 中 A~K 為客戶端，雲端服務提供商(Service Provider)，以下簡稱 SP。本研究的系統架構並沒有考慮使用者權限的問題（Access Control）[15]。假設個客戶端都可以任意使用雲端儲存空間上的任何檔案。使用者向雲端服務提供商請求服務時，雙方及上一為使用者會經過一個六步驟的訊息交換協定以產生該次服務請求的證據。雲端服務提供商保留所有客戶端. 8.

(14) 的所有的證據形成的雜湊鏈；每個客戶端保留自己最後一次服務請求的動作（Operation）所產生的證據。. 第二節訊息交換協定. SP. A. B. 1. Qs 2. Rs 5. RR. 3. Qc 4. Rc. 6. Ack. 圖三-2. 訊息交換順序. 圖三-2 為訊息交換的順序，A 為正在請求服務的裝置，B 則為上一個請求完服務的裝置，1~6 為每個步驟所傳送的訊息，稍後會介紹 1~6 訊息的內容。本協定有兩項假設：第一項，所有的客戶端都必須是誠實的。假設使用者透過不同的裝置讀寫雲端儲存空間。由於使用者並不希望自己的檔案被竄改或者遺失，所以必須誠實的把最後一次的證據交付給下一個使用雲端服務的裝置；第二項，請求服務的時候，上一次請求服務的裝置必須在線上。由圖三-2 很明顯的看出訊息交換協定中裝置 A 需要與上一個請求完服務的 9.

(15) 裝置 B 交換訊息。本系統在稽核時只需要最後一個請求服務的裝置在線上即可，比起 C&L Scheme，C&L Scheme 在稽核的時候，所有的使用者都必須上線，並且把每位使用者的最後一筆的證據繳交以進行稽核。在圖三-3 的示意圖中可以看出本研究只需要跟上一次請求服務的裝置交換訊息，不需要跟其他的裝置進行交換訊息。. Service Provider 1.Qs. 2.Rs. 5.RR 6.Ack. 3.Qc. B. A. C. K. 4.Rc. 圖三-3. 訊息交換示意圖. 訊息交換協定的六個步驟： Step 1：Qs=(OP,ClientIDA,[OPi,ClientIDA]pri(A)) 當裝置 A 欲請求服務時，發送訊息 Qs 給 SP。其中 OP(Operation)表示欲請求的動作(上傳或者下載檔案)，如果 OP 為上傳動作，則 OP 內必須包含檔案的雜湊值(FileHash，簡稱 FH)。ClientIDA 表示裝置 A 的 ID，最後把上述都進行簽章。 10.

(16) Step 1.1：如果是上傳動作，檔案則在這一步進行上傳。 Step 2：Rs=(Qs,ClientIDB,CHi-1,FHi,[Qs,ClientIDB,CHi-1,FHi]pri(s)) SP 收到服務請求後，將雜湊鏈最新的雜湊值(CHi-1)、上一個請求服務的裝置的 ID(ClientIDB)、 OPi 內所讀寫的 File Hash (FHi)以及 Qs 簽章後傳回給裝置 A。由於檔案上傳已經在 Step 1 結束了所以不論是上傳或者下載檔案的動作，SP 都可以在這個 Step 拿到最新的 File Hash。 Step 2.1：如果是下載動作，檔案則在這一步進行下載。 Step 3：Qc=(Rs,[Rs]pri(A)) 裝置 A 收到 Rs 後根據裡面的訊息可以找到上一個請求服務的裝置 B。裝置 A 把 Rs 簽章後傳給裝置 B，藉此詢問裝置 B 是否為最後一個請求服務的裝置，且該訊息是由 SP 告訴裝置 A 說裝置 B 是最後一個請求服務的裝置。 Step 4：Rc=(islast,Qc,CHi-1,[islast,Qc,CHi-1]pri(B)) 若裝置Ｂ裝置為最後一個請求服務的裝置，則 B 手中握有的證據的雜. *註：最後一個請求服務的裝置永遠只有一位。由於本協定每次的動作都必須詢問上一個請求服務的裝置，因此如果某裝置請求服務完成後，直到下一個請求服務的裝置詢問之前，該裝置都會是最後一個請求服務的裝置。如果該裝置被詢問了，那麼該裝置就會知道自己已經不是最後一個請求服務的裝置。. 11.

(17) 湊值即為雜湊鏈最新的雜湊值(CHi-1)，B 收到詢問後回傳給裝置 A 表明自己是否為最後一個裝置(islast)，且把 Qc 跟雜奏鏈最新的雜湊值 (CHi-1)簽章後回傳給裝置 A，使得裝置 A 能夠驗證 SP 給的訊息是否有誤。若裝置 B 不為最後一個請求服務的裝置，則表示 SP 在 Step1 中給的訊息有誤，回至 Step1 直到 SP 給出正確訊息 Step 5：RR=(Rc,[Rc]pri(A)) 裝置 A 收到 Rc 後即可驗證 Step 2 中 SP 給的雜湊鏈最新的雜湊值(CHi1)是否正確。因此. SP 無法進行回捲式攻擊。驗證完成後把 Rc 簽章後. 回傳給 SP。 Step 6：Ack=(RR,[RR]pri(s)) SP 收到 RR 後簽章回傳承認訊息(Ack)給裝置 A，至此證據交換完成，雙方皆以 Ack 當最作後一筆的證據。由於 Ack 都經過雙方簽章，因此雙方都有不可否認性。此時此 Ack 的雜湊值為此雜湊鏈最新的雜湊值，裝置Ａ為最後一個請求服務的裝置。. 第三節稽核由上述六個步驟產生的證據可得知該證據該次動作(OP)讀寫的檔案、檔案的雜湊值及上一次讀寫動作的證據的雜湊值。訊息經過六個步驟完成後，裝置 A 的證據成為了所有證據的最後一筆，這個時候裝置 A 會發動稽核。稽核發動時，雲端服務提供商會從最後一筆證據開始往前尋找到跟最後一筆證據讀寫相同檔案 12.

(18) 的證據，此串證據稱為 Partial Hash Chain。圖三-4 表示 SP 中所有的證據，F1、F2、F3 為該證據讀取或寫入的檔案的名稱，IH 為證據的初始值(Initial Hash)，IH 後依序為第一筆證據、第二筆證據…… 以此類推，證據內的長方形框框為上一筆證據的雜湊值，箭頭與括弧表示雜湊值為哪一筆資料的雜湊值。由於稽核時不需要用到全部的證據，所以 SP 只需傳送需要稽核的部分，如圖三-5 表示的 Partial Hash Chain。. IH. F1. F2. F3. 圖三-4. F1. F2. 完整證據. F2. 圖三-5. F2. F1. F2. Partial Hash Chain. 裝置 A 收到 Partial Hash Chain 後，由於自己手中握有雜湊鏈最新的雜湊值，因此 SP 無法任意的傳送錯誤的或者更早之前的證據發動回捲攻擊。從最後一筆證據向前驗證找到跟最後一筆證據服務相同檔案的證據後，即可根據該證據得知要稽核的最新的 File Hash。以圖三-4 及圖三-5 為例，裝置 A 下載檔案 F2 後欲稽核所拿到的檔案是否為 13.

(19) 最新的版本，步驟如下： Step 1：訊息交換完成後(如圖三-4)SP 找出 Partial Hash Chain(如圖三-5)，並傳回 Partial Hash Chain 給裝置 A。 Step 2：裝置 A 收到 Partial Hash Chain 後由於自己擁有最後一筆證據，可驗證其是否正確。由最後一筆證據內的 Rs 可得知上一筆證據的雜湊值，可驗證上一筆資料是否正確，依此類推至 Partial Hash Chain 的第一筆證據。途中每一筆證據都必須檢查是否都沒有包含該次要稽核的檔案。否則 Partial Hash Chain 的第一個證據就不為最新的 File Hash。 Step 3：比對所拿到的檔案的雜湊值(File Hash)與 Partial Hash Chain 的第一個證據紀錄的 File Hash 是否吻合。至此，稽核結束。. F2. F3. 圖三-6. F2. F1. F2. 錯誤的 Partial Hash Chain. 圖三-6 為一個 Server 傳錯誤的 Partial Hash Chain 的例子。因為欲稽核的檔案 F2 在 Partial Hash Chain 的第三筆證據又有做讀寫的動作，所以 Partial Hash Chain 的第一筆證據不為該檔案最新的雜湊值。因此，為了避免從 SP 拿出較舊版本的檔案及較舊版本的 File Hash 給使用者，Step 2 中檢查每個證據所讀寫的檔案是必須的。 14.

(20) 第四節證據縮減保存所有證據一定可以發動且完成稽核的動作，不過事實上因為證據的數量會無限成長，所以雲端服務提供商希望可以做證據縮減(Short cut)。假設我們可以產生出所有檔案的 Partial Hash Chain，就可以對所有的檔案做稽核的動作，因此雲端服務提供商只需要保存可以讓稽核順利完成的部份證據即可。由稽核的特性我們可以知道 Partial Hash Chain 都是由最後一筆證據開始往前驗證而產生的。比較直覺的解法是從最後一筆證據開始往前選取，直到選取的證據讀寫的檔案包含所有的檔案後，剩下沒被選取到的檔案即是可以刪除的檔案。上述方法留下來的證據即可產生所有檔案要稽核時所需要的 Partial Hash Chain，圖三-7 及圖三-8 為其示意圖。在圖三-7 中，任何稽核皆只會向前驗證到第三筆證據，並不會在向前做驗證的動作，因此第三筆證據前面的證據可以刪除，如圖三-8。. IH. F1. F2. 圖三-7. F3. F3. F1. F2. 證據縮減前的證據. F2. 圖三-8. F2. F1. F2. 證據縮減後的證據. 假設 SP 內保存的檔案非常多，為了檢查證據縮減後留下的證據包含所有的 15.

(21) 檔案，發動證據縮減可能會耗時一段時間而卡住服務。且證據縮減也不能保證每次都可以成功。假設第一筆證據所服務的檔案之後都沒有再被讀寫過，則沒辦法刪除任何一筆證據，也就是證據縮減失敗的狀況。又因為沒辦法確保每次證據縮減都可以成功，所以何時要發動證據縮減也是一個問題。由於從最後一筆證據來做證據縮減會遇到上述的問題，因此我們換了一個方向來做證據縮減。從第一筆證據檢查該證據是否可以刪除，如此一來可以先快速的檢查證據縮減是否會失敗以決定是否發動證據縮減，並且把檢查的步驟打散在每次的請求服務動作以提升速度，方法如下： Step 1：每次 SP 產生新的證據時，SP 會把上一個讀寫該次產生的證據所讀寫的檔案的證據標示為可刪除。這邊指的標記可以是產生一個對映證據的陣列或者其他方法，只要沒有更改證據內容皆可。 Step 2：檢查第一筆證據是否可以刪除(IH 在第一筆證據刪除時一併刪除)。倘若第一筆證據可以刪除則刪除，持續檢查下一筆證據是否可以刪除，直到無法刪除。至此，證據縮減結束。圖三-9 為一證據縮減的範例，圖三-9(a)為 SP 的初始狀態，SP 內共有 F1、 F2、F3 共三個檔案，四個證據，閃電符號即是標記為可刪除的標記。以圖三-9(a) 為例，第二筆證據讀寫了檔案 F2 後，在第四筆證據又對檔案 F2 進行讀寫，因此檔案 F2 最新的雜湊值應記錄在第四筆證據，第二筆證據應標示為可刪除，如圖中的閃電標記。圖三-9(b)為圖三-9(a)狀態後某個裝置讀寫了檔案 F3，SP 加入該 16.

(22) 次讀寫 F3 的證據後，將上一次讀寫 F3 的證據標示為可刪除，由於第一筆證據還無法刪除，所以無法進行證據縮減，五個證據皆須保留。圖三-9(c)為圖三-9(b)狀態後有另一個裝置讀寫檔案 F1，SP 加入該次讀寫 F1 的證據後，將上一次讀寫 F1 的證據標示為可刪除，此時證據的前三筆皆標示為可刪除，因此只需保留後三筆證據即可完成所有檔案的稽核。證據縮減完後，SP 保留的證據如圖三-9(c)。. IH. F1. F2. F3. F2. 圖三-9(a)證據縮減範例-1(初始狀態). IH. F1. F2. F3. F2. F3. 圖三-9 (b)證據縮減範例-2(讀寫F3後). F2. F3. F1. 圖三-9 (c)證據縮減範例-3(讀寫F1後). 圖三-9. 證據縮減範例. 即便有了上述的證據縮減方法，還是可能遇到稽核的效能下降的問題。假設 SP 內有 N 個檔案，因為 SP 保存的證據讀寫的檔案必須包含所有的檔案，所以 SP 最少需儲存 N 個證據。當 N 越大時，每次稽核所產生的 Partial Hash Chain 平 17.

(23) 均長度就會變長，稽核的效能就會越低。原本證據只串接成一條雜湊鏈，現在將它分割成 K 條雜湊鏈，將每個檔案的檔名取 Hash 再取 k 的餘數，使得每一個檔案都對應到唯一的雜湊鍊上。圖三-10 為證據分割前後的示意圖，如圖三-10(b)分割後，只要有讀寫檔案 F1 的證據都串接在第一條雜湊鏈上。. IH. F1. F2. F3. Fk. 圖三-10(a) 分割證據前. IH. F1. IH. F1 F2. F2. 共K條. IH. FK. Fk 圖三-10(b) 分割證據後圖三-10 分割證據前後. 18.

(24) 第四章實驗結果表格四-1 與表格四-2 為 Non-POV 與本研究寫入及讀取所耗費的時間比較表格，兩系統皆在相同的 Hop 數下運作，表格中時間單位為毫秒(in ms)。 READ operation. 10kB. 100kB. 1MB. 10MB. Non-POV. 14.9. 15.7. 25.1. 115. Transponder POV. 218.2. 219. 228.5. 362.2. WRITE operation. 10kB. 100kB. 1MB. 10MB. Non-POV. 14. 14.5. 24. 112.4. Transponder POV. 217. 218.4. 227.3. 360.7. 表格四-1 讀取寫入比較表格(1 個 hop). READ operation. 10kB. 100kB. 1MB. 10MB. Non-POV. 231. 292.3. 742.3. 4938.9. Transponder POV. 506.7. 546.2. 961.9. 5630.3. WRITE operation. 10kB. 100kB. 1MB. 10MB. Non-POV. 229.9. 290.1. 729.4. 4920.7. Transponder POV. 504.5. 544.6. 960.3. 5619.8. 表格四-2 讀取寫入比較表格(13 個 hops). 本研究(Transponder POV)與 Non-POV 存取檔案一次所花費的時間比較圖表，如表格四-1 還有表格四-2。實驗的方法是將讀取或寫入的動作重複一百次之後取其平均值。Non-POV 為單純的檔案讀寫；本篇系統在上述表格的數據， Partial Hash Chain 平均長度是 100 個證據。由上述表格可以發現，本研究在傳輸的檔案越大的時候，造成的負擔越小，因此適合用在讀寫的檔案容量較大的雲端儲存環境。. 19.

(25) 表格四-3 為各種長度的 Partial Hash Chain 所需的稽核時間，長度跟時間比大約成線性成長。一個證據大約需要 2ms 來稽核。表格四-3 稽核所需時間. Partial Hash Chain 的長. 100. 1000. 10000. 20000. 198. 1812. 15459. 30978. 度時間(in ms). Partial Hash Chain 會影響稽核的時間，其長度越短越好，如表四-3 所呈現。現實中我們無法控制使用者每次讀寫的檔案，即我們無法控制每次稽核所需的 Partial Hash Chain 長度。檔案讀寫越頻繁的檔案 Partial Hash Chain 就會越短，反之則越長；短可能短至 Partial Hash Chain 長度為 1 個證據，長可能長至 Partial Hash Chain 長度為無線大。由於無法控制檔案讀寫的頻率，且讀寫頻率太過極端也毫無意義，所以本實驗設計了檔案讀寫頻率皆相同的狀況。表格四-4 至表格四-13 為實驗結果。表格四-4 至表格四-13 分別是讓每一條證據上面對映到 100 及 1000 個檔案，分別做一萬、十萬、一百萬、一千萬、一億次把每次 Partial Hash Chain 的長度記錄下來。檔案的讀寫採取隨機存取，每個檔案被讀寫到的機率皆相同. 20.

(26) 表格四-4 平均 Partial Hash Chain 長度-1. 共有 100 檔案，做 10,000 次平均 Partial Hash Chain 長度 99.53 Partial Hash Chain 長度. 發生次數. 百分比. 0 到 100. 6342. 63.42. 長度是 100 到 200. 2324. 23.24. 長度是 200 到 300. 840. 8.4. 長度是 300 到 400. 309. 3.09. 長度是 400 到 500. 96. 0.96. 長度是 500 到 600. 59. 0.59. 長度是 600 到 700. 18. 0.18. 長度是 700 到 800. 8. 0.08. 長度是 800 到 900. 2. 0.02. 長度超過 900. 2. 0.02. 長度是. 表格四-5 平均 Partial Hash Chain 長度-2. 共有 100 檔案，做 100,000 次平均 Partial Hash Chain 長度 99.97 Partial Hash Chain 長度. 發生次數. 百分比. 0 到 100. 63,124. 63.12. 長度是 100 到 200. 23,324. 23.32. 長度是 200 到 300. 8,567. 8.57. 長度是 300 到 400. 3,177. 3.18. 長度是 400 到 500. 1,161. 1.16. 長度是 500 到 600. 403. 0.4. 長度是 600 到 700. 146. 0.15. 長度是 700 到 800. 61. 0.06. 長度是 800 到 900. 20. 0.02. 長度超過 900. 17. 0.02. 長度是. 21.

(27) 表格四-6 平均 Partial Hash Chain 長度-3. 共有 100 檔案，做 1,000,000 次平均 Partial Hash Chain 長度 100.00 Partial Hash Chain 長度. 發生次數. 百分比. 0 到 100. 629,668. 62.97. 長度是 100 到 200. 235,136. 23.51. 長度是 200 到 300. 85,848. 8.58. 長度是 300 到 400. 31,296. 3.13. 長度是 400 到 500. 11,471. 1.15. 長度是 500 到 600. 4,110. 0.41. 長度是 600 到 700. 1,568. 0.16. 長度是 700 到 800. 572. 0.06. 長度是 800 到 900. 203. 0.02. 長度超過 900. 128. 0.01. 長度是. 表格四-7 平均 Partial Hash Chain 長度-4. 共有 100 檔案，做 10,000,000 次平均 Partial Hash Chain 長度 100.00 Partial Hash Chain 長度. 發生次數. 百分比. 0 到 100. 6,304,031. 63.04. 長度是 100 到 200. 2,342,104. 23.42. 長度是 200 到 300. 858,502. 8.59. 長度是 300 到 400. 314,295. 3.14. 長度是 400 到 500. 114,609. 1.15. 長度是 500 到 600. 42,268. 0.42. 長度是 600 到 700. 15,375. 0.15. 長度是 700 到 800. 5,536. 0.06. 長度是 800 到 900. 2,064. 0.02. 長度超過 900. 1,216. 0.01. 長度是. 22.

(28) 表格四-8 平均 Partial Hash Chain 長度-5. 共有 100 檔案，做 100,000,000 次平均 Partial Hash Chain 長度 100.00 Partial Hash Chain 長度. 發生次數. 百分比. 0 到 100. 63,028,560. 63.03. 長度是 100 到 200. 23,437,218. 23.44. 長度是 200 到 300. 8,581,441. 8.58. 長度是 300 到 400. 3,140,867. 3.14. 長度是 400 到 500. 1,148,363. 1.15. 長度是 500 到 600. 420,635. 0.42. 長度是 600 到 700. 153,706. 0.15. 長度是 700 到 800. 56,631. 0.06. 長度是 800 到 900. 20,743. 0.02. 長度超過 900. 11,836. 0.01. 長度是. 表格四-9 平均 Partial Hash Chain 長度-6. 共有 1,000 檔案，做 10,000 次平均 Partial Hash Chain 長度 949.32 Partial Hash Chain 長度. 發生次數. 百分比. 6,438. 64.38. 長度是 1000 到 2000. 2,408. 24.08. 長度是 2000 到 3000. 778. 7.78. 長度是 3000 到 4000. 242. 2.42. 長度是 4000 到 5000. 89. 0.89. 長度是 5000 到 6000. 30. 0.3. 長度是 6000 到 7000. 13. 0.13. 長度是 7000 到 8000. 2. 0.02. 長度是 8000 到 9000. 0. 0. 長度超過 9000. 0. 0. 長度是. 0 到 1000. 23.

(29) 表格四-10 平均 Partial Hash Chain 長度-7. 共有 1,000 檔案，做 100,000 次平均 Partial Hash Chain 長度 994.95 Partial Hash Chain 長度. 發生次數. 百分比. 63,251. 63.25. 長度是 1000 到 2000. 23,456. 23.46. 長度是 2000 到 3000. 8,430. 8.43. 長度是 3000 到 4000. 3,123. 3.12. 長度是 4000 到 5000. 1,081. 1.08. 長度是 5000 到 6000. 427. 0.43. 長度是 6000 到 7000. 154. 0.15. 長度是 7000 到 8000. 53. 0.05. 長度是 8000 到 9000. 14. 0.01. 長度超過 9000. 11. 0.01. 長度是. 0 到 1000. 表格四-11 平均 Partial Hash Chain 長度-8. 共有 1,000 檔案，做 1,000,000 次平均 Partial Hash Chain 長度 999.48 Partial Hash Chain 長度. 發生次數. 百分比. 632,270. 63.23. 長度是 1000 到 2000. 232,572. 23.26. 長度是 2000 到 3000. 85,783. 8.58. 長度是 3000 到 4000. 31,294. 3.13. 長度是 4000 到 5000. 11,401. 1.14. 長度是 5000 到 6000. 4,206. 0.42. 長度是 6000 到 7000. 1,561. 0.16. 長度是 7000 到 8000. 577. 0.06. 長度是 8000 到 9000. 210. 0.02. 長度超過 9000. 126. 0.01. 長度是. 0 到 1000. 24.

(30) 表格四-12 平均 Partial Hash Chain 長度-9. 共有 1,000 檔案，做 10,000,000 次平均 Partial Hash Chain 長度 999.95 Partial Hash Chain 長度. 發生次數. 百分比. 6,320,794. 63.21. 長度是 1000 到 2000. 2,325,238. 23.25. 長度是 2000 到 3000. 856,427. 8.56. 長度是 3000 到 4000. 314,942. 3.15. 長度是 4000 到 5000. 115,317. 1.15. 長度是 5000 到 6000. 42,696. 0.43. 長度是 6000 到 7000. 15,488. 0.15. 長度是 7000 到 8000. 5,797. 0.06. 長度是 8000 到 9000. 2,092. 0.02. 長度超過 9000. 1,209. 0.01. 長度是. 0 到 1000. 表格四-13 平均 Partial Hash Chain 長度-10. 共有 1,000 檔案，做 100,000,000 次平均 Partial Hash Chain 長度 999.99 Partial Hash Chain 長度. 發生次數. 百分比. 63,191,464. 63.19. 長度是 1000 到 2000. 23,276,476. 23.28. 長度是 2000 到 3000. 8,554,660. 8.55. 長度是 3000 到 4000. 3,148,740. 3.15. 長度是 4000 到 5000. 1,157,108. 1.16. 長度是 5000 到 6000. 424,879. 0.42. 長度是 6000 到 7000. 156,306. 0.16. 長度是 7000 到 8000. 57,219. 0.06. 長度是 8000 到 9000. 21,122. 0.02. 長度超過 9000. 12,026. 0.01. 長度是. 0 到 1000. 25.

(31) 表格四-14 Partial Hash Chain 平均長度. 共有 N 個檔案，平均 Partial Hash Chain 長度為 N Partial Hash Chain 長度長度是. 大約百分比. 0到N. 63.3. 長度是 N 到 2N. 23.28. 長度是 2N 到 3N. 8.5. 長度是 3N 到 4N. 3. 長度是 4N 到 5N. 1.2. 長度是 5N 到 6N. 0.42. 長度是 6N 到 7N. 0.16. 長度是 7N 到 8N. 0.06. 長度是 8N 到 9N. 0.02. 長度超過 9N. 0.01. 由表格四-4 到表格四-13 可以整理出表格四-14。由表格四-14 的實驗結果可以得出，當 N 個檔案對映到一條證據的時候，可以歸類出以下三種特性：第一，每次稽核的 Partial Hash Chain 的平均長度為 N；第二，超過 80%的狀況 Partial Hash Chain 的長度在 2N 以內；第三，Partial Hash Chain 的長度超過 9N 的狀況發生機率微乎其微，其機率約為 0.01%。此實驗結果證明第三章第四節，把證據打散成多條的方法可以有效的加速稽核。. 26.

(32) 第五章相關研究由於近年來雲端技術的快速發展，越來越多的人不僅傳輸資料不再使用隨身碟，甚至連資料的存放也不再儲存在自身電腦的硬碟裡。使用者將自己的資料全數儲存至雲端儲存空間。常見的雲端儲存空間包含了 Google Drive、 Dropbox、SugarSync、SkyDrive 和 Box，但這些系統都不支援相互的不可否認性服務層級協議[14]，所以當使用者的資料出問題的時候，無法證明到底是服務提供商還是使用者本身的問題。 C&L Scheme 以及 Double Hash 這兩種方法因為都有留下互相不可否認的證據，可以有效的解決上述問題。不過因為無法即時稽核，因此問題發生的當下也無法偵測得出來，只能事後再求賠償。如果可以即時偵測的話，對雙方的損失都可以降低。以 FBHTree[16]及以馬可夫樹[10]皆可達成即時稽核的功能，不過以馬可夫樹[10]的花費時間實在太長，且在硬體上需多架設同步伺服器。本研究做法比起上述兩做法，上述兩做法都必須動到樹狀資料結構，本研究的作法只採用 Hash Chain 為線性的資料結構。以 History Tree[18]的做法也採用樹狀資料結構儲存證據，不過也是沒辦法達成即時稽核，須等到自己下一次的讀寫才可以知道這一次的證據是否正確。PeerReview[19]跟本研究一樣採取線性資料結構，不過是套用在分散式系統，未來如果服務提供商把檔案切割成多份儲存至更多 Server 的時候可以參考(目前的架構 Server 只有一個，或者 replication 是儲存多份一樣的資料)。 27.

(33) 第六章結論未來雲端儲存空間相互的不可否認性服務層級協議[14]的發展會加入即時稽核。大家都希望自己拿到的檔案是最新且正確的。當一群人一起編輯某一份文件時，即時稽核顯得更加的重要。在編輯檔案的時候如果拿到舊版本的資料，代表先前某一個使用者編輯的部份並沒有被寫入，下一個使用者在做寫入的動作的時候又會產生新版本的檔案。如此一來先前沒有被寫入的部份從此消失。如果編輯的檔案是合約內容等重要資料，很可能造成巨大的損失。本研究的作法盡可能的簡化架構及加快時間，雖然在稽核時間的部份有不確定的因素(Partial Hash Chain 長度不一導致稽核時間不固定)，但也有對應的方法控制時間 (將證據打散成多條)。此方法是建立在每個檔案讀寫的機率皆相同，現實生活中每個檔案讀寫的機率很可能是非常不平均的。因此未來的研究工作應該是將證據依據檔案讀寫的機率來做分類的動作，以達到本研究的效能。. 28.

(34) 第七章參考著作 [1] “Google Compute Engine,” https://cloud.google.com/compute/ [2] “Amazon EC2,” http://aws.amazon.com/tw/ec2/ [3] “Google App Engine,” https://cloud.google.com/appengine/docs [4] “Google Drive,” https://drive.google.com/start#home [5] “Dropbox,” https://www.dropbox.com/home [6] “SugarSync,” https://www.sugarsync.com/ [7] “Microsoft SkyDrive,” http://skydrive.live.com/. [8] “Box,” http://www.box.net [9] Gwan-Hwan Hwang, Jenn-Zjone Peng, and Wei-Sian Huang, “A Mutual Nonrepudiation Protocol for Cloud Storage with Interchangeable Accesses of a Single Account from Multiple. Devices,” The. Conference on Trust, Security and. 12th. Privacy in. Communications (IEEE TrustCom-2013),. IEEE. International. Computing. and. Melbourne, Australia, 16-18. July. [10] Gwan-Hwan Hwang, Wei-Sian Huang, and Jenn-Zjone Peng, “Real-time Proof of Violation for Cloud Storage,” International Conference on Cloud Computing Technology and Science, December 27-29, 2014, Singapore. [11] Raluca Ada Popa, Jacob R. Lorch, David Molnar, Helen J. Wang, and Li Zhuang, 29.

(35) “Enabling Security in Cloud Storage SLAs with CloudProof,” USENIX Annual Technical Conference (USENIX), 2011, pp. 31. [12] Jun Feng, Yu Chen, Douglas Summerville, Wei-Shinn Ku, Zhou Su, “Enhancing cloud storage security against roll-back attacks with a new fair multi-party nonrepudiation protocol,” in IEEE Consumer Communications and Networking Conference (CCNC), pp.521-522, January 2011.. [13] Alexander Shraer, Idit Keidar, Christian Cachin, Yan Michalevsky, Asaf Cidon, and Dani Shaket, “Venus: Verification for untrusted cloud storage,” ACM CCSW 2010. [14] Gwan-Hwan Hwang, Wei-Sian Huang, Jenn-Zjone Peng, and Yu-Wei Lin, “Fulfilling mutual. nonrepudiation. for cloud storage,” Concurrency and. Computation: Practice and Experience (2014). [15] Ravi S. Sandhu, Coynek, Edward J. Coyne, Feinsteink, Hal L. Feinstein, and Charles E. Youman, “Role-based access control models yz,” IEEE computer 29.2 (1996): 38-47. [16] Gwan-Hwan Hwang, and Hung-Fu Chen, “Efficient Real-time Auditing and Proof of Violation for Cloud Storage Systems,” International Conference on Cloud Computing, June 27 - July 2, 2016. [17] Gwan-Hwan Hwang, Yi-Ling Yuan, and Chi Wu-Lee, “Cryptographic 30.

(36) Accountability for Cloud-based Service-oriented Architecture Systems,” Submitted to IEEE Transactions on Service Computing (In revision) [18] Crosby, Scott A., and Dan S. Wallach. “Efficient Data Structures For TamperEvident Logging”. USENIX Security Symposium. 2009. [19] Haeberlen, Andreas, Petr Kouznetsov, and Peter Druschel. “PeerReview: Practical accountability for distributed systems”. ACM SIGOPS operating systems review. Vol. 41. No. 6. ACM, 2007. [20] “對雲端不信任的問題-1,” http://technews.tw/2015/08/23/can-we-really-trust-google/ [21] “對雲端不信任的問題-2,” http://www.netadmin.com.tw/article_content.aspx?sn=1208090001 [22] FIPS, PUB. "Federal Information Processing Standards Publication." DES modes of operation, US Department of Commerce/National Institute of Standards and Technology (1980).. 31.

(37)