In che modo WPA2-PSK impedisce la doppia password di phishing?

10

Diciamo che abbiamo un AP sicuro WPA2-PSK e ci sono diversi client come smartphone e notebook che si connettono automaticamente ad esso.
Ora se qualcuno doveva creare un altro AP che sembrava completamente uguale dall'esterno (stesso canale, stessa crittografia, stesso SSID, stesso BSSID ecc.), Ma con un segnale più strong. Sarebbe possibile che il software dietro l'AP raccolga le informazioni necessarie per autenticare l'AP originale semplicemente lasciando che i clienti provino ad autenticarsi con il gemello malvagio?

Da ciò che ho letto e sentito non è possibile. Ma non capisco davvero perché. Capisco che c'è una specie di stretta di mano che va avanti e indietro tra il client e l'AP durante il processo di autenticazione, ma se il gemello malvagio giocasse semplicemente l'uomo nel mezzo durante quel processo, non sarebbe in grado di ottenere il dati richiesti?

Suppongo che questa domanda debba essere già stata posta in precedenza e ho fatto del mio meglio per scoprire se lo fosse, ma non ho trovato nulla. Quindi ... mi scuso in anticipo se questo è un duplicato.

    
posta Forivin 17.01.2016 - 16:07
fonte

2 risposte

14

Nessuna password viene mai inviata durante l'handshake a 4 direzioni, quindi non può essere phishing.

Quando un client si connette a un punto di accesso (AP) utilizzando WPA2-PSK, la password o la chiave pre-condivisa (PSK) è, come suggerisce il nome, già nota a entrambe le parti. Quindi non è necessario sostituirlo di nuovo.

Non confondere questo con altri scenari in cui non è disponibile alcun segreto precondiviso. (Supponiamo che ti colleghi a un sito Web tramite SSL e che devi eseguire in anticipo uno scambio di chiavi Diffie-Hellman . )

In modo originale, il client e l'AP potrebbero semplicemente andare avanti e utilizzare la crittografia simmetrica (ad es. AES ) per comunicare in modo confidenziale. Utilizzerebbero il PSK come unica chiave di crittografia senza precedenti strette di mano o scambi di chiavi aggiuntivi. Tuttavia, questo approccio è errato poiché utilizza la stessa chiave per il messaggio evey e nessuna delle parti ha dovuto dimostrare la propria identità , aprendo così la porta per attacchi di rimandi , ecc.

Quindi, lo scopo dell'handshake a 4 vie non è quello di scambiare una passphrase, ma di dimostrare all'altra parte che conosci effettivamente il PSK (rispettivamente, un PMK che puoi considerare equivalente qui) e stabilire un tasto transitorio pairwise (PTK). Questo PTK combina le chiavi che verranno infine utilizzate per il trasferimento di dati crittografati effettivi.

La prova della conoscenza del PSK si verifica quando entrambe le parti lo utilizzano per generare un codice di integrità del messaggio (MIC) che verrà inviato insieme ai valori nonce casuali durante l'handshake. Pertanto, una stretta di mano tra il tuo gemello cattivo e un client legittimo sarebbe simile a questa:

  • Il tuo AP rogue genera un nonce casuale ( ANonce ) e lo invia al client.
  • Il client sceglie un nonce ( SNonce ) e ora è in grado di calcolare il PTK. Invia il nonce insieme a un MIC generato dal tasto.
  • Ora il tuo AP dovrà restituire una chiave temporale di gruppo (GTK) con un MIC corrispondente. Poiché non puoi generare il MIC senza conoscere il PSK, il cilent respingerà comunque la tua risposta e l'autenticazione fallirà.
risposta data 17.01.2016 - 22:44
fonte
1

Citazione della descrizione su Wikipedia :

The four-way handshake

The four-way handshake is designed so that the access point (or authenticator) and wireless client (or supplicant) can independently prove to each other that they know the PSK/PMK, without ever disclosing the key. Instead of disclosing the key, the access point & client each encrypt messages to each other—that can only be decrypted by using the PMK that they already share—and if decryption of the messages was successful, this proves knowledge of the PMK. The four-way handshake is critical for protection of the PMK from malicious access points—for example, an attacker's SSID impersonating a real access point—so that the client never has to tell the access point its PMK.

Quindi in pratica l'AP e il client non si dicono mai i dettagli sulla chiave, tranne che si dimostrano a vicenda entrambi lo sanno. Vedi anche Zero-knowledge password proof

    
risposta data 17.01.2016 - 22:01
fonte

Leggi altre domande sui tag