網絡安全傳輸通道技術的研究

網絡安全傳輸通道技術的研究2007-9-1216:15:49【大中小】【您是本文第位讀者】摘要：安仝傳輸通道是對待傳輸的原始信息進行加密和協(xié)議封裝處理，從而實現安全傳輸的技術，本文從介紹TCP/IP協(xié)議棧的分層體系結構出發(fā)，分別在TCP/IP的各個層次I：提出了實現安全傳輸通道的技術和解決方案。特別是對網絡層的安全傳輸通道技術提出了實現機制。關鍵詞：安全傳輸通道、TCP/IP協(xié)議棧、安全協(xié)議、PPTP、L2TP、IPSec,SSL、SSH1概述隨著因特網的高速發(fā)展，網絡上開發(fā)的應用越來越多，一些關鍵業(yè)務也開始通過因特網提供。而Internet的一大特性是他的開放性，正是這種開放性給因特網上服務的安全構成了嚴重威脅。為了保證它健康有序的發(fā)展，必須在網絡安全上提供強有力的保證。所謂網絡安全傳輸通道，就是利用安全通道技術(SecumTunnelingTechnology),通過將待傳輸的原始信息進行加密和協(xié)議封裝處理后再嵌套裝入另一種協(xié)議的數據包送入網絡中，像普通數據包一樣進行傳輸。經過這樣的處理，只仃源端和目的端的用戶對通道中的嵌套信息能夠進行解釋和處理，而對于其他用戶而言只是無意義的信息。網絡安全傳輸通道應該提供以下功能和特性：.機密性：通過對信息加密保證只有預期的接收者才能讀出數據。.完整性：保護信息在傳輸過程中免遭未經授權的修改，從而保證接收到的信息與發(fā)送的信息完全相同。.對數據源的身份驗證：通過保證每個計算機的真實身份來檢杳信息的來源以及完整性。.反重發(fā)攻擊：通過保證每個數據包的唯一性來確保攻擊者捕獲的數據包不能重發(fā)或重用。在因特網上普遍采用的是TCP/IP協(xié)議，TCP/IP協(xié)議的體系結構相對于OSI/ISO體系結構的7層模型是比較簡單而實用的，其模型如下：此體系結構中，最下面的主機到網絡層實際上.包括了OSI模型中的2層：數據鏈路層和物理層。木文

將從TCP/IP的各個層次介紹相關的安全傳輸通道技術。2在數據鏈路層實現安全傳輸通道的技術[1]數據鏈路層技術涉及到軟件和硬件兩個方面，硬件方面不在本文中討論。當前能在此層提供安全通道技術的安全協(xié)議主要有：PPTP和L2IP。它們主要是為了組建遠程訪問VPN而提出的。PPTP是第2層協(xié)議，它將PPP幀封裝在1P數據報里以在IP網絡中傳輸.它是微軟開發(fā)的一個較舊的協(xié)議。相反，L2TP是基于Cisco的“第2層轉發(fā)（L2F）”協(xié)議和微軟的PPTP協(xié)議的較新協(xié)議。它可以封裝在IP、X.25、幀中繼、異步傳輸模式等上發(fā)送的PPP幀。雖然L2TP比PPTP更靈活，但它比PPTP需要更多的CPU能力。L2TP和PPTP的主要技術性區(qū)別如K：I.PPTP要求傳輸網絡基于IP,而L2TP只要求傳輸網絡提供點對點連通性；PPTP只支持VPN客戶機和VPN服務器之間的一個隧道，L2Tp允許在終點間使用多個隧道。使用L2TP可以為不同服務質量而創(chuàng)建不同的隧道或滿足不同安全要求；L2TP提供信息頭壓縮，當啟用信息頭壓縮時，L2TP以4字節(jié)開銷運行相當于PPTP以6字節(jié)運行。PPTP的封裝原始IP數據報在PPTP客戶機和PPTP服務器之間傳輸時，PPTP封裝它。圖1顯示了PPTP信息包的封裝格式：IPQGRE>PPP~IPpTCP或UDPp用戶數據，i原始數據報，

