網(wǎng)絡(luò)安全導(dǎo)論 課件 第十章 安全通信1

第十章

安全通信（1）本章提要應(yīng)用安全技術(shù)構(gòu)建網(wǎng)絡(luò)安全協(xié)議并進(jìn)而采用安全協(xié)議進(jìn)行通信，是保護(hù)網(wǎng)絡(luò)通信安全的客觀要求?？蒲腥藛T針對不同的網(wǎng)絡(luò)層研制了大量特制的安全協(xié)議。在哪個(gè)層次上應(yīng)用哪個(gè)協(xié)議，要依賴于具體應(yīng)用的安全目標(biāo)和協(xié)議所能實(shí)現(xiàn)的功能。本章提要網(wǎng)絡(luò)層安全協(xié)議簇IPsec使用共享密鑰為數(shù)據(jù)傳輸提供安全服務(wù)。傳輸層安全協(xié)議簇SSL/TLS主要用于保護(hù)Web通信。部署SSL/TLS證書是保證網(wǎng)銀系統(tǒng)和電子商務(wù)網(wǎng)站通信安全的最佳解決方案。。本章要求本章重點(diǎn)是IPsec協(xié)議。要求學(xué)生掌握IPsec的框架、AH和ESP采用的算法和能夠提供的安全服務(wù)，理解TLS協(xié)議在實(shí)現(xiàn)層次和認(rèn)證方法上與IPsec協(xié)議的不同，能夠利用IPsec或TLS構(gòu)建VPN。1網(wǎng)絡(luò)安全性協(xié)議概述通信協(xié)議是關(guān)于通信如何所達(dá)成的一致性規(guī)則。網(wǎng)絡(luò)安全協(xié)議是指在計(jì)算機(jī)網(wǎng)絡(luò)中使用具有安全功能的通信協(xié)議就是把密碼技術(shù)用于通信。不要想當(dāng)然地認(rèn)為我只要在應(yīng)用層用用一下密碼技術(shù)就可以了。安全協(xié)議概念安全協(xié)議：通信各方為保證信息交換安全協(xié)商的規(guī)則集合。安全協(xié)議目標(biāo)：信息交換安全=站點(diǎn)之間+站點(diǎn)內(nèi)部安全協(xié)議語法：安全交換數(shù)據(jù)格式+安全交換操作格式安全協(xié)議語義：數(shù)據(jù)項(xiàng)和數(shù)據(jù)操作的具體含義安全協(xié)議時(shí)序：數(shù)據(jù)交換和數(shù)據(jù)操作先后次序安全協(xié)議主要技術(shù)：密碼技術(shù)安全協(xié)議分類按功能分類：認(rèn)證協(xié)議+密鑰管理協(xié)議+防否認(rèn)協(xié)議+信息安全交換協(xié)議認(rèn)證協(xié)議：消息認(rèn)證+源認(rèn)證+身份認(rèn)證密鑰管理協(xié)議：密鑰分配+密鑰交換+密鑰保存+密鑰更新+密鑰共享防否認(rèn)協(xié)議：數(shù)字簽名+數(shù)字證書+數(shù)字指紋信息安全交換協(xié)議：例如IPsec、S-MIME、sHTTP鄭州輕工業(yè)學(xué)院計(jì)算機(jī)與通信TCP/IP協(xié)議族分層HTTPSMTPDNSRTPTCPUDP硬件接口網(wǎng)絡(luò)層鏈路層運(yùn)輸層應(yīng)用層………以太網(wǎng)FRATMIGMPARPPARPICMP令牌網(wǎng)物理介質(zhì)/0層電纜FDDI雙絞線雙絞線微波無線衛(wèi)星IPTCP/IP協(xié)議族安全架構(gòu)網(wǎng)絡(luò)用戶物理介質(zhì)（物理防護(hù)與日常檢修）設(shè)備驅(qū)動(dòng)與接入?yún)f(xié)議PPTPL2FPPPL2TPIPIPsec(ah)IPsec(esp)TCPssltlsudP應(yīng)用程序setE-mailpgps/mimepemsnmpiketelnethttpsDNS安全擴(kuò)展x.509ripv2snmpv3bgp4鏈路層網(wǎng)際層傳輸層應(yīng)用層相關(guān)網(wǎng)絡(luò)安全協(xié)議Applicationlayerssh,S/MIME,PGP,httpdigest,TransportlayerSSL,TLS,WTLSNetworklayerIPsecDataLinklayerCHAP,PPTP,L2TP,

WEP(WLAN),A5(GSM),BluetoothPhysicallayerScrambling,Hopping,

QuantumCommunicationsCommunicationlayersSecurityprotocols什么VPN?就是利用上述某個(gè)協(xié)議，實(shí)現(xiàn)在公共網(wǎng)絡(luò)上構(gòu)建私人專用網(wǎng)2

IPSec13一、IP安全性概述14IPv4這是目前互聯(lián)網(wǎng)采用的最基本協(xié)議，它向其它運(yùn)行在網(wǎng)絡(luò)層或網(wǎng)絡(luò)層之上的協(xié)議提供了數(shù)據(jù)傳送服務(wù)。任何類型的數(shù)據(jù)都能通過這個(gè)基本的傳送機(jī)制得到傳輸服務(wù)，但是IP不提供安全服務(wù)，IP數(shù)據(jù)包可以被偽造、篡改。因此如何保障IP傳輸?shù)陌踩允且粋€(gè)很重要的問題。15

