Se il tuo PSK è strong (ad es. 128-bit di entropia) non devi preoccuparti, poiché attaccarlo con forza bruta o un attacco di dizionario non sarà fattibile.
Tuttavia, i PSK deboli possono essere attaccati da un server canaglia.
Per IKEv2 ( RFC 7296, sezione 2.15 ), la PSK non è mescolata nel materiale chiave utilizzato per crittografare la richiesta IKE_AUTH e il carico utile AUTH fornito dal client, che incorpora il PSK tramite un PRF, viene inviato prima dell'autenticazione del server (diverso per l'autenticazione EAP basata su nome utente / password, dove il server è prima autenticato con un certificato). Un server canaglia può, quindi, attaccare relativamente facilmente PSK deboli dopo aver ottenuto il payload AUTH. Tuttavia, la richiesta è crittografata, quindi un listener passivo non può attaccarlo.
Con IKEv1 ( RFC 2409, sezione 5.4 ) in Modalità principale, la PSK viene aggiunta a il materiale chiave utilizzato per crittografare la terza richiesta da parte del cliente. Ma un server canaglia può ancora attaccare PSK deboli cercando di decrittografare la terza richiesta con PSK diversi fino a quando i dati decrittografati possono essere analizzati come messaggio IKE e il carico utile HASH_I può essere verificato con lo stesso PSK (qualcosa di simile a volte deve essere fatto da server legittimi che dispongono di più PSK disponibili per lo stesso IP client). Come con IKEv2, un listener passivo non può attaccare il PSK a causa della crittografia.
Ora, per IKEv1 in modalità aggressiva, il server deve fornire HASH_R , che incorpora il PSK, in primo luogo per dimostrare di conoscere il PSK, quindi per il tuo scenario è più sicuro, in quanto il client non continuerà se il ladro il server risponde con un hash errato. Tuttavia, in generale, non è affatto sicuro, perché gli hash vengono scambiati senza crittografia e possono quindi essere attaccati da un listener passivo.