電子金融與支付第8章-SSL及SET

第八講：SSL及SET協(xié)議1.SSL工作原理2．SSL協(xié)議3．SSL協(xié)議的平安性分析4.SET協(xié)議什么是協(xié)議?雙方或多方共同協(xié)商達(dá)成的規(guī)定,各方需共同遵守執(zhí)行!日常生活中：合同網(wǎng)頁傳輸：HTTP文件傳輸：FTP數(shù)據(jù)傳輸：TCP/IPSSL和SET協(xié)議是目前最常使用的,用于保證電子商務(wù)網(wǎng)絡(luò)支付的平安交易協(xié)議。規(guī)定了在完成網(wǎng)絡(luò)支付時所需要的技術(shù)和操作流程，從而保證了平安，有序，快速完成網(wǎng)上支付。OSI網(wǎng)絡(luò)結(jié)構(gòu)的七層模型IPHTTPSSL提供路由和尋址的功能，使兩終端系統(tǒng)能夠互連負(fù)責(zé)總體的數(shù)據(jù)傳輸和數(shù)據(jù)控制建立會話，撤除會話等會話管理效勞不同終端的上層用戶提供數(shù)據(jù)和信息的語法表示變換方法TCP應(yīng)用層表示層會話層傳輸層網(wǎng)絡(luò)層數(shù)據(jù)鏈路層物理層SSL

SecureSocketLayerProtocolNetscape公司設(shè)計，用于Web的平安傳輸協(xié)議SSL協(xié)議是一個兩層協(xié)議，可為應(yīng)用層協(xié)議如HTTP，F(xiàn)TP，SMTP等提供平安傳輸，通過將HTTP與SSL相結(jié)合，Web效勞器就可以實(shí)現(xiàn)客戶瀏覽器與效勞器間的平安通信。SSL協(xié)議：SSL記錄協(xié)議(Recordprotocol)SSL握手協(xié)議(Handshakeprotocol)協(xié)商密鑰，大局部內(nèi)容就是通信雙方如何利用它來平安的協(xié)商出一份密鑰〔用公鑰算法協(xié)商出一份秘鑰，然后用對稱算法加密數(shù)據(jù)〕定義傳輸格式TCP/IP協(xié)議棧中的平安機(jī)制一、SSLSecuresocketlayer,是Netscape提出的。TLS〔TransportLayerSecurity〕1.0〔RFC2246〕=SSLv3.l。設(shè)計目標(biāo)是在TCP根底上提供一種可靠的端到端的平安效勞，其效勞對象一般是WEB應(yīng)用。傳輸層的平安協(xié)議。SSL(SecureSocketLayer)

平安套接層協(xié)議特點(diǎn)：提供傳輸層的平安效勞〔按7層協(xié)議，也可以認(rèn)為是會話層〕最先(1995年)是由Netscape公司開發(fā)的，被廣泛應(yīng)用于Web等平安效勞，后改編為Internet標(biāo)準(zhǔn)TLS(TransportLayerSecurity)〔TLS1.0，RFC2246與SSL3.0類似〕獨(dú)立于應(yīng)用層傳輸層采用TCP提供可靠業(yè)務(wù)SSL可分成兩層：SSL握手協(xié)議：用于在客戶與效勞器之間建立平安連接之前交換平安信息SSL記錄協(xié)議〔低〕：確定數(shù)據(jù)平安傳輸模式SSL解決的問題〔功能〕客戶對效勞器的身份認(rèn)證SSL效勞器允許客戶的瀏覽器使用標(biāo)準(zhǔn)的公鑰加密技術(shù)和一些可靠的認(rèn)證中心〔CA〕的證書，來確認(rèn)效勞器的合法性。效勞器對客戶的身份認(rèn)證也可通過公鑰技術(shù)和證書進(jìn)行認(rèn)證，也可通過用戶名，password來認(rèn)證。建立效勞器與客戶之間平安的數(shù)據(jù)通道SSL要求客戶與效勞器之間的所有發(fā)送的數(shù)據(jù)都被發(fā)送端加密、接收端解密，同時還檢查數(shù)據(jù)的完整性SSL提供的平安效勞用戶和效勞器的合法性認(rèn)證usingX.509v3digitalcertificates傳輸數(shù)據(jù)的機(jī)密性usingoneofDES,TripleDES,IDEA,RC2,RC4,…傳輸數(shù)據(jù)的完整性usingMACwithMD5orSHA-1SSL協(xié)議的特性

保密性：握手之后，采用單鑰體制進(jìn)行數(shù)據(jù)加密、采用雙鑰體制進(jìn)行身份鑒別可靠性：采用消息摘要算法進(jìn)行完整性檢查確認(rèn)性：盡管會話的客戶端認(rèn)證是可選的，但是效勞器端始終是被認(rèn)證的靈活性：通信雙方可選擇密碼算法；允許多種形式各種級別的身份鑒別SSLArchitectureIPSSLChangeCipherSpecProtocolSSLAlertProtocolApplicationProtocolTCPSSLRecordProtocolSSLHandshakeProtocolSSLArchitecture

