• 沒有找到結果。

在一段長時間後,客戶端裝置理所當然的會有數以百計的資料運算,然而這樣 的情況會造成服務提供者必須儲存大量的伺服器端證據造成系統負擔,因此我們 必須要有方法消除這些證據,然而利用雜湊樹或是馬可樹(Merkle tree)[12]可以有 效的解決這個問題。雜湊樹是由雜湊值所產生的,樹葉是將資料區雜湊過所產生 的值,而且雜湊樹的最頂端是雜湊樹的樹根(root hash)。圖 四-1A 描述了雜湊樹。

每一個在資料夾的資料都連結了各自的雜湊值。常用的加密雜湊演算法為 SHA-1、

Whirlpool、Tiger。資料雜湊的符號在這裡表示 h(資料名稱)。如資料 f6 的雜湊值 為 h(f6)。此外,資料夾的雜湊值是資料夾內所有資料雜湊值的串接,也就是

h(d2)=h(h(f3),h(d3),h(f4))。雜湊樹的樹根就是所有資料夾根的雜湊值串接在雜湊,

如 h(d1)=h(h(f1),h(d2),h(f2))。

d1

在帳戶新增之後,使用者更新一些資料和包含資料的資料夾。首先,服務提 供者和客戶端的裝置先各自算出他們所擁有資料的雜湊樹的樹根,然後比較他們 得到的雜湊樹的樹根,同意這個雜湊樹的樹根為第一個時代所產生的雜湊樹的樹 根。接者,服務提供者送出一個訊息為{(Root hash, EpochID), [Root hash,

EpochID]Pri (Server)},確認並同意它為雜湊樹的樹根。之後,使用者回送簽章過的 承認訊息。最後,服務提供者利用所有使用者的資料產生一個資料的骨架(file

skeleton (FSK))並將它儲存起來。這裡要注意的是使用者也需要儲存協議過的雜湊

樹的樹根。資料的骨架包含所有資料的結構、名稱、以及所有資料及資料夾的雜 湊值,如圖 四-1B。後續的資料運算(包含讀取與寫入),都要遵守第三章提及的 協定。

我們現在要描述當稽核過後,或是累積過多的伺服器端證據,該如何消除證 據。事實上我們是在同一時間進行稽核和驗證證據。在消除證據之後,我們轉換 現在第 i 個時代到第 i+1 個時代。以下是消除證據的步驟(這裡要注意的是,使用 者必須選一個客戶端的裝置來實施溝通的需求以及運算,我們假設協議好的第 i 個時代的雜湊樹的樹根已經存在裝置中):

Step 1: 服務提供者送第 i 個時代的 FSK F 給客戶端的裝置。

Step 2: 如果驗證 F 是正確的,客戶端的裝置使用 F 並且同意某個雜湊值是第

i 個時代的雜湊樹的樹根。

Step 3: 服務提供者回送伺服器端的證據給客戶端的裝置,這些證據就是先前提

到的從客戶端的裝置收到的回覆回應訊息,我們假設它們為{RR1, …, RRz}。

Step 4: 客戶端的裝置驗證{RR1, …, RRz} 是否正確。

Step 5: 根據現在使用者帳戶的資料夾結構,服務提供者計算出最新的雜湊樹的 樹根(這裡稱之)。

Step 6: 客戶端的裝置利用 F 以{RR1, …, RRz}推導出修正過 FSK F的,並且根 據 F計算出雜湊樹的樹根(這裡稱為)。

Step 7: 服務提供者和客戶端的裝置比較它們剛才推算出的雜湊樹的樹根是否 相同,如果等於,代表雙方同意此雜湊樹的根為 i+1 的時代的雜湊樹 的樹根。服務提供者送出訊息{[, (i+1)th Epoch ID], [, (i+1)th Epoch

ID]Pri(Server)}給客戶端的裝置。

Step 8: 服務提供者產生現在資料夾狀態的 FSK,並將它儲存起來。這就是第 i+1

的時代的 FSK。

{RR1, …, RRz}這些證據可以在步驟八之後刪除,顯而易見的,並不是所有在相 同帳戶底下的使用者裝置都會被通知轉換新時代,在開始一個新的時代後,連結 每個客戶識別名稱的 LSN 都會重新從 1 開始,因此當某個客戶端裝置送請求訊息 時,會發現 LSN 不正確,此時服務提供者會通知此裝置已經進入新的時代,客戶 端的裝置必須重置 LSN,並且發送正確的請求訊息。

相關文件