Domanda:
Perché non riesco a MitM uno scambio di chiavi Diffie-Hellman?
orokusaki
2015-06-16 01:40:37 UTC
view on stackexchange narkive permalink

Dopo aver letto 5 volte la risposta selezionata di "Diffie-Hellman Key Exchange" in un inglese semplice non riesco, per la vita mia, a capire come mi protegge da un attacco MitM.

Dato il seguente estratto (dalla risposta di tylerl):

  1. Ho trovato due numeri primi g e p e ti dicono cosa sono.
  2. Quindi scegli un numero segreto ( a ), ma non lo dici a nessuno. Invece, calcoli ga mod p e mi invii il risultato. (La chiameremo A poiché proviene da a ).
  3. Faccio la stessa cosa, ma chiameremo il mio numero segreto b e il numero calcolato B . Quindi calcolo gb mod p e ti invio il risultato (chiamato " B ")
  4. Ora, prendi il numero che ti ho inviato e fai la stessa identica operazione con esso . Quindi questo è Ba mod p .
  5. Faccio la stessa operazione con il risultato che mi hai inviato, quindi: Ab mod p .

Ecco gli stessi 5 passaggi con Alpha che controlla la rete:

  1. Tenti di inviarmi g e p , ma Alpha intercetta e apprende g e p
  2. Ti viene in mente a e cerchi di inviarmi il risultato di ga mod p ( A ), ma Alpha intercetta e apprende A
  3. Alpha presenta b e ti invia il risultato di gb mod p ( B )
  4. Esegui Ba mod p
  5. Alpha esegue Ab mod p

Durante l'intero processo Alpha finge di essere te e crea un segreto condiviso con me usando lo stesso metodo.

Ora, sia tu che Alpha, e Alpha e io abbiamo una coppia di segreti condivisi.

Ora pensi che sia sicuro parlare con me in segreto, perché quando tu mi mandi messaggi crittografati con il tuo segreto Alpha li decrittografa usando il segreto creato da te e Alpha, li crittografa usando il segreto creato da Alpha e me, poi me li invia. Quando ti rispondo, Alpha fa la stessa cosa al contrario.

Mi sto perdendo qualcosa qui?

