電商安全協(xié)議及支付安全

1、5.1.1 SSL協(xié)議工作原理SSL協(xié)議處于互聯(lián)網(wǎng)多層協(xié)議集的傳輸層上，運行在TCP/IP協(xié)議之上而在其他高層協(xié)議（如HTTP、Telnet、FTP和IMAP等）之下，如圖5-1所示。在建立一次SSL連接之前，首先建立TCP/IP連接。SSL協(xié)議可以讓應用層協(xié)議透明地加以應用。運行時，支持SSL協(xié)議的服務器可以同一個支持SSL協(xié)議的客戶機彼此認證自己，還允許這兩個機器之間建立安全的加密連接，同時保證信息在傳輸過程中的完整性。 SSL協(xié)議可以分為4個子協(xié)議：SSL握手協(xié)議、SSL更改密碼規(guī)程協(xié)議、SSL報警協(xié)議和SSL記錄協(xié)議，其中最重要的兩個協(xié)議是握手協(xié)議和記錄協(xié)議。SSL記錄協(xié)議定義了數(shù)據(jù)傳

2、送的格式，它位于一些可靠的傳輸層協(xié)議之上（如TCP），用于各種更高層協(xié)議的封裝。SSL握手協(xié)議位于SSL記錄協(xié)議之上，并被SSL記錄協(xié)議所封裝。它描述建立安全連接的過程，在客戶和服務器傳送應用層數(shù)據(jù)之前，該協(xié)議允許服務器與客戶機之間協(xié)商加密算法和會話密鑰，完成通信雙方的身份驗證等功能。應用層協(xié)議（HTTP、Telnet、FTP、IMAP等）SSL握手協(xié)議SSL更改密碼規(guī)程協(xié)議SSL報警協(xié)議SSL記錄協(xié)議TCP協(xié)議IP協(xié)議圖5-1 SSL協(xié)議的分層結(jié)構(gòu)5.1.2 SSL記錄協(xié)議SSL記錄協(xié)議（Record Protocol）定義了傳輸?shù)母袷剑ㄓ涗涱^和記錄數(shù)據(jù)格式的規(guī)定。發(fā)送方記錄層的工作過程

3、如圖5-2所示： 分 片添加 MAC壓 縮加 密添加SSL 記錄頭計算MAC圖5-2 記錄層的工作過程1. 記錄層從上層接收到任意大小的應用層數(shù)據(jù)塊，把數(shù)據(jù)快分成不超過214字節(jié)的分片。2. 記錄層用當前的會話狀態(tài)中給出的壓縮算法靜分片壓縮成一個壓縮快，壓縮操作是可選的。3. 每個會話都有相應“加密規(guī)格”指定了對稱加密算法和MAC算法。記錄層用指定的MAC算法對壓縮塊計算MAC，用指定的對稱加密算法加密壓縮塊和MAC，形成密文塊。4. 對密文塊添加SSL記錄頭，然后送到傳輸層，傳輸層受到這個SSL記錄層數(shù)據(jù)單元后，記上TCP報頭，得到TCP數(shù)據(jù)包。MAC數(shù)據(jù) 實際數(shù)據(jù) 附加數(shù)據(jù)圖5-3 SSL

4、記錄協(xié)議中數(shù)據(jù)項的格式5.1.3 SSL握手協(xié)議客戶機服務器server_hellocertificateserver_key_exchange*certificate_request*hello_donecertificate_verifyclient_key_exchangeCertificate*change_cipher_specfinishedcertificate_verify*finishedchange_cipher_specclient_hellono_certificate*Step1：確定一些相關(guān)參數(shù)，包括協(xié)議版本、會話ID、加密規(guī)格、壓縮算法和初始隨機數(shù)Step2：服務

5、器端發(fā)送自身證書（或臨時公鑰）及證書請求，最后發(fā)送hello階段結(jié)束信號。Step3：客戶端驗證服務器端證書、發(fā)送自身證書、交換對稱密鑰。Step4：雙方確定加密規(guī)格，結(jié)束握手協(xié)議。圖5-4 SSL建立新會話時的握手過程1）建立新會話時的握手過程握手協(xié)議用于數(shù)據(jù)傳輸之前。它可以進行服務器與客戶之間的身份鑒別，同時通過服務器和客戶協(xié)商，決定采用的協(xié)議版本、加密算法，并確定加密數(shù)據(jù)所需的對稱密鑰，隨后采用公鑰加密技術(shù)產(chǎn)生共享機密信息（例如對稱密鑰）。每次連接，握手協(xié)議都要建立一個會話。會話中包含了一套可在多次會話中使用的加密安全參數(shù)，從而減輕了每次建立會話的負擔。然而，必須指出的是，SSL中的每次

