Experiments with Security and Privacyin IoT Networks

Mary R. Schurgot, David A. Shinberg, Lloyd G. GreenwaldLGS Innovations, LLC, Florham Park, New Jersey{maschurg,shinberg,lgreenwald}@lgsinnovations.com

Abstract—We explore the risks to security and privacy inIoT networks by setting up an inexpensive home automationnetwork and performing a set of experiments intended to studyattacks and defenses. We focus on privacy preservation in homeautomation networks but our insights can extend to other IoTapplications. Privacy preservation is fundamental to achieving thepromise of IoT, Industrial Internet and M2M. We look at bothsimple cryptographic techniques and information manipulationto protect a user against an adversary inside the IoT network oran adversary that has compromised remote servers. We show howuser data can be masked or selectively leaked and manipulated.We provide a blueprint for inexpensive study of IoT security andprivacy using COTS products and services.

Index Terms—IoT, Internet of Things, privacy, network secu-rity, home automation.

I. INTRODUCTION

The Internet of Things (IoT) is expanding rapidly, withprojections of 50 billion connected devices by 2020 [1]. Thesedevices will provide an unprecedented ability to sense andcontrol our environments, from our homes through our utilitiesto our industries, in our cars and on our bodies. Sensor datacan be aggregated across our devices and sent to remote datacenters to be analyzed. Device control can be initiated fromacross the world. Industrial equipment makers are routinelyadding sensors and network connectivity to equipment suchas turbines that have traditionally been controlled only locallyin order to yield cost savings due to increased monitoring andremote control [2]. The positive potential of connected devicesand analytics is driving large investments into the IoT, theIndustrial Internet and Machine-2-Machine communications.

One promising application of IoT is in our homes. Smarthome technologies provide sensors and controllers throughoutour homes that promise energy savings, home automation, andother cost savings and conveniences. For example, thermostatscan be adjusted automatically based on sensed motion patterns,doors can be unlocked when the owner’s smartphone movesinside of a geofence around the home, and open garagedoors can be reported to us while on vacation thousandsof miles away from home. However, without security andprivacy controls, this promise will not be positively achieved.An adversary with access to smart home sensor data candetect when the owner leaves the home or suppress an opengarage door alarm in order to gain physical access. Well-known security and privacy problems have been shown acrossdevices and networks, from pacemakers that can be made todeliver a fatal charge to networked light bulbs that can provide

back doors into WiFi networks, to smart TVs that listen toconversations, to refrigerators that are enlisted into denial ofservice attacks [3].

In this paper we begin to explore the risks to security andprivacy of IoT networks, focusing first on home automationnetworks. A testbed of home automation equipment can beset up at minimal cost using commercial off-the-shelf (COTS)products. Studying potential attacks on smart homes providesinsight into other IoT applications. Privacy attacks due to homesensor data being sent to remote data centers for analysis havesimilarities to attacks on industrial systems due to exposingturbine data and control to unauthorized access in third-party data centers. An adversary who gains access to a homeautomation network to manipulate sensor readings may usesimilar techniques to gain access to an automobile telematicsnetwork to cause harm to the vehicle or occupants.

Our initial research focuses on mechanisms for privacypreservation in smart homes. In particular, we experiment withtechniques to trade-off resilient use of IoT-enabled serviceswith protection of user data privacy. We look at both simplecryptographic techniques and information manipulation toprotect a user against an adversary inside the IoT network oran adversary that has compromised remote servers. Our goal isto experiment with techniques that manipulate the adversary’sview of a user’s IoT data. In this way the user can reconstructthe true state of their data while the adversary has uncertaintyabout the true state. This increases the adversary’s difficultyin conducting a successful attack.

In Section II we introduce our experimental set-up andour process for gathering data and affecting the IoT. Ourexperimental set-up is based on COTS home automationproducts that, nevertheless, take advantage of remote cloudservers and include an ecosystem of both smartphone andweb-based monitoring and control applications. We rely onpassively captured network traffic to understand our targethome automation network and to observe how our experimen-tal actions affect the network. We create encrypted overlaynetworks using commercially accessible VPN services. Wemanipulate home automation sensors using simple automationtools.

