摘? 要： 分析了SET協(xié)議的不足，并提出了相應的改進策略，采用更安全的數(shù)據(jù)傳輸方式保留交易證據(jù)，增強了抗抵賴性。

　　關鍵詞： 電子支付? SET協(xié)議? 安全

?

　　電子支付是電子商務的關鍵環(huán)節(jié)，也是電子商務得以順利發(fā)展的基礎條件。沒有適宜的電子支付手段的配合，電子商務只能是虛擬商務，而無法進行網(wǎng)上交易。如何通過電子支付方式安全公平地完成整個交易，已成為網(wǎng)上交易必須面對的首要問題。SET(Security Electronic Transaction)是當前比較通用的電子交易協(xié)議，因此研究SET協(xié)議對于現(xiàn)在物流行業(yè)與電子商務的發(fā)展具有一定的現(xiàn)實意義。

1? 通用SET協(xié)議的分析

　　當前國內外最典型的支付模型為SET協(xié)議。SET提供對交易參與者的認證，確保交易數(shù)據(jù)的安全性，特別是保證不會將持卡人的賬戶信息泄露給商家。SET模型的工作流程如圖1所示。

?

?

　　(1)用戶在銀行開立信用卡賬戶，獲得信用卡。(2)用戶在商家的Web主頁上查看商品目錄選擇所需商品，填寫定單并通過網(wǎng)絡傳遞給商家，同時附上付款指令，其中定單和付款指令要有用戶的數(shù)字簽名并加密，使商家無法看到用戶的私人賬戶信息。(3)商家收到定單后，向發(fā)卡行請示支付認可；發(fā)卡行確認后，批準交易，并向商家返回確認信息。(4)商家發(fā)送定單確認信息給用戶，并發(fā)貨給用戶。(5)商家請示銀行支付貨款，銀行將貨款由用戶的賬戶轉移到商家的賬戶。

　　SET協(xié)議已成為電子商務中在線支付的一種主要模式，但由于在通用的SET協(xié)議模型中，SET交易復雜，且存在一定的局限性，因此其推廣受到一定的限制。目前SET協(xié)議存在的主要問題如下。

　　(1)SET不支持商品的原子性。(2)SET不支持抗抵賴性。SET協(xié)議沒有解決交易過程中的證據(jù)保留問題，對交易后的數(shù)據(jù)的保存和處理沒有說明。SET協(xié)議僅能做到對支付信息的認證，沒有解決交易中證據(jù)的生成和保留問題，因此不能為交易保留法律性的依據(jù)。當顧客和商家發(fā)生爭議時，缺乏有效說明來劃分責任，無法滿足電子商務協(xié)議的公平性原則。(3)整個交易的流程太復雜，參加認證的實體太多，給程序的設計帶來很大不便。(4)SET協(xié)議中對交易過程沒有作狀態(tài)描述，使顧客或商家對交易的狀態(tài)難以把握。(5)加密算法通常采用的是RSA算法，加密和解密時間復雜度比較大，從而使交易時間過長。(6)關鍵數(shù)據(jù)的傳輸不是很安全。

2?SET協(xié)議改進策略

　　針對SET協(xié)議存在的問題，本文提出了相應的改進策略。改進后的SET協(xié)議模型如圖2所示。在客戶和商戶之間采用了客戶交易代理和商戶交易安全平臺，以保證數(shù)據(jù)的安全傳輸。支付網(wǎng)關是SET交易實體和金融網(wǎng)絡的接口，可以看成是金融網(wǎng)絡的代理，并可以作為誠信的第三方，通過它可以減少交易認證流程的復雜度。

?

?

2.1 客戶交易代理和商戶交易安全平臺

　　電子交易過程中涉及到用戶與商家之間的機密數(shù)據(jù)，如用戶信用卡信息、交易碼等，因此需要解決電子交易過程中的安全問題。在電子交易過程中可采用客戶交易代理和商戶交易安全平臺協(xié)商產(chǎn)生安全通信，保護客戶端與Web服務器間傳輸?shù)臄?shù)據(jù)?？蛻艚灰状碡撠熆蛻舳硕嗣荑€的管理及與服務器端連接的安全性。商戶交易安全平臺負責服務器端密鑰的管理及保證服務器端的安全性?？蛻敉ㄟ^安全通道與商戶建立連接，雙方交換證書，彼此驗證身份，確認身份的真實性、合法性。服務器與客戶端可相互查詢CA證書中心以獲取對方的公開密鑰。假設K11和K12分別代表服務器端公鑰和私鑰，K21和K22分別代表客戶端的公鑰和私鑰。安全通信的建立過程如下。

　　(1)客戶端建立起與服務器端IP與特定Port端口的連接相關聯(lián)的網(wǎng)絡套接字，向服務器申請網(wǎng)絡連接。(2)服務器端偵聽特定端口，檢測發(fā)送方的客戶端是否有建立連接的請求，如有則在服務器端，針對客戶端的發(fā)送套接字構建相應的接收套接字。(3)等待服務器接受連接申請后，客戶端向服務器端發(fā)送一隨機數(shù)R1。(4)服務器端也產(chǎn)生一個隨機數(shù)R2，并用自己的私有密鑰K22對R1、R2加密，得(R1、R2)，傳輸給客戶端。(5)客戶端接收到(R1、R2)后，采用服務器的公開密鑰對其進行解密，將得到的解密結果與原始R1對照，確認服務器端合法性，完成對服務器的認證。同時對R2解密結果使用自己私有密鑰加密得到(R2)，傳輸?shù)椒掌鞫恕?6)服務器采用客戶公開密鑰對(R2)解密并和原始R2對照，完成對客戶端認證。

