IPsec — IPsec

Pakiet protokołów internetowych
Warstwa aplikacji
Warstwa transportowa
Warstwa internetowa
Warstwa łącza

W computing , Internet Protocol Security ( IPsec ) jest bezpieczna sieć protokół apartament , który uwierzytelnia i szyfruje te pakiety danych, aby zapewnić bezpieczną, szyfrowaną komunikację pomiędzy dwoma komputerami nad Internet Protocol sieci. Jest używany w wirtualnych sieciach prywatnych (VPN).

Protokół IPsec zawiera protokoły do ​​ustanawiania wzajemnego uwierzytelniania między agentami na początku sesji i negocjowania kluczy kryptograficznych używanych podczas sesji. Protokół IPsec może chronić przepływy danych między parą hostów ( host-host ), między parą bram zabezpieczeń ( sieć do sieci ) lub między bramą zabezpieczeń a hostem ( sieć do hosta ). Protokół IPsec korzysta z usług zabezpieczeń kryptograficznych w celu ochrony komunikacji w sieciach protokołu internetowego (IP). Obsługuje uwierzytelnianie równorzędne na poziomie sieci, uwierzytelnianie pochodzenia danych, integralność danych, poufność danych (szyfrowanie) i ochronę odtwarzania.

Pierwotny pakiet IPv4 został opracowany z kilkoma zabezpieczeniami. Jako część ulepszenia IPv4, IPsec jest modelem OSI warstwy 3 lub kompleksowym schematem zabezpieczeń warstwy internetowej . W przeciwieństwie do tego, podczas gdy niektóre inne powszechnie stosowane systemy zabezpieczeń internetowych działają powyżej warstwy 3, takie jak Transport Layer Security (TLS), który działa powyżej warstwy Transport Layer i Secure Shell (SSH), która działa w warstwie aplikacji, IPsec może automatycznie zabezpieczać aplikacje w warstwa IP.

Historia

Począwszy od wczesnych lat 70. Agencja Zaawansowanych Projektów Badawczych sponsorowała serię eksperymentalnych urządzeń szyfrujących ARPANET , początkowo do natywnego szyfrowania pakietów ARPANET, a następnie do szyfrowania pakietów TCP/IP; niektóre z nich zostały certyfikowane i wystawione. W latach 1986-1991 NSA sponsorowała rozwój protokołów bezpieczeństwa dla Internetu w ramach swojego programu Secure Data Network Systems (SDNS). To zgromadziło różnych dostawców, w tym Motorolę, która wyprodukowała sieciowe urządzenie szyfrujące w 1988 roku. Praca była otwarcie publikowana od około 1988 roku przez NIST, a spośród nich protokół bezpieczeństwa w warstwie 3 (SP3) ostatecznie przekształcił się w standard ISO Network Layer Security Protocol (NLSP).

W latach 1992-1995 różne grupy prowadziły badania nad szyfrowaniem w warstwie IP.

  • 1. W 1992 roku US Naval Research Laboratory (NRL) rozpoczęło projekt Simple Internet Protocol Plus (SIPP) w celu zbadania i wdrożenia szyfrowania IP.
  • 2. W 1993 roku, na Uniwersytecie Columbia i AT&T Bell Labs , John Ioannidis i inni badali eksperymentalne oprogramowanie Software IP Encryption Protocol (swIPe) na SunOS .
  • 3. W 1993 roku, sponsorowany przez projekt usług internetowych Whitehouse, Wei Xu z Trusted Information Systems (TIS) dalej badał protokoły bezpieczeństwa IP oprogramowania i opracował obsługę sprzętową dla potrójnego standardu szyfrowania danych DES , który został zakodowany w jądrze BSD 4.1 i obsługiwane zarówno architektury x86, jak i SUNOS. Do grudnia 1994 roku firma TIS wypuściła sponsorowany przez DARPA produkt Gauntlet Firewall o otwartym kodzie źródłowym ze zintegrowanym szyfrowaniem sprzętowym 3DES z szybkością przekraczającą T1 . Po raz pierwszy zastosowano połączenia IPSec VPN między wschodnim i zachodnim wybrzeżem Stanów Zjednoczonych, znane jako pierwszy komercyjny produkt IPSec VPN.
  • 4. W ramach wysiłków badawczych finansowanych przez NRL DARPA , NRL opracowało specyfikacje ścieżek standardów IETF (RFC 1825 do RFC 1827) dla IPsec, które zostały zakodowane w jądrze BSD 4.4 i wspierały architekturę procesorów x86 i SPARC. Implementacja IPsec w NRL została opisana w ich artykule w materiałach konferencyjnych USENIX z 1996 roku. Implementacja protokołu IPsec o otwartym kodzie źródłowym NRL została udostępniona online przez MIT i stała się podstawą większości początkowych wdrożeń komercyjnych.

