Jun 15, 2014 - Android operating system's CPU on the client end to modulate network traffic emitted from the mobile device by purposely adjusting the CPU's ...
Constructing Timing-Based Covert Channels in Mobile Networks by Adjusting CPU Frequency Mengchao Yue
William H. Robinson
Lanier Watkins
Cherita Corbett
Information Security Institute Johns Hopkins University Baltimore, MD, USA
Security and Fault Tolerance Research Group Vanderbilt University Nashville, TN, USA
Information Security Institute Johns Hopkins University Baltimore, MD, USA
Johns Hopkins University Applied Physics Laboratory Laurel, MD, USA
ABSTRACT We have identified a novel wireless covert timing channel (WCTC) that could be used by malware to exfiltrate data from mobile devices. We introduce the WCTC by demonstrating its ability to transmit data covertly: (1) across existing network services, (2) across ICMP pings, and (3) via a trojanized chat application. The WCTC is implemented by manipulating the Android operating system’s CPU on the client end to modulate network traffic emitted from the mobile device by purposely adjusting the CPU’s speed to send a binary 1 or 0. The data is recovered and deciphered on the receiving end by applying a simple threshold to the average inter-packet spacing of a fixed number of packets within a bit stream sent by the client. To our knowledge, there only exists intrusive methods to defeat this type of channel. We characterize this potential threat by determining: (1) its channel capacity, (2) the accuracy of its data transmission, (3) the effects of network hops on its accuracy, and (4) the minimum mobile device signal strength required to maintain 90% or better message recovery.
Categories and Subject Descriptors D.3.3 [Mobile Security]: Android mobile devices – CPU scaling
General Terms Experimentation, Security.
Keywords Android, mobile devices, security, CPU scaling, covert channels
1
INTRODUCTION
A covert channel is any method of communication that is used to transfer information illicitly, thus breaking the security policy of the system. Any shared resource can potentially be used as a covert channel. Thus, covert channels can be a serious threat to the security of a network. By using covert channels, malicious applications on Android-based smartphones are able to subvert the permissions system and share data in a potentially untraceable Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. HASP '14, June 15 2014, Minneapolis, MN, USA Copyright 2014 ACM 978-1-4503-2777-0/14/06 $15.00. http://dx.doi.org/10.1145/2611765.2611768
manner. These channels are easy to exploit today, and have enough bandwidth to transmit sensitive information in real-time between collaborating applications [1]. In this paper, we focus on: (1) establishing the feasibility of WCTC and (2) understanding its information capacity. We demonstrate the ability of the WCTC to transmit data covertly across existing network services, across ICMP pings, and via a trojanized chat application. Then we detail the process used by the receiver to recover the covert data. Also, we discuss how theoretical covert timing channel elimination methods could be used to reduce the threat of WCTCs. The paper is organized as follows. Section 2 discusses the motivation for our work. In Section 3, we describe how CPU scaling is exploited to implement this covert timing channel. We discuss how bits can be channelized in Section 4. Sections 5 and 6 present our experimental testbed and the corresponding results. In Section 7, we discuss related work, and finally, in Section 8, we conclude the paper and discuss future work.
2
MOTIVATION
The Android operating system (OS) has the largest market share of any mobile device OS on the planet [2]. So, there is no surprise that it is the most targeted mobile OS by malware writers [3]. Our proposed WCTC is an example of the potential threat to the security of the network. We describe the basic operation of the WCTC and its capability within a mobile environment.
2.1
How Does It Work?
The WCTC was motivated by the observation that mobile devices with an Android OS use CPU scaling as a power management tool (see Section 3 for more detail). This is critical, because the authors in [4] have demonstrated that network traffic sourced from an Android mobile device varies directly with the CPU load of the executing mobile application (i.e., a higher CPU load drives a higher CPU throttled speed). For instance, Figure 1 illustrates that the average inter-packet (IPS) of network traffic from a low CPU-intensive application is discernible from the network traffic from a high CPU-intensive application. Consequently, by explicitly setting the CPU speed high or low, binary information could be transmitted from the mobile device in the same way. Another way to interpret Figure 1 is to assign the experimental trials in the bottom half as all zeros and the trials in the top half as all ones.
2.2
How Can It Be Used?
Since mobile devices have become so powerful, they are beginning to take the place of personal computers, therefore mobile devices contain many different types of personal data (e.g.,
3
HIJACKING ANDROID’S CPU FREQUENCY SCALING 3.1 Overview The Android operating system (OS) has a Linux kernel. As to processor frequency management (i.e., CPU scaling), Android uses the same technology adopted in Linux (i.e., governor). The goal of CPU frequency scaling is to save power. By default, the OS will automatically scale the CPU frequency depending on the system load [5]. Also, users can manually scale CPU frequency by using the Android Debug Bridge or adb shell on a rooted device to interact with the governor.
3.2
Figure 1. Nexus S Google Phone Experiments [4]. credit card numbers, passwords). Once malware gains control of a mobile device, then all of this personal information is potentially compromised. We envision an attacker using our WCTC as a conduit to exfiltrate personal data from mobile devices down to a file server that he controls. As illustrated in Figure 2, the attacker could either remotely or directly gain control of a file server within an organization and upload trojanized mobile applications that mobile users are likely to install. Once the malware is installed, it will locate the targeted personal data and send it back down to the compromised server. Most importantly, the WCTC offers the ability to send data in the inter-packet spacing of legitimate network traffic, such as: (1) trivial file transport protocol TFTP) traffic, (2) user datagram protocol (UDP) traffic, or (3) internet control message protocol (ICMP) traffic. This means that the malware could start a legitimate TFTP file transfer session or chat session and use the WCTC to exfiltrate the personal data within the inter-packet spacing of the file transfer or chat session. Also, the attacker could simply ping the compromised mobile device, and the malware could use the WCTC to exfiltrate personal data in the inter-packer spacing of the ICMP request and replies.
Governor
The governor is a set of pre-defined instructions provided by the Linux kernel to the processor that determines how and when the CPU’s speed will vary. There are many different governors. In this paper, we used the Performance governor, which always sets the processor frequency to the maximum frequency in order to improve the mobile device’s responsiveness. In reality, many mobile device users prefer the Performance governor for this very same reason. This governor allows us to set the mobile device’s CPU speed explicitly to either the maximum or minimum frequency to send a binary 1 or 0.
3.3
Scaling CPU Frequency Via ADB Shell
In our feasibility experiments (Sections 5.2.1 and 5.2.2) we manipulate the CPU speed of the mobile device by using the adb shell. The adb shell is a command line tool that allows the user to communicate directly with an Android mobile device. We use the adb shell to set the CPU speed to its maximum value and send 100 packets to represent a binary 0, or we set the CPU speed to its minimum value and send 100 packets to represent a binary 1. This is done by writing the minimum or maximum value into the folder sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq. For the ICMP experiments, using the adb shell, we look at the wireless interface and determine when the mobile device has sent 100 ICMP packets. Then we write the maximum or minimum value to the specified directory to set the CPU speed to represent binary 1 or 0. We proceed in this manner continuously. Similarly, for the TFTP experiments, we write the maximum or minimum value to the specified directory to set the CPU speed to represent binary 1 or 0. Then we use the adb shell to TFTP a file to the monitor node which takes 100 packets exactly.
4
CHANNEL FRAMING USING ASCII
Instead of simply sending binary digits down the covert channel, a more sophisticated approach can be taken. An actual channel framing scheme can be formulated and implemented to better organize and protect the integrity of the data transferred across the covert channel.
4.1 Figure 2. Cyber-theft scenarios
ASCII Encoding
We chose ASCII as the character-encoding system. It builds on the English alphabet that encodes 128 characters including the numbers from 0-9, the letters a-z (lowercase and uppercase) and
some other special characters into 7-bit binary integers. Because every ASCII character can be represented by a fixed 7-bit binary string, transport of an ASCII character can be done just by sending a binary sequence of ones and zeros. For instance, Table 1 shows the ASCII and binary representation of the word “hello”. Table 1 Normal Network Traffic Characters
h
e
l
l
o
ASCII Value
104
101
108
108
111
Binary String
1101000
1100101
1101100
1101100
1101111
4.2
Figure 3a. Experimental Setup
Channel Framing
Chanel framing is essential for synchronization and decoding on the server side. We implement a simple framing scheme. To denote the start bit, we add a binary 1 to the beginning of the 7digit ASCII binary value, and we add a binary 0 to the end of the 7-digit ASCII binary value. As a result, each ASCII character is framed by a 9-bit binary string. These binary strings are encoded into the inter-packet spacing of network traffic by the WCTC. As an example, Table 2 illustrates the framing of the characters of the word “hello.”
Table 2 Channel Framing
Figure 3b. Three hop WCTC over TFTP experiment
5.2
Characters
Binary Value
Framed Binary Values
h
1101000
111010000
e
1100101
111001010
l
1101100
111011000
l
1101100
111011000
0
1101111
111011110
Our experimental procedure has four parts. We demonstrate the feasibility of the WCTC at excellent signal strength over: (1) TFTP network traffic, (2) ICMP network traffic, and (3) chatbased network traffic. Lastly, (4) we further characterize the WCTC by determining or discussing: its channel capacity, effects of network hops on accuracy, effects of signal strength on accuracy, and battery life impacts.
5.2.1
5
EXPERIMENTAL EVALUATION
In this section, we discuss the design and experimental evaluation of the WCTC. Our inspiration stems from the fact that by manipulating CPU throttling, distinctions in network traffic can be observed.
5.1
Experimental Setup
The experimental setup consists of the following items: 1. 2. 3. 4. 5.
HTC T328W, Motorola Backflip Android-based smartphones and a Kyros Anroid tablet A wireless access point A laptop used as a backend server A laptop used to connect to the mobile device via adb shell Custom scripts and a mobile application a. An android-based application that implements the WCTC over a UDP-based chat program b. A custom script that implements the WCTC over tftp c. A custom script that implements the WCTC over ICMP d. Custom server scripts (MATLAB and C#) to recover the covert message
Experimental Procedure
TFTP Network Traffic
We use the setup in Figure 3a to send a continuous stream of 1s and 0s across a wireless network. First we use a custom script running in the adb shell from the interface laptop to: (1) set the CPU speed to CPUmax, (2) transmit a file via TFTP to the backend server, (3) pause for one second, (4) set the CPU speed to CPUmin, and, (5) repeat this process. The back-end server captures the delta delays between successive packets, averages them, and compares the averages to a pre-defined threshold. Average inter-packet spacing values above the threshold are logged as a binary 1 and vice versa for binary 0.
5.2.2
ICMP Network Traffic
We use the setup in Figure 3a to send a continuous stream of 1s and 0s across a wireless network. First, we use a custom script running on the backend server that pings the mobile device, captures the timestamps of the responses, and calculates the interpacket spacing. The average inter-packet spacing for 100 packets is calculated and compared to a predefined threshold. Average inter-packet spacing values above the threshold are logged as a binary 1 and vice versa for binary 0.
5.2.3
Chat-Based Network Traffic
Using the setup in Figure 3a, we developed a UDP-based Android chat mobile application that sends an overt chat message and a covert message. The chosen overt message is “hello” and the covert message is a continuous stream of 1s and 0s. The overt message is sent in the payload of the packets, and the covert message is sent in the inter-packet spacing of adjacent packets. This is done by setting the CPU speed to CPUmax, sending 100 packets, to the backend server, pausing for one second, setting the CPU speed to CPUmin, and, then repeating this process. The backend server captures the delta delays between successive packets, averages them and compares the averages to a pre-defined threshold. Average inter-packet spacing values above the threshold are logged as a binary 1 and vice versa for binary 0.
5.2.4
Figure 4. WCTC over TFTP
Characterizing the WCTC
The characteristics of the WCTC that are in scope for this paper are: (1) channel capacity, (2) effects of network hops on accuracy, and (3) effects of signal strength on accuracy and battery life. We calculate the channel capacity by determining the number of packets that can be sent over a standard 802.11g link per second at a given signal strength; then we divide this number by the number of packets it takes to encode each binary digit. To determine the effects of network hops on WCTC accuracy, we use the same procedure as in Section 5.2.1, except we use the setup in 3b; then we determine the accuracy of the WCTC. To determine the effects of signal strength on accuracy, we modified the chat application from Section 5.2.3to allow the user to enter a covert message. The covert messages will be: (1) “Redshoe”, a potential password, and (2) “CH9300762011623852957”, a potential Swiss Bank Account number. Next we determine the accuracy of the WCTC at excellent signal strength (i.e., 54 Mbps), and then we separate the access point and the mobile device until the signal strength is good (i.e., 48 Mbps) and determine the accuracy of the WCTC. Finally, we discuss battery life impacts in terms of game play.
6 RESULTS AND DISCUSSION 6.1 WCTC Feasibility As a feasibility study, we demonstrate that the WCTC can be implemented over traditional network services like TFTP. Figure 4 illustrates how the average inter-packet spacing of TFTP network traffic is used in conjunction with a threshold predetermined (based on previous network traffic produced from this specific device at excellent signal strength) to decipher the WCTC.
Table 3. Experimental results for deciphering the WCTC over TFTP Covert Message
Wrong
Right
Correctly Received
Model
Continuous 1s and 0s
09
191
95.5%
Backflip
In addition, the red line represents the threshold separating binary 0 from 1; it is applied to every value in Figure 4.All values above the threshold are considered a binary 1 and those values below the threshold are considered a binary 0. The accuracy in Table 3 is above 90%, thus we assume it is feasible to implement the WCTC over TFTP. As an additional feasibility study, we also demonstrate that the WCTC can be implemented over traditional network services like ICMP. Figure 5 illustrates how the average inter-packet spacing of ICMP network traffic is in conjunction with a threshold to decipher the WCTC. Similarly, 20,000 packets were sent for the experiment in Table 4. Then the average inter-packet spacing for every 100 packets is calculated and applied against a threshold. The accuracy in Table 4 is greater than 90%; thus we assume it is feasible to implement the WCTC over ICMP.
There were a total of 20,000 packets sent for the experiment in Table 3. For every 100 packets, the inter-packet spacing was calculated and averaged, and the results are the packets illustrated in Figure 4.
Figure 5. WCTC over ICMP
Table 4. Experimental results for deciphering the WCTC over ICMP
Table 5. Experimental results for deciphering the WCTC over a chat-based mobile application for continuous 1s and 0s
Covert Message
Wrong
Right
Correctly Received
Model
Covert Message
Wrong
Right
Correctly Received
Model
Continuous 1s and 0s
12
188
94%
Kyros
Continuous 1s and 0s
29
471
94%
Backflip
Continuous 1s and 0s
6
494
99%
HTC
For another experiment, we use the adb shell to examine the wireless interface and determine when the mobile device has sent 100 ICMP replies. Then we set the CPU speed to the maximum or minimum value to represent binary 1 or 0. The data in Table 4 suggests that the WCTC can be accurately used over ICMP services.
6.2
WCTC Mobile Application Implementation
We implemented the WCTC in a traditional UDP-based chat client/server mobile application. Figure 6 and Figure 7 illustrate how the average inter-packet spacing of UDP network traffic is used in conjunction with a threshold (based on previous network traffic produced from this specific device at excellent signal strength) to decipher the binary bits. The data in Table 5 suggests that the WCTC can be accurately used over chat-based services.
Similar to the other feasibility test, we test a continuous stream of 1s and 0s over chat-based services. The application sends an overt message inside of the data packets and the covert message in the inter-packet spacing. We send 50,000 packets, and we use two different mobile devices to demonstrate the robustness of the approach. The data in Table 5 suggests that the mobile application can accurately transmit binary data over the WCTCs.
6.3
Characterizing the WCTC
First, we calculate the channel capacity of the WCTC by using the following equations:
∗
Figure 6. WCTC over chat-based network traffic for Backflip
.
(1)
(2)
In Equation 1, NPPS represents the number of packets per second, and in Equation 2, CPS represents the number of characters per second. Given 54 megabit per second as the bandwidth and 1500 bytes as the max ethernet packet size, the number of packets per second (i.e., Equation 1) for the WCTC is 4,500 packets per second. Using 4,500 packets per second and n as 100 for Equation 2 yields 45 bits per second or 5 ASCII characters per second (i.e., 45 bits per second divided by 9 bits per frame) as the channel capacity for the WCTC. This is very low bandwidth for large data transfers, and can be increased by choosing n to be values lower than 100. For instance, if n is 10, then the bandwidth is increased by a factor of 10; however, we have not tested the accuracy of the method using lower values of n. This will be reserved for future work. This issue is mitigated by the fact that the present low bandwith is sufficient for sending credit card numbers, bank account numbers, passwords or keystrokes. For example, it would take 3.2 seconds (i.e., 16 digits divided by 5 ASCII characters per second) to transfer a 16-digit credit card number, and 6.8 seconds to transfer a 34-digit Swiss bank account number.
Table 6. Experimental results for deciphering the WCTC over TFTP across an enterprise
Figure 7. WCTC over chat-based network traffic for HTC
Covert Message
Wrong
Right
Correctly Received
Model
Continuous 1s and 0s
1333
8667
86.7%
Backflip
mitigate this issue. Finally, in terms of the WCTC’s impact on a mobile device’s battery, it has no greater impact than playing an online game for a few seconds (i.e., it takes only 3.2 seconds to transfer a credit card number and 6.8 seconds to transfer a bank account number). Recall that the WCTC works by controlling CPU throttling (i.e., setting the CPU speed to CPUmin to send a binary 0 and CPUmax to send a binary 1) which in itself is a power management function, so whenever a binary 0 is sent, the device is actually being placed into power save mode. In other words the operation of the WCTC, which is mostly in short durations, continuously places the mobile device into either power save or maximum use mode. Figure 8. WCTC over TFTP through 3 hops bits 1 - 500
6.4
Limitations of the WCTC
Our chat-based WCTC is limited in that it requires no more than one network hop and excellent signal strength. These limitations are not critical, because they could be mitigated by adding functionality to the WCTC. Adding such functionality as a module to test the traffic patterns of the network before sending packets, and using TCP as the transport protocol instead of UDP would allow the WCTC to maintain a certain level of accuracy across multiple hops and less than excellent signal strength. The additional functionality mentioned in this section will be pursued in future work. Figure 9. WCTC over TFTP through 3 hops bits 8000 - 8500 We determine the effects of multiple network hops on the WCTC accuracy by sending packets over 3 hops (i.e., 2 switches/access points and 1 router) using TFTP. The accuracy results are illustrated in Table 6. In contrast to the data in Table 3, which are the results from the same experiment except over 1 hop (i.e., switch/access point), the accuracy dips below 90%. Multiple network hops add delays to the network, and corrupt the WCTC channel. This effect could probably be neutralized if the traffic pattern of the network can be anticipated in advance. The effects of heavy traffic on the network can be seen in Figure 8, and the effects of light traffic can be seen in Figure 9. We will investigate easy implementable ways of determining a network’s traffic patterns in future work. To test the effects of signal strength on WCTC accuracy we modified the chat application from Section 5.2.3 to allow the user to enter an alphanumeric covert message that gets converted to a binary message and then transferred across the WCTC. At excellent signal strength (i.e., 54 Mbps) the application was consistently and accurately able to send the covert messages: (1) “Redshoe”, and then (2) “CH9300762011623852957.” As soon as the signal strength drops to good (i.e., 48 Mbps), no covert messages are able to be deciphered across the WCTC due to minor UDP packet loss. This is problematic, because the covert messages are encoding in the inter-packet spacing of 100 packets. When packets are lost, the ability of the receiver to decipher the binary information becomes out of sync, and the received information is corrupted. In future work we plan to use TCP/IP, which should allow us to keep track of missing packets and
7
RELATED WORKS
Below are several timing covert channels which could be considered to be similar to the WCTC. All of them either externally manipulate network protocols or network traffic directly, involve non-standard communications (i.e., vibrations or volume) or colluding processes on the same device. The WCTC is unique in that it involves the use of mobile hardware (i.e., CPU speed) to indirectly influence standard network traffic before it is sent to the wireless network. The detection methods mentioned in Section 7.2 provide information regarding traditional methods to detect covert channels. To our knowledge, only the methods mentioned in [10] are effective in defeating covert timing channels; however, these methods are considered too intrusive to the network to actually be implemented.
7.1
Timing Covert Channels
In [6], the authors proposed TCP-Scrip a TCP-based timing channel. TCP-Script embeds messages in normal TCP data bursts and exploits TCP's feedback and reliability service to increase the decoding accuracy. Their theoretical capacity analysis and extensive experiments have shown that TCP-Script offers much higher channel capacity and decoding accuracy than an IP timing channel. There are four components in the model considered in this paper: an encoder, a decoder, a server, and a warden. The encoder and warden are in a close proximity in terms of communication delay. The warden can monitor and analyze all the incoming and outgoing network traffic, including those from the encoder's machine. The goal of the encoder is to leak out information to the decoder outside without being detected by the
warden. In so doing, she establishes a normal TCP connection with the server outside her network and embeds messages in the TCP data channel. The decoder, on the other hand, can eavesdrop on the segments sent from the encoder to the server. In [7], the authors design and implement a TCP-based covert timing channel. In their design, they use packet inter -transmission times to convey information. A malicious process on the sender side manipulates the inter-transmission times, while another malicious process either at the receiver or en route to the receiver can decode the privileged information by observing the interreception times. They encode L-bit binary strings in a sequence of n packet inter-transmission times T1, T2, …, Tn. They call it the “L-bits to n-packets” scheme. These n packets are transmitted in variable length time intervals. The receiver will then map the npacket inter-reception times R1, R2, …, Rn back to an L-bit binary string according to the code book. In [8], the authors define and implement an Android-based covert timing channel that does not require special permission from the user. The authors select vibration as the media to transmit the data. The vibration channel uses a system-wide notification event to transmit bits (3-state vibration setting = 1.6 bits per event). In the “Idle Foreground” condition, the Droid was able to send 100 events (160 bits) in less than half a second. The authors were able to send a 3000 bit message on the Droid in approximately six seconds, a rate of 500 bps. The G1 cellphone, however, was able to sustain a bit-rate of only 110 bps. The authors mention another covert channel, which is called a volume channel. The volume channel polls the media stream volume continuously and detects changes to the volume level (8 possible values). Under the “idle foreground” condition, further experiments gave a sustained rate of 101 bps that could be achieved on the Droid, and a rate of 83 bps on the G1 cellphone. In Cioranesco et al. [9], CPU usage monitoring is used by colluding remote users on different cores of the same computational grid to create a covert timing channel. The sender modulates the CPU usage (i.e., using short and long CPU intensive tasks) on its core to send binary data, and the receiver monitors CPU usage on sender's core to gather the binary data. Zander et al. [10] mentions several types of timing covert channels in their covert channel survey paper. The first method mentioned involves a synchronized sender and receiver where the sender either transmits or stays silent to send a binary 1 or 0. The next method traditionally modulates the packet timing; however, no synchronization is required because the covert information is encoded directly in the inter-packet delays of the consecutive packets. The last method uses an intermediary which receives packets from the sender and sends packet to the receiver. Since the clock skews of a node is dependent on the CPU temperature, which is dependent on the number of packets per time unit processed, the sender can either send or not send packets to the intermediary to represent a binary 1 or 0. The receiver can estimate the clock skew by examining packet timestamps. Another timing-based covert channel [11] results from externally
(i.e., outside of the node) modulating the network traffic. Since this network traffic is artificially manipulated, these types of covert channel are easier to detect. Some timing-based covert channels are similar to this method, but they are used for colluding processes on the same device [12].
7.2
Detection of Timing Covert Channels
The main topic of [13] is detection of two kinds of covert channels. First, the authors mentioned covert channel detection in IP packets. Specifically, the option, ID, and the source IP address fields are employed for establishing covert channel communication. The option field in comparison to other fields is used less as this field typically gets removed by routers and firewalls. Goher et al. provide an overview of the different methods that can be used as a carrier of steganographic covert channels by modifying TCP/IP header fields and different techniques related to the detection of these covert channels. Next, the authors mention covert channel detection in TCP communications. The sequence number is initialized with an initial sequence number pseudo value. After the initialization of sequence number, it is incremented, and it does not change throughout that session. Thus an attacker can transfer the information in the initial sequence number value. Then the authors discussed detection of timing covert channels. The detection is made possible by attempting to find the regularities in inter-arrival times that must exist for the existence of a covert timing channel. The main topic of [14] is the detection of timing covert channels. Detection relies upon discerning the underlying regularity that must be present in the packet inter-arrival times (PIATs) in order for the channel to carry information. The author’s idea is that the bits that are being extracted likely reside in memory at some point during the transmission, and any correlation between memory content and inter-packet time delays, even a remote one, is no coincidence. This correlation could likely suggest an active timing channel. Furthermore, even if the data have been encrypted prior to transmission, at least a portion of the corresponding cipher-text should reside somewhere in the address space used by the rogue process. In [2], the authors discuss a very simple but powerful technique to identify covert timing channels by capturing network traffic, calculating the inter-packet spacing of network traffic, and taking the histogram. Then they determine if two prominent peaks emerge, which denotes attempts to send binary information. Zander et al. [10] mention several types of methods to defeat covert timing channels, even though they admit that these methods are unlikely to be actually implemented on current IP networks due to their intrusiveness. The first method adds noise to the clock in the system in an attempt to disrupt outgoing packet timing. The next method is referred to as link padding, where the send rate of flows is forced to a specified rate by delaying packets or injecting dummy packets. The authors also mention a simpler method than link padding where several additional packet rates are introduced into the link. Another method is similar to game theory where a jammer attempts to retime the packet send rate of a
sender-receiver pair such that the covert channel is defeated or its capacity significantly lowered.
8
SUMMARY AND FUTURE WORK
In this paper, we have identified a novel timing-based covert channel that relies on CPU frequency adjustment. One of its advantages is its difficulty to detect. The only methods that we are aware of to defeat this timing covert channel are those that are intrusive to the network as a whole, where all network flows are purposely delayed and forced to conform to a specified rate [10]. Future work includes adding more features to the WCTC to improve data confidentiality and integrity such as CRC algorithms to detect and fix errors or adding a shared secret to add flexibility to receiver deciphering. In other words, before sending a covert message, two parties can negotiate using a special mechanism to transfer message. One possible method is that two parties use the Fibonacci sequence to encode the set of packets and to identify the set of packets which contain the encoding in their spacing. For instance, consider the first six Fibonacci numbers (i.e., 1, 1, 2, 3, 5, 8). The sender would encode the first packet along with the next n packets, then the second packet after that set along with the next n packets and then the third packet after that set along with n, where n is chosen by the sender (we used n = 100 in our experiments). This would improve the confidentiality. Also, we would like to revise the chat application using: (1) TCP/IP to keep track of missing packets when the mobile device is far from the access point, and (2) network traffic prediction techniques to allow for multiple hops. Finally, we would like to test the accuracy of the WCTC using lower values or n (i.e., n
