第八章 安全協(xié)議與安全標準

第8章

安全協(xié)議與安全標準

[本章要點]→電子商務安全服務支撐協(xié)議包含安全套接層協(xié)議SSL協(xié)議、安全電子傳輸規(guī)范SET協(xié)議、安全通信協(xié)議S-HTTP、Internet電子數(shù)據(jù)交換協(xié)議、互聯(lián)網安全協(xié)議IPSec安全協(xié)議。→其它三個重要的電子支付協(xié)議：Netbill協(xié)議、FirstVirtual協(xié)議、iKP協(xié)議?！鷥蓚€重要的安全電子郵件協(xié)議：PEM和S/MIME概述。→Windows2000的IPSec策略和SSL配置策略。→國際安全評估的五個準則。第8章安全協(xié)議與安全標準引例8匿名匯票“雙重花費”問題8.1安全協(xié)議概述8.2安全套接層協(xié)議8.3安全電子交易規(guī)范

8.4電子支付專用協(xié)議

8.5安全超文本傳輸協(xié)議

8.6安全電子郵件協(xié)議

8.7Internet電子數(shù)據(jù)交換協(xié)議

8.8IPSec安全協(xié)議

8.9安全技術評估標準

8.1安全協(xié)議概述

安全協(xié)議是參與完成加密行為步驟的完整集合的規(guī)范，包括在每種意外情況下如何繼續(xù)工作的顯式規(guī)范算法是一種范圍窄得多的過程，涉及將一些數(shù)字數(shù)據(jù)轉換成另一些數(shù)字數(shù)據(jù)。安全協(xié)議與算法的關系密碼協(xié)議不可避免地涉及到使用一種或更多密碼算法，但是安全性（以及其它密碼術目標）是整個協(xié)議的產物。將強大的算法構建到脆弱的協(xié)議中的很簡單的示例

考慮一種加密產品，設計成允許Alice通過電子郵件向Bob發(fā)送秘密消息。假設該產品采用了一種“不可破解的”算法E。如果協(xié)議的其它部分很脆弱，那么盡管有“不可破解的”算法，Mallory還是有很多方法截取Alice的明文。例如，Mallory可能有辦法截取密鑰，從而使得“不可破解的”加密形同虛設（可能沒有安全地存儲密鑰，或在發(fā)送時它本身缺乏足夠的安全性）。或者，明文并沒有在整個傳輸過程中始終作為密文存在，而是在它的部分“旅程”（比如說，從Alice的工作站到她的郵件服務器）中是作為更容易受攻擊的明文傳輸?shù)摹；蛘撸饷芎螅ɑ蛘咴谑紫燃用苤埃┛赡軟]有安全地存儲消息。說句套話，如果鏈條上的其它環(huán)節(jié)更脆弱，則Mallory不必攻擊“不可破解的”算法。誤導性的聲明某公司可能聲明：“如果使用我們的產品，您的數(shù)據(jù)將很安全，因為最快的計算機也要用一百萬年才能破解我們的加密法！”該聲明可能是真實的，但是仍然不足以證明這是一個非常好的產品。單是一個關于算法強度的真實聲明，未必就意味著采用該算法作為其中一個步驟的整個協(xié)議就沒有其它弱點了。8.2安全套接層協(xié)議

由美國Netscape公司1995年開發(fā)和倡導的安全套接層SSL協(xié)議（SecureSocketsLayer，SSL），它是目前安全電子商務交易中使用最多的協(xié)議之一。SSL主要用于提高應用程序之間的數(shù)據(jù)的安全系數(shù)。SSL協(xié)議的實現(xiàn)屬于SOCKET層，在Internet網絡層次中的位置處于應用層和傳輸層之間。

8.2.1SSL提供的安全服務8.2.2SSL協(xié)議的運行步驟8.2.3SSL體系結構8.2.4SSL的安全措施8.2.5SSL的安全性8.2.6Windows2000中SSL的配置與應用

8.2.1SSL提供的安全服務一、用戶和服務器的合法性認證

二、加密數(shù)據(jù)以隱藏被傳送的數(shù)據(jù)

三、保護數(shù)據(jù)的完整性

8.2.2SSL協(xié)議的運行步驟

①接通階段：客戶通過網絡向服務商打招呼，服務商回應；②密鑰交換階段：客戶與服務器之間交換雙方認可的密鑰，一般選用RSA密碼算法，也有的選用Diffie-Hellmanf和Fortezza-KEA密碼算法；③協(xié)商密鑰階段：客戶與服務商間產生彼此交談的會話密鑰；④檢驗階段：檢驗服務商取得的密鑰；⑤客戶認證階段：驗證客戶的可信度；⑥結束階段，客戶與服務商之間相互交換結束的信息。8.2.3SSL體系結構

