A user-centric Internet of Things platform to empower users for managing security and privacy concerns in the Internet of Energy

Abstract

Current worldwide energy challenges require the synergy of multidisciplinary actions and activities affecting different stakeholders, such as governments, utility companies, and citizens. In recent years, these needs are being addressed through the integration of the Smart Grid paradigm with the so-called Internet of Things, in order to make energy decisions aware of data from devices that are physically deployed on a smart city. However, to address such concerns, many of the scenarios from this resulting ecosystem, require huge amounts of data in order to make efficient and effective decisions about energy distribution and saving. In this sense, the application of proper security mechanisms to allow the selective disclosure of information to the intended parties is crucial to guarantee that users’ privacy is not harmed. In this work, we propose the application of specific attribute-based access control technologies to protect the energy data that are outsourced from different devices. This integration is part of the ongoing work within MiMurcia Smart City project, which is intended to provide an integral platform to build a more sustainable and efficient city.

Keywords

Internet of Energy security privacy Internet of Things energy efficiency

Introduction

The world has experienced an unprecedented urban growth in recent decades. The trend of population migration to the cities reached a milestone in 2008, when for the first time the world’s population was evenly split between urban and rural areas. According to a report from the United Nations (UN) (World Urbanization Prospects: The 2007 Revision Population Database (2007) by United Nations Population Division), in developed nations, about 74% of the population is urban. Moreover, there are more than 400 cities with a population of over 1 million people and 19 with over 10 million.

Such population concentration involves numerous challenges; resource and energy management is a crucial issue for the worldwide economy and environment. Indeed, the global need for energy optimization in city management is reported by the United Nations; Christiana Figueres, executive secretary of United Nations Framework Convention on Climate Change (UNFCCC), stated that information and communications technology (ICT) can play an essential role in saving energy to cope with climate change. The aspects are considered by a recent GeSI SMARTer2020 report (http://gesi.org/smarter2020) where the energy consumed by data centers is also estimated to increase by 81% by 2020, being smart cities the biggest collective source of information, which will have a big impact on the energy consumption scope.

Fortunately, numerous developments on ICT have transformed the energy area, especially based on the use of networked embedded devices (i.e. sensors and actuators) that become tools for understanding the complexity of the urban daily life and allow an effective response to it. In this sense, thanks to the recent advances in wireless communication technologies, and the increasing interest from standardization bodies, such as the Internet Engineering Task Force (IETF), the development of a real internet protocol (IP)-based Internet of Things (IoT),¹ is becoming a reality. One of the scenarios with a strong attention stems nowadays from the integration between the IoT and the so-called Smart Grid Ecosystem in order to build more sustainable and green cities. Specifically, this integration is known as the Internet of Energy (IoE),² in which the IoT paradigm is considered as an active and key enabler for energy-saving initiatives.

However, the IoT poses strong challenges in terms of security and privacy, especially in large-scale deployments for energy management applications that collect and manage sensitive data from citizens and control actuators throughout the city. IoT devices such as power meters or traffic management devices are accessible through the network. Thus, they can be manipulated and consequently produce fake information that can cause dangerous situations. The flow of messages between IoT devices and applications go frequently across the Internet, and consequently, they should be secured to avoid any disclosure of confidential information. Indeed, the application of correlation and data mining techniques on raw energy measurements could raise serious privacy concerns from citizens. In this sense, there is a lack of effective approaches to empower users for managing the disclosure of personal data through the integration with advanced cryptographic and access control schemes.

In order to address these challenges, this article describes a user-centric IoT platform, SMARTIE, which has been designed to efficiently disseminate data in smart city applications while ensuring citizens’ security and privacy. This platform’s architecture is based on the reference architecture (RA) from the IoT-A European Union (EU) project.³ From this RA, the SMARTIE’s security and privacy requirements for the IoE ecosystem are addressed, through the design and development of an attribute-based access control infrastructure, which integrates a policy-based authorization approach with the use of advanced cryptographic schemes. In particular, the proposal is based on the eXtensible Access Control Markup Language (XACML)⁴ to empower users for defining their access control preferences and the use of the Ciphertext-Policy Attribute-Based Encryption (CP-ABE).⁵ The approach is complemented with our Distributed Capability-Based Access Control (DCapBAC)⁶ as a lightweight mechanism to ensure only authorized IoE devices will be able to provide energy measurements to the SMARTIE platform. The use of these technologies represents an instantiation of the SMARTIE architecture, by defining specific components to accomplish the described functionality. In addition, this platform is currently being integrated as part of the MiMurcia initiative, which represents an ambitious effort to build a solid smart city infrastructure in the Region of Murcia (Spain). MiMurcia is intended to improve energy management in Murcia based on SMARTIE components, while security and privacy requirements are still reconciled.

The remainder of this article is organized as follows: section “MiMurcia” presents MiMurcia smart city project and some of the components for managing energy-saving aspects. The description of SMARTIE’s architecture for secure smart cities is given in section “SMARTIE: security and privacy for smart cities.” Then, from such architecture, the instantiation through specific technologies of the main security functional components (FCs) is provided in section “User-centric security and privacy.” Section “An IoE use case” describes the application of such technologies to control the access to data from smart meters, as a common device on an IoE scenario. The validation of these mechanisms, as well as set of evaluation results, is provided in section “Implementation and evaluation results,” and finally, the article concludes in section “Conclusion.”

MiMurcia

MiMurcia is a smart city project developed in the city of Murcia, Spain, whose target is to make the city of Murcia a reference in resource optimization (energy, water, public transport services, etc.) and quality of life, making Murcia’s environment more sustainable. In order to reach these objectives, an intelligence system is required to generate information and knowledge from physical devices’ raw data. This system can be considered as the brain of the city, and it is intended to enable coordinated actions in order to make effective and efficient decisions according to citizens’ needs. MiMurcia comprises a smart city platform that integrates all the information from sensors and services of the city council, a business intelligence application that analyzes this information (providing also indicators and digital control centers), and an orchestration and management application. By the interconnection with different facilities of the city council, such as call centers, a web portal, social networks, and different apps, this system is able to coordinate specific, personalized, and geo-localized actions for citizens and the different areas of the city council.

As the cornerstone of MiMurcia initiative, this platform is intended to serve as the brain of the city by integrating information and measurements from all the available municipal services and a huge amount of heterogeneous IoT devices, which are to be deployed on the city. Such information is publicly available through a map-based website where such information is geo-localized, as shown in Figure 1.

Figure 1.

Map-based website with geo-localized information.

As far as IoE is concerned, energy management is strongly considered under MiMurcia initiative. Indeed, smart meters and other devices, such as presence, luminosity, humidity, and temperature sensors, and actuators, such as heating, ventilation, and air conditioning (HVAC), light, or window/door open/close controllers, have been installed in different facilities of the Murcia city council. Furthermore, these devices have been integrated into the platform with the main goal of reducing the energy consumption and reaching an optimal use of the energy resources. Such sensors and actuators can be considered as specific IoT devices that are intended to provide a certain kind of data or service. Therefore, the IoE ecosystem is risen as a suitable scenario for analyzing the application of SMARTIE components to address the identified security and privacy challenges in the scope of a smart city.

Figure 2 presents a web view of the map of Murcia, as an example of the energy management information integrated into the smart city platform, which shows energy consumption information of a facility of the city council. Such information is provided by the smart meter that is installed there. Regarding energy management, it provides different information, such as active and reactive energy, active and reactive power, and power factor either grouped (left column) or separated by phases (in the other three columns). Regarding actuation over the elements of the resources of the city, Figure 3 presents an example of lighting system management which enables to vary its luminosity.

Figure 2.

Example of MiMurcia energy consumption monitoring view.

Figure 3.

Actuation over lighting system.

From the security and privacy point of view, the dissemination of all information through MiMurcia platform, as well as the actuation on IoT devices, is managed by SMARTIE components. Following sections provide a detailed description of SMARTIE’s architecture and how it is instantiated through the use of specific technologies to manage security and privacy concerns in IoE scenarios.

SMARTIE: security and privacy for smart cities

Under a data-driven IoE, there is a real need for user-centric security and privacy mechanisms that are able to reach consensus among different actors, such as regulatory bodies, utility companies, energy suppliers, or end users, while the benefits from IoT are still realized. In fact, the promulgated vision of the IoE paradigm imposes new challenges related to security and privacy. On the one hand, the integration of smart meters into the Internet infrastructure makes these devices vulnerable to attack and abuse. This is particularly challenging, since these devices will be often physically deployed in uncontrolled environments. On the other hand, the need to provide a large-scale approach to energy efficiency requires huge amounts of data from individual users, in order to adopt effective arrangements (e.g. an energy plan for a building) with a global impact for energy efficiency.

Indeed, for the deployment of effective energy-saving strategies in smart cities, there is a real need to collect sensitive information from citizens, such as data to help for modeling their daily habits, usual locations (e.g. workplace and home), and scheduled activities. It is also necessary to allow remote control of public infrastructure and even citizens’ personal devices. In this “big brother” and automated environment, the risk and impact of security threats can have serious consequences to the community. Data collected in a smart city must be protected in order to reduce the risk of data theft and leakage, which can lead to identity fraud, financial damage, and invasion of privacy. The city’s infrastructures and IoT devices must also be protected from malicious attacks that may waste the energy resources of the city (e.g. controlling the water and energy management of the city) or even cause physical injuries to citizens by causing accidents (e.g. taking control on the city’s lights) or panic (e.g. showing fake alerts about dangerous contamination).

The SMARTIE platform is aimed to ensure security and privacy, which are essential for the success of smart city solutions and for their acceptance by the citizens. As described below, this platform’s architecture has been derived from a reference framework. This architecture was designed to ensure fundamental principles of information security such as confidentiality, integrity, access control, and availability for the different aspects of a smart city. In particular, confidentiality is needed to protect the privacy of citizens and valuable information of stakeholders in the city, thereby protecting against unauthorized external access. Integrity protects data against modifications that can lead to harmful decisions and hence it helps on unauthorized device control, hacking, and sabotage. Confidentiality and access control are also key aspects for smart cities’ platforms to prevent denial of service, man-in-the-middle, and intrusion attacks. Data confidentiality in databases by cryptographic means is fundamental to avoid private data disclosure to internal adversaries. Furthermore, guaranteeing data availability and control functionality is also essential, especially in hard situations, such as rescue operations for public safety in which coordination tasks are required.

Architecture design from a RA

The design of reference IoT architectures⁷ will be key for the interoperation of future IoT platforms by providing a reference framework to guarantee the quality of these platforms, or to measure their level of interoperability, among other aspects. Nevertheless, reference IoT architectures is a recent research topic. Very limited experience and feedback have been reported about the application of these architectures in real scenarios. In spite of this situation, there are emerging initiatives that are intended to promote interoperability for large-scale IoT deployments. In Europe, the Alliance for Internet of Things Innovation (AIOTI) was initiated by the European Commission in 2015 as an ambitious effort to support the dialogue and interaction among different IoT players in Europe. In particular, as part of AIOTI, the “IoT standardization” working group (WG03) has initiated the development of a High-Level Architecture (HLA)⁸ for IoT in order to foster architectural convergence among others WGs. Moreover, the IEEE Standard for an architectural framework for the Internet of Things (IEEE P2413)⁹ defines a three-tier architectural framework, addressing descriptions, definitions, and common aspects in different IoT domains. Other recent approaches, such as the oneM2M initiative¹⁰ or the ITU-T Y.2060 “Overview of the Internet of Things” recommendation,¹¹ follow similar approaches, in order to provide a more harmonized view about the IoT ecosystem.

In the scope of European research projects, the huge range of IoT application domains has led to the specification of different architectures, which are usually tailored to be deployed on specific scenarios. This was identified as a significant barrier for large-scale IoT deployments, and, at the same time, as an incentive for the creation of coordinated efforts. In this sense, IoT-A was a large-scale project focused on the design of an architecture reference model (ARM)³ to be additionally instantiated by other IoT architectures through a set of specific tools and guidelines. In order to promote quality aspects of IoT in smart cities, the architecture of the SMARTIE platform has been designed from the ARM. The main motivation behind this choice is ARM, which already provides a comprehensive view of the IoT ecosystem, by proposing different models and architectures. In addition, ARM is strongly supported by already mentioned initiatives, such as the IEEE P2413 or the initial definition of HLA provided by AIOTI WG03.

Indeed, this RA addresses the different phases of the architecting process by providing inputs (e.g. guidance, examples, common semantics) that can greatly help architects to design their IoT systems. The ARM was conceived as an abstract and application-independent reference framework in order to support the generation process of IoT architectures in any IoT domain. Thus, the ARM defines high-level concepts, semantics, and functions that are common to any platform.

A simplified version of the ARM-compliant SMARTIE architecture¹² is shown in Figure 4. This architecture is composed by a set of functional groups (FGs) that are composed by different FCs. The device and application FGs make reference to the physical devices of interest and the applications that will access to our platform, respectively. The IoT process management FG provides an environment for the modeling of IoT-aware business processes (i.e. process modeling FC) and their execution (i.e. process execution FC). Our architecture does not contemplate yet these activities, since business processes are as of now pre-configured in the platform.

Figure 4.

Simplified version of the IoT–ARM–compliant SMARTIE architecture.

The following sections describe some of these components that are related to security. For more information on the SMARTIE architecture refer to SMARTIE.¹²

Security and privacy design choices in SMARTIE

Ensuring security properties in smart cities is challenging because of scalability issues and the constrained computation power of “things,” that is, sensors and actuators. Traditional approaches that are widespread deployed on the Internet, such as centralized access control servers, asymmetric cryptography, and transport layer security (TLS) among others do not work well in the IoT. Lightweight and decentralized security mechanisms are paramount to ensure overall security in smart cities.

The SMARTIE project looks at smart cities from a security point of view in order to enable the exchange of heterogeneous information, while guaranteeing privacy and trust efficiently, even on devices with strong resource constraints. SMARTIE requirements on security, privacy, and trust as well as their associated architectural design choices were deduced from a deep analysis on the IoT-ARM’s threat analysis, unified requirements, and the Trust, Security, and Privacy perspectives.³ Since the ultimate goal of SMARTIE is to facilitate the integration of user-centric privacy and governance into IoT applications for smart cities, security and privacy are first-class business goals in order to enable citizens to:

Control their devices that join an IoT application to sense and publish data;

Define fine-grained access control rules for their devices;

Decide who can or cannot access their devices’ data.

The IoT-ARM high-level tactics and design choices allowed us to identify Quality of Service (QoS) requirements, classify them, determine concrete design choices, and correlate them based on different QoS perspectives. Let us summarize some fundamental design choices related to security and privacy for SMARTIE. For further information on the SMARTIE requirements and design choices, respectively, refer to SMARTIE.^12,13

First, the enforcement of context-aware user access control decisions is moved to the very edge of the network, that is, the data producers that can have scarce resources.

Second, only the actual authorized data will be granted by IoT devices rather than providing sensor data to centralized servers in charge of applying privacy filters. To accomplish this design choice while guaranteeing scalability, access control to IoT devices is decentralized through the use of the DCapBAC.⁶ This approach enables the separation of access control logic from application logic, thereby facilitating one of the QoS objectives of SMARTIE: extensibility. SMARTIE makes the integration with different IoT applications easier and facilitates device-to-device communication based on DCapBAC.

A third important design choice relates to push communication based on subscriptions: sensor data have to be end-to-end protected by cryptography based on application-level user-defined attributes that data receivers must satisfy. This design choice ensures user privacy policies regardless of who receives the data; only those receivers that satisfy certain application-level attributes will be able to decipher the data. As described below, this design choice is addressed through CP-ABE⁵ and XACML.⁴

User-centric security and privacy

The realization of many IoE use cases is based on the huge amount of data, which are sent from IoT devices. However, the information that is collected and sent by smart meters may unintentionally reveal sensitive information regarding users’ daily habits. Indeed, with the current development of enhanced machine learning techniques, the application of aggregation and correlation algorithms increases this concern, allowing an accurate profiling and tracking of users. As a consequence, protecting access to this information is crucial in order to ensure that only authorized applications or services are able to obtain this data. In this sense, devices’ owners within the IoE ecosystem must be empowered to maintain the control over how their devices share that information and to whom. This is particularly challenging, especially when this information is outsourced, combined with each other, correlated, and stored over long periods of time.

To cope with the main security and privacy needs in the IoE paradigm, SMARTIE’s approach is based on the instantiation of the producer/consumer vision for smart objects that we proposed in the study of Hernandez-Ramos et al.¹⁴ Under such approach, a smart object¹⁵ can play the role of data producer or consumer in any time of its life cycle. Specifically, in a common IoE scenario, a smart meter can be considered as a data producer, which generates energy consumption measurements. These data are outsourced to a central data platform for additional processing tasks. Once processed, this information is disseminated to groups of users or services (e.g. a utility company) acting as data consumers. Then, based on such information, they are responsible for making energy-saving decisions, such as the implementation of a certain energy plan in a particular building. This typical IoE scenario raises numerous security and privacy issues, which must be addressed by scalable and flexible mechanisms.

On the one hand, from the producer perspective, there is a real need to protect the access to the platform, so that only legitimate and authorized entities (i.e. smart meters) are able to provide information to the platform. Otherwise, a high degree of reliability on the information that is provided by the platform cannot be guaranteed. Toward this end, as already mentioned, this instantiation of SMARTIE’s architecture follows the DCapBAC model,⁶ in order to provide an efficient and lightweight access control mechanism that is used to protect the access to the platform. This technology is based on linking access rights or capabilities to the client’s public key (e.g. a smart object or user), following an approach similar to the use of SPKI Certificate Theory¹⁶ or authoriZation-Based Access Control (ZBAC).¹⁷ In this way, unlike typical OAuth-based approaches¹⁸ in which the use of a bearer token does not require the bearer to prove that it is actually the entity associated with that token, DCapBAC uses public key cryptography as a proof-of-possession mechanism.¹⁹ The application of the IoT-based access control model was initially proposed in the IoT@Work EU project²⁰ and has been used as the basis for the definition of an authorization credential to be used in IoT scenarios. From a technical perspective, DCapBAC tokens are represented with JavaScript Object Notation (JSON) and following a similar semantics to JSON Web Tokens (JWT).²¹ However, unlike these credentials, capability tokens contain the access rights that are bound to the client’s public key, as well as a set of access conditions to be locally verified by the target device or service when this token is presented. These access rights are represented by $< action, resource >$ pairs, where the resource refers to a URL that identifies a certain service being hosted by a smart object or the platform itself (e.g. coap://smartieplatform.um.es/topics/consumption), and the action references to a Constrained Application Protocol (CoAP) method (i.e. GET, POST, PUT, or DELETE). DCapBAC tokens are sent over the CoAP²² over the Datagram Transport Layer Security (DTLS)²³ by making use of Elliptic Curve Cryptography (ECC).²⁴ Furthermore, it has been integrated with a policy-based access control approach using the XACML standard; so, users or services in charge of the platform are enabled to define proper access control policies for the platform’s services.

On the other hand, from the consumer perspective, there is a real need to ensure only legitimates and authorized users or services are able to access the information provided by smart meters (acting as producers) through the platform. In this sense, SMARTIE makes use of Attribute-Based Encryption (ABE),²⁵ in order to provide a flexible and scalable encryption-based access control approach for such scenarios. ABE represents the generalization of the Identity-Based Encryption (IBE) scheme²⁶ in which data is encrypted according to identity attributes’ value. Based on ABE, there are mainly two alternative approaches: the Key-Policy Attribute-Based Encryption (KP-ABE)²⁷ and the CP-ABE.⁵ Specifically, SMARTIE’s approach is based on CP-ABE in which each piece of data is encrypted under a certain logical combination (or policy) of identity attributes, whereas a private key is associated with a certain set of attributes. In this way, different services or users will be able to decrypt a certain piece of information sent by a smart meter if their key satisfies the policy that was used to encrypt such data. The use of CP-ABE in this case provides two significant advantages to be exploited in IoE scenarios. On the one hand, its straightforward application to provide confidentiality in one-to-many configurations, since the group of entities satisfying the policy, will be able to access the information, providing a high level of scalability and adequacy to publish/subscribe scenarios. On the other hand, CP-ABE offers a simplified key management that does not require key refresh or revocation to be able to decrypt data that were encrypted under different policies. Indeed, changing or modifying the CP-ABE policy that is used to encrypt a data does not require new key management tasks. We provide the description of a real IoE scenario in which these SMARTIE components have been integrated to provide a fine-grained user-managed access control approach in the following section.

An IoE use case

By considering the high-level architecture presented in section SMARTIE: security and privacy for smart cities, as well as the technologies described in the previous section, Figure 5 shows the application of both DCapBAC and CP-ABE technologies for the management of access control concerns in IoE scenarios. Before the description of the main required interactions, it should be noted that we have considered four main external entities:

The SMARTIE Platform Manager is the user or service in charge of defining access control policies, in order to guarantee only authorized smart meters will be able to provide information to the platform.

The Smart Meter Owner is responsible for defining encryption policies to state which users or services will be able to access their smart meters’ data.

The Smart Meter represents the instantiation of a smart object that acts a data producer, by generating energy consumption measurements and sending them to the platform.

The User represents a data consumer, which aims to receive notifications about energy consumption measurements through the platform.

Figure 5.

Application of SMARTIE components for access control in the IoE.

In addition to these external entities, SMARTIE’s components have been instantiated by different deployment elements to realize the described access control functionality into the SMARTIE platform. In this way, according to already mentioned technologies, it should be noted DCapBAC has been enabled through the definition of different components within the SMARTIE platform in order to automate the DCapBAC tokens generation process. In particular, we have made use of XACML for the implementation of the policy administration point (PAP) and the policy decision point (PDP) components, which have been deployed as web services. In addition, we have added the Capability Manager as the component for generating DCapBAC tokens in case of receiving affirmative authorization decisions from the PDP.

Furthermore, CP-ABE functionality is realized by three main components. In particular, the CP-ABE Key Generation Center is responsible for generating and distributing CP-ABE keys, which are employed by Users to decrypt data from the platform. The CP-ABE Policy Selector aims to give a central point where smart meters’ (and, in general, smart objects) owners are empowered to define which CP-ABE policy is used to encrypt data from their devices. Then, based on such policies, the CP-ABE-Engine is in charge of encrypting energy consumption measurements that are provided by smart meters.

Finally, the IoT Broker is intended to provide the functionality of a data broker, in order to allow producers (i.e. smart meters) and consumers (i.e. users and applications) to remain decoupled, by following a publish/subscribe communication model.

Before describing the main interactions among the components, it should be noted there are different steps (with dashed line) that are assumed to be made before the process. First, we consider the SMARTIE Platform Manager has already defined a set of access control policies through the PAP, to determine which entities are authorized to publish information on the platform. As an example of the definition of these policies, Listing 1 shows a high-level view of a policy that is intended to authorize University of Murcia devices to perform GET and POST operations related to energy consumption at the campus. Second, we assume that the Smart Meter Owner has already defined the CP-ABE policies (or combinations of identity attributes) through the CP-ABE Policy Selector that will be used to encrypt information from their smart meters. Third, we consider a User or set of Users is already subscribed to a certain topic called Energy in the IoT Broker, so they are enabled to receive notifications about energy measurements changes. In addition, it is assumed that Users have already obtained the necessary cryptographic material (CP-ABE key and public cryptographic parameters) to try to decrypt the information from the platform.

Listing 1.

High-level XACML policy example.

In this way, according to Figure 5, when the smart meter intends to publish its energy consumption measurements into the platform, it requests a token for this action, by querying the Capability Manager (step 1). Then, this component asks the PDP (step 2) to determine whether the requested credential must be generated. The PDP uses the policies defined by the SMARTIE Platform Manager in the PAP (step 3) and evaluates them against the smart meter’s request (step 4). In the case of an affirmative decision (step 5), the Capability Manager generates a token for the smart meter (step 6), so it will be allowed to publish its energy measurements into the platform.

This token includes the smart meter’s public key (which was pre-installed by its manufacturer), as well as a specific action (e.g. POST method) over a service hosted by the SMARTIE platform (IoT Broker), as an access right, which includes a specific topic (Energy) in which the smart meter is authorized to publish its data. Additionally, it includes time restrictions, delimiting the validity period for this credential. In addition, the Capability Manager signs the generated token. This way, once the smart meter obtains the token, it tries to publish its data on the topic Energy in the IoT Broker, by making use of the token, as well as a proof to demonstrate that it is effectively the entity associated with that token (proof-of-possession¹⁹) (step 7). This interaction is specifically carried out using CoAP-DTLS with mutual authentication based on public key (that is, raw public key or certificate). Therefore, the IoT Broker can verify that the public key contained in the DCapBAC token is the same key that was used in the authentication during the DTLS exchange.

In addition, the IoT Broker evaluates the content of the token (step 8) by verifying the validity of the token using the time restrictions and checking if the requested operation (publish in the topic Energy) is contained in the token as an access right. Furthermore, it verifies the token’s signature by making use of the Capability Manager’s public key, which is assumed to be statically configured during an out-of-band process. Finally, in case the token is correctly evaluated, the smart meter publishes its information into the SMARTIE platform.

Once energy data are sent to the platform by making use of DCapBAC and XACML components, CP-ABE functionality is used to handle the dissemination of such information to intended consumers. The main purpose of the CP-ABE application to this scenario is to allow only authorized receivers (i.e. satisfying the CP-ABE policy that was used to encrypt) who will be able to decrypt energy consumption data.

In this way, when the smart meter sends its energy information to the IoT Broker, this entity queries the CP-ABE Engine in order to encrypt the information associated with that topic (step 9). Before this process, the CP-ABE engine queries the CP-ABE Policy Selector for the CP-ABE policy to be applied for this topic (step 10). As already mentioned, this component is used by the Smart Meter Owner to define its access control preferences (i.e. combinations of identity attributes or CP-ABE policies). In particular, we assume that there is a CP-ABE policy for each topic that is defined in the IoT Broker (e.g. stating that the topic Energy is encrypted with the policy P = (role =smartBuildingManager OR utilityCompany=companyC)).

Once obtained, the CP-ABE engine encrypts the new value (step 11) of the topic Energy with P and sends it to the IoT Broker (step 12). Finally, the updated and encrypted value is sent to the Users (step 13), which are subscribed to any change of that topic. As already mentioned, we have assumed that these users have already requested the required cryptographic parameters to the CP-ABE Key Generation Center, as well as a CP-ABE key (associated with their identity attributes), in order to be able to decrypt the received notification (step 14). In this case, if its private key satisfies the CP-ABE policy (i.e. the policy P) that was used to encrypt the topic, it will be able to get access to the updated value from that topic. Otherwise, it will not have access to the energy information being shared through the SMARTIE platform.

This common IoE use case represents an application scenario in which some of the main access control components from the SMARTIE’s architecture can be leveraged. Indeed, we have provided an integrative approach, in which different technologies are used to address some of the major security and privacy concerns of the IoE ecosystem. We give additional details on the implementation of these components, as well as a set of evaluation results, in the following section.

Implementation and evaluation results

The implementation of the aforementioned components has been carried out during the development of the SMARTIE project. It should be noted that the evaluation is mainly focused on the application of CP-ABE components for the access to energy measurements, in order to complement the results from our previous works related to the use of DCapBAC.^6,28

In this way, SMARTIE platform components have been deployed on a laptop with an Intel Core i5-5257U 2.70 GHz processor and 2 GB of RAM. Moreover, we have developed an Android application in order to instantiate the functionality of the User entity. This application is intended to provide a user-friendly graphical user interface (GUI) so that users can access the energy consumption data from SMARTIE platform using their smartphones. In particular, this application has been deployed on different smartphones to simulate users with different attributes, in order to demonstrate how CP-ABE can be used to control the access to data coming from smart meters.

Indeed, Figure 6 shows example screenshots in which two different users attempt to decrypt the energy consumption data received from the platform (i.e. step 13 of Figure 5). Thus, on the left side, we show a screenshot for the case in which the user’s CP-ABE key does not satisfy the policy that was used to encrypt. On the right side, we show a screenshot of the application in the case of a user whose key satisfies the CP-ABE policy used. In this case, details on energy consumption are accessible for the user. Additionally, for evaluation purposes, we made use of a smartphone Samsung Galaxy J3⁶ with a 1.5-GHz quad-core processor, 1.5 GB of RAM, and version 5.1 of Android (Lollipop).

Figure 6.

Screenshots of the User’s Android application after the CP-ABE decryption of a notification received.

For the access control process (based on XACML and DCapBAC) that is required for the publication of data in the platform, the Capability Manager has been implemented as a CoAP-DTLS server, using californium and scandium libraries (https://github.com/eclipse/californium). Also, the PDP has been implemented as a web service by making use of the SUN XACML library (http://sunxacml.sourceforge.net/) for the policy evaluation engine. Figure 7 shows the delay and RAM consumption required by the Capability Manager to generate the token. In particular, the Get Authorization Decision Delay series references to the time required to get a XACML decision from the PDP (step 2 in Figure 5) upon a DCapBAC token request (step 1), by modifying the number of attributes of the smart meter (i.e. the Subject element of the XACML request). According to the results, this delay fluctuates between 51 and 58 ms by considering the same set of XACML policies in the PDP. Furthermore, the DCapBAC Token Generation Delay series makes reference to the time required to generate the token, including the signature operation. This operation takes around 30 ms. Additionally, the Get Authorization Decision RAM and DCapBAC Token Generation Delay series show the RAM consumption for the same operations. While the former requires about 2200–2800 KB, the latter only requires around 100–130 KB for the process. It should be noted that the delay and RAM consumption are constant, while the number of identity attributes (that are used to launch the authorization process) is increased. Additionally, it should be pointed that this process is not performed every time the smart meter aims to publish data on the platform; the same DCapBAC token can be used several times until it expires or is revoked by the platform.

Figure 7.

Delay and RAM consumption for DCapBAC tokens generation on the platform.

For the CP-ABE functionality that is required in the IoE use case, we have compared two CP-ABE implementations. On the one hand, we have made use of the library provided by Wang,²⁹ which is a Java implementation built on top of the Java Pairing–Based Cryptography library (jPBC).³⁰ On the other hand, we have deployed the required functionality for CP-ABE aspects through the use of the library provided in the study of Bethencourt et al.,³¹ which is a C implementation (based on the PBC library³²) that was developed by the authors of the CP-ABE scheme itself. Both libraries have been deployed on the platform (to implement the CP-ABE Key Generation Center and CP-ABE Engine functionality), as well as on the Android application for the decryption process. It should be noted that, for the C library, we have followed a similar approach in the study of Ambrosin et al.³³ using Android Native Development Kit (NDK) and CMake (https://cmake.org/) tools, in order to accommodate C code into the Android application.

In particular, using such libraries, we have made use of type A pairings, which are built on the supersingular curve $y^{2} = x^{3} + x$ over the field $F_{p}$ for some prime $p = 3 \mod 4$ . In this case, let p be the prime order of $F_{p}$ , and $E (F_{p})$ , the additive group of points of affine coordinates $(x, y)$ with $x, y$ in $F_{p}$ , that satisfy the curve equation, q represents the order of the cyclic subgroup of interest in $E (F_{p})$ . Under these considerations, it should be pointed out that the proposed evaluation has been carried out with $| p | = 512$ , $| q | = 160$ , so a 80-bit security level is considered.³³

For all the tests, we have used the 1–10 range for the number of attributes associated with the CP-ABE key or ciphertext, since we consider this range expressive enough for most scenarios and use cases. Furthermore, for encryption and decryption tests, we have used CP-ABE policies with AND gates by considering a one-level policy tree. In addition, for all the CP-ABE operations, we test the behavior of both implementations by considering different workloads within the 1–10 range for the number of operations that would be performed concurrently. Unlike the performance analysis from the study of Ambrosin et al.,³³ these tests are intended to provide insights about scalability aspects, which are crucial in any IoT scenario.

Taking into account these premises, Figure 8 shows the delay required for both implementations in the case of CP-ABE key generation that is performed on the platform. Indeed, this process makes reference to step 0 (Get CP-ABE Key in Figure 5). The x-axis represents the number of attributes that is associated with the generated key. For the implementation based on the study of Wang,²⁹ in the case of a one-attribute CP-ABE key, the time required to generate the key is around 108 ms, while for a 10-attribute key, it takes around 605 ms and 636 ms/4323 ms for a 10-operation workload. For this case, using the implementation based on the study of Bethencourt et al.,³¹ the delay is around 197 ms and 1498 ms, respectively. While it represents a considerable better performance, it should be noted that this process is not expected to be done frequently, since CP-ABE keys are associated with users identity attributes, which does not affect possible dynamic changes with CP-ABE policies for encryption.

Figure 8.

Comparison for CP-ABE key generation on the platform.

Moreover, Figure 9 makes reference to the delay required to encrypt the energy consumption value coming from a smart meter under a specific CP-ABE policy. Specifically, it references the step 11 Encrypt energy data from Figure 5. For the encryption process, the implementation based on the study of Wang²⁹ requires 104 ms with a one-attribute access policy and 590 ms for a 10-attribute policy in a one-operation workload setting. This delay is increased to 842 ms/4749 ms for a 10-operation workload. In the case of the implementation based on the study of Bethencourt et al.,³¹ this time is reduced to 138 ms/1404 ms for that setting, which represents a reduction of 70.45% for the 10-attribute policy. The encryption process is expected to be a more frequent operation, since a potentially high number of energy measurements could be sent to the platform. In this case, the use of this implementation represents a valuable improvement, especially to cope with scalability aspects.

Figure 9.

Comparison for CP-ABE encryption on the platform.

Moreover, Figure 10 shows the required delay for the CP-ABE decryption process, which is performed on the smartphone (i.e. step 14 in Figure 5). In this way, both implementations are compared during the process to decrypt the updated energy measurement contained in a notification message, by making use of a CP-ABE key satisfying the CP-ABE policy that was used to encrypt it. For the implementation of Wang,²⁹ in the case of a one-attribute access policy, the time required to decrypt the value data is around 1165 ms, while for a 10-attribute policy, it takes around 9332 ms using a 10-attribute CP-ABE policy/key (4587 ms/59064 ms for a 10-operation workload). It should be pointed out that these results were obtained by considering all attributes values must be satisfied (i.e. using the AND operator). Using the library of Bethencourt et al.,³¹ the time required to decrypt the value for a one-attribute access policy is 69 ms, while for a 10-attribute policy this delay is around 309 ms. For a 10-operation workload setting, the time is increased to 211 ms/944 ms, which represents an improvement of 95.4% and 98.4%.

Figure 10.

Comparison for CP-ABE decryption on the smartphone (delay).

Additionally to the execution time, we also measured the energy consumption that is required for the decryption process. For this purpose, we used the PowerTutor³⁴ tool. This way, Figure 11 shows the consumption required for the decryption algorithm for both implementations. For a 10-operation workload, the implementation based on the study of Wang²⁹ takes 9.2-J consumption for a one-attribute access policy, and 84.2 J in the case of a 10-attribute access policy. It should be noted that, according to the results, the energy consumption for the implementation based on Bethencourt et al.³¹ remains constant under these experimentation conditions (around 1–3 J). These results represent a significant improvement, which is particularly relevant according to the energy consumption concerns and the expected frequency of the decryption process, since this operation is also expected to be performed for other data, in addition to energy measurements.

Figure 11.

Comparison for CP-ABE decryption on the smartphone (energy).

As already mentioned, these results complement our previous works about the use of DCapBAC in different IoT scenarios. In this way, such experiments show the applicability and feasibility of the proposed integrative approach, in order to leverage the benefits of a DCapBAC and CP-ABE mechanisms in the IoE ecosystem. In particular, the integration of the library provided by Bethencourt et al.³¹ into the SMARTIE platform and smartphones provide significant performance improvements that can be leveraged especially to cope with scalability aspects in initiatives, such as MiMurcia. Furthermore, these schemes have been complemented with a policy-based approach so that users are empowered to define their access control preferences over their smart objects’ information.

Conclusion

SMARTIE is an integrating user-centric platform for efficient but secure dissemination of IoT data in smart cities. This article has given the authors’ insights into the application of the IoT-ARM to generate this platform. The main goal of this platform is to empower users to take control of their access control and privacy preferences to govern devices. To this end, SMARTIE, based on the IoT-ARM guidelines on security and scalability, provides architectural artifacts that enable easily and efficiently enforcing user access control policies. This article has shown an instantiation of such architecture by employing specific technologies to address access control concerns on a common IoE scenario. The proposed integrative approach is intended to give a user-managed, flexible, and scalable mechanism for access control to protect the access to smart meters’ data through the use of the SMARTIE platform. In addition to manage information, the main goal of this platform is to empower users with full control on their devices through a policy-based approach. In order to complement the proposed functionality, future work is focused on the application of identity-based signature schemes to guarantee data integrity, as well as the deployment of these components on FIWARE, as one of the main reference IoT platforms at European level.

Footnotes

Academic Editor: Pietro Manzoni

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work has been partially funded by the European Commission through the H2020-644852 ARMOUR and H2020-649849 ENTROPY research projects.

References

Heer

Garcia-Morchon

Hummen

et al . Security challenges in the IP-based internet of things. Wireless Pers Commun 2011; 61(3): 527–542.

Bui

Castellani

Casari

et al . The internet of energy: a web-enabled smart grid system. IEEE Netw 2012; 26(4): 39–45.

Bassi

Bauer

Fiedler

et al . Enabling things to talk: designing IoT solutions with the IoT architectural reference model. Berlin: Springer, 2013, pp.163–211.

Rissanen

eXtensible Access Control Markup Language (XACML), version 3.0. Burlington, MA: Oasis Standard, 2012.

Bethencourt

Sahai

Waters

. Ciphertext-policy attribute-based encryption. In: Proceedings of the IEEE symposium on security and privacy (SP’07), Berkeley, CA, 20–23 May 2007, pp.321–334. New York: IEEE.

Hernández-Ramos

Jara

Marín

et al . DCapBAC: embedding authorization logic into smart things through ECC optimizations. Int J Comput Math 2016; 93(2): 345–366.

Krco

Pokric

Carrez

Designing IoT architecture (s): a European perspective. In: Proceedings of the IEEE world forum on Internet of Things (WF-IoT), Seoul, South Korea, 6–8 March 2014, pp.79–84. New York: IEEE.

Standardisation AW. High level architecture (HLA), release 2.1. Alliance for Internet of Things Innovation (AIOTI), https://aioti-space.org/wp-content/uploads/2017/03/AIOTI-WG3-IoT-High-Level-Architecture-Release_2_1.pdf

Logvinov

Standard for an architectural framework for the Internet of Things: IEEE P2413. IEEE Standard Association, 2014, https://docbox.etsi.org/workshop/2014/201412_m2mworkshop/s04_standards/ieee_p2413_nappey.pdf

10.

Swetina

Jacobs

et al . Toward a standardized common M2M service layer platform: introduction to oneM2M. IEEE Wirel Commun 2014; 21(3): 20–26.

11.

(ITU-T) ITSS. Recommendation Y. 2060: overview of the Internet of Things. Geneva: ITU, 2012.

12.

SMARTIE. Deliverable 2.3: SMARTIE initial architecture specification, http://www.smartie-project.eu/download/D2.3-Initial%20Architecture%20Specification.pdf

13.

SMARTIE. Deliverable 2.2: SMARTIE requirements, http://www.smartie-project.eu/download/D2.2-Requirements.pdf

14.

Hernandez-Ramos

Bernabe

Skarmeta

Army: architecture for a secure and privacy-aware lifecycle of smart objects in the internet of my things. IEEE Commun Mag 2016; 54(9): 28–35.

15.

Kortuem

Kawsar

Sundramoorthy

et al . Smart objects as building blocks for the Internet of things. IEEE Internet Comput 2010; 14(1): 44–51.

16.

Ellison

Frantz

Lampson

et al . SPKI certificate theory. Technical report, September 1999. Internet Engineering Task Force (IETF).

17.

Karp

Haury

Davis

. From ABAC to ZBAC: the evolution of access control models. Technical report. HP Laboratories.

18.

Hardt

RFC 6749: the OAuth 2.0 authorization framework. Technical report, 2012. http://dx.doi.org/10.17487/rfc6749

19.

Jones

Bradley

Tschofenig

RFC 7800: proof-of-possession key semantics for JSON web tokens (JWTs). Technical report, 2016, http://dx.doi.org/10.17487/rfc7800

20.

Gusmeroli

Piccione

Rotondi

A capability-based security approach to manage access control in the Internet of Things. Math Comput Model 2013; 58(5–6): 1189–1205.

21.

Jones

Bradley

Sakimura

RFC 7519: JSON web token (JWT). Technical report, 2015, http://dx.doi.org/10.17487/rfc7519

22.

Shelby

Hartke

Bormann

RFC 7252: the constrained application protocol (CoAP). Technical report, 2014, http://dx.doi.org/10.17487/rfc7252

23.

Rescorla

Modadugu

RFC 6347: datagram transport layer security version 1.2. Technical report, 2012, https://www.rfc-editor.org/info/rfc6347

24.

Menezes

Elliptic curve public key cryptosystems. Berlin: Springer Science+Business Media, 1993, http://dx.doi.org/10.1007/978-1-4615-3198-2

25.

Sahai

Waters

Fuzzy identity-based encryption. In: Proceedings of the annual international conference on the theory and applications of cryptographic techniques, Aarhus, 22–26 May 2005, pp.457–473. Berlin: Springer.

26.

Boneh

Franklin

. Identity-based encryption from the Weil pairing. In: Kilian

(ed.) Advances in cryptology–CRYPTO 2001. Berlin: Springer Science+Business Media, 2001, pp.213–229, http://dx.doi.org/10.1007/3-540-44647-8_13

27.

Goyal

Pandey

Sahai

et al . Attribute-based encryption for fine-grained access control of encrypted data. In: Proceedings of the 13th ACM conference on computer and communications security, Alexandria, VA, 30 October–3 November, pp.89–98. New York: ACM.

28.

Hernandez-Ramos

Pawlowski

Jara

et al . Toward a lightweight authentication and authorization framework for smart objects. IEEE J Sel Area Comm 2015; 33(4): 690–702.

29.

Wang

Cpabe Java implementation, 2013, https://github.com/junwei-wang/cpabe

30.

De Caro

Iovino

. JPBC: java pairing based cryptography. In: Proceedings of the IEEE symposium on computers and communications (ISCC), Kerkyra, Greece, 28 June–1 July 2011, pp.850–855. New York: IEEE.

31.

Bethencourt

Sahai

Waters

. Cpabe toolkit, 2011, http://acsc.cs.utexas.edu/cpabe/

32.

Lynn

PBC library, 2006, http://crypto.stanford.edu/pbc

33.

Ambrosin

Conti

Dargahi

. On the feasibility of attribute-based encryption on smartphone devices. In: Proceedings of the workshop on IoT challenges in mobile and industrial systems, Florence, 18 May 2015, pp.49–54. New York: ACM.

34.

Yang

PowerTutor: a power monitor for android-based mobile platforms. EECS 2012; 2: 19.