電子商務(wù)安全：第7章 電子商務(wù)安全協(xié)議

第六章電子商務(wù)安全協(xié)議目錄1安全協(xié)議概述2SSL協(xié)議4其他安全協(xié)議3SET協(xié)議安全協(xié)議概述電子商務(wù)安全協(xié)議是完成信息安全交換的共同約定的邏輯操作規(guī)則，是保證網(wǎng)上交易的機密性、數(shù)據(jù)完整性、身份的合法性和抗否認(rèn)性的重要技術(shù)，協(xié)議是否完備成為它能否提供安全保障的關(guān)鍵。安全協(xié)議在電子支付中主要解決交易各方之間的安全通道問題，包括交易各方之間的相互確認(rèn)、信息傳送的可靠性與完整性等。安全協(xié)議中的角色：協(xié)議參與者、攻擊者(或稱敵手)、可信第三方協(xié)議參與者認(rèn)證協(xié)議：發(fā)起者/響應(yīng)者簽名協(xié)議：簽名申請者/簽署人/驗證人零知識證明：證明者/驗證者電子商務(wù)協(xié)議：商家/銀行/用戶攻擊者(或稱敵手)內(nèi)部攻擊者/外部攻擊者被動攻擊者/主動攻擊者SSL協(xié)議SSL概述1994年Netscape開發(fā)了SSL(SecureSocketLayer)安全套接層協(xié)議，專門用于保護(hù)Web通訊版本和歷史1.0，不成熟2.0，基本上解決了Web通訊的安全問題Microsoft公司發(fā)布了PCT(PrivateCommunicationTechnology)，并在IE中支持3.0，1996年發(fā)布，增加了一些算法，修改了一些缺陷TLS1.0(TransportLayerSecurity傳輸層安全協(xié)議,也被稱為SSL3.1)，1997年IETF發(fā)布了Draft，同時，Microsoft宣布放棄PCT，與Netscape一起支持TLS1.01999年，發(fā)布RFC2246(TheTLSProtocolv1.0)SSL協(xié)議的優(yōu)點在于它是與應(yīng)用層協(xié)議無關(guān)的。高層的應(yīng)用協(xié)議（如HTTP、FTP、Telnet等）能透明地建立于SSL協(xié)議之上。SSL協(xié)議在應(yīng)用層協(xié)議之前就已經(jīng)完成加密算法、通信密鑰的協(xié)商以及服務(wù)器的認(rèn)證工作。在此之后應(yīng)用層協(xié)議所傳送的數(shù)據(jù)都會被加密，從而保證通信的安全性。SSL解決的問題客戶對服務(wù)器的身份認(rèn)證SSL服務(wù)器允許客戶的瀏覽器使用標(biāo)準(zhǔn)的公鑰加密技術(shù)和一些可靠的認(rèn)證中心（CA）的證書，來確認(rèn)服務(wù)器的合法性。服務(wù)器對客戶的身份認(rèn)證也可通過公鑰技術(shù)和證書進(jìn)行認(rèn)證，也可通過用戶名，password來認(rèn)證。建立服務(wù)器與客戶之間安全的數(shù)據(jù)通道SSL要求客戶與服務(wù)器之間的所有發(fā)送的數(shù)據(jù)都被發(fā)送端加密、接收端解密，同時還檢查數(shù)據(jù)的完整性。SSL提供的安全服務(wù)用戶和服務(wù)器的合法性認(rèn)證usingX.509v3digitalcertificates傳輸數(shù)據(jù)的機密性usingoneofDES,TripleDES,IDEA,RC2,RC4,…傳輸數(shù)據(jù)的完整性usingMACwithMD5orSHA-1SSL工作過程SSL協(xié)議實現(xiàn)的六步驟

⑴接通階段：客戶機通過網(wǎng)絡(luò)向服務(wù)器打招呼，服務(wù)器回應(yīng)；⑵密碼交換階段：客戶機與服務(wù)器之間交換雙方認(rèn)可的密碼，一般選用RSA密碼算法；

⑶會談密碼階段：客戶機器與服務(wù)器間產(chǎn)生彼此交談的會談密碼；⑷檢驗階段：客戶機檢驗服務(wù)器取得的密碼；⑸客戶認(rèn)證階段：服務(wù)器驗證客戶機的可信度；⑹結(jié)束階段：客戶機與服務(wù)器之間相互交換結(jié)束的信息。SSL協(xié)議與電子商務(wù)SSL提供了用于啟動TCP/IP連接的安全性“信號交換”。這種信號交換導(dǎo)致客戶和服務(wù)器同意將使用的安全性級別，并履行連接的任何身份驗證要求。通過數(shù)字簽名和數(shù)字證書可實現(xiàn)瀏覽器和Web服務(wù)器雙方的身份驗證。在用數(shù)字證書對雙方的身份驗證后，雙方就可以用保密密鑰進(jìn)行安全的會話了。

