Revocable Attribute-Based Encryption (RABE)

• Revocable Attribute-Based Encryption (RABE) is an advanced ABE mechanism that integrates user revocation and time-bound decryption to manage dynamic access control in cloud and IoT environments.
• It employs diverse construction paradigms—including time-encoded, proxy-based, accumulator-based, and server-aided strategies—to balance efficiency and security.
• RABE designs must prevent rollback attacks and collusion while ensuring confidentiality, forward secrecy, and backward secrecy in sensitive applications.

Revocable Attribute-Based Encryption (RABE) is a family of attribute-based encryption mechanisms that extends ABE with explicit user revocation and, in many formulations, time-bound decryption or ciphertext-update functionality. In RABE, decryption is conditioned not only on satisfaction of an access policy or predicate by an attribute set, but also on the user’s revocation status at a given epoch; some constructions further outsource update or transformation work to a cloud server or proxy. The model is motivated by cloud storage, outsourced enterprise data, online social networks, low-bitrate wireless sensor and actuator networks, and IoT data sharing, where fine-grained authorization must coexist with dynamic membership changes (Lee, 2018, Giacon et al., 2016, Jahid et al., 2012, Manna et al., 2021, Li et al., 25 Sep 2025).

1. Formal model and access semantics

A canonical RABE syntax consists of seven PPT algorithms: $\mathsf{Setup}$, $\mathsf{ExtractKey}$, $\mathsf{Encrypt}$, $\mathsf{UpdateKey}$, $\mathsf{DeriveDK}$, $\mathsf{Decrypt}$, and $\mathsf{Revoke}$. In the cloud-based formulation, a fully trusted authority initializes the system, issues private attribute-keys, maintains a revocation list $RL$, and periodically publishes epoch key-updates; a cloud server stores ciphertexts and may run ciphertext-update to a new epoch; and data users hold identities and access structures and derive time-bound decryption keys from their secret keys and the public key-updates (Lee, 2018).

Revocable-storage ABE (RS-ABE) refines this syntax by adding a public $\mathsf{Update\,CT}$ algorithm that advances a ciphertext from time $T$ to time $\mathsf{ExtractKey}$0 without re-encrypting the message. In the key-policy setting, user keys are bound to access structures $\mathsf{ExtractKey}$1 and ciphertexts are labeled by attribute sets $\mathsf{ExtractKey}$2; decryption succeeds only if $\mathsf{ExtractKey}$3 and the user is not revoked at the relevant epoch (Giacon et al., 2016).

Server-aided formulations split decryption into additional algorithms such as $\mathsf{ExtractKey}$4, $\mathsf{ExtractKey}$5, $\mathsf{ExtractKey}$6, and $\mathsf{ExtractKey}$7. In that model, the authority issues both a user secret key and a small server-side token, the server derives a time-specific transformation key from the token and update material, and the user performs only the final decryption step (Ling et al., 2018).

Access control is represented by several equivalent formalisms. Waters-style CP-ABE variants use monotonic access policies encoded as linear secret-sharing schemes $\mathsf{ExtractKey}$8 over an attribute universe $\mathsf{ExtractKey}$9, with decryption characterized by the existence of reconstruction coefficients. Threshold-tree policies are also common, especially in BSW-style systems, where shares of a secret are assigned recursively to internal nodes and leaves (Bartolomeo, 2023, Manna et al., 2021). In key-policy systems, the access structure is attached to the key rather than the ciphertext (Giacon et al., 2016).

2. Construction paradigms

The literature exhibits several recurring construction patterns for revocation.

Pattern	Core mechanism	Representative source
Time-encoded RABE	Public time encodings, revocation tree, ciphertext update	(Lee, 2018)
Proxy-based immediate revocation	CP-ABE + Naor–Pinkas broadcast revocation + proxy convert	(Jahid et al., 2012)
Accumulator-based RABE	CP-ABE + bilinear-map dynamic universal accumulator	(Bartolomeo, 2023)
Broadcast-revocable CP-ABE	Update keys, lazy proxy re-encryption, WSAN broadcast	(Manna et al., 2021)
Policy-strengthening cloud re-encryption	MSP extension, cloud-assisted revocation, checksum	(Li et al., 25 Sep 2025)
RS-ABE via SUE and complete subsets	KP-ABE + self-updatable encryption + user tree	(Giacon et al., 2016)
Server-aided lattice RABE	Predicate encryption + complete-subtree revocation + transform	(Ling et al., 2018)