Hai perfettamente ragione sul fatto che gli scambi di chiavi Diffie-Hellman sono vulnerabili a un attacco MITM, proprio come hai descritto.
Sì, ma se lo descrivi in ​​un altro modo, non sarà vulnerabile al mitm.
Correlato anche: [Come è possibile che le persone che osservano una connessione HTTPS stabilita non sappiano come decrittografarla?] (Http://security.stackexchange.com/q/6290/29865)
Sei risposte:
#1
+159
Tom Leek
2015-06-16 03:37:25 UTC
view on stackexchange narkive permalink

Diffie-Hellman è un protocollo di scambio di chiavi ma non fa nulla per l'autenticazione.

Esiste un modo concettuale di alto livello per vederlo. Nel mondo delle reti di computer e della crittografia, tutto ciò che puoi vedere, in realtà, sono zeri e uno inviati su alcuni fili. Le entità possono essere distinte l'una dall'altra solo dagli zeri e dagli uno che possono o non possono inviare. Pertanto, l'utente "Bob" è in realtà definito solo dalla sua capacità di calcolare cose che i non Bob non possono calcolare. Poiché tutti possono acquistare gli stessi computer, Bob può essere Bob solo in base alla sua conoscenza di un valore che solo Bob conosce.

Nello scambio Diffie-Hellman grezzo che presenti, parli con un'entità che si suppone per generare un valore segreto casuale al volo e utilizzarlo. Tutti possono fare tale generazione casuale. In nessun punto del protocollo c'è alcuna operazione che solo uno specifico Bob può eseguire. Pertanto, il protocollo non può ottenere alcun tipo di autenticazione: non sai con chi stai parlando. Senza autenticazione, il furto d'identità è fattibile e questo include il doppio furto d'identità simultaneo, meglio noto come Man-in-the-Middle. Nella migliore delle ipotesi, Diffie-Hellman grezzo fornisce una caratteristica più debole: anche se non sai con chi stai parlando, sai comunque che stai parlando con la stessa entità per tutta la sessione.


Un singolo algoritmo crittografico non ti porterà lontano; qualsiasi protocollo di comunicazione significativo assemblerà diversi algoritmi in modo da ottenere determinate caratteristiche di sicurezza. Un ottimo esempio è SSL / TLS; un altro è SSH. In SSH, viene utilizzato uno scambio di chiavi Diffie-Hellman, ma la parte pubblica del server (il suo gb mod p ) è firmato dal server. Il client sa di parlare con il server giusto perché ricorda (da un passaggio di inizializzazione precedente) la chiave pubblica del server (solitamente di tipo RSA o DSA); nel modello spiegato sopra, il server legittimo è definito e distinto dagli imitatori per la sua conoscenza della chiave privata della firma corrispondente alla chiave pubblica ricordata dal cliente. Quella firma fornisce l'autenticazione; Diffie-Hellman produce quindi un segreto condiviso che verrà utilizzato per crittografare e proteggere tutti gli scambi di dati per quella connessione (utilizzando una crittografia simmetrica e algoritmi MAC).

Quindi, mentre Diffie-Hellman non lo fa tutto ciò di cui hai bisogno da solo, fornisce comunque una funzione utile, ovvero uno scambio di chiavi, che non potresti ottenere dalle firme digitali e che fornisce il segreto condiviso temporaneo necessario per crittografare i dati effettivamente scambiati.

Mi è piaciuta moltissimo questa descrizione: "Pertanto, l'utente" Bob "è veramente definito solo dalla sua capacità di calcolare cose che non Bobs non possono calcolare". Questo è un modo fantastico e conciso per spiegare l'identità che non è sempre intuitivo.
Buona risposta. Un dettaglio che avrei incluso è che DH senza autenticazione può ancora fornire una certa sicurezza. DH rende la tua comunicazione sicura contro lo snooping passivo, quindi un avversario dovrebbe passare al MITM attivo. Se anche una piccola percentuale di connessioni viene autenticata, verrebbe notato un MITM attivo su larga scala, che fornisce una certa sicurezza anche per le connessioni non autenticate. Ciò si basa sul fatto che connessioni autenticate e non autenticate siano indistinguibili da un avversario passivo.
#2
+58
zinfandel
2015-06-16 04:06:34 UTC
view on stackexchange narkive permalink

Tom ha fornito una buona spiegazione del motivo per cui Diffie-Hellman non può essere al sicuro contro l'uomo-nel-medio. Ora questo risponde alla domanda originale dell'OP ma probabilmente lascia alcuni lettori con la (ragionevole) domanda di follow-up: perché non usiamo semplicemente la crittografia a chiave pubblica (asimmetrica) per garantire la riservatezza dei nostri messaggi e abbandoniamo del tutto D-H? Ci sono alcuni motivi per non farlo:

  • Esistono algoritmi che supportano solo la firma, ma non la crittografia dei messaggi (ECDSA, ad esempio)
  • La crittografia e la decrittografia simmetriche è un molto più velocemente che farlo in modo asimmetrico
  • Probabilmente la cosa più importante è che vogliamo garantire la segretezza in avanti . Dopotutto, non è impossibile che la chiave privata di uno dei tuoi partner di comunicazione venga compromessa a un certo punto. Ora, se ti affidavi solo alla crittografia asimmetrica, tutti i messaggi che hai inviato a quel partner potrebbero essere decrittografati dall'aggressore in retrospettiva. Al contrario, se usiamo Diffie-Hellman e, per essere precisi, Diffie-Hellman effimero , generiamo una nuova coppia di chiavi DH per ogni sessione di comunicazione e la buttiamo via (= non memorizzarla) in seguito , il che significa che è impossibile decrittografare i nostri messaggi in un secondo momento.
#3
+3
supercat
2015-06-16 22:17:04 UTC
view on stackexchange narkive permalink

Dopo uno scambio di chiavi DH, entrambe le parti sanno quale chiave hanno calcolato. Se nessun man-in-the-middle si è infiltrato nella connessione, entrambe le parti avranno la stessa chiave. Se la connessione è stata violata, avranno chiavi diverse. Se esiste un mezzo attraverso il quale una parte può chiedere all'altra quale chiave sta usando, l'uomo al centro sarà in grado di rimanere inosservato solo se sarà in grado di rispondere nello stesso modo che avrebbe fatto la parte legittima. Anche se spesso si risponde alla domanda utilizzando una firma digitale, per rendere difficile la rappresentazione, è possibile porre / rispondere alla domanda anche tramite cose come la comunicazione vocale. Se un'applicazione vocale mostra ai partecipanti la chiave di crittografia corrente e un partecipante seleziona arbitrariamente un intervallo e una famosa star del cinema (ad esempio Marilyn Monroe) e chiede all'altra di leggere dalla quindicesima alla venticinquesima cifra con la migliore voce di Marilyn Monroe, una il partecipante reale che ha i numeri davanti a sé potrebbe farlo in modo rapido e scorrevole e, in assenza di un attacco MITM, le cifre corrisponderebbero a quelle viste dalla prima parte. Un utente malintenzionato man-in-the-middle non avrebbe problemi a rilevare la domanda e, dato il tempo, potrebbe essere in grado di falsificare un file vocale del legittimo comunicante che fa una cattiva imitazione di Marilyn Monroe dicendo le cifre appropriate, ma lo farebbe avere difficoltà a farlo velocemente come quello vero.

In breve, il DH da solo può essere robusto contro gli attacchi MITM se ogni partecipante sa qualcosa che l'altro partecipante sarà in grado di fare con un numero in modo più efficiente di un attaccante. Altri protocolli vengono generalmente utilizzati in combinazione con DH, tuttavia, perché è utile che il processo di autenticazione sia automatizzato e la maggior parte delle forme di autenticazione che non si basano sulla crittografia (cose come voce, fraseggio, ecc.) Richiede la convalida umana. Inoltre, è spesso necessario che le entità sollecitino la comunicazione da estranei. Se vuoi parlare con un rappresentante di Acme Bank, un impostore man-in-the-middle potrebbe creare un falso ufficio "Acme Bank" e rispondere alla mia chiamata, e avere qualcun altro in un soggiorno fasullo che trasmetta tutto ciò che dico al reale Acme Bank, e nessuno sarebbe il più saggio. Se non avessi idea di quanto bene o male un vero impiegato di Acme Bank sarebbe in grado di imitare Marilyn Monroe, non avrei modo di sapere che l'imitazione di un impostore non era la stessa.

#4
+2
DarcyThomas
2015-06-18 07:35:23 UTC
view on stackexchange narkive permalink

Il DH non è generalmente resistente agli attacchi Man in the Middle.

Se Alice e Bob (A<-> B) possono impostare un segreto condiviso. Quindi Frank può impostare un segreto condiviso con Alice (A<-> F) Allo stesso tempo Frank può impostare un secondo segreto condiviso (diverso) con Bob (F<-> B). Frank può quindi decrittografare i messaggi A-> F e crittografarli nuovamente e inviarli a bob F-> B & viceversa.

* Quindi è necessario un modo per assicurarsi che il messaggio provenga effettivamente da ) Alice. O con un segreto condiviso in precedenza (consegnato tramite un altro canale) o utilizzando un'autorità di certificazione (per proxy attendibile). O qualche altro metodo.

