電子商務(wù)安全協(xié)議及支付安全參考

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

2、議和SSL記錄協(xié)議，其中最重要的兩個協(xié)議是握手協(xié)議和記錄協(xié)議。SSL記錄協(xié)議定義了數(shù)據(jù)傳送的格式，它位于一些可靠的傳輸層協(xié)議之上（如TCP），用于各種更高層協(xié)議的封裝。SSL握手協(xié)議位于SSL記錄協(xié)議之上，并被SSL記錄協(xié)議所封裝。它描述建立安全連接的過程，在客戶和服務(wù)器傳送應(yīng)用層數(shù)據(jù)之前，該協(xié)議允許服務(wù)器與客戶機(jī)之間協(xié)商加密算法和會話密鑰，完成通信雙方的身份驗(yàn)證等功能。應(yīng)用層協(xié)議（HTTP、Telnet、FTP、IMAP等）SSL握手協(xié)議SSL更改密碼規(guī)程協(xié)議SSL報(bào)警協(xié)議SSL記錄協(xié)議TCP協(xié)議IP協(xié)議圖5-1 SSL協(xié)議的分層結(jié)構(gòu)5.1.2 SSL記錄協(xié)議SSL記錄協(xié)議（Record P

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

4、得到TCP數(shù)據(jù)包。MAC數(shù)據(jù) 實(shí)際數(shù)據(jù) 附加數(shù)據(jù)圖5-3 SSL記錄協(xié)議中數(shù)據(jù)項(xiàng)的格式5.1.3 SSL握手協(xié)議客戶機(jī)服務(wù)器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é)

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

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

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

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

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

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

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

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

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

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

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

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

17、(OP)HashRSAKcuH(PI)Sig ( H(OP)H(OP)HashM接收到的數(shù)據(jù)比較圖5-8 雙重簽名驗(yàn)證過程用收到的OI，生成H (OI)將H (OI)與接收到的摘要H (PI)連接生成OP得到OP的摘要H (OP)用C公鑰Kcu解開SignH(OP)，得到H(OP)比較H (OP)與H(OP)是否相同。如果相同，則表示數(shù)據(jù)完整且未被篡改。在交易中持卡人發(fā)往銀行的支付指令是通過商家轉(zhuǎn)發(fā)的，雙重簽名避免了交易的過程中商家竊取持卡人的信用卡信息，也避免了行跟蹤持卡人的行為，侵犯消費(fèi)者隱私；同時還不影響商家和銀行對持卡人所發(fā)信息的合理的驗(yàn)證，以及銀行和商家之間的溝通，保證當(dāng)商家同意持卡

18、人的購買請求后再讓銀行給商家付費(fèi)。5.2.3 SET交易流程SET協(xié)議由一系列請求/響應(yīng)（Req/Res）信息對組成。SET協(xié)議信息結(jié)構(gòu)共有6大部分：認(rèn)證過程、交易初始化過程、購買指令執(zhí)行過程、授權(quán)檢驗(yàn)過程、扣款請求執(zhí)行過程及持卡人查詢過程。SET信息結(jié)構(gòu)中除了認(rèn)證過程以外的其他過程構(gòu)成了一個完成的購買交易流程，如圖5-9所示。下面將介紹持卡人、商家和支付網(wǎng)關(guān)協(xié)同完成交易的具體步驟。持卡人商家交易初始化響應(yīng)PInit Res購買請求PReq購買響應(yīng)PRes授權(quán)請求Auth Req授權(quán)響應(yīng)Auth Res扣款請求Cap Req扣款響應(yīng)Cap Res查詢請求Inq Req*交易初始化請求PInit

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

20、買持卡人發(fā)出請求購買指令的過程為：產(chǎn)生定單信息OI和支付信息PI，PI中包含OI的摘要。 生成OI和PI的雙重簽名。 用隨機(jī)產(chǎn)生的對稱密鑰K1加密PI 和雙重簽名，生成加密的支付信息；再用支付網(wǎng)關(guān)的公鑰加密K1和持卡人的卡號信息，生成支付信封。將OI、雙重簽名、支付信封 、加密的支付信息、PI的摘要和持卡人證書一起發(fā)送給商戶。商戶響應(yīng)購買請求指令的過稱為：驗(yàn)證持卡人證書。驗(yàn)證雙重簽名。將PI送給支付網(wǎng)關(guān)。生成購物響應(yīng)并進(jìn)行簽名。將購物響應(yīng)、商戶簽名和商戶證書傳給持卡人。商戶向支付網(wǎng)關(guān)請求授權(quán)，若授權(quán)成功，商戶通知持卡人。持卡人收到商戶的購物響應(yīng)后：驗(yàn)證商戶證書。驗(yàn)證購物響應(yīng)中的商戶簽名。 保存

21、購物響應(yīng)。3）授權(quán)檢驗(yàn)商戶請求支付網(wǎng)關(guān)授權(quán)的過程為：生成授權(quán)請求，包含交易ID和金額，并對請求進(jìn)行簽名用隨機(jī)產(chǎn)生的對稱密鑰K2對授權(quán)請求進(jìn)行加密，并用支付網(wǎng)關(guān)公鑰將K2加密，生成授權(quán)請求數(shù)字信封。商戶將加密的授權(quán)請求 、持卡人傳來的經(jīng)過加密的支付信息和支付信封、持卡人證書、商戶證書傳給網(wǎng)關(guān)。支付網(wǎng)關(guān)響應(yīng)授權(quán)請求的過程為：驗(yàn)證商戶證書。用私鑰解密授權(quán)請求數(shù)字信封得到K2，再用K2解密授權(quán)請求。驗(yàn)證商戶簽名。驗(yàn)證持卡人證書。用私鑰解密支付信封得到K1，再用K1解密支付信息。驗(yàn)證持卡人的雙重簽名。檢查商戶的授權(quán)請求中的交易ID與PI中的交易ID是否一致。將授權(quán)請求通過金融專網(wǎng)發(fā)送到發(fā)卡行，在銀行內(nèi)部

22、網(wǎng)中查詢持卡人的銀行卡是否有支付能力，如果得到肯定回應(yīng)，則繼續(xù)進(jìn)行下一步。生成授權(quán)響應(yīng)信息并且簽名。用隨機(jī)產(chǎn)生的對稱密鑰K3加密授權(quán)響應(yīng)，用商戶的加密公鑰加密K3生成授權(quán)響應(yīng)信封。產(chǎn)生扣款令牌（Capture Token）并簽名。用隨機(jī)產(chǎn)生的對稱密鑰K4加密扣款令牌，用網(wǎng)關(guān)的加密公鑰加密K4生成扣款令牌信封。將加密的授權(quán)響應(yīng)和授權(quán)響應(yīng)信封、加密扣款令牌和扣款令牌信封，以及支付網(wǎng)關(guān)證書一起傳給商戶。商戶收到授權(quán)響應(yīng)后：驗(yàn)證支付網(wǎng)關(guān)證書。用私鑰解密授權(quán)響應(yīng)信封得到K3，用K3解密授權(quán)響應(yīng)。驗(yàn)證支付網(wǎng)關(guān)對授權(quán)響應(yīng)的簽名。保存加密扣款令牌和扣款令牌信封，以便以后請求扣款時使用。商戶完成購物請求處理，確

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

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

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

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

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

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

29、確認(rèn)收到訂單，同時網(wǎng)商服務(wù)器將用戶的訂單信息和支付信息經(jīng)支付網(wǎng)關(guān)發(fā)送到發(fā)卡銀行?？蛻舳藶g覽器與發(fā)卡銀行網(wǎng)絡(luò)服務(wù)器進(jìn)行安全連接，客戶端自動驗(yàn)證發(fā)卡銀行網(wǎng)絡(luò)服務(wù)器的數(shù)字證書。驗(yàn)證結(jié)束后，SSL握手協(xié)議完成，持卡客戶端與銀行服務(wù)器端之間的安全連接已經(jīng)建立，可以進(jìn)行加密通信。在發(fā)卡銀行的支付界面，會顯示從網(wǎng)商服務(wù)器發(fā)來的訂單信息及支付金額信息，買方在相應(yīng)的欄目填入信用卡的相關(guān)信息，并確認(rèn)支付?？蛻舳耸盏街Ц冻晒π畔ⅲ?jīng)買方確認(rèn)后，SSL安全連接結(jié)束。發(fā)卡銀行發(fā)送付款成功信息給網(wǎng)商，并進(jìn)行轉(zhuǎn)賬結(jié)算。網(wǎng)商收到付款信息后，發(fā)送收款信息給買方，承諾發(fā)貨，買方監(jiān)督訂單執(zhí)行情況，交易結(jié)束。5.3.3第三方支付模式

