Recently, Mathy Vanhoef from the University of Leuven published, with his supervisor Frank Piessens, a Key Re-initialisation Attack on WPA/WPA2.  This was significant because these standards are so widely used, and also because there were proofs of strength for the the protocol they attacked (in models which consequently are shown to be inadequate).

WPA and WPA2 are very similar, and each can use either Temporal Key Integrity Protocol (TKIP) or CCMP (CTR with CBC-MAC protocol) for data encryption/authentication. TKIP was included as way for older, insecure, WEP WiFi standard hardware to attain higher security levels, but AES-based CCMP is more secure, so for simplicity we'll assume that's being used in what follows.

In CCMP (Counter mode with Cipher block chaining with Message authentication code Protocol), AES-128 is used in counter mode for traffic encryption – a block cipher used as a stream cipher – with CBC MAC for data authentication, as defined in RFC 3610 (with M = 8, L = 2).  Each encrypted packet is accompanied by a 48-bit packet number PN, which is set to 1 for the first encrypted packet, and incremented by 1 for each encrypted packet until a new PTK is established using the 4-message protocol (see below).  The CCM nonce is constructed from PN and other data static from packet to packet.

Traffic keys for CCMP are established when a device connects to a WiFi access point (AP).  A four-message protocol is used, as defined in 802.11i-2004, and the messages are conveyed in EAPOL packets.  In the first, the AP sends the device a message containing a 256-bit value ANonce.  Then in the second, the device replies with a 256-bit value SNonce.  Both ends of the link compute a 376-bit “Pairwise Transient Key” PTK from a secret password (the WiFi key), the name of the network (SSID), ANonce and SNonce, and the MAC addresses of both AP and device.  This calculation starts by deriving an intermediate value PMK from the secret key using PBKDF2, an intentionally intensive calculation intended to provide some protection against password search.   Once computed, the PTK is split into 3 keys: 128-bit Key Confirmation Key KCK for authenticating messages 2-4, 128-bit Key Encryption Key KEK used for message 3 confidentiality, and 128-bit Temporal Key TK for encrypting and authenticating packet data.  Message 3, sent by the AP, conveys a group key for encryption of broadcast packets, and message 4 is sent by the device to tell the AP it is about to start using the new keys for packet encryption.  Messages 2-4 all incorporate a message integrity code, which both parties, now knowing the KCK, can compute/verify.  They also contain another counter to protect against replay: this counter is set to 0 when the device first associates with the AP, and is incremented by the AP for each EAPOL message it sends; the device replies to any AP message with the same counter value; and the counter is reset to 0 when a PTK is established.

If message 4 is not received by the AP, it will send a new message 3 to the device (with incremented counter); and whenever a device receives a valid message 3 the standard states that it should install the PTK established in messages 1 and 2 for encrypting subsequent 802.11 traffic packets.  The main observation the paper makes is that this is problematic, because the device might already have started using a new PTK, and if it is reinstalled, PN is reset to 1, resulting in repeated use of keystream potentially compromising the encryption, and susceptibility to replay attacks.

Having observed this, Vanhoef went on to examine what happens in WiFi client implementations.  He did this by implementing a Man-in-the-Middle attack, where the MitM presents an access point to the client on a different WiFi channel, with the same MAC address as the real AP.  This MitM can prevent message 4 from reaching the AP, and then delays the transmission of the new message 3 the AP generates.  He found that some devices (Windows 7, Windows 10, iOS 10.3.1) don't accept subsequent message 3 transmissions (in violation of the standard), others don't accept plaintext subsequent message 3 transmissions (OS X 10.9.5 and 10.12, Open BSD 6.1), but others do (wpa_supplicant 2.3 - 2.6, Android 6.0.1, MediaTek).  The authors also describe an attack on some systems that only accept encrypted message 3 transmissions.  In this case, message 3 is not passed on to the device until a second message 3 is generated by the AP, and then both passed on in close succession.  When the device receives the first it installs the new PTK, and uses it with PN=1 to encrypt message 4, but implementation delays may mean that the second message, encrypted under the old PTK, is also accepted; and then the next message the device sends will be encrypted under repeated keystream.

All the systems examined were also susceptible to re-initialisation attacks on the group key exchange protocol.  A Group Temporal Key (GTK), used instead of the TK to protect message broadcast by the AP to multiple devices, is first established using the 4-message handshake discussed above, but is then subsequently updated (e.g. every hour) in a Group Key Handshake.  To do this update, the AP sends the device a new GTK in an EAPOL packet, encrypted with the KEK and integrity-protected with the KCK, and the device replies with an integrity-protected EAPOL message to say that it is now using the new GTK with associated PN reset to 1.  In once variant of the attack, where the AP starts using the new GTK immediately, a MitM prevents the device's Group Handshake Message from reaching the AP; the AP then resends its handshake message with incremented EAPOL counter; finally, the MitM can replay this before an encrypted broadcast from the AP to cause PN to be reset again, compromising broadcast message protection – for example, previous broadcast message can be replayed.

Apparently the standards 802.11 standards are to be updated to prevent these attacks.