arxiv: 2605.04280 · v1 · submitted 2026-05-05 · 💻 cs.CR · cs.DC

Recognition: unknown

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

Chun Yin Chiu

Authors on Pith no claims yet

Pith reviewed 2026-05-08 17:11 UTC · model grok-4.3

classification 💻 cs.CR cs.DC

keywords CP-ABEblockchainIoT data sharingkey managementrevocationaccess controlciphertext policy

0 comments

The pith

Publishing CP-ABE ciphertext keys on the blockchain ledger lets users decrypt IoT data locally while supporting epoch-based revocation without re-encrypting files.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper establishes a key-management design for blockchain IoT systems that stores metadata tuples of the form (CID, CK, PolicyID, epoch) on a permissioned ledger, where CK is a CP-ABE ciphertext wrapping an AES-GCM key. Users fetch the CK and attempt local decryption only if their attributes satisfy the embedded policy, removing the need for an always-online key-release server. An epoch/time-bound attribute together with a CK-rotation protocol allows policy changes and revocations to be enacted by updating only the small CK and the corresponding ledger entry rather than the bulk encrypted payloads. Experiments on commodity hardware show that the dominant cost is the initial CP-ABE encryption (approximately 186 ms for a k=6 policy) while ledger and storage operations stay in the low milliseconds, and that epoch rotation amortizes update cost under user churn.

Core claim

A revocation-ready key layer for blockchain-based IoT data sharing replaces online key-release gates with ledger-published CP-ABE ciphertexts; forward revocation and policy evolution are achieved by rotating only the small ciphertext keys and their epoch attributes, so that authorized users continue to decrypt locally after retrieving the current CK from the ledger.

What carries the argument

The epoch/time-bound attribute paired with a lightweight CK-rotation protocol that updates only ciphertext keys and ledger entries instead of bulk data.

If this is right

Revocation cost scales with the number of shared assets rather than the number of readers.
Gateway-assisted decryption reduces client-side latency by more than 4x when clients are resource-constrained.
Ledger growth remains linear in the number of distinct data assets, independent of reader population.
Policy evolution no longer requires re-encrypting or re-uploading the original encrypted payloads.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

The same ledger-plus-epoch pattern could be reused for access control in other content-addressed storage systems that already maintain tamper-evident metadata.
By moving policy evaluation entirely to the client after CK retrieval, the design reduces the attack surface of smart-contract key-release logic.
Testing the scheme on a public permissionless ledger would reveal whether the public visibility of CK values introduces new side-channel risks not present in the permissioned setting studied here.

Load-bearing premise

Attribute assignment occurs securely outside the system and the chosen CP-ABE scheme remains secure even when its ciphertexts are published on a public ledger.

What would settle it

An experiment in which a previously authorized user, after an epoch rotation that removes the matching attribute, is still able to decrypt data using a retained old CK.

Figures

Figures reproduced from arXiv: 2605.04280 by Chun Yin Chiu.

**Figure 1.** Figure 1: System components and data flow in the proposed ledger plus content-addressed storage view at source ↗

**Figure 2.** Figure 2: CP-ABE encryption time versus policy size view at source ↗

**Figure 3.** Figure 3: End-to-end store and retrieve latency breakdown for a 1 MB object under a mixed view at source ↗

**Figure 4.** Figure 4: Total cryptographic rekeying cost over a 180 s window for naive per-revocation rekeying view at source ↗

**Figure 5.** Figure 5: Experiment 3 operational scaling: ledger growth and access latency (p50/p99) as the view at source ↗

**Figure 6.** Figure 6: Median (p50) time for full client decryption versus gateway-assisted decryption under view at source ↗

**Figure 7.** Figure 7: Append throughput versus ledger batch size in the local hash-chained log used by the view at source ↗

read the original 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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

Epoch-bound CP-ABE on the ledger gives a workable revocation path for IoT data sharing, but the immutable history of entries undercuts forward security claims.

read the letter

