Towards Towards Secure Secure and and Relia liable Io IoT Applica - - PowerPoint PPT Presentation

Towards Towards Secure Secure and and Relia liable Io IoT Applica Applicatio ions

Gang Gang Tan, Tan, CSE, CSE, Penn Penn State State

Nov 15th, 2019 @ 2nd IoT Security and Privacy Workshop

Internet of Things (IoT) enables the future

Smart Homes

Source: Samsung

Healthcare

Source: John Hopkins

Smart Energy

Source: LG

Smart Farms

Source: Microsoft

2

Connected Connected devic devices

IoT is not magic

Mobile bile app app

IoT IoT ap

applic licatio ion Autom Automation tion

Power Consumption 30% saving With no smart With smart Usage/ month

IoT enables the future (and a whole lot of problems)

3

Many of these failures are traditional security problems: So Softw ftware re bugs, bugs, user user erro errors, rs, poor poor co configuratio iguration, or

• r faulty

faulty desi design gn

4

IoT app interaction (via the physical world)

• fire ‐> sprinkler activation ‐> water leak detection ‐> shut off water valve ‐> no

water for sprinkler!

• Problem: the interaction between IoT apps cause unreliability and insecurity.

If water leak detected, then shut off main water valve

wa water ter‐le leak‐de detector tector app app

If smoke detected then sound alarm, and if also excessive heat detected, activate sprinkler

sm smoke‐alar alarm app app

IoT app interaction: another example

5

Heater‐control app: time at 6pm ‐> turn the heater on ‐> temperature rise Temp‐control app: open the window, when temp > 80 ℉

* Example by Ding & Hu [CCS 2018]

In this talk…

How to in incre crease se securi security and and reliability reliability of IoT Apps and their interaction?

6

IoT IoT Safety Safety and and Security Security

Saint: Sensitive Information Tracking in Commodity IoT [USENIX Security, 2018] Z. Berkay Celik, Leo Babun, Amit Sikder, Hidayet Aksu, Gang Tan, Patrick McDaniel, and Selcuk Uluagac

IoT IoT Pri Privac acy

IoTGuard: Dynamic Enforcement of Safety and Security Policy in Commodity IoT [NDSS, 2019] Z. Berkay Celik, Gang Tan, and Patrick McDaniel Soteria: Automated IoT Safety and Security Analysis [USENIX Annual Technical Conference, 2018] Z. Berkay Celik, Patrick McDaniel, and Gang Tan IotRepair: Systematically Addressing Device Faults in Commodity IoT [Ongoing work] Michael Norris, Z. Berkay Celik, Prasanna Venkatesh, Shulin Zhao, Gang Tan, Patrick McDaniel, and Anand Sivasubramaniam

IoT IoT Fault Fault Tol Toleran rance

Surv Surveys: s:

Program Analysis of IoT Applications for Security and Privacy: Challenges and Opportunities [ACM Computing Surveys, 2019] Z. Berkay Celik, Earlence Fernandes, Eric Pauley, Gang Tan, and Patrick McDaniel Verifying Internet of Things Safety and Security in Physical Spaces [IEEE S&P magazine, 2019] Z. Berkay Celik, Patrick McDaniel, Gang Tan, Leo Babun, Salcuk Uluagac

Collaborators

• Other collaborators

Penn State: Prasanna Venkatesh, Shulin Zhao, and Anand Sivasubramaniam Florida International University: Leo Babun, Amit Sikder, Hidayet Aksu, and Selcuk Uluagac

7

Patrick McDaniel

(Penn State)

• Z. Berkay Celik

(Penn State ‐> Purdue)

Michael Norris

(Penn State)

Agenda

Soteria

8

Automated IoT Safety and Security Analysis

* Greek goddess protecting from harm

9

[U [USE SENIX ATC ATC 2018] 2018]

Soteria*

Soteria

• Soteria performs model

del checki hecking on IoT apps to see whether they conform to a set of safety/security properties

Soteria

Problem: IoT platforms cannot evaluate whether an IoT app or a collection of apps is safe, secure, and operates correctly

