1. HanGuard: SDN-driven Protection of Smart Home WiFi Devices from Malicious Mobile Apps
Good morning. My name is Soteris Demetriou and I am a PhD student at the University of Illinois at Urbana-Champaign. Today I will present our solution for vulnerable WiFi smart home devices. This is joined work with Nan Zhang, Yeonjoon Lee and Xiaofeng Wang from Indiana University, Bloomington, and Xiaoyong Zhou and Michael Grace from Samsung Research America.
Soteris Demetriou 🔵, Nan Zhang 🔴, Yeonjoon Lee 🔴, XiaoFeng Wang 🔴, Carl A. Gunter 🔵, Xiaoyong Zhou 🔸, Michael Grace 🔸 🔵 🔴 🔸

2. $79 Billion smart-home industry (2014)
Billion devices
Cisco estimates that Billion devices will be Internet connected by 2020
$1.7 Trillion
IDC estimates that global spending on IoT devices and services will rise to $1.7 Trillion by 2020
The Internet of Things is an important topic of study.
In fact, Cisco estimates that by 2020 at least 50 billion devices will be Internet connected. The smart-home industry on its own generated $79 Billion dollars in 2014, while estimations predict a market of 1.7 Trillion dollars focusing on IoT devices and services.
Unfortunately, the plethora of available devices and their increasing penetration to the general public in tandem with the monetary worth of this ecosystem, attracts not only businesses and entrepreneurs but also adversaries.
$79 Billion smart-home industry (2014)

4. In our work we studied the communication between WiFi smart home devices and their control. Here is a typical scenario of a modern home automation system: devices use WiFi to connect to the router and then to the smartphone or cloud.
For the convenience of management, such interconnected IoT equipment often relies on the secure connections of HAN (Wi-Fi authentication) for protection and trusts all the computing systems on the same network. This treatment, however, completely exposes the device to the attacks from compromised local systems, a threat becoming increasingly realistic.

5. Weak/No App-Level Authentication Hardcoded Credentials
To make things worse, most of the consumer home automation devices have a small form factor and development is driven by time to market business requirements.
This leads to bad security practices such as hardcoding credentials in the devices’ firmware.

6. As a proof of concept, we have performed attacks that exploit similar vulnerabilities on 4 real world devices, including switches, motion sensors and multipurpose devices.
Given the millions of such devices already sold and installed, and historical evidence of bad security practices, a practical solution needs to be independent of device manufacturers and application developers.
INSECURE

7. HanGuard: SDN-driven protection of WiFi smart home devices
Towards this end we designed HanFence.
HanGuard: SDN-driven protection of WiFi smart home devices
HanGuard

8. Design Requirements Backward Compatible
independent from device manufacturers
independent from application developers
use of existing infrastructure
Practical
no hardware requirements
no smartphone OS modifications
Backward Compatible
independent from device manufacturers
independent from
Practical

9. Adversary Model

10. Consider the following scenario
Consider the following scenario. This WiFi smart switch can be installed in a home area network and can be controlled by its respective mobile application. The app sends a command which the router delivers to the switch. In response the switch turns on.
However, this switch assumes that if a device is authenticated to the home area network then it should be trusted. This allows, any smartphone - could be the one of a guest - to control it. Things become even more problematic when a malicious app is installed on an authorized device. Once an authenticated phone also carries malware (even when the app has nothing but the network privilege), protecting the device it controls becomes impossible at the network level, as the phone is completely legitimate to access the device though the malicious app running on it is not.

11. High-Level Approach

12. Controller Router Monitors Drivers Domain: Cameras Domain: Lights
LEGEND
ROLE 1
ROLE 2
ROLE 3
ROLE M
ROLE Guest
control channel
Monitors
MCN
data channel
SCN 1
SCN 2
SCN n
Admin Role
WPA2 key
Enforcement
Hook
Category tags
Controller
Flow Table
Domain: Cameras
Domain: Lights
Drivers
Router

13. > 95% Mobile OS Marketshare
iotlist.co
Monitor
> 95% Mobile OS Marketshare

14. Setting The Policies

16. Scenarios Remote Adversary [full cone NAT] - Not covered here
Device-level adversary [network partition] - Not covered here
App-level adversary

17. Example: Authorized app on authorized phone
To help me illustrate some of the functions of HanGuard I will use as an example an access request from a mobile apps. To the interest of time I will focus on the application level decisions and enforcement.
Firstly lets look at a legitimate scenario, where an authorized application on an authorized user phone, attempts to access an IoT device.
Example: Authorized app on authorized phone

