雲端聯盟之違約證明

全文

(1)國立臺灣師範大學資訊工程研究所碩士論文. 指導教授：黃冠寰. 博士. 雲端聯盟之違約證明. Proof of Violation for Cloud Federation. 研究生：中華民國. 陳之中一零五. 撰年. 八. 月.

(2) 摘要. 雲端聯盟之證明違約陳之中雲端聯盟（Cloud Federation）是聯合兩個或兩個以上服務提供者（Service Provider）組成之聯盟，在相同聯盟內的服務提供者會對其他服務提供者提出服務的請求，由所有提供服務之服務提供者以及使用者所組成之聯盟。當使用者（Client）對服務提供者提出服務請求時，服務提供者會對其請求提供服務。根據使用者提出之服務請求，若無法完成，則轉發給其他服務提供者，由同個聯盟下其他的服務提供者，提供相對應之資料或服務，使用者僅需對單一服務提供者提出服務請求，不需要對應到其他服務提供者。傳統上使用者對服務提供者提出請求，服務提供者會保留日誌檔，來記錄服務的過程，但日誌檔是不安全的。日誌檔的產生沒有經過密碼學的保護，也沒有雙方的確認，可能會遭受服務提供者竄改，使用者無法驗證日誌檔的正確性。當使用者提出服務請求，服務提供者將請求轉發給其他服務提供者，使用者無法得知服務提供者與其他服務提供者溝通之記錄，若發生問題則使用者無法得知是哪個環節出現問題，服務提供者無法提出可信的證明，來證明自己是正確的。為了要證明違約，我們定義一個協定來規範服務提供者及使用者，我們稱為加密問責協定（Cryptographic Accountability Protocols），在本文中我們簡稱為 i.

(3) CAP。我們要求服務提供者要保留每次的動作並留下雙方不可否認的證據，使用者需要留下最後一筆與服務提供者溝通的證據。若發生問題，可利用使用者手中證據來稽核[1]服務提供者，來確保整個系統的正確性。我們先利用舊有的證明違約技術來實作[10]，在實作的過程中會產生無法稽核的情況及將證明違約技術應用於雲端聯盟上會產生新的問題，我們提出新的架構應用於雲端聯盟上，來解決遇到的問題。. 關鍵字：雲端聯盟、違約證明、即時稽核. ii.

(4) 誌謝感謝黃冠寰老師兩年來的教導，每次的 Meeting 討論，從開始看論文，討論題目，發現問題，到解決問題的過程，都一步一步的詳細記錄下來。討論時，常常都能有新的想法，再更一步的討論，了解問題的核心，要如何解決問題，在討論的過程中也會讓教導我做研究的態度以及方法，不斷的引導，修正我犯的錯誤，才能有這最後的成果。另外感謝研究室的學長姐的指導，還有同學們大家一起討論。我們一起修的課、一起寫作業、一起面對考試，都是非常難忘的回憶。讓我在這兩年學生的生活充滿歡笑。最後感謝我的父母、家人以及女友筱雯，因為有你們這兩年的支持才能讓我能順利的走完這兩年。讓我可以順利的完成碩士的學位。. 陳之中誌於國立臺灣師範大學資訊工程研究所中華民國一零五年八月. iii.

(5) 目錄第一章緒論............................................................................................................ 1 第一節雲端聯盟上的安全性議題................................................................ 1 第二節情境.................................................................................................... 2 第三節研究目的............................................................................................ 3 第四節論文大綱............................................................................................ 4 第二章證明違約.................................................................................................... 5 第三章 CAP 應用於雲端聯盟 ............................................................................... 8 第一節系統架構............................................................................................ 8 第二節產生的問題...................................................................................................... 9 第四章改良證明違約協定應用於雲端醫療系統.............................................. 11 第一節系統架構.......................................................................................... 11 第二節 CAP 之選擇 ..................................................................................... 13 第五章實驗結果.................................................................................................. 25 第六章相關研究.................................................................................................. 31 第七章結論.......................................................................................................... 32 參考著作...................................................................................................................... 33. iv.

(6) 附表目錄表表表表表表表. 1 TTP 內儲存之格式 ............................................................................ 26 2 近五年人口增長................................................................................ 26 3 加入 CAP 之實驗數據(一個服務提供者) ....................................... 27 4 加入 CAP 之實驗數據(三個服務提供者) ....................................... 28 5 不同數量檔案稽核比較時間(三個服務提供者) .............................. 29 6 加入 CAP 之實驗數據(五個服務提供者) ........................................ 29 7 不同數量檔案稽核比較時間(五個服務提供者)............................. 30. v.

(7) 附圖目錄圖圖圖圖圖圖圖. 1 雲端聯盟架構圖.................................................................................. 8 2 加入 TTP 之雲端聯盟架構圖 .......................................................... 12 3 Client 溝通步驟圖 .............................................................................. 16 4 證據分散在不同 Cloud ..................................................................... 17 5 當 CloudB 刪除保存之證據 .............................................................. 18 6 將上一個動作 Cloud 的證據複製到動作前 .................................... 19 7 複製證據會產生之問題.................................................................... 20. 圖 8 將證據以詢問的方式連結................................................................ 22 圖 9 將證據改串接到 Cloudc 下 ............................................................... 24. vi.

