In This Section

Project Description

Smart Home System

In following figure, a typical architecture of a SHS is shown. A SHS has four basic building blocks as shown in Figure 1. The first block of the SHS comprises sensors and devices in the system. These smart home devices and sensors are connected to each other via a smart hub. As there is no generic interoperability standard among smart home devices, the hub provides a common access point for all the entities in the SHS. The hub is connected to both cloud backend service and smartphone/tablet companion app. Users can use the smartphone app to control the smart home entities or install different apps from the app stores. Indeed, we can group SHS architectures in two main categories: a cloud-based architecture where the installed apps run in the cloud backend (e.g., SmartThings), and hub-based architecture where the installed apps run the hub locally (e.g., Apple HomeKit).

Figure: A smart home environment and its major components

Threat Model

For testing Aegis, we classify five different threat models.

Design Features Considered by Aegis

Context-awareness: Context-awareness refers to the ability of a system to use situational and environmental information about the user, location, and devices to adapt its operation accordingly. In a SHS, all the sensors and devices follow different trigger-action scenarios to perform tasks. Here, sensors are used to provide input in the devices (trigger) and devices take autonomous decisions (actions) based on these inputs. When a user performs a task in a SHS, several smart home sensors and devices may become active in a sequential pattern. The pattern of active devices and sensors is different but specific for distinct user activities. Existing SHS cannot observe these patterns in sensors’ and devices’ states over time and can not understand the context of the user activity. For example, while a user moves from one bedroom to a hallway, several devices and sensors become active in a sequential manner (Figure~\ref{context}): moving towards bedroom door (sub-context 1: BL1, BLi1, BM1 are active), bedroom door opens (sub-context 2: BL1, BLi1, BM1, BD1 are active), entering the hallway (sub-context 3: BL1, BLi1, BD1, HLi2, HL2, HM2 are active), bedroom door and light close and reaches the hallway (sub-context 4: HLi2, HL2, HM2 are active). To complete the activity (moving from the bedroom to the hallway), the user must follow the sub-contexts in the same sequential pattern. The user cannot skip one specific sub-context and move to the next one to complete the activity. For instance, the transition from sub-context 1 to sub-context 4 is not possible as a user cannot go to the hallway from the bedroom without opening the door. Motivated by this, Aegis is designed to understand this property of SHS to build a context-aware model for different user activities and usage patterns and differentiates between benign and malicious activities of smart home devices and sensors.

Sensor-device co-dependence: In a SHS, sensors, and devices can be configured as independent entities. However, they work in a co-dependent manner to provide autonomous functionalities. For instance, smart lights can be configured with motion sensors to light up when motion is sensed. Here, the smart light depends on the input from the motion sensor while the motion sensor alone cannot provide any significant function in a SHS. The functions of devices and sensors create a co-dependent relationship with each other. In this way, sensors and devices in the SHS can build many-to-many co-dependent relationships. However, existing SHSs do not consider this co-dependent relationship and can not visualize the context of a user activity by observing the usage pattern of smart home entities. In short, sensors and devices in a SHS are configured as independent components, but in reality, they are function-wise co-dependent. Aegis considers these relations to build the context of the user activities in a SHS.

User activity-device correlation: In a SHS, different users utilize and control smart home devices in multiple ways. For instance, a user can set a security camera to take pictures whenever a motion is detected in the associated motion sensors. On the other hand, users control devices in multiple ways. For example, a user can unlock a door by using the smartphone app or entering the code manually. Here, the state of the lock can be determined by user activity on the smartphone or by using a presence sensor to detect the user near the smart lock. In short, by observing the user activities in a SHS, it is possible to determine the normal operation of smart home devices. One can define normal or malicious user behavior with the user activity-device correlation. Current SHS cannot correlate user activity and device actions correctly, which is considered as a feature in Aegis to differentiate benign and malicious activities.

Aegis Framework

There are three phases in 6thSense – data collection, data processing, and data analysis.

Data collection: In data collection phase, we collect data from different sensors over a certain period. We choose nine different sensors of smart devices which are enough to build a context-aware model of user activities. These are – accelerometer, gyroscope, light sensor, proximity sensor, GPS, audio sensor (microphone and speaker), camera, and headphone. We choose nine different user activity to collect the sensor data and build ground truth for proposed IDS framework. These user activities are given in the table.

Table: Typical Activities of Users on Smart Device

Data processing: After collecting sensor data for different user activity, we process the data to use these in the later phase. First, we remove missing data entries and clean the data. As different sensors have different frequencies, we have to sample the sensor data over a specific period. For 6thSense, we observe the change in the sensor condition in each second and from this per second change, 6thSense determines the activity of users. As our analytical model only take sensor condition (on/off) into account, we calculate the average of sensor data over one second and observe the change in sensor condition from the previous timestamp. If the sensor value is changing from the previous timestamp, we represent the sensor condition as 1 and 0 otherwise. These reorganized data then used in data analysis phase.

Data analysis: In data analysis phase, we use three different approaches (Markov Chain, Naïve Bayes, and Machine Learning Techniques) to analyze data from the previous phase. We use 75% of data for training purpose and rest of the data for testing purpose in 6thSense. Data used in training phase includes both benign and malicious activities. Test datasets are compared with the training model to distinguish malicious activities.

Figure: 6thSense Framework

Performance

We tested our framework against abovementioned threat model and conduct detail performance evaluation. Based on our test result, 6thSense achieves over 98% accuracy in all three detection approaches we adapted in this framework. Moreover, 6thSense introduces lower performance overhead (CPU and memory usage, battery usage, etc.) in smart devices.