Hey there,
I am currently working on my thesis and i am trying to see if my AP can recognise his hashed SSID. The goal is that the AP is able to match his SSID to his hashed SSID. Does any one has an idea where i can do such a modification? I am working with a raspberryPi which is running openWrt.
The idea is based on the following paper:
Is your AP running OpenWrt?
I'm trying to understand how is this related to OpenWrt.
Hey, thank you for the question, i forgot to add that.
Yes i am using a RaspberryPi with an OpenWrt, so that i can use the Pi as an access point. Now i want to modify the AP.
Some thoughts on the problem: Hashing could be a nice way to add some privacy. But it can be defeated by a motivated attacker by either guessing the SSID (hashcat), or rainbow tables.
It might be possible to further improve privacy by salting the hash, for that to work the client and AP must find some way to agree on what the salt is. Maybe the AP's BSSID could be the salt?
Thank you for the thought. Yes the idea which is described in the paper is to use a hash and than salt it:
"...To circumvent the need to send cleartext SSIDs, we propose to send them in a hashed and salted manner instead. The device emitting the probe request would first salt the SSID using its randomised sender MAC address and the sequence number of the packet and then hash it. It would then send the hash, but omit both salt components as they are included in the frame anyway like so:
π πππ(βππ β(ππ΄πΆ||ππ||πππΌπ·))..."
Hi,
thanks for the very interesting research topic 
I am not quite sure whether the hostapd ubus interface would be sufficient to achieve the goal, or if this behaviour needs to be implemented in mac80211 and/or even the particular wireless driver.
In case of Raspberry Pi, you are probably dealing with a Cypress SDIO wifi chipset, which is running its own (proprietary closed-source) firmware. I would expect things like dealing with Probe Requests etc. could be offloaded to run in hardware, i.e. would happen within that firmware, but there might also be ways around that.
Regarding wireless chipsets, one of the best supported drivers in Linux is probably ath9k for the Qualcomm Atheros 802.11n chips, which do not have any code run on the hardware itself, but it's basically just a huge set of radio registers, giving the kernel driver full control over the hardware.
So, regardless of the system components to be modified for the implementation (hostapd/mac80211/driver!?), it might be a good idea to acquire some ath9k-based router for testing (you probably also find developers around here knowing that driver more easily), which would basically include all hardware from the ath79 OpenWrt target (preferably those without .ac on 5GHz, since ath10k chips run closed-source firmware again).
As far as I understand, you only need this behaviour for detecting Probe Requests (considering most of them will be unsuccessful while the user is out of the network's reach), and upon a match, the Probe Response would be followed by a regular Association procedure (which would then disclose the SSID, but at least this does not happen in public situations far away from the actual network)?
I think this might be a good question to ask on the openwrt-devel mailing list (maybe even linux-wireless, if there is no solution using hostapd), but you should try to craft your question carefully to attract wireless developer's interest (e.g. include a concise summary of the solution proposed in your paper, like in your last post)
By the way, what does the station side look like, did you have any success on implementing the hashed probing on a real wireless client yet?
Off-Topic:
I have never truly understood the need for the dualism of Beacons vs. Probe Responses in 802.11, like why they could not agree on the specification of a single frame type that would serve both needs.
Considering that other technologies like e.g. DECT have been implementing power save mechanisms for decades now, even sparse wifi networks with only a few clients occasionally connected will pollute the precious channel capacity with a few hundred megabytes of beacons per day, transmitted at the lowest MCS index.
For sparse networks, I've been dreaming of some kind of "probe to beacon" mode, which would monitor the channel for incoming (probably non-wildcard only) Probe Requests, and only startup the "full" AP after a match, and disable it a few minutes after the last client disconnected. This could probably even be done in userspace, by setting the card to monitor mode and filtering frames with airpcap while the AP is off. This would not send a valid Probe Response frame initially, but the client should eventually find the network after some time. Of course this would be cooler to be implemented right in the driver, but unfortunately I don't have the skill and insight to the wireless drivers to implement this.
For your scenario, passive scanning would probably not work since you need this behaviour even while other clients are already connected; very few drivers (like ath9k) should however support parallel monitor and AP mode as well as packet injection, but you would still have to craft your own Probe Responses, which would not be a perfectly clean solution either (but then again, why wouldn't the client find the network from the beacon eventually, even without a proper Probe Response? assuming a non-hidden SSID)