　　這樣服務器端和客戶端就建立了信任連接，在電子交易過程中采用客戶交易代理和商戶交易安全平臺，實現(xiàn)數(shù)據(jù)安全傳輸。

2.2 改進后SET的流程

　　改進后的SET的工作流程如下。

　　(1)客戶通過安全通道與商戶建立連接，雙方交換證書，彼此驗證身份，確認身份的真實性和合法性。

　　(2)客戶向商戶發(fā)送購買初始請求。傳輸?shù)男畔⒂蒙虘舻墓€加密，用客戶的私鑰做數(shù)字簽名。

　　(3)商戶收到初始請求后，向客戶發(fā)回初始回答信息，其中包括支付網(wǎng)關的公鑰(這是為了客戶發(fā)送支付信息時，不讓商戶看到信用卡的資料)及本次交易的ID、收到初始請求的時間t1。所有的信息用客戶的公鑰加密，并用商戶的私鑰做數(shù)字簽名。

　　(4)客戶看到商戶的回答，分別驗證商戶和支付網(wǎng)關的合法性。核實之后，向商戶發(fā)送購買信息，包括2部分：①給商戶的購買信息，即商品和這次交易的ID(用商戶的公鑰加密，用客戶的私鑰做數(shù)字簽名)。②商戶將轉發(fā)給支付網(wǎng)關的支付信息(用支付網(wǎng)關的公鑰加密，客戶的私鑰做數(shù)字簽名)。

　　(5)商戶收到購買請求后，核實信息的合法性，將客戶的購買信息存到本地數(shù)據(jù)庫，然后同時處理2件事情：①從本地得到接收訂單的時間t2，結合貨物的配送、與支付網(wǎng)關的通信條件，設置到貨的停滯時間t3，向客戶傳送購買回答信息(用客戶的公鑰加密，商戶的私鑰數(shù)字簽名)。②請求授權和轉發(fā)客戶發(fā)送的支付信息給支付網(wǎng)關(用支付網(wǎng)關的公鑰加密，商戶的私鑰數(shù)字簽名)。

　　(6)客戶驗證收到的購買回答信息的合法性，接著客戶交易代理將購買回答信息存到本地數(shù)據(jù)庫。

　　(7)在進行第(6)步的同時，支付網(wǎng)關根據(jù)商戶發(fā)來的信息驗證商戶和客戶的合法身份，然后支付網(wǎng)關向銀行發(fā)出授權請求，證明客戶的信用卡有效。當收到回答后，就向商戶發(fā)出授權回答，其中包括支付的令牌、客戶的支付信息、商戶確認的t2與t3(用商戶公鑰加密，支付網(wǎng)關的私鑰做數(shù)字簽名)，同時將這些信息存到本地數(shù)據(jù)庫，以備核實。

　　(8)商戶收到網(wǎng)關的授權回答后，核實合法性，計算停滯時間是否比原來的t3大。如果是就向客戶發(fā)送消息，說明原因并表示立即送貨(用客戶的公鑰加密，商戶的私鑰數(shù)字簽名)，客戶收到核實后，可以按照上面的時間查收貨物或咨詢商戶。

　　(9)隨后商戶通過支付網(wǎng)關向銀行要求定貨金額轉賬。商戶向網(wǎng)關發(fā)送支付的捕獲請求，包括網(wǎng)關發(fā)來的支付令牌(用支付網(wǎng)關的公鑰加密，商戶的私鑰做數(shù)字簽名)。

　　(10)驗證商戶及支付令牌的合法性，并按照支付的金額向銀行發(fā)出轉賬請求，銀行將金額轉賬到商戶，同時回答支付網(wǎng)關。

　　(11)支付網(wǎng)關給商戶發(fā)送支付捕獲回答(用商戶公鑰加密，支付網(wǎng)關的私鑰做數(shù)字簽名)。

　　(12)商戶收到支付捕獲回答，驗證合法性，存到本地數(shù)據(jù)庫，以備和銀行發(fā)生賬物糾紛時清查。

3?結? 論

　　改進后的SET協(xié)議簡化了交易的復雜度，減少了認證的實體，降低了程序設計人員的工作強度，使SET協(xié)議的實現(xiàn)更加容易。通過安全的客戶交易代理和商業(yè)交易平臺之間特有的安全通信，保障了核心數(shù)據(jù)的安全傳輸；保證了客戶的信用卡信息不被商家看到；保證交易的各方都是合法的實體；保證了各方收到的信息都是完整的；保留了交易的憑證，使公平性得到保障。

參考文獻

1?方美琪.電子商務概論.北京：清華大學出版社，2002

2?王永峰，唐毅.SET協(xié)議的安全性分析及改進.微型電腦應用，2001；17(7)

3 張大陸，李恩民.SET的支付流程分析和改進措施.微型電腦應用，2001；17(8)

4 尹存燕，謝俊元.一個公平、有效的安全電子交易協(xié)議.計算機應用研究，2002；(1)

5?劉文遠，唐杰，鄧玉成等.原子和公平匿名的電子交易協(xié)議的研究.計算機工程與應用，2003；(3)