(8) 第一章緒論雲端聯盟（Cloud Federation）[19]是未來的趨勢，使用者所需要的服務往往不是由單一服務提供者能夠完成的，於是需要多個服務提供者的共同參與來完成，每個服務提供者提供不同的資料或是提供不同的服務。透過服務提供者跟服務提供者之間的溝通來完成使用者的服務請求。. 第一節. 雲端聯盟上的安全性議題. 在這裡我們先從單一服務提供者的架構下討論，再推廣至多個服務提供者。在傳統 Client-Server 架構下，使用者的請求通常是由一個服務提供者來完成，然而服務提供者可能會洩漏使用者的資料，例如在 2014 年美國零售業者 Target，因為承包商導致會員資料大量外洩的問題。以及雲端上的資料遭到修改、移除，回傳不正確的結果給使用者。例如安全公司 CheckPoint 在 2016 年提及 Facebook 上的程式漏洞[18]，有心人士可以利用漏洞，移除、回傳不正確的結果給使用者。這些問題的產生，可能是伺服器端的程式有 BUG、硬體損毀，或是外部攻擊者非法存取服務提供者儲存之資料，甚至內部員工擅自修改資料庫上的資料，即使服務提供者建置了非常完善的環境，還是可能在某些環節下的疏忽，導致問題的產生。將問題推廣至多個服務提供者上，使用者對服務提供者提出服務請求，服務提供者接受請求後，若是無法完成，則將服務請求轉發給其他服務提供者，由其他服務提供者完成使用者的請求，最後再將結果回傳給使用者。服務提供 1.

(9) 者跟服務提供者之間的溝通過程，使用者無法得知，若過程中發生上述的問題，導致使用者權益受損，常常使用者無法求償，就算服務提供者上有儲存的日誌檔，也可能會遭受服務提供者的竄改，導致無法證明服務提供者的過失，使用者也沒辦法提出證據，例如上述的 Facebook 案例[18]，因為承包商的問題而導致資料的外洩，使用者沒辦法直接證明是何處出了問題，無法求償，使用者也很難證明是程式的漏洞，導致本身的權益受損。上述問題產生時，通常不會馬上被發現，被發現後，使用者無法證明服務提供者有其過失，導致損失無法向服務提供者求償。當使用者發生問題時，服務提供者提出對應之日誌檔來證明是使用者操作上導致問題產生，往往也無法有效的說服使用者，因為提供的日誌檔並沒有法律效益也會遭受到使用者質疑其正確性。. 第二節. 情境. 在本篇論文中，為了能更了解問題，會利用大眾所熟知的醫療系統當作背景架構。我們採用台灣行政院下衛生福利部署立醫院來當背景。在台灣署立醫院超過 30 家，裡面包含醫院、分院、支院、療養院。我們舉一個情境來描述看診的過程中有可能產生的問題。情境：今天病人在台北醫院看診，醫生透過醫院的醫療系統，瀏覽病人的之前檢查的報告，根據之前的報告以及這次的檢驗結果，做出診斷，寫回醫院的資料庫。下一次同位病人到了苗栗醫院看診，因為兩間醫院都是所屬衛生福 2.

(10) 利部北區區域聯盟的醫院，彼此的病歷資料是相通的，也就是說在苗栗醫院，可以直接查詢到台北醫院的病歷資料。這時候有可能因為系統的關係或是檢驗室的疏失，造成醫生看到的資料是不正確的，導致醫生的誤診，造成病人權益的受損。舉例來說，可能因為原本病人有三筆病歷，但是在苗栗醫院醫生看診時，只看到兩筆，而導致誤診。會發生這種問題，有可能是因為系統本身有 BUG、中途網路的傳輸錯誤、醫生本身的漏看、甚至在台北醫院就少了一筆資料，都可能是造成問題的原因。上述情境，在過程中，有多個不同的使用者進入醫院的系統操作，彼此之間有先後關係。在台北醫院使用者的動作結果，會直接影響到後來苗栗醫院的使用者。將病人、醫生及檢驗單位當成使用者，醫療系統及醫院當成服務提供者就可將問題轉換成雲端上 Client-Server 的問題。上述情境中，可能是一個服務提供者對應多個使用者也可能是多個服務提供者對應多個使用者，彼此溝通上產生錯誤，導致結果出錯。. 第三節. 研究目的. 將原本的證明違約協定改良後應用於醫療系統上，打造一個安全可信的雲端醫療系統，保障所有動作的參與者。當有問題產生時，可以明確知道是哪個環節出錯，後面的使用者也可證明自己的正確性，不僅可以保障每個參與者，更可以針對錯誤的地方提出改善方案，更健全整個醫療系統。利用相同原理， 3.

(11) 進一步推廣至雲端聯盟上，保障整體雲端聯盟參與者，提升整體雲端的安全性。. 第四節. 論文大綱. 本篇論文組織架構如下：第一章我們介紹到雲端聯盟上的安全性議題，以及有可能遇到的情境，第二章詳細介紹證明違約及其協定（CAP），以及之前所做的相關研究，第三章我們介紹雲端聯盟的架構，並將 CAP 應用於雲端醫療系統上，探討所產生的問題，並解釋為何無法正常工作，第四章將 CAP 應用改良後在應用到雲端醫療系統，在此章，我們介紹採用的架構及技術，以及為何使用，並將所遇到之問題列出，提出方法來解決，且詳細列出其步驟，實驗結果呈現於第五章，從實驗數據中可以得知改良後的證明違約協定帶給原本雲端運作上多少負擔以及最後稽核的效率，最後於第六章做出本文的結論，並於第七章探討其他相關的研究文獻。. 4.

