電子商務安全教學課件作者張波05安全協(xié)議與安全標準

第5章平安協(xié)議與平安標準學習目的了解電子商務平安協(xié)議與平安標準的概念、屬性等內(nèi)容；掌握平安套接層協(xié)議、平安電子交易協(xié)議、電子支付協(xié)議等主要平安協(xié)議知識；把握常用信息平安標準和電子商務平安標準等內(nèi)容。引例

匿名匯票“雙重花費〞問題5.1概述電子商務平安協(xié)議是一種特殊的應用范圍很廣的平安協(xié)議，它比一般的網(wǎng)絡平安協(xié)議具有更多的平安屬性，除應具有認證性、原子性、正確性和保密性之外，還應具有不可否認性、可追究性、公平性、適時中止性等重要平安屬性。電子商務平安標準那么是電子商務平安活動的行動指南和操作標準。以下介紹五個關鍵平安屬性：〔1〕認證性認證性是主體進行身份識別的過程。當外部第三方修改錯誤消息、重發(fā)消息、成心發(fā)送錯誤消息、消息不全或在網(wǎng)絡數(shù)據(jù)喪失的情況下，不能導致任意一方支付或產(chǎn)品的損失。認證是最重要的平安性質(zhì)之一，其他平安性質(zhì)的實現(xiàn)都依賴于認證性。認證是分布式網(wǎng)絡系統(tǒng)中的主體進行身份識別的過程。主體與認證效勞器共享一個秘密，通過對擁有此秘密的證明，主體可建立對其的信任，如在多用戶環(huán)境中使用口令效勞就是一個例子?！?〕公平性在一個協(xié)議消息交換開始前，交易雙方〔或多方〕已就將要交換的項達成了一致。一個合法的參與方能按照協(xié)議標準產(chǎn)生消息并根據(jù)某些特定的消息推導規(guī)那么處理消息?？尚诺谌降膮⑴c是保證公平性的常用方法。雙方直接進行通信時執(zhí)行的是主協(xié)議，如果一個交易方不能從另一個參與方接收到所期望的消息，就能覺察到這一點，單邊中止主協(xié)議，并根據(jù)需要向第三方發(fā)起子協(xié)議?？尚诺谌綉塥毩灰追降恼埱笞龀鲰憫?，否那么協(xié)議隱含了交易方是老實和可靠的假設，協(xié)議就不可能到達公平性和其他平安目標?？珊侠淼丶僭O一個子協(xié)議只涉及一個交易方，在一次交換中一個交易方至多只需發(fā)起一個子協(xié)議即能滿足其平安需求，可信第三方可通過某種安排使得子協(xié)議的執(zhí)行具有原子性?！?〕原子性一個協(xié)議的原子性是指在任何情況下，交易完成正確的金額，交換了正確的物品，或者當交易取消后就不存在金額與物品的交換?！?〕不可否認性不可否認性是電子商務平安協(xié)議的一個重要性質(zhì)。其目的在于通過通信主體提供對方參與協(xié)議交換的證據(jù)來保證其合法利益不受侵害，即協(xié)議主體必須對自己的合法行為負責，不能也無法事后否認。不可否認協(xié)議主體的目的在于收集證據(jù)，以便事后能夠向仲裁方證明對方主體確實發(fā)送或接收了消息。證據(jù)一般是以簽名消息的形式出現(xiàn)的，從而將消息與消息的發(fā)送方和接受方進行綁定。其兩個根本目標是提供發(fā)送方和接收方非否認依據(jù)，即發(fā)送方非否認依據(jù)〔EOO,EvidenceofOrigin〕和接收方非否認依據(jù)〔EOR,EvidenceofReceipt〕。在不可否認協(xié)議中，主體目標互不相同。而要達成不可否認這一目標，協(xié)議必須具有證據(jù)的正確性及交易的公平性兩個特點。在不可否認性之中還可引申出電子商務一些其他的相關性質(zhì)，如適時中止性、公平性、可追究性等?！?〕可追究性可追究性是指電子商務交易發(fā)生糾紛時，可通過歷史信息獲取交易當時的情況，從而獲得解決交易糾紛的能力。另外，還有一些平安屬性易于理解，如隱私性。對于商戶以外的參與者，訂單信息〔支付金額和產(chǎn)品詳細信息〕等應被屏蔽。5.2商務平安協(xié)議SSL協(xié)議體系結(jié)構(gòu)如圖5-1所示。圖5-1SSL協(xié)議體系結(jié)構(gòu)