HTTPSSL握手協(xié)議SSL更改密文規(guī)范協(xié)議SSL警告協(xié)議SSL記錄協(xié)議TCPIP8.2.4SSL的安全措施

SSL采用對稱密碼技術和公開密碼技術相結合，采用密碼和證書實現(xiàn)通信數(shù)據(jù)完整性、認證性等安全服務.安全措施：加密算法（RC4、RC2、IDEA、DES）和會話密鑰（MD5）

認證算法（X.509電子證書標準）服務器認證客戶端認證8.2.5SSL的安全性

優(yōu)點邏輯嚴密、完整、正確SSL協(xié)議有它獨到的“重傳攻擊”的解決辦法(連接序列號）

在我國應用SSL的缺點：系統(tǒng)不符合國務院最新規(guī)定系統(tǒng)安全性差

只能提供512bitRSA公鑰、40bit對稱密鑰8.3安全電子交易規(guī)范8.3.1SET提供的安全服務8.3.2SET協(xié)議的運行步驟8.3.3SET的體系結構8.3.4SET的安全措施8.3.5SET和SSL的比較

安全電子交易規(guī)范SET(SecureElectronicTransaction)是Visa和MasterCard于1997年5月聯(lián)合開發(fā)的一個加密和安全規(guī)范，它具有很強的安全性。該規(guī)范由若干以前發(fā)表的協(xié)議形成，它們是：STT(Visa/Microsoft)、SEPP(MasterCard)和iKP協(xié)議族(IBM)。SET及其適合的諸協(xié)議是基于安全信用卡協(xié)議的一個例子。由于它得到了IBM、HP、Microsoft、Netscape、VeriFone、GTE、Terisa和VeriSign等很多大公司的支持，已成為事實上的工業(yè)標準，目前已獲得IETF標準的認可。

8.3.1SET提供的安全服務

①確保在支付系統(tǒng)中支付信息和訂購信息的安全性；②確保數(shù)據(jù)在傳輸過程中的完整性，即確保數(shù)據(jù)在傳輸過程中不被破壞；③對持卡者身份的合法性進行檢查；④對商家身份的合法性進行檢查；⑤提供最優(yōu)的安全系統(tǒng)，以保護在電子貿易中的合法用戶；⑥確保該標準不依賴于傳輸安全技術，也不限定任何安全技術的使用；⑦使通過網絡和相應的軟件所進行的交互作業(yè)簡便易行

8.3.2SET協(xié)議的運行步驟

8.3.3SET的體系結構

SET支付系統(tǒng)的主要參與方有：l

持卡人，即消費者，他們通過web瀏覽器或客戶端軟件購物；

l

商家，提供在線商店或商品光盤給消費者；

l

發(fā)卡人，它是一金融機構，為持卡人開帳戶，并且發(fā)放支付卡；

l

收款銀行，它為商家建立帳戶，并且處理支付卡的認證和支付事宜l支付網關，是由受款銀行或指定的第三方操縱的設備，它處理商家的支付信息，

8.3.4SET的安全措施

通過加密保證信息機密性

應用數(shù)字簽名技術進行鑒別

使用X.509v3數(shù)字證書來提供信任

應用散列函數(shù)保證數(shù)據(jù)完整性

8.3.5SET和SSL的比較

SSL協(xié)議SET協(xié)議工作層次傳輸層與應用層之間應用層是否透明透明不透明過程簡單復雜效率高低安全性商家掌握消費者PI消費者PI對商家保密認證機制雙方認證多方認證是否專為EC設計否是8.4電子支付專用協(xié)議8.4.1NetBill協(xié)議8.4.2FirstVirtual協(xié)議8.4.3iKP協(xié)議

8.4.1NetBill協(xié)議圖8-7NetBill協(xié)議流程

8.4.2FirstVirtual協(xié)議

①戶把在FirstVirtual的ID號發(fā)給商家；②商家聯(lián)結FirstVirtual服務器驗證ID號的合法性，如果合法，商家把客戶所需的信息直接發(fā)送給客戶；③FirstVirtual服務器向客戶以E－mail形式發(fā)送詢問信息，征詢客戶是否愿意為其付費，客戶同樣以E－mail形式回復“是”或“否”。如果客戶的回復為“是”，F(xiàn)irstVirtual通過用戶信用卡的代理獲得相應的款項；④在90天的延時后，F(xiàn)irstVirtual服務器將款項轉給相應的商家。8.4.3iKP協(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é)議，它只要求支付網關擁有一對公私鑰，用戶和商戶只需擁有支付網關認證了的公鑰或經一個權威機構認證了的支付網關公鑰(該機構通過簽名證書來使支付網關的公鑰合法化)。這就涉及到了CA基礎設施，用戶通過他們的信用卡號和相關的PIN來認證。支付通過交換用支付網關的公鑰加了密的信用卡號和PIN以及限定的相關信息(諸如交易量、ID號等)來認證，1KP協(xié)議不能對用戶和商戶發(fā)送的消息提供非否認性，這就意味著不容易解決支付訂購的爭端。

2KP協(xié)議要求支付網關和商戶都擁有公鑰對和公鑰證書。協(xié)議對來自商戶發(fā)送的消息能提供非否認性。該協(xié)議能使用戶無需和任何在線第三方聯(lián)系，就能通過檢測證書來驗證與之進行交易的商戶的真實性。與1KP協(xié)議一樣，支付訂購是通過用戶的信用卡號和PIN來認證的(在傳輸之前要求加密)。3KP協(xié)議要求支付網關、顧客和商人三方都擁有公鑰對，并提供完全的多方安全。它對各方涉及到的所有的消息提供非否認性，支付訂購是通過顧客的信用卡號和PIN以及顧客的數(shù)字簽名來認證。該協(xié)議要求基礎設施提供顧客的公鑰證書。特別值得一提的是iKP協(xié)議只關心支付而未涉及訂貨和價格協(xié)商，這里假定這些方面已由商人和顧客事先決定好了，該協(xié)議也沒有明確地提供對訂購信息的加密，這種保護被假定由已存在的機構來完成，諸如SHTTP，SSL(注意：SSL不支持非否認性)等。

8.5安全超文本傳輸協(xié)議8.5.1S-HTTP協(xié)議概述8.5.2SSL與S-HTTP的比較

8.5.1S-HTTP協(xié)議概述S-HTTP是用于互聯(lián)網進行安全信息傳輸?shù)膮f(xié)議，該協(xié)議對客戶機和服務器雙方進行安全管理。S－HTTP建立在HTTP之上，S－HTTP好似HTTP規(guī)范之外的一個封閉層，旨為HTTP事務提供身份認證和加密手段。S－HTTP中的URL以shttp機制開頭。S-HTTP使用HTTP的MIME網絡數(shù)據(jù)包進行簽名、驗證和加密，數(shù)據(jù)加密可以采用對稱或非對稱加密。S-HTTP提供了文件級的安全機制。S-HTTP提供了對多種單向散列（Hash）函數(shù)的支持，如：MD2、MD5和SHA；對多種單鑰體制的支持，如：DES、三元DES、RC2、RC4和CDMF；對數(shù)字簽名體制的支持，如：RSA和DSS。8.5.2SSL與S-HTTP的比較

