Feature request: use random MAC addresses when scanning

[Johannes Berg]

On Fri, 2014-06-13 at 02:53 +0200, Björn Smedman wrote:

> The WWDC slide [5] reads "the MAC address used for Wi-Fi scans may not
> always be the device's real (universal) address." If anything I think
> that wording indicates thoughtfulness, which is really all I'm
> advocating here (I'm not saying "don't ever randomize", I'm saying
> "please think it through carefully").
> 
> 5. https://twitter.com/fredericjacobs/status/475601665836744704

I'm reading it more as a CYA statement - scanning can happen while
associated for example, which clearly has issues with ACK transmissions.

> True, if the chipset/driver can completely focus on the scan. But
> looking at mac80211 [6] as an example there's optimization for the
> case when we're scanning only the operating channel and there's no
> need to disrupt the normal operation of the driver/chipset. That would
> be difficult (but also luckily relatively pointless) to do for an
> incognito scan.

Indeed. I'm thinking that this is likely why the slide reads "may" and
not "will", because background scanning while connected would probably
still use the real address (or at least the address it used to connect,
whichever that may be)

> But what I was really referring to was the far more radical
> implementation that would leave the MAC as random when connecting. If
> you do that with ath9k and a few virtual STA interfaces (or attempt
> the above optimization for incognito scan) you will end up with an ack
> mask [7] that is dangerously close to all zeros, i.e. you run the risk
> of acking frames addressed to other devices.

Obviously. That's why this needs to be a feature flag and why there are
other considerations. But keep in mind that this is but one device -
most others that even support multi-interface operation have different
limitations, e.g. just supporting a handful of addresses, rather than
calculating an ACK mask.

Using random addresses for connecting also has a host of other potential
issues - this one isn't even the most interesting one because it's a
complete corner case.

> True. The somewhat radical step comes if/when you use the probe
> response addressed to this randomized MAC to generate an
> Authentication frame with the real (universal) MAC (or decide that no
> such Authentication frame can be generated)... 

I don't see any issues with that. In many cases we don't even send a
probe request until we connect with the real address. If you've managed
to find the network, from the spec POV it's fair game to connect.
There's no requirement to even send a probe request, you may connect to
the network if you know it's there, regardless of how you discovered it.

> Again taking mac80211
> [8] as a reference there is an explicit check to avoid using probe
> responses addressed to other devices:
> 
>     /* ignore ProbeResp to foreign address */
>     if ((!sdata1 || !ether_addr_equal(mgmt->da, sdata1->vif.addr)) &&
>         (!sdata2 || !ether_addr_equal(mgmt->da, sdata2->vif.addr)))
>             return;
> 
> I think that code makes sense. Essentially that's what I'm (somewhat
> clumsily) trying to say in A below: "just because some other device
> got a certain Probe Response that doesn't mean I would necessarily get
> the same". Also of course in the negative: "just because some other
> device didn't get a response doesn't mean I wouldn't."
> 
> (And the phrase "some other device" is of course logically
> interchangeable with my own incognito alter ego / random MAC.)
> 
> 8. http://lxr.free-electrons.com/source/net/mac80211/scan.c?v=3.15#L186

I think this is debatable. The check makes a certain amount of sense,
though I'd argue it's mostly for the case where there actually *are*
different probe responses. That's unlikely to start with.

Either way, the check would have to be modified/removed for randomized
scan.

> I think there definitely are cases when you want to scan with the real
> MAC address, e.g. (at the very least) when already connected there is
> little point to incognito scanning (as the real MAC is already out
> there) and a number of problems (e.g. it's disruptive to the normal
> operation of the chipset/driver as discussed above and it can cause
> problems for networks that try to manage handover).

Yes, when you're connected then this would be tricky. Again, this is why
I think the original slide says "may".

> The case I'm thinking about is when there is no connection when the
> device wakes up, because no suitable network has been found with
> incognito scan. As I see it there can be two reasons for that: 1)
> there simply is no suitable network or 2) there is at least one
> suitable network but it's not visible in incognito scan mode. Now the
> latter (2) could be a hidden network, or an SDN-based network, or
> possibly some other type of networks we haven't yet thought of here at
> all. In this case I think it makes sense to do an active scan.

That's a bit of an integration question I guess. I'd guess that it ends
up that everyone who wants to do something like this will do the same
Apple did ;-)

> (And I don't agree that this is very different from what a typical
> phone does today: When you take the keylock off a smartphone there's
> generally a burst of Probe Request frames, some with preferred SSIDs.
> I'm just saying we should keep it that way for now.)

I've never observed that, but then again my phone is actually connected
to wifi most of the time.

> As I see it this incognito scan is a temporary hack. Real privacy IMHO
> requires randomization/encryption of *all* identifying information,
> both when scanning and when connected. That's doable, but not without
> the IEEE getting involved (at least not in a safe way).

I can't really agree with the "temporary hack" phrasing, and I'm not
sure I share your optimism about privacy enhancements. Scanning is an
integral part of the protocol, and the only way to hide your address
there is exactly this. It seems to me that there's no reasonable way to
hide your address otherwise, given the ACK requirements etc.

If you start thinking about making it even more private, you'd have to
encrypt or at least hide more, which seems to boil down to either a
complete frame format change (highly unlikely), or using random
addresses - maybe with a spec extension to let the real address be
transferred as part of the encrypted authentication handshake.

johannes