Source-linked AI summary
Blockchain based Proxy Re-Encryption Scheme for Secure IoT Data Sharing
Ahsan Manzoor, Madhsanka Liyanage, An Braeken, Salil S. Kanhere, Mika Ylianttila
TL;DR
Centralized IoT data sharing relies on cloud providers, raising trust, payment, and scalability concerns. The paper combines blockchain smart contracts with proxy re-encryption for data sharing. In its private Ethereum testbed, sharing encrypted data took an average of 48.01 s, with proxy re-encryption increasing delay by 60%.
Problem
Centralized IoT data sharing depends on third-party cloud providers, while static agreements and provider trust and fees present challenges to scaling and timely sharing.
Source: §I · p. 1Method
The paper combines blockchain smart contracts with proxy re-encryption to share encrypted sensor data and manage transactions and access agreements.
Source: §I · p. 1, §VII · p. 4Results
48.01 s average sharing time after the initial request; adding proxy re-encryption increases delay by 60% due to mining the re-encryption key.
Source: A. Impact of Proxy Re-Encryption · p. 4Takeaways & Limitations
The authors report a proof-of-concept system validated on a private Ethereum testbed using off-the-shelf laptops and Raspberry Pis.
Source: §VII · p. 4
Abstract
from arXiv · showhide
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.
I. INTRODUCTION
Centralized cloud sharing depends on third parties for storage and access control, raising trust, payment, and scalability concerns. The paper proposes blockchain-based proxy re-encryption with smart contracts to protect data and automate transactions.
I. INTRODUCTION
- The paper situates its proposal amid projected IoT growth, heterogeneous sensor data, and applications spanning sectors such as healthcare, smart cities, and manufacturing.It cites predictions of 100 billion connected devices by 2025 and more than $11 trillion in global economic impact.Source: §I · p. 1
- Centralized IoT sharing requires sensor owners and users to trust and pay cloud providers, while static agreements delay sharing and the model may not scale.IoT data serves heterogeneous stakeholders, and resource-constrained devices need efficient integrity, processing, and security mechanisms.Source: §I · p. 1
- The proposed blockchain and proxy re-encryption scheme protects data confidentiality while smart contracts automatically manage financial transactions and apply agreed service requirements.The paper says this removes manual payment verification and avoids disputes over payments and predefined requirements.Source: §I · p. 1
II. RELATED WORK
Prior work addresses IoT security threats, blockchain applications, and proxy re-encryption, but the paper identifies a need for a practical approach to secure IoT data sharing. It proposes combining blockchain with pairing-free proxy re-encryption.
II. RELATED WORK
- Prior IoT security research has examined threats and insecure data transfer, while blockchain has also been discussed for securing IoT platforms.The cited work includes reviews of IoT security challenges and demonstrations of basic security weaknesses in off-the-shelf smart-home devices.Source: §II · pp. 1–2
- Earlier proxy re-encryption schemes were described as nondynamic or not implemented in practice, while the proposed scheme builds on a cloud-storage approach and adds metadata.The paper attributes the metadata modification to making the underlying scheme practical.Source: §II · p. 2
- The paper argues that prior work only partly addresses secure IoT data sharing and proposes blockchain with pairing-free proxy re-encryption for secure sensor-data transfer.It notes that limited device computing and power make complex security algorithms harder to execute on IoT devices.Source: §II · p. 2
111. PROPOSED ARCHITECTURE
The architecture links sensor owners, requesters, cloud storage, and a blockchain. Smart contracts coordinate access, payment, and proxy re-encryption so requesters can retrieve data encrypted for them.
111. PROPOSED ARCHITECTURE
- The architecture has sensor owners, data requesters, a cloud provider, and a blockchain, with the blockchain supporting registration and access requests.Owners register sensors through a smart-contract function and provide key material for encrypted uploads to cloud storage.Source: 111. PROPOSED ARCHITECTURE · p. 2
- After a user requests sensor access, the owner and requester agree through a mined smart contract that manages the public key and associated financial transactions.The blockchain notifies cloud storage, which filters data according to the request; the owner's re-encryption key is updated on the contract.Source: 111. PROPOSED ARCHITECTURE · p. 2
- The cloud server re-encrypts filtered data and stores it temporarily; the blockchain publishes its address and notifies the requester, who decrypts it with a private key.The system therefore returns data encrypted for the requester rather than exposing the owner's original ciphertext.Source: 111. PROPOSED ARCHITECTURE · p. 2
IV. SECURITY ASPECTS
The paper applies a certificate-based proxy re-encryption scheme to support encryption, delegation, re-encryption, and decryption. Its setup establishes public parameters, and the proposed key-generation phase combines user key generation and certification.
IV. SECURITY ASPECTS
- The certificate-based proxy re-encryption scheme consists of seven polynomial-time algorithms, and combines UserKeyGen and Certify into CertifiedUserKeyGen.The listed phases include setup, certified user key generation, encryption, re-key generation, re-encryption, and two decryption phases.Source: §IV · p. 2
- Setup derives public parameters and a master secret key from a security parameter, including an elliptic-curve group, generator point, and four hash functions.The setup passage defines the group as elliptic-curve points and gives the public parameters as the group, order, generator, public value, and hashes.Source: §IV · p. 2
- CertifiedUserKeyGen is based on the ECQV certificate mechanism and includes entity-generated randomness and certification-authority checks.The passage describes the entity sending an identity and value to the CA, which checks identity and returns a certificate-related tuple.Source: §IV · pp. 2–3
- Encryption attaches metadata to the message, while ReKey derives a delegation key using the owner's secret and the delegate's certified public key.The ciphertext output includes the original ciphertext and metadata; the resulting re-encryption key is rkAB.Source: §IV · p. 3
- Re-encryption changes the owner's ciphertext into a delegate ciphertext, and the delegate's decryption phase derives the message from that transformed ciphertext.The owner also has a decryption phase to recover the original message and check its authenticity.Source: §IV · p. 3
V. IMPLEMENTATION
The prototype combines a permissioned Ethereum blockchain, IoT sensors, and cloud storage to demonstrate the system design. It connects the devices and uses Google Firebase for data storage.
V. IMPLEMENTATION
- The prototype combines a permissioned Ethereum blockchain, IoT sensors, and a cloud server for data storage.The authors present it as a feasibility demonstration of the system design.Source: §V · p. 3
- The setup includes three IoT sensors, three mining computers, five Ethereum full nodes, two regular users, and one cloud storage server.Source: §V · p. 3
- The devices were connected to the internet, miners and full nodes were linked using Geth auto-discovery, and Google Firebase was configured for storage.Source: §V · p. 3
A. Miners
Three miners generate blocks on average every 13 seconds, running on virtual machines with identical hardware capabilities. They use one Ethereum wallet and Geth V1.80 with four mining threads each.
A. Miners
- The three miners generate a block of transactions on average every 13 seconds.Source: A. Miners · p. 3
- The miners run on virtual machines with the same hardware capabilities.Source: A. Miners · p. 3
- The miners use one Ethereum wallet to collect rewards and run Geth V1.80 [34] with four mining threads each.Source: A. Miners · p. 3
B. Smart Contracts
The implementation uses two smart contracts: one provides sensor registration, data-request, and financial functions, while another is created at runtime when a user requests data.
B. Smart Contracts
- The system uses two smart contracts developed with Truffle [35] and compiled with Solidity 0.4.24 [36].Source: B. Smart Contracts · p. 3
- The first contract provides functions to register sensors, request data, and handle financial operations.Source: B. Smart Contracts · p. 3
- The second contract is dynamically created at runtime when a user requests data.Source: B. Smart Contracts · p. 3
C. IOT Sensors
Each TI Sensortag CC2650 connects to a Raspberry Pi 3 Model B over Bluetooth Low Energy, and the Pi manages sensor transactions on the blockchain. The sensor application performs the proxy re-encryption operations, uploads encrypted data, and uses the sensor MAC address as its identity.
C. IOT Sensors
- Each TI Sensortag CC2650 connects to a Raspberry Pi 3 Model B through Bluetooth Low Energy, and the Pi manages the sensor and its Ethereum account for blockchain transactions.Source: C. IOT Sensors · p. 3
- A Python 2.7.12 application connects to the sensor, performs the proxy re-encryption cryptography, uploads data to cloud storage, and synchronizes with the blockchain through Python-JSON-RPC.Source: C. IOT Sensors · p. 3
- The sensor MAC address serves as its identity for re-encryption; after registration, it uploads encrypted data, with the BLE connection to the Pi assumed completely secure.Source: C. IOT Sensors · p. 4
D. User Application
The user application selects a sensor and request terms, then retrieves, verifies, and decrypts data; the cloud server handles storage, authentication, integrity, and proxy re-encryption. In the proof-of-concept performance test, sharing encrypted data averaged 48.01 s, with proxy re-encryption adding 60% delay.
D. User Application
- The user selects a sensor and specifies data requirements, then downloads, checks the signature and integrity of, and decrypts the requested data.The application tracks the Ethereum wallet and the requester’s ECC secret key.Source: D. User Application · p. 4
E. Cloud Storage Server
- The cloud server uses the RSP as an Ethereum full node and Firebase for data storage, while performing proxy re-encryption and updating the contract’s shared-data address.Authentication and integrity checks occur on the RSP; encrypted sensor data and metadata are uploaded to Firebase in JSON format.Source: E. Cloud Storage Server · p. 4
VI. PERFORMANCE ANALYSIS
- The performance experiments evaluate the proof-of-concept framework, including the effect of proxy re-encryption on the overall system.In this experiment, sensors encrypt data before upload and re-encrypt it for sharing.Source: §VI · p. 4, A. Impact of Proxy Re-Encryption · p. 4
A. Impact of Proxy Re-Encryption
- 48.01 s on average to share encrypted data with the user; adding proxy re-encryption increases delay by 60%.The reported confidence interval is 2.07 s; the increase is attributed to mining the re-encryption key.Source: A. Impact of Proxy Re-Encryption · p. 4, Figure 3
B. Scalability
The scalability experiment varied the number of requester transactions and observed gradually increasing delay, attributed in the figure caption to Ethereum’s scalability problem. The paper reports a private-Ethereum proof of concept and identifies distributed cloud storage as a future scalability extension.
B. Scalability
- Delay increases gradually as transactions increase; the figure caption attributes this to Ethereum’s scalability problem and notes a speed–reward tradeoff for block generation.The number of transactions mined per block depends on factors including gas price; the supplied caption ends before completing that point.Source: Figure 4
VII. CONCLUSIONS
- The proof-of-concept model was validated on a private Ethereum testbed using off-the-shelf laptops and Raspberry Pis.The scalability experiment repeated each scenario 10 times, increasing requests in steps of five up to 50.Source: §VII · p. 4, B. Scalability · p. 4
- The authors plan to implement the system on another blockchain platform, such as Hyperledger, and add distributed cloud storage to improve scalability.Source: §VII · p. 4