In Section III we describe our initial studies. Our initialstudies look at how user data can be masked or selectivelyleaked and manipulated. Simple masking can be accomplishedwith VPN overlay networks, analogous to how Tor provides anoverlay network for anonymous Web browsing. We experiment

978-1-4799-8461-9/15/$31.00 c©2015 IEEE

with VPN servers at various physical locations, studying boththe performance and functionality changes due to varying loca-tion. We spoof user location by faking GPS readings, providinga mechanism to protect location privacy and studying theimpact of location privacy on home automation utility. Weexperiment with sensor manipulation to mask user behaviorpatterns from an adversary while being able to reconstructtrue behavior at the home automation application. We showthat sensor manipulation can be used to manipulate if-this-then-that (IFTTT) recipes. Finally, in Section V we discussour results and introduce open questions for future work.

II. HOME AUTOMATION STUDY

A. Network Architecture

A home automation network, formed by a set of networkedhome automation products, connects to a centralized cloudserver for sensor reporting and control. Local devices on theperiphery of the network may speak non-IP protocols, such asZigbee R©1 and Z-Wave R©2. These devices can be bridged intoan IP network using an IoT hub as depicted in Fig. 1.

Fig. 1. A home automation network with an IoT hub bridging proprietarydevices into an IP network. A cloud server notifies a user’s mobile device ofactivity in the home.

For the studies in this paper, we configured aSmartThingsTM hub and several SmartThings sensors:an open/close sensor, a motion sensor, and a mobile presencesensor3. SmartThings, like most home automation products,provides a web client and mobile app for monitoring andcontrol. Through passive traffic analysis, we observed thatthe SmartThings hub communicates via an SSL encryptedchannel with a cloud server hosted by Amazon Web Services(AWS), located in the Eastern U.S. The experiments in thispaper and the vulnerabilities we discuss are not unique toSmartThings; they can be generalized to any home automationnetwork with a client/server architecture using SSL.

B. Network Traffic Analysis

In order to design our experiments, we started by passivelyobserving traffic flowing over the home automation network.

1Zigbee R© is a registered trademark for the ZigBee Alliance.2Z-Wave R© is a registered trademark of Sigma Designs and its subsidiaries

in the United States and other countries.3SmartThings is a trademark of SmartThings, Inc.

We collected packet captures using tcpdump from a numberof locations in the network: on eth0, tun0, and at the VPNserver. The SmartThings hub and mobile device running theSmartThings app communicate with different IP addresses,which motivated our distinction of a phone server and hubserver in Fig. 1. Following a DNS lookup, we observed theIoT hub establish a TCP connection with the server and thenbuild an SSL connection. Analysis of the SSL traffic suggeststhat the hub periodically checks in with the server, whichis supported by the pings reported in the hub view of theSmartThings web client. In Fig. 2 we show a screenshot of anexample packet capture showing a TCP keepalive pattern andencrypted application data.

III. PRIVACY PRESERVING TECHNIQUES

Consumers expect a certain level of privacy when usinghome automation products and naively trust that their datawill be protected [4], [5]. As IoT data is generated, it is sharedwith an IoT service provider and typically hosted in the cloudby a third-party service. Despite measures taken to ensure auser’s privacy, including encrypting client/server communica-tion, 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 networkmay still reveal unwanted details to (un)trusted third parties.We began our experiments by investigating the feasibility ofconcealing a user’s location.

Fig. 3. Home automation network with VPN.

A. Conceal Location Information

Providing location information to IoT devices enables ad-ditional functionality like thermostats utilizing local weatherdata and smart homes making control decisions with geofenc-ing. In order to activate this additional functionality, users mustsacrifice individual privacy and agree to disclose their locationto an IoT server. Even if a user does not provide supplementallocation information, location details are revealed by a user’sIP address (e.g. in our experimental testbed, our IP address canbe located to the Eastern U.S.). To address this, we proposesetting up a VPN server to proxy communication between auser’s home network and the cloud.

Fig. 2. TCP keepalives are periodically sent from the hub. Open/close and motion sensor traffic appear similar with length 109 bytes.

