Hacker News new | past | comments | ask | show | jobs | submit login
Wi-Fi Alliance Introduces Wi-Fi Certified WPA3 Security (wi-fi.org)
276 points by nikolay on June 26, 2018 | hide | past | favorite | 81 comments

I'm not optimistic. I believe that the underlying crypto protocol is this:


It's "secure authentication of equals", which is a protocol that kind of looks like it's trying to be a PAKE (Password Authenticated Key Exchange), but the paper does not mention PAKE anywhere in its abstract, and I'm not at all confident that SAE's design or analysis takes into account the properties that PAKE protocols should have.

I think that the original WPA key exchange was supposed to use the SRP protocol, which is a PAKE, but that was dropped due to patent issues. Since then, as I understand it, quite a few very nice PAKE protocols have had their patents expire, so I don't see what the problem is now.

So color me extremely skeptical.

That's a Dan Harkins protocol; Harkins is a little notorious for Dragonfly, a PAKE he tried to get "approved" by IETF CFRG before being slagged by Trevor Perrin†, who wrote up a particularly simple and nasty side channel attack on the elliptic curve point generation technique Dragonfly used. SAE includes what looks like the same "hunt-and-peck" point generator.



All I ever read about the Dragonfly PAKE was trevp taking it apart on CFRG, but from a quick skim of this paper and the IETF draft Harkins wrote for Dragonfly, this looks like it's just an instantiation of Dragonfly.

That would be pretty funny.

What is it about WiFi security that makes it such a backwater?

> What is it about WiFi security that makes it such a backwater?

The fact that the specs are developed behind closed doors in pay-to-play venues? At least, IME, there's a pretty strong correlation between specs developed behind closed doors and bad specs.

This reminds me that not all of the attacks we know on WEP now was known when TKIP was developed in 2001-2002. The worst is probably the WPS debacle though.

Would WiFi be better if we treated it like the bus it is instead of treatining like it's switched.

I'd note that the circumstances surrounding Dragonfly have been controversial, and it did end up being RFC 7664




There is plenty of more discussion on IETF mailing lists (and probably elsewhere too). Ultimately on a glance I can't say how trustworthy Dragonfly is because of the controversy. Perrin has obvious strong dislike for it, but that alone is not yet the end of the world.

Good references, thanks. Some highlights of one:


"I'd like to request the removal of Kevin Igoe from CFRG co-chair."

"Twice Kevin suggested a technique for deriving the Dragonfly password-based element which would make the protocol easy to break [IGOE_1, IGOE_2]. He also endorsed an ineffective attempt to avoid timing attacks by adding extra iterations to one of the loops [IGOE_3, IGOE_4]."

Note that Kevin Igoe's mail address is "at nsa.gov" and all the quoted "accidents" happened before Snowden disclosures (which were in the Summer of 2013).

> Probably nobody is ever going to use Dragonfly in the real world

Oh, the optimism :)

