網(wǎng)絡(luò)安全協(xié)議(82張)課件_第1頁
網(wǎng)絡(luò)安全協(xié)議(82張)課件_第2頁
網(wǎng)絡(luò)安全協(xié)議(82張)課件_第3頁
網(wǎng)絡(luò)安全協(xié)議(82張)課件_第4頁
網(wǎng)絡(luò)安全協(xié)議(82張)課件_第5頁
已閱讀5頁,還剩79頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

1、章網(wǎng)絡(luò)安全協(xié)議 Internet在最初建立時的指導(dǎo)思想是資源共享,因此以開放性和可擴展性為核心。在建立協(xié)議模型與協(xié)議實現(xiàn)時,更多考慮到易用性,而在安全性方面考慮存在嚴(yán)重不足,這就給攻擊者造成了可乘之機。本章以TCP/IP協(xié)議族結(jié)構(gòu)為指導(dǎo),自底向上分層闡述不同層次的安全協(xié)議保障機制,主要包括PPP、IPSec、SSL/TLS、SET等。 引言第4章 網(wǎng)絡(luò)安全協(xié)議 4.1數(shù)據(jù)鏈路層安全通信協(xié)議 PPT協(xié)議;PPTP協(xié)議;L2TP協(xié)議4.2 網(wǎng)絡(luò)層安全通信協(xié)議 IPSec協(xié)議簇4.3傳輸層安全通信協(xié)議 SSL/TSL協(xié)議簇4.4應(yīng)用層安全通信協(xié)議 電子郵件安全協(xié)議;SET協(xié)議; SNMP協(xié)議;S-H

2、TTP協(xié)議4.1數(shù)據(jù)鏈路層安全通信協(xié)議 數(shù)據(jù)鏈路層對網(wǎng)絡(luò)層顯現(xiàn)為一條無錯的線路,主要任務(wù)是加強最底層物理層原始傳輸單位比特的功能,在兩個相鄰結(jié)點間的線路上無差錯地傳送以幀為單位的數(shù)據(jù),還要解決由于鏈路上的通信干擾造成數(shù)據(jù)幀的破壞、丟失而所需要的數(shù)據(jù)幀的重發(fā)以及流量的調(diào)節(jié)、出錯的處理和信道的共享等問題。 數(shù)據(jù)鏈路層加密就是簡單地對要通過物理媒介傳輸?shù)拿恳粋€字節(jié)進(jìn)行加密;解密則在收到時處理。這可以保證數(shù)據(jù)在鏈路上傳輸時不會被截獲。 4.1數(shù)據(jù)鏈路層安全通信協(xié)議 在數(shù)據(jù)鏈路層提供安全機制的優(yōu)點 :無需對其任何上層進(jìn)行改變就能對所有數(shù)據(jù)加密,提供鏈路安全能夠由硬件在數(shù)據(jù)傳輸和接收時輕易實現(xiàn),而且它對性

3、能的影響將會很小,能達(dá)到的速率最高;它能夠和數(shù)據(jù)壓縮很好的結(jié)合起來;對流分析能提供最高的保護性;對隱通道能提供最高的保護性;基于網(wǎng)絡(luò)攻擊的途徑最少。 4.1數(shù)據(jù)鏈路層安全通信協(xié)議 在數(shù)據(jù)鏈路層提供安全機制的缺點 :它只能應(yīng)用在兩個直連的設(shè)備上,而數(shù)據(jù)在網(wǎng)絡(luò)上傳輸時重要的是端到端的安全,在單獨的鏈路上加密并不能保證整個路徑的安全性;局域網(wǎng)并不能提供鏈路層安全,即對內(nèi)部攻擊人員無保護;最高的通信成本;新節(jié)點加入時要求電信公司重新配置網(wǎng)絡(luò)。 4.1.1 PPP協(xié)議 PPP (Point-to-Point Protocol)是“點對點”協(xié)議,它提供了基于廣域網(wǎng)的網(wǎng)絡(luò)層數(shù)據(jù)封裝和向上層提供物理透明性的功

4、能。PPP定義一種如何在點到點鏈路上傳輸多協(xié)議分組的封裝機制。 4.1.1 PPP協(xié)議 字段含義 :(1) 標(biāo)志字段(Flag)標(biāo)志幀的開始和結(jié)束,為一個字節(jié),值為0 x7e;(2) 地址字段(Address)為一個字節(jié),表示鏈路上站的地址;(3) 控制字段:也是一個字節(jié),其值也是固定值,為0 x03;(4) 協(xié)議字段:兩個字節(jié)組成,指示所封裝在信息字段的數(shù)據(jù)類型。 (5) 信息字段(Information)是由0或多個字節(jié)組成,由協(xié)議字段標(biāo)志的數(shù)據(jù)報構(gòu)成,信息字段的結(jié)束是由最近的標(biāo)志字段位確定的。 (6) 校驗字段(FCS)通常為兩個字節(jié),為提高檢測能力,可經(jīng)由協(xié)商,使用32位的校驗字段。

5、4.1.1 PPP協(xié)議建立失敗失敗NCP 配置認(rèn)證成功通信結(jié)束載波停止檢測到載波雙方協(xié)商一些選項認(rèn)證網(wǎng)絡(luò)打開終止靜止圖4.2 PPP協(xié)議的狀態(tài)圖 4.1.2 PPTP協(xié)議 點到點隧道協(xié)議(Point-Point Tunneling Protocol,RFC2637)是對PPP的擴展。由Microsoft和Ascend開發(fā)。PPTP使用一種增強的GRE(Generic Routing Encapsulation)封裝機制使PPP數(shù)據(jù)包按隧道方式穿越IP網(wǎng)絡(luò),并對傳送的PPP數(shù)據(jù)流進(jìn)行流量控制和擁塞控制。PPTP并不對PPP協(xié)議進(jìn)行任何修改,只提供了一種傳送PPP的機制,并增強了PPP的認(rèn)證、壓縮

6、、加密等功能。由于PPTP基于PPP協(xié)議,因而它支持多種網(wǎng)絡(luò)協(xié)議,可將IP、IPX、APPLETALK、NetBEUI的數(shù)據(jù)包封裝于PPP數(shù)據(jù)幀中。 4.1.2 PPTP協(xié)議 PPTP是一種用于讓遠(yuǎn)程用戶撥號連接到本地ISP(Internet Service Provider,Internet服務(wù)提供商),通過因特網(wǎng)安全遠(yuǎn)程訪問公司網(wǎng)絡(luò)資源的網(wǎng)絡(luò)技術(shù)。PPTP對PPP協(xié)議本身并沒有做任何修改,只是使用PPP建立撥號連接然后獲取這些PPP包并把它們封裝進(jìn)GRE頭中。PPTP使用PPP協(xié)議的PAP或CHAP進(jìn)行認(rèn)證,另外也支持Microsoft公司的點到點加密技術(shù)(MPPE)。PPTP支持的是一種

