Privacy-by-Design Framework for Assessing Internet of Things Applications and Platforms Charith Perera 1, Ciaran McCormick 1, Arosha K. Bandara 1, Blaine A. Price 1 Bashar Nuseibeh 1,2 1 The Open University, Milton Keynes, UK 2 Lero - The Irish Software Research Centre, Limerick, Ireland fi[email protected] ABSTRACT services are called ‘middleware’ as they sit ‘in the mid- The Internet of Things (IoT) systems are designed and dle’ , in a layer above the operating system and network- developed either as standalone applications from the ing software and below domain-specific applications [1]. ground-up or with the help of IoT middleware platforms. Our proposed privacy-by-design (PbD) framework can They are designed to support different kinds of scenarios, be used to assess both IoT applications and middleware such as smart homes and smart cities. Thus far, privacy platforms without any changes and agnostic to their dif- concerns have not been explicitly considered by IoT ap- ferences. Therefore, in this paper, we use the terms ‘ap- plications and middleware platforms. This is partly due plication’ and ‘middleware platform’ interchangeably. to the lack of systematic methods for designing privacy Our research is motivated by a lack of privacy protec- that can guide the software development process in IoT. tion features in both IoT applications and middleware In this paper, we propose a set of guidelines, a privacy- platforms. We also recognise that existing privacy-by- by-design framework, that can be used to assess privacy design frameworks do not provide specific guidance that capabilities and gaps of existing IoT applications as well can be used by software engineers to design IoT applica- as middleware platforms. We have evaluated two open tions and middleware platforms. Further, recent security source IoT middleware platforms, namely OpenIoT and and privacy breaches in IoT solutions domain (e.g., In- Eclipse SmartHome , to demonstrate how our framework ternet connected baby monitor [40]) have also motived can be used in this way. our research. ACM Classification Keywords In recent years, many parties have built IoT mid- K.4.1 Computers and Society: Public Policy Issues— dleware platforms, from large corporations (e.g., Mi- Privacy ; D.2.10 Software Engineering: Design— Method- crosoft Azure IoT) to start-ups (e.g., wso2.com, Xively), ologies from proprietary to open source (e.g., KAAproject.org), and from academic organisations (e.g., OpenIoT.eu) Author Keywords to broader communities (e.g., Eclipse Smart Home: Internet of Things, privacy, Software Engineering eclipse.org/smarthome). Thus far, privacy has not been considered explicitly by any of these platforms, we be- INTRODUCTION lieve partly due to a lack of privacy-by-design methods The Internet of Things (IoT) [34] is a network of physi- for the IoT. To address this, we propose a privacy-by- cal objects or ‘things’ enabled with computing, network- design (PbD) framework that can guide software engi- ing, or sensing capabilities which allow these objects to neers to systematically assess the privacy capabilities of collect and exchange data. To make IoT application IoT applications and middleware platforms. We suggest development easier, a variety of IoT middleware plat- that the proposed framework can also be used to design forms have been proposed and developed. TThese plat- new IoT platforms. However, in this paper, we only fo- forms offer distributed system services that have stan- cus on assessing existing IoT platforms. dard programming interfaces and protocols, which help There are number of existing frameworks that have solve problems associated with heterogeneity, distribu- been proposed to help elicit privacy requirements and tion and scale in IoT applications development. These to design privacy capabilities in systems. The origi- Permission to make digital or hard copies of all or part of this work for personal or nal privacy-by-design framework was proposed by Ann classroom use is granted without fee provided that copies are not made or distributed Cavoukian [3]. This framework identifies seven founda- for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the tional principles that should be followed when developing author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or privacy sensitive applications. These are: (1) proactive republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. not reactive; preventative not remedial, (2) privacy as IoT’16, November 07 - 09, 2016, Stuttgart, Germany the default setting, (3) privacy embedded into design, (4) © 2016 Copyright held by the owner/author(s). Publication rights licensed to ACM. full functionality positive-sum, not zero-sum, (5) end-to- ISBN 978-1-4503-4814-0/16/11. $15.00 end security; full life-cycle protection, (6) visibility and DOI: http://dx.doi.org/10.1145/2991561.2991566 transparency- keep it open, and (7) respect for user pri- vacy, keep it user-centric. These high level principles are proposed for computer systems in general but does not provide enough details to be adopted by software engi- neers when designing and developing IoT applications. Building on the ideas of engineering privacy-by- architecture vs. privacy-by-policy presented by Spiek- erman and Cranor [39], Hoepman [20] proposes an ap- proach that identifies eight specific privacy design strate- gies: minimise, hide, separate, aggregate, inform, con- trol, enforce, and demonstrate. This is in contrast to other approaches that we considered. In a similar vein, LINDDUN [11] is a privacy threat analysis framework Figure 1: Typical data flow in IoT Applications that uses data flow diagrams (DFD) to identify privacy threats. It consists of six specific methodological steps: also called centralised architecture, used in IoT applica- define the DFD, map privacy threats to DFD elements, tion development [38]. Each of these devices have differ- Identify threat scenarios, prioritise threats, elicit mitiga- ent computational capabilities. They also have different tion strategies, and select corresponding privacy enhanc- types of access to energy sources from permanent to so- ing technologies. However, both LINDDUN and Hoep- lar power to battery power. Further, depending on the man’s framework are not aimed at the IoT domain. Fur- availability of knowledge, each device may have limita- ther, they not prescriptive enough in guiding software tions as to the type of data processing that can be done. engineers. An IoT application should integrate all these different In contrast, the STRIDE [21] framework was developed types of devices with different capabilities. We believe to help software engineers consider security threats, it is that IoT middleware platforms should provide in-built an example framework that has been successfully used privacy protection capabilities. As a result, IoT appli- to build secure software systems by industry. It suggests cation developers will be able to easily use middleware six different threat categories: spoofing of user identity, platforms to achieve their own objectives while protect- tampering, repudiation, information disclosure (privacy ing user privacy. breach or data leak), denial of service, and elevation of We divided the data life cycle into five phases in order to privilege. However, its focus is mostly on security rather structure our discussion. Within each device (also called than privacy concerns. node), data moves through five data life cycle phases: On the other hand, designing IoT applications is much Consent and Data Acquisition [CDA], Data Preprocess- more difficult than designing desktop, mobile, or web ing [DPP], Data Processing and Analysis [DPA], Data applications [32]. This is beacause a typical IoT appli- Storage [DS] and Data Dissemination [DD]. The CDA cation requires both software and hardware (e.g., sen- phase comprises routing and data reading activities by sors) to work together on multiple heterogeneous nodes a certain node. DPP describes any type of processing with different capabilities under different conditions [30]. performed on raw data to prepare it for another pro- Assessing an IoT application in order to find privacy cessing procedure [36]. DPA is, broadly, “the collection gaps is a complex task that requires systematic guid- and manipulation of items of data to produce meaning- ance. For these reasons, we believe that IoT development ful information” [15]. DS is the storage of raw data of would benefit from having a privacy-by-design frame- processed information for later retrieval and DD is the work that can systematically guide software engineers to transmission of data to an external party. assess (and potentially design new) IoT applications and We assume that all the data life cycle phases are present middleware platforms. Typically, systematic guidelines in all nodes in an IoT application to be utilised by soft- will generate a consistent result irrespective of who car- ware engineers to protect user privacy. However, based ried out a given assessment. Such a framework will also on the decisions taken by the engineers, some data life reduce the time taken to assess a given application or cycle phases in some nodes may not be utilised. For platform. example, a sensor node may utilise the DPP phase to average temperature data. Then, without using both INTERNET OF THINGS: DATA FLOW DPA and DS phases to analyse or store data (due to In this section, we briefly discuss how data flows in a hardware and energy constraints) the sensor node may typical IoT application that follows a centralised archi- push the averaged data to the gateway node in the DD tecture pattern [38]. This helps us to introduce privacy phase. guidelines and their applicability to different types of computational nodes and data life-cycle phases. As il- lustrated in Figure 1, in IoT applications, data moves PRIVACY-BY-DESIGN GUIDELINES from sensing devices to gateway devices to a cloud in- After reviewing existing privacy design frameworks, we frastructure [30].