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
8
之外，我們在服務提供端另外加上了 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內的請求之檔案名稱對應的
9
信號標、客戶識別名稱對應的帳戶 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並確認該電子簽章的
10
正確性後準備開始檢查相關內容。
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後，將其保留作為以後稽核之證據，而且該
11
12
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的該次寄信有正確地抵達；若是信件在途中遺失或是 對方伺服器問題無法送達，則電子郵件系統會傳送一封失敗的通知信到使 用端信箱中，當服務提供端收到時也會在鏈結雜湊上簽章一個證據以供稽 核。
13
IH
R1
OP(S)1, A1, 0, hash(R0), hash(MAIL1)
R2
OP(S)2, A2, 0, hash(R1), hash(MAIL2)
ACK3 hash(maili))
R5 hash(MAIL2)
R2
OP(S)1, A1, 0, hash(R1), hash(MAIL1)
ACK3 hash(maili))
R5 hash(maili)
R5
在圖 二-3 (A)(B)中為一般的 C&L，即為沒有加入帳戶
LSN(Account-LSN)的原始版本。在(A)中為正確的寄信順序以及鏈結雜湊，R1與 R2分別 為使用端裝置 A1以及 A2對同一個帳戶 B 寄信，並且使用端裝置 A1的順序 在使用端裝置 A2之前完成。但是在(B)中可以看到可能會因為服務提供端 與使用端裝置 A2勾串而導致寄信順序顛倒，並且由於在回復訊息
(Response)中僅記錄使用端裝置的 LSN，無法代表任何寄信順序，因此應 該要在回復訊息(Response)中記錄帳戶 LSN (Account-LSN)以保證寄信時的 順序不會被更改，如圖 二-3 (C)所示。
3. 不同使用端利用分別帳戶進行寄信的順序不可否認性：
14
雖然不同帳戶在相對應的服務提供端皆有一條鍊結雜湊，但若是不曾 有過信件來往的兩個帳戶便不會有關聯的證據存在，因此當兩個不同帳戶 對另外單一帳戶進行寄信時，之間的順序關係僅能依靠在收信服務提供端 上的信號標(Semaphore)。當收信服務提供端想要接收一個來自其他帳戶的 信件時，它會先試著去上鎖請求中帳戶所對應的信號標，若信號標並未上 鎖則這一個請求服務提供者可以執行，否則必須等待該信號標被解鎖，也 就是等待另一個正在對該帳戶做存取的請求完成，並且該帳戶對應的鏈結 雜湊有正確被串聯到該帳戶上一個鏈結雜湊，方可解鎖信號標讓下一個請 求開始存取。藉由這樣的信號標即可在收信端維持住不同使用端利用分別 帳戶進行寄信的順序。
4. 服務提供者可能跟使用端的證據勾串：
在服務提供端為使用者進行轉信時，由於必須要等到對方伺服器的信 號標被解鎖才能進行轉送信，但是有可能會因為這樣而導致對方伺服器與 其他送信帳戶的勾串，對方伺服器假裝信號標因為其他帳戶仍在使用而尚 未解鎖，進而影響收信時的順序。當送信端遇到對方伺服器超過固定時間 未回應回復訊息時，則可請額外的公信第三方(Trust third party)進行詢問，
確認信號標的鎖定是否合乎規定。若是經由公信第三方認定為惡意鎖定，
送信端可藉由公信第三方的交信證據向對方伺服器提出求償。