Z Wikipedii

IPsec to zbiór protokołów służących implementacji bezpiecznych połączeń oraz wymiany kluczy kodowych 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 oraz kodowaniem (klucze) oraz kanału (jednego lub więcej), który niesie pakiety transmitowane poprzeć sieć prywatną. Kanał wymiany kluczy jest standardowym połączeniem UDP (port 500). Kanały przesyłu danych oparte są na protokole ESP (numer prot. 50) opisanym w dokumencie RFC 2406.

Spis treści 1 Architektura IPSec 2 Protokół IKE 3 Jednokierunkowość 4 Klucze kryptograficzne 5 Tryb transportowy i tunelowy 6 Linki zewnętrzne

[edytuj] Architektura IPSec

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 enkapsulacji, 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 tragiczny 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.

[edytuj] Protokół IKE

Protokół IKE (Internet Key Exchange) został zaprojektowany w większości przez NSA (National Security Agency) i jest niebywale 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 dogadaniu się 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 całą masę 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 SPI i numer sekwencyjny

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 dwoma 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łu 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 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 ataków przez powtórzenie (replay attacks). Ponieważ numer ten jest wartością 32-bitową, po 2^32 wysłanych pakietów kanał musi być zamknięty, a w jego miejsce stworzony nowy, z licznikiem startującym od zera.

[edytuj] Jednokierunkowość

Kolejną istotną cechą kanałów IPSec jest ich jednokierunkowość - dany kanał obsługuje tylko ruch idący z hosta A do B. Jak więc realizowana jest dwukierunkowa komunikacja? Oczywiście 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 pozostaniemy przy określeniu "kanał"). Każde SA charakteryzuje się przez adresy IP początku i końca oraz SPI.

[edytuj] Klucze kryptograficzne

Jak już wiemy, do pełnej łączności między dwoma hostami potrzebne są dwa kanały IPSec. Jeśli wykorzystamy 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). Podsumowując, 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.

[edytuj] Tryb transportowy i tunelowy

Zarówno ESP jak i AH można stosować w dwóch trybach: transportowym lub tunelowym. Przypomnijmy jak wygląda typowy pakiet IP (załóżmy ż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łuchiwacza. 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...
+-----+-----+===============================

Oczywiście, 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 dwoma 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łuchiwaczowi nie jest znana ani ich treść, ani nawet zastosowana w sieci korporacyjnej adresacja.

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

[edytuj] Linki zewnętrzne

Opis protokołu IPSec w serwisie IPSec.pl