WPA3

Everyone is writing about the new WPA3 Wi-Fi security standard, and how it improves security over the current WPA2 standard.

This summary is as good as any other:

The first big new feature in WPA3 is protection against offline, password-guessing attacks. This is where an attacker captures data from your Wi-Fi stream, brings it back to a private computer, and guesses passwords over and over again until they find a match. With WPA3, attackers are only supposed to be able to make a single guess against that offline data before it becomes useless; they’ll instead have to interact with the live Wi-Fi device every time they want to make a guess. (And that’s harder since they need to be physically present, and devices can be set up to protect against repeat guesses.)

WPA3’s other major addition, as highlighted by the Alliance, is forward secrecy. This is a privacy feature that prevents older data from being compromised by a later attack. So if an attacker captures an encrypted Wi-Fi transmission, then cracks the password, they still won’t be able to read the older data—they’d only be able to see new information currently flowing over the network.

Note that we’re just getting the new standard this week. Actual devices that implement the standard are still months away.

Tags: , , ,

Posted on July 12, 2018 at 6:11 AM • 32 Comments

Comments

Aaron Kelley • July 12, 2018 7:00 AM

Any chance of existing devices being updated to support WPA3, via OS/driver/firmware updates? I know that many vendors would not bother to make the attempt, but some including the leading “mesh network” vendors roll out regular firmware updates with new features from time to time. It seems like it shouldn’t actually require new hardware in order to get up and running, but rather it could be implemented mostly in software?

M@ • July 12, 2018 7:31 AM

@Aaron Some of the recent gen gear will definitely update over firmware. I don’t want to plug any given vendor here, but there’s a good handful who are already cranking away on it. The same gear that is repeatedly compromised because no one ever updates it ever, however, will likely require hard changes, so get ready for your favorite blue-and-black-box vendors to try to sell you new hardware because they don’t invest in better software delivery.

stdpundit • July 12, 2018 8:15 AM

a large part of the WPA3 standard is the straight implementation of features present in the 2012 edition of the 802.11 Standard. Most notably, the first handshake is called SAE and has been introduced in 802.11s the year before. (The second handshake is ye good old KRACKed 4 way handshake).

wpa_supplicant and hostapd already support those things (which is logical, considering the maintainer contributes to the wi-fi and 802.11 standard), but your driver probably do not.

Pete • July 12, 2018 8:24 AM

Based on the history for all other standards, I’ll still be using a VPN even to connect to my home LAN from a wifi router I manage.

People are entirely too trusting of RF solutions. Add a VPN layer if you actually care about security.

Confused • July 12, 2018 10:08 AM

“With WPA3, attackers are only supposed to be able to make a single guess against that offline data before it becomes useless”

Can someone please explain to me how that works?

RealFakeNews • July 12, 2018 11:26 AM

From what I’ve heard about WPA3: it’s nothing special, and as written above, is a missed opportunity.

The whole thing needs re-working from scratch, and needs to get rid of all the junk that’s included.

Wardriver • July 12, 2018 2:32 PM

What @confused said.

There isn’t any way to do what they are advertising they can done regarding one-time password attempts without (a) making it impossible for the average user to use or (b) overstating how hard it is to crack.

“they’ll instead have to interact with the live Wi-Fi device every time they want to make a guess. (And that’s harder since they need to be physically present, and devices can be set up to protect against repeat guesses.)”

(a) Wait, what? I don’t know on anyone who cracks wifi passowrds without being physically present to the wifi stream. The average range of a home router in perfect conditions is about 100 yards. People are not capturing a signal, flying to another country, and then cracking it. Don’t be damn silly. They are sitting in their car with tinted windows down the block from your house…

(b) there is no way to limit repeated guesses for an attacker that don’t also limit repeated guesses for the legitimate end user. This sounds like a money-making scheme for the router industry to force people to throw their routers away every time they forget their password.

@refalfakenews “TL;DR: most of the new features and improvments are optional so most vendors will do the bare minum and place “wifi certified” over it.”

Of course they will be optional because the standard is security theater run amok.

Wardriver • July 12, 2018 2:50 PM

https://ieeexplore.ieee.org/document/4622764/

