Understanding and Guaranteeing Security, Privacy, and Safety of Smart Homes
Total Page:16
File Type:pdf, Size:1020Kb
UNIVERSITY OF CALIFORNIA, IRVINE Understanding and Guaranteeing Security, Privacy, and Safety of Smart Homes DISSERTATION submitted in partial satisfaction of the requirements for the degree of DOCTOR OF PHILOSOPHY in Computer Engineering by Rahmadi Trimananda Dissertation Committee: Professor Brian Demsky, Chair Professor Athina Markopoulou Professor Guoqing (Harry) Xu 2020 © 2020 Rahmadi Trimananda DEDICATION To God the Trinity, my family, and humanity ii TABLE OF CONTENTS Page LIST OF FIGURES vi LIST OF TABLES vii ACKNOWLEDGMENTS ix VITA xi ABSTRACT OF THE DISSERTATION xiii 1 Introduction 1 1.1 Overview of a Smart Home . .2 1.1.1 Components . .3 1.1.2 Execution Model . .4 1.2 Smart Home Devices . .4 1.3 Smart Home Platforms . .7 1.4 Smart Home Apps . .8 1.5 Organization . 12 2 Packet-Level Signatures for Smart Home Devices 14 2.1 New Packet-Level Signatures . 14 2.2 Problem Setup . 15 2.2.1 Threat Model . 15 2.2.2 Smart Home Environment and Experimental Testbed . 16 2.2.3 Motivating Case: Smart Plugs . 20 2.3 PingPong Design . 21 2.3.1 Training . 22 2.3.2 Detection . 30 2.4 Evaluation . 33 2.4.1 Extracting Signatures from Smart Home Devices . 37 2.4.2 Smart Home Testbed Experiment . 40 2.4.3 Negative Control Experiment . 42 2.4.4 Events Triggered Remotely . 43 2.4.5 Devices from the Same Vendor . 47 2.4.6 Public Dataset Experiment . 48 2.4.7 Parameters Selection and Sensitivity . 56 iii 2.5 Possible Defenses against Packet-Level Signatures . 57 2.5.1 Possible Implementations . 58 2.5.2 Residual Side-Channel Information . 59 2.5.3 Efficacy of Packet Padding . 60 2.5.4 Recommendations for Padding . 62 2.5.5 Traffic Shaping and Injection . 62 3 Securing Smart Home Edge Computing 64 3.1 Smart Home System Vulnerabilities . 64 3.2 Vigilia Approach . 66 3.3 Threat Model and Guarantees . 67 3.4 Example . 68 3.5 Architecture and Programming Model . 70 3.6 Vigilia Security Mechanisms . 75 3.7 Vigilia Runtime System . 80 3.8 Evaluation . 83 3.8.1 Applications . 84 3.8.2 Comparisons . 87 3.8.3 Public IP . 92 3.8.4 Performance Microbenchmarks . 94 4 Understanding and Detecting Conflicting Interactions between Smart Home IoT Applications 96 4.1 Methodology . 97 4.1.1 Definitions . 98 4.1.2 Smart Home App Pairs . 101 4.1.3 Threats to Validity . 104 4.2 Device Interaction . 106 4.2.1 RQ1: Types of Non-Conflicting Interactions . 107 4.2.2 RQ2: Types of Conflicting Interactions . 108 4.2.3 RQ3: Prevalence of Conflicts . 110 4.2.4 RQ4: Unsafe Coding Patterns . 110 4.3 Physical-Medium Interaction . 111 4.3.1 RQ1&2: Types of (Non-)Conflicting Interactions . 111 4.3.2 RQ3&4: Prevalence of Conflicts/Unsafe Coding . 113 4.4 Global-Variable Interaction . 114 4.4.1 RQ1: Types of Non-Conflicting Interactions . 114 4.4.2 RQ2: Types of Conflicting Interactions . 115 4.4.3 RQ3&4: Prevalence of Conflicts and Unsafe Coding . 116 4.5 IoTCheck: Automated Conflict Detection . 117 4.5.1 IoTCheck Design . 117 4.5.2 Results . 122 iv 5 Related Work 124 5.1 Network Traffic Analysis and Defenses . 124 5.2 Smart Home and IoT Security . 132 5.3 Interactions of Smart Home Applications . 139 5.4 Other Related Work . 149 6 Conclusions 151 6.1 Summary . 151 6.2 Limitations and Future Directions . 152 Bibliography 155 v LIST OF FIGURES Page 1.1 SmartThings platform that integrates devices and manages multiple apps. .2 2.1 Our experimental setup for studying smart home devices. \Wi-Fi Device" is any smart home device connected to the router via Wi-Fi (e.g., Amazon and WeMo plugs). \Ethernet Device" is any smart home device connected to the router via Ethernet (e.g., SmartThings hub that relays the communication of Zigbee devices). Smart home device events may result in communication between Phone-Cloud, Device-Cloud, or Phone-Device. There may also be background traffic from additional computing devices in the home. 17 2.2 Left: PingPong Overview. Right: TP-Link plug is used as a running example throughout this section. 23 2.3 Pair clustering and signature creation for 2 extreme cases|TP-Link plug has the simplest signature with only 1 pair (see our initial findings in Ta- ble 2.2). The Arlo camera has a more complex signature with 1 sequence of 2 pairs and 1 sequence of 1 pair. The left subfigure, in every row, depicts the packet lengths in one packet pair (Pc1 , Pc2 ). Notation: C->S means a pair where the first packet's direction is Client-to-Server and the second packet's direction is server-to-client, and vice versa for S->C; f: 50 means that the pair appears in the clustering with a frequency of 50 ; Signature notation shows a summary of 2 sets of 50 instances of packet sequences. Example: C->S 556, 1293 f: 50 means that the pair of packets with lengths 556 (client-to-server) and 1293 (server-to-client) appear 50 times in the cluster. 24 3.1 A closer examination of an irrigation system. 68 3.2 Vigilia system architecture. 70 3.3 Example application code in Java. 72 3.4 Example device driver header in C++. 74 3.5 Capability-based RMI example. 79 3.6 Vigilia program (i.e., irrigation system) (a), device database (b), and instan- tiated firewall rules (c). 80 3.7 Vigilia hardware setup. 84 4.1 SmartThings Execution Traces. 98 4.2 IoTCheck Architecture. 118 4.3 Conflict Analysis . 119 vi LIST OF TABLES Page 2.1 The set of smart home devices considered in this paper. Devices highlighted in green are among the most popular on Amazon. 18 2.2 Packet-level signatures of TP-Link, D-Link, and SmartThings smart plugs observable by the WAN sniffer. The numbers represent packet lengths, with red indicating that the length is different for ON vs. OFF, and the arrows represent packet directions. 19 2.3 Smart plugs found to exhibit Phone-Cloud, Device-Cloud, and Phone-Device signatures. Prefix PH indicates Phone-to-device direction and prefix D indi- cates Device-to-phone direction in Signature column. Column Dura. reports numbers in the form of Min./Avg./Max., namely minimum, average, and maximum durations respectively. 34 2.4 Smart light bulbs found to exhibit Phone-Cloud, Device-Cloud, and Phone- Device signatures. Prefix PH indicates Phone-to-device direction and prefix D indicates Device-to-phone direction in Signature column. Column Dura. re- ports numbers in the form of Min./Avg./Max., namely minimum, average, and maximum durations respectively. 35 2.5 Smart thermostats and sprinklers found to exhibit Phone-Cloud, Device- Cloud, and Phone-Device signatures. Prefix PH indicates Phone-to-device direction and prefix D indicates Device-to-phone direction in Signature col- umn. Column Dura. reports numbers in the form of Min./Avg./Max., namely minimum, average, and maximum durations respectively. 36 2.6 Smart home security devices and others found to exhibit Phone-Cloud, Device- Cloud, and Phone-Device signatures. Prefix PH indicates Phone-to-device di- rection and prefix D indicates Device-to-phone direction in Signature column. Column Dura. reports numbers in the form of Min./Avg./Max., namely minimum, average, and maximum durations respectively. 37 2.7 Device-Cloud signature in 9 devices triggered by IFTTT home automation. 44 2.8 Comparison of Device-Cloud signatures for three devices (TP-Link plug, D- Link plug, and Rachio sprinkler) triggered in three different ways: via (i) a local phone, (ii) a remote phone, and (iii) IFTTT home automation. 45 2.9 Signatures extracted from different TP-Link devices. ∗These are the latest signatures for the TP-Link plug and TP-Link light bulb (per December 2019). 48 2.10 Signatures extracted from the cameras and light bulbs only in the Mon(IoT)r [166] dataset. 49 vii 2.11 Signatures extracted from the voice command devices only in the Mon(IoT)r [166] dataset. 50 2.12 Signatures extracted from the smart TVs and other devices only in the Mon(IoT)r [166] dataset. 51 2.13 Common devices that have the same signatures in the Mon(IoT)r and our testbed experiments. ∗ signature: training on our testbed. y signature: training on Mon(IoT)r [166]. Matching: training on testbed, detection on Mon(IoT)r. The number of events vary (around 30-40) per event type|the result is presented in % for convenience. 51 2.14 Common devices that have similar signatures in the Mon(IoT)r and our testbed experiments. ∗ signature: training on our testbed. y signature: training on Mon(IoT)r [166]. Matching: training on testbed, detection on Mon(IoT)r. The number of events vary (around 30-40) per event type|the result is pre- sented in % for convenience. 52 3.1 Lines of code in Vigilia applications. 85 3.2 Summary of Vigilia applications. 85 3.3 Attacks performed on devices. ..