Attacco man-in-the-middle su un canale criptato

2

Recentemente ho appreso degli attacchi man-in-the-middle e ho trovato questa domanda.

Diciamo che abbiamo due computer che provano a comunicare attraverso la rete. Ogni computer ha un crittografo e un decryptor. Supponiamo inoltre che il ciper utilizzato dai due computer sia infrangibile e che i computer utilizzino una chiave pre-condivisa.

Ad esempio, se inviamo pacchetti da un computer a un altro, verrà prima crittografato dal crittografo del primo computer e quindi decrittografato dal decodificatore dell'altro e così via.

È possibile un attacco man-in-the-middle qui? Se è così, come possiamo farlo? Considera il fatto che i dati sono crittografati su entrambi i lati.

Come possiamo proteggerci in questo caso? È possibile annusare i pacchetti su questa comunicazione in altri modi?

    
posta David 19.06.2013 - 22:54
fonte

1 risposta

9

Terminologia: un canale sicuro è un canale di comunicazione protetto contro attacchi man-in-the-middle e intercettazioni . La sola crittografia non rende un canale sicuro. Il modo semplice per stabilire un canale sicuro è utilizzare SSL / TLS . ma ci sono sottigliezze.

La crittografia del traffico è solo una parte della protezione contro gli attacchi man-in-the-middle. Ciò impedisce all'utente malintenzionato di decodificare il traffico, perché non conosce la chiave di decrittografia. Ciò impedisce inoltre al malintenzionato di iniettare traffico arbitrario, perché non conosce la chiave di crittografia.

Con la sola crittografia, il man-in-the-middle può iniettare un po ' traffico arrivando con un testo cifrato. Potrebbe non sapere quale sia il testo in chiaro, ma ciò può ancora causare problemi: il destinatario sta ricevendo dati confusi, che potrebbero anche far scattare un bug del parser. Un canale sicuro fornisce non solo la crittografia, ma l'autenticazione: una verifica che i dati provengano dalla fonte legittima.

Se il protocollo di comunicazione è basato sul pacchetto, ogni pacchetto deve avere un tag che indica chi lo ha inviato (in modo che l'attaccante non possa inviare il traffico da una parte a se stesso) e un qualche tipo di numero di sequenza (in modo che il l'attaccante non può inviare nuovamente un vecchio pacchetto, che ora potrebbe avere un effetto diverso).

Naturalmente, se l'attaccante può sopprimere il traffico oltre all'ascolto e all'iniezione, l'attaccante può interrompere la comunicazione tagliandola del tutto, riordinando i pacchetti, ecc. Riordinando i pacchetti può essere rilevato (e i pacchetti riordinati o scartati) da utilizzare correttamente i numeri di sequenza per autenticare la comunicazione (che è più strong dell'autenticazione di ogni singolo pacchetto). Nessuna quantità di crittografia rimuoverà la capacità dell'aggressore di bloccare tutto il traffico, se è in grado di eliminare i pacchetti. Hai bisogno di mezzi fisici: corrieri armati, trasmettitori radio più potenti dei disturbatori dell'avversario, ...

La crittografia potrebbe non garantire sempre che la comunicazione rimanga confidenziale. La comunicazione può consentire i canali laterali . In particolare, le dimensioni e i tempi dei pacchetti potrebbero rivelarsi rivelatori. Ad esempio:

  • Se il 5 giugno 1944 la BBC avesse improvvisamente trasmesso una raffica di messaggi in codice, ciò avrebbe indicato che c'era qualcosa in piedi, anche se i messaggi erano indecodificabili. Rimedio: invia sempre messaggi codificati e, se non hai nulla da inviare, invia messaggi casuali che non sono distinguibili dai messaggi utili.
  • La dimensione del messaggio potrebbe essere un'indicazione. Ad esempio, se gli ordini militari vengono inviati a un rnpwbhm anziché a un mcouzjooyb, si dovrebbe sapere che l'ambito è abbastanza importante da coinvolgere un capitano piuttosto che un tenente, anche se non si sarebbe stati in grado di decifrare il grado. Rimedio: utilizzare codici a lunghezza fissa per concetti correlati; dualmente, varia a caso la lunghezza di termini potenzialmente riconoscibili (ad esempio attraverso varianti di ortografia di nomi propri o più sistematicamente immondizia a lunghezza casuale). (Sia l'attacco che il rimedio che cito qui sono tratti da storie della seconda guerra mondiale, anche se non ho il riferimento a portata di mano.)
  • Il traffico vocale è particolarmente vulnerabile alla ricostruzione perché è tipicamente compresso e inviato in tempo reale. Il ritmo dei pacchetti da solo può essere sufficiente per ricostruire il linguaggio in condizioni di laboratorio. Rimedio: comprimi di meno e accetta più lag, ad esempio invia un pacchetto a dimensione fissa ogni N millisecondi.

Un'altra difficoltà con la protezione dagli attacchi man-in-the-middle è l'avvio della comunicazione. Con una chiave pre-condivisa, questo non è un problema, ma se le due parti non si conoscono in anticipo, l'autore dell'attacco potrebbe essere un vero e proprio man-in-the-middle: quando Alice tenta di stabilire un canale con Bob, Eve intercetta tutti i pacchetti e consente ad Alice di stabilire un canale con lei, quindi stabilisce un canale con Bob e inoltra il traffico o meno a suo piacimento. Questo è il motivo per cui SSL richiede una verifica del certificato: il client verifica che il canale che sta configurando sia sul server desiderato (e, facoltativamente, il server esegue la verifica simmetrica).

    
risposta data 19.06.2013 - 23:37
fonte