• 沒有找到結果。

CAP 之選擇

在文檔中 雲端聯盟之違約證明 (頁 20-32)

第四章 改良證明違約協定應用於雲端醫療系統

第二節 CAP 之選擇

在前敘述 CAP 中 C&L Scheme[10]可以解決 CloudProof[8]這個問題,利用 鏈結雜湊搭配 LSN(Local Sequence Number),使用者名稱(ClientID),以及時

代識別名稱(Epoch ID),加入證據中,不只可以確保雙方的不可否認性,在

LSN 的協助下,也可成功抵禦回復式攻擊。並在原本的架構上加入 TTP 的存 在,可以解決當使用者不在線上無法稽核之問題。

雖然乍看之下證明違約協定加上 TTP,可解決雲端聯盟上安全性之問題,

但首先若是遇到惡意的使用者或是網路傳輸上的問題產生慢速攻擊,無法抵

擋。其次在 C&L Scheme[10]上本身有一項很大的限制,為了確保執行的結果不

會被服務提供者竄改、否認,C&L Scheme 必須在鏈結雜湊內加入當次請求的

執行結果,這對雲端聯盟的操作上是一大限制。在某些應用上其系統特性,剛

好不會產生問題,例如:雲端儲存系統,因為服務提供者可以快速的找出請求

檔案並計算出雜湊值當成執行結果,包在證據內,但在醫療系統上,我們並無

法提前得知此動作之雜湊值,所以若是採取 C&L Scheme[10]會造成動作無法平

行處理,必須等到前面使用者完成動作,才能繼續動作。最後因為在醫療系統

上的特殊性,不能發生問題才發動稽核,這樣會使得病人權益受損,產生不可

挽回之後果,所以這部分必需採取即時稽核機制。

基於上述三個理由,必須修改原本 C&L Scheme[10],改採取四步驟雙重鏈 結雜湊(Four-Step Double Hashes)技術並搭配即時稽核制度來解決上述問題。

14

為了清楚描述此協定,我們先解釋符號代表之意義,[O]pri(x)代表使用者 x 簽署在資料物件 O 上的電子簽章,此簽章是由使用者 x 的私鑰所簽署,若有多

個物件則會以逗號隔開來表示,例如:[O1, O2, O3]pri(x)表示資料物件 O1, O2, O3

被使用者 x 的私鑰所簽署。

我們假設每個使用者都有自己的獨一無二的客戶識別名稱(ClientID), 接下來介紹此方法的步驟:

Step1:當使用者要對服務提供者提出請求時,會傳送一個請求訊息(Request

Message)Qi給服務提供者,Qi=(OPi, ClientID, ClientLSN, [OPi,

ClientID, ClientLSN]pri(U))其中 OPi為這次動作,例如寫入病歷、讀取病 歷,其中還包含 PatientID、CloudName,PatientID 為這次要對其動作之

擁有者 ID,CloudName 為目前使用者所屬之服務提供者,ClientID 為這

次提出請求之使用者 ID,ClientLSN 為使用者本身第幾次的動作。

Step2:當服務提供者收到使用者的請求 Qi後,先驗證 Qi的電子簽章是否正確,

若無效則拒絕此次請求,有效則將系統上一個動作的回應給 Ri-1取雜湊

後與使用者上一個動作的承認訊息(Acknowledgment Message)取雜湊

後放入此動作 Ri中回傳給使用者,其中 Ri=(Qi, hash(ACKj), hash(Ri-1),

[Qi, hash(ACKj), hash(Ri-1)] pri(provider)),其中 hash(ACKj)為同個使用者上一 個動作的 ACK,hash(Ri-1)是整個系統上個動作的 ACK。

Step3:當使用者收到服務提供者的回應 Ri後,也必需驗證服務提供者電子簽章

15

是否正確,再以 PatientID 向 TTP 索取最後一筆證據。

Step4:比對服務提供者與 TTP 的證據是否相同,若是相同則回傳 RRi給服務提 供者,其中 RRi=(Ri, [Ri]pri(U))。

Step5:當服務提供者收到 RRi後便開始執行 Qi所要求執行的指令,執行完後,

服務提供者傳送 ACKi給使用者,ACKi=(Li, RRi, [RRi]pri(provider))其中 Li

為執行結果。

Step6:使用者收到 ACKi後,將 ACKi上傳到 TTP,TTP 收到後將原本的證據更 新為新的證據後回傳回條給使用者,完成這次動作。

我們在這裡每個證據透過兩條雜湊鏈結,一條是鏈結到自己上一個動作,

另外一條是鏈結到整個系統的上一個動作,有了這兩條鏈結,我們可以證明,

服務提供者就無法竄改已經連結的證據,包含 ACK 的改變順序、移除 ACK、

或是變更執行內容,也可避免慢速攻擊。

在整個過程中使用者只需要維護自己的 ClientID 以及最後一筆 ACK,在完 成動作後上傳到 TTP。

根據上述的步驟,我們把詳細過程套用到整個醫療架構下。使用者利用病 人 ID 向 TTP 請求病人相關證據,TTP 收到請求後,會傳回有關這位病人之所

有使用者簽署的相關證據,收到 TTP 傳回之證據後,使用者蒐集相關服務提供

者上面的相關動作、病歷資料,然後發動稽核讀取相關病歷,確認是否正確,

若是正確無誤後,再執行這次診斷的動作,診斷完成後,利用 4 步驟的交握式

16

上傳到服務提供者上,完成動作後,服務提供者回傳 ACK 給使用者,使用者

