Smart Dressing Sensor

6thSense: A Context-aware Sensor-based Attack Detector for Smart Devices Amit Kumar Sikder, Hidayet Aksu, A. Selcuk Uluagac

Abstract

Sensors (e.g., light, gyroscope, accelerometer) and sens- ing enabled applications on a smart device make the ap- plications more user-friendly and efficient. However, the current permission-based sensor management systems of smart devices only focus on certain sensors and any App can get access to other sensors by just accessing the generic sensor API. In this way, attackers can exploit these sensors in numerous ways: they can extract or leak users’ sensitive information, transfer malware, or record or steal sensitive information from other nearby devices.

In this paper, we propose 6thSense, a context-aware in- trusion detection system which enhances the security of smart devices by observing changes in sensor data for different tasks of users and creating a contextual model to distinguish benign and malicious behavior of sen- sors. 6thSense utilizes three different Machine Learning- based detection mechanisms (i.e., Markov Chain, Naive Bayes, and LMT) to detect malicious behavior associated with sensors. We implemented 6thSense on a sensor- rich Android smart device (i.e., smartphone) and col- lected data from typical daily activities of 50 real users.

Furthermore, we evaluated the performance of 6thSense against three sensor-based threats: (1) a malicious App that can be triggered via a sensor (e.g., light), (2) a mali- cious App that can leak information via a sensor, and (3) a malicious App that can steal data using sensors. Our extensive evaluations show that the 6thSense framework is an effective and practical approach to defeat growing sensor-based threats with an accuracy above 96% with- out compromising the normal functionality of the device.

Moreover, our framework costs minimal overhead.

Introduction

Smart devices such as smartphones and smartwatches have become omnipresent in every aspect of human life. Nowadays, the role of smart devices is not limited to making phone calls and messaging only. They are in- tegrated into various applications from home security to health care to military [18, 60].

Since Smart Devices

seamlessly integrate the physical world with the cyber world via their sensors (e.g., light, accelerometer, gyro- scope, etc.), they provide more efficient and user-friendly applications [37, 41, 85, 55, 48].

While the number of applications using different sen- sors is increasing and new devices offer more sen- sors, the presence of sensors have opened novel ways to exploit the smart devices . Attackers can exploit the sensors in many different ways : they can trig- ger an existing malware on a device with a simple flash- light ; they can use a sensor (e.g., light sensor) to leak sensitive information; using motion sensors such as ac- celerometer, and gyroscope, attackers can record or steal sensitive information from other nearby devices (e.g., computers, keyboards) or people [10, 87, 26, 42]. They can even transfer a specific malware using sensors as a

Communication Channel . Such Sensor-Based Threats

become more serious with the rapid growth of Apps uti- lizing many sensors [6, 2]. In fact, these sensor-based threats highlight the flaws of existing sensor management systems used by smart devices. Specifically, Android sensor management sys- tem relies on permission-based access control, which considers only a few sensors (i.e., microphone, camera, and GPS)1. Android asks for access permission (i.e., with a list of permissions) only while an App is being installed for the first time. Once this permission is granted, the user has no control over how the listed sensors and other sensors (not listed) will be used by the specific App.

Moreover, using some sensors is not considered as a vi- olation of security and privacy in Android. For instance, any App is permitted to access to motion sensors by just accessing the sensor API. Access to motion sensors is not controlled in Android.

1IOS, Windows, and Blackberry also have permission-based sensor management systems. In this work, we focus on Android.

Arxiv:1706.10220V1 [Cs.Cr] 30 Jun 2017

Existing studies have proposed enhanced access con- trol mechanisms for some of the sensors, but these en- hancements do not cover all the sensors of a smart de-

Vice . Some Proposed Solutions Introduced Trusted

paths on top of the existing security mechanism for con- trolling information flow between sensors and Apps, but these are also App-specific solutions and depend upon explicit user consent [32, 61].

Thus, Introducing Ad-

