Wspólna grupa DH, świeże sekrety: dlaczego atak staje się tańszy

Parametry grupy są jawne z założenia i właśnie ta jawność czyni je łatwymi do przeoczenia. W Diffie-Hellmanie nad ciałem skończonym moduł i generator są wspólne, natomiast prywatne wykładniki i wynikające z nich klucze sesji już nie. Drogi etap ataku sitowym w ciele liczbowym zależy od grupy, a nie od jednej wymiany, więc jedna słaba grupa używana wszędzie staje się wspólnym obciążeniem. Nazywanie parametrów jawnymi jest trafne i nie na miejscu, bo koszt, który jest wykorzystywany ponownie, to koszt ataku na tę właśnie grupę.

Jawna połowa nie jest połową podatną, i w tym tkwi pułapka

Zwykły półargument mówi, że parametry są opublikowane w standardzie, więc atakujący już je zna, a ich ukrywanie niczego by nie zmieniło. Oba twierdzenia są prawdziwe i żadne nie wynika z drugiego. Dostarczana grupa domyślna jest jawna, a grupa prywatna wygenerowana w zeszłym tygodniu również jest widoczna dla każdego, kto ukończy uścisk dłoni. Tajność nigdy nie była kontrolą; są nią siła i walidacja.

Zmienia się to, ile miejsc dzieli tę samą słabość. Jedna organizacja generująca własną grupę 2048-bitową płaci własny koszt ataku, podczas gdy wartość domyślna protokołu wybrana przez miliony amortyzuje jeden koszt na nich wszystkich. W tym sensie niezwykła grupa nie jest automatycznie lepsza. Niezwykła grupa, która jest za mała, to po prostu mniejszy wspólny sekret z mniejszą liczbą oczu na nim.

Walidacja jest równie ważna jak rozmiar. Partner, który wysyła moduł z małymi czynnikami albo taki, który nie ma kształtu oczekiwanego przez protokół, może ujawnić informacje o wykładniku prywatnym, nawet gdy długość w bitach wygląda poważnie. Biblioteki, które odrzucają zniekształcone parametry na wejściu, wykonują prawdziwą pracę, dlatego ręcznie pisane przetwarzanie parametrów to złe miejsce na oszczędzanie wysiłku.

Co wstępne obliczenie naprawdę daje atakującemu

Sito w ciele liczbowym ma etap, który zależy wyłącznie od liczby pierwszej, a jego wynik można wykorzystać ponownie przeciw każdej wymianie używającej tej liczby pierwszej. To cały mechanizm stojący za historyczną obawą: droga część jest płacona raz, a koszt krańcowy każdej kolejnej sesji spada. Świeże wykładniki nadal chronią każdą pojedynczą wymianę przed pasywnym obserwatorem, dopóki grupa jest wystarczająco duża, by przesianie było niewykonalne. Oba twierdzenia są spójne, a większość sporów na ten temat bierze się z wybrania jednego i odrzucenia drugiego.

Praca o Logjam z 2015 roku pokazała degradację do 512-bitowego Diffie-Hellmana klasy eksportowej i oszacowała, ile kosztowałby atak na większe, szeroko ponownie używane grupy przy znacznych zasobach. Demonstracja była konkretna, szacunki były szacunkami i żadne z nich nie było dowodem, że odszyfrowano konkretną sesję VPN.

Cytuj tę pracę dla mechanizmu i dla pokazanej degradacji, a nie jako pomiar twojego wdrożenia. Stare statystyki o tym, ile serwerów dzieliło grupę domyślną, opisują internet tamtego roku, a nie sieć, którą można zbadać dziś. Warte przeniesienia jest pytanie: czy twoje urządzenia nadal negocjują grupę, która jest mała lub słabo zwalidowana?

Standaryzacja to nie to samo co słabość

RFC 7919 definiuje nazwane grupy nad ciałem skończonym, aby obie strony zgodziły się na grupę według identyfikatora i stosowały spójną politykę. Bycie standardem jest zaletą, bo usuwa niejednoznaczność negocjacji i pozwala implementacji odrzucać nieobsługiwane rozmiary. Nazwana grupa jest słaba tylko wtedy, gdy jej rozmiar jest poniżej polityki, którą rzekomo stosujesz, a nie dlatego, że pojawia się w dokumencie. Ta sama logika dotyczy grup krzywych eliptycznych, które mają inną strukturę i inne tryby awarii.

Traktuj konstrukcje osobno, gdy o nich rozumujesz. Wniosek o Diffie-Hellmanie nad ciałem skończonym nic nie mówi o X25519, a wniosek o grupie MODP 1024-bitowej nic nie mówi o grupie 3072-bitowej. Polityka siły jest określana na mechanizm, na rozmiar i na wersję protokołu, dlatego fraza silna kryptografia nie jest twierdzeniem podlegającym przeglądowi.

Uwierzytelnianie to druga połowa i nie zastępuje. Silna grupa bez weryfikacji partnera zostawia atakującego w środku, a ważny certyfikat nie uratuje wymiany 768-bitowej. Przejrzyj je jako dwie niezależne linie, a potem potwierdź, że obie są rzeczywiście negocjowane.

Odczytaj wynegocjowaną grupę na prawdziwym połączeniu

Odczytuj wynegocjowaną grupę z urządzenia, a nie z szablonu konfiguracji. Szablony opisują intencję, a interesującą wartością jest ta, na którą obie strony zgodziły się podczas ostatniego uścisku dłoni. Na punkcie końcowym IPsec wyjście stanu zwykle wypisuje wybraną propozycję, w tym grupę MODP.

Zapisz tę linię przed zmianą polityki i po niej, i przechowuj obie w rejestrze zmian. Porównanie jest dowodem.

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

Jeśli po zmianie stan nadal pokazuje starą grupę, połączenie nie wynegocjowało ponownie, a edycja konfiguracji niczego nie dowiodła. Zrestartuj partnera albo usuń asocjację bezpieczeństwa, a potem odczytaj stan ponownie. Polityka egzekwowana tylko na nowych połączeniach pozostawi długotrwałe tunele na starych parametrach, dopóki będą działać.

Sprawdź grupę i tożsamość partnera osobno

Oddziel to, co chroni grupa, od tego, kto jest po drugiej stronie. Zapisz metodę wymiany kluczy, rozmiar grupy i metodę uwierzytelniania jako trzy pola, ponieważ zawodzą niezależnie. Tunel, który wynegocjował grupę 3072-bitową, ale akceptuje dowolny certyfikat, nie jest tym samym ryzykiem co tunel, który przypina partnera i używa grupy 2048-bitowej.

Zapisz kryteria akceptacji przed rozpoczęciem przeglądu, aby wynik był porównaniem, a nie opinią. Minimalny rozmiar grupy na wersję protokołu, lista dozwolonych nazwanych grup i obowiązkowa weryfikacja partnera wystarczą, by decyzja była mechaniczna. Niejednoznaczność na tej liście zmienia przegląd w spór, a sporów nie naprawia się. Wtedy wynikiem jest lista punktów końcowych, które łamią podaną regułę.

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

Zamknij pętlę, odczytując ponownie wynegocjowane wartości po naprawie. Zgodny plik konfiguracji nie jest dowodem, że tunel go przyjął. Dowodem jest wyjście stanu i jeden świeży uścisk dłoni, a ich zebranie zajmuje mniej czasu niż spotkanie o tym, czy są potrzebne.