6、連接時，在握手協(xié)議中產(chǎn)生的對稱密鑰都是獨特的，這種每次更換密鑰的方法顯然在更大程度上確保了系統(tǒng)的不易攻破性。根據(jù)是否驗證對方的證書，SSL的握手過程可以分為以下三種驗證模式：客戶和服務器都被驗證；只驗證客戶機，不驗證服務器，這是Internet上使用最廣泛的形式；客戶和服務器都不驗證，也稱為完全匿名模式。SSL握手協(xié)議建立一個新的會話的過程如圖5-4所示，具體如下：階段1：確定一些相關(guān)參數(shù)，包括協(xié)議版本、會話ID、加密規(guī)格、壓縮算法和初始隨機數(shù)（1） 客戶端發(fā)送client_hello消息給服務器，向服務器傳送客戶端支持的SSL協(xié)議的版本號、加密算法的種類、MAC算法的種類、會話標識、密碼屬性

7、（如hash塊的大?。约捌渌掌骱涂蛻舳酥g通信所需要的各種信息。（2） 服務器以server_hello向客戶應答，服務器端傳選定的SSL協(xié)議的版本號、加密算法的種類、MAC算法的種類、密碼屬性及其他相關(guān)信息。階段2：服務器端發(fā)送自身證書（或臨時公鑰）及證書請求，最后發(fā)送hello階段結(jié)束信號。（3） 如果需要驗證服務器，服務器將發(fā)送certificate消息。服務器首先建立一個隨機數(shù)，然后對這個隨機數(shù)進行數(shù)字簽名，將這個含有簽名的隨機數(shù)和服務器的證書，放在certificate消息中發(fā)送給客戶端。若不需要驗證服務器證書，服務器發(fā)送包含其臨時公鑰的server_key_exchange

8、消息。（4） 若服務器需要驗證客戶，則發(fā)送certificate_request消息（5） 服務器發(fā)送hello_done消息，表示雙方握手過程中的hello階段結(jié)束。階段3：客戶端驗證服務器端證書、發(fā)送自身證書、交換對稱密鑰。（6） 客戶利用服務器傳過來的信息驗證服務器的合法性，發(fā)送certificate_verify消息，確定驗證通過。服務器的合法性包括：證書是否過期，發(fā)行服務器證書的CA是否可靠，發(fā)行者證書的公鑰能否正確解開服務器證書的“發(fā)行者的數(shù)字簽名”，服務器證書上的域名是否和服務器的實際域名相匹配。如果合法性驗證沒有通過，通信將斷開；如果合法性驗證通過，則將繼續(xù)進行下一步。（7）

9、客戶端先隨機產(chǎn)生一個用于后面通信的預主密碼（pre-master-key），然后用服務器的公鑰（從服務器的證書中獲得）對其加密，再將加密后的預主密碼通過client_key_exchange消息傳給服務器。（8） 如果服務器要求客戶的身份認證（在握手過程中為可選），客戶端會首先建立一個隨機數(shù)，然后對這個隨機數(shù)進行數(shù)字簽名，將這個含有簽名的隨機數(shù)和客戶自己的證書放在certificate消息中，發(fā)送給服務器端。如果客戶端沒有證書，則會回應no_certificate告警。階段4：雙方確定加密規(guī)格，結(jié)束握手協(xié)議。（9） 客戶端向服務器端發(fā)出chenge_cipher_spec信息，指明后面的數(shù)據(jù)通

10、信將“預主密碼”為對稱密鑰，同時向服務器發(fā)送finished消息，表示完成了與服務器的握手。（10） 服務器檢驗客戶證書和簽名隨機數(shù)的合法性，發(fā)送certificate_verify消息。具體的合法性驗證包括：客戶的證書使用日期是否有效，為客戶提供證書的CA是否可靠，發(fā)行CA的公鑰能否正確解開客戶證書的發(fā)行CA的數(shù)字簽名，檢查客戶的證書是否在證書撤銷列表（CRL）中。檢驗如果沒有通過，則通信立刻中斷；如果驗證通過，則服務器將用自己的私鑰解開加密的“預主密碼”，然后執(zhí)行一系列步驟來產(chǎn)生通信使用的主密碼（master-key）（客戶端也將通過同樣的方法產(chǎn)生相同的主密碼）。（11） 服務器向客戶端發(fā)

