第二章 雲端運算之行為證明
第二節 相關證明技術與解法應用
壹 Proof of Violation
第一節所提到的作法最大的問題是證據的可信度太低，若要使證據具有效力，
在本實驗室過去的研究中提出了證明違約演算法（Proof of Violation）[8]，可讓使
用者與雲端服務提供商在每一次的服務請求時，都留下具有法律效力且經過簽章，
雙方皆不可否認的證據。證明違約演算法其中的協定可以偵測並證明雲端儲存系
統上的四種安全性質：保密性（Confidentiality）、完整性（Integrity）、寫入的循序
性（Write Serializability）、讀取的最新性（Read Freshness），合稱為 CIWF。使用
者可以偵測雲端儲存系統是否有違反 CIWF；而雲端服務提供商若是無辜的，則
也可以反駁使用者的誣告。
因為這個系統保證讓使用者所做的請求以及雲端服務提供商維護資料的狀
態都會被綁定在證據裡面，使得雙方對彼此都建立了不可否認性。而使用者所做
的每一次請求都會和雲端服務提供商交換證據，且這些證據都有利用鏈結雜湊
（Chained Hashes）的方式記錄下來，因此使用者端的裝置上面只需要保留最後一
個鏈結雜湊的證據（即最新的一筆證據），而雲端服務提供者則必須保留所有的證
據以便稽核時所需。
過去曾提出相關研究[9]，但是鏈結雜湊這個方法不能夠防止來自雲端服務提
供商的回復式攻擊（Roll-Back Attack），也就是利用恢復較為先前版本的舊資料以
及相關的電子簽章來掩蓋雲端服務提供商不小心遺失或是惡意遺漏了最新版本
的數據，除非使用者有將所有的證據保留起來或者在每一次交易完成後使用廣播
的方式將最後的證據告知其他使用者端的裝置。
貳 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]，即當使
用者對雲端服務提供商提出服務請求時，可能會受到網路傳輸速度影響或是使用
整體系統效能甚至可能癱瘓系統的運作。
參 四步驟交握協定與雙重鏈結雜湊
若是遇到雲端服務商無法立即取得執行結果的這類系統，我們使用 C&L Scheme 就可能產生如上所述之不利於系統運作的情況，則此類問題可以藉由四步 驟交握協定與雙重鏈結雜湊（Four-Step Handshaking Protocols with Double Chained
Hashes）[11]的方式來解決無法平行處理同時間收到多個服務請求的問題。如圖 4
（B）所示，在第 i 筆交易（Transaction）還沒完成時，就可以先將第 i+1 筆交易
鏈結上並接著執行後續的動作，如此一來便能夠省下許多等待時間（Waiting Time）。
Step 1
Step 2
ithtransaction i+1thtransaction Time
ithtransaction i+1thtransaction
Step 4
Step 1.1 Step 1.1 time
Step 4.1
（A）Four-Step C&L and（B）Four-Step DH
本文最終採用四步驟的交握協定配合雙重鏈結雜湊技術再加以改良至可以
運行在多個雲端服務提供商與使用者的環境中，由於系統架構自點對點之有責性
變成 Service Relaying Chains 之間的有責性，本文將會改變固有的證據儲存方式以
及當雲端服務提供商與使用者在做四步驟的交握溝通時，加入特定的資訊以供稽
核時審查不同 Service Relaying Chains 涉及至相同服務端時是否正確地串接其執
行順序，改良的細節與架構將在第三章提到。