Here is the ieee paper about stopping off-line contradictory attacks. Honestly, I not enough of a crypto-geek to know if what they are talking about makes sense. But as an old wardriver I can’t see it interfering with the work. It seems to be intent of defeating a class of attacks that by and large are just not done (except maybe by script kiddies who have just found out about Kismet and Jack The Ripper.)

Mark • July 12, 2018 10:45 PM

The biggest change since ISPs started to ship routers with WPA2 enabled?

Honestly I view wireless security (WPA2 with a strong passphrase) as a solved problem, especially in corporate environments with user+certificate authentication.

Ross Snider • July 13, 2018 1:49 AM

Is the summary here that popular editorials have glossed over the controversial decisions of an NSA-backed standard?

The use of the dragonfly PAKE has significant disadvantages:
1. There are known timing side channels on the protocol which already defeat the password protection.
2. There are several known active attacks on the protocol which already defeat the password protection, some under the assumption of non-robust implementations and others unconditional properties of the protocol.
3. The implication of the protocol is that passwords must be stored in a format which make them brute forceable, again defeating the password protection.
4. The parameter negotiation can be used to force malicious parameters, which is even more dangerous given how the protocol can be initiated by any side.
5. The implementation of the crypto is fragile (easy to exclude checks which subvert the security of the scheme). It is not clear that the specification includes all checks necessary for a robust implementation.

This is on top of there being no formal security proofs and a lack of crypt-analysis, while there are other already standardized alternatives. To note that these protocols are typically very difficult to design.

I question the IETF’s decision, believe this standard to contain significant cryptographic weaknesses that probably amount to an NSA backdoor, and will attempt to use VPN over WPA3 wifi connections.

Some Guy • July 13, 2018 2:18 AM

@swr: Dragonfly caused some controversy in the IETF:

It’s not the protocol I’d have chosen. The author is a difficult person to work with and has a long history of trying to push his pet crypto projects through as standards despite multiple cryptographers pointing out problems with them, which he invariably perceives as some sort of personal attack on him rather than the genuine technical criticism which they are. It’ll be interesting to see whether further attacks on Dragonfly turn up in the future (I would say, yes, they will). It’d also be interesting to find out what sort of shenanigans went on for Dragonfly of all things to get adopted for WPA3 when there are so many other well-designed, heavily-analysed protocols around.

Weather • July 13, 2018 2:40 AM

Trying to understand this new standard, the router sends data to the client which then uses that to work out the key to use. Is that correct can’t you just bruteforce the data that the router sends that is used..
is the key worthless because it decrement a value making the key no longer valued??

RealFakeNews • July 13, 2018 6:04 AM

@Ross Snider: I thought that was the case but I wasn’t sure I was confusing it with something else.

I think it’s been debated here quite extensively in the Squid posts.

me • July 13, 2018 6:31 AM

@Wardriver
(a) Wait, what? I don’t know on anyone who cracks wifi passowrds without being physically present…People are not capturing a signal, flying to another country, and then cracking it.

You are wrong, that’s exactly what happens:
1-you go in range
2-you launch a deauthentication attack
3-you record the “login” handshake
4-you have everything you need, you can go offline or wherever you want.
5-you use one or more computers to try multiple passwords against the recorded handshake until you find one that match.
and people use amazon cloud computing to do that, or a desktop pc with multiple gpu.
they use it because is a super computer, quite faster than home pc.

in the new way you can’t record “something”, copy that “something” to 100 pc and use their full power to crack that “something”.
you will have to ask the router if your guess is right or not, and the router computing power is quite limited, and it can be set to answer only one question per second. so yes, it will prevent bruteforcing.

(b) there is no way to limit repeated guesses for an attacker that don’t also limit repeated guesses for the legitimate end user. This sounds like a money-making scheme for the router industry to force people to throw their routers away every time they forget their password.

true that it will limit legit users too, but you can allow say 10 times without any delay and after that enable the bruteforcing protection that answer only once per second (or slower).
this is a standard protection that every website uses and you never notice it.
user: one guess every 10 seconds (time needed to write the password)
attacker: 100 guess per second (automated)
while for the forgot password, well you can just reset the router.

654654108 • July 13, 2018 7:25 AM

@confused

