雲端資料庫之行為違反證明技術

全文

(1)國立臺灣師範大學資訊工程研究所碩士論文. 指導教授：黃冠寰. 博士. 雲端資料庫之行為違反證明技術. Proof of Violation for Trust and Accountability of Cloud Database Systems. 研究生：中華民國. 傅詩凱一零四. 年. 撰六. 月.

(2) 摘要雲端資料庫之行為違反證明技術傅詩凱雲端資料庫是一種執行在雲端運算平台上的資料庫，使用者不需要自己維護資料庫，由雲端服務提供者負責安裝、維護資料庫實體。服務提供者可能因為系統當機、錯誤的操作或是遭受嚴重的攻擊而造成我們重要的資料遺失或被更動導致給我們不一致的版本。某些雲端資料庫可以讓使用者透過 Web interfacec 或是 API(Application programming interface)存取資料庫操作的日誌檔，但使用者無法使用日誌檔去證明服務提供者是否有違反 Query Integrity 與 Transaction Serializability，因為這些日誌檔不是經由密碼學加密的證據。證明違約(Proof of Violation)協定使得使用者與服務提供者雙方留下一個珍貴的證據，用來證明服務提供者是否有違反他所保障的屬性。首先我們展現舊有的證明違約協定但它無法應用在我們的雲端資料庫系統上，我們提出一個新的證明違約協定雙重鏈結雜湊(Double Hashes)應用在雲端資料庫系統，除此之外舊有的稽核方法也不適用於 SQL 資料庫，我們設計一個新的稽核方法取代它。服務提供者藉由我們新的證明違約協定保障其服務階層協議內對於資料庫操作的承諾，因為證明違約協定的證據具有服務提供者與使用者雙方的不可否認性。關鍵字：雲端資料庫、雲端安全、不可否認性、證明違約 i.

(3) ABSTRACT Proof of Violation for Trust and Accountability of Cloud Database Systems by Shih-Kai Fu A cloud database is a database that typically runs on a cloud computing platform which is not maintained by the user but a service provider. The service provider can leak confidential data, modify the data, or return inconsistent data to users due to bugs, crashes, operator errors, or even malicious security attacks. Some cloud database systems provide Web interface or application programming interface for clients to access logs of database transactions. However, these logs are not cryptography-based proofs. Clients cannot use these logs to prove whether a cloud service provider has violated some required properties such as query integrity and transaction serializability. A POV scheme enables a user or a service provider to produce a precise proof of either the occurrence of the violation of properties or the innocence of the service provider. In this thesis, we develop POV and auditing schemes for cloud database systems. We first show that previously developed POV schemes cannot be applied to cloud database systems directly. Then, we propose a new POV scheme called double hashes (DH). In addition, previously proposed auditing schemes also cannot be applied to perform auditing requirements of SQL database according to collected attestations. We design a new auditing scheme for cloud database systems. Service providers can use the proposed schemes to provide a mutual nonrepudiation guarantee for database transactions in their service-level agreements. Key words: Cloud database, cloud security, nonrepudiation, proof of violation ii.

(4) 誌. 謝. 感謝黃冠寰老師這兩年來的教導，老師對研究的熱忱與精闢的見解，讓我們能快速的瞭解問題的本質，進一步藉由縝密有系統的作研究方法培養我們解決問題的能力，除此之外每週的個人指導時間更是讓我學會獨立思考，藉由每次的討論隨著老師的引導讓我釐清自己思考的盲點，不斷的修正才能有最後的成果。再者，我也很感謝我的父母與妹妹還有女友玟慧在這兩年內全力支持我，讓我無後顧之憂的投注心力在研究與課業上順利完成碩士學位。另外感謝實驗室的李祺學長、裕偉學長在我研究遇到困難時總是願意與我一起討論，感謝我的同學們虹甫、子豪、上語、欣芸與我一同修課、參與系上大大小小的活動，感謝儀齡與我一同扛起了產學的合作案，還有學弟們柏翔、之中、偉智、浩群、佳均因為有你們才讓實驗室每天有許多的歡笑，希望我們雲端運算實驗室互助的精神能一直傳承下去。最後感謝我身邊的好友與關心我的所有人，因為有你們大家的相挺我才能走完這兩年，達成今天的成就。. iii.

(5) 目錄. 摘要............................................................................................................................... i ABSTRACT .................................................................................................................. ii 誌. 謝......................................................................................................................... iii. 第一章. 緒論................................................................................................................. 1. 第一節. 雲端資料庫的安全性研究..................................................................... 1. 第二節. 論文大綱................................................................................................. 3. 第二章. 證明違約協定................................................................................................. 4. 第三章. 證明違約協定應用於雲端資料庫............................................................... 12. 第一節. 系統架構............................................................................................... 12. 第二節. 產生的困難........................................................................................... 13. 第三節. 改良證明違約協定............................................................................... 16. 第四章. 壹、貳、. 欄位值皆取雜湊儲存的 Merkle Tree.................................... 16 欄位值以明文儲存的 Merkle Tree........................................ 17. 參、. 欄位值以明文與雜湊混合的 Merkle Tree............................ 17. 改良的證明違約協定應用於雲端資料庫實作........................................... 19. 第一節. 證據的產生........................................................................................... 19. 第二節. 稽核....................................................................................................... 23. 第五章. 實驗成果....................................................................................................... 26. 第一節. 一般的資料庫 ........................................... 26. 第二節. 含有圖片或影音的資料庫................................................................... 32. 第三節. 模擬存有圖片的醫療系統................................................................... 36. 第六章. 相關研究探索............................................................................................... 38. 第七章. 結論............................................................................................................... 42. 參考著作....................................................................................................................... 43. iv.

(6) 表格目錄表格表格表格表格表格表格表格表格. 二-1 雲端儲存系統在 Four-Step-DH 架構下五個運算的訊息 ....................... 10 五-1 操作平均執行時間 .................................................................................... 28 五-2 操作平均稽核完成時間 ............................................................................ 28 五-3 服務提供者保存的證據 ............................................................................ 31 五-4 操作平均執行時間 .................................................................................... 33 五-5 操作平均稽核完成時間 ............................................................................ 34 五-6 稽核產生的 Merkle Tree 大小................................................................... 35 五-7 服務提供者保存的證據 ............................................................................ 36. 表格五-8 放射科 X 光檢驗室儲存在雲端資料庫的資料統計 ............................... 36 表格五-9 Merkle Tree 中 X 光相片以明文儲存的預估稽核時間............................ 37 表格五-10 Merkle Tree 中 X 光相片以雜湊值儲存的稽核時間.............................. 37. v.

(7) 圖目錄圖圖圖圖圖圖圖圖. 二-1 C&L Scheme 產生的問題(A)C&L Scheme (B)Four-Step-DH ....................... 6 二-2 雲端儲存系統在 Four-Step-DH 架構下五個運算的證據串聯 ................... 10 三-1 使用者帳戶底下建有多個資料庫實體 ........................................................ 12 三-2 證明違約協定應用於雲端儲存系統[16]檔案目錄的雜湊樹...................... 14 三-3 雲端資料庫系統依照證明違約協定建立的 Merkle Tree ........................... 15 三-4 將每筆資料下的欄位值以雜湊儲存建立的 Merkle Tree............................ 16 三-5 將每筆資料下的欄位值以明文儲存建立的 Merkle Tree............................ 17 三-6 將每筆資料下的欄位值以明文與雜湊混和儲存建立的 Merkle Tree........ 18. 圖圖圖圖圖圖. 四-1 Four-Step-DH 服務提供者與客戶端裝置保留承認訊息 ............................ 20 四-2 雲端資料庫使用 Four-Step-DH 架構流程圖 ............................................... 21 四-3 雲端資料庫使用 Four-Step-DH 架構流程圖 ............................................... 24 五-1 OP1 平均稽核完成時間折線圖 .................................................................... 29 五-2 OP2 平均稽核完成時間折線圖 .................................................................... 30 五-3 OP3 平均稽核完成時間折線圖 .................................................................... 30. vi.

(8) 第一章緒論雲端資料庫(Cloud Database)[1]是一種執行在雲端運算平台上的資料庫，雲端運算平台提供資料庫作為一種服務(Database as a service，DBaaS)[1]使用者不需要自己維護資料庫，雲端服務提供者負責安裝、維護資料庫實體。資料庫在雲端上支援兩種資料模型，分為透過結構化查詢語言(Structured Query Language，SQL)[2]存取資料與不使用 SQL 作為查詢語言(Not Only SQL， NoSQL)[3]存取資料，本文僅探討應用結構化查詢語言存取資料的關聯式資料庫系統，使用者只需透過 SQL 語法就能讀寫資料庫。由於使用者透過雲端資料庫提供的服務無法直接觸及資料庫實體以外的檔案，像是資料庫的設定檔、日誌檔，某些雲端資料庫例如 Google 的 Cloud SQL[4]、Amazon 的 RDS for MySQL[5]可透過 Web interfacec 或是 API(Application programming interface)可存取日誌檔，但使用者無法驗證日誌檔的正確性，日誌檔可能發生遭受服務提供者竄改的可能性無法拿來證明違約(Proof of Violation)。證明違約協定我們於第二章詳述，服務提供者會記錄每次使用者的動作並於最後留下一個雙方都不可否認的證據用來稽核檔案系統檔案的保密性、完整性、每次讀取資料的新鮮性與寫入檔案的循序性。. 第一節雲端資料庫的安全性研究近幾年隨著雲端服務的成熟越來越多中小企業希望能將其公司提供的服務 1.

(9) 2. 搬至雲端上，傳統的伺服器架設與主機維護對於企業內部是一個很大的營運負擔成本，如果使用 IaaS 層的雲端服務通過簡單的設定就能擁有自己的一台主機於雲端上像是 Amazon 的 EC2[6]，按照系統使用的規模大小計費，不用在逐年編列昂貴的預算在主機擴充與維護人力上。同樣的資料庫系統也能搬到雲端上，將資料庫系統當作一項服務(DBaaS)提供給企業使用，企業可以省下硬體的採購成本、每年伺服器的維護費用、相關軟體的授權費用，只要依據服務的使用量去付出相對的費用即可[7]。雖然雲端服務帶來相當大的好處與便利性，但是將所有資料儲存在雲端伺服器上使用者不免會擔心資料是否正確與完整。一則研究訪問 17 國的 500 名的 IT 管理人員與經理人，高達 80%的受訪者寧願使用既有的內部系統也不願使用雲端服務去取代，因為他們擔心失去重要資料的控制權[8]，這是有可能發生的情況，因為雲端伺服器出錯將我們的資料丟失或是雲端伺服器遭受攻擊導致我們資料被竄改。本文我們探討雲端資料庫的安全從兩個層面，資料庫資料的保密性(Data Confidentiality)與資料庫資料的完整性(Data Integrity)，資料庫的保密性從以前到現在就有許多文章在探討與實作[9][10][11][12]，資料庫的完整性自從將資料庫搬到雲端上則變成一個有趣的議題，雖然有雲端服務提供者給的系統日誌訊息，但我們無法相信雲端服務提供者，也無法驗證這個日誌檔的正確性，除非日誌檔交由公正的第三方所保管，但也有可能雲端服務提供者基於利益與第三.

(10) 3. 方共謀竄改，或是第三方遭受攻擊導致日檔被竄改或遺失[13]。我們的證明違約協定實現一個架構，會記錄每次使用者的動作並於最後留下一個雙方都不可否認的證據可用來稽核資料庫系統數據的完整性、每次讀取資料的新鮮性與寫入檔案的循序性。. 第二節論文大綱本篇論文組織結構如下: 第二章開始介紹證明違約協定，第三章探討我們如何將證明違約協定應用到雲端資料庫系統以及遇到的困難，並提出一個改良的證明違約協定解決，於第四章實作改良的證明違約協定應用於雲端資料庫系統上，實驗結果於第五章呈現從中我們可以得知使用證明違約協定帶給原本的資料庫管理系統多少額外的負擔與稽核的效率，最後於第六章我們為本文做出總結並於第七章探討其他相關的研究文獻。.

(11) 第二章證明違約協定證明違約協定提供了服務提供者與使用者之間的不可否認性，當有問題產生時能證明服務提供者是無辜的以及讓使用者證明自己沒有過失的方法，而證明雙方有沒有過失又稱作稽核(Auditing)[14]。只要達到不可否認性，使用者和服務提供者之間可以建立一個商業合約，這個合約會依照使用者想要安全層級來定價；如果服務提供者管理的資料有被竊取或竄改，則需給付使用者一些合約中簽訂的賠償金。然而稽核需要有根據，我們稱之為證據(Attestation)，這個證據都是經過雙方簽證過的訊息(Signed messages)。在這個章節我們會先介紹時段性證明違約(Epoch-based Proof of Violation)的方法 CloudProof、C&L Scheme 以及雙重鏈結雜湊。CloudProof[15]文中提出了一個系統，其中的協定可以偵測並證明雲端儲存系統上四種安全性質：保密性 (Confidentiality)、完整性(Integrity)、寫入循序性(Write Serializability)以及讀取新鮮性(Read Freshness)，合稱為 CIWF。使用者可以偵測雲端儲存系統是否違反 CIWF，而服務提供者可以反駁使用者的誣告，這個系統有保證不可否認性，使用者所做的請求以及服務提供者維護資料的狀態都會被綁定在證據裡面。使用者所做的請求都會和服務提供者交換證據，這些證據都利用鏈結雜湊(Chain Hash)的方式記錄下來，因此客戶端裝置上面只需要留下擁有最後一個鏈結雜湊的證據，而服務提供者保留所有的證據以便稽核時所需。然而鏈結雜湊這個方. 4.

(12) 5. 法不能夠抵禦來自服務提供者的回復式攻擊，除非客戶端裝置保留所有的證據或者有一個方法可以廣播最後的證據給其他客戶端裝置。 C&L Scheme[16]解決了 CloudProof 這個問題，利用鏈結雜湊搭配嵌入 LSN(Local Sequence Number)、客戶識別名稱(ClientID)以及時代識別名稱 (EpochID)於證據中，不只確保了雙方的不可否認性，在 LSN 的協助下可以成功抵禦服務提供者發起的回復式攻擊，在這個方法中客戶端裝置在存取雲端儲存空間中的一個單一帳戶，客戶端裝置之間不需要彼此交換證據，而且每一個客戶端裝置都只需要保留最後一個由服務提供者傳來的證據。雖然 C&L Scheme 解決了 CloudProof 這個問題，但其本身有一項很大的限制，為了確保執行的結果不會被服務提供者丟失、竄改，C&L Scheme 必須在鏈結雜湊裡加入當次請求的執行結果。這特性在某些系統上剛好不會造成問題如雲端儲存系統，因為服務提供者可以快速的找出該次請求的目標檔案雜湊值作為其執行結果，但像是雲端資料庫系統則無法，每次的 query 請求無法預期需要耗費多少時間，如圖二-1(A)每個服務請求都必須得等系統上一個服務請求執行完後才能鏈結上，因為前一個 transaction 可能修改資料庫，這麼一來除了服務提供者無法平行處裡服務請求，如果同時間有多個服務請求送到服務提供者，也可能無法被正確鏈結上，服務提供者可以任意更改其執行的順序造成錯誤發生。因此我們歸納出如果服務提供者無法立即取得執行結果的系統，我們使用四步驟雙重鏈結雜湊(Four-Step Double Hashes)圖二-1(B)解決這個問題，第 i 個.

(13) 6. transaction 還沒完成時就能將第 i+1 個 transaction 鏈結上執行後續的動作，省下很多 network time。 Time. ith transaction Step 1 Step 2 Step 3. Time. i+1th transaction Step 1. Step 3.1. Waiting time. ith transaction Step 1 Step 2 Step 3 Step 3.1 Step 4. Step 4 Step 2 Step 3 Step 3.1. Step 4.1. Step 4.1. i+1th transaction Step 1 Step 2 Step 3 Step 3.1. Waiting time. Step 4 Step 4.1. Step 4. Step 4.1 (A). (B). 圖二-1 C&L Scheme 產生的問題(A)C&L Scheme (B)Four-Step-DH 為了描述此協定，我們先解釋這個協定的符號意義，[O]pri(x)表示使用者 x 簽署在資料物件(Data object)O 上的電子簽章，此簽章是由使用者 x 自己的私有鑰匙所簽署，此外在中括號內，多個資料物件會以逗號隔開，表示多個物件資料被使用者 x 簽署，如例子[O1, O2, O3]pri(x)表示資料物件 O1、O2 和 O3 被使用者 x 的私有鑰匙所簽署。考慮一個在雲端儲存系統上的情境，有一個帳戶可以被多個客戶端裝置去做存取的一些基本動作，我們假設客戶端裝置擁有使用者 U 用來存取帳戶的私有鑰匙，當一個新的客戶端裝置準備好開始存取使用者 U 的帳戶前，它先傳送一個 client-ID-request 訊息，Z=(Timestamp, RequestID, [Timestamp,.

(14) 7. RequestID]pri(U))，給服務提供者去索取一個獨一無二的客戶識別名稱(ClientID), 其中時間戳記(Timestamp)是當前的時間，請求身分識別(Request ID)指此訊息是請求唯一的身分識別名稱，這個訊息有附上電子簽章，因此服務提供者可以授權這則訊息的擁有者。之後服務提供者傳送一個訊息(Timestamp, EpochID, ClientID, [Timestamp, EpochID, ClientID]pri(Provider))給客戶端裝置，其中時代識別名稱表示一段時間世代，不同的使用者或是帳戶會有不同的時代識別名稱，當所有證據都被稽核完畢要進入下一個時代時，這些證據都不需要在保存而會被丟棄，用戶識別名稱是一個獨一無二的，如果客戶端裝置丟失了目前使用的可以再申請新的一組。我們採用證明違約協定中的 Four-Step-DH(Four-step handshake protocols with double chained hashes)這個方法，服務提供者將雙重鏈結雜湊嵌入在彼此交換的訊息中，留有這些經過電子簽章簽署的訊息得以確保不可否認性，客戶端裝置只需保存最後一個證據，服務提供者就無法竄改已經鏈結的證據包括改變承認訊息的順序、移除承認訊息或是變更承認訊息內的執行結果。此方法包含下列幾個步驟： Step 1: 當一個使用者 U 所持的客戶端裝置想要存取使用者 U 的帳戶時，裝置要傳送一個請求訊息(request message) Qi 給服務提供者，Qi=(OPi, ClientID, [OPi, ClientID]pri(U))，其中 OPi 會包含此次操作的必要資料，例如檔案寫入、檔案讀取、檔案雜湊值和檔案路徑等等。.

(15) 8. Step 2: 當服務提供者收到來自客戶端裝置的請求 Qi，首先驗證此請求 Qi 內的電子簽章[OPi, ClientID]pri(U)是否有效，如果電子簽章有效再將此檔案系統的上一個操作回應訊息(response message)Ri-1 取雜湊與客戶端裝置上一個操作的承認訊息(acknowledgment message)取雜湊後放入此次操作 Ri，最後傳送回應訊息 Ri 給客戶端裝置，Ri=(Qi, EpochID, hash(ACKj), hash(Ri–1), [Qi, EpochID, hash(ACKj), hash(Ri–1)]pri(Provider))。 Step 3: 當客戶端裝置收到服務提供者傳送的回應訊息 Ri 後，先驗證 Ri 內的電子簽章與客戶識別名稱還有時代名稱是否有效，再比較 Ri 內客戶端裝置上一個操作的承認訊息雜湊是否與客戶端裝置目前保留的最後一個操作承認訊息雜湊相同，但此時客戶端裝置無法檢查 Ri 是否正確地有和上一個回應訊息 Ri-1 串聯，因為客戶端裝置只有保留最後一個來自服務提供者的完成動作後所傳送給客戶端裝置的承認訊息 ACKj，其中 j < i 且 j 可能不等於 j-1。當檢查完畢後，客戶端裝置傳送回覆回應訊息(replyresponse message) RRi 給服務提供者，其中 RRi=(Ri, [Ri]pri(U))。 Step 4: 服務提供者回覆回應訊息 RRi 後便開始執行 Qi 內所要求的操作指令，最後，服務提供者傳送承認訊息 ACKi，ACKi=( Li, RRi, [Li, RRi]pri(provider))，給使用者 U 的客戶端裝置，其中 Li 為執行結果。 Step 4.1: 服務提供者記錄客戶端裝置於此次操作的目標檔案的最後一個操作承認訊息為 ACKi。.