1) VPN Architecture: We set up a VPN server hosted byDigital Ocean out of New York City (NYC) using OpenVPN R©[6] as depicted in Fig. 34. We installed the OpenVPN client onan Ubuntu machine configured as an Ubuntu router [7] with theSmartThings hub connected to eth0 and IP forwarding to tun0.The SmartThings hub functioned as expected with the VPNmasking the true IP address of the hub or home router (if usingNAT). We also used a NexusTM 4 to run the SmartThings appwith the OpenVPN client application5. The VPN overlay didnot cause any failures in the use of the SmartThings network.The SmartThings app continued to run as expected with eventnotifications received as sensors were triggered.

In a subsequent experiment, we set up a second VPNserver out of San Francisco (SFO) and further validated thepreservation of functionality given the VPN configuration. Todetermine if switching VPN servers would be reported bySmartThings and therefore presented to the user, we performedtwo open/close tests (detailed later in III-B1) changing theVPN server in the middle. A script was used to minimize thedelay in switching VPN servers. The hub did not report to theweb client that it was inactive, nor did the mobile app receivea notification that the hub was offline during the VPN switch.

Fig. 4. Time between TCP keepalive sent from client and TCP keepaliveACK received from server as compared to the processing delay for an eventnotification originating from the hub to be received by the mobile device.

4“OpenVPN” is a trademark of OpenVPN Technologies, Inc.5Nexus is a trademark of Google Inc.

The lack of notification for momentary losses of a con-nection between the hub and the server is on the surfacenot a concern. However, a momentary loss of the connectionand then the hub appearing from a different IP address issignificant6. The change in addresses could indicate a Man-in-The-Middle attack.

Adding a VPN to the network architecture does introducedelay in the network. In Fig. 4 we show the time betweenthe transmission of a keepalive (KA) message from the hubclient and the receipt of a keepalive ack from the server.The average time without the VPN setup is 0.778ms; 13.97ms with a VPN server in NYC; and 155.23ms with a VPNserver in SFO. The distance (number of hops) between thehub’s location, the VPN server’s location, and the IoT server’slocation contributes to the additional delay with the SFO serveras confirmed by supplemental traceroute data. An averageprocessing delay of 250.02ms for the hub server to notifythe phone server to notify the mobile app is more significantthan the networking delay from the VPN. Additionally, thetime between the hub sending a notification to the server andthe phone receiving the corresponding message is variable.This round trip time varies between 250ms and 364ms, witha standard deviation of 43ms.

2) Mobile Presence Spoofing: While the VPN allows thehub or mobile device to take on the IP address of the VPNserver, the mobile app may still reveal details about the user’slocation. The phone can act as a mobile presence sensorusing the phone’s GPS to trigger notifications as the devicetraverses a geofence as shown in Fig. 5(a). We used the FakeGPS location app by Lexa [8] to spoof the location of ourAndroidTM device7. The fake GPS location in Fig. 5(b) wasoffset by one mile just outside of the geofence; the blue dot inFig. 5(c) represents the new, spoofed location outside of thegeofence in the SmartThings app. While using a fake location,the sensor reporting continued as expected and conditionalactions/alerts were completed based on the spoofed location.

6Our test case is particularly troublesome because the IP address movedfrom New York to San Francisco.

7Android is a trademark of Google Inc.

(a) Geofence with true GPS location (b) GPS spoofing with Fake GPS (c) Geofence with spoofed location

Fig. 5. 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 locationshown 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 anadversary, the timing and frequency of sensor events revealsinformation about a user’s private behavior and daily patterns.We explored three classes of techniques to manipulate eventsreported to the hub server in order to create a false view ofdata leaving the network including delaying events, insertingevents, and dropping events. The techniques described arepossible because the web client reports the time that thenotification was received at the server, not the time it wasgenerated at the hub.

To disrupt the network and manipulate the timing of eventsby delaying them, we explored the set of firewall rulessummarized in Table I. The experiments using the first rule,Drop TCP, are described in detail below. The other rules delayor block event reporting as noted in the “Result” column. Theremaining tests were executed and their results are summarizedin the table. Any combination of these firewall rules canbe automatically enabled/disabled with a script to introducerandomness into a user’s pattern of life profile.

