Institute of Parallel and Distributed Systems University of Stuttgart Universitätsstraße 38 D–70569 Stuttgart Masterarbeit Privacy for the MBP IoT Platform Jakob Benz Course of Study: Softwaretechnik Examiner: PD Dr. rer. nat. Holger Schwarz Supervisor: Dr. rer. nat. Pascal Hirmer Commenced: April 15, 2020 Completed: October 31, 2020 Abstract The popularity of the Internet of Things is rapidly increasing and so is the range of IoT application scenarios. The prominent examples are Smart Homes, Industry 4.0 and Car2X. Undoubtedly, there are huge benefits for end-users in these scenarios. However, due to the pervasiveness of the Internet of Things, the amount of private and sensitive data captured in IoT environments is of great magnitude. A central IoT platform is often used to manage this data. That is, privacy concerns arise which have to be dealt with, e.g., by the vendors of IoT platforms. To address the privacy related issues in IoT environments, we propose a concept for privacy and access control particularly tailored for IoT environments. In a first step, an exhaustive evaluation of related work in the field of access control is conducted. We then present a generic end-to-end reference architecture for IoT environments. Based on this reference architecture, we examine the special requirements towards privacy and access control in IoT environments. Following that, we present a generic concept for IoT environments, that allows different ways of integration, provides flexible yet expressive specification of privacy settings, is highly customizable, and introduces minimal overhead for access control enforcement. The concept provides details about the integration into existing IoT environments, the access control workflow and components as well as the suggested domain model and evaluation algorithm. A concrete implementation is illustrated with the Multi-purpose Binding and Provisioning Platform (MBP) developed at the University of Stuttgart. 3 Kurzfassung Das Internet of Things wird immer beliebter und ist immer weiter verbreitet. Die bekanntesten Anwendungsszenarien umfassen Smart Homes, Industrie 4.0 und Car2X. Ohne Zweifel entstehen dadurch viele Vorteile für Endanwender. Da diese Anwendungsfälle aber mit der Erhebung und Speicherung großer Mengen an privaten Daten einhergehen, welche oftmals in zentralen IoT Platt- formen gespeichert werden, müssen z.B. Hersteller solcher Plattformen besondere Aufmerksamkeit auf den Datenschutz legen. In dieser Arbeit wird ein Konzept vorgestellt, das benutzt werden kann, um Datenschutz und Zugangskontrolle in IoT-Umgebungen umzusetzen. In einem ersten Schritt werden daher bereits existierende Ansätze und Arbeiten im Bereich der Zugangskontrolle evaluiert. Eine generische Ende-zu-Ende Referenzarchitektur für IoT-Umgebungen wird vorgestellt, basierend auf welcher die speziellen Anforderungen an ein Zugangskontrollsystem für IoT-Umgebungen erhoben werden. Als Hauptbestandteil dieser Arbeit wird das generische Konzept für Zugangskontrolle in IoT- Umgebungen vorgestellt. Dieses Konzept erlaubt verschiedene Arten der Integration, flexible und sehr ausdrucksstarke Spezifikation von Datenschutz-Einstellungen, ist hochgradig anpassbar und erweiterbar, und unterstützt eine effiziente Umsetzung der Zugangskontrolle. Das Konzept beinhaltet Details zur Integration, zum Ablauf der Zugangskontrolle und den involvierten Komponenten, sowie ein Domänenmodell und einen Algorithmus zur Evaluierung von Zugangsanfragen. Eine konkrete Implementierung wird für die an der Universität Stuttgart entwickelte Multi-purpose Binding and Provisioning Platform (MBP) vorgestellt. 4 Contents 1 Introduction 15 2 Basics 17 2.1 The Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2 Security & Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3 Related Work 23 3.1 Role-Based Access Control (RBAC) Models . . . . . . . . . . . . . . . . . . . . 24 3.2 Attribute-Based Access Control (ABAC) Models . . . . . . . . . . . . . . . . . 25 3.3 Access Control Models based on UCON . . . . . . . . . . . . . . . . . . . . . . 30 3.4 Capability-Based Access Control (CBAC) Models . . . . . . . . . . . . . . . . . 31 3.5 Other Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4 Requirements 33 4.1 End-to-End IoT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.3 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5 Conceptual Design 41 5.1 Architecture and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2 Access Control Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6 PoC Implementation for the MBP 51 6.1 Architecture of the MBP IoT Platform . . . . . . . . . . . . . . . . . . . . . . . 51 6.2 Scope of the MBP Access Control System . . . . . . . . . . . . . . . . . . . . . 51 6.3 Conceptual Aspects and Implementation . . . . . . . . . . . . . . . . . . . . . . 53 7 Evaluation 57 7.1 Requirements Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 8 Conclusion & Future Work 61 Bibliography 63 5 List of Figures 2.1 IoT Platform Reference Architecture according to [GBF+16] . . . . . . . . . . . 18 2.2 The MBP IoT Graphical Environment Modeling Tool [FHS+20] . . . . . . . . . 19 3.1 Existing access control models . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2 RestACL architecture according to [HS16c] . . . . . . . . . . . . . . . . . . . . 28 3.3 Abstract permission model according to [SM19] . . . . . . . . . . . . . . . . . . 29 3.4 UCON core components model according to [PS04] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.5 Alternative model according to [ZPSP05] . . . . . . . . . . . . . . . . . . . . . 30 4.1 End-to-End IoT Architecture adapted from [SGM20] [GBF+16] . . . . . . . . . 33 4.2 Health Care Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.1 Dataflow in IoT environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2 Access Control Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.3 Access Control Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.4 Access Control Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.1 MBP Architecture and Access Control Integration . . . . . . . . . . . . . . . . . 54 6.2 MBP Condition Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7 List of Tables 4.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 9 Listings 3.1 Example policy according to [YT05] . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2 Example according to [SH06] . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1 Policy with condition and constraint in JSON format . . . . . . . . . . . . . . . 49 11 List of Algorithms 5.1 Evaluation algorithm for access requests . . . . . . . . . . . . . . . . . . . . . . 48 6.1 Evaluation algorithm for access requests . . . . . . . . . . . . . . . . . . . . . . 56 13 1 Introduction Imagine your coffee machine, washing machine, and car have their own social media accounts and you can communicate or even talk to them like it was the most normal thing on earth? This is becoming reality with the Internet of Things (IoT), bridging the gap between the real and the digital world [OMEO17]. Nowadays, more and more objects in our everyday life are fitted with sensors or even actuators, turning them into smart devices. Fueled by recent power-efficient and low-cost communication technologies, these smart devices can be interconnected very easily [SM19]. There are a lot of already well-established application scenarios for the IoT, commonly referred to as SMART environments, e.g., SMART Homes [BLM+11]. Due to sensor technology becoming more sophisticated, versatile, and affordable, the number of smart devices with sensors and actuators is increasing significantly. However, the complexity of (initially) setting up an IoT environment with a large number of heterogeneous devices increases as well. The Multi-Purpose Binding and Provisioning Platform (MBP)1 has been developed at the University of Stuttgart to facilitate creating, modeling, and deploying IoT environments and to automate the process of connecting devices since doing so manually can be very cumbersome and costly. Once an IoT environment has been set up, the devices and respective sensors capture a wide range of data which requires quite a bit of data storage. Due to the resource-constrained and short-range-communication nature of such devices the data is hardly ever stored on the device itself, but rather outsourced to the cloud [ZCDV17] through a layer of communication middleware. Considering that most of the data collected in IoT environments should be labeled personal or sensitive – especially revisiting the SMART Home scenario and also enterprise-level use cases, where data may be confidential or even classified – security and privacy are inevitable. Unfortunately, both security and privacy are often treated negligently when it comes to IoT application scenarios [OMA15]. Although there is a wide variety of approaches to security and privacy, these are hardly ever applicable in the IoT context, due to its dynamic and ever-changing nature, completely different communication stacks, and scalability requirements necessitated by the immense amount of devices and sensors [SRGC15]. In addition to these architectural challenges, the great variety of opportunities that arise with the IoT at the same time calls for security and privacy measures that are adaptable and customizable to an extremely high degree while keeping the required expertise to a minimum. Although there has been a lot of work done in the field of security and privacy in the context of a modern computing environment, including but not limited to the IoT, existing approaches do not (completely) meet the special requirements of IoT environments. Therefore, the main focus of this work is on the development of a generic concept for privacy and access control in IoT environments. 1MBP GitHub Repository: https://github.com/IPVS-AS/MBP 15 https://github.com/IPVS-AS/MBP 1 Introduction As a first step, the basics related to the Internet of Things and privacy are briefly explained in Chapter 2. Then, an extensive survey of existing approaches towards privacy and access control, especially focusing on IoT platforms like the MBP, is discussed along with an assessment of their suitability in Chapter 3. Based on a generic end-to-end reference architecture for IoT environments, Chapter 4 contains the result of the requirements elicitation. Chapter 5 presents the core of this work, the concept for privacy and access control in IoT environements. The prototypical implemenation for the MBP is shown in Chapter 6 before evaluating the concept and discussing its limitations in Chapter 7. Finally, Chapter 8 provides a conclusion and an outlook on future work. 16 2 Basics This section provides some fundamental information relevant in the context of this work. An introduction to the Internet of Things is given in Section 2.1, including IoT platforms, a corresponding reference architecture, and a brief presentation of the MBP. Section 2.2 introduces and distinguishes the terms privacy and security in the context of this work. 2.1 The Internet of Things The essential idea behind the Internet of Things (IoT) is to connect heterogeneous, physical devices using the internet, creating a pervasive presence of Things [AIM10] in our everyday life, which is also referred to as “stringent connectedness” [Ray18] between the physical world and its digital twin. These Things can be Radio-Frequency Identification (RFID) tags, sensors and actuators, or also existing devices fitted with them, e.g., smartphones, household devices, cars, etc. The goal on the one hand is to enable users to communicate with these Things, on the other hand to enable the communication between them, paving the way for well-advanced application scenarios, which unquestionably will have a big impact on the way we experience our daily life. Additionally, the extent and scale of these use cases is virtually unlimited, e.g., Industry 4.0 and smart factories are already in place, there is even the term Factory of Things [Zue10]. Following up on the larger scale IoT application scenarios mentioned in the previous section, these especially demand for the corresponding infrastructure and comprehensive administration tools to manage the millions of devices, the connection and communication between them, as well as the data captured by sensors of these devices. This is exactly what IoT platforms have been developed for. With the IoT gaining more and more attention, the number of already available IoT platform solutions increases alike. Although the offered functionality is often similar [GBF+16], due to the heterogeneity of the Things and many different (communication) standards, the technology stacks used in available IoT platforms are very heterogeneous themselves. The range of state-of-the-art IoT platforms includes both open-source solutions, such as ThingsBoard1, FIWARE2, and of course the MBP, as well as proprietary ones, e.g., Amazon Web Services IoT3 [GBF+16]. When developing an IoT platform or frameworks for or on top of one, such as the privacy concept developed in this work, the downside of the heterogeneity among existing IoT platforms is noticeable, as there is no commonly accepted standard for IoT platform architectures. Guth et al. propose an abstract and generic reference architecture for IoT platforms [GBF+16] which is depicted in Figure 2.1. It comprises three layers: the device layer, the middleware layer, and the application layer. On the bottom most level there are the devices, to which sensors and actuators can be connected using 1Thingsboard Homepage: https://thingsboard.io 2FIWARE Homepage: https://www.fiware.org 3Amazon Web Services IoT Homepage: https://aws.amazon.com/en/iot/ 17 https://thingsboard.io https://www.fiware.org https://aws.amazon.com/en/iot/ 2 Basics 1 IoT Integration Middleware Gateway Sensor Actuator Device Driver Driver Application Figure 2.1: IoT Platform Reference Architecture according to [GBF+16] respective drivers. Sensors measure environmental information, e.g., the current room temperature or the location of a smartphone. Actuators on the other hand are able to manipulate their environment by performing, e.g., mechanical, optical, or acoustical actions. In order to access the data gathered by sensors and to send commands to actuators, the integration middleware layer provides the means that the application layer needs to communicate with the devices. Direct communication between the integration middleware and a device is possible if the device is compatible in terms of the transport protocol, such as HTTP or MQTT, and data format, such as JSON, or XML. In case a device is not capable of directly communicating with the integration middleware, a gateway can be used as an adapter, which transforms and forwards the data exchanged between devices and the integration middleware. The functionality of the integration middleware is not limited to the above mentioned use cases, but can also encompass data (pre-) processing logic or even a rules engine [GBF+16]. The application layer consists of software artifacts that implement IoT application scenarios using sensors and actuators. Furthermore, it can provide insights by aggregating and processing various sensor data which are then presented to users through different kinds of dashboards. For administrative purposes, the application layer usually provides a user interface for managing devices, sensors, and actuators as well as the way they’re interconnected. We use this reference architecture throughout this work, since the abstract design enables it to be used as the architectural basis for the concept for privacy and access control in IoT environments, which in turn increases the concept’s degree of reusability. 2.1.1 The Multi-purpose Binding and Provisioning Platform (MBP) The Multi-purpose Binding and Provisioning Platform (MBP) has been developed at the University of Stuttgart as a working prototype for an open-source IoT platform [FHS+20]. The primary target is to ease the management of IoT environments along all lifecycle phases. At first, a new IoT 18 2.1 The Internet of Things environment has to be designed and modelled, which is faciliated by the MBPs own environment modeling tool (cf. Figure 2.2). Once a new IoT environment has been modelled, it has to be deployed, i.e., the application layer (cf. Figure 2.1) needs to be enabled to access the sensors and actuators via the respective devices, which is called binding [HWBM16b]. This can be done using either the MBP’s web frontend or the RESTful API, since both of them offer the functionality to register and manage devices, sensors, and actuators [HBS+16]. The MBP employs a set of small scripts to control the devices, i.e., to start or stop them, and to extract sensor data and control actuators. These adapters scripts don’t have to be device-specific and can be implemented generically, allowing to re-use them among multiple devices [HWBM16a] . Several ready-to-use adapter scripts can be found in the MBP Operators Repository4, nevertheless it is possible to add custom adapter scripts. The middleware layer is implemented using a Mosquitto MQTT Broker5, to which the adapter scripts publish the extracted sensor data [FHS+20]. The rule modeling tool enables users to create automated workflows in an MBP-managed IoT environment by defining rules using the event-condition-action pattern, where events are based on Complex Event Processing (CEP) [CM12] queries on sensor data and actions specified for actuators [FHPM18]. That way, also non-expert users can, e.g., easily add some automation to their homes. Fig. 1. The MBP UI by connecting to the MBP registration hotspot. Once an IoT environment is modeled and saved, it can automatically be registered with the MBP through the MBP UI. At this point, basic monitoring information about IoT objects can be already visualized in dashboards, such as network accessibility, CPU usage, and CPU temperature of a device. B. Deploying IoT environments The MBP provides several ready-to-use extraction and control operators in the form of scripts. One exemplary extraction operator reads measurement values of an analog temperature sensor (TMP36 module) connected to a Raspberry Pi. This operator sends the extracted values to the MBP through MQTT, a publish/subscribe communication protocol. In the MBP, such operators can be simply linked to registered devices and, in sequence, be deployed onto these devices. Through this approach, sensors are bound automatically to the MBP and measured sensor values can be live-visualized immediately, and furthermore, are available as historical data. Nonetheless, the MBP also enables the users to provide their own operators, which can be implemented in any programming language. The MBP only requires the existence of specific lifecycle management scripts (e.g., install, start, or stop) for the operator, in order to be able to automate the deployment of the user-defined operators. These management scripts are executed by the MBP onto IoT devices at deployment time. The application logic of these management scripts can be still defined by the user, e.g., specifying necessary software that needs to be installed. In this way, users can create operators fulfilling their specific requirements, such as the use of specific hardware types or programming libraries. C. Monitoring IoT environments Once IoT objects are bound to the MBP, these IoT objects can be monitored by the users through provided dashboards. These dashboards show status and statistical information about IoT devices, sensors, and actuators. Furthermore, both live sensor data and historical sensor data can be visualized. To realize an automatic monitoring based on sensor data, and Fig. 2. The MBP UI - IoT environment modeling tool furthermore, to trigger actuators automatically based on recog- nized conditions, the MBP provides the means for creating IoT applications based on user-defined rules. Such rules, which are based on the event-condition-action approach, can be defined on the graphical rule modeling tool integrated in the MBP. These high-level rules are then transformed into complex event processing queries and are evaluated using corresponding CEP systems [4], which are able to provide an efficient, timely sensor data processing. An example of an IoT application that can be modeled with the MBP is a heating, ventilation, air conditioning (HVAC) system, in which the temperature of a room is continuously monitored in order to recognize and react when the temperature exceeds or goes below the thermal comfort zone. D. MBP setup The MBP can be installed by an installation script on Linux or it can be used as a docker container. After installation, the MBP user interface can be accessed through an internet browser (we recommend Chrome or Firefox). The MBP user interface is based on Bootstrap templates and is implemented in Angular JS. Furthermore, the data management and pro- cessing in the MBP is based on a lambda-based architecture, in which both live and historical data can be managed and processed. To store measurement data, i.e., sensor data and timestamp-based data, we use a time-series database. Further metadata are stored in a NoSQL database to clearly separate data and metadata. Furthermore, in [5], we provide an ap- proach realizing the placement of operators of a data stream processing model onto IoT environments. In this approach, requirements of operators (e.g., minimum required storage) and capabilities of IoT objects are searched and matched by algorithms for an optimal placement decision. III. MBP DEMONSTRATION In this section, we explain how a simple IoT scenario, a smart office, can be realized with the MBP. An office is defined as a room in which people conduct their work tasks. In order to make an office smart, it can be enhanced with computing power and sensing and acting capabilities through Figure 2.2: The MBP IoT Graphical Environment Modeling Tool [FHS+20] 4MBP Operators Repository: https://github.com/IPVS-AS/MBP/tree/master/resources/operators 5Eclipse Mosquitto Homepage: https://mosquitto.org 19 https://github.com/IPVS-AS/MBP/tree/master/resources/operators https://mosquitto.org 2 Basics The technology stack of the MBP further comprises two databases, a MongoDB6 for device (meta) data and user data, and an InfluxDB7 as a time series database for sensor data, allowing the presentation of both current and historical data in the web frontend. The backend is hosted on an Apache Tomcat application server8. Finally, an Android smartphone app is available as an alternative frontend. 2.2 Security & Privacy As sensors are becoming increasingly ubiquitous and sophisticated [DTS+16], awareness of privacy and security risks among users increases likewise [ZACF18]. Undoubtedly, privacy and security are of vital importance. In the following, the terms security and privacy are briefly explained. Security in the context of information technology is built on three main aspects, namely confiden- tiality, integrity, and availability, which together form the so-called CIA-Triangle [WM11]. While confidentiality measures protect secure entities from unauthorized access in general, integrity mea- sures are designed to prevent the unauthorized manipulation of said entities, e.g., the unauthorized update of database records, to ensure that reliable and correct data can be provided to authorized users. Countermeasures to protect confidentialiy and integriy include, among others, authentication, access-control lists, and data encryption. The purpose behind the third aspect, availability, is to guarantee that authorized users actually are able to access the entities they have been granted access for [MYAZ15]. While security is focused more on protecting personal data against unwanted access in general, such as malicious attacks, privacy relates to the right of users to control the extent to which they want to share their personal data, e.g., when and with whom to share their camera roll. With modern computing paradigms such as Cloud Computing and the Internet of Things, where privacy is reduced due to the omnipresence of intelligent devices [SNCC18], sophisticated privacy-preserving techniques are inalienable. Since the data captured in IoT environments is mostly privacy-sensitive, they become attractive targets for attacks. In order to preservce the privacy of (IoT) users and also to protect their data from unwanted access, a widely used mechanism are access control systems. These systems manage the process of determining whether some requesting entity, e.g., a user or an application, should be granted access to some resource. Thereby, the decision-making process might be based on certain conditions, that have to hold in order to grant access. Moreover, the access control system could decrease the level of detail of the data that is presented to the requesting entity, e.g., by blurring images or reducing the accuracy of a location. For instance, hospital staff needs to have access to personal information of patients for administrative purposes, but should not be able to access the patients medical records. On another note, the data recorded in smart buildings might result in the disclosure of information of people and their habits that they don’t want to share, such as when and where they went and what they did [PDY+17]. Going beyond the domain of personal and home IoT 6MongoDB Hompage: https://www.mongodb.com 7InfluxDB Homepage: https://www.influxdata.com 8Apache Tomcat Homepage: https://tomcat.apache.org/download-80.cgi 20 https://www.mongodb.com https://www.influxdata.com https://tomcat.apache.org/download-80.cgi 2.2 Security & Privacy application scenarios towards enterprise and government use cases, legal issues associated with privacy and access control have to be considered, such as legal requirements regarding the logging of production steps [SWW15]. While the idea behind and the purpose of different access control models is more or less the same, the concept and implementation differ substantially. The next chapter presents various categories of access control models and related work within these categories, respectively. 21 3 Related Work Many privacy-preserving approaches, models, frameworks, and mechanisms have been proposed in the context of the IoT. This chapter presents the most relevant work grouped by the following categories: • Role-based access control models • Attribute-based access control models • UCON-based access control models • Capability-based access control models • Other models The concepts of each category is briefly explained before a set of representative approaches is presented. Figure 3.1 shows an overview of the work done in the aforementioned categories of access control. 8d Access Control Models UCON-BasedAttribute-Based Capability-BasedRole-Based Other [PS02] [Par03] [PS04] [ZPSP05] [GW11] [AS11] [BYG14] [DV66] [Gon+89] [MAPP+13] [AMPP12] [AMP+13] [GPR13] [HJMS13a] [KBB+03] [BAAO15] [AD06] [KDBK09] [OMEO17] [SO17] [CZH19] [ZT10] [BMA15] [JXC12] [KT08] [KMJ+05] [MXCM16] [Cpp20] [SCFY96] [YT05] [SH06] [She09] [SSXL09] [DHYJ12] [ZWWL14] [HNBH12] [AK05] [GO04] [AS02] [CGLO08] [JF06] [CCT07] [WO11] [AEH18] [AEH19] [HS15] [HS16c] [Hüf19] [HHM+17] [SM19] [SGM20] [DWHY18][HFK+13] Figure 3.1: Existing access control models 23 3 Related Work 3.1 Role-Based Access Control (RBAC) Models The role-based access control model (RBAC) is the most widely accepted access control method [TJA10]. The core concept of RBAC uses roles with a set of associated permissions. These roles are then assigned to users, which are able to use the permissions associated with the respective roles [FSG+01]. Thereby, system administrators can easily manage users and their respective permissions, since roles can be predefined and reused, e.g., when creating new users [CW13]. Core RBAC can be extended by introducing role hierarchies allowing roles to extend other roles, and constraints, allowing for separation of duties, which guarantees that one individual cannot be assigned mutually exclusive roles, e.g., purchasing manager and accounts payable manager [SCFY96]. However, traditional RBAC is not able to cope with the high dynamic, heterogeneity, and scalability requirements of the IoT [OMEO17]. A major problem with RBAC in IoT environments is role-permission explosion due to the specification of permissions in terms of object identifiers, i.e., individual objects [RJK15]. In the following, several approaches that adopt traditional RBAC towards access control solutions for the IoT are presented. Zhang and Tian [ZT10] propose a service-based approach to facilitate integration and management of physical objects, i.e., the functionality of IoT devices can be accessed through a set of standard services. They extend RBAC by introducing contextual constraints to allow the consideration of time, location, and other environmental variables in the evaluation of an access request. Such access requests are targeted at services offered by IoT devices. Prior to invoking a service, authorization of the requesting user is verified. Although the service-based approach greatly benefits the integration of heterogeneous IoT devices, this approach has been critized (e.g., by Ouaddah et al. [OMEO17]) for a number of shortcomings, including role-permission explosion, the fact that roles are only assigned to users excluding other devices and services, and missing description of the way the contextual information is captured from the devices’ environments. Additionally, their approach has only been evaluated in a case study, omitting a prototypical implementation and implementation details. Barka et al. [BMA15] present another approach based on RBAC that is focused on the Web of Things (WoT). Although they establish a careful mapping between the entities in RBAC and the WoT, such as WoT-participant/RBAC-subject and WoT-Thing/RBAC-object, the set of mappings does not include any information on how roles are mapped to the WoT entities and components. The proposed architecture is based on the concept of a modified version of the ISO reference monitor [ISO96] [MASM13] and employs two facilities: an Access Control Enforcement Facility (AEF) and an Access Decision Facility (ADF). The AEF intercepts every request to access an object and forwards it to the ADF, which evaluates the request using the role-based policies and returns the decision to the AEF. This decision is then enforced at the AEF. Due to the completely centralized access control architecture, the WoT Things (abstractions of physical or virtual entities in the WoT [W3C20]) do not have any impact on the decision-making process. The problem of role proliferation is addressed by using role parameterization [FKC03]. Even though RBAC is capable of incorporating constraints, the authors do not describe if and how constraints are included in their approach. Furthermore, the decision whether access is granted or not, does not comprise any contextual information. Additionally, access is either granted fully or not at all, without allowing constraint access to resources. 24 3.2 Attribute-Based Access Control (ABAC) Models Another approach targeted at the WoT and based on RBAC is presented by Jindou et al. [JXC12]. They propose an extension to Sandhu’s standard RBAC model [SCFY96], named SARBAC, integrating Social Network Services (SNS), e.g., Facebook, and attributes, mainly focusing on the usability aspect of access control in the WoT. Thereby, a provider, which acts as the device owner, is able to configure user-role assignments based on the data obtained from user profiles (e.g., age, gender, occupation) and relationships between several user profiles, called social links (e.g., family, colleague). Likewise, role-permission assignments and policy definitions can be done using device attributes, e.g., a set of tags or the location. However, device-to-device communication is not addressed. Also, this approach is tightly coupled and highly dependent on the respective SNS provider, which makes the SNS provider an implicit trusted third party [OMEO17]. Kulkarni et al. [KT08] dynamically integrate context into RBAC by adding a context management layer on top of the access control layer, creating the Context-Aware RBAC Model (CA-RBAC). They aim at securing user data while simultaenously enabling third parties to access user data in case of, e.g., an emergency. This is achieved by establishing a modular context structure which is divided into three context conditions: normal, critical, and emergency. Although this structure is very easy to understand and user-friendly, it is very limited due to the non-generic and pre-defined context conditions. Kim et al. introduce CWAC [KMJ+05], which employs a state checking matrix (SCM), a state checking agent, and a context-aware agent to monitor the context of users and dynamically adjust the role of the user, respectively. However, only user-related contextual information is incorporated into the access decision-making process. A major issue with both CA-RBAC and CWAC is the limited scalability and inefficiency, that can be caused by role-proliferation and/or improper configuration. In addition to that, the previously discussed disadvantages can be identified as well. Several other role-based access control approaches have been proposed, such as Break-the-Glass Access Control (BTG-AC) by [MXCM16] [MXCM14] based on the Break-the-Glass Role-Based Access Control BTG-RBAC) model by Ferreira et al. [FCF+09], which offers the possibility to execute break-the-glass actions (e.g., override access policy) to authorized users, or the framework proposed by Chatterjee et al. [CPP20] which enables on-chain access control based on smart contracts in the context of Distributed Ledger Technology (DLT) with a clear separation of business logic and access control logic. However, these and other role-based approaches focus on different target environments. 3.2 Attribute-Based Access Control (ABAC) Models Although the role-based approach is well suited for use cases where the set of permissions and the set of roles associated with users change infrequently, environments like the IoT demand for highly dynamic and flexible access control schemes. A widely used method is attribute-based access control (ABAC). We use the definition of Hu et al. [HFK+13]: A logical access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships that describe the allowable operations for a given set of attributes. 25 3 Related Work Using attributes, a more comprehensive and detailed input into the decision-making process can be achieved while simulateneously eliminating the need to define explicit user-permission mappings due to the attribute-based policies that can be applied generically to every requesting entity [AEH18]. However, challenges arise with large sets of policies or also very complex policies, which is very likely in enterprise IT landscapes [HKFV15], since evaluating (many) complex policies can be very expensive in terms of computing power. The eXtensible Access Control Markup Language (XACML) [Sta05] provides a comprehensive, but complicated policy specification and evaluation mechanism with quite a bit of performance overhead [KAPI18]. Considering the rather resource-constrained nature of the IoT, an efficient, yet expressive and easy-to-understand policy specification and evaluation technique is desired. In the following, several attribute-based access control models are discussed. An early attribute-based approach to access control for web services has been proposed by Yuan and Tongin [YT05]. They evaluate challenges and requirements regarding access control and propose a new ABAC approach based on attributes of subjects, objects, and the environment. Their model includes an authorization architecture, which is based on Attribute Authorities (AA) creating and managing the attributes of subjects, a Policy Enforcement Point (PEP) requesting access decisions and enforcing them, a Policy Decision Point (PDP) evaluating policies and making the access decision requested by the PEP, and a Policy Authority (PA) managing the access control policies. These policies are defined as Boolean functions but evaluated using XACML. A sample policy (rule) is shown in Listing 3.2, where a subject may access the resource with the name ApprovePurchase, if it has the value Manager for the attribute Role. 1 R: can_access(s, r, e) ← 2 (Roles(s) = ''Manager'') ∧ 3 (Name(r) = ''ApprovePurchase'') ∧ Listing 3.1: Example policy according to [YT05] However, the authors only give an overview of the relation between the attributes and policies and focus more on policy fomulation without providing any implementation details with regard to policy evaluation. Furthermore, the decision results only encompass fully granting or fully denying access. Similar to the previous approach, authors in [SH06] propose WS-ABAC, an attribute-based model for web services. They defined policies as a triple , where S identifies the subjects the policy includes, srv is the respective web service, and C is the attribute constraint, which is a set of attribute conditions of the form . A sample attribute constraint according to the WS-ABAC model is shown in Listing 3.2, where access to the web service is limited to a manager, that requests the service from his/her office between 9am and 5pm. 1 C: Identity = ''manager'' ∧ Time ≥ 09:00 ∧ Time ≤ 17:00 ∧ Location = ''office'' Listing 3.2: Example according to [SH06] The attribute constraints can be combined using the logical AND or OR operator. However, the set of allowed operators inside the constraint is limited to <, >, ≤, ≥,=,,. An access request has the form , where U identifies the requesting user, srv identifies the requested web service, and RA contains the runtime attributes, which are used to evaluate the attribute constraints of the matching policies. They present an XACML-based authorization architecture similar to the one by Yuan and Tong [YT05], and in addition to that a trust negotiation architecture, which allows 26 3.2 Attribute-Based Access Control (ABAC) Models regulation over when and how secure information, such as user credentials, is transferred from the requestor to the service provider, e.g., if further proof is required. However, their approach has been critized (e.g., by Servos and Osborn [SO17]) for being minimalistic and the lack of a complete and foundational attribute-based model for access control. According to Servos and Osborn [SO17], several approaches related to the previous two models have been proposed [DHYJ12] [SSXL09] [She09] [ZWWL14], all of which basically have the same shortcomings. Several hybrid models that combine role-based elements with attribute-based access control have been proposed [SO17]. The most basic solution for the combining the two models, is to use roles as simply another attribute. Huang et al. [HNBH12] propose a two-layer-architecture with a role-based frontend and a backend, which controls access based on attribute-based policies. This separation enables different levels of access control managament. Daily reviews of role assignments can be done using the frontend while rather complex administration operations, such as defining policies, can be performed in the backend. However, this advantage only maintains as long as all of the attribute-based policies can be mapped to the purely role-based model of the frontend, i.e., identity-less policies will cause issues [SO17]. The concept of parameterized roles has been addressed by Abdallah and Khayat [AK05], as they simply add a condition that is evaluated before a certain permission is granted. In contrast to that, Ge and Osborn [GO04] incorporate the attributes of subjects as well as the content of objects through locigal expressions similar to XPath [CD+99], which are evaluated at runtime based on subject attributes obtained from sessions. Another way to combine RBAC and ABAC is to assign roles based on attributes. Al-Kahtani and Sandhu [AS02] propose Rule-Based RBAC (RB-RBAC) which dynamically assigns roles to users at runtime based on certain attribute expressions, whereas attributes of objects are not considered. A similar model is presented in [CGLO08], where roles are assigned likewise, but with the additional option to define constraints for roles. Moreover, Semantic Web Technologies [HKR09] have been used in several attribute-based approaches. Dong et al. [DWHY18] propose the Context-States-Aware Access Control (CSAAC) Model which combines ABAC with both role-based elements as well as context-states-awareness. They provide an abstract logical architecture, which extends the basic XACML reference architecture [Sta05] with state-tracking support. Policies are defined using the Sematic Web Rule Language1 (SWRL). However, even the authors themselves state that implementing an access control system using Sematic Web Technology such as SWRL, is very difficult and extremely complex, which probably is the reason why they did not provide any implementation details or prototypical implemention. Servos and Osborn [SO17] provide a list of other approaches that also use Semantic Web Technologies, including [JF06], [CCT07], and [WO11]. However, all of these models aim at assigning roles through the evaluation of attributes, which is not the goal of this work. Furthermore, none of the mentioned models uses attributes of objects and the environment, besides the approach of Jin and Fang-chun [JF06], which only encompasses temporal environment information [SO17]. A different approach is based on automatic policy specification [AEH18]. This automatic policy specification mechanism uses two types of contexts, a guard context, which is defined by an administrator or device owner and can be seen as a set of preconditions (application dependent variables and thresholds), that have to be met in order to access the respective resource, and an operational context, which contains real-time measurements of attributes of the subject, object, and 1W3C SWRL Proposal: https://www.w3.org/Submission/SWRL/ 27 https://www.w3.org/Submission/SWRL/ 3 Related Work resource/operation. These contexts are defined using a set of predicates, so-called primitive facts, which basically are tuples of key-value pairs. However, so-called resource profiles, desribing the respective attribute domains through a range of possible values, have to be defined first. Access control policies are configured through a user-friendly web interface, and afterwards converted into primitive facts, which represents the notion of automatic policy specifciation, although the administrator is required to approve the automatically generated policy. Flexibility, maintainability, and reusability are constrainted due to the non-generic nature of resource profiles and the fact that access decision results are limited to full access or no access at all. The Continuous Access Policy Enforcement (CAPE) framework also proposed by Alkhresheh et al. [AEH19] addresses the aspect of continuity in access control systems, which is necessary since the context of entities in IoT environments changes frequently. Automatic policy specification [AEH18] and continuous policy update and enforcement is provided using two main components: a Session Registry (SR) maintaining information regarding active (access) sessions, and a Context Monitor (CM) continuously observing all operational contexts and checking for policy updates, i.e., changed guard contexts. If necessary, access decisions are re-evaluted, e.g., because a subject’s operational context does not match a corresponding guard context anymore. Despite the optimized adaptability of access control policies in highly dynamic IoT environments due to continuous re-definition of primitive facts and re-evaluation of access decisions at runtime, it has to be mentioned, that this approach produces performance overhead. The authors present a short performance evaluation of the access response time and the re-enforcement time. However, they state that CAPE is suitable for large-scale IoT environments, while limiting the number of attributes to only 13 and the number of primitive facts to only 1000 when investigating the performance of re-enforcement operations. Additionally, implementation details or a prototypical implementation are not provided. Hüffmeyer et al. propose RestACL [HS15] [HS16c] [Hüf19], an access control language for RESTful services, which provides a resource-oriented high-level architecture and policy specification model for integrating access control into RESTful environments. The proposed architecture is shown in Figure 3.2. A RESTful server receives requests from RESTful clients and forwards requests to 3 RESTful Client RESTful Server Domain Policy Repository Access Control System Attribute Provider Figure 3.2: RestACL architecture according to [HS16c] secured resources to the Access Control System, which contains the decision-making logic. For computing an access decision, it uses the domain (model), which provides a mapping between resources and policies, the Policy Repository holding all policies, and an optional Attribute Provider that can provide additional attributes that cannot be obtained from the request itself. RestACL policies comprise an identifier, a priority in case more than one policy is defined for a resource, 28 3.2 Attribute-Based Access Control (ABAC) Models a (composite) condition, which holds a function to compare arguments, and an effect indicating the action to perform, e.g., grant access, if the condition holds. Furthermore, this model allows parameterized access, i.e., access to only parts of resources, such as filtered lists. In addition, it is possible to use URI templates when defining the set of policies for a (sub-) resource, which facilitates the administration of resource-policy mappings. A formal comparison with XACML is presented by Hüffmeyer and Schreier in [HS16b] and [HS16a]. The results indicate significant performance advantages regarding processing time and memory consumption compared to already optimized versions of XACML. The only downside of RestACL is the lack of partial or gradual access to resources. However, this can be achieved by optimizing the expressiveness of the effect parameter in policies. SitAC, a system for situation-aware access control, is proposed by Hüffmeyer et al. [HHM+17]. This system is built on top of RestACL and the situation recognition system SitOPT [WSBL15] [HWS+15] [SHWM16]. Access decisions are based on attribute-based policies and real-time situation recognition using sensor values. However, the authors only provide a high-level architecture and describe concepts but no (prototypical) implementation. Furthermore, devices and sensors are managed by the SitOPT Resource Management Platform (RMP), which requires manual device, sensor, and service registration and administration, which can be cumbersone in large-scale IoT environments. Stach and Mitschang introduce ACCESSORS [SM19], a data-centric approach to modeling permissions in IoT privacy systems. They reason that humans think in a data-centric way, which is why existing permission models are not suitable for the IoT. Therefore, data abstraction is used to eliminate the need to define a separate rule for each data-source, e.g., a particular sensor, if a user wants to protect a certain type of personal data, possibly originating from multiple data sources. Figure 3.3 illustrates the basic structure of an ACCESSORS permission. Besides the data4 Context Abstraction Rule Core Constraint Abstraction User Abstraction Data Abstraction Data Source Abstraction Data Sink Abstraction Figure 3.3: Abstract permission model according to [SM19] abstraction element, ACCESSORS provides abstractions for users, contexts, and constraints. The user abstraction can be used to distinguish between different requesting entities, such as applications, devices, or users. The context abstraction enables the selective activation of rules, e.g., only if a certain situation occurs, while the constraint abstraction provides means to grant or deny access to data on the one hand, and to limit the access to data, e.g., to a certain type of data, on the other hand. The authors illustrate application scenarios of ACCESSORS for both the back-end layer and the smartphone layer, yet they do not provide any implementation details. 29 3 Related Work A simplified version of ACCESSORS is used in DISPEL [SGM20], a distributed privacy management platform for the IoT. In contrast to most existing privacy systems, DISPEL introduces data protection at the source level, i.e., access to sensor data is granted individually to authorized applications, rather than storing sensitive data in a central database and controlling access to it. Once access has been granted to an application, a gateway extracts data from the respective device. Afterwards, several privacy plugins can be used to transform sensitive data, e.g., to reduce the accuracy of a location prior to forwarding the data to the inquiring application. ACCESSORS follows the privacy-by-default approach, that is, applications initially do not have any permission. Permissions to access data have to be granted by users for every application and every application purpose individually, which causes substantial overhead in terms of permission administration. 3.3 Access Control Models based on UCON The usage control (UCON) model has been proposed by [PS02] [Par03] [PS04] as a conceptual model for session-based access control introducing support for the mutability of attributes and decision sustainability, both of which are very important in the IoT context. Sustainable decision 7 Authorizations Rights Obligations Subjects Objects Attributes Attributes Conditions Usage Decisions Figure 3.4: UCON core components model according to [PS04] 6 Rights Usage Decisions Authorizations Subjects Objects Attributes Attributes Obligations Conditions Figure 3.5: Alternative model according to [ZPSP05] making is achieved by continuous permission evaluation and enforcement, i.e., authorization is enforced before, during, and after the access execution. Thereby, access might be revoked if certain conditions are not satisfied anymore due to changed attribute values. The core elements of the UCON model are shown in Figure 3.4. Subjects are entities that can aquire rights to access objects. Thereby, a right contains a set of usage functions that defines to what extent a subject can access or use an object. In contrast to other access control models, rights are not predefined, e.g., in an access control list, but rather determined exactly when an access request is made. Park et al. describe authorizations as functional predicates, which are evaluated by access decision routines in order to determine whether certain rights should be granted. Environmental information is considered through the incorporation of conditions in the decision making process, e.g., a certain right should only be granted during daytime. Lastly, using obligations, subjects can be forced to fulfill, or at least to agree on the fulfillment, of some mandatory actions either before the access is granted or during ongoing access. Note that both the authorizations and the obligations have to be fulfilled by the respective subject, while the conditions must be met by the environment. An alternative interpretation of the UCON model has been proposed in [ZPSP05], which emphasizes the usage 30 3.4 Capability-Based Access Control (CBAC) Models decisions, while the original version focuses on the relationships between the core components. It has to be noted that the aspect of administration and configuration regarding authorizations has not been addressed yet. Guoping and Wentao propose an abstration of the UCON model in the IoT [GW11]. They provide a mapping between entities in UCON and the IoT and an assessment model based on fuzzy theory. Additionally, they present several small (theoretical) experiments to prove the expressiveness of the UCON model in the IoT context. However, the feasibility for implementation in real access control systems is not addressed [OMEO17]. Bai et al. present ConUCON [BYG+14], which incorporates context information into the usage control model aiming at enhancing data and resource protection in the context of the WoT. They provide the design and implementation for two specific use cases, a Smart Home platform and a remote appliance management prototype. However, the process of policy administration is quite cumbersome as the XML-based policies in ConUCON are complex, since the authors state that their policy model is derived from languages like XACML and SAML without explicitly defining which parts they use from which language. Furthermore, their approach is mainly focused on the WoT, which makes its suitability for IoT platforms questionable. Similarly, Almutairi and Siewe [AS11] propose CA-UCON, a context-aware usage control model, which aims at improving the quality of service through access continuity, since in the original UCON access might be revoked if the environment changes, even if the subject still meets the requirements of the authorizations and obligations. In this case, CA-UCON tries to adapt to the new environmental situation by triggering certain actions without disrupting ongoing access sessions. However, details about which types of rules of changes in the envrionment their approach is applicable to are not provided. 3.4 Capability-Based Access Control (CBAC) Models Dennis and Van Horn [DV66] first introduced the concept of a capability. Thereby, a capability is a token, ticket, or key that enables the entity holding it to access certain resources. Although the concept of capability-based access control faces two major downsides, namely the problem of capability propagation and revocation [Gon+89], it has been adopted in a wide range of IoT related systems [OMEO17]. Gong proposed the Secure Identity-based Capability System (ICAP) [Gon+89] to address the aforementioned drawbacks. The difference between the traditional capability-based approach resides in storing the identity of the subject along with the operation, aiming at facilitating capability propagation and improving the efficiency of capability storage [OMEO17]. A number of extensions to ICAP have been proposed [MAPP+13] [AMPP12] [AMP+13]. Gusmeroli et al. propose CapBAC [GPR13], a capability-based access control model for the IoT, which employs a central policy decision point for all authorization-related procedures and a separate capability revocation service. Similar to this approach, authors in [HJMS13b] [HJMS13a] propose DCapBAC, a distributed capability-based access control model, which implements the authorization functionality on IoT devices rather than a central platform. DCapBAC has been extended by authors in [BHS16] to create a trust-aware model based on fuzzy logic. However, 31 3 Related Work all of the discussed capability-based approaches lack at least one the following requirements: context-awareness, fine-grained policy definition, dynamic and continuous policy enforcement, or lightweight computation mechanisms. 3.5 Other Models For the purpose of completeness, this section provides a brief summary regarding other access control models. Organization-based access control (OrBAC) [KBB+03] extends the classic role-based access control model by adding an abstract level in order to enable administrators to specify policies independent of the actual use case/implementation. Approaches based on OrBAC include SmartOrBAC [BAAO15], Multi-OrBAC [AD06], and PolyOrBAC [KDBK09]. However, since these approaches ar based on OrBAC, which extends RBAC, the disadvantages dicussed in Section 3.1 apply as well. Other approaches include task-based models, cryptography-based models, modifications and/or simplifications of XACML, and combinations of the previously mentioned appraoches. These are not be discussed here, since they are beyond the scope of this work. The interested reader is referred to survey papers by Ouaddah et al. [OMEO17], Servos and Osborn [SO17], and Cai et al. [CZH+19]. 32 4 Requirements This chapter presents the result of the requirements elicitation regarding general privacy in the context of the IoT. At first, a generic end-to-end IoT architecture is created which acts as a reference model for the requirements and conceptual model of the privacy and access control framework developed in this work. Along with this architecture we present a representative use case to help deduce the functional and non-functional requirements, presented later in this chapter. The next step is to conceptualize the design of the privacy framework based on these requirements, which is discussed in the next chapter. 4.1 End-to-End IoT Architecture The end-to-end IoT architecture depicted in Figure 4.1, which is based on the architecture in [SGM20] and the reference architecture for IoT platforms by Guth et al. [GBF+16], provides insight into the dataflow between the components and entities in an IoT environment. This architecture9 Health App End Users Smart Home Application Temperature Sensor AC Control Surveillance Camera Smartwatch GPS Raspberry Pi SmartphoneGateway IoT Platform Untr us ted Zone Backend Layer Application / End-User Layer Edge Layer Perception Layer Figure 4.1: End-to-End IoT Architecture adapted from [SGM20] [GBF+16] 33 4 Requirements comprises four layers and thereby slightly deviates from the standard three-layer IoT architecture. The reason for this lies in connectivity-constrainted devices that cannot directly communicate with other devices and need a gateway, such as a smartphone connected via Bluetooth [SGM20]. Therefore, things like sensors, cameras, smart watches, or actuators reside in the perception layer are connected to, e.g., a Raspberry Pi, that is assigned to the edge layer, which is new compared to the standard three-layer architecture. In order to interconnect all these devices, the backend layer typically hosts a central IoT platform, which enables communication between the devices as well as data accumulation, storage, and analysis. Furthermore the backend layer provides the interface to the application and end-user layer, which covers (third-party) applications, such as health care apps or Smart Home solutions accessing data through an exposed API, and end users that access data through a graphical interface, e.g, an IoT platform web frontend. The top most layer is classified as an untrusted zone, since it encompasses third-party software and other users, for which no reliable assumptions can be made in terms of trustworthiness [SGM20]. We refrain from listing an exhaustive set of use cases and rather present an in-depth discussion of one representative use case which serves both as an illustration of the presented architecture and a foundation for the requirements eliciation. The health care domain is perfectly suited for demonstrating both the emerging opportunities as well as the privacy concerns that come along with them. Figure 4.2 illustrates an example application scenario for a health care IoT platform. The patient weares a smartwatch that continuously monitores 10 Health Care Platform Health Care Patient with Smartphone monitors heart rate Smartwatch with Heart Rate Sensor connected Doctor Figure 4.2: Health Care Scenario its heart rate. Although the smartwatch might be able to detect an emergency in case of a very low or high heart rate, more complex diagnosis requires both a broader range of medical data and more computing power than the smartwatch can provide on its own. Therefore, the measured data is made available to the health care platform via the connected smartphone, which then is capable to perform a more sophisticated evaluation of the current situation, e.g., by including additional data, such as the patient’s current location, into the analysis. Based on the result of this evaluation, the appropriate actions can be triggered, such as informing a doctor or even calling an ambulance. Thinking one step further, the data of multiple patients could be used for research purposes, e.g., to study the effectiveness of a newly developed drug. On this note, the arising privacy concerns regarding the patients, which act as representatives for any end-user in an IoT application scenario, have to be addressed with a privacy-preserving concept. Therefore, the next sections cover the elicitation of the functional and non-functional requirements towards this concept. 34 4.2 Functional Requirements 4.2 Functional Requirements Personal (medical) data is highly sensitive, therefore it should be shared only if absolutely required (e.g., in an emergency situation), since medical concerns supersede privacy concerns. To guarantee this, there are two aspects, that have to be covered by a privacy-preserving concept in an IoT environment: 1. Configuration, and 2. Enforcement. The first aspect, configuration, has to enable users (patients) to control, who can access which (type of) data under which conditions and to what extent. E.g., a patient might want to share its heart rate and blood sugar measurements at all time while granting access to its current location or its audio-visual peripheral equipment (e.g., camera and microphone) only in emergency situations. The second aspect, enforcement, has to make sure, that the users’ privacy configuration is enforced, i.e., that entities in the untrusted zone (cf. Figure 4.1) are granted access only if permitted by the respective user’s privacy configuration. Based on these aspects, we can now formally define the functional requirements shown in Table 4.1: FR1 The system should allow a 1:n owner-mapping from a user to an entity in the edge or perception layer. FR2 The system should implement a privacy-by-default approach, i.e., initially no access is granted to any requesting entity from the untrusted zone except for the owner. FR3 The system should allow entity owners to specify conditions under which certain entities are granted certain access. FR3.1 These conditions must comprise different contextual information of the requesting entity as well as the requested entity, and FR3.2 The possibility to restrict the data presented to the requesting entity in terms of, e.g., completeness or accuracy. FR4 The system should provide a user interface for privacy configuration purposes. FR5 The system should enforce the users’ privacy configuration, respectively. Table 4.1: Functional Requirements FR1 is the most basic but also most essential requirement, as it guarantees the respective user’s right to self-determined privacy configuration. Any device, sensor, actuator or other entity from the perception or edge layer is mapped to exactly one owner, while every user may be the owner of one or more entities. In the health care use case this could mean, that a patient is the owner of a wearable metering device. FR2 ensures that each and every access to, e.g., sensor data or an action performed by an actuator, is explicitly granted by the respective entitiy owner. Compared to a blacklist-based appraoch, where the owner has to restrict certain entities from certain access types, this approach provides a more secure and user-friendly way of privacy configuration. The third functional requirement, FR3, introduces context-awareness into the decision-making process as well as gradual / partial access permissions. FR3.1 enables the owner to specify conditions, that must be met to be granted access. These conditions evaluate contextual information of both the requesting entity and the requested entity. Revisiting the health care scenario, an example would 35 4 Requirements be for doctors to be granted access to medical data only in case some threshold, such as blood pressure, is exceeded. Using contextual information reduces the effort of privacy configuration, since conditions can be defined in an identity-less way. FR3.2 allows very fine-grained access decision results, due to the possibility to grant access to only parts of sensor data. For instance, a patient in the health care scenario might want to share its location with only a certain accuracy when not in an emergency situation. With FR4, it is ensured, that users can view and configure their privacy settings easily through a graphical interface. Lastly, FR5 guarantees, that the privacy configuration is actually evaluated and subsequently enforced whenever an entity requests access to a resource, for which it is not registered as the owner. This is important, since configuration without enforcement is worth nothing. In addition to the previously discussed requirements, the health care scenario as well as the context of the IoT pose more requirements. However, these requirements relate to challenges, that cannot be addressed with purely functional requirements. Therefore, the next Section provides the elicitation of the non-functional requirements based on our representative health care scenario on the one hand and a survey of related literature [BAAO15] [OMEO17] [SM19] [SGM20] on the other hand. 4.3 Non-Functional Requirements In this section, the results of the analysis of non-functional requirements is discussed. The following high-level non-functional requirements have been identified: 1. Expressiveness 2. Continuity 3. Transparency 4. Extendability 5. Efficiency 6. Usability Each of these non-functional requirements is explained in detail. Furthermore, several aspects (sub-requirements) are presented, respectively. An overview of the non-functional requirements is shown in Table 4.2. 4.3.1 Expressiveness Due to the heterogeneous nature of entities participating in IoT application scenarios and the resources provided by them, a privacy framework for the IoT has to stand out in terms of expressiveness. In order to achieve an expressive solution, the following aspects have to be addressed: a) context-awareness, b) granularity, c) a data-centric permission model [SM19], and d) data minimization [SGM20]. The first aspect, context-awareness, is also part of FR3.1 (cf. Table 4.1) and means, that the decision-making process should be based not only on static rules but rather incorporate the current state of the entities involved in the respective access request. The second aspect, granularity, on the one hand increases expressiveness by enabling a more fine-grained selection of entities, such as a specific doctor instead of any (available) doctor or a specific device rather than all devices connected via Bluetooth. On the other hand, a fine-grained 36 4.3 Non-Functional Requirements privacy configuration allows sophisticated permissions compared to the all-or-nothing approach, which either completely grants or denies access. To realize this fine granularity of the privacy framework, the following two aspects are essential. A data-centric permission model introduces an abstract layer below the perception layer in our reference architecture (cf. 4.1), which encompasses the data procuded by sensors and the actions provided by actuators. The aspect of data minimization goes one step further as it aims at modifying the data presented by means of, e.g., adding noise to or decreasing the accurary of the data. 4.3.2 Continuity In addition to the heterogeneity of the entities in IoT application scenarios, another key aspect is the constantly changing state of these entites (just think of the location of smartphone somebody carries around). Therefore, the evaluation and enforcement of privacy configurations should be performed in a continuous way, instead of a one-time or session-oriented manner. Moreover, when a set of permissions granted to an entity is altered, it is important, that these changes come into effect immediately. The following aspects have to considered: a) real-time evaluation & enforcement, and b) continuous evaluation & enforcement based on up-to-date (contextual) data. The process of evaluating and enforcing should be done in real-time to avoid the lost-update problem, which could occurr if changes are made to the privacy configuration between the start of the evaluation process and the permission grant, which then would be based on outdated data. Likewise, changes to the privacy configuration could be made right between two consecutive access requests where the requesting and requested entities are identical, respectively. If evaluation is performed only for the first request, the changes to the privacy configuration won’t be reflected in the second access request. This is why each access request should be evaluated indepedently, which is what the second aspect aims at. 4.3.3 Transparency An essential requirement closely related to privacy is the aspect of transparency. To achieve transparency in an IoT privacy framework, the following aspects have to be dealt with: a) access purpose transparency [SGM20], and b) derivation transparency [SM19]. In order to decide whether to grant access to a (potentially unknown) third-party application or person, users should be able to see what their data is used for, which is referred to as the access purpose [SGM20]. E.g., a patient in the health care example might agree to share its medical records with a health care service for the purpose of medical advice from a doctor but not for marketing purposes of pharmaceutical companies. Furthermore, data might be correlated with regard to derivation, e.g., X could be derived from Y. Now, if the data owner decides not to share X, but at some point wants to share Y, the privacy framework should at least generate a warning, which indicates that by sharing Y, entities with access to Y might be able to derive X. 4.3.4 Extendability The ever-changing nature cannot only be observed with the entites in IoT application scenarios, but also with the concept of the IoT itself. New (communication) technologies, platforms, and concepts are constantly emerging. Therefore, a very important characteristic of a good privacy framework for the IoT is extendability. The key factor to achieve an extensible solution is generic design, which should be applied to the following artifacts of the privacy framework: a) the domain 37 4 Requirements model for configuration, and b) the evaluation and enforcement facilities. The domain model should be as flexible as possible in order to support a wide range of (future) use cases. Additionally, a generic domain model is important to decrease the effort of privacy configuration, e.g., by providing identity-less and attribute-oriented configuration mechanisms and enabling reusable privacy settings. The components and algorithms used for evaluation and enforcement should be generic in terms of where they can be deployed and executed, in order to support both centralized approaches as well as distributed approaches. The latter approach becomes increasingly relevant, since we can observe a „smartness shift from the center to the edge“ [OMA15]. 4.3.5 Efficiency Following up on the distributed architecture approach discussed in the last section, efficiency is a crucial requirement, since the IoT is resource-constrained by design. Two aspects have to kept in mind when designing and implementing an IoT privacy framework: a) lightweight computation, and b) scalability. The importance of lightweight computation is obvious if the edge layer is involved in the evaluation and enforcement of privacy settings. However, it cannot be disregarded even if all evaluation and enforcement functionality is implemented on a central platform, which has access to sufficient resources. The number of entities participating in IoT application scenarios tends to grow exponentially and might lead to substantial scalability issues, if evaluation and enforcement requires huge amounts of computational resources. Scalability is immediately linked with the continuity aspect (cf. Section 4.3.2), since a non-scalable solution can affect real-time decisions. Revisiting the health care scenario, this might add some delays in an emergency situation, which in turn might have fatal consequences for some patients. 4.3.6 Usability Last but not certainly not least, a privacy framework for the IoT should address the following aspects in order to achieve a high degree of usability: a) efficient privacy configuration mechanisms, and b) an easy-to-understand permission model. The interface and mechanisms provided to users for the configuration of privacy settings should support easy and efficient configuration workflows. If users have to navigate through complicated and extensive configuration strucutures, they are likely to configure their privacy settings either too restrictive, due to coarse-grained access restriction to avoid having to create different fine-grained permissions, or too loose, due to no configuration at all. While this correlates to the accuracy of permissions, in order for them to also be defined correctly, the permission model should be easy-to-understand for the user. This aspect correlates to the first non-functional requirement, expressiveness (cf. 4.3.1), as the permission model should be highly-expressive yet easy-to-understand at the same time. Otherwise, the benefits of an expressive permission model could be annihilated. 38 4.3 Non-Functional Requirements NFR1 Expressiveness Context-Awareness Granularity Data-Centric Permission Model Data Minimization NFR2 Continuity Real-Time Evaluation & Enforcement Continuous Evaluation & Enforcement based on up-to-date (contextual) data NFR3 Transparency Access Purpose Transparency Derivation Transparency NFR4 Extendability Domain Model for Configuration Evaluation and Enforcement Facilities NFR5 Efficiency Lightweight Computation Scalability NFR6 Usability Efficient Privacy Configuration Mechanisms Easy-to-understand Permission Model Table 4.2: Non-Functional Requirements 39 5 Conceptual Design This chapter presents the conceptual design of the access control system developed in this work. The concept is presented top-down, beginning with a high-level dataflow model and gradually zooming in to the access control domain model and syntax. We start with the architecture and integration of the access control system which are discussed with respect to a dataflow model for IoT environments. After that, the access control workflow is described based on which the elicitation of the respective components is presented. Finally, the core of the access control system – its domain model – is discussed. 5.1 Architecture and Integration In this section the architecture is presented along with the rationale for the most important aspects. As a first step, we have to determine the dataflow in an IoT environment. Figure 5.1 shows an abstract dataflow model based on the reference architecture by Guth et al. [GBF+16]. The interaction 11 Application & End-User IoT Platform Integration Middleware Things 4472C4 Security Privacy Login Request Response Command Data Command Data Figure 5.1: Dataflow in IoT environments between users (including users in the form of applications) and the IoT environment is always handled by the central IoT platform. In the case of human users, this is mostly done through a web interface, whereas applications can communicate with the IoT environment through an exposed API, e.g., a REST API. The communication between the Things, such as devices and sensors, and the IoT platform is enabled by several middleware components, e.g., a message broker. This way, commands can be sent to the Things, e.g., to trigger certain actions, and data from sensors can be sent to the IoT platform. Based on the established dataflow model, the following sections discusses several key architecture and integration issues and presents the solution that has been determined most suitable. 5.1.1 Privacy vs. Security The purpose of an access control system is to restrict access to certain resources to only those users, that are authorized to access them, e.g., if the respective resource is owned by the user or particular access has been granted by the owning user to the requesting user. When designing the architecture of the access control system, it is important to thoroughly consider which functionality is related to privacy or access control and which functionality is already covered by security mechanisms in a respresentative target environment. For our concept, we assume that the following security measures are established in the target environment: 41 5 Conceptual Design • Authentication of end-users and applications: every request from an end-user or an application to the IoT platform is authenticated, e.g., using HTTP basic authentication or OAuth2. Likewise, requests originating from the web frontend of an IoT platform require previous user login, i.e., authentication. • Secure communication: the communication between all entities shown in Figure 5.1 is encrypted, e.g., using TLS 1 or lightweight protocols like the Constrained Application Protocol (CoAP) 2 considering resource-contrained devices. Consequently, the scope of the access control system only has to encompass the authorization of requests and does not have to deal with authentication. This is also important when dealing with the domain model and syntax, since the design and scope of the domain model are directly related to the functional scope. Now that we differentiated privacy and security and determined the scope of the access control system, the next step is to determine how to integrate the access control system into the target environment. 5.1.2 Centralized vs. Distributed Architecture There are several options for the architecture and integration of the access control system, which are discussed in the following. The central question is where and at which point in the dataflow (cf. Figure 5.1) the authorization process is performed. Centralized Architecture The most obvious solution is to implement the access control system directly in the central IoT platform. This way, each request to the IoT platform is forwarded to the access control system and evaluated. Furthermore, the privacy settings for each user and entity can be stored in a central database within the IoT platform. The web frontend can be used for administration purposes by end-users. However, contextual information plays a very important role in the decision-making process, therefore, some overhead might be introduced when constantly having to retrieve contextual information, e.g., the state of a device. Distributed Architecture Another solution is to outsource the access control logic to the Things themselves, which then can act autonomously. This way, the required contextual information is always available in real-time. However, the big disadvantage is the overhead that is caused by the access control processes. In addition to that, forwarding the request and the contextual information of the requesting user has to be dealt with. In contrast to the IoT platform, a Thing is usually resource-constrained, which makes this solution inappropriate for most IoT application scenarios. Moreover, with this distributed architecture, the delays attributed to access control processes are most definitely higher than the delays caused by access control processes in a centralized architecture, since in both cases contextual information has to be transferred and the IoT platform is certainly able to evaluate the access requests significantly faster. Hybrid Architecture A third solution is to use a hybrid approach which is based on the centralized architecture. In addition to that, a lightweight access control system is added to the Things, which then are able to configure the data sent to the IoT platform and trigger actions to be executed based 1RFC-5246: The Transport Layer Security (TLS) Protocol 2RFC-7252: The Constrainer Application Protocol (CoAP) 42 https://www.rfc-editor.org/info/rfc5246 https://www.rfc-editor.org/info/rfc7252 5.1 Architecture and Integration on the current contextual information, completely detached from the current requests related to a particular Thing. With this approach, a 2-way access control system can be achieved, where some general conditions are created, that define when to send data to the IoT platform and when not to, and the access control system within the IoT platform handles the evaluation of each request. This way, it is possible to prevent sensitive or personal data to be sent to the IoT platform in the first place or at least to be anonymized, e.g., someone’s current location during a certain time in the day. Considering these three architectural approaches, the advantages of the hybrid architecture clearly prevail. Therefore, we implement the access control system based on the hybrid approach. The flexibility of this approach, i.e., the fact that the (additional) access control logic implemented on the Things can be seen as optional, makes it the most suitable option for most target environments. 5.1.3 Access Control Workflow The access control workflow is heavily influenced by the way the entities in the IoT environment (cf. Figure 5.1) are communicating. The most important aspect is the request-response type of communication between the IoT platform and end-users or applications. In combination with the requirements from Chapter 4, especially context-awareness and continuiuty in the enforcement of privacy settings, a request-based access control workflow is most appropriate. Figure 5.2 illustrates 15 4472C4 IoT Platform Requesting End-User / Application Access Control Owner 1 3 5 4 2 2 2 Figure 5.2: Access Control Workflow the generic, request-based access control workflow, which is described in the following. 1. In a first step, a user registers a new Thing, e.g., a smart camera, and creates several privacy settings accordingly. 2. Once the camera has been registered, it sends data to the IoT platform depending on the privacy settings. For now, let’s assume that the camera is sending (raw) data. 3. Now another user can request the data from the camera. 43 5 Conceptual Design 4. The IoT platform receives the request and immediately can determine the requested entity and the corresponding privacy settings defined by the owner. The request is forwarded to the integrated access control system, which evaluates the request and applies the appropriate constrains to the data, e.g., reducing the resolution of the images obtained from the camera. 5. The requesting user receives the response which contains the result of the evaluation of the access request. In case access is granted, the response contains the requested data. Using this request-based access control workflow, continuous enforcement of access requests is covered, since each request is processed and evaluated individually in contrast to session-based or token-based models. Now we have to consider the aspect of context-awareness. The challenge is to provide the contextual information of both the requesting entity (user) and the requested entity to the access control system. This is addressed in the next section. 5.1.4 Access Control Components Until now, the access control system has been described from a black-box point of view. The next step is to zoom in and discuss the component-level design of the access control system. Therefore, this section presents the various components of the access control system as well as several key design decisions. In order to determine the required components for the access control system, we have to look at the required functionality and how we can achieve an optimal cut of the functionality into components. Figure 5.3 provides an overview of the components in the access control system as well as the interaction between them. The interface to the IoT platform is the component that receives the requests sent to the IoT platform (by end-users or applications), here called the Request Receiver, which for instance could be a controller for REST endpoints. The numbers on the connections 16 Request Receiver Access Request Handler Constraint Applicator Context Provider Policy Evaluation Service Policy Store 1 2 3 74 8 5 6 9 10 Figure 5.3: Access Control Components 44 5.1 Architecture and Integration between the components illustrate the workflow inside the access control system. Dashed lines indicate optional components. Due to the modular architecture with optional components, a high degree of flexibility is achieved which allows to tailor the access control system individually to different target environments. For instance, the full-blown version of the access control system could be implemented in the IoT platform, while employing a lightweight version on the Things themselves. The main component in the access control system is the Access Request Handler. It acts as a coordinator for the access control workflow and receives the access request from the IoT platform’s request receiver along with information about the requesting and requested entity (1). The requesting entity may include contextual information in the request. However, it is hard to verify the validity of this information, which is why contextual information sent by the requesting entity should only be considered if the requesting entity is trusted, e.g., if the request originates from the IoT platform’s web frontend. The Context Provider is responsible for determining and providing (additional) contextual information with regard to both the requesting and requested entity based on trusted sources (cf. [HS16c]). There are many conceivable options for implementing more sophisticated context providers, e.g., based on situation recognition technology. Furthermore, the number of context providers is not limited and the access control system could just as well connect to an external attribute provider. If a Context Provider is included in an access control system implementation, the Access Request Handler requests (additional) contextual information from the Context Provider (2), which responds with the information that is currently available on the requesting and requested entity, e.g., the current state of a device (3). From now on, we use the term policy when refering to privacy configuration or privacy settings. Once all information required for the evaluation of an access request has been retrieved, the request is forwarded to the Policy Evaluation Service (4). Based on the requested entity, the Policy Evaluation Service retrieves the corresponding policies from the Policy Store (5) (6). The Policy Store could be a separate database within the access control system or could also be integrated into an existing database of the IoT platform. The Policy Evaluation Service is then able to evaluate the given policies based on the contextual information. The result of the policy evaluation process is returned to the Access Request Handler (7). In case access is denied, the decision is immediately returned to the IoT platform’s request handler. If access is granted, it has to be checked whether the policy, that grants access, specifies one or more constraints for the access. These constraints may filter a given set of data or also modify data, e.g., for anonymization purposes. The functionality to apply constraints is implemented in the Constraint Applicator, which is an optional component and can be ommitted for simple use-cases that don’t require the application of constraints. If a Constraint Applicator is available in the access control system, the Access Request Handler sends the data to constrain to the Constraint Applicator (8) and receives the constrained data (9). The access control workflow is now complete, i.e., the decision and (constrained) data can be returned to the IoT platform’s request handler. 5.1.5 Key Design Decisions Based on the access control workflow presented in the previous section, there are several implications on key design decisions regarding the underlying access control model. In Chapter 3, various approaches to access control models have been presented. Since we have to provide context-aware access decisions, the model we choose is crucial. Role-based access control models lack the required degree of expressiveness. This is often remedied by overengineering roles, however, it is not a recommendable way of achieving fine-grained permissions in highly dynamic environments. The remaining two types of models discussed earlier, UCON-based and 45 5 Conceptual Design capability-based access control models, both fall short in terms of context-awareness, lightweight evaluation of policies, and extendability (cf. Section 3.3 and Section 3.4). Furthermore, the amount of research done in these resepective areas is limited, which results in fewer proposed approaches and extensions, especially in the context of IoT environments. With attribute-based access control there is a very powerful solution to access control in IoT environments, which is perfectly suited to support context-aware access control, since attributes can be used to easily capture contextual information. Moreover, the attribute-based approach, due to its generic nature, can be extended and customized very easily and quite extensively. Another very important aspect is whether to use a whitelist-based or blacklist-based approach for the definition of policies. The whitelist-based approach would grant access as soon as there is a policy that grants that access, whereas with the blacklist-based approach, every policy has to be evaluated in order to determine whether there is a policy that denies that access. Therefore, we choose the whitelist-based approach, since it reduces the overhead caused by the evaluation policies on the one hand, and simplifies the process of access configuration, i.e., defining policies, for the users on the other hand. 5.2 Access Control Domain Model Now that the component-level architecture and integration has been established, we can zoom in even more and have a look at the elements of the access control model. In this section, the domain model and the syntax of the access control system are presented. Figure 5.4 shows the complete domain model in the form of a entity-relationship diagram. In the following, each element in the model is described in detail. A requesting entity can either be an end-user, a third-party application or a Thing in the IoT environment itself. These entities can request access to certain other entities, called requested entities. A requested entity can be something real, e.g., a physical device, but it can also be seen as an abstraction for data [SGM20]. Using this data abstraction, users can specify fine-grained policies (cf. Section 4.3.1), e.g., a user could specify a policy only for location data and a separate policy for other data instead of one policy for the entire device or sensor the data originates from. Access to entities is further differentiated based on the Access Type and the Access Purpose. The access type indicates whether, e.g., reading or writing access is requested, whereas the access purpose specifies, what the requesting entity intends to use the requested access for. Revisiting the health care scenario from Chapter 4 (cf. Figure 4.2), the doctor could specify „perform diagnosis“ as the access purpose. Access type and purpose are also reflected in the specification of policies, which are discussed later. In the previous section, we already mentioned the importance of contextual information with regard to context-aware access control decision-making. Since we are using an attribute-based access control model, context is simply a set of attributes. Both requesting and requested entities are characterized by one or more attributes. An attribute is defined as a key-value pair and could hold any information that comes to mind. Even a legacy role-based access control system could be incorporated into our attribute-based system by simply adding an attribute „role“. The core of the domain model are policies. A policy specifies whether access should be granted or denied based on one or more conditions. In addition to that, policies are prioritized for two reasons: 1) to allow one policy to overrule another policy, and 2) to enable fast access request evaluation. Policy conditions can be of one of three forms: simple condition, composite condition, or situation condition [HS16c]. A simple condition basically is an equation with two arguments and a function 46 5.2 Access Control Domain Model 17 Requesting Entity Access Context Attribute requests to Requested Entity specifies Policy is-a End-User Application Thing has has defines Access Type Access Decision contains uses determines 1 n 1 1 n 1 11 1 1 1 n n n 1 Constraint defines is-a Filtering Constraint Modifying Constraint Condition Simple Condition Situation Condition is-a Composite Condition contains n n 1nn 1 n 1 n 1 is-a Thing Data Sensor Access Purposedefines n 1 n n priority owns 1 n Figure 5.4: Access Control Domain Model to compare the two arguments. The left side of the equation always is an attribute value that has to be evaluated. The right side of the equation can either be a fixed value or an attribute value. By using attribute values, conditions can be evaluated based on dynamic values, i.e., based on up-to-date data (cf. Section 4.3.2). With composite conditions, there is a way to specify more complex conditions by building boolean expressions based on simple or also nested composite conditions. Situation conditions take the degree of context-awareness to another level by allowing policies to be based on situations determined by situation recognition and complex event processing technology. In addition to this expressive set of conditions, constraints allow to further restrict the access granted to the requesting entity if the conditions hold. Two types of constraints are available – filtering constraints and modifying constraints. An application for filtering constraints could be to 47 5 Conceptual Design filter a range of values based on an upper and lower bound. An example for a modifying constraints would be to reduce the accuracy of the returned data, which is of particular interest when dealing with location data. It would further be possible to completely pseudomyize or even anonymize the data presented to the requesting entity. The access decision is finally determined by the policies based on the conditions and constraints. Possible access decisions are: access denied, access granted, and access granted with constraints. 5.2.1 Syntax To give an idea of how the domain model presented previously can be implemented from a data format viewpoint, Listing 5.1 provides an example for a policy written in JSON. The policy specification is done independent of particular requested entities, which allows to re-use policies for several requested entities. Moreover, the process of assigning or removing a policy to or from a certain requested entity can be implemented by simply updating the list of policy ids associated with a requested entity. Another advantage of this solution is that the set of policies to evaluate for an access request can be directly obtained with the requested entity itself. The policy in Listing 5.1 contains a composite condition with two simple conditions that are linked with the logical AND, i.e., both of the simple conditions have to evaluate to „true“ in order for the composite condition to hold. The policy grants access to a fixed group of users and to all employees that are on or above the senior level. If access is granted based on the condition, the constraint of the policy restricts the accuracy of the returned data (e.g., some financial figures) to an accuracy of ten, i.e., 87.5 would be returned as 90. It has to be mentioned, that the presented syntax should only be regarded as an example for a concrete implementation of the domain model. The actual syntax and implementation should be designed individually and with focus on the respective target environment. 5.2.2 Evaluation The last part of the access control system to discuss is the algorithm that is used to evaluate access requests. This functionality is implemented in the Policy Evaluation Service (cf. Section 5.1.4). Input: Requested entity e, Context of requesting and requesting entity c, access type, access purpose Output: Access decision policies ← getPolicies(e, access_type, access_purpose) policies ← sort(policies, priority) for Policy p in policies do if evaluate(p, c) == True then if p.constraint then e ← applyConstraint(e, p.constraint) end if return AccessDecision(GRANTED, e) end if end for return AccessDecision(DENIED) Algorithm 5.1: Evaluation algorithm for access requests Listing 5.1 shows the evaluation algorithm for access requests. It has four input parameters: the requested entity, the context (attributes) of both the requesting and requested entity, the access type, and the access purpose. The generated output is the access decision (access granted or denied) 48 5.2 Access Control Domain Model Listing 5.1: Policy with condition and constraint in JSON format 49 5 Conceptual Design which contains the possibly constrained requested entity if access should be granted. The algorithm first retrieves all policies for the requested entity based on the access type and access purpose. This way, non-applicable policies are filtered before even processing them. The set of applicable policies is then sorted by priority, before iterating over each policy and evaluating the policy condition. As soon as the first policy (condition) evaluates to „true“, the requested entity is returned either directly or after applying the respective constraint. If no condition evaluates to „true“, access is denied. 50 6 PoC Implementation for the MBP The last chapter presented the conceptual design of an access control system for generic IoT environments. Now, we want to prove that the concept actually works. Therefore, the concept has been implemented for the MBP IoT platform (cf. Section 2.1.1). As in the previous chapter, we pres