Wi-fi password is not used to encrypt your transmisison, but only to connect your device and negotiate encryption between your device and router. You can’t use captured trafic to validate passwords you are trying. This was true in WPA2 as well, but WPA3 is doing better job in initial handshake, so you can’t get hold of password or encryption key (which is constatly changing) by capturing traffic.

Somewhat less confused now • July 13, 2018 8:09 AM

@654654108
Thanks for that explanation

If I understood you right then really they aren’t making “a single guess against that offline data” as previously stated at all, but submitting a password guess to the router then?

Dan Harkins • July 13, 2018 1:38 PM

@Some Guy, do I know you? Have we worked together? The things I
take as personal attacks are when people publicly accuse me of
being an NSA plant out to subvert the Internet (which someone did
both in email and in print). So yea, I take personal attacks as
if they’re personal attacks.

I’m not sure which “multiple cryptographers” you’re talking about.
Dragonfly got lots of comments, some from prominent cryptographers
and some of the comments were security critical. They were all
addressed. Dragonfly has been proven secure in the random oracle
model. It’s an unencumbered and proven secure protocol.

It’s a balanced PAKE though and that may not be the best thing for
some deployments. It is also susceptible to side channel attack if
the mitigation against it, which is well documented in the
specification, is not employed.

It was adopted by 802.11 for the mesh networking standard because
it’s unencumbered and balanced– it is a true peer-to-peer protocol
which is required for mesh. That was back in 2009 or so. There
has been plenty of time for someone (looking at you @Some Guy) to
specify a different PAKE for 802.11 but somehow no one did and
the “shenanigans” were basically to take the only thing in 802.11
that fixes the well-known flaws of WPA2-PSK and to certify it.
Sorry the story is such a boring let down… no shenanigans.

AlexT • July 13, 2018 2:37 PM

One thing that worries me is that this has been worked on without public scrutiny. They “just” came up with those standards… They might be well thought out (time will tell) but I can’t even get the full technical details. I’m out is not how good security is achieved.

Dan Harkins • July 14, 2018 12:19 PM

@Ross Snider

What do you mean “an NSA backed standard”? Can you please substantiate that statement?

Regarding the weaknesses of dragonfly:
1) there is one known side channel attack if one chooses to do the “hunting-and-pecking” version of PWE assignment. One could, alternatively, use any of the techniques in draft-sullivan-hash-to-curve that are not susceptible to side channel
attack. In any event, there is a mitigation against side channel attack in the
specification anyway so I don’t think this is an issue.
2) what are the “several known active attacks”? I’m very curious to learn of these.
3) not quite right. It’s a balanced PAKE so the implication is that the credential
is stored in a format that is directly usable by the protocol. Even asymmetric PAKEs
store a password-derived credential in a manner that is brute force-able. That’s
just the nature of the PAKE. If you have a better idea please describe it.
4) what malicious parameters are you talking about? Please let me know as this issue
should be addressed if it really is an issue.
5) what is the crypto fragility you are talking about? Validating received elements?
That is prudent for every protocol that does public key crypto. On the other hand,
if there’s some issue other than element verification then please do bring it to
my attention!

Can you please answer these questions? If you are talking about actual problems then
you should bring them to the attention of the industry. You know how to get in touch
with me if this forum is not appropriate.

In any event, use a VPN, yes! WPA3 only protects the air, nothing more.

Joao • July 16, 2018 9:12 AM

Idea to create a new wireless protocol and create a new certification program… call it “Advanced Wireless Security” or something else.

Simple improvements:
– All devices must have their own public/ private like the “M-511” elliptic curve (or some other, maybe one that already resists Quantum Computing attacks);
– The administrator/ proprietary must be able to change the public/ private keys (in all it’s equipment’s);
– Then it can request, optionally, if defined by the administrator/ proprietary, a password to provide also symmetric encryption;
– The public key must be broadcast to the air;
– The public key must be use to make the first encrypted and authenticate communication tunnel, and if any symmetric key (“password”) is also configured then it must create a new encrypted tunnel inside the previous. In both cases it also must create temporarily session keys that change at every new connection and also when it goes by a predetermined time (by default 60 minutes, but configurable).

This way the devices would refuse to connect to devices that don’t have the correct private key to the public key, would simply not work and even if the public key is defeated it still uses the symmetric encryption part if it is set. The session keys are used to prevent anyone from recording the data and then able to access the contents after breaking the public key and symmetric key, at least the data recorded until that time should not be easily converted into legible information.

