Actually, there are several attacks of a similar sort discussed in the paper that introduced KRACK, so they’re more properly known as the KRACK Attacks.

These KRACK attacks mean that most encrypted Wi-Fi networks are not as secure as you think.

KRACK works against networks using WPA and WPA2 encryption, which these days covers most wireless access points where encryption has been turned on.

An attacker in your midst (at least, within Wi-Fi range) could, in theory, sniff out at least some of the encrypted traffic sent to some of the computers in your organisation.

Even if an attacker can only “bleed off” small amounts of traffic, in dribs and drabs, the end result could be very serious.

(If you remember the Firesheep attack of 2010, just bled a few bytes of data when you connected to Facebook or Twitter was enough to let a crook clone your connection and access your account for as long as you stayed logged in.)

KRACK in a few words

KRACK is short for Key Reinstallation Attack, which is a curious name that probably leaves you as confused as we felt when we heard about it, so here’s our extremely simplified explanation of what happens (please note this explanation covers just one of numerous flavours of similar attack).

At various times during an encrypted wireless connection, you (the client) and the access point (the AP) need to agree on security keys.

To do so, a protocol known as the “four-way handshake” is used, which goes something like this:

(AP to client) Let’s agree on a session key. Here’s some one-time random data to help compute it.

(Client to AP) OK, here’s some one-time random data from me to use as well.

At this point, both sides can mix together the Wi-Fi network password (the so-called Pre-Shared Key or PSK) and the two random blobs of data to generate a one-time key for this session.

This avoids using the PSK directly in encrypting wireless data, and ensures a unique key for each session.

(AP to client) I’m confirming we’ve agreed on enough data to construct a key for this session.

(Client to AP) You’re right, we have.

The KRACK Attacks (with numerous variations) use the fact that although this four-way protocol was shown to be mathematically sound, it could be – and in many cases, was – implemented insecurely.

In particular, an attacker with a rogue access point that pretends to have the same network number (MAC address) as the real one can divert message 4 and prevent it reaching the real AP.

During this hiatus in the handshake, the client may already have started communicating with the AP, because the two sides already have a session key they can use, albeit that they haven’t finalised the handshake.

This means that the client will already be churning out cryptographic material, known as the keystream, to encrypt the data it transmits.

To ensure a keystream that never repeats, the client uses the session key plus a nonce, or “number used once”, to encrypt each network frame; the nonce is incremented after each frame so that the keystream is different each time.

As far as we can determine, all the KRACK attacks involve reused keystream material accessed by “rewinding” crypto settings and thus encrypting different data with the same keystream. If you know one set of data you can figure out the other – that’s the best case; some cases are worse than that because you can as good as take over the connection both ways.

Back to the handshake

At some point, the real AP will send another copy of message 3, possibly several times, until the rogue AP finally lets the message get through to the client.

The mathematical certainty in the protocol now meets cryptographic sloppiness in its implementation.

The client finalises the handshake at last, and resets its keystream by “reinstalling” the session key (thus the name of the attack), and resetting the nonce to what it was immediately after stage 2 of the handshake.

This means the keystream starts repeating itself – and re-using the keystream in a network encryption cipher of this sort is a big no-no.

If you know the contents of the network frames that were encrypted the first time, you can recover the keystream used to encrypt them; if you have the keystream from the first bunch of network frames, you can use it to decrypt the frames encrypted the second time when the keystream gets re-used.

Even if attackers are only able to recover a few frames of the data in any session, they still come out ahead.

Gold dust sounds less valuable than a gold ingot – but if you collect enough gold dust, you get to the same value in the end.

What to do

Changing your Wi-Fi password won’t help: this attack doesn’t recover the password (PSK) itself, but instead allows an attacker to decrypt some of the content of some sessions.

Changing routers probably won’t help either, because there are numerous variants of the KRACK Attacks that affect most Wi-Fi software implementations in most operating systems.

Here’s what you can do:

Until further notice, treat all Wi-Fi networks like coffee shops with open, unencrypted, wireless.

Stick to HTTPS websites so your web browsing is encrypted even if it travels over an unencrypted connection.

Consider using a VPN, which means that all your network traffic (not just your web browsing) is encrypted, from your laptop or mobile device to your home or work network, even if it travels over an unencrypted connection along the way.

Apply KRACK patches for your clients (and access points) as soon as they are available.

Simply put, if you ever use open Wi-Fi access points (or Wi-Fi access points where the password is widely known, e.g. printed on the menu or handed out by the barista), you are already living in a world where at least some of your network traffic could be sniffed out at will by anyone.