圖1PPTP的封裝格式在上圖中，原始數據報首先封裝在PPP幀里。使用PPP可壓縮和加密該部分數據。然后將PPP幀封裝在GRE（GenericRoutingEncapsulation）幀里，該幀是PPTP客戶機和PPTP服務器之間發(fā)送的新IP數據報的有效負載。該新數據報的源和目標IP地址將和PPTP客戶機及PPTP服務器的IP地址相對應。執(zhí)行中該數據報將進一步封裝在數據鏈路層幀里并且有正確的信息頭和信息尾。L2TP的封裝和PPTP相似，當經過傳輸網絡傳送時，L2TP封裝原始IP數據報。由于在L2TP中，是*IPSec提供加密功能，所以L2TP封裝分兩個階段完成：初始L2TP封裝和IPSec封裝。階段1:初始L2Tp封裝IP,UDP“L2TP,PPP|TCP或UDP「用戶數據；

初始數據報~階段2:IPSec封裝階段2:耍睦封裝，IP-ESP頭+UDP+]L2TP，ppp-TCP或UDP+用戶數據;ESP尾1睇嗡證信息.i初始數據報，t使用聯(lián)加密Q圖2L2Tp的兩階段封裝如圖2所示，L2TP首先將原始數據報封裝在PPP幀里（和PPTP一樣）：然后將PPP幀插入到有UDP信息頭和L2Tp信息頭的新IP數據報。然后結果數據報再應用IPSec加密。在這里，應用了IPSec標準中的封裝安全載荷（ESP）協(xié)議的信息頭和信息尾以及IPSec驗證信息尾，這樣就保證了信息的完整性和機密性以及信息源的身份驗證。最外層IP報頭所包含的源和目標IP地址與VPN客戶機和VPN服務器相對應。

3在網絡層實現安全傳輸通道的技術[2]當前，在網絡層實現安全已經成為一大研究熱點，并且Internet工程任務組（IETF）于1998年公布了因特網安全體系結構——IPSec規(guī)范，這更加速了這方面的研究和實施。IPSec簡介它是由IETF的IPSec工作組提出的將安全機制引入TCP/IP網絡的一系列標準，包括安全協(xié)議（驗證頭AH和封裝安全凈荷ESP）、安全聯(lián)盟、密鑰管理和安全算法等，它定義了IP數據包格式和相關基礎結構，以便為網絡通信提供端對端、加強的身份驗證、完整性、反重播和保密性等。使用IETF定義的Internet密鑰交換（IKE）,還提供按需要的安全協(xié)商和自動密鑰管理服務。IPSec可保障主機之間、安全網美之間（如路由器或防火墻）或主機與安全網關之間的數據報的安全。它可以實現各種方式的VPN：ExtraNetVPN、IntraNetVPN和遠程訪問VPN.安全協(xié)議包括驗證頭（AH）和封裝安全載荷（ESP）。他們既可用來保護一個完整的1P載荷，亦可用來保護某個IP載荷的上層協(xié)議。這兩方面的保護分別是由IPSec兩種不同的實現模式來提供的，如圖3所示：傳送模式用來保護上層協(xié)議；而隧道模式用來保護整個IP數據包。在傳送模式中，IP頭與上層協(xié)議之間需插入一個特殊的IPSec頭；而在通道模式中，要保護的整個IP包都需封裝到另一個IP數據報里，同時在外部與內部1P頭之間插入一個IPSec頭。兩種安全協(xié)議均能以傳送模式或隧道模式工作。

IP關TCP頭數據「卜

初始弊據報+，IP頭W |TCP頭2|數據。~|2傳送模式下策典處理后的數據報格立

外層IP頭HJRS電頭QI內層IP頭2TCP頭CI數據P卜

