IPSec (IP Security)

IPSec jest zbiorem protokołów i metod podwyższania bezpieczeństwa w sieciach TCP/IP, kształtowanym przez IETF od 1992 r. W efekcie IPSec może przeprowadzać autoryzację nadawcy, sprawdzać integralność danych, zapewniać poufność transmisji i sterować dostępem w sieciach z IPv4 (opcjonalnie) oraz IPv6 (obowiązkowo). Tworzenie wirtualnych sieci prywatnych na podstawie tego protokołu jest prawie standardem.

Ale IPSec Working Group IETF zdefiniowała w istocie otwartą architekturę i otwartą strukturę, znaną jako IPSec. Nazwa struktura bierze się stąd, że pomaga utworzyć stabilną bazę zapewniającą bezpieczeństwo w warstwach sieciowych. Ma wydajne algorytmy szyfrowania oraz identyfikacji. IPSec ma dwa tryby szyfrowania: tunelowy i transportowy. W pierwszym z nich szyfruje się nagłówek i ładunek każdego z pakietów, natomiast w drugim tylko ładunek. Wszystkie urządzenia muszą używać wspólnego klucza, a zapory ogniowe muszą mieć ustanowione podobne polityki bezpieczeństwa. IPSec może szyfrować dane między różnymi urządzeniami, takimi jak dwa rutery, ruter i zapora ogniowa czy komputer osobisty i ruter. Obowiązkowym algorytmem szyfrowania jest DES (Data Encryption Standard) w trybie CBC (wektor inicjujący IV). Do alternatywnych algorytmów szyfrujących należą: 3DES, CAST-128 (RFC 2144), RC5 (RFC 2040), IDEA, Blowfish i ARCFour.

Wspomniana grupa robocza skoncentrowała się na zdefiniowaniu protokołów odnoszących się do kilku płaszczyzn. Przede wszystkim na identyfikacji oryginalności danych, czyli weryfikowaniu, czy każdy pakiet pochodzi od przypisanego nadawcy. Drugą ważną kwestią jest integralność danych. W tym przypadku weryfikuje się zawartość pakietu, tzn.: czy nie był on zmieniony podczas przesyłania. Natomiast poufność danych ukrywa właściwy tekst wiadomości, zazwyczaj przy użyciu szyfrowania.

Kolejnym problemem jest automatyczne zarządzanie kluczami kryptograficznymi i SA (Security Association). SA to w wolnym tłumaczeniu związek zabezpieczeń, czyli relacja między dwoma (lub więcej) komputerami w sieci Internet, określająca sposób korzystania z usług ochrony podczas sesji komunikacyjnej. System IPSec został więc oparty na koncepcji SA – wspomnianych powiązań zabezpieczeń, nazywanych też skojarzeniami zabezpieczeń. Takie powiązanie SA jest z definicji zbiorem informacji bezpieczeństwa odnoszących się do jednokierunkowego połączenia sieciowego lub czasem do zbioru połączeń. Do zidentyfikowania SA służą jednocześnie: specjalny indeks SPI (Security Parameters Index) i adres docelowy. SPI jest 32-bitową liczbą wybieraną losowo albo wymyślaną przez administratora podczas ręcznego konfigurowania połączenia. Wspieranie SA przez protokoły AH i ESP jest obowiązkowe: za SPI kryje się w istocie wiele bardzo ważnych parametrów, jak na przykład algorytmy uwierzytelnienia i szyfrowania, wymiana kluczy, klucze sesji, czas ważności kluczy, czas życia SA, identyfikator poziomu bezpieczeństwa czy kolejność protokołów. Dane SA są gromadzone w systemowej bazie SAD (SA Database). Jest ona podrzędna w stosunku do bazy polityki bezpieczeństwa – SPD (Security Policy Database). Przed transmisją danych z jednego węzła do drugiego musi być zestawione bezpieczne połączenie. Połączenie IPSec, jak wspomniano, jest zdefiniowane przez SA. Połączenia są zawsze jednokierunkowe, dlatego na potrzeby transmisji dwukierunkowej zestawia się przynajmniej dwa połączenia.

W odniesieniu do modelu OSI IPSec funkcjonuje w warstwie sieciowej oraz aplikacyjnej i ma strukturę modularną, niezależną od stosowanych algorytmów bezpieczeństwa. Z kolei w odniesieniu do IP jest protokołem podrzędnym. Architektura bezpieczeństwa Internetu w postaci zbliżonej do dzisiejszego IPSec została opisana w RFC 1825; nazwa IPSec jeszcze wtedy nie występowała. Dwa kolejne RFC opisywały zmiany wprowadzone do protokołów AH (RFC 1926, zastąpiony przez RFC 2402) i ESP (RFC 1827, zastąpiony przez 2406) używanych przez IPSec.

IPSec opiera się na trzech protokołach:

• AH (Authentication Header), który zapewnia zarówno identyfikację oryginalności danych, jak i ich integralności,
• ESP (Encapsulating Security Payload), dostarczający poufności danych, identyfikację oryginalności danych, integralności i replay protection,
• ISAKMP (Internet Security Association and Key Management Protocol), który dostarcza metody automatycznego ustawiania SA i zarządzania ich kluczami kryptograficznymi. Dzięki temu IPSec funkcjonuje także w warstwie aplikacyjnej.

W warstwowym modelu komunikacyjnym warstwa sieciowa jest najniższą, która może dostarczyć bezpieczeństwa typu end-to-end. Protokoły bezpieczeństwa warstwy sieciowej dają całościową ochronę dla wszystkich danych aplikacyjnych pochodzących z warstw wyższych, a przesyłanych w ładunku pakietu IP, nie wymagając od użytkownika modyfikowania aplikacji.

AH

AH zapewnia uwierzytelnienie integralności i pochodzenia danych. Integralność danych jest zapewniona poprzez sumę kontrolną generowaną przez kod identyfikacyjny wiadomości, np. MD5. Natomiast sprawdzenie oryginalności danych dokonuje się poprzez zamieszczenie sekretnego, współdzielonego klucza w danych przeznaczonych do identyfikowania. Ochronę typu Replay protection zapewnia się za pośrednictwem pola numeru sekwencyjnego zawartego w nagłówku AH.

Algorytmy użyte przez protokół AH są znane jako HMAC (Hashed Message Authentication Code). Proces HMAC (Keyed-Hashing for Message Authentication Code) jest zdefiniowany w RFC 2104. AH chroni całą zawartość pakietu IP z wyjątkiem niektórych pól w nagłówku IP.

AH może być aplikowany w trybie

• tunelowym,
• transportowym.

W trybie transportowym oryginalny nagłówek pakietu IP jest najbardziej na zewnątrz nagłówka IP; w trybie tunelowym generowany zostaje nowy nagłówek IP, aby używać go jako zewnętrznego nagłówka IP powstałego pakietu. Adresy źródła i przeznaczenia nowego nagłówka różnią się od użytych w oryginalnym nagłówku. Całość pakietu, tzn. nowy nagłówek IP, nagłówek AH, nagłówek IP i ładunek (payload), jest chroniona przez protokół AH. AH może być stosowany samodzielnie lub w połączeniu z ESP. W takiej kombinacji identyfikacja może być zapewniona między parą komputerów, zapór ogniowych lub między komputerem a zaporą.

ESP

ESP zapewnia poufność danych dzięki szyfrowaniu. Może także opcjonalnie zapewnić uwierzytelnienie pochodzenia danych, sprawdzanie integralności i replay protection. Porównując ESP do AH widać, że tylko ten pierwszy dostarcza szyfrowania, natomiast oba zapewniają identyfikację, sprawdzenie integralności i replay protection. Szyfrowanie ESP stosuje współdzielony klucz symetryczny, tzn. klucz współużytkowany przy szyfrowaniu i deszyfrowaniu danych. Kiedy używa się funkcji identyfikujących ESP, wtedy stosuje się te same algorytmy HMAC, czyli HMAC-MD5 lub HMAC-SHA, jak w przypadku protokołu AH. Jednak w trochę inny sposób.

W trybie transportowym ESP chroni tylko oryginalny ładunek IP, natomiast nie ochrania oryginalnego nagłówka IP. W trybie transportowym AH chroni zarówno oryginalny nagłówek IP, jak i oryginalny ładunek IP. W trybie tunelowym, ESP chroni oryginalny nagłówek IP i ładunek IP, ale nie nowy nagłówek IP. W tym trybie AH chroni wszystkie trzy. ESP może być stosowany w obu trybach. W trybie transportowym oryginalny nagłówek pakietu IP jest zachowywany. Jedynie nagłówek oryginalnego pakietu IP i ESP Trailer są szyfrowane. Trzeba tu przypomnieć, że sam nagłówek IP nie podlega uwierzytelnianiu ani szyfrowaniu. W ten sposób informacja dotycząca adresowania z wierzchu nagłówka jest widziana przez ewentualnego intruza w chwili transportu pakietu. W trybie tunelowym generuje się nowy nagłówek IP. Cały oryginalny pakiet, tzn. zarówno nagłówek, jak i ładunek, oraz ESP Trailer są szyfrowane. Ponieważ oryginalny nagłówek jest zaszyfrowany, jego zawartość nie jest widziana przez osoby nastawione na atak. Najczęstszym powodem użycia trybu tunelowego ESP jest ukrycie informacji adresowych, gdy datagram jest tunelowany między dwiema zaporami ogniowymi.

Tryb transportowy jest zazwyczaj używany między punktami końcowymi połączenia. Przykładowo, jeżeli w ścieżce komunikacyjnej wzdłuż wszystkich elementów pomiędzy serwerem, a klientem wymaga się bezpiecznej komunikacji, to klient i serwer użyją trybu transportowego IPSec.