IP安全性概述在當(dāng)今的Internet中，存在著大量特制的協(xié)議，專門用來保障網(wǎng)絡(luò)各個(gè)層次的安全。到底在哪個(gè)層次上應(yīng)用安全措施，要依賴于應(yīng)用（程序）對安全保密的要求，以及用戶自己的一些需要。通常可以在應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和鏈路層實(shí)現(xiàn)網(wǎng)絡(luò)安全。在網(wǎng)絡(luò)層實(shí)現(xiàn)安全服務(wù)具有多方面的優(yōu)點(diǎn)。多種傳送協(xié)議和應(yīng)用程序可共享由網(wǎng)絡(luò)層提供的密鑰管理架構(gòu)。假如安全服務(wù)在較低層實(shí)現(xiàn)，那么需要改動(dòng)的應(yīng)用程序便要少得多。通過它，我們不必集中在較高的層實(shí)現(xiàn)大量安全協(xié)議。網(wǎng)絡(luò)層安全最有用的一項(xiàng)特性是能夠構(gòu)建VPN和內(nèi)聯(lián)網(wǎng)(Intranet)。由于VPN和內(nèi)聯(lián)網(wǎng)是以子網(wǎng)為基礎(chǔ)，而且網(wǎng)絡(luò)層支持以子網(wǎng)為基礎(chǔ)的安全，所以很容易實(shí)現(xiàn)VPN和內(nèi)聯(lián)網(wǎng)。16在網(wǎng)絡(luò)層提供安全服務(wù)的缺點(diǎn)是很難解決像數(shù)據(jù)的“不可抵賴”之類的問題。這樣的問題最好還是在較高的層解決。若在網(wǎng)絡(luò)層提供安全服務(wù)，很難在一部多用戶的機(jī)器上實(shí)現(xiàn)逐用戶的控制。然而，我們可在終端主機(jī)上提供相應(yīng)的機(jī)制，實(shí)現(xiàn)以用戶為基礎(chǔ)的安全保障。IP安全機(jī)制在網(wǎng)絡(luò)層提供了安全服務(wù)，包括鑒別、機(jī)密性和密鑰管理。鑒別機(jī)制保證收到的分組的真實(shí)性，以及確保分組在傳輸過程中未被修改；機(jī)密性機(jī)制使得通信節(jié)點(diǎn)加密報(bào)文以防止竊聽；密鑰管理機(jī)制是處理密鑰的安全交換的。IPSec是目前唯一一種能為任何形式的Internet通信提供安全保障的協(xié)議。此外，IPSec也允許提供逐個(gè)數(shù)據(jù)流或者逐個(gè)連接的安全，所以能實(shí)現(xiàn)非常細(xì)致的安全控制。IP安全性概述17IPv6availabilityGenerallyavailablewith(new)versionsofmostoperatingsystems.BSD,Linux2.2Solaris8AnoptionwithWindows2000/NTMostrouterscansupportIPV618IPv6DesignIssuesOvercomeIPv4scalingproblemlackofaddressspace.Flexibletransitionmechanism.Newroutingcapabilities.Qualityofservice.Security.Abilitytoaddfeaturesinthefuture.19IPv6ProtocolIPv6中的變化體現(xiàn)在以下五個(gè)重要方面：?擴(kuò)展地址。?簡化頭格式。?增強(qiáng)對于擴(kuò)展和選項(xiàng)的支持。?流標(biāo)記。?身份驗(yàn)證和保密。20IPv6HeadersSimplerheader-fasterprocessingbyrouters.Nooptionalfields-fixedsize(40bytes)Nofragmentationfields.NochecksumSupportformultipleheadersmoreflexiblethansimple“protocol”field.21IPv4HeaderVERSHLFragmentOffsetFragmentLengthServiceDatagramIDFLAGTTLProtocolHeaderChecksumSourceAddressDestinationAddressOptions(ifany)Data1byte1byte1byte1byte4forIPv422IPv6HeaderVERSPRIOHopLimitFlowLabelPayloadLengthNextHeader1byte1byte1byte1byte6forIPv6SourceAddress(128bits-16bytes)Dest.Address(128bits-16bytes)23IPv6HeaderFieldsVERS:6(IPversionnumber)Priority:willbeusedincongestioncontrolFlowLabel:experimental-sendercanlabelasequenceofpacketsasbeinginthesameflow.PayloadLength:numberofbytesineverythingfollowingthe40byteheader,or0foraJumbogram.24IPv6HeaderFieldsNextHeaderissimilartotheIPv4“protocol”field-indicateswhattypeofheaderfollowstheIPv6header.HopLimitissimilartotheIPv4TTLfield(butnowitreallymeanshops,nottime).25ExtensionHeadersRoutingHeader-sourceroutingFragmentationHeader-supportsfragmentationofIPv6datagrams.AuthenticationHeaderEncapsulatingSecurityPayloadHeader26ExtensionHeaders27二、IPsec28RFC2411鑒于對IP層上的安全需求，IPSec工作組制定了目前的IP層的安全協(xié)議IPSec，IPSec是一組協(xié)議套件，其中包括鑒別首部AH、封裝安全載荷ESP、Internet密鑰交換IKE協(xié)議。IPsec提供的是IP的安全性體系結(jié)構(gòu)，而不是Internet的安全性體系結(jié)構(gòu)。兩者的區(qū)別很重要：IPsec定義了在IP層使用的安全性服務(wù)，對IPv4和IPv6都可用。如果在適當(dāng)?shù)腎Pv4選項(xiàng)格式中實(shí)現(xiàn)AH和ESP頭，IPv4也可以使用這種安全性功能，只是在IPv6中更容易實(shí)現(xiàn)。IPsec30IPSec提供的安全服務(wù)安全服務(wù)AHESP（只加密）ESP（加密并鑒別）訪問控制YYY無連接完整性YY數(shù)據(jù)源鑒別YY拒絕重放YYY保密性YY流量保密YY3132IPsec的工作模式IPSec有兩種工作模式：傳輸模式：傳輸模式的保護(hù)對象是IP載荷，即對運(yùn)行于IP之上的協(xié)議進(jìn)行保護(hù)，采用傳輸模式時(shí)，原IP數(shù)據(jù)包的報(bào)文頭之后的數(shù)據(jù)發(fā)生改變，IP報(bào)文頭不變，只有在要求兩個(gè)主機(jī)的端到端的安全保障時(shí)，才能使用傳輸模式隧道模式：隧道模式的保護(hù)對象是整個(gè)IP數(shù)據(jù)包，它將一個(gè)數(shù)據(jù)包用一個(gè)新的數(shù)據(jù)包封裝，再加上一個(gè)新的IP報(bào)文頭，通常在數(shù)據(jù)包的始發(fā)點(diǎn)或目的地不是安全終點(diǎn)的情況下需要使用隧道模式。3334隧道模式的IPSec運(yùn)作的舉例隧道模式被用在兩端或是一端是安全網(wǎng)關(guān)的架構(gòu)中，例如裝有IPSec的路由器或防火墻。使用了隧道模式，防火墻內(nèi)很多主機(jī)不需要安裝IPSec也能安全地通信。某網(wǎng)絡(luò)的主機(jī)甲生成一個(gè)IP包，目的地址是另一個(gè)網(wǎng)中的主機(jī)乙。這個(gè)包從起始主機(jī)被發(fā)送到主機(jī)甲的網(wǎng)絡(luò)邊緣的安全路由器或防火墻。防火墻把所有出去的包過濾，看看有哪些包需要進(jìn)行IPSec的處理。如果這個(gè)從甲到乙的包需要使用IPSec，防火墻就進(jìn)行IPSec的處理，并把網(wǎng)包打包，添加外層IP包頭。這個(gè)外層包頭的源地址是防火墻，而目的地址可能是主機(jī)乙的網(wǎng)絡(luò)邊緣的防火墻?，F(xiàn)在這個(gè)包被傳送到主機(jī)乙的防火墻，中途的路由器只檢查外層的IP包頭。主機(jī)乙網(wǎng)絡(luò)的防火墻會把外層IP包頭除掉，把IP內(nèi)層發(fā)送到主機(jī)乙去。35AnIPSecurityScenario36IPsecExampleInternetHead