SSL證書保障在線服務(wù)器的安全服務(wù)器身份驗證——防假冒網(wǎng)絡(luò)信息發(fā)送內(nèi)容加密——防偷窺網(wǎng)絡(luò)信息發(fā)送完整性檢測——防刪節(jié)網(wǎng)絡(luò)信息發(fā)送內(nèi)容修改提醒——防篡改SSL當(dāng)初并不是為支持電子商務(wù)而設(shè)計的，所以在電子商務(wù)系統(tǒng)的應(yīng)用中還存在很多弊端:SSL是一個面向連接的協(xié)議，在涉及多方的電子交易中，只能提供交易中客戶與服務(wù)器間的雙方認(rèn)證，而電子商務(wù)往往是客戶、網(wǎng)站、銀行三家協(xié)作完成,SSL協(xié)議并不能協(xié)調(diào)各方間的安全傳輸和信任關(guān)系；購貨時客戶要輸入通信地址，這樣將可能使得客戶收到大量垃圾信件。SSL協(xié)議運行的基點是商家對客戶信息保密的承諾。但在上述流程中SSL協(xié)議有利于商家而不利于客戶。客戶的信息首先傳到商家，商家閱讀后再傳到銀行，這樣，客戶資料的安全性便受到威脅。隨著電子商務(wù)參與方的迅速增加，認(rèn)證問題越來越突出，SSL協(xié)議的缺點完全暴露出來。SSL協(xié)議逐漸被新的SET協(xié)議所取代。目前我國開發(fā)的電子支付系統(tǒng)，無論是中國銀行的長城卡電子支付系統(tǒng)，還是上海長途電信局的網(wǎng)上支付系統(tǒng)，均沒有采用SSL協(xié)議，主要原因就是無法保證客戶資金的安全性。SSL協(xié)議安全性分析安全機制分析⑴鑒別機制。 公開密鑰技術(shù)和數(shù)字證書可以實現(xiàn)客戶端和服務(wù)器端的身份鑒別。ClientHello和ServerHello發(fā)過去自己的證書(里面包含了身份和自己的公鑰)。⑵加密機制。

混合密碼體制的使用提供了會話和數(shù)據(jù)傳輸?shù)募用苄员Ｗo(hù)。雙方使用非對稱密碼體制協(xié)商出本次將要使用的會話密鑰，并選擇一種對稱加密算法。⑶完整性機制。

定義了共享的、可以用來形成報文鑒別碼MAC的密鑰。數(shù)據(jù)進(jìn)行分片壓縮后，使用單向散列函數(shù)產(chǎn)生一個MAC，加密后置于數(shù)據(jù)包的后部，并且再一次和數(shù)據(jù)一起被加密,然后加上SSL首部進(jìn)行網(wǎng)絡(luò)傳輸。 這樣，如果數(shù)據(jù)被修改，其散列值就無法和原來的MAC相匹配，從而保證了數(shù)據(jù)的完整性。⑷抗重放攻擊。 SSL使用序列號來保護(hù)通信方免受報文重放攻擊。這個序列號被加密后作為數(shù)據(jù)包的負(fù)載。 在整個SSL握手中，都有一個唯一的隨機數(shù)來標(biāo)記這個SSL握手，這樣重放便無機可乘。脆弱性分析1.客戶端假冒因為SSL協(xié)議設(shè)計初衷是對Web站點及網(wǎng)上交易進(jìn)行安全性保護(hù)，使消費者明白正在和誰進(jìn)行交易要比使商家知道誰正在付費更為重要，為了不致于由于安全協(xié)議的使用而導(dǎo)致網(wǎng)絡(luò)性能大幅下降，SSL協(xié)議并不是默認(rèn)地要求進(jìn)行客戶鑒別，這樣做雖然有悖于安全策略，但卻促進(jìn)了SSL的廣泛應(yīng)用。針對這個問題，可在必要的時候配置SSL協(xié)議，使其選擇對客戶端進(jìn)行認(rèn)證鑒別。2.SSL協(xié)議無法提供基于UDP應(yīng)用的安全保護(hù)SSL協(xié)議需要在握手之前建立TCP連接，因此不能對UDP應(yīng)用進(jìn)行保護(hù)。如果要兼顧UDP協(xié)議層之上的安全保護(hù)，可以采用IP層的安全解決方案。3.SSL協(xié)議不能對抗通信流量分析由于SSL只對應(yīng)用數(shù)據(jù)進(jìn)行保護(hù)，數(shù)據(jù)包的IP頭和TCP頭仍然暴露在外，通過檢查沒有加密的IP源和目的地址以及TCP端口號或者檢查通信數(shù)據(jù)量，一個通信分析者依然可以揭示哪一方在使用什么服務(wù)，有時甚至揭露商業(yè)或私人關(guān)系的秘密。4.進(jìn)程中主密鑰泄漏除非SSL的工程實現(xiàn)大部分駐留在硬件中，否則主密鑰將會存留在主機的主存儲器中，這就意味著任何可以讀取SSL進(jìn)程存儲空間的攻擊者都能讀取主密鑰，因此，不可能面對掌握機器管理特權(quán)的攻擊者而保護(hù)SSL連接，這個問題要依靠用戶管理策略來解決。5.磁盤上的臨時文件可能遭受攻擊對于使用虛擬內(nèi)存的操作系統(tǒng)，不可避免地有些敏感數(shù)據(jù)甚至主密鑰都交換到存盤上，可采取內(nèi)存加鎖和及時刪除磁盤臨時文件等措施來降低風(fēng)險。

