shattered chain of trust: understanding security risks in cross...

Shattered Chain of Trust Understanding Security Risks in Cross-Cloud IoTAccess Delegation

Bin Yuan1324lowast Yan Jia572lowast Luyi Xing2daggerDongfang Zhao2 XiaoFeng Wang2 Deqing Zou13 Hai Jin63 Yuqing Zhang75

1School of Cyber Science and Engineering Huazhong Univ of Sci amp Tech China 2Indiana University Bloomington3National Engineering Research Center for Big Data Technology and System Cluster and Grid Computing Lab Services Computing

Technology and System Lab and Big Data Security Engineering Research Center Huazhong Univ of Sci amp Tech China4 Shenzhen Huazhong University of Science and Technology Research Institute China 5School of Cyber Engineering Xidian University China

6School of Computer Science and Technology Huazhong Univ of Sci amp Tech China7National Computer Network Intrusion Protection Center University of Chinese Academy of Sciences China

Abstract

IoT clouds facilitate the communication between IoT de-vices and users and authorize usersrsquo access to their devicesIn this paradigm an IoT device is usually managed under aparticular IoT cloud designated by the device vendor egPhilips bulbs are managed under Philips Hue cloud Todayrsquosmainstream IoT clouds also support device access delega-tion across different vendors (eg Philips Hue LIFX etc)and cloud providers (eg Google IFTTT etc) for exam-ple Philips Hue and SmartThings clouds support to delegatedevice access to another cloud such as Google Home so auser can manage multiple devices from different vendors allthrough Google Home Serving this purpose are the IoT del-egation mechanisms developed and utilized by IoT cloudswhich we found are heterogeneous and ad-hoc in the wild inthe absence of a standardized delegation protocol suited forIoT environments In this paper we report the first system-atic study on real-world IoT access delegation based upona semi-automatic verification tool we developed Our studybrought to light the pervasiveness of security risks in thesedelegation mechanisms allowing the adversary (eg Airbnbtenants former employees) to gain unauthorized access to thevictimrsquos devices (eg smart locks) or impersonate the devicesto trigger other devices We confirmed the presence of crit-ical security flaws in these mechanisms through end-to-endexploits on them and further conducted a measurement studyOur research demonstrates the serious consequences of theseexploits and the security implications of the practice todayfor building these mechanisms We reported our findings torelated parties which acknowledged the problems We furtherpropose principles for developing more secure cross-cloudIoT delegation services before a standardized solution can bewidely deployed

1 IntroductionlowastWork was done when the first two authors were at Indiana University

BloomingtondaggerCorresponding author Luyi Xing Indiana University Bloomington

The popularity of Internet of Things (IoT) gives rise to thedemand for effectively managing these devices which hasbeen supported by IoT clouds These clouds are operatedby both device vendors (Philips Hue LIFX Tuya etc) andcloud providers (Google Amazon IFTTT etc) offering in-tegrated services for IoT users to control their devices acrossthe Internet in a convenient and transparent way Prominentexamples include SmartThings [33] IFTTT [13] and GoogleHome [12] Such cloud services facilitate the communicationbetween IoT devices and users and manage usersrsquo accessto the devices IoT devices are registered to the clouds andusersrsquo control commands (eg opening a lock typically is-sued through the companion app of the device) go through thecloudsrsquo authentication and authorization ensuring only autho-rized users can operate a device Todayrsquos IoT clouds tend toprovide complicated functionalities like cross-vendorcross-cloud device control sharing of device access device controlautomation etc as enabled by the cloudrsquos vast computingand communication resources Of particular importance is thecapability to delegate device access across different cloudsand users for example Philips Hue may allow Google Hometo control its smart light bulb so the owner of the bulb canmanage multiple devices from different vendors all throughGoogle Home an Airbnb host may temporarily give the ac-cess to the smart devices in her home to her guest duringhis stay Such a capability can lead to a convoluted delega-tion chain whose complicated authorization operations couldeasily go wrong Although threats to IoT devices have beenstudied before [23 52 56 57 62 76] little has been doneso far to systematically analyze and understand the securityimplications of this IoT delegation process

Risks in cross-cloud delegation Delegation of authority hasbeen studied in the access control community for decadeswith security risks such as credential leakage incomplete re-vocation and incorrect policy enforcement [61 69 73] beingdiscovered Unlike the theoretic models analyzed before inwhich all parties run the same delegation protocol and inter-act through unified interfaces real-world IoT clouds oftenutilize their individual heterogeneous delegation protocols

that may not be compatible with those of other clouds andmay not have been properly verified For example the LIFXand IFTTT clouds delegate access to the SmartThings cloudthrough different protocols LIFX issues an OAuth token toSmartThings to access LIFX bulbs while IFTTT providesSmartThings a secret URL as a security token to access its de-vices (see Section 3) To work with these delegator clouds theSmartThings cloud runs a program from each of them that im-plements the corresponding protocol to enable SmartThingsto communicate with the devices on each delegator cloud1

Such a program allows the delegator to participate in furtheraccess management of the device for users on SmartThingscloud a security risk could arise however when the programis not fully compliant with SmartThingsrsquo security policies(Section 31) Given that a standard delegation protocol (suchas WAVE [45]) could take a long time to be adopted and de-ployed in the wild until all compatibility and usability issuesare resolved a systematic analysis of todayrsquos IoT delegationand in-depth understanding of its security risks are of criticalimportance This however has never been done before up toour knowledge

Findings In this paper we report the first attempt to analyzethe security weaknesses of real-world IoT access delegationand mitigate their potential threats to the IoT ecosystem Us-ing a semi-automatic verification tool we evaluated the dele-gation supports provided by 10 popular IoT clouds includingboth device vendors (Philips Hue LIFX iHome etc) andIoT cloud providers (IFTTT Amazon SmartThings Googleetc) Our study shows that device delegation on these cloudsis often vulnerable (Section 3) and can be exploited to gainunauthorized access to the victimrsquos devices or impersonatethe devices to perform unauthorized interactions with otherdevices The consequences of such attacks are serious rang-ing from completely losing control on the delegated accessrights on SmartThings (Section 32) to leaking sensitive de-vice IDs on Google Home that enables the attacker to unlockthe victimrsquos home door by spoofing events (Section 31)

Most importantly our research shows that the heteroge-neous and ad-hoc delegation processes in the wild have ledto conflicting delegation policies across IoT clouds Morespecifically under todayrsquos IoT cloud delegation model thedelegator and delegatee clouds are less decoupled than ex-pected and therefore need to be aware of each otherrsquos securityconstraints when determining their own delegation policiesAs mentioned earlier the SmartThings cloud delegated withaccess rights to a device requires the delegator cloud to uploada program aka SmartApp to help access the device fromthe delegator When SmartThings further grants to its usersthe access to the device however we found that a SmartApp

1Throughout the paper we call the party (an IoT cloud or the deviceowner) delegating access right to another party delegator and the recipientof the right delegatee Also we call a cloud with direct access to a devicedevice vendor cloud or simply vendor cloud (as it is typically operated bythe vendor)

not compliant with the delegation policies of SmartThings(eg the IFTTT SmartApp) exposes to the SmartThings usersthe privilege that SmartThings cannot revoke (Section 31)On the other hand SmartThingsrsquo access delegation to theGoogle Home cloud needs to go through Googlersquos interfacethat asks for both device ID and OAuth token Although de-vice ID is public for many IoT clouds (Belkin Philips Hueand MiHome) [52 76] it is an authentication token on Smart-Things [56] Unaware of this side effect Google Homersquospolicy of sharing SmartThings device ID with its users en-ables a malicious delegatee user to directly access devices onSmartThings cloud even after Google Home has revoked hisaccess to the device (Section 31) Such incomplete informa-tion of the other partyrsquos security policies and constraints turnsout to be a fundamental problem in todayrsquos IoT delegationmodel

Also an IoT cloud tends to directly adopt existing autho-rization protocols such as OAuth which however cannot meetall delegation requirements in the IoT environments (Sec-tion 32) Particularly we found that a malicious delegateeuser on the Tuya cloud can bypass its access control by strate-gically delegating his access to Tuya devices to another cloud(eg Google Home) and leveraging the latterrsquos OAuth tokento access the devices even after his access right has beenrevoked in the Tuya cloud ndash a violation of the transitivityproperty in delegation (Section 32) Also problematic is theheterogeneous and custom delegation protocols which of-tentimes did not go through a rigorous verification and aretherefore error-prone in their policy enforcement causingsecurity risks such as leaking the OAuth token to an unautho-rized party (Section 32)

Methodology Our security analysis was facilitated by a semi-automatic verification tool called VerioT which performsmodel checking for IoT delegation systems To this end wecame up with a simple generalized security property thatcaptures the requirements of IoT delegation Most challeng-ing here is to model different real-world delegation systemswhich requires manual effort to read developer documen-tations and user manuals of those IoT clouds and analyzecommunication traffic of their companion mobile apps tounderstand their delegation mechanisms and operations Toreduce such manual efforts we leverage the observation thatcross-cloud delegation can be described by combinations ofbasic types of delegation operations (Section 42) and cor-responding data flows such as OAuth token issuing whichare similar across different clouds This allows us to designa modeling approach involving a base delegation model thatoutlines the generic operations and data flows in a cross-clouddelegation and a set of templates for different basic types ofdelegation operations To describe a real-world delegationsystem one can directly use or customize existing templatesto refine the base delegation modelThe new model automati-cally produced by our tool is then verified against the securityproperty using Spin [38] an off-the-shelf model checker Any

counterexample produced by the checker represents a poten-tial attack path which can lead to the detection of a weaknessin the delegation process VerioT was used in our researchto find all except one vulnerabilities reported in the paper Wehave made the tool publicly available [34] including the basedelegation model and operation templates

Impacts Running VerioT to analyze the delegation op-erations on leading IoT clouds including Google HomeSmartThings IFTTT Philips Hue etc we have discovered6 security-critical vulnerabilities that expose millions of IoTusers and hundreds of IoT clouds to security risks (Section 5)We reported all these flaws to the affected parties includingGoogle Home SmartThings Philips Hue etc which are tak-ing actions to address them eg SmartThings has deployedtwo fixes and Philips Hue claimed that they will release a fixto our reported vulnerability in their upcoming update Weare helping other cloud providers and device vendors to findsolutions The demos of our attacks are online [34]

Contributions We summarize the contributions of the paperas follows

bull New understanding of IoT delegation We performed thefirst systematic study on security risks in IoT device accessdelegation Our research has brought to light new categoriesof unexpected and security-critical vulnerabilities in the del-egation process of todayrsquos leading IoT cloud providers anddevice vendors the serious consequences once these vulnera-bilities have been exploited their fundamental causes and thechallenges in fixing them The lesson learned will contributeto better protection of real-world IoT delegation

bull IoT delegation verification We developed and released thefirst support for formal verification of real-world IoT delega-tion Our base model delegation operation templates securityproperty and refinement technique have made the first steptoward convenient and automated discovery of delegationvulnerabilities which helps secure not only todayrsquos but alsotomorrowrsquos IoT delegation operations

Roadmap The rest of this paper is organized as followsSection 2 provides the background information of IoT de-vice delegation and discusses its security requirements andpotential risks Section 3 elaborates the vulnerabilities wediscovered Section 4 describes the semi-automatic method-ology we used to find these vulnerabilities Section 5 reportsa measurement study on the impacts of the delegation flawsSection 6 discusses the design principles for developing se-cure delegation mechanism the limitations of our work andpotential future directions Section 7 compares the relatedprior studies with our work and Section 8 concludes the paper

2 Cross-cloud IoT Access Delegation

21 BackgroundCloud-based IoT access Figure 1 shows the typical proce-dure for accessing devices through IoT clouds Specificallythe owner of an IoT device first registers her device to thedevice vendorrsquos cloud (eg through presenting a client cer-tificate embedded in a device as an iHome smart plug does)or a third-party cloud adopted by the device vendor (egKEYGMA devices are registered to Tuya cloud [16]) so thedevice could be managed through the cloud As mentioned inSection 1 we call a cloud with direct access to a device devicevendor cloud or simply vendor cloud When a user attemptsto access the device (eg through her mobile app or webconsole) the cloud authenticates the user and then sends hercommands to the target device if the user is authorized ThisIoT access paradigm has been adopted by mainstream IoTdevice vendors (eg Philips August iRobot LIFX iHomeTuya etc) as well as third-party IoT clouds (SmartThingsGoogle Amazon etc)

IoT

Cloud

IoT

Cloud

IoT Devices

Device

Vendor

Cloud

IoT

Cloud

UserUser

register delegate

IoT

Cloud

IoT

Cloud

②①

⑤delegate ④delegate

⑥delegate ⑥delegate

③delegate②delegate

Figure 1 The complex delegation in IoT

