LOR-A2ABE: Lightweight and Revocable Attribute-Anonymous ABE with Outsourced Decryption in Centralized IoT

Abstract

Due to the rapid proliferation and evolution of the Internet of Things (IoT) in industrial and smart city applications, concerns over sensitive data security have become increasingly prominent. This is especially true in resource-constrained “cloud–terminal” centralized architectures, where ensuring privacy protection for downlink data and implementing fine-grained access control have become critical. Ciphertext-Policy Attribute-Based Encryption (CP-ABE) serves as an effective solution due to its fine-grained access control capability. Nevertheless, conventional CP-ABE approaches face notable limitations when deployed in these practical settings, including the lack of an efficient and lightweight client-side revocation mechanism, excessive decryption overhead on terminal devices, and the practical difficulty in balancing security with performance. To address these issues, this paper proposes LOR-A2ABE, a Lightweight, Outsourced, and Revocable Anonymous Attribute-Based Encryption scheme. The scheme achieves lightweight client-side revocation through partial updates by embedding version numbers and timestamps into keys and ciphertexts via hash mapping. Furthermore, it employs outsourcing to offload the majority of computations to the cloud, allowing client-side decryption with only constant, low-complexity operations, thereby significantly reducing the computational burden on resource-constrained terminals. Considering the practical context where client devices are typically resource-limited sensors or microcontrollers and downlink data often require real-time processing, our scheme adopts a practical security model optimized for IoT constraints. This model prioritizes forward security and efficient revocation—the most critical requirements for operational IoT systems—while maintaining provable security under the Decisional Linear (DLIN) assumption within a bounded collusion model, achieving IND-CPA security and anonymity. Theoretical analysis and experimental simulations show that LOR-A2ABE incurs acceptable and controllable overhead in the key issuance and encryption phases, while outperforming most existing schemes in decryption and revocation efficiency, making it particularly suitable for “cloud–terminal” centralized IoT environments where terminal devices are resource-constrained and require frequent decryption operations.

1. Introduction

The Internet of Things (IoT), built upon robust networks of real-time sensors and microcontrollers, is widely applied in domains such as smart cities [1,2] and the Industrial IoT [3,4]. Currently, key constraints on IoT development include the limited computational resources of terminal devices [3,5,6] and the security and privacy concerns associated with the massive amounts of sensitive data generated by IoT devices [7,8]. The issue of constrained computational resources is often addressed or mitigated by integrating with cloud computing [9,10,11], while the security and privacy of sensitive data are tackled through cryptographic techniques [12,13,14,15,16].

Moreover, compared to distributed networks, centralized networks offer advantages such as lower initial deployment and maintenance costs, more straightforward and unified overall management, configuration, and policy implementation [17], greater convenience in data aggregation and large-scale analysis [18] and enhanced performance in resource scheduling and load balancing [19]. These advantages are especially decisive in IoT applications where security, real-time response, and consistent policy enforcement are paramount.

These practical advantages of centralized architectures become particularly critical in security-sensitive IoT applications demanding real-time, fine-grained access control. Consider a smart factory predictive maintenance system: vibration and temperature data from hundreds of machines are streamed to a central analytics platform. The access policy must be dynamic, granting engineers from specific maintenance teams access only to data from their assigned production lines and only during their scheduled shifts. In such a scenario, a distributed access control system would face inherent challenges: (1) Policy Synchronization Latency: Propagating and reaching consensus on immediate attribute revocation (e.g., when an engineer’s shift ends) across all devices would introduce unacceptable delay, creating security windows. (2) Communication Overhead: Frequent, fine-grained policy updates would generate massive coordination traffic among resource-constrained sensors, contradicting the goal of energy efficiency. In contrast, a centralized authority, as assumed in our work, can enforce such complex, dynamic policies instantly and consistently, making it the natural architectural fit for these “cloud–terminal” IoT environments where data aggregation and real-time control are paramount.

This example underscores the critical need for fine-grained access control within the “cloud–terminal” centralized IoT paradigm. Ensuring that downlink commands or data are accessible only to authorized users or devices is critical, making fine-grained access control a core security requirement [20,21,22]. Attribute-Based Encryption (ABE) can be classified into Ciphertext-Policy ABE (CP-ABE) and Key-Policy ABE (KP-ABE), distinguished by CP-ABE binding the access policy to the ciphertext, whereas KP-ABE binds it to the key [23]. Comparatively, CP-ABE is evidently more suitable for the “cloud–terminal” centralized IoT environment characterized by a vast user scale, massive shared data, and dynamically changing attributes [24].

However, CP-ABE relies on bilinear pairing computations, and its attribute matching efficiency decreases as the number of users and the complexity of the access policy increase [23,25,26]. Classical CP-ABE frameworks do not adequately address the efficiency challenges of large-scale matching, such as the BSW framework [23], CGW framework [27], ABGW framework [28], and FAME framework [29]. In 2022, Riepel et al. proposed the FABEO framework [30], which utilizes cluster operations to concentrate substantial computations into the smallest group, achieving the fastest performance among classical CP-ABE frameworks. Subsequently, the FABESA scheme [31], based on the FABEO framework, introduced an adaptive chosen-plaintext attack (CPA) secure scheme with anonymity. In the “cloud–terminal” centralized IoT environment, attribute name hiding can better mitigate the privacy and security risks introduced by “centralization”. However, FABESA is not specifically designed for IoT environments and thus cannot be well-adapted to the “cloud–terminal” centralized IoT setting.

Simultaneously, considering the resource-constrained nature of IoT environments, cloud computing outsourcing has emerged as a solution to alleviate the computational overhead of bilinear pairings in CP-ABE [32,33,34,35]. However, the scheme proposed in [32] has a weaker security model, offering only static security. The scheme in [33] achieves stronger CCA security but imposes a significant computational burden on the server and lacks in-depth investigation into dynamic attribute management in IoT contexts. The FOC-PH-CP-ABE scheme [34] significantly enhances privacy protection through policy hiding and a fully outsourced mechanism, but this security improvement comes at the cost of partially reduced encryption/decryption efficiency, resulting in overall performance inferior to schemes like [30] that prioritize computational speed.

These schemes do not sufficiently address dynamic attribute management, particularly attribute revocation. Yet, in “cloud–terminal” centralized IoT environments, large-scale dynamic management of terminal attributes is inevitable. Some schemes have proposed attribute revocation methods, such as the MTA scheme [36] and the TRH scheme [37], but their revocation efficiency is limited, thus are not suitable for achieving lightweight revocation in IoT environments.

However, these existing methods are not well-suited for the “cloud–terminal” centralized IoT environment:

• Resource Constraints and Environmental Adaptability Issues: Schemes such as FABESA [31] achieve strong theoretical security but are not optimized for the resource-constrained nature of IoT environments. Moreover, they lack efficient attribute revocation mechanisms essential for dynamic IoT deployments.
• Insufficient Revocation Efficiency: Although revocation schemes like MTA [36] and TRH [37] exist, they introduce complexities of $O\left(\right|A\left|\right)$ or $O(log|U\left|\right)$ that scale with system size. For large-scale IoT deployments with frequent attribute updates, such overhead becomes prohibitively high and contradicts the lightweight requirements of IoT terminals.
• Imbalanced Computation Distribution: Some IoT-oriented schemes, such as FOC-PH-CP-ABE [34], achieve computational outsourcing at the cost of significantly increased encryption time or server burden. This creates new bottlenecks in the “cloud–terminal” processing pipeline and shifts rather than resolves the computational challenges.

In summary, the current landscape lacks a CP-ABE scheme that simultaneously provides all of the following characteristics: (1) an $O\left(1\right)$ lightweight revocation mechanism suitable for dynamic IoT management; (2) truly efficient outsourced decryption with constant-time client-side operations; (3) attribute anonymity for enhanced privacy in centralized architectures; and (4) practical security trade-offs that align with IoT operational realities, such as prioritizing forward security and accepting limited backward secrecy based on data timeliness.

To address these limitations, this paper proposes a novel attribute-based encryption scheme specifically designed for centralized IoT environments. Our main contributions are as follows:

• The proposed LOR-A2ABE scheme achieves lightweight attribute revocation by partially updating keys and ciphertexts, providing an efficient attribute revocation management solution for large-scale IoT environments.
• A prominent advantage of our scheme lies in its highly efficient and practical decryption performance on the user side. We employ outsourcing techniques to offload the majority of computations to the cloud, requiring IoT terminal devices to perform only constant, low-complexity operations for decryption, thereby significantly alleviating the computational burden on end-users.
• In terms of security, our scheme incorporates a deliberate trade-off in its security design. We forgo backward security and operate under a limited collusion resistance assumption. Concurrently, we formally prove that the scheme achieves forward security, IND-CPA security, and anonymity security under the DLIN assumption.

A comprehensive performance evaluation combining theoretical analysis and experimental simulations demonstrates that: by accepting controllable overhead in key issuance and encryption, our scheme achieves lightweight attribute revocation while ensuring its decryption performance is significantly superior to that of most mainstream schemes. This highlights its exceptional practical value, making it particularly suitable for scenarios in “cloud–terminal” IoT where a massive number of resource-constrained terminal devices frequently perform decryption operations.

The structure of this paper is outlined as follows. In Section 2, we introduce essential cryptographic background information and formally establish the security model. Section 3 elaborates on the construction of our LOR-A2ABE scheme. Section 4 furnishes a formal security proof of the proposed scheme. A performance evaluation is conducted in Section 5, encompassing theoretical analysis and experimental comparisons with prior works. Lastly, Section 6 summarizes the paper and suggests avenues for future investigation.

2. Preliminaries

2.1. Bilinear Pairings

Suppose $\lambda$ denotes the security parameter and p is a large prime whose bit-length equals $\lambda$, which ensures the system withstands attacks of computational cost $O\left(2^{\lambda }\right)$, thereby delivering $\lambda$-bit security. Consider $G_1$, $G_2$ as additive cyclic groups of prime order p, and $G_T$ as a multiplicative cyclic group also of order p. Assume $g_1\in G_1$ and $g_2\in G_2$ are generators of their respective groups. A bilinear map $e:G_1\times G_2\to G_T$ is called a Type 3 (asymmetric) pairing if it is non-degenerate, no efficient homomorphism exists between $G_1$ and $G_2$, and it satisfies the following properties:

• Bilinearity: For any $a,b\in {\mathbb{Z}}_p$, $e(g_1^a,g_2^b)=e{(g_1,g_2)}^{ab}$.
• Non-degeneracy: $e(g_1,g_2)$ is a generator of $G_T$. For all $a,b\in {\mathbb{Z}}_p$, $e(g_1^a,g_2^b)=1_{G_T}$ if and only if $a=0$ or $b=0$.
• Computability: There exists an efficient algorithm such that $e:G_1\times G_2\to G_T$ is computable in deterministic polynomial time with respect to the security parameter $\lambda$.

2.2. Monotone Span Programs

A monotone span program (MSP) is defined by the quadruple $(\mathbb{F},M,\rho ,\mathbf{v})$, where:

• $\mathbb{F}={\mathbb{Z}}_p$ is a finite base field of prime order p.
• $M\in {\mathbb{Z}}_p^{m\times n}$ is an $m\times n$ matrix over $\mathbb{F}$.
• $\rho :\{1,2,\dots ,m\}\to U$ is a labeling function that maps each row of M to an attribute in the universal attribute set U. Multiple rows may be mapped to the same attribute.
• $\mathbf{v}=(1,0,0,\dots ,0)\in {\mathbb{Z}}_p^{1\times n}$ is the target vector.

For any attribute set $S\subseteq U$, define the row index set $I_S=\{i\in \{1,\dots ,m\}\mid \rho \left(i\right)\in S\}$. The set S is considered authorized (i.e., satisfying the access policy) if and only if the target vector $\mathbf{v}$ lies in the row space spanned by ${\left\{M_i\right\}}_{i\in I_S}$.

Formally, there must exist scalars ${\{w_i\in \mathbb{F}\}}_{i\in I_S}$ such that:

$$\sum _{i\in I_S}{w}_i·M_i=\mathbf{v}$$

2.3. Partially Hidden Structure (Anonymity)

To mitigate privacy inference threats in centralized IoT management systems using a “cloud–terminal” model, it is beneficial to conceal sensitive attribute values while revealing only non-sensitive attribute names. This approach not only enhances decryption efficiency but also prevents leakage of sensitive information. The concept of “partially hidden structure” was introduced by Lai et al. [38] to address this challenge.

Let $S={\left\{u_i\right\}}_{i\in \left[m\right]}$ be an attribute set, where each $u_i=(n_i,v_i)$ includes an attribute name $n_i$ and its corresponding value $v_i$. An access policy A can be expressed as $A=(M,\pi ,{\left\{\pi \left(i\right)\right\}}_{i\in \left[l\right]})$, where M is an $l\times n$ matrix and the mapping function $\pi$ maps the i-th row of M to an attribute $\pi \left(i\right)=(n_{\pi \left(i\right)},v_{\pi \left(i\right)})$. The attribute set S satisfies the access policy A if and only if there exists a collection of constants ${\left\{{\gamma }_i\right\}}_{i\in I}$ satisfying

$$\sum _{i\in I}{\gamma }_i{M}_i=(1, 0, \dots , 0),$$

and $\pi \left(i\right)=u_i$ holds for all $i\in I$.

It is important to delineate the privacy guarantee of this “partially hidden” approach. The scheme protects the confidentiality of specific attribute values (e.g., whether “Age” = 25 or 40) but does not hide the attribute names themselves (e.g., “Age”, “Department”, “Medical_Condition”). In scenarios where attribute names carry sensitive metadata (e.g., an access policy involving “Has_Heart_Disease” directly reveals the medical context of the data), this constitutes a semantic leakage. Our security model, following the standard notion of attribute anonymity [38], ensures that given a ciphertext, an adversary cannot determine which among a set of possible value assignments was used, assuming the attribute names are known or non-critical.

Therefore, the applicability of our anonymity feature depends on the deployment context. In many IoT scenarios (e.g., access control based on “Sensor_Type”, “Location”, or “Temperature_Range”), attribute names are non-sensitive, making value-hiding both sufficient and efficient. For environments where even attribute names are confidential, fully policy-hiding techniques would be required, which typically incur significantly higher computational and communication overhead, conflicting with the lightweight objectives of this work.

2.4. Decisional Linear (DLIN) Assumption

Let $\mathsf{par}=\left(p,G_1,G_2,G_T,g_1,g_2,e:G_1\times G_2\to G_T\right)$ be the description of a standard asymmetric (Type 3) bilinear-map setting with security parameter $1^{\lambda }$.

Pick random $x_1,x_2,y_1,y_2\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$ and a random $R\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$. The public information is given by

$$D=\left(g_1^{x_1},g_1^{x_2},g_2^{y_1},g_2^{y_2},g_1^{x_1{y}_1},g_1^{x_2{y}_1},g_2^{x_1{y}_1},g_2^{x_2{y}_1}\right).$$

An adversary $\mathcal{A}$ is challenged to distinguish between the two tuples:

$$T_0=\left(g_1^{y_2+y_1},g_2^{y_2+y_1}\right),T_1=\left(g_1^R,g_2^R\right).$$

The advantage of $\mathcal{A}$ in solving the DLIN problem within polynomial time is defined as

$${\mathbf{Adv}}_{\mathcal{A}}^{\mathrm{DLIN}}\left(\lambda \right)=\left|Pr[\mathcal{A}(\mathsf{par},D,T_0)=1]-Pr[\mathcal{A}(\mathsf{par},D,T_1)=1]\right|.$$

We say that the DLIN assumption holds under the group parameters $\mathsf{par}$ if the advantage ${\mathbf{Adv}}_{\mathcal{A}}^{\mathrm{DLIN}}\left(\lambda \right)$ is negligible for any probabilistic polynomial-time (PPT) adversary $\mathcal{A}$.

3. LOR-A2ABE

3.1. System Model

The architecture of the LOR-A2ABE scheme is illustrated in Figure 1. It consists of the following entities: the Central Authority (CA), the IoT Device User (DU), the Cloud Server (CS), and the data acquisition system (Sensor). The scheme mainly involves five processes as described below.

• System Initialization: The CA based on the security parameter $\lambda$, and runs the system initialization algorithm to produce the master key pair.
• Key Generation: The DU submits a registration request to the CA, and the CA generates attribute keys for the DU according to its attribute set.
• Data Encryption: The CA encrypts the data $Msg$ submitted by the Sensor under a access control structure, and uploads the resulting to the CS for storage, enabling the DU to apply for download on demand.
• Data Decryption: The DU applies to the CS for ciphertext download and submits part of its own attribute keys. Based on the request, the CS performs partial decryption on the ciphertext, generates a transformation key, and returns it to the DU. The DU then uses the transformation key to complete the final decryption and obtains the data $Msg$.
• Revocation: The CA periodically generates key update information and updates the ciphertext stored in the CS. The key update information is sent to non-revoked DUs, who then update their own keys locally upon receipt.

In LOR-A2ABE, encryption and other complex operations are handled by the resource-sufficient CA, not by constrained terminals (DU). Terminal devices only perform lightweight decryption and key updates with constant complexity, ensuring the scheme’s “lightweight” characteristic genuinely benefits the resource-constrained endpoint.

3.2. Detailed Construction

This section provides a detailed description of the proposed LOR-A2ABE scheme.

• System Initialization. The CA performs system initialization according to the security parameter $\lambda$ and generates the system master key pair via $\mathsf{Setup}\left(1^{\lambda }\right)\to (msk,mpk)$.
  The CA randomly selects $\alpha ,b_1,b_2\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$. Then, the master secret key and the master public key are defined as

  $$\begin{array}{cc}\hfill msk& =(\alpha ,\beta ,b_1,b_2),\hfill \end{array}$$

  (1)

  $$\begin{array}{cc}\hfill mpk& =\left(\mathsf{par},g_1^{b_1},g_1^{b_2},g_2^{\beta },H,e{(g_1,g_2)}^{\alpha }\right).\hfill \end{array}$$

  (2)
• Key Generation. Upon receiving a registration request from a DU, the CA generates attribute keys according to the DU’s attribute set $S\subseteq \mathbb{U}$ by running $\mathsf{KeyGen}(mpk,msk,S)\to sk$.
  Randomly choose $r\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$, a version number $Ver\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$, and a timestamp $nonce$. Compute:

  $$\begin{array}{cc}\hfill s{k}_1& =g_1^r,\hfill \end{array}$$

  (3)

  $$\begin{array}{cc}\hfill s{k}_2& =g_1^{\alpha }·g_1^{\beta r},\hfill \end{array}$$

  (4)

  $$\begin{array}{cc}\hfill s{k}_{3,u}& =g_1^{H(0\parallel u_i)r/b_1}·g_1^{r/b_1}=g_1^{(H(0\parallel u_i)+1)r/b_1},\hfill \end{array}$$

  (5)

  $$\begin{array}{cc}\hfill s{k}_{4,u}& =g_1^{H(1\parallel u_i)r/b_2}·g_1^{r/b_2},\hfill \end{array}$$

  (6)

  $$\begin{array}{cc}\hfill s{k}_5& =e{(g_1^{\alpha },g_2)}^{H(nonce\parallel Ver)}.\hfill \end{array}$$

  (7)
  For each attribute $u\in S$, the full secret key is

  $$\begin{array}{c}\hfill sk=\left(s{k}_1,s{k}_2,{\{s{k}_{3,u},s{k}_{4,u}\}}_{u\in S},s{k}_5\right).\end{array}$$

  (8)
