雲端資料庫之有效率的即時稽核

全文

(1)國立臺灣師範大學資訊工程研究所碩士論文. 指導教授：黃冠寰. 博士. 雲端資料庫之有效率的即時稽核. Efficient Real-Time Auditing for Cloud Database Systems. 研究生：中華民國. 李信德一零七. 年. 撰七. 月.

(2) 摘要雲端資料庫之有效率的即時稽核. 李信德雲端資料庫是一個執行在雲端運算平台的資料庫系統，由雲端服務提供者 (Cloud Service Provider, CSP)負責安裝與維護，使用者只需要支付租金即可使用。但 CSP 可能會洩漏機密數據、修改數據，或是因為系統錯誤、不當操作或是遭受駭客攻擊，造成回傳不一致的數據給使用者。某些雲端資料庫有提供 Web interface 或 API (Application programming interface)給使用者查閱日誌檔，但是日誌檔並不是密碼學證據，不能用來證明 CSP 違反 Query Integrity 與 Transaction Serializability。即時稽核架構應該符合以下兩點，CSP 在租借資料庫給用戶時，用戶能夠在執行 query 時，透過用戶的證據作即時性稽核，避免 CSP 回傳錯誤的數據。在拿到錯誤的數據時，可以透過用戶的證據證明雲端資料庫發生資料不一致的責任歸屬。為快速稽核資料，通常會使用大量 CPU 資源運算 Hash Function，本篇論文提出的做法可以有效降低稽核時 CPU 耗能，使伺服器能在使用相同的計算量服務更多的使用者。. 關鍵字：雲端資料庫、雲端安全、不可否認性、違約證明.

(3) 致謝時光荏苒而逝，轉瞬兩年碩士班求學光陰即過。回首細數這段學習過程，培養的不單限於專業素養，亦增加問題思考的邏輯性，並在討論過程中學習如何應對進退的智慧與態度；然而，一切成果絕非憑我一己之力得以達成，僅由寥寥數語表達我心中難以言喻的感激。首先獻上由衷敬意感謝指導教授黃冠寰老師，於這段時間內不單指導學生研究之外，還引導學生如何去發現問題、理解問題並且解決問題，並時時督促學生改進缺失、檢討不足之處，使學生無論求學與為人處事都有所精進，心中感激實難以片言隻語盡述。還要感謝兩年中遇到的學長以及朋友們，感謝鄭安傑學長、黃鯤義學長，在我不懂的時候可以耐心的教導我，以及給我很多建議和方向。感謝這兩年來跟我一起奮鬥的同學們人恩、承翰、聖翰，謝謝你們在這兩年中也教了我許多，還有一起陪伴我在實驗室奮戰的日子。最後，感謝家人支持我完成碩士班學業，求學的過程裡不免經常備感壓力或遭遇挫折，若無您們的包容與溫暖一切將變得寸步難行。感謝在研究過程中所有曾經給予我幫助的人，無法一一答謝，謹此透過本篇論文表達內心最誠摯的感激。李信德. 誌於. 國立臺灣師範大學資訊工程所民國. iii. 107 年 5 月.

(4) 目錄. 摘要................................................................................................................................ii 致謝.............................................................................................................................. iii 目錄............................................................................................................................... iv 附表目錄....................................................................................................................... vi 附圖目錄......................................................................................................................vii 第一章緒論................................................................................................................ 1 第一節雲端儲存................................................................................................ 1 第二節雲端資料庫的問題................................................................................ 1 第三節證明違約協定........................................................................................ 2 第四節目標........................................................................................................ 3 第二章過往的作法.................................................................................................... 4 第一節 Hash Function ........................................................................................ 4 第二節 Signature Aggregation ........................................................................... 4 第三節 B+ Tree .................................................................................................. 5 第三章即時稽核架構.............................................................................................. 10 第一節 Index Merkle Tree ................................................................................ 11 1.1 資料結構............................................................................................. 11 1.2 SQL 指令結果之稽核流程 ................................................................ 12 1.3 稽核細節............................................................................................. 15 1.4 Range Selection .................................................................................. 16 1.5 問題..................................................................................................... 17 第二節 Aggregate Hash .................................................................................... 17 2.1. 資料結構............................................................................................. 17. 2.2 2.3. SQL 指令結果之稽核流程 ................................................................ 18 稽核細節............................................................................................. 20. 2.4 Range Selection .................................................................................. 21 第四章相關實驗數據.............................................................................................. 22 第一節 B+ Tree 相關數據 ............................................................................... 22 第一段定位問題...................................................................................... 22 第二段分裂問題...................................................................................... 23 第三段過度集中問題.............................................................................. 24 第四段 B+ Tree 稽核 .............................................................................. 25 第二節 Index Merkle Tree 相關數據 ............................................................... 27 iv.

(5) 第一段 Index function Γ 的碰撞測試 .................................................... 27 第二段不同樹高的記憶體比較.............................................................. 28 第三段 Index Merkle Tree 稽核 ............................................................... 29 第三節 Aggregate Hash 相關數據 ................................................................... 30 第一段 Index function Γ 的碰撞測試 .................................................... 30 第二段 Aggregate Hash 稽核 .................................................................. 30 第四節綜合比較.............................................................................................. 31 第一段單點稽核比較.............................................................................. 32 第二段範圍查找稽核比較...................................................................... 33 第三段耗能比較...................................................................................... 34 第五章結論.............................................................................................................. 35 第六章參考著作...................................................................................................... 36. v.

(6) 附表目錄表表表表表表. 1 2 3 4 5 6. B+ Tree 不同樹高的平均定位時間 ............................................... 23 B+ Tree 不同樹高重建二元樹所需時間 ....................................... 23 B+ Tree 資料過度集中問題 .......................................................... 24 B+ Tree 子數平均層數 .................................................................. 25 B+ Tree 本機測試數據 .................................................................. 26 B+ Tree 同網段測試數據 .............................................................. 26. 表表表表表. 7 8 9 10 11. B+ Tree 不同網段測試數據 .......................................................... 27 IMT 碰撞測試 ................................................................................. 28 IMT 不同樹高的記憶體比較 ......................................................... 28 IMT 不同層數的稽核時間 ........................................................... 30 Aggregate Hash 不同 slot 數的稽核時間 ..................................... 31. 表表表表. 12 13 14 15. 綜合比較(本機測試) ..................................................................... 32 綜合比較(同網段測試) ................................................................. 33 綜合比較(不同網段測試) ............................................................. 33 範圍查找的比較數據.................................................................... 34. 表 16. 耗能比較........................................................................................ 34. vi.

(7) 附圖目錄圖圖圖圖圖圖. 1 2 3 4 5 6. 範例 B+ Tree ..................................................................................... 6 範例 Full Binary Hash Tree ............................................................... 6 B+ Tree 分裂問題示意圖(分列前) ................................................... 8 B+ Tree 分裂問題示意圖(分裂後) ................................................... 8 B+ Tree 建立子樹示意圖 ................................................................. 9 B+ Tree 子樹資料過度集中示意圖 ................................................. 9. 圖圖圖圖圖. 7 8 9 10 11. 即時稽核架構.................................................................................. 11 IMT 資料結構 ................................................................................. 12 Slice 示意圖..................................................................................... 15 用 Slice 稽核.................................................................................. 16 資料庫查詢結果 ............................................................................ 17. vii.

