電子商務安全基礎-ppt(中職)第6章-電子商務安全協(xié)議_第1頁
電子商務安全基礎-ppt(中職)第6章-電子商務安全協(xié)議_第2頁
電子商務安全基礎-ppt(中職)第6章-電子商務安全協(xié)議_第3頁
電子商務安全基礎-ppt(中職)第6章-電子商務安全協(xié)議_第4頁
電子商務安全基礎-ppt(中職)第6章-電子商務安全協(xié)議_第5頁
已閱讀5頁,還剩35頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、第 6章 電子商務安全協(xié)議電子商務安全基礎中國人民大學出版社6.1電子商務安全交易需求6.2安全套接層協(xié)議主要內容6.3安全電子交易規(guī)范6.4安全超文本傳輸協(xié)議6.5實驗項目導 入隨著計算機和網(wǎng)絡的發(fā)展,電子商務已經(jīng)深入到我們生活中的各個角落。Internet已經(jīng)在電子商務領域開發(fā)了與應用相關的安全機制,包括SSL、SET、S-HTTP、Internet電子數(shù)據(jù)交換和IPSec等。本章將對這些協(xié)議進行較為詳細的研究和介紹。6.1 電子商務安全交易需求電子商務交易的安全性要求:(1)真實性要求。能對信息、實體的真實性進行鑒別。(2)機密性要求。保證信息不被泄露給非授權的人或實體。(3)完整性要求

2、。保證數(shù)據(jù)的一致性,防止數(shù)據(jù)被非授權建立、修改或破壞。(4)可用性要求。保證合法用戶對信息和資源的使用不會被不正當?shù)鼐芙^。(5)不可抵賴性要求。建立有效的責任機制,防止實體否認其行為。(6)可控性要求。能控制使用資源的人或實體的使用方式。6.1.1 電子商務銷售者面臨的安全威脅在傳統(tǒng)交易過程中,買賣雙方是面對面地交易容易保證交易的安全性,并建立起信任關系。在電子商務過程中,買賣雙方是通過網(wǎng)絡進行建立交易雙方的安全和信任關系困難在電子商務交易中雙方都面臨不同的安全威脅6.1.1 電子商務銷售者面臨的安全威脅對于銷售者而言,面臨的安全威脅主要有:(1)中央系統(tǒng)安全性被破壞。(2)競爭者檢索商品遞送

3、狀況。(3)客戶資料被競爭者獲取。(4)被他人假冒而損害公司的信譽。(5)消費者提交訂單后不付款。(6)獲取他人的機密數(shù)據(jù)。6.1.2 電子商務消費者面臨的安全威脅對于消費者而言,面臨的安全威脅主要有:(1)付款后不能收到商品。(2)拒絕服務。攻擊者可能向銷售商的服務器發(fā)送大量的虛假訂單來耗盡其資源,從而使消費者得不到正常的服務。(3)機密性喪失。6.2 安全套接層協(xié)議安全套接層協(xié)議(SSL)由美國網(wǎng)景公司于1995年開發(fā)和倡導,是目前電子商務交易安全中使用最多的協(xié)議之一。SSL協(xié)議主要用于提高應用程序之間數(shù)據(jù)的安全系數(shù),SSL協(xié)議的實現(xiàn)屬于Socket層,在Internet網(wǎng)絡層次中的位置處

4、于應用層和傳輸層之間。6.2.1 SSL提供的安全服務數(shù)據(jù)加密服務1)安全套接層協(xié)議所采用的加密技術有對稱加密技術和公開密鑰技術2)在客戶機與服務器進行數(shù)據(jù)交換之前,交換SSL初始握手信息,在SSL握手過程中,采用各種加密技術對其加密,以保證其機密性和數(shù)據(jù)的完整性,并且用數(shù)字證書進行鑒別。SSL標準主要提供三種服務: 數(shù)據(jù)加密服務、認證服務和數(shù)據(jù)完整性服務。6.2.1 SSL提供的安全服務數(shù)據(jù)加密服務1)安全套接層協(xié)議所采用的加密技術有對稱加密技術和公開密鑰技術2)在客戶機與服務器進行數(shù)據(jù)交換之前,交換SSL初始握手信息,在SSL握手過程中,采用各種加密技術對其加密,以保證其機密性和數(shù)據(jù)的完整

