{'fraction_non_alphanumeric': 0.026688286077391647, 'fraction_numerical': 0.008238748411411543, 'mean_word_length': 4.942578125, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 2, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 5, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
VindiCo: Privacy Safeguard Against Adaptation Based Spyware in Human-in-the-Loop IoT

Personalized IoT adapts their behavior based on contextual information, such as user behavior and location. Unfortunately, the fact that personalized IoT adapts to user context opens a side-channel that leaks private information about the user. To that end, we start by studying the extent to which a malicious eavesdropper can monitor the actions taken by an IoT system and extract users' private information. In particular, we show two concrete instantiations (in the context of mobile phones and smart homes) of a new category of spyware which we refer to as Context-Aware Adaptation Based Spyware (SpyCon). Experimental evaluations show that the developed SpyCon can predict users' daily behavior with an accuracy of 90.3%. The rest of this paper is devoted to introducing VindiCo, a software mechanism designed to detect and mitigate possible SpyCon. Being new spyware with no known prior signature or behavior, traditional spyware detection that is based on code signature or app behavior is not adequate to detect SpyCon. Therefore, VindiCo proposes a novel information-based detection engine along with several mitigation techniques to restrain the ability of the detected SpyCon to extract private information. By having general detection and mitigation engines, VindiCo is agnostic to the inference algorithm used by SpyCon. Our results show that VindiCo reduces the ability of SpyCon to infer user context from 90.3% to the baseline accuracy (accuracy based on random guesses) with negligible execution overhead.


INTRODUCTION
Context-aware systems provide personalized services that are adaptive according to user context and surrounding environments. These pervasive systems have enabled a multitude of applications in several IoT sectors including smart cities [39], health care [35], smart classrooms [13,57], and automotive systems [3,16,37]. However, these enhanced capabilities come at the expense of privacy weaknesses [14,24,53,55] and sometimes lack of fairness in context-adaptation [12].
Unfortunately, previous work ignores the fact that decisions taken by IoT are often triggered by human beings. For example, a smart NEST thermostat 3 can automatically turn on and off the HVAC equipment based on users' presence.
Such a coupling between human behaviors and decisions taken by IoT system can open a side channel, leaking sensitive information about users. As pictorially illustrated in Figure 1, a human-in-the-loop (HITL) IoT utilizes edge devices (e.g., mobile phones and wearables) to sense and infer human states. Such states are then used by the IoT to produce actions and adapt its behavior to match the human state. Resting on this observation, this paper raises the following questions: (1) Can an eavesdropper who monitors the actions taken by the IoT be able to reverse engineer these actions in order to estimate human states and leak sensitive information? (  To explore the answers, we introduce a new type of spyware that exploits privacy leaks in context-aware adaptations which we call SpyCon. Besides, we purpose VindiCo, a novel detection and mitigation engine that is designed to protect against privacy leaks due to the actions taken by HILT IoT but observed by SpyCon. Contrary to traditional malware detection approaches, VindiCo does not rely on prior information about the code signatures or run-time behaviors of known malware. Instead, VindiCo is designed to be generic and agnostic to the implementation of SpyCon.

Related Work
Context Monitoring Malware on Mobile Platforms: Mobile systems are becoming an integral component in multiple IoT systems due to their sensing capabilities [46]. While mobile users benefit from these sensing technologies, there are increasing privacy and security concerns. The permission systems on both Android and iOS become the first line of defense to protect users from leaking sensitive information. However, the traditional grant-all-or-none policy allows third-party apps to have all permissions [28]. Even worse, most users have trouble with realizing the potential privacy hazards after granting such permissions. For example, though seems innocuous, ACCESS_WIFI_STATE becomes a heavily privacy intrusive permission since local MAC address can serve as a unique device identifier [1]. Felt et al. [21] shows that as little as 17% of users pay attention to the permissions during app installation phase.
Different side-channel attacks have been proposed, for example, using inertial sensors and touch screen to infer user input such as passwords [25,40,44,50]. Besides, we witnessed how to exploit cellular signal strengths, air pressure, or power consumption for locations [27,42,43], gyroscope for eavesdropping conversations [41], system-level aggregate statistics for user's real world identity [62], and the state of shared memory for foreground apps, and even, activity transition sequences [47]. There is a trend that malicious apps are adapting to wearable devices [51]. For example, MoLe [58] exploits the wrist motion derived from smartwatches to infer keystroke inputs. So far we've provided many examples showing "Your apps are watching you" [32] in a broad spectrum which a majority of users will never realize, and for sure "These aren't the droid you're looking for" [28].
Contrary to the aforementioned side-channel attacks, we consider a spyware which does not have access to sensor information like inertial or gyroscope sensors, a spyware which can monitor only the actions that are triggered-by HITL IoT-based on changes in these sensory data.
Malware Detection Techniques: Several techniques have been proposed for malware detection and can be broadly categorized into two groups. (1)Code signature-based approach [6,11,18,23,38] detects stealthy behavior based on the code flow. (2)Behavior-based approach [17,33,61,64] performs information leakage detection in execution time, but tackling the issue from different layers of an operating system. DroidRanger [63] points out that an app can download binary payload in the runtime, which code-signature based approach can never diagnose its intention but raise a warning of potential hazard. Nevertheless, VindiCo is distinct from the above techniques by considering the fact that a malicious app can learn sensitive information based on the adaptations made by HITL IoT.
Malware Mitigation Techniques: Different mitigation techniques have been proposed, including sensory value perturbation [8,9,28], finer-grained permission control [29,49], and permission recommendation systems [2]. Box [36] and SemaDroid [60] introduce a notion of privacy budget and seek a balance between utilization and privacy sacrifice. VindiCo shares the similar goal to quantify the degree of information being leaked and choose an appropriate data perturbation method and according mitigation magnitude based on the desired degree of data distortion.

Paper Contribution
Our contributions can be divided into two categories: SpyCon: a new category of spyware targeting HITL IoT systems: • We exploit a new side-channel attack vector arising from monitoring actions and decisions taken by IoT systems.
We call this new set of attacks a context-aware adaptation based spyware, or in short, SpyCon. • We show two concrete instantiation of SpyCon. The first instantiation targets mobile phones in which the SpyCon can maliciously infer user's behavior by monitoring the decisions taken by context-based apps. We assess the performance of the developed SpyCon through a one-month user study involving human subjects. The second instantiation targets smart homes, in which the SpyCon monitors HVAC activity reported to the cloud and use it to infer human activity. We assess the performance of the developed SpyCon through an industrial-level simulation engines simulating HVAC systems.
VindiCo: A safeguard against SpyCon: • We design, implement, and demonstrate VindiCo, a safeguard against SpyCon. We introduce a novel detection mechanism (named information-based detection) along with two genres of mitigation policies. • We re-examine the proposed mitigation policies against the developed SpyCon to assess it and show how its performance decreases after applying mitigation policies.

SPYCON: A CONTEXT-AWARE ADAPTATION BASED SPYWARE
We define a spyware that spies on context-aware adaptations a SpyCon. Since adaptions are dependent on the user context, observing adaptions made by HITL IoT can reveal sensitive user information. In this section, we show two examples of SpyCon, one targets IoT mobile/edge devices while the other one targets the IoT cloud [14]. We refer to these two SpyCon as "SpyCon Edge" and "SpyCon Cloud", respectively.

SpyCon Edge: Popular Phone Manager Apps
A typical pipeline of an IoT application includes edge devices which generate sensor data, an IoT cloud which stores and forwards these data, and a mobile phone which consumes the data, computes the actions, and presents them to IoT users.   Mobile phones are arguably a primary target for spyware due to their sensing capabilities and the integrations with IoT systems. In this scenario, we consider SpyCon is mounted on a mobile phone to leak sensitive information, depicted in if a notification reminder of a grocery list is observed (the adaption). Location-based phone settings management is one of the most popular context-aware applications 4 . Due to their capability to adapt to user context, apps like Llama [34], Tasker [30], and Locale [22] have gained more than 1 million downloads from Google Play Store. Moreover, these location-based apps are increasingly integrated as part of larger IoT systems. Motivated by the popularity of these location-based context-aware apps, we choose user location as the sensitive data for which SpyCon is trying to leak.
2.1.1 Spyware Description. We design a SpyCon that monitors changes in phone settings to demonstrate it is possible to leak user location, an arguably the most sensitive type of user information [48]. The phone setting changes are triggered by the decisions taken by a location-based context-aware app as part of an IoT system. We start by making the following two important remarks: • No user permissions: Unlike location information, many phone settings can be monitored without seeking user permissions. For example, SpyCon can easily get current screen brightness or alarm volume without user consent. • Ambiguity on setting changes: Manual adjustment can make changes in phone settings through physical buttons. Although SpyCon can not discriminate a priori between the changes in the phone settings done by a  location change or by manual adjustment from users, machine learning algorithms can be handy in discovering repetitive patterns in the data.
The operation of the designed SpyCon is divided into two phases: • Logging:SpyCon monitors all the changes in phone settings and records a timestamped value upon a change is detected. A list of phone settings that we consider in our SpyCon is given in Table 1. • Data Mining: Once enough data is collected, SpyCon analyzes these data to discover repeated patterns and hence infers user's daily behavior. More details about the data mining algorithm are given in Section 2.1.3 after we discuss the user study setup.

SpyCon User Study.
Shadow Logging Application. To understand how much information is leaked by context-aware apps like Tasker and Locale, we developed a shadow app that resembles the functionality of Tasker and Locale in order to collect the ground truth data. First, we ask users to enter the same profiles which they would provide in the context-aware apps (Tasker or Locale). To be more specific, users have to enter a fixed-radius circular geo-fence as a context trigger, as well as a set of actions (e.g., adjusting screen brightness or changing ringer mode to vibration) that would be activated when the user enters these geofences. The full phone settings we considered are listed in Table 1. Secondly, in order to keep track of the golden output (ground truth) for later evaluation, the shadow app keeps and timestamps a record whenever the active profile is changed, implying that the user moves to a different location.
SpyCon Application. We developed a SpyCon whose only task is to log phone settings in the background without any interaction with all the other apps, including the context-aware app 5 . All the settings collected by the SpyCon app can be accessed without permissions in Android OS, including those listed in Table 1.
However, it should be noted that any SpyCon app may benefit from knowing whether a context-aware adaption application is installed. This information can be retrieved through different ways such as the getInstalledApplications() User Study. We implemented both apps mentioned above on Android 5.0.1 running on Nexus 4 and Nexus 5. Seven participants are recruited in our user study, including four males and three females. Each participant carries our phone for four weeks. Users can choose the settings/profiles based on their personal preferences, and they are allowed to change the phone settings manually. Based on the data we collected during the user study, we explore what sensitive information can be mined maliciously as shown in the following experiment.  Table 2. Clustering accuracy (in percentage) of all users compared to the baseline accuracy (the accuracy that the SpyCon can have based on blind guesses) by applying k-means using the settings in Table 1 2.1.3 Experiment 1a: Data Mining by Clustering. Revealing the semantics of the user location trace, or equivalently, the active profile sequence from phone settings is challenging since both the profile and the phone settings do not always have a one-to-one mapping. This is because (1) Users configure only a subset of the 12 settings listed in Table 1 in their profiles and hence it is not known a priori which subset of settings are used by the user. Furthermore, different profiles may include different phone settings to be changed. (2) Users can manually override the phone settings by, for instance, pressing the volume buttons or adjusting the brightness through the Settings App. Thus, we use a clustering technique to approach the user data mining problem, and in particular, we use k-means algorithm.
Deciding the number of clusters in the k-means algorithm is known to be hard in general and is usually application dependent. Since our SpyCon does not know how many profiles are defined by users, we brute-forcedly set to be any value between 2 through 7 (selected based on the maximum number of profiles defined by our participants). Our algorithm returns the clustering result with the highest silhouette score.
Critical Phone Settings. Inspired by how most unsupervised machine learning algorithms work, we implement a greedy algorithm to find dominant phone settings. The algorithm procedures are provided below: (1) Initialize the selected feature set = .
(2) We examine every other setting not in by performing k-means with feature set ∪ { }. The silhouette score ℎ is computed accordingly.
(3) Denoteĥ as the maximum ℎ from the previous step. Ifĥ is larger than previous silhouette score, then = ∪ { } and go back to step 2. Otherwise, the algorithm terminates.
Privacy Implications. The clustering result of one participant in our study is demonstrated in Figure 3. Figure 3a shows the actual user profile changes across the day (the golden output as explained in Section 2.1.2). Figure 3b shows the k-means clustering result (using an adaptive number of clusters) and demonstrates similar patterns with the golden output in Figure 3a. Our algorithm is able to capture subtle events, for example, learning that the user regularly went to a particular place (which turns out to be the child care) after leaving or before returning home, despite the portion of time this user spent in child care is short. Clustering result derived by dominant features from our feature selection algorithm is shown in Figure 3c. Figures 3b and 3c clearly indicate the ability of the developed SpyCon to reconstruct user context (switching profiles in this case) by just monitoring its side effect (changes in phone settings) 7 .
The overall accuracy of our clustering algorithm is reported in Table 2. We define baseline accuracy by using blind guesses, that is, the SpyCon always reports a user is at home without observing any phone settings. The results in Tasker [30] location phone settings Locale [22] location phone settings RockMyRun [52] biometrics music played HABU music [45] mood music played Table 3. Context-aware apps in the market and their side-channel the rest of the columns are the additional information (the increase in accuracy) the SpyCon gains over the baseline accuracy if an inference is used based on a different number of clusters. The accuracy derived from dominant features is slightly higher because the feature selection algorithm excludes noisy features leading to a better result. We report dominant features for each user in the last column of Table 2. We observed that the ringer mode is a dominant feature.
In summary, this study shows that the designed SpyCon can estimate and learn with an average accuracy of 90.3% the user behavior, in particular: (1) Average commuting time between home and work.
(2) Average time spent at work and at home.
(3) Weekend behavior, such as if a specific place is frequently visited on Sundays and average time spent at home.

Experiment 2: Detection Using Current Antivirus Apps.
After we had implemented this spyware app, we examined it using 5 well-known anti-virus applications 8 . None of them reported this app as malware. This follows from the fact that the proposed SpyCon does not have any suspicious code signature. This motivates the need to find a new detection technique that suits this kind of spyware.

Experiment 3: Beyond Location SpyCon. While the previous experiment aims at studying how the proposed
SpyCon can leak the semantics of the user location, we further explore how acquiring side-channels can reveal other sensitive user information. To this end, we study several context-aware apps in the Android market and report the monitored context and the corresponding actions taken by these apps in Table 3. Since other apps can observe these actions (even without asking for user permissions), these actions open a side-channel that leaks information about the user behavior. For example, monitoring changes in the played music media 9 can leak information about the user biometrics (heart rate and running pace) and user mood whenever such context-aware apps are used. In general, the proposed SpyCon can take advantage of any pair of get and set methods that are present in the Android framework APIs.

SpyCon Cloud: Smart HVAC System
Cloud servers continue to be one of the weakest points when it comes to data breaches [4]. We argue in this example, that even non-sensitive information collected on HITL IoT clouds can be used to leak sensitive user information. To that end, we choose the personalized smart HVAC system as an example of a HITL IoT application [26,31]. The personalized HVAC incorporate the human's activity to change the HVAC set point to maximize his comfort level [15]. In this scenario, as pictorially shown in Figure 2b, human's activity such as cooking, sleeping, sitting, etc. is used with the current temperature in the house to tune the HVAC set point. the HVAC set point is calculated on the phone and pushed to the cloud service that controls the smart thermostat, a SpyCon operating on the cloud could monitor the changes in temperature set points along with the current home temperature to infer the human's daily behavior.

Spyware Description.
We conduct a simulation-based experiment using EnergyPlus [10], an industrial-level physics-based simulation engine, to model HVAC systems. We use the weather reports in Colorado-Denver during January 2018 [19]. The user activity is used to control the set point of the HVAC [15] across the day to maximize the human thermal comfort measured in Prediction Mean Vote (PMV) [20]. Privacy Implications. The results shown in Figure 4b suggest that SpyCon operating in the cloud can infer sensitive information like when the IoT user wakes up and goes to sleep (prof3), and when the user leaves the house and comes back (prof1). SpyCon Cloud is also able to detect the occurrence of a periodic user activity just after returning home from work which is not performed during the weekends (prof6). The accuracy of the clustering is listed in

VINDICO SYSTEM ARCHITECTURE
In VindiCo, we focus on the general question of how to design software mechanisms that can detect and mitigate SpyCon. Our entry point is that mobile phones play an important role in connecting the user to numerous HITL IoT.
For example, in both the scenarios discussed in Section 2, namely when a SpyCon operated on the edge/phone and the cloud, sensitive user information are collected from the user's phone. Being the source of several user's sensitive information, a natural choice of implementing a privacy safeguard would be on the user's phone. Indeed, the same concepts developed in this section can be applied to other sources of sensitive user information before it is used by the rest of the HITL IoT.

Threat Model and Design Objectives
Motivated by the observations from the previous section, we define our threat model as follows.
[T1] No prior signature or behavior: Since SpyCon is a new class of spyware, we assume neither prior knowledge of code signatures nor prior recorded suspicious behaviors exist.
[T2] Unknown inference algorithm: We assume no knowledge of the algorithms used by SpyCon to infer the sensitive information.
[T3] Access to information: We assume that SpyCon has access to the APIs 10 on the phone and have access to the information stored in the cloud.
[T4] Knowledge of Existence of VindiCo: Finally, we assume that SpyCon is aware of the existence of VindiCo.
That is, SpyCon has full knowledge of VindiCo detection and mitigation algorithms and SpyCon may adapt its behavior accordingly.
T1 and T2 imply that traditional malware detection schemes (e.g., [59]) are not adequate in our problem setup. Hence, a new SpyCon detection scheme has to be designed without possessing any prior information (signature or behavior) of such spyware. In particular, we propose the following design objectives in VindiCo: [O1] Generic Detection: VindiCo should be able to detect any possible privacy leak without prior knowledge of spyware signatures or behavior.
[O2] Mitigation: VindiCo should be able to mitigate the impact of a possible SpyCon while minimally affecting the performance of the HITL IoT.
[O3] Performance: VindiCo should be lightweight and add minimal execution overhead.
Motivated by these three design objectives, we designed VindiCo as discussed in this section in three main blocks: Context-adaptation registration, Detection Engine, and Mitigation Engine. The details of each building block are given in the subsequent sections.

Context-adaptation Registration
In order to protect the actions and decisions made by the HITL IoT, VindiCo needs to know the context-action relations within the IoT system. One action in an adaption can be made based on several context, and one context can be shared by different actions. For example, a user may use a camera app and another app for listening to music in the background while running. Upon detecting that the user is running, the camera app adjusts the hardware camera focus while the music app changes the music playlist. Both actions from these two apps, i.e., changing camera properties and altering music playlist, are made based on the same context, i.e., user's physical activity. Providing the context-action relations is essential for VindiCo to monitor how likely a SpyCon is inferring associated context. 10 Our study in the section 2.1 shows that many of such Android APIs do not require permissions. In order to automatically retrieve the context-action relations, we use FlowDroid [6] (which augments the Java code analysis tool Soot [56]) in order to analyze the call flow graph of the context-aware app (e.g., Tasker) and extract all relations between the setter APIs and getter APIs along with the information about which data will be sent and recieved over the network interface to the cloud. The final output is an XML file that maps context (getter APIs and data received from the cloud) to actions (setter APIs and data sent to the cloud). We call this XML file a registry file. The developer can then view the automatically generated XML file to verify or modify it before being used by VindiCo.
In the registry file example shown in Figure 5, there are two adaptation policies. Each adaptation represents one context-action relation. The first adaptation makes decisions based on GPS location and updates ringer mode and alarm volume accordingly. In the second adaptation, the application adjusts the camera settings to accommodate battery capacity, GPS location, and transportation modality.
During application installation phase, VindiCo checks the existence of the registry file. If the file exists, VindiCo considers the associated application as a context-aware app and will offer detection and mitigation mechanisms to protect this app from potential context exposures against any other suspicious SpyCon.

Information-Based Detection Engine
It follows from assumptions T1 and T2, in our threat model, that existing signature-based detection mechanisms are not able to detect the developed SpyCon. Similarly, behavior-based detection techniques are not suitable to detect such spyware since no prior behavior is known. Exacerbating the situation, the behavior of SpyCon is coupled to the behavior of the authentic context-aware apps that are part of the HITL IoT. That is, if the IoT (and hence the authentic context-aware app) triggers actions more frequently, SpyCon will monitor the actions by calling the getter values APIs for these actions more frequently. This behavior coupling hinders the usability of the behavior-based detection techniques.
The idea behind the information-based detection is to keep track of the ability of SpyCon to infer the context through monitoring actions triggered by this context. Recall that we do not have any prior knowledge or assumption on how SpyCon performs its inference (T2). To this end, we draw on the literature of information theory and leverage mutual information to quantify the amount of correlation (or dependence) between two random variables. In our scenario, we use the mutual information between context and action as a metric to measure how certain a SpyCon can infer context from observed actions. Mutual information provides a theoretical bound on the inference capability of any learning algorithm. Generally speaking, the lower the mutual information between context and actions is, the lower the accuracy any inference algorithm can get. Push into one extreme, if the mutual information is zero, then no algorithm can infer context from monitored actions.

Based on this intuition, our detection engine constantly tracks what actions have been monitored by each app,
computes an estimate of mutual information between the actual context and those actions monitored by this app, and assigns a suspicion score accordingly. This score is then passed to our Mitigation Engine, as an indicator of the magnitude of countermeasures, which aims at reducing the amount of information possessed by suspicious apps.

Mitigation Engine
Once the suspicion score, assigned to each possibly running SpyCon, increases beyond a certain threshold (named alarm threshold), the Mitigation Engine informs the user with the possibility of having a SpyCon and asks the user permission to apply countermeasures against the suspicious app. Upon the user consent, the Mitigation Engine seeks a general way to hinder the SpyCon's capability of revealing user context. While completely blocking all side-channels may not be practical, our goal is to drastically reduce its bandwidth. This process needs to be done without any prior assumption on the type of inference algorithms used by SpyCon (T2). There are two solution regimes to achieve this: 1) imposing delays so that a SpyCon cannot get the latest action updates in real time, and 2) tearing down the correlation between the actions monitored by SpyCon and the associated context. We call the mitigation method in the first regime delay and introduce three different mitigation methods in the second regime: suppression, row-masking, and feature-masking.
Before delving into the details of various mitigation algorithms, we would like to stress the following facts: • Complementary and adaptive mitigation: The two regimes of mitigation methods achieve different goals and can complement each other. In practical scenarios, we combine both delay mitigation with one in the second regime which reduces the mutual information. VindiCo does not assume any mitigation can always outperform the others. In fact, a mitigation technique may be effective only in a certain situation. Hence, VindiCo starts by selecting a mitigation method and applies it accordingly. Next, VindiCo tracks the effectiveness of the imposed mitigation technique by constant monitoring of changes in the suspicion score. If a SpyCon can still survive under current mitigation treatment, VindiCo increases the mitigation magnitude first and eventually switches to a different method.
• The Scope of mitigation: The mitigation is applied on a per-app basis instead of a system-wide configuration.
Hence, well-behaved apps (including the protected context-aware app) can receive correct action values. Therefore, mitigations cause no negative impact on context-aware apps.
The rest of this section we explain the details of the mitigation techniques we have in VindiCo.

Mitigate by Delay.
Our first strategy is to let VindiCo delay the information about when adaptation actions are taken so that a SpyCon can only get an outdated context instead of the latest one. That is, whenever an app with high suspicious score or whenever the cloud is getting information about actions taken based on changes in user contexts, VindiCo will send old information that are delayed minutes which is selected randomly (to prevent the SpyCon from revealing the delay).

Mitigate by Suppression.
With the previous mitigation method, even though SpyCon may not be able to get the real-time update from delay mitigation, a SpyCon can retrofit users' daily routine by aligning with a priori knowledge, for example, when a person usually goes to school or work. Once the personal schedule is derived, this mitigation will have no effect in the future. The fundamental reason is that simply imposing a delay will not reduce the mutual information. Suppression mitigation, on the other hand, is designed to decrease the information a SpyCon can harvest. The main idea of this mitigation technique is to give SpyCon false adaptation actions. For SpyCon that are detected on the phone (i.e., associated with high-suspicious score), VindiCo can return action values associated with another context without affecting the actual actions taken by the trusted app and hence eliminating any negative affect  on the system. On other hand, if the cloud is associated with a high-suspicious score, VindiCo will corrupt the actions before they are sent to the cloud leading to some negative effect on the whole system performance.

Mitigate by
Masking. Yet another mitigation to increase obfuscation is to mask some action values, i.e., returning zeros. We explore two variants of the masking approach: row-masking and feature-masking. In row-masking, our system returns correct action values, but with a certain probability , our system returns 0 to SpyCon for all the action values after context changes. The masking effect takes place until the next adaptation is made. In consequence, SpyCon cannot infer anything during the masked periods, but can still make inferences based on the unmasked observations. The feature-masking approach, in contrast, considers each action value individually. Upon an adaptation is made, each action has a certain probability to be masked. As a result, at any given context change, the SpyCon can only observe partial action values after an adaptation occurs. The decision of masking all actions in row-masking or which action values to be masked in feature-masking depends on flipping a biased coin with a selected probability , which serves as the parameter of mitigation effectiveness. The evaluation of the mitigation techniques is shown in Section 5.3.

IMPLEMENTATION
VindiCo is implemented by modifying the Android system image for platform 5.0.1 API 22 [5]. We extend the Android system layer to add the three main parts of VindiCo as shown in explained in Section 3. VindiCo increases the sizes of system image by 4.5% (original image size is 998 MByte). The overhead on the API call is shown in Section 4.3 Upon installation time (as shown in Figure 6) VindiCo searches for the registry file and creates the necessary data structures to track all changes in user contexts and actions associated with these changes. It then creates a list called Protection Lists and Mutual Information tables that keeps track of the available information at each app and the cloud.
To update these tables, VindiCo intercepts all the calls between apps and the Android OS. Whenever an app (or the cloud) gets information about context changes, VindiCo starts to suspect this app (or the cloud) by assigning a suspicion score to this app (or the cloud service). The value of this suspicion score is equal to the mutual information associated with the getter API (invoked by the app) which is stored in the mutual information tables. Since the same app may have called several getter APIs belonging to different Protection Lists, VindiCo associates a set of suspicion scores (instead of just one suspicion score), one per Protection List in a table that is called applications suspicion scores table.

VindiCo Detection Engine
An important aspect that is related to the use of mutual information is the convergence of estimated mutual information to the actual mutual information from the data samples accessed by VindiCo. That is, it is well known that calculating an estimate of mutual information with enough precision requires the access to multiple samples from both context and triggered actions 11 . Hence, one can argue that a malicious spyware-who is aware of the existence of VindiCo as per assumption T4 in our threat model-may be tempted to reduce the frequency for which it monitors the actions with the goal of decreasing the number of samples used to estimate his mutual information and hence deceives VindiCo by reducing the associated suspicion score 12 . To avoid such situation, we associate mutual information to actions instead of apps. That is, whenever an action takes place, we update the amount of mutual information between this particular action and all the context associated with it. At any time point, once an app monitors this action, we copy the mutual information associated with this action to the app. Therefore, regardless of how frequent an app monitors actions, we associate to it the mutual information based on all samples in history-recall that the number of these samples are not controlled by the malicious app-not only on those to which it has access.

VindiCo Mitigation Engine
As mentioned in Section 3.4, VindiCo does not presume any mitigation treatment outperforms the others, and opportunistically selects a method and see the effect and gradually increases the mitigation. If the suspicion score cannot be effectively decreased, VindiCo will switch to another mitigation method. To optimize the run-time of mitigation engine, we cache the decisions taken by the mitigation engine on this API call for each calling application while a separate thread update this cache based on mutual information values.

Timing Analysis of VindiCo
The execution time is obtained using Android traceview [54]. Table 5 shows the CPU execution time when the complexity of the context-aware app increases, which is majorly reflected by the number of adaptation tags in the registry file.
Parsing and processing the registry file take approximately 6 . Fortunately, this overhead takes place only during the installation of a new package on the phone. On the other hand, at runtime, VindiCo adds negligible overhead (less than 0.1 ) which is approximately 3% increase from the average execution time of the original API call.

EVALUATION
In this section, we discuss the performance of the proposed VindiCo in mitigating possible SpyCon Edge and SpyCon Cloud.

Experiment 4: How many SpyCon Edge in the market?
We start by examining how many apps currently in the market and have the capability of being a successful SpyCon Edge app. While identifying whether a real app is actually exploiting the proposed side-channel is hard to be checked without the knowledge of the app behavior, we focus in this experiment, instead, on identifying real apps in the market that possess enough information to leak sensitive information about phone user.
To that end, we performed static analysis on 45 of the most downloaded free apps from the Google Play store to check which getter APIs are being used by these apps. Next, we intercepted these getter APIs to retrieve the information possessed by these applications. Finally, we use this data to leak information about the phone user when a location-based context adaptation apps like Tasker/Locale and Silence (a calendar events-based context adaptation app) are taking actions by changing the phone setups based on location and calendar events, respectively. As mentioned in Section 2, context-based apps are increasingly used by IoT platforms like IBM Watson IoT to allow the designed IoT system to adapt its functionality to the human user. Figure 7 shows the accuracy of retrieving the user context from the data available to the 45 apps. Our results show that 86% of the top downloaded free apps have enough information to leak user context with some of the apps scoring more than 80% accuracy in leaking user context when a location-based context aware app is used. Similarly, for calendar-based context, 64% of these apps can leak sensitive information with an accuracy more than 80% showing the significance of this side-channel information.

Detection Accuracy.
We investigate the effect of choosing the alarm threshold (the threshold on the suspicion score above which an app is considered malicious) on the performance of the proposed information-based detection algorithm. In particular, we evaluate the performance of the detection engine regarding both the false positive rate and false negative rate. In this context, an application is considered malicious whenever its clustering accuracy exceeds the baseline accuracy by blind guesses defined in Section 2.1.3. A false positive flags the case when the information-based detector claims that an application possesses enough information to accurately identify the user behavior with accuracy more than the baseline accuracy while the real accuracy of the app is indeed lower than the baseline accuracy. A false negative is defined similarly. Similar to the previous experiment, we focus again on the case when SpyCon is monitoring phone settings changed by a location-based context-aware app (Tasker/Locale) and when these settings are changed by a calendar events-based context-aware app (Silence).

5.2.2
Detection of SpyCon in the Market. Next, we ran the proposed information-based detection algorithm (with alarm threshold set to 0.65) against the 45 real applications from the market used in Experiment 4. Recall that Experiment 4 asserts most apps can identify the user context with accuracy more than 80% which in turn indicates that each app possesses high amount of information. Running the proposed information-based detection algorithm against these applications results into suspicion scores that are greater than the alarm threshold for all the 45 apps. Therefore, VindiCo marks all these apps as malicious reflecting the fact that these apps possess enough information to leak sensitive details

Experiment 6: Performance of Mitigation Algorithms
To evaluate the performance of the proposed mitigation technique, we applied the proposed mitigation methods on SpyCon Edge and SpyCon Cloud.

5.3.1
Mitigation of SpyCon Edge. In Figure 9, we plot the profile timeline of user 2 (the profile of the same user was analyzed and discussed previously in Section 2.1) after applying different mitigation techniques. Comparing the results in Figure 3c and Figure 9, we notice the distortion in the patterns of user profile compared to the case when no mitigation is applied. To better judge the effect of the proposed mitigation algorithms, we plot in Figure 10 the accuracy of the developed clustering algorithm when different mitigation techniques are applied along with the corresponding mutual information. These results show how the SpyCon accuracy (measured as the accuracy increase above the baseline accuracy) drops in general to the baseline accuracy. Moreover, and as expected from the theoretical underpinnings of mutual information, whenever mutual information decreases-as a consequence of the mitigation parameter (number of records in suppression case and the probability of masking in the row-masking and feature masking case)-the accuracy of the developed SpyCon must decrease (on average). We also observe that the suppression method leads to a sharp decrease in the mutual information with a fast saturation whenever > 2 as shown in Figure 10a. In contrast, the other two proposed mask mitigation methods (row-masking and feature-masking) lead to a gradual decrease in the mutual information as the probability of masking increases (Figure 10b, 10c). This gradual degradation provides more flexibility for VindiCo to adjust to a desired mutual information.
Finally, though we expect mutual information should monotonically decrease when the mitigation is stronger (higher masking probability), 10c shows that mutual information goes higher when masking probability = 0.1. One possible explanation is that noisy settings are cleared with this configuration, causing higher correlation between mitigated data (c) Occupancy detection after masking mitigation (p=0.8) Fig. 11. Activity and occupancy timeline of human #1 after VindiCo applies the mitigation techniques and user profile. However, the mutual information decreases sufficiently when larger masking probability is applied (i.e., >= 0.4).

Mitigation of SpyCon Cloud.
Using the same mitigation procedure as SpyCon Edge (Section 5.3.1), we plot the mitigation results of human #1 in Figure 11. We applied row masking and feature masking simultaneously with different probabilities. We observe that the performance of the SpyCon Cloud in detecting the user profile is adversely affected by increasing the probability of masking. Similarly, as shown in Figure 11c, the SpyCon ability to detect home occupancy degraded severely as a consequence of applying the mitigation. The decrease in accuracy for both human 1 and human 2 across different probabilities of mitigation is shown in Figure 12. for the human thermal comfort [20]-before and after mitigation in Figure 13. The PMV score ranges from −3 to 3 which is the range of thermal sensation from very cold (−3) to very hot (3). According to ISO standard ASHRAE 55 [7], a PMV in the range of −0.5 and +0.5 for an interior space is recommended to achieve thermal comfort. We used the Fanger model in EnergyPlus to estimate the PMV value [20]. In particular, as seen in Figure 13, a choice of masking probability equal 0.6 lead to user PMV in the range of −0.8 to 1.2 while achieving a degradation in SpyCon accuracy by 45% (as shown in Figure 12). To exacerbate the situation, our experiments showed that this new spyware is undetectable using off-the-shelf antivirus packages and moreover many of the top 45 downloadable free Android apps have enough information to reveal sensitive user information. In the second example (SpyCon Cloud), we showed a simulated example of a smart HVAC, in which the cloud service has a mounted SpyCon. In our experiments, we showed how the mounted SpyCon can infer the user's occupancy at home and his daily schedule (awake, sleep).
To circumvent such scenarios, we designed VindiCo, a safeguard which protects authentic HITL IoT applications against leaking private information via this side-channel. VindiCo employs a detection technique based on mutual information which is agnostic to the SpyCon implementation details. VindiCo uses three mitigation techniques. Our mitigation techniques have shown a degradation of SpyCon Edge inference accuracy from 90.3% to the baseline accuracy and a degradation in SpyCon Cloud by 45% and by only adding negligible overhead (3%) on the API call performance. Future work includes studying the effect of collaborative SpyCon. In such scenario, multiple IoT devices collect different (or partial) information from the proposed side-channel and fuse them to leak sensitive user information while maintaining small individual mutual information and hence bypass the information-based detection algorithm.