(12) 第二章證明違約一般雲端環境下，使用者跟服務提供者雙方之間溝通的不可否認性是沒辦法保證的。也就是說，若是有一方否認有其溝通，另外一方無法提供相關的證據來反駁。一般情況，使用者並不會留下跟服務提供者溝通的記錄，當服務提供者提供錯誤的資料，使用者無法證明是服務提供者的錯誤還是自己操作上的錯誤。通常服務提供者會利用日誌檔來記錄跟使用者溝通之過程，但是日誌檔不是真正的安全、可信任的，有可能會遭到服務提供者竄改、遺失，而且日誌檔是服務提供者產生，當發生問題時使用者並不一定會相信服務提供者所提供之記錄。過去的研究證明違約[27](Proof of Violation)能建立雙方不可否認性，當使用者提供的資料有問題時，能證明服務提供者是無辜的，是使用者本身的問題。又或者當服務提供者發生問題時，使用者可以證明是服務提供者產生的問題，當作求償的依據。進一步來達到整個系統的安全及責任歸屬，創造更加可信任的雲端運算環境。證明違約有三個特性：第一，需要先定義其屬性（Properties）；第二，雙方都要保留證據（Attestation），且證據具有法律效益，每個證據都必需要有雙方的簽章（Digital Signature），來證明雙方都同意證據的內容，來完成不可否認性；第三，具有稽核（Auditing）的機制，因保存的證據具有法律效益，發生問 5.

(13) 題時，可以根據證據的內容，來檢測是何者發生問題，達到責任釐清，更可進一步檢討改善。目前著名的雲端儲存空間有 Google Drive [2]、 Dropbox [3]、OneDrive [4]、 iCloud [5]、 SugerSync [6]以及 Box [7]。在 CloudProof[8]文中提出一個系統，其中的協定可以偵測並證明雲端儲存空間上四種安全性質：保密性（Confidentiality）、完整性（Integrity）、寫入循序性（Write Serializability）以及讀取新鮮性（Read Freshness），合稱 CIWF。使用者可以偵測服務提供者是否違反 CIWF，若是違反，可向服務提供者提出賠償。反之，服務提供者也可證明使用者是否提供錯誤資料故意敲詐。這個系統具有雙方不可否認性，使用者所做的請求、服務提供者提供的服務，都會被綁定在證據裡面。雙方保留的證據都會利用鏈結雜湊（Chain Hash）的方式記錄下來，因此使用者僅需保留最後一個鏈結雜湊的證據，而服務提供者要保留所有的證據，以便稽核所需。然而鏈結雜湊這個方法並不能抵禦服務提供者的回復式攻擊[9]（Roll-Back Attack），利用舊版的資料來否認遺失新版的資料，除非使用者保留所有的證據或是可以確保所有參與的使用者都可以得到最新的證據。 C&L Scheme[10]解決了這個問題，在證據裡面加上 LSN（Local Sequence Number）、使用者名稱（Client ID）、時代識別名稱（Epoch ID）搭配鏈結雜湊（Chain Hash），不只確保了雙方不可否認性，在使用者不需要彼此交換證據 6.

(14) 下，也可成功抵禦服務提供者發起的回復式攻擊，但是會遭遇到慢速攻擊（Slow Running Attack）[17]。在本文中採用 Double Chain Hash Scheme[17]來抵擋慢速攻擊。而後相關的研究也有針對應用於雲端資料庫、雲端回應時間[11]、雲端即時稽核[12][16]。在上述研究中，都是一個服務提供者搭配少量使用者的雲端環境。在本研究中，我們將 CAP 推廣，應用於雲端聯盟中，探討多個服務提供者，彼此之間溝通會產生的問題。最後我們針對上述問題，提出方法，並用理論證明提出來的方法是可行的，最後利用實作來驗證其效能。. 7.

(15) 第三章 CAP 應用於雲端聯盟第一節. 系統架構. 將證明違約協定應用於雲端聯盟上，跟以往最大的差別在於，雲端聯盟上，通常使用者提出請求後，單一服務提供者無法完成使用者所提出之請求，需要多個服務提供者介入，每個服務提供者都可能對應到多個使用者。如圖 1 所示。. ClientA ClientB ClientC. ……. Cloud2. Cloud1. ……. ……. ……. ClientD. CloudN. ClientE. ClientF. 圖 1 雲端聯盟架構圖接下來我們利用雲端醫療系統來當例子，假設使用者 A 為病人，使用者 B 為醫生，使用者 C 為檢驗單位，服務提供者為醫院系統。在單一雲端下，當病人去掛號看診時，會對醫院的醫療系統提出服務請求，例如掛號，當醫生看診時，也會使用醫療系統來查看病患的病歷，以及將診斷結果寫回醫療系統，過 8.