6.對證書的攻擊和竊取類似Verisign之類的公共CA機構(gòu)并不總是可靠的，系統(tǒng)管理員經(jīng)常犯的錯誤是過于信任這樣的公共CA機構(gòu)。因為對于用戶的證書，公共CA機構(gòu)可能不像對網(wǎng)站數(shù)字證書那樣重視和關(guān)心其準(zhǔn)確性。

SSL協(xié)議流程商家需要與銀行的支付網(wǎng)關(guān)建立連接；（1）商家需要在該銀行開通網(wǎng)上銀行，并申請支付網(wǎng)關(guān)證書，商家網(wǎng)銀證書。網(wǎng)關(guān)證書用于商家向支付網(wǎng)關(guān)發(fā)送加密信息。網(wǎng)銀證書用于商家發(fā)送簽名消息。（2）由銀行方提供接口，即訂單的報文格式等。商家按照對應(yīng)的接口開發(fā)調(diào)試網(wǎng)站程序，與銀行網(wǎng)關(guān)直連。（3）銀行與商家之間協(xié)商一種加密算法，對訂單信息進(jìn)行加密處理?？蛻暨M(jìn)行支付的業(yè)務(wù)流程（1）客戶在商家網(wǎng)站選購某些商品并選擇一家銀行實施網(wǎng)上支付，商家網(wǎng)站的支付網(wǎng)關(guān)接口會產(chǎn)生一個報文M（訂單號、金額、商家號、商家返回地址、交易日期）。然后自動調(diào)轉(zhuǎn)到客戶選擇的銀行網(wǎng)關(guān)，同時將這些信息加密后發(fā)送給銀行網(wǎng)關(guān)。（2）支付網(wǎng)關(guān)會將報文M中的關(guān)鍵字段如訂單號、金額、商家名、交易日期等回顯在客戶端，客戶確認(rèn)無誤后，登錄到銀行網(wǎng)站進(jìn)行支付。SSL仍然不失為一套全面完善的安全策略中有效的組成元素。然而，與網(wǎng)絡(luò)安全的其它工具軟件一樣，僅使用單一的防護(hù)軟件都是遠(yuǎn)遠(yuǎn)不夠的。對SSL的過高評價有可能帶來高的安全風(fēng)險，它僅僅是網(wǎng)絡(luò)安全工具的一種，必須和其它網(wǎng)絡(luò)安全工具緊密結(jié)合，方能構(gòu)造出全面、完善、安全可靠的網(wǎng)絡(luò)。SET協(xié)議SET協(xié)議(SecureElectronicTransaction，安全電子交易)是由VISA和MasterCard兩大信用卡公司聯(lián)合推出的規(guī)范。。SET主要是為了解決用戶、商家和銀行之間通過信用卡支付的交易而設(shè)計的，以保證支付命令的機密、支付過程的完整、商戶及持卡人的合法身份，以及可操作性。SET中的核心技術(shù)主要有公開密鑰加密、數(shù)字簽名、數(shù)字信封、數(shù)字安全證書等。比SSL協(xié)議復(fù)雜，因為前者不僅加密兩個端點間的單個會話，它還可以加密和認(rèn)定三方間的多個信息SET協(xié)議概述SET是在開放網(wǎng)絡(luò)環(huán)境中的卡支付安全協(xié)議，它采用公鑰密碼體制(PKI)和X.509電子證書標(biāo)準(zhǔn)，通過相應(yīng)軟件、電子證書、數(shù)字簽名和加密技術(shù)能在電子交易環(huán)節(jié)上提供更大的信任度、更完整的交易信息、更高的安全性和更少受欺詐的可能性。SET協(xié)議用以支持B-C這種類型的電子商務(wù)模式，即消費者持卡在網(wǎng)上購物與交易的模式。

