電子郵件系統之行為違反證明技術

全文

(1)國立臺灣師範大學資訊工程研究所碩士論文. 指導教授：黃冠寰. 博士. 電子郵件系統之行為違反證明技術. Proof of Violation for Cloud E-mail Systems. 研究生：中華民國. 王子豪. 一百零四. 年. 撰八. 月.

(2) 摘要鑒於電子郵件系統結合傳統郵件的通訊結構與現代的方便性，使得它成為網路時代的著名成就之一，數以百萬計的用戶每天透過系統服務者管理、儲存以及轉發他們私人的信件，這些大量且具有隱私問題的信件時常遺漏或丟失，且不僅僅是服務提供者會有如此重大的紕漏，用戶也有可能會犯這樣的錯誤，但是在目前的電子郵件中，無論是對於個別使用者或是公司企業而言，郵件的安全送達或是抵達的順序都是相當重要的。根據證明違約架構(POV)，可以讓服務提供者證明自己並無違反與使用者之間的約定以及讓使用者證明自己所有動作的完成，證明方法是根據使用者在每次的請求之中附上電子簽章以及服務提供者在一個明確的情況下完成並且保存雙方完整的簽章證據以供稽核。使用者每次請求時都會和服務提供者交換數位簽章證據，這些證據是被單一鏈結雜湊所串連起來並且儲存在服務提供端，因此客戶端裝置僅需要儲存最後一個證據便可保障每次請求一定會被完成，而且裡面包含著最後一個鏈結雜湊。服務提供者則須保留所有的證據以供稽核。在這篇論文中，我們將證明違約架構加入現有的電子郵件系統中，其中單一鏈結雜湊可以保證信件抵達的順序性與數位簽章可達到客戶與服務提供者雙方的不可否認性，利用這些特性即可使得現有的系統更加穩固與值得信賴。關鍵字：雲端安全、電子郵件系統、稽核、不可否認性、證明違約. i.

(3) 誌. 謝. 首先非常感謝黃冠寰老師在這兩年中不畏艱辛的教導，讓我能夠從一個原本完全不懂得活用書中知識的懵懂學生成長為較懂得兼顧實際與想法，老師常常跟我們說在剛接觸到一件新的東西時，要先抱持著懷疑的態度去面對，而不是一昧地去認為自己看到的就是正確的，而是再透過自己的分析與其他資料的輔助之後，進而去證實甚至是推翻之前的言論，這讓我能夠在以後面對到新的環境時，能夠更快地去適應或者是發掘出不是那麼顯而易見的問題點，透過這樣兩年以來的訓練與成長，我想在洞察事物與表達能力上都有不凡的改進。除此之外，在這兩年中我的家人也無怨言的默默地支持著我，讓我能夠全心全力第去完成我的學業。另外，還有要感謝這兩年中遇到的學長與朋友們，感謝李祺學長、裕偉學長，在對於學業感到困惑、迷惘時給予很多他們的經驗作為引路燈，讓我能夠從泥沼中躍出。感謝我一起奮鬥的同學上語、詩凱、虹甫，是你們一起才讓我有了繼續前進的動力。最後感謝後學們，柏翔、佳均、儀齡、浩群、偉智以及之中，有你們的歡笑與活力，為我們的實驗室注入了一股活力，感謝大家。. 王子豪. 誌於. 國立臺灣師範大學資訊工程研究所民國一百零五年八月. ii.

(4) 目錄摘要................................................................................................................................. i 誌謝............................................................................................................................ ii 第一章. 緒論........................................................................................................ 1. 第一節. 電子郵件系統的簡介............................................................................ 1. 第二節. 電子郵件的安全性議題........................................................................ 2. 第三節. POV 簡介............................................................................................ 4. 第四節. 論文組織與結構.................................................................................... 6. 第二章. 電子郵件系統之證明違約.................................................................... 7. 第三章. 稽核...................................................................................................... 15. 第一節. 信件的完整抵達性.............................................................................. 15. 第二節. 單一帳戶寄信順序不可否認性.......................................................... 16. 第三節. 單一帳戶收信順序不可否認性.......................................................... 17. 第四節. 確認信件的已讀.................................................................................. 18. 第四章. 實驗成果.............................................................................................. 20. 第一節. 證明違約架構的額外負擔.................................................................. 21. 第二節. 量測三個客戶端－單一服務提供端.................................................. 22. 第三節. 量測三組客戶端－服務提供端.......................................................... 23. 第四節. 稽核效率.............................................................................................. 24. 第五章. 相關研究研討...................................................................................... 26. 第六章. 結論...................................................................................................... 28. 參考著作 .................................................................................................................. 29. iii.

(5) 圖目錄圖圖圖圖圖圖. 二-1 在 C&L 架構下使用者與系統所需維護的資訊 .......................... 7 二-2 在 C&L 架構下五個運算的訊息 ................................................. 11 二-3 使用端與服務提供端儲存資訊.................................................. 12 三-1 服務提供端證據儲存格式........................................................... 14 四-1 三個客戶端對單一服務提供端送信示意圖............................... 17 四-2 三個客戶端對相對應的服務提供端送信示意圖....................... 19. iv.

(6) 表格目錄表格表格表格表格. 四-1 單一客戶端傳遞每封信件平均時間(in sec) ....................... 21 四-2 三個客戶端同時傳送每封信件平均執行時間(in sec)....... 22 四-3 服務提供端收取每封信件平均執行時間(in sec)............... 23 四-4 個別稽核單一狀況的執行時間(in sec).............................. 24. v.

