改良的雲端儲存即時稽核協定

為了處理前面所提到的 worse-case，我們提出了一種全新的、更快速的架構，

能夠解決客戶端在真正檔案操作的動作前同步時間太長的問題，如圖 3 所示。

圖 3 : 改良的雲端儲存即時稽核架構

在這個新的架構中，一樣使用同步伺服器來儲存最後操作所留下的證據，即 服務提供者的回覆。但是在這個新的架構中，客戶端的設備完全不需要儲存任何 的 merkle tree 或證據資料，藉由利用多個各自獨立的服務提供者，收集他們回傳

的結果以即時的確認資料的版本是否正確。各個服務提供者的伺服器儲存使用者 的資料夾的 merkle tree，還有備份這次操作修改的檔案的前一個版本，為的是後 來稽核演算法的需要，利用備份的前一個版本的檔案記算出前一個版本的 merkle

tree。在後面的章節會解釋稽核演算法的步驟。

我們的系統的安全性基於一個假設：「同時有 k 個伺服器同時回傳錯誤結果 的機率是趨近於 0。」在此說明，因為我們可以選擇全世界不同地區的服務提供 者，不容易因為天然或人為的災害遺失所有伺服器上的資料；而不同的服務提供 者使用不同的演算法來備份使用者的資料，有心人士無法使用同一個方法來攻擊 各式各樣的系統，因此我們這個假設是十分合理的。有了這樣的假設，使用者可 以相信多數一樣結果的服務提供者是對的。每次的檔案操作請求後，收集各個服 務提供者的回覆並比較，若有不同的結果出現時，只要稽核與多數不同的服務提 供者就可以了 [18]。

即時稽核溝通架構:

當每次設備 P 要向伺服器提出請求，都會遵循以下步驟：

步驟一 : Lock 同步伺服器。

步驟二 : 當設備 P 要存取他帳號(用戶 U)裡的檔案，他會發送一個請求訊息

(request message) Qi, Qi=(OPi, SNi, [OPi, SNi]pri(U))給各個伺服器。其中 OPi為請求的格式，有操作的類別(讀取檔案、寫入檔案或稽核要求)、

目標檔案的路徑、目標檔案的雜湊值。SNi 為這次動作的序號。

步驟三 : 當一個伺服器收到 Qi後，藉由驗證 [OPi]pri(U)電子簽章，以及檢查 OPi

裡面的檔案的 hash 值，確認是否為正確的請求。

步驟四 : 如果 Q_i為寫入檔案 f，伺服器備份檔案 f 的 hash 值，使用 Q_i的 OP_i中 的檔案 hash 值更新 merkle tree。

步驟五 : 伺服器將檔案 f 的 hash 值和 merkle tree 的 roothash 值加入執行結果 L_i。 步驟六 : 伺服器回傳一個回應訊息(acknoledgement message) ACK_i給設備 P，其

中 ACK_i=(Li,Qi,[Li,Qi]pri(Server))。

步驟七 : 設備 P 收集所有伺服器回傳的 ACK_i，確認所有的 ACK_i結果皆相同，

更新同步伺服器的 ACK_i。 步驟八 : Unlock 同步伺服器。

步驟九 : 如果 Q_i為讀取檔案，向最近的伺服器下載檔案，確認 ACK_i中的 hash 值是否相同。

步驟十 : 如果 Q_i為寫入檔案，將檔案上傳到每一個伺服器。

步驟二在請求訊息中加入了序號，是為了保障服務提供者端的安全。序號從

0 開始，和 i 是一樣的值。不同設備之間利用同步伺服器可以得到最新的序號，

因此整個系統共用一組序號就可以了。在請求訊息中加入序號能夠讓使用者無

法假造前一次動作的證據，有了這個序號，使用者的證據和服務提供者的證據 就必須一致，使用者不能任意拿出對他有利的版本再宣稱是最後的版本，因此 加上序號便能夠保護服務提供者端。

在步驟七中，使用者藉由檢查每一個伺服器回傳的結果是否相同，馬上可以

知道系統是否發生錯誤，服務提供者是否給予不正確的檔案或證據，即時的啟動 稽核的機制。因此在這樣多個裝置的操作環境中，能夠防止回捲攻擊。

因為伺服器回傳的 ACK 中有包含 root hash，最後儲存在同步伺服器中，因 此可以確定在使用者未進行下一個請求前，服務提供者所儲存的資料是被驗證過 沒有問題的。接著使用者發出下一個請求，若在這個請求後伺服器回傳的結果是 錯誤的，就可以確定是在這一次的請求發生問題，使用稽核的演算法也就只要檢 查這一次的過程中哪裡出錯，就可以確定發生錯誤的是使用者或是服務提供者。

使用者要啟動稽核，首先需要向伺服器索取前一個版本的 merkle tree (MT_i-1)，接 下來稽核演算法檢查完以下兩點，就能證明這次操作的過程是否有出錯：

1. 使用者檢查 MTi-1的 root hash，應該要和儲存於同步伺服器中的前一版本證 據 (ACK_i-1) 裡面的 root hash 一樣，如此一來才能確定服務提供者沒有給錯 誤的 merkle tree 給使用者。

2. 使用者以這次請求中的 OPi 裡面的 hash 值更新 MTi-1 ，也就是找到對應的 檔案位置，將 hash 值修改後，在由下往上重新計算到 root hash，這也就是 為什麼要完整的 merkle tree 的原因。於是更新後 MT_i-1 的 root hash 應該要

和服務提供者現在的 root hash 是一樣的，若不同則表示這一次的請求是服務 提供者出了問題，因此才會和使用者重新驗算出的 root hash 值不相同。如此 一來，使用者就有足夠的證據能夠提供法院或是信賴的第三方，證明服務提 供者的錯誤，以獲得雙方約定的賠償。