(8) 第一章第一節. 緒論. 雲端儲存. 雲端儲存(Cloud storage)[1]是一種網路線上儲存，將資料存放在雲端服務提供者(Cloud Service Provider, CSP)的伺服器上，使用者只需要依照使用的儲存空間支付費用，不需要自行添購儲存裝置，減少大量硬體與管理的成本。本文僅針對雲端儲存中的雲端資料庫(Cloud database)進行探討。雲端資料庫是一種執行在雲端運算平台的資料庫，雲端運算平台以提供資料庫作為服務(Database as a service, DBaaS)，使用者不需要自行架設、維護資料庫，由 CSP 負責安裝與維護資料庫。資料庫在雲端上支援兩種資料模型，分為透過結構化查詢語言(Structured Query Language, SQL)[2]存取資料與不使用 SQL 作為查詢語言(Not Only SQL, NoSQL)[3]存取資料，本文僅探討應用 SQL 存取資料的關聯式資料庫系統，使用者只需透過 SQL 語法就能讀寫資料庫。. 第二節. 雲端資料庫的問題. 雖然雲端服務帶來相當大的好處與便利性，但是將所有資料儲存在雲端伺服器上，使用者不免會擔心資料的正確性與完整性。由於使用者透過雲端資料庫提供的服務無法直接觸及資料庫實體以外的檔案，像是資料庫的設定檔、日誌檔 (Log)，某些雲端資料庫例如 Google 的 Cloud SQL[4]、Amazon 的 RDS for MySQL[5]可透過 Web interface 或是 API (Application programming interface)讀取. 1.

(9) 日誌檔，但使用者還是無法驗證日誌檔的正確性，除非將日誌檔交給公正的第三方所保管，但也有可能 CSP 基於利益與第三方共謀竄改，為確保資料庫的資料正確，使用者與 CSP 之間必須要明定一些驗證機制。當用戶在雲端資料庫上儲存一系列的資料後，如果要確保這些資料的完整性，用戶端必須對資料庫進行驗證，稱作稽核(Auditing)。用戶端在使用資料庫時，可以根據自己手邊的證據確認 SQL 指令回傳的資料是否正確，但是當用戶稽核到不正確的資料時，還需要一些密碼學證據以釐清資料不正確的責任歸屬，使用者與 CSP 必須協定一個合約以維護問題發生時雙方的權益，稱為證明違約協定 (Proof of Violation, POV)[6][7][8][9]，會在下一節詳細說明。. 第三節. 證明違約協定. 證明違約協定提供 CSP 與使用者之前的不可否認性，當有問題產生時，能證明雙方有沒有過失。為達到不可否認性，CSP 與使用者之間可以建立一個商業合約，這個合約會依照用戶想要的安全層級來定價，如果 CSP 管理的資料有被竊取或竄改，則須給付用戶一些合約中簽訂的賠償金。當用戶在使用 CSP 的服務時，對每一個動作皆會產生一組密碼學證據(Cryptographic attestation)，這些證據都是經過雙方簽證過的訊息(Signed messages)。在 POV 的論文中提到，POV 可分為 Epoch-based POV 以及 Real-time POV。其中 Epoch-based POV 是指用戶與服務提供者會設定一個時期(Epoch)，在時期還沒到之前，雲端服務提供商必須蒐集所有用戶使用服務時的動作及結果，當時 2.

(10) 期一到，雲端服務提供商必須與用戶端將所有的動作及結果做一次性的稽核，更新證據到最新狀態，然而這個方法卻沒辦法在每一次使用服務時檢查服務提供者是否有過失。Real-time POV 則是在用戶使用服務時，可以在非常短的時間內透過用戶手中的密碼學證據稽核此次的動作結果，下一節將敘述我們希望在雲端資料庫上可以達到的目標。. 第四節. 目標. 在租用雲端資料庫後，由於個人或是公司的資料皆放在 CSP 的伺服器上， CSP 可能惡意的將敏感資料進行竄改，另一方面，也有可能因為伺服器出問題，導致資料庫的最新資料遺失或是不正確，CSP 進而試圖將資料庫還原成過去的版本，藉由上述的兩個簡短案例，希望在使用雲端資料庫前，能透過即時稽核以及證明違約協定快速的驗證資料庫，以確保資料安全無慮。即時稽核方式分別使用 B+ Tree、Index Merkle Tree 以及 Aggregate Hash 三種資料結構進行，相關細節將會在第三章介紹。. 3.

(11) 第二章第一節. 過往的作法 Hash Function. 雜湊函式(Hash Function)錯誤! 找不到參照來源。是一種可以從任何一種資料中建立指紋的方法，將資料壓縮成一個固定長度的雜湊值(Hash value)，所有雜湊都有一個基本特性，如果兩個雜湊值不相同，則兩個雜湊值的輸入即不相同。若將雜湊函式應用在資料庫稽核中，用戶在新增一筆資料到雲端資料庫時，對上傳的每一行(row)使用 SHA-256 演算法計算出雜湊值，計算出的雜湊值由用戶端保存，當要稽核資料時，用戶先從伺服器下載要稽核的那一行資料，再將該筆資料計算出雜湊值，從用戶端儲存的雜湊值中去比對，這樣即可完成檔案稽核。這種方式是資料庫稽核中最直覺的方式，使用這種方式有兩個缺點：用戶上傳資料時就需要儲存一個新的雜湊值，隨著上傳的數量增多，需要儲存的雜湊值也增加，因此用戶需要大量的硬碟空間儲存大量的雜湊值。這個方式無法有效率的支援證明違約協定。. 第二節. Signature Aggregation. 在[10]當中提到一個對資料庫稽核的方法，當使用者上傳一系列的資料到雲端資料庫時，使用者會對每一筆資料使用 SHA-256 演算法計算出雜湊值，將雜湊值透過運算產生數位簽章(Digital Signature)，並儲存在雲端服務提供者的伺服器上，當使用者想要驗證雲端資料庫中的資料是否遭到竄改等等的惡意動作時，. 4.

(12) 可以下載這些數位簽章稽核所對應資料是否相符。為了節省用戶端下載所有資料的簽章時間，這篇論文提出了一個作法 Signature Aggregation，將所有資料的簽章透過合併運算合併成一個簽章，用戶端僅需要下載合併的簽章及所有資料就可以做一次完整性的稽核。然而透過這樣的驗證方式沒辦法防止 rollback attack[11]， rollback attack 是指當雲端資料庫發生毀損時，假設服務提供商企圖將資料庫還原成舊有的版本，使用者只能驗證資料庫的完整性，沒辦法證明資料是舊的，另外 Signature Aggregation 這個做法雖然將多筆資料的簽章合併成一個簽章以減少用戶端下載證據的時間，但是在稽核資料時卻還是得將查詢的資料結果一一做簽章，接著合併後與服務提供者回傳的合併簽章做比對，這樣的稽核動作在資料量大的情況下還是會耗費很多時間，詳細數據會在第四章呈現。. B+ Tree. 第三節. 在[12]當中提到一個對於資料庫稽核的方法，其資料結構使用 B+Tree[13]與 Full Binary Hash Tree，B+Tree 是一種樹資料結構，使用(index, value)的格式儲存資料，特點是儲存的資料是用 index 排序過的，將這個特性運用在資料庫稽核上可以在範圍查找(Range Select)中獲得很好的效率。其稽核的方式是將資料庫中取一個欄位作為 index，將每個 row 用 SHA-256 計算雜湊值，將雜湊值作為 value，用這個方式將整個資料庫中的所有資料存到 B+Tree 中，如圖 1，之後將 B+Tree 中每個葉節點(LeafNode)計算出一個雜湊值，按照順序放到一個 Full Binary Hash Tree，如圖 2，從葉節點將資料一層一層計算 5.

(13) 雜湊值，直到運算出樹頂端的雜湊值稱之為 Root Hash。因為密碼學加密函數的特性，倘若有修改過其中一個節點的值，那麼就會得出不同的 Root Hash，所以我們可以用 Root Hash 來驗證整個資料庫的完整性。這個 Root Hash 要經過用戶與伺服器交互簽章，讓雙方不能否認這個證據以支援 POV。. 圖 1. 圖 2. 範例 B+ Tree. 範例 Full Binary Hash Tree. 稽核資料庫時，假設要稽核 id=40 的資料，要先向伺服器提出稽核，伺服器先從 B+Tree 中找到資料所在的葉節點，接著定位葉節點的編號，到 Merkle Hash Tree 中取得第 4 個葉節點的 slice，如圖 2 圈起來的部分，將要稽核的該筆資料與 slice 回傳給用戶，用戶即可利用回傳的資料計算雜湊值，與自己保留的 Root. 6.

(14) Hash 進行比對，如果相等則稽核完成。如果要稽核的資料比較靠右側，則會造成定位的時間拉長，這個是 B+Tree 架構的第一個問題。若要進行範圍查詢時，假設我們向資料庫查詢 10<id<34 的資料時，服務提供者除了回傳資料結果外，會透過 B+Tree 取出 E2、E3，另外將 Merkle Hash Tree 中包括 E2、E3 的 Partial Merkle Tree 回傳給用戶端進行做稽核，所以稽核速度會非常快。新增刪除資料時，與稽核的步驟類似，先將資料欲插入的 B+Tree 葉節點與對應的 slice 回傳給使用者稽核，將資料插入後，用戶與伺服器同時做更新 slice 的動作，取出的 Root Hash 雙方進行比對，若無誤則進行交互簽章，以支援 POV。但是 B+Tree 有自動平衡的特性，有時候在插入資料會造成節點分裂或合併的情況，如圖 3，假設 B+Tree 的 Max degree = 5，如果插入 id = 82 時會造成 E7 這個葉節點分裂，對應到 Merkle Hash Tree 上時，E7 右邊的所有葉節點都要往右移一格，如圖 4，要更新的 Partial Merkle Tree 會比未分裂的狀況多很多，這個是 B+Tree 架構的第二個問題。. 7.

(15) 64 90 66 78. 23 32 35. 78. 23 24. 32 33. 35 40 55. 96 99. 64 65. 66 68. 78 80 89. 90 95. 96 97. 99 101. ....... Root Hash. H1~8. H9|10. H12|34. H1|2. E1. H56|78. H3|4. E2. E3. H9|10. H7|8. H5|6. E4. E5. 圖 3. E6. E7. H9|10. E8. E9. E10. B+ Tree 分裂問題示意圖(分列前) Root Hash. H9|10. H1~8. H12|34. H1|2. E1. H56|78. H3|4. E2. E3. H9|10. H7|8. H5|6. E4. E5. E6. E7. H9|10. E8. E9. E10. Right shift. Root Hash. H89|10. H1~8. H12|34. H1|2. E1. E2. H56|78. H3|4. E3. E4. 圖 4. H7|8. H5|6. E5’. E6. H89|10. E7. H8|9. E7’. E8. E9. H10. E10. B+ Tree 分裂問題示意圖(分裂後) 8.

(16) 為了解決這兩個問題，作者使用限制 B+Tree 高度的作法，先規定 B+Tree 成長到指定高度時就停止分裂，當葉節點中內容數量超過 Max degree 時，以建立子樹的方式取代分裂，如圖 5，B+Tree 的子樹也對應產生一個 Merkle Hash Tree，用相同的方式去建立。新增、刪除與稽核的方式與原先的方式相同。. 圖 5. 圖 6. B+ Tree 建立子樹示意圖. B+ Tree 子樹資料過度集中示意圖. 雖然解決了定位與分裂的問題，卻產生了新的問題，若資料過度集中於某一個特定範圍，可能會造成如圖 6 的狀況，但是這種狀況不易產生，詳細的數據將在第四章呈現。. 9.

(17) 第三章即時稽核架構在這個章節中會呈現用戶使用雲端資料庫時，向雲端資料庫下 SQL 指令時，如何對雲端資料庫做完整性的檢驗，並且將驗證結果存放在一個安全的裝置上，提供用戶下次使用雲端資料庫時可以即時稽核資料庫的完整性。在即時稽核架構中使用兩種不同的資料結構來完成，但是流程上是差不多的，會先將資料庫中的每一筆 row，使用 SHA-256 演算法來計算雜湊值(Hash)存進不同的資料結構，用戶只需要保留部分證據就可以不怕資料庫遭人竄改。在介紹資料結構之前，先介紹即時稽核架構，如圖 7。在即時稽核架構中，用戶端裝置會與 CSP 共同協定並租用一個同步伺服器(Synchronization Server)，接著用戶端裝置會向 CSP 上傳資料，CSP 會針對每一筆資料產生 Hash，並將這些 Hash 存入資料結構中，而該資料結構會儲存在 CSP 的伺服器上，最後 CSP 會回傳證據給用戶端裝置，用戶端裝置則將最新的證據上傳到同步伺服器。每當用戶端裝置使用雲端資料庫前，會先向同步伺服器下載最新的證據，接著向雲端資料庫下指令，此時 CSP 回傳的資料可以利用用戶端的證據進行即時稽核。. 10.

(18) Synchronization Server. Client Devices. Service Provider(SP) DB TableA. row1. …. (γ, SN, Sigsp). …. TableB. rowN. row1. …. rowM. FBHTree. γ, SN. 圖 7. 第一節. 即時稽核架構. Index Merkle Tree 1.1. 資料結構. 在這一節中，將會介紹實驗室的研究成果Index Merkle Tree(以下簡稱為IMT)。 IMT是一個二元樹，可以分為3個部分：葉節點、內節點、根節點。在建立IMT之前，要先決定以哪一種Condition來進行建樹，例如：使用資料庫中的ID欄位。接著使用一個Index function Γ 計算來得到其該存放到指定葉節點的位置，此Index function Γ 如下。 𝚪(𝐂𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧) = 𝐒𝐇𝐀𝟐𝟓𝟔(𝐂𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧) 𝐦𝐨𝐝 𝟐𝐍−𝟏 其中 N 為樹高，Condition 為使用者查詢資料時經常使用的欄位條件，例如 id=10、22000<Salary<50000 等。定位後將那一筆 row 的證據儲存在葉節點，葉節點是利用(key, value)的方式儲存，儲存格式如下。 𝐱 = 𝚪(𝐂𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧) 11.

(19) 𝐤𝐞𝐲 = 𝐂𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧 𝐯𝐚𝐥𝐮𝐞 = [𝐡(𝐫𝐨𝐰𝐡𝐚𝐬𝐡(𝐱)), 𝐡(𝐫𝐨𝐰𝐡𝐚𝐬𝐡(𝐱 − 𝟏)), 𝐡(𝐫𝐨𝐰𝐡𝐚𝐬𝐡(𝐱 + 𝟏))] 每一個內節點都代表著，其左子節點的 Hash 值和其右子節點的 Hash 值，兩者串連起來再做一次計算所得出來的 Hash 值，重複著以上的步驟，由樹的最底層，一層一層往上運算，就可以得出根節點的 Hash 值，而這個根節點的 Hash 值我們稱之為此 IMT 的 Root Hash，就是我們可以拿來對雲端資料庫作稽核的一個依據，Root Hash 還要交由雙方進行簽章並互相保存以支援 POV。 IMT 在儲存方式上使用一維陣列來儲存，如圖 8 所示，每個葉節點 ID(以 I 表示)，都可以轉換成一個 Tree node ID(以 X 表示)，轉換的表示式為X = 2N− + I。從 Γ 得出葉節點 ID 以後，我們可以根據這個公式來快速的找到每個節點的 Hash 值被存放到一維陣列中的哪個位置。. 1 2 4. 3 5. 6. 0. 1. 2. 3. 4. 5. 6. 7. 7. 圖 8 1.2. IMT 資料結構. SQL 指令結果之稽核流程. 在即時稽核架構中，分別有同步伺服器、用戶端裝置、雲端服務提供者三個. 12.

(20) 角色，我們將介紹在每一個 SQL 指令中，稽核的詳細流程。 Select operation: Step1: 用戶端向同步伺服器拿最新的 Root hash Step2: 用戶端向雲端資料庫發出 Select operation 請求 Step3: 服務提供者將 Select operation 結果及 IMT 中對應的 slice 取出 Step4: 服務提供者回傳 Select operation 結果及 IMT 中對應的 slice Step5: 用戶端透過 Select operation 結果及 IMT 中對應的 slice 做稽核 Step6: 用戶端稽核完成，告知服務提供者 Insert operation: Step1: 用戶端向同步伺服器拿最新的 Root hash Step2: 用戶端向雲端資料庫發出 Insert operation 請求 Step3: 服務提供者將 Insert operation 結果及 IMT 中對應舊的 slice 取出並計算新的 slice 及 Root Hash Step4: 服務提供者回傳 Insert operation 結果、IMT 中對應舊的 slice、更新後的 slice、Root Hash 及針對 Root Hash 所作簽章 Step5: 用戶端稽核舊的 slice 並更新 slice 算出 Root Hash Step6: 用戶端更新完成，回傳新的 Root Hash 及雙方簽章給服務提供者及同步伺服器 Delete operation: 13.

(21) Step1: 用戶端向同步伺服器拿最新的 Root hash Step2: 用戶端向雲端資料庫發出 Delete operation 請求 Step3: 服務提供者將 Delete operation 結果及 IMT 中對應舊的 slice 取出並計算新的 slice 及 Root Hash Step4: 服務提供者回傳 Delete operation 結果、IMT 中對應舊的 slice 及更新後的 slice Step5: 用戶端稽核舊的 slice 並更新 slice 算出 Root Hash Step6: 用戶端更新完成，回傳新的 Root Hash 及雙方簽章給服務提供者及同步伺服器 Update operation: Step1: 用戶端向同步伺服器拿最新的 Root hash Step2: 用戶端向雲端資料庫發出 Update operation 請求 Step3: 服務提供者將 Update operation 結果及 IMT 中對應舊的 slice 取出並計算新的 slice 及 Root Hash Step4: 服務提供者回傳 Update operation 結果、IMT 中對應舊的 slice 及更新後的 slice Step5: 用戶端稽核舊的 slice 並更新 slice 算出 Root Hash Step6: 用戶端更新完成，回傳新的 Root Hash 及雙方簽章給服務提供者及同步伺服器 14.

(22) 1.3. 稽核細節. 當用戶向雲端服務提供者提出 query 請求前，需先向同步伺服器拿取最新的 Root hash，query 請求後，服務提供者需產生 Condition 資料相符的 Slice 資訊，如圖 9。回傳 Slice 與 query 結果後，用戶須先使用 query 的結果取 Hash，接著使用 Slice 回推 Root Hash，如圖 10，如果獲得的結果與在同步伺服器的內容相符的話，稽核成功，若失敗，則以服務提供者所回傳的資訊與保存的雙方簽章作為證據，要求服務提供者進行賠償。 Slice of IMT= Root node | Left Internal node | Right internal node |…| Left PB-pair | Right PB-pair. Slice. :Root Node :Internal node. 樹高= 9. :PB-pair. 圖 9. Slice 示意圖. 15.

(23) Slice (Compare). Root hash. Client device. Leaf node ID=166. A.row1 B.row10. 圖 10 1.4. 用 Slice 稽核. Range Selection. 在使用資料庫時，我們常常會對雲端資料庫查詢一個範圍的資料，例如 20000<Salary<50000，這種條件查詢我們稱為 Range Selection，服務提供者可能會少回傳資料，假設今天我們對資料庫所下的查詢指令為 SELECT * FROM `company` WHERE `Salary`<50000. AND `Salary`>20000，且查詢的正確結果如. 圖 10，而服務提供者試圖少給查詢結果的 Row3，只回傳 Row1、Row2、Row4 的資料以及它們的 Slices，若只利用 row hash 驗證，則無法檢查出少了資料，所以在葉節點的 value 中，額外儲存了前後兩筆 row hash，在 Range Selection 的動作中，用戶要要求服務提供者額外回傳前後兩筆 row 的資料，這樣就可以檢查服務提供者是否有少給資料。. 16.

(24) Salary. Name. …. Row1. 25000. Jerry. …. Row2. 30000. Paul. …. Row3. 40000. Hank. …. Row4. 45000. Jack. …. 圖 11 資料庫查詢結果 1.5. 問題. 使用 Index Merkle Tree 的方法進行稽核，在各方面的表現幾乎都勝過 B+ Tree，唯有範圍查找的稽核速度較差，在大量資料的新增、修改、刪除方面均有進步的空間，因此而有了下一個方法 Aggregate Hash。. Aggregate Hash. 第二節 2.1. 資料結構. 在這一節中，將會介紹實驗室的研究成果 Aggregate Hash，Aggregate Hash 是利用數學中的同餘(modulo)[14]來產生密碼學證據，需要宣告一個大質數 P 與一個固定長度的一維陣列並將陣列中的值設為 1，接著使用一個 Index function Γ 計算來得到其該存放到陣列中的哪個位置，此 Index function Γ 如下。 𝚪(𝐂𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧) = 𝐒𝐇𝐀𝟐𝟓𝟔(𝐂𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧) 𝐦𝐨𝐝 𝐀𝐫𝐫𝐚𝐲𝐒𝐢𝐳𝐞. 17.

