Blockchain based Proxy Re-Encryption Scheme for Secure IoT Data Sharing

11/06/2018
by   Ahsan Manzoor, et al.
0

Data is central to the Internet of Things (IoT) ecosystem. Most of the current IoT systems are using centralized cloud-based data sharing systems, which will be difficult to scale up to meet the demands of future IoT systems. Involvement of such third-party service provider requires also trust from both sensor owner and sensor data user. Moreover, the fees need to be paid for their services. To tackle both the scalability and trust issues and to automatize the payments, this paper presents a blockchain based proxy re-encryption scheme. The system stores the IoT data in a distributed cloud after encryption. To share the collected IoT data, the system establishes runtime dynamic smart contracts between the sensor and data user without the involvement of a trusted third party. It also uses a very efficient proxy re-encryption scheme which allows that the data is only visible by the owner and the person present in the smart contract. This novel combination of smart contracts with proxy re-encryption provides an efficient, fast and secure platform for storing, trading and managing of sensor data. The proposed system is implemented in an Ethereum based testbed to analyze the performance and the security properties.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

08/27/2019

IoT Notary: Sensor Data Attestation in Smart Environment

Contemporary IoT environments, such as smart buildings, require end-user...
01/25/2021

Personal Data Access Control Through Distributed Authorization

This paper presents an architecture of a Personal Information Management...
10/29/2021

Trustworthy Pre-Processing of Sensor Data in Data On-chaining Workflows for Blockchain-based IoT Applications

Prior to provisioning sensor data to smart contracts, a pre-processing o...
08/04/2021

IoT Notary: Attestable Sensor Data Capture in IoT Environments

Contemporary IoT environments, such as smart buildings, require end-user...
08/02/2019

Secure Calibration in High-Assurance IoT: Traceability for Safety Resilience

Traceable sensor calibration constitutes a foundational step that underp...
08/02/2019

Secure Calibration for High-Assurance IoT: Traceability for Safety Resilience

Traceable sensor calibration constitutes a foundational step that underp...
12/03/2021

A Privacy-Preserving Platform for Recording COVID-19 Vaccine Passports

Digital vaccine passports are one of the main solutions which would allo...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

The Internet of Things (IoT) is an emerging technology which has great technical, social, and economic significance. Current predictions for the impact of IoT are very impressive. It is anticipating that 100 billion connected IoT devices will be used by 2025[1]. It will also have a global economic impact of more than $11 trillion[2].

Data is central to the IoT paradigm. IoT data is collected to serve many different types of applications such as smart home, smart city, wearable, healthcare, smart grid, autonomous vehicles, smart farms, industries and manufacturing, and retail sector[3]. Therefore, numerous heterogeneous sensors exist to measure a variety of parameters. The collected data from these IoT sensors can be useful for different stakeholders. For instance, air quality measurements are of interest to governmental organizations, application developers and inhabitants of the relevant spaces. However, many challenges arise when organizing this data sharing as these IoT devices, which are typically resource-constrained, require efficient mechanisms to guarantee the data integrity and to enable proper processing and security. Due to the large number of IoT devices, scalable deployment, and maintenance costs[3] should also be taken into account.

Currently, almost all the sensor systems upload the data to a centralized cloud and share the sensor data with different stakeholders, who prove access to the cloud storage [4]. The sensors get services from the third-party cloud service provider, such as access control in addition to the data storage. In that case, both sensor and sensor data user have to trust the third-party service provider and also need to pay some fee for their services. In addition, it is needed to establish an agreement between the third-party service provider and sensor data user about the pricing and the amount of data shared. Moreover, these agreements can be even established without the consent of the IoT sensor [5]. Most of these agreements are static and take lots of time and administration to be established. For instance, the sensor data user has to pay the correct amount or buy a subscription to access data, which requires the involvement of other trusted parties such as banks and legal authorities. It will result in a significant increase of time before the actual data sharing can be realized [6]. Thus, the current centralized architecture model in IoT systems will struggle to scale up to meet the demands of future IoT systems.

Our Contribution: To solve these issues, the decentralized and consensus-driven blockchain technology and the underlying cryptographic processes behind it can offer an intriguing alternative. Thus, we propose a novel blockchain based scheme in combination with a proxy re-encryption mechanism to ensure the confidentiality of the data. Here, the advantage of using blockchain mechanisms to sell the sensor measurements with different users is that the corresponding financial transactions are automatically managed through the agreed smart contract, stored at the blockchain. Moreover, the availability and other quality of service requirements from the legal contract between both parties can be automatically applied. Consequently, compared to the business scenario where the data is stored in a cloud-based infrastructure, there is no need for manual verification of the payments and the predefined requirements. Also, disputes on these aspects are completely avoided.

To the best of our knowledge, our proposal is the first one to use a hybrid architecture of combining blockchain with cloud storage to solve this particular issue of sharing data. Moreover, we discuss the different aspects of the implementation of the proposed scheme. On the one hand, we propose a very efficient proxy re-encryption scheme to be used as the security mechanisms and how it allows that the data is only visible by the owner and the person present in the smart contract. On the other hand, we discuss the practical points such as the use of a smart contract, the storage of data and the communication between the cloud server provider and the blockchain. A prototype of the proposed scheme is implemented in a test bed to verify the viability of the proposal. Moreover, a detailed performance analysis is provided to demonstrate the scalability and performance metrics of the approach.