(7) 第一章緒論現今在雲端上提供的服務種類很多，電子郵件系統(e-mail system)是藉由服務提供者所架設的伺服器，提供使用者一個簡潔的介面收發電子郵件，電子郵件系統可以藉由使用者端裝置或是網頁版的使用者介面去登入使用服務，著名的雲端電子郵件系統包括 Gmail[1], Yahoo mail[2], and Hotmail[3]，在雲端計算中是歸類為平台即服務(Platform as a Service)。. 第一節電子郵件系統的簡介電子郵件是由一個發信者到一個或多個接收者接換信息的網路方法，信件格式由 RFC5322[4]協定規範，其中由標題文本、內文組成。標題文本中每個項目皆以單行單行記錄，最基本包含了寄信者、收信者與信件標題(如上圖)，內文中包含了信件內容以及附加檔案。早期的電子郵件系統，須由雙方皆同時在線上進行信息交換，但現今的電子郵件系統設計為存儲與轉發兩大模式，而當中僅需一個系統提供者替使用者完成所有工作。儘管電子郵件最早的歷史可追朔至 1971 年，並且近年來更是蓬勃發展，但最主要的概念卻未曾更動，而現在大多電子郵件服務提供者之間使用的 SMTP(簡單郵件傳輸協議)[5]在 RFC 5321[6]中正式發表，奠定了電子郵件發展的基礎。電子郵件傳遞過程可以簡單分為兩個階段：客戶端和服務提供端、服務提供端和服務提供端。前者之間收信通訊管道為 POP3[7]與 IMAP[8]兩種，兩者最 1.

(8) 大的差異在於 POP3 所有編輯動作皆會在客戶端進行，即在連進服務提供端時會立即下載所有信件並斷開連線，但 IMAP 可以在伺服器上建立，重新命名，或刪除信箱，同時可感知其他用戶在不同時間對於同一信箱所做的操作，但傳送信時依舊是透過 SMTP 協定進行；後者利用 SMTP 協定進行通訊。. 第二節電子郵件的安全性議題在現今的電子郵件系統中，無論是 SMTP 或其他資料交換協定(如 FTP, …) 都沒有保證信件能夠確實的抵達，即便服務提供者在傳送的過程中遺失了信件且，則使用者並無從得知自己寄出的信件並未送達，因此對於使用者而言，信件一旦交由系統提供者傳送時，便失去的對於信件的掌控權，並且在無法確認信件抵達時的順序性以及確定性。因此，使用者與服務提供者之間就必須簽訂一個商業性合約，若是使用者的權益因服務提供者的過失而有所損害，使用者可以透過合約中所訂定的賠償金予以索賠。我們用以下的情境說明信件傳遞有可能發生的糾紛：愛麗絲與鮑伯為同一家公司的員工，在一次的會議中兩人被告知獲得爭取晉升的機會，但是前提是必須要在今天午夜以前交付關於公司財務改善的計劃報告書，並且以電子郵件的方式傳送結果，率先完成的人將得到此次晉升的機會。隔天一早，經理便在會議中表示愛麗絲獲得晉升因為她優先提交了報告且未曾收到鮑伯的相關信件，對此鮑伯提出了不滿表示他非常地確定自己的報告有完成提交並且是在愛麗絲之前，但由於現今的電子郵件系統並. 2.

(9) 無法證明鮑伯卻時在愛麗絲之前完成了計畫書並且提交了報告，亦無法證明鮑伯所陳述的是謊話。由以上範例可以很明顯看出對於一個完整的電子郵件系統而言，信件收取順序性以及行為不可否認性是不可或缺的，因此，我們需要一個可以讓服務提供者證明自己並無過失且使用者能夠保障自己信件傳遞權益的方法，而此種證明的方法稱作稽核(Auditing)且根據為雙方簽證過的訊息所留下的證據(Attestation)來達到不可否認性。 CloudProof[9]文中提出了一個系統，其中的協定可以偵測並證明雲端儲存空間上四種安全性質：保密性(Confidentiality)、完整性(Integrity)、寫入循序性(Write Serializability)以及讀取新鮮性(Read Freshness)，何稱為 C IWF。使用者可以偵測雲端儲存空間是否違反 CIWF，而服務提供者可以反駁使用者的誣告，這個系統有保證不可否認性，使用者所做的請求以及服務提供者維護資料的狀態都會被綁定在證據裡面。使用者所做的請求都會和服務提供者交換證據，這些證據都利用鏈結雜湊(Chain Hash)的方式記錄下來，因此客戶端裝置上面只需要留下擁有最後一個鏈結雜湊的證據，而服務提供者保留所有的證據以便稽核時所需。然而鏈結雜湊這個方法不能夠抵禦來自服務提供者的回復式攻擊，除非客戶端裝置保留所有的證據或者有一個方法可以廣播最後的證據給其他客戶端裝置，因此若是用 CloudProof 建構在電子郵件系統上，服務提供者可以輕易地去更改使用者的寄件證據而不被察覺，如此一來便失去了郵件順序以及正確傳遞的保證。 3.

(10) 另一種新的方法 C&L Scheme[10]解決了 CloudProof 這個問題，文中提出除非客戶端裝置保留所有的證據或者廣播自己最後一個證據給其他客戶端裝置，否則只使用鏈結雜湊無法抵禦回復攻擊的證明，並利用鏈結雜湊搭配嵌入 LSN(Local Sequence Number)、客戶識別名稱(ClientID)以及時代識別名稱(Ep ochID)於證據中，不只確保了雙方的不可否認性，在 LSN 的協助下可以成功抵禦服務提供者發起的回復式攻擊，在這個方法中客戶端裝置在存取雲端儲存空間中的一個單一帳戶，客戶端裝置之間不需要彼此交換證據，而且每一個客戶端裝置都只需要保留最後一個由服務提供者傳來的證據。 CloudProof 以及 C&L Scheme 這兩種利用證據來稽核的方法我們歸類為時段性證明違約(Epoch-based Proof of Violation)。我們認為應該要在現有的電子郵件系統中加上時段性證明違約來記錄所有信件的轉發與接收，如此一來便可以確保雙方權益不受到損害。. 第三節 POV 簡介在這個章節我們會先介紹時段性證明違約的方法。首先，為了描述此協定，我們先解釋這個協定的符號意義，[O]pri(x)表示使用者 x 簽署在資料物件 (Data object)O 上的電子簽章，此簽章是由使用者 x 自己的私有鑰匙所簽署，此外在中括號內，多個資料物件會以逗號隔開，表示多個物件資料被使用者 x 簽署，如例子[O1, O2, O3]pri(x)表示資料物件 O1、O2 和 O3 被使用者 x 的私有鑰匙. 4.