• Encryption. The CA encrypts the received message $Msg$ under an access structure $(M,\pi )$ and uploads the resulting ciphertext to the CS via $\mathsf{CAEncryption}\left(\mathsf{Enc}\left(Msg\right),mpk,(M,\pi )\right)\to ct$.
  Choose random $s_1,s_2\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$ and set $s=s_1+s_2$. Additionally, choose a random vector $\mathbf{v}={(s,v_2,\dots ,v_n)}^{\top }\in {\mathbb{Z}}_p^n$ where $v_2,\dots ,v_n\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$. For each row i of the matrix M, compute the share ${\lambda }_i=M_i·\mathbf{v}$. Then compute:

  $$\begin{array}{cc}\hfill c{t}_0& =Msg·e{(g_1^{\alpha },g_2)}^s,\hfill \end{array}$$

  (9)

  $$\begin{array}{cc}\hfill c{t}_{1,i}& =g_2^{M_i{(s\parallel v)}^{\top }+s+s_{1}H(0\parallel \pi \left(i\right))+s_{2}H(1\parallel \pi \left(i\right))},\hfill \end{array}$$

  (10)

  $$\begin{array}{cc}\hfill c{t}_2& =g_2^{s+H(nonce\parallel Ver)},\hfill \end{array}$$

  (11)

  $$\begin{array}{cc}\hfill c{t}_3& =g_2^{b_1{s}_1},\hfill \end{array}$$

  (12)

  $$\begin{array}{cc}\hfill c{t}_4& =g_2^{b_2{s}_2},\hfill \end{array}$$

  (13)

  $$\begin{array}{cc}\hfill c{t}_5& =g_2^{\beta (s+H(nonce\parallel Ver\left)\right)}·g_2^s.\hfill \end{array}$$

  (14)

  Here, $M_i{(s\parallel v)}^{\top }$ equals the share ${\lambda }_i$ computed for row i of the monotone span program M. The terms s, $s_{1}H(0\parallel \pi \left(i\right))$, and $s_{2}H(1\parallel \pi \left(i\right))$ serve as attribute-specific blinding factors essential for security and anonymity. The complete ciphertext is

  $$\begin{array}{c}\hfill ct=\left(c{t}_0,{\left\{c{t}_{1,i}\right\}}_{i\in \left[n_1\right]},c{t}_2,c{t}_3,c{t}_4,c{t}_5\right).\end{array}$$

  (15)
• Outsourced Decryption (CS-Side). After receiving a decryption request from a DU, the CS performs partial decryption on the ciphertext and obtains a transformation key by executing $\mathsf{CSDecrypt}(S,ct,sk)\to TK$.
  If the terminal’s attribute set S is an authorized set under the access structure $(M,\pi )$, there exists a set of constants ${\left\{{\gamma }_i\right\}}_{i\in I}$ such that ${\sum }_{i\in I}{\gamma }_i{M}_i=(1,0,\dots ,0)$. The CS then computes the transformation key as:

  $$\begin{array}{cc}\hfill TK& ={\displaystyle \frac{e(s{k}_2,c{t}_2)·e\left({\prod }_{i\in I}{\left(c{t}_{1,\pi \left(i\right)}\right)}^{{\gamma }_i},s{k}_1\right)}{e(s{k}_1,c{t}_5)·e\left({\prod }_{i\in I}{\left(s{k}_{3,i}\right)}^{{\gamma }_i},c{t}_3\right)·e\left({\prod }_{i\in I}{\left(s{k}_{4,i}\right)}^{{\gamma }_i},c{t}_4\right)}}.\hfill \end{array}$$

  (16)
• Final Decryption (DU-Side). After obtaining the transformation key returned by the CS, the DU can complete the final decryption and recover the original message via $\mathsf{IoTDecrypt}(TK,s{k}_5)\to Msg$.
  The DU first recovers the session key:

  $$\begin{array}{c}\hfill key=TK/s{k}_5.\end{array}$$

  (17)

  The original message is then obtained as:

  $$\begin{array}{c}\hfill Msg=c{t}_0/key.\end{array}$$

  (18)
• Lightweight Attribute Revocation. The CA periodically generates key update information and refreshes the stored ciphertext by running $\mathsf{Revoked}(sk,ct)\to (s{k}^{\prime },c{t}^{\prime })$.
  The CA randomly selects a new version number $Ve{r}^{\prime }\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$ and updates the timestamp to $nonc{e}^{\prime }$. It then computes:

  $$\begin{array}{cc}\hfill update& =H(nonc{e}^{\prime }\parallel Ve{r}^{\prime }),\hfill \end{array}$$

  (19)

  $$\begin{array}{cc}\hfill key\_update& =e{(g_1,g_2)}^{\alpha ·update}.\hfill \end{array}$$

  (20)

  The $key\_update$ is sent to all non-revoked DUs. Upon receiving it, each DU locally updates its secret-key component:

  $$\begin{array}{c}\hfill s{k}_5^{\prime }=s{k}_5·key\_update.\end{array}$$

  (21)
  In LOR-A2ABE, the revocation mechanism is designed with built-in constraints to counter practical collusion attacks. First, the $key\_update$ value is intrinsically linked to the specific $(nonc{e}^{\prime },Ve{r}^{\prime })$ pair generated in each update round. Devices that have been revoked are excluded from subsequent update distributions and thus cannot obtain the necessary $nonc{e}^{\prime }$ and $Ve{r}^{\prime }$ values. Without these parameters, even if the $key\_update$ value itself is leaked, it is impossible to construct the correct versioned hash chain required for successful decryption. Second, any intercepted $key\_update$ value has a limited validity window, typically restricted to the period before the next update. This design significantly limits the practical feasibility of collusion attacks that rely on sharing such critical update information.
  Concurrently, the CA updates the ciphertext. It chooses a fresh random $s^{\prime }\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$ and computes:

  $$\begin{array}{cc}\hfill c{t}_{2\_new}& =g_2^{s^{\prime }+update},\hfill \end{array}$$

  (22)

  $$\begin{array}{cc}\hfill c{t}_{5\_new}& =g_2^{\beta (s^{\prime }+update)}.\hfill \end{array}$$

  (23)

  The updated ciphertext components are:

  $$\begin{array}{cc}\hfill c{t}_0^{\prime }& =c{t}_0·e{(g_1,g_2)}^{\alpha s^{\prime }},\hfill \end{array}$$

  (24)

  $$\begin{array}{cc}\hfill c{t}_2^{\prime }& =c{t}_2·c{t}_{2\_new},\hfill \end{array}$$

  (25)

  $$\begin{array}{cc}\hfill c{t}_5^{\prime }& =c{t}_5·c{t}_{5\_new},\hfill \end{array}$$

  (26)

  $$\begin{array}{cc}\hfill c{t}^{\prime }& =\left(c{t}_0^{\prime },{\left\{c{t}_{1,i}\right\}}_{i\in \left[n_1\right]},c{t}_2^{\prime },c{t}_3,c{t}_4,c{t}_5^{\prime }\right).\hfill \end{array}$$

  (27)

4. Security Proofs

4.1. Design Trade-Offs for Security

This scheme is specifically designed for the resource-constrained “cloud–terminal” centralized IoT Management Environments and incorporates explicit design trade-offs in security. We prioritize forward secrecy, which is critical to the overall system security, while achieving a lightweight user revocation mechanism. Given that data in such environments usually possesses strong timeliness and the set of devices remains relatively stable, backward secrecy is considered non-essential in this scenario. Furthermore, to address potential collusion risks that may arise in practical deployment, the scheme assumes a limited collusion resistance: by strictly confining key update operations to local execution on legitimate terminal devices, this prevents adversaries from acquiring or updating attribute keys belonging to other devices.

This design choice allows the scheme to effectively guard against common attacks and a certain range of internal collusion threats, while significantly reducing both computational and communication overhead.

4.1.1. Trade-Offs of Limited Collusion Resistance

The practical effectiveness of LOR-A2ABE in IoT deployments is enhanced by considering the operational constraints of real-world environments. In standard cryptographic theory, it is typically assumed that adversaries possess unlimited collusion capabilities. However, in the “cloud–terminal” centralized IoT environment, terminal devices are usually resource-constrained sensors or microcontrollers with severely limited computational power, storage capacity, and communication bandwidth.

Considering this practical context, we identify the following operational characteristics that enhance the scheme’s practical effectiveness in IoT deployments: In the “cloud–terminal” centralized IoT architecture, it is operationally difficult for an adversary to organize terminal devices into an effective, real-time collusion network for key information exchange:

• Terminal devices typically perform predefined single functions and lack the computational and communication capabilities required to dynamically coordinate and execute complex collusion protocols.
• The $key\_update$ information is strongly bound to system version numbers and timestamps, possessing a strong timeliness attribute. Revoked devices struggle to obtain the version hash chain corresponding to the ciphertext. Missing any version hash value will prevent normal decryption.
• In practical deployments, terminal devices are often physically or logically isolated, making it difficult to establish direct and covert channels for key information exchange.
• In the target IoT scenarios, protected downlink data (e.g., control commands, configuration updates) usually have strong timeliness requirements. A successful collusion attack not only requires obtaining all historical $key\_update$ values but must also be completed within the data’s validity period and before the next system update, which further increases the practical difficulty of the attack.

Under these operational conditions, even if an adversary controls some terminal devices, real-time exchange of key_update information remains challenging. This practical analysis explains why LOR-A2ABE is well-suited for IoT deployments, while its formal security is guaranteed by the cryptographic proofs in Section 4.4 and Section 4.5.

4.1.2. Trade-Offs of Backward Secrecy

The design of LOR-A2ABE intentionally prioritizes forward secrecy and system efficiency over backward secrecy—a deliberate decision grounded in the practical constraints of IoT operational environments. This trade-off is justified by the following key considerations:

Time-Sensitive Nature of Data Value. In IoT environments, downstream data—such as control commands, sensor readings, and configuration updates—typically exhibits strong timeliness. Once data exceeds its effective operational period, its security significance diminishes considerably. Consequently, ensuring the security of future data (forward secrecy) is paramount for system operation, while the necessity of protecting historical data (backward secrecy) decreases as data gradually loses operational relevance.

Imperative for System Efficiency. Achieving cryptographically strong backward secrecy would impose substantial system overhead. Conventional approaches either require re-encryption of all historical ciphertexts during revocation (resulting in $O\left(n\right)$ communication costs) or necessitate complex key evolution mechanisms that increase storage and computational burdens on resource-constrained devices. Both methods would compromise the $O\left(1\right)$ revocation efficiency essential for scalable IoT deployments with frequent attribute updates.

Controlled Risk Exposure. In target applications such as sensor data streaming, environmental monitoring, and real-time control commands, data value decays rapidly over time. The practical risk associated with revoked devices accessing historical data is acceptably low, making the performance gains from efficient revocation mechanisms a worthwhile trade-off against comprehensive backward secrecy.

Coherence with Limited Collusion Resistance. It is important to note that this limitation in backward secrecy does not contradict the limited collusion resistance mechanism described in Section 4.1.1. While limited collusion resistance enhances protection during data’s operational period by increasing the difficulty of real-time collusion, the acceptance of limited backward secrecy reflects the diminished need for protection after data exceeds its useful lifespan. Together, these design choices implement a time-proportional security model that provides strong protection when data matters most while maintaining efficient system operation.

Based on these considerations, LOR-A2ABE intentionally omits cryptographic backward secrecy—a clear design choice that enables the lightweight, efficient revocation essential for practical IoT deployments. This is not a compromise but a targeted optimization: we deliberately exchange comprehensive backward security for the performance characteristics required by resource-constrained, time-sensitive IoT environments.

4.2. Security Model

4.2.1. IND-CPA Security

The IND-CPA security is defined via a security game ${\mathsf{Game}}_{\mathsf{CP}-\mathsf{ABE}}^{\mathsf{IND}-\mathsf{CPA}}(\mathcal{A},\lambda )$ between a challenger $\mathcal{C}$ and an adversary $\mathcal{A}$.

Phase 1: Initialization. The challenger $\mathcal{C}$ executes the $\mathsf{Setup}\left(\lambda \right)$ algorithm, which outputs the master public key $mpk$ and the master secret key $msk$. Subsequently, $\mathcal{C}$ provides $mpk$ to the adversary $\mathcal{A}$ while keeping $msk$ confidential.

Phase 2: Query Phase 1. The adversary $\mathcal{A}$ is permitted to adaptively submit a polynomially bounded number of queries of the following types to $\mathcal{C}$:

• Random oracle query $H(·)$: $\mathcal{C}$ maintains a query list and responds to each distinct query with a randomly generated value.
• Key-generation oracle $O_{\mathsf{KeyGen}}\left(S\right)$: $\mathcal{A}$ submits an attribute set S. $\mathcal{C}$ runs $\mathsf{KeyGen}$ to generate a secret key $s{k}_S$, records $s{k}_S$ in a user list $\mathsf{UL}$, and returns $s{k}_S$ to $\mathcal{A}$.
• Revocation oracle $O_{\mathsf{revok}}\left(uid\right)$: $\mathcal{A}$ submits a user $uid$ to be revoked, provided that $uid\in \mathsf{UL}$ and $uid\notin \mathsf{RL}$ (the revocation list). $\mathcal{C}$ generates a new version number $Ve{r}^{\prime }\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$ and a timestamp $nonc{e}^{\prime }\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$, runs the $\mathsf{revoked}$ algorithm to update the ciphertext to $c{t}_{\mathsf{update}}$ and to produce a key-update message $key\_update$, sends the updated ciphertext and the key-update message to $\mathcal{A}$, and records $uid$ together with $key\_update$ in the revocation list.
• Key-update oracle $O_{\mathsf{KeyUpdate}}(uid,key\_update)$: $\mathcal{A}$ submits a user $uid$ and a key-update message $key\_update$, provided that $uid\in \mathsf{UL}$ and $uid\notin \mathsf{RL}$. $\mathcal{C}$ updates the user’s secret key using $key\_update$ and returns the updated key $s{k}_{\mathsf{update}}$ to $\mathcal{A}$.
  Remark 1.

  This step mimics the real-world scenario where each terminal or sensor can only update its own key. Because terminals are not actual users and their resources are extremely constrained, we consider a “limited-collusion” setting, i.e., the adversary $\mathcal{A}$ is not allowed to use $update$ to refresh other users’ keys.
• Outsourced-decryption oracle $O_{\mathsf{Transform}}(ct,uid)$: $\mathcal{A}$ submits a ciphertext $ct$ and a user $uid$. $\mathcal{C}$ runs $\mathsf{CSDecrypt}$ to compute the transformation key $TK$ for $ct$ and returns $TK$ to $\mathcal{A}$.

Phase 3: Challenge. $\mathcal{A}$ chooses two messages $m_0$ and $m_1$ of identical length, together with a target access structure $(M,\pi )$, subject to the condition that none of the attribute sets requested in Phase 2 can satisfy $(M,\pi )$. $\mathcal{C}$ then picks a random bit $b\in 0,1$, invokes $\mathsf{CAEncryption}$ with the current version and timestamp to encrypt $m_b$ under $(M,\pi )$, and delivers the resulting challenge ciphertext $c{t}^{*}$ to $\mathcal{A}$.

Phase 4: Query Phase 2. $\mathcal{A}$ may again issue a polynomial number of queries as in Phase 2, subject to the following restrictions:

• In any $O_{\mathsf{KeyGen}}\left(S\right)$ query, S must not satisfy $(M^{*},{\pi }^{*})$.
• In any $O_{\mathsf{revok}}\left(uid\right)$ query, if the user $uid$ possesses an attribute set that satisfies $(M^{*},{\pi }^{*})$ and has already obtained the corresponding key in Phase 2, then $uid$ cannot be revoked in this phase.
• In any $O_{\mathsf{KeyUpdate}}(uid,update)$ query, if $uid$ has been revoked, the update information $update$ cannot be used to refresh its key.
• The $O_{\mathsf{Transform}}(·)$ oracle cannot be queried on the challenge ciphertext $c{t}^{*}$.

Phase 5: Guess. $\mathcal{A}$ outputs a guess $b^{\prime }$.

The advantage of $\mathcal{A}$ in this game is defined as

$${\mathbf{Adv}}_{\mathcal{A}}^{\mathsf{IND}-\mathsf{CPA}}\left(\lambda \right)=\left|Pr[b^{\prime }=b]-{\displaystyle \frac{1}{2}}\right|.$$

The scheme is said to be IND-CPA secure if this advantage is negligible.

4.2.2. Anonymity Security

The anonymity security is defined via a security game ${\mathsf{Game}}_{{\mathsf{A}}^{\mathsf{2}}\mathsf{ABE}}^{\mathsf{anonymity}}(\mathcal{A},\lambda )$ between $\mathcal{C}$ and $\mathcal{A}$.

Phase 1 and 2: Identical to those in the IND-CPA security model.

Phase 3: Challenge. $\mathcal{A}$ provides two access policies $(M,\pi 0)$ and $(M,\pi 1)$ that have identical attribute–name matrices but distinct value assignments, along with two messages $m_0$ and $m_1$ of equal length. $\mathcal{C}$ selects a random bit $b\in 0,1$, invokes $\mathsf{CAEncryption}$ to encrypt $m_b$ under policy $(M,\pi b)$, and returns the ciphertext $ct$ to $\mathcal{A}$. The policy mapping satisfies $\pi b\left(i\right)=(n_i,v_{b,i})$.

Phase 4: Query Phase 2. Phase 3 proceeds analogously to Phase 2, with the additional restriction that no attribute set S submitted for queries may satisfy the target policy $(M,\pi b)$, and $\mathcal{A}$ is prohibited from requesting any attribute set that fulfills the challenge structure $(M,\pi b)$.

Phase 5: Guess. $\mathcal{A}$ outputs a guess $b^{\prime }$.

The advantage of $\mathcal{A}$ in the anonymity game is defined as

$${\mathbf{Adv}}_{\mathcal{A}}^{\mathsf{anonymity}}\left(\lambda \right)=\left|Pr[b^{\prime }=b]-{\displaystyle \frac{1}{2}}\right|.$$

The scheme is said to be attribute-anonymous if this advantage is negligible.

4.3. Practical Considerations for IoT Deployment

This section analyzes the practical operational implications of LOR-A2ABE’s revocation mechanism, complementing the formal security proofs. The following technical discussion explains why the scheme remains effective in real IoT deployments under resource constraints.

The core of the LOR-A2ABE revocation mechanism is the version-timestamp chain. For a device created and issued a key at epoch 1, its secret key component evolves at epoch t as follows:

$$s{k}_5^{\left(t\right)}=e{(g_1,g_2)}^{\alpha ·{\sum }_{k=1}^{t}H\left(nonc{e}^{\left(k\right)}\parallel Ve{r}^{\left(k\right)}\right)}.$$

(28)

Similarly, a ciphertext created at epoch 1 evolves at epoch t into the following component:

$$c{t}_2^{\left(t\right)}=g_2^{s^{\left(t\right)}+{\sum }_{k=1}^{t}H\left(nonc{e}^{\left(k\right)}\parallel Ve{r}^{\left(k\right)}\right)}.$$

(29)

Decryption requires the version-timestamp terms in $c{t}_2^{\left(t\right)}$ and $s{k}_5^{\left(t\right)}$ to cancel each other out. Therefore, for a device revoked at epoch r to decrypt a ciphertext from a later epoch $t>r$, it must possess the complete and consistent chain of incremental values:

$${\mathcal{CHAIN}}_{r+1\to t}={\left\{e{(g_1,g_2)}^{\alpha ·H\left(nonc{e}^{\left(k\right)}\parallel Ve{r}^{\left(k\right)}\right)}\right\}}_{k=r+1}^t,$$

(30)

and its updated secret key must satisfy:

$$s{k}_5^{\left(t\right)}=s{k}_5^{\left(r\right)}·\prod _{k=r+1}^{t}e{(g_1,g_2)}^{\alpha ·H\left(nonc{e}^{\left(k\right)}\parallel Ve{r}^{\left(k\right)}\right)}.$$

(31)

If any term in this product is missing during the update to $s{k}_5^{\left(t\right)}$, the version-timestamp components in $s{k}_5^{\left(t\right)}$ and $c{t}_2^{\left(t\right)}$ will not align, thereby preventing successful decryption.

Consequently, achieving limited collusion resistance in LOR-A2ABE imposes the following requirements on an adversary:

• Complete Version-Timestamp Chain Requirement: A revoked device must obtain every $key\_update$ value from its revocation epoch onward. Missing even a single update breaks the chain integrity.
• Persistent Collusion Requirement: Colluding devices must share $key\_update$ values continuously and in real-time, rather than through one-time exchanges.
• Increasing Attack Complexity: The longer a device remains revoked, the more $key\_update$ values it must collect, making sustained collusion progressively more difficult to maintain.

However, practical constraints in real-world “cloud–terminal” centralized IoT environments render such collusion highly challenging:

• Update Frequency: In real-time IoT systems, key updates typically occur every few seconds to minutes.
• Continuous Monitoring Requirement: To maintain decryption capability, a revoked device would need to receive $key\_update$ values continuously and reliably throughout the revocation period.
• Difficulty in Maintaining Covert Channels: Establishing and sustaining a hidden communication channel that operates at the same frequency as system updates is particularly challenging for resource-constrained IoT devices with limited computational and communication capabilities.
• Detection Risk: Such persistent, periodic communication patterns are more susceptible to detection by network monitoring and intrusion detection systems.

The practical effectiveness of LOR-A2ABE in IoT environments is demonstrated by its requirement for strict continuity of the version chain, which raises the practical barrier for mounting collusion attacks beyond the reach of typical resource-constrained terminals. This approach achieves the dual objectives of ensuring highly efficient ($\mathcal{O}\left(1\right)$) revocation—a critical requirement for large-scale IoT deployments—while providing effective protection against realistic threats in actual operational scenarios. Ultimately, this design aligns with the security realities of IoT ecosystems, where operational efficiency and protection against sporadic, opportunistic attacks take precedence over defending against unbounded theoretical adversaries.