QuartersSubsidiaryIdefixVPNTunnelVPNTunnelAsterix

4Obelix

8VPNClient/16/1655.66.x.xMajestixTroubadix37三、AH38鑒別首部(AH)鑒別首部是IPSec協(xié)議之一，用于為IP提供數(shù)據(jù)完整性、數(shù)據(jù)源身份驗(yàn)證和一些可選的、有限的抗重放服務(wù)。不能提供保密39AH首部的字段40AH的字段含義●下一個(gè)頭：表示AH頭之后首部的類型。在傳輸模式下，將是處于保護(hù)中的上層協(xié)議的值，比如UDP或TCP協(xié)議的值。在隧道模式下，其數(shù)值4表示IP-in-IP(IPv4)封裝；數(shù)值41表示IPv6封裝?！褙?fù)載長度：采用32位字為單位的長度減去2來表示?！?/p>

SPI字段中包含SPI。該字段和外部IP頭的目的地址一起，用于識別對這個(gè)包進(jìn)行身份驗(yàn)證的安全關(guān)聯(lián)。●序列號：一個(gè)單向遞增計(jì)數(shù)器。主要為了抵抗重放攻擊。●認(rèn)證數(shù)據(jù)：是一個(gè)可變長度字段，其中包括完整性校驗(yàn)的結(jié)果。4142輸出處理43輸入處理44窗口與重放攻擊檢測由于IP協(xié)議是無連接、不可靠的，不能保證接收某個(gè)數(shù)據(jù)包時(shí)組成該消息的所有數(shù)據(jù)包都已順序接收，在接受端建立了長度為W的窗口，接收到的數(shù)據(jù)包必須滿足下面全部條件才不會被丟棄:1)接收到的數(shù)據(jù)包序列號必須是新的，即在窗口中未出現(xiàn)過2)接收到的數(shù)據(jù)包序列號必須落在窗口內(nèi)部或窗口右側(cè)3)接收到的數(shù)據(jù)包能通過鑒別檢查如果接收到的數(shù)據(jù)包落在窗口右側(cè)且通過鑒別檢查，窗口就會向前走4546四、ESP47封裝安全載荷(ESP)封裝安全載荷(ESP)為IP提供保密性和抗重播服務(wù)，作為可選的功能，ESP也可提供數(shù)據(jù)完整性和鑒別服務(wù)。48491)安全參數(shù)索引(SPI)是一個(gè)任意的32位值，它與目的IP地址和安全協(xié)議(ESP)結(jié)合，惟一地標(biāo)識這個(gè)數(shù)據(jù)報(bào)的SA。2)序列號(SequenceNumber)包含一個(gè)單調(diào)遞增的計(jì)數(shù)器值。用于抗重放攻擊。3)有效載荷數(shù)據(jù)(PayloadData)包含ESP要保護(hù)的數(shù)據(jù)504)填充多種情況需要使用填充字段：●采用的加密算法要求明文是某個(gè)數(shù)量字節(jié)的倍數(shù)●利用填充字段來確保結(jié)果密文是32位的字右對齊●填充字段可以用于隱藏有效載荷實(shí)際長度，支持(部分)信息流機(jī)密性。515)填充長度(PadLength)指明緊接其前的填充字節(jié)的個(gè)數(shù)。6)下一個(gè)報(bào)文頭(NextHeader)標(biāo)識有效載荷字段中包含的數(shù)據(jù)類型7)認(rèn)證數(shù)據(jù)(AuthenticationData)包含一個(gè)完整性校驗(yàn)值(ICV)，ESP分組中該值的計(jì)算不包含驗(yàn)證數(shù)據(jù)本身。驗(yàn)證數(shù)據(jù)字段是可選的，只有SA選擇驗(yàn)證服務(wù)才包含驗(yàn)證數(shù)據(jù)字段。52ESP的工作模式ESP使用方式：傳輸模式或隧道模式。1)傳輸模式僅在主機(jī)中實(shí)現(xiàn)，提供對上層協(xié)議的保護(hù)，不提供對IP報(bào)文頭的保護(hù)。2)隧道模式下，整個(gè)受保護(hù)的IP包都封裝在一個(gè)ESP中，并且還增加一個(gè)新的IP報(bào)文頭。53IPv4分組中ESP傳輸模式54ESP隧道模式55IPsecTunnelModeusingESPOriginal

IPHeaderTCP

HeaderDataIPv4BeforeapplyingESPIPprotocolnumberforESP:50ESPauthenticationisoptionalbutoftenusedinplaceofAHOriginalIPHeaderisencryptedandthereforehiddenOuter

IPHeaderESP

HeaderIPv4AfterapplyingESPencryptedauthenticatedOriginal

IPHeaderTCP

HeaderDataESP

TrailerESP

AuthEncapsulatingSecurity

Payload(ESP):RFC240656ESP處理過程(輸出)57ESP處理過程(輸入)58EncryptionandAuthenticationAlgorithmsEncryption:Three-keytripleDESRC5IDEAThree-keytripleIDEACASTBlowfishAuthentication:HMAC-MD5-96HMAC-SHA-1-9659五、安全關(guān)聯(lián)(SA)60安全關(guān)聯(lián)（securityassociation)在使用AH或ESP之前，先要從源主機(jī)到目的主機(jī)建立一條網(wǎng)絡(luò)層的邏輯連接，這個(gè)邏輯連接就叫安全關(guān)聯(lián)。!

