物联网实验
Introduction
The Internet of Things (IoT) is expanding rapidly, with projections of 50 billion connected devices by 2020 [1]. These devices will provide an unprecedented ability to sense and control our environments, from our homes through our utilities to our industries, in our cars and on our bodies. Sensor data can be aggregated across our devices and sent to remote data centers to be analyzed. Device control can be initiated from across the world. Industrial equipment makers are routinely adding sensors and network connectivity to equipment such as turbines that have traditionally been controlled only locally in order to yield cost savings due to increased monitoring and remote control [2]. The positive potential of connected devices and analytics is driving large investments into the IoT, the Industrial Internet and Machine-2-Machine communications.
One promising application of IoT is in our homes. Smart home technologies provide sensors and controllers throughout our homes that promise energy savings, home automation, and other cost savings and conveniences. For example, thermostats can be adjusted automatically based on sensed motion patterns, doors can be unlocked when the owner's smartphone moves inside of a geofence around the home, and open garage doors can be reported to us while on vacation thousands of miles away from home. However, without security and privacy controls, this promise will not be positively achieved. An adversary with access to smart home sensor data can detect when the owner leaves the home or suppress an open garage door alarm in order to gain physical access. Well-known security and privacy problems have been shown across devices and networks, from pacemakers that can be made to deliver a fatal charge to networked light bulbs that can provide back doors into WiFi networks, to smart TVs that listen to conversations, to refrigerators that are enlisted into denial of service attacks [3].
In this paper we begin to explore the risks to security and privacy of IoT networks, focusing first on home automation networks. A testbed of home automation equipment can be set up at minimal cost using commercial off-the-shelf (COTS) products. Studying potential attacks on smart homes provides insight into other IoT applications. Privacy attacks due to home sensor data being sent to remote data centers for analysis have similarities to attacks on industrial systems due to exposing turbine data and control to unauthorized access in third-party data centers. An adversary who gains access to a home automation network to manipulate sensor readings may use similar techniques to gain access to an automobile telematics network to cause harm to the vehicle or occupants.
Our initial research focuses on mechanisms for privacy preservation in smart homes. In particular, we experiment with techniques to trade-off resilient use of IoT-enabled services with protection of user data privacy. We look at both simple cryptographic techniques and information manipulation to protect a user against an adversary inside the IoT network or an adversary that has compromised remote servers. Our goal is to experiment with techniques that manipulate the adversary's view of a user's IoT data. In this way the user can reconstruct the true state of their data while the adversary has uncertainty about the true state. This increases the adversary's difficulty in conducting a successful attack.
In Section II we introduce our experimental set-up and our process for gathering data and affecting the IoT. Our experimental set-up is based on COTS home automation products that, nevertheless, take advantage of remote cloud servers and include an ecosystem of both smartphone and web-based monitoring and control applications. We rely on passively captured network traffic to understand our target home automation network and to observe how our experimental actions affect the network. We create encrypted overlay networks using commercially accessible VPN services. We manipulate home automation sensors using simple automation tools.
In Section III we describe our initial studies. Our initial studies look at how user data can be masked or selectively leaked and manipulated. Simple masking can be accomplished with VPN overlay networks, analogous to how Tor provides an overlay network for anonymous Web browsing. We experiment with VPN servers at various physical locations, studying both the performance and functionality changes due to varying location. We spoof user location by faking GPS readings, providing a mechanism to protect location privacy and studying the impact of location privacy on home automation utility. We experiment with sensor manipulation to mask user behavior patterns from an adversary while being able to reconstruct true behavior at the home automation application. We show that sensor manipulation can be used to manipulate if-this-then-that (IFTTT) recipes. Finally, in Section V we discuss our results and introduce open questions for future work.
Home Automation Study
A. Network Architecture
A home automation network, formed by a set of networked home automation products, connects to a centralized cloud server for sensor reporting and control. Local devices on the periphery of the network may speak non-IP protocols, such as Zigbee®1 and Z-Wave®2. These devices can be bridged into an IP network using an IoT hub as depicted in Fig. 1.
A home automation network with an iot hub bridging proprietary devices into an IP network. A cloud server notifies a user's mobile device of activity in the home.
For the studies in this paper, we configured a SmartThings ™ hub and several SmartThings sensors: an open/close sensor, a motion sensor, and a mobile presence sensor 3. SmartThings, like most home automation products, provides a web client and mobile app for monitoring and control. Through passive traffic analysis, we observed that the SmartThings hub communicates via an SSL encrypted channel with a cloud server hosted by Amazon Web Services (AWS), located in the Eastern U.S. The experiments in this paper and the vulnerabilities we discuss are not unique to SmartThings; they can be generalized to any home automation network with a client/server architecture using SSL.
B. Network Traffic Analysis
In order to design our experiments, we started by passively observing traffic flowing over the home automation network. We collected packet captures using tcpdump from a number of locations in the network: on eth0, tun0, and at the VPN server. The SmartThings hub and mobile device running the SmartThings app communicate with different IP addresses, which motivated our distinction of a phone server and hub server in Fig. 1. Following a DNS lookup, we observed the IoT hub establish a TCP connection with the server and then build an SSL connection. Analysis of the SSL traffic suggests that the hub periodically checks in with the server, which is supported by the pings reported in the hub view of the SmartThings web client. In Fig. 2 we show a screenshot of an example packet capture showing a TCP keepalive pattern and encrypted application data.
TCP keepalives are periodically sent from the hub. Open/close and motion sensor traffic appear similar with length 109 bytes.
Privacy Preserving Techniques
Consumers expect a certain level of privacy when using home automation products and naively trust that their data will be protected [4], [5]. As IoT data is generated, it is shared with an IoT service provider and typically hosted in the cloud by a third-party service. Despite measures taken to ensure a user's privacy, including encrypting client/server communication, data about a user- his behaviors, patterns, preferences-may still be leaked. In the following set of experiments, we show that passive observance of the underlying network may still reveal unwanted details to (un)trusted third parties. We began our experiments by investigating the feasibility of concealing a user's location.
A. Conceal Location Information
Providing location information to IoT devices enables additional functionality like thermostats utilizing local weather data and smart homes making control decisions with geofencing. In order to activate this additional functionality, users must sacrifice individual privacy and agree to disclose their location to an IoT server. Even if a user does not provide supplemental location information, location details are revealed by a user's IP address (e.g. in our experimental testbed, our IP address can be located to the Eastern U.S.). To address this, we propose setting up a VPN server to proxy communication between a user's home network and the cloud.
1) VPN Architecture
We set up a VPN server hosted by Digital Ocean out of New York City (NYC) using OpenVPN® [6] as depicted in Fig. 3 4. We installed the OpenVPN client on an Ubuntu machine configured as an Ubuntu router [7] with the SmartThings hub connected to eth0 and IP forwarding to tun0. The SmartThings hub functioned as expected with the VPN masking the true IP address of the hub or home router (if using NAT). We also used a Nexus™ 4 to run the SmartThings app with the Open VPN client application 5. The VPN overlay did not cause any failures in the use of the SmartThings network. The SmartThings app continued to run as expected with event notifications received as sensors were triggered.
In a subsequent experiment, we set up a second VPN server out of San Francisco (SFO) and further validated the preservation of functionality given the VPN configuration. To determine if switching VPN servers would be reported by SmartThings and therefore presented to the user, we performed two open/close tests (detailed later in III-B1) changing the VPN server in the middle. A script was used to minimize the delay in switching VPN servers. The hub did not report to the web client that it was inactive, nor did the mobile app receive a notification that the hub was offline during the VPN switch.
The lack of notification for momentary losses of a connection between the hub and the server is on the surface not a concern. However, a momentary loss of the connection and then the hub appearing from a different IP address is significant6. The change in addresses could indicate a Man-in -The-Middle attack.
Adding a VPN to the network architecture does introduce delay in the network. In Fig. 4 we show the time between the transmission of a keepalive (KA) message from the hub client and the receipt of a keepalive ack from the server. The average time without the VPN setup is 0.778ms; 13.97 ms with a VPN server in NYC; and 155.23ms with a VPN server in SFO. The distance (number of hops) between the hub's location, the VPN server's location, and the IoT server's location contributes to the additional delay with the SFO server as confirmed by supplemental traceroute data. An average processing delay of 250.02ms for the hub server to notify the phone server to notify the mobile app is more significant than the networking delay from the VPN. Additionally, the time between the hub sending a notification to the server and the phone receiving the corresponding message is variable. This round trip time varies between 250ms and 364ms, with a standard deviation of 43ms.
Time between TCP keepalive sent from client and TCP keepalive ACK received from server as compared to the processing delay for an event notification originating from the hub to be received by the mobile device.
2) Mobile Presence Spoofing
While the VPN allows the hub or mobile device to take on the IP address of the VPN server, the mobile app may still reveal details about the user's location. The phone can act as a mobile presence sensor using the phone's GPS to trigger notifications as the device traverses a geofence as shown in Fig. 5(a). We used the Fake GPS location app by Lexa [8] to spoof the location of our Android™ device7. The fake GPS location in Fig. 5(b) was offset by one mile just outside of the geofence; the blue dot in Fig. 5(c) represents the new, spoofed location outside of the geofence in the SmartThings app. While using a fake location, the sensor reporting continued as expected and conditional actions/alerts were completed based on the spoofed location.
In (a) the red pin represents the home location set by the device, and the current location is displayed with a blue dot. The device's spoofed location shown with a red pin in (b) is approximately one mile away at the end of the road and outside of the geofence shown in (c).
B. Manipulate Event Reporting
While a user can hide his true location to confuse an adversary, the timing and frequency of sensor events reveals information about a user's private behavior and daily patterns. We explored three classes of techniques to manipulate events reported to the hub server in order to create a false view of data leaving the network including delaying events, inserting events, and dropping events. The techniques described are possible because the web client reports the time that the notification was received at the server, not the time it was generated at the hub.
To disrupt the network and manipulate the timing of events by delaying them, we explored the set of firewall rules summarized in Table I. The experiments using the first rule, Drop TCP, are described in detail below. The other rules delay or block event reporting as noted in the “Result” column. The remaining tests were executed and their results are summarized in the table. Any combination of these firewall rules can be automatically enabled/disabled with a script to introduce randomness into a user's pattern of life profile.
1) Baseline Event Reporting
In order to understand the impact of our firewall rules, we created a baseline experiment using the open/close sensor. Open/close testing was performed by manually “opening and closing” the SmartSense open/close sensor at 30 second intervals. The experimental procedure was identical for tests with and without the VPN connections. For each test the sensor started in the closed position, then was opened after 30 seconds and finally closed after another 30 seconds. Before the sensor was closed or opened, a single ping was sent to the hub and if applicable the VPN server to provide a marker in the data. The initial TTL of the ping packet was 50 for the open event and 100 for the closed event. The event notifications plotted in Fig. 6 (allow TCP) were displayed to the user via web client or phone app approximately every 30 seconds as expected.
The open/close sensor is triggered every 30 seconds. When the firewall rule is disabled, the event notifications reach the server. Otherwise, a portion of the notifications reach the server at 668s once TCP traffic is allowed.
Given the SSL encryption, the packets for an open/close trigger are indistinguishable. From the location of the ping packets, we can infer that event notifications from the hub are of length 109 bytes as shown in packets 5 and 17 which follow the pings in packets 3 and 13 of Fig. 2. Whether intentional or not, the design of the hub messages to the server prevented us from selectively manipulating traffic by device type since the packets looked the same for the sensors considered. Ultimately, we were able to disrupt the home automation network and effect the communication between the client and server as discussed in the remainder of this section.
2) Delaying Events
To evaluate the performance of the system when communications between the hub and hub server were disrupted, we used a modified version of the open/close testing procedure. This test began with an open event followed by a close event after 30 seconds. Next the “Drop TCP” firewall rule was used to drop all TCP packets between the hub and the hub server. We then performed the open/close testing procedure. After ten iterations, the blocking firewall rule was deleted. Pings were used to mark the open and close events as well as the creation and deletion of the firewall rule.
Once the rule was removed, a portion of the event notifications in Fig. 6 (drop TCP) were received at the server with timestamps reflecting the approximate time the rule was removed. As a result of delayed event reporting, conditional actions are also delayed. For example, we enabled an IFTTT recipe to place a phone call when the door sensor is triggered as shown in Fig. 7. Following the door opening, the recipe did not trigger until the event was reported at the server. an adversary and artificially creating events can further contribute to the perceivedactivity in a home. In order to trigger the motion and open/close sensor, we assembled a LEGO® MINDSTORMS® robot8 and programmed it to periodically trigger the sensors. A photo of our setup is shown in Fig. 8.
Delayed event reporting delays conditional actions like this IFTTT recipe set to trigger a phone call if the door opens.
Experimental setup of LEGO® MINDSTORMS® for artificially triggering the open/close and motion sensors.
3) Inserting Events
Delaying events can certainly confuse By filtering the false events at the application level, a user can reconstruct true behavior while potentially confusing a third party consuming all of the data. Programmatically, but randomly triggering sensors can hamper the pattern of life analysis. A more complex robot can move from room to room and cause events to be triggered such as turning lights on and off. Open/close sensors can be placed where the robot can open and close a door labeled as “Back Door”, when the house does not have a back door. These deception techniques will likely prevent an outside observer from determining if the house is occupied. The user will know to ignore certain sensors.
4) Dropping Events
Another technique considered is dropping TCP packets until the hub's buffer fills. Reducing events during a period of time can lead to incorrect inferences about user activity. Supressing events could be done by dropping TCP packets for an extended period of time while true sensor readings build up or by inserting enough synthetic events until the buffer's queue overflows. The “Drop Size 109–300, Allow Size 254” firewall rule could be used to maintain intermittent connectivity with the server. To an outside observer, this behavior could be attributed to connectivity problems within a user's home network. While its applicability to privacy preservation is less interesting, this technique could be used by an attacker to disrupt event reporting and prevent IFTTT actions from being performed.
Discussion
Our initial studies show that user data can be masked or selectively leaked and manipulated. By manipulating sensor data we can increase the cost of adversary attack. In particular, increasing an adversary's uncertainty about the true state of an IoT network increases the risk that an attack will fail or cause unintended effects. In this work we just scratch the surface of both the challenges of fielding a secure and private IoT and the potential solutions. In future work we will expand both the cryptographic techniques to provide security and privacy and introduce new information manipulation techniques. We are particularly interested in information leakage detection and control in IoT networks.
In related work, [9] focuses on IoT privacy in RFID asset tracking within the context of a legal framework, pointing out the use of VPN, TLS, secure DNS, onion routing, and private information retrieval to enhance privacy. The author discusses privacy rights of an individual's activity in addition to basic personally identifiable information (PII).
The adoption of IoT technology may ultimately be driven by the consumer's willingness to tradeoff utility and privacy. In this paper we explore the mechanisms to manipulate information to effect this tradeoff. In future work we will quantify the amount of information manipulation that is possible and the tradeoffs between increasing attack difficulty and decreasing IoT network utility and performance. By creating a false baseline of home activity we impact the statistics used by the provider to secure the service. Selectively inserted events can be removed at the user application but are more difficult to remove from analytics results performed at a remote data center. We are exploring more complex interactions between inserted sensor events and analytics and how analytics results can be inverted to remove inserted events. The work in [10] provides an approach to identify the sensitivity of smart meter sensor readings using statistical methods. They use mutual information to quantify the level of privacy in a dataset.
Energy is another dimension in evaluating IoT security and/or privacy tradeoffs, as reviewed in [11]. With respect to our work in this paper, by introducing additional, artificial events, the sensors must perform additional energy-consuming transmissions. However, many IoT devices are designed to use low-energy sensors [11]. As we extend our work, we will consider the performance implications of our privacy preserving techniques with respect to multiple objectives as in [12], including energy consumption.
An important contribution to security and privacy issues in IoT networks is the extent of information distribution. Security and privacy may be improved by providing more localized information exchange. In [13], the authors explore these challenges with respect to centralized and distributed services architectures, providing both strengths and limitations of the alternative approaches. Overlays for exchanging information locally have also been explored in work on content-centric networking [14].
Conclusion
We have provided an initial study of the risks to security and privacy of IoT networks, focusing on home automation networks. Our studies have focused primarily on privacy preservation. Preserving privacy is key to achieving the potential of billions of connected devices and analytics, such as providing smart home technologies to save energy and improve home security. We provide a blueprint for inexpensive study of IoT security and privacy using COTS products and services. These inexpensive testbeds can provide insight into other IoT applications. We demonstrate that both simple cryptographic techniques and information manipulation can be employed to protect a user against an adversary inside the IoT network or an adversary that has compromised remote servers. We show the utility of proxying IoT network data through VPN overlay networks. This can become a generic service to IoT users, analogous to Web browsing anonymity provided by Tor.
Automated fingerprinting and characterization is another technique to help improve the security and privacy of IoT networks. Many of our initial observations from experimentation can be applied toward fingerprinting IoT networks and devices. In particular, we observed the initial connection set-up, firmware update messages, and periodic status updates, all of which can apply to developing a fingerprint. In future work we will tackle network and device characterization techniques for IoT architectures. Similarly, our analysis techniques can be extended to perform protocol reverse engineering and vulnerability analysis of IoT architectures, using only passively captured binary traffic.
浙公网安备 33010602011771号