對於雲端虛擬機器執行環境的即時稽核

全文

(1)國立臺灣師範大學資訊工程研究所碩士論文指導教授：黃冠寰. 博士. 對於雲端虛擬機器執行環境的即時稽核. Efficient Real-Time Audit for Execution Environment of Virtual Machine in Cloud System. 研究生：中華民國. 廖柏翔 105 年. 撰 8. 月.

(2) 摘要今日雲端提供租借虛擬機器的服務日漸普及，用戶可以在虛擬機器上運行任何自己的軟體或應用程式。然而雲端服務提供商只有提供硬體的租借，將虛擬機器交由用戶全權自由的使用，並不會提供額外的安全性檢驗服務。然而用戶並不知道當他們在暫停使用虛擬機器的情況下，雲端服務提供商是否有安全地保存用戶的虛擬機器。所以在使用虛擬機器作為開發軟體以及其他服務時，我們需要對雲端虛擬機器平台做一個即時的完整性驗證，才能夠確保開發資料以及個人資料不會因為雲端服務提供商不當的保存而損毀以及外洩。本篇論文提出了一個即時稽核架構，雲端服務提供商在租借虛擬機器給予用戶時，能夠在用戶執行軟體之前就能夠即時性的發現因為雲端服務提供商不當疏忽而造成虛擬機器檔案損毀或者被篡改，希望能夠達到在每次使用 VM 時都能夠達到快速的即時性稽核，我們將使用 Full Binary Hash Tree 來實作我們的架構。. 關鍵字：雲端運算、虛擬機器、即時稽核、違約證明機制. i.

(3) 誌謝首先要先感謝我的指導教授黃冠寰老師，老師很有耐心的教導我如何做研究以及非常多的資訊科學領域的知識，很感謝老師引導我如何去發現問題、理解問題並且解決問題，這兩年讓我收穫很多。老師讓我能夠從一個原本完全不懂得活用知識的學生開始慢慢學會如何去思考，在這兩年當中我學到的不只是資訊科學的相關知識，更學到了許多如何做研究的態度以及方法，透過老師兩年的訓練，讓我在解決問題的能力上有不凡的改進。也謝謝我的家人默默的支持我念完這兩年的研究所，讓我能全心全力去完成我的學業。另外還要感謝兩年中遇到的學長以及朋友們，感謝葉上語學姐、陳虹甫學長、傅詩凱學長、王子豪學長，學長姐們在我不懂的時候可以耐心的教導我，以及給我很多建議和方向。感謝這兩年來跟我一起奮鬥的同學偉智、浩群、佳均、之中，謝謝你們在這兩年中也教了我許多，還有一起陪伴我在實驗室奮戰的日子，以及學弟安傑這一年來的陪伴，最後更感謝儀齡，這兩年來謝謝儀齡教導我許多資訊科學上以及程式上的各種問題，謝謝儀齡讓我在這兩年的研究所生活覺得非常快樂。廖柏翔誌於國立臺灣師範大學資訊工程所民國 104 年 8 月. ii.

(4) 目錄摘要.................................................................................................................................. i 誌謝................................................................................................................................. ii 附圖目錄........................................................................................................................ iv 附表目錄......................................................................................................................... v 第一章簡介................................................................................................................... 1 第一節雲端運算................................................................................................... 1 第二節虛擬機器................................................................................................... 1 第三節證明違約協定以及即時稽核................................................................... 2 第四節目標........................................................................................................... 4 第五節過往的作法............................................................................................... 4 第六節論文大鋼................................................................................................... 5 第二章即時稽核結構架構........................................................................................... 6 第一節 Merkle Tree ............................................................................................... 6 第二節:Full Binary Hash Tree .............................................................................. 11 第三節稽核檔案................................................................................................. 13 第四節更新檔案................................................................................................. 15 第三章相關實驗數據................................................................................................. 17 第四章相關研究探討................................................................................................. 28 第五章結論................................................................................................................. 29 參考著作....................................................................................................................... 30. iii.

(5) 附圖目錄. 圖 1:資料夾 .................................................................................................. 7 圖 2:資料夾的 Merkle Tree .......................................................................... 8 圖 3:Partial Merkle tree ................................................................................ 9 圖 4:同一層資料夾中有很多資料夾需要串連 .......................................... 9 圖 5: 即時稽核架構 .................................................................................. 10 圖 6: FBHTree with tree height four ........................................................... 11 圖 7:樹高為 9 的 FBHTree ........................................................................ 13 圖 8: 比對 Root Hash 示意圖 ................................................................... 13 圖 9: FBHTree 中 Slice 需要更新的節點 ................................................. 15 圖 10: FBHTree 容納不同數目檔案稽核和更新時間折線圖 ................. 21. iv.

(6) 附表目錄表 1: Index function Γ 的碰撞測試 ................................................................... 18 表 2: FBHTree 容納不同數目檔案的操作時間 ............................................... 19 表 3: Integrity checking 以及 Merkle Tree 的初始化比較 ............................... 22 表 4: FBHTree 各個樹高的比較 ....................................................................... 23 表 5: HashMap 稽核和更新一個檔案所需的時間 .......................................... 24 表 6: Merkle tree 稽核和更新一個檔案所需時間 ........................................... 24 表 7: Integrity checking 以及 Merkle Tree 應用程式檢測時間(單位:ms)....... 26 表 8:FBHTree 的應用程式檢測時間(單位:ms)................................................ 26 表 9: Integrity checking 以及 Merkle Tree 應用程式檢測時間 2(單位:ms).... 26 表 10: FBHTree 的應用程式檢測時間 2(單位:ms).......................................... 27. v.