The remainder of this paper has the following structure. Section II provides the background information and Section III presents related work. The proposed scheme is explained in Section IV. The security aspects and security analysis are presented in Section V and Section VII. Section VI discusses the implementation of the proposed scheme. The performance analysis results are presented in Section VIII. Discussion and practical limitations are presented in Section IX. Finally, Section X presents our conclusions.

Ii Background

Ii-a Blockchain

A blockchain is a continually evolving, tamper-evident, shared digital ledger[7]. It holds the records of the transactions such as the exchange of assets or data between the peers in a public or private peer-to-peer network. The ledger is shared, replicated, and synchronized among the member nodes in the network. This ledger holds the records permanently in a sequential chain of cryptographic hash-linked blocks[7].

Without the involvement of a central authority or third-party mediator, the participant nodes in the blockchain network govern and agree by consensus on the updates to the records in the ledger. These records cannot be altered or reversed unless the change is agreed by all members of the network in a subsequent transaction[8].

Consensus mechanisms in blockchains offer the benefits of a consolidated and consistent dataset with reduced errors, near-real-time reference data, and the flexibility for participants to change the descriptions of the assets they own [8]. Moreover, none of the participating members own the source of origin for information contained in the shared ledger. The blockchain leads to increased trust and integrity in the flow of transaction information among the participating nodes [8].

Ii-B Smart Contracts

A smart contract is a computer protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of a contract. [9] Unlike traditional contracts that rely on the reputation of the counterparties, smart contracts can be made between untrusted, anonymous people. Also, the execution of contractual terms is automatic and does not rely on any third party. The concept of smart contracts was introduced in 1990 by Wei Dai [10]. However, smart contracts were not possible in many traditional systems since the participating parties use to maintain separate databases and they do not rely on a proper trust model. However, the possibility to develop a trusted and shared database based on a blockchain has eliminated this limitation.

A blockchain-based smart contract is a self-executing code on a blockchain that automatically implements the terms of an agreement between parties [11]. Blockchain-based smart contracts could offer a number of benefits, such as fast, dynamic and real-time updates, low cost of operation, high accuracy and fewer intermediaries[9, 11]. These benefits also fuel the adaptation of a smart-contract in different applications. Thus, blockchain-based smart contracts are getting a significant interest across a wide range of industries.

Several blockchain platforms such as Bitcoin, Ethereum, NEM, Hyperledger Fabric, Stellar, iOlite, Lisk are available to develop smart contracts. However, Ethereum[12, 11] is the most popular platform due to its stable and safe operation.

Ii-C Cryptographic Operations and Notations

The cryptographic scheme is based on Elliptic Curve Cryptography (ECC) [13], allowing to offer lightweight public key cryptographic solutions. For instance, corresponding with an 80-bit security parameter, a field size of 160 bits for ECC is sufficient, while RSA based solutions require 1024 bits. ECC is based on the algebraic structure of elliptic curves (ECs) over finite fields. We denote the curve in the finite field by , defined by the equation with and two constants in and . We denote by the base point generator of of prime order . All points on , together with the infinite point form an additive group .

The product with and results in a point of the EC and represents an EC multiplication. The scheme relies on two computational hard problems.

  • The Elliptic Curve Discrete Logarithm Problem (ECDLP). This problem states that given two EC points and of ), it is computationally hard for any polynomial-time bounded algorithm to determine a parameter , such that .

  • The Elliptic Curve Diffie Hellman Problem (ECDHP). Given two EC points with two unknown parameters , it is computationally hard for any polynomial-time bounded algorithm to determine the EC point .

In addition, we denote a one-way cryptographic hash function (e.g., SHA2 or SHA3) with output a number in by . The concatenation and xor operation of two messages and is denoted by and respectively. We further assume that the EC parameters and the associated EC operations, together with the hash function are implemented in each entity participating in the scheme.

Iii Related work

There exist different studies on the security and privacy of the IoT [14, 15] and the vast majority of this research work is on understanding and identifying these threats [16]. The IoT devices sense, gather and share a large amount of data, thus opening up significant security and privacy concerns. Khan and Salah [17] in their paper have reviewed different security challenges to IoT and identified insecure transferring of IoT data as a high-level security risk. Authors in [18] demonstrated the lack of basic security by hacking off-the-shelf smart home IoT devices.

