On Thu, Jan 23, 2025 at 03:41:29PM +0000, João Lucas wrote: > The purpose of this patch is to allow configuring wpa_supplicant to generate > pseudo-random MAC addresses by hashing (sha256) the SSID together with the > permanent address, just like iwd does when the AddressRandomization option is > set to "network". This allows having a unique consistent address for each > network without the need for additional per-network manual configuration. Lots of this description from the cover letter should really be in the commit message within the actual PATCH 1/1 email.. The proposed design would use this construction: per-network-address = SHA256(SSID | permanent-address) While it might be fine to use SHA256, or maybe more appropriately HMAC-SHA256(permanent-address, SSID), if permanent-address were a truly secret value that is never exposed. However, it seems quite likely that the permanent address gets exposed, e.g., if there are other network blocks where address randomization is not enabled or even if such cases have existed in the past. If a third party knows the permanent address, it is straightforward to confirm whether a random address used in another network is based on this scheme and as such, track the device. In other words, it is much better to use a truly random value that is generated independently for each network profile. If there is desire to avoid having to store such random value separately, I would recommend finding something else to use as the supposedly secret part in the derivation. This could be a single randomly generated seed value or some other system specific information that is not exposed over the air (and that could be concatenated with the permanent address, if desired). > I'd like to request some opinions because I'm not sure if some things were > implemented in the most ideal way, particularly: > > - The function that generates the MAC address (random_mac_addr_from_ssid) is > defined in the same file from which it is called from > (wpa_supplicant/wpa_supplicant.c), unlike others such as random_mac_addr, > which is in src/utils/common.c. This was because the new function is only > called from there (currently) and the #includes section of common.c seemed a > bit too clean for me to add "crypto/sha256.h" to it; That seems fine for now; the function can always be moved if other uses show up for it. > - The new value for the mac_addr option was appended to enum wpas_mac_addr_style > in wpa_supplicant/config_ssid.h, as number 4. This is a problem because option > 3 should be excluded from the global configuration (wpa_supplicant/config.c, > global_fields[]), while the new option 4 should be included. However setting > the INT_RANGE up to 4 ends up including 3 as well. Inserting it as 3 instead > would break compatibility. That feels acceptable. > Also, if I may suggest: I think it would make more sense to put randomization > style and randomization "range" (full/same_oui) into separate options, since > this range would also be applicable to potential future styles such as this one. > > What do you think? Is this something worth perfecting, or is there no intention > in getting such feature merged? To be frank, I don't really want to see a large number of new slightly different way of generating random MAC addresses to be added. I think there are already unnecessarily many, but things come up when someone decides to make a product requirement of a specific way of doing this and not allowing any other option.. In any case, no, I don't think this part is worth perfecting since the current cases will need to continue to be maintained for existing users and I don't particularly want to promote easiness of adding yet more styles. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
