實驗結果

我們以醫療資料庫中的處方籤表單(Prescription)為例，選取一個整數型態(INT)和三 個文字型態(TEXT)的欄位，分別是：處方籤編號(Pr_Id, INT)、病患編號(Pid, TEXT)、病 患姓名(Patient_Name, TEXT)和藥名(Drug_Name, TEXT)四個欄位的資料來驗證我們的 完整性檢測機制。

 新增資料：

 圖十三：透過代理伺服器連入 MySQL，新增處方籤表單的資料。

 圖十四：代理伺服器的訊息，改寫插入的操作指令：原操作指令中的每個欄位，

除了 CryptDB 洋蔥加密法擴增的欄位以外，也另外新增了存放完整性標籤的欄 位(IC_tag_XXX)；對應的插入值也有系統自動計算的完整性標籤值。

圖 十三、終端機介面-新增資料

圖 十四、終端機介面-計算完整性標籤

34

 查詢資料：

 圖十五：透過代理伺服器連上 MySQL，查詢處方籤表單中的處方籤編號、病 患編號、病患姓名和藥名（依序由左至右），可以成功解密得到資料回傳。

 圖十六：不透過代理伺服器，直接連入 MySQL，可以看到處方籤表單和其欄 位均以匿名呈現。

圖 十五、終端機介面-查詢資料，解密得明文

35

 圖十七：依照建立表單時的欄位順序計算出處方籤編號、病患姓名和藥名欄位 的匿名，並嘗試查詢欄位資料，得到密文。

圖 十六、終端機介面-表單匿名結構

圖 十七、終端機介面-查詢密文資料

36

 圖十八：修改藥名欄位的第二筆資料。

 圖十九：修改處方籤編號的第三筆資料

圖 十八、終端機介面-竄改密文資料(text)

圖 十九、終端機介面-竄改密文資料(int)

37

 圖二十：竄改密文資料後，透過代理伺服器連入 MySQL，查詢處方籤表單中 的處方籤編號、病患編號、病患姓名和藥名，發生解密錯誤。

 圖二十一：自代理伺服器的訊息，得到竄改後的密文並沒辦法通過 RND 層的 解密（密文格式不符）。

 圖二十二：透過代理伺服器連入 MySQL，利用 CryptDB 提供指令剝除藥名欄 位的 RND 層得到 DET 層密文。

圖 二十、終端機介面-解密失敗

圖 二十一、終端機介面-系統偵測密文格式不符

圖 二十二、終端機介面-調整洋蔥加密法加密結構(至 DET 層)

38

 圖二十三：再一次透過代理伺服器連入 MySQL，查詢處方籤表單中的處方籤 編號、病患編號、病患姓名和藥名；觀察代理伺服器的訊息：未遭竄改的欄位 可以通過驗證，遭到竄改的欄位則無法通過驗證。

 圖二十四：獨立來看這筆密文資料是剛剛竄改的處方籤編號欄位第三筆資料。

圖 二十三、終端機介面-完整性檢測 DET 層密文資料

圖 二十四、終端機介面-遭竄改的 DET 層密文資料無法通過完整性檢測

39

 圖二十五：查詢之後回傳之後的訊息，通過完整性檢測的資料會解密，反之則 會呈現完整性檢測失敗的警告。

 圖二十六：改以條件查詢處方籤表單中的處方籤編號、病患編號、病患姓名和 藥名，設定篩選條件是處方籤編號小於 5 的資料；仍然可以驗證我們的完整性 檢測機制。

圖 二十五、終端機介面-查詢資料，發送警訊通知使用者資料未通過完整性檢測

圖 二十六、終端機介面-條件查詢資料，發送警訊通知使用者資料未通過完整性檢測

40