PaperlayerView exact revision on arXiv

Source-linked AI summary

Program Analysis of Commodity IoT Applications for Security and Privacy: Challenges and Opportunities

Z. Berkay Celik, Earlence Fernandes, Eric Pauley, Gang Tan, Patrick McDaniel

arXiv:1809.06962v3cs.CRcs.PL

TL;DR

IoT security and privacy concerns are growing, but the application and scope of program analysis in IoT remain underexplored. This paper studies five platforms, IoT-specific analysis issues, and existing systems; it finds significant gaps in sensitivity and multi-app coverage. It concludes that further progress is needed before apps are safe for broader use.

  • Problem

    IoT apps can affect physical processes and private data, while the application and scope of program analysis for IoT remain underexplored.

    Source: §1 · p. 1, §4.2 · p. 9

  • Method

    The paper studies five platforms, identifies IoT-specific analysis issues, and examines recent IoT security and privacy analysis systems.

    Source: §1 · p. 2, §7 · p. 24

  • Results

    The review finds that most approaches lack path and context sensitivity and often omit multi-app environments and information flows in trigger-action platforms.

    Source: §7 · p. 24

  • Takeaways & Limitations

    The authors conclude that IoT program analysis needs additional progress before apps are safe for broader use.

    Source: §7 · p. 25

    Current systems often focus on smart homes, while diverse IoT domains and scalability demands in settings such as smart automobiles and industrial IoT remain challenges.

    Source: §7 · p. 25

Abstract

from arXiv · show

Recent advances in Internet of Things (IoT) have enabled myriad domains such as smart homes, personal monitoring devices, and enhanced manufacturing. IoT is now pervasive---new applications are being used in nearly every conceivable environment, which leads to the adoption of device-based interaction and automation. However, IoT has also raised issues about the security and privacy of these digitally augmented spaces. Program analysis is crucial in identifying those issues, yet the application and scope of program analysis in IoT remains largely unexplored by the technical community. In this paper, we study privacy and security issues in IoT that require program-analysis techniques with an emphasis on identified attacks against these systems and defenses implemented so far. Based on a study of five IoT programming platforms, we identify the key insights that result from research efforts in both the program analysis and security communities and relate the efficacy of program-analysis techniques to security and privacy issues. We conclude by studying recent IoT analysis systems and exploring their implementations. Through these explorations, we highlight key challenges and opportunities in calibrating for the environments in which IoT systems will be used.

1 INTRODUCTION

IoT security and privacy analysis matters because apps can control risky physical processes and expose private data, while IoT platforms pose challenges distinct from other analysis domains. The paper studies five platforms, IoT-specific issues, and existing analysis systems to identify challenges and opportunities.

1 INTRODUCTION

  • IoT apps can control physical devices in ways that threaten safety and security, while networked systems can expose private information about users.Examples include unlocking a door, turning off heat, and revealing when household members are home.Source: §1 · p. 1
  • IoT platforms use diverse languages, expose subtle device states, and include features such as reflection and web requests that complicate program analysis.The paper contrasts these characteristics with Android’s well-defined intermediate representation.Source: §1 · p. 2
  • The study examines five platforms, maps common app structures, and surveys IoT-specific issues, analysis requirements, and six major-venue systems.Its scope is publications using program analysis for IoT security and privacy.Source: §1 · p. 2

2 BACKGROUND

This background outlines IoT architectures and programming platforms, then surveys security and privacy risks and defenses. It focuses on consumer IoT while situating the concerns across wider application domains.

2 BACKGROUND

  • Consumer IoT is the focus because it has the largest number of applications and the most significant market, despite IoT’s reach across domains.The cited domains include automotive, aviation, homes, wearables, agriculture, and smart cities.Source: §2 · p. 3, §2.2 · p. 3

2.1 An Overview of IoT System Architectures

  • IoT systems combine devices, connectivity protocols, and programming platforms; edge gateways connect devices, while cloud back ends synchronize states and support remote control.Devices sense physical states and actuate changes, with protocols chosen for environmental requirements such as low power.Source: §2.1 · p. 3

2.2 IoT Security and Privacy

  • IoT failures and misuse can cause privacy violations, vehicle crashes, monetary theft, health consequences, and environmental disasters.Defenses include perimeter protections, while other studies examine device and platform vulnerabilities and application source code.Source: §2.2 · p. 4
  • Existing surveys address devices, protocols, architectures, solutions, and privacy threats; this work instead focuses on application security and privacy through program analysis.The broader surveys are identified as covering IoT more generally.Source: §2.2 · p. 4

3 IOT PROGRAMMING PLATFORMS

A review of five major IoT programming platforms finds shared event-driven app structures despite differing languages and execution environments. The paper generalizes these structures into common building blocks for analysis.

3 IOT PROGRAMMING PLATFORMS

  • The survey reviews five major platforms using official documentation, example apps, and app-construction logic, finding similar structures with differences in communication protocols.The platforms are SmartThings, OpenHAB, HomeKit, Android Things, and AWS IoT.Source: §3 · pp. 4–5

3.1 Overview of IoT Programming Platforms

  • SmartThings and OpenHAB apps react to events through handlers or rules, while HomeKit scripts, AWS rules, and Android Things callbacks connect triggers to actions.These platforms differ in languages and runtime arrangements, including Groovy, a DSL, Swift or Objective-C, AWS services, and Android-based callbacks.Source: §3.1 · pp. 5–7

3.2 Generalizing IoT Application Structure

  • The generalized platform-agnostic model represents IoT apps through permissions, events, and call graphs within a sensor-computation-actuator structure.Permissions grant access to devices and user inputs; events connect sensor readings to handlers, and call graphs represent entry points and call sites.Source: §3 · p. 5, §3.2 · p. 7
  • IoT apps are event-driven without a main method, and their entry points are event-handler subscriptions; abstract events include timers, app touches, external requests, and mode changes.An event handler can actuate device-state changes, while its call graph captures invoked functions.Source: §3.2 · pp. 7–8

4 PROGRAM ANALYSIS OF IOT APPS

IoT program analysis targets sensitive-data leaks, unsafe device behavior, and permission misuse. Its challenges include diverse platform languages, physical processes, interactions among apps and online services, and platform-specific features.

4.1 Goals of Analyses

  • Analysis goals include detecting sensitive-data disclosures, preventing unsafe device-capability abuse, and identifying overbroad or unnecessary permissions.Source: §4.1 · pp. 8–9
  • Provenance systems instrument apps and aggregate behavior into structures such as graphs to support forensics and diagnosis of attack causes.Source: §4.1 · p. 9

4.2 Issues in IoT Program Analysis

  • Unlike Android's available intermediate representation, IoT platforms use different languages, so analysis must capture apps' event-driven behavior.Source: §4.2 · p. 9
  • IoT apps control physical processes, so capability misuse can create health risks, including light patterns that may trigger seizures in people with photosensitive epilepsy.Source: §4.2 · pp. 9–10
  • Co-located apps can interact when one app's device action triggers another, potentially creating unsafe states such as a locked door during a fire.Source: §4.2 · p. 10
  • Trigger-action platforms extend interactions between IoT devices and digital services, connecting device events and actions with online-service events and actions.Source: §4.2 · p. 10
  • Platform-specific features, such as SmartThings Groovy reflection and web-service apps, require special treatment and make analysis more difficult.Source: §4.2 · p. 10

5 ANALYSIS OF IOT PROGRAMS

This section examines IoT program analysis for risks and behaviors involving physical devices, interacting apps and services, and platform-specific code patterns, with precision choices suited to programs’ state, control flow, and execution contexts. It covers how path conditions and data provenance sharpen analysis and how SmartThings apps propagate data to device actions.

5.1 IoT-specific Analysis Issues

  • Physical processes can enable side-channel leaks, health risks, and indirect device control, motivating checks for unsafe device states and context-sensitive guards.Examples include varying a light’s intensity to signal whether occupants are home [22], flashing lights that may trigger seizures, and manipulating room temperature to open a window [24, 32].Source: §5.1 · pp. 11–12
  • IoT simulation must model heterogeneous devices, event and action dependencies, and evolving physical states, but available simulators lack sufficient device and event support.The section calls for discrete-event simulation with continuous-time solvers and state-machine modeling to represent physical processes over time.Source: §5.1 · pp. 12–13
  • Automated IoT test generation must cover diverse event inputs and device states, yet tools for generating IoT app inputs and events are largely non-existent.Thermostat and power-meter attributes may be discrete or continuous, making exhaustive test generation impractical; fuzzing and symbolic execution offer relevant approaches.Source: §5.1 · p. 13
  • Individually safe apps can create safety violations through shared devices or events, so multi-app analysis must find interactions and check policies for undesired states.In the example, a simulated-occupancy app’s light-on event causes a welcome-home app to turn on a heater and coffee machine while the user is away [24, 25, 32].Source: §5.1 · pp. 13–14
  • Trigger-action rules can violate integrity or confidentiality, while analyzing them requires extracting and labeling rule events and actions that may need user help or natural-language processing.Examples include an untrusted tweet turning on a trusted light and a door-unlocked state being logged publicly.Source: §5.1 · pp. 14–15

5.2 IoT Application Idiosyncrasies

  • RESTful APIs expose devices to external services, creating risks of sensitive-data disclosure and undesired commands; a compromised forecast server could trigger high-power devices and outages.The SmartThings corpus included 23 official and six third-party web-service apps [22].Source: §5.2 · p. 15
  • IoT language features require tailored analysis: closures need expression-level inspection for taint propagation, while reflective calls need conservative targets or string analysis to refine them.In the corpus, 37 official and nine third-party apps used closures; nine official and one third-party app used reflection [22].Source: §5.2 · pp. 15–16

