Mechanizmy kryptograficzne w ISAKMP/IKE

Architektura IPSec (IP Security), enkapsuluje całe datagramy protokołu IP, zapewniając ochronę:

  • danych użytkownika
  • informacji protokołów wyższych warstw (TCP, UDP)
  • informacji protokołu IP (adresy od/do)

Dostępne są dwa podprotokoły IPSec:

  • tryb ochrony integralności i autentyczności (Authentication Header), bez ochrony poufności
  • tryb ochrony integralności, autentyczności i poufności (Encapsulation Security Payload)

Te dwa protokoły, AH i ESP, wykorzystują kryptograficzne algorytmy symetryczne (szyfry lub/i funkcje skrótu) z kluczami znanymi obu stronom połączenia. Klucze te są generowane losowo i uzgadniane między stronami za pomocą dodatkowego protokołu Internet Key Exchange (IKE).

PROTOKÓŁ ENCAPSULATION SECURITY PAYLOAD

ESP enkapsuluje dane wyższego poziomu, zapewniając ich poufność za pomocą szyfrowania oraz integralność i autentyczność za pomocą uwierzytelniającej funkcji skrótu (HMAC).

Szyfrowanie danych odbywa się za pomocą szyfru 3DES w trybie CBC (Ciphertext Block Chaining) z losowym wektorem początkowym (IV). Implementacja 3DES składa się z trzech operacji DES: szyfruj-deszyfruj-szyfruj trzema różnymi kluczami, dającymi sumaryczny klucz o długości 192 bitów (efektywnie 168 bitów po odliczeniu bitów parzystości). Wektor początkowy stanowi pierwszy blok wynikowego kryptogramu i jest przesyłany w postaci jawnej.

Protokół ESP posiada częściowe zabezpieczenie przed atakami przez powtórzenie (replay attacks) w postaci numerów sekwencyjnych pakietów (packet sequence number). Numer ten ma rozmiar 32 bitów. Startuje od zera i jest zwiększany o 1 z każdym kolejnym pakietem.

Każdy pakiet ESP posiada przypisaną wartość SPI (Security Parameters Index), która pozwala stronie odbierającej przypisać pakiet do jednego ze znanych sobie sesji IPSec i zastosować do niego przekształcenia kryptograficzne odpowiednie dla tej sesji. Numer ten ma rozmiar 32 bitów i jest generowany losowo dla każdej sesji.

Ochrona integralności jest realizowana przez uwierzytelniającą funkcjęskrótu (HMAC), opisaną niżej. Za jej pomocą wysyłający oblicza wartość ICV (Integrity Check Value) dla pola SPI, numeru sekwencyjnego oraz kryptogramu, a następnie dołączana na końcu pakietu. Strona odbierająca akceptuje wyłącznie pakiety o poprawnej wartości ICV. HMAC wykorzystuje klucz symetryczny znany obu stronom, inny niż ten użyty do szyfrowania danych.

Należy zaznaczyć, że protokół ESP działa wyłącznie w jednej relacji, to jest dane SPI jest przypisane do jednej, unikalnej pary adresów IP węzła źródłowego i docelowego. Pakiety przesyłane w przeciwnym kierunku mają przypisane inny kanał ESP, inne SPI oraz inne klucze kryptograficzne. Zatem pełne, dwukierunkowe połączenie IPSec wykorzystuje w sumie cztery losowe klucze - dwa do szyfrowania i dwa do uwierzytelniania danych.

ALGORYTM HMAC

Algorytm HMAC (Keyed-Hashing for Message Authentication Code) może wykorzystywać dowolną kryptograficzną funkcję skrótu oraz tajny klucz do zapewnienia integralności oraz autentyczności danych przesyłanych między dwoma stronami. Ochrona integralności polega na obliczeniu wartości HMAC dla wysyłanych danych i dołączeniu jej do kryptogramu, a następnie ponownym obliczeniu jej dla odebranych danych po drugiej stronie i porównaniu wyniku.

Ochrona autentyczności opiera się na założeniu, że poprawną wartość HMAC może wygenerować tylko oraz tajny

klucz do zapewnienia integralności oraz autentyczności danych przesyłanych między dwoma stronami. Ochrona integralności polega na obliczeniu wartości HMAC dla wysyłanych danych i dołączeniu jej do kryptogramu, a następnie ponownym obliczeniu jej dla odebranych danych po drugiej stronie i porównaniu wyniku.

