Discovering Physical Interaction Vulnerabilities in IoT Deployments
Muslum Ozgur Ozmen, Xuansong Li, Andrew Chun-An Chu, Z. Berkay Celik, Bardh Hoxha, Xiangyu Zhang
DDiscovering Physical Interaction Vulnerabilities inIoT Deployments
Muslum Ozgur Ozmen
Purdue [email protected]
Xuansong Li ∗ Nanjing University of Science [email protected]
Andrew Chun-An Chu
Purdue [email protected]
Z. Berkay Celik
Purdue [email protected]
Bardh Hoxha
Toyota Research Institute of [email protected]
Xiangyu Zhang
Purdue [email protected]
ABSTRACT
Internet of Things (IoT) applications drive the behavior of IoT de-ployments according to installed sensors and actuators. It has re-cently been shown that IoT deployments are vulnerable to physicalinteractions, caused by design flaws or malicious intent, that canhave severe physical consequences. Yet, extant approaches to se-curing IoT do not translate the app source code into its physicalbehavior to evaluate physical interactions. Thus, IoT consumersand markets do not possess the capability to assess the safety andsecurity risks these interactions present. In this paper, we introducethe
IoTSeer security service for IoT deployments, which uncoversundesired states caused by physical interactions.
IoTSeer operatesin four phases (1) translation of each actuation command and sen-sor event in an app source code into a hybrid I/O automaton thatdefines an app’s physical behavior, (2) combining apps in a novelcomposite automaton that represents the joint physical behavior ofinteracting apps, (3) applying grid-based testing and falsification tovalidate whether an IoT deployment conforms to desired physicalinteraction policies, and (4) identification of the root cause of policyviolations and proposing patches that guide users to prevent them.We use
IoTSeer in an actual house with 13 actuators and six sensorswith 37 apps and demonstrate its effectiveness and performance.
CCS CONCEPTS • Security and privacy → Formal methods and theory of secu-rity ; Vulnerability scanners ; •
Computer systems organization → Sensors and actuators ; KEYWORDS
IoT; Security Analysis; Physical Interaction Vulnerabilities
An IoT deployment includes a set of IoT devices and applications(apps). IoT devices are comprised of two components: actuators andsensors. IoT actuators influence physical channels by executing anactuation command, e.g., heater - on command changes the temper-ature. IoT sensors measure physical channels and generate sensorevents, e.g., a sound sensor measures ambient sound and generatesa sound - detected event. IoT’s most attractive feature is support for ∗ This work was completed while the author was at Purdue University. custom automation in the form of apps. Apps are event-driven.They subscribe to sensor events, and when the event happens, theyinvoke an event handler method to activate actuators.With the growing number of apps and devices co-installed inan IoT deployment, the interactions among apps cause increasingsafety and security violations [14, 60, 63]. There are two fundamen-tal sources of app interactions: software and physical. Softwareinteractions occur when IoT apps interact through a common de-vice in apps’ source code. Consider the scenario where an app thatturns on the lights when smoke is detected and an app that locks thedoor when lights are turned on are co-deployed. These apps interactthrough a common light device defined in their source code ( smoke −−−−−−→ light - on light - on −−−−−−−→ door - locked ), which puts users at risk during afire. Physical interactions are another notable threat: an app in-vokes an actuation command, a sensor detects the physical channelinfluenced by this command, which triggers other apps subscribedto the sensor event. For example, an app that turns on a heaterinteracts with an app that opens the window when temperatureexceeds a threshold. These apps interact through the temperaturephysical channel ( heater - on ∼∼∼∼∼∼∼ (cid:3) temperature window - open ), which may allowa burglar to break into the house. These interactions can be causedby design flaws from users and can be leveraged by an adversaryto make an IoT deployment reach an undesired state.Recent efforts mainly focus on identifying software interactionsvia app source code analysis [7, 8, 12–14, 45, 56]. These approachesfind interacting apps by matching the common device attributes inmultiple apps, such as the light - on attribute in the first example.Thus, they cannot detect the physical interactions among apps,such as the interaction through the temperature channel above.There have been limited efforts to discover physical interac-tions, which is the focus of this paper. These works (1) use manualinteraction rule templates to define relations between actuationcommands and sensor events [3], and (2) leverage NLP and devicebehavioral models to map apps’ events and commands [10, 21, 60].For example, a manually crafted rule maps the heater - on commandin the app source code to the temperature channel. A model forthe heater - on command defines the temperature increases by ° C in hours. Yet, these rules and models have limited expressivenessof physical channels, and ultimately fail to identify such interac-tions. Specifically, these approaches lead to over-approximationof physical channels, which are false alarms (e.g., the system flagsthat the temperature from oven - on opens the window, yet the oven a r X i v : . [ c s . CR ] F e b oes not increase the temperature enough to open the window),and under-approximation of physical channels, which are the in-teractions that the system fails to identify (e.g., the system ignoresthe motion from a robot vacuum that unlocks the door).In this paper, we introduce the IoTSeer security service for IoTdeployments, which builds the unified physical behavior of IoTapps from their source code to uncover undesired states caused byphysical interactions.
IoTSeer operates in four steps. It first extractsapps’ actuation commands and sensor events from the source codeof apps through static analysis and translates each into a hybridI/O automaton to define their physical behavior. From this,
IoTSeer unifies the automata of apps in a composite automaton to representthe joint physical behavior of interacting apps.
IoTSeer then sys-tematically develops a set of physical IoT policies through metrictemporal logic to express the physical interactions that cause un-desired system states, and uses grid-based testing and falsificationto validate that IoT apps conform to those policies. Lastly,
IoTSeer determines the root cause of the physical interactions and presentsa warning report that guides users on how to fix them.We used
IoTSeer in an actual house with 13 actuators and sixsensors, automated by 37 apps to reveal how physical interactionpolicies are violated. We built the hybrid I/O automata of 26 actua-tion commands and six sensor events defined in the source code ofapps.
IoTSeer found 11 unique physical interaction policy violationson the composite automata of different groups of interacting apps.We repeated the experiments in the actual house and verified thatall violations reported by
IoTSeer are true positives.
IoTSeer is adap-tive to the newly added, removed, and updated devices and imposesminimal automata construction and validation time overhead. Ittakes on average 21 secs to falsify and 69 secs to verify a physicalinteraction policy on the composite automaton of four interactingapps. In this paper, we make the following contributions: • Translating IoT App Source Code into its PhysicalBehavior : We translate the actuation commands and sen-sor events in the app source code into hybrid I/O automatato define their physical behavior. • Composition of Interacting Apps : We introduce a com-posite model architecture that defines the joint physicalbehavior of interacting apps. • Policies for Physical Interactions : We develop policiesto identify five types of physical interactions due to thedesign flaws from benign users and malicious intent fromadversaries to cause undesired states. • Evaluation in an Actual House : We use
IoTSeer in areal house that contains 13 actuators and six sensors andexpose 11 physical interaction policy violations.
IoT Deployments.
An IoT deployment is composed of a set of appsthat monitor and control sensors and actuators. Apps subscribeto events (e.g., motion - detected ) that invoke their event handlermethods, which trigger actuation commands (e.g., light - on ). Usersinstall official apps from IoT markets such as HomeKit [33] andOpenHAB [46] and third-party apps through proprietary web inter-faces. Another trend to create custom automation is trigger-actionplatforms such as IFTTT [35], Zapier [62], and Apiant [6]. These timer-event Robot VacuumCleaner-Start Motion Sensormotion-active Turn on LightsUnlock Patio Door (a) Scenario 1 Cooker.OnOven.On
App MalApp cooking-mode Fan.On (b) Scenario 2 Temp Sensortemp > threshold Open the Window
App Sound Sensorsound-detected Send Notification
App Physical ChannelPhysical Channel
MotionTemperatureSound T e m p e r a t u r e MalApp App timer-event cooking-mode Figure 1: Illustration of physical interactions among apps inan IoT deployment that cause undesired states. platforms allow users to use conditional statements in the form ofif/then rules for integrating digital services with IoT devices. Forinstance, a user can link her IoT platform and email accounts toa trigger-action platform to turn off the lights and send an emailwhen the door is unlocked. In this paper, we use the term app(s) torefer to both IoT apps and trigger-action rules.
Definitions.
Actuators manipulate a physical channel through anactuation command, e.g., a heater’s heater - on command changesthe environment’s temperature. Sensors measure physical changesin an environment (e.g., sound), and generate sensor events basedon these changes, e.g., sound - detected . We characterize the physi-cal relations between an app’s actuation commands and an app’ssensor events with four properties: (1) influence type, (2) time, (3)distance, and (4) dependency. Influence defines the physical chan-nels an actuation command changes, and a sensor event observes.An actuation command may influence a single or multiple chan-nels, e.g., a clothes - dryer - on command introduces sound, heat, andvibration. A sensor measures the influence from single or multipleactuation commands, e.g., an illuminance sensor measures the sumof (aggregated) luminance from TV - on and light - bulb - on . Time de-fines a command’s instant or continuous influence, e.g., heater - on gradually increases temperature, and bulb - on immediately changesilluminance. Distance quantifies an actuation command’s influenceon a physical channel at different locations. A command’s influenceon a sensor often decreases when the distance between sensors andactuators increases. Lastly, dependency defines the implicit relationamong distinct physical channels, where a change in a physicalchannel affects another channel. For instance, variations in ambienttemperature change the environment’s humidity.
Problem Definition.
In an IoT deployment, when an app invokesan actuation command, it influences a set of physical channelsmeasured by sensors, which interacts with other apps subscribed tothose sensor events, invoking other commands. An adversary canprovide users with apps operating correctly in isolation yet exploitthe unintended interactions among apps to cause unsafe states.Figure 1 depicts an IoT deployment that includes seven actuatorsand three sensors controlled by four apps
App - App . An adversarysupplies two apps, MalApp and MalApp , to create unintended phys-ical interactions. In the first scenario (Figure 1-a), the user sets therobot vacuum cleaner to operate at midnight through App . When2 nInt Physical Channel Int Physical ChannelDoes not trigger sensor event itself A S
Actuation Command Sensor Event
Legend A S A App App (a) Unintended Implicit Trigger A S A S Increase D e c r e a s e (e) Dependency Conflict App App App A SA n Agg (b) Unintended Aggregation Trigger
App App n App n+1 I n c r ea s e D e c r e a s e (d) Aggregation Conflict A SA n Agg A n+1 A n+1 S A SA Agg
App App App n+1
Agg
Aggregation
App App n App n+1
App n+1
App n+2
App n+2 A n+2 A n+2 (c) Aggregation Bypass A n+1 IoT App Trigger A A Figure 2: Physical interaction vulnerabilities: (a)-(c) results in undesired states and (d)-(e) delays or cancels the desired states. the vacuum cleaner roams around the home, its movements activatethe motion sensor. The motion - active event triggers MalApp thatturns on the lights and unlocks the patio door at midnight. In thesecond scenario (Figure 1-b), App turns on the pressure cooker andactivates the cooking - mode at a user-defined time. MalApp turns onthe oven and exhaust fan when the mode is set to cooking. The oven - on and cooker - on commands both increase the temperature.The increase in temperature triggers App that opens the window.Here, oven - on and cooker - on ’s individual influence does not trigger App , but their aggregated impact on temperature causes an unex-pected interaction among App , MalApp and App . Lastly, the soundfrom the exhaust fan activated by MalApp triggers App through the sound - detected event, sending an “ intruder alert ” message.The preceding scenarios demonstrate that the final environmen-tal states depend not just on individual apps but are a result ofthe unified physical behavior of IoT devices controlled by multipleapps. In this, each app is individually safe, yet their unified physicalinteractions leave users at risk. For instance, the door gets unlockedat midnight, robot - vacuum - on ( App ) ∼∼∼∼∼ (cid:3) motion motion - active ( MalApp ) → door - unlock ( MalApp ), which allows the adversary to break intothe house, and the erroneous intruder alert, fan - on ( MalApp ) ∼∼∼∼ (cid:3) sound sound - detected ( App ) → send - intruder - msg ( App ), causes panic andunnecessarily brings resources (e.g., police dispatch) to the home. IoT Forum Study.
To investigate whether users run into unin-tended physical interactions in real IoT deployments, we studied100 popular posts in IoT community forums including Apple Home-Kit [34], Samsung SmartThings [54] official forums, and smarthome and home automation subreddits [50]. We found that usersencounter similar problems due to the interacting apps. For instance,a Reddit user confirms the first scenario stating, “
I put a motionsensor in my living room, the lights will turn on. Well, silly me didnot realize that my Roomba is set to clean every night at 3 am wouldtrigger the sensor and keep the lights on until it is finished ” [26].Another user confirms the second scenario saying “ ...do not putthermostats in a kitchen or laundry room either, the extra warmthfrom the appliances slow heating or cooling to other rooms ” [25].
We consider design flaws (from benign users) and malicious intent(from adversaries) that cause unsafe or undesired states in an IoTdeployment due to the physical interactions among IoT apps.For the design flaws, a user installs a set of apps in an IoT de-ployment. We assume the apps are vetted by IoT platforms beforedistribution and operate correctly in isolation. Yet, the physicalinteractions subvert the intended use of IoT devices, leading to un-desired states. The interactions may happen due to errors in users’ creation, installation, and configuration of apps. This is becauseIoT users are usually uninformed about the implications of the appinteractions, as demonstrated by prior work [57, 65].For malicious cases, an adversary intentionally provides apps toa user that create physical interactions to execute privileged actions,such as unlocking the door. The adversary’s goal is to stealthilyexploit the physical interactions among apps. For instance, an ad-versary that supplies a malicious app that unlocks the patio door atnight is not stealthy. This is because the app can be rejected fromthe IoT app market during the platform’s security vetting, and theusers may recognize the malicious behavior by manually checkingthe app’s events and commands. In contrast, a stealthy adversarymay provide single or multiple apps innocuous in isolation such as
MalApp to gain physical entry to the house when this app interactswith App through the motion physical channel. An adversary maycause such hidden interactions through the following scenarios: (1)tricks the user to install malicious apps via phishing and other socialengineering methods, (2) distributes malicious apps through IoTforums, and (3) discovers a physical interaction between a user’sapps and exploits the interaction by manipulating the responsereturned from an external service to trigger apps. We introduce five types of physical interaction vulnerabilities amongapps that could be leveraged by an adversary to make an IoT deploy-ment reach an unsafe state. To properly designate the circumstancesunder which the app interactions are a vulnerability or feature , wedefine two labels, intended ( Int ) and unintended (
UnInt ).–
Intended Physical Channel ( Int ): An actuation command’sinfluence on a physical channel is “intended” if the use of theactuation command is to change that physical channel.–
Unintended Physical Channel ( UnInt ): An actuation command’sinfluence on a physical channel is “unintended” if it is unplannedby a system or undesired by a user.To illustrate, if the heater - on command’s Int labeled influence ontemperature triggers apps, it is a feature; but, if clothes - dryer - on ’s UnInt labeled influence on the sound, temperature, and motion trig-gers apps, it is a vulnerability. We note that the physical channellabels might be highly contextual depending on the use cases ofdevices and the environment in which the devices are deployed.For instance, consider an app that turns on a heater interacts withanother app that opens the window when the room temperature ex-ceeds a threshold. The correctness of opening the window through heater - on ’s influence on the temperature channel might be deemed3afe or dangerous based on the use cases of devices. As needs dictate,we allow users to label physical channels as Int or UnInt .Figure 2 depicts the vulnerabilities: (a)-(c) causes undesired states,and (d)-(e) delays or cancels desired states. To systematically il-lustrate the vulnerabilities, we abstract an app’s source code asa labeled transition system, which is a tuple TS = ( D , L , ∼∼ (cid:3) ) . D isa set of actuation commands ( A ) and sensor events ( S ). L is a setof physical channel labels, { Int , UnInt } and {
Inc , Dec }. Inc and
Dec represent if a command increases or decreases a physical channel. ∼∼ (cid:3) defines the labeled physical channels between apps. Lastly, wedefine a transition Agg ( { A , . . . A n }) ∼∼ (cid:3) L S to represent the aggregatedinfluence of multiple commands that triggers a sensor event. Unintended Implicit Trigger (Figure 2a).
An app’s actuationcommand introduces an unintended physical channel detected by asensor. The consequent sensor event triggers other apps that invokefurther actuation commands. Formally, two apps interact due tothe A ∼∼∼∼∼ (cid:3) UnInt S transitions. Two examples of this interaction are seenin Figure 1. (1) When App turns on the robot vacuum, it causes the robot - vacuum - on ∼∼∼∼∼∼∼∼ (cid:3) UnInt-motion motion - active transition that triggers the MalApp , unlocking the patio door. (2) When MalApp turns on thefan, it causes the exhaust - fan - on ∼∼∼∼∼∼∼∼ (cid:3) UnInt-sound sound - detected transition,which triggers App , sending an intruder alert notification. Unintended Aggregation Trigger (Figure 2b).
An actuationcommand’s influence on a physical channel does not trigger a sen-sor event; however, the aggregation of unintended influences frommultiple actuation commands triggers a sensor event. Formally, mul-tiple apps interact with each other due to the
Agg ( { A , . . . A n }) ∼∼∼∼∼ (cid:3) UnInt S transitions. In Scenario 2 shown in Figure 1-b, App and MalApp cause the Agg ( { cooker - on , oven - on }) ∼∼∼∼∼∼∼∼∼∼∼∼ (cid:3) UnInt-temp temp > threshold tran-sition, which triggers App , opening the window. Aggregation Bypass (Figure 2c).
The aggregation of intendedand unintended influences from multiple commands triggers an appwhile an actuation command’s intended influence itself does not.Formally, this interaction occurs due to a
Agg ( { A , . . . A n }) ∼∼∼∼∼∼ (cid:3) Int,UnInt S transition, yet a A k ∼∼∼∼ (cid:3) Int
S s . t . ∃ k ≤ n transition does not happen. Toillustrate, consider a smart bulb, a TV and an illuminance sensorare co-located. Here, an app’s bulb - on command does not createthe bulb - on ∼∼∼∼ (cid:3) Int light - detected transition, i.e., the bulb’s luminancedoes not trigger the light - detected event itself. Yet, if an app’s TV - on command is also invoked, the aggregated luminance from bulb - on and TV - on causes the Agg ( { bulb - on , TV - on }) ∼∼∼∼∼∼∼∼∼∼∼ (cid:3) Int,UnInt-illum light - detected transition. Thus, the sensor event only occurs when the UnInt illu-minance contributes to the sensor measurements.
Aggregation Conflict (Figure 2d).
Multiple actuation com-mands influence an intended physical channel in conflicting ways.That is, an app’s actuation command increases an
Int physical chan-nel while another app invokes an actuation command that decreasesthe same physical channel. This conflicting impact on a physicalchannel may cause triggering other apps to take longer or to be late,and delay or prevent intended states. Formally, these interactions oc-cur due to the ( A ∼∼∼∼∼ (cid:3) Int, Inc S ) , ( A ∼∼∼∼∼ (cid:3) Int, Dec S ) transitions. For instance, if theAC and heater are turned on at the same time, heater - on increasestemperature, whereas AC - on decreases it. This delays or preventstriggering other apps conditioned on the temperature - change event. Dependency Conflict (Figure 2e).
Apps also interact due tothe dependency between physical channels. While two actuation I O TS EERDescribing Apps’ Joint Physical Behavior
Static Analysis Automata Construction Automata Composition
Security Analysis of a Deployment
Policy Identification Policy Validation Deployment Patching u Composite Automaton v wx zy
ActuatorsSensorsIoT apps
IoT Deployment
Adversary
Inject malicious apps
Figure 3: Overview of
IoTSeer ’s architecture. commands ( A , A ) have Int influences on two distinct physical chan-nels, they cause a conflicting impact on a channel and its sensorevents. That is, A increases p and A increases p , yet A decreases p due to the dependency between p and p . Formally, this inter-action occurs due to the A ∼∼∼∼∼ (cid:3) Int, Inc S , A ∼∼∼∼∼ (cid:3) Int, Inc S , and A ∼∼∼∼∼∼ (cid:3) UnInt,Dec S tran-sitions. For instance, heater - on ’s Int influence on temperature im-pacts humidity due to their dependency (Detailed in Section 5.1.3).If a heater and humidifier are both on, the heater decreases hu-midity while increasing temperature and the humidifier increaseshumidity. Similar to the aggregation conflict, this delays or preventstriggering the apps conditioned on the humidity channel’s events.
Figure 3 provides an overview of the six stages of
IoTSeer . IoTSeer first extracts an app’s actuation commands and sensor events fromits source code through static analysis ( 1 ). From this,
IoTSeer mapsan actuation command to a hybrid I/O automaton for each physicalchannel it influences, and a sensor event to a hybrid automaton forthe channel it measures ( 2 ). Each automaton translates the high-level commands and events in the source code into their physicalbehavior through well-studied differential and algebraic equations.
IoTSeer then extends system identification to tune automata pa-rameters using device traces collected from actual IoT devices forprecision. For instance, Figure 4 presents the hybrid automaton of
App ’s robot - vacuum - on command’s influence on motion (Left) and MalApp ’s motion - active sensor event (Right). IoTSeer next unifies each app’s automaton in a composite automa-ton to represent the interacting apps’ joint physical behavior ( 3 ).
IoTSeer ’s composition algorithm takes into account complex physi-cal properties, including aggregation and dependency of physicalchannels. For instance, Figure 5 presents the composite automatonof three apps,
App , App , MalApp , illustrated in Figure 1-b. There-after, IoTSeer integrates conformance algorithms into the compositeautomaton to account for environmental factors, such as room lay-outs and the presence of human inhabitants. This process ensuresthat a composite automaton has the correct functional propertiesof a real IoT deployment amenable to formal analysis.We develop a set of policies with metric temporal logic to detectthe physical interaction vulnerabilities introduced in Section 4 ( 4 ).For instance, a policy for unintended implicit trigger states that“a motion - active event from robot - vacuum - on must not unlock thedoor”. IoTSeer validates whether the apps’ joint behavior conformsto the identified policies via grid-based testing for exhaustivenessand optimization-guided falsification for scalability ( 5 ). If
IoTSeer flags a policy violation, it reports the root cause, including theinteracting apps, their actuation commands, sensor events, andtheir physical channel.
IoTSeer then proposes patches that guide4 ff On
Input (U) Output (O)O = 0 On Input (U) Output (O) (a) motion automaton of robot-vacuum-on (b) motion-active automaton
O = f(X) tStart = 1Stop = 1 O = f(X)
Figure 4: (Left) hybrid automaton of robot - vacuum - on com-mand and (Right) hybrid automaton of motion - active sensorevent abstracted from the source code of App and MalApp . users to prevent the physical interactions, such as removal of apps,activating apps in isolation, and new device placement ( 6 ). IoTSeer extractsan app’s actuation commands and sensor events from its sourcecode.
IoTSeer integrates static analysis tools designed for IoT apps [12,13, 60] to support various IoT programming platform apps. Theseplatforms are diverse, and each offers a different programminglanguage to automate IoT devices. For instance, consumer IoT plat-forms such as OpenHAB enable users to write apps with a DomainSpecific Language based on Xbase [46], and trigger-action platformssuch as IFTTT and Zapier implement if-then abstractions through aset of APIs for the ease of users [35, 62]. Common to all, they modelan app’s life-cycle, including its entry points and event handlersfrom an app’s inter-procedural control flow graph (ICFG) and ex-tract the (1) devices and events, and (2) actuations invoked for eachevent (often in the event handlers). To illustrate, the descriptionof the
MalApp ’s IFTTT app in Figure 1-a says “Turn on the lightand open the patio door when motion is detected”. IoTSeer obtains light - on and door - unlock commands, and the motion - active eventthat triggers these commands via static analysis.We studied three IoT programming platform markets, IFTTT,Microsoft Flow, and OpenHAB, and obtained the popular IoT apps.We use the actuation commands and sensor events of these appsto define their physical behaviors in the next subsection. Throughthis process, we extracted 13 different commands such as heater - on , clothes - dryer - on , robot - vacuum - on . The actuation commands influ-ence six physical channels, temperature, humidity, illuminance,sound, motion, and smoke, measured by six different sensors. IoTSeer mapseach actuation command and sensor event extracted from an app’ssource code to hybrid I/O automata to describe an app’s physicalbehavior. We extend physics-based modeling to construct a separateautomaton for each physical channel an actuation command influ-ences, and a sensor event observes. We then use system identification (SI) to tune automata parameters [37, 48].The physics-based modeling integrates a generic differential oralgebraic equation from control theory into an automaton to modeleach command and event’s physical behavior. In the SI stage, wetake each automaton constructed at the physics-based modelingand use limited data traces from IoT devices to infer the devia-tions between automata and actual devices. We then tune eachautomaton’s parameters to address the discrepancies among them.This approach enables unique advantages over past efforts thatsolely use input-output data to determine a system’s empirical de-scription. These efforts provide a set of inputs to a real system,
Off On
O = 0 On O = f(X) tStart = 1Stop = 1 O = f(X)
Off On
O = 0 O = f(X)Start = 1Stop = 1 On Send Notification tO = f(X)
Off On
O = 0 O = f(X) Start = 1Stop = 1
Sound
Agg
Aggregated Temp.Temp.Temp. Window.OpenCooker.StartOven.StartFan.Start
App MalApp MalApp App App Figure 5: Composite automaton that represents the unifiedphysical behavior of
App , App , App , MalApp in Figure 1. acquire raw data traces, and construct a system’s dynamics fromthem [15, 17, 20, 49, 64]. Yet, SI solely built on raw data traces hastwo main limitations in IoT deployments. First, they require anextensive amount of data traces for each device to correctly identifytheir physical behavior [37]. For instance, they need temperaturevalues when an oven is turned on at different temperatures fordifferent periods of time and distances. Second, they repeat thecomprehensive data collection for each separate IoT deployment.This is because environmental factors and device types differ in eachdeployment [16, 51]. We address the first limitation by construct-ing generic physics-based automata and tuning their parametersthrough SI, which requires a minimal amount of data traces. For thesecond limitation, we build configurable automata that take deviceparameters as an input. This allows us to define generic automatatemplates for devices that change the same physical channels. Actuation Command Hybrid I/O Automaton.
IoTSeer buildsa hybrid I/O automaton for each physical channel an actuationcommand changes. To identify the physical channels, we deployed13 actuators and 6 sensors in a house, invoked each actuation com-mand, and recorded the sensor readings. We repeated the experi-ments with different distances between sensors and actuators toobserve each command’s impact. Through these experiments, wecreated a physical-channel reference file that includes the completeset of channels each actuation command changes.
IoTSeer uses thisfile to map each actuation command in the source code to singleor multiple automata. For example, the clothes - dryer - on actuationcommand changes sound, humidity, temperature, and motion. Thus,it is associated with a separate automaton for each physical channel.An automaton models the discrete and continuous dynamicsof an actuation command. The discrete behavior is a finite statemachine for invoking the command from the app source code. Thecontinuous behavior is an algebraic or differential equation for itsphysical behavior. Formally, a hybrid I/O automaton [41] is a tuple H a = ( Q , X , f , → , U , O ) , where Q is a set of discrete states, X is a set ofcontinuous variables, f is a flow function that defines the evolu-tion of continuous variables in each state, ( → ) defines the discretetransitions, and U / O defines the input/output variables. We definethe discrete states as Q = { on , off } , and discrete transitions enableswitching between them. We initialize each command automatonin the off state. The automaton switches to the on state when anactuation command is triggered in the app’s source code.The flow functions govern the physical behavior of actuationcommands. They are in the form of differential equations for contin-uous physical channels such as temperature and algebraic equations5 pp
1. //Devices2. dryer d
3. //User Inputs4. t_on
5. if timer = t_on d.on()
1. //Devices2. temp_sensor t window w
4. //User Inputs5. th
6. if currentTemp > th w.on()
1. //Devices2. sound_sensor s
3. if s.sound-detected notification() 𝜕T𝜕t = 𝛼(𝜕 ! T𝜕x ! ) 𝑆𝑃 ! = 𝑆𝑃 " + (2) dryer-on Sound " (𝑥 " 𝑥 ! )) d r y e r - o n (1) currentTemp(2) sound-detected dryer-on (1) dryer-on Temperature
App App Figure 6: The physical behavior of the clothes - dryer - on actua-tion described by two separate hybrid automata that definesits influence on temperature and sound physical channels. for instant channels such as sound. A flow function takes two con-tinuous variables (parameters) as input: device configuration anddistance from the actuator. The device configuration parameter de-scribes the characteristics of a device, such as its operating power.This enables us to use the same flow function for different actua-tors influencing the same channel (e.g., oven - on and cooker - on ), andthe actuators with multiple working patterns (e.g., AC ’s modes) bysetting different parameters. The distance parameter quantifies thecommand’s influence at different locations (e.g., the fan - on ’s soundintensity at 1 meter away and 2 meters away from the fan). Thismakes IoTSeer practical against dynamic device placement changesin the deployment, and enables effortless porting of
IoTSeer to otherIoT deployments with different device placements.
Example.
We constructed 26 hybrid I/O automata of 13 actua-tion commands (See Section 6). Figure 6 illustrates the automata of clothes - dryer - on command that changes sound and temperature.First, we associate an app’s clothes - dryer - on command with appssubscribed to currentTemp and sound - detected events. We constructan automaton for each physical channel. Figure 6 (Top) depicts asample output of the temperature automaton, which uses a flowfunction of the partial differential heat diffusion equation [31]. Theautomaton’s output is the dryer’s influence on environment tem-perature over time per distance.Second, the dryer - on ’s sound automaton uses a flow functionwith an algebraic equation based on the inverse square law [59].Given the dryer’s sound pressure parameter at a fixed distance, theautomaton outputs the sound pressure (dB) at arbitrary distances. Sensor Event Hybrid I/O Automaton.
A sensor event’s hybridI/O automaton is similar to actuation commands, yet it only mea-sures physical channels. We define a sensor event’s automaton ( H s )with a single state, Q = { on } , and a timed self-loop transition on t −→ on ,where time t is the frequency a sensor samples its readings.The sensor event automaton takes a sensitivity-level parame-ter, which defines the minimum amount of change in the physicalchannel (threshold) required for a sensor to change its numerical orbinary measurement. A threshold function outputs a sensor readingindicating whether the physical channel level is equal or greaterthan the sensitivity level. If the sensor measures Boolean-typedvalues such as motion, the automaton outputs a binary bit that indi-cates “ motion - detected ” or “ motion - undetected ” events. If the sensormakes numerical readings such as temperature, the automaton out-puts the numerical value. The sensor event automata’s output isthen used to trigger other apps subscribed to those events. Example.
We constructed hybrid I/O automata for 6 sensors,temperature, humidity, illuminance, sound, motion, and smoke (SeeSection 6). Figure 6 depicts the automaton output of the temperaturesensor’s currentTemp and the sound sensor’s sound - detected events.The temperature sensor event automaton monitors the tempera-ture based on its sensitivity level and outputs numerical tempera-ture values. For instance, a temperature sensor with a sensitivitylevel of ± . ° F and a sampling rate of 5 secs at 2 m away from thedryer outputs currentTemp = . ° F event when the clothes - dryer - on command increases the ambient temperature ( . ° F ) by ° F . Thesensor event automaton detects this change as it exceeds the sen-sor’s sensitivity level and triggers the apps that are conditioned onthis change, e.g., currentTemp = . ° F and currentTemp > ° F .Similarly, the sound sensor automaton outputs a binary valuewhen the dryer’s sound exceeds its threshold. It then sends a sound - detected event to the apps subscribed to this event. System Identification (SI) for Tuning Automata Parameters.
SI is a learning-based method commonly used by control engineersto estimate parameters or models of physical processes using ex-perimental data traces [37, 48]. We use SI to ensure that the deviceautomata constructed through physics-based models have highconformance with actual devices in an IoT deployment. Each au-tomaton requires a set of configuration parameters that affect howthe devices influence or measure the physical channels. We initiallydetermine these parameters from the device datasheets. However,a discrepancy in parameters could occur, for example, due to anerror in the device sheets or device aging [51].To address such discrepancies, we extend ( 𝜏, 𝜖 ) -closeness [2] thatmeasures the conformance of automata with actual device traces.We then use SI to estimate the automata parameters to maximizeconformance. This process requires a fewer amount of traces thanSI’s traditional usage as we only tune the configuration parametersinstead of estimating the complete equations for each device. ( 𝜏, 𝜖 ) -closeness determines the difference among two traces intheir timing ( 𝜏 ) and states ( 𝜖 ), where 𝜖 is referred to as deviationscore [2]. Let x be an automaton’s traces, and y be the real devicetraces generated with the same inputs. Given T ∈ R + , and ( 𝜏, 𝜖 ) ≥ x and y are ( 𝜏, 𝜖 ) -close if for all t ∈ x , t ≤ T , there ex-ists s ∈ y where | t − s | ≤ 𝜏 , and | x ( t ) − y ( s )| ≤ 𝜖 , and for all t ∈ y , t ≤ T , there exists s ∈ x where | t − s | ≤ 𝜏 and | y ( t ) − x ( s )| ≤ 𝜖 .Given an IoT deployment, we first select an actuation command-sensor pair where the sensor measures the actuation command’sinfluence. We collect sensor traces with different distances betweenthe actuator and sensor ( . - . m with . m intervals), and com-pute the ( 𝜏, 𝜖 ) -closeness between the actual device and automatatraces. For instance, consider the oven - on automaton trace yields t = . , v = . ° F , and actual device trace yields t = . , v = . ° F ,where v is the sensor output at time t . IoTSeer ’s conformance algo-rithm outputs that the automaton and actual device traces differ intime ( 𝜏 ) by . with a deviation score ( 𝜖 ) of 0. If an actuator-sensorpair yields a high deviation score, we run automata with a grid ofconfiguration parameters and conduct a binary search to obtainthe optimal values that minimize the deviation score. In Section 6.1,we present our detailed numerical results in an actual house. IoTSeer buildsa separate composite automaton representing the joint physical6 lgorithm 1
Composition of Apps’ Physical Behavior
Input:
Actuation command automata ( H a ), sensor event automata ( H s ), Apps ( L app ) Output:
Composite automaton ( M Ha , Hs )1: function Composition( H a , H s , L app )2: for H i ∈ H a , H j ∈ H s do
3: Unify ( H i , H j ) ⊲ Actuation command to sensor event transitions4: end for for app i ∈L app do ⟨L actuation - command , L sensor - event ⟩ = StaticAnalysis( app i )7: for s ∈ L sensor - event , a ∈ L actuation - command do
8: Unify ( H s , H a ) ⊲ Sensor event to actuation command transitions9: end for end for for H j ∈ H s do
12: Agg ( H j . U ) ⊲ Aggregate inputs of the sensor events13: for H k ∈ H s do if H j . O = H k . U then Dep ( H j → H k ) ⊲ sensor-to-sensor dependency15: end if end for end for return M Ha , Hs = (cid:208) ( H a , H s ) ⊲ Return the composite automaton19: end function behavior of a set of interacting apps. The separate composite au-tomaton allows
IoTSeer to perform scalable analysis of many appsattached to many devices and receiving many events.Algorithm 1 presents our approach to composite automatonconstruction. The algorithm starts with identifying the interactingapps by matching the physical channels of the sensor events andactuation commands. First, if a sensor measures a physical channelthat an actuation command influences, we add a transition from theactuation command automaton ( H a ) output to the sensor event au-tomaton ( H s ) input (Lines 2-4). Second, if the actuation command’sinfluence on a channel exceeds the sensor event’s sensitivity, ittriggers the event handler of apps subscribed to the sensor event.In this case, we add a transition from the sensor event automaton( H s ) output to the actuation command automaton ( H a ) input (Lines5-10). The transitions are expressed with a UNIFY ( H a , H s ) operator,which defines the interactions as a labeled transition, H a ∼∼ (cid:3) L H s and H s L −→ H a . Here, L = { UnInt , Int } , ∼∼ (cid:3) L is an actuation command’s la-beled influence on a physical channel, and L −→ is a sensor event thattriggers actuation commands in an app’s event handler method.Figure 5 illustrates the composite automaton of four apps inFigure 1-b. Here, when MalApp invokes oven - on and exhaust - fan - on commands, IoTSeer identifies that smart - oven - on ’s temperature au-tomaton interacts with the temperature sensor event in App and exhaust - fan - on ’s sound automaton interacts with App . The follow-ing transitions are then added to the composite automaton: H a { smart - oven - on } ( MalApp ) ∼∼∼∼∼∼∼ (cid:3) UnInt-temp H s { temp > threshold } ( App ) H a { exhaust - fan - on } ( MalApp ) ∼∼∼∼∼∼∼ (cid:3) UnInt-sound H s { sound - detected } ( App )Similarly, new transitions are added when (1) the temperaturesensor measures an increased temperature, App triggers a sensorevent that opens the window, and (2) the sound sensor detects sound, App triggers a sensor event that sends intruder alert message: H s { temp > threshold } ( App ) UnInt −−−−−−→ H a { window - open } ( App ) H s { sound - detected } ( App ) UnInt −−−−−−→ H a { send - intruder - msg } ( App ) Physical Channel Aggregation.
A sensor measures the accumu-lated influence of multiple actuation commands on a physical chan-nel. For this, we define an aggregation operator (
AGG ). AGG combinesthe
UNIFY ( H a , H s ) operators where a sensor event automaton takesthe aggregated output of the actuation command automata as input(Lines 11-13). Turning to App that turns on the pressure cooker and MalApp that turns on the oven, a transition is added to the com-posite automaton, Agg ( H { cooker - on } ( App ), H { oven - on } ( MalApp ) ) ∼∼∼∼∼∼∼∼∼∼∼∼ (cid:3) UnInt-temp temp > threshold . The AGG operator’s output is definedbased on the physical channel’s unit. It is the sum of the actua-tion command automata outputs ( (cid:205) ni = UNIFY ( H ia , H s ) ) for linear scalephysical channels (e.g., temperature) [66]. On contrary, the physicalchannels represented in the logarithmic scale (e.g., sound) are aggre-gated after converted to a linear scale, × log ( (cid:205) ni = H ia / ) [44]. Physical Channel Dependency.
A physical channel ( p j ) dependson another channel ( p i ) if a change in p i affects p j . Due to de-pendencies, a sensor event automaton’s output can influence howanother sensor event automaton measures a physical channel. Weidentify the dependencies by iteratively taking each sensor eventautomaton and checking if it is used in the threshold function ofanother sensor event (Lines 14-17). We identified a dependencyin the studied sensors; the increase in temperature increases themaximum air-water capacity and affects the humidity sensor’sevents [39]. This is because the humidity sensor event automatontakes air-water concentration and temperature level as inputs andoutputs relative humidity. To address this, we add a DEP ( H is → H js ) transition from the temperature sensor event automaton output( H is ) to the humidity sensor event automaton input ( H js ). We use conformancealgorithms to tune device automata parameters in Section 5.1.4,however, environmental factors may also affect the devices’ be-havior. For instance, human activities (e.g., an exercising person)and physical obstacles between actuators and sensors (e.g., furni-ture) may change sensor readings. We add a new automaton to thecomposite automaton to address human activities, and revise thecommand automata’s flow functions to address physical obstacles.We select the actuation command-sensor pairs in the IoT de-ployment where a sensor measures the physical channel that anactuation command changes. We then activate each actuator andcollect traces from the sensors when people are cooking and exercis-ing, and with furniture (e.g., couch) placed between devices basedon the IoT deployment’s layout. We compute the ( 𝜏, 𝜖 ) -closeness ofthe actual device traces under environmental factors with automatatraces. If we find a statistically-significant difference, we integratethe environmental factor’s impact into the composite automaton.For the human activities that impact sensor readings, we add anew automaton to the composite automaton to include the influenceof human activity. For instance, we found in our experimental housethat a person < cm away from the humidity sensor exercisingfor mins increases humidity measurements. To address this, weadd a human - exercising automaton to the composite automaton.For the physical obstacles, we multiply the actuation commandautomaton’s output with a coefficient that increases or decreasesit to match with the sensor readings in actual traces. For instance,we found in our experiments that opaque furniture between anilluminance sensor and a light bulb decreases the luminance. Wemultiply the bulb - on automaton’s output with a coefficient thatequalizes its output to the actual sensor readings. We detail ournumerical findings on environmental factors in Section 6.1. Environmental Noise.
The uncontrolled environmental distur-bances may impact actuation command outputs and sensor inputs,such as mechanical devices (e.g., ceiling fan) and living organisms7 able 1: Descriptions and MTL formulas of policy templates for physical interaction vulnerabilities.
Category ID Policy Description MTL Formula † Individual I Unintended physical channels from an actuation command must not trigger a sensor event. □ [ , t ] ( imp (⟨ UnInt , p ⟩) ≤ th ) Aggregation G Unintended physical channels from multiple actuation commands must not trigger a sensor event. □ [ , t ] ( imp (⟨ UnInt , p ⟩ , . . . , ⟨ UnInt n , p ⟩) ≤ th ) G Unintended physical channels must not aggregate with intended physical channels to □ [ , t ] ¬( imp (⟨ Int , p ⟩) < s ∧ imp (⟨ Int , p ⟩ , trigger a sensor event unless intended physical channels alone can trigger the sensor event. ⟨ UnInt , p ⟩ , . . . , ⟨ UnInt n , p ⟩) ≥ th ) G Multiple intended physical channels must not influence a sensor event in opposite ways. □ [ , t ] ¬( isOppImp ( imp (⟨ Int , p ⟩) , imp (⟨ Int , p ⟩))) Dependency D An intended physical channel must not influence a sensor event on another channel □ [ , t ] ( isOppImp ( imp (⟨ Int , p ⟩) , in an opposite way due to the dependency between the physical channels. depImp ( imp (⟨ Int , p ⟩) , p )))† (1) imp (⟨ Int , p ⟩) and imp (⟨ UnInt , p ⟩) denote the intended ( Int ) and unintended (
UnInt ) influence on a physical channel p (e.g., p = temp ). When multiple Int / UnInt channels are defined in imp , it denotes the aggregated influence. th denotes the sensitivity level of a sensor. (2) isOppImp ( imp , imp ) denotes a binary function that outputswhether imp and imp introduce opposing influences on a physical channel. (3) depImp ( imp (⟨ Int , p ⟩) , p ) denotes the impact on p due to the dependency on p . besides humans (e.g., plants). Similar to addressing uncertainty insecurity risk assessments, we add noise automata to the compositeautomaton. Each noise automaton outputs a sample from a givenmean and standard deviation in each time step. Its output is then ag-gregated with the physical channel values through the AGG operator.The noise parameters for mechanical devices can be estimated byactivating them and recording the changes in the sensor measure-ments. For uncertain factors, the parameters are manually set basedon the environment’s needs, high-values to over-approximate thephysical channel values, and low-values to under-approximate.
We develop a security analyzer that evaluates an IoT deployment’sapps against a set of physical interaction policies (Section 5.2.1). Thepolicies are validated on the composite automaton of interactingapps (Section 5.2.2). If a violation is flagged, the security analyzeridentifies its root cause and presents a warning report that guidesusers on preventing the interactions causing the undesired states.
The policies define the physical in-teractions that apps must satisfy for an IoT deployment to be consid-ered safe. We introduce five policies to evaluate an IoT deploymentagainst physical interaction vulnerabilities introduced in Section 4.We formally represent the policies with Metric Temporal Logic(MTL) [1, 38]. In contrast to Linear Temporal Logic (LTL) [47] andComputation Tree Logic (CTL) [18] that enable reasoning overevent ordering, MTL expresses both temporal and causal relations.This enables us to reason about the physical behavior of apps andidentify their interactions with state and time constraints [24].Table 1 presents five policy templates for each physical interac-tion vulnerability depicted in Figure 2: (1) an individual ( I ), (2) threeaggregation ( G , G , G ), and (3) a dependency ( D ). For instance, theindividual policy ( I ) template states that an actuation command’sunintended influence on a physical channel must not trigger a sen-sor event. To illustrate, the sound produced by garbage - disposal - on command must not trigger the sound - detected event in apps within t minutes. Its MTL policy is □ [ , t ] ( imp ( ⟨ gar . - disp . - on , sound ⟩) < th ) ; □ [ , t ] means always within t time units and imp () denotes the la-beled ( Int / UnInt ) influence on a physical channel.
We use two separate approaches, grid-based testing, and optimization-guided falsification, to validate MTLpolicies on the composite automaton. Testing is exhaustive as itchecks an automaton’s behavior until a policy is satisfied. In con-trast, falsification is scalable as it confirms an automaton’s behavior
Algorithm 2
Grid-based Testing
Input:
Composite automaton ( M H a , H s ) with actuation command ( H a ) andsensor event automata ( H s ), parameters ( x - distances among devices),inputs ( U - actuator start times as a grid t : Δ t : t end ), policy ( 𝜓 ). Output: P = ( inputs , apps , dist , stime , y ) function Grid_Test( H a , H s , x , U , M H a , H s ,𝜓 ) for j ∈ H s , H OP ⊆ H a do for Different start times of each actuator in H OP do if Φ (M H OP , H s , x , u ) ⊭ 𝜓 then P ← P ∪ { x , u , Φ (M H OP , H s , x , u ) } end if end for end for return P end function until a violation is observed. We use falsification if an IoT deploy-ment includes many apps that lead to a large composite automaton,because it offers scalability at the expense of full verification. Bothapproaches report the root cause of the violations and present userswith patches to prevent them. Executing Composite Automaton.
We execute the compositeautomaton and collect data traces to validate the MTL policies. Theexecution requires two parameters: time-step, the time betweentwo consecutive recorded data trace points, and execution-time, theduration of trace collection (See Section 6 for parameter selection).The automata traces ( v , t ) are timed ( t ) state sequences of com-mands and sensor events ( v ). Each actuation command automaton’sstate is its influence on a physical channel, and each sensor eventautomaton’s state is its measurements. The traces include labels( Int / UnInt ) and app IDs of the commands and sensor events.
Grid-based Testing.
Testing determines whether the compositeautomaton satisfies a policy, Φ (M , x , u ) | = 𝜓 , where Φ representsthe behavior of the composite automaton ( M ) under a finite set ofparameters ( x ∈ X , distances between devices) and inputs ( u ∈ U , ac-tuator start times–the time that apps invoke actuation commands).Algorithm 2 presents our grid-based testing approach. We set thedistance between actuators and sensors to fixed paths (e.g., robotvacuum and motion sensor) or constants (e.g., temperature sensorand heater). We then set actuators’ start times as a grid ( t : Δ t : t end )(Line 3). The algorithm executes the composite automaton with agrid-search on the actuators’ start times and validates a policy oneach execution’s automata traces with a robustness metric (Lines4-6). The robustness quantifies how close an MTL formula is to thepolicy violation. Positive robustness values indicate the policy issatisfied, and negative values indicate the policy is violated.8 able 2: Physical channels of studied actuators and sensors. Sensors † Actuator (Actuation Command) a Temp. b Illum. c Sound d Hum. e Motion f Smoke Marley Baseboard Heater (set(val))
Int ✗ ✗
UnInt ✗ ✗ Whirlpool Oven (on)
UnInt ✗ ✗
UnInt ✗ Int Instant Pot Pressure Cooker (on)
UnInt ✗ ✗
UnInt ✗ ✗ Mr. Coffee Coffee maker (on)
UnInt ✗ ✗
UnInt ✗ ✗ Easy Home Dehumidifier (on) ✗ ✗ ✗
Int ✗ ✗ Whirlpool Clothes Washer (on) ✗ ✗
UnInt UnInt UnInt ✗ Whirlpool Dryer (on)
UnInt ✗ UnInt UnInt UnInt ✗ Sunbeam Humidifier (on) ✗ ✗ ✗
Int ✗ ✗ Whirlpool Garbage Disposal (on) ✗ ✗
UnInt ✗ ✗ ✗ Vizio 48” TV (on) ✗ UnInt Int ✗ ✗ ✗ Roborock S4 Robot Vacuum (on) ✗ ✗ ✗ ✗
UnInt ✗ CREE Smart Light Bulb (on) ✗ Int ✗ ✗ ✗ ✗ Kenmore AC (set(val))
Int ✗ UnInt Int ✗ ✗✗
Actuationcommanddoesnotinfluencesensors(Determinedwithexperiments(Section5.1.2)).
Int / UnInt is marked based on the description of IFTTT apps. See Appendix 6 for sensor brands.
Optimization-Guided Falsification.
Falsification searches forcounterexamples ( x ∈ X , u ∈ U ) that violate a policy on the compositeautomaton ( Φ (M , x , u ) ⊭ 𝜓 ) [1, 4]. Unlike grid-based testing, it takesranges for the distances between devices and the actuators’ starttimes. It uses an optimization algorithm (Monte Carlo sampler) toscalably search for policy violations by sampling distances and starttimes from given ranges. It then executes the composite automatonand records data traces, and computes a robustness value similarto the grid-based testing. The sampler then seeds another input tothe composite automaton within the ranges (similar to the inputgeneration in fuzzing [29]). The sampler’s objective is to minimizerobustness, as its negative values indicate a policy violation. Thetermination criteria for input generation is either when the policyis falsified or a user-defined max number of iterations is met. Root Cause Analysis.
Testing and falsification output a quintuple, O = ( inputs , apps , dist , stime , v ) , that details a policy violation’s rootcause. Here, dist is the distance from actuators to sensors, stime is the actuators’ start times, and v is a set of { Int , UnInt } labeledsensor and actuator states. Turning to Figure 1, robot - vacuum - on ( App ) triggers motion - active ( MalApp ) that turns on the lights andunlocks the patio door. The security analyzer outputs a quintuple: input = ( [ robot - vacuum - on ]) , apps = (cid:2) [ timer , robot - vacuum , app ] , [ mot - sen , light , pat - door , malapp ] (cid:3) , stime ( robot - vacuum ) = , dist ( robot - vacuum , mot - sensor ) = , v = (cid:2) [ timer - event , robot - vacuum . move ] , [ motion - active ( UnInt ) , light . on , patio - door . unlocked ] (cid:3) , The security analyzer parses the quintuple to identify the root cause, robot - vacuum - on ’s UnInt motion triggers motion - active event invok-ing actuation commands. It further outputs the violation occurswhen the robot - vacuum - on command is invoked at minute of theautomata execution, and it is m away from the motion sensor. Patching the IoT Deployment.
We present a report that guidesusers to patch an IoT deployment and eliminate the identified phys-ical interaction vulnerabilities. The security analyzer first reportsto users which apps to remove to eliminate the physical interaction.For instance, removing
App or MalApp eliminates the individualpolicy violation above. However, users may not always desire to re-move apps if their functionality is needed. In this case, the securityanalyzer proposes patches based on the violated policy category.If an aggregation or a dependency policy is violated, it outputs apredicate code block, which guards the app’s actuation commands,to be inserted to app source code. The predicate is false if otheractuation commands in the policy violation were invoked withina time limit (determined from the actuators’ stime ). This means ab c Sensors d ef
Actuators
TemperatureHeater Humidity SmokeIlluminance Sound MotionOvenPressure CookerCoffee MakerDehumidifier WasherDryerHumidifier TVRobot VacuumLight BulbACGarbage Disposal bf c3 45a d m Figure 7: Sensor/actuator layout in the actual house. the app cannot invoke its actuation command causing the physi-cal interaction. Turning to the scenario 2 in Figure 1, we insert apredicate in
MalApp that checks if cooker - on occurred. If it did oc-cur, the predicate blocks the oven - on command. This eliminates theinteraction with the temperature sensor in App since cooker - on ’s in-dividual influence cannot trigger an event. If an individual policy isviolated, the security analyzer guides users to increase the distancebetween the actuator and the sensor. For instance, increasing thedistance between the sound sensor and the exhaust fan eliminatesthe interaction between MalApp ’s fan - on and App ’s sound - detected . We evaluate
IoTSeer in a real home with 6 sensors and 13 actuators,as shown in Figure 7. We use 37 popular official IFTTT apps [35] toautomate the IoT devices. We constructed 26 actuation commandand 6 sensor event automata from the apps. Table 2 presents physi-cal channel labels (
Int / UnInt ) of each actuation command measuredby sensors. We develop
IoTSeer in Matlab [42] using the Simulinktoolbox [43]. We present the apps, automata flow functions, and anexample automaton developed in Simulink in Appendix 1. We runthe automata executions on a laptop with a 2 . mins with a secs time-step tocollect data traces for automata conformance and policy validation.We begin by evaluating the conformance of the automata withreal devices (Section 6.1). We next validate the policies on the com-posite automaton and identify policy violations (Section 6.2). Weverify all reported violations are true positives through experimentsin the actual house (Section 6.2.1). Lastly, we present IoTSeer ’s per-formance overhead (Section 6.3).
We evaluate the conformance of device automata with actual de-vices and tune automata parameters. We first select all actuationcommand and sensor pairs where the sensor measures the actuationcommand’s influence. We then set the distance in each pair to . m- . m with . m intervals. We collect the traces of automataand real devices for each distance. We then integrate the impactof environmental factors into the composite automaton. We nextinvoke actuation commands and collect sensor traces when an au-thor and an independent Ph.D. student are conducting activities(e.g., cooking and exercising) and with furniture placed based on theexperimental house. We also collect traces when only mechanical9 able 3: ( 𝜏, 𝜖 ) -closeness of model and IoT devices. Temperature Illum. Sound Humidity Motion SmokeActuator 𝜏 𝜖 𝜏 𝜖 𝜏 𝜖 𝜏 𝜖 𝜏 𝜖 𝜏 𝜖
Heater . ± . / A N / A 5 . ± . . ± . / A N / A Oven . ± . / A N / A 1 . ± . / A 0 0
Pressure Cooker ± . . ± . / A N / A 1 ± . . ± . / A N / A Coffee maker / 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 . ± . / A Dryer . ± . / A 0 0 . ± . . ± . / A Humidifier N / A N / A N / A 0 . ± . . ± . / A N / A Garbage Disposal N / A N / A 0 0 . ± . / A N / A N / A TV N / A 0 18 . ±
37 0 0 N / A N / A N / A Vacuum Robot N / A N / A N / A N / A 0 . ± .
07 0 N / A Light Bulb N / A 0 20 . ± . / A N / A N / A N / A AC . ± . / A 0 0 . ± . . ± . ± . / A N / A Measurement units: 𝜏 : minutes; 𝜖 : depends on the physical quantity; Motion, smoke, sound:binary; Illuminance: luminous flux; Temperature: ° F ; Humidity: RH %. devices are turned on to estimate the noise from the environmen-tal factors. We use these data traces to tune automata parametersand integrate environmental factors. This process ensures that acomposite automaton has the correct functionality with the IoTdeployment amenable to policy validation. Tuning Automata Parameters.
We found that out of actua-tion command automata have high deviation scores ( ( 𝜏, 𝜖 ) -closeness).These include AC - on (3), heater - on (2), oven - on (1), humidifier - on (1), dehumidifier - on (1), garbage - disposal - on (1), and TV - on (1)–the val-ues in parentheses represent the number of automata with highdeviation scores. To illustrate, the sound sensor automaton detectsthe garbage - disposal - on ’s sound in greater distances than those ob-served in the actual device traces. Specifically, the deviation scoreis 𝜖 = (highest for a binary output) when the distance betweenthe garbage disposal and sound sensor is greater than meter. Toaddress this, we use SI and find the optimal automata configura-tions where the deviation score between automata traces and devicetraces are minimized. For instance, we found that decreasing thesound pressure parameter of the garbage - disposal - on automatonminimizes the deviation. Following the same approach for 10 actua-tion command automata, we tuned their configuration parameters.Table 3 details the ( 𝜏, 𝜖 ) -closeness of actual devices with theautomata after parameters are tuned. Each row includes the meanand standard deviation of the timing difference ( 𝜏 ) and deviationscore ( 𝜖 ) in different distances. We observe slight deviations in tem-perature, illuminance, sound, and humidity automata inputs. This isdue to the uncertainties in the environmental factors (e.g., amountof sunlight in the room [22]) that impact actual device traces.To illustrate, Figure 8 plots the traces from automata and deviceexperiments of light - bulb - on ’s influence on the illuminance sensorand oven - on ’s influence on the temperature sensor. We found thatthe light - bulb - on automaton deviates on average ≈
20 lux fromdevice data traces. Additionally, oven - on increases the temperaturesensor readings by . ° F in both automata and actual device tracesat . meters. The automaton yields an increase at minute . , butthe increase in the device traces occurs at . . This leads to onaverage 𝜏 = . ± . timing difference and 𝜖 = deviation score.As we detail in Section 6.2, these observations lead to safe over-approximation in detecting violations at slightly different times. Environmental Factors.
We evaluate the following environmen-tal factors in the house’s actual layout (depicted in Figure 7): (1)humans doing an activity in the environment, (2) furniture betweendevices, and (3) an uncontrolled environmental noise. We foundthese factors impact automata conformance under rare conditions. 𝜖 – deviation score 𝜏 – timing difference Figure 8:
Automata and device traces: (Left) light - bulb - on changesthe illum. and (Right) oven - on changes the temp. sensor readings. To account for them, we add new automata to composite automataand refine the actuation command automata’s flow functions.
Human Inhabitants.
To assess the human-presence on physi-cal channels, we obtain traces from sensors when an author and anindependent Ph.D. student are cooking, watching TV, and exercis-ing. We select these common activities as they potentially influencethe temperature and humidity physical channels. We evaluate theimpact of body heat and respiration on physical channels, as actua-tion command automata of cooking appliances and TV are alreadyconstructed. We observe a % RH increase in humidity sensor read-ings when a user is < cm away from the sensor and exercisingfor 10 mins. For other activities, the users do not introduce de-tectable changes to sensors. We add a human - exercising automatonwith Int label output into the composite automaton to account forthe user’s influence on humidity. The { on , off } states are defined asuser-present and not-present that allows executing the compositeautomaton with and without human presence in the house. Physical Obstacles.
We collect sensor data traces with furni-ture placed between devices based on the room layout. The opaqueobstacles between a light source (bulb and TV) and illuminancesensor change the sensor readings, whereas furniture negligiblyimpacts other physical channels. For instance, when the bulb turnson . m away from the sensor, we observe ≈ lux without anobstacle, and ≈ lux with an obstacle. To integrate this into com-posite automata, we refine the bulb - on automaton by multiplyingits output with a coefficient c = . , which is obtained from thedeviation difference between automata and actual sensor traces. Environmental Noise.
To evaluate uncontrolled environmen-tal factors, we obtain data traces from sensors when only the me-chanical devices in the deployment are on. We observe a ± . dB ambient noise on the sound sensor due to the refrigerator en-gine’s routine sound, whereas the noise on other physical channelswas negligible. Hence, we add an ambient - noise automaton thatinfluences the sound sensor with Gaussian noise of mean 𝜇 = and standard deviation 𝜎 = . to the composite automaton. Table 4 presents 11 flagged policy violations caused by physicalinteractions among different groups of devices in 37 apps installedin the house. In these experiments, we use the composite automatonof apps after automata conformance when a user is present. All vio-lations are identified with both grid-based testing and falsification.
IoTSeer ’s prototype implementation (before automata confor-mance) identified 9 out of 11 policy violations, where two viola-tions involving AC - on ’s sound and humidity physical channels were10 able 4: Policy violations identified by IoTSeer . P ID Devices Violation Description Example Apps Triggered
I V [ A : GarbageDisposal ( )] , Sound sensor detects
UnAuth sound
App : sound detected −−−−−−−−−−−−−→ turn on lights [ S : SoundSensor ( e )] of the garbage disposal and triggers apps. App : sound detected −−−−−−−−−−−−−→ DM roommate V [ A : VacuumRobot ( )] , Motion sensor detects
UnAuth motion
App : motion det . −−−−−−−−−−→ turn on oven, cooker [ S : MotionSensor ( f )] of the robot vacuum and triggers apps. App : motion det . −−−−−−−−−−→ call the user G V [ A : CoffeeMaker ( )] , Temperature sensor reading increases
App : temp > t ° F −−−−−−−−→ turn on AC [ A : Oven ( )] , [ A : Dryer ( )] , due to UnAuth heat of the
App : temp > t ° F −−−−−−−−→ turn on humidifier [ A : PressureCooker ( )] , coffee maker, oven, dryer and [ S : TempSensor ( a )] pressure cooker, and triggers apps. V [ A : AC ( )] , [ A : Washer ( )] , Sound sensor detects
UnAuth App : sound detected −−−−−−−−−−−−−→ call your phone [ A : Dryer ( )] , sound of the AC, washer and dryer, App : sound detected −−−−−−−−−−−−−→ turn on TV [[ S : SoundSensor ( e )] and triggers apps. V [ A : CoffeeMaker ( )] , Humidity sensor reading decreases due
App : hum < RH % −−−−−−−→ turn on humidifier [ A : Oven ( )] , [ A : Dryer ( )] , to UnAuth heat from the coffee maker,
App : hum < RH % −−−−−−−→ turn off AC [ A : PressureCooker ( )] , oven, dryer, pressure cooker and [ A : Washer ( )] , washer, and triggers apps. [ S : HumSensor ( b )] G V [ A : Heater ( )] , Temperature sensor reading increases
App : temp > t ° F −−−−−−−−→ turn on humidifier [ A : CoffeeMaker ( )] , due to Auth heat of the heater and
UnAuth App : temp > t ° F −−−−−−−−→ turn off heater [ S : TempSensor ( a )] heat of the coffee maker, and triggers apps. V [ A : Bulb ( )] , Illuminance sensor detects
Auth App : light detected −−−−−−−−−−−−−→ turn off lights [ A : TV ( )] , luminance of the bulb and UnAuth [ S : IllumSensor ( d )] luminance of the TV, and triggers apps. G V [ A : Heater ( )] , [ A : AC ( )] , The heater and AC have conflicting
App : temp > t ° F −−−−−−−−−→ turn off heater [ S : TempSensor ( a )] impacts on temperature sensor reading. App : temp > t ° F −−−−−−−−−→ turn off AC V [ A : Humidifier ( )] , The humidifier and AC have conflicting
App : hum < RH % −−−−−−−−→ turn off AC [ A : AC ( )] , impacts on humidity sensor reading. App : hum > RH % −−−−−−−−→ turn off humidifier [ S : HumSensor ( b )] V [ A : Humidifier ( )] , The humidifier and dehumidifier have
App : hum < RH % −−−−−−−−→ turn off dehumidifier [ A : Dehumidifier ( )] , conflicting impacts on App : hum > RH % −−−−−−−−→ turn off humidifier [ S : HumSensor ( b )] humidity sensor reading. D V [ A : Humidifier ( )] , The heater and humidifier have conflicting
App : hum > RH % −−−−−−−→ turn off humidifier [ A : Heater ( )] , impacts on humidity sensor reading [ S : HumSensor ( b )] due to the dependency.Both grid-based testing and optimization-guided falsification identify all violations. Grid-based testing outputs multiplestart times which cause the violation, falsification outputs a single start time for each actuator. missed due to the high deviations in its automata. We exercised eachpolicy violation in the house and verified they are true positives. Individual Policy ( I ) Violations. IoTSeer flagged two uniquephysical interactions that cause I violations. UnInt sound from garbage - disposal - on triggers 5 apps ( V ), and UnInt motion from robot - vacuum - on triggers 5 apps ( V ). For instance, in V , the soundsensor ( e ) detects the sound from garbage disposal ( 9 ) and triggers App that turns on the lights, and App that sends a notification. In V , the motion sensor ( f ) detects the presence of the robot vacuum( ) and triggers App that calls the user, and App that turns onthe oven and cooker. We note that there are many other apps in theIFTTT market conditioned on sound - detected and motion - active events, such as those that open the garage door, window, or soundan alarm. While these apps do not yield I policy violations in theexperimental house as the actuators are not installed, such interac-tions may cause violations in different deployments. Aggregation Policy ( G ) Violations. IoTSeer flagged eight uniquephysical interactions among 25 apps causing G − G violations. Wedetail a violation for each aggregation policy, V for G , V for G , and V for G . In V , the temperature sensor ( b ) measures the aggregated UnInt temperature from coffee - maker - on ( 4 ), oven - on ( 2 ), dryer - on ( 7 ), and cooker - on ( 3 ). The increase in temperature triggers App that turns on the AC, and App that turns on the humidifier. We notethat the same violation occurs when a subset of these commands(two or three of them) are invoked. In V , the illuminance sensor ( d )measures the aggregated luminance of bulb - on ( ) and TV - on ( ).The increase in luminance triggers ( App ) turning off the bulb. Here, bulb - on ’s Int labeled luminance does not exceed the illuminancesensor’s sensitivity threshold. Yet, its aggregation with TV - on ’s UnInt luminance exceeds the threshold. Lastly, in V , the heater ( 1 ) andAC ( ) turn on at the same time that causes a conflicting influenceon the temperature sensor’s measurements ( a ). Light Not Detected Light Detected (Green)Motion Sensor Motion Not DetectedMotion Sensor Motion Detected (b) V policy violation(a) V policy violation Figure 9: Illustration of (a) V violation, and (b) V violation.Dependency Policy ( D ) Violation. IoTSeer identified a single de-pendency violation ( V ) between 4 apps. This violation happenswhen heater - on ( 1 ) increases temperature and humidifier - on ( 8 )increases humidity. The dependency between humidity and tem-perature leads to a conflicting impact on the humidity sensor ( b ). We validate each iden-tified violation in the house containing the real IoT devices andconfirm that all ( V - V ) occur. In-home validation begins by ana-lyzing the root cause of each violation via the quintuple ( inputs , apps , dist , stime , y ) logged by IoTSeer . We place the sensors andactuators at the distances given by dist and turn on each actuatorinvolved in the violation using its inputs and stime . We record thetraces for each violation and confirm the interacting apps . Lastly, wecompare automata and device traces to identify any discrepancies.Figure 9-a illustrates a V violation, motion - active event occursdue to the robot - vacuum - on command. Figure 9-b illustrates a V violation. The illuminance sensor does not detect the Int lumi-nance from bulb - on , but generates a light - detected event due tothe aggregated luminance of bulb - on ( Int ) and TV - on ( UnInt ).The policy violations on continuous physical channels (temper-ature and humidity) are observed earlier in the house, comparedto automata executions. In contrast, violations on instant physicalchannels (motion, sound, and light) are observed with minor timedeviations. For instance, when coffee - maker - on , oven - on , dryer - on ,and cooker - on occur at time in the executions, IoTSeer flagged a V at time . . However, the violation is observed at time ≈ inthe house experiments. As detailed in automata conformance exper-iments in Section 6.1, the discrepancy in timing between automataand device traces is expected due to inevitable environmental noise. We compare the policyviolations flagged by
IoTSeer with IoT systems in Table 5, Men-Shen [10], iRuler [60], IoTCom [3], IoTMon [21], that target iden-tifying physical interactions among IoT apps. If we assume thesesystems correctly map all 26 physical channels of 13 actuationcommands in our deployment through manual mappings or NLPtechniques, they are able to identify 2 out of 11 violations (indi-vidual ( I ) policy violations V and V ). This is because they do notmodel the physical behavior of devices and do not consider aggrega-tion and dependency. Additionally, they flag 24 false alarms as mostphysical channels do not individually cause app interactions. Toillustrate, they define a physical channel between the temperaturesensor and oven; however, in our deployment, oven - on ’s individualinfluence on temperature is not enough to cause an interaction.11 able 5: A comparison of IoTSeer with other IoT systems.
Physical Channel Properties Security AnalysisSystem Distance Agg. Dep. Labels Time Policy Root Cause(Int/UnInt) Constraints Validation † Analysis
MenShen [10] ✗ ✗ ✗ ✗ ✗ RA ✗ iRuler [60] ✗ ✗ ✗ ✗ ✗ RL ✗ IoTCom [3] ✗ ✗ ✗ ✗ ✗ MC ✗ IoTMon [21] ✗ ✗ ✗ ✗ N / A ✗ ✗ IoTSeer ✓ ✓ ✓ ✓ ✓ F & T ✓ † RA :Reachability Analysis, RL :Rewriting Logic, MC :Model Checking, F :Falsification, T : Testing. IoTSeer to other IoT Deployments.
Users can port
IoTSeer to other IoT deployments by following 4 steps. (1) Usersneed to derive the automata of actuation commands and sensorevents and update the physical-channel reference file if their IoT de-ployment includes apps that automate devices different from the 13actuators and 6 sensors we considered. Our constructed automataare generic for a family of devices and can be directly used if theautomata of new devices change the same physical channels. 5 (2)Users need to update the automata parameters through device specsheets (e.g., the operation power of oven), which is necessary toobtain the correct physical behavior of actual devices. (3) The phys-ical channel labels (
Int / UnInt ) of the physical interaction policytemplates (Table 1) need to be updated based on the users’ needs.(4) Users need to collect data traces from IoT deployment to tunethe automata parameters for precision and to accommodate for theenvironmental factors (Detailed in Section 6.3).
Automata Size vs. Time.
We evaluate the overhead of
IoTSeer ’spolicy validation algorithms with an increasing automata size. Fig-ure 10 (Left) shows the policy validation time with an increasingnumber of actuation command automata that influence the samephysical channel. Grid-based testing time overhead increases withthe number of actuation commands as each policy is validated usinga combination of actuator start times, and all violations are identi-fied. On the contrary, falsification maintains a near constant timeoverhead. The optimization algorithm samples actuator start timesand searches for low robustness values for a single violation. Thisadds a negligible delay, on the order of seconds, to policy validationwith an increasing number of actuation commands.
Number of Policies vs. Time.
We evaluate the policy validationtime with an increasing number of policies. We set the numberof actuation command automata to three, and a sensor measurestheir aggregated influence on a physical channel. Figure 10 (Right)shows the time overhead of both testing and falsification increaseslinearly with the number of policies. Testing takes ≈ × longerthan falsification because it reports all violations, while falsificationsearches for a single counterexample that violates the policy. Time for Trace Collection.
We present the time for trace col-lection from constructed automata and actual devices for (1) gen-erating the physical-channel reference file, (2) tuning automataparameters, and (3) addressing environmental factors. These stepsare required to improve
IoTSeer ’s accuracy in finding physical in-teractions among apps and minimizing the false alarms. Here wenote that, even without steps 2 and 3,
IoTSeer identified 9 out of 11violations in our experimental house by only using the automataconstructed through physics-based modeling. First, to generate thephysical-channel reference file (Table 2), we collected . hours of T i m e ( s ) ( l og ) Grid-based TestingFalsification T i m e ( s ) Grid-based TestingFalsification
Figure 10: (Left) data traces from 13 actuation commands that impact 6 sensor’s mea-surements. Second, we recorded . hours of data traces to tuneautomata parameters through conformance experiments. This is animprovement over generating the flow functions by system identifi-cation solely using device traces, which would require ≈ hoursof data traces with different device configurations and distances.Lastly, to address the environmental factors, we recorded . hoursof traces and spent . hours to define new automata and derivecoefficients for integrating them into the composite automaton. IoTSeer can be used to validate additional safety and security poli-cies that are based on the use cases of one or multiple devices. Forinstance, a user may desire to validate a policy that states the alarmmust go off in two seconds after smoke is detected. This can be rep-resented with MTL as □ ( ( smoke > threshold ) → (cid:51) [ , ] ( alarm = ON )) .In future work, we will identify such policies through requirementsengineering and validate them on the composite automata. IoTSeer defines the flow functions of the actuation commandsand sensor events through algebraic and differential equations thatare well-studied in control theory. However, there may be morecomplex equations that are a better contextual fit. These can beintegrated into
IoTSeer by replacing the automata’s flow functions.Future work will study the optimization techniques such asactuation commands’ monotonic behavior on physical channels tominimize the validation inputs for scalability, and evaluate
IoTSeer in other deployments such as safety-critical CPSs.
There has been an increasing number of works in IoT safety andsecurity. We compare
IoTSeer with several recent approaches thatfocus on the identification of physical interactions among IoT apps.As presented in Table 5,
IoTSeer is the first system that integratesthe complex properties of the physical behavior of actuation com-mands and sensor events into the source code of IoT apps (Columns“Physical Channel Properties”). Unfortunately, none of the systemsmodel the complex physical behavior of apps but they manuallybuild physical channel mappings (e.g., a mapping between heaterand temperature) [3], generate naive actuator models (e.g., ovenincreases temperature 1° 𝐹 per hour) [10], or use machine learningtechniques (e.g., inspection of apps’ text descriptions) [21, 60] toinfer interacting apps. Therefore, they identify limited physical in-teractions and lead to significant false positives, as we compared thenumber of violations they can identify with IoTSeer in Section 6.2.2.The systems studied here use different formulas (e.g., LTL) toexpress the physical interactions and different verification tech-niques (e.g., model checking) to validate policies on the abstracted12pp models (Columns "Security Analysis"). However, their policyrepresentations do not consider timing constraints on the physicalchannels and physical channel labels. Additionally, their validationtechniques cannot be readily used to verify physical interactionssince apps exhibit both discrete and continuous behaviors. In con-trast,
IoTSeer expresses policies with MTL for timing constraints,integrates physical channel labels into MTL, and extends grid-basedtesting for exhaustiveness and falsification for scalability in pol-icy validation of large-scale IoT deployments. Lastly, none of thesystems is able to identify the root cause of the complex physicalinteractions.
IoTSeer reports the root cause of the violation andproposes patches that guide users on how to fix them.
We present the
IoTSeer security service, which identifies the physi-cal interaction vulnerabilities in IoT deployments. Our evaluationin a real house demonstrates that many apps interact with eachother, and
IoTSeer efficiently identifies all policy violations.
IoTSeer is an important step forward in achieving the compositional safetyand security of an IoT system’s physical behavior.
REFERENCES [1] Houssam Abbas, Georgios Fainekos, Sriram Sankaranarayanan, Franjo Ivančić,and Aarti Gupta. 2013. Probabilistic temporal logic falsification of cyber-physicalsystems.
ACM Transactions on Embedded Computing Systems (TECS)
12 (2013).[2] Houssam Abbas, Hans Mittelmann, and Georgios Fainekos. 2014. Formal propertyverification in a conformance testing framework. In
ACM/IEEE Conference onFormal Methods and Models for Codesign (MEMOCODE) .[3] Mohannad Alhanahnah, Clay Stevens, and Hamid Bagheri. 2020. Scalable analysisof interaction threats in IoT systems. In
Proceedings of the 29th ACM SIGSOFTInternational Symposium on Software Testing and Analysis . 272–285.[4] Yashwanth Singh Rahul Annapureddy and Georgios E Fainekos. 2010. Antcolonies for temporal logic falsification of hybrid systems. In
IECON 36th AnnualConference on IEEE Industrial Electronics Society . IEEE.[5] Yashwanth Annpureddy, Che Liu, Georgios Fainekos, and Sriram Sankara-narayanan. 2011. S-taliro: A tool for temporal logic falsification for hybridsystems. In
International Conference on Tools and Algorithms for the Constructionand Analysis of Systems . Springer.[6] Apiant 2020. Apiant: Connect your apps, automate your business. https://apiant.com/. (2020). [Online; accessed 30-August-2020].[7] Musard Balliu, Massimo Merro, and Michele Pasqua. 2019. Securing cross-appinteractions in iot platforms. In
IEEE Computer Security Foundations Symposium .[8] Musard Balliu, Massimo Merro, Michele Pasqua, and Mikhail Shcherbakov. 2020.Friendly Fire: Cross-App Interactions in IoT Platforms.
ACM Transactions onPrivacy and Security (TOPS) (2020).[9] Louis A Bloomfield. 2007.
How everything works: making physics out of theordinary . John Wiley & Sons.[10] Lei Bu, Wen Xiong, Chieh-Jan Mike Liang, Shi Han, Dongmei Zhang, Shan Lin,and Xuandong Li. 2018. Systematically ensuring the confidence of real-timehome automation IoT systems.
ACM Transactions on Cyber-Physical Systems
NIST Tech. Note
ACM Computing Surveys (CSUR)
52, 4 (2019),1–30.[13] Z Berkay Celik, Patrick McDaniel, and Gang Tan. 2018. Soteria: Automated iotsafety and security analysis. In
USENIX Annual Technical Conference (USENIXATC) .[14] Z Berkay Celik, Gang Tan, and Patrick D McDaniel. 2019. IoTGuard: DynamicEnforcement of Security and Safety Policy in Commodity IoT. In
NDSS .[15] Yuqi Chen, Christopher M Poskitt, and Jun Sun. 2018. Learning from mutants:Using code mutation to learn and monitor invariants of a cyber-physical system.In
IEEE Symposium on Security and Privacy (S&P) .[16] Hongjun Choi, Sayali Kate, Yousra Aafer, Xiangyu Zhang, and Dongyan Xu. 2020.Software-based Realtime Recovery from Sensor Attacks on Robotic Vehicles. In
International Symposium on Research in Attacks, Intrusions and Defenses (RAID) . [17] Hongjun Choi, Wen-Chuan Lee, Yousra Aafer, Fan Fei, Zhan Tu, Xiangyu Zhang,Dongyan Xu, and Xinyan Deng. 2018. Detecting attacks against robotic vehicles:A control invariant approach. In
ACM SIGSAC Conference on Computer andCommunications Security (CCS) .[18] Edmund M Clarke and E Allen Emerson. 1981. Design and synthesis of synchro-nization skeletons using branching time temporal logic. In
Workshop on Logic ofPrograms . Springer.[19] R Clausius. 1850. On the motive power of heat and the laws which can bededuced therefrom regarding the theory of heat.
Annalen der Physik
Proceedings of the 35th Annual Computer Security Applications Conference .[21] Wenbo Ding and Hongxin Hu. 2018. On the safety of IoT device physicalinteraction control. In
ACM SIGSAC Conference on Computer and CommunicationsSecurity (CCS) .[22] Isaac Elishakoff. 2000.
Whys and hows in uncertainty modelling . Springer.[23] Georgios Fainekos, Bardh Hoxha, and Sriram Sankaranarayanan. 2019. Robust-ness of Specifications and Its Applications to Falsification, Parameter Mining,and Runtime Monitoring with S-TaLiRo. In
International Conference on RuntimeVerification . Springer.[24] Georgios E Fainekos and George J Pappas. 2006. Robustness of temporal logicspecifications. In
Formal Approaches to Software Testing and Runtime Verification .Springer.[25] Forum Post 2015. High utility bills? Your thermostat might be on the wrongwall - Comments. https://tinyurl.com/y39wwee8. (2015). [Online; accessed25-August-2020].[26] Forum Post 2018. Roomba sets off motion sensor at night? https://tinyurl.com/yyux5fys. (2018). [Online; accessed 25-August-2020].[27] Leon R Glicksman and Steven Taub. 1997. Thermal and behavioral modeling ofoccupant-controlled heating, ventilating and air conditioning systems.
Energyand Buildings
NDSS .[30] Rafal Goebel, Ricardo G Sanfelice, and Andrew R Teel. 2009. Hybrid dynamicalsystems.
IEEE control systems magazine
29, 2 (2009), 28–93.[31] Matthew J Hancock. 2006. The 1-D heat equation.
MIT OpenCourseWare.
Tables of thermal properties of gases: comprising tablesof thermodynamic and transport properties of air, argon, carbon dioxide, carbonmonoxide, hydrogen, nitrogen, oxygen, and steam
JOM
48, 9 (1996), 16–23.[37] Karel J Keesman. 2011.
System identification: an introduction . Springer Science &Business Media.[38] Ron Koymans. 1990. Specifying real-time properties with metric temporal logic.
Real-time systems
2, 4 (1990), 255–299.[39] Mark G Lawrence. 2005. The relationship between relative humidity and thedewpoint temperature in moist air: A simple conversion and applications.
Bulletinof the American Meteorological Society
86, 2 (2005), 225–234.[40] T G Lee and George W Mulholland. 1977. Physical Properties of Smokes Pertinentto Smoke Detector Technology. Final Report.
NIST Interagency/Internal Report(NISTIR) (1977).[41] Nancy Lynch, Roberto Segala, and Frits Vaandrager. 2003. Hybrid i/o automata.
Information and computation
Fiber Optics . Springer, 259–261.[45] Dang Tu Nguyen, Chengyu Song, Zhiyun Qian, Srikanth V Krishnamurthy,Edward JM Colbert, and Patrick McDaniel. 2018. IoTSan: Fortifying the safetyof IoT systems. In
Proceedings of the 14th International Conference on emergingNetworking Experiments and Technologies . IEEE.
48] Claudius Ptolemaeus (Ed.). 2014.
System Design, Modeling, and Simulation usingPtolemy II . Ptolemy.org. http://ptolemy.org/books/Systems[49] Raul Quinonez, Jairo Giraldo, Luis Salazar, and Erick Bauman. 2020. SAVIOR:Securing Autonomous Vehicles with Robust Physical Invariants. In
USENIXSecurity
Noise theory and application to physics: from fluctuationsto information . Springer Science & Business Media.[52] Agustin Salazar. 2003. On thermal diffusivity.
European journal of physics
Proceedings of the 26th InternationalConference on World Wide Web .[57] Blase Ur, Melwyn Pak Yong Ho, Stephen Brawner, Jiyun Lee, Sarah Mennicken,Noah Picard, Diane Schulze, and Michael L Littman. 2016. Trigger-action pro-gramming in the wild: An analysis of 200,000 IFTTT recipes. In
CHI Conferenceon Human Factors in Computing Systems .[58] JT Van Ginkel and E Hasselaar. 2006. Moisture balance in dwellings.
HealthyBuildings proceedings (Volume 3); Design and operation of healthy buildings (2006).[59] Nikolaos Voudoukis and Sarantos Oikonomidis. 2017. Inverse square law for lightand radiation: A unifying educational approach.
European Journal of EngineeringResearch and Science
2, 11 (2017), 23–27.[60] Qi Wang, Pubali Datta, Wei Yang, Si Liu, Adam Bates, and Carl A Gunter. 2019.Charting the Attack Surface of Trigger-Action IoT Platforms. In
ACM SIGSACConference on Computer and Communications Security (CCS) .[61] Ethan Winer. 2012.
The audio expert: everything you need to know about audio .CRC Press.[62] Zapier 2020. Zapier: Connect your apps and automate workflows. https://zapier.com/. (2020). [Online; accessed 30-August-2020].[63] Lefan Zhang, Weijia He, Jesse Martinez, Noah Brackenbury, Shan Lu, and BlaseUr. 2019. AutoTap: synthesizing and repairing trigger-action programs usingLTL properties. In .[64] Mu Zhang, Chien-Ying Chen, Bin-Chou Kao, Yassine Qamsane, Yuru Shao, YikaiLin, Elaine Shi, Sibin Mohan, Kira Barton, James Moyne, and Z. Morley Mao.2019. Towards Automated Safety Vetting of PLC Code in Real-World Plants. In
IEEE Symposium on Security and Privacy (S&P) .[65] Valerie Zhao, Lefan Zhang, Bo Wang, Shan Lu, and Blase Ur. 2020. VisualizingDifferences to Improve End-User Understanding of Trigger-Action Programs. In
CHI Conference on Human Factors in Computing Systems .[66] Alexander Zhivov, Hakon Skistad, Elisabeth Mundt, Vladimir Posokhin, MikeRatcliff, Eugene Shilkrot, and Andrey Strongin. 2001. Principles of air andcontaminant movement inside and around buildings. In
Industrial ventilationdesign guidebook . Elsevier.
APPENDIX1 APPENDIX GUIDE
This Appendix provides the necessary information to reproduceour results. In Appendix 2, we present an example composite au-tomaton developed with Simulink. In Appendix 3, we detail theapps considered in our motivation and experiments. In Appendix 4,we present the implementation of our policy validation techniques.In Appendix 5, we present our flow functions of the studied actua-tion commands and sensor events. In Appendix 6, we present theimpact of actuation commands on physical quantities, the distancesbetween the sensors they impact, and the sensor sensitivity levels.We note that
IoTSeer contains all the tools necessary to extendthe composite automaton to other apps, and allows for replacingthe flow functions of the studied actuation commands and sensorevents with ones that may be a better contextual fit.
Figure 1: Simulink automaton of light - bulb - on , TV - on , and light - detected . The composite automaton of light - bulb - on , TV - on commands and light - detected event is presented in Figure 1. The actuation com-mand and sensor event automata (including their flow functions)are implemented within Matlab functions inside the Simulink boxes.We note that IoTSeer ’s implementation can be easily migrated toother software such as GNU Octave [28], SpaceEx [55], Scilab [53]with third-party code converters.
Table 1 lists the description of the apps considered in our paper. Ex _ App - Ex _ App and MalApp - MalApp are the apps used in Sec-tion 3 Figure 1. App - App are the apps deployed in our experimentsin Section 6 from the official IFTTT trigger-action platform. We use open-source temporal logic falsification toolbox
S-TaLiRo ’s [5] dptaliro function as a subroutine into our grid-based testing al-gorithm and the staliro function into optimization-guided falsifi-cation to validate MTL policies on the composite automaton. Weuse the staliro function with simulated annealing by hit-and-runMonte Carlo sampling for input generation [23]. In both functions,we use a dynamic programming-based algorithm to compute therobustness of MTL policies.
Parameter Selection.
For grid-based testing, we set fixed dis-tances among sensors and actuators as in Figure 7. We considerapps invoke actuation commands with -min intervals, thus, theactuators’ start times are set as a grid to : : . For falsification,we set ranges for distances among sensors/actuators as ± . m onthe placement in Figure 7 to account for possible variations. Weset the actuators’ start time ranges as any time in the execution( − ). We define the maximum number of tests to as we donot observe a significant change in robustness after . To determine the flow functions of automata, we first analyze thephysical channels each sensor event observes [36, 59]. We thenstudy how actuation commands influence these channels, and howthey diffuse in a way that changes the sensor readings [9, 11, 19,14 able 1: App list and their descriptions.
ID Description Apps used in Figure 1 in Section 3. Ex _ App Activates iRobot at specific times defined by the user Ex _ App Activates the pressure cooker and cooking-mode at a specific time Ex _ App Opens the window when the temperature exceeds a specific threshold Ex _ App Sends the user a notification when sound is detected in a home’s “away” mode
MalApp Turns on the oven and exhaust fan when the user activates the cooking mode
MalApp Turns on the light and opens the patio door when motion is detected
IFTTT apps considered in the evaluation (Section 6).
App Activates the heater at a user-defined time
App Activates the oven at a user-defined time
App Activates the pressure cooker at a user-defined time
App Activates the coffee maker at a user-defined time
App Activates the dehumidifier at a user-defined time
App Activates the clothes washer at a user-defined time
App Activates the dryer at a user-defined time
App Activates the humidifier at a user-defined time
App Activates the garbage disposal at a user-defined time
App Activates the TV at a user-defined time
App Activates the robot vacuum at a user-defined time
App Activates the light bulb at a user-defined time
App Activates the AC at a user-defined time
App Activates robot vacuum when the home mode is set to “away” or “vacation”
App Wiser (thermostat) “away mode” ON at a user-defined time
App Notifies user when sound is detected
App Turns on the light when sound is detected
App Calls a user’s phone when Nest detects sound
App Turns on a Hubitat device (TV) when motion or sound is detected
App Sends roommate a message when it gets too loud in the house
App Turns on the AC if the temperature is above a threshold
App Activates the heater when the sensor reports too cold;Turns off the heater when temperature is normal
App Turns on Kasa plug (humidifier) when temperature is above a threshold
App Turns on the pressure cooker and oven when motion is detected
App Calls the user when motion is detected
App Turns on the light when motion is detected
App Turns on smart plug (dehumidifer) when motion is detected by a specific sensor
App Calls the user when smoke is detected
App Turns on all lights in case of a smoke detection
App Turns on AC if humidity rises above a threshold
App Activates the humidifier when the air is dry
App Switches off a SmartLife plug (AC) according to humidity sensor status
App Flashes a light if humidity level is high
App Turns off the light when the room gets bright
App Turns off humidifier when humidity has risen back to normal level
App Turns off dehumidifier when humidity sensor detects low humidity
App Turns on/off the AC based on the temperature of the room (setTemp)
31, 39, 52, 66]. Here, we present the equations that rely on the lawsof physics, that are integrated into our automata as flow functions.Different equations that can capture more detailed influences ofactuation commands on physical channels can be easily integratedby updating the corresponding flow functions.
Temperature.
Actuation commands’
UnInt influences on temper-ature are due to hot surfaces diffusing heat to their surroundings.Therefore, the heat diffusion equation from a point source [31](which is based on a partial differential equation) is used as theirflow function. 𝜕 T 𝜕 t = 𝛼 𝜕 T 𝜕 x (1) T ( e , ) = T (2) T ( , ) = T s (3)In the formula, T is temperature in ° K , x is the distance from theactuator in meters, 𝛼 is the thermal diffusivity constant (in m / s ), e is the maximum distance from the source, and T s is the temperature of the source. We set the thermal diffusivity as 2 . · − m / s as aconstant [32, 52].On the other hand, HVAC systems (e.g., heater and AC) influ-ence temperature with an air flow (due to convection) to ensurequick heat dissipation. In particular, air flow of these systems en-ables uniform temperature from their influences [27]. Therefore,we construct their flow functions through ordinary differentialequations [30]. 𝑑 T 𝑑 t = T Δ · q (4) T ( ) = T (5)In the equation, T is the initial temperature, T Δ is the impactfrom the HVAC system based on its power (positive for heater,negative for AC) and q denotes whether the system’s actuationcommand ( on or off ). Although these devices cause air flow in theroom in order to enable uniform temperature, the unauthorizeddevices still generate heat which diffuses to influence the sensormeasurements. Therefore, both diffusion and convection play acritical role in the temperature measurements. Relative Humidity.
The ratio of the existing water vapor in theair to the maximum capacity of water vapor that can exist in theair, is defined as relative humidity [39], detailed below. RH % = ww s ×
100 (6)In the formula, w represents the water vapor in the air, and w s represents the maximum capacity of water vapor the air can contain. w s exponentially depends on the ambient temperature, related to theClausius–Clapeyron equation [19]. Therefore, we leverage existingexperiments [58] to fit an exponential function to compute w s basedon temperature. In particular, this function is defined as: w s = . × 𝑒 . × T (7)where T represents the temperature of the environment in ° F .The actuation command automaton flow functions are imple-mented as ordinary differential equations that generate or reducewater content in the air. Smoke.
We consider an ionization-based smoke detector that de-tects the presence of smoke by filtering air through an ionizationchamber. When smoke particles enter through the chamber, conduc-tivity decreases and smoke presence is detected [11]. The thresholdof these sensors are in obscuration density per meter ( OD / m ), wherea typical sensor’s sensitivity is 0 . OD / m corresponding to 13 mg / m smoke density [11, 40]. Gas particles (such as the particles in smoke)move very fast through the air in room temperature [9]. Therefore,we define the flow function of actuation command automata as anordinary differential equation. Illuminance.
The influence of light is instant, and therefore, ismodeled with an algebraic equation. Its influence follows the in-verse square law, as shown below [59]. I x = I s × 𝜋 × x (8)In the formula, I s denotes the luminosity flux of the source.15 EST & MQ2 Smoke SensorsArduino UNOBMP183 Temp/Hum Sensor LM393 Sound Detection SensorSmartThings & PIR Motion Sensors Photoresistor Illuminance Sensor
Figure 2: Sensors installed in the house (See Figure 7).Sound.
Sound is modeled with an algebraic equation equation dueto its high speed of diffusion over air. Sound intensity is modeledwith the inverse square law [59]. Therefore, the sound pressure,which is the quantity the sensors measure, is represented with thefollowing formula. SP = SP + × log ( x x ) (9)Sound pressure SP at distance x can be calculated in decibels( dB ) with this formula, where SP is the sound pressure level atdistance x (the standard value of x is meter) [61]. When thedistance is doubled, SP decreases by 6 dB . Motion.
There are different types of motion sensors available onthe market. For instance, accelerometers detect motion based onthe acceleration generated by the source, PIR sensors detect motionbased on the infrared heat map of an environment, and laser-basedsensors detect motion by generating an invisible laser betweentwo devices and detecting the cut-offs. We consider PIR motionsensors, and model them through their range to detect motion. Ifthe actuators’ movement rate exceeds a threshold and the distanceis close enough, motion is detected.
Actuator configurations, distances to sensors they influence, andthe details of their influence are presented in Table 2.For sensors (presented in Figure 2), sensitivity values, and thresh-olds for detection (e.g., for sound, illuminance, smoke) are set asfollows: (i) temperature sensor - ± . F , (ii) humidity sensor - ± %,(iii) smoke sensor - 0 . OD / m ≈ mg / m , (iv) illum. sensor - lux,(v) sound sensor - 55 dB, and (vi) motion sensor - m. Table 2: Details of the actuators in the house.