18. Control Channel Data Channel Control Packet Data Packet App Monitor
User-space
As mentioned before, the Monitor app on the user’s phone detects the application responsible for initiating a flow to the target IoT device. Here I will focus on the Android Monitor internals since it is more interesting. I will just say that on iOS we utilized a VPN API available to third-party apps to trap all network traffic to the HanGuard Monitor.
On Android, we utilized side channels to detect benign flows. This allowed us to minimize performance overheads.
In particular, when when app generates network traffic, the network-related kernel data structures are mirrored in the process virtual file system. Our Monitor app continuously observes flow information in the procfs to identify the apps responsible for the flows.
The data flows remain unhindered whereas security information are forwarded to the router through the control channel.
Kernel
/net/tcp
Virtual File System
/net/tcp6
TCP
Transport Layer IP
Protocol Layer
WiFi
Drivers

19. Controller Worker Thread
Control Channel
Data Channel
Flow ID #
Control Packet
Data Packet
Flow Rule
Controller Interface #
Userspace
Kernel
Controller Worker Thread #
Flow
Table
Device-Level
Policy Base ?

20. Controller Worker Thread
Control Channel
Data Channel
Flow ID #
Control Packet
Data Packet
Flow Rule
Controller Interface
Userspace
Kernel
Controller Worker Thread #
Flow
Table
Device-Level
Policy Base ?

21. Example: Unauthorized app on authorized phone

22. Control Channel Data Channel Control Packet Data Packet App Monitor
User-space
On Android, we utilized side channels to detect benign flows. This allowed us to minimize performance overheads.
In particular, when when app generates TCP or UDP traffic, the network-related kernel data structures are mirrored in the process virtual file system. Our Monitor app continuously observes flow information in the procfs to identify the apps responsible for the flows.
The data flows remain unhindered whereas security information are forwarded to the router through the control channel.
Clearly, the data and control flows traverse the network stack once in contrast with the iOS approach which require two passes.
Kernel
/net/tcp
Virtual File System
/net/tcp6
TCP
Transport Layer IP
Protocol Layer
WiFi
Drivers

23. Controller Worker Thread
Control Channel
Data Channel
Control Packet
Data Packet
Controller Interface
Userspace
Kernel
Controller Worker Thread
Flow
Table
Device-Level
Policy Base ?

24. Evaluation

25. Evaluation: effectiveness
VANILLA
HANGUARD
Phone-Level
App-Level
WeMo Switch ✓ ✗
WeMo Motion
WeMo Insight
N3rd

26. Battery Consumption Trepn Power Profiler by Qualcomm
Our approach on Android requires continuous polling of the procfs we evaluate the battery consumption on the phone.
On the same Nexus 5 phone, we also ran Trepn [68] by Qualcomm to collect the baseline power profile of the phone for 30 seconds before running our Monitor app for 2 minutes.
We tried two approaches. The HanGuard Simple approach polls the files every 10ms, opens and reads from them. The HanGuard Smarter approach also polls every 10ms but it doesn’t open the file unless it has been modified since the last check (last modified time - mtime).
The simple one incur similar consumption with a popular antivirus program in scanning mode, while the smarter one was less than Gmail in idle mode (an optimized service which is always running).
On iOS we used Xcode's Instruments tool Energy Use Level which was given to be 0 out of 20. The value observed was consistently 0. This can be explained since we used a feature offered by the platform and as such is optimized by the platform developers.

27. x10 Vanilla HanGuard ( ) TCP APP Throughput 20MB
In terms of Throughput, we use a custom app to transmit a file of 20MB to its server counterpart on the same network. This was repeated 10 times.
We found no significant drop in throughput. This is expected as the data plane is untouched on the phone and the checks at the router are minimized.
TCP APP
20MB
x10
Vanilla

28. Throughput
In terms of Throughput, we use a custom app to transmit a file of 20MB to its server counterpart on the same network. This was repeated 10 times.
We found no significant drop in throughput. This is expected as the data plane is untouched on the phone and the checks at the router are minimized.

29. Summary
Designed a system to control access to WiFi smart home devices.
Achieves application - level access control without client OS modifications.
Backward Compatible
Implementation on a commodity router and both iOS and Android (>95% of mobile OSs)
HanGuard

30. Thank You! HanGuard Soteris Demetriou | sdemetr2@illinois.edu
I sincerely hope this triggered your interest in reading our work. You can find Pluto’s source code and the full set of our evaluation results online.
With this I conclude my presentation and I would be more than happy to address any questions you might have.
Project Website:
HanGuard