Mobile Netw Appl (2014) 19:79–87DOI 10.1007/s11036-013-0482-7

Quantifying and Classifying Covert Communicationson Android

Raquel Hill · Michael Hansen · Veer Singh

Published online: 6 November 2013© Springer Science+Business Media New York 2013

Abstract By exploiting known covert channels, Androidapplications today are able to bypass the built-in permis-sion system and share data in a potentially untraceablemanner. These channels have sufficient bandwidth to trans-mit sensitive information, such as GPS locations, in real-time to collaborating applications with Internet access. Inthis paper, we extend previous work involving an appli-cation layer covert communications detector. We measurethe stability of the volume and vibration channels on theAndroid emulator, HTC G1, and Motorola Droid. In addi-tion, we quantify the effect that our detector has on chan-nel capacities for stealthy malicious applications using atheoretical model. Lastly, we introduce a new classifica-tion of covert and overt communication for the Androidplatform.

Keywords Covert communication · Androidsmartphones · Security

1 Introduction

Android-based smartphones are ubiquitous today, makingthem a salient target for malware authors. Through theGoogle Play store, users can download and install applica-tions from developers around the world. Despite having astrong built-in permissions system, malicious applicationson Android can use covert channels to share data in apotentially untraceable manner. Covert channels use systemevents to conceal the transfer of data between processes [14,15]. These channels are easy to exploit, and may allow

R. Hill (�) · M. Hansen · V. SinghIndiana University, Bloomington, USe-mail: ralhill@indiana.edu

malicious applications to transmit sensitive information inreal-time (i.e., credit card numbers, social-security numbers,GPS coordinates, etc.). As shown in previous work [12],the vibration and volume channels alone are able to sustaintransfer rates of at least 80-100 bits per second with virtu-ally no data loss. While not enough to transfer videos orphotos, these bandwidths are sufficient for streaming GPScoordinates (64-bits per coordinate) or browsing historyURLs (hundreds of bits per URL) in real-time to a maliciouscollaborator. If the collaborator has Internet access, this sen-sitive information can then be sent to a server, even in thepresence of smartphone security systems like Kirin [10] andTaintDroid [9].

Schlegel et al. [19] developed an Android applicationthat extracts credit card information from the tones that areemitted by a phone dialer, and they demonstrated that thecredit card data could be sent via covert channels. In priorwork, we designed and implemented an application-layercovert communications detector for Android smartphonesthat detected Schlegel’s application and any application thatused volume, vibration and wakelock settings [12]. Ourdetector used a simple thresholding algorithm to determinewhen system settings are being changed in an anomalousmanner. Our limiting assumption for the detector is thatthe OS is not compromised and that it properly reports allchanges to system settings.

Since our detector resides at the application layer, itis able to detect and disrupt covert communications, butunable to prevent malicious applications from trying toestablish covert channels. Therefore, the goal of this paperis determine how our detector can be used to reduce thecapacity of a channel, thereby making it less attractive fortransferring data. To this end, in this paper, we define a the-oretical model that allows us to change the parameters ofour thresholding algorithm and quantify how these changes

80 Mobile Netw Appl (2014) 19:79–87

Fig. 1 Using a covert channel, applications can subvert the referencemonitor and communicate regardless of permissions

affect channel capacity. We also introduce a software stack-based classification of covert and overt channels for theAndroid platform. This categorization denotes where in thesoftware stack an efficient detection mechanism would needto reside (e.g. application layer, OS kernel, virtual machine).Finally, we measure the stability of the vibration and vol-ume channels across several platforms, and demonstrate theeffects of background noise on channel capacity.

2 Background and related work

2.1 Android operating system

The Android OS was designed to address the problems oftraditional malware. First, processes run within their vir-tual machine environment, thereby limiting how they mayimpact other applications. Inter-application communicationis achieved through an intermediary component known asthe reference monitor. Applications must explicitly requestpermission from the user at install time to access eachdangerous component.1 Process isolation and permissionsalone do not prevent malicious applications from usingcovert channels to bypass the reference monitor (Fig. 1).