從體系結(jié)構(gòu)圖可以看出，SSL協(xié)議可分為兩層：●SSL記錄協(xié)議〔SSLRecordProtocol〕：建立在可靠的傳輸協(xié)議〔如TCP〕之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等根本功能的支持?！馭SL握手協(xié)議〔SSLHandshakeProtocol〕：建立在SSL記錄協(xié)議之上，用于在實際的數(shù)據(jù)傳輸開始前，通訊雙方進行身份認證、協(xié)商加密算法、交換加密密鑰等。SSL協(xié)議實際上是SSL握手協(xié)議、SSL修改密文協(xié)議、SSL警告協(xié)議和SSL記錄協(xié)議組成的一個協(xié)議族?！?〕SSL記錄協(xié)議圖5-2SSL記錄協(xié)議的操作流程〔2〕SSL警告協(xié)議SSL警告協(xié)議是用來為對等實體傳遞SSL的相關警告。如果在通信過程中某一方發(fā)現(xiàn)任何異常,就需要給對方發(fā)送一條警示消息通告。警示消息有兩種：●Fatal錯誤,如傳遞數(shù)據(jù)過程中發(fā)現(xiàn)錯誤的MAC,雙方就需要立即中斷會話,同時消除自己緩沖區(qū)相應的會話記錄。●Warning消息,這種情況,通信雙方通常都只是記錄日志,而對通信過程不造成任何影響。SSL握手協(xié)議可以使得效勞器和客戶能夠相互鑒別對方,協(xié)商具體的加密算法和MAC算法以及保密密鑰,用來保護在SSL記錄中發(fā)送的數(shù)據(jù)?！?〕SSL修改密文協(xié)議為了保障SSL傳輸過程的平安性,客戶端和效勞器雙方應該每隔一段時間改變加密標準。所以有了SSL修改密文協(xié)議。SSL修改密文協(xié)議是三個高層的特定協(xié)議之一,也是其中最簡單的一個。在客服端和效勞器完成握手協(xié)議之后,它需要向?qū)Ψ桨l(fā)送相關消息(該消息只包含一個值為1的單字節(jié))，通知對方隨后的數(shù)據(jù)將用剛剛協(xié)商的密碼標準算法和關聯(lián)的密鑰處理，并負責協(xié)調(diào)本方模塊按照協(xié)商的算法和密鑰工作。〔4〕SSL握手協(xié)議1〕SSL握手協(xié)議報文頭由三個字段構(gòu)成●類型〔1字節(jié)〕：該字段指明使用的SSL握手協(xié)議報文類型?！耖L度〔3字節(jié)〕：以字節(jié)為單位的報文長度?！駜?nèi)容〔≥1字節(jié)〕：使用的報文的有關參數(shù)。2〕SSL握手協(xié)議的報文類型〔表5-1〕報文類型參數(shù)hello_request空client_hello版本、隨機數(shù)、會話ID、密文族、壓縮方法server_hello版本、隨機數(shù)、會話ID、密文族、壓縮方法certificatex.509V3證書鏈server_key_exchange參數(shù)、簽名certificate_request類型、授權(quán)server_done空certificate_verify簽名client_key_exchange參數(shù)、簽名finishedHash值表5-1SSL握手協(xié)議報文類型3〕SSL握手協(xié)議的過程圖5-4SSL握手協(xié)議的過程〔帶*的傳輸是可選的，或者與站點相關的，并不總是發(fā)送的報文〕2.SSL協(xié)議平安性分析5.2.2平安電子交易協(xié)議〔2〕SET協(xié)議的工作過程