10

From IoT apps to finite‐state machines

IoT IoT environm environmen ent

temp>135°F smoke

S1:alarm‐on S0:alarm‐off

S1 S0 S2

S2: water valve on and sprinkler active

Sm Smok

• ke‐Ala

Alarm

S0

water leak

S1:water valve closed S0:water valve on

S1

Wa Water‐Le Leak ak‐Detec Detector

Mo Model check checking: Does Does the the sprin sprinkler ler system system activate activate when when the there is is a fire fire? Mo Model check checking: Does Does the the sprin sprinkler ler system system activate activate when when the there is is a fire fire?

Soteria

11

Soteria components

Soteria

12

Pass Pass Fail Fail

IoT app source code Property identification indi ndivi vidual dual Tem Temporal

• ral lo

logic Property Property verific verificatio tion

(M (Mod

• del checke

checker) r)

1 3 4

Pass Fail

IoT app source code Property identification indi ndivi vidual dual Tem Temporal

• ral lo

logic Property Property verific verificatio tion

(M (Mod

• del checke

checker) r)

1 3 4

unio union

State State‐mod model extractio extraction

Obtai Obtain IR IR

2

State‐model extraction from source code

S1 S2 S3 S4

1 2 2 1 3 2 3 2 1 1 2 3 3

S1 S2 S3 S4

1 2 1 3 2 3 2 1 1 2 3 3

• Challenges of extracting state models
• IoT programming platforms are diverse
• Transitions may be guarded by conditions
• State‐explosion problem

State State‐mod model of

• f an

an exam example ple app app Soteria

Even Events ts Device Device attributes tributes

13

• What is a state model?

States and transitions In IoT applications… ‐ States: Device attributes ‐ Transitions: Labeled by events that trigger the attribute changes

Soteria

Coping with diverse IoT platform languages

14

State State‐model model Extraction Extraction

IR IR

IoT platform programming language

Groovy Python DSL

• App source ‐> IR ‐> state model
• We can reuse the part from IR to state‐model extraction, for a

new source language

Soteria

An example toy app

15

• The app: when users are back at home, turn on the light, unlock the

door, and send a notification email

• Between fromTime and toTime

input (p, presenceSensor, type:device) input (s, switch, type:device) input (d, door, type:device) input (fromTime, time, type:user_defined) input (toTime, time, type:user_defined) input (c, contact, type:user_defined) subscribe(p, “present”, handler)

Devices

Event subscription

Computation

Soteria

The IR of the example app

16

* Extracted from Groovy code for Samsung’s SmartThings

handler(){ def between = inBetween() if (between){ s.on() d.unlock() notify() } } inBetween(){ return timeOfDayIsBetween(fromTime, toTime) } notify(){ sendSms(c, “...”) }

17

Conditional device attribute changes

• Add a transition using end states and path conditions

subscribe(presence, present, handler)

// Entry point

handler(){ above = 50 below = 5 power = get_power() if(power > above){ switch.off() } if(power < below){ switch.on() } }

get_power(){ latest_pow=power_meter.currentValue("power") return latest_pow }

Entry point Entry point

power<5 power<5

• Perform path exploration and accumulate path conditions

Soteria

power>50 power>50

1: 6: 8: 11:

Wi Without

• ut path

path ex exploratio ation present S0 S1 Source Source code code of

• f Energy

Energy‐control control Io IoT app app

switch‐on

present S0 S1 Wi With path path exp exploratio ation power<5 power<5

switch‐on

18

switch‐off switch‐off

Coping with state explosion

• Reduce states by aggregating numerical‐valued attributes

def modeChangeHandler(evt){ def temp = 68 setTemp(temp) } 1: 2: 3: 4: 5: 6: 7: def setTemp(t){ ther.setHeatingPoint(t) }

• (6:

6: t) (6: 6: t, 3: 3: tem temp) (2: 2: te temp = 68) Worklist rklist t=50 t=51 t=95 . . .

Therm Thermosta stat tem temperature

Wi Without

• ut state

state redu reductio ion

