第四章 改良的證明違約協定應用於雲端資料庫實作
第一節 證據的產生
本章節將敘述如何實作改良後的證明違約協定於雲端資料庫上,為了使用 此協定將先解釋部分符號意義,[O]pri(x)表示使用者 x 簽署在資料物件(Data
object)O 上的電子簽章,此簽章是由使用者 x 自己的私有鑰匙所簽署,此外在中 括號內,多個資料物件會以逗號隔開,表示多個物件資料被使用者 x 簽署,如
例子[O1, O2, O3]pri(x)表示資料物件 O1、O2和 O3被使用者 x 的私有鑰匙所簽署。
考量一個實際的案例,一個雲端資料庫由一個申請該服務的使用者 U 擁 有,該使用者可為這個資料庫的存取增添客戶,每個客戶依據各自的權限能對 不同的資料表進行存取,我們假設每個客戶端裝置都擁有使用者 U 用來存取雲 端資料庫服務的私有鑰匙,並且由服務提供者得到一個獨一無二的客戶識別名 稱(ClientID)與時代識別明稱(EpochID),其中時代識別名稱表示一段時間世代,
不同的使用者帳戶會有不同的時代識別名稱,當所有證據都被稽核完畢要進入 下一個時代時,這些證據都不需要在保存而會被丟棄。
Service Provider
ClientA
User U‘s database ClientB User U’s account
ClientC
ACK1, ClientA ACK2, ClientB ACK3, ClientA ACK4, ClientC ACK5, ClientC
ACK1
ACK5 ACK4 ACK3
ACK2
圖 四-1 Four-Step-DH 服務提供者與客戶端裝置保留承認訊息 參考圖 四-1,服務提供者必須保留相同使用者帳戶下所有客戶識別名稱與 其每個操作的承認訊息(acknowledgment message),一個客戶端裝置需要保留它 自己的客戶識別名稱以及對應的最後一次操作的承認訊息,這個方法採取將雙 重鏈結雜湊嵌入在彼此交換的訊息中確保資料完整性與操作的正確性,留有這 些經過電子簽章簽署的訊息得以確保不可否認性。這個方法稱作
Four-Step-DH(Four-step handshake protocols with double chained hashes),如圖 四-2 總共有 13 個步驟以下將詳述每個步驟所做的事:
1. send Request
2. receive Request
4. send Response
6. receive Response
8. send RR
9. receive RR
11. send ACKi 10. do Operation
13. receive ACKi
Service Provider Client Device
7. check epochID, ClientID
12. ACKlatest(ClientID, DB)= ACKi Semaphore(DB(Tablei)).acquire
Semaphore(DB(Tablei)).release
3. chaining hash(Ri-1) & hash(ACKj) Qi
Ri
RRi
ACKi
5. Rmain(DB) = Ri
8.1. upload data
13.1. download ACK Result
圖 四-2 雲端資料庫使用 Four-Step-DH 架構流程圖 回應訊息(response message)Ri-1取雜湊與客戶端裝置上一個操作的承認訊
息(acknowledgment message) ACKj取雜湊後放入此次操作 Ri。
Step 4: 最 後 傳 送 回 應 訊 息 Ri 給 客 戶 端 裝 置 , Ri=(Qi, EpochID, hash(ACKj), hash(Ri–1), [Qi, EpochID, hash(ACKj), hash(Ri–1)]pri(Provider)) 。
Step 5: 記錄此次操作的目標資料庫最後一個操作的回應訊息為此次的 Ri。 Step 6: 客戶端裝置接收服務提供者傳送的回應訊息 Ri。
Step 7: 當客戶端裝置收到服務提供者傳送的回應訊息 Ri後,先驗證 Ri內的電子 簽章與客戶識別名稱還有時代名稱是否有效,再比較 Ri內客戶端裝置上 一個操作的承認訊息雜湊是否與客戶端裝置目前保留的最後一個操作承 認訊息雜湊相同,但此時客戶端裝置無法檢查 Ri是否正確地有和上一個 回應訊息 Ri-1串聯,因為客戶端裝置只有保留最後一個來自服務提供者的 完成動作後所傳送給客戶端裝置的承認訊息 ACKj,其中 j < i 且 j 可能不 等於 j-1。
Step 8: 當檢查完畢後,客戶端裝置傳送回覆回應訊息(reply-response message) RRi
給服務提供者,其中 RRi=(Ri, [Ri]pri(U))。
Step 8.1: 客戶端裝置執行 Qi內 SQL 指令中的檔案上傳。
Step 9: 服務提供者接收驗證回覆回應訊息 RRi。
Step 10: 在服務提供者收到並且驗證回覆回應訊息 RRi 後便開始執行 Qi 內所要 求的 SQL 指令。
Step 11: 服務提供者傳送承認訊息 ACKi,ACKi=( Li, RRi, [Li, RRi]pri(provider)),給
客戶端裝置,其中 Li為 SQL 指令的執行結果雜湊值。
Step 12: 服務提供者記錄客戶端裝置於此次操作的目標資料庫上的最後一個操
作承認訊息為 ACKi。
Step 13: 客戶端裝置接收服務提供者傳送的承認訊息為 ACKi。
Step 13.1: 客戶端裝置從服務提供者下載 SQL 指令的執行結果 Li。