You may have noticed that WPA3 has an issue or two with their security protocols. This was first disclosed back in April on the website detailing the researchers exploitation of the DragonFly handshake protocol used for WPA3’s implementation of Simultaneous Authentication of Equals (SAE). The April attacks used some very clever methods of attacking key exchanges. One used the transition mode of trying to help WPA2 and WPA3 clients co-exist on the network. But the more impressive one is the math-related attack.
The original attack in April found a way to downgrade the elliptical key exchange from a robust P-521 down to a P-256. That forced the Wi-Fi Alliance to move to using Brainpool Curves. However, the move to Brainpool Curves opened up even more issues concerning side channel attacks. There are two new CVEs that address this, including a timing attack found in CVE-2019-13377. This latest exploit was discussed recently at Black Hat
.
Dragon Slaying
During the recent Aruba presentation at Mobility Field Day 4, Dan Harkins took a few minutes to address the latest round of vulnerabilities in WPA3-SAE and the DragonFly key exchange:
Dan is pretty forthright in the above video when he discusses these issues. He discusses the methodology of how the SAE handshake has some pre-work that needs to be done to find the secret point on the curve that’s smaller than the prime of the curve. That means that Dragonfly needs to do a lot of looking to find that point. The standard suggests that you loop 40 times over the curve to discover the point. The researchers were able to find gear that only looped 7-8 times and were therefore able to narrow the results they found and recover the key for the network.
Dan’s solution was to implement a new method from the IETF Crypto Forum Research Group that allows you to do algebra to compute a hash value into the curve without searching for values, or “hunting and pecking” as Dan calls it. Here is his draft proposal to the IETF for this new implementation.
Can’t We All Just Get Along?
So, what does this new proposal really mean for WPA3? Well, the good news is that it’s not going to require any additional hardware purchases. Because this is all done in software it’s going to be a transparent software fix to the end user.
- When the client attempts to connect to the AP using WPA3, the AP will respond first with the SAE method of using the “hashing into the curve challenge”. If the client responds that it is capable of this method the two devices will make the negotiation and all will be fine. Security will prevail.
- If the client doesn’t respond to the offer, the AP will fall back on the “old” method of hunting and pecking to find hash values on the curve. It’s not as secure as the new method but it’s still better than nothing at all.
All that changes is the initial handshake offer. Everything after that is still the same protocol we’ve seen before. This is a different version of WPA3 from what has already been released, so Dan isn’t sure what they’re going to call it. In the video, he states that it shouldn’t be called WPA4 because it’s just a minor authentication change. Sam Clements (@Samuel_Clements) suggested maybe WPA3.1 or something like that as a way to differentiate the initial handshake offer.
The Mighty Windmills
So, what does this really mean? Is WPA3 fundamentally broken? Do we need to go back to the drawing board?
In a word: no.
WPA3 isn’t broken because what’s being attacked is the handshake between devices. Sure, some clients implemented the protocol in a non-suggested way and caused issues with the researchers able to recover keys. That method was patched within two days. This also doesn’t affect the EAP methods that require more stringent interrogation of the client. SAE was designed as a replacement for pre-shared keys (PSK), which themselves are very insecure. When you start challenging users for credentials that are valid on the system, you’re going to see attacks like this get minimized.
More importantly, I want to take a moment to discuss the other thing brought up in the paper. Vanhoef and Ronen were upset that the Wi-Fi Alliance develops the standards for things like WPA3 in secret before releasing them to the community to be implemented. Vanhoef and Ronen want more involvement of open source community members in the process would have prevented issues with DragonFly.
Funny that SAE came from the IETF, not from the Wi-Fi Alliance, isn’t it? The IETF is built on the idea of contribution and working ideas. The Wi-Fi Alliance took the ideas from IEEE and IETF and implemented them. Now, I’m not one for saying that all standards should be developed in a vacuum behind closed doors, but what exactly would open source have contributed to the discussion? How would they have affected the outcome?
Here’s a little tidbit for thought. Did you know that Opportunistic Wireless Encryption was dropped from WPA3 requirements because of backlash from the vendors? They didn’t make it a requirement of the protocol implementation, just a suggested additional security aspect of it. Scott Lester has a great post here outlining it. If the Wi-Fi Alliance can’t get their members to implement common sense security protocols for the protection of users for trivial reasons, what makes you think they’re going to listen to security researchers finding holes in handshakes and requiring more expensive protocols to enable the fixes?
The only way to make the Wi-Fi Alliance stand up to these issues is for them to require more secure protocol exchanges in their recommendations and then make them stick. Don’t slide back for compatibility. Don’t give up because someone claims it’s unfair to make them implement harder things to be safer. Stick to the decision and make it work. You’ll find that people tend to be more willing to compromise in your direction when you don’t give them ground time and time again to let them get their way.
Bringing It All Together
Dragonblood represents the way that security should be done. We find an exploit and we patch it. We figure out a method doesn’t work and we replace it. People looking to break something are going to find ways to break it. Whether or not that’s practical is anyone’s guess in the long run. But what is true is that this cycle works like it does for a reason. The Wi-Fi Alliance wasn’t looking for every possible exploit imaginable when they started building WPA3. They needed something that worked with clients, protected users, and didn’t require a supercomputer to implement. The holes will get fixed as they are found. And the security researchers are going to keep plugging away to find them.