SET在保留對客戶信用卡認(rèn)證的前提下，又增加了對商家身份的認(rèn)證，這對于需要支付貨幣的交易來講是至關(guān)重要的。SET協(xié)議得到了IBM、HP、Microsoft、VeriFone、GTE、Verisign等許多大公司的支持，已成為事實上的工業(yè)標(biāo)準(zhǔn)。目前，它已獲得了IETF標(biāo)準(zhǔn)的認(rèn)可。SET協(xié)議的發(fā)展1996年2月，MarsterCard和Visa國際信用卡組織與技術(shù)合作伙伴GTE、Netcape、IBM、TerisaSystems、Verisign、Microsoft、SAIC等一批跨國公司共同開發(fā)了安全電子交易規(guī)范(SET)。1997年2月，由MasterCard和Visa發(fā)起成立SETCO公司.SETCO建設(shè)認(rèn)證體系(CA)。為了推動電子商務(wù)的發(fā)展，首先要驗證或識別參與網(wǎng)上交易活動的各個主體(如持卡消費者、商戶、收單銀行的支付網(wǎng)關(guān))的身份，并用相應(yīng)的電子證書代表他們的身份。各級認(rèn)證機構(gòu)根認(rèn)證機構(gòu)(RootCA)、品牌認(rèn)證機構(gòu)(BrandCA)，持卡人商戶收單行支付網(wǎng)關(guān)認(rèn)證機構(gòu)(HolderCardCAorMerchantCAorPaymentGatewayCA)由上而下按層次結(jié)構(gòu)建立的SET協(xié)議的功能及其重要特征SET協(xié)議是信用卡在因特網(wǎng)上進(jìn)行支付的一種開放式安全協(xié)議和格式.解決持卡人、商家和銀行之間通過信用卡來進(jìn)行網(wǎng)上支付的交易，旨在保證支付命令的機密性、支付過程的完整性、商家以及持卡人身份的合法性以及可操作性。SET協(xié)議分為三個階段：第一階段為購買請求階段，持卡人與商家確定所用支付方式的細(xì)節(jié)；第二階段是支付的認(rèn)定階段，商家與銀行核實，隨著交易的進(jìn)行，他們將得到支付；第三階段為受款階段，商家向銀行出示所有交易的細(xì)節(jié)，然后銀行以適當(dāng)方式轉(zhuǎn)移貨款。工作流程1）消費者利用自己的PC機通過因特網(wǎng)選定所要購買的物品，并在計算機上輸入訂貨單、訂貨單上需包括在線商店、購買物品名稱及數(shù)量、交貨時間及地點等相關(guān)信息。2）通過電子商務(wù)服務(wù)器與有關(guān)在線商店聯(lián)系，在線商店作出應(yīng)答，告訴消費者所填訂貨單的貨物單價、應(yīng)付款數(shù)、交貨方式等信息是否準(zhǔn)確，是否有變化。3）消費者選擇付款方式，確認(rèn)訂單簽發(fā)付款指令。此時SET開始介入。4）在SET中，消費者必須對訂單和付款指令進(jìn)行數(shù)字簽名，同時利用雙重簽名技術(shù)保證商家看不到消費者的帳號信息。5）在線商店接受訂單后，向消費者所在銀行請求支付認(rèn)可。信息通過支付網(wǎng)關(guān)到收單銀行，再到電子貨幣發(fā)行公司確認(rèn)。批準(zhǔn)交易后，返回確認(rèn)信息給在線商店。6）在線商店發(fā)送訂單確認(rèn)信息給消費者。消費者端軟件可記錄交易日志，以備將來查詢。7）在線商店發(fā)送貨物或提供服務(wù)并通知收單銀行將錢從消費者的帳號轉(zhuǎn)移到商店帳號，或通知發(fā)卡銀行請求支付。SET一個基于可信的第三方認(rèn)證中心的方案，主要目標(biāo)是:

⑴保證信息在互聯(lián)網(wǎng)上安全傳輸，防止數(shù)據(jù)被黑客或被內(nèi)部人員竊取。⑵保證電子商務(wù)參與者信息的相互隔離?？蛻舻馁Y料加密或打包后通過商家到達(dá)銀行，但是商家不能看到客戶的賬戶和密碼信息。⑶解決多方認(rèn)證問題。不僅要對消費者的信用卡認(rèn)證，而且要對在線商店的信譽程度認(rèn)證，同時還有消費者、在線商店與銀行間的認(rèn)證。⑷保證網(wǎng)上交易的實時性，使所有的支付過程都是在線的。⑸效仿EDI貿(mào)易的形式，規(guī)范協(xié)議和消息格式，促使不同廠家開發(fā)的軟件具有兼容性和互操作功能，并且可以運行在不同的硬件和操作系統(tǒng)平臺上。完成安全性的電子交易的過程消費者開立賬戶。首先消費者要在有支持電子支付及SET的銀行建立信用卡賬戶，比如MasterCard或Visa。消費者收到證書。銀行簽署的X.509v3數(shù)位證書。這個證書用來核對消費者的RSA公開密鑰及密鑰的有效期限。同時，也建立了消費者的密鑰組與信用卡之間的關(guān)系，并由銀行來保證這個關(guān)系。特約商店證書。接受某家公司的信用卡的特約商店必須擁有兩個證書，分別包含一把公開密鑰：一個用來簽署信息，一個是用在密鑰交換。特約商店也要保留一份支付網(wǎng)關(guān)的公開密鑰證書。消費者訂購。特約商店核對。除了訂購單，特約商店會發(fā)送它們的證書副本，而消費者可以核對所消費的商店是否為合法有效的。發(fā)送訂單及支付。消費者將其訂單、支付命令與其證書傳送給特約商店。這份訂單對所支付的款項進(jìn)行核對。支付中會包含了信用卡的細(xì)節(jié)。因此支付的信息要經(jīng)過加密，才不會被特約商店獲取其中的重要信息。而消費者的證書可以讓特約商店核對消費者身份。特約商店請求支付認(rèn)證。特約商店在這個時候會向支付網(wǎng)關(guān)傳送支付命令，并且請求核對消費者的信用卡是否能支付這筆款項。特約商店核準(zhǔn)訂單。特約商店將核準(zhǔn)的訂單信息傳送給消費者。特約商店提供其貨物或服務(wù)。將消費者訂購的商品裝運，或提供給消費者其它服務(wù)。特約商店請求支付。商店將請求支付的消息送到支付網(wǎng)關(guān)，支付網(wǎng)關(guān)會處理支付工作。SET協(xié)議采用的加密和認(rèn)證技術(shù)SET使用多種密鑰技術(shù)來達(dá)到安全交易的要求，其中對稱密鑰技術(shù)、公鑰加密技術(shù)和Hash算法是其核心。綜合應(yīng)用以上三種技術(shù)產(chǎn)生了數(shù)字簽名、數(shù)字信封、數(shù)字證書等加密與認(rèn)證技術(shù)。⑴對稱密鑰加密SET協(xié)議缺省使用由IBM公司制定的DES（DataEncryptionStandard）標(biāo)準(zhǔn)。DES將數(shù)據(jù)分割成64位的數(shù)據(jù)塊，用56位的密鑰對其進(jìn)行一系列的數(shù)學(xué)變換后產(chǎn)生密文，然后接收者用同一密鑰將密文解譯成明文。對稱密鑰加密的優(yōu)點時加密、解密效率高，適用于大數(shù)據(jù)量加密與解密。其缺點是密鑰沒有安全的傳遞方式，容易被截獲，不能適應(yīng)大范圍應(yīng)用。⑵公鑰加密技術(shù)缺點是加密與解密速度慢，比DES算法慢10倍以上。所以它只適用于少量數(shù)據(jù)的加密和用于對稱密鑰的傳遞。RSA的密鑰長度可從512bit至2048bit。SET中使用1024bit、2048bit兩種長度，以滿足不同等級的加密要求。⑶Hash算法Hash算法并不是加密算法，但卻能產(chǎn)生信息的數(shù)字“指紋”，主要用途是為了確保數(shù)據(jù)沒有被篡改或發(fā)生變化，以維護(hù)數(shù)據(jù)的完整性。Hash算法有三個特征：能處理任意大小的信息，并生成固定長度（160bit）的信息摘要。具有不可預(yù)見性。信息摘要的大小與原信息的大小沒有任何聯(lián)系。原信息的一個微小變化都會對信息摘要產(chǎn)生很大的影響。具有不可逆性。沒有辦法通過信息摘要直接恢復(fù)原信息。SET使用SHA1安全Hash算法。⑷數(shù)字簽名A用其私鑰加密文件，這便是簽字過程;A將加密的文件送到B;B用A的公鑰解開A送來的文件;簽名方法是符合可靠性原則的。即：簽字是可以被確認(rèn)的簽字是無法被偽造的簽字是無法重復(fù)使用的文件被簽字以后是無法被篡改的簽字具有不可否認(rèn)性