SET協(xié)議的工作過程中要對商家、客戶、支付網(wǎng)關等交易各方進行身份認證，因此它的工作過程相對復雜。具體流程如圖5-5所示：圖5-5SET協(xié)議的工作過程2.SET協(xié)議平安性分析SET協(xié)議提供了多層次平安保障，復雜程度顯著增加；這些平安環(huán)節(jié)在一定程度上增加了交易的復雜性。另外，SET協(xié)議目前只局限于銀行卡的網(wǎng)上支付，對其他方式的支付沒有給出很好的解決方案。SET協(xié)議只支持B2C模式的電子商務，而不支持目前最具有前途和影響力的B2B電子商務交易。SET由于其高度的平安性和標準性，使其逐步開展成為目前平安電子支付的國際標準。由于SSL協(xié)議的本錢低、速度快、使用簡單，對現(xiàn)有網(wǎng)絡系統(tǒng)不需進行大的修改，因而目前取得了廣泛的應用。但隨著電子商務規(guī)模的擴大，網(wǎng)絡欺詐的風險性也在提高，在未來的電子商務中SET協(xié)議將會逐步占據(jù)主導地位。3.SET協(xié)議與SSL協(xié)議的比較SSL和SET是當前在電子商務中應用最為廣泛的平安協(xié)議．兩者的差異主要表達在以下幾個方面?！?〕在認證要求方面〔2〕在平安性方面〔3〕在網(wǎng)絡層協(xié)議位置方面〔4〕在應用領域方面〔5〕在用戶接口方面〔6〕在處理速度方面5.2.3電子支付專用協(xié)議1.NetBill協(xié)議Netbill協(xié)議涉及三方：客戶、商家及Netbill效勞器?？蛻舫钟械腘etbill帳號等價于一個虛擬電子信用卡帳號。協(xié)議步驟如下〔圖5-6所示〕：圖5-6NetBill協(xié)議流程2.FirstVirtual協(xié)議〔1〕客戶戶把在FirstVirtual的ID號發(fā)給商家；〔2〕商家聯(lián)結(jié)FirstVirtual效勞器驗證ID號的合法性，如果合法，商家把客戶所需的信息直接發(fā)送給客戶；〔3〕FirstVirtual效勞器向客戶以E－mail形式發(fā)送詢問信息，征詢客戶是否愿意為其付費，客戶同樣以E－mail形式回復“是〞或“否〞。如果客戶的回復為“是〞，F(xiàn)irstVirtual通過用戶信用卡的代理獲得相應的款項；〔4〕在90天的延時后，F(xiàn)irstVirtual效勞器將款項轉(zhuǎn)給相應的商家。3.iKP協(xié)議iKP(i－Key－Protocol，i=1，2，3)是一族平安電子支付協(xié)議。該族協(xié)議與現(xiàn)有的商業(yè)模式和支付系統(tǒng)根底設施相匹配。所有的iKP協(xié)議都基于公鑰密碼學，但它隨著擁有自己公鑰對的成員數(shù)目而變化，分別稱為1KP協(xié)議、2KP協(xié)議和3KP協(xié)議，其平安性和復雜性遞增?！?〕1KP協(xié)議是最簡單的協(xié)議，它只要求支付網(wǎng)關擁有一對公私鑰，用戶和商戶只需擁有支付網(wǎng)關認證了的公鑰或經(jīng)一個權(quán)威機構(gòu)認證了的支付網(wǎng)關公鑰(該機構(gòu)通過簽名證書來使支付網(wǎng)關的公鑰合法化)?！?〕2KP協(xié)議要求支付網(wǎng)關和商戶都擁有公鑰對和公鑰證書?！?〕3KP協(xié)議要求支付網(wǎng)關、顧客和商人三方都擁有公鑰對，并提供完全的多方平安。5.2.4平安超文本傳輸協(xié)議1.S-HTTP簡介2.S-HTTP與SSL的比較S-HTTP和SSL是從不同角度提供Web的平安性的。S－HTTP建立在HTTP之上，旨為HTTP事務提供身份認證和加密手段。SSL那么建立在HTTP的下一層，并可用于FTP、Gopher等其他協(xié)議。S-HTTP對單個文件作“私人/簽字〞之區(qū)分，而SSL那么把參與相應進程之間的數(shù)據(jù)通道接“私用〞和“已認證〞進行監(jiān)管。S-HTTP是應用層的加密協(xié)議，它能感知到應用層數(shù)據(jù)的結(jié)構(gòu)，而不是像SSL一樣完全當作流來處理，也就是說，S-HTTP把消息當成對象進行簽名或加密傳輸，而SSL那么主動把數(shù)據(jù)流分幀處理，而不理會消息的邊界。也由于這樣，S-HTTP可以提供基于消息的抗抵賴性證明，而SSL不可以。因此，S-HTTP比SSL更靈活，功能更強大，但是實現(xiàn)較困難，而使用也更困難，也因此現(xiàn)在使用基于SSL的HTTPS要比S-HTTP要更普遍。目前SSL根本取代了S-HTTP。大多數(shù)Web貿(mào)易均采用傳統(tǒng)的Web協(xié)議，并使用SSL加密的HTTP來傳輸敏感的賬單信息。5.2.5平安電子郵件協(xié)議1.PEM標準PEM是通過Internet傳輸平安性商務郵件的非正式標準。它提供了四種平安效勞：●數(shù)據(jù)隱蔽:使數(shù)據(jù)免遭非授權(quán)的泄露,防止有人半路截取和竊聽。●數(shù)據(jù)完整性:提供通信期間數(shù)據(jù)的完整性可用于偵查和防止數(shù)據(jù)的偽造和篡改。●對發(fā)送方的鑒別:用來證明發(fā)送方的身份防止有人冒名頂替?！穹腊l(fā)送方否認:結(jié)合上述功能,防止發(fā)送方事后不成認發(fā)送過此文件。PEM目前尚未提供存取控制和防接收方否認等平安功能。PEM對報文的處理包括如下過程：1〕做標準化處理：為了使PEM與MTA(報文傳輸代理)兼容，按SMTP協(xié)議對報文進行標準化處理；2〕MIC(MessageIntegrityCode)計算；3〕把處理過的報文轉(zhuǎn)化為適于SMTP系統(tǒng)傳輸?shù)母袷健?.S/MIME5.2.6電子數(shù)據(jù)交換協(xié)議1.EDI的根本原理〔1〕映射〔Mapping〕——生成EDI平面文件〔2〕翻譯〔Translation〕——生成EDI標準格式文件〔3〕通信——這一步由計算機通信軟件完成〔4〕EDI文件的接受和處理2.EDI的平安威脅與平安策略

