2 ms·

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 believ

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.

spr-alex 2y ago
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 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.
- karma_pharmer 2y ago
  > I do not have reason to believe that This phrase has no place in security research.
  - spr-alex 2y ago
    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.

spr-alex 2y ago

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 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.

karma_pharmer 2y ago
> I do not have reason to believe that This phrase has no place in security research.
- spr-alex 2y ago
  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.