Partial Merkle tree

第二章即時稽核架構

2.1 Partial Merkle tree

接著在這個章節裡，我們將會開始介紹，用戶與服務商之間同步交換 Merkle

tree 以及 root hash 的機制。為什麼無法解決不可否認性的問題，以及講解為何要改進 Merkle tree 以及其方法。

首先當一個用戶開啟使用服務後，用戶開始上傳檔案以及資料夾，例如圖一.1，接著將計算每個檔案的 hash 值並記錄下來，如圖一.2 所示，以 hash tree 的架構，從樹的底層的葉，將檔案以及資料夾一層一層疊上來，例如 h(d2) = h(h(f3), h(d3),h(f4))。而最後頂端之 hash 值稱之為 root hash。只要底下某一個節 點有所變動，root hash 就會有所變動。接著我們將整個資料夾的架構記錄起來，

稱之為 Merkle tree，我們實作的範例可參考附錄裡的圖 A.1，而這樣的結構儲存在用戶端，若是在用戶跟服務商存取檔案過後雲端供應商傳回 root hash，與用戶

所儲存的 Merkle tree 所算出 root hash，若是相同，即可驗證雙方資料夾結構的一致性。然而這樣的作法會有三個問題：第一、無法支援多個用戶，因為在用戶做完檔案操作，並更改 Merkle tree 後，必須要將此 Merkle tree 傳給其他的用戶，

以確保下一個用戶在作操作時，手上的 Merkle tree 為最新的狀態，但是此舉是非常耗時間的，因為必須等到其他用戶都上線更新；第二、當檔案數量越多，用戶儲存的 Merkle tree 也會越來越大，不管在任何計算以及儲存上都會造成負擔；

第三、就算以上兩點就解決了，但是若是服務商傳回的 root hash 與自己不同，

則無法得知用戶與服務商雙方誰對誰錯，因為可能是用戶自己忘記更新檔案，又或者是服務商耍賴更改資料，想要敲詐用戶，所以雙方必須要有一個雙方承認的證據，在有糾紛的時候，可以提出來稽核。我們的詳細解決方法在下一節會說明。

為了減少用戶在儲存 Merkle tree 空間上的負擔，我們提出了 partail Merkle

tree(pMT) ，讓用戶只需儲存部分的 Merkle tree。想像一種真實的情況，如圖一.1 所示，這是一名用戶的資料夾，並且儲存他的 Merkle tree 以做為驗證(圖一.2)。

今天這名用戶可能會在這個月內因為工作只動到 d2 資料夾下面的檔案，假設 d3 下面的檔案以及資料夾數目非常可觀，而使用者也不常用那個資料夾的話，其實在 Merkle tree 中，如圖二.2 所示，只需紀錄 d3 的 hash 值，而不需將 d3 下的整個結構記錄在 client 端，因為我們在驗證時，若是 d3 有錯，整個 root hash 就會錯，可以再省下使用者的負擔。

: 資料夾hash值 : 檔案hash值 f1

d2 d3 d4

: 以下忽略的資料夾hash值

圖二.2：部分的 Merkle tree 2.2 即時稽核溝通架構

接下來我們會呈現用戶或裝置如何與同步伺服器有效率的即時稽核，並且達到不可否認性。當每次用戶 P 向服務商發出請求，都必須遵循以下的機制步驟：

步驟一： Lock(Mutex)

步驟二：向同步伺服器取得 root hash(RH)以及最後的證據(α_L)，確認目前是否最新狀態

步驟三：若取得的 RH 不同，則需要向稽核伺服器更新最新狀態。假設目前同步伺服器的最後證據為αL，而用戶 P 手上的證據為 α_p，則將(α p, α L) 送給稽核伺服器。

步驟四：稽核伺服器將用戶未更新的區段，也就是αp到α L之間的證據交給用戶步驟五：確認α L  αp是否正確的鏈結

步驟六：並取出在這段證據之中，是寫入而且在 pMT_p之中，即更新 pMT_p，更新最新狀態後算出 root hash 確認是否與 RH 相同，接著才能做存取的動作。

步驟七：我們假設設備 P 要執行檔案的運作到用戶 U 的帳戶，以下是與稽核伺服器交換證據的步驟：

 當設備 P 想要存取他帳號裡的檔案，他會送一個請求訊息

(request message) Qi, 則 Qi=( OPi, [OPi]pri(U))) 給稽核伺服器。其中