It does indeed seem to be DRAGONFLY (I'd heard rumours indicating such in advance): a surprising choice for an interactive protocol with attacker-observable timings, I felt, given its already chequered reputation?

I couldn't possibly speculate as to why, but one does feel inclined to agree that the people behind wireless LAN security haven't always generally chosen high quality methods in the past, and this feels to me like it could well be a continuation of that pattern.

I tried to read the device provisioning protocol. To read it, I would need to fill out a form to ask for permission and to agree to some contract. No thanks.

Given that “easy connect” seems to require no UI at all on the IoT device, I suspect it’s vulnerable to fairly trivial to reassociate a victim device to a rogue network, and it may be impossible to defend against at attacker who has ever seen the QR code without replacing the device outright.

The right way to do this is probably to arrange for IoT wireless clients to each get its own private VLAN and to have no ability to engage in any communication other than bandwidth-limited device-initiated traffic to the public Internet.

It seems Dan Harkins (as Daniel) is also in the group of inventors applying for some possibly relevant patents:


This one is granted:


"Original Assignee Aruba Networks Inc"

"Current Assignee Hewlett-Packard Enterprise Development LP"

He co-authored a blog post about the WPA3(TM):


I don't think I've ever heard cryptosecurity disputes being described in such a...visceral manner.

Mincing words isn't a good idea for this sort of thing. This is becoming a standard that will be used to protect the data of a billion+ users over time as devices get upgraded.

Visceral would be 'fetid pile of maggot-ridden pig intestines'. 'Backwater' is practically bucolic.

I assumed they were referring to Trevor's IETF posts; the Igoe and Dragonfly comments he posted are about as intemperate as I've ever seen him, in any venue. He is not an angry dude.

Oh! I only read the first thing you linked at first so maybe misunderstood. It does heat up a bit after but only seems 'visceral' in the way showing a bit of ankle is 'racy'. Then again, I don't know anything about the civility baseline of the list or people involved.

I mean, if you want visceral, there is this shameful email from Dan Harkins:


I didn't really follow it very far, I did notice Dan Harkins quickly got assholier-than-thou. But there's no shortage of crypto or general tech talk that is worse.

"such a backwater"

After some years staring at this I've decided everything looks this way if you're used to the Web PKI. I tried very hard at first to assume that the PCI SSC, the EMV group, Wi-Fi Alliance and suchlike are doing great work but it's behind closed doors and so invisible to me. That theory has been challenged so thoroughly that I feel compelled to reject it.

Four things that stick in my mind in no particular order in relation to this realisation:

1. Peter Gutmann's out of the blue attack on ACME when it was relatively young. Gutmann's SCEP doesn't solve the problem, and at first my assumption was that he just needed to have that explained. After a while I realised that SCEP's success depends up not understanding what the real problem is, and SCEP is widely deployed outside the Web PKI largely _because_ choosing not to understand the problem suits those applications perfectly well. ACME can't displace SCEP in such applications but its existence might cause people to ask uncomfortable questions and perhaps Peter would (unconsciously?) rather that didn't happen.

2. Eric Rescorla's explanation of what a great environment HTTP (and particularly web browsers) is for a cryptographic adversary. In the literature imaginary bad guys often get to watch one party do a million message/reply back and forths, time them accurately and then send a million bytes of nonsense data to the target as setup for their attack, and in many applications this would be ludicrous in practice, the target would obviously react, how could you do cause anyone to send so many messages without attracting notice, let alone time them? So the attacks seem just theoretical. But on the web you can just write some Javascript and victims will happily run it for you on their computers.

3. Dean Coclin of Symantec and eventually the various banks/ payment providers etcetera that had hidden behind Symantec explaining that such institutions really _needed_ security, unlike mere cat blogs and search engines, but of course they couldn't be expected to react to notice of serious issues with an obsolete hash algorithm in a timely fashion, and so surely they ought to get an extra year or five to upgrade from SHA-1, and if they didn't there'd be dire consequences.

4. ETSI's work on the "Middlebox Security Protocol" aka ETSI TS 103 523. Obviously most of this happens out of view, so we have no idea if there's something productive being discussed - but they kindly (?) shared their work in progress documents with outsiders including the TLS Working Group and er... yuck. I mean... see for yourself:


Looks like 802.11s dates before that post.

Agreed. I'm worried SAE hasn't received as much peer review as other PAKE protocols.

IMHO they should have gone with J-PAKE (https://en.wikipedia.org/wiki/Password_Authenticated_Key_Exc...) which is one of the few PAKE protocols that is not patent encumbered and decently peer-reviewed. In fact, that's why Thread (https://www.threadgroup.org/) selected J-PAKE as their authentication protocol.

That paper does cite a number of other PAKE papers, including SRP.

> the SRP protocol, which is a PAKE, but that was dropped due to patent issues.

What about (EC)DHE_PSK, is it also patented? If so, the software patent is fricking insane...

Another patent that will probably expire soon is the patents on OCB, which was also tried for 802.11i.

IIRC OCB is now available for free under a reasonable license. I could be remembering wrong, though.

> Wi-Fi Alliance is also introducing Wi-Fi CERTIFIED Easy Connect™, a new program that reduces the complexity of onboarding Wi-Fi devices with limited or no display interface – such as devices coming to market for Internet of Things (IoT) – while still maintaining high security standards. Wi-Fi Easy Connect™ enables users to securely add any device to a Wi-Fi network using another device with a more robust interface, such as a smartphone, by simply scanning a product quick response (QR) code. Wi-Fi Easy Connect and WPA3 represent the latest evolution in Wi-Fi Alliance programs to ensure users receive a positive experience while remaining securely connected as the security landscape evolves.

This is highly reminiscent of WPS. The language indicates that they've learned their lesson and focused on making the standard secure, at least in theory. Time will tell how well it's implemented, but history says to be skeptical and disable it for the time being.

It is allowing any device already on the network to vouch for new devices. What could possibly go wrong? WPS had flaws in its implementation, but was reasonable on a theoretical level. This seems foolhardy at best.

WPA2, when properly implemented, is very secure. I'm not sure of WPA3's real purpose. Is strong encryption of wifi signals of any benefit? The days of banking passwords being send in html gets should be behind us. Anything important will be protected by other encryption layers than wifi. Is WPA3 meant to protect unauthorized network access? WPA2 isn't exactly easy to crack. Do we really need a new scheme, and the inevitable new flaws that come with it? Or is this really about streamlining the user experience, about making wifi that little bit less complicated, so that people can attached their smart toasters to the home network without having to actually remember the password.

To clarify for those who obviously do not understand the difference between protocol and concept implementation: Errors in the protocol would have been inconsequential if WPS was implemented properly. Had it not been left on 24/7, the temporary use of shorter keys would have been a good thing. It would have allowed home networks to adopt much more complex keys without having to type them into every new device (a big deal on things like printers which didn't have keyboards). WPS could have contributed to greater WPA2 security. But instead the concept was improperly implemented, allowing the inevitable errors discovered in the adopted protocol to be leveraged.

It doesn't say _any_ device. On the contrary, it sounds like the network admin has to explicitly delegate that authority to the configurator device:

> With Wi-Fi Easy Connect, a network owner chooses one device as the central point of configuration.


Though with WPA2 (personal, at least), isn't it already possible for "any permitted device" to "vouch for new devices" by simply giving those new devices the Wi-Fi password?

Yes, Apple devices offer to do this for eachother if you are in the person's contacts.

Works between your own devices too, requires bluetooth but no pairing.

Best thing ever when traveling and your colleague just got the wifi password for the coffee shop you are in and you don't feel like typing it out.

No, that's factually wrong. KRACK showed the protocol itself is vulnerable, not the implementations, and it affects all devices.


This is really why they went with WPA3, but I've noticed the Wi-Fi Alliance goes to great lengths to avoid any mentions of KRACK. So now, many, like you, are scratching their heads wondering what's the point of WPA3.

You are right, the protocol is broken. But that is only because it was accepted with a flaw that should be fixable.

While re-starting routers it was possible for an attacker to re-use nuonces (number used once). Because of a "SHOULD" clause in the RFC, the fix was optional and made it vulnerable.

Had that been a "MUST" (required) We would not be hearing even the a trace of WPA3.

An excerpt from the same website you sourced :

"When the victim reinstalls the key, associated parameters such as the incremental transmit packet number (i.e. nonce) and receive packet number (i.e. replay counter) are reset to their initial value. Essentially, to guarantee security, a key should only be installed and used once. Unfortunately, we found this is not guaranteed by the WPA2 protocol."

> WPS had flaws in its implementation, but was reasonable on a theoretical level.

Not sure about that since it has a key space of 10,000.

Implementations without a timeout were super-easy to crack while those with a timeout just took time to figure out how long the timeout was and to not exceed it. I have a Netgear wifi bridge that doesn't turn of WPS (even if you click the button) with no timeout and is trivial to get the password out of while another case it took a couple weeks once I determined the timeout.

*of course I only tested on my own devices and never engaged in wifi thievery from my neighbors

To be compliant you must not be able to turn off WPS at all (assuming because that wouldn't be "user-friendly" which is the whole point of WPS).

That is, any WPS compliant router is cancer.

> WPA2, when properly implemented, is very secure

Not really:


>Anyone can disconnect you

so can someone with a jammer. I'm not sure how a protocol upgrade would protect against that.

>The password can be cracked offline

true, but the solutions presented don't really address the issue. they're variants of key stretching (using a better kdf, mandating stronger passwords, etc.). at the end he mentions "Contemporary cryptography provides tools that could solve this problem.", but that's hand wavy at best. i'm not quite sure it's even possible to implement such a feature in a PSK setting.

>Once you know the password, you can sniff traffic and spoof anyone

>This problem could be solved by using Diffie–Hellman key exchange (DH).

Doubt it. DHE does not offer protection against MITM attacks, which an active attacker can certainly do with a powerful enough antenna.

>From the user's perspective, unless you really know what you're doing, I advise you not to browse any sensitive websites (especially banking) over wireless

this is fearmongering. most "sensitive" websites already use https, which makes this an non-issue.

>It won't let you secure a passwordless network

>How could this be solved? The new WPA security standard could support the "passwordless" mode that requires no authentication, but keeps an encrypted channel of communication so that the anonymous user can identify himself and make traffic only readable by the access point.

how does this protect against MITM? that is, a rogue router pretending to be an hotspot?

> Silly "terms of service" in your cafe can break your applications and expose you to risk

valid point, but already solved: https://en.wikipedia.org/wiki/Hotspot_(Wi-Fi)#Hotspot_2.0

EDIT: Ignore me I've confused terminology.

> Doubt it. DHE does not offer protection against MITM attacks, which an active attacker can certainly do with a powerful enough antenna.

Huh? That's precisely what Diffie-Hellman is for. It's a protocol for establishing a shared secret over an insecure channel. Have you got an antenna big enough to read the private key? Sure, you can argue that pure DH is weak compared to ECDH or PKCS, but this is exactly what the system does.

No, DH doesn't stop impersonation or spoofing attacks. It doesn't do authentication. That much I agree with you on. You need something like ECDSA for that. But those types of attacks aren't MITM.

DHE protects against eavesdroppers, not middlemen.

Oh, fair enough. Dang, I get those confused far too often for my own good.

You don't think that MITM is a kind of impersonation attack? DHE is a mechanism for agreeing on a secret; it does nothing to authenticate the station you're agreeing on that secret with.

Think of what happens in TLS interception; DHE still takes place with the intercepting device, it's PKI which tells you who you're agreeing with.

Yeah, I had my terminology confused. I was mistaken.

In fact, you were closer to the truth than the person you replied to.

The new standard uses a PAKE (password-authenticated key exchange) protocol. This type of cryptographic construct is similar to an unauthenticated key exchange protocol (such as Diffie-Hellman), but in addition succeeds only if both parties know the same password, without leaking any information about the password to a party if they don’t know it. At least one of the best-known PAKE algorithms, namely SRP, is quite similar to Diffie-Hellman in structure, although it’s not the one being used here (which I don’t know anything about).

If I'm not completely mistaken, only the DoS ("Anyone can disconnect you") is valid for true scotsman WPA2 (aka WPA2-EAP aka WPA2-Enterprise). "Silly "terms of service" in your cafe can break your applications and expose you to risk" is hardly fault of WPA2; while some sort of side-channel for provider-provided messages would be nice, I think at least the ToS case could be handled by e.g. DHCP option.

I think the deauthentication issue was fixed with 802.11w, which is required for vendors to implement to get their 802.11ac license[1]. It was introduced in 2009, so you can be sure there are plenty of vulnerable consumer routers out in the wild.

Of course, WPA3 will also suffer this same issue of adoption.

[1] https://security.stackexchange.com/a/64440

Great, I haven't been tracking the situation that closely. Additionally googling around I did also find that there are standards to replace the typical captive-portal wifi setup, namely "online sign-up" (OSU) and "additional steps required for access" (ASRA).

While I don't know how well they do work in real life, they do demonstrate that the problem is manageable within the WPA2 framework.

That being said, the whole landscape around wifi is ridiculously muddied and complex, so if WPA3 does tackle the issues more natively (which I somewhat doubt), then that would be very welcome.

>It won't let you secure a passwordless network

Yes it does. 802.1x solves this. Just allow any user/password combination. This has been in use successfully. It worries me that the author doesn't mention this.

> WPA2, when properly implemented, is very secure.

Nope, WPA2 has a number of security issues. Let me introduce you to the Wi-Fi deauthentication attack [1].

  [1] https://en.wikipedia.org/wiki/Wi-Fi_deauthentication_attack

That is a matter of reliability, not security. I can also flood the air with white noise. That doesnt mean radio isnt secure.

Denial of service is a security vulnerability.

I know it's part of the "CIA" stuff, but I don't see it as a vulnerability in this specific case. Jamming affects all devices, not just "secure" ones.

Also, there is no countermeasure against it, which makes it even less a security vulnerability.

You could easily be a MITM using the de-authentication message.

Not everyone has access or the funds to get a jammer. Making it more "Vulnerable"

Take a gander at EVIL TWINS: https://rootsh3ll.com/evil-twin-attack/

That is not reliable. Windows for example won't connect to an open AP that previously had encryption enabled. At least not automatically. The next problem you might face is that TLS enabled websites will trigger an error warning.

Your TLS argument is true. That however does not make it any less insecure.

You see, People around the world click 'proceed anyway' on so many of those websites. That is what happens when APs in coffee shops are misconfigured around the world.

It is barely a useful prompt (if at all).

And keep in mind this is a MITM we are talking about. He could simply, replace an instance of a website with his local version using 'http' instead of 'https'. The prompt would not even show up in this case.

It's still a dialog in the OS, not on a website.

You can blame it to users stupidity all you want, but if people click on "continue" it's their fault. They can read. If they can't, they shouldn't use a PC in the first place.

This isn't really like WPS. It's more like... what a lot of IoT devices already do.

I'm not sure any IoT devices ever used WPS.

Currently you need bluetooth between your smartphone and the IoT device just to set it up. Maybe with the help of this, bluetooth could be removed.

No, a lot of WiFi IoT devices create a hotspot that your phone connects to. It's hacky as hell - you have to do the connection manually on iOS (unless it uses Homekit), and some devices only support one WiFi connection so they have to disconnect from your phone before attempting to connect to your network so you get zero feedback.

But it saves $2 on the BOM.

most wifi SoC support peer-to-peer over wifi, now-a-days you don't really need bluetooth.

From a user standpoint they lack the profiles that bluetooth has baked in, that ensures that devices can talk to each other with little to no extra software.

And if the IoT device is using Wi-Fi anyway there is no need for low power demand of Bluetooth.

Pardon my negative comment, but given their history of absolutely terrible crypto, I can't wait to see how they mess it up this time.

Some thoughts on WPA2: https://github.com/d33tah/call-for-wpa3/

If I understood everything, you have to be a Wi-Fi Alliance member in order to develop/contribute/vote on all things WiFi. The smallest membership that allows you to participate is US$7,500/year for 2018 (next year it’ll be $7,725/year). And that’s only for small businesses and they won’t have all voting rights. The actual membership is a whopping US$15,000/year ($450 more next year).

It disgusts me to see that in order to improve something that a crapton of people use daily to protect them self, that’s currently broken, you’d have to pay. I didn’t see any mention that individuals can become members on the website of the Wi-Fi Alliance seems to be only businesses can participate.

I’d be alright with some open-source implementation instead.


Seems like it would encounter same problem earlier in Wifi history

"Early 802.11 products suffered from interoperability problems because the Institute of Electrical and Electronics Engineers (IEEE) had no provision for testing equipment for compliance with its standards."


Wi-Fi enhanced open looks like a nice security enhancement for open networks, but unfortunately (correct me if I'm wrong) it still doesn't look like it protects users from rogue access points; it only stops eavesdropping if users have already connected to the correct network.

I'd love to see a system similar to what Wi-Fi is already doing with Easy Connect, where users can scan a public key embedded in a QR Code or NFC tag to securely connect to a Wi-Fi network. (Or does Easy Connect already allow that? It'd be great if it does.)

Why wasn't this designed in the open like TLS 1.3? The process behind isn't very confidence inspiring...

Because IETF is NOT an industrial alliance, but Wi-Fi Alliance is. See the differences?

see also: 3GPP.

That is the obvious difference, but why don't they develop crypto protocol with a more open model? They have had too many fiascos for me to trust their current model.

If a large company wanted to push for a wifi alternative it could probably happen.

> WPA3 leverages Simultaneous Authentication of Equals (SAE), a secure key establishment protocol between devices, to provide stronger protections for users against password guessing attempts by third parties.

Is that their term for PAKE?

Also I hope they have finally included an actual error message for incorrect passwords, rather than just "connection failed" which is the best that seems to be possible at the moment.

I've seen some cases where I actually do get an authentication failed error connecting to wifi, but other cases where it just gives me some generic connection failed (even when the issue turns out to be authentication). It seems quite random.

Wow, I hadn't realized that WiFi standards were developed like this. Looking down the page, I see a bunch of TM symbols, endorsements from massive companies, and no technical details or even attempt to describe anything related to security. Not very confidence-inspiring to an outsider.

Does this fix the primary problem with WPA presently: the lack of forward secrecy?

If you had followed the link in the PR release labeled "For further information, please visit: https://www.wi-fi.org/discover-wi-fi/security"

you would have found the following statement: "Forward secrecy: Protects data traffic even if a password is compromised after the data was transmitted" under "WPA3-Personal"

Given the apparent state of affairs, it seems like the vendor or vendors who care should bake a vpn into their firmware to provide better protection. Of course it is possible to use a pi or perhaps integrate into an open source firmware, but having a simple vendor provided config would be much better for adoption rates.

WPA2 isn't that bad as long as you use a password that isn't going to be pwned by a dictionary attack in 2 seconds so does this prevent against that if frames are captured? IDK.

It attempts to. Whether or not it succeeds depends on whether the highly questionable SAE protocol actually works — see the other comments here.

Security of Wi-Fi will always be a shit show, because standards are not public.

Want to dig into TLS? RFCs are on internet, ietf.org, in nice courier fonts.

Want to dig into WPA2? IEEE wireless security standards carry a retail cost of hundreds of dollars to access, and costs to review multiple interoperable standards can quickly add up to thousands of dollars [0]

"IEEE working groups are a closed industry process."

[0] www.wired.com/story/krack-wi-fi-meltdown-open-standards/

WPA3 Personal seems to be another name for SAE that was defined in 802.11s

Revolution is needed. Let IETF take over development of Wi-Fi standards. If it's patents rigged, start from scratch.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact