Wi-Fi Alliance Introduces Wi-Fi Certified WPA3 Security
wi-fi.org
wi-fi.org
https://ieeexplore.ieee.org/document/4622764/
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.
† https://www.ietf.org/mail-archive/web/tls/current/msg10922.h...
Later:
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?
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.
https://www.ietf.org/mail-archive/web/tls/current/msg10962.h...
https://www.ietf.org/mail-archive/web/cfrg/current/msg03554....
https://www.ietf.org/mail-archive/web/cfrg/current/msg03736....
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.
https://www.ietf.org/mail-archive/web/cfrg/current/msg03554....
"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).
Oh, the optimism :)
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.
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.
https://patents.justia.com/inventor/daniel-harkins
This one is granted:
https://patents.google.com/patent/US20170013449
"Original Assignee Aruba Networks Inc"
"Current Assignee Hewlett-Packard Enterprise Development LP"
He co-authored a blog post about the WPA3(TM):
http://community.arubanetworks.com/t5/Technology-Blog/WPA3-T...
https://www.ietf.org/mail-archive/web/tls/current/msg10971.h...
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:
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.
What about (EC)DHE_PSK, is it also patented? If so, the software patent is fricking insane...
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.
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.
> With Wi-Fi Easy Connect, a network owner chooses one device as the central point of configuration.
https://www.wi-fi.org/discover-wi-fi/wi-fi-easy-connect
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?
Works between your own devices too, requires bluetooth but no pairing.
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.
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."
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
That is, any WPS compliant router is cancer.
Not really:
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
> 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.
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.
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).
Of course, WPA3 will also suffer this same issue of adoption.
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.
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.
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_attackAlso, there is no countermeasure against it, which makes it even less a security vulnerability.
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/
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.
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.
I'm not sure any IoT devices ever used WPS.
But it saves $2 on the BOM.
Some thoughts on WPA2: https://github.com/d33tah/call-for-wpa3/
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.
/rant
"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."
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.)
see also: 3GPP.
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.
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"
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/