第三章 即時稽核架構
第一節 Index Merkle Tree
1.3 稽核細節
當用戶向雲端服務提供者提出query 請求前，需先向同步伺服器拿取最新的 Root hash，query 請求後，服務提供者需產生 Condition 資料相符的 Slice 資訊，
如圖9。回傳 Slice 與 query 結果後，用戶須先使用 query 的結果取 Hash，接著使 用 Slice 回推 Root Hash，如圖 10，如果獲得的結果與在同步伺服器的內容相符 的話，稽核成功，若失敗，則以服務提供者所回傳的資訊與保存的雙方簽章作為 證據，要求服務提供者進行賠償。
Slice of IMT= Root node | Left Internal node | Right internal node |…| Left PB-pair | Right PB-pair
樹高= 9
:Root Node
:PB-pair :Internal node
Slice
圖 9 Slice 示意圖
(Compare)
A.row1 B.row10 Leaf node ID=166
Root hash
Slice
Client device
圖 10 用 Slice 稽核 1.4 Range Selection
在使用資料庫時，我們常常會對雲端資料庫查詢一個範圍的資料，例如 20000<Salary<50000，這種條件查詢我們稱為 Range Selection，服務提供者可能
會少回傳資料，假設今天我們對資料庫所下的查詢指令為 SELECT * FROM
`company` WHERE `Salary`<50000 AND `Salary`>20000，且查詢的正確結果如
圖 10，而服務提供者試圖少給查詢結果的 Row3，只回傳 Row1、Row2、Row4 的資料以及它們的Slices，若只利用 row hash 驗證，則無法檢查出少了資料，所 以在葉節點的value 中，額外儲存了前後兩筆 row hash，在 Range Selection 的動 作中，用戶要要求服務提供者額外回傳前後兩筆row 的資料，這樣就可以檢查服 務提供者是否有少給資料。
Salary Name … Row1 25000 Jerry … Row2 30000 Paul … Row3 40000 Hank … Row4 45000 Jack …
圖 11 資料庫查詢結果 1.5 問題
使用Index Merkle Tree 的方法進行稽核，在各方面的表現幾乎都勝過 B+ Tree，
唯有範圍查找的稽核速度較差，在大量資料的新增、修改、刪除方面均有進步的 空間，因此而有了下一個方法Aggregate Hash。
第二節 Aggregate Hash
2.1 資料結構
在這一節中，將會介紹實驗室的研究成果 Aggregate Hash，Aggregate Hash 是利用數學中的同餘(modulo)[14]來產生密碼學證據，需要宣告一個大質數 P 與
一個固定長度的一維陣列並將陣列中的值設為1，接著使用一個 Index function Γ 計算來得到其該存放到陣列中的哪個位置，此Index function Γ 如下。
𝚪(𝐂𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧) = 𝐒𝐇𝐀𝟐𝟓𝟔(𝐂𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧) 𝐦𝐨𝐝 𝐀𝐫𝐫𝐚𝐲𝐒𝐢𝐳𝐞
其中 Condition 為使用者查詢資料時經常使用的欄位條件，例如 id=10、
22000<Salary<50000 等。定位後將那一筆 row 的證據儲存在該位置，陣列是利用 (key, value)的方式儲存，儲存格式如下。
𝐱 = 𝚪(𝐂𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧) 𝐤𝐞𝐲 = 𝐂𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧
𝐯𝐚𝐥𝐮𝐞 = [𝐡(𝐫𝐨𝐰𝐡𝐚𝐬𝐡(𝐱)), 𝐡(𝐫𝐨𝐰𝐡𝐚𝐬𝐡(𝐱 − 𝟏)), 𝐡(𝐫𝐨𝐰𝐡𝐚𝐬𝐡(𝐱 + 𝟏))]
儲存後需要將陣列中的每一個slot都計算出一個證據，其證據的計算方式如
下。
𝐀𝐫𝐫𝐚𝐲[𝐱] = 𝟏 × 𝐡(𝐯𝐚𝐥𝐮𝐞𝟏) × 𝐡(𝐯𝐚𝐥𝐮𝐞𝟐) × … × 𝐡(𝐯𝐚𝐥𝐮𝐞𝐧) 𝐦𝐨𝐝 𝐏
用戶必須要保存整個陣列用來稽核，當每一個slot都計算完之後，將這些證
據結合成一個證據，其計算方式如下。
𝐀𝐇 = 𝐀𝐫𝐫𝐚𝐲[𝟎] × 𝐀𝐫𝐫𝐚𝐲[𝟏] × … × 𝐀𝐫𝐫𝐚𝐲[𝐧] 𝐦𝐨𝐝 𝐏
這個AH值可以拿來對雲端資料庫作稽核的一個依據，AH還要交由雙方進行 簽章並互相保存以支援POV。
2.2 SQL 指令結果之稽核流程
在即時稽核架構中，分別有同步伺服器、用戶端裝置、雲端服務提供者三個 角色，我們將介紹在每一個SQL 指令中，稽核的詳細流程。
Select operation:
Step1: 用戶端向同步伺服器拿最新的 AH 及作為證據的 Array
Step2: 用戶端向雲端資料庫發出 Select operation 請求
Step3: 服務提供者將 Select operation 結果及對應 slot 的內容取出 Step4: 服務提供者回傳 Select operation 結果及對應 slot 的內容 Step5: 用戶端透過 Select operation 結果及對應 slot 的內容稽核 Step6: 用戶端稽核完成，告知服務提供者
Insert operation:
Step1: 用戶端向同步伺服器拿最新的 AH 及作為證據的 Array Step2: 用戶端向雲端資料庫發出 Insert operation 請求
Step3: 服務提供者將 Insert operation 結果及對應 slot 的內容取出並計算新的 AH
Step4: 服務提供者回傳 Insert operation 結果、對應 slot 的內容、新的 AH 及
針對AH 所作簽章
Step5: 用戶端稽核舊的資料並更新 AH
Step6: 用戶端更新完成，回傳新的 AH 及雙方簽章給服務提供者及同步伺服
器
Delete operation:
Step1: 用戶端向同步伺服器拿最新的 AH 及作為證據的 Array Step2: 用戶端向雲端資料庫發出 Delete operation 請求
Step3: 服務提供者將 Delete operation 結果及對應 slot 的內容取出並計算新
的AH
Step4: 服務提供者回傳 Delete operation 結果、對應 slot 的內容、新的 AH 及
針對AH 所作簽章
Step5: 用戶端稽核舊的資料並更新 AH
Step6: 用戶端更新完成，回傳新的 AH 及雙方簽章給服務提供者及同步伺服
器
Update operation:
Step1: 用戶端向同步伺服器拿最新的 AH 及作為證據的 Array Step2: 用戶端向雲端資料庫發出 Update operation 請求
Step3: 服務提供者將 Update operation 結果及對應 slot 的內容取出並計算新
的AH
Step4: 服務提供者回傳 Update operation 結果、對應 slot 的內容、新的 AH
及針對AH 所作簽章
Step5: 用戶端稽核舊的資料並更新 AH
Step6: 用戶端更新完成，回傳新的 AH 及雙方簽章給服務提供者及同步伺服
器
2.3 稽核細節
當用戶向雲端服務提供者提出query 請求前，需先向同步伺服器拿取最新的 AH 及作為證據的 Array，query 請求後，服務提供者需利用 Condition 來進行定
位slot，取出與其相同 slot 的內容。回傳該 slot 內容與 query 結果後，用戶須先 使用query 的結果取 hash 比對 row hash，接著與其他內容回推該 slot 的值，如果 獲得的結果與在同步伺服器的內容相符的話，稽核成功，若失敗，則以服務提供 者所回傳的資訊與保存的雙方簽章作為證據，要求服務提供者進行賠償。
2.4 Range Selection
與IMT 相同，若只利用 slot hash 驗證，則無法檢查出少了資料，所以在 slot 的value 中，額外儲存了前後兩筆 row hash，在 Range Selection 的動作中，用戶
要要求服務提供者額外回傳前後兩筆 row 的資料，這樣就可以檢查服務提供者
是否有少給資料。
第四章 相關實驗數據
在第三章，我們做了一系列的實驗，來證明本論文提出方法之可行性。我們 使 用 JAVA 來 實 作 我 們 的 即 時 稽 核 架 構 ， 以 及 digest function 為 java.security.MessageDigest 中的 SHA-256 algorithm，我們使用兩台電腦來作實
驗，服務提供者與用戶端的電腦作業系統為 Windows 10，處理器為 Intel(R) Core(TM) i5-7500CPU @3.40GHz ， 記 憶 體 為 8GB 。 資 料 庫 系 統 我 們 使 用 MySQL5.7.18，資料庫系統的連接與操作使用 JDBC(Java Database Connectivity)
來模擬資料庫實體的連接與 SQL 指令的執行，我們在資料庫當中建立了一個一
百萬筆資料的Table 作為實驗對象，每筆 row 最大為 3.2KB，Table 大小為 2.37GB。
第一節 B+ Tree 相關數據
設定B+ Tree 的 max degree = 5 來進行實驗。
第一段 定位問題
第二章中所提到的第一個問題就是定位問題，因為B+ Tree 中的葉節點是依 照順序擺放至二元樹的葉節點，所以在B+ Tree 查找完資料後，需要先計算該葉 節點是第幾個葉節點，才能在二元樹中找到對應的資料，以下表格為實驗最久的 定位時間，B+ Tree 的 max degree = 5，由表 1 可以看出，B+ Tree 層數越高，所 需要的定位時間越大。
表 1 B+ Tree 不同樹高的平均定位時間
B+ Tree 層數 葉節點數量 平均定位時間(ms)
5 625 0.002
6 3,125 0.006
7 15,625 0.046
8 78,125 0.175
9 390,625 1.454
10 1,953,125 8.019
11 9,765,625 13.146
第二段 分裂問題
在資料庫中，新增刪除是常常會用到的動作，套用到B+ Tree 中，新增刪除 會造成分裂的問題，一旦發生分裂，大部分的二元樹都要重新計算值，以下表格
為實驗分裂時所需要重建二元樹的時間，由表2 可以發現，越高層樹所需要重建
的時間就越久，因此才會有子樹的方法出現。
表 2 B+ Tree 不同樹高重建二元樹所需時間
B+ Tree 層數 重建二元樹所需時間(ms)
5 0.51
6 3.438
7 7.528
8 19.008
9 66.368
10 312.575
11 575.854
第三段 過度集中問題
使用子樹的方法後，解決了本節前兩個問題，但是卻造成了另一個問題，也 就是當資料過度集中時，會造成樹的結構被拉長，以下表格為實驗當資料集中於 某個區段塞入B+ Tree 時所造成的問題，從表 3 可以看出因為子樹在低層數時無 法塞入大量資料，所以會將結構拉得很長，造成稽核和重建樹的時間需要更多的 時間。
表 3 B+ Tree 資料過度集中問題
子樹限高 子樹資料量 所需層數 稽核時間
(ms)
重建樹時間 (ms)
5 <2500 >400 34 37
6 <12500 >80 6 11
7 <62500 >16 2 9
但是這個問題只有在刻意將資料往某個區段放入才會出現，若是用隨機的方 式將一百萬筆資料放入的話結果應該如下表。
表 4 B+ Tree 子數平均層數
子樹限高 最高層數 最低層數
3 12 4
4 6 3
5 4 2
6 3 2
7 3 2
8 2 1
9 1 1
第四段 B+ Tree 稽核
這一段將會呈現B+ Tree 用在即時稽核的所有實驗結果，會分為三個表格來 呈現，表5 為本機測試，不包含網路傳輸，表 6 為同網路區段的實驗數據，表 7 為不同網路區段的實驗數據。
表 5 B+ Tree 本機測試數據
100萬筆row subtree max level
(sml)
Sub tree height
Audit(ms) Select a row
Audit(ms) Select 100
rows
0.74 0.83 0.33 0.82 0.36 0.82 0.33
4 0.05 0.68 0.13 0.69 0.14 0.65 0.13
B+ (4 sml) 6 0.09
0.42
0.75 0.24 0.76 0.24 0.74 0.24
3 0.04 0.67 0.12 0.62 0.12 0.65 0.13
B+ (5 sml) 4 0.09
0.38 0.72 0.24 0.76 0.27 0.71 0.24
2 0.04 0.66 0.11 0.62 0.11 0.62 0.11
B+ (6 sml)
3 0.07
0.35
3.53 0.17 3.55 0.17 3.51 0.16
2 0.04 3.52 0.14 3.52 0.15 3.55 0.14
B+ (7 sml) 3 0.07
0.35 7.66 0.19 7.62 0.18 7.63 0.19
2 0.06 7.45 0.16 7.41 0.16 7.42 0.15
B+ (8 sml)
2 0.08
0.29 18.9 0.19 18.93 0.18 18.93 0.19
1 0.05 18.88 0.12 18.83 0.12 18.85 0.13
B+ (11 sml)
1 0.23
0.31
575.85 575.85 575.85
1 0.06 0.06 0.06 0.06
表 6 B+ Tree 同網段測試數據
100萬筆row subtree max level
(sml)
Sub tree height
Audit(ms) Select a row
Audit(ms) Select 100
rows
632.36 649.85 633.36
1 5.37 56.57 73.57 57.57
表 7 B+ Tree 不同網段測試數據
100萬筆row subtree max level
(sml)
Sub tree height
Audit(ms) Select a row
Audit(ms) Select 100
rows
25.20 651.00 668.00 652.00
1 24.01 75.21 92.21 76.21 點內的資料相當多的話，會影響到稽核的時間，因此，Index function Γ 如果碰撞
的機率越低，稽核會越有效率，以下表格為實驗隨機值利用 Index function Γ 進 行的碰撞測試，從表8 中可以發現樹高越高，碰撞的機率越低。
表 8 IMT 碰撞測試
樹高 葉節點數 平均碰撞次數 最小碰撞次數 最大碰撞次數
1 1 1000000 1000000 1000000
4 8 125000 124395 125439
6 32 31250 30955 31656
8 128 7812.5 7582 7983
10 512 1953.125 1812 2075
12 2048 488.281 403 559
14 8192 122.070 84 164
16 32768 30.517 9 53
18 131072 7.633 0 24
20 524288 2.24 0 11
21 1048576 1.552 0 9
第二段 不同樹高的記憶體比較 表 9 IMT 不同樹高的記憶體比較
樹高 內節點(MB) 葉節點(MB)
1 0.000031 60.8
4 0.000458 60.8
6 0.0019 60.8
8 0.0077 60.8
10 0.031 61.07
12 0.124 61.5
14 0.49 63.6
16 1.99 71.8
18 7.99 104
20 31.99 233
21 63.99 304
本 實 驗 是 透 過 java.io.ObjectOutputStream 中 的 writeObject 將 建 構 好 的 FBHTree 輸出成一個物件檔儲存在電腦當中，在記憶體空間大小上，當 FBHTree
樹高超過16 以後，會因為葉節點以倍數的增加導致整棵樹所有節點所佔的記憶
體不斷變大，但是在我們的方法下，使用者只需要儲存一個32bytes 的 Root hash 值，大幅減少用戶儲存上的負擔。
第三段 Index Merkle Tree 稽核
這一段將會呈現Index Merkle Tree 用在即時稽核的所有實驗結果，如下表，
從表10 中可以看出隨著樹高的成長，稽核時間越來越短，但是 IMT 超過 20 層 後，時間反而變長了，因為IMT 資料太多，導致讀取變慢，因此後面將使用 20 層來進行比較。
表 10 IMT 不同層數的稽核時間
稽核時間(ms) 稽核時間(ms) 稽核時間(ms) 稽核時間(ms)
樹高 Select a row Insert a row Delete a row Update a row 1 295.66 881.55 884.46 891.48 4 39.72 118.17 118.98 120.87
6 10.92 33.15 32.52 32.19
8 2.81 8.42 8.49 8.43
10 0.76 2.25 2.31 2.28
12 0.25 0.78 0.75 0.75
14 0.13 0.45 0.39 0.39
16 0.12 0.36 0.33 0.31
18 0.13 0.42 0.33 0.33
20 0.13 0.39 0.33 0.36
21 0.14 0.39 0.49 0.42
第三節 Aggregate Hash 相關數據
第一段 Index function Γ 的碰撞測試 此實驗結果如同IMT，所以在此段就不再重複。
第二段 Aggregate Hash 稽核
這一段將會呈現Aggregate Hash 用在即時稽核的所有實驗結果，如下表，從
表 11 中可以看出 Slot 數量越多，稽核的時間明顯降低，之後將使用2 9個 Slots 來與其他作法進行比較，選2 9個 Slots 的原因是與 20 層 IMT 的葉節點數量相 同。
表 11 Aggregate Hash 不同 slot 數的稽核時間
表 11 Aggregate Hash 不同 slot 數的稽核時間