PaperlayerView exact revision on arXiv

Source-linked AI summary

Privacy-by-Design Framework for Assessing Internet of Things Applications and Platforms

Charith Perera, Ciaran McCormick, Arosha K. Bandara, Blaine A. Price, Bashar Nuseibeh

arXiv:1609.04060v1cs.CYcs.CRcs.SE

TL;DR

IoT applications and middleware have lacked explicit privacy consideration and systematic methods to guide privacy design. The paper proposes guidelines as a privacy-by-design framework and demonstrates assessment of two open-source platforms. The authors also describe limits on platform comparisons and a lifecycle-phase assumption in their framework.

  • Problem

    The authors identify a lack of privacy protection features and IoT-specific methods to guide software engineers in designing privacy for IoT applications and middleware.

    Source: INTRODUCTION · pp. 1–2

  • Method

    The paper proposes privacy-by-design guidelines as a framework for systematically assessing existing IoT applications and middleware platforms.

    Source: INTRODUCTION · p. 1, CONCLUSIONS AND FUTURE WORK · p. 8

  • Results

    The authors demonstrate the framework by assessing the open-source Eclipse Smart Home and OpenIoT platforms.

    Source: CONCLUSIONS AND FUTURE WORK · p. 8

  • Takeaways & Limitations

    The authors say detailed privacy-gap analysis can help engineers share design reasoning and develop new privacy features.

    Source: CONCLUSIONS AND FUTURE WORK · p. 9

    The guidelines should not be used to compare platforms with different intended functions, though they may support privacy comparisons between similar platforms.

    Source: PRIVACY-BY-DESIGN GUIDELINES · p. 3

Abstract

from arXiv · show

The Internet of Things (IoT) systems are designed and developed either as standalone applications from the ground-up or with the help of IoT middleware platforms. They are designed to support different kinds of scenarios, such as smart homes and smart cities. Thus far, privacy concerns have not been explicitly considered by IoT applications and middleware platforms. This is partly due to the lack of systematic methods for designing privacy that can guide the software development process in IoT. In this paper, we propose a set of guidelines, a privacy-by-design framework, that can be used to assess privacy capabilities and gaps of existing IoT applications as well as middleware platforms. We have evaluated two open source IoT middleware platforms, namely OpenIoT and Eclipse SmartHome, to demonstrate how our framework can be used in this way.

INTRODUCTION

IoT applications are difficult to design, and existing privacy frameworks lack specific guidance for engineers assessing or designing them. The paper proposes a privacy-by-design framework for assessing IoT applications and middleware platforms, while this paper focuses on assessing existing platforms.

INTRODUCTION

  • The authors identify a lack of privacy protection features and IoT-specific privacy-by-design guidance as motivations for their work.They also cite recent IoT privacy and security breaches, including an internet-connected baby monitor.Source: INTRODUCTION · p. 1
  • The proposed framework guides systematic assessment of privacy capabilities in IoT applications and middleware platforms; this paper assesses existing platforms.The authors suggest it could also guide the design of new platforms.Source: INTRODUCTION · p. 1
  • Existing general-purpose privacy principles lack the detail needed for software engineers developing IoT applications.The authors also say Hoepman’s strategies and LINDDUN are not IoT-specific and are not prescriptive enough for engineers.Source: INTRODUCTION · p. 2
  • STRIDE categorizes six security threats, including information disclosure, but focuses mostly on security rather than privacy.The categories are spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.Source: INTRODUCTION · p. 2
  • IoT development is complex because applications integrate heterogeneous software and hardware across nodes with different capabilities and conditions.The authors argue that systematic guidance can make privacy-gap assessments more consistent and reduce assessment time.Source: INTRODUCTION · p. 2

INTERNET OF THINGS: DATA FLOW

A typical centralized IoT architecture moves data from sensing devices through gateways to cloud infrastructure. The paper structures data handling into five lifecycle phases and assumes each node has all five, though engineers may omit phases at some nodes.

INTERNET OF THINGS: DATA FLOW

  • Data in a typical centralized IoT architecture moves from sensing devices to gateways and then to cloud infrastructure.Figure 1 illustrates this typical data flow.Source: INTERNET OF THINGS: DATA FLOW · p. 2, Figure 1 · p. 2
  • IoT devices differ in computational capability, energy access, and feasible data processing, while middleware is proposed to provide built-in privacy protections.The authors say such middleware could help application developers protect user privacy while pursuing their objectives.Source: INTERNET OF THINGS: DATA FLOW · p. 2
  • The framework divides each node’s data lifecycle into five phases: Consent and Data Acquisition, Data Preprocessing, Data Processing and Analysis, Data Storage, and Data Dissemination.These cover data reading and routing, preparation, analysis, storage, and transmission to an external party.Source: INTERNET OF THINGS: DATA FLOW · p. 2
  • The framework assumes all five phases are present at every node, although engineers may omit phases based on their decisions.For example, a constrained sensor may average temperature data and send it to a gateway without analyzing or storing it locally.Source: INTERNET OF THINGS: DATA FLOW · p. 2

PRIVACY-BY-DESIGN GUIDELINES