Internet Engineering Task Force (IETF) utworzyła Grupę Roboczą zabezpieczeń IP w 1992 roku w celu ujednolicenia jawnie podane rozszerzenia zabezpieczeń na IP, zwane IPsec . W 1995 roku grupa robocza zorganizowała kilka warsztatów z udziałem członków z pięciu firm (TIS, CISCO, FTP, Checkpoint, itp.). Podczas warsztatów IPSec standardy NRL oraz oprogramowanie Cisco i TIS są standaryzowane jako źródła publiczne, publikowane jako RFC-1825 do RFC-1827.

Architektura bezpieczeństwa

IPsec to otwarty standard w ramach pakietu IPv4. IPsec używa następujących protokołów do wykonywania różnych funkcji:

Nagłówek uwierzytelniania

Wykorzystanie formatu nagłówka uwierzytelniania IPsec w trybach tunelowania i transportu

Nagłówek uwierzytelniania zabezpieczeń ( AH ) został opracowany w Laboratorium Badawczym Marynarki Wojennej Stanów Zjednoczonych na początku lat 90. XX wieku i wywodzi się częściowo z prac poprzednich standardów IETF dotyczących uwierzytelniania protokołu Simple Network Management Protocol (SNMP) w wersji 2. Nagłówek uwierzytelniania (AH) jest członek pakietu protokołów IPsec. AH zapewnia bezpołączeniową integralność za pomocą funkcji skrótu i tajnego klucza współdzielonego w algorytmie AH. AH gwarantuje również pochodzenie danych poprzez uwierzytelnianie pakietów IP . Opcjonalnie numer sekwencyjny może chronić zawartość pakietu IPsec przed atakami typu powtórka , wykorzystując technikę przesuwanego okna i odrzucając stare pakiety.

  • W IPv4 AH zapobiega atakom polegającym na wstawianiu opcji. W IPv6 AH chroni zarówno przed atakami wstawiania nagłówka, jak i atakami wstawiania opcji.
  • W IPv4 AH chroni ładunek IP i wszystkie pola nagłówka datagramu IP z wyjątkiem pól zmiennych (tj. tych, które mogą być zmieniane podczas przesyłania), a także opcji IP, takich jak opcja bezpieczeństwa IP (RFC 1108). Zmienne (a zatem nieuwierzytelnione) pola nagłówka IPv4 to DSCP / ToS , ECN , Flags , Fragment Offset , TTL i Header Checksum .
  • W IPv6 AH chroni większość nagłówka podstawowego IPv6, sam AH, niezmienne nagłówki rozszerzenia po AH i ładunek IP. Ochrona nagłówka IPv6 wyklucza zmienne pola: DSCP , ECN , Flow Label i Hop Limit.

AH działa bezpośrednio na IP, korzystając z protokołu IP o numerze 51 .

Poniższy diagram pakietów AH pokazuje, jak konstruowany i interpretowany jest pakiet AH:

