Perché non riesco a MitM uno scambio di chiavi Diffie-Hellman?

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

C'è un modo concettuale e di alto livello per vederlo. Nel mondo delle reti informatiche e della crittografia, tutto quello che puoi vedere, in realtà, sono gli zeri e quelli inviati su alcuni fili. Le entità possono essere distinte l'una dall'altra solo dagli zeri e da quelli che possono o non possono inviare. Quindi, l'utente "Bob" è veramente definito solo dalla sua capacità di calcolare cose che i non-Bob non possono calcolare. Dal momento che tutti possono acquistare gli stessi computer, Bob può essere Bob solo per la sua conoscenza di un valore che solo Bob conosce.

Nello scambio raw Diffie-Hellman che tu presenti, parli con qualche entità che dovrebbe generare al volo un valore segreto casuale e usarlo. Ognuno può fare una tale generazione casuale. In nessun punto del protocollo esiste alcuna operazione che solo un determinato Bob può eseguire. Pertanto, il protocollo non può raggiungere alcun tipo di autenticazione: non si sa con chi si sta parlando. Senza autenticazione, la rappresentazione è fattibile e include la doppia impersonificazione simultanea, meglio conosciuta come Man-in-the-Middle . Nel migliore dei casi, Raw Diffie-Hellman fornisce una funzionalità più debole: sebbene tu non sappia 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 alcune caratteristiche di sicurezza definite. Un primo esempio è SSL / TLS ; un altro è SSH . In SSH, viene utilizzato uno scambio di chiavi Diffie-Hellman, ma la parte pubblica del server (il suo g ^b mod p ) è firmato dal server. Il client sa che parla al server giusto perché il client ricorda (da un precedente passo di inizializzazione) la chiave pubblica del server (di solito di tipo RSA o DSA); nel modello spiegato sopra, i server legittimi sono definiti e distinti dagli imitatori in base alla sua conoscenza della chiave privata della firma corrispondente alla chiave pubblica ricordata dal client. Quella firma fornisce l'autenticazione; il Diffie-Hellman produce quindi un segreto condiviso che verrà utilizzato per crittografare e proteggere tutti gli scambi di dati per quella connessione (utilizzando alcuni algoritmi di crittografia simmetrica e MAC).

Così, mentre Diffie-Hellman non fa tutto ciò che ti serve da solo, fornisce comunque una funzionalità utile, vale a dire uno scambio di chiavi , che non otterresti dalle firme digitali e che fornisce il segreto condiviso temporaneo necessario per crittografare i dati effettivamente scambiati.

Tom ha fornito una buona spiegazione sul perché Diffie-Hellman non può essere al sicuro contro l'uomo nella media. Ora questo risponde alla domanda originale dell'OP, ma probabilmente lascia alcuni lettori con la (ragionevole) domanda di follow-up: Perché non usiamo solo la crittografia a chiave pubblica (asimmetrica) per garantire la riservatezza dei nostri messaggi e far cadere completamente 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 decodifica simmetriche sono molto più veloci rispetto a eseguirle in modo asimmetrico
• Probabilmente la cosa più importante è che vogliamo garantire inoltrare la segretezza . Dopo tutto, non è impossibile che la chiave privata di uno dei tuoi partner di comunicazione sia compromessa a un certo punto. Ora, se ti fidi solo della crittografia asimmetrica, tutti i messaggi che hai inviato a quel partner potrebbero essere decodificati dall'attaccante in retrospettiva. Al contrario, se utilizziamo Diffie-Hellman - e per essere precisi, Diffie-Hellman effimero , generiamo una nuova coppia di chiavi DH per ogni sessione di comunicazione e la gettiamo via (= non la memorizziamo) in seguito , il che significa che è impossibile decifrare i nostri messaggi in un secondo momento.

Dopo uno scambio di chiavi DH, entrambe le parti sanno quale chiave hanno calcolato. Se nessun man-in-the-middle ha infiltrato la connessione, entrambe le parti avranno la stessa chiave. Se la connessione è stata violata, avranno chiavi diverse. Se c'è un mezzo attraverso il quale una parte può chiedere all'altro quale chiave sta usando, l'uomo nel mezzo sarà in grado di rimanere inosservato solo se è in grado di rispondere nello stesso modo in cui avrebbe fatto la parte legittima. Mentre la domanda viene spesso risolta usando una firma digitale, per rendere difficile la rappresentazione, la domanda può anche essere posta / risposta attraverso 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 stella del cinema (ad es. Marilyn Monroe), e chiede all'altro di leggere il quindicesimo fino al venticinquesimo nella loro migliore voce di Marilyn Monroe, il vero partecipante che ha i numeri di fronte a lui sarebbe in grado di farlo in modo rapido e scorrevole e, in assenza di un attacco MITM, le cifre corrisponderebbero a quelle viste dalla prima parte. Un aggressore di tipo "man-in-the-middle" non avrebbe problemi a scoprire la domanda, e - dato il tempo - potrebbe essere in grado di falsificare un file vocale del comunicatore legittimo facendo una brutta imitazione di Marilyn Monroe che pronuncia le cifre appropriate, ma avere difficoltà a farlo velocemente quanto quello reale.

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

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 (diverso) segreto condiviso con Bob (F < - > B). Frank può quindi decifrare A- > F messaggi e re-crittografare e inviare a bob F- > B & viceversa.

* Quindi hai bisogno di un modo per garantire che il messaggio provenga effettivamente (è stato firmato da) Alice. O con un segreto precedentemente condiviso (consegnato attraverso un altro canale) o utilizzando un'autorità di certificazione (per fidelizzare il proxy). O qualche altro metodo.

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

Ora Alice e Bob hanno un segreto condiviso. Frank non riusciva a farsi strada nel mezzo. Tuttavia, la CA non ha avuto alcun ruolo nel creare il segreto condiviso (firmando solo le parti inviate lungo la strada). Quindi la CA non può nemmeno interpretare un cattivo attore. Anche se Frank li minaccia con una chiave inglese da $ 5.

* Leggermente semplicistico, ma questa è l'idea generale.

Devo rendere più preciso un punto della 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. La firma solo di g ^b mod p non è sufficiente: si potrebbe spoofare il server SSH semplicemente connettendosi ad esso e ripetendo il pacchetto [SSH-TRANS] in un secondo momento. Ciò non dimostra la conoscenza dei dati della sessione corrente; omette g ^a mod p, le stringhe SSH ID e la negoziazione del protocollo.

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

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

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

In questo modo, nessuno può spoofare nulla, tranne se hanno rotto l'algoritmo della firma.

Questo qui è dove le abilità descrittive linguistiche della lingua inglese falliscono. Diffie helman è resistente al mitm se un'entità di terze parti fuori banda è in grado di aiutare a distribuire chiavi e / o verificare l'identità. Troverete in letteratura, ciò che definisce principalmente è una rete di fiducia che circonda l'identità del destinatario o, nella maggior parte dei casi, la persona collegata alla chiave o al certificato.