這樣，Ipsec就將傳統(tǒng)的Internet無連接的網(wǎng)絡(luò)層轉(zhuǎn)換為具有邏輯連接的層。61安全關(guān)聯(lián)安全關(guān)聯(lián)是一個(gè)單向連接，如果雙向通信，則需要建立兩個(gè)安全關(guān)聯(lián)。一個(gè)安全關(guān)聯(lián)由一個(gè)三元組組成：安全協(xié)議標(biāo)識符（用來標(biāo)識使用AH或ESP）此單向連接的目的IP一個(gè)32bit的連接標(biāo)識符,稱為安全參數(shù)索引SPI(securityparameterindex)對于一個(gè)給定的安全關(guān)聯(lián)，每個(gè)Ipsec數(shù)據(jù)報(bào)都有一個(gè)存放SPI的字段，通過此SA的所有數(shù)據(jù)報(bào)都使用同樣的SPI值。62在IPSec的實(shí)施方案中，需要維護(hù)兩個(gè)邏輯上的數(shù)據(jù)庫：安全關(guān)聯(lián)數(shù)據(jù)庫SAD,安全策略數(shù)據(jù)庫SPD63當(dāng)一個(gè)系統(tǒng)需要對發(fā)送的包使用IPSec實(shí)施保護(hù)時(shí)，它查詢數(shù)據(jù)庫中的安全關(guān)聯(lián)，根據(jù)其相關(guān)內(nèi)容進(jìn)行特定處理，然后將安全連接的SPI插入到IPSec報(bào)頭當(dāng)對等接收方收到數(shù)據(jù)包時(shí)，就利用SPI和目的IP地址，從網(wǎng)絡(luò)數(shù)據(jù)庫中查詢相對應(yīng)的安全關(guān)聯(lián)，之后根據(jù)安全關(guān)聯(lián)的內(nèi)容對數(shù)據(jù)包作相關(guān)的安全處理。64SA的管理：創(chuàng)建和刪除SA管理既可以手工進(jìn)行，也可以通過一個(gè)Internet標(biāo)準(zhǔn)密鑰管理協(xié)議來完成，比如IKE。SA的創(chuàng)建分兩步進(jìn)行——先協(xié)商SA參數(shù)，再用SA更新SADB(安全關(guān)聯(lián)數(shù)據(jù)庫)。安全關(guān)聯(lián)數(shù)據(jù)庫包含了每個(gè)SA的參數(shù)信息，如AH和ESP的算法和密鑰、序列號、協(xié)議模式和有效期等。65在IPSec的早期開發(fā)及測試過程中，SA管理曾得到廣泛的應(yīng)用手工進(jìn)行。通信雙方都需要離線同意SA的各項(xiàng)參數(shù)。66在已經(jīng)配置好的IPSec環(huán)境中，SA的建立可以通過因特網(wǎng)標(biāo)準(zhǔn)密鑰管理協(xié)議(比如IKE)來完成。如果安全策略要求建立安全、保密的連接，但卻找不到相應(yīng)的SA，IPSec的內(nèi)核便會自動(dòng)調(diào)用IKE。IKE會與目標(biāo)主機(jī)或者途中的主機(jī)/路由器協(xié)商具體的SA；SA創(chuàng)建好且加入SADB數(shù)據(jù)庫后，在兩個(gè)主機(jī)間正常流動(dòng)的數(shù)據(jù)包便會采用SA參數(shù)實(shí)現(xiàn)相應(yīng)的安全服務(wù)。67可能有很多方面的理由需要?jiǎng)h除SA，例如：存活時(shí)間過期；密鑰已遭破解；使用SA加密/解密或驗(yàn)證的字節(jié)數(shù)已超過策略設(shè)定的某一個(gè)閾值；另一端要求刪除這個(gè)SA。68安全策略安全策略決定了為一個(gè)包提供的安全服務(wù)。如確定要保護(hù)什么樣的數(shù)據(jù)包，采用何種手段保護(hù)數(shù)據(jù)包。對所有IPSec實(shí)施方案來說，它們都會將策略保存在一個(gè)數(shù)據(jù)庫中，這個(gè)數(shù)據(jù)庫名為SPD(安全策略數(shù)據(jù)庫)。IP包的外出和進(jìn)入處理都要以安全策略為準(zhǔn)。在進(jìn)入和外出包處理過程中，需要查詢SPD，以判斷為這個(gè)包提供的安全服務(wù)有哪些。69IKE是一個(gè)使用已知的UDP端口（端口為500）的應(yīng)用層協(xié)議六、InternetKeyExchange

IKE70因特網(wǎng)密鑰管理協(xié)議前面我們在使用IPSec時(shí)都假定一個(gè)安全關(guān)聯(lián)已經(jīng)建立，IPSec并沒有提供如何建立該安全關(guān)聯(lián)的機(jī)制。實(shí)際上，因特網(wǎng)工程任務(wù)組(IETF)把整個(gè)過程分成了兩個(gè)部分：IPSec提供了分組級別的安全處理，而因特網(wǎng)密鑰管理協(xié)議(IKMP)負(fù)責(zé)協(xié)商安全關(guān)聯(lián)。IETF確定IKE作為配置IPSec安全關(guān)聯(lián)的標(biāo)準(zhǔn)協(xié)議。71IPSec的密鑰管理72小結(jié)IPSec/IKE系統(tǒng)處理73主機(jī)系統(tǒng)的外出IPSec處理只要IPSec功能激活，任何外出數(shù)據(jù)包都將受到安全策略數(shù)據(jù)庫(SPD)約束，通過查詢該數(shù)據(jù)庫來確定是否需要IPSec處理。如果需要，那么就根據(jù)數(shù)據(jù)包的信息來搜索安全關(guān)聯(lián)數(shù)據(jù)庫(SAD)以找到相匹配的SA。如果不存在相應(yīng)的SA，那么通常會啟動(dòng)IKE協(xié)商，并最終為該數(shù)據(jù)包建立所需的SA。然后對該數(shù)據(jù)包進(jìn)行IPSec處理，并發(fā)送出去。74主機(jī)系統(tǒng)的外出IPSec處理75主機(jī)系統(tǒng)的進(jìn)入IPSec處理進(jìn)入處理有別于外出處理，收到IP包后，假如包內(nèi)根本沒有包含IPSec頭，那么安全層就會對策略進(jìn)行檢查，判斷該如何對這個(gè)包進(jìn)行處理。它會用選擇符字段來檢索SPD數(shù)據(jù)庫。策略的輸出可能是下述三種選擇：丟棄、繞過或應(yīng)用。如果策略的輸出是丟棄，那么數(shù)據(jù)包就會被放棄；如果是應(yīng)用，但SA沒有建立，那就要看系統(tǒng)是否支持按需(on-demand)建立進(jìn)入SA，如果不支持包同樣會被丟棄。否則，就將包傳遞給下一層，作進(jìn)一步的處理。76主機(jī)系統(tǒng)進(jìn)入IPSec處理77IPsec–AutomaticKeyManagement