(11) 所簽署。考慮一個情境，有一個帳戶可以被多個客戶端裝置去做存取的一些基本動作，我們假設客戶端裝置擁有使用者 U 用來存取帳戶的私有鑰匙，當一個新的客戶端裝置準備好開始存取使用者 U 的帳戶前，它先傳送一個 client-ID-. request 訊息，Z=(Timestamp, RequestID, [Timestamp, RequestID]pri(U))，給服務提供者去索取一個獨一無二的客戶識別名稱(ClientID), 其中時間戳記 (Timestamp)是當前的時間，請求身分識別(Request ID)指此訊息是請求唯一的身分識別名稱，這個訊息有附上電子簽章，因此服務提供者可以授權這則訊息的擁有者。之後服務提供者傳送一個訊息(Timestamp, EpochID, ClientID, [Timestamp, EpochID, ClientID]pri(Provider))給客戶端裝置，其中時代識別名稱表示一段時間世代，不同的使用者或是帳戶會有不同的時代識別名稱，當所有證據都被稽核完畢要進入下一個時代時，這些證據都不需要在保存而會被丟棄，用戶識別名稱是一個獨一無二的，如果客戶端裝置丟失了目前使用的可以再申請新的一組，一個用戶識別名稱會對應一個正整數，稱為 local sequence number(LSN)，標記為 LSN(ClientID)，LSN 是從 1 開始連續成長。服務提供者必須保留相同帳戶下所有客戶識別名稱所對應的 LSN 以及這個帳戶的時代識別名稱，一個客戶端裝置需要保留它自己的客戶識別名稱以及對應的 LSN 以及當前的時代識別名稱，這個方法採取將單一鏈結雜湊以及 LSN 嵌入在彼此交換的訊息中，留有這些經過電子簽章簽署的訊息得以確保不可否認 5.

(12) 性。這個方法稱作 C&L Scheme。. 第四節論文組織與結構本篇論文組織如下: 第二章介紹在電子郵件系統中時段性證明違約協定的運作，第三章敘述在時段性證明違約協定下需要保證的架構特性，第四章證據稽核的方法與步驟，第五章提出實作成果以及實驗數據，第六章描述相關研究，在第七章我們做出總結。. 6.

(13) 第二章電子郵件系統之證明違約在現今網路蓬勃發展的時代裡，電子郵件系統早已取代了緩慢的傳統郵件，而在每日頻繁的電子郵件傳遞下，無論電子郵件本身的重要性，不知已經有多少遺失或毀損在傳遞的過程中，然而這樣的情況下使用電子郵件系統不論是私人用途或是公司用途都會有自我利益損失，因此我們必須提出辦法在每次郵件的傳送與接收時，達成使用者以及服務提供者雙方的不可否認性，因此我們將證明違約架構加到現有的電子郵件系統當中。. MS_DA_1. MS_DA_1. (A1,2,G_B,3). (B1,2,G_B,3). (A2,1,G_B,4). (B2,1,G_B,4). (A3,2,G_B,5). redirector. redirector. ACK LSN. ACK LSN. ACK LSN. ACK LSN. Client_A1. Client_A2. Client_B1. Client_B2. 圖二-1 在 C&L 架構下使用者與系統所需維護的資訊如圖二-1 所示，對於每個使用者帳戶而言，服務提供者除了基本的儲存所有信件、保存所有的證據以及記錄所有識別帳戶對應 LSN 的 Account-LSN table. 7.

(14) 之外，我們在服務提供端另外加上了 Mail-LSN table，最主要為了防止服務提供端與部分使用者進行勾串，為了對部分使用端有進而更改寄信順序。其中在 LSN 對應表中的 A1、A2、B1 代表使用端不同裝置，。相對於服務提供者，每個不同的使用端裝置僅需記錄該裝置所對應的 LSN 與保存最後的證據即可。以下我們將先介紹留存證據的方法，相關步驟如下： Step 1:. 使用者 U 使用所持的客戶端裝置要對使用者 U 的帳戶做收、送信. 時或服務提供者想要轉送信時，裝置要傳送一個請求訊息 Qi 給服務提供者，Qi=(OPi/RRJ, ClientID, LSN(ClientID), [OPi, ClientID, LSN(ClientID)]pri(U))，若是由服務提供端轉送信則會將 OPi 改為與使用端的簽章證據 RRJ，其中 OPi 包含此次請求的詳細資訊，OPi =(Header，Email，PathName)，其中 Header 為電子郵件的傳送簡易訊息，內容包括發件人、收件人和發送日期， Data 為信件的雜湊值並非指實際信件，PathName 為附加檔案的路徑位址，ClientID 為該使用者 U 之客戶端裝置所持的客戶識別名稱，LSN(ClientID)為該裝置對應的唯一的一組整數，用來和服務提供者檢查存取動作的新鮮性，最後將三者全部做一次簽章的動作。 Step 2: 當服務提供者接收到來自客戶端裝置的請求 Qi，首先驗證此請求 Qi 內的電子簽章[OPi, ClientID, LSN(ClientID)]pri(U)是否有效，無效將拒絕這次請求，有效則會將請求 Qi 內的請求之檔案名稱對應的 8.