(16) 程中可能需要檢驗單位之協助檢驗，檢驗單位也會將檢驗結果寫回醫療系統，提供醫生觀看。但在多個醫院所組成之聯盟下，可能因為病人上次並不在同個醫院看診，醫生也有可能不在同個醫院看診，所以有可能在看診的過程中，病患的病歷儲存在另外一個醫院上，當醫生在目前的醫院上找不到相關病歷，就必須根據使用者之證據去其他醫院查詢相關病歷。將 CAP 應用於雲端聯盟上，還會有使用者角色及數量的問題。在以往 CAP 中，使用者往往是使用者周邊的裝置，例如：手機、平板、電腦，但是在雲端聯盟上是由其他不同角色的使用者組成，例如：病人、醫生、護理人員、檢驗單位，在使用者數量上，也從原本可能少數的裝置，變成大量且不同身分的使用者。. 第二節產生的問題若用以往的 CAP[10]架構，會有以下的問題產生。首先是證據部分，在[10] 研究中只有一個服務提供者，服務提供者需儲存所有的證據，當使用者想要服務提供者提出服務時，傳送一個請求訊息 Q 給服務提供者，服務提供者收到後會驗證裡面的訊息是否正確無誤，再回傳 R 給使用者，代表收到使用者之請求。使用者驗證完服務提供者簽章後，再回覆 RR 給服務提供者，服務提供者收到 RR 後開始動作，當服務提供者完成使用者要求後回傳 ACK 給使用者。服務提供者必須把所有證據留下，並用鏈結雜湊的方式串接起來，使用者僅需儲 9.

(17) 存最後一筆證據，服務提供者就無法竄改已經鏈結的證據。當稽核時，使用者拿出最後一筆證據，服務提供者拿出所有的證據來驗證。但在雲端聯盟的架構下，會有三個問題產生，導致無法稽核。第一，一個服務會有多個服務提供者的參與，導致證據會分散在不同的服務提供者上。會因服務提供者上證據的不連貫，增加稽核的困難、甚至導致無法稽核的問題產生。第二，原本應用於雲端儲存系統上，稽核時所有使用者拿出最後一筆證據是可行的，但是在雲端聯盟環境下，使用者的數量無法預估，稽核時要求所有使用者上線拿出最後一筆證據不太可能實現，也導致無法稽核的情況發生。第三，會遭遇慢速攻擊[17]，當有使用者提出服務請求，因網路傳輸問題或是惡意的使用者提出請求後未能在限定時間內完成動作，而導致其後的使用者無法繼續動作，導致服務提供者癱瘓之情形發生。上述的三個問題都會導致 CAP 無法在雲端聯盟上進行，在後續的章節內，我們針對上述問題提出解決方法，將 CAP 進行改良，並以理論及實驗證明提出之改良的證明違約協定是可解決上述問題，並可實際運行在雲端聯盟上。. 10.

(18) 第四章改良證明違約協定應用於雲端醫療系統第一節. 系統架構. 因上述問題，我們提出新的 CAP 架構，來解決無法稽核的問題。首先加入可信任的第三方（Trust Third Party）的架構。在可信任第三方的研究中[13]，大致上有三種分類，Inline、Online、Offline。Inline 的 TTP 會在協定中介入每一則訊息，Online 的 TTP 不會介入每一則訊息，但是雙方可以隨時跟 TTP 進行溝通進行稽核，Offline 的 TTP 則是只有在出現異常的情況下才會介入。首先我們先討論 Inline 的 TTP，又稱為 delivery agent，對於 TTP 的假設太強，不太可能真正實現，理由如下：第一，我們無法實現一個真正公平的系統環境，若是第三方有任何偏頗，可能會導致嚴重的後果發生；第二，對於 TTP 負擔太大，所有使用者跟服務提供者所傳達的所有訊息 TTP 都會介入並被記錄下來，那麼第三方的訊息量可能會超載；第三，TTP 可能會成為整個系統的瓶頸，當有大量的訊息同時進入，會導致 TTP 無法在短時間內，提供完整的服務。其次討論 Offline 的 TTP，這種 TTP 對於整個系統的負擔是最輕的而且也是最容易實現的，但是只能在發生問題的時候，才出來干涉兩方之間的內容或是當仲裁的角色。在本篇論文，我們採取的是 Online 的 TTP，當使用者做完動作後上傳證據到 TTP，當使用者下線時，若有需要稽核時僅需向 TTP 蒐集相關證據，則還是 11.

(19) 可以完成稽核的動作。如圖 2 所示，加入一個 TTP，使用者將最後一筆證據上傳至 TTP，使用者僅需保留上傳 TTP 所簽收之回條即可。. ClientA ClientB ClientC. ……. Cloud2. Cloud1. ……. ……. ……. ClientD. TTP. 圖 2 加入 TTP 之雲端聯盟架構圖. 12. Cloud3. ClientE. ClientF.

(20) 第二節. 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）技術並搭配即時稽核制度來解決上述問題。 13.