S-HTTP和SSL是從不同角度提供Web的安全性的。S－HTTP建立在HTTP之上，旨為HTTP事務提供身份認證和加密手段。SSL則建立在HTTP的下一層，并可用于FTPGopher等其他協(xié)議。S-HTTP對單個文件作“私人/簽字”之區(qū)分，而SSL則把參與相應進程之間的數(shù)據(jù)通道接“私用”和“已認證”進行監(jiān)管。目前SSL基本取代了S-HTTP。大多數(shù)Web貿易均采用傳統(tǒng)的Web協(xié)議，并使用SSL加密的HTTP來傳輸敏感的賬單信息。8.6安全電子郵件協(xié)議8.6.1保密增強郵件（PEM）8.6.2安全多功能Internet電子郵件擴充（S/MIME）8.6.3OutlookExpress下的安全電子郵件傳送

8.6.1保密增強郵件（PEM）保密增強郵件(PrivateEnhancedMail,PEM)是增強Internet電子郵件隱秘性的標準草案,是美國RSA實驗室基于RSA和DES算法而開發(fā)的產品,其目的是為了增強個人的隱私功能。它在Internet電子郵件的標準格式上增加了加密、鑒別和密鑰管理的功能，允許使用公開密鑰和專用密鑰的加密方式,并能夠支持多種加密工具。對于每個電子郵件報文可以在報文頭中規(guī)定特定的加密算法、數(shù)字鑒別算法、散列功能等安全措施。PEM是通過Internet傳輸安全性商務郵件的非正式標準。

8.6.2安全多功能Internet電子郵件擴充（S/MIME）

S/MIME是Secure/MultipurposeInternetMailExtensions的簡稱，它是Internet中用來發(fā)送安全電子郵件的協(xié)議。S/MIME為電子郵件提供了數(shù)字簽名和加密功能。該標準允許不同的電子郵件客戶程序彼此之間收發(fā)安全電子郵件。S/MIME是從PEM（PrivacyEnhancedMail）和MIME(Internet郵件的附件標準)發(fā)展而來的。

8.6.3OutlookExpress下的安全電子郵件傳送

一、獲取數(shù)字標識二、使用數(shù)字標識三、備份數(shù)字標識四、安全電子郵件8.7Internet電子數(shù)據(jù)交換協(xié)議8.7.1EDI消息處理原理8.7.2EDI系統(tǒng)面臨的安全威脅8.7.3EDI系統(tǒng)的安全策略8.7.4InternetEDI安全服務的實現(xiàn)

