雲端環境下接力服務的有責性協定設計

全文

(1)國立臺灣師範大學資訊工程研究所碩士論文. 指導教授：黃冠寰. 博士. 雲端環境下接力服務的有責性協定設計. Accountability for Service Relaying in Intercloud. 研究生：. 中華民國. 陳佳均. 一零五. 年. 撰. 八. 月.

(2) 摘要在 Intercloud 的環境中，雲端服務提供商欲提供一套完整的服務可能會再租用由其他雲端服務商所提供的服務來完善自己的系統，而被租用的雲端服務也有可能再涉及其他雲端服務商的參與，以此類推，如此複雜的處理過程，難免會遇到一些無法預期的錯誤，導致資料處理異常。例如各個服務提供商呼叫其租用的服務時，不同的 Service Relaying Chains 可能涉及至相同之雲端服務，而服務執行的順序不同便有可能會造成資料的結果不正確而導致接下來執行的服務使用到錯誤的數據。於是本文藉由改良證明違約協定中的四步驟雙重鏈結雜湊法，使得原本只適用於點對點的有責性架構可以應用至多條 Service Relaying Chains 之架構上，並在四步驟訊息交換中加入特定資訊以確保不同 Service Relaying Chains 涉及至同一雲端服務時可正確地記錄服務參與者與其執行順序，以便發生異常行為時，能提出證據指出多數參與者中是哪一方該為此錯誤負責甚至要求其為之賠償。. 關鍵字：雲端運算、雲端安全、不可否認性、證明違約、有責性. i.

(3) 目錄. 摘要.................................................................................................................................. i 圖目錄............................................................................................................................ iii 表格目錄........................................................................................................................ iv 第一章緒論................................................................................................................. 1 第一節雲端運算................................................................................................. 1 第二節雲端的有責性......................................................................................... 1 第三節 Intercloud 及 Service Relaying Chain .................................................... 2 第四節研究目的................................................................................................. 3 第五節情境說明................................................................................................. 4 第六節論文大綱................................................................................................. 6 第二章雲端運算之行為證明..................................................................................... 7 第一節現有架構與缺失..................................................................................... 7 第二節相關證明技術與解法應用..................................................................... 9 壹 Proof of Violation.................................................................................... 9 貳 C&L Scheme ......................................................................................... 10 參四步驟交握協定與雙重鏈結雜湊....................................................... 11 第三章技術改良與系統架構................................................................................... 13 第一節改良的方向........................................................................................... 13 第二節解法與步驟........................................................................................... 15 第四章實驗結果....................................................................................................... 20 第五章相關研究....................................................................................................... 24 第六章結論............................................................................................................... 25 第七章參考著作....................................................................................................... 26. ii.

(4) 圖目錄. 圖圖圖圖圖. 1 Intercloud 及 Service Relaying Chain 示意圖 ................................... 2 2 情境介紹............................................................................................. 4 3 雲端運算有責性的相關解法............................................................. 8 4 同步執行連續交易之等待時間....................................................... 11 5 DRA4SOA Message Passing Process ............................................... 14. 圖 6 圖 7. 情境之證據儲存結果....................................................................... 18 Service Relaying Graph .................................................................... 23. iii.

(5) 表格目錄. 表格 1 表格 2. Service Relaying Model 執行時間 ............................................... 21 雲端服務提供商數目與執行時間............................................... 22. iv.

(6) 第一章第一節. 緒論. 雲端運算. 雲端運算（Cloud Computing）的技術提供了具便利性、低成本以及可擴充性的資料儲存與處理，甚至可以支援大量的數據分析以及根據使用需求來分配資源，如 Amazon EC2[1]。其中較為常見的雲端運算服務如雲端儲存空間（Cloud Storage） [15]，是一種透過網際網路的線上儲存系統，使用者可以將資料存放至雲端服務提供商（Cloud Service Provider）代管的虛擬伺服器中，令使用者可依照各自的需求向服務提供商購買或租用這些空間來存放資料，例如大型企業不需在自己的資料中心或辦公室裡安裝實體的儲存裝置，大幅減少管理系統與維護設備的成本。常見的雲端儲存系統有 Google Drive[2]、Dropbox[3]、OneDrive[4]等等。. 第二節. 雲端的有責性. 第一節所提到之雲端運算的優點促使企業漸漸將應用程式的開發與資料的管理移至雲端，不過由於企業所上傳至雲端的資訊會包含了個人（客戶）的隱私資料或公司內部的機密文件，於是除了考量到雲端所提供的便利性、低成本以及可擴充性等優點之外，企業更注重的是雲端能否提供安全性的保障。有責性（Accountability）是指雲端安全的一種規範，其主要概念是透過這樣的機制，在雲端服務處理客戶的請求時，雲端服務提供商可以向客戶證明：系. 1.

