The study of "KRACK"

10月 18, 2017

The study of "KRACK"

Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2

All protected Wi-Fi networks use the 4-way handshake to generate a fresh session key.
The 4-way handshake provides mutual authentication and session key agreement.

When a client joins a network, it executes the 4-way handshake to negotiate a fresh session key.
It will install this key after receiving message 3 of the handshake.
Once the key is installed, it will be used to encrypt normal data frames using a data-confidentiality protocol.

The Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment.
As a result, the client may receive message 3 multiple times.
Each time it receives this message, it will reinstall the same session key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the data confidentiality protocol.

wpa_supplicant, a Wi-Fi client commonly used on Linux, it will install an all-zero encryption key instead of reinstalling the real key.

To summarize, KRACK

introduce key reinstallation attacks
show that the 4-way handshake, PeerKey handshake, group key handshake, and fast BSS transition handshake are vulnerable to key reinstallation attacks.

Background

The RSNA PSK consistes of 256 bits or 64 bits in hex, it is difficult for a user to input 64 hex characters correctly.
A pass-phrase-to-PSK mapping uses the PBKDF2 method from PKCS:


    PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256)

802.11i defines the 4-way handshake, and two data-confidentiality and integrity protocols called (WPA-)TKIP and (AES-)CCMP.
Both WPA and WPA2 are based on 802.11i, they are almost identical on a technical level. The main difference is that WPA2 mandates support for the more secure CCMP, and optionally allows TKIP, while the reverse is true for WPA.

The 4-way handshake provides mutual authentication based on a shared secret called the Pairwise Master Key (PMK), and negotiates a fresh session key called the Pairwise Transient Key (PTK).

The PMK may be obtained directly from a Preshared Key(PSK) derived from a pre-shared password in a personal network or be negotiated using an 802.1x EAP method in an enterprise network.

The 4-way handshake confirms the possession of PMK.

The fresh session key PTK is derived from :

the PMK
Authenticator Nonce (ANonce)
Supplicant Nonce (SNonce)
the MAC addresses of both the supplicant and authenticator

Once PTK is generated, the PTK is split into:

a Key Confirmation Key (KCK)
Key Encryption Key (KEK)
Temporal Key (TK)

The KCK and KEK are used to protect handshake messages, while the TK is used to protect normal data frames with a data-confidentiality protocol. If WPA2 is used, the 4-way handshake also transports the current Group Temporal Key (GTK) to the supplicant.

Mater keys are not used to encrypt data, but rather to produce encryption keys ( called "temporal keys") that are used to encrypt data.
PTKs are used to encrypt unicast data between a STA and an AP, GTKs are used to encrypt broadcast/multicast data between a STA and an AP.

Every message in the 4-way handshake is defined using EAPOL frames.
The bit and octet convention for fields in the EAPOL-Key frame are defined in IEEE 802.1X-2001 "7.1:

The "replay counter" field is used to detect replayed frames. The authenticator always increments the replay counter after transmitting a frame. When the supplicant replies to an EAPOL frame of the authenticator, it uses the same replay counter as the one in the EAPOL frame it is responding to.

We use the following notation:


    MsgN(r, Nonce; GTK)

It represents message N of the 4-way handshake, having a replay counter of r , and with the given nonce (if present). All parameters after the semicolon are stored in the key data field, and hence are encrypted using the KEK.

The authenticator initiates the 4-way handshake by sending message 1. It contains the ANonce, and is the only EAPOL message that is not protected by a MIC. On reception of this message, the supplicant generates the SNonce and derives the PTK (i.e., the session key).
The supplicant then sends the SNonce to the authenticator in message 2.
Once the authenticator learns the SNonce, it also derives the PTK, and sends the group key (GTK) to the supplicant.
Finally, to finalize the handshake, the supplicant replies with message 4 and after that installs the PTK and GTK. After receiving this message, the authenticator also installs the PTK (the GTK is installed when the AP is started).