OPi為請求的格式，例如新增檔案、更新檔案內容或者讀取檔案。

 當服務供應商收到 Qi 後，要藉由驗證[OPi]pri(U)電子簽章，確 認是否為正確的請求，接著就送一個回應訊息(request message) R_i，則 R_i = (Qi, [Qi, CHi–1]pri(AuditingServer)) 給用戶，其中 CHi–1 為第(i–1) 個鏈結雜湊，且

CHi–1=[ Qi–1,CHi–2]pri(AuditingServer)。

 當用戶 P 收到了 Ri之後，用戶藉由 Q_i 和 CHi–1=[Qi–1,

CHi–2]pri(AuditingServer) 去驗證其數位簽章是否為正確。如果 R_i 與 Ri–1

順序為正確，則用戶 P 回傳(reply-response message) RR_i給服務供

應商，其中 RR_i= (R_i, [R_i]_pri(U))。

 稽核伺服器執行 Qi ，假設執行結果為 L_i，服務供應商回傳一 個確認訊息(acknowledgement message) ACK_i給用戶，其中

ACK_i=(L_i, RR_i, [L_i, RR_i]pri(AuditingServer))，則用戶必須保存。

步驟八：如果是 Q_i為讀取 f 且 pMT_p有 f 之雜湊值(hit)：

 儲存伺服器將 f 傳給用戶

 由用戶的 pMTp找到 f 的雜湊值，確認 Ack_i中的 hash 值是否相同，完成讀取。

 unlock 同步伺服器

否則 (也就是 f₁雜湊值不在 pMT_p之中)：

 和稽核伺服器下載 pMT({f})

 將 pMTp = pMT_p ∪ pMT({f})

 向儲存伺服器下載 f1

 由用戶的 pMTp找到該檔案的雜湊值，確認 Ack_i中的 hash 值是否相同，完成讀取。

 unlock 同步伺服器

步驟九：如果 Q_i為寫入 f₁且 pMT_p有 f 之雜湊值(hit)：

 將改寫的檔案傳到伺服器

 將欲改寫的檔案雜湊過後更新 pMTp

 根據 pMTp重新計算新的root hash(RH’)

 更新同步伺服器的 α L以及 RH 後 unlock 否則 (也就是 f 雜湊值不在 pMT_p之中)

 和稽核伺服器下載 pMT({f})

 將 pMTp = pMT_p ∪ pMT({f})

 將改寫的檔案傳到伺服器

 將欲改寫的檔案雜湊過後更新 pMTp

 根據 pMTp重新計算新的root hash(RH’)

 更新同步伺服器的 α L以及 RH 後 unlock

在步驟七之中，我們使用了接下來將加了數位簽章的證據鏈結起來，根據

C&L 機制[12]，如果用戶可以取得最後的證據以及 root hash 的話，在多個裝置操作的機制裡，是可以避免回捲攻擊的。在我們的機制裡，使用 semaphore Mutex 讓同時間只有一個裝置可以開始我們的機制，因為只有一個裝置可以 lock

semaphore 去執行我們機制，所以我們可以保證 CIWF。

接下來我們講解每個檔案的操作都是可以成功的完成稽核。在步驟六裡面，

因為所有的證據都是正確鏈結的關係，設備 p 每次都能成功的更新他的 pMT_p，

我們有以下幾種狀況：

 如果檔案操作為讀取檔案 f 且 f 的雜湊值有在 pMTp裡面，一定可以保證所讀到的檔案 f 是否為正確。

 如果檔案操作為讀取檔案 f 且 f 的雜湊值卻沒有在 pMTp裡面，設備 P 下載包含 f 以及所有相關更動資料夾，因為在步驟二中，每次都會獲得最新的 root hash，就可以辨別更動後的 pMT_p是否為正確。接著，

就可以根據 pMT_p來辨別讀到的檔案是否為正確。

 如果如果檔案操作為寫入檔案 f，只要確保證據是否正確被鏈結，

pMTp是否更新為最新，最後把證據以及更動後的 root hash 送給同步伺服器儲存。

2.3 即時稽核架構討論

接下來在這一節關於即時稽核架構我們提出了幾個問題來討論。

為什麼這個機制可以保證不可否認性(non-repudiation)，檔案完整性(data integrity)，寫入的循序性(write serializability)，以及讀取的新鮮性(read freshness)？

