Diffie-Hellman è un algoritmo di scambio di chiavi . La domanda buona da porre è: scambiare una chiave, sì, ma con chi?
Dal punto di vista della rete, "vedi" altre persone solo attraverso i pacchetti che ti inviano; e dato che tutti possono acquistare lo stesso tipo di PC, tutti possono inviare gli stessi pacchetti - tranne che alcune persone / sistemi potrebbero conoscere alcuni valori che altri non hanno. In crittografia, la conoscenza è potere , il che significa che tu sei ciò che sai. Se inizi a scambiare dati con Alice, sai che stai parlando con Alice e non con Bob perché Alice può inviarti un messaggio che potrebbe essere stato calcolato solo da qualcuno che conosce un determinato valore e in qualche modo sappi che c'è qualcuno chiamato "Alice" che conosce quel valore, e qualcun altro chiama "Bob" che non lo fa.
Se, nel tuo modello, non definisci almeno che esistono diversi interlocutori con una conoscenza distinta, allora la nozione di "uomo nel mezzo" non ha nemmeno senso, perché tutte le altre persone, in quel modello, sono identici. Se vuoi parlare dell'attacco man-in-the-middle e di come evitarli, devi prima definire con chi vuoi parlare, e ciò implica specificare che cosa quel sistema / persona sa, che l'attaccante non lo sa.
In breve: MitM è un caso speciale di imitazione (anche una doppia impersonificazione), in cui un attaccante assume l'identità di qualcun altro. Quindi hai bisogno di una nozione di "identità" prima di iniziare a discutere degli attacchi MitM.
Supponiamo ora di aver definito una nozione di identità. Per esempio. sei un browser Web e stai cercando di raggiungere un URL https://www.example.com/foobar.html . Quindi la nozione di identità è "chiunque controlli il server www.example.com , come registrato nel DNS ".
Diffie-Hellman è un algoritmo di scambio di chiavi. Ciò significa che non include, di per sé, alcun tipo di autenticazione. Questo non significa che il DH sia inutile; solo che è improbabile che fornisca da solo la totalità della funzionalità di sicurezza che si cerca di ottenere. In pratica, diversi algoritmi crittografici sono assemblati in un protocollo come SSL / TLS .
Tornando al nostro esempio, Diffie-Hellman è ampiamente utilizzato in SSL / TLS, con le suite di crittografia "DHE". L'intera torre della crittografia ha questo aspetto:
- Il server ha una coppia di chiavi pubblica / privata adatta per firme (RSA, DSA, ECDSA ...).
- Il server genera la metà dello scambio di chiavi DH, quindi lo firma (con la sua chiave privata di firma) e lo invia al client.
- Il server invia anche la sua chiave pubblica della firma al client, come certificato emesso da qualche CA.
- Il client convalida il certificato (perché il client conosce già e si fida della CA) e apprende quindi la chiave pubblica del server.
- Il client verifica che il certificato del server contenga il nome del server previsto (qui:
www.example.com ).
- Il client verifica la firma sulla metà-DH inviata dal server, utilizzando la chiave pubblica del server.
- Il client calcola il suo mezzo-DH e lo invia al server.
- Il client e il server completano il calcolo DH e ottengono un segreto condiviso, che viene poi espanso in chiavi simmetriche per crittografare tutti i dati.
La nozione di identità utilizzata dal client è che un proprietario del server non può ottenere certificati validi da una CA attendibile a meno che non controlli effettivamente il dominio pertinente. Quindi, dal punto di vista del cliente, il "vero www.example.com server" è "chiunque conosca una chiave privata corrispondente a una chiave pubblica in un certificato di una CA attendibile e contenente il nome www.example.com ". La conoscenza della chiave privata è ciò che rende il server "quello giusto". La CA collega quella chiave (la chiave pubblica, in particolare) al nome DNS.
Ciò che protegge MitM è che il man-in-the-middle non conosce la chiave privata (potrebbe generare chiavi private, ma non corrisponderebbe alla chiave pubblica nel certificato). La firma è il meccanismo con il quale questa protezione viene applicata. Quello non è Diffie-Hellman che fornisce quella protezione. D'altra parte, la firma non risulta in un segreto condiviso: questo è il lavoro di DH.
Riepilogo: si desidera ottenere un segreto condiviso con un server specifico, in modo da poter crittografare i gigabyte di dati da inviare a quel server. Questo è un lavoro in due parti: vuoi un segreto condiviso , ma deve anche essere con un server specifico . DH fa la parte del "segreto condiviso". Hai bisogno di qualcos'altro per l'altra parte, ad es. qualche algoritmo di firma. Questo è ciò che accade in SSL o SSH.