7、客戶-LAN型隧道的VPN實現(xiàn)。 4.1.2 PPTP協(xié)議 建立PPTP連接,首先要建立客戶端與本地ISP的PPP連接。一旦成功地接入因特網(wǎng),下一步就是建立PPTP連接。從最頂端PPP客戶端、PAC和PNS服務(wù)器之間開始,由已經(jīng)安裝好PPTP的PAC建立并管理PPTP任務(wù)。如果PPP客戶端將PPTP添加到它的協(xié)議中,所有列出來的PPTP通信都會在支持PPTP的客戶端上開始與終止。由于所有的通信都將在IP包內(nèi)通過隧道,因此PAC只起著通過PPP連接進(jìn)因特網(wǎng)的入口點的作用。從技術(shù)上講,PPP包從PPTP隧道的一端傳輸?shù)搅硪欢?,這種隧道對用戶是完全透明的。 4.1.2 PPTP協(xié)議 PPTP具有兩種

8、不同的工作模式:被動模式和主動模式。被動模式的PPTP會話通過一個一般是位于ISP處的前端處理器發(fā)起,在客戶端不需要安裝任何與PPTP有關(guān)的軟件。在撥號連接到ISP的過程中,ISP為用戶提供所有的相應(yīng)服務(wù)和幫助。被動方式好處是降低了對客戶的要求,缺點是限制了用戶對因特網(wǎng)其它部分的訪問。主動方式是由客戶建立一個與網(wǎng)絡(luò)另外一端服務(wù)器直接相連的PPTP隧道。這種方式不需要ISP的參與,不再需要位于ISP處的前端處理器,ISP只提供透明的傳輸通道。這種方式的優(yōu)點是客戶擁有對PPTP的絕對控制,缺點是對用戶的要求較高并需要在客戶端安裝支持PPTP的相應(yīng)軟件。 4.1.3 L2TP協(xié)議 第二層隧道協(xié)議L2

9、TP(Layer 2 Tunneling Protocol)是用來整合多協(xié)議撥號服務(wù)至現(xiàn)有的因特網(wǎng)服務(wù)提供商點。IETF(因特網(wǎng)工程任務(wù)組)的開放標(biāo)準(zhǔn)L2TP協(xié)議結(jié)合了PPTP協(xié)議和L2F的優(yōu)點,特別適合于組建遠(yuǎn)程接入方式的VPN,目前已經(jīng)成為事實上的工業(yè)標(biāo)準(zhǔn)。在由L2TP構(gòu)建的VPN中,有兩種類型的服務(wù)器,一種是L2TP訪問集中器LAC(L2TP Access Concentrator),它是附屬在網(wǎng)絡(luò)上的具有PPP端系統(tǒng)和L2TP協(xié)議處理能力的設(shè)備,LAC一般就是一個網(wǎng)絡(luò)接入服務(wù)器,用于為用戶提供網(wǎng)絡(luò)接入服務(wù);另一種是L2TP網(wǎng)絡(luò)服務(wù)器LNS(L2TP Network Server),是P

10、PP端系統(tǒng)上用于處理L2TP協(xié)議服務(wù)器端部分的軟件。4.1.3 L2TP協(xié)議 L2TP特點:(1)差錯控制 L2TP通過其包頭中的兩個字段Next Received和Next Sent進(jìn)行流控制和差錯檢測。 (2)地址分配 L2TP支持在NCP協(xié)商機制的基礎(chǔ)上動態(tài)分配客戶地址。 (3)身份認(rèn)證 具有身份認(rèn)證功能(4)安全性能 采用IPSec對LAC和LNS之間的IP包進(jìn)行加密傳送 4.1.3 L2TP協(xié)議 L2TP格式: T位為標(biāo)識消息類型。數(shù)據(jù)消息設(shè)置為0,控制消息設(shè)置為1如果L位為1,表示長度域存在。對于控制消息,必須設(shè)置為1; X位是為將來保留的擴展位。所有的保留位在呼出消息中必須設(shè)置為

11、0,在呼入消息中必須忽略。 若O位(序列號位)為1,則Ns和Nr域存在。對于控制消息來說,該位必須設(shè)置為1。 Ver(版本號)可以設(shè)置為2,標(biāo)明當(dāng)前的L2TP版本號為第二版?;蛘邽?,標(biāo)明當(dāng)前的L2TP版本號為第三版。 Length域標(biāo)識以八位組表示的消息長度。4.1.3 L2TP協(xié)議 L2TP格式: Tunnel ID指示控制鏈接的標(biāo)識符。只有本地有效的標(biāo)識符才能用來給L2TP tunnels命名。 Session ID指示一個tunnel內(nèi)的會話標(biāo)識符。只有本地有效的標(biāo)識符才能用來給L2TP session命名。 Ns指示數(shù)據(jù)或控制消息的序列號,從0開始,每發(fā)送一個消息其值加1。Nr指示下

12、一個期望被收到的控制消息的序列號。 Offset Size域如果存在,則表明運送的數(shù)據(jù)期望開始的地方。 4.1.3 L2TP協(xié)議 L2TP工作流程 :隧道建立、會話建立和PPP幀的封裝前轉(zhuǎn) (1)隧道建立 隧道建立就是L2TP控制連接的建立,通過控制連接管理類消息實現(xiàn),如圖4.5所示。LAC和LNS任一端均可發(fā)起隧道的建立,它包括兩輪消息交換.主要完成如下功能:LAC和LNS相互間的認(rèn)證,采用CHAP認(rèn)證算法;LAC和LNS各自為隧道分配隧道ID,并通知對方;確定隧道的承載類型和幀封裝類型;確定接收窗口尺寸;隧道終結(jié)可用StopCCN消息完成。 4.1.3 L2TP協(xié)議(2)會話建立 會話建立

13、過程由呼叫觸發(fā),在撥號接入的情況下,就是由用戶至LAC的入呼叫觸發(fā),其過程如圖4.6所示,由呼叫管理類消息實現(xiàn),類似隧道建立,消息過程將交換如下信息:LAC和LNS各自為會話分配的會話ID;數(shù)據(jù)信道的承載類型和幀封裝類型;主被叫號碼及子地址;收發(fā)線路速率;數(shù)據(jù)消息是否要加序號。 4.1.3 L2TP協(xié)議(3) PPP幀前轉(zhuǎn) 會話建立后進(jìn)入通信階段此時LAC收到遠(yuǎn)端用戶發(fā)來的PPP幀去除CRC校驗字段幀封裝字段和規(guī)避字段將其封裝入L2TP數(shù)據(jù)消息經(jīng)隧道前傳給LNS反向則執(zhí)行相反的過程。LAC在會話建立時可置入需要有序AVP則所有數(shù)據(jù)消息必須加序號如果LAC未作此請求則由LNS控制如果LNS在發(fā)出

14、的消息中置序號則LAC在其后發(fā)出的消息中亦置序號如果LNS不置序號LAC其后也不再置序號。 4.1.3 L2TP協(xié)議4.2 網(wǎng)絡(luò)層安全通信協(xié)議 從ISO/OSI互聯(lián)參考模型的七層體系結(jié)構(gòu)來看,網(wǎng)絡(luò)層是網(wǎng)絡(luò)傳輸過程中非常重要的一個功能層,它主要負(fù)責(zé)網(wǎng)絡(luò)地址的分配和網(wǎng)絡(luò)上數(shù)據(jù)包的路由選擇。因此,在網(wǎng)絡(luò)層提供安全服務(wù)實現(xiàn)網(wǎng)絡(luò)的安全訪問具有很多先天性的優(yōu)點。常見的安全認(rèn)證、數(shù)據(jù)加密、訪問控制、完整性鑒別等,都可以在網(wǎng)絡(luò)層實現(xiàn)。該層的安全協(xié)議主要有IPSec等。 IPSec的優(yōu)點提供強大的安全性,應(yīng)用于防火墻和路由器防火墻內(nèi)部的IPSec可以抵制旁路IPSec在傳輸層以下,對應(yīng)用程序透明IPSec對終端