In addition to the direct device access initiated by the usermainstream IoT clouds such as SmartThings IFTTT Ama-zon Alexa etc also allow the user to define trigger-actionrules to automatically trigger her devicesrsquo actions under someevents for example once the userrsquos front door lock is un-locked the cloud also turns on her living room bulbCross-cloud access delegation To control an IoT device theuser needs to install its vendorrsquos app which is not scalablewith an increasing number of devices from different vendorsone needs to manage To address this challenge cross-cloudIoT delegation has emerged to provide a uniform and trans-parent interface to handle devices from different vendors Forexample through the app of Google Home which has beengiven access rights to all devices in the userrsquos possession shecould control her smart bulb in the Philips cloud smart lock inthe SmartThings cloud smart plug on iHome cloud etc Thisaccess paradigm is made possible by a delegation process

As illustrated in Figure 1 to manage a smart lock in the

SmartThings cloud Google Home needs to get an access to-ken (eg an OAuth token [24]) from the SmartThings cloudthe lock is registered to With the token an authorized Googleuser can issue commands through Google to SmartThings soas to operate on the device For this purpose SmartThingsneeds to delegate the right to access the device to Googlethrough OAuth [24] or other custom authorization solutionsTaking OAuth as an example the user can trigger this dele-gation process through the following steps (1) logs onto herGoogle Home console (eg a mobile app ) (2) selects ldquosetup device to enter her SmartThings account credential (3) ifthe user is allowed to use the device SmartThings generatesan access token and forwards it to Google Home Such cross-cloud delegation has been supported by all mainstream IoTclouds

22 Complexity in IoT delegationDelegation chain Real-world IoT delegation often involvesmultiple parties and can become quite complicated as illus-trated by Figure 1 As we can see the access right to an IoTdevice is first given to its device vendor cloud (Agrave) The ven-dor then delegates the access to a delegatee cloud (Aacute) suchas Google Home for controlling a userrsquos devices managedby different vendor clouds The delegatee cloud may furtherhand over the access right to another (delegatee) cloud (Acirc)On each of these clouds access to the device can be granted(by the device administrator) to one or more (delegatee) users(Atilde Auml) Along the delegation chain the (delegatee) user mayfurther give her access to another (delegatee) cloud (Aring)Cross-cloud delegation mechanisms Different IoT cloudstoday have their own authorization mechanisms to delegate de-vice access rights to or receive delegations from other cloudsand their own users Each party on a delegation chain is ex-pected to follow the mechanisms (and their input constraints)of its upstream (delegator) and downstream (delegatee) actorsSuch heterogeneous authorization gets each IoT cloud entan-gled in the device management of another cloud even afterthe delegation happens In our research we analyzed the typi-cal authorization mechanisms as deployed on 10 mainstreamIoT clouds which are presented belowbull OAuth and its customizations OAuth is an open standardfor access delegation [24] which has been widely adopted byIoT clouds A problem is that OAuth is not designed for IoTand therefore some IoT clouds have customized it to facili-tate cross-cloud device management An example is Actionson Google protocol which is a customization to OAuth byGoogle [1] any device vendor cloud (such as Philips HueLIFX iHome) that delegates access tokens (ie OAuth token)to Google Home is required to provide a set of informationabout the target device(s) including device IDs device typesdevice names etc Such information is used by Google forcross-cloud device control which allows the Google Homeuser to find and operate on devices based on their IDs names

etc albeit the devices are actually behind another cloud

bull Custom authorization We also found that IoT clouds canuse custom sometimes ad-hoc authorization mechanisms forcross-cloud delegation For example IFTTT cloud delegatesaccess to SmartThings cloud through a secret URL when aSmartThings user needs to access the device behind IFTTTSmartThings sends her requests to IFTTT through the URLIn the meantime SmartThings asks its delegator to upload aSmartApp (eg the IFTTT SmartApp) for communicatingwith both the delegator-side device and its client who uses thedevice

23 Security Requirements

As mentioned earlier cross-cloud IoT delegation involves dif-ferent actors with different security policies and complicatedsometimes ad-hoc enforcement Access control under thiscircumstance faces unique challenges and is expected to meetunique security requirements as summarized below

Safe and consistent delegation policies IoT delegation in-volves parties from different organizations (vendors cloudsusers) with discrepant security needs Under the delegationmodel deployed on todayrsquos clouds a party on a delegationchain could get involved in another partyrsquos management ofa device Therefore in the absence of a full picture of otherpartiesrsquo security constraints a delegation process could get tothe situation where a delegateersquos policy could bring in a riskthat could put a delegatorrsquos security in jeopardy So ideallydelegation policies across all actors on a chain should be con-sistent with each partyrsquos individual security policies ensuringthat they will not be exposed to new threats during the wholeprocess

Non-bypassable and transitive delegation control On adelegation chain access rights to an IoT device could bedistributed across multi-parties Enforcement of a delegationpolicy therefore is expected to be comprehensive blockingall avenues of unauthorized access Also important is thetransitivity in delegation control once a delegator enforcesa policy (eg revoking its delegatee partyrsquos access right) alldownstream parties should all follow suit (eg even accessrights further delegated out by the delegatee should also beautomatically revoked)

24 Threat model

We define two user roles in the distributed IoT system theadministrator and the delegatee user The administrator can bea device owner or a system administrator of an organizationThe administrator can delegate the access to IoT devices toother users ndash the delegatee user Delegatee userrsquos access issubject to revocation and expiry The delegatee user mayfurther delegate to others

In our research we consider the system administrator andthe IoT clouds to be honest while the delegatee user canbe malicious who may attempt to get unauthorized accessto IoT devices We assume that the malicious user wouldmake full use of his power to acquire the credentials anduseful information he is not entitled to access eg makingAPI requests to gain extra credentials extracting informationfrom system logs official developer documents and capturednetwork traffic generated by his mobile app In the meantimewe do not consider the adversary capable of eavesdroppingon the communication between other parties

3 Security of Cross-Cloud IoT Delegation

In this section we report a security analysis on cross-cloudIoT delegation operated by 10 leading IoT clouds includ-ing Google Home SmartThings IFTTT Philips Hue Au-gust LIFX Tuya etc Through discovery of five flaws andconstruction of their end-to-end attacks (see video demosonline [34]) our study shows that in the absence of a stan-dardized verified cross-cloud delegation protocol delegationacross mainstream IoT clouds is hard to make right oftencontaining serious flaws in its policy design or enforcement

One of the flaws (Flaw 4 see below) was found manuallywhich led to this research and our development of VerioTthat helped discover all other flaws based on our modelingof real-world cross-cloud delegation and formal verification(Section 4) With respect to the two security requirementssummarized earlier (Section 23) we classify all flaws iden-tified in our study into two categories (1) inconsistent se-curity policies between the delegator and delegatee clouds(Section 31) (2) inadequate enforcement of delegation transi-tivity in the presence of customized often ad-hoc delegationmanagement across real-world IoT clouds (Section 32)

31 Inadequate Cross-Cloud Coordination

As mentioned earlier under the heterogeneous and often ad-hoc authorization on todayrsquos IoT clouds a cloud on a del-egation chain often cannot decouple its access delegationmanagement from those of other clouds and thus easily getsinvolved in othersrsquo access control decisions So it is importantfor these clouds to be aware of each otherrsquos security assump-tions and constraints Such a coordination however is not inplace today as discovered in our research which brings insecurity risks to the parties on the chain Here we report twovulnerabilities discovered on popular IoT cloud services thatcharacterize the real-world challenges in securing cross-cloudIoT access management

Flaw 1 Device ID disclosure As mentioned earlier (Sec-tion 22) clouds that delegate device access to Google Homemust follow an OAuth protocol customized by Google thedelegator cloud is required to provide both an OAuth token

and its device information to Google For example (see Fig-ure 2) to enable a Google Home user to manage devicesbehind the SmartThings cloud (eg smart lock smart switchetc) Google needs to be given both an OAuth token (througha regular OAuth process) and additionally the device informa-tion (eg device IDs device names etc) from SmartThingsSuch device information is further passed to the Google Homeuser to command the target device

deviceID

Google Home cloud

August

smart lock

SmartThings cloud Google Home user

delegateOAuth

deviceID

SmartThings

switch

SmartThings

hub

SmartAPP

Figure 2 Google Home leaks the deviceID of SmartThingsswitch enabling the adversary to unlock smart lock

In our study we found that such a delegation process intro-duces a new security risk due to Googlersquos lack of knowledgeabout the security implication of SmartThingsrsquo device ID Al-though the device ID normally just serves the purpose of locat-ing its device on a cloud (such as Philips Hue and MiHome) itis also used as an authentication token on SmartThings for itstrigger-action management by presenting the ID of a device(a 32-digit string unique to a device under SmartThings) onecan issue events (eg temperature change switch toggledpresence detected etc) to the SmartThings cloud on behalf ofthe device (through the sendLocationEvent API see our PoCattack) such events can further trigger other devices managedunder the SmartThings cloud (through trigger-action rulessee Section 21) Note that although the presence of the de-vice ID allows an event to be issued and related operations tobe triggered on SmartThings (according to predefined rules)it is not an authorization token for device access that is anunauthorized party cannot use the ID to command the devicehe is not entitled to access

Unaware of this side effect Google discloses this ID toany client with the access right to the device which brings inthe security hazard Specifically on Google Home as longas the administrator (eg an Airbnb host a property man-ager) delegates a devicersquos access right to a user once (egan Airbnb guest a tenant) the ID of the SmartThings deviceis permanently exposed Even after the delegateersquos accessis revoked on Google Home (eg after he checks out of theAirbnb apartment) he still retains the capability to fake eventsof the device using the ID and triggers the administratorrsquosother devices Depending on the trigger-action rules config-ured by the owneradministrator the fake events can open asmart lock (letting in an unauthorized individual) turn off analarm etc through the SmartThings platform [10]

In our research we performed a measurement study onthe consequences of the attack (Section 52) and found thatpotentially many vendors could be affected by such a flawFurther we did not find any mechanisms in place to allow

the clouds like Google (delegated with device access rightsfrom almost 1000 vendors) to get information about theirdelegatorsrsquo security assumptions and constraints based uponthe documentations we inspected (see Section 52)PoC exploit on Flaw 1 Exploiting the above weakness weimplemented an end-to-end PoC attack on our own devicesndash an August smart lock and a SmartThings switch (a virtualswitch that can be toggled in mobile app ndash not a physicalswitch) The experiment setting is outlined in Figure 2 Specif-ically the victim set a trigger-action rule on the SmartThingscloud if the switch is toggled then lockunlock the smart lockalso she linked her SmartThings account to Google HomeThen through Google Home she granted the access right ofthe switch to a malicious user (eg an ill-intentioned Airbnbguest) At this point the attacker obtained the SmartThingsdevice ID of the switch by inspecting the network traffic be-tween his Google Home mobile app and the Google cloudLater the victim revoked the malicious userrsquos access right andhe could not control the device from his Google Home appHowever using a simple SmartApp of SmartThings (see oursource code online [34]) which sends fake switchoff eventsto the SmartThings cloud with the switchrsquos device ID theattacker was able to open the smart lock

SmartThings

cloudSmartThings user

SmartApp

IFTTT

applet

IFTTT cloud

August

smart lock

SmartThings

switch

delegate delegate

Figure 3 Security policy confliction between IFTTT cloudand SmartThings cloud

Flaw 2 Leaking secret of delegatee cloud Delegation Flaw1 shows that a delegatee cloud (Google) could leak the se-cret of its delegator cloud (SmartThings) Surprisingly wefound that such unintended information disclosure could alsogo other way around a delegator cloud can also expose thesensitive data that the delegatee cloud intends to protect Theproblem affects multiple leading IoT clouds (SmartThingsIFTTT etc) Again it is caused by the entangled delegationprocess with both the delegator and the delegatee involved inthe otherrsquos authorization process and the lack of coordinationto align their security policies

Unlike Google that uses a delegation protocol with a manda-tory input interface its delegator cloud must follow Smart-Things cloud provides a flexible mechanism its delegator isallowed to upload a software module called SmartApp [35]to SmartThings to help execute its delegation protocol andmanage the access to the device under the delegator cloudAs an example the IFTTT cloud delegates access to its de-vice through sharing a secret URL with SmartThings throughthe URL when a SmartThings device issues an event (eg asmart switch is operated) the SmartThings cloud can trigger

the actions of an applet on IFTTT to control another device be-hind the IFTTT cloud (eg August smart lock see Figure 3)based upon pre-defined trigger-action rules This rather ad-hoc delegation protocol runs on the SmartThings side by anIFTTT SmartApp (Figure 3) which acts as an interface be-tween the two clouds With the IFTTT SmartApp the usercan define such trigger-action rules to connect the devices(eg the switch and the lock) across the clouds As a resulther operation on the SmartThings device will be used by theSmartApp to invoke the activities on the device behind IFTTTcloud

