圖 三-1 在 C&L 架構下使用者帳戶維護的 LSN
在這個章節，我們提出了一個新的不可否認協定，考慮我們剛剛所提到的情 形，多個客戶端裝置利用相同的帳戶交錯的對資料做存取，客戶端的裝置都不交 換訊息，而且不需要額外的空間將所有使用者端的證據都儲存下來。
我們假設每個客戶端的裝置都有使用者的私鑰可以存取使用者 U 的帳戶。當 某個新的客戶端裝置準備開始利用 U 的帳戶存取資料時，他首先要送
client-ID-request 訊息 Z=(Timestamp, RequestID, [Timestamp, RequestID]
pri(U))給服 務提供者申請唯一的客戶端識別名稱，時間戳記(Timestamp)表示現在的時間，請 求身分識別(RequestID)這個訊息是指請求唯一的身分識別名稱，這個請求訊息還 加上了電子簽章，所以服務提供者可以藉此認證這個訊息是從哪個使用者所發過 來的，之後服務提供者回送訊息(Timestamp, EpochID, ClientID, [Timestamp,LSN(Client_1)
…
Service provider
Client_1
LSN(Client_2)
Client_2
LSN(Client_x)
Client_x
LSN(Client_1) LSN(Client_2)
. . LSN(Client_x)
EpochID, ClientID]pri(Provider))給客戶端的裝置，這裡的時間戳記(Timestamp)指 的是產生此訊息的時間，時代識別名稱是指某一段交易的時間，不同的使用者(或 帳戶)有不同的時代識別名稱。當所有的證據被銷毀時，我們將更變時代。每個客 戶端的裝置都有唯一的客戶端識別名稱，如果將它遺失了，必須向伺服器重新申 請。每個客戶端識別名稱都會連接一個正整數，稱為 local sequence number (LSN)，
標記為 LSN(ClientID)。LSN 是從 1 開始連續不斷的成長。
參考到圖 三-1，服務提供者必須保留所有客戶端裝置的 LSN，以及每個使 用者的時代識別名稱。客戶端的裝置只需要保留他們所申請的客戶識別名稱以及
LSN 和時代識別名稱。這個架構採用了鏈結雜湊以及 LSN，將他們崁入在溝通訊 息之中以確保雙方的不可否認性。
C&L 架構包含以下步驟：
Step 1: 當一個參與者想要存取某個共用資源時，這個參與者必須傳送一個要求
訊息 Qi, 到服務提供者，此外 Qi=(OPi, ClientID, LSN(ClientID), [OPi, ClientID,
LSN(ClientID)]pri(U))。這裡的 OPi 表示一個請求運算，如果這個服務是雲端 儲存伺服器，這個運算可以是寫入文件、讀取文件。若是網路銀行服務，這 個運算可以是提錢、存錢。
Step 2: 當服務提供者收到 Qi，他必須先驗證電子簽章([OPi, ClientID,
LSN(ClientID)]pri(U))是否正確，再者必須驗證 LSN(ClientID)的值是否有效(每 個使用者的 LSN 必須連號)，最後，服務提供者回傳回應訊息 Ri, Ri=(Qi,
EpochID, [Qi, EpochID, CHi–1]pri(Provider))給使用者。CHi–1 是 是第 i–1 次的鏈結 雜湊而且 CHi–1=[Qi–1
,
EpochID, CHi–2]pri(Provider)。Step 3: 當這個參與者收到 Ri，他必須先驗證 Ri的電子簽章是否有效而且要確保 時代識別名稱以及客戶端識別名稱是否正確。在這裡，這個參與者只能確認 電子簽章以及上述這些因子，他沒有辦法確定 Ri是否真的鏈結到 Ri–1之後，
原因是每一個參與者都只保有他們從服務提供者得到最新的承認訊息 ACK，j
j<i 而且 j 不一定等於 i–1。當這個簡略的驗證成功後，這個參與者送回覆回
應訊息 RRi給服務提供者，此時 RRi=(Ri, [Ri]pri(U))，在最後把 LSN(ClientID) 加一。這裡要注意的是服務提供者要保留所有的回覆回應訊息以供未來稽核 之用。
Step 4: 服務提供者執行此參與者的要求，當執行結束後回傳承認訊息 ACKi, where ACKi=(Li, RRi, [Li, RRi]pri(U))給使用者，Li 表示執行結果。
Step 5: 服務提供者將 LSN(ClientID)加一表示此運算完成
以下是 C&L 架構的例子，假設有兩個參與者分別為 ClientA 以及 ClientB 想 要存取伺服器上的資源，並且這個時間點的時代識別名稱為 EPH000001
Q1={(OP1, ClientA,1), [OP1, ClientA,1]Pri(U)}
R1={(Q1,EPH000001), [Q1,EPH000001, CH0]Pri(Server)} RR1={R1 ,[R1]pri(U)}
ACK1=(L1, RR1, [L1, RR1]pri(U))
Q2={(OP2, ClientA,2), [OP2,ClientA.2]Pri(U)}
R2={(Q2,EPH000001), [Q1,EPH000001, CH1]Pri(Server)} RR2={R2 ,[R2]pri(U)}
ACK2=(L2, RR2, [L2, RR2]pri(U))
Q3={(OP3, ClientB,1), [OP3, ClientB,1]Pri(U)}
R3={(Q3, EPH000001), [Q3, EPH000001, CH2]Pri(Server)} RR3={R3 ,[R3]pri(U)}
ACK3=(L3, RR3, [L3, RR3]pri(U))
Q4={(OP4, ClientA,3), [OP4, ClientA,3]Pri(U)}
R4={(Q4, EPH000001), [Q4, EPH000001, CH3]Pri(Server)} RR4={R4 ,[R4]pri(Client)}
ACK4=(L4, RR4, [L4, RR4]pri(U))
Q5={(OP5, ClientB,2), [OP5, ClientB,2]Pri(U)}
R5={(Q5, EPH000001), [Q5, EPH000001, CH4]Pri(Server)} RR5={R5 ,[R5]pri(Client)}
ACK5=(L5, RR5, [L5, RR5]pri(U))
圖 三-2 在 C&L 架構下五個運算的訊息
圖 三-2 對於客戶端 A 來說有三個證據，他的 LSN 是一、二、三。在 C&L 架構中，客戶端的裝置只須要維護他們自己的 LSN，若成功的完成對服務的請求，
則每個客戶端裝置的 LSN 必須連續不可中斷，如果客戶端的裝置有問題，在跟服 務提供者交換證據時，其 LSN 不連續，則服務提供者必須拒絕此次的存取。某個 客戶端的裝置有可能遺失他們的 LSN，因此在這個情況下，每個客戶端的裝置必 須重新像伺服器註冊新的客戶識別名稱，服務提供者的負擔包含了維護所有已註 冊的客戶識別名稱的 LSN。每一個客戶端的裝置都必須儲存最後一個從服務提供 者傳來的承認訊息。
定理(一):當我們使用 C&L 架構，服務提供者不可能啟動回復式攻擊 證明:
在 C&L 架構中，服務提供者必須儲存所有合法的伺服器端證據，並且利用這些 證據做以下的四點的確認：(R1)所有的電子簽章是正確的、(R2)所有的證據裡面 儲存的時代識別名稱必須相同而且正確、(R3)每個客戶識別名稱所連結的 LSN 都 必須從一開始，並且要連續且唯一、(R4)在伺服器端的證據所包含的回應訊息是 正確的鏈結，而且初始的雜湊值是雙方一開始就定義好的。若是依照上述 R1、
R2、R3、R4 這四個需求做檢測，服務提供者不可能遺失或是在正確的存取順序 中，插入任何合法的伺服器端證據造成使用者資料的錯誤，因為每一個客戶端的 裝置都存有最後一個從服務提供者送來的承認訊息，在 C&L 架構下的第三步驟，
客戶端的裝置沒有確認當下的回應訊息是否有正確的鏈結到前一個回應訊息中。
然而，根據第四個需求，因為初始的雜湊值是雙方事先定義好的，服務提供者必 須要正確的鏈結所有回應訊息，除非沒有在稽核的時候偵測錯誤，否則服務提供 者不可能發動回復式攻擊。
回到 Figure2，假設服務提供者試圖要遺失或是隱藏伺服器端的證據(RRk+1 to RRN)，
由於 LSN 是由客戶端裝置所產生並加在請求訊息中的，這樣會造成客戶端裝置的 LSN 不連續。客戶端裝置知道現在正確的 LSN，而且最後一個承認訊息也可以驗 證 LSN 的正確性。除了不可否認性之外，C&L 架構也可以保證寫入的順序性，
以及讀取的最新性，因為在同一個帳戶下，每一個運算的回應訊息都被正確的鏈 結在一起。