(7) 第一章簡介第一節雲端運算雲端運算（Cloud Computing），依據 NIST(National Institute of Standards and Technology，美國國家技術標準局)所定義的內容，雲端服務架構可依服務類型指標劃分為軟體即服務（Software as a Service，簡稱 SaaS）、平台即服務（Platform as a Service，簡稱 PaaS）、基礎建設即服務（Infrastructure as a Service，簡稱 IaaS）三大層次。IaaS 提供基礎運算的資源給予使用者，如處理器、儲存容量、網路等基礎的運算資源，且能自行控制作業系統等底層的功能，但不需自行購買硬體即建置基礎設施，如：Amazon EC2[1]等；PaaS 提供使用者運作應用程式的環境，使用程式語言或程式庫等服務，但並不需要掌控作業系統及硬體端，介於 IaaS 和 SaaS 之間，如：Goole App Engine[2]、Amazon Web Service[3]；SaaS 是軟體的集合，這些應用架構於 IaaS 提供的資源以及 PaaS 提供的環境之上，並透過網路交付給用戶，如：Gmail[4]、Youtube[5]。. 第二節虛擬機器. 虛擬機器（Virtual Machine，以下簡稱 VM)是一種通過軟體模擬且具有完整硬體系統功能、運行在一個隔離環境中的完整計算機系統，虛擬機器分為兩大類，系統虛擬機器以及程式虛擬機器。程式虛擬機器，如：Java 虛擬機（JVM[6]），只能執行單一程式。相反的，系統虛擬機器，如：VirtualBox[7]提供一個可以執 1.

(8) 行完整作業系統的完整系統平台。虛擬機器的一個本質特點是執行在虛擬機器上的軟體被局限在虛擬機器提供的資源裡。在本篇論文中將針對系統虛擬機器作探討。雲端日漸普及，許多雲端服務提供商開始提供 VM 的租借服務。在現今，很多人都會選擇在雲端上租用 VM 來做為軟體開發或者提供網站服務。然而，雲端服務提供商在提供 VM 服務的時候，並不全然安全，VM 依然有可能會因為雲端服務提供商的不當保存導致損毀，甚至 VM 遭受植入惡意程式，儘管有些雲端服務提供商聲稱他們的服務可以達到安全的防禦，但是我們並不能知道他們是否真的有將我們的 VM 安全的隔離防護。我們考慮到以下情境發生，用戶 Alice 到雲端上租借 VM 來使用，雲端平台有可能在 Alice 暫停使用 VM 時將其 VM 關閉，在 Alice 下次開機使用時在將其映像檔重新載入，然而 Alice 並不知道雲端服務提供商是否有安全的將 VM 關閉並且保存，也就是說，Alice 不知道她的映像檔是否在關閉的期間因為雲端服務提供商沒有安全保存而被病毒感染、甚至遭受駭客訪問植入惡意程式。. 第三節證明違約協定以及即時稽核. 證明違約協定[8]（Proof of Violation，以下簡稱 POV）提供了服務提供者與用戶之間的不可否認性，當有問題產生時能證明服務提供者是無辜的以及讓用戶證明自己沒有過失的方法，而證明雙方有沒有過失又稱作稽核(Auditing)。只要達. 2.

(9) 到不可否認性，用戶和服務提供者之間可以建立一個商業合約，這個合約會依照用戶想要的安全層級來定價；如果服務提供者管理的資料有被竊取或竄改，則需給付用戶一些合約中簽訂的賠償金。然而稽核需要有根據，我們稱之為證據 (Attestation)，這個證據都是經過雙方簽證過的訊息 (Signed Messages)。稽核 (Auditing)可分為時期(Epoch-based Auditing)以及即時稽核(Real-time Auditing)。其中時期稽核為用戶可以在設定的期限，去做稽核與服務商更新最新狀態，這個方法可以減少雲端服務提供商產生證據運算的時間。因為我們必須在每次執行應用程式前都要檢查一次，才能確保雲端平台安全無慮，所以時期稽核並不能達到我們所要的需求。在 PaaS 當中，因為雲端方必須維護我們的資源，且用戶沒有權限可以更改雲端上的資源，所以在 PaaS 當中就可以加入 POV 的機制，能夠確保用戶的權益不受損，然而，在 IaaS 當中，我們並不能夠做到 POV 的機制，因為用戶可以全權的使用 VM，VM 內部並不是雲端方面維護的，且當 VM 被關閉的時候，雲端服務提供商可以將責任推卸給網路問題，用戶也因為 VM 被突然關閉而沒有辦法掌握到證據，所以在 IaaS 當中要達到 POV 是非常困難的。在本篇論文中，我們將探討在 IaaS 當中，如何在 VM 中達到快速的完整性稽核。考慮到用戶在 VM 當中開發軟體時，如果不能夠達到即時稽核的話，那麼用戶就只能在 VM 發生錯誤時才能得知 VM 遭受惡意竄改甚至病毒感染，所以必須要在程式執行前就確保用戶的 VM 是安全的執行環境，才能保障用戶的 VM 不會 3.

(10) 有重大災害，因此即時稽核在雲端平台上是非常重要的一個機制。. 第四節目標我們的目標是希望用戶在雲端 VM 上使用服務時，能夠在每一次執行程式前，都能先將程式所需要用到的靜態檔案做過一次完整性稽核，確認執行的程式需要用到的靜態檔案並未被篡改，以防範用戶的 VM 發生重大錯誤，例如：個人資料外洩，開發軟體資料損毀。在每次執行程式時，程式都會呼叫函式庫，如果說我們的函式庫有被植入惡意程式碼，就有可能會執行惡意指令，例如：開啟遠端連線給惡意使用者訪問，傳送個人敏感資料給駭客。所以我們必須在執行程式之前就對函式庫的完整性做好一次確認，才能確保用戶在 VM 上的重要資料安全無慮。在本篇論文中我們將針對函式庫來做為實驗的範例。我們使用本實驗室研究成果 FBHTree[9]來加快對檔案做稽核時間，我們將會在下一章介紹相關細節，在第三章相關的實驗數據結果可以呈現檢查所需要的時間，來證明這個機制的可行性以及優點。. 第五節過往的作法過去 Mishra Umakant[10]曾提出了一個在非雲端環境中簡單的解決方法，稱為 Integrity checking。我們可以把函式庫當中所有檔案的 Hash 值全部記錄下來放置在一個安全的地方，而用戶在每次要執行程式前，將這些保存的 Hash 值跟在 VM 中的函式庫檔案 Hash 值作比對，這樣就能夠知道執行的程式是否有遭受不當篡改。保存這些 Hash 值會有額外的成本負擔，為了減少用戶在儲存這些 Hash 值的負擔以及減少用戶在傳輸這些 Hash 值的時間，我們假設將這些 Hash 值存放在用 4.