(7) 統在處理服務的請求時，有確實遵從雙方所擬定的規範並且正確無誤的執行檔案、數據的運算或傳遞；抑或是在處理資料的過程中出現異常狀態或發生無法預期之錯誤時，能夠提出確切有效的證據指出問題是出自於哪一個服務的供應商且該供應商必須為此錯誤負責並可向其要求賠償。也就是說，雲端服務提供商可以防止使用者的誣告，而使用者也可以抵禦雲端服務提供商規避該負的責任。. 第三節. Intercloud 及 Service Relaying Chain. Service Provider 3 Service Provider 2 Service Provider 4. Request. Service Provider 1. User. 圖 1. Service Provider 5. Intercloud 及 Service Relaying Chain 示意圖. Intercloud [14] 所指的是每一個單獨的雲並非具有足夠的資源，包括計算、. 2.

(8) 儲存或是其他相關的物理資源，或是該雲只限定在某個地理區域內可以使用這些資源。所以每一個單獨的雲之間有可能會相互租用彼此的功能或設備來完善在各自的雲中所提供的服務，這便是所謂的 Intercloud。如圖 1 所示，在 Intercloud 的環境下，一套完整的雲端服務必須再經手其他雲端的服務來支援，而該支援的雲端服務可能會再涉及其他雲端服務的參與，以此類推，本文定義這樣的關係為 Service Relaying Chain。. 第四節. 研究目的. 由於現行的雲端運算服務中，沒有辦法在他們的服務層級協定（Service Level Agreement）中保證安全性，例如 Amazon S3[5]及 Microsoft Azure[6]只保證可用性（Availability）。基本的安全性指的是身分驗證、保密性、資料完整性以及不可否認性，其中，身分驗證、保密性及資料完整性可以透過密碼學的加密技術達成。然而，無法保證雲端服務提供商與使用者之間的雙向不可否認性就成了一個常見的問題，若在 Intercloud 的環境下再伴隨著多條 Service Relaying Chains 參與交易，即使用者無法得知有多少參與者共同進行著此次交易時，一旦發生利益糾紛，使用者求償無門的情況會更加常見。於是我們需要加入一個協定使得雲端服務提供商之間與使用者在進行溝通與傳輸資料時，可以建立雙向不可否認性並留下交易進行的紀錄與順序，讓各方在日後若有發生交易糾紛時可以拿出此記錄證明究竟是雲端服務提供商想要掩蓋錯誤發生的事實導致使用者權益受損，或是使用者自身管理疏失想要誣告雲端服務提供商而獲取利益。. 3.

(9) 為了使雲端服務提供商之間與使用者端各方都必須留下適當的密碼學證據（Cryptographic Proofs）以便日後對交易處理的結果有疑慮時，可藉由稽核（Auditing）各方所留下之證據相互比對後找出錯誤，本論文提出了改善證據的儲存方式及不需其他可信第三方參與即可確保證據的有效性（Validity），一旦當雲端服務提供商與使用者之間發生利益糾紛時，可以確實地提出具有法律效力的證據來對簿公堂。. 第五節. 情境說明. 訂單處理. 商品後製. 1.5. A. B 1.4. Y 2.1. 2.2 C. 公司. 線上交易. 1.2. E 公司帳戶. 1.1. D. 顧客購物網站. X. 1.3. 圖 2 情境介紹（A~E 為不同的雲端服務提供商，公司與顧客為服務請求之發起者，1.1~1.5 及 2.1~2.2 分別為 2 筆不同的交易事件及其呼叫順序）. 4.