5、性,并且用數(shù)字證書進行鑒別。SSL標準主要提供三種服務: 數(shù)據(jù)加密服務、認證服務和數(shù)據(jù)完整性服務。6.2.1 SSL提供的安全服務數(shù)據(jù)加密服務SSL客戶機與服務器都有各自的識別號,這些識別號使用公開密鑰進行加密, 使得它們能夠確信數(shù)據(jù)將被發(fā)送到正確的客戶機和服務器上。SSL采用哈希函數(shù)和機密共享的方法提供完整性的服務,在客戶機與服務器之間建立安全通道,以保證數(shù)據(jù)在傳輸中完整地到達目的地。數(shù)據(jù)完整性服務SSL是在Internet基礎上提供的一種保證私密性的安全協(xié)議。它可以用于保護正常運行于TCP之上的任何應用協(xié)議,如HTTP、FTP、SMTP或Telnet的通信,最常見的是用SSL來保護HTTP

6、的通信。SSL協(xié)議的優(yōu)點在于它是與應用層協(xié)議無關的高層的應用協(xié)議6.2.2 SSL協(xié)議的運行步驟SSL協(xié)議的運行分為六個步驟,它們包括:(1)接通階段。客戶機通過網(wǎng)絡向服務器打招呼,服務器回應。(2)密碼交換階段??蛻魴C與服務器之間交換雙方認可的密碼,一般選用RSA密碼算法。(3)會談密碼階段。客戶機與服務器間產(chǎn)生彼此交談的會談密碼。(4)檢驗階段。客戶機檢驗服務器取得的密碼。(5)客戶認證階段。服務器驗證客戶機的可信度。 (6)結束階段??蛻魴C與服務器之間相互交換結束的信息。6.2.2 SSL協(xié)議的運行步驟說明:1)發(fā)送時信息用對稱密鑰加密,對稱密鑰用非對稱算法加密,再把兩個包綁在一起傳送過

7、去。接收的過程與發(fā)送正好相反,先解開有對稱密鑰的加密包,再用對稱密鑰解密。2)SSL安全協(xié)議的缺點: 不能自動更新證書; 認證機構編碼困難; 瀏覽器的口令具有隨意性; 不能自動檢測證書作廢列表(CRL); 用戶的密鑰信息在服務器上是以明文方式存儲的; 客戶的數(shù)據(jù)都完全暴露在商家的面前6.2.3 SSL體系結構SSL協(xié)議位于TCP/IP協(xié)議模型的網(wǎng)絡層和應用層之間,使用TCP來提供一種可靠的端到端的安全服務,它使客戶/服務器應用之間的通信不被攻擊竊聽,并且始終對服務器進行認證,還可以選擇對客戶進行認證。SSL協(xié)議在應用層通信之前就已經(jīng)完成加密算法、通信密鑰的協(xié)商以及服務器認證工作6.2.3 SS

8、L體系結構 SSL記錄協(xié)議1)SSL記錄協(xié)議為SSL連接提供了兩種服務: 一是機密性, 二是消息完整性。2)SSL記錄協(xié)議工作過程: 首先接收傳輸?shù)膽脠笪?將數(shù)據(jù)分片成可管理的塊,進行數(shù)據(jù)壓縮(可選),應用MAC算法; 其次利用IDEA、DES、3DES或其他加密算法進行數(shù)據(jù)加密; 最后增加由內容類型、主要版本、次要版本和壓縮長度組成的首部。被接收的數(shù)據(jù)剛好與接收數(shù)據(jù)工作過程相反,依次被解密、驗證、解壓縮和重新裝配,然后交給更高級的用戶6.2.3 SSL體系結構 SSL修改密文協(xié)議SSL修改密文協(xié)議是使用SSL記錄協(xié)議服務的SSL高層協(xié)議的三個特定協(xié)議之一,協(xié)議由單個消息組成,該消息只包含一

