Discovering IoT Physical Channel Vulnerabilities

Muslum Ozgur Ozmen Xuansong Li∗†‡ Andrew Chu†

Purdue University School of Computer Science and University of Chicago
[email protected] Engineering, Nanjing University of [email protected]
Science and Technology
[email protected]

Z. Berkay Celik‡ Bardh Hoxha Xiangyu Zhang

Purdue University Toyota Research Institute Purdue University
[email protected] North America [email protected]
[email protected]

ABSTRACT CCS CONCEPTS

Smart homes contain diverse sensors and actuators controlled by • Security and privacy → Formal methods and theory of security;
IoT apps that provide custom automation. Prior works showed Vulnerability scanners; • Computer systems organization →
that an adversary could exploit physical interaction vulnerabilities Sensors and actuators.
among apps and put the users and environment at risk, e.g., to
break into a house, an adversary turns on the heater to trigger an KEYWORDS
app that opens windows when the temperature exceeds a thresh- Smart Homes; Security Analysis; Physical Channel Vulnerabilities
old. Currently, the safe behavior of physical interactions relies on
ACM Reference Format:
either app code analysis or dynamic analysis of device states with
Muslum Ozgur Ozmen, Xuansong Li, Andrew Chu, Z. Berkay Celik, Bardh
manually derived policies by developers. However, existing works Hoxha, and Xiangyu Zhang. 2022. Discovering IoT Physical Channel Vulner-
fail to achieve sufficient breadth and fidelity to translate the app abilities. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and
code into their physical behavior or provide incomplete security Communications Security (CCS ’22), November 7–11, 2022, Los Angeles, CA,
policies, causing poor accuracy and false alarms. USA. ACM, New York, NY, USA, 17 pages. https://doi.org/10.1145/3548606.
In this paper, we introduce a new approach, IoTSeer, which ef- 3560644
ficiently combines app code analysis and dynamic analysis with
new security policies to discover physical interaction vulnerabili- 1 INTRODUCTION
ties. IoTSeer works by first translating sensor events and actuator With the growing number of IoT devices co-located in an environ-
commands of each app into a physical execution model (PeM) and ment, the interactions among IoT apps cause increasing safety and
unifying PeMs to express composite physical execution of apps security issues [18, 19, 31, 43, 61, 65]. There are two fundamental
(CPeM). CPeM allows us to deploy IoTSeer in different smart homes sources of app interactions, software and physical. Software inter-
by defining its execution parameters with minimal data collection. actions occur when IoT apps interact through a common device
IoTSeer supports new security policies with intended/unintended defined in their source code. Consider an app that turns on the
physical channel labels. It then efficiently checks them on the CPeM lights when smoke is detected and another app that locks the door
via falsification, which addresses the undecidability of verification when the lights are turned on. These apps interact through a com-
due to the continuous and discrete behavior of IoT devices. smoke light-on
mon light device ( −−−−− → light-on −−−−−−→ door-locked) and makes
We evaluate IoTSeer in an actual house with 14 actuators, six
residents get trapped during a fire.
sensors, and 39 apps. IoTSeer discovers 16 unique policy violations,
Physical interactions are another notable (and stealthier) threat;
whereas prior works identify only 2 out of 16 with 18 falsely flagged
an app invokes an actuation command, and a sensor detects the
violations. IoTSeer only requires 30 mins of data collection for each
physical channel influenced by this command, triggering other apps
actuator to set the CPeM parameters and is adaptive to newly added,
that actuate a set of devices. Consider an app that turns on the heater
removed, and relocated devices.
and another app that opens the window when the temperature ex-
∗ Also ceeds a threshold. These apps interact through the temperature
with State Key Laboratory for Novel Software Technology, Nanjing University. temp.
† Thiswork was completed while the authors were at Purdue University. channel (heater-on∼∼∼∼ window-open). An adversary who exploits
‡ Corresponding authors. the heater controller app can stealthily trigger the window-open com-
mand and break into the house when the user is not home.
Permission to make digital or hard copies of part or all of this work for personal or Discovering software and physical interactions has received in-
classroom use is granted without fee provided that copies are not made or distributed creasing interest from the security community since they enable
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for third-party components of this work must be honored. an adversary to indirectly gain control over sensitive devices and
For all other uses, contact the owner/author(s). put the user and environment in danger. Prior works mainly focus
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA on identifying software interactions via app source code analy-
© 2022 Copyright held by the owner/author(s).
ACM ISBN 978-1-4503-9450-5/22/11. sis [10, 11, 16, 17, 19, 20, 45, 56]. These approaches find interacting
https://doi.org/10.1145/3548606.3560644 apps by matching the device attributes in multiple apps, such as
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA Ozmen et al.

App2
the light-on attribute in the first example. They cannot detect the App1
Physical
physical interactions because the app source code does not state Channel
Robot Vacuum Motion Sensor motion-active Turn on Lights
the physical channels, e.g., the heater’s influence on temperature. home-mode = away Motion Unlock the Patio Door

There have been limited efforts to discover physical interactions. motion-active

Cleaner-Start Turn on the Heater
These works mainly (1) use pre-defined physical channel mappings
App3
between commands and sensor events [5] and (2) leverage NLP
and device behavioral models to map the events and commands
of apps [13, 22, 61]. However, these approaches have limited ex- Figure 1: Illustration of physical interactions: the vacuum
pressiveness of physical channels, causing two issues. They lead to robot is activated when the user is not home, which unlocks
over-approximation of physical channels, which are false alarms the patio door and turns on the lights and heater.
(e.g., the system flags the temperature from oven-on and opens the
window, yet the temperature from the oven is not enough to create
with 18 false positives. We repeated the experiments in the actual
a physical channel), and under-approximation of physical channels,
house and verified that all violations discovered by IoTSeer are true
which are the interactions that the system fails to identify (e.g., the
positives. IoTSeer is adaptive to newly added, removed, and updated
system ignores the motion from robot-vacuum-on).
devices and imposes minimal model construction and validation
Recent work identifies physical interactions by collecting run-
time overhead. It requires, on average, 30 mins of data collection
time device states and enforces security rules at run-time [23].
for each actuator to set the parameters, and it takes, on average, 21
However, this approach has three limitations, which limit its effec-
secs to validate a physical channel policy on four interacting apps.
tiveness. (1) It defines rules based on devices’ use cases to prevent
In this paper, we make the following contributions.
physical interaction vulnerabilities. However, such rules do not
prevent unintended interactions that subvert the intended use of • Translating App Source Code into its Physical Behav-
apps and devices. For instance, a user installs an app that unlocks ior: We translate the actuation commands and sensor events
the patio door when motion is detected to automate their home in the app source code into physical execution models to
entry process. This system, however, does not prevent unlocking define their physical behavior.
the patio door even if the motion is detected due to the vacuum • Composition of Interacting Apps: We introduce a novel
robot’s movements. (2) As a dynamic enforcement system, it cannot composite physical execution model architecture that defines
infer the specific command that influences a physical channel at the joint physical behavior of interacting apps.
run-time. For example, when the motion sensor detects motion, it • Physical Channel Policy Validation: We develop new
cannot determine if this motion is from the vacuum robot or hu- security policies with intended/unintended physical channel
man presence. (3) When a device location changes, it makes wrong labels. We formally validate the policies on CPeM through
predictions about the app interactions, leading to unnecessarily optimization-guided falsification.
enforcing rules and failing to prevent violations. For instance, if • Evaluation in an Actual House: We use IoTSeer in a real
a portable heater is moved away from the temperature sensor, its house containing 14 actuators and six sensors and expose
influence on temperature measurements decreases. Yet, it would 16 physical channel policy violations.
predict a higher influence and turn the heater off prematurely. • IoTSeer code is available at
In this paper, we introduce IoTSeer, which builds the joint physi- https://github.com/purseclab/IoTSeer
cal behavior of IoT apps through code and dynamic analysis, and for public use and validation.
validates a set of new security policies to discover physical interac-
tion vulnerabilities. IoTSeer first extracts an app’s commands and 2 MOTIVATION AND THREAT MODEL
sensor events from its source code. It translates them into physical A smart home is composed of a set of apps that monitor and con-
execution models (PeMs), which define each app’s physical behavior. trol sensors and actuators. Apps subscribe to events (e.g., motion-
It unifies the PeMs of interacting apps in a composite physical exe- detected) that invoke their event handler methods, activating actu-
cution model (CPeM). To maximize CPeM’s fidelity in different smart ation commands (e.g., door-unlock). Users install official apps from
homes, it collects device traces to define its execution parameters. IoT markets such as HomeKit [35] and OpenHAB [47], and third-
IoTSeer supports new security policies that operate on intended/un- party apps through proprietary web interfaces. Another trend for
intended physical channel labels and validates if IoT apps conform custom automation is trigger-action platforms such as IFTTT [37]
to these policies through falsification. IoTSeer addresses the limi- and Zapier [64]. These platforms allow users to use conditional
tations of prior works with formal physical models of apps, new statements in the form of if/then rules to integrate digital services
security policies, and validation through metric temporal logic. with IoT devices. In this paper, we use the term app(s) to refer to
We applied IoTSeer in an actual house with 14 actuators and six both IoT apps and trigger-action rules.
sensors, automated by 39 apps from popular IoT platforms. We built When an actuation command is invoked, it influences a set of
the PeMs of 24 actuation commands and six sensor events used in physical channels measured by sensors. The command then inter-
the app source code and unified them in CPeM. IoTSeer found 16 acts with apps subscribed to those sensor events, invoking other
unique physical interaction policy violations on different groups of commands. An adversary can exploit such physical interactions to
interacting apps. We compared the violations discovered by IoTSeer indirectly control devices and cause unsafe states.
with existing works that identify physical interaction vulnerabil- To illustrate, Figure 1 shows a common smart home with four
ities and found that they can only identify 2 out of 16 violations devices. The user installs App1 that starts the robot vacuum cleaner
Discovering IoT Physical Channel Vulnerabilities CCS ’22, November 7–11, 2022, Los Angeles, CA, USA

when the home mode is set to away (or at specific times). An adver- 3 DESIGN CHALLENGES
sary can provide users with App2 and App3 that operate correctly in
C1: Correct Physical Interactions. To identify physical interac-
isolation yet exploit the physical interactions to cause unsafe states.
tion vulnerabilities, prior works have used NLP techniques, e.g., the
When motion is detected (the user enters the home), App2 turns on
heater is semantically related to temperature [22], manually crafted
the lights and unlocks the patio door, and App3 sets the heater to a
interaction mappings, e.g., heater-on is mapped to the temperature
specific temperature value.
channel [5], and constructed naive device models, e.g., heater-on
In this deployment, the user leaves home and sets the home mode
increases temperature by 1°C in 8 hours [61].
to away, triggering App1 that starts the robot vacuum cleaner. The
These approaches, unfortunately, discover erroneous interac-
movements of the robot vacuum create a physical interaction with
tions or fail to discover them due to over-approximating and under-
App2 and App3 since the motion sensor detects the robot vacuum.
approximating physical channel properties. Such errors may cause
This results in unlocking the patio door and turning on the lights
serious consequences. For instance, when the user is not at home,
and the heater while the user is not at home. The unlocked patio
they fail to block door-unlock or mistakenly approve window-open.
door may allow a burglar to break in, the turned-on lights may
indicate whether the users are at home or not, and the heater’s C2: Unintended Physical Interactions. Prior works define se-
influence on temperature may trigger other apps (e.g., opening the curity rules based on the use cases of devices to prevent physical
windows), causing a chain of interactions between multiple apps. interaction vulnerabilities. Such rules do not consider unintended
The preceding example shows that the final environment states interactions, which occur beyond the intended use of devices and
do not just depend on individual devices but are a result of the apps, and unexpectedly trigger actions in a smart home. For in-
physical interactions of multiple devices. Each app is individually stance, the user uses App2 and App3 in Figure 1 to turn on the light
safe, yet their unified physical interactions leave users at risk. and heater and unlock the patio door when they enter the home.
However, when the vacuum robot creates motion, it unintentionally
triggers both of these apps and invokes their actions.
2.1 Threat Model Additionally, an actuation command may unintentionally trigger
Our threat model is similar to related IoT security works, which a security rule and subvert its intended use. For example, prior
focus on app interaction vulnerabilities [19, 22, 23, 61]. We consider works define a rule that states, “The alarm must sound and an
an adversary whose goal is to execute undesired device actions SMS/Push message should be sent to the owner when motion is
(e.g., unlocking the door when the user is sleeping) and cause un- detected, and home mode is away” to protect the smart home from
safe system states. The adversary achieves this goal by creating or intruders [23]. This rule can be triggered when App1 turns on the
exploiting physical app interactions. vacuum robot, which would create panic and unnecessarily bring
The adversary can conduct two types of attacks, a mass attack resources (e.g., police dispatch) to the home.
or a targeted attack. In a mass attack, an adversary provides users C3: Run-time Dilemmas. Dynamic systems that examine the
with apps operating correctly in isolation yet exploits the physical device states at run-time [19, 23] cannot infer the influence of an
interactions among apps to cause unsafe states on a large scale. exact command on a physical channel. For instance, in Figure 1, it
The adversary does not target a specific smart home but harms is unclear to these systems whether the motion is from the vacuum
many users and hurts the trustworthiness of an IoT platform. The robot or human presence. This challenge becomes more critical
adversary can conduct this attack by (1) distributing apps on IoT when multiple devices influence the same physical channel. For
platforms and third-party IoT forums and (2) tricking users into example, if a sound sensor detects the sound from both AC and
installing apps via phishing and other social engineering methods. dryer, the dynamic systems cannot determine if a single device or
In a targeted attack, the adversary determines a specific smart their aggregated influence changes the sound. This makes them
home to exploit its physical app interactions. First, the adversary flag incorrect physical interactions.
discovers an exploitable physical interaction in the target smart When an interaction vulnerability is identified, dynamic systems
home. For this, the adversary remotely learns the devices and in- either block device actions or notify users. However, these responses
stalled apps by eavesdropping on the commands and sensor events could be dangerous. For example, the door-unlock action might be
over network packets and mining their correlations [3, 26]. The blocked if there is a fire in the house when the user is not home.
adversary can then wait until the physical interactions naturally C4: Device Placement Sensitivity. Prior works do not model the
occur and create unsafe states (e.g., the door is unlocked when the impact of the distance between an actuator and a sensor on physical
user is not at home) to conduct a physical attack. The adversary interactions. Intuitively, if the distance between an actuator and
can also leverage vulnerable apps to remotely control a set of com- sensor increases, the physical influence of a command on sensor
mands and cause physical interactions [22, 23, 61]. Through this, readings decreases monotonically. Thus, when a device’s placement
the adversary can stealthily invoke actuation commands through is changed, the identified interactions may no longer occur, and
physical channels even if they cannot directly control them. there may be new interactions that were not previously identified.
The physical interactions might also happen due to the errors This observation causes wrong predictions with false positives
in users’ creation, installation, and configuration of apps. In such (incorrect policy violations and unnecessarily enforcing policies)
cases, the physical interactions subvert the intended use of IoT and false negatives (missing violations and failing to prevent them).
devices, leading to unsafe states. This is because IoT users are This is critical in smart homes as frequent device placement changes
usually uninformed about the implications of app interactions, as may occur with lightweight and portable IoT devices.
demonstrated by prior works [58, 66].
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA Ozmen et al.