One line of work uses explicit time encodings and a binary revocation tree. In Xu et al.’s scheme, public functions $\mathsf{Encrypt}$0 and $\mathsf{Encrypt}$1 encode epochs into bit strings, while a complete binary tree $\mathsf{Encrypt}$2 and a set $\mathsf{Encrypt}$3 determine which update components cover exactly the non-revoked leaves at epoch $\mathsf{Encrypt}$4. Secret keys are distributed along root-to-leaf paths, and a decryption key for time $\mathsf{Encrypt}$5 is derived by combining a path component with a matching update component (Lee, 2018).

A second line uses proxy or server assistance. PIRATTE interleaves BSW CP-ABE with Naor–Pinkas broadcast revocation so that each user key is blinded by a secret polynomial value $\mathsf{Encrypt}$6 and a minimally trusted proxy holds the shares required to remove that blinding during decryption. Revocation only refreshes the proxy’s material; no new keys are issued to non-revoked users and no existing ciphertexts are re-encrypted (Jahid et al., 2012). SEA-BREW similarly adopts indirect revocation, but packages update information so that a WSAN gateway distributes a single short broadcast message and the cloud performs lazy proxy re-encryption on stored ciphertexts (Manna et al., 2021).

A third line incorporates public accumulators. In the credential-oriented construction based on small-universe Waters CP-ABE, the publicly maintained set $\mathsf{Encrypt}$7 of currently non-revoked indices is embedded in an accumulator value $\mathsf{Encrypt}$8, and each user carries a witness $\mathsf{Encrypt}$9 proving current membership. Revocation updates the accumulator and the associated public terms; users update their witnesses locally or lose the ability to decrypt new ciphertexts (Bartolomeo, 2023).

A fourth line binds revocation to ciphertext evolution or policy strengthening. The key-policy RS-ABE construction combines a Complete-Subset framework over a binary tree, a self-updatable encryption component to track time, and a standard KP-ABE component for attribute policies; only the SUE header evolves during $\mathsf{UpdateKey}$0 (Giacon et al., 2016). RFABEO-DI instead lets the data owner provide an update key $\mathsf{UpdateKey}$1 that strengthens the access structure from $\mathsf{UpdateKey}$2 to $\mathsf{UpdateKey}$3, after which the cloud re-encrypts the ciphertext under a combined MSP while preserving a checksum for integrity verification (Li et al., 25 Sep 2025).

Finally, server-aided RABE can be instantiated from lattices. The lattice-based framework specializes server-aided revocable predicate encryption to the ABE setting using the Agrawal–Freeman–Vaikuntanathan inner-product PE scheme and the Complete-Subtree method of Naor, Naor, and Lotspiech; revocation is mediated by server-side transformation keys rather than by direct user-side epoch processing (Ling et al., 2018).

3. Security objectives and proof frameworks

A standard RABE security target includes four properties. First, confidentiality requires that no coalition of non-revoked users, the cloud server, or revoked users learns a message from ciphertexts for which their attributes do not satisfy the access policy or for which they have been revoked by time $\mathsf{UpdateKey}$4. Second, collusion resistance requires that combining valid keys does not enable unauthorized decryption. Third, revocability, stated as forward secrecy, requires that once an identity is revoked at epoch $\mathsf{UpdateKey}$5 it cannot decrypt ciphertexts encrypted at epochs $\mathsf{UpdateKey}$6 even if it colludes with the cloud server. Fourth, backward secrecy requires that a newly joined or newly unrevoked user at epoch $\mathsf{UpdateKey}$7 cannot decrypt ciphertexts from epochs $\mathsf{UpdateKey}$8 (Lee, 2018).

These properties are formalized in several related indistinguishability games. In the selective IND-RABE-CPA game, the adversary declares a challenge attribute set in advance, receives public parameters, adaptively queries key generation, revocation, and update-key oracles under “no trivial win” restrictions, and is challenged on an encryption at epoch $\mathsf{UpdateKey}$9; its advantage is $\mathsf{DeriveDK}$0 (Lee, 2018). The accumulator-based construction proves selective security by extending Waters CP-ABE’s game, with challenge ciphertexts formed under the current accumulator state and assumptions given by Decisional BDH and Decisional $\mathsf{DeriveDK}$1-BDHE (Bartolomeo, 2023). RFABEO-DI strengthens the confidentiality target to adaptive IND-CPA with many challenge ciphertexts and also defines forward-secure IND-CPA, backward-secure IND-CPA, and an integrity notion in which successful ciphertext forgery implies breaking discrete log (Li et al., 25 Sep 2025).

Underlying hardness assumptions vary with the platform. Pairing-based systems often assume DBDH in bilinear groups (Lee, 2018, Jahid et al., 2012). The key-policy RS-ABE proof uses composite-order bilinear groups and three assumptions denoted A1, A2, and A3, realized through a hybrid sequence that turns keys and ciphertexts semi-functional (Giacon et al., 2016). SEA-BREW proves adaptive IND-CPA in the generic bilinear group model against both colluding consumers and an honest-but-curious cloud colluding with consumers (Manna et al., 2021). The server-aided lattice construction is proven secure in the standard model, in a selective manner, under Learning With Errors (Ling et al., 2018).