11、出change_cipher_spec信息，指明后面的數(shù)據(jù)通信將使用預主密碼為對稱密鑰，同時發(fā)送finished消息，通知客戶端服務器端的握手過程結(jié)束。（12） SSL的握手部分結(jié)束，SSL安全通道的數(shù)據(jù)通信開始，客戶和服務器開始使用相同的對稱密鑰進行數(shù)據(jù)通信，同時進行通信完整性的檢驗。2）恢復一個已存在會話時的握手過程由上可以看出，SSL協(xié)議的握手過程是非常好使的，為了減少握手過程的交互次數(shù)，以及對網(wǎng)絡帶寬的占用，可將雙方經(jīng)過完整握手過程建立起來的會話狀態(tài)記錄下來。在以后連接時，采用會話重用技術(shù)恢復會話過程，免去會話參數(shù)的協(xié)商。SSL握手協(xié)議恢復一個已存在的會話的過程如圖5-5所示。客戶端發(fā)

12、送client_hello消息給服務器，其中的session id是要恢復的會話的標識，服務器在會話緩存中檢查是否有這個會話標識：若有，服務器將在相應的會話狀態(tài)下建立一個新的連接，服務器發(fā)送含有session id的server_hello；若沒有，服務器會生成一個新的session id，建立一個新的會話過程。當通過恢復一個會話建立一個連接時，這個新的連接將繼承這個會話狀態(tài)下的壓縮算法、加密規(guī)格和預主密碼。但該連接會產(chǎn)生新的隨機數(shù)和通信密碼?？蛻魴C服務器change_cipher_specfinishedfinishedchange_cipher_specserver_helloclient

13、_helloStep2：更改加密規(guī)格，結(jié)束握手協(xié)議Step1：從會話緩存中恢復一個已經(jīng)存在的對話圖5-5 SSL恢復一個已存在會話時的握手過程5.1.4 SSL協(xié)議的缺陷根據(jù)以上內(nèi)容可知，SSL協(xié)議所采用的加密算法和認證算法使它具有一定的安全性，能夠在一定程度上抵抗某些攻擊。 除此之外SSL協(xié)議具備很強的靈活性，在瀏覽器中大都建有SSL功能。但是SSL協(xié)議也有很多缺陷，具體如下：（1）密鑰管理問題設計一個安全秘密的密鑰交換協(xié)議是很復雜的，因此，SSL握手協(xié)議中客戶機和服務器在互相發(fā)送自己能夠支持的加密算法時，是以明文傳送的，存在被攻擊修改的可能。（2）加密強度問題服務器證書分為高端和低端兩種，

14、高端證書加密強度比低端證書高。SSL通信中具體達到的加密強度與客戶操作系統(tǒng)、瀏覽器版本、網(wǎng)絡服務器的所采用的證書等因素相關(guān)。如許多客戶的系統(tǒng)不支持128位強度的加密鏈接，即便服務器證書可以支持128位，客戶端也自動降低加密強度，除非他采用了支持SCG技術(shù)的服務器證書（強制型），方可實現(xiàn)128位加密強度。因此，客戶機的性能將會影響到SSL的安全性。（3）數(shù)字簽名問題SSL協(xié)議對握手之后的通信內(nèi)容沒有數(shù)字簽名功能，即沒有抗否認服務。若要增加數(shù)字簽名功能，則需要在協(xié)議中打“補丁”。這樣做，在用于加密密鑰的同時又用于數(shù)字簽名，這在安全上存在漏洞。后來PKI體系完善了這種措施，即雙密鑰機制，將加密密鑰和