將數(shù)字摘要和數(shù)字簽名結(jié)合明文AliceBobA的私鑰HiBobAliceA的公鑰

摘要哈希函數(shù)gJ39vzamp4xOurjj9rRr%9$數(shù)字簽名HiBobAlice明文Ourjj9rRr%9$數(shù)字簽名HiBobAlice明文gJ39vzamp4x新摘要哈希函數(shù)gJ39vzamp4x=？相同1、沒有篡改2、是Alice發(fā)送的1234567⑸數(shù)字信封技術(shù)

王先生要買李小姐的一處房產(chǎn)，他發(fā)給李小姐一個購買報價單及對他對銀行的授權(quán)書的消息，要求銀行如果李小姐同意按此價格出賣，則將錢劃到李小姐的帳上。但是王先生不想讓銀行看到報價，也不想讓李小姐看到他的銀行帳號信息。此外，報價和支付是相連的、不可分割的，僅當(dāng)李小姐同意他的報價，錢才會轉(zhuǎn)移。首先生成兩條消息的摘要，將兩個摘要連接起來，生成一個新的摘要（稱為雙重簽名），然后用簽發(fā)者的私有密鑰加密，為了讓接收者驗證雙重簽名，還必須將另外一條消息的摘要一塊傳過去。這樣，任何一個消息的接收者都可以通過以下方法驗證消息的真實性：生成消息摘要，將它和另外一個消息摘要連接起來，生成新的摘要，如果它與解密后的雙重簽名相等，就可以確定消息是真實的。因此，如果李小姐同意，它發(fā)一個消息給銀行表示她同意，另外包括報價單的消息摘要，銀行能驗證王先生授權(quán)的真實性，用張先生的授權(quán)書生成的摘要和李小姐消息中的報價單的摘要驗證雙重簽名。銀行根據(jù)雙重簽名可以判定報價單的真實性，但卻看不到報價單的內(nèi)容。SET的交易流程持卡人注冊（Cardholderregistration）：持卡人必須在發(fā)送SET信息給特約商店之前向CA注冊。特約商店注冊（Merchantregistration）：特約商店必須在它們和消費者與支付網(wǎng)關(guān)交換SET信息之前，向CA申請注冊。購買請求（Purchaserequest）：從消費者送出給特約商店的消息，包含給特約商店的OI與給銀行的PI。支付授權(quán)（Paymentauthorization）：在特約商店與支付網(wǎng)關(guān)之間的交換，可以對特定賬戶信用卡持卡人的采購做授權(quán)。支付獲得（Paymentcapture）：讓特約商店可以從支付網(wǎng)關(guān)請求支支付項。證書詢問與狀態(tài)（Certificateinquiryandstatus）：如果CA無法快速完成一個證書請求的處理，它會發(fā)送一個消息給持卡人或特約商店，表明要請求者稍后再做確認(rèn)。而持卡人或特約商店會發(fā)送證書詢問的消息，來確定證書請求的狀態(tài)，如果請求得到批準(zhǔn)就會接收到證書了。采購詢問（Purchaseinquiry）：采購響應(yīng)消息收到后，持卡人可以詢問訂單處理狀態(tài)。記錄回復(fù)（Capturereversal）：特約商店可以更正在取得請求消息中的錯誤，如銷售員輸入錯誤的交易數(shù)量。購買請求在購買請求之前，持卡人已經(jīng)完成瀏覽選定商品以及訂購的工作。這些工作都還沒有使用到SET協(xié)議。購買請求過程，由四個消息構(gòu)成：初始請求、初始回應(yīng)、購買請求、購買回應(yīng)。為了傳送SET消息到特約商店，持卡人必須要保留一份特約商店及支付網(wǎng)關(guān)的證書副本。消費者在初始請求的消息中要求申請證書，然后這個消息會送到特約商店。這個消息包括消費者所使用的信用卡的公司，也包含了由消費者指定的回應(yīng)這組請求的一個ID。支付網(wǎng)關(guān)則需要執(zhí)行以下工作：

