TAPInspector: Safety and Liveness Verification of Concurrent Trigger-Action IoT Systems
11 TAPInspector: Safety and Liveness Verification ofConcurrent Trigger-Action IoT Systems
Yinbo Yu, Jiajia Liu
Abstract —Trigger-action programming (TAP) is a popular end-user programming framework that can simplify the Internetof Things (IoT) automation with simple trigger-action rules.However, it also introduces new security and safety threats. Alot of advanced techniques have been proposed to address thisproblem. Rigorously reasoning about the security of a TAP-based IoT system requires a well-defined model and verificationmethod both against rule semantics and physical-world states,e.g., concurrency , rule latency , and connection-based interactions ,which has been missing until now. This paper presents TAPIn-spector, a novel system to detect vulnerabilities in concurrentTAP-based IoT systems using model checking. It automaticallyextracts TAP rules from IoT apps, translates them into a hybridmodel with model slicing and state compression, and performsmodel checking with various safety and liveness properties.Our experiments corroborate that TAPInspector is effective: itidentifies 533 violations with 9 new types of violations from 1108real-world market IoT apps and is 60000 times faster than thebaseline without optimization at least. Index Terms —Trigger-action rule, concurrent model, rule la-tency, liveness property, model checking, Internet of Things.
I. I
NTRODUCTION
Enhanced by advanced technologies (e.g., 5G, artificialintelligence, and edging computing), the Internet of Things(IoT) is promise to change the way humans interact with tech-nology. New end-user programming frameworks also usherIoT provision into a new appified era, in which IoT servicesare programmable for users rather than hard-coded in propri-etary equipment. Such appified provision makes IoT closerto reality. Currently, trigger-action programming (TAP) is themost popular framework for IoT programming, which enablesusers with or without programming experience to expresstheir intent in automating IoT services [1]–[3]. TAP has beenwidely supported by many commercial IoT platforms, e.g.,Samsung SmartThings [4], IFTTT [5], OpenHab [6], MicrosoftAutomate [7], Apple HomeKit [8], Zapier [9], and etc.With TAP, IoT systems are controlled by event-driven apps,each of which is composed of one or a set of TAP rules .A TAP rule basically contains a trigger (an event or a statechange) and an action (a device command) in the form of “ IF that trigger occurs, THEN perform the action”. Additionally,a Boolean constraint on states (i.e., condition ) may also beinserted in rules to enable accurate contexts. An example ofTAP rules is “ IF the temperature drops below 10°C After
THEN turn on the heater”. Given a TAP rule, IoT systemwill automatically react following it without user involvement.
Y. Yu, and J. Liu are with the School of Cybersecurity, NorthwesternPolytechnical University, Xi’an, Shaanxi, 710072, P.R.China (e-mail: [email protected]; [email protected]).
TAP simplifies customization of IoT automation, especiallyfor novice users. But its limited expressivity makes users hardto construct large and intelligent automation [10], [11], forwhich users need to design a lot of rules and coordinate themto complete tasks. The complex physical world introduces alarge understanding space to users to express their intent inthe cyber world and results in security and safety risks due toflawed rules as well as rule interactions [2], [12].Recently, a lot of advanced techniques have been pro-posed to secure TAP-based IoT systems, including interactionthreats [2], [12]–[14], privacy leakage [15], [16], anomalydetection [17], [18],dynamic policy enforcement [19], andautomation generation [3], [20]. These techniques make greatcontributions to the security analysis of TAP rules by usingstatic analysis or formal methods. Most of them [12]–[14],[21] assume that rules are performed atomically in order andmodel the IoT system as a sequential model. We agree withthis assumption because many triggers do not share globalvariables and sequential models can provide a compact anal-ysis space. However, the IoT system is concurrent, in whichtriggers driven by the physical world can occur concurrentlyand thus multiple rules can be executed in parallel, even undera single hub [22]. Describing an IoT system with a sequentialmodel may result in high false positive or false negativerates in security analysis. Therefore, we further scrutinize thedeficiencies that need to be solved as follows:
Rule latency : A TAP rule’s action may not be executedimmediately when its trigger activates, due to delays definedin apps (e.g., runIn in SmartThings) or platform delays inevent handling [22]. Additionally, besides instantaneous and sustained actions which are completed in a one-time step,another type of action is extended in time (i.e., completed inseveral time steps), e.g., uploading video. These two factorsboth introduce latency in rule execution, i.e., rule latency .Modeling the concurrent IoT system as a sequential modelwithout rule latency can fail to inspect concurrent securityissues (e.g., data race) and even lead to erroneous analysis.
Rule interaction : There are physical channels which canchain TAP rules unexpectedly and underpin security issues [2],[13], [14]. Besides channels, we find there is another commonfactor that can cause rule interactions, e.g., wired connectionbetween an outlet and its powered actuators, wireless connec-tion between a ZigBee Hub and ZigBee sensors. We call it connection , which also exists both in cyber and physical. Acomprehensive analysis of rule interaction (provided in § IV-C)can ensure that our study will not miss potentially unsafeinteraction behaviors, e.g., sprinkler not working due to lossof sensitive smoke data. a r X i v : . [ c s . CR ] F e b Safety and liveness property : Security risks in TAP ruleshave been widely studied with various safety properties (i.e.,something bad should never happen). But a richer set ofproperties is left out, which depend on IoT systems guarantee-ing liveness (i.e., something good eventually happens). Theyare indispensable, especially for a concurrent system [23].While a safety property guarantees partial correctness , liveproperties correspond to total correctness , e.g., terminationwithout action looping or guaranteed device states. We arguethat verification both with safety and liveness properties offersa more natural way to inspect TAP rules. For instance, aproperty “the intrusion video is eventually uploaded to theCloud upon physical intrusion” contains liveness and implicitsafety, and can be used to check both the beginning andtermination of the extended action of “uploading video”.In this paper, through in-depth study of the gap betweenthe cyber and physical world, we propose a novel approachnamed TAPInspector to analyze security risks in TAP-basedIoT systems. To our best knowledge, TAPInspector is the firstwork that can address these above problems. It automaticallyextracts TAP rules from IoT apps, translates them into afinite state machine, and performs model checking with bothsafety and liveness properties. Our main contributions aresummarized as follows: • Analysis of TAP rules and Interaction Threats ( § II-III).We carefully analyze the process of TAP rule enforcementboth in the cyber and physical world. We point outthree essential features about physical attributes, extendedactions, and rule latency, which are ignored by existingliterature and need to be paid more attention to in securityanalysis of TAP rules. Based on these features, we define7 categorizations of rule interaction threats. • Automatic Modeling of IoT systems ( § IV). We for-mulize TAP-based IoT systems, respecting rule semanticswith rule latency and channel- and connection-basedrule interactions. Then, several modules are proposed toautomatically extract TAP rule semantics from apps ofdifferent IoT platforms through static code analysis andconstruct as formulated TAP rules. • Hybrid Transition Model with Optimization ( § V). Con-sidering the concurrency of IoT systems, we design ahybrid model rather than a sequential model. We firsttranslate TAP rules as a transition system in the con-current format and then slice it into a set of submodelsusing rule dependencies caused by rule interactions. Ineach submodel, rules that have dependencies are executedsequentially and that have no dependency are executedconcurrently. Finally, the state space of each submodel iscompressed for the efficiency of verification. • Evaluation ( § VI). We evaluate the performance of TAPIn-spector for accuracy of verification with a labeled IoT appbenchmark [24] and capability of vulnerability detection with a real-world market IoT app dataset (1108 apps)from multiple IoT platforms (SmartThings and IFTTT).TAPInspector identifies 9 new types of vulnerability(leading to totally 533 violations) from 1108 apps andsignificantly reduces the verification time from minute- level to millisecond-level.II. B
ACKGROUND AND M OTIVATION
A. Trigger-Action IoT Platform
To seek a rigorous security analysis of rule executions inIoT, we conduct an in-depth study of the cyber-physical gaparound three nonnegligible features as follows:
1) Attribute.
Introducing the TAP paradigm into IoTplatforms provides an intuitive abstraction of IoT servicesand devices. We use attribute to represent the basic abstractobject that services interact with devices, including state ofdevices and system state (e.g., locationMode ). Consideringphysical features, we make a distinction with two attributetypes:
Immediate , whose value can change in one time step,e.g., illuminance, and
Tardy , whose value takes a while tochange, e.g., temperature. Such distinction can improve theaccuracy of rule execution model.
2) Rule Semantic.
An IoT device can be a sensor , an actuator , or both. A sensor measures and reports external in-formation, e.g., a motion detector. An actuator executes devicecommands and manipulates corresponding attributes, e.g., aswitch. By abstracting devices, the IoT platform provides a setof abstract events , states , and commands for users to customizeTAP rules as follows: • Trigger : it can be defined by an event (an instantaneousinput signal, e.g., motion is detected) or a state change(a Boolean constraint on attributes becomes true, e.g., temperature > °C). • Condition : it is a Boolean constraint defined on one ormore states, and all of them must be evaluated to be truefor rule executions. • Action : two types of action ( instantaneous and sustained )are both completed within a one-time step and havebeed widely studied. While the former does not changeattributes, e.g., “send a notification”, the later changesattributes via actuators, e.g., “turn on the light”. Addition-ally, there is a third and common type of actions, which is extended in time [10]. We call them extended actions . Anextended action usually switches the state of a device into“doing something” (e.g., opening, brewing) and needs totake a while (varying from seconds to hours) to complete.Finally, the state of the device switches to its originalor another state. Examples of extended actions include“uploading videos” and “turn on fan for 15 minutes”.
3) Rule latency.
Given a TAP rule, existing literatureassumes that its action will be executed immediately whenits trigger and condition activates. However, that is not thetrue case. Rule execution may contain rule latency, whichcan come from two aspects: trigger-to-action (T2A) latency and delay in extended actions . T2A latency is the delay fromwhen the trigger occurs to when the action is executed, andcan be: (1) defined in IoT apps to postpone the executionof actions within a delay, e.g., runIn(delay, method) in SmartApps (actions in the method will be executed afterthe delay ), “after a quiet period” in IFTTT applets; or (2)introduced by platform delays in event handling, e.g., longintervals in IFTTT’s polling operations which are long (usually
B. Model Checking with Safety and Liveness Properties
Model checking is a method to determine if a systemsatisfies a given property. A system is usually modeled as a transition system . A property about the system is expressedin temporal logic formula [25], with which the model checkertraverses every possible matching paths of state transitions.Properties can be categorized into safety and liveness fora modelled system [23], [26]. Informally, safety stipulates“something bad should never happen” and liveness guarantees“something good eventually happens”. If the system cannotsatisfy a safety property, it implies some irremediable “some-thing bad” (i.e., an undesired state) must happen in a path ofstate transitions. A liveness property asserts that it is alwaysthe case that some desired state (e.g., termination, guaranteedservice) can be reached in the future, and ensures no partialpath is irremediable. Liveness verification has widely appliedin networks, e.g., stateful network functions [27], broadcastnetwork [28]. Generally, liveness properties can be expressedin two forms [23]: “event A leads-to event B” and “event A eventually happens”. Some example properties that guaranteeliveness in IoT systems include: 1) whenever the temperaturein a room is below 18°C, setting the heater to 28°C leads-to the temperature rising to 28°C; 2) the intrusion video iseventually uploaded to the Cloud upon physical intrusion.
C. Motivation
Although rule interactions can chain rules together to pro-vide more intelligent home automation, most users may forgetor even not realize them due to independent app developmentand the large understanding space of the physical world [3].Existing literature model TAP rules into a sequential model,which performs rules atomically in order. However, once weconsider concurrency, tardy attributes, extended actions, andrule latency, rule interactions may not act as described in thesequential model. Taking rules in Fig. 1 for example, r and r do not interact due to ordered executions, r and r interactthrough the temperature channel in the sequential model. Onceset in a concurrent model with rule latency, we can identifya violation between r and r that after the user comes andthen leaves within 10 minutes, the curling iron will be turnedon after the user leaves. Considering a rule r “if temperature > r and r in the concurrentmodel, a violation may occur that the heater cannot be turnedoff when the temperature is greater than 29°C. This is because r ’s outlet is incorrectly configured to the one powered theZigBee hub of the temperature sensor and after r is executed, r is activated before r due to tardy temperature and disablestemperature sensing. Thus, r will not be activated ever. Theseissues are due to the neglect of the differences between the PresentNot present
Turn curling iron on after 10 mins
Turn curling iron off 𝑟 ! 𝑟 " (a) Rule latency 𝑟 ! 𝑟 " (b) Physical channel Fig. 1: Rule interactions. cyber and physical world. Therefore, in this work, we aimto conduct security analysis of TAP rule execution in homeautomation via a more accurate model.III. O
VERVIEW
A. Scope
Our goal is to detect vulnerabilities which are caused bydesign flaws in TAP rule interactions and are exploited byattackers. Rule interaction vulnerabilities may be caused bymany reasons: (1) An adversary tricks a user into installingmalicious apps, which contains fake events or actions [2],[15]; (2) Non-rigorous app development leads to inconsisten-cies between app descriptions and code logic [12], [21]; (3)Complex IoT environments make users hard to perceive subtlerules interactions when installing or configuring rules [2], [13];(4) Unstable rule latency results in non-determinism, whichconsequently leads to concurrent issues, e.g., data race. Suchvulnerabilities can subvert users’ intent by turning the systeminto an insecure or unsafe state and enable attackers to launchattacks, e.g., privileged actions, proximity-based attacks, orsafety threats. Generating patches for repairing vulnerabilitiesis out of this work’s scope, but is left to future work.
B. Rule Interaction Threats
Before presenting our solution, we discuss and define ruleinteraction threats based on both existing efforts [2], [12],[14], [21] and our analysis, which are used to verify thecorrectness of IoT systems. Here, we first give the primarydefinition of a TAP rule: r := ( t, C t ) l (cid:55)→ ( C a , A ) , where t isthe trigger, A is the action set, C t and C a is the condition setof trigger and action, respectively, and the total condition setis C = C t ∪ C a . Between trigger and action, we introduce arule latency l ≥ . Detailed rule formulation is referred to § IV-A. Based on the formulation, we now define the followingthreats with a summary shown in Table I: T1 : Action-Trigger Interaction . It is a common threat [2],[13], [14], where r i and r j have nonexclusive condition set(i.e., Sibling ( C i , C j ) ) and a i triggers t j to be activated ( a i ⇒ t j ) directly or through a physical channel. If r i and r j triggereach other alternately, this threat can result in infinite actuationloop and violate liveness of termination . T2 : Action Duplication . In this threat, two rules have thesame trigger and mutually nonexclusive condition set denotedby
Sibling ( r i , r j ) , and both have an action with the samedevice, attribute, and value. Duplicated actions may be redun-dant (e.g., repeated messages) and even harmful (e.g., repeatedtransactions [2]). TABLE I: Rule Interaction Threats.
ID Threat Definition DescriptionT1
Action-Trigger In-teraction ∃ a i ∈ A i , a j ∈ A j , s.t. Sibling ( C i , C j ) ∧ a i ⇒ t j † r i can activate r j directly or through phys-ical channel. T2 Action Duplication ∃ a i ∈ A i , a j ∈ A j , s.t. Sibling ( r i , r j ) ∧ a i = a j r i and r j are activated simultaneouslywith repeated actions. T3 Action Conflict ∃ a i ∈ A i , a j ∈ A j , s.t. Sibling ( r i , r j ) ∧ l i = l j ∧ a i = ¬ a j * r i and r j are activated simultaneouslywith conflicting actions. T4 Action Overriding ∃ a i ∈ A i , a j ∈ A j , s.t. Sibling ( C i , C j ) ∧ l i (cid:54) = l j ∧ a i = ¬ a j r j overrides the effect of r i . T5 Action Breaking ∃ a i ∈ A i , a j ∈ A j , s.t. a i l e → a (cid:48) i ∧ a j ⇒ Stop ( a i ) r j breaks the action in progress of r i . T6 Condition Blocking ∃ c i ∈ C ai , a j ∈ A j , s.t. a j ⇒ ¬ c i r j blocks the condition of r i . T7 Device Disabling ∃ a i ∈ A i , s.t. V ( a i ) = off ∧ D ( a i ) ← (cid:45) D ( r j ) r j disables the execution of r i † Sibling ( C i , C j ) means two condition set are not mutually exclusive. * Sibling ( r i , r j ) means two rules have the same trigger and mutually nonexclusive condition set. T3 : Action Conflict . This threat is similar to T2 , but inwhich two rules have actions conflicting with each other( a i = ¬ a j , i.e., they work on the same device and attribute buthave different values). With the same rule latency, this threatcan potentially cause the system to enter into a unstable orunknown state. T4 : Action Overriding . This threat also has conflictingactions, but requires different rule latency and does not needthe same trigger, even has exclusive triggers. It can lead to theeffect of a i to be valid in a short time and then overrode bya different a j . T5 : Action Breaking . It mainly occurs in the extendedactions. We use the notation a ei l e → a e (cid:48) i to represent theexecution of an extended action a ei , i.e., once a ei starts, thecorresponding device will stay on a state for a period l e andthen switches to another state via a e (cid:48) i . During this period,another rule r j may be activated and has an action a j thatcan stop the progress of a i , i.e., Stop ( a i ) . T6 : Condition Blocking . This threat occurs between actionand condition. We define it as: rule r i has the action a i that candirectly or indirectly (through a physical channel) cause thecondition c j of rule r j not be satisfied (denoted by a i ⇒ ¬ c j ).This threat may cause that security actions cannot be activated,e.g., alarm does not work when fire. T7 : Device Disabling . It is a threat caused by incorrectdevice connections: if the parent device is closed by a rule r j (i.e., the value V ( a i ) is to turn the device off), the connecteddevice is also powered off and any rule r i depending on thedevice (i.e., D ( a i ) ← (cid:45) D ( r j ) ) is then disabled. This threat canresult in disabled secure actions or loss of sensitive data. C. System Overview
To identify these threats, we present an overview of oursolution, TAPInspector, a framework for automatically mod-eling and verifying the correctness of concurrent TAP-basedIoT systems. Fig. 2 depicts the workflow of TAPInspector:it crawls source codes of IoT apps and corresponding userpreferences from IoT platform websites, translates them withour defined rule interaction models into a finite state machine(FSM), and finally performs model checking with safety andliveness properties. These properties include both functionaland security requirements desired by users or developers.TAPInspector mainly contains two components:
IoT APPIoT APPIoT APPIoT App
Sourcecodes
UserpreferencesRule interaction models
ICFG
Properties
Vulnerabilities
AST
ICFG constructionRule constructionModel construction Slicing & CompressionIoT platform websitecrawler Model checking
Fig. 2: The framework of TAPInspector.
Rule Extraction ( § IV) . It contains two modules:
ICFGconstruction and rule construction . This component first ex-tracts inter-control flow graphs (ICFG) of IoT apps, in eachof which the entry node is an event handler of a trigger,and the condition and actions of TAP rules are coded inits paths. Then, by associating ICFG with device attributesand commands, it formulates ICFGs into latency-sensitiveTAP rules. Finally, it uses rule interaction models to establishdependency relationships between rules.
Rule Modeling & Verification ( § V) . It is responsiblefor model construction, optimization, and verification. It firsttranslates formal TAP rules into an FSM model. To avoid alarge state space, it slices the model into a set of independentsub-models using dependency relationships and compressesthe size of model variables into a small range space. Finally,we define various properties to perform model checking onoptimized models for inspecting vulnerabilities.IV. T RIGGER -C ONDITION -A CTION R ULE
A. TAP Rule Formulation
Basically, a TAP rule r is formulated as follows: r := ( t, C ) (cid:55)→ ( A ) , (1)where t is a trigger, C is a condition set, and A is anaction set. Each component can be described by a triple (cid:104) Subject, Expressions (cid:105) as follows:
Subject Expressions t := caps ( A s ) : ¬ A c := caps ( A s ) : ( A (cid:54) = A ) ∧ ( A > a := caps ( A s ) : A := V . A subject S can be a cyber attribute A env , e.g., time,or a device D which is described by a set of capabil-ities C s , each of which C is then described by a setof attributes A s , e.g., a temperature sensor has a capabil-ity temperatureMeasurement which has an attribute temperature . For a trigger or condition, the Expression is a predicate expression (denoted by P ) describing constraintsto A s and their compounds, which represents an instant event(e.g., door ring) or a sustained state (e.g., after 5 p.m.). Foran action, the Expression is an assignment (denoted by
Assign ) statement to an attribute A with a value V , whichrepresents the command that needs the actuator to execute.To be aware of rule latency l ≥ , we reformulate (1) to be latency-sensitive as follows: r := ( t, C t ) l (cid:55)→ ( C a , A ) , (2)where we divide the condition set C into two sets: C t whichis checked when the trigger occurs and C a which is checkedbefore executing actions. For simplicity, we introduce a timer τ r and divide the original r containing T2A latency into twosub-rules: r := ( t, C t ) (cid:55)→ ( ∅ , τ r := l ) , (3) r := ( τ r = 0 , ∅ ) (cid:55)→ ( C a , A ) . (4) r is equipped with an action to setup a timer τ r with a timeoutvalue l . Once τ r times out, r performs actions of r . We call r a timeout rule. Similarly, we also use a timer τ e and splitthe rule r containing an extended action a e into two sub-rules: r := ( t, C t ) (cid:55)→ ( C a , { a e , τ e := l } ) , (5) r := ( τ e = 0 , ∅ ) (cid:55)→ ( ∅ , a e (cid:48) ) , (6)where, we use a e (cid:48) to denote switching to another state. B. Rule Extraction
The coding form of TAP rules varies from platform toplatform. In this work, we mainly focus on SmartThings andIFTTT, two popular IoT platforms that have been widelystudied in the exist literature. We first extract inter-proceduralcontrol flow graphs (ICFGs) from IoT apps and then translateICFGs to TAP rules as defined in the above subsection.
ICFG Construction . SmartApps are coded in Groovy lan-guage and usually contain multiple rules with extensive logic.To extract ICFGs from a SmartApp, we implement an
ASTvisitor built on Groovy compiler which allows to insertextra code passes via compiler hooks. Then, TAPInspectortraverses AST nodes at the compiler’s semantic analysis phaseand performs the path-sensitive analysis [29] to extract intra-control flow graph (CFG) of each method and inter-call graph among different methods. According to different entrymethods, we classify ICFGs in two types: one is used for appinitialization and schedule , which can initialize variables bothof cyber states and device attributes, subscribe event handlersvia the subscribe method, and setup system schedulesvia API methods, e.g., runIn or schedule ; the othertype is used for event handling declared via subscribe ,which contains most TAP rules defined in a SmartApp. Tobuild accurate ICFGs, we need to deal with closed-sourceSmartThings’s API methods, which are used both for methodinvocations and object property access. Similar to [12], we re-view the SmartThings API documentation [30] to model theseAPIs manually. For example, runIn(delay, method) is an API that delays the invocation of method within aspecified delay . Hence, in the ICFG, we associate the CFGof method with the CFG where runIn locates in.IFTTT applets provision rules via REST services [5]. Eachapplet contains only one TAP rule. From the IFTTT website,we crawl information about rule title, rule description, triggertitle, trigger channel, action title, and action channel of anapplet. Similar to [14], [19], TAPInspector performs stringanalysis on this information. First, it maps all trigger andaction titles into corresponding triggers and actions. Afterparsing the rule, trigger, and action title of each applet, itconstructs a two-node ICFG in which the entry node is thetrigger, and the other node is the action. IFTTT applets usefilter codes as conditions, which, however, are not publiclyvisible due to privacy concerns. But we find that some ruledescriptions contain a simple condition, like “If the door openafter 8pm, notify me”. We combine these simple conditionsinto the entry node of their ICFGs. Rule Construction . Given an ICFG, we first need informa-tion about device capabilities and user preferences to formu-late it as TAP rules. A device capability describes attributesof a device and related command methods used in apps. Weextract them provided by SmartThings [31] and reformulatethem in JSON format. Each file defines the capability ofa device, including a set of attributes (each contains name,type (Boolean, Integer, or Enumerated), and a value list)and a set of command methods (each contains name andarguments). SmartThings’ device capabilities have coveredmost of devices used in IFTTT. For undefined devices, wemanually construct them. Furthermore, SmartThings devicecapabilities do not distinguish extended action and others.Hence, we manually list a set of extended actions with compactdelays. User preferences are user declarations for constantsused in constraints (e.g., temperature threshold, T2A latency).User preferences are private and thus usually not included insource codes. To obtain them, we provide a crawler basedon
Selenium [32] to users, with which a user can use herusername and password of SmartThings to ask the crawlerto extract her preferences for installed SmartApps from theplatform website [33].With the above information, we extract valid execution pathsfrom an ICFG and translate into formulated TAP rules asfollows: for paths in app initialization , we set t and C emptyand formulate all direct or indirect (through device commands)variable-value assignment statements as the action set A ; for a path in app schedule , we set up an empty rule with the actionof setting up a timer of schedule delay and a timeout rulewith actions A ; and for a path in event handling , we extract thesubject declared in subscribe and its associated constraintsas the trigger predicate t , combine other logic conditions inthe path into the condition set C , and translate commands inthe path into A . If there is a rule latency l , we reformulate therule as two subrules with a timer. C. Rule Interaction Model
As we analyze in § III-B, rule interactions may occur un-expectedly and result security risks. Existing literature haswidely studied that channel-based interactions are the mainreasons causing unexpected rule interactions. Besides, we alsofind another reason, called connection . We now formulate ruleinteraction models as follows:
Channel : it can be a physical or cyber one. A physicalchannel refers to a shared environment attribute A c (e.g.,temperature) among actions and triggers. Through the channel,actions can change its attribute (“turn on the heater”) and trig-gers can be activated (e.g., “when the temperature rises above28°C, open the window”). Similarly, there also exist cyberchannels , but their attributes are virtually defined by apps,e.g., locationMode, vacationState . Considering the differencebetween an immediate channel attribute and a tardy one,we define the channel-based interaction model of a channelattribute A ch as follows: A ch : a i ( A ch ) l ch ← (cid:45) t j ( A ch ) or c j ( A ch ) , (7)where ← (cid:45) means a dependency relation, i.e., t j or c j containing A ch can be changed by a i ; l ch is the delay from when a i startsto when the value of A ch activates t j or c j ; Connection : it works on among subjects and also hastwo types: physical and cyber. A physical connection meansthat two devices are connected, e.g., a smart plug and aconnected heater, a Zigbee hub and a Zigbee sensor. A cyberconnection means the dependency between two subrules ofa rule containing latency. Misconfigurations of connectionscan lead to loss of safety-sensitive data or disabling securitydevices. For instance, there is a rule “when high voltage usageis detected, turn off the outlet”. A user wants to activate it onan outlet connecting a heater for saving energy, but carelesslyon the one connecting a water valve. If the rule is activated dueto electric leakage and there is fire, the sprinkler opened byother rules cannot be valid since the valve cannot be opened.Formally, we define a connection as follows: S cop → S coc : a i ( S cop ) ← (cid:45) r j ( S coc ) , (8)which means the validity of rules using the child subject S coc depends on states of the parent subject S cop .We construct these interaction models as follows: Sincecyber channels are defined in apps, we identify them bycomparing all rules having operations defined in (7); Physicalchannels we used are found by existing literature [13], butwe redefine tardy channels (temperature and humidity) withlatency and keep immediate channels (illuminance, voltage, water, motion, and presence) without latency; We define ourfound connections having parent devices, including smartplug/outlet, ZigBee hub, Wi-Fi gateway, and Bluetooth hub.Child subjects are configured in different automation sce-narios. With both channel- and connection-based interactionmodels, TAPInspector establishes dependency relationshipsbetween rules in the next section.V. R ULE M ODELING AND V ERIFICATION
A. Model Construction
Given a set R of formulated TAP rules, we translate theminto a finite state machine (FSM) M := { S, Σ , I } , where S isa finite non-empty set of states, Σ ⊆ S × S is a state-transitionfunction, and I ⊆ S is a set of initial states. I is definedby initialization assignments in those rules declared in ICFGsfor app initialization and schedule. A state s ≡ A s := V s represents the attribute set A s of all installed subjects havingvalue V s . For other rules in R , we translate each rule r i as astate-transition function σ ( s, s (cid:48) ) ∈ Σ in M as follows: s (cid:48) = (cid:26) Assign i ( s ) if P ri ( s ) ∧ P ci ( s ) and Φ P i ( s ) (cid:54) = Φ P i ( s (cid:48)(cid:48) ) s otherwise . (9)If the current state s can make the predicate of trigger andcondition of rule r i satisfy ( P ri ( s ) ∧ P ci ( s ) = True), the modelperforms assignments (
Assign i ) of r i ’s actions on s ; if not, s keeps no change. For a FSM, if P ri ( s ) ∧ P ci ( s ) is alwaystrue in every step, Assign i will be executed repeatedly,which violates real rule executions. Therefore, we introduce anauxiliary variable φ ∈ Φ for each attribute to record its valuein the last state s (cid:48)(cid:48) and add a new constraint Φ P i ( s ) (cid:54) = Φ P i ( s (cid:48)(cid:48) ) into the predicate. With this constraint, the model performs Assign i only when P ri ( s ) ∧ P ci ( s ) becomes true. B. Model Slicing and State Compression
By setting attributes of triggers to be non-deterministic, thestate of an FSM can activate several transitions simultaneously.This describes the concurrency of IoT systems, but can alsoresult in a huge state space. As the number of attributes grows,the state space will grow exponentially, even explode, andresult in a very long verification time. To address this problem,we propose two optimization approaches: model slicing andstate compression. The former can slice the model into a set ofhybrid models, each of which has several groups executed inorder and rules in each group are executed concurrently. Thelater compresses the range of variables to reduce redundantstate space. Such a hybrid model can ensure both compactstate space and model concurrency.
Model Slicing . Given channel- (7) and connection-based (8)interaction models, we define a dependency relation d betweentwo rules (i.e., transitions σ ) r i and r j in an FSM as follows: d ≡ Assign i ← (cid:45) P j , (10)i.e., a predicate P j of r j depends on an assignment Assign i in r i . Given a dependency d , TAPInspector inserts it into theFSM. For a channel-based dependency d c , TAPInspector first Algorithm 1:
Dependency-based Model Slicing
Input:
An FSM model M with a rule set R ; Dependencyrelationships D Collect all attributes A s operated by all actions of R ; Empty expression dependency edge set E e ; for A i , A j ∈ A s and A i (cid:54) = A j do Collect rule lists R ( A j ) ⊆ R ; for r ∈ R ( A j ) do if A i ← (cid:45) P ∈ r then add an edge (cid:104) A i , P (cid:105) into E e ; Empty rule dependency edge set E r ; for e ∈ E e do Collect rule lists R ( e. A ) ⊆ R ; for r ∈ R and ∃ P ∈ r, P ∈ e do Add edges (cid:104) r s , r (cid:105) into E r , ∀ r s ∈ R ( e. A ) ; Empty model slicer set S ; for (cid:104) r s , r t (cid:105) ∈ E r do if S is empty or ∀ s ∈ S, r s (cid:42) s then Move r s and r t from R to a new slicer s in S ; for (cid:104) r (cid:48) s , r (cid:48) t (cid:105) ∈ E r do if r (cid:48) s ⊆ s and r (cid:48) t (cid:42) s then Move r (cid:48) t from R to the slicer s ; Extract set E (cid:48) in E r whose source is r (cid:48) t ; for r (cid:48)(cid:48) t ∈ E (cid:48) and r (cid:48)(cid:48) t (cid:42) s do Move r (cid:48)(cid:48) t from R to the slicer s ; GoTo line 20 with r (cid:48)(cid:48) t ; else if r (cid:48) t ⊆ s then Move r (cid:48) s from R to the slicer s ; Add remained rules in R as a single slicer into S ; Output: a set of FSM model S adds the channel attribute A c as a variable in the FSM, andthen traverses all transitions in Σ : If a transition r has anaction a that can change A c (i.e., r.a → A c ) and A c is atardy attribute, A c should be changed within several steps,rather than in one step. Thus, TAPInspector adds a new rule r.a l c (cid:55)→ a c , in which we use r.a to represent a trigger when r.a is executed, set a latency l c defined by d c , and an action a c tochange A c ; If A c is an immediate attribute, we directly add theaction a c into the action set of r ; If the trigger or condition of r depends on A c , we build a rule dependency to those havingactions on A c . For a connection d co , since we did not checkhow different platforms handle the situation that a device isoffline, we propose two settings: the platform (1) disablesrules associated with offline devices; or (2) uses sensing datafrom their last measurement. If there is a transition r having asubject connected to S cop of d co : for setting (1), TAPInspectorinserts a constraint S cop = on (i.e., S cop is in the state of on )into condition set of r ; for setting (2), TAPInspector insertsthis constraint into the transition of obtaining sensing data.After enhancing the model, TAPInspector performs modelslicing with Algorithm 1 in three stages: (1) building ex-pression dependency edges : TAPInspector collects all usedattributes and figures out the expression dependency set E e (Line 2-7). An expression dependency means that for twoattributes A i and A j , a rule uses A j and also has a constraint P depending on A i ; (2) building rule dependency edges : TAPInspector traverses the expression dependency set E e toconstruct rule dependency edge set E r (Line 9-12). A ruledependency edge means if a rule r uses the source attribute e. A of an expression dependency e ∈ E e and contains a sink P in e , all rules r s using e. A have the rule dependency on r ;(3) slicing model : TAPInspector performs forward traversal onthe model using E r to slice the model M into a set of FSMmodel (i.e., slicers) S (Line 13-26). If for two rule dependency e and e (cid:48) , a slicer s contains e and r (cid:48) s ∈ e (cid:48) without r (cid:48) t ∈ e (cid:48) ,TAPInspector performs forward traversal of the model alongwith sink rules of r (cid:48) t . If r (cid:48) t is contained in s , TAPInspectoradds r (cid:48) s into s . Finally, TAPInspector adds remained rules asa single slicer into S and outputs a set of hybrid FSMs. State Compression . There are many integer variables rep-resenting attributes in the IoT system, such as time andilluminance. They may have a huge range, e.g., the indoorilluminance can be 0 to 2000 lx , which can lead to a largeand redundant state space for model checking. Hence, weoptimize these variables as integers within a compact range inthe FSM to avoid state explosion. Specifically, given an FSM,TAPInspector lists all used values of an integer variable, mapsthem into a small integer range, and re-declares the variablewith this range. For instance, we use time points involved in allrules to form a range for the cyber time, rather than increasethe time as a continuous counter in each transition.While compressed variables are meaningful for immediateattributes, it can raise new issues for tardy attributes, especiallywith concurrent events. For example, there are three rules: r (“after 8pm, turn on the thermostat to 28°C”), r (“If thetemperature rises above 25°C, turn off the thermostat”), and r (“If the temperature rises above 27°C, open the window”). Ifwe simply compress the temperature as an integer in the rangeof [0,3] and set it directly change to 3 (28°C) from 0 in a fewtransitions after r is executed, r and r will be executedsimultaneously, which violates the fact. Hence, after listingall involved values of a tardy attribute, we add transitions ofvalue changes to cover all of them, e.g., 1 (25°C) and 2 (27°C). C. Model Checking
Given an FSM of IoT systems, TAPInspector uses NuSMV[34], a mature symbolic model checker, to verify its correct-ness with a set of security properties. To check rules withinteraction threats in Table I, TAPInspector first compares eachrule action with all components of another rule to check forinteraction threats. Once a threat is identified, TAPInspectorgenerates a safety or liveness property according to its formulashown in Table II by filling corresponding elements, andvalidates the threat via model checking. For instance, an actionbreaking threat ( T5 ) is found by rule comparison in two rules“When the user arrives at home ( t ), brew coffee ( a )” and“When sunset ( t ), close the outlet a ”, in which the coffeemaker is powered by the outlet. Then, TAPInspector generatesa liveness property “ a leads-to finishing brewing coffee ( a (cid:48) )”for model checking. Finally, a violation is confirmed that theuser arrives at home a short time before sunset, the coffeecannot be finished.Besides on these rule interaction threats, we further designa set of specific safety and liveness properties, which are TABLE II: Examples of safety and liveness properties.
Property Description T1 * a i leads-to a j via a tardy channel attribute2) When a i is executed, a j should be executed via aimmediate channel attribute T2 N/A since two rules have the same semantics T3 When t i and C i is activated, a i should be executed T4
1) When t i is activated, a j should not be executed2) t i and C i leads to a i T5 a i leads-to a (cid:48) i
2) before l e times out, a (cid:48) i should not be executed T6 When t i is activated, a i should be executed T7 If V ( a i ) = off , a j can executeS.1 When no one is present, the curling iron should never beturned onS.2 When smoke is detected, the valve should never be closedS.3 When motion is detected, the siren should be activatedS.4 When temperature is below a predefined value † and no oneis present, the heater should never be turned onS.5 When no one is present, locationMode should be AwayL.1 The camera video is eventually uploaded to the Cloud afterstarting to uploadL.2 Turning on AC leads to temperature drawing within apredefined range † L.3 The presence of users leads to humidity keeping with in apredefined range † L.4 After oven starts, it will eventually be done cookingL.5 After 10 pm, the light will eventually be turned off * While properties of
T3-7 are used to find conforming counterexamples, theproperties of T1 are used to detect the absence of T1 . † TAPInspector fills them according to user preferences or randomly. expressed through
Linear Temporal Logic (LTL) or
ComputingTree Logic (CTL) [25]. For safety properties, we defineundesirable behaviors used in prior works [3], [14], [21], [35].In this work, we further define a set of liveness properties.Note that some liveness properties are not practical, e.g.,“after user leaves, the door is eventually closed”, which allowsopening door for a long time to be correct. We carefully designseveral practical liveness properties, especially for terminationof extended actions and guaranteed device states. Table II givessome examples of safety and liveness properties we defined formodel checking. In total, we consider 67 properties, including37 safety, 21 liveness, and 9 general for rule interactionthreats. These properties all can be specified by users for theirconcerned devices or attributes.VI. E
VALUATION
In this section, we present our evaluations of TAPInspector.We implement a prototype system of TAPInspector in Javawith over 9K lines of code, including three parts: (1)
ICFGExtraction , (2)
Rule Construction , and (3)
Model Constructionand Optimization . With this system, we perform evaluationsfrom three aspects: accuracy validation, vulnerability detec-tion, and performance evaluation. All of them are conducted ona desktop with 3GHz Intel Core i7-9700 and 16GB memory.Our evaluations are conducted with several public datasets.First, to validate the accuracy of TAPInspector, we use abenchmark, IoTMAL [24], which provides flawed SmartAppsthat contain property violations in an individual app or multi-app environments [36]. Besides, for vulnerability detection, wegather 1108 market smart home apps from two sources: (1)we obtain 71 SmartApps in SmartThings public repository [37]after removing these apps using HTTP requests; (2) we use the IFTTT dataset used in [22], in which IFTTT applets are codedin JSON format. We obtain 1037 applets by checking if itselements can be both defined by device capabilities providedin [31].
A. Accuracy Validation
To validate the accuracy of TAPInspector, we perform afair and effective comparison with the state-of-the-art on theIoTMAL benchmark, which has been used as ground truthof violation detection in several literature [14], [21], [36].However, we find that most of existing approaches [12], [12],[13], [15], [19], [19] are not open-source, excluding IoTSAN[21] and I OT C OM [14]. Hence, we only focus on SOTERIA[36], IoTSAN, and I OT C OM , whose paper or technical report[35] provides the results of inspecting apps in IoTMAL. Ad-ditionally, IoTMal does not provide violations about concur-rency, rule latency, physical channel, and device connection.I OT C OM provides three new app groups containing physical-channel-related violations. Similarly, we also develop severalnew individual apps and app groups with designed violationsrelated to concurrency, rule latency, and device connection.We summarize the results of accuracy validation with safetyand liveness properties via TAPInspector and other approachesin Table III. TAPInspector identifies all known violations in 9individual apps ( ID 1-9 ) and 6 app groups (
Group 1-3 and
Group 4-6 are defined by IoTMAL and I OT C OM , respec-tively). ID 5.1 can generate a fake event using a string-basedmethod invocation by reflection. We fine-tune TAPInspectorto support such method invocation to improve the accuracyof ICFG construction. Thus, TAPInspector can successfullyidentify this fake event leading to turning off the alarm whenthere is smoke. While
Group 1-3 contain violations causedby rule interactions through cyber channels,
Group 4-6 defineviolations through physical-channel-based interactions.Besides, TAPInspector also identify violations about con-currency, rule latency, or device connections from our newdefined apps (
N 1-3 and
Group N 4-5 ). N 1 contains two rulesshown in Fig. 1(a). We check
N 1 with a property: “the curlingiron should never be turned off when no one is present”.
N 2 contains two concurrent rules on the same device, butwith different latency.
N 3 contains an extended action and atime-related event that can stop the extended action.
Group N4 contains several apps interacted with a device connection.Apps in
Group N 5 involve both rule latency and physicalchannels. For these apps, SOTERIA, IoTSAN, and I OT C OM identified no or incorrect violations. For instance, N 2 unlocksor locks the door depending on the user’s presence. IoTSANand I OT C OM expose that there is an action conflict in N 2 .But in fact, with different T2A latency, the two actions aredesired to be executed sequentially. By considering varyingrule latency, TAPInspector can identified the violation of N2 that the door is unlocked after the user is not present.In summary, TAPInspector achieves 100% accuracy for thisbenchmark. B. Vulnerability Detection in Market apps
We further evaluate TAPInspector’s ability to detect vul-nerabilities with market IoT apps. We randomly divide 1108
TABLE III: Accuracy comparison of violation detection betweenSOTERIA [35], IoTSAN [21], I OT C OM [14], and TAPInspector. Weuse (cid:26) , ○␣ , and Œ to denote true positive, false negative, and falsepositive, respectively.Test cases SOTERIA IoTSAN I OT C OM TAPInspector
Individual App
ID 1 (cid:26) (cid:26) (cid:26) (cid:26)
ID 2
Œ ○␣ (cid:26) (cid:26)
ID 3 (cid:26) ○␣ (cid:26) (cid:26)
ID 4 (cid:26)○␣ ○␣ (cid:26) (cid:26) ID 5.1 ○␣ ○␣ ○␣ (cid:26)
ID 6 (cid:26) (cid:26) (cid:26) (cid:26)
ID 7 (cid:26) ○␣ (cid:26) (cid:26)
ID 8 (cid:26) (cid:26) (cid:26) (cid:26)
ID 9
Œ ○␣ (cid:26) (cid:26)
N 1 * ○␣ ○␣ ○␣ (cid:26) N 2 * ‡ ○␣ Œ (cid:63) Œ (cid:63) (cid:26) N 3 * ‡ ○␣ ○␣ ○␣ (cid:26) App Group
Group 1 (cid:26) (cid:26) (cid:26) (cid:26)
Group 2 (cid:26) ○␣ (cid:26) (cid:26)
Group 3 (cid:26) ○␣ (cid:26) (cid:26)
Group 4 ○␣ ○␣ (cid:26) (cid:26)
Group 5 ○␣ ○␣ (cid:26) (cid:26)
Group 6 ○␣ ○␣ (cid:26) (cid:26)
Group N4 † ○␣ ○␣ ○␣ (cid:26) Group N5 * † ○␣ ○␣ Œ (cid:63) (cid:26) ID 4 contains two violations: repeated actions and conflicting actions.SOTERIA can identify only repeated actions, while I OT C OM and TAP-Inspector can identify both. * Benchmarks involving rule latency related violations. ‡ Benchmarks involving concurrency related violations. † Benchmarks involving channel or connection related violations. (cid:63)
Incorrect action conflict violation. market apps into a set of groups. Each group contains 2-6 SmartThings apps and 4-10 IFTTT applets. Besides thesegroups, we also extract app groups associated with safety-sensitive device groups derived from [21], e.g., heater, doorlocker, door controller, smoke detector, motivation sensor,alram, oven, and etc. To configure deployed devices foreach group, we assume a smart home environment contain-ing only one for most devices, but two temperature sensors( insideTemp and outsideTemp ), two luminance sensors( insideLum and outsideLum ), and two lights (one inliving room and another in bedroom). For these subject namesin apps without explicit meanings (e.g., “myswitch1”), werandomly map them to these devices with the correspondingcapability (e.g., light or outlet). We also pick up some outletsand safety-sensitive devices to set up physical connections .These outlets or devices are controlled by different rules.To configure preferences (including user preferences andlatency in extended actions and tardy attributes) used in apps,we come up with a random but reasonable range for eachconstant based on common sense regarding how we use theapps. T2A latency has two possible sources: user preferencesand platform delay. We configure preference-based latencywith a random value up to 20 minutes or the fixed valuedefined in apps. We do not directly insert platform delays inall rules and just randomly select a small part of them to insertlatency. Based on this evaluation environment, TAPInspectortotally identifies 533 violations from 1108 apps. We class them into six major categorizations (V-I to V-VI), and thedistribution of violations is shown in Fig. 3(a). From violationsin category
V-II to V-VI , we find totally ( F1-F9 ), which are all confirmed on theSmartThings platform and a third platform, Mi Home.
V-I : Action Duplication & Action Conflicts . We set vio-lations of these two threats into a single category since wedo not find new forms of violations from them. To findviolations about these two threats, TAPInspector first comparesformulated TAP rules and then confirms with model checking.TAPInspector finnally pinpoints 136 violations of action du-plication and 52 violations of action conflict, respectively. Wefind that these violations found in the rule comparison step arefeasible in model check. This is because in these two threats,rules have similar semantics and TAPInspector can compareall predicates accurately between two rules. The main rootcause of this category of violation we believe is independentapplication development. F1 ( V-II ): Action-Trigger Interaction . This vulnerabilityis detected similar to
V-I . But we find there are spuriousviolations in the first step. The reason is that we distinguishchannel attributes in two types: immediate and tardy, and a fewaction-trigger threats associated with tardy channel attributesare not invalid. An example in found violations is that there aretwo rules: r i (“if temperature drops below 10°C, turn heateron” from SmartApp its-too-cold ) and r j (“if temperaturerises above 28°C, open window” from an IFTTT applet).The action a i (“turn heater on”) can cause the temperatureto rise and thus can activate r j to open the window. Butonce the model includes a third rule r k (“if temperature risesabove 20°C, turn the heater off” from an IFTTT applet), thisviolation cannot be found again. This is because TAPInspectormodels the temperature as a tardy attribute which changessmoothly and thus, t k is activated before t j , which makes t j not be activated ever. Since we set a random range foreach preference, through multiple detections, TAPInspectoralso detects another vulnerability among these three rules thatif the temperature threshold of t k is greater than t j , the windowwill be opened first and the heater will not be turned off sincethe outside temperature is below 10°C. We summarize thistype of vulnerability in Fig. 3(b), in which a i can activatetwo rules through a physical channel and the two rules haveconflicting actions and different trigger preference on the tardychannel attribute. Finally, TAPInspector reports valid action-trigger violations (totally 67) with concrete preferences. V-III : Action Overriding . It is much similar to actionconflicts, but has different T2A latency. With 17 safety and13 liveness properties (12 are generated according to theproperties designed for T4 in Table II), TAPInspector identifies81 violations associated with action overriding, in which 52violations come from action conflicts but inserted with randomT2A latency. From these violations, we found two types ofvulnerability as follows: • F2 ( V-III-A ). As shown in Fig. 3 (c), this vulnerabilityoccurs between two rules with the same trigger, butconflicting actions and different T2A latency. These tworules are meaningful for action scheduling. It is similar toan extended action that activates the device’s state via a i 8 + 8 + + 8 + + + 8 + 8 8 8 8 8 + 8 K Q N C V K Q P U 0 G Y 8 W N P G T C D K N K V [ (a) Number of violations found in1108 market IoT apps. 𝑎 ! t ! t " 𝑎 " 𝑡 𝑟 ! 𝑟 " t 𝑎 Tardy attribute (b) F1 ( V-II ): Action-trigger. 𝑐 ! 𝑎 ! t ! 𝑐 " t " 𝑎 " 𝑙 ! 𝑙 " 𝑎 " 𝑡 𝑟 ! 𝑟 " (c) F2 ( V-III-A ): Disordered ac-tion scheduling. 𝑐 ! 𝑎 ! t ! 𝑐 " t " 𝑎 " 𝑙 ! 𝑙 " 𝑡 𝑟 ! 𝑟 " 𝑎 " (d) F3 ( V-III-B ): Action overriding. 𝑎 ! t ! 𝑎 !" 𝑎 t 𝑡 𝑟 ! 𝑟 " extended (e) F4 ( V-IV ): Action breaking. 𝑎 ! t ! t " 𝑎 " 𝑙 " 𝑐 " 𝑡 𝑟 ! 𝑟 " 𝑐 ! BA (f) F5 & F6 ( V-V-A & B ): Condition dy-namic blocking. 𝑎 ! 𝑐 ! t " 𝑎 " 𝑙 " 𝑡 𝑟 ! 𝑟 " ∆ 𝑐 " D C (g) F7 & F8 ( V-V-C & D ): Scheduled condi-tion blocking. 𝑎 ! t ! 𝑐 ! t " 𝑎 " 𝑟 ! 𝑟 " 𝑡 𝔻 " 𝔻 ! (h) F9 ( V-VI ): Device disabling.
Fig. 3: The results of violation detection. We use dashed red arrows toindicate state blocking, grean arrows to indicate that two constraintswork on the same attribute (dotted line) or are equivalent (dashedline), dashed orange arrows to indicate condition enabling, and dottedred arrows to indicate rule disabling. in a quiet period and then reverts back via a j . However,we observe that misconfigurations of T2A latency orplatform delays can disorder such scheduling and leadto violations. We call it disordered action scheduling .An example is that in two IFTTT applets: r (“Whenmotion is detected, turn on the light”) and r (“Whenmotion is detected over a 1 minute, turn off the light”),TAPInspector inserts a random platform delay greaterthan 1 minutes in r and identified a violation that thelight will not turned off which violates r ; • F3 ( V-III-B ). It is shown in Fig. 3(d) and has no constraintof two identical triggers, even allows two triggers tobe mutually exclusive. In the vulnerability, the triggerof r i is activated, but its action a i is delayed with alatency l i . During this latency, r j is performed withoutT2A latency or with a smaller latency. After l i timesout, a i is executed, which overrides the effect of r j ’saction ’ a j . This threat has a different and broader effect than disordered action scheduling. The most commonviolations of this vulnerability have two rules having logicsimilar to the two rules in SmartApp curling-iron (seeFig. 1a), which result in safety-sensitive devices to beingturned on at an unexpected time (e.g., door is unlockedafter the user leaves), or being not able to be activated ata specific time (e.g., no alarm when fire). F4 ( V-IV ): Action Breaking . As shown in Fig. 3(e), thistype of vulnerability is found by analyzing extended actions.TAPInspector figures out all TAP rules using extended actionsfrom 1108 apps and sub-models containing the rules whoseaction may break an extended action. By combining themin a group for each extended action, TAPInspector performsmodel checking with 18 liveness properties (10 generated via T5 ) and finally identifies 45 action breaking violations afterremoving repeated actions. We find that while non-extendedactions can break the extended action, extended action is alsopossible broken by itself. An example violation occurs intwo IFTTT applets r i (“Turn on fan for 15 minutes whenCO > r j (“At noon turn your fan on for 15minutes”). If r j is activated a few minutes (not more than 15minutes) before r i , the fan will be turned off by r j first beforethe extended action of r i ends, which leads to security risks. V-V : Condition Blocking . It is also a common vulnerability[2], [12], [14]. From our results, we find four new modes ofvulnerability related to condition blocking (totally 89 viola-tions): • F5 ( V-V-A ). As shown in Fig. 3(f), in this vulnerability, t i and t j or c j work on the same channel attribute but havedifferent preferences, and a j can lead the condition c ai tobe not satisfied (i.e., a j ⇒ ¬ c ai ). There is a T2A latency l i in the rule r i which is greater than the internal duringwhich the channel attribute rises or drops from the valueused in t i to the one used in t j or c j . After two rule r i and r j are both activated, a j is executed, but a i is notdue to a j ⇒ ¬ c ai . • F6 ( V-V-B ). It is similar to F5 . As shown in Fig. 3(f), themainly difference is that r j has no or a small T2A latencyand the condition c j is equivalent to or satified after thepredicate of t i , e.g., c j is “after 6 pm” and t i is “if it is 6pm”. t j (e.g., “user is present”) may be activated duringthe latency l i and can lead c ai to be not satisfied. We call F5 and F6 as condition dynamic blocking . • F7 ( V-V-C ). Fig. 3(g) depicts a condition blocking vulner-ability, which occurs with two scheduled rules r i and r j . r j is scheduled to perform at an internal δ after t i of r i is activated, e.g., “when motion detected ( t i ) after a quietperiod ( δ )”. However, due to latency misconfigurations orplatform delays, a j is executed before l i times out andleads c ai to be not satisfied. • F8 ( V-V-D ). Still with the two scheduled rules, TAPIn-spector also identifies another vulnerability, shown in Fig.3(g). The difference between F7 and F8 is that in F8 , c j is enabled by a i ( a i ⇒ c j ). An example violationoccurs in two rules r i (“If humidity drops below 38%,water the garden”) and r j (“Over 5 minutes after humidityis below 38% while the watering system is turned on, close the watering system”), but due to platform delays, l i becomes greater than 5 minutes which leads c j (i.e.,watering system is turned on) to be not satisfied and thusthe watering system will not be locked. We call F7 and F8 as scheduled condition blocking .By setting these four modes of vulnerability in a sequentialmodel (i.e., r i and r j are performed in order) and checkingmanually, we find that they all cannot be identified. F9 ( V-VI ): Device disabling . It is a vulnerability related todevice connections shown in Fig. 3(h). In our evaluation, wemainly focus on incorrect connections with outlets. We havetwo settings about how the IoT platform handles offline de-vices as discussed in § V-B. With the setting (1), TAPInspectoridentifies 32 violations with different offline devices, includingsafety-sensitive actuators (e.g., siren, door locker, sprinkler) onwhich related commands cannot be executed, e.g., when smokeis detected, the siren cannot be turned on; or sensors (e.g.,motion detector, humidity sensor) for which sensing data isunavailable, e.g., since motion cannot be detected, the securitysystem cannot react correctly. With setting (2), TAPInspectoridentifies 29 violations. An example in them occurs amongthe three rules discussed in action-trigger vulnerability (Fig.3(b)) and a rule r h in an IFTTT applet (“Bright customerscan turn off smart plug when bright indicates that energyprices are high”). The smart plug is misconfigured with atemperature sensor. r h is activated after the heater is turned on.Then, r j and r k cannot obtain the actual temperature due tooffline temperature sensor and thus, cannot be executed. Thisviolation leads the heater to be kept on, no matter how thetemperature rises. In summary, device disabling is a seriousvulnerability, which is easy to occur since device connectionshighly depend on users’ manual configurations and has a widerange of safety hazards for TAP-based IoT systems.Finnally, to validate the 9 new types of vulnerability modedetected from market apps, we run them both on SmartThingsplatform and a third platform (Mi Home, which also usesTAP rules to enable home automation) to ensure platform-agnostic. We re-construct SmartApps for SmartThings or TAPrules for Mi Home for each vulnerability mode with ouravailable devices shown in Fig. 4. We use turning on and offof a Bluetooth light with a delay between them to representstarting and finishing status of an extended action (e.g., “turnon fan for 15 minutes”). While SmartThings uses runIn toinsert T2A latency, Mi Home also allows to insert any delaysbetween trigger and action. On the two platforms, we findthese vulnerability modes are all valid. Besides, we observethat immediate and tardy attributes are not distinguished in IoTplatforms. That is if we hold the temperature sensor in hand,the measured temperature will quickly rise, which violatesthe actual physical feature of temperature and eases eventspoofing. Hence, we need to standardize rule customization toavoid these vulnerability modes and the IoT providers shouldalso optimize their hardware and software from physical viewsto prevent fake events. C. Performance
Finally, we evaluated TAPInspector’s performance of vul-nerability detection. Fig. 5 illustrates the time overhead for ver-
Fig. 4: Smart Home Devices Used in Our Experiments. ) T Q W R ) T Q W R ) T Q W R % Q O D K P G F 5 N K E G F 0 0 0 0 ) T Q W R 0 ) T Q W R 0 % Q O D K P G F 5 N K E G F 5 N K E G T 5 N K E G T 5 N K E G T 5 N K E G T 5 N K E G T 5 N K E G T ) T Q W R Q H 6 V K O G O K N N K U G E Q P F V K O G Q W V 9 K V J Q W V 1 R V K O K \ C V K Q P 9 K V J % Q O R T G U U K Q P 5 N K E K P I Y K V J Q W V % Q O R T G U U K Q P 5 N K E K P I % Q O R T G U U K Q P 6 T C P U K V K Q P U 6 T C P U K V K Q P U Fig. 5: Verification time. The right vertical axis represents the numberof transitions ( ifying TAP rules extracted from different IoT apps. These appsinclude both the benchmark datasets provided by I OT C OM ( Group 4-6 ) and TAPInspector (
N1-4 and
Group N4-5 ), andthe market dataset. For each benchmark dataset, we performedmodel checking on the individual model of each app or group,their combined model, the model with state compression, andthe sliced sub-models. All properties for
Group 4-6 are safety.We can find that the efficiency of verifying the model withmodel slicing and state compression (48.2 milliseconds (ms))is significantly improved than verifying individually (withoutoptimization is totally 3.3 seconds and with compression istotally 53.2 ms) or the combined model (without optimizationis 49.3 minutes and with compression is 307.6 ms).For
N1-4 and
Group N4-5 , we performed model checkingwith liveness properties. The verification time for its slicedmodels with state compression is totally 295.4 ms, for itsindividual apps and groups without optimization is totally 28.2seconds, but for their combined model without optimizationtimes out. Note that since
N 4 only contains limited state, itsverification time is not explicitly improved through state com-pression. The third part of Fig. 5 is about the verification timeof market apps. We randomly selected 6 model slicers (
Slicer1-6 ) generated by TAPInspector during analyzing market appsand show their verification time with state compression (totally177.1 ms) or not (totally 8.9 minutes) in Fig. 5. We can findthat with model slicing and state compression, TAPInspector’sverification time is significantly reduced. TABLE IV: Comparison between TAPInspector and related works.
Related work Concurrency Rule latency Liveness property Rule interaction Physical channel Device connectionSIFT [38] (cid:55) (cid:55) (cid:55) (cid:51) (cid:55) (cid:55)
AutoTAP [3] (cid:55) (cid:55) ‡ (cid:55) (cid:55) (cid:55) (cid:55) IoTGuard [19] (cid:55) (cid:55) (cid:55) (cid:51) (cid:55) (cid:55)
SOATERIA [36] (cid:55) (cid:55) (cid:55) (cid:51) (cid:55) (cid:55)
IoTSan [21] (cid:51) * (cid:55) (cid:55) (cid:51) (cid:55) (cid:55) IoTMon [13] (cid:55) (cid:55) (cid:55) (cid:51) (cid:51) (cid:55) S AFE C HAIN [16] (cid:55) (cid:55) (cid:55) (cid:51) (cid:51) (cid:55) iRuler [2] (cid:51) † (cid:55) ‡ (cid:55) (cid:51) (cid:51) (cid:55) IoTCom [14] (cid:55) (cid:55) (cid:55) (cid:51) (cid:51) (cid:55)
HomeGuard [12] (cid:55) (cid:51) ¶ (cid:55) (cid:51) (cid:55) (cid:55) TAPInspector (cid:51) (cid:51) (cid:51) (cid:51) (cid:51) (cid:51) * Compares a concurrent model without rule latency with a sequential model. † Models IoT systems as a concurrent model, but does not consider concurrency-related issues. ‡ Models time only for time-related external events. ¶ Validates the effect of T2A latency defined by runIn . D. Limitations
While TAPInspector has been corroborated to be efficientand fast to identify vulnerabilities in TAP rules, it has thefollowing limitations.
First , our ICFG construction for IFTTTapplets is based on simple string analysis, which cannotcorrectly parse these applets with new defined triggers andactions. A future improvement can introduce natural languageprogramming (NLP) techniques for parsing IFTTT applets,similar to [2].
Second , enhancing TAPInspector with dynamicanalysis for reflections and HTTP requests in SmartAppsis necessary for a more complete rule extractor.
Third , ourstate compression only works on integer attributes. Anothercommon type of attributes is enumerated, which can also in-troduce redundant state space. Considering negative predicatesin rules’ conditions, we leave them in full. By eliminatingirelevant elements, the state space can be further reduced.
Fourth , we perform model checking with a random prefer-ence space, which is not rigorous. Implementing an entirepreference space analysis should be able to further improveTAPInspector’ analysis ability.
Fifth , our security analysis doesnot consider the location of IoT devices. It is desired to addsuch spatial context into vulnerability detection, since physicalchannels or connections are sensitive to the location.
Sixth , itis desired to provide an automatic vulnerability repair tool forTAP-based IoT apps, which can help users fix flawed apps andconfigurations in home automation.VII. R
ELATED W ORK
IoT security has received wide attention from several aspects[39], such as IoT devices [40]–[43], protocols [44]–[46], sidechannels [47], [48], and platforms [20], [49], [50]. Here, wemainly discuss the efforts related to our research. To ensurethe security of IoT apps, analyzing their source codes anddetecting violations with static analysis is a much powerfulapproach, which has been widely followed, including SOA-TERIA [36], IoTSAN [21], HomeGuard [12], I OT C OM [14],and also our work TAPInspector. SOATERIA [36], Home-Guard [12] and I OT C OM [14] are similar in extracting be-havior models from IoT apps that they perform AST analysison the Groovy codes of APPs and construct ICFGs for modelconstruction. Since apps in many IoT platforms [4]–[6] areopen-source, such approach can provide finer-grained and deterministic meanings for model construction. We also followthis advanced approach. IoTSAN [21] translates the Groovycode of apps to Java for using the Bandera [51], a toolsetfor model checking Java programs. This translation eases themodel construction but can also result in limited semantics forcovering new apps.Different from source code analysis of IoT apps, IoT-Mon [13] and iRuler [2] present a approach that leveragesNLP techniques to identify behavior models from IoT apps formodel checking or risk analysis. Such an NLP-based approachprovides the support security analysis for where source codesare not available. S AFE C HAIN [16] is a model-checking-based system for privilege escalation and privacy leakage. Itconstructs an FSM of IoT systems manually and automaticallyoptimizes the FSM’s state space by grouping functional equiv-alent attributes and pruning redundant attributes. We believesuch model optimization can also work on our models besidesour model slicing and state compression to further reduceverification time.SIFT [38], AutoTAP [3], ContexIoT [50], and IoT-Guard [19] focus on action-related violation detection andresolution in a static [3], [38] or dynamic [19], [50] man-ner. SIFT [38] is a safety-centric programming platform thatdetects action conflicts and provides assistance in under-standing how to correct problems through model checking.AutoTAP [3] is a tool that can automatically improve orgenerate TAP rules to repair flawed rules specified by usersaccording to given properties. For dynamic resolution, Con-texIoT [50] analyzes individual IoT apps to prevent sensitiveinformation leakage at run-time. IoTGuard [19] is a dynamicrule enforcement system that can prevent the executions ofthese actions leading to violations. Violation detection in theseworks is limited to action conflicts and duplication. Therefore,automated violation resolution is worthy of further study formore comprehensive violations.To compare our work against these above techniques, wepresent their comparison over various features in Table IV.Rule interaction and physical channel have been widely stud-ied. For other features, in IoTSAN [21], the authors discussedthe difference between concurrency and sequential model ofIoT systems. They experimented with small systems and foundthat the sequential approach can discover all violations found the concurrent one. They did not consider rule latency andassumed that the internal events associated with an externalevent are handled atomically in order. Therefore, their con-current model is much similar to the sequential one. iRuler[2] models IoT apps in a concurrent model, and also modelstime as a monotonically increasing variable for time-relatedevents. However, this work did not study concurrency-relatedissues. To the best of our knowledge, TAPInspector is the firstanalysis technique for automated analysis of IoT apps withconcurrent models, rule latency, liveness properties, and deviceconnections. That is why TAPInspector can identify severalnew vulnerability modes.VIII. C ONCLUSION
In this work, we design TAPInspector, a novel automaticvulnerability analysis system for TAP-based IoT systems. Witha comprehensive analysis of the TAP-based IoT system, weidentified several critical features that motivate us to designthe first model-checking-based security analysis system thatcan inspect the IoT system in a concurrent model. With au-tomatic rule extraction and model construction, TAPInspectoraddresses challenges in inspecting the concurrent IoT system,such as formulating TAP rules with various rule latency andreducing state space of models due to concurrency and rulelatency. By designing a set of safety and liveness properties,our evaluations show that TAPInspector identifies 9 new typesof vulnerabilities with excellent performance overhead.R
EFERENCES[1] Z. B. Celik, E. Fernandes, E. Pauley, G. Tan, and P. McDaniel, “Pro-gram analysis of commodity iot applications for security and privacy:Challenges and opportunities,”
ACM Computing Surveys , vol. 52, no. 4,pp. 1–30, 2019.[2] Q. Wang, P. Datta, W. Yang, S. Liu, A. Bates, and C. A. Gunter,“Charting the Attack Surface of Trigger-Action IoT Platforms,” in
Proc.CCS , 2019, p. 1439–1453.[3] L. Zhang, W. He, J. Martinez, N. Brackenbury, S. Lu, and B. Ur,“AutoTap: synthesizing and repairing trigger-action programs using LTLproperties,” in
Proc. ICSE
Proc. UbiComp , 2015, p. 215–225.[11] F. Corno, L. De Russis, and A. Monge Roffarello, “Empowering EndUsers in Debugging Trigger-Action Rules,” in
Proc. CHI , May 2019, p.1–13.[12] H. Chi, Q. Zeng, X. Du, and J. Yu, “Cross-App Interference Threatsin Smart Homes: Categorization, Detection and Handling,” in
Proc.IEEE/IFIP DSN , Jun. 2020, pp. 411–423.[13] W. Ding and H. Hu, “On the Safety of IoT Device Physical InteractionControl,” in
Proc. CCS , Oct. 2018, p. 832–846.[14] M. Alhanahnah, C. Stevens, and H. Bagheri, “Scalable Analysis ofInteraction Threats in IoT Systems,” in
Proc. 29th ISSTA , Jul. 2020,p. 272–285.[15] I. Bastys, M. Balliu, and A. Sabelfeld, “If This Then What? ControllingFlows in IoT Apps,” in
Proc. CCS , Oct. 2018, p. 1102–1119.[16] K. Hsu, Y. Chiang, and H. Hsiao, “SafeChain: Securing Trigger-ActionProgramming From Attack Chains,”
IEEE TIFS , vol. 14, no. 10, pp.2607–2622, 2019. [17] A. K. Sikder, H. Aksu, and A. S. Uluagac, “6thsense: A context-awaresensor-based attack detector for smart devices,” in
USENIX Security ,Aug. 2017, pp. 397–414.[18] C. Fu, Q. Zeng, and X. Du, “HAWatcher: Semantics-Aware AnomalyDetection for Appified Smart Homes,” in
USENIX Security , Aug. 2021.[19] Z. B. Celik, G. Tan, and P. McDaniel, “IOTGUARD: Dynamic Enforce-ment of Security and Safety Policy in Commodity IoT,” in
Proc. NDSS ,Feb. 2019.[20] S. Manandhar, K. Moran, K. Kafle, R. Tang, D. Poshyvanyk, andA. Nadkarni, “Towards a Natural Perspective of Smart Homes forPractical Security and Safety Analyses,” in
Proc. IEEE Symp. Secur.& Privacy , May 2020, pp. 482–499.[21] D. T. Nguyen, C. Song, Z. Qian, S. V. Krishnamurthy, E. J. M. Colbert,and P. McDaniel, “IotSan: Fortifying the Safety of IoT Systems,” in
Proc. 14th CoNEXT , Dec. 2018, p. 191–203.[22] X. Mi, F. Qian, Y. Zhang, and X. Wang, “An Empirical Characterizationof IFTTT: Ecosystem, Usage, and Performance,” in
Proc. IMC , Nov.2017, p. 398–404.[23] S. Owicki and L. Lamport, “Proving Liveness Properties of ConcurrentPrograms,”
ACM Trans. Program. Lang. Syst. , vol. 4, no. 3, p. 455–495,Jul. 1982.[24] IoTMAL benchmark app repository. Accessed: 2021-1. [Online].Available: https://github.com/IoTBench/IoTBench-test-suite[25] A. Pnueli, “The temporal logic of programs,” in , 1977, pp. 46–57.[26] B. B´erard, M. Bidoit, A. Finkel, F. Laroussinie, A. Petit, L. Petrucci,P. Schnoebelen, and P. Mckenzie,
Liveness Properties , 2001, pp. 91–98.[27] F. Yousefi, A. Abhashkumar, K. Subramanian, K. Hans, S. Ghorbani,and A. Akella, “Liveness Verification of Stateful Network Functions,”in
Proc. NSDI , Feb. 2020, pp. 257–272.[28] P. Chini, R. Meyer, and P. Saivasan, “Liveness in broadcast networks,” in
International Conference on Networked Systems . Springer, Sep. 2019,pp. 52–66.[29] I. Dillig, T. Dillig, and A. Aiken, “Sound, Complete and Scalable Path-Sensitive Analysis,” in
Proc. PLDI
Computer Aided Verification .Springer, 2002, pp. 359–364.[35] Z. B. Celik, P. McDaniel, and G. Tan, “Soteria: Automated IoT Safetyand Security Analysis,” arXiv preprint arXiv:1805.08876 , 2018.[36] ——, “Soteria: Automated IoT Safety and Security Analysis,” in
Proc.USENIX ATC , Jul. 2018, pp. 147–158.[37] SmartThings Public Repository. Accessed: 2021-1. [Online]. Available:https://github.com/SmartThingsCommunity/SmartThingsPublic[38] C.-J. M. Liang, B. F. Karlsson, N. D. Lane, F. Zhao, J. Zhang, Z. Pan,Z. Li, and Y. Yu, “SIFT: Building an Internet of Safe Things,” in
Proc.IPSN , Apr. 2015, p. 298–309.[39] O. Alrawi, C. Lever, M. Antonakakis, and F. Monrose, “SoK: SecurityEvaluation of Home-Based IoT Deployments,” in
Proc. IEEE Symp.Secur. & Privacy , May 2019, pp. 1362–1380.[40] X. Wang, Y. Sun, S. Nanda, and X. Wang, “Looking from the Mirror:Evaluating IoT Device Security through Mobile Companion Apps,” in
USENIX Security , Aug. 2019, pp. 1151–1167.[41] J. Chen, W. Diao, Q. Zhao, C. Zuo, Z. Lin, X. Wang, W. C. Lau, M. Sun,R. Yang, and K. Zhang, “IoTFuzzer: Discovering Memory Corruptionsin IoT Through App-based Fuzzing.” in
Proc. NDSS , Feb. 2018.[42] G. Ho, D. Leung, P. Mishra, A. Hosseini, D. Song, and D. Wagner,“Smart Locks: Lessons for Securing Commodity Internet of ThingsDevices,” in
Proc. 11th ASIACCS , May 2016, p. 461–472.[43] D. Kumar, K. Shen, B. Case, D. Garg, G. Alperovich, D. Kuznetsov,R. Gupta, and Z. Durumeric, “All things considered: An analysis ofiot devices on home networks,” in
USENIX Security , Aug. 2019, pp.1169–1185.[44] E. Ronen, A. Shamir, A. Weingarten, and C. O’Flynn, “IoT GoesNuclear: Creating a ZigBee Chain Reaction,” in
Proc. IEEE Symp. Secur.& Privacy , May 2017, pp. 195–212. [45] P. Morgner, S. Mattejat, Z. Benenson, C. M¨uller, and F. Armknecht,“Insecure to the Touch: Attacking ZigBee 3.0 via Touchlink Commis-sioning,” in Proc. 10th WiSec , Jul. 2017, p. 230–240.[46] B. Fouladi and S. Ghanoun, “Security evaluation of the Z-Wave wirelessprotocol,”
Black hat USA , vol. 24, pp. 1–2, Jul. 2013.[47] J. Han, A. J. Chung, M. K. Sinha, M. Harishankar, S. Pan, H. Y.Noh, P. Zhang, and P. Tague, “Do You Feel What I Hear? EnablingAutonomous IoT Device Pairing Using Different Sensor Types,” in
Proc.IEEE Symp. Secur. & Privacy , May 2018, pp. 836–852.[48] E. Ronen and A. Shamir, “Extended Functionality Attacks on IoTDevices: The Case of Smart Lights,” in
IEEE EuroS&P , Mar. 2016,pp. 3–12.[49] E. Fernandes, J. Jung, and A. Prakash, “Security Analysis of EmergingSmart Home Applications,” in
Proc. IEEE Symp. Secur. & Privacy , May2016, pp. 636–654.[50] Y. J. Jia, Q. A. Chen, S. Wang, A. Rahmati, and A. Prakash, “ContexIoT:Towards Providing Contextual Integrity to Appified IoT Platforms,” in
Proc. NDSS , Feb. 2017.[51] J. Hatcliff and M. Dwyer, “Using the Bandera tool set to model-checkproperties of concurrent Java software,” in