(10) 如圖 2 所示，假設一個在 Intercloud 環境下的情境：有一間相簿集公司架設了一個提供線上購物的平台網站（D），提供顧客針對欲購買的相簿集內容做編輯與修飾的服務，並申請ㄧ個專門的線上帳戶（E）向顧客進行收款與付款給所租用之服務。假設（1.1）有一顧客透過購物網站下單購買一本自然風景的相簿集，並希望賣家將自己的生活照之背景與該相簿集的自然風景照做替換，做成屬於自己的自然風景生活照片集。待（1.2）付款至公司帳戶後，（1.3）購物網站便開始進行訂單的處理。（1.4）首先自公司帳戶付款給所租用的商品後製服務之租用費後，（1.5）再將商品及顧客要求之內容送至商品後製服務繼續處理相片的修飾事宜與產品的成品配送服務。而在任何時間點，包括處理訂單的過程中，（2.1）公司可以同時進行其他的線上交易（2.2）且透過公司帳戶付款。此時，多筆不同的獨立交易行為，因為 Intercloud 的環境下，有可能在交易進行的過程中，存取到同一個雲端服務（E），若此雲端服務提供商（E）沒有正確的紀錄不同筆交易之間的執行順序，則可能導致資料的結果不正確而使接下來的服務終止（例如：原本帳戶有足夠的資金可以向租用的服務付出租金卻因先執行了其他的線上交易而導至帳戶資金不足）或是使用到錯誤的數據（例如：該線上帳戶提供資金不足則可直接申請線上貸款的服務，可能會在較大的交易款項上進行貸款而支付更多的利息）而造成利益糾紛。於是我們需要設計一個方法，令使用者與雲端服務提供商得以正確地記錄交易的過程並保留證據，一旦發生交易糾紛時，雙方可以提出證據找出該為錯誤負責的參與者或是防止他人誣告。. 5.

(11) 第六節. 論文大綱. 本論文組織結構如下：第二章介紹目前在雲端環境下處理有責性問題的解法、缺失、相關技術，以及仍然存在的問題。第三章將探討相關技術的改良方向與本論文所提出的解法；第四章是模擬在雲端環境下，實作本論文架構的結果與數據分析；第五章描述相關研究以及與本論文異同之處；第六章對本論文做出總結；第七章為參考文獻。. 6.

(12) 第二章. 雲端運算之行為證明. 第一節. 現有架構與缺失. ㄧ般而言，雲端運算有責性的相關解法[7]大致上都與架設監視器（Monitor）用來記錄服務參與者的行為並留下紀錄，最後藉由可信第三方（Trusted Third Party）將收集而來的紀錄做稽核（Auditing）的方式相關。如圖 3 所示，假設今天有一使用者 Alice 在線上進行一筆交易，而該筆交易有 A、B、C 共三個雲端服務提供商參與。若想要解決雲端在有多方參與某服務的情況下有責性的問題，直觀的解法便是在所有參與該服務的雲端上（即 A、B、C）各架設一臺監視器，用來記錄該服務之所有參與者的行為並將之以日誌檔（Log）的形式保存下來，以便日後需要對此交易做稽核時當作證據使用。而稽核的部分則是透過使用者對某次交易的結果產生疑慮時發動，此時，架設於各個參與過該次服務的雲端上的監視器必須將該筆交易所留下的日誌檔送至負責稽核的單位（此處指可信第三方）來驗證記錄在日誌檔內之行為有無違反使用者 Alice 與雲端服務提供商之間的協定。若是有某個參與該次服務的雲端上的監視器無法提供應該要保留至稽核完成的該筆交易之日誌檔，則該雲端服務提供商就必須為該次交易造成損失的部分負起責任以及賠償。. 7.

(13) Service 1 Customer. Monitor. Service 2 Monitor. Auditor. Service 3 Monitor. 圖 3 雲端運算有責性的相關解法. 然而，在上述的機制下，由於負責記錄服務參與者行為的監視器是架設於雲端上，而雲端本身的工作就是負責處理資料運算與數據傳輸的角色，像這樣令雲端身兼處理與監視的行為，便會被認為是一種球員兼裁判的情況。所以，縱使有可信第三方參與稽核，在收集的證據可能有效力不足的風險下，也無法確保可信第三方驗證之結果的真實性。. 8.

(14) 第二節. 相關證明技術與解法應用壹. Proof of Violation. 第一節所提到的作法最大的問題是證據的可信度太低，若要使證據具有效力，在本實驗室過去的研究中提出了證明違約演算法（Proof of Violation）[8]，可讓使用者與雲端服務提供商在每一次的服務請求時，都留下具有法律效力且經過簽章，雙方皆不可否認的證據。證明違約演算法其中的協定可以偵測並證明雲端儲存系統上的四種安全性質：保密性（Confidentiality）、完整性（Integrity）、寫入的循序性（Write Serializability）、讀取的最新性（Read Freshness），合稱為 CIWF。使用者可以偵測雲端儲存系統是否有違反 CIWF；而雲端服務提供商若是無辜的，則也可以反駁使用者的誣告。因為這個系統保證讓使用者所做的請求以及雲端服務提供商維護資料的狀態都會被綁定在證據裡面，使得雙方對彼此都建立了不可否認性。而使用者所做的每一次請求都會和雲端服務提供商交換證據，且這些證據都有利用鏈結雜湊（Chained Hashes）的方式記錄下來，因此使用者端的裝置上面只需要保留最後一個鏈結雜湊的證據（即最新的一筆證據），而雲端服務提供者則必須保留所有的證據以便稽核時所需。過去曾提出相關研究[9]，但是鏈結雜湊這個方法不能夠防止來自雲端服務提供商的回復式攻擊（Roll-Back Attack），也就是利用恢復較為先前版本的舊資料以. 9.

