"Back in the Summer of 2-0-5: Implementation of a Wireless Covert Communcation Protocol"
Based on work by myself and Ania Kacewicz under the supervision of Dr. Sanjay Shakkottai
Introduction and Background
The purpose of this report is to briefly describe a covert protocol for "theoretical" use in IEEE 802.11 wireless networks. The protocol was co-developed by myself and Ania Kacewicz in summer of 2005 under the guidance of Dr. Sanjay Shakkottai. The premise for this protocol was  in which the authors describe a game, in which adversaries in a channel pass messages in a Slotted Aloha network, which is a time division multiplex access (TDMA) wireless protocol.
The game is played in the following manner. First the adversaries want to non-deterministically cause packet corruptions of a message in such a way that the corruptions appear to be either noise in the channel (thermal or otherwise) or typical contention seen by all actors.
Challenges in this manner of covert communication first include the possibility that a "legitimate" packet corruption occurs. This corruption may occur because of real noise in the channel or contention between actors trying to send messages at the same time. Another issue of the protocol is discerning whether this packet collision was caused by an adversary or other noise in the channel. The next problem is ensuring randomization of the covert bit stream because if there is an excessive number of packet jams in the channel, awareness of participants is raised with the exponential back-off due to the contention thus resulting in detection. This randomization is issue we address in our protocol is synchronization.
Covert Communication Protocol in IEEE 802.11
In our protocol, we have two main bit states, where "1" represents a jam or packet corruption and "0" represents a packet allowed to pass uncorrupted. Next, we strategically place the adversaries in the wireless network, in such away that they both can hear the same packets and respond accordingly. Otherwise, problems arise due to the "hidden node" problem and simply response time to cause interference on the packet. This "hidden node" happens because a node is out of listening range for another node, which means they can potentially communicate simultaneously and there packets can collide at the wireless access point. IEEE 802.11 deals with this problem by allowing nodes to selectively send a Request to Send (RTS), and the AP responds respectively with a (CTS), which signals to the other nodes that the channel is occupied. The other reason for strategic positioning is to give some improve the chances of a successful jam on a packet. In a wireless network, the radio signal gives us only a very small fraction of time to detect and interfere with a packet.
In the protocol there are at least two adversaries, and then any number of legitimate participants. One adversary is the listener while the other is the sender (e.g. packet jammer). The sender and listener passively synchronize by waiting for a period of silence, which we call the contention window (CW). After this delta of silence, the sender will wait for the next packet and either corrupt the packet or allow the packet to pass with no interference. The listener will also know that they should be listening in this period. Simply because of latencies in the operating system among other things, we also allow for a jamming window (JW), which is a period of time where the sender is allowed to jam and the listener is allowed to listen. After the JW expires, the pair must wait until another CW passes before sending/ listening for another bit of information. If by any chance the CW is interrupted, the sender and listener must reset their timers and wait for the next full CW to pass. Figure 1. illustrates the nominal operation of the protocol, while Figure 2. represents a reset in the CW.
|<Legitimate Traffic (LT)>|<- CW -->|<-- JW ->|<— LT ->|
Figure 1. Successful Protocol Exectuion
|<--—(LT)->|<Silence>|<LT>|<- CW -->|<— JW -—>|
Figure 2. Illustration of the interrupted CW
Other details for the covert communication imply the use of Forward Error Correction Codes and interleaving to protect against channel noise and unwanted corruptions by others in the network. This function could be realized through the use of Turbo Codes or any other error correction code integrated with some sort of bit randomization. The actual jamming pattern is derived by taking our text message converting it to ascii-binary, and then performing the encoding the message stream. The resulting bit stream is then transmitted as the jamming pattern.
We implemented our protocol in Network Simulator-2, which is an academic application used to rapidly prototype and experiment a variety of wireless protocols in a simulated environment. One of the limitations of this implementation however resulted from the fact that the simulator was event based, which prevented the listener from functioning properly. We did however realize that packet jamming was correctly taking place by monitoring the interaction between the sender and the other network participants. As a result, we improvised and acted as the listener and logged the packet jamming activity to file for further analysis.
Since this project was limited in time, we were only able to implement the Huffman and Repition encoding strategies as error correction methods. Repition codes simply duplicate a symbol n-times. When the message is decoded, the number of bits are counted, and the majority of the bits present results in the bit recorded (e.g. more 1's than zeros means that a 1 is recorded for the period). The Huffman encoding is essentially a binary tree of the most optimal code for a given message, where the tree is formed by the given probability weight of a codewords occurence in the message.
Results without Supporting Data
In our experiments, we used only two hosts and an access point as our network participants, and then two hosts as our adversaries. The CTS/RTS functionality of the IEEE 802.11 protocol were disabled, and the actors were set to communicate with the same period sending a moderate amount of traffic. We then employed our Repetition and Huffman encoding and sent our messages. In the experiments, we varied the JW and CW to account for greedy and patient adversaries. For the repition codes we also varied, the number of reptitions for the bits.
From the results we could see that congestion in the network traffic resulted very quickly in the case of the repition codes due to the exponential back-off. This result was not unexpected given that this protocol works similar to that of IEEE 802.3 Ethernet. The Huffman encoding was not much of an improvement, but in this case, the consideration that only two hosts were actually used to transmit traffic should be also taken into account. Regardless, the bandwidth of this channel is very small and could only be utilized for very small messages, and the message could only be passed when the network is moderately active.
1. “Communication Through Jamming Over a Slotted ALOHA Channel,” S. Bhadra, S. Shakkottai and S. Vishwanath. A shorter version appeared in the Proceedings of the 42nd Allerton Conference on Communication, Control, and Computing, Urbana, IL, October, 2004..
2. Wikipedia.org. http://en.wikipedia.org/wiki/Huffman_codes.