In an existing connection, the PTK can be refreshed by initiating a new 4-way handshake. During this rekey, all 4-way handshake messages are encrypted by the data-confidentiality protocol using the current PTK.

The 802.11i amendment defines two data-confidentiality protocols: Temporal Key Integrity Protocol (TKIP) and (AES-)CCMP.

To denote that a frame is encrypted and authenticated using a data-confidentiality protocol, we use the following notation:


    Enc(n, k) {·}

Here n denotes the nonce being used (and thus also the replay counter).
The parameter k denotes the key, which is the PTK (session key) for unicast traffic, the GTK (group key) for group-addressed traffic ( broadcast and multicast frames).

The authenticator periodically refreshes the group key, and distributes this new group key to all clients using the group key handshake.

The authenticator initiates the handshake by sending a group message 1 to all clients. The supplicant acknowledges the receipt of the new group key by reply- ing with group message 2. Depending on the implementation, the authenticator installs the GTK either after sending group message 1, or after receiving a reply from all connected clients.

If a client transmits a broadcast or multicast frame, she first sends it as a unicast frame to the AP. The AP then encrypts the frame using the group key, and broadcasts it to all clients. This assures all clients within the range of the AP receive the frame.

ATTACKING THE 4-WAY HANDSHAKE

802.11i states that the AP retransmits message 1 or 3 if it did not receive a reply.

8.5.3.5 4-Way implementation considerations

If the Authenticator does not receive a reply to its messages, it shall attempt dottRSNAConfigPairwiseUpdateCount transmits of the message, plus a final timeout.

Because the supplicant still accepts retransmissions of message 3, even when it is in the PTK-DONE state, we can force a reinstallation of the PTK.

Establish a man-in-the-middle (MitM) position between the supplicant and authenticator
We use this MitM position to trigger retransmissions of message 3 by preventing message 4 from arriving at the authenticator.
Authenticator will retransmit message 3, which causes the supplicant to reinstall an already-in-use PTK. In turn, this resets the nonce being used by the data-confidentiality protocol.

This attack is based on that the client (victim) accepts plaintext retransmissions of message 3.
In practice, there are some obstacles:

Not all supplicants accept the retransmission of message 3. These implementations are not vulnerable to this key reinstallation attack against the 4-way handshake.
This used a channel-based MitM attack which MitM is the AP 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.
Certain implementations only accept frames protected using the data-confidentiality protocol once a PTK has been installed. This means the retransmitted message will be ignored by the supplicant because the authenticator will retransmit message 3 without encryption.

Advanced Wi-Fi Attacks Using Commodity Hardware

In this section we present a man-in-the-middle attack on WPA1/2 secured networks. Our goal is not to decrypt traffic, but to reliable intercept and manipulate it.

Clone the AP on a different channel and forward all traffic to the real AP. This requires two Wi-Fi dongles: one operating on the channel of the real AP, and one cloning the AP on a different channel.
We continuously jam the channel of the real AP. This forces the clients to switch to our channel and connect to our rogue AP.
Once the clients have switched, we can stop the jammer, and start forwarding frames between the clients and the real AP

A command-line tool is implemented to allows a user to:

specify which AP to clone
whether to jam the channel of the real AP until clients connect to our AP/li>
whether to write all intercepted traffic to file

The WiFi driver is modified so injected frames are retransmitted in case of failure. Experiment equipments:

victim: a Latitude E6500 running Linux 3.7.2
AP: a Linksys WAG320N
attack machine: a VMWare player instance

intercepter: WiFi USB dongle(TL-WN722N)
forwarder: WiFi USB dongle(WNDA3200)
jammer: WiFi USB dongle(AWUS036nha)

Plaintext Retransmission of message 3

If the victim still accepts plaintext retransmissions of message 3 after installing the session key,

stage 1
stage 2
stage 3

搜尋此網誌

I'm Jay's father