9、個值為1的單個字節(jié)。該消息的唯一作用就是使未決狀態(tài)拷貝為當前狀態(tài),更新用于當前連接的密碼組。 SSL告警協(xié)議SSL告警協(xié)議是用來為對等實體傳遞SSL的相關警告。警示消息有兩種:1) Fatal錯誤雙方就需要立即中斷會話,同時消除自己緩沖區(qū)相應的會話記錄2) Warning消息這種情況,通信雙方通常都只是記錄日志,而對通信過程不造成任何影響。6.2.3 SSL體系結構 SSL握手協(xié)議1)SSL握手協(xié)議允許通信實體在交換應用數(shù)據(jù)之前協(xié)商密鑰的算法、加密密鑰和對客戶端進行認證(可選)的協(xié)議、為下一步記錄協(xié)議要使用的密鑰信息、使客戶端和服務器建立并保持安全通信的狀態(tài)信息。2)在任何應用程序數(shù)據(jù)傳輸之前

10、使用3)SSL握手協(xié)議包含四個階段: 第一個階段建立安全能力; 第二個階段服務器鑒別和密鑰交換; 第三個階段客戶鑒別和密鑰交換; 第四個階段完成握手協(xié)議6.2.4 SSL的安全措施SSL采用對稱密碼技術和公開密碼技術相結合的技術,采用密碼和證書實現(xiàn)通信數(shù)據(jù)完整性、認證性等安全服務 加密算法和會話密鑰加密算法和會話密鑰是在握手協(xié)議中協(xié)商,并由CIPHER-CHOICE消息指定的?,F(xiàn)有的SSL版本中所用到的加密算法有RC4、RC2、IDEA和DES,加密算法所用的密鑰由消息哈希函數(shù)MD5產(chǎn)生。RC4、RC2是由RSA定義的其中RC2適用于塊加密,RC4適用于流加密。6.2.4 SSL的安全措施 認

11、證算法認證算法采用X.509電子證書標準,通過RSA算法進行數(shù)字簽名來實現(xiàn)。SSL認證包括服務器的認證和客戶的認證兩種1)服務器的認證對服務器進行認證時,只有用正確的服務器方私有密鑰加密CLIENT-HELLO消息形成的數(shù)字簽名,才能被客戶正確地解密,從而驗證服務器的身份。首先服務器方在SERVER-HELLO消息中的服務器證書中,提供了服務器的公有密鑰;服務器用其私有密鑰才能正確地解密由客戶方使用服務器的公有密鑰加密的MASTER-KEY;獲得服務器方的讀密鑰和寫密鑰。6.2.4 SSL的安全措施 認證算法2)客戶的認證 只有用正確的客戶私有密鑰加密的內容才能被服務器方用其讀密鑰正確地解開客

12、戶收到服務器方發(fā)出的REQUEST-CERTIFICATE消息時,客戶首先使用MD5消息哈希函數(shù)獲得服務器方信息的摘要,服務器方的信息包括KEY-MATERIAL-0、KEY-MATERIAL-1、KEYMATERIAL-2、CERTIFICATE-CHALLENAGE-DATE(來自于REQUEST-CERTIFICATE消息)、服務器所賦予的證書(來自于SERVER-HELLO)消息。然后客戶使用自己的私有密鑰加密摘要形成數(shù)字簽名,從而被服務器認證。6.3 安全電子交易規(guī)范SET的產(chǎn)生:1996年2月,由萬事達和維薩國際信用卡組織與技術合作伙伴GTE、網(wǎng)景、IBM、Terisa Syste

13、ms、Verisign、微軟、SAIC等一批跨國公司共同開發(fā)了安全電子交易規(guī)范(SET),它具有很強的安全性。已成為事實上的工業(yè)標準。目前,它已獲得了IETF標準的認可。SET是一個基于可信的第三方認證中心的方案,它要實現(xiàn)的主要安全目標有下列三個方面:(1)保障付款安全。確保付款資料的隱秘性及完整性,提供認證,并定義安全服務所需的演算法及相關協(xié)定。(2)確定應用的互通性。提供一個開放式的標準,明確定義細節(jié),使標準達到相容性與接受性的目標。(3)達到全球市場的接受性。 6.3.1SET提供的安全服務SET的主要安全目標 為實現(xiàn)上述目標,SET為此提供以下七個方面的安全服務:(1)確保在支付系統(tǒng)中