(簡稱 CIWF[8])。在步驟七之中，我們使用加了數位簽章的證據並按照順序鏈結起來，根據 C&L scheme，如果用戶可以取得最後的證據以及 root hash 的話，在多個裝置操作的機制裡，是可以避免回捲攻擊的。在我們的機制裡，使用 semaphore Mutex 讓同時間只有一個裝置可以開始我們的機制，因為只有一個裝

置可以 lock semaphore 去執行我們機制，所以我們可以保證 CIWF。

為什麼要將最後的證據以及 root hash 放在同步伺服器？首先我們必須要假設同步伺服器不可被攻破，如果被侵入或是有人放了錯誤的證據或者是 root hash，

是有可能讓稽核伺服器發動回捲攻擊的。如果不將這些資料放在同步伺服器，假如服務商修改稽核伺服器上的資料，將舊的版本的證據或是 root hash 交給用戶，

也就是回放攻擊，因為用戶不知道其他用戶更新了哪些部分，所以是不能相信服務商的。因此最後一個做存取的用戶必須將最後做完的證據以及 root hash 放在同步伺服器。

在這個機制之中，如果不使用同步伺服器交換證據的話，那就要使用

Broadcasting 的做法，在其中一個設備要做操作之後必須要將證據傳給其他用戶，

其解決方法並不太完備，接著想像一種情況，當設備 A 對 server 請求寫入檔案了以後，完成後尚未將最後的證據傳送出去時，設備 B 就要向 server 做下一個

operation，則設備 B 可能得到錯誤的 file 卻不知道，當這類的事情沒有避免，之後又有更多的 Device 做操作，則其他設備都會得到舊版本的檔案或證據，整個機制將無法保證正確。並且若是透過服務商將證據傳給其他用戶，則會有兩個問題，(1) 無法避免服務商傳回來的證據是否確實為最新的版本，在設備 A 沒有上線的情況之下，是很難求證以及相信服務商的。(2) 若是設備 A 直接傳給其他用戶，則必須等待全部用戶都上線更新完成，才能確保下一個設備在做存取時是最

新的狀態，但是這是非常浪費時間的。

因此，如果能做到在每次其中一個用戶做完操作之後，其證據能馬上且安全的送到其他用戶，避免上述的問題的話，即可不需要同步伺服器幫忙。

第三章實作與實驗數據

在這個章節我們實作了一系列的實驗來證明此架構的可行性以及詳細執行時間，包含產生 root hash、Merkle tree 的時間和各種步驟所需要花的時間。

首先我們看到我們實驗所使用的三個不同的帳戶，如表三.1 所示分別是(1) 帳 戶 A，屬於檔案數目以及容量小的範例，(2) 帳戶 B 為檔案數目眾多，但是每個檔案容量皆不大，(3) 帳戶 C 為實際使用 20 年的一個資料夾，所以有參考價值。

表三.1：實驗數據中的三個範例帳戶

帳戶 A 帳戶 B 帳戶 C

Number of files

44 22968 28404

Number of folders

6 188 1718

Total size

666 MB 32.9 MB 6.9 GB

表三.2：從未 hash 過的檔案所產生 root hash 所需的時間(單位:秒) 帳戶 A 3.208 帳戶 A 15.744

帳戶 B 8.893 帳戶 B 875.211 帳戶 C 120.003 帳戶 C 978.889

(A) PC (B) Hadoop system

表三.3：直接從檔案的雜湊值產生 root hash 所需的時間(單位:秒) 帳戶 A 0.023 帳戶 A 1.823

帳戶 B 3.874 帳戶 B 198.572 帳戶 C 32.423 帳戶 C 347.568

(A) PC (B) Hadoop system

接下來的實驗我們在兩個平台上面實作：(1) Windows 7 電腦 (2) Hadoop 系統[17]，而檔案都是自動複製以及分散到 Hadoop 系統之中。其中(1) Windows7 電腦規格 CPU 為 3.1GHz Intel Core i5 2400 四核心，6GB 的記憶體，500GB 的硬碟空間。(2) Hadoop cluster 規格為由五台 PC、五個節點組成。每個節點都有

3.0GHz Intel Core 2 Quad processor 的 CPU、2 GB 的記憶體、500 GB 的硬碟空間、Ubuntu 10.04 LTS 的作業系統以及 Java Development Kit 6。

表三.2 為第一次帳號開啟時，所有的檔案都還沒有算過雜湊值，所以必需

在文檔中以部分雜湊樹達成有效率的雲端儲存系統即時稽核 (頁 17-0)

第二章 即時稽核架構