IPsec
網際網路安全協定(英語:Internet Protocol Security,縮寫:IPsec)是一個協議套件,透過對IP協議的分組進行加密和認證來保護IP協議的網絡傳輸協議族(一些相互關聯的協議的集合)。
標準現狀
編輯IPsec的源始編碼是在IPv4的環境中於1994年開發,第一版IPsec協議在RFC 2401-2409中定義。在2005年第二版標準文檔發布,新的文檔定義在RFC 4301和RFC 4309中[7][8]。在IPv4中IPsec的使用是一個可選項,在IPv6 RFC 6434中為必選的內容 [9],這樣做的目的,是為了隨着 IPv6的進一步流行,IPsec可以得到更為廣泛的使用。
歷史概要
編輯從1920-70年代初開始,美國高級研究項目局贊助了一系列實驗性的ARPANET加密設備,起初用於本地ARPANET數據包加密,隨後又用於TCP/IP數據包加密。
從1986年到1991年,美國國家安全局在其安全數據網絡系統(SDN)計劃下贊助了互聯網安全協議的開發,包括摩托羅拉在內的各種供應商聚集在一起,於1988年生產了一種網絡加密設備,這項工作於1988年由NIST公開發表,其中第3層的安全協議(SP3)演變為ISO標準的網絡層安全協議(NLSP)。[10]
從1992年到1995年,有三個研究小組對IP層加密分別進行了獨立研究:
- 1. 1992年,美國海軍研究實驗室(NRL)開始了Simple Internet Protocol Plus(SIPP)項目來進行IP加密協議的研究。
- 2. 1993年,哥倫比亞大學SunOS和AT&T貝爾實驗室,開始由 JohnIoanndis等人研發實驗性軟件IP加密協議 (swIPe)。
- 3. 1993年,在白宮信息高速公路項目的支持下,Trusted Information Systems(TIS)科學家徐崇偉(Wei Xu)[11] 研究和開發了第一代軟件 IPSEC 協議,它的編碼是在BSD 4.1內核中完成的,支持x86和SUNOS CPU架構,同時開發了硬件安全3DES的加密技術,並為數據加密標準開發了設備驅動程序。到1994年12月,TIS發布了由DARPA贊助的開放源代碼的「手銬防火牆」產品,其VPN速度超過T1,首次用 IPSec VPN 實現了美國東西海岸安全鏈接,也是歷史上第一個 IPSec 商用產品。[12]
- 4. 在美國國防部高級研究計劃局(DARPA)資助的研究工作下,1996年,NRL為IPsec開發了IETF標準跟蹤規範(rfc1825到rfc1827),它的編碼是在BSD 4.4內核中,同時支持x86和SPARC CPU架構[13] 。
互聯網工程任務組(IETF)於1992年成立了IP安全工作組,以規範對 IPsec 的公開協議,1995年工作組成員有 TIS、Cisco、FTP、Checkpoint 等五個企業組成,首次合作協商改進了 NRL 起草的 IPsec 協議標準,以及規範了 Cisco 和 TIS 提供的 IPsec 開放源代碼,此後,發布了RFC-1825和RFC-1827,NRL在1996年 USENIX 會議論文集中進行了描述了,由麻省理工學院在線提供,並成為大多數初始商業實現的基礎。[14]
設計意圖
編輯IPsec被設計用來提供(1)入口對入口通信安全,在此機制下,分組通信的安全性由單個節點提供給多台機器(甚至可以是整個局域網);(2)端到端分組通信安全,由作為端點的計算機完成安全操作。上述的任意一種模式都可以用來構建虛擬專用網(VPN),而這也是IPsec最主要的用途之一。應該注意的是,上述兩種操作模式在安全的實現方面有着很大差別。
因特網範圍內端到端通信安全的發展比預料的要緩慢[來源請求],其中部分原因,是因為其不夠普遍或者說不被普遍信任。公鑰基礎設施能夠得以形成(DNSSEC最初就是為此產生的),一部分是因為許多用戶不能充分地認清他們的需求及可用的選項,導致其作為內含物強加到賣主的產品中(這也必將得到廣泛採用);另一部分可能歸因於網絡響應的退化(或說預期退化),就像兜售信息的充斥而帶來的帶寬損失一樣。
IPsec與其它互聯網安全協議的對比
編輯IPsec協議工作在OSI模型的第三層,使其在單獨使用時適於保護基於TCP或UDP的協議(如安全套接子層(SSL)就不能保護UDP層的通信流)。這就意味着,與傳輸層或更高層的協議相比,IPsec協議必須處理可靠性和分片的問題,這同時也增加了它的複雜性和處理開銷。相對而言,SSL/TLS依靠更高層的TCP(OSI的第四層)來管理可靠性和分片。
技術細節
編輯此條目需要更新。 (2020年5月22日) |
認證頭(AH)
編輯認證頭(Authentication Header,AH)被用來保證被傳輸分組的完整性和可靠性。此外,它還保護不受重放攻擊。認證頭試圖保護IP數據報的所有字段,那些在傳輸IP分組的過程中要發生變化的字段就只能被排除在外。當認證頭使用非對稱數字簽名算法(如RSA)時,可以提供不可否認性(RFC 1826)[15]。
認證頭分組圖示:
位偏移 | 字節 | 0 | 1 | 2 | 3 |
---|---|---|---|---|---|
位 | 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |
0 | 下一個頭 | 載荷長度 | 保留 | ||
32 | 安全參數索引(SPI) | ||||
64 | 序列號 | ||||
96+ | 認證數據(可變長度) |
字段含義:
- 下一個頭:標識被傳送數據所屬的協議。
- 載荷長度:認證頭包的大小。
- 保留:為將來的應用保留(目前都置為0)。
- 安全參數索引:與IP地址一同用來標識安全參數。
- 序列號:單調遞增的數值,用來防止重放攻擊。
- 認證數據:包含了認證當前包所必須的數據。
封裝安全載荷(ESP)
編輯封裝安全載荷(Encapsulating Security Payload,ESP)協議對分組提供了源可靠性、完整性和保密性的支持。與AH頭不同的是,IP分組頭部不被包括在內。
ESP分組圖示:
位偏移 | 字節 | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
位 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | |
0 | 安全參數序列(SPI) | ||||||||||||||||||||||||||||||||
32 | 序列號 | ||||||||||||||||||||||||||||||||
64+ | 載荷*(可變長度) | ||||||||||||||||||||||||||||||||
填充(0-255字節) | |||||||||||||||||||||||||||||||||
填充長度 | 下一個頭 | ||||||||||||||||||||||||||||||||
認證數據(可變長度) |
字段含義:
- 安全參數索引:與IP地址一同用來標識安全參數
- 序列號:單調遞增的數值,用來防止重放攻擊。
- 載荷數據:如果沒使用ESP的加密功能,則載荷數據域的內容是「下一個頭」所指示的數據;如果使用了ESP的加密功能,則使用加密載荷數據和ESP尾部數據所得的密文作為payload data.
- 填充:某些塊加密算法用此將數據填充至塊的長度。
- 填充長度:以位為單位的填充數據的長度。
- 下一個頭:標識載荷中封裝的數據所屬的協議。
- 認證數據:又叫做完整性校驗值(ICV)。包含了認證當前包所必須的數據。
安全關聯(SA)
編輯實現
編輯FreeS/WAN項目已經開發了一個開源的GNU/Linux作業系統下的IPsec實現。Free S/WAN項目的開發在2004年時被中止。Openswan、strongSwan和libreswan是Free S/WAN延續。
至今已有許多IPsec協議和ISAKMP/IKE協議的實現。它們包括:
- NRL IPsec,屬於原型的一種
- OpenBSD,代碼源於NRL IPsec
- Mac OS X,包含了Kame IPsec的代碼
- Cisco IOS
- Microsoft Windows
- SSH Sentinel(現作為SafeNet的一部分)提供了工具包
- Solaris
- FreeBSD
- NetBSD
- Android
- iOS
參見
編輯參考文獻
編輯- ^ Thayer, R.; Doraswamy, N.; Glenn, R.. IP Security Document Roadmap. IETF. November 1998. . RFC 2411.
- ^ Hoffman, P.. Cryptographic Suites for IPsec. IETF. December 2005. . RFC 4308.
- ^ Kent, S.; Atkinson, R.. IP Authentication Header. IETF. November 1998. . RFC 2402.
- ^ Kent, S.. IP Authentication Header. IETF. December 2005. . RFC 4302.
- ^ Kent, S.; Atkinson, R.. IP Encapsulating Security Payload (ESP). IETF. November 1998. . RFC 2406.
- ^ The Internet Key Exchange (IKE), RFC 2409, §1 Abstract
- ^ RFC 4301
- ^ RFC 4309
- ^ "IPv6 Node Requirements", E. Jankiewicz, J. Loughney, T. Narten (December 2011)
- ^ Network Encryption - history and patents. [2022-01-18]. (原始內容存檔於2014-09-03).
- ^ Trusted Information Systems. (原始內容存檔於2020-06-21).
- ^ The history of VPN creation. (原始內容存檔於2020-09-29).
- ^ "https://www.usenix.org/legacy/publications/library/proceedings/sd96/atkinson.html (頁面存檔備份,存於網際網路檔案館)"
- ^ IETF IP Security Protocol (ipsec) Working group History. (原始內容存檔於2019-09-13).
- ^ RFC 1826
外部連結
編輯- 計算機系統安全
- IPsec簡介[永久失效連結]
- IETF的IPsec工作組。
- Free S/WAN項目主頁(頁面存檔備份,存於網際網路檔案館)。
- Openswan項目主頁(頁面存檔備份,存於網際網路檔案館)。
- strongSwan項目主頁(頁面存檔備份,存於網際網路檔案館)。
- VPN社團(頁面存檔備份,存於網際網路檔案館)。
- A long thread on the ipsec@lists.tislabs.com關於是否要將字母S大寫,RFC文檔寫的很清楚,應該是IPsec。