IKEv2: Perché è importante "che ogni lato firmi il nonce dell'altro lato"

2

Attualmente sto approfondendo il protocollo IKEv2. Nella descrizione dell'autenticazione (RFC5996, pagina 48), viene fornita la seguente dichiarazione:

"È fondamentale per la sicurezza dello scambio che ciascun lato firmi il nonce dell'altro lato"

Qualcuno può spiegarmi questo problema? Per me è chiaro che ho bisogno di un tipo di tipo di firma per provare la conoscenza di un segreto per poterlo autenticare. Inoltre, ogni lato firma il primo pacchetto IKE_SA_INIT completo per garantire l'integrità.

    
posta sege 24.04.2014 - 11:33
fonte

1 risposta

3

La frase che citi riguarda gli attacchi di replay . Se due sistemi A e B eseguono il protocollo e B ne dimostra l'identità firmando alcuni elementi x , quindi quel valore x deve cambiare in qualche modo ogni volta che viene riprodotto il protocollo. Altrimenti, se x viene riutilizzato, un utente malintenzionato C può impersonare B , osservando prima il protocollo una volta (per ottenere una copia di B firma su x ), quindi affermando di essere B e mostrando di nuovo quel valore di firma.

Quindi x deve cambiare ogni volta; e A deve essere sicuro che x è un nuovo valore, quindi non deve essere scelto da B , ma da A . Un valore scelto di nuovo per ogni protocollo eseguito da una parte e inviato all'altro è chiamato nonce .

La situazione simmetrica si verifica quando i segni A e B si verificano, quindi hai bisogno di due nonce, e ogni sistema deve firmare il nonce dell'altro lato.

Un semplice nonce non è sufficiente, tuttavia, poiché un attaccante laborioso potrebbe fare quanto segue:

  • C si connette a A e afferma di essere B .
  • Allo stesso tempo, C si connette a B e afferma di essere A .
  • A manda un C non firmato a lo verificherà con B )
  • B invia un nonce v da firmare C ( B lo verificherà con A )
  • C invia u a B come nonce da firmare B .
  • C invia v a A come nonce da firmare A .
  • B firma u , come specificato dal protocollo.
  • Un firma v , come specificato dal protocollo.
  • C invia la firma B su u a A .
  • C invia la firma A su v a B .

E voilà! entrambi A e B hanno ricevuto una firma da, rispettivamente, B e A , sui valori nonce u e v che hanno inviato. Quindi ora A e B sono "sicuri" di parlare tra loro, mentre in realtà stanno parlando con l'attaccante C .

Il trucco qui è che C "retargets" nonces e firme: l'attaccante invia come "nonce per firmare" il valore che ha ricevuto lui stesso, e lo rimanda come "signature on nonce" a firma che ha ricevuto. Per prevenire tali attacchi, la firma non deve coprire solo il nonce, ma anche abbastanza dati specifici della connessione per impedire questo retargeting. Questo è il punto di includere l'intero IKE_SA_INIT in quel blocco che è firmato.

Questo tipo di problema del protocollo è generico; troverai lo stesso tipo di contromisure in SSL / TLS , dove sia la firma del client ( CertificateVerify ) e i checksum finali ( Finished messaggi) operano sugli hash calcolati su tutti i precedenti messaggi di handshake.

    
risposta data 24.04.2014 - 13:29
fonte

Leggi altre domande sui tag