ipsec(AH和ESP)
介紹
最初的IP協議是沒有任何的安全措施的。IP資料報含有諸如源地址,目的地址,版本,長度,生存週期,承載協議,承載資料等欄位。雖然其擁有“首部校驗和”這樣的欄位來提供極其簡易的完整性功能,但無力抗拒對資料的意外或者故意修改,也無法阻止資訊的洩露等問題。
IPSec(Intemet Protocol Security)是由IEIF設計的一種端到端的確保IP層通訊安全的機制,它不是一個單獨的協議,而是一組協議。IPSec是IPv6的組成部分,也是IPv4的可選擴充套件協議。目前IPSec最主要的應用是構造虛擬專用網(VPN),它作為一個第三層隧道協議實現了VPN通訊,可以為IP網路通訊提供透明的安全服務,保證資料的完整性和機密性,有效抵禦網路攻擊。它所使用的加密演算法和完整性驗證演算法從目前看來是不可能被破解的。定義IPSec協議簇的RFC如表3.5.1所示。
RFC | 內容 |
---|---|
2401 | IPSec體系結構 |
2402 | AH協議 |
2403 | HMAC-MD5-96在AH和ESP中的應用 |
2404 | HMAC-SHA-1-96在AH和ESP中的應用 |
2405 | DES-CBC在ESP中的應用 |
2406 | ESP協議 |
2407 | IPSec DOI |
2408 | ISAKMP協議 |
2409 | IKE協議 |
2410 | NULL加密演算法及其在IPSec中的應用 |
2411 | IPSec文件路線圖 |
2412 | OAKLEY協議 |
IPSec眾多的RFC通過關係圖組織在一起,IPSec各元件的關係圖如圖3.5.1所示。
它包含了三個最重要的協議:認證頭AH(Authentication Header),封裝安全載荷ESP(Encapsulating Security Payload),金鑰交換協議IKE(Internet Key Exchange),注意這些協議的使用均可獨立於具體的加密演算法:
(1)AH為IP資料包提供3種服務(統稱驗證):資料完整性驗證,通過使用Hash函式(如MD5)產生的驗證碼來實現;資料完整性時加入一個共享的會話金鑰來實現;防重放攻擊,在AH報頭中加入序列號可以防止重放攻擊。
(2)ESP除了為IP資料包提供AH上述的3種服務外,還能夠提供資料加密。
3.5.2 技術細節
(1)認證頭(AH)
AH概述
IPSec的子協議頭認證協議AH,為IP報文提供資料完整性驗證和資料來源身份認證,使用的是HMAC演算法,HMAC演算法和非常相似,一般是由Hash演算法演變而來,也就是將輸入報文和雙方事先已經共享的對稱金鑰結合然後應用Hash演算法。採用相同的HMAC演算法並共享金鑰的雙方才能產生相同的驗證資料。所有的IPSec必須實現兩個演算法:HMAC-MD5和HMAC-SHA1.
AH和ESP的最大區別有兩個:一個是AH不提供加密服務,另一個是它們驗證的範圍不同,ESP不驗證IP報頭,而AH同時驗證部分報頭,所以需要結合使用AH和ESP才能保證IP報頭的機密性和完整性。AH為IP報頭提供儘可能多的驗證保護,驗證失敗的包將被丟棄,不交給上層協議解密,這種操作模式可以減少拒絕服務攻擊成功的機會。
AH頭部格式
AH協議是被IP協議封裝的協議之一,如果IP協議頭部的“下一個頭”欄位是51,則IP包的載荷就是AH協議,在IP包頭後面跟的就是AH協議頭部。AH報文頭部如圖3.5.2所示。
8位 | 8位 | 16位 |
下一個頭 | 有效載荷長度 | 保留 |
安全引數索引(SPI) | ||
序列號 | ||
驗證資料(可變長度) |
(1)下一個頭(8位):表示緊跟在AH頭部後面的協議型別。在傳輸模式下,該欄位是處於保護中的傳輸層協議的值,如6(TCP),17(UDP)或50(ESP)。在隧道模式下,AH保護整個IP包,該值是4,表示是IP-in-IP協議。
(2)有效載荷長度(8位):其值是以32位(4位元組)為單位的整個AH資料(包括頭部和變長驗證資料)的長度再減2。
(3)保留(16位):準備將來對AH協議擴充套件時使用,目前協議規定這個欄位應該被置為0。
(4)安全引數索引SPI(32位):值為[256,2^32-1]。實際上它是用來標識傳送方在處理IP資料包時使用了哪些安全策略,當接收方看到這個欄位後就知道如何處理收到的IPsec包。
(5)序列號(32位):一個單調遞增的計數器,為每個AH包賦予一個序號。當通訊雙方建立SA時,初始化為0。SA是單向的,每傳送/接收一個包,外出/進入SA的計數器增1。該欄位可用於抗重放攻擊。
(6)驗證資料:可變長,取決於採用何種訊息驗證演算法。包含完整性驗證碼,也就是HMAC演算法的結果,稱為ICV,它的生成演算法由SA指定。
(2)封裝安全載荷(ESP)
ESP概述
ESP協議提供資料完整性驗證和資料來源身份認證的原理和AH一樣,只是和AH比ESP的驗證範圍要小些。ESP協議規定了所有IPSec系統必須實現的驗證演算法:HMAC-MD5,HMAC-SHA1,NULL。和L2TP,GRE,AH等其他軌道技術相比,ESP具有特有的安全機制——加密,而且可以和其他隧道協議結合使用,為使用者的遠端通訊提供更強大的安全支援。ESP加密採用的則是對稱加密演算法,它規定了所有IPSec系統必須實現的加密演算法是DES-CBC和NULL,使用NULL是指實際上不進行加密或驗證。
ESP頭部格式
ESP協議是被IP協議封裝的協議之一。如果IP協議頭部的“下一個頭”欄位是50,IP包的載荷就是ESP協議,在IP包頭後面跟的就是ESP協議頭部。ESP報文頭部如3.5.3所示,其中ESP頭部包含SPI和序列號欄位,ESP尾部包含填充項,填充長度和下一個頭欄位。
8位 | 8位 | 16位 | |
安全引數索引(SPI) | |||
序列號 | |||
報文有效載荷(長度可變) | |||
填充項(可選)(長度可變) | |||
填充長度 | 下一個頭 | ||
驗證資料(可選) |
(1)安全引數索引SPI(32位):值為[256,2^32-1]。
(2)序列號(32位):一個單調遞增的計數器,為每個AH包賦予一個序號。當通訊雙方建立SA時,初始化為0。SA是單向的,每傳送/接收一個包,外出/進入SA的計數器增1。該欄位可用於抗重放攻擊。
(3)報文有效載荷:是變長的欄位,如果SA採用加密,該部分是加密後的密文;如果沒有加密,該部分就是明文。
(4)填充項:是可選的欄位,為了對齊待加密資料而根據需要將其填充到4位元組邊界。
(5)填充長度:以位元組為單位指示填充項長度,範圍為[0,255]。保證加密資料的長度適應分組加密演算法的長度,也可以用以掩飾載荷的真實長度對抗流量分析。
(6)下一個頭:表示緊跟在ESP頭部後面的協議,其中值為6表示後面封裝的是TCP。
(7)驗證資料:是變長欄位,只有選擇了驗證服務時才需要有該欄位。
很多情況下,AH的功能已經能滿足安全的需要,ESP由於需要使用高強度的加密演算法,需要消耗更多的計算機運算資源,使用上受到一定限制。
在IPSec協議簇中使用兩種不同功能的協議使得IPSec具有對網路安全細粒度的功能選則,便於使用者依據自己的安全需要對網路進行靈活配置。
(3)IPSec的兩種模式
a. 傳輸模式
傳輸模式(Transport Mode)是IPSec的預設模式,又稱端到端(End-to-End)模式,它適用於兩臺主機之間進行IPSec通訊。
傳輸模式下只對IP負載進行保護,可能是TCP/UDP/ICMP協議,也可能是AH/ESP協議。傳輸模式只為上層協議提供安全保護,在此種模式下,參與通訊的雙方主機都必須安裝IPSec協議,而且它不能隱藏主機的IP地址。啟用IPSec傳輸模式後,IPSec會在傳輸層包的前面增加AH/ESP頭部或同時增加兩種頭部,構成一個AH/ESP資料包,然後新增IP頭部組成IP包。在接收方,首先處理的是IP,然後再做IPSec處理,最後再將載荷資料交給上層協議。
IP頭 | IPSec頭 | IP載荷 |
傳輸模式的資料包結構
b. 隧道模式
隧道模式(Tunnel Mode)使用在兩臺閘道器之間,站點到站點(Site-to-Site)的通訊。參與通訊的兩個閘道器實際是為了兩個以其為邊界的網路中的計算機提供安全通訊的服務。
隧道模式為整個IP包提供保護,為IP協議本身而不只是上層協議提供安全保護。通常情況下只要使用IPSec的雙方有一方是安全閘道器,就必須使用隧道模式,隧道模式的一個優點是可以隱藏內部主機和伺服器的IP地址。大部分VPN都使用隧道模式,因為它不僅對整個原始報文加密,還對通訊的源地址和目的地址進行部分和全部加密,只需要在安全閘道器,而不需要在內部主機上安裝VPN軟體,期間所有加密和
解密以及協商操作均由前者負責完成。
啟用IPSec隧道模式後,IPSec將原始IP看作一個整體作為要保護的內容,前面加上AH/ESP頭部,再加上新IP頭部組成新IP包。隧道模式的資料包有兩個IP頭,內部頭由路由器背後的主機建立,是通訊終點;外部頭由提供IPSec的裝置(如路由器)建立,是IPSec的終點。事實上,IPSec的傳輸模式和隧道模式分別類似於其他隧道協議(如L2TP)的自願隧道和強制隧道,即一個是由使用者實施,另一個由網路裝置實施。
外部IP頭 | IPSec頭 | 內部IP頭 | IP載荷 |
隧道模式下,隧道中的資料包結構
(4)身份驗證與AH
AH通過對報文應用一個使用金鑰的單向雜湊函式來建立一個雜湊或訊息摘要來進行身份驗證。雜湊與文字合在一起傳輸。接收方對接收到的報文運用同樣的單向雜湊函式並將結果與傳送方提供的訊息摘要的值比較,從而檢測報文在傳輸過程中是否有部分發生變化。由於單向雜湊也包含兩個系統之間的一個共享金鑰,因此能確保真實性。
AH作用於整個報文,但任意會在傳輸中改變的IP頭欄位除外。例如,由沿傳輸路徑的路由器修改的生存時間(Time to Live, TTL)欄位是可變欄位。
AH的處理過程順序如下。
步驟1 使用共享金鑰對IP頭和資料載荷進行雜湊。
步驟2 雜湊構建一個新的AH頭,插入到原始報文中。
步驟3 新報文路由器使用共享金鑰對IP頭和資料載荷進行雜湊,從AH頭中取出傳輸的雜湊,再比較兩個雜湊。
雜湊值必須精確匹配。如果報文傳輸中有一個位元位發生了變化,則接收到的報文的雜湊輸出將改變,AH頭將不能匹配。
AH支援HMAC-MD5和HMAC-SHA-1演算法。在使用NAT的環境中,AH可能會遇到問題。
(5)使用ESP進行身份驗證與加密
ESP通過加密載荷實現機密性,它支援多種對稱加密演算法。如果選擇了ESP作為IPSec協議,也必須選擇一種加密演算法。IPSec的預設演算法是56位DES。
ESP也能提供完整性和認證。首先對載荷加密,然後對加密過的載荷使用一種雜湊演算法(HMAC-MD5或HMAC-SHA-1)。雜湊為資料載荷提供認證和資料完整性。
作為可選功能,ESP還能進行防重放保護。防重放保護驗證每個報文是唯一的且沒有被複制,這種保護確保黑客不能攔截報文和在資料流中插入改變後的報文。防重放的工作原理是跟蹤報文順序號並在目的端使用一個滑動視窗。當在源和目的間建立了一條連線時,兩端的計數器被初始化為0。每次有報文傳送時,源給報文追加一個順序號,目的端使用滑動視窗確定預期的順序號。目的端驗證的報文的順序號不是複製的,並且以正確的順序被接收。例如,如果目的端的滑動視窗設為1,目的端期望接收到順序號為1的報文。收到這樣的報文後,滑動視窗進入到2.如果檢測到重放的報文,重放報文將被丟棄,對此事件記錄日誌。
原始資料通過ESP得到良好保護,因為完整的原始IP資料報和ESP附加尾部都被加密。使用ESP認證,加密的IP資料報和附加尾部以及ESP頭都得到雜湊程序處理。最後,一個新的IP頭被附加到經過認證的載荷,使用新的IP地址在Internet中路由報文。
如果同時選擇了認證和加密,先執行加密。這種處理順序的一個原因是它有助於接收裝置快速檢測和丟棄重放的或偽造的報文。在解密報文之前,接收方可以認證進入的報文。這樣可以快速檢測到問題,並間接的降低了DoS攻擊的影響。