(25) 其中 Condition 為使用者查詢資料時經常使用的欄位條件，例如 id=10、 22000<Salary<50000 等。定位後將那一筆 row 的證據儲存在該位置，陣列是利用 (key, value)的方式儲存，儲存格式如下。 𝐱 = 𝚪(𝐂𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧) 𝐤𝐞𝐲 = 𝐂𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧 𝐯𝐚𝐥𝐮𝐞 = [𝐡(𝐫𝐨𝐰𝐡𝐚𝐬𝐡(𝐱)), 𝐡(𝐫𝐨𝐰𝐡𝐚𝐬𝐡(𝐱 − 𝟏)), 𝐡(𝐫𝐨𝐰𝐡𝐚𝐬𝐡(𝐱 + 𝟏))] 儲存後需要將陣列中的每一個slot都計算出一個證據，其證據的計算方式如下。 𝐀𝐫𝐫𝐚𝐲[𝐱] = 𝟏 × 𝐡(𝐯𝐚𝐥𝐮𝐞𝟏 ) × 𝐡(𝐯𝐚𝐥𝐮𝐞𝟐 ) × … × 𝐡(𝐯𝐚𝐥𝐮𝐞𝐧 ) 𝐦𝐨𝐝 𝐏 用戶必須要保存整個陣列用來稽核，當每一個slot都計算完之後，將這些證據結合成一個證據，其計算方式如下。 𝐀𝐇 = 𝐀𝐫𝐫𝐚𝐲[𝟎] × 𝐀𝐫𝐫𝐚𝐲[𝟏] × … × 𝐀𝐫𝐫𝐚𝐲[𝐧] 𝐦𝐨𝐝 𝐏 這個AH值可以拿來對雲端資料庫作稽核的一個依據，AH還要交由雙方進行簽章並互相保存以支援POV。 2.2. SQL 指令結果之稽核流程. 在即時稽核架構中，分別有同步伺服器、用戶端裝置、雲端服務提供者三個角色，我們將介紹在每一個 SQL 指令中，稽核的詳細流程。 Select operation: Step1: 用戶端向同步伺服器拿最新的 AH 及作為證據的 Array 18.

(26) Step2: 用戶端向雲端資料庫發出 Select operation 請求 Step3: 服務提供者將 Select operation 結果及對應 slot 的內容取出 Step4: 服務提供者回傳 Select operation 結果及對應 slot 的內容 Step5: 用戶端透過 Select operation 結果及對應 slot 的內容稽核 Step6: 用戶端稽核完成，告知服務提供者 Insert operation: Step1: 用戶端向同步伺服器拿最新的 AH 及作為證據的 Array Step2: 用戶端向雲端資料庫發出 Insert operation 請求 Step3: 服務提供者將 Insert operation 結果及對應 slot 的內容取出並計算新的 AH Step4: 服務提供者回傳 Insert operation 結果、對應 slot 的內容、新的 AH 及針對 AH 所作簽章 Step5: 用戶端稽核舊的資料並更新 AH Step6: 用戶端更新完成，回傳新的 AH 及雙方簽章給服務提供者及同步伺服器 Delete operation: Step1: 用戶端向同步伺服器拿最新的 AH 及作為證據的 Array Step2: 用戶端向雲端資料庫發出 Delete operation 請求 Step3: 服務提供者將 Delete operation 結果及對應 slot 的內容取出並計算新 19.

(27) 的 AH Step4: 服務提供者回傳 Delete operation 結果、對應 slot 的內容、新的 AH 及針對 AH 所作簽章 Step5: 用戶端稽核舊的資料並更新 AH Step6: 用戶端更新完成，回傳新的 AH 及雙方簽章給服務提供者及同步伺服器 Update operation: Step1: 用戶端向同步伺服器拿最新的 AH 及作為證據的 Array Step2: 用戶端向雲端資料庫發出 Update operation 請求 Step3: 服務提供者將 Update operation 結果及對應 slot 的內容取出並計算新的 AH Step4: 服務提供者回傳 Update operation 結果、對應 slot 的內容、新的 AH 及針對 AH 所作簽章 Step5: 用戶端稽核舊的資料並更新 AH Step6: 用戶端更新完成，回傳新的 AH 及雙方簽章給服務提供者及同步伺服器 2.3. 稽核細節. 當用戶向雲端服務提供者提出 query 請求前，需先向同步伺服器拿取最新的 AH 及作為證據的 Array，query 請求後，服務提供者需利用 Condition 來進行定 20.

(28) 位 slot，取出與其相同 slot 的內容。回傳該 slot 內容與 query 結果後，用戶須先使用 query 的結果取 hash 比對 row hash，接著與其他內容回推該 slot 的值，如果獲得的結果與在同步伺服器的內容相符的話，稽核成功，若失敗，則以服務提供者所回傳的資訊與保存的雙方簽章作為證據，要求服務提供者進行賠償。 2.4. Range Selection. 與 IMT 相同，若只利用 slot hash 驗證，則無法檢查出少了資料，所以在 slot 的 value 中，額外儲存了前後兩筆 row hash，在 Range Selection 的動作中，用戶要要求服務提供者額外回傳前後兩筆 row 的資料，這樣就可以檢查服務提供者是否有少給資料。. 21.

(29) 第四章相關實驗數據在第三章，我們做了一系列的實驗，來證明本論文提出方法之可行性。我們使用 JAVA 來實作我們的即時稽核架構，以及 digest function 為 java.security.MessageDigest 中的 SHA-256 algorithm，我們使用兩台電腦來作實驗，服務提供者與用戶端的電腦作業系統為 Windows 10，處理器為 Intel(R) Core(TM) i5-7500CPU @3.40GHz ，記憶體為 8GB 。資料庫系統我們使用 MySQL5.7.18，資料庫系統的連接與操作使用 JDBC(Java Database Connectivity) 來模擬資料庫實體的連接與 SQL 指令的執行，我們在資料庫當中建立了一個一百萬筆資料的 Table 作為實驗對象，每筆 row 最大為 3.2KB，Table 大小為 2.37GB。. 第一節. B+ Tree 相關數據. 設定 B+ Tree 的 max degree = 5 來進行實驗。第一段. 定位問題. 第二章中所提到的第一個問題就是定位問題，因為 B+ Tree 中的葉節點是依照順序擺放至二元樹的葉節點，所以在 B+ Tree 查找完資料後，需要先計算該葉節點是第幾個葉節點，才能在二元樹中找到對應的資料，以下表格為實驗最久的定位時間，B+ Tree 的 max degree = 5，由表 1 可以看出，B+ Tree 層數越高，所需要的定位時間越大。. 22.