1) Baseline Event Reporting: In order to understand theimpact of our firewall rules, we created a baseline experimentusing the open/close sensor. Open/close testing was performedby manually “opening and closing” the SmartSense open/closesensor at 30 second intervals. The experimental procedure wasidentical for tests with and without the VPN connections. Foreach test the sensor started in the closed position, then wasopened after 30 seconds and finally closed after another 30seconds. Before the sensor was closed or opened, a single pingwas sent to the hub and if applicable the VPN server to providea marker in the data. The initial TTL of the ping packet was50 for the open event and 100 for the closed event. The eventnotifications plotted in Fig. 6 (allow TCP) were displayed tothe user via web client or phone app approximately every 30

Fig. 6. The open/close sensor is triggered every 30 seconds. When the firewallrule is disabled, the event notifications reach the server. Otherwise, a portionof the notifications reach the server at 668s once TCP traffic is allowed.

seconds as expected.Given the SSL encryption, the packets for an open/close

trigger are indistinguishable. From the location of the pingpackets, we can infer that event notifications from the hub areof length 109 bytes as shown in packets 5 and 17 which followthe pings in packets 3 and 13 of Fig. 2. Whether intentional ornot, the design of the hub messages to the server prevented usfrom selectively manipulating traffic by device type since thepackets looked the same for the sensors considered. Ultimately,we were able to disrupt the home automation network andeffect the communication between the client and server asdiscussed in the remainder of this section.

2) Delaying Events: To evaluate the performance of thesystem when communications between the hub and hub serverwere disrupted, we used a modified version of the open/closetesting procedure. This test began with an open event followedby a close event after 30 seconds. Next the “Drop TCP”

TABLE ISUMMARY OF FIREWALL RULES USED TO DISRUPT THE HOME AUTOMATION NETWORK.

Description Firewall Rule Result

Drop TCP iptables -I FORWARD 2 -i eth0 -o tun0 -p tcp -j DROP Hub drops SSL connection with server

Drop SSL iptables -I FORWARD 2 -i eth0 -o tun0 -p tcp –dport 443 -j DROP SSL connection closes. Hub tries to re-establish TCP connection

Drop Size 109 iptables -I FORWARD 2 -i eth0 -o tun0 -p tcp -m length –length 109 -j DROP Delays notification until first retransmission

Drop Size 109-178 iptables -I FORWARD 2 -i eth0 -o tun0 -p tcp -m length –length 109:178 -j DROP Delays notification until second retransmission

Drop Size 109-300 iptables -I FORWARD 2 -i eth0 -o tun0 -p tcp -m length –length 109:300 -j DROP Blocks notifications until rule is disabled

Drop Size 109-300,Allow Size 254

iptables -I FORWARD 2 -i eth0 -o tun0 -p tcp -m length –length 109:300 -j DROPiptables -I FORWARD 2 -i eth0 -o tun0 -p tcp -m length –length 254 -j ACCEPT

Blocks all notifications and periodically re-establishes SSL connection with server

firewall rule was used to drop all TCP packets between thehub and the hub server. We then performed the open/closetesting procedure. After ten iterations, the blocking firewallrule was deleted. Pings were used to mark the open and closeevents as well as the creation and deletion of the firewall rule.

Once the rule was removed, a portion of the event noti-fications in Fig. 6 (drop TCP) were received at the serverwith timestamps reflecting the approximate time the rule wasremoved. As a result of delayed event reporting, conditionalactions are also delayed. For example, we enabled an IFTTTrecipe to place a phone call when the door sensor is triggeredas shown in Fig. 7. Following the door opening, the recipe didnot trigger until the event was reported at the server.

Fig. 7. Delayed event reporting delays conditional actions like this IFTTTrecipe set to trigger a phone call if the door opens.

3) Inserting Events: Delaying events can certainly confusean adversary and artificially creating events can further con-tribute to the perceived activity in a home. In order to triggerthe motion and open/close sensor, we assembled a LEGO R©MINDSTORMS R© robot8 and programmed it to periodicallytrigger the sensors. A photo of our setup is shown in Fig. 8.

