Revocation-Ready CP-ABE Key Management for Blockchain-Based IoT Data Sharing

TL;DR

This paper introduces a revocation-ready key management system for blockchain-based IoT data sharing that enhances security and efficiency by replacing online key release with ciphertext publication and supporting policy evolution without re-encrypting large files.

Contribution

It proposes a novel key management layer using CP-ABE ciphertexts, epoch-based revocation, and a lightweight rotation protocol to improve security and scalability in IoT data sharing systems.

Findings

CP-ABE encryption takes about 186 ms for a complex policy.

Ledger and storage operations are very fast, around 1-2 ms.

Epoch-based revocation reduces key update costs and scales with shared assets.

Abstract

Blockchain-based IoT data sharing systems increasingly adopt a hybrid architecture in which a permissioned ledger stores tamper-evident metadata while encrypted payloads are placed in content-addressed storage. In such systems, a central security bottleneck is key access control: enforcing dynamic, multi-user authorization for releasing or using bulk-data decryption keys. Existing designs often rely on always-online RBAC or smart-contract gates that return keys to authorized users, reintroducing a trusted online policy enforcement point and weakening auditability. This paper presents a revocation-ready key management layer that replaces online key release with ciphertext key publication: the ledger records metadata of the form (CID, CK, PolicyID, epoch), where CK is a CP-ABE ciphertext encapsulating an AES-GCM key. Users retrieve CK from the ledger and decrypt locally if their attributes satisfy the policy. To support forward revocation and policy evolution without re-encrypting large files, the design introduces an epoch/time-bound attribute and a lightweight CK-rotation protocol that updates only small ciphertext keys and ledger entries. We implement a minimal end-to-end prototype using a local content-addressed store, a hash-chained ledger, and a CP-ABE backend, with the goal of isolating key-management costs rather than benchmarking production blockchain throughput. Experiments on a commodity MacBook show that CP-ABE encryption dominates store latency, with approximately 186 ms for a k=6 mixed-Boolean policy, while ledger and storage operations remain around 1-2 ms. Epoch-based revocation amortizes key update cost under churn, gateway-assisted mode reduces median client-side decryption time by more than 4x under a simulated 4x client slow-down, and ledger growth scales with the number of shared assets rather than the number of readers.