Regardless of whether the binary stream is the data itself or whether it represents a message, additional bits are usu- ally included in the transmission for three reasons. Firstly, additional parity bits may be appended to the data to add redundancy for error correction due to transmission errors (e.g., errors arising when a packet is lost). Secondly, addi- tional bits may be added for purposes of maintaining syn- chronization between sender and receiver. Finally, the data may be encrypted in order to add a further layer of privacy and obfuscation. This third issue is beyond the scope of this paper because our detection schemes are concerned with de- tecting only the presence of a covert channel, and are not designed to infer the content of such channels.
The message for transmission is subdivided into smaller blocks of binary data, referred to as frames in this paper. An example frame consists of data bits, synchronization bits, and error-correcting bits. While all the frames are of equal length, the actual length, as well as the interval between frames, is influenced by parameters of the encoding scheme and the network. This is further examined in Section 3.4, where we look at synchronization issues. Note that although one can employ error-correcting code bits, we have not in- cluded this option in our initial implementation.
The IP covert timing channel can be configured to run on any application port. Because the traffic pattern is expected to vary based on the application, choice of the protocol in which to hide the channel can affect detection ability. In- deed, we illustrate this empirically in Section 4.
In our experiments we have assumed a unidirectional com- munication model for the covert channel. Note that only the covert communication is assumed to be unidirectional; the communication itself is still bidirectional and the TCP/IP packets are ACKed. Assuming a unidirectional channel means that the receiver side cannot communicate with the sender of the covert channel using the covert channel itself. Restricting the channel to be unidirectional increases the difficulty in implementing an error-free channel. In particu- lar, the receiver cannot 1) acknowledge the correct receipt of covert packets, 2) rate limit the sender, or 3) indicate when
to resynchronize. We also receiver have the software packets.
assume that both the sender and to send/receive the covert channel
Several factors impact the performance of a network tim- ing covert channel.
Network conditions: The channel performance is directly affected by the network conditions between the com- municating parties. During the peak hours, when a congestion is likely, IP packets are more likely to be delayed, arrive out of order, or be lost during trans- mission. Additionally, jitter, which is the variability in round trip times (RTT) can cause synchronization problems.
Sender/receiver processing capabilities: The
and receiver processing units may be congested under heavy load (e.g., a web server observing high traffic at peak times). Under these conditions, the processing of the packets may be delayed. The bottleneck could be either the network processing card or any other busy resource that might delay packet processing.
The complexity of the algorithms: The
used in designing the communication channel should
be efficient. decrease the
In our experiments we were able to timing interval to millisecond precision,
hence the socket algorithms than this interval to meet the
should operate data rate.
The portability of the programming language: The synchronization of the channel depends solely on the correct and consistent functionality of program subroutines and the libraries used. One example is the nanosleep subroutine. The operation of these subroutines should be standard in different operating environments (e.g., same precision in both sender and receiver).
All four factors affect the packet synchronization, max- imum allowable bandwidth, and may introduce noise into the channel. Some of these factors can be mitigated (e.g., complexity and portability) by efficient design and imple- mentation methodologies. Others, such as varying network conditions, need more intelligent mechanisms to cope with them. We come back to this problem in Section 3.4 where we present different mechanisms for decreasing noise and for resynchronizing the channel.
We implemented our covert channel as a client and server using Berkeley sockets library in C for our communication protocol, and Python version 2.3 to encode/decode the data sent on the channel and as a wrapper that called the C library functions. This software was developed for and ran under RedHat Linux 9.0 kernel version 2.4.20.
The effective operation of the channel depends on synchro- nization between the sender and receiver. In our implemen- tation, the receiver initially listens on a blocking socket, and is therefore suspended until the initial transmission, called the start of frame (SOF), arrives. It then continues execut- ing and checks whether a packet arrives during the covert in- terval over non-blocking sockets. At the end of the frame, it reverts to a blocking socket until the next SOF. This scheme does not entirely solve the synchronization problem and sev- eral other schemes are discussed in Section 3.4.
Given the encoded message, the sender sends a packet in the middle of the timing interval for each 1, and stays silent for each 0. Before sending the data bits of a frame, the sender sends the SOF denoting the beginning of frame.
Determining the Timing Interval
The bandwidth of the timing channel is determined by the choice of timing interval, which is the interval between suc- cessive transmissions. The smaller the interval the higher the transmission data rate. The bandwidth of the chan- nel can be made as high as the processing speeds that the receiver and sender allow. There is a tradeoff though, be- cause network jitter, scheduling in the system, and clock skew increase the probability of errors as the timing interval is decreased. In Section 3.5 we explore this tradeoff experi- mentally.
The time interval of the channel must be known to both the sender and receiver for communication to be successful. It might be established by default, set ahead of time, or the sender could use a storage channel in the initial SOF packet to communicate what the interval will be.