(15) 及相關的電子簽章來掩蓋雲端服務提供商不小心遺失或是惡意遺漏了最新版本的數據，除非使用者有將所有的證據保留起來或者在每一次交易完成後使用廣播的方式將最後的證據告知其他使用者端的裝置。. 貳. C&L Scheme. 鑑於上述的問題，後來的研究又再提出了新的方法（C&L Scheme）[10]來改善之前的技術，即除了鏈結雜湊外，並於證據中加入了 LSN（Local Sequence Number）、客戶識別名稱（Client ID）以及時代識別名稱（Epoch ID），使得保有雙方的不可否認性外，更可以成功防止受到由雲端服務提供商所發起的回復式攻擊。不過 C&L Scheme 有一項前提是：必須在鏈結雜湊中加入當次請求的執行結果來確保執行的結果不會被雲端服務提供商丟失或惡意竄改。然而，由於無法準確的預期使用者對雲端服務提供商的服務請求（Query）需要耗費多少時間，且每個服務請求都必須得等到系統上一個的服務請求完成後，才能正確地計算雜湊鏈結，如圖 4（A）所示，一旦雲端服務提供商同時間遇到多個服務請求時，並無法對這些服務請求提供平行處理，假如雲端服務提供商任意更改其執行的順序，就可能導致結果無法被正確地鏈結上而造成錯誤發生；使用者亦可以利用雲端服務商無法平行處理多個不同的服務請求這點來發動 Slow-running Attack[11]，即當使用者對雲端服務提供商提出服務請求時，可能會受到網路傳輸速度影響或是使用者惡意地遲遲不完成動作，導致雲端服務提供商延宕處理後續的服務請求，影響. 10.

(16) 整體系統效能甚至可能癱瘓系統的運作。. 參. 四步驟交握協定與雙重鏈結雜湊. 若是遇到雲端服務商無法立即取得執行結果的這類系統，我們使用 C&L Scheme 就可能產生如上所述之不利於系統運作的情況，則此類問題可以藉由四步驟交握協定與雙重鏈結雜湊（Four-Step Handshaking Protocols with Double Chained Hashes）[11]的方式來解決無法平行處理同時間收到多個服務請求的問題。如圖 4 （B）所示，在第 i 筆交易（Transaction）還沒完成時，就可以先將第 i+1 筆交易鏈結上並接著執行後續的動作，如此一來便能夠省下許多等待時間（Waiting Time）。. Time. ith transaction Step 1 Step 1.1. Time. i+1th transaction. ith transaction Step 1 Step 2 Step 3 Step 3.1. Step 1 Step 1.1 Waiting time. Step 2. Step 4. Step 3 Step 2. Step 4. Step 4.1 Step 3. i+1th transaction Step 1 Step 2 Step 3 Step 3.1. Waiting time. Step 4. Step 4.1. Step 4.1 Step 4. (A). Step 4.1. (B). 圖 4 同步執行連續交易之等待時間（A）Four-Step C&L and（B）Four-Step DH. 本文最終採用四步驟的交握協定配合雙重鏈結雜湊技術再加以改良至可以. 11.

(17) 運行在多個雲端服務提供商與使用者的環境中，由於系統架構自點對點之有責性變成 Service Relaying Chains 之間的有責性，本文將會改變固有的證據儲存方式以及當雲端服務提供商與使用者在做四步驟的交握溝通時，加入特定的資訊以供稽核時審查不同 Service Relaying Chains 涉及至相同服務端時是否正確地串接其執行順序，改良的細節與架構將在第三章提到。. 12.