t=68 t<>68

Therm Thermosta stat tem temperature

Wi With state state redu reduction ion

Soteria

Soteria

19

Therm Thermostat stat‐control control Io IoT app app

• State

State‐reduction reduction effica efficacy

Microbencmarks

• 10 numerical‐valued devices in 14 apps

Setup: Intel i5 Core 2 Duo, Java Runtime 1.8, NuSMV 2.6, Graphviz 2.36

1 2 3 4 5 6 7 8 9 10 11

App ID

100 101 102 103 104

Number of States

Before state reduction After state reduction 1 2 3 4 5 6 7 8 9 10 11

App ID

100 101 102 103 104

Number of States

Before state reduction After state reduction

Soteria

• State

State mo model extra extractio tion overhead

• verhead*

20 40 60 80 100 120 140 160 180

Number of States

4 8 12 16 20

• Avg. State-model

Extraction Time (s)

20 40 60 80 100 120 140 160 180

Number of States

4 8 12 16 20

• Avg. State-model

Extraction Time (s)

• An app with 180 states, on avg. ~ 17 secs

IoT safety/security property identification

The The doo

• or must

ust alway ays be lock

• cked when

hen the he user user is not not hom

• me

The The refrige efrigerato rator and nd security security system system must st al always ys be be on

• n

The wat ater valv lve must be clo losed if a le leak is is detected … The ala larm rm must alw always go off when there is is smoke

• 5 general properties

motion‐active

switch‐on Conflicting Conflicting state state changes changes

motion‐active

switch‐off

• 30 application‐specific properties
• Device‐independent
• Identifies use cases of one or more devices
• Property is a system artifact formally expressed via temporal logic and

validated on the state model

Soteria

1 2 3 30 30 motion‐active

switch‐on Race Race condition condition of

• f eve

events ts

user‐present

switch‐off

5 1

…

21

• Relied on use/misuse case requirements engineering for discovering IoT Properties

App1 App1 App2 App2 App3 App3

Property validation

• Individual applications
• Multiple applications
• Properties verified at validated through a model checker

smoke‐detected

switch‐off switch‐on away‐mode

switch‐on

home‐mode door‐unlocked door‐locked

home‐mode

• Create a union state model* of interacting apps

Soteria

Soteria Is Is door door alw always unl unlock cked wh when en th there is is smoke smoke at at hom home? * Union state model represents the complete behavior when the multiple apps running together

vio violate ated

22

P.3 P.3

Initia Initial Sta States

Saf Safe

Vi Violatio ion

Soteria in action…

Soteria Mo Model Checking Checking Mo Model Checking Checking Soteria Soteria – a – a syste system for for form formal al verific verificatio tion of

• f IoT

IoT app apps thro through ugh model model check checking Soteria Soteria – a – a syste system for for form formal al verific verificatio tion of

• f IoT

IoT app apps thro through ugh model model check checking Source Source code code Source Source code code

[water.dry, valve.close] [water.wet, valve.close] water.wet water.wet [water.dry, valve.open] water.wet [water.wet, valve.open] water.wet

State State‐mod model State State‐mod model Out Output put Out Output put Stac Stacktrac race Stac Stacktrac race Property Property Property Property SM SMV form format at of

• f th

the state state‐mod model SM SMV form format at of

• f th

the state state‐mod model

section("Turn on a pump...") { input ”valve_device", "capability.valve", title: "Which?", required: true } def installed() { subscribe(valve_device, "water.wet", waterWetHandler) } section("Turn on a pump...") { input ”valve_device", "capability.valve", title: "Which?", required: true } def installed() { subscribe(valve_device, "water.wet", waterWetHandler) } // Permissions block input (water_sensor, waterSensor, type:device) input (valve_device, valve, type:device) // Permissions block input (water_sensor, waterSensor, type:device) input (valve_device, valve, type:device) water.wet ⇒ (AX valve.on) water.wet ⇒ (AX valve.on) Using NuSMV symbolic model checker… General properties failed at state‐model construction: none NuSMV >> read model ... NuSMV >> check property NuSMV >> true Using NuSMV symbolic model checker… General properties failed at state‐model construction: none NuSMV >> read model ... NuSMV >> check property NuSMV >> true

