具效率与可延迟验证之一次性信用卡号付款机制.docx

具效率與可延遲驗證之一次性信用卡號付款機制陳彥錚國立暨南國際大學資訊管理學系林佳緯國立暨南國際大學資訊管理研究所摘要隨著網際網路上電子商務蓬勃發展，電子商務所仰賴的網路付費系統越來越重要。各式電子付費系統皆有其付款機制的特性與適用的環境，透過網路等媒介提供使用者便利性，但也帶來安全與效率的議題。銀行在付費系統中扮演產生票據與驗證票據的功能，在處理大量的交易業務時，計算的效率與資料庫比對的效率顯得非常重要，因此，如何提供一個兼具安全與效率的電子付費系統是一個重要的研究課題。本論文提出一個具效率並採用一次性信用卡號的信用卡付費機制，此機制除了可以避免一般使用信用卡電子付費導致卡號洩漏的問題，在執行效率上，於延遲驗證時可以省去批次比對的步驟，大幅節省銀行驗證時的計算負擔。此外，我們也提出一個可以簡易地產生一次性信用卡號方法，可以大輻改善信用卡號驗證之效能。關鍵字：電子商務、電子付款機制、一次性信用卡號AbstractAlong with the blooming development of E-commerce over the Internet, Internet payment systems become increasingly important. Each Internet payment system has its own characteristics payment mechanism and applied environment. Although these payment systems provide much convenience via network and other media, various security and efficiency issues are to be investigated. Among current payment systems, banks play an important role in generation and verification of payment credentials used in the payment systems. To provide a secure payment service, a lot of computation cost and maintenance overhead is usually required in banks. As more electronic commerce services are provided in the Internet, it is important to improve the performance of the current payment systems, especially the performance of banks in processing a number of payment transactions. In this paper, we propose an efficient credit card payment system based on one-time credit card transaction numbers. Compared with previous approaches, the proposed system achieves better performance in the verification of one-time credit card numbers, especially when delayed verifications are allowed. We further propose a new way to generate one-time credit card numbers. The proposed method significantly improves the performance of credit card number verification.Keywords: Electronic Commerce, Electronic Payment, One Time Credit Card Number 壹、緒論近年來，於網際網路進行電子商務行為已愈來愈普遍，消費者透過網際網路進行購物行為，可以不用浪費時間在路途的往返，打破傳統的限制與不便，促進電子商務的發展。推廣使用網際網路購物一個成功的重要因素在於安全的付費機制，目前發展中的網路付費機制大體上可以分為三類(Neuman and Medvinsky, 1995)：線上信用卡付費系統(Credit Card Payment)、電子支票(Electronic Check System)、以及電子錢幣系統(Electronic Cash System)。線上信用卡付費系統，其安全性主要是配合SSL(Secure Sockets Layer) (Freier et al., 1996)之使用，或與SET(Secure Electronic Transaction)(SET, 2002)系統結合。使用SSL的加密模式能確保消費者在傳送信用卡資料與訂單資訊到商店端過程受到加密保護，不致於被截取信用卡資料，然而由於信用卡資訊已經存在商店端的伺服器中，因此若是商店的伺服器被入侵，則信用卡資訊有被盜用的風險(Krawczyk, 2001)。SET針對此問題做了改進，採用了PKI公開金鑰基礎建設(Public Key Infrastructure)，利用RSA加密方式將信用卡資訊與訂單資訊分開加密，信用卡的資訊是由銀行的公開金鑰加密，所以商家無法得知信用卡內的資訊、銀行不能看到商店的貨單資料因此可以保護消費者的隱私。但由於SET之使用必須先下載程式於客戶端電腦，並進行複雜的啟動程序，目前市場接受度不高(Asokan et al., 1997)。傳統以支票付款的方式已在社會接受且廣泛的使用，是商業交易中很重要的支付工具，透過網際網路以電子的方式來簽發電子支票，在操作上與傳統書面的方式沒有什麼差別，因此可以節省教育使用者的時間，也容易被使用者採納使用。但金融法規規定要開立支票帳戶需要有一定的限制，以維護信用交易秩序，因而限制了電子支票付款的使用對象與範圍。且電子支票就如同傳統的書面支票一樣，通常發票人、收票人、票據金額等資料都會被參與的銀行知悉，所以對買賣方的隱私沒有保護，因此不適合應用在有隱私需求的交易上。第三類使用電子錢幣之系統依據儲存方式又可以分為智慧卡型電子錢幣與網際網路空間型電子錢幣，智慧卡電子錢幣是將電子錢幣儲存在一個安全的智慧卡中，可隨身攜帶卡片來取代傳統的貨幣來交易；而網際網路空間型電子貨幣則是交易雙方設定電子給付系統來進行付款收款。電子錢幣具有匿名的特性，在使用上可以保障消費者的隱私與帳戶的安全性；且使用者沒有申請條件的限制，在使用上得成本也較低，適合進行大額與小額的付款。相關的電子錢幣系統包括E-Cash (Chaum, 1982)、CyberCash (Eastlake et al., 1996)、及PayPal (PayPal, 2009)。以上三類安全付費機制在安全與功能上各有其優劣，在實務上，由於需考慮用戶端的軟硬體需求，目前以使用SSL傳遞信用卡號的信用卡付款機制方式最為常見。本論文研究將探討使用信用卡付款機制之安全與效率問題，目前在信用卡的使用上，有一個重大的安全顧慮在於信用卡號外洩造成金錢上的損失，傳統信用卡在網路的使用上，可能會因為信用卡號在反覆使用後被惡意的攻擊者得知而遭遇欺騙行為。為此問題近年來有學者(Shamir, 2001)提出僅使用過一次便失效的一次性信用卡號(One-time Credit Card Transaction Number，簡稱CCT)的方式，以增強信用卡付費的安全強度。一次性的交易信用卡號是指信用卡在使用時，每次都會產生一個新的信用卡號，而這個信用卡號是暫時的，僅能使用一次，且在使用後就失去作用，這樣可以避免真正的信用卡號外流後而產生的犯罪問題。大部分現存的一次性信用卡號架構如American Express Private Payments (American Express, 2007)與SecureClick (Shamir, 2001)，在交易之前需要額外的透過SSL與銀行溝通來產生一次性的信用卡號，大量的使用將對銀行的伺服器造成負擔。Rubin與Wright學者(Rubin and Wright, 2001) 提出一個可以離線產生一次性交易信用卡號的方式，其產生方式需要加密計算，使用上也須需要網頁介面協助。Li與Zhang學者(Li and Zhang, 2005)提出一個使用雜湊計算可離線產生一次性交易信用卡號的方式，其一次性信用卡號是由原信用卡號與只有發卡銀行與持卡人知道的秘密經由多次雜湊計算而得。一個採用此機制的電子交易，必須在成功驗證所使用之一次性信用卡號之合法性後才算完成，由於一次性信用卡號之驗證必須由發卡銀行執行，當客戶在當次交易傳送一次性信用卡號給商家時，商家必須將此卡號傳送至發卡銀行進行驗證。為考量商家的作業與網路限制，卡號傳送銀行之驗證，依驗證之時機分為立即性與延遲性驗證兩種方式，亦即商家在收到客戶的一次性信用卡號後，可立即送至銀行驗證，或於一段時間內(例如24小時內)傳送至銀行驗證即可。Li與Zhang學者所提之一次性信用卡號驗證方式，需做多次的多次雜湊計算，當因延遲驗證時抵達銀行驗證的信用卡號不依照順序時，銀行在信用卡號驗證所需的計算負擔將更為嚴重，為了解決此問題，Li與Hwang在其機制中使用一個可暫時存放一次性信用卡號的驗證佇列，以減緩信用卡號延遲驗證的效率問題。然而，此機制在銀行在信用卡號驗證上仍需多次計算，且銀行容易遭受資源耗盡等惡意攻擊。針對Li與Zhang機制之缺失，本論文提出一個可以改進其驗證效能及避免惡意攻擊的改善方法，並進一步提出一個新的一次性信用卡號產生方式，銀行只需使用一次雜湊計算即可驗證一次性信用卡號，且不需任何驗證佇列，也可有效避免惡意攻擊。貳、Li與Zhang學者之CCT機制2005年Li與Zhang學者(Li and Zhang, 2005)提出使用雜湊函數運算來取代離線式加密產生一次性信用卡號的方法。其產生方式是利用前一次的CCT與晶片卡內的秘密訊息做串接再經過雜湊函數運算後產生。其中秘密訊息為只有發卡銀行與持卡人知道內容的一串數位字串，存放在持卡人手中的實體信用卡片內。在信用卡上嵌有一個晶片可以處理雜湊運算與儲存新的信用卡號。信用卡的晶片與要配合一個讀卡機來讀取，採用的都是簡單、成熟的技術且容易取得的設備。在持卡人這端的操作上，持卡人僅須將晶片信用卡插入讀卡機，然後將新產生的一次性信用卡號傳送給商家即可。傳統的信用卡有一個固定的信用卡號與相關的個人資訊，如持卡人姓名與使用期限。在Li與Zhang的架構中，需要有兩個附加的元素存放在信用卡上的晶片裡面：(1). 一個在晶片內，且不外洩的秘密訊息S。(2). 只供使用一次的信用用卡號Tcur。在發卡銀行發卡時會先產生一組初始的CCT，並且存到信用卡的晶片內，所以銀行方面知道該卡片的秘密訊息與初始的CCT。在交易進行時，一個新的CCT就會由先前一個CCT與秘密訊息經過雜湊函數H( )算出。表示為：。一次性信用卡號所使用相關符號說明如下：實際的信用卡號。一次性信用卡號碼(One-time Credit Card Transaction Number，CCT)。Tcur消費者先前一次交易所使用的信用卡號。消費者將要使用的信用卡號。保存在信用卡晶片內的秘密訊息。發卡銀行的驗證佇列(Verification Queue)。延伸限制(Extending Limit)。阻礙限制(Blocking Limit)。一、發卡銀行驗證架構消費者使用信用卡交易時，商店請求發卡銀行驗證信用卡之時機，包括立即驗證與延遲驗證，分述如下：(1). 立即驗證(Instant Verification)在信用卡交易時，商店立即將一次信用卡號立即傳送至銀行進行驗證，驗證結果立即傳回給商家，完成交易。(2). 延遲驗證(Delayed Verification)為方便交易過程之進行，許多提供使用信用卡交易之電子商務商家，並不會立即將信用卡號送至銀行驗證。由於實際的使用上，商家對於信用卡號的驗證會有延遲的情形，銀行在驗證一次性的信用卡號時，並不是依照卡號產生順序依序驗證，我們以下列例子說明延遲驗證的方式：假設有三個CCT依照時間的順序為，其中產生方式為：, , ，而已經由發卡銀行先驗證過了。若所有的交易是採用立即驗證方式的情境，則發卡銀行就可以依照抵達的順序，簡單的計算雜湊函數來一個一個驗證信用卡號。若有延遲驗證的情形，假設比提早抵達驗證，T2又比T1提早抵達驗證，其順序為，其驗證方法如下：(1). 當抵達時：發卡銀行會先由計算出，其計算方式為，然後比對與。由於驗證出兩者不相等，於是發卡銀行將存放到驗證佇列(Verification Queue)，以便做為將來比對之用。然後，發卡銀行繼續由計算出，其計算方式為，然後比對抵達的CCT與計算出來的CCT。由於驗證出兩者不相等，發卡銀行同樣地將存放到驗證佇列。經過一連串的運算與比對，當發卡銀行由算出，方符合現在抵達的CCT，完成T3之驗證。(2). 當抵達時：發卡銀行會先至中檢查，比對在佇列中是否有與相符的CCT，此時中包含(T1, T2)，可以直接驗證之正確性，並且將裡面驗證過的移除，完成T2之驗證。(3). 當抵達時：發卡銀行會先到中檢查，方法同之驗證。二、驗證演算法圖1顯示Li與Zhang學者所提一次性信用卡號之驗證演算法，初始時，驗證佇列(Verification Queue)裡並無任何CCT(第1-2行)，而第一個CCT是由發卡銀行與持卡人利用真正的信用卡號與晶片內的秘密訊息產生的，並且存放在信用卡鑲嵌的晶片裡。當持卡人產生一筆交易行為，這次的一次性信用卡號就會以前一次的信用卡號來產生，並且送到發卡銀行端來驗證。此演算法指描述單一持卡人的驗證流程。發卡銀行驗證的時候會依序做檢查，在延遲驗證的情境下，先到的CCT會先被驗證，延遲的CCT則會先存放到裡面。稍後抵達的CCT則會先從 中檢查是否有相符的情形(第4行)，若是相符則驗證完畢且從中移除該CCT。另外，若是抵達發卡銀行驗證的是從未檢查過、比較晚的CCT，則不會存放到中，於是發卡銀行在檢查過中沒有相符合的CCT後，便會從現有的CCT往後計算與比對個將來會抵達的CCT。且稱參數為延伸限制(Extending Limit)。若是抵達的CCT符合先前預先計算的個CCT串中的一個，則將目前抵達的那一個CCT之前的CCT串存入中(第7-10行)，供將來驗證使用。Verification Algorithm of Li and Zhangs Method/I. 下列驗證的演算法僅描述一部分驗證佇列。/II. 發卡銀行事先得知秘密訊息S與初始的一次性信用卡號T0。/III. n為延伸限制(見第六行)，m為阻礙限制(見第十二行)。1) current CCT Tcur=T0 /T0為初始的CCT2) verification queue Q= ø /為驗證的消費者初始一個驗證佇列3) foreach arrived CCT T that is to be verified do4) if T matches one CCT in Q then delete it from Q and return CCT verified5) else /若T不符合驗證序列內的CCT6) generate n new CCTs T1,.,Tn where T1=H(Tcur|S),.,Tn=H(Tn-1|S)7) if T matches Tk (1kn)8) TcurTk9) insert CCTs T1,.,Tk-1 into Q10) return CCT verified11) else return CCT not verified12) verification process is blocked if CCTs are not verified m times during certain period of time圖1 Li與Zhang架構之驗證演算法驗證演算法中使用參數與之目的是為了阻擋惡意攻擊，也意謂該架構能夠容忍驗證時的延遲與錯誤情形。因為攻擊者只要傳送任意一個非法偽造的一次性信用卡號，銀行便必須進行多次的雜湊計算與比對。因此，該驗證演算法必須使用參數與來限制驗證次數。假設為無限大時，任何一個隨機的CCT都可能成功的被驗證，若為1時，則該認證架構只能容許延遲驗證的個數為1。假設為無限大時，則攻擊者就可以不斷的測試CCT或是導致隨機產生的CCT意外符合而驗證成功，若為1時，則該驗證機制不能容許任何一次的認證的錯誤。我們可以發現，當使用較大的n與m值時，此驗證機制可以允許商家有較長的延遲時間再行驗證，然而必須承受惡意攻擊之計算負荷；相反地，使用較小的n與m值，雖然可以減輕惡意攻擊之威脅，但會限制忠實消費者合法交易的次數，意即如果消費者因延遲驗證尚未完成交易之次數超過n次時，第n+1次以後之交易將驗證失敗，因此，本論文認為Li與Zhang學者所提之機制及驗證演算法有待改進。參、改良的CCT機制在Li與Zhang的一次性信用卡號架構中，銀行在收到延遲的一次性信用卡號時，由於無法得知該信用卡號是第幾個信用卡號，必須進行多次的嘗試驗證，也因此為了省卻部份重複計算，必須利用驗證佇列(Verification Queue)以維持延遲驗證之效能。此外，在驗證佇列的使用上，也必須配合延伸限制(Extending Limit)與阻礙限制(Blocking Limit)機制之使用，以補救所提架構之缺失。我們認為此架構之使用效率上仍有改善空間，另外當攻擊者使用亂碼偽造信用卡號進行攻擊時，銀行必須花費大量成本進行計算與比對才能確認遭受攻擊，此缺失也有待改進。為此，本論文提出兩個改進一次性信用卡驗證機制，可以有效改善信用卡號驗證效能及防止因惡意攻擊造成銀行的大量計算成本。一、方法A本研究提出第一個改進的作法，沿用先前之架構，由前一個CCT來產生下一個CCT，但在CCT附加一個序號i，指明目前之CCT為該消費者第i次使用的CCT。消費者之信用卡晶片儲存三個資料：(1). 一個不外洩的秘密訊息S。(2). 只供使用一次的信用卡號Tcur。(3). 隨信用卡使用次數遞增的序號i。在發卡銀行發卡時，會先產生一組初始的CCT，並且存到信用卡的晶片內，所以銀行方面知道該卡片的秘密訊息與初始的CCT。在交易進行時，一個新的CCT就會由初始的CCT與秘密訊息經由雜湊函數算出，亦即Tnew = H(Tcur | S)，每次使用一個新的CCT，序號i隨即加1，以記錄CCT的使用次數。消費者進行交易時，將(Tnew, i)送給商家，供其至銀行進行驗證。相關符號說明如下：實際的信用卡號。一次性信用卡號碼One-time Credit Card Transaction Number(CCT)。消費者先前一次交易所使用的信用卡號。消費者將要使用的信用卡號。保存在信用卡晶片內的秘密訊息。發卡銀行的驗證佇列(Verification Queue)。n延伸限制(Extending Limit)。i該新的CCT之序號，指明該CCT是第i個產生的CCT。圖2說明方法A之信用卡驗證方法。在立即驗證(Instant Verification)的情況，與先前的架構一樣，信用卡會立即的被驗證。在延遲驗證(Delayed verification)的情況，我們以以下例子說明驗證方式：假設有四個CCT依照時間的順序為，其中產生方式為：, ，而已經由發卡銀行先驗證過了。若是所有的交易是採用立即驗證方式的情境，則發卡銀行就可以依照抵達的順序，簡單的計算雜湊函數來依照順序逐一驗證信用卡號。假設有延遲驗證的情形， 比提早抵達驗證，T2比T1提早抵達驗證，其順序為，驗證方法如下：(1). 當抵達時：發卡銀行由序號3得知在CCT中的順序，而直接由算至，比對是否相符，若是相符則驗證成功，並且把存入驗證佇列(Verification Queue)，用來做為將來比對之用。(2). 當抵達時：發卡銀行會先到中檢查，比對在驗證佇列中是否有與相符的CCT，此時中包含，於是驗證了，並且將裡面驗證過的移除。(3). 當T1抵達時：發卡銀行會先到Q中檢查，方法同T2。Verification Algorithm of Method A/I. 下列驗證的演算法僅描述一部分驗證佇列。/II. 發卡銀行事先得知秘密訊息S與初始的一次性信用卡號T0。/III. Icur為Tcur的索引，Icur的初始值為0。/IV. 索引i指明該CCT是第i個產生的CCT。1) current CCT Tcur = T0 / T0為初始的CCT2) Icur 03) verification queue Q= ø /為驗證的消費者初始一個驗證佇列4) foreach arrived CCT (T, i) that is to be verified do5) if i = Icur then return CCT not verified /重複使用6) if i > Icur + n then return CCT not verified /超過延伸限制7) if i < Icur8) if T matches one CCT in Q then delete it from Q and return CCT verified9) else return CCT not verified10) else11) generate TIcur+1,., Ti, where T Icur+1=H(Tcur|S),., Ti=H(Ti-1|S) 12) if T matches Ti13) TcurTi14) insert CCTs T Icur+1,.,Ti-1 into Q15) Icur i16) return CCT verified17) else return CCT not verified圖2 方法A之CCT延遲驗證方式方法A利用Icur值，可以迅速判斷待驗證之CCT是否在佇列、超過延伸限制、或待進行驗證計算，可改進Li與Zhang學者架構之執行效率，此外，當遭受惡意攻擊時，方法A至多只須計算n次的雜湊計算，而Li與Zhang學者架構需要nm次。由於方法A較不易遭受攻擊，n值便可以較大，因此可容許的延遲驗證交易次數較多，以實用性的觀點，方法A優於Li與Zhang學者架構。二、方法B由於方法A延用Li與Zhang使用連續雜湊方式產生CCT，仍需有驗證佇列保留已計算但未使用之CCT，以避免重複計算成本。我們提出第二個改進方法，使用新的CCT產生方式，可以大幅改進CCT驗證效率。採用方法B之CCT機制，發卡銀行發卡時於消費者之信用卡晶片儲存三個資料：(1). 一個不外洩的秘密訊息S。(2). 消費者的初始信用卡CCT T0。(3). 隨信用卡使用次數遞增的序號i。只有銀行方面知道該卡片的秘密訊息與初始的CCT。在交易進行時，一個新的CCT就會由初始的CCT、秘密訊息與序號i經過雜湊函式算出。使用序號i的CCT Ti表示為：Ti = H(T0 | S | i), i。每使用一次CCT，序號i便加一，意即序號i必須依序使用，以方便偵測CCT是否被重複使用。圖3顯示方法B的CCT驗證方法，相關符號定義同方法A。使用方法B驗證 CCT時不需使用驗證佇列，只需使用一個串列L用來存放最近使用過之CCT序號。圖3之Imin表示所有序號小於等於Imin之CCT均已使用過。串列L用來儲存大於Imin且已使用過之CCT序號，用來檢查是否有重複使用CCT情形。對於每一個待驗證的CCT: (T, j)，銀行由j的值確認T尚未使用過，且在延伸限制範圍，然後驗證T的正確性，若T確實為合法的CCT，則更新Icur, Imin及L。在正常情況下，CCT依序送達銀行進行驗證時，Imin將等於Icur，串列L將一直維持為空串列。若有延遲驗證情形，待驗證CCT之序號也將被限制在Imin至Icur+n範圍內，L的長度也因此被限制在Icur - Imin內。Verification Algorithm of Method B/I. 下列驗證的演算法僅描述一部分驗證佇列。/II. 發卡銀行事先得知秘密訊息S與初始的一次性信用卡號T0。/III. L 為一個依CCT序號排序之串列1) Imin = 02) Icur = 03) foreach arrived CCT (T, j) that is to be verified do4) if (j Imin) or (j in L) or (j > Icur + n) then5) return CCT not verified6) if T = H(T0 | S | j) then7) if j > Icur then Icur j8) if j = Imin+1 then9) Imin+10) foreach k in L / 依序取出已使用過之CCT序號11) if k = Imin+1 then12) Imin+13) remove k from L14) else continue15) else insert j into ordered list L16) return CCT verified17) else return CCT not verified圖3 方法B之CCT延遲驗證方式試以以下例子說明方法B驗證方式。假設有四個CCT依照時間的順序為，其中產生方式為：, , ，而已經由發卡銀行先驗證過了。若是所有的交易是採用立即驗證方式的情境，則發卡銀行就可以依照抵達的順序，簡單的計算雜湊函數來依照順序逐一驗證信用卡號。當有延遲驗證的情形，假設比還要早抵達驗證，其順序為，其驗證方法如下：(1). 當抵達時：發卡銀行直接由序號3計算出，其計算方式為，然後比對是否相符，相符則驗證成功。此時Imin = 0, Icur = 3, L = 3。(2). 當抵達時：發卡銀行直接由序號2計算出，其計算方式為，然後比對是否相符，相符則驗證成功。此時Imin = 0, Icur = 3, L = 2, 3。(3). 當抵達時：發卡銀行直接由序號1計算出，其計算方式為，然後比對是否相符，相符則驗證成功。此時Imin = 3, Icur = 3, L = 。由於驗證的過程可以由序號i直接算出該CCT，所需計算只有一次雜湊函數，發卡銀行也不須產生多餘的CCT，因此不需要使用驗證佇列(Verification Queue)儲放計算過的CCT。而當有惡意攻擊時，也只須一次雜湊函數計算便可判斷。在實務上，方法B採用n值限制延遲驗證範圍意義不大，因此n值可以是一個很大的值，因為惡意攻擊者很難在此範圍內以猜測方式偽造一個正確的CCT。 因此，方法B對發卡銀行而言，可以省下許多計算負擔，也不用擔心攻擊者對銀行送出假CCT使得發卡銀行為了驗證該筆CCT而花費大量計算，造成無法正常服務的阻斷服務攻擊(Denial of Service)。肆、效能分析一、驗證次數分析當一筆CCT抵達銀行進行驗證時，若銀行的驗證佇列內沒有該筆CCT時，各機制所必須執行的驗證次數是影響系統執行效能最重要的部分，以下針對三個機制之驗證次數分析進行說明。(一)、Li與Zhang方法當某一CCT Tk抵達時，發卡銀行計算n個CCT T1Tn(從Tcur起計算n個連續CCT)，逐筆與待驗證之CCT進行比對，直到與Tk相符為止，並且將1存入驗證佇列，Tk之後至n之間的CCT則拋棄， Tk Tn之間的運算為多餘之運算，如圖4.(1)至圖4.(3)所示。銀行若是收到惡意攻擊者送出假的CCT，Li與Zhang方法必須先找完在驗證佇列之CCT後，並進行次驗證運算才確定為惡意攻擊，如圖4.(4)所示，假設目前Tcur = Tk, 從Tk算起共有n×m次多餘的驗證運算。(二)、方法A當CCT (Ti, i)抵達時，發卡銀行由索引i查出新抵達的Ti是否在驗證佇列裡面，若無則從計算至Ti，並且把 Ti-1存入驗證佇列內，如圖5所示。因此，當(Ti, i)在佇列時，發卡銀行利用i值直接從驗證佇列取出對應的暫存值進行比對即可；當(Ti, i)不在佇列時，方法A則必須從目前第Icur個CCT值開始進行i-Icur次驗證計算以得到正確的Ti值。由於我們至多只允許延伸n個尚未驗證的CCT值，因此i-Icur 之值將小於等於 n。(三)、方法B當CCT (Ti, i)抵達時，CCT (Ti, i)本身所含i值已指出該Ti應如何計算與驗證，發卡銀行直接驗證Ti是否等於H(T0 | S |i)，倘若所送來之CCT為偽造或其他因素造成錯誤，致使驗證Ti失敗(即不相等)，銀行不用再進行任何運算，因此所需驗證次數只有一次。圖4 Li與Zhang方法驗證次數示意圖圖5 方法A驗證次數示意圖二、效能比較本節針對三種方法在CCT使用所需儲存內容、佇列之使用、產生與驗證CCT之雜湊計算次數、以及遭受偽造CCT惡意攻擊時之系統執行效能進行比較，在信用卡晶片上預先需存放內容所佔用儲存空間三者都相同，使用者在開始使用信用卡後，與Li與Zhang方法比較，方法A需多儲存一個索引值i，方法B則只須儲存索引值i，不需儲存最近所使用的信用卡號Tnew。在佇列的使用上，Li與Zhang與方法A都需要佇列，但方法A無須對暫存於佇列CCT進行逐一比對，至於方法B則完全不需要用來儲存CCT的佇列，不過在演算法過程，需要一個序號串列。另外，在一般情況下，驗證CCT所需雜湊計算次數，Li與Zhang方法必須一次產生n組CCT，因此需要n次雜湊計算，方法A則可依據索引值i進行i-Icur次雜湊計算，方法B則只須一次雜湊計算即可得到對應的CCT值。當有偽造CCT的惡意攻擊發生時，Li與Zhang方法由於沒有索引值i輔助資訊，因此必須進行至多nm次雜湊計算才能察覺惡意攻擊，方法A則可依據索引值i至多計算n次(當i=n)雜湊計算可發現惡意攻擊，由於方法B只須一次雜湊計算即可得到對應的CCT值，惡意攻擊者若偽造CCT，可立刻查覺，因此只須一次雜湊計算，茲將以上效能比較數據列於表1。表1 三個CCT機制之效能比較Li與Zhang方法A方法BCCT表示方式, i晶片中存放的內容使用者須儲存之資料,是否需要驗證佇列YesYesNo是否須逐筆搜尋驗證佇列YesNoNo產生CCT之雜湊計算次數1次1次1次驗證CCT之雜湊計算次數ni-Icur1惡意攻擊時雜湊計算次數nmn1總結以上之效能比較分析， Li與Zhang方法需要進入驗證佇列搜尋，且有多餘的運算，無法有效抵禦偽造CCT惡意攻擊。本論文提出的方法A，同樣需要有驗證佇列，但不需要進入驗證佇列中搜尋，所需驗證次數也較少。而方法B既不需要驗證佇列，也可快速驗證，大幅節省了銀行驗證時所需的花費的計算成本。若考量惡意攻擊造成銀行執行效能之影響，更能顯出本論文所提改進機制之優越性。伍、結論隨著電腦普及與網路頻寬的增加，現行的付費系統也延伸到網路環境上。各付費系統皆有其付款機制的特性與適用的環境，透過網路等媒介提供使用者便利性，但隨之而來有了安全與效率的議題。銀行在付費系統中扮演產生票據與驗證票據的功能，在處理大量的交易業務時，計算的效率與資料庫比對的效率顯得非常重要。本論文針對目前最常用的信用卡電子付款架構，提出較具效率且採用一次性的信用卡號方式的信用卡付款機制，除了可以避免一般使用上信用卡號洩漏的問題，另為考量銀行之信用卡驗證效率與安全，於一次性的信用卡號上增加一個方便銀行進行驗證之索引序號，以便在進行延遲驗證時可以省去批次比對的步驟，大幅節省銀行驗證時的計算負擔。此外本論文所提之改良機制，在抵禦惡意攻擊之能力，也因此較為強韌。在較為嚴格的安全需求考量下，本論文在一次性的信用卡號所附加之索引值，可能會洩漏使用者之消費能力或習性之資訊。此安全問題，可以於方法B中讓每位使用者所使用序號i之初始值不同，銀行在發卡時可隨機產生一序號初始值，與信用卡資料一起存於晶片，並將該使用者在驗證機制中對應的Icur設為此值即可。由於每位使用者之一次性信用卡號所使用序號初始值都不同，惡意的竊聽者或商家設法取得序號後，也無法從序號大小取得使用者的消費次數資訊，使用者之信用卡交易得到更進一步的安全保障。 參考文獻American Express, Private Payments locked with smart chip, , 2007.Asokan, N., Janson, P. A., Steiner, M., and Waidner, M., The State of the Art in Electronic Payment Systems, IEEE Computer, 1997, Vol. 30, No. 9, pp. 28-35.Chaum, David, Blind Signatures for Untraceable Payments. CRYPTO 1982, 1982, pp. 199-203.Eastlake 3rd, D., B. Boesch, S. Crocker, and M. Yesil, CyberCash Credit Card Protocol Version 0.8, RFC 1898, Feb. 1996.Freier, Alan O., Philip Karlton, and Paul C. Kocher, The SSL Protocol,