Funkcja HMAC polega na wmieszaniu tajnego klucza do wyniku kryptograficznej funkcji skrótu w następujący sposób:

  1. każdy bajt klucza jest sumowany modulo 2 z liczbą 0x36, dając w wyniku ciąg IPAD
  2. każdy bajt klucza jest sumowany modulo 2 z liczbą 0x5c, dając w wyniku ciąg OPAD
  3. obliczany jest skrót H1 dla połączenia IPAD z tekstem jawnym P
  4. obliczany jest skrót H2 dla połączenia OPAD z H1

Wartość H2 stanowi uwierzytelniający skrót wiadomości P.

 

POUFNOŚĆ DOSKONAŁA (PERFECT FORWARD SECRECY)

Pojęcie to jest wykorzystywane w dalszym opisie IKE, stąd konieczność jego zdefiniowania. Przez poufność doskonałą (Perfect Forward Secrecy, PFS) rozumiemy cechę asymetrycznego systemu wymiany klucza (tutaj Diffie-Hellmana), w której uzyskanie przez atakującego jednego klucza pozwala mu na odczytanie tylko i wyłącznie wiadomości zaszyfrowanych tym kluczem.

W szczególności nie jest możliwe, by atakujący odczytał poprzednio przechwycone i zarchiwizowane kryptogramy, ani kryptogramy przechwycone w przyszłości i szyfrowane innym kluczem.

Wynika stąd, że dla zapewnienia poufności doskonałej niedopuszczalne jest by dany klucz sesyjny był podstawą do wytworzenia kolejnego klucza sesyjnego.

 

PROTOKÓŁ INTERNET KEY EXCHANGE

W poniższym opisie dla uproszczenia pominięto protokół AH, zatem wszędzie tam gdzie odwołujemy się do ESP należy czytać "ESP lub AH".

Zadaniem protokołu Internet Key Exchange (IKE) jest:

  1. uwierzytelenieni stron szyfrowanego połączenia i nawiązanie bezpiecznego kanału łączności na potrzeby IKE (nazywanego ISAKMP SA)
  2. ustalenie wspólnego dla uwierzytelnionych stron materiału kluczowego na potrzeby IPSec (nazywanego ESP SA) i cykliczne ustalanie nowego materiału kluczowego

Faza 1 (Phase 1) określana jest przeprowadzana tylko raz, na początku konwersacji IKE pomiędzy komunikującymi się stronami. Linuksowa implementacja IKE FreeS/WAN obsługuje jeden standardowy tryb prowadzenia fazy 1 - "tryb główny" (Main Mode). Rezultatem pomyślnego zakończenia fazy 1 jest ISAKMP SA (bezpieczny kanał łączności dla protokołu IKE) oraz autentyczny materiał kluczowy przeznaczony do wykorzystania w fazie 2.

Podczas fazy 2 (Phase 2) następuje negocjacja parametrów kanałów IPSec oraz powiązanie materiału kluczowego z fazy 1 z konkretnymi kluczami dla ESP (kluczem szyfrującym i chroniącym autentyczność). Jest to realizowanego za pomocą "trybu szybkiego" (Quick Mode).

 

FAZA 1

Podczas fazy 1 strony w pierwszym kroku negocjują następujące podstawowe parametry, składające się na ISAKMP SAL:

  1. algorytm szyfrowania
  2. funkcja skrótu
  3. metoda uwierzytelnienia
  4. grupa MODP na której będzie liczony Diffie-Hellman

Implementacja w systemie Linux udostępnia wyłącznie szyfr 3DES, funkcje skrótu MD5 i SHA1 (w trybach standardowych oraz HMAC) oraz grupy MODP1024 i MODP1536. Dostępne metody uwierzytelnienia to uwierzytelnienie hasłem (shared secret) oraz podpisem RSA (RSA signature).

Następujące kroki zależą od rodzaju uwierzytelnienia. Wykorzystywane będą następujące skróty:

hmac(k, p) - funkcja HMAC na danych p z kluczem k

a | b - ciąg bitów a dołączony do ciągu bitów b

cookie - liczba stanowiąca skrót adresów IP nadawcy, odbiorcy oraz czasu i daty wraz z czynnkiem losowym, stanowiąca ochronę przed powtórzeniami