Users should carefully consider an application’s per-mission requests to avoid obvious malware, such as a“game” that wants to record audio from the microphoneduring phone calls as well as access the Internet. Ong-tang et al. have developed a security system on top ofAndroid that automatically identifies dangerous permissioncombinations, allowing for the pre-installation blocking ofpotentially malicious software [18].

As an example of two colluding applications, considera calendar that requests access to your phone’s contactsand an online newspaper reader that requests access to theInternet. Individually, it makes perfect sense to grant thesepermissions. If these two applications are malicious, how-ever, they could collude and transfer the names, phonenumbers, and e-mail addresses of everyone in your contacts

1For more details on Android security, see Enck et al. [10].

list out to a malware server. If this communication weredone overtly through a content provider, the file system,or some other inter-process communication (IPC) mecha-nism, it would be possible to use preventative measuresand block the transmission of this sensitive information.No such measures exist for covert channels, which by def-inition are unintended methods of communication. Usingour thresholding algorithm (see Section 4.1), we can limitthe transmission rate of easily exploitable covert chan-nels, making them an impractical target for stealthy mal-ware that require transmission rates above a few bits persecond.

2.2 Related work

Covert channels have been classified historically as eitherstorage or timing channels. Timing channels require syn-chronization with a shared clock, while storage channelsdo not. A new method for classifying covert channels ispresented by Wang and Lee [21]. They show that a covertchannel may exist if a sender is either able to invoke achange that is visible by the receiver or change an objectbased on whether the receiver has observed the object. Thefour classes of covert channels they present are value-basedspatial and temporal channels, and transition-based spatialand temporal channels. Value-based spatial channels andtransition-based temporal channels are similar to the stor-age and timing channels described by Lampson [16]. Thetransition-based spatial channel demonstrates that a covertstorage channel can be created without the sender having theability to control the value of the object. With value-basedtemporal channels, the sender predicts or learns the value ofan object, and is able to control when the receiver reads theobject.

Holloway and Beyah introduce a new medium for acovert timing channel with a high level of accuracy andspeed [13]. They use the IEEE 802.11 carrier sense multi-ple access and collision avoidance (CSMA/CA) mechanismto transmit data. CSMA/CA uses a random back-off toavoid multiple collisions, and Holloway and Beyah areable to modulate this back-off data. Both the sender andreceiver maintain a pre-defined code-book which includesa code for each possible back-off time. Their methodhad 99 % accuracy when the throughput was 5000 bpsor less.

To prevent communication on traditional covert chan-nels, Wray [22] uses “fuzzy time”. This method introducesrandom variations into the visible timing of events, makingprecise measurement of event time impossible. A similarmethod could be applied in Android at the operating systemlevel. This would make changes to system settings visibleonly after some random delay; imperceptible to the user,but destructive to malicious applications that rely on event

Mobile Netw Appl (2014) 19:79–87 81

timing. Gianvecchio and Wang [11] present an approachfor detecting covert timing channels inside a network usingentropy. They claim a change in the entropy of a processis key in determining that a covert timing channel has beencreated or exists. They show that their process is moreeffective than previous methods for detecting covert timingchannels. We are interested in detecting covert storage chan-nels on Android, since these channels are usually based ona system-wide setting and event (which do not depend onprecise timing). However, entropy-based measures may beuseful for future work in detecting unusual communicationpatterns over storage channels.

In prior work [12], we use event counting and threshold-ing to detect covert communications that use system settingsto construct a channel. We define a set of sliding windowsand compare these counts to their corresponding thresholds.A count value that exceeds its threshold indicates covertcommunication. See Sections 4.1 and 4.2 for a detaileddescription of the algorithm.

Ongtang et al. present Saint, a framework for run-timeenforcement of security policies [18]. Saint mediates com-munication between an application and the Android ref-erence monitor. This allows the application to add morespecific requirements, such as being connected to a trustedWi-Fi network. Such requirements must be met beforeanother application can communicate with it or use itsresources. This method would not prevent covert or overtcommunication between two malicious applications. Someof the concepts presented in the run-time enforcement pol-icy, however, could be used in a covert channel detectionscheme to determine the likelihood of covert communica-tion between two applications (i.e. by considering the stateof the phone).

