Przejdź do zawartości

IPsec

Z Wikipedii, wolnej encyklopedii

IPsec (ang. Internet Protocol Security, IP Security) – zbiór protokołów służących implementacji bezpiecznych połączeń oraz wymiany kluczy szyfrowania pomiędzy komputerami. Protokoły tej grupy mogą być wykorzystywane do tworzenia Wirtualnej Sieci Prywatnej (ang. VPN).

VPN oparta na IPsec składa się z dwóch kanałów komunikacyjnych pomiędzy połączonymi komputerami: kanał wymiany kluczy, za pośrednictwem którego przekazywane są dane związane z uwierzytelnianiem i szyfrowaniem (klucze), oraz kanału (jednego lub więcej), który niesie pakiety transmitowane poprzez sieć prywatną. Kanał wymiany kluczy jest standardowym protokołem UDP (port 500). Kanały przesyłu danych oparte są na protokole ESP (protokół IP numer 50) opisanym w dokumencie RFC 2406 ↓[1].

Architektura IPsec

[edytuj | edytuj kod]

Protokoły wchodzące w skład architektury IPsec służą do bezpiecznego przesyłania przez sieć pakietów IP. Działają one na zasadzie kapsułkowania, tj. oryginalny (zabezpieczany) pakiet IP jest szyfrowany, otrzymuje nowy nagłówek protokołu IPsec i w takiej formie jest przesyłany przez sieć.

Bezpieczeństwo zapewniane przez IPsec może być dwojakie, w zależności od stosowanego protokołu. I tak: pojawia się problem dystrybucji kluczy symetrycznych. Narzuca się zastosowanie kryptografii asymetrycznej, ale jest ona o wiele wolniejsza od szybkich szyfrów symetrycznych i dodanie ich do protokołów niskiego poziomu, jakimi są ESP i AH (Authentication Header), miałoby znaczący wpływ na wydajność. Te dwa protokoły pozostały więc relatywnie prostymi protokołami niskiego poziomu, a do skomplikowanych zadań dystrybucji klucza i uwierzytelniania stron stworzono oddzielny protokół IKE.

Protokół IKE

[edytuj | edytuj kod]

Protokół IKE (Internet Key Exchange) został zaprojektowany w większości przez NSA (National Security Agency) i jest skomplikowany, głównie ze względu na poziom abstrakcji, na jakim operuje. Wystarczy bowiem włożyć do niego własny zestaw algorytmów kryptograficznych, czy wręcz własną arytmetykę (zestaw ten określa się jako DOI, Domain of Interpretation), by otrzymać zupełnie inny od cywilnego protokół, na przykład na potrzeby wojska.

IKE funkcjonalnie składa się z dwóch części: specyfikacji metod kryptograficznych uwierzytelnienia i negocjacji kluczy Oakley (IKE: RFC 2409 ↓, IKEv1: RFC 4109 ↓, IKEv2: RFC 4306 ↓) oraz specyfikacji formatów pakietów i stanów protokołu ISAKMP. W praktyce nazwy ISAKMP używa się zamiennie z IKE.

Podstawowymi celami IKE są poniższe kroki, wykonywane kolejno:

  • uwierzytelnienie obu stron komunikacji wobec siebie za pomocą jednej z poniższych metod (ustalanych przez administratora):
    • hasło znane obu stronom (shared secret)
    • podpisy RSA (konieczna ręczna wymiana kluczy publicznych stron)
    • certyfikaty X.509 (najbardziej uniwersalna)
  • nawiązanie bezpiecznego kanału dla potrzeb IKE nazywanego ISAKMP SA (Security Association)
  • bezpieczne uzgodnienie kluczy kryptograficznych oraz parametrów tuneli IPsec
  • ewentualna ich renegocjacja co określony czas

Po nawiązaniu połączenia przez IKE obie strony mogą już stworzyć właściwe tunele IPsec (ESP lub AH) i rozpocząć komunikację. Jeśli wymagane jest, by klucze kryptograficzne były regularnie (np. co 8 godzin) zmieniane, IKE również to umożliwia.