Since the IFTTT SmartApp runs on the SmartThings cloudand interacts with the end user it is important to make surethat the SmartApp strictly follows SmartThingsrsquo security poli-cies Our research however shows that these policies have notbeen fully respected by the IFTTT SmartApp possibly dueto the lack of coordination between the two clouds Specifi-cally we found that by calling an API provided by the IFTTTSmartApp the SmartThings user can get the secret URL Thisviolates SmartThingsrsquo policy that allows a device administra-tor (eg an Airbnb host) to temporarily delegate the accessright on her devices to a user (eg delegating the SmartThingsswitch to an Airbnb guest to operate the lock) and later re-voke the right That is once the delegatee user acquires theURL he retains a direct channel to communicate with theIFTTT device even after the administrator revokes his accessto the device on SmartThings for example through the URLwhich serves as an authentication token the user can send afake event (eg switch is off) on behalf of the SmartThingsdevice (eg the smart switch) so as to trigger the action onthe IFTTT side (eg open the lock)

PoC exploit on Flaw 2 We conducted a PoC attack to exploitthe flaw As outlined in Figure 3 we configured our Augustsmart lock on the IFTTT cloud such that an applet in theIFTTT cloud will openclose our lock upon receiving theswitch event from the SmartThings cloud ndash a normal usagescenario intended by the IFTTT platform we also configuredour smart switch on SmartThings when the switch is turnedon or off an event will be issued by the IFTTT SmartAppthrough the IFTTT cloud leading to different operations onthe lock

After that we temporarily invited a ldquomaliciousrdquo user toaccess the switch on the SmartThings cloud Note that onSmartThings devices a user can access are organized as agroup called location which also includes the SmartAppsrelated to the devices (eg the IFTTT SmartApp) alsolocation is SmartThingsrsquo smallest unit for device delegationif the administrator wants to give the access to devices at alocation he needs to pass the control on the location to thedelegatee user In our attack with access to the location themalicious delegatee user could obtain the secret URL fromthe IFTTT SmartApp by calling the Web API it hosts (a URLendpoint such as httpsgraphapismartthingscomapismartapps[32-digit-string]subscriptions

specific to the IFTTT SmartApp in a particular location)To get the Web API the delegatee user called a publicWeb API of the SmartThings cloud (httpsgraphapismartthingscomapismartappsendpoints) which isdesigned to return to a client the Web APIs available in thelocation that the client has access to In our attack by simplycalling the returned Web API the delegatee user obtained thesecret URL from the IFTTT SmartApp then by posting anHTTP request to the URL the user was able to trigger theIFTTT applet to open the smart lock even after his accesshad been revoked in the SmartThings cloud

Discussion Here the problem comes from the misaligned se-curity policies between SmartThings and IFTTT Specificallythe IFTTT SmartApp simply trusts any user with access to thedevices and discloses the URL ndash a security token ndash to the ma-licious delegatee user Such an operation however completelyinvalidates SmartThingsrsquo enforcement of its delegation revo-cation policy Also importantly since the URL is hosted bythe IFTTT cloud there can be no easy way for SmartThings torevoke the URL without the proper policy coordination fromIFTTT or a mechanism supported by IFTTT for SmartThingsto revoke the URL anytime it wants (eg once SmartThingsrevokes access of a delegatee user) However our study indi-cates that proper cross-cloud policy coordination is absent intodayrsquos IoT ecosystem

Responsible disclosure We reported both flaws to affectedparties including Google Home SmartThings etc who ac-knowledged the seriousness of the problems SmartThingsawarded us through their bug bounty program

32 Inadequate Policy EnforcementIn addition to conflicting security policies across clouds theaccess delegation mechanisms developed by individual cloudsalso turn out to be ad-hoc likely due to the constraints oftheir systemsrsquo functionalities and the absence of a standard-ized IoT delegation protocol This leads to a problem thatthose real-world delegation operations often have not beenrigorously verified and therefore their enforcement of dele-gation policies can be vulnerable Following we elaborateon three security-critical flaws discovered from popular IoTclouds which demonstrate the importance of systematic secu-rity analysis on todayrsquos heterogeneous ad-hoc IoT delegationecosystem as we propose in the paper

OAuth delegate

LIFX bulbs LIFX cloud SmartThings cloud SmartThings user

OAuth Token

ID1 ID2 ID3

OAuth Token

ID1ID1

ID2

ID3 SmartApp

LIFX (Connect)

Figure 4 Policy violation between LIFX and SmartThings

Flaw 3 Exposing hidden devices in the delegator cloudLIFX [17] is a popular IoT manufacturer whose cloud can del-egate device access to other clouds such as SmartThings for

example when the device administrator wants to use Smart-Things to manage all her devices To support the delegationprotocol of LIFX the SmartThings cloud runs a LIFX Smar-tApp for the cross-cloud device access (Figure 4) like thedelegation from IFTTT (Flaw 2) Again the LIFX SmartAppnot only serves as the interface between the two clouds butalso helps SmartThings manage the access to LIFX devices

As mentioned earlier (Section 31) on SmartThings de-vices that the user can access and related SmartApps aregrouped into a location including devices behind the dele-gator clouds In reality however a property manager or anAirbnb host (the administrator) may not want to give hertenant access to all her devices (eg the smart lock for theownerrsquos room in a rented-out apartment) This is supportedby the LIFX SmartApp in her location which can be autho-rized to access all LIFX devices of the administrator (with theOAuth token issued by the LIFX cloud) and in the meantimecan be configured to expose only a subset of the devices tothe location As a result the delegatee user (eg the tenant)will only be able to use the subset of devices at the locationhe is given access to

However we found that the LIFX SmartApp has not beenproperly protected on the SmartThings cloud It turns out thatthe delegatee user on SmartThings is allowed to read from theprivate storage of the SmartApp at the location which allowshim to obtain the OAuth token kept there This exposure hasserious consequences No longer can the administrator hidesome LIFX devices from her delegatee who can retrieve alldevice IDs from the LIFX cloud through its List Lights API[19] using the OAuth token and further use the IDs and thetoken to command any device under the administratorrsquos con-trol through the Set State API [20] Even more seriously thisunauthorized privilege will be kept by the user even after hisright has been revoked by the administrator on SmartThingsFurther our measurment study (Section 52) shows that theproblem also affects tens of other IoT vendors that delegateto SmartThings access to their devices

PoC exploit on Flaw 3 To exploit the above weakness weperformed an end-to-end attack with our own LIFX bulbsAs outlined in Figure 4 we first delegated all LIFX bulbsto the SmartThings cloud and configured the LIFX Smar-tApp to expose only bulb1 (the one with ID1) to our Smart-Things location Then we delegated the SmartThings lo-cation to the malicious user for accessing bulb1 (with allother bulbs hidden) However since the malicious delegateegained the access to the location he successfully obtainedthe OAuth token from SmartThings IDE system [37] Smart-Thingsrsquo Web-based management console that shows Smar-tApps in the location and their storage With the OAuth to-ken the malicious user could acquire IDs of the administra-torrsquos other bulbs from LIFX List Lights Web API (httpsapilifxcomv1lightsall used to list all devicesavailable to a client) [19] and then control them remotely [20]

Flaw 4 OAuth pitfall Not only do custom delegation mech-anisms operated by todayrsquos mainstream IoT clouds (egGoogle SmartThings IFTTT etc) all contain serious securityweaknesses (Flaw 1-3) but our research further shows thateven a direct application of OAuth [24] ndash a cross-service del-egation standard to the complicated IoT delegation turns outto be error-prone The new security problem we discoveredaffects several IoT vendors including KEYGMA MOESUseelink etc (see Section 52)

Tuya

smart plug Tuya cloud Google Home

delegate delegate

Tuya user

OAuth Token

Figure 5 Independent OAuth Tokens for third-parties

Specifically let us use Tuya as an example (Figure 5) Thecloud allows the user to control her devices through GoogleHome To delegate the privilege to Google Tuya implementsthe standard OAuth protocol (Section 2) the user on GoogleHome can enter her Tuya credentials and if she is allowedto access the device Tuya will forward an OAuth token toGoogle Home enabling her to control the device

To find out whether Tuyarsquos OAuth protocol can ensure se-cure delegation we inspected the OAuth specification [39] inour research and found that one of its recommended imple-mentation options which has been taken by Tuya actuallyviolates the transitivity property expected in IoT delegation(see Section 23) When a service gives an OAuth token to itsdelegatee service the token can be issued on behalf of either(1) the user who initiates the OAuth process (eg the userin Figure 5) or (2) the delegatee service (eg Google Homein Figure 5)2 In our study we found that Tuyarsquos implemen-tation of OAuth takes the second option which introduces aserious security risk Specifically after a Tuya user delegatesto Google her device access the OAuth token Tuya issues toGoogle is not on behalf of the user but in the name of GoogleAs a result when the userrsquos access right is revoked on theTuya cloud he can still access the device through GoogleHome using its OAuth token since the token from Tuyarsquosperspective is independent of the user so it will not be invali-dated when the userrsquos access right (which has already beendelegated out to Google) is taken away

Again this weakness can be exploited in the real worldeg by a malicious Airbnb guest (or property tenant) to retainunauthorized device access Specifically the administrator onthe Tuya cloud (eg an Airbnb host or property manager) del-egates device access to the user and later revokes the accessthrough the Tuya cloudrsquos management console However ifthe user has already strategically delegated his device access

2OAuth protocol specifies that ldquoOAuth 20 authorization framework en-ables a third-party application to obtain limited access to an HTTP serviceeither on behalf of a resource owner by orchestrating an approval interac-tion between the resource owner and the HTTP service or by allowing thethird-party application to obtain access on its own behalf [39]

to Google Home he will still be able to stealthily operate onthe devices through Google Home even after his access isrevoked by the Tuya cloudPoC exploit on Flaw 4 We conducted a PoC attack to exploitthe vulnerability As shown in Figure 5 we first delegated theaccess to a Tuya smart plug to a malicious Tuya user throughthe Tuya cloud Then the delegatee further gave his privilegeto his own Google Home account After the userrsquos accessright was revoked on the Tuya cloud he could still use hisGoogle Home app to control the plugDiscussion This problem was first discovered through a man-ual check of the Tuya delegation process which motivatedthis research This case inspired us that the cross-cloud dele-gation in IoT can introduce new risks compared to traditionalcross-website delegation scenarios due to the different appli-cation paradigm and security requirements For example in atraditional scenario when a user delegates access to her Face-book account to another Website via OAuth her Facebookaccount would be almost impossible to be revoked by anotherparty and thus the need to invalidate the OAuth token follow-ing a revocation of the userrsquos own Facebook access is lessprominent That is delegation transitivity (see Section 23)is a less prominent security risk there In contrast delegatingaccess to an untrusted user (eg an Airbnb guest or prop-erty tenant) and frequent access revocation in IoT context arecommonplace This requires IoT applications to appreciatedelegation transitivity when applying OAuth which howeveris less understood before

Philips Hue

cloud

delegate

Philips Hue

user

delegate

Whitelist ID

OAuth Token

Philips Hue

devices

delegatee cloud

Whitelist ID

OAuth TokenWhitelist ID

Figure 6 Insecure revocation of Philips Hue

Flaw 5 Abusing cross-cloud delegation API As men-tioned earlier IoT device vendorsrsquo clouds (device vendorcloud) allow the user to operate on her devices through eitherthe device vendor cloud or the delegatee cloud In our studywe found that an unauthorized user in the device vendor cloudcan abuse the delegation APIs provided to the delegatee cloudand get unauthorized device access as elaborated below

Philips Hue lets the device administrator (eg an Airbnbhost or property manager) delegate device access to anotherPhilips user (eg an Airbnb guest or property tenant) Forexample Figure 6 shows that the delegatee user is given ac-cess to a Philips Hue bridge Use of the Hue bridge can bedone through the delegatee userrsquos mobile app (1) he firstpresses a physical button on the device (to enable a bindingprocess) (2) the Philips app automatically fetches a secrettoken called whitelistID from the device through the localnetwork they are all connected to (3) the user then logs intohis Philips app to obtain an OAuth token from the Philipscloud With these two tokens the user can issue commands to

the Hue bridge through the Philips cloud The cloud checksthe OAuth token and forwards the commands to the devicewhich verifies whitelistID To revoke the delegatee userrsquosaccess (eg after the tenantguest checks out) according toits official documentation [30] Philips takes an easy path theadministrator just needs to go to her cloud console to removethe delegateersquos whitelistID As a result the delegateersquos fu-ture commands will be denied by the device since it alreadydrops his whitelistID

Although the Philips delegatee user apparently loses hisaccess to the device this revocation enforcement turned outto be incomplete even without whitelstID the delegateeuserrsquos account still remains on the devicersquos access list main-tained by the Philips cloud This may not be exploited ifwe look at the Philips cloud alone but allows the delegateeuser to re-obtain the access to the device by abusing PhilipsHuersquos cross-cloud delegation APIs which is another avenueto access the device

