
Wi-Fi Alliance introduces security enhancements - el_duderino
https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-introduces-security-enhancements
======
fowl2
Summary:

WPA2:

\- not dead, in some unspecified way it will be improved.

WPA3 - 4 features:

\- Some sort of poor password mitigation (stretching?)

\- Another go at WPS, eg. PIN/push button network join (currently easily
crackable)

\- "individualized data encryption" for open networks. Nice!

\- "a 192-bit security suite, aligned with the Commercial National Security
Algorithm (CNSA) Suite from the Committee on National Security Systems" (who?)

Some of it sounds nice, if done properly.

Hopefully we'll see some of this in software updates, preferably in the OS.

------
bcaa7f3a8bbc
> WPA2 provides reliable security used in billions of Wi-Fi devices every day.

What do you mean, "reliable", the Wi-Fi Alliance? I get it: If DEAUTH attack
has been fixed by deploying 802.11w[0], provide the randomness is generated by
a proper CSPRNG (unlike the stupid one from the appendix of the official
spec!) with a high-quality entropy source (not system uptime in
milliseconds!)[1], and that bruteforce-friendly WPS ("Protected" Setup) has
been deactivated, finally KRACK attack has been patched from the both sides?
In addition don't forget to disable TKIP and force CCMP[2]?

This is another reason why (correctly-deployed) HTTPS must be pushed forward.
Just imagine these Wireless Internet of Shit.

Despite the PR and marketing blurbs in the article, I hope it's a good news
and I sincerely hope the engineers and designers have a good insight of what's
going on around cutting-edge modern cryptography this time, and also
understand my points below. Hopefully things will go better.

Even without these flaws, WPA's crypto is far from ideal under a modern
perspective.

The lack of Forward Secrecy is the greatest blunder of the protocol. Anyone
can record all the data packets then decrypt them later if the passphrase is
discovered. Designers at IEEE did realized the problem and they came up with
an unnecessarily complicated handshake protocol to derive a session key every
time you connect to an AP. But the handshake itself is ultimately still
protected by the single passphrase! Coincidentally, the DEAUTH loophole
enables attackers to pretend being the AP, kicking everyone out of the network
and force them to redo handshakes for your capture and wiretap immediately (in
case you never have a chance to get previous ones), combo!

Hence the WPA-"Personal" is crap so you go to WPA-"Enterprise", precisely WPA-
EPA, which is extremely complicated to configure with little benefits in terms
of security (major advantages are accountability, authorization, etc though),
as most OSes don't even check the root certificate by default. The only
workaround I could recommended to people who need serious security over Wi-Fi,
is to leave the existing WPA untouched and untrust, then installing a solid
VPN on the gateway and require everyone to connect for LAN/WAN access.

Real Solution is simple, exactly the same as how we fixed Transport Layer
Security and HTTPS: Diffie-Hellman Key Exchange.

The absence of DH may be justified by the low computational power in the early
2000s, but it can't be an excuse anymore. Just perform a DH before you
transmit any real data, can't be easier, and no unnecessarily complicated
handshake protocol required. You might still say, well, what about the Man-in-
the-Middle? Sure, but cracking Wi-Fi would not be as simple as capturing
packets and typing the passphrase in WireShark, period. Also works for public
networks without passwords.

In fact, interestingly, WPS REALLY DOES PERFORM THE DH to protect the main
passphrase, in other words, for every single PIN-code you try to bruteforce,
there's a DH exchange... The world is full of ironies.

Even better, because a pre-shared key is already presented (the Wi-Fi
"password"), the key itself can be used (and should only be used) to
authenticate the DH, MITM problem solved, no user-experience changed, no
internal PKI/CA needed, but strong cryptography, forward secrecy, and the only
pre-requirement is a strong passphrase, which can be generated by EFF's
Diceware[3] for all security-minded users.

Wi-Fi, secured for the first time.

It can be even better if the Diffie-Hellman is based on good crypto, something
like X25519, with authenticated encryption like ChaCha20-Poly1305, with a
modern key derivation function like Argon2 to stretch the passphrase to
stronger key and avoid bruceforce attacks.

And you can always use lightweight-equivalents (but not low-security version)
to these cutting-edge algorithms if hardware constraints is an issue.

BTW, this is what "ECDHE_PSK Cipher Suites"[4] in TLS is about: forward
secrecy, high security with only a passphrase and no certificate, for your
HTTPS, etc, it should be easy to use and widely used. But unfortunately nobody
ever noticed them and LibreSSL even removed them due to the lack of interest
and maintenance burden (contributes to security problems in the end). In fact
you can just make WPA-EPA's TLS to use a ECDHE_PSK ciphersuit, and you can
have "Enterprise" security with only a password, but nobody support this
ciphersuit anyway...

[0] [https://en.wikipedia.org/wiki/Wi-
Fi_deauthentication_attack](https://en.wikipedia.org/wiki/Wi-
Fi_deauthentication_attack)

    
    
        https://en.wikipedia.org/wiki/IEEE_802.11w
    
        https://github.com/DanMcInerney/wifijammer
    

Basically, the 802.11w defense is undeployable. Most clients and APs still
have no support. Even if you control all the devices, 802.11w needs to be
implemented by the device driver, but what a driver can do depends on the on-
chip firmware, which has no support of it! And you know the firmware is
proprietary and you can't do anything with it.

If my memory is right, only two or three Wi-Fi families have 802.11w on Linux,
and for hardware tinkers you are not disappointed, just as expected, it works
best with ath9k, which is a family with official involvement in mainline
driver development, and no on-chip firmware is used at all.

You can enable 802.11w on LEDE if a supported chip is used, RTFM for
instructions. You should only use "Optional", not "Mandatory", because of the
above reasons.

[1] Predicting, Decrypting, and Abusing WPA2/802.11 Group Keys

    
    
        https://media.ccc.de/v/33c3-8195-predicting_and_abusing_wpa2_802_11_group_keys (with Video)
    
        https://news.ycombinator.com/item?id=15478750
    

If you are using a Linux-based solution with newer kernels, like OpenWrt/LEDE,
it's completely safe from these attacks, thanks to the improvements of
/dev/random in newer kernel and kudos to hostapd's developers for using the
correct randomness from the beginning.

However, if the device uses a proprietary implementation, even w/ Linux, it's
likely a wrong one, accounts for 30% of the market share I guess... (and what,
you said firmware updates?)

[2] All Your Biases Belong To Us: Breaking RC4 in WPA-TKIP and TLS

    
    
        https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/vanhoef
    
        https://www.youtube.com/watch?v=Et8E1Y9c2GM
    

RC4, that's enough said.

[3] EFF's New Wordlists for Random Passphrases

    
    
        https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases
    

[4] ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)

    
    
        https://tools.ietf.org/html/rfc5489