(15) 信號標、客戶識別名稱對應的帳戶 LSN (Account-LSN)以及目標郵件對應的帳戶 LSN 從位於服務提供者所維護的三個資料結構 Map 之容器中調取出來，並試著上鎖請求中檔案所對應的信號標，而帳戶 LSN 則是以備下一步驟使用。 Step 3: 此時已進入檔案名稱對應信號標之臨界區間(critical section)，服務提供者必須檢查雙方此次所認知的 LSN 是否相同，首先解析出請求 Qi 中客戶識別名稱對應的 LSN，並檢查此 LSN 與上一步驟之 LSN 是否相同，由此可以避免惡意使用者或竊聽者之重放式攻擊，而透過 LSN 本身可以在稽核的階段偵測出是否服務提供者有發動回復式攻擊。 Step 4: 將該檔案最後一次操作之證據中的多鏈結雜湊 CHPathName(i–2)與先前取出的信件 LSN (Mail-LSN)及其目標郵件地址，串聯至此次操作中取雜湊得出此次的多鏈結雜湊 CHPathName(i–1)。 Step 5: 傳送回應訊息 Ri 給使用者 U 所持之客戶端裝置，Ri=(Qi, EpochID, CHPathName(i–1), TargetAddress, LSN(TargetAddress), [Qi, EpochID, CHPathName(i–1), TargetAddress, LSN(TargetAddress)]pri(Provider))，其中 CHPathName(i–1) 是該檔案路徑所對應的第(i–1)th 個多鏈結雜湊而 CHPathName(i–1)=[Qi–1, EpochID, CHPathName(i–2)]pri(Provider)。 Step 6: 客戶端裝置收到來自服務提供者的回應訊息 Ri 並確認該電子簽章的 9.

(16) 正確性後準備開始檢查相關內容。 Step 7: 客戶端裝置必須檢查回應訊息 Ri 內的客戶端名稱以及時代識別名稱確認是否服務提供者所認知的客戶端名稱以及時代識別名稱是否相同。但此時客戶端裝置無法檢查 Ri 是否正確地有和上一個回應訊息 Ri-1 串聯，因為客戶端裝置只有保留最後一個來自服務提供者的完成動作後所傳送給客戶端裝置的承認訊息 ACKj，其中 j < i 且 j 可能不等於 j-1。 Step 8: 當檢查完畢後，客戶端裝置傳送回覆回應訊息 RRi 給服務提供者，其中 RRi=(Ri, [Ri]pri(U))。 Step 9: 客戶端裝置的 LSN(ClientID)增加一以便下個請求使用，需要注意的是服務提供者必須保留所有的回覆回應訊息以便未來稽核所需。 Step 10: 服務提供者收到來自客戶端裝置的回覆回應訊息並確認該電子簽章的正確性後準備開始執行客戶端所要求的操作指令。 Step 11: 服務提供者開始執行 Qi 內所要求的操作指令。 Step 12: 操作指令執行完畢後，服務提供者傳送承認訊息 ACKi， ACKi=( Li, RRi, [Li, RRi]pri(provider))，給使用者 U 的客戶端裝置，其中 Li 為執行結果。 Step 13: 服務提供者將 LSN(ClientID) 增加一以便下個請求使用。客戶端裝置收到承認訊息 ACKi 後，將其保留作為以後稽核之證據，而且該 10.

(17) 證據只需保留最後一個操作指令的證據，其他根據協定會由服務提供者保留。下面我們對 C&L Scheme 展示一個範例，假設目前電子郵件系統為初始未進行任何動作的狀態，當有兩個客戶端裝置想要用使用者 S 這個電子郵件帳戶收信以及向 R 這個電子郵件帳戶寄信，其中客戶端裝置所持有的客戶識別名稱分別為 ClientA 以及 ClientB，以 OPi(S)與 OPi(R)分別代表送信以及收信，且當下的時代識別名稱為 EPH000001。簡易的動作流程為 A 寄信→B 寄信→S 替 A 轉信 →S 收 R 信→A 讀信。 Q1={(OP1(S), ClientA, 0, hash(mail1)), [OP1(S), ClientA, 0, hash(mail1)]pri(U)} R1={(Q1, EPH000001, CH0, R, 0), [Q1, EPH000001, CH0, R, 0]pri(Provider)} RR1={R1 ,[R1]pri(U)} ACK1=(L1, RR1, [L1, RR1]pri(Provider)) Q2={(OP2(S), ClientB, 0, hash(mail2)), [OP2(S), ClientB, 0, hash(mail2)]pri(U)} R2={(Q2, EPH000001, CH1, R, 1), [Q1, EPH000001, CH1, R, 1]pri(Provider)} RR2={R2 ,[R2]pri(U)} ACK2=(L2, RR2, [L2, RR2]pri(Provider)) Q3={( RR1, S, 0), [RR1, S, 0]pri(U)} R3={(Q3, EPH000001, CH2), [Q3, EPH000001, CH2]pri(Provider)} RR3={R3 ,[R3]pri(U)} ACK3=(L3, RR3, [L3, RR3]pri(Provider)) Q4={( RRi, R, 1, hash(maili)), [RRi, R, 1, hash(maili)]pri(U)} R4={(Q4, EPH000001, CH3), [Q4, EPH000001, CH3]pri(Provider)} RR4={R4 ,[R4]pri(U)} 11.