The precautions that you take in those cases – why not take them all the time?

If you always encrypt everything yourself, in a way that you get to choose and can control, you never have to worry what you might have forgotten about.

For most people, it’s bad but nowhere near as bad as it sounds at first.

As we mentioned in the article, if you’re in the habit of using Wi-Fi where there’s an access point that is open (unencrypted) or where there’s a Wi-Fi password that is essentially public knowledge (my favourite coffee shop in Oxford has the password chalked up on the wall behind the door) then you already have what amounts to a digital KRACK habit, because almoat anyone who wants to can snoop on your Wi-Fi traffic anyway.

So just pretend you’re on free Wi-Fi all the time – like you get at airports, on trains, and in shopping malls – and take the same precautions you would in those places. And once you’re used to those precautions (see above), just use them all the time, even after this bug is fixed.

You make the argument that “we’re all used to taking precautions on free Wi-Fi connections, so just make those precautions automatic no matter where you access Wi-Fi”. But you don’t really delineate what those precautions are– or should be. Since your assumption that “we already know/use these precautions” is false (at least in my case) then your reasoning is somewhat circular.
Wouldn’t it be more to the point to explain what those precautions should be? It would certainly help in my case! I mainly use a Wi-Fi connection from my (rural) home, and while that probably means I’m at lower risk for an attack of this nature (since I present less of a target-of-opportunity) it also means that I have no idea what precautions you’re talking about.

* Use a VPN back to a network you trust, e.g. work or home. (End-to-end encryption of all your network traffic.)

This keeps a wrapper of encryption between you and any prying eyes near the untrusted access point.

BTW there’s VPN software built into our free firewall downloads (see Free Tools links on this page) if you want to try out a VPN of your own. You’ll need a spare computer to run it on but you get a free non-commercial licence for everything, including email filtering, web filtering, VPN and more.

This is a channel M-i-t-M (man-in-the-middle) vulnerability.
To secure _your_ connection, only one side needs patched. So, patch your client/OS first, and _you_ are covered, even if the AP is not fixed.
For sites that offer wifi to guests…you know that most do not keep up-to-date with patches.
Businesses should update OS ASAP.
It’s going to be a while before vendors finish due diligence to release code updates to thousands of APs across dozens or hundreds of product SKUs.

Part of the testing is to see how badly one-time-key will break things like roaming and mesh interaction. Logic says, this means more drops than when the one-time-key was allowed to be used again during a attempted handshake.

At a minimum, at least one half (client or AP) needs to be patched per the paper:

“Do we now need WPA3?
No, luckily implementations can be patched in a backwards-compatible manner. This means a patched client can still communicate with an unpatched access point, and vice versa. In other words, a patched client or access points sends exactly the same handshake messages as before, and at exactly the same moments in time. However, the security updates will assure a key is only installed once, preventing our attacks. So again, update all your devices once security updates are available.”

As Chris points out later below, it seems that the paper author updated the FAQ I quoted from the site to encourage people to patch everything possible:
“Do we now need WPA3?
…However, the security updates will assure a key is only installed once, preventing our attack. So again, update all your devices once security updates are available. Finally, although an unpatched client can still connect to a patched AP, and vice versa, both the client and AP must be patched to defend against all attacks!”
Our enterprise wireless vendor referenced Wireless LAN Association’s blog that states 9 out of 10 vulnerabilities are client-side with “CVE-2017-13082 (accepting a retransmitted Fast BSS Transition Reassociation Request and reinstalling the pairwise key while processing it)” being the only infrastructure side vulnerability.
Kevin Beaumont of DoublePulsar is also of the opinion that “The attack realistically doesn’t work against Windows or iOS devices. The Group vuln is there, but it’s not near enough to actually do anything of interest.”

Yes – the bug is in how WPA and WPA2 are handled by many, if not most, Wi-Fi implementations. That includes the Wi-Fi support in your laptop, your phone, or in your router.

As others have noted already, if either end of any WPA/WPA2 wireless connection is patched, that connection is OK. So if your router vendor issues a firmware update, grab it because that will implicitly patch any device you subsequently connect to that access point.

No, luckily implementations can be patched in a backwards-compatible manner. [….] Finally, although an unpatched client can still connect to a patched AP, and vice versa, both the client and AP must be patched to defend against all attacks!

(Note to people: the above is a joke. WEP is an older protocol that has way more flaws than WPA/WPA2. WPS, I believe, has some sort of bad flaws too. I’m not sure because I’ve never actually had a router with a WPS button on it. Anyone wanting to use my WiFi has to type in a password like it’s the stone age or something.)

