第一章 緒論
現今在雲端上提供的服務種類很多，電子郵件系統(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]兩種，兩者最
2
大的差異在於 POP3 所有編輯動作皆會在客戶端進行，即在連進服務提供端時會 立即下載所有信件並斷開連線，但 IMAP 可以在伺服器上建立，重新命名，或刪 除信箱，同時可感知其他用戶在不同時間對於同一信箱所做的操作，但傳送信 時依舊是透過 SMTP 協定進行；後者利用 SMTP 協定進行通訊。
第二節 電子郵件的安全性議題
在現今的電子郵件系統中，無論是 SMTP 或其他資料交換協定(如 FTP, …) 都沒有保證信件能夠確實的抵達，即便服務提供者在傳送的過程中遺失了信件 且，則使用者並無從得知自己寄出的信件並未送達，因此對於使用者而言，信 件一旦交由系統提供者傳送時，便失去的對於信件的掌控權，並且在無法確認 信件抵達時的順序性以及確定性。因此，使用者與服務提供者之間就必須簽訂 一個商業性合約，若是使用者的權益因服務提供者的過失而有所損害，使用者 可以透過合約中所訂定的賠償金予以索賠。我們用以下的情境說明信件傳遞有 可能發生的糾紛：愛麗絲與鮑伯為同一家公司的員工，在一次的會議中兩人被 告知獲得爭取晉升的機會，但是前提是必須要在今天午夜以前交付關於公司財 務改善的計劃報告書，並且以電子郵件的方式傳送結果，率先完成的人將得到 此次晉升的機會。隔天一早，經理便在會議中表示愛麗絲獲得晉升因為她優先 提交了報告且未曾收到鮑伯的相關信件，對此鮑伯提出了不滿表示他非常地確 定自己的報告有完成提交並且是在愛麗絲之前，但由於現今的電子郵件系統並
3
無法證明鮑伯卻時在愛麗絲之前完成了計畫書並且提交了報告，亦無法證明鮑 伯所陳述的是謊話。由以上範例可以很明顯看出對於一個完整的電子郵件系統 而言，信件收取順序性以及行為不可否認性是不可或缺的，因此，我們需要一 個可以讓服務提供者證明自己並無過失且使用者能夠保障自己信件傳遞權益的 方法，而此種證明的方法稱作稽核(Auditing)且根據為雙方簽證過的訊息所留 下的證據(Attestation)來達到不可否認性。
CloudProof[9]文中提出了一個系統，其中的協定可以偵測並證明雲端儲存 空間上四種安全性質：保密性(Confidentiality)、完整性(Integrity)、寫入 循序性(Write Serializability)以及讀取新鮮性(Read Freshness)，何稱為 C IWF。使用者可以偵測雲端儲存空間是否違反 CIWF，而服務提供者可以反駁使 用者的誣告，這個系統有保證不可否認性，使用者所做的請求以及服務提供者 維護資料的狀態都會被綁定在證據裡面。使用者所做的請求都會和服務提供者 交換證據，這些證據都利用鏈結雜湊(Chain Hash)的方式記錄下來，因此客戶 端裝置上面只需要留下擁有最後一個鏈結雜湊的證據，而服務提供者保留所有 的證據以便稽核時所需。然而鏈結雜湊這個方法不能夠抵禦來自服務提供者的 回復式攻擊，除非客戶端裝置保留所有的證據或者有一個方法可以廣播最後的 證據給其他客戶端裝置，因此若是用 CloudProof 建構在電子郵件系統上，服務 提供者可以輕易地去更改使用者的寄件證據而不被察覺，如此一來便失去了郵 件順序以及正確傳遞的保證。
4
另一種新的方法 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 的私有鑰匙
5
所簽署。
考慮一個情境，有一個帳戶可以被多個客戶端裝置去做存取的一些基本動 作，我們假設客戶端裝置擁有使用者 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 嵌 入在彼此交換的訊息中，留有這些經過電子簽章簽署的訊息得以確保不可否認
6
性。這個方法稱作 C&L Scheme。
第四節 論文組織與結構
本篇論文組織如下: 第二章介紹在電子郵件系統中時段性證明違約協定的 運作，第三章敘述在時段性證明違約協定下需要保證的架構特性，第四章證據 稽核的方法與步驟，第五章提出實作成果以及實驗數據，第六章描述相關研 究，在第七章我們做出總結。
7
ACK LSN ACK LSN
MS_DA_1
ACK LSN ACK LSN
MS_DA_1
(B1,2,G_B,3) (B2,1,G_B,4)
圖 二-1 在 C&L 架構下使用者與系統所需維護的資訊
如圖 二-1 所示，對於每個使用者帳戶而言，服務提供者除了基本的儲存所 有信件、保存所有的證據以及記錄所有識別帳戶對應 LSN 的 Account-LSN table