How does WPA2-PSK prevent evil twin password phishing?

Question

Let's say we have a WPA2-PSK secured AP and there are several clients like smartphones and notebooks that automatically connect to it.
Now if someone was to create another AP that looked completely the same from the outside (same channel, same encryption, same SSID, same BSSID etc.), but with a way stronger signal. Would it be possible for the software behind the AP to gather the information required to authenticate to the original AP just by letting clients try to authenticate to the evil twin?

From what I read and heard it is impossible, but I don't really understand why. I understand there is some kind of handshake going back and forth between the client and the AP during the authentication process, but if the evil twin would simply play the man in the middle during that process, wouldn't it be able to get the the required data?

Answer 1

No password is ever sent during the 4-way handshake, therefore it cannot be phished.

When a client connects to an access point (AP) using WPA2-PSK, the password or pre-shared key (PSK) is, as the name suggests, already known by both parties. So there is no need to exchange it again.

Do not confuse this with other scenarios where no pre-shared secret is available. (Say, you're connecting to a website via SSL and need to perform a Diffie-Hellman key exchange beforehand.)

Naively, the client and AP could simply go along and use symmetric encryption (e.g. AES) to communicate confidentially. They would use the PSK as the only encryption key without any preceding handshakes or additional key exchanges. However, this approach is flawed since it uses the same key for evey message and neither party had to prove its identity, thus opening the door for replay attacks, etc.

So, the purpose of the 4-way handshake is not to exchange a passphrase, but to prove to the other party that you actually know the PSK (respectively, a PMK which you can consider equivalent here) and establish a pairwise transient key (PTK). This PTK combines the keys that will be finally used for the actual encrypted data transfer.

The proof of knowing the PSK happens when both parties use it to generate a message integrity code (MIC) that will be sent along with the random nonce values during the handshake. Therefore, a handshake between your evil twin and a legitimate client would look like this:

• Your rogue AP generates a random nonce (ANonce) and sends it to the client.
• The client chooses a nonce (SNonce) and is now able to compute the PTK. It sends the nonce along with a MIC generated from the key.
• Now your AP has to send back a group temporal key (GTK) with the corresponding MIC. Since you can't generate the MIC without knowing the PSK, the client will reject your response and the authentication fails.

Answer 2

Quoting the description on 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.

So basically the AP and the client never tell each other any details about the key except that they prove each other both of them knows it. See also Zero-knowledge password proof