Blockchain got popular at it used for recording financial transactions (e.g. Bitcoin), where transactions are encoded in blocks and kept by all the participants. Any modification in the blockchain transactions can be easily traced and detected. Later, blockchain has been used in other applications such as IoT, healthcare, transportation, and energy networks. Ethereum is one such blockchain system used in many applications Ethereum is a blockchain-based distributed computing system that has its own language such as Solidity [3]. It gives developers the flexibility to write their own codes and run them on the blockchain. Huh et al. [19] proposed using Ethereum blockchain to build an IoT system that could easily manage the configuration of the IoT devices and provide a platform for the key management system. They utilized smart contracts to manage the system in a fine-grained way. They implemented and evaluated the proof of concept with a few IoT devices to prove the feasibility of the system. Banerjee et al. [20] have analyzed security risks in sharing of IoT data and proposed the use of blockchain to ensure the integrity and security of the shared datasets. They discussed two blockchain based approaches and present nine research question regarding them. However, they did not implement any of the proposed approaches. Authors in [21] compared a cloud server with a blockchain-based model for the security of IoT and they concluded that a cloud architecture costs more and is susceptible to manipulation. One of the main reasons for blockchain’s incorporation into IoT is to strengthen its security. Authors in [22] have demonstrated how blockchains can be utilized for security and privacy of the smart home devices. They integrated local storage of sensor data in the blockchain. They have additionally analyzed their proposed framework with respect to fundamental security goals like confidentiality, integrity, and availability.

In 1998, Blaze, Bleumer, and Strauss [23] initially introduced the concept of proxy re-encryption and constructed the first bidirectional proxy re-encryption application. Proxy re-encryption has many exciting applications such as law enforcement, email forwarding and performing a cryptographic operation to secure network file storage [24]. Jiang and Guo [25] proposed an encrypted data-sharing scheme for secure cloud storage based on the conditional proxy re-encryption. They proved the correctness and security of the proposed system and also analyzed the space and computational costs of it. Authors in [26], [27] also propose a similar scheme but it is not dynamic, hence making it unsuitable for cloud data sharing. In [28], a very efficient solution for data storage in the cloud is proposed using a pairing free proxy re-encryption scheme. However, the scheme is not implemented in practice. Although the underlying structure of our proposed scheme is based on it, some important modification like the inclusion of metadata is included to ensure a practical usage of the scheme.

Most of the prior work partly addresses the problem of securely sharing the IoT data. It is nearly impossible to come up with device-embedded security to solve all the security threats to the IoT devices. Limited computing and power resources of IoT also make the execution of complex security algorithms harder on the device. We propose using the combination of a blockchain and a paring free proxy re-encryption scheme to provide a trading platform and to ensure secure transfer of the sensor data to the user.

Iv Proposed Architecture

In this section, we present our new architecture based on the mechanisms of blockchain and re-encryption for secure storing and sharing of the sensor data. We consider four entities in the system: IoT sensors, Data requester, cloud provider, and the blockchain, as shown in Figure 1.

Fig. 1: Proposed Architecture

Iv-a Sensors

An IoT sensor labeled as sensor owner in Figure 1 is a computing device that connects to a network and can capture and transmit data. It interacts with a). Cloud storage, to save and retrieve the encrypted sensor data from the database b). Blockchain, to perform smart contract transactions and manage the electronic wallet. The sensors’ owner activates the sensors, and registers them on the blockchain via a smart contract function. After successful registration, it provides the sensor with the required key material such that the measured data can be sent encrypted to the cloud storage server provider.

Iv-B Requester

The requester can be seen as a software agent acting on behalf of the user for specifying the requirement and type of sensor data to be queried. It interacts with the blockchain to share the public cryptographic key and manages all the financial associated transactions. When a user requests access to one (or a group of) sensor(s) of the owner and it comes to an agreement, a smart contract is generated and mined on the blockchain.

Iv-C Blockchain

A known and trusted application shares and synchronizes transaction data across multiple nodes. It interacts with all the entities in the system and logs those interactions in the form of transactions. Smart contracts only live in the blockchain context and are used for accessing blockchain external data. The smart contract manages the financial transaction costs and checks the corresponding requirements (e.g. Data Location) related to the data.

Iv-D Cloud Server

The cloud storage stores the encrypted sensor data and returns the records that match the requester specified criteria. The cloud server provider also checks the authentication and integrity of the data received from the sensors. If correct, the data is securely stored on the server and a transaction containing the address of the stored data is mined on the blockchain.

Iv-E Proxy Re-Encryption

The proxy re-encryption is a software agent running on the cloud server. It checks the authentication and integrity of the sensor data and stores it on the cloud server. On user request, this software filters the data, decrypts and re-encrypts it before storing it again on a temporary location onto the cloud server. It interacts with the blockchain to get and share the required information for proxy re-encryption.

V Security aspects

We will discuss in this section the requirements, cryptographic operations and notations, and the proposed re-encryption scheme.

V-a Requirements

The system should satisfy the following fundamental security features.

  • Confidentiality: The sensor data needs to be securely sent to the cloud server provider. Only the sensor owner, sensor and subscribed user are able to retrieve the actual measurements of the sensor. Consequently, no outsider, even not the cloud server, is able to derive useful information from the transmitted messages.

  • Integrity: The content of the data from the sensors to the cloud server provider should not be altered without being notified by the cloud server provider.

  • Authentication: Everybody, in particular, the cloud server provider and subscribed user, is able to check the authentication and integrity of the data.

  • The system should be resistant against well-known security attacks like man-in-the-middle attacks, impersonation and replay attacks.

