證明違約協定

前一章提到為了讓服務提供者可以證明自己的清白或是讓使用者證明服務 提供者的確有出錯，過去的研究提出了 POV 技術，由三個元組組成：第一，他 需要定義一組特性，服務提供者提供服務給使用者時必須不能違反這組特性。第 二，證據必須是基於密碼學的證據，使用簽章將使用者和他們發出的請求和服務 提供者全部結合在一起。第三，稽核能夠藉由收集密碼學的證據來實現，證明特 性是否違反。稽核可以偵測出服務提供者是否違反了特性，或是服務提供者可以 證明自己是否受到使用者錯誤的指控。假若一個違反的事件發生，客戶端和服務 提供者可以利用密碼學的證據決定誰要來負責。並且，雙方若有爭議發生，他們 可以呈現證據給一個第三方 (如仲裁人或法官) 。

第二節 雲端儲存即時稽核協定

一篇先前發表的論文提出了一個以部分雜湊樹達成有效率的雲端儲存系統 即時稽核技術(2014 CloudCom) [14]，在此提到這篇論文的原因，是因為本論文後 面提出的方法能夠有效的解決目前碰到的問題，因此先在此簡單介紹之前這篇論 文的架構與做法。此論文考慮一個用戶有多個裝置，可能會同時有許多的裝置向 服務提供者存取的情況。為了達到多個裝置的即時稽核，以及解決使用者與服務 提供者之間的不可否認性問題，此論文提出了一個機制，如圖 1 所示。

圖 1 : 以部分雜湊樹達成有效率的雲端儲存系統即時稽核

首先，使用 merkle tree [17]。merkle tree 是一個對應檔案目錄的資料型態，

他的子節點為資料的雜湊值，樹的頂端為 root hash。圖 2 中的 (A) 是一個檔案 目錄，(B) 為他的 merkle tree，每一個檔案和資料夾都可以對應到一個雜湊值。

資料夾的雜湊值為：將資料夾內檔案的雜湊值連結 (concatenation) 起來，然後再 計算這個資料的雜湊值。使用者保留部分的 merkle tree，每一次請求讀寫檔案後

檢查 merkle tree 的 root hash 值是否和服務提供者回傳的一樣，才能確認服務提 供者沒有操作錯誤。

圖 2 : 雜湊樹圖示說明

儲存伺服器儲存使用者的資料夾及檔案；稽核伺服器與使用者的裝置交換證 據以及 merkle tree，以達到與服務提供者同步的步驟；使用者必須儲存 merkle tree，

以及最後留下來的密碼學的證據，用來和稽核伺服器更新目前最新的狀態。最後 同步伺服器儲存最後一個使用者存取後的密碼學的證據以及 root hash，以防止服 務提供者更改檔案或是稽核時需要的資料。

以上的架構雖然能夠運作，但我們發現在一個特別的情況下，使用以上架構 的系統會遭遇到非常嚴重的延遲，使用者會因為這個問題，在未開始操作檔案的 上傳下載動作前要等待一段明顯的延遲時間。此問題發生在使用者的一個裝置上 線前，有其他的裝置操作了非常多次的動作之後，通常是因為此裝置一段時間未

始用。因為後來上線的裝置需要先將自己儲存的 merkle tree 更新，前面累積了數 百次、數千次的動作，merkle tree 需要重新計算大量的節點的 hash 值，因此在 還沒正式做指定的工作前，使用者必須等待一段很長的時間才能開始，此為以上 架構之最壞情況(worst-case)。