(11) 戶的雲端 VM 當中，這樣做會有個問題，我們無法確保雲端 VM 是否因為中毒而病毒程式將我們存放在 VM 上的 Hash 值偷偷更改過，也就是說雲端 VM 上保存的 Hash 值有可能被改成中毒檔案的 Hash 值，導致用戶在下次使用時不知道自己現行版本的檔案已經中毒，執行程式進而影響雲端 VM 發生錯誤。所以我們不能將這些檔案的 Hash 值保存在 VM 中，如果說函式庫檔案有 100 萬個，那麼就需要保存 100 萬個檔案 Hash 值，這對用戶會是個負擔，我們提出一個方法可以大幅減少用戶的負擔。. 第六節論文大鋼. 在本篇論文中，首先第二章將介紹我們第二節提到的情境的直覺解法，並且說明直覺解法的缺點，接著會介紹我們所提出的即時稽核架構，講解我們如何利用 FBHTree 的方法來減少運算時間以及負擔，以及 FBHTree 是如何達到快速的稽核。第三章相關實驗結果呈現我們的方法以及以往的直覺解決方法的比較結果，證明我們所提出的方法減少了許多負擔，也達到更快速的結果。第四章為相關研究，而第五章為本篇論文的結論。. 5.

(12) 第二章即時稽核結構架構在這個章節中會呈現當用戶使用雲端服務時，用戶如何在雲端平台中運作安全性的檢驗，並且將檢驗結果的證據存放在一個安全的裝置，提供用戶下次使用時能夠稽核當下的雲端平台是否安全。在第一章第二節中所提到的情境，我們有一個直覺方法可以解決安全性問題，並且還能減少使用者在儲存 Hash 值的負擔，就是將雲端平台中的函式庫資料夾建立成一個 Merkle tree，而用戶只需要保存這個 Merkle tree 的 Root hash,因為 size 小，這麼一來我們就不用擔心 Hash 值因為 VM 中毒而被偷改。以我們論文中的計算 Hash 方式，java.security.MessageDigest 中的 SHA-256 演算法來說，用戶也只需要一個來保存一個 32Bytes 的 Hash 值，在自然人憑證日趨普及的現代，用戶甚至可以藉由一個晶片卡來保存這樣的一個 Hash 值。接下來我們將介紹 Merkle Tree 以及其運作方式。第一節 Merkle Tree 在這一節當中，首先我們先介紹一個直覺地解法。當一個用戶開啟使用雲端服務後，用戶計算其作業系統中函式庫每個檔案以及資料夾(例如圖 1)的 Hash 值並記錄下來，如圖 2 所示，以 Hash Tree 的架構，從樹的底層的葉節點，將檔案以及資料夾一層一層計算上來，例如 h(d3)=h(h(f2)，h(d6)，h(f3))。而最後頂端之 Hash 值稱之為 Root Hash。因為密碼學加密函數的特性，倘若有修改過其中一個節點的值，那麼就會得出不同的 Root Hash，所以我們可以用 Root Hash 來驗證整個函式庫的完整性。我們將整個函式庫資料夾的架構記錄起來，稱之為 Merkle 6.

(13) Tree，這樣的結構儲存在雲端 VM 中，用戶則保存 Root Hash。而用戶每次更新函式庫時，再將雲端 VM 上的所有檔案及資料夾重新做一次計算，得出新的 Root Hash 以後，再將其 Root Hash 保存。在下次使用雲端 VM 執行程式時，再重新將雲端中的檔案計算 Root Hash 與用戶所保存的 Root Hash 做比對，若是相同，即可驗證雲端 VM 上的函式庫沒有被更動過。. d1 d2 f1. d5. d3 f2. f5. d4. f3. d6. f4. f7. f6. :資料夾d1~d7. :檔案f1~f7. 圖 1:資料夾. 7.

(14) Root Hash = H(d1). H(d2). H(f1). H(d3). H(d5). H(f5). H(f2). H(d4). H(d6). H(f3). H(f6). H(f4). H(f7). : 資料夾的Hash值 : 檔案的Hash值. 圖 2:資料夾的 Merkle Tree 然而這樣的作法速度非常慢，當檔案數量以及資料夾層數非常多的時候，所需要計算的 Merkle Tree 也會越來越大，花費的時間也就越來越龐大。為了改善 Merkle Tree 在計算時間上的負擔，我們使用本實驗室以前的研究成果，partail Merkle Tree(pMT)，只需計算部分的 Merkle Tree。想像一種真實的情況，如圖 1，這是一名用戶的雲端 VM 的函式庫，並且將 Merkle Tree 儲存在 VM 中以做為驗證(圖 2)。今天這名用戶可能會在這個月內因為工作只需要使用到 d2 資料夾下面的檔案，假設 d3 下面的檔案以及資料夾數目非常可觀，而使用者在這次使用時並不會用到那個資料夾的話，其實在 Merkle Tree 中，如圖 3 所示，只需紀錄 d3 的 Hash 值，而不需要將 d3 下的整個結構重新作一次計算，這麼一來，在計算 Merkle Tree 的時間就可以節省許多。. 8.

(15) Root Hash = H(d1). H(d2). H(d3). H(d4). H(d5). :以下忽略的資料夾. :資料夾的Hash值. H(f1). :檔案的Hash值. H(f5). 圖 3:Partial Merkle tree 但是這樣的結果依然存在個問題，如果我們所需要的檔案的資料的同一層檔案數量非常多的時候，如，我們仍然必須花很多時間在串連這些 Hash 值上，所圖 4 以我們使用 FBHTree 來儲存函式庫的這些 Hash 值，以達到更快速的稽核。. … … :以下省略的資料夾Hash值. …. :資料夾的Hash值. H(f5). :檔案的Hash值. 圖 4:同一層資料夾中有很多資料夾需要串連. 9.