(30) 表 1. B+ Tree 不同樹高的平均定位時間. B+ Tree 層數. 葉節點數量. 平均定位時間(ms). 5. 625. 0.002. 6. 3,125. 0.006. 7. 15,625. 0.046. 8. 78,125. 0.175. 9. 390,625. 1.454. 10. 1,953,125. 8.019. 11. 9,765,625. 13.146. 第二段. 分裂問題. 在資料庫中，新增刪除是常常會用到的動作，套用到 B+ Tree 中，新增刪除會造成分裂的問題，一旦發生分裂，大部分的二元樹都要重新計算值，以下表格為實驗分裂時所需要重建二元樹的時間，由表 2 可以發現，越高層樹所需要重建的時間就越久，因此才會有子樹的方法出現。表 2. B+ Tree 不同樹高重建二元樹所需時間. B+ Tree 層數. 重建二元樹所需時間(ms). 5. 0.51. 6. 3.438. 7. 7.528. 23.

(31) 8. 19.008. 9. 66.368. 10. 312.575. 11. 575.854 第三段. 過度集中問題. 使用子樹的方法後，解決了本節前兩個問題，但是卻造成了另一個問題，也就是當資料過度集中時，會造成樹的結構被拉長，以下表格為實驗當資料集中於某個區段塞入 B+ Tree 時所造成的問題，從表 3 可以看出因為子樹在低層數時無法塞入大量資料，所以會將結構拉得很長，造成稽核和重建樹的時間需要更多的時間。表 3. B+ Tree 資料過度集中問題稽核時間. 重建樹時間. (ms). (ms). >400. 34. 37. <12500. >80. 6. 11. <62500. >16. 2. 9. 子樹限高. 子樹資料量. 所需層數. 5. <2500. 6 7. 但是這個問題只有在刻意將資料往某個區段放入才會出現，若是用隨機的方式將一百萬筆資料放入的話結果應該如下表。. 24.

(32) 表 4 B+ Tree 子數平均層數子樹限高. 最高層數. 最低層數. 3. 12. 4. 4. 6. 3. 5. 4. 2. 6. 3. 2. 7. 3. 2. 8. 2. 1. 9. 1. 1. 第四段 B+ Tree 稽核這一段將會呈現 B+ Tree 用在即時稽核的所有實驗結果，會分為三個表格來呈現，表 5 為本機測試，不包含網路傳輸，表 6 為同網路區段的實驗數據，表 7 為不同網路區段的實驗數據。. 25.

(33) 表 5 B+ Tree 本機測試數據 100萬筆row subtree max level (sml). B+ (3 sml). B+ (4 sml). B+ (5 sml). B+ (6 sml). Sub tree height. Audit(ms) Select a row. 12. 0.13. 4. 0.05. 6. 0.09. 3. 0.04. 4. 0.09. 2. 0.04. 3. 0.07. 2. 0.04. 3. 0.07. 2. 0.06. 2. 0.08. 1. 0.05. 1. 0.23. 1. 0.06. B+ (7 sml). B+ (8 sml). B+ (11 sml). B+ (3 sml). B+ (4 sml). B+ (5 sml). B+ (6 sml). B+ (7 sml). B+ (8 sml). 0.74. 0.42. 0.38. 0.35. Audit(ms) Update (split/ no split). Audit(ms) Insert (split/ no split). Audit(ms) Delete (split/ no split). 0.83. 0.33. 0.82. 0.36. 0.82. 0.33. 0.68. 0.13. 0.69. 0.14. 0.65. 0.13. 0.75. 0.24. 0.76. 0.24. 0.74. 0.24. 0.67. 0.12. 0.62. 0.12. 0.65. 0.13. 0.72. 0.24. 0.76. 0.27. 0.71. 0.24. 0.66. 0.11. 0.62. 0.11. 0.62. 0.11. 3.53. 0.17. 3.55. 0.17. 3.51. 0.16. 3.52. 0.14. 3.52. 0.15. 3.55. 0.14. 7.66. 0.19. 7.62. 0.18. 7.63. 0.19. 7.45. 0.16. 7.41. 0.16. 7.42. 0.15. 18.9. 0.19. 18.93. 0.18. 18.93. 0.19. 18.88. 0.12. 18.83. 0.12. 18.85. 0.13. 0.35. 0.29. 575.85. 575.85. 575.85. 0.06. 0.06. 0.06. 0.31. 表 6 100萬筆row subtree max level (sml). Audit(ms) Select 100 rows. B+ Tree 同網段測試數據. Sub tree height. Audit(ms) Select a row. 12. 5.73. 4. 5.25. 6. 5.55. 3. 5.24. 4. 5.54. 2. 5.24. 3. 5.45. 2. 5.28. 3. 5.45. 2. 5.40. 2. 5.43. 1. 5.37. 1. 5.54. Audit(ms) Select 100 rows. 6.34. 6.02. 5.98. 5.95. 5.96. 5.89. Audit(ms) Update (split/ no split). Audit(ms) Insert (split/ no split). Audit(ms) Delete (split/ no split). 57.63. 57.13. 74.62. 74.16. 58.62. 58.13. 57.08. 56.53. 74.09. 73.54. 58.05. 57.53. 57.41. 56.90. 74.42. 73.90. 58.40. 57.90. 57.07. 56.52. 74.02. 73.52. 58.05. 57.53. 57.37. 56.89. 74.41. 73.92. 58.36. 57.89. 57.06. 56.51. 74.02. 73.51. 58.02. 57.51. 60.11. 56.75. 77.13. 73.75. 61.09. 57.74. 59.96. 56.58. 76.96. 73.59. 60.99. 57.58. 64.24. 56.77. 81.20. 73.76. 65.21. 57.77. 63.99. 56.70. 80.95. 73.70. 64.96. 57.69. 75.45. 56.74. 92.48. 73.73. 76.48. 57.74. 75.40. 56.64. 92.35. 73.64. 76.37. 57.65. 632.36. 649.85. 633.36. 56.57. 73.57. 57.57. 5.91. B+ (11 sml) 1. 5.37. 26.