Heh, with a boastful name like Wired Equivalent Privacy you know it couldn’t stand for long. Way back in (2001?) a security consultant with a handheld scanner cracked our corporate WiFi, as if it were taped on the wall behind Prince William.BoopBeep (points to his screen)
“there’s your WiFi, there’s your password.”

Let’s suppose that there is a business that offers employees and guests access to a WiFi solution and the business fails to update the firmware on the wireless access point. If the wireless access point is compromised by the KRACK exploit, what are the exposures for the business and the users granted access to the wireless solution? My thoughts are that the compromise for the access point can lead to a compromise of the client system. This could set up the end user for credential theft leading to account takeover on financial and medical sites, compromise of personal email accounts on providers like GMail and MS Outlook, and since the user’s client machine has been compromised, the client could become an attack vector when trying to connect to the businesses internal network over VPN.
Am I too far off in my thinking here? We focus too much on the encrypted data streams sometimes. We need to have a better understanding on the impact of this vulnerability on the client endpoints and their future targets.

Given domestic routers are updated once in a blue moon (usually by buying a replacement) is the best defence (at least for desktops and laptops) an ethernet cable?

My router manufacturer says you are “are only affected when in bridge mode (which is not enabled by default and not used by most customers).”, and they don’t list my router as one of their affected products (is that because they consider it is out of support or genuinely unaffaected?).

As for the number of tablets/TVs/Cameras/Consoles floating around which never get updates, do we just severely limit what we do on them (i.e. nothing that requires a password like ecommerce and nothing that impacts privacy)?

If you’re worried and you are able to use wired ethernet, then the KRACK attacks simply don’t apply – these attacks require you to be using a WPA or WPA2 Wi-Fi connection. (I hardly ever use a cable these days, even to transfer files locally, but every time I do I remember why they call it “gigabit ethernet” and find myself saying, “Wow, that’s quick” :-)

What you have not been told about KRACK is that it’s a very hard way to crack a wifi network with WPA2.

The following all must be true for the wifi network to be vulnerable:

1. The wifi network must have two wifi access points (AP’s) with the same SSID across the system. And a client with access that jumps or roams between the access points on the wifi network/wifi mesh.
2. Both wifi access points/mesh must be vulnerable and the wifi client needs to be vulnerable.
3. The client must hop between the access points with the vulnerability with 802.11r fast roaming and the access points must support 802.11r.
3. Message 3 in the 4 way chain handshake, the nonce, must be forced to repeat when it hops.
4. The traffic across the wifi network must be monitored for an extended time and the traffic known or dictionary attacked, eg: plain text http traffic.
5. You must be in range of the wifi access points, and both must be jammed for the nonce to have any chance of being repeated on both wifi access points.
6. Both wifi access points must be connected by ethernet on the same network.
7. WPA2-AES/CCMP cannot be broken the key is not repeated at any stage, unless group key wifi access points are repeated first and then you may have an attack vector once in a blue moon.
8. You must know the MAC address of the vulnerable client itself. Putting 00:00:00:00:00 as the client MAC doesn’t work, the 4 way handshake is encrypted including the MAC.
9. The attacking system must have the same SSID and password as the vulnerability on the other wifi access points. And act as an wifi access point in its own right in range.

As the traffic is still encrypted with WPA2, even though you have got the nonce to repeat. The traffic then needs to be broken by doing a dictionary attack on a packet. Only a single packet of traffic will be revealed when a dictionary attack occurs successfully. One then needs to jam the nonce again on both access points to repeat, and start again with the dictionary attack. One cannot do a dictionary attack on encrypted traffic inside the WPA2 encryption, such as when using SSL/VPN traffic. Injecting traffic like malware is very hard, for the traffic needs to meet a checksum of every packet itself. And to make that hard the 4 way handshake is encrypted as well, and has a encrypted checksum. Point 9 must have been missed by researchers and the media alike, you need the password!

In figure 4 (see page 6 of 16 in the paper) I think it seems clear that you don’t need the PSK. The man-in-the-middle simply delays some messages and plays them back later on. So the MiTM doesn’t need the PSK, and doesn’t recover it, either (except in the case of some Android versions, where a bug in the “keystream reset” code causes the PSK to be changed to all zeros).

How about blackberry bb10 devices. Are they vulnerable too? A lot of these phones are still in circulation. I understand that if I updated my router if one is available for krack will be OK for home use but sometimes use public wifi if its available.