The challenging part is to establish these security features in the most efficient way from the part of the sensor. Furthermore, the following assumptions are made:

  • The cloud server provider is responsible for the correct storage of the data. Moreover, it takes care of the communication of the addresses of the stored data to the blockchain. We consider the security model of an honest but curious server, meaning that it will perform all the required actions but is curious in deriving the data itself in order to use it for its own purposes (e.g. selling). The owner can check the correct behavior at any time by consulting the blockchain transactions.

  • We consider a secure communication between the cloud server provider and blockchain using traditional security mechanisms like Secure Sockets Layer (SSL) as both entities are not considered to be constrained devices. Consequently, the focus of the description on the security mechanisms is between the IoT sensor and the cloud server provider.

V-B System model

We propose to apply a Certificate Based Proxy Re-Encryption (CB-PRE) scheme, which constitutes of seven polynomial-time algorithms: Setup, CertifiedUserKeyGen, Encrypt, ReKeyGen, ReEncrypt, Decrypt1, and Decrypt2. We now explain each of these phases into more detail. In our proposal, we have combined the phases UserKeyGen and Certify to one phase called the CertifiedUserKeyGen phase.

Note that we will use metadata associated with the message and ciphertext for efficiency reasons to facilitate the look-up of information and the corresponding request from the delegate. For instance, a delegate can be interested to obtain all information posted by a particular delegator (in our context sensor) during a certain period. The metadata can consist of multiple fields. As a minimum, we propose the following fields:

  • : The identity of the delegator

  • : The timestamp of the creation of the message.

Additional fields can be for example a list of keywords, an access control list, and corresponding access rights, etc. The purpose of the different phases is summarised below:

  • Setup(): This algorithm is executed by the Certificate Authority (CA) and takes as input a security level , and generates based on this a list of public parameters . In addition, also a master secret key of the proxy is generated. The public parameters are published and is kept secret.

  • CertifiedUserKeyGen(): This phase enables the generation of a private and public key of the sensor/user in such a way that only the involved entity is aware of the private key and no secure channel for the distribution of the key material is required. The construction of the public key requires the usage of a certificate generated by the CA.

  • Encrypt(): In this phase, the delegator is able to generate a valid ciphertext for and corresponding metadata , using , the timestamp , and its private key . The output contains and auxiliary information to check the authentication.

  • ReKey(): The ReKey phase generates a re-encryption key for the output of the Encrypt phase coming from for the delegate with identity , using its certificate to compute the corresponding public key .

  • ReEncrypt(): This algorithm re-encrypts the ciphertext , using the re-encryption key to obtain the ciphertext . Replacing into of , results in .

  • Decrypt1(): The first decryption algorithm allows the delegator to retrieve its message from the ciphertext and to check the integrity.

  • Decrypt2(): The second decryption algorithm allows the delegate to retrieve the encrypted message of from the ciphertext of , using its private key . Also, the integrity and authentication are verified.

V-C Operation of the System

We now discuss the different operations in more detail.

  • SetUp(): Given a certain security parameter , the following steps will be executed to derive the public parameters and the master secret key .

    • First, the CA chooses an -bit prime . Next, an EC of order is generated, and a corresponding generator point is defined. Denote by the group of EC points.

    • A random value is chosen and is computed.

    • Four different hash functions are determined. , , , .

    • The public parameters are now and the master secret key is put as .

  • CertifiedUserKeyGen(): This algorithm is based on the Elliptic Curve Qu Vanstone (ECQV) certificate mechanism [29] and consists of the following three phases:

    • First, the involved entity generates a random value and computes . Next the tuple is sent to the CA.

    • Upon arrival, the CA checks the identity of . Next, it also chooses a random value and computes . Then the certificate is derived. Finally, auxiliary information to derive the private key for the involved entity is computed by . The tuple is sent back.

    • The involved entity computes first its private key . Its public key equals to . If , it accepts the key pair .

  • Encrypt(): The metadata is generated for the message , ie. . Next, the following computations are made.

    The output of this algorithm equals to .

  • ReKey(): First is derived from . Then, the public key of is computed as . This leads to the definition of the ReKey as

    The output is the key .

  • ReEncrypt(): The re-encryption phase changes the ciphertext to by

    Note that also corresponds to , which will be used in the decrypting phase of the delegate. The output is now the tuple, containing .

  • Decrypt1(): Here the delegator wants to decrypt the ciphertext to derive the original message and to check its authenticity. Therefore, the following computations are required:

  • Decrypt2(): In this phase, the delegate derives the message from by the following operations.

V-D Connection with the blockchain

We now discuss the relationship between the phases of the proxy re-encryption scheme and the blockchain. In Ethereum like any other blockchain system, there is a private and a public key. These keys are generated using ECC when you create a new ethereum account. Key holders can use their private key to sign a piece of data that can later be used to verify the transactions submitted on the blockchain.

The public key is uploaded on the blockchain while deploying the smart contact.

The re-encryption key is derived by the IoT sensor using the public key . It is then shared with the cloud using the same smart contract. The re-encryption key is hashed and signed using the ethereum private key of the sensor, before being mined by the blockchain. The following operations are made.

The cloud server then generates a valid ciphertext using re-encryption key and uploads it on the cloud storage.

The encrypted data is shared with delegate B, who decrypts it with its private key and verifies the signature.

Vi Implementation

This section provides the implementation details of the Blockchain based proxy re-encryption scheme.

Fig. 2: Overview of the Architecture Implemented

We demonstrate the feasibility of the system design with the prototype implementation containing a permissioned Ethereum blockchain, IoT sensors and a cloud server for storage of the data. Figure 2 illustrates the setup of the system with three IoT sensors, three mining computers, five ethereum full nodes, two regular users and one cloud storage server. We summarize the device types and their capabilities in Table I.

Miner Full node Iot Sensor
Device Dell Latitude Raspberry Pi 3 TI Sensortag CC2650
# of nodes 3 5 2
RAM 4GB 1GB -
OS Ubuntu 18.04 Raspbian Jessie BLE Stack 2.2.2
Geth v1.8.0 v1.8.0 -
Connectivity Internet Internet BLE
TABLE I: Devices and their capabilities

We configured and connected all the devices to the internet. We used the auto-discovery protocol of Geth to connect the miners and the full nodes, and configured google firebase cloud for storage.

Vi-a Miners

The proposed system consists of three miners that generate a block of transactions on average every 13 seconds. These miners are running on a virtual machine with the same hardware capabilities. All the mining devices were configured to use one Ethereum wallet that collects the mining reward. Newly mined tokens are then added to the overall balance that can be bought by users to pay for services, hence compensating for the miner electricity consumption. These miners are running on Geth v1.80 [30] with four mining threads each.

Vi-B Smart Contracts

We developed two smart contracts111https://github.com/ahsan100/smart-contract on truffle[31] and compiled them with Solidity 0.4.24 [32]. The first smart contract consists of the functions to register the sensor, request data, and financial functions. The second smart contract is dynamically created in the runtime when the user requests for the data. The address of the second smart contract is shared with the concerned entities via the swarm messaging. To increase the security we used function modifiers to automatically check the identity of the person calling the smart contract functions and allowing only the concerned entities to call them.

Vi-C IoT Sensors

Each sensor TI Sensortag CC2650 connects to a Raspberry Pi 3 Model B (RSP) through Bluetooth Low Energy, as shown in Figure 2. This RSP manages the sensor and the Ethereum account to perform transactions on the blockchain on behalf of sensors. A sensor application is developed in Python 2.7.12 that connects to the sensor, performs the cryptography functions described in the proxy re-encryption scheme on the sensor data and uploads that data to the cloud storage server. This application synchronizes with the blockchain using the Python- JSON-RPC (JavaScript Object Notation - Remote procedure Calls) library. As the blockchain notifies the application about the data request, it queries the Google Firebase and downloads the filtered data. It gets the re-encryption key from the smart contract and performs proxy re-encryption of the filtered data.

The registration of the sensor device on the system is performed by calling the function "methodRegister" of the smart contract. A fixed price of the sensor data and MAC address is sent along the function for registration. The MAC address of each sensor acts as its identity and is used for re-encryption. Once registered, the sensor starts uploading the encrypted data to the cloud server. This raspberry pi stores the private key locally and provides the cloud with a re-encryption key via the blockchain. It is assumed that the BLE connection between sensor and RSP is completely secure.

Vi-D User Application

Fig. 3: User Interface

A customized application is designed as the user interface in Python 2.7.12, running on a Raspberry Pi 3 attached to a touchscreen, as shown in Fig. 3. This application uses JSON-RPC to get the sensors’ information from the blockchain. After selecting the required sensor, the user enters details for specifying the data requirements. It interacts with the blockchain via a personal ethereum account. As the user calls the "requestData" function of the smart contract, we notify the sensor device and the cloud sever using the Event function in the smart contract. The "sendCoin" function is used to buy and transfer the tokens, required to pay for the sensor data.

We deploy a new smart contract on the blockchain in runtime based on the user-selected options for the requested data (e.g. Sensor selection, Price). The user also sends the public key as the constructor value when deploying the smart contract.

This application keeps track of the Ethereum wallet along with ECC [13] secret key of the data requester. The cloud server notifies the application when it updates the smart contract with the temporary address of the filtered sensor data. The application downloads the data from the cloud server, checks for the signature and integrity, and decrypts the requested data.

Vi-E Cloud Storage Server

The cloud storage server consists of the RSP and the Google Firebase. RSP acts as ethereum full node and connects to the blockchain, while Google Firebase is used for the storage of the data. The authentication and integrity of the data are performed on the RSP and encrypted sensor data along with the meta-data is upload to the Google Firebase in JSON format. This cloud also performs proxy re-encryption and updates the smart contract variable for data address sharing.

Vii Security Analysis

Vii-a Security requirements

Let us first discuss if the required security features are obtained in the proposed scheme.

  • Confidentiality: This feature is guaranteed by the fact that the data is sent in the encrypted format to the server. Due to the ECDHP, without knowledge of the secret key of the sender, it is impossible to derive the original message . After re-encryption, the message can also due to the ECDHP only be found by the persons who are in possession of the private key of the receiver or the random value determined by the sender, which is constructed by means of the private key of the sender. Consequently, only the sender is able to derive the message before re-encryption, and both sender and receiver after re-encryption.

  • Integrity: The integrity of the message can be verified by both the sender (Decrypt1 phase) and the receiver (Decrypt2 phase) by verifying the last equality in the process.

  • Authentication: Identity-based authentication is established in this scheme, thanks to the usage of the ECQV certificates. From the identity and the certificate, the corresponding unique public key can be derived, guaranteeing the link between identity and public key.

