Co robi klucz wstępnie współdzielony w IPsec, OpenVPN i WireGuard

Słowa klucz wstępnie współdzielony pojawiają się w dokumentacji IPsec, OpenVPN i WireGuard, ale opisują trzy różne obiekty. Jeden jest sekretem uwierzytelniania, drugi chroni kanał sterujący, a trzeci dodaje materiał do uzgadniania, które już ma tożsamości. Traktowanie ich jako wymiennych daje połączenie, które zawodzi na etapie, którego nikt się nie spodziewał. Przeczytaj, co to pole robi w danym protokole, zanim skopiujesz do niego wartość.

Trzy protokoły, trzy znaczenia

Każdy protokół określa zadanie klucza we własnej specyfikacji, a te zadania się nie pokrywają. Sekret uwierzytelniania dowodzi, że dwie strony znają tę samą wartość. Klucz kanału sterującego chroni negocjację, która następuje później. Dodatek do uzgadniania zmienia harmonogram kluczy, nie zmieniając tego, kim są strony.

Żadna z tych ról nie uwierzytelnia człowieka, i właśnie to zamieszanie kosztuje najwięcej czasu. Klucz wstępnie współdzielony jest wdrażany na urządzeniach lub bramach przed wymianą, więc każdy posiadacz wygląda dla drugiej strony identycznie. Ta właściwość jest zaletą w łączu między dwoma routerami i ryzykiem w usłudze dostępu zdalnego z nazwanymi pracownikami. Trzymaj poświadczenie konta i sekret kryptograficzny w osobnych kolumnach dokumentu opisującego wdrożenie.

IPsec i OpenVPN używają tego słowa inaczej

IKEv2 może uwierzytelnić drugą stronę sekretem wstępnie współdzielonym zamiast certyfikatów, a wartość musi być zgodna po obu stronach. Ponieważ ten sam sekret zwykle konfiguruje się dla grupy stron, każdy posiadacz może podszyć się pod pozostałych, a wymiana nie zyskuje żadnej tajności wprzód z kluczy tożsamości, których nigdy nie miała.

Opcje tls-auth i tls-crypt w OpenVPN przypinają statyczny klucz do kanału sterującego, dodając podpis HMAC albo szyfrując samą negocjację. Ten klucz nie jest hasłem użytkownika i nie zastępuje certyfikatu klienta. Rozróżnienie ma znaczenie przy odnawianiu, gdy zmiana hasła pozostawia klucz kanału sterującego nietknięty.

PSK w WireGuard dodaje, nie identyfikuje

Strony WireGuard mają już klucze publiczne i prywatne Curve25519, a uzgadnianie uwierzytelnia te tożsamości. Opcjonalny klucz wstępnie współdzielony jest mieszany z kluczem łańcuchowym i wnosi materiał symetryczny ponad wymianę kluczy publicznych.

Nie dostarcza własnej tożsamości ani konta użytkownika, więc operator nie odróżni dwóch posiadaczy po ich PSK. Obie strony muszą mieć tę samą wartość, inaczej uzgadnianie kończy się niepowodzeniem bez pomocnego komunikatu. Dlatego rotację trzeba zaplanować po obu stronach naraz, a nie jako edycję jednego pliku.

Sprawdź dystrybucję, rotację i usuwanie

Dystrybucja jest słabym punktem każdego projektu, który używa jednego sekretu w wielu miejscach. Wartość wklejona do okna czatu, zapisana w repozytorium albo używana ponownie w różnych środowiskach mnoży kopie, których nikt nie zdoła policzyć, a każda kopia po cichu poszerza zasięg szkód.

Tekst Base64 nie jest szyfrowaniem. Sekret trzymany obok publicznego certyfikatu w tym samym katalogu nadal jest sekretem jawnym.

openssl rand -base64 32
sudo wg show wg0 preshared-keys
sudo grep -R -n 'psk' /etc/ipsec.d/ 2>/dev/null

Rotuj według harmonogramu i po każdym podejrzanym ujawnieniu, aktualizując każdą przewidzianą stronę przed unieważnieniem starej wartości. Potem przetestuj łącze z obu końców, bo niedopasowany klucz zawodzi na uzgadnianiu i wygląda dokładnie jak problem z zaporą.

Zapisz, który sekret chroni który etap, żeby reset hasła nigdy nie został wzięty za odnowienie klucza kryptograficznego. Ta jedna linia oszczędza godzinę za każdym razem, gdy ktoś audytuje wdrożenie.