This paper's main contribution is a revocation-ready key management scheme using epoch-bound CP-ABE ciphertexts on a permissioned ledger, but the immutable history of entries undercuts forward security claims. It replaces always-online key gates with ledger-published CKs that users fetch and decrypt locally when their attributes match the policy. The design adds an epoch attribute and a rotation protocol that only updates the small CK entries and ledger metadata instead of re-encrypting the actual payloads. That is the concrete engineering step forward here. The prototype measurements back up the practicality angle. CP-ABE encryption dominates at roughly 186 ms for a k=6 policy, while ledger and storage operations stay in the low milliseconds. Gateway-assisted mode cuts client decryption time by more than 4x under slowdown, and growth scales with assets rather than readers. Those numbers isolate the key-management costs cleanly and show the approach stays lightweight under churn. The soft spot sits in the revocation guarantee. Because the ledger keeps every prior (CID, CK, PolicyID, epoch) tuple, a user revoked after epoch t can still retrieve the historical CK, decrypt it with attributes valid at that time, recover the AES key, and access the content-addressed data. The paper does not describe any mechanism that forces clients to ignore old entries or invalidates them, so the forward-revocation property rests on an unenforceable assumption about client behavior. No security proofs or explicit threat model appear to close this gap. This is useful reading for engineers building hybrid blockchain-IoT systems who need revocation without constant online policy points. A practitioner looking for implementation patterns and performance tradeoffs will get value from the prototype details. It deserves a serious referee to examine the revocation logic and request a clearer security argument.

Referee Report

3 major / 2 minor

Summary. The manuscript proposes a revocation-ready key management layer for blockchain-based IoT data sharing. It stores metadata of the form (CID, CK, PolicyID, epoch) on a permissioned ledger, where CK is a CP-ABE ciphertext of an AES-GCM key. Users fetch the CK from the ledger and decrypt locally if their attributes satisfy the policy. An epoch/time-bound attribute combined with a lightweight CK-rotation protocol is claimed to enable forward revocation and policy evolution without re-encrypting large files; only small CKs and ledger entries are updated. A minimal prototype on a local content-addressed store and hash-chained ledger shows CP-ABE encryption dominating latency (~186 ms for k=6 policy) while ledger operations are 1-2 ms, with epoch rotation amortizing costs under churn.

Significance. If the revocation mechanism holds, the design could reduce reliance on always-online trusted key-release points in hybrid blockchain/IoT systems while preserving auditability via the tamper-evident ledger. The prototype isolates key-management costs and provides concrete latency numbers, which is a positive for practicality claims. However, the absence of any security proofs, threat model, or baseline comparisons limits the result's immediate significance in the cs.CR venue.

major comments (3)

[Abstract] Abstract and design description: the central claim that the epoch/time-bound attribute plus CK-rotation protocol supports 'forward revocation' is undermined by the immutable ledger. Historical (CID, CK, PolicyID, epoch) entries remain readable; a user revoked after epoch t retains attributes valid up to t, can retrieve the old CK, decrypt the AES-GCM key under the old policy, and access the content-addressed payload. No mechanism is described that forces clients to ignore non-latest epochs or invalidates old CKs, making revocation ineffective for already-shared data.
[Abstract] No section provides a threat model, security definitions, or proofs. Publishing CKs on a public ledger and relying on external attribute assignment require explicit assumptions (e.g., against collusion, ledger tampering, or attribute leakage); without them the CP-ABE security reduction cannot be assessed.
[Experiments] Experiments section: the prototype demonstrates basic feasibility but reports no baseline comparisons to RBAC or smart-contract key-release schemes, no formal verification of the rotation protocol, and no analysis of revocation effectiveness against the historical-entry attack. This leaves the performance claims (e.g., 4x decryption speedup in gateway mode) uncontextualized.

minor comments (2)

[Abstract] The integration of the epoch attribute into the CP-ABE policy (e.g., as a time-bound Boolean or numeric attribute) should be specified explicitly so readers can verify how rotation interacts with existing policies.
Add references to standard CP-ABE constructions (e.g., Waters, Bethencourt et al.) and prior blockchain-IoT key-management papers to situate the contribution.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive feedback. We address each major comment below and indicate the revisions we will make to the manuscript.

read point-by-point responses