Vii-B Possible attacks and their prevention

We now discuss how resistance is offered against the most well-known attacks.

  • Man in the middle attacks and impersonation attacks. First of all, due to the existence of identity-based authentication in the scheme, no impersonation attacks are possible. In addition, when the re-encryption key is not correctly applied in the scheme, the integrity test in the Decrypt1 and Decrypt2 phase will fail.

  • Replay attacks. These types of attacks are avoided as the timestamps are involved in the metadata, which plays an important role in deriving the corresponding session key.

Viii Performance analysis

In this section, we describe the experiments to evaluate the proof of concept implementation. Experiments were designed to study the performance of the framework. We have performed multiple experiments, starting from the time taken to register a sensor to performing data requests and blockchain transactions. We tested the impact of proxy re-encryption on the overall system and performed some scalability tests.

Viii-a Sensor Registration

Fig. 4: Sensor Registration Delay

In the first experiment, we measure the time taken to register a sensor on the blockchain. In order to register, the sensor node sends a smart contract transaction, and we measure the delay it takes to mine that transaction. Figure 4 illustrates the average registration delay and variation over 50 runs of the scenario. Experiment results reveal that it takes 13.29 s on average to register a single sensor with error margin of 0.86 s. Blue dotted lines show the 95% confidence level for the mean. This delay is closely linked with the average time for block generation in Ethereum, i.e. 13 s. This concludes that block generation has the highest impact on the sensor registration.

Viii-B Impact of Proxy Re-Encryption

In the second experiment, we measure the impact of proxy re-encryption on the proposed system. The second experiment is divided into two parts. The first part consists of a user request for the data using the blockchain and the sensor data is shared through the cloud without any encryption, while in the second part encrypted data is uploaded on the cloud and re-encrypted by the cloud.

Viii-B1 Without Proxy Re-Encryption

Fig. 5: Flow Chart without Proxy Re-encryption

Figure 5 shows the flowchart describing the steps followed to measure the delay for the whole process without the proxy re-encryption scheme. We ran the experiment for 50 times before taking average for each phase and it takes on average 30.23 s for the end-to-end process.

Fig. 6: Impact without Proxy Re-Encryption

We start measuring the time as soon the user requests for the data. In the deploy phase, the user compiles the smart contract in runtime and sends it to the blockchain as a transaction. As the contract is deployed, the cloud starts filtering the data according to the requirement, this phase is marked as the filter on Figure 6. The last phase includes the mining of the temporary address on the blockchain. As can be concluded from Figure 6, deploying of the contract and mining of the temporary address have the highest impact on the delay.

Viii-B2 With Proxy Re-Encryption

In the second part, the sensor encrypts the data before uploading it to the cloud and later re-encrypts it for sharing the data. This experiment was similar to the first part except for the addition of the re-encryption phase that includes the generation of the re-encryption key and later mining it on the blockchain for sharing the key with the cloud server. Figure 7 shows the flowchart with the process followed for the measurements.

Fig. 7: Flow Chart with Proxy Re-encryption

In Figure 8

, the time of the different parts in the scheme is illustrated. As can be seen, it takes on average 48.01 s to share the encrypted data with the user after the initial request with a confidence interval of 2.07 s. Consequently, adding proxy re-encryption to the scheme increases the delay by 60% due to the mining of re-encryption key. The re-encryption phase includes filtering and re-encrypting of the data and it requires less than 1 s for most of the cases.

Fig. 8: Impact of Proxy Re-Encryption

Viii-C Scalability

In the third experiment, we measure the scalability of the architecture by performing multiple transactions from multiple requesters to one sensor. The whole process was repeated 10 times for each scenario before taking the average. In the first scenario, only 1 request was initiated by the user and time was measured from the request to the retrieval of data by the requester. In the latter scenarios, the process was repeated by increasing five requests until the overall request reached 50.

Fig. 9: Scalability Test

As seen from the Figure 9, the process shows a gradual increase in the delay due to the increase of transactions. This increase in the delay is caused by the scalability problem of the Ethereum blockchain. There seems to be a tradeoff between speed and reward for the generation of the new block. The number of transactions mined in a single block of Ethereum blockchain depends on multiple factors such as gas price and limit. Another factor that increases the delay is the cloud storage server. As all the requests are sent concurrently, the cloud takes time to filter, re-encrypt and save the data. This can be reduced by adding more cloud servers and distributing the load.

Ix Discussion

By now we have demonstrated the proposed design of a blockchain based proxy re-encryption scheme for secure IoT data sharing. Our proposed system benefits all the concerned entities without compromising the security. The sensor owner is motivated to join the system as they get a platform to securely sell their data guaranteeing the privacy of it. The sensor owner can make profit in a traditional way, while the data requester can easily get the required data. Miners in the system get an incentive by trading the generated token. The trading platform is able to avoid single points of failure thanks to this distributed, self-regulated blockchain for transaction processing. However, some aspects of the system design can be further improved.

Ix-a Distributed cloud for scalability