Natomiast tryb tunelowy stosuje się między dwoma urządzeniami w sytuacji, kiedy przynajmniej jedno z nich nie jest punktem końcowym połączenia. Na przykład kiedy wymaga się bezpiecznego połączenia między dwoma zaporami ogniowymi ulokowanymi między klientem, a serwerem, to obydwie zapory ogniowe w komunikacji między sobą użyją trybu tunelowego IPSec.

ISAKMP/Oakley SA

ISAKMP/Oakley SA (Security Association) zawiera wszystkie ważne informacje, których system komunikacyjny potrzebuje, aby wykonać protokoły IPSec, takie jak AH lub ESP. ISAKMP definiuje standardową strukturę negocjowania SA, inicjującego generowanie wszystkich kluczy kryptograficznych i późniejszego odświeżania tych kluczy. Oakley jest obowiązkowym protokołem zarządzania kluczem używanym w strukturze ISAKMP. Protokół ISAKMP wspiera zautomatyzowane negocjowanie SA oraz automatyczne generowanie i odświeżanie kluczy kryptograficznych. Zdolność do wykonania tych funkcji z niewielką lub nawet żadną ręczną konfiguracją urządzeń jest krytycznym elementem, od którego zależy zwiększenie rozmiaru VPN. Bezpieczna wymiana kluczy jest najważniejszym czynnikiem przy ustanawianiu zabezpieczonej komunikacji – bez względu na to, jak silne są zastosowane metody identyfikowania i szyfrowania, to okażą się one bezwartościowe, kiedy klucz będzie narażony na atak.

ISAKMP wymaga, żeby wszystkie wymiany informacji podlegały weryfikowaniu i szyfrowaniu. Dodatkowo metody ISAKMP zostały opracowane z myślą o przeciwdziałaniu następującym, dobrze znanym przypadkom:

• Odmowa usług (Denial of Service) – wiadomości są konstruowane z jednym (jedynym) cookies, który może być użyty do szybkiego identyfikowania i odrzucania nieważnych wiadomości bez potrzeby uruchamiania pochłaniających moc obliczeniową procesora operacji szyfrujących;
• Man-in-the-Middle – ochrona jest prowadzona przeciw pospolitym atakom typu: usuwanie wiadomości, modyfikowanie wiadomości, odbijanie wiadomości z powrotem do nadawcy, powtórzenie starych wiadomości i skierowanie wiadomości do przypadkowego odbiorcy.

Ręczne konfigurowanie połączeń SA i ustawianie kluczy jest ograniczane rozmiarami sieci. Powyżej pewnej liczby węzłów praktycznie żadna konfiguracja nie jest optymalna. W topologii każdy z każdym taka liczba jest nawet niższa od 10. Dlatego automatyczne negocjowanie parametrów bezpieczeństwa IPSec jest tak ważną zaletą. Uwierzytelnianiem komputerów z obydwu końców połączenia IPSec i wymianą kluczy kryptograficznych na potrzeby różnych SA może sterować protokół IKE (Internet Key Exchange), składający się z dwu części: wspomnianych ISAKMP (Internet Security Association and Key Management Protocol) i Oakley. Dominującym protokołem jest ISAKMP zarządzający sesją. Z kolei Oakley jest kryptograficznym protokołem wymiany kluczy, wykorzystującym algorytm Diffie-Hellmana; Oakley jest ulubioną przez autora protokołu postacią z „dzikiego zachodu”. Obydwa protokoły powstały niezależnie, ale zostały połączone w IKE na potrzeby IPSec.

IKE ustala tożsamość węzłów z obydwu końców połączenia, po czym tworzy chronione połączenie ISAKMP SA, przez które będą negocjowane parametry niezbędne dla IPSec. Połączenie ISAKMP SA pozostanie do końca sesji. Kiedy węzły wymienią klucze i ustalą algorytmy szyfrowania oraz inne parametry (zależne od polityki bezpieczeństwa), powstanie połączenie IPSec SA, przez które będzie można przesyłać zaszyfrowane i uwierzytelnione pakiety.

MD5

MD5 (Message Digest 5) – algorytm skrótu wiadomości, zbliżony do SHA, opisany w RFC 1321 i 2403. MD5 nie ogranicza długości wiadomości, niemniej jednak musi być ona dopełniona bitowo do 448 modulo 512. Dopełniona wiadomość jest następnie dzielona na 512-bitowe bloki, które po wielokrotnym przetwarzaniu przez specjalny moduł dają wynik końcowy – skrót wiadomości – w postaci ciągu zawsze o długości 128 bitów. Skrót jest następnie dołączany do wiadomości, podwyższając jej bezpieczeństwo. Algorytm ten, nazywany jednokierunkową funkcją skrótu, jest używany w PEM i PGP. Inne MD, jak 2 i 4, zostały złamane kryptoanalitycznie i nie są już stosowane. IPSec został opisany w RFC 2401–2411, 2451 i 2709.