〔1〕EDI系統(tǒng)的平安威脅●冒充：MTA之間是以交換明文形式的MTA名稱彼此證實的，一個未知的MTA可能會通過發(fā)送一個的MTA而與其它的MTA互連，冒名頂替、偷竊工作資源和信息?！翊鄹臄?shù)據(jù)：篡改數(shù)據(jù)除破壞數(shù)據(jù)的完整性外，還包括在遞交不可抵賴之后對源點本地存儲的文電內(nèi)容作篡改，以及在投遞不可抵賴后對接收端存儲的報文內(nèi)容作出篡改?！裢悼础⒏`取數(shù)據(jù)：這是指EDI系統(tǒng)的用戶及外來者未經(jīng)授權(quán)偷看或窺視他人的文電內(nèi)容以獲取商業(yè)秘密?！駡笪膯适В篍DI系統(tǒng)中的報文喪失主要有三種情況，一是UA、MS或MTA的錯誤而喪失文電；二是因平安保密措施不當而喪失文電；三是在不同的責任區(qū)域之間傳遞時喪失報文?！竦仲嚮蚴缚诜裾J：EDI處理的合同、訂單等貿(mào)易數(shù)據(jù)，在起草、遞交、投遞等環(huán)節(jié)中都可能發(fā)生抵賴或否認，尤其是在MHS環(huán)境中，由于采用自動轉(zhuǎn)發(fā)、重新定向等效勞方式，危險性就更大了?！窬芙^效勞：因局部系統(tǒng)的失誤及通信協(xié)議的不一致會導致系統(tǒng)中斷，從而拒絕效勞。局部系統(tǒng)出于自我保護目的而成心中斷通信更會導致拒絕效勞?！?〕EDI系統(tǒng)的平安策略針對上述EDI應用所面臨的威脅和攻擊，EDI系統(tǒng)的平安策略應是：●他人無法冒充合法用戶利用網(wǎng)絡及其資源；●他人不能非法竊取或偷看報文的內(nèi)容；●他人無法篡改、替換或擾亂數(shù)據(jù)；●與報文交換有關的各種活動及其發(fā)生時間均有準確、完整的記錄和審計；●確保報文在交換過程中不喪失；●防止因自然災害、人為原因和機器故障而引起的系統(tǒng)拒絕效勞。為實現(xiàn)這些目標,EDI系統(tǒng)中的用戶所需求的平安業(yè)務主要有以下幾種：●鑒別：包括源點鑒別和實體鑒別，即要能準確鑒別報文的來源?！裼脩羯矸葑R別。它包括訪問控制和證書管理兩方面的內(nèi)容。前者確保只有合法用戶才能進入EDI系統(tǒng)；后者為合法用戶簽發(fā)證書并實行有效管理?！駭?shù)據(jù)保密與數(shù)據(jù)完整性：保護數(shù)據(jù)不被第三者得悉，不被篡改、亂序、刪除和重復?！穹赖仲嚕杭丛袋c不可抵賴、接收不可抵賴和回執(zhí)不可抵賴。5.2.7IPSec平安協(xié)議IPSec通過使用基于密碼學的保護效勞、平安協(xié)議和動態(tài)密鑰管理，可實現(xiàn)以下目標：〔1〕認證IP報文的來源〔2〕保證IP數(shù)據(jù)報的完整性〔3〕確保IP報文的內(nèi)容在傳輸過程中未被讀取〔4〕確保認證報文沒有重復2.IPSec協(xié)議結(jié)構(gòu)圖5-7顯示了IPSec的體系結(jié)構(gòu)、組件及各組件間的相互關系。IPSec組件包括平安協(xié)議認證頭(AH)和封裝平安載荷(ESP)，平安聯(lián)結(jié)(SA)、密鑰交換(IKE)及加密和驗證算法等。圖5-7IPSec的體系結(jié)構(gòu)IPSec的處理簡圖如圖5-8：圖5-8IPSec處理簡圖〔1〕IPSecAH——IPSec認證頭協(xié)議AH協(xié)議頭格式如圖5-9所示：上層協(xié)議負荷長度保留字段安全參數(shù)索引值序號認證數(shù)據(jù)圖5-9AH協(xié)議頭格式〔2〕IPSecESP——IPSec封裝平安負載ESP頭(包)的格式如圖5-10所示：圖5-10ESP頭(包)的格式〔3〕IPSecIKE——Internet密鑰交換協(xié)議Internet密鑰交換〔IPSecInternetKeyExchangeProtocol，IPSecIKE〕是IPSec體系結(jié)構(gòu)中的一種主要協(xié)議。它是一種混合協(xié)議，使用局部Oakley和局部SKEME，并協(xié)同ISAKMP提供密鑰生成材料和其它平安連系，比方用于IPSecDOI的AH和ESP。IKE的實施必須支持以下的屬性值：●DES用在CBC模式，使用弱、半弱、密鑰檢查；●MD5[MD5]和SHA[SHA]；●通過預共享密鑰進行認證；●缺省的組1上的MODP?！?〕IPSecISAKMP——Internet平安連接和密鑰管理協(xié)議Interne平安連接和密鑰管理協(xié)議〔InternetSecurityAssociationandKeyManagementProtocol，ISAKMP〕是IPSec體系結(jié)構(gòu)中的一種主要協(xié)議。該協(xié)議結(jié)合認證、密鑰管理和平安連接等概念來建立政府、商家和因特網(wǎng)上的私有通信所需要的平安。ISAKMP關于DOI定義如下方面：1〕特定DOI協(xié)議標識的命名模式；2〕位置字段解釋；3〕可應用平安策略集；4〕特定DOISA屬性語法；5〕特定DOI有效負載目錄語法；6〕必要情況下，附加密鑰交換類型；7〕必要情況下，附加通知信息類型。3.IPSec工作原理圖5-11IPSec工作原理(1)IPSec流出處理1〕查找適宜的平安策略。從IP包中提取出“選擇符〞來檢索SPD，找到該IP包所對應的流出策略，之后用此策略決定對該IP包如何處理：繞過平安效勞以普通方式傳輸此包或應用平安效勞。2〕查找適宜的SA。根據(jù)策略提供的信息，在平安關聯(lián)數(shù)據(jù)庫中查找為該IP包所應該應用的平安關聯(lián)SA。如果此SA尚未建立，那么會調(diào)用IKE，將這個SA建立起來。此SA決定了使用何種根本協(xié)議(AH或ESP)，采用哪種模式(隧道模式或傳輸模式)，以及確定了加密算法，驗證算法，密鑰等處理參數(shù)。3〕根據(jù)SA進行具體處理。根據(jù)SA的內(nèi)容，對IP包的處理將會有幾種情況：使用隧道模式下的ESP或AH協(xié)議，或者使用傳輸模式下的ESP或AH協(xié)議。(2)IPSec流入處理1〕IP包類型判斷：如果IP包中不包含IPSec頭，將該包傳遞給下一層；如果IP包中包含IPSec頭，會進入下面的處理。2〕查找適宜的SA：從IPSec頭中摘出SPI，從外部IP頭中摘出目的地址和IPSec協(xié)議，然后利用<SPI，目的地址，協(xié)議>在SAD中搜索SPI。如果SA搜索失敗就丟棄該包。如果找到對應SA，那么轉(zhuǎn)入以下處理。3〕具體的IPSec處理：根據(jù)找到的SA對數(shù)據(jù)包執(zhí)行驗證或解密進行具體的IPSec處理。4〕策略查詢：根據(jù)選擇符查詢SPD，根據(jù)此策略檢驗IPSec處理的應用是否正確。最后，將IPSec頭剝離下來，并將包傳遞到下一層，根據(jù)采用的模式的不同，下一層或者是傳輸層，或者是網(wǎng)絡層。運用IPSec進行平安通信的大體步驟是：1〕使用IKE協(xié)議協(xié)商IPSecSA；2〕在建立好IPSecSA的根底上，進行通信；3〕通信完畢，撤銷IPSecSA；4〕當IPSecSA撤銷以后，與其相應的其他SA也要進行撤銷。5.3商務平安標準

5.3.1常用信息平安標準它們的關系如圖5－12所示。圖5-12幾個重要的信息平安國際標準的關系8.我國計算機信息系統(tǒng)平安保護等級劃分準那么5.3.2電子商務平安標準