Referee: [Abstract] Abstract and design description: the central claim that the epoch/time-bound attribute plus CK-rotation protocol supports 'forward revocation' is undermined by the immutable ledger. Historical (CID, CK, PolicyID, epoch) entries remain readable; a user revoked after epoch t retains attributes valid up to t, can retrieve the old CK, decrypt the AES-GCM key under the old policy, and access the content-addressed payload. No mechanism is described that forces clients to ignore non-latest epochs or invalidates old CKs, making revocation ineffective for already-shared data.

Authors: We appreciate this observation, which correctly identifies that the revocation semantics require clearer explanation. The CK-rotation protocol enables policy updates and revocation for new data shares by publishing a fresh CK under an updated epoch attribute, without re-encrypting the large payloads. We will revise the abstract and design sections to state explicitly that clients retrieve only the CK for the current (latest) epoch of each CID. We will also add a discussion noting that this provides forward revocation for subsequent shares while historical entries remain readable for auditability; users who held valid attributes at the time of an earlier share can still decrypt that data. This limitation is inherent to avoiding payload re-encryption and will be stated plainly in the revised text. revision: yes
Referee: [Abstract] No section provides a threat model, security definitions, or proofs. Publishing CKs on a public ledger and relying on external attribute assignment require explicit assumptions (e.g., against collusion, ledger tampering, or attribute leakage); without them the CP-ABE security reduction cannot be assessed.

Authors: We agree that an explicit threat model and security assumptions section is needed. In the revised manuscript we will add a dedicated section that defines the threat model, including assumptions about the permissioned ledger's integrity, the attribute authority, and non-collusion among users. We will articulate the security goals (confidentiality of the AES-GCM key under CP-ABE, tamper-evidence of metadata) and reference the standard CP-ABE security model. A full formal proof of the composite system is a substantial undertaking beyond the current scope and will be noted as future work; the contribution focuses on the practical architecture and prototype. revision: partial
Referee: [Experiments] Experiments section: the prototype demonstrates basic feasibility but reports no baseline comparisons to RBAC or smart-contract key-release schemes, no formal verification of the rotation protocol, and no analysis of revocation effectiveness against the historical-entry attack. This leaves the performance claims (e.g., 4x decryption speedup in gateway mode) uncontextualized.

Authors: We agree that the experiments section would benefit from additional context. In the revision we will add baseline comparisons to RBAC and smart-contract key-release approaches using equivalent metrics. We will also include a short analysis of revocation effectiveness, explicitly addressing the historical-entry scenario and the intended guarantees. The CK-rotation protocol will be described with clearer step-by-step detail to support verification. These additions will better situate the reported performance figures, including the 4x decryption speedup observed in gateway-assisted mode. revision: yes

Circularity Check

0 steps flagged

No circularity: design proposal uses external primitives without self-referential reductions

full rationale

The manuscript is a system-design paper that describes a hybrid blockchain/CP-ABE architecture, introduces an epoch attribute and CK-rotation protocol, and reports latency measurements from a prototype. No equations, fitted parameters, uniqueness theorems, or predictions are presented whose validity reduces to the paper's own inputs or self-citations. All load-bearing security claims rest on the standard assumptions of CP-ABE confidentiality and ledger immutability, which are treated as external. The experimental results are direct measurements rather than derived forecasts, so the derivation chain is self-contained.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The design relies on established cryptographic primitives and ledger properties without new free parameters or invented entities.

axioms (2)

domain assumption CP-ABE provides secure attribute-based decryption under standard assumptions
Invoked for local decryption when attributes satisfy the policy.
domain assumption Permissioned ledger supplies tamper-evident metadata
Required for recording (CID, CK, PolicyID, epoch) tuples.

pith-pipeline@v0.9.0 · 9792 in / 1094 out tokens · 31756 ms · 2026-05-08T17:11:01.956016+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

14 extracted references · 11 canonical work pages

[1]

Juan Benet. 2014. IPFS - Content Addressed, Versioned, P2P File System. arXiv:1407.3561. https://arxiv.org/abs/1407.3561

work page Pith review arXiv 2014
[2]

Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Muralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, Alessandro Sorniotti, Chrysoula Stathakopoulou, Marko Vukolic, Sharon Weed Cocco, and Jason...