(18) 第三章. 技術改良與系統架構. 第一節. 改良的方向. 在分散式系統的環境下，雲端運算可以看成是由一群服務所組成的，一個工作分割成多個小工作，藉由合作的電腦來進行平行的處理。於是可以理解成，雲端服務提供商所提供的一套完整的服務，可能會再經手其他雲端的服務來支援，而該支援的雲端服務可能會再涉及其他雲端服務的參與，最後會形成一個交錯複雜的處理過程。本實驗室先前的研究[12]有提出類似的概念，如圖 5 所示，解法是利用 XML 格式的訊息傳遞（Message Passing）並配合使用數位簽章來當作證據，把每一次的服務請求（Request）內容都放入下一個要呼叫（Invoke）的對象的服務請求中，即類似 TCP 資料傳輸的方式，一層一層的將請求訊息疊加並向下傳遞；而訊息回覆（Response）則是從服務呼叫的末端（即不需再繼續向下呼叫者）開始，同樣以一層一層的形式將此次回覆的執行結果放入下一個要回覆的執行結果的訊息內，依序回覆至服務請求的發起者（Originator）。最後由服務請求的發起者保留每一次交易完成後所收到的證據以供稽核時使用。這樣的方法可以保證服務呼叫者（Caller）的請求訊息一定會包含在被其呼叫的服務（Callee）傳遞給下一個被呼叫的服務（若有需要）之請求訊息中，如此則可以確定呼叫的順序，反之，也可以確定服務執行完成的順序。. 13.

(19) 圖 5. DRA4SOA Message Passing Process. 其中，REQ 以及 RES 表示服務請求（Request）以及回應訊息（Response）； M（REQ）表示服務請求的訊息內容，而 D（REQ）則是表示包含服務請求的訊息內容之文件；方框內之數字表示交易（Transaction）的編號，圓圈加上虛線與方框連結則表示每一個服務請求都必須有一個相對應的回應訊息；i 與 j 表示在此次交易中第 i 與 j 次的服務呼叫，且 i 先於 j。其缺點是：ㄧ、使用者端必須負起保留所有證據的責任，而每一筆證據又因其傳遞訊息的方式使得回到使用者手中的證據十分龐大；二、只能夠在單一筆交易上確保參與的服務之間執行的順序，若是發生多筆交易皆有經手同一雲端服務時，該雲端服務提供商則無法正確記錄它們之間的執行順序。在考慮到雲端系統上的情境與第二章的相關技術討論後，決定採用證明違約協定中的四步驟雙重鏈結雜湊這個方法並加以改良，即雲端服務提供商與使用者彼此交換訊息的過程中將加入雙重鏈結雜湊的方式，透過保有這些經過電子簽章簽署的訊息保證雙方之不可否認性外，使用者端裝置也只需保留最後一個證據便可達到令雲端服務提供商無法竄改已經鏈結的證據，包括改變承認訊息的順序、. 14.

(20) 移除承認訊息或是變更承認訊息內的執行結果。所以，藉由加入四步驟交握協定與雙重鏈結雜湊的技術，可以令使用者降低需保留之證據量，且在雲端服務提供商收到連續的服務請求時，可透過平行處理令使用者的等待時間大幅降低。另外在四步驟的交握溝通中，須加入特定資訊以判別不同 Service Relaying Chains 涉及至同一雲端服務時彼此間正確的執行順序。. 第二節. 解法與步驟. 本架構的方法是將四步驟雙重鏈結雜湊應用於點對點之有責性改良至可以應用於不同 Service Relaying Chains 間的有責性；又不希望使用者端負起保留全部證據的責任，於是將證據打散儲存於各個有參與該次交易的雲端服務提供者上；最後在原先四步驟雙重鏈結雜湊方法中彼此交換訊息的內容加上特定的請求訊息或是承認訊息之雜湊值，以確保當不同的 Service Relaying Chains 涉及至同一雲端服務時，各服務之間的正確執行順序。接下來先描述所使用的協定內的符號意義，[O]pri(x)表示使用者 x 簽署在資料物件（Data Object）上的電子簽章，此簽章是由使用者 x 本身的私有鑰匙（Private Key）所簽署，而在中括弧內，多個資料物件會以逗號隔開，表示多個資料物件被使用者 x 簽署，如[O1 , O2 , O3]pri(x)表示資料物件 O1、O2、O3 被使用者 x 的私有鑰匙所簽署。接下來介紹將使用者與雲端服務提供商彼此交換訊息時的步驟說明與訊息內的詳細內容：. 15.