30、第三方支付中的所謂“第三方”是指在電子商務(wù)交易中除了交易主體和銀行之外的第三種角色，它們通過第三方支付平臺與銀行和交易主體交互，完成資金劃撥。第三方機(jī)構(gòu)與各個主要銀行之間簽訂有關(guān)協(xié)議，可以與銀行進(jìn)行某種形式的數(shù)據(jù)交換和相關(guān)信息確認(rèn)。目前國外最流行的支付第三方支付產(chǎn)品為PayPal。中國國內(nèi)的第三方支付產(chǎn)品主要有支付寶、財(cái)付通、銀聯(lián)電子支付等，其中支付寶和財(cái)付通的市場份額分別為47%和24%?？蛻羯虘翥y行第三方支付平臺支付網(wǎng)關(guān)圖5-15 第三方支付模式示意圖以B2C交易為例，第三方支付的流程如圖5-15所示，具體如下：客戶瀏覽檢索商戶網(wǎng)頁達(dá)成交易意向，在商戶網(wǎng)站下訂單?？蛻暨x擇第三方支付平臺，直

31、接鏈接到其安全支付服務(wù)器上在支付頁面上選擇自己適用的支付方式，點(diǎn)擊后進(jìn)入銀行支付頁面進(jìn)行支付操作，將貨款支付到第三方支付平臺的賬號。第三方支付平臺將網(wǎng)上消費(fèi)者的支付信息，按照各銀行支付網(wǎng)關(guān)的技術(shù)要求，傳遞到各相關(guān)銀行。由相關(guān)銀行（銀聯(lián)）檢查網(wǎng)上消費(fèi)者的支付能力，實(shí)行凍結(jié)、扣帳或劃帳，并將結(jié)果信息傳至第三方支付平臺和網(wǎng)上消費(fèi)者本身。第三方支付平臺將支付結(jié)果通知商戶。支付成功的，由商戶向網(wǎng)上消費(fèi)者發(fā)貨或提供服務(wù)。商家確認(rèn)收到貨，通知第三方支付平臺向商家劃撥貨款。第三方支付平臺與各個銀行交互，將資金劃撥到商戶的第三方支付賬號。 5.3.4 電子現(xiàn)金支付模式電子現(xiàn)金的支付涉及到網(wǎng)商、用戶與電子現(xiàn)金的發(fā)行銀行三個主體，由銀行負(fù)責(zé)身份認(rèn)證和交易雙方之間的資金轉(zhuǎn)移，銀行和賣方之間應(yīng)有協(xié)議和授權(quán)關(guān)系。具體的使用過程