work page doi:10.1145/3190508.3190538 2018
[3]

Hu, David Ferraiolo, Rick Kuhn, Adam Schnitzer, Kenneth Sandlin, Robert Miller, and Karen Scarfone

Vincent C. Hu, David Ferraiolo, Rick Kuhn, Arthur R. Friedman, Alan J. Lang, Margaret M. Cogdell, Adam Schnitzer, Kenneth Sandlin, Robert Miller, and Karen Scarfone. 2014. Guide to Attribute Based Access Control (ABAC) Definition and Considerations. NIST Special Publication 800-162.https://doi.org/10.6028/NIST.SP.800-162

work page doi:10.6028/nist.sp.800-162 2014
[4]

John Bethencourt, Amit Sahai, and Brent Waters. 2007. Ciphertext-Policy Attribute-Based Encryption. InIEEE Symposium on Security and Privacy. 321–334. https://doi.org/10.1 109/SP.2007.11

2007
[5]

Brent Waters. 2011. Ciphertext-Policy Attribute-Based Encryption: An Expressive, Efficient, and Provably Secure Realization. InPublic Key Cryptography - PKC 2011. Springer. 53–70. https://doi.org/10.1007/978-3-642-19379-8_4

work page doi:10.1007/978-3-642-19379-8_4 2011
[6]

Shashank Agrawal and Melissa Chase. 2017. FAME: Fast Attribute-Based Message Encryption. InProceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. ACM.https://doi.org/10.1145/3133956.3134014

work page doi:10.1145/3133956.3134014 2017
[7]

gofe: A library for functional encryption in Go

Fentec Project. gofe: A library for functional encryption in Go. GitHub repository.https: //github.com/fentec-project/gofe. Accessed: May 2026

2026
[8]

Shucheng Yu, Cong Wang, Kui Ren, and Wenjing Lou. 2010. Achieving Secure, Scalable, and Fine-grained Data Access Control in Cloud Computing. InIEEE INFOCOM 2010. 1–9. https://doi.org/10.1109/INFCOM.2010.5462174

work page doi:10.1109/infcom.2010.5462174 2010
[9]

Tsz Hon Yuen, Peng Zhang, and Kaitai Liang. 2018. Time-Based Direct Revocable Ciphertext- Policy Attribute-Based Encryption with Short Revocation List. InApplied Cryptography and Network Security (ACNS 2018). Springer. https://doi.org/10.1007/978-3-319-93387-0 _27

work page doi:10.1007/978-3-319-93387-0 2018
[10]

Alejandro Penuelas-Angulo, Claudia Feregrino-Uribe, and Miguel Morales-Sandoval. 2023. Revocation in Attribute-Based Encryption for Fog-Enabled Internet of Things: A Systematic Survey.Internet of Things23, 100827.https://doi.org/10.1016/j.iot.2023.100827

work page doi:10.1016/j.iot.2023.100827 2023
[11]

Matthew Green, Susan Hohenberger, and Brent Waters. 2011. Outsourcing the Decryption of Attribute-Based Encryption Ciphertexts. InProceedings of the 20th USENIX Security Symposium.https://www.usenix.org/event/sec11/tech/full_papers/Green.pdf. 13

2011
[12]

Kanhere, Raja Jurdak, and Praveen Gauravaram

Ali Dorri, Salil S. Kanhere, Raja Jurdak, and Praveen Gauravaram. 2017. Blockchain for IoT Security and Privacy: The Case Study of a Smart Home. InIEEE International Conference on Pervasive Computing and Communications Workshops. https://doi.org/10.1109/PERCOMW. 2017.7917634

work page doi:10.1109/percomw 2017
[13]

Hua Dai, Zibin Zheng, and Yan Zhang. 2019. Blockchain for Internet of Things: A Survey. arXiv:1906.00245.https://arxiv.org/abs/1906.00245

work page arXiv 2019
[14]

Morris Dworkin. 2007. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. NIST Special Publication 800-38D.https://doi.org/10.6028/NI ST.SP.800-38D. 14

work page doi:10.6028/ni 2007