Che cosa fa una chiave precondivisa in IPsec, OpenVPN e WireGuard

Le parole chiave precondivisa compaiono nella documentazione di IPsec, OpenVPN e WireGuard, e descrivono tre oggetti diversi. Uno è un segreto di autenticazione, uno protegge un canale di controllo e uno aggiunge materiale a un handshake che ha già delle identità. Trattarli come intercambiabili produce una connessione che fallisce in una fase che nessuno si aspettava. Leggi che cosa fa il campo in quel protocollo prima di copiarvi un valore.

Tre protocolli, tre significati

Ogni protocollo definisce il compito della chiave nella propria specifica, e i compiti non si sovrappongono. Un segreto di autenticazione dimostra che due peer conoscono lo stesso valore. Una chiave di canale di controllo protegge la negoziazione che segue. Un’aggiunta per l’handshake cambia la sequenza delle chiavi senza cambiare chi sono i peer.

Nessuno di questi ruoli autentica un utente umano, ed è questa confusione che costa più tempo. Una chiave precondivisa viene fornita ai dispositivi o ai gateway prima dello scambio, così ogni detentore appare identico all’altro capo. Questa proprietà è un vantaggio per un collegamento sito a sito tra due router e un rischio per un servizio di accesso remoto con dipendenti nominati. Tieni la credenziale dell’account e il segreto crittografico in colonne separate del documento che descrive la distribuzione.

IPsec e OpenVPN usano la parola in modo diverso

IKEv2 può autenticare un peer con un segreto precondiviso invece che con i certificati, e il valore deve coincidere su entrambi i capi. Poiché lo stesso segreto è di solito configurato per un gruppo di peer, qualsiasi detentore può impersonare gli altri, e lo scambio non guadagna alcuna segretezza in avanti da chiavi di identità che non ha mai avuto.

Le opzioni tls-auth e tls-crypt di OpenVPN agganciano una chiave statica al canale di controllo, aggiungendo una firma HMAC oppure cifrando la negoziazione stessa. Quella chiave non è una password utente e non sostituisce il certificato del client. Distinguere le due cose conta al momento del rinnovo, quando un cambio di password lascia intatta la chiave del canale di controllo.

La PSK di WireGuard aggiunge, non identifica

I peer WireGuard hanno già chiavi pubbliche e private Curve25519, e l’handshake autentica quelle identità. Una chiave precondivisa opzionale viene mescolata nella chiave di concatenamento, apportando materiale simmetrico in aggiunta allo scambio di chiavi pubbliche.

Non fornisce un’identità propria né un account utente, quindi un operatore non può distinguere due detentori dalla loro PSK. Entrambi i capi devono portare lo stesso valore, altrimenti l’handshake fallisce senza un messaggio di errore utile. Per questo la rotazione va pianificata su entrambi i lati insieme e non come la modifica di un singolo file.

Controlla distribuzione, rotazione e rimozione

La distribuzione è il punto debole di ogni progetto che usa un segreto in molti posti. Un valore incollato in una finestra di chat, salvato in un repository o riutilizzato tra ambienti accumula copie che nessuno può elencare, e ogni copia allarga in silenzio il raggio d’azione.

Il testo Base64 non è cifratura. Un segreto conservato accanto a un certificato pubblico nella stessa directory resta un segreto in chiaro.

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

Ruota secondo un calendario e dopo qualsiasi esposizione sospetta, aggiornando ogni peer previsto prima di revocare il vecchio valore. Poi prova il collegamento da entrambi i capi, perché una chiave che non coincide fallisce all’handshake e sembra esattamente un problema di firewall.

Documenta quale segreto protegge quale fase, così un reset della password non viene mai scambiato per il rinnovo di una chiave crittografica. Quella riga fa risparmiare un’ora ogni volta che qualcuno controlla la distribuzione.