IKEv1 e IKEv2 con chiave precondivisa: cosa cambia nell’autenticazione

Due gateway configurati con la stessa chiave precondivisa completano un handshake e una cattura di pacchetti non mostra alcun segreto che attraversa il filo. È la parte che la gente ricorda. La parte interessante è ciò che ciascuna versione calcola davvero per dimostrare che il segreto è noto, perché IKEv1 e IKEv2 costruiscono quella prova da input diversi ed espongono informazioni diverse mentre lo fanno. Leggi le due tracce affiancate e la differenza smette di essere cosmetica.

Che cosa deve ottenere la prova

Diffie-Hellman dà a entrambi i peer un valore condiviso di cui chiunque osservi può calcolare anche le metà pubbliche. Di per sé non dimostra nulla sull’identità: un attaccante che completa uno scambio di chiavi ha lo stesso valore condiviso del tuo gateway. Il passo di autenticazione serve a legare quello scambio a un segreto che solo i peer previsti possiedono, e alle identità e ai parametri su cui si sono accordati.

È questo legame il motivo per cui l’hash copre più della chiave. Se coprisse solo il segreto, un attaccante potrebbe riprodurlo in uno scambio diverso, con identità o proposte diverse.

IKEv1 in Main Mode: derivare SKEYID e poi dimostrarlo

Il Main Mode esegue sei messaggi. La prima coppia negozia la security association, la seconda scambia i valori pubblici Diffie-Hellman e i nonce, la terza porta identità e hash di autenticazione sotto una cifratura appena stabilita. La RFC 2409 definisce la costruzione: con autenticazione a chiave precondivisa, SKEYID deriva dal segreto e da entrambi i nonce, e il materiale di chiave successivo deriva da SKEYID, dal valore condiviso Diffie-Hellman, dai cookie e da costanti.

L’hash nei messaggi cinque e sei si calcola sul valore Diffie-Hellman, sui due cookie, sulla proposta e sull’identità del mittente, con SKEYID come chiave. Il destinatario lo ricalcola con il segreto configurato da lui. Una discrepanza chiude lo scambio, e in nessun momento il segreto stesso è un payload.

L’Aggressive Mode comprime lo stesso lavoro in tre messaggi, il che significa che identità e hash di autenticazione viaggiano prima che esista un canale cifrato. È una vera esposizione se il segreto è indovinabile, ed è una questione separata dal fatto che il segreto sia stato trasmesso. IKEv1 è deprecato dalla RFC 9395, quindi una traccia legacy è un esercizio diagnostico, non un obiettivo di distribuzione.

IKEv2: una derivazione diversa e un payload AUTH diverso

IKEv2 non riusa il key schedule di IKEv1. Le chiavi IKE iniziali derivano da un seed costruito con i nonce e il valore condiviso Diffie-Hellman, e le security association figlie derivano da quello. La chiave precondivisa non alimenta affatto il seed.

L’autenticazione appare poi come payload AUTH. Per l’autenticazione a chiave condivisa, la RFC 7296 prescrive una forma del segreto con padding, ottenuta calcolando l’hash del segreto con la stringa fissa Key Pad for IKEv2, e poi calcolando l’hash dei dati di scambio firmati e dell’identità con quella chiave con padding. Il verificatore può ricostruire lo stesso valore; un osservatore non può, senza il segreto.

Nota cosa è cambiato. In IKEv1 il segreto è incorporato nel key schedule prima che l’hash di autenticazione esista; in IKEv2 il key schedule è indipendente dal segreto e la prova è un payload distinto, legato agli ottetti firmati. Stessa garanzia concettuale, macchinario diverso, ed è per questo che i nomi dei parametri e le catture non si mappano uno a uno.

Che cosa impara davvero un osservatore

I valori pubblici Diffie-Hellman, le proposte, i nonce e i cookie sono visibili in entrambe le versioni. Le identità sono visibili in IKEv1 Aggressive Mode e protette negli altri casi. Il segreto non è mai visibile.

Quell’ultima frase ha un limite che vale la pena dire. Un segreto debole, scelto da una persona, può essere attaccato per tentativi: l’attaccante calcola quale sarebbe il valore di autenticazione per un segreto candidato e confronta. IKEv1 Aggressive Mode rende questo il più economico perché l’evidenza è in chiaro, e gli standard mettono in guardia sui segreti a bassa entropia in generale. Non trasmettere mai il segreto non equivale a rendere sicuro un segreto cattivo.

Che fare con il confronto

Usa un segreto unico per ogni coppia di peer, generato da una fonte casuale, e ruotalo attraverso lo stesso percorso di provisioning che lo ha distribuito. Se il segreto è in un modello di configurazione che viene spedito a ogni filiale, un compromesso in un sito è un compromesso ovunque.

Preferisci l’autenticazione basata su certificati dove il costo operativo è accettabile, perché elimina il problema dell’indovinare il segreto condiviso e dà a ogni peer un’identità distinta. Dove una chiave precondivisa resta, tienila lunga, limitane l’ambito e tratta la versione IKE come una decisione di sicurezza, non come un dettaglio di interoperabilità.