Specifically the Philips cloud has an API interface fordelegating device access to another IoT cloud allowing a userto remotely control Philips Hue devices from the delegateecloud For this purpose the user enters her Philips credentialsin the delegatee cloud which then calls Philips Hue clouddelegation API [28] this will return not only an OAuth tokenbut also a fresh whitelistID generated by the device whichbased on the Philips cloud-side access list is accessible tothe user With the two tokens the delegatee cloud can issuecommands to the Philips Hue cloud to operate the device(through Philips Hue remote control API [31]) Such a cross-cloud delegation mechanism can be utilized for an attackthe Philips delegatee user whose access has been revokedcan leverage a delegatee cloud (eg SmartThings see PoCexploit below) to still control the Philips device

PoC exploit on Flaw 5 In our attack we used SmartThingsas the delegatee cloud to gain the unauthorized access to ourPhilips Hue bridge In particular SmartThings allows us toupload a SmartApp to work with the Philips Hue cloud whichgives us a vantage point to observe the internal operationson the delegatee cloud side (eg what the delegatee can re-ceive from Philips) In our implementation of the SmartAppwe utilized the SmartThings service (eg the Web ServicesSmartApp [41]) to construct an OAuth client and registered aservice with Philips Hue to initiate the delegation process [27]By doing so our SmartApp successfully invoked Philips dele-gation APIs to obtain a fresh WhitelistID and OAuth tokenThis enabled us to get access to the Philips Hue bridge evenafter our access had been revoked on the device

Responsible disclosure We reported all the problems to re-lated parties eg Samsung SmartThings Tuya Philips Huewhich are taking serious actions to address them SmartThingsand Tuya have deployed a fix and Philips Hue confirmed thatthey will release the fix to our reported vulnerability in theirupcoming update

4 System Modeling and Formal Verification

In this section we elaborate on the design and implementationof VerioT our semi-automatic tool for detecting delegationflaws in real-world IoT clouds

41 OverviewAt a high level IoT delegation systems should ensure thatthe unauthorized delegatee user should not have a path toaccess IoT devices which he is not entitled to access To detectsecurity flaws in real-world delegation systems our approachis to model their delegation operations as a transition systemand leverages a model checker to verify whether pre-definedsecurity properties hold in the model The counterexamplesreported by the model checker indicate security flaws in theIoT cloud systems that are described by the model Alsothe flaws reported by VerioT are manually validated on real-world IoT clouds to confirm their presence

Model Generator

Promela Model

Security Property Counterexample

Analyzer

Flaw

ReportsConfiguration

Model

Checker

CounterexamplesDelegation

Operation

Templates

Database

IoT Delegation

Base Model

Figure 7 The architecture of VerioT

Architecture Since different clouds often support differentsets of delegation operations (eg either issuing an OAuthtoken or secret URL to its delegatee cloud or hosting APIsfor delegatee cloud to invoke etc) we cannot build a singleunified model that can describe any clouds and their corre-sponding delegation operations Hence our approach is tomodel each specific set of real-world clouds between whichdelegations can happen (eg LIFX cloud and SmartThingscloud in Figure 8) called a delegation setting (or dele-setting)The model of a dele-setting then goes through our modelchecker for flaw detection

To this end we built VerioT that includes 3 core compo-nents a model generator a model checker and a counterex-ample analyzer (or simply analyzer) as outlined in Figure 7More specifically model generator generates the model foreach dele-setting found in the real-world To this end modelgenerator takes as input a configuration file that lists theactors (the delegator and delegatee clouds user device) inthe dele-setting and delegation operations supported by theactors (eg issuing a new OAuth token) and generates a statemachine model for the dele-setting The model describes thestates of all actors (the clouds user etc) in the system anddelegation operations an actor can perform which triggersstate transitions an actor in a state records its set of data thathave been generated and transferred between actors due to

delegation operations eg an OAuth token it obtained fromits delegator through an OAuth operation (Section 42) Themodel is specified using the Promela language [32] ndash Promelamodels can be verified with the off-the-shelf model checkerSpin [38] that is used in our research (Section 43) Internallyto generate a model model generator leverages a generalbase model (with a few actors and basic types of delegationoperations specified in Promela language) and extends it byadding additional operations supported in the dele-setting tothe base model which are already modeled as a one-time ef-fort and stored in our delegation operation templates database(Section 42)

For detecting delegation flaws the model generated bymodel generator then goes through our model checker forverification with respect to pre-defined security properties(Section 43) Specifically model checker reports a counterex-ample if it can find a state that has an access path acrossactors in the system that enables an unauthorized user actorto reach the device actor More specifically since the statemachine model records the dataset each actor holds if a useractor holds a token (eg OAuth token) that is issued by acloud actor for accessing a device we consider the user hasan access path to access the device (via the cloud) no matterthrough what operations the user actor obtained the token (egthrough regular OAuth operation invocation of cloud delega-tion APIs etc) When the user actor is in a state following adelegation revocation operation while he still has a path tothe device model checker reports a counterexample Then thecounterexample is analyzed and manually confirmed throughproof-of-concept exploit (Flaw 1-3 and Flow 5 in Section 3)on real IoT clouds

OAuth share


un-OAuth un-share

SmartApp

LIFX (Connect)

bind

unbind

token smartthingstoken lifx

Figure 8 Delegations between LIFX and SmartThings

Example Here we take Flaw 3 (Section 32) as an example todescribe how our approach detects IoT delegation flaw In ourmodel of dele-setting for LIFX and SmartThings (outlined inFigure 8) each actor is specified in Promela language as a vari-able (eg LIFX_bulb LIFX_cloud SmartT hings_cloudSmartT hings_user see section 44) each delegation opera-tion is represented by a function that can be called on the actorvariable(s) eg actor LIFX_cloud can perform OAuth oper-ation with actor SmartT hings_cloud which generates a newtoken tokenli f x and gives it to the latter actor for a state tran-sition a non-deterministic choice is made to randomly chooseone operation to execute In the state machine model afterthe userrsquos access is revoked by SmartThings cloud throughthe revocation operation (un-share in Figure 8) the checkerverifies the current state using our security property ndash heshould not have an access path to reach the device (see theformal definition of security property in Section 43) To this

end the checker inspected the data each actor in the currentstate holds and found a counterexample the user actor holdsa token issued by LIFX cloud (ie OAuth token tokenli f x)which he obtained from reading the storage of LIFX Smar-tApp (in SmartThings) in a previous state (before his accessis revoked) such a token allows the user whose access righthas been revoked on SmartThings cloud to still access thedevice through LIFX cloud

42 Modeling IoT Delegation

The state machine model We model IoT delegation as astate machine M = (A S O T s0) Here A is the set of actors(clouds devices users) S is a set of states in each of which anactor can perform a delegation related operation (eg issuingan OAuth token to another actor invoking an API) eachstate records the data that each actor holds (eg an OAuthtoken device ID etc obtained through delegation operations)and the access control list if the actor maintains one s0 (s0isin S ) is the initial state where no delegation operation hasbeen performed in the system O is a finite set of delegationrelated operations (eg OAuth ndash issuing an OAuth token seedefinition below) T is a transition function that drives thesystem to transit from one state to the next

Specifically for each actor ai (ai isin A) we use two datasets Recvai and Issuai to record the tokens ai received (fromits delegators) and issued (to its delegatees) during delega-tion operations respectively For example when ai issues anOAuth token to a j during an OAuth operation the token willbe recorded in both Issuai and Recva j Further each cloudactor in M maintains an access control list ie a relationthat maps the tokens it issues and the tokens it receives Forexample the SmartThings cloud (see Figure 8) sends out atoken (tokensmartthings) to the user which is mapped to thetoken SmartThings receives from the LIFX cloud (tokenli f x)for accessing a certain LIFX bulb intuitively when the userpresents tokensmartthings to the SmartThings cloud to accessthe bulb based on the mapping only if tokensmartthings ismapped to the tokenli f x ndash an access control check ndash will theSmartThings cloud forward the access request to the LIFXcloud together with tokenli f x To model such access controlmapping maintained by ai we use a set ACLai which con-sists of a set of 2-tuple (tokenT ) where token isin Issuai andT isin P(Recvai)

3 intuitively for example the mapping fromtokensmartthings to tokenli f x indicates that the access rightrepresented by tokenli f x (the access right to the bulb dele-gated out by LIFX cloud) is delegated to tokensmartthings (bySmartThings cloud)

Def 1 State A state sk(sk isinS ) records each actorrsquos token

3P(x) is the power set of set x We use P(Recvai ) (versus Recvai ) since thecloud such as SmartThings can map a token it issued to its user to multipletokens it received from its delegator cloud (to access multiple devices in thedelegator cloud)

sets and ACL set sk =⋃

aiisinA Recvai Issuai ACLai among

which the initial state s0 =⋃

aiisinA emptyemptyempty

Def 2 Operation A delegation operation from ai to a j indi-cates ai grantsrevokes access right tofrom a j which implieschanges to their token sets and ACL sets For example theOAuth operation (OAuth isin O) eg OAuth between the LIFXcloud (ai) and the SmartThings cloud (a j) in Figure 8 mod-eled as OAuth(aia jT ) performed by ai to delegate accessright T (T isin P(Recvai)) to a j is defined as

token = newOAuthToken()

Issuai = Issuai cup token Recva j = Recva j cup token ACLai = ACLai cup (tokenT )

Further ai may need to revoke the issued OAuth tokencorrespondingly the un-OAuth operation (un-OAuth isin O)modeled as un-OAuth(ai token) performed by ai to revoketoken token is defined as

Issuai = Issuai minus token ACLai = ACLai minus (tokenT ) | (tokenT ) isin ACLai

Altogether we modeled nine delegation operations as sum-marized in Table 1 (with their formal definitions in AppendixA)

Table 1 Summary of delegation operationsOperation Type Semantic Meaning

bind bind (register) a device to its vendor cloudunbind unbind the device from vendor cloud eg resetshare delegate an access to a user

un-share revoke an access of a userOAuth authorize another party through OAuth protocol

un-OAuth revoke an OAuth authorizationsetTrigger set a trigger-action rule

un-setTrigger remove the trigger-action ruleAPIRequest send API requests (eg Web API request)

Def 3 Transition T StimesO rarr S is a function that drivesthe transition from one state to the next For example T (siOAuth) = s j (where sis j isin S ) indicates that an OAuth opera-tion in state si drives the system to state s j

Generating models for different real-world dele-settingsBased on the model definition our model generator modelseach dele-setting and generates the model specified using thePromela language [32] Given the heterogeneous delegationmechanisms supported in different clouds and the large num-ber of dele-settings in the real world ndash for example the dele-gations from SmartThings to Google Home (Flaw 1) IFTTTto SmartThings (Flaw 2) and LIFX to SmartThings (Flaw 3)are all different dele-settings ndash manually modeling each dele-setting needs substantial human efforts To address this scal-ability problem model generator leverages an observationIoT cloudsrsquo delegation mechanisms are often comprised ofcommon basic types of operations such as issuingrevoking

a token givingremoving access to a user API requests thatcome with data exchange etc Hence to generate a model fora specific dele-setting model generator leverages a generalbase model and extends it by adding actors and delegationoperations supported in the dele-setting

Specifically the base model includes a minimum set of ac-tors (ie two devices a delegator cloud a delegatee cloud anda user) and delegation operations that trigger the state transi-tions As mentioned earlier (Section 41) the base model isspecified in the Promela language each actor is a variable andhas a corresponding dataset (including token set and ACL setsee Def 1) each operation is specified as a function that canbe called on the actor variable(s) which incurs changes to thedataset of the actors The extending process is facilitated byadding basic types of operations to the base model which areall modeled (one-time effort) and stored as template functionsin our delegation operation templates database it includesthe basic delegation operations (see Table 1) summarizedfrom 10 mainstream IoT clouds (see Section 5) Note thatthe same operation in two dele-settings eg share (denotingthat the cloud delegates an access to the user see Table 1)may incur different dataset changes to the actors in one shareoperation the cloud actor may issue a new token to the userand in the other the cloud actor may also pass along an exist-ing token obtained from its delegator cloud to the user (seeFlaw 3) In this case our template database keeps the twodifferent share operations respectively (as different templatefunctions) recorded as sub-types of share

Also as mentioned earlier the list of actors and operationsto add to the base model are specified in the configurationfile of a dele-setting The configuration file is built manu-ally after inspection of those cloudsrsquo delegation operationsSpecifically we look at the delegation operations supportedby the clouds and understand the data flows incurred by eachoperation (eg issuing a token to the user) This is done byreading their developer documentations user manuals andinspecting the network traffic of their mobile apps etc

43 Detecting Flaws

Formal verification With the generated models specifiedin Promela we leverage an off-the-shelf model checkerSpin [38] to verify the models on a generalized security prop-erty which we elaborate as follows

