krackattacks: proofread of README.md

README.md

@@ -62,8 +62,6 @@ The suggested patch is to not reinstall any keys when receiving a retransmitting
 
 The basic idea behind the attack is shown in Figure 4 of the paper, and relies on our channel-based MitM attack. Summarized, the 4-way handshake starts normally, but the adversary does not forward message 4 of the 4-way handshake to the AP (stage 1). After some duration the AP will retransmit message 3, and the adversary forwards it to the client (stage 3). When the client process the retransmitted message 3, it will reinstall the PTK. As a result, the client (victim) will reuse packet numbers (nonces) when sending new data packets (stage 5). For more details see section 3.3 in the paper.
 
-The above attack assumes that the client still accepts plaintext EAPOL frames once the pairwise key (PTK) has been installed. For several implementations, this is not the case. Our paper contains two techniques to bypass this limitation (section 3.4 - figure 5 and 6). After writing the paper, we also found a technique to make Linux's hostapd send an encrypted retransmitted message 3. Therefore, even if an implementation only accepts encrypted retransmitted messages 3's, it is still exploitable in practice. Our technique to make Linux's hostapd send an encrypted version of message 3 will not be included in the current research paper (but it will be included in follow-up wor
-
 ### TPTK Construction
 
 Supplicants that use a TPTK construction generate a Temporal PTK (PTK) on the reception of message 1's, and try to verify the Message Integrity Code (MIC) of message 3 using *both* the TPTK and, if available, the currently installed PTK. If one of these two keys correctly verifies the MIC, the incoming message 3 is accepted. A supplicant using the TPTK construction may be vulnerable to the following attack, even when an attempt was made to patch it:
@@ -91,7 +89,7 @@ An attacker can trigger transmissions of group message 1 by blocking the arrival
 
 ### Attack and impact details
 
-The precise instantiation of our attack depends on the behavior of the AP. For simplicity, we assume the client (victim) is connected to an AP that uses Linux's widely used hostapd. Our attack in this case is illustrated in figure 8 of the paper. Notice that we again use a channel-based MitM attack. Summarized, the adversary blocks group message 2 from arriving at the AP (end of stage 1). The AP will then transmit a new group message 1 (stage 2). The adversary then forwards the previously blocked group message 2 to the AP (stage 3). This completes the group key handshake, making hostapd install the new group key (GTK) in stage 3. Now, the adversary can forward the retransmitted group message 1 to the client, making it reinstall the group key (stage 5). As a result, previously transmitted broadcast or multicast data (i.e. those transmitted in stage stage 4) can now be replayed towards the client (see stage 6).
+The precise instantiation of our attack depends on the behavior of the AP. For simplicity, we assume the client (victim) is connected to an AP that uses Linux's widely used hostapd. Our attack in this case is illustrated in figure 8 of the paper. Notice that we again use a channel-based MitM attack. Summarized, the adversary blocks group message 2 from arriving at the AP (end of stage 1). The AP will then transmit a new group message 1 (stage 2). The adversary then forwards the previously blocked group message 2 to the AP (stage 3). This completes the group key handshake, making hostapd install the new group key (GTK) in stage 3. Now, the adversary can forward the retransmitted group message 1 to the client, making it reinstall the group key (stage 5). As a result, previously transmitted broadcast or multicast data (i.e. those transmitted in stage 4) can now be replayed towards the client (see stage 6).
 
 Note that the group key handshake messages are unicast data frames and are encrypted using the pairwise key (e.g. using TKIP or CCMP). Even though they are encrypted, an attacker can identify these messages based on their length. Additionally, several APs send EAPOL-Key frames (i.e. handshake messages) using a non-zero Quality of Service (QoS) Traffic Identifier (TID). This is important because all clients must maintain a separate replay counter for each QoS TID (see for example 12.5.3.4.4b in the 802.11-2016 standard). Combined, this means that when we capture an encrypted group message 1 which uses a packet number of x, we can forward other encrypted data frames to the client, without affecting the attack. This is because other data frames generally use a different QoS TID. Therefore, the packet number (= replay counter) of the captured group message 2 will still accepted. Put differently, normal data frames use a QoS TID of zero, meaning they do not affect the replay counter associated to the QoS TID of EAPOL-Key frames. As a result, we can forward the group message 1 whenever we want, even after forwarding normal data frames to the client. This gives a high amount of flexibility to the attack, making it easy to execute the attack in practice.