(18) ACK4=(L4, RR4, [L4, RR4]pri(Provider)) Q5={(OP5(R), ClientA, 1), [OP5(S), ClientA, 1]pri(U)} R5={(Q5, EPH000001, CH4), [Q5, EPH000001, CH4]pri(Provider)} RR5={R5 ,[R5]pri(U)} ACK5=(L5, RR5, [L5, RR5]pri(Provider)) 圖二-2 在 C&L 架構下五個運算的訊息在圖二-2 中，首先使用者 A 先向 R 這個電子郵件帳戶寄信且得到由服務提供端數位簽章後的證據，而在服務提供端替使用者 A 進行轉信之前，先收到且完成使用者 B 的要求之後才進行使用者 A 的轉信動作，如此一來，便可依據 Ri 所形成的鍊結雜湊確定所有動作的先後順序。藉由加入上述所提及的架構與留存下的證據，我們可以達到以下四點： 1.. 保證信件的抵達：在圖二-3 (C) 中可以看到 R1 為使用端裝置 A1 寄信給使用端 B 時與服務提供端數位簽章後所留下的證據，其中還包含了這次寄信的信件雜湊值以保證信件不會遭到更改，而 ACK3 則是記錄了服務提供端替使用端裝置 A1 轉送信後所得到的承認訊息(ACK)，藉由鏈結雜湊中的 R1 與 ACK3 即可證明使用端裝置 A1 的該次寄信有正確地抵達；若是信件在途中遺失或是對方伺服器問題無法送達，則電子郵件系統會傳送一封失敗的通知信到使用端信箱中，當服務提供端收到時也會在鏈結雜湊上簽章一個證據以供稽核。. 12.

(19) IH. IH. IH. R1. OP(S)1, A1, 0, hash(R0), hash(MAIL1). R1. OP(S)2, A2, 0, hash(R0), hash(MAIL2). R1. OP(S)1, A1, 0, hash(R0), hash(MAIL1), B, 0. R2. OP(S)2, A2, 0, hash(R1), hash(MAIL2). R2. OP(S)1, A1, 0, hash(R1), hash(MAIL1). R2. OP(S)2, A2, 0, hash(R1), hash(MAIL2), B, 1. ACK3. RR1, B, 0, hash(R2). ACK3. RR1, B, 0, hash(R2). ACK3. RR1, B, 0, hash(R2),. R4. RRii, A, 0, hash(R3), hash(maili)). R4. RRii, A, 0, hash(R3), hash(maili)). R4. RRii, A, 0, hash(R3), hash(maili). R5. OP(R)5, A, 1, hash(R4), hash(MAIL). R5. OP(R)5, A, 1, hash(R4), hash(MAIL). R5. OP(R)5, A, 1, hash(R4), hash(MAIL). (A). (B). (C). 圖二-3 2.. 不同使用端裝置利用同一帳戶進行寄信的順序不可否認性：在圖二-3 (A)(B)中為一般的 C&L，即為沒有加入帳戶 LSN(AccountLSN)的原始版本。在(A)中為正確的寄信順序以及鏈結雜湊，R1 與 R2 分別為使用端裝置 A1 以及 A2 對同一個帳戶 B 寄信，並且使用端裝置 A1 的順序在使用端裝置 A2 之前完成。但是在(B)中可以看到可能會因為服務提供端與使用端裝置 A2 勾串而導致寄信順序顛倒，並且由於在回復訊息 (Response)中僅記錄使用端裝置的 LSN，無法代表任何寄信順序，因此應該要在回復訊息(Response)中記錄帳戶 LSN (Account-LSN)以保證寄信時的順序不會被更改，如圖二-3 (C)所示。. 3.. 不同使用端利用分別帳戶進行寄信的順序不可否認性： 13.

(20) 雖然不同帳戶在相對應的服務提供端皆有一條鍊結雜湊，但若是不曾有過信件來往的兩個帳戶便不會有關聯的證據存在，因此當兩個不同帳戶對另外單一帳戶進行寄信時，之間的順序關係僅能依靠在收信服務提供端上的信號標(Semaphore)。當收信服務提供端想要接收一個來自其他帳戶的信件時，它會先試著去上鎖請求中帳戶所對應的信號標，若信號標並未上鎖則這一個請求服務提供者可以執行，否則必須等待該信號標被解鎖，也就是等待另一個正在對該帳戶做存取的請求完成，並且該帳戶對應的鏈結雜湊有正確被串聯到該帳戶上一個鏈結雜湊，方可解鎖信號標讓下一個請求開始存取。藉由這樣的信號標即可在收信端維持住不同使用端利用分別帳戶進行寄信的順序。 4.. 服務提供者可能跟使用端的證據勾串：在服務提供端為使用者進行轉信時，由於必須要等到對方伺服器的信號標被解鎖才能進行轉送信，但是有可能會因為這樣而導致對方伺服器與其他送信帳戶的勾串，對方伺服器假裝信號標因為其他帳戶仍在使用而尚未解鎖，進而影響收信時的順序。當送信端遇到對方伺服器超過固定時間未回應回復訊息時，則可請額外的公信第三方(Trust third party)進行詢問，確認信號標的鎖定是否合乎規定。若是經由公信第三方認定為惡意鎖定，送信端可藉由公信第三方的交信證據向對方伺服器提出求償。. 14.

(21) 第三章. 稽核. 我們利用多種稽核方式來達到 C&L Scheme 在電子郵件系統中保證的四個特性，分別為信件的完整抵達性、單一帳戶內寄信的順序不可否認性、單一帳戶內收信的順序不可否認性、確認信件的已讀。. 第一節信件的完整抵達性假設一個情境，使用者 S 透過服務提供者 U 進行所有信件的傳遞與接收，但是在一次的傳遞信件過後，使用者 S 被反應並沒有收到該封信件，此時使用者 S 並可以利用經由 C&L Scheme 留下的相關證據向服務提供者 U 進行求證。相關動作如下： Step 1: 使用者 S 收集所有裝置的最後一個證據。 Step 2: 使用者 S 向服務提供者 U 提出稽核請求，並且傳送該信件的雜湊值。 Step 3: 服務提供者 U 在鏈結雜湊中尋找相對應於該信件的傳送承諾訊息 (ACKi)，若是存在，便可證明使用者 S 的信件有交付給服務提供者 U 進行傳送。其中，ACKi 為服務提供者 U 簽章過後傳送給使用者 S 的承諾訊息。 Step 4: 服務提供者 U 在傳送承諾訊息(ACKi)的排序後尋找相對應的送達承諾訊息(ACKj)，若是存在，利用 ACKi 以及 ACKj 便可保證信件確 15.