Def 4 Access Path An access path from a j to am is anordered sequence of actors v = (a ja1a2 anam) alongwhich a j can reach am if either n gt 0 and F(a jamv) 6= empty(see definition below) or n = 0 and Recva j cap Issuam 6=empty

f (KACLai) =⋃

tokenisinK(tokenT )isinACLai

t | t isin T

F(a ja1v) = f ( Recva j ACLa1)

F(a jakv) = f ( F(a jakminus1v) ACLak ) (2le k le n)

F(a jamv) = F(a janv)cap Issuam

Intuitively an access path allows a user to access a targetdevice through the delegation of other actors on the path ina special case n = 0 means the user can access the targetdevice directly using his token issued by the device Takingthe SmartThings-LIFX example above (Section 42) a user(a j) with the token tokensmartthings is allowed to access am(a LIFX bulb) along the path through two actors (the Smart-Things cloud and the LIFX cloud) given the tokens they issue(tokensmartthings and tokenli f x) and their ACL sets

To validate whether a j to am has an access path v weleverage F(a jamv) intuitively F(a jamv) yields the setof access rights that are delegated out by am through otheractors on the path and finally delegated to a j (representedby Recva j ) F(a jamv) 6= empty means a j has at least oneaccess right (represented by Recva j ) that allows to accessam Also note that f (KACLai) yields given a set of to-kens K the access rights of ai that are delegated to thereceiver of K Taking the SmartThings example againf (tokensmartthingsACLasmartthings) yields a set tokenli f xthat represents the right of SmartThings to access the bulbwhich is delegated by SmartThings to the user receiving thetoken set tokensmartthingsDef 5 Security Property Given a device am a user a jshould not find an access path that lets him access the devicethat he is not entitled to The property can be specified asRecva j cap Issuam = empty and forall v isin (a ja1a2 anam) | ak isin A minusa jam1le k le n n gt 0 F(a j amv) =empty

With respect to the property our model checker reportsa counterexample (security property violation) if it can findan access path across actors in the system that enables anunauthorized user actor to access the device actor Such adetection is performed when certain state transitions occur inthe system eg once a userrsquos access is revoked the checkerverifies whether he can still access the device

Analyzing the counterexamples Fully automated valida-tion of reported counterexample on real-world IoT cloudsis nontrivial since the end-to-end validation requires one toset up devices under those clouds register user accounts andperform delegation operations on the cloudsrsquo managementconsoles mobile apps and even through physically touch-ing the device etc So we manually validated the reportedcounterexamples by performing proof-of-concept end-to-endexploits on corresponding clouds (see PoC exploits in Sec-tion 3)

44 Implementation of VerioT

We provide implementation details of VerioT in this sectionits full source code and a video demo on its usage are releasedonline [34]bull The Delegate Operation Templates Database We inspecteddelegation operations supported on 10 mainstream IoT clouds(SmartThings IFTTT Google Home Wink Amazon Alexa

Philips Hue LIFX August MiHome iHome) and generalizednine basic types of operations such as OAuth share (seeTable 1) Each operation also incurs data changes to the actorsin the states eg OAuth operation performed by a delegatorwill generate a token held by both delegator and delegateeactors in their storage In our implementation each basicoperation is represented as a template function using Promelalanguage Different sub-types of an operation (see Section 42)has separate template functions indexed in the TemplatesDatabase by the operation name and template number Alltemplate functions in the templates database are releasedonline [25]bull The Configuration file and the Model Generator TheConfiguration file lists actors in the dele-setting opera-tions supported by the actors (with reference to the opera-tionsrsquo template code in the database) and optionally listsmore actors (eg additional clouds and devices) that the dele-setting involves but missing in the base model An exampleconfiguration (for the dele-setting of LIFX and SmartThings)is illustrated in Figure 9 It lists five actors (Line 1-6) anddelegation operations supported by each actor (Line 8-17)for example delegatee cloud LIFX can perform share opera-tion with the user whose template function is referenced inthe templates database (by share_template2) The modelgenerator takes the Configuration file as input constructsactors and their storage (token set and ACL set see Def1) in Promela language then based on the operations eachactor supports pulls template functions from the templatesdatabase to generate a model represented in Promela codeThe generator is implemented in Python with 1000 lines ofsource code The generated models of each dele-setting in ourresearch (in Promela code) and all configuration files used togenerate the models are released online [40]

Figure 9 Configuration file example

45 Results and DiscussionWe applied VerioT to assess the security of 10 mainstream

IoT clouds (see Section 5) for their cross-cloud delegationand identified 6 new delegation flaws (including flaws ofMiHome and Wink in Section 5 Flaw 1-3 and 5 in Section 3)affecting all the ten clouds We manually confirmed all theflaws and implemented end-to-end PoC attacks using realdevices of ours for five of the flaws The measurement details

on these flaws are presented in Section 5

Discussion of limitation and coverage As mentioned ear-lier (Section 42) constructing a Configuration file in ourstudy involves manual efforts to understand the target systemie delegation operations it supports and data set changesthey incur (eg token set see Def 1) To this end we readtheir developer documentation and user manuals to learn suchinformation based on the devices we have we also manuallyperformed those delegations operations and monitored thenetwork traffic of the companion mobile apps (for each dele-setting in Section 3 we used a few devices discussed in thePoC attacks) The construction of a Configuration took 5to 30 hours in our study (based on the length of the documen-tation and the number of supported delegation operations inthe dele-setting)

In the absence of a standardized and well specified delega-tion protocol for IoT clouds we may not know all informationof a particular cross-cloud delegation system (all delegationoperations it supports all datatoken flows incurred by thedelegation operations and internal access list the cloud main-tains etc) Similar to the prior work [55] our strategy is tostart with a simple model and introduce additional complexityinto the model if no counterexamples are found Specificallywe progressively add more operations and their correspondingdata flows to the model along the way we understand the cor-responding systemrsquos operations until the model is completeenough to report a flaw

Also the access management and delegation-related opera-tions on real-world IoT cloud systems can be very complexHence in some cases we need to abstract the real-world sys-tems so as to start with a relatively simple model before wecan progressively enrich the model to better approximate thereal systems In particular we focus on the delegation opera-tions and look for all possible avenues where tokens can betransferred and shared between actors (eg programmaticWeb API calls and manual Web console access ndash both ab-stracted and modeled as APIRequest operation) and ignorecomplex usage contexts (eg whether it is programmatic ormanual Web access SmartThingsrsquo location etc) Let us takeFlaw 1 as an example Although SmartThings device ID isa security token only under certain usage context (ie it isa security token in trigger-action based device access butnot in direct device access see Section 31) in our modelof SmartThings-Google Home dele-setting we made an as-sumption to ignore the usage contexts and simply consideredSmartThings device ID as a security token that can be usedto access the device Further as we studied Google Homedocumentation and looked at the network traffic of GoogleHome mobile app we learnt that Google Home cloud trans-ferred the SmartThings device ID to the user-end app whensharing with him the access to the SmartThings device cor-respondingly in our modeling the user actor will add theSmartThings device ID to his token set once Google Homeperforms a share operation (see Table 1) with the user actor

Based on the model when our checker Spin enumerates allpossible states by running different delegation operations (im-plemented as functions in Promela language) it found thatthe user actor had an access path to the SmartThings device(via SmartThings cloud) based on the device ID he held in histoken set even after Google Home performed an un-shareoperation to revoke the userrsquos access to the device Note thatin our modeling of the un-share operation Google Homewill only revoke any token it generated and shared with theuser but will not revoke the SmartThings device ID ndash this isbecause we did not find any APIs or mechanisms provided bySmartThings for doing so based on public documentationsLast as mentioned earlier the bug found in the verificationprocess was then confirmed through PoC experiments usingour real devices

In the absence of a standardized IoT delegation protocol al-though we may not have full information of a particular cross-cloud delegation system (all delegation operations it supportsits internal access management etc) our approach has demon-strated its feasibility in identifying delegation weaknesseswith public information of those systems Also real-worldIoT vendors with full information about their delegation pro-tocols and operations can use our approach and tool to verifytheir systems

Last VerioT facilitates automatic search on all possiblestates in the model under the constraints of the search depthset for SPIN 20000 in our experiment Note that a delegationsystem with just a few actors can have hundreds or eventhousands of states considering the operations in differentorders among the actors which are hard to inspect manually

5 Measurement

51 Prevalence of Vulnerable Delegation

With the help of VerioT we evaluated the security risks inaccess delegation of 10 mainstream IoT clouds includingboth device vendor clouds ndash delegator clouds ndash and delegateeclouds

Device vendor clouds We evaluated 5 mainstream devicevendor clouds Philips Hue [26] August [8] LIFX [17] Mi-Home [21] and iHome [14] who collectively have millionsof users worldwide [9 15 18 22 29] It turned out all theseclouds are either vulnerable themselves or delegate deviceaccess to a vulnerable delegatee cloud (eg Google HomeSmartThings etc see below)

Of particular concern observed here is that those cloudstypically developed their customized often ad-hoc delegationmanagement which highlights the heterogeneous problem-atic IoT delegation ecosystem in the absence of a standardsecure delegation protocol Flaw 5 is one example of such Asanother example (Flaw 6) we found MiHome cloud delegatestwo tokens ndash one token generated by the cloud and one secretstring generated by the device ndash to its delegatee user when

MiHome revokes the delegatee userrsquos access it invalids thetoken on the cloud but does not inform the device to inval-idate the secret string Through our end-to-end experimentusing our own device we found this flaw introduces securityrisks in the real world scenario even after the delegatee userrsquosaccess is revoked (eg after an Airbnb guest checks out) aslong as he can still connect to the local network where thedevice connects to (eg by going close to the Airbnb house)he can use the secret string as a token to command the deviceSuch a device under MiHome cloud can be a door lock thatcan let the unauthorized user enter the house Further VerioTdid not report any flaws on August or iHome clouds Howevertheir devices can be registered to SmartThings and therebypotentially affected by Flaw 1

Delegatee clouds VerioT also helped us evaluate popu-lar delegatee clouds Google Home [12] Samsung Smart-Things [33] IFTTT [13] Amazon Alexa [7] and Wink [42]It turned out that all of them are affected by insecure delega-tion management Specifically in addition to Flaw 1-3 thatindicate design faults of Google Home SmartThings andIFTTT we found another flaw in Wink cloud (Flaw 7) whois also confused with its delegator cloudsrsquo security policiesand unwittingly leak their device IDs to untrusted delegateeusers This presents a risk similar to Flaw 1 Further albeitVerioT did not report a flaw on Amazon Alexa it is affectedby Flaw 3 Alexa supports to delegate access to SmartThingscloud which was found to leak the delegatorrsquos token

52 Scope of ImpactIn our study we also measured the scope of the impacts bymajor security problems discussed in Section 3IoT clouds affected by Flaw 1 In Flaw 1 Google Homediscloses device ID of its delegator cloud (ie SmartThings)and an unauthorized delegatee user can leverage the obtaineddevice ID to impersonate device events and unlock a smartdoor on SmartThings With this flaw any delegator of GoogleHome is affected if device ID on its cloud serves as a se-cret token To better understand the scope of affected dele-gator clouds we manually inspected nine delegator cloudsand found that three of them use device ID as a secret tokenSmartThings TP-Link Kasa and elinkSmart (names of thenine clouds are released online [2]) We launched end-to-endattack against SmartThings (see PoC exploit on Flaw 1) Forother two clouds through inspecting their documentationsand prior works [52 76] that specified the functionality oftheir device IDs the problem is also alarming an attackermay leverage their device IDs to send fake device events onbehalf of the device and trigger other sensitive devices (egdoor locks) based on trigger rules on the two cloudsIoT clouds affected by Flaw 2 With Flaw 2 (Section 31) allvendors that delegate access to IFTTT are potentially affectedWe illustrate 34 IoT vendors (names released online [2]) thatdelegate access to IFTTT whose productsservices range from

smart lights (eg LIFX) to home security devices (eg Arlo)IoT clouds affected by Flaw 3 In Flaw 3 (Section 32)SmartThings cloud leaks the credential (eg OAuth token)stored by its delegator clouds in their SmartApps Thereforeany delegator cloud that stores sensitive informationtokenin its SmartApp is affected by Flaw 3 From 127 devicesvendors that delegate access to SmartThings (see the list re-leased online [2]) we manually reviewed their SmartApps thatare open-source (on SmartThingsrsquo official Github repository[36]) and found that 18 SmartApps (see the full list online [2])store sensitive information (eg OAuth token authenticationtoken secret callback URL etc) That is 18 correspondinglydelegator clouds of SmartThings are potentially affected byFlaw 3IoT clouds affected by Flaw 4 In Flaw 4 Tuya cloud in-troduced a security risk in applying OAuth to cross-cloudIoT delegation Interestingly we found that this single flawaffected many IoT vendors Specifically Tuya not only man-ufactures IoT devices itself but also provides its IoT cloudservices to other device vendors who do not own a cloudthemselves That is Tuya cloud serves as device vendor cloudfor devices manufactured by many other vendors Interest-ingly given such a paradigm all those vendors can be affectedby Flaw 1 on Tuya cloud (see a list of 58 affected IoT vendorsonline [2])Conflicting security policies across clouds As shown inSection 31 different clouds have conflicting security policiesand may not have an effective mechanism to coordinate theirsecurity assumptions and operations To better understandthe scope of the problem we inspected the developer doc-umentations of popular delegatee clouds including GoogleHome [11] Alexa [6] and Wink [43] We found that to offercross-cloud delegation services they all ask their delegatorclouds to provide device information including device IDname model version and type in the delegation processHowever based on available information none of them com-municated their security assumptions with delegator cloudsthey did not describe how they would handle the data (egGoogle Home exposed the device ID and caused Flaw 1)or requested information from their delegators to confirmwhether the data are security-sensitive Such a finding furthersuggests the general lack of coordinated security managementacross IoT clouds