TheInternetKeyExchange(IKE)IKE是目前使用著的最通用的密鑰協(xié)商協(xié)議。

IKE允許兩個(gè)實(shí)體或者多個(gè)實(shí)體（也就是網(wǎng)絡(luò)主機(jī)或網(wǎng)關(guān)）通過一系列消息得到安全通信的會話密鑰，IKE交換為通信雙方的消息提供認(rèn)證和（或）加密，并且針對洪流、重播、欺騙等攻擊提供不同程度保護(hù)。

默認(rèn)的IPSEC密鑰協(xié)商方式IKE密鑰交換協(xié)議當(dāng)然，在IPSEC實(shí)施時(shí)也可以使用其它密鑰協(xié)商協(xié)議（如SKIP），但是IKE是所有IPSEC實(shí)施時(shí)都必須遵循的.

78TheInternetKeyExchange(IKE)IKE的核心就是實(shí)現(xiàn)密鑰信息的安全交換，建立安全的SA（包括IKESA和IPSECSA）。IKE通過兩個(gè)階段的ISAKMP完成通信雙方的密鑰交換.第一階段:交換模式是主模式或野蠻模式，結(jié)果建立了一個(gè)安全的IKESA；

第二階段:交換采用快速模式，結(jié)果建立一個(gè)安全的IPSECSA。ISAKMP提供了詳細(xì)的協(xié)議描述和包格式。79IPsec–AutomaticKeyManagement

TheInternetKeyExchange(IKE)NegotiatedParametersAuthenticationMechanism(secretorpublickey,certificates)EncryptionAlgorithm(mode,keylength,initializationvector)HashAlgorithmKeyvaluesandkeylifetimesSArenewalperiod80Exchange(IKE)–MainModeInternetKey主模式交換分為三個(gè)步驟，每個(gè)步驟由兩條消息組成，一共六條消息，最終建立了IKESA。模式協(xié)商交換；一次Diffie-Hellman交換和一次nonce交換；身份驗(yàn)證信息交換。其中身份驗(yàn)證信息的交換最為重要，驗(yàn)證方法包括：預(yù)共享密鑰認(rèn)證，數(shù)字簽名認(rèn)證和公共密鑰加密認(rèn)證三種方法。

81Exchange(IKE)–MainModeInternetKeyIKEusesUDPport500ResponderInitiatorIKE

HeaderDHKey

ExchangeNr43IKE

HeaderDHKey

ExchangeNiIKE

HeaderISAKMPSA

Proposal1IKE

HeaderISAKMPSA

Response25IKE

HeaderencryptedIDiCertiSigiencryptedIKE

Header6IDrCertrSigrIKEQuickMode–3messages82IKEMainModeusingPre-SharedKeysPre-sharedkey

●isworkedintoHash

●ispartoftheIKEsessionkey

ResponderInitiatorIKE

HeaderDHKey

ExchangeNr43IKE

HeaderDHKey

ExchangeNiIKE

HeaderISAKMPSA

Proposal1IKE

HeaderISAKMPSA

Response25IKE

HeaderencryptedIDiHashiencryptedIKE

Header6IDrHashr83IKEAggressiveModeusingPreSharedKeysUnencryptedIKEAggressiveModemessagescarryingcleartextIDscanbeeasilysniffedbyapassiveattacker.Pre-SharedKeyisworkedintoHashr,togetherwithotherknownparameters,sothatanoff-linecrackingattackbecomespossible.ResponderInitiator3HashiIKE

HeaderISAKMPSA

Proposal1DHKey

ExchangeNiIDiIKE

HeaderISAKMPSA

Response2DHKey

ExchangeNrIDrHashr84Man-in-the-MiddleAttackpossible

withIKEAggressiveModeandXAUTHVPNGatewayWLANAccessPointAttackerMan-in-the-MiddleWirelessLANUserVPNClientUsername:Password:bodoaznHu4UmXAUTHWithIKEAggressiveMode,use

One-TimePasswordscheme(e.g.SecureID).1GroupPassword2bodoaznHu4UmXAUTHGroupPassword85IKEPhase2–QuickMode

EstablishorRenewanIPsecSA第一階段建立了IKESA，便可以開始第二階段的協(xié)商了。第二階段只有一種模式，即快速模式。快速模式交換不一定要在第一階段后立刻進(jìn)行，只要目前存在已經(jīng)建立好的IKESA便可以了。另外在單獨(dú)一個(gè)IKESA的保護(hù)下甚至可以進(jìn)行多個(gè)快速模式交換?？焖倌Ｊ揭戎髂Ｊ胶唵危扇龡l消息組成，可以簡單地描述為“請求－響應(yīng)－驗(yàn)證”.86IKEPhase2–QuickMode

EstablishorRenewanIPsecSAEncryptedQuickModeMessageExchangeAllQuickModenegotiationsareencryptedwithasharedsecretkeyderivedfromaDiffie-Hellmannkey-exchangeplusadditionalparameters.NegotiationofIPsecParameters

Phase2QuickModeestablishesanIPsecSAusingthesecure

channelcreatedbythephase1IKESA.ThespecificconfigurationparametersfortheIPsecconnectionarenegotiated(AH,ESP,authentication/encryptionmethodsandparameters).QuickModecanbeusedrepeatedlytorenewIPSecSAsabouttoexpire.OptionalPerfectForwardSecrecyIfperfectforwardsecrecyisrequired,eachconsecutiveQuickModewilldoafreshDiffie-Hellmannkey-exchange.87Antje

BodoAntje

BodoPerfectForwardSecrecy(PFS)usingDHSession1:July10200209:00DataDataSession2:July11200210:00DataDataIfkeys1getscompromised,thenkeys2isstilltotallysecure!(assumingthata1,b1,a2andb2aretrulyrandom)88IPsecSA–ConfigurationExampleInternetHead