Some RABE systems also target properties beyond CPA confidentiality. The credential-oriented accumulator construction adds a mild CCA-secure KEM-style transform so that a verifier cannot distinguish which user key was used, beyond learning “decrypts/does not decrypt,” yielding credential unlinkability and anonymous predicate proofs (Bartolomeo, 2023). RFABEO-DI adds plaintext integrity by binding two blinded message components to a checksum $\mathsf{DeriveDK}$2 and rejecting any decryption whose recomputed checksum does not match (Li et al., 25 Sep 2025).

4. Ciphertext rollback and the ciphertext outdate attack

A central security lesson in RABE is that public update functionality can introduce rollback channels if time binding is malleable. In the analyzed Xu et al. construction, the attack surface is created by the interaction of $\mathsf{DeriveDK}$3, $\mathsf{DeriveDK}$4, and re-randomizable ciphertext components. The critical lemma states that if $\mathsf{DeriveDK}$5 and the zero-bit index sets satisfy $\mathsf{DeriveDK}$6, then from a ciphertext at epoch $\mathsf{DeriveDK}$7 one can compute

$\mathsf{DeriveDK}$8

thereby obtaining a valid earlier-epoch component from the original later-epoch ciphertext (Lee, 2018).

The attack proceeds in four steps. The cloud server harvests a revoked user’s private key $\mathsf{DeriveDK}$9 whose attribute policy satisfies the challenge set $\mathsf{Decrypt}$0. It then downloads a public key-update $\mathsf{Decrypt}$1 for some earlier $\mathsf{Decrypt}$2 and derives $\mathsf{Decrypt}$3. Given the challenge ciphertext $\mathsf{Decrypt}$4, it uses the lemma to downgrade the ciphertext to $\mathsf{Decrypt}$5. Finally, because the harvested key and the earlier update are still valid at epoch $\mathsf{Decrypt}$6, the pairing terms in decryption cancel and reveal $\mathsf{Decrypt}$7; the adversary therefore wins the IND game with advantage $\mathsf{Decrypt}$8 (Lee, 2018).

The same work states that the scheme can be secure only in a weaker security model that forbids the cloud server from obtaining any revoked user’s private key after revocation. That restriction is described as hard to enforce in practice, because the cloud server may collect leaked or discarded keys (Lee, 2018). This point is structurally related to trust assumptions in other server- or proxy-assisted systems, such as the assumption in PIRATTE that revoked users cannot recover their old keys (Jahid et al., 2012).

The proposed repair direction is to replace the “time-encoding + re-randomization” mechanism with a self-updatable encryption sub-scheme. In that approach, each ciphertext evolves in a way that cannot be manipulated into a valid ciphertext for an earlier epoch without fresh authority randomness, and each epoch transition is bound to a hidden tag that cannot be forged from revoked keys. The same source further states that time-encoded RABE schemes with public re-randomization should ensure that no subset of components can be combined to roll back a ciphertext to a weaker epoch, typically requiring non-malleability or CCA security in the time-update functionality; it also recommends isolating the time-update domain from the attribute-based domain by using a strongly unforgeable update token, for example via self-updatable encryption or hierarchical IBE (Lee, 2018).

5. Efficiency profiles

Reported efficiency characteristics differ substantially across construction families.

PIRATTE emphasizes immediate revocation without reissuing keys to non-revoked users or re-encrypting existing ciphertexts. Its asymptotic costs are $\mathsf{Decrypt}$9 for setup and proxy rekey, $\mathsf{Revoke}$0 for key generation with $\mathsf{Revoke}$1 attributes, $\mathsf{Revoke}$2 for encryption with $\mathsf{Revoke}$3 leaves, and $\mathsf{Revoke}$4 pairings plus $\mathsf{Revoke}$5 exponentiations for decryption. For MNT159, the element sizes are $\mathsf{Revoke}$6, $\mathsf{Revoke}$7, $\mathsf{Revoke}$8, and $\mathsf{Revoke}$9. On a 2.4 GHz Core 2 Duo with $RL$0, all operations fall well under $RL$1, and proxy conversion is typically only a few hundred milliseconds even for $RL$2 (Jahid et al., 2012).

The accumulator-based CP-ABE construction has $RL$3 pairings and $RL$4 exponentiations in setup, $RL$5 work in key generation, $RL$6 exponentiations in encryption, and $RL$7 pairings plus $RL$8 for the witness check in decryption. Its ciphertext size is “2 group-elements per row $RL$9 + 2 for $\mathsf{Update\,CT}$0 + description of $\mathsf{Update\,CT}$1,” while revocation state consists of one public accumulator element and one witness group element per user (Bartolomeo, 2023).