(21) Step 1: 當一個使用者 U 所持的客戶端裝置（Client）想要對一個服務提供者（Service Provider）提出服務請求時，使用者會傳送一個請求訊息（Request Message）Qi 給服務端，而 Qi = ( OPi , ClientID , hash( QPreCaller ) , [ OPi , ClientID , hash( QPreCallee ) ] pri(U) )，其中 OPi 會包含對此次操作所要求的動作，ClientID 則用來識別使用者的身分，PreCaller 表示對此 Caller 而言，上一個呼叫它的雲端服務，而加入 hash( QPriCaller )至請求訊息的目的是日後在做稽核時，可以用來檢查呼叫的順序是否與證據上所記錄的結果一致。如圖 2 所示，若從顧客端發送請求到購物網站服務端（D）（即 1.1 的過程），由於顧客為服務請求之發起者，沒有上一個呼叫他的人存在，則不需在 Qi 中加上 hash( QPriCaller )的內容；而由購物網站發送請求至公司帳戶服務端（E）與訂單處理服務端（A）時（即 1.2 與 1.3 的過程），由於需要先支付下單的費用至公司帳戶，而公司帳戶回報給購物網站確定顧客有執行支付費用的動作後，才接著處理訂單與接下來的服務。這樣的順序關係必須確保，所以在公司帳戶端完成此次操作後的承認訊息（Acknowledgment Message）中加上該承認訊息之 ID 以供驗證時辨識該承認訊息之證據儲存的位置，回傳給購物網站後，購物網站再將剛剛自公司帳戶端收到的承認訊息的雜湊值加入原本送至訂單處理服務端的 Request 中，所以訂單處理服務端可以確保顧客的確已經經過公司帳戶的付款程序，便可以繼續接著將請求的內容依照步驟執行完畢。. 16.

(22) Step 2:. 當服務提供者收到來自使用者的請求 Qi，首先會驗證此請求內的電子簽章[ OPi , ClientID , hash( QPreCaller ) ] pri(U)是否有效，如果電子簽章確認有效後，再將上一筆的操作回應訊息（Response Message）Ri-1 取雜湊後放入此次操作 R， i 並回傳回應訊息 Ri 給使用者端裝置，Ri = ( Qi , hash(ACKj) , hash(Ri-1) , [Qi , hash(ACKj) , hash(Ri-1)]pri(Provider) )，其中 ACKj 為使用者在此服務端的上一個操作的承認訊息。. Step 3:. 當使用者裝置收到由服務端所傳送的回應訊息 Ri 後，先驗證 Ri 內的電子簽章是否有效，再比較 Ri 內使用者裝置上一個操作的承認訊息的雜湊值是否與使用者裝置目前保留的最後一個操作之承認訊息的雜湊相同，其中，ACKj 之 j < i 且 j 可能不等於 i-1。當檢查完畢後，使用者裝置傳送回覆回應訊息（Reply-Response Message）RRi 給服務端，其中 RRi = ( Ri , [Ri]pri(U) )。. Step 4:. 服務端收到回覆回應訊息 RRi 後便開始執行 Qi 內所要求的操作指令，待執行完成後，服務端傳送承認訊息 ACKi 給使用者，ACKi = ( Li , RRi , hash(ACKCallee_ID) , ACK_ID , [Li , RRi , hash(ACKCallee_ID) , ACK_ID]pri(Provider) )，其中 Li 為執行結果，hash(ACKCallee_ID)為被呼叫者. 17.

(23) 該次操作之證據的雜湊值，ACK_ID 為該次操作留下的證據之識別名稱。. 最後，圖 2 所示之情境可以根據上述四步驟的交握協定配合雙重鏈結雜湊之技術依序建立起如圖 6 所示之證據，可透過鏈結雜湊的方式檢視同服務端內的服務執行順序，也可表示不同服務端之間各服務端呼叫的先後關係，圖中有框起來的部分皆為雜湊值，箭頭指向雜湊值的來源，IH（Initial Hash）表示初始的雜湊值。最後可對此證據儲存結果進行稽核，檢查每一筆不同的 Service Relaying Chains 之間的操作順序。. D. E. A. B. C. IHD. IHE. IHA. IHB. IHC. ACKD1 QXD OPXD , X , h(null) h(ACKIH) , h(R0) RRXD , LDE , RRDE , h(ACKE1) , ACKD2 OPDA , D , h(ACKD1). LDA , RRDA , h(ACKA2) , LXD. ACKE1 OPDE , D , h(QXD) , h(ACKIH) , h(R0) RRDE , LDE. QDA. ACKA1 OPDA , D , h(ACKD1) , h(ACKIH) , h(R0) RRDA ,. LAE , RRAE , h(ACKE2). ACKE2 OPAE , A , h(QDA) h(ACKIH) , h(RE1) RRAE , LAE. ACKA2. ACKB1 QYC ACKC1 OPAB , A , OPYC , Y , h(null) h(ACKA1) , h(ACKIH) , h(R0) h(ACKIH) , h(R0) RRYC , RRAB , LAB LCE , RRCE , h(ACKE3) , LYC. OPAB , A , h(ACKA1). ACKE3 OPCE , C , h(QYC) h(ACKIH) , h(RE2) RRCE , LCE. LAB , RRAB , h(ACKB1) , LDA. Y. X. LYC , RRYC , h(ACKC1). LXD , RRXD , h(ACKD2). 圖 6 情境之證據儲存結果. 18.