Introduced by Enck et al., Kirin is an install-time policysystem for blocking the installation of potentially mali-cious applications [10]. It provides a lightweight mechanismfor certifying an application at install-time based on itsrequested permissions. This certification is done using aset of rules that are meant to detect questionable config-urations of permissions which the user might otherwisemiss (e.g. microphone and Internet access). Kirin wouldnot be effective, though, if two different applications with“normal” permissions decided to communicate covertly orovertly. As long as both applications had a permission setthat was successfully certified by Kirin, nothing would pre-vent them from communicating and acting together as asingle malicious program.

Enck et al. have also created an information-flow track-ing system called TaintDroid that is capable of detectingsensitive information leaks [9]. By using “dynamic taintanalysis”, the authors are able to track sensitive data at thevirtual machine instruction level. This approach would be

very useful for ensuring that applications are not commu-nicating sensitive information, even overtly (see Section 5).TaintDroid could serve as a foundation for a detector oflanguage/runtime channels by tracking data as it flowsthrough a content provider and out to other applications.Since TaintDroid does not propagate taint labels into nativecode, however, covert channels over system settings willremove these labels.2 Even with native code label propa-gation, TaintDroid alone is not sufficient to detect covertchannels due to the high chance of false positives from datasent over system-wide events.

Mulliner et al. note that wireless devices, such as smart-phones, combine many different wireless technologies likeIEEE 802.11, cell networks, Bluetooth and GPS [17]. Sinceit is possible for these services to interact, an attacker canleverage their interaction for a special class of attacks thatmay end up costing the user money. They create a cross-service attack to demonstrate how this can be done, anddemonstrate how to combat such exploits with a mecha-nism that labels processes and system resources. Labelsare divided into 3 categories: interfaces, processes andresources. Whenever a process attempts to access an inter-face or use a resource, the existing policy is examined todetermine if the interaction should be granted. In evaluat-ing their approach they show that a process that creates asocket for Wi-Fi communication is unable to then establisha GSM connection, which is not allowed in the policy theyuse. They point out however that their approach fails in sit-uations where two services may be required (i.e. using aBluetooth headset during a cellular call). Such an approachwould not be helpful for us as it deals solely with what asingle process can access. The approach will not affect howtwo processes interact.

XManDroid (eXtended Monitoring on Android) is asecurity framework developed by Bugiel et al. that extendsthe Android reference monitor to prevent privilege esca-lation attacks [5]. By analyzing the transitive permissionusage of applications at runtime and applying system poli-cies, XManDroid can detect attacks that use Android’sICC (inter-component communication) framework. How-ever, many of the covert channels we describe are based onAndroid system settings. It would be very difficult to definea policy that successfully restricts malicious communicationover these channels while allowing legitimate applicationsto monitor necessary settings.

Developed by Dietz et al., Quire is a provenance systemfor the Android OS that provides a mechanism for pro-cesses to verify data that was received [7]. Quire is able toprovide authentication and verification for two untrustingapplications to communicate, and also aids an application

2Many settings live in native code drivers, such as the media volumeand vibration settings.

82 Mobile Netw Appl (2014) 19:79–87

in defending against confused deputy attacks. This methodprovides a system that will primarily benefit applicationdevelopers seeking to have verification of the informationreceived from other applications. Such a system is not usefulwhen two applications want to act together as a maliciousentity.

Several initiatives [1, 6, 8, 20], developed machine learn-ing based intrusion detection schemes that profile how usersinteract with smartphones and use specific applications.These profiles are then used to either authenticate a user,limit access to the device and its applications, and detectmalicious activity on the devices. In addition, other moregeneric intrusion detection schemes used dynamic and staticcode analysis techniques to detect malicious software at theOS and virtual machine layer [4, 23]. These latter schemescould be used to detect the presence of instructions thatchange system wide settings in an abnormal manner.

Zhou et al. [24] provide a mechanism for the user toset a policy regarding sensitive information like call logs,contacts, etcs. This policy is used to determine whetherapplications that have been given access to this data shouldbe allowed to access the data. If the policy says no, then fakedata may be sent to the requesting application. This workhelps the problem of information leakage because it enablesthe user to restrict access to sensitive information. The workcompliments our detector scheme, but it doesnt address theproblem of an application that has access and wants to sharethe data via a covert channel.

3 Covert channels on android

A malicious Android application can create a covert channelby using a ContentObserver to listen for changes ina variety of system settings [2].3 Schlegel et al. used thevibration, volume, and wake-lock settings, as well as filelocks to create covert channels on Android [19].

Of the three settings-based channels, vibration and vol-ume do not require any explicit permission from the userat install time to exploit. Wake-lock requires an additionalpermission from the user (WAKE LOCK), so we do not con-sider it to be as stealthy or severe as the other two channels.In addition, this channel depends on a latency in the elec-tronics of the device, and therefore may become unusableon future hardware without this latency [19]. Regardless,our detection algorithm (Section 4.1) and proof-of-conceptdetector (Section 4.2) accurately identifies covert commu-nications on the vibration, volume and wake-lock channels.By using a ContentObserver that monitors all system

3Our preliminary investigation found that virtually none of thesesettings were changed by popular applications in the Android Mar-ket. Thus, malicious applications would not have to worry aboutovercrowded settings channels.

settings, our prototype can be extended to detect and disruptmany other covert channels.

The file-lock channel is the most severe in terms of band-width alone. Schegel et al. reported that more than 685 bitsper second could be transmitted on a G1 phone. However,this channel requires that both colluding applications haveaccess to external storage. By default, Android applicationscannot access each other’s files and are unable modify exter-nal storage (e.g. the SD card) without prompting the userfor permission at install time.4 Since the lock state of everyfile on the external storage device would need to be contin-uously monitored, detecting the use of the file-lock channelfrom outside the OS would not be practical or foolproof.While one possible solution is to use our simple event-counting algorithm inside the OS itself (see Section 4.1), webelieve the danger presented by this channel is caused bythe coarse nature of the current external storage permission(applications get read or write access to the entire file sys-tem). Indeed, applications from a wide variety of domainsrequest write access to external storage [3], perhaps indi-cating the need to refine the permission by only grantingaccess to specific directories. If colluding applications hadto request write access to a particular set of files or a direc-tory on external storage to covertly communicate via thefile-lock channel, it could make the task of identifying themeasier. Malware detectors could then flag applications fromlargely different domains that request access to the sameexternal directory. The file-lock channel is difficult to detectoutside of the Android OS, and we believe that much of itsseverity is due to the permission set being too coarse. There-fore, we do not consider the file-lock channel further in thispaper.

The vibration and volume channels can be classifiedas either storage or timing channels depending on whatwe define as a “clock” [22]. Since it uses a system-widenotification event, we classify the vibration channel as stor-age. In contrast, no specific event exists for the volumechannel, making it highly dependent on the system clockand thus a timing channel. This categorization has practi-cal implications, since system noise from the user or otherapplications will impact storage and timing channels differ-ently. For storage channels that are based on a notificationevent (vibration, wake-lock), data loss is possible only ifa new event overwrites a previous one before the receiverhas a chance to inspect it. Android does not appear tomaintain event history, so data loss is always possible with-out additional synchronization mechanisms (e.g. receiveracknowledgement over a secondary channel). Timing chan-nels (like volume) are not only vulnerable to data loss fromnoise, but also race conditions where the sender and receiver

4Applications are currently able to mark their own files on internalstorage as world readable/writable, which we see as potential securityhole.

Mobile Netw Appl (2014) 19:79–87 83

(a) (b)

Fig. 2 Vibration channel (left) and volume channel (right) receive time for all platforms and loads (L = 100 events). Standard error is reportedfor N = 10 trials

get out of sync. As with storage channels, additional syn-chronization mechanisms can help mitigate these problemsat the expense of channel bandwidth. A secondary channelmay also be used, at the risk of making the application morevulnerable to detection.

3.1 Channel evaluation

In previous work, we implemented a pair of applicationscalled CovertSender and CovertReceiver to communicate afixed-length message over the vibration and volume chan-nels of an HTC G1, a Motorola Droid, and the Androidemulator [12]. Figure 2 compares the performance of thevibration and volume channels. We tested the effect of

noise on communication performance under the followingconditions:

1. Idle

– The device was idle during communication(CovertSender in foreground or background).

2. Video

– We played a standard definition video (480x352,H.264, MPEG-4).

3. Download

– We downloaded a large file (≈ 50 MB) over thephone’s Wifi connection.

Fig. 3 Settings screen forAndroid 2.3.3 vibration (left)and volume (right)

84 Mobile Netw Appl (2014) 19:79–87

4 Managing covert channels

4.1 Threshold detection

Detecting covert communication requires categorizing theuse of a channel as malicious or as expected within somemargin of error. Once malicious use is detected, we mustdecide on an appropriate response, such as blocking or dis-rupting communication, alerting the user, or taking steps tounmask the malicious applications.

We use event counting and thresholding to detect covertcommunications that use the vibration, volume, wake-lockand any settings with similar structure. For vibration andvolume settings changes, we maintain a history of events.Using a sliding window, we simply count the number ofevents within our window and compare this to a threshold(called the “burst” threshold b). A count value that is greaterthan or equal to b indicates covert communication. To detectapplications that try to consistently communicate below b,we use a lower threshold s, called the “sustained” threshold.Each time the event count inside a window exceeds s, wemark the window as “bad” and report when a set numberof consecutive time windows are bad. These two thresholdsare meant to capture two kinds of malicious behavior: (b)a large burst of communication over a short period of time,and (s) sustained communication below b.

The vibration setting on Android phones, for example,is normally set by the user through the Settings applica-tion (Fig. 3). Changing this setting requires several steps onrecent Android versions (e.g. 2.3.3). In our tests, it was vir-tually impossible to alter this setting more than three timesa second on the Android emulator and the Motorola Droid.The volume setting could be changed at most 18 times persecond via the Droid’s external buttons, which is less thanhalf the number of events that our test application was ableto generate through software.

4.2 Detector implementation

Our detector application monitors the vibration and volumechannels using the thresholding algorithm described above.On the main screen (Fig. 4), the user can set the thresholdparameters for either channel independently as well as thecombined vibration + volume channel (see details below).For testing purposes, the sliding time window is fixed at onesecond, although this could easily be exposed as a setting tothe user.

The vibration channel detector is a BroadcastReceiver registered to listen for the appropriate eventfrom the built-in AudioManager. The volume channeldetector polls the STREAM NOTIFICATION setting fromthe AudioManager continuously and counts an eventwhenever the setting changes. In addition to monitoring the

individual channels, we sum the event counts of both chan-nels and consider the combined vibration + volume channelas a separate channel with distinct parameters. This is doneto prevent stealthy applications from splitting up communi-cation over multiple independent channels, each kept belowthe burst and sustained thresholds.

We included two possible responses to covert communi-cation:

– The “Alert” response posts a notification message forthe user with the appropriate details, such as time ofdetection and channel name (Fig. 4). The names of allcurrently running processes on the system are recordedand stored in a database. Ideally, this list would be fil-tered to remove known system processes and comparedto past lists in order to identify culprits.

– The “Inject Noise” response randomly changes the set-tings for the identified channel, attempting to disruptcommunication.

To evaluate our approach, we used our detector applica-tion to monitor and expose covert communication betweentwo proof-of-concept Sender and Receiver applications.These applications were designed to pass a test messagefrom sender to receiver over a single covert channel asquickly as possible (i.e., using the maximum channel capac-ity).

We were able to detect covert communication betweenour proof-of-concept applications 100 percent of the timeover the vibration and volume channels. There were nofalse positives because the applications send data in burststhat exceed the rate at which a real user would changethe settings. Our detector was able to disrupt communica-tion by purposely changing the setting values and injectingnoise into the channel. In Section 3.1 we evaluated hownoise from regular system use affects the robustness andthroughput of the vibration and volume channels.

4.3 Theoretical model