(34) 表 7 100萬筆row subtree max level (sml). B+ (3 sml). B+ (4 sml). B+ (5 sml). B+ (6 sml). B+ (7 sml). B+ (8 sml). B+ Tree 不同網段測試數據. Sub tree height. Audit(ms) Select a row. 12. 24.67. 4. 23.79. 6. 24.35. 3. 23.78. 4. 24.33. 2. 23.78. 3. 24.18. 2. 23.86. 3. 24.18. 2. 24.08. 2. 24.11. 1. 24.03. 1. 24.18. Audit(ms) Select 100 rows. 25.62. 25.39. 25.26. 25.21. 25.24. 25.17. Audit(ms) Update (split/ no split). Audit(ms) Insert (split/ no split). Audit(ms) Delete (split/ no split). 78.17. 77.67. 95.16. 94.70. 79.16. 78.67. 76.42. 75.87. 93.43. 92.88. 77.39. 76.87. 77.54. 77.03. 94.55. 94.03. 78.53. 78.03. 76.41. 75.86. 93.36. 92.86. 77.39. 76.87. 77.45. 76.97. 94.49. 94.00. 78.44. 77.97. 76.40. 75.85. 93.36. 92.85. 77.36. 76.85. 80.01. 76.65. 97.03. 93.65. 80.99. 77.64. 79.42. 76.04. 96.42. 93.05. 80.45. 77.04. 84.14. 76.67. 101.10. 93.66. 85.11. 77.67. 83.75. 76.46. 100.71. 93.46. 84.72. 77.45. 95.22. 76.51. 112.25. 93.50. 96.25. 77.51. 95.10. 76.34. 112.05. 93.34. 96.07. 77.35. 651.00. 668.00. 652.00. 75.21. 92.21. 76.21. 25.20. B+ (11 sml) 1. 24.01. 從三個表格中，可以發現子樹限高越高，稽核的時間越快，但是發生分裂卻要花比較多時間，而子樹限高越低則稽核時間較久，但是發生分裂時重建樹較快，另外可以發現 B+ Tree 在 max degree = 5 且子樹限高設為五的時候，有比較平均的表現，因此後面在比較的時候，本篇論文會以子樹限高為五的數據去比較。. 第二節. Index Merkle Tree 相關數據. 第一段. Index function Γ 的碰撞測試. 此資料結構使用 Index function Γ 來進行存放資料的定位，如果同一個葉節點內的資料相當多的話，會影響到稽核的時間，因此，Index function Γ 如果碰撞的機率越低，稽核會越有效率，以下表格為實驗隨機值利用 Index function Γ 進行的碰撞測試，從表 8 中可以發現樹高越高，碰撞的機率越低。 27.

(35) 表 8. IMT 碰撞測試. 樹高. 葉節點數. 平均碰撞次數. 最小碰撞次數. 最大碰撞次數. 1. 1. 1000000. 1000000. 1000000. 4. 8. 125000. 124395. 125439. 6. 32. 31250. 30955. 31656. 8. 128. 7812.5. 7582. 7983. 10. 512. 1953.125. 1812. 2075. 12. 2048. 488.281. 403. 559. 14. 8192. 122.070. 84. 164. 16. 32768. 30.517. 9. 53. 18. 131072. 7.633. 0. 24. 20. 524288. 2.24. 0. 11. 21. 1048576. 1.552. 0. 9. 第二段表 9. 不同樹高的記憶體比較. IMT 不同樹高的記憶體比較. 樹高. 內節點(MB). 葉節點(MB). 1. 0.000031. 60.8. 4. 0.000458. 60.8. 6. 0.0019. 60.8. 28.

(36) 8. 0.0077. 60.8. 10. 0.031. 61.07. 12. 0.124. 61.5. 14. 0.49. 63.6. 16. 1.99. 71.8. 18. 7.99. 104. 20. 31.99. 233. 21. 63.99. 304. 本實驗是透過 java.io.ObjectOutputStream 中的 writeObject 將建構好的 FBHTree 輸出成一個物件檔儲存在電腦當中，在記憶體空間大小上，當 FBHTree 樹高超過 16 以後，會因為葉節點以倍數的增加導致整棵樹所有節點所佔的記憶體不斷變大，但是在我們的方法下，使用者只需要儲存一個 32bytes 的 Root hash 值，大幅減少用戶儲存上的負擔。第三段. Index Merkle Tree 稽核. 這一段將會呈現 Index Merkle Tree 用在即時稽核的所有實驗結果，如下表，從表 10 中可以看出隨著樹高的成長，稽核時間越來越短，但是 IMT 超過 20 層後，時間反而變長了，因為 IMT 資料太多，導致讀取變慢，因此後面將使用 20 層來進行比較。. 29.

(37) 表 10. IMT 不同層數的稽核時間. 稽核時間(ms). 稽核時間(ms). 稽核時間(ms). 稽核時間(ms). 樹高. Select a row. Insert a row. Delete a row. Update a row. 1. 295.66. 881.55. 884.46. 891.48. 4. 39.72. 118.17. 118.98. 120.87. 6. 10.92. 33.15. 32.52. 32.19. 8. 2.81. 8.42. 8.49. 8.43. 10. 0.76. 2.25. 2.31. 2.28. 12. 0.25. 0.78. 0.75. 0.75. 14. 0.13. 0.45. 0.39. 0.39. 16. 0.12. 0.36. 0.33. 0.31. 18. 0.13. 0.42. 0.33. 0.33. 20. 0.13. 0.39. 0.33. 0.36. 21. 0.14. 0.39. 0.49. 0.42. 第三節第一段. Aggregate Hash 相關數據 Index function Γ 的碰撞測試. 此實驗結果如同 IMT，所以在此段就不再重複。第二段. Aggregate Hash 稽核. 這一段將會呈現 Aggregate Hash 用在即時稽核的所有實驗結果，如下表，從 30.

(38) 表 11 中可以看出 Slot 數量越多，稽核的時間明顯降低，之後將使用2 9 個 Slots 來與其他作法進行比較，選2 9 個 Slots 的原因是與 20 層 IMT 的葉節點數量相同。表 11. Aggregate Hash 不同 slot 數的稽核時間. Slots. Audit(ms) Select a row. Audit(ms) Insert a row. Audit(ms) Delete a row. Audit(ms) Update a row. Array Size. 20. 2736.942. 609.49. 0.025. 609.515. 0.2 Kb. 2. 120.834. 37.081. 0.025. 37.106. 1.3 Kb. 29. 3.746. 1.146. 0.025. 1.171. 34.7 Kb. 2. 0.987. 0.288. 0.025. 0.313. 138.0 Kb. 2. 0.219. 0.081. 0.025. 0.106. 552.0 Kb. 2. 0.063. 0.026. 0.025. 0.051. 2.2 Mb. 2. 7. 0.016. 0.008. 0.025. 0.033. 8.6 Mb. 2. 9. 0.008. 0.005. 0.025. 0.030. 29.7 Mb. 2. 0.003. 0.004. 0.025. 0.029. 58.5 Mb. 2. 0.003. 0.004. 0.025. 0.029. 97.5Mb. 第四節. 綜合比較. 這一節將會把 B+ Tree, IMT, Aggregate Hash 三種作法進行比較，實驗中的 B+ Tree 是使用子樹限高為五且 max degree = 5，分為有發生分裂的情況與未發生分裂的情況，IMT 使用 20 層的結構，一共會有2 9 個葉節點，Aggregate Hash 的 31.

(39) 結構使用2 9 個 slots。第一段. 單點稽核比較. 實驗的第一個部分是單點稽核的比較，單點稽核是指單次 SQL quary 只有動到一筆資料，實驗結果如以下三張表，分別為不包含網路時間、同網路區段與不同網路區段的實驗數據。由下表可以發現，在單點稽核的情況下，Aggregate Hash 有著極為突出的表現，不僅稽核速度極快，且服務提供者的硬體需求較小。表 12. B+Tree 分裂 B+Tree 未分裂. 綜合比較(本機測試). Select. Update. Insert. Delete. Client. Server. (ms). (ms). (ms). (ms). Storage. Storage. 0.692. 0.696. 0.665 32Kb. 107 Mb. 0.065 0.175. 0.195. 0.165. IMT. 0.053. 0.093. 0.083. 0.083. 32 Kb. 267 Mb. Aggregate Hash. 0.009. 0.035. 0.007. 0.029. 5.5 Mb. 29.7 Mb. 32.