15、用戶透明需要時可以為單個用戶提供安全性路由選擇應(yīng)用,IPSec保證:路由器的通告(新的路由器通告它的存在)來自被認(rèn)可的路由器鄰站通告(一個路由器嘗試與另一個路由選擇域的一臺路由器建立或維護鄰站關(guān)系)來自被認(rèn)可的路由器重定向報文來自于原始報文發(fā)給它的路由器路由選擇更新不會被假造4.2 網(wǎng)絡(luò)層安全通信協(xié)議 4.2 網(wǎng)絡(luò)層安全通信協(xié)議 在網(wǎng)絡(luò)層提供安全機制的缺點在于很難解決像數(shù)據(jù)的不可否認(rèn)之類的問題。因為若在網(wǎng)絡(luò)層來解決該類問題,則很難在一個多用戶的機器上實現(xiàn)對每個用戶的控制。但是我們也可以在終端主機上提供相應(yīng)的機制實現(xiàn)以用戶為基礎(chǔ)的安全保障。 因此,通過上面的比較如果想要實現(xiàn)網(wǎng)絡(luò)安全服務(wù)而又不愿意

16、重寫很多系統(tǒng)和應(yīng)用程序的話,唯一可行的方案就是在比較低的網(wǎng)絡(luò)層中加入安全服務(wù),它能夠提供所有的配置方案,如主機對主機、路由器對路由器、路由器對主機。 4.2.1 IPSec協(xié)議簇 IPSec(Internet Protocol Security)是IETF為了在IP層提供通信安全而制定的一套協(xié)議簇。它包括安全協(xié)議部分和密鑰協(xié)商部分:安全協(xié)議部分定義了對通信的安全保護機制;密鑰協(xié)商部分定義了如何為安全協(xié)議協(xié)商保護參數(shù)以及如何對通信實體的身份進(jìn)行鑒別。 IPSec安全協(xié)議部分給出了封裝安全載荷ESP (Encapsulation Security Payload)和鑒別頭AH (Authentic

17、ation Header)兩種通信保護機制。其中ESP機制為通信提供機密性和完整性保護,AH機制為通信提供完整性保護。IPSec密鑰協(xié)商部分使用IKE (Internet Key Exchange)協(xié)議實現(xiàn)安全協(xié)議的自動安全參數(shù)協(xié)商,IKE協(xié)商的安全參數(shù)包括加密機制散列機制、認(rèn)證機制、Diffie-Hellman組密鑰資源以及IKE SA協(xié)商的時間限制等,同時IKE還負(fù)責(zé)這些安全參數(shù)的刷新。 4.2.1 IPSec協(xié)議簇 體系結(jié)構(gòu):一般性概念、安全需求、定義和機制封裝化安全凈荷ESP認(rèn)證頭標(biāo)AH加密算法:不同的加密算法如何應(yīng)用于ESP認(rèn)證算法:不同的鑒別算法如何應(yīng)用于AH和ESP密鑰管理:密鑰

18、管理機制解釋域DOI:包含了其他文檔需要的為了彼此之間相互聯(lián)系的一些值4.2.1 IPSec協(xié)議簇 IPSec在TCP/IP 協(xié)議簇中的位置 關(guān)聯(lián)是在發(fā)送者和為進(jìn)出通信提供安全服務(wù)的接收者之間的一種單向關(guān)系,如果需要一個對等的關(guān)系用于雙向的安全交換,就要兩個關(guān)聯(lián)。提供給一個SA的安全服務(wù)用于AH或ESP,但不能同時用于兩者。安全關(guān)聯(lián)由三個參數(shù)標(biāo)識安全參數(shù)索引SPI:SPI加載在AH和ESP的首部,使接收系統(tǒng)能夠選擇SA來處理接收的分組IP目的地址:SA的目的地址,端用戶或網(wǎng)絡(luò)安全協(xié)議標(biāo)識符:指出這個關(guān)聯(lián)是否AH或ESP安全關(guān)聯(lián) AH: Authentication Header ESP: En

19、capsulation Security Payload安全關(guān)聯(lián)(Security Associations)4.2.1 IPSec協(xié)議簇 序號計數(shù)器溢出:用于指示序號計數(shù)器的溢出是否生成可檢查的事件,防止在這個SA上繼續(xù)傳輸反重放窗口:確定進(jìn)入的AH或ESP分組是否是重放分組AH信息:認(rèn)證算法、密鑰及密鑰生存期等ESP信息:加密和認(rèn)證算法、密鑰及密鑰生存期等安全關(guān)聯(lián)生存期:一個時間區(qū)間或字節(jié)計數(shù),在這之后,SA被一個新的SA和新的SPI代替或終止IPSec協(xié)議方式:隧道方式、傳輸或通配符方式Path路徑MTU:可觀察的路徑的最大傳輸單元SA參數(shù)4.2.1 IPSec協(xié)議簇 IP通信量和特定的

20、SA相聯(lián)系的方式是名義上的安全策略數(shù)據(jù)庫SPD,每個SPD項通過IP和稱為選擇器的上層協(xié)議字段值的集合來定義。實際上這些選擇器是用來過濾輸出通信量的,目的是將其映射到特定的SA。對于每個IP分組,輸出處理遵從以下順序:將分組相應(yīng)字段的值與SPD比較以找到匹配的SPD項,后者將指向0個或多個SA如果這個分組存在SA,確定SA和它關(guān)聯(lián)的SPI完成需要的IPSec處理,即AH或ESPSA選擇器4.2.1 IPSec協(xié)議簇 4.2.1 IPSec協(xié)議簇 IPSec處理過程 4.2.1 IPSec協(xié)議簇 IPSec處理過程 IPSec輸入模塊執(zhí)行如下:(1)從AH協(xié)議頭或ESP協(xié)議頭中取安全參數(shù)索引SP

21、I,并從IP協(xié)議頭中取得目標(biāo)IP地址以及協(xié)議類型。(2)以三元組為選擇符查詢安全聯(lián)盟數(shù)據(jù)庫SADB,得到所需的安全聯(lián)盟SA。(3)如果查詢SADB返回為NULL,表明記錄出錯這個報文被丟棄。(4)如果查詢SADB返回一個SA項,則根據(jù)該項指示的變換策略調(diào)用相應(yīng)的AH認(rèn)證或ESP解密操作。(5)AH驗證和ESP解密操作成功后需檢查對這個報文應(yīng)用的策略是否正確,根據(jù)驗證和解密后數(shù)據(jù)報文的內(nèi)部IP地址查詢安全策略庫SPDB,如果對這個報文的安全服務(wù)與相應(yīng)SPDB項相符則說明處理正確,并將外部IP頭連同IPSec頭一起剝?nèi)?nèi)部IP報文傳回IP層處理。 4.2.1 IPSec協(xié)議簇 IPSec處理過程

