Risk-Based Permission Model for Smart Homes
Smart homes offer convenience and efficiency but also present security risks. The Tyche risk-based permission model addresses vulnerabilities in smart home platforms, emphasizing the importance of balancing security and usability. By grouping device operations based on risk levels, such as fire hazard or burglary risk, a middle-ground permission model can enhance security without sacrificing user experience. Measuring user-perceived risk plays a key role in empowering smart home platform builders to enhance security effectively.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Tyche: A Risk-Based Permission Model for Smart Homes Amir Rahmati, Earlence Fernandes, Kevin Eykholt, Atul Prakash
Smart Homes Are Useful, But Pose Security Risks Attacks at all layers of the stack Convenience, safety, energy efficiency, Devices Protocols Platforms 2
The Perils of Permission Models in Homes Smart home platforms run apps, like everything else today Design flaws in the permission models lead to attacks through misuse of permissions or overprivilege Fernandes et al., S&P 2016 (SmartThings), Fernandes et al., NDSS 2018 (IFTTT) Example attacks A door locker app that can unlock doors at any time A battery monitor that snoops on pincodes A remote control app that leaks occupant movement patterns, 3
Permission Model Spectrum Increasing Security Increasing Usability Single Group Functional Groups No Groups Devices Oven Doorlock Oven Doorlock set_temp(V) lock() set_temp(V) off() lock() unlock() set_temp(V) off() lock() unlock() off() unlock() Permission-Req Permission-Req Permission-Req Permission-Req App App App Is there a secure and usable middle-ground in the context of smart homes? 4
Intuitive Risk Asymmetry in Device Operations Fire hazard set_temp(V) off() How do we measure risk? Uncooked food How can we group operations in terms of risk, and then enforce it? Burglary risk unlock() lock() Annoyance Does risk-grouping strike a reasonable balance in security and usability? Privacy risk on() off() Disabled functionality 5
Step 1: Approximating User-Perceptions of Risk 6
Measuring Risk Goal: Empower builders of smart home platforms with a process estimate user-perceived risk with a process to Strawman: Run a user-study with real end-users every time a new a new device is released Challenges: Does not scale well (time, cost) Depending on the population, perceptions of risk might vary 7
Domain Expert Ratings Gather domain experts, and run a study 1 Not Concerned Imagine you have several apps installed in your home automation system. These apps require certain permissions and can perform actions on your behalf. For each action, indicate your level of concern based on a scale of 1 to 5 2 Mildly Concerned 3 Concerned N=3 67 types of devices 146 commands + attributes 4 Very Concerned 5 Would Not Allow But, do these ratings approximate user perceptions? 8
End-User Ratings Same task as before, but each user presented with half of device operations (we obtained 100 ratings per device op) Two groups (Mechanical Turk) Uninformed (N=200): Provided with operational description only Informed (N=200): Provided with operational description + misuse scenario Device Device Operational Description Operational Description Misuse Scenario Misuse Scenario Publicly share if sound is there. If there aren t any sounds, its probably that the home is unoccupied Tracks if there is sound in the environment Sound Sensor Unlock the door automatically or by user command Automatically unlock doors without your knowledge Door Lock 9
End-User Population Characteristics Filtered for random clickers using Pearson s Xi-square test N = 116 (uninformed) and 94 (informed) after filtering Approx. 30% of our population had smart homes (SmartThings, Google Home, Amazon Alexa) Of those, users of SmartThings had multiple apps Number of Apps Number of Apps < 5 < 5 5 5 10 10 > 10 > 10 % of SmartThings Users 48% 43% 9% 10
Do Expert-Ratings Approximate End-Users? Co-relation between (Pearson s r): Experts and Uninformed End-Users: 0.6 (moderate) Experts and Informed End-Users: 0.75 (strong) 0.75 (strong) Informed end-users and domain experts have co-related perceptions of risk for device operations! Smart home platform developers can use domain experts to assign risk ratings to device operations 11
Step 2: Computing Risk-Based Groupings 12
From Risk-Ratings to Risk-Groups How many groups (levels)? Too many groups -> too many permission prompts Too few groups -> overprivilege In this paper, we experiment with 3: low, medium, high How to form groups? We use k-means, with k=3 Risk Groups Risk Groups Low Low Medium Medium High High 62 58 26 Domain Expert (1 1.83) (1.84 2.83) (2.84 5) 13
Step 3: Enforcing Risk-Based Permissions 14
Enforcement Techniques - Rewriting Current app developer view input battery_dev , capability.battery Generate a permission prompt for the user If the user gives access, my API to the device is through this variable I want access to a device that has batteries Tyche view lowRiskRequest input battery_dev , capability.battery Identical, with extra annotation specifying risk level 15
Enforcement Techniques - Rewriting Device Device Operation Operation Risk Risk Annotated App Source Code Battery BattLevel Low DevA OpA Med AST Transform lowRiskRequest Input battery_dev , capability.battery . print battery_dev.BattLevel App Is op low risk? Risk-Table Ref-Monitor YES, allow, else NO, deny 16
Enforcement Techniques - Components We could have components corresponding to risk levels instead of functions! The new SmartThings infrastructure will take care of enforcement automatically 17
Applying Risk-Based Permissions to Apps Functional Grouping Functional Grouping Risk Risk- -Based Model Based Model App App Permissions Permissions Accessible Ops Accessible Ops Permissions Permissions Accessible Ops Accessible Ops Attrs Attrs: : lock, contact Cmds Cmds: : lock(), unlock() lock, lock.medRisk, contactSensor.lowRisk Attrs Attrs: : contact Cmds Cmds: : lock() LockDown contactSensor Attrs Attrs: : alarm, smoke Cmds Cmds: : off(), strobe(), both(), siren() Attrs Attrs: : alarm, smoke Cmds Cmds: : strobe(), siren(), both() alarm, smokeDet alarm.medRisk, smokeDet.medRisk SmokeProtector Attrs Attrs: : power, switch Cmds Cmds: : on(), off() Attrs Attrs: : power, switch Cmds Cmds: : on(), off() powerMeter, switch powerMeter.medRisk, switch.highRisk EnergySaver 18
Conclusion Like any other software system, permission models for smart homes lie on a spectrum The point chosen in the spectrum can lead to attacks, or to poor usability Physical devices exhibit intuitive risk asymmetry intuitive risk asymmetry We can measure risk using a study with domain experts Risk perceptions of domain experts co experts co- -related with informed end We analyzed 3 apps using the risk-based model, and show that they can remain functional, with 60% less access to high-risk operations We have laid a foundation and design process for future smart home permission models related with informed end- -users users 19
Tyche: Risk-Based Permissions for Smart Homes Like any other software system, permission models for smart homes lie on a spectrum The point chosen in the spectrum can lead to attacks, or to poor usability Physical devices exhibit intuitive risk asymmetry intuitive risk asymmetry We can measure risk using a study with domain experts Risk perceptions of domain experts co experts co- -related with informed end We analyzed 3 apps using the risk-based model, and show that they can remain functional, with 60% less access to high-risk operations We have laid a foundation and design process for future smart home permission models Earlence Fernandes, earlence.com, earlence@cs.washington.edu related with informed end- -users users 20