Praktyczną konsekwencją stosowania IKE jest to, że zamiast ręcznie konfigurować klucze (i wiele innych parametrów) na obu stronach połączenia administrator może w najprostszym przypadku skonfigurować na nich tylko hasło shared secret, by w pełni automatycznie uzyskać tunele IPsec.

Szczegóły IPsec

[edytuj | edytuj kod]

Istotną cechą ESP i AH jest mała ilość informacji, jakie potencjalny atakujący otrzymuje w wyniku podsłuchiwania szyfrowanej komunikacji. Po włączeniu sniffera zobaczy on tylko zaszyfrowany pakiet opatrzony dwiema liczbami:

  • SPI (Security Parameters Index)
  • numer sekwencyjny

Wartość SPI jest stała, najczęściej jest generowana losowo i ma kluczowe znaczenie dla stron połączenia, a żadnego dla atakującego. Strony połączenia bowiem na podstawie SPI rozpoznają, do jakiej sesji (tunelu) IPsec przynależy dany pakiet i jakie w związku z tym zastosować szyfry oraz klucze do jego rozszyfrowania.

Przykładowo, SPI 0x123456 może oznaczać, że dany pakiet należy do kanału IPsec łączącego sieci B i C, szyfrowanego 3DES z kluczem X. Inne SPI mogłoby oznaczać kanał między D i E, szyfrowany AES z kluczem Y. Numer SPI jest ustalany przez strony podczas tworzenia kanału i jest stały podczas jego istnienia.

Numer sekwencyjny jest losowany i zwiększany o 1 z każdym wysłanym przez dany kanał pakietem i służy do rozpoznawania pakietów o kolejności przestawionej podczas wędrówki po sieci oraz chroni przed atakami przez powtórzenie (replay attacks). Ponieważ numer ten jest wartością 32-bitową, po 232 wysłanych pakietów kanał musi być zamknięty, a w jego miejsce stworzony nowy, z licznikiem startującym od nowej wylosowanej liczby.

Jednokierunkowość

[edytuj | edytuj kod]

Kolejną istotną cechą kanałów IPsec jest ich jednokierunkowość – dany kanał obsługuje tylko ruch idący z hosta A do B. Każda pełna łączność wykorzystuje dwa kanały – jeden od A do B, drugi od B do A. Każdy z nich ma inne SPI, osobny licznik sekwencyjny, inne klucze kryptograficzne.

Taki jednokierunkowy kanał IPsec (ESP lub AH) jest określany nazwą Security Association (która nie ma dobrego polskiego tłumaczenia, stąd w artykule używane jest określenie „kanał”). Każde SA charakteryzuje się przez adresy IP początku i końca oraz SPI.

Klucze kryptograficzne

[edytuj | edytuj kod]

Do pełnej łączności między dwoma hostami potrzebne są dwa kanały IPsec. Jeśli wykorzystany zostanie protokół ESP, to każdy kanał będzie wymagał dwóch kluczy kryptograficznych – jednego do szyfrowania danych, drugiego do ochrony integralności i uwierzytelnienia. Jeśli będzie to AH, to odpadnie pierwszy klucz (szyfrujący). W najbardziej złożonym przypadku ESP do pełnej komunikacji będą potrzebne cztery klucze:

  • szyfrujący dla kanału relacji A do B
  • uwierzytelniający dla kanału relacji A do B
  • szyfrujący dla kanału relacji B do A
  • uwierzytelniający dla kanału relacji B do A

Jest to kolejny powód, dla którego ręczna konfiguracja kanałów IPsec jest uciążliwa – w przypadku stosowania IKE wszystkie klucze uzgadniane są automatycznie.

Tryb transportowy i tunelowy

[edytuj | edytuj kod]

Nagłówek IPsec – ESP można stosować w dwóch trybach: transportowym lub tunelowym. Typowy pakiet IP wygląda następująco (zakładając, że protokołem wyższej warstwy będzie TCP):

+----+-----+--------------------
| IP | TCP | dane użytkownika...
+----+-----+--------------------

