Hacker News Reader

Comment by spr-alex | Hacker News Reader

I work at Supernetworks where we're building secure by default Wi-Fi routers. Our software had the ability to assign MACs to interfaces for a little while now, and as a response to this study we've now also added MAC randomization, now in the dev branch, and generally available in our next release (https://github.com/spr-networks/super). Many cards which support WDS//AP-VLAN have no trouble with updating the BSSID.

For use as a travel router the UI makes it simple to randomize both the AP BSSID/MAC as well as interfaces working as WiFi client stations for internet uplink.

View on HN

Most wifi baseband firmware "helpfully" leaks the true eeprom-written MAC address in places like management frames and beacons:

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

As of 2017 the authors of the paper above found MAC leaks in a shocking 96% of all android phones. And the remaining 4% aren't proven to be leak-free -- they simply hadn't noticed any leaks by the time they wrote the paper.

Unless you have fully open-source firmware on your baseband, like ath9k_htc, there's really no way to prevent this leakage. Or even be sure if it's happening.

https://wiki.debian.org/ath9k_htc/open_firmware

With open source baseband firmware you can guarantee that the baseband never even has access to the hardware MAC address. You can even reflash the MAC address eeprom (on every boot if you like!)

We actually have an intern researcher working on a path towards an open source implementation of 802.11 for wifi 6 cards but do not have an ETA when our first proof of concept will be released.

We've also reported mac leaks to vendors -- we found stations would transmit packets with their non randomized state in certain scenarios, we'll blog about it when vendors release their fixes.

But more importantly I also want to say that I do not expect the MAC leaks are happening in most beacons & probe responses, which is what Apple and Google and others collect for their positional database with wi-fi SSIDs and BSSIDs. There's still ways to fingerprint, from digital fingerprints, to signal fingerprints unique to the radio and antennas and board, where machine learning can cluster and classify devices that are going to be very hard to anonymize for privacy.

Projects like https://www.nzyme.org/ actually apply fingerprinting techniques for defense to detect Rogue APs that could manifest in an actively attacked environment. They can pick up wifi implants as well as the Rogue AP attacks.

an open source implementation of 802.11 for wifi 6 cards

For which baseband chip, specifically?

I mean this would be great, but I have a very hard time believing any baseband vendor gave you enough documentation to achieve that -- especially not without an OSS-prohibitive NDA. Would love to be wrong about that. It happened once, but that was back when Atheros was an independent company -- before they were Qualcommized.

Also, aren't all the wifi 6 baseband firmwares cryptographically signed? Best case it'll be as "open source" as Tivo was.

We've also reported mac leaks to vendors

That's good, but I don't think the whack-a-mole approach inspires much confidence. There have been so many of these problems that at this point we really need to take the car keys away from the drunkard and have the baseband chip and the MAC-bearing eeprom be separate devices which can only communicate via the CPU. Or just have the CPU derive the MAC from the CPU's own serial number. Or maybe just not have hardware MAC addresses at all.

Not all are cryptographically signed, no. We have no special documentation but we are also not directly modifying closed firmware either. We are working with mediatek cards and will post more updates this summer. We last posted about our approach 6 months ago, https://www.supernetworks.org/pages/blog/barely-ap-surfaces.

So the randomization bugs we have reported are specifically about stations, namely: mobile smart phone devices failing to randomize their WiFi MAC address.

As for the study this thread's topic concerns, I do not have reason to believe that there are bugs with MAC randomization in cards running as APs that would make the randomization of BSSIDs fail.

The probe responses and beacon contents appear to consistently use their randomized MAC address in the cards we have tested. There could be underlying actively triggered bugs an active attacker could uncover, to get the non randomized address, but I do not expect such bugs would affect the BSSID + Positional databases of this study.

> I do not have reason to believe that

This phrase has no place in security research.

My comment is not unsubstantiated. When implementing the feature we verified Probe Responses, Beacons, & EAPOL Handshakes work as expected with the randomized MAC for the BSSIDs.

> we're building secure by default Wi-Fi routers

In addition to RPi hardware, it would be helpful to support Rockchip RK3399 and RK3588 SoCs that have minimal binary blobs, since these can used with open-source Arm Trusted Firmware (TF-A) for secure boot, to ensure that only owner-authorized OS and firmware are running on the device.

> Many cards which support WDS//AP-VLAN have no trouble with updating the BSSID.

Do these M.2 WiFi cards support AP/VLAN and BSSID updates?

  Qualcomm Atheros QCA6174 Wi-Fi 5
  Qualcomm Atheros QCNFA765 Wi-Fi 6

Rockchip RK3399 and RK3588 SoCs

Just so people don't get confused, there is a huge world of difference between these two chips. They are not in the same category.

Rockchip RK3399 is 100% blobless. You even control the EL3 Trustzone Secure World! This is True Root.

Rockchip RK3588 still needs blobs in EL3, the highest privilege level. We've been hearing rumors for years now about "oh they'll open source it next month for sure" and it.... just. never. happens. Please stop spreading this rumor. Source or GTFO, Rockchip.

Feb 2024, https://news.ycombinator.com/item?id=39490540 & https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a...

> Rockchip have sent a few patches to the TF-A project here to support [RK3588].. From TF-A we can now build a complete working BL31 and replace the closed binary blob with an open-source binary that we can compile ourselves.. There are still some missing parts and the most important that is remaining right now is the DDR training blob, which is still closed source.

Like I said: blobs in EL3, the highest privilege level.

We've been getting these "almost there" announcements quarterly for multiple years at this point.

In decreasing order of preference:

  OSS TF-A at EL3 + OSS DDR training (RK3399)
  OSS TF-A at EL3 + closed DDR training (RK3588)
  OSS uboot + closed TF-A 
  closed uboot + closed TF-A

Those who need the features of RK3588 can compare it to competitors which are less open.

Those who don't need the features of RK3588 can use the older and fully open RK3399.

> OSS TF-A at EL3 + closed DDR training (RK3588)

That should be "blob which does stuff, including DDR training, at EL3".

That blob certainly does DDR training. Maybe it does other stuff. But all of it is done at EL3.

> In decreasing order of preference

"Warning! Diagram is not drawn to scale."

> That blob certainly does DDR training. Maybe it does other stuff. But all of it is done at EL3.

If someone wants to find out, they can load it in IDA/Ghidra?

If it was that easy we'd have a cleanroom FOSS implementation by now. It's been more than two years!

https://wiki.raptorcs.com/wiki/Project_Ortega

Cleanroom reverse engineering for the purpose of publishing new driver code, to avoid legal/IP minefields, is super-expensive. It should be a much narrower scope to determine whether a binary blob's actions are limited to memory training, since there is no requirement to publish reusable source code.

Looks like Collabora is already monitoring the blob, so it's not entirely a mystery:

  At the moment of writing this article, we have identified a few differences from the binary blob previously used, which we can highlight as following:

  Binary BL31 contains some unknown code to get HDMI-RX PHY access working.
  The cpufreq support in binary BL31 is different from TF-A. 

  There could be more issues that are unknown at the moment and users should be aware of it.

> Cleanroom reverse engineering for the purpose of publishing new driver code, to avoid legal/IP minefields, is super-expensive

Project Ortega did it to an entire gigabit ethernet controller for the princely sum of zero dollars:

https://media.ccc.de/v/37c3-11781-adventures_in_reverse_engi...

https://wiki.raptorcs.com/wiki/Project_Ortega

> Binary BL31 contains some unknown code to get HDMI-RX PHY access working.

That doesn't sound like DDR training to me. Maybe now you see the problem?

> That doesn't sound like DDR training to me. Maybe now you see the problem?

It is absolutely a problem, but it's bounded by the ability to inspect and question code/behavior outside the officially claimed rationale. We can prefer open systems and also shine a bright light on the behavior of closed systems.

SPR can run about anywhere docker can run. So if you have a linux system running docker with these, you should be good to go. We provide the OS images as one path to running SPR.

We are currently looking at banana pi over rockchip but we are very happy to assist if someone has this gear.

I don't have access to Qualcomm information but if you have those chips it will be under the output of 'iw dev'.

I’m not sure if I understand your project correctly, but can this fix the issue with tracking people by location from their phones? Either way it’s a cool project.

I’m Danish, I think the only way to really prevent mass surveillance through WiFi is through laws and legislation. It used to be legal to track people here, but thankfully it’s not anymore. I still remember when there was an outcry from smaller municipalities when they could no longer track people on their “walking streets”. I’m not sure if you have those in other countries but they are basically the “central” street with a lot of shops that are only for pedestrians. Virtually every Danish city has one, larger cities have multiple. Anyway, smaller cities used to track people to see which parts of those streets were popular and which weren’t.

Now they didn’t exactly do it for sinister reasons as such. Our smaller cities have issues with what is called “city death” where their “waking streets” lose shops because people go to larger malls. Then they might add a play ground or other cultural things, or even help shops with rents in order to increase an even popularity in their “waking streets”.

Despite their good intention it was still mass scale surveillance.

> It used to be legal to track people here, but thankfully it’s not anymore.

It not legal anymore, except when you are big enough or you are the one that decides what is legal or not.

> Our software had the ability to assign MACs to interfaces for a little while now, and as a response to this study we've now also added MAC randomization, now in the dev branch […]

Will it follow what the IEEE is proposing?

* 802.11bh: Enhanced service with randomized MAC addresses

* 802.11bi: Enhanced service with Data Privacy Protection

* https://standards.ieee.org/beyond-standards/data-privacy-and...

Note the privacy-impaired 802.11bf: WLAN Sensing, https://www.ieee802.org/11/Reports/tgbf_update.htm & https://www.technologyreview.com/2024/02/27/1088154/wifi-sen...

> Someone outside your home could potentially tell when it’s vacant, or see what you are doing inside. Consider all the reasons someone might want to secretly track someone else’s movements. Wi-Fi sensing has the potential to make many of those uses possible.. it could be used by corporations to monitor consumers, workers, and union organizers; by stalkers or domestic abusers to harass their victims; and by other nefarious actors to commit a variety of crimes. The fact that people cannot currently tell they are being monitored adds to the risk. “We need both legal and technical guardrails"..

> At least 30 million homes already have some kind of Wi-Fi sensing available.. When the new standard comes out in 2025, it will allow “every Wi-Fi device to easily and reliably extract the signal measurements".. With Wi-Fi 7.., “the sensing capability can improve by one order of magnitude”.. The committee did discuss privacy and security.. But they decided that while those concerns do need to be addressed, they are not within the committee’s mandate.. Wi-Fi sensing is more concerning than cameras, because it can be completely invisible.

IEEE standards are a minimum starting point for interoperability. Security and privacy improvements can be implemented in open-source code, to inform future revisions of IEEE standards.

Privacy has been discussed with .11bf; see "§V.D Security and Privacy" of the following:

* https://arxiv.org/abs/2207.04859

Of course Wifi sensing is already a thing with existing signals:

* https://web.ece.ucsb.edu/~ymostofi/WiFiReadingThroughWall

* https://interestingengineering.com/innovation/scientists-tra...

> Privacy has been discussed

Discussion is a good start. That section of the paper states:

  Although there are already various ways to improve security and privacy, IEEE 802.11bf is still discussing which solution to add.

Hopefully the scheduled 2025 launch of 802.11bf will be gated upon _implementation_ of security and privacy.

> Of course Wifi sensing is already a thing with existing signals

Several orders of magnitude exist between researchers and commercial devices in the hands of millions of consumers.

> Several orders of magnitude exist between researchers and commercial devices in the hands of millions of consumers.

Well, between nation state actors and consumers

   fight_club.jpg

These amendments might not apply to BSSIDs/Access Points but refer to enhanced privacy features to stop the fingerprinting of stations as well as providing ways for APs to identify stations under randomization, across a complicated network.

If you had a nice enclosure for these routers you could take a large share of the prosumer market and be a "privacy" version of unifi.

As an average home user, I would love something like this (interface and features) but with a nicer looking hardware (wife tax).

Yes, We have some prototypes and will have some nice enclosures coming soon that we'll make available via our website at https://www.supernetworks.org

In addition, some parental controls would be nice (feature parity with, say, Gryphon). I see your subscription tier offers some of that (schedules and domain logging).

So is bringing your own travel router while traveling the current best practice for securely connecting to public wifi's?

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

  SSIDName_optout_nomap

pretty please don't fall for that crap

What's wrong about it?

This sounds very cool and IIUC could replace my EdgeRouterX($60) I currently use.

Suggestion, your site is not understandable to me. At the top it says you make routers. Under products it lists a a PI5 HAT. Is that a router? It sounds like it's a Wifi card for a Raspberry PI?? PI5 Pod, Is that a router? It says "bundled with PI5 Router" ??? "CM4 Capsule" is that a router?

Is this site only for people who already know these terms?

It also claims all this runs locally but then says you have a subscription... ?!

> It also claims all this runs locally but then says you have a subscription... ?!

Looks like the subscription is for those who want to help fund the project.

Not many functional differences, maybe those are handled in the config GUI?

From your site: “ Why should your vacuum be able talk to your doorbell? Inadequate network isolation makes breaches worse.”

Just got to say- that would be awesome for my vacuum to stop making a loud noise when someone pushed the doorbell, so I wouldn’t miss the person! (But I do completely get the underlying sentiment)

An untrusted vacuum and doorbell can each talk to trusted HomeAssistant for coordination, while isolated from each other.

Unfortunately wisp/biz/cafe net providers often seem to block randomised mac addresses on device side (I'm guessing the sign on portal they force people thru registers by mac).

Reply on news.ycombinator.com