Generic Offline Module Deployment-specific Module Security Analysis Module

u Off
O=0
Start = 1 On
O = f(X)
v w Physical Channel Policies
Stop = 1
Agg On CPEM CPEM
O = f(X)
Start = 1
IoT Apps Static App Sensor Actuation Generic PEM Off On
O=0
Stop = 1
O = f(X)
Setting the CPEM
Analysis Events Commands Construction
Parameters Falsification Policy Violations
Unifying PEMS

Figure 2: Overview of IoTSeer’s architecture

4 IOTSEER DESIGN
u IoT Apps w
To discover physical interaction vulnerabilities, we introduce IoT- User
x
Seer, which combines app code analysis and dynamic analysis with IOTSEER v Edge Device
new security policies, and efficiently addresses the C1-C4 chal- Added, Removed, Mobile App
lenges. Figure 2 provides an overview of IoTSeer’s modules. Updated Apps/Devices

In the generic offline module ( 1 ), IoTSeer first extracts actuation

commands and sensor events of apps from their source code via Figure 3: Usage scenario of IoTSeer
static analysis. From this, it builds physical execution models (PeMs)
for each physical channel a command influences and a sensor mea-
sures. Each PeM defines a generic physical behavior of commands presents users with the changed policy violations and their root
and events in hybrid automata with well-studied generic differential causes. First, if the user installs a new app or device, IoTSeer runs the
and algebraic equations. generic offline and deployment-specific modules to include the new
IoTSeer then unifies the PeMs in a composite physical execution apps and devices in the CPeM. Second, if the user removes an app or
model (CPeM) to represent the joint physical behavior of interacting device, IoTSeer removes their PeMs and transitions from the CPeM.
apps. Our composition algorithm considers a set of physical channel Lastly, if an app’s configuration or a device’s placement changes, IoT-
properties (e.g., the aggregation of physical influences) (C1) and Seer changes the CPeM’s parameters with the deployment-specific
distinguishes the influence of each command (C3). module. After updating the CPeM, IoTSeer runs the security analysis
The offline module delivers PeMs and CPeM that define a generic module to identify policy violations.
physical behavior for devices and their composition on the physical
channels. However, each smart home may contain devices with 4.1 Generic Offline Module
different properties (e.g., heater power) and environmental factors To map an IoT app source code to its physical behavior, IoTSeer re-
(e.g., furniture and room layout). quires an app’s events, actuation commands, and trigger conditions
To address this, in the deployment-specific module ( 2 ), IoTSeer associated with each command. However, IoT platforms are diverse,
extends RSSI-based localization [4, 63] to obtain the physical dis- and each offers a different programming language for automation.
tance between actuators and sensors. It next collects device traces For instance, IoT platforms such as OpenHAB enable users to write
and leverages system identification techniques to define the execu- apps with a Domain Specific Language based on Xbase [47], and
tion parameters of CPeM. The resulting CPeM defines the physical trigger-action platforms such as IFTTT implement if-then abstrac-
behavior of interacting apps for a specific smart home with minimal tions [37]. To address this, we leverage existing static analysis and
data collection and addresses the device location changes (C4). parsing tools for IoT apps [16, 17, 61].
In the security analysis module ( 3 ), we first develop security poli- In this way, IoTSeer supports apps from various IoT platforms.
cies to detect unintended physical interactions that cause unsafe and These tools model an app’s life-cycle, including its entry points and
undesired system states (C2). IoTSeer then extends optimization- event handlers from its interprocedural control flow graph (ICFG),
guided falsification to validate if the joint physical behavior of and extract (1) devices and events, (2) actuations to be invoked for
interacting apps conforms to the identified policies. If IoTSeer dis- each event, and (3) conditions to invoke the actuations. For instance,
covers a policy violation, it outputs the violation’s root cause with given an app “When the temperature is higher than 80°𝐹 , if the AC is
the interacting apps and physical channels. off, then open the window”, IoTSeer obtains the temp > 80 event, the
Deployment. Our IoTSeer prototype runs in conjunction with the window-open command, and the AC-off trigger condition.
edge device in a smart home (See Figure 3). However, it could be 4.1.1 Constructing PeMs. We translate each command and sensor
implemented as a software service in the cloud or in a local server. event of an app to a PeM expressed with a hybrid I/O automaton.
IoTSeer first obtains the IoT apps and runs its generic offline
This process begins by constructing a separate PeM for each physical
module ( 1 ). It then collects actuator and sensor traces through channel a command influences, and a sensor event observes with
the edge device for the deployment-specific module ( 2 ). It next physics-based modeling. The physics-based modeling integrates a
runs its security analysis module and presents users with the policy generic differential or algebraic equation from control theory into
violations and their root causes ( 3 ). a PeM to model each app’s physical behavior [38, 60, 67]. This
IoTSeer supports dynamic changes in the smart home, including
approach is widely used in robotic vehicles [9, 50] (e.g., to predict
added, removed, and updated IoT apps and devices ( 4 ). When a RV’s sensor values) and in autonomous vehicles [15] (e.g., to model
dynamic change occurs, IoTSeer reruns its related modules and the movements of cars and pedestrians).
Discovering IoT Physical Channel Vulnerabilities CCS ’22, November 7–11, 2022, Los Angeles, CA, USA

1 Actuation Command PEM

App4 1.5

1. //Devices Physical Channel

Temperature Increase (F)

2. heater h
Off
Start = 1
On
1 Aggregation 2 Sensor Event PEM
3. //User Inputs heater-on
O=0 O = f(X)
4. time_on
Stop = 1 0.5
2.5
App6
5. if timer = time_on

Temperature Increase (F)

6. h.on() 0
2
t 1. //Devices
0 10 20 30
Time (minutes)
40 50 60 1.5 2. temperature_sensor t Window.Open
Agg On 3. window w
App5 0.6 1
O = f(X)
1. //Devices 4. if temp.increase

Temperature Increase (F)

0.5

Start = 1
0.5

2. oven o oven-on Off On 0.4 5. w.open()

0
3. //User Inputs O=0 O = f(X) 0.3
0 10 20 30 40
Time (minutes)
50 60

4. time_on Stop = 1 0.2

5. if timer = time_on 0.1

6. o.on() 0
0 10 20 30 40 50 60
Time (minutes)

3 Composite Physical Execution Model (CPEM)

Figure 4: Illustration of PeMs for actuators and sensors, and their CPeM for the unified behavior of three apps (App4 , App5 , App6 ).

Determining the physical channels that a command influences Example Actuator PeM. We illustrate a PeM for actuators that
requires collecting actuator and sensor traces from the smart home influences the temperature channel. The flow function for com-
since static app analysis does not reveal the commands’ physical mands that influence temperature uses the partial differential heat
channels. IoTSeer initially considers each command may influence diffusion equation [32], (𝜕T)/(𝜕t) = 𝛼 (𝜕 2 T)/(𝜕x2 ) with boundary
all physical channels and removes the over-approximated channels conditions. Here, T is the environment’s temperature (°K), x is the
in the deployment-specific module (See Sec. 4.2.2). distance parameter (m), 𝛼 is the thermal diffusivity constant (m2 /s),
PeMs for Actuation Commands. A command PeM defines the and the boundary conditions define the actuator’s temperature.
discrete and continuous dynamics of a command. The discrete Given the device property parameter and the distance to the
behaviors are an actuator’s states (e.g., on/off) for invoking the temperature sensor, the PeM outputs the command’s influence on
command from the app. The continuous behavior is an algebraic or the temperature sensor’s measurements over time.
differential equation that defines its physical behavior. PeMs for Sensor Events. We define an event’s PeM as a hybrid
Formally, each PeM is a hybrid I/O automaton [42] in the form I/O automaton (Hs ) with a single state, Q = {on} , and a timed (t) self
t
of Ha = (Q, X, f, →, U, O). Here Q is a set of discrete states, X is a transition on →
− on, where t is the frequency that a sensor samples
continuous variable, f is a flow function that defines the continuous its measurements. Figure 4- 2 depicts a sensor event’s PeM that
variable’s evolution, (→) defines the discrete transitions, and U/O only measures physical channels.
defines the input/output variables, as shown in Figure 4- 1 . We The sensor event PeM takes a sensitivity-level parameter, which
define the discrete states as Q = {on, off} , and discrete transitions defines the minimum amount of change in the physical channel
enable switching between them. The continuous variable defines (threshold) for a sensor to change its reading. We set the sensitivity
a command’s influence on physical channels (e.g., temperature in level based on the sensors installed in the smart home. A threshold
°F, sound in dB). The flow function acts on the continuous variable, function outputs a sensor reading indicating if the physical channel
and the PeM outputs the command’s influence. level is equal to or greater than the sensitivity level. If the sensor
We define a separate generic flow function for each physical measures boolean-typed values (e.g., motion), the PeM outputs a bit
channel. They are differential equations for continuous physical indicating “detected” or “undetected” events. If the sensor makes
channels such as temperature and algebraic equations for instant numerical readings (e.g., temperature), it outputs numerical values.
channels such as sound. A flow function takes two parameters as Example Sensor PeM. We illustrate a PeM for a sound sensor
input, device property, and distance from the actuator and outputs that outputs boolean-typed measurements. The threshold func-
the actuator’s influence on a physical channel at that distance. These tion of sound sensor events is defined as f(sp) = 1 if sp > th, 0
parameters allow us to use the same flow function for different otherwise. where sp is the ambient sound pressure and th is the
actuators that influence the same channel (e.g., heater-on and AC-on) sensor’s threshold (sensitivity level). Here, the PeM outputting 1
and the actuators with multiple working patterns (e.g., AC’s modes) means “sound-detected” and 0 means “sound-undetected.”
by setting different parameters. Built-in PeMs. Using the above approach, we have integrated
The property parameter describes the characteristics of a device, into IoTSeer a total of 24 actuator command PeMs (e.g., heater-on,
such as its operating power. In Sec. 4.2, we show how to set the pa- door-unlock) that influence a total of six physical channels, namely
rameters based on a specific smart home with IoTSeer’s deployment- temperature, humidity, illuminance, sound, motion, and smoke, and
specific module for precision. The distance parameter quantifies six sensor event PeMs that measure these channels. The PeMs can be
the command’s influence at different locations (e.g., fan-on’s sound easily extended to define the physical behavior of various devices
intensity at 1 and 2 meters away from the fan). We set this parame- since their flow functions are generic for a family of devices that
ter as the distance from the actuator to the sensor that measures influence the same physical channel.
its influence (Sec. 4.2). This makes the PeM practical against de- The PeMs allow us to obtain the physical behavior of popular apps
vice placement changes and enables effortless porting of IoTSeer to used in diverse IoT platforms. We detail their hybrid I/O automata
other deployments with different placements. in Appendix F and evaluate them in our evaluation in Sec. 5.
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA Ozmen et al.