(24) 稽核的部分分成以下幾個步驟： Step 1:. 由服務請求發起者（即公司或顧客）留下的承認訊息可以得知該次交易是由服務請求發起者向某雲端服務提供商發起請求開始，並可藉由其識別名稱與比對證據的雜湊值可確認該雲端服務與該次交易相關的證據。若該服務提供者與該次相關之證據內沒有包含其他的承認訊息之雜湊值與其識別名稱，表示該雲端服務並無再繼續呼叫其他服務來參與此次操作；. Step 2:. 若有，則將此雜湊值與該雲端服務內之證據中找到由其呼叫之服務端所送回的承認訊息的雜湊值比對，相同則再繼續重複 Step 1 直到某一服務端所留下之證據內沒有存有其它承認訊息之雜湊值與其證據的識別名稱為止，則代表該服務端為此次操作的尾端，即沒有再繼續呼叫其他服務。. Step 3:. 經過 Step 1 及 Step2 後，可以建立起不同條 Service Relaying Chains 的呼叫情況，若有發生多筆交易涉及至同一雲端服務時，可藉由判斷該雲端服務的證據串接順序（承認訊息之 ID 值）來決定各服務發起請求之先後。. 19.

(25) 第四章實驗結果本章節將探討情境說明（圖 2）中所提到的服務呼叫案例，藉由實驗來佐證此架構可行，並分別比較雲端服務提供商的數目以及執行次數，了解在更複雜的情況下執行本架構所需的負擔成本多寡。最後在稽核完證據後，產生一張 Service Relaying Graph 顯示出不同 Service Relaying Chains 的呼叫情形，並能夠看出不同筆交易在涉及至同一雲端服務時執行的順序。本實驗使用實驗室的電腦做為服務提供者，其電腦規格為 Intel Core i5-4590 3.3GHz，記憶體 8G，傳統硬碟 1TB；以 Acer TravelMate P6 做為服務請求發起者，其電腦規格為 Intel Core 17-4500 2.4GHz，記憶體 4G，傳統硬碟 512G，作業系統均為 Windows 7。實驗所使用的雙重鏈結雜湊是以 SHA-1 安全雜湊演算法取雜湊，將證據以 XML 的格式儲存，並透過 Java Socket 傳遞資料，最後使用 Java 呼叫 Open Source 的繪圖軟體 GraphViz 來繪出 Service Relaying Graph。以下是本架構的實驗數據：. 20.

(26) 表格 1. Service Relaying Model 執行時間. 1 time. 50 times. 100 times. 200 times. 300 times. Execution. 136 ms. 4165 ms. 8504 ms. 15638 ms. 25437 ms. Auditing. 31 ms. 327 ms. 514 ms. 997 ms. 1431 ms. 如表格 1 所示，數據代表的是將 Service Relaying Model 分別執行 1 次、50 次、100 次、200 次與 300 次後，得到的總執行時間與稽核時間，單位為毫秒。從數據中可以得知，除了執行第一次所花的時間可能會受到程式初始化的影響使得執行速度稍為慢ㄧ些外，平均執行一次架構所花的時間皆在 80 毫秒左右，執行時間為線性的成長，；而稽核所需的時間會受到向雲端服務提供商搜尋證據的時間影響，當執行次數愈多也表示累積的證據量愈大，所以稽核時間亦會呈現線性的成長。. 21.

(27) 表格 2 雲端服務提供商數目與執行時間 1. 3. 5. 7. Execution. 2028 ms. 4278 ms. 6263 ms. 8705 ms. Auditing. 266 ms. 358 ms. 445 ms. 528 ms. 如表格 2 所示，數據代表的是雲端服務提供商數目分別為 1 個、3 個、5 個與 7 個時，對雲端服務提供商發出服務請求 100 次後的總執行時間與稽核時間，單位為毫秒。從數據中可以得知當雲端數目由 1 個增至 7 個後，平均執行一次所花的時間由 20 毫秒左右增加至 87 毫秒左右，所以增加的傳輸時間並不會對系統造成太多額外的負擔；而稽核時間會受到向不同雲端服務提供商請求證據的時間影響，當需要請求的數目增加時，其所增加的時間亦不會對系統有太多額外的負擔。. 22.

(28) 圖 7 Service Relaying Graph. 最後，如圖 7 所示，我們會產生一張 Service Relaying Graph 來表示稽核完成後所驗證的交易執行過程，其中數字代表雲端服務提供商被呼叫的先後。. 23.