ditional permission controls for sensors of a smart de- vice will not mitigate the risk of all sensor-based threats as they are App specific and address only data leakage risks. Some attacks may not abuse sensors directly, in- stead, they may use sensors as side channels to acti- vate another malware . Albeit useful, existing se- curity schemes overlook these critical threats which di- rectly impact the security and privacy of the smart device ecosystem. Moreover, although sensors on smart devices seem to work independently from each other, a task or activity on a smart device may activate more than one sensor to accomplish the task. Hence, it is necessary to secure all the different sensors on a smart device and consider the context of the sensors in building any solu- tion against sensor-based threats.

In order to address the sensor-based threats, in this pa- per, we present a novel intrusion detection (IDS) frame- work called 6thSense, a comprehensive security solution for sensor-based threats for smart devices. The proposed framework is a context-aware IDS and is built upon the observation that for any user activity or task (e.g., tex- ting, making calls, browsing, driving, etc.), a different, but a specific set of sensors becomes active. In a context- aware setting, the 6thSense framework is aware of the sensors activated by each activity or task. 6thSense ob- serves sensors data in real time and determines the cur- rent use context of the device according to which it con- cludes whether the current sensor use is malicious or not. 6thSense is context-aware and correlates the sen- sor data for different user activities (e.g., texting, mak- ing calls, browsing, driving, etc.) on the smart device and learns how sensors’ data correlates with different ac- tivities. As a detection mechanism, 6thSense observes sensors’ data and checks against the learned behavior of the sensors. In 6thSense, the framework utilizes several different Machine Learning-based detection mechanisms to catch sensor-based threats including Markov Chain, Naive Bayes, and LMT. In this paper, we present the design of 6thSense on an Android smartphone because of its large market share and its rich set of sensors.

To evaluate the efficiency of the framework, we tested it with data collected from real users (50 different users, nine different typical daily activities ). We also evalu- ated the performance of 6thSense against three different sensor-based threats and finally analyzed its overhead.

Our evaluation shows that 6thSense can detect sensor- based attacks with an accuracy and F-Score over 96%. Also, our evaluation shows a minimal overhead on the utilization of the system resources.

Contributions: In summary, the main contributions of

This Paper Are Threefold—

• First, the design of 6thSense, a context-aware IDS to detect sensor-based threats utilizing different ma-

Chine Learning Based Models From Markov Chain To

Naive Bayes to LMT.

• Second, The Extensive Performance Evaluation Of

6thSense with real user experiments over 50 users.

Testing 6Thsense Against Three Different

sensor-based threats. Organization: The rest of the paper is organized as follows: we give an overview of sensor-based threats and existing solutions in Section 2.

In Section 3, We

briefly discuss the Android’s sensor management system. Adversary model and design facts and assumptions for 6thSense are briefly discussed in Section 4. Different de- tection techniques used in our framework are described in Section 5. In Sections 6 and 7, we provide a detailed overview of 6thSense including its different components and discuss its effectiveness by analyzing different per- formance metrics. Finally, we discuss features and lim- itations and conclude this paper in Sections 8 and 9, re- spectively.

Sensor-Based Threats On Mobile Devices Have Be-

come more prevalent than before with the use of dif- ferent sensors in smartphones such as user’s location, keystroke information, etc. Different works have in- vestigated the possibility of these threats and presented different potential threats in recent years.

One Of The

most common threats is keystroke inference in smart-

Phones. Smartphones Use On-Screen Qwerty Keyboard

which has specific position for each button. When a user types in this keyboard, values in smartphone’s motion sensor (i.e., accelerometer and gyroscope) change ac- cordingly . As different keystrokes yield different, but specific values in motion sensors, typing informa- tion on smartphones can be inferred from an unautho- rized sensor such as motion sensor data or motion sen- sor data patterns collected either in the device or from a nearby device can be used to extract users’ input in smartphones [9, 66, 52]. The motion sensor data can be analyzed using different techniques (e.g., machine learning, frequency domain analysis, shared-memory ac- cess, etc.) to improve the accuracy of inference tech- niques such as [12, 53, 81, 46, 58, 47]. Another form of keystroke inference threat can be performed by observ- ing only gyroscope data. Smartphones have a feature of creating vibrations while a user types on the touch- pad. The gyroscope is sensitive to this vibrational force and it can be used to distinguish different inputs given by the users on the touchpad [51, 15, 44].

Recently,

ICS-CERT also issued an alert for accelerometer-based attacks that can deactivate any device by matching vi- bration frequency of the accelerometer [2, 1, 70]. Light sensor readings also change while a user types on the smartphone; hence, the user input in a smartphone can be inferred by differentiating the light sensor data in nor- mal and typing modes . The light sensor can also be used as a medium to transfer malicious code and trigger message to activate malware [28, 76]. The audio sen- sor of a smartphone can be exploited to launch different malicious attacks (e.g., information leakage, eavesdrop- ping, etc.) on the device. Attackers can infer keystrokes by recording tap noises on touchpad , record conver- sation of users , transfer malicious code to the device [73, 76], or even replicate voice commands used in voice- enabled different Apps like Siri, Google Voice Search, etc. [21, 39]. Modern smartphone cameras can be used to covertly capture screenshot or video and to infer infor- mation about surroundings or user activities [68, 43, 67].

GPS of a smartphone can be exploited to perform a false data injection attack on smartphones and infer the loca- tion of a specific device [75, 19].

Although Re-

searchers identified different sensor-based threats in re- cent years, no complete security mechanism has been proposed that can secure sensors of a smart device.

Most of the proposed security mechanisms for smart de- vices are related to anomaly detection at the application level [78, 74, 80, 22] which are not built with any protec- tion against sensor-based threats. On the other hand, dif- ferent methods of intrusion detection have been proposed for wireless sensor networks (WSN) [72, 30, 86, 23, 59], but they are not compatible with smart devices. Xu et al. proposed a privacy-aware sensor management frame-

Work For Smartphones Named Semadroid , An Exten-

sion to the existing sensor management system where users could monitor sensor usage of different Apps and invoke different policies to control sensor access by ac- tive Apps on a smartphone. Petracca et al. introduced AuDroid, a SELinux-based policy framework for smart- phones by performing behavior analysis of microphones

And Speakers . Audroid Controls The Flow Of Infor-

mation in the audio channel and notifies users when- ever an audio channel is requested for access. Jana et

Al. Proposed Darkly, A Trust Management Framework

for smartphones which audits applications of different trust levels with different sensor access permissions . Darkly scans for vulnerability in the source code of an

Figure 1: Android Sensor Management Architecture

application and try to modify the run-time environment of the device to ensure the privacy of sensor data.

Though

there is no direct comparable work to compare 6thSense with, differences between existing solutions and our framework can be noted as follows. The main limitation of Semadroid is that the proposed solution is only tested against a similar type of attack scenario (informa- tion leakage by a background application). Semadroid also does not provide any extensive performance evalua- tion for the proposed scheme. Finally, this work depends on user permissions to fully enforce an updated policy on the sensor usage which is vulnerable as users might unknowingly approve the sensor permissions for mali- cious Apps. In another prior work Darkly , the pro- posed framework is not tested against any sensor-based threats. More recent work Audroid presented a policy enforced framework to secure only the audio channels of a smart device. Albeit useful, similar to the others, this work does not consider other sensor-based threats, either. Compared to these prior works, 6thSense pro- vides a comprehensive coverage to all the sensors in a smart device and ensures security against three different types of sensor-based threats with high accuracy.

Smart Devices

Present versions of Android, iOS, or Blackberry do not comprise of any security mechanism to manage the infor- mation flow from sensors or among them. For example, any App can get access to motion sensors by just access- ing sensor API. One task may need more than one sensor, but protecting only one sensor is not a viable design. The lack of ability to secure the information flow between the sensors and Apps and a holistic view into the utilization of sensors can lead to different malicious scenarios like information leakage, eavesdropping, etc.

In our work, we focus on Android because of its open- source nature. In Figure 1, we present how Android han- dles access to different sensors by Apps (installed by the user) and system Apps (installed automatically by An- droid). Apps access to sensors by sending requests via

Software Development Kit (Sdk) Api Platform Which

then registers the App to a corresponding sensor . If more than one App tries to access the same sensor, the SDK API runs a multiplexing process which enables dif- ferent Apps to be registered in the same sensor. Hard- ware Abstraction Layer (HAL) works as an interface to bind the sensor hardware with the device drivers in An- droid. HAL has two parts: Sensors.h works as HAL in- terface and Sensors.cpp works as the HAL implementa- tion. Through the HAL library, different applications can communicate with the underlying Linux kernel to read and write files associated with sensors. For most of the sensors, no permission is needed to access these files. For permission-imposed sensors (i.e., camera, microphone, and GPS), a permission is explicitly needed from the user to ensure file access to a specific App. This user permis- sion is declared inside the AndroidManifest.xml file of an App and once the user accepts the permission, that App can have access to the corresponding sensor and other no-permission imposed sensors even without any explicit approval from the users. This lack of security in sensor access can lead to different malicious attacks on a device.

Adversary Model And Assumptions

In this section, we discuss different threats that may use sensors to execute malicious activities on a smart device. Different design assumptions are also explained in this section.

Adversary Model

For this work, we consider the following sensor-based

• Threat 1-Triggering A Malicious App Via A Sen-

sor. A malicious App can exist in the smart device

Which Can Be Triggered By Sending A Specific Sen-

sory pattern or message via sensors. • Threat 2-Information leakage via a sensor. A ma- licious App can exist in the device which can leak information to any third party using sensors.

• Threat 3-Stealing information via a sensor. A ma- licious App can exist in the device which can exploit the sensors of a smart device and start stealing infor- mation after inferring a specific device mode (e.g., sleeping).

In this paper, we cover these three types of malicious sensor-based threats. We also note that to build our ad- versary model, we consider any component on a smart device that interacts with the physical world as a sen-

Sor . In Section 7, We Show How 6Thsense Defends

against these threats.

In Designing A Comprehensive Security Scheme Like

6thSense for sensor-based threats, we note the following

Design Assumptions And Features:

• Sensor co-dependence: A sensor in a smart device is normally considered as an independent entity on the device. Thus, one sensor does not know what is happening in another sensor. However, in this work,

We Consider Sensors As Co-Dependent Entities On A

device instead of independent entities. The reason for this stems from the fact that for each user activity or task on a smart device, a specific set of sensors re- mains active. For example, if a user is walking with

Accelerometer), The Light Sensor, Gps Will Be Ac-

tive. On the contrary, if the user is walking with the phone in the pocket or bag, instead of the light sen- sor, the proximity sensor will remain active. Thus, a co-dependent relationship exists between sensors while performing a specific task. Each activity uses different, but specific set of sensors to perform the task efficiently. Hence, one can distinguish the user activity by observing the context of the sensors for a specific task. 6thSense uses the context of all the sensors to distinguish between normal user activi- ties and malicious activities. In summary, sensors in a smart device are individually independent, but per activity-wise dependent and 6thSense considers the context of the activities in its design.

• Adaptive sensor sampling: Different sensors have different sampling frequencies. To monitor all the

Sensor Data For A Specific Time, A Developed Solu-

tion must consider and sample the sensor data cor-

Rectly. Our Proposed Framework Considers Sampling

the sensor data over a certain time period instead of

Individual Sensor Frequencies Which Mitigates Any

possible error in processing of data from different sensors.

• Faster Computation: Modern High Precision Sen-

sors on smart devices have high resolution and sam- pling rate. As a result, sensors provide large volume of data even for a small time interval. A solution for sensor-based threats should quickly process any large data from different sensors in real time while ensuring a high detection rate. To address this, we use different machine learning algorithms which are proven simple and fast techniques [11, 62].

• Real-time monitoring: 6thSense provides real-time

Monitoring To All The Sensors Which Mitigates The

possibility of data tempering or false data injection on the device.

Dation

In this section, we describe the details of the detection techniques used in 6thSense from a theoretical perspec- tive.

For the context-aware IDS in 6thSense, we utilize sev- eral different machine learning-based techniques includ-

Ing Markov Chain , Naive Bayes And Alterna-

tive set of ML algorithms (e.g., PART, Logistic Function, J48, LMT, Hoeffding Tree, and Multilayer Perception) to differentiate between normal behavior from malicious behavior on a smart device. The main advantage of us- ing Markov Chain model is that it is easy to build the model from a large dataset and computational require- ments are modest which can be met by resource-limited devices. As smart devices have less processing speed, a Markov Chain-based approach can work smoothly in the context of sensor data analysis. On the other hand, Naive Bayes technique is chosen for its fast computa- tion rate, small training dataset requirement, and ability to modify it with new training data without rebuilding the model from scratch. Other ML techniques are also common in malware detection because of higher accu- racy rate. A brief discussion of these approaches in the context of 6thSense is given below. The efficacy of these different approaches utilized in 6thSense is analyzed in Section 7.

Markov Chain-Based Detection

A Markov Chain-based detection model can be described as a discrete-time stochastic process which denotes a set of random variables and defines how these variables change over time. Markov Chain can be applied to illus- trate a series of events where and what state will occur next depends only on the previous state. In 6thSense, a series of events represents user activity and state repre- sents sensor conditions (i.e., sensor values, on/off status) of the sensors in a smart device. We can represent the probabilistic condition of Markov Chain as in Equation

(1)

In 6thSense, we observe the changes of the conditions of a set of sensors as a variable which changes over time. The condition of a sensor indicates whether the sensor value is changing or not from a previous sensor value in time. As such, S denotes a set which represents current conditions of n number of sensors. So, S can be repre- sented as follows.

(2)

For 6thSense, we use a modified version of the general Markov Chain. Here, instead of predicting the next state, 6thSense determines the probability of a transition oc- curring between two states at a given time. In 6thSense, the Markov Chain model is trained with a training dataset collected from real users and the transition matrix is built accordingly. Then, 6thSense determines conditions of sensors for time t and t+1. Let us assume, a and b are a sensor’s state in time t and t+1. 6thSense looks up for the probability of transition from state a to b which can be found by looking up in the transition matrix, P and calculating P(a,b). As the training dataset consists sen- sor data from benign activities, we can assume that, if transition from state a to b is malicious, the calculated probability from transition matrix will be zero. Details of this Markov Chain-based detection model in 6thSense are given in Appendix A1.

Naive Bayes Based Detection

Naive Bayes model is a simple probability estimation method which is based on Bayes’ method. The main as- sumption of the Naive Bayes detection is that the pres- ence of a particular sensor condition in a task/activity has no influence over the presence of any other feature on that particular event. The probability of each event can be calculated by observing the presence of a set of specific features.

6thSense considers users’ activity as a combination of n number of sensors. Assume X is a set which repre- sents current conditions of n number of sensors. We con- sider that conditions of sensors are conditionally inde- pendent (See Section 4.2), which means a change in one sensor’s working condition (i.e., on/off states) has no ef- fect over a change in another sensor’s working condition.

As explained earlier, the probability of executing a task depends on the conditions of a specific set of sensors. So, in summary, although one sensors’ condition does not control another sensor’s condition, overall the proba- bility of executing a specific task depends on all the sen- sors’ conditions. As an example, if a person is walking with his smartphone in his hand, the motion sensors (ac- celerometer and gyroscope) will change. However, this change will not force the light sensor or the proximity sensor to change its condition. Thus, sensors in a smart- phone change their conditions independently, but execute a task together. We can have a generalized model for this

Detailed Description Of This Naive Bayes Model In

6thSense is given in Appendix A2.

In Addition To Markov Chain And Naive Bayes Mod-

els above, there are other machine learning algorithms (such as PART, Logistic Function, J48, LMT, Hoeffding Tree, and Multilayer Perception) that are very popular for anomaly detection frameworks because of their faster computation ability and easy implementation feature. In the alternative detection techniques, we used four types of ML-based classifier to build an analytical model for 6thSense. The following briefly discusses these classi- fiers and our rationale to include them.

Rule-Based Learning. Rule-Based Ml Works By Iden-

tifying a set of relational rules between attributes of a given dataset and represents the model observed by the system . The main advantage of the rule-based learn- ing is that it identifies a single model which can be ap- plied commonly to any instances of the dataset to make a prediction of outcome. As we train 6thSense with differ- ent user activities, the rule-based learning provides one model to predict data for all the user activities which sim- plifies the framework. For 6thSense, we chose, PART al- gorithm for the rule-based learning.

Regression Model. Regression model is widely used in data mining for its faster computation ability. This type of classifier observes the relations between dependent and independent variables to build a prediction model [20, 79].

For 6Thsense, We Have A Total 11 Attributes

where we have one dependent variable (device state: malicious/benign) and ten independent variables (sensor conditions). Regression model observes the change in the dependent variable by changing the values of the in- dependent variables and build the prediction model. We use the logistic regression model in 6thSense, which per- Figure 2: Overview of 6thSense.

forms with high accuracy against conventional Android malware .

Neural Network. Neural Network Is Another Common

technique that is being adapted by researchers for mal- ware detection. In neural network techniques, the rela- tion between attributes of dataset is compared with the biological neurons and a relation map is created to ob- serve the changes for each attribute . We chose Mul- tilayer Perceptron algorithm for training the 6thSense framework as it can distinguish relationships among non- linear dataset.

Decision Tree. Decision tree algorithms are predictive models where decision maps are created by observing the changes in one attribute in different instances .

These types of algorithms are mostly used in a prediction model where output can have a finite set of values. For 6thSense, we utilized and tested three different decision tree algorithms (J48, LMT (Logistic Model Tree), and Hoeffding tree) to compare the outcome of our frame- work.

6Thsense Framework

In this section, we provide a detailed overview of our proposed contextual behavior IDS framework, 6thSense, for detecting sensor-based threats on smart devices. As illustrated in Figure 2, 6thSense has three main phases: (1) data collection, (2) data processing, and (3) data anal- ysis. In the data collection phase, we use a custom An- droid application to collect the sensor data for differ- ent user activities and the collected sensor data are then processed in the data processing phase.

Note That In

6thSense some sensors provide discrete values as data (e.g., accelerometer, gyroscope, light sensor, etc.) while other sensors provide their on-off state as sensor data (e.g., microphone, speaker, etc.). In phase 3, the col- lected data is fed into detection models and the end result indicates whether the current state of the device is mali- cious or not. The following sub-sections briefly describe these three phases.

Data Collection Phase

In this phase, 6thSense collects data from different sen- sors of a smart device. There can be multiple sensors in a smart device. We chose nine sensors in total to identify different user activities using a sensor-rich Android de- vice. The sensors selected are accelerometer, gyroscope, light sensor, proximity sensor, GPS, audio sensor (micro- phone and speaker), camera, and headphone. 6thSense does not consider all the other sensors available in the device because all typical user activities do not affect all the sensor values. For example, the gravity sensor value does not change effectively while talking or walking with the phone. The chosen sensors are then categorized into two following categories.

Ter, Gyroscope, Light, Proximity Sensors). We Can

also refer these sensors as data-oriented sensors in the context of 6thSense because values provided by these sensors need to be observed to infer user activ- ities. For example, accelerometer’s and gyroscope’s

The Motion In Different Axes. To Detect Whether A

sensor is activated or not for a specific activity, one needs to observe values of these sensors.

• Permission-Imposed Sensors: Permission-Imposed

sensors are those which need user permission to be

And Headset). The Conditions Of These Sensors Can

be represented by their logical states (on/off status) for different user activities. Hence, we also referred to these sensors as logic-oriented sensors in the con- text of 6thSense. For example, camera has only two values to identify users’ activity: on and off. So, it can be represented with 0 or 1 to detect if the cam- era is on or off correspondingly.

To collect the data and logical values from sensors, we built a custom Android App and 6thSense used this in the data collection phase. In Android, this App uses sensoreventlistener API to log numerical values of the data-oriented sensors. On the other hand, the App deter- mines the state of the sensor and logs 0 or 1 if the sensor is on or off, respectively. This App uses the user permis- sion access to use the microphone, GPS, and camera to record the working condition of these sensors. For GPS, we consider two datasets - either GPS is turned on or not and either location is changing or not. In total, six different logic state information for five aforementioned permission-imposed sensors are collected by this App.

Note that we chose different typical daily human activ- ities that involve the smart device to build our contex- tual model. These activities include walking (with phone in hand and pocket), talking, interacting (playing games, browsing, listening to music), video calling, driving (as driver and passenger). Furthermore, the number of ac- tivities is configurable in 6thSense and is not limited to aforementioned examples. In the evaluation of 6thSense, we chose a total of nine typical daily activities as they are considered as common user activities for a smart de- vice . We collect these data using the App for different users to train the 6thSense framework which is then used to distinguish the normal sensor behavior from the ma- licious behavior. In summary, the aforementioned App collects data from nine different sensors for nine typi- cal user activities. We observe sensor state (combina- tion of working conditions (i.e., values, on/off status) of nine different sensors) in a per second manner for each user activity. Each second of data for user activity cor- responds to 1024 state information from nine different sensors.