SEA-BREW keeps endpoint encryption and decryption costs identical to Bethencourt–Sahai–Waters CP-ABE, but makes $\mathsf{Update\,CT}$2 and $\mathsf{Update\,CT}$3 constant-time, requiring one exponentiation in $\mathsf{Update\,CT}$4 regardless of $\mathsf{Update\,CT}$5 or $\mathsf{Update\,CT}$6. Its revocation broadcast inside a WSAN is reported as a signed packet of approximately $\mathsf{Update\,CT}$7 bytes, assembled from a $\mathsf{Update\,CT}$8-byte ECDSA signature, a $\mathsf{Update\,CT}$9-byte update term, and a $T$0-byte broadcast-encrypted component. In simulations with $T$1 stored ciphertexts, policies and attribute sets of size $T$2, daily Poisson$T$3 requests, and revocations Poisson$T$4, the cloud’s exponent-count remains flat as policy size grows, because proxy re-encryption cost is constant per ciphertext (Manna et al., 2021).

RFABEO-DI is optimized for IoT and cloud-assisted revocation. The reported implementation uses Python/Charm with MNT224 pairings. Under the same AND-policy of size $T$5, the scheme reduces encryption time by $T$6–$T$7 and revocation time by approximately $T$8 relative to RFAME-DI; decryption uses only $T$9 pairings versus $\mathsf{ExtractKey}$00 in RFAME-DI. The paper also states that key generation, encryption, revocation, and decryption times scale linearly in $\mathsf{ExtractKey}$01 but with markedly smaller constants (Li et al., 25 Sep 2025).

The key-policy RS-ABE construction makes the revocation/time trade-off explicit. For an LSSS of $\mathsf{ExtractKey}$02 rows, the RS-ABE private key is $\mathsf{ExtractKey}$03 group elements, the time-update key is $\mathsf{ExtractKey}$04, and the ciphertext size is $\mathsf{ExtractKey}$05. The tree-based Complete-Subset framework therefore achieves sublinear revocation overhead $\mathsf{ExtractKey}$06 at the cost of logarithmic user-key growth (Giacon et al., 2016).

6. Applications, extensions, and design directions

RABE is used wherever encrypted data must remain policy-protected under membership churn. Cloud storage is the motivating setting of the ciphertext outdate analysis, where users store data in the cloud and access it through the Internet while the cloud server is honest-but-curious and may collude with revoked users or harvest obsolete credentials (Lee, 2018). PIRATTE targets enterprise outsourcing and also describes an online social network architecture, including a prototype application on Facebook, in which each profile post is encrypted under a CP-ABE policy and revoked friends or attributes are prevented from reading new or old posts through a proxy-mediated handshake (Jahid et al., 2012).

In low-bitrate IoT and industrial IoT, SEA-BREW is designed for sensors, actuators, and users that exchange encrypted data via a cloud server or directly through wireless links inside the same WSAN. Its emphasis is immediate revocation with a single short broadcast message, rather than a number of unicasts linear in the number of nodes (Manna et al., 2021). RFABEO-DI addresses IoT cloud storage and outsourced data environments where revocation work is offloaded to the cloud and ciphertext integrity is explicitly checked so that tampering or lazy revocation updates by the cloud server are detectable (Li et al., 25 Sep 2025).

RABE techniques also underpin privacy-preserving credential systems. The accumulator-based construction shows how CP-ABE and revocation can be combined into anonymous proof of predicates with revocation through accumulators, and then wrapped in a mild CCA-secure transformation to restore full anonymity of predicate proofs. In that setting, the verifier learns only whether decryption succeeds, not which particular user key satisfied the policy (Bartolomeo, 2023).

Several design lessons recur across these applications. Public update mechanisms are attractive because they reduce redistribution costs, but they must not leave reusable structure that enables epoch rollback or unauthorized transformation. Proxy- and server-assisted systems reduce endpoint overhead, but they shift assurance requirements toward the correctness and limited trust assumptions of the assisting party. Accumulator-, tree-, and broadcast-based revocation all realize the same high-level goal—excluding revoked users without global re-encryption—but they expose different state, proof, and communication surfaces. A plausible implication is that robust RABE design now depends less on the mere presence of revocation than on how tightly time, policy, and update domains are cryptographically interlocked. The best-practice guidance given in the literature is correspondingly explicit: useful key material or auxiliary tokens must not survive in forms that enable time rollback or forward derivation, and secure designs often rely on self-updatable encryption, strongly unforgeable update tokens, non-malleable commitments to time, and zero-knowledge proofs of correct epoch transition (Lee, 2018).