IR IR IR IR

1 2 4 5 3

Mo Model Checking Checking Soteria Soteria – a – a syste system for for form formal al verific verificatio tion of

• f IoT

IoT app apps thro through ugh model model check checking Source Source code code

[water.dry, valve.close] [water.wet, valve.close] water.wet water.wet [water.dry, valve.open] water.wet [water.wet, valve.open] water.wet [water.dry, valve.close] [water.wet, valve.close] water.wet water.wet [water.dry, valve.open] water.wet [water.wet, valve.open] water.wet

State State‐mod model Out Output put Stac Stacktrac race Property Property SM SMV form format at of

• f th

the state state‐mod model

section("Turn on a pump...") { input ”valve_device", "capability.valve", title: "Which?", required: true } def installed() { subscribe(valve_device, "water.wet", waterWetHandler) } // Permissions block input (water_sensor, waterSensor, type:device) input (valve_device, valve, type:device) water.wet ⇒ (AX valve.on) Using NuSMV symbolic model checker… General properties failed at state‐model construction: none NuSMV >> read model ... NuSMV >> check property NuSMV >> true

IR IR

1 2 4 5 3

23

Follow‐up Work: IoTGuard [NDSS 19]

IoTGuard

24

Soteria Limitations:

• Static approaches overapproximate and report false positives
• Trigger‐action platform apps
• connect digital services with IoT apps
• 300+ online services (IoT and non‐IoT)
• IoTG

IoTGua uard: rd: A dynamic property property enforcem enforcement ent system on IoT device behaviors

• Use the same properties as Soteria
• But enforce the properties at runtime
• In addition, extend the scope to cover trigger‐action platform apps

Rul Rule

E (Sm Smart art hom

• me): user‐present

A (Googl Google): log user’s presence to a google doc file

Evaluation

• Implemented Soteria and IoTGuard for Samsung’s SmartThings platform

Soteria

• Selected 65

65 SmartThings market apps: 35 official and 30 third‐party apps

25

• For IoTGuard, further selected about 30 IFTTT trigger‐action apps

3 9 2 1 1 10 11 7 8 18 4 5 17 12 13 16 15 15 1 3 4

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Light switch(4) Door lock Presence sensor(2) Motion sensor(3) Contact sensor

• Temp. measure.

AC Heater Coffee machine Crockpot Leak detector(2) Fan Power meter Alarm(2) Smoke detector(2) Humidity sensor Luminance sensor Speakers Window shade Doorbell

• Did evaluation on a simulated smart home including 29

29 devices (20 20 device types)

• 14%

14% individual apps violate some properties (10 properties in total)

• All found violations were in third‐party apps

Soteria Findings ‐ Individual app analysis

App App ID ID Vi Viol

• lation

ation Descripti escription

• n

Vi Viol

• lated

ated Property Property

TP1 TP1 The music player is turned on when user is not at home P. P.13 13 TP2 TP2 The door is unlocked on sunrise and locked on sunset P. P.1 TP3 TP3 The location is changed to the different modes when the switch is turned off and when the motion is inactive S. S.4 TP4 TP4 The The flood

• od senso

sensor sounds sounds alarm alarm when when th there is is no no wa water ter P.29 TP5 TP5 The music player turns on when the user is sleeping P. P.28 28 TP6 TP6 The lights turn on and turn off when nobody is at home P. P.13, 13, S. S.1 TP7 TP7 The lights turn on and turn off when the icon of the app is tapped S. S.1 TP8 TP8 The switch turns on and blinks lights when no user is present P. P.12 12 TP9 TP9 The door is locked multiple times after it is closed S. S.2

TP = Third‐party S = General properties P = App‐specific properties Soteria

26

• Several groups of apps had property violations

Soteria Findings ‐ Multi‐app analysis

Gr.

• Gr. ID

ID App App ID ID Event/Acti Event/Actions

• ns

Vi Viol

• lated

ated Pr. Pr.

O7, TP3 P.12, P.13, P.14, P.17, S.1, S.2 O30, TP21 O31, TP22 O12, TP19

switch off

change location mode

motion inactive

switch‐on

location mode change

switch‐off

location mode change switch‐on location mode change

set thermostat heating

location mode change

set thermostat cooling

Soteria

Switch (O7/TP3)

chan change ge mode mode

mode change (O12/TP19) set

set the thermostat stat he heatin ating

mode change (O31/TP22) swi

switch ch on

• n

mode change (O12/TP19) set

set the thermostat stat cool cooling ing

switch‐on

…

swi switch ch off

• ff

switch‐off

…

3 (vacation, sleeping)

27

mode change (O30/TP21)

V.1.1 V.1.1 Rel Released ased in in Sept Sept 2018 2018

27 data leaks 28 security/safety violations 500+ official and third party Smartthings and OpenHAB apps

IoTB IoTBench ch

https://github.com/IoTBench/

28

System Systematically atically Addressi Addressing ng Devi Device ce Faults Faults in in Commod mmodity IoT IoT

29

IoTRepair

[O [Ongo ngoing Wo Work]

Motivation

• IoT devices are prone to faults

30

Faults lead to unreliable/insecure physical environments

Sprinkler stops working because of loss of power or software bug Flood sensor always reports flood because of device error (stuck‐at errors)

Fault types

• Fail‐stop faults

When devices stop responding to remote commands E.g., power loss, communication loss, software/hardware errors that stop devices

• Non fail‐stop faults

When devices continue to operate, but function incorrectly E.g., stuck‐at faults, outlier faults, spike faults, high‐variance faults

• Cascading faults

When a faulty device managed by one app triggers an event in another app

31

A survey of IoT platforms on how faults are handled

Undetected: the platform does not detect this type of fault Silent: the platform detects faults but does not notify applications Generic Error: the platform gives a generic error to applications accessing a faulty device Detailed Error: the platform specifies information about the fault type in the error

32

IoT platforms do not provide developers with sufficient mechanisms to handle faults: none none provi provides es in info fo about about non non‐fail fail‐sto stop faults; faults; onl

• nly Androi

AndroidThi dThings ngs provi rovides des in info fo about about fail fail‐sto stop faults, faults, but but it it does does not not provi provide devel developers pers means means to to handl handle faults faults

Prior research

• IoT fault identification

E.g., Sympathy [Ramanathan et al., Sensys 05]; DICE [Choi et al., DSN 18]; [SHARMA et al., TOSN 10]; … They detect faults, but do not perform fault handling

• Little work on IoT fault handling

Existing work lac lacks gener nerality ty and focuses on specific environments or specific recovery techniques E.g., UAV sensor fault isolation [Tu et al., arXiv 18] E.g., edge device removal in Rivulet [Ardekani et al., ACM Middleware 17]; E.g., transactions in Transactuations [Sengupta et al, ATC 19]

33

A need for a general IoT fault‐handling system across a diverse set of deployments

Design of IoTRepair

• Focus on fault handling, not fault detection

Assume a fault‐detection module, which detects faults and gives faulty device IDs

• Provide a library with a set of fault‐handling functions

E.g., activate duplicate, retry, restart, checkpoint/rollback

• Developers use the library for flexible fault handling

Through an API and a config file

• Provide an automated fault handler

Try fault‐handling functions using some scheme (order, …) With an auto‐generated and dynamically adjusted config file

34

IoTRepair system architecture

35

A toolkit of fault‐handling functions

• Device‐based functions: fix the state of a single device

Activate a redundant device Retry actuation (effective for fixing transient faults) Software and hardware restart

• Environment‐based functions: fix the state of an IoT environment

(multiple devices)

Checkpoint/rollback Transaction: perform a series of actuations in an all‐or‐none fashion

36

System configuration

• Specify parameters used in fault‐

handling functions

E.g., what is the ID of a duplicate device E.g., how many restart attempts E.g., what type of rollback should be used

• Developers can write this manually or

adjust an auto‐generated one

37

Automated fault handler

• Invoking fault‐handling functions according to some schem

scheme

A scheme controls the selection, ordering, and parameters of the fault‐handling functions If some function is able to recover from the fault, stop If none can, notify the user

38

History based checkpoint/rollback

• The automated handler

Continuously takes checkpoints of device states (sensor and actuator states) after an actuation

• Three kinds of rollbacks, when a fault is detected

Fail Fail‐recen recent: rollback to the most recent checkpoint Fail Fail‐no norm: rollback to the most frequent checkpoint that matches the current states of non‐faulty sensors Fail Fail‐safe safe: first filter checkpoints in the history using fail‐safe config of devices; then fail‐ norm

39

Fail‐Norm Rollback

40

Motion Presence Door lock Off Faulty (stuck at home) Unlocked

Frequency Motion Presence Door lock 30 On Home Unlocked 2 On Away Locked 3 Off Home Unlocked 50 Off Away Locked

History of checkpoints: These two match the motion sensor state and the second one has higher frequency; so rollback the door to be locked

Door‐lock‐app: unlock the door iff presence sensor says user is home

When user is away, unlikely to detect motion

Config file: auto generation and dynamic adjustments

• During system initialization

Obtain a list of connected devices, their types and capabilities Generate default configurations for devices based on their types/capabilities

• Some config info is adjusted at runtime

E.g., it detects duplicate devices based on runtime sensor/actuator states and put that info into the config file

41

Evaluation setup

• Simulated Home: 17 devices and 11 apps

Trace‐driven simulation runs based on generated events Events generated randomly, do not ensure full coverage

• Fault Injection: injected faults overwrite device states with faulty states

Each injection determines false states, length of the fault, and fault type

42

Evaluation: devices and apps

43

Devices used for evaluation Apps developed with devices for smart home

Evaluation (still ongoing)

• Timing: How fast fault handling functions and schemes can resolve faults

How long each fault takes to run averaged between devices, faults, and config How long each scheme takes to resolve fault types averages between devices, faults, and config

• Effectiveness: How effective our system can reduce fault effects

Single and Multiple faults injected in a given time Cascading Faults Implications of faults on Safety and Security

• Power Consumption: How much power our automated fault handler

consumes

Measure events, actuations, and restarts to capture how much device‐power is consumed

44

Effectiveness

• Incorre

Incorrect ct state states in a faulty execution: those that differ from the corresponding states in an identical but faultless execution

• Average the results of 100 runs, each with unique trace and faults

New traces are generated using random events in sensor devices New fault injection changes the random elements of all faults, which is false state, duration, and repairability

• Baselines:

Injected faults and no handling Injected faults and only device suppression

45

Automated Fault Handler Effectiveness

• Single: 63.51% decrease

from NoHandle to Transient Resistant

• Multiple: 36.68% decrease

from NoHandle to Transient Resistant

46

47

Projecting into the Future

What’s unique about IoT security?

• Interaction between digital and physical worlds

“Heater on ‐> temperature rise ‐> window open” Soteria: build models from the apps and bake in rules for digital and physical world interaction (e.g., “heater on ‐> temperature rise”) IoTMon [Ding & Hu, CCS 18]: use NLP techniques to find physical‐world connection between apps Future: need integration of better physical models (timing, velocity, etc.); side channels

48

What’s unique about IoT security?

• Distributed systems security

IoT is a network of devices (sensors and actuators) Centralized solutions unlikely to scale to large IoT networks Future: push security functions into devices (a la edge computing) Challenge: implement security in lower‐resourced devices Challenge: concurrency

■ synchronization between devices; multiple security functions running concurrently

Challenge: IoT devices made by a vast number of manufacturers

■ A security solution needs to accommodate diversity and easy to incorporate new devices

49

Hyppönen’s law, and IoT safety and security

"Whenever an appliance is described as being "smart", it's vulnerable."

As everything that can be smart will be smart, and interact with each other, they will become targets of adversaries.

Security expert Mikko Hyppönen posited that …

50

Questions?

51