(16) 在介紹 FBHTree 之前，先介紹我們所提出的即時稽核架構。在我們的即時稽核架構中，我們會在雲端 VM 中架設一個代理伺服器（Agent），來幫助用戶維護 FBHTree 及傳遞 Root Hash 給用戶，來讓用戶可以在下一次使用雲端 VM 時可以用 Root Hash 來對雲端 VM 做稽核，如圖 5。當用戶在雲端 VM 上首次開啟時，Agent 先將其函式庫中的檔案的 Hash 值都儲存成一個 FBHTree，而 FBHTree 儲存在 VM 當中，Agent 將 Root Hash 傳遞給用戶。在下次用戶要執行程式之前，用戶必須先將手上的 Root Hash 交給 Agent， Agent 在利用這個 Root Hash 以及 Slice 來對 VM 中的檔案做一次完整性稽核。接下來下一節我們將介紹 FBHTree 的結構。. Virtual Machine FBHTree. Agent. Root Hash. Device. 圖 5: 即時稽核架構. 10. User.

(17) 第二節:Full Binary Hash Tree :Tree node ID. i. 1. h1. 2. h2. 3. h3. Tree Height h4 h8. 8. 4. h5. h9. 9. 5. h6. 10. 11. 6. 12. h7 13. 6. 14. 15. h10. h11. h12. h13. h14. h15. 2. 3. 4. 5. 6. 7. Leaf node ID 0. 1. Tree node ID. 1. 2. 3. Array subsript. h1. h2. h3. 4. h4. 5. 6. h5. 7. h6. 8. h7. 9. h8. 10. 11. 12. 13. 14. 15. h9 h10 h11 h12 h13 h14 h15. 圖 6: FBHTree with tree height four Pair value = hash(file name)|hash(file name|hash(file)) PB-pair = Pair value 1st ->Pair value 2nd ->…->Pair value Nth Leaf node = hash(PB-pair) Internal node , Root node = hash (Left child node | Right child node ) 在這一個章節中，我們將介紹本實驗室的研究成果Full Binary Hash Tree(以下簡稱FBHTree)的結構。FBHTree的結構主要可以分為3個部分：葉節點、內節點、根節點。葉節點是一個由Pair value集合而成的PB-pairs的Hash值，而Pair value則是每個檔案的名稱以及其檔案的hash值，每個檔案都是經過一個Index function Γ 計算來得到其該存放到哪一個Leaf node的位置，此Index function Γ 如下。 𝚪(FileName)=SHA-256 (FileName) mod 2N-1。其中FileName為檔案的絕對路徑，N為樹高。 11.

(18) 而每一個內節點都代表著，其左子節點的 Hash 值和其右子節點的 Hash 值，兩者串連起來再做一次計算所得出來的 Hash 值，重複著以上的步驟，由樹的最底層，一層一層往上運算，就可以得出根節點的 Hash 值，而這個根節點的 Hash 值我們稱之為此 FBHTree 的 Root Hash，就是我們可以拿來對 VM 作稽核的一個依據。 FBHTree 在儲存方式上使用一維陣列來儲存，每個葉節點 ID(以 I 表示)，都可以轉換成一個 Tree node ID(以 X 表示)，轉換的表示式為 X=I+2N-1。從Γ得出葉節點 ID 以後，我們可以根據這個公式來快速的找到每個節點的 Hash 值被存放到一維陣列中的哪個位置。下一章節我們將介紹一個用來操作 FBHTree 的結構：Slice，根據 FBHTree 處理檔案 Hash 值以及 Root Hash 的運作模式，我們可以知道在操作 Slice 的時間上會變的非常有效率。. 12.

(19) 第三節稽核檔案. Slice. :Root Node :Internal node. 樹高= 9. :PB-pair. 圖 7:樹高為 9 的 FBHTree Slice of FBHTree = Root node | Left Internal node | Right internal node |…| Left PB-pair | Right PB-pair. User’s device. Slice (Compare). Root hash. User’s device. Leaf node ID=97. F20 F56. 圖 8: 比對 Root Hash 示意圖. 13.

(20) 當用戶要執行程式之前，必須要先確認執行程式所要用到的函式庫是否為安全無慮的檔案，以避免雲端 VM 重大災害。而當在稽核開始之前，Agent 必須先拿到一些資訊，其中包括用戶手上的 Root Hash、執行的程式所需要用到的函式庫檔案、以及找出 FBHTree 中對應檔案的 Slice。我們會利用 Algorithm 1 來找出檔案對應的 Slice 並且對即將執行所需要用到的檔案稽核。由於儲存 FBHTree 的方式為一維陣列來儲存，所以我們找出對應檔案的 Slice 的葉節點到根節點的 Hash value 時並不需要透過指標來走訪，只需要直接找到對應位置拿出裡面的元素。 Algorithm 1:從 VM 當中保存的 FBHTree 中找出檔案對應的 Slice 並且對此檔案做稽核。假設 FBHTree 的樹高為 N，檔案的 PB-pairs 數量有 m 個 I:檔案的葉節點 ID Ψ:儲存 FHBTree 的一維陣列 H:SHA-256 function 𝚪: Index function , 𝚪(FileName)=H (FileName) mod 2N-1 Y:重新推算的 Root Hash Input: R:用戶保存的 Root Hash, FileName:檔案的絕對路徑, FileHash:檔案的 Hash value Output: True or False (1) I=Γ(FileName) (2) X = I + 2N-1 // 轉換葉節點 ID 成 Tree node ID (3) Ψ [X]= H(PB-pair_1|PB-pair_2|…|FileHash|…|PB-pair_m) (4) WHILE (X ≠ 1) DO // 從最底層葉節點到根節點 IF X 是偶數 THEN Y=H(Ψ [X]) | Ψ [X+1]) 14.

(21) ELSE Y=H(Ψ [X-1]) | Ψ [X]) END IF X = ⌊ X ÷ 2 ⌋ //無條件四捨五入 END WHILE (5) IF R＝Y RETURN TRUE ELSE RETURN FALSE 第四節更新檔案. New node F20 F56. 圖 9: FBHTree 中 Slice 需要更新的節點當雲端 VM 的函式庫中有檔案需要更新時，Agent 利用 FBHTree 中的 Slice 以及更新的檔案 Hash 值，依照 Algorithm 2 來更新 FBHTree 的 Root Hash，在這些步驟完成以後就會得到一個新的 Root Hash，將這個更新過後的 Root Hash 傳給用戶保存。 Algorithm 2:更新保存在 VM 的 FBHTree 中的檔案 Hash 值。假設 FBHTree 的樹高為 N，檔案的 PB-pairs 數量有 m 個。 15.

