# MAC Address Anonymization for Crowd Counting
## 1 Introduction
### Collected Data and the Anonymization Procedure  
As depicted in Figure 2, sensors extract three key data from each PR: (i) a timestamp (whose precision is of one second), (ii) a received signal strength indicator (RSSI) in dBm and (iii) a source address (SA) (MAC address). Although some smartphones randomize the SAs embedded in PRs, it is not guaranteed and we want user tracking to remain impossible, even without terminal-side SA randomization. Thus, we transform the original SA into an _SA identifier_, which is its anonymous counterpart. To generate an _SA identifier_ from an SA, we use a SHA-256 hash function in conjunction with a pepper and truncate its output to 64 bits. With \(\{0,1\}^{\gamma}\) denoting the set of all binary sequences of \(\gamma\) bits, our anonymization function is \(h:\mathcal{X}\rightarrow\{0,1\}^{64}\), which is a truncated SHA-256 hash function whose inputs are 48-bit SAs (\(\mathcal{X}=\{0,1\}^{48}\)). Note that generating SA identifiers of 64 bits is advantageous as such binary sequences can be easily stored as long integers in most databases (e.g., using the standard SQL BIGINT data type). We prepend a time-varying pepper to every MAC address before hashing it. With \(||\) denoting the concatenation operation, and mac_address and global_pepper representing, respectively, the MAC address (i.e., the SA) to be anonymized and the pepper prepended, \(h(\texttt{global\_pepper}||\texttt{mac\_address})\) generates the SA identifier. Figure 1: Scheme of the PR sensing procedure. Three WiFi sensors with overlapping ranges detect WiFi probe requests emitted by the smartphones of individuals. The shaded ellipses and the associated cones depict sensor detection ranges. Each sensor uses HTTPS links to periodically retrieve server peppers from the central server and uses another HTTPS link to upload anonymized PRs. Time synchronization is achieved by calibration with NTP servers. Communication links are depicted for only one sensor to avoid clutter. The pepper consists of a concatenation of a fixed 128-bit _sensor pepper_ and a time-varying 128-bit _server pepper_. The central server maintains an up-to-date array of 20 server peppers for a duration of 20 min that sensors periodically fetch using an HTTPS link with transport security layer (TLS). Sensors use each server pepper for a specific _one-minute time frame_. Server peppers are generated using a pseudo random number generator (PRNG) (e.g., /dev/urandom or /dev/random on Linux). If this PRNG is deemed not secure (see [6]), hardware PRNG generators are alternatives [7; 8]. The server and the sensors delete server peppers once they become outdated; in particular, the sensors erase the volatile memory chunk storing server peppers before updating it with new peppers periodically retrieved from the server. The fixed sensor pepper forms a last line of defense in case the server peppers get compromised. It is written in a file or in the codebase of the sniffer, and it is never stored on the server. We have proposed a fixed sensor pepper but storing pregenerated sensor peppers for time frames of one minute is possible too; it would represent 42 MB of data for five years. Loosely speaking, the time-varying and eventually forgotten pepper has a high entropy and breaking the anonymization scheme is about finding out its value for all one-minute time frames of interest. As we show thereafter, this procedure is not computationally tractable. We also explain why SA identifiers generated using different peppers cannot be compared against one another, thereby precluding user tracking. Moreover, despite the data distortion that our anonymization procedure entails, we also demonstrate that it does not affect in any significant way the output of our counting method (a procedure that we explained in more details in [3; 5]). Intuitively, anonymization cannot affect counting if the SA identifier of any SA is identical across all sensors at (almost) all time instants.