When a covert application transmits at channel capacity, ourprototype quickly detects the communication. In an actualmalicious application whose author is trying to be stealthy,the application would limit its throughput to try and staybelow the thresholds. We can model the average capacityof the channel from the perspective of a stealthy maliciousapplication as follows.

Let w be the length of our detector’s time window in sec-onds, and n be the number of past time windows that we willconsider (including the current window). Let b be the burstthreshold (number of events counted in w at which we alert),s be the sustained threshold (number of events counted in wat which we mark the current window as “bad”), and q be thenumber of bits that can be transmitted per event (1.6 for the

Mobile Netw Appl (2014) 19:79–87 85

Fig. 4 Left main screen for theCovert Channel Detector. Rightalert issued after covertcommunication has beendetected

vibration channel, 2.8 for the volume channel). Finally, let cbe the maximum capacity of the channel in bits per second(this will depend on several factors – see Section 3.1).

Our detector uses a simple policy to decide whether ornot covert communication is occurring. If the number ofevents e in the current time window is greater than or equalto b, we alert the user. If e < b, we check if e ≥ s and ifso, we increase our running count v of “bad” windows. Ifv = n, then we alert. We reset v to zero if the number ofevents e drops below the sustained threshold s for the nexttime window (Fig. 5).

Using the model above, we determine the average chan-nel capacity for a covert message that is m bits long. Clearly,if m ≤ (b − 1)q (i.e., the entire message is less than theburst threshold) then the message can be sent at the maxi-mum channel capacity c, since this will not trigger an alert.When (b − 1)q < m ≤ (b − 1)q(n− 1), however, the aver-age channel capacity will be (b − 1)q/w. This is becauseour detector will not alert until n time windows in a rowhave been “bad” (i.e., v = n), so the malicious applicationcan transmit (b− 1)q bits during all n− 1 windows withoutrisking detection.

Fig. 5 Left pseudo-code for detector policy. Right model of chan-nel capacity when the detector thresholds are known by a maliciousapplication. We count events for n time windows of length w, withthresholds b and s. The channel has a maximum capacity of c/q eventsper second

For larger messages,5 a malicious application can maxi-mize its throughput by transmitting b − 1 events for n − 1time windows in a row, and then transmitting s − 1 eventsfor a single time window (causing v to be reset to zero).The maximum channel capacity for n time windows cantherefore be expressed as:

(n − 1)(b − 1)q

w︸ ︷︷ ︸

Under b for n−1 time bins

+ (s − 1)q

w︸ ︷︷ ︸

Under s for 1 time bin

(1)

By dividing Eq. 1 by n, we obtain an expression for theaverage channel capacity for large messages:

stealth capacity(q, b, s, n, w) = q(s + ((b − 1)n − b))

nw(2)

We can use this model to calculate the average chan-nel capacities for the vibration and volume channels withand without a detector. On the Droid, for example, wefound that c ≈ 100 bps for the volume channel [12].Without a detector in place, this is plenty of bandwidth tostream GPS coordinates (64-bits apiece) in real-time to amalicious collaborator. With a burst threshold of b = 20events, this caps the bandwidth for stealthy applications to(b − 1)q/w = 53.2 bps (remember that q = 2.8 bits forthe volume channel and w = 1 sec). If we include a sus-tained threshold of s = b/4 = 5 events and set n = 3time windows (effectively saying that we do not expectusers to change the volume more than 5 times a second for

5Where m > (b − 1)q(n − 1)

86 Mobile Netw Appl (2014) 19:79–87

Fig. 6 Effective volume channel capacity for the Droid with andwithout a detector

3 consecutive seconds), then our average channel capacityfor large messages is given by Eq. 2:

capacity(2.8, 20, 5, 3, 1) = 2.8(5 + ((20 − 1)3 − 20))

3= 39.2 bps

