L'uomo nell'attacco intermedio è possibile in una tipica autenticazione basata su challenge-response? Per un riferimento tipico, è possibile consultare questo carta .
La mia domanda è che è possibile che un intruso agisca da server (possibilmente usando lo spoofing del DNS, per il client) e come client per il server e diventi l'uomo nel mezzo?
Non è possibile rispondere alla tua domanda senza ulteriori informazioni. "Challenge-response" è una tecnica generale. Esistono molti protocolli che incorporano una sorta di meccanismo di risposta alle sfide per uno scopo o per un altro. Alcuni di questi protocolli sono vulnerabili agli attacchi man-in-the-middle; alcuni non lo sono.
In generale, se l'autenticazione sfida-risposta è il meccanismo solo utilizzato per l'autenticazione, allora il protocollo rischia di essere vulnerabile agli attacchi man-in-the-middle. Ad esempio, un attacco contro semplici sistemi di risposta alle sfide consiste nell'attendere che i due endpoint legittimi finiscano la parte del protocollo relativa alla risposta alla sfida e, solo dopo averlo fatto, iniziare a manomettere il traffico.
In generale, per garantire la sicurezza contro un man-in-the-middle, è necessario un protocollo che fornisca un canale sicuro. Per la maggior parte degli scopi, raccomanderei semplicemente di utilizzare SSL / TLS. È ben studiato e può fornire una strong resistenza agli attacchi man-in-the-middle, se usato correttamente.
Aggiornamento (11/15) : ora sembra che tu stia chiedendo specificamente del documento a cui ti sei collegato, di Yang et al. Ecco la mia analisi:
Non consiglierei di utilizzare lo schema proposto in quel documento. Ho seri dubbi sulla sua sicurezza.
Il documento non fornisce un'analisi di sicurezza convincente. Gli standard accettati nel campo oggi richiedono una prova di sicurezza di qualsiasi nuovo protocollo crittografico proposto, o almeno un'analisi molto approfondita della sicurezza contro gli attacchi noti. La carta non offre né In altre parole, l'onere della prova è sul documento per fornire prove convincenti che la sua proposta è sicura. Credo che il documento non soddisfi questo onere.
@Thomas Pornin sottolinea che il protocollo in quel documento sarà debole per la maggior parte delle scelte dei parametri, o completamente insicuro per alcune scelte dei parametri. Thomas lo spiega bene: "Se la funzione di hash F ha un'uscita maggiore di p o della stessa dimensione, allora qualsiasi scambio intercettato fornisce un oracolo per un attacco di dizionario offline che può escludere la metà delle possibili password. g genera un sottogruppo più piccolo di ( p -1) / 2, quindi uno scambio intercettato fornisce un oracolo molto migliore per gli attacchi offline. In breve, imitano l'EKE ma lo fanno male. non utilizzare questo protocollo. "
Il foglio tenta di "reinventare la ruota". Ci sono soluzioni nella letteratura per esattamente il problema che pone la carta; sono chiamati protocolli di scambio di chiavi autenticati dalla password (PAKE). Il documento non sembra essere al corrente dell'intera estensione del precedente lavoro su PAKE che era stato fatto prima della pubblicazione.
Esistono diversi protocolli PAKE che sono stati ben controllati: se si desidera seguire l'approccio delineato nel documento, propongo di utilizzare un noto protocollo PAKE, non lo schema ad hoc presentato nel documento.
Inoltre, lo schema proposto potrebbe presentare una debolezza di sicurezza elementare, a seconda di come è integrato in SIP. Il documento non descrive cosa succede dopo che il protocollo è stato completato e ciascuna parte ha autenticato l'altro. Se a questo punto la connessione continua in testo non crittografato, allora c'è un semplice attacco man-in-the-middle: l'attaccante aspetta semplicemente fino a quando il protocollo di autenticazione è stato completato con successo (senza interferire con i passaggi di risposta alla richiesta), quindi manomette i messaggi inviati dopo che entrambi i lati si sono autenticati con successo. Il documento non chiarisce se o come questo attacco sia impedito.
Leggi altre domande sui tag attacks