8.7.1EDI消息處理原理8.7.2EDI系統(tǒng)面臨的安全威脅

CCITTX.435建議中列出EDI系統(tǒng)面臨的主要威脅和攻擊，有以下六種：一、冒充二、篡改數(shù)據(jù)三、偷看、竊取數(shù)據(jù)四、文電丟失五、抵賴或失口否認六、拒絕服務

8.7.3EDI系統(tǒng)的安全策略

安全策略①他人無法冒充合法用戶利用網絡及其資源。②他人無法篡改、替換和擾亂數(shù)據(jù)。③與文電交換的各種活動及其發(fā)生時間均有精確、完整的記錄和審計。④確保文電在交換過程中不丟失。⑤確保商業(yè)文件(合同、契約、協(xié)議書……)不被無關者或競爭對手知悉。⑥防止因自然災害、人為原因和機器故障而引起的系統(tǒng)拒絕服務。EDI安全服務的內容有：①鑒別。包括對等實體鑒別和數(shù)據(jù)源鑒別。②訪問控制。保護網絡資源免受非法訪問和使用。③數(shù)據(jù)保密。保護數(shù)據(jù)不被第三者獲悉。④數(shù)據(jù)完整性。保護數(shù)據(jù)不被篡改、亂序、刪除和重復。⑤抗抵賴。防止發(fā)送者否認發(fā)送信息，接收者否認收到信息。8.7.4InternetEDI安全服務的實現(xiàn)

一、數(shù)字簽名二、文電加密三、源點不可抵賴四、接收不可抵賴。五、訪問控制六、文電丟失七、防拒絕服務8.8IPSec安全協(xié)議8.8.1IPSec組成8.8.2IPSec的工作原理8.8.3IP認證協(xié)議8.8.4IP安全封裝負載協(xié)議（ESP）8.8.5Windows2000的IPSec策略

為了改善現(xiàn)有IPv4協(xié)議在安全等方面的不足，IETF的下一代網絡協(xié)議(IPng)工作組于1995年底確定了IPng協(xié)議規(guī)范，稱為IP版本6(IPv6)。IPv6利用新的網絡安全體系結構IPSec，通過AH和ESP兩個安全協(xié)議分別為IP協(xié)議提供了基于無連接的數(shù)據(jù)完整性和數(shù)據(jù)保密性，加強了IP協(xié)議的安全，克服了原有IPv4協(xié)議安全的不足。IPv6為IP數(shù)據(jù)在IP層上實現(xiàn)數(shù)據(jù)完整性、數(shù)據(jù)保密性、認證、訪問控制和不可否認性等安全服務，并保證網絡上層應用程序不被改，同時實現(xiàn)IP網絡的通信安全。

8.8.1IPSec組成

IPSec安全協(xié)議有：ESP(EncapsulatingSecurityPayload)和AH(AuthenticationHeader)兩個安全協(xié)議。還有一系列與IPSec相關的技術標準，如加密算法及實現(xiàn)數(shù)據(jù)完整性的Hash算法的規(guī)范、密鑰的交換標準IKE(InternetKeyExchange)、安全關聯(lián)(SA)等。

8.8.2IPSec的工作原理

8.8.3IP認證協(xié)議（AH）AH協(xié)議是為IP數(shù)據(jù)報文提供數(shù)據(jù)源認證、無連接數(shù)據(jù)完整性檢測，同時也提供重放攻擊的保護。AH可以單獨使用，也可以與ESP結合一起使用，提供相連的主機之間、相連的安全網關之間和主機與網關之間的安全服務。AH還能維護數(shù)據(jù)的完整性，在傳輸過程中只要數(shù)據(jù)發(fā)生一點改變，數(shù)據(jù)包的認證和驗證都能將其檢測出來，從而保證數(shù)據(jù)的完整性驗證。AH不支持數(shù)據(jù)包的加密，因而AH無機密性保護。在AH標準中最普遍使用的認證算法是MD5和SHA-1，MD5使用最高到128位的密鑰，而SHA-1通過最高到160位密鑰提供更強的保護。8.8.4IP安全封裝負載協(xié)議（ESP）

ESP同AH一樣是提供IP的安全性，但它比AH有更強的安全性。ESP除了有AH對數(shù)據(jù)源的認證，數(shù)據(jù)完整性和反重放攻擊外，還提供數(shù)據(jù)保密和有限數(shù)據(jù)流保密服務。ESP的認證服務是通過使用消息認證碼(MAC)來實現(xiàn)，這與AH認證的使用一樣通過使用HMAC來達到對數(shù)據(jù)包的認證和完整性檢測。ESP協(xié)議可以單獨使用也可以與AH結合使用。在IPSec的規(guī)范中ESP