5.3 Analysis Sensitivities

  • Flow-, context-, field-, and path-sensitive analyses can distinguish feasible IoT data flows, but context depth may need to increase for more complex apps.Depth-one call-site sensitivity was precise in 230 analyzed apps; field sensitivity distinguishes persistent state fields, and path sensitivity avoids flagging an impossible flow.Source: §5.3 · pp. 17–18
  • Predicate analysis tracks path conditions to distinguish feasible execution paths and determine when sensitive device state flows into a message.The example has three paths: userTemp=0 with power below 50 returns 68; userTemp=0 with power at least 50 sends a text, turns off a switch, and returns 63; otherwise it returns userTemp.Source: §5.3 · p. 19
  • Provenance tracking labels data by origin, helping determine whether device actions using it are intended, mistaken, or potentially malicious.Hard-coded constants and a threshold yield developer-defined data; a user-entered threshold yields both user-defined and developer-defined labels.Source: §5.3 · p. 19
  • In 230 SmartThings apps, developer-defined constants or user inputs mostly flow to device-attribute changes, sometimes after simple arithmetic.One example stores a user input in y, computes x=y+10, and uses x to change a device attribute.Source: §5.3 · p. 19

6 STUDY OF IOT ANALYSIS SYSTEMS

The section surveys six IoT security and privacy analysis systems, their underlying techniques, and how they address platform-specific analysis challenges. It contrasts privacy systems with systems for safety and security, highlighting differences in scope and analysis choices.

6.1 Fundamental Analysis Techniques

  • The surveyed toolkit spans taint tracking, instrumentation, symbolic execution, model checking, slicing, and opacified computing for analyzing flows, behavior, paths, properties, dependencies, and data policies.These techniques respectively track sensitive data, collect runtime behavior, explore feasible paths, check specifications, identify statements affecting values, and sandbox access to sensitive functions.Source: §6.1 · pp. 20–21

6.2 Analysis of SmartThings Apps

  • SmartThings analysis often operates directly on Groovy source ASTs because compiler-generated bytecode uses reflection that can make the bytecode-analysis route infeasible.Compiler hooks and AST visitors can expose app entry points, structure, method calls, and expressions.Source: §6.2 · pp. 21–22

6 STUDY OF IOT ANALYSIS SYSTEMS

  • The review groups FlowFence and Saint as privacy systems, and ProvThings, SmartAuth, ContexIoT, and Soteria as safety and security systems.The study examines six recent IoT analysis systems and compares their techniques and implementation specifics.Source: §6 · p. 19, §6.3 · p. 22

6.3 Review of IoT Systems

  • The systems differ in analysis type, runtime, scope, and handling of IoT-specific issues, and the review organizes them by privacy versus safety and security goals.Table 4 summarizes the systems against the issues discussed in the paper.Source: §6.3 · p. 22, Table 4 · p. 22, §6.3.2 · p. 23

6.3.1 Systems for Privacy.

  • FlowFence enforces intended flows dynamically through quarantined modules, while Saint statically tracks source-to-sink flows and uses path- and context-sensitivity to prune infeasible paths.FlowFence can cover flows across multiple apps, whereas Saint detects flows within an individual app; reflective calls can lead Saint to over-taint by treating every method as a possible target.Source: §6.3.1 · pp. 22–23

6.3.2 Systems for Safety and Security.

  • Safety and security systems analyze ASTs but vary in instrumentation, state modeling, symbolic execution, and whether they analyze apps individually or together.ContexIoT and SmartAuth analyze apps in isolation, while ProvThings and Soteria capture interactions among apps; reflective-call handling can add unnecessary instrumentation or overapproximate violations.Source: §6.3.2 · pp. 23–24

7 TAKEAWAYS AND CONCLUSIONS

The paper synthesizes IoT app structures, analysis issues, and recent security and privacy analysis systems. It finds recurring gaps in platform coverage, analysis sensitivity, and multi-app and trigger-action security, while noting open challenges for broader use.

Study scope

  • The study maps five major IoT platforms’ app structures to common building blocks and reviews recent program-analysis work on IoT security and privacy.It reports that most efforts address sensitive data leaks, abuse prevention, permission misuse, and provenance collection.Source: §7 · p. 24

Key findings

  • Dominant IoT platforms structure apps around a sensor-computation-actuator idiom, but platform-targeted analysis tools remain largely absent.The study also finds that most approaches lack path- and context-sensitivity and often omit multi-app and trigger-action information-flow concerns.Source: §7 · p. 24

Open challenges

  • Most studied tools target smart homes, while domain diversity, scalability, resource costs, interactions with other environments, and safe responses to violations remain open challenges.The paper cautions that simply blocking an action or waiting for user approval can be unsafe in some circumstances.Source: §7 · p. 25

Conclusion

  • The resulting structure helps reason about the capacity of IoT systems and the extent to which they identify and mitigate safety, security, and privacy issues.The paper presents its exploration as a basis for future research.Source: §7 · p. 25
Loading 1809.06962v3…