Data Processing Phase

After the data collection, in the second phase of the framework, we organize the data to use in the proposed IDS framework. As different sensors have different fre- quencies on the smart device, the total number of read- ings of sensors for a specific time period is different. For example, the accelerometer and gyroscope of Samsung Galaxy S5 have a sampling frequency of approximately 202 Hz while the light sensor has a sampling frequency of 5.62 Hz. Thus, the data collected in Phase 1 needs to be sampled and reorganized. 6thSense observes the change in the sensor condition in each second to deter- mine the overall state of our device and from this per second change, 6thSense determines the activity of users.

For this reason, 6thSense takes all the data given by a sin- gle sensor in a second and calculates the average value of the sensor reading. This process is only applicable for the data oriented sensors as mentioned earlier. Again, the data collected from the App is numerical value given by the sensor. However, for the detection model, we only

110 Db, 1 Ma

Table 1: Sensor list of Samsung Galaxy S5 Duo used in experiment. consider the condition of the sensors. 6thSense observes the data collected by the aforementioned App and deter- mines whether the condition of sensors is changing or not. If the sensor value is changing from the previous value in time, 6thSense represents the sensor condition as 1 and 0 otherwise. The logic state information col- lected from the sensors need to be reorganized, too as these data are merged with the data collected from the collected values from the other sensors to create an in- put matrix. The sampling frequency of the logical state detection is 0.2 Hz which means in every five seconds the App generates one session of dataset. We consider the condition of the sensors to be the same over this time period and organize the data accordingly. The reorga- nized data generated from the aforementioned App are then merged to create the training matrices.

Data Analysis Phase

In the third and final phase, 6thSense uses different ma- chine learning-based detection techniques introduced in the previous section to analyze the data matrices gener- ated in the previous phase.

For the Markov Chain-based detection, we use 75% of the collected data to train 6thSense and generate the tran- sition matrix. This transition matrix is used to determine whether the transition from one state to another is appro- priate or not. Here, state refers to generic representation of all the sensors’ conditions on a device. For testing pur- poses we have two different data set — basic activities or trusted model and malicious activities or threat model.

The trusted model consists of 25% of the collected data for different user activities. We test the trusted model to ensure the accuracy of the 6thSense framework in de- tecting benign activities. The threat model is built from performing the attack scenarios mentioned in Section 4.

We calculate the probability of a transition occurring be- tween two states at a given time and accumulate the total probability to distinguish between normal and malicious activities.

To implement the Naive Bayes-based detection tech- nique, we use the training sessions to define different user activities. In 6thSense, we have nine typical user activities in total as listed in Table 2. We use groundtruth user data to define these activities. Using the theoretical foundation explained in Section 5, we calculate the prob- ability of a test session to belong to any of these defined activities. As we consider one second of data in each computational cycle, we calculate the total probability up to a predefined configurable time interval (in this case five minutes). This calculated probability is used to de- tect malicious activities from normal activities. If the computed probability for all the known benign activities is not over a predefined threshold, then it is detected as a malicious activity.

For the other alternative machine-learning-based de- tection techniques, we used WEKA, a data mining tool which offers data analysis using different machine learn- ing approaches [64, 27]. Basically, WEKA is a collection of machine learning algorithms developed at the Univer- sity of Waikato, New Zealand, which can be directly ap- plied to a dataset or can be integrated with a framework

Using Java Platform . Weka Offers Different Types

of classifier to analyze and build predictive model from given dataset. We use 10 fold cross-validation method to train and test 6thSense with different ML techniques in Section 7.

Performance Evaluation Of 6Thsense

In this section, we evaluate the efficiency of the proposed context-aware IDS framework, 6thSense, in detecting the sensor-based threats on a smart device. We test 6thSense with the data collected from different users for benign activities and adversary model described in Section 4.