22、 IPSec輸出處理模塊以(源IP地址,目的IP地址,安全協(xié)議標(biāo)識符端口號)為參數(shù)調(diào)用配置查詢模塊,查詢對應(yīng)的SPDB策略。若用戶沒有定義安全策略數(shù)據(jù)庫或者在查詢時未找到對應(yīng)的SPDB項,則丟棄報文,否則按以下三種情況處理: (1)如果策略指明需丟棄該報文,就返回IP層的調(diào)用進(jìn)程說明希望丟棄該報文。 (2)如果策略指明無需安全保護,就返回調(diào)用進(jìn)程以普通方式傳輸此報文。 (3)如果策略指明需要安全保護,這時需要驗證SA是否已建立如果已建立,就調(diào)用相應(yīng)的ESP或AH函數(shù)對IP報文進(jìn)行變換處理,并將結(jié)果返回IP層調(diào)用進(jìn)程(多個SA需要進(jìn)行多次變換處理)。如果SA尚未建立,策略引擎根據(jù)用戶配置的安全策

23、略,通知Internet密鑰協(xié)商(IKE)模塊創(chuàng)建SA。4.2.1 IPSec協(xié)議簇 IPSec中的主要協(xié)議 (1)AH(Authentieation Header) AH協(xié)議為IP報文提供數(shù)據(jù)完整性、數(shù)據(jù)源驗證以及可選擇的抗重放攻擊保護,但不提供數(shù)據(jù)加密服務(wù)。對AH的詳細(xì)描述在RFC2402中。AH協(xié)議使用散列技術(shù)來驗證數(shù)據(jù)完整性和驗證數(shù)據(jù)源。常用的散列函數(shù)有MD5、SHA-1、HMAC-MD5、 HMAC-SHA-1等。注意:AH不對受保護的IP數(shù)據(jù)報的任何部分進(jìn)行加密。由于AH不提供機密性保證,所以它也不需要加密算法。AH可用來保護一個上層協(xié)議(傳輸模式)或一個完整的IP數(shù)據(jù)報(隧道模式

24、) 它既可以單獨使用也可以和ESP聯(lián)合使用。 4.2.1 IPSec協(xié)議簇 IPSec中的主要協(xié)議 (1)AH(Authentieation Header) 4.2.1 IPSec協(xié)議簇 IPSec中的主要協(xié)議 (1)AH(Authentieation Header) AH封裝劃分為兩種模式:傳輸模式和隧道模式。如果將AH頭插入IP頭和路由擴展頭之后,上層協(xié)議數(shù)據(jù)和端到端擴展頭之前,則稱這種封裝為傳輸模式;如果將AH頭插入原IP分組的IP頭之前,并在AH頭之前插入新的IP頭,則稱這種封裝為隧道模式。 傳輸方式和隧道方式4.2.1 IPSec協(xié)議簇 IPSec中的主要協(xié)議 (2)ESP(Enca

25、psulating Security Payload)ESP協(xié)議為保證重要數(shù)據(jù)在公網(wǎng)傳輸時不被他人竊取,除了提供AH提供的所有服務(wù)外還提供數(shù)據(jù)加密服務(wù)。常用的數(shù)據(jù)加密方法有:DES,3DES等。ESP通過使用消息碼提供認(rèn)證服務(wù),常用的認(rèn)證算法有:HMAC-MD5,HMAC-SHA-1等。ESP是一個通用的易擴展的安全機制,它把基本的ESP定義和實際提供安全服務(wù)的算法分開。其加密算法和認(rèn)證算法是由ESP安全聯(lián)盟的相應(yīng)組件所決定的。同樣,ESP通過插入一個唯一的單向遞增的序列號提供抗重放攻擊的服務(wù)。4.2.1 IPSec協(xié)議簇 IPSec中的主要協(xié)議 (2)ESP(Encapsulating Se

26、curity Payload)4.2.1 IPSec協(xié)議簇 (2)ESP(Encapsulating Security Payload) ESP封裝的兩種模式:傳輸模式和隧道模式。 IPSec Services4.2.1 IPSec協(xié)議簇 IPSec中的主要協(xié)議 (3)IKE(Internet Key Exchange) Internet密鑰交換協(xié)議(IKE)是一個以受保護方式為SA協(xié)商并提供經(jīng)認(rèn)證的密鑰信息的協(xié)議。用IPSec保護一個IP包之前,必須先建立一個安全關(guān)聯(lián)(SA)。正如前面指出的那樣,SA可以手工建立或動態(tài)建立。IKE用于動態(tài)建立SA。IKE代表IPSec對SA進(jìn)行協(xié)商,并對安全

27、關(guān)聯(lián)數(shù)據(jù)庫(SADB)進(jìn)行填充。IKE由RFC2409文件描述。IKE實際上是一種混合型協(xié)議,它建立在由Internet安全關(guān)聯(lián)和密鑰管理協(xié)議(ISAKMP,Internet Security Association and Key Management Protocol)定義的一個框架上。同時IKE還實現(xiàn)了兩種密鑰管理協(xié)議(Oakley和SKEME)的一部分。 IKE協(xié)商的安全參數(shù)包括加密機制、散列機制、認(rèn)證機制、Diffie-Hellman組、密鑰資源以及IKE SA協(xié)商的時間限制等。其交換的最終結(jié)果是一個通過驗證的密鑰以及建立在雙方同意基礎(chǔ)上的安全聯(lián)盟。由于IKE同時借鑒了ISAKMP

28、SA中的“階段”概念和OAKLEY協(xié)議中的“模式”概念,所以在IKE的分階段交換中,每個階段都存在不同的交換模式。 4.2.1 IPSec協(xié)議簇 IPSec中的主要協(xié)議 (3)IKE(Internet Key Exchange) IKE將密鑰交換分成兩個階段,在第一個階段,就是ISAKMP SA的建立階段,通信實體之間建立一個經(jīng)過認(rèn)證的安全通道,用于保護階段2中消息的安全。階段1的交換模式有兩種:分別是主模式和積極模式: 主模式實際上是ISAKMP中定義的身份保護交換模式的一個具體實例化,它提供了對交換實體的身份保護,交換雙方在主模式中要交換三對共六條消息,頭兩條消息進(jìn)行cookie交換和協(xié)商

29、策略,包括加密算法、散列算法及認(rèn)證方法等;中間兩條用于交換Diffie-Hellman公開值和一些必要的輔助數(shù)據(jù),例如現(xiàn)時載荷Nonce等;最后兩條消息用于驗證DH交換和身份信息。 4.2.1 IPSec協(xié)議簇 IPSec中的主要協(xié)議 (3)IKE(Internet Key Exchange) 積極模式則是ISAKMP中積極交換模式的具體實例化,積極模式通常要求交換三條消息,前兩條消息用于安全策略協(xié)商,交換DH公開值和一些輔助數(shù)據(jù),并且在第二條消息中還要認(rèn)證響應(yīng)者的身份;第三條消息用于對發(fā)起者的身份進(jìn)行認(rèn)證,并提供參與交換的證據(jù)。由此可見,積極模式能夠減少協(xié)商的步驟并加快協(xié)商的過程。 階段2是