SSLProtocolStackHTTPLDAPIMAPSSL位于TCP/IP協(xié)議和應(yīng)用協(xié)議之間

SSL的體系結(jié)構(gòu)SSL的工作原理采用握手協(xié)議建立客戶與效勞器之間的平安通道，該協(xié)議包括雙方的相互認(rèn)證，交換密鑰參數(shù)采用告警協(xié)議向?qū)Χ酥甘酒淦桨插e誤采用改變密碼規(guī)格協(xié)議改變密碼參數(shù)采用記錄協(xié)議封裝以上三種協(xié)議或應(yīng)用層數(shù)據(jù)〔記錄類型20=改變密碼規(guī)格，21=告警，22=握手，23=應(yīng)用層數(shù)據(jù)〕HandshakeProtocol協(xié)商密鑰過程TCP鏈接建立之后ClientServer〔SSL客戶端〕

Clienth*llo-------->

Serverh*llo

Certificate*

ServerKeyExchange*

CertificateRequest*

<--------Serverh*lloDone

Certificate*

ClientKeyExchange

CertificateVerify*

[ChangeCipherSpec]

Finished-------->

[ChangeCipherSpec]

<--------Finished

ApplicationData<------->ApplicationData

發(fā)出Clienth*llo發(fā)起握手告訴效勞器，自己可以實(shí)現(xiàn)的加密算法列表和其他信息確定此次通信所需要的算法，自己的證書，公鑰客戶端隨機(jī)生成秘密消息，并用效勞器公鑰加密發(fā)送告訴客戶端，已經(jīng)OK用對稱加密密鑰加解密所需傳遞的信息〔明文和明文的數(shù)字摘要〕SSL握手協(xié)議層SSLHandShakeProtocollayer。用于SSL管理信息的交換，允許應(yīng)用協(xié)議傳送數(shù)據(jù)之前相互驗(yàn)證，協(xié)商加密算法和生成密鑰等。包括：SSL握手協(xié)議〔SSLHandShakeProtocol〕；SSL密碼參數(shù)修改協(xié)議〔SSLChangeCipherSpecProtocol〕；應(yīng)用數(shù)據(jù)協(xié)議〔ApplicationDataProtocol〕；SSL告警協(xié)議〔SSLAlertProtocol〕。TheSSLHandshakeProtocolAliceBob加密算法協(xié)商發(fā)送ID認(rèn)證加密CryptosuitesIsupport,RaCertificate,CryptosuiteIchoose,Rb<S>Pubkey-b,{keyedhashofhandshakemsgs}{keyedhashofhandshakemsgs}DataprotectedwithkeysderivedfromKK=Prf〔S，Ra，Rb〕K=Prf〔S，Ra，Rb〕SSL握手協(xié)議〔HandshakeProtocol〕SSL記錄協(xié)議層SSLRecordProtocollayer。為高層協(xié)議提供根本的平安效勞。記錄層封裝各種高層協(xié)議。具體實(shí)施壓縮解壓縮、加密解密、計算和校驗(yàn)MAC等與平安有關(guān)的操作。CleartextMessage+IntegrityCheckValue加密EncodedMessageTransmittedMessage解密CleartextMessage+IntegrityCheckValueSSL記錄協(xié)議工作流程圖Step1:先握手，確定要使用的算法和計算出隨機(jī)產(chǎn)生的對稱加密鑰匙〔如DES〕Step2:encrypt(DESkey)Step3:EncryptDESkeywithRSAPublickeyStep4:DecryptkeywithRSAprivatekeyStep5:DecryptwithDESkeySSL的兩個重要概念SSL連接〔connection)一個連接是一個提供一種適宜類型效勞的傳輸；SSL的連接是點(diǎn)對點(diǎn)的關(guān)系；連接是暫時的，每一個連接和一個會話關(guān)聯(lián)。SSL會話〔session〕一個SSL會話是在客戶與效勞器之間的一個關(guān)聯(lián)；會話由HandshakeProtocol創(chuàng)立。會話定義了一組可供多個連接共享的加密平安參數(shù)；會話用以防止為每一個連接提供新的平安參數(shù)所需昂貴的談判代價。SSL的會話狀態(tài)狀態(tài)分為兩種：待用狀態(tài)〔pendingstate〕，它包含了當(dāng)前握手協(xié)議協(xié)商好的壓縮、加密和MAC的算法，以及加解密的密鑰等參數(shù)。當(dāng)前操作狀態(tài)〔currentoperatingstate〕，它包含了當(dāng)前SSL紀(jì)錄層協(xié)議正在使用的壓縮、加密和MAC的算法，以及加解密的密鑰等參數(shù)。參數(shù)：會話標(biāo)識符:效勞器選擇的一個任意字節(jié)序列，用以標(biāo)識一個活動的或可激活的會話狀態(tài)。對方的證書:一個證書?？蔀榭?。壓縮算法:加密前進(jìn)行數(shù)據(jù)壓縮的算法。加密規(guī)約:指明數(shù)據(jù)體加密的算法〔無，或DES等〕以及散列算法〔如MD5或SHA-1〕用以計算MAC。還包括其他參數(shù)，如散列長度。主密值:48位秘密，在client與server之間共享?？芍匦麻_始的標(biāo)志:一個標(biāo)志，指明該會話是否能用于產(chǎn)生一個新連接。SSL記錄協(xié)議SSL記錄協(xié)議為SSL連接提供兩種效勞保密性。利用握手協(xié)議所定義的共享密鑰對SSL凈荷〔payload〕加密。完整性。利用握手協(xié)議所定義的共享的MAC密值來生成報文的鑒別碼〔MAC〕。SSL工作過程和SSL記錄格式SSLRecordFormatSSL工作過程發(fā)送方的工作過程從上層接收要發(fā)送的數(shù)據(jù)〔包括各種消息和數(shù)據(jù)〕；對信息進(jìn)行分段，成假設(shè)干記錄；使用指定的壓縮算法進(jìn)行數(shù)據(jù)壓縮數(shù)據(jù)〔可選〕；使用指定的MAC算法生成MAC；使用指定的加密算法進(jìn)行數(shù)據(jù)加密；發(fā)送數(shù)據(jù)。接收方的工作過程接收數(shù)據(jù)；使用指定的解密算法解密數(shù)據(jù)；使用指定的MAC算法校驗(yàn)MAC；使用壓縮算法對數(shù)據(jù)解壓縮〔在需要時進(jìn)行〕；將記錄進(jìn)行數(shù)據(jù)重組；將數(shù)據(jù)發(fā)送給高層。SSL握手協(xié)議層(1)加密規(guī)約修改協(xié)議僅定義了一個由單個字節(jié)“1〞構(gòu)成的消息報文；該消息將改變了連接所使用的加密規(guī)約。告警協(xié)議用于將SSL有關(guān)的告警傳送給對方實(shí)體；分為警告性告警〔warning〕或致命性告警〔fatal〕兩個級別。SSL握手協(xié)議層〔2〕握手協(xié)議〔SSLHandshakeProtocol〕是SSL中最復(fù)雜的一個局部。其功能是使效勞器和客戶能夠相互鑒別對方的身份，并且協(xié)商一系列平安參數(shù)。這些平安參數(shù)包括用于加密和MAC算法，以及用于在SSL記錄中保護(hù)發(fā)送數(shù)據(jù)的加密密鑰。SSL握手協(xié)議的消息格式握手協(xié)議定義的消息類型(1)消息類型說明參數(shù)hello_request握手請求，服務(wù)器可在任何時候向客戶端發(fā)送該消息。若客戶端正在進(jìn)行握手過程就可忽略該消息。否則客戶端發(fā)送cleint_hello消息，啟動握手過程。無client_hello客戶啟動握手請求，該消息時當(dāng)客戶第一次連接服務(wù)器時向服務(wù)器發(fā)送的第一條消息。該消息中包括了客戶端支持的各種算法。若服務(wù)器端不能支持，則本次會話可能失敗。版本、隨機(jī)數(shù)、會話ID、密文族、壓縮方法server_hello其結(jié)構(gòu)與client_hello消息，該消息是服務(wù)器對客戶端client_hello消息的恢復(fù)。版本、隨機(jī)數(shù)、會話ID、密文族、壓縮方法server_certificate服務(wù)器提供的證書。如果客戶要求對服務(wù)器進(jìn)行認(rèn)證，則服務(wù)器在發(fā)送server_hello消息后，向客戶端發(fā)送該消息。證書的類型一般是X.509v3。X．509v3證書鏈server_key_exchange服務(wù)器密鑰交換。當(dāng)服務(wù)器不使用證書，或其證書中僅提供簽名而不提供密鑰時，需要使用本消息來交換密鑰。參數(shù)、簽名握手協(xié)議定義的消息類型(2)消息類型說明參數(shù)certificate_request用于服務(wù)器向客戶端要求一個客戶證書。類型、授權(quán)server_hello_done該消息表明服務(wù)器端的握手請求報文已經(jīng)發(fā)送完畢，正在等待客戶端的響應(yīng)?？蛻舳嗽谑盏皆撓r，將檢查服務(wù)器提供的證書及其他參數(shù)是否是有效、可以接受的。無client_certificate客戶端對服務(wù)器certificate_request消息的響應(yīng)，只有在服務(wù)器端要求客戶證書的時候使用。一般該消息是客戶端收到server_hello_done消息后所發(fā)送的第一條消息。若客戶端沒有合適的證書，則向服務(wù)器端發(fā)送no_certificate的告警消息（無證書可能導(dǎo)致握手失?。．509v3證書鏈client_key_exchange客戶密鑰交換。當(dāng)客戶不使用證書，或其證書中僅提供簽名而不提供密鑰時，需要使用本消息來交換密鑰。參數(shù)、簽名certificate_verify該消息用于向服務(wù)器提供對客戶證書的驗(yàn)證。簽名finished該消息在“加密規(guī)約修改”（ChangeCipherSpec）消息之后發(fā)送，以證實(shí)握手過程已經(jīng)成功完成。本消息發(fā)送后，發(fā)送方開始使用協(xié)商的新參數(shù)來執(zhí)行操作。該消息需要在兩個方向上傳送。散列值握手協(xié)議過程〔1〕第一階段平安能力的建立 (1)客戶→效勞器：client_hello。 (2)效勞器→客戶：server_hello。第二階段效勞器認(rèn)證和密鑰交換 (3)效勞器→客戶：server_certificate。 (4)效勞器→客戶：server_key_exchange。 (5)效勞器→客戶：certificate_request。 (6)效勞器→客戶：server_hello_done。握手協(xié)議過程〔2〕第三階段客戶認(rèn)證和密鑰交換 (7)客戶→效勞器：client_certificate。 (8)客戶→效勞器：client_key_exchange。 (9)客戶→效勞器：certificate_verify。第四階段結(jié)束階段 (10)客戶→效勞器：change_cipher_spec。 (11)客戶→效勞器：finished。 (12)效勞器→客戶：change_cipher_spec。 (13)效勞器→客戶：finished。SSL的平安性幾乎所有操作平臺上的WEB瀏覽器〔IE、Netscatp〕以及流行的Web效勞器〔IIS、NetscapeEnterpriseServer等〕都支持SSL協(xié)議。因此使得使用該協(xié)議廉價且開發(fā)本錢小。但應(yīng)用SSL協(xié)議存在著不容無視的缺點(diǎn)：系統(tǒng)不符合國務(wù)院最新公布的《商用密碼管理?xiàng)l例》中對商用密碼產(chǎn)品不得使用國外密碼算法的規(guī)定系統(tǒng)平安性差。SSL協(xié)議的數(shù)據(jù)平安性其實(shí)就是建立在RSA等算法的平安性上，因此從本質(zhì)上來講，攻破RSA等算法就等同于攻破此協(xié)議。由于美國政府的出口限制，使得進(jìn)入我國的實(shí)現(xiàn)了SSL的產(chǎn)品〔Web瀏覽器和效勞器〕均只能提供512比特RSA公鑰、40比特對稱密鑰的加密。但是，一個平安協(xié)議除了基于其所采用的加密算法平安性以外，更為關(guān)鍵的是其邏輯嚴(yán)密性、完整性、正確性，從目前來看，SSL比較好地解決了這一問題。另外，SSL協(xié)議在“重傳攻擊〞上，有它獨(dú)到的解決方法。SSL協(xié)議為每一次平安連接產(chǎn)生了一個128位長的隨機(jī)數(shù)——“連接序號〞。理論上，攻擊者提前無法預(yù)測此連接序號，因此不能對效勞器的請求做出正確的應(yīng)答?？偟膩碇v，SSL協(xié)議的平安性能是好的，而且隨著SSL協(xié)議的不斷改進(jìn)，更多的平安性能、好的加密算法被采用，邏輯上的缺陷被彌補(bǔ)，SSL協(xié)議的平安性能會不斷加強(qiáng)。SSL的平安性SSL的應(yīng)用