(40) 表 13 Select (ms) B+Tree 分裂 B+Tree 未分裂. 綜合比較(同網段測試). Update (ms). Insert (ms). Delete (ms). 0.692. 0.696. 0.665. 0.065 0.175. 0.195. 0.165. Client Storage. Server Storage. 32Kb. 107 Mb. IMT. 0.053. 0.093. 0.083. 0.083. 32 Kb. 267 Mb. Aggregate Hash. 0.009. 0.035. 0.007. 0.029. 5.5 Mb. 29.7 Mb. Client Storage. Server Storage. 32Kb. 107 Mb. 表 14 Select (ms) B+Tree 分裂 B+Tree 未分裂. 綜合比較(不同網段測試). Update (ms). Insert (ms). Delete (ms). 0.692. 0.696. 0.665. 0.065 0.175. 0.195. 0.165. IMT. 0.053. 0.093. 0.083. 0.083. 32 Kb. 267 Mb. Aggregate Hash. 0.009. 0.035. 0.007. 0.029. 5.5 Mb. 29.7 Mb. 第二段. 範圍查找稽核比較. 第二個部分是 Range Selection 的實驗，以下表格是關於範圍查找的實驗，分別查找不同量的資料，從表 15 中可以發現，雖然 Aggregate Hash 單點稽核效率較高，可是在多筆稽核的情況下依然比不上 B+ Tree，因為 B+ Tree 的資料在儲存的時候就已經排序好了。. 33.

(41) 表 15. 範圍查找的比較數據. Range Selection. 1 row. 10 rows. 50 rows. 100 rows. 500 rows. 1000 rows. B+ Tree. 0.065. 0.17. 0.21. 0.24. 0.73. 1.48. IMT. 0.053. 0.87. 4.47. 8.07. 20.21. 39.81. Aggregate Hash. 0.009. 0.14. 0.65. 1.54. 6.84. 13.92. 第三段. 耗能比較. 第三個部份是比較效能，效能在雲端資料庫中是非常重要的，雲端服務提供者為了要配合使用者進行稽核動作，如果需要的計算量較少的話，就可以服務較多的使用者，三種即時稽核架構的效能比較如下表，從表 16 中可以發現 Aggregate Hash 的稽核速度會那麼快的原因，以單點稽核的部分大約是另外兩種作法的一成能耗，也就是說節省了將近九成的能耗，這個是本篇論文研究的最大成果。表 16. 耗能比較. Insert, Delete, Update 1 row. Select 1 row. 10 rows. 100 rows. 1000 rows. B+ Tree. 42 hash. 21 hash. 34 hash. 184 hash. 1681 hash. IMT. 40 hash. 20 hash. 200 hash. 2000 hash. 20000 hash. Aggregate Hash. 4 hash +2 module. 2 hash +1 module. 20 hash +10 module. 200 hash +100 module. 2000 hash +1000 module. 34.

(42) 第五章. 結論. 隨著雲端服務的普及，我們有越來越多的雲端服務可以選擇，將資料儲存在雲端不僅能讓使用者更方便的存取檔案，也可以省下許多硬體佈置、維護的成本。然而因為硬體不在我們身邊，我們無法掌控監視服務的所有狀況，現今提供雲端服務的公司大多與使用者簽下服務層級協議(Service Level Agreement)保障雲端服務的性能，但是當服務出問題時我們使用者也很難去舉證釐清究竟是服務提供者還是我們自己本身的因素造成的，某些雲端服務有提供即時的監控資訊或系統服務日誌，但我們不曉得服務提供者是否是公正的，也可能為了達成 SLA 的規範而提供給我們錯誤的資訊。我們的方法可以保障雲端資料庫系統數據的完整性，利用證名違約協定於操作雲端資料庫系統時，讓使用者與服務提供者雙方留下證據，能供日後出問題時拿出來稽核釐清雙方責任。藉由實驗的結果可以得知各種即時稽核架構的優缺點， B+ Tree 擅長於範圍查找，IMT 與 Aggregate Hash 擅長於單點稽核，Aggregate Hash 的作法能明顯降低雲端服務提供者的耗能，讓其可以在擁有即時稽核的狀態下服務更多的使用者。. 35.

(43) 第六章參考著作 [1] Cloud storage. (2018, June 18). Retrieved from Wikipedia: https://en.wikipedia.org/wiki/Cloud_storage [2] SQL. (2018, June 9). Retrieved from Wikipedia: https://en.wikipedia.org/wiki/SQL [3] NoSQL. (2018, June 20). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/NoSQL [4] Google CloudSQL. (n.d.). Retrieved from Google: https://cloud.google.com/sql/ [5] Amazon RDS for MySQL. (n.d.). Retrieved from Amazon: http://aws.amazon.com/tw/rds/mysql/ [6] Gwan-Hwan Hwang, Jenn-Zjone Peng, and Wei-Sian Huang. (2013). A Mutual Nonrepudiation Protocol for Cloud Storage with Interchangeable Accesses of a Single Account from Multiple Devices. 12th IEEE International Conference on Trust, Security and Privacy in Computing and Communications. [7] Gwan-Hwan Hwang, Hung-Fu Chen. (2013). A Mutual Nonrepudiation Protocol for Cloud Storage with Interchangeable Accesses of a Single Account from Multiple Devices. 12th IEEE International Conference on Trust, Security and Privacy in Computing and Communications. [8] Gwan-Hwan Hwang, Wei-Sian Huang, and Jenn-Zjone Peng. (2016). Real-time Proof of Violation for Cloud Storage. IEEE 6th International Conference on Cloud Computing Technology and Science. [9] Gwan-Hwan Hwang , Shih-Kai Fu. (2016). Proof of Violation for Trust and Accountability of Cloud Database Systems. 16th IEEE/ACM International Symposium on Cluster, Cloud, and Grid Computing. [10] HweeHwa Pang, Arpit Jain, Krithi Ramamritham, Kian-Lee Tan. (2005, June 1416). Verifying Completeness of Relational Query Results in Data Publishing. Proceedings of the 2005 ACM SIGMOD international conference on Management of data, pp. 407-418. [11] Jun Feng, Yu Chen, Douglas Summerville, Wei-Shinn Ku, Zhou Su. (2011, Jan 912). Enhancing Cloud Storage Security Against Roll-back Attacks with a New Fair Multi-party Non-repudiation protocol. 2011 IEEE Consumer Communications and Networking Conference (CCNC). [12] Kyriakos Mouratidis, Dimitris Sacharidis, HweeHwa Pang. (2009, January 1). Partially materialized digest scheme: an efficient verification method for outsourced databases. The VLDB Journal — The International Journal on Very 36.

(44) Large Data Bases, pp. 363-381. [13] B+Tree. (2018, May 18). Retrieved from Wikipedia: https://en.wikipedia.org/wiki/B%2B_tree [14] Modulo. (2018, June 12). Retrieved from Wikipedia: https://zh.wikipedia.org/wiki/%E5%90%8C%E9%A4%98. 37.

(45)