30、在階段1建立起的ISAKMP SA的基礎(chǔ)上,為特定的協(xié)議協(xié)商SA,用于保護通信雙方的數(shù)據(jù)傳輸安全。階段2的交換模式為“快速交換模式”。在階段2中,可由通信的任何一方發(fā)起一個快速模式(Quick Mode)交換,其目的是建立針對某一安全協(xié)議的SA,即建立用于保護通信數(shù)據(jù)的IPSecSA。一個階段1協(xié)商可以用于保護多個階段2協(xié)商,一個階段2協(xié)商可以同時請求多個安全關(guān)聯(lián)。 4.3 傳輸層安全通信協(xié)議 傳輸層的任務(wù)就是提供主機中兩個進(jìn)程之間的通信,其數(shù)據(jù)傳輸單位是報文段,而網(wǎng)絡(luò)層是提供主機與主機之間的邏輯通信。在協(xié)議棧中,傳輸層正好位于網(wǎng)絡(luò)層之上,傳輸層安全協(xié)議是為進(jìn)程之間的數(shù)據(jù)通信增加安全屬性,如S

31、SL/TLS等。 在傳輸層提供安全機制的優(yōu)點在于:它不需要強制為每個應(yīng)用作安全方面的改進(jìn);傳輸層能夠為不同的通信應(yīng)用配置不同的安全策略和密鑰。 在傳輸層提供安全機制的缺點在于傳輸層不可能提供類似于“隧道”(路由器對路由器)和“防火墻”(路由器對主機)這樣的服務(wù)。4.3.1 SSL/TLS協(xié)議簇 1995年,Netscape公司在瀏覽器Netscape1.1中加入了安全套接層協(xié)議SSL(Secure Socket Layer),以保護瀏覽器和Web服務(wù)器之間重要數(shù)據(jù)的傳輸,該協(xié)議的第一個成熟的版本是SSL2.0版,并被集成到Netscape公司的Internet產(chǎn)品中,包括Navigator瀏覽

32、器和Web服務(wù)器產(chǎn)品等。SSLv2.0的出現(xiàn),基本上解決了Web通信協(xié)議的安全問題,很快引起了大家的關(guān)注。1996年,Netscape公司發(fā)布了SSLv3.0draft-freier-ssl-version3-02:The SSL Protocol Version 3.0,該版本相比SSLv2.0更加成熟和穩(wěn)定,因此,很快就成為了事實上的工業(yè)標(biāo)準(zhǔn)。 SSL and TLS SSL was originated by NetscapeTLS working group was formed within IETFFirst version of TLS can be viewed as an S

33、SLv3.1SSL ArchitectureIPHTTP/ S- HTTPFTPSMTPTCPSSL or TLS4.3.1 SSL/TLS協(xié)議簇 SSL會話和SSL連接連接:提供恰當(dāng)類型服務(wù)的傳輸會話:客戶和服務(wù)器之間的關(guān)聯(lián),通過握手協(xié)議來創(chuàng)建會話狀態(tài)的定義會話標(biāo)識符、對方證書、壓縮方法、密文規(guī)約、主密碼、可重新開始連接狀態(tài)的定義服務(wù)器和客戶機的隨機數(shù)、服務(wù)器寫MAC密碼、客戶寫MAC密碼、服務(wù)器寫密鑰、客戶寫密鑰、初始化向量、序號4.3.1 SSL/TLS協(xié)議簇 SSL記錄協(xié)議為SSL連接提供兩種服務(wù)機密性:握手協(xié)議定義了共享的、可以用于對SSL有效載荷進(jìn)行常規(guī)加密的密鑰報文完整性:握手協(xié)

34、議定義了共享的、可以用來形成報文的鑒別碼MAC的密鑰4.3.1 SSL/TLS協(xié)議簇 4.3.1 SSL/TLS協(xié)議簇 握手協(xié)議 握手協(xié)議是SSL/TLS中最為重要的一個協(xié)議,它負(fù)責(zé)在建立安全連接之前在SSL/TLS客戶代理和SSL/TLS服務(wù)器之間鑒別雙方身份、協(xié)商加密算法和密鑰參數(shù),為建立一條安全的通信連接做好準(zhǔn)備。握手消息的結(jié)構(gòu)如圖4.20所示 四個階段:建立安全能力、服務(wù)器鑒別和密鑰交換、客戶鑒別和密鑰交換、結(jié)束4.3.1 SSL/TLS協(xié)議簇 SSL握手協(xié)議報文的類型4.3.1 SSL/TLS協(xié)議簇 握手協(xié)議過程階段1:建立安全能力開始邏輯連接并建立和這個連接關(guān)聯(lián)的安全能力,客戶發(fā)送

35、client_hello報文發(fā)起交換,包括參數(shù)版本、隨機數(shù)、安全I(xiàn)D、密文族、壓縮方式,然后等待server_hello報文密鑰交換方式,包括RSA、固定的Diffie-Hellman、短暫的Diffie-Hellman、匿名Diffie-Hellman、Fortezza密文規(guī)約CipherSpec,包括加密算法、MAC算法、加密類型、輸出(真或假)、散列大小、密鑰素材、IV大小階段2:服務(wù)器鑒別和密鑰交換發(fā)送server_key_exchange報文非匿名服務(wù)器向客戶請求證書certificate_request結(jié)束報文certificate_done階段3:客戶鑒別和密鑰交換客戶驗證服務(wù)器

36、是否提供了合法證書,檢查服務(wù)器Hello參數(shù)是可接受的,發(fā)送報文給服務(wù)器如果服務(wù)器請求證書,客戶通過發(fā)送certificate報文來開始這個階段;如無合適證書,發(fā)送no_alert發(fā)送client_key_exchange,密鑰交換方式包括RSA、固定的Diffie-Hellman、短暫的Diffie-Hellman、匿名Diffie-Hellman、Fortezza最后發(fā)送certificate_verify報文提供驗證階段4:結(jié)束,完成握手協(xié)議(完成安全連接的建立)客戶發(fā)送change_cipher_spec報文,將掛起的CipherSpec復(fù)制到當(dāng)前的CipherSpec發(fā)送finish

37、ed,驗證密鑰交換和鑒別過程是成功的服務(wù)器客戶發(fā)送change_cipher_spec報文,將掛起的CipherSpec復(fù)制到當(dāng)前的CipherSpec服務(wù)器發(fā)送finished報文,握手完成,開始交換應(yīng)用層數(shù)據(jù) 網(wǎng)絡(luò)層安全協(xié)議只是為主機與主機的數(shù)據(jù)通信增加安全性,而傳輸層安全協(xié)議是為進(jìn)程之間的數(shù)據(jù)通信增加安全屬性。這兩個安全協(xié)議并不區(qū)分一個具體應(yīng)用程序的要求,只要在主機之間或進(jìn)程之間建立起一條安全通道,那么根據(jù)此協(xié)議,所有通過該安全通道的信息都要自動用同一種方式進(jìn)行數(shù)據(jù)安全加密。如果要根據(jù)某個具體的應(yīng)用程序?qū)Π踩膶嶋H要求來進(jìn)行安全加密的話,就必須要借助于應(yīng)用層的安全協(xié)議,也只有應(yīng)用層才能夠

