802.11 has always been an interesting topic of testing, research and security assessment for me. Here I want to talk a little about a recent work of mine that shows how we can turn a built-in protocol feature into a robust covert channel. Since throughout the research, development and presentation phases of this project, I received lots of positive comments, insightful feedback and questions about different theoretical and technical aspects of the work, I found it useful to have a blog post here and have a rather low-level informal discussion of the story. The work was published and presented at NDSS 2025 [1].
Background
IEEE802.11 MAC layer Part 11 states that every access point in any infrastructure basic service set or personal basic service set (which includes all WiFi local area connection networks, or WiFi in general) shall periodically transmit a certain type of management frame which is known as a “beacon” frame. These beacons are what enable a WiFi client device (like your cellphone) to connect to and communicate with an access point (a WiFi network). Each beacon has a vast set of small pieces of information like a DNA sequence that are carried to WiFi devices which are later used to manage different aspects of WiFi association and connection like discovery, naming conventions, encryption and what we want to focus in this article; “synchronization“.
WiFi devices have to synchronize an internal high-resolution timer with that of the access point they are associated with to be able to perform low level radio procedures and scheduling of signals to communicate within the network. The timer must be precise and must be always accurate across the stations in each autonomous network. This timer is loosely referred to as TSF (Timing Synchronization Function). Since the protocol (and naturally the standard text) in nature is quite complex, a clear definition of terms is sometimes lost in myriad of scattered technical descriptions. While TSF can mean a few related things in this context, its purpose and management routine are quite clear and well defined.
The standard mandates that all stations have to synchronize TSF through beacon frames. There’s one certain field in the MAC layer inside each beacon, with a related name (Timestamp) to TSF, that carries the necessary data that stations need to perform their internal synchronization. The timestamp is a 64-bit integer that is populated by the access point firmware to carry the value of the TSF counter the moment the frame is dispatched to the antenna connectors. TSF handlers are implemented at the base station firmware and of course they are in all client NIC drivers. In the example below, the left code is from Realtek 8187 and the right one from Intel iwlwifi.
One of the core stages of TSF management at the AP side is scheduling a new beacon transmission after one TBTT. While an interval of roughly 102ms is inserted between the frames by the firmware, there are some small fluctuations in the real gaps that we can measure between beacons that are sent to the air due to various natural and physical factors like temperature (which affects the resonator frequency) and external radio interference (which can cause nuisance for the medium at the time of transmission). This does not create any problems for the synchronization process between the stations since we still have sufficient beacons per second and basically this type of variance is not even noticeable at the level of normal network operations. There is always some degree of imprecision in various timing components. However, this specific type of noise has the potential to be exploited in a unique way.
We call the micro-second level deviation from TBTT the TSF noise. Observing TSF noise of any access point yields similar results. Mathematical patterns of this type of noise is generally independent from hardware. Now we want to hide a layer of secret data payload in the noise and to keep the mathematical patterns intact, and indistinguishable from ambient TSF noise of any normal access point.
We can define a covert communication protocol solely based on the observed noise in the TSF component of an access point. By targeting the range of [0,1000] microseconds as the variable background TSF noise, we define two parameters delay step (ds) and delay level (dl) to quantify the TSF noise between each two consecutive beacons. The receivers only need to know which access point is taking part in the stealth communication and know the necessary parameters to decode modulated bits from the TSF noise of target access point. An adversary will not see any new frames or even any changes in the benign communication pattern of surrounding stations. It’s just the background TSF noise that exists in the air, with or without a covert channel. The result is that an access point can broadcast a continuous stream of data bits in a completely hidden communication channel; within the natural network ambient noise.
Overview and Experiments
In a recent research project, I was gauging the usability of timing patterns of interval deviations in beacon transmissions to make a covert channel. During the course of investigating different parts of 802.11 raw frames in a series of experiments, I observed a pattern of relatively steady variance in TBTT interval for every WiFi access point that was transmitting beacons in the area. While the existence of the variance itself is expected due to the nature of hardware clock and radio communication imperfections, there was something else about the numbers that encouraged me to dig into the frames and carefully study the specification of the related MAC layer fields in the standard. I noticed that the natural noise that appears in low level WiFi station synchronization strategy has some distinct characteristics that does not generally exist in other network timing components.
My initial idea was that, the constant and disciplined stream of beacons as a mandatory function of the protocol introduces some inevitable side effects that can be exploited to create a covert channel. Simply put, if we define a variable over the distance between the actual time that it takes an access point to transmit the next beacon and the theoretical time that the access point firmware has tried to wait, we can extract a sequence of oscillating numbers that always exist in all WiFi networks and unpredictably change at microsecond scale. What we need, in theory, to exploit these numbers to create a correlation between interval sequences and data bits, is a reliable and precise time measurement at the sender and receiver sides, in a way that both parties can agree on interpretation of this measurement.
----------- ----------- ------------
| beacon1 |===TBTT===v1==| beacon2 |===TBTT===v2== ... | beacon_n |
----------- ----------- ------------
| |
| |
v1 v2 ... v_n
In practice, effective measures must be put in place to reduce and even eliminate the influences of many software, hardware and physical factors that make the measurements look different at either end of communication. While this is doable, there will be obvious costs in terms of a drastic reduction in channel stability and bit rate.
Looking at the frame structure at the MAC layer exposes something interesting that offloads the burden of measurement complexities by using the existing software fields. The access point TSF counter is reported in the beacon timestamp field. This is a standard and necessary task that has been clearly defined in IEEE standard for the purpose of synchronizing TSF among the associated stations. The counter value is written in a 64 bit integer in the MAC frame body.
The noise that we are looking for is directly manifested as an unwanted component within this timestamp value. The beauty of this timestamp is that the magnitude of the transmitter-induced noise can be precisely calculated at the receiver side given the fact that the resolution of the timestamp is high enough to capture the noise, and the existing environment-specific variables that do change the receipt timing patterns, do not change this field. This is a big step forward towards formulating a working agreement between the two parties to create the basis of our mapping strategies.
-----------
| beacon1 |====RADIO.MAC
----------- |
| |
| `--> TS1 ==========
| |
----------- |
| beacon2 |====RADIO.MAC |=== d=TS1-TS2 =
----------- | | |
| | |
`--> TS2 ========= TBTT + (n_i)
Following the sequence of microsecond-level deviations from TBTT through observing the consecutive timestamps lays out a noise pattern which is generated by every single WiFi access point. This is a naturally occurring background noise that we can extract from the MAC layer independently of TX/RX induced noise components which are more difficult to deal with.
Now we can formulate a state-to-data covert transmission channel between a sender and (a) receiver(s) whose details are explained in the paper[1]. But the outcome of this channel is that, the ever-existing TSF noise, while meaningless to others, will be used to convey a separate layer of secret data in a way that only the parties that are involved in the covert communication can make sense of it.
I built a system, chaos, to test and implement this TSF exploitation strategy in practice in real world network environments with all existing restrictions and limitation. Technically, in this system, we need to be able to access and modify raw WiFi frames to carry out our encoding mechanism within the background TSF noise. I implemented the project under Linux and used ETH_P_ALL raw sockets to manage all necessary frame construction, modification and transmission. In chaos, we create a set of normal access points using one or (optionally) multiple network cards, centrally controlled by our code as the management driver. The induced TSF noise of these access points creates our covert channel.
The access points might or might not have SSID tags. What matters is that, they should be known to the transmitter and sender. In other words, a receiver must know which access points to target for TSF extraction. In the example below, I had the code build 10 access points with visible SSIDs of “CHAOS AP nn“, shown in a passive scan by mobile device.
Each WiFi access point is required by standard to broadcast several beacons per second. Huge groups of intertwined beacons are everywhere, flying in variable orders in the air. We use the order of beacons as a factor to expand our transmission permutation space. So the receiver, will need to observe the order of the chosen frames along with the noise levels. The noise is then converted to a delay level for each access point and the then set of delays forms a permutation component which is used for state-to-stream mapping in private sample space that each station builds. So the receiver performs a constant decoding of target AP set and TSF noise to form state sequences and correlate them with permutation sequences.
The specifics of the transmission model have been explained in the paper. Here, I want to go over how the covert channel works in action.
The prototype that I prepared for the tests runs on Linux. For the majority of all tests I used network cards with Intel and MediaTek firmware which turn out to have a better functionality on monitor mode. That said, not all aspects of transmission/receipt depend of the firmware. One of the most important challenges in radio communication is the problem of lost signals. I noticed that frame miss rates are not necessarily dependent on the firmware but the individual NICs. Different NICs with very similar prices can have varying levels of missed frame rates at the RX side. In CHAOS, as explained in the paper, we map batches of beacons to permutation components. When a beacon from one iteration of transmission is not seen by the receiver, it discards the batch and jumps to the next one. The way that the receiver can accurately recover from this situation, is through identifying where a new batch starts and how many batches have been missed by observing the progression of the timestamps or in other words, the time distance between the captured frames. The receiver remembers the missed buffer units and the transmitter rotates over the buffer to give the receiver a chance to recover the missing bits in the next iterations.
burst1 burst2 burst3
------ ------ ------ ------ ------ ------ ------ ------ ------
|bcn1|---|bcn2|---|bcn3|==============|bcn1|---|bcn2|---|bcn3|==============|bcn1|---|bcn2|---|bcn3|
------ ------ ------ ------ ------ ------ ------ ------ ------
| |
| |
------ ------ ------ ------ ------ ------ ------ ------
|bcn1|---|bcn2|---|bcn3| |bcn1|---******---|bcn3| |bcn1|---|bcn2|---|bcn3|
------ ------ ------ ------ ------ ------ ------ ------
| |
| |
-------------------
TBTT misalignment
RX buffer
========FILLED========== ====MARKED AS MISSING=== =======FORWARD SKIP======
------------------------- ------------------------- -------------------------
| x || x || x || x || x | | || || || || | | x || x || x || x || x |
------------------------- ------------------------- -------------------------
|
|
`--> Recovery rotator
This however comes with a cost. Although correctness is guaranteed, we will lose bandwidth. Now there is an obvious point of compromise. If we increase the size of batches (or bursts as called in the paper) we can exponentially increase the size of our permutation space and hence the transmission data rate, however the probability of getting a partial burst at the RX side also increases. So the theoretical data rate hits a hard practical limit. How much the miss rate increases depend on lots of factors, but let’s say we want to use cheap consumer level NICs, with normal capabilities. The same ones that are installed in people’s laptops or you can buy as USB adapters in prices as low as a few dollars.
After carrying out many tests, we concluded that on average, a burst size of 6 beacon frames works very well. It creates a great balance between having a good sample space (the theoretical aspect) by creating about 73k trillion sequences and not having too many missed frames by each receiver (the practical hurdle). The example below shows transmitting an RSA private key suing this covert channel in less than 15 seconds. Transmitter on the left and one receiver on the right.
Note that the burst size here is the size of the AP set that is used for covert transmission. We have mentioned in the paper we have two sets of access points (TXAP and CAP sets). Here we’re talking about the size of TXAP set. Changing the size of CAP set doesn’t affect bandwidth. It is used for another aspect of this covert strategy which has been explained in detail in the paper.
Wrap up
Covert channels have been studied across many communication domains. Interesting strategies invented and various approaches have been proposed in this area. I tried to look at the topic from a fresh perspective using a novel plan. Taking advantage of one of the fundamental WiFi radio routines to establish a covert channel proved to be an effective strategy in this work. While timing components are rampant across all communication protocols, TSF has some scarce and even unique characteristics that make it a great target for this purpose, especially when we consider the commonality of WiFi related technologies.
BitGuard 
Leave a comment