Trying to deploy WPA3 on my home network | Hacker News Reader

Trying to deploy WPA3 on my home network

gist.github.com

55 pointsynezz26 comments

Worried enough about security to deploy WPA3, but still uses a Galaxy S2? Even with LineageOS, aren't you still using ancient device drivers?

Device drivers don't usually need to be updated unless the driver interface changes (i.e. when you update the Linux kernel) or the driver needs to be updated to accommodate quirks of new software (i.e. graphics drivers and new video games).

They probably do want to be getting the latest security patches to the kernel and base OS.

I remember the creator of CopperheadOS claiming the "Nexus 5" (which is EOL) is not secure because of hardware (baseband?) vulnerabilities that wouldn't be trivial to fix.

Citation: https://twitter.com/DanielMicay/status/1058103333414522880

Can anyone recommend a post that introduces these kind of issues for Android outsiders?

I assumed Android ROMs carry a fully fledged distribution, including the kernel and firmware. Sure, the latter might be out of date.

When I tried digging into the question "where does this so-called open source come from", I stumbled upon Kernels that basically have one commit adding the whole blob.

Is the ROM merely the application software built for a target kernel (which is persistent on the device)?

I've hacked around with Kernel modules on Android before, but miss the big picture in that regard.

Edit: especially the new update infrastructure (treble?), Does it change anything here?

The ROM is kinda an inaccurate term for the whole "blob" of binaries that gets copied to eMMC (or similar) storage. This can include multiple partitions, firmware updates (including for your baseband) etc.

The device kernel is a fork of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... or more accurately https://source.android.com/devices/architecture/kernel/andro... at the end of the day. The "whole thing as one commit" is just people not caring enough to maintain source history.

Treble seems to mean that the software can be updated separately from the drivers and the firmware - https://www.androidauthority.com/project-treble-818225/, it could actually make things worse in terms of out of date drivers and firmware.

I think he's more saying that Nexus 5 is not secure going forwards because the firmware for the hardware is not getting updates. I can't see any reference to specific vulnerabilities, but when a platform is complex they're bound to exist. When you combine that with not getting updates, you have an insecure platform.

The firmware for the Nexus 5 wifi chip has well-known remotely-exploitable code-execution vulnerabilities [1] that were never patched. Nearly all modern devices have a full software stack inside the wifi (and other radio) chips and they all have plenty of security flaws and they're all proprietary and unaffected by the OS.

So it's not just about it not being secure going forwards. It and most other similar age handsets are insecure because a fix has never been released for the older chips.

[1] https://googleprojectzero.blogspot.com/2017/04/over-air-expl...

Basebands are generally terrible black boxes. Even for new devices, they're a major security concern.

Agreed.

Does anyone know anything about the GSMK Cryptophone 500? It's appears to be a modified Galaxy S3 with a heavily custom ROM and can double as an IMSI catcher. I wonder. Did they RE the baseband or replace it with their own?

https://www.cryptophone.de/en/products/mobile/cp500/

Interesting.

I seem to remember there being relatively complete access to the S3 baseband at one point. Not sure I'd use it as a daily driver though. The S3 had big problems with the eMMC suddenly dying.

Heh maybe.

I am aware of the eMMC issues. Not to mention a phone from those days is slower then current phones, although I don't know much that matters with the custom ROM they use.

Author here, sorry I only saw this late.

Yes, the drivers are ancient, and probably have a ton of security vulnerabilities. Has the general situation improved in recent years? To me it seems that hardware vendors generally don't care about these issues at all. Which phone would you say has secure drivers?

Hey, the replies here about CopperheadOS are pretty good for info on this.

It's a tradeoff - new phones are more secure, but they're also secured against you, e.g. if I OEM unlock my Galaxy Note 9, a bit is set permemnantly that could be used to determine whether the phone gets a warranty repair.

To get back on track, you may want to have a look to see if the "board support package" is still supported. You're well out of vendor support and it looks like the last commit to https://github.com/LineageOS/android_kernel_samsung_smdk4210... was 2013.

The gold standard would be a phone that runs a very-close or actually mainline Linux kernel, but I don't think we're there yet.

Nexus devices were fantastic, but they're gone now. Pixel, I guess, but I was scared off after the 5X and 6P hardware issues.

Use WPA3-Enterprise (you can use Let's Encrypt to get a valid certificate so it works fine in a home environment).

Don't use SAE (which is, indeed, an instantiation of Dragonfly). I have a strong suspicion that the way it is used, there will be a practical attack.

Or just use WPA2-Enterprise, afaik there are no pressing security needs to upgrade to WPA3 if you are using EAP, and it is widely supported out of the box

The problem with this I found for home use is that IoT devices don't typically support enterprise modes. And without PSK you just flat-out can't use those devices with WiFi

Still, I imagine lot more devices support WPA2-EAP over WPA3-EAP that OP recommended.

Can you provide any more info on your concerns about SAE?

Here is some background reading:

https://news.ycombinator.com/item?id=6942145

https://news.ycombinator.com/item?id=7017160

I was unable to find the spec for SAE as used in WPA3, but SAE itself doesn't seem to hash the shared secret into the session key, which would be an easy way to provide resistance to both quantum attackers and random implementation screwups (e.g. bad PRNGs) that defeat the security of the asymmetric parts of the scheme.

Basically, take the original password/secret, derive two secrets A and B, run SAE with A as the secret, get a session key K, then use hash(K|B) as the actual session key.

If they don't have anything like that, I wouldn't be surprised if real-world implementations end up being less secure than up-to-date WPA2.

Synology Routers support WPA3 by default

They also support a mode where they will use WPA3 when supported and fall back to WPA2 when there isn't device support.

That's just WPA2 with extra steps.

I mean from a security standpoint you're right, but having opportunistic WPA3 seems to be the only sensible way to deploy until you reach acceptable device support.

Wouldn't you keep (much of) the advantages of WPA3's forward secrecy?

Not really - if all of your devices use WPA3 the attacker won't be able to brute force your password for example. You might think "if all your devices support WPA3 then why not disable WPA2?". The obvious reason is you might occasionally want to use WPA2 without fiddling around with router settings, e.g. if guests want to use your WiFi without recompiling their phone's kernel.

Then another obvious but naive response is "then your security is no better than WPA2 anyway" but hopefully it's clear why that isn't the case in the real world.

Reply on news.ycombinator.com