(29) 第五章相關研究過去有研究提出過解決跨雲端服務提供商之間的有責性[13]，在分散式系統下，可能會發生拜占庭將軍問題（Byzantine Generals Problem），即點對點的通信中，不同的裝置透過訊息交換來互相取得聯繫，但有時候可能因系統錯誤而交換到錯誤的訊息，導致影響最終的結果。所以拜占庭將軍問題就根據錯誤裝置的數量，尋找可能的解決辦法，但這無法找到一個絕對的答案，卻可以用來驗證一個機制的有效程度。 PeerReview 保證了在發生拜占庭將軍問題時，透過檢查正確的節點可以找到故障發生的節點。也就是 PeerReview 可以在基於多個管理域彼此不信任的情況下，保障其中一個節點可以隨時抵禦誣告的行為。其作法是透過驗證器以定期稽核其日誌檔來檢查系統的一致性並讓日誌檔保持在一個防竄改的狀態下，不過此解法有一個前提是必須假設有至少一個正確的節點才能利用該節點找出故障的裝置。由於是在雲端環境下，不可能假設有某一方雲端服務是真正可信的，所以必須建立在各雲端服務提供商彼此之間不信任的情況下來討論，而本文所提出的方法，透過四步驟訊息交換協定與雙重鏈結雜湊的技術，可以不需額外的第三方（驗證器）來輔佐即可確保證據的有效性以及不可否認性，並可藉由稽核各方所留下的證據找出真正問題發生的端點。. 24.

(30) 第六章. 結論. 在 Intercloud 環境下，考慮到多條 Service Relaying Chains 涉及至同一雲端服務時，必須確保該雲端服務提供商正確記錄它們之間的正確執行順序。而點對點的有責性並不足以應付這樣的情況，於是改良了證明違約協定中的四步驟交握協定，在其四步驟的訊息交換中加入特定資訊並搭配雙重鏈結雜湊的技術，使其可以應用至 Service Relaying Model 並可確保有責性。最後藉由實驗來佐證本文架構的可行性，透過探討增加執行次數與雲端服務提供商的數目，了解本架構的方法並不會導致過多的成本負擔，並能夠藉由產生 Service Relaying Graph 來呈現稽核完成後所驗證的交易執行過程。. 25.

(31) 第七章. 參考著作. [1] “Amazon EC2,” https://aws.amazon.com/tw/ec2/ [2] “Google Drive,” https://www.google.com/intl/zh-TW/drive/ [3] “Dropbox,” https://www.dropbox.com/ [4] “OneDrive,” https://onedrive.live.com/about/zh-tw/ [5] “Amazon S3,” https://aws.amazon.com/tw/s3/ [6] “Microsoft Azure,” https://azure.microsoft.com/zh-tw/ [7] Anderson Santana de Oliveira, Jakub Sendor, Alexander Garaga and Kateline Jenatton. “Monitoring personal data transfers in the cloud,” Cloud Computing Technology and Science (CloudCom), 2013 IEEE 5th International Conference on. Vol. 1. IEEE, 2013. [8] 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,” 2013 12th IEEE International Conference on Trust, Security and Privacy in Computing and Communications. IEEE, 2013. [9] Raluca Ada Popa, Jacob R. Lorch, David Molnar, Helen J. Wang, and Li Zhuang. “Enabling Security in Cloud Storage SLAs with CloudProof,” USENIX Annual Technical Conference. Vol. 242. 2011.. 26.

(32) [10] Gwan‐Hwan Hwang, Wei-Sian Huang, Jenn-Zjone Peng, Yu-Wei Lin. “Fulfilling mutual nonrepudiation for cloud storage,” Concurrency and Computation: Practice and Experience (2014). [11] Gwan-Hwan Hwang, Yi-Ling Yuan, and Chi Wu-Lee. “Cryptographic Accountability. for. Cloud-based. Service-oriented. Architecture. Systems,”. Submitted to IEEE Transactions on Service Computing (In revision) [12] Gwan-Hwan Hwang, Kuh-Yih Huang, and Yu-Cheng Hsiao. “A Framework for Cryptography Based Accountability and Service Invocation Control for Service Composition in a Multicloud Architecture,” Trustcom/BigDataSE/ISPA, 2015 IEEE. Vol. 1. IEEE, 2015. [13] Haeberlen, Andreas, Petr Kouznetsov, and Peter Druschel. “PeerReview: Practical accountability for distributed systems,” ACM SIGOPS operating systems review. Vol. 41. No. 6. ACM, 2007. [14] “Intercloud,” https://en.wikipedia.org/wiki/Intercloud [15] “Cloud Storage,” https://en.wikipedia.org/wiki/Cloud_storage. 27.

(33)