SSL的典型應(yīng)用主要有兩個方面，一是客戶端，如瀏覽器等；另外一個就是效勞器端，如Web效勞器和應(yīng)用效勞器等。目前，一些主流瀏覽器〔如IE和Netscape等〕和IIS、DominoGoWebServer、NetscapeEnterpriseServer、Appache等Web效勞器都提供了對SSL的支持。要實(shí)現(xiàn)瀏覽器〔或其他客戶端應(yīng)用〕和Web效勞器〔或其他效勞器〕之間的平安SSL信息傳輸，必須在Web效勞器端安裝支持SSL的Web效勞器證書，在瀏覽器端安裝支持SSL的客戶端證書〔可選〕，然后把URL中的“://〞更換為“s://〞。SSL的應(yīng)用〔續(xù)〕由于出口限制和其他原因，目前的瀏覽器〔包括IE和Netscape〕只能支持56位對稱密鑰和512位非對稱密鑰長度的SSL連接，這在實(shí)際應(yīng)用中是非常不平安的，平安的SSL系統(tǒng)需要至少128位對稱密鑰和1024位非對稱密鑰長度。在SSL的客戶機(jī)/效勞器模式下，即使效勞器端可以支持位數(shù)更多的密鑰長度，具有較高的平安強(qiáng)度，但由于客戶端的限制，實(shí)際SSL連接中只能使用客戶端較低位數(shù)的密鑰長度來進(jìn)行平安信息傳輸。所以很多平安系統(tǒng)的客戶端大都安裝了一個SSL代理程序，它直接接管瀏覽器發(fā)送和接收的信息，利用平安的密鑰長度與效勞器進(jìn)行交互〔必要的時候還需要在效勞器端安裝SSL效勞器代理〕。SSL的缺陷

