Hai ragione a generare chiavi simmetriche all'inizio della sessione. Più precisamente, il metodo normale consiste nel generare una chiave simmetrica (una chiave di sessione), con un protocollo che assicura che entrambe le parti generino la stessa chiave, in modo che questa chiave condivisa possa essere utilizzata su entrambi i lati. Un protocollo popolare per tale scambio di chiavi è Diffie-Hellman . (Nonostante il nome, questo non è uno scambio di chiavi simmetriche: è uno scambio di chiavi pubbliche DH, che porta le due parti a essere in grado di generare lo stesso materiale segreto.)
Non è necessario che una delle parti abbia una coppia di chiavi asimmetriche per fare ciò e stabilire un canale sicuro.
Dove è necessario che almeno uno dei lati abbia una chiave privata e che l'altro lato abbia la chiave pubblica corrispondente, è per l'autenticazione. Con Diffie-Hellman, le due parti possono essere certe che nessun terzo sta per violare la loro comunicazione, ma non possono conoscere l'identità dell'altra parte, quindi un attacco man-in-the-middle è possibile: tutto l'attaccante ha fare è eseguire il protocollo di avvio della sessione con il client e il server in modo indipendente e da allora in poi i messaggi di inoltro (o meno).
Se una delle parti non è disposta a comunicare con chiunque, deve autenticare le altre parti. Esistono due metodi principali per eseguire questa operazione: con un segreto condiviso (una password) o con la crittografia a chiave pubblica. L'autenticazione della password non è semplice perché se ad es. il client invia la sua password al server, questo è pericoloso a meno che il client non sia sicuro che stia comunicando con il server legittimo. Altrimenti, in caso di un attacco man-in-the-middle, l'utente malintenzionato otterrebbe la password e potrebbe inviarlo in avanti al server per impersonare il client.
La crittografia a chiave pubblica risolve questo problema. Affinché il client possa autenticare il server, il client deve conoscere la chiave pubblica del server. Il client può inviare un messaggio crittografato con quella chiave pubblica; solo il server legittimo sarà in grado di decifrare il messaggio. Un semplice protocollo prevede che il client invii la sua password, oltre ad alcuni materiali chiave, in questo messaggio crittografato.
È possibile che entrambe le parti utilizzino una coppia di chiavi pubblica / privata. In questo caso, ciascuna parte avrà la propria chiave privata. Le chiavi private non vengono mai condivise tra le parti, altrimenti non sarebbe opportuno non utilizzare crittografie simmetriche.
Esercizi consigliati:
- Implementa quello che pensi sia un protocollo di canale sicuro.
- Una volta che la tua implementazione funziona, gioca con essa. Descrivi il tuo protocollo per iscritto o con diagrammi. Cerca di trovare una situazione in cui la tua implementazione si interrompa, in cui consente a terzi di intercettare le comunicazioni tra il client e il server, o di impersonare una delle parti, o di iniettare comandi o risposte illegittime. La crittografia è difficile, quindi non scoraggiarti se hai sbagliato: è quasi il punto dell'esercitazione.
- Si dice che chiunque possa costruire un protocollo crittografico che non possono rompere, se si sono sforzati abbastanza. Quindi se non riesci a rompere il tuo protocollo, consulta la documentazione su TLS , che è lo standard del settore per i canali sicuri . Trova una funzionalità in TLS che protegga da qualcosa che non lo fai. Scopri come rompere il tuo protocollo in questo modo.