6 Discussion and Future Work

Lessons learnt The most important lesson learnt from our re-search is the caution one should take when applying a customcross-cloud authorization scheme to todayrsquos already compli-cated IoT delegation In the absence of a standardized fullyverified cross-cloud delegation protocol there is no guaranteethat the new mechanism would not inadvertently bring in newsecurity flaws in policy setting or enforcement To be morespecific without fully understanding other partiesrsquo security

constraints or adequately informing other parties of their ownsecurity expectations there is a risk that the delegator and thedelegatee violate each otherrsquos security policies An equallycommon risk in IoT delegation is problematic security policyenforcement due to lack of rigorous verification

The risks reported in this paper affect scenarios of IoT ac-cess delegation which are common today For example anAirbnb host often needs to delegate the access to her doorlocks to Airbnb guests (for them to access the property) andrevoke the access later Convenient delegation of (the accessto) smart locks to Airbnb guests during their reservation pe-riod has been a prominent feature advocated by both Airbnband mainstream IoT vendors [3 4 5] including lock manu-facturers August Remotelock and AURMUR etcNew design principles To avoid such risks we propose threeprinciples for developing the delegation mechanism for indi-vidual IoT clouds before a consensus can be reached on astandardized solution

bull Communicating security assumptions and constraints Inad-equate coordination of security requirements cross the cloudsis one of the major causes for security hazards found in theheterogeneous IoT delegation The problem can be addressedby establishing a channel between clouds to exchange theirsecurity constraints and assumptions In particular all cloudsin a delegation should coordinate their security policies egwhen one cloud discloses tokensdata shared with or obtainedfrom another cloud it should be given (by the latter) the secu-rity implications in doing so To this end a formal descriptionof such information can be helpful This coordination effortcan also lay the foundation for the effort to standardize cross-cloud IoT delegation

bull Decoupling the delegatee and the delegator clouds Asshown in our research real-world IoT clouds have devel-oped heterogeneous and ad-hoc delegation protocols whichmade IoT clouds hard to decouple from each other and gettangled in othersrsquo access management for example IFTTTruns its SmartApps on SmartThings to help the latter man-age the access to IFTTT devices but gets into a positionthat can inadvertently violate the latterrsquos access policy Overthe longer term we envision that an IoT delegation protocolshould be standardized and verified with necessary securityrequirements and practice fully defined This addresses thefundamental cause of the flaws reported in the paper

bull Verifying delegation design whenever possible As demon-strated by our research formal verification of a real-worlddelegation mechanism can help reduce security risks Thesecurity property violations uncovered by a verification tooltuned for IoT like VerioT can help vendors identify weak-nesses in security policies and inadequate policy enforcementand thus lead to more secure IoT delegation ecosystem OurVerioT made a first step towards this end and further effortneeds to make to improve its efficacy

Compositional verification Modeling and verifying real-

world IoT delegation systems with many actors and opera-tions is complicated VerioT makes a first attempt towardsthis end though the model it verified is relatively small typ-ically involving two clouds and their supported operationsAnalysis of larger models needs compositional verificationwhich however cannot be provided by Spin the off-the-shelfmodel checker used in VerioT Other tools with the compo-sition capability [60 68] could potentially help us analyzemore complicated models Enhancement of our techniquewith these tools is left to our future research

Automated vulnerability detection Based on our under-standing of the security risks in cross-cloud IoT access dele-gation we believe that more automatic security analysis andvulnerability discovery are feasible With the help of VerioTwe were able to find the vulnerabilities reported in the paper ina semi-automatic way The manual effort in our current designwas made to capture the control flow and data flow of a delega-tion process to build its state machine which includes manualinspection of developer documentation analysis of communi-cation traffic on the related mobile app etc The knowledgediscovery part (inspecting documents) could be automatedusing Natural Language Processing (NLP) as did in the priorresearch on security analysis of payment services [53] Weenvision that significant effort will be seen on this subject

7 Related WorkIoT platform security Many works have been done to an-alyze security problems of the IoT Cloud considering theimportant role it plays [56] first reported the coarse-grainedcapability design and the insufficient protection in event sub-system of SmartThings platform [76] and [52] found flawsin device management of IoT clouds which both revealedthe serious consequences of leaking device identity [74]presented a system to discover inter-rule vulnerabilities onIFTTT In contrast our work attempts to understand the se-curity risks in cross-cloud IoT operations instead of identify-ing the flaws on a single IoT cloud Meanwhile extensiveworks [46 50 51 66 72 75] are proposed to protect IoT sys-tems For example [46 50 72] and [58] provided methodson protecting the informationdata flow As for permissionprotection [66] proposed a fine-grained context-based per-mission system In contrast we present a semi-automaticverification tool (VerioT) to conduct the first security analy-sis on the cross-cloud IoT access delegation process

Permission delegation in IoT Delegable authorization hasbeen well researched in the literature [47 48 49 67 70]Unlike the theoretic models and expressive languages ana-lyzed before access control on todayrsquos IoT clouds is not onlydistributed but also heterogeneous and ad-hoc To cope withnew application scenario [59] introduced Decentralized Ac-tion Integrity to prevent an untrusted trigger-action platformfrom misusing OAuth tokens[45] presented WAVE an autho-rization framework offering fully decentralized trust which

supports decentralized verification transitive delegation andrevocation etc WAVE fulfills the requirements of todayrsquoscomplicated IoT delegation and however requires all parties(different vendors) collaborate together following the sameframework API How to deploy a cryptographically ideal au-thorization framework (requiring storage servers auditorscryptographic functions) to real-world heterogeneous IoTenvironments that include diverse complicated applications(eg automation control trigger-action service) extremelylarge number of devices and even devices with extremely lowcomputing power (eg sensors) is not clear On the contrarywe conducted a systematic analysis of todayrsquos off-the-shelfIoT delegation and obtained in-depth understanding of itssecurity risks in real-world IoT systems Due to the absenceof standardized delegation protocol and a long time needed todeploy a standardized secure efficient effective protocol ourwork can lead to better understanding of todayrsquos IoT applica-tions and provide valuable insights towards standardizing apractical protocol

Model-based vulnerability discovery Prior works have at-tempted to automatically find vulnerabilities using fuzzingsymbolic execution formal verification etc [44 54 55 6364 65 71] [64] used a model-based approach to automat-ically discover the attacks in TCP congestion control and[55] identified new forms of idle port scan attack with thehelp of model checking [44] presented SmartVerif a noveland general framework that leverages dynamic strategy tosmartly search proof paths without human intervention Mostof these work focused on vulnerability discovery in a singlesystem or protocol while our work leveraged formal verifi-cation to (semi-)automate the security flaws discovered inthe IoT access delegation which involves multiple partiesdifferent protocols and heterogeneous systems

8 CONCLUSIONWe performed the first systematic study on security risks inthe cross-cloud IoT access delegation We proposed a semi-automatic verification tool to conduct an extensive investiga-tion of 10 leading IoT clouds Our research reveals new secu-rity vulnerabilities in IoT access delegation that are pervasivein IoT clouds Our findings suggest that the heterogeneousand ad-hoc delegation process is the root cause for such se-curity flaws Based on our new understanding on cross-cloudIoT access delegation we proposed new generalized designprinciples for mitigation Our new findings and understandingwill lead to better protection of todayrsquos IoT applications andprovide valuable insights towards securing IoT systems

Acknowledgment

We would like to thank our shepherd Dr Zakir Durumeric andthe anonymous reviewers for their insightful comments BinYuan Deqing Zou and Hai Jin are supported by the National

Natural Science Foundation of China (No 61902138) theChina Postdoctoral Science Foundation funded Project (No2018M640701) the National Key Research and DevelopmentPlan of China (No 2017YFB0802205) the Key-Area Re-search and Development Program of Guangdong Province(No 2019B010139001) and the Shenzhen Fundamental Re-search Program (No JCYJ20170413114215614) Yan Jia andYuqing Zhang are supported by the National Key RampD Pro-gram China (No 2018YFB0804701) the National NaturalScience Foundation of China (NoU1836210 No61572460)and in part by China Scholarship Council The authors of In-diana University are supported in part by Indiana UniversityFRSP-SF and NSF CNS-1618493 1801432 and 1838083

References[1] Actions on Google httpsdevelopersgooglecom

assistantsmarthomedevelopprocess-intents Ac-cessed 2019-11

[2] Affected Vendors httpssitesgooglecomviewshattered-chain-of-trust-underhomeaffected-vendorsauthuser=0s Accessed 2020-05

[3] Airbnb API httpswwwairbnbcompartner Ac-cessed 2020-05

[4] Airbnb Integration with August httpssupportaugustcomairbnb-integration-faq-B1YAULkC_z Accessed2020-05

[5] Airbnb Smart Locks httpswwwpostscapescomairbnb-smart-lock Accessed 2020-05

[6] Alexadiscovery interface httpsdeveloperamazoncomdocsdevice-apisalexa-discoveryhtml Ac-cessed 2019-11

[7] Amazon Alexa httpsdeveloperamazoncomen-USalexa Accessed 2019-11

[8] August httpsaugustcomproductsaugust-smart-lock-pro-connect Accessed 2019-11

[9] August Installs httpsplaygooglecomstoreappsdetailsid=comaugustluna Accessed 2019-11

[10] Get SmartApp Endpoints httpsdocssmartthingscomenlatestcapabilities-referencehtml Ac-cessed 2019-11

[11] Google assistant-process intents httpsdevelopersgooglecomassistantsmarthomedevelopprocess-intentssync-response Accessed 2019-11

[12] Google Home httpsdevelopersgooglecomassistantsmarthomeoverview Accessed 2019-11

[13] IFTTT httpsiftttcom Accessed 2019-11[14] ihome httpswwwihomeaudiocom Accessed 2019-11[15] iHome Installs httpsplaygooglecomstoreapps

detailsid=comsdiihomecontrol Accessed 2019-11[16] KEYGMA httpwwwkeygmacomenindexhtml Ac-

cessed 2020-05[17] LIFX httpswwwlifxcom Accessed 2019-11[18] LIFX Installs httpsplaygooglecomstoreapps

detailsid=comlifxlifx Accessed 2019-11[19] LIFX List Lights API httpsapideveloperlifxcom

docslist-lights Accessed 2019-11[20] LIFX Set State API httpsapideveloperlifxcom

docsset-state Accessed 2019-11[21] Mihome httpsxiaomi-micommi-smart-home Ac-

cessed 2019-11[22] MiHome Installs httpsplaygooglecomstore

appsdetailsid=comxiaomismarthome Accessed2019-11

[23] Mirai Attacks httpsgooglQVv89r Accessed 2019-11

[24] OAuth 20 httpsoauthnet2 Accessed 2019-11[25] Operation Templates in VerioT httpsgithubcom

VerioTVerioTtreemastertemplates Accessed2019-11

[26] Philips HUE httpswww2meethuecom Accessed2019-11

[27] Philips Hue Add new Remote Hue APIapp httpsdevelopersmeethuecomadd-new-hue-remote-api-app Accessed 2019-11

[28] Philips HUE API httpsdevelopersmeethuecomdevelophue-api Accessed 2019-11

[29] Philips Hue Installs httpsplaygooglecomstoreappsdetailsid=comphilipslightinghue2 Ac-cessed 2019-11

[30] Philips Hue Permission revocation httpswww2meethuecomen-ussupportapps-and-softwareHow_do_I_remove_an_unused_smart_device_from_my_Philips_Hue_system Accessed 2019-11

[31] Philips Hue Remote Control API httpsdevelopersmeethuecomdevelophue-apiremote-api-quick-start-guide Accessed 2019-11

[32] Promela httpsenwikipediaorgwikiPromela Ac-cessed 2019-11

[33] Samsung SmartThings httpswwwsmartthingscomAccessed 2019-11

[34] Shattered Chain of Trust Understanding Security Risksin Cross-Cloud IoT Access Delegation httpssitesgooglecomviewshattered-chain-of-trust-underhomeauthuser=1

[35] SmartApps httpsdocssmartthingscomenlatestsmartapp-developers-guide Accessed2019-11

[36] SmartThings Git httpsgithubcomSmartThingsCommunitySmartThingsPublic Accessed2019-11

[37] SmartThings Groovy IDE httpsgraphapismartthingscom Accessed 2019-11

[38] Spin httpspinrootcomspinwhatispinhtml Ac-cessed 2019-11

[39] The OAuth 20 Authorization Framework httpstoolsietforghtmlrfc6749 Accessed 2019-11

[40] VerioT Examples httpsgithubcomVerioTVerioTAccessed 2019-11

[41] Web Services SmartApps httpsdocssmartthingscomenlatestsmartapp-web-services-developers-guideindexhtml Accessed 2019-11

[42] Wink httpswwwwinkcom Accessed 2019-11[43] Wink api httpswinkapiv2docsapiaryio

referencedevice Accessed 2019-11[44] Smartverif Push the limit of automation capability of verifying

security protocols by dynamic strategies In 29th USENIXSecurity Symposium 2020

[45] Michael P Andersen Sam Kumar Moustafa AbdelBaky GabeFierro John Kolb Hyung-Sin Kim David E Culler andRaluca Ada Popa WAVE A decentralized authorization frame-work with transitive delegation In 28th USENIX SecuritySymposium pages 1375ndash1392 2019

[46] Iulia Bastys Musard Balliu and Andrei Sabelfeld If this thenwhat Controlling flows in iot apps In Proceedings of the2018 ACM SIGSAC Conference on Computer and Communi-cations Security pages 1102ndash1119 ACM 2018

[47] Elisa Bertino Elena Ferrari and Anna Squicciarini Trustnegotiations concepts systems and languages Computing inScience amp Engineering 6(4) 2004

[48] Arnar Birgisson Joe Gibbs Politz Uacutelfar Erlingsson AnkurTaly Michael Vrable and Mark Lentczner Macaroons Cook-ies with contextual caveats for decentralized authorization inthe cloud In 21st Annual Network and Distributed SystemSecurity Symposium 2014

[49] Matt Blaze Joan Feigenbaum and Jack Lacy Decentralizedtrust management In IEEE Symposium on Security and Pri-vacy pages 164ndash173 1996

[50] Z Berkay Celik Leonardo Babun Amit Kumar Sikder Hi-dayet Aksu Gang Tan Patrick McDaniel and A Selcuk Ulu-agac Sensitive information tracking in commodity iot In

27th USENIX Security Symposium (USENIX Security 18)pages 1687ndash1704 2018

[51] Z Berkay Celik Gang Tan and Patrick D McDaniel IotguardDynamic enforcement of security and safety policy in com-modity iot In NDSS 2019

[52] Jiongyi Chen Chaoshun Zuo Wenrui Diao Shuaike DongQingchuan Zhao Menghan Sun Zhiqiang Lin Yinqian Zhangand Kehuan Zhang Your iots are (not) mine On the re-mote binding between iot devices and users In 49th AnnualIEEEIFIP International Conference on Dependable Systemsand Networks pages 222ndash233 2019

[53] Yi Chen Luyi Xing Yue Qin Xiaojing Liao XiaoFeng WangKai Chen and Wei Zou Devils in the guidance Predictinglogic vulnerabilities in payment syndication services throughautomated documentation analysis In 28th USENIX SecuritySymposium pages 747ndash764 2019

[54] Chia Yuan Cho Domagoj Babic Pongsin PoosankamKevin Zhijie Chen Edward XueJun Wu and Dawn SongMACE model-inference-assisted concolic exploration for pro-tocol and vulnerability discovery In 20th USENIX SecuritySymposium 2011

[55] Roya Ensafi Jong Chun Park Deepak Kapur and Jedidiah RCrandall Idle port scanning and non-interference analysisof network protocol stacks using model checking In 19thUSENIX Security Symposium pages 257ndash272 2010

[56] Earlence Fernandes Jaeyeon Jung and Atul Prakash Securityanalysis of emerging smart home applications In 37th IEEESymposium on Security and Privacy pages 636ndash654 2016

[57] Earlence Fernandes Justin Paupore Amir Rahmati DanielSimionato Mauro Conti and Atul Prakash Flowfence Prac-tical data protection for emerging iot application frameworksIn 25th USENIX Security Symposium pages 531ndash548 2016

[58] Earlence Fernandes Justin Paupore Amir Rahmati DanielSimionato Mauro Conti and Atul Prakash Flowfence Prac-tical data protection for emerging iot application frameworksIn 25th USENIX Security Symposium (USENIX Security16) pages 531ndash548 2016

[59] Earlence Fernandes Amir Rahmati Jaeyeon Jung and AtulPrakash Decentralized action integrity for trigger-action iotplatforms In Proceedings 2018 Network and Distributed Sys-tem Security Symposium 2018

[60] Mihaela Gheorghiu Dimitra Giannakopoulou and Corina SPasareanu Refining interface alphabets for compositionalverification In 13th International Conference on Tools and Al-gorithms for the Construction and Analysis of Systems volume4424 pages 292ndash307 2007

[61] Weili Han Qun Ni and Hong Chen Apply measurable risk tostrengthen security of a role-based delegation supporting work-flow system In IEEE International Symposium on Policies forDistributed Systems and Networks pages 45ndash52 2009

[62] Grant Ho Derek Leung Pratyush Mishra Ashkan HosseiniDawn Song and David A Wagner Smart locks Lessons forsecuring commodity internet of things devices In 11th ACMAsia Conference on Computer and Communications Securitypages 461ndash472 2016

[63] Samuel Jero Xiangyu Bu Cristina Nita-Rotaru HamedOkhravi Richard Skowyra and Sonia Fahmy BEADS auto-mated attack discovery in openflow-based SDN systems In20th International Symposium on Research in Attacks Intru-sions and Defenses pages 311ndash333 2017

[64] Samuel Jero Md Endadul Hoque David R Choffnes AlanMislove and Cristina Nita-Rotaru Automated attack discov-ery in TCP congestion control using a model-guided approachIn 25th Annual Network and Distributed System Security Sym-posium 2018

[65] Samuel Jero Hyojeong Lee and Cristina Nita-Rotaru Lever-aging state information for automated attack discovery in trans-port protocol implementations In 45th Annual IEEEIFIP In-ternational Conference on Dependable Systems and Networkspages 1ndash12 2015

[66] Yunhan Jack Jia Qi Alfred Chen Shiqi Wang Amir Rahmati

Earlence Fernandes Zhuoqing Morley Mao Atul Prakash andShanghai JiaoTong Unviersity Contexlot Towards providingcontextual integrity to appified iot platforms In NDSS 2017

[67] Ninghui Li John C Mitchell and William H WinsboroughDesign of a role-based trust-management framework In IEEESymposium on Security and Privacy pages 114ndash130 2002

[68] Corina S Pasareanu and Dimitra Giannakopoulou Towards acompositional SPIN In the 13th International Workshop onModel Checking Software volume 3925 pages 234ndash251 2006

[69] Yoshiki Sameshima and Peter T Kirstein Authorization withsecurity attributes and privilege delegation Access controlbeyond the ACL Computer Communications 20(5)376ndash3841997

[70] Kent E Seamons Marianne Winslett Ting Yu Bryan SmithEvan Child Jared Jacobson Hyrum Mills and Lina Yu Re-quirements for policy languages for trust negotiation In 3rdInternational Workshop on Policies for Distributed Systemsand Networks pages 68ndash79 2002

[71] JaeSeung Song Cristian Cadar and Peter R Pietzuch Sym-bexnet Testing network protocol implementations with sym-bolic execution and rule-based specifications IEEE TransSoftware Eng 40(7)695ndash709 2014

[72] Yuan Tian Nan Zhang Yueh-Hsun Lin XiaoFeng WangBlase Ur Xianzheng Guo and Patrick Tague SmartauthUser-centered authorization for the internet of things In26th USENIX Security Symposium (USENIX Security 17)pages 361ndash378 2017

[73] Jacques Wainer Akhil Kumar and Paulo Barthelmess DW-RBAC A formal security model of delegation and revocationin workflow systems Inf Syst 32(3)365ndash384 2007

[74] Qi Wang Pubali Datta Wei Yang Si Liu Adam Bates andCarl A Gunter Charting the attack surface of trigger-actioniot platforms In Proceedings of the 2019 ACM SIGSAC Con-ference on Computer and Communications Security pages1439ndash1453 ACM 2019

[75] Qi Wang Wajih Ul Hassan Adam Bates and Carl GunterFear and logging in the internet of things In Network andDistributed Systems Symposium 2018

[76] Wei Zhou Yan Jia Yao Yao Lipeng Zhu Le Guan YuhangMao Peng Liu and Yuqing Zhang Discovering and under-standing the security hazards in the interactions between iotdevices mobile apps and clouds on smart home platforms In28th USENIX Security Symposium pages 1133ndash1150 2019

Appendix

A Definitions of the delegation operationsWe generalized nine basic types of delegation operations (seeTable 1) and constructed their operation templates in Promelalanguage (the Templates Database is released online [25])Note that one basic type of delegation operation may have afew sub-types (see Section 42) and correspondingly a fewoperation templates in the Templates Database We defineeach basic type of delegation operation as followsbind device ai issues a new token for cloud a jbind(aia j) is defined as

token = newUniqueToken()

Issuai = Issuai cup token Recva j = Recva j cup token

unbind device ai removes all the issued tokensunbind(ai) is defined as Issuai =empty

share cloud ai delegates access right T to user a j by issuinga new token and sharing the tokens the cloud received to theusershare(aia jT ) is defined as


Issuai = Issuai cup token Recva j = Recva j cup token cupRecvai

ACLai = ACLai cup(tokenT )un-share cloud ai revokes the access right from user a jby invalidating the token tokenun-share(ai token) is defined as

Issuai = Issuai minus token ACLai = ACLai minus(tokenT ) | (tokenT ) isin ACLai

OAuth cloud (ai) delegates cloud (a j) access right T byissuing a new tokenOAuth(aia jT ) is defined as



un-OAuth cloud (ai) revokes access right from cloud (a j)by revoking token tokenun-OAuth(ai token) is defined as


setTrigger cloud (ai) delegates cloud (a j) access rightT by issuing a new token and obtains read access right to thedevices that cloud (a j) has access tosetTrigger(aia jT ) is defined as


Issuai = Issuai cup token Recva j = Recva j cup token ACLai = ACLai cup (tokenT ) Recvai = Recvai cup ak | Recva j cap Issuak 6=emptyACLak =empty

un-setTrigger cloud (ai) does nothing to disable the itstriggersun-setTrigger(ai) is defined as None

APIRequest user (ai) makes API request to cloud (a j) toobtain all the tokens a j receivesAPIRequest(aia j) is defined asRecvai = Recvai cupRecva j

Introduction

Cross-cloud IoT Access Delegation

Background

Complexity in IoT delegation

Security Requirements

Threat model

Security of Cross-Cloud IoT Delegation

blackInadequate Cross-Cloud Coordination

blackInadequate Policy Enforcement

System Modeling and Formal Verification

Overview

Modeling IoT Delegation

Detecting Flaws

Implementation of VerioT

Results and Discussion

Measurement

Prevalence of Vulnerable Delegation

Scope of Impact

Discussion and Future Work

Related Work

CONCLUSION

that may not be compatible with those of other clouds andmay not have been properly verified For example the LIFXand IFTTT clouds delegate access to the SmartThings cloudthrough different protocols LIFX issues an OAuth token toSmartThings to access LIFX bulbs while IFTTT providesSmartThings a secret URL as a security token to access its de-vices (see Section 3) To work with these delegator clouds theSmartThings cloud runs a program from each of them that im-plements the corresponding protocol to enable SmartThingsto communicate with the devices on each delegator cloud1

Such a program allows the delegator to participate in furtheraccess management of the device for users on SmartThingscloud a security risk could arise however when the programis not fully compliant with SmartThingsrsquo security policies(Section 31) Given that a standard delegation protocol (suchas WAVE [45]) could take a long time to be adopted and de-ployed in the wild until all compatibility and usability issuesare resolved a systematic analysis of todayrsquos IoT delegationand in-depth understanding of its security risks are of criticalimportance This however has never been done before up toour knowledge

Findings In this paper we report the first attempt to analyzethe security weaknesses of real-world IoT access delegationand mitigate their potential threats to the IoT ecosystem Us-ing a semi-automatic verification tool we evaluated the dele-gation supports provided by 10 popular IoT clouds includingboth device vendors (Philips Hue LIFX iHome etc) andIoT cloud providers (IFTTT Amazon SmartThings Googleetc) Our study shows that device delegation on these cloudsis often vulnerable (Section 3) and can be exploited to gainunauthorized access to the victimrsquos devices or impersonatethe devices to perform unauthorized interactions with otherdevices The consequences of such attacks are serious rang-ing from completely losing control on the delegated accessrights on SmartThings (Section 32) to leaking sensitive de-vice IDs on Google Home that enables the attacker to unlockthe victimrsquos home door by spoofing events (Section 31)