QuartersSubsidiaryIdefixVPNTunnelVPNTunnelAsterix

4Obelix

8VPNClient/16/1655.66.x.xMajestixTroubadix89IPsec–RelevantRFCsIKE

RFC2409ISAKMP

RFC2408Oakley

RFC2412IPsecDOI

RFC2407AH

RFC2402ESP

RFC2406ISAKMPInternetSecurityAssociation

andKeyManagementProtocolIKEInternetKeyExchangeDOIDomainofInterpretationAH

AuthenticationHeaderESP

EncapsulatingSecurityPayloadIPsec

RFC240190MotivationforanewIKERFCIKEv1isspreadoverthreedocuments(RFCs2407,2408,and2409)Toomanymessages(6inMain/3-4inQuickMode)Toomanyvariants(AH/ESP,transport/tunnel,authenticationmodes)Toocomplex–thereforepotentiallyinsecure(BruceSchneier)CookiesnotrequiredwhennotunderDoSattackNewfeatures:NAT-T,QoS,DeadPeerDetection,etc.IKEv2Protocol<draft–ietf–ipsec–ikev2–17.txt>IPsecSAcanbeestablishedwith2request/responsepairsAdditionalChildSAsrequireonerequest/responsepair,eachIKEv2hasbeenapprovedaproposedstandardinSeptember2004IKEv2willnotbebackwardscompatiblewithIKEv1!!!

IKEv2七、VPN的基本概念

VPN(VirtualPrivateNetwork，虛擬專用網(wǎng))是近年來隨著Internet的廣泛應(yīng)用而迅速發(fā)展起來的一種新技術(shù)，實(shí)現(xiàn)在公用網(wǎng)絡(luò)上構(gòu)建私人專用網(wǎng)絡(luò)?！疤摂M”主要是指這種網(wǎng)絡(luò)是一種邏輯上的網(wǎng)絡(luò)。

1VPN的系統(tǒng)特性-------安全保障

雖然實(shí)現(xiàn)VPN的技術(shù)和模式很多，但所有的VPN均應(yīng)保證通過公用網(wǎng)絡(luò)平臺傳輸數(shù)據(jù)的專用性和安全性。在非面向連接的公用IP網(wǎng)絡(luò)上建立一個(gè)邏輯的、點(diǎn)對點(diǎn)的連接，稱為建立一個(gè)隧道，可以利用加密技術(shù)對經(jīng)過隧道傳輸?shù)臄?shù)據(jù)進(jìn)行加密，以保證數(shù)據(jù)僅被指定的發(fā)送者和接收者了解，從而保證了數(shù)據(jù)的私有性和安全性。在安全性方面，由于VPN直接構(gòu)建在公用網(wǎng)上，盡管實(shí)現(xiàn)簡單、方便、靈活，但同時(shí)其安全問題也更為突出。企業(yè)必須確保其VPN上傳送的數(shù)據(jù)不被攻擊者窺視和篡改，并且要防止非法用戶對網(wǎng)絡(luò)資源或私有信息的訪問。ExtranetVPN將企業(yè)網(wǎng)擴(kuò)展到合作伙伴和客戶，對安全性提出了更高的要求。

VPN的系統(tǒng)特性-------服務(wù)質(zhì)量保證

VPN網(wǎng)應(yīng)當(dāng)為企業(yè)數(shù)據(jù)提供不同等級的服務(wù)質(zhì)量保證(QoS)。不同的用戶和業(yè)務(wù)對服務(wù)質(zhì)量保證的要求差別較大。對于移動(dòng)辦公用戶，提供廣泛的連接和覆蓋性是保證VPN服務(wù)的一個(gè)主要因素；而對于擁有眾多分支機(jī)構(gòu)的專線VPN網(wǎng)絡(luò)，交互式的內(nèi)部企業(yè)網(wǎng)應(yīng)用則要求網(wǎng)絡(luò)能提供良好的穩(wěn)定性；對于其他應(yīng)用(如視頻等)則對網(wǎng)絡(luò)提出了更明確的要求，如網(wǎng)絡(luò)時(shí)延及誤碼率等。所有以上網(wǎng)絡(luò)應(yīng)用均要求網(wǎng)絡(luò)根據(jù)需要提供不同等級的服務(wù)質(zhì)量。在網(wǎng)絡(luò)優(yōu)化方面，構(gòu)建VPN的另一重要需求是充分有效地利用有限的廣域網(wǎng)資源，為重要數(shù)據(jù)提供可靠的帶寬。廣域網(wǎng)流量的不確定性使其帶寬的利用率很低，在流量高峰時(shí)引起網(wǎng)絡(luò)阻塞，產(chǎn)生網(wǎng)絡(luò)瓶頸，使實(shí)時(shí)性要求高的數(shù)據(jù)得不到及時(shí)發(fā)送；而在流量低谷時(shí)又造成大量的網(wǎng)絡(luò)帶寬空閑。QoS通過流量預(yù)測與流量控制策略，可以按照優(yōu)先級分配帶寬資源，實(shí)現(xiàn)帶寬管理，使得各類數(shù)據(jù)能夠被合理地先后發(fā)送，并預(yù)防阻塞的發(fā)生。

VPN的系統(tǒng)特性------可擴(kuò)充性和靈活性

VPN必須能夠支持通過Intranet和Extranet的任何類型的數(shù)據(jù)流，方便增加新的節(jié)點(diǎn)，支持多種類型的傳輸媒介，可以滿足同時(shí)傳輸語音、圖像和數(shù)據(jù)等新應(yīng)用對高質(zhì)量傳輸以及帶寬增加的需求。

可管理性

從用戶角度和運(yùn)營高角度方面應(yīng)可方便地進(jìn)行管理、維護(hù)。在VPN管理方面，VPN要求企業(yè)將其網(wǎng)絡(luò)管理功能從局域網(wǎng)無縫隙地延伸到公用網(wǎng)，甚至是客戶和合作伙伴。雖然可以將一些次要的網(wǎng)絡(luò)管理任務(wù)交給服務(wù)提供商去完成，企業(yè)自己仍需要完成許多網(wǎng)絡(luò)管理任務(wù)。所以，一個(gè)完善的VPN管理系統(tǒng)是必不可少的。VPN管理的目標(biāo)為：減小網(wǎng)絡(luò)風(fēng)險(xiǎn)、使其具有高擴(kuò)展性、經(jīng)濟(jì)性、高可靠性等優(yōu)點(diǎn)。事實(shí)上，VPN管理主要包括安全管理、設(shè)備管理、配置管理、訪問控制列表管理、QoS管理等內(nèi)容。