As discussed earlier, 6thSense considers three sensor- based threats: (1) a malicious App that can be triggered via a light or motion sensors, (2) a malicious App that can leak information via audio sensor, and (3) a mali- cious App that steals data via camera. Furthermore, we measured the performance impact of 6thSense on the de- vice and present a detailed results for the efficiency of the 6thSense framework. Finally, we discuss the perfor- mance overhead of the framework in this section.

Training Environment

In order to test the effectiveness of 6thSense, we imple- mented it on a sensor-rich Android-based smartphone. However, our framework would also efficiently work in another smart device such as smartwatch. In the eval- uations, we used Samsung Galaxy S5 Duos as a refer- ence Android device to collect sensor data for different typical user activities. We chose this Android device as Samsung currently holds approximately 20.7% of total marketshare of smartphone and provides a rich set of sensors. A list of sensors of Samsung Galaxy S5 Duos is given in Table 1. As discussed earlier, we selected 9 dif- ferent typical user activities or tasks to collect user data.

These are typical basic activities with smartphones that people usually do in their daily lives . The user ac- tivities/tasks are categorized in two categories as generic activities and user related activities.

Generic activities are the activities in which the sensor readings are not affected by the smartphone users. Sleep- ing, driving with the phone using GPS as a navigator, and driving with phone in pocket are three generic activities that we considered in this work. Basically, in the generic activities, sensors’ data are not affected by different users since the smart phone is not in contact with the user or user is not directly interacting with the phone. For user- related activities, in which the sensor readings may be affected by the device user, we identified six different ac- tivities including walking with the phone in hand, play- ing games, browsing, and making voice calls and video calls.

6thSense was tested by 50 different individuals aged from 18 to 45 while the sensor data was collected. We note that our study with human subjects was approved by the appropriate Institutional Review Board (IRB) and we followed all the procedures strictly in our study. Each participant received some monetary compensation for participating in our experiments. To ensure privacy and anonymity, we used fake user IDs rather than any per- sonal information. We collected 300 sets of data for six user-related activities where each dataset comprised of 5 minutes long data from the selected nine sensors men- tioned in Section 6. We also collected three sets of data for each general activity. We asked the different users to perform the same activity to ensure the integrity for dif- ferent tasks. Note that each five minute of data collected for user related and generic activities corresponds to 300 events with 1024 different states. Here, states represent a combination of conditions (i.e., values, on/off status) of nine different sensors and events represent user activities per second. So, a total of 307,200 different event-state information were analyzed by 6thSense.

For the malicious dataset, we created three different attack scenarios considering the adversary model men- tioned in Section 4. For Threat 1, we developed two dif- ferent Android Apps which could be triggered using the light sensor and motion sensors on the smartphone. To perform the attack described in Threat 2, we developed a malware that could record conversations as audio clips and playback after a specific time to leak the informa- tion. This attack scenario included both the microphone and speaker on the smartphone. For Threat 3, we devel- oped a malicious App that could scan all the sensors and if none of the sensors were changing their working con-

6. Making Video Calls

Table 2: Typical Activities of Users on Smart Device . ditions, the malicious App could open up the camera and record videos surreptitiously. We collected 15 different datasets from these three attack scenarios to test the effi- cacy of 6thSense against these adversaries.

Dataset

In order to test 6thSense, we divided the collected real user data into two sections as it is a common practice

. 75% Of The Collected Benign Dataset Was Used To

train the 6thSense framework and 25% of the collected data along with malicious dataset were used for test- ing purposes.

For The Markov Chain-Based Detection

technique, the training dataset was used to compute the state transitions and to build the transition matrix. On the other hand, in the Naive Bayes-based detection tech- nique, the training dataset was used to determine the fre- quency of sensor condition changes for a particular ac- tivity or task. As noted earlier, there were nine activities for the Naive Bayes technique. We split the data accord- ing to their activity for this approach. For the analysis of the other ML-based approaches, we define all the data in benign and malicious classes. The data were then used to train and test 6thSense using 10-fold cross validation for different ML algorithms.

Related Journal Articles & DOI Links

Selected peer-reviewed publications relevant to 12 Lead ECG Acquisition. Click the DOI to access the full paper (may require institutional access).

Why Choose Us?

Bangalore guidance for robotics, Spectre and autonomous systems projects.