Most importantly our research shows that the heteroge-neous and ad-hoc delegation processes in the wild have ledto conflicting delegation policies across IoT clouds Morespecifically under todayrsquos IoT cloud delegation model thedelegator and delegatee clouds are less decoupled than ex-pected and therefore need to be aware of each otherrsquos securityconstraints when determining their own delegation policiesAs mentioned earlier the SmartThings cloud delegated withaccess rights to a device requires the delegator cloud to uploada program aka SmartApp to help access the device fromthe delegator When SmartThings further grants to its usersthe access to the device however we found that a SmartApp

1Throughout the paper we call the party (an IoT cloud or the deviceowner) delegating access right to another party delegator and the recipientof the right delegatee Also we call a cloud with direct access to a devicedevice vendor cloud or simply vendor cloud (as it is typically operated bythe vendor)

not compliant with the delegation policies of SmartThings(eg the IFTTT SmartApp) exposes to the SmartThings usersthe privilege that SmartThings cannot revoke (Section 31)On the other hand SmartThingsrsquo access delegation to theGoogle Home cloud needs to go through Googlersquos interfacethat asks for both device ID and OAuth token Although de-vice ID is public for many IoT clouds (Belkin Philips Hueand MiHome) [52 76] it is an authentication token on Smart-Things [56] Unaware of this side effect Google Homersquospolicy of sharing SmartThings device ID with its users en-ables a malicious delegatee user to directly access devices onSmartThings cloud even after Google Home has revoked hisaccess to the device (Section 31) Such incomplete informa-tion of the other partyrsquos security policies and constraints turnsout to be a fundamental problem in todayrsquos IoT delegationmodel

Also an IoT cloud tends to directly adopt existing autho-rization protocols such as OAuth which however cannot meetall delegation requirements in the IoT environments (Sec-tion 32) Particularly we found that a malicious delegateeuser on the Tuya cloud can bypass its access control by strate-gically delegating his access to Tuya devices to another cloud(eg Google Home) and leveraging the latterrsquos OAuth tokento access the devices even after his access right has beenrevoked in the Tuya cloud ndash a violation of the transitivityproperty in delegation (Section 32) Also problematic is theheterogeneous and custom delegation protocols which of-tentimes did not go through a rigorous verification and aretherefore error-prone in their policy enforcement causingsecurity risks such as leaking the OAuth token to an unautho-rized party (Section 32)

Methodology Our security analysis was facilitated by a semi-automatic verification tool called VerioT which performsmodel checking for IoT delegation systems To this end wecame up with a simple generalized security property thatcaptures the requirements of IoT delegation Most challeng-ing here is to model different real-world delegation systemswhich requires manual effort to read developer documen-tations and user manuals of those IoT clouds and analyzecommunication traffic of their companion mobile apps tounderstand their delegation mechanisms and operations Toreduce such manual efforts we leverage the observation thatcross-cloud delegation can be described by combinations ofbasic types of delegation operations (Section 42) and cor-responding data flows such as OAuth token issuing whichare similar across different clouds This allows us to designa modeling approach involving a base delegation model thatoutlines the generic operations and data flows in a cross-clouddelegation and a set of templates for different basic types ofdelegation operations To describe a real-world delegationsystem one can directly use or customize existing templatesto refine the base delegation modelThe new model automati-cally produced by our tool is then verified against the securityproperty using Spin [38] an off-the-shelf model checker Any









IoT

Cloud

IoT

Cloud

IoT Devices

Device

Vendor

Cloud

IoT

Cloud

UserUser

register delegate

IoT

Cloud

IoT

Cloud

②①















24 Threat model










deviceID

Google Home cloud

August

smart lock


delegateOAuth

deviceID

SmartThings

switch

SmartThings

hub

SmartAPP






SmartThings


SmartApp

IFTTT

applet

IFTTT cloud

August

smart lock

SmartThings

switch

delegate delegate












OAuth delegate


OAuth Token

ID1 ID2 ID3

OAuth Token

ID1ID1

ID2

ID3 SmartApp

LIFX (Connect)








Tuya


delegate delegate

Tuya user

OAuth Token







Philips Hue

cloud

delegate

Philips Hue

user

delegate

Whitelist ID

OAuth Token

Philips Hue

devices

delegatee cloud

Whitelist ID













Model Generator

Promela Model


Analyzer

Flaw


Model

Checker


Operation

Templates

Database

IoT Delegation

Base Model






OAuth share


un-OAuth un-share

SmartApp

LIFX (Connect)

bind

unbind































43 Detecting Flaws



f (KACLai) =⋃


t | t isin T





















5 Measurement
























Acknowledgment
















































































Appendix




















Introduction


Background



Threat model





Overview


Detecting Flaws



Measurement


Scope of Impact


Related Work

CONCLUSION









IoT

Cloud

IoT

Cloud

IoT Devices

Device

Vendor

Cloud

IoT

Cloud

UserUser

register delegate

IoT

Cloud

IoT

Cloud

②①















24 Threat model










deviceID

Google Home cloud

August

smart lock


delegateOAuth

deviceID

SmartThings

switch

SmartThings

hub

SmartAPP






SmartThings


SmartApp

IFTTT

applet

IFTTT cloud

August

smart lock

SmartThings

switch

delegate delegate












OAuth delegate


OAuth Token

ID1 ID2 ID3

OAuth Token

ID1ID1

ID2

ID3 SmartApp

LIFX (Connect)








Tuya


delegate delegate

Tuya user

OAuth Token







Philips Hue

cloud

delegate

Philips Hue

user

delegate

Whitelist ID

OAuth Token

Philips Hue

devices

delegatee cloud

Whitelist ID













Model Generator

Promela Model


Analyzer

Flaw


Model

Checker


Operation

Templates

Database

IoT Delegation

Base Model






OAuth share


un-OAuth un-share

SmartApp

LIFX (Connect)

bind

unbind































43 Detecting Flaws



f (KACLai) =⋃


t | t isin T





















5 Measurement
























Acknowledgment
















































































Appendix




















Introduction


Background



Threat model





Overview


Detecting Flaws



Measurement


Scope of Impact


Related Work

CONCLUSION









24 Threat model










deviceID

Google Home cloud

August

smart lock


delegateOAuth

deviceID

SmartThings

switch

SmartThings

hub

SmartAPP






SmartThings


SmartApp

IFTTT

applet

IFTTT cloud

August

smart lock

SmartThings

switch

delegate delegate












OAuth delegate


OAuth Token

ID1 ID2 ID3

OAuth Token

ID1ID1

ID2

ID3 SmartApp

LIFX (Connect)








Tuya


delegate delegate

Tuya user

OAuth Token







Philips Hue

cloud

delegate

Philips Hue

user

delegate

Whitelist ID

OAuth Token

Philips Hue

devices

delegatee cloud

Whitelist ID













Model Generator

Promela Model


Analyzer

Flaw


Model

Checker


Operation

Templates

Database

IoT Delegation

Base Model






OAuth share


un-OAuth un-share

SmartApp

LIFX (Connect)

bind

unbind































43 Detecting Flaws



f (KACLai) =⋃


t | t isin T





















5 Measurement
























Acknowledgment
















































































Appendix




















Introduction


Background



Threat model





Overview


Detecting Flaws



Measurement


Scope of Impact


Related Work

CONCLUSION









deviceID

Google Home cloud

August

smart lock


delegateOAuth

deviceID

SmartThings

switch

SmartThings

hub

SmartAPP






SmartThings


SmartApp

IFTTT

applet

IFTTT cloud

August

smart lock

SmartThings

switch

delegate delegate












OAuth delegate


OAuth Token

ID1 ID2 ID3

OAuth Token

ID1ID1

ID2

ID3 SmartApp

LIFX (Connect)








Tuya


delegate delegate

Tuya user

OAuth Token







Philips Hue

cloud

delegate

Philips Hue

user

delegate

Whitelist ID

OAuth Token

Philips Hue

devices

delegatee cloud

Whitelist ID













Model Generator

Promela Model


Analyzer

Flaw


Model

Checker


Operation

Templates

Database

IoT Delegation

Base Model






OAuth share


un-OAuth un-share

SmartApp

LIFX (Connect)

bind

unbind































43 Detecting Flaws



f (KACLai) =⋃


t | t isin T





















5 Measurement
























Acknowledgment
















































































Appendix




















Introduction


Background



Threat model





Overview


Detecting Flaws



Measurement


Scope of Impact


Related Work

CONCLUSION


SmartThings


SmartApp

IFTTT

applet

IFTTT cloud

August

smart lock

SmartThings

switch

delegate delegate












OAuth delegate


OAuth Token

ID1 ID2 ID3

OAuth Token

ID1ID1

ID2

ID3 SmartApp

LIFX (Connect)








Tuya


delegate delegate

Tuya user

OAuth Token







Philips Hue

cloud

delegate

Philips Hue

user

delegate

Whitelist ID

OAuth Token

Philips Hue

devices

delegatee cloud

Whitelist ID













Model Generator

Promela Model


Analyzer

Flaw


Model

Checker


Operation

Templates

Database

IoT Delegation

Base Model






OAuth share


un-OAuth un-share

SmartApp

LIFX (Connect)

bind

unbind































43 Detecting Flaws



f (KACLai) =⋃


t | t isin T





















5 Measurement
























Acknowledgment
















































































Appendix




















Introduction


Background



Threat model





Overview


Detecting Flaws



Measurement


Scope of Impact


Related Work

CONCLUSION





OAuth delegate


OAuth Token

ID1 ID2 ID3

OAuth Token

ID1ID1

ID2

ID3 SmartApp

LIFX (Connect)








Tuya


delegate delegate

Tuya user

OAuth Token







Philips Hue

cloud

delegate

Philips Hue

user

delegate

Whitelist ID

OAuth Token

Philips Hue

devices

delegatee cloud

Whitelist ID













Model Generator

Promela Model


Analyzer

Flaw


Model

Checker


Operation

Templates

Database

IoT Delegation

Base Model






OAuth share


un-OAuth un-share

SmartApp

LIFX (Connect)

bind

unbind































43 Detecting Flaws



f (KACLai) =⋃


t | t isin T





















5 Measurement
























Acknowledgment
















































































Appendix




















Introduction


Background



Threat model





Overview


Detecting Flaws



Measurement


Scope of Impact


Related Work

CONCLUSION


Tuya


delegate delegate

Tuya user

OAuth Token







Philips Hue

cloud

delegate

Philips Hue

user

delegate

Whitelist ID

OAuth Token

Philips Hue

devices

delegatee cloud

Whitelist ID













Model Generator

Promela Model


Analyzer

Flaw


Model

Checker


Operation

Templates

Database

IoT Delegation

Base Model






OAuth share


un-OAuth un-share

SmartApp

LIFX (Connect)

bind

unbind































43 Detecting Flaws



f (KACLai) =⋃


t | t isin T





















5 Measurement
























Acknowledgment
















































































Appendix




















Introduction


Background



Threat model





Overview


Detecting Flaws



Measurement


Scope of Impact


Related Work

CONCLUSION









Model Generator

Promela Model


Analyzer

Flaw


Model

Checker


Operation

Templates

Database

IoT Delegation

Base Model






OAuth share


un-OAuth un-share

SmartApp

LIFX (Connect)

bind

unbind































43 Detecting Flaws



f (KACLai) =⋃


t | t isin T





















5 Measurement
























Acknowledgment
















































































Appendix




















Introduction


Background



Threat model





Overview


Detecting Flaws



Measurement


Scope of Impact


Related Work

CONCLUSION



OAuth share


un-OAuth un-share

SmartApp

LIFX (Connect)

bind

unbind































43 Detecting Flaws



f (KACLai) =⋃


t | t isin T





















5 Measurement
























Acknowledgment
















































































Appendix




















Introduction


Background



Threat model





Overview


Detecting Flaws



Measurement


Scope of Impact


Related Work

CONCLUSION





















43 Detecting Flaws



f (KACLai) =⋃


t | t isin T





















5 Measurement
























Acknowledgment
















































































Appendix




















Introduction


Background



Threat model





Overview


Detecting Flaws



Measurement


Scope of Impact


Related Work

CONCLUSION


















5 Measurement
























Acknowledgment
















































































Appendix




















Introduction


Background



Threat model





Overview


Detecting Flaws



Measurement


Scope of Impact


Related Work

CONCLUSION




















Acknowledgment
















































































Appendix




















Introduction


Background



Threat model





Overview


Detecting Flaws



Measurement


Scope of Impact


Related Work

CONCLUSION























































Appendix




















Introduction


Background



Threat model





Overview


Detecting Flaws



Measurement


Scope of Impact


Related Work

CONCLUSION

shattered chain of trust: understanding security risks in cross...

Documents