降低成本

VPN利用現(xiàn)有的Internet或其他公共網(wǎng)絡(luò)的基礎(chǔ)設(shè)施為用戶創(chuàng)建安全隧道，不需要專門的租用線路，如DDN和PSTN，這樣就節(jié)省了專門線路的租金。如果是采用遠(yuǎn)程撥號進(jìn)入內(nèi)部網(wǎng)絡(luò)，訪問內(nèi)部資源，需要長途話費(fèi)；而采用VPN技術(shù)，只需撥入當(dāng)?shù)氐腎SP就可以安全地接入內(nèi)部網(wǎng)絡(luò)，這樣也節(jié)省了線路話費(fèi)。VPN的原理與協(xié)議雖然VPN技術(shù)非常復(fù)雜，但目前實(shí)現(xiàn)VPN的幾種主要技術(shù)及相關(guān)協(xié)議都已經(jīng)非常成熟，并且都有廣泛應(yīng)用，尤其以L2TP、IPSec和

SSL協(xié)議應(yīng)用最廣，因此做為本節(jié)的主要內(nèi)容。

實(shí)現(xiàn)VPN的隧道技術(shù)

為了能夠有在公網(wǎng)中形成的企業(yè)專用的鏈路網(wǎng)絡(luò)，VPN采用了所謂的隧道(Tunneling)技術(shù)，模擬點(diǎn)到點(diǎn)連接技術(shù)，依靠ISP和其他的網(wǎng)絡(luò)服務(wù)提供商在公網(wǎng)中建立自己專用的“隧道”，讓數(shù)據(jù)包通過隧道傳輸。網(wǎng)絡(luò)隧道技術(shù)指的是利用一種網(wǎng)絡(luò)協(xié)議傳輸另一種網(wǎng)絡(luò)協(xié)議，也就是將原始網(wǎng)絡(luò)信息進(jìn)行再次封裝，并在兩個(gè)端點(diǎn)之間通過公共互聯(lián)網(wǎng)絡(luò)進(jìn)行路由，從而保證網(wǎng)絡(luò)信息傳輸?shù)陌踩?。它主要利用網(wǎng)絡(luò)隧道協(xié)議來實(shí)現(xiàn)這種功能，具體包括第二層隧道協(xié)議(用于傳輸二層網(wǎng)絡(luò)協(xié)議)和第三層隧道協(xié)議(用于傳輸三層網(wǎng)絡(luò)協(xié)議)。

第二層隧道協(xié)議是在數(shù)據(jù)鏈路層進(jìn)行的，先把各種網(wǎng)絡(luò)協(xié)議封裝到PPP包中，再把整個(gè)數(shù)據(jù)包裝入隧道協(xié)議中，這種經(jīng)過兩層封裝的數(shù)據(jù)包由第二層協(xié)議進(jìn)行傳輸。第二層隧道協(xié)議有以下幾種。(1)PPTP(RFC2637，Point-to-PointTunnelingProtocol)。(2)L2F(RFC2341，Layer2Forwarding)。(3)L2TP(RFC2661，LayerTwoTunnelingProtocol)。

第三層隧道協(xié)議是在網(wǎng)絡(luò)層進(jìn)行的，把各種網(wǎng)絡(luò)協(xié)議直接裝入隧道協(xié)議中，形成的數(shù)據(jù)包依靠第三層協(xié)議進(jìn)行傳輸。第三層隧道協(xié)議有以下幾種：(1)IPSec(IPSecurity)是目前最常用地VPN解決方案。(2)GRE(RFC2784，GeneralRoutingEncapsulation)。

隧道技術(shù)包括了數(shù)據(jù)封裝、傳輸和解包在內(nèi)的全過程。封裝是構(gòu)建隧道的基本手段，它使得IP隧道實(shí)現(xiàn)了信息隱蔽和抽象。封裝器建立封裝報(bào)頭，并將其追加到純數(shù)據(jù)包的前面。當(dāng)封裝的數(shù)據(jù)包到達(dá)解包器時(shí)，封裝報(bào)頭被轉(zhuǎn)換回純報(bào)頭，數(shù)據(jù)包被傳送到目的地。

隧道的封裝具有以下特點(diǎn)。(1)源實(shí)體和目的實(shí)體不知道任何隧道的存在。(2)在隧道的兩個(gè)端點(diǎn)使用該過程，需要封裝器和解包器兩個(gè)新的實(shí)體。(3)封裝器和解包器必須相互知曉，但不必知道在它們之間的網(wǎng)絡(luò)上的任何細(xì)節(jié)。

103SecurityProtocolsfortheOSIStackApplicationlayerssh,S/MIME,PGP,httpdigestTransportlayerSSL,TLS,WTLSNetworklayerIPsecDataLinklayerCHAP,PPTP,L2TP,

WEP(WLAN),A5(GSM),BluetoothPhysicallayerFrequencyHopping,

QuantumCryptographyCommunicationlayersSecurityprotocolsPPTP協(xié)議

點(diǎn)對點(diǎn)隧道協(xié)議(Point-to-PointTunnelingProtocol，PPTP)是常用的協(xié)議。這主要是因?yàn)槲④浀姆?wù)器操作系統(tǒng)占有很大的市場份額。PPTP是點(diǎn)對點(diǎn)協(xié)議(Point-to-PointProtocol，PPP)的擴(kuò)展，而PPP是為在串行線路上進(jìn)行撥入訪問而開發(fā)的。PPTP是在1996年被引入因特網(wǎng)工程任務(wù)組織(IntenetEngineeringTaskForce，IETF)的，它在WindowsNT4.0中就已完全實(shí)現(xiàn)了。PPTP將PPP幀封裝成IP數(shù)據(jù)報(bào)。以便在基于IP的互聯(lián)網(wǎng)上(如因特網(wǎng)，或一個(gè)專用的內(nèi)聯(lián)網(wǎng))傳輸。PPTP協(xié)議是一個(gè)為中小企業(yè)提供的VPN解決方案，但PPTP協(xié)議在實(shí)現(xiàn)上存在著重大安全隱患。有研究表明，其安全性甚至比PPP還弱，因此不用于需要一定安全保證的通信。如果條件允許，用戶最好選擇完全替代PPTP的下一代二層協(xié)議L2TP。