14、支付信息和訂購信息的安全性;(2)確保數(shù)據(jù)在傳輸過程中的完整性,即確保數(shù)據(jù)在傳輸過程中不被破壞;(3)對持卡者身份的合法性進行檢查;(4)對支付接收方的身份,即商家身份的合法性進行檢查;(5)提供最優(yōu)的安全系統(tǒng),以保護在電子貿易中的合法用戶;(6)確保該標準不依賴于傳輸安全技術,也不限定任何安全技術的使用;(7)使通過網(wǎng)絡和相應的軟件所進行的交互作業(yè)簡便易行。 6.3.1SET提供的安全服務SET的安全服務6.3.2SET的運行步驟在一個完整的購物處理流程中,SET的工作過程如圖所示 6.3.2SET的運行步驟說明:消息(1)、消息(2)是交易初始設置,客戶與商家相互交換身份證書,建立一個交易

15、ID號;在消息(3)中,包含商品或服務名、客戶簽名、加密的客戶信用卡信息;消息(4)是商家對客戶購買訂單的確認;消息(5)、消息(6)是商家對客戶支付信息合法性的驗證,在商家與銀行(或其代理機構)間進行;消息(7)、消息(8)是客戶對交易內容、交易狀態(tài)進行查詢;消息(9)、消息(10)是商家與銀行間的兌現(xiàn)和平賬過程。6.3.3SET的體系結構SET為基于信用卡進行電子化交易的應用提供了實現(xiàn)安全措施的規(guī)則。SET主要由三個文件組成: SET業(yè)務描述、SET程序員指南和SET協(xié)議描述。SET規(guī)范涉及加密算法的應用、證書信息和對象格式、購買信息和對象格式、確認信息和對象格式、劃賬信息和對象格式、對話

16、實體之間消息的傳輸協(xié)議等內容。6.3.3SET的體系結構SET交易的主要成員如下:(1)持卡人(即消費者) (2)網(wǎng)上商家:在網(wǎng)上的符合SET規(guī)格的電子商店,提供商品或服務,它必須具備相應電子貨幣使用的條件。(3)收單銀行:通過支付網(wǎng)關處理持卡人和商家之間的交易付款事務。 (4)支付網(wǎng)關:它是連接銀行專用網(wǎng)絡與Internet的一組服務器,其主要作用是完成兩者之間的通信、協(xié)議轉換和進行數(shù)據(jù)加、解密,以保護銀行內部網(wǎng)絡的安全。支付網(wǎng)關的功能主要有:1)將Internet傳來的數(shù)據(jù)包解密,并按照銀行系統(tǒng)內部的通信協(xié)議將數(shù)據(jù)重新打包;2)接收銀行系統(tǒng)內部反饋的響應消息,將數(shù)據(jù)轉換為Internet傳

17、送的數(shù)據(jù)格式,并對其進行加密。 6.3.3SET的體系結構(5)發(fā)卡銀行:在交易過程開始前,發(fā)卡銀行負責查驗持卡人的數(shù)據(jù),如果查驗有效,整個交易才能成立。在交易過程中,發(fā)卡銀行負責處理電子貨幣的審核和支付工作。(6)認證中心CA:接受持卡人、商家、銀行以及支付網(wǎng)關的數(shù)字認證申請書,并管理數(shù)字證書的相關事宜。CA的主要功能:接收注冊請求、處理/拒絕請求、頒發(fā)證書。6.3.4SET采用的安全措施SET采用的安全措施,幾乎全部以數(shù)據(jù)加密技術為基礎,可以說,沒有加密技術,就沒有安全電子交易。1)通過加密保證數(shù)據(jù)的機密性SET在一個數(shù)字信封中使用對稱和非對稱兩種加密技術和算法來保證數(shù)據(jù)的機密性。發(fā)送方將

18、消息用DES加密,并將DES對稱密鑰用接收方的公鑰加密,形成消息的數(shù)字信封,將數(shù)字信封與DES加密后的消息一起發(fā)給接收方。接收方收到消息后,先用其密鑰打開數(shù)字信封,得到發(fā)送方的DES對稱密鑰,再用這些對稱密鑰去解開數(shù)據(jù)。SET既需保證支付數(shù)據(jù)的機密性,也需保證非支付數(shù)據(jù)的機密性6.3.4SET采用的安全措施2)應用數(shù)據(jù)簽名技術進行鑒別簽名技術在SET中有以下兩種應用形式:數(shù)字簽名。在SET中,數(shù)字簽名采用RSA算法,數(shù)據(jù)發(fā)送方采用自己的私鑰加密數(shù)據(jù),接收方用發(fā)送方的公鑰解密,由于私鑰和公鑰之間的嚴格對應性,使用其中一個加密只能用另一個來解密,保證了發(fā)送方不能抵賴發(fā)送過的數(shù)據(jù),完全模擬了現(xiàn)實生活