(22) 實有抵達目標信箱。其中 ACKj 為信件正常抵達目標信箱時由對方服務提供者簽章過後傳回的承諾訊息。. 第二節單一帳戶寄信順序不可否認性假設一個情境，使用者 S 依序利用兩個不同的裝置 D_1 以及 D_2 透過服務提供者 U 向另一電子郵件地址進行信件傳送，但是一段時間過後，使用者 S 想要確定該次信件是否有依照傳送的順序抵達目標信箱，此時使用者 S 並可以利用經由 C&L Scheme 留下的相關證據向服務提供者 U 進行求證。相關動作如下： Step 1:. 使用者 S 收集所有裝置的最後一個證據。. Step 2:. 使用者 S 向服務提供者 U 提出稽核請求，並且傳送分別由客戶端. 裝置 D_1 以及 D_2 所傳送信件的雜湊值 Step 3:. 服務提供者 U 在鏈結雜湊中尋找相對應於分別信件雜湊值的傳送. 承諾訊息(ACKi)，若是存在，便可證明使用者 S 透過客戶端裝置傳送的信件有交付給服務提供者 U 進行傳送，分別記為 ACK1 和 ACK2。其中，ACKi 為服務提供者 U 簽章過後傳送給使用者 S 的承諾訊息， i=1,2。 Step 5: 服務提供者 U 在傳送承諾訊息(ACKi)的排序後尋找相對應的送達承諾訊息(ACKj)，分別記為 ACK3 和 ACK4。若是存在，利用 ACKi 以及 ACKj 便可保證信件確實有抵達目標信箱，並且利用分別客戶端. 16.

(23) 裝置的 ACK3 和 ACK4 得出傳送的順序是否正確。其中 ACKj 為信件正常抵達目標信箱時由對方服務提供者簽章過後傳回的承諾訊息， j=3,4。. 第三節單一帳戶收信順序不可否認性假設一個情境，使用者 S_1 與 S_2 透過分別的服務提供者向使用者 R 的電子郵件帳戶進行信件的傳遞，但是信件完成傳遞過後，使用者 S_1 與 S_2 想要確定在使用者 R 的電子信箱中的信件先後順序，此時使用者 S_1 與 S_2 便可以利用經由 C&L Scheme 留下的相關證據向使用者 R 的服務提供者進行求證。相關動作如下： Step 1: 使用者 S_1 與 S_2 分別收集各自所有裝置的最後一個證據。 Step 2: 使用者 S_1 與 S_2 將收集到的證據交由使用者 R 對其服務提供者提出稽核的請求，並且由使用者 R 同時將要比對的信件雜湊值傳送給服務提供者。 Step 6: 服務提供者在鏈結雜湊中尋找相對應於分別信件雜湊值的傳送承諾訊息(ACKi)，若是存在，則代表該信件確實有正常抵達，分別記為 ACK1 和 ACK2。利用上述的 ACK1 和 ACK2 便可確認信件的先後順序，服務提供者將結果回傳給使用者 R。其中，ACKi 為服務提供者簽章過後傳送給傳送信件端的承諾訊息，i=1,2。. 17.

(24) 第四節確認信件的已讀假設在使用端並沒有跟服務提供端共謀的情況下，送信端使用者 S 透過服務提供端 U1 向收信端使用者 R 的服務提供端 U2 進行一次信件的傳送，在完成傳送之後，此時使用者 S 便可以利用經由 C&L Scheme 留下的相關證據透過服務提供端 U1 向使用者 R 的服務提供者 U2 進行求證。相關動作如下： Step 1:. 使用者 S 收集所有裝置的最後一個證據。. Step 2:. 使用者 S 透過服務提供端 U1 向使用者 R 的服務提供端 U2 提出稽. 核請求並傳送該信件的雜湊值。 Step 3:. 服務提供者 U2 在鏈結雜湊中尋找相對應於分別信件雜湊值的傳送. 承諾訊息(ACKi)，若是存在，則代表該信件確實有正常抵達。 Step 4:. 服務提供者 U 在傳送承諾訊息(ACKi)的排序後尋找任何由使用者. R 執行動作結束後產生的承諾訊息(ACKj)，若存在，則代表使用者 R 必定已經讀取過信箱中任何信件。但是如果使用端跟服務提供端共謀，則可能使用者 R 向服務提供端 U2 進行了收信的動作後，使用者 R 認知到這次的讀信將有損害自我的權益，因此與服務提供端 U2 進行串謀(collusion)而刪去了這次讀信的證據，即便透過世後稽核也無法得知收信端 R 已經讀取過信件，但是同時使用者 S 也再也無法在服務提供端 U2 的鏈結雜湊上添加任何具有 C&L Scheme 效益的證據，因為一旦有新. 18.

(25) 的證據產生且串在鏈結雜湊上，送信端 S 便可利用這證據來證明信件已經被讀取，因此串謀的代價便是失去 C&L Scheme 對於信件傳遞不可否認性的保障。. 19.