(16) 9. 下面我們對 Four-Step-DH 展示一個範例，假設有兩個客戶端裝置想要存取在使用者 U 這個帳戶中的檔案，其中客戶端裝置所持有的客戶識別名稱分別為 ClientA 以及 ClientB，且當下的時代識別名稱為 EPH000001。 Q1={(OP1, ClientA), [OP1, ClientA]pri(U)} R1={(Q1, EPH000001, hash(IH), hash(IH)), [Q1, EPH000001, hash(IH), hash(IH)]pri(Provider)} RR1={R1 ,[R1]pri(U)} ACK1=(L1, RR1, [L1, RR1]pri(Provider)) Q2={(OP2, ClientA), [OP2, ClientA]pri(U)} R2={(Q2, EPH000001, hash(ACK1), hash(R1), [Q2, EPH000001, hash(ACK1), hash(R1]pri(Provider)} RR2={R2 ,[R2]pri(U)} ACK2=(L2, RR2, [L2, RR2]pri(Provider)) Q3={(OP3, ClientB), [OP3, ClientB]pri(U)} R3={(Q3, EPH000001, hash(IH), hash(R2), [Q3, EPH000001, hash(IH), hash(R2)]pri(Provider)} RR3={R3 ,[R3]pri(U)} ACK3=(L3, RR3, [L3, RR3]pri(Provider)) Q4={(OP4, ClientA), [OP4, ClientA]pri(U)} R4={(Q4, EPH000001, hash(ACK2), hash(R3), [Q4, EPH000001, hash(ACK2), hash(R3)]pri(Provider)} RR4={R4 ,[R4]pri(U)} ACK4=(L4, RR4, [L4, RR4]pri(Provider)).

(17) 10. Q5={(OP5, ClientB), [OP5, ClientB]pri(U)} R5={(Q5, EPH000001, hash(ACK3), hash(R4)), [Q5, EPH000001, hash(ACK3), hash(R4)]pri(Provider)} RR5={R5 ,[R5]pri(U)} ACK5=(L5, RR5, [L5, RR5]pri(Provider)) 表格二-1 雲端儲存系統在 Four-Step-DH 架構下五個運算的訊息 IH ACK1. OP1, A, EPH1,hash(L1), hash (IH) , hash(R0), L1, RR1 ACK2. OP2, A, EPH1,hash(L2), hash(ACK1) , hash(R1), L2, RR2 ACK3. OP3, B, EPH1,hash(L3), hash (IH) , hash(R2), L3, RR3 ACK4. OP4, A, EPH1,hash(L4), hash(ACK2) , hash(R3), L4, RR4 ACK5. OP5, B, EPH1,hash(L5), hash(ACK3) , hash(R4), L5, RR5. 圖二-2 雲端儲存系統在 Four-Step-DH 架構下五個運算的證據串聯如圖二-2 所示，持用客戶識別名稱 ClientA 的客戶端裝置有三個證據，他們分別為 ACK1、ACK2 和 ACK4，持用客戶識別名稱 ClientB 的客戶端裝置有兩個證據分別為 ACK3 和 ACK5，藉由證據中記錄的回應訊息雜湊 hash(Ri-1)與承認訊.

(18) 11. 息雜湊 hash(ACKj)，我們將每個證據透過兩條雜湊鏈結，服務提供者就無法竄改已經鏈結的證據包括改變承認訊息的順序、移除承認訊息或是變更承認訊息內的執行結果。在 Four-Step-DH 中，客戶端裝置只需要維護自己客戶識別名稱和最後一個操作的承認訊息 ACKj，服務提供者的負擔包含要維護所有使用者註冊的客戶識別名稱以及所有的操作承認訊息 ACK。.

(19) 第三章證明違約協定應用於雲端資料庫第一節系統架構每個使用者帳戶底下可能有多個資料庫實體由服務提供者提供服務如圖三-1，服務提供者為每個資料庫實體建立一條雜湊鏈結，可用來稽核執行資料庫的所有動作順序與結果是否正確，保障每個資料庫的資料都是完整的，使用者帳戶下可能有多個客戶欲存取資料庫實體，每次動作後服務提供者與客戶端都會留下一個證據供日後稽核使用。. Service Provider. User’s account. Database A. Database B. Database C. 圖三-1 使用者帳戶底下建有多個資料庫實體我們採用時段性證明違約每當使用者帳戶底下留下的證據太多時就會啟動稽核，如果稽核成功就將保存的所有證據清除進入下一個時代(epoch)，稽核主要分兩個部分其一是確認證據有無被竄改，我們藉由服務提供者提供該使用者帳戶底下的所有證據與客戶們的最後一個證據能驗證證據有無被竄改，再者就. 12.

(20) 13. 是確認資料庫的資料是否正確，透過模擬資料庫系統結構建立一棵 Merkle Tree 重現所有動作並推算出樹的根雜湊值，與服務提供者依據使用者帳戶底下目前資料庫實體所有資料推導而得的根雜湊值做比對就能證明資料庫系統的正確、完整性。. 第二節產生的困難證明違約協定應用於雲端儲存系統時，服務提供者根據檔案目錄的結構模擬建構出一棵 Merkle Tree 記錄一個時代開始時檔案系統的狀態[16]，如圖三-2B 的雜湊樹是由圖三-2A 的檔案結構組成，每個檔案都是一個雜湊值，資料夾的雜湊值由其下所有的檔案或資料夾雜湊值組成，稽核時服務提供者將 Merkle Tree 與這個時代所有的證據交由稽核者，稽核者確認證據沒被竄改後依照每個證據內的動作 OPi 更新 Merkle Tree 的雜湊值，在雲端儲存系統上 OPi 內容記錄此次操作的必要資料，包括檔案寫入、檔案讀取、檔案雜湊值和檔案路徑等等，所以稽核時可以輕易更新或讀回每個動作的目標檔案雜湊值。.

(21) 14. 圖三-2 證明違約協定應用於雲端儲存系統[16]檔案目錄的雜湊樹證明違約協定應用於雲端資料庫服務提供者是根據資料庫下的表結構模擬建構出一棵 Merkle Tree 記錄一個時代開始時資料庫系統的狀態，與雲端儲存系統不同的是證據中動作的內容，在雲端資料庫系統中每個動作 OPi 的內容包含使用的資料庫、SQL 的語法、與 SQL 語法有關的資料表、執行 SQL 語法 Insert 或 Update 的檔案雜湊值，我們預期執行稽核時稽核者透過服務提供者得到這個時代開始時的 Merkle Tree，並將它匯入自已的本地資料庫中接著重新執行這個時代所有的 SQL 指令，最後從 Merkle Tree 底部向上推得的根結點雜湊值即代表目前雲端資料庫系統的最新狀態。圖三-3 是根據證明違約協定如果將每筆資料取雜湊值，並按照資料庫結構建立出來的 Merkle Tree 根節點代表的就是整個資料庫，樹的第二層代表的是該.

(22) 15. 資料庫有含哪些表，第三層儲存的是每筆資料的雜湊值，很明顯地如果將每筆資料都取雜湊會造成每筆資料的欄位值無法被辨識這個嚴重的缺點，舉例來說假如 OP1 的操作內容記錄 SQL 指令為”Select * FROM Table1 WHERE ID = 1”，稽核者將無法執行這則 SQL 指令更新 Merkle Tree，因為 Table1 下的每筆資料皆已取雜湊無法辨識 WHERE 條件欄位 ID 值為 1。. MyDB. TableB. TableA. Row1. Row2. Hash(Data): Row. Row1. Row2. …… RowN. 圖三-3 雲端資料庫系統依照證明違約協定建立的 Merkle Tree 因為雲端儲存系統與雲端資料庫執行的操作不一樣所以無法直接套用證明違約協定，雲端儲存系統上執行的動作只有兩種讀取檔案或是新增檔案，藉由 OPi 內的檔案路徑就能更新或讀取 Merkle Tree 中檔案的雜湊值，雲端資料庫系統上執行的動作是 SQL 指令，SQL 指令可能含有條件式像是大於、小於、比較運算等等，依照證明違約協定 Merkle Tree 中的值都是以雜湊值儲存，那稽核時就無法執行這些條件運算，下一節將探討如何改良 Merkle Tree 以應用在雲端資料庫系統上。.

(23) 16. 第三節改良證明違約協定壹、欄位值皆取雜湊儲存的 Merkle Tree. Hash(Data):. MyDB. TableB. TableA Row1. id. name. Row2. id. Data. name. Row1. id. name. Row2. pic. …… RowN. id. name. pic. 圖三-4 將每筆資料下的欄位值以雜湊儲存建立的 Merkle Tree 如第二節所說，如果將 Merkle Tree 的第三層也就是表中的每筆資料皆取雜湊將無法辨識每筆資料的欄位值，所以如圖我們這次再往下一層到 Merkle Tree 的第四層也就是儲存表中每筆資料的欄位值分別對每個欄位取雜湊，這麼一來只要將 SQL 指令中 WHERE 條件的值取雜湊就能從 Merkle Tree 中找到符合的資料。不過將 Merkle Tree 的第四層每筆資料的欄位值取雜湊將造成執行 WHERE 條件很大的限制，一般的 Structured Query Language(SQL) WHERE 條件除了等於的運算外還有大於小於甚至是字串的比對，如果將欄位值取雜湊就只能做等於的運算。.

(24) 17. 貳、欄位值以明文儲存的 Merkle Tree Plaintext:. Data. MyDB TableB. TableA Row1. id. name. Row2. id. name. Row1. id. name. Row2. pic. …… RowN. id. name. pic. 圖三-5 將每筆資料下的欄位值以明文儲存建立的 Merkle Tree 為了解決 WHERE 的條件限制最直覺的方法那就是將 Merkle Tree 的每筆資料都以明文儲存如圖三-5，但是假設今天我們的資料庫內有一欄位是儲存圖或影音這種較大的檔案，資料龐大的欄位將造成服務提供者與稽核者的 Merkle Tree 於記憶體中佔據肥大的空間與操作性能的大幅下降。. 參、欄位值以明文與雜湊混合的 Merkle Tree 根據上述的探討，我們將證明違約協定應用於雲端資料庫 Merkle Tree 的產生與稽核時的操作會發生相當大的問題，如果我們要稽核的 SQL 指令含有條件式運算，為了不限制 WHERE 條件的運算式(可能是等於、小於、大於或字串比對)我們採用明文儲存 Merkle Tree 的資料，但是如果遇到資料庫是用來儲存照片或影音這些較大的檔案，這些含有較大資料的資料庫欄位會造成 Merkle Tree 於記憶體中過於肥大，稽核的操作性能也會嚴重下降。所以綜合上述的考量，為.

(25) 18. 了維持稽核時 SQL 指令的操作重現與稽核的性能，本文提出一個解決辦法就是將資料庫中含有較大資料的欄位取雜湊，其餘一般的欄位皆以明文儲存於 Merkle Tree 中如圖三-6。. MyDB. id. name. Row2. id. Data. Plaintext:. Data. TableB. TableA Row1. Hash(Data):. name. Row1. id. name. Row2. pic. …… RowN. id. name. pic. 圖三-6 將每筆資料下的欄位值以明文與雜湊混和儲存建立的 Merkle Tree.

(26) 第四章改良的證明違約協定應用於雲端資料庫實作第一節證據的產生本章節將敘述如何實作改良後的證明違約協定於雲端資料庫上，為了使用此協定將先解釋部分符號意義，[O]pri(x)表示使用者 x 簽署在資料物件(Data object)O 上的電子簽章，此簽章是由使用者 x 自己的私有鑰匙所簽署，此外在中括號內，多個資料物件會以逗號隔開，表示多個物件資料被使用者 x 簽署，如例子[O1, O2, O3]pri(x)表示資料物件 O1、O2 和 O3 被使用者 x 的私有鑰匙所簽署。考量一個實際的案例，一個雲端資料庫由一個申請該服務的使用者 U 擁有，該使用者可為這個資料庫的存取增添客戶，每個客戶依據各自的權限能對不同的資料表進行存取，我們假設每個客戶端裝置都擁有使用者 U 用來存取雲端資料庫服務的私有鑰匙，並且由服務提供者得到一個獨一無二的客戶識別名稱(ClientID)與時代識別明稱(EpochID)，其中時代識別名稱表示一段時間世代，不同的使用者帳戶會有不同的時代識別名稱，當所有證據都被稽核完畢要進入下一個時代時，這些證據都不需要在保存而會被丟棄。. 19.

(27) 20. Service Provider User U’s account. User U‘s database ACK1, ClientA ACK2, ClientB ACK3, ClientA ACK4, ClientC ACK5, ClientC. ClientA. ClientB. ClientC. ACK1. ACK2. ACK4 ACK5. ACK3. 圖四-1 Four-Step-DH 服務提供者與客戶端裝置保留承認訊息參考圖四-1，服務提供者必須保留相同使用者帳戶下所有客戶識別名稱與其每個操作的承認訊息(acknowledgment message)，一個客戶端裝置需要保留它自己的客戶識別名稱以及對應的最後一次操作的承認訊息，這個方法採取將雙重鏈結雜湊嵌入在彼此交換的訊息中確保資料完整性與操作的正確性，留有這些經過電子簽章簽署的訊息得以確保不可否認性。這個方法稱作 Four-StepDH(Four-step handshake protocols with double chained hashes)，如圖四-2 總共有 13 個步驟以下將詳述每個步驟所做的事：.

(28) 21. Client Device. 1. send Request. Service Provider Qi 2. receive Request Semaphore(DB(Tablei)).acquire 3. chaining hash(Ri-1) & hash(ACKj) Ri. 4. send Response 5. Rmain (DB) = Ri. 6. receive Response 7. check epochID, ClientID 8. send RR 8.1. upload data. RRi. ACKi. 9. receive RR 10. do Operation 11. send ACKi 12. ACKlatest (ClientID, DB)= ACKi. 13. receive ACKi 13.1. download ACK Result Semaphore(DB(Tablei)).release. 圖四-2 雲端資料庫使用 Four-Step-DH 架構流程圖 Step 1:. 當一個客戶端裝置想要存取其擁有的雲端資料庫時，客戶端裝置要傳. 送一個請求訊息(request message) Qi 給服務提供者，Qi=(OPi, ClientID, [OPi, ClientID]pri(U))，其中 OPi 會包含此次操作的必要資料，例如該次 SQL 語法、目標對象的資料庫、目標對象的資料表、執行 SQL 語法 Insert 或 Update 的檔案雜湊值。 Step 2: 當服務提供者收到來自客戶端裝置的請求 Qi，首先驗證此請求 Qi 內的電子簽章[OPi, ClientID]pri(U)是否有效。 Step 3: 如果 Qi 內的電子簽章[OPi, ClientID]pri(U)有效，將此資料庫的上一個操作回應訊息(response message)Ri-1 取雜湊與客戶端裝置上一個操作的承認訊.

(29) 22. 息(acknowledgment message) ACKj 取雜湊後放入此次操作 Ri。 Step 4: 最後傳送回應訊息 Ri 給客戶端裝置， Ri=(Qi, EpochID, hash(ACKj), hash(Ri–1), [Qi, EpochID, hash(ACKj), hash(Ri–1)]pri(Provider)) 。 Step 5: 記錄此次操作的目標資料庫最後一個操作的回應訊息為此次的 Ri。 Step 6: 客戶端裝置接收服務提供者傳送的回應訊息 Ri。 Step 7: 當客戶端裝置收到服務提供者傳送的回應訊息 Ri 後，先驗證 Ri 內的電子簽章與客戶識別名稱還有時代名稱是否有效，再比較 Ri 內客戶端裝置上一個操作的承認訊息雜湊是否與客戶端裝置目前保留的最後一個操作承認訊息雜湊相同，但此時客戶端裝置無法檢查 Ri 是否正確地有和上一個回應訊息 Ri-1 串聯，因為客戶端裝置只有保留最後一個來自服務提供者的完成動作後所傳送給客戶端裝置的承認訊息 ACKj，其中 j < i 且 j 可能不等於 j-1。 Step 8: 當檢查完畢後，客戶端裝置傳送回覆回應訊息(reply-response message) RRi 給服務提供者，其中 RRi=(Ri, [Ri]pri(U))。 Step 8.1:. 客戶端裝置執行 Qi 內 SQL 指令中的檔案上傳。. Step 9: 服務提供者接收驗證回覆回應訊息 RRi。 Step 10: 在服務提供者收到並且驗證回覆回應訊息 RRi 後便開始執行 Qi 內所要求的 SQL 指令。 Step 11: 服務提供者傳送承認訊息 ACKi，ACKi=( Li, RRi, [Li, RRi]pri(provider))，給.

(30) 23. 客戶端裝置，其中 Li 為 SQL 指令的執行結果雜湊值。 Step 12: 服務提供者記錄客戶端裝置於此次操作的目標資料庫上的最後一個操作承認訊息為 ACKi。 Step 13: 客戶端裝置接收服務提供者傳送的承認訊息為 ACKi。 Step 13.1: 客戶端裝置從服務提供者下載 SQL 指令的執行結果 Li。. 第二節稽核本文採用時代性證明違約協定，服務提供者於一個時代(epoch)開始時會模擬資料庫系統的結構為每個資料庫建立一棵 Merkle Tree 如圖四-3，並推導出樹的根雜湊值代表一個時代開始時資料庫的狀態，交給所有能存取該資料庫的客戶保存，稽核時服務提供者會將欲稽核資料庫的 Merkle Tree 交給稽核者，稽核者也會跟該帳戶下能存取這資料庫的客戶收集最後一個證據，首會先比對服務提供者與客戶這時代的根雜湊值是否一樣，再來根據每個證據中的更新該棵 Merkle Tree，最後推導出樹的根雜湊值與服務提供者依據目前資料庫資料推導而得的根雜湊值做比對，如果根雜湊值一樣則稽核成功，就能將服務提供者此時代的所有證據都清除並進入下一個時代，稽核總共有 15 個步驟以下將詳述所有步驟：.

(31) 24. 3. collect latest ack. 3.1 return latest ack & root hash. Auditor. 1. audit request ClientA. ClientB. 7. receive Merkle Tree & all ack. 8. check ack signature & compare latest ack of client to ack of service provider. Service Provider. 2. start audit 4. send Merkle Tree & all ack 5. derive root hash 6. send root hash. 9. Import Merkle Tree & redo operation 10. derive root hash ClientC. 11. receive service provider root hash 12. send audit result. 15. Broadcast next epoch root hash to client. 13. receive audit result 14. clean all attestation & entry next epoch. 圖四-3 雲端資料庫使用 Four-Step-DH 架構流程圖 Step 1:. 稽核者向服務提供者提出稽核請求。. Step 2:. 服務提供者收到稽核請求。. Step 3:. 稽核者向該使用者帳戶下的所有客戶收集最後一個證據，也就是該客. 戶的最後一個操作承認訊息(acknowledgment message)。 Step 3.1: 使用者帳戶下的客戶將自己的最後一個操作承認訊息與這個時代開始時從服務提供者拿到的 Merkle Tree 根雜湊值一同回傳給稽核者。 Step 4:. 服務提供者將欲稽核的使用者帳戶目前這時代開始時的 Merkle Tree 和. 這時代所有的操作承認訊息傳回給稽核者。 Step 5:. 服務提供者根據目前的資料庫狀態計算出新的根雜湊值。. Step 6:. 服務提供者將新的根雜湊值傳回給稽核者。.

(32) 25. Step 7:. 稽核者接收服務提供者傳來目前這時代開始時的 Merkle Tree 和這時代. 所有的操作承認訊息。 Step 8:. 稽核者首先驗證從服務提供者得到的承認訊息電子簽章，接著再比對. 從客戶得到的最後一個承認訊息與服務提供者提供的承認訊息是否相同，如果都相同即證明所有承認訊息沒有被竄改。 Step 9:. 稽核者將 Merkle Tree 匯入本地資料庫中，並執行每一個承認訊息中此. 次 OPi 的 SQL 指令。 Step 10: 稽核者完成這時代所有的動作後算出本地資料庫的根雜湊值。 Step 11: 稽核者接收服務提供者傳來目前雲端資料庫系統最新的根雜湊值。 Step 12: 稽核者比較本地資料庫的根雜湊值與從服務提供者得來的根雜湊值，如果相同即證明雲端資料庫經過這時代所有的操作後的狀態是正確的，並回傳稽核成功告知服務提供者。 Step 13: 服務提供者等待稽核者傳送稽核結果。 Step 14: 如果稽核成功服務提供者就將該使用者帳戶下目前這時代的證據都清除並進入下一個時代，將新算出的根雜湊值作為新時代開始時雲端資料庫系統的狀態。 Step 15: 稽核者將新的根雜湊值廣播給使用者帳戶底下的所有客戶，告知目前這時代結束已進入下一個時代。.

(33) 第五章實驗成果本章節的實驗將探討雲端資料庫系統中三種不同的案例，第一種是普通的資料庫，表中的欄位沒有特別大的值，第二種其資料庫下的表存有圖片或影音等較大檔案的欄位，最後則是模擬一個醫院的 X 光檢驗室，我們實作第四章改良的 Four-Step-DH 證明違約協定，雙重雜湊鏈結以 SHA-1 安全雜湊演算法取雜湊，將證據以 XML 的格式儲存並透過 Socket 通訊傳遞資料，資料庫系統我們使用 MySQL5.5，資料庫系統的連接與操作使用 JDBC(Java Database Connectivity) 來模擬資料庫實體的連接與 SQL 指令的執行，我們希望得知改良後的 Four-StepDH 證明違約協定應用在雲端資料庫系統上，跟不使用證明違約協定的雲端資料庫相比會產生多少額外的負擔，還有這兩種不同的資料庫案例稽核的效率是否相同。我們實驗使用 2012 年的 Mac mini 作為服務提供者與客戶，其電腦規格為 Intel Core i5 2.5GHz，記憶體 16GB，SSD 硬碟 512GB，稽核者則是使用 2012 年的 MacbookAir，其電腦規格為 Intel Core i5 1.8GHz，記憶體 8GB，SSD 硬碟 128GB，作業系統兩台皆為 OS X Yosemite。. 第一節一般的資料庫首先我們探討的是一般的雲端資料庫，其資料庫表中每筆資料皆不超過 1MB，每個欄位的資料大小都差不多沒有特別大的值並都是以明文儲存。透過 26.

(34) 27. 三種不同 SQL 指令的實驗統計，包括讀出單筆資料、讀出整張表的資料還有寫入單筆資料，我們可以得知不使用證明違約協定與使用證明違約協定資料庫的讀取與寫入效率，詳見表格五-1 整理三種不同的 SQL 指令與 Query 的資料量所得到的平均執行時間。完成數次操作後開始執行稽核整個資料庫，表格五-2 統計出不同的 SQL 指令與 Query 的資料量所得到的平均稽核時間和稽核時產生的 Merkle Tree 大小。最後表格五-3 依據不同指令與操作次數，統計服務提供者保存的證據量，平均一個請求所留下的承認訊息(acknowledgment)大約是 3K，如果該次請求是寫入的 SQL 指令則需要額外保留寫入的檔案以便稽核時模擬操作。 SQL 指令 OP1: SELECT * FROM Table WHERE ‘id’ = 1 OP2: SELECT * FROM Table OP3: INSERT INTO `Table` (ìd`,`name`,àge`,àddress`,`phone`,èxtra`) VALUES (NULL, 'Aron', '25', ‘Taipei’, ‘+886987654321’, ‘extra.txt’) OP1: 查詢一個 row OP2: 查詢整張資料表 OP3: 寫入一個 row 表格五-1 是 10 個使用者執行 10000 次 transaction 後所得的平均執行時間，Non POV 架構與 POV 架構的 Double Hashes 10 個使用者可以平行執行 10000 次 transaction，所以平均執行時間可以省下 10 倍左右，但 POV 架構的 C&L Scheme 則無法平行執行 transaction 理由我們在第二章有加以說明。.

(35) 28. 表格五-1 操作平均執行時間 SQL. Queried Data size. Non POV. POV (C&L). POV (DH). OP1. 1 KB. 1.1 ms. 28 ms. 2.8 ms. OP1. 10 KB. 1.2 ms. 30 ms. 3.1 ms. OP2. 1 KB. 1.3 ms. 34 ms. 3.5 ms. OP2. 1 MB. 6.5 ms. 84 ms. 8.7 ms. OP2. 10 MB. 53.4 ms. 554 ms. 57.1 ms. OP2. 100 MB. 447.8 ms. 4503 ms. 469.1 ms. OP3. 1 KB. 1.1 ms. 28 ms. 2.8 ms. OP3. 10 KB. 1.3 ms. 32 ms. 3.3 ms. 從表格五-2 平均稽核時間我們可以得知稽核時間在 Query 的資料小於 1 M 時是差不多的，隨著 Query 的資料越大需要耗費越多的時間，但稽核時間不會跟 Query 的資料大小呈正比，因為我們稽核是使用另一個空的資料庫去模擬所有動作最後建出 Merkle Tree 與當前的雲端資料庫比較，所以稽核時間不只跟 Query 的資料大小有關，還會跟資料庫的操作次數、操作時間和 Merkle Tree 的大小有關。本節的 Merkle Tree 內容是以明文的格式儲存資料庫的所有資料，所以表格中的 OP2 Query 100MB 的資料表 1000 次和 10000 稽核時間會過久，我們依據前面稽核 100 次的時間做推算填上大約的稽核完成時間。表格五-2 操作平均稽核完成時間.

(36) 29. SQL. Queried data size. N=10 10 個操作. N=100 100 個操作. N=1000 1000 個操作. N=10000 10000 個操作. Merkle Tree. OP1. 1 KB. 1 row. 1243 ms. 3414 ms. 16364 ms. 122783 ms. 2.51 KB. OP1. 10 KB. 1 row. 1346 ms. 3415 ms. 16446 ms. 125157 ms. 11.51 KB. OP2. 1 KB. 20 row. 1357 ms. 3467 ms. 16657 ms. 127892 ms. 2.51 KB. OP2. 1 MB. 1000 row. 1901 ms. 5373 ms. 32430 ms. 263322 ms. 1.0015 MB. OP2. 10 MB. 10000. 5033 ms. 19086 ms. 156055 ms. 1466730 ms. 10.0015. row OP2. OP3. 100. 100000. MB. row. 1 KB. 1 row. MB 38674 ms. 1313 ms. 205235 ms. 3331 ms. More than 30. More than 5. 100.0015. minute. hours. MB. 16583 ms. 126266 ms. (1.51+N) KB. OP3. 10 KB. 1 row. 1315 ms. 3519 ms. 17818 ms. 141231 ms. (1.51+10N) KB. 圖五-1 OP1 平均稽核完成時間折線圖.

(37) 30. OP1稽核完成時間(Query Row) 140. 稽核時間(單位:秒). 120 100 80 60 40 20 0 0. 2000. 4000. 6000. 8000. 10000. 12000. 10000. 12000. 操作次數10/100/1000/10000 OP1-1KB. OP1-10KB. 圖五-2 OP2 平均稽核完成時間折線圖. 稽核時間(單位:秒). OP2稽核完成時間(Query Table) 20000 18000 16000 14000 12000 10000 8000 6000 4000 2000 0 0. 2000. 4000. 6000. 8000. 操作次數10/100/1000/10000 OP2-1KB. OP2-1MB. OP2-10MB. OP2-100MB. 圖五-3 OP3 平均稽核完成時間折線圖.

(38) 31. OP3稽核完成時間(Insert Row) 160. 稽核時間(單位:秒). 140 120 100 80 60 40. 20 0 0. 2000. 4000. 6000. 8000. 10000. 12000. 操作次數10/100/1000/10000 OP3-1KB. OP3-10KB. 表格五-3 為每次操作後服務提供者所留下的證據大小，OP1 與 OP2 留下的證據大小會一樣是因為同樣都是讀的 SQL 指令，OP3 是寫入所以除了該次操作的承認訊息外還必須保留寫入的檔案，稽核時才有辦法模擬原先的寫入動作。. 表格五-3 服務提供者保存的證據 SQL. Queried data size. 10 個操作. 100 個操作. 1000 個操作. 10000 個操作. OP1. 1 KB, 10 KB. 32 KB. 321 KB. 3.13 MB. 31.32 MB. OP2. 1 KB, 1MB, 10. 32 KB. 319 KB. 3.11 MB. 31.12 MB. MB, 100 MB OP3. 1 KB. 41 KB. 405 KB. 3.96 MB. 39.51 MB. OP3. 10 KB. 130 KB. 1.27 MB. 12.73 MB. 127.26 MB.

(39) 32. 第二節含有圖片或影音的資料庫第二節我們探討資料庫中存有大檔案的案例，因為使用改良的證明違約協定，Merkle Tree 中對於資料庫存有大檔案的欄位是取其雜湊值儲存，我們從表格五-5 得知不管 SQL 指令操作這些大檔案的欄位值資料量有多大稽核時間都不受影響，稽核時間只隨著 Merkle Tree 的大小和 SQL 指令操作次數有所變化， Merkle Tree 的大小也會比實際資料庫的資料量小很多，因為 Merkle Tree 是由資料庫的所有資料建構而成。我們進一步的比較兩種不同內容的 Merkle Tree，一種是皆以明文儲存資料庫的值，另一種是針對資料庫的大檔案欄位會取雜湊值儲存，其餘欄位以明文儲存的混合型。我們藉由表格五-5 與表格五-6 來探討這兩種不同內容的 Merkle Tree 稽核時所耗費的時間與稽核時產生的 Merkle Tree 大小，可以發現混合型的 Merkle Tree 所耗費的稽核時間遠小於全部資料皆以明文儲存的 Merkle Tree，隨著 Query 的資料量越大、操作的次數越多，可以明顯地看到兩種不同內容的 Merkle Tree 所耗費的稽核時間與其本身的大小，相差的倍數越來越大。 SQL 指令 OP4: SELECT ÙltEx_img` FROM Ùltrasound_Exam` WHERE ÙltEx_id` = ‘1’ OP5: INSERT INTO Ùltrasound_Exam` (ÙltEx_id`,`Pat_id`,`Doc_id`,ÙltEx_date`,ÙltEx_img`) VALUES (NULL, '1', '1', CURRENT_TIMESTAMP, 'img.jpg') OP4: 查詢一個 row OP5: 寫入一個 row.

(40) 33. 表格五-4 是 10 個使用者執行 1000 次 transaction 後所得的平均執行時間， Non POV 架構與 POV 架構的 Double Hashes 10 個使用者可以平行執行 1000 次 transaction，所以平均執行時間可以省下 10 倍左右，但 POV 架構的 C&L Scheme 則無法平行執行 transaction 理由我們在第二章有加以說明。表格五-4 操作平均執行時間 SQL. Queried Data size. Non POV. POV (C&L). POV (DH). OP4. 1 MB. 2.7 ms. 75 ms. 7.7 ms. OP4. 10 MB. 15.9 ms. 203 ms. 20.7 ms. OP4. 100 MB. 167.4 ms. 1718 ms. 178.9 ms. OP4. 1000 MB. 1848.0 ms. 18553 ms. 1942.7 ms. OP5. 1 MB. 5.5 ms. 93 ms. 9.4 ms. OP5. 10 MB. 36.5 ms. 425 ms. 43.4 ms. OP5. 100 MB. 439.3 ms. 4426 ms. 456.3 ms. OP5. 1000 MB. 5551.6 ms. 55615 ms. 5854.2 ms. 表格五-5 為不同操作所耗費的稽核時間，稽核時間又分為大檔案欄位有取雜湊值的混合型與全部欄位都以明文儲存這兩種。我們可以看出隨著 query 的檔案越大，不管是讀取或寫入的 SQL 指令，資料內容以明文儲存的 Merkle Tree 其稽核時間比起混合型的 Merkle Tree 會相差越來越多倍，混合型的 Merkle Tree 其稽核時間不受 query 的資料大小影響，因為其中的大檔案欄位都會以雜湊值儲.

(41) 34. 存，所以在 Merkle Tree 中每筆檔案的大小其實是差不多大。表格五-5 操作平均稽核完成時間 Queried data size. 10 個操作. 10 個操作. 100 個操作. 100 個操作. (hash). (non hash). (hash). (non hash). OP4. 1 MB. 1285 ms. 1581 ms. 3363 ms. 4512 ms. OP4. 10 MB. 1316 ms. 3183 ms. 3353 ms. 12826 ms. OP4. 100 MB. 1213 ms. 12457 ms. 3317 ms. 95552 ms. OP4. 1000 MB 1319 ms. 157182 ms. 3358 ms. 1423084 ms. OP5. 1 MB. 1328 ms. 2142 ms. 3476 ms. 9985 ms. OP5. 10 MB. 1333 ms. 7578 ms. 3388 ms. 59223 ms. OP5. 100 MB. 1267 ms. 68532 ms. 3416 ms. 716352 ms. OP5. 1000 MB 1321 ms. 900731 ms. 3443 ms. More than 2 hour. SQL. 表格五-6 稽核時兩種不同格式的 Merkle Tree 大小會因為操作的 SQL 指令是寫入而變大，混合型的 Merkle Tree 因為大檔案取雜湊值儲存，雜湊值是以 SHA-1 演算法取得長度固定是 160 bit，所以就算在資料庫中實際的檔案大小不同，存在 Merkle Tree 中的每筆資料大小其實是相差不多，一筆資料的大小取決於其他沒取雜湊的明文欄位大小總和。表格五-6 讀取的 SQL 指令操作的資料都是固定同一筆，不同的資料量是替換大檔案欄位的值所以混合型的 Merkle Tree 大小才一樣，另一種都是以明文儲存的 Merkle Tree 大小就還得多考量到大.

(42) 35. 檔案欄位而有所不同。. 表格五-6 稽核產生的 Merkle Tree 大小 SQL. Queried data size. Merkle Tree (hash). Merkle Tree (non hash). 10 OP. 10 OP. 100 OP. OP4. 1 MB. OP4. 10 MB. OP4. 100 MB. 100.0017 MB. OP4. 1000 MB. 1000.0017 MB. OP5. 1 MB. OP5. 100 OP. 1.0017 MB. 1.76 KB. 2.86 KB. 12.63 KB. 10.0017 MB. 10.012 MB. 100.012 MB. 10 MB. 100.012 MB. 0.976 GB. OP5. 100 MB. 1000.012 MB. 9.766 GB. OP5. 1000 MB. 10000.012 MB. 97.656 GB. 表格五-7 服務提供者保存的證據除了所有操作的承認訊息外，如果是採用明文儲存的 Merkle Tree，需額外保存寫入 SQL 的大檔案，混合型的 Merkle Tree 則不用，因為保存的承認訊息中含有該次客戶端裝置的請求訊息，客戶端裝置的請求訊息內就有記錄此次操作欲寫入的大檔案雜湊值。.

(43) 36. 表格五-7 服務提供者保存的證據 10 個操作. SQL. 100 個操作. OP4. 33 KB. 328 KB. OP5 (hash). 35 KB. 348 KB. OP5 (non hash). (Insert data size + 35KB)*10. (Insert data size + 348KB)*100. 第三節模擬存有圖片的醫療系統今天有一間醫院其醫療系統採用雲端資料庫儲存資料並使用證明違約協定來保障雲端資料庫資料的完整性與操作的正確性，醫院內的放射科 X 光檢驗室每次檢驗為病人拍攝若干張高解析度圖像儲存於資料庫中，我們試著探討雲端資料庫中儲存 X 光相片的這張表的大小與其稽核效率會如何。假設醫院的 X 光檢驗室一天有 100 位病人要做檢驗，每位病人拍攝 3 張 X 光相片，每張相片的大小我們參考 Grant Shaw 寫的 X 光數位系統[17]，文內描述 X 光相片一張大小為 20MB 經過壓縮後為 8MB，根據上述的描述以下我們將探討此醫院的放射科 X 光檢驗室，儲存在雲端資料庫的資料量與其稽核資料的完整性所需的時間、稽核時產生的 Merkle Tree 大小。表格五-8 放射科 X 光檢驗室儲存在雲端資料庫的資料統計項目. 病人數量. 每次檢驗張數. X 光相片大小. 資料表列數資料表大小. 每日. 100 人. 3張. 8 MB. 300. 2400 MB. 每月. 1200 人. 3張. 8 MB. 3600. 28800 MB.

(44) 37. 表格五-9 Merkle Tree 中 X 光相片以明文儲存的預估稽核時間每日. 每月. Merkle Tree 大小. 2400.03 MB. 28800.38 MB. 預估稽核時間. 大約 4 分鐘. 大約 45 分鐘. 表格五-10 Merkle Tree 中 X 光相片以雜湊值儲存的稽核時間每日. 每月. Merkle Tree 大小. 32.52 KB. 390.23 KB. 稽核時間. 7.688 秒. 47.412 秒. 由. 表格五-9 與表格五-10 的統計資料，我們可以得知以明文儲存 X 光相片的 Merkle Tree 遠比以雜湊值儲存 X 光相片的 Merkle Tree 大上幾萬倍，稽核時間也相差好幾十倍，所以在此案例中採用明文與雜湊值混合的 Merkle Tree 是有必要的。.

(45) 第六章相關研究探索為了資料的保密性(Confidentiality)，一個直覺的方法是不讓服務提供者存取客戶端的資料，Hacigu et al.提出將客戶端的資料皆以 RSA 金鑰加密後再上傳 [18]，但如此一來會導致資料庫管理系統(DBMS)引擎無法執行 SQL 指令。 Hacigu et al.與 Popa et al.在後續的研究採用了新的加密方法解決了這個問題 [9][10]他們的架構基於一個受信任的中間代理人處理資料加密與存放加密後的描述性資料(metadata)代替客戶存取資料庫管理系統。應用在網頁端客戶透過其他中間伺服器存取資料庫系統雖然可行，但因為這個代理人需要被受信任，我們認為雲端服務提供者皆是不可信的[13]，所以無法將它移到雲端只能讓客戶端自行部屬維護。隨著資料庫管理系統的使用量變大，受信任的代理人新增不易，如果要部署多個代理人還得考量到存放在代理人上加密資料的描述性資料複本 (Replication)的一致性(Consistency)，必須得規劃描述性資料的同步演算法與協定，基於以上的原因將造成這個經過加密的資料庫管理系統會被中間受信任的代理人限制住可用性(Availability)與擴充性(Scalability)。 Damiani et al.提出一個解決[9][10]代理人造成資料庫系統效能瓶頸的方法將代理人移入每個客戶端自行維護[11]，如此一來客戶就能直接連線到資料庫管理系統不用透過代理人，但每個客戶有自己的加密引擎與加密資料的描述性資料要管理，還是會有描述性資料複本一致性問題要處理。Loca et al.提出一個同樣. 38.

(46) 39. 使用[9][10]的加密方法，但是將加密資料的描述性資料放到雲端資料庫管理系統內[12]，客戶存取描述性資料都是向雲端資料庫管理系統連線所以不用在本地同步加密資料的描述性資料複本，雖然解決了同步加密資料的描述性資料複本的問題，但將加密資料的描述性資料放到雲端資料庫管理系統會造成安全性的問題產生，因為我們前提假設在雲端上服務提供者與雲端資料庫管理系統都是不可信任的，[9][10][11][12]還有一個共同的問題就是雲端資料庫系統中的加密資料一致性沒考量到。有些資料庫管理系統引擎提供檔案系統等級的加密資料方法稱為透明資料加密(Transparent Data Encryption)[19][20]，但我們無法使用這特性建造一個受信任的資料庫管理系統透過一個不可信的服務提供者，所以這方法也不適用於雲端資料庫服務。資料庫的安全議題除了資料的保密性外，另一個探討的就是資料的完整性 (Integrity)，將數據外包的資料庫有兩種方法可以確保資料的完整性，基於身分認證的方法[21]與基於機率的方法[22]。基於身分認證的方法主要概念是加入使用者的數位簽章，使用者向服務提供者發出一個 query 指令後，服務提供者回傳 query 的結果與用來驗證的 Vo，Vo 的內容是由一個 Merkle Hash Tree 依據 query 結果的屬性與索引排序組成後再加上資料擁有者的電子簽章，Merkle Hash Tree 是一個資料結構其內部結點的值是其下所有子結點雜湊值的聯集，使用者可以藉由 Vo 來驗證 query 結果的正確性與完整性，如果驗證失敗則代表服務提供者.

(47) 40. 有出錯或竄改的可能，這個方法的主要缺點就是無法操作複雜的 query 指令，而且在新增資料時是非常沒效率的，還有為了驗證 Vo 使用者端也必須儲存完整的 Merkle Hash Tree。Min Xie et al.[22][23]提出基於機率的方法概念是使用者新增假的資料插入資料庫中，因為假資料是由使用者決定的，使用者就能從 query 的結果檢查出服務提供者是否有欺騙或是不正確的行為發生，有鑒於上述的偵測方式，我們不希望讓服務提供者得知哪筆資料是真實的或哪筆資料是假造的。 Min Xie et al.採用加密的方法將每筆資料內容都先加密後再新增到資料庫中，但加密的資料會對於資料庫的操作性能帶來嚴重的負擔，P. Ghazizadeh et al.[24]提出一個改良的方法不用加密資料也能使得服務提供者無法分辨真實資料或是假造的資料，他們設計了許多不同的函式組合，均勻的將假造的資料分散在資料庫中，使得服務提供者無法掌握他們新增假資料的模式。Min Xie et al.與 P. Ghazizadeh et al.提出的方法雖然可以偵測出服務提供者是否有欺騙或是不正確的行為發生，但無法證明是哪個操作有問題我們稱此種方法為偵測違約(Detect of Violation)。本文提出一個方法，改良證明違約協定中的四步驟鏈結雜湊(Four-Step-DH) 應用於雲端資料庫系統，我們的方法可以保障資料庫數據的完整性、讀取的新鮮性與寫入的循序性，藉由服務提供者將雙重鏈結雜湊嵌入在彼此交換的訊息中，留有這些經過電子簽章簽署的訊息得以確保不可否認性，客戶端裝置只需保存最後一個證據，服務提供者就無法竄改已經鏈結的證據包括改變承認訊息.

(48) 41. 的順序、移除承認訊息或是變更承認訊息內的執行結果。.

(49) 第七章結論隨著現在各式各樣雲端服務的普及，我們有越來越多的選擇，可以選用適合的雲端服務來取代我們原先舊有的服務，只需依服務的使用量計費，每年可以省下許多硬體佈置、維護的成本。然而因為硬體不在我們身邊，我們無法掌控監視服務的所有狀況，現今提供雲端服務的公司大多與使用者簽下服務層級協議(Service Level Agreement)保障雲端服務的性能，但是當服務出問題時我們使用者也很難去舉證釐清究竟是服務提供者還是我們自己本身的因素造成的，某些雲端服務有提供即時的監控資訊或系統服務日誌，但我們不曉得服務提供者是否是公正的，也可能為了達成 SLA 的規範而提供給我們錯誤的資訊。我們提出一個方法可以保障雲端資料庫系統數據的完整性，利用改良過的證名違約協定於操作雲端資料庫系統時，讓使用者與服務提供者雙方留下證據，能供日後出問題時拿出來稽核釐清雙方責任。我們藉由實驗結果得知加入證明違約協定不會對操作雲端資料庫系統時帶來太大的負擔，稽核時也因為我們採用混合的 Merkle Tree 能迅速的完成稽核，不會造成稽核者負擔也讓服務提供者不用保存太多的證據。. 42.

(50) 參考著作 [1] “Cloud database” http://en.wikipedia.org/wiki/Cloud_database [2] “SQL” http://en.wikipedia.org/wiki/SQL [3] “NoSQL” http://en.wikipedia.org/wiki/NoSQL [4] “Google Cloud SQL” https://cloud.google.com/sql/ [5] “Amazon RDS for MySQL” http://aws.amazon.com/tw/rds/mysql/ [6] “Amazon EC2” http://aws.amazon.com/ec2/?nc1=f_ls. [7] V. Mateljan, D. Cisic, and D. Ogrizovic, “Cloud database-as-a-service (daas) roi,” in MIPRO, 2010 Proceedings of the 33rd International Convention, May, pp. 1185–1188. [8] “Survey:cloud computing ’no hype’, but fear of security and control slowing adoption.” [9] Hacigu ̈mu ̈ ̧s, H., Iyer, B., Li, C., Mehrotra, S., “Executing sql over encrypted data in the database-service-provider model,” in Proceedings of the 2002 ACM SIGMOD International Conference on Management of Data, SIGMOD 2002, pp. 216–227. ACM, New York (2002) [10] Popa, R.A., Redfield, C.M.S., Zeldovich, N., Balakrishnan, H., “CryptDB: protect- ing confidentiality with encrypted query processing,” in Proceedings of the Twenty- Third ACM Symposium on Operating Systems Principles, SOSP 2011, pp. 85–100. ACM, New York (2011) [11] Damiani, E., De Capitani di Vimercati, S., Foresti, S., Jajodia, S., Paraboschi, S., Samarati, P., “Metadata Management in Outsourced Encrypted Databases,” in Jonker, W., Petkovi ́c, M. (eds.) SDM 2005. LNCS, vol. 3674, pp. 16–32. Springer, Heidelberg (2005) 43.

(51) 44. [12] Luca Ferretti , Fabio Pierazzi, Michele Colajanni, Mirco Marchetti, “Security and Confidentality Solutions for Public Cloud Database Services,” in SECURWARE 2013, The Seventh International Conference on Emerging Security Information, Systems and Technologies, pp. 36–42. Barcelona, Spain(2013) [13] R. Ranchal, B. Bhargava, A. Kim, M. Kang, L. B. Othmane, L. Lilien, and M. Linderman, “Protection of Identity Information in Cloud Computing without Trusted Third Party,” Proc. 29th IEEE Intl. Symp. on Reliable Distributed Systems (SRDS 10), pp. 368–372, doi: 10.1109/SRDS.2010.57. [14] S. Kamara and K. Lauter, “Cryptographic cloud storage,” Financial Cryptography and Data Security, ser. Lecture Notes in Computer Science. Springer Berlin/Heidelberg, 2010, vol. 6054, pp. 136–149. [15] R. A. Popa and J. R. Lorch. “Enabling Security in Cloud Storage SLAs with CloudProof,” USENIX Annual Technical Conference (USENIX), 2011, pp. 31. [16] 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 12th IEEE International Conference on Trust, Security and Privacy in Computing and Communications (IEEE TrustCom-2013), Melbourne, Australia, 16-18 July. [17] Grant Shaw, BM, “A clinician's guide to digital X-ray systems” J R Soc Med August 2001 vol. 94 no. 8 391-395. [18] Hacigu ̈mu ̈ ̧s, H., Iyer, B., Mehrotra, S., “Providing database as a service,” in Proceedings of the 18th International Conference on Data Engineering, pp. 29–38 (2002) [19] Cattaneo, G., Catuogno, L., Sorbo, A.D., Persiano, P., “The design and imple- mentation of a transparent cryptographic file system for unix,” in Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference, pp. 199–212. USENIX Association,.

(52) 45. Berkeley (2001) [20] Oracle corporation: Oracle advanced security (October 2012), http://www.oracle.com/technetwork/database/options/advanced-security [21] F. Li, M. Hadjieleftheriou, G. Kollios, and L. Reyzin, “Dynamic authenticated index structures for outsourced databases,” in Proceedings of the 2006 ACM SIGMOD international conference on Management of data, ser. SIGMOD ’06. New York, NY, USA: ACM, 2006, pp. 121–132. [22] M. Xie, H. Wang, J. Yin, and X. Meng, “Integrity auditing of outsourced data,” in Proceedings of the 33rd international conference on Very large data bases, ser. VLDB ’07. VLDB Endowment, 2007, pp. 782–793. [23] M. Xie, H. Wang, J. Yin, and Meng, “Providing freshness guarantees for outsourced databases,” in Proceedings of the 11th international conference on Extending database technology: Advances in database technology, ser. EDBT ’08. New York, NY, USA: ACM, 2008, pp. 323–332. [24] P. Ghazizadeh, R. Mukkamala S. Olariu, “Data Integrity Evaluation in Cloud Databaseas-a-Service,” in Proceedings of IEEE Ninth World Congress on Services, 2013, pp. 280285..

(53)