To add the device it would need to be configured: could be by snapping a picture at some QR code; or adding the verification hash of the device it’s trying to connect (derived from the public key); or by accepting the certificate in the “air” after confirming the hash is the same as indicated by the provider of the infra-structure and then entering the password if necessary; or by adding a configuration file with those information’s; or by, optionally, pressing a key (when the administrator actives that option, to prevent not authorized persons from adding new devices) or by using the main configuration panel of the device to activate to then exchange the information using light waves (infra-red, laser or other technology) so that it can’t be so easily intercepted and interfered when not in direct line of sight… if the device can’t do any of that, it must not be used.

The device that provides the wireless connection to access the network must have the option to allow the administrator/ proprietary to just allow to connect devices that it wants, by adding the hashs of the their public keys.

Wireman • July 20, 2018 4:28 PM

@realfakenews : “The whole thing needs re-working from scratch, and needs to get rid of all the junk that’s included.”

All that junk is a problem because the default implementations of most WiFi stacks turn it all on. Recently recompiled my WPA2, and disabled 70% of the default=on options. So, the problem on the hardware side reflects back to the software side. Kind of a mess, which is why I recently bought a bunch of ethernet cable LOL …

justinacolmena • July 23, 2018 3:26 PM

Re: forward secrecy, PFS, “perfect” forward secrecy.

Now I’m sure Bruce has a very good technical definition of this concept in one of books, but some of the details are slipping my mind, and the explanations I see online or in later editions are failing to hold water.

I’m having a lot of trouble grasping this one, and it seems very important that encrypted data captured online cannot later be decrypted even if “Eve” obtains the original private keys.

There’s something just a little bit hazy about this concept, and the lack of PFS is a major disadvantage of PGP email encryption.

Vendors are just a little bit too coy with the technical explanations on this one, and I fear snake oil.

Dan Harkins • August 10, 2018 4:38 PM

So I reached out to Ross Snider at Oracle over his comments about SAE and whether
he can substantiate his accusations of:

  1. “several known active attacks on the protocol which already defeat the password protection”
  2. how “parameter negotiation can be used to force malicious parameters”
  3. how “[t]he implementation of the crypto is fragile”
  4. why he said there is no formal security proof when one does exist
  5. what are the “significant cryptographic weaknesses” this protocol has
  6. how weaknesses “probably amount to an NSA backdoor”

Each time I asked he merely replied, “I will attempt to find some time to look into this.” There’s been plenty of time and no response.

So he has time to make unsubstantiated comments and impugn the integrity of people
(e.g. claiming I made an “NSA backdoor” in my protocol) but does not have the time
to back up those statements.

This whole thread is somewhat comical in the shrouded accusations being made.
All the “junk that is included” needs to be removed but nothing specific is
mentioned. Statements about how the commenter is “not enough of a crypto-geek to
know if what they are talking about makes sense” but says he “can’t see it
interfering with [off-line dictionary attack] work.” Amazing. But that’s not all!
We also have someone who admits he has “a lot of trouble grasping [PFS]” and
how “There’s something just a little bit hazy about this concept” but is not one
to let that ignorance get in the way of making a pronouncement like “Vendors are
just a little bit too coy with the technical explanations on this one, and I fear
snake oil.” Yea, he doesn’t know what he’s talking about, doesn’t understand the
concepts, but that stop him from making the “snake oil” claim.

A bunch of people speaking with the air of authority but without the necessary
knowledge to back it up those statements. Sad.

ac • November 28, 2018 5:03 AM

“With WPA3, attackers are only supposed to be able to make a single guess against that offline data before it becomes useless”

My feel on this is that if I can’t understand how that is going to work, I’d prefer to use a huge key sent on another channel. I don’t understand why are encryption key lengths “bits” instead of megabytes. Someone explain that?

Christopher • April 13, 2019 1:18 AM

I think everybody’s focused on the wrong issue. The real questions I have are this:

Why don’t consumers get to choose the WiFi radio firmware for their router and the devices that connect to it?

Why can’t I choose which security protocols and encryption algorithms for my devices by installing whatever open source firmware that I wish?

Why must the software be so tightly bound to the hardware that runs it?