Tryb transportowy polega na tym, że pomiędzy nagłówek IP a TCP dokładamy jeszcze dodatkowo nagłówek IPsec (załóżmy, że jest to ESP). Część oznaczona podwójną linią jest zaszyfrowana i całkowicie nieprzezroczysta dla ewentualnego podsłuchującego. Podlega ona także ochronie integralności.

+----+-----+==========================
| IP | ESP | TCP | dane użytkownika...
+----+-----+==========================

Jak widać, w trybie transportowym niewidoczne są dane użytkownika, ale nagłówek IP pozostaje widoczny. Atakujący nie wie zatem, o czym się rozmawia, ale wie za to, kto z kim tę konwersację prowadzi.

Tryb tunelowy zapewnia wyższy poziom ochrony – pakiet użytkownika jest w całości enkapsulowany w ESP, a na początek jest dokładany zupełnie nowy nagłówek IPn:

+-----+-----+===============================
| IPn | ESP | IP | TCP | dane użytkownika...
+-----+-----+===============================

Jeśli stacja A i B będą się łączyły bezpośrednio za pomocą trybu tunelowego, to nagłówek IPn będzie praktycznie identyczny jak oryginalny IP i całość będzie praktycznie równa trybowi transportowemu. Ale dzięki trybowi tunelowemu jest możliwe tworzenie wirtualnych sieci prywatnych (VPN), które stanowią główne zastosowanie IPsec.

Kluczową cechą VPN jest możliwość stworzenia szyfrowanego tunelu pomiędzy dwiema bramkami (B) łączącymi dwie części sieci korporacyjnej przez sieć publiczną:

10.1.1.0/24 ----- B1 ========= B2 ------ 10.2.2.0/24

Atakujący widzi wówczas wyłącznie zaszyfrowane pakiety przesyłane pomiędzy B1 i B2. Oryginalne pakiety są ukryte w tunelu i podsłuchującemu nie jest znana ani ich treść, ani nawet zastosowana w sieci korporacyjnej adresacja.

Zaletą stosowania trybu tunelowego jest niewielki narzut wielkości pakietu (mniej niż 2% przy MTU 1500 bajtów) wynikający z konieczności dodawania drugiego nagłówka IP. Wadą trybu transportowego jest niemożność tunelowania w nim pakietów dla innych sieci.

IPSec NAT Traversal

[edytuj | edytuj kod]

W przypadku protokołu AH nie jest możliwa zamiana adresu źródłowego w nagłówku pakietu IP, gdyż cały nagłówek zabezpieczony jest przed zmianą. Do nagłówka dodawany jest skrót kryptograficzny powstały z sumy kontrolnej pakietu oraz tajnego hasła. Jakakolwiek modyfikacja pakietu uznana będzie przez drugą stronę za naruszenie integralności danych. Dla protokołu AH nie jest możliwa translacja adresów.

W przypadku protokołu ESP sprawa wygląda lepiej, ponieważ ochronie integralności nie podlega zewnętrzny nagłówek IP, dlatego możliwa jest zamiana źródłowego adresu IP. Jednak gdy istnieje wielu klientów znajdujących się za tym samym routerem (maskaradą), wtedy pojawia się problem, ponieważ protokół ten nie wykorzystuje portów, tak jak to ma miejsce w przypadku protokołów TCP i UDP, dlatego nie można w prosty sposób odróżnić połączeń IPSec inicjowanych z różnych hostów wewnątrz sieci. Rozwiązaniem problemu jest tzw. NAT Traversal.

NAT Traversal polega na kapsułkowaniu pakietów IP na protokół UDP ze standardowym nagłówkiem UDP, który już umożliwia translację NAT poprzez routery i transmisję ramek pomiędzy węzłami sieci. Stąd nazwa NAT-Trawersowanie.

Dokumentacja IETF

[edytuj | edytuj kod]

Standardowe RFC

[edytuj | edytuj kod]
  • RFC 1829 ↓: The ESP DES-CBC Transform
  • RFC 2403 ↓: The Use of HMAC-MD5-96 within ESP and AH
  • RFC 2404 ↓: The Use of HMAC-SHA-1-96 within ESP and AH
  • RFC 2405 ↓: The ESP DES-CBC Cipher Algorithm With Explicit IV
  • RFC 2410 ↓: The NULL Encryption Algorithm and Its Use With IPsec
  • RFC 2451 ↓: The ESP CBC-Mode Cipher Algorithms
  • RFC 2857 ↓: The Use of HMAC-RIPEMD-160-96 within ESP and AH
  • RFC 3526 ↓: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
  • RFC 3602 ↓: The AES-CBC Cipher Algorithm and Its Use with IPsec
  • RFC 3686 ↓: Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)
  • RFC 3947 ↓: Negotiation of NAT-Traversal in the IKE
  • RFC 3948 ↓: UDP Encapsulation of IPsec ESP Packets
  • RFC 4106 ↓: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
  • RFC 4301 ↓: Security Architecture for the Internet Protocol
  • RFC 4302 ↓: IP Authentication Header
  • RFC 4303 ↓: IP Encapsulating Security Payload
  • RFC 4304 ↓: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
  • RFC 4307 ↓: Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
  • RFC 4308 ↓: Cryptographic Suites for IPsec
  • RFC 4309 ↓: Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
  • RFC 4543 ↓: The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
  • RFC 4555 ↓: IKEv2 Mobility and Multihoming Protocol (MOBIKE)
  • RFC 4806 ↓: Online Certificate Status Protocol (OCSP) Extensions to IKEv2
  • RFC 4868 ↓: Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
  • RFC 4945 ↓: The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
  • RFC 5282 ↓: Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol
  • RFC 5386 ↓: Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
  • RFC 5529 ↓: Modes of Operation for Camellia for Use with IPsec
  • RFC 5685 ↓: Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)
  • RFC 5723 ↓: Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption
  • RFC 5857 ↓: IKEv2 Extensions to Support Robust Header Compression over IPsec
  • RFC 5858 ↓: IPsec Extensions to Support Robust Header Compression over IPsec
  • RFC 7296 ↓: Internet Key Exchange Protocol Version 2 (IKEv2)
  • RFC 7321 ↓: Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
  • RFC 7383 ↓: Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation
  • RFC 7427 ↓: Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
  • RFC 7634 ↓: ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec

Eksperymentalne RFC

[edytuj | edytuj kod]
  • RFC 4478 ↓: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol

Informacyjne RFC

[edytuj | edytuj kod]
  • RFC 2367 ↓: PF_KEY Interface
  • RFC 2412 ↓: The OAKLEY Key Determination Protocol
  • RFC 3706 ↓: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
  • RFC 3715 ↓: IPsec-Network Address Translation (NAT) Compatibility Requirements
  • RFC 4621 ↓: Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
  • RFC 4809 ↓: Requirements for an IPsec Certificate Management Profile
  • RFC 5387 ↓: Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)
  • RFC 5856 ↓: Integration of Robust Header Compression over IPsec Security Associations
  • RFC 5930 ↓: Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol
  • RFC 6027 ↓: IPsec Cluster Problem Statement
  • RFC 6071 ↓: IPsec and IKE Document Roadmap
  • RFC 6379 ↓: Suite B Cryptographic Suites for IPsec
  • RFC 6380 ↓: Suite B Profile for Internet Protocol Security (IPsec)
  • RFC 6467 ↓: Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)

RFC zawierające specyfikację

[edytuj | edytuj kod]
  • RFC 5406 ↓: Guidelines for Specifying the Use of IPsec Version 2

Przestarzałe/Historyczne RFC

[edytuj | edytuj kod]

Zobacz też

[edytuj | edytuj kod]

Przypisy

[edytuj | edytuj kod]
  1. Protocol Numbers [online], IANA, 27 maja 2010 [dostęp 2022-07-13] [zarchiwizowane z adresu 2010-05-29].

Linki zewnętrzne

[edytuj | edytuj kod]