metodo di crittografia contro l'uomo nell'attacco centrale

Question

metodo di crittografia contro l'uomo nell'attacco centrale

#1 da (9 voti)
#2 da (1 voti)

2

Diciamo che ci sono 3 computer: Alice, Bob, Carol. Carol è un fornitore di rete, quindi tutto, da Alice a Bob e viceversa, passa per Carol. Carol può modificare i messaggi tra Alice e Bob. Esiste un algoritmo o un metodo per la comunicazione sicura tra Alice e Bob, anche se Carol può modificare i pacchetti? Per Diffie-Hellman ho trovato questo :

Roughly speaking, the basic idea is as follows. Prior to execution of the protocol, the two parties Alice and Bob each obtain a public/private key pair and a certificate for the public key. During the protocol, Alice computes a signature on certain messages, covering the public value ga mod p. Bob proceeds in a similar way. Even though Carol is still able to intercept messages between Alice and Bob, she cannot forge signatures without Alice's private key and Bob's private key. Hence, the enhanced protocol defeats the man-in-the-middle attack.

Qualcuno può spiegare con un esempio?

Modifica: A è client e B è server, A utilizza login / password per l'autenticazione.

cryptography encryption man-in-the-middle

posta torayeff 07.10.2012 - 16:03

fonte

2 risposte

1

Risposta possibile: quando hai comunicato tramite connessione protetta come SSH, SCP, SFTP e simili, e finché la tua casella di linux (client) non viene compromessa, sei praticamente al sicuro dall'attacco "man in the middle". Il protocollo TLS / SSL è considerato sicuro. Certificato autofirmato se lo hai firmato da solo, anche questo è sicuro.

Vedi anche link

risposta data 07.10.2012 - 16:30

fonte

Leggi altre domande sui tag cryptography encryption man-in-the-middle

Come testare il mio anonimato? L'autenticazione della password peggiora la messaggistica firmata se eseguita su SSL?

score 9 · Accepted Answer

Hai bisogno di una definizione . Vale a dire, cos'è "Bob" secondo Alice? Se "Bob" è "chi risponde", allora Carol farebbe un bel Bob - in quel caso, non c'è un vero attacco, solo Alice che parla con "qualcuno" che sembra essere Carol.

Se è una nozione definita di Bobness che Alice può usare, allora ci sono algoritmi che si basano su questo. Ecco come funziona SSL . Immagina di essere Alice, Bob è un sito Web che conosci per nome (ad esempio "www.paypal.com"), e Carol è il tuo Evil ISP. Non vuoi parlare solo con qualcuno , vuoi parlare con un Bob / server specifico che ha un nome. I certificati a chiave pubblica possono utilizzare firme per darti una certa garanzia sull'associazione tra il nome (" Bob ", alias" www.paypal.com ") e una chiave pubblica: la garanzia fornita dall'intero sistema è che una determinata chiave pubblica è realmente" posseduta "da un'entità che porta il nome" www.paypal.com ", dove "possedere" significa "avere il controllo esclusivo della corrispondente chiave privata", e in un modo che Carol non può ottenere una garanzia simile.

Una volta che c'è una chiave pubblica del server conosciuto, lo scambio di chiavi può essere protetto contro MitM. Di nuovo, guarda come è fatto con SSL.

Nel caso dei certificati X.509, Alice deve avere una conoscenza a priori di una chiave pubblica dell'autorità di certificazione root (qui "trust anchor"). Per un altro modello, considera SSH . Qui, noi presumiamo che Alice potesse stabilire, ad un certo punto, una connessione senza Carol a Bob (o una connessione che Carol non si preoccupava di alterare). Quindi, Alice ricorda la chiave di Bob e la utilizza nuovamente per tutte le connessioni successive. Ecco come SSH di solito funziona: per la prima connessione, il client richiede conferma dell'utente esplicito, quindi memorizza la chiave pubblica nel file .ssh/known_hosts di Alice. Idealmente, per la prima conferma, Alice verificherà con un meccanismo fuori banda la chiave pubblica del server (la sua impronta digitale) prima di accettarla la prima volta (ad esempio effettuando una chiamata al server sysadmin e controllando con lui la chiave impronte digitali).