(22) Ψ:儲存 FHBTree 的一維陣列 𝚪: Index function , Γ(FileName)=SHA-256(FileName) mod 2N-1 R:更新過後的 Root Hash Input: FileName:檔案的絕對路徑 FileHash:檔案更新過後的 Hash value Output: R (6) I=Γ(FileName) (7) X = I + 2N-1 // 轉換葉節點 ID 成 Tree node ID (8) Ψ [X]= H(PB-pair_1|PB-pair_2|…|FileHash|…|PB-pair_m) //更新 HashValue (9) WHILE (X ≠ 1) DO // 從最底層葉節點到根節點 IF X 是偶數 THEN Ψ [X/2] =H(Ψ [X]) | Ψ [X+1]) ELSE Ψ [(X-1)/2] =H(Ψ [X-1]) | Ψ [X]) END IF X = ⌊ X / 2 ⌋ //無條件四捨五入 END WHILE (10) RETURN. R. 16.

(23) 第三章相關實驗數據在這個章節中，我們做了一系列的實驗，來證明我們的結果比以往的作法能夠更快速地達到我們的目的。我們使用 JAVA 來實做我們的即時稽核架構，以及 digest function 為 java.security.MessageDigest 中的 SHA-256 algorithm，實驗的電腦為 Macbook Air 2014，作業系統為 OS X El Capitan 10.11.5，處理器為 1.4GHz Intel Core i5，記憶體為 4 GB 1600 MHz DDR3。而我們將利用這台電腦中的函式庫來做為實驗的對象，其中包含了 OSX 內建的函式庫以及許多應用程式的函式庫，總共有 149,487 個資料夾以及 717,976 個檔案。其中所安裝的應用程式有:FaceTime、 Photos、Maps、Mail、LINE、．．．等。第一部分讓我們對 Index function Γ 的碰撞機率作一個簡單的測試，在我們要從一個檔案的 Slice 計算出 Root Hash 前，我們必須先串聯儲存在中的 PB-pair，才能計算出這個檔案所在位置的 Leaf node 的 Hash 值，而如果我們的 Leaf node 中的 PB-pair 數量非常多時，那麼我們就會花費非常多的時間在串聯這些 PB-pair，就會影響到我們計算 Root Hash 的時間，所以我們的 Index function 必須要能夠均勻分散我們所要儲存的檔案 Hash 值。我們將實驗平台的函式庫放進各個樹高的 FBHTree，觀察存放了不同數量的 PB-pairs 在 FBHTree 中碰撞的情形。在表 1 中，是我們分別對樹高 1 到 20 的 FBHTree 作了碰撞測試的表格。. 17.

(24) 表 1: Index function Γ 的碰撞測試 Tree Height：FBHTree 的樹高 #Leaf Nodes：FBHTree 中的 Leaf node 總數量 #AVG collision：在一個不為空的 Leaf node 中儲存 PB-pairs 的平均值 #MAX collision：在一個不為空的 Leaf node 中儲存 PB-pairs 的最大值 Tree Height. #Leaf node. #AVG collision. #MAX collision. 1. 1. 717976.00. 717976. 2. 2. 358988.00. 359390. 3. 4. 179494.50. 179814. 4. 8. 89747.25. 89908. 5. 16. 44873.13. 45109. 6. 32. 22436.16. 22646. 7. 64. 11218.53. 11396. 8. 128. 5609.27. 5794. 9. 256. 2804.63. 2950. 10. 512. 1402.32. 1502. 11. 1024. 701.16. 784. 12. 2048. 350.58. 421. 13. 4096. 175.29. 221. 14. 8192. 87.64. 127. 15. 16384. 43.82. 72. 16. 32768. 21.91. 43. 17. 65536. 10.96. 26. 18. 131072. 5.50. 18. 19. 262144. 2.93. 14. 20. 524288. 1.84. 10. 當樹高為 1 的時候，FBHTree 會是一個由約 71 萬個檔案用 LinkList 串聯起來的結構。從表 1 中我們可以看出樹高增加的時候，PB-pair 的碰撞數會越來越少。接下來我們將針對 FBHTree 在不同樹高時放入不同數量的 PB-pair 對稽核速度的影響作探討，我們分別在偶數層的 FBHTree 放入 5 萬、25 萬、50 萬的 PB-pair，然後對隨機 500 個檔案做稽核，取其平均時間，如表 2，觀察碰撞數量對我們的稽核時間有何影響。 18.

(25) 表 2: FBHTree 容納不同數目檔案的操作時間 Tree Height:FBHTree 的樹高 #Files:FBHTree 容納的檔案數目 AVG Collision:Leaf node 的平均碰撞數目 Audit time:Algorithm 1 做了 500 次的平均時間(單位:ms) Update time:Algorithm 2 做了 500 次的平均時間(單位:ms) Tree Height. 1. 2. 4. 6. 8. 10. #Files. AVG Collision. Audit time. Update time. 5萬. 50000.0. 17.21. 19.11. 25 萬. 250000.0. 70.71. 73.66. 50 萬. 500000.0. 130.12. 136.99. 71 萬. 710000.0. 191.62. 201.68. 100 萬. 1000000.0. 257.29. 267.38. 5萬. 25000.0. 9.07. 10.06. 25 萬. 125000.0. 37.68. 42.59. 50 萬. 250000.0. 63.00. 65.95. 71 萬. 358994.0. 96.08. 101.56. 100 萬. 500000.0. 124.77. 134.30. 5萬. 6250.0. 2.77. 3.89. 25 萬. 31250.0. 10.90. 12.87. 50 萬. 62500.0. 17.11. 20.06. 71 萬. 89748.5. 27.57. 34.81. 100 萬. 125000.0. 31.90. 34.12. 5萬. 1562.5. 0.83. 2.12. 25 萬. 7812.5. 3.19. 7.05. 50 萬. 15625.0. 5.10. 7.21. 71 萬. 22437.1. 7.10. 9.13. 100 萬. 31250.0. 9.30. 11.58. 5萬. 390.6. 0.28. 1.24. 25 萬. 1953.1. 0.92. 3.35. 50 萬. 3906.3. 1.65. 3.54. 71 萬. 5609.3. 2.26. 4.02. 100 萬. 7812.5. 3.09. 7.29. 5萬. 97.7. 0.11. 0.97. 25 萬. 488.3. 0.26. 1.88. 50 萬. 976.6. 0.47. 2.18. 71 萬. 1402.3. 0.57. 1.49. 19.