Algorithm 1 Composition of Physical Behavior of Apps operators so that a sensor event PeM takes the aggregated output of
Input: Actuation Command PeMs (Ha ), Sensor Event PeMs (Hs ), Apps ( Lapp ) command PeMs as input (Lines 18-19). Turning to Figure 4, IoTSeer
Output: CPeM ( M ) adds Agg(H1a {heater-on} , H2a {oven-on} ) ∼∼ temp-increase transition
1: function Composition(Ha , Hs ,Lapp ) to the CPeM. The AGG operator’s output is defined based on the
2: for Hi ∈ Ha , Hj ∈ Hs do
3: Unify (Hi , Hj ) ⊲ Command to sensor event transitions physical channel’s unit. It is the sum of the command PeM outputs,
Ín i
i=1 UNIFY(Ha , Hs ) , for linear scale channels (e.g., temperature) [67].
4: end for
5: for appi ∈ Lapp do
6: ⟨ Lcommand
𝑖 , Lcondition
𝑖 , Levent
𝑖 ⟩ = StaticAnalysis(appi )
The channels in the log scale (e.g., sound) are aggregated after being
i
converted to a linear scale, 10 × log10 ( ni=1 10Ha /10 ) [44].
Í
7: for s ∈ Levent𝑖 , a ∈ Lcommand
𝑖 do
8: if a.condition = true then Another property of physical channels is that a physical channel
9: Unify (Hs , Ha ) ⊲ Sensor event to command transitions (pj ) may depend on another channel (pi ) if a change in pi affects pj .
10: end if
11: end for Due to dependencies, a sensor event PeM’s output may influence
12: end for another sensor event PeM’s readings. The generic PeMs allow us
13: for a1 ∈ Lcommand do
14: if a1 ∈ Levent
𝑖 and ai .condition = true then to easily identify dependencies by iteratively taking each sensor
15: Unify (Ha1 , Hai ) ⊲ Software channel transitions event PeM and checking if it is used in the threshold function of
16: end if another sensor event (Lines 20-23). For instance, when ambient
17: end for
18: for Hj ∈ Hs do temperature increases, the air-water capacity increases and affects
19: Agg (Hj .U) ⊲ Aggregate inputs of the sensor events the humidity sensor’s readings [40]. To address this, we add a
20: for Hk ∈ Hs do
21: if Hj .O = Hk .U then Dep (Hj → Hk ) ⊲ Dependency DEP(His → Hjs ) transition from the temperature sensor event PeM
22: end if output (His ) to the humidity sensor event PeM input (Hjs ).
23: end for
24: end for Ð
25: return M = (Ha , Hs ) ⊲ Return CPeM 4.2 Deployment-specific Module
26: end function
The actuation command PeMs require distance and device property
parameters, and the sensor event PeMs require a sensitivity level
parameter. We set these parameters based on the devices installed
4.1.2 Unifying the Physical Behavior of Apps. After we build the
in the smart home to ensure the CPeM precisely models the physical
PeMs for sensors and actuators to define the behavior of each app,
behavior of the apps.
we build a separate CPeM to represent their joint behavior.
Algorithm 1 presents our approach to CPeM construction. The 4.2.1 Setting the Distance Parameter. To determine the distance
algorithm starts with identifying the interacting apps by matching parameter in PeMs, we initially considered leveraging a recent IoT
the physical channels of sensor events and commands. First, if a device localization tool, Lumos [54]. Lumos localizes IoT devices
sensor measures a physical channel that a command influences, we with high accuracy by requiring the user to walk around the smart
add a transition from the command PeM (Ha ) output to the sensor home with a mobile phone. However, this approach could be incon-
event PeM (Hs ) input (Lines 2-4). Second, software and physical venient for smart home users since it requires manual effort.
channels can trigger the event handler of apps and invoke com- To address this, we integrate received signal strength intensity
mands if the apps’ conditions are satisfied. For physical channels, (RSSI)-based distance estimation techniques [4, 63] into IoTSeer.
we add a transition from a sensor event PeM (Hs ) to a command Such techniques leverage the inverse proportion between distance
PeM (Ha ) (Lines 5-12). For software channels, we add a transition and RSSI to estimate the distance between two devices. Although
from a command PeM (Ha1 ) to another command PeM (Ha2 ) if an this approach may incur an error in the distance parameter, our
app invokes a2 when a1 occurs (Lines 13-17). The transitions are evaluation shows that the impact of such errors on IoTSeer’s policy
expressed with a UNIFY operator, which defines the interactions violation identification is minimal (See Sec. 5).
as a transition, Ha ∼∼Hs , Hs→
− Ha , and Ha→
− Ha . Here, ∼∼ is a physical
influence on a channel, and → − is a software channel. 4.2.2 Setting the Device Property Parameter. We consider two op-
Figure 4- 3 shows the CPeM of three apps (App4 , App5 , App6 ) that tions for setting the device property parameters based on the in-
automate a heater, oven, window, and temperature sensor. When stalled devices. The first is using the installed device’s datasheets.
App4 invokes heater-on and App5 invokes oven-on, IoTSeer identifies Yet, in our prototype implementation, we realized that the datasheets
heater-on’s and oven-on’s temperature PeMs interact with tempera- might be incomplete, or a discrepancy could occur, for example,
ture sensor of App6 . IoTSeer adds the below transitions to the CPeM: due to device aging [51]. To address this, we extend System Identi-
Ha {heater-on} ∼∼ Hs {temp-increase} fication (SI), a learning-based method commonly used by control
Ha {oven-on} ∼∼ Hs {temp-increase} engineers to estimate parameters or models of physical processes
Another transition from the temperature sensor event PeM to using experimental data traces [39, 49].
window-open PeM is then added because when the sensor measures SI allows us to estimate device property parameters that ensure
an increased temperature, App6 opens the window. the CPeM achieves high fidelity with actual devices. This process
Hs {temp-increase} →
requires fewer traces than the traditional application of SI as we
− Ha {window-open}
only estimate parameters instead of complete equations (See Sec. 5).
Addressing Aggregation and Dependency. A sensor measures We particularly use (𝜏, 𝜖)-closeness [2] as the fidelity metric. (𝜏, 𝜖)-
the accumulated influence of multiple commands. For this, we closeness determines the difference between two traces in their
define an aggregation operator (AGG), which combines UNIFY(Ha, Hs ) timing (𝜏) and values (𝜖), where 𝜖 is referred to as deviation score.
Discovering IoT Physical Channel Vulnerabilities CCS ’22, November 7–11, 2022, Los Angeles, CA, USA

Table 1: Descriptions of intent-based policies to discover physical channel vulnerabilities in Figure 5.

ID∗ Formal Representation† Policy Description Security Goal

An actuation command’s influence on a physical channel must not Prevent attackers from creating and exploiting
G1 □(imp(⟨UnInt, p⟩) ≤ th)
unintentionally trigger an app’s sensor event and invoke its device actions. individual unintended physical interactions.
Multiple commands’ aggregated influence on a physical channel must not Prevent attackers from creating and exploiting
G2 □(imp(⟨UnInt1, p⟩, . . . , ⟨UnIntn, p⟩) ≤ th)
unintentionally trigger an app’s sensor event and invoke its device actions. aggregated unintended physical interactions.
□(imp(⟨Int1, p⟩ . . . ⟨Intk, p⟩) < th) → □(imp(⟨Int1, p⟩, If commands’ intended influences do not trigger an app’s sensor event, their Prevent attackers from bypassing intended
G3
. . . , ⟨Intk, p⟩, ⟨UnInt1, p⟩, . . . , ⟨UnIntn, p⟩) < th) aggregation with other commands’ unintended influences must not trigger it. physical interactions.
∗ The IDs correspond to the vulnerabilities in Figure 5 (G1 for (a), G2 for (b), and G3 for (c))
† imp() denotes an actuation commands’ labeled influence on a channel p. Multiple channels in imp denotes aggregated influences. th denotes a sensor’s sensitivity.

To apply this approach in a smart home, IoTSeer individually UnInt App A1

A1 S A2
activates each actuator and collects sensor measurements. It next
UnInt App
runs their PeMs with a device property parameter and obtains sensor (a) Unintended Individual Interaction AN-1 S AN+1
traces. It computes the (𝜏, 𝜖)-closeness between the actual device
and PeM traces. It conducts a binary search on the device property Int
A1 AN
parameter to obtain the optimal value that minimizes the deviation App
UnInt S AN+1
score. Using real device traces to determine the device property Int
AN AN S AN+1
parameters ensures that the impact of environmental conditions
(e.g., furniture) on sensor readings is integrated into the CPeM. (b) Unintended Aggregated Interaction (c) Unintended Aggregation Bypass
From the collected actual device traces, IoTSeer also determines
the set of physical channels that a command influences in the smart Figure 5: Intent-based physical channel vulnerabilities (A is
home. IoTSeer checks if a command does not change the sensor an actuation command, and S is a sensor event).
measurements or if its influence is statistically indistinguishable
from environmental noise. In such a case, IoTSeer removes the PeMs
of those commands from the CPeM. Consider an app that states “open the windows when you are
cooking” in its description, and the app is triggered when the tem-
4.3 Security Analysis Module perature sensor’s readings exceed a threshold. SmartAuth outputs
We first identify intent-based policies to detect unintended app that this app is related to the cooking activity. IoTSeer takes the
interactions and device-centric policies to detect the vulnerabilities app’s activity and checks whether any of the actuators installed in
intended interactions present (Sec. 4.3.1). IoTSeer then leverages fal- the smart home are semantically related to the activity. For this,
sification to validate the identified policies on the CPeM (Sec. 4.3.2). IoTSeer uses Word2Vec representations to compute the semantic
distance between the activity and the commands. It then assigns
4.3.1 Identifying Physical Channel Policies. To properly designate intended (Int) label to the commands with a distance lower than
the circumstances under which the physical interactions are a vul- a threshold and assigns unintended (UnInt) labels to others. For
nerability or feature, we define intended and unintended labels. instance, the cooking activity is semantically related to oven-on and
We define the physical channel between an actuator and an cooker-on commands, and thus, IoTSeer assigns Int to them.
app as intended if the app is installed to be triggered from that If an app’s description does not indicate an activity or none of the
command’s influence. For instance, consider a user that installs an commands are semantically related to the activity, IoTSeer assigns
app that turns on the AC when the temperature exceeds a threshold. the labels based on the apps’ sensor events. The apps conditioned
If the temperature from the oven triggers this app, the channel on motion or sound sensors’ events are used to detect the presence
between oven-on and the app is intended, as the oven causes the of users and intruders in smart homes. For instance, App2 in Sec. 2,
temperature to exceed the threshold defined by the user. which unlocks the patio door and turns on the lights when motion
We define a physical channel between an actuator and an app as is detected, is used to be triggered with user presence. IoTSeer
unintended if it is unplanned by a system or undesired by a user. assigns UnInt label to all commands for such apps because only the
For instance, consider a user that installs an app with the goal of influences from users and intruders are intended for them.
unlocking the patio door with the motion from her presence. If The apps conditioned on temperature, humidity, smoke, and
the motion from the vacuum robot triggers this app, the channel illuminance channels are installed to be triggered when the phys-
between robot-vacuum-on and the app is unintended, as unlocking ical channel’s state reaches a specific condition. For instance, an
the patio door due to the vacuum robot is not desired by the user. app that turns on the AC when the temperature is higher than a
Intended/Unintended Label Generation. IoTSeer automates gen- threshold controls the AC based on the ambient temperature level.
erating the interaction labels based on the use cases of apps. It also IoTSeer assigns Int label to all commands for such apps because
allows users to change the labels as their needs dictate. their intended use only depends on the physical channel conditions,
To generate the labels, IoTSeer first checks whether the intended regardless of which commands influence them.
use of an app is related to a specific activity. IoTSeer leverages Intent-based Policies. Based on generated labels, we define three
SmartAuth [57], an NLP-based technique that extracts the activity intent-based policies, as shown in Figure 5, which are used to iden-
related to an app from its description. tify unintended physical interactions that create undesired and
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA Ozmen et al.

