Può la verifica manuale dell'hash difendere da un attacco DH MITM?

1

Comprendo in che modo lo scambio di chiavi DH è vulnerabile a un attacco MITM.

Quando Alice invia Bob g, p e la sua chiave pubblica, se ha anche inviato un valore H che era un hash dei valori g, p, e la chiave pubblica tutti concatenati insieme, potrebbe lei e Bob avere una telefonata dove verificano che H sia lo stesso valore per entrambi e quindi hanno la certezza che hanno gli stessi valori per g, p e la chiave pubblica?

Mi rendo conto che il punto principale dello scambio di chiavi DH è che le parti anonime possono scambiare una chiave e che un passaggio manuale come questo in qualche modo non riesce a superare il punto di scambio della chiave DH.

Ancora, funzionerebbe?

    
posta Jeff 14.08.2013 - 17:31
fonte

1 risposta

1

Alice non dovrebbe inviare il valore hash sul filo; invece, Bob deve ricalcolare il valore dell'hash sul suo lato, in base ai valori che ha ricevuto, quindi confrontare il valore hash con una fonte autorevole (la telefonata).

Questo funziona. È facile vedere se lo consideriamo in due passaggi:

  1. In presenza di Diffie-Hellman, un attacco Man-in-the-Middle richiede che l'attaccante metta la propria chiave pubblica DH al posto di quella di Alice o Bob (un MitM è una doppia impersonificazione, quindi l'attaccante deve effettuare la sostituzione due volte). È sufficiente che Bob "si assicuri" che ciò che ha ricevuto è effettivamente ciò che Alice ha inviato per rilevare una tale sostituzione. Bob può telefonare ad Alice e comporre, oltre la linea telefonica, la chiave pubblica DH ricevuta (che include i parametri del gruppo DH p e g e la vera chiave pubblica DH da Alice g a mod p ).

  2. Invece di sillabare i tre grandi numeri interi (che sarebbero più di 1500 caratteri esadecimali), Alice e Bob possono semplicemente usare l'hash dei valori. Fintanto che la funzione di hash è seconda preimage resistente , la verifica del valore hash equivale a verificare la chiave pubblica completa.

Questo metodo è esattamente che cosa succede con SSH . La prima volta che ti connetti a un server SSH finora sconosciuto, ottieni qualcosa di simile a questo:

The authenticity of host 'foo.example.com (42.17.131.8)' can't be established.
RSA key fingerprint is 45:77:d0:f0:b1:76:ce:cf:14:60:e4:89:54:20:c5:3d.
Are you sure you want to continue connecting (yes/no)?

A questo punto, si dovrebbe telefonare al sysadmin del server desiderato per verificare il valore hash (o controllarlo con qualche altra fonte autorevole, che dipende dal contesto). Questo è esattamente ciò che suggerisci. Il client SSH registra quindi la chiave pubblica dal server, in modo che nessuna domanda di questo tipo sia necessaria per le connessioni successive.

    
risposta data 14.08.2013 - 17:44
fonte

Leggi altre domande sui tag