8LEGO R© and MINDSTORMS R© are trademarks of the LEGO R© Group.c©2012 The LEGO R© Group.

By filtering the false events at the application level, a usercan reconstruct true behavior while potentially confusing athird party consuming all of the data. Programmatically, butrandomly triggering sensors can hamper the pattern of lifeanalysis. A more complex robot can move from room to roomand cause events to be triggered such as turning lights on andoff. Open/close sensors can be placed where the robot can openand close a door labeled as “Back Door”, when the house doesnot have a back door. These deception techniques will likelyprevent an outside observer from determining if the house isoccupied. The user will know to ignore certain sensors.

Fig. 8. Experimental setup of LEGO R© MINDSTORMS R© for artificiallytriggering the open/close and motion sensors.

4) Dropping Events: Another technique considered is drop-ping TCP packets until the hub’s buffer fills. Reducing eventsduring a period of time can lead to incorrect inferences aboutuser activity. Supressing events could be done by droppingTCP packets for an extended period of time while true sensorreadings build up or by inserting enough synthetic events untilthe buffer’s queue overflows. The “Drop Size 109-300, AllowSize 254” firewall rule could be used to maintain intermittentconnectivity with the server. To an outside observer, thisbehavior could be attributed to connectivity problems withina user’s home network. While its applicability to privacypreservation is less interesting, this technique could be usedby an attacker to disrupt event reporting and prevent IFTTTactions from being performed.

IV. DISCUSSION

Our initial studies show that user data can be masked orselectively leaked and manipulated. By manipulating sensordata 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 causeunintended effects. In this work we just scratch the surface ofboth the challenges of fielding a secure and private IoT andthe potential solutions. In future work we will expand boththe cryptographic techniques to provide security and privacyand introduce new information manipulation techniques. Weare particularly interested in information leakage detection andcontrol in IoT networks.

In related work, [9] focuses on IoT privacy in RFID assettracking within the context of a legal framework, pointing outthe use of VPN, TLS, secure DNS, onion routing, and privateinformation retrieval to enhance privacy. The author discussesprivacy rights of an individual’s activity in addition to basicpersonally identifiable information (PII).

The adoption of IoT technology may ultimately be driven bythe consumer’s willingness to tradeoff utility and privacy. Inthis paper we explore the mechanisms to manipulate informa-tion to effect this tradeoff. In future work we will quantify theamount of information manipulation that is possible and thetradeoffs between increasing attack difficulty and decreasingIoT network utility and performance. By creating a falsebaseline of home activity we impact the statistics used bythe provider to secure the service. Selectively inserted eventscan be removed at the user application but are more difficultto remove from analytics results performed at a remote datacenter. We are exploring more complex interactions betweeninserted sensor events and analytics and how analytics resultscan be inverted to remove inserted events. The work in [10]provides an approach to identify the sensitivity of smart metersensor readings using statistical methods. They use mutualinformation to quantify the level of privacy in a dataset.

Energy is another dimension in evaluating IoT securityand/or privacy tradeoffs, as reviewed in [11]. With respectto our work in this paper, by introducing additional, artificialevents, the sensors must perform additional energy-consumingtransmissions. However, many IoT devices are designed touse low-energy sensors [11]. As we extend our work, wewill consider the performance implications of our privacypreserving techniques with respect to multiple objectives asin [12], including energy consumption.

An important contribution to security and privacy issues inIoT networks is the extent of information distribution. Securityand privacy may be improved by providing more localizedinformation exchange. In [13], the authors explore thesechallenges with respect to centralized and distributed servicesarchitectures, providing both strengths and limitations of thealternative approaches. Overlays for exchanging informationlocally have also been explored in work on content-centricnetworking [14].

V. CONCLUSION

We have provided an initial study of the risks to securityand privacy of IoT networks, focusing on home automationnetworks. Our studies have focused primarily on privacypreservation. Preserving privacy is key to achieving the po-tential of billions of connected devices and analytics, such as