(21) 為了清楚描述此協定，我們先解釋符號代表之意義，[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 後，也必需驗證服務提供者電子簽章 14.

(22) 是否正確，再以 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 步驟的交握式 15.

(23) 上傳到服務提供者上，完成動作後，服務提供者回傳 ACK 給使用者，使用者收到服務提供者所回傳 ACK 後，再將 ACK 上傳至 TTP，TTP 收到使用者的 ACK 後回傳“回條”給使用者，使用者手中保留回條。將動作以下圖 3 來表達。. TTP. Client. Service Providers. 1.利用病人ID向TTP請求相關證據 SPa. 2.傳回所有Client對病人的最後一筆證據 3.1 根據TTP傳回之證據，蒐集各SP上相關動作病歷資料 3.2 發動稽核，確認是否正確 3.3 讀取相關病歷資料 3.4 做出處置動作 3.5 利用Four-Step-DH 執行CAP來完成動作. SPb SPc. SPd. 4.Send ACK 5. 上傳ACK至TTP. SPe. 6. 回傳”回條”給Client. 1. 圖 3 Client 溝通步驟圖再來，我們將使用者、TTP、服務提供者溝通的內容描寫如下，使用者對 TTP 請求相關病人證據我們採取兩步驟動作，使用者發 Qi=(Opi, ClientID, 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 傳送給 16.

(24) TTP，不用擔心 TTP 否認。使用者上傳給服務提供者之內容。我們是採取四步驟動作，由使用者發 Qi，Qi=(Opi, ClientID, ClientLSN, [Opi, ClientID, ClientLSN]pri(client))，其中 Op 裡面包含 PatientID、CloudName 服務提供者收到後回傳 Ri=(Qi, hash(ACKj), hash(Ri-1), [Qi,hash(ACKj), hash(Ri-1)] pri(provider)），使用者收到後回傳 RRi=(Ri, [Ri]pri(client))給服務提供者，則服務提供者開始動作，最後完成動作後將結果 ACKi=(Li, RRi, [Li, RRi]pri(cloud))傳回使用者完成這次使用者服務的請求。最後我們討論有可能發生的問題，當病人在不同醫院看診時，證據會分別串在不同的服務提供者上，依圖 4 所示。. IH CloudA. C1. C3 CloudB. C2. C3. C5 CloudC. C4. C6 C6. C1. C1. 圖 4 證據分散在不同 Cloud 上這時會產生一個問題，當服務提供者 B，將存在的證據刪除，則會導致一個問 17.

(25) 題產生，就是服務提供者 C 會不知道上一個動作是在哪裡完成的，如圖 5. IH CloudA. C1 C2. C3 CloudB. C3. C5 CloudC. C4. C6 C6. C1. C1. 圖 5 當 CloudB 刪除保存之證據在這裡先利用一個比較直覺的解法，我們當要轉換服務提供者時，應該將原本舊的服務提供者上的最後一筆證據，複製一份至新的服務提供者，如圖 6。. 18.

(26) IH CloudA. C1. C1 CloudB. C3. C4 CloudC C5. C2. C3. C1. C4. C6 C6. C6. C1. 圖 6 將上一個動作 Cloud 的證據複製到動作前這時若是像上述情形，服務提供者 B 故意或是不小心遺失、損毀資料，在服務提供者 C 手上還有原本服務提供者 B 最後一筆證據，這時便可釐清責任歸屬的問題，以便整個系統的完善。但這裡有可能會產生問題，就是可能不同的服務提供者會像同一個服務提供者去要求最後一筆證據。例如在圖 6 若是 CloudC 也像 CloudA 索取最後一筆證據，或者是 CloudB 將 CloudA 的最後一筆證據複製給 CloudC，那也會導致順序上產生問題，如圖 7。. 19.

(27) IH CloudA. C1. C1. C1 CloudB. C3. CloudC C5. C2. C3. C1. C4. C6 C6. C6. C1. 圖 7 複製證據會產生之問題我們要避免這種情形發生，我們需要向上一次動作的服務提供者要求連結。在這裡我們一步一步的說明步驟。 Step1:在動作之前，我們需要先向 TTP 要求所有使用者對於病人動作的最後一筆證據。 Step2:根據 TTP 上的儲存證據的順序，我們可以知道最後上傳給 TTP 的使用者是屬於哪個服務提供者。 Step3:先向最後上傳證據的服務提供者詢問，是否上一筆動作是在其完成。若不是的話，再依序往上詢問，直到詢問到為止。 Step4:若之前已經被詢問過的服務提供者，便不會承認是最後一個服務提供者，因已經被詢問過，所以代表之後有比他更晚提供服務的。若是還沒有被 20.

(28) 詢問過的服務提供者，則會承認他是最後一個提供服務的。 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 表示。. 21.

(29) IH CloudA. C1. CA1 CloudB. C3. CA4 CloudC C5. C2. C3. C1. C4. C6 C6. CA6. C1. 圖 8 將證據以詢問的方式連結最後我們假設一種情形，Cloud 皆是不可信任的，舉例來說，當 CloudB 發生誤診的情形想要把資料覆蓋，則 CloudA 與 CloudC 勾串，將最後一筆詢答的 Connection Attestation 連接給 CloudC，這時若要稽核，則一樣會產生上述的問題。接下來證明若利用此架構，服務提供者便無法將既有的證據刪除或是故意串接錯誤，使整體順序有誤。首先我們規定在使用者動作完以後，必需要把手中證據上傳給 TTP，這個規定是合理的，因為在確定誤診之前，不會有使用者故意要犯錯，使用者為了要保護自己，所以會按照規定，將證據上傳給 TTP。證據裡面包含使用者的 ID 及所屬的 Cloud。這時下一次有使用者要動作時先向 TTP 要求之前所有跟病人 22.

(30) 相關的證據，利用 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 下。這樣便可確保整體的順序性可 23.

(31) 以被追蹤，如圖 9。. IH CloudA. C1. CA1 CloudB. CA1 CloudC C5. C2. C6. C1. C6 C3. 圖 9 將證據改串接到 Cloudc 下. 24.

(32) 第五章實驗結果在本章的實驗，我們會用到兩種情況來互相比對其結果。第一種是一般情況下，寫入一個檔案到資料庫，所需的時間。第二種是加入 CAP，寫入一個檔案到資料庫，所需的時間。因為我們將證據存在 TTP 上，我們也會評估一下整個 TTP 上面容量的負擔。首先我們先評估一下 TTP 所需要的空間，再來我們會按照之前所提到的步驟，模擬兩種情況，第一種是沒有 TTP 的加入，使用者上傳診斷結果，Cloud 收到後回傳 ACK 給使用者，所需要的時間，來當作是一般動作，再來我們按照上述動作加入 CAP，將使用者向 TTP 請求，TTP 傳回證據，再對服務提供者提出動作，完成動作再將證據上傳到 TTP，TTP 回傳回條給使用者當成一次動作，再做一次實驗，觀察兩次的動作所耗費的時間。最後再多個 Cloud 來比較。首先評估 TTP 所需的空間。TTP 裡面存放著每個使用者的最後一筆 ACK 以及對應的病人 ID，所以 TTP 的大小為|Patient|*|Client|*|ACK Size|，以台北市來說人口為兩百七十萬[14]，醫生數量為 1 萬人[15]，每筆 ACK Size 為 7K Byte，TTP 需要的空間為 189T (10K*2.7M*7K) Byte。但是實際上，並不會醫生診斷每個病人，所以我們可以降低這個空間容量。在 2014 年台北市平均每位醫生服務人口數上[15]，每位醫生僅服務 300 個病人，所以我們將病人數量改為 300，這樣 TTP 的容量可大幅縮減僅需 21G(10K*300*7K) Byte 的空間就可完 25.

(33) 成。下表 1 為 TTP 內儲存之格式。表 1 TTP 內儲存之格式 Attestations. Owner Corresponding. Corresponding patient. ACKi. ClientA. PatientA. ACKj. ClientB. PatientB. ACKk. ClientA. PatientA. 再來，我們進一步分析，TTP 空間的成長。首先每個 ACK 大小是固定的，為 Cloud 在完成此次動作後傳回給使用者，使用者在收到後按照本篇的協定，必需上傳至 TTP 來當成證據存在。再來，按照"台北市政府民政局"[14]以及"中華民國醫師公會全國聯合會"[15]來說，病人以及使用者的數量都是有限的，且按照過去的資料來看，兩者成長是極為緩慢的，幾乎是可以忽略的。且每年的變動不大。所以 TTP 大小的估算是非常可行的，如表 2。表 2 近五年人口增長台北市. 人口數(六月). 醫生服務人數(平均). 2016. 2704974. ------. 2015. 2704133. 285.68. 2014. 2688140. 293.32. 2013. 2675033. 296.92. 2012. 2652959. 296.83. 26.

(34) 我們實驗使用的電腦規格為，處理器 Intel® B950 2.1GHz，記憶體 DDR3 4GB，傳統硬碟 500G，作業系統為 Windows 7，將實驗的數據以下列表 3 呈現，並解釋所代表其意義。表 3 加入 CAP 之實驗數據(一個服務提供者) Non POV 檔案. POV. 上傳. 下載. 上傳. 下載. 1KB. 63 ms. 60 ms. 65 ms. 10KB. 61 ms. 60 ms. 100KB. 70 ms. 1MB. 大小. POV(Audit) 1筆 10 筆 50 筆資料. 資料. 資料. 63 ms. 9 ms. 77 ms. 246 ms. 68 ms. 74 ms. 9 ms. 94 ms. 231 ms. 63 ms. 76 ms. 73 ms. 9 ms. 81 ms. 264 ms. 104 ms. 97 ms. 121 ms. 98 ms. 8 ms. 80 ms. 237 ms. 10MB. 413 ms. 386 ms. 436 ms. 401 ms. 12 ms. 141 ms. 367 ms. 100MB. 3851 ms. 3368 ms. 4634 ms. 3902 ms. 11 ms. 248 ms. 858 ms. 首先看到，在只有一個服務提供者的情況下，這種情形其實最頻繁的出現，因為通常人看病，往往只會去習慣去的醫院。所以第一個我們先做沒有加入 POV 機制，對一個檔案動作需要花費的時間。在實驗中，我們是採取執行一百次再將其取平均，裡面可以看到就算對 100MB 上傳來操作的時間也只要 3368ms。我們在單一服務提供者下加入 POV 的機制，我們可以明顯的看出來，時間比未加入 POV 需要花費較多的時間，多出來的時間主要是產生證據及儲存證據的時間，對於上傳 100M 的檔案來說，只要 4634 ms。這個數字對於整個醫療看診的時間，相對是可以忽略的。表格後方是稽核的時間，對於服務提供者只有 1 筆證據的時候，大約為 10 ms，當服務提供者上有 50 筆證據時，以最大的檔案 100MB 來看，大約需要 858 ms 便可完成稽核動作，大約呈線性成長。 27.

(35) 最後我們模擬三個服務提供者以及五個服務提供者下稽核需要花費的時間，每次稽核動作完，只會寫入一個服務提供者，所以上傳跟下載的時間部分，參考一個服務提供者的時間。表 4 加入 CAP 之實驗數據(三個服務提供者) POV(Audit) 3筆. 15 筆. 30 筆. 150 筆. 資料. 資料. 資料. 資料. 1KB. 27 ms. 121 ms. 201 ms. 1069 ms. 10KB. 33 ms. 174 ms. 353 ms. 1687 ms. 100KB. 37 ms. 170 ms. 298 ms. 1457 ms. 1MB. 40 ms. 186 ms. 337 ms. 1722 ms. 10MB. 36 ms. 216 ms. 388 ms. 1931 ms. 100MB. 49 ms. 293 ms. 530 ms. 2796 ms. 檔案大小. 表 4 裡面分別是對不同筆資料去做稽核所花費的時間，以 150 筆資料為例，證據儲存在三個不同的服務提供者各 50 筆，但還需要另外加上 2 筆連接的證據，以連接不同服務提供者上的證據。. 28.

(36) 表 5 不同數量檔案稽核比較時間(三個服務提供者). 3個Server稽核時間 3000 2500 2000 1500 1000 500 0 3筆資料. 15筆資料. 30筆資料. Server3-1KB. Server3-10KB. Server3-100KB. Server3-1MB. Server3-10MB. Server3-100MB. 150筆資料. 表 6 裡面，以 250 筆資料為例，證據儲存在五個不同的服務提供者各 50 筆，還要另外加上 4 筆連接的證據來連結不同服務提供者上的證據。表 6 加入 CAP 之實驗數據(五個服務提供者) POV(Audit) 5筆. 25 筆. 50 筆. 250 筆. 資料. 資料. 資料. 資料. 1KB. 56 ms. 218 ms. 344 ms. 2493 ms. 10KB. 67 ms. 293 ms. 573 ms. 3345 ms. 100KB. 53 ms. 273 ms. 644 ms. 3723 ms. 1MB. 65 ms. 372 ms. 679 ms. 3632 ms. 10MB. 61 ms. 326 ms. 575 ms. 4331 ms. 100MB. 69 ms. 378 ms. 731 ms. 5796 ms. 檔案大小. 29.

(37) 表 7 不同數量檔案稽核比較時間(五個服務提供者). 5個Server稽核時間 7000 6000 5000 4000 3000 2000 1000 0 5筆資料. 25筆資料. 50筆資料. Server5-1KB. Server5-10KB. Server5-100KB. Server5-1MB. Server5-10MB. Server5-100MB. 250筆資料. 在表 5 及表 7 裡面，可以看到不同檔案大小，及不同數量的檔案稽核時間。可以觀察到在稽核的時間大約是跟資料的數量呈線性關係，當累積大量證據，所需的稽核時間也會相對地提高。. 30.

(38) 第六章相關研究在今日電子病歷是普遍有的共識，相關的研究也非常的多，在病歷保護方面利用屬性加密、身分加密來達到資料的保護[20]，利用物聯網的技術來對病人做監測、可以及時發現病人身體數據之變化[21][22]，對於病人過往的病歷隨時做監測[23][24]，以及整個儲存系統的改善[25]，少數有的研究對於整個醫療系統去做設計[26]，但是整體而言，針對醫療系統本身的安全性以及可能會遭受到的攻擊，卻少有著墨。本篇論文在此部分參考 POV 應用在雲端儲存設備上的技術[27]，將 POV 之技術用於醫療系統中，來達到病歷資料的保護。. 31.

(39) 第七章結論在本篇論文中，我們將 POV 的技術應用到雲端聯盟上，並以醫療系統為背景，來說明可能會遇到的問題，並假設 Cloud 是不可信任的，改良原本 POV 的技術，讓 POV 技術能順利運行在雲端聯盟上。我們提出了一個可以確保醫療系統上數據的完整性，利用改良過的 POV 技術在操做醫療系統上讓使用者以及服務提供者雙方留下證據，在下次動作前做稽核，來確保每次動作的正確性，以及責任的歸屬。我們在實驗的部分計算了，在一個雲端下實際運行的時間，也計算了在多個雲端下要運行的時間，並且大概估算人口數對應到 TTP 所需要的成本，在理論部分，利用 Double Hash 技術避免了，之前 POV 會遇到的問題，並且考慮到許多可能會遇到的攻擊，利用文章中的協定以及技術來避免掉。利用密碼學的基礎，發展出更多保障雲端環境的應用。在未來，我們希望可以將 POV 的技術應用在更多的實際情形中，在醫療系統下，整個系統的正確、安全是我們首要的考量，時間並不是我們主要的考量因素，但在更多應用中，時間可能才是主要需要考慮的，這些都是 POV 技術需要在雲端聯盟下有更多發展才能解決。我們希望可以利用 POV 的技術套用到所有雲端聯盟的應用，使得整體雲端環境更為安全、可靠。. 32.

(40) 參考著作 [1] Kamara, Seny, and Kristin Lauter. “Cryptographic cloud storage,” Financial Cryptography and Data Security. Springer Berlin Heidelberg, 2010. 136-149. [2] “Google Drive,” https://www.google.com/intl/en/drive/. [3] “Dropbox,” https://www.dropbox.com/. [4] “OneDrive,” https://onedrive.live.com/about/en/ [5] “iCloud,” https://www.icloud.com/. [6] “SugarSync,” https://www.sugarsync.com/. [7] “Box,” https://www.box.com/. [8] Raluca Ada Popa, Jacob R. Lorch, David Molnar, Helen J. Wang, and Li Zhuang. “Enabling Security in Cloud Storage SLAs with CloudProof,” USENIX Annual Technical Conference. Vol. 242. 2011. [9] Jun Feng, Yu Chen, Douglas Summerville, Wei-Shinn Ku, Zhou Su. “Enhancing cloud storage security against roll-back attacks with a new fair multi-party nonrepudiation protocol,” Consumer Communications and Networking Conference (CCNC), 2011 IEEE. IEEE, 2011. [10] Gwan-Hwan Hwang, Jenn-Zjone Peng, and Wei-Sian Huang. “A mutual nonrepudiation protocol for cloud storage with interchangeable accesses of a single account from multiple devices,” 2013 12th IEEE International Conference 33.

(41) on Trust, Security and Privacy in Computing and Communications. IEEE, 2013. [11] Gwan-Hwan Hwang, and Yi-Ling Yuan. “Proof of violation for response time auditing in cloud systems,” The Journal of Supercomputing (2015): 1-12. [12] Gwan-Hwan Hwang, Wei-Sian Huang, and Jenn-Zjone Peng. “Real-time proof of violation for cloud storage,” Cloud Computing Technology and Science (CloudCom), 2014 IEEE 6th International Conference on. IEEE, 2014. [13] Kremer, Steve, Olivier Markowitch, and Jianying Zhou. “An intensive survey of fair non-repudiation protocols,” Computer communications 25.17 (2002): 16061621. [14] “台北市政府民政局” http://ca.gov.taipei/ [15] “中華民國醫師公會全國聯合會” http://www.tma.tw/stats/stater.asp [16] Gwan-Hwan Hwang, and H.-F. Chen. “Efficient Real-time Auditing and Proof of Violation for Cloud Storage Systems,” in 9th IEEE International Conference on Cloud Computing, San Francisco, USA, 2016. [17] Gwan-Hwan Hwang, Yi-Ling Yuan, and Chi Wu-Lee. “Cryptographic Accountability for Cloud-based Service-oriented Architecture Systems,” Submitted to journal for publication (in revision) [18] “Checkpoint,” http://blog.checkpoint.com/2016/06/07/facebook-maliciouschat/ [19] Kurze, Tobias, David Bermbach, Alexander Lenk, Marcel Kunze. “Cloud 34.

(42) federation,” CLOUD COMPUTING 2011 (2011): 32-38. [20] Chang-Ji Wang, Xi-Lei Xu, Dong-Yuan Shi, Wen-Long Lin. “An Efficient Cloud-Based Personal Health Records System Using Attribute-Based Encryption and Anonymous Multi-receiver Identity-Based Encryption,” P2P, Parallel, Grid, Cloud and Internet Computing (3PGCIC), 2014 Ninth International Conference on. IEEE, 2014. [21] Andreas K. Triantafyllidis, Vassilis G. Koutkias, Ioanna Chouvarda, Nicos Maglaveras. “A pervasive health system integrating patient monitoring, status logging, and social sharing,” Biomedical and Health Informatics, IEEE Journal of 17.1 (2013): 30-37. [22] Wan-Young Chung, Ee May Fong. “Seamless personal health information system in cloud computing,” Engineering in Medicine and Biology Society (EMBC), 2014 36th Annual International Conference of the IEEE. IEEE, 2014. [23] Yeong-Tae Song, Sungchul Hong, and Jinie Pak. “Empowering patients using cloud based personal health record system,” Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing (SNPD), 2015 16th IEEE/ACIS International Conference on. IEEE, 2015. [24] Fatma Zubaydi, Ayat Saleh, Fadi Aloul, Assim Sagahyroon. “Security of mobile health (mHealth) systems,” Bioinformatics and Bioengineering (BIBE), 2015 35.

(43) IEEE 15th International Conference on. IEEE, 2015. [25] Wan, Au Thien, and Sriram Sankaranarayanan. “Development of a Health Information System in the Mobile Cloud Environment,” High Performance Computing and Communications & 2013 IEEE International Conference on Embedded and Ubiquitous Computing (HPCC_EUC), 2013 IEEE 10th International Conference on. IEEE, 2013. [26] Zhang, Xin, and Tingting Zhang. “Achieving scalability in a distributed electronic health record system,” Science and Information Conference (SAI), 2013. IEEE, 2013. [27] Gwan-Hwan Hwang, Jenn-Zjone Peng, and Wei-Sian Huang. “A mutual nonrepudiation protocol for cloud storage with interchangeable accesses of a single account from multiple devices,” Trust, Security and Privacy in Computing and Communications (TrustCom), 2013 12th IEEE International Conference on. IEEE, 2013.. 36.

(44)