THE PENNSYLVANIA STATE UNIVERSITY
THE GRADUATE SCHOOL
STATE ENDORSEMENT IN THE SMART HOME IOTIVITY FRAMEWORK
A Thesis in
Computer Science and Engineering
by
Kirti Jagtap
© 2020 Kirti Jagtap
Submitted in Partial Fulfillment of the Requirements for the Degree of
Master of Science
August 2020 The thesis of Kirti Jagtap was reviewed and approved by the following:
Trent Jaeger Professor of Computer Science and Engineering Thesis Advisor
Mahanth Gowda Assistant Professor of Computer Science and Engineering
Chitaranjan Das Distinguished Professor of Computer Science and Engineering Head of the Department of Computer Science and Engineering
ii Abstract
The increasing use of smart home devices has resulted in the emergence of software frameworks and automation platforms that provide scripts and Application Programming Interface (API) to develop different apps for these smart devices. Open-source platforms such as IoTivity make it easier to develop applications by providing Application Program- ming Interface. As the Internet of Things (IoT) and its applications in various domains have emerged only in the last few decades, the technology is relatively new; the developers are lacking experience and above all the complexity of Smart Home environment result in an increased number of bugs, security loopholes, and safety-critical issues leaving Smart Homes vulnerable to attacks. Since home automation is based on routines and triggers, using third-party applications or user-defined routines and custom automation [26] can lead to an unsafe and inconsistent home environment that is vulnerable to attacks thereby compromising user security and safety. These triggers and routines are dependent on the state of devices and the current home environment. Commonly used triggers for automation are user Home/Away mode, vacation mode, sleep mode. The complex environment makes it difficult to track different situations and make context-based decisions in Smart Homes. All the factors discussed above lead to inconsistent, vulnerable implementations and third-party apps with several security loopholes. I intend to provide a new approach to endorse a global state that enhances the security of the Smart Home. The main contribution would be the introduction of an endorsement framework in the Home Automation ecosystem that uses the information regarding relevant devices in the home network, builds policies, and endorses the global state change based on these policies. Each global state requires relevant device attribute values, an endorsement function, and a goal-based integrity lattice to endorse the global state change. This implementation supports a consistent global state based on the endorsement framework. Maintaining this global state will eliminate the problem of inconsistent implementation and context deficient partially designed policies thereby providing a foundation for a secure smart home.
iii Table of Contents
List of Figures vi
List of Tables viii
Acknowledgments ix
Chapter 1 Introduction 1
Chapter 2 Related Work 4
Chapter 3 Design 6 3.1 Open Connectivity Foundation (OCF) and IoTivity ...... 6 3.1.1 Open Connectivity Foundation (OCF) ...... 6 3.1.1.1 OCF Resource Model ...... 6 3.1.1.2 OCF Interaction Model ...... 7 3.1.1.3 OCF Roles ...... 7 3.1.2 IoTivity ...... 7 3.1.2.1 Functional Units ...... 7 3.1.2.2 IoTivity Resource API stack ...... 8 3.2 Overview ...... 10 3.3 Design Approach ...... 12 3.3.1 Ground-Truth Data Collection ...... 12 3.3.2 OCF Resources Collection ...... 12 3.3.3 Security Goal ...... 12 3.3.4 Integrity Lattice ...... 13 3.3.5 Global State for endorsement ...... 15 3.3.6 Policy Generation for Endorser ...... 16 3.3.6.1 Factors affecting Policies ...... 16 3.3.6.2 Policy Generation ...... 17
iv Chapter 4 Implementation 19 4.1 Global Home State in IoTivity ...... 19 4.2 Endorser Module and Global State Configuration ...... 19 4.3 Home/Away Mode in IoTivity ...... 20 4.4 Endorser Module ...... 21 4.4.1 Functions ...... 21 4.4.2 Procedure ...... 22 4.4.3 Client-Server Request Flow ...... 23 4.4.3.1 Sequence Flow: PUT request for global state server . . . 23 4.4.3.2 Sequence Flow: PUT request for other device resources . 24
Chapter 5 Results and Evaluation 25 5.1 Experimental setup ...... 25 5.1.1 Smart Home Simulation ...... 25 5.1.2 Global Home State ...... 27 5.1.3 Client Application ...... 27 5.1.4 Device Attribute Map ...... 28 5.1.5 Policies ...... 28 5.1.6 Attack Scenario and Threat Model ...... 28 5.1.7 Test Scenarios ...... 29 5.1.7.1 Scenario I ...... 29 5.1.7.2 Scenario II ...... 30 5.1.7.3 Scenario III ...... 30 5.1.7.4 Scenario IV ...... 30 5.1.8 Results ...... 31 5.1.8.1 Approved Request ...... 31 5.1.8.2 Rejected Request ...... 31 5.1.8.3 Scenario I ...... 32 5.1.8.4 Scenario II ...... 37 5.1.8.5 Scenario III ...... 37 5.1.8.6 Scenario IV ...... 38 5.2 Other Global States ...... 38 5.3 Challenges and Limitations ...... 40
Chapter 6 Conclusion 41
Appendix A OCF Device Type Overview 42
Appendix B Device-resource attribute pairs 51
v List of Figures
3.1 IoTivity Resource API Stack ...... 8
3.2 Server example for smart light ...... 9
3.3 Overview of the Smart Home with virtual resource implementation . . . 10
3.4 Building Blocks of Global Home State Server ...... 11
3.5 Integrity Lattice ...... 13
3.6 Device Attribute Pairs ...... 17
3.7 Selected Policies ...... 18
4.1 Building Blocks of Endorsement Framework ...... 20
4.2 Endorsement flow diagram ...... 22
4.3 Client-Server Request Flow ...... 23
4.4 Sequence Flow: PUT request for global state server ...... 23
4.5 Sequence Flow: PUT request for other device resources ...... 24
5.1 Home Simulation Environment Scenario ...... 25
5.2 Policies ...... 28
5.3 Sample Approved Request ...... 31
5.4 Sample Rejected Request ...... 31
vi 5.5 Door current state ...... 32
5.6 Security Panel current state ...... 33
5.7 Presence sensor current state ...... 34
5.8 Global State Server PUT request (REJECTED) ...... 34
5.9 Client application request response (REJECTED) ...... 35
5.10 Global State Server PUT request (APPROVED) ...... 36
5.11 Client application request response (APPROVED) ...... 37
vii List of Tables
3.1 Example of Device, Resource and Properties ...... 14
3.2 Factors affecting policies ...... 16
5.1 Security Panel ...... 26
5.2 Door ...... 26
5.3 Motion Sensor ...... 26
5.4 Thermostat ...... 27
5.5 Presense Sensor ...... 27
5.6 Global Home State ...... 27
5.7 Device Attribute Value Map ...... 28
5.8 Fire Alarm State ...... 38
5.9 Vacation Mode ...... 39
viii Acknowledgments
I express my sincere gratitude to Prof. Trent Jaeger for his continuous support, guidance, and motivation while working on the Master’s Thesis. I would also like to thank Dr. Adwait Nadkarni, Kaushal Kafle, and Mansoor Ahmed for their continued support and contribution. I would like to thank my family and friends for their support.
ix Chapter 1 | Introduction
A smart home is a home setup in which various appliances and devices are connected to the home network and can be controlled remotely using a mobile or other devices. It consists of different types of device categories such as lighting, space conditioning, infrastructure, appliances, and electronic devices [3]. These devices can be classified into two categories namely large devices (security panel, smart air conditioner, smart TV, etc.) and small devices (smart switch, smart plugs, sensors, actuators, etc.). Several software frameworks provide APIs to build applications to communicate, operate, and control these devices in Smart Home. The software applications build automation and scenes for different situations to make user life easier and comfortable along with improving the energy-efficiency of smart homes and also the security of physical environment. Automation can be as simple as “switch on the light when motion is sensed” or as complex and context-aware as “enable thermostat eco-temperatures, switch on the indoor camera and close the window when I leave home”. Situations are usually tracked and inferred by asking the user or through inference logic which can be different for different applications. Google Nest provides users with a Home/Away mode but this is not available for all devices. Unavailability of this feature across all devices in the smart home may give rise to inconsistent inference of home state and security flaws as there is no method to validate the state. Infrastructural devices such as doors, windows, locks, security panels and cameras are responsible for user privacy and security; unsupervised use of appliances like cooktop, oven, water heater, etc. can compromise user-safety. Hence maintaining a global home state is of paramount importance and endorsing global state changes in the platform framework is necessary. A recent research paper surveyed IFTTT (If This Then That) applets confirmed that Home/Away state change is among the top three triggers and notify, email, log are among top actions [2]. Very few Smart Home frameworks/apps provide Home/Away
1 mode with custom automations. Kaushal Kafle [9] argues that while widely available home automation platforms facilitate automation, they also expose security flaws affecting integrity of user’s physical environment. His research broadly categorized these platforms into API-based Smart Home Managers and Data Store-Based (DSB) Smart Home Platforms and carried out a systematic security analysis of some data store-based (DSB) smart home platforms namely Nest and Hue. This security analysis exposes the gaps in the security of home automation platforms which implement centralized data stores. The centralized data store meant to enhance communication among apps and devices via home state variable is also prone to situations where low-integrity devices/apps can indirectly modify the home state variable which both high and low-integrity devices/apps rely on. The research and its findings expressed the need of strong integrity guarantees of home state variables which reflect the state of the smart home in case of DSB platforms. Based on these recommendations, I have introduced an endorsement framework which relies on policy based mechanism to endorse the home state change and ensuring the integrity of the home state variable. According to Vitaly Shmatikov [2], existing IoT frameworks entangle access-control enforcement and situation tracking, resulting in over privileges along with redundant, inconsistent, and inflexible implementations. He proposed a component called environ- mental situation oracles (ESO) that track the home situation and act as a trusting base responsible for providing situational access control. As per this paper, the implementation relies on third party frameworks such as APIs of Google Nest, Smart Things etc to track situations and enforce access control policies. This approach however poses a limitation for devices which do not directly provide states such as Home/Away, Night mode etc. The proposed implementation on the other hand tries to work around this limitation by endorsing the global home state by querying multiple device attributes and applying suitable policies. Since our implementation uses multiple devices and their attributes to generate policies and validate global home state, it allows tolerance for certain device failures. This implementation differs from the ESO approach since ESOs can only track the situation but in this solution global state server along with endorser framework can track and endorse the global home state change. I decided to support the global home state through a virtual device in the Smart Home. It can be accessed and controlled by the client application and the endorser mechanism mediates operations for this global home state. The virtual device maintains a map of device attribute information in the home network. During the global home state
2 change request, the endorser mechanism will refer to this information map to approve or reject the request. Home Automation routines can be set based on this global state and will have a consistent implementation with an endorsement mechanism. I conducted an experiment using the endorsement framework in Smart Home Simula- tion by developing device servers and a simple client app using IoTivity. The thesis includes
• Implementation of Global Home State for IoTivity framework.
• Introduction of ground-truth based integrity lattice for policy generation.
• Endorsement framework for global home state change.
• Analysis of the global home state and endorser’s impact in Smart Home Environ- ment.
The rest of this thesis is organized as follows: Chapter II highlights previous work done by researchers in this domain. Chapter III gives a design overview of the endorsement framework. Chapter IV presents the detailed implementation of the concept in the IoTivity framework. I have presented the experimental setup, attack scenario evaluation, and results in section V and finally, section VI concludes the thesis.
3 Chapter 2 | Related Work
E. Fernandes [8] outlined several security flaws using code analysis of a large number of apps and device handlers that result in over-privileges in SmartApps. The paper also presented four attacks to exploit the design flaws: two of the four attacks were related to the situations in smart-home like vacation mode of the home and fake fire alarm which emphasize the importance of global states, and their state change endorsement to provide a strong guard for these global states. Various other research developed static analysis systems for validation of apps [25] and risk analysis in home automation [23]. Another research [36], has discussed other surfacing threat vector which consists of attacks that exploit the use of sensors in IoT devices. These attacks arise due to insufficient security measures to control the use of sensors by apps. The threat vector covers attacks such as denial-of-service (DoS), transfer of malware to a device, compromise the device by triggering a malicious activity and information leak. These emerging attacks emphasize on improving security measures for the sensors and the importance of endorsing global state changes that can be triggered using these sensors. Vitaly Shmatikov [2] has introduced a component called environmental situation oracles that tracks the situation and provides situational access control in Smart Homes. This solves the problem of over-privilege along with expensive, inaccurate, redundant and inconsistent implementation across different frameworks. The paper has also conducted IFTTT applets survey concluding that arrive and leave as top two triggers and notify, email and log as top three actions. Another study by Y. Ashibani [14] implemented contextual information and behavioral pattern-based access control in Smart Home. The relative location of devices, number of devices, and the structure of home make it difficult to build context-based access control in Smart Homes. A. Wang [11] pointed out some security loopholes in Away mode of smart plugs using statistical methods and emphasized on implementation of a stronger enforcement module
4 for Away mode in Smart Home. A study recently published [9] outlines security flaws in Smart Home platforms and its implications on the Smart Home environment. These security flaws jeopardize the security of users and highlight the importance of enforcing security in emerging home automation platforms. Other research work also includes machine learning, decision models, and predictive analytics approaches for situational awareness, anomaly or malicious behavior detection and analysis using these approaches [12,13,17,20]. Recent research introduced various systems that are based on context and policy- based enforcement in Smart Home like IoTGuard [16], ContexIoT [17], Aegis [21, 22] using context-based permission systems providing contextual integrity and performing effective access control. Some papers also introduced middleware for context-awareness and context sharing to overcome common problems such as redundancy, inconsistency, and inaccuracy in SmartHomes [2,18]. I propose an approach for the stronger security of Smart Home by providing shared global states and endorsement mechanism to guard these state changes and preventing automations based on these states. The shared global state is accessible to smart apps allowing a more consistent home state and defense against manipulative attackers using an endorsement framework. The concept of ground-truth based policies is also introduced in this work for stronger endorsement of global state change.
5 Chapter 3 | Design
3.1 Open Connectivity Foundation (OCF) and IoTivity
3.1.1 Open Connectivity Foundation (OCF)
The Open Connectivity Foundation (OCF) is an organization that develops standards for Internet of Things (IoT). It ensures secure interoperability for consumers, businesses and industries by delivering a standard communications platform. It also provides an open source implementation for seamless device-to-device connectivity and a certification program [37]. IoTivity is an open source implementation by OCF which provides framework and development tools that enable manufacturers and developers to create a connected ecosystem.
3.1.1.1 OCF Resource Model
Physical world entities such as motion sensor, smart devices are represented as Resources in OCF Model. Interactions with an entity are achieved using operations based on Representational State Transfer (REST) architecture. The entities are accessed using unique resource identifiers (URIs) and they support RESTful operations on their resources. In IoTivity Framework, the notion of the Client and Server is realized through roles. A Device can act as a Client and initiate a RESTful operation on other devices acting as a Server. An OCF Server contains one or more Resources to describe a real world entity. Each Resource contains properties that describes an aspect that is exposed through a Resource.
6 3.1.1.2 OCF Interaction Model
CREATE, RETRIEVE, UPDATE, DELETE, and NOTIFY (CRUDN) are operations defined for interacting with the Resources.
The following operations were used to interact with the resources:
• RETRIEVE (GET Request in IoTivity): Get the current state of a resource from a Device Server
• UPDATE (PUT Request in IoTivity): Update the information stored in a Resource
• NOTIFY(OBSERVE Request in IoTivity): Request asynchronous notifica- tion of resource state change.
There are several parameters passed as a part of the CRUDN messages which include, the source of the request, the URI of the resource, request unique identifier, request type, response code and content specific to the request [5].
3.1.1.3 OCF Roles
OCF Architecture defines 2 logical roles for a device:
• OCF Device Server : A logical entity, which exposes hosted resources, is discoverable, and responds to client initiated transactions
• OCF Client Application : A logical entity that runs on a smart phone and interacts with resources on an OCF Server via discovery and CRUDN actions
3.1.2 IoTivity
IoTivity provides an open source implementation of OCF standard specification. OCF developer tools provide product development engineers methods to adopt IoTivity and OCF.
3.1.2.1 Functional Units
The framework has following functions [38]:
7 • Device and Resource Discovery: IoTivity supports multiple discovery mecha- nisms for devices and resources in the network.
• Data Communication: IoTivity supports interactions with the device and re- sources using REST API.
• Device management: IoTivity supports diagnostics along with provisioning and configuration of devices.
3.1.2.2 IoTivity Resource API stack
Figure 3.1: IoTivity Resource API Stack Note: adapted from IoTivity [28] (accessed on May 6th, 2020) now updated to IoTivity-lite architecture.
IoTivity, an open-source implementation of the OCF Core Framework, is easy to use and provides C and C++ SDK for developing applications on devices. The API stack consists of 5 layers. On the other hand, the IoTivity-Lite, a light-weight implementation of the OCF specification, consists only of 4 layers. IoTivity is a resource stack coded in C and C++ whereas IoTivity-lite is coded in pure C code.
8 The main functionalities [30] provided by IoTivity are:
1. Resource Registration
2. Device and Resource Discovery
3. Resource Requests
(a) GET Resource State (b) PUT Resource State (c) OBSERVE Resource State
IoTivity is based on the REST architecture hence all the requests and communication are done using REST API. The APIs perform different functions such as resource dis- covery, querying resource state (GET, PUT, OBSERVE) for OCF clients, and resource registration for OCF server. Changes were made to IoTivity stack to support global home state and the endorsement of this global home state.
Simple example of client-server architecture for smart light
Figure 3.2: Server example for smart light Source: Open Connectivity Architecture [29]
9 3.2 Overview
Figure 3.3: Overview of the Smart Home with virtual resource implementation
The main objective of this experiment is to maintain global home state and endorse state change requests made to the global home state. The framework is divided into two components. The first component acts as a monitoring component and maintains a global home state accessible to the user requests such as PUT, GET and OBSERVE. The second component acting as a controller is the endorsement mechanism which mediates requests made to this global home state. For the endorser mechanism to approve or reject the changes to the global home state, it requires additional information regarding relevant devices. Each device attribute has read-only and read-write access modes. For this thesis, I have developed an endorsement mechanism for the IoTivity framework version 2.0.1. I have shortlisted read-only and read-write attributes for OCF devices using the OCF Specification Document (Appendix A, B) [3,4]. This collection can be used for endorsing the global home state change. For implementation purposes, I have constructed a global home state server with only one attribute Home State of type Boolean; FALSE denoting user is Away, and TRUE indicating user is Home.
10 Figure 3.4: Building Blocks of Global Home State Server
This global home state server has two functions:
• Monitor: Observe state changes of all relevant devices-attributes in the smart-home and keep Device-attribute value map up to date
• Controller: Mediate and respond to the change requests made to its Home State attribute.
The endorser mechanism is invoked whenever a change of state request is made to the global home state. This functionality uses the Device-attribute value map, constructs the policies and makes decisions to approve or reject the global state change. On approval, the state is changed and the response is sent to the client. If the state change is rejected, the client is notified with reasons for rejecting the state change.
11 3.3 Design Approach
3.3.1 Ground-Truth Data Collection
The endorsement framework’s primary objective is to endorse the global home state change but to be able to do that effectively, it requires ground truth data which is a set of relevant device-attribute pairs. With the help of this ground truth i.e. device-attribute pairs, the endorser can APPROVE or REJECT the global state change request.
3.3.2 OCF Resources Collection
The Open Connectivity Foundation(OCF) provides a standard communications platform for devices to communicate regardless of user transport technologies, service providers, underlying operating systems and device form factor. The specification entails definitions of various device types and resources associated with these device types. There are around 85 resources currently available in the OCF specifications, each with a set of attributes, either read-only or read-write. From these specifications, I have shortlisted 104 device-attribute combinations. Of these device-attribute combinations, 42 are read- only and 62 are read-write. (Refer Appendix B for the list of device-resource attribute pairs) [3,4]
3.3.3 Security Goal
The endorsement framework was conceived with a security goal of “Detecting and Preventing Home Intrusion”. This security goal is the basis to identify relevant devices such as security panels, motion sensors, cameras, and door locks and to select the device- attribute pairs necessary to define ground truth and policies for endorsement framework. To fulfill the security goal, I referred various devices and their attributes which can help determine whether a user is home or away, for example, door lock, security panel, sensors, etc can help to determine the user’s presence at home.
12 3.3.4 Integrity Lattice
Integrity Lattice used by the endorser is divided into three levels. The first level which is of the highest integrity contains all device-attribute pairs(direct observations), the second level is for the trusted applications which interact with the devices namely OCF client application and the lowest level is for untrusted third party applications. I have developed integrity lattice for our example Global Home State (Home/Away). The following figure illustrates the same.
Figure 3.5: Integrity Lattice
13 The integrity lattice shown above is specific to our security goal. The highest level includes the device attribute pairs specific and contributing to our security goal. The resource is any entity of device which can be requested or controlled. Attribute can be either metadata which is read-only or non-meta data which can be read-only or read-write. Some metadata attributes are id, interface, resource type. Each device can have multiple resources and each resource can have multiple attributes.
For example,
Table 3.1: Example of Device, Resource and Properties
Device: Door
Required and Recommended Resources: open level, door, lock sta- tus.
Resource Attributes
open level open level: open percentage of entities like door, window, blind.
range: lower and upper bound usually 0-100 (0 = closed 100 =open)
step: increment between values
door Open State: open/closed
Open Duration: time for which door is open
Open Alarm: whether open alarm is active or not
lock status Lock State: locked/unlocked
Source: OCF Specification 2.1.2 Device and Resource Specification [3, 4]
14 3.3.5 Global State for endorsement
The endorsement framework must endorse global state change, provide strong integrity and prevent tampering by untrusted third party applications.
The following example demonstrates this requirement.
Consider the automation:
“When a user is home, turn off the security camera.”
This automation is meant to ensure that the user is not being recorded when the user is home. If an untrusted application gains access to the global state Home/Away then it can modify the state and allow the intruder to switch the camera on, even though the user is physically at home. This violates the automation which the user had initially desired. Alternatively, a burglar can modify the Home/Away state to disable the camera and break into the house without the fear of being recorded.
The device-attribute pairs will help us set the global state whose existing value as well as changes will help us answer questions that are fundamental to our security goal “Detecting and Preventing Home Intrusion”. The goal of the endorser mechanism is to guard against the misuse of automation by protecting the home state.
15 3.3.6 Policy Generation for Endorser
3.3.6.1 Factors affecting Policies
Stronger endorsement requires situational knowledge along with relevant device-attribute pairs.
Situational knowledge would require answers to the following questions.
Table 3.2: Factors affecting policies
Location How are the devices situated in relation to one another? If all security-related devices are near main entrance or away from it?
Sequence What is the order of checking the device status?
Operational Are the devices active during endorsement? status
These three factors are important for policy generation and endorsement implementa- tion. IoTivity does not have a location attribute for the devices which compelled us to exclude this factor from the policy template.
16 3.3.6.2 Policy Generation
I have generated all possible combinations of device-attribute pairs from a set of selected device-attribute pairs and formed policies based on the relevant device-attribute pairs to endorse home/away global state change.
Figure 3.6: Device Attribute Pairs
Above is an exhaustive list of all device-attribute pair combinations. However many of these are invalid and irrelevant. So out of these only relevant pairs which contribute to the global state will be selected.
The endorser mechanism relies on a set of policies and integrity lattice to endorse global state change from one global state to another global state.
17 For example : Home->Away or Away->Home.
Policies are a set of attribute-value pairs which allow the endorser framework to infer the global state. While endorsing a state change, defined policies are taken into consider- ation to infer the global state and then endorse the global state change accordingly by the endorser framework. While endorsing this global state change the integrity lattice will be used to decide whether to honour the request or reject it depending on the source where it originated from. It could be one of the device servers which commands the highest integrity value in the integrity lattice, trusted applications which are at the next level of integrity or third party untrusted applications at the lowest level for which the global state change requests will be rejected.
Figure 3.7: Selected Policies
Once it is verified that the global state change request has come from trusted source then the endorser will validate the change request with the generated policies and accordingly the change request will be approved or rejected. If none of the policies could be validated the request is rejected automatically.
18 Chapter 4 | Implementation
4.1 Global Home State in IoTivity
I have created a Home/Away resource that can be viewed and controlled by client applications. It has an attribute with two possible values TRUE or FALSE wherein TRUE indicates Home state and FALSE denotes Away. I have utilized this Home/Away resource to represent the global home state. This resource supports requests such as GET to retrieve the global state, PUT to update the global state, and OBSERVE to generate asynchronous notifications on global state change.
4.2 Endorser Module and Global State Configuration
I have used IoTivity APIs to create a global state resource that acts as both client and server. I have also written an Entity handler for this global state. This global state is configured during client application configuration.
19 Figure 4.1: Building Blocks of Endorsement Framework
4.3 Home/Away Mode in IoTivity
This keeps the current value of device attributes in the Smart Home network. This map helps the endorser module to make a decision whether to APPROVE or REJECT the global state change requests.
For example:
Mode Away
door.lockState : locked
door.openLevel : closed
securitypanel.mode : armed
sensor.presence : false
sensor.motion : false
20 Mode Home
door.lockState : unlocked
door.openLevel : closed
securitypanel.mode : disarmed
sensor.presence : true
sensor.motion : true
4.4 Endorser Module
The endorser module handles endorsement functionality. I have placed an endorser module in IoTivity Base SDK (C++).
4.4.1 Functions
The global state server keeps the current value of device attributes in the Smart Home network. The current values of device attributes help the endorser module to make a decision whether to APPROVE or REJECT the global state change requests.
1. generate_policies: It generates policies based on the current device attribute map. The policies are generated at run-time based on the available devices. Each user will have a different combination of devices which would affect the policies accordingly. 2. endorser_check: It loads the current policy and matches the current state of the devices in the Device attribute map for each device-attribute in the policy. If all of them match, returns TRUE to approve otherwise returns FALSE to reject the state change request with the reason for denial.
21 Figure 4.2: Endorsement flow diagram
The endorser module which is placed in IoTivity base code is utilized only for shared global state since this implementation is targeted only at endorsing global state change requests.
4.4.2 Procedure
• When a PUT request is received by the server, the server checks its resource type. If the resource type is oic.r.globalstate the endorser module is invoked
• If the endorsement method endorser_check() returns TRUE, the state change is endorsed and the request is further processed. If it returns FALSE, the state change is rejected and the error reason string is appended to payload.
22 4.4.3 Client-Server Request Flow
Figure 4.3: Client-Server Request Flow
4.4.3.1 Sequence Flow: PUT request for global state server
Following is the sequence diagram for setting a global state with an endorser mechanism.
Figure 4.4: Sequence Flow: PUT request for global state server
23 4.4.3.2 Sequence Flow: PUT request for other device resources
Figure 4.5: Sequence Flow: PUT request for other device resources Note: The diagram is adapted from the sequence diagram of setting resource state in IoTivity (unavailable now) [32]
24 Chapter 5 | Results and Evaluation
5.1 Experimental setup
5.1.1 Smart Home Simulation
Figure 5.1: Home Simulation Environment Scenario
25 I have created a simulation of the Smart Home environment using a modified IoTivity framework encompassing the implementation of the endorser framework along with global home state. This Simulation of Smart Home environment using IoTivity implementation consisted of basic device server applications that use IoTivity APIs for resource registra- tion functionality and entity handlers to process requests made to these device server applications. For this simulated environment, I have used the following
Security Panel
Table 5.1: Security Panel
Device Security Panel Type oic.d.securitypanel Resource oic.r.mode Attribute mode Supported values disarmed | armed
Door
Table 5.2: Door
Device Door Type oic.d.door Resource oic.r.openlevel, oic.r.door, oic.r.lock.status Attribute openLevel, openState, lockState
Motion Sensor
Table 5.3: Motion Sensor
Device Motion Sensor Type oic.r.sensor.motion Attribute value Supported Values True | False
26 Thermostat Table 5.4: Thermostat
Device Thermostat Type oic.r.thermostat(sensor), oic.r.thermostat(actuator) Attribute temperature
Presence Sensor Table 5.5: Presense Sensor
Device Presence Sensor Type oic.r.sensor.presence Attribute value Supported Values True | False
5.1.2 Global Home State
I have used IoTivity APIs to create a global home state resource that acts as both client and server. This global state is configured during client application configuration. I have used APIs to code client component for this global state which discovers resources and sends OBSERVE requests to resources relevant to the global state change endorsement.
Table 5.6: Global Home State
Device Home State Type oic.r.globalstate Attribute value Supported Values True | False
5.1.3 Client Application
I have created a simple client application which when initialized discovers devices. It supports PUT requests to different device servers to change their states and a PUT
27 request to Global State Server to modify the global home state.
5.1.4 Device Attribute Map
A device attribute map that stores the following information is created and maintained by Virtual Server.
Table 5.7: Device Attribute Value Map
Device Stores the device identifier and type of the device. Attribute Stores the attribute of the device Value Stores the value of the device attribute Time It stores the timing information for the state change notification
5.1.5 Policies
The below policies are generated when presence sensor, door and security panel are active.
Figure 5.2: Policies
5.1.6 Attack Scenario and Threat Model
The proposed global state server is mandated to maintain global home state but it does not fully preclude interactions from other entities in the smart home such as device servers, client application and untrusted third party applications. In such a setup, these available communication interfaces allow scope for attacks rendering global state susceptible to
28 unintended change leading to undesired automations, intrusions and unsafe physical environment.
If a third-party app directly requests a global state server to change global home state, corresponding automations would not be prevented and may jeopardise the physical security of the home environment. For example, if an untrusted application gains access to global state Home/Away, then it can modify the state and thereby allow the intruder to switch the camera on, even though the user is physically at home violating the automation. Or even worse, an intruder can tamper the global home state, the camera will be switched off through automation, allowing the intruder to break in without being recorded.
In the smart home setup, the device servers are high up in the integrity lattice and the requests from any device server are honoured by the global state server and consequently by endorser. If a malicious device server that happens to be a part of a home network, requests a global home state change then the integrity of the global home state will be jeopardized, leading an inconsistent home environment.
The endorser framework’s state change endorsement creates policies that depend upon the values of relevant device attributes. If one or more of these devices are compromised and global home state change is triggered then the endorser may allow the global state change, thereby, allowing intruder with malicious intent to use automation to his advantage.
5.1.7 Test Scenarios
I have tested this framework for following attack scenarios.
5.1.7.1 Scenario I
Automations and predefined routines: I have used a user-defined routine to set global Home state to Home at a particular time to mimic a scenario where the user would use custom automation or define a routine in real life. When this routine is triggered, it
29 will send a PUT request to the global home state server to change the state to Home. Depending on Device-Attribute map, the request will be either approved or rejected.
5.1.7.2 Scenario II
Bugs or malicious client app: I have induced a bug in the client app which sends PUT requests to the global home state server to update the state every time the door is opened and closed. Depending on Device-Attribute map, the endorser module is expected to either approve or reject the request.
5.1.7.3 Scenario III
Handle Device failures: The policies are based on device attribute values and in case if a device fails to respond or notify the state, the endorser module has to handle such scenarios. In this test scenario, I have randomly stopped device servers and observed if the endorser module regenerates policies to handle this failure.
5.1.7.4 Scenario IV
Handle all device failures: There are no Device-Attribute values to regenerate the policy due to failure of all devices which were part of the Smart Home. In such a case, the endorser should flag this situation and reject the PUT requests to the global home state server.
30 5.1.8 Results
5.1.8.1 Approved Request
Figure 5.3: Sample Approved Request
5.1.8.2 Rejected Request
Figure 5.4: Sample Rejected Request
31 5.1.8.3 Scenario I
Door
Following is the output of the interaction of the door server with global state server and client application. The first request received in this scenario is the OBSERVE request from global state server and the door server responds with success response code. The subsequent two requests are GET request to which the server responds with the current door state. The next PUT request from trusted client application is processed and observers are notified of the change in the state. The observer in this case is the global state server which was set during the first request.
Figure 5.5: Door current state
Security Panel
Following is the output of the interaction of the security panel server with global state server and client application. The first request received in this scenario is the OBSERVE request from global state server and the security panel server responds with success response code. The subsequent two requests are GET request to which the server responds with the current security panel mode. The next PUT request from trusted
32 client application is processed and observers are notified of the change in the state. The observer in this case is the global state server which was set during the first request.
Figure 5.6: Security Panel current state
Presence Sensor
Following is the output of the interaction of the presence sensor server with global state server and client application. The first request received in this scenario is the OBSERVE request from global state server and the security panel server responds with success response code. The subsequent two requests are GET request to which the server responds with the current state of the presence sensor. The next two are notification response sent from presence sensor server to the global state server upon the change in state of the presence sensor.
33 Figure 5.7: Presence sensor current state
Global State Server
Figure 5.8: Global State Server PUT request (REJECTED)
34 The above screenshot represents sample global state server output. In this scenario, the application has sent a request to change the state from Away to Home. The endorser module is invoked as the request is made to the global state. It retrieves the Device attribute map, performs a check, and disapproves the request, keeping the state as Home.
Sample Client application request
Figure 5.9: Client application request response (REJECTED)
The client app gets an acknowledgement with the reasons for denial of state change.
35 Global State Server
Figure 5.10: Global State Server PUT request (APPROVED)
The above screenshot represents sample global state server output. In this scenario, the application has sent a request to change the state from Away to Home
The endorser module is invoked as the request is made to the global state. It retrieves the Device attribute map, performs a check, and approves the request, changing the state as Away.
36 Sample Client application request
Figure 5.11: Client application request response (APPROVED)
The client app gets an acknowledgment of the success return code.
5.1.8.4 Scenario II
To simulate a condition of user arriving home and user leaving home, I created a trigger to open and close door at a specific time intervals. An automation was set on door close to change the global home state. In this testing, the endorser framework correctly enforced the policy and rejected the requests since there was no corresponding change in the other relevant device attributes from the policy.
5.1.8.5 Scenario III
For testing this scenario, I stopped the device server of the presence sensor and security panel in consecutive tests. In both these simulations, the endorser framework correctly
37 regenerated the policies excluding the attributes of the unavailable devices, enforced those regenerated policies and processed the global home state change request successfully.
5.1.8.6 Scenario IV
For testing this scenario, I stopped all the device servers of the door, presence sensor and security panel simultaneously. In this simulation, the endorser framework failed to generate policies due to unavailability of devices and rejected all the global home state PUT requests.
5.2 Other Global States
The Global State Server along with the endorsement framework endorses global state Home/Away. However, the same approach and components can support endorsement of other global states such as User Vacation mode, Fire Alarm State, etc. Just like the Home/Away state, which is endorsed through a combination of multiple device-attribute pairs, these additional global states would also be inferred using a similar approach. Details of these global states and their relevant device-attribute pairs are as follows.
FIRE ALARM STATE
Table 5.8: Fire Alarm State
Device and Strong Description observations inference? Smoke Detector Yes Smoke detected by smoke sensor Air Quality Monitor No It reports any air quality issue, may not be always fire Temperature and No Temperature beyond threshold Humidity sensor
For inferring, if there is fire in the house through the endorsement of a global state, smoke detector can be used in conjunction with air quality monitor, temperature and
38 humidity sensor. However, in case of air quality monitor and temperature and humidity sensor, the inference is not as strong as the one for smoke detector, meaning even if the air quality monitor or humidity sensor gave an indication pertaining to a fire like situation, the endorser can’t be 100% sure to endorse this global state. On the other hand, the smoke detector offers a stronger inference allowing the endorsement of global state FIRE more reliably. In such safety-critical cases, the state change should be allowed while notifying the user.
USER VACATION MODE
Table 5.9: Vacation Mode
Device and Strong Description observations inference? Energy Consumption No If energy consumption is constantly lower than normal Mode set by user Yes The user can set the mode to vacation Mode set by user Yes The user can set the mode to away and it hasn’t changed for days Other Devices No Devices such as speaker, voice assistants, cof- feemaker, microwave, cooktop, washing ma- chine etc. are ideal/off for days
To endorse state change for Home/Vacation global state for the user home environment, the endorser can use a security panel, energy consumption meter along with other devices such as speakers, voice assistants, microwave, cooktop, washing machine etc. Users can explicitly set the mode to vacation or the endorser can endorse this state change similar to Home/Away. Similarly, if devices such as such speakers, voice assistants, coffeemaker, microwave, cooktop, washing machine etc have not been used for a number of days, then the endorser could infer that the user is on vacation. The energy consumption state referring to energy consumption being lower than normal also has a weaker inference to this global state.
Along with these, the global state server can also support global states such as sleep/awake mode, water leak detect, air quality(compromised/safe).
39 5.3 Challenges and Limitations
• The above experimentation has a challenge such as the inclusion of device location in the policy as the device location information is not available in the framework.
• The number of devices of the same type pose a challenge when there is an observation conflict between these devices making it difficult to implement policies. This is a side effect of the unavailability of the location parameter.
• IoTivity does not have an open-source client application for users. It’s a toolkit for developers and vendors which makes it challenging to deploy and test the global state server.
• IoTivity did not have a central data repository for device and state information which mandated the development of this functionality in the virtual server to collect and store this information for endorsement of global home state change.
• Given the above limitations, creating a simulated Smart Home environment for testing in IoTivity becomes challenging.
Additional Notes
• The experiments and implementation are done in IoTivity v2.0.1 which is currently not maintained. The resource stack of the latest version of IoTivity (IoTivity-lite 2.1.2) is different from the version (IoTivity 2.0.1) used in this experiment.
• The experiment was conducted using server applications for simulated devices so real devices may affect the execution of the modules.
40 Chapter 6 | Conclusion
In this thesis, I have proposed an endorsement framework for the global home state in the smart home environment. The proposed framework has monitoring component responsible for maintaining the device-attribute value map and endorser(mediation) module for approval and rejection of requests made to the global home state. Some frameworks with centralized engine and data stores will have an inbuilt monitoring which requires only a mediation module. However for IoTivity, I had to develop both functionalities. The data collected from the devices enables the framework to make reliable endorsement decisions. However, user feedback and input regarding the inclusion of devices in the policy generation and ranking could make the policies more user-friendly and improve the endorser mechanism.
The results of these experiments show that using the global home state, the endorser mechanism can make effective use of the device data, remove inconsistency and add extra security in Smart Homes. In this study, I have made some assumptions to keep the scope of framework manageable. However, in real-world applications, some of these assumptions may not directly apply. The performance and efficiency may be affected depending on the devices, the complexity of the environment, and communication overhead. This experiment was done in a simulated environment with different scenarios but may work differently in real life.
41 Appendix A| OCF Device Type Overview
Device Type Required Resource types Recommended Resource Types oic.d.3dprinter oic.r.switch.binary, oic.r.alertcollection, oic.r.printer.3d, oic.r.consumablecollection oic.r.operational.state, oic.r.temperature, oic.r.printer.queue oic.d.speaker oic.r.switch.binary, oic.r.media.input oic.r.audio oic.d.airconditioner oic.r.switch.binary, oic.r.airflowcontrol, oic.r.temperature oic.r.alertcollection, oic.r.consumable, oic.r.ecomode, oic.r.energy.consumption, oic.r.energy.usage, oic.r.humidity, oic.r.mode, oic.r.temperature, oic.r.time.period
42 Device Type Required Resource types Recommended Resource Types oic.d.airpurifier oic.r.switch.binary oic.r.Airflow, oic.r.airqualitycollection, oic.r.alertcollection, oic.r.energy.consumption, oic.r.energy.usage, oic.r.mode, oic.r.time.period oic.d.airqualitymonitor oic.r.airqualitycollection oic.r.alertcollection, oic.r.switch.binary, oic.r.energy.consumption, oic.r.energy.usage oic.d.battery oic.r.energy.battery oic.r.batterymaterial oic.d.blind oic.r.openlevel oic.r.alertcollection, oic.r.windowcovering oic.d.bridge oic.r.vodlist oic.d.camera oic.r.media oic.r.autofocus, oic.r.colour.autowhitebalance, oic.r.light.brightness, oic.r.nightmode, oic.r.ptz oic.d.washerdryer oic.r.switch.binary, oic.r.alertcollection, oic.r.operational.state oic.r.energy.drlc, oic.r.ecomode, oic.r.energy.consumption, oic.r.energy.usage, oic.r.mode, oic.r.temperature, oic.r.temperature, oic.r.sensor.water
43 Device Type Required Resource types Recommended Resource Types oic.d.coffeemachine oic.r.switch.binary, oic.r.alertcollection, oic.r.operational.state oic.r.brewing, oic.r.clock, oic.r.foaming, oic.r.grinder, oic.r.temperature, oic.r.temperature oic.d.cookerhood oic.r.airflowcontrol, oic.r.alertcollection, oic.r.switch.binary, oic.r.energy.consumption, oic.r.mode oic.r.energy.usage oic.d.cooktop oic.r.heatingzonecollection oic.r.alertcollection, oic.r.energy.consumption, oic.r.energy.usage, oic.r.time.period, oic.r.sensor.water oic.d.dehumidifier oic.r.switch.binary, oic.r.alertcollection, oic.r.humidity oic.r.airqualitycollection, oic.r.consumable, oic.r.energy.consumption, oic.r.energy.usage oic.d.dishwasher oic.r.switch.binary, oic.r.alertcollection, oic.r.mode oic.r.energy.drlc, oic.r.door, oic.r.energy.consumption, oic.r.energy.usage, oic.r.operational.state, oic.r.time.period, oic.r.sensor.water
44 Device Type Required Resource types Recommended Resource Types oic.d.door oic.r.openlevel oic.r.sensor.contact, oic.r.door, oic.r.lock.code, oic.r.lock.status oic.d.dryer oic.r.switch.binary, oic.r.alertcollection, oic.r.operational.state oic.r.energy.drlc, oic.r.ecomode, oic.r.energy.consumption, oic.r.energy.usage, oic.r.time.period oic.d.electricmeter oic.r.energy.consumption oic.r.energy.usage oic.d.electricvehiclechargeroic.r.switch.binary, oic.r.alertcollection, oic.r.operational.state, oic.r.energy.drlc, oic.r.energy.battery, oic.r.energy.consumption, oic.r.vehicle.connector oic.r.energy.usage, oic.r.time.period oic.d.energygenerator oic.r.energy.generation oic.r.energy.overload, oic.r.temperature oic.d.energymonitor oic.r..consumption oic.d.fan oic.r.switch.binary oic.r.airflowcontrol, oic.r.ptz oic.d.foodprobe oic.r.temperature
45 Device Type Required Resource types Recommended Resource Types oic.d.freezer oic.r.temperature, oic.r.alertcollection, oic.r.temperature oic.r.delaydefrost, oic.r.door, oic.r.energy.consumption, oic.r.energy.usage, oic.r.humidity, oic.r.icemaker, oic.r.refrigeration oic.d.garagedoor oic.r.door oic.r.alertcollection, oic.r.openlevel oic.d.sensor oic.r.
46 Device Type Required Resource types Recommended Resource Types oic.d.light oic.r.switch.binary oic.r.colour.hs, oic.r.colour.csc, oic.r.colour.colourtemperature, oic.r.light.dimming, oic.r.light.ramptime oic.d.mattress oic.r.switch.binary, oic.r.sensor.sleep, oic.r.mode oic.r.movement.linear oic.d.oven oic.r.switch.binary, oic.r.alertcollection, oic.r.temperature, oic.r.clock, oic.r.temperature oic.r.energy.consumption, oic.r.energy.usage, oic.r.humidity, oic.r.mode, oic.r.operational.state, oic.r.time.period oic.d.printer oic.r.switch.binary, oic.r.alertcollection, oic.r.operational.state oic.r.automaticdocumentfeeder, oic.r.consumablecollection, oic.r.printer.queue oic.d.multifunctionprinteroic.r.automaticdocumentfeeder, oic.r.alertcollection, oic.r.switch.binary, oic.r.consumablecollection, oic.r.operational.state, oic.r.printer.queue oic.r.operational.state oic.d.receiver oic.r.switch.binary, oic.r.clock, oic.r.audio, oic.r.media oic.r.media.input, oic.r.media.output
47 Device Type Required Resource types Recommended Resource Types oic.d.refrigerator oic.r.temperature, oic.r.alertcollection, oic.r.temperature oic.r.audio, oic.r.consumable, oic.r.delaydefrost, oic.r.energy.drlc, oic.r.door, oic.r.ecomode, oic.r.energy.consumption, oic.r.energy.usage, oic.r.humidity, oic.r.icemaker, oic.r.refrigeration oic.d.robotcleaner oic.r.switch.binary, oic.r.alertcollection, oic.r.mode oic.r.energy.battery, oic.r.clock, oic.r.consumable, oic.r.energy.drlc, oic.r.energy.consumption, oic.r.energy.usage, oic.r.operational.state, oic.r.time.period oic.d.scanner oic.r.switch.binary, oic.r.operational.state, oic.r.automaticdocumentfeeder oic.d.securitypanel oic.r.mode oic.r.alertcollection, oic.r.clock, oic.r.iaszone oic.d.stb oic.r.switch.binary oic.r.energy.consumption, oic.r.energy.usage, oic.r.media.input, oic.r.media.output
48 Device Type Required Resource types Recommended Resource Types oic.d.smartlock oic.r.lock.status oic.r.lock.code oic.d.smartplug oic.r.switch.binary oic.r.energy.consumption, oic.r.energy.usage, oic.r.time.period oic.d.steamcloset oic.r.operational.state, oic.r.alertcollection, oic.r.time.period oic.r.energy.consumption, oic.r.energy.usage, oic.r.humidity, oic.r.mode oic.d.switch oic.r.switch.binary oic.r.light.dimming oic.d.tv oic.r.switch.binary, oic.r.alertcollection, oic.r.audio, oic.r.light.brightness, oic.r.media.input oic.r.clock, oic.r.ecomode, oic.r.energy.consumption, oic.r.energy.usage, oic.r.meda.output, oic.r.time.period oic.d.thermostat oic.r.temperature(sensor), oic.r.airflowcontrol, oic.r.temperature(actuator) oic.r.alertcollection, oic.r.energy.battery, oic.r.switch.binary, oic.r.clock, oic.r.ecomode, oic.r.humidity, oic.r.mode, oic.r.operational.state, oic.r.sensor.presence oic.d.virtual
49 Device Type Required Resource types Recommended Resource Types oic.d.washer oic.r.switch.binary, oic.r.alertcollection, oic.r.operational.state oic.r.energy.drlc, oic.r.ecomode, oic.r.energy.consumption, oic.r.energy.usage, oic.r.mode, oic.r.temperature, oic.r.temperature, oic.r.time.period, oic.r.sensor.water oic.d.waterheater oic.r.switch.binary, oic.r.alertcollection, oic.r.temperature, oic.r.energy.drlc, oic.r.temperature oic.r.energy.consumption, oic.r.energy.usage, oic.r.sensor.water oic.d.waterpurifier oic.r.operational.state, oic.r.alertcollection, oic.r.waterinfo oic.r.consumable, oic.r.energy.consumption, oic.r.energy.usage oic.d.watervalve oic.r.openlevel oic.d.window oic.r.openlevel oic.r.sensor.contact, oic.r.sensor.glassbreak, oic.r.lock.status
source: OCF Device Type overview [27]
50 Appendix B| Device-resource attribute pairs
Device Name Required Resource types Attributes Access Mode
Door oic.r.openlevel openLevel Read Write
Security Panel oic.r.mode modes Read Write
Security Panel oic.r.mode supportedModes Read Only
Thermostat oic.r.temperature temperature Read Write
Window oic.r.openlevel openLevel Read Write
Motion Sensor oic.r.sensor.motion value Read Only
Presence Sensor oic.r.sensor.presence value Read Only
Garage Door oic.r.door openState Read Only
Contact Sensor oic.r.sensor.contact value Read Only
Touch Sensor oic.r.sensor.touch value Read Only
Smart Lock oic.r.lock.status lockState Read Write
Active Speaker oic.r.switch.binary value Read Write
51 Device Name Required Resource types Attributes Access Mode
Active Speaker oic.r.audio mute Read Write
Active Speaker oic.r.audio volume Read Write
Air Conditioner oic.r.switch.binary value Read Write
Air Conditioner oic.r.temperature temperature Read Write
Coffee Machine oic.r.switch.binary value Read Write
Coffee Machine oic.r.operational.state currentMachineState Read Write
Coffee Machine oic.r.operational.state machineStates Read Only
Cooker Hood oic.r.airflowcontrol speed Read Write
Cooker Hood oic.r.switch.binary value Read Write
Cooker Hood oic.r.mode modes Read Write
Cooker Hood oic.r.mode supportedModes Read Only
Cooktop oic.r.heatingzone heatinglevel Read Only
Cooktop oic.r.heatingzone maxheatinglevel Read Only
Energy Monitor oic.r.energy.consumption power Read Only
Energy Monitor oic.r.energy.consumption energy Read Only
Fan oic.r.switch.binary value Read Write
Grinder oic.r.operational.state currentMachineState Read Write
Grinder oic.r.operational.state machineStates Read Only
Grinder oic.r.grinder coarseness Read Write
52 Device Name Required Resource types Attributes Access Mode
Kettle oic.r.switch.binary value Read Write
Light oic.r.switch.binary value Read Write
Oven oic.r.switch.binary value Read Write
Oven oic.r.temperature temperature Read Write
Receiver oic.r.switch.binary value Read Write
Receiver oic.r.audio mute Read Write
Receiver oic.r.audio volume Read Write
Receiver oic.r.media.input sources Read Write
Receiver oic.r.media.output sources Read Write
Set Top Box oic.r.switch.binary value Read Write
Steam Closet oic.r.operational.state currentMachineState Read Write
Steam Closet oic.r.operational.state machineStates Read Only
Television oic.r.switch.binary value Read Write
Television oic.r.audio mute Read Write
Television oic.r.audio volume Read Write
Television oic.r.media.input sources Read Write
Water Heater oic.r.switch.binary value Read Write
Water Heater oic.r.temperature temperature Read Write
Air Purifier oic.r.switch.binary value Read Write
53 Device Name Required Resource types Attributes Access Mode
Air Quality Monitor oic.r.airquality contaminanttype Read Only
Air Quality Monitor oic.r.airquality valuetype Read Only
Air Quality Monitor oic.r.airquality contaminantvalue Read Only
Air Quality Monitor oic.r.airquality charge Read Only
Blind oic.r.openlevel openLevel Read Write
Camera oic.r.media media Read Write
Clothes Washer oic.r.switch.binary value Read Write Dryer
Clothes Washer oic.r.operational.state currentMachineState Read Write Dryer
Clothes Washer oic.r.operational.state machineStates Read Only Dryer
Dehumidifier oic.r.switch.binary value Read Write
Dehumidifier oic.r.humidity humidity Read Only
Dehumidifier oic.r.humidity desiredHumidity Read Write
Dishwasher oic.r.switch.binary value Read Write
Dishwasher oic.r.mode modes Read Write
Dishwasher oic.r.mode supportedModes Read Only
Dryer (Laundry) oic.r.switch.binary value Read Write
Dryer (Laundry) oic.r.operational.state currentMachineState Read Write
54 Device Name Required Resource types Attributes Access Mode
Dryer (Laundry) oic.r.operational.state machineStates Read Only
Energy Generator oic.r.energy.generation energygenerated Read Only
Food Probe oic.r.temperature temperature Read Write
Freezer oic.r.temperature temperature Read Write
Humidifier oic.r.switch.binary value Read Write
Printer oic.r.switch.binary value Read Write
Printer oic.r.operational.state currentMachineState Read Write
Printer oic.r.operational.state machineStates Read Only
Refrigerator oic.r.temperature temperature Read Write
Robot Cleaner oic.r.switch.binary value Read Write
Robot Cleaner oic.r.mode modes Read Write
Robot Cleaner oic.r.mode supportedModes Read Only
Scanner oic.r.switch.binary value Read Write
Scanner oic.r.operational.state currentMachineState Read Write
Scanner oic.r.operational.state machineStates Read Only
Scanner oic.r.automaticdocumentfeeder adfStates Read Only
Scanner oic.r.automaticdocumentfeeder currentAdfState Read Only
Smart Plug oic.r.switch.binary value Read Write
Switch oic.r.switch.binary value Read Write
55 Device Name Required Resource types Attributes Access Mode
Washer (Laundry) oic.r.switch.binary value Read Write
Washer (Laundry) oic.r.operational.state currentMachineState Read Write
Washer (Laundry) oic.r.operational.state machineStates Read Only
Water Purifier oic.r.operational.state currentMachineState Read Write
Water Purifier oic.r.operational.state machineStates Read Only
Water Purifier oic.r.waterinfo supportedwatertypes Read Only
Water Purifier oic.r.waterinfo currentwatertype Read Write
Water Valve oic.r.openlevel openLevel Read Write
Geolocation oic.r.sensor.geolocation longitude Read Only
Geolocation oic.r.sensor.geolocation latitude Read Only
Geolocation oic.r.sensor.geolocation alt Read Only
Carbon Dioxide Sen- oic.r.sensor.carbondioxide value Read Only sor
Carbon Monoxide oic.r.sensor.carbondioxide value Read Only Sensor
Glass Break Sensor oic.r.sensor.glassbreak value Read Only
Illuminance Sensor oic.r.sensor.illuminance illuminance Read Only
Water Sensor oic.r.sensor.water value Read Only
Acceleration Sensor oic.r.sensor.acceleration acceleration Read Only
Sleep Sensor oic.r.sensor.sleep value Read Only
56 Device Name Required Resource types Attributes Access Mode
Smoke Sensor oic.r.sensor.smoke value Read Only
source: OCF Device Type overview [3–5, 27]
57 References
[1] Kang, W. M., Moon, S. Y., & Park, J. H. (2017). An enhanced security framework for home appliances in smart home. Human-Centric Computing and Information Sciences, 7(1), 1-12. doi:http://dx.doi.org.ezaccess.libraries.psu.edu/10.1186/s13673-017-0087-4
[2] Roei Schuster, Vitaly Shmatikov, and Eran Tromer. 2018. Situational Access Control in the Internet of Things. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS ’18). Association for Computing Machinery, New York, NY, USA, 1056–1073. DOI: https://doi.org/10.1145/3243734.324381 7https://doi.org/10.1145/3243734.3243817
[3] Openconnectivity.org. OCF Device Specification [online] Available at: https://openconnectivity.org/specs/OCF_Device_Specification_v2. 1.2.pdf [Accessed 22 June 2020].
[4] Openconnectivity.org. OCF Resource type Specification [online] Available at: https://openconnectivity.org/specs/OCF_Resource_Type_Specifica tion_v2.1.2.pdf [Accessed 22 June 2020].
[5] Openconnectivity.org. OCF Core Framework [online] Available at: https://openconnectivity.org/specs/OCF_Core_Specification_v2.1. 2.pdf [Accessed 22 June 2020].
[6] Jaeger T. (2011) Reference Monitor. In: van Tilborg H.C.A., Jajodia S. (eds) Encyclopedia of Cryptography and Security. Springer, Boston, MA
[7] Vijay Sivaraman, Dominic Chan, Dylan Earl, and Roksana Boreli. 2016. Smart-Phones Attacking Smart-Homes. In Proceedings of the 9th ACM Conference on Security & Privacy in Wireless and Mobile Networks (WiSec ’16). Association for Computing Machinery, New York, NY, USA, 195–200. DOI: https://doi.org/10.1145/2939918.293992 5https://doi.org/10.1145/2939918.2939925
[8] E. Fernandes, J. Jung and A. Prakash, "Security Analysis of Emerging Smart Home Applications," 2016 IEEE Symposium on Security and Privacy (SP), San Jose, CA, 2016, pp. 636-654, doi: 10.1109/SP.2016.44.
[9] Kaushal Kafle, Kevin Moran, Sunil Manandhar, Adwait Nadkarni, and Denys Poshyvanyk. 2019. A Study of Data Store-based Home Automation. In Proceedings of the Ninth ACM
58 Conference on Data and Application Security and Privacy (CODASPY ’19). Association for Computing Machinery, New York, NY, USA, 73–84. DOI:https://doi.org/10.1145/ 3292006.3300031
[10] Tian, Yuan, et al. "Smartauth: User-centered authorization for the internet of things." 26th { USENIX} Security Symposium ({ USENIX} Security 17). 2017.
[11] A. Wang and S. Nirjon, "A False Sense of Home Security — Exposing the Vulnerability in Away Mode of Smart Plugs," 2019 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops), Kyoto, Japan, 2019, pp. 316-321, doi: 10.1109/PERCOMW.2019.8730664.
[12] Amit Kumar Sikder, Leonardo Babun, Hidayet Aksu, and A. Selcuk Uluagac. 2019. Aegis: a context-aware security framework for smart home systems. In Proceedings of the 35th Annual Computer Security Applications Conference (ACSAC ’19). Association for Computing Machinery, New York, NY, USA, 28–41. DOI:https://doi.org/10.1145/3359789.3359840
[13] Pan, Zhiwen. “A Context Aware Anomaly Behavior Analysis Methodology for Building Automation Systems.” (2017).
[14] Y. Ashibani, D. Kauling and Q. H. Mahmoud, "A context-aware authentication framework for smart homes," 2017 IEEE 30th Canadian Conference on Electrical and Computer Engineering (CCECE), Windsor, ON, 2017, pp. 1-5, doi: 10.1109/CCECE.2017.7946657.
[15] Will Brackenbury, Abhimanyu Deora, Jillian Ritchey, Jason Vallee, Weijia He, Guan Wang, Michael L. Littman, and Blase Ur. 2019. How Users Interpret Bugs in Trigger-Action Programming. In Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems (CHI ’19). Association for Computing Machinery, New York, NY, USA, Paper 552, 1–12. DOI:https://doi.org/10.1145/3290605.3300782
[16] Celik, Z. Berkay, Gang Tan, and Patrick D. McDaniel. "IoTGuard: Dynamic Enforcement of Security and Safety Policy in Commodity IoT." NDSS. 2019.
[17] Jia, Yunhan Jack, et al. "ContexloT: Towards Providing Contextual Integrity to Appified IoT Platforms." NDSS. 2017.
[18] Pan, Zhiwen, et al. "Context Aware Anomaly Behavior Analysis for Smart Home Systems." International Journal of Information and Communication Engineering 13.5 (2019): 261-274.
[19] Hoque, M. Robiul, M. Humayun Kabir, and Sung-Hyun Yang. "Development of a Coopera- tive Middleware to Provide Context-Aware Service in Smart Home." International Journal of Smart Home 11.5 (2017): 33-40.
[20] Dutta, Sofia, et al. "Context Sensitive Access Control in Smart Home Environments." 6th IEEE International Conference on Big Data Security on Cloud (BigDataSecurity 2020).
[21] Sikder, Amit Kumar, et al. "Aegis: a context-aware security framework for smart home systems." Proceedings of the 35th Annual Computer Security Applications Conference. 2019.
59 [22] Mahroo, Atieh, et al. "Enabling the smart home through a semantic-based context-aware system." 2018 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops). IEEE, 2018. [23] Jacobsson, Andreas, Martin Boldt, and Bengt Carlsson. "A risk analysis of a smart home automation system." Future Generation Computer Systems 56 (2016): 719-733. [24] Demetriou, Soteris, et al. "Guardian of the HAN: Thwarting mobile attacks on smart-home devices using OS-level situation awareness." arXiv preprint arXiv:1703.01537 (2017). [25] Celik, Z. Berkay, Patrick McDaniel, and Gang Tan. "Soteria: Automated iot safety and security analysis." 2018 { USENIX} Annual Technical Conference ({ USENIX}{ ATC} 18). 2018. [26] Custom Automations In The Smartthings App. [online] Available at: https://support.smartthings.com/hc/en-us/articles/115002056383 -Custom-Automations-in-the-SmartThings-app [Accessed 22 June 2020]. [27] Openconnectivityfoundation.github.io. OCF Device Type Overview. [online] Available at: https://openconnectivityfoundation.github.io/devicemodels/docs/index.html [Accessed 22 June 2020].
[28] IoTivity Available at: https://iotivity.org/documentation/linux/programmers-g uide [Accessed 6 May 2020]. [29] Openconnectivity.org. [online] Available at: https://openconnectivity.org/wp-content/uploads/2016/01/3-OCF- IoTivity-Architecture-HSU-Final.pdf [Accessed 22 June 2020]. [30] Openconnectivity.org. [ebook] Available at: https://openconnectivity.org/wp-content/uploads/2016/01/IoTivi ty-101_Vijay-Joey.pdf [Accessed 22 May 2020]. [31] Support.google.com. 2020. Nest Thermostat Home/Away Assist Toggling When I Don’T Want It To. - Google Nest Community. [online] Available at: https://support.google.c om/googlenest/thread/12008585?hl=en [Accessed 29 June 2020]. [32] Tizen.org. [online] Available at: https://www.tizen.org/sites/default/files/event/ballroom1_31s t_1100-1200_iotivity_-_connecting_things_in_iot.pdf [Accessed 29 June 2020]. [33] Openconnectivity.org. [online] Available at: https://openconnectivity.org/wp-content/uploads/2016/01/Iotivi ty-tutorial-lfelc-20161013rzr.pdf [Accessed 29 June 2020]. [34] A. C. Jose and R. Malekian, "Improving Smart Home Security: Integrating Logical Sensing Into Smart Home," in IEEE Sensors Journal, vol. 17, no. 13, pp. 4269-4286, 1 July1, 2017, doi: 10.1109/JSEN.2017.2705045. [35] Ullah, Israr Kim, DoHyeun. (2018). IoT Resource Management using Direct Discovery Mechanism in OCF Framework. International Journal of Grid and Distributed Computing. 11. 1-10. 10.14257/ijgdc.2018.11.5.01.
60 [36] Sikder, Amit Kumar, Giuseppe Petracca, Hidayet Aksu, Trent Jaeger and A. Selcuk Uluagac. “A Survey on Sensor-based Threats to Internet-of-Things (IoT) Devices and Applications.” ArXiv abs/1802.02041 (2018): n. pag.
[37] Openconnectivity.org. [online] Available at: https://openconnectivity.org [Accessed 22 June 2020].
[38] Architecture Overview. Retrieved May 07, 2020, from https://iotivity.org/documen tation/architecture-overview
61