(26) 第四章實驗成果我們進行多種情況來實測應用單一鏈結雜湊的 C&L Scheme 在電子郵件系統中信件傳遞的執行效率，所有的信件都是由同一個帳戶傳送，並由不同的客戶端裝置去對服務提供者進行傳送信件的動作。情況包含有 (1)在單一帳戶下，單一客戶端要求單一服務提供端進行轉送信件的動作時，證明違約架構對於電子郵件系統所造成的額外負擔，這個情況統整在表格五-1。 (2)在單一帳戶下，3 個客戶端裝置同時對單一服務提供端傳送信件，信件的目標電子郵件地址為同一服務提供端，這個情況統整在表格五-2。 (3)在 3 個帳戶下，個別客戶端對於相對應的服務提供者傳送信件，信件的目標電子郵件地址為同一服務提供端，這個情況統整在表格五-3。 (4) 利用上述兩步驟(2)、(3)實作中留下的證據，以第四章中所提及的稽核方法分別測試個別的效率，這個情況統整在表格五-4。其中傳遞信件與稽核的詳細步驟分別在第二章與第四章有詳細說明，表格中皆是以秒計，資料大小設定為 1kB、100Kb、10MB 和 100MB，並且執行 1、10、50 次信件傳遞後去取平均執行時間。我們實驗中服務提供者的電腦規格為 Intel(R)Core(TM) i7 CPU 920 @ 2.67GHz 2.67GHz，記憶體為 10GB，作業系統為 Windows 7(64 bits)，而客戶端所使用的電腦規格為 Intel(R)Core(TM) i5-4590 CPU @ 3.30GHz 3.30GHz，記憶體為 8GB，作業系統為 Windows 7(64 bits)。. 20.

(27) 第一節證明違約架構的額外負擔首先我們先量測證明違約架構對電子郵件系統所造成的額外負擔，在這項實驗中主要量測客戶端傳送信件所需的平均時間。在單一帳戶下，單一客戶端在對單一服務提供端傳送一百次不同大小信件時所花費的平均執行時間，如表格四-1 所示，可以看出 C&L 並沒有對系統造成過多的負擔，除了 100MB 的黨需要較多的時間完成之外，其他都可在可接受的範圍內完成。表格四-1 單一客戶端傳遞每封信件平均時間(in sec) Pure email sysytem. Email system with C&L Scheme operation. attestation. time(s). size(KB). operation time(s). 1kB. 0.242. 0.729. 163KB. 100kB. 0.275. 0.753. 163KB. 1M. 0.439. 0.951. 163KB. 10MB. 0.613. 1.122. 163KB. 100MB. 4.218. 4.829. 163KB (Average running time). 21.

(28) 第二節量測三個客戶端－單一服務提供端. ClientA. Sender Server. ClientB. Receiver Server. ClientC. 圖四-1 三個客戶端對單一服務提供端送信示意圖在這項實驗中，我們最主要量測服務提供端在面對多個客戶端裝置同時且大量的信件傳送時的執行效率。在三個客戶端下，對單一服務提供端同時進行不同次數不同大小信件所花費的平均執行時間。如表格四-2 所示，由於每個客戶端裝置在對服務提供端進行動作時，其他的客戶端裝置必須等到回復訊息串到鏈結雜湊之後才會得到處理權，因此在速度上皆會有延遲而造成額外的等待，尤其是在大檔案時又要加上檔案傳輸時間，情況會更加明顯。表格四-2 三個客戶端同時傳送每封信件平均執行時間(in sec) Pure email sysytem. Email system with C&L Scheme operation. attestation. time(s). size(KB). operation time(s). 1kB. 0.867. 1.296 22. 1201KB.

(29) 100kB. 1.273. 1.472. 1209KB. 1M. 1.356. 1.786. 1209KB. 10MB. 1.941. 2.371. 1207KB. 100MB. 4.885. 5.343. 1213KB. (Average running time). 第三節量測三組客戶端－服務提供端. ClientA. ServerA. ClientB. ServerB. ClientC. ServerC. Receiver Server. 圖四-2 三個客戶端對相對應的服務提供端送信示意圖在這項實驗中，我們最主要量測服務提供端同時且大量收取信件時的執行效率。在三個客戶端下，單一客戶端裝置對相對應的服務提供者進行不同次數不同大小信件所花費的平均執行時間。如表格四-3 所示，由於是每一客戶端裝置利用相對應的服務提供端進行動作，因此可讓之間所有行為平行處理減少等待時間，但是在大檔案的傳輸時間仍舊佔了大部分時間。表格四-3 服務提供端收取每封信件平均執行時間(in sec) 23.

(30) Pure email sysytem. Email system with C&L Scheme operation. attestation. time(s). size(KB). operation time(s). 1kB. 0.526. 0.888. 1221KB. 100kB. 0.826. 1.022. 1225KB. 1M. 1.451. 1.670. 1225KB. 10MB. 1.843. 2.374. 1227KB. 100MB. 5.146. 5.234. 1223KB. (Average running time). 第四節稽核效率在這項實驗中，我們將利用以儲存在使用端與服務提供端的資料進行量測各別稽核執行效率，稽核方法分別為(一)信件的完整抵達性 (二)單一帳戶內寄信的順序不可否認性 (三)單一帳戶內收信的順序不可否認性。由於執行時間會因為所選取的信件先後而有所不同，因此我們將所有信件分成一半，信件的選取則分成(1)前半部分信件任取一封 (2)後半部分信件任取一封 (3)全部信件隨機挑選一封進行稽核，每種情況分別執行 20 次後取平均時間。如表格四-4 所示，可以看出稽核信件分布的位置對於速度有很明顯的影響，但在隨機選取的效率來講卻來的比較平均，整體而言，由於稽核時僅需傳送與比對證據中的雜湊值，並沒有需要大量的計算流程，因此執行時間都還在可以接受的範圍內。表格四-4 個別稽核單一狀況的執行時間(in sec) 24.

(31) 前半信件任取. 後半信件任取. 隨機選取信件. α. 7.61. 11.4. 8.92. β. 6.23. 15.37. 10.25. γ. 6.98. 14.63. 11.02. α：信件的完整抵達性 β：單一帳戶內寄信的順序不可否認性 γ：單一帳戶內收信的順序不可否認性. 25. (Average running time).