⑴核對所有的證書⑵將授權(quán)區(qū)塊的數(shù)字信封解密，得到對稱密鑰，然后就可以對授權(quán)區(qū)塊解密了⑶核對授權(quán)區(qū)塊中的特約商店簽名⑷對支付區(qū)塊的數(shù)字信封解密，得到對稱密鑰后，可以再將支付區(qū)塊解密⑸核對支付區(qū)塊中的雙重簽名⑹核對從特約商店接收到的交易ID，是否和從消費者接收到的PI內(nèi)交易ID吻合⑺向發(fā)卡銀行請求并接受授權(quán)SET協(xié)議的安全性分析在ISO/IEC10181系列中闡述了開放式信息系統(tǒng)的安全架構(gòu)標(biāo)準(zhǔn)，共包含七個部分：鑒別、訪問控制、抗抵賴性、機密性、完整性、安全跟蹤與告警以及密鑰管理等服務(wù);訪問及安全跟蹤告警兩部份牽涉到企業(yè)安全政策與組織架構(gòu)的程度較深，SET并沒有針對它們給應(yīng)用系統(tǒng)開發(fā)人員提出系統(tǒng)的指導(dǎo)原則；關(guān)于密鑰管理的部分，SET協(xié)議也沒有說明該如何處理，也就是說，目前SET將上述三個部份留給應(yīng)用系統(tǒng)開發(fā)人員自行處理。⑴鑒別安全SET的鑒別工作必須依賴公開密鑰的運作體系（publickeyinfrastructure，PKI），使得系統(tǒng)是否能實際運作必須依賴整體大環(huán)境是否成熟而定，例如簽證體系的建立等，這將導(dǎo)致系統(tǒng)建設(shè)成本的大幅提升。⑵完整性安全SET協(xié)議使用數(shù)字簽名與哈希函數(shù)技術(shù)來達(dá)成完整性的要求，運作方式為發(fā)送方先將交易信息經(jīng)過哈希函數(shù)的計算產(chǎn)生消息摘要后，再使用發(fā)送方的私鑰加密產(chǎn)生簽名。SET使用的哈希函數(shù)算法是SHA-1，其產(chǎn)生的消息摘要長度為160位，而只要更改消息中任一個位，平均來說，將導(dǎo)致一半的消息摘要位改變，故可提升簽名的安全性。⑶機密性安全SET協(xié)議采用了對稱性與非對稱性的密碼系統(tǒng)。每一次交易雙方建立新的連接就是一次通信期間的開始，而每次通信期間都會產(chǎn)生新的通信密鑰，也就是說每個通信密鑰的有效期為通信期間，而這個期間通常都不長；基于這些特性，相對于長期間都使用同一把密鑰加密來說，就算某次的通信密鑰遭到破解，也不會影響到其它交易數(shù)據(jù)的安全性。⑷抗抵賴性SET協(xié)議可以利用數(shù)字簽名技術(shù)來產(chǎn)生不可否認(rèn)的證據(jù)，其中雙重簽名也隱含了這個功能。基于銀行對于商店不信任的假設(shè)，銀行可利用商店轉(zhuǎn)交持卡人的支付信息以及請求授權(quán)信息，來防止商店否認(rèn)交易內(nèi)容。⑸隱私權(quán)的安全保護(hù)SET協(xié)議為了提供消費者隱私權(quán)的保護(hù)，使用了一個重要的創(chuàng)新技術(shù)──雙重簽名SET協(xié)議是從銀行的角度來考慮，所以對于隱私的保護(hù)是建立在信任銀行的假設(shè)上。事實上，銀行可能匯集持卡人個別交易的支付信息，如果缺乏適當(dāng)?shù)姆婪洞胧?，將?dǎo)致持卡人隱私泄露的風(fēng)險。SET標(biāo)準(zhǔn)的應(yīng)用與局限性SET1.0版自1997年推出以來推廣應(yīng)用較慢，沒有達(dá)到預(yù)期的效果。最大的挑戰(zhàn)在于定期進(jìn)行網(wǎng)上購物的消費者極少，原因主要是SET協(xié)議為了保證安全性而犧牲了簡便性、操作過于復(fù)雜、成本較高、具有較大競爭力的SSL協(xié)議的廣泛應(yīng)用以及部分經(jīng)濟發(fā)達(dá)國家的法律規(guī)定了持卡人承擔(dān)較低的信用卡風(fēng)險等。SET協(xié)議提供了多層次安全保障，復(fù)雜程度顯著增加；這些安全環(huán)節(jié)在一定程度上增加了交易的復(fù)雜性。另外，SET協(xié)議目前只局限于銀行卡的網(wǎng)上支付，對其他方式的支付沒有給出很好的解決方案。SET協(xié)議只支持B2C模式的電子商務(wù)，而不支持目前最具有前途和影響力的B2B電子商務(wù)交易。SET由于其高度的安全性和規(guī)范性，使其逐步發(fā)展成為目前安全電子支付的國際標(biāo)準(zhǔn)。SSL與SET協(xié)議的比較項目SSL協(xié)議SET協(xié)議工作層次傳輸層與應(yīng)用層之間應(yīng)用層是否透明透明不透明過程簡單復(fù)雜效率高低安全性商家掌握消費者消費者對商家保密認(rèn)證機制雙方認(rèn)證多方認(rèn)證是否專為EC設(shè)計否是⑴協(xié)議層次和功能SSL屬于傳輸層的安全技術(shù)規(guī)范，它不具備電子商務(wù)的商務(wù)性、協(xié)調(diào)性和集成性功能。SET協(xié)議位于應(yīng)用層，它不僅規(guī)范了整個商務(wù)活動的流程，而且制定了嚴(yán)格的加密和認(rèn)證標(biāo)準(zhǔn)，具備商務(wù)性、協(xié)調(diào)性和集成性功能。SSL可以很好地封裝應(yīng)用層數(shù)據(jù)，不用改變位于應(yīng)用層的應(yīng)用程序，對用戶是透明的。同時，SSL只需要通過一次“握手”過程就可以建立客戶與服務(wù)器之間的一條安全通信通道，保證傳輸數(shù)據(jù)的安全。但是，SSL并不是專為支持電子商務(wù)而設(shè)計的，只支持雙方認(rèn)證，商家完全掌握消費者的賬戶信息。SET協(xié)議位于應(yīng)用層，其認(rèn)證體系十分完善，可以實現(xiàn)多方認(rèn)證，SET中消費者賬戶信息對商家來說是保密的。但是SET協(xié)議十分復(fù)雜，交易數(shù)據(jù)需要進(jìn)行多次驗證，用到多個密鑰以及多次加密解密，規(guī)范了整個商務(wù)活動的流程，從持卡人到商家，到支付網(wǎng)關(guān)，到認(rèn)證中心及信用卡結(jié)算中心之間的信息流走向及必須采用的加密、認(rèn)證都制定了嚴(yán)密的標(biāo)準(zhǔn)，從而最大限度地保證了商務(wù)性、服務(wù)性、協(xié)調(diào)性和集成性。⑵安全性SET協(xié)議由于采用了公鑰加密、信息摘要和數(shù)字簽名可以確保信息的保密性、可鑒別性、完整性和不可否認(rèn)性，且SET協(xié)議采用了雙重簽名來保證各參與方信息的相互隔離SSL協(xié)議雖也采用了公鑰加密、信息摘要和MAC檢測，可以提供保密性、完整性和一定程度的身份鑒別功能，但缺乏一套完整的認(rèn)證體系，不能提供完備的防抵賴功能。⑶處理速度SET協(xié)議非常復(fù)雜、龐大，處理速度慢。一個典型的SET交易過程需驗證電子證書9次、驗證數(shù)字簽名6次、傳遞證書7次、進(jìn)行5次簽名、4次對稱加密和4次非對稱加密，整個交易過程可能需花費1.5至2分鐘；而SSL協(xié)議則簡單得多，處理速度比SET協(xié)議快。⑷用戶接口SSL協(xié)議已被瀏覽器和WEB服務(wù)器內(nèi)置，無需安裝專門軟件；而SET協(xié)議中客戶端需安裝專門的電子錢包軟件，在商家服務(wù)器和銀行網(wǎng)絡(luò)上也需安裝相應(yīng)的軟件。⑸認(rèn)證要求早期的SSL協(xié)議并沒有提供身份認(rèn)證機制，雖然在SSL3.0中可以通過數(shù)字簽名和數(shù)字證書實現(xiàn)瀏覽器和Web服務(wù)器之間的身份驗證，但仍不能實現(xiàn)多方認(rèn)證，而且SSL中只有商家服務(wù)器的認(rèn)證是必須的，客戶端認(rèn)證則是可選的。SET協(xié)議的認(rèn)證要求較高