Robiłem IPsec VPN na ASA 8.0 i trochę o tym rozumiem. Inicjator rozpoczyna od wysłania swojej polityki ISAKMP do respondera, a on odpowiada z powrotem dopasowanej polityce. Następnie klucz Diffie-Hellman zostaje wymieniony, a następnie oba wysyłają klucz wstępny do drugiego w celu uwierzytelnienia.
Teraz mamy dwa klucze:
Który klucz służy do szyfrowania klucza współdzielonego?
Zadałeś świetne pytanie. Pytanie wydaje się bardzo proste, ale w rzeczywistości odpowiedź jest nieco bardziej złożona. Zrobię co w mojej mocy, aby udzielić zwięzłej odpowiedzi. Ponadto, skoro wspomniałeś o ISAKMP, zakładam, że jesteś zainteresowany IKEv1. W IKEv2 sytuacja się trochę zmienia (cóż, bardzo dużo), ale chciałem wspomnieć, że odpowiedź poniżej koreluje tylko z IKEv1.
Fazę 1 można osiągnąć w dwóch różnych modach: trybie głównym i trybie agresywnym. W obu trybach pierwsza wiadomość jest wysyłana przez inicjatora, a druga wiadomość jest wysyłana przez obiekt odpowiadający. Obie wiadomości zawierają to, co w świecie kryptografii znane jest jako nonce . Nonce to po prostu losowo generowana liczba do użycia przy generowaniu klucza. (termin Nonce pochodzi od _N_numeru użytego _Once_) . Tak więc po wiadomości 1 i 2 obie strony znają się wzajemnie.
Nonce są łączone z Pre-Shared-Key, aby utworzyć wartość początkową do generowania tajnych kluczy. Względna część IKE RFC znajduje się tutaj:
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYID to wartość początkowa, która zostanie później wykorzystana do wygenerowania dodatkowych tajnych kluczy. Pre-Shared-Key i obie wartości Nonce (Ni_b to nonce inicjatora, a Nr_B to nonce obiektu odpowiadającego) są łączone za pomocą PRF lub losowej funkcji Psuedo. PRF jest jak algorytm mieszający, tyle że wynik może mieć tyle bitów, ile potrzebujesz.
Teraz, jeśli początkowo korzystałeś z trybu głównego, wiadomości 3 i 4 współużytkują (odpowiednio) klucze publiczne Diffie-Hellmana inicjatora i obiektu odpowiadającego. Obaj używają tych wartości, aby wygenerować wspólny sekret Diffie-Hellman . Jeśli robisz tryb agresywny, te publiczne wartości DH są również zawarte w komunikacie 1 i komunikacie 2 (wraz z nonces).
Wartość początkowa jest następnie łączona z kluczem współdzielonym DH (i kilkoma innymi wartościami), aby utworzyć trzy klucze sesji : klucz Derevative, klucz uwierzytelniania i klucz szyfrowania. RFC stwierdza, że:
Wynikiem trybu głównego lub trybu agresywnego są trzy grupy uwierzytelnionego materiału klucza:
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
SKEYID_d, _a i _e to trzy klucze sesji wymienione powyżej. SKEYIDjest wartością Seed. g^xyjest wspólnym sekretem DH. CKY-Ii CKI-Rsą plikami cookie inicjatora i obiektu odpowiadającego, są to tylko dodatkowe losowo generowane wartości, które są później używane do identyfikacji tej konkretnej wymiany ISAKMP i powiązania bezpieczeństwa. 0 1 2są literalnymi liczbami 0, 1 i 2. Symbol |potoku reprezentuje konkatenację.
W każdym razie wszystkie te wartości są łączone za pomocą PRF, który tworzy trzy klucze sesji:
Klucz uwierzytelniający i klucz szyfrujący służą do zabezpieczenia / szyfrowania następnej negocjacji fazy 2. W trybie głównym komunikaty 5 i 6 fazy 1 są również chronione przez te klawisze. Ponadto wszelkie przyszłe wymiany informacji ISAKMP (DPD, zdarzenia Rekey, usuwanie wiadomości itp.) Są również chronione przez te dwa klucze.
Klucz pochodny jest przekazywany do IPsec, a IPsec generuje własny materiał klucza z tego klucza. Jeśli sobie przypomnisz, IPsec z natury nie zawiera mechanizmu wymiany kluczy, więc jedynym sposobem na uzyskanie tajnych kluczy jest albo ustawienie ich ręcznie (co jest archaiczne i nigdy tak naprawdę nie zrobione), LUB uzależnienie od usługi zewnętrznej, aby dostarczyć materiał na klucz, taki jak ISAKMP.
RFC mówi tak:
SKEYID_e jest kluczowym materiałem wykorzystywanym przez ISAKMP SA w celu ochrony poufności swoich wiadomości.
SKEYID_a jest kluczowym materiałem używanym przez ISAKMP SA do uwierzytelnienia swoich wiadomości.
SKEYID_d jest materiałem na klucz używany do uzyskiwania kluczy dla skojarzeń bezpieczeństwa innych niż ISAKMP.
Po tym wszystkim możemy odnieść się do twojego pytania: Jakiego klucza używa się do zabezpieczenia klucza współdzielonego?
W trybie głównym klucz wstępny (PSK) jest weryfikowany w komunikatach 5 i 6. Wiadomości 5 i 6 są chronione przez klucze sesji generowane przez ISAKMP, opisane powyżej.
W trybie agresywnym żadne wiadomości w trakcie negocjacji nie są szyfrowane. PSK jest weryfikowany w Wiadomościach 2 i 3. Uwaga, powiedziałem, że w obu przypadkach PSK jest weryfikowany i nigdy nie mówiłem, że PSK jest wymieniany . Oczywiście, jeśli nic w trybie agresywnym nie jest zaszyfrowane, a po prostu wysłałeś klucz współdzielony przez drut niezaszyfrowany, istniałaby ogromna luka bezpieczeństwa.
Na szczęście dla nas pisarze ISAKMP już o tym pomyśleli. W rezultacie stworzyli specjalną metodę weryfikacji, czy każda ze stron ma prawidłowy PSK, bez faktycznego udostępniania go przez sieć. Istnieją dwa elementy, które służą do sprawdzania poprawności u każdego elementu równorzędnego, że oba mają ten sam PSK: Metoda tożsamości i Hash tożsamości .
Partnerzy VPN mogą identyfikować się różnymi metodami; najczęściej peery po prostu użyją swojego źródłowego adresu IP. Ale mają opcję użycia nazwy FQDN lub nazwy hosta. Każdy z nich, wraz z wartością korelującą dla wybranej metody, stanowią Metodę tożsamości. Na przykład, gdybym miał IP 5.5.5.5 i chciałbym użyć mojego adresu IP do identyfikacji, moją Metodą identyfikacyjną byłaby efektywnie [Adres IP, 5.5.5.5] . (Uwaga: OBA wartości składają się na całą metodę ID)
Metoda ID jest następnie łączona (przy użyciu PRF) z wartością Seed, którą omówiliśmy wcześniej (SKEYID), i kilkoma innymi wartościami, aby utworzyć skrót tożsamości . Przypomnijmy, że przede wszystkim w tworzeniu SKEYID był Pre-Shared-Key.
Metoda ID i funkcja mieszania identyfikatora są następnie przesyłane przewodowo, a druga strona próbuje odtworzyć funkcję mieszania identyfikatora przy użyciu tej samej formuły. Jeśli odbiorca jest w stanie odtworzyć tę samą wartość skrótu identyfikatora, oznacza to, że nadawca musi mieć prawidłowy klucz wstępny.
Jest to opisane w RFC tutaj:
W celu uwierzytelnienia albo wymiany inicjator protokołu generuje HASH_I, a odpowiadający generuje HASH_R, gdzie:
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
IDii i IDir są metodą ID. A HASH_I i HASH_R są skrótami inicjatora i obiektu odpowiadającego. Oba są udostępniane w fazie 1. Z RFC:
Podczas uwierzytelniania klucza wstępnego tryb główny jest definiowany w następujący sposób:
Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_RTryb agresywny z kluczem wstępnym jest opisany w następujący sposób:
Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I -->
A teraz możemy wreszcie w pełni odpowiedzieć na twoje pytanie:
Pre-Shared-Key jest łączony za pomocą PRF z Nonces i wielu innych wartości znanych każdemu innemu w trakcie negocjacji. Wynikiem jest wartość, którą obie strony mogą osiągnąć tylko wtedy, gdy obie strony rozpoczną z tymi samymi wartościami - innymi słowy tym samym kluczem wstępnym. Wynikową wartością jest to, co jest udostępniane w przewodzie, dzięki czemu dwie strony mogą sprawdzić, czy mają pasujące klucze współdzielone wstępnie, bez ujawniania jakichkolwiek informacji o samym kluczu współdzielonym.
Tryb główny idzie o krok bezpieczniej, szyfrując również wymianę „wartości wynikowej” opisanej powyżej, co jeszcze bardziej utrudnia wydobycie użytecznych informacji o tym, czym był klucz współdzielony.
(wygląda na to, że nie udało mi się odpowiedzieć na to zwięźle)
Twoja odpowiedź jest na twoje pytanie: Wymiana Diffie-Hellman służy do generowania wspólnego klucza w celu bezpiecznej wymiany wspólnego klucza (tj. Wstępnego udostępniania).
Zobacz: /security/67953/understanding-diffie-hellman-key-exchange
źródło