With a detector in place, we have more than halvedthe average channel capacity (from 100 bps to 39.2 bps).This capacity could be reduced even further by dynami-cally adjusting the thresholds depending on the phone state(e.g., lower all thresholds when the phone is locked), orby including additional thresholds that take more historyinto account. Additionally, an OS-level detector could bemore clever by setting thresholds per-process with windowsizes dependent on scheduler time slices. As we mentionedin Section 4.2, the detector’s response to detecting covertcommunication could vary from injecting noise into thechannel (requiring more error correction from maliciousapplications) to simply recording the running processes andreporting likely culprits to the user or an anti-malwareservice (Fig. 6).

5 Discussion

Our detection algorithm could be improved in several ways.In its current form, malicious applications can reset thenumber of “bad” time windows v by transmitting below thesustained threshold s for one out of every n time windows.This behavior makes the average channel capacity easy toanalyze, but misses opportunities to take more historicalevent data into account. An improved detection algorithmmight keep track of non-consecutive “bad” time windows,

applying a discount factor to windows that are further inthe past. In this case, stealthy malicious applications wouldneed to keep more complex statistics on their own transmis-sion histories, and possibly prioritize messages based on thepresumed state of the detector.

Covert communications in an Android platform canoccur at various levels of the software stack. In addition,malicious applications may use overt mechanisms to sharerestricted data. Therefore, we propose classifying communi-cation channels by the location at which an efficient detectorwould need to reside in order to efficiently detect them.After our experience with covert channels on Android, wepropose the following classification levels:

– Application level

– Communication can be detected easily usinga regular application. Malicious applicationsare exploiting resources that detectors canefficiently monitor. Communication over thevibration, volume, and wake-lock channelswould fit this category, as well as all settings-based channels whose respective broadcastevents are available to any application. Adetector at this level requires that the underly-ing software layers (e.g. virtual machine, OS)are uncompromised.

– Operating system level

– Efficient detection would require hooks in theoperating system. Malicious applications use alarge number of resources for communication(e.g., many different files), forcing detectorsto have a global view of the system. Com-munication over the file-lock channel is oneexample, since it would be impractical to mon-itor the lock-state of every file on the externalfile system.

– Language/runtime level

– Communication that leaks sensitive informa-tion across applications is very difficult todetect. It does not necessarily have to occurover a covert channel, and could be accom-plished overtly through an intermediary con-tent provider. To expose this unwanted sharingof information, a detector needs to be embed-ded in the runtime itself (e.g., the Dalvik vir-tual machine) and must explicitly track theflow of information. The TaintDroid projectcould serve as a foundation for such a detector(see Section 2).

Mobile Netw Appl (2014) 19:79–87 87

6 Conclusion

Prior work [12, 19] has shown the ease with which covertchannels can be used in the Android environment to sub-vert its permissions system and reference monitor to exposesensitive information. As we use our smartphones to create,store, and process sensitive and confidential information,these devices become salient targets for malicious softwarethat seeks to steal such data. In this paper we demonstratethat covert communications can be detected and disrupted atthe applications layer. We also introduce a detector-centricclassification scheme that categorizes channels by the levelwithin the software stack that the detector resides. In addi-tion, we define a theoretical model that characterizes howour threshold algorithm reduces the effective capacity ofcovert channels.

References

1. Damopoulos D, Kambourakis G, Gritzalis S (2013) From keylog-gers to touchloggers: Take the rough with the smooth. ComputSec 32(0):102–114. doi:10.1016/j.cose.2012.10.002. http://www.sciencedirect.com/science/article/pii/S0167404812001654

2. Android (2012) Settings system. http://developer.android.com/reference/android/provider/Settings.System.html

3. Barrera D, Kayacik H, van Oorschot P, Somayaji A (2010) Amethodology for empirical analysis of permission-based secu-rity models and its application to android. In: Proceedings of the17th ACM conference on computer and communications security.ACM, pp 73–84

4. Blasing T, Batyuk L, Schmidt AD, Camtepe S, Albayrak S (2010)An android application sandbox system for suspicious softwaredetection. In: 2010 5th International conference on maliciousand unwanted software (MALWARE), pp 55–62. doi:10.1109/MALWARE.2010.5665792

5. Bugiel S, Davi L, Dmitrienko A, Fischer T, Sadeghi A (2011)Xmandroid: A new android evolution to mitigate privilege escala-tion attacks, Security

