在這個章節，我們要論證原始的鏈結雜湊架構在單一帳戶下，使用不同的裝 置來交互存取雲端上的資料會衍生的問題。首先，我們先說明原始的鏈結雜湊的 運作模式，為了更正式的描述鏈結雜湊，我們先定義幾個符號，[O]Pri(x)表示電子 簽章簽屬資料物件(Data object)O，並且利用使用者 X 的私有金鑰簽屬，此外在中 括號裡面以逗號隔開，表示多個資料物件被使用者 X 簽屬，如例子，[O1, O2, O3]Pri(x)
表示資料物件 O1,O2,O3 被使用者 X 的私有金鑰簽屬。以下步驟說明鏈結雜湊架 構如何運作:
Step 1: 當某個使用者 U 想要在他的用戶端存取他私人的文件，他會先發送一個
請求訊息(Request Message) Qi, 此外 Qi=(OPi, [OPi]pri(U))給服務提供者(Service Provider)，OPi表示請求的運算，可以是開新文件、更新文件、或是讀取文件。
Step 2: 當服務提供者收到從使用者送來的請求 Qi，首先，利用 U 的公開金鑰檢 查電子簽章[OPi]pri(U)是否正確，若是正確則回傳回應訊息(Response Message) Ri,此外 Ri=(Qi, [Qi, CHi–1]pri(Provider))給使用者 U。其中 CHi–1 是 (i–1)th chain hash 而且 CHi–1=[Qi–1, CHi–2]pri(Provider)。
Step 3: 步驟三:當使用者 U 收到了 Ri，首先，利用步驟一使用者發送的 Qi以及
CHi–1=[Qi–1, CHi–2]pri(Provider)進行驗證，若驗證成功，則使用者發送回覆回應訊
息(reply-response message)給服務提供者，此外 RRi=(Ri, [Ri]pri(U) )。服務提供
Step 4: 者要儲存所使用者發送的回覆回應訊息已備未來驗證之用途。
Step 5: 服務提供者執行剛才使用者提出的請求，假設執行結果為 Li，服務提供 者回傳服務承認訊息(acknowledgement message)給使用者 U，此外，ACKi=(Li,
RRi, [Li, RRi]pri(U))。使用者 U 必須持有最新的服務承認訊息，這表示使用者
端的證據，未來雙方產生爭議時，使用者必須要拿出此證據來證明對錯。
圖 二-1 k 個運算交換訊息
表示利用鏈結雜湊架構執行 k 個運算，表格內呈現所有的運算訊息。CH0是 事先定義好的，當使用者和服務提供者協議要用鏈結雜湊架構時，雙方必須事先 定義一個基準。在執行 k 個運算後，服務提供者必須要儲存所有的證據 (i.e., RR1,
RR2, …, RRk)而且使用者只需要存最新的證據(i.e., RRK).客戶端回傳的證據 RRj+1 被鏈結在 RRj 之後，且 1jk–1。這表示加密演算法可以被用來驗證 RRj是 RRj+1 之前的回覆回應訊息。圖 二-2a 假設現在使用者的使用狀態為，並且已經執行
了 k 個運算(i.e. OP1, OP2, …, OPk)，我們可以很容易的利用這 k 個運算來解析狀態
。所以在雙方要使用這個協定時，服務層級協定必須規定服務提供者保存所有
的伺服器端證據(server-side attestations) (i.e., RR1, RR2, …, and RRk)，這可以讓我 們用來驗證寫入的循序性 和讀取的最新性: (1) 使用者 U 提供他最新的 ACKk, 和(2) 服務提供者必須提供 RR1, RR2, …, 和 RRk. 就像上述說明的，我們可以知 道所有運算的鏈結關係。使用者和服務提供者之間的不可否認性問題是不存在的，
在後面章節，我們將探討如何消除所有累積的證據。
Q1=(OP1,[OP1]pri(U))
R1=(Q1, [Q1,CH0]pri(Provider)) RR1=(R1,[R1]pri(U))
ACK1=(L1, RR1, [L1, RR1]pri(U)) Q2=(OP2,[OP2]pri(U))
R2=(Q2, [Q2,CH1]pri(Provider)) RR2=(R2,[R2]pri(U))
ACK2=(L2, RR2, [L2, RR2]pri(U)) .
. .
Qk–1=(OPk–1,[OPk–1]pri(U))
Rk–1=(Qk–1, [Qk–1,CHk–2]pri(Provider)) RRk–1=(Rk–1,[Rk–1]pri(U))
ACKk–1=(Lk–1, RRk–1, [Lk–1, RRk–1]pri(U)) Qk=(OPk,[OPk]pri(U))
Rk=(Qk, [Qk,CHk–1]pri(Provider)) RRk=(Rk,[Rk]pri(U))
ACKk=(L k, RR k, [Lk, RRk]pri(U)) 圖 二-1 k 個運算交換訊息
接下來，我們將解釋為什麼鏈結雜湊架構不足以應付一種常見的情形，那就 是在單一帳戶下被多個客戶端裝置交互的使用。以一個例子來說，Dropbox 雲端 儲存服務提供者可以讓智慧型手機利用某個帳戶自動的上傳照片，而且他還可以 開啟資料分享的功能，將他分享給朋友。
我們假設每個客戶端的裝置在存取資料時，都利用同一個帳戶並且不交換使 用者端的證據，而且為了節省使用者端的資源利用率，每個客戶端的裝置都只儲 存最後一個從服務提供者送來的使用端證據，以下有幾個原因是為什麼使用者端 的裝置很難交換最後一個使用者端的證據，以確保每個使用者端的裝置都有最新
的證據：(1)顯而易見的，並不是每個使用者端的裝置都一定同一時間上線，(2) 使用者可能在他的帳號加入新的裝置以便使用，(3)因為使用者的裝置有可能頻繁 的交互的使用，所以在使用者的裝置間交換最後一個使用者端的證據有可能需要 極大的成本，(4)由於使用者的裝置有可能是記憶體很小的嵌入式裝置，所以在使 用者端的裝置上儲存所有的使用者端證據不太可行。
我們現在要描述為什麼服務提供者可以發動回復式攻擊，就像是圖 二-2A。
假設現在有 x 個客戶端裝置都具有權限存取使用者 U 的資料，而且這些裝置已經 成功做了 N 次的運算，分別為 OP1, OP2, …, OPN。此外，我們假設現在儲存在雲
端上的資料有部分已經損毀(可能伺服器損毀或是遭惡意攻擊)，此時服務提供者 企圖還原這些資料。假設使用者 U 在做這 N 次運算之前資料的原始狀態為，而 且系統狀態只能回復到，表示 OPk之後的運算全部遺失了，此時服務提供者試
圖用不正當的手法將資料回復到原始狀態如以下步驟。首先，服務提供者試圖隱 藏伺服器端儲存的證據，從 RRk+1 到 RRN，由於這些證據都是存在伺服器上，因 此所有客戶端的裝置都不會發現這個伺服器違規的動作，並且持續地發送要求，
而且每個客戶端都沒有最新的證據，他們沒有辦法確認伺服器端是否就像步驟三 一樣，正確地將他們的要求鏈結起來，因此客戶端在當下為了能讓要求順利執行，
只能不檢查證據的正確性，持續的更新做過的運算，當 X 個客戶端裝置都做過運 算並且持續在 OPk之後更新，最後所有的客戶端都成功更新證據，而且 Server 將 這些 OP 都鏈結進 OPk之後，如圖 二-2 B 所示，服務提供者已經將伺服器端的證
據都鏈結起來了，如 RR1, …, RRk, RRq, …, RRM。因為所有的客戶端裝置都成功