(26) 12. 14. 16. 18. 20. 100 萬. 1953.1. 0.83. 2.23. 5萬. 24.4. 0.08. 0.76. 25 萬. 122.1. 0.06. 1.57. 50 萬. 244.1. 0.23. 2.3. 71 萬. 350.6. 0.22. 1.9. 100 萬. 488.3. 0.35. 2.64. 5萬. 6.1. 0.07. 0.83. 25 萬. 30.5. 0.08. 1.77. 50 萬. 61.0. 0.12. 2.09. 71 萬. 87.6. 0.09. 1.92. 100 萬. 122.1. 0.08. 1.89. 5萬. 2.0. 0.03. 0.94. 25 萬. 7.6. 0.09. 1.64. 50 萬. 15.3. 0.07. 1.94. 71 萬. 21.9. 0.10. 1.64. 100 萬. 30.5. 0.04. 2.24. 5萬. 1.2. 0.09. 1.1. 25 萬. 2.2. 0.09. 1.86. 50 萬. 3.9. 0.08. 1.47. 71 萬. 5.5. 0.07. 1.71. 100 萬. 7.6. 0.06. 3.27. 5萬. 1.0. 0.09. 1.53. 25 萬. 1.3. 0.1. 1.99. 50 萬. 1.6. 0.07. 1.57. 71 萬. 1.8. 0.08. 4.21. 100 萬. 2.2. 0.14. 3.26. 我們將表 2 表示成折線圖，如圖 10。. 20.

(27) 圖 10: FBHTree 容納不同數目檔案稽核和更新時間折線圖. 5萬個檔案. 毫秒. 25萬個檔案. 2.5. 8 7. 2. 6 5. 1.5. 4 1. 3 2. 0.5. 1 0. 0 6. 8. 10. 12. 14. Audit. 16. 18. 6. 20. 8. 10. 12. Audit. Update. 50萬個檔案. 14. 16. 18. 20. Update. 71萬個檔案. 8. 10. 7. 8. 6 5. 6. 4 4. 3 2. 2. 1 0. 0 6. 8. 10. 12. 14. Audit. 16. 18. 20. 6. 8. Update. 10. Audit. 100萬個檔案 14 12 10 8 6 4 2 0 6. 12. 8. 10. 12. Audit. 14. 16 Update. 21. 18. 20. 14. 16 Update. 18. 20.

(28) 從圖 10 可以看出，在樹高少的 FBHTree 中，因為 PB-pair 碰撞的數量比較多，所以需要花比較多的時間串聯 PB-pair 計算 Hash 值，而樹高超過 12 層之後碰撞數量減少，但是計算 Hash 的時間仍會遞增，所以時間仍然會維持在同一個時間區間中，在這邊我們可以知道，只要將 FBHTree 的樹高設定在 10 之後，稽核速度會是較佳的。接下來的部分是初始化的時間測試，假設我們首次使用的 VM 在第一次開啟時是安全沒有被篡改過的狀態，在首次使用時，我們必須先將安全 Library 的狀態儲存起來，我們分別實作了論文中提到的三種檢測方法 Integrity checking、 Merkle tree 以及 FBHTree。表 3 為首次使用服務時所建立 Hash Map、Merkle tree，Integrity checking 的方法我們利用 java.util.HashMap 將檔案的絕對路徑以及檔案 Hash 值儲存成一個 <Key,Value>的 HashMap 來實作。我們在計算這些檔案的 Hash 值時就花了 509.227 秒。表 3: Integrity checking 以及 Merkle Tree 的初始化比較檢測方法. Cost Time(s). Size(MB). Integrity checking. 516.086. 147.6. Merkle tree. 566.482. 87.2. 表 4 為首次使用服務時所建立 FBHTree 所花的時間以及其建立之後所佔用的容量大小，FBHTree 的初始化會先將 FBHTree 的節點以及指標結構建構起來，然後在將檔案名稱以及檔案的 Hash 值利用 Index function 一個一個放入 FBHTree，我們分別對 1~20 層樹高做了測試。 22.

(29) 表 4: FBHTree 各個樹高的比較 Tree Height. Cost Time(s). Size(MB). 1. 522.621. 147.6. 2. 520.177. 147.6. 3. 518.591. 147.6. 4. 517.993. 147.6. 5. 518.092. 147.6. 6. 518.315. 147.6. 7. 518.167. 147.6. 8. 518.776. 147.7. 9. 518.692. 147.7. 10. 518.562. 147.8. 11. 518.164. 147.9. 12. 518.298. 148.2. 13. 518.487. 148.8. 14. 518.757. 150.0. 15. 518.731. 152.4. 16. 518.914. 157.2. 17. 519.331. 166.8. 18. 520.682. 185.9. 19. 520.769. 223.6. 20. 520.037. 296.4. 在時間上，從表 3 中我們可以看出，Merkle tree 因為多包含了資料夾的 Hash 值計算，所以會比 Integrity checking 的方法費時許多，表 4 中 FBHTree 在初始化建立的時間並不會比 Integrity checking 的方法多出太多，在樹高層數低的 FBHTree，因為碰撞數非常大，所以會花費比較多一點的時間在新增的 PB-pair 串接上，而在層數高的 FBHTree，雖然碰撞數低，但是因為節點數量非常多，在建立 FBHTree 的結構的時間會比較多。在容量大小上，因為 HashMap 以及 FBHTree 在檔案名稱儲存的是檔案的絕對路徑，而 Merkle Tree 在檔案名稱的儲存上只需要儲存檔名，雖然 Merkle Tree 23.