6. Damopoulos D, Menesidou SA, Kambourakis G, Papadaki M,Clarke N, Gritzalis S (2012) Evaluation of anomaly-based ids formobile devices using machine learning classifiers. Secur CommunNetworks 5(1):3–14. doi:10.1002/sec.341

7. Dietz M, Shekhar S, Pisetsky Y, Shu A, Wallach D (2011) Quire:lightweight provenance for smart phone operating systems. In:USENIX security

8. Dini G, Martinelli F, Saracino A, Sgandurra D (2012) Madam:a multi-level anomaly detector for android malware. In: Proceed-ings of the 6th international conference on mathematical methods,models and architectures for computer network security: com-puter network security, MMM-ACNS’12. Springer-Verlag, Berlin,pp 240–253. doi:10.1007/978-3-642-33704-8 21

9. Enck W, Gilbert P, Chun B, Cox L, Jung J, McDaniel P, ShethA (2010) Taintdroid: an information-flow tracking system forrealtime privacy monitoring on smartphones. In: Proceedings ofthe 9th USENIX conference on operating systems design andimplementation, USENIX Association, pp 1–6

10. Enck W, Ongtang M, McDaniel P (2009) Understanding androidsecurity. IEEE Secur Privacy 7(1):50–57

11. Gianvecchio S, Wang H (2007) Detecting covert timing channels:an entropy-based approach. In: Proceedings of the 14th ACM con-ference on computer and communications security. ACM, pp 307–316

12. Hansen M, Hill R, Wimberly S (2012) Detecting covert com-munication on android. In: IEEE local computer networks 2012conference

13. Holloway R (2010) Covert dcf-a dcf-based covert timing channelin 802.11 networks

14. Kemmerer R (1983) Shared resource matrix methodology: anapproach to identifying storage and timing channels. ACM TransComput Syst (TOCS) 1(3):256–277

15. Kemmerer R (2002) A practical approach to identifying storageand timing channels: twenty years later. In: 18th Annual com-puter security applications conference, 2002. Proceedings. IEEE,pp 109–118

16. Lampson B (1973) A note on the confinement problem. CommunACM 16(10):613–615

17. Mulliner C, Vigna G, Dagon D, Lee W (2006) Using label-ing to prevent cross-service attacks against smart phones. DetectIntrusions Malware Vulnerability Assess: 91–108

18. Ongtang M, McLaughlin S, Enck W, McDaniel P (2009) Semanti-cally rich application-centric security in android. In: Annual com-puter security applications conference, 2009. ACSAC’09. IEEEpp 340–349

19. Schlegel R, Zhang K, Zhou X, Intwala M, Kapadia A, Wang X(2011) Soundcomber: a stealthy and context-aware sound trojanfor smartphones. In: Proceedings of the network and distributedsystem security symposium

20. Shabtai A, Kanonov U, Elovici Y, Glezer C, Weiss Y(2012) Andromaly: a behavioral malware detection frame-work for android devices. J Intell Inf Syst 38(1):161–190.doi:10.1007/s10844-010-0148-x

21. Wang Z, Lee R (2005) New constructive approach to covert chan-nel modeling and channel capacity estimation. Inf Secur: 498–505

22. Wray J (1991) An analysis of covert timing channels. In: Proceed-ings IEEE computer society symposium on research in securityand privacy, 1991. IEEE, pp 2–7

23. Yan LK, Yin H (2012) Droidscope: seamlessly recon-structing the os and dalvik semantic views for dynamicandroid malware analysis. In: Proceedings of the 21st USENIXconference on security symposium, Security’12. USENIX Asso-ciation, Berkeley, pp 29–29. http://dl.acm.org/citation.cfm?id=2.3627932362822

24. Zhou Y, Zhang X, Jiang X, Freeh VW (2011) Taming information-stealing smartphone applications (on android). In: Proceedings ofthe 4th international conference on trust and trustworthy com-puting, TRUST’11. Springer-Verlag, Berlin, pp 93–107. http://dl.acm.org/citation.cfm?id=2.0222452022255