對于電子商務(wù)應(yīng)用來說，使用SSL可保證信息的真實(shí)性、完整性和保密性。但由于SSL不對應(yīng)用層的消息進(jìn)行數(shù)字簽名，因此不能提供交易的不可否認(rèn)性SSL在全球的大規(guī)模使用還有一定的難度。SSL產(chǎn)品的出口受到美國國家平安局〔NSA〕的限制，美國政府只允許加密密鑰為40位以下的算法出口，而美國的商家一般都可以使用128位的SSL，致使美國以外的國家很難真正在電子商務(wù)中充分利用SSLSSL所涉及的技術(shù)和機(jī)構(gòu)：對稱加密算法不對稱加密算法數(shù)字摘要數(shù)字證書CA認(rèn)證中心Q：由SSL所涉及的技術(shù)和機(jī)構(gòu)可知道，SSL可提供怎么樣的平安效勞？〔1〕機(jī)密性〔2〕完整性〔3〕認(rèn)證性

SSL協(xié)議在IE瀏覽器內(nèi)的配置本機(jī)器所支持的SSL協(xié)議版本SSL特點(diǎn)-應(yīng)用面廣,操作簡單-根本所有瀏覽器和效勞器都支持SSL-實(shí)施本錢低-認(rèn)證客戶端與效勞器,無法解決多方支付的平安傳輸和支付問題-大多數(shù)電子商務(wù)應(yīng)用系統(tǒng)都是基于SSL協(xié)議申請和安裝SSL客戶端證書請參看以下鏈接:://microsoft/china/technet/security/guidance/secmod31.mspx#EQFSSL的平安性使用dsniff工具可以通過中間人攻擊截獲s的信息結(jié)構(gòu)嚴(yán)謹(jǐn),但是實(shí)際中常常出現(xiàn)不嚴(yán)謹(jǐn)?shù)膽?yīng)用如:

(1)使用沒有證書的密鑰交換算法如DH算法(2)當(dāng)中間人用自己的證書替換掉原有的證書后,客戶端瀏覽器會彈出警告框,很多人不注意警告(3)只采用瀏覽器自帶的加密功能,理論上存在被破解的可能查看自己的瀏覽器為多少位加密128位!!!SSL平安代理---可利用一些代理系統(tǒng)獲得更高級的加密算法和密鑰強(qiáng)度參考資料:SET

SecureElectronicTransactionVISA和MasterCard兩大信用卡公司聯(lián)合推出的標(biāo)準(zhǔn)SETSSL二、平安電子交易協(xié)議SETSET〔SecureElectronicTransaction〕是由Visa和MasterCard兩大信用卡組織聯(lián)合開發(fā)的電子商務(wù)平安協(xié)議。它是一種基于消息流的協(xié)議，用來保證公共網(wǎng)絡(luò)上銀行卡支付交易的平安性，因而成為Internet上進(jìn)行在線交易的電子付款系統(tǒng)標(biāo)準(zhǔn)它采用公鑰密碼體制和X.509數(shù)字證書標(biāo)準(zhǔn)，主要應(yīng)用于BtoC模式中保障支付信息的平安性。SET協(xié)議本身比較復(fù)雜，設(shè)計比較嚴(yán)格，平安性高，它能保證信息傳輸?shù)臋C(jī)密性、真實(shí)性、完整性和不可否認(rèn)性。SET協(xié)議是PKI框架下的一個典型實(shí)現(xiàn)，也是一個基于可信的第三方認(rèn)證中心的方案平安電子交易(SET)SecurityElectronicTransaction。主要是為了解決用戶、商家和銀行之間通過信用卡支付的交易而設(shè)計的，以保證支付信息的機(jī)密和支付過程的完整。SET中的核心技術(shù)包括公開密鑰加密、數(shù)字簽名、電子信封、電子平安證書等。是一個平安協(xié)議的集合。SET和SSL除了都采用RSA公鑰算法以外，二者在其他技術(shù)方面沒有任何相似之處。而RSA在二者中也被用來實(shí)現(xiàn)不同的平安目標(biāo)。

