2

When a client is forced to reinstall the key and to reset the nonce and the replay counter, what does it imply for the future communication between the client and the AP? There's a adversary in the MITM position who now can decrypt packets, but I'm thinking if the client can still communicate with the AP (and with the internet) provided that adversary forwards packets in both directions.

As I understand it, the AP's replay counter won't be reseted, and therefore it will refuse any packets with number lower than its replay counter. Also AP will assume that it is receiving data encrypted with keystream from nonce X, but because of the attack and the client's nonce reset, it will receive data encrypted with keystream from nonce 0.

0

The KRACK paper states:

We first establish a man-in-the-middle (MitM) position between the supplicant and authenticator.

And:

A second minor obstacle is that we must obtain a MitM position between the client and AP. This is not possible by setting up a rouge AP with a different MAC address, and then forwarding packets between the real AP and client. Recall from Section 2.3 that the session key is based on the MAC addresses of the client and AP, meaning both would derive a different key, causing the handshake and attack to fail. Instead, we employ a channel-based MitM attack, where the AP is cloned on a different channel with the same MAC address as the targeted AP. This assures the client and AP derive the same session key.

(Emphasis mine)

From what that section of the paper says, there is a MITM between the supplicant (client) and the authenticator (AP). Furthermore, there is a diagram on the paper (page 6) which shows the MITM connection involving the supplicant, adversary and authenticator:

MITM Diagram

The paper also mentions how the authenticator will accept any replay counter:

However, a careful inspection of the 802.11 standard reveals that the authenticator may accept any replay counter that was used in the 4-way handshake, not only the latest one.

  • According to the paper, authenticator may accept any replay counter used in the 4-way handshake, but not in data packets. For example, in the diagram above, authenticator receives Enc(2)(ptk){Msg4(r+2)} and then Enc(1)(ptk){Data}. It receives packet with nonce 1 after packet with nonce 2. Should't this cause problems? – Jan Luxemburk Oct 17 '17 at 19:16
  • I believe this is because some APs accept an older replay counter which was used in a message to the client, but not used as a reply from the client to the AP. In the diagram above that's exactly what is happening - replay counter r + 1 is sent from the AP to client, but not sent back to the AP from the client so that older replay counter can be used. – Joe Oct 17 '17 at 19:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.