38、對癥下藥,才能夠提供這種特定的安全服務(wù)。應(yīng)用層安全協(xié)議主要有:S/MIME、PGP、PEM、SET、Kerberos、SHTTP、SSH等。 4.4 應(yīng)用層安全通信協(xié)議 4.4 應(yīng)用層安全通信協(xié)議 在應(yīng)用層提供安全機制的優(yōu)點在于:以用戶為背景執(zhí)行,因此更容易訪問用戶憑據(jù),比如私人密鑰等;對用戶想保護的數(shù)據(jù)具有完整的訪問權(quán),簡化了提供某些特殊的服務(wù)的工作,比如不可抵賴性;應(yīng)用可自由擴展,不必依賴操作系統(tǒng)來提供。由此可見安全服務(wù)直接在應(yīng)用層上處理單獨應(yīng)用需求是最靈活的方法,例如一個郵件系統(tǒng)可能需要對發(fā)出的郵件進(jìn)行簽名這在由低層提供安全服務(wù)的情況下是無法實現(xiàn)的,因為它不知道郵件的結(jié)構(gòu)和哪些部分需要簽

39、名。所以無論低層協(xié)議能提供何種形式的安全功能,在應(yīng)用層提供安全服務(wù)是有理由的。 在應(yīng)用層提供安全機制的缺點在于:針對每個應(yīng)用,都要單獨設(shè)計一套安全機制。這意味著對現(xiàn)有的很多應(yīng)用來說,必須進(jìn)行修改才能提供安全保障。 1. PGP PGP(Pretty Good Privacy)是Phillip Zimmerman在1991年提出來的,它既是一種規(guī)范也是一種應(yīng)用,已經(jīng)成為全球范圍內(nèi)流行的安全郵件系統(tǒng)之一。PGP是一個完整的電子郵件安全軟件包,它包含四個密碼單元:對稱加密算法、非對稱加密算法、單向散列算法以及隨機數(shù)產(chǎn)生器。它的特點是通過單向散列算法對郵件體進(jìn)行簽名,以保證郵件體無法修改,使用對稱和非

40、對稱密碼相結(jié)合的技術(shù)保證郵件體保密且不可否認(rèn)。通信雙方的公鑰發(fā)布在公開的地方,如FTP站點,而公鑰本身的權(quán)威性則可由第三方(特別是收信方信任的第三方)進(jìn)行簽名認(rèn)證。 4.4.1 電子郵件安全協(xié)議 PGP(Pretty Good Privacy)Philip R. Zimmerman的主要工作選擇了最好的加密算法作為基礎(chǔ)構(gòu)件集成加密算法,形成通用的應(yīng)用程序制作軟件包和文檔,包括源碼,免費提供提供完全兼容的低價格的商用版本PGP快速發(fā)展和流行的原因免費獲得,運行不同平臺的多個版本建立在普遍認(rèn)為非常安全的算法的基礎(chǔ)上應(yīng)用范圍廣泛不受任何組織和政府控制 PGP的加密解密過程:(1)根據(jù)一些隨機的環(huán)境數(shù)

41、據(jù)(如擊鍵信息)產(chǎn)生一個密鑰。(2)發(fā)送者采用對稱加密算法,使用會話密鑰對報文進(jìn)行加密。(3)發(fā)送者采用非對稱加密算法,使用接收者的公開密鑰對會話密鑰進(jìn)行加密,并與加密報文結(jié)合。(4)接收者采用同一非對稱密碼算法,使用自己的私有密鑰解密和恢復(fù)會話密鑰。(5)接收者使用會話密鑰解密報文。 4.4.1 電子郵件安全協(xié)議 PGP的簽名驗證過程:(1)PGP根據(jù)報文內(nèi)容,利用單向hash函數(shù)計算出定長的報文摘要。(2)發(fā)送者用自己的私鑰對報文摘要進(jìn)行加密得到數(shù)字簽名。(3)發(fā)送者把報文和數(shù)字簽名一起打包傳送給接收者。(4)接收者用相同的單向hash函數(shù)計算接收到的報文的摘要。(5)接收者用發(fā)送者的公鑰

42、解密接收到的數(shù)字簽名。(6)接收者比較(4)、(5)步計算的結(jié)果是否相同,相同則表示驗證通過,否則拒絕。4.4.1 電子郵件安全協(xié)議 PGP提供的服務(wù) 2. S/MIME S/MIME是Secure/Multipurpose Internet Mail Extension的簡稱。它是從PEM(Privacy Enhanced Mail)和MIME(Internet郵件的附件標(biāo)準(zhǔn))發(fā)展而來的。S/MIME集成了三類標(biāo)準(zhǔn):MIME(RFC1521),加密消息語法標(biāo)準(zhǔn)(Cryptographic Message Syntax Standard)和證書請求語法標(biāo)準(zhǔn)(Certification Requ

43、est Syntax Standard)。 S/MIME與PGP主要有兩點不同:它的認(rèn)證機制依賴于層次結(jié)構(gòu)的證書認(rèn)證機構(gòu),所有下一級的組織和個人的證書由上一級的組織負(fù)責(zé)認(rèn)證,而最上一級的組織(根證書)之間相互認(rèn)證,整個信任關(guān)系基本是樹狀的,這就是所謂的Tree of Trust。還有,S/MIME將信件內(nèi)容加密簽名后作為特殊的附件傳送,它的證書格式采用X.509 V3相符的公鑰證書。 4.4.1 電子郵件安全協(xié)議 表4.2 S/MIME的各種服務(wù)4.4.1 電子郵件安全協(xié)議 MISE內(nèi)容類型MISE子類型S/MIME類型S/MIME服務(wù)附件擴展名應(yīng)用PKcs7-MIMS簽名數(shù)據(jù)保證數(shù)據(jù)的完整性

44、、認(rèn)證和無法否認(rèn)接收;使用不透明簽名.p7m封裝數(shù)據(jù)保證數(shù)據(jù)的真實性.p7m復(fù)合SignedNA保證數(shù)據(jù)的完整性,認(rèn)證和無法否認(rèn)接收;使用透明簽名NA應(yīng)用Pkcs7-signatureNA保證數(shù)據(jù)的完整性,認(rèn)證和無法否認(rèn)接收;使用透明簽名.p7s4.4.2 SET協(xié)議 SET(Secure Electronic Transaction)協(xié)議是由VISA和MasterCard等國際信用卡組織于1997年提出的一種電子商務(wù)協(xié)議,它被設(shè)計為開放的電子交易信息加密和安全的規(guī)范,可為Internet公網(wǎng)上的電子交易提供整套安全解決方案:確保交易信息的保密性和完整性;確保交易參與方身份的合法性;確保交易的