Table 2: Example device-centric policies (The complete list Algorithm 2 Grid-Testing

of policies is presented in Appendix B). Input: CPeM ( MHa ,Hs ) with command PeMs (Ha ) and sensor event PeMs (Hs ),
parameters (x - distances among devices), inputs (U - apps’ activation times t0 :
ID Policy Description Formal Representation Δt : tend ), policy (𝜓 ).
When the home is in the away mode, Output: P= (inputs, apps, dist, atime, y)
DC2 □(mode-away → window-close)
the window must be closed. 1: function Grid_Test(Ha , Hs , x, U, MHa ,Hs ,𝜓 )
DC3
A device must not open, then close and
□¬(on ∧ #3 [0,t] (off ∧ #3 [0,t] on)) 2: for j ∈ Hs , HOP ⊆ Ha do
then reopen (actuation loop) within t seconds. 3: for Different activation times in HOP do
DC5
The alarm must go off within t seconds
□(smoke-detected → 3 [0,t] alarm-on) 4: if Φ( MHOP ,Hs , x, u) ⊭ 𝜓 then
after smoke is detected. 5: P ← P ∪ {x, u, Φ( MHOP ,Hs , x, u) }
The main door must not be left
DC6 3 [0,t] door-lock 6: end if
unlocked for more than t seconds.
7: end for
The door must always be locked and lights
DC9 □(mode-away → door-lock ∧ light-off) 8: end for
must be off when the home is in the away mode.
9: return P
10: end function

unsafe system states. We present the security goal of each policy CPEM MTL Policy (𝝍) Policy Violation
and its expression with Metric Temporal Logic (MTL) in Table 1. 0
b. <
Off Start = 1 On
O=0
Stop = 1
O = f(X)
t Ro x
We validate the policies on the CPeM in the next section. Agg On v
The first policy, G1 , unintended individual interaction, states Off Start = 1 On
O = f(X)
Actuator and w Stochastic
O=0
Stop = 1
O = f(X)
Sensor TracesRobustness Rob. Optimization
that an actuation command’s unintended influence on a physi- Computation

cal channel must not trigger an app’s sensor event and invoke its u Apps’ Activation Times

device actions (Figure 5(a)). For instance, the robot vacuum’s mo-
Figure 6: Overview of falsification to find policy violations.
tion must not trigger an app that unlocks the patio door when a
motion-detected event occurs. This is because an adversary who
can invoke the start robot vacuum action (e.g., through a vulnerable
At each execution, the CPeM takes apps’ activation times as
app) can exploit this interaction to indirectly unlock the patio door.
input, which is the time when the app invokes its commands and
The second policy, G2 , states the aggregated influence from multi-
the command PeM transitions to the “on” state. The CPeM simulates
ple commands must not unintentionally trigger an app and invoke
the unified physical behavior of commands and sensor events and
its device actions (Figure 5(b)). Although a command’s individual
outputs traces of PeMs. The traces (v, t) are composed of a periodic
influence may not trigger an app, its aggregation with another com-
timestamp t, and a physical channel value v. Each command PeM’s
mand’s influence may trigger it. For example, the aggregated sound
v shows how much it influences a channel, and each sensor event
of AC-on and dryer-on must not trigger an app that sounds an alarm
PeM’s v shows its measurements. The traces also include labels
when the sound-detected event occurs, and the home mode is away.
(Int/UnInt) and app IDs of commands/events for root cause analysis.
The last policy, G3 , states if the commands’ intended influences
do not trigger an app’s sensor event, their aggregation with other Policy Validation Challenges. The physical channel values and
commands’ unintended influences must not trigger it (Figure 5(c)). the app activation times are continuous; thus, the CPeM’s state
For instance, if the light bulb’s Int influence on illuminance does space becomes infinite, which makes formal verification approaches
not create a light-detected event and trigger apps, its aggregation (e.g., model checking) undecidable on the CPeM [6, 33, 48].
with the TV’s UnInt influence must not trigger the apps as well. To address this issue, we initially implemented a grid-testing
These unintended physical interactions, by definition, are not approach, a commonly applied method for testing CPS and au-
features as they are not desired by users. Yet, an adversary can tonomous vehicle software [21, 46, 68]. Grid-testing determines
exploit them to indirectly control devices and cause unsafe states. whether the CPeM satisfies a policy under a finite set of apps’ ac-
tivation times– the times that apps invoke actuation commands.
Device-Centric Policies. While intent-based policies detect unsafe
Algorithm 2 presents the grid-testing approach on the CPeM for pol-
states from unintended physical interactions, Int labeled physical
icy validation. We set apps’ activation times as a grid (t0 : Δt : tend )
channels can also cause unsafe states. For instance, the heater’s
(Line 3). The algorithm executes the CPeM with a search on activa-
intended influence on the temperature sensor may trigger an app
tion time combinations. It then validates a policy on each execu-
that opens the windows when the temperature exceeds a threshold.
tion’s traces from PeMs with a robustness metric (Lines 4-6), where
To address such violations, we extend the security rules of previ-
negative robustness values indicate a policy violation.
ous works [17, 19, 23] (and enhance them with time-constrained
However, we found that grid-testing does not scale larger analy-
temporal operators in MTL) to define device-centric policies. We
ses with the increasing number of interacting apps and may miss
present a subset of device-centric policies in Table 2 and give the
policy violations due to input discretization. To address these, we
complete list in Appendix B. For instance, the DC5 policy states phys-
extend optimization-guided falsification and compare it with grid-
ical interactions must not prevent an alarm from going off in two
testing in identifying violations and performance overhead in Sec. 5.
secs after smoke is detected (□( (smoke > th) → 3 [0,2] (alarm = ON) ) ,
where □ is always, and 3 [0,2] is eventually within next 2 secs). Optimization-Guided Falsification. Falsification is a formal anal-
ysis technique that searches for a counterexample to an MTL policy
4.3.2 Validating Policies on CPeM. After identified policies are ex- from a continuous input set [1, 7]. Figure 6 depicts our approach in
pressed with MTL, IoTSeer executes the CPeM (hybrid I/O automa- leveraging falsification to search for interacting apps that cause a
ton) and collects actuator and sensor traces to validate policies. policy violation on the CPeM.
Discovering IoT Physical Channel Vulnerabilities CCS ’22, November 7–11, 2022, Los Angeles, CA, USA

Sensors
Table 3: Physical channels of studied actuators and sensors.
12 a Temperature c Sound e Motion

b Illuminance d Humidity f Smoke

11 Sensors
9 10
b
Actuator (Actuation Command) Temp. Illum. Sound Hum. Motion Smoke
2 Marley Baseboard Heater (set(val)) ✓ ✗ ✗ ✓ ✗ ✗
Actuators
3 e Kenmore AC (set(val)) ✓ ✗ ✓ ✓ ✗ ✗
5m

1 Heater 6 Washer Robot CREE Smart Light Bulb (on) ✗ ✓ ✗ ✗ ✗ ✗

c 11
8 Vacuum
Instant Pot Pressure Cooker (on) ✓ ✗ ✗ ✓ ✗ ✗
f 2 Oven 7
a d 4 Dryer 12 Light Bulb Mr. Coffee Coffee maker (on) ✓ ✗ ✗ ✓ ✗ ✗
13
Pressure Sunbeam Humidifier (on) ✗ ✗ ✗ ✓ ✗ ✗
3 Cooker 8 Humidifier 13 AC
Easy Home Dehumidifier (on) ✗ ✗ ✗ ✓ ✗ ✗
14
6 5 4 Coffee
9 Garbage 14 Door Lock Whirlpool Clothes Washer (on) ✗ ✗ ✓ ✓ ✗ ✗
Maker Disposal Whirlpool Dryer (on) ✓ ✗ ✓ ✓ ✗ ✗
7 12 1 5 Dehumidifier 10 TV Whirlpool Garbage Disposal (on) ✗ ✗ ✓ ✗ ✗ ✗
3m Roborock S4 Robot Vacuum (on) ✗ ✗ ✗ ✗ ✓ ✗
Vizio 48” TV (on) ✗ ✓ ✓ ✗ ✗ ✗
Door (unlock) ✗ ✗ ✓ ✗ ✗ ✗
Figure 7: Sensor/actuator layout in the actual house. Whirlpool Oven (on) ✓ ✗ ✗ ✓ ✗ ✗
✗ means the command does not influence the physical channel the sensor observes and ✓means
the command influences it. See Appendix G for sensor brands.
Specifically, we use an optimization algorithm to search for policy
violations by sampling activation times ( 1 ). We then execute the
CPeM and record actuator and sensor traces from PeMs ( 2 ). From We built a total of 24 PeMs for channels the commands influence
the traces, we compute a robustness value that quantifies how close (number of physical channels the actuators influence in Table 3) and
an MTL formula is to the policy violation ( 3 ). Positive robustness six sensor event PeMs for the channels they observe (temperature,
values indicate the policy is satisfied, and negative values indicate it illuminance, sound, humidity, motion, and smoke). We also use the
is violated. The sampler then seeds another input to the CPeM within collected sensor measurements to conduct SI and tune the CPeM
the ranges (similar to input mutation in fuzzing [29]). The sampler’s parameters. We detail the CPeM fidelity in Appendix C. Lastly, we
objective is minimizing the robustness to find a policy violation ( 4 ). assign Int/UnInt labels between the commands and apps based on
The termination criteria for input generation is when the policy is the apps’ intended uses, as described in Sec. 4.3.1.
violated or a user-defined maximum number of iterations is met. We implement grid-testing and our falsification approach using
1 " Policy Violation " : {
an open-source temporal logic toolbox, S-TaLiRo [8]. We leverage
2 " I n p u t " : r o b o t −vacuum −on , S-TaLiRo’s dptaliro function as a subroutine in grid-testing and
3 " Apps " :
4 " app_a " : e : = t i m e r , a : = r o b o t . vacuum −on , staliro function in our optimization-guided falsification to vali-
5 " app_b " : e : = mot − a c t i v e , a : = p a t D o o r . u n l o c k , date MTL policies on the CPeM. We use the staliro function with
6 " A c t i v a t i o n Time " : 1 0 ,
7 " Distance " : 2 , simulated annealing by hit-and-run Monte Carlo sampling for input
8 " P h y s i c a l Channel V a l u e s " : generation [25]. We use a dynamic programming-based algorithm
9 " t = 1 0 " : r o b o t −vacuum . move ,
10 " t = 1 1 " : ( U n I n t ) mot − a c t i v e , to compute the robustness of MTL policies. In grid-testing’s im-
11 " t = 1 1 " : patDoor . unlock }
plementation, we consider apps invoke actuation commands at
Listing 1: An example output of policy validation. 10-min intervals; thus, the apps’ activation times are set as a grid
to 0 : 10 : 60. In falsification’s implementation, we set the apps’
When IoTSeer identifies a policy violation, it outputs a quintuple, activation times as continuous ranges, any time in the execution
O = (inputs, apps, dist, atime, v) , that details the policy violation’s (0-60), and we define the max number of tests to 100 as we do not
root cause. Here, atime is the activation time of apps, v is Int, UnInt observe a significant change in robustness after 100.
labeled command PeM and sensor event PeM outputs, and dist is the We run the CPeM executions on a laptop with a 2.3 GHz 2-core
distance from actuators to sensors. Listing 1 presents the output of i5 processor and 8 GB RAM, using Simulink 10.0.
a policy violation when Appa turns on a robot vacuum and interacts
with Appb that unlocks the patio door when it detects the robot 5.1 Effectiveness
vacuum’s motion. The output further details the violation occurs
We validate intent-based and device-centric security policies on the
when robot-vacuum-on is activated at minute 10 when it is 2 meters
CPeM tuned for our home (See Appendix D for an example CPeM).
away from the motion sensor. In Sec. 6, we detail how this output
Table 4 presents 16 identified policy violations caused by physical
can be used to mitigate the violation.
interactions among seven different groups of devices. We compare
the violations flagged by IoTSeer with prior works that identify
5 EVALUATION
physical interaction vulnerabilities and show they can discover 2
We evaluate IoTSeer in a real home with six sensors and 14 actuators, out of 16 violations. We also conduct in-home experiments with
as shown in Figure 7. To automate the devices, we study three IoT real devices and confirm that all 16 violations are true positives.
app markets, IFTTT, Microsoft Flow, and SmartThings, and install
39 popular apps (See Appendix E for their descriptions). We then 5.1.1 Intent-based Policy Violations. IoTSeer identified 14 interac-
invoke each actuation command and collect sensor measurements tions that subvert the apps’ intended use, causing unsafe states.
from actual devices in the house for 30 mins to identify the channels Individual Policy (G1 ) Violations. IoTSeer flagged 10 individual
each command influences (See Table 3)1 . policy (G1 ) violations that occur due to the physical interactions
1We have consulted our university’s IRB office and got advised that IRB approval is among three groups of devices. First, the motion sensor detects the
not required since we do not collect any sensitive information. presence of the robot vacuum and unintentionally triggers five apps
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA Ozmen et al.

Table 4: Policy violations identified by IoTSeer and previous works.

Number of Existing Work

Policy ID App Interactions Violation Description
Violations iRuler IoTMon IoTSafe
motion-det.
−−−−−−−−−−→ door-unlock
motion-det. Robot vacuum’s motion unintentionally triggers
−−−−−−−−−−→ light-on
V1 motion-det. 5 five apps and causes door-unlock, heater-on, ✗ ✗ ✗
robot-vacuum-start −−−−−−−−−−→ heater-on
motion-det. light-on, TV-on and call-user actions.
−−−−−−−−−−→ TV-on
G1 motion-det.
−−−−−−−−−−→ call-user
sound-det. Garbage disposal’s sound unintentionally
−−−−−−−−−→ light-on
V2 sound-det. 3 triggers three apps and causes ✗ ✗ ✗
garb-disp-on −−−−−−−−−→ TV-on
sound-det. light-on, TV-on and call-user actions.
−−−−−−−−−→ call-user
sound-det.
−−−−−−−−−→ light-on TV’s sound unintentionally triggers two
V3 TV-on sound-det. 2 ✗ ✗ ✗
−−−−−−−−−→ call-user apps and causes light-on and call-user actions.
sound-det. Aggregated sound from the AC, washer and dryer
−−−−−−−−−→ light-on
G2 V4 sound-det. 3 ✗ ✗ ✗
Agg(AC-on, washer-on, dryer-on) −−−−−−−−−→ TV-on unintentionally triggers three apps and causes
sound-det.
−−−−−−−−−→ call-user light-on, TV-on and call-user actions.
Aggregated light from the bulb and TV bypasses
light-det.
G3 V5 Agg(bulb-on, TV-on) −−−−−−−−−→ light-off 1 bulb’s intended influence and triggers an ✗ ✗ ✗
app that turns off the lights.
sleep-mode temp<th° F Temperature decreases due to the AC’s influence and
DC8 V6 sleep-mode-activate −−−−−−−−−→ AC-on −−−−−−−−−→ light-on 1 ✗ ✓ ✓
turns on the bulb when the home mode is sleep.
away-mode motion-det. Temperature increases due to the heater’s influence and
DC9 V7 away-mode-activate −−−−−−−−→ vacuum-start −−−−−−−−−−→ 1 ✗ ✓ ✓
temp>th° F turns on the bulb when the home mode is away.
heater-on −−−−−−−−−→ light-on

conditioned on the motion-detected event. For instance, this viola- App26 to turn on the heater ( 1 ). The heater’s Int temperature then
tion occurs when App17 starts the robot vacuum when the home triggers App23 and turns on the bulb, violating DC9 .
mode is set to away, and App27 unlocks the door when motion is de-
tected. Second, the sound sensor detects the garbage disposal’s (V2 )
and TV’s (V3 ) sound, unintentionally triggering apps conditioned 5.1.3 Comparison with Previous Work. In Table 4, we compare
on sound-detected. For example, App9 turns on the garbage disposal the policy violations flagged by IoTSeer with the most applicable
at a user-defined time, and App19 notifies the user when sound is approaches, iRuler [61], IoTMon [22], and IoTSafe [23], that run on
detected, creating unnecessary panic. IoT app source code to identify physical interaction vulnerabilities.
Aggregation Policy (G2 ) Violations. IoTSeer flagged three ag- To identify physical interactions among apps, iRuler uses device
gregation policy (G2 ) violations among one group of devices. The behavioral models (e.g., AC-on decreases the temperature by 1°C ev-
sound sensor outputs a sound-detected event due to the unintended ery hour), and IoTMon mines the apps’ text descriptions (e.g., finds
aggregated influence from AC-on, washer-on, and dryer-on. This, in AC is semantically related to temperature). If we assume they cor-
turn, triggers three apps conditioned on the sound-detected event rectly map all physical channels that each command influences in
and causes light-on, TV-on, and call-user actions. our smart home, iRuler cannot identify any of IoTSeer’s violations,
Bypass Policy (G3 ) Violations. IoTSeer identified a single bypass and IoTMon can identify 2 out of 16 violations. This is because (1)
policy (G3 ) violation. The illuminance sensor measures the aggre- their policies cannot reason about the intended use of apps, (2) they
gated illuminance of light-on and TV-on. The increase in illuminance do not consider the complex physical properties such as aggregation
triggers App34 , turning off the lights. However, App34 ’s intended oper- and dependency, and (3) iRuler does not consider device-centric
ation is turning off the lights when the daylight is enough to illumi- vulnerabilities. Additionally, IoTMon would flag 18 false positives
nate the environment, which is semantically related to the light-on as most commands do not individually cause physical interactions.
action. Therefore, light-on’s influence on App34 ’s sensor event is To illustrate, it defines a physical channel between the temperature
intended, whereas TV-on’s influence is unintended. Since light-on’s sensor and oven; yet oven-on’s individual influence on temperature
individual influence cannot trigger App34 ’s light-detected event is not enough to cause an interaction.
but its influence aggregated with the unintended influence from IoTSafe models the apps’ physical behavior through dynamically
TV-on triggers it, the app’s intended use is bypassed. collected sensor traces and predicts physical channel values at run-
time for policy enforcement. Compared to IoTMon, IoTSafe does not
flag any false positives since it relies on sensor traces collected from
5.1.2 Device-Centric Policy Violations. IoTSeer identified two device- real devices. However, it can also detect only 2 out of 16 violations
centric policy violations, V6 between three apps and V7 between four in our smart home. This is because, as a run-time enforcement
apps. In V6 , while the home is in sleep mode, the AC’s influence system, it cannot infer the influence of an exact command on a
on temperature triggers App23 to turn on the bulb. This violates physical channel. Additionally, its policy enforcement may create
DC8 since the bulb is turned on when the home mode is sleep. In unnecessary panic in our home since the robot vacuum’s motion
V7 , two physical interactions occur due to UnInt and Int channels. would trigger its policy that sounds an alarm and sends a message
While the home mode is away, the vacuum’s UnInt motion triggers to the user when motion is detected.
Discovering IoT Physical Channel Vulnerabilities CCS ’22, November 7–11, 2022, Los Angeles, CA, USA

motion- App27: Table 5: The physical channels that cause policy violations
App17:
Motion vacuum-on Motion
detected door-unlock after new device placement, and their tolerance to errors.
Sensor Sensor
Motion Not Motion
Detected Detected
Physical Channel Tolerance to Distance Error
washer-on ∼∼ sound-detected 20%
Figure 8: Illustration of the V1 violation. dryer-on ∼∼ sound-detected > 50%
TV-on ∼∼ sound-detected > 50%

5.1.4 In-Home Validation Experiments. We repeated each identified

violation in the actual house and confirmed that they (V1 -V7 ) are true IoTSeer’s Tolerance to Errors in Distance Parameter. Errors
positives. In-home validation begins by analyzing each violation’s in the distance parameter may occur due to slight deviations in
root cause through their (inputs, apps, dist, atime, y) logged by the accuracy of IoT device localization tools and RSSI-based lo-
IoTSeer. We activate each actuator involved in the violation using its calization techniques. Such errors do not impact IoTSeer’s ability
inputs and atime. We record the traces and confirm the interacting to discover the initial policy violations since IoTSeer integrates SI
apps. Lastly, we compare traces from PeMs and devices to identify to tune the PeMs based on real device traces. However, the errors
any differences in the time the violations occur. may impact IoTSeer’s effectiveness in identifying violations after
We observe that policy violations on continuous physical chan- a device’s location is changed. Thus, we introduce errors ranging
nels (temperature) occur later in the house compared to CPeM. For from ±10%-50% to the distance parameter when the placements of
instance, when heater-on is invoked at time 0 in the CPeM, IoT- devices are changed and check if IoTSeer outputs any false positive
Seer flags a DC9 violation at second 56. However, we observe the or negative violations. We select these error rates because IoTSeer’s
violation at second ≈ 65 in the house. In contrast, violations on RSSI-based distance estimation gives, on average, a 22.8% error
instant channels (motion, sound, and illuminance) occur with minor in our setup, and the only error higher than 50% is the estimation
time deviations. These slight timing deviations are expected due to between the TV and sound sensor (due to the wall between devices).
inevitable environmental noise. Table 5 presents the maximum error in distance parameters
Case Study. We present a case study to illustrate a violation and de- under which IoTSeer can still correctly identify the violations. For
tail an attack scenario demonstrating how an adversary can exploit instance, if IoTSeer estimates the distance between the washer
the observed physical interaction. Figure 8 depicts the V1 violation; and sound sensor with a 20% error, it can still correctly identify
a motion-detected event occurs due to the robot-vacuum-start com- these devices’ policy violations. However, if the error is larger than
mand and triggers App27 that unlocks the door. To exploit this, an 20%, IoTSeer would miss the violations, causing false negatives. On
adversary can leverage a vulnerability in the vacuum controller the contrary, IoTSeer’s dryer and TV PeMs are more tolerant to
app to start it and stealthily unlock the door. The adversary can error, where they correctly identify the violations even under 50%
also wait until the user sets the home mode to away, which trig- error. This is because these devices’ influences on sound are higher,
gers App17 that turns on the vacuum and causes the door to unlock. enabling IoTSeer to identify their interactions.
Through this attack, the adversary can break into the house. We further checked whether the errors in the distance parameter
cause any false positives, where IoTSeer flags violations that do not
5.2 Violations with Device Placement Changes actually occur. We found that IoTSeer identifies two false positives
We change the placement of illuminance, sound sensors, and the TV if the distance error is 50%, (1) the bulb-on’s illuminance PeM, and (2)
and use IoTSeer to identify the policy violations that occur with the the AC-on’s sound PeM. Yet, such high errors are unlikely in practice
new placement. We select these devices as they are easily relocated since IoTSeer integrates state-of-the-art localization techniques.
and potentially impact nine policy violations.
IoTSeer correctly identifies that three physical channels that 5.3 Performance Evaluation
caused policy violations in the initial placement do not occur any- 5.3.1 Scalability Experiments. We evaluate the policy validation
more, and it discovers two new physical channels causing violations. time of IoTSeer’s falsification algorithm and compare its results with
We then evaluate the impact of the distance parameter’s accuracy the baseline approach of grid-testing. Grid-testing discretizes the
in identifying policy violations and show that IoTSeer only misses times when apps activate actuators as a grid and validates policies
a single violation when the distance parameter has a 50% error. with all combinations of activation times. Although grid-testing
Violations After New Device Placement. Table 5 presents the identifies all 16 violations in our experiments, it yields a high time
physical channels that cause policy violations after the device place- overhead, as detailed below.
ment changes. IoTSeer identified three physical channels (V2 , V4 , CPeM Size vs. Time. Figure 9a shows the policy validation time
and V5 ) that caused policy violations before do not occur in the new of the grid-testing and falsification with an increasing number of
device placement. On the contrary, TV-on command still creates a command PeMs influencing the same channel in the CPeM. Testing
sound-detected event, unintentionally triggering two apps. time exponentially increases with the number of commands as each
IoTSeer also flagged two new physical channels that cause policy policy is validated using a combination of apps’ activation times.
violations, where the washer’s and dryer’s sound cause G1 violations In contrast, falsification has a near-constant time overhead as it
since the sound sensor was moved closer to them. We confirmed samples activation times and searches for low robustness values
with in-home experiments that all identified policy violations with for a single violation. This adds a negligible delay, on the order of
the new device placement are true positives. seconds, with an increasing number of commands.
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA Ozmen et al.

350
105 Table 6: Mitigated policy violations with different methods.
Grid-Testing
Grid-Testing
Falsification
300 Falsification
4
10
250
Policy
Time (s) (log)

Time (s)
103 200 Mitigation Method G1 G2 G3 DC
2 150 Patching the App Code 10/10 3/3 1/1 0/2
10
100
Device Placement Changes 10/10 3/3 1/1 2/2
101 Removal of Apps 10/10 3/3 1/1 2/2
50

100 0
1 2 3 4 5 6 1 2 3 4 5
# Influencing Actuation Commands # Policies

(a) (b)
user may prefer this method if an app is not critically needed and
Figure 9: (a) #Actuation commands and (b) #Policies vs. time. other mitigation techniques are not feasible.
For the 16 identified policy violations, we applied the above miti-
gation methods and evaluated their effectiveness. Table 6 shows the
number of policy violations prevented by our mitigation methods.
Number of Policies vs. Time. We evaluate the validation time First, patching the app code prevents 14 out of 16 violations as it in-
with an increasing number of policies. We set the number of com- serts predicates that guard the unintended physical interactions. For
mand PeMs to three, and a sensor measures their aggregated physi- instance, V1 is patched by adding a condition to the apps triggered
cal influence. Figure 9b shows the time overhead of both testing and by the motion detected event. The condition checks whether the
falsification increases linearly with the number of policies. Here, robot vacuum is not on before sending the app’s commands. Second,
falsification is ≈ 3× more efficient than testing as testing validates changing the device placement prevents all violations. We validate
the policies with all combinations of apps’ activation times. this through in-home experiments with increased distance between
the devices in the policy violations. For instance, increasing the
5.3.2 Time for Device Trace Collection. We present the time for ac-
distance from the garbage disposal to the sound sensor prevents
tuator and sensor trace collection from actual devices to tune CPeM
V2 as garbage-disposal-on’s sound cannot reach the sensor. Finally,
parameters. It took 7 hours to record the measurements from actual
removing the apps involved in the physical interactions prevents
sensors, which required turning on each actuator and collecting
all violations, e.g., removing a single app from the three apps that
traces from all sensors in the smart home. This is an improvement
cause the V6 violation prevents it.
over generating generic flow functions by SI solely using device
We note that our mitigation methods may prevent desired actions
traces, which requires ≈ 175 hours of data collection with different
while eliminating dangerous app interactions. First, code patching
device properties and distances.
blocks actions while actuators that unintentionally influence a
physical channel are turned on, yet, a user may desire to issue
6 DISCUSSION & LIMITATIONS those actions. In such cases, the user can manually activate them
Mitigating the Policy Violations. IoTSeer identifies policy viola- and respond to the app interactions. Second, changing a device’s
tions and presents users with a report that details the violation’s placement may be inconvenient for the user, and it may cause
root cause. However, there is a need to mitigate the policy viola- other policy violations. However, IoTSeer can identify new policy
tions to ensure the safe and secure operation of the smart home. violations by updating its distance parameters and running its
We discuss three methods for mitigation, (1) patching the app code, security analysis module. Lastly, removing an app eliminates all
(2) device placement changes, and (3) removal of apps. of its interactions; however, users may not desire to remove the
The first mitigation technique is patching the app code to block apps they need. In future work, we will conduct user studies to
its commands if the app is triggered due to an unintended influence. learn how users perceive the mitigation methods and investigate
This technique adds a code block that guards an app’s action with a advanced techniques for automated patching. For instance, we will
predicate conditioned on the devices that unintentionally influence explore automated distance range discovery through parameter
the app’s sensor event. If a device is unintentionally influencing mining [36] to find the specific distance ranges between actuators
a channel, the predicate becomes false, preventing the app from and sensors that can prevent all policy violations.
issuing its command. For instance, the V4 violation is prevented Manual Effort Required. IoTSeer requires users’ effort in deter-
by adding a predicate to the apps conditioned on sound-detected. mining the distance parameter in the CPeM and the Int/UnInt labels
The predicate blocks apps’ actions if the AC, washer, and dryer are for intent-based policies. First, the users need to confirm that the dis-
simultaneously turned on, preventing the unintended interactions. tances found from RSSI-based localization are correct and provide
Second, we recommend users increase the distance between the the distances manually if necessary. This effort is not a significant
actuator and sensor to prevent policy violations. This is because a burden for users since they can provide approximate distances.
command’s influence on sensor readings monotonically decreases This is because IoTSeer can tolerate small errors in the distance
as the distance between the actuator and sensor increases [60, 67]. parameter, as shown in our evaluation. Second, although IoTSeer
For instance, operating the robot vacuum away from the motion generates Int/UnInt labels between commands and apps, the users
sensor (e.g., by setting ‘keep out zones’) prevents the motion from may have different intentions than the generated ones. Therefore,
vacuum-on from triggering events. Lastly, removing one or more they need to check the labels and update them if necessary based
apps involved in the physical interaction prevents a violation. A on their intended use of the actuators and apps.
Discovering IoT Physical Channel Vulnerabilities CCS ’22, November 7–11, 2022, Los Angeles, CA, USA

Table 7: Comparison of IoTSeer with IoT security systems. both discrete and continuous behaviors. In contrast, IoTSeer extends
optimization-guided falsification for scalable policy validation.
Physical Channel Properties Security Analysis
Labels Time Policy
System Dist. Agg. Dep. Composition
(Int/UnInt) Constraints Validation†
IotGuard∗ [19] ✗ ✗ ✗ ✗ ✗ ✗ RA
8 CONCLUSIONS
IoTSafe∗ [23] ✗ ✓ ✓ ✗ ✗ ✗ RP
MenShen [13] ✗ ✗ ✗ ✗ ✗ ✗ RA
We introduce IoTSeer, which identifies the physical channel vul-
iRuler [61] ✗ ✗ ✗ ✗ ✗ ✗ RL nerabilities in smart homes. IoTSeer combines static app analysis
IoTCom [5] ✗ ✗ ✗ ✗ ✗ ✗ MC
IoTMon [22] ✗ ✗ ✗ ✗ ✗ ✗ N/A
with system identification to precisely model the composite phys-
IoTSeer ✓ ✓ ✓ ✓ ✓ ✓ F ical behavior of apps and uses falsification to validate identified
∗ IoTGuard and IoTSafe are run-time policy enforcement systems. physical channel policies. Our evaluation in a real house demon-
† RA: Reachability Analysis, RL: Rewriting Logic, MC: Model Checking, F: Optimization-guided
Falsification, RP: Run-time Prediction. strates that many apps interact over physical channels, and IoTSeer
efficiently and effectively identifies all policy violations. This paper
is an important step forward in achieving the compositional safety
and security of an IoT system’s physical behavior.
Environmental Noise. The environment that the devices operate
in may influence the physical channels and impact the app interac-
tions. As IoTSeer leverages SI to tune CPeM parameters, it integrates ACKNOWLEDGMENTS
various environmental impacts such as room layout and furniture. We would like to thank Engin Masazade and Ali Cem Kizilalp for
Yet, human activities and uncontrolled environmental noise may their feedback on the earlier version of this paper. This work has
also influence sensor measurements. To measure the impact of been partially supported by the National Science Foundation (NSF)
human activities, we conducted additional experiments while a under grants CNS-2144645, 1901242, and 1910300, DARPA VSPELLS
user was cooking and exercising. We have found that the users do under grant HR001120S0058, Rolls-Royce Cyber Technology Re-
not introduce detectable changes to sensors. We have shown in search Network Award, National Natural Science Foundation of
in-home validation experiments that uncontrolled noise causes the China (No. 61702263), and the scholarship from China Scholarship
violations to occur at slightly different times. Council (No. 201906845026). The views expressed are those of the
authors only.
7 RELATED WORK
In Table 7, we compare IoTSeer with several recent approaches that REFERENCES
focus on identifying the vulnerabilities that IoT app interactions [1] Houssam Abbas, Georgios Fainekos, Sriram Sankaranarayanan, Franjo Ivančić,
present. These approaches can be classified into two categories: and Aarti Gupta. 2013. Probabilistic temporal logic falsification of cyber-physical
systems. ACM Transactions on Embedded Computing Systems (TECS).
run-time policy enforcement and static analysis for IoT apps. [2] Houssam Abbas, Hans Mittelmann, and Georgios Fainekos. 2014. Formal property
Run-time Policy Enforcement. IoTGuard [19] instruments apps verification in a conformance testing framework. In ACM/IEEE Conference on
Formal Methods and Models for Codesign (MEMOCODE).
to build dynamic models and enforces policies at run-time. Yet, it [3] Abbas Acar, Hossein Fereidooni, Tigist Abera, Amit Kumar Sikder, Markus Miet-
cannot correctly identify physical interactions since its models do tinen, Hidayet Aksu, Mauro Conti, Ahmad-Reza Sadeghi, and A Selcuk Uluagac.
2018. Peek-a-Boo: I see your smart home activities, even encrypted! arXiv
not include the commands’ physical influences. preprint arXiv:1808.02741.
IoTSafe [23] collects actuator and sensor traces to identify physi- [4] Omotayo G Adewumi, Karim Djouani, and Anish M Kurien. 2013. RSSI based
cal interactions and builds physical models for continuous physical indoor and outdoor distance estimation for localization in WSN. In IEEE Interna-
tional Conference on Industrial Technology (ICIT).
channels to predict incoming policy violations at run-time. How- [5] Mohannad Alhanahnah, Clay Stevens, and Hamid Bagheri. 2020. Scalable analysis
ever, it cannot identify intent-based violations as its policies are of interaction threats in IoT systems. In ACM SIGSOFT International Symposium
only defined based on the use cases of devices, and it cannot de- on Software Testing and Analysis.
[6] Rajeev Alur, Costas Courcoubetis, Nicolas Halbwachs, Thomas A Henzinger,
termine the specific command that influences a physical channel Pei-Hsin Ho, Xavier Nicollin, Alfredo Olivero, Joseph Sifakis, and Sergio Yovine.
from examining sensor measurements at run-time. Additionally, 1995. The algorithmic analysis of hybrid systems. Theoretical Computer Science.
[7] Yashwanth Singh Rahul Annapureddy and Georgios E Fainekos. 2010. Ant
IoTSafe does not consider distance in its models and flags incorrect colonies for temporal logic falsification of hybrid systems. In Annual Conference
violations or fails to detect a violation when a device’s placement is on IEEE Industrial Electronics Society.
changed. These systems motivate the need for IoTSeer, which can [8] Yashwanth Annpureddy, Che Liu, Georgios Fainekos, and Sriram Sankara-
narayanan. 2011. S-taliro: A tool for temporal logic falsification for hybrid
precisely identify dangerous physical interactions before the smart systems. In International Conference on Tools and Algorithms for the Construction
home’s run-time operation. and Analysis of Systems. Springer.
[9] Ardupilot SITL 2022. Ardupilot Simulation. https://ardupilot.org/dev/docs/
Static Analysis of IoT Apps. Existing static analysis systems do simulation-2.html. [Online; accessed 18-April-2022].
not model apps’ complex physical behavior. Instead, they build indi- [10] Musard Balliu, Massimo Merro, and Michele Pasqua. 2019. Securing cross-app
vidual physical channel mappings, generate naive device behavioral interactions in IoT platforms. In IEEE Computer Security Foundations Symposium.
[11] Musard Balliu, Massimo Merro, Michele Pasqua, and Mikhail Shcherbakov. 2020.
models [13, 61], or use natural language processing [22] to infer Friendly Fire: Cross-App Interactions in IoT Platforms. ACM Transactions on
interacting apps. Thus, they identify limited physical interactions Privacy and Security (TOPS).
[12] Louis A Bloomfield. 2007. How everything works: making physics out of the
and lead to false positives. As presented in Table 7, IoTSeer is the ordinary. John Wiley & Sons.
first to integrate the complex physical properties of commands and [13] Lei Bu, Wen Xiong, Chieh-Jan Mike Liang, Shi Han, Dongmei Zhang, Shan Lin,
sensor events into the source code of IoT apps (“Physical Channel and Xuandong Li. 2018. Systematically ensuring the confidence of real-time
home automation IoT systems. ACM Transactions on Cyber-Physical Systems.
Properties” Columns). Additionally, their validation techniques can- [14] R Bukowski, R Peacock, J Averill, T Cleary, N Bryner, W Walton, P Reneke, and
not readily be used to verify physical interactions as apps exhibit E Kuligowski. 2003. Performance of home smoke alarms. NIST Tech. Note.
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA Ozmen et al.

[15] Carla Physics 2022. Carla - Control and Monitor Vehicle Physics. https://carla. and Technologies.
readthedocs.io/en/latest/tuto_G_control_vehicle_physics/. [Online; accessed [46] Justin Norden, Matthew O’Kelly, and Aman Sinha. 2019. Efficient black-box
18-April-2022]. assessment of autonomous vehicle safety. arXiv preprint arXiv:1912.03618.
[16] Z Berkay Celik, Earlence Fernandes, Eric Pauley, Gang Tan, and Patrick McDaniel. [47] OpenHab 2022. OpenHAB: Open Source Automation Software for Home. https:
2019. Program analysis of commodity IoT applications for security and privacy: //www.openhab.org/. [Online; accessed 30-April-2022].
Challenges and opportunities. ACM Computing Surveys (CSUR). [48] Erion Plaku, Lydia E Kavraki, and Moshe Y Vardi. 2009. Falsification of LTL safety
[17] Z Berkay Celik, Patrick McDaniel, and Gang Tan. 2018. Soteria: Automated IoT properties in hybrid systems. In International Conference on Tools and Algorithms
safety and security analysis. In USENIX Annual Technical Conference (USENIX for the Construction and Analysis of Systems. Springer.
ATC). [49] Claudius Ptolemaeus (Ed.). 2014. System Design, Modeling, and Simulation using
[18] Z Berkay Celik, Patrick McDaniel, Gang Tan, Leonardo Babun, and A Selcuk Ptolemy II. Ptolemy.org. http://ptolemy.org/books/Systems
Uluagac. 2019. Verifying internet of things safety and security in physical spaces. [50] PX4 SITL 2022. PX4 Simulation. https://docs.px4.io/master/en/simulation/.
IEEE Security & Privacy. [Online; accessed 18-April-2022].
[19] Z Berkay Celik, Gang Tan, and Patrick D McDaniel. 2019. IoTGuard: Dynamic [51] Philippe Réfrégier. 2004. Noise theory and application to physics: from fluctuations
Enforcement of Security and Safety Policy in Commodity IoT. In NDSS. to information. Springer Science & Business Media.
[20] Haotian Chi, Qiang Zeng, Xiaojiang Du, and Jiaping Yu. 2020. Cross-app interfer- [52] Agustin Salazar. 2003. On thermal diffusivity. European Journal of Physics.
ence threats in smart homes: Categorization, detection and handling. In IEEE/IFIP [53] Scilab 2022. Scilab: Open source software for numerical computation. https:
International Conference on Dependable Systems and Networks (DSN). //www.scilab.org/. [Online; accessed 15-April-2022].
[21] Anthony Corso, Robert J Moss, Mark Koren, Ritchie Lee, and Mykel J Kochender- [54] Rahul Anand Sharma, Elahe Soltanaghaei, Anthony Rowe, and Vyas Sekar. 2022.
fer. 2020. A survey of algorithms for black-box safety validation. arXiv preprint Lumos: Identifying and Localizing Diverse Hidden IoT Devices in an Unfamiliar
arXiv:2005.02979. Environment. In USENIX Security.
[22] Wenbo Ding and Hongxin Hu. 2018. On the safety of IoT device physical inter- [55] SpaceEx 2022. SpaceEx: State Space Explorer. http://spaceex.imag.fr/. [Online;
action control. In ACM SIGSAC Conference on Computer and Communications accessed 15-April-2022].
Security (CCS). [56] Milijana Surbatovich, Jassim Aljuraidan, Lujo Bauer, Anupam Das, and Limin Jia.
[23] Wenbo Ding, Hongxin Hu, and Long Cheng. 2021. IoTSafe: Enforcing Safety and 2017. Some recipes can do more than spoil your appetite: Analyzing the security
Security Policy with Real IoT Physical Interaction Discovery. In NDSS. and privacy risks of IFTTT recipes. In International Conference on World Wide
[24] Isaac Elishakoff. 2000. Whys and hows in uncertainty modelling. Springer. Web.
[25] Georgios Fainekos, Bardh Hoxha, and Sriram Sankaranarayanan. 2019. Robust- [57] Yuan Tian, Nan Zhang, Yueh-Hsun Lin, XiaoFeng Wang, Blase Ur, Xianzheng
ness of Specifications and Its Applications to Falsification, Parameter Mining, Guo, and Patrick Tague. 2017. Smartauth: User-centered authorization for the
and Runtime Monitoring with S-TaLiRo. In International Conference on Runtime internet of things. In USENIX Security.
Verification. Springer. [58] Blase Ur, Melwyn Pak Yong Ho, Stephen Brawner, Jiyun Lee, Sarah Mennicken,
[26] Chenglong Fu, Qiang Zeng, and Xiaojiang Du. 2021. HAWatcher: Semantics- Noah Picard, Diane Schulze, and Michael L Littman. 2016. Trigger-action pro-
Aware Anomaly Detection for Appified Smart Homes. In USENIX Security. gramming in the wild: An analysis of 200,000 IFTTT recipes. In CHI Conference
[27] Leon R Glicksman and Steven Taub. 1997. Thermal and behavioral modeling of on Human Factors in Computing Systems.
occupant-controlled heating, ventilating and air conditioning systems. Energy [59] JT Van Ginkel and E Hasselaar. 2006. Moisture balance in dwellings. Healthy
and Buildings. Buildings proceedings; Design and operation of healthy buildings.
[28] GNU Octave 2022. GNU Octave: Scientific Programming Language. https: [60] Nikolaos Voudoukis and Sarantos Oikonomidis. 2017. Inverse square law for light
//www.gnu.org/software/octave/. [Online; accessed 15-April-2022]. and radiation: A unifying educational approach. European Journal of Engineering
[29] Patrice Godefroid, Michael Y Levin, and David A Molnar. 2008. Automated Research and Science.
Whitebox Fuzz Testing. In NDSS. [61] Qi Wang, Pubali Datta, Wei Yang, Si Liu, Adam Bates, and Carl A Gunter. 2019.
[30] Rafal Goebel, Ricardo G Sanfelice, and Andrew R Teel. 2009. Hybrid dynamical Charting the Attack Surface of Trigger-Action IoT Platforms. In ACM SIGSAC
systems. IEEE Control Systems Magazine. Conference on Computer and Communications Security (CCS).
[31] Furkan Goksel, Muslum Ozgur Ozmen, Michael Reeves, Basavesh Shivakumar, [62] Ethan Winer. 2012. The audio expert: everything you need to know about audio.
and Z Berkay Celik. 2021. On the safety implications of misordered events and CRC Press.
commands in IoT systems. In IEEE Security and Privacy Workshops (SPW). [63] Giovanni Zanca, Francesco Zorzi, Andrea Zanella, and Michele Zorzi. 2008. Ex-
[32] Matthew J Hancock. 2006. The 1-D heat equation. MIT OpenCourseWare. perimental comparison of RSSI-based localization algorithms for indoor wireless
[33] Thomas A Henzinger, Peter W Kopke, Anuj Puri, and Pravin Varaiya. 1998. sensor networks. In Proceedings of the Workshop on Real-World Wireless Sensor
What’s decidable about hybrid automata? J. Comput. System Sci. Networks.
[34] Joseph Hilsenrath. 1955. Tables of thermal properties of gases: comprising tables [64] Zapier 2022. Zapier: Connect your apps and automate workflows. https://zapier.
of thermodynamic and transport properties of air, argon, carbon dioxide, carbon com/. [Online; accessed 30-April-2022].
monoxide, hydrogen, nitrogen, oxygen, and steam. US Department of Commerce, [65] Lefan Zhang, Weijia He, Jesse Martinez, Noah Brackenbury, Shan Lu, and Blase
National Bureau of Standards. Ur. 2019. AutoTap: synthesizing and repairing trigger-action programs using
[35] HomeKit 2022. Apple’s HomeKit. https://www.apple.com/ios/home/. [Online; LTL properties. In 2019 IEEE/ACM 41st International Conference on Software
accessed 30-April-2022]. Engineering (ICSE).
[36] Bardh Hoxha, Adel Dokhanchi, and Georgios Fainekos. 2018. Mining parametric [66] Valerie Zhao, Lefan Zhang, Bo Wang, Shan Lu, and Blase Ur. 2020. Visualizing
temporal logic properties in model-based design for cyber-physical systems. Differences to Improve End-User Understanding of Trigger-Action Programs. In
International Journal on Software Tools for Technology Transfer. CHI Conference on Human Factors in Computing Systems.
[37] IFTTT 2022. IFTTT (If This Then That). https://ifttt.com/. [Online; accessed [67] Alexander Zhivov, Hakon Skistad, Elisabeth Mundt, Vladimir Posokhin, Mike
18-April-2022]. Ratcliff, Eugene Shilkrot, and Andrey Strongin. 2001. Principles of air and con-
[38] AG Jackson, SJP Laube, and J Busbee. 1996. Sensor principles and methods for taminant movement inside and around buildings. In Industrial Ventilation Design
measuring physical properties. JOM. Guidebook. Elsevier.
[39] Karel J Keesman. 2011. System identification: an introduction. Springer Science & [68] Aditya Zutshi, Jyotirmoy V Deshmukh, Sriram Sankaranarayanan, and James
Business Media. Kapinski. 2014. Multiple shooting, cegar-based falsification for hybrid systems.
[40] Mark G Lawrence. 2005. The relationship between relative humidity and the In International Conference on Embedded Software.
dewpoint temperature in moist air: A simple conversion and applications. Bulletin
of the American Meteorological Society.
[41] T G Lee and George W Mulholland. 1977. Physical Properties of Smokes Pertinent
to Smoke Detector Technology. Final Report. NIST Interagency/Internal Report A APPENDIX GUIDE
(NISTIR). This Appendix provides the information necessary to reproduce
[42] Nancy Lynch, Roberto Segala, and Frits Vaandrager. 2003. Hybrid I/O automata.
Information and Computation. our results. In Appendix B, we present the identified device-centric
[43] Sunil Manandhar, Kevin Moran, Kaushal Kafle, Ruhao Tang, Denys Poshyvanyk, policies. In Appendix C, we describe the CPeM fidelity experiments
and Adwait Nadkarni. 2020. Towards a Natural Perspective of Smart Homes
for Practical Security and Safety Analyses. In IEEE Symposium on Security and
and present our numerical results. In Appendix D, we present an
Privacy (S&P). example CPeM developed with Simulink. In Appendix E, we detail
[44] Fedor Mitschke. 2009. Decibel units. In Fiber Optics. Springer. the apps considered in our evaluation. In Appendix F, we present the
[45] Dang Tu Nguyen, Chengyu Song, Zhiyun Qian, Srikanth V Krishnamurthy,
Edward JM Colbert, and Patrick McDaniel. 2018. IoTSan: Fortifying the safety flow functions of studied actuation commands and sensor events.
of IoT systems. In International Conference on Emerging Networking Experiments In Appendix G, we present the influence of actuation commands on
Discovering IoT Physical Channel Vulnerabilities CCS ’22, November 7–11, 2022, Los Angeles, CA, USA