Imagine a world where the consumer actually gets to choose how their radios communicate with each other. Security concerns and conspiracy theories would virtually disappear over time. The most secure open source solutions would prevail by a simple function of it’s effectiveness to secure communications between devices.

The only problem I could ever see with a choice-based system is that of compatibility fragmentation which could easily be remedied by standardized fallback protocols and encryption algorithms.

1&1~=Umm • April 13, 2019 11:21 AM

@Christopher:

“Why can’t I choose which security protocols and encryption algorithms for my devices by installing whatever open source firmware that I wish?”

Because of ‘history’ in the telecoms industry.

Back when cellular phones were still ‘a brick in your coat pocket’ various people had ideas about what we now call ‘mobile broadband’. The problem they saw was the limited radius of coverage thus the massive cost of installing a vast network of ‘nano/pico-cells’ (think about every 100-200ft down a residential street).

So somebody came up with the idea of ‘Make the customer pay’ not just for the equipment, but runing costs as well…

So various ‘Cable/DSL-broadband’ packages were offered that included a subsidized WiFi router that had your private network and a public network. In return you got access to this public network (BT in the UK for instance still has something similar running with coffee shops and the like).

Thus for such a system to work everyones WiFi routers would have to work in exactly the same way… Which is why the standards were developed that way, and running anything other than the ‘standard’ protocols on the ‘Over The Air’ (OTA) interface is illegal in most parts of the world. But also as you go up the stack to atleast ‘level 3 routing’ it has to likewise be ‘standard’ for it to work… But other areas such as authentication also have to work all the way up the stack to the presentation level if not ‘user and managment’ levels as well.

However there is a flip side, as you probably know ‘security’ on WiFi right from day one with WEP has been thoroughly lamentable. In part it’s ‘industry vested interests’ but also the Intel and Law Authority agencies have always pushed for certain types of weaknesses that they can exploit, and this is still as true as it was back in the days when GSM A5 was chosen.

The thing to remember is running the highest level ‘communications security / encryption’ protocols serves you nothing, if third parties can get at the OS level without such security and ‘end run’ your applications. To easily get at the plaintext that appears below not just your application, but below your OS Kernel as well in the I/O drivers which often are never tested for security by those who write them… Thus it is with such ‘rotten foundations’ that the SigInt and LE agencies can worm their way in. But the SigInts prefer other ways when snooping on their fellow citizens for ‘collect it all’. For instance if they have ‘fritzed’ the application, protocols, or standards the apps use such that the get ‘covert side channel’ key leakage out on the network they don’t need to enter your network. They just need to access an ‘upstream router’ from you, that you can not see, but all your traffic goes through. Because it’s a lot more covert thus way less risky… Even if they do get caught most companies will look the other way rather than have the government put them out of business via tax audits and court action etc.

But as for the industries original plans to make you carry their costs, time and technology have a habit of making fools of us all…

3G onwards offered most of what people at the time wanted with mobile broadband and 4G/4G-LTE provides most of what people want and need now (and GPRS/EdGe/HSDP etc* still fill many many users such as smart meters and trafic light control needs). It’s currently doubtfull if 5G is going to do the same due to OTA spectrum interoperability issues. Basically your handset will only do 5G with your supplier so no 5G-Roaming, to do roaming your 5G handset will fall back to the current 4G-LTE or earlier protocols.

  • This page written around a decade ago gives you enough info on data mode speeds so you can follow up further,

https://m.clove.co.uk/help-guides/a-guide-to-cellular-mobile-technologies

Anonymous • December 5, 2020 3:51 PM

Broken!
https://www.youtube.com/watch?v=tRWMp3jXlRg
https://zaufanatrzeciastrona.pl/post/a-mialo-byc-tak-bezpiecznie-wpa3-dragonfly-dragonblood/

CERT ID #VU871675: Downgrade attack against WPA3-Transtition mode leading to dictionary attacks.
CERT ID #VU871675: Security group downgrade attack against WPA3’s Dragonfly handshake.
CVE-2019-9494: Timing-based side-channel attack against WPA3’s Dragonfly handshake.
CVE-2019-9494: Cache-based side-channel attack against WPA3’s Dragonfly handshake.
CERT ID #VU871675: Resource consumption attack (i.e. denial of service) against WPA3’s Dragonfly handshake.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.