Format nagłówka uwierzytelniania
Przesunięcia Oktet 16 0 1 2 3
Oktet 16 Bit 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Następny nagłówek Ładowność Len Skryty
4 32 Indeks parametrów bezpieczeństwa (SPI)
8 64 Numer sekwencji
C 96 Wartość kontroli integralności (ICV)
...
... ...
Następny nagłówek (8 bitów)
Typ następnego nagłówka, wskazujący, jaki protokół wyższej warstwy był chroniony. Wartość jest pobierana z listy numerów protokołów IP .
Ładowność Len (8 bitów)
Długość tego nagłówka uwierzytelniania w jednostkach 4-oktetowych, minus 2. Na przykład wartość AH równa 4 równa się 3 x (32-bitowe pola AH o stałej długości) + 3 x (32-bitowe pola ICV) - 2, a zatem wartość AH 4 oznacza 24 oktety. Chociaż rozmiar jest mierzony w jednostkach 4-oktetowych, długość tego nagłówka musi być wielokrotnością 8 oktetów, jeśli jest przenoszony w pakiecie IPv6. To ograniczenie nie dotyczy nagłówka uwierzytelniania przenoszonego w pakiecie IPv4.
Zarezerwowane (16 bitów)
Zarezerwowane do wykorzystania w przyszłości (do tego czasu wszystkie zera).
Indeks parametrów bezpieczeństwa (32 bity)
Dowolna wartość, która jest używana (wraz z docelowym adresem IP) do identyfikacji powiązania bezpieczeństwa strony odbierającej.
Numer sekwencyjny (32 bity)
Monotoniczny ściśle rosnąca liczba sekwencji (zwiększany o 1 dla każdej wysłanych pakietów), w celu zapobiegania atakom przez powtórzenie . Gdy wykrywanie powtórek jest włączone, numery sekwencyjne nigdy nie są ponownie używane, ponieważ nowe skojarzenie zabezpieczeń musi zostać ponownie wynegocjowane przed próbą zwiększenia numeru sekwencyjnego poza jego maksymalną wartość.
Wartość sprawdzania integralności (wiele 32 bitów)
Wartość kontrolna zmiennej długości. Może zawierać dopełnienie, aby wyrównać pole do granicy 8-oktetowej w przypadku IPv6 lub do 4-oktetowej granicy w przypadku IPv4 .

Hermetyzacja ładunku zabezpieczającego

Wykorzystanie IPsec Encapsulating Security Payload (ESP) w trybach tunelowania i transportu

IP Encapsulating Security Payload (ESP) został opracowany w Naval Research Laboratory w 1992 roku jako część projektu badawczego sponsorowanego przez DARPA i został otwarcie opublikowany przez grupę roboczą IETF SIPP, zredagowaną w grudniu 1993 roku jako rozszerzenie bezpieczeństwa dla SIPP. Ten ESP został pierwotnie wyprowadzony z protokołu SP3D Departamentu Obrony USA , a nie z protokołu ISO Network-Layer Security Protocol (NLSP). Specyfikacja protokołu SP3D została opublikowana przez NIST pod koniec lat 80., ale została zaprojektowana przez projekt Secure Data Network System Departamentu Obrony USA. Encapsulating Security Payload (ESP) jest członkiem pakietu protokołów IPsec. Zapewnia pochodzenia autentyczności przez źródło uwierzytelniania , integralności danych za pomocą funkcji skrótu i poufności poprzez szyfrowanie ochrony IP pakietów . ESP obsługuje również konfiguracje tylko do szyfrowania i tylko do uwierzytelniania , ale korzystanie z szyfrowania bez uwierzytelniania jest zdecydowanie odradzane, ponieważ jest to niebezpieczne.

W przeciwieństwie do nagłówka uwierzytelniania (AH) , ESP w trybie transportu nie zapewnia integralności i uwierzytelniania dla całego pakietu IP . Jednak w trybie tunelowym , w którym cały oryginalny pakiet IP jest hermetyzowany z dodanym nowym nagłówkiem pakietu, ochrona ESP jest zapewniona całemu wewnętrznemu pakietowi IP (w tym nagłówkowi wewnętrznemu), podczas gdy zewnętrzny nagłówek (w tym wszelkie zewnętrzne opcje IPv4 lub rozszerzenie IPv6 nagłówki) pozostają niezabezpieczone. ESP działa bezpośrednio na IP, używając protokołu IP o numerze 50.

Poniższy diagram pakietów ESP pokazuje, w jaki sposób pakiet ESP jest konstruowany i interpretowany:

Format hermetyzacji ładunku zabezpieczającego
Przesunięcia Oktet 16 0 1 2 3
Oktet 16 Bit 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Indeks parametrów bezpieczeństwa (SPI)
4 32 Numer sekwencji
8 64 Dane ładunku
... ...
... ...    
... ...   Dopełnienie (0-255 oktetów)  
... ...   Długość podkładki Następny nagłówek
... ... Wartość kontroli integralności (ICV)
...
... ...
Indeks parametrów bezpieczeństwa (32 bity)
Dowolna wartość używana (wraz z docelowym adresem IP) do identyfikacji powiązania bezpieczeństwa strony odbierającej.
Numer sekwencyjny (32 bity)
Monotonicznie rosnąca liczba sekwencji (zwiększany o 1 dla każdej wysłanych pakietów), w celu ochrony przed atakom przez powtórzenie . Dla każdego stowarzyszenia bezpieczeństwa prowadzony jest oddzielny licznik.
Dane ładunku (zmienne)
Chroniona zawartość oryginalnego pakietu IP, w tym wszelkie dane używane do ochrony zawartości (np. wektor inicjalizacji algorytmu kryptograficznego). Typ chronionej treści jest wskazywany przez pole Następny nagłówek .
Dopełnienie (0-255 oktetów)
Dopełnienie szyfrowania w celu rozszerzenia danych ładunku do rozmiaru zgodnego z rozmiarem bloku szyfrowania i wyrównania następnego pola.
Długość padu (8 bitów)
Rozmiar dopełnienia (w oktetach).
Następny nagłówek (8 bitów)
Typ następnego nagłówka. Wartość jest pobierana z listy numerów protokołów IP .
Wartość sprawdzania integralności (wiele 32 bitów)
Wartość kontrolna zmiennej długości. Może zawierać dopełnienie, aby wyrównać pole do granicy 8-oktetowej w przypadku IPv6 lub do 4-oktetowej granicy w przypadku IPv4 .