VirtualPrivateNetworksInternetHead

QuartersSubsidiary?RoadWarrior“VPNTunnelVPNTunnelVPNGateway

4VPNGateway

8VPNClient/16/1655.66.x.xExtranetVPNsInternetPartner

NetworkCustomerVPNTunnelVPNTunnelVPNClientCustomer

AccessPrivate

NetworkPartner

AccessVPNGatewayVPNGatewayNetworkaccessmustbepartitionedandtightlycontrolledFlexibleanddynamicsetupofExtranetVPNconnectionsExtranetVPNspansmultipleadministrativetrustdomainsIntranetVPNsInternetPrivateIntranetWireless

IntranetUserVPNTunnel

/0VPNGateway

/FirewallVPNClientIntranet

ServerWLANAccessPointDMZInterfaceWirelessVPNclientstunnel100%oftheirIPtrafficovertheinsecureairlinkusingthepeernetworksubnetmask/0.3.傳輸層安全協(xié)議簡介SSLandTLSSSLwasoriginatedbyNetscapeTLSworkinggroupwasformedwithinIETFFirstversionofTLScanbeviewedasanSSLv3.1SSLArchitecture1)用戶和服務(wù)器的合法性認(rèn)證認(rèn)證用戶和服務(wù)器的合法性，使得它們能夠確信數(shù)據(jù)將被發(fā)送到正確的客戶機(jī)和服務(wù)器上?？蛻魴C(jī)和服務(wù)器都有各自的識別號，這些識別號由公開密鑰進(jìn)行編號，為了驗(yàn)證用戶是否合法，安全套接層協(xié)議要求在握手交換數(shù)據(jù)時(shí)進(jìn)行數(shù)字認(rèn)證，以此來確保用戶的合法性。

2)加密數(shù)據(jù)以隱藏被傳送的數(shù)據(jù)安全套接層協(xié)議所采用的加密技術(shù)既有對稱密鑰技術(shù)，也有公開密鑰技術(shù)。在客戶機(jī)與服務(wù)器進(jìn)行數(shù)據(jù)交換之前，交換SSL初始握手信息，在SSL握手信息中采用了各種加密技術(shù)對其加密，以保證其機(jī)密性和數(shù)據(jù)的完整性，并且用數(shù)字證書進(jìn)行鑒別，這樣就可以防止非法用戶破譯。3)保護(hù)數(shù)據(jù)的完整性安全套接層協(xié)議采用Hash函數(shù)和機(jī)密共享的方法提供信息的完整性服務(wù)，建立客戶機(jī)與服務(wù)器之間的安全通道，使所有經(jīng)過安全套接層協(xié)議處理的業(yè)務(wù)在傳輸過程中能全部完整準(zhǔn)確無誤地到達(dá)目的地。SSL協(xié)議提供的安全服務(wù)ImplementedSSL/TLSProtocolVersionsSSL–SecureSocketsLayerVersion2.0InitiallydevelopedbyNetscapeSSL2.0issensitivetoman-in-the-middleattacksleading

tothenegotiationofweak40-bitencryptionkeysBrowserSupport:AllbrowsersSSL–SecureSocketsLayerVersion3.0

InternetDraftauthoredbyNetscape,November1996BrowserSupport:AllbrowsersTLS–TransportLayerSecurityVersion1.0IETFRFC2246,January1999TLS1.0istnotbackwardscompatibletoSSL3.0(differencesin

MACcomputation,PRFfunctionformaster_secretandkeymaterial)BrowserSupport:Mozilla1.x,InternetExplorer5.x/6.0SSL體系結(jié)構(gòu)SSL會話和SSL連接連接：提供恰當(dāng)類型服務(wù)的傳輸會話：客戶和服務(wù)器之間的關(guān)聯(lián)，通過握手協(xié)議來創(chuàng)建會話狀態(tài)的定義會話標(biāo)識符、對方證書、壓縮方法、密文規(guī)約、主密碼、可重新開始連接狀態(tài)的定義服務(wù)器和客戶機(jī)的隨機(jī)數(shù)、服務(wù)器寫MAC密碼、客戶寫MAC密碼、服務(wù)器寫密鑰、客戶寫密鑰、初始化向量、序列號SSLRecordProtocol

記錄協(xié)議SSL記錄協(xié)議為SSL連接提供兩種服務(wù)保密性：握手協(xié)議定義了共享的、可以用于對SSL有效載荷進(jìn)行常規(guī)加密的密鑰報(bào)文完整性：握手協(xié)議定義了共享的、可以用來形成報(bào)文的鑒別碼MAC的密鑰SSLRecordFormat(1)發(fā)送方的工作過程1)從上層協(xié)議接收要發(fā)送的數(shù)據(jù)2)對數(shù)據(jù)進(jìn)行分段，分成若干記錄3)使用指定的壓縮算法進(jìn)行數(shù)據(jù)壓縮4)使用指定的MAC算法生成MAC值5)使用指定的加密算法進(jìn)行數(shù)據(jù)加密6)發(fā)送數(shù)據(jù)SSL記錄協(xié)議的工作過程(2)接收方的工作過程1)接收數(shù)據(jù)2)使用指定的解密算法解密數(shù)據(jù)3)使用指定的MAC算法校驗(yàn)MAC值4)使用壓縮算法對數(shù)據(jù)解壓縮5)將記錄進(jìn)行數(shù)據(jù)重組6)將數(shù)據(jù)發(fā)送給上層協(xié)議HandshakeProtocolThemostcomplexpartofSSL.Allowstheserverandclienttoauthenticateeachother.Negotiateencryption,MACalgorithmandcryptographickeys.Usedbeforeanyapplicationdataaretransmitted.四個(gè)階段：建立安全能力、服務(wù)器認(rèn)證和密鑰交換、客戶認(rèn)證和密鑰交換、結(jié)束SSL握手協(xié)議消息類型TheSSL/TLSHandshakeProtocolServerServerHelloRSServerHelloDoneClientClientHelloRCApplicationData°ApplicationData°Certificate*ClientKeyExchangeCertificateVerify**optionalServerKeyExchange*Certificate*CertificateRe