收到服務提供者所回傳 ACK 後,再將 ACK 上傳至 TTP,TTP 收到使用者的 ACK 後回傳“回條”給使用者,使用者手中保留回條。將動作以下圖 3 來表達。

1

Client Service Providers 1.利用病人ID向TTP請求相關證據

PatientID, [Opi, ClientID, PatientID] pri(client))給 TTP,TTP 收到後回傳 Ri=(Qi,

PatientData, [Qi, PatientData] pri(TTP))給使用者。使用者上傳 ACK 給 TTP 也是採 取兩步驟動作,將 ACK 以 Q 的方式傳給 TTP 內容如 Qi=(ACKi,

[ACKi]pri(client)),TTP 收到後回傳 Ri=(Hash(Qi,CHi-1), [Hash(Qi,CHi-1)] pri(TTP)) )給使 用者,使用者手中握有 TTP 回傳之回條,便可證明自己有將 ACK 傳送給

17

TTP,不用擔心 TTP 否認。

使用者上傳給服務提供者之內容。我們是採取四步驟動作,由使用者發

Qi,Qi=(Opi, ClientID, ClientLSN, [Opi, ClientID, ClientLSN]pri(client)),其中 Op 裡 面包含 PatientID、CloudName 服務提供者收到後回傳 Ri=(Qi, hash(ACKj),

CloudA CloudB CloudC

圖 4 證據分散在不同 Cloud 上

這時會產生一個問題,當服務提供者 B,將存在的證據刪除,則會導致一個問

18

題產生,就是服務提供者 C 會不知道上一個動作是在哪裡完成的,如圖 5

IH C1 C2 C1

C3 C3 C4

C5 C6 C6

C1

CloudA CloudB CloudC

圖 5 當 CloudB刪除保存之證據

在這裡先利用一個比較直覺的解法,我們當要轉換服務提供者時,應該將原本

舊的服務提供者上的最後一筆證據,複製一份至新的服務提供者,如圖 6。

19

CloudA CloudB CloudC

C6

20

CloudA CloudB CloudC

C6

21

詢問過的服務提供者,則會承認他是最後一個提供服務的。

Step5:詢問到最後一筆動作之服務提供者後,開始動作之前我們需要先請求連 結,先將證據連結到上一個服務提供者,完成連結後,開始稽核。

Step6:稽核無誤後,再開始此次動作,動作完成後,將證據串接在連結的證據後 面。

我們以上述例子來看,使用者先跟 TTP 要求所有使用者上傳至 TTP 關於病

人的最後一筆證據,在 CloudB,C4動作前我們先詢問 CloudA,是否上一筆動作

是在 CloudA上完成,若是成立,則下一次當 CloudC再向 CloudA詢問時,因為

CloudA已經被詢問過了,便可知道 CloudA不是上次動作的 Cloud,便可避免

CloudC惡意的串接到 CloudA後。為了區別詢問的證據,我們將其命名為連接證 據(Connection Attestation),CAi=(HashPath, CloudName, PatientID, [HashPath,

CloudName, PatientID]pri(cloud))。我們以圖 8 表示。

22

CloudA CloudB CloudC

CA6

CA1 CA4

圖 8 將證據以詢問的方式連結

最後我們假設一種情形,Cloud 皆是不可信任的,舉例來說,當 CloudB發 生誤診的情形想要把資料覆蓋,則 CloudA與 CloudC勾串,將最後一筆詢答的

Connection Attestation 連接給 CloudC,這時若要稽核,則一樣會產生上述的問 題。

23

相關的證據,利用 TTP 接收到證據的時間來像 Cloud 詢問是否為最後一個

Cloud,確認最後動作之 Cloud 後,便可向 Cloud 請求連結。因為我們是採取每 筆動作都要稽核,所以如果 Cloud 故意將其證據刪除或是串接錯誤,在第一時

間我們便可以發現在 TTP 上面的證據與最後一個動作的 Cloud 上證據有出入,

那我們便可即時發現 Cloud 有問題。

這時我們發現一個問題,假設在使用者還未上傳證據的時候,下一個使用

者就去動作,這時候我們會發現詢問不到最後一筆證據的情況產生。因為這時

候向 TTP 詢問到的最新上傳證據使用者的 Cloud,已經被上一次動作還未寫入

的使用者詢問過,這時候我們必須用廣播才能知道最後一個動作。這種情形並

不常見,因為必須在使用者動作完成後,還沒上傳至 TTP 的時間內,病人到其

他 Cloud 動作才會產生此情形。這時候,我們必須利用廣播的方式來詢問,哪

一個是最後動作的 Cloud。確認最後動作後,有兩種方式處理,等待最後動作

使用者上傳證據後再動作,或者是串接在使用者的前一個動作後面,等到使用

者完成動作後再轉串到新的 Cloud 下面。例如當 CloudB最後一筆動作還未完

成,病人就到 CloudC上面看診,這時 CloudC必須透過廣播的方式確認 CloudB

為最後動作之 Cloud,則若是選擇要等待其動作完成,則利用上述方法等到

CloudB最後一筆證據串接上去再向 CloudB要求連結。若是選擇採取直接動作,

則向 CloudB請求連結到目前的最後一筆證據後面,進行動作,等到 CloudB

使用者動作完成後,再將動作串接到 CloudC下。這樣便可確保整體的順序性可

24

以被追蹤,如圖 9。

IH C1 C2 C1

C5 C6 C6

CloudA CloudB CloudC

C3

CA1 CA1

圖 9 將證據改串接到 Cloudc

25

在文檔中 雲端聯盟之違約證明 (頁 20-32)

相關文件