SET是一種基于消息流的協(xié)議，它主要由MasterCard和Visa以及其他一些業(yè)界主流廠商設(shè)計發(fā)布，用來保證公共網(wǎng)絡(luò)上銀行卡支付交易的平安性。SET已經(jīng)在國際上被大量實(shí)驗(yàn)性地使用并經(jīng)受了考驗(yàn)，但大多數(shù)在Internet上購的消費(fèi)者并沒有真正使用SET。SET是一個非常復(fù)雜的協(xié)議，因?yàn)樗浅Ｔ敿?xì)而準(zhǔn)確地反映了卡交易各方之間存在的各種關(guān)系。SET還定義了加密信息的格式和完成一筆卡支付交易過程中各方傳輸信息的規(guī)那么。事實(shí)上，SET遠(yuǎn)遠(yuǎn)不止是一個技術(shù)方面的協(xié)議，它還說明了每一方所持有的數(shù)字證書的合法含義，希望得到數(shù)字證書以及響應(yīng)信息的各方應(yīng)有的動作，與一筆交易緊密相關(guān)的責(zé)任分擔(dān)。SET的設(shè)計目標(biāo)為支付/訂購信息提供機(jī)密性。通信信息的完整性。鑒證持卡者是否是信用卡賬戶的合法用戶。持卡用戶需要確認(rèn)能與之進(jìn)行平安交易的商家的身份。采用最好的平安策略和系統(tǒng)設(shè)計技術(shù)來保護(hù)電子商務(wù)交易中的所有合法方。平安性應(yīng)不依賴于傳運(yùn)輸層平安機(jī)制，但又可以充分利用傳輸層的平安效勞。協(xié)議應(yīng)該獨(dú)立于硬件平臺、操作系統(tǒng)和WEB軟件。SET協(xié)議的目標(biāo)信息在互聯(lián)網(wǎng)上平安傳輸，不能被竊聽或篡改用戶資料要妥善保護(hù)，商家只能看到訂貨信息，看不到用戶的賬戶信息持卡人和商家相互認(rèn)證，以確定對方身份軟件遵循相同的協(xié)議和消息格式，具有兼容性和互操作性平安電子交易SET支付模式SET平安電子商務(wù)的構(gòu)成利用SET協(xié)議的典型交易事件序列申領(lǐng)信用卡。持卡用戶獲得證書。商家獲得證書。持卡用戶訂購商品。用戶對商家的身份認(rèn)證。用戶發(fā)送訂購和支付信息。商家請求支付認(rèn)可。商家確認(rèn)訂購。供貨。商家請求支付。SET協(xié)議中的角色

持卡人：在電子商務(wù)環(huán)境中，消費(fèi)者和團(tuán)體購置者通過計算機(jī)與商家交流，持卡人通過由發(fā)卡機(jī)構(gòu)頒發(fā)的付款卡(例如信用卡、借記卡)進(jìn)行結(jié)算。在持卡人和商家的會話中，SET可以保證持卡人的個人帳號信息不被泄漏。發(fā)卡機(jī)構(gòu)：它是一個金融機(jī)構(gòu)，為每一個建立了帳戶的顧客頒發(fā)付款卡，發(fā)卡機(jī)構(gòu)根據(jù)不同品牌卡的規(guī)定和政策，保證對每一筆認(rèn)證交易的付款。商家：提供商品或效勞，使用SET，就可以保證持卡人個人信息的平安。接受卡支付的商家必須和銀行有關(guān)系。銀行：在線交易的商家在銀行開立帳號，并且處理支付卡的認(rèn)證和支付。支付網(wǎng)關(guān)：是由銀行操作的，將Internet上的傳輸數(shù)據(jù)轉(zhuǎn)換為金融機(jī)構(gòu)內(nèi)部數(shù)據(jù)的設(shè)備，或由指派的第三方處理商家支付信息和顧客的支付指令。

UsingSETinE-commerceTransactions

SET協(xié)議的工作原理

SET所涉及的技術(shù)和對象SET涉及的對象:--持卡人Card-Holder--商家Merchant--發(fā)卡行IssuingBank--收單行AcquiringBank--支付網(wǎng)關(guān)PaymentGateway--認(rèn)證中心CertificateAuthoritySET使用的技術(shù):對稱加密(DES)不對稱加密(RSA)數(shù)字證書數(shù)字摘要(SHA-1)雙重簽名PKI體制〔1〕用戶向商家發(fā)送購貨單和一份經(jīng)過簽名、加密的信托書。書中的信用卡號是經(jīng)過加密的，商家無從得知；

〔2〕商家把信托書傳送到收單銀行，收單銀行可以解密信用卡號，并通過認(rèn)證驗(yàn)證簽名；

〔3〕收單銀行向發(fā)卡銀行查問，確認(rèn)用戶信用卡是否屬實(shí)；

〔4〕發(fā)卡銀行認(rèn)可并簽證該筆交易；

〔5〕收單銀行認(rèn)可商家并簽證此交易；

〔6〕商家向用戶傳送貨物和收據(jù)；

〔7〕交易成功，商家向收單銀行索款；

〔8〕收單銀行按合同將貨款劃給商家；

〔9〕發(fā)卡銀行向用戶定期寄去信用卡消費(fèi)賬單。