隧道模式下經史處理后的數據報格式，圖3兩種模式下的數據報格式。，封裝安全載荷(EncapsulatingSecurityPayload,簡稱ESP)：屬于IPSec的?種安全協(xié)議，它可確保IP數據報的機密性、數據的完整性以及對數據源的身份驗證。此外，它也能負責對重放攻擊的抵抗。具體做法是在IP頭(以及任何選項)之后，并在要保護的數據之前，插入一個新頭，亦即ESP頭。受保護的數據可以是一個上層協(xié)議，或者是整個IP數據報。最后，還要在后面追加一個ESP尾,格式如圖4所示。ESP是種新的協(xié)議，對它的標識是通過IP頭的協(xié)議字段來進行的。假如它的值為50,就表明這是一個ESP包，而且緊接在IP頭后面的是一個ESP頭。[3]IP頭ESP頭要保護的數據ESP尾圖4一個受ESP保護的IP包驗證頭(AuthenticationHeader,簡稱AH)：與ESP類似，AH也提供了數據完整性、數據源驗證以及抗重放攻擊的能力。但要注意它不能用來保證數據的機密性。正是由了這個原因，AH比ESP簡單得多，AH只有頭，而沒有尾，格式如圖5所示。[4]IP頭AH頭要保護的數據圖5一個受AH保護的IP包安全聯(lián)盟(SecurityAssociation＞簡稱SA)的概念為了正確封裝及提取IPSec數據報，有必要采取?套專門的方案，將安全服務/密鑰與要保護的通信數據聯(lián)系到一起；同時要將遠程通信實體與要交換密鑰的IPSec數據傳輸聯(lián)系到一起。換言之，要解決如何保護通信數據、保護什么樣的通信數據以及由誰來實行保護的問題，這樣的構建方案稱為“安全聯(lián)盟Internet密鑰交換(InternetKeyExchange.簡稱IKE)IKE的用途就是在IPSec通信雙方之間建立起共享的安全參數及驗證過的密鑰（亦即建立“安全聯(lián)盟”關系）。IKE協(xié)議是Oaklay和SKEME協(xié)議的?種混合，并在由ISAKMP規(guī)定的框架內運作。ISAKMP是“Internet安全聯(lián)盟和密鑰管理協(xié)議”的簡稱，它定義了包格式、重發(fā)計數器以及消息構建要求，事實上,它定義了整套加密通信語言.IKE采用了“安全聯(lián)盟SA”的概念，1KESA定義了雙方的通信形式。舉例來說，用哪種算法來加密IKE通信；怎樣對遠程通信方的身份進行驗證；等等。隨后，便可用IKESA在通信雙方之間提供任何數量的IPSecSA.[5]運用IPSec進行安全通信的大體步驟是：①建立IKESA；②在已經建立好的IKESA上建立IPSecSA；③在已經建立好的IPSecSA上，進行實際的通信；④通信完畢，撤消IPSecSA；⑤當此IKESA上的所有IPSecSA都撤消以后，最后撤消IKESA?IPSec的實現機制IPSec既可在主機系統(tǒng)上實現，亦可在某種安全網關上實現（如路由器或防火墻）.由于IPSec的實現是與系統(tǒng)密切相關的，所以在主:機上和在安全網關上的實現機制是不相同的，這里僅簡述主機上的實現機制。主機實現[6]可分為兩類。1）與操作系統(tǒng)集成：由于IPSec是個網絡層協(xié)議，所以可作為網絡層的?部分來實現，如下圖6.它需要IP層的服務來構建IP頭，實現機制與其它網絡層協(xié)議（如ICMP）相似，需要訪問IP堆棧。2）堆棧中的塊（BumpInTheStack,簡稱BITS）：倘若根本無法訪問一臺主機的IP堆棧，便需將IPSec作為“堆棧內的塊”來實現。通常以一個額外的“填充物”的形式出現，插入到網絡層和數據鏈路層之問，負責從IP堆棧提取數據報，處理后再將其插入，如圖7所示。應用層應用層傳輸層傳輸層網絡層+IPSec網絡層數據鏈路層IPSec圖60S集成實現的分層數據鏈路層圖7BITS實現的分層圖7BITS實現的分層與OS集成方案有許多好處，其中關鍵的是：由于1Psec與網絡層緊密集成到一起，因此它更有利于諸如分段、PMTU和用戶場景（如套接子）之類的網絡服務，使實現方案更為有效。但需要訪問IP堆棧，即開發(fā)人員能拿到IP堆棧的源代碼。堆棧中的塊實現方案不必訪問IP堆棧，開發(fā)人員只耍掌握操作系統(tǒng)的鏈接機制，將IPSec組件插入網絡層和數據鏈路層之間即可。但它最大的問題是功能的重復，要求實現網絡層的大部分功能，比如分段和路由，而這些問題又是很難解決的。在操作系統(tǒng)中實現由于IPSec的實現是與操作系統(tǒng)密切相關，所以必須研究各操作系統(tǒng)提供的實現機制。WindowsNT/2000系統(tǒng)：由于微軟采用了相時比較封閉的策略，它的內核源碼一般是拿不到，所以開發(fā)人員只能利用系統(tǒng)公布的編程接口。在內核中有兩個公共的接口：網絡驅動程序接口規(guī)范NDIS和傳輸驅動程序接口TDI.TCP/IP堆棧就是在這兩個接口之間實現的，而此堆棧兒乎是無法插入的，開發(fā)人員只能在NDIS接口上做文章。[7]LINUX系統(tǒng)：由于LINUX的所有內核源碼都可以免費得到，所以協(xié)議模塊開發(fā)人員是完全可以在它上實現IPSec的?在LINUX中，各層協(xié)議之間以及協(xié)議層與網絡設備驅動程序之間只傳遞套接字緩沖區(qū)，即一個比較復雜的數據結構sk_buff,在sk_buff中有指針和長度域等，這樣各層協(xié)議即可通過標準函數或方法使用數據。另外，LINUX在文件net/ipv4/pn）tocol.c中也提供了協(xié)議模塊的注冊和注銷機制。一旦模塊編程完畢，重新編譯內核即可。[8]4在傳輸層實現安全傳輸通道當前，在傳輸層能夠實現安全傳輸通道的協(xié)議是Netscape通信公司制定的安全套接層協(xié)議（SecureSocketLayer,簡稱SSL），它建立在可*的傳輸服務（如TCP/IP所提供）基礎之上。SSL當前為版本3（SSLv3）于1995年12月制定。它主要由以下兩個協(xié)議組成：SSL記錄協(xié)議：它涉及應用程序提供的信息的分段、壓縮、數據認證和加密。SSLv3提供對數據認證用的MD5和SHA以及數據加密用的R4和DES等的支持，用來對數據進行認證和加密的密鑰可以通過SSL的握手協(xié)議來協(xié)商。SSL握手協(xié)議：用來交換版本號、加密算法、（相互）身份認證并交換密鑰。SSLv3提供對Deffie-Hellman密鑰交換算法、基于RSA的密鑰交換機制和另?種實現在Fortezzachip上的密鑰交換機制的支持。1996年4月，IETF授權一個傳輸層安全（TLS）工作組著手制定一個傳輸層安全協(xié)議（TLSP）,以便作為標準提案向1ESG正式提交。TLSP將會在許多地方酷似SSL.因特網層安仝機制的主要優(yōu)點是它的透明性，即安全服務的提供不要求應用層做任何改變，這時傳輸層來說是做不到的。原則上，任何TCP/IP應用，只要應用傳輸層安全協(xié)議，比如說SSL或PCT,就必定要進行若干修改以增加相應的功能，并使用（稍微）不同的IPC界面。于是，傳輸層安全機制的主:要缺點就是要對傳輸層1PC界面和應用程序兩端都進行修改.可是，比起應用層的安全機制來，這里的修改還是相當小的。另一個缺點是，基于UDP的通信很難在傳輸層建立起安仝機制來。同網絡層安全機制相比,傳輸層安全機制的主要優(yōu)點是它提供基丁進程對進程的（而不是主機對主機的）安全服務.這一成就如果再加上應用級的安全服務，就可以再向前跨越?大步了.5應用層實現安全傳輸通道網絡層（或傳輸層）的安全協(xié)議允許為主機（進程）之間的數據通道增加安全屬性。本質上，這意味著真正的安全數據通道還是建立在主機（或進程）之間，但對同一通道I：傳輸的具體文件的安全性要求卻不能區(qū)分.比如說，如果?個主機與另?個主:機之間建立起?條安全的IP通道，那么所有在這條通道上傳輸的IP包就都要自動地被加密。同樣，如果一個進程和另一個進程之間通過傳輸層安全協(xié)議建立起了一條安全的數據通道，那么兩個進程間傳輸的所有消息就都要自動地被加密。如果確實想要區(qū)分具體文件的不同的安全性要求，那就必須借助于應用層的安全性。提供應用層的安全服務實際上是最靈活的處理單個文件安全性的手段。例如一個電子郵件系統(tǒng)可能需要對要發(fā)出的信件的個別段落實施數字簽名。較低層的協(xié)議提供的安全功能一般不會知道任何要發(fā)出的信件的段落結構，從而不可能知道該對哪一部分進行簽名。只有應用層是唯一能夠提供這種安全服務的層次。在應用層提供安全服務主要有以下幾種可能的做法：1）就是對每個應用（或應用協(xié)議）分別進行修改，這是最容易想到的，一些重要的TCP/IP應用也已經這樣做了。比如S-HTTP,它是Web上使用的超文本傳輸協(xié)議（HTTP）的安全增強版本，提供文件級的安全機制。2）安全外殼（SecureShell,簡稱SSH）：上述方法面臨一個主要的問題，就是每個這樣的應用都要單獨進行相應的修改，如果能有一個統(tǒng)一的修改手段，那就好多了.通往這個方向的一個步驟就是赫爾辛基大學的TatuYloenen開發(fā)的安全sheU（SSH）.SSH允許其用戶安全地登錄到遠程主機上，執(zhí)行命令，傳輸文件。它實現了?個密鑰交換協(xié)議，以及主機及客戶端認證協(xié)議。3）認證和密鑰分配協(xié)議：把SSH的思路再往前推進一步，就到了認證和密鑰分配系統(tǒng)，本質上，認證和密鑰分配系統(tǒng)提供的是?個應用編程接口（API），它可以用來為任何網絡應用程序提供安全服務，例如:認證、數據機密性和完整性、訪問控制以及非否認服務。目前已經有一些實用的認證和密鑰分配系統(tǒng)，如：MIT的Kerberos,IBM的CryptoKnight和NetwrokSecurityProgram等都是得到廣泛采用的實例。4）通用安全服務編程接I」（SecureServiceProgrammingInterface.簡稱GSS-API）：認證和密鑰分配協(xié)議的一個問題是它仍要求對應用本身做出改動?？紤]到這一點，對一個認證和密鑰分配協(xié)議來說，提供一個標準化的安全API就顯得格外重要。能做到這一點，開發(fā)人員就不必再為增加很少的安全功能而對整個應用程序大動干戈了。因此，認證系統(tǒng)設計領域內最主要的進展之一就是制定了標準化的安仝API,即通用安全服務API（GSS-API）.GSS-API（vl及v2）對于一個非安全專家的編程人員來說可能仍顯得過于技術化了些，但德州Austin大學的研究者們開發(fā)的安全網絡編程（SNP）,把界面做到了比GSS-API更高的層次，使同網絡安全性有關的編程更加方便了。6小結在網I:建立安全傳輸通道是使用網絡開展關鍵業(yè)務的必然需求，對了不同的應用，需要在不同的層次來考慮安全傳輸。也就是說，不同層次的安全傳輸通道技術提供的功能和特性各不相同，因而應用領域也不同：PPTP和L2TP協(xié)議可保障客戶機與遠程網絡之間的通信安全，主要用于遠程訪問VPN-IPSec規(guī)范可保障主機之間、安全網關之間（如路由器或防火墻）或主機與安全網關之間的數據報的安全。它可以實現各種方式的VPN：ExtraNetVPN、IntraNetVPN和遠程訪問VPN，是應用領域最廣泛，功能最全面，使用最靈活的一種保障端到端通信安全的因特網安全標準。傳輸層安全機制可提供應用程序之間（即進程之間）的安全服務，而不是主機之間（IPSec提供的）；缺點是通信的應用程序兩端都要進行少量的修改，FL基于UDP的通信很難在傳輸層建立起安全機制來。應用層安全機制可以區(qū)分具體文件的不同的安全性要求，它實際上是最靈活的唯?的處理單個文件安全性的手段；但每種應用為了獲得所需的安全服務都要進行大量的修改，不像在數據鏈路層和網絡層實現安全可以做到一勞永逸。參考文獻[1][美1ThomasLeeJosephDavies著，北京超品計算機有限責任公司譯.Windows2000TCP/IP協(xié)議和服務技術參考.人民郵電出版社,2000年11月.410-419頁[2]（美）NaganandDoraswamy,DanHarkins著，京京工作室譯.IPSec新一代因特網安全標準.機械工業(yè)出版社，2000年3月S.Kent&R.Atkinson.IPEncapsulatingSecurityPayload（ESP）,RFC2406.November1998。S.Kent&R.Atkinson.IPAuthenticationHeader,RFC2402.November1998D.Piper.TheInternetIPSecurityDomainofInterpretationforISAKMPRFC2407.November1998[6]（美）NaganandDoraswamy,DanHarkins著，京京工作室譯.IPSec新?代因特網安全標準.機械工業(yè)出版社，2000年3月.4042頁.[7]MicrosoftCorp.MSDN2001,Windows2000DDK,NetworkDrivers.[8]（美）DavidA.Rusling等著，朱珂，涂二等譯.Linux編程白皮書.The