15、數(shù)字簽名密鑰二者分開，成為雙證書機制。這是PKI完整的安全服務體系。（4）必須建立在可靠連接基礎(chǔ)上SSL協(xié)議的底層協(xié)議僅限于TCP協(xié)議。由于SSL要求有TCP通道，所以對于使用UDP協(xié)議的DNS類型的應用場合是不適合的。（5）多方通信表現(xiàn)欠佳由于SSL的連接本質(zhì)上是一對一的，所以在通信方只有兩個的情況下它會工作的很好。在多對多的環(huán)境中，它的表現(xiàn)欠佳。 5. 2 SET協(xié)議5.2.2 雙重簽名雙重簽名是SET協(xié)議中的一個重要技術(shù)。生成雙重簽名的流程如圖5-7所示。假設持卡人為C，商家為M，銀行支付網(wǎng)關(guān)為B，則雙重簽名的生成過程如下：OIPIH(OI)H(PI)OPSig ( H(OP)H(OP)

16、HashHashRSAKcp圖5-7 雙重簽名生成過程（1） 產(chǎn)生發(fā)訂購信息OI（Order Information）和支付指令PI（Payment Information）。（2） 產(chǎn)生OI、PI的摘要H(OI)，H(PI)。（3） 連接H(OI)和H(PI)得到OP，（4） 生成OP的摘要H(OP)，（5） 用C的RSA私鑰Kcp簽名H(OP)，得到signH(OP)，稱為雙重簽名。通過一系列交互和加解密過程，M將獲得的數(shù)據(jù)包括OI、H(P1)和signH(OP)，B將獲得的數(shù)據(jù)包括PI、H(OI)和signH(OP) 。下面以M為例，介紹驗證雙重簽名的過程。C驗證雙重簽名的過程與此相似，

17、不再贅述。M驗證雙重簽名的過程如圖5-8所示，具體如下：OIH (OI)OPH(OP)HashRSAKcuH(PI)Sig ( H(OP)H(OP)HashM接收到的數(shù)據(jù)比較圖5-8 雙重簽名驗證過程（1） 用收到的OI，生成H (OI)（2） 將H (OI)與接收到的摘要H (PI)連接生成OP（3） 得到OP的摘要H (OP)（4） 用C公鑰Kcu解開SignH(OP)，得到H(OP)（5） 比較H (OP)與H(OP)是否相同。如果相同，則表示數(shù)據(jù)完整且未被篡改。在交易中持卡人發(fā)往銀行的支付指令是通過商家轉(zhuǎn)發(fā)的，雙重簽名避免了交易的過程中商家竊取持卡人的信用卡信息，也避免了行跟蹤持卡人的

18、行為，侵犯消費者隱私；同時還不影響商家和銀行對持卡人所發(fā)信息的合理的驗證，以及銀行和商家之間的溝通，保證當商家同意持卡人的購買請求后再讓銀行給商家付費。5.2.3 SET交易流程SET協(xié)議由一系列請求/響應（Req/Res）信息對組成。SET協(xié)議信息結(jié)構(gòu)共有6大部分：認證過程、交易初始化過程、購買指令執(zhí)行過程、授權(quán)檢驗過程、扣款請求執(zhí)行過程及持卡人查詢過程。SET信息結(jié)構(gòu)中除了認證過程以外的其他過程構(gòu)成了一個完成的購買交易流程，如圖5-9所示。下面將介紹持卡人、商家和支付網(wǎng)關(guān)協(xié)同完成交易的具體步驟。持卡人商家交易初始化響應PInit Res購買請求PReq購買響應PRes授權(quán)請求Auth Re

19、q授權(quán)響應Auth Res扣款請求Cap Req扣款響應Cap Res查詢請求Inq Req*交易初始化請求PInit Req查詢響應Inq RPs*支付網(wǎng)關(guān)圖5-9 SET協(xié)議交易流程1)交易初始化初始化請求的步驟為：（1） 持卡人選擇SET支付方式時，商戶軟件喚醒持卡人的電子錢包。（2） 持卡人向商家發(fā)送初始請求。初始請求指定了交易環(huán)境，包括交易卡類型、持卡人所使用的語言、交易所在地識別碼等（3） 對出示請求進行簽名（4） 將簽名的初始化請求和持卡人證書發(fā)送給商戶初始化響應步驟為：（5） 商家收到初始請求后產(chǎn)生交易ID。（6） 商家對包括交易ID在內(nèi)的響應信息進行運算，生成消息摘要，對此消

20、息摘要進行數(shù)字簽名（7） 將交易識別碼、數(shù)字簽名、商家證書和支付網(wǎng)關(guān)證書等發(fā)送給持卡人。 持卡人收到初始化響應后：（8） 驗證商戶證書和網(wǎng)關(guān)證書。（9） 驗證商戶的簽名。（10） 保存初始化響應2）購買持卡人發(fā)出請求購買指令的過程為：（1） 產(chǎn)生定單信息OI和支付信息PI，PI中包含OI的摘要。 （2） 生成OI和PI的雙重簽名。 （3） 用隨機產(chǎn)生的對稱密鑰K1加密PI 和雙重簽名，生成加密的支付信息；再用支付網(wǎng)關(guān)的公鑰加密K1和持卡人的卡號信息，生成支付信封。（4） 將OI、雙重簽名、支付信封 、加密的支付信息、PI的摘要和持卡人證書一起發(fā)送給商戶。商戶響應購買請求指令的過稱為：（5） 驗

21、證持卡人證書。（6） 驗證雙重簽名。（7） 將PI送給支付網(wǎng)關(guān)。（8） 生成購物響應并進行簽名。（9） 將購物響應、商戶簽名和商戶證書傳給持卡人。（10） 商戶向支付網(wǎng)關(guān)請求授權(quán)，若授權(quán)成功，商戶通知持卡人。持卡人收到商戶的購物響應后：（11） 驗證商戶證書。（12） 驗證購物響應中的商戶簽名。 （13） 保存購物響應。3）授權(quán)檢驗商戶請求支付網(wǎng)關(guān)授權(quán)的過程為：（1） 生成授權(quán)請求，包含交易ID和金額，并對請求進行簽名（2） 用隨機產(chǎn)生的對稱密鑰K2對授權(quán)請求進行加密，并用支付網(wǎng)關(guān)公鑰將K2加密，生成授權(quán)請求數(shù)字信封。（3） 商戶將加密的授權(quán)請求 、持卡人傳來的經(jīng)過加密的支付信息和支付信封、持

22、卡人證書、商戶證書傳給網(wǎng)關(guān)。支付網(wǎng)關(guān)響應授權(quán)請求的過程為：（4） 驗證商戶證書。（5） 用私鑰解密授權(quán)請求數(shù)字信封得到K2，再用K2解密授權(quán)請求。（6） 驗證商戶簽名。（7） 驗證持卡人證書。（8） 用私鑰解密支付信封得到K1，再用K1解密支付信息。（9） 驗證持卡人的雙重簽名。（10） 檢查商戶的授權(quán)請求中的交易ID與PI中的交易ID是否一致。（11） 將授權(quán)請求通過金融專網(wǎng)發(fā)送到發(fā)卡行，在銀行內(nèi)部網(wǎng)中查詢持卡人的銀行卡是否有支付能力，如果得到肯定回應，則繼續(xù)進行下一步。（12） 生成授權(quán)響應信息并且簽名。（13） 用隨機產(chǎn)生的對稱密鑰K3加密授權(quán)響應，用商戶的加密公鑰加密K3生成授權(quán)響應信

23、封。（14） 產(chǎn)生扣款令牌（Capture Token）并簽名。（15） 用隨機產(chǎn)生的對稱密鑰K4加密扣款令牌，用網(wǎng)關(guān)的加密公鑰加密K4生成扣款令牌信封。（16） 將加密的授權(quán)響應和授權(quán)響應信封、加密扣款令牌和扣款令牌信封，以及支付網(wǎng)關(guān)證書一起傳給商戶。商戶收到授權(quán)響應后：（17） 驗證支付網(wǎng)關(guān)證書。（18） 用私鑰解密授權(quán)響應信封得到K3，用K3解密授權(quán)響應。（19） 驗證支付網(wǎng)關(guān)對授權(quán)響應的簽名。（20） 保存加密扣款令牌和扣款令牌信封，以便以后請求扣款時使用。（21） 商戶完成購物請求處理，確定交易成功，產(chǎn)生交易完成信息。4）扣款商戶請求扣款的過程為：（1） 商戶產(chǎn)生扣款請求，并對扣款請

24、求簽名。（2） 用隨機產(chǎn)生的對稱密鑰K5加密扣款請求，用支付網(wǎng)關(guān)公鑰加密K5，得到扣款請求信封。（3） 將加密的扣款請求和扣款請求信封、加密的扣款令牌和扣款令牌信封、商戶證書一起發(fā)送給網(wǎng)關(guān)。網(wǎng)關(guān)響應扣款請求的過程為：（4） 驗證商戶證書。（5） 用網(wǎng)關(guān)私鑰解密加密的扣款請求信封得到K5，再用K5解密扣款請求。（6） 驗證扣款請求的商戶簽名。（7） 用網(wǎng)關(guān)私鑰解密扣款令牌信封得到K4，再用K4解密扣款令牌。（8） 比較扣款請求和扣款令牌。（9） 將扣款請求通過金融專網(wǎng)發(fā)送到發(fā)卡行，有銀行內(nèi)部網(wǎng)完成扣款操作。（10） 生成扣款響應信息并且簽名。（11） 用隨機產(chǎn)生的對稱密鑰K6加密扣款響應，再用商

25、戶公鑰加密K6生成扣款響應信封。（12） 將加密的扣款響應和扣款響應信封、網(wǎng)關(guān)證書一起傳給商戶。商戶收到網(wǎng)關(guān)的扣款響應后：（13） 驗證網(wǎng)關(guān)證書。（14） 用商戶加密私鑰解密扣款響應信封得到K6，用K6解密扣款響應。（15） 驗證網(wǎng)關(guān)簽名，確定扣款已完成。5）持卡人查詢過程查詢信息對允許持卡人核對交易狀態(tài)，查詢可以在購物之后的任何時間進行。持卡人只能查詢有關(guān)自己的購物交易情況；對一筆交易，可查詢多次。持卡人查詢不是必須的，具體執(zhí)行過程為：（1） 持卡人生成查詢請求并簽名，連同持卡人證書一起發(fā)送到商戶。查詢請求消息中包括交易ID。（2） 商戶收到查詢請求后，先驗證消息是否來自持卡人，然后生成查詢

26、響應信息并簽名，同商戶證書一起送回。查詢響應消息包括交易狀態(tài)、結(jié)果碼、是否已付款等。收到查詢響應后，持卡人就知道了某交易是否已由商戶認可，以及處理情況。5.2.4 SET協(xié)議的優(yōu)勢和劣勢1）SET的優(yōu)勢（1）認證機制方面，SET的安全需求較高，所有參與SET交易的成員都必須先申請數(shù)字證書來識別身份。（2）對客戶而言，SET保證了商家的合法性，并且用戶的信用卡號不會被竊取。SET替客戶保守了更多的秘密使其在線購物更加輕松。（3）SET協(xié)議規(guī)定，交易過程中的每條消息都要經(jīng)過嚴格檢驗，從而能更嚴密地保證交易安全。（4）實際應用中，SET可以被用在系統(tǒng)的一部分或者全部。大多數(shù)SET軟件提供商在其產(chǎn)品中

27、都提供了靈活構(gòu)筑系統(tǒng)的手段。2）SET協(xié)議的缺陷（1）SET交易過程不能保證客戶付款后一定得到商品，以及得到的商品是否是自己訂購的。由于協(xié)議中采用的是款到后付貨，一旦出現(xiàn)客戶對商家提供的商品不滿意，或是商品質(zhì)量有問題時，不能保證客戶的利益。（2）SET沒有解決交易中證據(jù)的生成和保留問題。SET技術(shù)規(guī)范沒有提及在事務處理完成后，如何安全地保存或銷毀支付數(shù)據(jù)。商家雖然無法獲得客戶的賬戶信息，但是他保留有經(jīng)過加密的客戶信息，這種漏洞可能會使這些數(shù)據(jù)以后受到潛在的攻擊，仍存在著安全隱患，容易引起客戶不放心。（3）SET協(xié)議非常復雜，成本很高，處理速度慢，沒有對時間進行控制，可能會出現(xiàn)由于時間的延誤而導

28、致的糾紛。SET交易過程中，需要多次傳遞證書、驗證證書、進行簽名、驗證簽名，多次進行對稱加密、生成數(shù)字信封、拆封數(shù)字信封、解密對稱密文，整個交易過程要花費較長時間。（4）SET要求在銀行網(wǎng)絡、商戶服務器、顧客的PC機上安裝相應的軟件，這給顧客、商家和銀行增加了許多附加的費用，成為SET被廣泛接受的障礙。SET要求必須向各方發(fā)放證書，也會增加更多成本。SET協(xié)議機制過于復雜，成本過高，以至于到現(xiàn)在還沒有得到市場的認可。目前，我國各大商業(yè)銀行的網(wǎng)銀均采用了SSL協(xié)議保證支付安全。中國銀行在1996年開通網(wǎng)銀業(yè)務時，曾經(jīng)采用IBM公司開發(fā)的基于SET協(xié)議的電子商務解決方案，但目前已經(jīng)回歸主流，采用了

29、SSL協(xié)議。5.3.2銀行卡安全支付模式銀行卡網(wǎng)上安全支付大多在基于SSL協(xié)議的環(huán)境下完成，在這個過程中，參與交易與支付的網(wǎng)商和銀行需持有由CA認證中心頒發(fā)的數(shù)字證書，持卡人的數(shù)字證書不是必須的。支付過程遵守SSL協(xié)議的安全通信與控制機制，通過SSL協(xié)議實現(xiàn)信用卡信息和支付金額信息等安全在線傳輸，最終通過互聯(lián)網(wǎng)完成交易支付和資金的劃撥。支付流程如圖5-11所示。認證認證認證銀行專用網(wǎng)互聯(lián)網(wǎng)訂貨、收款信息用戶CA認證中心網(wǎng)商收單銀行支付網(wǎng)關(guān)信用卡、授權(quán)支付信息發(fā)卡銀行圖5-11 基于SSL協(xié)議的銀行卡支付流程（1） 持卡用戶瀏覽網(wǎng)商的網(wǎng)頁，選購商品和服務，填寫訂單。（2） 買方確認訂單信息和資金

30、金額，將訂單提交給商家服務器，并選擇信用卡支付。（3） 網(wǎng)商服務器向買方回復確認收到訂單，同時網(wǎng)商服務器將用戶的訂單信息和支付信息經(jīng)支付網(wǎng)關(guān)發(fā)送到發(fā)卡銀行。（4） 客戶端瀏覽器與發(fā)卡銀行網(wǎng)絡服務器進行安全連接，客戶端自動驗證發(fā)卡銀行網(wǎng)絡服務器的數(shù)字證書。（5） 驗證結(jié)束后，SSL握手協(xié)議完成，持卡客戶端與銀行服務器端之間的安全連接已經(jīng)建立，可以進行加密通信。（6） 在發(fā)卡銀行的支付界面，會顯示從網(wǎng)商服務器發(fā)來的訂單信息及支付金額信息，買方在相應的欄目填入信用卡的相關(guān)信息，并確認支付。（7） 客戶端收到支付成功信息，經(jīng)買方確認后，SSL安全連接結(jié)束。（8） 發(fā)卡銀行發(fā)送付款成功信息給網(wǎng)商，并進行

31、轉(zhuǎn)賬結(jié)算。（9） 網(wǎng)商收到付款信息后，發(fā)送收款信息給買方，承諾發(fā)貨，買方監(jiān)督訂單執(zhí)行情況，交易結(jié)束。5.3.3第三方支付模式第三方支付中的所謂“第三方”是指在電子商務交易中除了交易主體和銀行之外的第三種角色，它們通過第三方支付平臺與銀行和交易主體交互，完成資金劃撥。第三方機構(gòu)與各個主要銀行之間簽訂有關(guān)協(xié)議，可以與銀行進行某種形式的數(shù)據(jù)交換和相關(guān)信息確認。目前國外最流行的支付第三方支付產(chǎn)品為PayPal。中國國內(nèi)的第三方支付產(chǎn)品主要有支付寶、財付通、銀聯(lián)電子支付等，其中支付寶和財付通的市場份額分別為47%和24%?？蛻羯虘翥y行第三方支付平臺支付網(wǎng)關(guān)圖5-15 第三方支付模式示意圖以B2C交易為例

32、，第三方支付的流程如圖5-15所示，具體如下：（1） 客戶瀏覽檢索商戶網(wǎng)頁達成交易意向，在商戶網(wǎng)站下訂單。（2） 客戶選擇第三方支付平臺，直接鏈接到其安全支付服務器上（3） 在支付頁面上選擇自己適用的支付方式，點擊后進入銀行支付頁面進行支付操作，將貨款支付到第三方支付平臺的賬號。（4） 第三方支付平臺將網(wǎng)上消費者的支付信息，按照各銀行支付網(wǎng)關(guān)的技術(shù)要求，傳遞到各相關(guān)銀行。（5） 由相關(guān)銀行（銀聯(lián)）檢查網(wǎng)上消費者的支付能力，實行凍結(jié)、扣帳或劃帳，并將結(jié)果信息傳至第三方支付平臺和網(wǎng)上消費者本身。（6） 第三方支付平臺將支付結(jié)果通知商戶。（7） 支付成功的，由商戶向網(wǎng)上消費者發(fā)貨或提供服務。（8） 商家確認收到貨，通知第三方支付平臺向商家劃撥貨款。（9） 第三方支付平臺與各個銀行交互，將資金劃撥到商戶的第三方支付