45、不可抵賴性。SET本身不是一個支付系統(tǒng),它是一個安全協(xié)議和格式規(guī)范的集合。它可以使用戶以一種安全的方式在公共、開放的Internet上傳送銀行帳戶等敏感信息。從本質(zhì)上講,SET提供了三種服務(wù): 在參與交易的各方之間建立安全的通信信道。 通過使用符合X.509規(guī)定的數(shù)字證書來提供身份認(rèn)證和信任。 為了保證安全性,只有在必要的時候、必要的交易階段才向必要的交易參與方提供必要的交易信息。 4.4.2 SET協(xié)議 SET協(xié)議主要特征:(1)信息的保密性。即客戶的帳號、密碼等支付信息在通過網(wǎng)絡(luò)傳輸?shù)臅r候應(yīng)該是安全的。它區(qū)別于SSL 的一個最重要的特征是,防止商家得到客戶的信用卡號碼。因為支付信息應(yīng)該是只

46、有銀行才可以看到的。同樣,也應(yīng)該防止銀行看到客戶的訂單信息,訂單信息應(yīng)該是只有商家才可以看到的。這樣明顯的職責(zé)分割將提高整個交易過程的保密性。(2)數(shù)據(jù)的完整性。即客戶的訂單信息和支付信息,以及商家向銀行所發(fā)出的支付授權(quán)的內(nèi)容均應(yīng)該在傳輸?shù)倪^程中保持原來的樣子,而不能被不懷好意的人修改。而且還應(yīng)該保證,即使被別人修改之后,在交易的下一個環(huán)節(jié)中,交易參與方可以及時的發(fā)現(xiàn)并中止本次電子交易的過程,然后等待有效信息的到來。(3)不可抵賴性。即可在交易過程中判斷當(dāng)前交易的參與方是否是合法認(rèn)證證書的持有者,以及是否是他所聲稱的那個人。這樣,通過身份認(rèn)證的交易參與方將對交易過程中發(fā)生的一切相關(guān)責(zé)任負(fù)責(zé)。S

47、ET ParticipantsSequence of events for transactionsThe customer opens an account.The customer receives a certificate.Merchants have their own certificates.The customer places an order.The merchant is verified.The order and payment are sent.The merchant request payment authorization.The merchant confi

48、rm the order.The merchant provides the goods or service.The merchant requests payments.4.4.3 SNMP協(xié)議 SNMP協(xié)議在研發(fā)之初并沒有過多地考慮協(xié)議本身的安全問題,因為當(dāng)時網(wǎng)絡(luò)規(guī)模比較小。而當(dāng)Internet的迅猛發(fā)展,網(wǎng)絡(luò)規(guī)模不斷擴大,SNMP安全問題越來越成為其發(fā)展的障礙,為此IETF工作組在不斷努力,試圖改變這種局面。在IETF的努力下,從SNMPv2開始,在研發(fā)SNMP協(xié)議時,安全問題得到充分考慮。SNMPv3在安全方面發(fā)揮到了目前情況下SNMP協(xié)議的極致。本節(jié)主要介紹SNMP協(xié)議的安全機制。

49、 4.4.3 SNMP協(xié)議 1. SNMPv1安全機制 SNMPv1的安全機制很簡單,只是驗證SNMP消息中的團體名。屬于同一團體的管理和被管理代理才能互相作用,發(fā)送給不同團體的報文被忽略。 (1)團體(Community) :SNMP的團體是一個代理和多個管理站之間的認(rèn)證和訪問控制關(guān)系。 (2)簡單的認(rèn)證服務(wù)一般來說,認(rèn)證服務(wù)的目的是保證通信是經(jīng)過授權(quán)的。在SNMP中,認(rèn)證服務(wù)主要是保證接收的報文來自它所聲稱的源。 4.4.3 SNMP協(xié)議 2SNMPv2安全機制 為了解決SNMPv1安全問題,SNMPv2發(fā)展可謂曲折漫長,先后開發(fā)了如下的協(xié)議版本:基于參加者SNMPsec、基于參加者SNM

50、Pv2p、基于共同體名的SNMPv2c、基于用戶的SNMPv2u、基于用戶的SNMPv2*等。 SNMPv2加密報文如圖4.27所示: privDst:指向目標(biāo)參加者的對象標(biāo)識符,即報文的接收者,這一部分是明文。 privData(SnmpAuthMsg):經(jīng)過加密的報文,接收者需解密后才可以閱讀。 被加密報文為SnmpAuthMsg,包含下列內(nèi)容: 4.4.3 SNMP協(xié)議 authInfo:認(rèn)證信息,由消息摘要authDigest,以及目標(biāo)方和源方的時間戳authDstTimestamp和authSrcTimestamp組成。 authData(SnmpMgmtCom):即經(jīng)過認(rèn)證的管理消

51、息,包含目標(biāo)參加者dstParty、源參加者srcParty、上下文context,以及協(xié)議數(shù)據(jù)單元pdu等4部分。4.4.3 SNMP協(xié)議 SNMPv2加密報文操作如下:發(fā)送實體首先構(gòu)造管理通信消息SnmpMgmtCom,這需要查找本地數(shù)據(jù)庫,發(fā)現(xiàn)合法的參加者和上下文。然后,如果需要認(rèn)證協(xié)議,則在SnmpMgmtCom前面加上認(rèn)證信息authInfo,構(gòu)成認(rèn)證報文SnmpAuthMsg,否則把authInfo置為長度為0的字節(jié)串(OCTET STRING)。若參加者的認(rèn)證協(xié)議為v2md5Authprotocol,則由本地實體按照MD5算法計算產(chǎn)生16個字節(jié)的消息摘要,作為認(rèn)證信息中的auth

52、Digest。第三步是檢查目標(biāo)參加者的加密協(xié)議,如果需要加密,則采用指定的加密協(xié)議對SnmpAuthMsg加密,生成privData(SnmpAuthMsg)。最后privDst=dstParty,組成完整的SNMPv2報文,并經(jīng)過BER編碼發(fā)送出去。目標(biāo)方實體接收到SnmpPrivMsg后首先檢查報文格式,如果這一檢查通過,則查找本地數(shù)據(jù)庫,發(fā)現(xiàn)需要的驗證信息。根據(jù)本地數(shù)據(jù)庫記錄,可能需要使用加密協(xié)議對報文解密,對認(rèn)證碼進(jìn)行驗證,檢查源方參加者的訪問特權(quán)和上下文是否符合要求等。一旦這些檢查全部通過,就可以執(zhí)行協(xié)議請求的操作。 4.4.3 SNMP協(xié)議 3. SNMPv3安全機制 1998年1

53、月,IETF SNMPv3工作組公布了SNMPv3。它由RFC2271-2275組成,SNMPv3參考了SNMPv2*與SNMPv2u,采用基于用戶的管理框架。SNMPv3主要在安全性和管理機制方面擴展了SNMPv2,而并未定義新的PDU格式,繼續(xù)使用SNMPv1和SNMPv2的PDU格式。RFC 2271定義了SNMPv3的體系結(jié)構(gòu),體現(xiàn)出模塊化設(shè)計思想,可以簡單地實現(xiàn)功能的增加和修改。SNMP代理和SNMP管理站通稱為SNMP實體,由SNMP引擎和SNMP應(yīng)用程序兩部分組成,如圖4.28所示。SNMP引擎由4組件組成:調(diào)度器、消息處理子系統(tǒng)、安全子系統(tǒng)和訪問控制子系統(tǒng)。SNMPv3應(yīng)用程序