(30) 的方法當中多了 14 萬個資料夾名稱和 Hash 值的儲存，但是檔案數量大於資料夾數量非常多，所以儲存的字串相較起來 HashMap 以及 FBHTree 所儲存的字串長度還是比較大，所以在容量上 Merkle Tree 會小非常多。在容量上，雖然 FBHTree 的容量比 HashMap 的還要大，但是如果使用我們方法，用戶只需要儲存一個 32byte 的 Root hash 值，大幅減少用戶儲存上的負擔。表 5 為 Integrity checking 的方法稽核和更新一個檔案所需的時間，Audit 我們利用 java.Util.HashMap 中的 Method：get()來取得每個檔案的 Hash 值並且跟 VM 上的 Library 檔案 Hash 值比對，速度是非常快的， Update 則是利用 java.Util.HashMap 中的 Method：put()來將檔案的 Hash 值更新，因為需要置換 Hash 值所以時間上會比較慢一些。然而 HashMap 的方法，是無法做到 Proof of Violation 的。表 5: Integrity checking 稽核和更新一個檔案所需的時間 Audit time. Update time. 0.003. 0.08. 接下來是 Merkle Tree 稽核和更新一個檔案所需時間，如表 6，Audit 是將所需要用到的檔案利用 Partial Merkle Tree 方法計算出 Root hash 跟另外保存的 Root hash 做比對，Update 也是利用 Partial Merkle Tree 的方法更新檔案的 Hash 值。表 6: Merkle tree 稽核和更新一個檔案所需時間 Audit time. Update time. 6.83. 18.51. 在 Merkle tree 的方法中需要串聯許多同一層的檔案以及資料夾 Hash 值，再將這些串聯起來的 Hash 值取一次 Hash，所以花非常多的時間。但是在 Merkle tree 24.

(31) 的方法中我們是可以達成 Proof of Violation 的。接下來的實驗，我們用了幾個在 Mac 上面的常見應用程式來做測試，在程式執行時都會呼叫動態函式庫，我們分別對 LINE、Mail、FaceTime、Pages 這幾個應用程式做了測試。首先，我們以 LINE 來做範例說明，在 terminal 中進入應用程式 LINE.app/Contents/MacOS 的資料夾以後，輸入指令”otool –L LINE”，就可以找到 LINE 在執行程式時會需要用到的動態函式庫。表中為對這幾個應用程式所需要用到的動態函式庫檔案做稽核的時間。 Integrity checking 的方法我們使用 java.Util.HashMap 中的 Method:getValue()來找出儲存起來的 HashMap 中檔案的 Hash 值，並且跟函式庫中的檔案計算 Hash 後做比對。而 Merkle Tree 代表改良過後的 partial Merkle Tree 的方法，將所需要的檔案 partial 重新做一次 Hash 計算得出 Root Hash 以後跟所保存的 Root Hash 做比對。FBHTree 的方法為將 FBHTree 中對應檔案的 Slice 找出來後推導 Root Hash 後，在將其與保存的 Root Hash 做比對。在 FBHTree 的實作上我們分別列出了偶數層數的樹高的 FBHTree 來做觀察，而三個方法我們分別都做了 500 次然後取其平均值。表 7、表 8、表 9、表 10 中我們可以看到，Merkle tree 的方法非常費時，是因為當同一層的檔案或者資料夾數量非常多的時候，在串連這些資料夾或者檔案的 Hash 值就會花費非常多的時間，所以在這樣的情況下會比我們所提出的方法來的耗時。當我們的 FBHTree 建立在樹高 10 之後，我們所提出的 FBHTree 方 25.

(32) 法稽核的時間都是非常接近的，從數據上我們可以看出，在 70 萬個檔案的情況下，我們將 FBHTree 的樹高設定超過 16 時，稽核速度會是較佳的，而且稽核速度會跟 Integrity checking 的作法非常接近。. 表 7: Integrity checking、<Key,Value>+POV、Merkle Tree 應用程式檢測時間（ms） Application 只取 Hash. FaceTime. LINE. Pages. Mail. 2214. 1241. 3283. 3059. Integrity checking. 2214.03. 1241.02. 3283.03. 3059.03. <Key, Value>+POV. 13251.24. 5839.72. 8985.14. 10701.81. Merkle Tree. 2631.32. 1600.37. 3986.86. 3586.14. 表 8:FBHTree 的應用程式檢測時間(單位:ms) Application. FaceTime. LINE. Pages. Mail. 2. 7844.22. 3585.57. 6167.55. 6900.70. 4. 3664.80. 1853.77. 4031.34. 4048.33. 6. 2649.86. 1413.86. 3502.17. 3356.66. 8. 2360.94. 1298.14. 3353.99. 3159.45. 10. 2247.48. 1256.75. 3296.95. 3079.50. 12. 2228.88. 1245.80. 3287.03. 3069.25. 14. 2222.06. 1242.53. 3285.48. 3063.10. 16. 2217.72. 1243.25. 3286.10. 3062.69. 18. 2220.82. 1243.17. 3285.17. 3062.69. 20. 2219.58. 1242.48. 3285.11. 3061.05. Tree Height. 表 9: Integrity checking、<Key,Value>+POV、Merkle Tree 應用程式檢測時間 2 Application 只取 Hash. Maps(ms) 767. Calender(ms) 1069. Preview(ms) 703. Photos(ms) 2481. Integrity checking. 767.02. 1069.02. 703.02. 2481.03. <Key,Value>+POV. 7089.80. 9146.04. 6577.50. 13990.68. Merkle Tree. 1671.14. 1960.27. 1623.95. 5923.20. 26.