In the current set-up, the storage infrastructure is organized in a very centralized way. Currently, in cloud computing, resources can be shared, and the end customer could have much lower costs and higher efficiency and uptime. However, data breaches or service interruptions in the big cloud are very common. These failures aren’t a one-time occurrence and they show that the cloud computing model of centralized storage is not as secure as it could be because it has a single point of failure.

Blockchain greatest strength is its versatility. Blockchain creates a decentralized and distributed storage marketplace. Blockchain along with cloud storage makes data fully decentralized because it is stored on multiple nodes across the globe while blockchain can keep track of all the interactions. Distributed cloud storage breaks files into fragments after being encrypted and then intelligently distributes them across dozens of nodes.

Ix-B Blockchain limitations

Proof of Work (PoW) is a heavy consensus algorithm, and its inefficiency becomes more significant in a public blockchain as miners would increase their hash power to gain more block rewards. Although it did not appear to be a problem in our implementation as our architecture includes a permissioned blockchain. As blockchain evolves, lightweight consensus protocols are being explored. One of the most promising replacements is the Proof-of-Stake (PoS) proposed by King et al. [33]. Our system design can be easily adapted to other blockchain platforms that use different consensus protocols. Hyperledger Fabric is an open source permissioned Distributed Ledger Technology (DLT) platform, that delivers some key differentiating capabilities over other popular distributed ledger or blockchain platforms [34]. Hyperledger Fabric has a highly modular and configurable architecture. It provides support for pluggable consensus protocols that enables the platform to be more effectively customized to fit particular use cases and trust models.

X Conclusions

In this paper, we have proposed a blockchain based trading platform with the combination of a paring free proxy re-encryption scheme to ensure secure transfer of the sensor data to the user. We have also validated the proof of concept model on a private Ethereum testbed and demonstrated the practicality of the system design using off-the-shelf laptops and raspberry pis. Moreover, our experiments and analysis verify that combing proxy re-encryption scheme with blockchain enables a secure platform for trading and sharing of the sensor data. The use of blockchain does increase the delay but it keeps a record of all the interaction between the entities and eliminates a need for a trusted third party. Our framework provides an efficient, fast and secure platform for storing, trading and managing of sensor data.

In the future, we plan to address the issues and challenges identified. We plan to extend the proposed system with an implementation on a different blockchain platform e.g. Hyperledger. We also plan to extend our architecture by adding a distributed cloud storage to make the system more scalable. In addition, we will try to increase the security of the cloud by adding a smart contract based Access Control List (ACL) and auditing system of the cloud server managed by the blockchain.

Acknowledgment

This work has been performed under the framework of the SECUREConnect, 6Genesis Flagship (grant 318927), Towards Digital Paradise, Industrial Edge, COST Action CA15127 (RECODIS) and CA16226 (SHELD-ON) projects.

