| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
In the context of the response to the KRACK vulnerability, it might be worth reviewing the following elements of the KRACK paper (my emphasis), https://papers.mathyvanhoef.com/ccs2017.pdf , if this has not already been done: First, the entity implementing the data-confidentiality protocol should check whether an already-in-use key is being installed. If so, it should not reset associated nonces and replay counters. This prevents our attacks, at least if an adversary cannot temporarily trick an implementation into installing a different (old) key before reinstalling the current one. In particular, when using this countermeasure
it is essential that the replay counter of received group key handshake messages only increases. Otherwise, an adversary can use an old group message 1 to make a victim temporarily install an old (different) key, to subsequently reinstall the current group key using a more recent group message 1. A second solution is to assure that a particular key is only in- stalled once into the entity implementing the data-confidentiality protocol during a handshake execution. For example, the generated session key in a 4-way handshake should only be installed once. When the client receives a retransmitted message 3, it should reply, but not reinstall the session key. This
can be accomplished by adding a boolean variable to the state machine of Figure 3. It is initialized to false, and set to true when generating a fresh PTK in PTK-START. If the boolean is true when entering PTK-DONE, the PTK is installed and the boolean is set to false. If the boolean is false when entering PTK-DONE, installation of the PTK is skipped When GCMP is used, the impact is catastrophic. First, it is possible to replay and decrypt packets. Additionally, it is possible to recover the authentication key [43], which in GCMP is used to protect both communication directions (recall Section 2.4). Therefore, unlike with TKIP, an adversary can forge packets in both directions. Given that GCMP is expected to be adopted at a high rate in the next few years under the WiGig name [58], this is a worrying situation […] with GCMP the authentication key can be recovered in case of nonce recuse, while this is not so for CCMP. More generally, a nonce misuse-resistant encryption scheme should be used, examples being AES-SIV, GCM-SIV, or HS1-SIV [16]. when attacking the 4-way handshake in Section 3.3, we observed that
the 802.11 standard is ambiguous as to which replay counter values should be accepted. A more precise or formal specification would avoid any such potential incorrect interpretations. […] 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 [1, §12.7.6.5]: “On reception of message 4, the Authenticator verifies that the Key Replay Counter field value is one that it used on this 4-way handshake.” In practice, we found that several APs indeed accept an older replay counter. More precisely, some APs accept replay counters that were used in a message to the client, but were not yet used in a reply from the client (see column 2 in Table 2 on page 8). These APs will accept the older unencrypted message 4, which has the replay counter r+1
in Figure 4. As a result, these AP will install the PTK, and will start sending encrypted unicast data frames to the client. the
model of the 4-way handshake used in formal proofs did not fully reflect reality. This is because it did not define when the negotiated session key should be installed. As a result, there was no guarantee that a session key is installed just once. the 14-year-old 4-way handshake is vulnerable to key reinstallation attacks. Moreover,
this flaw is not just present in implementations, but in the protocol specification (standard) itself. The 802.11 standard
says that a retransmitted message 4 must be sent in plaintext in the initial 4-way handshake [1, §12.7.6.5],
but nearly all clients send it using encryption Thanks, Mark -- Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From: Dorothy Stanley [mailto:dstanley1389@xxxxxxxxx]
--- This message came from the IEEE 802.11 Working Group Reflector ---
All, A revised TGmd agenda is available, see
https://mentor.ieee.org/802.11/dcn/17/11-17-1556-01-000m-november-2017-tgmd-agenda.pptx . Please note: proposed Wednesday PM1 motions, see
https://mentor.ieee.org/802.11/dcn/17/11-17-0989-05-000m-resolutions-for-obsolete-and-repace-comments-d0-1.docx, for –CID 60 PCO Phased co-existence operation
–CID 66 Strictly Ordered Service Class
Thanks, Dorothy ---------------------- dorothy.stanley@xxxxxxx _______________________________________________________________________________
If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.
Instead, go to
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.
If there is no LEAVE button here, try
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO. Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand. SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button. Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________ |