SET協(xié)議規(guī)定的工作流程在一次使用SET協(xié)議傳輸數(shù)據(jù)的過程中:共驗(yàn)證數(shù)字證書9次驗(yàn)證數(shù)字簽名6次傳遞各方數(shù)字證書7次進(jìn)行5次數(shù)字簽名4次對稱加密和不對稱加密驗(yàn)證數(shù)字簽名驗(yàn)證數(shù)字證書進(jìn)行數(shù)字簽名(5)傳遞數(shù)字證書對稱加密不對稱加密初試應(yīng)答(1)支付信息,訂貨單(2)支付信息(3)支付應(yīng)答(4)購物應(yīng)答(5)驗(yàn)證數(shù)字簽名(6)客戶驗(yàn)證商家初試應(yīng)答里的商家,和支付網(wǎng)關(guān)的數(shù)字證書(1)商家驗(yàn)證訂貨單和支付通知(2)驗(yàn)證商家的支付請求(3)驗(yàn)證用戶的支付通知(4)驗(yàn)證支付應(yīng)答(5)驗(yàn)證購物應(yīng)答(6)驗(yàn)證數(shù)字證書(9)驗(yàn)證用戶證書(1)-初試請求驗(yàn)證商家和支付網(wǎng)關(guān)的證書(2,3)-初試應(yīng)答驗(yàn)證用戶證書(4)-支付信息,訂單信息驗(yàn)證商家和用戶證書(5,6)-支付請求和支付通知驗(yàn)證支付網(wǎng)關(guān)(7)-支付應(yīng)答驗(yàn)證商家證書(8)-購物應(yīng)答驗(yàn)證客戶證書(9)-購物完成傳遞數(shù)字證書(7)客戶證書(1)傳遞商家和網(wǎng)關(guān)證書(2)客戶證書(3)客戶證書和商家證書(4)支付網(wǎng)關(guān)證書(5)商家證書(6)客戶證書(7)對稱加密(4)不對稱加密(4)訂貨單,支付單等(1)訂貨單,支付請求,支付通知(2)支付應(yīng)答(3)購物應(yīng)答(4)雙向簽名持卡用戶需要將訂購信息〔OI〕和支付信息〔PI〕一起發(fā)送給商家。但是實(shí)際上訂購信息是發(fā)送給商家的，而支付信息是需要發(fā)送給銀行系統(tǒng)的。為了向持卡用戶提供更好的隱私保護(hù)，SET將OI和PI別離開來，由不同的機(jī)構(gòu)處理。簡單地將OI和PI別離是不行的。這兩個方面的信息也必須采用某種必要的方式連接起來，以解決可能出現(xiàn)的爭端。雙向簽名可以連接兩個發(fā)送給不同接收者的消息報文，可以滿足這種需求。SET的雙向簽名機(jī)制SET支持的交易類型〔1〕卡用戶注冊持卡用戶在CA中注冊，以便能夠與商家進(jìn)行SET報文的交互商家注冊商家在CA中注冊，以便能夠支持與持卡用戶和支付網(wǎng)關(guān)之間的SET報文交互購買請求持卡用戶向商家發(fā)送報文，其中包含提交給給商家的訂購信息OI和提交給的銀行系統(tǒng)的支付信息PI支付認(rèn)可支付認(rèn)可是商家和支付網(wǎng)關(guān)之間的交換，用來核準(zhǔn)用戶的信用卡賬號足以支付購買支付獲取商家向支付網(wǎng)關(guān)請求支付證書調(diào)查和狀態(tài)持卡用戶或商家向CA發(fā)出證書請求后，如果CA不能立刻處理，它將給持卡用戶或商家發(fā)送回答，指示請求者以后再查看。持卡用戶或商家通過發(fā)送“證書調(diào)查”報文來確定該證書請求的狀態(tài)，并且在請求被批準(zhǔn)時接收證書SET支持的交易類型〔2〕購買調(diào)查持卡用戶在收到了對購買請求的響應(yīng)以后，可以使用“購買調(diào)查”報文來檢查訂購處理的狀態(tài)。認(rèn)可撤銷它允許商家更正以前的認(rèn)可請求。如果訂購將不被完成，商家撤銷整個認(rèn)可；若部分訂購不被完成，商家可以部分撤銷認(rèn)可數(shù)量。收款撤銷允許商人糾正收款請求中的差錯，如錯誤地輸入了的交易數(shù)量。信用商家可向持卡用戶的賬號發(fā)出一個信用，用于退貨或者在運(yùn)輸過程中損壞。信用撤銷商家對先前請求的信用進(jìn)行更正。支付網(wǎng)關(guān)證書請求用于商家請求驗(yàn)證支付網(wǎng)關(guān)的，并且接收支付網(wǎng)關(guān)當(dāng)前的密鑰交換和簽名證書。批管理允許商家與支付網(wǎng)關(guān)之間的批量信息通信。差錯信息用于指示由于報文錯誤而導(dǎo)致的報文被拒絕。購置請求的交互過程發(fā)起請求消息向商家請求商家的證書和支付網(wǎng)關(guān)的證書。發(fā)起響應(yīng)消息包括商家的簽名證書以及支付網(wǎng)關(guān)的密鑰交換證書；持卡用戶對商家提供的證書和支付網(wǎng)關(guān)證書進(jìn)行驗(yàn)證，驗(yàn)證通過證書中CA簽名來進(jìn)行。購置請求消息與支付相關(guān)的信息；與訂購有關(guān)的信息；持卡用戶的證書。購置響應(yīng)消息包含相應(yīng)的交易號碼用于確認(rèn)訂購。購置請求消息與支付相關(guān)的信息：與支付相關(guān)的信息將被商家轉(zhuǎn)發(fā)給支付網(wǎng)關(guān)。支付信息〔PI〕；雙向簽名〔DS〕，是在PI和OI上計算的散列值，并使用用戶的私有簽名密鑰進(jìn)行簽名；訂購信息〔OI〕的報文摘要OIMD，支付網(wǎng)關(guān)需要OIMD來驗(yàn)證雙向簽名；數(shù)字信封，是用支付網(wǎng)關(guān)的公開密鑰KUb對對稱密鑰Ks進(jìn)行加密而形成的。與訂購有關(guān)的信息：是商家處理交易所必需的信息。訂購信息OI，OI是明文發(fā)送的；雙向簽名〔DS〕，是在PI和OI上計算的散列值，并使用用戶的私有簽名密鑰進(jìn)行簽名；支付信息PI報文摘要〔PIMD〕，用于商家進(jìn)行雙向簽名的驗(yàn)證。持卡用戶的證書。包含了持卡用戶的簽名公開密鑰，商家和支付網(wǎng)關(guān)都需要使用該密鑰來進(jìn)行簽名的驗(yàn)證。持卡用戶生成“購置請求〞的過程商家對用戶“購置請求〞的驗(yàn)證商家對用戶“購置請求〞的驗(yàn)證過程通過持卡用戶的CA簽名來驗(yàn)證持卡用戶的證書。使用持卡用戶的簽名公開密鑰來驗(yàn)證雙向簽名，以驗(yàn)證訂購信息的完整性，即在傳輸過程中沒有被篡改。處理訂購信息，并將支付信息轉(zhuǎn)交給支付網(wǎng)關(guān)進(jìn)行支付認(rèn)可。向卡用戶發(fā)送“購置響應(yīng)〞消息報文。支付認(rèn)可商家在處理來自持卡用戶的購置請求期間，需要請求支付網(wǎng)關(guān)來認(rèn)可和確認(rèn)該項(xiàng)交易。商家向支付網(wǎng)關(guān)發(fā)送一個“認(rèn)可請求〞消息報文。與支付相關(guān)的信息；與認(rèn)可有關(guān)的信息；證書。接收到“認(rèn)可請求〞后，支付網(wǎng)關(guān)完成以下操作：驗(yàn)證所有的證書。對認(rèn)可數(shù)據(jù)塊的數(shù)字信封進(jìn)行解密，獲得一次性對稱密鑰，然后解密認(rèn)可數(shù)據(jù)塊。驗(yàn)證認(rèn)可數(shù)據(jù)塊中商家的簽名。對認(rèn)支付數(shù)據(jù)塊的數(shù)字信封進(jìn)行解密，獲得一次性對稱密鑰，然后解密支付數(shù)據(jù)塊。驗(yàn)證支付數(shù)據(jù)塊中的雙向簽名。驗(yàn)證從商家提交的交易ID是否與用戶PI中的交易ID匹配。向發(fā)卡機(jī)構(gòu)請求并接收一個認(rèn)可。從發(fā)卡機(jī)構(gòu)獲得了認(rèn)可之后，支付網(wǎng)關(guān)就可向商家返回“認(rèn)可響應(yīng)〞報文。支付貨款商家同支付網(wǎng)關(guān)交互。商家發(fā)送收款請求消息。支付網(wǎng)關(guān)收到了收款請求報文時，解密并驗(yàn)證獲取請求數(shù)據(jù)塊和收款權(quán)標(biāo)，并檢查它們的一致性。支付網(wǎng)關(guān)通過專用支付網(wǎng)絡(luò)向發(fā)卡機(jī)構(gòu)發(fā)送清算請求，其執(zhí)行的結(jié)果是將貨款劃撥到商家的賬戶。操作完成后，支付網(wǎng)關(guān)向商家發(fā)送收款響應(yīng)報文。支付協(xié)議中采用的加密技術(shù)

