• Scope: The work focuses on the security (offensive and
defensive) of home-based IoT systems.
• Impact: The work is regarded as significant based on the
number of citations.
• Disruption: The work uncovers a new area that the
community is currently investigating.
D. Evaluation Scope and Attack Model
Evaluation Scope. Our second contribution is the evaluation
of home-based IoT devices using the abstract model to assess
the security properties. We limit our scope to home-based IoT
devices because they are relevant to the systematized work,
they are readily available, and the experiment setup can be
easily reproduced.
Attack Model. For the evaluation, we simplify the attack
model to an Internet protocol (IP) network attacker. We
recognize that there are more powerful adversaries that can
attack low-energy (LE) based devices [15], but they require
specialized resources that are not available in many home net-
works. We consider the exploitation of a hub device (commu-
nication bridge between low-energy and IP) to be equivalent
to exploiting all the connected low-energy devices because
a trust session exists between the hub and the low-energy
devices. We exclude direct evaluation of low-energy devices
but consider their hubs for evaluation. Finally, we consider
the home network to be an untrusted network and we make
no assumptions about the security state of mobile applications,
modems/routers, or web browsers that have complete visibility
to the home network ([16]).
III. SYSTEMIZATION OF KNOWLEDGE
This section presents the systematization of home-based IoT
research based on the abstract graph model (see Figure 3).
Table I presents an overview of the systematized work and
their corresponding subsections where we discuss the literature
in detail. The component classification highlights the focus of
the work while the attack vectors, mitigations, and stakehold-
ers identify the approach. The systematization highlights repre-
sentative work; hence it does not provide an all-encompassing
reference to every related work.
A. Device
Most of the home-based IoT research focuses on the device
because the device component is the cornerstone of an IoT
deployment.
1) Attack Vector: Several works ([17]–[20]) explored IoT
device configuration insecurities. Barnes [17], building on the
findings of Clinton et al. [18], demonstrated how exposed
hardware pins on a device allowed him to gain privilege access
and spy on the end-users. Insecure configurations combined
with weak or a lack of authentication can exacerbate the
problem as shown by Chapman [21] and Rodrigues [22].
Weak or a lack of authentication in running services is a key
contributor to several documented attacks [23]–[26]. These
attacks demonstrate that device setup and configuration is an
important process that the vendor must consider and evaluate
for security flaws. Vendors should enforce strict authentication
policies and for end-users to configure the device before
allowing it to operate.
Max [23] assessed the security of the August Smart Lock
and found that weak authentication and insecure default con-
figuration broke the security of the lock. He found hard-coded
credentials and debug configurations that allows modification
and introspection of the lock. The work of Obermaier et
al. [25] on cloud-based cameras found that although the device
had what appeared to be a strong password (36 characters of
alphanumeric and symbols), the password was the MAC ad-
dress of the camera reversed and Base64 encoded. Kavalaris et
al. [26] showed that the Sonos device runs undocumented and
unauthenticated services on high ports allowing LAN clients to
fully control the device. The Sonos device was susceptible to
unauthorized device pairing due to the lack of authentication.
SmartAuth [24] found that the authentication problem also
manifests itself in the IoT application platforms through over-
privileged applications. Device pairing establishes a trusted
channel between a client and their device. Further, IoT hubs
bridge LE devices to IP networks, which have a pre-established
trust relationship as shown in Figure 3. An attacker would
exploit this specific process to circumvent the device or use it
as a pivot point.
IoT application platforms expose a permission-based model
to allow third-party applications to run. Fernandes et al. [27]–
[29] showed how implicit trust to third-party applications
can have major implications on the security of the device.
There are many subcomponents within the device’s platform,
which can make securing the device difficult. Many vendors
have good practices in place to ensure secure authentica-
tion and secure default configurations (as demonstrated by
O’Flynn [30]), but core device services can suffer from side-
channel information leakage. Ronen et al. [15] showed that
although the Philips Hue device was reasonably secure, they
were able to extract the master encryption key through a side-
channel attack and combine it with a vulnerability found in
the communication protocol, which resulted in a wormable
exploit.
Flaws in firmware allow attackers to steal WiFi creden-
tials [31], turn smart thermostats into spy gadgets [32], ransom
them [33], run arbitrary commands on smart TVs [34], and
control home assist devices covertly [35]. Costin et al. [36]
conducted a large-scale study on firmware analysis and found
an array of flaws. The literature showed that device security re-
quires defensive approaches to secure side-channel, firmware,
and hardware. The toolchain for software and hardware de-
velopment has a well-defined secure development process that
vendors must utilize.
2) Mitigations: To address vulnerable services, misconfigu-
ration, and weak authentication, vendors patch through device
updates, while inherent design flaws in IoT platforms are
mitigated through new frameworks. Wang et al. [37] proposed
a provenance-based framework to aggregates device activities
across a deployment that can detect errors and malicious
activities.
3