19、中的簽名。雙重簽名。6.3.4SET采用的安全措施使用X.509 v3數(shù)字證書來提供信任-SET中主要的證書是持卡人證書和商家證書。持卡人證書是支付卡的一種電子化的表示。持卡人證書內容是用單向哈希算法根據(jù)賬號和截止日期生成的一個編碼,如果知道賬號、截止日期、密碼值即可導出這個編碼-除了持卡人證書和商家證書以外,還有支付網(wǎng)關證書、銀行證書等。-網(wǎng)購中,持卡人的證書與發(fā)卡機構的證書關聯(lián),而發(fā)卡機構的證書通過不同品牌卡的證書連接到根CA,而根CA的公開密鑰對所有的SET軟件都是已知的,可以校驗每一個證書6.3.4SET采用的安全措施應用哈希函數(shù)保證數(shù)據(jù)完整性-數(shù)據(jù)完整性保證接收到的是實際發(fā)出的數(shù)據(jù),

20、SET中用從傳輸數(shù)據(jù)產(chǎn)生的完整性數(shù)值來實現(xiàn)這一功能。-SET將哈希函數(shù)和數(shù)字簽名結合起來使用,允許接收方驗證數(shù)據(jù)的來源和完整性,防止偽造和篡改。-在SET結構中,數(shù)字簽名是采用發(fā)送方私用密鑰加密支付數(shù)據(jù)的哈希值,該哈希值保證消息內數(shù)據(jù)的完整性。6.3.5SET和SSL的比較比較內容認證要求方面安全性方面網(wǎng)絡層協(xié)議位置方面應用領域方面SSL沒有提供商家身份認證機制;不能實現(xiàn)多方認證SSL只對持卡人與商家的信息交換進行加密保護;不具備商務性、服務性、協(xié)調性和集成性SSL是基于傳輸層的通用安全協(xié)議SSL主要是和Web應用一起工作SET所有參與SET交易的成員都必須申請數(shù)字證書,進行身份識別SET規(guī)范

21、了整個商務活動的流程;最大限度地保證了商務性、服務性、協(xié)調性和集成性SET位于應用層,對網(wǎng)絡上其他各層也有涉及SET是為信用卡交易提供安全6.4 安全超文本傳輸協(xié)議安全超文本傳輸協(xié)議(S-HTTP),是Web使用的HTTP的安全增強版本。S-HTTP協(xié)議為 HTTP 客戶機和服務器提供了多種安全機制S-HTTP為客戶機和服務器提供了相同的性能,同時維持HTTP的事務模型和實施特征S-HTTP 客戶機和服務器能與某些加密信息格式標準相結合,S-HTTP支持多種兼容方案并且與 HTTP 相兼容S-HTTP不需要客戶端公用密鑰認證(或公用密鑰),但它支持對稱密鑰的操作模式S-HTTP提供了完整且靈活的加密算法、模態(tài)及相關參數(shù)6.4.1S-HTTP協(xié)議簡介6.4.2 S-HTTP協(xié)議結構 在語法上,S-HTTP報文由請求或狀態(tài)行組成,后面是信頭和主體;S-HTTP報文由從客戶機到服務器的請求和從服務器到客戶機的響應組成。 請求報文的格式 請求行通用信息頭請求頭實體頭信息主體為了區(qū)分HTTP報文,S-HTTP需要特殊處理,請求行使用特殊的“安全”途徑和指定協(xié)議“S-HTTP/1.4”6.4.2 S-HTTP協(xié)議結構 S-HTTP響應采用指定協(xié)議“S-HTTP/1.4”。 響應報文的格式 注意,S-HTTP 響應行中的狀態(tài)并不表明展開的 HTTP 請求的成功或失敗。如果 S-H

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論