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

Question

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

#1 da (1 voti)

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?

man-in-the-middle key-exchange diffie-hellman

posta Jeff 14.08.2013 - 17:31

fonte

1 risposta

Leggi altre domande sui tag man-in-the-middle key-exchange diffie-hellman

Il provider VPN avrà accesso ai miei contenuti? [duplicare] Bancomat / Carta di debito Sicurezza [chiuso]

score 1 · Accepted Answer

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:

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 ).
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.