(32) 第五章相關研究研討現在較廣為人知的雲端儲存空間包含有包括 Gmail[1], Yahoo mail[2], and Hotmail[3]，但是這些服務提供者僅僅單純提供使用者相對應的服務，並不提供使用者與服務提供者之間的不可否認性，一個最簡單的方法去保證使用者的所有信件皆能夠正常且完整收發的方法便是不間斷地等待服務提供端的結果，否則有可能在一段時間後便遺忘了去確認信件的正常傳送與否，因此若是需要使用者持續關注自己所寄出的每一封郵件就違背了電子郵件系統顛覆傳統郵件的方便性與即時性。Gmail 的讀取回條是在收件者在開啟郵件時，會回覆給寄件者的電子郵件通知，這樣的功能能夠讓寄件者確認自己的信件卻時傳送且已經被閱讀，並會將查看時間與相關資訊紀錄在郵件內文下面，但是這樣的紀錄卻有可能會因為服務提供端的惡意刪除而永久遺失，並且使用端沒有能夠留下佐證的相關資訊而失去效用。有些系統則是考慮電子郵件在傳送到目標伺服器之前便遺失，無論是服務提供端的惡意丟失郵件或是傳送過程中的錯誤皆造成將近 5%的比例[11][12]，並且使用者無法得知寄出的信件已丟失，SureMail[13]是設計用來偵測且通知使用者的一個電子郵件系統，此系統設計概念分成兩層，第一層利用連續的郵件傳送保證任何其中的郵件都不會被遺漏，其中每封郵件都包含前一封的部分資訊，藉由系統收信時的自動比對確保上一封的傳送；第二層為系統內的雜湊. 26.

(33) 表紀錄，即每個 SureMail 帳戶皆會有一個雜湊表去紀錄即將送達的郵件，事後可藉由比對雜湊表得知是否有郵件遺失，這系統最大問題在於雜湊表的保存在服務提供端且使用者並無證據可去追朔郵件遺失權責。上述提到對於電子郵件系統缺失所提出的架構，雖然針對單一問題提出了相對應的解決方法，但是相同的瓶頸在於所有的動作皆由服務提供端代替完成，並且留下作為佐證的紀錄也全部交由服務提供者保管，對於使用者而言是相當沒保障，電子郵件擔保架構[14]則是使用端會留下所有的證據以供稽核，在此架構下，使用者在每次想要傳送郵件時，會先對郵件進行對稱加密後再傳送給服務提供端，且收件者必須藉由從使用端收到的一組雜湊值向第三公正方驗證身分後，才能獲得相對應的對稱密鑰解開加密。雖然此架構保證了信件的抵達與安全性，但是卻無法解決信件遺失的權責以及郵件抵達順序的公平性問題。. 27.

(34) 第六章. 結論. 現今證明違約在電子郵件系統中的應用是相當具有重要性，當包含了重要資訊的郵件內容及附件的傳遞是由其他人所執行的情況下，如果在過程中發生問題時，必須要能夠去釐清是當中的哪個環節出了差錯，並且讓使用者能夠傭有實質的證據去捍衛自己收發信的權益，同時也藉由 C&L Scheme 在使用者以及服務提供者之間進行郵件動作時留下的數位簽章證據，確保了兩方之間的不可否認性以保障郵件的正確送達與順序性。雖然我們提出了應用 C&L Scheme 在現今電子郵件系統中，保障了收發信雙方的不可否認性，但是卻無法處理使用者與服務提供者的讀信勾串，即是收信端在讀取信件之後，發現讀取信件對自己不利，因此與服務提供端勾串，刪除相對應的讀信證據。由於所有的動作皆是在對方伺服器中進行，寄件端並無從得知，僅能透過其他方法進行通知讀信，但仍無法做為稽核且求償的證據，在這方面仍有改善的空間，目前僅能用失去 C&L Scheme 的代價防範勾串的行為。. 28.

(35) 參考著作 [1] “Gmail”, https://www.gmail.com/intl/zh-TW/mail/help/about.html [2] “Yahoo mail”, https://tw.help.yahoo.com/kb/helpcentral [3] “Hotmail”, http://windows.microsoft.com/zh-tw/hotmail/home [4] P. Resnick, “RFC 5322 - Internet Message Format,” Oct.2008. [Online]. Available: http://www.ietf.org/rfc/rfc5322.txt\ [5] J. Klensin, “Simple Mail Transfer Protocol,” RFC 5321, IETF, October 2008. [6] J. Klensin, “RFC 5321 - Simple Mail Transfer Protocol,”Oct. 2008. [Online]. Available: http://www.ietf.org/rfc/rfc5321.txt [7] Crispin, M., "Internet Message Access Protocol – Version 4rev1", RFC 2060, December 1996. [8] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [9] R. A. Popa and J. R. Lorch. “Enabling Security in Cloud Storage SLAs with CloudProof,” USENIX Annual Technical Conference (USENIX), 2011, pp. 31. [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,” The 12th IEEE International Conference on Trust, Security and Privacy in Computing and Communications (IEEE TrustCom-2013), Melbourne, Australia, 16-18 July. [11]M. Afergan and R. Beverly. The State of the Email Address. ACM CCR, Jan 29.

(36) 2005. [12]A. Lang. Email Dependability. Bachelor of Engineering Thesis, The University of New South Wales, Australia, Nov 2004. http://uluru.ee.unsw.edu.au/etim/dependable email/thesis.pdf. [13]Sharad Agarwal, Venkata N. Padmanabhan, Dilip A. Joseph, “Addressing Emai l Loss with SureMail: Measurement, Design, and Evaluation” 2007 USENIX Annual USENIX Association Technical Conference [14]Giampaolo Bella, Universit`a di Catania, Lawrence C. Paulson, University of Cambridge, “Accountability Protocols: Formalized and Verified” ACM Journal Name, Vol. V, No. N, January 2006. 30.

(37)