providing smart home technologies to save energy and improvehome security. We provide a blueprint for inexpensive studyof IoT security and privacy using COTS products and services.These inexpensive testbeds can provide insight into other IoTapplications. We demonstrate that both simple cryptographictechniques and information manipulation can be employed toprotect a user against an adversary inside the IoT network oran adversary that has compromised remote servers. We showthe utility of proxying IoT network data through VPN overlaynetworks. This can become a generic service to IoT users,analogous to Web browsing anonymity provided by Tor.

Automated fingerprinting and characterization is anothertechnique to help improve the security and privacy of IoTnetworks. Many of our initial observations from experimen-tation can be applied toward fingerprinting IoT networks anddevices. In particular, we observed the initial connection set-up, firmware update messages, and periodic status updates, allof which can apply to developing a fingerprint. In future workwe will tackle network and device characterization techniquesfor IoT architectures. Similarly, our analysis techniques canbe extended to perform protocol reverse engineering and vul-nerability analysis of IoT architectures, using only passivelycaptured binary traffic.

REFERENCES

[1] D. Evans, “The Internet of Things – How the Next Evolution of theInternet is Changing Everything,” Cisco Internet Business SolutionsGroup (IBSG), April, 2011.

[2] P. C. Evans and M. Annunziata, “General Electric: Industrial Internet,Pushing the Boundaries of Minds and Machines,” November, 2012.

[3] L. H. Newman, “Pretty Much Every Smart Home Device You CanThink of Has Been Hacked,” Slate Future Tense Blog, Decem-ber, 2014. Web. http://www.slate.com/blogs/future tense/2014/12/30/theinternet of things is a long way from being secure.html

[4] J. Hagins, ”Security Announcement from SmartThings.” SmartThingsCommunity. 9 Feb. 2015. Web. http://community.smartthings.com/t/security-announcement-from-smartthings/10950

[5] “SmartThings SSL Certificate Validation Vulnerability.” Gotham DigitalScience. GDS Blog. 4 Mar. 2015. Web. http://blog.gdssecurity.com/labs/2015/3/4/smartthings-ssl-certificate-validation-vulnerability.html

[6] “How to Install OpenVPN Access Server onUbuntu 12.04.” Tutorials, Digital Ocean Community,Web. https://www.digitalocean.com/community/tutorials/how-to-install-openvpn-access-server-on-ubuntu-12-04

[7] “Router.” Ubuntu Documentation. Ubuntu Community Help Wiki, 5 Jul.2014. Web. https://help.ubuntu.com/community/Router

[8] “Fake GPS location.” Google Play. Lexa, Web. https://play.google.com/store/apps/details?id=com.lexa.fakegps

[9] R. H. Weber, “Internet of Things: New Security and Privacy Challenges,”Computer Law & Security Review, vol. 26, no. 1, pp. 23-30, 2010.

[10] A. Ukil, S. Bandyopadhyay, and A. Pal, “IoT-Privacy: To Be Private OrNot To Be Private,” Proceedings of IEEE INFOCOM Workshops, 2014.

[11] W. Trappe, R. Howard, and R. S. Moore, “Low-Energy Security: Limitsand Opportunities in the Internet of Things,” IEEE Security & Privacy,vol. 13, no. 1, pp. 14-21, 2015.

[12] K. Jaffres-Runser, M.R. Schurgot, Q. Wang, C. Comaniciu, and J-M. Gorce, “A Cross-layer Framework for Multiobjective PerformanceEvaluation of Wireless Ad Hoc Networks,” Ad Hoc Networks, vol. 11,no. 8, pp. 2147-2171, 2013.

[13] R. Roman, J. Zhou, and J. Lopez, “On the Features and Challengesof Security and Privacy in Distributed Internet of Things,” ComputerNetworks, vol. 57, Elsevier, pp. 2266-2279, July 2013.

[14] M. Schurgot, J. Esteban, L. Greenwald, Y. Guo, M. Smith, D. Stott, M.Varvello, and L. Wang, “Providing Local Content Discovery and Sharingin Mobile Tactical Networks,” Military Communications Conference(MILCOM) 2013, San Diego, CA, November 2013.