Table 8: Device-centric security policies.

ID Policy Description Formal Representation

The sprinkler system must go off
DC1 □(fire → 3 [0,t] sprinkler-on)
within t seconds when there is a fire.
When the home is in the away mode, 𝜖 – deviation score
DC2 □(mode-away → window-close) 𝜏 – timing difference
the window must be closed.
A device must not open, then close and
DC3 □¬(on ∧ #3 [0,t] (off ∧ #3 [0,t] on))
then reopen (actuation loop) within t seconds.
The window must not open
DC4 □(heater-on → ¬window-open)
when the heater is on.
The alarm must go off within t seconds
DC5 □(smoke-detected → 3 [0,t] alarm-on)
after smoke is detected. (a) (b)
The main door must not be left
DC6 3 [0,t] door-lock
unlocked for more than t seconds.
DC7
The window must not be open
□(AC-on → ¬window-open)
Figure 10: PeM and device traces: (a) bulb-on changes the illu-
when the AC is on.
The lights must be turned off when
minance sensor readings and (b) oven-on changes the temper-
DC8 □(mode-sleep → light-off)
the home is in the sleep mode. ature sensor readings.
The door must always be locked and lights
DC9 □(mode-away → door-lock ∧ light-off)
must be off when the home is in the away mode.
The TV must be turned off when
DC10 □((mode-away ∨ mode-sleep) → TV-off)
the home is in the away or sleep mode.

Table 9: (𝜏, 𝜖)-closeness of CPeM and actual IoT devices.

Temperature Illum. Sound Humidity Motion Smoke

Actuator 𝜏 𝜖 𝜏 𝜖 𝜏 𝜖 𝜏 𝜖 𝜏 𝜖 𝜏 𝜖
Heater 8.2 ± 4.3 0 N/A N/A 5.2 ± 1.8 3.2 ± 1.1 N/A N/A
Oven 0.8 ± 1.9 0 N/A N/A 1.3 ± 2.9 0 N/A N/A
Pressure Cooker 1 ± 2.1 0.4 ± 0.8 N/A N/A 1 ± 2.2 0.4 ± 0.9 N/A N/A
Coffee maker 0 0 N/A N/A 0 0 N/A N/A
DeHumidifier N/A N/A N/A 0 0 N/A N/A
Clothes Washer N/A N/A 0 0.2 ± 0.4 0 0 N/A N/A
Dryer 0 1.1 ± 2.4 N/A 0 0.2 ± 0.4 0 1.2 ± 2.7 N/A N/A
Humidifier N/A N/A N/A 0.6 ± 1.4 1.6 ± 0.9 N/A N/A
Garbage Disposal N/A N/A 0 0.2 ± 0.4 N/A N/A N/A
TV N/A 0 18.7 ± 37 0 0 N/A N/A N/A
Vacuum Robot N/A N/A N/A N/A 0.26 ± 0.07 0 N/A
Light Bulb N/A 0 20.2 ± 4.3 N/A N/A N/A N/A
AC 9.6 ± 3.4 0 N/A 0 0.4 ± 0.5 3.2 ± 2 1.2 ± 1.1 N/A N/A Figure 11: Simulink CPeM of the light-bulb-on, TV-on actuation
Door Lock N/A N/A 0 0 N/A N/A N/A commands, and the light-detected event.
Measurement units: 𝜏: minutes; 𝜖: depends on the physical quantity; Motion, smoke, sound:
binary; Illuminance: luminous flux; Temperature: °F; Humidity: RH%.

physical channels, the distances between the actuators and sensors, distances. We observe slight deviations in temperature, illuminance,
and the sensor sensitivity levels. We note that IoTSeer contains all sound, and humidity sensor PeM outputs and no deviation in motion
tools necessary to extend the CPeM to other apps and allows for sensor PeM outputs. This shows that our actuator and sensor PeMs
replacing the flow functions of studied actuation commands and have high fidelity with actual device traces. The slight deviations
sensor events with the ones that may be a better contextual fit. are due to the uncertainties in the environmental factors (e.g., the
sunlight amount in the room [24]) that impact actual device traces.
B DEVICE-CENTRIC POLICIES To illustrate, Figure 10 plots the traces from PeMs and actual
We present the identified device-centric policies in Table 8. device experiments of light-bulb-on’s influence on the illuminance
sensor and oven-on’s influence on the temperature sensor. We found
C CPEM FIDELITY EXPERIMENTS the bulb-on PeM deviates on average ≈ 20 lux from device traces.
Additionally, oven-on increases the temperature sensor readings by
We evaluate the fidelity of CPeM compared to the actual devices.
1.8°F in both PeM and actual device traces at 0.5 meters. The PeM
We select all actuation command and sensor pairs where the sensor
yields an increase at minute 19.6, but the increase in the device
measures the command’s influence. We set the distance in each
traces occurs at minute 23.8. This leads to 𝜏 = 0.8 ± 1.9 timing
pair to 0.5 m - 2.5 m with 0.5 m intervals. We collect PeM and real
difference and 𝜖 = 0 deviation score. As detailed in Sec. 5.1, these
device traces for each distance to evaluate their fidelity.
lead to safe over-approximations in detecting violations at slightly
We compute the (𝜏, 𝜖)-closeness of actual device traces with the
different times.
PeM traces to measure CPeM fidelity. Let x be a PeM’s traces, and y be
the real device traces generated with the same inputs. Given T ∈ R+ ,
and (𝜏, 𝜖) ≥ 0, we determine x and y are (𝜏, 𝜖)-close if for all t ∈ x, D SIMULINK CPEM EXAMPLE
t ≤ T, there exists s ∈ y where |t − s| ≤ 𝜏, and |x(t) − y(s)| ≤ 𝜖, The CPeM of light-bulb-on, TV-on commands, and the light-detected
and for all t ∈ y, t ≤ T, there exists s ∈ x where |t − s| ≤ 𝜏 and event is presented in Figure 11. The actuation command and sen-
|y(t) − x(s)| ≤ 𝜖. sor event PeMs (including their flow functions) are implemented
Table 9 details the (𝜏, 𝜖)-closeness of actual device traces with with Matlab functions in the Simulink boxes. Our implementation
the PeM traces. Each row includes the mean and standard deviation can be easily migrated to other software such as GNU Octave [28],
of the timing difference (𝜏) and deviation score (𝜖) over different Scilab [53], and SpaceEx [55] with third-party code converters.
CCS ’22, November 7–11, 2022, Los Angeles, CA, USA Ozmen et al.

Table 10: Apps in our experiments and their descriptions.

T(e, 0) = T0 (2)
ID Description
App1 Activates the heater at a user-defined time T(0, 0) = Ts (3)
App2 Activates the oven at a user-defined time
App3 Activates the pressure cooker at a user-defined time In the formula, T is the temperature in °K , x is the distance from
App4 Activates the coffee maker at a user-defined time
the actuator in meters, 𝛼 is the thermal diffusivity constant (in
App5 Activates the dehumidifier at a user-defined time
App6 Activates the clothes washer at a user-defined time m2 /s), e is the maximum distance from the source, and Ts is the
App7 Activates the dryer at a user-defined time temperature of the source. We set the thermal diffusivity to 2.2·10 −5
App8 Activates the humidifier at a user-defined time m2 /s as a constant [34, 52].
App9 Activates the garbage disposal at a user-defined time
App10 Activates the TV at a user-defined time On the other hand, HVAC systems (e.g., heater and AC) influence
App11 Activates the robot vacuum at a user-defined time temperature with an airflow to ensure quick heat dissipation (due to
App12 Activates the light bulb at a user-defined time convection). In particular, the airflow of the HVAC systems enables
App13 Activates the AC at a user-defined time
App14 Locks the door at a user-defined time
them to uniformly influence different locations [27]. Therefore,
App15 Turns on “away mode” at a user-defined time we construct their flow functions through ordinary differential
App16 Turns on “sleep mode” at a user-defined time equations [30].
App17 Activates robot vacuum when the home mode is set to “away” or “vacation”
App18 Turns on the light when sound is detected
App19 Calls a user’s phone when Nest detects sound and the home mode is away 𝑑T
= TΔ · q (4)
App20 Turns on a Hubitat device (TV) when motion or sound is detected 𝑑t
Activates the heater when the sensor reports too cold;
App21 T(0) = T0 (5)
Turns off the heater when temperature is normal
App22 Turns on Kasa plug (humidifier) when temperature is above a threshold
App23 Turns on the light when temperature is above or below a threshold In the equation, T0 is the initial temperature, TΔ is the impact
App24 Calls the user when motion is detected and home mode is away from the HVAC system based on its power (positive for the heater,
App25 Turns on the light when motion is detected negative for the AC), and q denotes the system’s actuation command
App26 Turns on the heater when motion is detected
App27 Unlocks the door when motion is detected
(on or off). Although these devices cause an airflow in the room in
App28 Calls the user when smoke is detected order to enable uniform temperature, the appliances still generate
App29 Turns on all lights when smoke is detected heat through diffusion and influence the sensor measurements.
App30 Turns on AC if humidity rises above a threshold
App31 Activates the humidifier when the air is dry
Therefore, both diffusion and convection play a critical role in
App32 Switches off a SmartLife plug (AC) when humidity level is high temperature sensor measurements.
App33 Flashes a light if humidity level is high Relative Humidity. The relative humidity is defined as the ratio
App34 Turns off the light when the room gets bright
App35 Turns off humidifier when humidity has risen back to normal level of the existing water vapor in the air to the maximum capacity of
App36 Turns off dehumidifier when humidity level is low water vapor that can exist in the air [40].
App37 Turns on/off the AC based on the temperature of the room
App38 Turns on the light when the room gets dark w
App39 Turns on the AC when the home mode is set to sleep RH% = × 100 (6)
ws
In the formula, w represents the water vapor in the air, and ws
E APPS DEPLOYED IN THE EXPERIMENTS represents the maximum capacity of water vapor the air can con-
tain. ws exponentially depends on the environmental temperature,
The full list of the apps considered in our experiments is presented
related to the Clausius–Clapeyron equation. Therefore, we leverage
in Table 10.
existing experiments [59] to fit an exponential function to compute
ws based on temperature. In particular, this function is defined as:
F PEM FLOW FUNCTIONS
To determine the flow functions of PeMs, we first analyze the physi- ws = 2.6055 × 𝑒 0.0262×T (7)
cal channels each sensor event observes [38, 60]. We then study how
actuation commands influence these channels and how they diffuse where T represents the environmental temperature in °F.
in a way that changes the sensor readings [12, 14, 32, 40, 52, 67]. We implement the actuation command PeM’s flow functions
Here, we present the equations that rely on the laws of physics, as ordinary differential equations that generate or reduce water
which are integrated into our PeMs as flow functions. Different content in the air.
equations that can capture more detailed influences of actuation Smoke. We consider an ionization-based smoke detector that de-
commands on physical channels can be easily integrated by updat- tects the presence of smoke by filtering air through an ionization
ing the corresponding flow functions. chamber. When smoke particles enter the chamber, conductivity de-
Temperature. Appliances’ influences on temperature are due to creases, and smoke presence is detected [14]. The threshold of these
hot surfaces diffusing heat to their surroundings. Therefore, the sensors is in obscuration density per meter (OD/m), where a typical
heat diffusion equation from a point source [32] (which is based on sensor’s sensitivity is 0.02 OD/m, corresponding to 13 mg/m3 smoke
a partial differential equation) is used as their flow function. density [14, 41]. Gas particles (such as the particles in smoke) move
very fast through the air at room temperature [12]. Therefore, we
𝜕T 𝜕2 T define the flow function of actuation command PeMs as an ordinary
=𝛼 2 (1) differential equation.
𝜕t 𝜕x
Discovering IoT Physical Channel Vulnerabilities CCS ’22, November 7–11, 2022, Los Angeles, CA, USA

Table 11: Details of the actuators in the house. Illuminance. The influence of light is instant. Therefore, it is mod-
eled with an algebraic equation. Its influence follows the inverse
Device (ID)
Operating
Distance (m)† Details‡ square law, as shown below [60].
Time (mins)
temp - 2.8 set(70 − 82°F)
1 set(temp)
- 2.8
Is
hum Dep Ix = (8)
temp - 1.5 surfTemp = 104°F 4 × 𝜋 × x2
2 10
hum - 1.5 Dep In the formula, Is denotes the luminosity flux of the source.
temp - 0.9 surfTemp = 104°F
3 15
hum - 0.9 Dep Sound. Sound is modeled with an algebraic equation due to its high
temp - 0.5 surfTemp = 150°F diffusion speed. Sound intensity is modeled with the inverse square
4 3
hum - 0.5 Dep law [60]. Therefore, the sound pressure, which is the quantity the
5 20 hum - 1.5 vaporRem = 0.5g/min
hum - 1.7 vaporGen = 0.1g/min
sensors measure, is represented with the following formula.
6 25
sound - 1.8 55 dB at 1 m
x1
temp - 1.8 surfTemp = 96°F SP2 = SP1 + 20 × log10 ( ) (9)
7 30 hum - 1.8 Dep x2
sound - 1.8 58 dB at 1 m Sound pressure SP2 at distance x2 can be calculated in decibels
8 20 hum - 1.8 vaporGen = 0.8g/min
(dB) with this formula, where SP1 is the sound pressure level at
9 0.2 sound - 0.8 58 dB at 1 m
illum - 1.2 400 lumens distance x1 (the standard value of x1 is 1 meter) [62]. When the
10 25
sound - 2 62 dB at 1 m distance is doubled, SP2 decreases by 6 dB.
11 20 motion - variable
∗ Move towards sensor
12 15 illum - 1.4 815 lumens
Motion. There are different types of motion sensors available on
temp - 2 set(70 − 82°F) the market. For instance, accelerometers detect motion based on
13 set(temp) hum - 2 vaporRem = 10g/min the acceleration generated by the source, PIR sensors detect motion
sound - 3.5 62 dB at 1 m
14 0.1 sound - 3.7 50 dB at 1 m
based on the infrared heat map of an environment, and laser-based
† temp: Temperature Sensor, hum: Humidity Sensor, illum: Illuminance Sensor, motion:
sensors detect motion by generating an invisible laser between
Motion Sensor, sound: Sound Sensor two devices and detecting the cut-offs. We consider PIR motion
‡ surfTemp: Surface Temperature, vaporGen: Water Vapor Generation Rate, vaporRem: sensors and model them through their range to detect motion. If
Water Vapor Removal Rate, Dep: The actuator impacts the sensor due to dependency
∗ Robot vacuum moves towards the motion sensor.
the actuators’ movement rate exceeds a threshold and the distance
is close enough, motion is detected.

G DEVICE SPECIFICATIONS
NEST & MQ2
Smoke Sensors Table 11 presents the actuator configurations, influences of the
SmartThings & PIR DHT11 actuators on sensors, and distances to the sensors they influence.
Motion Sensors Temp/Hum Sensor For sensors (presented in Figure 12), sensitivity values, and
thresholds for detection (e.g., for sound, illuminance, smoke) are
Photoresistor Arduino UNO LM393 Sound set as follows: (i) temperature sensor - ±1.8°F, (ii) humidity sensor -
Illuminance Sensor Detection Sensor
±2%, (iii) smoke sensor - 0.02 OD/m ≈ 13 mg/m3 , (iv) illum. sensor -
50 lux, (v) sound sensor - 55 dB, and (vi) motion sensor - 1 m.
Figure 12: Sensors installed in the house (See Figure 7).