54、是SNMP實體內(nèi)的應(yīng)用程序,當(dāng)前定義了5類應(yīng)用程序:命令生成器、命令響應(yīng)器、通知發(fā)生器、通知接收器和代理轉(zhuǎn)發(fā)器。4.4.3 SNMP協(xié)議 4.4.3 SNMP協(xié)議 SNMP協(xié)議從SNMPv1、SNMPv2,再到SNMPv3,安全性能有所加強,特別是SNMPv3增加了基于用戶的安全模型USM和基于視圖的訪問控制模型VACM,大大增強了SNMP安全性。但是USM中使用的認(rèn)證方式是基于代理的,認(rèn)證是單向的,因為管理站被看作是經(jīng)過授權(quán)的,因此它可以免于認(rèn)證。由于認(rèn)證是單向的,所以這也給某些攻擊提供了條件;再有就是認(rèn)證中的消息摘要使用的MD5算法,這種算法的原理已經(jīng)泄露,同樣給網(wǎng)絡(luò)安全管理帶來了難度。S

55、NMPv3中對信息的加密使用的是DES算法,該算法使用的密鑰是單一密鑰,也就是說加密和解密使用同一個密鑰,密鑰的保密是一個問題,一旦密鑰丟失,則加密信息不再具有保密性了。再有密鑰在線路上傳輸也存在被竊取的可能,如果傳輸線路沒有被加密的話。DES算法的密鑰長度僅有56位,密鑰長度不夠長,同樣也存在安全隱患。因此,網(wǎng)絡(luò)安全管理需加強。4.4.4 S-HTTP協(xié)議 S-HTTP(The Secure HyperText Transfer Protocol,安全HTTP協(xié)議)是IETF(Internet Engineering Task Force)制訂的一種帶有身份認(rèn)證、數(shù)據(jù)加密、數(shù)據(jù)完整性功能的應(yīng)

56、用層協(xié)議。S-HTTP是對HTTP的改進(jìn),加入了對安全功能的支持。在早期的WWW訪問協(xié)議HTTP中,并沒有考慮到安全問題,WWW服務(wù)的安全就只能依賴于服務(wù)器和客戶的其它方面設(shè)置。1999年, IETF發(fā)布了RFC 2660,The Secure HyperText Transfer Protocol,即安全HTTP協(xié)議(簡稱S-HTTP)。S-HTTP協(xié)議支持通信雙方利用公鑰算法和PKI數(shù)字證書進(jìn)行身份認(rèn)證、加密算法和MAC(Message Authenticity Check)算法協(xié)商,建立安全可信的連接。4.4.4 S-HTTP協(xié)議 S-HTTP連接的建立過程大致如下: (1)客戶對服務(wù)器

57、進(jìn)行認(rèn)證;服務(wù)器對客戶的認(rèn)證則是可選的。 (2)利用認(rèn)證過程得到的數(shù)字證書,雙方進(jìn)行對稱加密算法、會話密鑰和MAC算法的協(xié)商。 (3)根據(jù)協(xié)商的結(jié)果進(jìn)行協(xié)議數(shù)據(jù)的加密傳輸,并且由MAC算法保證數(shù)據(jù)完整性。S-HTTP協(xié)議的通信都是經(jīng)過加密的,其機密性由協(xié)商使用的對稱加密算法來保證。因為S-HTTP協(xié)議中引入PKI技術(shù),在認(rèn)證和密鑰協(xié)商過程中使用PKI數(shù)字證書,使得事先沒有建立直接聯(lián)系的雙方可以利用數(shù)字證書建立安全可信的連接,只要雙方都信任對方的根CA;非常適合于大規(guī)模WWW服務(wù)的應(yīng)用環(huán)境。 小結(jié) 身份認(rèn)證應(yīng)用層代理或網(wǎng)管用戶授權(quán)與訪問控制電路層防火墻(如SOCKS)應(yīng)用層安全通信協(xié)議傳輸層安全

58、 通信協(xié)議數(shù)字簽名第三方公證主機和服務(wù)的審計記錄分析應(yīng)用系統(tǒng)的容錯容災(zāi)、服務(wù)管理應(yīng)用系統(tǒng)主機、路由器等源發(fā)認(rèn)證相鄰節(jié)點間的認(rèn)證包過濾防火墻主機或路由器間IPSec等協(xié)議點到點之間的鏈路加密流量分析入侵檢測網(wǎng)絡(luò)結(jié)構(gòu)設(shè)計,路由系統(tǒng)安全,基礎(chǔ)服務(wù)安全,網(wǎng)絡(luò)管理網(wǎng)絡(luò)平臺認(rèn)證訪問控制數(shù)據(jù)完整性數(shù)據(jù)保密性抗抵賴審計可用性數(shù)據(jù)鏈路層與物理層網(wǎng)絡(luò)層傳輸層應(yīng)用層圖4.29 網(wǎng)絡(luò)不同層次的安全服務(wù)1、不是井里沒有水,而是你挖的不夠深。不是成功來得慢,而是你努力的不夠多。2、孤單一人的時間使自己變得優(yōu)秀,給來的人一個驚喜,也給自己一個好的交代。3、命運給你一個比別人低的起點是想告訴你,讓你用你的一生去奮斗出一個絕地

59、反擊的故事,所以有什么理由不努力!4、心中沒有過分的貪求,自然苦就少。口里不說多余的話,自然禍就少。腹內(nèi)的食物能減少,自然病就少。思緒中沒有過分欲,自然憂就少。大悲是無淚的,同樣大悟無言。緣來盡量要惜,緣盡就放。人生本來就空,對人家笑笑,對自己笑笑,笑著看天下,看日出日落,花謝花開,豈不自在,哪里來的塵埃!5、心情就像衣服,臟了就拿去洗洗,曬曬,陽光自然就會蔓延開來。陽光那么好,何必自尋煩惱,過好每一個當(dāng)下,一萬個美麗的未來抵不過一個溫暖的現(xiàn)在。6、無論你正遭遇著什么,你都要從落魄中站起來重振旗鼓,要繼續(xù)保持熱忱,要繼續(xù)保持微笑,就像從未受傷過一樣。7、生命的美麗,永遠(yuǎn)展現(xiàn)在她的進(jìn)取之中;就像

60、大樹的美麗,是展現(xiàn)在它負(fù)勢向上高聳入云的蓬勃生機中;像雄鷹的美麗,是展現(xiàn)在它搏風(fēng)擊雨如蒼天之魂的翱翔中;像江河的美麗,是展現(xiàn)在它波濤洶涌一瀉千里的奔流中。8、有些事,不可避免地發(fā)生,陰晴圓缺皆有規(guī)律,我們只能坦然地接受;有些事,只要你愿意努力,矢志不渝地付出,就能慢慢改變它的軌跡。9、與其埋怨世界,不如改變自己。管好自己的心,做好自己的事,比什么都強。人生無完美,曲折亦風(fēng)景。別把失去看得過重,放棄是另一種擁有;不要經(jīng)常艷羨他人,人做到了,心悟到了,相信屬于你的風(fēng)景就在下一個拐彎處。10、有些事想開了,你就會明白,在世上,你就是你,你痛痛你自己,你累累你自己,就算有人同情你,那又怎樣,最后收拾殘

溫馨提示

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

最新文檔

評論

0/150

提交評論