相關實驗數據

在這個章節中，我們做了一系列的實驗，來證明我們的結果比以往的作法能 夠更快速地達到我們的目的。我們使用 JAVA 來實做我們的即時稽核架構，以及

digest function 為 java.security.MessageDigest 中的 SHA-256 algorithm，實驗的電腦 為 Macbook Air 2014，作業系統為 OS X El Capitan 10.11.5，處理器為 1.4GHz Intel

Core i5，記憶體為 4 GB 1600 MHz DDR3。而我們將利用這台電腦中的函式庫來 做為實驗的對象，其中包含了 OSX 內建的函式庫以及許多應用程式的函式庫，

總共有 149,487 個資料夾以及 717,976 個檔案。其中所安裝的應用程式有:FaceTime、

Photos、Maps、Mail、LINE、．．．等。

第一部分讓我們對 Index function Γ 的碰撞機率作一個簡單的測試，在我們要 從一個檔案的 Slice 計算出 Root Hash 前，我們必須先串聯儲存在中的 PB-pair，

才能計算出這個檔案所在位置的 Leaf node 的 Hash 值，而如果我們的 Leaf node 中的 PB-pair 數量非常多時，那麼我們就會花費非常多的時間在串聯這些 PB-pair，

就會影響到我們計算 Root Hash 的時間，所以我們的 Index function 必須要能夠均 勻分散我們所要儲存的檔案 Hash 值。我們將實驗平台的函式庫放進各個樹高的 FBHTree，觀察存放了不同數量的 PB-pairs 在 FBHTree 中碰撞的情形。在表 1 中，

是我們分別對樹高 1 到 20 的 FBHTree 作了碰撞測試的表格。

18

表 1: Index function Γ 的碰撞測試 Tree Height：FBHTree 的樹高

#Leaf Nodes：FBHTree 中的 Leaf node 總數量

#AVG collision：在一個不為空的 Leaf node 中儲存 PB-pairs 的平均值

#MAX collision：在一個不為空的 Leaf node 中儲存 PB-pairs 的最大值 Tree Height #Leaf node #AVG collision #MAX collision

1 1 717976.00 717976

表 2: FBHTree 容納不同數目檔案的操作時間 Tree Height:FBHTree 的樹高

#Files:FBHTree 容納的檔案數目

AVG Collision:Leaf node 的平均碰撞數目

Audit time:Algorithm 1 做了 500 次的平均時間(單位:ms) Update time:Algorithm 2 做了 500 次的平均時間(單位:ms)

Tree Height #Files AVG

Collision Audit time Update time

1

20

圖 10: FBHTree 容納不同數目檔案稽核和更新時間折線圖

22

從圖 10 可以看出，在樹高少的 FBHTree 中，因為 PB-pair 碰撞的數量比較 多，所以需要花比較多的時間串聯 PB-pair 計算 Hash 值，而樹高超過 12 層之後 碰撞數量減少，但是計算 Hash 的時間仍會遞增，所以時間仍然會維持在同一個 時間區間中，在這邊我們可以知道，只要將 FBHTree 的樹高設定在 10 之後，稽 核速度會是較佳的。

接下來的部分是初始化的時間測試，假設我們首次使用的 VM 在第一次開啟 時是安全沒有被篡改過的狀態，在首次使用時，我們必須先將安全 Library 的狀 態儲存起來，我們分別實作了論文中提到的三種檢測方法 Integrity checking、

Merkle tree 以及 FBHTree。

表 3 為首次使用服務時所建立 Hash Map、Merkle tree，Integrity checking 的 方法我們利用 java.util.HashMap 將檔案的絕對路徑以及檔案 Hash 值儲存成一個

<Key,Value>的 HashMap 來實作。我們在計算這些檔案的 Hash 值時就花了 509.227 秒。

表 3: Integrity checking 以及 Merkle Tree 的初始化比較

檢測方法 Cost Time(s) Size(MB)

Integrity checking 516.086 147.6

Merkle tree 566.482 87.2

表 4 為首次使用服務時所建立 FBHTree 所花的時間以及其建立之後所佔用 的容量大小，FBHTree 的初始化會先將 FBHTree 的節點以及指標結構建構起來，

然後在將檔案名稱以及檔案的 Hash 值利用 Index function 一個一個放入 FBHTree，

我們分別對 1~20 層樹高做了測試。

表 4: FBHTree 各個樹高的比較

Tree Height Cost Time(s) Size(MB)

1 522.621 147.6 建立的時間並不會比 Integrity checking 的方法多出太多，在樹高層數低的 FBHTree，

因為碰撞數非常大，所以會花費比較多一點的時間在新增的 PB-pair 串接上，而 在層數高的 FBHTree，雖然碰撞數低，但是因為節點數量非常多，在建立 FBHTree 的結構的時間會比較多。

在容量大小上，因為 HashMap 以及 FBHTree 在檔案名稱儲存的是檔案的絕 對路徑，而 Merkle Tree 在檔案名稱的儲存上只需要儲存檔名，雖然 Merkle Tree

24

的方法當中多了 14 萬個資料夾名稱和 Hash 值的儲存，但是檔案數量大於資料夾 數量非常多，所以儲存的字串相較起來 HashMap 以及 FBHTree 所儲存的字串長 度還是比較大，所以在容量上 Merkle Tree 會小非常多。在容量上，雖然 FBHTree 的容量比 HashMap 的還要大，但是如果使用我們方法，用戶只需要儲存一個