Stowarzyszenie bezpieczeństwa

Główny artykuł: stowarzyszenie bezpieczeństwa

Protokoły IPsec używają powiązania bezpieczeństwa , w którym strony komunikujące się ustalają wspólne atrybuty bezpieczeństwa, takie jak algorytmy i klucze. W związku z tym IPsec zapewnia szereg opcji po ustaleniu, czy używany jest protokół AH, czy ESP. Przed wymianą danych dwa hosty uzgadniają, który algorytm jest używany do szyfrowania pakietu IP, na przykład DES lub IDEA , oraz która funkcja skrótu służy do zapewnienia integralności danych, na przykład MD5 lub SHA . Parametry te są uzgadniane dla konkretnej sesji, dla której należy ustalić czas życia oraz klucz sesji .

Algorytm uwierzytelniania jest również uzgadniany przed transferem danych, a IPsec obsługuje szereg metod. Uwierzytelnianie jest możliwe za pomocą klucza wstępnego , w którym klucz symetryczny jest już w posiadaniu obu hostów, a hosty wysyłają sobie nawzajem skróty klucza współdzielonego, aby udowodnić, że są w posiadaniu tego samego klucza. IPsec obsługuje również szyfrowanie kluczem publicznym , gdzie każdy host ma klucz publiczny i prywatny, wymieniają się swoimi kluczami publicznymi, a każdy host wysyła drugiemu jednorazowo zaszyfrowany klucz publiczny drugiego hosta. Alternatywnie, jeśli oba hosty posiadają certyfikat klucza publicznego z urzędu certyfikacji , można go użyć do uwierzytelniania IPsec.

Powiązania bezpieczeństwa protokołu IPsec są ustanawiane przy użyciu protokołu ISAKMP ( Internet Security Association and Key Management Protocol ). ISAKMP jest implementowany przez ręczną konfigurację ze wstępnie udostępnionymi hasłami , wymianę kluczy internetowych (IKE i IKEv2), kerberyzowaną negocjację kluczy internetowych (KINK) oraz użycie rekordów DNS IPSECKEY . RFC 5386 definiuje zabezpieczenia Better-Than-Nothing (BTNS) jako nieuwierzytelniony tryb IPsec przy użyciu rozszerzonego protokołu IKE. C. Meadows, C. Cremers i inni wykorzystali metody formalne do identyfikacji różnych anomalii występujących w IKEv1, a także w IKEv2.

Aby zdecydować, jaka ochrona ma być zapewniona dla pakietu wychodzącego, IPsec używa indeksu parametrów bezpieczeństwa (SPI), indeksu do bazy danych skojarzeń bezpieczeństwa (SADB), wraz z adresem docelowym w nagłówku pakietu, który razem jednoznacznie identyfikuje powiązanie bezpieczeństwa dla tego pakietu. Podobna procedura jest wykonywana dla pakietu przychodzącego, w którym protokół IPsec zbiera klucze odszyfrowywania i weryfikacji z bazy danych skojarzeń zabezpieczeń.

W przypadku multiemisji IP dla grupy zapewnione jest powiązanie bezpieczeństwa, które jest duplikowane we wszystkich autoryzowanych odbiornikach grupy. Dla grupy może istnieć więcej niż jedno skojarzenie zabezpieczeń, korzystające z różnych SPI, co pozwala na wiele poziomów i zestawów zabezpieczeń w grupie. Rzeczywiście, każdy nadawca może mieć wiele skojarzeń bezpieczeństwa, umożliwiających uwierzytelnianie, ponieważ odbiorca może wiedzieć tylko, że ktoś znający klucze wysłał dane. Należy zauważyć, że odpowiedni standard nie opisuje, w jaki sposób wybiera się i powiela powiązanie w całej grupie; zakłada się, że wyboru dokonała strona odpowiedzialna.

Tryby działania

Protokoły IPsec AH i ESP mogą być zaimplementowane w trybie transportu host-host, a także w trybie tunelowania sieciowego.

Tryby IPsec

Tryb transportu

W trybie transportu tylko ładunek pakietu IP jest zwykle szyfrowany lub uwierzytelniany. Routing jest nienaruszony, ponieważ nagłówek IP nie jest ani modyfikowany, ani szyfrowany; jednak gdy używany jest nagłówek uwierzytelniania , adresy IP nie mogą być modyfikowane przez translację adresów sieciowych , ponieważ zawsze unieważnia to wartość skrótu . Do transportu i nanoszenia warstwy są zawsze zabezpieczone przez hash, więc nie mogą być modyfikowane w jakikolwiek sposób, na przykład poprzez tłumaczenia z portów liczb.

Sposób enkapsulacji wiadomości IPsec dla przechodzenia NAT został zdefiniowany w dokumentach RFC opisujących mechanizm NAT-T .

Tryb tunelowy

Główny artykuł: Protokół tunelowania

W trybie tunelowym cały pakiet IP jest szyfrowany i uwierzytelniany. Następnie jest enkapsulowany w nowy pakiet IP z nowym nagłówkiem IP. Tryb tunelowy jest używany do tworzenia wirtualnych sieci prywatnych do komunikacji międzysieciowej (np. między routerami a witrynami łączy), komunikacji między hostami (np. zdalny dostęp użytkownika) oraz między hostami (np. prywatny czat).

Tryb tunelowy obsługuje przechodzenie przez NAT.

Algorytmy

Algorytmy szyfrowania symetrycznego

Algorytmy kryptograficzne zdefiniowane do użytku z protokołem IPsec obejmują:

Szczegółowe informacje można znaleźć w dokumencie RFC 8221.

Algorytmy wymiany kluczy

Algorytmy uwierzytelniania

Realizacje

Protokół IPsec można zaimplementować w stosie IP systemu operacyjnego , co wymaga modyfikacji kodu źródłowego. Ta metoda implementacji jest wykonywana dla hostów i bram bezpieczeństwa. Firmy, takie jak HP czy IBM, oferują różne stosy IP z obsługą protokołu IPsec. Alternatywą jest implementacja tzw. bump-in-the-stack (BITS), w której kod źródłowy systemu operacyjnego nie musi być modyfikowany. Tutaj IPsec jest instalowany pomiędzy stosem IP a sterownikami sieciowymi . W ten sposób systemy operacyjne można wyposażyć w IPsec. Ta metoda implementacji jest również stosowana zarówno w przypadku hostów, jak i bram. Jednak podczas modernizacji protokołu IPsec enkapsulacja pakietów IP może powodować problemy z automatycznym wykrywaniem MTU ścieżki , w przypadku którego ustalany jest maksymalny rozmiar jednostki transmisji (MTU) na ścieżce sieciowej między dwoma hostami IP. Jeśli host lub brama ma osobny kryptoprocesorem , co jest powszechne w wojsku i można również znaleźć w systemach handlowych, tzw gula-in-the-wire (BITW) realizacja IPsec jest możliwe.

Gdy protokół IPsec jest zaimplementowany w jądrze , zarządzanie kluczami i negocjacja ISAKMP / IKE odbywa się z przestrzeni użytkownika. Opracowany przez NRL i otwarcie określony „PF_KEY Key Management API, Version 2” jest często używany do umożliwienia aplikacji zarządzania kluczami w obszarze aplikacji aktualizacji powiązań zabezpieczeń IPsec przechowywanych w ramach implementacji protokołu IPsec w obszarze jądra. Istniejące implementacje IPsec zwykle obejmują ESP, AH i IKE w wersji 2. Istniejące implementacje IPsec w systemach operacyjnych typu UNIX, na przykład Solaris lub Linux, zwykle obejmują PF_KEY w wersji 2.

Wbudowany protokół IPsec może służyć do zapewnienia bezpiecznej komunikacji między aplikacjami działającymi w systemach z ograniczonymi zasobami przy niewielkim nakładzie pracy.

Stan norm

Protokół IPsec został opracowany w połączeniu z protokołem IPv6 i początkowo wymagał obsługi przez wszystkie zgodne ze standardami implementacje protokołu IPv6, zanim RFC 6434 uczynił to tylko zaleceniem. Protokół IPsec jest również opcjonalny dla implementacji IPv4 . Protokół IPsec jest najczęściej używany do zabezpieczania ruchu IPv4.

Protokoły IPsec zostały pierwotnie zdefiniowane w dokumentach RFC 1825 do RFC 1829, które zostały opublikowane w 1995 roku. W 1998 roku dokumenty te zostały zastąpione przez RFC 2401 i RFC 2412 z kilkoma niekompatybilnymi szczegółami technicznymi, chociaż były one koncepcyjnie identyczne. Ponadto zdefiniowano protokół wzajemnego uwierzytelniania i wymiany kluczy Internet Key Exchange (IKE) w celu tworzenia i zarządzania powiązaniami bezpieczeństwa. W grudniu 2005 r. zdefiniowano nowe standardy w RFC 4301 i RFC 4309, które w dużej mierze są nadzbiorem poprzednich edycji z drugą wersją standardu Internet Key Exchange IKEv2 . Te dokumenty trzeciej generacji standaryzowały skrót IPsec na wielkie litery „IP” i małe litery „sec”. „ESP” ogólnie odnosi się do RFC 4303, który jest najnowszą wersją specyfikacji.

Od połowy 2008 r. w IETF działa grupa robocza IPsec Maintenance and Extensions (ipsecme).

Domniemana ingerencja NSA

W 2013 r. w ramach wycieków Snowdena ujawniono, że Agencja Bezpieczeństwa Narodowego USA aktywnie pracowała nad „wstawianiem luk w komercyjnych systemach szyfrowania, systemach IT, sieciach i urządzeniach komunikacyjnych punktów końcowych używanych przez cele” w ramach programu Bullrun . Istnieją zarzuty, że IPsec był ukierunkowanym systemem szyfrowania.

Stos OpenBSD IPsec pojawił się później i również był szeroko kopiowany. W liście, który główny deweloper OpenBSD, Theo de Raadt, otrzymał 11 grudnia 2010 r. od Gregory'ego Perry'ego, rzekomo Jason Wright i inni pracujący dla FBI wprowadzili do krypto OpenBSD „liczne backdoory i mechanizmy wycieku kluczy bocznych kanałów ”. kod. W przesłanej wiadomości e-mail z 2010 r. Theo de Raadt nie wyraził początkowo oficjalnego stanowiska w sprawie zasadności roszczeń, z wyjątkiem dorozumianego poparcia dla przekazania wiadomości e-mail. Odpowiedź Jasona Wrighta na zarzuty: „Każda miejska legenda staje się bardziej realna przez uwzględnienie prawdziwych imion, dat i godzin. E-mail Gregory'ego Perry'ego należy do tej kategorii. … Powiem wyraźnie, że nie dodałem backdoorów do działającego OpenBSD systemu kryptograficznego OpenBSD (OCF)." Kilka dni później de Raadt skomentował, że „Wierzę, że NETSEC prawdopodobnie został zakontraktowany do pisania backdoorów, jak rzekomo. … Jeśli zostały napisane, nie wierzę, że trafiły do ​​naszego drzewa”. Zostało to opublikowane przed wyciekami Snowdena.

Alternatywne wyjaśnienie przedstawione przez autorów ataku na Logjam sugeruje, że NSA naruszyła IPsec VPN, podważając algorytm Diffie-Hellmana używany w wymianie kluczy. W swoim artykule twierdzą, że NSA specjalnie zbudowała klaster obliczeniowy do wstępnego obliczania multiplikatywnych podgrup dla określonych liczb pierwszych i generatorów, takich jak druga grupa Oakley zdefiniowana w RFC 2409. W maju 2015 r. 90% adresowalnych sieci VPN IPsec obsługiwało drugą grupę Oakley w ramach IKE. Jeśli organizacja miałaby wstępnie obliczyć tę grupę, mogłaby uzyskać wymieniane klucze i odszyfrowywać ruch bez wstawiania jakichkolwiek backdoorów programowych.

Drugim zaproponowanym alternatywnym wyjaśnieniem było to, że Equation Group wykorzystywała exploity dnia zerowego przeciwko urządzeniom VPN kilku producentów, które zostały zweryfikowane przez Kaspersky Lab jako powiązane z Equation Group i zweryfikowane przez tych producentów jako prawdziwe exploity, z których część były exploitami zero-day w momencie ich ujawnienia. W Cisco PIX i ASA zapór miał słabych punktów, które zostały wykorzystane do podsłuchu przez NSA.

Ponadto sieci IPsec VPN korzystające z ustawień „Trybu agresywnego” wysyłają czysty skrót PSK. Może to być i najwyraźniej jest celem NSA przy użyciu ataków słownikowych offline.

Dokumentacja IETF

Ścieżka standardów

  • RFC  1829 : Transformacja ESP DES-CBC
  • RFC  2403 : Zastosowanie HMAC-MD5-96 w ESP i AH
  • RFC  2404 : Zastosowanie HMAC-SHA-1-96 w ESP i AH
  • RFC  2405 : algorytm szyfrowania ESP DES-CBC z wyraźnym IV
  • RFC  2410 : algorytm szyfrowania NULL i jego użycie z protokołem IPsec
  • RFC  2451 : algorytmy szyfrowania w trybie ESP CBC
  • RFC  2857 : Zastosowanie HMAC-RIPEMD-160-96 w ESP i AH
  • RFC  3526 : bardziej modułowe wykładnicze (MODP) grupy Diffie-Hellmana dla Internet Key Exchange (IKE)
  • RFC  3602 : Algorytm szyfrowania AES-CBC i jego użycie z protokołem IPsec
  • RFC  3686 : Korzystanie z trybu licznika Advanced Encryption Standard (AES) z IPsec Encapsulating Security Payload (ESP)
  • RFC  3947 : Negocjacje NAT-Traversal w IKE
  • RFC  3948 : Enkapsulacja UDP pakietów IPsec ESP
  • RFC  4106 : Użycie trybu Galois/Counter (GCM) w IPsec Encapsulating Security Payload (ESP)
  • RFC  4301 : Architektura bezpieczeństwa dla protokołu internetowego
  • RFC  4302 : Nagłówek uwierzytelniania IP
  • RFC  4303 : IP Encapsulating Security Payload
  • RFC  4304 : Dodatek ESN (Extended Sequence Number) do domeny interpretacji IPsec (DOI) dla protokołu Internet Security Association i Key Management Protocol (ISAKMP)
  • RFC  4307 : Algorytmy kryptograficzne do użytku w internetowej wymianie kluczy w wersji 2 ( IKEv2 )
  • RFC  4308 : pakiety kryptograficzne dla IPsec
  • RFC  4309 : korzystanie z trybu CCM Advanced Encryption Standard (AES) z IPsec Encapsulating Security Payload (ESP)
  • RFC  4543 : Użycie kodu uwierzytelniania wiadomości Galois (GMAC) w IPsec ESP i AH
  • RFC  4555 : IKEv2 Mobility and Multihoming Protocol (MOBIKE)
  • RFC  4806 : Rozszerzenia protokołu OCSP (Online Certificate Status Protocol) do protokołu IKEv2
  • RFC  4868 : Używanie HMAC-SHA-256, HMAC-SHA-384 i HMAC-SHA-512 z protokołem IPsec
  • RFC  4945 : profil PKI zabezpieczeń IP w Internecie w protokołach IKEv1/ISAKMP, IKEv2 i PKIX
  • RFC  5280 : Certyfikat infrastruktury klucza publicznego Internet X.509 i profil listy odwołania certyfikatów (CRL)
  • RFC  5282 : Używanie algorytmów szyfrowania uwierzytelnionego z zaszyfrowanym ładunkiem protokołu Internet Key Exchange w wersji 2 (IKEv2)
  • RFC  5386 : Bezpieczeństwo lepsze niż nic: nieuwierzytelniony tryb IPsec
  • RFC  5529 : Tryby działania kamery Camellia do użytku z protokołem IPsec
  • RFC  5685 : mechanizm przekierowywania dla protokołu wymiany kluczy internetowych w wersji 2 (IKEv2)
  • RFC  5723 : Wznawianie sesji protokołu wymiany kluczy internetowych w wersji 2 (IKEv2)
  • RFC  5857 : Rozszerzenia IKEv2 obsługujące solidną kompresję nagłówków przez IPsec
  • RFC  5858 : Rozszerzenia IPsec obsługujące solidną kompresję nagłówków przez IPsec
  • RFC  7296 : Internetowy protokół wymiany kluczy w wersji 2 (IKEv2)
  • RFC  7321 : Wymagania dotyczące implementacji algorytmu kryptograficznego i wskazówki dotyczące użytkowania dotyczące enkapsulacji ładunku zabezpieczającego (ESP) i nagłówka uwierzytelniania (AH)
  • RFC  7383 : Fragmentacja wiadomości protokołu wymiany kluczy internetowych w wersji 2 (IKEv2)
  • RFC  7427 : Uwierzytelnianie podpisu w Internet Key Exchange w wersji 2 (IKEv2)
  • RFC  7634 : ChaCha20, Poly1305 i ich zastosowanie w protokole wymiany kluczy internetowych (IKE) i IPsec