1．?dāng)?shù)字信封：SET依靠密碼系統(tǒng)保證消息的可靠傳輸，在SET中，使用DES算法產(chǎn)生的對稱密鑰來加密數(shù)據(jù)，然后，將此對稱密鑰用接收者的公鑰加密，稱為消息的“數(shù)字信封〞，將其和數(shù)據(jù)一起送給接收者，接收者先用他的私鑰解密數(shù)字信封，得到對稱密鑰，然后使用對稱密鑰解開數(shù)據(jù)。

2．?dāng)?shù)字簽名：由于公開密鑰和私有密鑰之間存在的數(shù)學(xué)關(guān)系，使用其中一個密鑰加密的數(shù)據(jù)只能用另一個密鑰解開，SET中使用RSA算法來實(shí)現(xiàn)。發(fā)送者用自己的私有密鑰加密數(shù)據(jù)傳給接收者，接收者用發(fā)送者的公鑰解開數(shù)據(jù)后，就可確定消息來自于誰。這就保證了發(fā)送者對所發(fā)信息不能抵賴。

支付協(xié)議中采用的加密技術(shù)(續(xù))3．消息摘要：在SET協(xié)議中，原文通過SHA-1算法生成消息的文摘。4.雙重簽名：為了保證消費(fèi)者的賬號等重要信息對商家隱蔽，SET中采用了雙重簽名技術(shù)，它是SET推出