Feature request: use random MAC addresses when scanning

Jouni Malinen j
Mon Jun 9 00:34:30 PDT 2014


On Sun, Jun 08, 2014 at 04:22:16PM -0600, Eric Branson wrote:
> Sorry, I should have been more precise in my words. I did not mean
> "associated" as in a STA associated with an AP, but just those
> functions "related" to scanning. A particularly poor choice of words
> on my part, I must say.

That was not directly from your email, but the earlier discussions I've
had regarding this topic, i.e., there is interest in being able to do
that both before and after association (and while potentially interest
to change even during association, that is not really realistic without
significant AP changes to support this as well).

Please note that there are number of concurrent use cases nowadays where
scanning and GAS can be done while associated (or operating a P2P GO).
These are some of the corner cases that get more complex even if you
leave out temporary address for the actual association. Number of WLAN
drivers do not support arbitrary source addresses, so you would likely
end up "leaking" your address when running a background scan etc. Sure,
that would still be limited to areas where you are associated with an
AP.

> With that said, do you think using random MAC addresses with
> unconnected, non-associated scanning functions is doable in
> wpa_supplicant without the aforementioned API changes?

That should be doable with many drivers, but it does come with the
price of having to set the interface down to change the address and that
can be somewhat inconvenient depending on how the network related
programs operate on the device.

> Wouldn't that prevent the real (universal)
> MAC address from being logged by every AP and wardriver in town as you
> traveled around? That's my real feature request.

Well.. Not using active scans (or GAS/ANQP) would already do that and
there may be better ways of doing that in mobile devices. Anyway, yes,
you could probably reduce identifiability of the device to some extend
by changing the MAC address in unconnected state. However, it would not
really fully prevent you from being tracked if the device is doing
active scanning for specific SSIDs or exposing some similar recognizable
behavior in frame contents or timing. Obviously, that is more complex to
do, but this comes to the question of whether this is good enough to
justify the implementation complexity vs. working on a more complete
solution that avoids many of the issues with a design where
wpa_supplicant simply changes the local address every now and then.

> Using randomized MAC addresses in association states would be ...
> complicated, I agree. Actually, if that's what we're talking about, I
> would think just changing the MAC address on the interface with
> IFLA_ADDRESS or whatever would suffice, no? Is there a use case where
> one might want to keep the real address on the interface but
> nevertheless use random addresses in associations? I don't think
> cfg80211/mac80211 API changes would be an easy sell, and, in any
> event, I don't think I'm the man to advocate for them. :(

There are many different levels of protection you can get. What is
sufficient is subject to debate. If both AP and station side changes,
over-the-air addresses could be made completely temporarily (and change
even during an association) and mapped to a more permanent address for
secure networks if required.

My initial target was to do simple cfg80211 changes to enable random
source address for scan/GAS use. Changing the interface address would be
even simpler, but somewhat more problematic from the view point of other
applications, approach.
 
-- 
Jouni Malinen                                            PGP id EFC895FA



More information about the Hostap mailing list