g^{xy} - wspólny klucz uzyskany w wyniku algorytmu Diffie-Hellmana

g^{xi}, g^{xr} - publiczne czynniki Diffie-Hellmana, odpowiednio strony inicjującej i odbierającej

Tryb główny fazy 1 z uwierzytelenieniem hasłem (shared secret) przebiega następująco:

 

  1. 1. Strona inicjująca wysyła do strony odpowiadającej:
    1. swoją publiczną część Diffie-Hellmana (KE)
    2. liczbę losową (nonce) Ni
    3. liczbę CKY-I (initiator cookie)
  2. Strona odpowiadająca odsyła analogicznie swoje KE, Nr i CKY-R.
  3. Strony obliczają wartości materiału kluczowego:
    SKEYID = hmac(hasło, Ni | Nr)
    SKEYID_d = hmac(SKEYID, g^xy | CKY-I | CKY-R | 0)
    SKEYID_a = hmac(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
    SKEYID_e = hmac(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
  4. Strony rozpoczynają szyfrowanie transmisji ISAKMP SA za pomocą klucza SKEYID_e, uwierzytelniając każdy pakiet skrótem HASH_I (strona inicjująca) lub HASH_R (strona odpowiadająca), gdzie:
    HASH_I = hmac(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi | IDii )
    HASH_R = hmac(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi | IDir )

Wartości SAi, IDii, IDir są polami pakietu IKE oznaczającymi odpowiednio propozycję algorytmów dla uzgadnianego tunelu, identyfikację strony inicjującej oraz identyfikację strony odbierającej.

Tryb główny fazy 1 z uwierzytelenieniem podpisem RSA przebiega analogicznie, z następującymi różnicami:

 

  • wartość SKEYID jest obliczana według innego wzoru:
     SKEYID = hmac(Ni_b | Nr_b, g^xy)
  • wartości HASH_I oraz HASH_R są podpisane kluczem prywatnym RSA nadawcy i weryfikowane przez odbiorcę

 

FAZA 2

Podczas fazy 2 (Phase 2) następuje:

  1. uzgodnienie parametrów ESP (algorytm szyfrujący oraz algorytm ochrony autentyczności)
  2. uzgodnienie materiału kluczowego na potrzeby w/w algorytmów

Linuksowa implementacja IPSec umożliwia negocjację szyfru 3DES oraz jednej z funkcji skrótu MD5 lub SHA1 w trybie HMAC w charakterze algorytmu ochrony autentyczności.

Materiał kluczowy może być uzgodniony na dwa sposoby, w zależności od tego czy jest wymagana poufność doskonała (Perfect Forward Secrecy) czy nie. Jeśli NIE JEST ona wymagana, materiał kluczowy dla ESP jest wyliczany za pomocą HMAC z materiału uzyskanego w fazie 1 w następujący sposób:

 K = hmac(SKEYID_d, prot | SPI | Ni | Nr)

 

Wartości prot i SPI oznaczają odpowiednio numer protokołu oraz SPI dla kanału ESP uzgodnionego podczas fazy 2.

Jeśli poufność doskonała JEST wymagana, strony muszą w fazie drugiej wymienić się dodatkowo nowymi wartościami publicznymi Diffie-Hellmana i uzgodnić nową wspólną wartość za pomocą tego algorytmu. Materiał kluczowy dla ESP jest wtedy obliczany następująco:

 K = hmac(SKEYID_d, g^xy | prot | SPI | Ni | Nr)

Jedynym powodem dla której poufność doskonała nie jest czasami stosowana, jest konieczność przeprowadzenia za każdym razem kosztownej obliczeniowo operacji potęgowania w algorytmi Diffie-Hellmana.

 

OPIS MECHANIZMU GENEROWANIA CIĄGU LOSOWEGO

Ciągi losowe w Linuksie mogą być generowane z co najmniej czterech źródeł:

 

  • układu generacji ciągu losowego Intel 82802
  • fluktuacji w pracy zegarów taktujących procesor oraz płytę główną (demon clrngd)
  • odstępów czasowych pomiędzy znakami przesyłanymi przez port szeregowy
  • odstępów czasowych pomiędzy pakietami odbieranymi przez każdy z interfejsów sieciowych Ethernet

Jądro systemu operacyjnego posiada bufor o wielkości 32 kilobajtów, nazywany "zbiornikiem entropii", który gromadzi i udostępnia usługom systemowym ciągi losowe o wymaganej wielkości.

 

ZASILANIE ZBIORNIKA ENTROPII

Bufor ten podczas startu systemu jest inicjalizowany wartością zapisaną podczas ostatniej operacji "write" wydanej z konsoli administracyjnej lub zapisanej na kluczu USB. Wartość tę stanowi ciąg losowy o długości 4 kilobajtów pobrany ze zbiornika entropii podczas operacji "write". Załadowanie tej wartości pozwala na szybkie przywrócenie nieprzywidywalnego stanu zbiornika entropii tuż po uruchomieniu systemu, kiedy ilość danych otrzymanych ze źródeł fizycznych jest jeszcze niewielka.

Podczas pracy systemu ciągi losowe pochodzące z każdego z wymienionych wyżej źródeł są dodawane do zbiornika entropii przez skrócenie ich za pomocą funkcji "CRC" (zbliżonej do CRC), a następnie dodanie modulo 2 do poprzedniej wartości zbiornika, a następnie przemieszanie go.

Funkcja "CRC" stosowana do dodawania entropii do zbiornika nie jest kryptograficznie silną funkcją skrótu. Celem jej zastosowania jest jak najmniejszy narzut czasowy, wynikający z faktu że jest ona wywoływana m.in. przy każdym przerwaniu karty sieciowej. Równocześnie jednak słabość tej funkcji nie stwarza możliwości takiego wpłynięcia na stan zbiornika entropii, by uzyskać jego przewidywalny stan na wyjściu, jeśli choć jedno ze źródeł dostarcza niezafałszowanych celowo danych losowych. Wykorzystanie dwóch źródeł wewnętrznych oraz minimum dwóch zewnętrznych pozwala osiągnąć wysoką odporność generatora ciągu losowego na zakłócanie pracy systemu różnymi czynnikami.

 

POBIERANIE CIĄGU LOSOWEGO

Pobieranie ciągu losowego odbywa się przez obliczenie skrótu zbiornika entropii za pomocą zmodyfikowanej funkcji SHA1, która podczas kolejnych iteracji dodaje wartości pośrednie z powrotem do zbiornika losowości (za pomocą funkcji "CRC"). Wynik przed zwróceniem klientowi jest dodatkowo mieszany.

Zastosowanie w tym miejscu silnej kryptograficznie funkcji skrótu (SHA1) jest podyktowane koniecznością ochrony poufności stanu zbiornika, a wywołanie tej funkcji w tym miejscu nie jest kosztowne obliczeniowo.

 

UKŁAD INTEL 82802

Układ ten dostarcza do zbiornika losowści ciąg pochodzący ze źródła fizycznego, jakim jest szum termiczny powstający na rezystorach. Szumy dwóch rezystorów są wzmacniane a ich różnica służy do modulowania wolniejszego z dwóch oscylatorów, wbudowanych w układ. Oscylator modulowany szumem próbkuje wynik drugiego, szybkiego oscylatora. Wynik jest źródłem ciągu cyfr binarnych.

Ciąg ten podlega dalszemu przetwarzaniu za pomocą kompensatora von Neumanna, który wyrównuje dystrybucję zer i jedynek. Kompensator działa w ten sposób, że dla każdych następujących po sobie różnych bitów zwraca 1 lub 0 (w zależności od kolejności), dla dwóch takich samych bitów ciągu nie zwraca nic.

Ciąg bitów generowany przez układ Intela jest pobierany przez oprogramowanie w blokach po 2500 bajtów. Po wypełnieniu takiego bloku przeprowadzany jest na nim test statystyczny FIPS 140-1 i po jego spełnieniu blok jest dodawany do zbiornika losowości.

 

Bibliografia

  1. RSA Laboratories ,,PKCS #5 - Password-Based Cryptography Standard'' http://www.rsasecurity.com/rsalabs/pkcs/pkcs-5/
  2. IETF ,,Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers'', rozdział 1.1 ftp://ftp.icm.edu.pl/pub/doc/rfc/rfc1423.txt
  3. IETF ,,Keyed-Hashing for Message Authentication'' ftp://ftp.icm.edu.pl/pub/doc/rfc/rfc2104.txt

 

$Id: kryptografia.txt,v 1.1 2002/09/26 17:01:38 kravietz Exp $