Se ti fidi solo un po 'di una CA, Alice può impostare un segreto condiviso DH con Bob, firmando il messaggio con il certificato della CA. Bob controlla che i messaggi siano stati firmati dalla CA. Frank non può falsificare i messaggi, poiché non hanno il certificato richiesto.

Ora Alice e Bob hanno un segreto condiviso. Frank non poteva fingere di farsi strada nel mezzo. Tuttavia, la CA non ha avuto alcun ruolo nella creazione del segreto condiviso (firmando solo le parti inviate lungo il percorso), quindi la CA non può nemmeno recitare come un cattivo attore. Anche se Frank li minaccia con una chiave inglese da $ 5.

* Leggermente semplicistico ma questa è l'idea generale.

#5
+2
Benoît Morgan
2019-01-05 21:44:51 UTC
view on stackexchange narkive permalink

Devo precisare un punto nella risposta di Tom Leek: "In SSH, viene utilizzato uno scambio di chiavi Diffie-Hellman, ma la parte pubblica del server (la sua g b mod p) è firmata dal server. "

In realtà, l'intero scambio di chiavi DH è firmato. Firmare solo g b mod p non è sufficiente: si potrebbe falsificare il server SSH semplicemente connettendosi ad esso e riproducendo il pacchetto [SSH-TRANS] più tardi. Ciò non prova la conoscenza dei dati della sessione corrente; omette g a mod p, le stringhe ID SSH e la negoziazione del protocollo.

L'autenticazione viene eseguita dopo che le due parti si scambiano stringhe ID SSH e messaggi di negoziazione del protocollo e il client invia un messaggio di scambio di chiavi Diffie-Hellman contenente g a mod p.

Il server calcola g b mod p e hash tutte le informazioni importanti: H = hash (context || sig_pub || g a mod p || g b mod p || g ab mod p) con context = SSH Stringhe ID || messaggi di negoziazione del protocollo.

Quindi firma l'hash della stretta di mano: sig = signature (sig_priv, H) e rimanda (sig_pub, g b mod p, sig) al client.

In questo modo, nessuno può falsificare nulla tranne se ha violato l'algoritmo della firma.

#6
  0
munchkin
2015-06-18 10:44:02 UTC
view on stackexchange narkive permalink

Qui è dove le capacità descrittive linguistiche della lingua inglese falliscono. Diffie helman è resistente al mitm se un'entità di terze parti fuori banda è in grado di aiutare nella distribuzione delle chiavi e / o nella verifica dell'identità. Troverai in letteratura, ciò che definisce principalmente è una rete di fiducia connessa che circonda l'identità del destinatario o, nella maggior parte dei casi, la persona allegata alla chiave o al certificato.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...