Conference PaperPDF Available

HOMESCAN: Scrutinizing Implementations of Smart Home Integrations

Authors:
Conference Paper

HOMESCAN: Scrutinizing Implementations of Smart Home Integrations

HOMESCAN: Scrutinizing Implementations of
Smart Home Integrations
Kulani Mahadewa, Kailong Wang, Guangdong Bai, Ling Shi, Jin Song Dong∗† and Zhenkai Liang
National University of Singapore, Griffith University
Abstract—A key feature of the booming smart home is the
integration of a wide assortment of technologies, including
various standards, proprietary communication protocols and
heterogeneous platforms. Due to customization, unsatisfied as-
sumptions and incompatibility in the integration, critical security
vulnerabilities are likely to be introduced by the integration.
Hence, this work addresses the security problems in smart
home systems from an integration perspective, as a complement
to numerous studies that focus on the analysis of individual
techniques. We propose HOMESCAN, an approach that examines
the security of the implementations of smart home systems. It
extracts the abstract specification of application-layer protocols
and internal behaviors of participants, so that it is able to conduct
an end-to-end security analysis against various attack models.
Applying HOMESCAN on three extensively-used smart home
systems, we have found twelve non-trivial security vulnerabilities,
which may lead to unauthorized remote control and credential
leakage.
I. INTRODUCTION
Enabled by the various intelligent Internet of Things (IoT)
techniques, the smart home paradigm has been significantly
changing the lifestyle of its users. New convenient facilities,
such as smart lighting systems, smart TVs and security alarm
systems, are becoming ubiquitous. Along with the booming
growth of smart home, security incidents have been continually
observed [1], [2]. Researchers have made efforts to address
security issues in smart home systems [3], [4], with focus on
several aspects, ranging from radio communications, network-
ing, operating systems, middleware, and protocols, to backend
cloud services.
In this work, we investigate security of smart home systems
from an integration perspective. Our motivation is out of such
a key observation—to realize a “smart” automated home, it is
essential that multiple subsystems are integrated. The controls
are typically initiated from the handheld devices such as smart
phones, transmitted over wireless channels such as Bluetooth,
ZigBee and Wi-Fi, forwarded by intermediate relays such as
gateways, and web-based service portals, and finally executed
by the end devices such as bulbs and locks. Due to the
involvement of such a wide assortment of technologies and
devices (usually from diverse manufacturers), it becomes chal-
lenging to coordinate them into a secure system. The challenge
may be attributed to at least the following two factors.
Incompatibility. Since diverse standards are enforced,
there may be incompatibilities among the subsystems.
For example, in the Philips Hue system that we have
analyzed, the authentication between the bulb and the
hub is through the Touchlink Commissioning (TLC) over
ZigBee, while that between the hub and the control app
is through a customized authentication over Wi-Fi. Once
these three are integrated, due to the incompatibility
between the two mechanisms, there is no way for the bulb
to authenticate the control app. This allows a malicious
app which has infected the mobile phone that the control
app is installed on to acquire control over the bulb.
Invalidated Assumptions. A developer or manufacturer
may make assumptions (e.g., trust relation, message for-
mat and correct sequence of API calls) when using the
interfaces provided by other parties. If the assumptions
are invalid, the interfaces may be used in an insecure way.
For example, in the same system above, the manufacturer
of the hub actually assumes the LAN is secure, whereas
this assumption may not be true if a malicious app has
been installed on the user’s mobile phone.
We present an approach named HOMESCAN, which scruti-
nizes security of the implementations of smart home systems.
It extracts the application-layer protocols and security-relevant
internal behaviors of each subsystem (or protocol participant)
from the implementations. Through this, it can derive a unified
abstraction of the end-to-end system to flatten the difference of
the protocols employed by each participant. The challenges yet
stem from the partial availability of the implementations. First,
the source code is seldom visible, although the executable
of the control app (from the app market), the firmware
extracted from devices, and SDKs provided by vendors, are
available for analysis. Second, the cryptographic protocols
are used among the participants, so that the communication
is blurred to us, even though we are able to capture the
exchanged traffic. To alleviate these challenges, HOMESCAN
uses a hybrid analysis including dynamic testing,whitebox
analysis and trace analysis. The dynamic testing executes
test cases, and captures communication traffic and execution
traces; the whitebox analysis identifies semantics by analyzing
the program that is available; the trace analysis infers the
association relation between a value of unknown semantics
and a participant, a session or a value whose semantics has
been identified.
HOMESCAN uses labeled transition systems (LTSs) [5] that
have been extensively used to model and reason various sys-
21
2018 23rd International Conference on Engineering of Complex Computer Systems (ICECCS)
978-1-5386-9341-4/18/$31.00 ©2018 IEEE
DOI 10.1109/ICECCS2018.2018.00011
tems to represent the extracted specification. An LTS describes
the execution of a particular participant, including its internal
behaviors (e.g., generating a nonce and validating a digital
signature) and communication behaviors (e.g., sending and
receiving a message). At this abstract level, the security rea-
soning can ignore the heterogeneity of underlying protocols,
but focus on the logic that is implemented by the system.
Using this abstraction, reasoning security properties of the
whole integration becomes effective, and we show that most
of the properties specific to the smart home systems can be
reduced to reachability checking.
It is obvious that obtaining the complete or sound specifi-
cation is almost infeasible. HOMESCAN focuses on extracting
as precise specification as possible, whereby it can identify
security issues. We prototype HOMESCAN and apply it to three
extensively-used smart home systems, including Philips Hue,
LIFX, and Chromecast. It manages to identify twelve security
vulnerabilities.
Contributions. To summarize, we make the following main
contributions in this paper.
Specification Extraction Techniques. We propose hy-
brid techniques to extract specifications from the imple-
mentations of the smart home systems. Our evaluation
of real-world systems demonstrates that the extracted
specification is precise enough to identify significant
security issues.
Vulnerability Identification Techniques. We have mod-
eled a set of practical attacks to facilitate the vulnerability
identification techniques based on LTS representations.
We reduce the vulnerability identification to traditional
reachability analysis on LTS.
Practical Results. We apply HOMESCAN to real-world
systems and successfully identify twelve non-trivial secu-
rity vulnerabilities from them. The supporting materials
are published online for future research [6].
II. BACKGROUND AND OVERVIEW
In this section, we brief typical specification of smart home
systems from the integration perspective, and provide an
overview on the security properties and attack models in the
vulnerability identification of smart home systems.
ZigBee
Smart Device (SD)
Control Point (CP) Hub
HTTP
Server
(HS)
ZigBee
RF Front-
End
(ZFE)
1
2
2
14
6
1
3
5
10
4
3
9
11 12
13
S1
S2
S3
(S1- Discovery Stage, S2-Authentication Stage, S3- Control Stage, -Broadcasting)
-
-
-
Wi-Fi
-
Fig. 1: A Smart Home System Containing a CP, Hub and a SD
A. Overview of a Smart Home System Specification
In order to facilitate our LTS construction, we abstract a
generic system architecture from several smart home systems
popular on the market, such as Samsung SmartThings [7]
and HomeGenie[8]. In our abstraction, a smart home system
consists of three subsystems, i.e., a control point (denoted
by CP) which interacts with the end users and issues the
controls, several smart devices (denoted by SD) which are
operable electronic end devices, and several relays (denoted
by hub) which bridge the communications. Covering from
configuration to control, the working procedure of the end-
to-end smart home system is divided into three stages, i.e.,
discovery,authentication and control.
Actions
Inferred Components
s1
SD *
BeaconRequest
ZFE *
PanID,
HubID, AssoPermit
SD *
DeviceID, PanID
1
CP *
UPnPMsearchRequest, CPIP
2
HS CP
CPIP, ServerName, HubIP, HubID
s2
3
CP HS
HubIP, nonce
4
HS CP
CPIP , hash(nonce)
5 CP HS
HubIP, hash(nonce), SearchLights
6
ZFE *
PanID, ScanRequest
7
SD ZFE
HubID,
ScanResponse
8
ZFE SD
DeviceID, {NetworkKey}
Kmaster
9
SD ZFE
HubID
, JoinSuccessResponse
10
HS CP
CPIP, SDJoinSuccess
s3
11 CP HS
HubIP, hash(nonce), Command
12
ZFE SD
DeviceID, {Command}
KNetworkKey
13
SD ZFE
HubID
, ACK
14
HS CP
CPIP, Success
1
2
3
S3
S1
S2
Fig. 2: Inferred Specification for the Ex-
ample in Fig. 1
In Fig. 1, we
show an example
of this architecture,
and its specification
which HOMESCAN
aims to extract is
listed in Fig. 2. In
this example, the
CP is an Android
app which supports
HTTP protocol over
Wi-Fi, and the SD
only supports the
ZigBee protocol.
Therefore, the hub
further includes an HTTP server (denoted by HS) and a ZigBee
front end (denoted by ZFE) to facilitate the communication
between the HTTP-based CP and ZigBee-based SD. In a
nutshell, the system works as follows.
Discovery Stage (denoted by S1in Fig. 1 and Fig. 2). The
CP searches for the hub and pairs with the HS (step x&
y). After searching existing ZigBee networks to join, the
SD discovers the network created by ZFE (step -).
Authentication Stage (denoted by S2). The CP and the
SD authenticate themselves to the hub. To this end, the
CP and the HS use a customized authentication (step z-
{), while the SD and the ZFE use the TLC of ZigBee
Light Link (ZLL) [9] profile (step }-) after the CP
requests the hub to find and connect SDs in the vicinity
(step |). Once the SD is authenticated by the ZFE, the
HS sends a success response to the CP (step ).
Control Stage (denoted by S3). The CP controls the
SD which is connected to the hub by sending control
commands to the HS (step 11
-14
). Once receiving a
command, the hub converts it to a ZigBee packet and
sends it to the SD; upon the ACK received at the ZFE,
the HS sends a success response to the CP.
B. Security Properties and Attack Models
Security Properties. Our approach analyzes the security
properties including data security (i.e., data confidentiality
and integrity), association security, and access security (i.e.,
authentication and authorization), given that various work has
shown the importance of these security properties to IoT [10],
[11], [12]. These properties are detailed in Table I.
Attack Models. The common threats to a smart home system
are unauthorized access, manipulation by malicious partici-
2
22
TABLE I: Security Properties
Property Security Property Description
Data
Security
The property ensures that the data transmitted in a
smart home system should be delivered to the intended
participants without being revealed or altered by the
unauthorized participants.
Associa
-tion
Security
The association between the user/device behaviors and
the corresponding encrypted messages should not be
revealed by exploiting meta data of the encrypted mes-
sages such as the packet size, the message source/des-
tination addresses, etc.
Access
Security
The property ensures that all participants in a smart
home system can verify the identities of their commu-
nicating participants, and only the authorized partici-
pants are granted access to services and information.
pants [13], [14], and vulnerable settings of wireless commu-
nications [15]. Hence, we consider both malicious participants
and network attackers, whose capabilities are described in
Table II. Malicious participants are able to sabotage the access
security properties by pretending to be honest ones to collect
information (e.g., identities of other participants and session
keys) illegally or send unauthorized commands to honest
participants. Network attackers are able to eavesdrop, intercept
and modify messages within the local network (e.g., Wi-Fi and
ZigBee) in which the attacker resides or over the Internet.
TABLE II: Attack Models and Capabilities
Attack
Model
Attack Capability Description
Malicious
Participa
-nts
Malicious CPs are able to manipulate victim hubs
and SDs over the same local network or Internet by
sending unauthorized commands.
Malicious hubs are able to manipulate the victim SDs
in the vicinity by sending unauthorized commands.
Malicious SDs are able to capture the sensitive infor-
mation (e.g., identity and address of the hub or CP)
and possibly even take control of the victim hubs and
other SDs in the vicinity.
Network
Attacker
Eavesdropping. The attacker is able to obtain crucial
information (e.g., session keys and the identity of the
hub) by eavesdropping.
Intercepting and Modifying Control Activities. The
attacker is able to manipulate the system behavior by
either replaying or modifying control commands such
as ON/OFF of SDs, casting a video and changing light
color.
Intercepting and Modifying Administration Activ-
ities. The attacker is able to replay or modify the
administrative commands such as device authentica-
tion/removal/reset, possibly causing functional disrup-
tion including Denial of Service.
III. HOMESCAN OVERVIEW AND PREREQUISITES
In this section, we present an overview of HOMESCAN.
A. HOMESCAN Overview
HOMESCAN uses a set of techniques for specification ex-
traction and vulnerability identification. It takes the following
inputs.
Implementation of the Smart Home System. A
runnable setup of the smart home system and a set of
programs (PS), including available source code, libraries,
and binaries of participants are input to the HOMESCAN.
Test Cases. A set of test cases (TC) is required to trigger
the functionality of the smart home and at least one test
case is required to initialize trace capturing component.
A test case should include steps to discover, authenticate
and control of the system. Each test case corresponds to
a configuration of the system. Configurations refer to the
participants (e.g., CP, SD and hub) of the system and the
different users (e.g., admin, general user and guest).
Initial Knowledge. Initial knowledge (IK) is represented
as a 3-tuple (P,CH,KV ), where Pis the set of partici-
pants of the input system; CH is the set of channels used
for communication among participants; KV is the set of
knowledge required to execute the TC.
As shown in Fig. 3, HOMESCAN includes three major
components including trace capturing and pre-processing,
specification extraction and flaw identification.
HTTP
Dynamic Analysis Tools
¬& Snifng Hardware
Implementation
Initial Knowledge
Test Cases (TC)
ZigBee
Wi-Fi
BLE
Other
Arrange
Traces
Extract Values
Input
Trace Capturing & Pre-processing
Traces
TRSet
¬& EL
Exhaustive Search
Type Propergation
Whitebox
Diff Analysis
PI List
LTS
List
Security
Properties
Attack
Models
Specication Extraction
Vulnerabilites
Flaw Identication
Output
Security
¬Analyst
race
s
mutation
updateTRSet ¬TC.next 1
2
1
3
1
Fig. 3: Overview of HOMESCAN
Trace Capturing. The first step of the HOMESCAN is to
capture the trace of the system under analysis by executing
the initial test case. It captures two types of traces, i.e., traffic
traces and execution logs. HOMESCAN uses existing sniffers
to capture the traffic traces, and records the execution of
the participants, whenever instrumentation can be done. In
addition, HOMESCAN generates new traces by mutating the
values (e.g., HTTP header values or HTTP parameters) from
the captured traces, after executing each test case.
Pre-Processing. Pre-processing takes the set of captured traces
as input and aims to generate a set of transactions (defined
soon). A captured trace is a sequence of messages, contain-
ing the exchanged data between two or more participants.
HOMESCAN first merges the traces in chronological order
and then extracts the values from the traces. Based on the
underlying protocols, HOMESCAN extracts data referring to
their standard message formats. The extraction is done using
keyword (e.g.,“host” in an HTTP request) searching, pattern
matching and string splitting with delimiters (e.g.,“&”).
Specification Extraction. The objective of this step is to gen-
erate LTS representation of the system, given the transactions
generated from the pre-processing component. We propose a
3
23
hybrid extraction technique including whitebox analysis and
trace analysis for the specification extraction. The extracted
specification is represented by LTS. In Section IV, we detail
the specification extraction component.
Flaw Identification. In this step, we propose a verification
algorithm to check IoT-specific security properties of the LTS
representation against predefined attack models. Essentially,
the verification algorithm is a reachability analysis. It can
apply any of classic searching algorithms (e.g., DFS and BFS)
on the generated LTS to search the reachability of a bad state
wherein the security property is violated. In Section V, we
detail our verification algorithm.
B. Prerequisites
In order to bridge the semantic gap between the low-level
traces and the high-level LTS, we introduce several interme-
diate data structures to maintain the information required to
generate an LTS.
Transactions. A transaction (TR) is a preliminary abstraction
of one round of information exchange. We represent it as
a 5-tuple (id,se,R,EVSet,BR), where id is the transaction
ID, se Pis the sender, RPis the set of receivers,
and EVSet ={EV1,EV2, ..., EVα}is the set of values (total
number α) extracted from the message exchanged in the TR.
Each EViis a 3-tuple (v,t,id)where vis the value, tis its type,
and id is the value ID. The transaction also includes branch
information (BR), which is defined soon.
To represent the output of the pre-processing component,
we propose a transaction set denoted by TRSet ={TR1,
TR2, ..., TRβ}where βis the total number of transactions.
Additionally, the ordered execution logs are output as a
sequence EL.
Branch Information. Each transaction TR includes a branch
set (denoted by BR), which is a set of transaction IDs that rep-
resent the transactions branching from the current transaction.
There are three types of branches, i.e., options, self-recursions,
and sequence-recursions. An option branch is either labeled as
an option in the test case, resulted from test case mutation or
resulted from configuration changes. HOMESCAN identifies
self-recursions or sequence-recursions when data of a single
transaction or data of a sequence of transactions are repeated
in the trace respectively.
Types. For each extracted value EV EVSeti(1 iβ),
HOMESCAN attempts to identify a type (t) during the specifi-
cation extraction. HOMESCAN defines two categories of types,
i.e., primitive and domain-specific. The primitive type can be
an integer, boolean, or string. The domain-specific type can
be any of network address (used in ZigBee-like protocols), IP
address, MAC address, username, password, encryption key,
etc. During pre-processing, HOMESCAN assigns a primitive
type to EV.tand updates it to a domain-specific type (which
is more precise) when more information is inferred.
The domain-specific types are formalized as terms (denoted
by T). Terms are categorized into three subsets, i.e., Constants
(denoted by C), Functions (denoted by F), and Variables
(denoted by V), such that T=CFV. Ground terms are
TABLE III: Function Terms
Function
Term (F)
Definitions Meaning
senc(msg,k)msg T; symmetric key kTciphertext
hash(msg)msg Thash value
terms that only contain constants and functions. Variables are
terms that are not ground. Table III lists part of the Functions
terms use by HOMESCAN, and the full list is included in the
technical report [6].
Actions. A label of an LTS is an action which can be either a
communication or a local action. The actions which send and
receive messages with other participants are communication
actions, and the actions that execute local behaviors of each
participant are local actions. Table IV lists several actions used
by HOMESCAN.
TABLE IV: Communication and Local Actions
Type Action Definitions Meaning
Comm. send(ch,msg)ch C;msg Tsending a message
via channel ch
receive(ch,x)ch C;xVreceiving a message
and storing in x
Local newnonce(x)variable xVgenerating a nonce
and storing in x
newskey(x)variable xVgenerating & storing
a symmetry key
Protocol Information. Protocol Information (denoted by PI)
is defined during the specification extraction. A PI is a 5-tuple
(msg,ACSeq,ch,lc,BR), where PI.msg is a concatenation of
terms representing the message transmitted by the correspond-
ing TR, and PI.ACSeq =AC1,AC2, ..., ACγis a sequence of
action information where γis the total number of actions. An
action information ACiis a 3-tuple (u,a,X)where u(P)is
the participant who performed the action, ais the name of
action and Xis a set of terms taken as parameters to a.PI.ch
is the communication channel. Further, if the message PI.msg
needs to be transmitted between two sub-components within
a device, which acts on different protocols, the algorithm
introduces local communication actions (e.g., between HS and
ZFE of hub shown by the broken lines in Fig.1). PI.lc Pis
the receiver (lc ∈ TR.R) when local communication between
two sub-components exists. PI.BR is the branch information.
Parameterized Labeled Transition System. A traditional
labeled transition system (LTS) is a 4-tuple L=(S,s0,A,)
where Sis a set of states (locations); s0Sis the initial state;
Ais a set of actions; →⊆ S×A×Sis a labeled transition
relation. We extend the LTS with parameters to differentiate
the instances of the same behavior pattern to facilitate the
attacker modeling. For example, we use the parameter HubID
to represent the identity of the malicious hub compared with
the HubID for the benign hub.
IV. SPECIFICATION EXTRACTION
The goal of specification extraction is to generate a rep-
resentation of system integration. One challenge that can
be foreseen is the gap between the execution traces (to be
precise, the transactions after pre-processing) and the target
LTS. To bridge the gap, we design a two-step extraction
4
24
input : (TRSet,PS,EL,IK,TC)
output: A List PIL =[PI1,PI2, ..., PIδ]where δ=β; Each
transaction in TRSet is mapped to a PI.
1F={f1,f2, ..., fη}where ηis the number of selected hash,
cryptography and encoding/decoding functions.;
2g:GEVSet ×P(TRSet)is relation indicates the transactions which a
value appears.;
3TRSetnew TRSet,TRSetold TRSet;
4do
5TRSet TRSetnew;
6GEVSet =EVSeti(1 iβ)// global set of EVSet.;
7gGrouping(TRSet);
8GEVSet WB(GEVSet,PS,EL,IK);
9PIL Propagation(GEVSet,g);
10 GEVSet ES(GEVSet,F,IK);
11 PIL Propagation(GEVSet,g);
12 GEVSet DA(GEVSet,PIL,TRSet,TRSetold ,IK);
13 PIL Propagation(GEVSet,g);
14 TRSetold TRSet;
15 TRSetnew updateTRSet(TC.next);
16 while TRSetnew =TRSet;
17 return PIL;
Algorithm 1: PI Inference Algorithm
approach, which first extracts PIs from the transactions, and
then transforms the PIs into LTS representations.
A. Inference of Protocol Information
Given the transactions generated from trace processing,
HOMESCAN uses several analysis techniques to infer the PIs
using Algorithm 1. It takes a 5-tuple (TRSet,PS,EL,IK,TC)
as input, where TRSet is the set of transactions; PS is the set
of programs; EL is the set of execution logs; IK is the set
of initial knowledge; TC is the set of test cases. The output
of the algorithm is a list of inferred PI (PIL), each of which
correlates with one transaction. The algorithm executes the
next test case (TC.next at line 15) and iteratively identifies
new semantics until no new information can be found from the
input resources. In each next iteration, the TRSetnew includes
new values and new branch information (BR) corresponding to
the new configuration specified in the TC.next.H
OMESCAN
infers the types of new values using the techniques we detail
in the remaining of this section.
Whitebox Analysis.H
OMESCAN uses WB(GEVSet,PS,
EL,IK)(line 8) to infer each extracted value EV.vof trans-
action TR. It identifies type information of a value EV.v
GEVSet and related local behaviors, and branch information
by analyzing how vis generated or processed in the given
program (PS).
First, HOMESCAN identifies the code snippet for analysis
from the input PS. It uses the following two approaches for
code snippet identification.
If the source code is runnable, HOMESCAN logs API calls
which send or receive the message of transaction TR (e.g.,
execute() of DefaultHttpClient.class with
Java API of Apache) in the program.
If only the executable files are available, HOMESCAN
recovers the code using off-the-shelf reverse-engineering
tools. Next, it scans the recovered code for existence of
strings against a dictionary of strings. This dictionary is
constructed with the extracted strings from the network
trace corresponding to the message of TR.H
OMESCAN
confirms the code snippet by instrumenting the recovered
code to obtain dynamic debug information, while execut-
ing the test case which triggers TR.
Next, HOMESCAN identifies associations among vari-
ables in the code snippet, for type information recog-
nition of v. To this end, it uses data flow analysis
techniques, including both backward and forward flow
analysis. HOMESCAN assigns Constant terms to vif
it is associated with a constant given as prior knowl-
edge (e.g., IP address, cryptographic key) in the program.
pp
POST /
api HTTP/1.1
Host:
http://192.168.0.100/
mytag
=s23490..fauisdf
private static String DEVICE_ID = “s23490..f”;
public class Test {
public static void send (){
String x = DEVICE_ID;
String value = genValue(x);
params.setParameter(“mytag”,value);
request.setParams(params);
httpClient.execute(request);
}private static String genValue(String s) {
Random noGen = new Random( );
String randomString = no Gen.nextString();
return s + randomString; }}
Dst
: 192.168.0.101 HTTP/1.1 200 OK
Content
-type: application/json
{"success",{“
token":"
ebb66d40a4817244594866
2e2840fc3fb70767f0
"}}
A
3
4
Fig. 4: Part of Captured HTTP Traces
and Part of CP Source Code for the
System in Fig.1
It assigns Variable
terms if vis associated
with a random value
identified by the use of
corresponding API (e.g.,
java.util.Random)
calls. HOMESCAN
assigns Function terms
if vis associated
with values generated
by security sensitive
functions (e.g.,
encryption, decryption
and signature) which
are identified by the
cryptographic API (e.g.,
javax.crypto.KeyGenerator) calls. In addition,
HOMESCAN records local actions related to the generation or
processing of the value v. For example, if a new symmetric
encryption key is generated, HOMESCAN records a local
action newskey(x)(listed in Table IV). For example, consider
the message 3
in Fig. 4, which is transmitted by TR 3
in
Fig. 2, and generated by the code snippet Alisted in Fig. 4. The
TR3=(3,CP,HS,{(s23490..fauisdf ,String,0)},)has one
extracted value (EV1), which is an HTTP request parameter.
HOMESCAN infers EV1.vas terms (DeviceID,nonce1).
The corresponding PI3is (msg=(DeviceID,nonce1),
ACSeq=(CP,newnonce,{nonce1}),(CP,send,{msg}),(HS,r-
ecieve,{msg}),ch=wifi,lc=,BR=).
HOMESCAN identifies the branch information resulted from
configuration changes in the smart home system. For example,
different privileges may be assigned to different user (e.g.,
general and guest users) or CP (e.g., mobile or desktop
app) configurations. With this approach, HOMESCAN uncovers
control flows (e.g., if-else and case-switch) in a given program,
and utilizes all input resources (e.g., mobile and desktop CP
source code) during PI inference. To formalize the configura-
tions, we assume the finite configuration set C={C1,C2, ..., Ci
, ..., Cλ}where λis the number of configurations that can be
changed (e.g., C={Cuser,CCP }where Cuser ={general,guest}
and CCP={mobile,desktop}). As an example, in the LIFX
system that we studied, the desktop app (CP) allows to control
the SD over SD’s open Wi-Fi hotspot whilst the mobile app
forces to setup the SD with the home Wi-Fi before starting the
5
25
control. Hence, HOMESCAN records the control (over open
Wi-Fi) and setup (with home Wi-Fi) actions as two option-
branches in the PI corresponding to the discovery success
transaction.
Exhaustive Search. HomeScan uses exhaustive search to
identify the type of a value with respect to a known function
applied on a subset of extracted values. Hence, in this search,
a finite set of existing functions are executed on all extracted
values to check whether the values of unknown types can be
generated. As shown in Algorithm 1, the GEVSet is input
into the ES(GEVSet,F,IK)with Fa set of existing func-
tions (e.g., MD5, SHA-1 and Base64) and IK. For example,
consider v=“ebb66d...0767f0” in our running example ({in
Fig. 4). HOMESCAN performs all the existing hash functions
on the values it has collected in GEVSet. Once it finds that
SHA1(nonce1)has the same value, it can infer that the type
of this value is a hash value over nonce1.
Differential Analysis.H
OMESCAN uses DA(GEVSet,PIL,
TRSet,TRSetold ,IK)to infer the types based on the associ-
ations from two categories of changes, i.e., configurations and
control commands. HOMESCAN identifies the association for
the difference of the vin TRSetold and TRSet for the value with
identity EV.id TR. Further, HOMESCAN triggers the trace
capturing component to re-execute a particular test case during
an analysis to assure the consistency of values EVSet TR.
Configuration Changes. In our generic architecture, the
configuration C={Chub,CSD ,CCP}is a set of participants.
Hence, for example, HOMESCAN can substitute the hub with
other hubs using the same interface (e.g., the communication
protocol), i.e., Chub={hub1,hub2, ..., hubμ}where μindicates
the number of the hubs under the control of HOMESCAN,to
check the difference of the target EV.vagainst the change
of the hub. For a value EV .vwhose domain-specific type is
unknown, HOMESCAN infers its type (t) as follows.
If Ciand EV.valways change together, then they are
likely correlated, e.g., HubID in the running example.
If EV.valways changes in every execution, then it is
likely a session-specific random nonce, e.g., nonce.
If EV.vkeeps constant, then it is likely a protocol-specific
value, e.g., UPnPMsearchRequest.
Control Command Changes. During the control stage, the
commands sent to the SD may be encrypted. HOMESCAN
exploits the association between the control commands and
the meta-data of the encrypted messages by using differential
analysis, to infer the types (e.g., ON/OFF/color-change com-
mand) of the encrypted messages. According to the connection
through which a control command can be sent to the SD,
HOMESCAN uses the following approaches to infer its type.
Persistent Connection. Typically, the heartbeats are re-
quired in order to maintain a persistent connection. In
this scenario, the packets including the commands may be
inundated by the heartbeat packets. To remove the packets
of the heartbeat from the trace, HOMESCAN captures
the packets when no command is issued by the CP, and
labels it as the heartbeat. This enables HOMESCAN to
input : PIL
output: A List LTSL =[LTS1,LTS2, ..., LTSσ]where σ=|P|.
Each participant in Pis mapped to an LTS
1for pPdo
2srcps0,dstpnull,LTSp=(srcp,{srcp},,);
3foreach PIqPIL do sq
pnull;
4end
5for PIqPIL do
6PIq.ACSeqCreateLCActions(PIq.msg,PIq.lc);
7uch UniqueCH(PIq.ch);
8for ac PIq.ACSeq do
9p=ac.u,lCreateLabel(ac,uch);
10 dstpGenState(ac);
11 if (sq
p=null)then srcpsq
p;
12 LTSp.ALTSp.A∨{
l},LTSp.SLTSp.S∨{
dstp};
13 LTSp.Tr LTSp.Tr ∨{
srcp,l,dstp};
14 srcpdstp,sq
pnull;
15 for TR.id BR do
16 if (q<TR.id)then sTR.id
pdstp;
17 else if (q=TR.id)then
18 LTSp.Tr LTSp.Tr ∨{
dstp,l,dstp};
19 else if (q>TR.id)then
20 exdstpGenState(AC1PITR.id .ACSeq);
21 LTSp.Tr LTSp.Tr ∨{
dstp,l,exdstp};
22 end
23 LTSL LTSp
24 end
25 end
26 return LTSL;
Algorithm 2: LTS Representation Algorithm
remove the heartbeat packets from the trace and infers
the remaining packets as the control command(s).
Non-persistent Connection. In non-persistent connection,
a handshake is often used to establish the connection
before a control command is sent. Therefore, given a trace
of control command execution, HOMESCAN identifies
the packets on the trace corresponding to three differ-
ent stages in a handshake based protocol (connection,
command, disconnection). To achieve this, HOMESCAN
reruns test cases for different control commands. The
packets common in all runs are considered to be relevant
to connection and disconnection stages. The remaining
packets are inferred as the command data packets.
Type Propagation.H
OMESCAN uses Propagation(GEVSet,
g)to propagate the type of a particular value to its other
occurrences. The rationale is that in security protocols, a data
item typically appears in multiple steps (as shown with red
arrows in Fig. 2). HOMESCAN exploits this feature to propa-
gate inferred information in different transactions. To do the
propagation, HOMESCAN generates groups GEVSet (line 4 in
Algorithm 1) to track all occurrences of each value throughout
all transactions. Later after each analysis, the updated GEVSet
and the groups are input to propagation component for the PI
generation.
B. LTS Generation
After extracting the PIs, HOMESCAN translates them into
the LTS representations. Algorithm 2 shows our approach. It
takes the PIL (output of Algorithm 1) as input and generates
a list of LTSs. It begins with initializing an LTSpfor each
participant pPwith the initial state (s0), the set of states
6
26
(S), the set of actions (A), and the set of transitions (Tr)in
a tuple (s0,{s0},,)(lines 1-4). Then it iterates through
the PIL and transforms each PI into LTS transitions. First, it
extends the PI.ACSeq, if a private communication exists (line
6). Next, it creates a unique channel (line 7) before creating an
action label (line 9). Once the source and destination states and
labels are created (lines 9-11), it updates the LTS components
of participant pidentified at line 9. If the PI has branch
information, it either records the source state of options (line
16), adds self-recursions (line 18), adds sequence-recursions,
or merges branches (lines 20-21). Below, we detail the LTS
generation.
States. A transition involves two states. Its source state is
denoted by srcp, while the destination state is denoted by dstp.
In addition, HOMESCAN uses state sq
pto track the srcpof a
branch, where qis the transaction ID (TR.id). The dstpis given
by the function GenState (line 10). If the input ac represents
a new action, GenState outputs a new dstp. If the action has
been mapped to a dstpby the function before, the function
outputs the existing dstp. Moreover, the srcpof the immediate
transition is the dstpof the current transition, when it is not a
branch (line 14).
Actions and Transitions. During the iterations through PIL,
the information in each PIqis used to create labels (actions).
The PIq.ACSeq states the action information with their se-
quence. The algorithm creates labels for actions in the stated
order (e.g., AC1,AC2,AC3,AC4where AC1and AC2are
local actions conducted by the sender, AC3=(se,send,msg)
is an action of message sending, and AC4=(riR,receive,
msg)is an action of message receiving). Further, HOMESCAN
uses the CreateLCActions function to add information of the
local sending and local receiving actions to PIq.ACSeq (e.g.,
PIq.ACSeq(riR,send,msg),(lc,receive,msg)(line 6).
Each label is created using the function CreateLabel (line
9). The input to the function, i.e., ac, has information about
action (aand X). If ac is a local action, then a∈{newnonce,
newkey,newkeypair,executeCommand}and XT.Ifac is a
communication action, then a∈{send,receive}and X=msg.
The input uch generated using the UniqueCH function is used
to send/receive the msg via a unique channel (line 7). If ac is
a local communication, then the CreateLabel function uses a
unique private channel to transmit the msg. Once the label and
the next state are ready, LTSpis updated such that srcp
l
dstp
is added (lines 12-13).
Branches. If the PIqincludes information about branches (rep-
resented by TR.id BR), it is analyzed from line 15 to line
22. Fig. 5 shows different types of branches in an LTS. If
TR.id of the branch is greater than that of the current PI,it
is an option. Hence, current dstpis tracked using sTR.id
p(line
16). After it is set, sTR.id
pis taken as the srcp(line 11) in
the next iteration. If the TR.id of the branch is the same as
that of PI, this branch is a self-recursion. It is represented as
an edge from dstpto dstp(line 18). Otherwise, the PITR.id
is already processed. Hence, the dstpof the first action
(as stated in sequence PITR.id .ACSeq) of the branch exists.
Fig. 5: Types of Branches in an LTS
The GenState function
returns that existing
state as exdstp.HOME-
SCAN adds a transition
from the current state
dstpto exdstp(lines
20-21). This is called
a branch merge. If the
first action of the branch exists in the current path (root to the
srcp), this branch is a sequence-recursion. Hence, HOMESCAN
merges the current and existing srcpstates. After all actions
are processed, the LTS representation is generated.
V. F LAW IDENTIFICATION
After the specification extraction, the LTS representation
is generated to model the behaviors of the participants and
their communications. We can further analyze the security
properties of the extracted protocol by verifying the generated
LTS model against the attack models.
Fig. 6: LTS Representation for the Malicious CP and Wi-Fi Attacker
In HOMESCAN, the behavior of an attacker is modeled as
an LTS Latt =(S,s0,Aatt,att ), where Aatt is a set of actions
performed by the attacker. In Fig. 6, we illustrate the behaviors
of the malicious participants and the network attacker using
the examples of the malicious CP and the Wi-Fi network
attacker in the running example. Note that we assume the
attacker is able to check and receive a specific message which
is modeled as a guard on the received messages (denoted by
“=”). The malicious CP pretends to be an honest one in the
same network with a different IP address CPIP’. It sends out
its newly generated nonce n(state att m2), trying to receive
an authenticated user ID hash(n)(we store this value in a
variable qin the LTS in Fig. 6) from the hub (state att m4).
Once successful, the malicious CP is able to find the SDs
within the network it has joined and then controls them by
sending its own malicious command command’ (state att m7).
The Wi-Fi network attacker resides between the CP and the
HS. It is able to intercept and replace the command sent from
the honest CP with command1’ (state att n1).
Given the extracted LTS models of both participants and
attackers, HOMESCAN generates the execution of the whole
smart home system defined in Definition 1.
Definition 1 (System LTS Generation) Let Li=(Si,s0i,A,
i)be the model of participant i, Latt =(Satt ,s0att ,Aatt ,att)
be the attack model, NSatt be the attacker’s knowledge set,
7
27
and Acbe the set of sending Asand receiving actions Ar
(As,ArAcA). The model of the whole system is an
LTS (S,s0,A,), where S S1×···Sn×(Satt ×PT),
initial state s0=(s01,··· ,s0n,(s0att ,)),A
=AAatt Asr,
Asr =(As×Ar)is a set of sending and receiving action pairs
denoting synchronization, and →⊆ S×A×S is the transition
relation.
Due to the page limitation, we list part of our LTS gener-
ation rules in Fig. 7, and the full list can be found in our
technical report [6]. Here we intuitively introduce it. Rule
comm denotes a communication action between two honest
participants. Rules att rec and att send represent the attacker’s
capabilities. att rec captures the message sent from an honest
participant and those generated by the attacker (attacker can
apply a cryptographic function to the captured message and
generate new terms using function Upd). These new terms are
added to the set NSatt.att send sends out a fake simulated
message to pretend as an honest participant. Rule att send all
represents the network attacker’s capability that it can intercept
the communication between honest participants and thereafter
randomly send a message from its knowledge set NSatt to the
intercepted honest receiver.
Notice that we define an additional sending action
send(ch,)to represent the network attacker’s capability
of sending any message from the attacker’s knowledge set
NSatt Kwhere the knowledge set Kis a set of terms.
According to Definition 2, an attacker has the capability of
updating his knowledge set NSatt by applying the attacker
knowledge’s set update function Upd defined as follows.
Definition 2 (Attacker Knowledge Set Update) Let NSatt
and NS
att be the input and output of the attacker’s knowledge
update function Upd such that NS
att Upd(NSatt ). Let m,n,
pk,sk T where pk and sk represent a public-private key
pair such that:
NS
att NSatt
{senc(m,n)},m,nNSatt
{m},senc(m,n),nNSatt
{aenc(m,pk)},m,pk NSatt
{m},aenc(m,pk),sk NSatt
{sign(m,sk)},m,sk NSatt
{m},sign(m,sk),pk NSatt
{hash(m)},mNSatt
In order to verify the security properties, HOMESCAN
applies the reachability analysis to the generated execution of
the smart home systems, using the classical algorithms such
as BFS and DFS. It determines whether a vulnerability exists
by searching whether a particular state (referred to bad state
hereinafter) can be reached in the whole system. For example,
in order to determine if the CP can have unauthorized control
of the hub and the SD, we can query if the system execution in
the running example can reach state att m6from state att m7
in Fig. 6. Alternatively, we can also query the existence of a
particular set of terms in the attacker’s knowledge set NSatt
to determine if the attacker has enough information to launch
an attack. For example, we can query if the set {command,
hash(n)}exists in the attacker’s knowledge set in Fig. 6 to
determine if the malicious CP can have unauthorized control
of the hub and the SD.
si
Send(ch,M)
−−−−−is
i,sj
Receive(ch,x)
−−−−−−js
j,ai=Send(ch,M),aj=Receive(ch,x)[comm ]
(s1,··· ,si,··· ,sj,···sn,(satt,NSatt)) (ai,aj[M/x])
−−−−−−(s1,···,s
i,··· ,s
j,···sn,(satt,NSatt))
si
Send(ch,M)
−−−−−is
i,satt
Receive(ch,x)
−−−−−−att s
att,ai=Send(ch,M),aatt =Receive(ch,x)[att re c ]
(s1,··· ,si,··· ,sn,(satt,NSatt)) (ai,aatt [M/x])
−−−−−−(s1,···,s
i,··· ,sn,(s
att,Upd(NSatt ∪{M})))
si
Receive(ch,x)
−−−−−−is
i,satt
Send(ch,M)
−−−−−att s
att,ai=Receive(ch,x),aatt =Send(ch,M)[att send ]
(s1,··· ,si,··· ,sn,(satt,NSatt)) (aatt ,ai[M/x])
−−−−−−(s1,···,s
i,··· ,sn,(s
att,NSatt))
si
Receive(ch,x)
−−−−−−is
i,satt
Send(ch,)
−−−−−att s
att,ai=Receive(ch,x),MiNSatt aatt =Send(ch,Mi)[att send all ]
(s1,··· ,si,··· ,sn,(satt,NSatt)) (aatt ,ai[Mi/x])
−−−−−−−→→(s1,··· ,s
i,··· ,sn,(s
att,NSatt))
Fig. 7: Execution Rules where x,x1V,MTand ch C
VI. EVALUATION
In this section, we present our experiment setup and overall
results. The supporting materials are published online [6].
A. Subjects of Our Evaluation
Philips Hue. Philips Hue is a smart lighting system produced
by Philips and is claimed to be the world’s most popular
smart lighting system [16]. The components and the working
process of this system are similar to the example discussed
in Section II-A. The detailed description is available in the
technical report [6].
LIFX. LIFX smart lighting system comprises a CP and a SD
(i.e., the smart bulb). The SD is Wi-Fi enabled and initially
provides an open Wi-Fi hotspot. In the discovery stage, the
CP joins the SD’s hotspot and discovers the configurations of
the SD by broadcasting a UDP packet. In the authentication
stage, the CP sends credentials of the home Wi-Fi to the SD
over SD’s hotspot. With the received credentials, the SD joins
the home Wi-Fi. In the control stage, the SD can be controlled
by any CP which joins the home Wi-Fi.
Chromecast. Google’s Chromecast allows streaming a video
to a TV. It comprises a CP, a receiver SD, and a Google’s
server (denoted by GS). The Chromecast SD also provides
an open Wi-Fi hotspot. In the discovery stage, the CP
joins SD’s hotspot and receives the device information (e.g.,
PublicKey) of the SD. In the authentication stage, the CP
sends the credentials of the home Wi-Fi to the SD over SD’s
hotspot. Once the SD has joined the home Wi-Fi, the CP uses
Multicast DNS (MDNS) to discover the SD. Further, to pair
the CP and the GS, the CP sends the ScreenID of the SD
to the GS. The GS responds to the CP with a token.In
the control stage, the CP uses this token to authenticate its
YouTube-video-casting requests with the GS.
B. Setup
Trace Capturing and Pre-Processing. We use 2.4 GHz
deRFusb23-E00 USB sniffing radio stick and Perytons An-
alyzer to capture ZigBee traces, and Wireshark tool to capture
the Wi-Fi traffic. We use Xposed framework [17] to obtain the
execution log of the Android app (i.e., the CP).
8
28
TABLE V: Summary of the Vulnerabilities
Misresponse
to Discovery
Request
Flawed
Authentication
Protocol
Lack of Au-
thorization
Use of Inse-
cure Underly-
ing Protocols
Unprotected
SD’s Wi-Fi
Hotspot
Lack of Device
or User Authenti-
cation Protocol
Vulnerable
to Network
Traffic Replay
Philips Hue 2 1 1 1 0 0 0
LIFX 0 0 0 0 2 1 1
Chromecast 1 0 0 0 1 1 0
PI Inference and LTS Representation. The detailed LTSs
for the three systems are available in the technical report [6].
Flaw Identification.H
OMESCAN uses a model checker called
PAT [18] as the inference engine in these case studies. By
analyzing the LTS representations of the systems against the
attack models defined in Section II-B, HOMESCAN reports
twelve security flaws shown in Table V.
C. Results
HOMESCAN discovered seven categories of vulnerabilities.
Mis-response to Discovery Request. During the discovery
stage, participants send/receive discovery requests to identify
potential participants of the system. However, if a participant
fails to validate the source of discovery requests, it may in-
correctly respond to the attacker. HOMESCAN identifies three
vulnerabilities which belong to this category. First, Philips Hue
HS replies to discovery requests, from any UPnP (a known
flawed protocol [19]) enabled devices. Second, Philips Hue
ZFE always replies to the discovery requests from ZigBee
enabled devices. Third, the Chromecast SD replies to MDNS
discovery requests from any device in the home Wi-Fi.
Flawed Authentication Protocol. Due to the resource limita-
tions, smart home systems may adopt customized authentica-
tion protocols. This may result in flawed protocols. HOMES-
CAN identifies one vulnerability from Philip Hue which can be
exploited by a malicious CP. In the authentication stage, the
Philips Hue HS relies on the user to press the button on the
hub to enable the authentication token generation. However,
after the pressing, this protocol does not guarantee that the HS
only generates the token to the benign CP requests.
Lack of Control to Administration Commands. In the con-
trol stage, the CP is allowed to send administration commands,
such as adding/removing SDs. However, this permission
should be limited to authorized parties. HOMESCAN identifies
one vulnerability from Philips Hue—any CP authenticated
by the HS, instead of only the admin user, can re-configure
Philips Hue. This may lead to severe consequences, including
uncontrolled authentication and denial-of-service against both
the hub and the SD.
Use of Insecure Underlying Protocols. Smart home systems
typically rely on existing protocols, but some of them may
select an insecure one. HOMESCAN identifies such a vulner-
ability from Philips Hue, which uses ZLL for authentication.
However, ZLL is designed to allow a participant to reset the
established connection. In particular, after the SD and the hub
have established a connection though ZLL, the attacker can
send a NextworkJoinRequest to the SD to trigger it to re-
execute the protocol. After that, the attacker can impersonate
as a hub to establish another connection with the SD.
Unprotected SD’s Wi-Fi Hotspot. SDs may come with on-
board open Wi-Fi hotspots. These unprotected Wi-Fi hotspots
can be exploited by malicious participants at all stages of
the system. HOMESCAN identifies three vulnerabilities which
belong to this category. First, in the discovery stage of LIFX,
any CP which joins the SD’s hotspot can obtain the SD’s
configurations and forcefully connect the SD to an attacker’s
Wi-Fi. Another vulnerability of this category are found in the
CPs of the LIFX and Chromecast, which cause them to be
deceitfully connected to a fake SD’s hotspot. This vulnerability
leads to a severe consequence in LIFX’s authentication stage,
where the CP sends the credentials of the home Wi-Fi in plain
text so that the attacker can exploit this vulnerability to steal
these credentials.
Lack of Device or User Authentication Protocol. Due to
the resource limitations, smart home systems may be devel-
oped without any authentication protocol. These systems can
be exploited by malicious participants to take over control
or obtain sensitive information. HOMESCAN identifies two
vulnerabilities of this category. In the LIFX system, any CP
which joins the home Wi-Fi can control the SD. Similarly, but
with a serious consequence, a malicious CP in the Chromecast
system which joins the home Wi-Fi can obtain the VideoID
of a private YouTube video and cast it to the TV screen.
Vulnerable to Network Traffic Replay. The network packets
exchanged among participants over channels may not include
any session related data (e.g., timestamp and nonce). These
packets can be intercepted and later replayed by a network
attacker who taps on the communication channel. HOMESCAN
identifies one vulnerability which belong to this category. The
UDP packets sent by LIFX CP can be intercepted and replayed
by a network attacker to manipulate the victim SD.
VII. RELATED WORK
A. Specification Extraction
There exists different approaches [20], [21], [22], [23], [24]
to build the model of a system through static code analysis or
execution trace analysis. However, the existing approaches are
not directly applicable to the specification extraction of a smart
home systems, due to the challenge of partial availability of
the implementation. Hence, as a compliment to existing work,
we propose a hybrid approach in this work.
B. IoT Security
The research of IoT security mainly focuses on three
domains, i.e., IoT devices, protocols and platforms.
Security of IoT Devices. Ho et al. [25] present flaws in the
design of smart locks and show how they lead to unauthorized
home access. Fawaz et al. [26] propose a system that protects
9
29
BLE equipped devices from privacy leakages during the device
discovery. Das et al. [27] have discovered privacy leakage in
BLE network traffic of wearable fitness trackers.
Security of IoT Protocols. Ronen et al. [28] discover a worm
attack against Philips Hue lamps by exploiting the ZigBee pro-
tocol. Zilliner et al. [29] show that the actual implementations
of ZigBee certified smart devices have insufficient security
controls. Santos et al. [30] reveal the information leakage on
ZigBee network and propose countermeasures. Armknecht et
al. [31] discuss attacks on the ZLL by studying its specifi-
cations. Fouladi et al. [32] demonstrate that proprietary Z-
Wave protocol vulnerabilities could lead to remote unlocking
of locks. Siby et al. [33] propose IoTScanner which provides
an overview of operations in all observed wireless networks.
Choi et al. [34] develop an automatic spoofer tool which
reconstructs protocols over IEEE 802.15.4. Compared with
these studies, our work focuses more on the application layer
of the integration of such protocols which may introduce novel
attacks.
Security of IoT Platforms. Jia et al. [4] propose a context-
based permission system for applied IoT platforms. Fernandes
et al. [35] propose an approach to address how the sensitive
data processed by third party apps after obtaining the access.
Fernandes et al. [12] demonstrate that CP applications could
be exploited by evaluating the security design of Samsung
SmartThings framework. The existing studies mainly focus on
the application frameworks, which is part of our consideration
in our work.
VIII. CONCLUSION AND FUTURE WORK
We present HOMESCAN, a semi-automatic approach to ex-
tract the abstract specification of the application-layer protocol
and internal behaviors of smart home systems from their im-
plementations, whereby it is possible to conduct an end-to-end
security analysis against various practical attack models. Using
HOMESCAN, we have found twelve security vulnerabilities
from three real-world smart home systems. Our work has
demonstrated the necessity of considering the security issues
in IoT systems from the perspective of integration.
REFERENCES
[1] Y. Oren and A. D. Keromytis, “From the Aether to the Ethernet-
Attacking the Internet using Broadcast Digital Television,” in USENIX
Security, 2014, pp. 353–368.
[2] K. Townsend, “Attacking smart TVs ,” http://itsecurity.co.uk/2014/06/
attacking-smart- tvs/, 2017.
[3] Y. Michalevsky, S. Nath, and J. Liu, “Mashable: mobile applications of
secret handshakes over bluetooth le,” in MobiCom, 2016, pp. 387–400.
[4] Y. J. Jia, Q. A. Chen, S. Wang, A. Rahmati, E. Fernandes, Z. M. Mao,
and A. Prakash, “Contexiot: Towards providing contextual integrity to
appified iot platforms,” in NDSS, 2017.
[5] R. M. Keller, “Formal verification of parallel programs,Communica-
tions of the ACM, vol. 19, pp. 371–384, 1976.
[6] HomeScan. https://sites.google.com/view/homescandemo/home.
[7] Samsung SmartThings. http://www.samsung.com/us/smart-home/.
[8] HomeGenie. https://genielabs.github.io/HomeGenie/.
[9] “Zigbee light link standard version 1.0,” http://
www.newsroom.lighting.philips.com/news/2017/20170831-philips-
hue-marks- 5th-birthday- with-new-products-and- entertainment-
capability, 2012.
[10] M. M. Hossain, M. Fotouhi, and R. Hasan, “Towards an analysis of
security issues, challenges, and open problems in the internet of things,”
in IEEE SERVICES, 2015, pp. 21–28.
[11] T. Denning, T. Kohno, and H. M. Levy, “Computer security and the
modern home,” Communications of the ACM, vol. 56, pp. 94–103, 2013.
[12] E. Fernandes, J. Jung, and A. Prakash, “Security analysis of emerging
smart home applications,” in IEEE S&P, 2016, pp. 636–654.
[13] H. Ryu and J. Kwak, “Secure data access control scheme for smart
home,” in Ubicomp, 2015, pp. 483–488.
[14] S. Sicari, A. Rizzardi, L. Grieco, and A. Coen-Porisini, “Security,
privacy and trust in internet of things: The road ahead,Computer
Networks, pp. 146 – 164, 2015.
[15] O. Mouaatamid, M. Lahmer, and M. Belkasmi, “Internet of things se-
curity: Layered classification of attacks and possible countermeasures,”
Electronic Journal of Information Technology, 2016.
[16] P. den Dunnen. Philips. http://www.newsroom.lighting.philips.com/
news/2017/20170831-philips-hue-marks- 5th-birthday- with-new-
products-and- entertainment-capability.
[17] Xposed. http://repo.xposed.info/.
[18] J. Sun, Y. Liu, J. S. Dong, and J. Pang, “Pat: Towards flexible verification
under fairness,” in CAV, 2009, pp. 709–714.
[19] H. Moore, “Security flaws in universal plug and play: Unplug. dont
play,” https://hdm.io/writing/SecurityFlawsUPnP.pdf.
[20] T. D. B. Le and D. Lo, “Deep specification mining,” in Proceedings of
the 27th ACM SIGSOFT ISSTA. ACM, 2018, pp. 106–117.
[21] L. Mariani, M. Pezz`
e, and M. Santoro, “Gk-tail+ an efficient approach
to learn software models,” IEEE TSE, vol. 43, no. 8, pp. 715–738, 2017.
[22] T.-D. B. Le, X.-B. D. Le, D. Lo, and I. Beschastnikh, “Synergizing
specification miners through model fissions and fusions (t),” in IEEE
ASE, 2015, pp. 115–125.
[23] G. Bai, J. Lei, G. Meng, S. S. Venkatraman, P. Saxena, J. Sun, Y. Liu,
and J. S. Dong, “Authscan: Automatic extraction of web authentication
protocols from implementations.” in NDSS, 2013.
[24] Q. Ye, G. Bai, K. Wang, and J. S. Dong, “Formal analysis of a single
sign-on protocol implementation for android,” in ICECCS, 2015, pp.
90–99.
[25] G. Ho, D. Leung, P. Mishra, A. Hosseini, D. Song, and D. Wagner,
“Smart locks: Lessons for securing commodity internet of things de-
vices,” in ASIACCS, 2016, pp. 461–472.
[26] K. Fawaz, K.-H. Kim, and K. G. Shin, “Protecting privacy of ble device
users,” in USENIX Security, 2016, pp. 1205–1221.
[27] A. K. Das, P. H. Pathak, C.-N. Chuah, and P. Mohapatra, “Uncovering
privacy leakage in ble network traffic of wearable fitness trackers,” in
HotMobile, 2016, pp. 99–104.
[28] E. Ronen, A. Shamir, A.-O. Weingarten, and C. OFlynn, “Iot goes
nuclear: Creating a zigbee chain reaction,” in IEEE S&P, 2017, pp.
195–212.
[29] T. Zillner and S. Strobl, “Zigbee exploited: The good the bad and the
ugly,” in Black Hat, 2015.
[30] J. Dos Santos, C. Hennebert, and C. Lauradoux, “Preserving privacy in
secured zigbee wireless sensor networks,” in WF-IoT, 2015, pp. 715–
720.
[31] F. Armknecht, Z. Benenson, P. Morgner, and C. M¨
uller, “On the
security of the zigbee light link touchlink commissioning procedure,”
in Gesellschaft f¨
ur Informatik eV (GI), 2016, p. 229.
[32] B. Fouladi and S. Ghanoun, “Honey, i’m home !!-hacking z-wave home
automation systems,” in Black Hat, 2013.
[33] S. Siby, R. R. Maiti, and N. O. Tippenhauer, “Iotscanner: Detecting
privacy threats in iot neighborhoods,” in IoTPTS, 2017, pp. 23–30.
[34] K. Choi, Y. Son, J. Noh, H. Shin, J. Choi, and Y. Kim, “Dissecting
customized protocols: Automatic analysis for customized protocols
based on ieee 802.15.4,” in ACM WiSec, 2016, pp. 183–193.
[35] E. Fernandes, J. Paupore, A. Rahmati, D. Simionato, M. Conti, and
A. Prakash, “Flowfence: Practical data protection for emerging iot
application frameworks,” in USENIX Security, 2016, pp. 531–548.
10
30
... Ma et al. (2018) showed that an attacker can post a message (text, audio, video) on the user's TV/Chromecast screen without requiring any authentication [48]. Mahadewa et al. (2018) demonstrated that any SHD in a home network can control the light bulbs available. Chromecast allowed private YouTube videos to be cast on television without requiring any authentication [49]. ...
... Mahadewa et al. (2018) demonstrated that any SHD in a home network can control the light bulbs available. Chromecast allowed private YouTube videos to be cast on television without requiring any authentication [49]. ...
... Default Credentials. While the SHD industry as a whole has not caught up in implementing authentication credentials in devices [48,49], some manufacturers allow the set up of credentials, such as passwords and pins, in their devices. However, many devices run with their default credentials [31,54] and users are not aware about how to change them. ...
Chapter
Smart Home Devices (SHDs) offer convenience that comes at the cost of security and privacy. SHDs can be subject to attacks and they can be used to conduct attacks on businesses or governments providing services to individuals. In this paper, we report vulnerabilities that have been published in research papers in IEEE Xplore digital library and ACM digital library. We followed a systematic approach to search for vulnerabilities in the literature, analyzed them and placed them in common categories. The study resulted in 153 vulnerabilities. The categories are based on the place of occurrence or component of smart home architecture, such as device, protocol, gateway, network, and software architecture. We also identified areas of research and development that have been underexplored in the past and need further efforts. Researchers, developers and users will benefit from this comprehensive analysis and systematic categorization of smart home vulnerabilities.
... The challenge may be attributed to the following two factors. This article extends the preliminary results presented in [1]. It includes a more detailed description on the protocol extraction algorithms, a detailed description and additional data on the experiment and evaluation. ...
... [ Symmetric init arg1 ] n.arg [1].dT ← k n.method = "Cipher.init(int, ...
Article
A key feature of the booming smart home is the integration of a wide assortment of technologies, including various standards, proprietary communication protocols and heterogeneous platforms. Due to customization, unsatisfied assumptions and incompatibility in the integration, critical security vulnerabilities are likely to be introduced by the integration. Hence, this work addresses the security problems in smart home systems from an integration perspective, as a complement to numerous studies that focus on the analysis of individual technologies. We propose HOMESCAN, an approach that examines the security of the implementations of smart home systems. It extracts the abstract specification of application-layer protocols and internal behaviors of entities, so that it is able to conduct an end-to-end security analysis against various attack models. Applying HOMESCAN on three extensively-used smart home systems, we have found twelve non-trivial security vulnerabilities, which may lead to unauthorized remote control and credential leakage.
Preprint
Full-text available
The connection of home electronic devices to the internet allows remote control of physical devices and involves the collection of large volumes of data. With the increase in the uptake of Internet-of-Things home devices, it becomes critical to understand the digital harms of smart homes. We present a systematic literature review on the security and privacy harms of smart homes. PRISMA methodology is used to systematically review 63 studies published between January 2011 and October 2021; and a review of known cases is undertaken to illustrate the literature review findings with real-world scenarios. Published literature identifies that smart homes may pose threats to confidentiality (unwanted release of information), authentication (sensing information being falsified) and unauthorised access to system controls. Most existing studies focus on privacy intrusions as a prevalent form of harm against smart homes. Other types of harms that are less common in the literature include hacking, malware and DoS attacks. Digital harms, and data associated with these harms, may vary extensively across smart devices. Most studies propose technical measures to mitigate digital harms, while fewer consider social prevention mechanisms. We also identify salient gaps in research, and argue that these should be addressed in future cross-disciplinary research initiatives.
Article
Full-text available
L'internet des objets (IdO) est un domaine actif de recherche. Assurer la sécurité des données échangées figure parmi ses grands défis. Cet article propose une nouvelle classification des attaques selon les couches OSI et l'objectif de sécurité à atteindre afin de développer de nouvelles techniques et procédures pour lutter contre ces attaques. Abstract Internet of Things is undoubtedly a well-known research area. In fact, ensuring security of data exchange is among the great challenges of the Internet of things. In this paper, we endeavour to introduce a new classification of attacks in compliance with the OSI layers and the objective of security that we seek to attained in order to develop novel techniques and processes to fight against these attacks.
Conference Paper
Full-text available
In the context of the emerging Internet of Things (IoT), a proliferation of wireless connectivity can be expected. That ubiquitous wireless communication will be hard to centrally manage and control, and can be expected to be opaque to end users. As a result, owners and users of physical space are threatened to lose control over their digital environments. In this work, we propose the idea of an IoTScanner. The IoTScanner integrates a range of radios to allow local reconnaissance of existing wireless infrastructure and participating nodes. It enumerates such devices, identifies connection patterns, and provides valuable insights for technical support and home users alike. Using our IoTScanner, we investigate metrics that could be used to classify devices and identify privacy threats in an IoT neighborhood.
Article
Full-text available
In the context of the emerging Internet of Things (IoT), a proliferation of wireless connectivity can be expected. That ubiquitous wireless communication will be hard to centrally manage and control, and can be expected to be opaque to end users. As a result, owners and users of physical space are threatened to lose control over their digital environments. In this work, we propose the idea of an IoTScanner. The IoTScanner integrates a range of radios to allow local reconnaissance of existing wireless infrastructure and participating nodes. It enumerates such devices, identifies connection patterns, and provides valuable insights for technical support and home users alike. Using our IoTScanner, we attempt to classify actively streaming IP cameras from other non-camera devices using simple heuristics. We show that our classification approach achieves a high accuracy in an IoT setting consisting of a large number of IoT devices. While related work usually focuses on detecting either the infrastructure, or eavesdropping on traffic from a specific node, we focus on providing a general overview of operations in all observed networks. We do not assume prior knowledge of used SSIDs, preshared passwords, or similar.
Conference Paper
Formal specifcations are essential but usually unavailable in software systems. Furthermore, writing these specifcations is costly and requires skills from developers. Recently, many automated techniques have been proposed to mine specifcations in various formats including fnite-state automaton (FSA). However, more works in specifcation mining are needed to further improve the accuracy of the inferred specifcations. In this work, we propose Deep Specifcation Miner (DSM), a new approach that performs deep learning for mining FSA-based specifcations. Our proposed approach uses test case generation to generate a richer set of execution traces for training a Recurrent Neural Network Based Language Model (RNNLM). From these execution traces, we construct a Prefx Tree Acceptor (PTA) and use the learned RNNLM to extract many features. These features are subsequently utilized by clustering algorithms to merge similar automata states in the PTA for constructing a number of FSAs. Then, our approach performs a model selection heuristic to estimate F-measure of FSAs and returns the one with the highest estimated Fmeasure. We execute DSM to mine specifcations of 11 target library classes. Our empirical analysis shows that DSM achieves an average F-measure of 71.97%, outperforming the best performing baseline by 28.22%. We also demonstrate the value of DSM in sandboxing Android apps.
Article
In this article, we describe a new type of attack on IoT devices, which exploits their ad hoc networking capabilities via the Zigbee wireless protocol, and thus cannot be monitored or stopped by standard Internet-based protective mechanisms. We developed and verified the attack using the Philips Hue smart lamps as a platform, by exploiting a major bug in the implementation of the Zigbee Light Link protocol, and a weakness in the firmware update process. By plugging in a single infected lamp anywhere in the city, an attacker can create a chain reaction in which a worm can jump from any lamp to all its physical neighbors, and thus stealthily infect the whole city if the density of smart lamps in it is high enough. This makes it possible to turn all the city’s smart lights on or off, to brick them, or to use them to disrupt nearby Wi-Fi transmissions.
Conference Paper
There has been a tremendous increase in popularity and adoption of wearable fitness trackers. These fitness trackers predominantly use Bluetooth Low Energy (BLE) for communicating and syncing the data with user's smartphone. This paper presents a measurement-driven study of possible privacy leakage from BLE communication between the fitness tracker and the smartphone. Using real BLE traffic traces collected in the wild and in controlled experiments, we show that majority of the fitness trackers use unchanged BLE address while advertising, making it feasible to track them. The BLE traffic of the fitness trackers is found to be correlated with the intensity of user's activity, making it possible for an eavesdropper to determine user's current activity (walking, sitting, idle or running) through BLE traffic analysis. Furthermore, we also demonstrate that the BLE traffic can represent user's gait which is known to be distinct from user to user. This makes it possible to identify a person (from a small group of users) based on the BLE traffic of her fitness tracker. As BLE-based wearable fitness trackers become widely adopted, our aim is to identify important privacy implications of their usage and discuss prevention strategies.
Article
Inferring models of program behavior from execution samples can provide useful information about a system, also in the increasingly common case of systems that evolve and adapt in their lifetime, and without requiring large developers’ effort. Techniques for learning models of program behavior from execution traces shall address conflicting challenges of recall, specificity and performance: They shall generate models that comprehensively represent the system behavior (recall) while limiting the amount of illegal behaviors that may be erroneously accepted by the model (specificity), and should infer the models within a reasonable time budget to process industrial scale systems (performance). In our early work, we designed GK-tail, an approach that can infer guarded finite state machines that model the behavior of object-oriented programs in terms of sequences of method calls and constraints on the parameter values. GK-tail addresses well two of the three main challenges, since it infers guarded finite state machines with a high level of recall and specificity, but presents severe limitations in terms of performance that reduce its scalability. In this paper, we present GK-tail+, a new approach to infer guarded finite state machines from execution traces of object-oriented programs. GK-tail+ proposes a new set of inference criteria that represent the core element of the inference process: It largely reduces the inference time of GK-tail while producing guarded finite state machines with a comparable level of recall and specificity. Thus, GK-tail+ advances the preliminary results of GK-tail by addressing all the three main challenges of learning models of program behavior from execution traces.
Conference Paper
We present new applications for cryptographic secret handshakes between mobile devices on top of Bluetooth Low-Energy (LE). Secret handshakes enable mutual authentication, with the property that the parties learn nothing about each other unless they have been both issued credentials by a group administrator. This property provides strong privacy guarantees that enable interesting applications. One of them is proximity-based discovery for private communities. We introduce MASHaBLE, a mobile application that enables participants to discover and interact with nearby users if and only if they belong to the same secret community. We use direct peer-to-peer communication over Bluetooth LE, rather than relying on a central server. We discuss the specifics of implementing secret handshakes over Bluetooth LE and present our prototype implementation.