32byte 的 Root hash 值，大幅減少用戶儲存上的負擔。

表 5 為 Integrity checking 的方法稽核和更新一個檔案所需的時間，Audit 我 們利用 java.Util.HashMap 中的 Method：get()來取得每個檔案的 Hash 值並且跟 VM 上 的 Library 檔 案 Hash 值 比 對 ， 速 度 是 非 常 快 的 ， Update 則 是 利 用

java.Util.HashMap 中的 Method：put()來將檔案的 Hash 值更新，因為需要置換 Hash 值所以時間上會比較慢一些。然而 HashMap 的方法，是無法做到 Proof of Violation 的。

表 5: Integrity checking 稽核和更新一個檔案所需的時間 Audit time Update time

0.003 0.08

接下來是 Merkle Tree 稽核和更新一個檔案所需時間，如表 6，Audit 是將所 需要用到的檔案利用 Partial Merkle Tree 方法計算出 Root hash 跟另外保存的 Root hash 做比對，Update 也是利用 Partial Merkle Tree 的方法更新檔案的 Hash 值。

表 6: Merkle tree 稽核和更新一個檔案所需時間 Audit time Update time

6.83 18.51

在 Merkle tree 的方法中需要串聯許多同一層的檔案以及資料夾 Hash 值，再 將這些串聯起來的 Hash 值取一次 Hash，所以花非常多的時間。但是在 Merkle tree

的方法中我們是可以達成 Proof of Violation 的。

接下來的實驗，我們用了幾個在 Mac 上面的常見應用程式來做測試，在程式 執行時都會呼叫動態函式庫，我們分別對 LINE、Mail、FaceTime、Pages 這幾個 應用程式做了測試。

首 先 ， 我 們 以 LINE 來 做 範 例 說 明 ， 在 terminal 中 進 入 應 用 程 式

LINE.app/Contents/MacOS 的資料夾以後，輸入指令”otool –L LINE”，就可以找到 LINE 在執行程式時會需要用到的動態函式庫。表中為對這幾個應用程式所需要 用 到 的 動 態 函 式 庫 檔 案 做 稽 核 的 時 間 。 Integrity checking 的 方 法 我 們 使 用

java.Util.HashMap 中的 Method:getValue()來找出儲存起來的 HashMap 中檔案的 Hash 值，並且跟函式庫中的檔案計算 Hash 後做比對。而 Merkle Tree 代表改良過 後的 partial Merkle Tree 的方法，將所需要的檔案 partial 重新做一次 Hash 計算得 出 Root Hash 以後跟所保存的 Root Hash 做比對。FBHTree 的方法為將 FBHTree 中對應檔案的 Slice 找出來後推導 Root Hash 後，在將其與保存的 Root Hash 做比 對。在 FBHTree 的實作上我們分別列出了偶數層數的樹高的 FBHTree 來做觀察，

而三個方法我們分別都做了 500 次然後取其平均值。

表 7、表 8、表 9、表 10 中我們可以看到，Merkle tree 的方法非常費時，

是因為當同一層的檔案或者資料夾數量非常多的時候，在串連這些資料夾或者檔 案的 Hash 值就會花費非常多的時間，所以在這樣的情況下會比我們所提出的方 法來的耗時。當我們的 FBHTree 建立在樹高 10 之後，我們所提出的 FBHTree 方

26

法稽核的時間都是非常接近的，從數據上我們可以看出，在 70 萬個檔案的情況 下，我們將 FBHTree 的樹高設定超過 16 時，稽核速度會是較佳的，而且稽核速 度會跟 Integrity checking 的作法非常接近。

表 7: Integrity checking、<Key,Value>+POV、Merkle Tree 應用程式檢測時間（ms）

Application FaceTime LINE Pages Mail

只取 Hash 2214 1241 3283 3059

Integrity checking 2214.03 1241.02 3283.03 3059.03

<Key, Value>+POV 13251.24 5839.72 8985.14 10701.81 Merkle Tree 2631.32 1600.37 3986.86 3586.14

表 8:FBHTree 的應用程式檢測時間(單位:ms)

Application

Tree Height

FaceTime LINE Pages Mail 表 9: Integrity checking、<Key,Value>+POV、Merkle Tree 應用程式檢測時間 2

Application Maps(ms) Calender(ms) Preview(ms) Photos(ms)

只取 Hash 767 1069 703 2481

Integrity checking 767.02 1069.02 703.02 2481.03

<Key,Value>+POV 7089.80 9146.04 6577.50 13990.68 Merkle Tree 1671.14 1960.27 1623.95 5923.20

表 10: FBHTree 的應用程式檢測時間 2(單位:ms)

Application

Tree Height

Maps Calender Preview Photos

2 3932.06 4984.24 3498.27 8308.38 4 1590.14 2081.20 1441.42 4031.62 6 1008.40 1368.88 919.38 2922.44 8 847.26 1166.02 778.95 2626.08 10 784.00 1089.58 730.28 2515.72 12 772.44 1077.40 709.20 2490.30 14 769.72 1073.20 709.20 2487.20 16 770.40 1070.26 704.86 2488.44 18 769.04 1072.36 704.55 2485.96 20 769.72 1071.94 705.48 2485.96

雖然在稽核時間上，我們的方法會比 Integrity checking 的方法慢了一些，但 是我們的方法也大幅的減少用戶在儲存這些用來稽核的 Hash 值的空間成本，而 且我們的方法可以是達到 POV 的成效，而 Integrity checking 並沒有辦法達成

POV。

28