4.4. IND-CPA Security Proof

Theorem 1.

Our proposed CP-ABE scheme achieves adaptive IND-CPA security within the random oracle model, relying on the Decisional Linear (DLIN) assumption.

Proof of Theorem 1.

Suppose an adversary $\mathcal{A}$ can win the security game ${\mathsf{Game}}_{\mathsf{CP}-\mathsf{ABE}}^{\mathsf{IND}-\mathsf{CPA}}(\mathcal{A},\lambda )$ with a non-negligible advantage $\epsilon$. In this case, we can build a simulator $\mathcal{B}$ that utilizes $\mathcal{A}$ to solve the DLIN problem with advantage $\epsilon$.

Given a DLIN instance defined as follows:

$$\begin{array}{cc}\hfill A& =g_1,B=g_2,C=g_1^{b_1},D=g_1^{b_2},E=g_2^{b_1},F=g_2^{b_2},\hfill \end{array}$$

(32)

$$\begin{array}{cc}\hfill G& =g_1^{b_1{s}_1},H=g_1^{b_2{s}_2},I=g_2^{b_1{s}_1},J=g_2^{b_2{s}_2},Y,Z,\hfill \end{array}$$

(33)

where $s=s_1+s_2$, $R\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$, and the challenger $\mathcal{C}$ randomly chooses $b\in \{0,1\}$. If $b=0$, set $(Y,Z)=(g_1^s,g_2^s)$; otherwise $(Y,Z)=(g_1^R,g_2^R)$. The simulator $\mathcal{B}$ guesses the value of b as follows.

Phase 1: Initialization. $\mathcal{B}$ picks $\alpha \stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$ and sets:

$$\begin{array}{cc}\hfill pk& =\left(H,p,G_1,G_2,G_T,e,B^{\beta },A,B,E,F,e{(A,B)}^{\alpha }\right),\hfill \end{array}$$

(34)

$$\begin{array}{cc}\hfill msk& =(\alpha ,\beta ).\hfill \end{array}$$

(35)

$\mathcal{B}$ sends $pk$ to the adversary $\mathcal{A}$ and keeps $msk$ secret.

Phase 2: Query Phase 1. $\mathcal{A}$ is allowed to make a polynomial number of queries to the following oracles:

• Random oracle $H(·)$: $\mathcal{B}$ maintains the lists $P=\langle H\left(x_i\right),h_i,k_i\rangle$, $L=\langle H(0\parallel x_i)+1,h_{0,i},t_i\rangle$, $Q=\langle H(1\parallel x_i)+1,h_{1,i},{\sigma }_i\rangle$, $W=\langle H(0\parallel x_i)+1,h{h}_{0,i},w_i\rangle$, $N=\langle H(1\parallel x_i)+1,h{h}_{1,i},{\delta }_i\rangle$, where $h_i=A^{k_i}=g_1^{k_i}$, $h_{0,i}=C^{t_i}=g_1^{{b_{1}t}_i}$, $h_{1,i}=D^{{\sigma }_i}=g_1^{b_2{\sigma }_i}$, $h{h}_{0,i}=E^{w_i}=g_2^{b_1{w}_i}$, $h{h}_{1,i}=F^{{\delta }_i}=g_2^{b_1{\delta }_i}$. On a query for $H\left(x_i\right)$, $H(0\parallel x_i)+1$ or $H(1\parallel x_i)+1$, $\mathcal{B}$ checks whether the value already exists in the corresponding list. If yes, it returns the recorded $h_i$, $h_{0,i}$, $h_{1,i}$, $h{h}_{0,i}$ or $h{h}_{1,i}$; otherwise it picks a random ${\xi }_i\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$ and returns $A^{{\xi }_i}$, $C^{{\xi }_i}$, $D^{{\xi }_i}$, $E^{{\xi }_i}$ or $F^{{\xi }_i}$, respectively, and stores the new entry in the list.
• Key-generation oracle $O_{\mathsf{KeyGen}}(·)$: $\mathcal{A}$ submits an attribute set $S=\left\{u_i\right\}$. $\mathcal{B}$ queries $H(·)$ for each $u_i$ to obtain $h_i$, $h_{0,i}$ and $h_{1,i}$. Choosing random $r,ver,nonce\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$, $\mathcal{B}$ constructs the secret key as:

  $$\begin{array}{cc}\hfill s{k}_1& =A^r,s{k}_2=A^{\alpha +\beta r},s{k}_{3,u}=A^{t_{i}r},s{k}_{4,u}=A^{{\sigma }_{i}r},\hfill \end{array}$$

  (36)

  $$\begin{array}{cc}\hfill s{k}_5& =e{(A^{\alpha },B)}^{H(nonce\parallel ver)}.\hfill \end{array}$$

  (37)
  Indeed,

  $$\begin{array}{cc}\hfill s{k}_{3,u}& =g_1^{H\left(0\left|\right|u_i\right)r/b_1}{g}_1^{r/b_1}=g_1^{(H\left(0\left|\right|u_i\right)+1)r/b_1}=g_1^{\left(b_1{t}_i\right)r/b_1}=A^{t_{i}r},\hfill \end{array}$$

  (38)

  $$\begin{array}{cc}\hfill s{k}_{4,u}& =g_1^{H\left(1\left|\right|u_i\right)r/b_1}{g}_1^{r/b_1}=g_1^{(H\left(1\left|\right|u_i\right)+1)r/b_1}=g_1^{\left(b_1{\sigma }_i\right)r/b_1}=A^{{\sigma }_{i}r}.\hfill \end{array}$$

  (39)
  $\mathcal{B}$ returns $s{k}_S=\left(s{k}_1,s{k}_2,{\{s{k}_{3,u},s{k}_{4,u}\}}_{u\in S},s{k}_5\right)$ to $\mathcal{A}$ and records the user information in the user list $\mathsf{UL}$.
• Revocation oracle $O_{\mathsf{revok}}(·)$: $\mathcal{A}$ submits a user $uid$ to be revoked, provided $uid\in \mathsf{UL}$ and $uid\notin \mathsf{RL}$. $\mathcal{B}$ picks new $ve{r}^{\prime },nonc{e}^{\prime },s^{\prime }\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$ and sets

  $$\begin{array}{cc}\hfill update& =H(nonc{e}^{\prime }\parallel ve{r}^{\prime }),\hfill \end{array}$$

  (40)

  $$\begin{array}{cc}\hfill key\_update& =e{(A^{\alpha },B)}^{update}.\hfill \end{array}$$

  (41)
  It then simulates the updated ciphertext:

  $$\begin{array}{cc}\hfill c{t}_0^{\prime }& =c{t}_0·e{(A,B)}^{\alpha s^{\prime }},\hfill \end{array}$$

  (42)

  $$\begin{array}{cc}\hfill c{t}_2^{\prime }& =c{t}_2·B^{s^{\prime }+update},\hfill \end{array}$$

  (43)

  $$\begin{array}{cc}\hfill c{t}_5^{\prime }& =c{t}_5·B^{\beta (s^{\prime }+update)},\hfill \end{array}$$

  (44)

  and returns $c{t}^{\prime }=\left(c{t}_0^{\prime },{\left\{c{t}_{1,i}\right\}}_{i\in \left[n_1\right]},c{t}_2^{\prime },c{t}_3,c{t}_4,c{t}_5^{\prime }\right)$ together with $key\_update$ to $\mathcal{A}$. $\mathcal{B}$ records $\mathit{Record}\left[uid\right]=\{ve{r}^{\prime },nonc{e}^{\prime },update,key\_update\}$.
• Key-update oracle $O_{\mathsf{KeyUpdate}}(·)$: $\mathcal{A}$ submits $uid$ and $key\_update$, provided $uid\in \mathsf{UL}$ and $uid\notin \mathsf{RL}$. $\mathcal{B}$ updates the user’s secret-key component as $s{k}_5^{\prime }=s{k}_5·key\_update$ and returns the updated key.
• Outsourced-decryption oracle $O_{\mathsf{Transform}}(·)$: $\mathcal{A}$ provides a ciphertext $ct$ and a user $uid$ whose attribute set meets the access policy associated with $ct$. Assuming there exist coefficients ${\gamma }_{i}i\in I$ satisfying $\sum i\in I{\gamma }_i{M}_i=(1,0,\dots ,0)$, $\mathcal{B}$ proceeds to compute the transformation key:

  $$\begin{array}{c}\hfill TK={\displaystyle \frac{e(s{k}_2,c{t}_2)e\left({\prod }_{i\in I}{\left(c{t}_{1,\pi \left(i\right)}\right)}^{{\gamma }_i},s{k}_1\right)}{e(s{k}_1,c{t}_5)e\left({\prod }_{i\in I}{\left(s{k}_{3,i}\right)}^{{\gamma }_i},c{t}_3\right)e\left({\prod }_{i\in I}{\left(s{k}_{4,i}\right)}^{{\gamma }_i},c{t}_4\right)}},\end{array}$$

  (45)

  and returns $TK$ to $\mathcal{A}$.

Phase 3: Challenge. $\mathcal{A}$ selects two messages $m_0$ and $m_1$ of the same length, along with a target access policy $(M,\pi )$. This choice is subject to the constraint that all attribute sets previously queried in Phase 2 are unable to satisfy $(M,\pi )$. $\mathcal{B}$ randomly chooses $b\in \{0,1\}$ and encrypts $m_b$ as follows.

For each attribute $\pi {\left(i\right)}^{*}$, $\mathcal{B}$ queries $H(·)$ to obtain $h_{0,i},h_{1,i},h{h}_{0,i},h{h}_{1,i}$, picks random $s_1,s_2\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p$ and a vector $v\stackrel{\$}{\leftarrow }{\mathbb{Z}}_p^{n-1}$. In the exponent we set $H(0\parallel \pi \left(i\right))+1=b_1{w}_i$, $H(1\parallel \pi \left(i\right))+1=b_2{\delta }_i$. Then:

$$\begin{array}{cc}\hfill c{t}_0^{*}& =m_b·e{(Y,B)}^{\alpha },\hfill \end{array}$$

(46)