Eksperymentalne RFC

  • RFC  4478 : wielokrotne uwierzytelnianie w protokole wymiany kluczy internetowych (IKEv2)

Informacyjne dokumenty RFC

  • RFC  2367 : Interfejs PF_KEY
  • RFC  2412 : Protokół określania klucza OAKLEY
  • RFC  3706 : Oparta na ruchu metoda wykrywania martwych partnerów wymiany kluczy internetowych (IKE)
  • RFC  3715 : Wymagania dotyczące zgodności translacji adresów sieciowych IPsec (NAT)
  • RFC  4621 : Projekt protokołu IKEv2 Mobility and Multihoming (MOBIKE)
  • RFC  4809 : Wymagania dotyczące profilu zarządzania certyfikatami IPsec
  • RFC  5387 : Oświadczenie o problemie i zastosowaniu dla bezpieczeństwa Better-Than-Nothing (BTNS)
  • RFC  5856 : Integracja solidnej kompresji nagłówków przez skojarzenia zabezpieczeń IPsec
  • RFC  5930 : Korzystanie z trybu Advanced Encryption Standard Counter Mode (AES-CTR) z protokołem Internet Key Exchange w wersji 02 (IKEv2)
  • RFC  6027 : Oświadczenie o problemie z klastrem IPsec
  • RFC  6071 : Mapa drogowa dotycząca IPsec i IKE
  • RFC  6379 : pakiety kryptograficzne Suite B dla IPsec
  • RFC  6380 : profil pakietu B dla zabezpieczeń protokołu internetowego (IPsec)
  • RFC  6467 : Secure Password Framework dla Internet Key Exchange w wersji 2 (IKEv2)

Dokumenty RFC dotyczące najlepszych obecnych praktyk

  • RFC  5406 : Wytyczne dotyczące określania użycia protokołu IPsec w wersji 2

Przestarzałe/historyczne dokumenty RFC

  • RFC  1825 : Architektura bezpieczeństwa dla protokołu internetowego (przestarzałe przez RFC 2401)
  • RFC  1826 : Nagłówek uwierzytelniania IP (przestarzały przez RFC 2402)
  • RFC  1827 : IP Encapsulating Security Payload (ESP) (przestarzałe przez RFC 2406)
  • RFC  1828 : Uwierzytelnianie IP przy użyciu klucza MD5 (historyczne)
  • RFC  2401 : Architektura zabezpieczeń dla protokołu internetowego (przegląd IPsec) (przestarzałe przez RFC 4301)
  • RFC  2406 : IP Encapsulating Security Payload (ESP) (przestarzałe przez RFC 4303 i RFC 4305)
  • RFC  2407 : Internetowa domena bezpieczeństwa IP interpretacji dla ISAKMP (przestarzała przez RFC 4306)
  • RFC  2409 : Internetowa wymiana kluczy (przestarzała przez RFC 4306)
  • RFC  4305 : Wymagania dotyczące implementacji algorytmu kryptograficznego dla enkapsulacji ładunku zabezpieczającego (ESP) i nagłówka uwierzytelniania (AH) (przestarzałe przez RFC 4835)
  • RFC  4306 : protokół wymiany kluczy internetowych (IKEv2) (przestarzały przez RFC 5996)
  • RFC 4718 : Wyjaśnienia i wytyczne dotyczące implementacji protokołu  IKEv2 (przestarzałe przez RFC 7296)
  • RFC  4835 : Wymagania dotyczące implementacji algorytmu kryptograficznego dla enkapsulacji ładunku zabezpieczającego (ESP) i nagłówka uwierzytelniania (AH) (przestarzałe przez RFC 7321)
  • RFC  5996 : Internet Key Exchange Protocol w wersji 2 (IKEv2) (przestarzały przez RFC 7296)

Zobacz też

Bibliografia

Zewnętrzne linki