IKEv1 a IKEv2 z kluczem wstępnie współdzielonym: czym różni się uwierzytelnianie

Dwie bramy skonfigurowane z tym samym kluczem wstępnie współdzielonym kończą uzgadnianie, a zapis pakietów nie pokazuje żadnego sekretu przecinającego łącze. To część, którą ludzie pamiętają. Ciekawa jest ta część, którą każda wersja faktycznie oblicza, aby dowieść znajomości sekretu, bo IKEv1 i IKEv2 budują ten dowód z różnych danych wejściowych i przy tym ujawniają różne informacje. Przeczytaj oba ślady obok siebie, a różnica przestaje być kosmetyczna.

Co musi osiągnąć dowód

Diffie-Hellman daje obu stronom wspólną wartość, której publiczne połowy potrafi obliczyć także każdy obserwator. Sama w sobie nie dowodzi niczego o tożsamości: napastnik, który kończy wymianę kluczy, ma tę samą wspólną wartość co twoja brama. Krok uwierzytelniania istnieje po to, aby powiązać tę wymianę z sekretem, który mają tylko zamierzone strony, oraz z tożsamościami i parametrami, co do których się zgodziły.

Właśnie to powiązanie sprawia, że skrót obejmuje więcej niż klucz. Gdyby obejmował tylko sekret, napastnik mógłby odtworzyć go w innej wymianie, z innymi tożsamościami lub propozycjami.

IKEv1 w Main Mode: wyprowadź SKEYID, a potem go udowodnij

Main Mode wykonuje sześć komunikatów. Pierwsza para negocjuje asocjację bezpieczeństwa, druga wymienia publiczne wartości Diffie-Hellman i nonce, a trzecia niesie tożsamości oraz skróty uwierzytelniające pod właśnie ustanowionym szyfrowaniem. RFC 2409 definiuje konstrukcję: przy uwierzytelnianiu kluczem wstępnie współdzielonym SKEYID wyprowadza się z sekretu i obu nonce, a późniejszy materiał kluczowy z SKEYID, wspólnej wartości Diffie-Hellman, plików cookie i stałych.

Skrót w piątym i szóstym komunikacie liczy się po wartości Diffie-Hellman, obu plikach cookie, propozycji i tożsamości nadawcy, z SKEYID jako kluczem. Odbiorca przelicza go własnym skonfigurowanym sekretem. Niezgodność kończy wymianę, a sekret nigdy nie jest ładunkiem.

Aggressive Mode ściska tę samą pracę w trzy komunikaty, co oznacza, że tożsamości i skrót uwierzytelniający podróżują, zanim powstanie szyfrowany kanał. To realna ekspozycja przy sekrecie możliwym do odgadnięcia, i jest to odrębna kwestia od tego, czy sekret został przesłany. IKEv1 jest przestarzały zgodnie z RFC 9395, więc stary ślad jest ćwiczeniem diagnostycznym, a nie celem wdrożenia.

IKEv2: inne wyprowadzenie i inny ładunek AUTH

IKEv2 nie używa ponownie harmonogramu kluczy z IKEv1. Początkowe klucze IKE pochodzą z ziarna zbudowanego z nonce i wspólnej wartości Diffie-Hellman, a podrzędne asocjacje bezpieczeństwa wyprowadza się z niego. Klucz wstępnie współdzielony w ogóle nie zasila ziarna.

Uwierzytelnianie pojawia się wtedy jako ładunek AUTH. Dla uwierzytelniania kluczem współdzielonym RFC 7296 określa dopełnioną postać sekretu, otrzymaną przez haszowanie sekretu z ustalonym ciągiem Key Pad for IKEv2, a następnie haszowanie podpisanych danych wymiany i tożsamości tym dopełnionym kluczem. Weryfikator potrafi odtworzyć tę samą wartość; obserwator nie, bez sekretu.

Zauważ, co się zmieniło. W IKEv1 sekret jest wtopiony w harmonogram kluczy, zanim skrót uwierzytelniający w ogóle powstanie; w IKEv2 harmonogram kluczy jest niezależny od sekretu, a dowód to odrębny ładunek związany z podpisanymi oktetami. Ta sama gwarancja pojęciowa, inna maszyneria, i dlatego nazwy parametrów oraz zapisy nie mapują się jeden do jednego.

Czego naprawdę dowiaduje się obserwator

Publiczne wartości Diffie-Hellman, propozycje, nonce i pliki cookie są widoczne w obu wersjach. Tożsamości są widoczne w IKEv1 Aggressive Mode, a w pozostałych przypadkach chronione. Sekret nigdy nie jest widoczny.

To ostatnie zdanie ma granicę, którą warto wypowiedzieć. Słaby, wybrany przez człowieka sekret można zaatakować zgadywaniem: napastnik oblicza, jaka byłaby wartość uwierzytelniająca dla kandydata na sekret, i porównuje. IKEv1 Aggressive Mode czyni to najtańszym, bo dowód jest jawny, a standardy ogólnie ostrzegają przed sekretami o niskiej entropii. Nigdy niewysyłanie sekretu to nie to samo, co uczynienie złego sekretu bezpiecznym.

Co zrobić z tym porównaniem

Używaj jednego unikalnego sekretu na każdą parę stron, generuj go z losowego źródła i rotuj tą samą ścieżką wdrożeniową, która go rozdzieliła. Jeśli sekret znajduje się w szablonie konfiguracji wysyłanym do każdego oddziału, kompromitacja w jednym miejscu jest kompromitacją wszędzie.

Preferuj uwierzytelnianie oparte na certyfikatach tam, gdzie koszt operacyjny jest akceptowalny, ponieważ usuwa problem zgadywania wspólnego sekretu i daje każdej stronie odrębną tożsamość. Tam, gdzie klucz wstępnie współdzielony zostaje, trzymaj go długim, wąsko ograniczonym, a wersję IKE traktuj jako decyzję o bezpieczeństwie, nie jako szczegół interoperacyjności.