# Is it possible to speed up WPA/WPA2-PSK cracking using a rogue AP?

We know that WPA/WPA2-PSK uses a PTK (Pairwise Transient Key) for each client to encrypt the communication. This PTK is generated through the process known as 4-way handshake. As told in the related page on Wikipedia:

The PTK is generated by concatenating the following attributes: PMK, AP nonce (ANonce), STA nonce (SNonce), AP MAC address, and STA MAC address. The product is then put through a cryptographic hash function.

So, if an attacker has the ability to setup a rogue AP (Access point) and make some clients automatically deauth & connect (especially mobile clients) to that rogue AP of his, can he gain some advantage to speed up calculations for cracking the PSK by introducing some specially generated inputs for example ANonce, AP MAC -the variables which he can control-?

We can assume that he has the chance to do this for some reasonable times such as 10. So he will obtain that number of 4-way handshakes which he used some specially selected inputs (similar to a chosen-plaintext attack). I wonder if there is some component in the design which will prevent that he gains some speed advantage by using a rogue AP rather than simply capturing the 4-way handshakes?

-
If the hash function used is any good and the attacker has no knowledge of the PMK (=PSK), there should be no way of doing this. – Paŭlo Ebermann Oct 30 '11 at 13:44
What I'm asking is exactly this, but I want a detailed and confident answer. – sanilunlu Oct 31 '11 at 3:56

## 2 Answers

The key derivation of the PTK is defined in section 8.5.1.2 of IEEE 802.11-2007, Figure 8-20 (page 198, which is page 247 in the PDF file):

``````PRF-X(PMK, "Pairwise key expansion",
Min(AA,SPA) || Max(AA,SPA) ||
Min(ANonce,SNonce) || Max(ANonce,SNonce))
``````

AA and SPA are the addresses of both communicating partners, ANonce and SNonce are the nonces sent by them.

`X` is the number of bits needed, and depending on the use, `X` is here either 384 or 512.

In the previous section 8.5.1.1, the PRF (pseudo-random function) is defined, and it is effectively

``````PRF-X(K, A, B) = HMAC-SHA-1(K, A || 0 || B || 1) ||
HMAC-SHA-1(K, A || 0 || B || 2) ||
...
``````

(with as many repetitions as needed to fill the needed number of bits, discarding the remaining ones.)

So the question effectively is: Can one attack HMAC-SHA-1 in a way that, knowing some of the input and choosing other parts of the input, but not knowing the key, one can (a) derive parts of the output, or (b) derive the key?

As far as is known, neither the HMAC construction nor the SHA-1 hash function has a weakness in this respect.

So the only currently known way to break this would be to brute-force the PSK (or the password from which it is derived), which would need not much more than one listened handshake, but lots of computation to find the key.

There is no realistic chance to break the 256-bit key, but one might find a password from which it is derived quite easier. So use a good password.

-
So we can't be sure without having a detailed inspection on the construction of PTK. Unless there is some chosen-plain-text attack on HMAC construction or SHA-1, we can't gain any thing further than brute force. – sanilunlu Oct 31 '11 at 20:13

If a user has connected before, their client should complain if the MAC address of the AP has changed and warn the user about connecting. Under windows it will forcibly append "2" to the ap name. This should reduce the likelihood of success. However, if the MAC address is the same, the client will have no way of knowing if the AP is rouge. This means that you could have a hard-coded `ANonce` value which would reduce the key space that has to be searched. If you where brute forcing the offset one handshake would reduce the number of permutations to the size of the SNonce.

-
For many clients let's say that MAC address change is not a problem or if we want to be strict we can just use only the `ANonce` value. Our aim is not to ensure that user won't notice the change and know about a rogue AP. Let's assume we've succeed to trick the user/device. That's not a problem I think. The problem is, if we change this value for a few times and recapture 4-way handshakes for each, would this information help us cracking the password? I am asking that is it's helpful to speedup the cracking phase, that could be integrated into tools such as aircrack-ng, cowpatty and pyrit. – sanilunlu Oct 29 '11 at 23:59
@sanilunlu Multiple captures would not speed up cracking unless there was a flaw in the underlining primitive. For instance the flaws in RC4 leading to the downfall of WEP. WPA2 uses AES which is significantly more secure. – rook Oct 30 '11 at 1:12
What I'm trying to learn is if someone knows there may be some weakness in the use of crypto (hashing alg., etc.), so we can gain more information about the key having captured different PTKs computed using different `ANonce`s. So we'll have for example 5 different PTK calculations which use 5 different `ANonce` values and same MACs, PMK but potentially different `SNonce`s as the inputs. Rather than having one capture of 4-way handshake, having for example 5 different captures constructed using attacker-chosen `ANonce`s. – sanilunlu Oct 31 '11 at 3:52
@sanilunlu I honestly don't see how that helps. At the end of the day you just have to iterate over that keyspace. – rook Oct 31 '11 at 5:26