The framework organizes IoT privacy-by-design guidance around Hoepman’s strategies and the data life cycle. Its adaptable guidelines address secondary usage and unauthorized access, while their use for comparison is limited to applications or platforms with similar intended functionality.

Scope

  • The guidelines should not be used to compare platforms with different purposes, though they may support privacy comparisons between platforms with similar intended functionality.The paper contrasts SmartHome’s home-hub purpose with OpenIoT’s smart-city middleware purpose.Source: PRIVACY-BY-DESIGN GUIDELINES · p. 3

Framework purpose

  • The guidelines are intended for customized adoption, with data minimization identified as the most important strategy and the goal of using only the data needed.They are derived from literature and use cases, and are not fool-proof recommendations independent of application-specific objectives and implementation.Source: PRIVACY-BY-DESIGN GUIDELINES · p. 3

Risk framing

  • The framework maps guidelines to two privacy risks: secondary usage of data beyond its initially consented purpose and unauthorized access during any life-cycle phase.The symbols in the guidelines indicate which risk is relevant.Source: PRIVACY-BY-DESIGN GUIDELINES · p. 3

Minimize

  • Guidelines cover minimizing collected data, data sources, raw-data intake, knowledge discovery, storage, and retention.They also recommend reducing data granularity and using query answers or aggregation instead of releasing raw data.Source: PRIVACY-BY-DESIGN GUIDELINES · p. 3

Hide

  • Guidance for data protection includes hidden routing, anonymization, and encryption of communication, processing, and storage.Encryption may use hardware or software technologies, depending on circumstances.Source: PRIVACY-BY-DESIGN GUIDELINES · p. 4

Inform

  • Information disclosure asks engineers to inform data subjects before or after data enters or leaves a life-cycle phase.The phase-based questions cover acquisition, preprocessing, analysis, storage, and dissemination.Source: PRIVACY-BY-DESIGN GUIDELINES · p. 5

Control

  • Control mechanisms should let data owners manage privacy preferences, with engineers selecting useful controls and providing default options when users lack expertise.Potential controls include granularity, anonymization, retention, and dissemination.Source: PRIVACY-BY-DESIGN GUIDELINES · p. 5

Demonstrate

  • Logging across life-cycle phases supports later examination, while auditing can independently examine logs, procedures, processes, and system specifications.Open source code, data-flow diagrams, certification, standards, and regulatory compliance are also presented as ways to demonstrate privacy protection.Source: PRIVACY-BY-DESIGN GUIDELINES · pp. 5–6

EVALUATION

The authors assess two open-source middleware platforms using data-flow and life-cycle tables, then rate each guideline by support status. Examples show that support can vary by platform and phase, and that open-source code review does not necessarily include privacy auditing.

Evaluation scope

  • The evaluation applies the framework to two open-source platforms selected for their availability to the research community, despite their different purposes.OpenIoT focuses on enterprise and industrial IoT, while Eclipse Smart Home integrates home-automation systems and technologies.Source: EVALUATION · pp. 6–7

Methodology

  • The assessment identifies device categories and builds a table for each node, with life-cycle phases as columns and privacy guidelines as rows.Engineers then apply color codes and may record notes explaining their ratings and rationale.Source: EVALUATION · p. 7

Assessment findings

  • OpenIoT supports configurable sampling rates in data preprocessing, while SmartHome lacks similar functionality; both platforms’ data-acquisition phases are extendible but do not provide the feature readily.OpenIoT uses a declarative language for sampling-rate configuration; wrappers in OpenIoT and bundles in SmartHome can be extended for minimum-data requests.Source: EVALUATION · p. 8
  • Both platforms are marked unsupported for privacy auditing because their code reviews address coding standards, not privacy aspects.The authors state they conducted similar examinations across all guidelines.Source: EVALUATION · p. 8

CONCLUSIONS AND FUTURE WORK

The paper presents a guideline-based conceptual framework for systematically assessing IoT application and platform privacy capabilities, and demonstrates it on Eclipse Smart Home and OpenIoT. It identifies future work in empirical assessment studies and in testing framework-guided design of new applications and platforms.

Conclusion

  • The paper presents privacy-by-design guidelines as a conceptual framework for systematically assessing privacy capabilities in IoT applications and platforms.It demonstrates the framework using Eclipse Smart Home and OpenIoT and describes a step-by-step process for applying it.Source: CONCLUSIONS AND FUTURE WORK · p. 8

Practical implications

  • Summarized privacy-status reporting may help engineers justify investments in privacy features, while detailed gap analysis may help colleagues share design reasoning for new features.These are presented as potential uses of the framework’s reporting and analysis.Source: CONCLUSIONS AND FUTURE WORK · p. 9

Future work

  • Planned empirical studies will test assessment with and without the framework and explore use by non-specialized IT professionals.The proposed participant groups include final-year students and new software-engineering graduates.Source: CONCLUSIONS AND FUTURE WORK · p. 9
  • Future work also includes testing framework use in designing new applications and platforms and developing privacy patterns for design processes.The proposed design study would compare scenarios completed with and without the guidelines and measure effectiveness quantitatively.Source: CONCLUSIONS AND FUTURE WORK · p. 9
Loading 1609.04060v1…