$$\begin{array}{cc}\hfill c{t}_{1,i}^{*}& =g_2^{M_i^{*}{\left(s\right|\left|v\right)}^{\top }}·g_2^{s_1\left(H\right(0\left|\right|\pi \left(i\right))+1)}{·g}_2^{s_2\left(H\right(1\left|\right|\pi \left(i\right)+1)}=Z^{M_{i,1}^{*}}·B^{{\sum }_{j=2}^n{M}_{i,j}^{*}{v}_j}·I^{w_i}·J^{{\delta }_i},\hfill \end{array}$$

(47)

$$\begin{array}{cc}\hfill c{t}_2^{*}& =g_2^s·g_2^{H\left(nonce\left|\right|ver\right)}=Z·B^{H(nonce\parallel ver)},\hfill \end{array}$$

(48)

$$\begin{array}{cc}\hfill c{t}_3^{*}& =I,\hfill \end{array}$$

(49)

$$\begin{array}{cc}\hfill c{t}_4^{*}& =J,\hfill \end{array}$$

(50)

$$\begin{array}{cc}\hfill c{t}_5^{*}& =g_2^{s(\beta +1)}·g_2^{\beta H\left(nonce\left|\right|ver\right)}=Z^{\beta +1}·B^{\beta H(nonce\parallel ver)},\hfill \end{array}$$

(51)

$$\begin{array}{cc}\hfill c{t}^{*}& =\left(c{t}_0^{*},{\left\{c{t}_{1,i}^{*}\right\}}_{i\in \left[n_1\right]},c{t}_2^{*},c{t}_3^{*},c{t}_4^{*},c{t}_5^{*}\right).\hfill \end{array}$$

(52)

$\mathcal{B}$ sends $c{t}^{*}$ to $\mathcal{A}$.

Phase 4: Query Phase 2. $\mathcal{A}$ may again issue a polynomial number of queries, subject to the same restrictions as in Phase 2 and the additional constraints:

• No $O_{\mathsf{KeyGen}}\left(S\right)$ query may use an attribute set S satisfying $(M^{*},{\pi }^{*})$.
• No $O_{\mathsf{revok}}\left(uid\right)$ query is allowed for a user $uid$ whose attribute set satisfies $(M^{*},{\pi }^{*})$ and who already obtained the corresponding key in Phase 2.
• No $O_{\mathsf{KeyUpdate}}(uid,update)$ query may use an update for a revoked user.
• The oracle $O_{\mathsf{Transform}}(·)$ cannot be queried on the challenge ciphertext $c{t}^{*}$.

Phase 5: Guess. $\mathcal{A}$ outputs a guess $b^{\prime }$. If $b^{\prime }=b$, $\mathcal{B}$ outputs ${\mu }^{\prime }=0$ (meaning that $(Y,Z)$ is a valid DLIN tuple); otherwise $\mathcal{B}$ outputs ${\mu }^{\prime }=1$ (meaning that $(Y,Z)$ is random).

When $\mu =0$, $\mathcal{A}$ has advantage $\epsilon$, so $Pr[b^{\prime }=b\mid \mu =0]={\displaystyle \frac{1}{2}}+\epsilon$; when $\mu =1$, $\mathcal{A}$ has no advantage, so $Pr[b^{\prime }=b\mid \mu =1]={\displaystyle \frac{1}{2}}$. Consequently,

$$\begin{array}{cc}\hfill Pr[{\mu }^{\prime }=\mu ]& ={\displaystyle \frac{1}{2}}Pr[{\mu }^{\prime }=\mu \mid \mu =0]+{\displaystyle \frac{1}{2}}Pr[{\mu }^{\prime }=\mu \mid \mu =1]={\displaystyle \frac{1}{2}}\left({\displaystyle \frac{1}{2}}+\epsilon \right)+{\displaystyle \frac{1}{2}}·{\displaystyle \frac{1}{2}}={\displaystyle \frac{1}{2}}+{\displaystyle \frac{\epsilon }{2}}.\hfill \end{array}$$

(53)

Thus, the advantage of $\mathcal{B}$ in solving the DLIN problem is

$$\begin{array}{cc}\hfill {\mathbf{Adv}}_{\mathcal{B}}^{\mathsf{DLIN}}\left(\lambda \right)& =\left|Pr[{\mu }^{\prime }=\mu ]-\frac{1}{2}\right|={\displaystyle \frac{\epsilon }{2}}.\hfill \end{array}$$

(54)

This completes the proof. □

4.5. Anonymity Security Proof

Theorem 2.

Our proposed CP-ABE scheme achieves adaptive anonymity within the random oracle model, relying on the Decisional Linear (DLIN) assumption.

Proof. 

Suppose an adversary $\mathcal{A}$ can win the security game ${\mathsf{Game}}_{\mathsf{CP}-\mathsf{ABE}}^{\mathsf{IND}-\mathsf{CPA}}(\mathcal{A},\lambda )$ with a non-negligible advantage $\epsilon$. In this case, we can build a simulator $\mathcal{B}$ that utilizes $\mathcal{A}$ to solve the DLIN problem with advantage $\epsilon$.

The DLIN instance is given as in the IND-CPA proof. $\mathcal{B}$ proceeds as follows.

Phase 1 and 2: Identical to those in the IND-CPA proof.

Phase 3: Challenge. $\mathcal{A}$ submits two challenge access policies $(M^{*},{\pi }_0^{*})$ and $(M^{*},{\pi }_1^{*})$ that share the same attribute–name structure but differ in attribute values, together with two equal-length messages $m_0,m_1$. Here ${\pi }_b^{*}\left(i\right)=(n_{\pi \left(i\right)},v_{\pi \left(i\right)}^b)$ for $b\in \{0,1\}$.

$\mathcal{B}$ randomly picks $b\in \{0,1\}$ and encrypts $m_b$ under $(M^{*},{\pi }_b^{*})$. For each attribute ${\pi }_b^{*}\left(i\right)$, $\mathcal{B}$ queries $H(·)$ to obtain $h_{0,i},h_{1,i},h{h}_{0,i},h{h}_{1,i}$. Because $v_{\pi \left(i\right)}^0\ne v_{\pi \left(i\right)}^1$, the values $w_i^0$ (from $h{h}_{0,i}=g_2^{b_1{w}_i^0}$) and $w_i^1$, as well as ${\delta }_i^0$ (from $h{h}_{1,i}=g_2^{b_2{\delta }_i^0}$) and ${\delta }_i^1$, are independently random.

Setting $H(0\parallel \pi \left(i\right))+1=b_1{w}_i^b$ and $H(1\parallel \pi \left(i\right))+1=b_2{\delta }_i^b$ in the exponent, $\mathcal{B}$ computes the challenge ciphertext exactly as in the IND-CPA challenge phase:

$$\begin{array}{cc}\hfill c{t}_0^{*}& =m_b·e{(Y,B)}^{\alpha },\hfill \end{array}$$

(55)

$$\begin{array}{cc}\hfill c{t}_{1,i}^{*}& =Z^{M_{i,1}^{*}}·B^{{\sum }_{j=2}^n{M}_{i,j}^{*}{v}_j}·I^{w_i^b}·J^{{\delta }_i^b},\hfill \end{array}$$

(56)

$$\begin{array}{cc}\hfill c{t}_2^{*}& =Z·B^{H(nonce\parallel ver)},\hfill \end{array}$$

(57)

$$\begin{array}{cc}\hfill c{t}_3^{*}& =I,\hfill \end{array}$$

(58)

$$\begin{array}{cc}\hfill c{t}_4^{*}& =J,\hfill \end{array}$$

(59)

$$\begin{array}{cc}\hfill c{t}_5^{*}& =Z^{\beta +1}·B^{\beta H(nonce\parallel ver)},\hfill \end{array}$$

(60)

$$\begin{array}{cc}\hfill c{t}_b^{*}& =\left(c{t}_0^{*},{\left\{c{t}_{1,i}^{*}\right\}}_{i\in \left[n_1\right]},c{t}_2^{*},c{t}_3^{*},c{t}_4^{*},c{t}_5^{*}\right).\hfill \end{array}$$

(61)

$\mathcal{B}$ sends $c{t}_b^{*}$ to $\mathcal{A}$.

Analysis:

• If $b=0$: then $(Y,Z)=(g_1^s,g_2^s)$, $I=g_2^{b_1{s}_1}$, $J=g_2^{b_2{s}_2}$. Substituting into $c{t}_{1,i}^{*}$ gives

  $$\begin{array}{cc}\hfill c{t}_{1,i}^{*}& =g_2^{s{M}_{i,1}^{*}}·g_2^{{\sum }_{j=2}^n{M}_{i,j}^{*}{v}_j}·{\left(g_2^{s_1{b}_1}\right)}^{w_i^b}·{\left(g_2^{s_2{b}_2}\right)}^{{\delta }_i^b}=B^{M_i^{*}{(s\parallel v)}^{\top }+s_1{b}_1{w}_i^b+s_2{b}_2{\delta }_i^b}.\hfill \end{array}$$

  (62)

  Because $H(0\parallel \pi \left(i\right))+1=b_1{w}_i^b$ and $H(1\parallel \pi \left(i\right))+1=b_2{\delta }_i^b$, we have

  $$\begin{array}{cc}\hfill c{t}_{1,i}^{*}& =g_2^{{M*}_i{\left(s\right|\left|v\right)}^{\top }+s_1(H\left(0\right|\left|\pi \left(i\right)\right)+1)+s_2(H\left(0\right|\left|\pi \left(i\right)\right)+1)}=B^{M_i{(s\parallel v)}^{\top }+s+s_{1}H(0\parallel \pi \left(i\right))+s_{2}H(1\parallel \pi \left(i\right))},\hfill \end{array}$$

  (63)

  which is a valid encryption of $m_b$ under $(M^{*},{\pi }_b^{*})$ with attribute value $v_{\pi \left(i\right)}^b$.
• If $b=1$: then $(Y,Z)=(g_1^R,g_2^R)$, and

  $$\begin{array}{cc}\hfill c{t}_{1,i}^{*}& =B^{R{M}_{i,1}^{*}}·B^{{\sum }_{j=2}^n{M}_{i,j}^{*}{v}_j}·B^{s_1{b}_1{w}_i^b}·B^{s_2{b}_2{\delta }_i^b}.\hfill \end{array}$$

  (64)
  The term $g_2^{R{M}_{i,1}^{*}}$ is completely random, making $c{t}_{1,i}^{*}$ a random element of $G_2$ that carries no information about the attribute value $v_{\pi \left(i\right)}^b$.

Phase 4: Query Phase 2. $\mathcal{A}$ may again issue queries, with the restriction that every queried attribute set S must not satisfy $(M^{*},{\pi }_b^{*})$, and $\mathcal{A}$ is forbidden to query any attribute set matching the challenge policy $(M^{*},{\pi }_b^{*})$.

Phase 5: Guess. $\mathcal{A}$ outputs a guess $b^{\prime }$. If $b^{\prime }=b$, $\mathcal{B}$ outputs ${\mu }^{\prime }=0$; otherwise $\mathcal{B}$ outputs ${\mu }^{\prime }=1$.

When $\mu =0$, $\mathcal{A}$ has advantage ${\epsilon }^{\prime }$, so $Pr[b^{\prime }=b\mid \mu =0]={\displaystyle \frac{1}{2}}+{\epsilon }^{\prime }$; when $\mu =1$, $Pr[b^{\prime }=b\mid \mu =1]={\displaystyle \frac{1}{2}}$. Hence

$$\begin{array}{c}\hfill Pr[{\mu }^{\prime }=\mu ]={\displaystyle \frac{1}{2}}\left({\displaystyle \frac{1}{2}}+{\epsilon }^{\prime }\right)+{\displaystyle \frac{1}{2}}·{\displaystyle \frac{1}{2}}={\displaystyle \frac{1}{2}}+{\displaystyle \frac{{\epsilon }^{\prime }}{2}},\end{array}$$

(65)

and

$$\begin{array}{c}\hfill {\mathbf{Adv}}_{\mathcal{B}}^{\mathsf{anonymous}}\left(\lambda \right)=\left|Pr[{\mu }^{\prime }=\mu ]-\frac{1}{2}\right|={\displaystyle \frac{{\epsilon }^{\prime }}{2}}.\end{array}$$

(66)

Thus, the scheme is attribute-anonymous under the DLIN assumption. □

4.6. Corollaries

• Revocation Security: Our scheme guarantees forward secrecy: a user revoked at time (epoch) $t_r$ cannot decrypt any ciphertext generated or updated after $t_r$, even if the user’s pre-revocation secret key is compromised.
  This property is intrinsically ensured by our revocation mechanism and is covered by the IND-CPA security proof. Recall the decryption process from Section 3.2: successful recovery of the session key requires the cancellation of the version-timestamp term between $s{k}_5$ and $c{t}_2$.
  For a user revoked at $t_r$, its $s{k}_5$ component is frozen with the hash value $h_{old}=H(nonc{e}_{old}\parallel Ve{r}_{old})$ from the last update it received. Any ciphertext $\mathbf{ct}$ created or refreshed after $t_r$ will be associated with a new, independent hash value $h_{new}=H(nonc{e}_{new}\parallel Ve{r}_{new})$ in its $c{t}_2$ component. Since the revoked user does not receive the $key\_update=e{(g_1^{\alpha },g_2)}^{h_{new}}$, its $s{k}_5$ remains $e{(g_1^{\alpha },g_2)}^{h_{old}}$. The mismatch ($h_{old}\ne h_{new}$) prevents the necessary cancellation in the decryption equation, making decryption fail.
  Formally, in the IND-CPA security game ${\mathsf{Game}}_{\mathsf{CP}-\mathsf{ABE}}^{\mathsf{IND}-\mathsf{CPA}}$ (Section 4.2.1), an adversary $\mathcal{A}$ modeling a forward secrecy attack would need to, after revoking a user, obtain a ciphertext encrypted under a new version/timestamp. The game’s restriction that “the $O_{\mathsf{KeyUpdate}}$ oracle cannot be queried for a revoked user” (Phase 4) directly prohibits the adversary from acquiring the necessary updated key component. Therefore, any advantage ${\mathcal{A}}_{\mathsf{FS}}$ might have in breaking forward secrecy translates into an advantage in the standard IND-CPA game against the updated system parameters, which is proven to be negligible under the DLIN assumption in Theorem 1. Hence, our scheme provides forward secrecy.
• Forward Secrecy: If a user $uid$ is revoked at time t, it cannot decrypt any ciphertext generated after t. This holds because:
  • After revocation, $s{k}_5$ does not contain the new version number and timestamp, so it cannot cancel the corresponding terms in fresh ciphertexts.
  • In the IND-CPA game, the adversary is prohibited from updating the keys of revoked users whose attribute sets satisfy the challenge policy.
  Hence revoked users cannot adapt to the new version, achieving forward secrecy. The forward-security property is already embedded in the IND-CPA security proof, and our scheme provides forward secrecy under the DLIN assumption.

5. Performance Evaluation

5.1. Theoretical Analysis

As shown in

Table 1. Comparison of computational costs among different attribute-based encryption schemes.

Schemes	Key Generation	Encryption	Decryption
BSW [23]	$[(m+1)M+(m+2)E+mH]G_1+\left[mE\right]G_2$	$[lE+lH]G_1+\left[(l+1)E\right]G_2$	$\left[(2x+1)H\right]G_T+(2x+1)P$
CGW [27]	$\left[(3m+6)E\right]G_2$	$[6lnM+(6l+9n)E]G_1$	$[3xM+3xE+6H]G_T+6P$
ABGW [28]	$\left[(2m+1)E\right]G_2$	$[2lM+5lE]G_1$	$[2xM+(x+2)H]G_T+(x+2)P$
FAME [29]	$[(6m+9)M+(9m+9)E+(6m+6)H]G_1+\left[3E\right]G_2$	$[(6ln+3l)M+6lE+(6l+6n)H]G_1+\left[3E\right]G_2$	$[(6x+3)M+6H]G_T+6P$
FABEO [30]	$[1M+(m+2)E+(m+1)H]G_1+\left[1E\right]G_2$	$[lM+2lE+(l+1)H]G_1+\left[2E\right]G_2$	$[2xM+3H]G_T+3P$
FABESA [31]	$[1M+(2m+2)E+2mH]G_1+\left[1E\right]G_2$	$[2lM+3lE+2lH]G_1+\left[3E\right]G_2$	$[3xM+4H]G_T+4P$
LOR-A2ABE	$[(4m+2)E+(2m+1)H]G_1+\left[1E\right]G_T+1P$	$[(l+4)E+lH]G_2$	$[3(x-1)M+3xE]G_1+[xM+xE]G_2+\left[2M\right]G_T+5P$

Notations: m: number of attributes; $l,n$: rows and columns of MSP matrix; x: attributes used in decryption. Abbreviations: M: Mul, E: Exp, H: Hash, P: Pairing.

, we present a theoretical comparison of the computational complexity among various schemes in terms of key generation, encryption overhead, and total decryption overhead (including both user-side and via cloud server). Additionally, Table 1 compares the functional features of these schemes.

Compared with other schemes, the LOR-A2ABE scheme introduces hash and pairing operations during the key generation phase, resulting in higher computational overhead than lightweight schemes such as BSW and FABEO. Nevertheless, these operations enable lightweight user revocation functionality.

In the encryption phase, a notable characteristic of the LOR-A2ABE scheme is that all encryption computations are performed in the $G_2$ group. On the BN254 curve used in our implementation, a single exponentiation in $G_2$ is approximately 3–5 times slower than in $G_1$ according to well-established benchmarking studies [39]. This quantitative performance gap directly explains the slower encryption time of LOR-A2ABE despite its comparable operation count to other schemes. Nevertheless, in the LOR-A2ABE $G_2$ is used for ciphertext computation and $G_1$ for key computation. This design represents an optimization strategy: it reduces the waiting time for users during key issuance while maintaining lightweight final decryption overhead at the client side—where users only perform division operations in the $G_T$ group. Since encryption is handled by the resource-sufficient Certificate Authority (CA) and ciphertexts are stored in the cloud server after encryption, the computational cost of $G_2$ operations does not impact client-side performance. This constitutes a reasonable trade-off in IoT environments.

In the total decryption phase, unlike schemes such as BSW whose costs grow linearly with the number of attributes x, the LOR-A2ABE scheme involves a fixed number of six pairing operations, which is only slightly higher than those of FABEO and FABESA. This represents a significant advantage of the LOR-A2ABE scheme. Moreover, it is worth noting that while supporting user revocation, LOR-A2ABE also outsources a substantial portion of the decryption computations to the cloud server. The user side only needs to perform constant-level lightweight operations to complete decryption, further reducing the computational burden on the client.

In terms of functionality, the LOR-A2ABE scheme achieves anonymity, which enhances user privacy protection. It also supports outsourced decryption and lightweight user revocation, outperforming other schemes in terms of functional completeness.

Theoretical analysis indicates that although the LOR-A2ABE scheme exhibits higher computational overhead in the key generation and encryption phases, it offers notable advantages in decryption efficiency and functional integrity. It is particularly suitable for resource-constrained, decryption-intensive, and dynamically managed centralized IoT environments, demonstrating strong theoretical justification and practical applicability.

5.2. Experimental Analysis

As shown in Figure 2, we implemented the proposed LOR-A2ABE scheme and performed a comprehensive performance comparison with several existing schemes. All experiments were conducted in a Python 3.10 environment using the Charm-Crypto 0.5 library. The hardware platform consisted of an ASUS TUF Gaming A15 laptop equipped with an AMD Ryzen 7 7940H processor and 16 GB RAM. All compared schemes employ the industry-standard asymmetric pairing BN254 curve, ensuring consistent security assumptions for fair performance evaluation. Furthermore, we simulated a worst-case experimental scenario: all attributes in the access policy were concatenated using AND gates (e.g., “(1 AND 2) AND 3”). The number of attributes was incrementally increased from 10 to 500 in steps of 20. Each data point in Figure 2 represents the average execution time over ten independent runs. A full statistical analysis including variance metrics is a subject for future extended benchmarking.

The detailed experimental analysis is presented as follows.

• Setup Time (Figure 2a): The LOR-A2ABE scheme demonstrates significantly higher efficiency in setup time compared to the CGW schemes (which grows from 79 ms to 1.44 s). While it exhibits a slightly longer initialization time (≈35 ms) than schemes such as FABESA (≈19 ms) and FABEO (≈18 ms), its overall setup duration remains low and stable, showcasing the scheme’s reliable and efficient initialization characteristics.
• Key Generation Time (Figure 2b): The experimental results for key generation align with the theoretical analysis. The introduction of a hash operation and an additional pairing to enable the revocation feature results in a higher key issuance time for LOR-A2ABE (86 ms to 2.1 s) compared to other schemes (e.g., FABEO: 11 ms to 281 ms). However, this overhead remains comparable to that of the FAME scheme (89 ms to 1.88 s) and within an acceptable range. It is important to note that LOR-A2ABE targets “cloud–terminal” Centralized IoT Management Environments, where data acquisition systems are relatively static, and key issuance is not a frequent operation. Consequently, the increased key generation overhead has minimal practical impact in real-world deployment.
• Encryption Time (Figure 2c): Consistent with the theoretical expectations, the encryption time of LOR-A2ABE (113 ms to 1.76 s) is marginally higher than that of other schemes (e.g., FABESA: 34 ms to 805 ms) due to the concentration of all computations within the $G_2$ group. Nevertheless, its time growth curve exhibits a relatively flat trend, in contrast to the near-linear growth observed in schemes like CGW (184 ms to 3.44 s) and FAME (68 ms to 1.81 s). This indicates that the LOR-A2ABE scheme can maintain stable encryption efficiency even when handling a large number of attributes.
• Total Decryption Time (Figure 2d): The LOR-A2ABE scheme demonstrates a distinct advantage in total decryption time (constant ≈185 ms). Its performance is comparable to that of efficient schemes like FABESA (≈60 ms) and FABEO (≈45 ms), and crucially, it remains largely invariant with respect to the number of attributes—unlike BSW (572 ms to 13.56 s) and ABGW (316 ms to 6.71 s). Notably, when employing outsourced decryption techniques, the user-side decryption efficiency of LOR-A2ABE drops to only ≈0.2 ms, which is the fastest among all evaluated schemes. This makes it particularly suitable for environments where decryption operations are frequent and user-end resources are severely constrained.
• Revocation Time (Figure 2e): The LOR-A2ABE scheme exhibits constant and low revocation overhead (9.7–22 ms) as the number of attributes increases. This scalability characteristic demonstrates the efficiency of its partial update mechanism, which avoids the linear-cost re-encryption required by traditional revocation approaches.

The experimental analysis confirms that the results for the LOR-A2ABE scheme are in precise agreement with the theoretical predictions. Specifically designed for “cloud–terminal” Centralized IoT Management Environments, LOR-A2ABE successfully achieves lightweight revocation and efficient outsourced decryption, underscoring its significant practical deployment value.

5.3. Theoretical Analysis of Revocation Mechanisms

In Section 5.1 and Section 5.2, we systematically analyzed the performance of relevant CP-ABE schemes during the initialization, key generation, encryption, and decryption phases through both theoretical and experimental comparisons with LOR-A2ABE. However, in terms of revocation functionality, most existing CP-ABE schemes that support revocation are implemented based on the SS512 curve [36,37], whereas LOR-A2ABE adopts the BN254 curve, which offers stronger security guarantees. Since these two curves correspond to different security assumptions and parameter configurations, a direct experimental performance comparison would be invalid due to these differing security foundations. We therefore focus on theoretical complexity analysis, which provides meaningful insights across security levels. The following analysis examines algorithmic complexity characteristics within each scheme’s respective security context, rather than making direct performance comparisons.

As shown in

Table 2. Theoretical complexity comparison of revocation mechanisms.

Scheme	Security Level	Key Update	Ciphertext Update	Outsourced Decryption
LOR-A2ABE	128-bit (BN254)	$\mathcal{O}\left(1\right)$	$\mathcal{O}\left(1\right)$	✓
MTA [36]	96-bit (SS512)	$\mathcal{O}\left(\right|A\left|\right)$	$\mathcal{O}\left(1\right)$	×
TRH [37]	96-bit (SS512)	$\mathcal{O}(log|U\left|\right)$	$\mathcal{O}\left(r\right)$	×

✓: supported; ×: not supported. $\left|A\right|$: number of attributes, $\left|U\right|$: total users, r: size of revocation cover set. Note: Complexity comparisons are presented within their respective security contexts.

, the theoretical complexity analysis reveals that our proposed LOR-A2ABE scheme achieves the most favorable complexity profile for revocation operations, making it particularly suitable for centralized IoT systems that require frequent and efficient revocation operations.

In terms of computational complexity for key update, the LOR-A2ABE scheme achieves constant complexity $\mathcal{O}\left(1\right)$, requiring only one group multiplication per user. Notably, this efficiency is maintained at the higher 128-bit security level (BN254). In comparison, the MTA scheme requires users to update all non-revoked attributes, resulting in linear complexity $\mathcal{O}\left(\right|A\left|\right)$. Meanwhile, the TRH scheme incurs logarithmic overhead $\mathcal{O}(log|U\left|\right)$ due to its binary tree structure. These comparisons highlight LOR-A2ABE’s algorithmic efficiency advantage within its security context.

In terms of computational complexity for ciphertext update, LOR-A2ABE enables constant-complexity updates $\mathcal{O}\left(1\right)$ through partial updates. This contrasts with MTA’s approach which, although also $\mathcal{O}\left(1\right)$, requires full ciphertext re-encryption. Meanwhile, TRH’s complexity $\mathcal{O}\left(r\right)$ depends on the revocation cover set size, which may increase with system scale. The constant overhead of LOR-A2ABE remains advantageous within its higher-security framework.

In terms of theoretical complexity, LOR-A2ABE demonstrates clear advantages for IoT systems. Unlike MTA’s linear key update cost or TRH’s cover-set-dependent ciphertext update, LOR-A2ABE provides constant-time operations while operating at a higher security level. These characteristics align well with IoT requirements including resource constraints and frequent revocation events.

In summary, the theoretical complexity analysis indicates that LOR-A2ABE achieves constant-time key and ciphertext updates ($\mathcal{O}\left(1\right)$) within its 128-bit security framework, making it suitable for resource-constrained IoT architectures where both security and efficiency are critical.

5.4. Performance Inference and Analysis for IoT Terminals

Although the performance evaluation of this scheme was conducted on a general-purpose computing platform (laptop), one of its core design objectives is to substantially reduce the computational burden on IoT terminal devices. To more rigorously assess the applicability of this scheme in real resource-constrained environments, this section combines benchmark data provided by Perazzo et al. [40] from their empirical study on IoT ABE performance to conduct a theoretical inference and comparative analysis of the decryption performance of the LOR-A2ABE scheme on terminal devices (client side). The following analysis provides theoretical performance inferences based on architectural comparisons.

The work of Perazzo et al. [40] presents the first comprehensive empirical measurements (time, energy consumption, battery life) of various ABE schemes, including the classic CP-ABE scheme BSW, on two typical constrained IoT hardware platforms: ESP32 and RE-Mote. Their key conclusion indicates that ABE schemes can be deployed on devices with extremely limited memory and computational resources while achieving acceptable battery life, provided the number of attributes does not exceed 10 and hardware-accelerated cryptography is utilized. Specifically, the BSW scheme requires approximately 1.2 s and consumes about 100 µWh to decrypt a ciphertext with 10 attributes (worst-case policy) on the ESP32 platform.

As described in the system model in Section 3.2, in our “cloud–terminal” centralized IoT architecture, key generation and encryption are performed by the Central Authority (CA), while the majority of decryption computations are offloaded to the resource-abundant Cloud Server (CS). Resource-constrained client devices are only responsible for executing lightweight final decryption steps. Based on the computational complexity analysis in Section 5.1, the client-side decryption in the BSW scheme requires $2x+1$ bilinear pairing operations (where x is the number of matched attributes), with its overhead growing linearly with policy complexity. In contrast, the LOR-A2ABE scheme shifts all bilinear pairing operations to the CS. The client side merely performs two fixed modular division operations in the finite field $G_T$, resulting in a constant computational complexity of $O\left(1\right)$.

Given these architectural differences, we can infer that on the same IoT hardware platform (e.g., ESP32), the decryption time and energy consumption on the LOR-A2ABE client side will no longer increase with the number of attributes but will remain at an extremely low constant level. Compared to the empirically measured second-level decryption latency and hundreds of microwatt-hour energy consumption of the BSW scheme with 10 attributes, the client side of our scheme involves only two basic modular operations. Its expected overhead is bound to be at least one order of magnitude lower than the “second-hundreds of µWh” level of BSW. Reference [40] has already confirmed that BSW is “feasible” on constrained terminals, while the computational load on the LOR-A2ABE client side is significantly lower than that of BSW. Therefore, it is reasonable to infer that under the same deployment conditions (number of attributes ≤ 10), the energy efficiency performance of LOR-A2ABE on the terminal side will be far superior to that of traditional schemes, with a more negligible practical impact on device battery life.

Consequently, although this work does not involve on-site IoT deployment, by integrating the structural advantages of our scheme (outsourced decryption, constant terminal overhead) with reliable third-party IoT performance benchmarks, we can theoretically and robustly argue that the LOR-A2ABE scheme fully meets the requirements for efficient operation on resource-constrained IoT terminals such as ESP32. Its client-side performance is significantly superior to that of traditional CP-ABE schemes that have been empirically validated as feasible.

6. Conclusions and Future Work

This paper addresses the access control requirements in “cloud–terminal” centralized IoT Management Environments by proposing a lightweight anonymous attribute-based encryption scheme with support for lightweight revocation and outsourced decryption. The scheme embeds hash functions into both the key and ciphertext structures, enabling efficient attribute revocation and outsourced decryption without introducing significant computational overhead. Security analysis demonstrates that the LOR-A2ABE scheme achieves IND-CPA security under the Decisional Linear Diffie–Hellman assumption. Both theoretical and experimental results show that the proposed scheme exhibits excellent efficiency in decryption and revocation operations. It is particularly suitable for IoT scenarios characterized by frequent data updates, resource-constrained terminals, and dynamically evolving access policies, thereby providing a feasible technical pathway for achieving secure and efficient fine-grained access control in practical deployments.

In future work, we plan to further investigate lattice-based post-quantum secure lightweight anonymous attribute-based encryption schemes to mitigate potential threats posed by quantum computing. This direction aims to offer both theoretical foundations and practical guidance for the long-term secure deployment of IoT systems. Furthermore, while the performance inference presented in Section 5.4 strongly supports the efficiency of LOR-A2ABE on resource-constrained terminals based on architectural comparison and established benchmarks, conducting direct on-device measurements on platforms such as ESP32 or ARM Cortex-M remains an important empirical step for future validation. Exploring system architectures that integrate with other emerging IoT-specific security constructs, such as hybrid access control models for smart environments [41], and with lightweight in-sensor computing frameworks, presents a valuable direction for building more comprehensive and efficient secure IoT systems.