證據縮減

保存所有證據一定可以發動且完成稽核的動作，不過事實上因為證據的數量

會無限成長，所以雲端服務提供商希望可以做證據縮減(Short cut)。假設我們可

以產生出所有檔案的 Partial Hash Chain，就可以對所有的檔案做稽核的動作，因

此雲端服務提供商只需要保存可以讓稽核順利完成的部份證據即可。

由稽核的特性我們可以知道 Partial Hash Chain 都是由最後一筆證據開始往

前驗證而產生的。比較直覺的解法是從最後一筆證據開始往前選取，直到選取的

證據讀寫的檔案包含所有的檔案後，剩下沒被選取到的檔案即是可以刪除的檔案。

上述方法留下來的證據即可產生所有檔案要稽核時所需要的 Partial Hash Chain，

圖三-7 及圖三-8 為其示意圖。在圖三-7 中，任何稽核皆只會向前驗證到第三筆

證據，並不會在向前做驗證的動作，因此第三筆證據前面的證據可以刪除，

如圖三-8。

圖三-7 證據縮減前的證據

圖三-8 證據縮減後的證據

假設 SP 內保存的檔案非常多，為了檢查證據縮減後留下的證據包含所有的

檔案，發動證據縮減可能會耗時一段時間而卡住服務。且證據縮減也不能保證每

次都可以成功。假設第一筆證據所服務的檔案之後都沒有再被讀寫過，則沒辦法

刪除任何一筆證據，也就是證據縮減失敗的狀況。又因為沒辦法確保每次證據縮

減都可以成功，所以何時要發動證據縮減也是一個問題。

由於從最後一筆證據來做證據縮減會遇到上述的問題，因此我們換了一個方

向來做證據縮減。從第一筆證據檢查該證據是否可以刪除，如此一來可以先快速

的檢查證據縮減是否會失敗以決定是否發動證據縮減，並且把檢查的步驟打散在

每次的請求服務動作以提升速度，方法如下：

Step 1： 每次 SP 產生新的證據時，SP 會把上一個讀寫該次產生的證據所讀寫 的檔案的證據標示為可刪除。這邊指的標記可以是產生一個對映證據

的陣列或者其他方法，只要沒有更改證據內容皆可。

Step 2： 檢查第一筆證據是否可以刪除(IH 在第一筆證據刪除時一併刪除)。倘 若第一筆證據可以刪除則刪除，持續檢查下一筆證據是否可以刪除，

直到無法刪除。至此，證據縮減結束。

圖三-9 為一證據縮減的範例，圖三-9(a)為 SP 的初始狀態，SP 內共有 F1、

F2、F3 共三個檔案，四個證據，閃電符號即是標記為可刪除的標記。以圖三-9(a) 為例，第二筆證據讀寫了檔案 F2 後，在第四筆證據又對檔案 F2 進行讀寫，因此

檔案 F2 最新的雜湊值應記錄在第四筆證據，第二筆證據應標示為可刪除，如圖

中的閃電標記。圖三-9(b)為圖三-9(a)狀態後某個裝置讀寫了檔案 F3，SP 加入該

F1 F2 F3 F2 IH

F1 F2 F3 F2

IH F3

圖三-9(a)證據縮減範例-1(初始狀態)

圖三-9 (b)證據縮減範例-2(讀寫F3後)

圖三-9 (c)證據縮減範例-3(讀寫F1後)

F2 F3 F1

次讀寫 F3 的證據後，將上一次讀寫 F3 的證據標示為可刪除，由於第一筆證據還

無法刪除，所以無法進行證據縮減，五個證據皆須保留。圖三-9(c)為圖三-9(b)狀

態後有另一個裝置讀寫檔案 F1，SP 加入該次讀寫 F1 的證據後，將上一次讀寫

F1 的證據標示為可刪除，此時證據的前三筆皆標示為可刪除，因此只需保留後 三筆證據即可完成所有檔案的稽核。證據縮減完後，SP 保留的證據如

圖三-9(c)。

即便有了上述的證據縮減方法，還是可能遇到稽核的效能下降的問題。假設

SP 內有 N 個檔案，因為 SP 保存的證據讀寫的檔案必須包含所有的檔案，所以

SP 最少需儲存 N 個證據。當 N 越大時，每次稽核所產生的 Partial Hash Chain 平

圖三-9 證據縮減範例

均長度就會變長，稽核的效能就會越低。

原本證據只串接成一條雜湊鏈，現在將它分割成 K 條雜湊鏈，將每個檔案

的檔名取 Hash 再取 k 的餘數，使得每一個檔案都對應到唯一的雜湊鍊上。

圖三-10 為證據分割前後的示意圖，如圖三-10(b)分割後，只要有讀寫檔案 F1

的證據都串接在第一條雜湊鏈上。

共K條

F1 F1

IH

F2 F2

IH

F_K Fk

IH

F1 F2 F3 Fk

IH

圖三-10(a) 分割證據前

圖三-10(b) 分割證據後 圖三-10 分割證據前後