CRDCMay 5

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

arXiv:2605.042802.0
Predicted impact top 98% in CR · last 90 daysOriginality Incremental advance
AI Analysis

For blockchain-based IoT data sharing systems, this work addresses the key management bottleneck by enabling dynamic, multi-user authorization with revocation support while maintaining auditability and avoiding online policy enforcement points.

The paper proposes a revocation-ready CP-ABE key management layer for blockchain-based IoT data sharing that replaces online key release with ciphertext key publication, supporting forward revocation and policy evolution without re-encrypting large files. Experiments show CP-ABE encryption dominates store latency (~186 ms for a k=6 policy), while ledger operations remain ~1-2 ms, and gateway-assisted mode reduces client decryption time by >4x under simulated slowdown.

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.

Foundations

The foundational work for this paper's niche, ranked by how specifically the neighbourhood builds on it — not by global fame.

Your Notes