References

  • [1] R. Taylor, D. Baron, and D. Schmidt, “The world in 2025-predictions for the next ten years,” in Microsystems, Packaging, Assembly and Circuits Technology Conference (IMPACT), 2015 10th International.   IEEE, 2015, pp. 192–195.
  • [2] N. Suryadevara and S. Mukhopadhyay, “Internet of things: A review and future perspective,” Reliance, 2018.
  • [3] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and M. Ayyash, “Internet of things: A survey on enabling technologies, protocols, and applications,” IEEE Communications Surveys & Tutorials, vol. 17, no. 4, pp. 2347–2376, 2015.
  • [4] L. Hou, S. Zhao, X. Xiong, K. Zheng, P. Chatzimisios, M. S. Hossain, and W. Xiang, “Internet of things cloud: architecture and implementation,” IEEE Communications Magazine, vol. 54, no. 12, pp. 32–39, 2016.
  • [5] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of things (iot): A vision, architectural elements, and future directions,” Future generation computer systems, vol. 29, no. 7, pp. 1645–1660, 2013.
  • [6] E. Karafili and E. C. Lupu, “Enabling data sharing in contextual environments: Policy representation and analysis,” in Proceedings of the 22nd ACM on Symposium on Access Control Models and Technologies.   ACM, 2017, pp. 231–238.
  • [7] A. Panarello, N. Tapas, G. Merlino, F. Longo, and A. Puliafito, “Blockchain and iot integration: A systematic survey,” Sensors, vol. 18, no. 8, p. 2575, 2018.
  • [8] Z. Zheng, S. Xie, H. Dai, X. Chen, and H. Wang, “An overview of blockchain technology: Architecture, consensus, and future trends,” in Big Data (BigData Congress), 2017 IEEE International Congress on.   IEEE, 2017, pp. 557–564.
  • [9] H. Watanabe, S. Fujimura, A. Nakadaira, Y. Miyazaki, A. Akutsu, and J. Kishigami, “Blockchain contract: Securing a blockchain applied to smart contracts,” in Consumer Electronics (ICCE), 2016 IEEE International Conference on.   IEEE, 2016, pp. 467–468.
  • [10] S. Ølnes, “Beyond bitcoin enabling smart government using blockchain technology,” in International Conference on Electronic Government and the Information Systems Perspective.   Springer, 2016, pp. 253–264.
  • [11] J.-C. Cheng, N.-Y. Lee, C. Chi, and Y.-H. Chen, “Blockchain and smart contract for digital certificate,” in 2018 IEEE International Conference on Applied System Invention (ICASI).   IEEE, 2018, pp. 1046–1051.
  • [12] M. Bartoletti and L. Pompianu, “An empirical analysis of smart contracts: platforms, applications, and design patterns,” in International Conference on Financial Cryptography and Data Security.   Springer, 2017, pp. 494–509.
  • [13] N. Koblitz, “Elliptic curve cryptosystems,” Mathematics of computation, vol. 48, no. 177, pp. 203–209, 1987.
  • [14] J. S. Kumar and D. R. Patel, “A survey on internet of things: Security and privacy issues,” International Journal of Computer Applications, vol. 90, no. 11, 2014.
  • [15] Y. Yang, L. Wu, G. Yin, L. Li, and H. Zhao, “A survey on security and privacy issues in internet-of-things,” IEEE Internet of Things Journal, vol. 4, no. 5, pp. 1250–1258, 2017.
  • [16] H. Suo, J. Wan, C. Zou, and J. Liu, “Security in the internet of things: a review,” in Computer Science and Electronics Engineering (ICCSEE), 2012 international conference on, vol. 3.   IEEE, 2012, pp. 648–651.
  • [17] M. A. Khan and K. Salah, “Iot security: Review, blockchain solutions, and open challenges,” Future Generation Computer Systems, vol. 82, pp. 395–411, 2018.
  • [18] S. Notra, M. Siddiqi, H. H. Gharakheili, V. Sivaraman, and R. Boreli, “An experimental study of security and privacy risks with emerging household appliances,” in Communications and Network Security (CNS), 2014 IEEE Conference on.   IEEE, 2014, pp. 79–84.
  • [19] S. Huh, S. Cho, and S. Kim, “Managing iot devices using blockchain platform,” in Advanced Communication Technology (ICACT), 2017 19th International Conference on.   IEEE, 2017, pp. 464–467.
  • [20] M. Banerjee, J. Lee, and K.-K. R. Choo, “A blockchain future for internet of things security: a position paper,” Digital Communications and Networks, vol. 4, no. 3, pp. 149–160, 2018.
  • [21] N. Kshetri, “Can blockchain strengthen the internet of things?” IT Professional, vol. 19, no. 4, pp. 68–72, 2017.
  • [22] A. Dorri, S. S. Kanhere, R. Jurdak, and P. Gauravaram, “Blockchain for iot security and privacy: The case study of a smart home,” in Pervasive Computing and Communications Workshops (PerCom Workshops), 2017 IEEE International Conference on.   IEEE, 2017, pp. 618–623.
  • [23] M. Blaze, G. Bleumer, and M. Strauss, “Divertible protocols and atomic proxy cryptography,” in International Conference on the Theory and Applications of Cryptographic Techniques.   Springer, 1998, pp. 127–144.
  • [24] G. Ateniese, K. Fu, M. Green, and S. Hohenberger, “Improved proxy re-encryption schemes with applications to secure distributed storage,” ACM Transactions on Information and System Security (TISSEC), vol. 9, no. 1, pp. 1–30, 2006.
  • [25] L. Jiang and D. Guo, “Dynamic encrypted data sharing scheme based on conditional proxy broadcast re-encryption for cloud storage,” IEEE Access, vol. 5, pp. 13 336–13 345, 2017.
  • [26] C.-K. Chu, J. Weng, S. S. Chow, J. Zhou, and R. H. Deng, “Conditional proxy broadcast re-encryption,” in Australasian Conference on Information Security and Privacy.   Springer, 2009, pp. 327–342.
  • [27] M. Sun, C. Ge, L. Fang, and J. Wang, “A proxy broadcast re-encryption for cloud data sharing,” Multimedia Tools and Applications, vol. 77, no. 9, pp. 10 455–10 469, 2018.
  • [28] P. Shabisha, A. Braeken, A. Touhafi, and K. Steenhaut, “Elliptic curve qu-vanstone based signcryption schemes with proxy re-encryption for secure cloud data storage,” in International Conference of Cloud Computing Technologies and Applications.   Springer, 2017, pp. 1–18.
  • [29] M. Campagna, “Sec 4: Elliptic curve qu-vanstone implicit certificate scheme (ecqv),” institution content-type= institution> Certicom Res</institution>., Mississauga, ON, Canada, Tech. Rep, 2013.
  • [30] “Official go implementation of the ethereum protocol,” Accessed: 27.09.2018, uRL: https://github.com/ethereum/go-ethereum.
  • [31] “Truffle,” Accessed: 27.09.2018, uRL: https://truffleframework.com/docs/truffle/overview.
  • [32] “Solidity, the contract-oriented programming language,” Accessed: 27.09.2018, uRL: https://github.com/ethereum/solidity.
  • [33] S. King and S. Nadal, “Ppcoin: Peer-to-peer crypto-currency with proof-of-stake,” self-published paper, August, vol. 19, 2012.
  • [34] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich et al., “Hyperledger fabric: a distributed operating system for permissioned blockchains,” in Proceedings of the Thirteenth EuroSys Conference.   ACM, 2018, p. 30.