(33) 表 10: FBHTree 的應用程式檢測時間 2(單位:ms) Application. Maps. Calender. Preview. Photos. 2. 3932.06. 4984.24. 3498.27. 8308.38. 4. 1590.14. 2081.20. 1441.42. 4031.62. 6. 1008.40. 1368.88. 919.38. 2922.44. 8. 847.26. 1166.02. 778.95. 2626.08. 10. 784.00. 1089.58. 730.28. 2515.72. 12. 772.44. 1077.40. 709.20. 2490.30. 14. 769.72. 1073.20. 709.20. 2487.20. 16. 770.40. 1070.26. 704.86. 2488.44. 18. 769.04. 1072.36. 704.55. 2485.96. 20. 769.72. 1071.94. 705.48. 2485.96. Tree Height. 雖然在稽核時間上，我們的方法會比 Integrity checking 的方法慢了一些，但是我們的方法也大幅的減少用戶在儲存這些用來稽核的 Hash 值的空間成本，而且我們的方法可以是達到 POV 的成效，而 Integrity checking 並沒有辦法達成 POV。. 27.

(34) 第四章相關研究探討過去的研究中，Ibrahim, Amani S[7]中曾經提及，虛擬機器為 IaaS 層面中的關鍵角色，而也因為將硬體虛擬化，所以仍然會有許多問題需要解決，作者在 VM 當中架設一個監視器來觀察 memory 有無的異常活動。Wei, Jinpeng[8]中也曾經提及，雲端服務提供商安全管理映像檔的重要性，他們提出了一個雲端服務提供商在映像檔使用者存取控制的一套管理系統。而在雲端中 VM 一樣會有中毒的風險，在研究[6]當中，曾經提及可以利用 Integrity check 的方法來做檔案完整性的檢查，以防執行檔被植入病毒。在過去也有很多並非建立於雲端環境中檢測虛擬機器的研究，如 Virtual Machine Introspection 相關研究[10]、Virtual Machine Monitor[11] [12]等。多半於在虛擬機器上置入程式並留下活動紀錄檔，亦有於 OS 下裝設虛擬機器監控等模式，防止有外來的駭客竄改虛擬機器內的資料等檔案；Garfinkel Tal, Ben Pfaff, Jim Chow, Mendel Rosenblum, Dan Boneh 在研究[12]中，發展出 TVMM(Trusted Virtual Machine Monitor)，所有建立於此系統上面的應用如 Email、Web Apps、Online Game、 Management VM 等，皆會與 TVMM 做溝通並且於 TVMM 之下留下證據，此 TVMM 如同一個可信任的第三方，以 inline 的模式經手所有的訊息，但是這樣的信任第三方的假設太過於強大。. 28.

(35) 第五章結論隨著雲端平台服務越來越普及，我們在雲端上使用的服務選擇越來越多元，而在雲端服務的環境上仍然有許多安全性的疑慮，如果雲端平台沒有辦法提供一個可信任的平台，那麼用戶碰到雲端環境發生問題的情況下，我們就無法申訴保障消費者的自我權益，如果只靠著用戶活動記錄當作證據的話，雲端服務提供商有可能在記錄上作假，所以這樣的一個記錄並不具有法律效力，因此我們希望能夠利用即時性的稽核來讓雲端平台成為一個可被信任且安全的環境。在本篇論文中提出了解決雲端環境 IaaS 中虛擬機器安全性的快速稽核應用，雖然在更新的時間上，我們的方法並沒有辦法達到非常快速的成果，但是在稽核檔案上，我們提出的方法並不會比最快速的方法還要增加太多時間，卻大量降低在用戶保存稽核根據容量上的成本負擔。我們甚至可以用這個方法來取代以往的病毒偵測中的 Integrity checking 方法。. 29.

(36) 參考著作 [1] “Amazon EC2,” http://aws.amazon.com/tw/ec2/ [2] “Google App Engine,” https://cloud.google.com/appengine/docs [3] “Amazon AWS,” http://aws.amazon.com/tw/ [4] “Gmail”, https://mail.google.com/mail [5] “Youtube”, https://www.youtube.com/ [6] “JAVA Virtual Machine”, https://www.oracle.com/java/index.html [7] “VirtualBox”, https://www.virtualbox.org/ [8] Gwan-Hwan Hwang, Wei-Sian Huang, Jenn-Zjone Peng. “Real-time proof of violation for cloud storage,” Cloud Computing Technology and Science (CloudCom), 2014 IEEE 6th International Conference on IEEE, 2014. [9] Gwan-Hwan Hwang, Hung-Fu Chen. “Efficient Real-time Auditing and Proof of Violation for Cloud Storage Systems,” Cloud Computing (Cloud),2016 9th IEEE International Conference on Cloud Computing on IEEE ,2016. [10] Mishra, Umakant. “Methods of Virus detection and their limitations,” Available at SSRN 1916708 (2010) [11] Gwan-Hwan. Hwang,. Jenn-ZjonePeng,. Wei-SianHuang.. “A. Mutual. Nonrepudiation Protocol for Cloud Storage with Interchangeable Accesses of a Single Account from Multiple Devices,” The 12th IEEE International Conference 30.

(37) on Trust, Security and Privacy in Computing and Communications (IEEE TrustCom-2013), Melbourne, Australia, 16-18 July. [12] Ibrahim, Amani S, James Hamlyn-Harris, John Grundy and Mohamed Almorsy. “Cloudsec: a security monitoring appliance for virtual machines in the iaas cloud model,” Network and System Security (NSS), 2011 5th International Conference on. IEEE, 2011. [13] Wei, Jinpeng, Xiaolan Zhang, Glenn Ammons, Vasanth Bala, Peng Ning. “Managing. security. of. virtual. machine. images. in. a. cloud. environment,” Proceedings of the 2009 ACM workshop on Cloud computing security. ACM, 2009. [14] Garfinkel, Tal, and Mendel Rosenblum. “A Virtual Machine Introspection Based Architecture for Intrusion Detection.” NDSS. Vol. 3. 2003. Haeberlen, P.Aditya, R.Rodrigues, P.Druschel. “Accountable Virtual Machines, “In Proc. of OSDI, 2010. [15] Rosenblum, Mendel, and Tal Garfinkel. "Virtual machine monitors: Current technology and future trends." Computer 38.5 (2005): 39-47. [16] Garfinkel Tal, Ben Pfaff, Jim Chow, Mendel Rosenblum, Dan Boneh. “Terra: A virtual machine-based platform for trusted computing.” ACM SIGOPS Operating Systems Review. Vol. 37. No. 5. ACM, 2003. 31.

(38)